<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Disagree.</p>
<p>My point about TLS is quite different.</p>
<p>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.<br>
</p>
<p>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 (<span id="result_box" class="short_text"
lang="en"><span>as practice has shown, it is very likely</span></span>),
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.<br>
</p>
<p>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.<br>
</p>
<br>
<div class="moz-cite-prefix">26.03.2018 13:47, Sticher, Jascha
пишет:<br>
</div>
<blockquote type="cite"
cite="mid:E286ADE35F919742812E3076A36122E701BFCAA911@tdsnsumbx2vp">
<pre wrap="">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] <a class="moz-txt-link-freetext" href="https://security.stackexchange.com/questions/1599/what-is-the-difference-between-ssl-vs-ssh-which-is-more-secure">https://security.stackexchange.com/questions/1599/what-is-the-difference-between-ssl-vs-ssh-which-is-more-secure</a>
[2] <a class="moz-txt-link-freetext" href="https://wiki.hetzner.de/index.php/Ed25519">https://wiki.hetzner.de/index.php/Ed25519</a> - hetzner shipped the same elliptic-curve host key on each host for a time
[2] e.g. <a class="moz-txt-link-freetext" href="https://github.com/mitmproxy/mitmproxy">https://github.com/mitmproxy/mitmproxy</a>
Von: squid-users [<a class="moz-txt-link-freetext" href="mailto:squid-users-bounces@lists.squid-cache.org">mailto:squid-users-bounces@lists.squid-cache.org</a>] Im Auftrag von Yuri
Gesendet: Montag, 26. März 2018 03:13
An: <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
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?
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl-especially-in-terms-of-sftp-vs-ftp-over-ssl">https://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl-especially-in-terms-of-sftp-vs-ftp-over-ssl</a>
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.
<a class="moz-txt-link-abbreviated" href="http://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">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</a>
_______________________________________________
squid-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
--
"C++ seems like a language suitable for firing other people's legs."
*****************************
* C++20 : Bug to the future *
*****************************
_______________________________________________
squid-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
"C++ seems like a language suitable for firing other people's legs."
*****************************
* C++20 : Bug to the future *
*****************************</pre>
</body>
</html>