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

Mon Mar 26 13:16:37 UTC 2018

Disagree.

My point about TLS is quite different.

SSH, by design, assumes end-to-end encryption and do not assumes any
third-party treats as trusty, like TLS does. SSH immediately notice you
when server key surprisingly changed. Any MiTM in SSH tunnel immediately
breaks connection. Of course, you can steal client private key, you can
break private key password. But you can't easy become fake server or
intermediate hop and silently decrypt tunneled SSH traffic. You can't do
this by design.

Basics of TLS (in HTTPS implementation) assumes trusted third-party,
which is authenticate both sides of conversations (i.e. Bob and Alice).
I.e., in case of this third party becomes untrusted by any reason (as
practice has shown, it is very likely), it can silently decrypt Bob and
Alice conversation without any notification - you still see green lock.
Here we're can not talking about SSL Bump itself. Just imagine - not
only you can do it with squid, but any who can get intermediate CA
signed by trusted root CA.

Yes, users is involved in both cases. However the difference still here.
SSH is end-to-end always by design (we're not talking about things like
Kerberos here), TLS is not.

26.03.2018 13:47, Sticher, Jascha пишет:
> Hi everyone,
>
> I know this is quite off-topic, but I wanted to clarify a bit.
>
> SSH and TLS both provide the same thing, namely a tunnel between a client and a server. While both use asymmetric crypto for authentication and symmetric crypto for data transfer and therefore the same algorithms (that's why openssh requires openssl/gnutls - as crypto library), they are independent protocols. SSH uses its own key format, which does not know such a thing as a CA – each server generates its own server key pair (or at least it should).[1,2]
>
> As to SSH-MiTM, this is indeed possible, in two cases:
> a) The server key is unknown to the client and not verified correctly (by the user!). Then a fake server can decrypt SSH and intercept everything.
> b) The client validates server certificates incorrectly or is told ignore changes in the server key (eg. “-o StrictHostKeyChecking=no” with openssh)
>
> There are some SSH-MITM solutions available on the internet.[3]
>
> To conclude, if crypto is involved _every_ part of the conversation needs to do it _right_. Including the user.
>
>
> Kind regards,
>
> Jascha
>
>
> [1] https://security.stackexchange.com/questions/1599/what-is-the-difference-between-ssl-vs-ssh-which-is-more-secure
> [2] https://wiki.hetzner.de/index.php/Ed25519 - hetzner shipped the same elliptic-curve host key on each host for a time
> [2] e.g. https://github.com/mitmproxy/mitmproxy
>
>
>
> Von: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] Im Auftrag von Yuri
> Gesendet: Montag, 26. März 2018 03:13
> An: squid-users at lists.squid-cache.org
> Betreff: Re: [squid-users] How to configure a "proxy home" page ?
>
>
>
> 26.03.2018 07:08, Amos Jeffries пишет:
> On 26/03/18 13:44, Yuri wrote:
>
>
> 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:
>
>
> 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.
>
> I'm not 100% sure, but it uses the same message framing as TLS and
> performs the same handshake sequence and security verifications.
> This is not the same as transport, yes? Because of transport is primary target for bumping.
>
>
>
> That said *SSL* _is_ different from TLS so the quote is technically
> correct either way.
> It seems to me that the difference is not of principle. Both SSL and TLS use the same architecture, in which, in principle, it is possible to have an MiTM certificate, which one of the parties trusts.
>
>
> Amos
>
> Erleben Sie Industrie 4.0 konkret – auf der HANNOVER MESSE.
> Vom 23. bis 27. April 2018.
> www.fujitsu.com/de/microsite/hmi/register/index.html?utm_source=Email&utm_medium=Signature%20EMail&utm_campaign=HANNOVER%20MESSE%20DE&utm_term=&utm_content=Ticket-anfordern
>
> _______________________________________________
> 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 *
> *****************************
> _______________________________________________
> 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/60774c41/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/60774c41/attachment-0001.sig>