[ 
https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510196#comment-15510196
 ] 

Alan M. Carroll commented on TS-4468:
-------------------------------------

If they are always the same, then why does it matter which is used as an 
argument to {{acquire_session}}? Although I see the point of what the patch is 
actually doing if on the origin server side the SNI and FQDN in the request are 
always the same. It may be only in the sticky session case this matters.

> 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)

Reply via email to