5 ms·

No, you don't need a HTTP request to upgrade: it's done as part of the TLS negotiation with ALPN. No extra round trips, and TLS 1.3 will probably go even faster

No, you don't need a HTTP request to upgrade: it's done as part of the TLS negotiation with ALPN. No extra round trips, and TLS 1.3 will probably go even faster. If you're not using TLS, despite things like the China QUANTUM attack on Baidu against Github, I don't know what to say to you, except most browsers already chose to refuse to speak HTTP/2 over cleartext, because using cleartext in 2015 is a bad idea in almost any scenario.

guilt 12y ago
If we don't support TLS, doesn't mean we don't care about E2E Encrypted Data, or E2H Encrypted Data, or Signed Data. I do understand how the system works - and I've seen ISPs issue fake real certificates (which CA issues Google's certificate?) and I think sometimes, you just have to do it deeper, and yourself, if you have to do it right.
- 001spartan 12y ago
  I hope I'm parsing this statement incorrectly, but it seems as though you're rolling your own solution to authentication and encryption, rather than using TLS. According to your organization's website, you're an IoT platform. That's terrifying, honestly. I hope I'm misinterpreting something.
  - AlyssaRowan 12y ago
    A Cortex-M0+ core - which is a really tiny microcontroller - can do TLS 1.2 just fine (using the AES-CCM AEAD instead of the AES-GCM AEAD helps somewhat, apparently: I've not tried to implement it myself, so I'm not clear precisely why, but it's probably GHASH). With enough work, an 8-bit class chip with a couple kilobytes of RAM could implement a constrained subset. If that's somehow still too heavy, I'm not sure how. I hope they can find a way to make TLS 1.3 work for their IoT scenarios: CHACHA20_POLY1305 and Curve25519 will also hopefully help, quite a lot. They're as small as they are fast.
    - guilt 12y ago
      For AEAD, We'd most likely look at ChaCha20(Poly1305(Text)+Text) and I think that's a great idea. :) We're definitely looking at non-NIST algorithms, we've just had enough of those.
- teraflop 12y ago
  If you don't support TLS, then browsers won't connect to you using HTTP/2 anyway, so it's a moot point.

guilt 12y ago

If we don't support TLS, doesn't mean we don't care about E2E Encrypted Data, or E2H Encrypted Data, or Signed Data. I do understand how the system works - and I've seen ISPs issue fake real certificates (which CA issues Google's certificate?) and I think sometimes, you just have to do it deeper, and yourself, if you have to do it right.

001spartan 12y ago
I hope I'm parsing this statement incorrectly, but it seems as though you're rolling your own solution to authentication and encryption, rather than using TLS. According to your organization's website, you're an IoT platform. That's terrifying, honestly. I hope I'm misinterpreting something.
- AlyssaRowan 12y ago
  A Cortex-M0+ core - which is a really tiny microcontroller - can do TLS 1.2 just fine (using the AES-CCM AEAD instead of the AES-GCM AEAD helps somewhat, apparently: I've not tried to implement it myself, so I'm not clear precisely why, but it's probably GHASH). With enough work, an 8-bit class chip with a couple kilobytes of RAM could implement a constrained subset. If that's somehow still too heavy, I'm not sure how. I hope they can find a way to make TLS 1.3 work for their IoT scenarios: CHACHA20_POLY1305 and Curve25519 will also hopefully help, quite a lot. They're as small as they are fast.
  - guilt 12y ago
    For AEAD, We'd most likely look at ChaCha20(Poly1305(Text)+Text) and I think that's a great idea. :) We're definitely looking at non-NIST algorithms, we've just had enough of those.
teraflop 12y ago
If you don't support TLS, then browsers won't connect to you using HTTP/2 anyway, so it's a moot point.