چگونه HTTPS را از طریق VPN به اولین درخواست تبدیل کنیم

مرورگری که ابتدا http:// را تایپ می کند و پس از تغییر مسیر روی https:// فرود می آید، قبلاً یک درخواست را به صورت پاک ارسال کرده است، و VPN آن را تغییر نمی دهد. تونل پا را از مشتری تا گره خروجی محافظت می کند؛ هیچ چیزی را در بالای لایه انتقال رمزگذاری نمی کند، بنابراین یک ناظر بین خروجی و مبدا همچنان پرش متن ساده را می بیند. تبدیل HTTPS به اولین درخواست، تغییر سمت مشتری با سه بخش است: آدرس HTTPS واقعی، حالت ارتقاء مرورگر، و خط مشی خود سایت. مراحل زیر ترتیبی است که من استفاده می‌کنم، هر کدام با چکی که به شما می‌گوید آیا این کار انجام شده است یا نه.

مرحله 1: تأیید کنید که اولین درخواست واقعاً چیست

قبل از تغییر هر چیزی، به آنچه مرورگر ارسال می کند نگاه کنید. پانل شبکه را با صفحه بارگذاری مجدد از یک کش سرد باز کنید و ردیف اول را بخوانید: اگر طرح http و وضعیت 301 یا 308 باشد، همه چیز بعد از آن ردیف درخواست دوم است. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com همان دنباله را در خارج از مرورگر بازتولید می کند و نشانی اینترنتی را که در نهایت به آن رسیدید چاپ می کند.

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

مرحله 2: حالت فقط HTTPS مرورگر را روشن کنید

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

در فایرفاکس، کنترل‌ها در پشت about:config و در صفحه تنظیمات حریم خصوصی، با dom.security.https_only_mode به‌عنوان سوئیچ و استثناهای هر سایت از منوی قفل مدیریت می‌شوند، وجود دارند. در Chrome و Edge همین ایده در قسمت تنظیمات، حریم خصوصی و امنیت، امنیت، با برچسب همیشه از اتصالات امن استفاده کنید، قرار دارد. برچسب هرچه که باشد، رفتار را در برابر میزبانی که فقط در پورت 80 پاسخ می‌دهد تأیید کنید، زیرا حالتی که ارتقا می‌یابد و سپس بی‌صدا به عقب می‌افتد، محافظتی نیست که فکر می‌کنید فعال کرده‌اید. مستندات فقط HTTPS-Firefox به‌روزرسانی، هشدار و رفتار استثنایی آن مرورگر را بیان می‌کند.

مرحله 3: منابع را اصلاح کنید، نه فقط نوار آدرس

هنگامی که ارتقاء ناموفق بود، به جای نوار آدرس، خطای دقیق را بخوانید. یک میزبان بدون شنونده HTTPS، یک نام میزبان که با گواهی مطابقت ندارد و یک زنجیره منقضی شده، پیام‌های مختلفی تولید می‌کنند و به مالکان مختلف تعلق دارند. تنها مورد اول یک شکاف سمت سرور است؛ دومی معمولاً نشانکی است که هرگز به روز نشده است؛ سومین مشکل تجدید است که اتصال VPN به آن بی ربط است.

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

قسمت سوم در داخل صفحه است و این قسمتی است که مردم از دست می دهند. صفحه‌ای که از طریق HTTPS بارگیری می‌شود همچنان می‌تواند تصاویر، فونت‌ها یا اسکریپت‌ها را از یک URL http بیرون بکشد و مرورگر آنها را مسدود کرده یا نشانگر امنیتی کل صفحه را کاهش می‌دهد. درخواست های ناموفق را در پانل شبکه بررسی کنید و به جای اینکه فرض کنید نوار آدرس هر درخواست را توصیف می کند، منابع منبع را در صاحب آنها اصلاح کنید. در سایتی که اجرا می کنید، به این معنی است که URL های ذخیره شده در CMS یا الگو را به جای بازنویسی در مرورگر تصحیح کنید. اگر نمی توانید منبع را تغییر دهید، محتوای ترکیبی را به عنوان یک شکاف شناخته شده ضبط کنید، زیرا قفل صفحه ای که منابع متن ساده را می کشد یک سیگنال نادرست است.

