ข้ามไปเนื้อหา

ผู้ประกอบการรับรอง

จากวิกิพีเดีย สารานุกรมเสรี

ผู้ประกอบการรับรอง หรือ certificate authority (CA) เป็นหน่วยงานที่ออกใบรับรองดิจิทัลในการเข้ารหัส ซึ่งใบรับรองดิจิทัลรับรองความเป็นเจ้าของกุญแจสาธารณะโดยมีชื่อเรื่องของใบรับรอง มีการรับรองอนุญาตให้คนอื่นใช้งานได้ โดยขึ้นอยู่กับลายเซ็นหรือยืนยันตัวโดยการทำกุญแจส่วนตัว (private key) ที่สอดคล้องกับกุญแจสาธารณะ (public key) ที่ถูกรับรอง ในรูปแบบความสัมพันธ์ที่เชื่อถือได้ ผู้ออกใบรับรองเป็นบุคคลที่สามที่เชื่อถือได้ ซึ่งได้รับความเชื่อถือทั้งจากเจ้าของข้อมูลที่มีใบรับรองและผู้ที่ได้รับสิ่งที่มีใบรับรองนั้น รูปแบบของการรับรองอยู่บนมาตรฐาน X.509 หรือ EMV แผนของผู้ให้บริการเทคโนโลยีโครงสร้างพื้นฐานกุญแจสาธารณะ (Public Key Infrastructure, PKI) จำนวนมากจะแสดงตนว่าเป็นผู้ออกใบรับรองด้วย

ภาพรวม

[แก้]

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

ผู้ใช้บริการของผู้ออกใบรับรอง เป็นผู้ดูแลเซิร์ฟเวอร์ ซึ่งต้องการใบรับรองที่เซิร์ฟเวอร์ของพวกเขาจะนำเสนอให้แก่ผู้ใช้บริการได้ จ่ายให้กับผู้ออกใบรับรองในการออกใบรับรอง และลูกค้าของพวกเขาหวังว่าใบรับรองของผู้ออกใบรับรองจะถูกรวบรวมโดยเว็บเบราว์เซอร์ส่วนใหญ่ เพื่อที่จะให้การเชื่อมต่อปลอดภัยคือ เซิร์ฟเวอร์ซึ่งถูกรับรองทำงานได้อย่างราบรื่น จำนวนเว็บเบราว์เซอร์ อุปกรณ์อื่น ๆ และ แอปพลิเคชันซึงเชื่อถือผู้ออกใบรับรองโดยเฉพาะ จะถูกกล่าวถึงอย่างแพร่หลาย มอซิลลาซึ่งเป็นองค์กรที่แสวงผลกำไร ได้กระจายใบรับรองของผู้ออกใบรับรองกับผลิตภัณฑ์ของบริษัทไปอย่างแพร่หลาย[1] ในขณะที่มอซิลลาพัฒนานโยบาย CA/Browser Forum ได้พัฒนาแนวทางสำหรับความน่าเชื่อถือของผู้ออกใบรับรองเช่นกัน ใบรับรองของผู้ออกใบรับรองใบเดียวอาจจะถูกใช้ร่วมกับหลาย ๆ ผู้ออกใบรับรอง และลูกค้าของพวกเขา ใบรับรอง root CA มักจะเป็นฐานที่จะออกใบรับรองกลาง ที่สามารถประยุกต์ตามความต้องการที่แตกต่างกัน

นอกเหนือจากผู้ออกใบรับรอง ผู้ให้บริการบางรายออกใบรับรองดิจิทัลให้กับผู้อื่นโดยไม่คิดค่าใช้จ่าย ตัวอย่างที่น่าสนใจคือ CAcert สถาบันขนาดใหญ่และหน่วยงานภาครัฐอาจมีเทคโนโลยีโครงสร้างพื้นฐานกุญแจสาธารณะ (PKI) เป็นของตัวเอง ซึ่งรวมผู้ออกใบรับรองของตัวเองเข้าไปด้วย โดยปกติเว็บไซต์ใดใช้ใบรับรองที่ลงนามเองต้องทำหน้าที่เป็นผู้ออกใบรับรองของตัวเองด้วย เบราว์เซอร์ และผู้ใช้บริการคนอื่น ๆ โดยทั่วไปจะอนุญาตให้ผู้ใช้เพิ่มหรือลบใบรับรองของผู้ออกใบรับรองตามความต้องการ ในขณะที่ใบรับรองเซิร์ฟเวอร์ทั่วไปมีอายุการใช้งานที่สั้น ใบรับรองของผู้ออกใบรับรองล่าสุดมีอายุการใช้งานที่ยาวนานกว่า[2] ดังนั้นสำหรับเซิร์ฟเวอร์ที่มีผู้ใช้งานบ่อย ๆ ก็จะมีข้อผิดพลาดน้อยในการติดตั้งและเชื่อถือผู้ออกใบรับรองที่ออกใบรับรองให้ มากกว่าการยืนยันข้อยกเว้นการรักษาความปลอดภัยทุกครั้งที่เซิร์ฟเวอร์ต่ออายุใบรับรอง

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

ผู้ให้บริการ

[แก้]

ธุรกิจผู้ออกใบรับรองทั่วโลก มีการแบ่งส่วนทั้งระดับชาติและระดับภูมิภาคซึ่งมีอำนาจเหนือตลาดทั่วไป เป็นเพราะการใช้งานใบรับรองดิจิทัลจำนวนมากเชื่อมโยงกฎหมายท้องถิ่น ซึ่งมีข้อบังคับ และการให้อำนาจวางแผนสำหรับผู้ออกใบรับรอง เช่น สำหรับผลเกี่ยวข้องทางกฎหมายลายเซ็นดิจิทัล อย่างไรก็ตามมีตลาดสำหรับใบรับรอง SSL ซึ่งเป็นใบรับรองใช้สำหรับการรักษาความปลอดภัยเว็บไซต์ ทีโดยส่วนใหญ่จัดขึ้นโดยบริษัทข้ามชาติจำนวนหนึ่ง ตลาดนี้มีอุปสรรคสำคัญในการเข้าถึงเนื่องจากข้อกำหนดทางเทคนิค ในขณะที่ไม่จำเป็นต้องทำตามกฎหมาย ผู้ให้บริการรายใหม่อาจเลือกที่จะได้รับการตรวจสอบรายปี ซึ่งจะถูกรวมอยู่ในรายการของเว็บเบราว์เซอร์ที่มีผู้รับรองที่น่าเชื่อถือ เช่น WebTrust[3] สำหรับผู้ออกใบรับรองในอเมริกาเหนือ และ ETSI ในยุโรป[4] ใบรับรอง root certificate มากกว่า 50 ใบที่เชื่อถือได้เป็นที่นิยมในเว็บเบราว์เซอร์ โดยบริษัท W3Techs ได้สำรวจตั้งแต่เดือนกุมภาพันธ์ พ.ศ. 2558 พบว่า

อันดับ ผู้ออกใบรับรอง การใช้งาน ส่วนแบ่งการตลาด
1. Comodo 6.6% 33.6%
2. Symantec Group 6.5% 33.2%
3. Go Daddy Group 2.6% 13.2%
4. GlobalSign 2.2% 11.3%
5. DigiCert 0.6% 2.9%

วันที่ 18 พฤศจิกายน พ.ศ. 2557 กลุ่มบริษัทและองค์กรที่ไม่แสวงผลกำไร รวมทั้ง the Electronic Frontier Foundation, Mozilla, Cisco และ Akamai ประกาศว่า "Let's encrypt" ผู้ออกใบรับรองที่ไม่แสวงผลกำไรรายใหม่วางแผนที่จะออกใบรับรอง TLS โดยไม่คิดค่าใช้จ่าย โดยรวมทั้งซอฟต์แวร์ที่ใช้สำหรับติดตั้งและบำรุงรักษาใบรับรอง[5] Let's encrypt จะถูกดำเนินการโดยกลุ่มวิจัยการรักษาความปลอดภัยอินเทอร์เน็ต "Internet Security Research Group" ที่ถูกจัดตั้งขึ้นมาใหม่ในแคลิฟอร์เนีย ซึ่งใช้ประโยชน์จากการยกเว้นภาษีของรัฐบาลตามมาตรา 501 (c) (3) ในช่วงเวลาการประกาศ[6]

การตรวจสอบโดเมน

[แก้]

ผู้ออกใบรับรองซึ่งออกกลุ่มใบรับรองที่ลูกค้าไว้วางใจสำหรับเซิร์ฟเวอร์อีเมล และเซิร์ฟเวอร์ HTTPS สาธารณะมักจะใช้เทคนิคที่เรียกว่า "การตรวจสอบโดเมน" ในการตรวจสอบผู้รับใบรับรอง การตรวจสอบโดเมนเกี่ยวข้องกับการส่งอีเมล ที่มีการรับรองโทเค็นหรือลิงก์ไปยังที่อยู่อีเมลที่รู้จักกัน ซึ่งดำเนินการรับผิดชอบสำหรับโดเมน ซึ่งอาจเป็นรายการที่อยู่อีเมลที่ติดต่อทางเทคนิคใน WHOIS entry ของโดเมน หรืออีเมลที่เกี่ยวกับการบริหารงาน เช่น โดเมน admin@, administrator@, webmaster@, hostmaster@ หรือ postmaster@[7][8] ผู้ออกใบรับรองบางรายอาจยอมรับการใช้ โดเมน root@, info@ หรือ support@[9] ทฤษฎีที่อยู่เบื้องหลังการตรวจสอบโดเมนก็คือมีเจ้าของโดเมนที่ถูกต้องเท่านั้นที่จะสามารถอ่านอีเมลที่ส่งไปยังที่อยู่ของผู้ดูแลระบบ

การตรวจสอบโดเมนประสบกับข้อจำกัดของการรักษาความปลอดภัยของโครงสร้างบางอย่าง โดยเฉพาะอย่างยิ่งมันมักจะเสี่ยงต่อการโดนโจมตีที่ช่วยให้ฝ่ายตรงข้ามจะสังเกตเห็นอีเมล การตรวจสอบโดเมนที่ส่งโดยผู้ออกใบรับรองรวมถึงการโจมตีโพรโทคอล DNS, TCP และ BGP หรือการประนีประนอมของเราเตอร์ (ซึ่งขาดการคุ้มครองการเข้ารหัสลับของ TLS/SSL) การโจมตีดังกล่าวเป็นไปทั้งบนเครืองข่ายที่ใกล้ผู้ออกใบรับรองหรือใกล้โดเมนเหยื่อเอง

ผู้ออกใบรับรองบางรายเสนอใบรับรอง Extended Validation (EV) เป็นทางเลือกที่เข้มงวดมากขึ้นในการตรวจสอบโดเมนใบรับรอง หนึ่งในข้อจำกัดของ EV เป็นวิธีการแก้จุดอ่อนของการตรวจสอบโดเมนจากการโจมตีที่ยังคงได้รับใบรับรอง โดยใบรับรองการตรวจสอบโดเมนสำหรับโดเมนของผู้เคราะห์ร้ายมีการปรับใช้ระหว่างการโจมตีที่เกิดขึ้น ซึ่งมีเพียงข้อแตกต่างที่สังเกตได้ให้กับผู้ใช้ที่ตกเป็นเหยื่อโดยจะแสดงเป็นแถบ HTTPS address สีน้ำเงิน มากกว่าจะเป็นสีเขียว ผู้ใช้น้อยคนนักจะมีแนวโน้มที่จะยอมรับข้อแตกต่างนี้ซึ่งเป็นสิ่งบ่งชี้การโจมตีที่กำลังดำเนินการอยู่

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

การออกใบรับรอง

[แก้]

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

