ALPN, HTTP/2 and sslbump

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

ALPN, HTTP/2 and sslbump

senor
I am surprised that I didn't find this question asked and answered
recently. Maybe this issue is newer than I realize.

I understand that support of HTTPS/2 is in development but I'd like to
better understand what is and is not currently supported. I discovered
the other day that an intercepted client https connection, which
included both h2 and http/1.1 in the ALPN extension, was tunneled when
the server responded with only h2. I'm assuming that was due to squid
not fully supporting HTTP/2.

My initial need is to prevent the tunnel. Preferably by forcing http/1.1
and bumping but just denying the connection is second best. I'm not
aware of any squid built-in mechanisms to manage ALPN or HTTP/2 so I'm
thinking the external_acl is the only way to go. I think the client ALPN
data is available at bump step 2 but what options do I have at that point?

Help or corrections to my assumptions are appreciated.

Senor

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ALPN, HTTP/2 and sslbump

Amos Jeffries
Administrator
On 08/11/17 17:15, senor wrote:
> I am surprised that I didn't find this question asked and answered
> recently. Maybe this issue is newer than I realize.
>
> I understand that support of HTTPS/2 is in development but I'd like to
> better understand what is and is not currently supported. I discovered
> the other day that an intercepted client https connection, which
> included both h2 and http/1.1 in the ALPN extension, was tunneled when
> the server responded with only h2. I'm assuming that was due to squid
> not fully supporting HTTP/2.

Hmm. If you are using SSL-Bump to bump the traffic the current Squid
should be delivering an ALPN containing only HTTP/1.1 to the server.
Sending h2 in the ALPN is only valid if the proxy supports h2 natively
or intends up front to splice the transaction back to "tunneled".


>
> My initial need is to prevent the tunnel. Preferably by forcing http/1.1
> and bumping but just denying the connection is second best. I'm not
> aware of any squid built-in mechanisms to manage ALPN or HTTP/2 so I'm
> thinking the external_acl is the only way to go. I think the client ALPN
> data is available at bump step 2 but what options do I have at that point?
>
> Help or corrections to my assumptions are appreciated.
>

Any info about your Squid version, and squid.conf contents - especially
http_access and SSL-Bump related things would be useful. Random guesses
about complex things like TLS are harmful to solving actual problems.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ALPN, HTTP/2 and sslbump

senor
Thanks Amos. I guess I was assuming that squid was just copying the ALPN
extension info from Client Hello without regard to capabilities (squid
3.5.26). I'll take another stab at the debug info and post more details
if that doesn't pop something up.


Senor


On 11/7/2017 20:29, Amos Jeffries wrote:

> On 08/11/17 17:15, senor wrote:
>> I am surprised that I didn't find this question asked and answered
>> recently. Maybe this issue is newer than I realize.
>>
>> I understand that support of HTTPS/2 is in development but I'd like to
>> better understand what is and is not currently supported. I discovered
>> the other day that an intercepted client https connection, which
>> included both h2 and http/1.1 in the ALPN extension, was tunneled when
>> the server responded with only h2. I'm assuming that was due to squid
>> not fully supporting HTTP/2.
>
> Hmm. If you are using SSL-Bump to bump the traffic the current Squid
> should be delivering an ALPN containing only HTTP/1.1 to the server.
> Sending h2 in the ALPN is only valid if the proxy supports h2 natively
> or intends up front to splice the transaction back to "tunneled".
>
>
>>
>> My initial need is to prevent the tunnel. Preferably by forcing http/1.1
>> and bumping but just denying the connection is second best. I'm not
>> aware of any squid built-in mechanisms to manage ALPN or HTTP/2 so I'm
>> thinking the external_acl is the only way to go. I think the client ALPN
>> data is available at bump step 2 but what options do I have at that
>> point?
>>
>> Help or corrections to my assumptions are appreciated.
>>
>
> Any info about your Squid version, and squid.conf contents -
> especially http_access and SSL-Bump related things would be useful.
> Random guesses about complex things like TLS are harmful to solving
> actual problems.
>
> Amos
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ALPN, HTTP/2 and sslbump

brianbergstrom
In reply to this post by Amos Jeffries
I am using Squid 3.5.27 and recently started having issues when I upgraded
from openssl 1.0.1 to 1.0.2 which I believe introduced support for h2/ALPN.
I have narrowed down the issue to a request that fails but succeeds with
curl's --no-alpn flag.  

Here is the error message from Squid for the failure, though the request
ends up timing out with an EOF error.
Handshake with SSL server failed: error:140920E3:SSL
routines:ssl3_get_server_hello:parse tlsext

A tcpdump of the failure when curl sends ALPN which contains http/1.1 and h2
as its client protocols, of which the Server Hello replies and chooses h2.

A tcpdump of successful request with the --no-alpn flag verifies that no
ALPN TLS extension data is present.

If I understand the docs and this thread correctly, Squid should be removing
h2 from the ALPN in the Client Hello since Squid does not support it.  But
it appears to be passing it through and failing when the server chooses it.

The relavent lines from my squid.conf:
http_port 3130 ssl-bump cert=/etc/squid/squid.pem
follow_x_forwarded_for allow localnet

cache deny all

acl SSL_Port port 443
acl Proxy_port port 3130
http_access allow Proxy_port
http_access allow SSL_Port

acl allowed_http_sites dstdom_regex '/etc/squid/trusted_http_sites.lst'
acl allowed_https_sites ssl::server_name_regex
'/etc/squid/trusted_https_sites.lst'
acl allowed_https_ips dst '/etc/squid/trusted_https_ips.lst'

http_access allow allowed_http_sites

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

