6 ms·
Jeremy, thanks for Chitchatter and for bringing this up here. The first feedback I can give you is about the threat model and the associated OPSEC measures ment
by adg001 4y ago
Jeremy, thanks for Chitchatter and for bringing this up here. The first feedback I can give you is about the threat model and the associated OPSEC measures mentioned in the README.
Anyone with knowledge of the room UUID can listen to the conversation, even though the presence of the eavesdropper may (or may not) show up in the connected peers' counter. It is of essence to share such UUIDs over a secure channel, or the communication security will be compromised trivially.
It is mentioned in the README the relevance of government level threat actors and email, SMS, Discord, among the possible mediums over which the UUIDs can be shared. Of course this leaves Chitchatter open to be attacked by governments and network operators, who do have access to the phone network(s), email servers, and other platforms involved. It would be best to prefer other out-of-bound channels, or come up with one-time UUIDs generators able to resynchronise and shared among the peers.
- TheJoeMan 4y agoI had a relevant thought just the other day: why do our chat apps (sms, wechat, etc) need the ability to message someone without first meeting face to face? Maybe just use a QR code you scan from their phone and that’s it. If anyone gets your phone number they can send you unwanted spam because it’s “push”
- kornhole 4y agoButnernote.com could be a good way to share the room URL over generally insecure channels. After MVP, maybe an ephemeral room link could be created using the code from burnernote to save a step.
- deleted 4y ago[deleted]
- jamesholden 4y agoBurnernote.com ? I think you meant?
- edf13 4y agoHow do the likes of Burnernote and yopass prove security/safety/offline?
- kornhole 4y agoWhen you don't have a secure E2EE coms channel with someone, these services enable creation of a one time link that you can send over SMS/email. If the intended recipient is unable to open the link, you know your coms have been intercepted.
- gloosx 4y agoBut who said they don't backtrack every note with sender IP index? I would do that, imagine the temptation to store all the secrets making a centralised secret notes service
- kornhole 4y agoBurnernote code is FOSS if you want to investigate how it works. As for IP addresses, you are probably aware of TOR and VPN's if you want that additional layer of obscurity.
- gloosx 4y agoThere are numerous problems with that. First – why on earth i need to believe that the source hosted on Github is actually used to build burnernote.com bundle? The bundle is highly minified and obfuscated and the only way to check that is to build the same bundle on your machine and checksum. Did anyone ever did that? Another big issue is since it open-source – it relies on 1000 open-source dependencies, any one of them can be compromised, and the changes to them happening quicker than you can audit them all
- yamrzou 4y agoOr Yopass: https://yopass.se https://yopass.se
- jckahn 4y agoI've added both of these to the README. Thanks for the suggestions!
- feb 4y agoThe README is a bit optimistic about it the security model. Like the parent said the room UUID is a very critical asset and should be handled as a critical secret. Sadly, users may not know that. In addition, the README says one can audit the full code and the assets used. For example, it suggests to audit the gh-pages branch for the static assets. But when hosting with github, that branch could change at any time and deliver non-audited content. Powerful attackers like government could do it easily, and less powerful ones too.
- dspillett 4y ago> should be handled as a critical secret. Sadly, users may not know that. Or find it inconvenient at some point and think "it doesn't matter that much, does it?"... As is often the case, the human is the weakest link in the security chain.
- jckahn 4y ago> For example, it suggests to audit the gh-pages branch for the static assets. But when hosting with github, that branch could change at any time and deliver non-audited content. Powerful attackers like government could do it easily, and less powerful ones too. That's a great point. There's nothing stopping folks from producing their own builds and self-hosting Chitchatter though, so that seems like a reasonably easy problem to solve.
- DreamFlasher 4y agoInitial key exchange via public private keys would be an amazing addition!
- jckahn 4y agoI don't know if this would be considered a legitimate public/private key exchange, but we now have a feature request for integrated OTP functionality: https://github.com/jeremyckahn/chitchatter/issues/2 https://github.com/jeremyckahn/chitchatter/issues/2 Hopefully this will address the need for secure room access!
- jwally 4y agoAgree. I started building this out last year to explore web crypto and webrtc but got sidetracked. Have you looked into webcrypto? Create a new ecdh keypair for each session for each party, keep the private inextricable in memory, trade public keys over webrtc. This (I think) ensures no-one can evesdrop. Peer auth could occur normally with ecdsa signatures done OUTSIDE of the browser or whatever.
- jckahn 4y agoThis is an interesting idea. How do you envision this working, broadly speaking?
- ajconway 4y agoOn top of that, like every p2p service without onion routing, one's IP address is visible to every other room participant by design.
- jckahn 4y agoDo you know if that might be mitigated by using Chitchatter via a Tor browser? I’m still building my understanding of the low-level mechanics of WebRTC.
- jckahn 4y agoThat's a great point. I'll tweak the README a little later to suggest using https://burnernote.com/ https://burnernote.com/ (as others here have suggested) to more securely share room links. Thanks for the suggestion! > Anyone with knowledge of the room UUID can listen to the conversation, even though the presence of the eavesdropper may (or may not) show up in the connected peers' counter. Though much of Chitchatter's security model is based on security by obscurity, I don't know that peers would be able to connect without room participants being notified. Is there a scenario you have in mind where a peer would be able to connect and intercept messages without the peer counter incrementing?
- adg001 4y agoAn attacker may try to exploit bugs in the code base, or subtle language features (e.g., weird behaviours, overflows), in order to hide one or more connected endpoints. Further, in order to build assurance about the counter integrity, we would need to employ formal verification and code authentication techniques, so as to ensure that 1/ the software will behave only as intended, and 2/ nobody has tampered with the code base. In absence of such assurance guarantees – which are difficult to provide when the client can be instantiated essentially on any compatible device, the security of the protocol (ie., WebRTC + UUID out-of-band communication) reduces to software security of the code base.
- jckahn 4y agoThat makes sense. Thank you for the explanation! > Further, in order to build assurance about the counter integrity, we would need to employ formal verification and code authentication techniques Can you point me to resources that might help be understand what that might look like? I'm assuming it requires a third party to audit the project in-depth. I would further assume that such a service costs quite a bit of money. Chitchatter is not a revenue-generating project, so that would have to be to be figured out. FWIW, I don't consider myself a security expert. I'm learning security best practices by developing Chitchatter. More than anything, I'm hoping to form a community of interested subject matter experts around this project to help build towards the vision of simple and secure communication! :)