trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Carroll <>
Date Thu, 14 Jul 2016 16:19:10 GMT
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? 

    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

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 :-/


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message