On 26/03/18 12:34, Yuri wrote: > > 26.03.2018 05:23, Amos Jeffries пишет: >> On 26/03/18 12:07, Yuri wrote: >>> 26.03.2018 05:05, Amos Jeffries пишет: >>>> On 26/03/18 11:05, Yuri wrote: >>>>> And yes, HTTPS is insecure by design and all our actions does not it >>>>> less insecure :-D >>>> We are not talking about HTTPS. Only about TLS. Because the TLS decrypt >>>> is what is "failing" at the time any of these details we are discussing >>>> are relevant. >>>> >>>> The "page" mentioned is HTML created by the _client_ as its way to show >>>> the user things. Still no HTTP(S) involvement. Squid has zero >>>> involvement with that so cannot make it do anything active (like install >>>> CA certs). >>> Exactly. Users do. And we're almost have all required tools to implement >>> user'driven helper ;) >> Yet again you are circled back to involving the user. Remember the >> original point was trying to do things *without any user* knowing or >> being involved. > I could not make such a stupid idea. It does not work out that way. The > user is always asked whether trust the installing CA certificate. " On 17/03/18 01:43, Yuri wrote: > I guess better way to do this is create special ACL to catch exactly > certificate error and then redirect by 302 using deny_info to proxy page > with explanation and certificate. " The mistake here was thinking the error was something Squid could see or detect. It is not. > > The only way known for me to make this silently - using AD group policy. > > AFAIK, we're discussing usual way with catch error and redirect to page. > No more. Captive Portal, Splash, ACL etc. > In order to deliver that splash page or redirect requires the client to trust the proxy CA and decrypt the proxy HTTPS response. BUT, the problem Nicolas had in the first place was the client not trusting the proxy CA and displaying a page of its own: " On 16/03/18 23:37, Nicolas Kovacs wrote: > User who don't have the certificate installed > normally get a big fat HTTPS error as soon as they connect " The idea proposed to replace the client-created page was to send a custom one from the proxy. Which is a circle. On 26/03/18 12:34, Yuri wrote:> > 26.03.2018 05:23, Amos Jeffries пишет: >> >> This is what I mean by "TLS used properly" - proper is when it always >> circles back to user deciding who they trust. No matter how indirectly, >> the user installs a (root) CA causing trust or allowed someone else to >> do so. > Generally speaking, yes. > > I just mean, that in some other protocols you have no any possibility to > make MiTM by any way, whenever installing something or not. This > prevents any improper or malicious use of protocol. > > TLS*have* this possibility. SSH is *not*. You can't MiTM or compromise > SSH by installing any key/certs to client. Correct? This is by design? No. SSH is just TCP/telnet over TLS. So if the SSH software were to trust the cert/key Squid delivers one could use SSL-Bump on that SSH traffic. The on_unsupported_protocol feature is for exactly this non-HTTP traffic to be bumped (and rejected) or spliced by Squid. NP: The only thing protecting SSH against SSL-Bump is that servers there are *supposed* to check client certs as well as the server certs being checked by clients. The bi-directional checking breaks bumping. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
