ไฟล์ DH หรือคีย์ tls-auth? แยกไฟล์ OpenVPN สองไฟล์ให้ถูก

สองไฟล์ สองไดเรกทีฟ และนิสัยที่ตั้งชื่อทั้งคู่ตามสิ่งที่มันกำหนดค่า นั่นคือวิธีที่ dh.pem ไปอยู่ในบรรทัด tls-auth แล้วไคลเอนต์ล้มเหลวพร้อมข้อความเรื่องรูปแบบคีย์ที่ไม่คาดคิด การตัดสินใจตรงหน้าคุณไม่ใช่ว่าไฟล์ไหนแข็งแรงกว่า แต่คือบทบาทไหนที่การติดตั้งต้องการจริง ๆ และสามเงื่อนไขเป็นตัวตัดสิน: TLS สแตกของคุณจะเจรจาการแลกเปลี่ยนคีย์แบบใด คุณต้องการการพิสูจน์ตัวตนของช่องสัญญาณควบคุมหรือไม่ และวัสดุต้องเป็นความลับหรือไม่

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

อ่านป้ายก่อนชื่อไฟล์

บรรทัดแรกของไฟล์ให้ข้อมูลมากกว่าชื่อ เพราะชื่อเป็นธรรมเนียมของมนุษย์ ส่วนป้ายนั้นเครื่องมือเป็นผู้สร้าง พารามิเตอร์ Diffie-Hellman มีป้าย PEM BEGIN DH PARAMETERS คีย์แบบคงที่ของ OpenVPN เป็นโครงสร้างคนละแบบเลย มีหัวของตัวเองและเพย์โหลดฐานสิบหก

การเปลี่ยนชื่อไม่ได้แปลงอะไร ไฟล์พารามิเตอร์ที่ชื่อ ta.key ก็ยังเป็นพารามิเตอร์ และคีย์คงที่ที่ชื่อ dh.pem ก็ยังเป็นคีย์คงที่ ตัวแยกวิเคราะห์อ่านเนื้อหาและปฏิเสธความไม่ตรงกัน ตรวจก่อนแก้โปรไฟล์:

head -n 1 dh.pem
head -n 1 ta.key

สามเงื่อนไขที่กำหนดว่าคุณต้องใช้ไฟล์ไหน

เงื่อนไขแรกคือการแลกเปลี่ยน การจับมือ Diffie-Hellman ในฟิลด์จำกัดต้องมีกลุ่ม และไดเรกทีฟ dh คือที่ที่เซิร์ฟเวอร์ระบุพารามิเตอร์ให้มัน การจับมือบนเส้นโค้งวงรีไม่ต้องใช้ไฟล์นั้นเลย เพราะเส้นโค้งคือชุดพารามิเตอร์เอง ถ้าเซิร์ฟเวอร์ของคุณเจรจาเฉพาะชุด ECDHE ไฟล์ DH ก็เป็นภาระตายไม่ใช่กำลังเพิ่ม

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

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

สร้างวัสดุที่ถูกต้องสำหรับแต่ละบทบาท

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

openvpn --genkey tls-auth ta.key

คำสั่งนั้นสร้างวัสดุลับใหม่ ไม่ได้ซ่อมแซมหรือตรวจสอบคีย์ที่มีอยู่ และการเรียกซ้ำจะให้คีย์อื่นที่ฝ่ายอื่นไม่มี คัดลอกไฟล์ที่ได้ไปยังฝ่ายที่ต้องการผ่านช่องทางที่คุณใช้สำหรับความลับร่วมใด ๆ และรักษาธรรมเนียมทิศทางให้สม่ำเสมอ: กับ tls-auth ฝ่ายหนึ่งใช้ key-direction 0 และอีกฝ่ายใช้ key-direction 1

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

dh none หมายถึงอะไรและไม่หมายถึงอะไร

dh none เป็นไดเรกทีฟจริงที่มีความหมายแคบ: จะไม่มีไฟล์พารามิเตอร์ฟิลด์จำกัดถูกโหลด เพราะการจับมือใช้ Diffie-Hellman บนเส้นโค้งวงรี มันไม่ใช่คำย่อของ «ข้ามขั้น DH» ในความหมายของการทำให้อะไรอ่อนลง และแน่นอนไม่ได้บอกให้ OpenVPN ยอมรับไฟล์อื่นแทน

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

ถ้าไฟล์ผิดถูกติดตั้งไปแล้ว

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

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

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