SSL Decryption บน Firewall ทำงานอย่างไร และอะไรไม่ควรถอดรหัส

SSL decryption บน firewall คือการให้ firewall ตั้ง TLS session สองเส้นแยกกัน เส้นหนึ่งกับ client และอีกเส้นกับ server แล้วอ่านข้อมูลที่อยู่ระหว่างสองเส้นนั้นเป็น plaintext ก่อนเข้ารหัสใหม่และส่งต่อ ชื่อเรียกต่างกันไปตามยี่ห้อ Palo Alto Networks เรียก SSL Forward Proxy และ SSL Inbound Inspection, Fortinet เรียก deep inspection หรือ full SSL inspection, Cisco Secure Firewall ใช้ rule action ชื่อ Decrypt - Resign และ Decrypt - Known Key แต่กลไกข้างในเหมือนกันครับ

บทความนี้ไล่ดูกลไกทีละขั้น แล้วต่อด้วยเรื่องที่ทำให้ project decryption ส่วนใหญ่ช้า คือ traffic ที่ถอดรหัสไม่ได้ และ traffic ที่ไม่ควรถอด ถ้ายังไม่คุ้นกับข้อความใน TLS 1.3 handshake แนะนำให้อ่าน TLS 1.3 Handshake ทีละข้อความ ก่อน บทความนี้จะไม่อธิบาย handshake ซ้ำ

 CLIENT                     FIREWALL                  SERVER    
┌──────────┐             ┌────────────┐             ┌──────────┐
│ laptop   │   TLS #1    │          ● │   TLS #2    │ server   │
│          │●────────────│ decrypt    │─────────────│          │
│ trust:FW │             │ inspect    │             │ real cert│
└──────────┘             │ re-encrypt │             └──────────┘
                         │            │                         
                         └────────────┘                         
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
 1  ClientHello to files.example.com, intercepted               
                                                                
 two TLS sessions; plaintext exists only inside the firewall    

ทำไม firewall ต้องถอดรหัสก่อนถึงจะตรวจได้

เพราะสิ่งที่ security profile ต้องดู เช่น URL เต็ม ไฟล์ที่ดาวน์โหลด และ payload ที่มี exploit อยู่ในส่วนที่ถูกเข้ารหัสทั้งหมด Palo Alto Networks เขียนไว้ในหน้า Decryption Basics ว่าเราบล็อก traffic ที่ไม่ได้ตรวจไม่ได้ และยกตัวอย่างว่าถ้าผู้โจมตีวาง malware ไว้บนเว็บ HTTPS พนักงานที่เข้าเว็บนั้นจะดาวน์โหลด malware มาโดยไม่รู้ตัว

Fortinet ยกตัวอย่างคล้ายกันใน Deep inspection คือไฟล์ที่มีไวรัสระหว่าง session e-commerce หรือไฟล์จาก phishing ที่เปิดแล้วสร้าง session เข้ารหัสไปที่ command and control server ซึ่งอาจผ่านมาตรการ security ของเครือข่ายไปได้เพราะ session ถูกเข้ารหัส

Forward proxy ถอดรหัส traffic ขาออกทีละขั้นอย่างไร

Forward proxy ใช้กับ traffic จากผู้ใช้ภายในออกไป internet firewall สร้าง session สองเส้นแยกกัน คือระหว่าง client กับ firewall และระหว่าง firewall กับ server ลำดับตามเอกสาร SSL Forward Proxy ของ Palo Alto Networks มีดังนี้

ขั้นที่ 1: client เริ่ม TLS session

client ในเครือข่ายเริ่ม TLS session ไปที่ server ภายนอก เช่น https://files.example.com firewall ดัก session นั้นไว้ ในมุมของ client firewall คือ server ปลายทาง

ขั้นที่ 2: firewall เปิด session ใหม่ไปที่ server จริง

firewall ส่ง request ต่อไปที่ server ในฐานะ client อีกตัว server ไม่รู้ว่ามี firewall อยู่ตรงกลาง และส่ง certificate ของตัวเองกลับมาที่ firewall

ขั้นที่ 3: firewall ตรวจ certificate ของ server

