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?
Firesheep, a day later
11–17 of 17 posts
Re: Firesheep, a day later
#12> 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/ This isn't an issue for the likes of Facebook, of course, but it is a problem for sites sm…
About 60% of client computers are running Windows XP, according to 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.
He's just saying that Facebook can deal with it much better than a small shop.
Re: Firesheep, a day later
#13Earlier quoted context omitted.
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.
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.
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
With only some complex Javascript hacks making it a possible solution:
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.
Re: Firesheep, a day later
#14Earlier quoted context omitted.
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.
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 With only some complex Javascript hacks making it a possible solution: http://www.peej.co.uk/articles/http-auth-with-html-forms.htm... Also, HTTP authentication i…
It's all been discussed by WHATWG/W3C and the conclusion was that cookies have too large momentum, Digest is not secure enough, and everyone should be using HTTPS.
http://www.w3.org/html/wg/tracker/issues/13?changelog
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-Nov...
Digest is vulnerable to MITM attacks. It's only secure against passive sniffing, but if you can sniff, you usually can also modify response, spoof DNS/ARP/base station. If everyone switched to Digest, it would be only a matter of time when someone writes Digest-stripping Firesheep2.
Re: Firesheep, a day later
#15Would a mixed (http + https) site with cookieless http traffic (from a different domain) be secure? Could something like this be included in the spec?
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).
Re: Firesheep, a day later
#16Would a mixed (http + https) site with cookieless http traffic (from a different domain) be secure? Could something like this be included in the spec?
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).
ahh ok, that's true. Hadn't thought of that. Is there a caching solution that supports https?
Re: Firesheep, a day later
#17I'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 whic…
[deleted]