trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <>
Date Thu, 14 Jul 2016 22:35:46 GMT

> On Jul 15, 2016, at 2:19 AM, Alan Carroll <>
> 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 <> 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
>> 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

View raw message