Proxy port offers HTTP/2, but doesn't support it

[airtower-luna]

Tiger 3.0.1 offers HTTP/2 in ALPN during TLS handshake, but then fails if the client sends an HTTP/2 request. 2.3.2 works. If Tiger isn't meant to support HTTP/2 that's fine, but then it shouldn't be offered in ALPN.

Reproducer

Start the Tiger proxy. No config needed, I'm just setting the proxy port so I don't need to look it up in the log.

$ java -jar tiger-standalone-proxy-3.0.1.jar --tigerProxy.proxyPort=9090

Connect to the proxy port over HTTPS. The actual URL doesn't matter, the bug occurs before any proxying would. I first encountered it with a URL for which the Tiger instance was configured as a reverse proxy.

$ curl -v --insecure https://localhost:9090/test
*   Trying 127.0.0.1:9090...
* Connected to localhost (127.0.0.1) port 9090 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (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, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=localhost; O=Gematik; L=Berlin; ST=Berlin; C=DE
*  start date: Mar 12 12:03:26 2024 GMT
*  expire date: Apr 13 12:03:26 2025 GMT
*  issuer: CN=Tiger-Proxy; O=Gematik; L=Berlin; ST=Berlin; C=DE
*  SSL certificate verify result: self-signed certificate in certificate chain (19), continuing anyway.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /test]
* h2h3 [:scheme: https]
* h2h3 [:authority: localhost:9090]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x55974ab24c80)
> GET /test HTTP/2
> Host: localhost:9090
> user-agent: curl/7.88.1
> accept: */*
> 
* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

Result in the Tiger log:

2024-03-22T13:03:34.793+01:00  INFO 44365 --- [orkerEventLoop3] o.b.jsse.provider.ProvTlsServer          : [server #2 @659d483e] accepting connection from (unknown):(unknown)
2024-03-22T13:03:34.797+01:00  INFO 44365 --- [orkerEventLoop3] o.b.jsse.provider.ProvTlsServer          : [server #2 @659d483e] established connection with (unknown):(unknown)
2024-03-22T13:03:34.798+01:00  INFO 44365 --- [orkerEventLoop3] d.g.t.t.m.netty.proxy.BinaryHandler      : received binary request: 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a00001204000000000000030000006400040200000000020000000000000408000000000001ff0001
2024-03-22T13:03:34.798+01:00  INFO 44365 --- [orkerEventLoop3] d.g.t.t.m.netty.proxy.BinaryHandler      : unknown message format, only HTTP requests are supported for mocking or HTTP & binary requests for proxying, but request is not being proxied and request is not valid HTTP, found request in binary: 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a00001204000000000000030000006400040200000000020000000000000408000000000001ff0001 in utf8 text: PRI * HTTP/2.0

SM

�
2024-03-22T13:03:34.799+01:00  INFO 44365 --- [orkerEventLoop3] o.b.jsse.provider.ProvTlsServer          : [server #2 @659d483e] disconnected from (unknown):(unknown)

Workaround

Force the client to use HTTP/1.1 only (for curl: --http1.1 option).

[Arkinator]

Could reproduce, ticket is opened (internal tracking number TGR-1329). Due to strained ressources I can't give an ETA right now.

[snlachelos]

Hello, Is there any timeplan, when the bug fix will be released ?

[Arkinator]

Hello!

This bug was inadvertently fixed in a rework of the TCP-Connect behavior. Version 3.1.3 should work without TLS, 3.1.4 will carry the fix for TLS. The analysis might be iffy due to https://github.com/gematik/app-Tiger/issues/5.

The error will stay the same (connection closed out-of-bounds, meaning TCP close (RST, ACK in this exact case)). This might be unexpected. Our reasoning is as follows: We duplicate a remote test-resource. In-bound errors (HTTP/HTTPS in this case) could be interepreted as originating from the remote server. Errors from the proxy can be hard to differentiate. We therefore opt to log the error and simply close the connection.

[Arkinator]

Reproducible, mirrored internally as TGR-1500, MR is already open, so we expect delivery with 3.1.4, which should ship within the next weeks, most likely sooner.

[airtower-luna]

Hi, were those comments possibly meant for #5? I don't see how closing the TCP connection on error would fix ALPN. :thinking:

[Arkinator]

you are of course correct, mixup on my end (while checking these two issues were very much interlocked). This one will stay open unfortunately, mirrored in TGR-1329. The inadvertent fix actually just corrected the ALPN behavior, the http/2 layer however is not done correctly. I will push the ticket up in the backlog.