I mean, for example: SSL_ERROR_CLIENT_DOES_NOT_KNOW_THIS_CA
during TLS negotiation between client and proxy. To be separated from rare cases when real world CA exists, but not yet included to well-known CA's bundle. Something like this. Now we're can't differentiate UNKNOWN_ISSUES error - it is external or internal issue. 26.03.2018 04:11, Yuri пишет: > > By the way, Amos. I have an idea spinning around. 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? This would greatly facilitate the task > that we are discussing. > > We're can, in this case, just use deny_info to redirect client to > proxy page. ;-) > > > 26.03.2018 04:05, Yuri пишет: >> And yes, HTTPS is insecure by design and all our actions does not it >> less insecure :-D >> >> >> 26.03.2018 04:03, Yuri пишет: >>> 26.03.2018 03:55, Amos Jeffries пишет: >>>> 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. >>> 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? >>>>> 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 ... >>> 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....... ;) >>>> Amos >>>> _______________________________________________ >>>> squid-users mailing list >>>> squid-users@lists.squid-cache.org >>>> 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 * > ***************************** -- "C++ seems like a language suitable for firing other people's legs." ***************************** * C++20 : Bug to the future * *****************************
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users