Tim Hudson, ประธานของ OpenSSL Corporation – ชุดสัมภาษณ์

Tim Hudson เป็นผู้ร่วมเขียน SSLeay และเป็นหนึ่งในผู้จัด OpenSSL Conference ที่ปรากราฟ ระหว่าง 13‑15 ตุลาคม 2026 เขามีประสบการณ์ด้านระบบและความปลอดภัยเครือข่ายมากกว่า 30 ปีและดำรงตำแหน่งประธานของ OpenSSL Corporation และหัวหน้าฝ่ายเทคโนโลยี (Chief Technology Officer) ที่ Cryptsoft Pty Ltd. ตั้งแต่ปี 1995 งานของเขารวมถึงการก่อตั้งร่วม SSLeay กับ Eric Young, ไลบรารีการเข้ารหัสที่ต่อมาเป็น OpenSSL Library, การก่อตั้งศูนย์พัฒนา RSA Security Australia, การมีส่วนร่วมในการเปลี่ยนแปลงกฎระเบียบการส่งออกการเข้ารหัสของสหรัฐ, การเป็นหัวหน้าการตรวจสอบ FIPS 140 มากกว่า 30 ครั้ง, การเป็นประธานร่วมคณะกรรมการเทคนิค OASIS KMIP และ SAM, และการบรรยายในงานประชุมความปลอดภัยชั้นนำหลายงาน เช่น RSA Conference, AusCERT, ICMC, LinuxConf และ OpenSSL Conference.

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

คุณร่วมก่อตั้ง SSLeay กับ Eric Young ในปี 1995 หลังจากเห็นความจำเป็นที่จะต้องมีการพัฒนา SSL นอกสหรัฐฯ และผลงานนั้นได้กลายมาเป็นรากฐานของ OpenSSL เดิมทีคุณต้องการแก้ปัญหาอะไร และในเวลานั้นเคยคิดหรือไม่ว่าเทคโนโลยีนี้จะกลายเป็นส่วนสำคัญอย่างยิ่งของการรักษาความปลอดภัยบนอินเทอร์เน็ต?

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

สิ่งที่ฉันมีคือความรู้เกี่ยวกับสิ่งที่หลายคนลืมไป Eric Young เคยเขียนการนำเข้า DES เมื่อหลายปีก่อน : โค้ดที่ดี, สะอาด, ฟรี, เขียนเพื่อความสนุกของตนเองและไม่มีส่วนเกี่ยวข้องกับ SSL Eric ไม่ได้ทำงานเกี่ยวกับ SSL และก็ไม่ได้รับรู้ถึง SSL เมื่อ Netscape เผยแพร่สเปคฉันก็อ่านมัน, ไปหา Eric พร้อมปัญหาและอธิบายว่าเป็นขั้นตอนที่ไม่ยากเกินไปจากที่เขามีอยู่แล้ว

นี่ไม่ได้เป็นภาพรวมทั้งหมด แต่ละส่วนเป็นเรื่องง่ายแต่ก็มีหลายส่วนที่ซับซ้อน การนำเข้า DES ให้คุณได้เพียงหนึ่งอัลกอริทึมสมมาตร SSL ต้องการการเข้ารหัสแบบกุญแจสาธารณะ, คณิตศาสตร์ความแม่นยำไม่จำกัด, ASN.1, การจัดการใบรับรอง X.509, และเครื่องสถานะของโพรโทคอล, ทั้งหมดต้องถูกต้อง เพราะในด้านการเข้ารหัส “เกือบ‑ถูกต้อง” กับ “เสีย” คือสิ่งเดียวกัน ฉันได้อธิบายขนาดของงานอย่างมองโลกในแง่ดี Eric จึงได้คำนวนเร็วว่า มีอะไรบ้างและเขาก็ชอบมัน เพราะขนาดของงานกลับกลายเป็นแรงจูงใจ ไม่ใช่อุปสรรค ฉันไม่แน่ใจว่ามันจะเริ่มต้นอย่างอื่นได้หรือไม่

เขาทำส่วนแกนการเข้ารหัส, ซึ่งเป็นเหตุผลที่ไลบรารีมีอักษรย่อของเขาอยู่ ฉันรับผิดชอบส่วนที่ทำให้ไลบรารีกลายเป็นสิ่งที่คนอื่นสามารถใช้งานได้ : การรวมแอปพลิเคชัน, การทดสอบ, เอกสารและส่วนของชุมชน ฉันยังตามหาและแทนที่ไลบรารีการเข้ารหัสที่แข่งกันอยู่ทุกที่ SSLtelnet, SSLftp, NCSA httpd และแพคเกจอื่น ๆ อีกหลายรายการเป็นผลงานของฉัน, แอปพลิเคชันที่สร้างบนอัลกอริทึมและโพรโทคอลที่ Eric พัฒนา การผสมผสานนี้ทำให้แต่ละคนโฟกัสที่สิ่งที่ตนสนใจจริง ๆ ซึ่งเป็นเหตุผลหลักที่ทำให้โครงการดำเนินต่อไป

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

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

