This article glosses over a few important details.
The reason that end to end encryption exists is precisely because man in the middle attacks are possible, and always will be. This kind of attack is devastating for Telegram, because by default they don't use end to end encryption, and instead store the entire plaintext history of every message you've ever sent or received, all of which an attacker instantly gets access to.
For WhatsApp, everything is end to end encrypted by default, so the attacker doesn't get any message history. All of the contacts for the MITM'd user also get a notice that their contact's security code changed, and a comparison will fail to match. This is exactly what E2E was built to protect against.
Yeah, I don't see how this is devastating for WhatsApp - you simply verify the other party's key once and then good to go, if it ever changes you'll get a big scary warning (you'll get that anyways but you should still verify the key in case your initial session was compromised). Admittedly I've only worked with Signal, but I'm assuming WhatsApp offers similar as they hired the same devs.
Am I missing something here? I don't see how this attack would be useful against end-to-end encrypted messaging apps (well, properly implemented ones at least).
I hope Moxie can share with us why this feature is disabled by default. Does Whatsapp really think the notification would quickly become very annoying for regular users? How often would someone's closest friends really change their phones or uninstall Whatsapp? I imagine not that often for this to be a huge inconvenience, which is why I don't understand why the setting is off by default.
Maybe it's something else I'm missing, which is why it would be good for Moxie or Whatsapp to clear up this puzzling choice.
Also I hope both the Whatsapp and Signal teams think of ways to encourage security code authentication through better UI. Viber, for instance, has taken an interesting approach to encouraging easier authentication. It probably still doesn't go far enough to make it easy enough for just about anyone to want to authenticate their contacts, but I'd like to see more of this sort of UI experimentation:
I hope Moxie can share with us why this feature is disabled by default. Does Whatsapp really think the notification would quickly become very annoying for regular users? How often would someone's closest friends really change their phones or uninstall Whatsapp? I imagine not that often for this to be a huge inconvenience, which is why I don't understand why the setting is off by default.
Moxie did not make Whatsapp. He made the protcol originally designed for Signal/TextSecure that Whatsapp uses. It's a little extreme to blame him for what is basically a UX/GUI decision on an app that just uses his protocol.
He has said before that key changes in the wild are an extremely common event. I imagine even just the notification that chats are now encrypted caused a lot of confusion and upset given the enormous size of the userbase.
Spamming users with warnings that 99.9999% of the time will not be understandable let alone actionable is a quick way to get another SSL warning dialog scenario.
My mother stopped using Whatsapp completely when she saw the "your chats are now encrypted" message the first time, until she reached out and I explained it was OK.
Because people do replace their phone, and also uninstall/reinstall the app or wipe app data etc.
You could argue (and I have done) that a key change event should be surfaced in the UI as "Your contact has switched to a new $MODEL_NAME phone" so if it occurs in the middle of a conversation or you happen to know they really haven't upgraded, it can lead people to tap it and learn more. An alert like "Contact key has changed" would be meaningless. But it's also the case that notifications that seem useless to people rapidly get phased out, and unfortunately any notification that boils down to "you MIGHT be being attacked by your own government but PROBABLY your friend just dropped their phone" is a non starter.
> you simply verify the other party's key once and then good to go
Against what, though? The key that Whatsapp asserts is valid for the other user?
As far as I am aware there's no way to access and visually eyeball-compare the raw keys in Whatsapp, just what the app presents as a signature or QR code. Open to correction.
> What's wrong with the QR code? That QR code is a hash of the public key
I have no way to verify that.
If WhatsApp is trustworthy and secure, then the QR code might be a hash of the public key, but to be completely frank, it could be anything.
* I don't have the source code.
* Nobody I know has the source code
* Nobody I know has bothered to jailbreak their device and/or decompile the binary. I just got an update recently, and my friends are busy.
If I had access to my own public and private key, I (or someone I know) could conceivably verify that I'm using it by decrypting my messages using another device (e.g. using wireshark).
I appreciate that you might have the source code, or know someone with the source code, or might have reverse engineered the most recent update and have more confidence than I do, but you cannot transmit that confidence to me by simply insisting that it is the hash of the public key.
> If WhatsApp is trustworthy and secure, then the QR code might be a hash of the public key, but to be completely frank, it could be anything.
The problem being solved here is validating that another Whatsapp user's key belongs to a flesh-and-blood person you know. We're taking it on faith at this point that Whatsapp's application is trustworthy. If it's not, validating keys is useless -- the app could upload all your chat transcripts in the background for all we know.
I'm all for validating software. But it's difficult and we're exceedingly bad at it, and imo this problem is orthogonal to validating other users on social networks.
If your argument is "let's not trust Whatsapp", then it helps not to confuse it with discussion about QR codes.
We're bad at it, because we can't tell the difference between a "QR code is a hash of the public key", and a "QR code is something WhatsApp tells us represents this other person."
Why not just use pictures of puppies? Pick the puppy you've seen represent this person before, and be suspicious if the puppy's changed! Try talking to them in person about the puppy icon used for them and make sure they match! That is actually more secure than the QR code, even if it still doesn't protect you from WhatsApp.
The reason we're talking about QR codes is because they seem more secure than puppies; to make someone think that this QR code is actually security measure! While this attack may be "foiled" by E2E cryptosystems, it's important to note the big fucking trapdoor that means WhatsApp isn't actually providing E2E protection.
Conflating this simple fact with the overarching boogeyman of "validating software" does the discussion a disservice.
> What else would you validate? A number? Whatsapp can just show you the wrong number.
Good. You appear to understand the problem now.
I already alluded to the solution here:
> If I had access to my own public and private key, I (or someone I know) could conceivably verify that I'm using it by decrypting my messages using another device (e.g. using wireshark).
and here:
> That's why providing the keys (or better: being able to supply my own) is essential.
See, if I have the keypair, then for WhatsApp to subvert my conversation it needs to send the private key to itself -- something it can only do when it's not looking.
This means it would need to let me download the keys before it does any networking. If it absolutely must network before letting me have the keys, then it can allow me to install my own (new) keys. Then, WhatsApp doesn't know when I'm not looking.
If WhatsApp made it possible to catch them being dishonest, then it only takes one person to catch them and their name becomes mud.
Of course, the mere possibility that moxie could be compromised or even make a mistake is clearly too big a leap for HN these days...
> See, if I have the keypair, then for WhatsApp to subvert my conversation it needs to send the private key to itself -- something it can only do when it's not looking.
> This means it would need to let me download the keys before it does any networking. If it absolutely must network before letting me have the keys, then it can allow me to install my own (new) keys. Then, WhatsApp doesn't know when I'm not looking.
Look up signed Diffie-Hellman. Have fun trying to capture that with Wireshark. You'd need a custom MITM tool. That or you're suggesting the developer gives up forward secrecy and passive attack resistance.
> If WhatsApp is trustworthy and secure, then the QR code might be a hash of the public key, but to be completely frank, it could be anything.
Sure, but we're talking about this specific attack's effect on WhatsApp, if you want to debate the relative merits of open source vs closed source End-To-End encryption tools, you may have a point, but it's not one that's relevant here as it has nothing to do with this attack. Unless the attack can be used to update the app or something with a modified malicious version.
Say it were Signal instead of WhatsApp if you must. Is there any effect made by this attack?
Source code is pretty useless when it is running on a proprietary platform on a device with a secondary chip running a buggy proprietary OS that has an always-on high-speed wireless network connection.
If you are using a mobile phone you have already lost in the security stakes.
You can do that if you really want, it takes about 10s of reverse engineering work to read or swap the keys. Won't do you any good though unless you constantly MITM yourself.
So many people confuse encryption with authentication...
Suppose you're a whistleblower trying to contact a reporter using WhatsApp. You've never met in person, so you send a message over WhatsApp, "Hello!" The reporter replies, "Hi!"
You now have a big problem -- you don't KNOW that it was the reporter who replied to you, it might've been a nefarious 3rd party who already intercepted your original message and is now replying.
WhatsApp's only mechanism for checking if that's the case is comparing some numbers out-of-band (e.g. in person, with QR codes).
What's even more tragic is that WhatsApp doesn't track/show which contacts you may have already authenticated.. good luck remembering which of your 100 contacts are verified
Just curious, how would you solve the authentication problem? I worked on a semester long project building decentralized chat and found this as well as bootstrapping to a node that you could trust be some of that hardest problems to solve because it always boiled down to just trust.
As he said, first you should encourage your users to authenticate one others by out-of-bands means. Then display who you truly authenticated. This can be gamified to encourage users doing it.
Now to authenticate a user out of band you can just have a shared secret that both users need to enter. You can share that secret via another channel in hope that it is not man-in-the-middled (or at least not by the same attacker). But then it is close to a trust on first use (TOFU) security: often "good enough", sometimes not (SMS).
Now if you're looking for cool ways to force the user to do it IRL, there are things like Bluetooth and NFC that would help.
There are also easier ways to do that, as ashitlerferad says, that we use for larger problems like mail and www: web of trust (WOT) and public key infrastructure (PKI).
I'd offer up keybase.io as a workable way to solve this authentication problem. On keybase I can authenticate my identify by leveraging social media and public identify proofs across multiple services.
Out of band, very public signatures. Of course this only works for fairly known people, but the reporter example could be easily covered by that solution. Publishing signatures with every article for example.
This fails for two anonymous people... but that's "by design" of being anonymous.
Is there a reason the Socialist Millionaire protocol isn't included in WhatsApp by default?
It can be handy to ask questions such as "Where did we go last Friday", perhaps even allowing for users to ask multiple questions for added confidence.
Ok, we changed the title in an attempt to make it less misleading. If anybody suggests a better (more accurate and neutral) title, we can change it again.
How does two factor authentication address they don't use end to end encryption, and instead store the entire plaintext history of every message you've ever sent or received?
Security flaws are found with any software on a regular basis. To say that it will 'devastate' a project is completely blown out of proportion. The first TrueCrypt had a lot of flaws and it still were to become the most popular encryption software. The whole point of updates is that something can be improved when flaws are found.
>For WhatsApp, everything is end to end encrypted by
default, so the attacker doesn't get any message history. All of the contacts for the MITM'd user also get a notice that their contact's security code changed, and a comparison will fail to match. This is exactly what E2E was built to protect against.
All of this 'safety' is rendered false hope when we can't conclude that WhatsApp isn't backdoored. Trusting a closed source project by Facebook is completely nonsensical imo.
Thanks. From that article: "To access an SS7 network, attackers can acquire
an existing provider’s connection on the black (underground) market and obtain
authorization to operate as a mobile carrier in countries with lax communications
laws. In addition, any hacker who happens to work as a technical specialist at a
telecommunications operator, would be able to connect their hacking equipment to
the company’s SS7 network. In order to perform certain attacks, legitimate functions of the existing communication network equipment must be used. There is also an opportunity to penetrate a provider’s network through a cracked edge device (GGSN or a femtocell)."
So they don't have a way to break into WhatsApp without breaking into SS7 first. SS7 isn't publicly accessible, and it doesn't extend out to the air link for mobiles. The attacker has to find a backdoor into SS7. The problem is that, once on the SS7 network, you can send lots of messages which are believed by telco networks. You can divert phone calls and set up MITM attacks easily.
If this works against WhatsApp, their app lacks adequate MITM protection.
But you can just connect to a carrier SS7 network because you bought an SS7 gateway appliance or because bought a SIP trunk to some third party. It doesn't work like this. You need to have an agreement with a carrier to even talk to their gateway. These are usually well vetted as well because you are entering into a financial agreement with a carrier when you connect to them this way.
You might find this angle interesting to. It's why Clive and I have pushed for not trusting the carriers, basebands, or cellphones themselves for years now.
SMS verification really sucks. It's hugely helpful because it is an 'open social graph' to use a Zuckerbergism. However, it's not at all designed to do this. It's like the problem with SSL verifying ownership via email - ok at first sight, but then say you run a webmail service and you can register webmaster@, game over without any crypto bother. Or just trojan the webmaster@ mailbox and get control over the guy that runs it and issue a valid cert. Insta-MITM.
Mobile numbers are easy to spoof and easy to port away from people. In most countries telco regulators look at how easy it is to port cell numbers as a badge of honour on how efficient their mobile regulation is. Just like everything, attackers will rush to the easiest point of failure. In this it's SMS and using phone numbers as a trusted identifier.
In the UK you need to get a "PAC code" to change provider, but it's not hard to social engineer that if you went through someones trash and grabbed an old cell bill. The number will be ported in a day or less and even worse, there's no way for you to port it back quickly since you'll have no idea who it's got to. And with it your WhatsApp, etc will all be gone security wise.
All this talk of "oh just enable these super warnings and scan QR codes" is nonsense. People port phone numbers and move phones all the time, these warnings can't be this strong otherwise half your phonebook would false positive.
SS7 is not broken at all. It's an extremely robust protocol thats been around forever. It was designed to work in the closed Bell system not designed for an idea 40 years in the future. Its not uncommon for an SS7 gateways to have 6 9's of uptime. Yes 6. There is nothing broken about it.
...he points out that telecom and spy agencies were very tight in U.K. (and often U.S.). Many features that benefit spying are there on purpose. As he predicted, they continued to be a problem in upgrades due to the compatibility argument and downgrade attacks following. Worst, certification or connection to a major wireless standard might force you to include weak crypto or security in your product.
It's all crap in terms of security. Sure they're reliable... amazingly so in some cases... but they're not secure and that's on purpose.
I may have misread it. The subject is SS7 security and here's the parent comment:
"broken beyond repair... infact it being a walled garden is the only security it ever had."
bogomipz countered with how robust the protocol is. Your critique is true if bogomipz was only countering the words "broken beyond repair" with no context. In context, though, the counter would imply disagreement with the security claim.
"isn't claiming that SS7 is secure. Nobody thinks it is."
Not everyone uses WhatsApp or other 3rd party app while SMS is enabled by default on all user phones, even "dumb" ones (still used by many people around the world). I use Signal, many friends use WhatsApp, others Telegram etc. Do you expect a bank to support them all or somehow enforce installation of their app of choice?
So when another new, shiny app made by some walled garden company shows app, bank should enforce that instead? My bank is using mobile signature(1) and I think it's way superior to any app, because the encryption part is done inside SIM which has quite good security record. There's simply no way I would trust Facebook (via WhatsApp) with my financial data.
>...encrypted apps use SMS authentication to identify and authenticate users participating in encrypted conversations
Is this true? Because it's common knowledge that SMS is insecure. So I don't understand how why anyone would want to use it for secure authentication - especially in the case of Whatsapp.
I realize every new outlet on the internet is regurgitating this story but if I call you via whats app and are both using wifi does the communication even transit an SS7 gateway at all? Why would it? Also SS7 is generally a closed system, not anyone can connect to an SS7 gateway. To signal to a carrier's SS7 gateway you have to either be a subscriber or carrier that has agreement with the owner of a SS7 gateway to terminate traffic, since this is how calls are billed. For an external carrier to connect to another carriers SS7 gateway they need to know your "code points"(kind of like an IP address for SS7.) in advance. There wasn't a lot to go on in the google translated doc.
i can't say much for telegram as their encryption has been broken, and is not an openned, but whatsapp's new signal protocol designed by moxy marlinspike doesn't use sms to authenticate. It doesn't by default require authentication, but rather has it as an option and the option generates a long 80 character passcode or QR code, to be communicated in person or via some out of band communication channel, similar to threma. Maybe they are talking about old whatsapp?
I think the article is referring to the fact that out-of-band key verification is optional and isn't something that most users will perform. If you're doing out-of-band key verification with all your contacts, and have enabled the setting that'll make WhatsApp notify you about key changes of your contacts, this doesn't concern you.
Do you have a link describing how the E2E encryption in telegram been broken? For what its worth, the client code where all the encryption happens is open source. It'd be so nice if whatsapp would do the same.
So trust on first use -style system can be attacked by intercepting the initial handshake? Yay... I suppose next the researchers will show how to MITM SSH with free wifi hotspot.
They are the local government and they just get access. They don't need to hack anything, they can just tell the local telco operators to give them access and that is the end of that.
Getting tired of constantly cleaning malware from my father's and sister's laptops, I've installed Linux Mint for them. No complaints so far (few years later) and I highly doubt they are hackers.
Yeah. Back in the days of 2012 when schools used Macs, some of the kids caught on to the fact that SSH and Terminal existed because I was using them. Now NOBODY is safe.
:-D
The reason that end to end encryption exists is precisely because man in the middle attacks are possible, and always will be. This kind of attack is devastating for Telegram, because by default they don't use end to end encryption, and instead store the entire plaintext history of every message you've ever sent or received, all of which an attacker instantly gets access to.
For WhatsApp, everything is end to end encrypted by default, so the attacker doesn't get any message history. All of the contacts for the MITM'd user also get a notice that their contact's security code changed, and a comparison will fail to match. This is exactly what E2E was built to protect against.