ใบรับรอง VPN ไม่ได้ปกป้องส่วน LDAP

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

ความไม่สมมาตรนั้นคือกลไกเบื้องหลังการเข้าสู่ระบบที่ดูเหมือนเข้ารหัสแต่ยังส่งรหัสผ่าน bind แบบเปิดเผย

สองการเชื่อมต่อ สองการตัดสินใจเรื่องความเชื่อถือ

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

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

StartTLS กับ LDAPS เลือกอย่างตั้งใจ

StartTLS เปิดเป็น LDAP ธรรมดาแล้วยกระดับในที่เดิม โดยปกติอยู่ที่พอร์ต 389 ส่วน LDAPS เริ่ม TLS พร้อมกับการเชื่อมต่อ โดยปกติอยู่ที่ 636 ทั้งสองวิธีถูกต้องและอะแดปเตอร์ต้องตรงกับสิ่งที่ไดเรกทอรีเสนอ การกำหนดให้ต้องใช้ StartTLS ต่างจากการลองใช้แล้วดำเนินการต่อเมื่อการยกระดับล้มเหลว และช่องว่างนั้นเองที่รหัสผ่าน bind อาจหลุดออกไป ตั้งค่าโหมดเข้มงวดและอย่าอนุญาตเส้นทางสำรองที่ไม่มีการปกป้องสำหรับ bind ด้วยรหัสผ่าน

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

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

ไคลเอนต์ LDAP อ่านที่เก็บความเชื่อถือใด

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

ปลายทางสำรองทุกแห่งต้องเป็นไปตามนโยบายระบุตัวตนเดียวกัน สภาพแวดล้อมที่ตรวจสอบฝั่งหลักแต่ไม่ตรวจสอบฝั่งรองนั้นแย่กว่าการไม่มีทางสำรอง เพราะเส้นทางที่อ่อนแอกว่าจะถูกค้นพบเฉพาะระหว่างเหตุขัดข้อง

บัญชี bind ยังคงเป็นปัญหาแยกต่างหาก

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

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

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