Tags:
Node Thumbnail

กระบวนการออกใบรับรองดิจิตอลทุกวันนี้มีช่องว่างสำคัญคือหน่วยงานออกใบรับรองดิจิตอล (certification authority - CA) ทุกรายสามารถออกใบรับรองให้กับโดเมนใดๆ ก็ได้ ตอนนี้มาตรการเพิ่มเติมในการจำกัดสิทธิ์ของ CA ก็เตรียมบังคับใช้เดือนกันยายนนี้ หลังการโหวตมาตรฐาน Certification Authority Authorization (CAA) โดย CA/Browser Forum ผ่านไปแล้ว

CAA เป็นมาตรฐาน rfc6844 มาตั้งแต่ปี 2013 ระบุให้เจ้าของโดเมนสามารถล็อก CA ที่จะออกใบรับรองให้กับโดเมนของตนได้ ผ่าน Resource Record (RR) ใน DNS เช่น example.org. CAA 128 issue "letsencrypt.org" จะล็อกให้ Let's Encrypt เท่านั้นที่สามารถออกใบรับรองให้กับ example.com ได้

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

ผลการลงมติบังคับ CAA มีผลเกือบเอกฉันท์ มีเพียง Sertifitseerimiskeskus จากเอสโทเนียเท่านั้นที่โหวตคัดค้าน และจะมีผลเดือนกันยายนนี้ ตอนนี้ทาง Qualys SSL Labs ก็รายงานแล้วว่าเว็บใดบ้างที่เปิด CAA เอาไว้ (ตัวอย่าง Google.com)

ที่มา - Qualys Blog

Get latest news from Blognone

Comments

By: e.p.
ContributorAndroid
on 14 March 2017 - 23:08 #975181
e.p.'s picture

ขยายความเพิ่มว่าการล็อกว่า CA ไหนที่จะเป็นคนออกใบรับรองได้นั้นตัว CA เป็นคนเช็คจาก CAA record เอง ดังนั้นถ้ามี CA ที่อยู่นอกรายการที่ระบุใน CAA ออกจะออกใบรับรองก็ยังสามารถทำได้อยู่ (CA อื่นๆ จะออกใบรับรองเพื่อมาดักฟังก็ทำได้เหมือนเดิม)

ใน RFC 6844 ระบุด้วยว่าเนื่องจากใบรับรองมีอายุนาน เป็นไปได้ที่ขณะใช้งานใบรับรองอยู่ตัว CA อาจจะไม่ได้อยู่ในรายการ CAA ปัจจุบันแล้ว (แต่เคยอยู่ในขณะออกใบรับรอง) ดังนั้นห้ามใช้ CAA record ในการทำ certificate validation

สรุปสั้นๆ คือป้องกัน CA ที่ประพฤติตัวดีไม่ให้ออกใบรับรองพลาดในบางกรณี แต่ไม่ช่วยในการป้องกันความจงใจ...

By: lew
FounderJusci's WriterMEconomicsAndroid
on 14 March 2017 - 23:47 #975189 Reply to:975181
lew's picture

เคสนี้คือถ้า CA ฝ่าด่าน ออกใบรับรองทั้งๆ ที่มีหลักฐานว่าทำ CAA ไว้ จากเดิมที่บอกว่ามีความผิดพลาดอย่างอื่นๆ ได้ (เช่นเจ้าของโดเมนพลาดเอง) และ CA นี้ไม่เชื่อ CAA หลังจากนี้ถ้าชัดตัว CA ก็มีโอกาสปลิวตาม WoSign, Diginotar, และ CNNIC ไป


lewcpe.com, @wasonliw

By: e.p.
ContributorAndroid
on 15 March 2017 - 07:01 #975212 Reply to:975189
e.p.'s picture

พิสูจน์ CAA ว่าเคยมีหรือไม่เคยมีในเวลาที่ออกใบรับรองก็ไม่ง่ายนะครับ มันไม่มีหลักฐาน

By: e.p.
ContributorAndroid
on 15 March 2017 - 07:56 #975214 Reply to:975189
e.p.'s picture

ยกตัวอย่างอีกเคส ถ้าผู้ขอใบรับรองจงใจสร้าง views ใน DNS ให้ผู้ออกใบรับรองมองเห็น CAA record ที่ระบุชื่อ CA ของตัวไว้ได้คนเดียวแล้วขอใบรับรองไป

คนอื่นๆ ที่อยู่นอกวงจะมองว่า CA ออกใบรับรองเถื่อนไหมครับ? แถม CA เองก็ไม่รู้ด้วยว่าเห็น CAA อันนั้นอยู่คนเดียว

หรือจะสร้าง CAA แล้วขอใบรับรอง ได้แล้วเอา CAA ออก แล้วไปฟ้องว่า CA ออกใบรับรองโดยพละการได้ไหม เพราะ CA เองไม่มีหลักฐานอะไรเลยว่ามันเคยมีอยู่ (ยกเว้นใช้ DNSSEC แล้วเก็บข้อมูลที่ใช้ทำ validation ทุกขั้นเอาไว้ แต่ในกรณีนี้เค้าก็ไม่ได้บังคับว่าต้องทำ DNSSEC)

Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not
required.
An issuer MUST NOT issue certificates if doing so would
conflict with the relevant CAA Resource Record set, irrespective of
whether the corresponding DNS records are signed.

DNSSEC provides a proof of non-existence for both DNS domains and RR
set within domains. DNSSEC verification thus enables an issuer to
determine if the answer to a CAA record query is empty because the RR
set is empty or if it is non-empty but the response has been
suppressed.

Use of DNSSEC allows an issuer to acquire and archive a proof that
they were authorized to issue certificates for the domain
.
Verification of such archives MAY be an audit requirement to verify
CAA record processing compliance. Publication of such archives MAY
be a transparency requirement to verify CAA record processing
compliance.