SSL و HTTPS چیست و چرا برای سایت ضروری است؟

وقتی مرورگر کنار آدرس قفل نشان می‌دهد یا برعکس «Not secure» می‌نویسد، موضوع تزئین بصری نیست؛ موضوع این است که ارتباط بین کاربر و سرور رمزنگاری شده و هویت سرور با گواهی قابل‌اتکا تأیید شده یا نه. مردم هنوز می‌گویند «SSL نصب کنیم»، اما پروتکل امروزی که وب روی آن امن می‌شود Transport Layer Security (TLS) است. HTTPS همان HTTP است که روی TLS سوار شده.

MDN HTTPS را نسخهٔ رمزنگاری‌شدهٔ HTTP تعریف می‌کند که با TLS همهٔ ارتباط کلاینت و سرور را رمز می‌کند تا دادهٔ حساس — لاگین، پرداخت، فرم — در مسیر شنود یا دستکاری آسان نشود. MDN دربارهٔ TLS هم صریح می‌گوید این پروتکل پیش‌تر با نام SSL شناخته می‌شد و مرورگرهای مدرن برای ارتباط امن به گواهی دیجیتال معتبر از سمت سرور نیاز دارند.

این مقاله تعریف‌ها را از منابع رسمی می‌گیرد، Mixed Content و HSTS را خلاصه می‌کند، Let's Encrypt را مفهومی توضیح می‌دهد، و دربارهٔ SEO فقط همان چیزی را می‌گوید که Google Search Central نوشته — نه بیشتر.

پاسخ کوتاه

SSL نام تاریخی خانوادهٔ پروتکل است؛ امروز باید TLS (ترجیحاً ۱.۲ یا ۱.۳) را در ذهن داشته باشید. HTTPS یعنی HTTP روی کانال TLS: مرورگر گواهی سرور را می‌بیند، کلید جلسه برقرار می‌شود، و ترافیک رمز می‌شود. بدون HTTPS، رمز عبور و کوکی نشست روی مسیرهای ناامن در برابر شنود آسیب‌پذیرترند و بسیاری از قابلیت‌های مرورگر مدرن محدود یا هشداردهنده می‌شوند.

برای SEO: گوگل از ۲۰۱۴ HTTPS را به‌عنوان یک سیگنال رتبه‌بندی سبک معرفی کرد و بعداً «served in a secure fashion» را در ارزیابی page experience مطرح کرده است. این به‌معنای «فقط HTTPS بگذار و رتبهٔ اول شو» نیست؛ محتوا و تجربهٔ کلی مهم‌ترند. HTTPS ضروری امنیتی است که هم‌راستا با سیستم‌های گوگل هم هست — نه یک رتبهٔ جادویی.

اگر هنوز می‌گویید SSL، منظورتان را شفاف کنید: منظورتان گواهی و HTTPS روی TLS است، نه پروتکل منسوخ SSL.

SSL در برابر TLS: نام‌ها را درست کنید

در گفت‌وگوی روزمره «SSL» به هر چیز مرتبط با قفل مرورگر گفته می‌شود: گواهی، نصب روی هاست، حتی اجبار HTTPS. از نظر تاریخی SSL پیش‌نیاز TLS بود؛ MDN صریحاً می‌نویسد TLS سابقاً Secure Sockets Layer نامیده می‌شد. مرورگرهای عمده پشتیبانی TLS 1.0 و 1.1 را حدود ۲۰۲۰ کنار گذاشتند؛ سرور باید TLS 1.2 یا 1.3 را پشتیبانی کند.

پس وقتی فروشنده می‌گوید «SSL رایگان»، معمولاً یعنی صدور و نصب گواهی برای HTTPS با TLS. اشکالی ندارد همان اصطلاح بازاری را بفهمید؛ اشکال این است که تصور کنید پروتکل قدیمی SSL هنوز استاندارد تولید است. در مستندات فنی، پیکربندی، و گزارش امنیتی بنویسید TLS/HTTPS.

HTTPS دقیقاً چه کار می‌کند؟

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

نتیجه برای کاربر: کمتر دیده شدن داده در Wi-Fi عمومی، سخت‌تر شدن تزریق تبلیغ یا اسکریپت وسط مسیر، و اعتماد بیشتر مرورگر به origin امن. نتیجه برای توسعه‌دهنده: بسیاری از APIهای حساس مرورگر و کوکی‌های Secure فقط در بستر امن معنا دارند. نتیجه برای محصول: فرم لاگین و پرداخت روی HTTP دیگر قابل‌دفاع نیست.

گواهی دیجیتال (Certificate) چیست؟

گواهی یک سند رمزنگاری است که یک Certificate Authority (CA) برای یک یا چند نام دامنه صادر می‌کند و کلید عمومی سرور را به آن نام‌ها پیوند می‌دهد. مرورگر زنجیرهٔ اعتماد را تا CA ریشهٔ ازپیش‌معتمد خود دنبال می‌کند. اگر نام دامنه با گواهی جور نباشد، گواهی منقضی باشد، یا زنجیره ناقص باشد، اتصال شکست می‌خورد یا هشدار جدی نشان داده می‌شود.

انواع رایج از دید صاحب سایت: تک‌دامنه، چنددامنه (SAN)، و Wildcard برای زیردامنه‌ها. انتخاب نوع به معماری نام‌ها بستگی دارد نه به «قدرتمندتر بودن جادویی». نکتهٔ مهم‌تر از نوع گواهی، پوشش درست نام‌هایی است که کاربر واقعاً تایپ می‌کند (با و بدون www، API، پنل) و تمدید خودکار قبل از انقضا.

Let's Encrypt به زبان مفهومی

Let's Encrypt گواهی را از طریق API خودکار مبتنی بر پروتکل ACME صادر می‌کند. طبق صفحهٔ Getting Started خودشان، برای گرفتن گواهی باید یک ACME Client داشته باشید؛ خود وب‌سایت صرفاً اطلاعاتی است. بسیاری از هاست‌ها کلاینت را برایتان اجرا می‌کنند؛ وگرنه ابزارهایی مثل Certbot رایج‌اند. Staging برای تست توصیه شده تا محدودیت نرخ تولید را بی‌جهت مصرف نکنید.

Let's Encrypt رایگان بودن را با اتوماسیون گره زده است: اگر تمدید خودکار نشکند، مدل ۹۰روزه مشکلی نیست؛ اگر Cron یا پلاگین هاست بمیرد، سایت ناگهان هشدار گواهی می‌دهد. مسئولیت عملیات با کسی است که سرور یا لبه را نگه می‌دارد — نه با «چون رایگان است پس بی‌نیاز از مراقبت است».

Mixed Content: وقتی صفحه HTTPS است ولی منابع HTTP

MDN Mixed Content را این‌طور تعریف می‌کند: صفحه‌ای که از origin امن (HTTPS) بارگذاری شده، اما منابعی را با HTTP یا پروتکل ناامن می‌کشد. حتی اگر خود HTML امن باشد، اسکریپت یا منبع دستکاری‌شده می‌تواند صفحه را خراب کند. مرورگرها ریسک را با ارتقای خودکار بعضی منابع (مثل تصویر/ویدئو/صدا در موارد تعریف‌شده) و مسدود کردن بقیه کاهش می‌دهند.

علائم عملی: قفل شکسته، هشدار کنسول، یا اسکریپت‌هایی که دیگر لود نمی‌شوند. درمان درست: همهٔ منابع خودتان را HTTPS کنید، لینک‌های http:// را نسبی یا https:// کنید، و برای منابع شخص ثالث نسخهٔ امن بگیرید. مهاجرت ناقص به HTTPS — فقط صفحهٔ اصلی امن، بقیه نه — تجربهٔ کاربری و اعتماد را هم‌زمان خراب می‌کند.

HSTS: بعد از HTTPS، اجبار مرورگر به HTTPS

هدر Strict-Transport-Security (HSTS) به مرورگر می‌گوید این میزبان را فقط با HTTPS باز کن و تلاش‌های بعدی HTTP را ارتقا بده. MDN تأکید می‌کند هدر باید روی HTTPS ارسال شود نه HTTP، وگرنه نادیده گرفته می‌شود تا مهاجم وسط مسیر نتواند آن را خراب کند. HSTS اولین بازدید ناامن را جادو نمی‌کند؛ preload و redirect دائمی به HTTPS ضعف «اولین اتصال» را کم می‌کنند.

برای سایت تولید، الگوی رایج این است: redirect دائمی HTTP→HTTPS، سپس HSTS با max-age معقول، و فقط وقتی همهٔ زیردامنه‌ها آماده‌اند includeSubDomains را جدی بگیرید. خاموش کردن عجولانهٔ HSTS ساده نیست؛ با max-age=0 روی اتصال امن باید برنامه‌ریزی کنید.

HTTPS و SEO: سیگنال هست، میانبر رتبه نیست

در اوت ۲۰۱۴ وبلاگ Google Search Central اعلام کرد HTTPS به‌عنوان سیگنال رتبه‌بندی استفاده می‌شود و در آن زمان سیگنالی بسیار سبک بود — اثر روی کمتر از ۱٪ کوئری‌های جهانی و وزن کمتر از محتوای باکیفیت — با این هدف که مالکان سایت به HTTPS مهاجرت کنند. متن رسمی همان‌جا HTTPS را «HTTP over TLS» هم می‌نامد.

در مستند page experience گوگل، یکی از پرسش‌های خودارزیابی این است که آیا صفحات به‌صورت امن سرو می‌شوند. گوگل می‌گوید سیستم‌های اصلی رتبه‌بندی به تجربهٔ خوب صفحه پاداش می‌دهند و نباید روی یک یا دو جنبه قفل شد. همچنین تصریح می‌کند یک «سیگنال واحد page experience» وجود ندارد. جمع‌بندی صادقانه: HTTPS لازم است، با جهت سیستم‌های گوگل هم‌راستاست، و جایگزین محتوا، ربط کوئری، و تجربهٔ کلی نیست.

از ادعای «با نصب SSL صد پله بالا می‌روید» فاصله بگیرید. اگر رقیب هم‌تراز دارید، نبود HTTPS می‌تواند شما را عقب بیندازد؛ اما مشکل محتوای ضعیف را حل نمی‌کند. گزارش HTTPS در Search Console برای یافتن صفحات ناامن ابزار عملی است، نه داشبورد معجزه.

چک‌لیست عملی برای صاحب سایت

1. همهٔ نام‌های عمومی سایت (apex، www، api در صورت نیاز) روی HTTPS با گواهی معتبر و زنجیرهٔ کامل.
2. Redirect دائمی از HTTP به HTTPS؛ اجتناب از حلقه و محتوای تکراری روی هر دو طرح.
3. حذف Mixed Content: اسکریپت، CSS، فونت، XHR/fetch، و دانلودها.
4. کوکی‌های نشست با پرچم Secure (و ترجیحاً HttpOnly) — جزئیات در مقالهٔ Cookie/Session.
5. تمدید خودکار گواهی را مانیتور کنید؛ هشدار انقضا قبل از شکایت کاربر.
6. TLS 1.2+ فعال؛ پروتکل‌ها و رمزهای قدیمی را ببندید.
7. پس از پایداری، HSTS را مرحله‌ای فعال کنید.

مسیر کاربر از تایپ آدرس تا قفل مرورگر

کاربر https://example.com را باز می‌کند یا از http به https هدایت می‌شود. دست‌دهی TLS انجام می‌شود: سرور زنجیرهٔ گواهی را می‌فرستد، مرورگر اعتبار زمانی، نام دامنه (SAN)، و اعتماد به CA را می‌سنجد، سپس کلیدهای جلسه توافق می‌شود. از این لحظه درخواست‌های HTTP داخل کانال رمزشده می‌روند. اگر جایی در میانهٔ مسیر گواهی برای نام دیگری باشد — مثلاً DNS به سرور اشتراکی اشتباه اشاره کند — کاربر هشدار می‌بیند حتی اگر «روی هاست SSL نصب کرده باشید».

اینجا پیوند مقالهٔ دامنه/DNS/هاست عملی می‌شود: گواهی به نام دامنه بسته است، مسیر به IP از DNS می‌آید، و فایل کلید خصوصی روی Hosting یا لبهٔ CDN می‌ماند. جابه‌جایی هاست بدون انتقال کلید/صدور مجدد، یا روشن کردن CDN بدون گواهی درست روی لبه، همان خطای رایجی است که تیم‌ها به‌اشتباه «خراب شدن SSL» می‌نامند.

اشتباه‌های عملیاتی پرتکرار

