4 ms·

There's a lot of discussion here about key exchange, and how you need to trust whatever service is managing the keys. From the demo, it looks like the key is ba

There's a lot of discussion here about key exchange, and how you need to trust whatever service is managing the keys. From the demo, it looks like the key is basically a password. If you can share the password out-of-band through another secure channel (perhaps post it in a Signal chat or something), then your meeting should be secure. It can even be included as part of the link. But then doesn't the Jitsi web server have to access password when you enter it on their website/have it in the link? Nope! It looks like they're putting the password in an anchor fragment in the URL, which is not sent to the web server [1]. So all encryption/decryption is being done client side (and is therefore real end-to-end encryption). Yes, it's possible the web server is sending you evil JavaScript that is extracting your password anyway, but at least that's something you can in principle check. For all end-to-end encryption to work, you have to know your client is not compromised. [1] https://stackoverflow.com/a/3081862 https://stackoverflow.com/a/3081862

dcposch 6y ago
This goes straight to one of the biggest holes in the web platform: there is no mechanism for code signing or release tracking. The web already has the world's most widely used public key infrastructure. When I go to amazon.com, I can be confident that my browser is talking to a service operated by Amazon, with nobody spying on or modifying messages in flight. However, I have zero guarantees regarding the HTML/CSS/JS that service returns. It can return code modified for me specifically, different from what any other user of that app is running. For traditional server side rendered web apps, this is normal and expected. SPAs often return identical app resources for every user, and all user specific data is later transmitted via API calls... but nothing in the web enforces this. For decentralized or end-to-end encrypted apps, this is very bad. Most Ethereum apps today, for example, are used primarily via Metamask browser extension. Nothing stops an operator of such an app from just serving a different, malicious version to one specific user, based eg on IP. Such a compromise would be very hard to prove. Similarly, Jitsi might like to give users confidence that they are running the same code as everyone else, and that the code is logged, versioned, and open to security analysis. In principle, an approach similar to Certificate Transparency could provide this kind of assurance. For this to really work well, they would also have to practice good dependency hygiene and ship unminified bundles. -- This is an important web primitive that's currently missing. Do any browsers have a solution somewhere in the pipeline?
- PureParadigm 6y ago
  For code signing to work you need to trust whoever is signing the code. As you mentioned, with HTTPS, all the contents are already signed by the web server. If Jitsi published a native app and signed it, would that even help you? You still have to trust them because they could have signed anything. Maybe you mean to compare it to a copy that has already been audited by someone else? Then you might as well use the auditor's web server to get the client (and you can do this because Jitsi can be self-hosted). So I think it just comes down to connecting to web servers run by people you trust, since HTTPS already takes care of integrity checking.
  - michaelt 6y ago
    If you are running a project like Tor Browser, that needs the highest security going, you would want: 1. Signing with an offline key, so an attacker can't make a release just by hacking the web server, and the key doesn't end up on however many hundred CDN web servers around the world. 2. Clear boundaries between releases, and a slow enough release schedule that third-party auditors can keep up. 3. Non-repudiation, so users know everyone else saw the same version they saw. 4. Reproducible builds from code in a public repo, so third-party auditors know what was released is what they reviewed. 5. An update process that verifies 1-3 before applying an update. These requirements are fundamentally incompatible with webapps - where a no-questions-asked software update is only a press of F5 away, by design.
    - dane-pgp 6y ago
      > These requirements are fundamentally incompatible with webapps - where a no-questions-asked software update is only a press of F5 away, by design. If by "webapps" you mean "applications that run inside a web browser" then I disagree, since it is possible to pin a specific (presumably third-party audited) version of a webapp by using a static local bookmarklet or saved file. See my other comment [1]. You're right, though, that this is not the typical user experience for a web app, and you might reasonably believe that all webapps should be visibly associated with a domain on the internet. Personally I think it is acceptable if a high security webapp requires a slightly less convenient UX compared to normal webapps. Nevertheless, it should still be quicker and safer to "install" a bookmarklet than install a native application like the Tor Browser. [1] https://news.ycombinator.com/item?id=22862376 https://news.ycombinator.com/item?id=22862376
