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

قبل از هر چیز؛ TLS چیست؟

(Transport Layer Security) یا TLS پروتکلی است که ارتباط بین دو سرور یا بین کاربر و سرور را رمزنگاری می‌کند. حرف S در انتهای https که مرورگرتان کنار قفل سبز نشان می‌دهد، دقیقا همین پروتکل است. TLS جانشین نسخه قدیمی‌تری به‌نام پروتکل SSL شده و تفاوت TLS و SSL هم عمدتا در الگوریتم‌های رمزگذاری و سطح امنیت است، هرچند هنوز خیلی‌ها از سر عادت به هر دو «SSL» می‌گویند.

نکته: TLS فقط برای وب‌سایت‌ها نیست. سرورهای ایمیل هم وقتی پیامی را بین خودشان جابه‌جا می‌کنند، از یک دستور به‌نام STARTTLS در پروتکل SMTP استفاده می‌کنند تا اتصال را رمزنگاری ارتباطات کند. اما این‌جاست که دو مسیر جدا می‌شود: TLS فرصت‌طلب و TLS اجباری.

TLS فرصت‌طلب یعنی چه؟

در Opportunistic TLS، سرور فرستنده همیشه اول تلاش می‌کند اتصال را رمزگذاری کند. اگر سرور مقصد از TLS پشتیبانی کند، پیام رمزنگاری‌شده می‌رود؛ اما اگر مقصد اصلا TLS نداشته باشد یا هندشیک رمزنگاری شکست بخورد، پیام بدون رمزگذاری و به‌صورت متن ساده ارسال می‌شود. پیام حتما می‌رسد، ولی امنیتش تضمینی نیست.

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

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

TLS اجباری چگونه کار می‌کند؟

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

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

مقایسه TLS فرصت طلب با اجباری

هیچ‌کدام از این حالت‌های TLS برنده مطلق نیستند، فقط اولویت‌هایشان فرق دارد:

• TLS فرصت‌طلب: اولویت با تحویل پیام است، نه امنیت صددرصدی. مناسب ایمیل‌های عمومی و بازاریابی.
• TLS اجباری: اولویت با امنیت است، حتی به قیمت از‌دست‌رفتن پیام. مناسب ایمیل‌های احراز هویت، مالی یا سازمانی.

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

مشکل واقعی TLS فرصت‌طلب: حمله downgrade

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

طبق سند رسمی RFC ۸۴۶۱ که استاندارد MTA-STS را تعریف می‌کند، درباره TLS فرصت‌طلب آمده:

“provides a high barrier against passive man-in-the-middle traffic interception” «سدی بلند در برابر شنود غیرفعال ترافیک (حمله مرد میانی) ایجاد می‌کند. »

نکته این‌جاست که این جمله فقط درباره شنود غیرفعال صدق می‌کند، نه حملات فعال downgrade؛ همان نقطه‌ای که این سند برای رفعش استاندارد جدیدی معرفی می‌کند.

راه‌حل مدرن: MTA-STS و DANE

برای رفع این ضعف، دو استاندارد جدیدتر معرفی شده که هردو نسخه پیشرفته‌تری از TLS اجباری هستند:

MTA-STS چیست؟

MTA-STS یا Mail Transfer Agent Strict Transport Security یک سیاست است که از طریق پروتکل HTTPS منتشر می‌شود و به سرورهای فرستنده می‌گوید فقط با رمزنگاری معتبر پیام بفرستند. این پروتکل معمولا در دو حالت اجرا می‌شود: حالت آزمایشی که فقط گزارش خطا می‌دهد و پیام را هم می‌فرستد، و حالت enforce که واقعا جلوی ارسال بدون رمزگذاری را می‌گیرد. توصیه اکثر متخصص‌ها این است که اول چند هفته در حالت آزمایشی بمانید و گزارش‌های TLS-RPT را بررسی کنید، بعد به حالت اجباری بروید.

DANE چیست و ارتباطش با DNSSEC چیست؟

DANE به‌جای تکیه بر مراجع صدور گواهی (CA)، اطلاعات گواهی سرور را مستقیم در DNS و از طریق رکوردهای TLSA، منتشر می‌کند. این روش امنیت بالاتری دارد چون به هیچ CA بیرونی وابسته نیست، اما یک پیش‌نیاز جدی دارد: بدون DNSSEC فعال روی دامنه، DANE اصلا کار نمی‌کند. برای همین با وجود امنیت بالاتر، هنوز خیلی کمتر از MTA-STS استفاده می‌شود؛ چون راه‌اندازی DNSSEC روی همه زنجیره DNS کار ساده‌ای نیست.

نقش تکنولوژی SNI و گواهی SSL چیست؟

نکته‌ای که کمتر به آن اشاره می‌شود این است که موفقیت هندشیک TLS به چند فاکتور دیگر هم بستگی دارد. تکنولوژی SNI (Server Name Indication) به سرور اجازه می‌دهد چند دامنه با گواهی‌های جداگانه را روی یک IP میزبانی کند و در ابتدای هندشیک TLS، مشخص کند کدام دامنه درخواست شده است. اگر SNI درست تنظیم نشود یا خطای احراز SSL رخ دهد (مثلا گواهی منقضی‌شده یا نامعتبر باشد)، حتی در حالت فرصت‌طلب هم اتصال رمزنگاری‌شده شکست می‌خورد و پیام بدون رمزگذاری می‌رود.

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

TLS فرصت طلب یا اجباری، کدامیک را انتخاب کنید؟

اگر سایت یا سرویس شما داده‌های حساس مثل اطلاعات پرداخت یا سلامت جابه‌جا می‌کند، TLS اجباری یا حتی MTA-STS در حالت enforce تنها انتخاب منطقی است. برای ایمیل‌های روزمره و خبرنامه‌ها، TLS فرصت‌طلب همچنان قابل قبول است، به‌شرطی که سرورهایتان همیشه TLS را پیشنهاد بدهند و به حالت متن ساده نیفتند، مگر اینکه واقعا لازم باشد. یادتان باشد انواع SSL و سطح رمزنگاری هم روی این تصمیم اثر دارد؛ گواهی‌های EV یا Wildcard نسبت به گواهی‌های رایگان معمولا سازگاری بیشتری با سرورهای مختلف نشان می‌دهند. 

TLS به کجا می‌رود؟ نگاهی به فردای این فناوری

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

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

سوالات متداول

۱. تفاوت TLS فرصت طلب و اجباری در یک جمله چیست؟ 

TLS فرصت‌طلب اول رمزنگاری را امتحان می‌کند و در نبود آن، پیام را بدون رمزگذاری می‌فرستد؛ اما TLS اجباری در نبود رمزگذاری، اصلا پیام را ارسال نمی‌کند.

۲. آیا TLS فرصت‌طلب اصلا امن است؟

تا حدی؛ در برابر شنود غیرفعال خوب عمل می‌کند، اما در برابر حملات فعال downgrade آسیب‌پذیر است.

۳.  MTA-STS چه فرقی با TLS اجباری معمولی دارد؟ 

MTA-STS یک نسخه استاندارد و قابل‌اعتماد از TLS اجباری است که سیاستش را از طریق HTTPS منتشر می‌کند و در برابر حملات downgrade مقاوم‌تر است.

۴. برای فعال‌کردن DANE چه پیش‌نیازی لازم است؟ 

DNSSEC فعال روی دامنه که بدون آن، رکوردهای TLSA که DANE به آن‌ها تکیه می‌کند، قابل اعتماد نخواهند بود.

۵. کدام حالت TLS برای کسب‌وکارهای کوچک مناسب‌تر است؟

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