[squid-users] host_verify_strict and wildcard SNI

Wed Jul 6 20:48:57 UTC 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I am very seriously concerned about the issue CDN, because every day I
discover more and more problematic sites, namely in connection with the
CDN and HTTPS. For more than four Squid servers are experiencing these
problems in my network. And I still do not see any reason why any
solutions to these problems.

Moreover, the splice does not solve these problems.

Just skip the whole networks in the proxy bypass.

What is totally unacceptable. Traffic is money. And a lot of money.

07.07.2016 2:38, Eliezer Croitoru пишет:
> 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 at ngtech.co.il
> 
>
> From: Yuri Voinov [mailto:yvoinov at gmail.com]
> Sent: Wednesday, July 6, 2016 11:15 PM
> To: Eliezer Croitoru; squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] host_verify_strict and wildcard SNI
>
>
> 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 at ngtech.co.il <mailto: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
> <mailto: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

iQEcBAEBCAAGBQJXfW65AAoJENNXIZxhPexGWaYIAM0SDMtDNaeqMhQAzPn2vIBL
enqBVF1yyg532T3zGg/QwznS6dz2qKiNuMTmVfRgX0Z7QWOe/IiLlDPHboe11MXe
Y2r5JOsPht3uq/iWBPewdFlEkzLxvWlLuG65Rd9TOTmuTvM5OKTnHIHUIhXzEQXW
NUITE/FlVKoUQb5mK4wOMoDCX1gXQ1FKm77F8HxsGdwlLqx4YbMqH4J1AVJu/FwZ
IRNbnXvqXQIEn+iePPwghPxsIDl7iDzQ2H70RDeATdClaPco9bEbvxv/6pdS2hI0
Al9bCx7vNbp0pEgUmzX+O9KOWQAu0s2qhxbJ1z9eZnXFciysPBsZJf1LJ4JPbrg=
=bLEa
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160707/0db3b166/attachment.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/0db3b166/attachment.key>