Guest User!

You are not Sophos Staff.

[9.193-11][Bug] SSL Errors

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)
Parents
  • 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.

Reply
  • 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.

Children
No Data