Jered Floyd commented on TS-4468:
I don't see how this is relevant, as "don't use pristine_host_hdr with TLS" is
not an acceptable mitigation.
Anyway, I can't easily test that, as my production environment would not be
able to operate without the request "Host" headers -- I have multiple external
sites hosted by the same origin servers, and for ease of configuration and
management the origin servers are configured as if they were not behind a
I am confident that the problem can exist in situations that have
pristine_host_hdr disabled, though, as it is Apache which is returning the 400
Bad Request error. A configuration file like:
map https://example.com/ https://origin1.example.com/
map https://www.example.com/ https://origin2.example.com/
where origin1.example.com and origin2.example.com are the same IP address would
cause the same failure with match = ip. I agree that with pristine_host_hdr
disabled the the problem cannot occur with match = host or match = both.
> 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