ابزارهای جدید کلودفلر برای بررسی رمزنگاری پساکوانتومی

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

تتیم تحریریه۱۰ دقیقه مطالعه۰ بازدیدهمین حالا
ابزارهای جدید کلودفلر برای بررسی رمزنگاری پساکوانتومی

امروز، ما ابزارهای اضافی دیده‌بانی رمزنگاری پساکوانتومی (PQ) را به محصولات امنیت برنامه (Application Security) و لاگ‌های کلودفلر (Cloudflare) معرفی می‌کنیم. اکنون می‌توانید پذیرش رمزنگاری TLS 1.3 پساکوانتومی را برای ترافیک زنده مستقیماً از درون Logpush، Log Explorer و داشبورد HTTP Traffic Analytics بازرسی و نمودارگیری کنید. با نمایش الگوریتم توافق کلید مذاکره‌شده در هر درخواست ورودی از سوی بازدیدکنندگان به پلتفرم ما، کلودفلر (Cloudflare) به مشتریان تله‌متری دقیق و به ازای هر اتصال را ارائه می‌دهد تا وضعیت پساکوانتومی خود را ممیزی کنند، تطابق را ارزیابی نمایند و شکاف‌های رمزنگاری را در دامنه‌های خود شناسایی کنند.

کلودفلر (Cloudflare) سال 2029 را برای امنیت کامل پساکوانتومی هدف گذاری کرده است و اجرای یک انتقال رمزنگاری در مقیاس وسیع نیازمند تله‌متری دقیق است. ما از قبل رمزنگاری پساکوانتومی را در بسیاری از محصولات خود مستقر کرده‌ایم، از جمله در پلتفرم پروکسی ابری خود و در هر نقطه ورود و خروج از پلتفرم SASE خود. از آنجایی که بسیاری از مشتریان ما برای مهلت‌های آمادگی در برابر کوانتوم در حدود سال 2030 تلاش می‌کنند، ما با پیش‌فرض قرار دادن رمزنگاری پساکوانتومی در بسیاری از محصولات خود، به اشتراک‌گذاری آموخته‌های ابزار کشف رمزنگاری داخلی خود و راه‌اندازی ویژگی‌های جدید دیده‌بانی پساکوانتومی برای TLS که در این وبلاگ به آن‌ها خواهیم پرداخت، این انتقال را تسهیل می‌کنیم.

آوردن دیده‌بانی پساکوانتومی به سطح دامنه

هنگامی که صحبت از دیده‌بانی پساکوانتومی می‌شود، ما از طریق Cloudflare Radar دیدگاهی در سطح کلان نسبت به پذیرش پساکوانتومی در سراسر اینترنت در TLS داریم. در Radar، ما آمارهای جهانی رمزنگاری پساکوانتومی را ردیابی می‌کنیم، هم زمانی که کلودفلر (Cloudflare) درخواست‌های HTTP را از بازدیدکنندگان پروکسی می‌کند (اتصال بازدیدکننده به کلودفلر (Cloudflare)) و هم زمانی که کلودفلر (Cloudflare) به سرورهای مبدأ متصل می‌شود (اتصالات کلودفلر (Cloudflare) به مبدأ)، همانطور که در این شکل نشان داده شده است.

از Radar می‌توانیم ببینیم که حدود 70 درصد از ترافیک تولید شده توسط مرورگر که به شبکه کلودفلر (Cloudflare) می‌رسد (در اتصال بازدیدکننده به کلودفلر (Cloudflare)) با استفاده از الگوریتم ترکیبی ML-KEM (FIPS 203) با رمزنگاری پساکوانتومی محافظت می‌شود. در همین حال، می‌توانیم ببینیم که امروز، فقط حدود 15 درصد از مبداهایی که کلودفلر (Cloudflare) به آن‌ها متصل می‌شود از ML-KEM ترکیبی استفاده می‌کنند. این‌ها اعداد کلی هستند؛ عدد اول در تمام ترافیک تولید شده توسط مرورگری که می‌بینیم جمع‌آوری می‌شود و عدد دوم در تمام مبداهایی که به آن‌ها متصل می‌شویم جمع‌آوری می‌شود.

