<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br>
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.<br>
<br>
Moreover, the splice does not solve these problems.<br>
<br>
Just skip the whole networks in the proxy bypass.<br>
<br>
What is totally unacceptable. Traffic is money. And a lot of money.<br>
<br>
07.07.2016 2:38, Eliezer Croitoru пишет:<br>
<span style="white-space: pre;">> Hey Yuri,<br>
><br>
> I am not the "standards" guy but I do know that if something
can be encoded<br>
> it can be "decoded".<br>
> There are special cases which needs special "spice" which
sometimes is not<br>
> present here or there on the shelves.<br>
> To my disappointment and happiness there are very good
products out there<br>
> which are not squid with much better fines invested in them.<br>
> I can clearly say that the Squid-Cache project is not the
most "advanced"<br>
> piece of software in the market and I know that it cannot
compare to let say<br>
> even 500 coding programmers work.<br>
> I have seen couple products that are open source which tries
to provide<br>
> functionality which is similar to squid only in the protocol
level and a<br>
> simple proxy with great luck.<br>
> Some of them are not as great as they might seems but I think
that a young<br>
> programmer with enough investment can learn the required
subjects to<br>
> implement a solution.<br>
> However, here admins, users, programmers can ask questions as
they please<br>
> and I encourage to ask.<br>
> I try to answer as much as I can and in many cases my
knowledge might not<br>
> be enough but I am trying to answer what I can with hope that
it will help.<br>
> And unlike MD Doctors SysAdmins do not need to swear on
something like "do<br>
> not harm" and I think it's a good aspect on things.<br>
><br>
> I am still looking for clues about cloudflare since I have
yet to see the<br>
> person who hold the keys for them.<br>
><br>
> Eliezer<br>
><br>
> ----<br>
> Eliezer Croitoru <a class="moz-txt-link-rfc2396E" href="http://ngtech.co.il/lmgtfy/"><http://ngtech.co.il/lmgtfy/></a> <br>
> Linux System Administrator<br>
> Mobile: +972-5-28704261<br>
> Email: <a class="moz-txt-link-abbreviated" href="mailto:eliezer@ngtech.co.il">eliezer@ngtech.co.il</a><br>
> <br>
><br>
> From: Yuri Voinov [<a class="moz-txt-link-freetext" href="mailto:yvoinov@gmail.com">mailto:yvoinov@gmail.com</a>] <br>
> Sent: Wednesday, July 6, 2016 11:15 PM<br>
> To: Eliezer Croitoru; <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> Subject: Re: [squid-users] host_verify_strict and wildcard
SNI<br>
><br>
><br>
> I know. Just asked. Since I am familiar with the standards.<br>
><br>
> 07.07.2016 1:54, Eliezer Croitoru пишет:<br>
> > Hey Yuri,<br>
><br>
><br>
><br>
> > These two subjects are not related directly to
each other but<br>
> they might have something in common.<br>
><br>
> > Squid expects clients connections to meet the
basic RFC6066<br>
> section 3:<br>
><br>
> > <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6066#section-3">https://tools.ietf.org/html/rfc6066#section-3</a><br>
> <a class="moz-txt-link-rfc2396E" href="https://tools.ietf.org/html/rfc6066"><https://tools.ietf.org/html/rfc6066></a><br>
><br>
><br>
><br>
> > Which states that a host name should be there and
the legal<br>
> characters of a hostname from both rfc1035 and rc6066
are very<br>
> speicifc.<br>
><br>
> > If a specific software are trying to request a
wrong sni name<br>
> it's an issue in the client side request or software
error<br>
> handling and enforcement.<br>
><br>
> > A http server would probably respond with a 4XX
response code<br>
> or the default certificate.<br>
><br>
> > There are other options of course but the first
thing to<br>
> check is if the client is a real browser or some
special creature<br>
> that tries it's luck with a special form of ssl.<br>
><br>
> > To my understanding host_verify_strict tries to
enforce basic<br>
> security levels while in a transparent proxy the rules
will always<br>
> change.<br>
><br>
><br>
><br>
> > Eliezer<br>
><br>
><br>
><br>
> > ----<br>
><br>
> > Eliezer Croitoru<br>
><br>
> > Linux System Administrator<br>
><br>
> > Mobile: +972-5-28704261<br>
><br>
> > Email: <a class="moz-txt-link-abbreviated" href="mailto:eliezer@ngtech.co.il">eliezer@ngtech.co.il</a>
<a class="moz-txt-link-rfc2396E" href="mailto:eliezer@ngtech.co.il"><mailto:eliezer@ngtech.co.il></a><br>
><br>
><br>
><br>
><br>
><br>
> > -----Original Message-----<br>
><br>
> > From: squid-users<br>
> [<a class="moz-txt-link-freetext" href="mailto:squid-users-bounces@lists.squid-cache.org">mailto:squid-users-bounces@lists.squid-cache.org</a>] On
Behalf Of<br>
> Yuri Voinov<br>
><br>
> > Sent: Wednesday, July 6, 2016 10:43 PM<br>
><br>
> > To: <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> <a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org"><mailto:squid-users@lists.squid-cache.org></a><br>
><br>
> > Subject: Re: [squid-users] host_verify_strict and
wildcard<br>
> SNI<br>
><br>
><br>
><br>
><br>
><br>
> > Sounds familiar.<br>
><br>
><br>
><br>
> > Do you experience occasional problems with
CloudFlare sites?<br>
><br>
><br>
><br>
><br>
><br>
> > 06.07.2016 20:36, Steve Hill пишет:<br>
><br>
><br>
><br>
> > > I'm using a transparent proxy and SSL-peek
and have hit<br>
> a problem with<br>
><br>
> > an iOS app which seems to be doing broken things
with the<br>
> SNI.<br>
><br>
><br>
><br>
> > > The app is making an HTTPS connection to a
server and<br>
> presenting an<br>
><br>
> > SNI with a wildcard in it - i.e. "*.example.com".
I'm not<br>
> sure if this<br>
><br>
> > behaviour is actually illegal, but it certainly
doesn't seem<br>
> to make a<br>
><br>
> > lot of sense to me.<br>
><br>
><br>
><br>
> > > Squid then internally generates a "CONNECT<br>
> *.example.com:443" request<br>
><br>
> > based on the peeked SNI, which is picked up by<br>
> hostHeaderIpVerify().<br>
><br>
> > Since *.example.com isn't a valid DNS name, Squid
rejects the<br>
> connection<br>
><br>
> > on the basis that *.example.com doesn't match the
IP address<br>
> that the<br>
><br>
> > client is connecting to.<br>
><br>
><br>
><br>
> > > Unfortunately, I can't see any way of working
around the<br>
> problem -<br>
><br>
> > "host_verify_strict" is disabled, but according to
the docs,<br>
><br>
> > > "For now suspicious intercepted CONNECT
requests are<br>
> always responded<br>
><br>
> > to with an HTTP 409 (Conflict) error page."<br>
><br>
><br>
><br>
> > > As I understand it, turning
host_verify_strict on causes<br>
> problems with<br>
><br>
> > CDNs which use DNS tricks for load balancing, so
I'm not sure<br>
> I<br>
><br>
> > understand the rationale behind preventing it from
being<br>
> turned off for<br>
><br>
> > CONNECT requests?<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
></span><br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBCAAGBQJXfW65AAoJENNXIZxhPexGWaYIAM0SDMtDNaeqMhQAzPn2vIBL
<br>
enqBVF1yyg532T3zGg/QwznS6dz2qKiNuMTmVfRgX0Z7QWOe/IiLlDPHboe11MXe
<br>
Y2r5JOsPht3uq/iWBPewdFlEkzLxvWlLuG65Rd9TOTmuTvM5OKTnHIHUIhXzEQXW
<br>
NUITE/FlVKoUQb5mK4wOMoDCX1gXQ1FKm77F8HxsGdwlLqx4YbMqH4J1AVJu/FwZ
<br>
IRNbnXvqXQIEn+iePPwghPxsIDl7iDzQ2H70RDeATdClaPco9bEbvxv/6pdS2hI0
<br>
Al9bCx7vNbp0pEgUmzX+O9KOWQAu0s2qhxbJ1z9eZnXFciysPBsZJf1LJ4JPbrg=
<br>
=bLEa
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>