Hacker News Reader

Comment by obtu | Hacker News Reader

It may be counter-intuitive, but with the right cyphers, the crypto costs of SSL and SPDY are negligible.

No, they are not. For one thing you have to terminate all your SSL on your loadbalancer in order to distribute the traffic. That makes SPDY a no-go for web-hotels/web-hosting where each customer has their own certificate.

Second, there are perfectly valid legally mandated circumstances which forbid end-to-end privacy, from children in schools to inmates in jail and patients in psych. hospitals, not to mention corporate firewalls and the monster that looks out for classified docs not leaking out of CIA.

I was talking about performance, but: SNI addresses your first point. For the second point, whoever needs to enforce snooping already has to deal with SSL.

> No, they are not. For one thing you have to terminate all your SSL on your loadbalancer in order to distribute the traffic. That makes SPDY a no-go for web-hotels/web-hosting where each customer has their own certificate.

That's what SNI is for.

> Second, there are perfectly valid legally mandated circumstances which forbid end-to-end privacy

Then install spyware on the user's computer, or add a trusted SSL key and mitm all the things.

What about embedded devices/the 'internet of things'? Should I have to add a (costly) crypto chip to my microcontroller just to have a HTTP/web interface? Or a large SSL stack?

(HTTP 1 would be sufficient for these use cases for a long time to come, but resource considerations should factor into these standards discussions)

I would keep HTTP/1.1, as you suggest. SSL servers on cheap (sub-Raspberry Pi) embedded devices are a no-go for another reason: it is hard to keep the certificate unique and private. Embedded devices with smart cards might be workable.

Reply on news.ycombinator.com