3 ms·

> First, Firefox (and some others) are forcing TLS to use HTTP/2 : https://wiki.mozilla.org/Networking/http2 https://wiki.mozilla.org/Networking/http2 ; that's

by glass- 12y ago

> First, Firefox (and some others) are forcing TLS to use HTTP/2 : https://wiki.mozilla.org/Networking/http2 https://wiki.mozilla.org/Networking/http2 ; that's a big deal breaker for a lot of people. Yes, encryption is all well and good. I'll all for it! But SSL certs either cost money, or you get them from companies that will want cash to revoke them for you if compromised Mozilla are currently planning/testing oportunistic encryption without certs over HTTP/2.0. Akamai is being used as the first test case. See: https://wiki.mozilla.org/Platform/2014-10-14#Necko_.28dougt.2Fjduell.29 https://wiki.mozilla.org/Platform/2014-10-14#Necko_.28dougt.... This is great as it is first step towards decoupling HTTP encryption from the CA cabal, and removing the barrier to encryption that you explicitly mentioned. Good job spreading FUD though.

byuu 12y ago
> Good job spreading FUD though. What you said sounds good. Maybe if they were more clear in their Wiki page, I wouldn't have been as concerned. "The current implementation is of draft-14 with compression-09 [august 6 nightly] Firefox will only be implementing HTTP/2 over TLS" "There is a separate, more experimental, build available that supports HTTP/2 draft-12 ... Sometimes this is known as opportunistic encryption." To an outsider like myself not following every step of the draft process, that reads to me like opportunistic encryption was dropped between draft-12 and draft-14. I am glad to hear that's apparently not the case. All the same, even self-signing isn't going to completely eliminate the overhead of needing to write or use TLS encryption libraries. It's going to complicate the requirements to create tools that talk over the web. You can argue that this is a good thing and everyone should be using libraries and you may be right. But some of us oldschool programmers like the simplicity of talking to things like serial to the unbelievable complexity of things like USB. There was something magic about HTTP where you could just open a socket, send it a header, recv the response, and you're done. Now, there are of course ways to make opportunistic encryption this easy. If our libc copies were to gain something like AF_INET_OTLS, and the network stack would do the encryption transparently on your send/recv requests, that would be great. But I'd be willing to bet money they're instead just going to say, "oh well that's on you, the application developer. Just use OpenSSL or LibreSSL."

by glass- 12y ago

byuu 12y ago

> Good job spreading FUD though. What you said sounds good. Maybe if they were more clear in their Wiki page, I wouldn't have been as concerned. "The current implementation is of draft-14 with compression-09 [august 6 nightly] Firefox will only be implementing HTTP/2 over TLS" "There is a separate, more experimental, build available that supports HTTP/2 draft-12 ... Sometimes this is known as opportunistic encryption." To an outsider like myself not following every step of the draft process, that reads to me like opportunistic encryption was dropped between draft-12 and draft-14. I am glad to hear that's apparently not the case. All the same, even self-signing isn't going to completely eliminate the overhead of needing to write or use TLS encryption libraries. It's going to complicate the requirements to create tools that talk over the web. You can argue that this is a good thing and everyone should be using libraries and you may be right. But some of us oldschool programmers like the simplicity of talking to things like serial to the unbelievable complexity of things like USB. There was something magic about HTTP where you could just open a socket, send it a header, recv the response, and you're done. Now, there are of course ways to make opportunistic encryption this easy. If our libc copies were to gain something like AF_INET_OTLS, and the network stack would do the encryption transparently on your send/recv requests, that would be great. But I'd be willing to bet money they're instead just going to say, "oh well that's on you, the application developer. Just use OpenSSL or LibreSSL."