firewall ตรวจว่า certificate ของ server เซ็นโดย CA ที่ firewall เชื่อหรือไม่ ถ้าเชื่อ firewall จะสร้างสำเนา certificate ของ server ที่เซ็นด้วย Forward Trust certificate ส่งให้ client ถ้าไม่เชื่อ จะใช้ Forward Untrust certificate แทน ซึ่งทำให้ client ขึ้นคำเตือน สำเนานี้เรียกว่า impersonation certificate เพราะไม่ใช่ certificate จริงของ server

ขั้นที่ 4: client ตรวจ certificate ที่ได้รับ

client ตรวจ impersonation certificate ตามปกติ ถ้าผ่าน การแลก key จะเกิดขึ้นสองชุด ชุดหนึ่งระหว่าง client กับ firewall และอีกชุดระหว่าง firewall กับ server

ขั้นที่ 5: ข้อมูลวิ่งผ่าน firewall

firewall ถอดรหัส ใช้ Security policy, security profile และ decryption profile แล้วเข้ารหัสใหม่ก่อนส่งต่อ ในทั้งสองทิศ

Fortinet อธิบายแบบเดียวกัน FortiGate ทำหน้าที่เป็น subordinate CA ที่เซ็น certificate ขึ้นมาทันทีระหว่างเข้ารหัสใหม่ และมักใช้ subordinate CA ที่เซ็นโดย private CA ขององค์กร ฝั่ง Cisco ใช้ rule action Decrypt - Resign สำหรับ traffic ขาออก ซึ่งเซ็น certificate ของ server ใหม่ด้วย CA certificate แล้วทำตัวเป็น man-in-the-middle

ทำไมเครื่อง client ต้องเชื่อ CA ของ firewall

เพราะ certificate ที่ client ได้รับในขั้นที่ 3 เซ็นโดย firewall ไม่ใช่ CA สาธารณะ ถ้า client ไม่มี CA นั้นใน trust store ก็จะขึ้นคำเตือนทุกเว็บ เอกสารของ Palo Alto Networks ระบุว่าถ้าไม่ติดตั้ง Forward Trust certificate บนเครื่อง client ผู้ใช้จะเห็นคำเตือน certificate ทุกครั้งที่เข้าเว็บ SSL Fortinet เขียนเงื่อนไขเดียวกัน คือต้องมี certificate chain ย้อนกลับไปถึง root CA ที่ติดตั้งบนเครื่องผู้ใช้

ในทางปฏิบัติมีสองทาง (Palo Alto Networks):

• ใช้ certificate ที่เซ็นโดย enterprise CA ที่เครื่องในองค์กรเชื่ออยู่แล้ว กรณีนี้ไม่ต้องแจกอะไรเพิ่ม
• ใช้ self-signed certificate แล้ว export root CA certificate ไปใส่ใน Trusted Root Certification Authorities ของ client

มีสองข้อที่เอกสารเน้นและผมคิดว่าสำคัญมาก ข้อแรก private key ของ Forward Trust CA ต้องอยู่บน firewall และไม่ export ไปที่ client ข้อสอง ห้ามติดตั้ง Forward Untrust certificate บน client เพราะ Forward Untrust มีไว้ให้ client ขึ้นคำเตือนเมื่อ server ใช้ certificate ที่ไม่น่าเชื่อถือ ถ้า client เชื่อมันด้วย คำเตือนนั้นจะหายไป

private key ของ Forward Trust CA เซ็น certificate ให้โดเมนไหนก็ได้ที่ client ในองค์กรจะเชื่อ เอกสารของ Palo Alto Networks จึงแนะนำให้เก็บ key นี้บน HSM และ backup ไว้ในที่ปลอดภัย

Inbound inspection ต่างจาก forward proxy อย่างไร

Inbound inspection ใช้กับ traffic จากภายนอกเข้ามาที่ server ขององค์กรเอง และ firewall ใช้ certificate กับ private key จริงของ server แทนการเซ็น certificate ขึ้นใหม่ เอกสารของ Palo Alto Networks ระบุว่า SSL Inbound Inspection ต้องติดตั้ง certificate และ private key ของ server ทุกตัวที่ต้องการป้องกันไว้บน firewall firewall ตรวจว่า certificate ที่ server ส่งมาตรงกับที่อยู่ใน decryption policy rule หรือไม่ ถ้าตรงจึงส่ง certificate ของ server ต่อให้ client

