5 ms·

That is fucking infuriating. What was their reasoning for removing it? http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html http://lists.w3.or

That is fucking infuriating. What was their reasoning for removing it? http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/... >To be clear - we will still define how to use HTTP/2.0 with http:// http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case -- browsing the open Web -- you'll need to use https:// https:// URIs and if you want to use the newest version of HTTP. Someone explain to me when "an informed choice" would ever come to the conclusion of, "Encryption? Not Necessary!"

warkdarrior 12y ago
> Someone explain to me when "an informed choice" would ever come to the conclusion of, "Encryption? Not Necessary!" I've been informed that encrypted web traffic costs money for the certificate and for additional server hardware. Thus I made the informed choice to use HTTP/2.0 without encryption.
- tracker1 12y ago
  They should have made the secure channel for encryption over HTTP/2 use DNSSEC, then you could roll your own keys, no CA authority needed (beyond DNS)
- nickysielicki 12y ago
  >encrypted web traffic costs money for the certificate and for additional server hardware 1.) You can make and self sign your own cert. As another poster pointed out, there's also distributed solutions. 2.) When we let standards that are going to be in-place for at least a decade be manipulated by the hardware costs at their inception, it's a bad standard.
brohee 12y ago
90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption. Encryption only really comes handy when confidential information and authentication credentials get exchanged. Now if you provide authentication by other means, and confidentiality of the traffic not important, plain text protocols make sense because it enables caching proxy. Typical use case: software updates distributed as signed packages. The information isn't very confidential, and using plain HTTP enables the usage of a caching local proxy.
- hurin 12y ago
  > 90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption. Authentication of the server is not sufficient, you also have to authenticate every message as having a valid checksum and signature. >Typical use case: software updates distributed as signed packages This is a specific use-case because the package checksums are verified before any of the code is executed (unlike injected javascript to webpages). Also the checksum is usually obtained from the package server, so if SSL is broken the checksum can be spoofed as well.
  - Pyxl101 12y ago
    > encryption is necessary for there to be any meaning to authentication. Could you elaborate on why that is the case? Do you perhaps mean cryptography rather than encryption?
    - hurin 12y ago
      > Do you perhaps mean "cryptography" rather than "encryption"? That's true the poster said authentication of the server, if you sign every message cryptographically, you'll be able to detect message tampering. I should edit that.
  - brohee 12y ago
    You know you can use MAC and a NULL cipher right? Even in IPsec there is a whole mode, AH where messages are authenticated but not encrypted...
- nickysielicki 12y ago
  >Encryption only really comes handy when confidential information and authentication credentials get exchanged. It's 2015 and we have quad-core processors in phones that are faster than my laptop. What reason can anyone possibly have to not at least strive to encrypt everything? When is it advantageous to not encrypt?
xg15 12y ago
Localhost connections? Watching your own traffic on a LAN for debugging purposes?
- spb 12y ago
  Exactly. HTTPS is for the public-facing Nginx proxy. No reason to require a cert to encrypt traffic on the internal bridge to the app.
  - nickysielicki 12y ago
    No reason? https://plus.google.com/+BrandonDowney/posts/SfYy8xbDWGG https://plus.google.com/+BrandonDowney/posts/SfYy8xbDWGG
- nickysielicki 12y ago
  The danger of allowing unencrypted traffic to dominate the web for another decade is not worth the convenience to developers.
spb 12y ago
Unencrypted HTTP/2 is for host-internal communication, ie. between app servers and public endpoints. Firefox and Chrome are both only going to support HTTPS for HTTP/2.

warkdarrior 12y ago

> Someone explain to me when "an informed choice" would ever come to the conclusion of, "Encryption? Not Necessary!" I've been informed that encrypted web traffic costs money for the certificate and for additional server hardware. Thus I made the informed choice to use HTTP/2.0 without encryption.

tracker1 12y ago
They should have made the secure channel for encryption over HTTP/2 use DNSSEC, then you could roll your own keys, no CA authority needed (beyond DNS)
nickysielicki 12y ago
>encrypted web traffic costs money for the certificate and for additional server hardware 1.) You can make and self sign your own cert. As another poster pointed out, there's also distributed solutions. 2.) When we let standards that are going to be in-place for at least a decade be manipulated by the hardware costs at their inception, it's a bad standard.

brohee 12y ago

90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption. Encryption only really comes handy when confidential information and authentication credentials get exchanged. Now if you provide authentication by other means, and confidentiality of the traffic not important, plain text protocols make sense because it enables caching proxy. Typical use case: software updates distributed as signed packages. The information isn't very confidential, and using plain HTTP enables the usage of a caching local proxy.

hurin 12y ago
> 90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption. Authentication of the server is not sufficient, you also have to authenticate every message as having a valid checksum and signature. >Typical use case: software updates distributed as signed packages This is a specific use-case because the package checksums are verified before any of the code is executed (unlike injected javascript to webpages). Also the checksum is usually obtained from the package server, so if SSL is broken the checksum can be spoofed as well.
- Pyxl101 12y ago
  > encryption is necessary for there to be any meaning to authentication. Could you elaborate on why that is the case? Do you perhaps mean cryptography rather than encryption?
  - hurin 12y ago
    > Do you perhaps mean "cryptography" rather than "encryption"? That's true the poster said authentication of the server, if you sign every message cryptographically, you'll be able to detect message tampering. I should edit that.
- brohee 12y ago
  You know you can use MAC and a NULL cipher right? Even in IPsec there is a whole mode, AH where messages are authenticated but not encrypted...
nickysielicki 12y ago
>Encryption only really comes handy when confidential information and authentication credentials get exchanged. It's 2015 and we have quad-core processors in phones that are faster than my laptop. What reason can anyone possibly have to not at least strive to encrypt everything? When is it advantageous to not encrypt?

xg15 12y ago

Localhost connections? Watching your own traffic on a LAN for debugging purposes?

spb 12y ago
Exactly. HTTPS is for the public-facing Nginx proxy. No reason to require a cert to encrypt traffic on the internal bridge to the app.
- nickysielicki 12y ago
  No reason? https://plus.google.com/+BrandonDowney/posts/SfYy8xbDWGG https://plus.google.com/+BrandonDowney/posts/SfYy8xbDWGG
nickysielicki 12y ago
The danger of allowing unencrypted traffic to dominate the web for another decade is not worth the convenience to developers.

spb 12y ago

Unencrypted HTTP/2 is for host-internal communication, ie. between app servers and public endpoints. Firefox and Chrome are both only going to support HTTPS for HTTP/2.