[squid-users] host_verify_strict and wildcard SNI
Eliezer Croitoru
eliezer at ngtech.co.il
Wed Jul 6 21:53:49 UTC 2016
If the splice doesn’t solve the issue what would you expect squid to do?
Spilce equals routing…
The other solution which ufdbguard implements is probing the destination hosts.
If you want a solution I can try to see if it is possible but I cannot guarantee that you or anyone will like it.
Eliezer
----
<http://ngtech.co.il/lmgtfy/> Eliezer Croitoru
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:49 PM
To: Eliezer Croitoru; squid-users at lists.squid-cache.org
Subject: Re: [squid-users] host_verify_strict and wildcard SNI
-----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/> <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 <mailto: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> <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>
<mailto: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>
> <mailto: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/f796037e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 11297 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160707/f796037e/attachment-0001.png>
More information about the squid-users
mailing list