- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
https://github.com/positive-intentions/chat
Is this a secure messaging app? probably not… but id like to share some details about how my app works so you can tell me what im missing. id like to have wording in my app to say something like “most secure chat app in the world”… i probably cant do that because it doesnt qualify… but i want to understand why?
im not an expert on cyber security or cryptography. im sure there are many gaps in my knowlege in this domain.
using javascript, i created a chat app. it is using peerjs-server to create an encrypted webrtc connection. this is then used to exchange additional encryption keys from cryptography functions built into browsers to add a redundent layer of encryption. the key exchange is done like diffie-helman over webrtc (which can be considered secure when exchanged over public channels). the algorithms are fairly easy to use and interchangable as described here.
- i sometimes recieve feedback like “javascript is inherently insecure”. i disagree with this and have opened sourced my cryptography module. its basically a thin wrapper around vanilla crypto functions of a browser. a prev post on the matter.
- another concern for my kind of app (PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for selfhosting. selhosting this app has some unique features. unlike many other selfhosted projects, this app can be hosted on github-pages for free (instructions are provided in the readme). im also working on introducing a way that users can selfhost federated modules. a prev post on the matter.
- to prevent things like browser extensions, the app uses strict CSP headers to prevent unauthorised code from running. selfhosting users should take note of this when setting up their own instance.
- i received feedback the Signal/Simplex protocol is great, etc. id like to compare that opinion to the observation in how my todo app demo works. (the work is all experimental work-in-progress and far from finished). the demo shows a simple functionality for a basic decentralized todo list. this should already be reasonably secure. i could add handlers for exchanging keys diffie-helman style. which at this point is relatively trivial to implement. I think it’s simplicity could be a security feature.
- the key detail that makes this approach unique, is because as a webapp, unlike other solutions, users have a choice of using any device/os/browser.
i think if i stick to the principle of avoiding using any kind of “required” service provider (myself included) and allowing the frontend and the backend to be hosted independently, im on track for creating a chat system with the “fewest moving parts”. im hope you will agree this is true p2p and i hope i can use this as a step towards true privacy and security. security might be further improved by using a trusted VPN.
i created a threat-model for the app in hopes that i could get a pro-bono security assessment, but understandable the project is too complicated for pro-bono work. i contacted “Trail of bits” because of their work on SimpleX and they have quoted me $50,000. the best i can offer is “open-source and communicating on reddit”. (note: i asked them if i can share those details… summarized response: the SOW is confidential, but i can share the quote.)
while there are several similar apps out there like mine. i think mine is distinctly a different approach. so its hard to find best practices for the functionalities i want to achieve. in particular security practices to use when using p2p technology.
(note: this app is an unstable, experiment, proof of concept and not ready to replace any other app or service. It’s far from finished and provided for testing and demo purposes only.)
- Github: positive-intentions/chat
- More information about the app: positive-intentions.com
- Follow the subreddit: r/positive_intentions
I am not an expert either (anyone claiming to be so is knee-deep in dunning-kruger), but here are some thoughts:
Why are you adding an additional layer of complexity to webrtc? It has e2ee already?
How does a user validate that they are actually e2ee? Could a malicious server pretend to support your protocol and decrypt everything?
the app is more “research + development” than “a product”. i started of with a webrtc chat app without the additional encryption and it worked like it does now. i wanted to explore some of the browser based functionalities for encryption and to my surprise, it seems fairly performant so i kept it in. it is a redundent layer of encryption and as long as it doesnt compromize the security or privacy, i dont see why not. similarly, im also investigating the cryptography capabilities from WASM.
this is where the redundent layer of encryption shines. while webrtc has e2ee, using the browser crytography functions i can generate and exchange keys using the diffie-helman method and ensuring that the message can only be decrypted with the corresponding public-key. something i cant easily verify with webrtc, im just told that its there and it works.
messages can only be decrypted using the public key exchanged after the initial connection (where those keys are generated and stored for future use). malicious actors will exist in any case and so while i think the app is secure for the majority of cases, here is a section where i have suggestions on enhacing your security. (hint: it relies of you being sensible with how you use the app and not connecting to people you dont trust.)
Less code/complexity is less chance for bugs, which is why I suggest it might not be wise to add more layers.
The extra layer of encryption may give you something if the webrtc connection is assumed to be mitm’d, but you still need a way the ensure that your internal crypt is appropriately mitm resistant. On signal, this is achieved with the safety numbers that you must verify in a separate channel (IRL/email/other).
Do you have a way to do that? Is the last part of the invite URL the public key? - https://chat.positive-intentions.com/#/login/60c01cecb60530e79c0f9d90cee6642d
If not, the malicious server can simply do the handshake to both clients separately and decrypt/log/reencrypt the messages. If I am not explaining it clearly, let me know and I’ll try again.
completely agree. im breaking the app into smaller chunks (in the form of microfronends). i created a bare-minimum example of p2p communication and state management and framed it as a “todo list” app as can be seen here: https://p2p.positive-intentions.com/?path=/docs/demo-todo-list--docs . it doesnt have the bell and whistles of redundent browser cryptography. it isnt open source or anywhere near finished.
i am going in the direction of developing this further into basic chat functionality. the aim is that this new module will replace what is seen in the chat app. which i expect at that point will be a lot less complex than the one used in the app and with all the features like unit tests and documentation expected in quality work.
in the URL shared, that value is a cryptographically random value used as an ID for the peerjs-server. its best you dont share that publicly (like in your comment) because it undermines it being cryptographically random (the aim is to make it unguessable). i guess its like a phone number (i would suggest you clear all site data from your browser before continuing… you dont want strangers to connect.).
the way it works is that the unguessable ID is first used to connect peers. then on that initial connection, additional keys are created for the extra encryption. if in the future your ID is compromised people wont be able to impersonate you because messages to/from known-peers would be encrypted using that extra layer of encryption.
I wasn’t planning on reusing that ID, it was an incognito tab.
Without a way for users to validate each others public keys, at most I think you can claim is that your chat has encryption. To be properly e2ee, users need a way to validate each others public keys via a side channel, so they can be sure there is no MitM.
Also, I notice that you claim your app is decentralised, but I don’t think that is true? There is no federation or similar, so if two users want to talk, they must use the same server?
sorry for diving into the code here i dont expect you to start debugging my spaghetti code but to try and explain, let me point you to how i validate public keys. in the file found here around line 96 is what happens on an initial connection. it might not be clear, but i do something like:
i would also like to make an update to check the that the keys are signed (not sure about the terminology, but it was suggested that is a better way to do this validation… will all the redundency i have going on, im not against doing both if its seamless to the user). (note: all peers get a new set of keys generated).
the app is basically a static bundle GUI for peerjs-server. by default it is using the officialy peerjs-server. this is to make it easier for users to get started. it is possible to host your own instance and configure to use it within the app. the frontend is decentralised in the sense it can be selfhosted. and data is only stored locally on your device on your browser. no registration database.
im also investigating options for establishing a webrtc connection with no backend using QR codes to exchange the connection data. this is working but not refined enough to roll out into the app. its something i want to address in the p2p microfrontend i mentioned earlier with the todo-list.
there is no federation with peerjs-server and so peers you connect to will have to be on the same server. for those cases you will have to connect to the same server which is why it makes sense to have a the official peerjs-server as the default. it is only used for brokering a webrtc connection after which connections are P2P.
Okay, that is not a way to validate the other users public key, all that does is validate the other ends public key. The other end and the other user are not the same thing.
If this was a malicious server (or a MitM server), the way it would work is:
A wants to speak to B. The server lies, and instead of giving B’s public key, gives E. The server has the public and private keys for E.
A generates the hash, and encrypts it with what it thinks is B’s public key. The server completes the rest of your “handshake”. A has no idea that A is handshaking with E instead of B. B will also handshake with E. The server can then decrypt everything between A and B, and A and B have no idea they are using the wrong keys.
Unless A and B meet and compare public keys, they can’t know that something is up.
thanks!
i understand. can you help me understand what i can do for this. id appriciate if you could critique my approach:
im putting all the weight of the initial exchange being secure on the cryptographically random ID. if you can exchange that on a channel that is secure (whatsapp?/qr-code?/sms?), then the initial connection will establish the keys. the mitm there could be the peerjs-server (or even your ISP), but because the ID is crypto random, it would not be possible to predict who is who. (of course it could be logging connections and IP’s and figuring out from other metadata, but if that’s a concern, then you should selfhost a peerjs-server).
i previsously created something for sharing files by QR codes as described here. to enhance security more for when peers are together to exchange keys, ive taken that qr-code investigation further to create something that is able to transfer encryption keys fully offline.
I am not really sure what the real solution is beyond creating the out of band method of validating the public key. Historically, this would be done by publishing your public gpg key to a 3rd party key server. Most modern apps use a qr code (I don’t know how this works, may require research) you can scan when you physically meet, or scan over a different medium (email, SMS etc).
The problem with relying on the random number is that E can decrypt the message from A, and then reencrypt it and send it to B. B won’t know it has been inspected enroute. So B could call A and tell them the random number, but it wouldnt actually be secure. Also, if later in the chat A were to tell B, “My public key is XYZ”, E could detect that and alter it to " My public key is ABC" before sending it on to B.
If A can generate a hash of the B’s public key, and B also makes a hash, they can call each other and compare, and if the hashes don’t match, E is listening. I think that is all you need, a way to present the public key to the users so they can validate it manually.
Aside, but I don’t think it is a good idea for you to spend money on an audit yet. Spend some time trying to break your own system, by creating the malicious E server. You can then tweak and adjust your scheme until E is either impossible or trivially detectable. Unless this become a large scale venture, an audit isn’t worth it, and I get the impression this is more of a learning exercise for yourself? Also, once you are finalised, write up a paper on your scheme. Something like: https://signal.org/docs/specifications/x3dh/. Crypto experts will be able to easily validate that your scheme based on the paper. Crypto people can easily validate your scheme based on the paper…