วิธีทำให้ 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 สร้างลำดับเดียวกันภายนอกเบราว์เซอร์และพิมพ์ URL ที่คุณไป

ผลลัพธ์เป็นไปได้สองประการและต้องการการแก้ไขที่แตกต่างกัน หากไซต์ให้บริการ HTTPS บนโฮสต์เดียวกัน การแก้ไขคือการหยุดเผยแพร่แบบฟอร์ม HTTP: อัปเดตบุ๊กมาร์ก ลิงก์ Wiki ทางลัดบนเดสก์ท็อป และเทมเพลตอีเมลที่ผู้คนคลิก หากไซต์ไม่ให้บริการ HTTPS เลย การตั้งค่าเบราว์เซอร์จะไม่สร้างไซต์นั้นขึ้นมา และคำตอบที่ตรงไปตรงมาก็คือปลายทางคือปัญหา อย่าจดบันทึกในกรณีที่สองโดยมีข้อยกเว้น เนื่องจากข้อยกเว้นใบรับรองในหน้าบัญชีจะแปลงปัญหาการขนส่งให้เป็นปัญหาข้อมูลประจำตัว จดบันทึกว่าคุณอยู่ในกรณีใดก่อนที่คุณจะแตะการตั้งค่า

ขั้นตอนที่ 2: เปิดโหมด HTTPS เท่านั้นของเบราว์เซอร์

โหมดอัปเกรดเป็นส่วนที่สอง และโหมดไม่สามารถใช้แทนกันได้ ตรวจสอบสิ่งที่คุณทำก่อนที่จะเปิดใช้งาน: อัปเกรดโดยไม่ต้องแจ้งให้ทราบ อัปเกรดโดยมีคำเตือน หรือปฏิเสธที่จะโหลด

ใน Firefox การควบคุมอยู่เบื้องหลัง about:config และในหน้าการตั้งค่าความเป็นส่วนตัว โดยมี dom.security.https_only_mode เป็นสวิตช์และข้อยกเว้นต่อไซต์ที่จัดการจากเมนูแม่กุญแจ ใน Chrome และ Edge แนวคิดเดียวกันนี้อยู่ภายใต้การตั้งค่า ความเป็นส่วนตัวและความปลอดภัย ความปลอดภัย ซึ่งมีป้ายกำกับว่า ใช้การเชื่อมต่อที่ปลอดภัยเสมอ ไม่ว่าป้ายกำกับจะเป็นเช่นไร ให้ตรวจสอบลักษณะการทำงานกับโฮสต์ที่ตอบเฉพาะบนพอร์ต 80 เท่านั้น เนื่องจากโหมดที่อัปเกรดแล้วถอยกลับอย่างเงียบๆ ไม่ใช่การป้องกันที่คุณคิดว่าคุณเปิดใช้งาน เอกสาร Firefox เฉพาะ HTTPS เท่านั้น อธิบายลักษณะการอัปเกรด คำเตือน และข้อยกเว้นสำหรับเบราว์เซอร์นั้น

ขั้นตอนที่ 3: แก้ไขทรัพยากร ไม่ใช่แค่แถบที่อยู่

เมื่อการอัปเกรดล้มเหลว ให้อ่านข้อผิดพลาดทั้งหมดแทนการอ่านแถบที่อยู่ โฮสต์ที่ไม่มีตัวฟัง HTTPS ชื่อโฮสต์ที่ไม่ตรงกับใบรับรองและเชนที่หมดอายุจะสร้างข้อความที่แตกต่างกันและเป็นของเจ้าของที่แตกต่างกัน เฉพาะอย่างแรกคือช่องว่างฝั่งเซิร์ฟเวอร์ ส่วนที่สองมักเป็นบุ๊กมาร์กที่ไม่เคยอัปเดต ปัญหาที่สามคือปัญหาการต่ออายุที่ไม่เกี่ยวข้องกับการเชื่อมต่อ VPN

