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 <jpe...@apache.org>: > > > On Jul 15, 2016, at 4:20 PM, Chao Xu <xuc...@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 <jpe...@apache.org>: > > > >> > >>> 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 > >>> > >> > >> > >