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

["Alan M. Carroll (JIRA)" <ji...@apache.org>]

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

Alan M. Carroll edited comment on TS-4468 at 6/3/16 2:22 AM:
-------------------------------------------------------------

For most users of Traffic Server the default behavior is not a problem and in fact is desirable as sharing sessions as much as possible is the goal. This is a very significant performance difference. If it is a problem, as in this case, sharing can be disabled entirely. But we should probably try to do better.

The fundamental issue is there are requests for host A and B. These are mapped to host Q. The session from ATS to Q uses the SNI name 'A' or 'B' depending on which request is the first to create the connection to Q. As noted this can be problematic if additional security checks are done to verify the SNI name against the host in the request. There is the language in [RFC6066|https://tools.ietf.org/html/rfc6066]

bq. 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.

On the other hand this propagation of the original SNI name may be desired in order to do additional or differential security checks. Therefore a single policy will be insufficient.

I've spent some time pondering this, though, and it seems to me the best option might be to enable remap rules to set the SNI name as well. This would preserve backwards compatibility so that deployments that depend on the propagation of the original SNI name continue to work. For the bug case here the remap rules that map A->Q and B->Q can also set the SNI name to Q.  It should be simple to say "set the SNI name in the outbound connection to the FQDN of the origin server" but it should probably be possible to set it to any value. I thought there was another bug outstanding on this precise point but I have been unable to find it.


was (Author: amc):
For most users of Traffic Server the default behavior is not a problem and in fact is desirable as sharing sessions as much as possible is the goal. This is a very significant performance difference. If it is a problem, as in this case, sharing can be disabled entirely. But we should probably try to do better.

The fundamental issue is there are requests for host A and B. These are mapped to host Q. The session from ATS to Q uses the SNI name 'A' or 'B' depending on which request is the first to create the connection to Q. As noted this can be problematic if additional security checks are done to verify the SNI name against the host in the request. There is the language in [RFC6066|https://tools.ietf.org/html/rfc6066]

bq. 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.

On the other hand this propagation of the original SNI name may be desired in order to do additional or differential security checks. Therefore a single policy will be insufficient.

I've spent some time pondering this, though, and it seems to me the best option might be to enable remap rules to set the SNI name as well. This would preserve backwards compatibility so that deployments that depend on the propagation of the original SNI name continue to work. For the bug case here the remap rules that map A->Q and B->Q can also set the SNI name to Q. 

> 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
>             Fix For: 7.0.0
>
>
> 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)