In the desktop application case, if the server you’re connected to is malicious they can’t replace the code running on your desktop.īut for e2e webapps, you’re trusting the server - and the integrity of the data flow between your browser and the server.Īnother challenge is you need to decide where to store the key material. ![]() This means a malicious server can tamper with any of the code served to you and can, for example, display “verified fingerprints” in the webapp while an active man-in-the-middle is taking place.Ĭompare this with developer-signed desktop applications, where you can ensure that code from the developer you trust is what is running. ![]() The main issue is that when you use an e2e webapp, the webserver you’re connected to is serving the cryptographic code to you. End-to-end over the webĪ lot has been written already on the significant challenges using a web browser for e2e crypto. ![]() As always, if you have thoughts on this or notice errors, feel free to drop me a note on Twitter or by email. I’m not looking into the voice and video aspects, just the messaging and file sharing capabilities as I’m investigating to see how a similar approach could be used for SecureDrop, where voice/video isn’t an option. ![]() Next in the series, I investigate current messaging applications that both provide web applications and are using the Signal Protocol (or a protocol very similar or derived from Signal), here specifically Wire and Whatsapp.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |