ماجرای گواهی‌های تقلبی 1.1.1.1 کلادفلر

شرکتی که این کار رو کرده بود «فاینا سی‌ای» (Fina CA) نام داشت. این شرکت از فوریه ۲۰۲۴ تا آگوست ۲۰۲۵، دوازده تا گواهی برای آدرس 1.1.1.1 بدون اجازه کلادفلر صادر کرده بود. نکته مهم اینه که کلادفلر بررسی کرد و دید که این صدور غیرمجاز فقط برای 1.1.1.1 اتفاق افتاده و برای بقیه دامنه‌ها و سرویس‌هاش مشکلی پیش نیومده.

حالا سوال اصلی اینه که آیا کسی از این گواهی‌های تقلبی سو استفاده کرده؟ کلادفلر میگه هیچ مدرکی پیدا نکرده که نشون بده آدم‌های خلافکار از این اشتباه سو استفاده کرده باشن. برای اینکه یه هکر بتونه خودشو جای سرویس DNS کلادفلر جا بزنه، فقط داشتن یه گواهی غیرمجاز و کلید خصوصی مربوط به اون کافی نیست. چند تا شرط دیگه هم لازمه:

1. کاربرهایی که مورد حمله قرار میگیرن، باید به شرکت صادرکننده گواهی یعنی «فاینا سی‌ای» اعتماد داشته باشن. (یعنی این شرکت باید تو لیست شرکت‌های مورد اعتماد سیستم‌عاملشون باشه).
2. ترافیک اینترنتی بین کاربر و آدرس 1.1.1.1 باید توسط هکر شنود یا دستکاری بشه.

کلادفلر این اتفاق رو یه اشتباه امنیتی غیرقابل قبول از طرف «فاینا سی‌ای» میدونه، اما در عین حال قبول داره که خودشون هم باید زودتر متوجه این قضیه میشدن و بهش واکنش نشون میدادن. بعد از صحبت با «فاینا سی‌ای»، مشخص شد که اون‌ها این گواهی‌ها رو برای تست‌های داخلی خودشون صادر کرده بودن. اما قانون کلی اینه که هیچ شرکت صادرکننده گواهی (CA) نباید برای دامنه‌ها و آدرس‌های آی‌پی که کنترلشون رو در دست نداره، گواهی صادر کنه. در حال حاضر همه اون دوازده تا گواهی باطل شدن و کلادفلر منتظر یه گزارش کامل و دقیق از طرف «فاینا سی‌ای» هست تا ببینه دقیقا چه اتفاقی افتاده.

با اینکه این اتفاق ناخوشایند بوده، اما یه فرصت خوبه تا با هم یاد بگیریم که اصلا اعتماد تو اینترنت چطور کار میکنه؛ اعتمادی که بین شبکه‌هایی مثل کلادفلر، مقصدهایی مثل 1.1.1.1، شرکت‌های صادرکننده گواهی مثل «فاینا سی‌ای» و دستگاهی که شما الان باهاش دارید این مطلب رو میخونین وجود داره.

بیایید با اصول اولیه آشنا بشیم: DNS و 1.1.1.1 چی هستن؟

خب، قبل از اینکه عمیق‌تر بشیم، بذارین یه کم در مورد مفاهیم پایه صحبت کنیم. کلادفلر یه سرویس DNS عمومی به اسم 1.1.1.1 داره. کار DNS چیه؟ خیلی ساده‌س. وقتی شما تو مرورگرتون مینویسین example.com، کامپیوتر شما که این اسم رو نمیفهمه. کامپیوترها با آدرس‌های عددی به اسم آی‌پی (IP) کار میکنن. سرویس DNS مثل یه دفترچه تلفن غول‌پیکر برای اینترنته که اسم‌های قابل فهم برای انسان (مثل example.com) رو به آدرس‌های آی‌پی قابل فهم برای کامپیوتر (مثلا 192.0.2.42 یا 2001:db8::2a) ترجمه میکنه. میلیون‌ها دستگاه در سراسر دنیا از سرویس 1.1.1.1 برای همین کار استفاده میکنن.

