My website is inaccessible from a particular workplace proxy upon activating a HTTPS encryption. Switch back to a HTTP connection and it works. I have also confirmed that the website is working from an outside internet connection and Qualys SSL Labs issued an A+ Rating.
Server Configuration
Ubuntu 16.04 with Apache 2.4.18
SSL Certificates issued from Let’s Encrypt (letsencrypt.org)
Ruled Out
Certificate Provider: Managed to access other sites encrypted with Let’s Encrypt certificates.
Keyword Block: This would mean that my HTTP site would not be accessible as well but that is not the case.
A+ on SSL Labs indicates that your server uses fairly modern cipher suites. It’s possible that your proxy is unable to use any of these, similar to how older web browser (think: IE 6) would be unable to visit such a site.
My recommendation would be try the cipher suites recommended by Mozilla’s SSL Configuration Generator in the “Intermediate” or “Old” setting. To do that, you’d replace the SSLProtocol and SSLCipherSuite directives in your apache configuration with the values provided by that site.
If things work with the intermediate settings, you should be okay with those. These ciphers aren’t the best out there, but plenty of big sites think they’re good enough. If things only work with the old settings, I’d definitely look into updating or replacing that proxy rather than changing your server configuration, as those ciphers and protocol are considered fairly insecure nowadays.
In 2012 Jeff Jarmoc pointed out that using proxies this way can result in diminished security because the proxies’ TLS clients are weaker against some security threats than the browsers’ would be. (One reason can simply be that the proxy software probably isn’t updated nearly as frequently as browser software would be.)
I’ve taken your recommendation and tested it with the following settings on Mozzilla’s SSL Configuration Generator.
Unfortunately, even with the “Old” setting, the site is still not working for those users behind the proxy. It still shows an A+ on SSL Labs though. I’ll be leaving the server configured with the cipher suite recommended for any further testing if needed for the next few days.
Perhaps there could be something else I missed out? Twitter is also graded an A+ and the site works for the users.
Error Messages
Internet Explorer - "The proxy server isn’t responding"
Google Chrome - "This site can’t be reached. The connection was reset. [ERR_CONNECTION_RESET]"
Firefox - "Secure Connection Failed"
This indicates that the change did not go into effect. Was the domain in question https://www.circles.life/? I just checked and noticed that this domain is hosted behind CloudFlare. In that case, your browser does not connect directly to your server, but rather to CloudFlare. CloudFlare has a separate certificate for your domain (not from Let's Encrypt), and you can't really change the TLS configuration since that's up to CloudFlare. At least for this domain, Let's Encrypt is not really part of the equation.
What kind of error are you getting? Could you run traceroute ocsp.int-x3.letsencrypt.org if you can't connect at all?
I can confirmed the changes were applied as changing the cipher suite to ALL:+LOW caused the grading to be capped at B on SSL Labs. I’ve attached my configuration file for your reference.
<IfModule mod_ssl.c>
<VirtualHost *:443>
SSLCertificateFile /.../fullchain.pem
SSLCertificateKeyFile /.../privkey.pem
ServerName techlingo.sg
Header always set Strict-Transport-Security "max-age=15768000"
</VirtualHost>
# intermediate configuration, tweak to your needs
SSLProtocol all -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP
#SSLCipherSuite ALL:+LOW
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling off
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/.../ocsp(128000)
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
</IfModule>
There were no error messages and the browser just shows a blank page. Other OSCP sites will download a file. Anyway, OCSP Stapling is disabled and I believe it shouldn’t be the cause of this issue.
Apparently the tracert command in cmd will not work behind the proxy as they might have blocked some of the protocols. Running it outside the proxy shows the destination at 101.100.190.154 which I believe is not the actual destination.
If that doesn’t change anything, we know it’s likely not protocol/cipher-related.
There are a few other differences between those servers, most of which I don’t think would have any effect on a proxy, but who knows what these things care about. Here’s a list:
helloworld.letsencrypt.org supports OCSP stapling. If the proxy indeed has problems talking to Let’s Encrypt’s OCSP but supports stapling, that could be an explanation. I think this should be enough to enable stapling:
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)```
- `helloworld.letsencrypt.org` supports NPN, your server supports ALPN. This is related to the `openssl` version you're using, NPN is supported by older versions of `openssl` while newer ones support ALPN. If you want to rule out that this is the cause, you'd have to spin up a new web server with `openssl` < `1.0.2`, e.g. Ubuntu 14.04. Wouldn't bother with this until everything else is ruled out.
I don’t think session resumption and NPN are likely candidates, as this should be a fairly common configuration, so odds are many sites would break if your proxy had problems with that. Then again, this is the last TLS-related difference between your site and helloworld.letsencrypt.org I can think of, so who knows, maybe it’s a weird combination of things and one of these two is actually the culprit.
A few of my colleagues realised it may be due to the root certificate not being trusted by the proxy server. Namely DST Root CA X3 and AddTrust External CA Root. The root certificate is the next thing that is similar across all sites that doesn’t work behind the proxy which we’ve previously mentioned.
Why https://helloworld.letsencrypt.org still works may be due to a 2nd certificate that is shown in SSL Labs from IdenTrust Commercial Root CA 1. Guess the next thing to try changing our Certification Authority and I’ll keep you updated.
The second certificate shown by SSL Labs should only be relevant if your proxy doesn’t support SNI - otherwise, it would only see the certificate chaining up to the DST root. If it actually doesn’t support SNI and gets the certificate chaining up to “IdenTrust Commercial Root CA 1”, it should still fail as that certificate doesn’t include the helloworld.letsencrypt.org domain (only letsencrypt.org and www.letsencrypt.org). Then again, based on the things these proxies get wrong sometimes, it wouldn’t surprise me if they skipped the hostname check.
You are right. Even after trying with a different Certification Authority, the website is still not accessible.
I think we would have to look at other areas since we’ve ruled out this list. I’ll continue researching By the way, the domain in question has been moved to https://techlingo.sg
Here’s a list:
By the way, the domain in question has been moved to