tls routes can be established via more than one hostname in the same wildcard domain
{
"localAddress":"tls#1",
"remoteAddress":"http2#1",
"extension": {"store":"client","hostname":"serverA.example.com","applicationProtocol":null}
}
{
"localAddress":"tls#1",
"remoteAddress":"http2#2",
"extension": {"store":"client","hostname":"serverB.example.com","applicationProtocol":null}
}If a client presents server name of serverA.example.com then it should follow the first route to http2#1 and if the client presents a server name of serverA.example.com then it should follow the second route to http2#2.
However, by specification http2 is permitted to send requests on the same connection based on hostnames authorized by the certificate presented by the server during TLS handshake.
In this case, if a *.example.com certificate is used to complete the handshake for serverA.example.com then the http2 client is free to reuse that connection for https://serverB.example.com/ requests.
Using the above routes, these https://serverB.example.com/ requests would fail as they are directed to the http2#1 route table instead of the http2#2 route table.
As a workaround, the routes can be updated such that tls#1 routes to http2#1 for both serverA.example.com and serverB.example.com.
Ideally, the scope of the certificate would be integrated with the route table in such a way that accidental routing issues can be more easily avoided.
tlsroutes can be established via more than onehostnamein the same wildcard domain{ "localAddress":"tls#1", "remoteAddress":"http2#1", "extension": {"store":"client","hostname":"serverA.example.com","applicationProtocol":null} } { "localAddress":"tls#1", "remoteAddress":"http2#2", "extension": {"store":"client","hostname":"serverB.example.com","applicationProtocol":null} }If a client presents server name of
serverA.example.comthen it should follow the first route tohttp2#1and if the client presents a server name ofserverA.example.comthen it should follow the second route tohttp2#2.However, by specification
http2is permitted to send requests on the same connection based on hostnames authorized by the certificate presented by the server during TLS handshake.In this case, if a
*.example.comcertificate is used to complete the handshake forserverA.example.comthen thehttp2client is free to reuse that connection forhttps://serverB.example.com/requests.Using the above routes, these
https://serverB.example.com/requests would fail as they are directed to thehttp2#1route table instead of thehttp2#2route table.As a workaround, the routes can be updated such that
tls#1routes tohttp2#1for bothserverA.example.comandserverB.example.com.Ideally, the scope of the certificate would be integrated with the route table in such a way that accidental routing issues can be more easily avoided.