I noticed today that I could not access https://ssebuild.cased.de/nightly/soot/javadoc. Chrome gave me an ERR_CONNECTION_CLOSED, meaning that the connection was closed by the server. Safari gave me the same error. So I checked the domain via http://www.downforeveryoneorjustme.com/, which told me the domain is up. Therefore I was quite sure it is not an issue of the domain, but must be on my end. A check over a VPN convinced me that the problem is local to my machine. So I disabled my ad-blocker, that didn’t help. Then I disabled and enabled the Avast shields, which allowed me to rule out WebShield as the culprit: With WebShield enabled, I could not access the domain; disabled, I could. As there was no notification from Avast, I inspected the system logs:
Avast Mac Security 2015
Version: 11.16 (46730)
Virus definitions: 16073000
What’s going on here?
I can work around the issue by adding the domain as an entry to the excluded servers in the WebShield settings. But it looks like something is broken in the WebShield proxy.
By the way, it was impossible to copy and paste the Avast version text from “About Avast”, but instead I had to type it (possible error source). It would be nice if that text was selectable too.
Yes, it does work without the exclusion workaround if I disable the “Scan secured connections” option in the WebShield settings. But doesn’t it mean that an infected page would not be detected if the connection is over HTTPS? That’s not desirable.
It does. If you disable HTTPS scanning, than no HTTPS connections are scanned. Today, this is nearby equivalent to turning the web shield completely off.
The problem is clearly visible from the system log message. The system function used to verify the certificate chain - SecTrustEvaluate() - returns kSecTrustResultOtherError for ssebuild.cased.de. This means an error occurred during the certificate chain verification and thus the Avast web shield can not pass this connection. The reason for the error is however unclear for me at the moment - it may be some OS X bug or some restrictive settings applied by default (but not in Safari, that uses the same OS X framework to verify the certificates) together with a somehow broken certificate in the chain.
Anyway, the only solution for you at the moment is to add the web to the exclusions.