คำแนะนำเบื้องต้นเกี่ยวกับการอนุญาตของผู้ออกใบรับรอง (CAA)

ทำไมต้องใช้ CAA

CA ใช้วิธีการเสมอ การตรวจสอบโดเมน เพื่อให้แน่ใจว่า SSL /TLS คำขอใบรับรองได้รับอนุญาต (โดยปกติจะทำให้แน่ใจว่ามีการลิงก์ในบางเว็บไซต์ที่ใช้โดเมนนั้น)

ตัวอย่างเช่น CA อาจให้ไฟล์การตรวจสอบพิเศษแก่ผู้ร้องขอ การวางไฟล์นี้บนเว็บไซต์เป็นการพิสูจน์ว่าผู้ร้องขอยังควบคุมเว็บไซต์นั้น แต่ไม่สามารถรับประกันได้ว่า ถูกต้องตามกฎหมาย ของการควบคุมนั้น แฮกเกอร์ที่ได้รับการควบคุมไซต์อาจปลอมตัวเป็นเจ้าของที่ถูกต้องและสามารถร้องขอและรับ SSL /TLS ใบรับรองที่ผ่านการตรวจสอบมาตรฐานของ CA ดังนั้น ดูเหมือนว่า ถูกต้องตามกฎหมาย จากนั้นพวกเขาสามารถหันกลับมาและใช้ SSL นั้น /TLS ใบรับรองการก่อความเสียหายในไซต์นั้นหรือที่อื่น ๆ

CAA ช่วยป้องกันการใช้ประโยชน์ประเภทนี้โดยการกำหนดว่า CA ใดได้รับอนุญาตให้ออกใบรับรองสำหรับโดเมน (หรือแม้กระทั่ง จำกัด การออกใบรับรองทั้งหมด) สิ่งนี้จะจำกัดความเสียหายที่นักจี้สามารถสร้างได้แม้ว่าพวกเขาจะสามารถควบคุมไซต์ได้ แต่พวกเขาก็มีตัวเลือกน้อยลงอย่างมากในการทำคะแนน SSL ที่หลอกลวงTLS ใบรับรอง

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.)

ธงและแท็กที่กำหนดโดย 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 ทั้งหมดไม่ได้รับการรับรอง ข้อกำหนดพื้นฐานของฟอรัม CA / B (ซึ่ง CA ที่เชื่อถือได้ทั้งหมดเป็นไปตาม) สั่งให้ CA ระบุระดับที่รองรับ CAA ในเอกสารออนไลน์ อย่างไรก็ตามในขณะที่เขียนนี้ใช้ CAA เท่านั้น แนะนำ, ไม่ต้องการ. ผู้ออกใบรับรองที่ไม่สอดคล้องกับ CAA ยังคงสามารถกำหนดเป้าหมายได้และจนกว่า CAA จะมีการใช้งานในวงกว้างนักจี้อาจจะสามารถค้นหา CA ที่ไม่สอดคล้องตามที่เต็มใจจะออกใบรับรองโกง

ข้อเสียที่เกี่ยวข้องคือแม้ว่าจะมีการบันทึก 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 แต่มีการหารือกันเกี่ยวกับการแนะนำหรือบังคับให้ใช้ CA นี้ทั้งหมด แม้ว่า CAA เพียงอย่างเดียวจะไม่หยุดการออกใบรับรองที่ผิดทุกครั้ง แต่ก็เป็นขั้นตอนที่ถูกต้องในทิศทางที่ถูกต้องและ SSL.com ต้องการให้คุณพิจารณาใช้ CAA บันทึกด้วยตัวคุณเอง

อ้างอิง

• RFC6844: บันทึกทรัพยากรการอนุญาต (CAA) ของผู้ออกใบรับรอง DNS
• RFC5070: รูปแบบการแลกเปลี่ยนวัตถุคำอธิบายเหตุการณ์
• RFC6546: การส่งผ่านข้อความเรียลไทม์เครือข่ายการป้องกัน (RID) ผ่าน HTTP /TLS
• RFC4033: บทนำและข้อกำหนดด้านความปลอดภัย DNS
• CA / B ฟอรัมการลงคะแนน 125 - บันทึก CAA
• รายการ Wikipedia เกี่ยวกับการอนุญาตของผู้ออกใบรับรอง DNS