We changed some SSL settings on our Apache HTTP servers, namely adding SNI support. After this change it seems that some users behind corporate SSL proxies (MITM boxes) get vague errors such as ERR_TUNNEL_CONNECTION_FAILED. The certificates we use have not changed, nor has the default cert that is served from the IP address in case of a non-SNI browser. The cert chains are served as before, as the Qualys SSL test gives a rating of "A", as before.

Are the proxies caching something? What could cause these errors? Is there anything we can do? Unfortunately, I have no idea on what software they are running, so this is just guessing.

enter image description here


First, caching can't be involved as you (or more correctly the proxy) have yet to complete the TLS handshake before retrieving pages.

Next, check your server logs, although there is a good possibility you wont find anything except if you have debug enabled. This because as the handshake isn't yet done when clients get a failure, there is no HTTP request hitting your server.

Next, can you reproduce the problem by yourself? If so troubleshooting get's easier. Without the possibility to reproduce the problem, I've had success leaving a tcpdump for some time collecting connections then opening the resulting pcap and checking for handshake failures

And a shoot in the dark, make sure your ServerName / Alias are correctly configured on your HTTPS Vhosts, and while we are at it can you post the output of:

apachectl -S 

in your question?

This is all i can suggest based on your details.


Background: some comments indicated confusion with the behaviour for regular proxies, not SSL inspection proxies: MITM (Man In The Middle) proxies are proxies performing TLS/SSL interception and inspection. They accept a client request for a target HTTPS site, and provide a (faked) certificate from a trusted root certification authority (selected/created by the admin, and trusted by the client). and then can read - in cleartext - any communication between the client and the target site.

SSL Inspection tends to be implemented differently by different vendors: it's not a standard, and so MITM proxies work differently. What's common is that once the proxy has terminated the connection to itself, it makes a new connection to the target site, using its own SSL library and technology. That "final" outbound connection is the connection which is going to determine the behaviour of the remote site.

Original answer: TLS Server Name Indication (SNI) isn't yet supported by all proxies, particularly older ones. Proxies tend to linger far after they've stopped being supported, because they're critical infrastructure and they're working, so...

I'd guess that in enabling SNI, you might've prevented older SSL Inspection-enabled proxies with less secure connection profiles from allowing a connection. If that can be addressed, that's your best possible path to fixing it - for example, on IIS, there's the concept of a "default" SSL certificate which is used as a fallback if SNI doesn't find a match. If that's not configured for you, or if that's a possibility, that might be best. Apologies it doesn't match your architecture.

When you add that to already-semi-flakey SSL inspection by a proxy which doesn't understand what the other end is doing, or even something as simple as the proxy not being able to correctly resolve the name the client used (disparate DNS for transparent SSL inspection; no client hints as to the server name)... yeah, I can imagine that could be a problem.

I'm unsure how you'd track that down except anecdotally by contact with admins... other than by taking network traces of SSL session setups at your server end, paring them down to just the failures, and then attempting to "footprint" the caller in case of obvious failure (reverse IP lookup on the source, analysis of non-SSL traffic for VIA header clues or similar).

  • Not sure in this case SNI can have an effect, when you use a forward proxy normally you get TCP proxied using the CONNECT method.
    – Fredi
    Nov 28 '16 at 13:03
  • "SNI isn't yet supported by all proxies. And particularly older ones. Proxies tend to linger far after they've stopped being supported, because they're critical infrastructure and they're working, so..." – do you happen to have any stats or pointers on this?
    – tuomassalo
    Nov 28 '16 at 15:32
  • No, just my observation.
    – TristanK
    Nov 29 '16 at 3:57
  • @Fredi, yep, if the proxy's doing SSL inspection, it's a proxy-level thing, otherwise it should just be TCP-session-setup and get-out-of-the-way.
    – TristanK
    Nov 29 '16 at 3:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.