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

Oknet Xu edited comment on TS-4468 at 9/21/16 2:01 PM:
-------------------------------------------------------

RFC 6066 conflic with RFC 7540:

{code}
RFC 6066

                                            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.

{code}


{code}
RFC 7540

9.1.1 Connection Reuse

Connections that are made to an origin server, either directly or through a 
tunnel created using the CONNECT method (Section 8.3), MAY be reused for 
requests with multiple different URI authority components. A connection can be 
reused as long as the origin server is authoritative (Section 10.1). For TCP 
connections without TLS, this depends on the host having resolved to the same 
IP address.

For https resources, connection reuse additionally depends on having a 
certificate that is valid for the host in the URI. The certificate presented by 
the server MUST satisfy any checks that the client would perform when forming a 
new TLS connection for the host in the URI.

An origin server might offer a certificate with multiple subjectAltName 
attributes or names with wildcards, one of which is valid for the authority in 
the URI. For example, a certificate with a subjectAltName of *.example.com 
might permit the use of the same connection for requests to URIs starting with 
https://a.example.com/ and https://b.example.com/.

{code}


RFC 7540, HTTP/2 allow connection reuse depends on having a certificate that is 
valid for the host in the URI.
But RFC 6066, Only allow connection reuse depends on having a same SNI for the 
host in the URI.

Depend on a research for Firefox, Chrome and Edge, Sarfri:
https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

- Firefox reuse connection by IP address.
- The chrome reuse connection by both.
- Edge & Sarfri reuse connection by hostname.



was (Author: oknet):
RFC 6066 conflic with RFC 7540:

{code}
RFC 6066

                                            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.

{code}


{code}
RFC 7540

9.1.1 Connection Reuse

Connections that are made to an origin server, either directly or through a 
tunnel created using the CONNECT method (Section 8.3), MAY be reused for 
requests with multiple different URI authority components. A connection can be 
reused as long as the origin server is authoritative (Section 10.1). For TCP 
connections without TLS, this depends on the host having resolved to the same 
IP address.

For https resources, connection reuse additionally depends on having a 
certificate that is valid for the host in the URI. The certificate presented by 
the server MUST satisfy any checks that the client would perform when forming a 
new TLS connection for the host in the URI.

An origin server might offer a certificate with multiple subjectAltName 
attributes or names with wildcards, one of which is valid for the authority in 
the URI. For example, a certificate with a subjectAltName of *.example.com 
might permit the use of the same connection for requests to URIs starting with 
https://a.example.com/ and https://b.example.com/.

{code}


RFC 7540, HTTP/2 allow connection reuse depends on having a certificate that is 
valid for the host in the URI.
But RFC 6066, Only allow connection reuse depends on having a same SNI for the 
host in the URI.


> 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