💾 Archived View for koyu.space › zuz › glog › ctemplar-can-not-be-trusted-1074.gmi captured on 2023-03-20 at 18:12:29. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

CTemplar, “the only really secure end-to-end encrypted webmail”, can’t be trusted (as any other)

Posted by bu on Fri, 18 Feb 2022 06:31:38 +0100 in “Privacy”, “Smanett” and tagged with “Code”, “CTemplar”, “End-to-end encryption”, “Javascript”, “Privacy”, “Security”, “Web”, “Webmail”

Last modified on Sat, 05 Nov 2022 14:49:22 +0100

It’s silly.

CTemplar is a recent player in “secure end-to-end encrypted webmail” field.

They claim: «{Our mission is to provide an anonymous E2EE (End to End Encrypted) email. No one except you and your recipient can read the contents of your emails, not even us[1]}» ({archived[2]}).

They also claim: «{In November of 2018, Professor Kobeissi revealed that if JavaScript is required for encryption, it can also be used to hack users who use end-to-end encrypted email services. How Did We Solve This With Checksums? The checksums, released on GitHub after every update, allows our users to quickly compare the code served to their browser, with the code hosted on GitHub within 15-30 seconds. Usually, comparing code can take hours or days. With checksums, you can do it in seconds[3]}» ({archived[4]} – you can read Kobeissi findings {here[5]}).

They give instructions about how to “quickly compare the code served to their [the users’] browser, with the code hosted on GitHub within 15-30 seconds” {here[6]} ({archived[7]}).

But the fact is: all users should spend “15-30 seconds” (I spent at least one minute when trying) /every time/ they access /any URL serving CTemplar webmail service/ on {https://mail.ctemplar.com/[8]}, in order to maybe /feel/ certain (and currently not /to be/ certain: see below) that the Javascript code running in their browsers is actually the same as that published on github – which is evidently totally impractical for anyone.

And the fact is: when I tried, the {login page to their webmail service[9]} ({archived[10]}) /was not/ the same as the {login page they published on github[11]} ({archived[12]}): it sourced some more Javascript code at the end.

And the fact is: would have it been the same, /I still could not have been certain/ the Javascript code running in my browser was the same as that published on github, since for example the «browser-compatibility.js» file (among many other files the «index.html» sourced) had /two/ integrity checksums.

The checksum of the «browser-compatibility.js» file published on github actually matched the first one specified in the integrity attribute for «browser-compatibility.js» on the page I got from the server, but I actually could have received /the other, unknown and different/ «browser-compatibility.js» that /is not/ published on github and that matches the second checksum (the problem here is that {SRI allows to specify more than one checksum[13]} for a given file).

What does this all mean?

This means and confirms that {Services offering end-to-end encryption through web sites can’t be trusted[14]}.