trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Susan Hinrichs <shinr...@network-geographics.com>
Subject Re: TS_VCONN_PRE_ACCEPT_HOOK and TS_SSL_SNI_HOOK hooks
Date Mon, 18 Jul 2016 15:54:58 GMT
I would think that you could do this without a dummy certificate.  I 
just set this up on my transparent test VM, and it looks like we aren't 
tunneling at all.  Will track this down. Either a bug in the code or UE 
on my part.


On 7/18/2016 6:26 AM, Chao Xu wrote:
> sorry, I did not try the feature, but I think Susan maybe known it in
> detail.
>
> 2016-07-18 12:44 GMT+08:00 James Peach <jpeach@apache.org>:
>
>>> 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