[
https://issues.apache.org/jira/browse/TS-4706?focusedWorklogId=26168&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26168
]
ASF GitHub Bot logged work on TS-4706:
--------------------------------------
Author: ASF GitHub Bot
Created on: 03/Aug/16 00:09
Start Date: 03/Aug/16 00:09
Worklog Time Spent: 10m
Work Description: Github user gtenev commented on the issue:
https://github.com/apache/trafficserver/pull/837
@zwoop thanks for reviewing!
As far as can tell the escalate plugin was implemented later then the
HttpHdr caching and the caching implementation does not support its use-case
well. The reason we started noticing the truncated/garbage name problems is
that SSL handshake changed (got stricter)
This fix is meant to solve the immediate problem of having
`t_state.hdr_info.server_request` cache not being invalidated after the
escalate plugin called `TSHttpTxnRedirectUrlSet()` to retry the request to a
secondary origin after the primary origin failed.
This code change would invalidate (only invalidate) client request and
server request `HttpHdr` at the same time only during
`HttpSM::redirect_request()`, the caching state of the 2 objects would not
necessarily be kept (or assumed to be) in sync (client request and server
request HttpHdr were not meant to be invariant).
Filed Jira: [TS-4712](https://issues.apache.org/jira/browse/TS-4712) to
look into the `HttpHdr` caching use-cases and verify the HttpHdr caching
functionality.
Issue Time Tracking
-------------------
Worklog Id: (was: 26168)
Time Spent: 50m (was: 40m)
> SSL hostname verification failed due to truncated SNI name
> ----------------------------------------------------------
>
> Key: TS-4706
> URL: https://issues.apache.org/jira/browse/TS-4706
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Gancho Tenev
> Assignee: Gancho Tenev
> Fix For: 7.0.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> SSL hostname verification fails due to truncated SNI name when escalation
> plugin is used to redirect a failed request (404) from a primary origin
> {{primary.com}} to a secondary origin {{secondary.com}}.
> {code:title=Excerpt from the ATS logs showing the error|borderStyle=solid}
> DEBUG: <SSLNetVConnection.cc:1258 (sslClientHandShakeEvent)> (ssl) using SNI
> name ‘secondary.c'’ for client handshake
> DEBUG: <SSLNetVConnection.cc:1303 (sslClientHandShakeEvent)> (ssl.error)
> SSLNetVConnection::sslClientHandShakeEvent, SSL_ERROR_WANT_READ
> DEBUG: <SSLNetVConnection.cc:1258 (sslClientHandShakeEvent)> (ssl) using SNI
> name 'secondary.c’’ for client handshake
> DEBUG: <SSLClientUtils.cc:83 (verify_callback)> (ssl) Hostname verification
> failed for (‘secondary.c')
> {code}
> One could see that the SNI name {{secondary.com}} is truncated to
> {{secondary.c}}
> {code:title=Test case to reproduce}
> $ cat etc/trafficserver/remap.config
> map http://example.com https://primary.com @plugin=escalate.so
> @pparam=404:secondary.com
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for
> client handshake'
> DEBUG: <SSLNetVConnection.cc:1223 (sslClientHandShakeEvent)> (ssl) using SNI
> name 'primary.com' for client handshake
> DEBUG: <SSLNetVConnection.cc:1223 (sslClientHandShakeEvent)> (ssl) using SNI
> name 'secondary.c' for client handshake
> $ curl -x localhost:80 'http://example.com/path/to/object'
> {code}
> I have a fix available which produces the following log (SNI hostname no
> longer truncated)
> {code:title=Excerpt from ATS logs after applying the fix}
> $ sudo ./bin/traffic_server -T ssl 2>&1 | egrep -e 'using SNI name .* for
> client handshake'
> DEBUG: <SSLNetVConnection.cc:1223 (sslClientHandShakeEvent)> (ssl) using SNI
> name 'primary.com' for client handshake
> DEBUG: <SSLNetVConnection.cc:1223 (sslClientHandShakeEvent)> (ssl) using SNI
> name 'secondary.com' for client handshake
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
