ทำไมต้องใช้ CAA
นักวิทยาศาสตร์คอมพิวเตอร์ Phillip Hallam-Baker และ Rob Stradling พัฒนา CAA ขึ้นเพื่อตอบสนองต่อความกังวลที่เพิ่มขึ้นเกี่ยวกับความปลอดภัยของหน่วยงานรับรองที่น่าเชื่อถือต่อสาธารณะ ความคิดริเริ่มนี้อยู่ภายใต้ Internet Engineering Task Force (IETF) ซึ่งเป็นองค์กรพัฒนามาตรฐาน (SDO) ชั้นนำสำหรับอินเทอร์เน็ต IETF สร้างมาตรฐานโดยสมัครใจที่ได้รับการยอมรับอย่างกว้างขวางจากผู้ใช้อินเทอร์เน็ต ผู้ให้บริการเครือข่าย และผู้จำหน่ายอุปกรณ์ ซึ่งมีอิทธิพลต่อวิวัฒนาการของอินเทอร์เน็ต
IETF จัดทำเอกสารมาตรฐานทางเทคนิคในเอกสารเผยแพร่ที่เรียกว่า RFC (Requests for Comments) เอกสารเหล่านี้จะระบุประเด็นสำคัญของโครงสร้างพื้นฐานอินเทอร์เน็ต รวมถึงการระบุที่อยู่ การกำหนดเส้นทาง และเทคโนโลยีการขนส่ง CAA ถูกกำหนดไว้โดยเฉพาะใน RFC 6844.
ผู้มีอำนาจออกใบรับรอง (CA) มักใช้วิธีการดังต่อไปนี้ การตรวจสอบโดเมน เพื่อให้แน่ใจว่า SSL /TLS คำขอใบรับรองได้รับอนุญาต (โดยปกติจะทำให้แน่ใจว่ามีการลิงก์ในบางเว็บไซต์ที่ใช้โดเมนนั้น)
ตัวอย่างเช่น CA อาจให้ไฟล์การตรวจสอบพิเศษแก่ผู้ร้องขอ การวางไฟล์นี้บนเว็บไซต์เป็นการพิสูจน์ว่าผู้ร้องขอยังควบคุมเว็บไซต์นั้น แต่ไม่สามารถรับประกันได้ว่า ถูกต้องตามกฎหมาย ของการควบคุมนั้น แฮกเกอร์ที่ได้รับการควบคุมไซต์อาจปลอมตัวเป็นเจ้าของที่ถูกต้องและสามารถร้องขอและรับ SSL /TLS ใบรับรองที่ผ่านการตรวจสอบมาตรฐานของ CA ดังนั้น ดูเหมือนว่า ถูกต้องตามกฎหมาย จากนั้นพวกเขาสามารถหันกลับมาและใช้ SSL นั้น /TLS ใบรับรองการก่อความเสียหายในไซต์นั้นหรือที่อื่น ๆ
CAA ช่วยป้องกันการใช้ประโยชน์ประเภทนี้โดยการกำหนดว่า CA ใดได้รับอนุญาตให้ออกใบรับรองสำหรับโดเมน (หรือแม้กระทั่ง จำกัด การออกใบรับรองทั้งหมด) สิ่งนี้จะจำกัดความเสียหายที่นักจี้สามารถสร้างได้แม้ว่าพวกเขาจะสามารถควบคุมไซต์ได้ แต่พวกเขาก็มีตัวเลือกน้อยลงอย่างมากในการทำคะแนน SSL ที่หลอกลวงTLS ใบรับรอง
CNAME คืออะไร?
ระเบียน CNAME เป็นประเภทการกำหนดค่า DNS ที่อนุญาตให้มีโดเมนหนึ่งโดเมน เช่น ร้านค้า mybusiness.com, เพื่อทำหน้าที่เป็นนามแฝงให้กับผู้อื่น เช่น มายบิสซิเนส.คอมแทนที่จะต้องจัดการระเบียน A หลายรายการเพื่อสะท้อนการเปลี่ยนแปลงที่อยู่ IP CNAME จะทำให้ขั้นตอนนี้ง่ายขึ้นโดยชี้ชื่อแทนไปยังโดเมนเป้าหมาย วิธีนี้มีประโยชน์อย่างยิ่งสำหรับธุรกิจที่เปลี่ยนโฮสต์เว็บหรือผู้ให้บริการ CDN เป็นประจำ นอกจากนี้ ระเบียน CNAME ยังมีค่าอย่างยิ่งสำหรับการสร้างระบบเฟลโอเวอร์ ซึ่งการรับส่งข้อมูลจะถูกส่งไปยังเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์รอง เพื่อให้แน่ใจว่าบริการจะดำเนินต่อไปได้ในระหว่างที่หยุดให้บริการ
ในบริบทของการอนุญาตผู้มีอำนาจออกใบรับรอง (CAA) ระเบียน CNAME จะมีอิทธิพลต่อกระบวนการโดยเปลี่ยนเส้นทางการตรวจสอบ CAA ไปยังโดเมนเป้าหมาย ตัวอย่างเช่น หาก ร้านค้า.mysite.net ใช้ CNAME เพื่อชี้ไปที่ เว็บไซต์ของฉัน.netCA ที่ดำเนินการตรวจสอบ CAA จะประเมินบันทึกสำหรับ เว็บไซต์ของฉัน.net เพื่อตรวจสอบการอนุญาตในการออกใบรับรอง หากบันทึก CAA บน เว็บไซต์ของฉัน.net ไม่อนุญาตให้ CA ออกใบรับรองได้ วิธีนี้ช่วยให้มั่นใจว่ามีการบังคับใช้นโยบาย CAA อย่างสม่ำเสมอ แม้ว่าโดเมนจะใช้ประโยชน์จากระเบียน CNAME สำหรับการสร้างนามแฝง DNS ก็ตาม
CAA ทำงานอย่างไร
CAA ใช้ DNS
การขอ ระบบชื่อโดเมน (DNS) เป็นส่วนสำคัญของโครงสร้างพื้นฐานของอินเทอร์เน็ต เจ้าของโดเมนใด ๆ เก็บรักษาระเบียน DNS (ภายในที่เรียกว่า ไฟล์โซน) ชี้ชื่อโดเมนของพวกเขาไปยังที่อยู่ IP ที่โฮสต์เว็บไซต์ของพวกเขาและช่วยให้เราพิมพ์ google.com ลงในหน้าต่างเบราว์เซอร์แทน 216.58.194.46.
โดยทั่วไปจะใช้ระเบียน DNS เป็น "สมุดโทรศัพท์สำหรับอินเทอร์เน็ต" แต่ DNS ยังอนุญาตให้มีระเบียนพิเศษประเภทอื่น ๆ ซึ่งสามารถกำหนดข้อมูลอื่นให้กับชื่อโดเมนได้
บันทึก CAA
CAA ใช้บันทึกชนิดพิเศษที่เรียกว่า บันทึกทรัพยากรการอนุญาตของผู้ออกใบรับรอง (บันทึก CAA) สิ่งเหล่านี้เผยแพร่โดยใช้ DNS และเจ้าของโดเมนเพียงเพิ่มระเบียน CAA ข้างระเบียน DNS อื่น ๆ ของเขา ระเบียน CAA รวมถึง แท็ก และ ความคุ้มค่าและคู่ของค่าแท็กจะเรียกว่า คุณสมบัติ. นอกจากนี้ยังมี ธง ระบุว่าคุณสมบัตินี้มีความสำคัญเพียงใด นี่คือสิ่งที่ดูเหมือน:
example.com CAA 0 ฉบับ "ssl.com"
ที่นี่ example.com เป็นโดเมนที่ระเบียนนี้ใช้กับและ CAA ช่วยให้เราทราบว่าเป็นระเบียนประเภทใด 0 เป็นแฟล็ก (ค่าเริ่มต้นคือศูนย์) แท็กคือ ปัญหา และค่า (ในเครื่องหมายคำพูด) คือ ssl.comซึ่งรวมกันเป็นทรัพย์สิน
ธง
สถานะปัจจุบันมีสถานะที่กำหนดไว้อย่างเข้มงวดเพียงสองสถานะ: 0 (ไม่สำคัญ) และ 1 (ที่สำคัญ) ธงที่สำคัญบอก CA ว่ามัน ต้อง เข้าใจแท็กคุณสมบัติอย่างครบถ้วนเพื่อดำเนินการต่อ RFC 6844 เปิดโอกาสให้ผู้ใช้กำหนดแฟล็กได้ (อ่านเพิ่มเติมด้านล่าง)
แท็ก
RFC 6844 กำหนดการใช้แท็กทั่วไปสามแท็ก: ปัญหา, ออกป่า และ ไอโอดีน. (เช่นเดียวกับแฟล็กจะอนุญาตสำหรับประเภทแท็กที่กำหนดเองอื่น ๆ )
การขอ ปัญหา แท็ก
การขอ ปัญหา tag ระบุว่า (ถ้ามี) CA ใดที่ได้รับอนุญาตให้ออกใบรับรองสำหรับโดเมนนี้ ตัวอย่างเช่นเจ้าของโดเมน example.com สามารถ จำกัด การออกใบรับรองให้กับหนึ่ง CA (ที่นี่ SSL.com) โดยใช้ไฟล์โซน DNS ต่อไปนี้:
example.com CAA 0 ฉบับ "ssl.com"
เจ้าของโดเมนสามารถเลือกที่จะตั้งค่าไฟล์หลายโซนสำหรับโดเมน:
example.com CAA 0 ปัญหา "ssl.com" example.com CAA 0 ฉบับ "comodoca.com"
บันทึกข้างต้น จำกัด SSL /TLS การออกใบรับรองสำหรับ example.com ถึงสอง CAs (SSL.com และ Comodo.com)
การขอ ปัญหา บันทึกอนุญาตให้ CA ที่มีชื่อออกใบรับรองสำหรับโดเมนย่อยใด ๆ ของโดเมนที่ระบุ บันทึกที่อนุญาตให้ SSL.com สามารถอนุญาตให้ออกใบรับรองได้ example.com และโดเมนย่อยเช่น www.example.com, เมล.example.com และแม้กระทั่งโดเมนย่อยแบบพิเศษ * .example.com.
สามารถใช้บันทึก CAA เพื่อ จำกัด การออกใบรับรองด้วยเช่นกันบันทึกนี้บอกผู้ออกใบรับรองโดยใช้ CAA ว่า ไม่ SSL /TLS ควรออกใบรับรองให้ example.com และโดเมนย่อยโดย ใด แคลิฟอร์เนีย:
example.com ปัญหา CAA 0 ";"
(อัฒภาคในตัวอย่างนี้หมายถึง“ไม่อนุญาตอะไรที่นี่“ แต่ตามที่เราจะแสดงในภายหลังมันยังใช้เพื่อกำหนดพารามิเตอร์ที่กำหนดเองด้วย)
โปรดทราบว่าแท็กปัญหามาตรฐานอนุญาตให้ CA ออกใบรับรองสำหรับสัญลักษณ์แทนเว้นแต่จะแก้ไขโดย ...
การขอ ออกป่า แท็ก
แท็กนี้ระบุว่า CA ได้รับอนุญาตให้ออกใบรับรองตัวแทนสำหรับโดเมนของเจ้าของ (เช่น * .example.com).
ไวลด์การ์ดสามารถครอบคลุมโดเมนย่อยได้ไม่จำกัดจำนวน ดังนั้นจึงต้องเอาใจใส่เป็นพิเศษเมื่อออกใบรับรองไวลด์การ์ด ออกป่า แท็กช่วยให้เจ้าของโดเมนกำหนด CA ที่สามารถออกใบรับรองสำหรับ wildcard แยกจากโดเมนหลักหรือโดเมนย่อยอื่น ๆ ออกป่า แท็กมีความสำคัญมากกว่าสิ่งใด ปัญหา แท็ก พวกเขาใช้ไวยากรณ์เดียวกันกับ ปัญหา แท็ก ตัวอย่างบางส่วน:
example.com CAA 0 ปัญหา "ssl.com" example.com CAA 0 ผู้ออกดิน ";"
ข้างต้นอนุญาตให้ SSL.com ออกใบรับรองสำหรับ example.com และโดเมนย่อยทั้งหมด ยกเว้น สำหรับสัญลักษณ์แทน * .example.com. (ทั้ง SSL.com และ CA อื่น ๆ ไม่ได้รับอนุญาตให้ออกใบรับรองไวด์การ์ดสำหรับ example.com.)
example.com ปัญหา CAA 0 ";" example.com ผู้ออก CAA 0ewild "ssl.com"
ตัวอย่างนี้ห้าม ทั้งหมด CA ที่จะออกใบรับรองให้ example.com และโดเมนย่อย แต่สร้างข้อยกเว้นเพื่ออนุญาตให้ SSL.com ออกใบรับรองไวด์การ์ด (และ เพียง ใบรับรองตัวแทน) สำหรับ example.com.
การขอ ไอโอดีน แท็ก
แท็กที่กำหนดที่สามคือ ไอโอดีน. แท็กนี้สามารถใช้เพื่อรายงานคำขอใบรับรองที่ไม่ถูกต้องไปยังเจ้าของโดเมนและมีลักษณะดังนี้:
example.com CAA 0 iodef "mailto: certissues@example.com" example.com CAA 0 iodef "certissues.example.com"
สถิติสูงสุดให้ข้อมูล CA ที่จำเป็นในการส่งการแจ้งเตือนทางอีเมลไปยังที่อยู่ certissues@example.com. ข้อความที่สองนำ CA เพื่อโพสต์ข้อความเหตุการณ์ไปยังบริการเว็บ (ตั้งค่าเพื่อวัตถุประสงค์นี้โดยเจ้าของโดเมน) ที่ certissues.example.com. (สามารถใช้วิธีใดวิธีหนึ่งหรือทั้งสองนี้ขึ้นอยู่กับวิธีที่ CA และเจ้าของโดเมนตั้งค่าการทำงาน)
ไอโอดีน ข้อความโพสต์ใช้รูปแบบมาตรฐานที่เรียกว่า วัตถุเหตุการณ์คำอธิบายรูปแบบการแลกเปลี่ยน หรือ IODEF - ด้วยเหตุนี้ชื่อ (IODEF ถูกกำหนดไว้ใน RFC 6546.)
แท็ก issuemail สำหรับ S/MIME
การพัฒนาที่สำคัญใน CAA คือการขยายออกไป S/MIME (ใบรับรองส่วนขยายเมลทางอินเทอร์เน็ตที่ปลอดภัย/อเนกประสงค์) เป็นทางการใน RFC 9495 S/MIME ใบรับรองให้ความปลอดภัยอีเมลผ่านการพิสูจน์ตัวตน ความเป็นส่วนตัวของข้อมูล และความสมบูรณ์ของข้อความ CA/Browser Forum ได้เปิดตัวแท็กคุณสมบัติ CAA ใหม่ที่เรียกว่า “issuemail” โดยเฉพาะสำหรับการควบคุมการออกใบรับรอง S/MIME ใบรับรอง.
เริ่มตั้งแต่วันที่ 15 กันยายน 2024 ขอแนะนำให้ CA ดำเนินการตรวจสอบ CAA S/MIME ใบรับรองที่ต้องนำไปปฏิบัติจริงภายในวันที่ 15 มีนาคม 2025. แบบฟอร์มบันทึก CAA มาตรฐานสำหรับที่อยู่อีเมลจะมีลักษณะดังนี้:
mail.client.example CAA 0 ปัญหาmail "authority.example"
การขยาย CAA ไปยังใบรับรองอีเมลนี้ช่วยให้เจ้าของโดเมนสามารถควบคุมได้ในระดับเดียวกัน S/MIME การออกใบรับรองตามที่ได้มีไว้ TLS ใบรับรองลดความเสี่ยงจากการออกใบรับรองโดยไม่ได้รับอนุญาต.
ธงและแท็กที่กำหนดโดย CA
CAA ตามที่อธิบายไว้ใน RFC 6844 กำหนดสถานะของสองสถานะเท่านั้น (0 และ 1) และสามแท็ก (ปัญหา, ออกป่า และ ไอโอดีน) อย่างไรก็ตามมันปล่อยให้การออกแบบเปิดเพียงพอสำหรับ CA ในการสร้างและใช้แท็กและแฟล็กที่กำหนดเองเพื่อกำหนดกระบวนการออกใบรับรอง ตัวอย่างอาจจะ:
example.com CAA 0 ปัญหา "SSL.com; policy = ev"
บันทึกนี้ใช้มาตรฐาน ปัญหา แท็กด้วยพารามิเตอร์พิเศษที่สั่งให้ CA ใช้นโยบาย Extended Validation (EV) เมื่อออกใบรับรองสำหรับโดเมนนี้
example.com CAA 128 pca "PCA = 12345"
เจ้าของโดเมนสามารถใช้บันทึกนี้กับใหม่ที่กำหนดโดย CA PCA แท็กเพื่อแสดงว่าพวกเขามีบัญชีลูกค้าที่ต้องการและตั้งหมายเลขบัญชีเป็นพารามิเตอร์ (การตั้งค่าสถานะสามารถเป็นค่าที่กำหนดเองได้สูงสุด 255 รายการ) ทั้งนี้ขึ้นอยู่กับวิธีการตั้งค่าบัญชี CA ซึ่งอาจอนุญาตวิธีการเรียกเก็บเงินโดยเฉพาะการตรวจสอบบัญชีที่กำหนดพิเศษหรือการจัดการพิเศษอื่น ๆ
ข้อดีและข้อเสีย
มีเหตุผลหลายประการที่ยอดเยี่ยมในการใช้ CAA ข้อได้เปรียบหลักและสำคัญที่สุดคือความสามารถของ CAA ในการลดความเสี่ยงในการออกใบรับรองที่ผิดพลาดได้อย่างมาก ซึ่งจะช่วยปกป้องโดเมน ธุรกิจของคุณ และตัวตนออนไลน์ของคุณ ผู้โจมตีที่อาจพบจุดบกพร่องในซอฟต์แวร์ของ CA เฉพาะเจาะจงจะไม่สามารถใช้ประโยชน์จากจุดบกพร่องนั้นเพื่อออกใบรับรอง SSL สำหรับโดเมนของคุณได้ นอกจากนี้ การใช้แท็ก iodef ช่วยให้คุณได้รับรายงานหากมีการพยายามใช้จุดบกพร่อง
การออกแบบของ CAA ช่วยเพิ่มความปลอดภัย แต่ยังช่วยให้สามารถจัดสรรทรัพยากรได้อย่างละเอียดมากขึ้นตัวอย่างเช่น บริษัท สามารถตั้งค่าบันทึกเพื่ออนุญาต (หรือ จำกัด ) ฝ่ายขายและการตลาดในการซื้อใบรับรอง SSL สำหรับ sales.example.com จากแหล่งที่กำหนด
นอกจากนี้ CAA ยังมอบความยืดหยุ่นที่ยอดเยี่ยม สำหรับเจ้าของโดเมนนั้นจะใช้ระเบียนทรัพยากร DNS ที่อยู่ภายใต้การควบคุมของตนเองและสามารถเปลี่ยนแปลงได้ตามต้องการดังนั้นจึงไม่เชื่อมโยงกับ CA ที่ระบุ (และสามารถมี CA มากกว่าหนึ่งรายการที่ได้รับอนุญาตพร้อมกับบันทึกปัญหาสำหรับชื่อโดเมนที่กำหนด) . สำหรับ CAs นอกเหนือจากการใช้งานที่กำหนดเองแล้วกฎที่นำมาใช้ใหม่โดย CA / B Forum (กลุ่มที่กำหนดมาตรฐานสำหรับ CA และเรื่องความปลอดภัยของเบราว์เซอร์) สามารถอนุญาตให้ใช้ระเบียน CAA เพื่อวัตถุประสงค์ในการตรวจสอบได้
ข้อเสียประการหนึ่งคือแม้ว่าจะมีบันทึก CAA อยู่แล้ว ผู้ใช้ก็ไม่สามารถ บังคับใช้ การใช้งานโดยผู้ออกใบรับรอง CA ต้องเป็นไปตาม RFC 6844 เพื่อให้เร็กคอร์ดเหล่านั้นดำเนินการได้และ CA ที่ไม่เป็นไปตามข้อกำหนดอาจเพิกเฉยต่อความปรารถนาด่วนของเจ้าของโดเมนตามที่ประกาศไว้ในระเบียน CAA
CAA ต้องได้รับการกำหนดค่าอย่างถูกต้องโดยทั้งเจ้าของโดเมนและ CA Let's Encrypt (ซึ่งรองรับ CAA) เมื่อเร็ว ๆ นี้ รายงานปัญหาเล็กน้อยเกี่ยวกับรหัสฐาน ซึ่งน่าเสียดายที่ทำให้กฎ CAA ถูกเพิกเฉยและการออกใบรับรองหกฉบับผิดพลาด ไม่มีข้อยกเว้นที่เป็นอันตราย (และขอขอบคุณทีม Let's Encrypt เพื่อแก้ไขและรายงานปัญหาภายในไม่กี่ชั่วโมงหลังจากค้นพบ) อย่างไรก็ตามนี่เป็นการตอกย้ำว่าผู้ออกใบรับรองที่เป็นไปตามข้อกำหนด ต้อง ใช้ CAA ไม่มีที่ติ.
ปัญหาที่อาจเกิดขึ้นอีกประการหนึ่งคือการพึ่งพา DNS ของ CAA เว้นแต่เจ้าของโดเมนจะได้รับบริการชื่อของตนสิ่งนี้อาจเป็นเวกเตอร์สำหรับการโจมตีได้ RFC 6844 แนะนำการใช้งาน ส่วนขยายความปลอดภัยของระบบชื่อโดเมน (DNSSEC)ซึ่งใช้ระเบียน DNS ที่เซ็นชื่อแบบดิจิทัลเพื่อรับรองความถูกต้องของข้อมูลและต่อต้านการคุกคามของการปลอมแปลง DNS
ในที่สุดแม้จะมี CAA และนำไปใช้อย่างถูกต้อง แต่บันทึก CAA ด้วยตัวเองก็ไม่สามารถป้องกันการออกใบรับรองโกงได้อย่างสมบูรณ์ แม้ว่า CAA จะเป็นเครื่องมือที่มีประโยชน์และสำคัญในการ จำกัด ตัวเลือกของผู้โจมตี แต่นักจี้ที่มีการเข้าถึงที่เพียงพอ (ตัวอย่างเช่นโดยการควบคุม DNS หรือผ่านทางวิศวกรรมสังคม) อาจสามารถกำหนดเส้นทางไปรอบ ๆ ตัวได้
สรุป
การอนุญาตสิทธิ์การรับรองมีศักยภาพที่ยอดเยี่ยมในฐานะส่วนหนึ่งของระบบนิเวศความปลอดภัยที่กว้างขึ้น และการนำไปใช้อย่างแพร่หลายและการนำ CAA มาใช้จะช่วยป้องกันการออกใบรับรองที่ผิดพลาด แม้ว่า CAA เพียงอย่างเดียวจะไม่สามารถหยุดการออกใบรับรองที่ผิดพลาดได้ แต่ก็ถือเป็นก้าวที่ดีในทิศทางที่ถูกต้อง และ SSL.com ขอแนะนำให้คุณพิจารณาใช้ระเบียน CAA ด้วยตนเอง
อ้างอิง
- RFC6844: บันทึกทรัพยากรการอนุญาต (CAA) ของผู้ออกใบรับรอง DNS
- RFC5070: รูปแบบการแลกเปลี่ยนวัตถุคำอธิบายเหตุการณ์
- RFC6546: การส่งผ่านข้อความเรียลไทม์เครือข่ายการป้องกัน (RID) ผ่าน HTTP /TLS
- RFC4033: บทนำและข้อกำหนดด้านความปลอดภัย DNS
- CA / B ฟอรัมการลงคะแนน 125 - บันทึก CAA
- รายการ Wikipedia เกี่ยวกับการอนุญาตของผู้ออกใบรับรอง DNS
คำแนะนำที่เกี่ยวข้อง
- ข้อกำหนดสำหรับ SSL.com SSL คืออะไร /TLS การตรวจสอบความถูกต้องของโดเมนใบรับรอง
- “ค่าเฉพาะ” ที่ใช้ในการตรวจสอบโดเมน (DV) คืออะไร
- ชื่อโดเมน SSL /TLS Pre-การตรวจสอบ