سرویس 1.1.1.1 از طریق چند تا دامنه و آدرس آی‌پی مختلف در دسترسه. مثلا:

• دامنه‌ها: cloudflare-dns.com و one.one.one.one
• آدرس‌های آی‌پی: 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, 2606:4700:4700::1001

علاوه بر این، یه سرویس دیگه به اسم 1.1.1.1 for Families هم وجود داره که برای خانواده‌ها طراحی شده و روی آدرس‌های آی‌پی متفاوتی میزبانی میشه: 1.1.1.2, 1.1.1.3, 1.0.0.2, 1.0.0.3 و نسخه‌های IPv6 اونها.

مشکل DNS قدیمی: چرا به امنیت بیشتری نیاز داشتیم؟

پروتکل DNS در ابتدا که طراحی شد (طبق استانداردهای RFC 1034 و RFC 1035)، هیچ فکری برای حریم خصوصی و امنیتش نشده بود. درخواست‌ها و جواب‌های DNS به صورت متن ساده و رمزنگاری نشده بین کامپیوتر شما و سرور DNS رد و بدل میشد. این یعنی هر کسی وسط راه میتونست ببینه شما دنبال آدرس چه سایتی میگردین و حتی میتونست جواب رو دستکاری کنه و شما رو به یه سایت تقلبی بفرسته، بدون اینکه شما یا سرور DNS اصلا متوجه بشین. جالبه بدونین که هنوز هم حدود ۶۰ درصد درخواست‌هایی که به سرویس 1.1.1.1 کلادفلر میرسه، از همین روش قدیمی و ناامن استفاده میکنه.

برای حل این مشکل، متخصص‌ها دو تا راه حل جدید طراحی کردن:

1. DNS over TLS (DoT): که تو استاندارد RFC 7878 تعریف شده.
2. DNS over HTTPS (DoH): که تو استاندارد RFC 8484 تعریف شده.

در هر دوی این روش‌ها، خود پروتکل DNS تغییر زیادی نکرده، بلکه یه لایه امنیتی بهش اضافه شده. به جای اینکه درخواست‌ها به صورت متن ساده فرستاده بشن، اول یه کانال امن، خصوصی و رمزنگاری شده با استفاده از تکنولوژی TLS برقرار میشه و بعد درخواست‌های DNS از توی این کانال امن رد و بدل میشن. اینجوری دیگه کسی وسط راه نمیتونه درخواست‌های شما رو بخونه یا دستکاری کنه.

نقش کلیدی گواهی‌های TLS در امنیت

حالا میرسیم به بخش مهم ماجرا، یعنی گواهی‌ها. وقتی کامپیوتر شما میخواد با استفاده از DoT یا DoH به سرور DNS وصل بشه، یه فرآیندی به اسم «دست‌دهی TLS» یا TLS handshake اتفاق میفته. در این فرآیند، سرور برای اینکه هویت خودشو به کامپیوتر شما ثابت کنه، یه گواهی دیجیتالی (Certificate) نشون میده. کامپیوتر شما این گواهی رو چک میکنه تا ببینه آیا توسط یه «مرکز صدور گواهی» یا (Certification Authority – CA) معتبر امضا شده یا نه. اگه همه چیز درست بود، ارتباط برقرار میشه و از اون به بعد تمام اطلاعات به صورت رمزنگاری شده رد و بدل میشه.

گواهی‌هایی که برای DoT و DoH استفاده میشن، دقیقا از همون نوع گواهی‌هایی هستن که وبسایت‌های HTTPS استفاده میکنن. بیشتر گواهی‌های وبسایت‌ها برای اسم دامنه (مثلا example.com) صادر میشن. اما گواهی‌های سرور DNS یه فرق کوچولو دارن.

