Services offering end-to-end encryption through web sites can’t be trusted

A false sense of security is worse than no security at all

Whatsapp, Telegram, Element/Matrix, Protonmail, Tutanota are just the most known and widely used services, among many, offering end-to-end encryption not only through their apps, but also through their web sites.

– Can users of these web sites be confident that the people behind these web sites’ servers can’t read their “end-to-end encrypted” contents?

No, they can’t.

Not because end-to-end encryption itself is not secure (it can be); just because the delivery model of web apps, and particularly of their client-side code (i.e. code that will be executed on the user’s device), is incompatible with security: on the server-side, the client-side code that will be executed on the user’s device can be changed at any time by anyone who has access to the server(s) with very little probability of anyone noticing (not the users, and less so a “targeted” user, and less so any “third parties”). It’s not a mistery: anyone with some knowledge of how a browser works knows this; and it’s not even much of a problem (arguably, but this is my opinion), when users trust their web app providers and don’t need to trust that their data are inaccessible to anyone, i.e. not even their web app providers and in general the people on its server(s) side; it is a problem, though, when users do need to be sure of this, and it’s even more a problem when they are told, by the service owners, that this is the case: that nobody, not even them, the service providers and the people on the server(s) side, can access users’ data, while that’s just not true with web apps.

First, let’s get rid of one possible misconception: HTTPS does not make your contents unreadable by the people behind these or any other web site’s servers, it just gives you and those people pretty good security against others who may try to read your contents on the path between your device and the web sites’ servers.

Then, to the point, let’s make an example. User John logs into web.whatsapp.com and starts typing for his friend Bob, believing Whatsapp claims that what he will send through Whatsapp servers will only be readable by Bob and nobody else, not even the people at Whatsapp, since it is always end-to-end encrypted. Jimmy, an admin at web.whatsapp.com, could have set the servers so that they included into the web “page” that John is using a little javascript key-logging function that sends what John is typing to Whatsapp servers, unencrypted; and Jimmy could have set it just for John, and just for a few hours.

– Is there something John can do, when using web sites offering end-to-end encryption, to be sure the people behind the servers actually won’t read what they are not meant to read?

In order to be sure of that, John should read the whole content his browser gets on each “page” (URL) access and understand what its client-side code actually does, which is totally impractical for anyone.

– Could Jimmy-the-admin get to know John’s password too?

If Jimmy worked for Element/Matrix, Protonmail or Tutanota, I’m sure he could, since all these service providers’ web sites have a login page with a password field; their login pages usually include javascript code that, on users’ login, hashes users’ passwords before sending these hashes to the provider’s servers; when this is the case, the people behind these web sites servers actually can’t get to know their users’ passwords, but at any time these people can omit the password-hashing javascript code from any user’s login page (or from a “targeted” user’s login page, using cookies), or include the usual password-hashing javascript code with just a few changes making it do absolutely nothing; this way they can receive any user’s password in clear text.

– What can they do, once they get to know a user’s password, say John’s password?

Once they know John’s password, without doing any more “tricks”, they can decrypt John’s private key, that, if John has used one of these web sites even just once, has been stored on their servers (this is declaredly the case with Protonmail, see https://security.stackexchange.com/a/58552; page is archived here: https://archive.is/GQUf3; I’m certain it’s the case also with Element/Matrix, Tutanota and all the other providers offering end-to-end encryption through their web sites without requiring their users to pick a local file containing the private key each time it is needed); once they have John’s private key password, since that very moment they can use his private key (because they have it on their servers); thus, they can read any encrypted content John received that is still on their servers; they can read any encrypted content John will receive; they can read any encrypted content John has sent that is still on their servers, if John encrypted it with his own public key as well as with his recipients’ ones (which is common practice); they can read any encrypted content John will send, if John will encrypt it with his own public key too ––– and, since that very moment, they can do all of this not only when John is using their web sites, but also when he’s using their applications, because any content John receives and sends, even when using their applications, always passes through their servers; last but not least, they can also send encrypted and-or signed contents on John’s behalf.

I’m also sure that even the people behind the servers at Whatsapp, Telegram, and any other provider whose web site’s login page uses a login method not requiring a password, can get to know, on each login (authentication) John does with their web sites, a “secret” of John’s allowing them to unlock his private key, since in any case they need to use it for encryption, signing, and decryption, without requiring John to pick a file with his private key every time it is needed; and even if this was not the case (it is), they can read what he’s writing (and what other “targeted” John’s friends are writing, too) with a simple keylogger written in javascript (or webasm, or any client-side language which is embedded in browsers), as I wrote above.

– Do you think these security issues have been exploited yet?

I can’t be sure, of course, but there are many suspicious cases: see here and here, for example. In these cases, involving Telegram and Protonmail, it’s not clear and not explained whether Telegram and Protonmail provided authorities with just users’ metadata or even users’ data (conversations contents), but they surely could, in spite of what the already linked Wikipedia page is currently telling about Proton Mail: it’s just not true, currently, that «Due to the encryption utilized, Proton Mail is unable to hand over the contents of encrypted emails under any circumstances», as it’s just currently not true in any other case of services offering end-to-end encryption through their web sites.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *