[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143883#comment-14143883 ]
ASF GitHub Bot commented on TS-3006: ------------------------------------ Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/116 > 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)