[squid-users] host_verify_strict and wildcard SNI

[Eliezer Croitoru]

Hey Yuri,

These two subjects are not related directly to each other but they might have something in common.
Squid expects clients connections to meet the basic RFC6066 section 3:
https://tools.ietf.org/html/rfc6066#section-3

Which states that a host name should be there and the legal characters of a hostname from both rfc1035 and rc6066 are very speicifc.
If a specific software are trying to request a wrong sni name it's an issue in the client side request or software error handling and enforcement.
A http server would probably respond with a 4XX response code or the default certificate.
There are other options of course but the first thing to check is if the client is a real browser or some special creature that tries it's luck with a special form of ssl.
To my understanding host_verify_strict tries to enforce basic security levels while in a transparent proxy the rules will always change.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il


-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Yuri Voinov
Sent: Wednesday, July 6, 2016 10:43 PM
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] host_verify_strict and wildcard SNI


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
Sounds familiar.

Do you experience occasional problems with CloudFlare sites?


06.07.2016 20:36, Steve Hill пишет:
>
> I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
>
> The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com".  I'm not sure if this
behaviour is actually illegal, but it certainly doesn't seem to make a
lot of sense to me.
>
> Squid then internally generates a "CONNECT *.example.com:443" request
based on the peeked SNI, which is picked up by hostHeaderIpVerify().
Since *.example.com isn't a valid DNS name, Squid rejects the connection
on the basis that *.example.com doesn't match the IP address that the
client is connecting to.
>
> Unfortunately, I can't see any way of working around the problem -
"host_verify_strict" is disabled, but according to the docs,
> "For now suspicious intercepted CONNECT requests are always responded
to with an HTTP 409 (Conflict) error page."
>
> As I understand it, turning host_verify_strict on causes problems with
CDNs which use DNS tricks for load balancing, so I'm not sure I
understand the rationale behind preventing it from being turned off for
CONNECT requests?
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXfV9aAAoJENNXIZxhPexGSaIH/0Q9/FiYOhBeoWIkppSU9joc
uE80bqZ9QP+e0MRcDWjsiZd6RmbcNj5+KnrFsjRLerFF42A5IZ6x9KzkswEz1sO5
CBz3gpUg9uJuTbS9WBEGmw+n1dL8nXSwpFhXM7wjb40m7cAGdFiF5DGdquj/b8bv
WgZMYREFXZaK49NunaEUIvx7DQHEqQaMLLYhQTIrTjIV1RWaiWFl5wLijfJKdpSK
MF/PK847dwmaoquzQPwVFLEuiEXyYpJMYEzQRiJhksklcW2qZRLw8LMDrj3Jrhiq
iKsB3lhyoQR1/SzXHCNxpVrZonQ4HN0LC1JeAbZteaFBYu2IH4Jd9CiTLHU4fqs=
=R47a
-----END PGP SIGNATURE-----