پروتکل HTTPS چیست؟ کاربرد ها و تفاوت های HTTPS و HTTP

HTTPS چیست ؟ https مخفف Hypertext Transfer Protocol Secure یا پروتکل امن انتقال ابر متن یک نسخه رمزگذاری شده از HTTP است که پروتکل اصلی مورد استفاده برای انتقال داده ها از طریق وب جهان گستر (World Wide Web) می باشد.

HTTPS از ارتباط بین مرورگر و سرور شما در برابر استراق سمع (interception) و دستکاری شدن توسط مهاجمان محافظت می کند. این پروتکل محرمانگی (Confidentiality)، صحت و درستی پیام ها (Integrity) و احراز هویت (authentication) اکثر قریب به اتفاق ترافیک امروز WWW را فراهم می کند.

هر وب سایتی که نماد قفل را در نوار آدرس نشان دهد، به این معناست که از پروتکل HTTPS استفاده می کند.

HTTP در مقابل HTTPS: کاربرد پروتکل HTTPS

قبل از بیان کاربرد  پروتکل HTTPS ابتدا اجازه دهید که ارتباط بین مشتری (مرورگر) و سرور را به همراه وجود یک مهاجم در میانشان به صورت ساده نشان بدهم.

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

حملات احتمالی شبکه می تواند در هر مکانی با یک روتر (Router) نامعتبر و یا ISP اتفاق بیفتد. بنابراین هر شبکه WiFi عمومی در معرض چنین حملاتی است. خوشبختانه به نظر می رسد که عموم مردم از این واقعیت (افزایش استفاده از VPN ها) آگاه هستند. با این حال ، ایمن کردن تجربه مرور (browsing) همه بر عهده وب مسترها است و باید بار آن را به دوش بکشند.

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

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

اکنون ، هنگام ایجاد کانکشن HTTPS ، اتفاقات زیادی رخ می دهد. به صورت کلی، HTTPS برای تامین امنیت کانکشن ها به رمزگذاری TLS (Transfer Layer Security) متکی است.

نحوه کار گواهینامه های TLS

تنها راه فعال کردن HTTPS در وب سایتتان، دریافت گواهینامه TLS و نصب آن بر روی سرور است. همچنین ممکن است به عنوان گواهینامه SSL یا SSL / TLS با آن روبرو شوید، اما نگران نباشید ، همه چیز یکسان است. اگر چه همه ما از نظر فنی از TLS به عنوان جانشین SSL استفاده کنیم، اما SSL اصطلاحی است که هنوز هم به صورت گسترده ای استفاده می شود،.

گواهینامه های TLS توسط Certificate Authorities (CA) صادر می شوند. نقش CA این است که به عنوان شخص ثالث قابل اعتمادی در روابط مشتری و سرور ظاهر شود. اساساً ، هرکسی می تواند گواهینامه TLS صادر کند اما فقط CA های مورد اعتماد عموم توسط مرورگرها پشتیبانی می شوند.

با کلیک بر روی نماد قفل در نوار آدرس مرورگر خود ، می توانید گواهینامه TLS و CA صادر کننده آن را چک کنید.

برای کسب اطلاعات بیشتر می توانید روی گواهینامه کلیک کنید. نکته مهم در اینجا خط "صادر شده برای: (Issued to:)" می باشد. این زمانی است که ما با انواع مختلفی از استانداردهای اعتبارسنجی برای گواهینامه های TLS روبرو می شویم که گواهینامه های رایگان و پولی را جدا می کند.

DV، OV و EV: به چه معنایی هستند و کدام یک را باید انتخاب کرد؟

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

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

رایج ترین گواهینامه DV TLS از یک CA غیر انتفاعی به نام Let’s Encrypt تهیه می شود. این همان چیزی است که اکثر شرکت های ارائه دهنده گواهینامه های TLS تجدید پذیر خودرکار و رایگان، استفاده می کنند.

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

اگر وب سایت شما اجازه ورود (login) و یا پرداخت را می دهد ، باید در یک گواهینامه TLS که organization validation (OV) و یا extended validation (EV) را ارائه می دهد، سرمایه گذاری کنید. این دو نوع، در فرآیند تأیید با یکدیگر متفاوت هستند (سختگیری بیشتر در EV).