این گواهی‌ها علاوه بر اسم دامنه، باید حتما آدرس آی‌پی سرویس رو هم داخل خودشون داشته باشن. چرا؟ چون وقتی کامپیوتر شما میخواد برای اولین بار به یه سرور DNS وصل بشه، هنوز نمیتونه اسمی مثل cloudflare-dns.com رو به آی‌پی ترجمه کنه (چون کار خود DNS همینه!). پس دستگاه‌ها از اول با یه آدرس آی‌پی مشخص مثل 1.1.1.1 تنظیم میشن. وقتی با DoT یا DoH به این آی‌پی وصل میشن، سرور یه گواهی TLS میده که داخلش آدرس آی‌پی 1.1.1.1 نوشته شده. کامپیوتر شما این گواهی رو چک میکنه و اگه معتبر بود، مطمئن میشه که داره با صاحب واقعی 1.1.1.1 صحبت میکنه و شروع به فرستادن درخواست‌هاش میکنه.

برای مثال، اگه به گواهی واقعی که کلادفلر برای سرویس DNS خودش استفاده میکنه نگاه کنین، میبینین که کلی آدرس آی‌پی و دامنه داخلش وجود داره:

• Subject Alternative Name (نام‌های جایگزین):
  • DNS: cloudflare-dns.com
  • DNS: *.cloudflare-dns.com
  • DNS: one.one.one.one
  • IP Address: 1.0.0.1
  • IP Address: 1.1.1.1
  • IP Address: 162.159.36.1
  • IP Address: 162.159.46.1
  • و چندین آدرس IPv6 دیگه.

این گواهی توسط شرکت معتبر DigiCert صادر شده و مشخص میکنه که این دامنه‌ها و آی‌پی‌ها همگی متعلق به کلادفلر هستن.

بازگشت به مشکل اصلی: وقتی یک گواهی غیرمجاز صادر می‌شود

خب، حالا که با اصول کار آشنا شدیم، برگردیم سراغ اتفاقی که افتاده. همونطور که گفتیم، اعتبارسنجی گواهی، راهی هست که کامپیوتر شما از واقعی بودن هویت سرور DNS مطمئن میشه. پس صدور یه گواهی غیرمجاز برای 1.1.1.1 یه نگرانی جدی به حساب میاد.

فکر کنین یه کامپیوتر تنظیم شده که از سرویس 1.1.1.1 با روش امن DoT استفاده کنه. این کامپیوتر برای شروع کار، باید یه ارتباط TLS با سرور برقرار کنه. برای اینکه سرور مورد اعتماد باشه، باید یه گواهی ارائه بده که توسط یه CA (مرکز صدور گواهی) که کامپیوتر شما بهش اعتماد داره، صادر شده باشه. به مجموعه گواهی‌های این مراکز معتبر که روی سیستم شما نصب هستن، «مخزن ریشه» یا Root Store میگن.

یک مرکز صدور گواهی یا CA، سازمانی مثل DigiCert هست که وظیفه‌اش اینه که درخواست‌های صدور گواهی رو دریافت کنه و بررسی کنه که آیا درخواست‌دهنده واقعا کنترل اون دامنه رو در اختیار داره یا نه. در این ماجرا، شرکت «فاینا سی‌ای» برای 1.1.1.1 گواهی صادر کرده، بدون اینکه کلادفلر در جریان باشه. این یعنی «فاینا سی‌ای» به درستی بررسی نکرده که آیا درخواست‌دهنده، کنترل واقعی آدرس 1.1.1.1 رو داره یا نه.

توضیح خود شرکت «فاینا سی‌ای» این بوده:
«این گواهی‌ها به منظور تست داخلی صدور گواهی در محیط عملیاتی صادر شدند. در حین صدور گواهی‌های تستی، هنگام وارد کردن آدرس‌های آی‌پی خطایی رخ داد و به همین دلیل این گواهی‌ها در سرورهای لاگ شفافیت گواهی منتشر شدند.»

کلادفلر تاکید میکنه که مشکل اصلی، انتشار گواهی‌های تستی در سیستم شفافیت گواهی نیست (که جلوتر توضیح میدیم چیه)، بلکه اشتباه اصلی اینه که «فاینا سی‌ای» از کلیدهای عملیاتی و اصلی خودش برای امضای یک گواهی برای آدرس آی‌پی که مالکش نبوده، استفاده کرده. اون‌ها باید به جای آی‌پی معروف 1.1.1.1، از یه آدرس آی‌پی که تحت کنترل خودشون هست برای تست استفاده میکردن.

سابقه مشکلات مشابه و راه‌حل: شفافیت گواهی (Certificate Transparency)

