HTTPS pass through / SNI filtering

Discussion:

Deniz Eren

2011-07-04 12:04:59 UTC

Hi;

I'm planning to work on an acl which uses SNI. But I need to pass
https traffic through squid without processing it. Because I'm not
interested in filtering or seeing the content, SNI server_name info
will be enough. But with squid it is not possible to pass https
traffic without processing it. In my design I won't use proxy, the
iptables rule below will redirect https traffic to squid:

iptables -t nat -I PREROUTING -p tcp --dport 443 -j DNAT
--to-destination 192.168.0.1:3128

Can you give me ideas how to solve above problem? And also are you
working on SNI filtering?

Good day to you..

Deniz Eren

2011-07-06 06:34:08 UTC

Permalink

Hi;

Can you give me an idea from where to start in order to pass https
traffic unprocessed through squid or implement SNI filtering for
squid, that will be enough to start my project.

Thanks in advance..

Post by Deniz Eren
Hi;
I'm planning to work on an acl which uses SNI. But I need to pass
https traffic through squid without processing it. Because I'm not
interested in filtering or seeing the content, SNI server_name info
will be enough. But with squid it is not possible to pass https
traffic without processing it. In my design I won't use proxy, the
iptables -t nat -I PREROUTING -p tcp --dport 443 -j DNAT
--to-destination 192.168.0.1:3128
Can you give me ideas how to solve above problem? And also are you
working on SNI filtering?
Good day to you..

Amos Jeffries

2011-07-06 08:36:55 UTC

Permalink

Post by Deniz Eren
Hi;
Can you give me an idea from where to start in order to pass https
traffic unprocessed through squid or implement SNI filtering for
squid, that will be enough to start my project.
Thanks in advance..

We have not yet gotten around to implementing a "ssl" flag on http_port
directives. You will need to start with that to allow detection of the
case where ssl traffic is intercepted on a port.

You will need to adjust TunnelStateData so that you can create it with
only a Comm::Connection object instead of a ClientHttpRequest or
HttpRequest object.

You will need to then figure out what changes to ConnStateData are
needed to detect the intercept+ssl flags case and do SNI instead of
parsing an HTTP request. Have it spawn a TunnelStateData object to do
the actual bit-relay work. Somehow making sure the whole SSL sequence
including SNI data arrive properly at the destination server without
getting lost or swallowed by Squids processing.

Good luck.

Post by Deniz Eren

--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.14
Beta testers wanted for 3.2.0.9

Deniz Eren

2011-08-03 08:38:55 UTC

Permalink

Hi again;

I have changed tunnelStart(...) function a bit and now I can create
fake HTTP request without depending on ClientHttpRequest, but problem
is I could not find the right place to intercept connection and use
tunnelStart(...) to forward HTTPS packets through squid. Can you give
me ideas where to call tunnelStart(...) function and after that how to
continue? (By the way I am doing all these stuff with squid-3.1.14).

Good day to you..

Amos Jeffries <squid3 () treenet ! co ! nz>

We have not yet gotten around to implementing a "ssl" flag on http_port
directives. You will need to start with that to allow detection of the
case where ssl traffic is intercepted on a port.

You will need to adjust TunnelStateData so that you can create it with
only a Comm::Connection object instead of a ClientHttpRequest or
HttpRequest object.

You will need to then figure out what changes to ConnStateData are
needed to detect the intercept+ssl flags case and do SNI instead of
parsing an HTTP request. Have it spawn a TunnelStateData object to do
the actual bit-relay work. Somehow making sure the whole SSL sequence
including SNI data arrive properly at the destination server without
getting lost or swallowed by Squids processing.

Good luck.

--
Deniz Eren

Amos Jeffries

2011-08-03 09:21:17 UTC

Permalink

In src/client_side.cc the function called httpsAccept() is run on each
new connection.

Near the end it runs "commSetSelect(newfd, COMM_SELECT_READ, ..." to
kick off the SSL negotiation. Which in turn starts the regular HTTPS
receive handling.

I think you need to do something at that point like:

if (s->intercepted) {
... new call to handle SNI and lead on to tunnel creation.
} else {
commSetSelect(newfd, COMM_SELECT_READ, clientNegotiateSSL ...);
}

Then you configure a regular https_port with the "intercept" mode set
and connections to it will run through your code.

Amos

Post by Deniz Eren
Amos Jeffries<squid3 () treenet ! co ! nz>
We have not yet gotten around to implementing a "ssl" flag on http_port
directives. You will need to start with that to allow detection of the
case where ssl traffic is intercepted on a port.
You will need to adjust TunnelStateData so that you can create it with
only a Comm::Connection object instead of a ClientHttpRequest or
HttpRequest object.
You will need to then figure out what changes to ConnStateData are
needed to detect the intercept+ssl flags case and do SNI instead of
parsing an HTTP request. Have it spawn a TunnelStateData object to do
the actual bit-relay work. Somehow making sure the whole SSL sequence
including SNI data arrive properly at the destination server without
getting lost or swallowed by Squids processing.
Good luck.

--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.14
Beta testers wanted for 3.2.0.10

Tsantilas Christos

2011-08-03 10:05:48 UTC

Permalink

Hi Deniz,
You can not use SSL SNI in squid unless you are intercepting the SSL
connection. So you need to touch the sslbump related code. I think you
should touch the httpsAccept function which is implemented in
client_side.cc file.

Some time ago created an experimental SNI patch which funded by
Measurement Factory which worked with intercepted connections and if I
am correct worked quite well with some restrictions (which may can be
resolved).
In the case you are interested contact Alex Rousskov and Measurement
Factory.

Regards,
Christos

Post by Deniz Eren
Hi again;
I have changed tunnelStart(...) function a bit and now I can create
fake HTTP request without depending on ClientHttpRequest, but problem
is I could not find the right place to intercept connection and use
tunnelStart(...) to forward HTTPS packets through squid. Can you give
me ideas where to call tunnelStart(...) function and after that how to
continue? (By the way I am doing all these stuff with squid-3.1.14).
Good day to you..
Amos Jeffries<squid3 () treenet ! co ! nz>
We have not yet gotten around to implementing a "ssl" flag on http_port
directives. You will need to start with that to allow detection of the
case where ssl traffic is intercepted on a port.
You will need to adjust TunnelStateData so that you can create it with
only a Comm::Connection object instead of a ClientHttpRequest or
HttpRequest object.
You will need to then figure out what changes to ConnStateData are
needed to detect the intercept+ssl flags case and do SNI instead of
parsing an HTTP request. Have it spawn a TunnelStateData object to do
the actual bit-relay work. Somehow making sure the whole SSL sequence
including SNI data arrive properly at the destination server without
getting lost or swallowed by Squids processing.
Good luck.