5 ms·

Firesheep, a day later

77 points by cdine 16y ago

mooism2 16y ago
> In the past, an SSL service required a dedicated IP address. This isn’t true any more with the advent of Server Name Indication (RFC 3546) and improvements in TLS. If any of your users are using Internet Explorer on Windows XP, then this seems to still be true, alas - http://www.alexanderkiel.net/2008/04/22/status-of-tls-sni/ http://www.alexanderkiel.net/2008/04/22/status-of-tls-sni/ This isn't an issue for the likes of Facebook, of course, but it is a problem for sites small enough to be on shared hosting.
- mooism2 16y ago
  About 60% of client computers are running Windows XP, according to http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=10 http://marketshare.hitslink.com/operating-system-market-shar... Clearly they're not all running Internet Explorer, but equally clearly it's far too early to lock out clients that lack SNI.
  - calloc 16y ago
    Since all of the browsers on Windows XP use the Windows SChannel API none of them support SNI. That includes the beloved Google Chrome, FireFox, and Safari. (Not sure about Opera on Windows XP) http://en.wikipedia.org/wiki/Server_Name_Indication#Support http://en.wikipedia.org/wiki/Server_Name_Indication#Support That is unfortunately an issue that only Microsoft can rectify unless developers on the Windows platform want to take the time and effort to re-implement parts of the SChannel API.
    - acqq 16y ago
      > none of them support SNI. That includes (..) Google Chrome, FireFox, and Safari You're wrong about Firefox! I'm writing this from an XP box and I've just tested a SNI site with Firefox 3.6. It works with SNI just fine. > Not sure about Opera Opera also works with SNI.
      - calloc 16y ago
        My apologies regarding FireFox. I don't use FireFox and when I do it is from a Mac OS X machine. Either way Internet Explorer doesn't support it and as such it is still a no-go from a usability stand point since XP still has such a large market share.
  - TheSOB88 16y ago
    He's just saying that Facebook can deal with it much better than a small shop.
mjw 16y ago
I'd be interested to hear thoughts on HTTP digest auth as an alternative to full end-to-end encryption for avoiding these attacks. Personally I'm hopeful that Firesheep will be what it takes to persuade browser vendors (and the HTML5 crowd) that real usable support for HTML login forms based on HTTP digest authentication is a necessity. There are some pretty significant issues involved in rolling out full-on SSL which while not insurmountable do lead one to wonder if a more lightweight solution like HTTP digest auth might be sufficient for most non-security-critical cases. On this topic http://www.cgisecurity.com/2010/01/weaning-the-web-off-of-session-cookies-making-digest-authentication-viable.html http://www.cgisecurity.com/2010/01/weaning-the-web-off-of-se... is worth a read.
- jcromartie 16y ago
  Definitely. The hardest thing to sell, when it comes to regular HTTP digest auth, is the user interface. People (clients) truly prefer pretty and insecure over ugly and secure.
  - mjw 16y ago
    For sure. Hence the need for browser vendors to provide hooks - via new HTML5 form attributes, a Javascript API, or ideally both, to enable us to develop our own, usable HTML-based session login and logout forms with HTTP auth.
    - tiles 16y ago
      This is incredibly necessary for HTTP authentication to be useful, and bizarrely, has been given little to no attention over the years. There's a proposal for HTTP authentication in HTML dating all the way back to 1999: http://www.w3.org/TR/NOTE-authentform http://www.w3.org/TR/NOTE-authentform With only some complex Javascript hacks making it a possible solution: http://www.peej.co.uk/articles/http-auth-with-html-forms.html http://www.peej.co.uk/articles/http-auth-with-html-forms.htm... Also, HTTP authentication is a benefit to RESTful service design. Cookies have always been the wrong solution to this problem, having all web services to move to HTTPS feels like missing the point.
grandalf 16y ago
Would a mixed (http + https) site with cookieless http traffic (from a different domain) be secure? Could something like this be included in the spec?
- pornel 16y ago
  If you used cookies with HTTP-only and secure flags, then cookies alone should be safe, but the site wouldn't. Someone could sniff login forms via injected scripts (XSS = game over) and modify page's content via unprotected CSS and images (which aids phishing, clickjacking).
  - grandalf 16y ago
    ahh ok, that's true. Hadn't thought of that. Is there a caching solution that supports https?

77 points by cdine 16y ago

> In the past, an SSL service required a dedicated IP address. This isn’t true any more with the advent of Server Name Indication (RFC 3546) and improvements in TLS. If any of your users are using Internet Explorer on Windows XP, then this seems to still be true, alas - http://www.alexanderkiel.net/2008/04/22/status-of-tls-sni/ http://www.alexanderkiel.net/2008/04/22/status-of-tls-sni/ This isn't an issue for the likes of Facebook, of course, but it is a problem for sites small enough to be on shared hosting.

mooism2 16y ago
About 60% of client computers are running Windows XP, according to http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=10 http://marketshare.hitslink.com/operating-system-market-shar... Clearly they're not all running Internet Explorer, but equally clearly it's far too early to lock out clients that lack SNI.
- calloc 16y ago
  Since all of the browsers on Windows XP use the Windows SChannel API none of them support SNI. That includes the beloved Google Chrome, FireFox, and Safari. (Not sure about Opera on Windows XP) http://en.wikipedia.org/wiki/Server_Name_Indication#Support http://en.wikipedia.org/wiki/Server_Name_Indication#Support That is unfortunately an issue that only Microsoft can rectify unless developers on the Windows platform want to take the time and effort to re-implement parts of the SChannel API.
  - acqq 16y ago
    > none of them support SNI. That includes (..) Google Chrome, FireFox, and Safari You're wrong about Firefox! I'm writing this from an XP box and I've just tested a SNI site with Firefox 3.6. It works with SNI just fine. > Not sure about Opera Opera also works with SNI.
    - calloc 16y ago
      My apologies regarding FireFox. I don't use FireFox and when I do it is from a Mac OS X machine. Either way Internet Explorer doesn't support it and as such it is still a no-go from a usability stand point since XP still has such a large market share.
- TheSOB88 16y ago
  He's just saying that Facebook can deal with it much better than a small shop.

mjw 16y ago

I'd be interested to hear thoughts on HTTP digest auth as an alternative to full end-to-end encryption for avoiding these attacks. Personally I'm hopeful that Firesheep will be what it takes to persuade browser vendors (and the HTML5 crowd) that real usable support for HTML login forms based on HTTP digest authentication is a necessity. There are some pretty significant issues involved in rolling out full-on SSL which while not insurmountable do lead one to wonder if a more lightweight solution like HTTP digest auth might be sufficient for most non-security-critical cases. On this topic http://www.cgisecurity.com/2010/01/weaning-the-web-off-of-session-cookies-making-digest-authentication-viable.html http://www.cgisecurity.com/2010/01/weaning-the-web-off-of-se... is worth a read.

jcromartie 16y ago
Definitely. The hardest thing to sell, when it comes to regular HTTP digest auth, is the user interface. People (clients) truly prefer pretty and insecure over ugly and secure.
- mjw 16y ago
  For sure. Hence the need for browser vendors to provide hooks - via new HTML5 form attributes, a Javascript API, or ideally both, to enable us to develop our own, usable HTML-based session login and logout forms with HTTP auth.
  - tiles 16y ago
    This is incredibly necessary for HTTP authentication to be useful, and bizarrely, has been given little to no attention over the years. There's a proposal for HTTP authentication in HTML dating all the way back to 1999: http://www.w3.org/TR/NOTE-authentform http://www.w3.org/TR/NOTE-authentform With only some complex Javascript hacks making it a possible solution: http://www.peej.co.uk/articles/http-auth-with-html-forms.html http://www.peej.co.uk/articles/http-auth-with-html-forms.htm... Also, HTTP authentication is a benefit to RESTful service design. Cookies have always been the wrong solution to this problem, having all web services to move to HTTPS feels like missing the point.

grandalf 16y ago

Would a mixed (http + https) site with cookieless http traffic (from a different domain) be secure? Could something like this be included in the spec?

pornel 16y ago
If you used cookies with HTTP-only and secure flags, then cookies alone should be safe, but the site wouldn't. Someone could sniff login forms via injected scripts (XSS = game over) and modify page's content via unprotected CSS and images (which aids phishing, clickjacking).
- grandalf 16y ago
  ahh ok, that's true. Hadn't thought of that. Is there a caching solution that supports https?