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