Oknet Xu commented on TS-4468:
RFC 6066 conflic with RFC 7540:
If the server_name is
established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the application layer.
9.1.1 Connection Reuse
Connections that are made to an origin server, either directly or through a
tunnel created using the CONNECT method (Section 8.3), MAY be reused for
requests with multiple different URI authority components. A connection can be
reused as long as the origin server is authoritative (Section 10.1). For TCP
connections without TLS, this depends on the host having resolved to the same
For https resources, connection reuse additionally depends on having a
certificate that is valid for the host in the URI. The certificate presented by
the server MUST satisfy any checks that the client would perform when forming a
new TLS connection for the host in the URI.
An origin server might offer a certificate with multiple subjectAltName
attributes or names with wildcards, one of which is valid for the authority in
the URI. For example, a certificate with a subjectAltName of *.example.com
might permit the use of the same connection for requests to URIs starting with
https://a.example.com/ and https://b.example.com/.
RFC 7540, HTTP/2 allow connection reuse depends on having a certificate that is
valid for the host in the URI.
But RFC 6066, Only allow connection reuse depends on having a same SNI for the
host in the URI.
> http.server_session_sharing.match = both unsafe with HTTPS
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, SSL
> Affects Versions: 6.1.1
> Reporter: Jered Floyd
> Assignee: Susan Hinrichs
> Fix For: 7.0.0
> Attachments: TS-4468.patch
> Time Spent: 3h 10m
> Remaining Estimate: 0h
> proxy.config.http.server_session_sharing.match has a default value of "both",
> which compares IP address, port, and FQDN when determining whether a
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a
> reverse proxy. The compared value is the origin server FQDN after mapping,
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS
> will attempt to reuse a connection that may have an SNI Host that does not
> match the HTTP Host. With Apache 2.4 origin servers this results in 400 Bad
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see
> 400 Bad Request responses intermittently.
> proxy.config.http.server_session_sharing.match should have a default value of
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is
> 3) Compare target host (SNI host) rather than replacement host when
> determining if reuse of server session is allowed (when
> server_session_sharing.match is set to "host" or "both").
This message was sent by Atlassian JIRA