<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">26.03.2018 03:02, Amos Jeffries пишет:<br>
    </div>
    <blockquote type="cite"
      cite="mid:b54fe88b-74bd-e158-a5d7-4a760cb294a1@treenet.co.nz">
      <pre wrap="">
On 26/03/18 09:49, Yuri wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">

26.03.2018 02:45, Amos Jeffries пишет:
</pre>
        <blockquote type="cite">
          <pre wrap="">On 26/03/18 04:41, Yuri wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">
25.03.2018 20:32, Matus UHLAR - fantomas пишет:
</pre>
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre wrap="">Le 25/03/2018 à 13:08, Yuri a écrit :
</pre>
                    <blockquote type="cite">
                      <pre wrap="">The problem is not install proxy CA. The problem is identify client
has no proxy CA and redirect, and do it only one time.
</pre>
                    </blockquote>
                  </blockquote>
                  <pre wrap="">On 25.03.18 13:46, Nicolas Kovacs wrote:
</pre>
                  <blockquote type="cite">
                    <pre wrap="">That is exactly the problem. And I have yet to find a solution for
that.

Current method is instruct everyone - with a printed paper in the
office
- to connect to proxy.company-name.lan and then get further
instructions
from the page. This works, but an automatic splash page would be more
elegant.
</pre>
                  </blockquote>
                </blockquote>
                <pre wrap="">25.03.2018 18:42, Matus UHLAR - fantomas пишет:
</pre>
                <blockquote type="cite">
                  <pre wrap="">impossible and unsafe. The CA must be installed before such splash
page shows
</pre>
                </blockquote>
              </blockquote>
              <pre wrap="">On 25.03.18 18:44, Yuri wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="">Possible. "Safe/Unsafe" should not be discussion when SSL Bump
implemented already.
</pre>
              </blockquote>
              <pre wrap="">it's possible to install splash page, but not install trusted authority
certificate.  Using such authority on a proxy is the MITM attack and
whole
SSL has been designed to prevent this.
</pre>
            </blockquote>
            <pre wrap="">Heh. If SSL designed - why SSL Bump itself possible? ;):-P
</pre>
          </blockquote>
          <pre wrap="">As all our SSL-Bump documentation should be saying:

   when TLS is used properly SSL-Bump *does not work*.

A client checking the cert validity and producing _its own_ error page
about missing/unknown/untrusted CA is one of those cases. Since the
client is producing the "page" itself there is no possibility of Squid
replacing that with something else.
</pre>
        </blockquote>
        <pre wrap="">Amos,

squid is irrelevant here. "Used properly" and "Implemented properly",
and, especially, "Designed properly" - which means "Secure by design",
like SSH or The Onion Router.

HTTPS is *NOT*.

</pre>
      </blockquote>
      <pre wrap="">
You are missing the point. Sometimes TLS *is* implemented properly.

Squid is very relevant here because it is the agent producing the
un-verifiable certificate. The certificate is un-verifiable exactly
because Squids own CA is being used and the client does not trust that CA.</pre>
    </blockquote>
    Waaaaaaaa, Amos, why you say "unverifiable"? You can show CA to
    users, they can see your PKI by eyes, check fingerprint, read your
    CPS ;) Users, in this case, trust not NSA or any abstract CA issuer,
    but your personally. Client can trust or do not trust you. But in
    case of far far away What-due-call-am-CA client trust them by
    default. Why?<br>
    <br>
    Can you do the same checks against, for example, Comodo, or
    DigiCert? I think no. You forced to trust them in absentia. "We
    swear by my mother, everything is safe with us!"<br>
    <br>
    Do your remember Trustico story?<br>
    <br>
    So, what is more secure? I am here or What-due-call-am-CA there?<br>
    <br>
    The point is not technical. <span id="result_box"
      class="short_text" lang="en"><span class="">It is rather a matter
        of faith.<br>
        <br>
        The Onion Router uses only self-signed in they infrastructure.
        We're should not trust'em due to it CA's not signed by global
        "trusted" CA? It makes TOR less secure?<br>
        <br>
        The same case here. Security/insecurity is not a matter of
        technique. This is a question of man. The car can carry, and can
        kill.<br>
        <br>
        However, there is secure by design things. And there is insecure
        by design things.<br>
        <br>
        End-to-end encryption in IM is secure by design. HTTPS is not.
        End-to-end you can't be easy break. HTTPS - just install
        third-party CA into your PC! HTTPS permits it.<br>
        <br>
        Squid here just tool. Which can be used for MiTM. Or can't. It's
        independent from you. You just manufacture the car for me. I'll
        deside, how it will be uses.<br>
        <br>
        So, users will decide - if they trust me, or do not trust. Me,
        not abstract remote CA.<br>
      </span></span>
    <blockquote type="cite"
      cite="mid:b54fe88b-74bd-e158-a5d7-4a760cb294a1@treenet.co.nz">
      <pre wrap="">

Amos
_______________________________________________
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>
    <pre class="moz-signature" cols="72">-- 
"C++ seems like a language suitable for firing other people's legs."

*****************************
* C++20 : Bug to the future *
*****************************</pre>
  </body>
</html>