[liuliu]

it is unclear how key exchanges can be handled securely in these cases. The post seems to suggest Zoom cannot insert itself as middleman ("without showing on the participant list"). But that contradicts directly to how these "connectors" work.

[jcrawfordor]

The connectors appear in the participant list - this is a pretty common architecture for all kinds of communications bridging solutions. When someone joins a meeting by phone, Zoom spins up a service that 'assumes the identity' of that phone user to join the meeting (incl. negotiating keys). So, the Zoom service is now a participant in the meeting, but you do know that since a user appears in the participant list.

I have no special insight into how Zoom implements it, that's just how this is normally implemented in a number of other situations (e.g. h.323 bridges).

[liuliu]

Thanks, that makes sense. I am not familiar with Zoom the product to know the connectors show up in participant list.

I think even if proper e2e channel established, without authentication (Zoom just allows you to join any meeting with a token, like every other Hangout product), the key exchanges with other participants will be very automated. There seems to be very limited security guarantee if anyone can send you a public key in exchange for the current session key to participate in a meeting to begin with.

[jcrawfordor]

Right, and this is kind of the key problem that Zoom is having to solve right now. The only material you (used to) need to know to join a meeting was a 9-ish digit meeting ID, and since that meeting ID entitles you to negotiate keys, it more or less nullifies encryption guarantees (except the post-hoc guarantee of the meeting host being able to see if something was up).

I would point out that this is in no way unique to Zoom, though. In fact, after the changes Zoom made in response to all of these issues, Zoom probably has the highest by-default level of meeting security of just about any product out there.