ทำไม openssl rand สร้างคีย์ที่ tls-crypt ต้องการไม่ได้

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

ไฟล์บนดิสก์ต้องเป็นอะไรกันแน่

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

ออบเจกต์ชนิดเดียวกันนี้ให้บริการทั้งสองฟีเจอร์ของช่องควบคุม ด้วย tls-auth แต่ละเพียร์ยังต้องมีทิศทางเพื่อไม่ให้แพ็กเก็ตของฝ่ายหนึ่งสะท้อนกลับมาที่มัน ด้วย tls-crypt ความลับร่วมเพียงตัวเดียวเข้ารหัสและพิสูจน์ตัวตนช่องควบคุมทั้งสองทิศทาง ซึ่งซ่อนแฮนด์เชกและปกป้องมันไปพร้อมกัน

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

วิธีที่รองรับในการสร้างขึ้นมาหนึ่งไฟล์

สร้างคีย์แบบสถิตธรรมดาด้วยเครื่องมือที่จะใช้งานมัน แล้วอ้างอิงจากทั้งสองฝั่ง:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

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

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

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

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

จุดที่ไบต์ที่ทำด้วยมือพังทลาย

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

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

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

หมุนเวียนโดยไม่ล็อกทุกคนออก

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

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

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