4 ms·

(I work with HTTP/2 as part of my job) Downsides: * TLS requirements are complicated and hardly anyone knows how it works. * Several agents partially support

(I work with HTTP/2 as part of my job) Downsides: * TLS requirements are complicated and hardly anyone knows how it works. * Several agents partially support it, but the overlapping feature set is useless. An easy example is trailers. * More complex implementation. You can't look at the bytes without a program to decode the frames. * Flow control is hard. Upsides: * Too numerous to count. HTTP/2 fixes all the most painful parts of HTTP/1.1, and even provides backwards compatibility for HTTP/1.1 proxies. Aside from bugs (and lack of counterparty support), there is no reason to keep using HTTP/1.1.

newman314 8y ago
Can you elaborate more on the TLS complications as it pertains to HTTP/2?
- denormalfloat 8y ago
  HTTP/2 effectively forces TLS 1.2+, due to the limited cipher suites in the RFC, and browsers' restrictions. For the sake of argument, TLS is a requirement. To this end: * TLS requires ALPN. This would not be so bad, but so many clients don't provide a way to set the ALPN string. Java. In old versions of Java there is no way to do so, except to hack the JDK classpath. (Go users are feeling pretty smug right about about now, but the rest of the world suffers). * Setting up more advanced TLS is highly undocumented. Anything such as custom host domain validation, or IP SNI, or client side certificates, or encrypted keys results in people getting stuck. There is very little help available (how would you do this in nodejs, or ruby, or python, or C#, or PHP, etc.?) * Modern ciphersuites are not supported everywhere. For a long time, Java8 had non-hardware acceleration of AES-GCM, at a max speed of about 20MB/s per core. (on Intel, the max speed it closer to 3500MB/s). This makes it prohibitively expensive on languages/libraries that don't support it. (I'm looking at you, Android.) * How do you test TLS? LetsEncrypt rate limits cert creation. For the purpose of CI, there isn't an easy way to get trust on both sides. Unit test become a pain, so people just don't encrypt.
  - deathanatos 8y ago
    > due to the limited cipher suites in the RFC With this point, I just wanted to say, I have to agree fully. The requirements that get forced on folks just to adopt HTTP/2 are frustrating. As much as I also like PFS, tying HTTP/2 to it was silly, IMO. If the old ciphers are really that bad, I wish the vendors would just commit to that and put out a timeline for deprecating them. But this "they're only bad if you're using HTTP/2" to me seems like a nonsense carrot and stick. > client side certificates, or encrypted keys These aren't particular to HTTP/2 though; you can use or not use them equally the same w/ HTTP/1.x. (In particular, client certs aren't going to effect most people.) > How do you test TLS? LetsEncrypt rate limits cert creation. For the purpose of CI, there isn't an easy way to get trust on both sides. Unit test become a pain, so people just don't encrypt. Testing your certificate issuance stuff is orthogonal to HTTP/2, again, is it not? Outside of ensuring you get the appropriate key usage bits set on the certificate, I don't see why it shouldn't be very feasible, for testing HTTP/2, to simply mock out LE w/ a self-signed certificate.
  - ioquatix 8y ago
    From my POV: > TLS requires ALPN. Supported by recent versions of Ruby pretty well, but as you say, older versions, not so well. > Setting up more advanced TLS is highly undocumented. It was slightly tricky with Ruby but it provides the appropriate callbacks and the documentation is reasonable: https://github.com/socketry/falcon/blob/940c25f4d19e9ad900cee4827e771b89c3a3a82c/lib/falcon/hosts.rb#L107-L109 https://github.com/socketry/falcon/blob/940c25f4d19e9ad900ce... > How do you test TLS? I specifically solved this problem by using a self-signed local certificates and certificates store: https://github.com/socketry/async-rspec/blob/master/lib/async/rspec/ssl.rb https://github.com/socketry/async-rspec/blob/master/lib/asyn... That code makes appropriate contexts available for client and server in unit testing. Additionally I hacked this together: https://github.com/socketry/localhost https://github.com/socketry/localhost It generates local self-signed certificates which you can easily use with a web browser. It solves the "localhost development via https" problem.

newman314 8y ago

Can you elaborate more on the TLS complications as it pertains to HTTP/2?

denormalfloat 8y ago
HTTP/2 effectively forces TLS 1.2+, due to the limited cipher suites in the RFC, and browsers' restrictions. For the sake of argument, TLS is a requirement. To this end: * TLS requires ALPN. This would not be so bad, but so many clients don't provide a way to set the ALPN string. Java. In old versions of Java there is no way to do so, except to hack the JDK classpath. (Go users are feeling pretty smug right about about now, but the rest of the world suffers). * Setting up more advanced TLS is highly undocumented. Anything such as custom host domain validation, or IP SNI, or client side certificates, or encrypted keys results in people getting stuck. There is very little help available (how would you do this in nodejs, or ruby, or python, or C#, or PHP, etc.?) * Modern ciphersuites are not supported everywhere. For a long time, Java8 had non-hardware acceleration of AES-GCM, at a max speed of about 20MB/s per core. (on Intel, the max speed it closer to 3500MB/s). This makes it prohibitively expensive on languages/libraries that don't support it. (I'm looking at you, Android.) * How do you test TLS? LetsEncrypt rate limits cert creation. For the purpose of CI, there isn't an easy way to get trust on both sides. Unit test become a pain, so people just don't encrypt.
- deathanatos 8y ago
  > due to the limited cipher suites in the RFC With this point, I just wanted to say, I have to agree fully. The requirements that get forced on folks just to adopt HTTP/2 are frustrating. As much as I also like PFS, tying HTTP/2 to it was silly, IMO. If the old ciphers are really that bad, I wish the vendors would just commit to that and put out a timeline for deprecating them. But this "they're only bad if you're using HTTP/2" to me seems like a nonsense carrot and stick. > client side certificates, or encrypted keys These aren't particular to HTTP/2 though; you can use or not use them equally the same w/ HTTP/1.x. (In particular, client certs aren't going to effect most people.) > How do you test TLS? LetsEncrypt rate limits cert creation. For the purpose of CI, there isn't an easy way to get trust on both sides. Unit test become a pain, so people just don't encrypt. Testing your certificate issuance stuff is orthogonal to HTTP/2, again, is it not? Outside of ensuring you get the appropriate key usage bits set on the certificate, I don't see why it shouldn't be very feasible, for testing HTTP/2, to simply mock out LE w/ a self-signed certificate.
- ioquatix 8y ago
  From my POV: > TLS requires ALPN. Supported by recent versions of Ruby pretty well, but as you say, older versions, not so well. > Setting up more advanced TLS is highly undocumented. It was slightly tricky with Ruby but it provides the appropriate callbacks and the documentation is reasonable: https://github.com/socketry/falcon/blob/940c25f4d19e9ad900cee4827e771b89c3a3a82c/lib/falcon/hosts.rb#L107-L109 https://github.com/socketry/falcon/blob/940c25f4d19e9ad900ce... > How do you test TLS? I specifically solved this problem by using a self-signed local certificates and certificates store: https://github.com/socketry/async-rspec/blob/master/lib/async/rspec/ssl.rb https://github.com/socketry/async-rspec/blob/master/lib/asyn... That code makes appropriate contexts available for client and server in unit testing. Additionally I hacked this together: https://github.com/socketry/localhost https://github.com/socketry/localhost It generates local self-signed certificates which you can easily use with a web browser. It solves the "localhost development via https" problem.