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

Transport Layer Security (TLS) یکی از مهمترین و به طور گسترده مورد استفاده پروتکل های امنیتی است. این از بخش قابل توجهی از داده هایی که بصورت آنلاین منتقل می شوند محافظت می کند. برجسته ترین است استفاده می شود برای اطمینان از داده های سفر بین یک مرورگر وب و وب سایت از طریق HTTPS, اما همچنین می تواند برای ایمن سازی ایمیل و تعداد زیادی پروتکل دیگر مورد استفاده قرار گیرد.

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

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

TLS چه کاری انجام می دهد?

هنگام ارسال اطلاعات به صورت آنلاین ، ما به سه مشکل امنیتی اصلی رسیدگی می کنیم:

• چگونه می توانیم بدانیم که آیا شخصی که با آنها ارتباط برقرار می کنیم واقعاً همان کسی است که می گوید آنها هستند?
• چگونه می توانیم بدانیم که داده ها از زمان ارسال آنها دستکاری نشده است?
• چگونه می توانیم دیگران را از دیدن و دسترسی به داده ها جلوگیری کنیم?

این موضوعات بسیار مهم هستند ، به ویژه هنگامی که ما اطلاعات حساس یا ارزشمندی را ارسال می کنیم. TLS از طیف وسیعی از تکنیک های رمزنگاری برای رفع هر یک از این سه مشکل استفاده می کند. با هم ، آنها به پروتکل اجازه می دهند طرف مقابل را در یک ارتباط تأیید کنید ، یکپارچگی داده ها را بررسی کرده و از آن محافظت شده رمزگذاری کنید.

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

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

TLS با استفاده از چندین فرآیند مختلف این نیازها را برآورده می کند. این با آنچه که به عنوان a شناخته می شود شروع می شود لرزش دست TLS, که در آن محل تأیید اعتبار است و کلیدها تعیین می شوند.

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

اگر مرحله نامه شما حاوی نیمی از یک شماره پین ​​باشد که قصد دارید در ارتباطات آینده از آنها استفاده کنید ، مرحله تأسیس کلیدی کمی شبیه خواهد بود. شما از گیرنده خود می خواهید که در نیمه دوم شماره آمده و در نامه برگشت آنها برای شما ارسال کند.

هنگامی که پیک هویت را تأیید کرده و شماره پین ​​را تعیین کرده بود ، برای ارسال ایمن اطلاعات ، همه موارد لازم را خواهید داشت. در واقعیت ، این مراحل بسیار پیچیده تر است ، اما بعداً به آن خواهیم رسید.

TLS با پروتکل برنامه اطلاعات را با خیال راحت تبادل می کند. برای انجام قیاس ما ، انتقال ایمن داده ها از طریق TLS ، مانند نوشتن پیام و قرار دادن آن در پاکت است. شما امضاء خود را بر روی مهر می نوشتید ، به گونه ای که اگر نامه دستخوش تغییر شود ، گیرنده شما می تواند با امضای پاره شده بگوید (این در واقع با ریاضی انجام می شود ، اما دوباره ، ما بعداً آن را عمیقا پوشش خواهیم داد).

سپس نامه را درون یک جعبه فلزی کوچک قرار می دهید که دارای قفل ترکیبی است و این ترکیب را به عنوان شماره پین ​​که مشترکاً با گیرنده خود تعیین کرده اید تعیین می کند. شما جعبه را از طریق پیک ارسال می کنید که هنگام تحویل بسته ها ، شناسایی را بررسی می کند. گیرنده شما به همان روش پاسخ می دهد ، و هرگونه ارتباطات بعدی همان مراحل را دنبال می کند.

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

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

TLS در مقابل SSL

هنگام مطالعه در مورد TLS ، اغلب ذکر SSL یا حتی TLS / SSL را مشاهده خواهید کرد. Secure Sockets Layer (SSL) نسخه قدیمی TLS است ، اما بسیاری از این صنعت هنوز تحت عنوان قدیمی به TLS مراجعه می کنند. در این مقاله از اصطلاح TLS در سراسر استفاده خواهد شد ، اما توجه به این نکته ضروری است که نامها اغلب بصورت متقابل استفاده می شوند. می توانید اطلاعات بیشتری در مورد SSL در راهنمای ما بخوانید.

