DPI (การตรวจสอบ SSL) ขัดแย้งกับการเข้ารหัส แต่บริษัทต่างๆ กำลังนำสิ่งนี้ไปใช้

ห่วงโซ่แห่งความไว้วางใจ ซีซี BY-SA 4.0 ญาณพาส

การตรวจสอบการรับส่งข้อมูล SSL (การถอดรหัส SSL/TLS, การวิเคราะห์ SSL หรือ DPI) กำลังกลายเป็นหัวข้อสนทนาที่ร้อนแรงมากขึ้นในภาคองค์กร แนวคิดในการถอดรหัสการรับส่งข้อมูลดูเหมือนจะขัดแย้งกับแนวคิดเรื่องการเข้ารหัส อย่างไรก็ตาม ความจริงก็คือข้อเท็จจริง: บริษัทต่างๆ จำนวนมากขึ้นเรื่อยๆ กำลังใช้เทคโนโลยี DPI โดยอธิบายเรื่องนี้โดยจำเป็นต้องตรวจสอบเนื้อหาเพื่อหามัลแวร์ ข้อมูลรั่วไหล ฯลฯ

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

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

แทนที่จะต้องใช้ใบรับรองที่ลงนามด้วยตนเองหรือใบรับรองจากอุปกรณ์ DPI คุณสามารถใช้ CA เฉพาะจากผู้ออกใบรับรองบุคคลที่สาม เช่น GlobalSign แต่ก่อนอื่น เรามาพูดถึงภาพรวมของปัญหากันก่อน

การตรวจสอบ SSL คืออะไร และเหตุใดจึงใช้

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

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

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

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

กระบวนการถอดรหัส/การเข้ารหัสใหม่ทำงานอย่างไร

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

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

ข้อความเตือนสำหรับใบรับรองที่ลงนามด้วยตนเองใน Chrome แหล่งที่มา: BadSSL.com

ในคอมพิวเตอร์ Windows คุณสามารถใช้ Active Directory และนโยบายกลุ่มได้ แต่สำหรับอุปกรณ์มือถือ ขั้นตอนจะซับซ้อนกว่า

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

ตัวเลือกที่ดีที่สุด: ใบรับรองรูทส่วนตัวแบบเฉพาะจาก CA บุคคลที่สาม

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

สถาปัตยกรรมที่เรียบง่ายสำหรับใบรับรองรูทไคลเอ็นต์เฉพาะ

การตั้งค่านี้ช่วยขจัดปัญหาบางอย่างที่กล่าวถึงข้างต้น: อย่างน้อยก็ช่วยลดจำนวนรากที่ต้องได้รับการจัดการ ที่นี่ คุณสามารถใช้สิทธิ์รูทส่วนตัวเพียงสิทธิ์เดียวสำหรับความต้องการ PKI ภายในทั้งหมด โดยมี CA ระดับกลางจำนวนเท่าใดก็ได้ ตัวอย่างเช่น แผนภาพด้านบนแสดงลำดับชั้นหลายระดับโดยที่ CA ระดับกลางตัวหนึ่งใช้สำหรับการตรวจสอบ/ถอดรหัส SSL และอีกตัวหนึ่งใช้สำหรับคอมพิวเตอร์ภายใน (แล็ปท็อป เซิร์ฟเวอร์ เดสก์ท็อป ฯลฯ)

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

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

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

เบราว์เซอร์กำลังต่อสู้กลับ

ควรสังเกตว่านักพัฒนาเบราว์เซอร์กำลังพยายามตอบโต้แนวโน้มนี้และปกป้องผู้ใช้จาก MiTM ตัวอย่างเช่น เมื่อไม่กี่วันที่ผ่านมา Mozilla ตัดสินใจแล้ว เปิดใช้งานโปรโตคอล DoH (DNS-over-HTTPS) ตามค่าเริ่มต้นในเบราว์เซอร์เวอร์ชันถัดไปใน Firefox โปรโตคอล DoH ซ่อนการสืบค้น DNS จากระบบ DPI ทำให้การตรวจสอบ SSL ทำได้ยาก

เกี่ยวกับแผนที่คล้ายกัน 10 กันยายน 2019 ประกาศ Google สำหรับเบราว์เซอร์ Chrome

เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ เข้าสู่ระบบ, โปรด.

คุณคิดว่าบริษัทมีสิทธิ์ตรวจสอบการรับส่งข้อมูล SSL ของพนักงานหรือไม่ เพราะเหตุใด

• ใช่ โดยได้รับความยินยอมจากพวกเขา

• ไม่ การขอความยินยอมดังกล่าวถือเป็นการกระทำที่ผิดกฎหมาย และ/หรือผิดจริยธรรม

ผู้ใช้ 122 คนโหวต ผู้ใช้ 15 รายงดออกเสียง

ที่มา: will.com