آشنایی با پروتکل SSL/TLS

بخش اول: SSL/TLS چیست؟

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

ناگفته نماند سرویس‌های دیگه‌ای هم که بر مبنای TCP کار می‌کنند، از SSL/TLS استفاده میکنن که از اون‌ها میشه ایمیل (STMP/POP3)، ارسال پیام (XMPP) و FTP و VPN اشاره کرد. معمولا وقتی سرویسی از این پروتکل‌ها برای ارتباط امن استفاده میکنه، آخر اسمش حرف S اضافه میشه که مطمئناً عبارات HTTPS، STMPS، FTPS و SIPS به گوشمون خورده. بیشتر مواقع هم پیاده‌سازی SSL/TLS بر اساس کتابخانه OpenSSL انجام میشه.

پروتکل‌های SSL/TLS ارتباط بین دو محیط (معمولا کلاینت-سرور) رو رمزنگاری میکنن. که به موجب اون هیچ شخص (گروه) سومی نمیتونه اطلاعاتی که از طریق این ارتباط جابجا میشه رو بخونن یا تغییر بدن. این اطلاعات میتونه شامل نام‌های کاربری و پسووردها، اطلاعات حساب‌های بانکی و اطلاعاتی از این قبیل باشه.

شناسایی و تعیین هویت

پروتکل‌های SSL/TLS از رمزنگاری کلید عمومی (public key cryptography) استفاده میکنن. و علاوه بر رمزگذاری اطلاعات، از این تکنولوژی برای اعتبار سنجی طرف‌های اون ارتباط هم استفاده میشه. به عنوان مثال وقتی یک تراکنش مالی در یک درگاه بانکی در حال انجام هست، مرورگر شما مطمئن هست که اطلاعات حساب شما فقط و فقط به سرورهای بانک ارسال میشه و اطلاعات ارسالی از سوی سرور بانک هم فقط و فقط برای شمایی که اطلاعات رو وارد کردید نمایش داده بشه. و این اطمینان از هویت طرفین ارتباط، با رمزنگاری کلید عمومی حاصل میشه. وقتی یک ارتباط امن بین سرور و کلاینت ایجاد میشه، اون سرور، گواهی SSL/TLS (SSL/TLS certificate) خودش رو برای کلاینت ارسال میکنه و این گواهی توسط یک مرجع صدور گواهی معتبر (CA: Certificate Authority) بررسی میشه. چون این گواهی‌ها قابل تحریف نیستند، نهایتا با تأیید این گواهی توسط CA، مبادله اطلاعات از طریق این ارتباط امن انجام میشه.

یک توضیح کوتاه در مورد نحوه عملکرد رمزنگاری کلید عمومی: این نوع رمزنگاری توسط یک جفت کلید (key pair) انجام میشه که یکیشون کلید عمومی (public key) و دیگری کلید خصوصی (secret key) هستند. کلید عمومی در دسترس همه هست و همه میتونن با استفاده از اون اطلاعاتشون رو رمزگذاری کنند و رمزگشایی این اطلاعات تنها با در اختیار داشتن کلید خصوصی ممکن خواهد بود که در اختیار همه قرار نداره.

مکانیسم Perfect Forward Secrecy یا به اختصار PFS

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

بخش دوم: مختصری از تاریخچه SLL/TLS

خیلی کوتاه اشاره‌ای به تاریخچه SLL/TLS می‌کنیم و بعدش میریم سراغ مطالب جذاب‌تر.

پروتکل SSL اولین بار در سال ۱۹۹۴ توسط کمپانی Netscape معرفی شد. و دلیل اصلی ارائه این پروتکل، رشد اینترنت و نیاز به تبادل امن اطلاعات در این بستر بود. نسخه ۱٫۰ این پروتکل هیچوقت منتشر نشد چون مشکلات امنیتی بزرگی داشت. نسخه ۲٫۰ در سال ۱۹۹۵ و ورژن ۳٫۰ که آخرین ورژن SSL هم بود، سال ۱۹۹۶ منتشر شد. سال ۲۰۱۱ بود که SSL version 2.0 رسما منسوخ شد و در سال ۲۰۱۵ هم اتفاق مشابه برای SSL version 3.0 افتاد.

