جامعه SEO، در بیشتر موارد، ابتدا توجه خود را به قفل سبز کوچک HTTPS در سال 2014 معطوف کرد، زمانی که گوگل پستی را منتشر کرد که HTTPS را به عنوان سیگنال رتبه بندی اعلام کرد . تقریباً بلافاصله همه سئوکاران به مشتریان HTTP خود توصیه کردند که برای اهداف رتبهبندی به HTTPS بروند، اما در واقعیت، هرگز در مورد رتبهبندی نبوده (و هرگز نباید میبود).
پس چرا گوگل در مورد رتبه بندی صحبت کرد؟ به طور خلاصه، برای جلب توجه مردم.
هدف بلندمدت گوگل این بوده است که وب را برای کاربران ایمن تر کند و از کاربران خود محافظت کند. به هر حال، اگر Google نتیجهای را به کاربر ارائه دهد که مشاهده کند اطلاعات کارت اعتباریاش دزدیده شده است، ممکن است اعتماد کمتری به Google برای ارائه نتایج ایمن و با کیفیت به آنها داشته باشد.
HTTPS دوباره در کانون توجه قرار گرفته است زیرا Google Chrome 68 به طور فعال وب سایت ها را به عنوان "امن" و "ناامن" برای کاربران برجسته می کند. مسئله برای من، استفاده از کلمه "امن" در همین جاست.
داشتن گواهینامه SSL به این معنی نیست که شما یک وب سایت امن دارید و با نزدیک شدن سریع مقررات جدید GDPR اروپا، بسیاری از مشاغل ممکن است به دلیل این تصور اشتباه گرفتار شوند. حملات سایبری پرمخاطب در سرتاسر جهان همچنین رسانههای جمعی را به موضوعات امنیت سایبری مورد توجه قرار داده است، زیرا برندهای بزرگ (مانند بارکلیز، یک بانک سرمایهگذاری چندملیتی بریتانیایی) کمپینهای عمومی را برای افزایش آگاهی در مورد اصول اولیه امنیت سایبری راهاندازی میکنند.
اما، حتی این تبلیغ تلویزیونی بارکلیز نیز اشتباه بود. این تبلیغ میکرد که سایتی با قفل سبز و HTTPS نشانه اصلی بودن یک وبسایت است و بدون آن وبسایت میتواند جعلی باشد. وب سایت های جعلی همچنان می توانند از HTTPS استفاده کنند.
اگر وبسایتی، جعلی یا واقعی، بخواهد از فناوریهای SSL/TLS استفاده کند، تنها کاری که باید انجام دهد این است که گواهینامه دریافت کند. گواهینامه های SSL را می توان به صورت رایگان دریافت کرد و در عرض چند دقیقه از طریق فناوری هایی مانند Cloudflare پیاده سازی کرد و تا آنجا که به مرورگر مربوط می شود - سایت امن است.
درک نحوه عملکرد گواهینامه های SSL
هنگامی که کاربر به یک وب سایت هدایت می شود، وب سایت گواهی را در اختیار مرورگر قرار می دهد. سپس مرورگر گواهی ارائه شده توسط وب سایت را تأیید می کند:
- برای همان دامنه ای که به آن دسترسی دارید معتبر است.
- توسط یک CA (مرجع صدور گواهی) مورد اعتماد صادر شده است.
- معتبر است و تاریخ انقضا آن تمام نشده است.
هنگامی که مرورگر کاربر اعتبار گواهینامه SSL را تأیید کرد، اتصال به صورت ایمن ادامه می یابد. در غیر این صورت، در مرورگر خود یک اخطار ناامن دریافت خواهید کرد یا دسترسی به سایت را رد می کند. در صورت موفقیت آمیز بودن، مرورگر و سرور وب سایت جزئیات لازم را برای ایجاد یک اتصال ایمن مبادله می کنند و سایت بارگیری می شود.
بنابراین تا چه حد HTTPS یک وب سایت را ایمن می کند؟
رمزگذاری در انتقال / رمزگذاری در حالت استراحت
HTTPS (و SSL/TLS) چیزی را فراهم می کند که «رمزگذاری در حین انتقال» نامیده می شود. این بدان معنی است که داده ها و ارتباطات ما بین مرورگر و سرور وب سایت (با استفاده از یک پروتکل ایمن) در قالب رمزگذاری شده است، بنابراین اگر این بسته های داده رهگیری شوند، نمی توان آنها را خواند یا دستکاری کرد.
با این حال، زمانی که مرورگر دادهها را دریافت میکند، آنها را رمزگشایی میکند، و زمانی که سرور دادههای شما را دریافت میکند، رمزگشایی میشود - بنابراین میتواند در آینده به خاطر سپرده شود یا توسط سایر ادغامها، مانند CRM استفاده شود. SSL و TLS در حالت استراحت (زمانی که داده ها در سرور وب سایت ذخیره می شوند) رمزگذاری را برای ما فراهم نمی کنند. این بدان معنی است که اگر یک هکر بتواند به سرور دسترسی پیدا کند، می تواند تمام داده هایی را که شما ارسال کرده اید بخواند.
اکثر هکها و نقضهای داده با مشخصات بالا در نتیجه دسترسی هکرها به این پایگاههای داده رمزگذاری نشده اتفاق میافتد، بنابراین در حالی که فناوریهای HTTPS به این معنی است که دادههای ما به صورت امن به پایگاههای داده میرسند، اما بهطور امن ذخیره نمیشوند.
SSL همچنین می تواند آسیب پذیر باشد
مانند بسیاری از فناوریها، SSL و TLS همیشه در حال تکامل و ارتقا هستند. SSLv1 هرگز به صورت عمومی منتشر نشد، بنابراین اولین تجربه واقعی همه ما با SSL در سال 1995 با SSLv2 بود که حاوی تعدادی نقص امنیتی جدی بود.
SSLv2 هنوز هم میتواند مشکلاتی ایجاد کند، زیرا تعداد زیادی از پیادهسازیها و پیکربندیهای فعلی SSL نادرست هستند به این معنی که مستعد حملات DROWN هستند .
SSLv3 در سال 1996 معرفی شد و از آن زمان تاکنون شاهد معرفی TLSv1، TLSv1.1 و TLSv1.2 هستیم.
اینجاست که SSL خود می تواند یک آسیب پذیری مستقیم باشد. با پیشرفت فناوریها، همه وبسایتها با آنها پیشرفت نمیکنند، و بسیاری از وبسایتها با وجود استفاده از گواهینامه SSL جدید، همچنان از پروتکلهای قدیمیتر پشتیبانی میکنند. هکرها میتوانند از این آسیبپذیری و پشتیبانی قدیمیتر برای انجام یک حمله کاهش رتبه پروتکل استفاده کنند - جایی که مرورگر کاربر را با یک پروتکل قدیمیتر به وبسایت متصل میکنند - و در حالی که بسیاری از مرورگرهای مدرن مانع از اتصال SSLv2 میشوند، SSLv3 هنوز بیش از 20 سال از عمر آن میگذرد. .
خود SSL نیز در برابر تعدادی از حملات احتمالی دیگر از جمله BEAST ، BREACH ، FREAK و Heartbleed آسیب پذیر است .
HTTPS در صفحات پرداخت/ورود به سیستم یک امنیت نادرست است
برای مدت طولانی، بسیاری از مشاغل تجارت الکترونیک HTTPS را فقط در صفحات پرداخت یا صفحات ورود به سیستم کاربر حفظ می کردند اما HTTP را در صفحات دیگر اجرا می کردند.
وقتی وارد یک وب سایت می شوید، سرور یک کوکی را پس می فرستد، این بدان معنی است که شما مجبور نیستید وارد سایت شوید و از آن خارج شوید (شما را به خاطر می آورد). مشکل این است که وقتی به مرور وبسایت در HTTP ادامه میدهید، همان کوکی احراز هویت از طریق یک اتصال ناامن ارسال و دریافت میشود، که میتواند منجر به رهگیری کوکی توسط مهاجم، سرقت آن و سپس جعل هویت شما در تاریخ بعدی شود.
در نتیجه گیری
SSL/TLS، زمانی که به درستی پیاده سازی شود، یک فناوری حیاتی برای ایمن سازی داده های کاربر در هنگام انتقال بین مرورگر کاربر و سرور وب سایت است. برای پوشش کامل، یک وب سایت همچنین باید از HSTS برای محافظت در برابر حملات کاهش رتبه پروتکل و ربودن کوکی ها استفاده کند.
این فناوری همچنین یک وب سایت را در برابر هزاران سوء استفاده قابل هک شناخته شده دیگر که می تواند داده های کاربر را به خطر بیندازد، ایمن نمی کند.
گفتن اینکه HTTPS ایمن است نادرست نیست، اما کاملاً درست نیست. این یک قطعه در یک اره منبت کاری اره مویی امنیت سایبری است که در ظاهر یکی از ساده ترین ویژگی های امنیتی برای شناسایی است - به ویژه از نقطه نظر خزنده وب. من قبلاً در مورد افزودن یک عنصر اسکن غیرفعال به یک وب خزنده پیشرفته در آینده توسط گوگل و در نظر گرفتن جنبه های مختلف امنیت وب سایت در فاکتورهای رتبه بندی آنها نوشته ام .
ما باید به مشتریان خود آموزش دهیم که برای ایمن کردن وبسایتهای خود و محافظت از کاربران خود و همچنین مطابقت با GDPR، باید اقداماتی بیش از HTTPS انجام دهند.