If Tiger gets a non-proxy request for a path it doesn't have a reverse proxy route (or other configuration) for, it goes into an infinite loop trying to handle the request. It does not close the connection, and the infinite loop continues if the client closes it, endlessly consuming resources and filling the log.
This allows for effective denial of service attacks on standalone instances, including unintentionally (e.g. from a typo in a test case). The reason I'm writing this as an issue here (and not via the security process) is that Tiger should be used only for test systems.
Found in 3.0.1 and 2.3.2, I haven't checked other versions. The log excerpt below is from 3.0.1.
Expected behavior
I'd expect Tiger to return a 404 error when a client requests a URL that isn't available.
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
Make a request to the proxy port with a path where Tiger doesn't have a proxy route (or other configured response).
proxy route (or other configuration) for, it goes into an infinite
$ curl -v --insecure --http1.1 https://localhost:9090/test/doesnotexist
* Trying 127.0.0.1:9090...
* Connected to localhost (127.0.0.1) port 9090 (#0)
* ALPN: offers 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 http/1.1
* Server certificate:
* subject: CN=localhost; O=Gematik; L=Berlin; ST=Berlin; C=DE
* start date: Mar 29 17:28:59 2024 GMT
* expire date: Apr 30 16:28:59 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/1.1
> GET /test/doesnotexist HTTP/1.1
> Host: localhost:9090
> User-Agent: curl/7.88.1
> Accept: */*
>
^C
Result in the Tiger log (repeated infinitely):
2024-04-08T18:27:32.300+02:00 INFO 12977 --- [orkerEventLoop4] o.b.jsse.provider.ProvTlsServer : [server #127 @6e8e74a1] accepting connection from (unknown):(unknown)
2024-04-08T18:27:32.305+02:00 INFO 12977 --- [orkerEventLoop4] o.b.jsse.provider.ProvTlsServer : [server #127 @6e8e74a1] established connection with (unknown):(unknown)
2024-04-08T18:27:32.307+02:00 INFO 12977 --- [orkerEventLoop4] d.g.t.t.p.h.AbstractTigerRouteCallback : Received HTTPS GET /test/doesnotexist User-Agent: 'curl/7.88.1' Request-Length: 0 bytes => localhost:9090
With HTTP instead of HTTPS the TLS provider lines are absent naturally, but the general behavior is the same.