5 ms·
Frankly many problems addressed by these proposals are not things that should be solved in a protocol like HTTP. Do you want every HTTP request to be slowed dow
by bifrost 14y ago
Frankly many problems addressed by these proposals are not things that should be solved in a protocol like HTTP.
Do you want every HTTP request to be slowed down with a crypto token exchange and verification? unlikely. In special cases you definately want it, but all the time? Absolutely not.
- obtu 14y agoIt 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.