ما همچنین اخیراً تبادل کلید خودکار (Automatic Key Exchange) را برای اتصال کلودفلر (Cloudflare) به مبدأ راه‌اندازی کرده‌ایم که نشان می‌دهد کدام الگوریتم‌های رمزنگاری توسط یک مبدأ معین پشتیبانی می‌شوند. این مفید است زیرا پیکربندی‌های منسوخ می‌توانند باعث شوند یک مبدأ با استفاده از رمزنگاری کلاسیک به کلودفلر (Cloudflare) متصل شود، حتی اگر از رمزنگاری پساکوانتومی پشتیبانی کند.

در حالی که Radar و تبادل کلید خودکار هر دو دیدگاه‌های سطح کلان باارزشی از آمادگی در سطح اینترنت ارائه می‌دهند، مشتریان ما از ما خواسته‌اند که بتوانیم فراتر از اعداد کلی برویم و به رفتار دامنه‌های فردی شیرجه بزنیم.

ما مدت‌هاست که دیده‌بانی نسخه TLS استفاده شده در دامنه‌های فردی (TLS 1.3، TLS 1.2 و غیره) را فراهم کرده‌ایم.

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

رمزنگاری پساکوانتومی در TLS

قبل از اینکه وارد ویژگی‌های جدید محصول شویم، بیایید یک مرور سریع روی رمزنگاری پساکوانتومی در TLS داشته باشیم تا بتوانیم اطلاعاتی را که این ویژگی ارائه می‌دهد، درک کنیم.

در سال 2024، انستیتو ملی فناوری و استانداردهای آمریکا (NIST) اعلام کرد که RSA و رمزنگاری منحنی بیضوی (ECC) باید تا سال 2030 منسوخ شوند و بسیاری از دولت‌ها و رگولاتورها از آن زمان پشت آن مهلت ایستاده‌اند. به همین دلیل است که امروز، بسیاری از محصولات ما با رمزنگاری پساکوانتومی با استفاده از یک الگوریتم توافق کلید رمزنگاری به نام hybrid ML-KEM محافظت می‌شوند. رمزنگاری پساکوانتومی در حال حاضر برای متوقف کردن حملات ضبط کن و بعداً رمزگشایی کن (harvest-now-decrypt-later attacks) مورد نیاز است، جایی که یک مهاجم داده‌ها را امروز جمع‌آوری می‌کند و سپس آن‌ها را در آینده پس از آنلاین شدن کامپیوترهای کوانتومی قدرتمند رمزگشایی می‌کند. سازمان‌هایی که داده‌هایی دارند که حتی در صورت رمزگشایی در 3 تا 10 سال آینده ارزشمند هستند (بخش عمومی، دفاع، امور مالی، مخابرات، مراقبت‌های بهداشتی و غیره)، باید فوراً ترافیک خود را با رمزنگاری پساکوانتومی محافظت کنند.

در TLS 1.3، گروه تبادل کلید X25519MLKEM768 تنها الگوریتم پیشنهادی برای رمزنگاری پساکوانتومی است. این اکنون الگوریتم ترجیحی توسط اکثر مرورگرهای اصلی است. (توجه: رمزنگاری پساکوانتومی در TLS 1.2 یا هیچ نسخه قبلی TLS در دسترس نیست.) اگر از کروم (Chrome) استفاده می‌کنید، می‌توانید با راست‌کلیک کردن روی «Inspect»، رفتن به تب «Security» و جستجوی موارد زیر، الگوریتم توافق کلید استفاده شده توسط این صفحه web (یا هر صفحه دیگر) را بررسی کنید:

با X25519MLKEM768 در TLS 1.3، کلاینت و سرور هر دو را اجرا می‌کنند:

  • تبادل کلید دیفی-هلمن منحنی بیضوی (ECDHE) روی منحنی X25519 و
  • مکانیزم کپسوله‌سازی کلید شبکه مدولار پساکوانتومی (ML-KEM)

X25519 و MLKEM768 هر کدام یک راز مشترک تولید می‌کنند. سپس TLS آن دو راز را ترکیب کرده و از نتیجه برای رمزگذاری ترافیک TLS استفاده می‌کند. این رویکرد ترکیبی (hybrid) امنیت چندلایه فراهم می‌کند؛ تا زمانی که یکی از دو تبادل کلید امن باشد، راز مشترک حاصل نیز امن است. TLS 1.3 همچنین از سایر گروه‌های تبادل کلید، از جمله X25519، P-256 و P-384 پشتیبانی می‌کند که همگی فقط ECDHE کلاسیک روی منحنی‌های بیضوی مختلف هستند؛ این الگوریتم‌ها هنوز در سرتاسر وب استفاده می‌شوند. در نسخه‌های قبلی TLS همچنین می‌توانید توافق کلید مبتنی بر الگوریتم RSA را پیدا کنید که در برابر کوانتوم آسیب‌پذیر است و خوشبختانه این روزها به دلیل مشکلات امنیتی کلاسیک شناخته شده بسیار کمتر محبوب است.