หากผู้ใช้ไว้วางใจผู้ออกใบรับรองและสามารถตรวจสอบลายเซ็นของผู้ออกใบรับรอง ดังนั้นเขาสามารถเชื่อได้ว่ากุญแจสาธารณะเป็นของใครก็ตามที่ระบุไว้ในใบรับรองนั้น[11]

ตัวอย่าง

[แก้]

การเข้ารหัสกุญแจสาธารณะสามารถนำมาใช้ในการเข้ารหัสข้อมูลที่สื่อสารกันระหว่าง 2 ฝ่าย ซึ่งจะเกิดขึ้นเมื่อเมื่อผู้ใช้เข้าสู่ทุกเว็บไซต์ที่ implement โพรโทคอลการรักษาความปลอดภัย HTTPS ในตัวอย่างนี้ให้เราคิดว่าผู้ใช้เข้าสู่ระบบ www.bank.example เพื่อทำธุรกรรมทางการเงิน เมื่อผู้ใช้เปิดหน้าแรก www.bank.example เขาจะได้รับกุญแจสาธารณะ พร้อมกับข้อมูลทั้งหมดที่แสดงบนหน้าเว็บเบราว์เซอร์ กุญแจสาธารณะสามารถนำมาใช้ในการเข้ารหัสข้อมูลจากผู้ใช้ไปยังเซิร์ฟเวอร์ แต่ขั้นตอนที่ปลอดภัยที่จะใช้ในโพรโทคอลที่กำหนดกุญแจที่สมมาตรกัน ข้อความในโพรโทคอลดังกล่าวเป็นรหัสลับพร้อมกับกุญแจสาธารณะ และมีเพียงเซิร์ฟเวอร์ของธนาคารเท่านั้นที่มีกุญแจสาธารณะในการอ่านข้อมูล การสื่อสารดำเนินการโดยใช้กุญแจที่สมมาตรกันใหม่ ดังนั้นเมื่อผู้ใช้ป้อนข้อมูลบางอย่างไปยังหน้าเพจของธนาคารและกด submit ส่งข้อมูลให้ธนาคารแล้ว ข้อมูลผู้ใช้จะถูกป้อนไปยังหน้าเพจซึ่งจะถูกเข้ารหัสโดยเว็บเบราว์เซอร์นั่นเอง ดังนั้นถึงแม้ว่าบางคนสามารถเข้าถึงข้อมูลที่ถูกสื่อสารจากผู้ใช้ไปยัง www.bank.example ดังนั้นคนดักจับข้อมูลจะไม่สามารถอ่านและถอดรหัสได้[12]

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

ผู้ออกใบรับรองเป็นองค์กรที่เก็บกุญแจสาธารณะและเป็นเจ้าของ ทุกกลุ่มในการสื่อสารไว้วางใจองค์กรนี้และรู้จักกุญแจสาธารณะของผู้ออกใบรับรอง เมื่อเว็บเบราว์เซอร์ของผู้ใช้ได้รับกุญแจสาธารณะจาก www.bank.example และยังได้รับลายเซ็นดิจิทัลของกุญแจด้วย เบราว์เซอร์ครอบครองกุญแจสาธารณะของผู้ออกใบรับรองอยู่แล้วจึงสามารถตรวจสอบลายเซ็น ไว้วางใจใบรับรองและกุญแจสาธารณะได้ เมื่อ www.bank.example ใช้กุญแจสาธารณะซึ่งผู้ออกใบรับรองได้รับรอง www.bank.example ปลอม จะสามารถใช้ได้แค่กุญแจสาธารณะที่เหมือนกันเท่านั้น เมื่อ www.bank.example ปลอมไม่รู้จักกุญแจส่วนตัวที่เกี่ยวข้องแล้ว ก็ไม่สามารถออกลายเซ็นที่จำเป็นในการตรวจสอบความถูกต้อง[13]

การรักษาความปลอดภัย

[แก้]

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

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

แม้จะมีมาตรการรักษาความปลอดภัยรับรองการตรวจสอบความถูกต้องของบุคคลและบริษัท ยังมีความเสี่ยงของผู้ออกใบรับรองรายองค์กร ในการออกใบรับรองปลอมเพื่อหลอกลวง นอกจากนี้ยังเป็นไปได้ที่จะจดทะเบียนนิติบุคคลและบริษัทด้วยชื่อที่เหมือนหรือคล้ายกันมาก ๆ จนทำให้เกิดความสับสน เพื่อลดความอันตรายนี้ จึงมีการเสนอการตรวจสอบทุกใบรับรองใน public unforgeable log ซึ่งสามารถช่วยปัองกันการ phishing[15][16]

ในการใช้งานขนาดใหญ่ Alice อาจไม่คุ้นเคยกับใบรับรองของ Bob เพราะอาจมีผู้ออกใบรับรองที่แตกต่างกัน ดังนั้นใบรับรองของ Bob ยังอาจรวมกุญแจสาธารณะของผู้ออกใบรับรองที่ลงนามโดย CA ที่ต่างกัน ซึ่ง Alice น่าจะรู้จัก กระบวนการนี้นำไปสู่การรับรองเป็นลำดับชั้น หรือโครงข่ายผู้ออกใบรับรองหรือ "ใบรับรองผู้ออกใบรับรอง"

รายการเพิกถอนสิทธิ

[แก้]

รายการเพิกถอนสิทธิ (ARL) เป็นรูปแบบของ CRL ที่มีใบรับรองออกไปยังผู้ออกใบรับรอง ตรงกันข้ามกับ CRLs ที่มีใบรับรองเพิกถอนบุคคล

องค์กรอุตสาหกรรม

[แก้]
  • Certificate Authority Security Council (CASC) – ก่อตั้งขึ้นในปี พ.ศ. 2556 ในฐานะที่เป็นองค์กรที่สนับสนุนอุตสาหกรรม มุ่งเป้าไปยังปัญหาที่มีอยู่และให้ความรู้แก่ประชาชนเกี่ยวกับการรักษาความปลอดภัยอินเทอร์เน็ต สมาชิกผู้ก่อตั้งคือผู้ออกใบรับรองขนาดใหญ่ลำดับที่ 7[17][18]

การโจมตีผู้ออกใบรับรอง

[แก้]

ถ้าผู้ออกใบรับรองสามารถโดนโจมตี ซึ่งจะทำให้ระบบทั้งหมดเกิดความเสียหาย แม้ว่าหน่วยงานทั้งหมดจะเชื่อถือผู้ออกใบรับรองที่โดนบุกรุกนั้น ยกตัวอย่าง กรณีใบรับรองสนับสนุนการโจมตีเช่น Eve จัดการบางอย่างให้ได้การรับรองจาก CA ซึ่งมาจากใบรับรองของเธอที่อ้างว่าเป็นของ Alice ใบรับรองจะแถลงต่อสาธารณะว่านี่เป็นของ Alice และอาจรวมข้อมูลอื่น ๆ ของ Alice ข้อมูลบางอย่างเกี่ยวกับ Alice เช่นนายจ้างของเธออาจจะจริง ซึ่งช่วยเพิ่มความน่าเชื่อถือของใบรับรอง อย่างไรก็ตาม Eve อาจมีข้อมูลกุญแจส่วนตัวของใบรับรองที่สำคัญทั้งหมด ซึ่ง Eve สามารถใช้ใบรับรองเพื่อทำการลงนามดิจิทัลในอีเมลและส่งไปให้ Bob เพื่อหลอก Bob ให้เชื่อว่าอีเมลนั้นเป็นของ Alice โดย Bob อาจตอบอีเมลที่ถูกเข้ารหัสนั้น และเชื่อว่าจะถูกอ่านโดน Alice ซึ่ง Eve สามารถถอดรหัสอีเมลนั้นมาอ่านได้โดยใช้กุญแจส่วนตัว การทำลายระบบของผู้ออกใบรับรอง ที่โด่งดังเช่น กรณีนี้เกิดในปี พ.ศ. 2544 เมื่อผู้ออกใบรับรอง VeriSign ได้ออกใบรับรองสองตัวให้แก่บุคคลผู้แทนของบริษัทไมโครซอฟท์ ใบรับรองนั้นมีชื่อว่า “Microsoft Corporation” ดังนั้นอาจถูกใช้เพื่อหลอกใครบางคนเพื่อให้เชื่อว่าเป็นการปรับปรุงซอฟต์แวร์ของไมโครซอฟท์ ซึ่งจริง ๆ แล้วไม่ใช่ การทุจริตนี้ถูกพบในต้นปี พ.ศ. 2544 ซึ่งไมโครซอฟท์ และ VeriSign ได้ทำขั้นตอนเพื่อลดผลกระทบของปัญหาดังกล่าว[19][20]

