رمزنگاری مقدماتی : امضا و گواهینامه دیجیتال

رمزنگاری مقدماتی به زبان ساده : امضا دیجیتال و گواهینامه دیجیتال
رمزنگاری مقدماتی به زبان ساده : امضا دیجیتال و گواهینامه دیجیتال

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

امضای دیجیتال (Digital Signature) :

امضای پیام یا امضای دیجیتال درواقع همون امضای دنیای واقعی خودمونه ولی توی دنیای کامپیوتر ما ازش استفاده میکنیم ، چه چیز هایی برای ما فراهم میکنه ؟ Integrity یا صحت پیام و Authentication یا همون اعتماد از اینکه فردی که داریم باهاش صحبت میکنیم واقعا همون فرد مد نظر ماست و شخص جعلی ای نیست!

ما از دوتا الگریتم میتونیم برای امضای دیجیتال استفاده کنیم :

  1. RSA : ما توی مطلب قبلی گفتیم و اینجا هم جریان همونه ، اگر کسی با کلید خصوصیش یه پیامی رو رمز کنه و بفرسته و شما با کلید عمومی بتونی اونو رمزگشایی کنی ، یعنی این پیام واقعا از سمت طرف امده ، درواقع این یه نوع امضا حساب میشه ، چطوری شما وقتی به امضای یکی نگاه میکنی میگی اره این 99 درصد شبیه امضای فرده پس این از سمت خودشه؟ شما هم اگر با کلید عمومی طرف بتونی پیامشو رمز کنی یعنی طرف واقعا کلید خصوصیش دستش بوده و 100 درصد خودشه !
  2. DSA : (Digital Signature Algorithm(DSS))

ما برای امضای دیجیتال کلا یه چیز جداگونه داریم که بهش میگن DSA یا DSS و با این هم ما امضا میگیریم از یه پیام هم امضا رو میتونیم اعتبار سنجی کنیم :

امضای دیجیتال با RSA :

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

عکس1
عکس1


علی اول از پیامش هش میگیره و اونو با کلید خصوصیش رمز میکنه که بهش میگیم امضا ، علی امضا و پیام رو برای زهرا میفرسته ، زهرا اول پیام رو با کلید عمومی علی باز میکنه و به یه هشی میرسه، بعد از پیام هش میگیره و جفت هش هارو مقایسه میکنه ، اگر یکی بودن که هیچ اگر نه یعنی یکی این وسط پیام رو تغییر داده (ما اینجا هدفمون Integrity هست و Authentication که مطمئن شیم طرف خودشه) ولی اینجا ما Confidentiality یا محرمانگی نداریم و ممکنه یه مهاجم این وسط باشه پیام رو بخونه !

امضای دیجیتال با DSA :

Signature Creation :

INPUT : Message + Domain Parameters + Random Num + Private Key

OUTPUT: Signature

Signature Verification :

INPUT : Message + Domain Parameters + Signature + Public Key

OUTPUT: True(1) or Flase(0)

توی امضای دیجیتال ما دوتا فرایند داریم ، فرایند اول ساخت امضاعه و فرایند دوم اعتبار سنجی اون امضاعه ، در ساخت امضا ما چند تا ورودی داریم : پیام + یه مقدار اولیه برای شروع + یه مقدار رندوم + کلید خصوصی ، ترکیب این ها باهم میشه امضا یا Signature ، در قسمت اعتبارسنجی ما پیام رو وارد میکنیم ، مقدار اولیه ای که باهاش شروع کردیم ، امضا و کلید عمومی ، نتیجه یا 1 هست یا 0 (Boolean) یعنی یا امضا درسته و خودشه یا نیست

نکته : دقت کنید که در DSA ما هیچ رمزنگاری یا رمزگشایی ای انجام ندادیم !

امضا دیجیتال دوتا هدف رو برای ما به ارمغان میاره : Integrity و Authentication

در RSA اگر پیام تغییر کنه ، هشی که گرفتیم موقع بازکردن با کلید خصوصی ارور میده و در DSA اگر پیام تغییر کنه، نتیجه اعتبار سنجی امضا 0 یا False برمیگرده

