วิกิพีเดีย

ผลต่างระหว่างรุ่นของ "ผู้ประกอบการรับรอง"

เรียกดูประวัติแบบโต้ตอบ
← การแก้ไขก่อนหน้าการแก้ไขถัดไป →
เนื้อหาที่ลบ เนื้อหาที่เพิ่ม
เห็นภาพข้อความวิกิ
Wap (คุย | ส่วนร่วม)
การแก้ไข 5,805 ครั้ง
BotKung (คุย | ส่วนร่วม)
บอต
การแก้ไข 434,714 ครั้ง
ล เก็บกวาดบทความด้วยบอต
บรรทัด 37:
CA ซึ่งออกกลุ่มใบรับรองที่ลูกค้าไว้วางใจสำหรับ e-mail server และ server HTTPS สาธารณะมักจะใช้เทคนิคที่เรียกว่า "การตรวจสอบโดเมน" ในการตรวจสอบผู้รับใบรับรอง การตรวจสอบโดเมนเกี่ยวข้องกับการส่ง e-mail ที่มีการรับรอง token หรือ link ไปยัง e-mail address ที่รู้จักกัน ดำเนินการรับผิดชอบสำหรับโดเมน ซึ่งอาจเป็นรายการ e-mail address ที่ติดต่อทางเทคนิคใน WHOIS entry ของโดเมน หรือ e-mail ที่เกี่ยวกับการบริหารงาน เช่น โดเมน admin@ administrator@ webmaster@ hostmaster@ หรือ postmaster@ Certificate Authorities บางรายอาจยอมรับการใช้ โดเมน root@ info@ หรือ support@ ทฤษฎีที่อยู่เบื้องหลังการตรวจสอบโดเมนก็คือมีเจ้าของโดเมนที่ถูกต้องเท่านั้นจะสามารถอ่าน e-mail ที่ส่งไปยังที่อยู่ของผู้ดูแลระบบ
 
การตรวจสอบโดเมนประสบกับข้อจำกัดของการรักษาความปลอดภัยของโครงสร้างบางอย่าง โดยเฉพาะอย่างยิ่งมันมักจะเสี่ยงต่อการโดนโจมตีที่ช่วยให้ฝ่ายตรงข้ามจะสังเกตเห็น e-mail การตรวจสอบโดเมนที่ส่งโดย CA รวมถึงการโจมตีโปรโตคอลโพรโทคอล DNS TCP และ BGP หรือการประนีประนอมของเราเตอร์ (ซึ่งขาดการคุ้มครองการเข้ารหัสลับของ TLS/SSL) การโจมตีดังกล่าวเป็นไปทั้งบนเครืองข่ายที่ใกล้ CA หรือใกล้โดเมนเหยื่อเอง
 
ผู้ออกใบรับรองบางรายเสนอใบรับรอง Extended Validation (EV) เป็นทางเลือกที่เข้มงวดมากขึ้นในการตรวจสอบโดเมนใบรับรอง 1 ในข้อจำกัดของ EV เป็นวิธีการแก้จุดอ่อนของการตรวจสอบโดเมนคือการโจมตียังคงได้รับใบรับรองใบรับรองการตรวจสอบโดเมนสำหรับโดเมนของผู้เคราะห์ร้ายและปรับใช้ระหว่างการโจมตี ถ้าที่เกิดขึ้นนั้นเป็นเพียงข้อแตกต่างที่สังเกตได้ให้กับผู้ใช้ที่ตกเป็นเหยื่อควรจะเป็นแถบ HTTPS address สีน้ำเงิน มากกว่าจะเป็นสีเขียว ผู้ใช้น้อยคนนักจะมีแนวโน้มที่จะยอมรับข้อแตกต่างนี้ซึ่งเป็นสิ่งชี้แนะของการโจมตีที่กำลังดำเนินการอยู่
บรรทัด 51:
===ตัวอย่าง===
 
