|
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@xxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Yuri Gesendet: Montag, 26. März 2018 03:13 An: squid-users@xxxxxxxxxxxxxxxxxxxxx Betreff: Re: 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@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 * ***************************** _______________________________________________ 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