Arathorn 6y ago
yup, if you trust people to pass the URL around securely with a secret in a fragment, and you trust the recipients to keep the URL secret, and you're okay for anyone who ever discovers that secret to be able to decrypt and replay recordings of your conferences... then that may be acceptable. Otherwise, you'll want a way to ensure that only devices belonging to users you've explicitly invited are able to participate (and you'll want to keep the secret evolving for forward secrecy, as amusing as it'd be for you to invite your sysadmin to a conference, only for him to go and decrypt the conversation prior to him joining to find out what you were saying before he came in...) - and this require key management to track who's who and who's trusted.
- LinuxBender 6y ago
  Would there be a way to make the secret only valid for n period of time that is customizable by the admins or users?

dcposch 6y ago

This goes straight to one of the biggest holes in the web platform: there is no mechanism for code signing or release tracking. The web already has the world's most widely used public key infrastructure. When I go to amazon.com, I can be confident that my browser is talking to a service operated by Amazon, with nobody spying on or modifying messages in flight. However, I have zero guarantees regarding the HTML/CSS/JS that service returns. It can return code modified for me specifically, different from what any other user of that app is running. For traditional server side rendered web apps, this is normal and expected. SPAs often return identical app resources for every user, and all user specific data is later transmitted via API calls... but nothing in the web enforces this. For decentralized or end-to-end encrypted apps, this is very bad. Most Ethereum apps today, for example, are used primarily via Metamask browser extension. Nothing stops an operator of such an app from just serving a different, malicious version to one specific user, based eg on IP. Such a compromise would be very hard to prove. Similarly, Jitsi might like to give users confidence that they are running the same code as everyone else, and that the code is logged, versioned, and open to security analysis. In principle, an approach similar to Certificate Transparency could provide this kind of assurance. For this to really work well, they would also have to practice good dependency hygiene and ship unminified bundles. -- This is an important web primitive that's currently missing. Do any browsers have a solution somewhere in the pipeline?

PureParadigm 6y ago
For code signing to work you need to trust whoever is signing the code. As you mentioned, with HTTPS, all the contents are already signed by the web server. If Jitsi published a native app and signed it, would that even help you? You still have to trust them because they could have signed anything. Maybe you mean to compare it to a copy that has already been audited by someone else? Then you might as well use the auditor's web server to get the client (and you can do this because Jitsi can be self-hosted). So I think it just comes down to connecting to web servers run by people you trust, since HTTPS already takes care of integrity checking.
- michaelt 6y ago
  If you are running a project like Tor Browser, that needs the highest security going, you would want: 1. Signing with an offline key, so an attacker can't make a release just by hacking the web server, and the key doesn't end up on however many hundred CDN web servers around the world. 2. Clear boundaries between releases, and a slow enough release schedule that third-party auditors can keep up. 3. Non-repudiation, so users know everyone else saw the same version they saw. 4. Reproducible builds from code in a public repo, so third-party auditors know what was released is what they reviewed. 5. An update process that verifies 1-3 before applying an update. These requirements are fundamentally incompatible with webapps - where a no-questions-asked software update is only a press of F5 away, by design.
  - dane-pgp 6y ago
    > These requirements are fundamentally incompatible with webapps - where a no-questions-asked software update is only a press of F5 away, by design. If by "webapps" you mean "applications that run inside a web browser" then I disagree, since it is possible to pin a specific (presumably third-party audited) version of a webapp by using a static local bookmarklet or saved file. See my other comment [1]. You're right, though, that this is not the typical user experience for a web app, and you might reasonably believe that all webapps should be visibly associated with a domain on the internet. Personally I think it is acceptable if a high security webapp requires a slightly less convenient UX compared to normal webapps. Nevertheless, it should still be quicker and safer to "install" a bookmarklet than install a native application like the Tor Browser. [1] https://news.ycombinator.com/item?id=22862376 https://news.ycombinator.com/item?id=22862376

Arathorn 6y ago

yup, if you trust people to pass the URL around securely with a secret in a fragment, and you trust the recipients to keep the URL secret, and you're okay for anyone who ever discovers that secret to be able to decrypt and replay recordings of your conferences... then that may be acceptable. Otherwise, you'll want a way to ensure that only devices belonging to users you've explicitly invited are able to participate (and you'll want to keep the secret evolving for forward secrecy, as amusing as it'd be for you to invite your sysadmin to a conference, only for him to go and decrypt the conversation prior to him joining to find out what you were saying before he came in...) - and this require key management to track who's who and who's trusted.

LinuxBender 6y ago
Would there be a way to make the secret only valid for n period of time that is customizable by the admins or users?