فرض کنید اپِ بانکی یا سرویسِ استریمِ خود را باز میکنید. هیچ هشداری نمیبینید و همهچیز عادی است. این آرامش به یک فرض تکیه دارد: سروری که به آن وصل شدهاید همان سروری است که ادعا میکند. در اکتبرِ ۲۰۲۶ معلوم شد این فرض در یک جای زنجیره ترک برداشته است. کلیدهای خصوصیِ هشت گواهیِ میانی متعلق به شرکتِ هندیِ eMudhra چنان ضعیف ساخته شده بودند که هر کسی میتوانست آنها را حساب کند. ماجرای گواهیهای eMudhra را از این زاویه مرور میکنیم: بعد از واکنشِ سریعِ مرورگرها، خطر هنوز کجا مانده و سهمِ شما بهعنوانِ کاربر چیست؟
در یک نگاه
کلیدهای خصوصیِ هشت گواهیِ میانیِ eMudhra با حداکثر ۲۵۶ حدس پیدا میشدند. با این کلیدها میشد برای هر دامنهای گواهیِ جعلی ساخت. Mozilla و Google این گواهیها را مسدود کردند. خطرِ باقیمانده در اپها، سرورها، کانتینرها و ابزارهایی است که مخزنِ اعتمادِ جداگانه دارند و باید جدا بهروز شوند.
- کلیدهای خصوصیِ هشت گواهیِ میانیِ eMudhra، که در ۳۰ آوریلِ ۲۰۲۵ ساخته شده بودند، همگی عددی کمتر از ۲۵۶ بودند و با حدس پیدا میشدند.
- از این هشت گواهی، ششتا برای صدورِ گواهیِ TLSِ وبسایتها و دوتا برای امضای کد به کار میرفتند.
- Mozilla این گواهیها را از راهِ سامانهٔ OneCRL مسدود کرد و کاربرِ فایرفاکس برای این حفاظت به بهروزرسانی یا راهاندازیِ دوبارهٔ مرورگر نیاز نداشت.
- برنامههای Go، اپهای Python که از certifi استفاده میکنند، سرویسهای Node.js، کلاینتهای API و دستگاههایی که ابطالِ گواهی را بررسی نمیکنند، تا بهروز نشوند ممکن است همچنان به این گواهیها اعتماد کنند.
- مهمترین کارِ کاربرِ عادی در این ماجرا بهروز نگهداشتنِ سیستمعامل و اپها از منبعِ رسمی است. اقدام روی سرور و زیرساخت با متخصصِ امنیتِ دارای صلاحیت است.
گواهیِ میانی چیست و چرا لو رفتنِ کلیدش اینقدر خطرناک است؟
گواهیِ میانی واسطهای است که میتواند برای وبسایتها شناسنامهٔ دیجیتال صادر کند. هر کس کلیدِ خصوصیِ آن را داشته باشد، عملاً میتواند برای هر سروری در اینترنت گواهیِ معتبر بسازد. Ars Technica در گزارشِ ۲۰ اکتبرِ ۲۰۲۶ دقیقاً به همین نکته اشاره کرد.
برای فهمِ ماجرا، HTTPS را زنجیرهای در نظر بگیرید. در بالای زنجیره «ریشه» قرار دارد، یعنی مرجعی که مرورگر و سیستمعامل از پیش به آن اعتماد دارند. ریشه به چند «میانی» اعتبار میدهد و میانیها برای سایتها گواهی صادر میکنند. اگر کلیدِ یک میانی لو برود، هر گواهیای که با آن امضا شود از نگاهِ نرمافزار کاملاً درست به نظر میرسد.
Cloudflare پیامدِ عملیِ این وضع را روشن گفته است. مهاجم میتوانست برای هر دامنهای گواهیِ جعلی بسازد، خودش را جای سرورِ واقعی جا بزند و ترافیک را شنود یا دستکاری کند. Mozilla و برنامهٔ Rootِ گوگل کروم هم تأیید کردند که کلیدهای خصوصیِ هر هشت گواهیِ CAِ میانیِ eMudhra لو رفتهاند. CA یعنی مرجعِ صدورِ گواهی.
کلیدهای eMudhra چطور اینقدر ضعیف ساخته شدند؟
کلیدها با یک خطای فرایندی ضعیف شدند، نه با حملهٔ پیچیده. هر هشت کلید از نوعِ P-384 بودند، یعنی کلیدهایی مبتنی بر «منحنیِ بیضوی». در این روشِ رمزنگاری، امنیت به این بستگی دارد که کلیدِ خصوصی عددی بسیار بزرگ و تصادفی باشد. مقدارِ خصوصیِ همهٔ این کلیدها کمتر از ۲۵۶ بود. یعنی با امتحانِ حداکثر ۲۵۶ عدد میشد آنها را پیدا کرد.
برای تصورِ این ضعف، قفلِ گاوصندوقی را در نظر بگیرید که باید رمزی با میلیاردها حالت داشته باشد، اما فقط ۲۵۶ ترکیب دارد. حتی با دست هم در چند دقیقه باز میشود. برای یک رایانه، امتحانِ ۲۵۶ عدد تقریباً هیچ زمانی نمیبرد.
طبقِ بررسیِ اولیهٔ خودِ eMudhra، کلیدها در ۳۰ آوریلِ ۲۰۲۵ و در «مراسمِ تولیدِ کلید» با ماژولهای امنیتیِ سختافزاریِ Utimaco ساخته شدند. ماژولِ امنیتیِ سختافزاری دستگاهی ویژه برای ساخت و نگهداریِ امنِ کلیدهاست. یک اسکریپتِ معیوب کنارِ کلیدهای درست چند کلیدِ ضعیف هم ساخت. برچسبِ کلیدها شبیه هم بود و کارکنان بهاشتباه کلیدهای ضعیف را در درخواستِ امضای گواهی (CSR) به کار بردند.
یک نکتهٔ مهم دربارهٔ عددِ «هشت» هم هست. عنوانِ Ars Technica از «۸ گواهیِ TLS» حرف میزند، اما طبقِ The Hacker News فقط ششتا برای صدورِ گواهیِ TLSِ وبسایتها بودند. دوتای دیگر برای امضای کد، یعنی تأییدِ اصالتِ نرمافزار، به کار میرفتند.
چه کسی ماجرا را کشف کرد و واکنشها چقدر سریع بود؟
یک پژوهشگرِ مستقل مشکل را پیدا کرد و مرورگرها در عرضِ چند روز واکنش نشان دادند. تاریخها در منابع کمی با هم فرق دارند و بینِ ۱۷ تا ۲۰ اکتبرِ ۲۰۲۶ قرار میگیرند. ترتیبِ رویدادها طبقِ منابعِ موجود این است:

- ۱۷ اکتبر: پژوهشگری با نامِ Wayne هنگامِ بررسیِ گواهیهای پایگاهِ مشترکِ CAها (CCADB) به مشکل برخورد. او با امضای یک پیام با هر هشت کلید نشان داد که همه را در اختیار دارد. سپس به eMudhra و برنامههای Rootِ مرورگرها خبر داد.
- ۱۷ اکتبر: Mozilla گواهیها را از راهِ OneCRL مسدود کرد. OneCRL فهرستِ سیاهی است که فایرفاکس خودکار دریافت میکند و برای اعمالش نیازی به بهروزرسانی یا راهاندازیِ دوبارهٔ مرورگر نبود.
- ۱۹ اکتبر: Cloudflare از ماجرا باخبر شد. بررسیِ امنیتیِ این شرکت نشانهای از سوءاستفادهٔ فعال روی سرویسهایش پیدا نکرد.
- ۲۰ اکتبر: Ars Technica گزارشِ خود را منتشر کرد.
- پس از اقدامِ Google و Mozilla، سهامِ eMudhra با ۲۰٪ افت به سقفِ مجازِ ریزشِ روزانه رسید. وزارتِ الکترونیک و فناوری اطلاعاتِ هند (MeitY) هم تیمی برای بررسی تشکیل داد و اعلام کرد خدماتِ امضای دیجیتال آسیبی ندیدهاند.
مرورگرها بسته شدند؛ پس خطرِ گواهیهای eMudhra هنوز کجاست؟
خطرِ باقیمانده بیرون از مرورگر است. بسیاری از نرمافزارها به فهرستِ اعتمادِ مرورگر نگاه نمیکنند. آنها «مخزنِ اعتماد»ِ خودشان را دارند، یعنی فهرستی از ریشهها و گواهیهایی که به آنها اعتماد میکنند. تا این فهرست بهروز نشود، گواهیِ جعلی برایشان معتبر میماند.

