ไซเฟอร์ของ Windows และ strongSwan: จับคู่เลเยอร์ให้ถูก

ทั้งสองฝั่งบอกว่า AES-128 แต่ทันเนลก็ยังไม่ยอมสร้างขึ้น CBC และ GCM เป็นทรานส์ฟอร์มที่ต่างกันซึ่งบังเอิญมีความยาวคีย์เท่ากัน และไคลเอนต์ที่เสนออย่างหนึ่งก็ไม่ทำให้เกตเวย์ที่รับเฉพาะอีกอย่างหนึ่งพอใจ คำว่า AES อธิบายตระกูล ไม่ใช่ข้อตกลง

ยังมีแกนที่สองด้วย และนั่นคือสิ่งที่สร้างข้อผิดพลาดที่สับสน

สองเลเยอร์ สองรายการที่เป็นอิสระต่อกัน

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

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

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

อ่านข้อผิดพลาดข้างข้อเสนอ

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

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

เก็บ CBC และ GCM เป็นทางเลือกที่แยกจากกัน

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

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

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

ข้อเสนอ ESP ไม่ใช่ข้อเสนอ IKE ที่เปลี่ยนชื่อ

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

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

ตรวจสอบทั้งสองชุด แล้วจึงตรวจสอบการสร้างคีย์ใหม่

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

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