การเข้ารหัส public key สามารถนำมาใช้ในการเข้ารหัสข้อมูลที่สื่อสารกันระหว่าง 2 ฝ่าย ซึ่งจะเกิดขึ้นเมื่อเมื่อผู้ใช้เข้าสู่ทุกเว็บไซต์ที่ implement โปรโตคอลโพรโทคอลการรักษาความปลอดภัย HTTP ในตัวอย่างนี้ให้เราคิดว่าผู้ใช้เข้าสู่ระบบ www.bank.example เพื่อธรรมธุรกรรมทางการเงิน เมื่อผู้ใช้เปิดหน้าแรก www.bank.example เขาจะได้รับ public key พร้อมกับข้อมูลทั้งหมดที่แสดงบนหน้าเว็บเบราเซอร์เบราว์เซอร์ public key สามารถนำมาใช้ในการเข้ารหัสข้อมูลจากผู้ใช้ไปยังเซิฟเวอร์ แต่ขั้นตอนที่ปลอดภัยที่จะใช้ในโปรโตคอลโพรโทคอลที่กำหนด key ที่สมมาตรร่วมกัน ข้อความในโปรโตคอลโพรโทคอลดังกล่าวเป็น cipher พร้อมกับ public key และมีเพียงเซิฟเวอร์ของธนาคารเท่านั้นที่มี private key ในการอ่านข้อมูล การสื่อสารดำเนินการโดยใช้ symmetric key ใหม่ ดังนั้นเมื่อผู้ใช้ป้อนข้อมูลบางอย่างไปยังหน้า page ของธนาคารและกด submit ส่งข้อมูลให้ธนาคารแล้วข้อมูลผู้ใช้จะถูกป้อนไปยังหน้า page ซึ่งจะถูกเข้ารหัสโดย web browser นั่นเอง ดังนั้นถึงแม้ว่าบางคนสามารถเข้าถึงข้อมูลที่ถูกสื่อสารจากผู้ใช้ไปยัง www.bank.example ดังนั้นคนดักจับข้อมูลไปมาสามารถอ่านและถอดรหัสได้
 
กลไลนี้จะมีความปลอดภัยในกรณีที่ผู้ใช้มั่นใจได้ว่ามันเป็นธนาคารที่เขาเห็นบนเว็บเบราเซอร์เบราว์เซอร์ของเขา หากผู้ใช้พิมพ์ใน www.bank.example แต่การสื่อสารของเขายังถูกดักจับระหว่างทางและปลอมเว็บไซต์ที่อ้างว่าเป็นของธนาคารส่งข้อมูลหน้า page กลับไปยัง user web-page ปลอมสามารถส่ง public key ปลอมไปยังผู้ใช้ เพื่อที่จะให้เว็บไซต์ปลอมมี private key ที่เข้ากับ public key ปลอม ผู้ใช้จะกรอกแบบฟอร์มที่มีข้อมูลส่วนตัวของเขาและ submit หน้า page หน้าเว็บปลอมจะได้รับการเข้าถึงข้อมูลของผู้ใช้
 
CA เป็นองค์กรที่เก็บ public key และเป็นเจ้าของ ทุกกลุ่มในการสื่อสารไว้วางใจองค์กรนี้และรู้จัก public key ของ CA เมื่อเว็บเบราเซอร์เบราว์เซอร์ของผู้ใช้ได้รับ public key จาก www.bank.example และยังได้รับลายเซ็นดิจิตอลของ key ด้วย เบราเซอร์เบราว์เซอร์ครอบครอง public key ของ CA แล้วจึงสามารถตรวจสอบลายเซ็น ไว้วางใจใบรับรองและ public key ได้ เมื่อ www.bank.example ใช้ public key ซึ่ง CA รับรอง www.bank.example ปลอมสามารถใช้ได้แค่ public key ที่เหมือนกันเท่านั้น เมื่อ www.bank.example ปลอมไม่รู้จัก private key ที่เกี่ยวข้องแล้ว ก็ไม่สามารถลายเซ็นที่จำเป็นในการตรวจสอบความถูกต้อง
 
===การรักษาความปลอดภัย===
 
