Hacker News new | ask | show | jobs
by bifrost 5080 days 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.
1 comments
obtu 5080 days ago
It may be counter-intuitive, but with the right cyphers, the crypto costs of SSL and SPDY are negligible.
link
phkamp 5080 days 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.

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.

link
comex 5079 days 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.

link
obtu 5080 days ago
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.
link
mcbridematt 5079 days ago
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)

link
obtu 5079 days ago
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.
link