คุณทำงานด้านการเข้ารหัสและความปลอดภัยอินเทอร์เน็ตมานานกว่าสามทศวรรษ ภูมิทัศน์ภัยคุกคามเปลี่ยนแปลงไปมากที่สุดในด้านใด และปัญหาความปลอดภัยใดที่ยังคงคล้ายเดิมอย่างน่าประหลาดใจ แม้เทคโนโลยีจะก้าวหน้าไปอย่างมาก?

การเปลี่ยนแปลงที่ใหญ่ที่สุดคือการโจมตีระบบกลายเป็นอาชีพที่มีโมเดลทางเศรษฐกิจเป็นพื้นฐาน ในช่วงกลางทศวรรษ 1990 ผู้ที่แฮ็กระบบทำเพราะมันน่าสนใจ วันนี้มีอุตสาหกรรมที่มีความเชี่ยวชาญ, เครื่องมือ, โซ่อุปทาน, การสนับสนุนลูกค้า และบางกรณีได้รับเงินสนับสนุนจากรัฐ สิ่งนี้เปลี่ยนแปลงทุกอย่างเกี่ยวกับวิธีคิด เพราะคุณไม่ได้ต่อสู้กับความอยากรู้อยากเห็นแล้ว แต่ต่อสู้กับผู้มีงบประมาณ, กำหนดเวลาและกรณีธุรกิจ

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

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

OpenSSL 4.0 เปิดตัวในเดือนเมษายน 2026 นับเป็นรุ่นใหญ่ครั้งแรกของโครงการในรอบหลายปี รุ่นนี้บอกอะไรเกี่ยวกับทิศทางของโครงสร้างพื้นฐานด้านการเข้ารหัส และคุณคิดว่าการเปลี่ยนแปลงใดจะสำคัญที่สุดต่อองค์กรที่พึ่งพา OpenSSL?

สิ่งที่ควรเข้าใจที่สุดเกี่ยวกับ 4.0 คือมันเป็นการปลดล้าง (subtraction) เป็นเหตุผลหลักของการปล่อยเวอร์ชันนี้

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

มีการเพิ่มเข้ามาใหม่ : Encrypted Client Hello, การสนับสนุน RFC 8998 รวมถึงกลุ่มไฮบริด SM2/ML‑KEM, cSHAKE, SNMP และ SRTP KDFs, การเจรจา FFDHE สำหรับ TLS 1.2. ECH โดยเฉพาะปิดช่องว่างด้านความเป็นส่วนตัวที่แท้จริง เพราะ Server Name Indication รั่วไหลข้อมูลของทุกเว็บไซต์ที่คุณเยี่ยมชมตั้งแต่ TLS 1.3 เปิดตัว แต่การลบคือเรื่องหลัก

ข้อสรุปที่ฉันอยากให้องค์กรจำได้คือ : 4.0 ไม่ใช่รุ่น LTS รองรับจนถึงพฤษภาคม 2027 รุ่น LTS ปัจจุบันคือ 3.5 รองรับจนถึงเมษายน 2030 และ 3.5 มีอัลกอริทึมหลังควอนตัมอยู่แล้ว หากคุณต้องการโค้ดใหม่ที่สุดให้ใช้ 4.0 หากต้องการเป้าหมายที่มั่นคงเพื่อวางแผนการย้ายระยะห้าปีให้ใช้ 3.5 การเลือกเลขรุ่นที่สูงกว่าเพียงเพราะเป็นเลขที่สูงกว่าเป็นความผิดพลาดที่เราเห็นบ่อยทุกรอบ

การเข้ารหัสหลังยุคควอนตัมกำลังเปลี่ยนจากโจทย์วิจัยเป็นความท้าทายในการย้ายระบบ โดย OpenSSL รองรับ ML-KEM, ML-DSA, SLH-DSA และการแลกเปลี่ยนกุญแจแบบไฮบริดหลังยุคควอนตัมแล้ว ผู้นำธุรกิจที่คิดว่าคอมพิวเตอร์ควอนตัมยังอยู่อีกไกลจนไม่ต้องกังวล กำลังมองข้ามความเสี่ยงใดในวันนี้?

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

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

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

