17 ms·

Proof of concept: end-to-end encryption in Jitsi Meet

617 points by jrepinc 7y ago

emilfihlman 7y ago
>GET parameter Yes, it's convenient. But to tout that as what a well designed encryption scheme should look like? Nah.
- bflesch 7y ago
  What is your alternative suggestion? In a browser-based video chat scenario you are ultimately assuming some level of browser security and that the clients are trusted. What they propose is an E2E encryption, e.g. Zoom / MS Teams are unable to decrypt your conversations. Obviously, if you choose a weak key, they can just store the stream and crack it later.
- giancarlostoro 7y ago
  It was a hash mark, only the client got that value (specifically JavaScript). Note how his page did not reload when he hit enter. Had it been a GET request, it would of refreshed.
- CrazyStat 7y ago
  From the link: > In order to enable quick demos of the feature we allowed for e2ee keys to be passed to Jitsi Meet via a URL parameter. > IMPORTANT NOTE: This is a demo of an e2e encrypted call and the feature is NOT YET intended for general availability, so play with it all you want, but, for now, in matters where security is paramount we still recommend deploying your own Jitsi Meet instance. > As we already pointed out, passing keys as URL parameters is a demo thing only. Aside from being impractical it also carries risks given that URL params are stored in browser history. > Our next step is therefore to work out exactly how key management and exchange would work. We expect we will be using The Double Ratchet Algorithm through libolm but the details are still to be ironed out. They're not touting passing the keys in a URL parameter as a "well designed encryption scheme." They're presenting it as a proof of concept, and planning for the future work that they acknowledge is necessary. Your comment is ill-informed and misleading.