حالا محتویاتی که توی Message داریم چی هست ؟

1. در SSL Certificate ، درواقع Message همون محتوای خود مدرکه و ما داریم بررسی میکنیم که آیا محتوا این مدرک درسته یا نه (جلوتر میرسیم به بحث مدرک)

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

3. ما هیچ وقت برای Bulk Data نمیاییم از امضا دیجیتال استفاده کنیم چون حجم پردازش دیتا خیلی زیاد میشه ، بجاش ما از MAC استفاده میکنیم برای امضای دیتاهای حجیم !

نکته : اینجا علی پیام رو خالی ارسال کرده برای زهرا که بعدا وقتی امضا رو باز کردن و از پیامم هش گرفت مطمئن بشه پیام تغییر نکرده ، علی میتونست پیام رو هم با کلید خصوصی خودش یا کلید عمومی زهرا رمز کنه که پیام هم محرمانه منتقل بشه (اگر با کلید خصوصی خودش رمز میکرد ، وقتی زهرا پیام رو و امضا رو با کلید خصوصی علی باز میکنه ، از دوجا مطمئن میشه که این پیام واقعا از سمت علی آمده و تغییریم نکرده) خیلی ایـــــــــــزی :)

Trust Model - PKI - Certificates :

بحث اعتماد تو اینترنت وقتی مطرح شد ، همه گفتن چطوری اعتماد کنیم که این کلید عمومی برای فلانیه ؟ ما یه مفهومی داریم به نام WOT (Web Of Trust)

عکس 2
عکس 2

مثل زندگی روزمره و دنیای واقعی ما ، جریان اینطوریه که ی دختری ما داریم بالا وسط که صورتیه و یه دختر بنفش رو میشناسه ، دختر بنفشه فقط یه مرد زرد رو میشناسه ، مرد زرده یه دختر ابی و یه پسر بادمجونی رو میشناسه ، پسرک بادمجونی رنگ ما یه مرد قرمزو میشناسه که اونم دوتا مرد نارنجی و سبزو میشناسه ! این آدم ها وقتی هم دیگه رو میشناسن یعنی هویت اون رو تایید میکنن ، حالا بریم تو دنیای کامپیوتر ، هویت هر فرد کلید عمومیشه دیگه ؟ من اگر بخوام تاییدش کنم باید امضاش کنم دیگه ؟ تموم شد رفت ، هرکی وقتی کس دیگه ای رو میشناسه کلید عمومیشو امضا میکنه و یه لیست درست میکنن که آقا این افراد تو این سیستم شناسن و شما میتونید به این ها پیام بدید (به غیر این ها نمیتونید پیام بدید)

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

حالا این سیستمو آمدن گذاشتن کنار ولی یه سیستم مبتنی بر اون ساختن به اسم PKI

قبلش بزارید یه مثال از دنیای واقعی بزنم که خوبتر درک کنید جریانو ، شما یه فرد 22 ساله هستید که توی جیبتون کارت بانکی ، کارت ملی ، گواهی نامه دارید ، یه پست برای شما امده و شما میرید اون رو تحویل بگیرید ، طرف میگه مدارک هویتی بده ، شما چه چیزی ارائه میدید؟ شما هر کارتی رو که همراه دارید اگر ارائه بدید تایید کننده هویتتونه ، اگر کارت ملی ارائه بدید یعنی هویتتون رو سازمان ثبت احوال تایید کرده ، اگر کارت بانکی بدید یعنی هویت تون رو بانک تایید کرده و اگر گواهی نامه بدید یعنی هویتتون رو پلیس تایید کرده ، شما به وسیله تاییدیه و اعتبار ثبت احوال ، بانک ، پلیس معتبر شناخته میشید ، یعنی چون اونا معتبرن و به شما اعتبار میدن ، شما هم معتبر شناخته میشید ، حــــالـا

