6 ms·

>First, Firefox (and some others) are forcing TLS to use HTTP/2 : […]; that's a big deal breaker for a lot of people I would argue that not forcing SSL would b

by pilif 12y ago

>First, Firefox (and some others) are forcing TLS to use HTTP/2 : […]; that's a big deal breaker for a lot of people I would argue that not forcing SSL would be a big deal breaker for the whole protocol. If the experience we had with HTTP 1.1 pipelining or more recently with WebSockets is any indication then not using SSL would mean that HTTP/2 can't be reliably used anywhere because proxy servers and security (theater) products would be either breaking the Upgrade:-handshake or they would pretend to support it and then still fuck it up. SSL works because you get guaranteed peer-to-peer connectivity without dubious software from the late 90ies intercepting your request trying to make sense of the new protocol.

icebraining 12y ago
You'll still have those, they just do SSL MITM with a custom cert installed in the browser.
- pilif 12y ago
  Yes. But that's happening on a much smaller scale (HTTP interception is ubiquitous) and as certificate pinning is happening in browsers and applications, this is going down even more.
michaelt 12y ago
Unfortunately it seems like the plan is to support "opportunistic encryption", aka self-signed certificates, which can be trivially generated for MITM attacks. I doubt self-signed certificates will stop proxy servers, broken security products, and Verizon and AT&T doing MITM to inject UIDH tracking cookies.
- ithkuil 12y ago
  Technically they can do it, but if they will start doing it just to support HTTP/2 then at least they'll build their hacks with the knowledge of the HTTP/2 protocol. Self-signed certificates sound better than just plain text for compatibility reasons. The user agent shouldn't give any indication to the end user that the connection is secure though.
- BillinghamJ 12y ago
  The idea is to allow any certificate, but utilise DNSSEC to verify that it is legitimate. If the necessary records are missing, or DNSSEC isn't set up, self-signed certs would not be accepted - as per now. http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Nam...

by pilif 12y ago

icebraining 12y ago

You'll still have those, they just do SSL MITM with a custom cert installed in the browser.

pilif 12y ago
Yes. But that's happening on a much smaller scale (HTTP interception is ubiquitous) and as certificate pinning is happening in browsers and applications, this is going down even more.

michaelt 12y ago

Unfortunately it seems like the plan is to support "opportunistic encryption", aka self-signed certificates, which can be trivially generated for MITM attacks. I doubt self-signed certificates will stop proxy servers, broken security products, and Verizon and AT&T doing MITM to inject UIDH tracking cookies.

ithkuil 12y ago
Technically they can do it, but if they will start doing it just to support HTTP/2 then at least they'll build their hacks with the knowledge of the HTTP/2 protocol. Self-signed certificates sound better than just plain text for compatibility reasons. The user agent shouldn't give any indication to the end user that the connection is secure though.
BillinghamJ 12y ago
The idea is to allow any certificate, but utilise DNSSEC to verify that it is legitimate. If the necessary records are missing, or DNSSEC isn't set up, self-signed certs would not be accepted - as per now. http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Nam...