A draft of some HTML extensions and one “browser rule” to secure web end-to-end encrypted communications

[Last edited on Friday, May the 20th, 2022, 07:30]

Nowadays there’s a huge security problem with webapps claiming to provide end-to-end secure encryption. The problem does not reside into end-to-end encryption itself: it can be secure enough for every kind of end user, when it’s well implemented and its implementations are periodically enough audited by affordable third parties. The main and by far biggest problem with end-to-end encryption through webapps (that is, through web sites) currently resides in the fact that any webapp, with its javascript client-side code, is delivered to any user – that is you, me, anyone else – every time he/she/* opens a “page” (an URL). This means that there can’t be any effective auditing activity by affordable third parties to ensure a webapp claiming to be secure does what it should and does not what it shouldn’t, since any malicious actor with access to the web server(s) it runs on could at any time change the code to steal any (possibly targeted) user’s supposedly client-side-only and secure data.

Continua a leggere A draft of some HTML extensions and one “browser rule” to secure web end-to-end encrypted communications

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

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» (archived).
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» (archived – you can read Kobeissi findings here).
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 (archived).
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/, 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 (archived) was not the same as the login page they published on github (archived): it sourced some more Javascript code at the end.

CTemplar login page source

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.

CTemplar login page source (2)

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 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.