TLSعملکرد مشاهده در قالب PDF چاپ فرستادن به ایمیل
نوشته شده توسط حمیدرضا نبی زاده   
یکشنبه, 02 مرداد 1401 ساعت 10:54

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

 

TLS چیست؟

 

TLS یک پروتکل رمزنگاری است که امنیت داده‌های ارسال شده بین برنامه‌های کاربردی را از طریق اینترنت فراهم می‌کند. بیشتر از طریق استفاده از آن در مرور وب ایمن، و به ویژه نماد قفل که در مرورگرهای وب هنگام برقراری یک جلسه امن ظاهر می شود، برای کاربران آشنا است. با این حال، می‌تواند و در واقع باید برای برنامه‌های کاربردی دیگری مانند ایمیل، انتقال فایل، کنفرانس ویدیویی/صوتی، پیام‌رسانی فوری و انتقال صوتی از طریق IP، و همچنین خدمات اینترنتی مانند DNS و NTP استفاده شود.

 

TLS از لایه های سوکت ایمن (SSL) که در ابتدا توسط Netscape Communications Corporation در سال 1994 برای ایمن سازی جلسات وب توسعه داده شد، تکامل یافته است. SSL 1.0 هرگز به صورت عمومی منتشر نشد، در حالی که SSL 2.0 به سرعت با SSL 3.0 که TLS بر اساس آن است جایگزین شد.

 

TLS برای اولین بار در RFC 2246 در سال 1999 به عنوان یک پروتکل مستقل از برنامه ها مشخص شد، و در حالی که به طور مستقیم با SSL 3.0 قابل همکاری نبود، در صورت لزوم یک حالت بازگشتی را ارائه داد. با این حال، SSL 3.0 اکنون ناامن در نظر گرفته می‌شود و توسط RFC 7568 در ژوئن 2015 منسوخ شد، با این توصیه که باید از TLS 1.2 استفاده شود. TLS 1.3 نیز در حال حاضر (از دسامبر 2015) در دست توسعه است و پشتیبانی از الگوریتم‌های کمتر امن را متوقف خواهد کرد.

 

لازم به ذکر است که TLS داده ها را در سیستم های نهایی ایمن نمی کند. این به سادگی تحویل امن داده ها را از طریق اینترنت تضمین می کند و از استراق سمع احتمالی و/یا تغییر محتوا جلوگیری می کند.

 

TLS معمولاً در بالای TCP به منظور رمزگذاری پروتکل‌های لایه برنامه مانند HTTP، FTP، SMTP و IMAP پیاده‌سازی می‌شود، اگرچه می‌توان آن را روی UDP، DCCP و SCTP نیز پیاده‌سازی کرد (به عنوان مثال برای استفاده‌های کاربردی مبتنی بر VPN و SIP) . این به عنوان امنیت لایه انتقال داده‌گرام (DTLS) شناخته می‌شود و در RFCهای 6347، 5238 و 6083 مشخص شده است.

چرا باید به TLS اهمیت بدهم؟

 

داده‌ها در طول تاریخ به صورت رمزگذاری نشده از طریق اینترنت منتقل می‌شوند، و در جایی که از رمزگذاری استفاده می‌شد، معمولاً به صورت تکه‌ای برای اطلاعات حساس مانند رمز عبور یا جزئیات پرداخت استفاده می‌شد. در حالی که در سال 1996 (توسط RFC 1984) به رسمیت شناخته شد که رشد اینترنت مستلزم حفاظت از داده های خصوصی است، در طول دوره میانی به طور فزاینده ای آشکار شده است که توانایی های استراق سمع و مهاجمان بیشتر و فراگیرتر از آنچه قبلا تصور می شد است. . بنابراین IAB در نوامبر 2014 بیانیه‌ای منتشر کرد و از طراحان، توسعه‌دهندگان و اپراتورهای پروتکل خواست تا رمزگذاری را برای ترافیک اینترنت عادی کنند، که اساساً به معنای محرمانه کردن آن به طور پیش‌فرض است.

 

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

 

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

 

بنابراین توصیه می شود که همه مشتریان و سرورها بر استفاده اجباری از TLS در ارتباطات خود و ترجیحاً جدیدترین نسخه TLS 1.2 اصرار داشته باشند. برای امنیت کامل، لازم است از آن همراه با زیرساخت کلید عمومی X.509 (PKI) مورد اعتماد عمومی و ترجیحاً DNSSEC نیز استفاده شود تا تأیید شود که سیستمی که اتصال به آن برقرار می شود واقعاً همان چیزی است که ادعا می کند. بودن.

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

 

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

 

با رمزنگاری متقارن، داده ها با یک کلید مخفی که برای فرستنده و گیرنده شناخته شده است، رمزگذاری و رمزگشایی می شود. معمولاً 128 اما ترجیحاً 256 بیت طول دارد (هر چیزی کمتر از 80 بیت اکنون ناامن در نظر گرفته می شود). رمزنگاری متقارن از نظر محاسبات کارآمد است، اما داشتن یک کلید مخفی مشترک به این معنی است که باید به شیوه ای امن به اشتراک گذاشته شود.

 

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

 

مزیت رمزنگاری نامتقارن این است که فرآیند به اشتراک گذاری کلیدهای رمزگذاری نباید ایمن باشد، اما رابطه ریاضی بین کلیدهای عمومی و خصوصی به این معنی است که اندازه کلیدهای بزرگتر مورد نیاز است. حداقل طول کلید توصیه شده 1024 بیت است و 2048 بیت ترجیح داده می شود، اما این مقدار از نظر محاسباتی تا هزار برابر بیشتر از کلیدهای متقارن با قدرت معادل است (به عنوان مثال، یک کلید نامتقارن 2048 بیتی تقریباً معادل یک کلید متقارن 112 بیتی است) و رمزگذاری نامتقارن را برای بسیاری از اهداف بسیار کند می کند.

انواع مختلفی از روش‌های مختلف تولید و مبادله کلید، از جمله RSA، Diffie-Hellman (DH)، Ephemeral Diffie-Hellman (DHE)، منحنی بیضوی Diffie-Hellman (ECDH) و Ephemeral Eliptic Curve Diffie-Hellman (ECDHE) قابل استفاده است. DHE و ECDHE همچنین محرمانه‌ای را ارائه می‌دهند که به موجب آن در صورت به دست آوردن یکی از کلیدهای خصوصی در آینده، کلید جلسه به خطر نمی‌افتد، اگرچه تولید اعداد تصادفی ضعیف و/یا استفاده از محدوده محدودی از اعداد اول فرض شده است که امکان شکستن را فراهم می‌کند. حتی کلیدهای 1024 بیتی DH با توجه به منابع محاسباتی سطح دولتی. با این حال، ممکن است این موارد به جای مسائل پروتکل، پیاده سازی در نظر گرفته شوند، و ابزارهایی برای آزمایش مجموعه های رمز ضعیف تر وجود دارد.

 

با TLS همچنین مطلوب است که کلاینت متصل به سرور بتواند مالکیت کلید عمومی سرور را تأیید کند. این معمولاً با استفاده از یک گواهی دیجیتال X.509 صادر شده توسط یک شخص ثالث قابل اعتماد معروف به مرجع صدور گواهی (CA) انجام می شود که صحت کلید عمومی را تأیید می کند. در برخی موارد، سرور ممکن است از گواهی خودامضا شده استفاده کند که باید صریحاً مورد اعتماد مشتری باشد (مرورگرها باید هشداری را در صورت مواجه شدن با گواهی نامعتبر نشان دهند)، اما این ممکن است در شبکه‌های خصوصی و/یا جایی که گواهی امن قابل قبول باشد. توزیع امکان پذیر است. با این حال، استفاده از گواهینامه های صادر شده توسط CAهای مورد اعتماد عمومی بسیار توصیه می شود.

 

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

 

انواع مختلفی از روش‌های مختلف تولید و مبادله کلید، از جمله RSA، Diffie-Hellman (DH)، Ephemeral Diffie-Hellman (DHE)، منحنی بیضوی Diffie-Hellman (ECDH) و Ephemeral Eliptic Curve Diffie-Hellman (ECDHE) قابل استفاده است. DHE و ECDHE همچنین محرمانه‌ای را ارائه می‌دهند که به موجب آن در صورت به دست آوردن یکی از کلیدهای خصوصی در آینده، کلید جلسه به خطر نمی‌افتد، اگرچه تولید اعداد تصادفی ضعیف و/یا استفاده از محدوده محدودی از اعداد اول فرض شده است که امکان شکستن را فراهم می‌کند. حتی کلیدهای 1024 بیتی DH با توجه به منابع محاسباتی سطح دولتی. با این حال، ممکن است این موارد به جای مسائل پروتکل، پیاده سازی در نظر گرفته شوند، و ابزارهایی برای آزمایش مجموعه های رمز ضعیف تر وجود دارد.

 

با TLS همچنین مطلوب است که کلاینت متصل به سرور بتواند مالکیت کلید عمومی سرور را تأیید کند. این معمولاً با استفاده از یک گواهی دیجیتال X.509 صادر شده توسط یک شخص ثالث قابل اعتماد معروف به مرجع صدور گواهی (CA) انجام می شود که صحت کلید عمومی را تأیید می کند. در برخی موارد، سرور ممکن است از گواهی خودامضا شده استفاده کند که باید صریحاً مورد اعتماد مشتری باشد (مرورگرها باید هشداری را در صورت مواجه شدن با گواهی نامعتبر نشان دهند)، اما این ممکن است در شبکه‌های خصوصی و/یا جایی که گواهی امن قابل قبول باشد. توزیع امکان پذیر است. با این حال، استفاده از گواهینامه های صادر شده توسط CAهای مورد اعتماد عمومی بسیار توصیه می شود.

یکی از ضعف‌های سیستم X.509 PKI این است که اشخاص ثالث (CAs) می‌توانند برای هر دامنه گواهی صادر کنند، خواه نهاد درخواست‌کننده واقعاً مالک آن باشد یا در غیر این صورت آن را کنترل کند. اعتبار سنجی معمولاً از طریق اعتبارسنجی دامنه انجام می شود - یعنی ارسال یک ایمیل با پیوند احراز هویت به آدرسی که از نظر اداری مسئول دامنه است. این معمولاً یکی از آدرس‌های تماس استاندارد مانند 'hostmaster@domain' یا مخاطب فنی فهرست شده در پایگاه داده WHOIS است، اما این خود را برای حملات انسان در میان بر روی پروتکل‌های DNS یا BGP یا ساده‌تر باز می‌گذارد. کاربرانی که آدرس های اداری را در دامنه هایی که رزرو نشده اند ثبت می کنند. شاید مهمتر از آن، گواهینامه های معتبر دامنه (DV) ادعا نمی کنند که یک دامنه با یک شخص حقوقی ارتباط دارد، حتی اگر یک دامنه ممکن است به نظر برسد.

 

به همین دلیل، CA ها به طور فزاینده ای استفاده از گواهی های معتبر سازمانی (OV) و اعتبار سنجی توسعه یافته (EV) را تشویق می کنند. با گواهی OV، نهاد درخواست کننده تحت بررسی های اضافی مانند تایید نام سازمان، آدرس و شماره تلفن با استفاده از پایگاه های داده عمومی قرار می گیرد. با گواهینامه های EV، بررسی های اضافی در مورد استقرار قانونی، مکان فیزیکی، و هویت افرادی که مدعی عمل از طرف نهاد درخواست کننده هستند، وجود دارد. مرورگرها معمولاً زمانی که با گواهی نامه EV معتبر مواجه می شوند، نام سازمان معتبر را به رنگ سبز نشان می دهند، اگرچه متأسفانه هیچ راه آسانی برای تشخیص OV از گواهی DV وجود ندارد.

 

البته، این هنوز مانع از صدور تصادفی یا تقلبی گواهی‌های نادرست توسط CA نمی‌شود، و همچنین مواردی از نقض امنیت رخ داده است که در آن CAها فریب خورده‌اند تا گواهی‌های جعلی صادر کنند. علیرغم تشدید قابل توجه رویه‌های امنیتی در پی چندین رویداد پرمخاطب، سیستم همچنان به اعتماد شخص ثالث متکی است که منجر به توسعه پروتکل تأیید هویت نهادهای نام‌گذاری شده مبتنی بر DNS (DANE) همانطور که در RFCs 6698 مشخص شده است، شده است. 7671، 7672 و 7673.

 

با DANE، یک مدیر دامنه می تواند کلیدهای عمومی خود را با ذخیره آنها در DNS تأیید کند، یا به طور متناوب مشخص کند که کدام گواهینامه ها باید توسط یک کلاینت پذیرفته شوند. این امر مستلزم استفاده از DNSSEC است که به صورت رمزنگاری اعتبار رکوردهای DNS را تأیید می کند، اگرچه DNSSEC هنوز گسترش گسترده ای ندارد و مرورگرهای اصلی در حال حاضر برای پشتیبانی از DANE به نصب افزونه نیاز دارند. علاوه بر این، DNSSEC و DANE همچنان به اعتبارسنجی دارندگان دامنه نیاز دارند که احتمالاً باید به جای CA توسط رجیستری‌ها و/یا ثبت‌کنندگان دامنه انجام شود.




 

اخبار و رویدادها

با ما باشید.

در باره ما

در باره ما

آخرین نظرات

آخرین نظرات

آدرس

آدرس