[squid-users] How to configure a "proxy home" page ?

[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.
>
> 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 at 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 *
*****************************


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180326/be9b281d/attachment.sig>