trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: TS_VCONN_PRE_ACCEPT_HOOK and TS_SSL_SNI_HOOK hooks
Date Mon, 18 Jul 2016 04:44:16 GMT

> On Jul 15, 2016, at 4:20 PM, Chao Xu <xuchao@gmail.com> wrote:
> 
> Do you try set action=tunnel in ssl_multicert.config ?
> 
> # action=[tunnel]
> #   If the tunnel matches this line, traffic server will not participate
> #   in the handshake.  But rather it will blind tunnel the SSL connection.
> #   If the connection is identified by server name, an openSSL patch must
> #   be applied to enable this functionality.  See TS-3006 for details.

Are you using this feature? From code inspection you have to specify a (dummy?) certificate
in the configuration, and it still depends on inbound transparency.

> 
> 2016-07-15 6:35 GMT+08:00 James Peach <jpeach@apache.org>:
> 
>> 
>>> On Jul 15, 2016, at 2:19 AM, Alan Carroll
>> <solidwallofcode@yahoo-inc.com.INVALID> wrote:
>>> 
>>> Yes, SSL blind tunnelling requires inbound transparency because without
>> that, there is no way to determine the orign server address. We may want to
>> look at being able to set the target origin server address, but OTOH would
>> that be possible either? Where would that destination address information
>> come from?
>> 
>> My use case was to just proxy the TLS stream to the host in the SNI
>> extension without any transparency being involved. I expect we could make
>> this work, but my use case might be changing :-/
>> 
>>>   On Thursday, July 14, 2016 12:36 AM, James Peach <jpeach@apache.org>
>> wrote:
>>> 
>>> 
>>> 
>>>> On Jul 14, 2016, at 2:45 PM, James Peach <jpeach@apache.org> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I'm looking at a plugin that will blind tunnel SSL sessions, so I tried
>> to use both TS_VCONN_PRE_ACCEPT_HOOK and the TS_SSL_SNI_HOOK. AFAICT
>> neither of these work.
>>>> 
>>>> If you use TS_VCONN_PRE_ACCEPT_HOOK, the session just hangs unless you
>> bounce the call to TSVConnReenable through TSContSchedule. Once you do
>> this, curl fails with a SSL record error.
>>>> 
>>>> If you use TS_SSL_SNI_HOOK and call TSVConnTunnel without a
>> TSVConnReenable, you also get a SSL record error. If you call
>> TSVConnReenable, you get a SSL negotiation error (expected since I don't
>> have any certificates).
>>>> 
>>>> I'm going to keep debugging this, but I wondered whether anyone has
>> successfully used these?
>>> 
>>> OK, the SSL record error is because Traffic Server responds with a clear
>> text 500 error (though something eats the HTTP response header). We do end
>> up in HttpTransact::HandleBlindTunnel(), but this bails once it turns out
>> we are not doing inbound transparency. So it looks like these APIs only
>> work if you are doing transparent networking :-/
>>> 
>>> J
>>> 
>> 
>> 


Mime
View raw message