EDIT: Session cookie needs to be set as "secure" and Strict-Transport-Security should be implemented in order to protect against certain attacks. End users can just add this HTTPS-Everywhere ruleset:
I've been using HTTPS-Everywhere for a reasonably long time now (a couple of years?) but this is actually the first time I've added a rule...so if anyone else falls into that boat: all you need to do is save the YCombinator.xml file (linked above, from Mike's GitHub) into the HTTPSEverywhereUserRules folder in your Firefox profile folder, then restart Firefox.
Hopefully that'll save someone else from having to look it up ;)
If you're on an unsecured wireless network (e.g. at a library) and you don't want someone to see your HN password when you log in.
(This just increases the incentive for sites to use HTTPS Everywhere, so they're not left out in the dark as to who is sending them traffic.)
Another useful tool is SSLScan, which for Hacker News shows that they are accepting of a very strange set of HTTPS cipher and MAC configurations.
SSLv2 should be turned off, as well as the majority of 40-bit and 56-bit ciphers. Their unusual preference of CAMELLIA-256-CBC is pretty amusing to me.
Prefered Server Cipher(s):
SSLv2 168 bits DES-CBC3-MD5
SSLv3 256 bits DHE-RSA-AES256-SHA
TLSv1 256 bits DHE-RSA-AES256-SHA
(I have other complaints about the SSLabs grades, but I'm not getting into it here).
Yea, I noticed it too when I checked this using Firefox and Chrome.
Certificate ------ 100
Protocol Support - 85
Key Exchange ----- 80
Cipher Strength -- 90
For non- HTTPS- nerds: STS resolves the problem where your first contact with a site is via (insecure) HTTP, and a MITM makes all subsequent contacts lie to you about whether HTTPS is available. Since we've lasted many years without even having HTTPS, I think we can all just look at the address bar carefully instead.
I'd say that it is worth going out of your way for. If you're implementing HTTPS, it is only slightly more effort to implement STS as well. And it's definitely worth adding the secure flag to the cookie as well.
STS: Nice to have. Most installed browsers don't even support it.
Cookie Secure flag: Must have. Every modern browser supports it to some extent.
You're entitled to your opinion about this stuff, but know that my opinion has been hardened by many many years doing appsec for financial services companies. I would not doc a company for not having STS†, unless I was doing design/best practices review. I would doc anybody for not setting the secure flag on cookies for an HTTPS site.
† (ie: if you ask me to doc stuff like STS and Clickjacking)
It takes very little effort to implement STS, and there are significant tangible benefits from doing so. For this reason alone, I would recommend that all HTTPS sites use it. I acknowledge that using the "secure" flag with cookies provides a bigger benefit though.
HN doesn't have a framebuster either, but you didn't call them out on that. The security nerds we work with are far more likely to call us out for not hyperventilating about clickjacking than about HSTS, which, again, is not widely supported in the field to begin with.
There are actual apparent problems with HN's HTTPS; it will for instance happily do SSLv2 with 40 bit RC4. Let's advocate for those fixes first.
No modern browser is going to choose such a weak cipher, but because SSLv2 is enabled, a MITM can force it. The same MITM who can abuse the lack of STS.
I think you've gone on tilt on this issue, so, feel free to the last word.
All modern browsers are susceptible to the other MITM attack I described though. Unless the website uses STS.
EDIT: It's worth noting that anybody using IE7+, FF2+, Opera, Chrome or Safari aren't affected be the weak ciphers, or by the existence of SSLv2, as their browsers will not negotiate a weak SSL connection. They are all affected by the lack of STS though.
And when there's a solution that is trivial to implement, and can fix the issue for two existing major modern browsers (probably more to come), it might not be a completely crazy idea to go ahead and implement it.
P.S. Thank you for graciously gifting me the final word
And that is it. Your browser now prefers to use https for your web site. That was really not that much trouble, was it?
Also, https is not just for banking. I like it when people cannot see what I am doing online. Whether that is online banking, doing a google search or writing a posting on hackernews.
Strict-Transport-Security: max-age=604800, includeSubDomains
manila:pieter$ curl -I http://news.ycombinator.com
curl: (52) Empty reply from server
manila:pieter$ curl -I https://news.ycombinator.com
HTTP/1.1 200 OK
Date: Sun, 21 Aug 2011 15:09:27 GMT
Content-Type: text/html; charset=utf-8
Edit: The CN in the cert is news.ycombinator.com, so it's unlikely my explanation is the cause (but still could be).
Unfortunately, there's no guarantee that an HTTPS site is identical to the corresponding HTTP site. In most web servers, each one has its own configuration, so it's best to visit SSL sites only when you've been explicitly directed to do so.
If someone logs in on a wifi hotspot, their password is easily visibile to others. And voilà, suddenly you have access to someone's email, facebook account, etc.
By not using a VPN you're leaving yourself open to all manner of attacks (take for example the recent iOS SSL Cert validation issues as an example, but also consider the fact that an attacker could inject malicious content to attack your system over any HTTP traffic - or invalid HTTPS traffic if you make the connection).
At the very least you should use an SSH tunnel or some form of transport to protect all of your outbound traffic when in a hostile environment.
[Shameless Plug] I quit my day job earlier this year and started building https://www.getcloak.com/ with two friends. We're caffeine addicts who dog-food our product; that's why we work out of coffee shops here in Seattle. (You can find our office by following @seafreemob on Twitter. ;-)
• If you are generating your content in a dynamic creation system, the encryption overhead of SSL is not going to matter.
• SSL initial session latency is highly variable based on packet round trip time of the user. Some people will be irritated, other's can't tell the difference.†
† I suppose there is room in the world for a CDN-like entity that places anycasted SSL entry points in strategic locations (or topology sensitive DNS lookups), then uses a zero-turnaround at startup encryption protocol back to the "real" servers. (Say, HTTP over a VPN or something more clever, after all you are the client and the server, life is easy). You'd even beat straight HTTP since by keeping alive the HTTP link to the real servers you'd save the TCP SYN turnaround. 👍
‡ Unrelated: The unicode committee has lost their mind. OS X Lion users will be seeing a flesh colored thumbs up symbol at the end of the previous paragraph. I suppose now that PILE_OF_POO and NAIL_POLISH are taken care of the committee will add everyone's avatars from all systems.
All I see is EOT symbol
That was already possible using HN's OpenID support and a secure provider.
Not actually sure what your point is here.
By the way, I'm not claiming that enabling HTTPS is wrong, I'm giving potential disadvantages. It's the website admins' job to weight those against the advantages and decide whether it's the right thing to do or not.
https gives you more than just encryption.
on the client side, I don't think you can really feel the latency. is measurable, of course, but i don't think you can feel it.
That doesn't seem to be the general opinion here: http://news.ycombinator.com/item?id=2565694
It adds half a second or more to initial page load times. For doing any sort of marketing where potential customers are arriving at your landing page, that's huge.
Admittedly this is a poor comparison vs a huge site, but then you'll probably find the server processing time is your greater foe.
I am sorry if it sounded like I was talking about any website in general. That is not the case.