ssl_bump peek step1
ssl_bump peek step2 allowed_https_sites
ssl_bump peek step2 allowed_https_ips
ssl_bump splice step3 allowed_https_sites
ssl_bump splice step3 allowed_https_ips
ssl_bump terminate step2 all

http_access deny all




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ALPN, HTTP/2 and sslbump

Alex Rousskov
On 01/03/2018 03:30 PM, brianbergstrom wrote:

> If I understand the docs and this thread correctly, Squid should be removing
> h2 from the ALPN in the Client Hello since Squid does not support it.

Please note that Squid cannot remove something when using "peek" and
"splice" actions.

I do not know whether Squid removes unsupported ALPN values when using
"stare" and "bump" actions, and I would not be surprised to learn that
Squid does not police those values at all (yet), but I want to emphasize
that the combination of "removing" and "splicing" is impossible.


> ssl_bump peek step1
> ssl_bump peek step2 allowed_https_sites
> ssl_bump peek step2 allowed_https_ips
> ssl_bump splice step3 allowed_https_sites
> ssl_bump splice step3 allowed_https_ips
> ssl_bump terminate step2 all


HTH,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ALPN, HTTP/2 and sslbump

Amos Jeffries
Administrator
In reply to this post by brianbergstrom
On 04/01/18 11:30, brianbergstrom wrote:

> I am using Squid 3.5.27 and recently started having issues when I upgraded
> from openssl 1.0.1 to 1.0.2 which I believe introduced support for h2/ALPN.
> I have narrowed down the issue to a request that fails but succeeds with
> curl's --no-alpn flag.
>
> Here is the error message from Squid for the failure, though the request
> ends up timing out with an EOF error.
> Handshake with SSL server failed: error:140920E3:SSL
> routines:ssl3_get_server_hello:parse tlsext
>
> A tcpdump of the failure when curl sends ALPN which contains http/1.1 and h2
> as its client protocols, of which the Server Hello replies and chooses h2.
>
> A tcpdump of successful request with the --no-alpn flag verifies that no
> ALPN TLS extension data is present.
>
> If I understand the docs and this thread correctly, Squid should be removing
> h2 from the ALPN in the Client Hello since Squid does not support it.  But
> it appears to be passing it through and failing when the server chooses it.

Sort of, but not quite.

What you have configured is 'splice' - so Squid is constrained to
delivering both the TLS handshake and the encrypted data from the client
exactly as-is to the server. The APLN removal happens when Squid is able
to alter the handshake - eg for the 'bump' action.

The existence of things like ALPN should not matter to Squid when
splicing as the HTTP inside the encryption is never even looked at.

However, for the 'peek' action to succeed your OpenSSL library on the
Squid machine does need to support the TLS features being used by both
client and server endpoints. In this case it appears that the TLS
extension message in TLS itself is not being parsed correctly by the
library.


Your best options (in order of preference) are:

* update to an even more recent OpsenSSL version (1.1 etc) in hopes that
the ALPN support is more correct than the 1.0.2 code, and/or

* move your squid.conf "ssl_bump splice ..." above the "ssl_bump peek
.." lines so the splicing happens earlier if the client SNI details are
sufficient to make the decision, and/or

* try an upgrade to Squid-4. We have redesigned the handshake parsing in
that version not to depend so much on OpenSSL.

If even the latest Squid with latest OpenSSL library have the issue
please file a bug report. It will need a copy of your config settings,
and the tcpdump full-packet trace of the server handshake which is failing.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ALPN, HTTP/2 and sslbump

Amos Jeffries
Administrator
In reply to this post by Alex Rousskov
On 04/01/18 12:37, Alex Rousskov wrote:

> On 01/03/2018 03:30 PM, brianbergstrom wrote:
>
>> If I understand the docs and this thread correctly, Squid should be removing
>> h2 from the ALPN in the Client Hello since Squid does not support it.
>
> Please note that Squid cannot remove something when using "peek" and
> "splice" actions.
>
> I do not know whether Squid removes unsupported ALPN values when using
> "stare" and "bump" actions, and I would not be surprised to learn that
> Squid does not police those values at all (yet),

It does *unless* peeking at the server handshake:
<https://github.com/squid-cache/squid/blob/v3.5/src/ssl/bio.cc#L1261>.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ALPN, HTTP/2 and sslbump

brianbergstrom
Thanks for the input.  Peeking less and splicing sooner appears to resolve the issue I was having.  Since SNI is available at step 2 after peeking at step 1, I there was no lose in functionality.  So my ssl_bump config ends up looking like below:

ssl_bump peek step1
ssl_bump splice step2 allowed_https_sites
ssl_bump splice step2 allowed_https_ips
ssl_bump terminate step2 all


Thanks again!

On Wed, Jan 3, 2018 at 5:47 PM, Amos Jeffries <[hidden email]> wrote:
On 04/01/18 12:37, Alex Rousskov wrote:
On 01/03/2018 03:30 PM, brianbergstrom wrote:

If I understand the docs and this thread correctly, Squid should be removing
h2 from the ALPN in the Client Hello since Squid does not support it.

Please note that Squid cannot remove something when using "peek" and
"splice" actions.

I do not know whether Squid removes unsupported ALPN values when using
"stare" and "bump" actions, and I would not be surprised to learn that
Squid does not police those values at all (yet),

It does *unless* peeking at the server handshake: <https://github.com/squid-cache/squid/blob/v3.5/src/ssl/bio.cc#L1261>.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users



--
Brian Bergstrom
SOFTWARE ENGINEER

SportsEngine | 807 Broadway St NE | Suite 300 | Minneapolis, MN 55413

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users