trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Susan Hinrichs <>
Date Mon, 18 Jul 2016 18:06:56 GMT
Both UE and a code problem!

Once I fixed my configuration problem, there were two remaining checks 
that insisted on specifying a cert on the line in ssl_multicert before 
inserting the entry in the lookup tree.  Once I removed those checks a 
line like

dest_ip= action=tunnel

Worked just fine to blind tunnel SSL traffic destined to  
But my server port was configured for tr-full. We'd have to make some 
additional changes to make this work for non-transparent.

I'll go ahead and file a bug to see if we want to make these changes.  
And/or make additional changes for the non-transparent case.

On 7/18/2016 10:54 AM, Susan Hinrichs wrote:
> 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 <>:
>>>> On Jul 15, 2016, at 4:20 PM, Chao Xu <> 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 <>:
>>>>>> On Jul 15, 2016, at 2:19 AM, Alan Carroll
>>>>> <> 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 
>>>>>> <>
>>>>> wrote:
>>>>>>> On Jul 14, 2016, at 2:45 PM, James Peach <>
>>>>>>> Hi all,
>>>>>>> I'm looking at a plugin that will blind tunnel SSL sessions,
so I
>>> tried
>>>>> 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
>>>>> successfully used these?
>>>>>> OK, the SSL record error is because Traffic Server responds with
>>> 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

View raw message