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

[Yuri]

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"? 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?

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 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180326/a0748973/attachment-0001.html>
-------------- 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/a0748973/attachment-0001.sig>