IKEv2 มีสองลายเซ็น: ใบรับรองและ IKE_AUTH
CA ลงนามในใบรับรอง และคู่ค้าลงนามในการแลกเปลี่ยน IKE_AUTH ด้วยรูปแบบของตนเอง อ่านแต่ละรายการจากฟิลด์ของมัน แล้วบันทึกทั้งสอง
ตั๋วของคุณระบุว่าใบรับรองเป็น SHA-256 ขณะที่บันทึกของเกตเวย์ระบุอัลกอริทึมลายเซ็นอื่น และมีคนร่างคำขอออก CA ใหม่ไว้แล้ว ก่อนคำขอนั้นจะถูกส่งไปที่ใด จงแยกสองลายเซ็นนี้: หนึ่งคือตราประทับของผู้้ออกบนกุญแจสาธารณะ อีกหนึ่งคือ หลักฐานของคู่ค้าว่าถือกุญแจส่วนตัวที่ตรงกันระหว่าง IKE_AUTH องค์ประกอบต่าง ๆ เป็นผู้เลือก และอนุญาตให้แตกต่างกันได้ การอ่านแต่ละรายการจากที่ที่มันอยู่ต้องใช้สองคำสั่งและหนึ่งตาราง
อ่านลายเซ็นของผู้้ออกจากใบรับรอง
CA วางลายเซ็นของตนบนความผูกพันระหว่างตัวตนกับกุญแจ ลายเซ็นนั้นบันทึกสิ่งที่ CA ทำตอนออก ไม่ใช่สิ่งที่ผู้รับจะทำตอนเชื่อมต่อ อัลกอริทึมของมันจึงอธิบายการเลือกแฮชและกุญแจของ CA เอง กุญแจของผู้รับชนิดหนึ่งสามารถอยู่ใต้กุญแจ CA อีกชนิดได้โดยไม่มีความขัดแย้งใด ๆ และการหมุนกุญแจ CA เป็นงานประจำไม่ใช่ข้อบกพร่อง อ่านสองฟิลด์แล้วคุณมีครึ่งหนึ่งของบัญชี:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"บันทึกทั้งสองป้ายเป็นรายการแยกกัน ป้ายแรกอธิบาย CA ป้ายที่สองอธิบายกุญแจของผู้รับ และไม่มีอันใดทำนายลายเซ็นออนไลน์ได้
อ่านลายเซ็นออนไลน์จากการแลกเปลี่ยน IKE
ระหว่างการพิสูจน์ตัวตน คู่ค้าแต่ละฝ่ายลงนามข้อมูลแลกเปลี่ยนด้วยกุญแจส่วนตัวของตน และอีกฝ่ายตรวจสอบหลักฐานนั้นกับตัวตน ห่วงโซ่ความเชื่อถือ และนโยบายของใบรับรอง ใน RSA การเติมและแฮชเป็นของรูปแบบออนไลน์นี้ กุญแจที่ยาวขึ้นหรือใบรับรอง SHA-256 ใหม่จึงเลือก RSA-PSS สำหรับลายเซ็นพิสูจน์ตัวตนเองไม่ได้ วิธีที่เจรจากันจะปรากฏในบันทึกของดีมอนหรือในรายการเชื่อมต่อ ไม่เคยอยู่ในใบรับรอง ถามแต่ละฝ่ายว่าเจรจาอะไรไว้ เพราะสองทิศทางอาจต่างกัน
ipsec statusall | grep -i "auth\|proposal"เมื่อฝ่ายหนึ่งระบุรูปแบบที่อีกฝ่ายสร้างไม่ได้ คุณพบความไม่ตรงกันที่ตั๋วพูดถึง การออก CA ใหม่เป็นการซ่อมที่ผิด เพราะสิ่งที่ล้มเหลวไม่ใช่ใบรับรอง
RFC 7427 เปลี่ยนอะไรและไม่เปลี่ยนอะไร
วิธีดั้งเดิมมีหมายเลขตามการผสมอัลกอริทึมใน RFC 7296 ส่วนขยายลายเซ็น RFC 7427 ที่มาทีหลังเพิ่มวิธี Digital Signature ทั่วไปพร้อมการส่งสัญญาณรองรับแฮชลายเซ็น แฮชใหม่จึงไม่ต้องมีหมายเลขวิธีของตัวเองอีก เป็นสิ่งที่เจรจากัน ไม่ใช่สมมติ：คู่ค้าไม่ได้ส่วนขยายเพราะไลบรารีของตนแยกวิเคราะห์ใบรับรองเดียวกันได้ และคู่ค้าที่ใช้วิธีดั้งเดิมเท่านั้นบังคับให้เกตเวย์เก็บวิธีใดวิธีหนึ่งไว้ นี่คือการแลกเปลี่ยนนโยบายที่มีต้นทุนความเข้ากันได้ ไม่ใช่ข้อบกพร่อง
การรองรับเป็นรายทิศทางและรายการเชื่อมต่อ จึงควรทดสอบบิลด์ที่อยู่ตรงหน้าคุณแทนที่จะเชื่อคำกล่าวอ้างระดับตระกูล เมทริกซ์ความสามารถที่เขียนเมื่อสามปีก่อนอธิบายบิลด์อายุสามปี
ใส่สี่แถวในบัญชี
บันทึกที่ยุติข้อโต้แย้งมีสี่บรรทัด แต่ละบรรทัดอ่านจากที่ต่างกันและแต่ละบรรทัดมีคนต่างกันแก้ไข เติมให้ครบก่อนตัดสินใจใด ๆ เพราะแถวที่ผิดคือแถวที่เลือกการซ่อม
| วัตถุ | อ่านจากที่ใด | ใครแก้ไข |
|---|---|---|
| ลายเซ็นของผู้้ออกใบรับรอง | ฟิลด์ Signature Algorithm ของใบรับรอง | ผู้ดูแล CA ตอนออก |
| กุญแจสาธารณะของผู้รับ | ฟิลด์ Public Key Algorithm ของใบรับรอง | ผู้สร้างกุญแจของผู้รับ |
| รูปแบบการพิสูจน์ตัวตน IKE | บันทึกดีมอนหรือรายการเชื่อมต่อ การแจ้งเตือน auth และ signature-hash | โปรไฟล์ IKE บนคู่ค้าทั้งสอง |
| อัลกอริทึมป้องกัน IKE และ ESP | รายการข้อเสนอของการเชื่อมต่อ | โปรไฟล์ IPsec ตามทิศทาง |
แต่ละแถวมีผลต่อความเข้ากันได้ของตนเอง การเปลี่ยนไซเฟอร์ ESP ไม่ได้เลือกลายเซ็นของผู้้ออก และการผ่อนปรนการตรวจสอบ CA ไม่ได้เพิ่มวิธีออนไลน์ที่คู่ค้าไม่เคยเจรจากัน เมื่อตั๋วอ้างความไม่ตรงกันของลายเซ็น แถวที่ผิดจริงแทบไม่เคยเป็นแถวแรก
แก้กรณีเก่าโดยไม่ทำให้ PKI อ่อนแอ
คู่ค้าเก่าอาจเสนอเฉพาะรูปแบบที่นโยบายของคุณไม่อนุญาตแล้ว ทางเลือกคือข้อยกเว้นความเข้ากันได้แบบมีกำหนดเวลา การอัปเดตไคลเอนต์ หรือการจัดรูปแบบการพิสูจน์ตัวตนต่างออกไปเฉพาะคู่ค้านั้น การสร้าง PKI ใหม่รอบลายเซ็นใบรับรองที่อ่อนกว่าไม่ได้แก้ข้อจำกัดในการแลกเปลี่ยนออนไลน์ และทำให้บริการอื่นทั้งหมดที่เชื่อถือ CA เดียวกันอ่อนแอลง บันทึกว่าคุณเปลี่ยนแถวใดและข้อยกเว้นหมดเมื่อใด
จากนั้นรันการอ่านทั้งสองอีกครั้งจากด้านบน เพราะการเปลี่ยนในแถวหนึ่งอาจเลื่อนสิ่งที่เจรจากันในอีกแถว บัญชีทั้งหมดคือสองคำสั่งและหนึ่งตาราง และเป็นงานเดียวกันไม่ว่าคู่ค้าจะเป็นเราเตอร์ แล็ปท็อป หรืออุปกรณ์