ความพยายาม VPN ผิด: ข้อมูลรับรองประเภทใดข้ามเส้นเขต?

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

หยุดและเก็บหลักฐานไว้

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

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

อะไรข้ามเขตได้

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

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

การพิสูจน์กุญแจไม่ใช่การอัปโหลดกุญแจ

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

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

รหัสผ่านตามแบบจำลองความเชื่อใจที่ต่างออกไปทั้งหมด ตัวรวมศูนย์ที่ตั้งค่ากับตัวตรวจสอบภายนอกอาจส่งค่าที่ส่งเข้ามาต่อไปได้ ดังนั้นการรับมันจึงเป็นหน้าที่ที่ตั้งใจ และปลายทางที่ผิดคือการเปิดเผยจริงไม่ใช่เชิงทฤษฎี

สร้างความพยายามขึ้นใหม่จากล็อก

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

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

grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30

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

ตัดสินใจ แล้วจึงลงมือ

การตัดสินใจมาจากหลักฐาน ไม่ใช่ว่าความล้มเหลวดูน่าตกใจแค่ไหน อ่านสี่แถวเทียบกับข้อเท็จจริงที่คุณสร้างขึ้นใหม่:

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

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