Mailing-List: contact dev-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@trafficserver.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: TS_VCONN_PRE_ACCEPT_HOOK and TS_SSL_SNI_HOOK hooks
From: James Peach <jpeach@apache.org>
In-Reply-To: <613737343.3762691.1468513150169.JavaMail.yahoo@mail.yahoo.com>
Date: Fri, 15 Jul 2016 08:35:46 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADB7A83B-0319-4526-87D2-BFD9D1818652@apache.org>
References: <22470B9B-928A-47B1-A922-B624B6A4AE95@apache.org> <908908D1-4477-41DB-AFD4-AFC5E198FEFE@apache.org> <613737343.3762691.1468513150169.JavaMail.yahoo@mail.yahoo.com>
To: dev@trafficserver.apache.org,
 Alan Carroll <solidwallofcode@yahoo-inc.com>
archived-at: Thu, 14 Jul 2016 22:36:02 -0000


> On Jul 15, 2016, at 2:19 AM, Alan Carroll =
<solidwallofcode@yahoo-inc.com.INVALID> wrote:
>=20
> 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:
>=20
>=20
>=20
>> On Jul 14, 2016, at 2:45 PM, James Peach <jpeach@apache.org> wrote:
>>=20
>> Hi all,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> I'm going to keep debugging this, but I wondered whether anyone has =
successfully used these?
>=20
> 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 :-/
>=20
> J
>=20