در دنیای اینترنت ما یه CA (Certificate Authority) داریم ، یه جاییه مثل سازمان ثبت احوال یا بانک یا پلیسی که گفتم ، یه شرکت معتبریه که همه میشناسنش و اعتبارش تایید شدس ، میرید اونجا و اون ازتون درخواست مدرک میکنه برای احراز هویتتون ، مثل بانک که میخواید کارت بگیرید ازتون مدارک هویتی میگیره ، وقتی احرازتون تکمیل شد ، CA ازتون کلید عمومی تونو میخواد که باید از طریق کانال امنی بهش منتقل کنید ، CA یه مدرک دیجیتالی یا Digital Certificate میسازه که اطلاعات هویتی شما و علی الخصوص کلید عمومیتون توشه ، بعد این مدرک توسط اون CA امضا میشه و بهتون داده میشه ، شما این مدرک رو هرکجا که ببرید (وقتی سایت دارید میتونید ازش استفاده کنید) ثابت میکنه که این فرد شمایید یا این سایت متعلق به شماست و معتبره ، کسیم بخواد اعتبار سنجی بکنه میاد از اون CA میپرسه که آیا این فرد واقعا واقعیه یا نه

سوال : شما میگی مدرکت رو به همه بده و قابل دسترسم هست ، اگر کسی این مدرک رو برداره و بره ادعا کنه به بقیه که منم چی؟

مشکلی پیش نمیاد چون نهایت کاری که اتفاق می افته اینه که یه پیام با کلید عمومی شما رمز میشه که چون فقط شما کلید خصوصی رو دارید خودتون میتونید باز کنید و بقیه هرچقدرم ادعا کنن این کلید و مدرک برای منه نمیتونن پیام رو باز کنن چون کلید خصوصی تونو ندارن

وقتی میخوایم Certificate بگیریم ، داریم از استاندارد x509 پیروی میکنیم ، پس اگر شنیدید x509 Certificate بدونید همونه و چیز خاصی نیست ، فرایند گرفتن مدرک اینطوریه :

عکس 3
عکس 3


توی عکس سه همونطور که شاهد هستید ما در یک طرف قضیه یه فردی رو داریم که میخواد احراز کنه ، یه فرم به نام فرد CSR یا تقاضانامه امضا دیجیتال پر میکنه و توش کلید عمومی شو میزاره و از طریق راه امن (راه امن رو توضیح میدم جلوتر) میرفته به CA ، بعد CA ازش میخواد هویتشو تایید کنه و احراز کنه ( این مرحله بشدت سخت گیرانس چون اگر راحت باشه هویت و اعتبار CA زیر سوال میره و اساسا کلا میپوکه و مردم بهش بی اعتماد میشن و دیگه هیچ) بعد که تایید شد در قالب ساختار x509 میاد کلید عمومی اون فرد رو میزاره و با کلید خصوصی خودش اون رو امضا میکنه و این رو تحویل فرد میده و طرف از این به بعد Certificate رو داره :)

دوتا نکته بی ربط اما مهم :

فرق بین امنیت پیام و راه امن چیه ؟ یه نکته رو من مختصر اینجا بگم و بهتون یه دید کامل بدم که جریان از چی قراره ، ببینید ما کلا دوتا مکانیزم کلی برای امن سازی داریم ، یا پیامو امن کنیم ، یا راه رو امن کنیم ، فرض کنید یه پادشاهی میخواد یه نامه ای بده به سربازش که ببره بده پادشاه دیگه ، دوتا کار باید بکنه ، یا نامه رو رمز کنه و بده سربازش که اگر سربازشو خفت کردن نامه لو نره ، یا نامه رو کاری نکنه ، و همراه سربازش 200 نفر بفرسته که از نامهه محافظت بکنن ، راه اولی میشه امن کردن پیام و دومی میشه تونل و راه امن ، کدوم بنظرتون بصرفه تره و هزینش کمتره ؟ 200 تا سربازو غذا بدی یا فقط یه سرباز؟ 200 تا اسب یا یک اسب؟ پس همیشه رمز کردن پیام بهتر از امن کردن راهه ولی ما توی کامپیوتر خیلی اوقات میاییم و راه رو امن میکنیم و برامون اونقدر کند نمیشه شرایطو ، الگریتم های وی پی ان از این دسته هستن ، کارشون Tunneling یا تونل زدنه ، میان و یه راه امن ایجاد میکنن و شما داخل اون هرچیی خواستی ردو بدل کن هیچ مهاجمی نمیتونه چیزی بفهمه ، ولی ما تو اکثر شرایط برامون چون نمیصرفه ، میاییم کلید رو یطوری میرسونیم به مخاطبمون و میگیم با این رمز کن و بفرست

