Hey Yuri, I am not the "standards" guy but I do know that if something can be encoded it can be "decoded". There are special cases which needs special "spice" which sometimes is not present here or there on the shelves. To my disappointment and happiness there are very good products out there which are not squid with much better fines invested in them. I can clearly say that the Squid-Cache project is not the most "advanced" piece of software in the market and I know that it cannot compare to let say even 500 coding programmers work. I have seen couple products that are open source which tries to provide functionality which is similar to squid only in the protocol level and a simple proxy with great luck. Some of them are not as great as they might seems but I think that a young programmer with enough investment can learn the required subjects to implement a solution. However, here admins, users, programmers can ask questions as they please and I encourage to ask. I try to answer as much as I can and in many cases my knowledge might not be enough but I am trying to answer what I can with hope that it will help. And unlike MD Doctors SysAdmins do not need to swear on something like "do not harm" and I think it's a good aspect on things. I am still looking for clues about cloudflare since I have yet to see the person who hold the keys for them. Eliezer ---- Eliezer Croitoru <http://ngtech.co.il/lmgtfy/> Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx From: Yuri Voinov [mailto:yvoinov@xxxxxxxxx] Sent: Wednesday, July 6, 2016 11:15 PM To: Eliezer Croitoru; squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: host_verify_strict and wildcard SNI -----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 <https://tools.ietf.org/html/rfc6066> > > 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 <mailto: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 <mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx> > Subject: Re: 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-----
<<attachment: winmail.dat>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
