اما علاوه بر دو سمت ارتباط (یعنی کلاینت و سرور)، هر ریکوئستی عبوری از طریق دیوایس‌های مختلفی که در شبکه وجود دارند ممکن است شُنود شده و عملاً پرایوسی نقض شود که برای حل این مشکل از پروتکل HTTPS، که ورژن امن HTTP می‌باشد، استفاده می‌کنند که در این آموزش قصد داریم به آشنایی با سازوکار و نحوهٔ کارکرد این پروتکل بپردازیم که گامی مهم در فرایند مقابله با نقض حریم خصوصی است.
با فاکتور گرفتن از تاریخچه و حاشیه‌های غیرفنی این فناوری، در ادامه مستقیم به اصل مطلب می‌پردازیم و آن هم چیزی نیست جز اینکه HTTPS چگونه دیتای Plain Text را در بر بستر اینترنت امن کرده و از شَر کلیۀ کسانی که قصد شُنود و یا تخریب دیتا را دارند، در امان نگاه داشته است.
HTTPS در واقع دیتای Plain Text (متن ساده) را به اصطلاح Encrypt میکند و در بین مسیر کلاینت تا سرور، دیتایی که توسط نُودهای دیگر دیده می‌شود چیزی جز یکسری عبارات نامفهوم و بی‌معنی نیستند اما در عین حال در دو سمت کلاینت و سرور این دیتا اصطلاحاً Decrypt شده و به دیتایی بامُسمی تبدیل می‌شوند که برای مرورگرها قابل‌درک هستند. شاید ظاهر فرایندی که طی می‌شود آن‌قدر پیچیده نباشد، ولی وقتی کمی دقت کنید ممکن است این سؤال مطرح می‌شود که چگونه می‌توان دیتا را طوری رمزنگاری کرد که فقط در دو سر کلاینت و سرور رمزگشایی شود و مطمئن باشیم فرد دیگری نمی‌تواند این کار را انجام دهد که برای روشن‌تر شدن این مسئله، نیاز به ذکر یک مثال فرضی از دنیای واقعی است.
فرض کنید به چند صد سال قبل برگشته‌ایم؛ زمانی که اساساً کامپیوتری وجود نداشت و شما پادشاه سرزمینی به نام ایران هستید و قصد دارید برای یکی از ایالت‌های خود نامه‌ای بفرستید اما در عین حال نمی‌خواهید کسی از محتوای نامه باخبر شود به علاوه اینکه دوست دارید مطمئن شوید که نامه بدون هیچ‌گونه دستکاری، صحیح و سالم به دست والی آن ایالت می‌رسد. برای این منظور، احتمالاً یک پیک نامه‌رسان را که بیشتر از چشمان خود به او اطمینان دارید خبر کرده و نامه را به دستش می‌دهید و کلی هم سفارش می‌کنید تا آن را بدون هیچ‌گونه کم‌وکاستی و بدون آنکه کسی آن را ببینید به مقصد برساند. تا اینجای کار هیچ مشکلی نیست و همه‌چیز قاعدتاً باید به خوبی پیش برود و پیک شما عازم سفر می‌شود اما در بین راه دشمن کمین کرده و نامه را از چنگش درآورده و از محتوای آن باخبر می‌شود!
خبر کشته شدن پیک به شما می‌رسد و احتمالاً درس بزرگی گرفته‌اید و آن هم اینکه هر چه‌قدر هم پیک شما مطمئن باشد، باید راه‌حلی به منظور مقابله با چالش‌های پیش روی وی پیدا کنید و با درس‌هایی که از اتفاقات ناگوار گذشته گرفته‌اید، دفعهٔ بعد که نامه‌ای می‌نویسید، جوری در آن صحبت می‌کنید که اساساً اگر دست شخص دیگری به آن رسید، هیچ‌وقت متوجه نوشته‌های شما نشود. مثلاً یک زبان رمزی خاصی ابداع می‌کنید و همیشه با آن زبان به مقصد مهم خود نامه می‌فرستید اما باز هم مشکلی که ایجاد می‌شود این است که چگونه والی ایالت مد نظر شما زبان ابتکاری‌تان را درک کند؟
فرض کنید که هیچ‌وقت امکان دیدار حضوری برای شما دو نفر وجود نداشته باشد و از همین روی مجبور می‌شوید قواعد زبان اختراعی خودتان را طی یک نامۀ جداگانه برایش ارسال کنید اما دوباره با مشکل قبلی روبه‌رو خواهید شد بدین صورت که اگر کسی در بین راه به پیک شما دستبرد بزند و قواعد زبان را کشف کند، عملاً اختراع زبان جدید هم بی‌فایده می‌شود.
می‌بینید که در سناریوی فرضی فوق مشکل دوچندان شد اما خبر امیدوارکننده اینکه در دنیای اینترنت این معضل به سادگی و با استفاده از HTTPS رفع شده است اما قبل از توضیح در مورد فرایند اصلی مابین کلاینت و سرور در این پروتکل، نیاز است تا در مورد روش‌های رمزنگاری نامتفارن و متقارن یکسری توضیحات کلی داشته باشیم.
تفاوت رمزنگاری نامتقارن با رمزنگاری متقارن چیست؟
در Asymmetric Encryption (رمزنگاری نامتقارن) یک قفل و یک کلید وجود دارد و همان‌طور که از نام‌شان پیدا است، قفل این وظیفه را دارد تا دیتا را رمزنگاری کند و کلید هم قرار است دیتا را رمزگشایی نماید و این در حالی است که در پروسهٔ رمزنگاری نامتقارن، قفل و کلید دو موجودیت کاملاً متفاوت هستند به طوری که به قفل Public Key و به کلید اصطلاحاً Private Key گفته می‌شود اما در Symmetric Encryption (رمزنگاری متقارن) قفل و کلید دو موجودیت متفاوت نبوده و هر دو یکسانند که به آن‌ها Pre-Shared Key یا Session Key و یا حتی Symmetric Key گفته می‌شود.
HTTPS چگونه کار میکند؟
جالب است بدانید که پروتکل امن HTTPS از هر دو روش رمزنگاری نامتقارن و متقارن استفاده میکند بدین صورت که پس از درخواست کلاینت به سرور مبنی بر ایجاد یک ارتباط امن، سرور گواهینامۀ دیجیتال خود را به همراه Public Key به سمت کلاینت ارسال میکند که گواهینامۀ دیجیتال (Digital Certificate) به نوعی بیانگر هویت آن وب‌سایت بوده و نشان می‌دهد که وب‌سایت مذکور معتبر بوده و مجوز رسمی دارد.
کلاینت پس از دریافت Digital Certificate یا به اختصار DC، آن را به سمت وب‌سایت دیگری به اسم CA Server فرستاده تا از صحت ادعای سرور مطمئن شود.
| نکته |
CA Server مرکزی است که وظیفۀ اعتبارسنجی و هویت‌سنجی گواهینامهٔ SSL را بر عهده دارد و هر سروری که قصد دارد ارتباط امنی ایجاد کند، موظف است تا از این دست مراکز یک گواهینامۀ معتبر تهیه کند. |
پس از آنکه CA Server هویت سرور را تأیید کرد و به کلاینت ریسپانس تأیید را فرستاد، در ادامه مرورگر یک Symmetric Key به صورت رَندوم تولید کرده و با استفاده از Public Key رمزنگاری میکند و به سمت سرور می‌فرستد؛ به عبارتی، مرورگر کلید متقارن خود را با استفاده از قفلی که سرور برایش فرستاده است و CA Server هم صحت آن را تأیید کرده برای سرور می‌فرستد و کسی به جز خود سرور که Private Key را در اختیار دارد، قادر به رمزگشایی پیام کلاینت نیست. در ادامه، پس از طی این مراحل، هم سرور و هم کلاینت Symmetric Key که توسط مرورگر کلاینت تولید شده را در اختیار دارند و SSL Connection ایجاد شده است و ارتباط سرور و کلاینت از این به بعد با استفاده از Symmetric Key صورت می‌گیرد که می‌توانند دیتا را رمزنگاری و رمزگشایی کنند که تصویر زیر به صورت کامل این فرایند را نمایش می‌دهد:
به عنوان یک قانون کلی، چنانچه حفظ حریم خصوصی برایتان حائز اهمیت است، توصیه می‌شود حتماً از وب‌سایت‌هایی استفاده کنید که از پروتکل HTTPS استفاده می‌کنند (دقت کنید که علامت قفل سبزرنگ کنار آدرس‌بار برخی مرورگرها نشان‌دهندۀ آن است که سِرتیفیکیت سرور هنوز معتبر است و در صورتی که این آیکان قرمز باشد، مرورگر به شما هشدار می‌دهد که سِرتیفیکیت معتبر نیست و ریسک تبادل اطلاعات با خودتان می‌باشد.)
| به خاطر داشته باشید |
| با توجه به اهمیت این موضوع، گوگل در رنکینگ خود صفحات سایت‌هایی که روی پروتکل امن HTTPS نباشند را به نوعی ناایمن تلقی کرده تا جایی که دیگر در مرورگر گوگل کروم علامت قفل به رنگ سبز نیست تا به وب‌مسترها نشان دهد که این پروتکل دیگر یک آپشن نبوده بلکه یک باید است. |
همچنین توصیه می‌کنیم برای درک بهتر نحوهٔ عملکرد HTTPS، به وب‌سایت How HTTPS Works مراجعه نمایید که به خوبی این سازوکار را به نمایش درآورده است.