<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 know. Just asked. Since I am familiar with the standards.<br>
    <br>
    07.07.2016 1:54, Eliezer Croitoru пишет:<br>
    <span style="white-space: pre;">> Hey Yuri,<br>
      ><br>
      > These two subjects are not related directly to each other but
      they might have something in common.<br>
      > Squid expects clients connections to meet the basic RFC6066
      section 3:<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>
      ><br>
      > Which states that a host name should be there and the legal
      characters of a hostname from both rfc1035 and rc6066 are very
      speicifc.<br>
      > 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.<br>
      > A http server would probably respond with a 4XX response code
      or the default certificate.<br>
      > 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.<br>
      > To my understanding host_verify_strict tries to enforce basic
      security levels while in a transparent proxy the rules will always
      change.<br>
      ><br>
      > Eliezer<br>
      ><br>
      > ----<br>
      > Eliezer Croitoru<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>
      > -----Original Message-----<br>
      > From: squid-users
      [<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
      Yuri Voinov<br>
      > Sent: Wednesday, July 6, 2016 10:43 PM<br>
      > To: <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>
      > Sounds familiar.<br>
      ><br>
      > Do you experience occasional problems with CloudFlare sites?<br>
      ><br>
      ><br>
      > 06.07.2016 20:36, Steve Hill пишет:<br>
      ><br>
      > > I'm using a transparent proxy and SSL-peek and have hit
      a problem with<br>
      > an iOS app which seems to be doing broken things with the
      SNI.<br>
      ><br>
      > > The app is making an HTTPS connection to a server and
      presenting an<br>
      > SNI with a wildcard in it - i.e. "*.example.com".  I'm not
      sure if this<br>
      > behaviour is actually illegal, but it certainly doesn't seem
      to make a<br>
      > lot of sense to me.<br>
      ><br>
      > > Squid then internally generates a "CONNECT
      *.example.com:443" request<br>
      > based on the peeked SNI, which is picked up by
      hostHeaderIpVerify().<br>
      > Since *.example.com isn't a valid DNS name, Squid rejects the
      connection<br>
      > on the basis that *.example.com doesn't match the IP address
      that the<br>
      > client is connecting to.<br>
      ><br>
      > > Unfortunately, I can't see any way of working around the
      problem -<br>
      > "host_verify_strict" is disabled, but according to the docs,<br>
      > > "For now suspicious intercepted CONNECT requests are
      always responded<br>
      > to with an HTTP 409 (Conflict) error page."<br>
      ><br>
      > > As I understand it, turning host_verify_strict on causes
      problems with<br>
      > CDNs which use DNS tricks for load balancing, so I'm not sure
      I<br>
      > understand the rationale behind preventing it from being
      turned off for<br>
      > CONNECT requests?<br>
      ><br>
      ><br>
      ><br>
      ></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBCAAGBQJXfWanAAoJENNXIZxhPexGvqgH/2IuLJk7Aa4D7migO+zAFZ5p
<br>
    AheNbsZcXjkT5eno1WqNkGuVROK/L97HHazYz/QvbZp4ioFJ4PZ40nHknP679KqH
<br>
    RSiavQlKCmL0AuW6/ztAb7VJRbokUTRGJy39uG9ecw2uEvbS6Iq/LSAH8L9LYZgQ
<br>
    vf1wd9y7iCVUDJDz++rl36XY6aqZK2u8mUVhlxoBFsOOLVSbupXIQuVEkdXL61Oo
<br>
    Vrau9hUALBk5zWJ+PBlIIs578zIf36J9OhApBa/bR7/tNdVNYnB7uvSbhrgk3N1N
<br>
    ChHbm2P2E1mgSMQycVW+I2E5+GvJRvi8K9wMD7TsSwWKJviY7KTS5SFyxDOY224=
<br>
    =Ox2x
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>