Surse verificate la 22 octombrie 2026, ora Beijingului. Audience: utilizatori individuali, operatori de site-uri web, dezvoltatori și administratori de sistem.
Slăbiciunile grave au făcut ca un grup de chei private eMudhra/emSign intermediare CA să fie recuperate. Acest lucru afectează clienții care utilizează sistemul de certificate publice pentru a autentifica site-uri web, API-uri și software. Încrederea publică se întinde pe sistemele de operare majore, dar setul de chei compromise și impactul potențial asupra clientului sunt domenii diferite. 15
Textul principal folosește paranteze drepte pentru a numerota sursele corespunzătoare, iar toate legăturile de referință externe sunt enumerate în anexă. Versiunea listată este versiunea de bază confirmată pentru a conține remedierea acestui incident de la data verificării. La implementare, se acordă prioritate versiunii stabile actualizate în aceeași ramură acceptată.
TL;DR
EOpt chei private intermediare CA sunt confirmate compromise. Rapoartele actuale nu stabilesc că cheile private de rădăcină sau criptografia HTTPS în general au fost sparte. Actualizările acoperă o mare parte din ecosistemul de încredere publicului; riscul rezidual depinde de aplicarea efectivă.15
- Utilizatori individuali: actualizează browserele, sistemele de operare și componentele de securitate. Pe Android, actualizați și serviciile Google Play. Utilizați Firefox Android 158.0.2 sau mai târziu. 12
- Servere: actualizează pachetele
ca-certificates/NSS ale distribuției și verifică magazinele de încredere incluse în aplicații. Actualizarea doar a gazdei este insuficientă. 7810 - Medii de dezvoltare: actualizează Node 24 la 24.22.1 sau o versiune mai nouă în acea ramură, după caz. În mediile Python, actualizați la cel puțin pip 26.2.2, certifi 2026.10.19 și uv 0.13.4. Obțineți binare Go fixe sau reconstruiți-le; actualizați Java conform avizului furnizorului său. 12–15
- Activați actualizările: reporniți serviciile afectate și reconstruiți și redistribuiți containerele. Pentru Cloudflare Tunnel, actualizați cloudflared la 2026.10.2 sau mai târziu. 7
- Certificate de site: înlocuiește un lanț afectat dacă conține un CA intermediar revocat sau blocat sau se bazează pe o rădăcină neîncrezătoare. Reemiterea unui certificat nu înlocuiește actualizarea depozitelor de încredere ale clienților. 158
- Verificare: testează calea TLS reală a fiecărei aplicații. Distingeți respingerea certificatului de timeout-uri și eșecurile DNS. Păstrați verificarea certificatului activată; nu utilizați
-kși nu omiteți verificarea pentru a suprima erorile. 7
1 Fapte și cauze ale incidentului
fapte confirmate
Mozilla și Google au defecte confirmate la opt chei private eMudhra intermediare CA. Cercetătorul a furnizat dovada controlului cheii private; Mozilla a recuperat independent cheile și a reprodus problema. Șase CA intermediare deservesc TLS și două deservesc semnarea codului. 25
Defectul constă în cheile generate: aceste CA intermediare folosesc curba P-384, dar cheile lor private sunt numere întregi sub 256. Acest lucru este departe de a selecta cheile în siguranță la întâmplare din intervalul mare prevăzut. Recuperarea acestor chei slabe nu demonstrează că cheile P-384 generate corect pot fi sparte. 2
„Certificatul este spart” aici ar trebui să fie înțeles cu exactitate ca „cheia privată corespunzătoare poate fi recuperată”. Certificatul și cheia publică din el sunt în mod inerent publice; ceea ce trebuie păstrat secret este cheia privată care poate genera o semnătură validă.
Probleme legate de procesul de generare a cheilor încă în curs de investigare
O descriere inițială a eMudhra urmărește problema până la o ceremonie de generare a cheilor din aprilie 2025. Explicația implică un pas de încapsulare și decapsulare a cheii: pe lângă cheia puternică originală, apare un alt set de chei slabe, iar cheile slabe sunt ulterior utilizate pentru aplicarea și emiterea certificatelor. Compania a spus că cauza exactă nu a fost determinată în mod concludent. 6
Prin urmare, ceea ce se poate determina este că aceste chei sunt foarte slabe și au fost compromise; Eșecul nu poate fi descris în continuare ca o anumită sursă hardware de numere aleatoare a HSM sa dovedit a fi defectă și nici nu poate fi descrisă ca o descoperire criptografică generală a RSA, ECC sau TLS.
Ce înseamnă neîncrederea în certificatul rădăcină?
Browserul sau sistemul de operare pot bloca direct certificatul sau cheia publică a CA intermediar afectat sau poate elimina încrederea rădăcină care duce la acestea. Această din urmă măsură va respinge și unele certificate legitime sub aceeași rădăcină.
Google a programat eliminarea emSign ECC Root CA - G3 pentru a proteja utilizatorii magazinului rădăcină Chrome care nu primesc actualizări de la CRLSet. Îndepărtarea depozitului de rădăcină este de așteptat să fie împinsă în perioada corespunzătoare din 27 până în 28 octombrie, ora Beijingului; ora inițială a Google este dimineața zilei de 27 octombrie, ora de vară a Pacificului din SUA. Acest plan este separat de blocarea cheii publice de urgență care a fost implementată anterior. 1
Neîncrederea într-o rădăcină este o măsură de răspuns; ea însăși nu dovedește că cheia privată rădăcină a fost compromisă.
2 De ce impactul potențial se întinde pe ecosistemul încrederii publicului
Chei compromise și căi de încredere afectate
| Obiectul judecății | Sfera acestui incident |
|---|---|
| Identificată cheie problematică | 8 chei private intermediare CA pentru eMudhra |
| Platforme care pot necesita acțiuni | Magazin public rădăcină, browser, sistem de operare, runtime de limbă, pachet software și ecosistem de containere |
| Identitate posibilă uzurpată TLS | Site-uri web sau servicii vizitate de clienți care încă acceptă lanțul de certificate falsificate asociat |
| Înseamnă că toate dispozitivele au fost compromise? | Nu; condițiile de încredere, locația rețelei atacatorului și alte strategii de verificare determină exploatarea |
| Înseamnă că toate certificatele legale sunt invalide? | Nu; invalidarea asociată depinde de ce rădăcini sau lanțuri de certificate nu are încredere clientul. |
Red Hat limitează în mod explicit exploatarea la condițiile în care clientul încă acceptă lanțul relevant, atacatorul posedă cheia privată compromisă și este capabil să intercepteze conexiunea în rețea. Acoperirea riscurilor nu trebuie confundată cu numărul de atacuri care au avut loc. 10
Site-urile web care utilizează alte CA pot fi, de asemenea, usurizate
Să presupunem că un site web folosește de fapt certificatul Let’s Encrypt, iar clientul vizitatorului are încredere în mai multe CA publice în același timp. Un atacator ar putea încerca să folosească intermediarul compromis CA pentru a crea un alt certificat pentru același nume de domeniu. De obicei, clienții nu solicită în prealabil ca numele de domeniu să poată utiliza doar Let’s Encrypt; dacă lanțul fals este încă acceptat, ceea ce CA îl folosește de fapt site-ul web nu este suficient pentru a exclude astfel de atacuri. 8
Acest mecanism explică: Înlocuirea unui alt certificat CA care a fost inițial normal nu va repara automat încrederea clientului în CA compromis. Ceea ce trebuie cu adevărat tăiat este calea clienților de a accepta identități false.
Cele trei efecte trebuie tratate separat
IRiscul de uzurpare a identității: Clienții care nu au blocat lanțul relevant pot accepta identitatea falsificată de atacator, determinând trimiterea cererilor sensibile către servicii false.
Risc de disponibilitate legitimă a serviciului: eliminarea încrederii la rădăcină poate cauza erori de certificat pentru site-uri web altfel legitime, care ar putea necesita migrarea către un alt lanț acceptat.
Riscul de acoperire de implementare: sistemul de operare poate fi remediat în timp ce un magazin de încredere, un mediu virtual, o imagine de container veche sau un program compilat păstrează vechiul comportament de validare.
Aceste trei domenii nu sunt identice. Răspunsul lui Cloudflare acoperă validarea identității de la distanță, magazine de încredere partajate, imagini de bază și aplicații individuale, ilustrând de ce ultimele două sarcini trebuie gestionate separat. 7
3 CA și furnizorii de certificate afectați
Furnizor și tip de impact
| furnizor sau sistem | Rol în acest incident | Limite care trebuie distinse |
|---|---|---|
| eMudhra／emSign | Cheia privată intermediară CA este compromisă direct. | Nu puteți scrie toate rădăcinile eMudhra și toate certificatele ca crăpate |
| Lanțul de semnături încrucișate asociat cu Sectigo | Certificatul încrucișat A a fost emis pentru același lot de chei publice afectate, formând o altă cale de încredere. | Certificatul încrucișat corespunzător sau cheia publică trebuie blocată; cheia privată rădăcină Sectigo nu s-a dovedit a fi compromisă. |
| Niveluri de certificate relevante pentru Internet2/InCommon | Unele certificate legitime se bazează pe rădăcina emSign ECC pentru a fi eliminate, implicând migrarea | Este un impact colateral al neîncrederii rădăcinilor și nu poate fi considerat ca mijlocul acelor 8 chei slabe CA |
| Let’s Encrypt, DigiCert, Google Trust Services, GlobalSign etc. | Nu este listată ca parte a cărei cheie privată a fost compromisă în acest raport | Certificatele legitime nu sunt invalidate uniform; Clienții vulnerabili pot accepta în continuare certificate false care uzurpă identitatea site-urilor web pe care le deservesc |
| CDN, platformă cloud, distribuitor de certificate | Este posibil să furnizați certificate relevante sau să utilizați un truststore public atunci când vă conectați la origine și API | Pentru a verifica lanțul de certificate și validatorul real, nu vă uitați doar la platforma sau numele produsului |
Notificarea Mozilla documentează cheile compromise și semnăturile încrucișate Sectigo. Discuția publică a Google despre incident abordează migrarea ierarhiilor legitime Internet2/InCommon. 25 Cloudflare soluționează serviciul de adrese și încrederea clienților; nu indică compromiterea cheilor private Cloudflare proprii CA. 7
Lanț de certificate TLS și semnătură încrucișată
Următoarea relație descrie numai căile legate de TLS de data aceasta. Nu include căi de semnare a codului și nici nu înseamnă că aceste căi sunt încă de încredere pe toate platformele. 17
emSign ECC Root CA - G3→emSign Root TLS CA - G3→ TLS afectat cheie publică intermediară CA → Certificat falsificat pentru domeniul țintăAAA Certificate Services→ TLS afectat cheie publică intermediară CA → Certificat falsificat pentru domeniul țintă
emSign Root TLS CA - G3 este un emitent direct al intermediarilor TLS afectați și poate fi el însuși o ancoră de încredere în unele magazine. emSign ECC Root CA - G3 oferă un alt nivel de semnătură încrucișată. Sectigo AAA Certificate Services creează o cale suplimentară către aceleași chei publice intermediare CA. 17
Prin urmare, există două granularități diferite la reparare:
- Blocați exact intermediarul CA sau cheia publică:, aceasta poate păstra alte ierarhii legitime sub aceeași rădăcină, unde validatorul acceptă acel mecanism.
- Eliminați încrederea rădăcină: aceasta poate proteja clienții fără capabilități intermediare de blocare CA, dar poate afecta compatibilitatea. Toate celelalte căi pe care clientul le acceptă trebuie, de asemenea, acoperite. 5
„Ștergeți toate rădăcinile Sectigo/eMudhra” nu ar trebui luată ca un pas general nediscriminatoriu și nici ștergerea unui certificat cu un nume similar nu ar trebui să însemne că toate căile sunt închise.
4 Sistem de operare și acoperire browser
Platforma principală
| Platformă | Dispoziție cunoscută | Domeniul de aplicare care ar trebui verificat la utilizare |
|---|---|---|
| Windows și Windows Server | Microsoft Distribuție blocată prin actualizarea automată a listei de încredere a certificatelor | Dacă dispozitivul a primit actualizarea; autonom CA bundle nu utilizează neapărat calea de verificare a Windows |
| macOS, iOS, iPadOS etc. Platformă Apple | Coordonatorul incidentului a confirmat că Apple a desfășurat blocada relevantă | Nu se garantează că fiecare versiune mai veche și aplicație terță parte vor primi aceeași acoperire |
| Android | Google distribuie blocuri echivalente prin serviciul Google Play | ROM fără Google Play serviciul ar trebui verificat conform anunțului producătorului; utilizați verificatorul încorporat pentru o verificare suplimentară |
| Ubuntu | Au fost furnizate remedieri ale pachetului de certificate de sistem, inclusiv mai multe ramuri de versiune actuală și veche | Versiunea veche a ESM acceptă condiții, pachetul de certificat intern al containerului și biblioteca încorporată a aplicației |
| Debian și Devuan | Debian a înregistrat ca-certificates fixat | Trebuie să verificați ramura reală utilizată și pachetul instalat și nu puteți copia numărul de versiune al altei ramuri. |
| RHEL și derivate | Lista oficială este RHEL 6, 7, 8, 9, 10 și acoperă produse și imagini conexe care pot fi afectate | Începând cu această verificare, anunțul nu a enumerat încă o listă completă de remedieri și errate; „Actualizarea nu a fost găsită” nu poate fi considerată neafectată |
| Fedora, Arch, Gentoo, Alpine etc. | Menținătorul evenimentului a compilat înregistrările de reparații corespunzătoare | Confirmat independent de lansare, ramură de versiune și imagine |
| FreeBSD | Enumeră oficial toate versiunile acceptate și oferă reparații în magazinul de încredere de sistem | După actualizare, reporniți procesul demonului relevant conform anunțului; verificați separat magazinul de încredere pentru aplicații. |
Pentru un rezumat al Windows, Apple și versiuni, consultați 4; pentru Android, vezi 1; pentru Ubuntu, Debian, RHEL și FreeBSD Înregistrările emitentului sunt afișate în 8–11, respectiv.
Sistemele care nu mai sunt acceptate, dispozitivele offline, NAS, routerele și alte medii încorporate trebuie să confirme dacă mai au încredere în lanțul relevant și dacă au canale pentru a primi revocare sau actualizări de software. Numele platformei în sine nu este un substitut pentru verificarea comportamentului real de verificare.
Protecția browserului este diferită de protecția sistemului de operare
Chrome folosește CRLSet pentru a distribui blocuri de urgență; Firefox utilizează mecanisme precum OneCRL. Firefox a fost, de asemenea, lansat cu informații de blocare pentru a oferi protecție suplimentară pentru configurațiile care nu primesc corect setările de la distanță. 13
Unele configurații ale lui Firefox Android nu aplicaseră corect lista actualizată la pornire, despre care Mozilla a declarat că este remediată de 158.0.2.. Prin urmare, starea 158.0.1 timpurie nu poate fi extinsă pentru a include toate configurațiile Android Firefox protejate. 2
Au fost luate măsuri pentru verificarea sistemului Apple și Windows, dar aceasta nu înseamnă că toate programele din linia de comandă de pe aceeași mașină vor fi supuse verificării sistemului. Organizatorul de evenimente a reamintit în mod special că unele instrumente încorporate macOS utilizează fișiere de certificate independente; backend-ul TLS și sursa CA ar trebui înregistrate la verificare. 4
Limite de protecție pentru transparența certificatelor
Google a confirmat că, înainte de a implementa blocul, cele șase TLS intermediare CA nu au emis certificatul TLS care a intrat în jurnalul CT. Prin urmare, clienții Chrome care impun CT au protecție suplimentară. Acest fapt nu exclude posibilitatea ca alți clienți care nu execută CT să fi acceptat certificate nedocumentate. 15
„Se pare că poate fi legat de rădăcina de încredere”, „există condiții potențiale de exploatare” și „a avut loc un atac” sunt trei judecăți diferite și nu ar trebui înlocuite una de alta.
5 Mediul de dezvoltare și linia de referință pentru repararea timpului de execuție
Următoarele este o bază de corecții confirmate și nu este o cerință pentru fixarea acestor versiuni pe termen lung. Distribuțiile pot remedia numerele de versiuni mai vechi prin mutarea patch-urilor înapoi, iar avizele lor de securitate ar trebui, de asemenea, revizuite.
| componente | Versiune sau metodă de actualizare confirmată | Considerente de implementare |
|---|---|---|
| Node.js 24 | 24.22.1 sau actualizați versiunea stabilă a aceleiași ramuri | Conține actualizări ale depozitului rădăcină și respingerea cheilor publice blocate; verificați calea Node folosită efectiv de serviciu și reporniți |
| Python certifi | 2026.10.19 sau o versiune mai nouă | Verificați fiecare mediu de rulare real; nu puteți actualiza doar un pachet sub Python global |
| pip | 26.2.2 sau o versiune mai nouă | Actualizați separat pip în vechiul mediu virtual și revizuiți versiunea după crearea noului mediu |
| uv | 0.13.4 sau o versiune mai nouă | Actualizați o copie a instrumentului așa cum a fost instalat efectiv |
| Go | 1.27.3 sau 1.26.10, este disponibilă și versiunea actualizată a sucursalei corespunzătoare | Reconstruiți și implementați programele relevante după actualizarea lanțului de instrumente sau obțineți binarul de reparații al furnizorului |
| Oracle JDK | Critical corecții pentru liniile de versiune acceptate corespunzătoare | Diferiți editori JDK își urmează propriile anunțuri; nu există un număr unic de versiune care să se aplice tuturor versiunilor Java |
| Cloudflare Tunnel | cloudflared 2026.10.2 sau o versiune mai nouă | Actualizați serviciile de rulare; implementarea containerului necesită înlocuirea imaginii și redistribuire |
| Cloudflare One／WARP | Versiunea client fix corespunzătoare platformei sau versiunea stabilă actualizată | Măsurile la nivelul clientului și al serverului sunt confirmate separat. Pentru versiuni specifice de platformă, consultați anexa 7 |
Instrucțiunile originale pentru Node , Python , Go , Oracle şi Cloudflare sunt, respectiv, disponibile în 13 , 12 , 14 , 15 , 7 .
Python problemă cu baza de date a certificatelor independente
Oficialii Python au subliniat că vechiul pip va folosi o combinație de încredere în sistem și certifi încorporat. Simpla modificare a depozitului de certificate de sistem sau adăugarea unui fișier CA la pip nu poate exclude în mod fiabil încrederea veche încorporată. Prin urmare, PIP_CERT, REQUESTS_CA_BUNDLE sau --cert nu pot fi utilizate ca înlocuitor de reparații universal pentru pip mai vechi. 12
Verificați mediile virtuale existente după actualizare. Verificați, de asemenea, versiunea pip instalată efectiv în medii nou create, astfel încât componentele bootstrap mai vechi să nu reintroducă instrumente vulnerabile. Pentru actualizarea inițială, urmați sursele de descărcare și pașii de verificare SHA-256 din avizul Python înainte de a actualiza alte pachete. 12
Go și alte programe compilate
Remedierea pentru Go a schimbat logica de validare pentru crypto/x509. 14 Din perspectiva mecanismului de implementare, actualizarea compilatorului pe mașina de dezvoltare nu va rescrie binarul deja implementat. Pentru a obține blocarea noului strat de cod, aplicația ar trebui reconstruită și înlocuită sau ar trebui utilizată o versiune actualizată furnizată de furnizor. Dacă un program mai vechi poate beneficia și de actualizările rădăcinii sistemului, depinde de calea reală de verificare pe care o folosește.
Containere și aplicații ambalate
Pachetul de certificat de sistem, dependențele aplicației și timpul de rulare din container sunt de obicei determinate de conținutul imaginii. Actualizarea gazdei nu este egală cu actualizarea conținutului imaginii; imaginea de bază și dependențele trebuie actualizate, iar instanța care rulează trebuie reconstruită, implementată și verificată. Aplicațiile împachetate și programele desktop care vin cu propriul timp de rulare ar trebui, de asemenea, actualizate în funcție de canalele de lansare ale furnizorului. 710
6 Instrucțiuni de implementare a reparațiilor
Determinați mai întâi obiectul de inspecție
Se recomandă să înregistrați următoarele informații pentru serviciile care trebuie protejate și apoi să selectați calea de reparație corespunzătoare. Aceasta este o listă de verificare a implementării și nu necesită ca toate componentele să fie prezente pe fiecare sistem.
| Proiect | Ceea ce trebuie înregistrat |
|---|---|
| Aplicații și utilizări | Browser, client API de plată, serviciu de trimitere de e-mailuri, instrument de descărcare, proxy invers etc. |
| pozitia de operare | Gazdă, container, mașină virtuală, aplicație desktop sau dispozitiv mobil |
| Verificați implementarea | Validator de sistem de operare, OpenSSL, Node, bibliotecă Python, Java sau implementare personalizată a aplicației |
| sursă de încredere | Pachetul de sistem CA, certifi, magazin de încredere JDK, CA bundle încorporat sau configurație de întreprindere |
| Starea reparației | Versiunea instalată, sursa patch-urilor, dacă să reporniți sau să redistribuiți |
| Rezultate de acceptare | Dacă lanțul afectat este respins, dacă conexiunea normală de afaceri are succes și timpul de verificare |
Ghidul dezvoltatorului pentru Cloudflare precizează în mod specific că SDK poate delega verificarea altor componente; doar actualizarea SDK de nivel superior nu schimbă neapărat politica de încredere reală. 7
Sisteme de operare și browsere
Windows: activați și verificați actualizările automate ale listei de încredere ale certificatelor. Distribuiți actualizări prin politici de management stabilite. Dispozitivele offline sau dispozitivele cu actualizări automate dezactivate necesită blocarea aplicată printr-un proces de gestionare adecvat. Verificați separat programele care nu utilizează validarea sistemului Windows. 4
Apple Platformă: Actualizări complete ale sistemului, componentelor de securitate și aplicațiilor. Pentru instrumentele de dezvoltare de pe macOS, verificați, de asemenea, backend-ul TLS, fișierele de certificat și sursele de instalare. Nu se poate aprecia că întreaga mașină a fost reparată doar pentru că Safari a respins lanțul de testare. 4
Android: actualizați serviciile Google Play pe dispozitivele care îl au. Google afirmă că repornirea unui dispozitiv poate declanșa o actualizare imediată. Pentru dispozitivele fără aceste servicii, urmați avizul furnizorului sau ROM; Declarația de acoperire a Google nu se aplică automat fiecărui dispozitiv Android. 1
Ubuntu/Debian: actualizați pachetele de certificate din depozitele acceptate și verificați avizul pentru distribuția instalată. De exemplu, un sistem bazat pe APT poate folosi:
sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificatesActualizările relevante pentru Ubuntu 22.04, 24.04, 26.04 și 26.10 sunt suport standard; versiunile anterioare ar trebui să verifice suportul ESM și starea depozitului. După ce comanda se încheie cu succes, ar trebui să comparați în continuare versiunea pachetului de corecții din buletin. 89
RHEL și produse conexe: Verificați pachetul de certificate și erorile de securitate pe canal de produs. Verificarea versiunii se poate face folosind:
rpm -q ca-certificatesUtilizați mecanismul de actualizare acceptat DNF/YUM pentru a obține corecții de la furnizor; dacă canalul nu a furnizat încă o remediere, nu considerați „nici un pachet actualizabil” ca fiind sigur. Când este necesar să eliminați temporar încrederea rădăcină, adoptați măsuri clar enumerate de producător și evaluați compatibilitatea certificatelor de afaceri legitime. 10
FreeBSD: actualizați ramura relevantă a sistemului conform indicațiilor oficiale, apoi reporniți demonii folosind configurația de încredere OpenSSL afectată sau reporniți sistemul. 11
Aplicații și imagini
După finalizarea actualizărilor de rulare și a dependenței de certificate corespunzătoare, verificați calea fișierului executabil în care rulează serviciul pentru a evita ca terminalul să fi trecut la o versiune nouă și demonul să folosească în continuare directorul de instalare vechi. Pentru multi-mediu Python, containerele de service și aplicațiile care vin cu propriul timp de rulare, acestea ar trebui verificate separat.
Pentru componentele care trebuie reconstruite, salvați versiunea de compilare, versiunea dependenței și ID-ul imaginii de implementare. Obiectul de acceptare este instanța care rulează efectiv și nu poate verifica doar noua etichetă din mașina de compilare sau din registrul de imagini. 71214
Migrarea certificatului de site
Dacă lanțul unui site web conține un CA intermediar revocat sau blocat sau, în cele din urmă, se bazează pe o rădăcină neîncrezătoare, obțineți un alt lanț pe care clienții îl acceptă în continuare. Instalați lanțul complet de certificate de server și verificați fiecare intrare, inclusiv echilibrarea încărcăturii, proxy-urile inverse, punctele finale CDN și originile accesibile direct. 15
Dacă este necesară migrarea se bazează pe lanțul real. Filtrarea numai după marca de vânzare a certificatelor poate pierde relațiile de revânzare sau de semnare încrucișată; Este posibil ca doar așteptarea reînnoirii periodice a expirării să nu termine neapărat migrarea înainte ca magazinul rădăcină să fie actualizat.
Pentru alte certificate normale de site-uri web emise de CA care nu se bazează pe rădăcina afectată, nu este nevoie să le resemnați din cauza acestui incident. În același timp, serverul site-ului web în sine ar trebui să efectueze verificări de reparații la nivelul clientului atunci când apelează servicii externe.
7 Verificați dacă remedierea are efectiv efect
Verificarea versiunii și verificarea comportamentului sunt efectuate separat
Verificările versiunilor sunt folosite pentru a confirma că patch-urile sau componentele fixe au fost implementate; verificările comportamentale sunt folosite pentru a confirma că aplicația folosește de fapt calea de verificare așteptată. Cele două verificări rezolvă probleme diferite, iar niciuna dintre ele nu poate fi înlocuită cu „Comanda de actualizare executată cu succes”.
Organizatorul evenimentului furnizează materiale pentru site-ul de testare și pentru lanțul de certificate, iar intrarea este concentrată în anexa 4. Ar trebui verificat în mediul de operare real al aplicației țintă, menținând configurația normală de verificare a certificatului. 47
| Verificați rezultatele | Concluzii care se pot trage |
|---|---|
| Respingeți în mod explicit deoarece lanțul afectat nu este de încredere | Indică faptul că calea de verificare testată a respins lanțul |
| Acceptați lanțul afectat în mod normal | Indică faptul că această cale trebuie să fie reparată în continuare sau configurația verificată. |
| Eroare DNS, expirare a conexiunii, respingere proxy sau serviciu inaccesibil | Nu se poate concluziona că riscul certificatului a fost eliminat pe baza acestui fapt. |
| Browserul respinge, dar apelul aplicației nu este bifat | Poate confirma doar browserul, nu programul de fundal. |
| Lanțul A a fost respins | Încă trebuie să luați în considerare dacă clientul acceptă o altă cale de semnare încrucișată |
Testul ar trebui să acopere, de asemenea, conexiunile normale de afaceri pentru a evita confundarea tuturor eșecurilor cererii ca reparații reușite după eșecurile afacerii sunt cauzate de eliminarea prea multă încredere.
Condiții de finalizare sugerate
- Sursa de actualizare și versiunea componentelor afectate sunt documentate.
- Instanța care rulează corespunzătoare a fost repornită, reconstruită sau redistribuită.
- Aplicația actuală respinge lanțul afectat, iar verificarea TLS pentru afaceri normale continuă să funcționeze.
- Nu există nicio configurație pentru a dezactiva temporar verificarea certificatului pentru a restabili conexiunea.
- Dacă este implicată migrarea certificatului de site, toate intrările externe au fost schimbate și verificate.
Condițiile de finalizare de mai sus sunt sugestii pentru operarea și acceptarea întreținerii pentru această eliminare; nu echivalează cu a demonstra că echipamentul nu are alte probleme de siguranță.
8 Trafic istoric HTTPS și limitele de risc
Trei tipuri de chei au utilizări diferite
| cheie | Scopul principal |
|---|---|
| CA cheie privată | Semnați identitatea și legarea cheii publice în certificat |
| cheie privată a site-ului web | Dovediți identitatea serverului în acordul de mână TLS autentificat cu certificat |
| cheia de sesiune | Protejați datele transmise efectiv pe o conexiune |
Obținerea cheii private CA nu este echivalentă cu obținerea cheii private a site-ului web sau a tuturor cheilor de sesiune. A conexiunea normală cu secretizare directă folosind schimbul temporar de chei nu va expune automat sesiunile istorice doar pentru că cheia de semnare pe termen lung este ulterior compromisă. Pentru atributele de securitate relevante ale TLS 1.3, consultați RFC 8446. 16
Riscul principal de această dată apare în faza de autentificare: dacă clientul acceptă certificatul serverului fals, acesta poate stabili o conexiune cu atacatorul care este încă criptată. TLS 1.3 necesită, de asemenea, autentificare de încredere; Pur și simplu actualizarea versiunii de protocol nu este un substitut pentru blocarea CA.
Judecăți care pot și nu pot fi făcute în prezent
Confirmat: cheile private intermediare specifice CA sunt compromise; căile de încredere a publicului afectate au o acoperire largă; platforme majore și mai multe ecosisteme software au luat măsuri. 145
Nu a stabilit prin acest incident: că toți utilizatorii au suferit atacuri de tip man-in-the-middle, că alte chei private CA sunt compromise, că tot traficul istoric HTTPS este decriptabil sau că actualizarea unui browser protejează fiecare aplicație de pe browser.
Decizia finală cu privire la un anumit serviciu ar trebui să se bazeze pe lanțul de certificate, politica de verificare, componentele care rulează efectiv și starea actualizării, nu doar dacă bara de adrese arată HTTPS.
Anexă A Nume CA intermediar afectat
Următoarele nume ajută la verificarea activelor. Numele nu înlocuiesc amprentele certificatelor sau identificatorii cheii publice. Potrivirea automată ar trebui să utilizeze identificatorii exacti publicati de întreținerii incidentului sau de furnizori, inclusiv certificate cu semnătură încrucișată. 5
| Mijloc CA | Scop | Organizații asociate |
|---|---|---|
| EM EV TLS CA - G3B | TLS | eMudhra BV |
| EM OV TLS CA - G3B | TLS | eMudhra BV |
| EM DV TLS CA - G3B | TLS | eMudhra BV |
| EM EV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV TLS CA - G3C | TLS | eMudhra Inc |
| EM DV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV CS CA - G3B | semnarea codului | eMudhra BV |
| EM OV CS CA - G3C | semnarea codului | eMudhra Inc |
TLS nu este exact același mecanism de validare și revocare ca semnarea codului. Obiectivul acestui articol este HTTPS/TLS; mediul de semnare a codului ar trebui să adopte Microsoft, JDK sau furnizori de software înrudiți în acest scop de verificare, iar rezultatele testelor browserului nu trebuie considerate ca acceptare a semnării codului. 515
Anexă B Link de referință
Următoarele surse au fost verificate pe 22 octombrie 2026. Anunțul continuu poate fi actualizat în continuare, iar starea și versiunea din text ar trebui să fie înțelese pe baza datei acestui document.
Faptele incidentelor și gestionarea platformei
[1] Google Chrome și Android Anunț oficial Descrie defectele cheii private, blocarea SPKI, distribuirea serviciilor Google Play, protecția CT și planurile de eliminare a depozitului rădăcină Chrome. Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
[2] Mozilla Bugzilla 2083449 Înregistrare eveniment Conține rapoarte originale, verificare independentă, investigare a procesului de generare, remedieri ulterioare pentru Firefox Android și discuții privind migrarea certificatelor legale; concentrați-vă pe comentariile 5, 11, 29 și 30. eMudhra Private key compromise of Intermediate Certificates
[3] Mozilla Firefox Notă de securitate Descrierea distribuției de urgență OneCRL și a ulterioară eliminarea Firefox/NSS. Protecting Firefox users following the compromise of eMudhra intermediate certificates
[4] Coordonator eveniment Dennis Jackson Rezumat întreținere și portal de detectare Oferă instrucțiuni suplimentare privind starea reparației platformei și a software-ului, intrarea testului, materialele lanțului de certificate publice și medii precum Windows/macOS. Rezultatele testelor reprezintă doar căile de verificare efective testate. eMudhra Intermediate CA Compromise
[5] Mozilla Notificare către administratorii de distribuție și depozit de încredere Descrie 6 TLS și 2 intermediari de semnare a codului CA, Sectigo granițele de procesare a semnării încrucișate, revocare și încredere rădăcină și enumeră certificatul exact și identificarea cheii publice. oss-security eMudhra Intermediates Compromise
[6] eMudhra Declarație oficială despre eveniment Furnizați explicația preliminară a producătorului despre procesul de generare a cheilor; cauza profundă exactă va fi încă supusă încheierii investigației finalizate. eMudhra Statement on Recent Certificate Security Incident
[7] Cloudflare Instrucțiuni oficiale de incident și reparații Acoperă WARP, Cloudflare Tunnel, verificarea site-ului de origine, dependențele de rulare, actualizări de imagini și metode de verificare. 8 eMudhra certificates are compromised Here is what you need to know
Sisteme de operare și distribuții
[8] Ubuntu Anunț oficial de reparație Enumeră pachetele de corecție ca-certificates, canalele de asistență și pașii de actualizare vizați pentru fiecare versiune. eMudhra CA compromise fixes available
[9] Debian Fișă oficială de probleme și reparații Înregistrarea de corecție a întreținătorului și pachetul de lansare corespunzător ar trebui să fie luate ca standard, iar sugestiile temporare timpurii din discuția problemei nu ar trebui să fie considerate ca soluție finală. Debian bug 1151413 eMudhra Intermediate CA key compromise
[10] Red Hat Buletin oficial de siguranță RHSB 2026 012 Enumeră de la RHEL 6 până la 10, impacturile asociate cu produsul și containerul și remediați intrările privind eliberarea și eliminarea intermediară. Certificate compromise eMudhra
[11] FreeBSD Buletin oficial de securitate Furnizați ramurile de sistem afectate, versiunile de reparații și cerințele de repornire a serviciului. FreeBSD SA 26 73 caroot
Runtime și protocoale
[12] Python Descriere oficială a evenimentului Oferă linii de bază pentru reparații pentru pip, certifi, uv etc., explică problema vechiului magazin de încredere independent pip și oferă metoda de actualizare inițială cu verificarea SHA-256. Information for Python users regarding eMudhra emSign CA certificate security incident
[13] Node.js 24.22.1 Lansare oficială Conține actualizări ale magazinului rădăcină NSS și respinge modificările care conțin lanțuri de certificate de chei publice blocate. Node.js 24.22.1 security release
[14] Go Lansare oficială de securitate Descriere Actualizare de filtrare a lanțului de certificate crypto/x509 pentru Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released
[15] Oracle JDK Instrucțiuni oficiale de eliminare Explicați patch-ul critic JDK și măsurile de configurare aferente atunci când nu poate fi actualizat imediat. Distrusting eMudhra Intermediate Certificates in Oracle JDK
[16] TLS 1.3 Protocol standard RFC 8446 Consultați anexa E.1 pentru instrucțiuni privind autentificarea identității, schimbul temporar de chei și secretul direct. The Transport Layer Security Protocol Version 1.3
[17] Certificat rădăcină legat de eveniment și date despre relația de emitere Folosit pentru a înțelege relația de emitent direct și de semnătură încrucișată; starea de includere a magazinului rădăcină nu poate înlocui cea mai recentă stare de revocare sau de blocare a clientului. Root certificate relationships JSON