สิ่งที่สามคือข้อจำกัดที่ไม่มีใครจัดสรรงบประมาณให้ : ลายเซ็นหลังควอนตัมมีขนาดใหญ่ ML‑DSA‑65 มีขนาดประมาณห้าสิบเท่าของลายเซ็น ECDSA P‑256 และ SLH‑DSA ใหญ่กว่าอีก การเพิ่มขนาดนี้ทำให้เกิดปัญหาในขนาดการจับมือ, อุปกรณ์ที่มีข้อจำกัด, โปรโตคอลที่มีขีดจำกัดฟิลด์, ลิงก์ดาวเทียมและ IoT คุณจะพบปัญหาเหล่านี้จากการทดสอบ ไม่ได้จากการอ่านมาตรฐาน

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

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

คุณต้องมองหา มีสามชั้นและต้องใช้เทคนิคที่แตกต่างกัน โค้ดที่คุณเขียน : การวิเคราะห์แบบสถิตย์, การสแกนการพึ่งพา, และการค้นหาอัลกอริทึมที่คุณเขียนแบบฮาร์ดโค้ดหลายปีก่อน โค้ดที่คุณลิงก์ : รายการวัสดุซอฟต์แวร์ (software bill of materials) ที่ขยายเป็นรายการวัสดุการเข้ารหัส (cryptographic bill of materials) ซึ่งเป็นที่ทำงานของ CBOM ที่เป็นประโยชน์จริง สิ่งที่คุณซื้อหรือเชื่อมต่อ : การสังเกตเครือข่าย, เพราะสิ่งที่ระบบของคุณเจรจาบนสายเป็นความจริงพื้นฐานและบ่อยครั้งไม่ตรงกับที่ใครก็เชื่อ

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

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

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

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

AI ทำการเปลี่ยนแปลงสิ่งหนึ่งจริง ๆ และฉันพูดถึงมันโดยตรงเพราะมันเกิดขึ้นกับเรา

จำนวนมากของช่องโหว่ที่เปิดเผยใน OpenSSL ปีนี้พบโดยการวิเคราะห์ที่ขับเคลื่อนด้วย AI ในเดือนมกราคมเราออกเวอร์ชันที่แก้ไข 12 ปัญหา, ส่วนใหญ่จากกลุ่มวิจัยหนึ่งที่ใช้การวิเคราะห์อัตโนมัติและพวกเขายังส่งแพตช์พร้อมกับรายงาน ในเดือนมิถุนายนเราแก้ไขการใช้‑หลัง‑อิสระที่รุนแรงในการตรวจสอบ PKCS#7 ที่พบโดยนักวิจัยที่ทำงานกับระบบ AI นั่นเป็นการเปลี่ยนแปลงความสามารถจริง ๆ ในการค้นหาบั๊กด้านความปลอดภัยหน่วยความจำและการพาร์สในโค้ด C ที่ผ่านการตรวจสอบโดยผู้เชี่ยวชาญหลายปี ฉันได้เห็นรูปแบบเดียวกันในไลบรารีการเข้ารหัสอื่น ๆ การวิเคราะห์ชุดของ CVE ของ Bouncy Castle ปีนี้ทำให้เห็นรอยของการวิเคราะห์โค้ดอัตโนมัติอย่างชัดเจน

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

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

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

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

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

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

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

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

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

จากนั้นให้ฝึกซ้อม การฝึกจำลองระดับผู้บริหารปีละครั้งจะเปิดเผยช่องว่างที่แท้จริงมากกว่าการเพิ่มเครื่องมืออีกชิ้น

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

องค์กรที่จัดการได้ดีคือได้ทำการตัดสินใจสำคัญล่วงหน้าแล้ว, ดังนั้นในเหตุการณ์พวกเขากำลังดำเนินการแทนที่จะต้องคิดใหม่ นั่นคือส่วนใหญ่ของความแตกต่าง

นอกเหนือจากการเตรียมการ, มีหลายสิ่งที่แยกการตอบสนองที่ดีออกจากที่แย่

พวกเขาแยกการสืบสวนเชิงเทคนิคออกจากเส้นทางผู้บริหารและการสื่อสาร, มีอินเทอร์เฟซที่กำหนดชัดเจนระหว่างสองส่วน หากคนเดียวพยายามกักข้อบกพร่องและร่างการแจ้งลูกค้า งานทั้งสองมักทำได้แย่

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

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

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

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

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

การคาดการณ์คือสิ่งที่เราต้องให้กับผู้ใช้ เราปล่อยเวอร์ชันฟีเจอร์ในเดือนเมษายนและตุลาคม เราบอกล่วงหน้าว่าเวอร์ชันใดเป็น LTS และจนถึงเมื่อไหร่ เราแจ้งการลบคุณลักษณะสำคัญล่วงหน้า การลบ ENGINE ใน 4.0 ถูกอธิบายสาธารณะหลายเดือนก่อนการปล่อยและได้รับความเห็นชอบจากทั้ง Corporation และ Foundation ผู้ที่ประหลาดใจในเดือนเมษายนไม่ได้ใส่ใจและเราทำให้การติดตามง่ายที่สุดเท่าที่เราสามารถทำได้

