AnyConnect บน Linux ขึ้นข้อผิดพลาด TLS ไม่ถูกต้อง: กำหนดขอบเขตการแก้ไขก่อน

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

อ่านข้อความก่อนแตะนโยบาย

เก็บข้อความที่แน่นอนจากกล่องโต้ตอบไว้ ข้อร้องเรียนเรื่องเวอร์ชันชี้ไปที่ชั้นโปรโตคอล ข้อร้องเรียนเรื่องใบรับรองชี้ไปที่ความเชื่อถือหรือการตั้งชื่อ และการเข้าสู่ระบบที่ล้มเหลวชี้ไปที่ข้อมูลรับรอง เกตเวย์ที่เสนอ TLS 1.0 พร้อมกลุ่ม DHE ขนาด 1024 บิต AES-256-CBC และลายเซ็น SHA-1 อาจมีใบรับรองที่ถูกต้องสมบูรณ์และยังถูกปฏิเสธโดยนโยบายสมัยใหม่ก่อนที่ข้อมูลของคุณจะถูกส่งด้วยซ้ำ

ตรวจสอบปลายทางด้วย OpenSSL ของระบบ โดยใช้ชื่อโฮสต์จริงและพอร์ตที่ไคลเอนต์ใช้

หาก openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ล้มเหลวในขณะที่ -tls1 -cipher DEFAULT@SECLEVEL=0 สำเร็จ แสดงว่าขอบเขตคือเวอร์ชันและขนาดกุญแจรวมกัน หากคำสั่งแรกแจ้งกุญแจ DH ขนาดเล็กแทนการเตือนโปรโตคอล แสดงว่าเวอร์ชันปกติและมีเพียงกลุ่มที่ต้องให้ความสนใจ อย่าใส่กุญแจส่วนตัวหรือรหัสผ่านลงในการตรวจสอบเด็ดขาด

ทางเลือก 1: ผ่อนนโยบายทั้งโฮสต์ด้วยนโยบายการเข้ารหัส

บน Fedora และ RHEL 8 และ 9 update-crypto-policies --set LEGACY ลดนโยบายระบบของ OpenSSL และ update-crypto-policies --show ยืนยันว่าอะไรทำงานอยู่ โดยปกติจะทำให้อุโมงค์กลับมา แต่มีการอ่านนโยบายเมื่อโปรเซสเริ่มทำงาน ดังนั้นให้รีสตาร์ตไคลเอนต์และตัวช่วยใด ๆ ที่มันสร้างขึ้นก่อนทดสอบใหม่ นอกจากนี้ยังอนุญาตโปรโตคอลเก่าและกลุ่มที่อ่อนแอกว่าสำหรับไคลเอนต์ TLS ทุกตัวบนเครื่อง ตั้งแต่เบราว์เซอร์ในหน้าต่างถัดไปจนถึงตัวจัดการแพ็กเกจที่อัปเดตเคอร์เนล

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

Debian และ Ubuntu ไม่มีสวิตช์เดียวสำหรับเรื่องนี้ สิ่งที่เทียบเท่าคือการแก้ไข /etc/ssl/openssl.cnf ที่ตั้ง MinProtocol ให้ต่ำลงและ CipherString = DEFAULT@SECLEVEL=0 ในส่วนค่าเริ่มต้นของระบบ ขอบเขตเดียวกัน ไฟล์ต่างกัน หายจากสายตาระหว่างอัปเกรดรีลีสได้ง่ายกว่าเล็กน้อย

ทางเลือก 2: ไฟล์กำหนดค่าเดียวสำหรับไคลเอนต์เดียว

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

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

ชี้ OPENSSL_CONF ไปที่ไฟล์นั้นและเปิดไคลเอนต์ VPN ผ่านตัวห่อที่ส่งออกไฟล์นั้น ทุกอย่างอื่นบนโฮสต์ยังคงนโยบายเริ่มต้น และนั่นคือคุณสมบัติที่สำคัญเมื่อคำถามเรื่องการปฏิบัติตามข้อกำหนดมาถึง ยืนยันว่าไฟล์มีผลจริงก่อนโทษเกตเวย์: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 ควรแสดงรายการรหัสลับ TLS 1.0 และผลลัพธ์ว่างหมายความว่าห่วงโซ่ขาดและไคลเอนต์เก็บค่าเริ่มต้นของระบบไว้อย่างเงียบ ๆ

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

ขีดจำกัดคือความครอบคลุม อะไรก็ตามที่ลิงก์กับ GnuTLS หรือ NSS จะเพิกเฉยต่อ OPENSSL_CONF และโปรเซสช่วยเหลือใด ๆ ที่ไคลเอนต์เปิดโดยไม่สืบทอดสภาพแวดล้อมก็เช่นกัน ตรวจสอบด้วย ldd ว่าไบนารีลิงก์กับไลบรารี TLS ใดจริง ๆ ก่อนสร้างตัวห่อ เพราะคำตอบตัดสินว่าทางเลือกนี้มีอยู่หรือไม่

ทางเลือก 3: VM หรือคอนเทนเนอร์ใช้ครั้งเดียว

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

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

การเปรียบเทียบเหลืออะไรให้คุณ

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

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