مرحله 4: HSTS چه چیزی اضافه می کند و چه چیزی اضافه نمی کند

HSTS یک خط‌مشی سایت است تا ترجیح مرورگر، و تنها مکانیزمی است که در اینجا از http:// تایپ‌شده در نمایه‌ای تازه باقی می‌ماند. هنگامی که یک مرورگر یک هدر Strict-Transport-Security را برای یک میزبان دید، درخواست‌های بعدی را قبل از ارسال مجدد به https بازنویسی می‌کند، که دقیقاً همان خاصیت مورد نظر شما است. هیچ کاری برای میزبانی که مرورگر هرگز از آن بازدید نکرده است، و برای نام میزبان متفاوتی که همان برنامه کاربردی را ارائه می دهد، انجام نمی دهد.

بررسی کنید مبدا چه چیزی با curl -sSI https://example.com | grep -i strict-transport-security ارسال می‌کند. هدر گم شده یک تغییر سرور است و چیزی نیست که مشتری بتواند نصب کند. اگر وجود دارد، max-age را بخوانید و آیا includeSubDomains تنظیم شده است، زیرا حداکثر سن کوتاهی بین بازدیدها منقضی می‌شود و یک includeSubDomains از دست رفته، هر زیردامنه را بدون محافظت می‌گذارد. RFC 6797 تعریف می‌کند که یک عامل کاربر چگونه این خط‌مشی را اعمال می‌کند و چه مواردی را ممکن است نادیده بگیرد. پیش بارگذاری یک تعهد جداگانه است، بنابراین قبل از اینکه به کسی قول بدهید که یک دامنه در لیست است، وضعیت را از طریق API hstspreload.org بررسی کنید.

تأیید و بازگشت

بازگشت برای تنظیمات مشتری ارزان و برای HSTS گران است. خاموش کردن حالت فقط HTTPS رفتار قبلی را بلافاصله بازیابی می کند؛ حداکثر سن طولانی اینطور نیست و بازدیدکنندگانی که قبلاً آن را دریافت کرده‌اند به ارتقای آن ادامه می‌دهند تا زمانی که منقضی شود.

بنابراین قبل از اینکه کار را انجام دهید به ترتیب بررسی کنید. بارگیری مجدد از یک حافظه پنهان سرد و تأیید کنید که اولین درخواست در پانل شبکه https بدون تغییر مسیر قبلی است. سپس یک زیر دامنه را بررسی کنید، زیرا includeSubDomains جایی است که معمولاً این خط‌مشی‌ها محدودتر از حد تصور می‌شوند. سپس صفحه‌ای را بررسی کنید که دارایی‌های شخص ثالث را جذب می‌کند، زیرا محتوای مختلط شکستی است که در هر اصلاح دیگری باقی می‌ماند.

اگر بعد از همه اینها درخواست اول همچنان http باشد، مشتری دیگر متغیر نیست: پیوندی که افراد روی آن کلیک می‌کنند همین است. مکان‌هایی را که کنترل می‌کنید برای فرم http نام میزبان جستجو کنید، آن‌ها را به‌روزرسانی کنید و با همان بارگذاری مجدد حافظه پنهان، مجدداً آزمایش کنید. سؤال VPN را در سرتاسر جداگانه نگه دارید، زیرا تونل تغییر می کند که چه کسی می تواند درخواست را ببیند و هرگز تغییر نمی دهد که آیا درخواست رمزگذاری شده است. خطی که باید در بلیط قرار دهید این است که اولین درخواست مهم است و تغییر مسیر فقط رسید برای درخواستی است که قبلاً ارسال شده است.