ใบรับรอง VPN แบบลงนามเอง: หมายความว่าอะไร และเชื่อถืออะไร

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

ใบรับรองไม่ใช่ที่เก็บความเชื่อถือ

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

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

ตัวเลือก ca ของ OpenVPN เป็นกรณีที่ชัดที่สุดของความเชื่อถือที่จำกัดเฉพาะแอป ไฟล์นั้นระบุสมอที่ไคลเอนต์จะยอมรับ และอาจมี CA ส่วนตัวหนึ่งตัว หรือในการติดตั้งขนาดเล็กจะมีใบรับรองแบบลงนามเองของเซิร์ฟเวอร์เอง เวอร์ชัน 2.6 ยังยอมรับ --peer-fingerprint สำหรับการปักหมุดลายนิ้วมือ SHA-256 แทนการแจกจ่ายไฟล์ CA WireGuard อยู่ไกลกว่านั้นอีก มันไม่มีใบรับรองเลย มีเพียงกุญแจสาธารณะแบบคงที่ต่อเพียร์หนึ่งตัว ดังนั้นคำถามเรื่องการลงนามเองจึงไม่ใช้กับมัน

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

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

บน Debian หรือ Ubuntu การวางไฟล์ใน /usr/local/share/ca-certificates/ และเรียกใช้ update-ca-certificates จะเปลี่ยนชุดทั้งระบบ บน Windows certutil -addstore -f Root เขียนลงที่เก็บของเครื่องและต้องใช้พรอมต์ที่ยกระดับ ขณะที่การเพิ่ม -user จะกำหนดเป้าหมายที่เก็บของผู้ใช้ปัจจุบันแทน ทั้งสองใช้แทนกันไม่ได้ Firefox เก็บฐานข้อมูล NSS ของตัวเอง ดังนั้นการนำเข้าที่ระดับระบบปฏิบัติการอาจไม่ปรากฏที่นั่นเลย

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

คุณยังคงเข้ารหัสโดยไม่มี CA สาธารณะ

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

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

การเชื่อถือผู้ออกไม่ได้ข้ามการตรวจสอบชื่อ

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

OpenVPN ทำให้การแยกมองเห็นได้ verify-x509-name ปักหมุดหัวเรื่องที่คาดไว้ผ่านการจับคู่ name, name-prefix หรือ subject remote-cert-tls server กำหนดให้ใบรับรองของเพียร์ใช้เป็นใบรับรองเซิร์ฟเวอร์ได้ ซึ่งปฏิเสธใบรับรองเฉพาะไคลเอนต์แม้ผู้ออกจะได้รับความเชื่อถือ ไม่มีการตั้งค่าใดถูกแทนที่ด้วยการส่งไฟล์ CA

ตรวจสอบใบรับรองก่อนตัดสินใจอะไร:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName แสดงว่าใครออกให้ สำหรับชื่อใด และถึงเมื่อใด
• openssl verify -CAfile ca.crt server.crt ตรวจสอบว่าห่วงโซ่ที่คุณจะส่งนั้นตรวจสอบใบได้จริงหรือไม่
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error ใช้ได้กับปลายทาง TLS เช่นพอร์ทัลเว็บ โปรโตคอล OpenVPN บนพอร์ต 1194 ไม่ใช่สตรีม TLS ธรรมดา การทดสอบนั้นจึงไม่ใช้ที่นั่น

ใบรับรองที่วันหมดอายุ ไม่มี subjectAltName สำหรับชื่อที่คุณเชื่อมต่อ หรือไม่มีการใช้ serverAuth จะล้มเหลวไม่ว่าจะติดตั้งสมออย่างระมัดระวังเพียงใด

ห้าการตรวจสอบก่อนยอมรับหนึ่งใบ

เปรียบเทียบลายนิ้วมือผ่านช่องทางที่ไม่ใช่การเชื่อมต่อที่คุณพยายามซ่อม เช่น คอนโซล ตัวติดตั้งที่คุณมีอยู่แล้ว ไฟล์การกำหนดค่าที่ลงนาม openssl x509 -in server.crt -noout -fingerprint -sha256 บนเซิร์ฟเวอร์และค่าเดียวกันในบันทึกของไคลเอนต์เพียงพอที่จะรู้ว่าคุณกำลังดูวัตถุชิ้นเดียว

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

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

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