• گواهی فقط برای www؛ کاربر به apex می‌آید یا برعکس.
• زنجیرهٔ میانی (intermediate) ناقص؛ بعضی مرورگرها می‌سازند، بعضی نه.
• Mixed Content بعد از مهاجرت؛ اسکریپت‌های قدیمی http باقی مانده.
• تمدید Let's Encrypt روی سروری که Cron غیرفعال شده.
• فعال کردن HSTS با includeSubDomains وقتی یک زیردامنه هنوز HTTP-only است.
• فرض اینکه CDN همهٔ مشکلات Origin را مخفی می‌کند؛ Origin ناامن یا گواهی‌نادرست همچنان می‌شکند.

برای عیب‌یابی: از یک ماشین جدا dig بگیرید، با openssl s_client یا ابزار آنلاین زنجیره را ببینید، و در کروم Security panel وضعیت گواهی را چک کنید. اگر فقط یک شبکه مشکل دارد، گاهی SSL Inspection سازمانی یا آنتی‌ویروس وسط مسیر است — نه لزوماً پیکربندی شما.

چه چیزی HTTPS نیست؟

HTTPS جلوی XSS ذخیره‌شده، Broken Access Control، یا Secret داخل مخزن را نمی‌گیرد. کانال امن است؛ منطق برنامه ممکن است ناامن بماند. همچنین «قفل سبز» قدیمی یا هر آیکون قفل به‌معنای اعتماد کامل به کسب‌وکار نیست؛ فقط به‌معنای انتقال رمزشده تا سروری است که گواهی‌اش برای آن نام معتبر بوده. فیشینگ روی دامنهٔ شبیه با HTTPS معتبر همچنان ممکن است.

بنابراین اولویت درست این است: اول HTTPS و گواهی سالم برای همهٔ entrypointها، بعد کنترل هویت و دسترسی، بعد سخت‌سازی اپلیکیشن. جابه‌جا کردن این ترتیب — مثلاً صرف بودجه برای افزونهٔ SEO قبل از رفع Mixed Content — اعتماد کاربر را بیشتر از رتبهٔ فرضی تحت تأثیر قرار می‌دهد.

جمع‌بندی برای تصمیم

HTTPS ضروری است چون از کاربر و نشست در مسیر شبکه محافظت می‌کند، با انتظارات مرورگر مدرن جور است، و با سیگنال‌های اعلام‌شدهٔ گوگل هم‌راستاست. SSL را به‌عنوان برچسب بازاری بفهمید؛ در عمل TLS و گواهی درست و تمدید خودکار را پیاده کنید. Mixed Content را بعد از مهاجرت پاک کنید و HSTS را وقتی مسیر پایدار شد اضافه کنید.

اگر همین هفته یک کار می‌کنید: سایت را در حالت ناشناس باز کنید، قفل و هشدار را ببینید، کنسول را برای Mixed Content چک کنید، و تاریخ انقضای گواهی و وضعیت تمدید خودکار را در یک خط مستند کنید. برای مرحلهٔ بعد، تفاوت دامنه/DNS/هاست را روشن نگه دارید تا گواهی روی نام و مقصد درست نصب شود.

امنیت انتقال فقط یک لایه است؛ بعد از HTTPS هنوز باید Authentication و Authorization، کوکی امن، و مدیریت Secret را جدی بگیرید — وگرنه کانال امن به اپلیکیشن ناامن می‌رسد.

منابع و مراجع

• MDN — HTTPS (Glossary) — https://developer.mozilla.org/en-US/docs/Glossary/HTTPS
• MDN — TLS (Glossary) — https://developer.mozilla.org/en-US/docs/Glossary/TLS
• MDN — Mixed content — https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
• MDN — Strict-Transport-Security — https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
• Let's Encrypt — Getting Started — https://letsencrypt.org/getting-started/
• Google Search Central Blog — HTTPS as a ranking signal (2014) — https://developers.google.com/search/blog/2014/08/https-as-ranking-signal
• Google Search Central — Understanding page experience — https://developers.google.com/search/docs/appearance/page-experience

اگر در حال مهاجرت از HTTP هستید، اول نام‌ها و DNS را ثابت کنید، بعد گواهی و redirect، بعد پاکسازی Mixed Content؛ عجله برای «فقط یک پلاگین SSL» بدون این ترتیب معمولاً قفل شکسته و تیکت پشتیبان می‌سازد.