TLS و SSL: یک کار، دو نام
TLS (Transport Layer Security) میان TCP و HTTP قرار می‌گیرد و یک اتصال باز را به اتصالی خصوصی تبدیل میکند. وقتی آدرسی با https:// شروع میشود، چیزی که امنش میکند TLS است؛ همین پروتکل از ایمیل، DNS over TLS و بیشتر APIها هم محافظت میکند.
SSL (Secure Sockets Layer) نقطهٔ شروع بود. Netscape نسخهٔ SSL 2.0 را در 1995 و SSL 3.0 را در 1996 منتشر کرد. وقتی IETF پروتکل را تحویل گرفت، نامش را عوض کرد: TLS 1.0 (1999) در اصل همان SSL 3.1 است. پس از آن TLS 1.1 (2006)، TLS 1.2 (2008) و TLS 1.3 (2018) آمدند.
همهٔ نسخههای SSL امروز ممنوع‌اند. SSL 3.0 در 2014 با حملهٔ POODLE فروریخت و در 2015 رسماً ممنوع شد؛ TLS 1.0 و 1.1 هم در 2021، وقتی مرورگرها از قبل کنارشان گذاشته بودند، منسوخ اعلام شدند. آنچه امروز استفاده میشود TLS 1.2 و TLS 1.3 است.
نام قدیمی در زبان روزمره زنده مانده است. وقتی کسی می‌گوید «گواهی SSL»، منظورش گواهی‌ای است که سرور TLS ارائه میدهد؛ گواهی SSL و گواهی TLS جدا از هم وجود ندارند. هر دو همان فایل X.509 هستند و با هر نسخه‌ای از پروتکل که دو طرف بر سرش توافق کنند کار میکنند. اگر دنبال خود گواهی هستید، از راهنمای SSL رایگان شروع کنید.
TLS چه چیزی را تضمین میکند و چه چیزی را نه
TLS سه ویژگی به اتصال میدهد.
محرمانگی. هرچه پس از handshake می‌آید با کلیدهایی رمز میشود که فقط دو طرف می‌دانند. کسی که روی همان Wi-Fi، نزد ارائه‌دهندهٔ اینترنت یا روی یک لینک ترانزیت است، فقط بایت‌های رمزشده میبیند.
یکپارچگی. هر رکورد یک برچسب احراز اصالت دارد. اگر حتی یک بایت در مسیر تغییر کند، تشخیص داده میشود و بهجای تحویل دادهٔ دست‌کاری‌شده به برنامه، اتصال بسته میشود.
احراز هویت. سرور ثابت میکند کلید خصوصی گواهی‌ای را دارد که برای نامی صادر شده که مرورگر درخواست کرده است. همین مانع میشود مهاجم به‌سادگی بهجای شما پاسخ بدهد. هویت کلاینت را هم میشود با TLS دوطرفه (mTLS) احراز کرد، اما در وب عمومی کمتر پیش می‌آید.
دانستن کارهایی که TLS انجام نمی‌دهد هم به همان اندازه مفید است. TLS پنهان نمیکند با کدام سرور صحبت میکنید: آدرس‌های IP دیده میشوند و نام دامنه در SNI هم همین‌طور (پایین‌تر توضیح می‌دهیم). محتوا را امن نمیکند: یک SQL injection درست به همان اندازهٔ فرم ورود رمزشده می‌رسد و متوقف‌کردنش کار یک WAF است. و فقط از داده در مسیر محافظت میکند؛ وقتی سرور داده را رمزگشایی کرد، نقش TLS تمام میشود.
handshake در TLS 1.2: دو رفتوبرگشت
پیش از آنکه حتی یک بایت HTTP فرستاده شود، مرورگر و سرور باید روی نسخه و رمز توافق کنند، گواهی را بررسی کنند و کلیدهای مشترک بسازند. این مذاکره TLS handshake نام دارد و در TLS 1.2 دو رفتوبرگشت کامل روی اتصال TCP طول میکشد.
رفتوبرگشت اول. مرورگر ClientHello میفرستد: نسخه‌ها و cipher suiteهایی که پشتیبانی میکند، یک مقدار تصادفی و افزونه‌هایی مثل SNI و ALPN (اینکه کدام نسخهٔ HTTP را می‌خواهد). سرور با ServerHello (نسخه و رمز انتخاب‌شده)، زنجیرهٔ گواهی خود و، در suiteهای ECDHE، سهم خودش از تبادل کلید که با کلید گواهی امضا شده پاسخ میدهد.
رفتوبرگشت دوم. مرورگر گواهی را بررسی میکند، سهم کلید خودش را میفرستد و دو طرف کلیدهای یکسانی برای نشست محاسبه میکنند. سپس هرکدام یک Finished می‌فرستند، یعنی چکیده‌ای از همهٔ چیزهایی که تا آن لحظه رد و بدل شده؛ اگر کسی در handshake دست برده باشد، همین‌جا شکست می‌خورد.
تازه حالا اولین درخواست میتواند فرستاده شود. اگر handshake مربوط به TCP را هم بشماریم، هر اتصال HTTPS تازه روی TLS 1.2 پیش از آنکه مرورگر بتواند صفحه را بخواهد سه رفتوبرگشت خرج میکند. با 20 میلی‌ثانیه برای هر رفتوبرگشت کسی متوجه نمی‌شود؛ اما روی یک اتصال موبایل با 150 میلی‌ثانیه فاصله میان بازدیدکننده و سرور، به نیم‌ثانیه نزدیک میشود. این یکی از دلایلی است که CDNها TLS را روی edge خاتمه می‌دهند و نه روی origin دوردست: رفت‌وبرگشت‌هایی که handshake لازم دارد کوتاه میشوند.
TLS 1.3: یک رفتوبرگشت و جای خطای کمتر
TLS 1.3 (RFC 8446، سال 2018) بر یک مشاهده بنا شده است: مرورگر میتواند حدس بزند. تقریباً همهٔ سرورها از همان چند گروه تبادل کلید پشتیبانی میکنند؛ بنابراین مرورگر سهم کلیدش را بدون آنکه منتظر پرسش بماند، مستقیماً داخل ClientHello میفرستد.
سرور یک رمز انتخاب میکند، با سهم کلید خودش پاسخ میدهد و از همان لحظه هر دو طرف کلیدها را دارند. هرچه پس از ServerHello می‌آید، از جمله گواهی، از قبل رمز شده است. مرورگر گواهی را بررسی میکند، Finished را میفرستد و اولین درخواستش را درست پشت آن می‌گذارد: یک رفتوبرگشت برای TLS و روی هم دو رفتوبرگشت با TCP. در HTTP/3، که QUIC پروتکل TLS 1.3 را داخل handshake خودش حمل میکند، انتقال و رمزنگاری با هم در یک رفتوبرگشت انجام میشوند.
اگر حدس اشتباه باشد، یعنی سرور گروهی بخواهد که مرورگر برایش سهمی نفرستاده، سرور با HelloRetryRequest پاسخ میدهد و handshake یک رفتوبرگشت بیشتر طول میکشد. چون تقریباً همهٔ مرورگرها X25519 را پیشنهاد می‌دهند، این اتفاق کم پیش می‌آید.
نیمهٔ دیگر TLS 1.3 چیزهایی است که حذف کرد.
تبادل کلید RSA دیگر وجود ندارد. هر handshake از (EC)DHE موقت استفاده میکند، پس هر اتصال محرمانگی پیشرو دارد: کلید خصوصی‌ای که سال آینده دزدیده شود نمی‌تواند ترافیکی را که امروز ضبط شده رمزگشایی کند.
فقط رمزهای AEAD باقی مانده‌اند: AES-GCM و ChaCha20-Poly1305. حالت CBC، RC4، 3DES، SHA-1 و MD5 اصلاً بخشی از پروتکل نیستند.
مذاکرهٔ مجدد (renegotiation) و فشرده‌سازی حذف شدند و با آنها خانواده‌های کاملی از حمله‌ها.
TLS 1.3 در برابر پایین‌آوردن نسخه هم محافظت دارد: سروری که TLS 1.3 را می‌شناسد و به نسخهٔ قدیمی‌تر رانده شود، پاسخش را علامت می‌زند و کلاینت TLS 1.3 با دیدن این علامت اتصال را قطع میکند. اگر هر دو طرف 1.3 بلد باشند، از آن استفاده میکنند؛ هیچ تنظیم «1.3 را ترجیح بده» وجود ندارد که لازم باشد یادتان بماند.
0-RTT و ازسرگیری نشست: میان‌بر و هزینه‌اش
بازدیدکننده‌ای که قبلاً وصل شده به handshake کامل نیاز ندارد. در پایان یک handshake در TLS 1.3، سرور میتواند یک بلیت نشست (session ticket) به مرورگر بدهد؛ دفعهٔ بعد مرورگر آن را نشان میدهد و دو طرف از گواهی و توافق پرهزینهٔ کلید می‌گذرند. این ازسرگیری نشست (session resumption) است و همچنان یک رفتوبرگشت طول میکشد.
0-RTT (داده‌های زودهنگام یا early data) یک قدم جلوتر می‌رود. مرورگر با بلیت، اولین درخواستش را با کلیدهای نشست قبلی رمز میکند و آن را در همان بستهٔ ClientHello میفرستد. سرور میتواند بی‌درنگ پاسخ بدهد و درخواست منتظر هیچ handshakeی نمی‌ماند.
هزینه‌اش تکرار (replay) است. دادهٔ زودهنگام پیش از آنکه سرور در این اتصال حرفی زده باشد فرستاده میشود، پس هیچ چیز تازه‌ای از سرور در آن نیست. مهاجمی که این بستهٔ اول را ضبط کند میتواند دوباره بفرستدش و سرور یک درخواست معتبر را دو بار میبیند. برای یک GET که فایل استایل را می‌گیرد بی‌خطر است؛ برای یک POST که سفارش ثبت میکند، پول جابهجا میکند یا رمز عبور را عوض میکند، نه. داده‌های زودهنگام محرمانگی پیشرو هم ندارند: هر کس بعدها کلید بلیت‌ها را به دست آورد، میتواند آنها را رمزگشایی کند.
قاعده‌ها از همین‌جا می‌آیند. 0-RTT را فقط برای درخواست‌های idempotent بپذیرید (GET و HEAD بدون اثر جانبی). کاری کنید که سرور یا پراکسی درخواست‌های زودهنگام را با هدر Early-Data: 1 و وضعیت 425 Too Early از RFC 8470 علامت بزند تا برنامه بتواند از اجرای آنها سر باز بزند. و هرگز 0-RTT را شتاب‌دهنده‌ای مجانی ندانید که همه‌جا روشنش کنید.
edge در CDN.com.tr داده‌های زودهنگام 0-RTT را نمیپذیرد؛ پس مسئلهٔ تکرار اصلاً به برنامهٔ شما نمی‌رسد. بازدیدکنندهٔ بازگشتی نشستش را با یک handshake تک‌رفت‌وبرگشتی TLS از سر می‌گیرد.
گواهی‌ها و زنجیرهٔ اعتماد
گواهی راهی است که سرور با آن ثابت میکند کیست. گواهی یک کلید عمومی را به یک یا چند نام دامنه، فهرست‌شده در فیلد Subject Alternative Name، پیوند میدهد، دورهٔ اعتبار دارد و یک مرجع صدور گواهی (CA) امضایش کرده است.
مرورگرها مستقیماً به گواهی شما اعتماد نمی‌کنند. آنها به چند ده گواهی ریشه در مخزن اعتمادشان اعتماد دارند، و ریشه‌ها خودشان گواهی سایت‌ها را امضا نمی‌کنند: آنها گواهی‌های میانی را امضا میکنند و یک گواهی میانی گواهی شما را امضا میکند. مرورگر باید مسیری از گواهی شما تا ریشه‌ای که می‌شناسد بسازد: گواهی نهایی (گواهی شما برای www.example.com) ← میانی (گواهی صادرکنندهٔ CA) ← ریشه (در مخزن اعتماد).
از سرور انتظار می‌رود گواهی نهایی و گواهی‌های میانی را بفرستد. جاانداختن گواهی میانی خرابی کلاسیک است: مرورگرهای دسکتاپ اغلب باز هم کار میکنند، چون گواهی گم‌شده را در cache دارند یا میتوانند دریافتش کنند، اما curl، اپلیکیشن‌های Android، callbackهای پرداخت و کلاینت‌های API با خطای «unable to get local issuer certificate» از کار می‌افتند. اگر چیزی در مرورگرتان کار میکند ولی از روی یک سرور نه، اول زنجیره را بررسی کنید.
یک نمونهٔ واقعی: در 7 اکتبر 2026، cdn.com.tr گواهی‌ای از Let's Encrypt ارائه می‌داد که گواهی میانی YR1 امضایش کرده بود؛ زنجیره به ISRG Root YR می‌رسید و سرور نسخه‌ای از Root YR را هم می‌فرستاد که ISRG Root X1 بهصورت متقابل امضایش کرده بود، یعنی ریشه‌ای که مرورگرها سال‌هاست به آن اعتماد دارند. همین امضای متقابل است که اجازه میدهد ریشه‌ای کاملاً تازه روی دستگاه‌هایی که هرگز نامش را نشنیده‌اند کار کند.
مدت اعتبار. گواهی‌های Let's Encrypt نود روز اعتبار دارند و کل صنعت به همان سمت می‌رود: طبق قواعدی که CA/Browser Forum در 2025 تصویب کرد، بیشینهٔ عمر یک گواهی عمومی در مارس 2026 به 200 روز رسید و تا 2029 به 47 روز می‌رسد. تمدید دیگر کار سالانه نیست؛ فرایندی است که باید خودبه‌خود اجرا شود.
DV، OV، EV. سطح اعتبارسنجی مشخص میکند CA چه چیزی را بررسی کرده (فقط کنترل دامنه یا سازمان هم)، نه قدرت رمزنگاری را. یک گواهی رایگانِ اعتبارسنجی‌شده با دامنه و یک گواهی EV گران‌قیمت دقیقاً همان اتصال TLS را برقرار میکنند.
SNI: سایتهای HTTPS زیاد روی یک IP
HTTPS در روزهای اولش با مسئلهٔ مرغ و تخم‌مرغ روبه‌رو بود. سرور باید گواهی را در حین handshake ارائه کند، اما نام دامنهای که بازدیدکننده می‌خواهد در هدر Host پروتکل HTTP می‌آید، یعنی بعد از handshake. به همین دلیل هر سایت HTTPS به آدرس IP مخصوص خودش نیاز داشت.
SNI (Server Name Indication) این مشکل را با گذاشتن نام دامنه داخل ClientHello حل میکند. سرور پیش از انتخاب گواهی آن را می‌خواند؛ این‌طور است که یک آدرس میتواند هزاران سایت HTTPS را، هرکدام با گواهی خودش، میزبانی کند. همهٔ CDNها و همهٔ هاست‌های اشتراکی به آن وابسته‌اند و هر مرورگری از دههٔ گذشته آن را میفرستد.
دو پیامد آن ارزش دانستن دارد.
کلاینتی که SNI نفرستد، گواهی پیش‌فرض را می‌گیرد. کلاینت‌های خیلی قدیمی، برخی دستگاه‌های embedded و اسکریپت‌هایی که بدون تعیین نام سرور به یک آدرس IP وصل میشوند، گواهی جایگزین سرور را دریافت میکنند و با خطای ناهمخوانی نام از کار می‌افتند. وقتی با openssl تست میکنید، همیشه -servername را بدهید.
SNI رمزنگاری نمی‌شود. نام دامنه بهصورت متن ساده داخل ClientHello جابهجا میشود؛ پس شبکه میتواند ببیند کدام سایت را باز میکنید و بر همین اساس فیلترش کند، حتی اگر خود صفحه را نبیند. فیلترینگ مبتنی بر SNI همین‌طور کار میکند. افزونهای که آن را پنهان میکند Encrypted Client Hello (ECH) است و مرورگرها پشتیبانی از آن را شروع کرده‌اند؛ تا وقتی همه‌جا فراگیر نشده، فرض را بر این بگذارید که نام دامنه دیده میشود.
cipher suiteها: نام‌ها را چطور بخوانیم
یک cipher suite الگوریتم‌هایی را که اتصال استفاده میکند نام می‌برد. TLS 1.2 چهار انتخاب را در یک نام جا میدهد.
ECDHE-RSA-AES128-GCM-SHA256 یعنی: تبادل کلید با ECDHE (دیفی-هلمن موقت روی منحنی بیضوی که محرمانگی پیشرو میدهد)، احراز هویت با RSA (نوع کلید گواهی)، رمزنگاری داده با AES-128 در حالت GCM (یک رمز AEAD: محرمانگی و یکپارچگی در یک گام) و SHA-256 برای ساختن کلیدها.
نام‌ها در TLS 1.3 کوتاه‌ترند، چون تبادل کلید و امضا جداگانه مذاکره میشوند، و فقط پنج suite وجود دارد که سه‌تایشان واقعاً استفاده میشوند: TLS_AES_128_GCM_SHA256، TLS_AES_256_GCM_SHA384 و TLS_CHACHA20_POLY1305_SHA256. همه AEAD هستند و همه محرمانگی پیشرو دارند؛ دیگر چیزی برای تنظیم باقی نمی‌ماند.
یک فهرست خوب در TLS 1.2 تبادل ECDHE و رمزهای AEAD را در بالا دارد، هیچ چیزی با RC4، 3DES، MD5، NULL یا EXPORT در آن نیست و انتخاب با سرور است، بر اساس ترتیب خودش و نه ترتیب کلاینت. suiteهای قدیمی CBC اغلب برای کلاینت‌های خیلی قدیمی ته فهرست نگه داشته میشوند؛ وقتی سرور انتخاب میکند، مرورگر مدرن هرگز به آنها نمی‌رسد. یک اسکنر هرچه سرور پیشنهاد میدهد فهرست میکند؛ برای دیدن آنچه یک اتصال واقعی استفاده میکند، با دستورهای انتهای همین راهنما به suite مذاکره‌شده نگاه کنید.
ChaCha20-Poly1305 برای دستگاه‌هایی ساخته شده که شتاب‌دهندهٔ سخت‌افزاری AES ندارند، بیشتر گوشی‌های قدیمی، که در آنها بهصورت نرم‌افزاری از AES-GCM سریعتر است.
خطاهای رایج TLS و معنای واقعی آنها
ERR_SSL_PROTOCOL_ERROR (Chrome): handshake به شکلی قطع شد که مرورگر نتوانست دسته‌بندی‌اش کند. علت‌های معمول: چیزی غیر از TLS روی پورت 443 پاسخ میدهد (HTTP ساده یا صفحهٔ ورود شبکهٔ عمومی)، یک آنتی‌ویروس یا تجهیز شبکه اتصال را رهگیری میکند، یا سرور برای آن دامنه گواهی ندارد. اول از شبکهٔ دیگری امتحان کنید؛ اگر فقط روی یک شبکه خطا میدهد، مشکل از سرور نیست.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH، و در Firefox SSL_ERROR_NO_CYPHER_OVERLAP: کلاینت و سرور هیچ نسخه یا cipher suite مشترکی ندارند. امروز این تقریباً همیشه یعنی یکی از دو طرف خیلی قدیمی است، مثلاً یک دستگاه embedded که فقط TLS 1.0 بلد است یا سروری که هنوز برای آن تنظیم شده.
ERR_CERT_COMMON_NAME_INVALID: گواهی دامنهای را که باز کرده‌اید فهرست نکرده است. معمولاً وقتی پیش می‌آید که DNS یک زیردامنهٔ تازه را به سروری اشاره داده که هنوز برایش گواهی ندارد، یا وقتی www در گواهی نیست.
ERR_CERT_DATE_INVALID: گواهی منقضی شده یا ساعت بازدیدکننده اشتباه است. اگر فقط یک نفر آن را میبیند، ساعتش را بررسی کنید؛ اگر همه می‌بینند، تمدید متوقف شده است.
unable to get local issuer certificate (curl، OpenSSL و بسیاری از SDKها): سرور گواهی میانی‌اش را نفرستاده است. زنجیره را روی سرور درست کنید، نه مخزن اعتماد کلاینت را.
خطای 502 از یک پراکسی یا CDN در حالی که مرورگر قفل معتبر نشان میدهد: TLS بازدیدکننده سالم بود، اما اتصال خود پراکسی به origin شما شکست خورد. این handshake جداگانهای است با گواهی و نسخههای خودش؛ راهنمای خطای 502 Bad Gateway آن را قدم‌به‌قدم توضیح میدهد.
CDN.com.tr چطور TLS را روی edge خاتمه میدهد
وقتی سایت شما پشت CDN.com.tr است، اتصال TLS بازدیدکننده روی یک سرور edge از CDN.com.tr خاتمه می‌یابد، نه روی origin شما: edge گواهی شما را نگه می‌دارد و handshake را انجام میدهد. این کار را برای هر دامنه انجام میدهد، بدون تنظیمی در سطح هر سایت که ممکن باشد فراموش شود.
فقط TLS 1.2 و TLS 1.3. TLS 1.0 و 1.1 در handshake رد میشوند، نه اینکه نسخه پایین بیاید. edge رمز را از فهرست خودش انتخاب میکند که در صدرش تبادل ECDHE و رمزهای AEAD قرار دارند؛ در آزمایش ما در 7 اکتبر 2026، TLS 1.3 روی X25519 به TLS_AES_256_GCM_SHA384 رسید. سیاست برای همهٔ حسابها یکسان است و جزئیاتی که پرسش‌نامه‌های امنیتی می‌خواهند در صفحهٔ سیاست TLS آمده است.
HTTP/3 برای همهٔ سایت‌ها. HTTP/3 روی QUIC کار میکند که TLS 1.3 را در خود دارد. مرورگرها از هدر Alt-Svc با آن آشنا میشوند و در اتصال بعدی به آن می‌روند؛ چیزی برای روشنکردن نیست. بیشتر در HTTP/3 و IPv6.
برای هر دامنه یک گواهی، انتخاب‌شده با SNI. هرکدام از دامنه‌های شما با گواهی خودش سرویس داده میشود.
Let's Encrypt، صادرشده و تمدیدشده بهجای شما. با SSL خودکار، به محض اینکه دامنهٔ شما تأیید شد و DNS آن به ما اشاره کرد، گواهی درخواست میشود و 30 روز پیش از انقضا خودکار تمدید میشود. اگر DNS دامنهٔ شما روی CDN.com.tr باشد، گواهی میتواند یک wildcard باشد که دامنهٔ اصلی و همهٔ زیردامنه‌های سطح اول را پوشش میدهد و با یک رکورد DNS اعتبارسنجی میشود. سایت فعالی را منتقل میکنید؟ ویزارد صدور بدون قطعی همان wildcard را پیش از تغییر DNS و از راه یک رکورد TXT نزد ارائه‌دهندهٔ DNS فعلی‌تان صادر میکند و HTTPS از ثانیهٔ اول کار میکند.
گواهی خودتان، هر وقت لازم شد. یک گواهی OV یا EV که جای دیگری خریده‌اید را می‌توان بارگذاری کرد و به یک دامنه وصل کرد و دقیقاً همان سیاست TLS را می‌گیرد.
یک اتصال TLS جداگانه به origin شما. به‌طور پیش‌فرض درخواست HTTPS از origin شما هم با HTTPS دریافت میشود، از راه اتصال خود edge به پورت HTTPS در origin شما. بازدیدکننده هرگز این handshake را نمی‌بیند؛ اگر شکست بخورد، بهجای هشدار گواهی خطای 502 می‌گیرد.
HSTS، هر وقت آماده بودید. وقتی همه‌چیز روی HTTPS کار کرد، پیش‌تنظیم امنیتی HSTS به مرورگرها می‌گوید دیگر هرگز HTTP ساده را روی دامنهٔ شما امتحان نکنند.
TLS هر سایتی را در یک دقیقه بررسی کنید
پنج دستور به بیشتر پرسش‌های TLS پاسخ می‌دهند: یک اتصال واقعی از چه نسخه و رمزی استفاده میکند، سرور چه زنجیره‌ای میفرستد، گواهی کی منقضی میشود، آیا نسخههای قدیمی رد میشوند و handshake چقدر طول میکشد. بهجای www.example.com دامنهٔ خودتان را بنویسید و -servername را حذف نکنید؛ بدون آن، گواهی پیش‌فرض سرور را تست میکنید، نه گواهی خودتان را.
نسخه، رمز، زنجیره، تاریخ انقضا و زمان handshake از خط فرمان
# Negotiated version and cipher
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher is"
# The chain the server sends: subject (s:) and issuer (i:) of each certificate
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9]+ s:|^ *i:"
# When the certificate expires
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
# TLS 1.1 must be refused (SECLEVEL=0 stops your own OpenSSL from refusing first)
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 -cipher 'DEFAULT:@SECLEVEL=0' </dev/null
# Seconds spent on TCP and on TCP + TLS
curl -so /dev/null -w 'tcp %{time_connect} tls %{time_appconnect}\n' https://www.example.com/پرسش‌های پرتکرار
آیا TLS و SSL یکی هستند؟
TLS جانشین SSL است. IETF وقتی در 1999 پروتکل را تحویل گرفت نامش را عوض کرد، پس TLS 1.0 در عمل همان SSL 3.1 است. همهٔ نسخههای SSL امروز ممنوع‌اند؛ وقتی کسی «SSL» می‌گوید تقریباً همیشه منظورش TLS است و «گواهی SSL» هم چیزی جز گواهی‌ای که سرور TLS ارائه میدهد نیست.
آیا TLS 1.2 هنوز امن است؟
بله، اگر درست تنظیم شده باشد: تبادل کلید ECDHE، رمزهای AEAD مثل AES-GCM یا ChaCha20-Poly1305 و بدون RC4، 3DES یا suiteهای export. سرورها برای کلاینت‌های قدیمی‌تر همچنان آن را کنار TLS 1.3 ارائه می‌دهند. نسخه‌هایی که باید خاموش شوند TLS 1.0 و 1.1 هستند.
آیا TLS 1.3 سایت را سریعتر میکند؟
اتصالهای جدید را سریعتر میکند: handshake بهجای دو رفتوبرگشت یکی طول میکشد، یعنی هر اتصال جدید یک رفتوبرگشت شبکه صرفهجویی میکند که بیشتر روی شبکههای کند موبایل حس میشود. خود انتقال را سریعتر نمیکند؛ وقتی اتصال باز شد، TLS 1.2 و 1.3 داده را عملاً با یک سرعت جابهجا میکنند.
آیا روشنکردن 0-RTT امن است؟
فقط برای درخواستهایی که بیضرر قابل تکرارند. مهاجمی که دادهٔ 0-RTT را بگیرد میتواند دوباره بفرستدش؛ پس درخواستی که وضعیت را تغییر میدهد هرگز نباید از دادهٔ زودهنگام پردازش شود. سرورهایی که آن را میپذیرند باید محدودش کنند به متدهای امن و این درخواستها را علامت بزنند (هدر Early-Data، وضعیت 425) تا برنامه بتواند ردشان کند. edge در CDN.com.tr دادهٔ زودهنگام نمیپذیرد.
SNI چیست و آیا دیگران میتوانند آن را ببینند؟
Server Name Indication نام دامنهای است که مرورگر در ابتدای handshake میفرستد تا سرور گواهی درست را انتخاب کند؛ همان چیزی که اجازه میدهد یک IP سایتهای HTTPS زیادی را سرویس بدهد. بهصورت متن ساده فرستاده میشود، پس شبکه میبیند کدام سایت را باز میکنید، اما صفحه و محتوایش را نه. افزونهای که آن را پنهان میکند Encrypted Client Hello (ECH) است.
CDN.com.tr از کدام نسخههای TLS پشتیبانی میکند؟
TLS 1.2 و TLS 1.3 روی همهٔ دامنهها، بهعلاوهٔ HTTP/3 که همیشه روی TLS 1.3 کار میکند. TLS 1.0 و 1.1 رد میشوند. سیاست برای همهٔ حسابها یکسان است و فرقی نمیکند گواهی خودکار Let's Encrypt استفاده کنید یا گواهی خودتان را بارگذاری کنید.
برای داشتن TLS 1.3 باید چیزی را روی سرورم تغییر دهم؟
برای بازدیدکنندگانتان نه. پشت CDN.com.tr، handshake آنها روی edge انجام میشود، پس هرچه روی origin شما اجرا شود، TLS 1.3 و HTTP/3 میگیرند. origin شما فقط در اتصال جداگانهای که edge باز میکند شرکت دارد و آنجا هم TLS 1.2 و هم TLS 1.3 کار میکنند.