[squid-users] host_verify_strict and wildcard SNI

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
I know. Just asked. Since I am familiar with the standards.

07.07.2016 1:54, 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
>
>
> 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
 
iQEcBAEBCAAGBQJXfWanAAoJENNXIZxhPexGvqgH/2IuLJk7Aa4D7migO+zAFZ5p
AheNbsZcXjkT5eno1WqNkGuVROK/L97HHazYz/QvbZp4ioFJ4PZ40nHknP679KqH
RSiavQlKCmL0AuW6/ztAb7VJRbokUTRGJy39uG9ecw2uEvbS6Iq/LSAH8L9LYZgQ
vf1wd9y7iCVUDJDz++rl36XY6aqZK2u8mUVhlxoBFsOOLVSbupXIQuVEkdXL61Oo
Vrau9hUALBk5zWJ+PBlIIs578zIf36J9OhApBa/bR7/tNdVNYnB7uvSbhrgk3N1N
ChHbm2P2E1mgSMQycVW+I2E5+GvJRvi8K9wMD7TsSwWKJviY7KTS5SFyxDOY224=
=Ox2x
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160707/5b432bf9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160707/5b432bf9/attachment-0001.key>