<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>I mean, for example:</p>
    <p>SSL_ERROR_CLIENT_DOES_NOT_KNOW_THIS_CA</p>
    <p>during TLS negotiation between client and proxy.</p>
    <p>To be separated from rare cases when real world CA exists, but
      not yet included to well-known CA's bundle.</p>
    <p>Something like this. Now we're can't differentiate UNKNOWN_ISSUES
      error - it is external or internal issue.<br>
    </p>
    <br>
    <div class="moz-cite-prefix">26.03.2018 04:11, Yuri пишет:<br>
    </div>
    <blockquote type="cite"
      cite="mid:57cab373-2a9b-d1fc-c3e5-e34558303b47@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <p><span id="result_box" class="" lang="en"><span>By the way,
            Amos.</span> <span>I have an idea spinning around.</span> <span
            class="">Is it possible to specify the SSL error of the
            unknown certificate issuer for the correct processing of the
            situation when the client does not have a proxy certificate
            installed?</span> <span class="">This would greatly
            facilitate the task that we are discussing.</span></span></p>
      <p><span id="result_box" class="" lang="en"><span class="">We're
            can, in this case, just use deny_info to redirect client to
            proxy page. <span class="moz-smiley-s3"><span>;-)</span></span><br>
          </span></span></p>
      <br>
      <div class="moz-cite-prefix">26.03.2018 04:05, Yuri пишет:<br>
      </div>
      <blockquote type="cite"
        cite="mid:d96136f0-bf89-d3ee-af98-f8347f82c3e8@gmail.com">
        <pre wrap="">And yes, HTTPS is insecure by design and all our actions does not it
less insecure :-D


26.03.2018 04:03, Yuri пишет:
</pre>
        <blockquote type="cite">
          <pre wrap="">26.03.2018 03:55, Amos Jeffries пишет:
</pre>
          <blockquote type="cite">
            <pre wrap="">On 26/03/18 10:16, Yuri wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">26.03.2018 03:02, Amos Jeffries пишет:
</pre>
              <blockquote type="cite">
                <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>
              <pre wrap="">Waaaaaaaa, Amos, why you say "unverifiable"? 
</pre>
            </blockquote>
            <pre wrap="">Because that is the situation. The client software cannot silently
verify the certificate nor automatically install the not-trusted CA to
cause that *previous* verification attempt to succeed.
</pre>
          </blockquote>
          <pre wrap="">Sure. User always should:

a) Have root/administrative privilegies to install any CA in trusted
store on client
b) Device always asks users "Hey, somebody tries to install CA with
fingerprint blah-blah-blah.... you trust them? Install? (Yes/No)"

We're not talking about forced silently push proxy CA to client, right?
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">You can show CA to users,
</pre>
            </blockquote>
            <pre wrap="">Er, you are now going in circles.

The initial problem was that it is not possible to verify the cert
automatically *without* showing the user things. Requiring the user to
see something to get around that problem ...
</pre>
          </blockquote>
          <pre wrap="">Yes. We're want just to determine - is proxy CA installed? and if not,
redirect user to page to make desicion - install/not install. Get
internet/remain locally ;)
On this page we're can inform user about all require things: our CPS,
our privacy policy, warnings, legal issues, CA fingerprint, CA issuer
etc. ;)

This seems better? All same like adult CA does :)

We're all understand we're can't silently push any CA to client ;) This
is illegal, technically impossible, insecure....... ;)
</pre>
          <blockquote type="cite">
            <pre wrap="">Amos
_______________________________________________
squid-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org" moz-do-not-send="true">squid-users@lists.squid-cache.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users" moz-do-not-send="true">http://lists.squid-cache.org/listinfo/squid-users</a>
</pre>
          </blockquote>
        </blockquote>
      </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>
    </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>