Arathorn 7y ago
This is insanely cool - insertable webrtc streams only just landed in canary (https://www.chromestatus.com/feature/6321945865879552 https://www.chromestatus.com/feature/6321945865879552). Also very cool they’re looking to use Matrix’s libolm Double Ratchet implementation for key exchange, which hopefully will make it easier to integrate Matrix’s e2ee with Jitsi’s in future :)
giancarlostoro 7y ago
Jitsi was the one Jabber client I used a few years back that I liked. I didn't find as many people on Jabber back then as I've seen elsewhere however. I believe you could use OTR alongside it, so you don't even need to trust them, just their implementation / version of OTR (a few more layers to consider I suppose).
- Arathorn 7y ago
  I don’t think this is anything to do with the legacy jitsi xmpp/sip client, but the “jitsi meet” video conferencing app.
  - giancarlostoro 7y ago
    Oh it's been too long if that one's irrelevant.
shadowgovt 7y ago
It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being MITM on encryption? Especially since if you have their keys you already could. Still, very cool technical demo, even if the odds of it displacing something like Zoom are near nil.
- drivingmenuts 7y ago
  At its most basic, encryption should be a thing that just happens, out of sight and mind of the user. Yes, that leaves vulnerability, but people generally don’t want to have to deal with it. Most of us are more interested in getting work done, rather than fiddling with the tools.
  - diablo1 7y ago
    > out of sight and mind of the user Which can be sometimes dangerous as more and more crypto is designed to be set-and-forget. It leaves the windows open for bad actors to exploit such simplicity and introduce backdoors when no-one was looking. Vigilance in managing keys (and integrity of the cryptosystem) is still required.
    - shadowgovt 7y ago
      You can require something people won't do all you want, and it doesn't get done. Cryptographic theory breaks down at the UX layer. If you try to improve security by cycling passwords too frequently, users start writing them on sticky notes tacked to their monitors. If you require users to keep their private keys in their own possession, users lose their private keys, get angry when you can't reconstitute those keys for them, and go use a service that can offer that feature. I think there's a reason the entire ecosystem has moved in the direction of trusted actors who could, in theory, exploit that trust to know everything they can about the signal passing through their trusted zone (with those who trust nobody still operating independently as a fringe minority).
CiPHPerCoder 7y ago
Ah, I they see they're using libolm, as is the Matrix project! I have a number of critiques of libolm that I haven't developed into a practical attack, but are simple enough to fix (if you ignore the massive legacy support and backwards compatibility t̵r̵a̵p̵ ̵t̵h̵e̵y̵'̵v̵e̵ ̵s̵e̵t̵ ̵f̵o̵r̵ ̵t̵h̵e̵m̵s̵e̵l̵v̵e̵s̵ EDIT: see Arathorn's comment below). Libolm is encrypting with AES-CBC [1]. In addition to side-stepping entire classes of attack (i.e. padding oracles), CTR would allow better performance: You can parallelize both encryption and decryption with CTR mode. With CBC mode, you can only parallelize decryption (but not encryption) since the IV for all but the first block is the previous block of ciphertext, which means you'll know the correct IV when decrypting but not when encrypting (since you have to calculate it sequentially). Yes, they HMAC the ciphertext [2]. However, their variable name choice doesn't inspire confidence in its correctness. Furthermore, they truncate the HMAC to 8 byes and attempt to justify the truncation by appending an Ed25519 signature, but that sort of configuration is just begging for a confused deputy scenario, like an old iMessage vulnerability [3]. It's no where near as bad (iMessage eschewed MACs entirely, this still uses a MAC, so it's not exploitable), but it's something that probably would make anyone working in cryptography (and any adjacent fields) give a confused puppy head tilt when they read it. Regarding their ratcheting protocol [4]: Instead of feeding HMAC-SHA256 back into itself at each ratchet step, I'd feel way more comfortable if the protocol did HMAC-SHA512 and used one half of the output to derive encryption/authentication keys and the other half the ratcheting-forward key (instead of one HMAC-SHA256 for both purposes). Using two distinct 256-bit secrets (even if they're generated from the same input at i=0) instead of reusing a secret strengthens the forward secrecy of the entire protocol. HMAC-SHA256: One ring to rule them all (at any given ratchet step). HMAC-SHA512-split: If you (against all odds) guess one of the keys, that doesn't give you the ratchet-forward key too, since they're two distinct keys (albeit generated deterministically from the same input). Nothing I said above is exploitable, otherwise I'd be emailing their security team instead of posting on HN. :) That being said, if the Libolm devs want to shore up the security of their protocol in a future revision, the following changes would go a long way: 1. Use HMAC-SHA-512 and split it in half for the ratcheting step of Olm/Megolm 2. Use AES-CTR instead of AES-CBC 3. Stop truncating MACs [1]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#message-encryption https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me... [2]: https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547ebb3058680a9c3ad88186bb2030da/src/cipher.cpp#L64-96 https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... [3]: https://blog.cryptographyengineering.com/2016/03/21/attack-of-week-apple-imessage/ https://blog.cryptographyengineering.com/2016/03/21/attack-o... [4]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#the-megolm-ratchet-algorithm https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
Vinnl 7y ago
Jitsi has been doing great recently, and it's pretty amazing how many of my now-at-home-friends now reach for Jitsi by default (as opposed to Zoom, which used to be the case) after having been introduced to it just recently. I've never managed to "convert" so many people to something so easily :) However, I'm wondering if anyone on here has become, or works somewhere that has become, a customer of 8x8 [1], the company behind it [2]? They supposedly support Jitsi primarily to 1) get contributions that also make their product better and 2) to advertise their product. I'm somewhat worried about whether 2 is working, and hence whether Jitsi will continue to receive their support. (I'm not affiliated or anything btw, just a happy Jitsi user.) [1] https://www.8x8.com/ https://www.8x8.com/ [2] https://jitsi.org/user-faq/#heading8 https://jitsi.org/user-faq/#heading8
- deleted 7y ago
  [deleted]
- cdolan 7y ago
  I gave my impressions on 8x8 in a different comment below. It got really long and touched upon some things outside the scope of your question so I made it its own top level comment.
- shravj 7y ago
  Although I'm not technically a 8x8 customer, I do use 8x8 Video Meetings which is powered by Jitsi Meet. 8x8 Video Meetings seems to be a completely free and separate product from the rest of 8x8's conferencing solutions and does not require any sort of existing or new 8x8 subscription to use. From what I can tell, it just seems to be a Jitsi Meet instance running on 8x8 infrastructure with 8x8 branding tied in. See here: https://www.8x8.com/products/video-conferencing https://www.8x8.com/products/video-conferencing
- throwaway7281 7y ago
  Open source one of the most empowering paradigms. Here is a list of people and organizations running their own servers: https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instances https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instance...
shawnz 7y ago
I see a lot of blocky patterns in the encrypted video streams... isn't that indicative of encryption weaknesses?
- philcrump 7y ago
  I think, I haven't looked at their implementation; they'll be an artifact of piping the encrypted/mis-decrypted stream into a video decoder. A lot of video coding techniques use variable-size blocks to describe changes to areas of the image, so it's reasonable that piping pseudo-random data into the decoder would produce some noticeable block shapes.
- jaywalk 7y ago
  I think it's more a side effect of how video codecs try to make sense of bad data.
- saghul 7y ago
  We’ve kept the entire packet header unencrypted so the effect is more visible. The final implementation will just leave the minimum required bytes (1 or 2) of the header unencrypted.
  - shawnz 7y ago
    Interesting, thanks for the information. And also thank you for working on this important technology.
jcims 7y ago
Tech support question haha. I run Jitsi Meet (the service at meet.jit.si) on an iPad that I bought last year. After about an hour the audio completely fails. No audio in. No audio out. I can't really tell if it's something with the app or if it's my terrible little dsl router/nat box dropping the audio stream. I don't have this problem on the desktop or laptop clients, just the iPad, so I'm guessing it's the app...but it could be that it works differently on the network. Anyone see similar?
- jcims 7y ago
  welp...
pal_9000 7y ago
Jitsi is on a roll! By the way, Does anyone know the challenging part of e2e in video chats? Thinking out of intuition, it would be keys are exchanged during handshake and binary data is decoded on the clients? I'm just wondering how could Zoom miss it?
- Arathorn 7y ago
  The challenging bits are: * How do you handle non-encrypted participants (e.g. people dialling in from the PSTN?) * Up until this week, you haven't been able to intercept WebRTC streams for doing E2EE if running in-browser. (Zoom however doesn't use WebRTC, so they don't have this excuse). * Do you have a safe place to store the keys, and manage user identity?
- georgyo 7y ago
  I cannot think how you could possibly do the key exchange securely and automatically, if you want to give a link to someone and have it "just work". If all you have is the URL, then the server sees the encryption key. Video conferencing also rarely has users register. So there isn't a way to validate users either. And even if they did register and users didn't care about the extra friction, multiple devices means either the server stores your private key, or you have many keys which is much harder to verify. E2EE is much easier on phones, which is why Signal is so good. The identity is your phone number, and you can only have one key associate with your number. That key never leaves your device. Conceptually easy. Video conferencing has none of those advantages, and I don't know how you would make it conceptually easy for users without reducing the security.
  - waterhouse 7y ago
    I don't know much about the broader context, but to this part: > If all you have is the URL, then the server sees the encryption key. Not necessarily. It's possible to put the key after a "#" in the URL, which allows client-side code to use it without sending it to the server. This technique is used at ZeroBin, among other places. (Edit: This is actually done in the video in the OP as well.)
  - 7y ago
cdolan 7y ago
I just learned Jitsi is supported in part by 8x8. That gives me concern and I'll have to research the ties there before switiching ti Jitsi. I'm making this a top level comment given its length, but I wrote this after seeing Vinnl's question on 8x8. I was an 8x8 customer for about 10 years as a small/medium business. I would never buy from them again. I now use Zoom, but am considering switching given the recent privacy revelations. Here was my 8x8 customer journey. Stick around - at the end I highlight their shifty auto-renewal contracting practices and dark patterns to force you to stay. 2011-2015: Startup phase. Was great to get a VOIP phone at this time! Still needed desktop phones from Polycom for the system to work well. Zero online meetings as far as I knew. Acceptable product, was happy enough. Around 2015 or so through about 2019: Newer versions of iOS, that allowed for better phone integration, began to pop up. 8x8 was viable as a mobile-only VOIP provider, but lacked quality features for a growing business: - The ability to retrieve recorded calls from a Mac required you log in with a certain version of Safari that had Flash Enabled. Then, you could only download X MB of calls at a time. All of this had to be done manually. There was no API for reporting, jus CSV exports. This made calculating total customer service costs for our business a massive pain. - If you edited your extensions online, ALL OF YOUR CALL RECORDINGS SINCE THE OPENING OF YOUR ACCOUNT ARE DELETED. We found this out the hard way, and there was no warning that adjusting extensions would have this impact. 2019 Q1 thru Q3 I wanted to switch to Zoom, because the 8x8 apps had poor usability from our experience, specifically as a remote-only setup. I did not trust that a video product from 8x8 would be acceptable, and I enjoyed using Zoom with other organizations I am involved with. Porting phone numbers to Zoom was really easy. It requires about 1-2 weeks of paperwork and processing time (no matter who you are porting numbers with I think this is the default). However - 8x8 tried to block the transfer for about 20% of our numbers, saying that the information we provided was incorrect. After days of back and forth, all the while our numbers were unavailable for use and causing operational problems, the case was escalated and resolved, simply because a new person read the original forms we submitted and processed it correctly. On the 8x8 contract & account management dark patterns: 8x8 did not have a copy of the PDF of our agreement. I did have a copy. The contract was for 3 years with 12 month auto-renewal clauses. Multiple times in 2018 I requested my account manager offer new pricing, as our rates had doubled from $25/number to $50/number in just 1 year. The cost was out of control. They never did offer pricing, but continually played the Car Salesman move of "Let me see what I can get my finance department to approve", come back with a meager 5% discount, rinse, repeat... The account manager would passively threaten that they will take my account to month to month, "but the pricing controls will no longer be in place and your rates could rise". Big deal, I thought, my rates are already skyrocketing! Multiple times in 2016-2018 I wrote to them asking if I had an auto-renewal. They would not answer this question over email, but instead forced me to call in. When I called in ("...to a recorded line, for quality assurance purposes..."), they would tell me I did have an auto renewal in August each year for 12 months. I would tell them over the phone to mark that I wish to cancel my auto renewal and continue on a month to month basis. I would follow up with my 8x8 Account Manager that I was told over the phone by the 8x8 Billing Representative that my company did not have an auto renewal. My account manager never acknowledge these messages. 2019 Q3: I submitted a cancellation notice to 8x8. They wanted to charge me an Early Termination penalty of more than half the year, claiming I was in a 1 year auto renewal. It took me over a dozen phone calls for more than an hour each to get this resolved. I've come to expect garbage contract patterns from legacy companies. However... THE WORST PART ABOUT THIS in my opinion was that calls 1 through 11 to 8x8 customer support and billing to resolve this were not successful, in my opinion, because I was being very nice and understanding to the support person on the other line. ONLY when I started threatening legal action, "I do not care what the script is telling you to say, I must talk to a manager", etc, did I get someone to waive these cancellation fees and allow me to transfer my numbers. I have done customer service oriented work, I understand the drain it can have on people. I try to be overly nice to anyone I have to call into because so many people are abusive to the support agents trying to assist them. But at the end of the day, wether its Apple or 8x8, the only success I've had at getting what I need in situations where the company is clearly playing hide-the-ball, is to be threatening to the minimum wage worker on the other end of the line. And that is my take away - you can tell a lot about a company from how they arm (or bind & toss overboard) their front-line support agents to deal with a terminating customer contract.
kodablah 7y ago
I have a naive question as I'm toying w/ a similar WebRTC project myself. Since all browsers support h264/opus, can I just reasonably ask each client to send 720p to my WebRTC peer which is really a server before I relay it? Then, can't we just use naive e2e encryption with any extra encoding/decoding? Meaning, in my TransformStream, can I just window.subtle.encrypt on the way out and window.subtle.decrypt on the way in? Is it due to the fact that the insertable streams have to remain in their video format? Pardon my ignorance. This naive approach does assume everyone can at least handle the download speeds of the group's video and the upload speed of their own.
manishsharan 7y ago
Love Jitsi but dont try to run this on AWS EC2 -- the network charges quickly add up. I had set Jitsi videobridge for my kid's friends and their friends -- the network charges quickly added up before I shut it down.
- miglmj 7y ago
  Networked applications like this really expose the real money drain in AWS and other cloud services, network charges particularly network egress rates.
- capableweb 7y ago
  Try a host that doesn't charge for bandwidth. Dedicated servers at Hetzner and/or OVH doesn't charge this imaginary fee so you can sleep well and just pay a static sum each month.
  - sigwinch28 7y ago
    Precisely. Hetzner can provide a dedicated server with an Intel Core i7-2600, 16 GB RAM, and 2x3TB spinning disks for 29,00 €/month before tax with unlimited traffic via their server auction site for orphaned servers [0]. Other Hetzner and many OVH offerings have traffic caps, but these are in the region of ~10TB/month. [0]: https://www.hetzner.com/sb/ https://www.hetzner.com/sb/
CrankyBear 7y ago
Oh please. It's a demo. Moving on.
mbochenek 7y ago
I love the fact that it's open source, and well documented. I am currently hosting my own instance at https://jitsi.mastodo.ch/ https://jitsi.mastodo.ch/ and I plan to offer it as a free alternative to zoom, citrix, etc.
christefano 7y ago
Sad to see this is dependent on an extension to WebRTC that’s (currently) Chrome / Chromium-only. It’s still a proposed API, and I don’t see when this will be supported by any other browsers.
- garmaine 7y ago
  Really, really sad. I’m not going to run Chrome for this one application.
  - sigwinch28 7y ago
    I'm not sure if you are aware of the difference, but you can use Chromium instead of Chrome. I am mainly a Firefox user on NixOS, but for running Chrom{e,ium} I find that Firejail [0] is a good option. For example, to run chromium in "store" mode and point it to the demo jitsi instance: firejail --profile=chromium chromium --app="https://meet.jit.si" In reality, I combine this with `nix-shell` and set it as a shell alias, since Chromium isn't something I use regularly: nix-shell -p chromium --run "firejail --profile=chromium chromium --app=\"https://meet.jit.si\"" The `--app` option removes browser controls, so it almost behaves like an Electron application. [0]: https://github.com/netblue30/firejail https://github.com/netblue30/firejail
    - barbs 7y ago
      Or you can download the Electron app here https://github.com/jitsi/jitsi-meet-electron https://github.com/jitsi/jitsi-meet-electron
      - sigwinch28 7y ago
        Didn't realise they had one! Might be more convenient than my shell aliases :)
    - garmaine 7y ago
      I’m not going to run a different browser for one application. I don’t even install anything derived from Chrome in my computer, and I’m not going to change that policy.
exabrial 7y ago
As long as I can disable this, good. I need performance over E2EE, much like many others. We face far more threats from poor communication being distant than we do from an threat where someone gets past our VPN, Firewall, breaks TLS encryption, gets into our VPS and private server, and silently participates in our meetings.
tinus_hn 7y ago
Does this only work in Chrome? Or why are they using the Chrome logo in the graphs?
- saghul 7y ago
  The "insertable streams" API is currenly only available in Chrome.
coinward 7y ago
A bit random, but I'd really like to manage video calls through a browser extension. Am I alone in this? Seems unnecessary to move in between apps, couldnt we be hopping in and out of rooms without leaving the browser?
sigwinch28 7y ago
This is huge for decoupling zoom clients from zoom backend servers. In theory, using a fixed/trusted set of client assets (javascript+html, e.g. an electron wrapper) allows groups of users to choose a Jitsi "backend" provider that they don't even trust if the encryption key is never sent to the server (and can't be, i.e. it is never in the URL hash). Since the video is e2e-encrypted and in theory the server never has to be given the key, this would allow people to purchase hosting services from untrusted providers or spin up a VM in a public cloud with the confidence that the content of their conversations is not available to the provider. Yes, we could just argue that this is XMPP servers and Pidgin all over again (in fact, Jitsi uses an XMPP server internally), but the modern UI and the timing w.r.t. COVID-19 lockdowns and Zoom privacy issues is fantastic.
crazygringo 7y ago
I'm actually really curious as to whether verifiable E2EE is possible in normal business videoconferencing -- if someone here can enlighten me I'd really appreciate it. It seems clear that there has to be a single key, rather than separate keys for each pair of participants, since in a large meeting we need all video streams running through a server and everyone receiving the same streams, for manageable upload bandwidth. Also, many participants often cannot peer directly due to NAT etc. But therefore... as long as you're trusting the server with key distribution/management in the first place... don't you necessarily have to simply trust that the server isn't peeking? That by necessity, since anyone else can join the call and get the decryption key from any of the peers... that the server can too, whether by MITM attack, a "fake participant" that joins for a millisecond but doesn't appear in UX, etc.? That unless you actually have the capability of auditing the server and the code it's running, E2EE doesn't actually give you any concrete guarantees whatsoever? You've just got to trust? Which at the end of the day, is no different from trusting them not to peek at transport encryption? Of course you can run your own Jitsi server. But if you've already got control over your servers then you might as well just be using transport encryption anyways, since you trust yourself -- right? (Obviously if you come up with your own keys and send them to participants via a separate channel of communication then it's fine -- but obviously that's not something regular users are ever going to do.) Would love to know if I'm misunderstanding something here -- if the newfound significance of E2EE in videoconferencing is just due to Zoom falsely advertising it, or if it's actually a realistic goal.
- tpolzer 7y ago
  Key distribution is a problem, yes (as discussed in other comments here). Upload bandwidth isn't so much of a problem with the number of participants, as you of course wouldn't encrypt the whole data stream separately for each peer. Instead, you would encrypt it with a rotating symmetrical key that you can then safely exchange with all peers (at negligible bandwidth cost). You would still depend on the server to replicate your encrypted stream (and do NAT traversal etc), but it wouldn't be able to peek inside. A separate problem is that you usually want your server to actually create reencoded video of your stream for participants with bad internet. There's potentially some ways to do that without server involvement with some clever video encoding (so that instead of reencoding you can just throw away some chunks), but afaik there's nothing production ready for video codecs here.
