On 26/03/18 10:16, Yuri wrote: > > > 26.03.2018 03:02, Amos Jeffries пишет: >> On 26/03/18 09:49, Yuri wrote: >>> >>> 26.03.2018 02:45, Amos Jeffries пишет: >>>> On 26/03/18 04:41, Yuri wrote: >>>>> 25.03.2018 20:32, Matus UHLAR - fantomas пишет: >>>>>>>>> Le 25/03/2018 à 13:08, Yuri a écrit : >>>>>>>>>> The problem is not install proxy CA. The problem is identify client >>>>>>>>>> has no proxy CA and redirect, and do it only one time. >>>>>>>> On 25.03.18 13:46, Nicolas Kovacs wrote: >>>>>>>>> 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. >>>>>>> 25.03.2018 18:42, Matus UHLAR - fantomas пишет: >>>>>>>> impossible and unsafe. The CA must be installed before such splash >>>>>>>> page shows >>>>>> On 25.03.18 18:44, Yuri wrote: >>>>>>> Possible. "Safe/Unsafe" should not be discussion when SSL Bump >>>>>>> implemented already. >>>>>> 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. >>>>> Heh. If SSL designed - why SSL Bump itself possible? ;):-P >>>> 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. >>> 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*. >>> >> 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. > Waaaaaaaa, Amos, why you say "unverifiable"? 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. > You can show CA to users, 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 ... Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
