|
26.03.2018 03:02, Amos Jeffries пишет:
Waaaaaaaa, Amos, why you say "unverifiable"? You can show CA to users, they can see your PKI by eyes, check fingerprint, read your CPS ;) Users, in this case, trust not NSA or any abstract CA issuer, but your personally. Client can trust or do not trust you. But in case of far far away What-due-call-am-CA client trust them by default. Why?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 showsOn 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? ;):-PAs 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. Can you do the same checks against, for example, Comodo, or DigiCert? I think no. You forced to trust them in absentia. "We swear by my mother, everything is safe with us!" Do your remember Trustico story? So, what is more secure? I am here or What-due-call-am-CA there? The point is not technical. It is rather a matter of faith. The Onion Router uses only self-signed in they infrastructure. We're should not trust'em due to it CA's not signed by global "trusted" CA? It makes TOR less secure? The same case here. Security/insecurity is not a matter of technique. This is a question of man. The car can carry, and can kill. However, there is secure by design things. And there is insecure by design things. End-to-end encryption in IM is secure by design. HTTPS is not. End-to-end you can't be easy break. HTTPS - just install third-party CA into your PC! HTTPS permits it. Squid here just tool. Which can be used for MiTM. Or can't. It's independent from you. You just manufacture the car for me. I'll deside, how it will be uses. So, users will decide - if they trust me, or do not trust. Me, not abstract remote CA. 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
