5 ms·
Wonderful and fascinating analysis. Thanks for the data. You can see why SSL proxies would prefer a lighter weight protocol, hijacking all that traffic is taxi
by ColinDabritz 12y ago
Wonderful and fascinating analysis. Thanks for the data.
You can see why SSL proxies would prefer a lighter weight protocol, hijacking all that traffic is taxing! On the other hand, if you're in the middle for presumably legitimate reasons, you have a responsibility to protect those connections. On the other hand, a malicious man-in-the-middle would want to go undetected, and probably does a better job of passing along the same protocol the client is using. It's time to replace those ancient proxies, and perhaps consider not restricting your users freedoms. A win-win.
- schoen 12y agoJeff Jarmoc had a great talk about this at BlackHat Europe: http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/ http://www.secureworks.com/cyber-threat-intelligence/threats... https://media.blackhat.com/bh-eu-12/Jarmoc/bh-eu-12-Jarmoc-SSL_TLS_Interception-Slides.pdf https://media.blackhat.com/bh-eu-12/Jarmoc/bh-eu-12-Jarmoc-S... He described the risk of outsourcing cryptographic security to a proxy -- though he was more focused on the fact that the proxy might not be as cautious or as correct about validating certs as your client, rather than that the proxy might have a different ciphersuite policy than your client. But he does explicitly mention this risk, including the idea that the proxy may be using a weaker ciphersuite. (The example he gives is PFS, where your client and the server might both support PFS ciphersuites, but the proxy might not, so you don't actually get PFS.)
- voltagex_ 12y agoYep. Things like Bluecoat were vulnerable to reverse-heartbleed, even if the servers/clients behind them weren't.