[
https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145870#comment-14145870
]
ASF GitHub Bot commented on TS-3006:
------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/118
> Augment SNI callback processing
> -------------------------------
>
> Key: TS-3006
> URL: https://issues.apache.org/jira/browse/TS-3006
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL
> Reporter: Susan Hinrichs
> Assignee: Susan Hinrichs
> Fix For: 5.2.0
>
> Attachments: openssl-sni.patch
>
>
> When starting to proxy a SSL connection, it would be nice to have the
> servername available for decision making. The SNI callback gives us this
> information. The SNI callback is currently used by core. Plugins may also
> want to execute their own logic at the SNI callback. They can do that now
> using the openssl calls directly, but that would remove the core SNI callback
> processing.
> We should add plugin calls to register code to be executed in the SNI
> callback for a connection. The plugin code would be executed after the core
> SNI callback logic.
> In addition, there are scenarios when it would be useful to change how things
> are processed after learning the server name, e.g., decide to blind tunnel
> instead of proxy tunnel (see TS-2956) or perform some different certificate
> calculations. Performing these extended operations are not feasible within
> the SNI callback. Instead we want to break out of the SSL_accept() and
> perform some other logic.
> Openssl as it stands does not allow to break out of the openssl handshake
> from the SNI callback short of issuing an error (which would send an error
> message back to the client). We have created a patch that adds a new return
> which breaks out of the SSL_accept() with a non-error but non-complete return
> (like needs to read). If that patch was present, the core logic could be
> extended to adjust processing.
> In the blind tunnel case, the core logic could resend the first message
> (client hello) directly to the original server and move into the blind tunnel
> processing for the connection. In a certificate case, the core logic or some
> plugin logic could perform some certificate calculations and then try the
> SSL_accept() again at some later point in time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