این حالتی که گفتم ما به مخاطبمون میگیم کلید چیه (از طریق امن البته) و مخاطب کلید رو داره (متقارن یا نامتقارن فرق نداره ولی اکثرا متقارنه) و باهاش رمز میکنه پیام رو و میده به ما ، به این حالت میگن E2EE (End-To-End Encryption) و به این معنیه که رمزنگاری و رمزگشایی پیام فقط در مبدا و مقصد اتفاق می افته و در حین انتقال پیام هیچ گونه رمزنگاری/رمزگشایی ای روش انجام نمیشه !

درواقع رمزنگاری پیام در شیوه سنتی و رایج اینطوریه که وسط انتقال حالا یه جایی رمز میشه(مثلا ممکنه پیام از دستگاه شما تا سرور فرستنده به صورت خام بره و اونجا رمزبشه) ولی اگر رمزنگاری E2EE باشه ، در بدو ارسال از دستگاه شما رمز میشه، و دیگه بازم نمیشه(دقت کنید، دیگه باز نمیشه) تا به مقصد برسه !

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

فرق بین RCA و ICA چیست ؟

قبل اینکه مطلب رو ادامه بدم بیام و یه نکته رو کوتاه عرض کنم که امنیت کلید خصوصی خود CA برامون خیلی مهمه ، فرض کنید یه CA بیاد و مدرک میلیون ها سایت رو گردن بگیره ، حالا فرض کنید کلید خصوصی این CA لو بره و میلیون ها سایت امنیتشون به خطر میفته و میلیون ها Certificate باید Revoke بشن ، آمدن گفتن خب ما بیاییم چند تا CA اصلی یا مرکزی یا ریشه داشته باشیم (Root CA (RCA)) از اونور هر کدوم از این RCA ها به چند زیر شاخه تقسیم بشن و چندین CA هم بشن زیر شاخه این ها (Intermediate CA (ICA)) و اینطوری آمدن ریسک پخش شدن کلید رو کم کردن ، به این صورت که وقتی ما ICA های زیادی داشته باشیم که سایت ها از این ها مدرک میگیرن ، چون دیگه زیاد با کلید خصوصی RCA کار نداریم (جلوتر میگم چرا) و فقط با کلید خصوصی ICA ما ما امضا میکنیم ، قرار بر لو رفتن باشه کلید این ICA ها لو میره و حجم و محدوده خرابی مون خیلی کمتر میشه

عکس4
عکس4

فرایند به این صورته ، همونطور که در مدرک هر سایت پیداس ، مثلا من این عکسو از SSL سایت چت جی پی تی برداشتم ، سایت که سومی باشه ، توسط یه ICA که کلودفلره امضا شده مدرکش و بالاترم RCA شو میبینید

سایت از ICA مدرک میگیره ، خود ICA یک امضا داره از RCA و RCA هم که شناسه و چیزی نیاز نداره ! پس وقتی ما به سایت ریکوئست میدیم ، چون میریم امضا ICA رو چک میکنیم و امضاشم وصله به RCA و ما هویت اون برامون روشنه پس سایتم اوکیه دیگه :)

بررسی فرایند ساخت یه CSR در Openssl :

قبل از هرچیزی بگم که این فرایند کلا جداست از بحثی که یادگرفتیم ، فقط یکم دست به کیبرد میزنیم که ببینیم چیزایی که یادگرفتیم چقدر فرق داره با دنیای واقعی :

hpn# openssl req -new -newkey rsa:2048
..+.+..+.+..............+.................................+..........+..............+...+...+....+...+...........+....+..+.+...+...........+++++++++++++++++++++++++++++++
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
Country Name (2 letter code) [AU]:IR
State or Province Name (full name) [Some-State]:ARAK
Locality Name (eg, city) []:MALEK
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Mohammad Hassan
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:Qholi
Email Address []:ermac@null.net