PureParadigm 7y ago
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 7y 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?
yeuking 7y ago
better than Zoom

617 points by jrepinc 7y ago

emilfihlman 7y ago

>GET parameter Yes, it's convenient. But to tout that as what a well designed encryption scheme should look like? Nah.

bflesch 7y ago
What is your alternative suggestion? In a browser-based video chat scenario you are ultimately assuming some level of browser security and that the clients are trusted. What they propose is an E2E encryption, e.g. Zoom / MS Teams are unable to decrypt your conversations. Obviously, if you choose a weak key, they can just store the stream and crack it later.
giancarlostoro 7y ago
It was a hash mark, only the client got that value (specifically JavaScript). Note how his page did not reload when he hit enter. Had it been a GET request, it would of refreshed.
CrazyStat 7y ago
From the link: > In order to enable quick demos of the feature we allowed for e2ee keys to be passed to Jitsi Meet via a URL parameter. > IMPORTANT NOTE: This is a demo of an e2e encrypted call and the feature is NOT YET intended for general availability, so play with it all you want, but, for now, in matters where security is paramount we still recommend deploying your own Jitsi Meet instance. > As we already pointed out, passing keys as URL parameters is a demo thing only. Aside from being impractical it also carries risks given that URL params are stored in browser history. > Our next step is therefore to work out exactly how key management and exchange would work. We expect we will be using The Double Ratchet Algorithm through libolm but the details are still to be ironed out. They're not touting passing the keys in a URL parameter as a "well designed encryption scheme." They're presenting it as a proof of concept, and planning for the future work that they acknowledge is necessary. Your comment is ill-informed and misleading.