ฝั่ง Cisco คือ Decrypt - Known Key ซึ่งเหมาะกับ traffic ที่เข้ามาที่ server ที่องค์กรดูแลเอง และต้องมี private key ของ server

ถ้าไม่ถอดรหัส firewall ยังเห็นอะไรได้บ้าง

เห็นข้อมูลที่อยู่ก่อนส่วนที่ถูกเข้ารหัส FortiGate มี certificate inspection profile ซึ่งตรวจเฉพาะ header จนถึงชั้น SSL/TLS Fortinet แนะนำโหมดนี้ในกรณีที่ไม่ต้องการ deep scan ด้วยเหตุผลด้าน privacy แต่ยังต้องการควบคุมการเข้าเว็บ profile เริ่มต้นแบบนี้ฟังเฉพาะ port 443 ถ้าเว็บใช้ port อื่น เช่น 8443 ต้องสร้าง profile ใหม่

ข้อจำกัดคือใน TLS 1.3 certificate ของ server ถูกเข้ารหัสแล้ว สิ่งที่เหลือให้เห็นจึงน้อยลง รายละเอียดว่าข้อความไหนยังอ่านได้ อยู่ในบทความ TLS 1.3 Handshake ทีละข้อความ ครับ

Traffic แบบไหนถอดรหัสไม่ได้

traffic ที่ client ตรวจ certificate แบบเจาะจง (pinning) traffic ที่ใช้ client certificate และ traffic ที่ไม่ได้วิ่งบน TLS ปกติ เอกสาร SSL Forward Proxy ระบุว่า firewall ถอดรหัสบาง session ไม่ได้ เช่น session ที่มี client authentication หรือ pinned certificate เพราะ firewall เป็น proxy

• Certificate pinning: แอปเช็กว่า certificate ที่ได้ต้องเป็นตัวที่แอปรู้จักเท่านั้น impersonation certificate จึงไม่ผ่าน Cisco เขียนว่าถอดรหัส traffic นี้ด้วยการเซ็น certificate ใหม่ไม่ได้ และไม่มีทางเลี่ยง Cisco แนะนำให้วาง Do Not Decrypt rule ไว้ก่อน Decrypt - Resign rule
• Mutual authentication: server ขอ client certificate firewall ไม่มี private key ของ client จึงแสดงตัวแทน client ไม่ได้
• Certificate chain ไม่ครบ และ cipher ที่ไม่รองรับ: Palo Alto Networks นับเป็นเหตุผลทางเทคนิคที่ต้อง exclude ด้วย
• QUIC: วิ่งบน UDP และ PAN-OS ถอดรหัสไม่ได้ วิธีที่เอกสารแนะนำคือบล็อก QUIC เพื่อให้ browser กลับไปใช้ TLS ซึ่งถอดรหัสได้

PAN-OS แยกการจัดการ traffic กลุ่มนี้ไว้สามที่ คือ predefined exclusion list ที่ Palo Alto Networks อัปเดตผ่าน content update, Local SSL Decryption Exclusion Cache ที่ firewall เพิ่มเองอัตโนมัติและเก็บไว้ 12 ชั่วโมง ถ้า decryption profile อนุญาต unsupported mode และ custom exclusion list ที่ผู้ดูแลเพิ่มเอง

Traffic แบบไหนไม่ควรถอดรหัส

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

• Fortinet: เมื่อสร้าง SSL/SSH inspection profile แบบ full SSL inspection หมวด Finance and Banking, Health and Wellness และ Personal Privacy ถูกยกเว้นเป็นค่าเริ่มต้น
• Palo Alto Networks: traffic ที่เลือกไม่ถอดรหัสด้วยเหตุผลทางธุรกิจ กฎระเบียบ หรือส่วนบุคคล เช่น financial-services, health-and-medicine หรือ government ให้ใช้ policy-based decryption exclusion
• Cisco: ไม่ควรถอดรหัสถ้ากฎหมาย นโยบายบริษัท หรือกฎด้าน privacy ห้ามไว้

