การยืนยันตัวตน HTTPS Basic เทียบกับ IPsec: แต่ละอย่างปกป้องอะไร

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

จุดตรวจที่หนึ่ง: นี่คือเซิร์ฟเวอร์ที่คุณตั้งใจจะคุยด้วยหรือไม่

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

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

จุดตรวจที่สอง: อะไรเดินทางจริงในการแลกเปลี่ยน 401

การยืนยันตัวตนแบบ HTTP Basic ส่งตัวระบุผู้ใช้และรหัสผ่านในส่วนหัว เข้ารหัสด้วย Base64 ตามที่อธิบายใน RFC 7617 Authorization: Basic dXNlcjpwYXNz คือรูปแบบของมัน การเข้ารหัสย้อนกลับได้โดยใครก็ตามที่อ่านคำขอได้ ความลับทั้งหมดจึงมาจากการรับส่งที่อยู่ข้างใต้ curl -v แสดงทั้งข้อท้าทาย WWW-Authenticate: Basic และส่วนหัวที่คุณส่งกลับ

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

อุโมงค์ IPsec อยู่ตรงไหนในเส้นทางนั้น

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

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

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

อ่านความล้มเหลวที่ชั้นซึ่งรายงานมัน

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

ใช้หลักฐานที่แต่ละชั้นสร้างขึ้น แผงเครือข่ายของเบราว์เซอร์สำหรับสถานะและส่วนหัว openssl s_client -connect host:443 สำหรับห่วงโซ่ใบรับรอง ตัวนับ SA และบันทึกของเกตเวย์สำหรับทราฟฟิกอุโมงค์ และบันทึกของแอปสำหรับการตัดสินบัญชี เมื่อสองชั้นรายงานข้อผิดพลาดพร้อมกัน ให้แก้ชั้นล่างก่อน เพราะอุโมงค์ที่ตายแล้วสามารถบดบังความล้มเหลวในการยืนยันตัวตนได้ง่าย และในทางกลับกันก็เช่นกัน

ทำแผนที่บริการหนึ่งรายการตั้งแต่ต้นจนจบ

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

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

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