อย่าเพิ่มข้อยกเว้นใบรับรองลงในไซต์บัญชีเนื่องจาก VPN เปิดอยู่ ข้อยกเว้นจะปิดใช้งานการตรวจสอบที่จะตรวจจับการสกัดกั้นที่ VPN มีไว้เพื่อป้องกันอย่างแน่นอน

ส่วนที่สามอยู่ในหน้า และเป็นส่วนที่ผู้คนคิดถึง หน้าที่โหลดผ่าน HTTPS ยังสามารถดึงรูปภาพ แบบอักษร หรือสคริปต์จาก http URL ได้ และเบราว์เซอร์จะบล็อกหรือดาวน์เกรดตัวบ่งชี้ความปลอดภัยสำหรับทั้งหน้า ตรวจสอบคำขอที่ล้มเหลวในแผงเครือข่ายและแก้ไขการอ้างอิงทรัพยากรที่เจ้าของ แทนที่จะคิดว่าแถบที่อยู่อธิบายทุกคำขอ บนไซต์ที่คุณใช้งาน นั่นหมายถึงการแก้ไข 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 กำหนดวิธีที่ตัวแทนผู้ใช้ใช้นโยบายและสิ่งที่อาจเพิกเฉย การโหลดล่วงหน้าเป็นข้อผูกพันแยกต่างหาก ดังนั้นโปรดตรวจสอบสถานะผ่าน hstspreload.org API ก่อนที่จะสัญญากับใครก็ตามว่าโดเมนอยู่ในรายการ

การตรวจสอบและการย้อนกลับ

การย้อนกลับมีราคาถูกสำหรับการตั้งค่าไคลเอนต์ และมีราคาแพงสำหรับ HSTS การปิดโหมด HTTPS เท่านั้นจะคืนค่าพฤติกรรมก่อนหน้าทันที อายุสูงสุดที่ยาวนานจะไม่เกิดขึ้น และผู้เยี่ยมชมที่ได้รับมันแล้วจะอัปเกรดต่อไปจนกว่าจะหมดอายุ

ดังนั้นโปรดตรวจสอบตามลำดับก่อนที่จะเรียกให้เสร็จสิ้น โหลดซ้ำจากแคชเย็นและยืนยันว่าคำขอแรกในแผงเครือข่ายคือ https โดยไม่มีการเปลี่ยนเส้นทางก่อนหน้า จากนั้นตรวจสอบโดเมนย่อย เนื่องจาก includeSubDomains เป็นที่ที่นโยบายเหล่านี้มักจะแคบกว่าที่คิดไว้ จากนั้นตรวจสอบหน้าหนึ่งที่ดึงเนื้อหาของบุคคลที่สาม เนื่องจากเนื้อหาแบบผสมคือความล้มเหลวที่จะรอดพ้นจากการแก้ไขอื่นๆ

หากคำขอแรกยังคงเป็น http หลังจากทั้งหมดนั้น ไคลเอนต์ก็ไม่ใช่ตัวแปรอีกต่อไป: ลิงก์ที่ผู้ใช้คลิกคือตัวแปร ค้นหาตำแหน่งที่คุณควบคุมด้วยรูปแบบ http ของชื่อโฮสต์ อัปเดต และทดสอบอีกครั้งด้วยการโหลด แคชเย็นชุดเดิมอีกครั้ง แยกคำถาม VPN ออกจากกันตลอด เนื่องจาก ช่องสัญญาณจะเปลี่ยนผู้ที่สามารถดูคำขอ และไม่เคยเปลี่ยนว่าคำขอนั้นเข้ารหัสหรือไม่ บรรทัดที่ต้องใส่ในตั๋วคือคำขอแรกคือคำขอที่สำคัญ และการเปลี่ยนเส้นทางเป็นเพียงใบเสร็จรับเงินสำหรับคำขอที่ส่งไปแล้ว