Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 32 replies
  • Subscribers 0 subscribers
  • Views 15437 views
  • Users 0 members are here
Options
Suggested

[9.193-11][Bug] SSL Errors

mod2402
I've some strange errors if I switch-on HTTPS scanning. 

Sometimes the UTM generates wrong certificates with ip address instead of domainname. See images (google-chrome.jpg, google-ff.png, google-ie.png)

Mostly, I see ssl log errors and IE shows faulty certificate, but certificate itself Shows, all is good.. See images (google-ie2.png, google-ie3.png)

[HTML]2014:02:03-12:50:53 asg-1 httpproxy[6276]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0x13d81540" function="ssl_log_errors" file="ssl.c" line="86" message="C 192.168.xx.xx: 4096207728:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:s3_pkt.c:989:"[/HTML]

HTTPS (SSL) traffic is on (Decrypt and scan)
  • 0
    If the UTM cert is in the trusted pool like it should be, it won't scream about a forged cert. If you see, my cert shows it is trusted, just the address is wrong. If they used the address instead of the ip, there would be no issues.
  • 0
    I thought I had a client that would do so but now I can't seem to recreate the client rejection.

    Thinking now, it'll generate a cert for the proper name when in "Decrypt and scan" so there's not any difference in the security impact.

    I'll agree that applying the above logic when a name can be determined is incorrect logic.
  • 0
    We are looking into this.  At issue is whether - at the time of the TCP / SSL connection - we can determine the correct address.  In Standard mode this is easy and in transparent it can be difficult.  It might be that the software is behaving as best as it can due to technical limitations - even though it sucks.  It may be that there is a bug or a way to improve it in the near timeframe.
  • 0 in reply to Michael Dunn
    We are looking into this.  At issue is whether - at the time of the TCP / SSL connection - we can determine the correct address.  In Standard mode this is easy and in transparent it can be difficult.  It might be that the software is behaving as best as it can due to technical limitations - even though it sucks.  It may be that there is a bug or a way to improve it in the near timeframe.


    Understood, I think it (For Url Filtering Only) should be able to. Because if the SSL url it isn't blocked, it passes the normal cert though. If it is, it then generates the cert. At least that's what it looks like when I tested.
  • 0
    The issue comes back in my enviroment. I'm now at 9.200-11..
    This issue occurs not everytime, just sometimes..
    Tested with IE 10 and Firefox.. (no authentication)
  • 0
    One of these issues is very strange. If I start my bowser with start page "www.google.de" the certificate shows "www.google.com". See attached image..
  • 0
    mod2402, I am unclear - are you using "URL Filtering Only" or are you using "Decrypt and Scan".

    The behavior is different for these two scenarios and investigation must be separate.
  • 0
    Here is an attempt to explain the process as well as I know it right now.

    The following assumes you are NOT using AD SSO (which complicates things).


    Client opens TCP connection and tries to do SSL handshake with Internet Web Server.

    IF HTTPS scanning is URL Filter Only -or- Decrypt
      THEN Look at SSL handshake and SNI to determine destination domain name and categorize it

      IF destination domain should be blocked
         THEN man-in-the-middle.  Issue a certificate based on domain (if possible) or IP.  Display block page text.
      IF destination domain should be allowed AND URL Filter Only
         THEN allow the HTTPS handshake to continue with destination
      IF destination domain should be allowed AND Decrypt and Scan
         THEN man-in-middle.  UTM initiates SSL handshake with destination and gets certificate information.  UTM then issues a certificate to client based on the information it got from the real certificate (including correct domain name).  Allow the traffic.


    Therefore:
    1) Regardless of the HTTPS scanning option selected, if you get a block page you will get a man-in-the-middle and be issued a certificate from the UTM.  This certificate might have the domain or the IP.
    2) If you are doing Decrypt and Scan it and the page is Allowed then it should be using a certificate with the correct name.


    Some people are experiencing 1) which is to be expected and NOT a bug.  We are looking at whether we can do anything to make the issue by IP less common.
    mod2402 is experiencing a problem with 2) where he has an incorrect certificate on an allowed connection with decrypt and scan.  This is being investigated.

    If there are any issues not detailed in this post, please let me know.
  • 0
    You will be please to know that we have discovered the problem and it should be fixed in 9.201.

    This fix will greatly reduce (but not eliminate) how often you will a certificate based on IP for block pages.  It will also eliminate the error where two domain names share the same IP and you get a certificate with the wrong name (mod4202's problem)
Unfiltered HTML