26.03.2018 06:41, Yuri пишет: > > 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. I'm sure SSH using openssl under the hood. But not sure it uses same tunneling implementation like TLS-over-HTTP. And now it is still unknown any method to MiTM SSH, AFAIK. >> 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
