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

Yuri yvoinov at gmail.com
Mon Mar 26 00:44:18 UTC 2018



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 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/55f1ce7a/attachment-0001.sig>


More information about the squid-users mailing list