OpenConnect เปลี่ยนคุกกี้ล็อกอินให้เป็นอุโมงค์ได้อย่างไร?

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

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

ไคลเอนต์และเกตเวย์แลกเปลี่ยนอะไรกัน ตามลำดับ

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

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

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

คุกกี้เป็นตัวพาเซสชัน ไม่ใช่กุญแจ

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

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

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

ส่งต่อคุกกี้โดยไม่ทิ้งสำเนา

การส่งต่อเชิงกลไกที่ปลอดภัยที่สุดบน Linux คืออินพุตมาตรฐาน --cookie-on-stdin อ่านค่าจาก stdin คุกกี้จึงไม่ปรากฏในรายการอาร์กิวเมนต์ของโปรเซส ซึ่งผู้ใช้ในเครื่องคนใดก็อ่านได้ด้วย ps ท่อส่งที่พิสูจน์ตัวตนในโปรเซสหนึ่งและป้อนอุโมงค์ในอีกโปรเซสหนึ่งเก็บค่าไว้ในท่อแทนที่จะเป็นไฟล์หรือตัวแปรสภาพแวดล้อม

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

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

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

การตรวจสอบและการหมดอายุในขั้นตอนที่สอง

ขั้นตอนที่สองยังต้องตรวจสอบเซิร์ฟเวอร์ FINGERPRINT ที่ --authenticate พิมพ์ออกมาคือการตรึงใบรับรองในรูปแบบ pin-sha256: และการส่งต่อไปยังการเรียกอุโมงค์ด้วย --servercert จะตรึงการตรวจสอบไว้กับเกตเวย์ที่คุณพิสูจน์ตัวตนด้วย การปิดการตรวจสอบใบรับรองเพื่อให้สคริปต์ง่ายขึ้นจะลบหลักฐานเดียวที่ว่าคุกกี้ถูกส่งไปยังโฮสต์ที่ตั้งใจไว้

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

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