اگر قصد خرید فقط یکی از آن ها را دارید، توصیه می کنم مستقیماً به سراغ گواهینامه EV TLS بروید. چون قابل اعتمادترین بوده و هزینه آن بیش از نوع OV هم نیست.

گواهینامه های SAN TLS و Wildcard

با پشت سر گذاشتن استانداردهای اعتبار سنجی ، اجازه دهید به سراغ دسته دیگری از گواهینامه های TLS برویم.

از گواهینامه های SAN و Wildcard برای ایمن سازی همزمان چندین دامنه (زیر دامنه) استفاده می شود. در واقع، اگر یک گواهینامه استاندارد EV TLS برای example.com خریداری کرده اید ، برای blog.example.com به یک گواهینامه جداگانه دیگری نیاز خواهید داشت.

گواهینامه های Wildcard می توانند زیر دامنه های نامحدود (example.com، blog.example.com ، docs.example.com) را ایمن کنند در حالی که گواهینامه های SAN همچنین می توانند دامنه های دیگر را نیز امن کنند (example.com، blog.example.com، different.org).

این گواهینامه ها با انواع اعتبار سنجی ترکیب می شوند ، بنابراین هنگام جستجو گزینه های ارائه شده توسط CA ، انواع ترکیبات را خواهید دید. آنها همچنین شما را در ارتباط با این موضوع (فرآیند اعتبار سنجی) راهنمایی خواهند کرد.

تاثیر HTTPS بر سئو

تقریباً تمام تاثیر HTTPS بر سئو بر می گردد:

⦁ سیگنال رتبه بندی سبک

⦁ امنیت و حریم خصوصی بهتر

⦁ حفظ و نگه داری داده های ارجاعی

⦁ امکان استفاده از پروتکل های مدرن به منظور افزایش امنیت و سرعت سایت

مزایای HTTPS به SEO : سیگنال رتبه بندی سبک

گوگل اعلام کرد که HTTPS یک عامل رتبه بندی خفیف در سال 2014 بوده است. این عامل بیشتر شبیه وقت اضافه در مسابقه محسوب می شودکه اگر سایر متغیرهای عامل رتبه بندی بدون تغییر بمانند می تواند در رتبه بندی شما اثر بگذارد. این اساساً همکاری و کمک گوگل به پذیرش سریعتر HTTPS در سراسر جهان را نشان می دهد.

امنیت و حریم خصوصی بهتر در سایت های https

ما قبلاً در مورد این موضوع صحبت کردیم. اما این داستان چگونه به سو. ربط پیدا می کند؟

وقتی در یک وب سایت نا امن قرار می گیرید ، چیزی شبیه به این را خواهید دید:

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

حدس من این است که HTTPS می تواند باعث بهبود زمان توقف (Dwell time) شده و از پوگو استیکینگ (Pogo sticking) جلوگیری کند. در حالی که این عوامل رتبه بندی فقط تئوری (تأیید نشده) هستند ، وادار کردن مردم به ماند در وب سایتتان، چیزی است که شما همیشه صرف نظر از سئو به دنبال آن هستید.

E-A-T چیست؟ چرا برای سئو مهم است؟

حفظ و نگه داری داده های ارجاعی

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

از آنجا که این روزها بیشتر وب با HTTPS کار می کند ، منبع بیشتر ترافیک ارجاعی (کلیک روی لینک های وب سایت های دیگر) در اکثر نرم افزارهای تجزیه و تحلیل به عنوان مستقیم (direct) تگ گذاری می شود.

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

نکته: اگر به اشتباهات رایج ردیابی Google Analytics علاقه مند هستید ، این پست را چک کنید.

امکان استفاده از پروتکل های مدرن به منظور افزایش امنیت و سرعت سایت

روی کاغذ ، HTTPS به دلیل ویژگی های امنیتی اضافه شده ، کندتر از HTTP است. با این حال ، داشتن HTTPS پیش نیاز استفاده از جدیدترین فناوری امنیتی و عملکرد وب است.

به عبارت دیگر ، علاوه بر امنیت ، HTTPS همچنین به وب سایت شما این امکان را می دهد تا هنگام استفاده از پروتکل‌هایی مانند TLS 1.3 و HTTP / 2 ، سرعت صفحه خود را بهبود ببخشد. جدای از تجربه کاربری بهتر ، گوگل سرعت صفحه را به عنوان یک عامل رتبه بندی کوچک و خفیف مانند HTTPS در نظر می گیرد:

