[jira] [Comment Edited] (TS-3006) Augment SNI callback processing

["Sudheer Vinukonda (JIRA)" <ji...@apache.org>]

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

Sudheer Vinukonda edited comment on TS-3006 at 12/22/14 8:09 PM:
-----------------------------------------------------------------

Ran into a memory leak in production testing of v5.2.0 and [~bcall] turned on io buffer memory tracking and has isolated this to this jira. Running a fix (refer TS-3257) on this host for the issue.


was (Author: sudheerv):
Ran into a memory leak in production testing of v5.2.0 and [~bcall] turned on io buffer memory tracking and has isolated this to this jira. Running a fix (refer TS-3257) for the issue.

> 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)