ข้อที่ต่างกันระหว่างสองกลุ่มนี้คือที่วางใน config บน PAN-OS traffic ที่ถอดไม่ได้ทางเทคนิคไปอยู่ใน exclusion list ส่วน traffic ที่เลือกไม่ถอดไปอยู่ใน no-decrypt policy rule ตาม URL category, source หรือ destination การแยกแบบนี้ทำให้ตอบได้ทีหลังว่าแต่ละรายการถูกยกเว้นเพราะอะไร

Fortinet เพิ่มอีกข้อที่ผมเห็นด้วย คือผู้ใช้ควรรู้ว่าการสื่อสารของตัวเองถูกตรวจแบบนี้ และ privacy ไม่สามารถรับประกันได้ ส่วน Palo Alto Networks เตือนว่าการใช้ SSL traffic ถูกกำกับดูแลในบางประเทศ ให้ตรวจกฎหมายท้องถิ่นก่อน mirror หรือเก็บ traffic ที่ถอดรหัสแล้ว เรื่องกฎหมายของแต่ละประเทศควรถามฝ่ายกฎหมายขององค์กรครับ

TLS 1.3 เปลี่ยนอะไรกับ decryption

TLS 1.3 ทำให้ firewall ที่ไม่ถอดรหัสเห็น certificate ไม่ได้ และทำให้ inbound inspection แบบใช้ RSA key exchange ใช้ไม่ได้อีกต่อไป เอกสาร TLS 1.3 Decryption ของ Palo Alto Networks ระบุผลที่เกิดกับ config ไว้หลายข้อ (Palo Alto Networks):

• ต้องเปิดเอง: ถ้าไม่ตั้ง TLSv1.3 ใน decryption profile, PAN-OS ใช้ TLSv1.2 เป็น max version ที่แนะนำคือ Min Version TLSv1.2 และ Max Version เป็น Max
• แอปมือถือที่ pin certificate: TLS 1.3 เข้ารหัสข้อมูล certificate ที่เวอร์ชันก่อนไม่ได้เข้ารหัส firewall จึงเพิ่ม exclusion อัตโนมัติจากข้อมูล certificate ไม่ได้ และอาจ drop traffic ของแอปมือถือบางตัว เอกสารแนะนำให้ตั้ง Max Version เป็น TLSv1.2 ใน rule ของแอปเหล่านั้น หรือทำ No Decryption rule แยก
• No Decryption profile ใช้ไม่ได้กับ TLS 1.3: profile นี้ตรวจ certificate หมดอายุหรือ issuer ที่ไม่น่าเชื่อถือ แต่ใน TLS 1.3 firewall มองไม่เห็น certificate จึงทำให้ profile ไม่มีผล
• Inbound inspection: TLSv1.3 ตัดการรองรับ RSA key exchange และใน handshake TLS 1.3 firewall ส่ง certificate หรือ chain เดียวกับที่ได้จาก server ให้ client

Cisco มีข้อจำกัดเฉพาะของตัวเองด้วย เมื่อเปิด TLS 1.3 decryption แล้วใช้ ECDSA certificate กับ Decrypt - Known Key traffic ที่ match จะถูกบล็อก

การถอดรหัสเพิ่มความเสี่ยงอะไรบ้าง

firewall ที่ถอดรหัสกลายเป็นจุดเดียวที่ตรวจ certificate ของ server แทน client ถ้าตรวจไม่ดี client ก็ไม่มีทางรู้ CISA Alert TA17-075A อธิบายว่า client ตรวจได้เฉพาะ connection ระหว่างตัวเองกับอุปกรณ์ที่ intercept HTTPS และต้องพึ่งการตรวจของอุปกรณ์นั้นทั้งหมด alert ฉบับเดียวกันอ้างรายงานที่พบว่าอุปกรณ์หลายตัวไม่ตรวจ certificate chain ของ server ให้ถูกต้องก่อนเข้ารหัสใหม่และส่งต่อ และอาจยอมใช้ protocol เวอร์ชันเก่าหรือ cipher อ่อนกับ server ขณะที่ฝั่ง client ยังเห็น cryptography แข็งแรง

