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@xxxxxxxxxxxx -----Original Message----- From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Yuri Voinov Sent: Wednesday, July 6, 2016 10:43 PM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: 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----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
