บันทึก ผู้แปล: เพื่อความสะดวกของผู้อ่าน วันที่จะถูกระบุตามเวลามอสโก
เมื่อเร็วๆ นี้ เราพลาดการหมดอายุของใบรับรองที่ใช้ในการลงนามส่วนเสริม ส่งผลให้ส่วนเสริมถูกปิดใช้งานสำหรับผู้ใช้ ตอนนี้ปัญหาส่วนใหญ่ได้รับการแก้ไขแล้ว ผมจึงอยากจะแบ่งปันรายละเอียดสิ่งที่เกิดขึ้นและงานที่ทำเสร็จแล้ว
ความเป็นมา: การเพิ่มเติมและลายเซ็น
ส่วนเสริมที่ติดตั้งจะต้องมี ลายเซ็นดิจิทัลซึ่งปกป้องผู้ใช้จากส่วนเสริมที่เป็นอันตราย และต้องมีการตรวจสอบส่วนเสริมขั้นต่ำโดยเจ้าหน้าที่ของ Mozilla เราเปิดตัวข้อกำหนดนี้ในปี 2015 เนื่องจากเรากำลังประสบปัญหาอยู่ ปัญหาร้ายแรง ด้วยส่วนเสริมที่เป็นอันตราย
วิธีการทำงาน: Firefox ทุกสำเนาจะมี "ใบรับรองหลัก" กุญแจสำคัญในการ "รูท" นี้ถูกเก็บไว้ใน โมดูลความปลอดภัยของฮาร์ดแวร์ (HSM)โดยไม่ต้องเข้าถึงเครือข่าย ทุก ๆ สองสามปีจะมีการลงนาม "ใบรับรองระดับกลาง" ใหม่ด้วยคีย์นี้ ซึ่งใช้ในการลงนามส่วนเสริม เมื่อนักพัฒนาส่งส่วนเสริม เราจะสร้าง "ใบรับรองสิ้นสุด" ชั่วคราวและลงนามโดยใช้ใบรับรองระดับกลาง ส่วนเสริมนั้นจะถูกลงนามด้วยใบรับรองขั้นสุดท้าย แผนผัง ดูเหมือนว่านี้.
โปรดทราบว่าใบรับรองแต่ละใบมี "หัวเรื่อง" (ผู้ที่ออกใบรับรองให้) และ "ผู้ออก" (ผู้ออกใบรับรอง) ในกรณีของใบรับรองหลัก "เรื่อง" = "ผู้ออก" แต่สำหรับใบรับรองอื่น ผู้ออกใบรับรองจะเป็นเรื่องของใบรับรองหลักที่มีการลงนาม
จุดสำคัญ: แต่ละ Add-on ได้รับการลงนามโดยใบรับรองปลายทางที่ไม่ซ้ำกัน แต่เกือบทุกครั้งใบรับรองสุดท้ายเหล่านี้จะถูกลงนามโดยใบรับรองระดับกลางเดียวกัน
หมายเหตุของผู้เขียน: ข้อยกเว้นคือการเพิ่มเติมที่เก่ามาก ในเวลานั้นมีการใช้ใบรับรองระดับกลางต่างๆ
ใบรับรองระดับกลางนี้ทำให้เกิดปัญหา: ใบรับรองแต่ละใบสามารถใช้ได้ในช่วงระยะเวลาหนึ่ง ก่อนหรือหลังช่วงเวลานี้ ใบรับรองไม่ถูกต้องและเบราว์เซอร์จะไม่ใช้โปรแกรมเสริมที่ลงนามโดยใบรับรองนี้ น่าเสียดายที่ใบรับรองระดับกลางหมดอายุในวันที่ 4 พฤษภาคม เวลา 4 น.
ผลที่ตามมาไม่ปรากฏทันที Firefox จะไม่ตรวจสอบลายเซ็นของส่วนเสริมที่ติดตั้งอย่างต่อเนื่อง แต่จะตรวจสอบประมาณหนึ่งครั้งทุกๆ 24 ชั่วโมง และเวลาในการตรวจสอบจะแตกต่างกันไปสำหรับผู้ใช้แต่ละราย เป็นผลให้บางคนประสบปัญหาทันที ในขณะที่บางคนประสบปัญหามากในภายหลัง อันดับแรกเราทราบถึงปัญหาในช่วงเวลาที่ใบรับรองหมดอายุ และเริ่มมองหาวิธีแก้ไขทันที
การลดความเสียหาย
เมื่อเราตระหนักถึงสิ่งที่เกิดขึ้น เราก็พยายามป้องกันไม่ให้สถานการณ์แย่ลง
ประการแรก พวกเขาหยุดรับและลงนามในเอกสารเพิ่มเติมใหม่ ไม่มีประโยชน์ที่จะใช้ใบรับรองที่หมดอายุสำหรับสิ่งนี้ เมื่อมองย้อนกลับไปฉันจะบอกว่าเราสามารถทิ้งทุกอย่างไว้เหมือนเดิมได้ ตอนนี้เรากลับมารับอาหารเสริมแล้ว
ประการที่สอง พวกเขาส่งการแก้ไขทันทีที่ทำให้ไม่สามารถตรวจสอบลายเซ็นได้ทุกวัน ดังนั้นเราจึงบันทึกผู้ใช้ที่เบราว์เซอร์ยังไม่มีเวลาตรวจสอบส่วนเสริมใน XNUMX ชั่วโมงที่ผ่านมา ขณะนี้การแก้ไขนี้ถูกถอนออกแล้วและไม่จำเป็นอีกต่อไป
การทำงานแบบขนาน
ตามทฤษฎีแล้ว วิธีแก้ไขปัญหาดูเรียบง่าย: สร้างใบรับรองระดับกลางที่ถูกต้องใหม่และลงนามส่วนเสริมแต่ละรายการอีกครั้ง น่าเสียดายที่สิ่งนี้ใช้ไม่ได้:
- เราไม่สามารถลงนามโปรแกรมเสริม 15 รายการอีกครั้งได้อย่างรวดเร็วในคราวเดียว ระบบไม่ได้ออกแบบมาสำหรับโหลดดังกล่าว
- หลังจากที่เราลงนามเพิ่มเติมแล้ว จะต้องส่งมอบเวอร์ชันที่อัปเดตให้กับผู้ใช้ ส่วนเสริมส่วนใหญ่ได้รับการติดตั้งจากเซิร์ฟเวอร์ Mozilla ดังนั้น Firefox จะค้นหาการอัปเดตภายใน XNUMX ชั่วโมงข้างหน้า แต่นักพัฒนาบางรายจะเผยแพร่ส่วนเสริมที่ลงนามแล้วผ่านช่องทางของบุคคลที่สาม ดังนั้นผู้ใช้จะต้องอัปเดตส่วนเสริมดังกล่าวด้วยตนเอง
แต่เราพยายามพัฒนาวิธีแก้ไขที่จะเข้าถึงผู้ใช้ทุกคนโดยไม่ต้องดำเนินการใดๆ มากนักหรือไม่ต้องดำเนินการใดๆ เลย
เรามาถึงกลยุทธ์หลักสองกลยุทธ์อย่างรวดเร็ว ซึ่งเราใช้ควบคู่กัน:
- อัปเดต Firefox เพื่อเปลี่ยนระยะเวลาความถูกต้องของใบรับรอง ซึ่งจะทำให้ส่วนเสริมที่มีอยู่กลับมาทำงานได้อีกครั้งอย่างน่าอัศจรรย์ แต่จะต้องมีการเผยแพร่และจัดส่ง Firefox เวอร์ชันใหม่
- สร้างใบรับรองที่ถูกต้องและโน้มน้าวให้ Firefox ยอมรับแทนใบรับรองที่มีอยู่ซึ่งหมดอายุแล้ว
เราตัดสินใจใช้ตัวเลือกแรกก่อน ซึ่งดูใช้การได้ค่อนข้างดี ในตอนท้ายของวัน พวกเขาได้เปิดตัวการแก้ไขครั้งที่สอง (ใบรับรองใหม่) ซึ่งเราจะพูดถึงในภายหลัง
การเปลี่ยนใบรับรอง
ดังที่ได้กล่าวไปแล้วข้างต้น จำเป็นต้องมี:
- สร้างใบรับรองที่ถูกต้องใหม่
- ติดตั้งระยะไกลใน Firefox
เพื่อให้เข้าใจว่าเหตุใดจึงใช้งานได้ เรามาดูรายละเอียดขั้นตอนการตรวจสอบส่วนเสริมกันดีกว่า ส่วนเสริมนั้นมาในรูปแบบชุดไฟล์ รวมถึงชุดใบรับรองที่ใช้สำหรับการลงนาม ด้วยเหตุนี้ สามารถตรวจสอบส่วนเสริมได้หากเบราว์เซอร์ทราบใบรับรองหลักซึ่งมีอยู่ใน Firefox ในขณะสร้าง อย่างไรก็ตาม ตามที่เราทราบแล้วว่าใบรับรองระดับกลางหมดอายุแล้ว ดังนั้นจึงไม่สามารถยืนยันส่วนเสริมได้
เมื่อ Firefox พยายามตรวจสอบส่วนเสริม จะไม่จำกัดเพียงการใช้ใบรับรองที่มีอยู่ในส่วนเสริมเท่านั้น เบราว์เซอร์จะพยายามสร้างกลุ่มใบรับรองที่ถูกต้องแทน โดยเริ่มจากใบรับรองสุดท้ายและดำเนินการต่อไปจนถึงระดับรูท ในระดับแรก เราเริ่มต้นด้วยใบรับรองสิ้นสุด จากนั้นค้นหาใบรับรองที่มีหัวเรื่องเป็นผู้ออกใบรับรองขั้นสุดท้าย (นั่นคือ ใบรับรองระดับกลาง) โดยทั่วไปใบรับรองระดับกลางนี้จะมาพร้อมกับส่วนเสริม แต่ใบรับรองใดๆ จากที่เก็บข้อมูลของเบราว์เซอร์ก็สามารถใช้เป็นใบรับรองระดับกลางนี้ได้ หากเราสามารถเพิ่มใบรับรองที่ถูกต้องใหม่ไปยังที่เก็บใบรับรองจากระยะไกลได้ Firefox จะพยายามใช้งาน สถานการณ์ก่อนและหลังการติดตั้งใบรับรองใหม่.
หลังจากติดตั้งใบรับรองใหม่ Firefox จะมีสองตัวเลือกในการตรวจสอบกลุ่มใบรับรอง: ใช้ใบรับรองเก่าที่ไม่ถูกต้อง (ซึ่งจะใช้งานไม่ได้) หรือใบรับรองใหม่ที่ถูกต้อง (ซึ่งจะใช้งานได้) สิ่งสำคัญคือใบรับรองใหม่จะต้องมีชื่อเรื่องและคีย์สาธารณะเดียวกันกับใบรับรองเก่า ดังนั้นลายเซ็นบนใบรับรองขั้นสุดท้ายจึงจะมีผลใช้ได้ Firefox ฉลาดพอที่จะลองใช้ทั้งสองตัวเลือกจนกว่าจะเจอตัวเลือกที่ใช้งานได้ ดังนั้นส่วนเสริมจึงได้รับการทดสอบอีกครั้ง โปรดทราบว่านี่เป็นตรรกะเดียวกับที่เราใช้ตรวจสอบใบรับรอง TLS
หมายเหตุผู้เขียน: ผู้อ่านที่คุ้นเคยกับ WebPKI จะทราบว่าใบรับรองข้ามทำงานในลักษณะเดียวกันทุกประการ
ข้อดีของการแก้ไขนี้คือ คุณไม่จำเป็นต้องลงนามโปรแกรมเสริมที่มีอยู่อีกครั้ง ทันทีที่เบราว์เซอร์ได้รับใบรับรองใหม่ ส่วนเสริมทั้งหมดจะทำงานได้อีกครั้ง ความท้าทายที่เหลืออยู่คือการส่งมอบใบรับรองใหม่ให้กับผู้ใช้ (โดยอัตโนมัติและจากระยะไกล) รวมถึงการได้รับ Firefox เพื่อตรวจสอบโปรแกรมเสริมที่ถูกปิดใช้งานอีกครั้ง
นอร์มังดีและระบบการวิจัย
น่าแปลกที่ปัญหานี้แก้ไขได้ด้วยส่วนเสริมพิเศษที่เรียกว่า "ระบบ" ในการทำการวิจัย เราได้พัฒนาระบบที่เรียกว่า Normandy ซึ่งนำเสนอการวิจัยแก่ผู้ใช้ การศึกษาเหล่านี้ดำเนินการโดยอัตโนมัติในเบราว์เซอร์ และปรับปรุงการเข้าถึง API ภายในของ Firefox การวิจัยสามารถเพิ่มใบรับรองใหม่ไปยังที่เก็บใบรับรองได้
หมายเหตุผู้เขียน: เราไม่ได้เพิ่มใบรับรองพร้อมสิทธิพิเศษใดๆ มันถูกลงนามโดยใบรับรองหลัก ดังนั้น Firefox จึงเชื่อถือ เราเพียงเพิ่มลงในกลุ่มใบรับรองที่เบราว์เซอร์สามารถใช้ได้
ดังนั้นแนวทางแก้ไขคือสร้างการศึกษา:
- ติดตั้งใบรับรองใหม่ที่เราสร้างขึ้นสำหรับผู้ใช้
- บังคับให้เบราว์เซอร์ตรวจสอบส่วนเสริมที่ถูกปิดใช้งานอีกครั้งเพื่อให้ทำงานได้อีกครั้ง
“แต่เดี๋ยวก่อน” คุณพูด “ส่วนเสริมใช้งานไม่ได้ ฉันจะเปิดส่วนเสริมของระบบได้อย่างไร” มาลงนามด้วยใบรับรองใหม่กันเถอะ!
รวมทุกอย่างแล้ว...ทำไมมันนานจังล่ะ?
ดังนั้นแผน: ออกใบรับรองใหม่เพื่อทดแทนอันเก่า สร้างส่วนเสริมของระบบ และติดตั้งให้กับผู้ใช้ผ่านทาง Normandy อย่างที่ฉันบอกไปแล้วว่าปัญหาเริ่มต้นในวันที่ 4 พฤษภาคมเวลา 4:00 น. และเวลา 12:44 น. ของวันเดียวกัน น้อยกว่า 9 ชั่วโมงต่อมาเราได้ส่งวิธีแก้ไขไปยังนอร์มังดี ใช้เวลาอีก 6-12 ชั่วโมงในการเข้าถึงผู้ใช้ทั้งหมด ไม่เลวเลย แต่ผู้คนบน Twitter ต่างถามว่าทำไมเราไม่สามารถดำเนินการได้เร็วกว่านี้
ประการแรก ต้องใช้เวลาในการออกใบรับรองระดับกลางใหม่ ดังที่ฉันได้กล่าวไว้ข้างต้น คีย์ไปยังใบรับรองหลักจะถูกจัดเก็บแบบออฟไลน์ในโมดูลความปลอดภัยของฮาร์ดแวร์ นี่เป็นสิ่งที่ดีจากมุมมองด้านความปลอดภัย เนื่องจากมีการใช้รูทน้อยมากและควรได้รับการปกป้องที่เชื่อถือได้ แต่จะไม่สะดวกเล็กน้อยเมื่อคุณต้องการลงนามในใบรับรองใหม่อย่างเร่งด่วน วิศวกรคนหนึ่งของเราต้องเดินทางไปยังสถานที่จัดเก็บ HSM จากนั้น มีการพยายามออกใบรับรองที่ถูกต้องไม่สำเร็จ และความพยายามแต่ละครั้งจะใช้เวลาหนึ่งหรือสองชั่วโมงในการทดสอบ
ประการที่สอง การพัฒนาส่วนเสริมของระบบใช้เวลาพอสมควร ตามแนวคิดแล้ว มันง่ายมาก แต่แม้แต่โปรแกรมธรรมดาๆ ก็ต้องการการดูแลเอาใจใส่ เราต้องการให้แน่ใจว่าเราไม่ได้ทำให้สถานการณ์แย่ลง ต้องมีการทดสอบการวิจัยก่อนส่งถึงผู้ใช้ นอกจากนี้ จะต้องลงนามส่วนเสริม แต่ระบบการลงนามส่วนเสริมของเราถูกปิดใช้งาน ดังนั้นเราจึงต้องหาวิธีแก้ปัญหาชั่วคราว
ในที่สุด เมื่อเราเตรียมงานวิจัยที่พร้อมส่งแล้ว การปรับใช้ก็ต้องใช้เวลา เบราว์เซอร์จะตรวจสอบการอัปเดต Normandy ทุก 6 ชั่วโมง คอมพิวเตอร์บางเครื่องไม่ได้เปิดและเชื่อมต่อกับอินเทอร์เน็ตตลอดเวลา ดังนั้นจึงต้องใช้เวลาก่อนที่การแก้ไขจะแพร่กระจายไปยังผู้ใช้
ขั้นตอนสุดท้าย
การวิจัยควรแก้ไขปัญหาให้กับผู้ใช้ส่วนใหญ่ แต่ก็ไม่สามารถใช้งานได้กับทุกคน ผู้ใช้บางรายต้องการวิธีการพิเศษ:
- ผู้ใช้ที่ปิดใช้งานการวิจัยหรือการตรวจวัดทางไกล
- ผู้ใช้เวอร์ชัน Android (Fennec) ซึ่งไม่รองรับการวิจัยเลย
- ผู้ใช้ Firefox ESR รุ่นที่กำหนดเองในองค์กรที่ไม่สามารถเปิดใช้งานการตรวจวัดทางไกลได้
- ผู้ใช้ที่อยู่ด้านหลังพร็อกซี MitM เนื่องจากระบบการติดตั้งส่วนเสริมของเราใช้การปักหมุดคีย์ ซึ่งใช้ไม่ได้กับพรอกซีดังกล่าว
- ผู้ใช้ Firefox เวอร์ชันเก่าที่ไม่สนับสนุนการวิจัย
เราไม่สามารถทำอะไรกับผู้ใช้ประเภทหลังได้ - พวกเขาควรอัปเดตเป็น Firefox เวอร์ชันใหม่ เนื่องจากผู้ใช้ที่ล้าสมัยมีช่องโหว่ร้ายแรงที่ไม่ได้รับการอัปเดต เรารู้ว่าบางคนใช้ Firefox เวอร์ชันเก่าอยู่เพราะต้องการเรียกใช้ส่วนเสริมเก่า แต่ส่วนเสริมเก่าๆ จำนวนมากได้รับการย้ายไปยังเบราว์เซอร์เวอร์ชันใหม่กว่าแล้ว สำหรับผู้ใช้รายอื่น เราได้พัฒนาแพตช์ที่จะติดตั้งใบรับรองใหม่ มันถูกปล่อยออกมาเป็นรุ่นแก้ไขข้อบกพร่อง (หมายเหตุผู้แปล: Firefox 66.0.5) เพื่อให้ผู้คนได้รับ - มีแนวโน้มว่าจะได้รับแล้ว - ผ่านช่องทางการอัปเดตปกติ หากคุณใช้ Firefox ESR รุ่นที่กำหนดเอง โปรดติดต่อผู้ดูแลของคุณ
เราเข้าใจว่าสิ่งนี้ไม่เหมาะ ในบางกรณี ผู้ใช้สูญเสียข้อมูลส่วนเสริม (เช่น ข้อมูลส่วนเสริม คอนเทนเนอร์หลายบัญชี).
ไม่สามารถหลีกเลี่ยงผลข้างเคียงนี้ได้ แต่เราเชื่อว่าในระยะสั้นเราได้เลือกทางออกที่ดีที่สุดสำหรับผู้ใช้ส่วนใหญ่ ในระยะยาว เราจะมองหาแนวทางสถาปัตยกรรมขั้นสูงอื่นๆ
บทเรียน
ประการแรก ทีมของเราทำงานได้อย่างยอดเยี่ยมในการสร้างและจัดส่งโปรแกรมแก้ไขภายในเวลาไม่ถึง 12 ชั่วโมงหลังจากค้นพบปัญหา ในฐานะคนที่เข้าร่วมประชุม ผมบอกได้เลยว่าในสถานการณ์ที่ยากลำบากนี้ ผู้คนทำงานหนักมากและเสียเวลาน้อยมาก
เห็นได้ชัดว่าสิ่งนี้ไม่ควรเกิดขึ้นเลย เห็นได้ชัดว่าคุ้มค่าที่จะปรับกระบวนการของเราเพื่อลดโอกาสที่จะเกิดเหตุการณ์ดังกล่าวและทำให้การแก้ไขง่ายขึ้น
สัปดาห์หน้า เราจะเผยแพร่ผลชันสูตรอย่างเป็นทางการและรายการการเปลี่ยนแปลงที่เราตั้งใจจะทำ สำหรับตอนนี้ ฉันจะแบ่งปันความคิดของฉัน ประการแรก จะต้องมีวิธีที่ดีกว่าในการตรวจสอบสถานะของระเบิดเวลาที่อาจเกิดขึ้น เราต้องแน่ใจว่าเราไม่ได้ตกอยู่ในสถานการณ์ที่หนึ่งในนั้นทำงานกะทันหัน เรายังคงหารายละเอียดอยู่ แต่อย่างน้อยที่สุดก็จำเป็นต้องคำนึงถึงสิ่งเหล่านี้ทั้งหมด
ประการที่สอง เราต้องการกลไกในการส่งมอบการอัปเดตให้กับผู้ใช้อย่างรวดเร็ว แม้ว่าโดยเฉพาะอย่างยิ่งเมื่อสิ่งอื่นๆ ล้มเหลวก็ตาม เป็นเรื่องดีที่เราสามารถใช้ระบบ "การวิจัย" ได้ แต่มันเป็นเครื่องมือที่ไม่สมบูรณ์และมีผลข้างเคียงที่ไม่พึงประสงค์ โดยเฉพาะอย่างยิ่ง เรารู้ว่าผู้ใช้จำนวนมากเปิดการอัปเดตอัตโนมัติไว้ แต่ไม่ต้องการเข้าร่วมการวิจัย (ฉันยอมรับว่า ฉันก็ปิดการอัปเดตอัตโนมัติเช่นกัน!) ในเวลาเดียวกัน เราต้องการวิธีในการส่งการอัปเดตไปยังผู้ใช้ แต่ไม่ว่าการใช้งานทางเทคนิคภายในจะเป็นเช่นไร ผู้ใช้ควรจะสามารถสมัครรับการอัปเดตได้ (รวมถึงโปรแกรมแก้ไขด่วน) แต่เลือกที่จะไม่รับอย่างอื่นทั้งหมด นอกจากนี้ ช่องทางการอัปเดตควรตอบสนองได้ดีกว่าที่เป็นอยู่ในปัจจุบัน แม้ในวันที่ 6 พฤษภาคม ก็ยังมีผู้ใช้ที่ไม่ได้ใช้ประโยชน์จากการแก้ไขหรือเวอร์ชันใหม่ ปัญหานี้ได้รับการแก้ไขแล้ว แต่สิ่งที่เกิดขึ้นแสดงให้เห็นว่าปัญหานี้มีความสำคัญเพียงใด
สุดท้ายนี้ เราจะมาดูสถาปัตยกรรมความปลอดภัยของส่วนเสริมอย่างละเอียดยิ่งขึ้น เพื่อให้แน่ใจว่ามีการรักษาความปลอดภัยในระดับที่เหมาะสมโดยมีความเสี่ยงน้อยที่สุดที่จะทำลายสิ่งใดๆ
สัปดาห์หน้าเราจะดูผลลัพธ์ของการวิเคราะห์สิ่งที่เกิดขึ้นอย่างละเอียดมากขึ้น แต่ในระหว่างนี้ ฉันยินดีที่จะตอบคำถามทางอีเมล: [ป้องกันอีเมล]
ที่มา: linux.org.ru