[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15515134#comment-15515134 ] Alan M. Carroll commented on TS-4468: - Oknet, I think you're also missing the point that in many cases the communication with the origin is not via TLS and not only is there not an SNI name to check but in such cases using the host in the request would prevent desirable session sharing. In fact the ability to split the check (that is, check FQDN and IP address independently) was put in to support that situation. Using the server name and then verifying SNI matching lets this continue to work in the non-TLS case. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513834#comment-15513834 ] Oknet Xu commented on TS-4468: -- For HTTP session reuse and upon my suggestion: release/acquire server session upon server_request->get_host() if proxy.config.url_remap.pristine_host_hdr is false: - t_state.current.server->name == server_request->get_host() == "origin.example.com" - no difference if proxy.config.url_remap.pristine_host_hdr is true: - t_state.current.server->name == "origin.example.com" - server_request->get_host() == "example.com" or "www.example.com" - reduces the value of server session reuse (but without any negative effects) With the option enabled: - The results of match=ip and match=ip+FQDN are almost the same. - The "match=ip" already meet our requirements. Because the FQDN is resolved to multiple IPs and the contents on each IP are the same. - The result of match=ip+Host more accurate/less than the result of match=ip+FQDN. For Http session reuse: - match=ip is enough <==> match = IP - match=FQDN is acceptable and improve the value while multiple IPs for a FQDN <==> match = HOST - match=ip+FQDN is almost the same as match=ip <==> match = BOTH - match=Host is acceptable and improve the value but lower than FQDN - match=ip+Host is acceptable but reduces the value of reuse For Https session reuse: - match=ip is unacceptable, againest RFC 6066 - match=FQDN is unacceptable, againest RFC 6066 - match=ip+FQDN is unacceptable, againest RFC 6066 - match=Host(SNI) is acceptable and improve the value - match=ip+Host(SNI) is required <==> match = IP - match=FQDN+Host(SNI) is acceptable and no difference with ip+Host <==> match = HOST - match=ip+FQDN+Host(SNI) is acceptable and no difference with ip+Host <==> match = BOTH Your patch implement the addtionnal SNI match for SSLNetVC. Depend on the analysis above, in order to get max value of reuse: - to reuse a server session connect to parent proxy, we prefer match=ip - to reuse a server session that reverse proxy to http origin server, we prefer match=ip - to reuse a server session that reverse proxy to https origin server, we prefer match=ip+sni(with the patch) - to reuse a server session that forward proxy to http origin server, we prefer match=host - to reuse a server session that forward proxy to https origin server, we prefer match=host+sni(with the patch) Now, ATS default setting is match=both that is middle solution(not bad but not the best). Thanks for your explaination and finally I'm totally understand the reuse. However, I will reserve my opinion about match=IP+FQDN <==> match=BOTH. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513645#comment-15513645 ] Jered Floyd commented on TS-4468: - I don't see how this is relevant, as "don't use pristine_host_hdr with TLS" is not an acceptable mitigation. Anyway, I can't easily test that, as my production environment would not be able to operate without the request "Host" headers -- I have multiple external sites hosted by the same origin servers, and for ease of configuration and management the origin servers are configured as if they were not behind a reverse proxy. I am confident that the problem can exist in situations that have pristine_host_hdr disabled, though, as it is Apache which is returning the 400 Bad Request error. A configuration file like: map https://example.com/ https://origin1.example.com/ map https://www.example.com/ https://origin2.example.com/ where origin1.example.com and origin2.example.com are the same IP address would cause the same failure with match = ip. I agree that with pristine_host_hdr disabled the the problem cannot occur with match = host or match = both. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513474#comment-15513474 ] Oknet Xu commented on TS-4468: -- Could you please do a test for the issue with the option disabled ? > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513178#comment-15513178 ] Jered Floyd commented on TS-4468: - I believe I considered this approach and ruled it out -- it's been a while and I'm just waking up so let me see if I can reconstruct why... I think the disadvantage with matching session reuse on the "Host" header (rather than the origin server FQDN) is that is reduces the value of server session reuse for non-SSL connections. That is, the semantics for your approach are fine for HTTPS but don't allow valid session reuse for HTTP when multiple targets map to the same origin server. So, to retain current HTTP session reuse behavior, you would need to index HTTP sessions based on origin server name while changing HTTPS sessions to be indexed on the Host header. Now, I don't know how much HTTP session reuse goes on in the scenario I describe (multiple targets on the same origin server) so maybe changing the index to be on "host" rather than "server" is just fine, but it's a more extreme change to the semantics of proxy.config.http.server_session_sharing.match = "host" or "both". > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513153#comment-15513153 ] Jered Floyd commented on TS-4468: - I do. I think the problem can occur with the option disabled, but it seems less likely (you would have to call the same origin server by different names in the records.config). > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513105#comment-15513105 ] Oknet Xu commented on TS-4468: -- By review the codes, the key point is "proxy.config.url_remap.pristine_host_hdr". if proxy.config.url_remap.pristine_host_hdr is false: t_state.current.server->name == server_request->get_host() == "origin.example.com" if proxy.config.url_remap.pristine_host_hdr is true: t_state.current.server->name == "origin.example.com" server_request->get_host() == "example.com" or "www.example.com" ATS always : - set SNI upon server_request->get_host() - release/acquire server session upon t_state.current.server->name as hostname My Suggestion is: - release/acquire server session upon server_request->get_host() - no need to check SNI in ServerSessionManager. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15512361#comment-15512361 ] Oknet Xu commented on TS-4468: -- [~jered] do you enable proxy.config.url_remap.pristine_host_hdr ? > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[
https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[
https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510070#comment-15510070
]
Oknet Xu commented on TS-4468:
--
{code}
One thing that's not clear is in what situations `t_state.current.server->name`
is not the same as `server_request.get_host`.
{code}
according the code, they are synced.
There would be a bug if they are not synced.
Therefore, we should revert the commit and fix the bug.
> 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[
https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510077#comment-15510077
]
Oknet Xu commented on TS-4468:
--
{code}
At most, if we decided we needed to be stringent in enforcing SNI/host matching
on client side, I would want the ability to opt out.
{code}
agree with that, an option to control it. [~jered]
> 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[
https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509978#comment-15509978
]
Oknet Xu commented on TS-4468:
--
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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506995#comment-15506995 ] Susan Hinrichs commented on TS-4468: I am concerned that we would be reducing client-side session reuse in HTTP/2 case if we get too aggressive in policing SNI matching host field on new requests. Say the client negotiated a new TLS connection with SNI name set to one.bob.come. It uses HTTP/2 to send a request with HOST set to one.bob.com. Then it sends a request with HOST field set to two.bob.com. one.bob.com and two.bob.com resolve to the same address, and the cert is a wildcard for *.bob.com, so the client is reusing the same HTTP/2 session. If we were stringent as [~oknet] suggests in bullet 2 we should reject that client request, which would reduce the utility of HTTP/2. [~jered]'s patch only adapts our reuse to meet the requirements of upstream HTTP/1.x servers. At most, if we decided we needed to be stringent in enforcing SNI/host matching on client side, I would want the ability to opt out. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506899#comment-15506899 ] Jered Floyd commented on TS-4468: - This is discussing when ATS is acting as a server? I haven't addressed this in my patch. Apache Server responds with a "400 Bad Request". RFC 6066 doesn't seem to offer guidance for the server actions. The current ATS behavior is probably acceptable. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506882#comment-15506882 ] Jered Floyd commented on TS-4468: - > As a client, we should always set SNI upon application layer. In another > word, the SNI of server_vc should always sync with Host header in > t_state.hdr_info.server_request. You are missing the purpose of the patch; there is also the requirement that we do not use the server session for a "Host" that does not match the previously established SNI. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[
https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506700#comment-15506700
]
Oknet Xu commented on TS-4468:
--
{code}
4789 shared_result = httpSessionManager.acquire_session(this,
// state machine
4790
_state.current.server->dst_addr.sa, // ip + port
4791
t_state.current.server->name, // hostname
4792ua_session,
// has ptr to bound ua sessions
4793this
// sm
4794);
{code}
The t_state.current.server->name should not used to acquire server session, It
is only used to lookup hostdb and get dst_addr.
We should replace it with server_request.get_host() here to obey RFC6066.
> 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506637#comment-15506637 ] Oknet Xu commented on TS-4468: -- By my understand to RFC6066: - As a server, we should always verify SNI while it get a new request. (This is not yet complete in ATS) - In another word, the SNI of client_vc should always sync with Host header in t_state.hdr_info.client_request. - As a client, we should always set SNI upon application layer. - In another word, the SNI of server_vc should always sync with Host header in t_state.hdr_info.server_request. Thus, we just do acquire server session upon server_request.get_host() is enough, and no need to compares SNI. We just fix the bug if they are not synced. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475075#comment-15475075 ] Susan Hinrichs commented on TS-4468: Sorry, disappeared off the thread. Distracted with other fires and shiny things. [~jered] I took a look at the patch and it seems quite reasonable. I'll set up a test build locally and play with it a bit. I can put up a PR if you don't get to it first. > 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 > > > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474274#comment-15474274 ] Jered Floyd commented on TS-4468: - If you're OK with my approach, then I will do so. I'm just back from two weeks vacation so it will take me a few days to get around to it, but I've put it on my TODO list. > 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 > > > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474259#comment-15474259 ] Leif Hedstrom commented on TS-4468: --- Can we get a Github Pull Request on this please? > 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 > > > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474255#comment-15474255 ] Leif Hedstrom commented on TS-4468: --- [~shinrich] Any more thoughts on this? Did you review the proposed patch? > 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 > > > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362685#comment-15362685 ] Jered Floyd commented on TS-4468: - Hey, sorry to nag -- anyone have comments on this proposed approach? > 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 > > Attachments: TS-4468.patch > > > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352000#comment-15352000 ] Jered Floyd commented on TS-4468: - I agree; they are related. Are you comfortable with my proposed solution? If so I will rewrite it against HEAD. > 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 > > Attachments: TS-4468.patch > > > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15351536#comment-15351536 ] Susan Hinrichs commented on TS-4468: While searching for issues, came across TS-3082 which seems to describe the same or a very similar issue. > 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 > > Attachments: TS-4468.patch > > > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15349039#comment-15349039 ] Jered Floyd commented on TS-4468: - Oh, also the return value of ServerSessionPool::acquireSession(...) is unused and always HSM_NOT_FOUND -- the NULL status of to_return is the actual return value. The return value of this function should be void, but I haven't addressed that in the patch because that's a cleanup rather than a bugfix. > 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 > > Attachments: TS-4468.patch > > > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321406#comment-15321406 ] Jered Floyd commented on TS-4468: - Thinking about this further, I'm wondering if session reuse blocking based on SNI should just be entirely orthogonal to the configuration setting. I think we could make a strong argument that a session must never be reused for a request that does not match the established SNI for that session, period. Would anyone object to that? If I get some free time this week I will prototype a patch. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313555#comment-15313555 ] Jered Floyd commented on TS-4468: - Alan: The current default behavior is definitely a problem, and can be mitigated in a way that has no negative effects on users that do not have multiple targets deployed on the same origin server. This speaks strongly toward a solution where the default resolves the issue, which is the case in all of solutions (1) through (3) above. If SNI is presented to an origin server, requests to a different host MUST NOT be presented on the same connection. For security purposes, SNI SHOULD be included in any origin server request. Therefore, I believe the correct (and simple) solution is one of (1) or (2) above. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313482#comment-15313482 ] Alan M. Carroll commented on TS-4468: - 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312678#comment-15312678 ] James Peach commented on TS-4468: - Contributing my 2c even though I haven't looked at this code in detail :) We should err on the side of simplicity and ItJustWorks (tm). This implies that we should not do any options and probably that the SNI name we send matches the host that we think we are talking to. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312663#comment-15312663 ] Jered Floyd commented on TS-4468: - I would argue that the default must be "safe" as in unlikely to cause error. I also agree that session reuse is valuable. Therefore, I suggest that the default behavior is either: 1) "host" (or "both") matching compares _target_ hostname instead of _replacement_ FQDN, or 2) "host" (or "both") matching compares target hostname in addition to replacement FQDN. I think option 1 there is simpler and sufficient, but please sanity check that. This solution would fix the problem and retain all the benefits of session reuse. I do not see any value in adding an further matrix of options that includes target hostname for server_session_sharing.match -- target hostname should either replace or augment replacement FQDN. There is also the third option you identified, 3) Don't set SNI name on origin connections. I think this is undesirable as it is a functional regression. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312583#comment-15312583 ] Susan Hinrichs commented on TS-4468: Bumping this issue to see if we can get some agreement on a good solution. Reusing server sessions is a big performance benefit, so I don't think we want to turn it off by default. Perhaps go to ip-only for default? What are folks thoughts on the other options listed above? [~jered] I'm afraid there is not much good detailed documentation on the state machine. I have seen something, but it was a bit out of date and not very detailed. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296480#comment-15296480 ] Susan Hinrichs commented on TS-4468: Did some research on this. The setting of SNI name for connections to origins was added in 5.1. It uses the HOST header of the server request for the SNI name for the connection from ATS to origin. Some other fixing options include: * Add option to not set SNI name. * Add another option on server session reuse to match on SNI name (instead of/in addition to FQDN and IP). > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296281#comment-15296281 ] Jered Floyd commented on TS-4468: - No problem; just describing the problem was enough to help me narrow down the trouble case enough to feel comfortable filing a ticket. :-) BTW, Is there a document that describes the various state machines? I'm familiar with pattern, but these are complex enough that I wasn't able to trace execution flow enough to provide a patch. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295882#comment-15295882 ] Leif Hedstrom commented on TS-4468: --- Thanks for the report. Sorry no one was around to help you in IRC, it was a nice Sunday afternoon, so most of us probably were out having family time :). So, I suspect, but [~amc] will have to chime in, is that this changed between v5 and v6, where we introduced the more advanced matching configurations for session reuse and sharing. Maybe we need more options, or different semantics, for TLS session sharing? Also, [~briang] might have some input on this as well. > 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)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295784#comment-15295784 ] Jered Floyd commented on TS-4468: - Also, this behavior appears to be a regression vs ATS 5.0.1, but I haven't yet identified how since the versions are so different. > 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 >Affects Versions: 6.1.1 >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)
