SSTP กับ SSL 3.0: ป้ายชื่อกับเวอร์ชันที่เจรจาจริง

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

สองคำตอบสำหรับคำถามเดียว

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

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

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

อ่านเวอร์ชันที่บริการเลือกจริง

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

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

แยกฟิลด์บันทึกออกจากการเจรจา

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

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

เพราะฉะนั้น “ภาระงานนี้น่าจะถูกใช้ประโยชน์ได้ยาก” ไม่ใช่เหตุผลที่จะเปิด SSL 3.0 ไว้ ข้อกำหนดคือการถอดโปรโตคอลออก ไม่ใช่การชนะการถกเถียงเรื่องการสาธิตครั้งเดียว

ปลดระวาง SSL 3.0 ด้วยนโยบายที่คุณปกป้องได้

ใน Windows การตั้งค่าโปรโตคอลของ Schannel อยู่ใต้คีย์ Protocols และอ่านแยกตามบทบาทไคลเอนต์และเซิร์ฟเวอร์ จึงเป็นเหตุให้การแก้ด้านหนึ่งอาจปล่อยอีกด้านไว้ไม่แตะต้อง การตั้งค่าปัจจุบันและข้อกำหนดการรีสตาร์ตมีเอกสารของ Microsoft กำกับ และไลบรารี TLS ของบุคคลที่สามบนโฮสต์เดียวกันก็เพิกเฉยต่อสิ่งเหล่านั้นทั้งหมด

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

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

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

รับการเปลี่ยนแปลงด้วยการเชื่อมต่อใหม่

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

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

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