[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094591#comment-14094591 ] Susan Hinrichs commented on TS-3006: This issue augments the proxy vs blind tunnel decision making introduced in TS-2956 > 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 > > 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.2#6252)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14097645#comment-14097645 ] Susan Hinrichs commented on TS-3006: Added logic to the core SNI callback that looks for the action=tunnel option in the ssl_multicert.config file. It returns SSL_TLSEXT_ERR_READ_AGAIN from the callback, if the entry for the server name includes the action=tunnel. If the openssl patch is applied, openssl will recognize that return and halt the accept processing returning SSL_ERROR_WANT_SNI_RESOLVE from SSL_accept. I augmented the code to setup a blind tunnel when SSL_accept returns SSL_ERROR_WANT_SNI_RESOLVE. To replay the client hello message that has already been set, I changed the ATS SSL processing to use a mem buffer BIO for read instead of the normal socket based BIO. During the handshake phase, we use the read_raw_data() method to read from the socket into the memory buffer. Then we make a read-only read BIO for the SSL object. We keep two readers on the MIOBuffer we use the hold the handshake data. If the handshake aborts to create a blind tunnel, we copy the data from the holding MIOBuffer into the standard read.vio buffer. If the handshake completes, we clean up the holding buffer and set the ssl object to a regular socket BIO for read processing. Next step to is add in support for plugin supplied logic for the SNI callback. > 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 > > 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.2#6252)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098585#comment-14098585 ] Leif Hedstrom commented on TS-3006: --- Which version are we targeting this for? > 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 > > 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.2#6252)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099850#comment-14099850 ] Susan Hinrichs commented on TS-3006: Not 5.1. Probably 5.2. > 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 > > 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.2#6252)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099863#comment-14099863 ] Leif Hedstrom commented on TS-3006: --- Make it so, #1 :). > 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 > > 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.2#6252)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102249#comment-14102249 ] Susan Hinrichs commented on TS-3006: Documentation of what has been implemented to date at http://network-geographics.com/ats/docs/ssl-api.en.html. Appreciate any comments. The basic functionality has been implemented. Will continue on with more extensive testing. > 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 > 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.2#6252)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143651#comment-14143651 ] ASF subversion and git services commented on TS-3006: - Commit 044da6999442449434b282d8b537d8858505bbfc in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=044da69 ] TS-3006: Add SSL extensions and examples. > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143866#comment-14143866 ] ASF GitHub Bot commented on TS-3006: GitHub user shinrich opened a pull request: https://github.com/apache/trafficserver/pull/116 Ts 3006 fixes TS-3006 Fix compile errors and warnings. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shinrich/trafficserver ts-3006-fixes Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/116.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #116 commit 929d429700270a9aacf6d27fa37520959c4ba1b5 Author: shinrich Date: 2014-09-22T21:27:39Z Fix compile warnings and errors for ts-3006 commit a5e23295fb098ffc1f6a9dfd12a96555c5b73de8 Author: shinrich Date: 2014-09-22T21:32:37Z Fix comment > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143876#comment-14143876 ] ASF subversion and git services commented on TS-3006: - Commit 2b64392d807fc4d8e75d3170f60a41a1c881cf8f in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2b64392 ] TS-3006: Fix compile warnings and errors. This closes #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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145029#comment-14145029 ] ASF subversion and git services commented on TS-3006: - Commit 13a1844e6722d9bec21fd2e2e3c929303acd20e8 in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=13a1844 ] TS-3006: Fix plugin build error. > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145418#comment-14145418 ] ASF subversion and git services commented on TS-3006: - Commit acd5f577bdceb15e25907bf8c9006d1ca4d98650 in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=acd5f57 ] TS-3006 rebased documentation additions with master > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145417#comment-14145417 ] ASF subversion and git services commented on TS-3006: - Commit 25bd7abc0e5e66ee1da4fc6249de5d5a59a16c7c in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=25bd7ab ] TS-3006 Fix makefile to pull library for experimental plugin from build tree not source tree. > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145778#comment-14145778 ] ASF subversion and git services commented on TS-3006: - Commit a8521d39dc1d962bbbe07c001a3a890f9a6e3c30 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a8521d3 ] TS-3006: Always build TSConfig, don't require WCCP. > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145854#comment-14145854 ] ASF GitHub Bot commented on TS-3006: GitHub user shinrich opened a pull request: https://github.com/apache/trafficserver/pull/118 TS-3006 Fix regression test Update regression test to reflect changes to the internal certificate storage structure You can merge this pull request into a Git repository by running: $ git pull https://github.com/shinrich/trafficserver ts-3006-fix-regression Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/118.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #118 commit b00662b9447c5753e5b460360e90e89517e0878a Author: shinrich Date: 2014-09-24T04:11:31Z TS-3006 Fix regression test > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145869#comment-14145869 ] ASF subversion and git services commented on TS-3006: - Commit 17bef772a8cd15d141e36ae17c3877866b858ee1 in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=17bef77 ] TS-3006: Regression test fixes. This closes #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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146237#comment-14146237 ] ASF GitHub Bot commented on TS-3006: GitHub user shinrich opened a pull request: https://github.com/apache/trafficserver/pull/119 TS-3006 fix regression again. Must propagate constants into test Added elements to the parallel test HOOK enum to satisfy regression test. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shinrich/trafficserver ts-3006-fix-regression Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/119.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #119 commit 5c45e5a300c99fb4b5af7cab5778cc698d60157b Author: shinrich Date: 2014-09-24T11:36:55Z TS-3006 fix regression again. Must propagate constants into test > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146323#comment-14146323 ] ASF subversion and git services commented on TS-3006: - Commit 6a02191396a16280cf084204a30f77fed14371c8 in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6a02191 ] TS-3006 fix regression again. Must propagate constants into test. This close #119 > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146325#comment-14146325 ] ASF GitHub Bot commented on TS-3006: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/119 > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146504#comment-14146504 ] ASF subversion and git services commented on TS-3006: - Commit d5382adef49a5f6cd3f4312d0b8c6535b939b5a5 in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d5382ad ] TS-3006: Fixing more obscure build errors and documentation tweaks. This close #120. > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14256136#comment-14256136 ] Sudheer Vinukonda commented on TS-3006: --- 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14257120#comment-14257120 ] ASF subversion and git services commented on TS-3006: - Commit 4077cef23805694b54fbf7a9e6b0ab2854cfa6a9 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4077cef ] [TS-3257]: Fix ssl handshake buffer memory leak introduced in TS-3006 > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14257207#comment-14257207 ] ASF subversion and git services commented on TS-3006: - Commit a4b492cdd3ac5331736c448ea914bc9a9fe393b9 in trafficserver's branch refs/heads/5.2.x from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a4b492c ] [TS-3257]: Fix ssl handshake buffer memory leak introduced in TS-3006 > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14258902#comment-14258902 ] Sudheer Vinukonda commented on TS-3006: --- [~shinrich]: Can you please check https://issues.apache.org/jira/browse/TS-3261?focusedCommentId=14258900&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14258900 > 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)
[jira] [Commented] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259421#comment-14259421 ] ASF subversion and git services commented on TS-3006: - Commit d3219505e46f2bce208aa5ab33b80de3030c5035 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d321950 ] [TS-3261]: Fix SSL BIO memory leak issue introduced in TS-3006 > 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)
