۹۸٪ اتصال‌های امن ایران با TLS 1.3 است.

این صفحه دقیقا چه چیزی را نشان می‌دهد؟

پیش از توضیح فنی، بهتر است بدانید عددهای صفحه‌ی TLS رادار سفید از کجا آمده‌اند. عددی که منبعش معلوم نباشد، بیشتر گیج می‌کند تا کمک.

داده‌ها از Cloudflare Radar می‌آید، با مجوز CC BY-NC 4.0. Cloudflare یک شرکت بزرگ اینترنتی است و بخش بزرگی از سایت‌های دنیا از شبکه‌ی آن رد می‌شوند. این شرکت بخشی عمومی به اسم Radar دارد که عددهای اینترنت کشورها را منتشر می‌کند. رادار سفید این عددها را فقط برای ایران می‌گیرد، هر ۶ ساعت تازه می‌کند، ۳۰ روز نگه می‌دارد و بعد پاک می‌کند. رادار سفید کار Cloudflare نیست و Cloudflare آن را تایید نکرده است؛ فقط از داده‌ی عمومی‌اش استفاده می‌کند.

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

در این صفحه سه چیز می‌بینید:

1. سهم هر نسخه‌ی TLS در ۷ روز گذشته. از همه‌ی درخواست‌های HTTPS که در این یک هفته از ایران به Cloudflare رسیده، چند درصد با TLS 1.0، چند درصد با TLS 1.1، چند درصد با TLS 1.2، چند درصد با TLS 1.3 و چند درصد با QUIC بوده است.
2. سهم اتصال‌های پساکوانتومی در ۷ روز گذشته. چند درصد همان درخواست‌ها با کلیدی ساخته شده‌اند که در برابر رایانه‌های کوانتومی آینده هم مقاوم است.
3. روند ۳۰ روزه‌ی سهم پساکوانتومی. همان عدد، روز به روز، تا ببینید در یک ماه بالا رفته یا نه.

عدد امروز بالای همین صفحه است. در این متن عددی از آن نمی‌آوریم، چون هر ۶ ساعت عوض می‌شود و متن ثابت می‌ماند.

TLS چیست؟ پاکتی که فقط گیرنده بازش می‌کند

فرض کنید می‌خواهید برای دوستتان نامه‌ای بفرستید که کسی در راه نخواندش. اگر نامه را روی یک کارت پستال بنویسید، هر نامه‌رسانی که کارت از دستش رد می‌شود می‌تواند آن را بخواند و حتی چیزی رویش اضافه کند. اینترنت بدون رمزنگاری همین کارت پستال است. پیام شما از دست ده‌ها دستگاه در راه می‌گذرد تا به سایت برسد.

TLS کوتاه شده‌ی Transport Layer Security است، یعنی «امنیت لایه‌ی انتقال». به زبان ساده، TLS پاکت دربسته‌ای است که دور پیام‌های شما و سایت کشیده می‌شود. این پاکت سه کار می‌کند:

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

وقتی در نوار نشانی مرورگر https می‌بینید، یعنی HTTP (زبانی که مرورگر و سایت با آن حرف می‌زنند) درون پاکت TLS رفت و آمد می‌کند. حرف S در HTTPS همین است: Secure، یعنی امن. چند درصد درخواست‌های ایران HTTPS است و چند درصد هنوز HTTP ساده، در صفحه‌ی پروتکل HTTP در ایران آمده است.

TLS handshake چیست؟ دو دستی که پیش از حرف زدن به هم می‌رسند

پیش از اینکه اولین حرف واقعی رد و بدل شود، مرورگر و سایت باید روی دو چیز توافق کنند: با چه روشی رمز کنند، و با چه کلیدی. به این مرحله دست‌دادن (handshake) می‌گویند. اسمش بی‌دلیل نیست؛ مثل دو نفر است که پیش از گفتگو دست می‌دهند و خودشان را معرفی می‌کنند.

دست‌دادن در چند قدم ساده

این قدم‌ها ساده شده‌ی کاری است که در TLS 1.3 اتفاق می‌افتد:

1. مرورگر سلام می‌کند (ClientHello). می‌گوید: «سلام، من این نسخه‌های TLS را بلدم، این روش‌های رمز را بلدم، و این هم نیمه‌ی من از کلید.» مرورگر در همین سلام اول، تکه‌ای از کلید را هم می‌فرستد.
2. سایت جواب سلام می‌دهد (ServerHello). می‌گوید: «سلام، بیا با TLS 1.3 و این روش حرف بزنیم، این هم نیمه‌ی من از کلید.»
3. هر دو کلید را می‌سازند. هر کدام از روی نیمه‌ی خودش و نیمه‌ی طرف مقابل، یک کلید مشترک می‌سازد. نکته‌ی جالب اینجاست که خود کلید هیچ وقت در راه نمی‌رود. کسی که همه‌ی پیام‌ها را دیده، باز هم نمی‌تواند کلید را بسازد.
4. سایت کارت شناسایی‌اش را نشان می‌دهد. گواهی‌اش را می‌فرستد و با امضای خودش ثابت می‌کند صاحب واقعی آن است. در TLS 1.3 این بخش دیگر رمز شده است.
5. گفتگو شروع می‌شود. از اینجا به بعد هر چه رد و بدل شود، درون پاکت است.

