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