Hacker News new | past | comments | ask | show | jobs | submit login

Nice. A solid demonstration to show next time your webmaster doesn't want to set up SSL everywhere.

That said, the current cartel-like setup of certificate authorities (protection money and everything!) makes SSL annoying and expensive if you want the browser to not have a fit. Especially for small-scale projects. But there's really no excuse for larger sites.




HTTPS also needs distinct IP addresses for distinct hostnames, so that the HTTP handshake, in which the Host: header appears, is already protected by an encrypted channel. No more having multiple websites on one IP address.


There's TLS 1.1 SNI extension which adds vhosts.

Works — of course — everywhere except IE6/7XP.


That's an incredibly drastic change and I seriously doubt it can even be done with IP4.


SSL is bad for the environment because it requires far more server side hardware... Well, I'm only partially serious about the environment thing, the question is, how can internet companies make it commercially viable to use SSL for everything? The added hardware and power costs make each user way more expensive, possibly to the point where they may not actually be worth it.

An alternative is to bind the user's session to their IP address, but that isn't fool proof either because of NAT, DHCP and certain big ISPs that tend to change IPs on the fly.

What cost-effective solution would you suggest?


When Gmail switched on SSL for everyone earlier this year they added "no additional machines" (http://unblog.pidster.com/imperialviolet-overclocking-ssl).

Regarding IPs, there's a bigger issue here. People are used to being able to shut their laptop at home and open it back up at work without having to re-authenticate all their browser tabs. If you filter by IP this breaks. SSL requires no changes to user behavior.


What about pairing the auth token with a browser fingerprint? [1]

It would make it harder to troll an open network for random victims, and wouldn't annoy the user.

[1] Perhaps a hash based on something like this https://panopticlick.eff.org/


yep then you extend it to something as simple as having a second ID in localStorage or a flash cookie

then the next version of this plugin just spoofs all of those parameters as well

the only solution[1] is SSL and client certificates

[1] in the case of being on the same network


People bring up the Google stat, but you have to remember they have incredible engineering resources so they probably optimize in many features every day without adding additional machines. That doesn't mean every dude with a LAMP stack out there can turn on SSL and expect the same performance, just that it's possible with mongo manpower and talent to make it work. (Google doesn't even release the details of their web stack so comparing their stat is apples and oranges.)


How many web servers do you know of which are CPU bound, and not through massive code stupidity, and not I/O (in some manner - waiting on SQL, disk access, bandwidth)? Encryption can run while other threads are waiting for a response.

In general, it's a negligible cost; it adds a very minor delay compared to latency / transfer time, and uses CPU otherwise highly unlikely to be pegged. If you're pushing threading limits / CPU usage limits, you're probably inches from needing new hardware anyway, and SSL should be considered part of the cost of running a web server.


It's not completely negligible--even if CPU usage is negligible, it does add latency during SSL negotiation that might be unpreferable for some apps. The testing burden is a lot higher because one wrong link to http:// in CSS, HTML, or AJAX will cause big scary messages. And there is the IP address problem, you can't vhost as most people with Apache like to do.


interesting info in that url, thanks


That may have been true 10 years ago, but the overhead of SSL for CPU is almost nothing, and only a few ms of latency. Web applications are mostly IO and memory bound, anyways. We should be using SSL all the time, by default. There's no reason not to, at this point, aside from certificate authorities.


Require SSL on any request who's response sends a set-cookie http header. Leave it out for the non-sensitive request/responses.


You'd still be able to get the cookie when the client sends it bnack to the server on subsequent, non-SSL requests.

It's gotta be SSL all the time.


You can get SSL certificates for free for one domain, and they work with all browsers (except Opera, IIRC). Also, you can use Perspectives for Firefox, which I think is much better than the current system.


Off topic, but re: Perspectives. It allows your browser to compare notes with other nodes on the Internet ('network notaries') to ensure that everyone is seeing the same cert for a given website.

Looks like a great idea, but how do they prevent the man-in-the-middle from impersonating a network notary?


Notaries sign their responses, if I remember correctly.


Perspectives doesn't work in the latest version of Firefox. Its home page says a new version is coming, though:

http://www.cs.cmu.edu/~perspectives/firefox.html


I've had a bit of a look on Google, but I'm not 100% sure which provider you mean? Where can you get free SSL certificates that don't upset browsers?


Ah, I can't remember the name now... Rapidssl? That's probably it. Check historio.us, the ssl cert there is a free one (which is, sadly, why subdomains don't validate).

EDIT: I searched and it's actually http://cert.startcom.org/.


Check historio.us, the ssl cert there is a free one (which is, sadly, why subdomains don't validate).

AFAIK this is common to all certs (free or otherwise). You need a separate one for each subdomain (including www).


No, there are also wildcard certificates that match all subdomains, but are rather more expensive.


Wildcard certificates are available for USD $49.90 from StartSSL (http://www.startssl.com/?app=40), which is rather more expensive than free, but shouldn’t be a hardship.


The only downside to wildcard certs through StartSSL is that getting one requires high-resolution proof of personal identity, to be kept on file outside local jurisdiction (the company's based in Israel) until the cert's final renewal or revocation, plus seven years.

I admire their model of only charging for operations which require human intervention, like identity validation, but handing over that degree of documentation for that amount of time requires a lot of trust, not just of the company as it currently exists, but as it will exist in the far future.

If there was a way to validate organizations which wasn't layered on top of an earlier validation of an individual, or if their decentralized web-of-trust was usable for class 2/wildcard certs, I'd be a big fan.

As it is, there's no reason not to use Start for class 1, single-domain certs, for which the validation is automated and reasonable.


Wildcard certs don't match the underlying domain, though. See, for example, dropbox.com instead of www.dropbox.com; they've got a wildcard cert and it's not valid for dropbox.com.


Didn't know that, thanks.


Namecheap provides free ssl certificates for each domain you get through them.


The monkeysphere is also a good alternative if you use debian and gpg.

http://web.monkeysphere.info/


Right, and even the paid ones can be had for well under $30/yr nowadays, which is pretty trivial.


There are levels of pay for functionality, like subdomains, and being able to issue your own certificates.

For instance, from Verisign: a 1 year Microsoft code signing certificate starts at $499 [1]. A top-of-the-line (from their main pages) web certificate for a single server for one year: $1499 [2]

[1]: https://securitycenter.verisign.com/celp/enroll/selectOption... [2]: https://ssl-certificate-center.verisign.com/process/retail/p...

edit: it would figure the links don't work. Just go to www.verisign.com and those are a couple clicks from the front page.


Startcom offers free no-BS certificate signing, and their CA is on most modern browsers, I believe. I think they could be suitable for small scale projects.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: