<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Arial">To follow up:<br>
      <br>
      Adding ssl to the cache_peer directive on squid1 (and changing
      squid2 so it listens for connections on an https_port) gets us a
      little further but still doesn't work.<br>
      <br>
      Clients get a SQUID_X509_V_ERR_DOMAIN_MISMATCH error (because the
      auto-generated cert squid1 gives to the client contains the domain
      of the cache_peer *not* the ultimate origin server).<br>
      <br>
      The above is with the following ssl_bump directives set in
      squid1's config:<br>
      <br>
      ssl_bump peek step1<br>
      ssl_bump peek step2<br>
      ssl_bump splice step3<br>
      <br>
      A post from another user on this list seems to suggest they
      successfully got squid to do what we want
(<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/pipermail/squid-users/2015-November/007955.html">http://lists.squid-cache.org/pipermail/squid-users/2015-November/007955.html</a>)
      but when emulating their setup (i.e. peeking at step1, staring at
      step2 and then bumping at step3) we get the same </font><font
      face="Arial"><font face="Arial">SQUID_X509_V_ERR_DOMAIN_MISMATCH
        error.<br>
        <br>
        Setting sslflags=DONT_VERIFY_DOMAIN on the cache_peer directive
        has no effect.<br>
        <br>
        Connecting to squid1 </font></font><font face="Arial"><font
        face="Arial"><font face="Arial"><font face="Arial">with a proxy
            aware client </font></font> (on a standard http_port with
        the ssl-bump flag set but no intercept) also results in the same
        problem.<br>
        <br>
        Where are we going wrong?<br>
        <br>
        Charlie<br>
      </font></font><br>
    <div class="moz-cite-prefix">On 27/01/2017 18:24, Charlie Orford
      wrote:<br>
    </div>
    <blockquote
      cite="mid:43c4ec96-c100-149e-d2c2-78cceb4ce530@charlie.is"
      type="cite">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <div class="moz-text-flowed" style="font-size: 17px;"
        lang="x-unicode">Hi list <br>
        <br>
        We're using squid 3.5.23 and trying to achieve the following: <br>
        <br>
        client https request (not proxy aware) -> squid1 (https NAT
        intercept) -> upstream squid2 (configured as a cache_peer in
        squid1) -> origin server (e.g. <a moz-do-not-send="true"
          class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>)
        <br>
        <br>
        Amos mentioned in this thread <a moz-do-not-send="true"
          class="moz-txt-link-freetext"
href="http://lists.squid-cache.org/pipermail/squid-users/2016-March/009468.html">http://lists.squid-cache.org/pipermail/squid-users/2016-March/009468.html</a>
        that: <br>
        <br>
        > Squid can: <br>
        > <br>
        >  A) relay CONNECT message from client to any upstream
        proxy. <br>
        > <br>
        >  B) generate CONNECT message on arriving intercepted HTTPS
        and relay <br>
        > that to upstream proxy <b class="moz-txt-star"><span
            class="moz-txt-tag">*</span>IF<span class="moz-txt-tag">*</span></b>
        (and only if) ssl_bump selects the 'splice' <br>
        > action. <br>
        > <br>
        >  C) relay <a moz-do-not-send="true"
          class="moz-txt-link-freetext" href="https://">https://</a>
        URLs to an upstream TLS proxy. <br>
        > <br>
        > <br>
        > That is all at present. <br>
        > <br>
        > Squid cannot (yet) generate CONNECT messages to try and
        fetch TLS <br>
        > details via a non-TLS cache_peer. If you are able to
        sponsor that <br>
        > enhancement work patches are welcome, or sponsorship $$ to
        help pay <br>
        > persons working on these things (Christos /
        measurement-factory) are <br>
        > also welcome. <br>
        <br>
        Option B seems to cover what we need i.e. squid1 wraps arriving
        intercepted HTTPS traffic in a CONNECT and sends it upstream to
        squid2 which in turn tunnels it to the origin server.
        Unfortunately, we can't get it to work: as soon as squid1
        receives a client HTTPS request it exits with "assertion failed:
        PeerConnector.cc:116: "peer->use_ssl"" in cache.log <br>
        <br>
        Relevant config for squid1: <br>
        ###################################### <br>
        acl localnet src 10.100.0.0/24 <br>
        acl SSL_ports port 443 <br>
        acl Safe_ports port 80          # http <br>
        acl Safe_ports port 443         # https <br>
        acl Safe_ports port 777         # multiling http <br>
        acl CONNECT method CONNECT <br>
        acl Blocked_domains dstdomain "/etc/squid3/blocked.domains.acl"
        <br>
        acl step1 at_step SslBump1 <br>
        acl step2 at_step SslBump2 <br>
        acl step3 at_step SslBump3 <br>
        acl MITM_TRAFFIC myportname MITM_port <br>
        <br>
        http_access allow manager localhost <br>
        http_access deny manager <br>
        http_access deny !Safe_ports <br>
        http_access deny CONNECT !SSL_ports <br>
        http_access deny to_localhost <br>
        http_access deny Blocked_domains <br>
        http_access allow localhost <br>
        http_access allow localnet <br>
        http_access deny all <br>
        http_reply_access allow all <br>
        <br>
        https_port 8443 ssl-bump intercept
        cert=/etc/squid3/root_ca.combined.pem
        generate-host-certificates=on dynamic_cert_mem_cache_size=8MB
        name=MITM_port <br>
        sslcrtd_program /usr/lib/squid3/ssl_crtd -s
        /var/lib/squid3/ssl_db -M 4MB <br>
        <br>
        ssl_bump peek all <br>
        ssl_bump splice all <br>
        <br>
        nonhierarchical_direct off <br>
        never_direct allow all <br>
        prefer_direct off <br>
        cache_peer 192.168.0.1 parent 3128 0 no-query no-digest
        no-netdb-exchange name=WWW_GATEWAY <br>
        <br>
        <br>
        Relevant config for squid2: <br>
        ###################################### <br>
        acl localnet src 192.168.0.0/24 <br>
        acl SSL_ports port 443 <br>
        acl Safe_ports port 80          # http <br>
        acl Safe_ports port 443         # https <br>
        acl Safe_ports port 777         # multiling http <br>
        acl CONNECT method CONNECT <br>
        <br>
        http_port 3128 <br>
        <br>
        http_access allow manager localhost <br>
        http_access deny manager <br>
        http_access deny !Safe_ports <br>
        http_access deny CONNECT !SSL_ports <br>
        http_access deny to_localhost <br>
        http_access allow localnet <br>
        http_access deny all <br>
        <br>
        http_reply_access allow all <br>
        <br>
        <br>
        Is what we want to do currently achievable with the latest 3.5
        branch or have we misunderstood what Amos was stating (some of
        his posts about ssl interception and cache_peer support can be
        fairly cryptic)? <br>
        <br>
        If it is achievable, does the cache_peer link itself also need
        to be encrypted (via the ssl flag) to make it work?<br>
        <br>
        Thanks, <br>
        Charlie <br>
        <br>
        <br>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
squid-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>