Just Tuesaday, I sent an email around the company discussing SSL vulnerabilities, how they impact our product, and ways we can mitigate that. I've pulled out t

Just Tuesaday, I sent an email around the company discussing SSL vulnerabilities, how they impact our product, and ways we can mitigate that. I've pulled out the parts specific to our product, but the rest may be interesting. I would love feedback on things I may have missed. FWIW, it doesn't instill great confidence in SSL, but it isn't completely horrible. ------------------------ 1. It is possible to pretend to be any site you want if you 1) find a sleezy CA (and they exist aplenty) or get the government involved and 2) can get between your browser and your final destination (like, for example, a wifi hotspot). There will be no way (reasonable) way to tell you aren't connected to whom you think you are. http://www.wired.com/threatlevel/2010/03/packet-forensics/ http://www.wired.com/threatlevel/2010/03/packet-forensics/ This could be addressed using http://convergence.io/ http://convergence.io/ 2. Way easier, but leaving some tell-tale signs you can find is to simply put yourself between your victim's browser and his server and convert all the links that come back to be insecure links that go through you. You then encrypt them as you pass them on to their final destination, while being able to see everything that happens. This is trivial to set up, but can be gotten around simply by using bookmarks that specify HTTPS. http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/ This won't go away until everybody is using 100% SSL and HTTP (unencrypted web traffic) is turned off in browsers. DOWNLOADING AND INSTALLING ANYTHING OVER AN UNSECURED NETWORK IS ALWAYS A BAD IDEA. 3. For the very determined, it is possible to determine the symmetric key a particular SSL session is using if you have some luck, some skill, and some time (about 30 minutes). http://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html http://www.schneier.com/blog/archives/2011/09/man-in-the-mid... This requires a protocol change to SSL. We've known about (theoretical) vulnerabilities for 10 years, yet most sites still run old versions of SSL. Given how slowly people like banks update infrastructure technology, I don't see this one going away for a long time. 4. If a site is improperly configured, it may allow an attacker to gain access to the cookie representing your secure session by making an insecure request. This is another class of vulnerabilities made possible by using untrusted networks. The misconfiguration allows the browser to send your (supposedly) secure cookies in an unsecured request simply by making any request (typically done by inserting JavaScript into an unsecured page you are browsing). It is possible to mark cookies as "secure only", but services will choose not do that so you don't lose your session if you type http://example.com http://example.com instead of https://example.com https://example.com. http://fscked.org/blog/cookiemonster-core-logic-configuration-and-readmes http://fscked.org/blog/cookiemonster-core-logic-configuratio...