<div dir="ltr"><div>SSL (used by HTTPS) depends on PKI to solve this problem. PKI is about having a trusted third party to vouch for the identity of at least one of the participants involved. That trusted third party is the CA - VeriSign, Thawte, Comodo, etc.<br></div><div><br></div><div>HTTPS is therefore secure against MITM as long as all of the (hundreds of) CAs operate correctly -- that is, they aren't subverted by a malicious party, and they don't lose their signing keys.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 December 2015 at 00:27, U.Mutlu <span dir="ltr"><<a href="mailto:for-gmane@mutluit.com" target="_blank">for-gmane@mutluit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Justin King-Lacroix wrote on 12/07/2015 02:52 PM:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No. Even in principle, this is essentially impossible -- two parties with<br>
no relationship basically can't communicate securely.<br>
There are lots of approaches to the problem, but they all involve breaking<br>
the 'no relationship' constraint. PKI -- and thus iMessage, WhatsApp --<br>
does it by introducing a well-known trusted third-party. PGP / Web of Trust<br>
does it by relying on social graphs. OTR and SSH leave it up to you: they<br>
show you the key fingerprint, and it's up to you to work out whether it's<br>
the right one.<br>
But in general, the problem you're describing has no solution.<br>
<br>
(Once you've exchanged keys, of course, there are a multitude of way to<br>
create a secure channel on that basis. But you need to exchange keys<br>
somehow first.)<br>
<br>
Justin<br>
</blockquote>
<br></span>
But this means for https in practice that:<br>
NONE of the security protocols used in https is secure against MITM.<br>
So, https is insecure whatever ciphers one uses, be it DH_RSA, DH_DSS,<br>
DHE_RSA, DHE_DSS or any of the others possible in the security protocol settings.<br>
That means, NSA & Co. can MITM all https communications.<br>
Unless one exchanges with the site in advance (ie. manually) the certified<br>
public keys of each other, but which in 99.9% of the cases surely not<br>
happens because of the extra and manual work (and costs) needed.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 6 December 2015 at 23:43, U.Mutlu <<a href="mailto:for-gmane@mutluit.com" target="_blank">for-gmane@mutluit.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Justin King-Lacroix wrote on 12/06/2015 03:23 PM:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are basically three common ways to authenticate a DH key exchange:<br>
<br>
     1. If you and your partner *already have* a shared secret: you mix it<br>
     into into the key exchange somehow. This is the 'shared key'<br>
mechanism, and<br>
     is the basis of (eg) PAKE. The crux of this mechanism is that the key<br>
     exchange will fail unless both parties knew the shared secret.<br>
     2. If you and your partner have long-term public keys, and *each<br>
already<br>
     knows the public key of the other*: you use the corresponding private<br>
     keys to augment the key exchange. This one basically breaks down into<br>
two<br>
     categories, depending on what kinds of long-term public keys you have.<br>
        1. If you have signing keys, then you digitally sign the DH<br>
        transaction to authenticate it. You also need to hash the<br>
long-term public<br>
        keys into the shared secret, or you introduce an identity<br>
misbinding<br>
        vulnerability.<br>
        2. If you have DH-type keys, then you basically do the DH crypto<br>
        twice, using both sets of keys.<br>
     3. If you and your partner have long-term public keys, and you *don't<br>
     know* each other's public keys, then you need someone to vouch for<br>
you.<br>
     In most people's heads, that means "PKI", but SSH/OTR-style<br>
     check-the-fingerprint is potentially viable.<br>
<br>
There's also a whole raft of academic literature on more subtle ways you<br>
can authenticate your DH transaction using the properties of the<br>
environment, like the availability of secondary, very low-bandwidth<br>
channels (think Bluetooth pairing); I can direct you to one or two of<br>
those<br>
papers if you're interested. But those three are the 'classically strong'<br>
ones, and the ones that are the easiest to understand.<br>
<br>
Justin<br>
<br>
</blockquote>
<br>
Hello, thank you,<br>
I'm interested in a practical and ultimate MITM-prevention method<br>
to be used in computer communication using TCP.<br>
<br>
All the papers and examples I read on MITM-prevention do expect<br>
that one already has safely (pre-) exchanged the public keys<br>
of a signing algo like RSA for signing+enc+dec.<br>
<br>
And just that exactly is now the question I'm seeking an answer for,<br>
ie. does there exist an algorithm for sending/exchanging the public keys<br>
safely (that is guaranteed authentic) over the public internet,<br>
w/o human interaction by the two parties?<br>
<br>
Said differently:<br>
Public keys are by definition of course public, but there is the "little"<br>
problem of authentically transmitting it to the other party, for example<br>
the public key of an ephemeral RSA method to be used as nonce in session<br>
creation with PFS: here Alice needs to be sure that Bob receives her<br>
new pubkey, and not that of someone else in the middle (MITM).<br>
Any algorithm known for solving this elementary problem of securely<br>
exchanging the public keys?<br>
<br>
--<br>
U.Mutlu<br>
</blockquote></blockquote>
<br>
<br>
_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
</div></div></blockquote></div><br></div>