ปัญหาของการรับประกันความถูกต้องระหว่างข้อมูลและเอกลักษณ์เมื่อข้อมูลถูกนำเสนอให้แก่ CA ซึ่งอาจจะผ่านเครือข่ายอิเล็กทรอนิกส์ และเมื่อข้อมูลประจำตัวบุคคล บริษัท หรือโปรแกรมร้องขอใบรับรองถูกนำเสนอในทำนองเดียวกันเป็นเรื่องยาก นี่คือเหตุผลที่ CA มักจะใช้การผสมผสานของการวิเคราะห์พฤติกรรมที่กำหนดเองและเทคนิคการทำให้น่าเชื่อถือประกอบไปด้วยการใช้ประโยชน์จากรัฐ โครงสร้างค่าใช้จ่าย ฐานข้อมูลของบุคคลที่สามและการบริการ ในบางระบบองค์กร รูปแบบทั่วไปของการตรวจสอบ เช่น Kerberos สามารถใช้ในการขอใบรับรองซึ่งสามารถถูกกลับมาใช้โดยบุคคลภายนอก พนักงานทะเบียนจำเป็นในบางกรณีที่รู้จักกลุ่มซึ่งลายเซ็นถูกรับรอง ซึ่่งซึ่งเป็นมาตรฐานที่สูงกว่าจะมาถึงโดย CA ตามที่เค้าร่างเนติบัณฑิตยสภาอเมริกาในการจัดการธุรกรรมออนไลน์ จุดหลักของธนาคารกลางอเมริกาและกฎเกณฑ์ของรัฐประกาศใช้กฎหมายที่เกี่ยวกับลายเซ็นดิจิตอลได้รับการป้องกันความขัดแย้งและความลำบากมากของกฎเกณฑ์ท้องถิ่นและสร้าง electronic writings ตอบสนองความต้องการแบบดังเดิ้มที่เป็นเอกสารกระดาษ เพิ่มเติม พรบ.อเมริกา E-sign และแนะนำรหัส UETA ช่วยให้แน่ใจว่า
 
1.ลายเซ็น สัญญา หรือบันทึกอื่นๆที่เกี่ยวกับธุรกรรมอาจจะไม่ได้รับการปฏิเสธความมีผลทางกฎหมาย ความถูกต้องหรือการบังคับใช้แต่เพียงผู้เดียว เพราะมันอยู่ในรูปแบบอเล็กทรอนิกส์ และ
บรรทัด 75:
*Certificate Authority Security Council (CASC) – ในเดือนกุมภาพันธ์ 2013, CASC ก่อตั้งขึ้นในฐานะที่เป็นองค์กรที่สนับสนุนอุตสาหกรรมทุ่มเทให้กับปัญหาที่อยู่ในอุตสาหกรรมและความรู้แก่ประชาชนเกี่ยวกับการรักษาความปลอดภัยอินเทอร์เน็ต. สมาชิดผู้ก่อตั้งคือผู้ออกใบรับรองขนาดใหญ่ลำดับที่ 7
* Common Computing Security Standards Forum (CCSF) – ในปี 2009 CCSF ก่อตั้งเพื่อสนับสนุนมาตรฐานอุตสาหกรรมเพื่อปกป้องผู้ใช้งาน. ผูบริหารของ Comodo Group Melih Abdulhayoğlu เป็นผู้ก่อตั้ง CCSF. [18]
* CA/Browser Forum – ในปี 2005, สมาคมผู้ออกใบรับรองแห่งใหม่และผู้ขายเว็บบราวเซอร์เบราว์เซอร์ได้รวมกันสนับสนุนมาตรฐานอุตสาหกรรมและความต้องการพื่นฐานของความปลอดภัยระบบอินเตอร์เน็ตอินเทอร์เน็ต. ผู้บริหาร Comodo Group Melih Abdulhayoğlu จัดการประชุมครั้งแรกและถือว่าเป็นผู้ก่อตั้งฟอรั่ม CA/Browser
 
==การโจมตี CA==
บรรทัด 95:
*TinyCA, which is a perl gui on top of some CPAN modules.
* XCA
* Automated Certificate Management Environment (ACME), ให้โปรโตคอลโพรโทคอลการเข้ารหัสเพื่อการสื่อสารระหว่างผู้ออกใบรับรองและเซิฟเวอร์. ให้การเข้ารหัสแบบ node-acme. Node.js ของ ACME, และการตรวจดูการเข้ารหัส, พื้ฯฐานจากภาษา Python ของการจัดการเซิฟเวอร์ใบรับรองโดยใช้โปรโตคอลโพรโทคอล ACME.
 
[[หมวดหมู่:การเข้ารหัส]]
เข้าถึงจาก "https://th.wikipedia.org/wiki/ผู้ประกอบการรับรอง"