The firm I work for uses Cisco Webex and the associated comms suite. It’s an enterprise solution, so I’ve no choice in what I use day to day.
None of this is due Covid though – it (and other enterprise solutions before it) has been a key part of my working life for years.
Peter wrote:
There have been some hacking concerns with Zoom in the past. It is important that the executable for Windows or a Mac are downloaded from zoom.us and not by clicking on some link. Especially for the Mac which suffered from dodgy versions in years past.
Peter, the issue in the past with Zoom on “the Mac” was not dodgy versions, but
That is, however, history. It got picked up, which is a good thing.
The biggest weakness by far, of any conferencing system, is authenticating the participants. If you have a conference of say 100, you can’t (practically). Even if you have a waiting room, and the 101th turns up in there, you are gonna let him in, aren’t you? 
Then he can record the session and put it on youtube.
Also every system is vulnerable via access to the server. I don’t know of any system which is end to end encrypted for everyone. It would mean your outgoing video stream being multiple encrypted, so with 100 people it would be encrypted separately with the public key of the other 99, so your 1mbps outgoing data rate would become 99mbps. This is also why groups on whatsapp, telegram, etc are not end to end encrypted. Only one-to-one chats are.
And if you allow people to turn off their webcams then you can forget security totally. It is also poor courtesy to anyone who makes an effort to do a presentation.
Peter wrote:
That is, however, history. It got picked up, which is a good thing.
The Zoom company showed such a bad attitude that I just don’t trust them anymore that there is not another thing lurking that they know about, but just refuse to fix.
Peter wrote:
Also every system is vulnerable via access to the server. I don’t know of any system which is end to end encrypted for everyone.
It is harder, but it can be done. Jitsi is end-to-end encrypted in its very latest newest version (or is it the beta development version… not sure any more). Zoom claims to be, for paying customers only.
Peter wrote:
so with 100 people it would be encrypted separately with the public key of the other 99, so your 1mbps outgoing data rate would become 99mbps.
No. The stream is encrypted with one symmetric cipher key, and only that key is sent to the other 99, so the extra bandwidth is only negotiating public key crypto establishment with the other 99; the stream is sent only once. When someone joins, the other 100 negotiate crypto with him and send him/her their symmetric cipher encryption key. If the system is designed extra well, when someone leaves the conference, everybody rotates their symmetric key and sends everybody still present their new key, and a quadratic (but small) bandwidth cost is paid at each such event.
Peter wrote:
The biggest weakness by far, of any conferencing system, is authenticating the participants.
Yes.
Without any registration and absolutely simple to use: wonder.me
No costs at all, no registration for the participants.
One has to set up a room, share the link, set up a password for the participants and then you can meet like on a party there, as long as you like.
Chrome is recommended, but it works with other browsers too.
The stream is encrypted with one symmetric cipher key, and only that key is sent to the other 99
What about server access (i.e. MITM attack)?
Peter wrote:
What about server access (i.e. MITM attack)?
It looks to me that the person that decides who is admitted to the conference (and thus anybody penetrating their computer) is indeed in a position to allow… anybody to join, and thus everyone will share their encryption key with that new person, which will permit to decrypt future (and past) video stream of that conference. I’d say the only way to avoid that is if each participant approves of each new participant, but that would be too onerous.
If one wants to protect about “past video stream before that person joins”, then everybody needs to rotate keys each time someone joins (not only each time someone leaves). I don’t know if any system does that.
As to the server, now that you make me think of it, yes, there is most probably still a vulnerability there. One can setup the protocol so that someone penetrating the server during a conference cannot access the audio/video stream (because the server doesn’t know the encryption key itself, and is not necessarily allowed to add people to the conference). However, I guess the first contact between the organiser and each participant is via the server as a trusted middleman, so yes, the server can MITM the whole lot from the beginning. To guard against that, you’d have to have a strong authentication between participants (with all the headaches of PKI… too onerous), or at least a preshared secret. The latter means, a password to access the conference that the server doesn’t know. Each participant needs to know the password, and each participant will only share their encryption key with someone that proves to them that they know the password (through a zero-knowledge proof). A bit of quadratic work again, but could be doable.
As to the server, now that you make me think of it, yes, there is most probably still a vulnerability there.
Exactly; this is not “end to end” encryption. You have to trust the server. Same with Jitsi, etc.
The keys are exposed at the server.
Peter wrote:
The keys are exposed at the server.
No, they are not as a routine matter. But I have a doubt whether, in the current implementations, the server is empowered to add a participant, and thus to convince every other participant to send their key to that person. Then, it can add itself, and get the key… As outlined in the end of my previous post, there are ways to structure things so that the server cannot do that. They don’t make usage simpler, though.
More fundamentally, in all these “works magically in a web browser” options (including Jitsi) you are running (in your browser) code that has been sent to you by the server, and it is that code that runs the streams, etc. I’d bet my money on: a compromised server can just send you a “different” version of the client code, that shares the audio/video feed (encryption key) with the attacker, and you are toast.
Yes, again, any process which can add a participant will expose the (common) key used. So it comes back to the same thing: do you trust the server?
I am not aware that there is any way around that.
