ติดตามแพ็กเก็ตควบคุมของ OpenVPN: tls-auth ก่อน TLS

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

อ่านซองตามลำดับที่มันถูกสร้าง

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

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

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

แสดงว่าการตรวจเกิดขึ้นก่อนแฮนด์เชก

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

เพิ่มระดับความละเอียดของเดม่อนและเฝ้าดูช่องควบคุมแทนอุปกรณ์ tun:

openvpn --config /etc/openvpn/server.conf --verb 6

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

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

จับคู่คีย์ ทิศทาง และ digest ที่ปลายทั้งสอง

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

สร้างความลับร่วมด้วยเครื่องมือไม่ใช่ด้วยโปรแกรมแก้ไข และรักษาสิทธิ์ให้แน่น:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

อย่าสับสน tls-auth กับ tls-crypt ทั้งคู่ป้องกันช่องควบคุม แต่ tls-crypt เข้ารหัสช่องนั้นด้วยและซ่อนแฮนด์เชกจากผู้สังเกต และแทนที่การแยกทิศทางด้วยการจัดการคีย์ของตัวเอง โปรไฟล์ที่ใช้อย่างหนึ่งจะทำงานร่วมกับคู่ที่กำหนดค่าสำหรับอีกอย่างไม่ได้ และไม่มีการปรับ digest ใดปิดช่องว่างนั้น

สร้างแท็กซ้ำจากรูปแบบจริงเท่านั้น

การสร้างซ้ำให้ตรงระดับไบต์เป็นงานแยกจากการรัน VPN และทำงานได้เฉพาะกับอินพุตจริง: การทำงานและเวอร์ชันที่สร้างแพ็กเก็ต, digest ที่เลือก, ทิศทาง และไบต์จริงรวมถึงตัวระบุเซสชันและอาร์เรย์การตอบรับ การแสดงรายการฟิลด์เป็นข้อความไม่ใช่ไบต์เหล่านั้น

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

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

ย้อนกลับความไม่ตรงกันโดยไม่ถอดการป้องกัน

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

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

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