[jira] [Updated] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

["Jered Floyd (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jered Floyd updated TS-4468:
----------------------------
    Summary: http.server_session_sharing.match = both unsafe with HTTPS  (was: http.server_session_sharing.match = both unsafe in reverse proxy mode)

Thinking about this further in the shower, I believe this is a general problem with SNI and not limited to reverse proxy mode (although will occur more commonly with it).

I believe that the HttpServerSession.hostname_hash should always be based on the SNI (or Request) Host when present, and this is the value that should be used for HttpServerSession::attach_hostname() and HttpSessionManager::acquire_session().

> 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
>            Reporter: Jered Floyd
>
> 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)