Arathorn 7y ago

This is insanely cool - insertable webrtc streams only just landed in canary (https://www.chromestatus.com/feature/6321945865879552 https://www.chromestatus.com/feature/6321945865879552). Also very cool they’re looking to use Matrix’s libolm Double Ratchet implementation for key exchange, which hopefully will make it easier to integrate Matrix’s e2ee with Jitsi’s in future :)

giancarlostoro 7y ago

Jitsi was the one Jabber client I used a few years back that I liked. I didn't find as many people on Jabber back then as I've seen elsewhere however. I believe you could use OTR alongside it, so you don't even need to trust them, just their implementation / version of OTR (a few more layers to consider I suppose).

Arathorn 7y ago
I don’t think this is anything to do with the legacy jitsi xmpp/sip client, but the “jitsi meet” video conferencing app.
- giancarlostoro 7y ago
  Oh it's been too long if that one's irrelevant.

shadowgovt 7y ago

It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being MITM on encryption? Especially since if you have their keys you already could. Still, very cool technical demo, even if the odds of it displacing something like Zoom are near nil.

drivingmenuts 7y ago
At its most basic, encryption should be a thing that just happens, out of sight and mind of the user. Yes, that leaves vulnerability, but people generally don’t want to have to deal with it. Most of us are more interested in getting work done, rather than fiddling with the tools.
- diablo1 7y ago
  > out of sight and mind of the user Which can be sometimes dangerous as more and more crypto is designed to be set-and-forget. It leaves the windows open for bad actors to exploit such simplicity and introduce backdoors when no-one was looking. Vigilance in managing keys (and integrity of the cryptosystem) is still required.
  - shadowgovt 7y ago
    You can require something people won't do all you want, and it doesn't get done. Cryptographic theory breaks down at the UX layer. If you try to improve security by cycling passwords too frequently, users start writing them on sticky notes tacked to their monitors. If you require users to keep their private keys in their own possession, users lose their private keys, get angry when you can't reconstitute those keys for them, and go use a service that can offer that feature. I think there's a reason the entire ecosystem has moved in the direction of trusted actors who could, in theory, exploit that trust to know everything they can about the signal passing through their trusted zone (with those who trust nobody still operating independently as a fringe minority).

CiPHPerCoder 7y ago

Ah, I they see they're using libolm, as is the Matrix project! I have a number of critiques of libolm that I haven't developed into a practical attack, but are simple enough to fix (if you ignore the massive legacy support and backwards compatibility t̵r̵a̵p̵ ̵t̵h̵e̵y̵'̵v̵e̵ ̵s̵e̵t̵ ̵f̵o̵r̵ ̵t̵h̵e̵m̵s̵e̵l̵v̵e̵s̵ EDIT: see Arathorn's comment below). Libolm is encrypting with AES-CBC [1]. In addition to side-stepping entire classes of attack (i.e. padding oracles), CTR would allow better performance: You can parallelize both encryption and decryption with CTR mode. With CBC mode, you can only parallelize decryption (but not encryption) since the IV for all but the first block is the previous block of ciphertext, which means you'll know the correct IV when decrypting but not when encrypting (since you have to calculate it sequentially). Yes, they HMAC the ciphertext [2]. However, their variable name choice doesn't inspire confidence in its correctness. Furthermore, they truncate the HMAC to 8 byes and attempt to justify the truncation by appending an Ed25519 signature, but that sort of configuration is just begging for a confused deputy scenario, like an old iMessage vulnerability [3]. It's no where near as bad (iMessage eschewed MACs entirely, this still uses a MAC, so it's not exploitable), but it's something that probably would make anyone working in cryptography (and any adjacent fields) give a confused puppy head tilt when they read it. Regarding their ratcheting protocol [4]: Instead of feeding HMAC-SHA256 back into itself at each ratchet step, I'd feel way more comfortable if the protocol did HMAC-SHA512 and used one half of the output to derive encryption/authentication keys and the other half the ratcheting-forward key (instead of one HMAC-SHA256 for both purposes). Using two distinct 256-bit secrets (even if they're generated from the same input at i=0) instead of reusing a secret strengthens the forward secrecy of the entire protocol. HMAC-SHA256: One ring to rule them all (at any given ratchet step). HMAC-SHA512-split: If you (against all odds) guess one of the keys, that doesn't give you the ratchet-forward key too, since they're two distinct keys (albeit generated deterministically from the same input). Nothing I said above is exploitable, otherwise I'd be emailing their security team instead of posting on HN. :) That being said, if the Libolm devs want to shore up the security of their protocol in a future revision, the following changes would go a long way: 1. Use HMAC-SHA-512 and split it in half for the ratcheting step of Olm/Megolm 2. Use AES-CTR instead of AES-CBC 3. Stop truncating MACs [1]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#message-encryption https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me... [2]: https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547ebb3058680a9c3ad88186bb2030da/src/cipher.cpp#L64-96 https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... [3]: https://blog.cryptographyengineering.com/2016/03/21/attack-of-week-apple-imessage/ https://blog.cryptographyengineering.com/2016/03/21/attack-o... [4]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#the-megolm-ratchet-algorithm https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...