CISA แนะนำให้ทดสอบกับ badssl.com อย่างน้อยถ้า test ในหมวด Certificate ทำให้ client ที่ต่อ internet ตรงเชื่อมต่อไม่ได้ client ที่ต่อผ่านอุปกรณ์ intercept ก็ต้องเชื่อมต่อไม่ได้เหมือนกัน

ความเสี่ยงอื่นที่เอกสาร vendor ระบุไว้:

• Decryption port mirroring ส่ง traffic ที่ถอดรหัสแล้วเป็น cleartext รวมถึงข้อมูลอ่อนไหว ไปที่อุปกรณ์ตัวอื่น
• HA: PAN-OS ไม่ sync session ที่ถอดรหัสแล้ว หลัง failover session ที่ถอดรหัสอยู่จะไม่ต่อ ต้องเริ่ม session ใหม่

ควรเริ่มตั้ง decryption policy จากตรงไหน

เริ่มจากเขียน rule ที่ไม่ถอดรหัสให้เสร็จก่อน แล้วค่อยเปิดถอดรหัสทีละกลุ่ม ลำดับที่ผมใช้คิดเป็นแบบนี้ (ทุกข้อมาจากเอกสารที่อ้างไว้ข้างบน แต่การเรียงลำดับเป็นความเห็นของผม):

1. เลือก CA: ใช้ subordinate CA จาก enterprise CA ถ้ามี เก็บ private key บน HSM ถ้าทำได้ และแจก root ให้ client ผ่านระบบจัดการเครื่อง
2. เขียน no-decrypt rule ตาม URL category สำหรับการเงิน สุขภาพ และหมวดที่ฝ่ายกฎหมายระบุ วางไว้ก่อน decrypt rule
3. บล็อก QUIC ใน traffic ที่จะถอดรหัส เพื่อให้ browser ใช้ TLS
4. ตั้ง decryption profile: Min TLSv1.2, Max เป็น Max และแยก rule กับ profile สำหรับแอปมือถือที่ต้อง Max TLSv1.2
5. เปิดถอดรหัสกับกลุ่มทดสอบก่อน แล้วดู decryption log ว่า session ไหนล้มเหลวและเพราะอะไร
6. เพิ่ม exclusion เฉพาะที่จำเป็น Palo Alto Networks แนะนำให้ไม่ทำ decryption exception ถ้าไม่จำเป็น เพื่อให้เห็น traffic มากที่สุด
7. ทดสอบการตรวจ certificate ด้วย badssl.com ผ่าน firewall เทียบกับต่อตรง

rule แบบข้อ 2 บน PAN-OS เขียนเป็นตารางได้ประมาณนี้ (ชื่อ rule และ zone เป็นตัวอย่าง):

#  name                  from   to       url-category                               action
1  no-decrypt-sensitive  trust  untrust  financial-services, health-and-medicine    no-decrypt
2  no-decrypt-pinned     trust  untrust  (custom list ของแอปที่ pin certificate)       no-decrypt
3  decrypt-outbound      trust  untrust  any                                        ssl-forward-proxy

rule ถูกตรวจจากบนลงล่าง rule ที่ไม่ถอดรหัสจึงต้องอยู่บนสุด Cisco แนะนำไว้ตรงกันว่า Do Not Decrypt rule สำหรับ traffic ที่ pin certificate ควรอยู่ก่อน Decrypt - Resign rule ครับ

แหล่งอ้างอิง

• Palo Alto Networks: Decryption Basics
• Palo Alto Networks: SSL Forward Proxy
• Palo Alto Networks: SSL Inbound Inspection
• Palo Alto Networks: Keys and Certificates for Decryption Policies
• Palo Alto Networks: Configure SSL Forward Proxy
• Palo Alto Networks: Decryption Exclusions
• Palo Alto Networks: TLS 1.3 Decryption
• Fortinet: SSL/TLS deep inspection (FortiOS 7.4 Best Practices)
• Fortinet: Deep inspection (FortiOS 7.4.3)
• Fortinet: Certificate inspection (FortiOS 7.4.3)
• Cisco: Secure Firewall Management Center Device Configuration Guide 7.4, Decryption Rules
• CISA Alert TA17-075A: HTTPS Interception Weakens TLS Security