> On Jul 15, 2016, at 2:19 AM, Alan Carroll > <solidwallofc...@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 <jpe...@apache.org> wrote: > > > >> On Jul 14, 2016, at 2:45 PM, James Peach <jpe...@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 >
