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.
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.
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).
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 instead of https://example.com.
1) You can address it in Chrome with pinning [1]. Built in pins require that you be a significant site, but you can also set them with HTTP headers [2].
4) Yep, cookies must be marked secure. HSTS can also fix this my eliminating the insecure requests. Even with secure cookies (but without HSTS), a MITM can also set the cookie. (i.e. to log you in to their account before you hit 'send' and then to log you back into yours before you notice the problem.)
Cause in that case a man in the middle can just insert links to other domains (say, http://examp1e.com/myotherpage when I was serving a link to http://example.com/myotherpage) and still have the attack work. Like the GP said, only starting at an HTTPS page would solve this.
But you're the expert and I'm not, so what am I missing? :-)
as long as mint.com has HSTS and either the user has been there once before or it was hard coded into the browser as an HSTS domain then the browser will never visit http://mint.com, it will immediately go to https://mint.com
EDIT: and well it doesn't seem that mint.com even has HSTS enabled... so bad example :P
How have I never seen convergence? I've been bitching about the weaknesses in the CA system for years, and totally missed that someone has done something about it.
Expanding on 1) you can also play man in the middle, decrypt and resign traffic with your own faked CA. If you ever have access to the users' machine you can install your faked CA as trusted and could have done it long in advance (eg via trojans/viruses).
When I was working on WAN optimizers I actually did this during research. All the various sites I visited still proudly told me how they were "Verisign Trusted" and even clicking on "Verify" links would tell me how verified and correct it was.
The UI in the browsers tries hard, but in reality users want to access the site and they will hit OK to get there. convergence is nice (if you run Firefox) but it is of significantly less help when using corporate/intranet sites.
It's not a "faked CA", it's a perfectly legitimate "internal CA" you created.
Of course you may be using it to impersonate external websites to your internal users, but the circumstances under which that may be an OK thing to do is a policy question that's still evolving.
I was working on WAN optimisers - ie something that would be sold to customers. With WAN optimizers you would typically put one in a branch office and one at headquarters. The boxes would then compress traffic between them. Typical compression ratios are 20x/95% - in other words your WAN link can now transfer about 20 times as much traffic. Additionally some traffic would be modified to do read ahead and write behind to provide latency improvements. An example of that was a user in Malaysia opening a Word document in San Jose, CA that was a 75kb file. Without a WAN optimiser it would take almost 3 minutes while with one it would take 5 seconds.
The problem with SSL traffic is that it is encrypted and doesn't repeat even for identical underlying data, and hence can't be compressed, nor can it be modified. This significantly hurts performance. To work well the SSL would need to be stripped off, the traffic compressed/read ahead etc, sent over the WAN and then SSL put back on. (The communication between the WAN optimisers was itself within IPSec or SSL.) SSL is designed so that you can't pull shenanigans like this, unless you have the private key of the servers, or resign the traffic with a different CA that can generate the needed certificates on the fly and are "trusted" by the user.
Many internal corporate services have moved to SSL and branch office users need to access them. Think about benefits systems, HR, documents, accounting, sales forecasting and tracking etc.
In the corporate world, it is used a lot for data loss prevention policies. It keeps employees from sending a file containing all their customers' social security numbers, addresses, and credit card to their home email account (or even one of them).
Convergence has a proxy system built in so you connect to notaries via other notaries. It's a rather rudimentary attempt at offering privacy to the user looking up the certificate. It (rightly or wrongly) works on the assumption that people running notaries wont collude.
Perspectives always leaks information about which sites you are visiting to all notaries.
Convergence leaks information about which sites you are visiting for the first time with the current key only if your bounce notary colludes with one other notary.
http://www.wired.com/threatlevel/2010/03/packet-forensics/
This could be addressed using 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/
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-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 instead of https://example.com.
http://fscked.org/blog/cookiemonster-core-logic-configuratio...