Envoy not serving ALPN, http2 over https to web browsers

[cmaloney]

Envoy supports http2, and browsers request it via ALPN, but currently envoy as configured via contour doesn't offer any protocols via alpn so clients fall back to http/1.1 (sample below using curl).

Based on the envoy docs (https://www.envoyproxy.io/docs/envoy/latest/api-v2/sds.proto#commontlscontext) alpn_protocols should be set to h2,http/1.1. I'd probably say do it on all tls contexts by default, although probably would be most sane to also make a annotation to override

$curl -v --http2 https://app.example.com
* Rebuilt URL to: https://app.example.com/
*   Trying 1.2.3.4...
* TCP_NODELAY set
* Connected to app.example.com (1.2.3.4) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=app.example.com
*  start date: Jan 17 01:03:39 2018 GMT
*  expire date: Apr 17 01:03:39 2018 GMT
*  subjectAltName: host "app.example.com" matched cert's "app.example.com"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: app.example.com
> User-Agent: curl/7.57.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-type: text/html; charset=UTF-8
< date: Thu, 18 Jan 2018 23:51:10 GMT
< x-envoy-upstream-service-time: 0
< server: envoy
< transfer-encoding: chunked
< 

[davecheney]

Thanks for reporting this issue.

The https listeners are being configured with

fields: <
        key: "codec_type"
        value: <
          string_value: "auto"
        >
      >

I thought that this would enable http/2 over tls, but I wasn't correct.

Let me look into this, it shouldn't take much to fix.

https://www.envoyproxy.io/docs/envoy/latest/api-v2/sds.proto#commontlscontext

[davecheney]

Thanks for the fix, this looks like http/2 is being served properly

% httpstat https://gketest.davecheney.com/

Connected to 35.189.26.87:443

HTTP/2.0 200 OK
Server: envoy
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Content-Length: 12026
Content-Type: text/html; charset=utf-8
Date: Fri, 19 Jan 2018 01:16:36 GMT
X-Envoy-Upstream-Service-Time: 101
X-Powered-By: Flask
X-Processed-Time: 0

Body discarded

  DNS Lookup   TCP Connection   TLS Handshake   Server Processing   Content Transfer
[      2ms  |          19ms  |         89ms  |            122ms  |            19ms  ]
            |                |               |                   |                  |
   namelookup:2ms            |               |                   |                  |
                       connect:21ms          |                   |                  |
                                   pretransfer:111ms             |                  |
                                                     starttransfer:234ms            |
                                                                                total:254ms    

I think I might do a 0.3.1 in a week or so, and i've made a note to backport this to the release-0.3 branch.

[cmaloney]

Working here as well with the current master build

[davecheney]

Nice. I remember using httpstat to check h2 status a while back and being confused that it wasn't showing h2. However at the time TLS support was super new and getting all the pieces together to serve h2 over https was a bit of an ask so I forgot to verify. Thanks for your fix. Always welcome.

…

On 19 January 2018 at 12:26, Cody Maloney ***@***.***> wrote: Working here as well with the current master build — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#168 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA2BuHdHyAaE490hzlu_zRePyHgwpks5tL-9TgaJpZM4RjyEA> .