کلید مشترک بدون فرستادن کلید؟

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

به این روش توافق کلید (key agreement یا key exchange) می‌گویند. روش رایج امروز اسمش X25519 است، یعنی نوعی توافق کلید با ریاضی منحنی‌های بیضوی که سریع و کوچک است. یادتان باشد این اسم را، چون پایین‌تر در بخش پساکوانتومی دوباره سراغش می‌آییم.

رفت و برگشت یعنی چه؟

در شبکه به یک بار رفتن پیام و برگشتن جواب، یک رفت و برگشت (round trip) می‌گویند. هر رفت و برگشت زمان می‌برد، به خصوص وقتی سرور دور است. در صفحه‌ی پینگ می‌بینید یک رفت و برگشت از ایران چقدر طول می‌کشد. هر چه دست‌دادن رفت و برگشت کمتری بخواهد، صفحه زودتر باز می‌شود. یکی از بزرگ‌ترین تغییرهای TLS 1.3 همین است که پایین‌تر می‌گوییم.

SSL و TLS چه فرقی دارند؟ یک تاریخچه‌ی کوتاه

خیلی‌ها هنوز می‌گویند «گواهی SSL» یا «SSL سایت». این اسم از قدیم مانده است. SSL و TLS در اصل یک خانواده‌اند: SSL نسخه‌های قدیمی است و TLS نسخه‌های جدیدتر همان فکر.

SSL: نسل اول

SSL کوتاه شده‌ی Secure Sockets Layer است، یعنی «لایه‌ی سوکت امن». سوکت یعنی سر یک اتصال شبکه در برنامه. SSL در میانه‌ی دهه‌ی ۱۹۹۰ برای مرورگرها ساخته شد. نسخه‌ی ۲ آن خیلی زود ضعف‌هایش معلوم شد و نسخه‌ی ۳ جایش آمد.

هر دو نسخه امروز رسما کنار گذاشته شده‌اند:

• استفاده از SSL 2.0 در سال ۲۰۱۱ با RFC 6176 ممنوع شد.
• SSL 3.0 در سال ۲۰۱۵ با RFC 7568 کنار رفت. این سند صریح می‌گوید SSLv3 نباید به کار برود و هیچ نسخه‌ای از TLS هم نباید اجازه بدهد اتصال به SSLv3 برگردد. یکی از دلیل‌هایی که خود سند می‌آورد، حمله‌ای به اسم POODLE است که سال ۲۰۱۴ نشان داد در SSLv3 می‌شود تکه‌هایی از متن رمزشده را بیرون کشید.

RFC یعنی چه؟ کوتاه شده‌ی Request for Comments است، یعنی سندهای رسمی که قاعده‌های اینترنت را می‌نویسند. گروهی به اسم IETF (گروه مهندسی اینترنت) این سندها را می‌نویسد و منتشر می‌کند. هر جا در این متن RFC آمده، منبع اصلی قاعده است، نه نظر یک شرکت.

TLS: همان فکر، با اسم تازه

بعد از SSL 3.0، کار ساختن نسخه‌ی بعدی به IETF رسید و اسمش شد TLS. نسخه‌ها به ترتیب این‌ها هستند:

1. TLS 1.0 در سال ۱۹۹۹ با RFC 2246. در عمل خیلی شبیه SSL 3.0 بود.
2. TLS 1.1 در سال ۲۰۰۶ با RFC 4346. چند ضعف را بست.
3. TLS 1.2 در سال ۲۰۰۸ با RFC 5246. روش‌های رمز جدیدتر و محکم‌تر را آورد و سال‌ها نسخه‌ی اصلی وب بود.
4. TLS 1.3 در اوت ۲۰۱۸ با RFC 8446. بزرگ‌ترین بازنویسی خانواده؛ سریع‌تر و ساده‌تر.

پس «گواهی SSL» غلط است؟

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

چرا TLS 1.0 و TLS 1.1 کنار رفتند؟

در مارس ۲۰۲۱، سند RFC 8996 با عنوان «کنار گذاشتن TLS 1.0 و TLS 1.1» منتشر شد. این سند هر دو نسخه را به وضعیت «تاریخی» برد، یعنی دیگر نباید استفاده شوند. همین سند نسخه‌ی 1.0 از DTLS را هم کنار گذاشت. DTLS یعنی همان TLS برای پیام‌هایی که بدون اتصال پیوسته فرستاده می‌شوند.

دلیل‌ها به زبان ساده این‌هاست:

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

اگر TLS 1.0 و 1.1 را ببندم، کسی جا می‌ماند؟

این دقیقا سوالی است که صفحه‌ی TLS رادار سفید به آن کمک می‌کند. اگر سهم TLS 1.0 و TLS 1.1 در اتصال‌های ایران تقریبا صفر باشد، یعنی تقریبا همه‌ی مرورگرها و برنامه‌هایی که از ایران به سایت‌ها وصل می‌شوند، نسخه‌ی 1.2 یا 1.3 را بلدند. عدد امروز بالای همین صفحه است.

ولی دو نکته را فراموش نکنید:

1. این عدد مال سایت‌های روی Cloudflare است، نه سایت شما. اگر سایت شما مشتری خاصی دارد، مثلا دستگاه‌های قدیمی صنعتی، کارت‌خوان‌ها، یا برنامه‌ای که سال‌ها به‌روز نشده، ممکن است آن‌ها هنوز فقط نسخه‌ی قدیمی را بلد باشند. بهترین منبع، گزارش‌های سرور خود شماست.
2. این عدد سهم درخواست‌هاست، نه آدم‌ها. یک برنامه‌ی پرتکرار ممکن است درخواست زیادی بفرستد و یک آدم با مرورگر تازه درخواست کمی. پس صفر بودن تقریبی یعنی «خیلی کم»، نه «هیچ کس».

در گزارش سرور خودم چطور ببینم؟

بیشتر سرورهای وب می‌توانند نسخه‌ی TLS هر اتصال را در گزارش (log) بنویسند. در nginx متغیری به اسم ssl_protocol هست و در Apache متغیری به اسم SSL_PROTOCOL. اگر این متغیر را به قالب گزارش اضافه کنید و چند روز صبر کنید، می‌بینید چند اتصال با نسخه‌های قدیمی آمده‌اند. اگر تقریبا هیچ نبود، بستن آن‌ها خطری ندارد.

TLS 1.3 چه چیزهایی را عوض کرد؟

TLS 1.3 فقط یک وصله روی 1.2 نیست. سند RFC 8446 در بخشی به اسم «تفاوت‌های اصلی با TLS 1.2» فهرستی آورده است. مهم‌ترین‌هایش را به زبان ساده می‌گوییم.

دست‌دادن کوتاه‌تر: یک رفت و برگشت

در TLS 1.2 دست‌دادن کامل معمولا دو رفت و برگشت می‌خواست. اول مرورگر و سایت روی روش توافق می‌کردند، بعد کلید رد و بدل می‌شد. در TLS 1.3 مرورگر از همان سلام اول نیمه‌ی کلیدش را می‌فرستد، پس دست‌دادن کامل یک رفت و برگشت است.

یعنی چه در عمل؟ اگر یک رفت و برگشت از ایران تا سرور مثلا یک دهم ثانیه طول بکشد، TLS 1.3 در هر اتصال تازه همین قدر زودتر به حرف اصلی می‌رسد. برای صفحه‌ای که از چند دامنه چیز می‌گیرد، این صرفه‌جویی جمع می‌شود.

صفر رفت و برگشت (0-RTT)

TLS 1.3 حالتی به اسم 0-RTT هم دارد. اگر مرورگر قبلا به همین سایت وصل شده باشد، می‌تواند در همان پیام اول، درخواستش را هم بفرستد و منتظر تمام شدن دست‌دادن نماند. این حالت سریع است ولی یک هزینه دارد: پیامی که در 0-RTT فرستاده می‌شود، ممکن است کسی در راه آن را ضبط کند و دوباره بفرستد. برای همین فقط برای درخواست‌هایی مناسب است که تکرارشان ضرری ندارد، مثل باز کردن یک صفحه، نه ثبت یک سفارش.

روش‌های رمز کمتر و محکم‌تر

در TLS 1.2 فهرست روش‌های رمز (به آن cipher suite می‌گویند، یعنی بسته‌ای از چند روش که با هم کار می‌کنند) خیلی بلند بود و بعضی‌شان ضعیف بودند. مدیر سرور باید با دقت فهرست را تنظیم می‌کرد تا روش ضعیفی روشن نماند.

RFC 8446 می‌گوید فهرست روش‌های رمز «از همه‌ی روش‌هایی که قدیمی شمرده می‌شوند پاک شده است». در TLS 1.3 فقط چند روش مانده و همه‌شان امروز محکم شمرده می‌شوند. یعنی جای کمتری برای اشتباه در تنظیم.

رازداری پیش‌رو (forward secrecy) برای همه

در نسخه‌های قدیمی، روشی بود که در آن کلید هر گفتگو با کلید ثابت سرور رمز می‌شد و فرستاده می‌شد. مشکل این بود: اگر کسی امروز گفتگوها را ضبط کند و سال‌ها بعد کلید ثابت سرور به دستش برسد، می‌تواند همه‌ی آن گفتگوهای قدیمی را باز کند.

رازداری پیش‌رو یعنی هر گفتگو کلید تازه‌ی خودش را دارد که بعد از تمام شدن دور ریخته می‌شود. لو رفتن کلید ثابت سرور در آینده، گفتگوهای گذشته را باز نمی‌کند. RFC 8446 می‌گوید در TLS 1.3 روش‌های قدیمی بدون این ویژگی حذف شده‌اند و همه‌ی روش‌های توافق کلید رازداری پیش‌رو دارند.

TLS 1.2 هنوز کافی است؟

جستجوی «tls 1.2 deprecated» زیاد است، پس صریح بگوییم: TLS 1.2 کنار گذاشته نشده است. سند راهنمای رسمی IETF برای استفاده‌ی امن از TLS، یعنی RFC 9325 (که با نام BCP 195 هم شناخته می‌شود و در نوامبر ۲۰۲۲ منتشر شد)، می‌گوید:

• نرم‌افزارها نباید با SSL 2، SSL 3، TLS 1.0 و TLS 1.1 اتصال بسازند.
• نرم‌افزارها باید TLS 1.2 را پشتیبانی کنند.
• نرم‌افزارها بهتر است TLS 1.3 را هم پشتیبانی کنند و اگر کردند، باید آن را به نسخه‌های قبلی ترجیح بدهند.

BCP یعنی Best Current Practice، یعنی «بهترین روش امروز». این سندها جمع‌بندی رسمی تجربه‌ی جامعه‌ی اینترنت درباره‌ی یک موضوع‌اند.

در کنار آن، مؤسسه‌ی ملی استاندارد و فناوری آمریکا (NIST) هم در راهنمای SP 800-52 Rev. 2 که اوت ۲۰۱۹ منتشر شد، پشتیبانی از TLS 1.2 را لازم دانسته و خواسته تا اول ژانویه‌ی ۲۰۲۴ پشتیبانی TLS 1.3 هم اضافه شود. این راهنما برای سامانه‌های خاصی نوشته شده، ولی جهت کلی‌اش همان است که IETF می‌گوید.

پس جمع‌بندی ساده: TLS 1.2 با روش‌های رمز خوب، امروز هنوز قابل قبول است؛ TLS 1.3 نسخه‌ای است که باید باشد و ترجیح داده شود.

QUIC در این صفحه یعنی چه؟

در فهرست نسخه‌های صفحه‌ی TLS، کنار 1.0 تا 1.3، یک ردیف به اسم QUIC هم هست. این یک نسخه‌ی دیگر TLS نیست، بلکه راه دیگری برای رساندن همان TLS 1.3 است.

TCP و UDP، به زبان ساده

بیشتر وب سال‌ها روی TCP کار کرده است. TCP قراردادی است که مطمئن می‌شود همه‌ی بسته‌های داده به ترتیب و کامل برسند. TLS معمولی روی TCP سوار است: اول TCP اتصال را می‌سازد (خودش یک رفت و برگشت)، بعد TLS دست می‌دهد.

UDP قرارداد ساده‌تری است که بسته‌ها را بی‌ترتیب و بی‌ضمانت می‌فرستد. QUIC پروتکلی تازه روی UDP است که کارهای TCP را خودش، به شکلی جدیدتر، انجام می‌دهد. HTTP/3 روی QUIC کار می‌کند. درباره‌ی HTTP/3 در صفحه‌ی پروتکل HTTP بیشتر بخوانید.

TLS درون QUIC

سند RFC 9001 که مه ۲۰۲۱ منتشر شد، می‌گوید QUIC چطور از TLS استفاده می‌کند. دو نکته‌ی مهمش برای ما این است:

1. فقط TLS 1.3. این سند می‌گوید اگر نسخه‌ای قدیمی‌تر از 1.3 توافق شود، اتصال باید بسته شود. پس هر اتصال QUIC یعنی TLS 1.3.
2. دست‌دادن یکی می‌شود. در QUIC، ساختن اتصال و دست‌دادن TLS با هم و در همان رفت و برگشت اول انجام می‌شوند. دیگر یک رفت و برگشت جدا برای TCP لازم نیست.

پس وقتی در صفحه سهم QUIC را می‌بینید، آن را هم جزو اتصال‌های TLS 1.3 حساب کنید. اگر بخواهید بدانید چند درصد اتصال‌ها روی کل خانواده‌ی 1.3 است، سهم TLS 1.3 و QUIC را با هم جمع کنید.

رمزنگاری پساکوانتومی چیست؟

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

رایانه‌ی کوانتومی، به زبان ساده

رایانه‌های امروز با بیت کار می‌کنند؛ هر بیت یا صفر است یا یک. رایانه‌ی کوانتومی نوع دیگری از رایانه است که از قاعده‌های فیزیک ذره‌های خیلی ریز استفاده می‌کند. برای بیشتر کارها از رایانه‌ی معمولی بهتر نیست، ولی برای چند مسئله‌ی خاص ریاضی خیلی سریع‌تر است.

بدبختانه دو تا از آن مسئله‌ها همان‌هایی هستند که توافق کلید امروز (مثل X25519 و روش‌های قدیمی‌ترش) و امضای گواهی‌ها رویشان بنا شده‌اند. یعنی اگر روزی رایانه‌ی کوانتومی به اندازه‌ی کافی بزرگ ساخته شود، می‌تواند از روی پیام‌هایی که در دست‌دادن رد و بدل شده، کلید گفتگو را حساب کند.

امروز چنین رایانه‌ای وجود ندارد. ولی یک مشکل هست که باعث شده کار از الان شروع شود.

«امروز جمع کن، فردا باز کن»

به انگلیسی به این خطر harvest now, decrypt later می‌گویند، یعنی «امروز درو کن، بعدا رمزگشایی کن». Cloudflare در نوشته‌ی وضعیت اینترنت پساکوانتومی (مارس ۲۰۲۴) و راهنمای رمزنگاری پساکوانتومی این خطر را این‌طور توضیح می‌دهد: کسی می‌تواند ارتباط رمزشده‌ی امروز را ضبط کند و نگه دارد تا روزی که رایانه‌ی کوانتومی کافی به دستش برسد و آن را باز کند.

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

«پساکوانتومی» یعنی چه؟

رمزنگاری پساکوانتومی (post-quantum cryptography، کوتاه PQ) یعنی روش‌های رمزنگاری که روی رایانه‌های معمولی امروز اجرا می‌شوند، ولی بر پایه‌ی مسئله‌هایی ساخته شده‌اند که گمان می‌رود رایانه‌ی کوانتومی هم نتواند حلشان کند. «پسا» یعنی «پس از»؛ یعنی رمزی برای دوره‌ی پس از آمدن رایانه‌ی کوانتومی.

برای این کار به سخت‌افزار خاصی نیاز نیست. همان مرورگر و همان سرور، با یک نرم‌افزار به‌روزتر، می‌توانند پساکوانتومی حرف بزنند.

ML-KEM: استاندارد رسمی

NIST چند سال مسابقه‌ای برگزار کرد تا روش‌های پساکوانتومی را بسنجد. یکی از برنده‌ها روشی به اسم Kyber بود که بعد از استاندارد شدن اسمش شد ML-KEM. سند رسمی آن FIPS 203 است با عنوان «استاندارد سازوکار کپسوله کردن کلید بر پایه‌ی شبکه‌های ماژولی» که ۱۳ اوت ۲۰۲۴ منتشر شد.

اسمش را باز کنیم:

• KEM کوتاه شده‌ی Key Encapsulation Mechanism است، یعنی «سازوکار کپسوله کردن کلید». به زبان ساده، یک طرف کلیدی می‌سازد و آن را در کپسولی می‌گذارد که فقط طرف دیگر می‌تواند باز کند. نتیجه همان است: دو طرف به یک کلید مشترک می‌رسند.
• ML یعنی Module Lattice، یعنی «شبکه‌ی ماژولی». این اسم ریاضی است که امنیت روش بر آن بنا شده؛ لازم نیست جزئیاتش را بدانید.

FIPS 203 سه اندازه برای ML-KEM تعریف می‌کند: ML-KEM-512، ML-KEM-768 و ML-KEM-1024. عدد بزرگ‌تر یعنی امنیت بیشتر و پیام بزرگ‌تر. در وب امروز بیشتر از ML-KEM-768 استفاده می‌شود.

کلید دوگانه: X25519MLKEM768 چیست؟

یک روش رمز تازه، هر چقدر هم بررسی شده باشد، هنوز به اندازه‌ی روش‌های قدیمی در دنیای واقعی آزموده نشده است. ممکن است روزی در ریاضی‌اش ضعفی پیدا شود، یا در یک برنامه اشتباه پیاده شود. برای همین وب امروز به جای جایگزین کردن یکباره، از کلید دوگانه (hybrid key agreement) استفاده می‌کند.

دو قفل روی یک در

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

در عمل، مرورگر و سرور در یک دست‌دادن، دو توافق کلید با هم انجام می‌دهند: یکی با X25519 قدیمی و آزموده، یکی با ML-KEM-768 تازه و پساکوانتومی. بعد کلید نهایی را از هر دو می‌سازند. برای باز کردن گفتگو، باید هر دو را شکست:

• رایانه‌ی معمولی امروز X25519 را نمی‌شکند.
• رایانه‌ی کوانتومی فردا (اگر ساخته شود) ML-KEM را نمی‌شکند.

اسم این ترکیب X25519MLKEM768 است. اسمش همان چیزی است که می‌گوید: X25519 به اضافه‌ی ML-KEM-768.

استاندارد آن کجاست؟

این ترکیب سال‌ها به صورت پیش‌نویس در IETF بود و حالا سند رسمی RFC 10024 با عنوان «سازوکارهای توافق کلید دوگانه‌ی پساکوانتومی و سنتی برای TLS 1.3» آن را تعریف می‌کند. این سند سه ترکیب تعریف کرده: X25519MLKEM768، SecP256r1MLKEM768 و SecP384r1MLKEM1024. از این سه، X25519MLKEM768 همانی است که بیشتر به کار می‌رود و سند هم آن را رایج‌ترین و عملی‌ترین انتخاب می‌داند. صفحه‌ی پیش‌نویس و تاریخچه‌اش در datatracker.ietf.org هست.

چرا فقط روی TLS 1.3؟

کلید دوگانه برای TLS 1.3 تعریف شده است. یعنی اتصالی که با TLS 1.2 ساخته شود، پساکوانتومی نیست. این یکی دیگر از دلیل‌هایی است که TLS 1.3 را باید روشن کرد.

پساکوانتومی کی روشن می‌شود؟ هر دو طرف باید بلد باشند

دست‌دادن یک گفتگوی دوطرفه است. مرورگر در سلامش می‌گوید چه روش‌هایی بلد است، و سرور از میان آن‌ها انتخاب می‌کند. Cloudflare در همان نوشته‌ی مارس ۲۰۲۴ یادآوری می‌کند که برای اتصال پساکوانتومی، هم مرورگر (یا هر برنامه‌ی دیگری که وصل می‌شود) و هم سرور باید آن را پشتیبانی کنند.

چهار حالت پیش می‌آید:

1. مرورگر بلد است، سرور هم. اتصال پساکوانتومی ساخته می‌شود.
2. مرورگر بلد است، سرور نه. سرور روش قدیمی را انتخاب می‌کند و اتصال عادی ساخته می‌شود. چیزی خراب نمی‌شود.
3. مرورگر بلد نیست، سرور بلد است. باز اتصال عادی؛ سرور روشی را که مرورگر پیشنهاد نکرده، نمی‌تواند انتخاب کند.
4. هیچ کدام بلد نیستند. اتصال عادی.

عدد پساکوانتومی رادار سفید یعنی چه؟

صفحه‌ی TLS سهم درخواست‌های HTTPS از ایران به Cloudflare را نشان می‌دهد که با رمزنگاری پساکوانتومی ساخته شده‌اند. چون این عدد فقط سایت‌های روی Cloudflare را می‌شمارد، طرف سرور این اتصال‌ها پساکوانتومی را بلد است. پس این عدد بیشتر می‌گوید چند درصد مرورگرها و برنامه‌هایی که از ایران وصل می‌شوند پساکوانتومی را پشتیبانی می‌کنند.

چه چیزهایی روی این عدد اثر می‌گذارد؟

• نسخه‌ی مرورگرها. مرورگرهای تازه‌تر این روش را دارند و نسخه‌های قدیمی نه. اگر بسیاری از کاربران مرورگرشان را به‌روز نکنند، عدد پایین‌تر می‌ماند.
• برنامه‌ها و ابزارها. درخواست‌ها فقط از مرورگر نیستند. برنامه‌های گوشی، ابزارهای خط فرمان و برنامه‌های خودکار هر کدام کتابخانه‌ی TLS خودشان را دارند و ممکن است این روش را نداشته باشند.
• سهم TLS 1.3. هر درخواستی که با TLS 1.2 بیاید، نمی‌تواند پساکوانتومی باشد.

روند ۳۰ روزه کمک می‌کند ببینید این عدد ثابت است یا بالا می‌رود. بالا رفتن آرام معمولا یعنی مرورگرها و برنامه‌ها کم کم به‌روز می‌شوند.

این عدد برای سایت من چه می‌گوید؟

هیچ چیز مستقیمی درباره‌ی سرور شما نمی‌گوید. ولی می‌گوید اگر سرورتان پساکوانتومی را روشن کند، چه سهمی از بازدیدکنندگان ایرانی می‌توانند از آن استفاده کنند. اگر نرم‌افزار سرورتان (مثلا کتابخانه‌ی OpenSSL که بسیاری از سرورها با آن کار می‌کنند) به نسخه‌ای رسیده که X25519MLKEM768 را دارد، معمولا با به‌روز کردن و تنظیم فهرست روش‌های توافق کلید روشن می‌شود. جزئیاتش را در راهنمای نرم‌افزار سرور خودتان ببینید، چون از نسخه‌ای به نسخه‌ی دیگر فرق می‌کند.

HSTS چیست؟ قولی که سایت از مرورگر می‌گیرد

HSTS به خود نسخه‌ی TLS ربطی ندارد و صفحه‌ی رادار هم عددی برای آن ندارد، ولی کنار TLS زیاد اسمش می‌آید، پس کوتاه می‌گوییم.

HSTS کوتاه شده‌ی HTTP Strict Transport Security است، یعنی «امنیت سخت‌گیرانه‌ی انتقال در HTTP». سند آن RFC 6797 است که نوامبر ۲۰۱۲ منتشر شد. MDN هم توضیح ساده‌ای دارد.

مشکلی که حل می‌کند این است: کاربر نشانی سایت را بدون https تایپ می‌کند، یا روی پیوندی با http ساده می‌زند. اولین درخواست بی‌پاکت می‌رود و سایت تازه جواب می‌دهد «برو به https». در همان یک لحظه‌ی بی‌پاکت، کسی که در راه است می‌تواند دخالت کند.

با HSTS، سایت در جواب‌های HTTPS خود یک سرآیند (header، یعنی یک خط اطلاعات همراه جواب) به اسم Strict-Transport-Security می‌فرستد. معنی‌اش این است: «مرورگر عزیز، تا این مدت، با من فقط از راه HTTPS حرف بزن.» دو بخش اصلی دارد:

• max-age: مدت این قول به ثانیه. مثلا 31536000 یعنی یک سال.
• includeSubDomains: اگر باشد، قول برای همه‌ی زیردامنه‌ها هم هست.

از آن به بعد مرورگر حتی اگر http تایپ کنید، خودش https باز می‌کند و اگر گواهی سایت مشکل داشته باشد، اجازه نمی‌دهد از هشدار رد شوید.

یک ضعف هم دارد که خود RFC 6797 به آن اشاره می‌کند: اولین بار که مرورگر سایت را می‌بیند، هنوز قول را نگرفته است. برای همین مرورگرها فهرست از پیش‌آماده‌ای از سایت‌هایی دارند که از همان اول فقط HTTPS باز می‌شوند.

یک احتیاط هم برای مدیر سایت: HSTS را وقتی روشن کنید که مطمئنید همه‌ی بخش‌های سایت (و اگر includeSubDomains می‌گذارید، همه‌ی زیردامنه‌ها) HTTPS درست دارند. چون تا max-age تمام نشود، مرورگرهایی که قول را گرفته‌اند، نسخه‌ی بی‌پاکت را باز نمی‌کنند. بهتر است با مدت کوتاه شروع کنید و کم کم بلندش کنید.

چطور نسخه‌ی TLS سایت خودم را ببینم؟

جستجوی «tls 1.3 test» هم زیاد است. لازم نیست ابزار خاصی نصب کنید؛ مرورگر خودش می‌گوید.

در Chrome و مرورگرهای هم‌خانواده

1. سایت را باز کنید.
2. ابزار برنامه‌نویس (DevTools) را باز کنید: کلید F12، یا در مک Cmd و Option و I با هم.
3. به بخش امنیت بروید. در نسخه‌های تازه اسمش Privacy and security است و در نسخه‌های قدیمی‌تر Security. اگر پیدایش نکردید، از منوی سه‌نقطه‌ی DevTools، بخش More tools را ببینید. راهنمای خود Chrome اینجاست.
4. در بخش Connection جمله‌ای شبیه این می‌بینید: اتصال با TLS 1.3، با فلان روش توافق کلید و فلان روش رمز ساخته شده است. اگر روش توافق کلید X25519MLKEM768 باشد، اتصال شما پساکوانتومی است.

در Firefox

1. روی نشان قفل کنار نوار نشانی بزنید.
2. بخش Connection secure و بعد More information را باز کنید.
3. در زبانه‌ی Security، بخش Technical Details نسخه‌ی TLS و روش رمز را نشان می‌دهد.

از خط فرمان

اگر به سرور دسترسی دارید و می‌خواهید ببینید یک نسخه‌ی خاص روشن است یا نه، ابزار openssl این کار را می‌کند. مثلا دستور openssl s_client -connect example.com:443 -tls1_1 تلاش می‌کند فقط با TLS 1.1 وصل شود. اگر سرور شما TLS 1.1 را بسته باشد، این اتصال باید شکست بخورد؛ که خبر خوبی است. با -tls1_2 و -tls1_3 هم می‌توانید ببینید آن نسخه‌ها روشن‌اند. به جای example.com دامنه‌ی خودتان را بگذارید.

روی سرور کدام نسخه‌ها را نگه دارم؟ آنچه استانداردها می‌گویند

اینجا نظر هیچ شرکتی را نمی‌آوریم؛ فقط چیزی که سندهای رسمی IETF و NIST می‌گویند، و بالاتر منبعشان آمد.

