26.03.2018 06:30, Amos Jeffries пишет: > 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. My bad. Miss it. So obvious thing for me. > > > > > 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. You sure? https://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl-especially-in-terms-of-sftp-vs-ftp-over-ssl Quote: "SSH has its own transport protocol independent from SSL, so that means SSH DOES NOT use SSL under the hood." Because I'm not. Different sources tells opposite. > > 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 -- "C++ seems like a language suitable for firing other people's legs." ***************************** * C++20 : Bug to the future * *****************************
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