متاسفانه صدور گواهی‌های غیرمجاز چیز جدیدی نیست. گاهی به خاطر بی‌دقتی (مثل اتفاقی که برای شرکت IdenTrust در نوامبر ۲۰۲۴ افتاد) و گاهی به خاطر هک شدن. یکی از معروف‌ترین موارد، هک شدن شرکت هلندی DigiNotar در سال ۲۰۱۱ بود که هکرها از کلیدهای اون برای صدور صدها گواهی تقلبی استفاده کردن.

این هک یک زنگ خطر بزرگ بود و باعث شد سیستمی به اسم شفافیت گواهی (Certificate Transparency – CT) معرفی بشه (که بعدا در استاندارد RFC 6962 رسمی شد). هدف CT این نیست که جلوی صدور اشتباه گواهی رو بگیره، بلکه هدفش اینه که هر صدور اشتباهی رو بعد از وقوع، به سرعت شناسایی کنه. چطوری؟ با این قانون که هر گواهی که توسط یک CA صادر میشه، باید در یک لاگ یا دفتر ثبت عمومی در دسترس همه قرار بگیره تا همه بتونن اون رو ببینن و بررسی کنن.

در سیستم شفافیت گواهی، چندین شرکت مستقل (از جمله خود کلادفلر) سرورهای لاگ عمومی رو مدیریت میکنن. امروزه خیلی از مرورگرهای مدرن، گواهی‌هایی رو که مدرکی مبنی بر ثبت شدن در حداقل دو تا از این لاگ‌های عمومی نداشته باشن، اصلا قبول نمیکنن. این مدرک به صورت یک «مهر زمانی گواهی امضا شده» (SCT) به گواهی اضافه میشه.

این سیستم به صاحبای دامنه‌ها اجازه میده که این لاگ‌های عمومی رو دائما زیر نظر داشته باشن و اگه گواهی برای دامنه‌شون صادر شد که خودشون درخواست نداده بودن، فورا متوجه بشن و هشدار بدن. سرویس‌های عمومی مثل crt.sh و صفحه شفافیت گواهی در رادار کلادفلر هم از همین داده‌ها استفاده میکنن تا همه بتونن گواهی‌های صادر شده رو جستجو کنن.

البته همه نرم‌افزارها این قانون رو رعایت نمیکنن. مرورگرها معمولا این کار رو میکنن، اما بیشتر کلاینت‌های DNS نه. کلادفلر میگه خوش‌شانس بودن که «فاینا سی‌ای» این گواهی‌های غیرمجاز رو در لاگ‌های CT ثبت کرده بود و همین موضوع باعث شد که ماجرا کشف بشه.

بررسی احتمال سو استفاده خرابکارانه

اولین نگرانی کلادفلر این بود که نکنه کسی از این گواهی‌ها برای جعل هویت سرویس 1.1.1.1 استفاده کرده باشه. همونطور که قبلا گفتیم، یه همچین حمله‌ای به چند تا شرط نیاز داره:

1. یک مهاجم به گواهی غیرمجاز و کلید خصوصی مربوط به اون نیاز داره.
2. کلاینت‌های مورد حمله باید به «فاینا سی‌ای» به عنوان یک مرجع صدور گواهی معتبر اعتماد داشته باشن.
3. ترافیک بین کلاینت و 1.1.1.1 باید توسط مهاجم شنود بشه.

کلادفلر این سه مورد رو به دقت بررسی کرد:

مورد اول: مشخصه که یک گواهی بدون اجازه کلادفلر صادر شده. پس باید فرض کرد که یک کلید خصوصی هم برای اون وجود داره که دست کلادفلر نیست و میتونه توسط یک مهاجم استفاده بشه. «فاینا سی‌ای» به کلادفلر گفته که کلیدهای خصوصی فقط در محیط کنترل شده خودشون بوده و حتی قبل از باطل شدن گواهی‌ها، فورا از بین برده شدن. اما چون راهی برای تایید این حرف وجود نداره، کلادفلر همچنان در حال بررسی هرگونه استفاده مخرب هست.

مورد دوم: بعضی از کلاینت‌ها به «فاینا سی‌ای» اعتماد دارن. این شرکت به طور پیش‌فرض در لیست شرکت‌های معتبر مایکروسافت و همچنین لیست ارائه‌دهندگان خدمات اعتماد اتحادیه اروپا قرار داره. اما خبر خوب اینه که این CA به طور پیش‌فرض در لیست ریشه‌های معتبر اندروید، اپل، موزیلا یا کروم وجود نداره. پس کاربرای این سیستم‌ها با تنظیمات پیش‌فرض، تحت تاثیر این مشکل قرار نگرفتن. کلادفلر بلافاصله بعد از کشف مشکل، با «فاینا سی‌ای»، مایکروسافت و اتحادیه اروپا تماس گرفت. مایکروسافت سریعا پاسخ داد و شروع به انتشار یک آپدیت برای لیست گواهی‌های غیرمجاز خودش کرد تا کلاینت‌ها دیگه به این گواهی‌ها اعتماد نکنن.

مورد سوم: کلادفلر یه تحقیق کامل رو برای پیدا کردن هرگونه شنود یا دستکاری ترافیک بین کاربرها و 1.1.1.1 شروع کرد. یک راه برای این کار، حملات «مرد میانی» (Man-in-the-middle) هست که مهاجم خودش رو بین کاربر و سرور قرار میده. تشخیص این نوع حملات برای کلادفلر سخته چون درخواست‌ها اصلا به سرورهای اصلی نمیرسن. سناریوی دوم، دزدیدن مسیر ترافیک 1.1.1.1 از طریق BGP هست. کلادفلر میگه تاریخچه اعلانات BGP مربوط به 1.1.1.1 رو بررسی کرده و هیچ مدرکی از وقوع چنین اتفاقی پیدا نکرده.

در نهایت، با اینکه نمیشه با اطمینان صد درصد گفت، اما تا الان هیچ مدرکی پیدا نشده که نشون بده این گواهی‌ها برای جعل هویت ترافیک سرویس DNS عمومی کلادفلر استفاده شده باشن.

نگاهی دقیق‌تر به مشخصات گواهی‌های غیرمجاز

تمام گواهی‌های غیرمجازی که برای 1.1.1.1 صادر شده بودن، دقیقا یک سال اعتبار داشتن و شامل نام‌های دامنه دیگه‌ای هم میشدن. جالبه که بیشتر این دامنه‌ها اصلا ثبت نشده بودن، که این نشون میده گواهی‌ها بدون بررسی صحیح کنترل دامنه صادر شدن. این کار نقض مستقیم قوانین انجمن CA/Browser و همچنین سیاست‌های خود شرکت «فاینا سی‌ای» هست.

لیست کامل دامنه‌هایی که در این گواهی‌های غیرمجاز پیدا شدن اینها بودن:

• fina.hr
• ssltest5
• test.fina.hr
• test.hr
• test1.hr
• test11.hr
• test12.hr
• test5.hr
• test6
• test6.hr
• testssl.fina.hr
• testssl.finatest.hr
• testssl.hr
• testssl1.finatest.hr
• testssl2.finatest.hr

نکته جالب دیگه اینه که در بخش مشخصات صاحب گواهی (Subject)، اسم یک سازمان خیالی به اسم TEST D.D. نوشته شده بود. برای مثال، یکی از این گواهی‌ها این مشخصات رو داشت:

• صاحب گواهی (Subject): C=HR, O=TEST D.D., L=ZAGREB, CN=testssl.finatest.hr
• نام‌های جایگزین (Subject Alternative Name):
  • DNS: testssl.finatest.hr
  • DNS: testssl2.finatest.hr
  • IP Address: 1.1.1.1

جدول زمانی اتفاقات: از اولین صدور تا باطل شدن

برای اینکه تصویر کامل‌تری از ماجرا داشته باشین، بیایید نگاهی به جدول زمانی این اتفاقات بندازیم (تمام زمان‌ها به وقت جهانی UTC هستن):

تاریخ و زمان (UTC)	شرح رویداد
2024-02-18 11:07:33	اولین گواهی صادر و در ساعت 11:40:00 همان روز باطل شد.
… (۱۱ صدور دیگر) …	از فوریه ۲۰۲۴ تا آگوست ۲۰۲۵، ۱۱ گواهی دیگر صادر و در زمان‌های مختلف باطل شدند.
2025-08-26 07:49:00	آخرین گواهی صادر شد و در تاریخ 2025-09-04 06:33:20 باطل شد.
2025-09-01 05:23:00	اولین گزارش عمومی در مورد صدور غیرمجاز در سایت Hacker News منتشر شد.
2025-09-02 04:50:00	گزارشی در پلتفرم HackerOne به کلادفلر ارسال شد، اما به اشتباه رسیدگی نشد.
2025-09-03 02:35:00	گزارش دومی در HackerOne ارسال شد که آن هم به اشتباه رسیدگی نشد.
2025-09-03 10:59:00	گزارشی در لیست ایمیل عمومی [email protected] ارسال شد که توجه تیم کلادفلر را جلب کرد.
2025-09-03 11:33:00	اولین پاسخ کلادفلر در لیست ایمیل مبنی بر شروع تحقیقات.
2025-09-03 12:08:00	حادثه به صورت رسمی اعلام شد.
2025-09-03 12:16:00	اطلاعیه صدور غیرمجاز به «فاینا سی‌ای»، «مخزن ریشه مایکروسافت» و «سرویس اعتماد اتحادیه اروپا» ارسال شد.
2025-09-03 12:23:00	کلادفلر لیست اولیه ۹ گواهی غیرمجاز را شناسایی کرد.
2025-09-03 12:24:00	تماس با «فاینا سی‌ای» برای اطلاع‌رسانی و درخواست ابطال گواهی‌ها.
2025-09-03 12:42:00	به عنوان یک اقدام پیشگیرانه، تحقیقات برای رد احتمال وقوع BGP hijack برای 1.1.1.1 آغاز شد.
2025-09-03 21:27:00	مایکروسافت اعلام کرد که با استفاده از مکانیزم ابطال سریع خود، جلوی استفاده بیشتر از گواهی‌های شناسایی شده را می‌گیرد.
2025-09-04 06:13:27	«فاینا سی‌ای» تمام گواهی‌های غیرمجاز را باطل کرد.
2025-09-04 12:44:00	کلادفلر پاسخی از «فاینا سی‌ای» دریافت کرد که توضیح می‌داد «هنگام صدور گواهی‌های تستی خطایی رخ داده» و قول دادند که جلوی تکرار چنین خطایی را خواهند گرفت.

اقدامات اصلاحی و قدم‌های بعدی کلادفلر

کلادفلر از ابتدا در اکوسیستم شفافیت گواهی سرمایه‌گذاری زیادی کرده. اون‌ها نه تنها لاگ‌های CT خودشون رو دارن، بلکه یک سیستم نظارتی هم دارن که به مشتریانشون در مورد صدور گواهی‌های مشکوک برای دامنه‌هاشون هشدار میده.

به همین دلیل، خیلی ناامیدکننده بود که اون‌ها نتونستن به درستی گواهی‌های مربوط به دامنه خودشون رو نظارت کنن. کلادفلر میگه که سه جا اشتباه کردن:

1. سیستم هشداردهی اون‌ها برای گواهی‌هایی که برای آدرس آی‌پی (مثل 1.1.1.1) صادر میشن، به درستی کار نمیکرد.
2. حتی اگه هشدارها رو دریافت میکردن، فیلترینگ مناسبی برای جدا کردن هشدارهای مهم از هشدارهای بی‌اهمیت نداشتن. چون تعداد دامنه‌ها و گواهی‌هایی که مدیریت میکنن خیلی زیاده، بررسی دستی همه اون‌ها ممکن نبوده.
3. به خاطر همین حجم بالای هشدارهای غیرمفید، سیستم هشداردهی رو برای همه دامنه‌هاشون فعال نکرده بودن.

کلادفلر داره هر سه این مشکلات رو برطرف میکنه. اون‌ها تمام گواهی‌های صادر شده برای دامنه‌ها و آی‌پی‌هاشون رو دوباره با استفاده از شفافیت گواهی بررسی کردن و تایید کردن که به جز گواهی‌های «فاینا سی‌ای»، مورد غیرمجاز دیگه‌ای وجود نداره.

با اینکه هیچ نشونه‌ای از سو استفاده از این گواهی‌ها پیدا نشده، کلادفلر این حادثه رو بسیار جدی گرفته و برنامه‌هایی برای جلوگیری از تکرار این مشکلات در آینده داره:

• هشداردهی: سیستم‌های هشدار و اطلاع‌رسانی برای صدور گواهی‌های مربوط به دامنه‌ها و آی‌پی‌های کلادفلر، از جمله 1.1.1.1، بهبود پیدا میکنه.
• شفافیت: کشف این گواهی‌ها به خاطر این بود که «فاینا سی‌ای» از شفافیت گواهی استفاده کرده بود. اما چون بیشتر کلاینت‌های DNS این موضوع رو اجباری نمیدونن، این کشف تا حدی شانسی بوده. کلادفلر در تلاشه تا شفافیت گواهی رو برای کلاینت‌های غیرمرورگری، به خصوص کلاینت‌های DNS که از TLS استفاده میکنن، هم الزامی کنه.
• برنامه پاداش در برابر باگ: فرآیند رسیدگی به گزارش‌های امنیتی در کلادفلر باعث تاخیر در پاسخگویی شده بود. اون‌ها دارن این فرآیند رو بازبینی میکنن تا مطمئن بشن گزارش‌های مهم به سرعت به دست افراد درست میرسن.
• نظارت: در طول این حادثه، تیم کلادفلر از ابزار crt.sh برای جستجو و بررسی گواهی‌ها استفاده کرد. اون‌ها قصد دارن یک رابط کاربری اختصاصی در پلتفرم «رادار» خودشون بسازن تا جستجوی گواهی‌ها، به خصوص گواهی‌های مبتنی بر آی‌پی، راحت‌تر بشه.

شما چه کاری می‌توانید انجام دهید؟

این اتفاق نشون میده که مدل فعلی اعتماد به مراکز صدور گواهی چقدر میتونه شکننده باشه. کافیه فقط یک مرکز صدور گواهی اشتباه کنه یا هک بشه تا امنیت همه به خطر بیفته.

• برای مدیران IT: اگه شما مسئول مدیریت تعداد زیادی دستگاه هستید، باید بررسی کنین که آیا نیازی به ابطال دستی این گواهی‌های غیرمجاز روی سیستم‌هاتون هست یا نه. با اینکه گواهی‌ها الان باطل شدن، اما فرآیند ابطال در همه سیستم‌ها آنی و خودکار نیست.
• برای مسئولان سیاست‌گذاری مخزن‌های ریشه: اگه شما در شرکتی کار میکنین که لیستی از CAهای معتبر رو مدیریت میکنه و «فاینا سی‌ای» هم در لیست شماست، باید فورا حضور این شرکت رو در لیستتون بازبینی کنین. همچنین باید الزام کنین که تمام CAهای موجود در لیست شما حتما در سیستم شفافیت گواهی شرکت کنن. بدون لاگ‌های CT، کشف مشکلاتی مثل این قبل از اینکه به کاربرها آسیب بزنن، تقریبا غیرممکنه.

کلادفلر تاکید میکنه که این اتفاق به این معنی نیست که باید استفاده از DoH یا DoT رو متوقف کنین. DNS معمولی روی UDP و TCP کاملا رمزنگاری نشده و هر درخواست و پاسخی در معرض خطر شنود و دستکاری قرار داره. اما امنیت کلاینت‌های DoH و DoT میتونه بهتر بشه اگه اون‌ها هم الزام کنن که گواهی سرور حتما باید در لاگ‌های شفافیت گواهی ثبت شده باشه.

این اولین باری بود که کلادفلر با صدور یک گواهی غیرمجاز برای سرویس DNS عمومی 1.1.1.1 مواجه شد. با اینکه شواهدی از قصد خرابکارانه وجود نداره، اما اون‌ها میدونن که ممکنه در آینده تلاش‌های خرابکارانه‌ای هم صورت بگیره. به همین دلیل، در تلاش هستن تا سرعت کشف و هشداردهی در مورد این نوع مشکلات رو افزایش بدن.

