mboost-dp1
Zoom
Altså det vil være end-to-end encryption på samme måde som Skype, Teams, og cirka alt andet non-p2p software.
Bruger A genererer en nøgle lokalt, og sender hans pub-key til serveren.
Bruger B modtager bruger A's nøgle fra serveren, og bruger den til at dekryptere bruger A's video/voice stream.
Men Zoom har stadigvæk pubkey, og kan derfor dekrypterer bruger A's (og bruger B) video/voice stream.
Og et man-in-the-middle attack mellem A<>Server, og Server<>B vil stadigvæk være muligt.
Bruger A genererer en nøgle lokalt, og sender hans pub-key til serveren.
Bruger B modtager bruger A's nøgle fra serveren, og bruger den til at dekryptere bruger A's video/voice stream.
Men Zoom har stadigvæk pubkey, og kan derfor dekrypterer bruger A's (og bruger B) video/voice stream.
Og et man-in-the-middle attack mellem A<>Server, og Server<>B vil stadigvæk være muligt.
Og det skal siges at overstående kun virker til 1:1. Og alternativet er at man kun bruger serveren til at sætte op en p2p forbindelse, og hvor pubkeys så udveksles via. p2p, altså uden om Zoom's serverer, hvilket så betyder at det kun er man-in-the-middle attacks der er et problem.
Men det betyder så desværre at det ikke er muligt at optage samtalen (meeting recording er en super populær feature i alle VoIP produkter til business).
Og det gør det rigtig rigtig langsomt at være i et conference call da man skal have pubkeys fra alle medlemmer, og hver eneste gang en ny medlem tilslutter opkaldet, og man kan ikke optimere ved at muxe alle de forskellige audio-streams into en enkelt stream, hvilket betyder at der er et enormt CPU og netværks forbrug hos hver enkelt bruger.
... sidstnævnte er hvordan Skype virkede da det var ren p2p. Og hvorfor alle altid klagede over problemer.
In short, p2p er sikkert, og kan virke nogenlunde til 1:1 opkald, men er praktiskt talt ubrugeligt til conference calls.
Imo. er der ingen måde at gøre conference calls rigtig sikker på. Enten skal man stole på MSFT/Google/Slack/ZOOM/Telefonselskabet, eller også skal man have en OnPrem løsning med sine egne encryption keys (WebEx, Pexip, etc.)
Men det betyder så desværre at det ikke er muligt at optage samtalen (meeting recording er en super populær feature i alle VoIP produkter til business).
Og det gør det rigtig rigtig langsomt at være i et conference call da man skal have pubkeys fra alle medlemmer, og hver eneste gang en ny medlem tilslutter opkaldet, og man kan ikke optimere ved at muxe alle de forskellige audio-streams into en enkelt stream, hvilket betyder at der er et enormt CPU og netværks forbrug hos hver enkelt bruger.
... sidstnævnte er hvordan Skype virkede da det var ren p2p. Og hvorfor alle altid klagede over problemer.
In short, p2p er sikkert, og kan virke nogenlunde til 1:1 opkald, men er praktiskt talt ubrugeligt til conference calls.
Imo. er der ingen måde at gøre conference calls rigtig sikker på. Enten skal man stole på MSFT/Google/Slack/ZOOM/Telefonselskabet, eller også skal man have en OnPrem løsning med sine egne encryption keys (WebEx, Pexip, etc.)
Claus Jørgensen (2) skrev:Og et man-in-the-middle attack mellem A<>Server, og Server<>B vil stadigvæk være muligt.
Der findes nu teknikker som Diffie hellman key exchange https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellm... (som SSH bruger) der muliggører at to parter opnår en fælles hemmelighed til at kryptere med, som man in the middle ikke kan udlede.
Det kræver så bare at man er sikker på man taler med den rigtige modpart mens man laver key exchange.
Claus Jørgensen (2) skrev:Altså det vil være end-to-end encryption på samme måde som Skype, Teams, og cirka alt andet non-p2p software.
Bruger A genererer en nøgle lokalt, og sender hans pub-key til serveren.
Bruger B modtager bruger A's nøgle fra serveren, og bruger den til at dekryptere bruger A's video/voice stream.
Men Zoom har stadigvæk pubkey, og kan derfor dekrypterer bruger A's (og bruger B) video/voice stream.
Og et man-in-the-middle attack mellem A<>Server, og Server<>B vil stadigvæk være muligt.
Er det virkligt rigtigt?
Jeg vil mene at:
Bruger A sender sin Pubkey A til Bruger B, Bruger B encoder sin trafik med Pubkey A. Bruger A decoder Bruger B trafik med Privkey A.
Det er nu kun Bruger A der kan decode trafik der er ment til Bruger A.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund