Cloudflare One حالا اولین پلتفرم SASE است که در سراسر پلتفرم از رمزنگاری مدرن post-quantum پشتیبانی میکند و این پشتیبانی را نه فقط در Secure Web Gateway (SWG) بلکه در راهحلهای Zero Trust و WAN هم گسترش داده است. 🔒☁️
ما قبلاً در جریان Security Week 2025، اولین Secure Web Gateway ابری با پشتیبانی post-quantum را معرفی کرده بودیم؛ اما آن قدم تنها بخشی از راه بود. برای امن کردن کامل ترافیک سازمانی — از دستگاه کاربر تا شبکههای عمومی و خصوصی — به یک SASE کامل نیاز داریم و امروز این معادله تکمیل شده است.
بهطور مشخص، Cloudflare One اکنون از post-quantum hybrid ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) در تمامی on-ramps و off-ramps اصلی پشتیبانی میکند. این یعنی کل مسیرهای ورود و خروج ترافیک میتوانند از کلیدگذاری مقاوم در برابر کوانتوم استفاده کنند.
برای تکمیل این مسیر، پشتیبانی از رمزنگاری post-quantum را به Cloudflare IPsec (WAN-as-a-Service ابری ما) و Cloudflare One Appliance (دستگاه فیزیکی یا مجازی WAN که اتصالهای Cloudflare IPsec را برقرار میکند) اضافه کردیم. Cloudflare IPsec از پروتکل IPsec برای ایجاد تونلهای رمزنگاریشده بین شبکه مشتری و شبکه جهانی Cloudflare استفاده میکند و با بهرهگیری از IP Anycast، تونلها به نزدیکترین دیتاسنتر Cloudflare هدایت میشوند. این سرویس تنظیم را ساده و از دسترسی بالا (high availability) پشتیبانی میکند: اگر یک دیتاسنتر در دسترس نباشد، ترافیک به نزدیکترین دیتاسنتر سالم هدایت میشود.
Cloudflare IPsec در مقیاس شبکه جهانی ما اجرا میشود و هم از اتصال site-to-site در یک WAN و هم از اتصالات خروجی به اینترنت پشتیبانی میکند. ارتقای Cloudflare One Appliance هماکنون به صورت generally available در نسخه appliance 2026.2.0 در دسترس است. ارتقای Cloudflare IPsec در فاز closed beta قرار دارد و در صورت علاقه میتوانید برای دسترسی ثبتنام کنید. ⚙️
چرا post-quantum مهم است؟ این یک نگرانی دهه آینده نیست — همین حالا مهم است. دلایل اصلی که سازمانها امروز به PQC اولویت میدهند عبارتند از:
اولاً: مهلتها نزدیکاند. در پایان 2024، NIST سیگنالی واضح فرستاد: دوران رمزنگاری عمومی کلاسیک رو به پایان است. NIST یک ضربالاجل 2030 برای بازنشسته کردن RSA و Elliptic Curve Cryptography (ECC) و گذار به PQC که در برابر کامپیوترهای کوانتومی مقاوم باشد تعیین کرده است. سازمانهایی که مهاجرت را آغاز نکردهاند ممکن است با نزدیک شدن مهلت در معرض عدم تطابق و آسیبپذیری قرار بگیرند.
دوم: ارتقاهای رمزنگاری سخت و زمانبر است. ممکن است 2030 دور به نظر برسد، اما تجربه نشان داده بازنشستهکردن الگوریتمها گاهی دهها سال طول میکشد (مثلاً مشکلات MD5 حتی دو دهه پس از بازنشستگی آن ظاهر شدند). نبود «crypto agility» — یعنی توانایی سریع تعویض الگوریتمها — یکی از گلوگاههای اصلی است. با قرار دادن PQ encryption داخل خود پلتفرم SASE، ما crypto agility را تعبیه کردهایم تا مهاجرت سازمانها برای دسترسی از راه دور و اتصال site-to-site سادهتر شود.
سوم: دادهها ممکن است همین حالا در خطر باشند. حملهای که با نام “Harvest Now, Decrypt Later” شناخته میشود یعنی مهاجمان ترافیک حساس را امروز ضبط میکنند تا بعد از ظهور کامپیوترهای کوانتومی آن را رمزگشایی کنند. اگر دادههای شما عمر طولانیتری دارند (مثلاً اطلاعات مالی، سلامت یا اسرار دولتی)، در صورت نبود PQ protection همین حالا در معرض خطر هستند.
دو مسیر مهاجرت تا ایمنی کوانتومی: key agreement و digital signatures. برای گذار به PQC باید دو جزء کریپتوگرافیک اصلی را بازبینی کنیم: تبادل کلید (key agreement) و امضاهای دیجیتال.
مهاجرت 1 — برقراری کلید: key agreement به دو طرف اجازه میدهد روی یک shared secret بر بستر کانالی ناامن توافق کنند؛ این shared secret برای رمزنگاری ترافیک استفاده میشود و نتیجهاش post-quantum encryption خواهد بود. صنعت عمدتاً روی ML-KEM به عنوان استاندارد PQ key agreement همنظر شده است. ML-KEM معمولاً در TLS همراه با classical ECDHE به کار میرود؛ در این ترکیب، کلیدی که برای رمزنگاری تولید میشود از ترکیب خروجیهای ML-KEM و ECDHE بهدست میآید — که به آن hybrid ML-KEM گفته میشود.
در حال حاضر بیش از 60٪ از ترافیک TLS تولیدشده توسط انسان به شبکه Cloudflare با hybrid ML-KEM محافظت میشود. مهاجرت به hybrid ML-KEM موفق بوده چون: جلوی حملات “harvest-now, decrypt-later” را میگیرد، نیازی به سختافزار یا اتصال فیزیکی ویژه مثل QKD ندارد، و حتی برای اتصالات کوتاهمدت TLS تاثیری قابلتوجه روی عملکرد ندارد. از آنجا که ML-KEM کنار ECDHE اجرا میشود، کاهش امنیت یا تطابق نسبت به ECDHE کلاسیک ایجاد نمیشود.
مهاجرت 2 — امضاهای دیجیتال: امضاها و گواهیها برای تضمین اصالت استفاده میشوند تا مهاجمان فعال نتوانند خود را بهجای سرور جا بزنند. متأسفانه امضاهای PQ فعلاً اندازه بزرگتری نسبت به الگوریتمهای کلاسیک ECC دارند و همین باعث کندی در پذیرش شده است. اما مهاجرت به PQ signatures از نظر فوریت کمتر است، چون هدف این امضاها جلوگیری از دشمنان فعال مسلح به کامپیوترهای کوانتومی قدرتمند است که هنوز شواهدی از وجودش نیست؛ بنابراین تمرکز فعلی ما در ارتقای Cloudflare IPsec روی ارتقای key establishment به hybrid ML-KEM است، در حالی که در زمینه PQ signatures هم در فرایند استانداردسازی و آمادهسازی هستیم.
آژانسهای مختلف هم این دو مسیر را شناختهاند؛ از جمله CISA در نشرۀ ژانویه 2026 با عنوان “Product Categories for Technologies That Use Post-Quantum Cryptography Standards.”
پیش رفتن با IPsec — قدمی جدید: برای رسیدن به یک SASE که کامل با post-quantum محافظت شده باشد، محصول Cloudflare IPsec را ارتقا دادیم تا IPsec از hybrid ML-KEM پشتیبانی کند. این یک گام مهم است چون مسیر IPsec به سوی PQ فرقهایی با TLS داشته است.
نکته فنی: TLS بهعنوان استاندارد رایج برای رمزنگاری ترافیک عمومی اینترنت در لایه 4 مطرح است — مثلاً از مرورگر تا یک CDN — و طراحی آن همواره روی امنیت و تعاملپذیری بین فروشندهها متمرکز بوده است. از طرف دیگر، IPsec یک پروتکل لایه 3 است که معمولاً دستگاههایی از یک فروشنده را به هم وصل میکند (مثلاً دو روتر) و تاریخی از کمتر بودن دغدغهٔ تعاملپذیری دارد. این تفاوتها شکل مسیر مهاجرت IPsec به سمت کوانتوم را رقم زدهاند.
پرسشهای رایج: Pre-Shared Keys؟ Quantum Key Distribution؟ RFC 8784 که در می 2020 منتشر شد، قرار بود بهروزرسانی post-quantum برای IKEv2 باشد، اما در عمل استفاده از long-lived pre-shared keys (PSK) یا QKD را پیشنهاد میداد — هر دو رویکردها معایبی دارند.
RFC 8784 پیشنهاد میکند PSK را با کلیدی که از Diffie Hellman Exchange (DHE) گرفته میشود مخلوط کنند و در نتیجه PSK در hybrid با DHE اجرا شود. این روش جلوی harvest-now-decrypt-later را میگیرد اما در برابر مهاجمان کوانتومی از forward secrecy کامل محافظت نمیکند. Forward secrecy مهم است چون تضمین میکند اگر کلید بلندمدت لو برود، ترافیک گذشته قابل بازیابی نباشد؛ اما PSK بلندمدت این خاصیت را از بین میبرد.
راهحل دیگر که RFC 8784 به آن اشاره میکند، ترکیب DHE با یک کلید تازه تولیدشده از QKD است. اما QKD بر پایه مکانیک کوانتومی نیاز به سختافزار ویژه یا اتصال فیزیکی اختصاصی دارد؛ محدودیتی که استفاده از آن را برای مواردی مثل اتصال یک لپتاپ به سروری دور از طریق Wi‑Fi غیرعملی میکند. به همین دلایل ما سراغ پیادهسازی QKD در Cloudflare IPsec نرفتیم، و همچنین NSA و BSI و NCSC هم هشدار دادهاند که نباید صرفاً به QKD تکیه کرد.
حالا بحث سازگاری (interoperability): RFC 9370 که در می 2023 منتشر شد، استفاده از hybrid key agreement را مشخص کرد، اما برخلاف TLS که معمولاً فقط ML-KEM پستکوانتومی را در کنار classical DHE تعریف میکند، این استاندارد IPsec اجازه میدهد تا هفت کلیدگذاری مختلف همزمان اجرا شوند و جزئیات دقیق الگوریتمها را به سازندهها واگذار میکند. نتیجه؟ بعضی فروشندهها، مثل Palo Alto Networks، پشتیبانی از بیش از هفت ciphersuite مختلف PQC را در NGFW خود قرار دادند که اغلب با دیگر فروشندهها قابلتطبیق نیستند یا هنوز توسط NIST استاندارد نشدهاند.
در مقابل، TLS روندی عکس داشته و تعداد ciphersuiteها را از صدها در TLS 1.2 به حدود پنج در TLS 1.3 کاهش داده است. کم کردن «ciphersuite bloat» مزایایی دارد: تعاملپذیری بهتر بین فروشندهها و مناطق، کاهش خطر حملات downgrade به ciphersuiteهای ضعیف، کاهش مشکلات ناشی از پیکربندی نادرست و کاهش باگهای پیادهسازی با کوچکتر کردن کد پایه.
به همین خاطر، رویکرد ما در پیشبرد IPsec به سمت post-quantum هم تأکید بر تعادل میان امنیت، تعاملپذیری و سادگی دارد — یعنی کمتر کردن مجموعههای ناسازگار و تمرکز روی مجموعهای محدود، استانداردشده و قابلاعتماد که برای محیطهای عملیاتی واقعی مناسب باشد. این رویکرد به شما بهعنوان مهندس DevOps/SRE کمک میکند تا مهاجرت را با ریسک کمتر، پیچیدگی کمتر و امکان مدیریت بهتر انجام دهید. ⚖️
در پایان، اگر شما مسئول شبکه یا SRE در سازمان هستید: اکنون زمان برنامهریزی و آزمایش مهاجرت به PQC است. تمرکز اول را روی key establishment بگذارید (hybrid ML-KEM) و برای امضاهای دیجیتال برنامهریزی بلندمدت داشته باشید. داشتن یک SASE که از پایه PQ-aware طراحی شده باشد، مسیر مهاجرت را سادهتر و ایمنتر میکند و از دادههایی که ممکن است سالها بعد هم ارزش داشته باشند محافظت خواهد کرد. 🚀