<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">26.03.2018 21:36, Matus UHLAR -
fantomas пишет:<br>
</div>
<blockquote type="cite" cite="mid:20180326153638.GC5681@fantomas.sk">On
26.03.18 19:16, Yuri wrote:
<br>
<blockquote type="cite">Disagree.
<br>
<br>
My point about TLS is quite different.
<br>
<br>
SSH, by design, assumes end-to-end encryption and do not assumes
any
<br>
third-party treats as trusty, like TLS does.
<br>
</blockquote>
<br>
actually, the ssh DOES support certificate authorities that sign
client or
<br>
host keys, so you don't need to transfer it over SSH server - it's
just not
<br>
widely used.
<br>
<br>
<a class="moz-txt-link-freetext" href="https://www.ssh.com/ssh/keygen/#sec-Using-X-509-Certificates-for-Host-Authentication">https://www.ssh.com/ssh/keygen/#sec-Using-X-509-Certificates-for-Host-Authentication</a>
<br>
</blockquote>
I know such obvious thing. But functionality you described was not
initially designed in SSH and was added later.<br>
<blockquote type="cite" cite="mid:20180326153638.GC5681@fantomas.sk">
<br>
<blockquote type="cite">SSH immediately notice you
<br>
when server key surprisingly changed.
<br>
</blockquote>
<br>
only when you already have the host key installed in your client.
If there's
<br>
MITM attack before you get the key, you will not notice that,
unless you
<br>
get the key by other (secure) way.
<br>
</blockquote>
By analogue with TLS - let's imagine I've already been on site. With
SSH client notify me - "Hey, man, you trying to connect to server
with .... fingerprint. Add it Yes/No?"<br>
<br>
Instead this, TLS never notify me if third-party CA is known to
client.<br>
<br>
<blockquote type="cite" cite="mid:20180326153638.GC5681@fantomas.sk">
<br>
unlike SSL, SSH was not designed to be used globally between
everyone, more
<br>
within one or more "friend" organizations, so it didn't specify
how host
<br>
keys are verified (the SSHFP DNS record just transfers trust to
DNS, which
<br>
can be hijacked too).
<br>
</blockquote>
<span id="result_box" class="" lang="en"><span>To be honest, a weak
argument.</span> <span class="">A secure connection should
always be encrypted end-to-end and should not "trusted"
third-parties as well. Never. Otherwise it is insecure
connection. IMHO.<br>
</span></span>
<blockquote type="cite" cite="mid:20180326153638.GC5681@fantomas.sk">
<br>
<blockquote type="cite">Yes, users is involved in both cases.
However the difference still here.
<br>
SSH is end-to-end always by design (we're not talking about
things like
<br>
Kerberos here), TLS is not.
<br>
</blockquote>
<br>
TLS was designed to be end-to-end encryption and the certificate
authority
<br>
</blockquote>
<span id="result_box" class="short_text" lang="en"><span class="">As
Stanislavsky said, "I do not believe it!"<br>
<br>
End-to-end encryption and the (<i>trusted third-party</i>)
certificate authority these are antonyms.<br>
</span></span>
<blockquote type="cite" cite="mid:20180326153638.GC5681@fantomas.sk">system
was built to fullfil this. The bumping proxies, antiviruses, and
<br>
application firewalls just break this.
<br>
<br>
</blockquote>
<span id="result_box" class="short_text" lang="en"><span class="">With
this I can not argue.</span></span>
<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>