4 ms·
It may be counter-intuitive, but with the right cyphers, the crypto costs of SSL and SPDY are negligible.
by obtu 14y ago
It may be counter-intuitive, but with the right cyphers, the crypto costs of SSL and SPDY are negligible.
- phkamp 14y agoNo, 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.
- obtu 14y agoI 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.
- comex 14y ago> 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.
- mcbridematt 14y agoWhat 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)
- obtu 14y agoI 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.