---

پرسش و پاسخ

سوال ۱: یعنی این اتفاق باعث شده بود اینترنت من در خطر باشه؟

جواب: به احتمال خیلی خیلی زیاد، نه. همونطور که گفتیم، برای اینکه یه هکر بتونه از این گواهی‌های تقلبی استفاده کنه، چند تا شرط باید همزمان برقرار میشد. اول اینکه سیستم‌عامل شما باید به شرکت «فاینا سی‌ای» اعتماد میکرد که اکثر سیستم‌عامل‌های معروف مثل اندروید و iOS این کار رو به طور پیش‌فرض نمیکنن. دوم اینکه هکر باید میتونست ترافیک اینترنت شما رو شنود کنه. کلادفلر هیچ مدرکی از سو استفاده گسترده پیدا نکرده، پس جای نگرانی برای کاربرای عادی وجود نداره.

سوال ۲: اگه این گواهی‌ها فقط برای تست بودن، پس مشکل چی بود؟ چرا اینقدر جدی گرفته شد؟

جواب: سوال خیلی خوبیه. مشکل اصلی این نبود که «تست» میکردن. مشکل این بود که برای تست، از یک آدرس آی‌پی عمومی و بسیار مهم (1.1.1.1) که مالکش نبودن، استفاده کردن. این مثل اینه که شما برای تست سیستم صدور کارت ملی، یه کارت ملی برای یه شخصیت معروف صادر کنین. این کار به شدت خطرناکه چون اون گواهی، حتی اگه تستی باشه، توسط کلیدهای اصلی و معتبر اون شرکت امضا شده و برای بعضی سیستم‌ها کاملا معتبر به نظر میرسه. قانون اینه که برای تست باید از دامنه‌ها و آی‌پی‌هایی استفاده بشه که تحت کنترل خود شرکت هستن.

سوال ۳: میشه یه بار دیگه این «شفافیت گواهی» یا CT رو به زبان ساده‌تر توضیح بدین؟

جواب: حتما. فکر کنین هر شناسنامه‌ای که در کشور صادر میشه، یه کپی ازش بلافاصله در یک دفتر ثبت عمومی که برای همه قابل مشاهده‌س، ثبت بشه. حالا شما میتونین هر روز این دفتر رو چک کنین و ببینین آیا شناسنامه‌ای به اسم شما بدون اینکه خبر داشته باشین صادر شده یا نه. «شفافیت گواهی» دقیقا همین کار رو برای گواهی‌های دیجیتال انجام میده. یک سیستم ثبت عمومی برای تمام گواهی‌هاست که به صاحبای دامنه‌ها اجازه میده هر صدور غیرمجازی رو خیلی سریع پیدا کنن. این سیستم بود که باعث شد این مشکل کشف بشه.

سوال ۴: چرا گواهی‌های سرور DNS باید حتما آدرس آی‌پی داشته باشن ولی گواهی سایت‌های عادی معمولا فقط اسم دامنه دارن؟

جواب: دلیلش یه جورایی مثل مشکل مرغ و تخم‌مرغه. وقتی شما میخواین به سایت google.com وصل بشین، مرورگر شما اول از DNS میپرسه که آی‌پی google.com چیه. بعد از اینکه آی‌پی رو گرفت، به اون آی‌پی وصل میشه و گواهی رو چک میکنه که ببینه آیا واقعا برای google.com صادر شده یا نه.
اما وقتی میخواین برای اولین بار به خود سرور DNS (مثلا 1.1.1.1) با پروتکل امن وصل بشین، شما هنوز هیچ DNSی ندارین که ازش بپرسین آی‌پی cloudflare-dns.com چیه! پس از اول باید با خود آدرس آی‌پی (1.1.1.1) ارتباط بگیرین. در این حالت، سرور باید یه گواهی به شما بده که ثابت کنه «من صاحب قانونی همین آدرس آی‌پی 1.1.1.1 هستم». به خاطر همین، آدرس آی‌پی باید مستقیما داخل گواهی نوشته شده باشه.