اما رمزنگاری پساکوانتومی تنها بخش اول ماجرا است؛ بخش دوم احراز هویت پساکوانتومی است. هنگامی که کامپیوترهای کوانتومی قدرتمند وجود داشته باشند، باید نگران ارتقای گواهی‌ها و امضاهای استفاده شده در TLS 1.3 به دور از RSA و ECC و به سمت الگوریتم‌های پساکوانتومی مانند ML-DSA باشیم. ما به طور فعال به سمت آن هدف پیشرفت می‌کنیم. در واقع، ما اخیراً اعلام کردیم که مبدأها می‌توانند از گواهی‌های ML-DSA-44 روی TLS 1.3 برای اتصال به کلودفلر (Cloudflare) استفاده کنند و امروز اعلام کردیم که در حال راه‌اندازی یک مرجع صادرکننده گواهی (certificate authority) هستیم که از گواهی‌های درخت مرکل (Merkle Tree Certificates) پساکوانتومی پشتیبانی خواهد کرد. با این حال، در حال حاضر این حقیقت باقی می‌ماند که رمزنگاری پساکوانتومی با MLKEM ترکیبی بسیار گسترده‌تر از احراز هویت پساکوانتومی مستقر شده است.

آوردن دیده‌بانی پساکوانتومی به اتصال بازدیدکننده به کلودفلر

امروز ما امکان مشاهده میزان استفاده از توافق کلید پساکوانتومی را در اتصال بازدیدکننده به کلودفلر (Cloudflare) برای هر دامنه در داشبورد HTTP Traffic Analytics، Logpush و Log Explorer فراهم می‌کنیم.

برای مشاهده داده‌های توافق کلید TLS در دامنه‌های خود، به داشبورد کلودفلر (Cloudflare) بروید و در زیر تب Analytics به بخش HTTP Traffic بروید. در اینجا آمارهای عمیقی در مورد انواع ترافیک بازدیدکننده از دامنه‌های خود دریافت خواهید کرد، که اکنون شامل یک کارت اختصاصی برای گروه‌های توافق کلید TLS در اتصال بازدیدکننده به کلودفلر (Cloudflare) است. در اینجا نگاهی به کارت توافق کلید TLS برای یکی از دامنه‌های تستی ما داریم:

همانطور که می‌بینید، اکثریت ترافیک این دامنه از X25519MLKEM768 پساکوانتومی (در TLS 1.3) استفاده می‌کند. ما مقداری ترافیک را می‌بینیم که از ECDHE کلاسیک روی منحنی X25519 یا P-256 (در TLS 1.3 یا پایین‌تر) استفاده می‌کند. ترافیک با برچسب "None" یا از توافق کلید RSA (در TLS 1.2 یا پایین‌تر) استفاده می‌کند یا اصلا از TLS استفاده نمی‌کند. و در نهایت ما تعداد کمی از بازدیدکنندگان را داریم که از الگوریتم اکنون منسوخ شده X25519Kyber768Draft00 با TLS 1.3 استفاده می‌کنند، که ما آن را قبل از اینکه X25519MLKEM768 به طور کامل توسط کارگروه مهندسی اینترنت (IETF) استانداردسازی شود، پیاده‌سازی کردیم. ما صبر کرده‌ایم تا پشتیبانی از X25519Kyber768Draft00 را تا زمانی که اتصالات مشاهده شده به میزان چشمگیری کوچک شوند، حذف کنیم تا از پسرفت کلاینت‌هایی که این تنها راه آن‌ها برای پشتیبانی از رمزنگاری PQ است، جلوگیری کنیم.