ในปี พ.ศ. 2554 ใบรับรอง *.google.com ที่หลอกลวงซึ่งบริษัท Comodo และ DigiNotar ได้รับมานั้น[21][22] มีการกล่าวหาว่ากระทำโดยแฮกเกอร์ชาวอิหร่าน โดยมีหลักฐานว่าใบรับรอง DigiNotar ที่ปลอมนั้นถูกใช้เพื่อการโจมตีแบบ man-in-the-middle ในอิหร่าน[23]

ในปี พ.ศ. 2555 เป็นที่ทราบกันว่า Trustwave ได้ออกใบรับรองชั้นรองจากระดับ root เพื่อใช้ในการจัดการดักจับการส่งข้อมูล (man-in-the-middle) ในองค์กรที่เป็นที่ยอมรับ โดยดักจับการส่งโพรโทคอล SSL ของเครือข่ายภายในโดยใช้ใบรับรองนั้น[24]

การออกแบบและพัฒนาโปรแกรมอย่างเปิดเผย

[แก้]

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

  • DogTag
  • EJBCA
  • gnoMint
  • OpenCA
  • OpenSSL, an SSL/TLS library มาพร้อมกับตัวช่วยอนุญาตในการใช้งานใบรับรองอย่างง่าย
  • EasyRSA, OpenVPN's command line CA utilities ซึ่งใช้โพรโทคอล OpenSSL
  • r509
  • TinyCA, ซึ่งเป็น perl gui ในส่วนบนของมอดูล CPAN
  • XCA
  • Automated Certificate Management Environment (ACME), ให้โพรโทคอลการเข้ารหัสเพื่อการสื่อสารระหว่างผู้ออกใบรับรองและเซิร์ฟเวอร์ ให้การเข้ารหัสแบบ node-acme, Node.js ของ ACME, และการตรวจดูการเข้ารหัส, พื้นฐานจากภาษาไพทอนของการจัดการเซิร์ฟเวอร์ใบรับรองโดยใช้โพรโทคอล ACME

อ้างอิง