Vinnl 7y ago

Jitsi has been doing great recently, and it's pretty amazing how many of my now-at-home-friends now reach for Jitsi by default (as opposed to Zoom, which used to be the case) after having been introduced to it just recently. I've never managed to "convert" so many people to something so easily :) However, I'm wondering if anyone on here has become, or works somewhere that has become, a customer of 8x8 [1], the company behind it [2]? They supposedly support Jitsi primarily to 1) get contributions that also make their product better and 2) to advertise their product. I'm somewhat worried about whether 2 is working, and hence whether Jitsi will continue to receive their support. (I'm not affiliated or anything btw, just a happy Jitsi user.) [1] https://www.8x8.com/ https://www.8x8.com/ [2] https://jitsi.org/user-faq/#heading8 https://jitsi.org/user-faq/#heading8

deleted 7y ago
[deleted]
cdolan 7y ago
I gave my impressions on 8x8 in a different comment below. It got really long and touched upon some things outside the scope of your question so I made it its own top level comment.
shravj 7y ago
Although I'm not technically a 8x8 customer, I do use 8x8 Video Meetings which is powered by Jitsi Meet. 8x8 Video Meetings seems to be a completely free and separate product from the rest of 8x8's conferencing solutions and does not require any sort of existing or new 8x8 subscription to use. From what I can tell, it just seems to be a Jitsi Meet instance running on 8x8 infrastructure with 8x8 branding tied in. See here: https://www.8x8.com/products/video-conferencing https://www.8x8.com/products/video-conferencing
throwaway7281 7y ago
Open source one of the most empowering paradigms. Here is a list of people and organizations running their own servers: https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instances https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instance...

shawnz 7y ago

I see a lot of blocky patterns in the encrypted video streams... isn't that indicative of encryption weaknesses?

philcrump 7y ago
I think, I haven't looked at their implementation; they'll be an artifact of piping the encrypted/mis-decrypted stream into a video decoder. A lot of video coding techniques use variable-size blocks to describe changes to areas of the image, so it's reasonable that piping pseudo-random data into the decoder would produce some noticeable block shapes.
jaywalk 7y ago
I think it's more a side effect of how video codecs try to make sense of bad data.
saghul 7y ago
We’ve kept the entire packet header unencrypted so the effect is more visible. The final implementation will just leave the minimum required bytes (1 or 2) of the header unencrypted.
- shawnz 7y ago
  Interesting, thanks for the information. And also thank you for working on this important technology.

jcims 7y ago

Tech support question haha. I run Jitsi Meet (the service at meet.jit.si) on an iPad that I bought last year. After about an hour the audio completely fails. No audio in. No audio out. I can't really tell if it's something with the app or if it's my terrible little dsl router/nat box dropping the audio stream. I don't have this problem on the desktop or laptop clients, just the iPad, so I'm guessing it's the app...but it could be that it works differently on the network. Anyone see similar?

jcims 7y ago
welp...

pal_9000 7y ago

Jitsi is on a roll! By the way, Does anyone know the challenging part of e2e in video chats? Thinking out of intuition, it would be keys are exchanged during handshake and binary data is decoded on the clients? I'm just wondering how could Zoom miss it?

Arathorn 7y ago
The challenging bits are: * How do you handle non-encrypted participants (e.g. people dialling in from the PSTN?) * Up until this week, you haven't been able to intercept WebRTC streams for doing E2EE if running in-browser. (Zoom however doesn't use WebRTC, so they don't have this excuse). * Do you have a safe place to store the keys, and manage user identity?
georgyo 7y ago
I cannot think how you could possibly do the key exchange securely and automatically, if you want to give a link to someone and have it "just work". If all you have is the URL, then the server sees the encryption key. Video conferencing also rarely has users register. So there isn't a way to validate users either. And even if they did register and users didn't care about the extra friction, multiple devices means either the server stores your private key, or you have many keys which is much harder to verify. E2EE is much easier on phones, which is why Signal is so good. The identity is your phone number, and you can only have one key associate with your number. That key never leaves your device. Conceptually easy. Video conferencing has none of those advantages, and I don't know how you would make it conceptually easy for users without reducing the security.
- waterhouse 7y ago
  I don't know much about the broader context, but to this part: > If all you have is the URL, then the server sees the encryption key. Not necessarily. It's possible to put the key after a "#" in the URL, which allows client-side code to use it without sending it to the server. This technique is used at ZeroBin, among other places. (Edit: This is actually done in the video in the OP as well.)
- 7y ago

cdolan 7y ago

I just learned Jitsi is supported in part by 8x8. That gives me concern and I'll have to research the ties there before switiching ti Jitsi. I'm making this a top level comment given its length, but I wrote this after seeing Vinnl's question on 8x8. I was an 8x8 customer for about 10 years as a small/medium business. I would never buy from them again. I now use Zoom, but am considering switching given the recent privacy revelations. Here was my 8x8 customer journey. Stick around - at the end I highlight their shifty auto-renewal contracting practices and dark patterns to force you to stay. 2011-2015: Startup phase. Was great to get a VOIP phone at this time! Still needed desktop phones from Polycom for the system to work well. Zero online meetings as far as I knew. Acceptable product, was happy enough. Around 2015 or so through about 2019: Newer versions of iOS, that allowed for better phone integration, began to pop up. 8x8 was viable as a mobile-only VOIP provider, but lacked quality features for a growing business: - The ability to retrieve recorded calls from a Mac required you log in with a certain version of Safari that had Flash Enabled. Then, you could only download X MB of calls at a time. All of this had to be done manually. There was no API for reporting, jus CSV exports. This made calculating total customer service costs for our business a massive pain. - If you edited your extensions online, ALL OF YOUR CALL RECORDINGS SINCE THE OPENING OF YOUR ACCOUNT ARE DELETED. We found this out the hard way, and there was no warning that adjusting extensions would have this impact. 2019 Q1 thru Q3 I wanted to switch to Zoom, because the 8x8 apps had poor usability from our experience, specifically as a remote-only setup. I did not trust that a video product from 8x8 would be acceptable, and I enjoyed using Zoom with other organizations I am involved with. Porting phone numbers to Zoom was really easy. It requires about 1-2 weeks of paperwork and processing time (no matter who you are porting numbers with I think this is the default). However - 8x8 tried to block the transfer for about 20% of our numbers, saying that the information we provided was incorrect. After days of back and forth, all the while our numbers were unavailable for use and causing operational problems, the case was escalated and resolved, simply because a new person read the original forms we submitted and processed it correctly. On the 8x8 contract & account management dark patterns: 8x8 did not have a copy of the PDF of our agreement. I did have a copy. The contract was for 3 years with 12 month auto-renewal clauses. Multiple times in 2018 I requested my account manager offer new pricing, as our rates had doubled from $25/number to $50/number in just 1 year. The cost was out of control. They never did offer pricing, but continually played the Car Salesman move of "Let me see what I can get my finance department to approve", come back with a meager 5% discount, rinse, repeat... The account manager would passively threaten that they will take my account to month to month, "but the pricing controls will no longer be in place and your rates could rise". Big deal, I thought, my rates are already skyrocketing! Multiple times in 2016-2018 I wrote to them asking if I had an auto-renewal. They would not answer this question over email, but instead forced me to call in. When I called in ("...to a recorded line, for quality assurance purposes..."), they would tell me I did have an auto renewal in August each year for 12 months. I would tell them over the phone to mark that I wish to cancel my auto renewal and continue on a month to month basis. I would follow up with my 8x8 Account Manager that I was told over the phone by the 8x8 Billing Representative that my company did not have an auto renewal. My account manager never acknowledge these messages. 2019 Q3: I submitted a cancellation notice to 8x8. They wanted to charge me an Early Termination penalty of more than half the year, claiming I was in a 1 year auto renewal. It took me over a dozen phone calls for more than an hour each to get this resolved. I've come to expect garbage contract patterns from legacy companies. However... THE WORST PART ABOUT THIS in my opinion was that calls 1 through 11 to 8x8 customer support and billing to resolve this were not successful, in my opinion, because I was being very nice and understanding to the support person on the other line. ONLY when I started threatening legal action, "I do not care what the script is telling you to say, I must talk to a manager", etc, did I get someone to waive these cancellation fees and allow me to transfer my numbers. I have done customer service oriented work, I understand the drain it can have on people. I try to be overly nice to anyone I have to call into because so many people are abusive to the support agents trying to assist them. But at the end of the day, wether its Apple or 8x8, the only success I've had at getting what I need in situations where the company is clearly playing hide-the-ball, is to be threatening to the minimum wage worker on the other end of the line. And that is my take away - you can tell a lot about a company from how they arm (or bind & toss overboard) their front-line support agents to deal with a terminating customer contract.

kodablah 7y ago

I have a naive question as I'm toying w/ a similar WebRTC project myself. Since all browsers support h264/opus, can I just reasonably ask each client to send 720p to my WebRTC peer which is really a server before I relay it? Then, can't we just use naive e2e encryption with any extra encoding/decoding? Meaning, in my TransformStream, can I just window.subtle.encrypt on the way out and window.subtle.decrypt on the way in? Is it due to the fact that the insertable streams have to remain in their video format? Pardon my ignorance. This naive approach does assume everyone can at least handle the download speeds of the group's video and the upload speed of their own.

manishsharan 7y ago

Love Jitsi but dont try to run this on AWS EC2 -- the network charges quickly add up. I had set Jitsi videobridge for my kid's friends and their friends -- the network charges quickly added up before I shut it down.

miglmj 7y ago
Networked applications like this really expose the real money drain in AWS and other cloud services, network charges particularly network egress rates.
capableweb 7y ago
Try a host that doesn't charge for bandwidth. Dedicated servers at Hetzner and/or OVH doesn't charge this imaginary fee so you can sleep well and just pay a static sum each month.
- sigwinch28 7y ago
  Precisely. Hetzner can provide a dedicated server with an Intel Core i7-2600, 16 GB RAM, and 2x3TB spinning disks for 29,00 €/month before tax with unlimited traffic via their server auction site for orphaned servers [0]. Other Hetzner and many OVH offerings have traffic caps, but these are in the region of ~10TB/month. [0]: https://www.hetzner.com/sb/ https://www.hetzner.com/sb/

CrankyBear 7y ago

Oh please. It's a demo. Moving on.

mbochenek 7y ago

I love the fact that it's open source, and well documented. I am currently hosting my own instance at https://jitsi.mastodo.ch/ https://jitsi.mastodo.ch/ and I plan to offer it as a free alternative to zoom, citrix, etc.

christefano 7y ago

Sad to see this is dependent on an extension to WebRTC that’s (currently) Chrome / Chromium-only. It’s still a proposed API, and I don’t see when this will be supported by any other browsers.

garmaine 7y ago
Really, really sad. I’m not going to run Chrome for this one application.
- sigwinch28 7y ago
  I'm not sure if you are aware of the difference, but you can use Chromium instead of Chrome. I am mainly a Firefox user on NixOS, but for running Chrom{e,ium} I find that Firejail [0] is a good option. For example, to run chromium in "store" mode and point it to the demo jitsi instance: firejail --profile=chromium chromium --app="https://meet.jit.si" In reality, I combine this with `nix-shell` and set it as a shell alias, since Chromium isn't something I use regularly: nix-shell -p chromium --run "firejail --profile=chromium chromium --app=\"https://meet.jit.si\"" The `--app` option removes browser controls, so it almost behaves like an Electron application. [0]: https://github.com/netblue30/firejail https://github.com/netblue30/firejail
  - barbs 7y ago
    Or you can download the Electron app here https://github.com/jitsi/jitsi-meet-electron https://github.com/jitsi/jitsi-meet-electron
    - sigwinch28 7y ago
      Didn't realise they had one! Might be more convenient than my shell aliases :)
  - garmaine 7y ago
    I’m not going to run a different browser for one application. I don’t even install anything derived from Chrome in my computer, and I’m not going to change that policy.

exabrial 7y ago

As long as I can disable this, good. I need performance over E2EE, much like many others. We face far more threats from poor communication being distant than we do from an threat where someone gets past our VPN, Firewall, breaks TLS encryption, gets into our VPS and private server, and silently participates in our meetings.

tinus_hn 7y ago

Does this only work in Chrome? Or why are they using the Chrome logo in the graphs?

saghul 7y ago
The "insertable streams" API is currenly only available in Chrome.

coinward 7y ago

A bit random, but I'd really like to manage video calls through a browser extension. Am I alone in this? Seems unnecessary to move in between apps, couldnt we be hopping in and out of rooms without leaving the browser?

sigwinch28 7y ago

This is huge for decoupling zoom clients from zoom backend servers. In theory, using a fixed/trusted set of client assets (javascript+html, e.g. an electron wrapper) allows groups of users to choose a Jitsi "backend" provider that they don't even trust if the encryption key is never sent to the server (and can't be, i.e. it is never in the URL hash). Since the video is e2e-encrypted and in theory the server never has to be given the key, this would allow people to purchase hosting services from untrusted providers or spin up a VM in a public cloud with the confidence that the content of their conversations is not available to the provider. Yes, we could just argue that this is XMPP servers and Pidgin all over again (in fact, Jitsi uses an XMPP server internally), but the modern UI and the timing w.r.t. COVID-19 lockdowns and Zoom privacy issues is fantastic.