تاریخچه TLS

همه اینها با نیاز به تأمین لایه حمل و نقل آغاز شد. همانطور که در بالا ذکر شد ، پیشرو TLS SSL بود. اولین نسخه های SSL در دهه نود توسط Netscape ساخته شد ، شرکتی که یکی از مرورگرهای اولیه وب را ساخت..

SSL 1.0 به دلیل اینکه دارای آسیب پذیری های جدی بود هرگز منتشر نشد. نسخه 2.0 با Netscape Navigator 1.1 در 1995 منتشر شد, با این حال هنوز هم تعدادی نقص جدی را در بر داشت. SSL 3.0 یک نسخه جدید طراحی مجدد بود و در سال 1996 منتشر شد که بسیاری از مسائل امنیتی برطرف شد.

در سال 1996, IETF پیش نویس SSL 3.0 را در RFC 6101 منتشر کرد. IETF یک کارگروه برای استاندارد سازی SSL تشکیل داد و نتایج را در سال 1999 با عنوان TLS 1.0 منتشر کرد. در RFC 2246 ثبت شد و استانداردسازی شامل برخی از تغییرات در پروتکل اصلی و همچنین تغییر نام بود. این تغییرات در نتیجه مذاکرات بین نت نت و مایکروسافت و گروه کاری IETF به وجود آمد.

در سال 2006 ، IETF RFC 4346 را منتشر کرد که TLS 1.1 را اسناد می کند. این نسخه حاوی مقررات امنیتی جدید و تعدادی بروزرسانی دیگر است. نسخه 1.2 فقط دو سال بعد در سال 2008 منتشر شد. این شامل پشتیبانی از رمزگذاری های رمزگذاری شده معتبر ، تعدادی از تغییر در نحوه استفاده از توابع هش و بسیاری از پیشرفت های دیگر.

نسخه بعدی تا سال [year] ، وقتی TLS 1.3 تعریف شد ، وارد بازار نمی شود. این برنامه دارای تعداد زیادی تغییرات است ، از جمله محرمانه بودن رو به جلو ، حذف پشتیبانی از الگوریتم های ضعیف تر و موارد دیگر.

TLS 1.0 و 1.1 اکنون در سال [year] مستهلک می شوند ، اما نسخه 1.2 در کاربرد گسترده ای قرار دارد. نسخه 1.3 شروع به افزایش پذیرش می کند.

TLS: جزئیات فنی

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

نمودار نشانگر پشته TLS. پشته پروتکل TLS توسط Jeffreytedjosukmono. تحت مجوز CC0 دارای مجوز است.

پروتکل ضبط شامل پنج زیر پروتوکل جداگانه است که هر یک به صورت فرمت شده است سوابق:

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

هر یک از این زیر پروتوکل ها در مراحل مختلف برای ارتباط با اطلاعات مختلف استفاده می شوند. مهمترین مواردی که می توان در دستیابی به آنها و پروتکل های برنامه استفاده کرد ، زیرا این وظیفه برقراری اتصال و سپس انتقال ایمن داده ها است.

پروتکل دستی TLS

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

سه نوع اساسی از دستی TLS وجود دارد: دستی اولیه TLS, دست زدن به TLS تأیید شده توسط مشتری و دست زدن به طور خلاصه.

دستی اولیه TLS

نمودار نشانگر روند دستکاری TLS. دستی کامل TLS 1.2 توسط FleshGrinder. تحت مجوز CC0 دارای مجوز است.

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

پیام Client Hello با یک متن ملاقات شده است سلام سرور پیام این پاسخ شامل شناسه جلسه ، نسخه پروتکل ، مجموعه رمزگذاری شده و فشرده سازی (در صورت استفاده از آن) است که سرور انتخاب شده از لیست مشتری. همچنین شامل یک عدد تصادفی متفاوت است.

این بستگی به مجموعه رمزنگاری انتخاب شده دارد ، اما سرور با ارسال a به طور کلی این موضوع را دنبال می کند گواهی پیام برای تأیید اعتبار. این هویت آن را تأیید می کند و حاوی کلید عمومی آن است.