คำตอบเชิงโครงสร้างคือการแยกออกจากกันเองเองเอง : Foundation มีไว้เพื่อให้บริการไลบรารีโอเพ่นซอร์สและชุมชนที่อยู่รอบ ๆ มัน Corporation มีไว้เพื่อให้บริการองค์กรที่มีความต้องการเชิงพาณิชย์ (การสนับสนุน, การตรวจสอบ FIPS, กำหนดเวลาที่เฉพาะเจาะจง) และทำให้โครงการทั้งหมดยั่งยืนทางการเงิน การแยกเหล่านี้หมายความว่าความต้องการของแต่ละฝ่ายไม่ได้ถูกแก้ไขโดยเงียบ ๆ ในฝ่ายอื่น เมื่อความต้องการขององค์กรและของชุมชนขัดแย้งกันจริง ๆ ความขัดแย้งจะเกิดขึ้นระหว่างสององค์กรที่มีขอบเขตชัดเจน แทนที่จะอยู่ในหัวของคนคนเดียว

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

เมื่อมองไปยังทศวรรษหน้า คุณคิดว่าองค์กรยังประเมินการเปลี่ยนผ่านด้านความปลอดภัยหรือการเข้ารหัสเรื่องใดต่ำเกินไป และผู้นำควรนำบทเรียนใดจากวิวัฒนาการของ SSL, OpenSSL และความปลอดภัยอินเทอร์เน็ตตลอด 30 ปีที่ผ่านมาไปใช้ในการเตรียมพร้อม?

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

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

ขนานกับนั้นคือการเปลี่ยนแปลงด้านกฎระเบียบ Cyber Resilience Act ในยุโรปและกรอบงานที่คล้ายกันในที่อื่น ๆ จะเปลี่ยนภาระหน้าที่ของการส่งซอฟต์แวร์ที่มีส่วนประกอบที่คุณไม่ได้เขียนเอง ส่วนใหญ่ขององค์กรยังไม่ได้พิจารณาว่ามันหมายความว่าอย่างไรต่อการพึ่งพาโอเพ่นซอร์สหรือผู้ที่ดูแลมัน

สามบทเรียนจากสามทศวรรษ :

1. การเปลี่ยนแปลงใช้เวลานานกว่าที่ประกาศไว้หนึ่งทศวรรษ SSLv3 ถูกยกเลิกในปี 2015, ปิดการใช้งานโดยค่าเริ่มต้นในปี 2016, และเราลบโค้ดนั้นในเดือนเมษายน 2026 นั่นคือสิบเอ็ดปีสำหรับโพรโทคอลที่ทุกคนเห็นว่าเสียหาย ควรวางแผนการย้าย post‑quantum ตามความเป็นจริงนี้ ไม่ใช่ตามข่าวประชาสัมพันธ์
2. ค่าเริ่มต้นเป็นการควบคุมความปลอดภัยเดียวที่ทำงานได้ในระดับใหญ่ สิ่งใดที่ต้องการให้ผู้ดูแลทุกคนตัดสินใจอย่างถูกต้องจะไม่มีวันเกิดขึ้น เหตุผลที่การแลกเปลี่ยนคีย์หลังควอนตัมแบบไฮบริดถูกนำไปใช้เร็วขนาดนี้คือเปิดใช้งานโดยค่าเริ่มต้นและไม่ต้องการการตัดสินใจใด ๆ ออกแบบสำหรับผู้ที่ไม่มีวันอ่านเอกสารของคุณ เพราะนั่นคือเกือบทุกคน
3. คุณพึ่งพาผู้คนน้อยกว่าที่คิด เกือบทุกองค์กรบนโลกพึ่งพาโค้ดการเข้ารหัสที่ดูแลโดยบุคคลจำนวนเล็กมาก ซึ่งเป็นความจริงตั้งแต่เราสองคนในบริสเบนและโครงสร้างยังไม่ได้เปลี่ยนแปลงแม้ความเสี่ยงจะเพิ่มเป็นหลายเท่าตัว สิ่งที่คุณกำลังวางแผนสำหรับทศวรรษหน้า, ส่วนหนึ่งของมันพึ่งพาผู้ดูแลที่คุณไม่เคยติดต่อและไม่ได้ให้เงินสนับสนุน นั่นคือสิ่งที่ควรรู้ก่อนที่คุณจะต้องพึ่งพาเขา

ขอบคุณสำหรับบทสัมภาษณ์ที่ดี ผู้อ่านที่ต้องการทราบเพิ่มเติมสามารถเข้าไปที่ OpenSSL.