0

About 2 weeks ago users started reporting that they were unable to access two https-only sites. When I inspected these sites I found they were completely intolerant to TLS. In order to connect, SSL3 was required and TLS (1.0-1.2) must be disabled in the browser. Now, with this workaround, the users can connect, however we have found some users do not need to do this at all - that the fallback to SSL3 still works correctly (as before). At first I thought this was some kind of POODLE mitigation, but that doesn't seem to be the issue. All sites are accessible when not on our internal network (I am able to access them at my house with default settings on both Chrome and IE). The only difference is that these networks go through a zScaler proxy at work. However, intermittently, we are able to connect without changing any settings on our internal network, with the proxy intact, leading me to believe that the proxy is not to blame (as was my first thought). The only other idea we have is that it might have something to do with how our 2 GRE routers are routing traffic. Is there anything else we should look into?

1 Answers1

0

Currently no major browser has SSL 3.0 disabled by default (there are often options to disable SSL 3.0 by hand) and all of them have still fallbacks implemented in case TLS does not work. Which means that direct connections should work in most cases.

I see no official statement of Zscaler what they do against POODLE inside the HTTPS interception, but it might be that they are simply in the process of disabling SSL 3.0. This would mean that in some occasions it will still work when your connection is via Zscaler proxy and in other cases SSL 3.0 is already blocked.

Steffen Ullrich
  • 12,227
  • 24
  • 37
  • This is what I initially postulated, however, connecting to the same proxy server with SSL3-only still works correctly. Zscaler insisted it hadn't disabled SSL3 on its proxies yet due to legacy SSL3-only clients. –  Nov 04 '14 at 19:12
  • Can you describe the details of the intolerance? From what I've seen browsers downgrade if the peer closes the connection or sends a RST, but just hang and don't attempt to downgrade if the peer simply does not respond. I've also seen cases where the behavior of the server depends on the ciphers used. It might just be that the ClientHello from some browsers and from Zscaler might trigger a behavior in the server which prevents the downgrade, that is something like just dropping the packet and thus keeping the connection open until timeout. Older F5 versions had a bug like this. – Steffen Ullrich Nov 04 '14 at 19:27
  • If you could share the URLs of the affected sites I would be interested to have a closer look. – Steffen Ullrich Nov 04 '14 at 19:28
  • One of them is (www required) https://www.dora.state.co.us. The same browsers work correctly outside of the network and in certain situations when inside it, which is why I don't believe it's the proxy. –  Nov 04 '14 at 19:40
  • We've also had occasional (rare) success with TLS enabled and no other network changes, which is one of the things that makes the problem all the more vexing. –  Nov 04 '14 at 19:44
  • Interesting is that dora.state.co.us and www.dora.state.co.us resolve to completely different IP so these might be different hosts too (although behind the same router according to tracepath). Maybe some users use the name with and some without www? Also, both IP seem to be down at the moment. – Steffen Ullrich Nov 04 '14 at 20:36
  • I believe one is TLS-only and the other serves HTTP-only content. And in regards to it being down: Could it be? Have they finally chosen to upgrade their servers? –  Nov 04 '14 at 20:40
  • @Seventy: This server now have TLS 1.0 enabled but both TLS version and **extensions** intolerance which is why it is falling back. – Yuhong Bao Nov 13 '14 at 10:20