طبقِ تحلیلِ ctlogs.dev، این گروه شاملِ برنامههای نوشتهشده با Go، اپهای Python که از بستهٔ certifi استفاده میکنند، سرویسهای Node.js، مخزنهای اعتمادِ سفارشی یا همراهِ نرمافزار، سرورهای مبدأ، کلاینتهای API و دستگاههایی است که ابطالِ گواهی یا CT را بررسی نمیکنند. CT یا Certificate Transparency دفترِ عمومیای است که صدورِ گواهیها در آن ثبت میشود. Cloudflare هم هشدار داد مشتریانی که سرورِ خودشان، mTLS یا کانتینر دارند شاید لازم باشد خودشان اقدام کنند. mTLS حالتی است که هر دو طرف، یعنی سرور و کاربر، گواهی نشان میدهند.
خبرِ خوب این است که وصلهها برای Go، Python، Node.js، Java و توزیعهای اصلیِ لینوکس منتشر شدهاند. Cloudflare هم Cloudflare One Client و Cloudflare Tunnel را بهروز کرد و روی محصولاتِ CDN، Developer و Zero Trust راهکارِ کاهشِ خطر پیاده کرد. اما وصله تا نصب نشود فایدهای ندارد. جدولِ زیر نشان میدهد هر بخش از زنجیره دستِ کیست:
- کجا: فایرفاکس · وضعیت طبقِ منابع: مسدود از راهِ OneCRL، بینیاز به بهروزرسانی · چه کسی باید اقدام کند: Mozilla انجام داده است
- کجا: کروم · وضعیت طبقِ منابع: برنامهٔ Rootِ کروم لو رفتن را تأیید کرد و Google اقدام کرد · چه کسی باید اقدام کند: کاربر: مرورگر را بهروز نگه دارد
- کجا: اپها و ابزارهای Go، Python (certifi)، Node.js، Java · وضعیت طبقِ منابع: وصله منتشر شده است · چه کسی باید اقدام کند: توسعهدهندهٔ اپ؛ کاربر باید نسخهٔ تازه را نصب کند
- کجا: توزیعهای اصلیِ لینوکس · وضعیت طبقِ منابع: وصله منتشر شده است · چه کسی باید اقدام کند: مدیرِ سیستم یا کاربرِ لینوکس
- کجا: سرورهای شخصی، mTLS، کانتینرها · وضعیت طبقِ منابع: مسدودسازیِ مرورگر کافی نیست · چه کسی باید اقدام کند: تیمِ فنی یا متخصصِ امنیت
- کجا: دستگاههایی که ابطال یا CT را بررسی نمیکنند · وضعیت طبقِ منابع: ممکن است همچنان اعتماد کنند · چه کسی باید اقدام کند: سازندهٔ دستگاه از راهِ بهروزرسانیِ رسمی
من کاربرِ اپِ پرداخت و سرویسِ اشتراکی هستم؛ چه کار کنم؟
سهمِ شما ساده است: سیستمعامل و اپها را بهروز نگه دارید. اپِ بانکی، کیفِ پول یا اپِ سرویسِ استریم اگر مخزنِ اعتمادِ خودش را داشته باشد، فقط با نسخهٔ تازه فهرستِ اصلاحشده را دریافت میکند. بهروزرسانی را فقط از منبعِ رسمی بگیرید، یعنی فروشگاهِ رسمیِ اپ یا سایتِ رسمیِ سازنده. فایلِ نصبیِ یک کانال یا پیامِ ناشناس میتواند خودش راهِ نفوذ باشد.
هشدارِ گواهی در مرورگر یا اپ را جدی بگیرید و از آن رد نشوید. عادتهای پایه را هم کنار نگذارید: رمزِ قوی و جداگانه برای هر سرویس، فعالکردنِ ورودِ دومرحلهای، و شک به هر پیامکی که شما را به صفحهٔ پرداخت یا ورود میکشاند. گواهیِ جعلی برای مهاجم فقط وقتی به کار میآید که شما را به مسیرِ اشتباه بکشاند.
اگر کسبوکار، سرور یا اپِ خودتان را دارید، موضوع جدیتر است. بررسیِ مخزنهای اعتماد، کانتینرها و پیکربندیِ mTLS کارِ تخصصی است. تصمیم و اجرا را به متخصصِ امنیتِ دارای صلاحیت بسپارید و راهنمای رسمیِ سازندهٔ هر ابزار را مبنا قرار دهید.
این ماجرا چه ربطی به گواهیهای دیجیتالِ ایران دارد؟
ربطِ مستقیمی ندارد؛ شباهت فقط در ساختارِ ریشه و میانی است. eMudhra در هند مرجعِ صدورِ گواهیِ دارای مجوز است. این مجوز را دفترِ کنترلکنندهٔ مراجعِ صدورِ گواهی (CCA) طبقِ قانونِ فناوری اطلاعاتِ ۲۰۰۰ هند داده است. CCA از ۱ نوامبرِ ۲۰۰۰ فعال است. این مقررات فقط در هند اعتبار دارد. برنامههای Rootِ مرورگرها هم قواعدِ خودِ Mozilla و Google هستند، نه قانونِ کشوری.
در ایران، آییننامهٔ اجرایی مادهٔ ۳۲ قانونِ تجارتِ الکترونیکی ساختارِ مراکزِ صدورِ گواهیِ الکترونیکی را تعیین میکند. مرکزِ ریشه زیرِ نظرِ دولت است. مراکزِ میانی را بخشِ خصوصی یا دستگاههای دولتی در حوزههای تخصصی راه میاندازند. این آییننامه دربارهٔ امضای الکترونیکی و زیرساختِ کلیدِ عمومیِ داخلی است و ربطی به اعتمادِ مرورگرها به سایتها ندارد.
زومیت هم گزارش داده که پس از قطعیِ چندبارهٔ گواهیهای امنیتیِ بانکها و باطلشدنِ گواهیها از سوی صادرکنندگانِ خارجی، ایران به سمتِ گواهیِ SSLِ داخلی رفت. وضعیتِ فعلیِ این طرح را بررسی نکردهایم. درسِ ماجرای eMudhra برای هر زیرساختی، داخلی یا خارجی، یکی است: امنیتِ کلِ زنجیره به دقتِ ساختِ هر کلید بستگی دارد.
پرسشهای پرتکرار
آیا اطلاعاتِ حسابِ من در سرویسهای استریم یا بانکی لو رفته است؟
منابع از لو رفتنِ اطلاعاتِ کاربران حرف نمیزنند. آنچه لو رفت کلیدِ هشت گواهیِ میانی بود. Cloudflare هم نشانهای از سوءاستفادهٔ فعال روی سرویسهایش پیدا نکرد. بهترین کارِ شما بهروز نگهداشتنِ اپها و سیستمعامل است.
اگر از فایرفاکس یا کروم استفاده کنم، کاری لازم است؟
فایرفاکس این گواهیها را از راهِ OneCRL مسدود کرده است و نیازی به بهروزرسانی یا راهاندازیِ دوباره ندارد. Google هم اقدام کرده است. در هر حال مرورگرتان را بهروز نگه دارید.
چرا بهروزرسانیِ مرورگر برای اپها کافی نیست؟
بسیاری از اپها، سرورها و ابزارها مخزنِ اعتمادِ جداگانه دارند و به فهرستِ مرورگر نگاه نمیکنند. تا خودشان یا بستهٔ Rootِ آنها بهروز نشود، ممکن است همچنان به این گواهیها اعتماد کنند.
این ماجرا به گواهیهای امضای دیجیتالِ ایران مربوط است؟
نه. eMudhra مرجعی دارای مجوز در هند است و زیرساختِ امضای الکترونیکیِ ایران تابعِ آییننامهٔ اجرایی مادهٔ ۳۲ قانونِ تجارتِ الکترونیکی است. شباهت فقط در ساختارِ ریشه و میانی است.
جمعبندی
ماجرای گواهیهای eMudhra نشان داد زنجیرهٔ اعتمادِ HTTPS به اندازهٔ ضعیفترین حلقهاش محکم است و یک اسکریپتِ معیوب میتواند کلیدی بسازد که با ۲۵۶ حدس باز شود. مرورگرها در چند روز واکنش نشان دادند، اما اینترنت فقط مرورگر نیست. اپها، سرورها، کانتینرها و دستگاهها هرکدام باید جداگانه بهروز شوند. برای شما بهعنوانِ کاربر، کار روشن است: بهروزرسانیِ رسمی را عقب نیندازید، هشدارهای امنیتی را جدی بگیرید و کارِ زیرساخت را به متخصص بسپارید.





نظرها
هنوز نظری ثبت نشده. اولین نفری باشید که نظر میدهد.
نظر شما