Both UE and a code problem!
Once I fixed my configuration problem, there were two remaining checks
that insisted on specifying a cert on the line in ssl_multicert before
inserting the entry in the lookup tree. Once I removed those checks a
line like
dest_ip=107.23.60.186 action=tunnel
Worked just fine to blind tunnel SSL traffic destined to 107.23.60.186.
But my server port was configured for tr-full. We'd have to make some
additional changes to make this work for non-transparent.
I'll go ahead and file a bug to see if we want to make these changes.
And/or make additional changes for the non-transparent case.
On 7/18/2016 10:54 AM, Susan Hinrichs wrote:
I would think that you could do this without a dummy certificate. I
just set this up on my transparent test VM, and it looks like we
aren't tunneling at all. Will track this down. Either a bug in the
code or UE on my part.
On 7/18/2016 6:26 AM, Chao Xu wrote:
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
