[
https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15506836#comment-15506836
]
Alan M. Carroll commented on TS-4468:
-------------------------------------
A key question would be, what should be done if the second request for a user
agent session is a different host? Should ATS send an error, or close the
connection? That would be quite different behavior than the current situation.
It might also be reasonable to allow changes of host that still match the
certificate used for the session. E.g. if the selected cert has the FQDNs
"yahoo.com" and "tumblr.com" it seems reasonable to let the user agent make
requests against both hosts, but not against "apple.com".
IIRC correctly I discussed this point with Susan while looking at Jered's
patch. If you check the patch, the session is not matched unless the
`server_request->get_host()` matches the SNI name of net connection to the
origin server.
One thing that's not clear is in what situations `t_state.current.server->name`
is not the same as `server_request.get_host`.
> 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.
> WORKAROUND:
> 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
> HTTPS.
> 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
(v6.3.4#6332)