در حالی که اینجا هستیم، چند نکته در مورد PQ-سازی ترافیک شما ارائه می‌دهیم. اگر به دامنه خود نگاه کردید و هیچ استفاده‌ای از X25519MLKEM768 نیافتید، باید تأیید کنید که TLS 1.3 فعال است. در داشبورد کلودفلر (Cloudflare)، دامنه خود را انتخاب کنید، به بخش SSL/TLS > Edge Certificates بروید و سپس اسکرول کنید تا کلید TLS 1.3 را پیدا کنید؛ TLS 1.3 را روی On قرار دهید. (تنظیمات پساکوانتومی جداگانه‌ای وجود ندارد: وقتی TLS 1.3 فعال است و یک بازدیدکننده از X25519MLKEM768 پشتیبانی می‌کند، کلودفلر (Cloudflare) به طور خودکار آن را مذاکره می‌کند.) همچنین، اگر اکثریت قریب به اتفاق ترافیک شما روی X25519 کلاسیک، P-256، P-384 یا None است، ممکن است به این دلیل باشد که اکثر بازدیدکنندگان آن دامنه کلاینت‌های غیرمرورگری هستند که فاقد پشتیبانی از X25519MLKEM768 و/یا TLS 1.3 هستند.

گروه توافق کلید اکنون می‌تواند یک اصطلاح فیلترینگ در داشبورد ترافیک HTTP باشد. در اینجا نحوه بررسی ترافیکی که از رمزنگاری پساکوانتومی با X25519MLKEM768 استفاده نمی‌کند آورده شده است:

تجزیه و تحلیل برای بررسی‌های کلی عالی است، اما توانایی دیدن این اطلاعات در خطوط لاگ منفرد می‌تواند حتی قدرتمندتر باشد. شما می‌توانید فیلد جدید ClientTLSKeyExchangeGroup را در زیر دسته TLS در مجموعه داده HTTP Requests فعال کنید تا در لاگ‌های اتصال Log Explorer و Logpush خود دیده‌بانی نسبت به توافق کلید پساکوانتومی فردی به دست آورید.

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

دیده‌بانی نسبت به مبداها و موارد بیشتر

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

به همین دلیل است که ما همچنین گروه تبادل کلید را از اتصال کلودفلر (Cloudflare) به مبدأ سطحی کرده‌ایم و دیده‌بانی سرتاسری را از کاربر تا مبدأ در Logpush به عنوان OriginTLSKeyExchangeGroup فراهم کرده‌ایم. (این گروه برای تمام اتصالات بازدیدکننده انجام شده به آن دامنه یکسان خواهد بود، به همین دلیل است که در داشبورد HTTP Traffic Analytics نشان داده نمی‌شود).

و برای مشتریانی که از سرورهای مبدأ قدیمی استفاده بعید است از رمزنگاری پساکوانتومی مدرن پشتیبانی کنند، ناامید نشوید. شما می‌توانید سرور مبدأ را پشت یک Cloudflare Tunnel قرار دهید تا ترافیک را از سرور مبدأ به کلودفلر (Cloudflare) روی TLS 1.3 با X25519MLKEM768 تونل کنید، بدون اینکه نیازی به ارتقای خود سرور مبدأ قدیمی باشد.

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

دامنه شما سفر پساکوانتومی خود را آغاز کرده است

اگر دامنه شما پشت کلودفلر (Cloudflare) است، سفر پساکوانتومی آن از قبل در جریان است. داشبورد HTTP Traffic Analytics و لاگ‌های خود را بررسی کنید تا درصد اتصالات بازدیدکننده به دامنه خود را که از قبل از TLS 1.3 با رمزنگاری پساکوانتومی (X25519MLKEM768) استفاده می‌کنند، مشاهده کنید. شما همچنین می‌توانید لاگ‌ها را بررسی کنید تا ببینید آیا از رمزنگاری پساکوانتومی در اتصال کلودفلر (Cloudflare) به مبدأ استفاده می‌کنید یا خیر. اگر سرور مبدأ شما بیش از حد قدیمی است که از رمزنگاری پساکوانتومی پشتیبانی کند، کافی است آن را پشت Cloudflare Tunnel قرار دهید. با تنظیمات و دیده‌بانی مناسب، می‌توانید امروز بخش بیشتری از ترافیک خود را روی کلودفلر (Cloudflare) در برابر حملات ضبط کن و بعداً رمزگشایی کن محافظت کنید.


منبع: blog.cloudflare.com

نظرات۰

برای نوشتن نظر، وارد حساب خود شوید.

ورود / ثبت‌نام

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