اولین ورژن TLS در سال ۱۹۹۹ به عنوان یه آپگرید برای SLL version 3.0 عرضه شد. تفاوت عمده‌ای ایجاد نکرد ولی این تفاوت به اندازه‌ای بود که باعث شه پروتکل TLS به عنوان یه پروتکل مجزا به کار خودش ادامه بده. به ترتیب در سال‌های ۲۰۰۶ و ۲۰۰۸ و ۲۰۱۸ هم TLS ورژن‌های ۱٫۱ و ۱٫۲ و ۱٫۳ منتشر شدن.

بخش سوم: نحوه رمزگذاری اطلاعات توسط SSL/TLS

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

رمزگذاری روندی هست که طی اون یک پیام که برای انسان مفهوم هست (plaintext) به پیامی که برای انسان مفهوم نیست (ciphertext) تبدیل میشه (تصویر پایین). و این عمل توسط یک (یا چند) کلید رمزگذاری (encryption key) انجام میشه. به این ترتیب فقط اشخاصی که که این کلید در اختیارشون هست یا به اصطلاح authorized هستند میتونن ciphertext رو رمزگشایی کنن و به اطلاعات اصلی (plaintext) دسترسی داشته باشند.

رمزنگاری نامتقارن (asymmetric encryption) و مجموعه‌های رمزنگاری (cipher suites) از اولیه‌ترین مفاهیم رمزنگاری مورد استفاده در پروتکل‌های SLL/TLS هستند که باید در موردشون بدونیم.

رمزنگاری متقارن (symmetric encryption)

در این روش، رمزگذاری و رمزگشایی اطلاعات هر دو با یک کلید (key) انجام میشه.به این صورت که اطلاعات خام (plaintext) توسط یک کلید رمزگذاری میشن و برای رمزگشایی اطلاعاتی که رمز شدن (ciphertext) هم از همون کلید استفاده میشه.

رمزنگاری نامتقارن (asymmetric encryption)

رمزنگاری نامتقارن نام دیگر رمزنگاری کلید عمومی (public key cryptography) هست که در بخش اول به توضیحش دادم. رمزنگاری نامتقارن (کلید عمومی) در واقع در تکمیل رمزنگاری متقارن به وجود اومد. از اشکالات رمزنگاری متقارن میشه به زیر اشاره کرد:

• کلید رمزگذاری و رمزگشایی یکسان هستند.
• برای انتقال کلید رمزنگاری، از قبل باید یک ارتباط امن ایجاد شده باشه.
• برای هر ارتباط مجزا، یک کلید منحصر به فرد نیاز است (پیچیده و سخت شدن مدیریت کلیدها).
• امکان اعتبارسنجی کاربران وجود ندارد (no user authentication).

با معرفی رمزنگاری نامتقارن، همه اشکالات فوق رفع شد اما یکی از معایبی که رمزنگاری نامتقارن داره، کند بودنش نسبت به رمزنگاری متقارن هست.

پروتکل TLS به شما این اجازه رو میده که از الگوریتم‌های مختلف رمزنگاری برای مقاصد مختلف استفاده کنید. این الگوریتم‌های مختلف با عنوان مجموعه‌های رمزنگاری (cipher suites) شناخته میشن. همونطور که گفتم این مجموعه‌ها برای هر منظوری، یک الگوریتم رمزنگاری مجزا ارائه میدن.

مجموعه‌های رمزنگاری (Cipher suites)

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

• الگوریتم تبادل کلید (key exchange algorithm)
• الگوریتم تبادل حجیم (bulk encryption algorithm)
• کد احراز هویت پیام (MAC: message authentication code)

کلید رمزگذاری (و رمزگشایی) باید قبل از شروع تبادل اطلاعات در اختیار طرفین این ارتباط امن قراره بگیره که بتونن اطلاعات ارسالی و دریافتی رو رمزگذاری و رمزگشایی کنن که الگوریتم تبادل کلید مسئول این امر هست.

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

کد احراز هویت پیام، مسئول تأیید تمامیت و درستی اطلاعات رو به عهده داره. به خصوص اینکه در حین ارسال این اطلاعات دستکاری نشده باشند.

علاوه بر سه موردی که اشاره کردم، مجموعه‌های رمزنگاری (cipher suites) همچنین می‌تونن شامل امضاها و الگوریتم‌هایی باشن که به احراز هویت سرور و کلاینت هم کمک کنند. به طور کلی صدها مجموعه رمزنگاری مختلف وجود دارند که ترکیب‌های مختلف الگوریتم‌ها در اون به کار برده شده و برخی از این ترکیب‌ها در گذر زمان نشون دادن که امنیت بیشتر و بهتری رو ارائه میدن.

هر مجموعه رمزنگاری (cipher suite) یک اسم منحصربفرد داره که علاوه بر مجزا کردن این مجموعه‌ها از هم، نشون دهنده محتوای الگوریتمیش هست. به عنوان مثال اسم زیر رو برای یک مجموعه رمزنگاری در نظر بگیرید:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

قسمت اول (TLS) معرف پروتکلی است که قراره از این مجموعه استفاده کنه.

عبارت ECDHE نشان دهنده الگوریتم تبادل کلید مورد استفاده در این مجموعه است.

عبارت RSA به مکانیسم احراز هویت در حین “دست دادن (handshake)” اشاره داره.

عبارت AES_128_GCM اشاره به الگوریتم رمزگذاری اطلاعات داره که عدد ۱۲۸ نشون دهنده سایز کلید رمزنگاری است که ۱۲۸ بیت خواهد بود.

عبارت SHA256 هم الگوریتم احراز هویت پیام رو  نشون میده.

بخش چهارم: نحوه ایجاد یک ارتباط TLS امن

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

همه ورژن‌های TLS تا نسخه ۱٫۲ تا حد زیادی از روتین هندشیک یکسانی استفاده میکردن ولی در نسخه ۱٫۳ (نسخه فعلی) این عمل بسیار ساده‌تر و سریع‌تر شده که به توضیح اون‌ها می‌پردازم.

مراحل هندشیک در TLS 1.2

گام اول: سلام دادن کلاینت (Client Hello)

در این مرحله، کلاینت با ارسال پیام سلام کلاینت (Client Hello) اطلاعات زیر رو برای سرور ارسال میکنه:

• ورژن کلاینت (Client Version): لیستی از ورژن‌های پروتکل SSL/TLS که کلاینت ازشون پشتیبانی میکنه و همیشه ترجیح میده که سرور اولین ورژن ارائه شده در اون لیست رو انتخاب کنه.
• عدد تصادفی کلاینت (Client Random): یک عدد ۳۲ بیتی رندوم که بعدها با ترکیب عدد رندوم سرور، کلید رمزگذاری (encryption key) رو تولید خواهند کرد.
• شناسه ارتباط (Session ID): این شناسه برای ایجاد ارتباط امن (secure connection) استفاده خواهد شد.
• روش‌های فشرده سازی (Compression Methods): با این روش‌ها، پک‌های SSL/TLS فشرده سازی میشن که این کار به خاطر اینه که پهناد باند کمتری استفاده شه و انتقال اطلاعات سریع‌تر انجام شه.
• مجموعه‌های رمزنگاری (Cipher Suites): در مورد ماهیت این مجموعه‌ها قبلا صحبت کردم. مثل ورژن کلاینت، لیستی از مجموعه‌های رمزنگاری که توسط کلاینت پشتیبانی میشه، به سرور ارسال میشه و باز هم کلاینت ترجیح میده که اولین مجموعه موجود در لیست توسط سرور انتخاب شه.
• افزونه‌ها (Extensions): کلاینت میتونه درخواست ابزارهای بیشتری بکنه برای برقراری ارتباط امن. مثل الگوریتم‌های پیچیده‌تر رمزنگاری یا الگوریتم‌های امضا. در صورتی که سرور نتونه این ابزارها رو مهیا کنه، کلاینت میتونه کلا ارتباط رو لغو کنه.

گام دوم: سلام دادن سرور (Server Hello)

وقتی سرور، Client Hello رو دریافت میکنه، متقابلا Server Hello رو برای کلاینت ارسال میکنه که یا ناموفق بودن هندشیک رو بیان میکنه، یا در صورت موفق بودن اون، اطلاعات زیر رو برای کلاینت ارسال میکنه:

• ورژن سرور (Server Version): از بین ورژن‌های SSL/TLS که کلاینت ارسال کرده است، سرور لیست ورژن‌هایی که ترجیح میدهد از آن‌ها استفاده کند را به کلاینت برمی‌گرداند.
• عدد تصادفی سرور (Server Random): یک عدد ۳۲ بیتی رندوم که با ترکیب عدد رندوم کلاینت، کلید رمزگذاری را تولید خواهند کرد.
• شناسه ارتباط (Session ID): اگر شناسه ارتباطی که کلاینت ارسال کرده است خالی باشد، سرور یک شناسه ارتباط جدید ایجاد کرده و آن را برای کلاینت ارسال میکند. اما اگر شناسه ارتباط ارسالی توسط کلاینت خالی نباشد، سرور با جستجو در شناسه‌های قبلی موجود در حافظه، آخرین ارتباط مربوط به آن شناسه را پیدا کرده و آن را ادامه می‌دهد.
• مجموعه‌های رمزنگاری (Cipher Suites): از بین مجموعه‌های رمزنگاری که کلاینت به سرور پیشنهاد کرده است، سرور یکی را انتخاب کرده و برای کلاینت ارسال می‌کنه.
• روش‌های فشرده سازی (Compression Methods): از بین روش‌های فشرده سازی که کلاینت برای سرور ارسال کرده است، سرور یکی را انتخاب کرده و برای کلاینت ارسال می‌کنه.

گام سوم: گواهینامه سرور (Server Certificate):

سرور یک گواهینامه تأیید شده SSL/TLS که حاوی اطلاعات احراز هویت سرور هست رو برای کلاینت ارسال می‌کنه که این گواهینامه همچنین حاوی کلید عمومی رمزگذاری اطلاعات هم هست.

گام چهارم: گواهینامه کلاینت (Client Certificate):

ارسال گواهینامه احراز هویت کلاینت برای سرور، خیلی معمول نیست و در موارد خاصی که کم پیش میاد، سرور نیاز خواهد داشت که کلاینت هم هویت خودش رو احراز کنه. که مثل گام قبلی ولی این بار کلاینت یک گواهینامه SSL/TLS تأیید شده رو برای سرور ارسال می‌کنه.

گام پنجم: تبادل کلید سرور (Server Key Exchange):

در این مرحله کلاینت قراره یک رشته ۴۸ بیتی رو با سرور به اشتراک بذاره که هم سرور و هم کلاینت قراره ازش استفاده کنند که کلیدهای عمومی و خصوصی رمزنگاری رو برای اون ارتباط تولید کنن. اسم این رشته ۴۸ بیتی pre-master secret هست. حالا پیام تبادل کلید سرور (server key exchange message) وقتی ارسال میشه که گواهینامه ارسالی توسط سرور، برای کلاینت به اندازه کافی امن نباشه که بتونه این رشته ۴۸ بیتی رو به اشتراک بگذاره. لازم به ذکره این رشته ۴۸ بیتی به صورت رمزگذاری شده از کلاینت به سرور میشه چون در گام سوم کلید عمومی برای کلاینت ارسال شده و می‌تونه باهاش اطلاعات ارسالی به سرور رو رمزگذاری کنه.

گام ششم: پایان سلام سرور (Server Hello Done):

سرور با ارسال پیامی برای کلاینت اعلام می‌کنه که Server Hello به پایان رسیده.

گام هفتم: تبادل کلید کلاینت (Client Key Exchange):

پیام تبادل کلید کلاینت دقیقا بعد از “پایان سلام سرور” انجام می‌شه. اگر سرور از کلاینت درخواست احراز هویت کرده باشه، پیام تبادل کلید کلاینت بعد از این احراز هویت انجام می‌شه. در همین مرحله است که رشته ۴۸ بیتی تولید و برای سرور ارسال می‌شه.

بعد از این که سرور این رشته ۴۸ بیتی (pre-master secret) رو دریافت می‌کنه، با استفاده از کلید خصوصی که در اختیار داره، اون رو رمزگشایی می‌کنه. حالا هم سرور و کلاینت به این رشته ۴۸ بیتی دسترسی دارن و از طرفی هم قبلا هر کدوم یه عدد ۳۲ بیتی تصادفی رو با هم به اشتراک گذاشتن و با ترکیب این دو عدد تصادفی و این رشته ۴۸ بیتی اقدام به تولید یه کلید رمزگذاری ۴۸ بیتی می‌کنن. این کار توسط یک PRF (pseudo-random function) انجام میشه که کار این تابع اینه که مقادیر شبه تصادفی تولید کنه. خروجی ۴۸ بیتی این تابع master secret نام داره.

هم سرور و هم کلاینت با استفاده از master secret، مقادیر زیر رو تولید می‌کنن:

• کلید احراز هویت کلاینت
• کلید احراز هویت سرور
• کلید رمزگذاری اطلاعات توسط کلاینت
• کلید رمزگذاری اطلاعات توسط سرور
• بردار اولیه کلاینت
• بردار اولیه سرور

کلاینت و سرور از این کلیدها استفاده خواهند کرد تا در طول این ارتباط امن، اطلاعات رو رمزگذاری و رمزگشایی کنند.

توضیح کوتاه در مورد بردارهای اولیه (Initialization Vectors): در برخی الگوریتم‌های رمزنگاری، نیاز داریم که اطلاعات رو به بلوک‌های با طول یکسان تقسیم کنیم که برای رمزگذاری هر بلوک، به بلوک قبلی هم نیاز داریم. ولی چون برای بلوک اول، بلو قبلی‌ای وجود نداره، از بردارهای اولیه استفاده می‌شه که امنیت این بردارهای اولیه هم درست به اندازه امنیت کل اطلاعات اصلی اهمیت داره. به این الگوریتم‌ها Block Ciphers می‌گن. حالا اگر Cipher Suite مورد استفاده در یک ارتباط شامل الگوریتم‌های بلوکی باشه، از master secret برای تولید بردارهای اولیه مورد نیاز هم استفاده خواهد شد.

گام هشتم: تغییر مشخصات رمزی کلاینت (Client Change Cipher Spec):

در این مرحله کلاینت آماده است تا وارد محیط رمزنگاری شده و امن بشه و از این گام به بعد، همه اطلاعات ارسالی توسط کلاینت، رمزگذاری شده خواهد بود.

گام نهم: پایان هندشیک کلاینت (Client Handshake Finished):

پیام پایان هندشیک کلاینت نشان دهنده پایان هندشیک از سوی کلاینت خواهد بود و همچنین این پیام، اولین پیام رمزگذاری شده از سوی کلاینت خواهد بود.

گام دهم: تغییر مشخصات رمزی سرور (Server Change Cipher Spec):

از این گام به بعد سرور نیز وارد ارتباط رمزگذاری شده خواهد شد و کلیه اطلاعات ارسالی توسط سرور، به صورتی رمزگذاری شده خواهد بود.

گام یازدهم: پایان هندشیک سرور (Server Handshake Finished):

پیام پایان هندشیک سرور نشان دهنده پایان هندشیک از سوی سرور خواهد بود و در این مرحله SSL/TLS Handshake تموم می‌شه.

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

مراحل هندشیک در TLS 1.3

همونطور که جزئیات هندشیک در TLS 1.2 رو دیدیم، این هندشیک دو مرحله رفت و برگشت داره. اولی سلام دادن کلاینت و سرور و دومی هم تبادل کلید سرور و کلاینت و سوئیچ به محیط رمزگذاری شده است.

هندشیک در TLS 1.3 با مراحل یک طرفه انجام می‌شه و همچنین روش‌های فشرده سازی (Compression Methods) ازش حذف شده.

در TLS 1.3 Handshake وقتی کلاینت سلام می‌ده (Client Hello) بلافاصله بعدش، پروتکلی که سرور قراره انتخاب کنه رو حدس می‌زنه. و بعد کلیدی که با این پروتکل رو تولید کرده، با سرور به اشتراک می‌ذاره. از طرفی پیام سلام دادن سرور (Server Hello) شامل کلید تولید شده، گواهینامه تأیید اعتبار و پیام پایان هندشیک خواهد بود. بعد از این دیگه نیازی به تبادل  و توافق روی مجموعه‌های رمزنگاری و غیره نخواهد بود چرا که قبلا کلیدها به اشتراک گذاشته شدن و هم سرور و هم کلاینت ابزار مورد نیاز برای رمزگذاری اطلاعات و ایجاد ارتباط امن رو دارن.

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

بخش پنجم: آسیب‌پذیری‌ها و حملات SSL/TLS

پروتکل‌های SSL/TLS هم مثل هر تکنولوژی دیگه‌ای نواقصی دارن که در این بخش اشاره کوتاهی به اون‌ها می‌کنم.

حمله POODLE (Padding Oracle On Downgraded Legacy Encryption):

این حمله که در اکتبر ۲۰۱۴  جزئیاتش منتشر شد، از کلاینت-سرورهایی سوء استفاده می‌کنه که هنوز از SSL 3.0 برای سازگار بودن با سیستم‌های قدیمی‌تر استفاده می‌کنن. شخص (یا گروه) حمله کننده، با انجام یک حمله MITM (man-in-the-middle) و جعل هویت سرور، خودش رو به عنوان سرور جا میده و کلاینت رو وادار به توافق روی پروتکل SSL 3.0 می‌کنه.

حمله BEAST (Browser Exploit Against SSL/TLS):

این حمله که در سپتامبر ۲۰۱۱ منتشر شد، مربوط به SSL 3.0 و TLS 1.0 میشه و مرورگرهایی رو هدف قراره میده که از TLS 1.0 یا ورژن‌های قدیمی‌تر پشتیبانی می‌کنن.

این حمله از حملات سمت کلاینت هست. حمله کننده از تکنیک MITM (man-in-the-middle) استفاده میکنه و پک‌هایی رو به جریان اطلاعات در TLS تزریق میکنه و از این طریق اقدام به حدس بردارهای اولیه (Initialization Vectors) میکنن و به این ترتیب شروع به رمزگشایی اطلاعات از اولین بلوک اطلاعات میکنه. لازم به ذکره که برای انجام این حمله، نیاز هست که حمله کننده کنترل نسبی روی مرورگر هدف داشته باشه.

حمله Heartbleed:

یکی از حملات حیاتی بود که علیه پروتکل TLS کشف شد. این حمله افزونه heartbeat که در کتابخانه معروف OpenSSL هست رو هدف قرار میده. افزونه heartbeat این امکان رو فراهم میکرد که ارتباط کلاینت-سرور رو تا زمانی که هر دوشون حاضر هستن، حفظ شه. مبنای کار این افزونه اینطور بود که طول اطلاعات ارسالی از سمت سرور باید با طول اطلاعات دریافتی از کلاینت برابر می‌بود. حمله کننده با اجرای تکنیک MITM (man-in-the-middle)، اطلاعات با طول غلط از سمت کلاینت برای سرور ارسال می‌کنه و سرور برای اینکه پاسخ با طول برابر به کلاینت برگردونه، مقادیر دیگه‌ای که در حافظه‌اش وجود داره رو به انتهای پیام خودش اضافه می‌کرد. و این مقادیر که اضافه میشن می‌تونن اطلاعات حساسی مثل اطلاعات حساب بانکی یا اطلاعات حساب کاربری باشن. این حمله میتونه بعضا منجر شه که حمله کننده به کلید رمزگشایی سرور دسترسی پیدا کنه و از این طریق به کلیه اطلاعات موجود در سرور دسترسی پیدا کنه.

برای جمع‌بندی این بخش، بهترین توصیه این هست که اطمینان حاصل کنید همیشه ورژن‌های قدیمی‌تر SSL/TLS رو غیرفعال کردید.

منابع:

https://www.acunetix.com/blog/articles/tls-security-what-is-tls-ssl-part-1
https://www.acunetix.com/blog/articles/history-of-tls-ssl-part-2
https://www.acunetix.com/blog/articles/tls-ssl-terminology-basics-part-3
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5
https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part
https://en.wikipedia.org/wiki/Cipher_suite