พร็อกซี HTTPS หมายถึงการเชื่อมต่อ TLS สองเส้น ไม่ใช่เส้นเดียว

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

สองคู่ปลายทาง สองการตรวจสอบ

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

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

มองทั้งสองเป็นการเชื่อมต่อสองเส้นที่บังเอิญใช้ซ็อกเก็ตเดียวกัน เพราะนั่นคือสิ่งที่มันเป็น

CONNECT สร้างอุโมงค์อะไรจริง ๆ

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

ความต่างข้อนี้คือข้อโต้แย้งด้านความปลอดภัยทั้งหมดของโหมดอุโมงค์ และก็เป็นข้อจำกัดของมันด้วย

พร็อกซี HTTP ที่ไม่มี TLS ในช่วงที่ผ่านพร็อกซียังพาเว็บไซต์ HTTPS ผ่าน CONNECT ได้ การแลกเปลี่ยนระหว่างไคลเอนต์กับพร็อกซีเป็นข้อความธรรมดา ขณะที่การเชื่อมต่อกับเว็บไซต์ไม่ใช่ และการเรียกทั้งหมดว่า พร็อกซี HTTPS ก็กลบความต่างนี้

ใบรับรองใดล้มเหลว

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

curl แยกตัวเลือกออกจากกันด้วยเหตุนี้เอง ส่วนไฟล์ CA ของพร็อกซีกำหนดการตรวจสอบพร็อกซี ส่วนไฟล์ CA กำหนดการตรวจสอบเซิร์ฟเวอร์ และพฤติกรรมของที่เก็บความเชื่อถือที่ใช้ยังขึ้นอยู่กับวิธีที่ curl ถูกสร้างขึ้นด้วย

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

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

การตรวจสอบเนื้อหาเป็นการจัดวางอีกแบบ

การตรวจสอบ TLS ไม่ใช่การทำอุโมงค์ ตัวกลางที่ตรวจสอบจะยุติความสัมพันธ์ความเชื่อถือฝั่งเว็บไซต์และแสดงใบรับรองของตัวเองต่อไคลเอนต์ ไคลเอนต์จึงตรวจสอบตัวกลางแทนที่จะตรวจสอบเว็บไซต์ สิ่งนี้อาจชอบธรรมภายใต้การออกแบบที่ได้รับอนุมัติ และเป็นข้ออ้างที่ต่างอย่างมีนัยสำคัญจากการส่งต่อไบต์ต่อไบต์ อย่าสันนิษฐานว่าพร็อกซีทุกตัวตรวจสอบเนื้อหา และอย่าสันนิษฐานว่าช่วงที่ผ่านพร็อกซีถูกเข้ารหัสแล้วจะตัดความเป็นไปได้นั้นออก

CA ขององค์กรในที่เก็บความเชื่อถือของคุณเป็นเพียงเบาะแสว่าคุณอยู่ในการจัดวางแบบใด ไม่ใช่หลักฐาน จงถามถึงการออกแบบแทนที่จะอนุมานจากห่วงโซ่ใบรับรอง

การจัดวางทั้งสองให้คำตอบต่างกันต่อคำถามว่าใครอ่านหน้าเว็บได้

เปรียบเทียบพร็อกซีกับ VPN บนสี่บรรทัดเดียวกัน

การเปรียบเทียบจะมีประโยชน์ก็ต่อเมื่ออธิบายการติดตั้งทั้งสองแบบด้วยวิธีเดียวกัน

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

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