-----BEGIN CERTIFICATE REQUEST-----MIICuzCCAaMCAQAwdjELMAkGA1UEBhMCSVIxDTALBgNVBAgMBEFSQUsxDjAMBgNV
eMZM/FoIlPoapR1rBDCvrycx0OKKzjhwpfuQmYE/Kq6q4k9RmJ7nc6wbiHEaoQHA
csTnJkRHBYosPBhiOddsQwwfaZsSC/6Yk0RFQyks3e1FEsxhH7mvlX3kcSx3QpaY
q15cw9K/FDVFugnJj9K1ctc5w9IZ8XlVqPc+o+8C+Q==
-----END CERTIFICATE REQUEST-----

اولش ما میگیم یه req یا csr میخوایم بسازیم که جدیده ، با کلید جدید از این نوع ، یه پسورد میخواد که از این CSR محافظت کنه ، بعد اطلاعات از ما میگیره و در نهایت یه متن base64 میده که ما باید بفرستیم برای CA و ادامه کار ..

Digital Certificate Revoking :

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

دوتا روش هست برای Revoke کردن که توسط CA ارائه میشه (یکیش منسوخ شده البته):

CRL (Certificate Revocation List) : یه لیست میسازه از مدارک باطل شده و هرکی هر گواهی نامه ای رو میخواد چک کنه باید بره توی این لیست بگرده ببینه هست یا نه ، اگر بود یعنی اون گواهینامه معتبر نیست ، اگر نبود یعنی معتبره ، مسخرس نه ؟ مثل WOT

OCSP (Online Certificate Status Protocol) : یک پروتوکوله یا سرویسیه که کاربر ها میتونن از طریق اون بپرسن که آیا این گواهی نامه معتبره یا نه

نکته : درواقع OCSP همون CRL عه ولی اینبار خود CA پشت صحنه انجام میده کارشو و نیاز نیست کاربر کاری کنه ، تازه کاربر هم نمیخواد کاری کنه و مرورگر وظیفه داره OCSP رو چک کنه ! (البته مروگر گوگل کروم سیاست و روش خودشو برای این کار داره که از سایر مرورگر ها جداست ولی خب مهم نیست اونقدارم :) )

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

الان اگر برگردید به مطلب امضای دیجیتالی که نوشتم بالای صفحه میفهمید وقتی میگم Message ای که امضا میشه در SSL خود محتوای مدرکه یعنی چی

عکس 5
عکس 5

دقت کنید به عکس سمت چپ ، یه مدرک ssl هست که ما در سمت وب استفاده میکنیم ، نوشته lets encrypt امضاش کرده برای ویرگول ، هششم اینه و مدت انقضاشم اینه

سمت راست یه برنامه هست توی مجموعه ویندوز اینترنالز به اسم Process Monitor ، دقت کنید که من Properties گرفتم رفتم سربرگ امضا دیجیتال و دیدم که بله ماکروسافت امضاش کرده ، حالا یه نکته ای ، چرا ماکروسافت امضاش کرده ؟ اگر این برنامه رسید به سیستم عامل ، سیستم عامل بدونه که از سمت ماکروسافته و مخرب نیست ، پس ویندوز به Sign ماکروسافت حساسه مخصوصا برای درایور ها چون خیلی حساسن، مکانیزم های امنیتیم به درایوری که Sign ماکروسافت باشه کاری ندارن ، حالااااا فکر کنید یکی ماکروسافتو بزنه و کلید خصوصیشو برداره و بیاد بدافزار خودشو بنویسه و بد افزار خودشو Sign کنه و به یه جا حمله کنه ، تمومه دیگه نه ؟ رسما کل مکانیزم های امنیتی و همه رو دور زده :) خبرو بخونید :

https://uk.pcmag.com/security/139354/hacking-group-starts-dumping-files-allegedly-stolen-from-microsoft
https://onhexgroup.ir/microsoft-storm-0558-private-key/