" یک فاکتور رتبه بندی کوچک به حساب می آید که بسیار شبیه به https در افزایش رتبه عمل می کند. تعجب آور نیست. شما این کار را در درجه اول برای تجربه کاربری بهتر انجام می دهید. - گری ایلیس (Gary Illyes (@methode) 28 آوریل 2020"

چگونگی راه اندازی HTTPS

به سناریو شما بستگی دارد.

1. شما در حال راه اندازی یک وب سایت جدید هستید

شما در قرعه کشی برنده شده اید. از ابتدا با HTTPS همراه شوید و دیگر نگران HTTP و خطاهای مرتبط با این تغییر پروتکل نباشید.

تمام کاری که شما باید انجام دهید این است که یک ارائه دهنده میزبانی خوب داشته باشید که شما را در روند کار راهنمایی کند و از آخرین نسخه های پروتکل HTTP و TLS پشتیبانی کند. بعد از تمام شدن و راه اندازی ، HSTS را به عنوان آخرین مرحله ایجاد امنیت، پیاده سازی کنید.

2.  شما قبلاً یک وب سایت دارای قابلیت HTTPS داشتید

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

3.  شما در حال حاضر وب سایتی دارید که از طریق HTTP اجرا می شود

مدتی طول می کشد تا همه چیز آماده و انجام شود. پیچیدگی انتقال به HTTPS به موارد زیر بستگی دارد:

⦁ اندازه و پیچیدگی وب سایت شما

⦁ این که از چه نوع CMS استفاده می کنید

⦁ ارائه دهندگان میزبانی/ CDN شما

⦁ توانایی های فنی شما

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

من به شما پیشنهاد می کنم مستندات CMS / سرور / هاستینگ / CDN خود را بررسی کرده و طبق آن پیش بروید (با احتیاط). مراحل زیادی وجود دارند که شما باید آن ها را انجام دهید ، بنابراین یک چک لیست ایجاد کرده و آن را دنبال کنید و سعی کنید که خود را درگیر فعالیت های دیگری نکنید.

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

نحوی بررسی خطاهای محتمل ناشی از انتقال سایت به HTTPS

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

در واقع ، در سال 2016 ، ما 10000 دامنه برتر را به منظور بررسی اشتباهات مختلف HTTPS تجزیه و تحلیل کردیم و موارد زیر را یافتیم:

⦁ 90.9% دامنه ها از اجرای بهینه HTTPS برخوردار نبودند.

⦁ HTTPS روی %65.39 دامنه ها به درستی کار نمی کرد.

⦁ 23.01٪ دامنه ها به جای ریدایرکت دائمی 301s، از 302 موقت استفاده می کردند.

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

اشتباه 1: صفحات باقی مانده بر روی HTTP

اول و مهمترین این است که شما باید مطمئن شوید که همه صفحات سایت شما بر پایه HTTPS هستند.

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

اگر از Ahrefs’ Site Audit استفاده می کنید ، تنظیمات زیر را توصیه می کنم:

پس از پایان کار ، جدیدترین crawl را باز کنید ، به Page Explorer بروید و فیلتر زیر را اعمال کنید:

لیست URL های HTTP را استخراج کرده و برای پایان دادن به این انتقال، آنها را مجدد هدایت کنید.

اشتباه 2: صفحات HTTPS با محتوای HTTP

این اشتباه زمانی رخ می دهد که فایل HTML اولیه با استفاده از HTTPS بارگیری شود در حالی که فایلهای منبع آن (تصاویر ، CSS ، JavaScript) هنوز به HTTPS به روز نشده باشد.

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

اشتباه 3: لینک های داخلی که به HTTPS به روز نشده اند

به روزرسانی نکردن لینک های داخلی شما به HTTPS باعث تغییر مسیرهای غیرضروری می شود. بدیهی است که این بهتر از فرود بر صفحه HTTP می باشد اما ما قبلاً این اشتباه را تجربه کرده ایم. تشخیص این لینک ها و رفع آنها آسان است.

این مشکل را در گزارش لینک ها در Site Audit پیدا خواهید کرد:

فقط URL ها را به https:// بازنویسی کنید. در این صورت کار شما به اتمام رسیده است. این امر فقط درصورتی اجرا شدنی است که از قبل اطمینان داشته باشید که هیچ صفحه HTTP ای با استفاده از توصیه های اشتباه شماره 1 باقی نمانده است.