[แก้]
  1. ↑ "Mozilla Included CA Certificate List — Mozilla". Mozilla.org. เก็บจากแหล่งเดิมเมื่อ 2013-08-04. สืบค้นเมื่อ 2014-06-11.
  2. ↑ Zakir Durumeric; James Kasten; Michael Bailey; J. Alex Halderman (12 September 2013). "Analysis of the HTTPS Certificate Ecosystem" (PDF). The Internet Measurement Conference. SIGCOMM. เก็บ (PDF)จากแหล่งเดิมเมื่อ 22 December 2013. สืบค้นเมื่อ 20 December 2013.
  3. ↑ "webtrust". webtrust. เก็บจากแหล่งเดิมเมื่อ 2013-08-18. สืบค้นเมื่อ 2013-03-02.
  4. ↑ Kirk Hall (April 2013). "Standards and Industry Regulations Applicable to Certification Authorities" (PDF). Trend Micro. เก็บ (PDF)จากแหล่งเดิมเมื่อ 2016-03-04. สืบค้นเมื่อ 2014-06-11.
  5. ↑ "Let's Encrypt: Delivering SSL/TLS Everywhere" (Press release). Let's Encrypt. เก็บจากแหล่งเดิมเมื่อ 2014-11-18. สืบค้นเมื่อ 2014-11-20.
  6. ↑ "About". Let's Encrypt. เก็บจากแหล่งเดิมเมื่อ 2015-06-10. สืบค้นเมื่อ 2015-06-07.
  7. ↑ "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.3" (PDF). เก็บ (PDF)จากแหล่งเดิมเมื่อ 2015-03-23. สืบค้นเมื่อ 2015-03-20.
  8. ↑ "CA/Forbidden or Problematic Practices - MozillaWiki". wiki.mozilla.org (ภาษาอังกฤษ). เก็บจากแหล่งเดิมเมื่อ 2017-07-21. สืบค้นเมื่อ 2017-07-06.
  9. ↑ "SSL FAQ - Frequently Asked Questions - Rapid SSL". www.rapidssl.com. เก็บจากแหล่งเดิมเมื่อ 2015-02-06.
  10. ↑ "Responsibilities of Certificate Authority". เก็บจากแหล่งเดิมเมื่อ 2015-02-12. สืบค้นเมื่อ 2015-02-12.
  11. ↑ "PKI". Network World. IDG Network World. 17 January 2000. pp. 55–56.
  12. ↑ Moti Yung; Markus Jakobsson; Jianying Zhou, บ.ก. (June 2004). Applied Cryptography and Network Security. Second International Conference, ACNS.
  13. ↑ Behr, Kevin (2006). The Shortcut Guide to Managing Certificate Lifecycles. Real-Time Publisher. ISBN 9781931491594.
  14. ↑ "Electronic Signatures and Records" (PDF). เก็บ (PDF)จากแหล่งเดิมเมื่อ 2016-03-04. สืบค้นเมื่อ 2014-08-28.
  15. ↑ "Certificate transparency". เก็บจากแหล่งเดิมเมื่อ 2013-11-01. สืบค้นเมื่อ 2013-11-03.
  16. ↑ "Certificate transparency". Internet Engineering Task Force. เก็บจากแหล่งเดิมเมื่อ 2013-11-22. สืบค้นเมื่อ 2013-11-03.
  17. ↑ "Multivendor power council formed to address digital certificate issues". Network World. February 14, 2013. คลังข้อมูลเก่าเก็บจากแหล่งเดิมเมื่อ July 28, 2013.
  18. ↑ "Major Certificate Authorities Unite In The Name Of SSL Security". Dark Reading. February 14, 2013. คลังข้อมูลเก่าเก็บจากแหล่งเดิมเมื่อ April 10, 2013.
  19. ↑ "CA-2001-04". Cert.org. เก็บจากแหล่งเดิมเมื่อ 2013-11-02. สืบค้นเมื่อ 2014-06-11.
  20. ↑ Microsoft, Inc. (2007-02-21). "Microsoft Security Bulletin MS01-017: Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard". เก็บจากแหล่งเดิมเมื่อ 2011-10-26. สืบค้นเมื่อ 2011-11-09.
  21. ↑ Bright, Peter (28 March 2011). "Independent Iranian hacker claims responsibility for Comodo hack". Ars Technica. เก็บจากแหล่งเดิมเมื่อ 29 August 2011. สืบค้นเมื่อ 2011-09-01.
  22. ↑ Bright, Peter (2011-08-30). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. เก็บจากแหล่งเดิมเมื่อ 2011-09-12. สืบค้นเมื่อ 2011-09-01.
  23. ↑ Leyden, John (2011-09-06). "Inside 'Operation Black Tulip': DigiNotar hack analysed". The Register. เก็บจากแหล่งเดิมเมื่อ 2017-07-03.
  24. ↑ "Trustwave issued a man-in-the-middle certificate". The H Security. 2012-02-07. เก็บจากแหล่งเดิมเมื่อ 2012-03-13. สืบค้นเมื่อ 2012-03-14.

แหล่งข้อมูลอื่น

[แก้]
เข้าถึงจาก "https://th.wikipedia.org/w/index.php?title=ผู้ประกอบการรับรอง&oldid=11013707"