4 ms·

Hacker pokes third hole in secure sockets layer (SSL)

6 points by rabble 18y ago

timf 18y ago
According to the following quote, the problem seems avoidable if you have an https login page to begin with (happily something I was planning on): "Marlinspike said SSLstrip is able to work because the vast majority of sites that use SSL begin by showing visitors an unencrypted page"
- mooism2 18y ago
  If your users get to your https login page by following a link from your http front page, I think he can rewrite the link in the front page to be http, and the attack can still happen. As you say in your other comment, we need more details.
- gojomo 18y ago
  The user also has to navigate with careful intent to the proper HTTPS entry point. (Counting on the site's redirect mechanism to bounce you from any plain-HTTP URL to the HTTPS login page is just as vulnerable as a plain-HTTP login form.)
  - timf 18y ago
    That sucks. This URL will even be a top level domain for me for other reasons. Your point may still apply because when someone enters the domain name without typing "https", that's also a redirect (albeit a 301 redirect, I have no idea if that would make a difference). This is such a nasty prospect in general because such a tiny fraction of users would take time to type in URLs...
timf 18y ago
"the tool uses a proxy on the local area network that contains a valid SSL certificate, causing the browser to display an "https" in the address bar." Needing a local LAN is another restriction on the attack. I usually VPN to a server when on wireless, seems that will still be OK if I put high trust in that endpoint. Well, we need a lot more details here, obviously.
pasbesoin 18y ago
Would this appear in the certificate chain as displayed by the browser? It frustrates me that viewing the chain is such a drilldown exercise; in Firefox 3, they added a bit of up front information to the address bar (upon click on the favicon) but then made displaying the chain itself take an extra couple of clicks. Yes, I'm paranoid, but I take a frequent gander at the certificate chain of sites I'm using. Particularly for sites I use frequently, I'll notice if something looks hinky. As for http pages that request credentials (presumably transmitting these to an https URL), those piss me off to no end. To my mind, they break a basic security paradigm that had been promulgated for browser use in general: Check that the page is secure before submitting any sensitive information. Of course, I believe this only really works if you also have the https --> http transition warning enabled in the browser. I hardly see any browser installations that leave that enabled, any more. But I don't know a lot about that bit of browser functionality; maybe my understanding is wrong.
timf 18y ago
Interview with Moxie Marlinspike: http://news.ycombinator.com/item?id=488817 http://news.ycombinator.com/item?id=488817
timf 18y ago
This tool is now available: http://news.ycombinator.com/item?id=493912 http://news.ycombinator.com/item?id=493912

6 points by rabble 18y ago

timf 18y ago

According to the following quote, the problem seems avoidable if you have an https login page to begin with (happily something I was planning on): "Marlinspike said SSLstrip is able to work because the vast majority of sites that use SSL begin by showing visitors an unencrypted page"

mooism2 18y ago
If your users get to your https login page by following a link from your http front page, I think he can rewrite the link in the front page to be http, and the attack can still happen. As you say in your other comment, we need more details.
gojomo 18y ago
The user also has to navigate with careful intent to the proper HTTPS entry point. (Counting on the site's redirect mechanism to bounce you from any plain-HTTP URL to the HTTPS login page is just as vulnerable as a plain-HTTP login form.)
- timf 18y ago
  That sucks. This URL will even be a top level domain for me for other reasons. Your point may still apply because when someone enters the domain name without typing "https", that's also a redirect (albeit a 301 redirect, I have no idea if that would make a difference). This is such a nasty prospect in general because such a tiny fraction of users would take time to type in URLs...

timf 18y ago

"the tool uses a proxy on the local area network that contains a valid SSL certificate, causing the browser to display an "https" in the address bar." Needing a local LAN is another restriction on the attack. I usually VPN to a server when on wireless, seems that will still be OK if I put high trust in that endpoint. Well, we need a lot more details here, obviously.

pasbesoin 18y ago

Would this appear in the certificate chain as displayed by the browser? It frustrates me that viewing the chain is such a drilldown exercise; in Firefox 3, they added a bit of up front information to the address bar (upon click on the favicon) but then made displaying the chain itself take an extra couple of clicks. Yes, I'm paranoid, but I take a frequent gander at the certificate chain of sites I'm using. Particularly for sites I use frequently, I'll notice if something looks hinky. As for http pages that request credentials (presumably transmitting these to an https URL), those piss me off to no end. To my mind, they break a basic security paradigm that had been promulgated for browser use in general: Check that the page is secure before submitting any sensitive information. Of course, I believe this only really works if you also have the https --> http transition warning enabled in the browser. I hardly see any browser installations that leave that enabled, any more. But I don't know a lot about that bit of browser functionality; maybe my understanding is wrong.

timf 18y ago

Interview with Moxie Marlinspike: http://news.ycombinator.com/item?id=488817 http://news.ycombinator.com/item?id=488817

timf 18y ago

This tool is now available: http://news.ycombinator.com/item?id=493912 http://news.ycombinator.com/item?id=493912