این اتفاق برای خیلی از شرکتا افتاده ، اگر یه شرکت سازنده سخت افزار کامپیوتریم باشه و درایورش لو بره مثل Intel یا MSI یا ASUS هرچی ، اونم همچین چیزی میشه ، این لینک و این لینک هم ببینید که کلید گیت هابم در رفته (منتها اشتباه کارکنانش بوده)

یک سری نکات تکمیلی :

1. بحث مدرک برای هانتر های عزیز خیلی مهمه از اونجایی که میتونن Subdomain Discovery و... بکنن و توی هانت خیلی کمکشون میکنه

2. آیا میتونه یه نفر خود برای خودش مدرک بزنه ؟ آره ولی خب اعتباری نداره چون خودش امضا میکنه و موقع اعتبار سنجی به هیچ جا وصل نیست پس تایید نمیشه

3. مدرک در حوزه وب (SSL-TLS-HTTPS) فقط برای دامین صادر میشه نه آیپی ، چرا؟ چون آیپی متغییره و دامین ثابته و نمیشه تضمین کرد که رنج های مختلف آیپی برای همون شرکت باقی بمونن و اصلا توی بحث Revoke شم شرکت های با مشکل مواجه میشن بعد یه مدتی !

4. مدرک توی حوزه وب (SSL-TLS-HTTPS) فقط برای احراز سروره ولی میتونیم ازش برای احراز کلاینت هم استفاده کنیم ، اگر بحث شبکه و وی پی ان زدن به درون یک سازمان رو مطرح کنیم ، ما وقتی به سرور وی پی ان میزنیم با Certificate اش صحت سرور رو احراز میکنیم و وقت کلاینت که ما باشیم Certificate داشته باشیم ، سرور هم میتونه مارو اعتبار سنجی کنه !

5. ما دوتا نکته داریم تحت عنوان Preloaded List و HSTS به صورت خلاصه بگم :

یه سری حملات ماروی SSL-TLS-HTTPS داریم و برای جلوگیری از این حملات آمدن دوتا مکانیزم امنیتی گذاشتن :

HSTS :

ما یه حمله داریم به اسم sslstrip که زیاد مهم نیست فقط بدونید که این حمله تو دسته حملات شبکس و اینطوریه که مهاجم وایمیسه تا شما به یه سایت که HTTPS داره درخواست بزنید ، درخواست شمارو ریدایرکت میکنه به نحوی که در پاسخ به شما HTTP برگرده ولی شما فکر کنید که دارید با HTTPS کار میکنید (تکنیک قدیمی ایه و از کار افتاده) و برای جلوگیری از این حمله آمدن یه مکانیزم توی سایت گذاشتن به نام HSTS که سایت تحت هیچ عنوان با HTTP لود نشه و فقط با HTTPS لود بشه ، اصطلاحا جلوی Protocol Downgrading یا تنزیل پروتوکول رو گرفتن و اینطوری این حمله جلوش بسته شد ، ولــــــی

Preloaded List :

حمله ای که بالا گفتم در یه صورت باز عمل میکرد ، و اونم درصورتیه که شما برای اولین بار یه سایتی رو باز کنید توی مرورگرتون ، مثلا گوگل یا فیس بوک رو برای اولین بار باز کنید ، اونطوری امکان اجرای این حمله بود ، آمدن گفتن خب ما چیکار کنیم ؟ آمدن توی مرورگر ها لیست سایت هایی که پیشفرض HTTPS روشون فعاله و باید با HTTPS بازش کنن رو گذاشتن و گفتن حتما این سایت هارو با HTTPS باز کنید ، و اینطوری جلوی این حمله به خیلی از سایت های مطرح گرفته شد ، ولی خب به طبع همه سایتا تو این لیست نیستن دیگه :)

دقت کنید که تکینک های مختلفی برای بایپس HSTS هست و اونم در صورتیه که شما لینک رو اشتباه تایپ کنید ، اگر اشتباه تایپ کنید و سایت بالا بیاد صد در صد مهاجم اون وسط نشسته یا اینکه ISP یه کارایی میکنه که بعیده :)

لیست Preloaded های مرورگر کروم و فایرفاکس

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