منابع در 22 اکتبر 2026 به وقت پکن بررسی شدند. Aمخاطب: کاربران فردی، اپراتورهای وب سایت، توسعه دهندگان و مدیران سیستم.
ضعف های جدی باعث شد گروهی از کلیدهای خصوصی eMudhra/emSign میانی CA قابل بازیابی باشند. این روی مشتریانی که از سیستم گواهی عمومی برای احراز هویت وبسایتها، APIها و نرمافزارها استفاده میکنند، تأثیر میگذارد. اعتماد عمومی سیستمهای عامل اصلی را در بر میگیرد، اما مجموعه کلیدهای در معرض خطر و تأثیر بالقوه مشتری دامنههای متفاوتی دارند. 15
متن اصلی از کروشه مربع برای شمارهگذاری منابع متناظر استفاده میکند و همه پیوندهای مرجع خارجی در ضمیمه فهرست شدهاند. نسخه فهرست شده نسخه پایه نسخه تأیید شده است که حاوی رفع مشکل این حادثه از تاریخ تأیید است. هنگام استقرار، اولویت به نسخه پایدار به روز شده در همان شاخه پشتیبانی شده است.
TL;DR
هشت کلید خصوصی میانی CA به خطر افتاده است. گزارشهای فعلی ثابت نمیکنند که کلیدهای خصوصی ریشه یا رمزنگاری HTTPS به طور کلی خراب شدهاند. به روز رسانی ها بخش زیادی از اکوسیستم اعتماد عمومی را در بر می گیرد. ریسک باقیمانده به کاربرد واقعی بستگی دارد.15
- کاربران منفرد: مرورگرها، سیستم عامل ها و اجزای امنیتی به روز رسانی می شوند. در Android، خدمات Google Play را نیز به روز کنید. از Firefox Android 158.0.2 یا جدیدتر استفاده کنید. 12
- سرورهای : بستههای
ca-certificates/NSS توزیع را بهروزرسانی کنید و فروشگاههای اعتماد همراه با برنامه را بررسی کنید. به روز رسانی فقط میزبان کافی نیست. 7810 - محیط های توسعه: به روز رسانی Node 24 به 24.22.1 یا نسخه جدیدتر در آن شاخه در صورت لزوم. در محیط های Python، حداقل به pip 26.2.2، certifi 2026.10.19، و uv 0.13.4 به روز رسانی کنید. باینری های ثابت Go را بدست آورید یا آنها را بازسازی کنید. Java را طبق توصیه فروشنده خود به روز کنید. 12–15
- Aبهروزرسانیها را فعال کنید: سرویسهای آسیبدیده را مجدداً راهاندازی کنید و کانتینرها را دوباره بسازید و مجدداً مستقر کنید. برای Cloudflare Tunnel، cloudflared را به 2026.10.2 یا جدیدتر به روز کنید. 7
- گواهیهای وبسایت: جایگزین زنجیره آسیبدیده میشود اگر حاوی یک CA لغو یا مسدود شده باشد یا به یک ریشه نامعتبر متکی باشد. صدور مجدد گواهی جایگزین به روز رسانی فروشگاه های اعتماد مشتری نمی شود. 158
- تأیید: مسیر واقعی TLS هر برنامه را آزمایش کنید. تشخیص رد گواهی از مهلت زمانی و خرابی DNS. تأیید گواهی را فعال نگه دارید. برای سرکوب خطاها از
-kاستفاده نکنید یا از تأیید صحت رد شوید. 7
1 حقایق و علل حادثه
حقایق تایید شده
Mozilla و Google نقصهایی را در هشت کلید خصوصی eMudhra میانی CA تأیید کردهاند. محقق مدرک کنترل کلید خصوصی را ارائه کرد. Mozilla به طور مستقل کلیدها را بازیابی کرد و مشکل را دوباره تولید کرد. شش CA میانی TLS و دو سرویس امضای کد را ارائه میکنند. 25
نقص در کلیدهای تولید شده نهفته است: این CAهای میانی از منحنی P-384 استفاده می کنند، اما کلیدهای خصوصی آنها اعداد صحیح زیر 256 هستند. این به دور از انتخاب ایمن کلیدها به صورت تصادفی از محدوده بزرگ مورد نظر است. بازیابی این کلیدهای ضعیف نشان نمی دهد که کلیدهای P-384 که به درستی تولید شده اند می توانند شکسته شوند. 2
“گواهی کرک شده است” در اینجا باید دقیقاً به این صورت درک شود که “کلید خصوصی مربوطه قابل بازیابی است”. گواهی و کلید عمومی موجود در آن ذاتا عمومی هستند. چیزی که واقعاً باید مخفی بماند، کلید خصوصی است که می تواند یک امضای معتبر ایجاد کند.
مسائل فرآیند تولید کلید هنوز در دست بررسی است
شرح اولیه eMudhra مشکل را به یک مراسم تولید کلید در آوریل 2025 نشان میدهد. توضیح شامل یک مرحله کپسولهسازی و کپسولزدایی کلید است: علاوه بر کلید قوی اصلی، مجموعه دیگری از کلیدهای ضعیف ظاهر میشود و کلیدهای ضعیف متعاقباً برای درخواست و صدور گواهی استفاده میشوند. این شرکت هنوز هم گفته است که علت اصلی آن به طور قطعی مشخص نشده است. 6
بنابراین، آنچه می توان تشخیص داد این است که این کلیدها به طور جدی ضعیف هستند و به خطر افتاده اند. این خرابی را نمی توان بیشتر به این دلیل توصیف کرد که منبع شماره تصادفی سخت افزار خاصی از HSM معیوب است و همچنین نمی توان آن را به عنوان یک پیشرفت رمزنگاری کلی از RSA، ECC یا TLS توصیف کرد.
بی اعتمادی گواهی ریشه به چه معناست؟
مرورگر یا سیستم عامل می تواند مستقیماً گواهی یا کلید عمومی واسطه آسیب دیده CA را مسدود کند، یا می تواند اعتماد ریشه منتهی به آنها را حذف کند. اقدام اخیر همچنین برخی از گواهیهای مشروع تحت همین ریشه را رد میکند.
Google حذف emSign ECC Root CA - G3 را برای محافظت از کاربران فروشگاه ریشه Chrome که بهروزرسانیهای CRLSet را دریافت نمیکنند، برنامهریزی کرده است. انتظار می رود حذف root store در دوره مربوطه از 27 تا 28 اکتبر به وقت پکن انجام شود. زمان اصلی Google صبح روز 27 اکتبر، به وقت تابستانی اقیانوس آرام ایالات متحده است. این طرح جدا از انسداد کلید عمومی اضطراری است که قبلاً اجرا شده است. 1
عدم اعتماد به ریشه یک معیار پاسخگویی است. این خود ثابت نمی کند که کلید خصوصی ریشه به خطر افتاده است.
2 چرا تأثیر بالقوه اکوسیستم اعتماد عمومی را در بر می گیرد؟
کلیدهای به خطر افتاده و مسیرهای اعتماد تحت تأثیر قرار گرفته است
| موضوع قضاوت | دامنه این حادثه |
|---|---|
| کلید مشکل ساز شناسایی شد | 8 کلید خصوصی CA میانی برای eMudhra |
| پلتفرم هایی که ممکن است نیاز به اقدام داشته باشند | فروشگاه ریشه عمومی، مرورگر، سیستم عامل، زمان اجرا زبان، بسته نرم افزاری و اکوسیستم کانتینر |
| هویت احتمالاً جعل هویت TLS | وبسایتها یا خدمات بازدید شده توسط مشتریانی که همچنان زنجیره گواهی جعلی مرتبط را میپذیرند |
| یعنی همه دستگاه ها خراب شده اند؟ | خیر؛ شرایط اعتماد، موقعیت شبکه مهاجم و سایر استراتژیهای تأیید، قابلیت بهرهبرداری را تعیین میکنند |
| یعنی همه گواهینامه های قانونی فاقد اعتبار هستند؟ | خیر؛ بی اعتباری مرتبط بستگی به این دارد که مشتری به کدام ریشه یا زنجیره گواهی اعتماد ندارد. |
Red Hat صراحتاً بهرهبرداری را به شرایطی محدود میکند که مشتری همچنان زنجیره مربوطه را میپذیرد، مهاجم کلید خصوصی در معرض خطر را در اختیار دارد و میتواند اتصال را در شبکه رهگیری کند. پوشش ریسک را نباید با تعداد حملاتی که رخ داده است اشتباه گرفت. 10
وبسایتهایی که از CA دیگر استفاده میکنند نیز ممکن است جعل هویت شوند
فرض کنید یک وب سایت در واقع از گواهی Let’s Encrypt استفاده می کند و مشتری بازدیدکننده به چند CA عمومی به طور همزمان اعتماد می کند. یک مهاجم میتواند سعی کند از واسطه در معرض خطر CA برای ایجاد گواهینامه دیگری برای همان نام دامنه استفاده کند. مشتریان معمولاً از قبل نیاز ندارند که نام دامنه فقط بتواند از Let’s Encrypt استفاده کند. اگر زنجیره جعلی همچنان پذیرفته شود، که سایت CA واقعاً از آن استفاده می کند برای رد چنین حملاتی کافی نیست. 8
این مکانیسم توضیح میدهد: جایگزینی گواهی CA دیگری که در ابتدا عادی بود، بهطور خودکار اعتماد مشتری به CA در معرض خطر را ترمیم نمیکند. آنچه واقعاً باید قطع شود، مسیر پذیرش هویت جعلی برای مشتریان است.
این سه اثر باید جداگانه بررسی شوند
خطر جعل هویت : مشتریانی که زنجیره مربوطه را مسدود نکردهاند ممکن است هویت جعل شده توسط مهاجم را بپذیرند و باعث ارسال درخواستهای حساس به سرویسهای جعلی شود.
خطر در دسترس بودن سرویس قانونی: حذف اعتماد ریشه میتواند باعث خطاهای گواهی برای وبسایتهای قانونی شود که ممکن است نیاز به انتقال به زنجیره مورد قبول دیگری داشته باشند.
خطر پوشش استقرار: ممکن است سیستم عامل برطرف شود در حالی که یک فروشگاه اعتماد همراه با برنامه، محیط مجازی، تصویر ظرف قدیمی یا برنامه کامپایل شده رفتار اعتبارسنجی قدیمی را حفظ می کند.
این سه حوزه یکسان نیستند. پاسخ Cloudflare اعتبارسنجی هویت از راه دور، فروشگاههای اعتماد مشترک، تصاویر پایه و برنامههای کاربردی را پوشش میدهد، و نشان میدهد که چرا دو وظیفه آخر باید جداگانه انجام شوند. 7
3 بر CA و ارائه دهندگان گواهی
ارائه دهنده و نوع تاثیر
| ارائه دهنده یا سیستم | نقش در این حادثه | مرزهایی که باید تشخیص داده شوند |
|---|---|---|
| eMudhra/emSign | کلید خصوصی متوسط CA مستقیماً در معرض خطر است. | شما نمی توانید تمام ریشه های eMudhra و همه گواهی ها را به صورت کرک شده بنویسید |
| زنجیره امضای متقابل مربوط به Sectigo | گواهی متقابل A برای همان دسته از کلیدهای عمومی آسیب دیده صادر شد و مسیر اعتماد دیگری را تشکیل داد. | گواهی متقاطع یا کلید عمومی مربوطه باید مسدود شود. ثابت نشده است که کلید خصوصی ریشه Sectigo به خطر افتاده است. |
| سطوح گواهی مربوطه برای Internet2/InCommon | برخی از گواهینامه های قانونی به ریشه emSign ECC برای حذف شدن متکی هستند که شامل مهاجرت می شود | این اثر جانبی بی اعتمادی ریشه است و نمی توان آن را وسط آن 8 کلید ضعیف CA به حساب آورد. |
| Let’s Encrypt، DigiCert، Google Trust Services، GlobalSign، و غیره. | به عنوان طرفی که کلید خصوصی آن در این گزارش به خطر افتاده است، فهرست نشده است | گواهینامه های قانونی به طور یکسان باطل نمی شوند. مشتریان آسیبپذیر ممکن است همچنان گواهیهای جعلی جعل وبسایتهایی را که ارائه میکنند بپذیرند |
| CDN، پلت فرم ابری، فروشنده گواهی | هنگام اتصال به مبدا و API احتمالاً گواهی های مربوطه را ارائه دهید یا از یک فروشگاه اعتماد عمومی استفاده کنید | برای بررسی زنجیره گواهی و اعتبارسنجی واقعی، فقط به پلتفرم یا نام محصول نگاه نکنید |
اطلاعیه Mozilla کلیدهای در معرض خطر و امضاهای متقابل Sectigo را مستند می کند. بحث رویداد عمومی Google به مهاجرت سلسله مراتب قانونی Internet2/InCommon می پردازد. 25 Cloudflare خدمات آدرس و اعتماد مشتری را رفع می کند. آنها به خطر افتادن کلیدهای خصوصی CA خود Cloudflare را نشان نمی دهند. 7
زنجیره گواهی TLS و امضای متقابل
رابطه زیر این بار فقط مسیرهای مربوط به TLS را توصیف می کند. این شامل مسیرهای امضای کد نمی شود و به این معنا نیست که این مسیرها هنوز در همه پلتفرم ها قابل اعتماد هستند. 17
emSign ECC Root CA - G3←emSign Root TLS CA - G3← تحت تأثیر TLS کلید عمومی میانی CA → گواهی جعلی برای دامنه هدفAAA Certificate Services→ TLS میانی CA کلید عمومی → گواهی جعلی برای دامنه هدف
emSign Root TLS CA - G3 یکی از صادرکنندگان مستقیم واسطه های TLS است که تحت تأثیر قرار گرفته است و خود می تواند در برخی فروشگاه ها یک لنگر اعتماد باشد. emSign ECC Root CA - G3 یک لایه علامت متقاطع دیگر را فراهم می کند. Sectigo AAA Certificate Services یک مسیر اضافی برای همان کلیدهای عمومی متوسط CA ایجاد می کند. 17
بنابراین، هنگام تعمیر دو دانه بندی متفاوت وجود دارد:
- کلید میانی دقیق CA یا کلید عمومی را مسدود کنید: این می تواند سلسله مراتب قانونی دیگر را تحت همان ریشه حفظ کند، جایی که اعتباردهنده از آن مکانیسم پشتیبانی می کند.
- حذف اعتماد ریشه: می تواند از کلاینت ها بدون قابلیت مسدودسازی متوسط CA محافظت کند، اما ممکن است سازگاری را تحت تأثیر قرار دهد. تمام مسیرهای دیگری که مشتری می پذیرد نیز باید پوشش داده شود. 5
“حذف تمام ریشه های Sectigo/eMudhra” نباید به عنوان یک گام کلی بی رویه تلقی شود، همچنین نباید صرفاً حذف یک گواهی با نام مشابه به این معنی باشد که همه مسیرها بسته هستند.
4 سیستم عامل و پوشش مرورگر
پلت فرم اصلی
| پلت فرم | منش شناخته شده | محدوده ای که هنگام استفاده باید بررسی شود |
|---|---|---|
| Windows و Windows Server | توزیع Microsoft از طریق بهروزرسانی خودکار فهرست اعتماد گواهی مسدود شد | آیا دستگاه بهروزرسانی را دریافت کرده است یا خیر؛ CA bundle مستقل لزوماً از مسیر تأیید Windows استفاده نمی کند |
| macOS، iOS، iPadOS، و غیره پلت فرم Apple | هماهنگ کننده حادثه تأیید کرد که Apple محاصره مربوطه را مستقر کرده است | هر نسخه قدیمی و برنامه شخص ثالث تضمینی برای دریافت پوشش یکسان نیست |
| Android | Google بلوک های معادل را از طریق سرویس Google Play توزیع می کند | ROM بدون سرویس Google Play باید طبق اعلام سازنده تأیید شود. برای تأیید بیشتر از تأیید کننده داخلی استفاده کنید |
| Ubuntu | اصلاحات بسته گواهینامه سیستم، از جمله چندین شعبه نسخه فعلی و قدیمی ارائه شده است | نسخه قدیمی ESM از شرایط، بسته گواهی داخلی کانتینر و کتابخانه داخلی برنامه پشتیبانی می کند. |
| Debian و Devuan | Debian ثبت شد ca-certificates ثابت شد | شما باید شاخه واقعی استفاده شده و بسته نصب شده را بررسی کنید و نمی توانید شماره نسخه شعبه دیگری را کپی کنید. |
| RHEL و مشتقات | لیست رسمی RHEL 6، 7، 8، 9، 10 است و محصولات و تصاویر مرتبطی را پوشش می دهد که ممکن است تحت تأثیر قرار گیرند. | از زمان این بررسی، این اطلاعیه هنوز لیست کاملی از اصلاحات و اشتباهات را فهرست نکرده است. «بهروزرسانی یافت نشد» را نمیتوان بدون تأثیر در نظر گرفت |
| Fedora، Arch، Gentoo، Alpine، و غیره. | نگهدارنده رویداد، سوابق تعمیر مربوطه را گردآوری کرده است | به طور مستقل توسط انتشار، شاخه نسخه و تصویر تأیید شده است |
| FreeBSD | به طور رسمی تمام نسخه های پشتیبانی شده را لیست می کند و تعمیرات فروشگاه اعتماد سیستم را ارائه می دهد | پس از به روز رسانی، طبق اعلامیه، فرآیند دیمون مربوطه را مجدداً راه اندازی کنید. فروشگاه اعتماد برنامه مستقل را جداگانه بررسی کنید. |
برای خلاصه ای از Windows، Apple و نسخه های منتشر شده، به 4 مراجعه کنید. برای Android، 1 را ببینید. برای Ubuntu، Debian، RHEL، و FreeBSD سوابق صادرکننده به ترتیب در 8–11 نشان داده شده است.
سیستمهایی که دیگر پشتیبانی نمیشوند، دستگاههای آفلاین، NAS، روترها و سایر محیطهای تعبیهشده باید تأیید کنند که آیا هنوز به زنجیره مربوطه اعتماد دارند و آیا کانالهایی برای دریافت لغو یا بهروزرسانیهای نرمافزاری دارند یا خیر. نام پلتفرم خود جایگزینی برای بررسی رفتار راستیآزمایی واقعی نیست.
محافظت از مرورگر با محافظت از سیستم عامل متفاوت است
Chrome از CRLSet برای توزیع بلوک های اضطراری استفاده می کند. Firefox از مکانیسم هایی مانند OneCRL استفاده می کند. Firefox همچنین با اطلاعات مسدود کننده منتشر شده است تا محافظت بیشتری برای پیکربندی هایی که تنظیمات از راه دور را به درستی دریافت نمی کنند، ارائه کند. 13
برخی از پیکربندیهای Firefox Android فهرست بهروزرسانیشده را در هنگام راهاندازی به درستی اعمال نکرده بودند، که Mozilla اعلام کرده است که توسط 158.0.2. رفع شده است، بنابراین، وضعیت 158.0.1 اولیه را نمیتوان گسترش داد تا شامل تمام تنظیمات Android Firefox محافظت شده باشد. 2
اقداماتی برای تأیید سیستم Apple و Windows انجام شده است، اما این بدان معنا نیست که همه برنامه های خط فرمان در یک دستگاه تحت تأیید سیستم قرار می گیرند. نگهدارنده رویداد به طور خاص یادآور شد که برخی از ابزارهای داخلی macOS از فایل های گواهی مستقل استفاده می کنند. هنگام بررسی باید باطن واقعی TLS و منبع CA ثبت شود. 4
مرزهای حفاظتی برای شفافیت گواهی
Google تأیید کرد که قبل از اجرای بلوک، شش TLS CA گواهی TLS را که وارد گزارش CT شده است صادر نکرده است. بنابراین، کلاینتهای Chrome که CT را اعمال میکنند، حفاظت بیشتری دارند. این واقعیت این احتمال را رد نمی کند که سایر کلاینت هایی که CT را اجرا نمی کنند، گواهینامه های غیرمستند را پذیرفته باشند. 15
«معلوم میشود که میتوان آن را به ریشه مورد اعتماد پیوند داد»، «شرایط بهرهبرداری بالقوه وجود دارد» و «حمله رخ داده است» سه قضاوت متفاوت هستند و نباید با یکدیگر جایگزین شوند.
5 محیط توسعه و پایه تعمیر زمان اجرا
موارد زیر پایه ای از اصلاحات تایید شده است و برای پین کردن طولانی مدت این نسخه ها الزامی نیست. توزیعها ممکن است شمارههای نسخههای قدیمیتر را با جابجایی وصلههای برگشتی اصلاح کنند، و توصیههای امنیتی آنها نیز باید بررسی شود.
| اجزاء | نسخه تایید شده یا روش به روز رسانی | ملاحظات استقرار |
|---|---|---|
| Node.js 24 | 24.22.1 یا نسخه پایدار همان شاخه را به روز کنید | حاوی بهروزرسانیهای مخزن ریشه و رد زنجیرههای کلید عمومی مسدود شده است. مسیر Node را که واقعاً توسط سرویس استفاده می شود بررسی کنید و راه اندازی مجدد کنید |
| Python certifi | 2026.10.19 یا نسخه جدیدتر | هر محیط در حال اجرا واقعی را بررسی کنید. شما نمی توانید تنها یک بسته را تحت جهانی Python به روز کنید |
| pip | 26.2.2 یا نسخه جدیدتر | pip را به طور جداگانه در محیط مجازی قدیمی به روز کنید و پس از ایجاد محیط جدید نسخه را بررسی کنید. |
| uv | 0.13.4 یا نسخه جدیدتر | یک نسخه از ابزار را همانطور که واقعاً نصب شده است به روز کنید |
| Go | 1.27.3 یا 1.26.10، نسخه به روز شده شعبه مربوطه نیز موجود است | پس از بهروزرسانی زنجیره ابزار، برنامههای مربوطه را بازسازی و استقرار دهید یا باینری تعمیر فروشنده را دریافت کنید. |
| Oracle JDK | وصله های Critical برای خطوط نسخه پشتیبانی شده مربوطه | ناشران مختلف JDK اعلامیه های خود را دنبال می کنند. هیچ شماره نسخه واحدی وجود ندارد که برای همه نسخههای Java اعمال شود |
| Cloudflare Tunnel | cloudflared 2026.10.2 یا نسخه جدیدتر | به روز رسانی خدمات در حال اجرا؛ استقرار کانتینر نیاز به جایگزینی تصویر و استقرار مجدد دارد |
| Cloudflare One/WARP | نسخه مشتری ثابت مربوط به پلتفرم یا نسخه پایدار به روز شده | اقدامات سمت مشتری و سمت سرور به طور جداگانه تأیید می شوند. برای نسخههای پلتفرم خاص، به پیوست 7 مراجعه کنید |
دستورالعمل اصلی برای Node , Python , Go , Oracle و Cloudflare به ترتیب در دسترس هستند 13 , 12 , 14 , 15 , 7 .
مشکل پایگاه داده گواهی مستقل Python
مقامات Python اشاره کردند که pip قدیمی از ترکیبی از اعتماد سیستم و certifi داخلی استفاده می کند. صرفاً تغییر ذخیرهگاه گواهی سیستم یا افزودن یک فایل CA به pip نمیتواند بهطور قابلاطمینانی اعتماد قدیمی داخلی آن را حذف کند. بنابراین، PIP_CERT، REQUESTS_CA_BUNDLE یا --cert را نمی توان به عنوان جایگزین تعمیر جهانی برای pip قدیمی تر استفاده کرد. 12
پس از بهروزرسانی، محیطهای مجازی موجود را بررسی کنید. همچنین نسخه pip را که واقعاً در محیط های تازه ایجاد شده نصب شده است بررسی کنید تا اجزای بوت استرپ قدیمی تر ابزارهای آسیب پذیر را دوباره معرفی نکنند. برای ارتقای اولیه، منابع دانلود و مراحل تأیید SHA-256 در توصیه Python را قبل از بهروزرسانی بستههای دیگر دنبال کنید. 12
Go و سایر برنامه های کامپایل شده
رفع مشکل Go منطق اعتبارسنجی crypto/x509 را تغییر داد. 14 از منظر مکانیسم استقرار، به روز رسانی کامپایلر در ماشین توسعه، باینری از قبل مستقر شده را بازنویسی نمی کند. برای به دست آوردن مسدودسازی لایه کد جدید، برنامه باید بازسازی و جایگزین شود، یا باید از نسخه به روز شده ارائه شده توسط فروشنده استفاده شود. اینکه یک برنامه قدیمیتر نیز میتواند از بهروزرسانیهای ریشه سیستم بهرهمند شود، به مسیر راستیآزمایی واقعی آن بستگی دارد.
ظروف و برنامه های بسته بندی شده
بسته گواهی سیستم، وابستگی های برنامه و زمان اجرا در کانتینر معمولاً توسط محتوای تصویر تعیین می شود. به روز رسانی هاست برابر با به روز رسانی محتوای تصویر نیست. تصویر اصلی و وابستگی ها باید به روز شوند و نمونه واقعی در حال اجرا نیاز به بازسازی، استقرار و بررسی دارد. برنامه های بسته بندی شده و برنامه های دسکتاپ که با زمان اجرا مخصوص به خود ارائه می شوند نیز باید طبق کانال های عرضه کننده به روز شوند. 710
6 دستورالعمل اجرای تعمیر
ابتدا شیء بازرسی را تعیین کنید
توصیه می شود برای سرویس هایی که نیاز به محافظت دارند اطلاعات زیر را ثبت و سپس مسیر تعمیر مربوطه را انتخاب کنید. این یک چک لیست استقرار است و نیازی به وجود همه اجزا در هر سیستم ندارد.
| پروژه | آنچه باید ثبت شود |
|---|---|
| کاربردها و کاربردها | مرورگر، مشتری پرداخت API، سرویس ارسال ایمیل، ابزار دانلود، پروکسی معکوس و غیره. |
| موقعیت عملیاتی | میزبان، کانتینر، ماشین مجازی، برنامه دسکتاپ یا دستگاه تلفن همراه |
| تایید اجرا | اعتبار سنجی سیستم عامل، OpenSSL، Node، کتابخانه Python، Java یا پیاده سازی سفارشی برنامه |
| منبع قابل اعتماد | بسته سیستم CA، certifi، فروشگاه اعتماد JDK، CA bundle داخلی یا پیکربندی سازمانی |
| وضعیت تعمیر | نسخه نصبشده، منبع وصله، راهاندازی مجدد یا راهاندازی مجدد |
| نتایج پذیرش | اینکه آیا زنجیره آسیبدیده رد میشود، آیا اتصال عادی تجاری موفقیتآمیز است و زمان بررسی |
راهنمای توسعهدهنده Cloudflare به طور خاص بیان میکند که SDK ممکن است تأیید را به سایر مؤلفهها واگذار کند. فقط به روز رسانی SDK سطح بالا لزوماً سیاست اعتماد واقعی را تغییر نمی دهد. 7
سیستم عامل ها و مرورگرها
Windows: به روز رسانی خودکار لیست اعتماد گواهی را فعال و تأیید کنید. به روز رسانی ها را از طریق سیاست های مدیریتی تعیین شده توزیع کنید. دستگاههای آفلاین یا دستگاههایی که بهروزرسانیهای خودکار غیرفعال است، نیاز به بلوک دارند که از طریق فرآیند مدیریت مناسب اعمال شود. برنامه هایی را که از اعتبارسنجی سیستم Windows استفاده نمی کنند به طور جداگانه بررسی کنید. 4
پلت فرم Apple: سیستم کامل، اجزای امنیتی و به روز رسانی برنامه ها. برای ابزارهای توسعه در macOS، فایلهای گواهینامه و منابع نصب TLS را نیز بررسی کنید. نمی توان قضاوت کرد که کل دستگاه فقط به این دلیل که Safari زنجیره آزمایش را رد کرده است، تعمیر شده است. 4
Android: به روز رسانی خدمات Google Play در دستگاه هایی که آن را دارند. Google بیان میکند که راهاندازی مجدد دستگاه میتواند باعث بروز رسانی فوری شود. برای دستگاههایی که این خدمات را ندارند، توصیههای فروشنده یا ROM را دنبال کنید. بیانیه پوشش Google به طور خودکار برای هر دستگاه Android اعمال نمی شود. 1
بسته های گواهی به روز رسانی Ubuntu/Debian: از مخازن پشتیبانی شده و توصیه های توزیع نصب شده را بررسی کنید. به عنوان مثال، یک سیستم مبتنی بر APT می تواند از موارد زیر استفاده کند:
sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates
بهروزرسانیهای مربوط به Ubuntu 22.04، 24.04، 26.04، و 26.10 پشتیبانی استاندارد هستند. نسخه های قبلی باید پشتیبانی ESM و وضعیت انبار را بررسی کنند. پس از پایان موفقیت آمیز دستور، همچنان باید نسخه فیکس پک را در بولتن مقایسه کنید. 89
RHEL و محصولات مرتبط: بسته گواهینامه و خطاهای امنیتی را بر اساس کانال محصول بررسی کنید. بررسی نسخه را می توان با استفاده از:
rpm -q ca-certificates
از مکانیزم بهروزرسانی DNF/YUM پشتیبانیشده برای بهدست آوردن وصلههای فروشنده استفاده کنید. اگر کانال هنوز راه حلی ارائه نکرده است، “بدون بسته قابل به روز رسانی” را ایمن ندانید. در صورت نیاز به حذف موقت اعتماد ریشه، اقداماتی را اتخاذ کنید که به وضوح توسط سازنده فهرست شده است و سازگاری گواهینامه های تجاری قانونی را ارزیابی کنید. 10
FreeBSD: شعبه سیستم مربوطه را طبق دستورالعمل رسمی به روز رسانی کنید، سپس دیمون ها را با استفاده از پیکربندی اعتماد آسیب دیده OpenSSL راه اندازی مجدد کنید یا سیستم را راه اندازی مجدد کنید. 11
برنامه ها و تصاویر
پس از تکمیل زمان اجرا و بهروزرسانیهای وابستگی گواهینامه، مسیر فایل اجرایی که در آن سرویس واقعاً در حال اجرا است را بررسی کنید تا از اینکه ترمینال به نسخه جدیدی تغییر کند و دیمون همچنان از دایرکتوری نصب قدیمی استفاده میکند، جلوگیری کنید. برای Python چند محیطی، کانتینرهای سرویس و برنامههایی که با زمان اجرا خودشان ارائه میشوند، باید جداگانه بررسی شوند.
برای اجزایی که نیاز به بازسازی دارند، نسخه ساخت، نسخه وابستگی و شناسه تصویر استقرار را ذخیره کنید. شیء پذیرش نمونه واقعی در حال اجرا است و نمی تواند فقط برچسب جدید را در ماشین ساخت یا رجیستری تصویر بررسی کند. 71214
انتقال گواهی وب سایت
اگر زنجیره یک وبسایت حاوی یک واسطه CA لغو یا مسدود شده است، یا در نهایت به ریشهای غیرقابل اعتماد متکی است، زنجیره دیگری را تهیه کنید که مشتریان همچنان آن را میپذیرند. زنجیره کامل گواهی سرور را نصب کنید و هر ورودی را بررسی کنید، از جمله متعادل کننده های بار، پراکسی های معکوس، نقاط پایانی CDN و مبداهای قابل دسترسی مستقیم. 15
اینکه آیا مهاجرت مورد نیاز است بر اساس زنجیره واقعی است. فیلتر کردن فقط بر اساس نام تجاری فروش گواهی ممکن است روابط فروش مجدد یا امضای متقابل را از دست بدهد. فقط انتظار برای تمدید انقضای منظم ممکن است لزوماً مهاجرت را قبل از بهروزرسانی فروشگاه ریشه کامل نکند.
برای سایر گواهیهای وبسایت عادی صادر شده توسط CA که به ریشه آسیبدیده متکی نیستند، به دلیل این حادثه نیازی به امضای مجدد آنها نیست. در عین حال، سرور وب سایت خود هنوز باید هنگام تماس با سرویس های خارجی، بررسی های تعمیر سمت مشتری را انجام دهد.
7 بررسی کنید که اصلاح واقعاً مؤثر است
بررسی نسخه و بررسی رفتار به طور جداگانه انجام می شود
بررسی نسخه برای تأیید اینکه وصله ها یا مؤلفه های ثابت مستقر شده اند استفاده می شود. بررسی های رفتاری برای تأیید اینکه برنامه واقعاً از مسیر تأیید مورد انتظار استفاده می کند استفاده می شود. این دو چک مشکلات مختلفی را حل میکنند و هیچ یک از آنها را نمیتوان با «فرمان بهروزرسانی با موفقیت اجرا شد» جایگزین کرد.
نگهدار رویداد، محل آزمایش و مواد زنجیره گواهی را فراهم می کند و ورودی در ضمیمه 4 متمرکز شده است. باید در محیط عملیاتی واقعی برنامه هدف، با حفظ پیکربندی تأیید گواهی عادی تأیید شود. 47
| نتایج را بررسی کنید | نتیجه گیری هایی که می توان گرفت |
|---|---|
| صریحاً رد کنید زیرا زنجیره آسیب دیده قابل اعتماد نیست | نشان می دهد که مسیر تأیید در حال آزمایش زنجیره را رد کرده است |
| زنجیره آسیب دیده را به طور معمول بپذیرید | نشان می دهد که این مسیر باید به تعمیر ادامه یابد یا پیکربندی بررسی شود. |
| خطای DNS، مهلت زمانی اتصال، رد پراکسی یا سرویس غیرقابل دسترسی | نمی توان نتیجه گرفت که بر این اساس ریسک گواهی حذف شده است. |
| مرورگر رد میکند، اما تماس برنامه بررسی نمیشود | فقط می تواند مرورگر را تأیید کند، نه برنامه پس زمینه. |
| زنجیره A رد شد | هنوز باید در نظر بگیرید که آیا مشتری مسیر دیگری را برای امضای متقابل قبول می کند یا خیر |
این آزمایش همچنین باید اتصالات تجاری معمولی را پوشش دهد تا از اشتباه گرفتن همه شکستهای درخواستی جلوگیری شود زیرا تعمیرات موفق پس از شکست کسبوکار ناشی از حذف اعتماد بیش از حد است.
شرایط تکمیل پیشنهادی
- منبع بهروزرسانی و نسخه مؤلفههای آسیبدیده مستند شده است.
- نمونه در حال اجرا مربوطه مجدداً راه اندازی، بازسازی یا مستقر شده است.
- برنامه واقعی زنجیره آسیب دیده را رد می کند و تأیید TLS برای تجارت عادی به کار خود ادامه می دهد.
- هیچ پیکربندی برای خاموش کردن موقت تأیید گواهی به منظور بازیابی اتصال وجود ندارد.
- اگر انتقال گواهی وب سایت درگیر باشد، همه ورودی های خارجی تغییر و تأیید شده اند.
شرایط تکمیل فوق پیشنهاداتی برای پذیرش عملیات و نگهداری برای این دفع است. این معادل اثبات این نیست که تجهیزات هیچ مشکل ایمنی دیگری ندارند.
8 ترافیک تاریخی HTTPS و مرزهای خطر
سه نوع کلید کاربردهای متفاوتی دارند
| کلید | هدف اصلی |
|---|---|
| کلید خصوصی CA | شناسه و کلید عمومی الزام آور در گواهی را امضا کنید |
| کلید خصوصی وب سایت | هویت سرور را در دست دادن TLS تأیید شده گواهی تأیید کنید |
| کلید جلسه | از داده هایی که واقعاً در یک اتصال منتقل می شود محافظت کنید |
دریافت کلید خصوصی CA معادل به دست آوردن کلید خصوصی وب سایت یا تمام کلیدهای جلسه نیست. اتصال معمولی A با محرمانه بودن رو به جلو با استفاده از مبادله موقت کلید، به طور خودکار جلسات تاریخی را نشان نمی دهد، فقط به این دلیل که کلید امضای بلندمدت بعداً به خطر می افتد. برای ویژگی های امنیتی مربوط به TLS 1.3، به RFC 8446 مراجعه کنید. 16
خطر اصلی این بار در مرحله احراز هویت رخ می دهد: اگر مشتری گواهی سرور جعلی را بپذیرد، ممکن است ارتباطی با مهاجم برقرار کند که هنوز رمزگذاری شده است. TLS 1.3 همچنین به احراز هویت قابل اعتماد نیاز دارد. صرفاً ارتقاء نسخه پروتکل جایگزینی برای مسدود کردن CA نیست.
قضاوت هایی که در حال حاضر می توان و نمی توان کرد
تأیید شده: کلیدهای خصوصی متوسط CA به خطر افتاده است. مسیرهای اعتماد عمومی تحت تأثیر دامنه وسیعی دارند. پلتفرم های بزرگ و چندین اکوسیستم نرم افزاری اقدام کرده اند. 145
با این حادثه مشخص نشده است: که همه کاربران حملات انسان در وسط را تجربه کرده اند، سایر کلیدهای خصوصی CA به خطر افتاده اند، اینکه تمام ترافیک تاریخی HTTPS قابل رمزگشایی است، یا اینکه به روز رسانی در یک مرورگر از هر برنامه ای محافظت می کند.
قضاوت نهایی در مورد یک سرویس خاص باید بر اساس زنجیره گواهی آن، خط مشی تأیید، مؤلفه های در حال اجرا واقعی و وضعیت به روز رسانی باشد، نه فقط اینکه آیا نوار آدرس HTTPS را می خواند یا خیر.
ضمیمه A نام متوسط تحت تأثیر CA
نامهای زیر به بررسی دارایی کمک میکنند. نام ها جایگزین اثر انگشت گواهی یا شناسه های کلید عمومی نمی شوند. تطبیق خودکار باید از شناسههای دقیق منتشر شده توسط نگهبانان یا فروشندگان حادثه، از جمله گواهیهای متقاطع استفاده کند. 5
| CA وسط | هدف | سازمان های مرتبط |
|---|---|---|
| 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 | امضای کد | eMudhra BV |
| EM OV CS CA - G3C | امضای کد | eMudhra Inc |
TLS دقیقاً همان مکانیسم اعتبارسنجی و ابطال امضای کد نیست. تمرکز این مقاله HTTPS/TLS است. محیط امضای کد باید Microsoft، JDK یا فروشندگان نرم افزار مرتبط را برای این منظور تأیید کند، و نتایج آزمایش مرورگر نباید به عنوان پذیرش امضای کد در نظر گرفته شود. 515
پیوست B لینک مرجع
منابع زیر در 22 اکتبر 2026 تأیید شدهاند. این اعلامیه ممکن است همچنان بهروزرسانی شود و وضعیت و نسخه موجود در متن باید براساس تاریخ این سند درک شود.
حقایق حادثه و مدیریت پلت فرم
[1] Google Chrome و Android اطلاعیه رسمی نقص های کلید خصوصی، مسدود کردن SPKI، توزیع سرویس Google Play، حفاظت CT و برنامه های حذف مخزن ریشه Chrome را شرح می دهد. Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
[2] Mozilla Bugzilla 2083449 ثبت رویداد شامل گزارشهای اصلی، تأیید مستقل، بررسی فرآیند تولید، اصلاحات بعدی برای Firefox Android، و بحثهای مهاجرت گواهی قانونی. روی نظرات 5، 11، 29 و 30 تمرکز کنید. eMudhra Private key compromise of Intermediate Certificates
[3] Mozilla Firefox اعلامیه امنیتی شرح توزیع اضطراری OneCRL و دفع بعدی Firefox/NSS. Protecting Firefox users following the compromise of eMudhra intermediate certificates
[4] هماهنگ کننده رویداد Dennis Jackson خلاصه نگهداری و پورتال تشخیص دستورالعمل های تکمیلی در مورد وضعیت تعمیر پلت فرم و نرم افزار، ورودی آزمون، مواد زنجیره ای گواهی عمومی و محیط هایی مانند Windows/macOS ارائه می دهد. نتایج آزمایش فقط نشان دهنده مسیرهای تأیید واقعی آزمایش شده است. eMudhra Intermediate CA Compromise
[5] Mozilla اطلاعیه به نگهبانان توزیع و فروشگاه اعتماد 6 TLS و 2 واسطه امضای کد CA، Sectigo امضای متقاطع، ابطال، و مرزهای پردازش اعتماد ریشه را توصیف می کند و گواهی دقیق و شناسایی کلید عمومی را فهرست می کند. oss-security eMudhra Intermediates Compromise
[6] eMudhra بیانیه رویداد رسمی توضیحات اولیه سازنده را در مورد فرآیند تولید کلید ارائه دهید. علت اصلی دقیق همچنان منوط به نتیجه گیری تحقیقات تکمیل شده خواهد بود. eMudhra Statement on Recent Certificate Security Incident
[7] Cloudflare دستورالعمل رسمی حادثه و تعمیر WARP، Cloudflare Tunnel، تأیید سایت مبدا، وابستگیهای زمان اجرا، بهروزرسانیهای تصویر و روشهای تأیید را پوشش میدهد. 8 eMudhra certificates are compromised Here is what you need to know
سیستم عامل ها و توزیع ها
[8] Ubuntu اطلاعیه تعمیر رسمی بستههای تعمیر ca-certificates، کانالهای پشتیبانی و مراحل بهروزرسانی هدفمند را برای هر نسخه فهرست میکند. eMudhra CA compromise fixes available
[9] Debian سابقه رسمی مشکل و تعمیر رکورد تعمیر نگهدارنده و بسته انتشار مربوطه باید به عنوان استاندارد در نظر گرفته شود و پیشنهادات موقت اولیه در بحث مشکل نباید به عنوان راه حل نهایی در نظر گرفته شود. Debian bug 1151413 eMudhra Intermediate CA key compromise
[10] Red Hat بولتن رسمی ایمنی RHSB 2026 012 RHEL 6 تا 10 مورد را فهرست میکند، اثرات مربوط به محصول و ظرف، و تصحیح ورودیهای انتشار و دفع موقت. Certificate compromise eMudhra
[11] FreeBSD بولتن رسمی امنیتی شاخه های سیستم آسیب دیده، نسخه های تعمیر و الزامات راه اندازی مجدد سرویس را ارائه دهید. FreeBSD SA 26 73 caroot
زمان اجرا و پروتکل ها
[12] Python شرح رویداد رسمی خطوط پایه تعمیر را برای pip، certifi، uv و غیره ارائه می دهد، مشکل فروشگاه اعتماد مستقل قدیمی pip را توضیح می دهد و روش ارتقای اولیه را با تأیید SHA-256 ارائه می دهد. Information for Python users regarding eMudhra emSign CA certificate security incident
[13] Node.js 24.22.1 انتشار رسمی حاوی بهروزرسانیهای فروشگاه ریشه NSS است و تغییرات حاوی زنجیرههای گواهی کلید عمومی مسدود شده را رد میکند. Node.js 24.22.1 security release
[14] Go انتشار رسمی امنیتی توضیحات به روز رسانی فیلتر زنجیره گواهی crypto/x509 برای Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released
[15] Oracle JDK دستورالعمل های دفع رسمی وصله حیاتی JDK و اقدامات پیکربندی مربوطه را هنگامی که نمی توان فوراً ارتقا داد توضیح دهید. Distrusting eMudhra Intermediate Certificates in Oracle JDK
استاندارد پروتکل [16] TLS 1.3 RFC 8446 برای دستورالعملهای مربوط به احراز هویت، تعویض موقت کلید و محرمانگی فوروارد، به پیوست E.1 مراجعه کنید. The Transport Layer Security Protocol Version 1.3
[17] گواهی ریشه مرتبط با رویداد و داده های ارتباط صدور برای درک رابطه صادرکننده مستقیم و امضای متقابل استفاده می شود. وضعیت گنجاندن فروشگاه ریشه نمی تواند جایگزین آخرین وضعیت لغو یا مسدود کردن مشتری شود. Root certificate relationships JSON