ย้อนดู Heartbleed

ในปี 2014 มีการพบจุดบกพร่องใน OpenSSL ซึ่งเป็นไลบรารีการเข้ารหัสยอดนิยมที่ทำให้เซิร์ฟเวอร์ส่วนมากบนอินเทอร์เน็ตปลอดภัย จุดบกพร่องนี้ทำให้ผู้โจมตีสามารถใช้คุณลักษณะที่ไม่สะดุดตาชื่อ TLS heartbeats ในการอ่านหน่วยความจำจากเซิร์ฟเวอร์ที่เกี่ยวข้องได้ การ Heartbleed นี้เป็นข่าวใหญ่จากการที่มันทำให้ผู้โจมตีสามารถดึงข้อมูลอันเป็นความลับที่สำคัญที่สุดบนเซิร์ฟเวอร์ไปได้: คีย์ส่วนตัวของ TLS/SSL certificate นั่นเอง หลังแน่ใจแล้วว่าข้อผิดพลาดนี้ ถูกเอาไปใช้ผิดๆ ได้ง่าย พวกเราจึงเพิกถอนและได้ออก Certificate ใหม่มากกว่า  100,000 certificates ซึ่งเป็นการทำให้ปัญหาใหญ่ในเรื่องการจัดการความปลอดภัยบนอินเทอร์เน็ตเป็นที่สนใจมากขึ้นได้

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

เก็บคีย์ให้ปลอดภัย

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

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

Heartbleed แสดงให้เราเห็นว่ากลยุทธ์นี้ยังสามารถเป็นประโยชน์ในการเสริมเลเยอร์ของความปลอดภัยแก่คีย์ส่วนตัวที่เราจัดการให้กับลูกค้าของเราด้วย Geo Key Manager เป็นคุณลักษณะที่อนุญาตให้ลูกค้าสามารถเลือกสถานที่ใดก็ได้บนโลกเพื่อเป็นที่เก็บคีย์ของพวกเขา Geo Key Manager ป้องกันช่องโหว่ทางกายภาพของเซิร์ฟเวอร์บนภูมิภาคต่างๆ ในปี 2019 พวกเราพัฒนาไปอีกขั้นด้วยการปรับใช้กลยุทธ์ชื่อ Keyless Everywhere โดยย้ายคีย์ที่ถูกจัดการทั้งหมดไปอยู่บนระบบซึ่งแยกอินเทอร์เน็ตและคีย์ออกจากกันอย่างสมเหตุสมผล

Keyless SSL เป็นโซลูชันการรักษาความปลอดภัยที่ยอดเยี่ยม แต่อาจมีเวลาแฝงได้โดยขึ้นอยู่กับที่ที่เก็บคีย์ ดังนั้น พวกเราจึงพัฒนามาตรฐานใหม่ที่เรียกว่า Delegated Credential ร่วมกับ IETF ซึ่งจะอนุญาตให้การเชื่อมต่อสามารถใช้คีย์ที่มีอายุสั้นจาก Certificate แทนที่จะใช้ตัว Certificate เองใน TLS วิธีการนี้สามารถกำจัดเวลาแฝงที่เพิ่มจาก Keyless SSL ได้ พวกเรารองรับ Delegated Credential สำหรับลูกค้าที่ใช้ Keyless SSL และ Geo Key Manager ทุกรายและ Firefox 89 (พฤษภาคม 2021) จะทำให้สามารถรองรับ Delegated Credential เป็นค่าเริ่มต้นได้

ทำให้การเพิกถอนได้ผล

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

ผลกระทบแรกของการเพิกถอน คือ การเกิดปริมาณการรับส่งข้อมูลที่เกี่ยวข้องในเครือข่ายเพิ่มขึ้นอย่างมหาศาล ในปี 2014 มีกลไกการเพิกถอน Certificate สามกลไกหลักด้วยกัน คือ:

• Certificate Revocation Lists (CRLs)
  • รายการหมายเลขซีเรียลที่ถูกเพิกถอนต่อ Certificate แต่ละรายการ
    
• โปรโตคอลสถานะใบรับรองออนไลน์ (OCSP)
  • โปรโตคอลในการดูประวัติของ Certificate แต่ละรายการและสถานะการเพิกถอน
    
  • สามารถดูประวัติ OCSP ได้จากเบราว์เซอร์หรือสามารถรวมการตอบกลับจากเซิร์ฟเวอร์ ณ ขณะที่มีการเชื่อมต่อ “การเย็บเล่ม OCSP” ได้
• ชุดของ CRL — ระบบเพิกถอนที่กำหนดได้ของ Chrome
  • รายการเกี่ยวกับการเปลี่ยนแปลงของหมายเลขประจำเครื่องที่ถูกเพิกถอนที่จำกัดแค่ Certificate ที่มีค่าสูง

Certificate หลายหมื่นใบถูกเพิกถอนพร้อมๆ กันจากความเสี่ยงในการเกิดช่องโหว่จาก Heartbleed จากนั้น CRL สำหรับ CA ที่โดดเด่น, GlobalSign เพิ่มจาก 22KB ขึ้นเป็น 4.7MB ในวันเดียวนันทำให้เกิดการหยุดชะงักครั้งใหญ่ในโครงสร้างพื้นฐานการแคชภายในของ Cloudflare และการเพิ่มขึ้นอย่างฉับพลันของ Bandwidth ที่ส่งผลกระทบต่ออินเทอร์เน็ตโดยรวมเมื่อไคลเอ็นต์ทุกคนที่ใช้ CRL ตรวจสอบ Certificate (ส่วนใหญ่เป็น Microsoft Windows) ดาวน์โหลดไฟล์ดังกล่าวหลังเหตุการณ์การเพิกถอนในครั้งนี้ก็ชัดเจนว่ามีสาเหตุอื่นว่าทำไมการเพิกถอนไม่ใช่ระบบที่ใช้งานได้ หากมีผู้ใช้ใน Firefox สร้างการเชื่อมต่อกับเว็บไซต์และไม่มีการตอบสนองของ OCSP ที่เย็บเล่มแล้ว Firefox จะสืบค้นภายในเซิร์ฟเวอร์เพื่อหาการตอบสนองนั้น แต่ในขณะเดียวกัน Firefox ก็จะปรับใช้กลยุทธ์ใช้งานเมื่อเกิดความผิดพลาด นั่นคือ: หากการตอบสนองของ OCSP ใช้เวลานานเกินไป การตรวจสอบการเพิกถอนนั้นจะถูกลัดขั้นตอนและหน้านั้นจะแสดงผล ผู้โจมตีที่มีตำแหน่งในเครือข่ายที่ดีกว่าสามารถใช้ Certificate ที่มีช่องโหว่และถูกเพิกถอน ในการโจมตีผู้ใช้งานได้โดยแค่บล็อกการร้องขอ OCSP และปล่อยให้เบราว์เซอร์ข้ามการตรวจสอบการเพิกถอนซะ การเย็บเล่มของ OCSP เป็นวิธีที่เชื่อถือได้ของเซิร์ฟเวอร์ในการได้การตอบสนองของ OCSP มายังเบราว์เซอร์ แต่เพราะการเย็บเล่มไม่ใช่ข้อบังคับสำหรับไคลเอ็นด์ ผู้โจมตีจึงสามารถแค่ตัดการเย็บเล่มออกไปได้และเบราว์เซอร์ก็จะไม่สามารถเปิดได้ ทำให้ผู้ใช้ถูกโจมตีได้ง่าย OCSP ยังไม่สามารถให้การป้องกันช่องโหว่ของคีย์ในโหมดเปิดใช้งานเมื่อล้มเหลวได้ดีนัก (แล้ว OCSP ยังถือเป็น การรั่วไหลของความเป็นส่วนตัว ด้วย แต่นั่นเป็นอีกปัญหาหนึ่ง)

สถานการณ์ด้านความปลอดภัยใน Chrome น่าเป็นห่วงมากกว่านั้นอีก เนื่องจากทั้ง OCSP และ CRL ไม่ได้ถูกตรวจสอบ Certificate ส่วนใหญ่ (ชุดของ CRL มีแต่ Certificate ที่ "มีการตรวจสอบแบบขยาย") Certificate ส่วนใหญ่จึงได้รับความไว้ใจโดยไม่มีการตรวจสอบสถานะการเพิกถอนเลย โซลูชันสำหรับการเพิกถอนชุด Certificate ที่ Cloudflare จัดการบน Chrome ในกรณี Heartbleed นั้น แท้จริงแล้วเป็นเพียง Patch สั้นๆ ของฐานรหัส Chromium เท่านั้น ชัดเจนว่าไม่ได้เป็นโซลูชันที่ขยายผลได้แน่!

การเพิกถอน Certificate ปริมาณมากในปี 2014 ว่ากันอย่างตรงไปตรงมาได้เลยว่ามันไม่ได้ผล ในขณะนั้น Certificate บางส่วนยังมึอายุมากถึง 5 ปี ช่องโหว่ของคีย์จึงเป็นปัญหาที่ส่งผลระยะยาว

ในปี 2015 ได้เกิดมาตรฐานแบบใหม่ที่ดูเหมือนจะเป็นโซลูชันที่สมเหตุสมผลกับปัญหานี้ขึ้น: มีการออก Certificate OCSP ที่ต้องเย็บเล่ม ที่มีคุณลักษณะที่ต้องเย็บเล่ม ซึ่งจะได้รับความไว้วางใจก็ต่อเมื่อมีการเย็บเล่ม OCSP ที่ถูกต้อง หาก Certificate OCSP ที่ต้องเย็บเล่มนี้มีช่องโหว่และถูกเพิกถอน มันก็จะถูกใช้โจมตีผู้ใช้ได้ในอายุของ OCSP ที่ออกให้ล่าสุดเท่านั้น (โดยปกติคือ 10 วันหรือน้อยกว่า) นี่จึงเป็นการปรับปรุงครั้งใหญ่และช่วยลดความเสี่ยงโดยรวมของผู้ถือ Certificate ลงได้

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

2014 เทียบกับ ปัจจุบัน

พวกเรามากันได้ไกลในระยะเวลาเจ็ดปี Cloudflare ได้คิดค้นการป้องกันคีย์ของ TLS/SSL และพื้นที่เพื่อความปลอดภัยอย่างไม่หยุดยั้ง นี่เป็นสิ่งที่เปลี่ยนไปในหลายปีมานี้:

ปี 2014

• Certificate อายุ 5 ปี
• การเย็บเล่ม OCSP เมื่อมีโอกาส
• ไม่มี OCSP ที่ต้องเย็บเล่ม
• คีย์ในกระบวนการเผชิญกับอินเทอร์เน็ต
• ไม่มี Keyless SSL
• ไม่มี Delegated Credentials

ปี 2021

• Certificate ตลอดชีพที่กำหนดได้ (จากหนึ่งปีลดลงมาเป็นสองสัปดาห์ด้วย ACM)
• รองรับการเย็บเล่ม OCSP ได้ 100%
• รองรับ OCSP ที่ต้องเย็บเล่ม
• Keyless Everywhere
• Keyless SSL + รองรับ HSM คลาวด์! (ใหม่)
• Geo Key Manager
• รองรับ Delegated Credentialการปรับปรุงเหล่านี้และการปรับปรุงที่มากกว่านี้คือเหตุผลสำคัญว่าทำไม Cloudflare ถึงเป็นผู้นำในพื้นที่สำหรับความปลอดภัยและทำไม Heartbleed อันต่อไปจะไม่แย่เท่าที่อันก่อนหน้านี้