Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 32 replies
  • Subscribers 0 subscribers
  • Views 15435 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
    same issue in 9.194-5 [:(]
    Is there anyone that has the same issue? I don't believe that this is only a local problem.

    any suggestions?
  • 0
    it seems that this issue only occures in transparent Proxy mode
  • 0
    I think you'll need to specify your HTTPS inspection mode, full (Decrypt and scan) or just domain(URL filtering only)?  I'm going to guess it's just domain but somehow a the packet containing the SNI is dropped.  I'd consider going wired if it's wireless, upgrading to 9.194, and performing a packet capture to confirm behavior.
  • 0
    The HTTPS inspection mode is "full (Decrypt and scan)". The release is  9.194-5. In "URL filtering only" mode, I don't have issues.
  • 0 in reply to Michael Dunn
    I'd like to add my own experiences here too.

    UTM 9.194-5, Web Protection is on in Transparent mode, AD-SSO is selected.  I'm doing SNI filtering only (URL Filtering on SSL requests).

    I can consistently produce this error.

    Using ANY browser (same host, three different browsers being IE, Chrome and FF all latest) and opening an SSL site for the first time I get informed that the site has failed the SSL check and that it may be compromised.  Looking into the cert details I see that the UTM has issued its own certificate, see screen shot 1. (first concern is that i'm NOT doing FULL SSL decryption)

    Nothing I do, short of turning off the SNI inspection and restarting http proxy, will grant me clean access to SSL sites.

    what I need to do is to first open up a plain text internet page, anything without SSL.

    Once I've done this, I can then refresh or re-open an SSL site and it proceeds to work as expected.  The SSL certificates match and the web filter logs have captured the SSL transaction and logged accordingly.

    AD-SSO in Transparent mode works great.  it's just this one SNI issue that is bugging me.  What complicates this matter more so is that the live logs don't show this initial exchange as the request from the client to the proxy is reset, and the browser states that 'no data was exchanged' (chrome specifically)...  If I click proceed on the certificate warning I get a messy block page which would indicate DNS resolution of the UTM has failed, and as a result auth has failed and browsing blocked, which is my intention to do so... however, auth should not have failed.

    The only clue I can find in the Web Fitler logs is this.  I'm unsure if it's related, but, it doesn't seem to stop me from being AD-SSO authenticated when visiting plain text sites initially.






    ==

    When in doubt, Script it out.

  • 0
    Hi azron,

    Can you confirm two things:

    1) If you turn AD SSO (in transparent mode) off, does the problem go away?

    2) If it does not, have you tried the same thing in 9.1?
  • 0
    Hi michael,
    I've changed my network topology because there was a miss configuration. Some internal packets are arrived at the external Interface of the utm. Now all is ok.

    Today, I can't reproduce any of these issues. All is working as expected. 
    I'll test a few days more..

    regards
    mod
  • 0
    Actually I just turned on Url Filtering Only with "Transparent Mode" and I have the same issue with blocked site. If I go to https://google.com I get googles correct certificate. However I changed the reputation of https://sni.velox.ch/ to be malicious so I could verify SNI was working and I have the same issue. It does block the site but it uses the ip instead of the url.

    Edit: and I don't have AD SSO at the moment.
  • 0
    This sounds as if it's "by-design" (but perhaps necessitating documentation) rather than a typical bug.

    If action == "block" AND https_filter_mode == "URL filtering only" then
      return SSL_cert_by_IP
    else
      do_other_stuff
    endif

    Imagine a client that has cached the certificate or knows the chain of a certificate for a given site.  Now, you generate a cert for that domain and the client will scream about a forged certificate (which in my opinion is a higher error and leess likely to be bypassable) rather than saying mismatched name (and possibly untrusted if you haven't trusted the UTM's CA).

    So I'd say this falls into:

    1) It's a documentation bug

    2) also, there should be a feature-request to allow the administrator to manipulate this behavior
Unfiltered HTML