اگر تبادل کلید زودگذر Diffie-Hellman یا ناشناس Diffie-Hellman استفاده می شود ، پس از آن تبادل کلید سرور پیام سایر روش های مبادله کلید این قسمت را پرش می کنند. هنگامی که سرور با سمت خود از مذاکره به پایان رسید ، ارسال می کند سرور سلام انجام شد پیام.

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

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

مشتری سپس ارسال می کند مشخصات رمز را تغییر دهید پیام این به سرور می گوید که پیام های زیر اکنون تأیید و رمزگذاری می شوند (گرچه بعضی اوقات ممکن است از رمزگذاری استفاده نشود).

مشتری سپس این مورد را با یک مورد دنبال می کند تمام شده پیام ، رمزگذاری شده و همچنین دارای کد تأیید اعتبار پیام (MAC) برای تأیید اعتبار است. سرور این پیام را رمزگشایی می کند و MAC را تأیید می کند. اگر هر یک از این فرایندها شکست بخورند ، باید ارتباط رد شود.

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

دستی TLS با تأیید اعتبار مشتری

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

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

دستکاری TLS مخفف

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

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

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

اگر سرور شناسه جلسه را تشخیص دهد ، پس از آن گواهی و تبادل کلید مراحل را می توان رد کرد. مشخصات رمز را تغییر دهید و تمام شده پیام ها به همان روشی که دستی اولیه TLS در بالا نشان داده شده است ، ارسال می شوند. هنگامی که مشتری پیام را رمزگشایی کرده و MAC را تأیید کرد ، داده ها می توانند از طریق اتصال TLS امن ارسال شوند.

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

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

در حال باز کردن دستگیره TLS

سه مرحله مهم از دست دادن شامل موارد زیر است:

• پارامترها انتخاب شده اند,
• این کار احراز هویت را انجام می دهد ، و
• کلیدها تنظیم شده اند.

بیایید آنها را با جزئیات بیشتری پوشش دهیم تا بتوانید درک کنید که واقعاً چه خبر است.

پارامترها

در شروع دستیابی ، مشتری و سرور با توافق متقابل ، پارامترهای اتصال را مذاکره می کنند. اولین مورد از این نسخههاست که از نسخه TLS استفاده خواهد شد. این بالاترین نسخه ای است که هر دو طرف از آن پشتیبانی می کنند ، و به نظر می رسد بیشترین امنیت را داشته باشد.

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

احراز هویت: گواهی های دیجیتال

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

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

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

یادداشت در مورد کلیدهای عمومی

رمزگذاری کلید عمومی (همچنین به عنوان رمزگذاری نامتقارن نیز شناخته می شود) بخش مهمی از رمزنگاری است و در جنبه های مختلف TLS کاربرد گسترده ای دارد. در اینجا یک آغازگر سریع برای کسانی که با نحوه کارشان ناآشنا هستند وجود دارد.

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

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

ایجاد یک راز استاد

همانطور که در بالا دیدیم وقتی درباره روند دستیابی اساسی TLS صحبت کردیم ، بعد از اینکه یک طرف (یا هر دو طرف) هویت خود را با گواهی عمومی خود اثبات کرد, قدم بعدی ایجاد راز استاد است که به عنوان راز مشترک نیز شناخته می شود. Master secret پایه ای برای بدست آوردن کلیدهایی است که برای رمزگذاری و بررسی صحت اطلاعات منتقل شده بین دو طرف استفاده می شود.

دستی TLS می تواند از تعدادی مکانیزم مختلف برای به اشتراک گذاشتن ایمن این راز استفاده کند. این موارد شامل RSA ، چندین نوع مختلف تبادل کلید Diffie-Hellman ، PSK ، Kerberos و موارد دیگر است. هرکدام مزایا و معایب خاص خود را دارند ، مانند تهیه راز رو به جلو ، اما این اختلافات خارج از محدوده این مقاله است.

فرآیند دقیق بستگی به این دارد که کدام روش تبادل کلیدی انتخاب شده باشد ، اما مراحل خشن ذکر شده در آن را دنبال می کند دستی اولیه TLS بخش.

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

مشتری و سرور سپس هر دو از رمزهای مربوط به پیش نویس و شماره های تصادفی که در ابتدای ارتباط برای آنها ارسال کرده اند استفاده می کنند تا از راز استاد مطلع شوند. پس از محاسبه کلید اصلی ، از چهار یا شش کلید جداگانه استفاده می شود. اینها هستند:

• کلید ارسال کلید MAC – این کلید توسط سرور برای بررسی صحت داده های ارسال شده توسط مشتری استفاده می شود.
• سرور کلید MAC را بنویسید – سرور نوشتن کلید MAC توسط مشتری برای بررسی صحت اطلاعاتی که توسط سرور ارسال شده است ، استفاده می شود.
• کلید رمزگذاری نوشتن مشتری – سرور از این کلید برای رمزگذاری داده های ارسال شده توسط مشتری استفاده می کند.
• کلید رمزگذاری نوشتن سرور – مشتری از این کلید برای رمزگذاری داده های ارسال شده توسط سرور استفاده می کند.
• کلید نوشتن IV – کلید نوشتن مشتری توسط سرور در رمزگذاری های AEAD استفاده می شود ، اما در زمان استفاده از سایر الگوریتم های تبادل کلید.
• کلید سرور نوشتن IV – به طور مشابه ، این کلید توسط مشتری در رمزگذاری AEAD استفاده می شود ، اما در هنگام استفاده از سایر الگوریتم های تبادل کلید.

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

پس از به دست آوردن کلیدهای تأیید اعتبار و رمزگذاری ، از آنها برای محافظت از هر دو استفاده می شود تمام شده پیام ها ، و همچنین سوابق ارسال شده از طریق پروتکل برنامه.

پروتکل برنامه

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

الگوریتم های تأیید اعتبار

تمامیت پیام ها را می توان با بسیاری از الگوریتم های مختلف بررسی کرد. این شامل:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

برای اثبات یکپارچگی داده های ارسال شده ، فرستنده اطلاعات را با استفاده از یک عملکرد هش اجرا می کند تا یک رشته منحصر به فرد از کاراکترها را برگرداند. این فرمول های ویژه ای هستند که هر زمان که همان ورودی را دریافت کنند ، همان نتیجه را به دست می آورند.

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

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

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

الگوریتم های رمزگذاری

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

TLS می تواند از بسیاری از الگوریتم های مختلف مانند کاملیا یا ARIA استفاده کند ، اگرچه محبوب ترین AES است.

فشرده سازی

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

لایه گذاری

Padding قبل از رمزگذاری اطلاعات اضافی را به پیام اضافه می کند. این یک فرایند رمزنگاری متداول است که برای کمک به جلوگیری از نکات در ساختار داده های رمزگذاری شده معنی واقعی آن را نشان نمی دهد. TLS معمولاً قبل از رمزگذاری ، padding PKCS # 7 را روی پرونده ها اعمال می کند.

پروتکل هشدار

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

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

TLS & مدل OSI

مدل OSI روشی برای مفهوم سازی و استاندارد سازی نحوه نگاه ما به سیستم ها و پروتکل های مختلف ارتباطی است. توجه داشته باشید که این فقط یک مدل است ، و برخی از پروتکل های ما مطابق با آن نیستند.

OSI دارای هفت لایه جداگانه است که سطحهایی را که پروتکلها در آن کار می کنند نشان می دهد, TLS به هیچ وجه متناسب نیست. این پروتکل حمل و نقل دیگری مانند TCP جریان دارد ، که باید حاکی از آن باشد که بالاتر از لایه چهارم یعنی لایه حمل و نقل است. این برجسته ترین مانند یک لایه حمل و نقل استفاده می شود ، اما به دلیل اینکه لرزش هایی را انجام می دهد ، این نشان می دهد که بخشی از لایه های ارائه یا برنامه است.

همانطور که مشاهده می کنید ، TLS به سادگی با مدل OSI مطابقت ندارد. این بدان معنا نیست که TLS خراب است یا اشتباه است ، در هر صورت ، این فقط نشان می دهد که مدل OSI دارای نقص است و قادر به حساب همه پروتکل های ارتباطی ما نیست.

استفاده از TLS

TLS برای تأمین بخش قابل توجهی از ارتباطات آنلاین ما استفاده می شود. به طور معمول این پروتکل ها مانند پروتکل های مشابه اجرا می شوند پروتکل کنترل انتقال (TCP), اما می تواند در پروتکل کنترل تراکم Datagram (DCCP) و پروتکل Datagram User (UDP) نیز استفاده شود.

این پروتکل می تواند پروتکل هایی مانند HTTP ، SMTP ، FTP ، XMPP و NNTP را ایمن کند, و همچنین دیگران متداول ترین برنامه به عنوان Hypertext Transfer Protocol Secure (HTTPS) است که از اتصال بین یک مرورگر وب و یک وب سایت محافظت می کند. می توانید بگویید چه زمانی از HTTPS برای تأمین اتصال آنلاین خود استفاده می شود ، زیرا یک نماد قفل سبز کوچک در سمت چپ URL در بالای مرورگر شما ظاهر می شود.

TLS همچنین می تواند برای ساخت VPN استفاده شود, مانند OpenConnect و OpenVPN. از قابلیت رمزگذاری و احراز هویت خود برای ایجاد تونلی استفاده می کند که می تواند میزبان ها و شبکه ها را به یکدیگر متصل کند. فناوری های VPN مبتنی بر TLS مانند OpenVPN نسبت به گزینه های دیگری مانند IPsec سودمند هستند ، زیرا شناخته شده نیست که OpenVPN دارای مشکلات امنیتی جدی است. این VPN ها همچنین می توانند پیکربندی ساده تر شوند.

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

مسائل امنیتی TLS

TLS مانند اکثر پروتکل ها ، آسیب پذیری های گذشته و حملات نظری را در برابر پیاده سازی های مختلف خود داشته است. با وجود این, آخرین نسخه ها برای اهداف عملی ایمن در نظر گرفته می شوند.

نسخه های گذشته ، مانند SSL 2.0 و 3.0 (و TLS 1.0 ، که در اصل برابر با SSL 3.0 است) دارای نقص امنیتی زیادی هستند ، اما از آنجا که این پروتکل های قدیمی و مستهلک هستند ، ما به جزئیات نمی پردازیم. شما باید از TLS 1.2 و 1.3 استفاده کنید تا به جای آن اتصالات خود را ایمن کنید.

نسخه های جدیدتر TLS دارای به روز رسانی های بیشماری است که باعث می شود نسبت به SSL آسیب پذیر نباشند. با وجود این ، پروتکل هنوز دارای موضوعات امنیتی زیر است:

حملات مذاکره

یکی از ویژگی های TLS این است که به جفت های سرویس دهنده و سرور این امکان را می دهد تا پارامترهای اتصال موجود خود را مجدداً مورد استفاده قرار دهند. در سال 2009 ، کشف شد که این می تواند توسط مهاجمان مورد سوء استفاده قرار بگیرد تا بتوانند ترافیک را تزریق کنند تا ظاهراً از طرف مشتری بدست آید. سرورها درخواست را به عنوان مشروعیت پذیرفتند ، به این معنی که مهاجمان به طور بالقوه می توانند پیامهای خروجی را دستکاری کنند.

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

BEAST

حمله مرورگر علیه SSL / TLS (BEAST) برای اولین بار توسط محققان در سال 2011 کشف شد. این حمله فقط روی TLS 1.0 تأثیر می گذارد ، که نسخه قدیمی و ضعیف تر پروتکل است. اگرچه تا سال [year] مستهلک نخواهد شد ، اما کاربران باید به جای آن از نسخه های 1.2 و 1.3 استفاده کنند.

زمان حملات

این حملات کانال جانبی تجزیه و تحلیل می کنند که مدت زمان اجرای الگوریتم چقدر طول می کشد ، سپس از آن اطلاعات برای کار به عقب و مشخص کردن کلید استفاده می کنید. در سال 2013 ، حمله بدشانسی سیزده کشف شد تا در زمان بررسی کد تأیید صحت پیام (MAC) ، به حمله زمانبندی و حمله اوراکل لمسی بپردازد. این حمله می تواند برای شکستن الگوریتم TLS استفاده شود ، اگرچه برای اکثر کاربران TLS خطرناک تلقی نمی شود.

جرم & رخنه

حمله CRIME در برابر طیف وسیعی از پروتکل ها کار می کند. وقتی داده فشرده شد ، می تواند محتوای کوکی های تأیید اعتبار را استخراج کند. از این اطلاعات می توان برای ربودن جلسه استفاده کرد. در حالی که بر تعدادی از پروتکل ها تأثیر می گذارد ، هنگام استفاده از فشرده سازی HTTP ، حمله به ویژه نگران کننده است ، زیرا هیچ راهکاری برای کاهش موثر وجود ندارد.

در سال 2013 ، بازبینی مرورگر و استخراج از طریق فشرده سازی سازگار با استفاده از Hypertext (BREACH) با استفاده از فشرده سازی HTTP به روشی مشابه تحت تأثیر قرار گرفت. این نسخه از حمله می تواند آدرس های ایمیل و سایر داده های ارزشمندی را که با TLS رمزگذاری شده است بازیابی کند. حمله BREACH با غیرفعال کردن فشرده سازی HTTP یا استفاده از تکنیک هایی مانند محافظت از درخواست جعلی (CSRF) از طریق سایت ، می تواند کاهش یابد..

حملات تخریب

اینها حمله هایی هستند که سرورها را برای استفاده از نسخه های اولیه و کمتر ایمن TLS ترفند می کنند. مهاجمان می توانند از این تکنیک ها برای مذاکره در مورد استفاده از مبادلات و رمزگذاری کلیدهای با امنیت کمتر استفاده کنند. حمله Logjam یک مثال خوب است زیرا می تواند باعث شود سرورهای آسیب پذیر از 512 بیتی Diffie-Hellman استفاده کنند ، که ضعیف است. سپس مهاجمان می توانند این مکانیسم تبادل کلید را بشکنند و کلیدها را استخراج کنند و به آنها امکان دسترسی کامل به جلسه را می دهد.

دلچسب

Heartbleed یک نقص امنیتی بود که به طور اتفاقی در سال 2012 وارد کتابخانه رمزنگاری OpenSSL شد, اما تا سال 2014 منتشر نشده است. از آنجا که این روش معمولاً از TLS استفاده می شود ، باعث خسارت قابل توجهی در جهان شد.

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

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

افتاد

حمله Decrypting RSA با حمله eNcryption Obsolete و Weakened eNcryption (DROWN) در سال 2016 اعلام شد و از پشتیبانی سرور برای SSL 2.0 بهره می برد. با استفاده از یک حمله متن رمز شده علیه سرورهایی که هنوز از SSL 2.0 پشتیبانی می کنند ، و همچنین کسانی که همان گواهی کلید عمومی را با سرور دیگری که SSL 2.0 را پشتیبانی می کند مشترک هستند..

هنگامی که این حمله اعلام شد ، می توانست با هزینه های اولیه راه اندازی در حدود 18000 دلار و برای هر حمله جداگانه 400 دلار انجام شود. هنگامی که حمله DROWN موفقیت آمیز باشد ، کلیدهای جلسه را به دست می آورد.

با به اشتراک گذاشتن گواهینامه های سرور ، حمله قابل کاهش است. گروه OpenSSL همچنین تکه هایی را منتشر کرده است که پشتیبانی از پروتکل ها و رمزگذاری های قدیمی را حذف می کند ، اما این تنها در صورتی کار می کند که گواهی سرور با سایر سرورهایی که SSL 2.0 را پشتیبانی می کنند به اشتراک گذاشته نشود..

PAC غیرمجاز

این حمله در سال 2016 یافت شد. این ضعف را ضعیف در پروتکل Autodiscovery Web Proxy (WPAD) یافت. هنگامی که یک کاربر سعی می کند از طریق یک اتصال رمزگذاری شده TLS به وب سایت مراجعه کند ، این نقص می تواند URL را قابل مشاهده کند. از آنجا که آدرس های اینترنتی بعضاً به عنوان نوعی تأیید اعتبار به کاربران ارسال می شود ، حمله غیرمستقیم PAC باعث می شود که یک مهاجم بتواند حساب یک کاربر را در دست بگیرد.

TLS بی خطر است?

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

فناوری کسب و کار امنیت سایبری توسط TheDigitalArtist تحت مجوز CC0