1. SSL 2.0 و SSL 3.0 را خاموش کنید. RFC 6176 و RFC 7568 و RFC 9325.
2. TLS 1.0 و TLS 1.1 را خاموش کنید. RFC 8996 و RFC 9325. پیش از بستن، گزارش سرور خودتان و عدد همین صفحه را ببینید تا مطمئن شوید کسی جا نمی‌ماند.
3. TLS 1.2 را روشن نگه دارید. RFC 9325 پشتیبانی از آن را لازم می‌داند. فقط روش‌های رمز محکم را برایش روشن کنید؛ همان سند فهرست روش‌های توصیه‌شده را دارد.
4. TLS 1.3 را روشن کنید و ترجیحش بدهید. RFC 9325 و NIST SP 800-52 Rev. 2.
5. اگر نرم‌افزار سرورتان X25519MLKEM768 را دارد، به روشن کردنش فکر کنید. چون کلید دوگانه است، امنیت فعلی را کم نمی‌کند و مرورگری که بلد نیست، باز با روش قدیمی وصل می‌شود. RFC 10024 آن را تعریف می‌کند.
6. HSTS را با احتیاط اضافه کنید. RFC 6797.

یک نکته‌ی عملی: بعد از هر تغییر در تنظیم TLS، سایت را با چند مرورگر و از چند دستگاه باز کنید و گزارش خطای سرور را چند روز زیر نظر بگیرید.

محدودیت‌های عدد این صفحه

هر عددی محدودیتی دارد و بهتر است صریح بگوییم:

• فقط آنچه از Cloudflare می‌گذرد. درخواست‌هایی که به سایت‌های بیرون از این شبکه می‌روند، در این عدد نیستند. سایت‌های داخلی که روی Cloudflare نیستند هم شمرده نمی‌شوند.
• فقط درخواست‌های HTTPS. درخواست‌های HTTP ساده که پاکت ندارند، در این صفحه نیستند؛ سهمشان در صفحه‌ی HTTP است.
• سهم درخواست، نه آدم. برنامه‌ای که پشت سر هم درخواست می‌فرستد، وزن بیشتری از یک آدم دارد.
• ۷ روز و ۳۰ روز. سهم نسخه‌ها و سهم پساکوانتومی برای ۷ روز گذشته است، تا نوسان یک روز خاص عدد را تکان ندهد. روند پساکوانتومی برای ۳۰ روز است، چون رادار سفید بیشتر از آن نگه نمی‌دارد.
• کشور از روی نشانی IP. Cloudflare کشور هر درخواست را از روی آدرس IP آن حدس می‌زند. این حدس معمولا درست است، ولی همیشه نه.

برای همین ممکن است عدد این صفحه با عددی که جای دیگری دیده‌اید فرق داشته باشد. هر منبع چیز متفاوتی را می‌شمارد.

چند پرسش کوتاه

تفاوت SSL و TLS چیست؟

SSL نسل قدیمی همین فکر بود که امروز ناامن است و کنار رفته (RFC 7568). TLS جانشین آن است و نسخه‌ی تازه‌اش TLS 1.3 است (RFC 8446). «گواهی SSL» فقط اسم قدیمی گواهی‌هایی است که با TLS کار می‌کنند.

TLS 1.2 منسوخ شده است؟

نه. RFC 9325 پشتیبانی از TLS 1.2 را لازم می‌داند و می‌گوید TLS 1.3 باید ترجیح داده شود. آنچه منسوخ شده، TLS 1.0 و TLS 1.1 است (RFC 8996).

رمزنگاری پساکوانتومی لازم است؟

برای امروز، ارتباط شما با روش‌های فعلی امن است. پساکوانتومی برای این است که ارتباطی که امروز ضبط می‌شود، سال‌ها بعد هم باز نشود. چون با کلید دوگانه هزینه‌ی امنیتی ندارد، روشن کردنش وقتی نرم‌افزار سرور آماده است، کار معقولی است.

خلاصه در چند خط

• TLS پاکت دربسته‌ی وب است: پنهان می‌کند، از دست‌کاری حفظ می‌کند و هویت سایت را نشان می‌دهد.
• SSL و TLS 1.0 و 1.1 کنار رفته‌اند؛ TLS 1.2 هنوز قابل قبول است و TLS 1.3 باید روشن و ترجیح داده شود.
• TLS 1.3 دست‌دادن را به یک رفت و برگشت رساند، روش‌های قدیمی را حذف کرد و رازداری پیش‌رو را برای همه آورد.
• QUIC همان TLS 1.3 است، روی UDP، با دست‌دادنی یکی‌شده.
• رمزنگاری پساکوانتومی برای خطر «امروز جمع کن، فردا باز کن» است؛ وب امروز با کلید دوگانه‌ی X25519MLKEM768 آن را انجام می‌دهد و هر دو طرف باید بلدش باشند.
• عدد امروز بالای صفحه‌ی TLS رادار سفید است. داده‌ها از Cloudflare Radar می‌آید، با مجوز CC BY-NC 4.0.