crazygringo 7y ago

I'm actually really curious as to whether verifiable E2EE is possible in normal business videoconferencing -- if someone here can enlighten me I'd really appreciate it. It seems clear that there has to be a single key, rather than separate keys for each pair of participants, since in a large meeting we need all video streams running through a server and everyone receiving the same streams, for manageable upload bandwidth. Also, many participants often cannot peer directly due to NAT etc. But therefore... as long as you're trusting the server with key distribution/management in the first place... don't you necessarily have to simply trust that the server isn't peeking? That by necessity, since anyone else can join the call and get the decryption key from any of the peers... that the server can too, whether by MITM attack, a "fake participant" that joins for a millisecond but doesn't appear in UX, etc.? That unless you actually have the capability of auditing the server and the code it's running, E2EE doesn't actually give you any concrete guarantees whatsoever? You've just got to trust? Which at the end of the day, is no different from trusting them not to peek at transport encryption? Of course you can run your own Jitsi server. But if you've already got control over your servers then you might as well just be using transport encryption anyways, since you trust yourself -- right? (Obviously if you come up with your own keys and send them to participants via a separate channel of communication then it's fine -- but obviously that's not something regular users are ever going to do.) Would love to know if I'm misunderstanding something here -- if the newfound significance of E2EE in videoconferencing is just due to Zoom falsely advertising it, or if it's actually a realistic goal.

tpolzer 7y ago
Key distribution is a problem, yes (as discussed in other comments here). Upload bandwidth isn't so much of a problem with the number of participants, as you of course wouldn't encrypt the whole data stream separately for each peer. Instead, you would encrypt it with a rotating symmetrical key that you can then safely exchange with all peers (at negligible bandwidth cost). You would still depend on the server to replicate your encrypted stream (and do NAT traversal etc), but it wouldn't be able to peek inside. A separate problem is that you usually want your server to actually create reencoded video of your stream for participants with bad internet. There's potentially some ways to do that without server involvement with some clever video encoding (so that instead of reencoding you can just throw away some chunks), but afaik there's nothing production ready for video codecs here.

PureParadigm 7y ago

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 7y 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?

yeuking 7y ago

better than Zoom