trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chao Xu <xuc...@gmail.com>
Subject Re: TS_VCONN_PRE_ACCEPT_HOOK and TS_SSL_SNI_HOOK hooks
Date Mon, 18 Jul 2016 11:26:32 GMT
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 <jpeach@apache.org>:

>
> > On Jul 15, 2016, at 4:20 PM, Chao Xu <xuchao@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 <jpeach@apache.org>:
> >
> >>
> >>> On Jul 15, 2016, at 2:19 AM, Alan Carroll
> >> <solidwallofcode@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 <jpeach@apache.org>
> >> wrote:
> >>>
> >>>
> >>>
> >>>> On Jul 14, 2016, at 2:45 PM, James Peach <jpeach@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
> >>>
> >>
> >>
>
>

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