ไฟล์ P12 เก่าล้มเหลวบน OpenSSL 3: รหัสผ่านผิดหรือไซเฟอร์เก่า?
แยกแยะรหัสผ่านที่พิมพ์ผิดออกจากบันเดิล RC2 เก่าที่ OpenSSL 3 ปฏิเสธที่จะแตกไฟล์ แล้วปิดผนึกไฟล์ใหม่โดยไม่ถอดการป้องกันคีย์
ไดอะล็อกนำเข้าใช้รหัสผ่านของคุณ หมุนสักครู่แล้วบอกว่าอ่านบันเดิลไม่ได้ ข้อความนั้นไม่ได้บอกว่าคุณพิมพ์รหัสผ่านผิดหรือไฟล์ถูกปิดผนึกด้วยไซเฟอร์ที่ไคลเอนต์ไม่รองรับแล้ว สองกรณีนี้เป็นความล้มเหลวต่างกันและวิธีแก้ก็ต่างกัน การเลือกผิดจะนำไปสู่การดาวน์เกรดไคลเอนต์ซึ่งเพียงเลื่อนการตัดสินใจออกไป การดูว่าไคลเอนต์หยุดที่ขั้นตอนใดแยกสองกรณีนี้ได้ในราวหนึ่งนาที
สิ่งที่เกิดขึ้นระหว่างไดอะล็อกกับรายการใบรับรอง
ไฟล์ .p12 เป็นคอนเทนเนอร์ ไม่ใช่ใบรับรอง ข้างในมีถุงใบรับรองหนึ่งถุงหรือมากกว่า และถุงคีย์ส่วนตัวที่เข้ารหัสด้วยคีย์ที่ได้มาจากรหัสผ่านของคุณ พร้อมการตรวจสอบความสมบูรณ์ที่เรียกว่า MAC ทั่วทั้งไฟล์ การเปิดจึงหมายถึงการตรวจสอบ MAC นั้น ถอดรหัสถุงคีย์ และจับคู่ใบรับรองกับคีย์ที่ได้ออกมา
ปัญหาของรหัสผ่านเกิดที่ขั้นตอน MAC ปัญหาของไซเฟอร์เกิดช้ากว่า เมื่อต้องแกะถุงคีย์และไบนารีที่แกะไม่มีการรองรับอัลกอริทึมที่ระบุไว้ในไฟล์
กรณีที่สองพบได้บ่อยในระบบปัจจุบันเพราะ OpenSSL 3 ย้ายกลุ่มอัลกอริทึมเก่าไปไว้ใน legacy provider ที่เป็นตัวเลือก บันเดิลที่ส่งออกโดย OpenSSL 1.x มักปิดผนึกใบรับรองด้วย RC2 ขนาด 40 บิต และคีย์ส่วนตัวด้วย Triple DES แบบสามคีย์ ไบนารี OpenSSL 3 ตามค่าเริ่มต้นยังตรวจสอบ MAC ด้วยรหัสผ่านที่ถูกต้องแล้วจึงล้มเหลวที่ถุงคีย์ ดังนั้นรหัสผ่านไม่เคยผิดและการพิมพ์ใหม่จึงไม่เปลี่ยนอะไร
อ่านคอนเทนเนอร์โดยไม่เขียนคีย์ออกมา
ขอให้ไบนารี OpenSSL บนเครื่องของคุณแยกวิเคราะห์ไฟล์และอ่านจุดที่มันยอมแพ้ การตรวจสอบโดยไม่มีไฟล์เอาต์พุตทำให้คีย์ยังเข้ารหัสอยู่บนดิสก์ และนั่นเป็นเหตุผลเดียวที่ขั้นตอนนี้ปลอดภัยบนโฮสต์ที่ใช้ร่วมกัน
openssl pkcs12 -in vpn-identity.p12 -info -nooutบนบันเดิลเก่าที่มีรหัสผ่านถูกต้อง คำสั่งนี้จะพิมพ์แอตทริบิวต์ของถุงแล้วหยุดด้วย digital envelope routines::unsupported หากรหัสผ่านผิดคุณจะได้ Mac verify error: invalid password? ก่อนที่จะมีการอ่านถุงใด ๆ ข้อความสองแบบชี้ไปคนละทาง ซึ่งเป็นข้อมูลที่ไคลเอนต์ปิดบังไว้พอดี
ถ้าความล้มเหลวเป็นแบบอัลกอริทึมที่ไม่รองรับ ให้รันคำสั่งเดิมอีกครั้งโดยเพิ่ม -legacy และไม่เปลี่ยนอย่างอื่น แฟล็กนั้นโหลด legacy provider สำหรับโปรเซสนั้นเพียงครั้งเดียว มันไม่ได้ทำให้ไคลเอนต์ VPN แยกวิเคราะห์บันเดิลเก่า ไม่ได้แตะนโยบายคริปโตทั้งระบบ และเป็นการวัดผลไม่ใช่การซ่อม เพราะไฟล์ยังต้องถูกแทนที่
ข้อผิดพลาดใดหมายถึงขั้นตอนใด
ตารางสั้น ๆ แยกผลลัพธ์สามอย่างออกจากกัน และถ้อยคำสำคัญกว่าตำแหน่งที่ไดอะล็อกปรากฏ
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
ข้อความอย่าง not enough data หรือ header too long ไม่ได้อยู่ในสองกลุ่มแรก นั่นคือปัญหาเรื่องรูปแบบ ไฟล์ DER ที่เปลี่ยนชื่อเป็น .pem สำเนาที่โปรแกรมแก้ไขเขียนบรรทัดจบใหม่จนเสีย หรือการดาวน์โหลดที่ไม่ครบ ให้เทียบเช็กซัมกับที่ผู้ออกส่งมาก่อนจะเริ่มดูไซเฟอร์
ถือว่า Mac verify error เป็นหลักฐานเกี่ยวกับรหัสผ่านเท่านั้น มันหมายความว่า MAC ที่คำนวณจากสิ่งที่คุณพิมพ์ไม่ตรงกับค่าที่จัดเก็บ ซึ่งเกิดจากการพิมพ์ผิด รหัสผ่านที่แคชจากการนำเข้าครั้งก่อน หรือไฟล์ที่ส่งออกใหม่ภายใต้รหัสผ่านอื่น มันไม่ได้บอกว่าอัลกอริทึมข้างในเก่าหรือไม่
สร้างบันเดิลที่ไคลเอนต์เปิดได้จริง
เมื่อตัวแยกวิเคราะห์ legacy ยืนยันว่าไฟล์สมบูรณ์ วิธีแก้ที่ยั่งยืนคือไฟล์แทนที่มีอัลกอริทึมที่ไคลเอนต์เป้าหมายรองรับ ได้แก่ AES-256-CBC สำหรับถุงคีย์และใบรับรอง PBKDF2 ที่ใช้ SHA-256 สำหรับการอนุมาน และ SHA-256 สำหรับ MAC ผู้ดูแล PKI ของคุณส่งออกได้จากวัสดุคีย์เดียวกัน และใบรับรองข้างในยังเป็นใบที่เซิร์ฟเวอร์ของคุณไว้วางใจอยู่แล้ว
เมื่อต้องแปลงในเครื่อง ให้ขอให้เครื่องมือ pkcs12 ปิดผนึกถุงใหม่แทนที่จะทิ้งถุงออกมาก่อน เก็บรหัสผ่านทั้งสองไว้นอกประวัติเชลล์โดยอ่านจากไฟล์
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passการแปลงที่สำเร็จไม่ได้บอกอะไรเกี่ยวกับวันหมดอายุ การใช้งานคีย์ การจับคู่คีย์ส่วนตัว หรือว่าเซิร์ฟเวอร์ไว้วางใจห่วงโซ่ผู้ออกหรือไม่ การบรรจุใหม่เป็นการเปลี่ยนการขนส่ง ไม่ใช่การต่ออายุ และแต่ละข้อก็ยังต้องตรวจของตัวเอง
ข้ามสูตรใด ๆ ที่ เขียนคีย์กลางที่ไม่มีการป้องกัน หรือรหัสผ่านเอาต์พุตว่าง เพียงเพราะไคลเอนต์ยอมรับไฟล์ในภายหลัง บันเดิลที่อ่านได้แต่ถูกถอดการป้องกันเป็นผลลัพธ์ที่แย่กว่าความล้มเหลวในการนำเข้าที่คุณเริ่มต้น
ยืนยันว่าไคลเอนต์นำเข้าไฟล์ที่คุณสร้าง
การแยกวิเคราะห์ที่สะอาดในเทอร์มินัลพิสูจน์ว่าคอนเทนเนอร์ถูกต้อง แต่ไม่ได้พิสูจน์ว่าไคลเอนต์เลือกมัน เพราะโปรไฟล์ที่ค้างอยู่อาจยังชี้ไปที่ไฟล์เก่า และไคลเอนต์บางตัวแคชตัวตนที่นำเข้าไว้ภายใต้ชื่อที่คุณไม่ได้เลือก
พิมพ์ตัวตนที่คุณกำลังจะนำเข้าและเทียบกับสิ่งที่ไคลเอนต์แสดงในมุมมองใบรับรอง
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256ลบรายการโปรไฟล์เก่าออกก่อนแล้วจึงนำเข้า ถ้าไคลเอนต์บันทึกหัวเรื่องหรือลายนิ้วมือที่โหลด ให้เทียบกับบรรทัดด้านบน ถ้ามันแสดงเพียงชื่อที่อ่านง่าย ให้ตรวจวันหมดอายุแทน เพราะสับสนกับใบรับรองอื่นจากผู้ออกเดียวกันได้ยากกว่า
เอกสารอ้างอิง PKCS12 ระบุ provider รหัสผ่าน และตัวเลือกเอาต์พุตที่ใช้ที่นี่ การเก็บ legacy provider ไว้นอกสภาพแวดล้อมของไคลเอนต์คือประเด็น วัดด้วยมัน ส่งมอบโดยไม่มีมัน และปล่อยให้คีย์ส่วนตัวได้รับการป้องกันบนดิสก์