I was at a conference recently and saw somebody start Firesheep -- HN profiles showed up. So the choices were: use HN on open wifi but risk having your session stolen, don't use HN, or connect to a VPN. The VPN is probably the smartest thing to do on an open wifi network, but it's nice to know that HN is now safe to use without it.
If you're going to a conference and you're using wifi there, please use a VPN. If you're going to a coffee shop and using wifi, if at all possible use a VPN.
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.
I saw Firesheep in active use at the TechCrunch Disrupt NYC hackathon earlier this year. Yikes. No solution is perfect, but VPNs seem like the way to go for now.
[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. ;-)
Thanks for the plug, finally a VPN solution that seems good (i.e. automatic, good pricing model etc.). That said, please sent an invite (my email stats jtl...)
Many people, myself included, would see that as a good thing. Not an "unfortunate" thing. Limiting HTTPS to logins only allows session hijacking. Session hijacking is a serious problem.
• 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.
Using OpenID (with a secure provider) to login to HN prevents the stealing of login credentials and was possible even without HN supporting HTTPS. I don't see what's strange about this.
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.
Also, if you can hijack the http, you can link to a phishing site which prompts users for their OpenID provider (typically their google account) credentials. Maybe they would notice that the domain name of the phishing site (say googleopenid.com, which is available) is fishy ...
I meant why the fact there was a way to do it already actually related to the debate overmuch. This protects people who just use a bog-standard HN account, and further secures all users when actually on the site regardless of login method.
On the server side, it is ycombinator's decision if they can handle the additional cpu cycles. i believe they can, or else they wouldn't have enabled it.
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.
And high(er) latency on HN would be a problem because ... ? It's such a highly interactive website? There are billions of high quality images to be loaded? Hundreds of ajax calls going back and forth every second?
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.
Not necessarily so noticable. I've been running my personal site with https and the effect is fairly minor on the whole in terms of load times. Not zero, but low enough that your average user on the other side of the Atlantic wouldn't notice much of a difference to normal.
Admittedly this is a poor comparison vs a huge site, but then you'll probably find the server processing time is your greater foe.
