Loading...

راهنمای CDN.com.tr

سیاست TLS در لبه شبکه

لبه شبکه CDN.com.tr فقط TLS 1.2 و TLS 1.3 را می‌پذیرد، همراه فهرستی با اولویت سرور از تبادل کلید ECDHE و رمزهای AEAD. TLS 1.0، TLS 1.1، RC4، 3DES، MD5 و رمزهای export رد می‌شوند.

سیاست TLS در لبه شبکه

لبه شبکه CDN.com.tr فقط TLS 1.2 و TLS 1.3 را می‌پذیرد، همراه فهرستی با اولویت سرور از تبادل کلید ECDHE و رمزهای AEAD. TLS 1.0، TLS 1.1، RC4، 3DES، MD5 و رمزهای export رد می‌شوند.

بخش‌هایی از TLS که خودتان کنترل می‌کنید

سیاست پروتکل مال ماست؛ گواهی، و اینکه آیا مرورگرها اجازه بازگشت به HTTP دارند یا نه، مال شماست.

بدون بازگشت به HTTP

روشن کردن HSTS

به مرورگرها بگویید دیگر هرگز HTTP ساده را برای نام‌میزبان شما امتحان نکنند.

باز کردن این موضوع
وقتی خراب می‌شود

وضعیت SSL و عیب‌یابی

خواندن وضعیت گواهی وقتی یک نام‌میزبان آن‌طور که انتظار می‌رود HTTPS سرویس نمی‌دهد.

باز کردن این موضوع

مسیر در پنل

  1. Not a panel setting
  2. Edge configuration, applied to every account

پیش‌نیازها

  • یک نام‌میزبان خودتان که از قبل توسط CDN سرویس داده می‌شود.
  • openssl روی دستگاه‌تان اگر می‌خواهید مدرک را بازتولید کنید.

راستی‌آزمایی

  • openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 — handshake رد می‌شود و گزارش می‌دهد هیچ پروتکلی در دسترس نیست.
  • openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_3 — handshake موفق می‌شود و TLS_AES_256_GCM_SHA384 را گزارش می‌دهد.
  • کلاینتی که ابتدا یک رمز CBC ارائه می‌دهد باز هم روی یک رمز AEAD قرار می‌گیرد، چون انتخاب با اولویت سرور است.

موارد کاربرد

یک پرسش‌نامه امنیتی، یک مناقصه، یا اسکنر خودتان می‌پرسد سایت شما کدام نسخه‌ها و رمزهای TLS را می‌پذیرد. پاسخ برای هر حساب یکسان است: این روی لبه شبکه تنظیم شده و یک تنظیم به‌ازای حساب نیست.

جریان کاری

  1. به سؤال از روی سیاست زیر پاسخ دهید — این سیاست روی هر نام‌میزبانی که CDN سرویس می‌دهد اعمال می‌شود.
  2. اگر به‌جای یک بیانیه به مدرک نیاز دارید، بررسی‌های openssl را در فهرست verification روی نام‌میزبان خودتان اجرا کنید.
  3. اگر یک کلاینت از سمت شما نمی‌تواند وصل شود، پیش از فرض کردن یک مشکل گواهی، نسخه TLS آن را شناسایی کنید.

بررسی‌ها

  • پذیرفته‌شده: TLS 1.2 و TLS 1.3.
  • رد شده: TLS 1.0 و TLS 1.1. تلاش برای handshake روی آن نسخه‌ها بسته می‌شود، نه اینکه سطح پایین‌تر بیاید.
  • انتخاب رمز با اولویت سرور است: لبه شبکه از فهرست ترتیب‌بندی‌شده خودش انتخاب می‌کند نه اینکه ترتیب کلاینت را رعایت کند.
  • این فهرست تبادل کلید ECDHE همراه رمزهای AEAD است. RC4، 3DES، MD5، NULL و رمزهای رده export ارائه نمی‌شوند.
  • برای این هیچ سوییچ به‌ازای حساب وجود ندارد. نه در Delivery Rules است و نه در SSL Management، چون یک گزینه ضعیف‌تر برای یک مشتری کل لبه مشترک را ضعیف می‌کند.
  • یک کلاینت خیلی قدیمی که فقط TLS 1.0 صحبت می‌کند نمی‌تواند وصل شود. این همان نتیجه مورد نظر این سیاست است.

پرسش‌های متداول

می‌توانید TLS 1.0 را برای یکی از کلاینت‌های قدیمی ما فعال کنید؟

خیر. فهرست پروتکل بین همه سایت‌های روی لبه شبکه مشترک است، پس یک استثنا برای یک حساب همه را ضعیف می‌کند. TLS 1.0 و 1.1 منسوخ شده‌اند و هر خط پایه انطباق فعلی را رد می‌کنند — معمولاً همان خط پایه‌ای که باعث این سؤال شما شده.

اسکنر ما یک رمز CBC گزارش می‌دهد. آیا این یک یافته است؟

فهرست ارائه‌شده یک دنباله CBC بعد از رمزهای AEAD برای کلاینت‌های قدیمی‌تر نگه می‌دارد. چون انتخاب با اولویت سرور است، هر کلاینت مدرن یک رمز AEAD مذاکره می‌کند — اسکنر آنچه ارائه شده را فهرست می‌کند، نه آنچه استفاده می‌شود. پیش از آنکه آن را یک یافته بدانید، رمز مذاکره‌شده یک اتصال واقعی را بررسی کنید.

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

خیر. نسخه‌های پروتکل و رمزها سیاست لبه شبکه هستند؛ گواهی شما هویت را تعیین می‌کند، نه پارامترهای handshake را. یک گواهی Auto SSL و یک گواهی تجاری آپلودشده دقیقاً همان سیاست TLS را می‌گیرند.

چطور این را به یک ممیز ثابت کنم؟

دو دستور openssl را در فهرست verification روی نام‌میزبان خودتان اجرا کنید و خروجی را پیوست کنید. تلاش TLS 1.1 شکست می‌خورد و تلاش TLS 1.3 یک رمز AEAD مذاکره‌شده گزارش می‌دهد؛ این دو با هم هر دو نیمه این سیاست را نشان می‌دهند.