اشتباه 4: تگ هایی که به HTTPS به روز نشده اند

دو نوع تگ وجود دارد که ممکن است در وب سایت خود استفاده کنید. همچنین لازم است URL های آنها به HTTPS به روز شوند: تگ های Canonical و تگ های Open Graph.

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

اگر از تگ های Open Graph برای بهینه سازی پست های رسانه های اجتماعی خود استفاده می کنید ، پس تگ های URL توسط Facebook الزامی هستند. آنها باید همانند URL های canonical باشند.

برای پیدا کردن صفحات با تگ های کنونیکال و اپن گراف HTTP ، این فیلتر سفارشی را در Page Explorer تنظیم کنید:

مجدداً ، تنها چیزی که باقی مانده این است که آنها را دوباره به https:// بازنویسی کنید.

اشتباه 5: ریدایرکت های ناموفق

ریدایرکت ها ممکن است حیله گرانه بوده و در موارد زیادی منجر به اشتباه شوند (از ریدایرکت های معیوب تا زنجیره ها و حلقه های ریدایرکت).

خوشبختانه ، تشخیص این خطاها با Site Audit آسان است. فقط گزارش ریدارکت ها را چک کرده و تمام مسائل را بررسی کنید.

بعد از کلیک روی "View affected URLs" ، گزارشی مشابه این را مشاهده خواهید کرد (فقط با ستون ها و معیارهای پیش فرض بیشتر):

بهترین چیز در اینجا این است که شما واقعاً تمام URL های تحت تأثیر قرار گرفته را مشاهده خواهید کرد (آن هایی دوباره هدایت شده اند، آن هایی که داخل زنجیره ریدایرکت قرار دارند و سایر مواردی که به URL های هدایت شده لینک می زنند).

در اینجا باید دو کار انجام دهید.

اولین مورد، جدا کردن ریدایرکت ها است ، در این حالت:

https://blog.example.com/123/> -> 301 redirect -> >https://example.com/blog/987/

این امر اطمینان می دهد که همه بک لینک هایی که به هر دو https://blog.example.com/123/ و https://example.com/blog/123/ اشاره دارند فقط یک بار ریدارکت می شوند. این موضوع برای لینک های خارجی خوب است زیرا دسترسی به وب مستر ها به منظور درخواست ویرایش لینک، بسیار ناکارآمد و آزار دهنده است.

هر چند می توانیم از نظر داخلی بهتر عمل کنیم.

شما باید برای کمترین تعداد ریدایرکت تلاش کنید. این زمانی است که تعدادی از اینلینک ها (Inlinks) وارد بازی می شوند.

اینلینک ها URL هایی هستند که به URL تحت تأثیر قرار گرفته از زنجیره ریدایرکت لینک می زنند. شما می خواهید لینک های موجود در آن صفحات را با URL هایی که کد وضعیت 200 HTTP را برمی گردانند ، تعوض کنید. اگر روی تعدادی از این لینک ها کلیک کنید ، همه آنها را مشاهده خواهید کرد:

البته ، دوباره ، مرحله بعدی، بررسی اینلینک های URL هایی است که در داخل زنجیره ریدایرکت قرار دارند. با این حال ، این امر اولویت کمتری دارد زیرا که ما از قبل زنجیره ریدایرکت را شکسته ایم. این موارد به عنوان ریدایرکت 301 در گزارش 3XX Redirects تگ گذاری می شوند.

حرف آخر

امیدوارم که با هم بتوانیم وب جهان گستر (World Wide Web) را سریعتر و ایمن تر جستجو کنیم.

طبق w3techs.com ، 59.4٪ از وب سایت ها به طور پیش فرض از HTTPS استفاده می‌کنند. به عنوان مقایسه ، گوگل گزارش می دهد که بین 88 تا 99 درصد از زمان جستجو در Chrome، به وب سایت های HTTPS اختصاص می یابد.

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

از نظر کیفیت پشتیبانی، TLS هنوز جای پیشرفت زیادی دارد. همانطور که در اینجا آموخته اید ، صرفا با نصب HTTPS، فرآیند انتقال و تغییر پروتکل پایان نمی یابد. همگام بودن با روند عملکرد و امنیت وب و اجرای جدیدترین ویژگی ها (features)، به نفع همه افراد درگیر در این موضوع است.