# Criptat pentru cine? | Marius Comper > Un apel poate păstra un lacăt pe pachete și totuși să ajungă la persoana greșită. Într-un studiu USENIX Security '26, 19 din 33 de servere media WebRTC au eșuat la autentificarea DTLS; în 9 cazuri, cercetătorii au recuperat media sau date protejate. [1] Edition: 14 August 2026 ## Lacătul poate funcționa. Identitatea poate lipsi. Comută singura verigă care schimbă rezultatul: verificarea identității. Restul scenei rămâne aceeași, tocmai ca diferența să fie vizibilă. În WebRTC, media este criptată cu SRTP. Cheile sunt negociate prin DTLS-SRTP. Asta protejează conținutul pe drum; nu repară singur un server care acceptă certificatul unui intermediar. [5] [2] ### Certificatul se potrivește. Serverul compară identitatea prezentată cu cea așteptată. Orice intermediar cu alt certificat este oprit înainte ca cheia media să fie folosită. ### Certificatul este acceptat fără dovadă. Intermediarul termină handshake-ul, primește acces la cheia de sesiune și cere media de la server. Pachetele pot rămâne criptate pe fiecare segment; persoana care le descifrează s-a schimbat. ## Criptarea și autentificarea nu răspund la aceeași întrebare. Confuzia apare când vedem lacătul și presupunem că am verificat și interlocutorul. ### Cine poate citi pachetul? SRTP transformă vocea sau imaginea într-un flux pe care un observator fără cheie nu îl poate citi. ### Cu cine ai negociat cheia? DTLS trebuie să lege cheia de identitatea corectă. Dacă certificatul intermediarului este acceptat, criptarea poate continua cu adversarul deja instalat în conversație. **Takeaway:** Când evaluezi un apel, întreabă cine a fost verificat înainte ca cheia să fie folosită. ## 19 este măsura eșecului. 9 este măsura impactului demonstrat. Cercetătorii au testat 33 de implementări media-server, folosite de 24 de furnizori. Browser-ele Chromium, Firefox și Safari nu au arătat același bypass direct de autentificare; problema a apărut la compoziția server-side a protocolului. [1] - **33:** implementări testate - **19:** eșecuri de autentificare DTLS - **9:** recuperare media sau date protejate Faptul că 19 teste au eșuat spune ceva despre identitate. Faptul că 9 au ajuns la media sau la date protejate spune ceva despre consecință. Cele două numere răspund la întrebări diferite. ## Ce s-a văzut în implementări Rândurile de mai jos pun testele istorice lângă remedierea anunțată de furnizori. O rezolvare într-un produs nu elimină riscul de design din toate produsele. | Sistem | Observație | Media / date | Situație publică | | --- | --- | --- | --- | | Webex | Un certificat gol a fost acceptat; PoC-ul Cisco a primit audio dintr-o întâlnire proprie. | Audio recuperat în scenariul controlat | CVE-2025-20215 / remediat în cloud | | Zoom | Clientul nu a cerut autentificarea necesară a clientului. | Bypass de autentificare cu severitate ridicată | Remediat / raportat prin programul de bug bounty | | Discord | Două căi de bypass în testele din 2022 și 2024. | Impact raportat și confirmat de furnizor | Remediat / bounty | | Steam | Server media care a continuat după bypass. | Media disponibilă cercetătorilor | Confirmat / remediat | | Vonage | Certificatul clientului web nu era cerut sau verificat corect. | Media disponibilă cercetătorilor | Confirmat / remediat | | RingCentral | Autentificarea clientului nu era cerută pe calea testată. | RTP disponibil după bypass | Confirmat / remediat | | Teams | Certificat gol sau arbitrar acceptat pe handshake; nu s-a recuperat RTP. | Metadate RTCP în clar; media RTP nu a fost demonstrată | În afara programului de bounty / caz limitat | | Browsere | Chromium, Firefox și Safari nu au prezentat bypass direct comparabil. | Niciun rezultat de media-server | Comparație de control | Pentru detaliile fiecărui rând și nuanțele de divulgare, vezi lucrarea și advisory-ul Cisco. [2] [3] ## Un număr de întâlnire nu este suficient. Calea demonstrată cere o poziție de tip man-in-the-middle. Atacatorul trebuie să poată observa și modifica traficul dintre participant și infrastructura media. ### Străinul cu doar ID-ul întâlnirii Poate încerca să intre în întâlnire prin căile normale ale serviciului. Nu are însă, doar din ID, poziția necesară pentru a intercala un handshake între participant și serverul media. **CAPABILITATE DEMONSTRATĂ: NU** ### Router sau Wi-Fi compromis Un dispozitiv compromis pe traseul local poate observa și modifica traficul. Advisory-ul Cisco descrie pentru Webex o condiție de rețea locală sau adiacentă, plus interceptarea traficului. **CAPABILITATE DEMONSTRATĂ: DA, ÎN CONDIȚII CONTROLATE** ### ISP sau segment monitorizat Cine controlează un segment de rețea poate vedea mai mult trafic, în funcție de rutare și de felul în care participantul ajunge la serviciu. Studiul nu spune că această capacitate a fost folosită de un serviciu de informații. **INFERENȚĂ DE RISC: PLAUZIBILĂ / NEOBSERVATĂ** Pentru CVE-2025-20215, Cisco a spus că atacatorul trebuie să fie network-proximate, să intercepteze traficul și că PSIRT nu avea cunoștință de exploatare malițioasă. [3] ## Ce merită întrebat înainte să numești o conversație sigură Cercetarea ține separat protocolul, infrastructura și capacitatea adversarului. - Unde se termină media: la participanți sau la un server care negociază separat cu fiecare parte? - Ce identitate verifică serverul înainte să accepte cheia? - Ce se întâmplă când verificarea certificatului eșuează? Se blochează handshake-ul sau continuă sesiunea? - Care este poziția de rețea necesară pentru a modifica acel handshake? - Există un advisory primar și o remediere verificabilă? Lucrarea susține o concluzie precisă: o parte critică din securitatea unui apel poate locui în serverul media, iar un defect de autentificare poate lăsa criptarea intactă în timp ce schimbă cine deține cheia. Nu știm dacă un serviciu de informații a folosit aceste căi. > Întrebarea de ținut minte: cine verifică identitatea înainte ca cheia să fie folosită? ## Citește sursele Fiecare card spune ce susține sursa și unde se oprește. ### [1] Breaking and Entering: How Media Servers Compromise the Security of WebRTC Bach, Zhang, Ku, van der Veen, Holz, Pöpper / 2026 / Peer-reviewed security paper The 24-provider, 33-media-server study; 19 DTLS-layer client-authentication failures; nine affected implementations with demonstrated media or protected-data retrieval; the Webex proof of concept; vendor outcomes and the browser comparison. Limit: The tests used controlled accounts and sessions. They show what an attacker can do from a required man-in-the-middle position; they do not establish widespread interception or use by an intelligence service. https://www.usenix.org/conference/usenixsecurity26/presentation/bach ### [2] Breaking and Entering: How Media Servers Compromise the Security of WebRTC, prepublication PDF USENIX Security '26 proceedings / 2026 / Methods and artifacts The call sequence, DTLS and SRTP relationship, test taxonomy, packet-level evidence, Webex packet flow, responsible-disclosure record and the artifact archive. Limit: The PDF is the research record. It does not provide a live status page for every vendor or prove that a historical implementation remains exposed. https://www.usenix.org/system/files/conference/usenixsecurity26/sec26_prepub_bach.pdf ### [3] Cisco Webex App Vulnerability Could Allow Unauthenticated Join Cisco PSIRT / 2025 / Vendor advisory CVE-2025-20215, the network-proximate prerequisite, the Webex remediation status and Cisco's statement that PSIRT was unaware of malicious use at publication. Limit: A vendor advisory covers the affected product and its fix. It cannot establish whether an unrelated actor used the capability. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webex-join-yNXfqHk4 ### [4] Paper accepted at USENIX Security 2026 ATHENE / TU Darmstadt / 2026 / Research centre summary The public research context and the scale framing around providers, media servers and network interception. Limit: This is a summary page. The peer-reviewed paper remains the authority for methods, counts and individual case details. https://www.athene-center.de/en/start-up-consultancy/news/paper-accepted-at-usenix-2026-1817 ### [5] SRTP in WebRTC WebRTC project documentation / Current source / Protocol documentation The protocol distinction that WebRTC media uses SRTP and that DTLS-SRTP negotiates the keys used by the media channel. Limit: Protocol documentation explains the intended mechanism. It does not certify that every server composition validates identities correctly. https://webrtc.googlesource.com/src/%2B/refs/heads/lkgr/pc/g3doc/srtp.md ### [6] Breaking and Entering: supplementary artifacts Bach et al. / 2026 / Reproducibility artifact The paper's released supporting material, including traces and artifacts associated with the study. Limit: Artifacts make the research inspectable; they still represent controlled experiments rather than an operational threat-intelligence collection. https://doi.org/10.5281/zenodo.17880120 Stare editorială: actualizat la 14 august 2026. Lucrarea raportează testări istorice și remediere acolo unde furnizorii au confirmat-o; reanaliza este declanșată de o nouă versiune primară a cercetării, un advisory material nou sau o schimbare de statut la furnizor.