DevOps Engineer / personal Site : sadeghkhademi.com
HTTPS چگونه کار میکند ؟
HTTPS بطور ساده همان پروتکل استاندارد HTTP میباشد که از لایه ی رمزنگاری /SSLTLS استفاده میکند. در واقع از رمز های عبور، جزییات کارت های اعتباری و بطور کلی تمام اطلاعات ارسالی بین کامپیوتر شما و سروری که میخواهید اطلاعات را برای آن ارسال کنید محافظت میکند. قفل سبز کوچک و حروف “https” در نوار آدرس به این معنی نیست که خطری اطلاعات شما و وبسایت هایی که مشاهده میکنید را تهدید نمیکند، آنها حداقل در برقراری ارتباط امن به شما کمک میکنند.
HTTPS چیست و چه کاری انجام میدهد ؟
HTTPS پروتکل HTTP مشهور و شناخته شده را می گیرد و لایه های رمزنگاری SSL/TLS (در ادامه به خلاصه SSL مطرح میشود)را به آن اضافه میکند. Server و سرویس گیرنده همچنان با استفاده از HTTP با همدیگر صحبت میکنند اما با استفاده از اتصال امن SSL که درخواست و پاسخ را تفکیک و رمزنگاری میکند. لایه ی SSL دو هدف اصلی دارد :
- تایید میکند شما بطور مستقیم به سروری متصل هستید که واقعا فکر میکنید به آن متصل شدید !
- مطمئن میشود که فقط سرور میتواند اطلاعاتی که شما ارسال میکنید را بخواند و فقط شما میتوانید اطلاعاتی که سرور ارسال میکند را بخوانید.
واقعا قسمت هوشمندانه این است که هر کسی میتواند هر یک از پیام های شما را با سرور مبادله کند !(man in the middle https attack) اما همچنان قادر نیست که هیچ یک از اطلاعاتی که شما به سمت سرور ارسال میکنید را بخواند!!!
جالب شد، پیام ها توسط هکر قابل دیدن است ولی نه به شکلی که شما میبینید.عکس زیر به خوبی این موضوع را نشان میدهد.
چگونه یک اتصال SSL برقرار میشود ؟
اتصال SSL بین سرویس گیرنده و Server توسط handshake شکل میگیرد که اهداف آن عبارتند از :
- مطمئن کردن سرویس گیرنده از اینکه با سرور درستی در حال تبادل میباشد.( بصورت اختیاری برعکس)
- توافق بر سر“cipher suite” که شامل انتخاب الگوریتم رمزنگاری برای تبادل اطلاعات میشود
- توافق بر سر استفاده از کلید خاص برای الگوریتم توافق شده
بعد از اینکه اتصال برقرار شد هر دو طرف میتوانند از الگوریتم و کلید های توافق شده برای ارسال پیام امن برای طرف مقابل اقدام کنند. ما handshake را به 3 قسمت اصلی تقسیم می کنیم :
Hello, Certificate Exchange, Key Exchange
- Hello : کاربر با ارسال پیام ClientHello فرآیند handshake را شروع میکند. این شامل تمام اطلاعاتی است که Server برای اتصال به سرویس گیرنده از طریق SSL نیاز دارد، که شامل “cipher suite” و بالاترین ورژن SSL که پشتبانی میکند میباشد.Server با استفاده از ServerHello پاسخ میدهد که مشابه همان اطلاعاتی است که سرویس گیرنده نیاز دارد، از جمله تصمیم گیری بر اساس ترجیحات سرویس گیرنده درباره cipher suite و ورژن SSL مورد استفاده است.
- Certificate Exchange : حالا اتصال برقرار شده و سرور میبایست هویت خود را به کاربر ثابت نماید.این اتفاق با استفاده از SSL Certificate صورت میپذیرد. SSL certificate شامل نام صاحب، ویژگی ( به عنوان مثال دامنه ) که به آن متصل است، کلید عمومی certificate، امضاء دیجیتال و اطلاعاتی درباره تاریخ انقضاء گواهینامه میباشد.سرویس گیرنده چک میکند که به گواهینامه اعتماد دارد، یا اینکه توسط یکی از چندین Certificate Authorities تایید شده و مورد اعتماد قرار گرفته است !!! توجه داشته باشید که سرور همچنین مجاز است برای اثبات هویت سرویس گیرنده گواهینامه درخواست کند، که این اتفاق در برنامه های حساس اتفاق می افتد.
- Key Exchange : رمزنگاری اطلاعات پیام مبادله شده توسط سرویس گیرنده و سرور با استفاده از الگوریتم متقارن انجام می شود که در مرحله Hello مطرح می شود.الگوریتم متقارن از یک کلید واحد برای رمزنگاری و رمز گشایی استفاده می کند، در مقایسه با الگوریتم های نامتقارن که نیاز به یک جفت کلید عمومی / خصوصی دارند.
سرویس گیرنده یک کلید تصادفی به منظور استفاده از الگوریتم متقارن تولید میکند و آن را با استفاده از الگوریتمی که در قسمت Hello توافق شده بود و کلید عمومی سرور رمز نگاری میکند (کلید عمومی سرور در گواهی SSL موجود است).این کلید رمزنگاری شده به سرور ارسال می شود و در آنجا با استفاده از کلید خصوصی سرور رمز گشایی می شود و در اینجا قسمت جالب handshake کامل میشود.
درخواست ها و پاسخ های HTTP اکنون میتواند بصورت پیام متنی ساده ایجاد و سپس رمزنگاری و ارسال شود.طرف مقابل تنها کسی است که میتواند پیام را رمز گشایی کند و هکر های MITM نمی توانند درخواست ها را بخوانند یا تغییر دهند.
گواهینامه ها :
اعتماد (Trust) : در ابتدایی ترین سطح گواهی SSL به سادگی یک فایل متنی است و هر کسی با استفاده از یک ویرایشگر متن میتواند آن را ایجاد کند.در واقع شما میتوانید گواهینامه ای بسازید و ادعا کنید که Google Inc هستید و دامنه ی gmail.com را کنترل میکنید(اگر همچین چیزی وجود داشت که SSL فقط یه جک بود.)
2 دلیل منطقی وجود دارد که می توانید به یک گواهی اعتماد کنید:
- آن در لیست گواهینامه های مورد اعتماد شما باشد
- مورد اعتماد یکی از کنترل کننده های گواهینامه ها باشد
بررسی معیار اول راحت هست، مرورگر شما یک لیست از پیش نصب شده ی گواهینامه های SSL معتبر Certificate Authorities را دارد که می توانید آن را مشاهده، اضافه و حذف کنید. این گواهینامه ها توسط یک گروه متمرکز (به صورت تئوری و عموما در عمل) سازمان های بسیار امن، موثق و قابل اعتماد مانند Symantec ، Comodo و GoDaddy کنترل می شوند. اگر سرور گواهینامه ای از این لیست ارائه دهد، می دانید که می توانید به آنها اعتماد کنید.
معیار دوم بسیار سخت تر است، سرور به راحتی می گوید ” نام من مایکروسافت است، شما به Symantec اعتماد میکنید و آنها به من اعتماد دارند”. کاربر باهوش میتواند از Symantec بپرسد که ” مایکروسافت ادعا میکند که شما به آن اعتماد دارید،این حقیقت دارد ؟” اما حتی اگه Symantec بگوید “اره، ما آنها را میشناسیم و مایکروسافت قانونی است ” شما همچنان نمی توانید مطمئن شوید که سروری که ادعا میکند مایکروسافت است، واقعا مایکروسافت است.اینجاست که امضاء دیجیتال وارد عمل میشود.
امضاء دیجیتال (Digital signatures): همانطور که قبلا ذکر شد، گواهینامه SSL دارای یک جفت کلید عمومی / خصوصی مرتبط است.کلید عمومی به عنوان بخشی از گواهی توزیع می شود و کلید خصوصی فوقالعاده ایمن نگهداری می شود.این جفت کلید نامتقارن در SSL handshake برای تبادل کلید های بعدی هر دو طرف به منظور رمزنگاری و رمز گشایی متقارن مورد استفاده قرار میگیرد.سرویس گیرنده از کلید عمومی سرور برای رمزنگاری کلید متقارن استفاده می کند و آن را امن به سرور ارسال می کند و سرور از کلید خصوصی برای رمزگشایی آن استفاده می کند.هر کسی میتواند با استفاده از کلید عمومی رمزنگاری کند ولی فقط سرور است که میتواند با استفاده از کلید خصوصی آن را رمزگشایی کند.
یک گواهینامه میتواند توسط دیگری “signed” شود و بیان شود “ما تأیید کردیم که کنترل کننده این گواهی نیز مالکیت (دامنه) را که در گواهی وجود دارد، کنترل می کند”.در این مورد، authority از کلید خصوصی خود برای رمزنگاری محتویات گواهی استفاده می کند و cipher text به عنوان امضاء دیجیتال آن به گواهی متصل است.هر کسی می تواند این امضا را با استفاده از کلید عمومی رمزگشایی کند اما تنها authority می تواند محتوا را با استفاده از کلید خصوصی رمزنگاری کند و بنابراین تنها authority می تواند در وهله اول یک امضاء معتبر ایجاد کند.
بنابراین اگر یک سرور همراه با داشتن ادعای یک گواهی برای Microsoft.com که توسط Symantec (یا برخی دیگر CA) امضا شده باشد مرورگر شما مجبور نیست که درخواست را اجرا نماید.در صورتی که قانونی باشد، Symantec از کلید خصوصی خود (ultra-secret) برای تولید امضاء دیجیتال گواهی SSL سرور استفاده خواهد کرد، بنابراین مرورگر شما می تواند از کلید عمومی (ultra-public) خود برای بررسی اعتبار این امضاء استفاده کند.Symantec نیز اقدامات لازم را برای اطمینان از اینکه سازمانی که امضای مایکروسافت را انجام داده واقعا خود مایکروسافت است انجام میدهد، به همین ترتیب با توجه به اعتمادی که Client به Symantec میکند می توانید مطمئن باشید که واقعا با شرکت مایکروسافت ارتباط گرفته اید.
Self-signing
توجه داشته باشید که تمام گواهینامه های root CA از نوع “self-signed” هستند، به این معنی که امضای دیجیتال با استفاده از کلید خصوصی خود گواهی تولید می شود.هیچ چیز خاصی در مورد گواهینامه های root CA وجود ندارد، شما اگر بخواهید میتوانید گواهی خود را امضا کنید و از آن برای امضای گواهی های دیگر استفاده کنید.اما از آنجایی که گواهی شما به عنوان یک CA به هیچ وجه در مرورگر قابل بارگیری نیست، هیچکدام از مرورگرها به شما اعتماد نمی کنند که گواهی های خود و دیگران را امضا کنید.این باعث می شود مسئولیت بسیار زیادی بر تمام مرورگرها و سیستم عامل ها برای اعتماد به root CA ها وجود داشته باشد.
شما به چی اعتماد دارید؟
جالب است که سرویس گیرنده از لحاظ فنی سعی در تأیید اینکه آیا باید به طرف مقابل که گواهی فرستاده است اعتماد کند یا نه نمی کند، اما باید به کلید عمومی موجود در گواهی اعتماد کرد.گواهینامه های SSL کاملا باز و عمومی هستند، بنابراین هر هکری می تواند گواهینامه مایکروسافت را بگیرد، درخواست Client را به مایکروسافت برگرداند و گواهینامه قانونی را به آن ارائه دهد.Client قبول میکند و با خوشحالی handshake را شروع میکند.با این حال، هنگامی که مشتری کلید را که برای رمزنگاری استفاده می شود، با استفاده از کلید عمومی واقعی مایکروسافت که از این گواهی بدست آمده است، رمزنگاری می کند و از آنجا که هکر دارای کلید خصوصی مایکروسافت نمیباشد قادر به رمزگشایی اطلاعات نیست.حتی اگر handshake کامل شود همچنان آنها قادر به رمزگشایی کلید نخواهند بود در نتیجه قادر به رمزگشایی اطلاعات تبادل شده نخواهند بود.مشکل زمانی بوجود می آید که هکر کلید خصوصی را در اختیار داشته باشد، در این حالت کلیه اطلاعات قابل رمزگشایی میباشد.
حقایق با حال
آیا صاحب کافی شاپ میتواند ترافیک https من را که از شبکه آن عبور میکند مانیتور کند ؟
جواب منفی است، رمزنگاری public-key بدان معنی است که هر هکری میتواند هر بایت داده ای که بین سرویس گیرنده و سرور مبادله میشود را تماشا کند اما هیچ ایده ای ندارد که شما در حال تبادل چه اطلاعاتی هستید.با این حال، ترافیک HTTP معمولی شما هنوز در شبکه wifi ناامن و بسیار آسیب پذیر است. به عنوان مثال، حتی اگر یک فرم ورودی نام کاربری / رمز عبور را بر روی HTTPS ارسال کند، اگر فرم خود به طور غیرمستقیم بر روی HTTP بارگذاری شده باشد، هکر می تواند فرم HTML را در مسیر خود به دستگاه شما جایگزین کند و آن را تغییر دهد تا جزییات ورود را به وی ارسال کند.
آیا شرکت میتواند ترافیک https من را مانیتور کند ؟
اگر شما از یک دستگاه تحت کنترل شرکت استفاده میکنید، پس بله، شرکت میتواند ترافیک شما را مانیتور کند.به یاد داشته باشید در هر رنجیره ی CA مورد اعتماد، یک CA مورد اعتماد شناخته میشود و لیبستی از authoritie ها را در مرورگر شما ذخیره میکند.شرکت شما میتواند از دسترسی خود به دستگاه شما برای اضافه کردن گواهی نامه ی self-signed خود به این لیست اقدام کند.از آنجا که شما تمام درخواستهای HTTPS خود را با استفاده از کلید عمومی گواهینامه دلخواه خود رمزنگاری می کنید آنها می توانند از کلید خصوصی مربوطه برای رمزگشایی و بازبینی (حتی اصلاح) درخواست شما استفاده کنند و سپس آن را به محل مورد نظر ارسال کنند.
آنها احتمالا این کار را نمی کنند ولی میتوانند.
به هر حال، این نحوه استفاده از یک پروکسی برای بازبینی و اصلاح درخواستهای HTTPS ساخته شده توسط یک برنامه آیفون است.
داستان Lavabit و FBI چی هست ؟
Lavabit ارائه دهنده ایمیل فوق العاده امن در طول افشاگری های ادوارد اسنودن درباره NSA در سال 2013 بود.بدون کلید خصوصی گواهی Lavabit ،آژانس هیچ کاری نمیتوانست بکند و در نتیجه به اطلاعات کاربران Lavabit (از جمله ادوارد اسنودن که از کاربران Lavabit بود) دسترسی نداشتند. با این حال یک قاضی ایالت متحده به بنیانگذار Lavabit گفته بود که باید این کلید را تحویل دهد و به FBI اجازه دهد که ترافیک را برای جاسوسی به مراکز داده ای خود منتقل کند.Levison سعی کرد که قضیه را با استفاده از ۲۵۶۰ کاراکتر از کلید بصورت پرینت شده بر روی کاغذ جمع بکند اما دادگاه به وی گفته بود که یا بصورت موثر با FBI همکاری کند و یا اینکه روزی ۵۰۰۰ دلار تا آخرین روز زنده بودنش پرداخت کند.
که Levison این کار را نکرد، پس از آن GoDaddy گواهی Lavabit را لغو کرد، با این کار گواهینامه ی Lavabit به لیست لغو گواهی (CRL) اضافه شد( CRL در واقع یک لیست از گواهی های نامعتبر که سرویس گیرنده ها نباید به آنها اعتماد کنند میباشد).گواهی های self-signed یا untrustworthy باعث میشوند که مرورگر ها یک پیغام خطای بزرگ قرمز را نمایش دهند تا کاربر را اقدامات بعدی منع کنند.متاسفانه مرورگر ها به اعتماد کردن به گواهینامه های نامعتبر تا زمانی که جدیدترین بروزرسانی های CRL انجام نشود ادامه میدهند.
نتیجه گیری :
HTTPS غیر قابل شکستن است و پروتکل SSL بطور دائم در حال تکامل است زیرا حملات جدید علیه آن کشف میشود اما هنوز راه قابل ملاحضه ای برای انتقال داده ها بطور مخفی از دید کسانی که میخواهند اطلاعات شما را ببیند هست.خیلی جزییات پیاده سازی مثل فرمت دقیق پیام های handshake اینجا ذکر نشده است.
نکته کلیدی که باید به یاد داشته باشید این است که در حالی که HTTPS اطلاعات را امن نگه می دارد، به هیچ وجه از شما (به عنوان یک کاربر یا توسعه دهنده) در برابر XSS و یا نشت داده های پایگاه داده یا هر چیز دیگری جلو گیری نمیکند.
مطلبی دیگر از این انتشارات
نصب ویندوز سرور 2016
مطلبی دیگر از این انتشارات
راه اندازی NFS Share در Ubuntu 16.04
مطلبی دیگر از این انتشارات
بهترین ضبط کننده های دسکتاپ برای اوبونتو