Https สามารถทำงานได้โดยไม่มีใบรับรองหรือไม่

เมื่อเร็ว ๆ นี้ทีมโครงสร้างพื้นฐานของเราบอกทีมพัฒนาของเราว่าคุณไม่จำเป็นต้องมีใบรับรองสำหรับ https พวกเขากล่าวว่าประโยชน์เพียงอย่างเดียวของการซื้อใบรับรองคือให้ความอุ่นใจแก่ผู้บริโภคว่าพวกเขากำลังเชื่อมต่อกับเว็บไซต์ที่ถูกต้อง

สิ่งนี้ขัดกับทุกสิ่งที่ฉันคาดเดาเกี่ยวกับ https

ฉันอ่านวิกิพีเดียและระบุว่าคุณต้องการใบรับรองที่เชื่อถือได้หรือใบรับรองที่ลงชื่อด้วยตนเองเพื่อกำหนดค่า https

เป็นไปได้หรือไม่ที่จะกำหนดค่า IIS ให้ตอบสนองต่อ https โดยไม่มีใบรับรองใด ๆ ?

— เครื่องหมาย
แหล่งที่มา

คุณอาจพบว่านี่เป็นเพียงปัญหาการสื่อสาร เซิร์ฟเวอร์ของคุณอาจมี certs ที่ลงชื่อด้วยตนเองพร้อมแล้ว อนึ่งคำเตือนนี้คุณควรหลีกเลี่ยงโดยใช้ใบรับรองความน่าเชื่อถือสาธารณะ: m86security.com/kb/article.aspx?id=13446 นั่น อาจเป็นที่ยอมรับในสภาพแวดล้อมของคุณหรืออาจไม่ได้ ฉันว่ามันเป็นมากกว่าแค่ความอุ่นใจ - ในเว็บไซต์สาธารณะมันเป็นสัญญาณของความเป็นมืออาชีพ!

— Dan

Certs ที่ลงชื่อด้วยตนเองจะให้การเข้ารหัสแก่คุณ แต่ไม่สามารถป้องกันจากมนุษย์ในการโจมตีตรงกลางได้เนื่องจากคุณได้รับคำเตือนแบบเดียวกันเกี่ยวกับ certs ที่ไม่ถูกต้องหรือไม่ได้ตรวจสอบสำหรับการเซ็นชื่อด้วยตนเองเช่นเดียวกับที่คุณ ขโมยข้อมูลและเข้ารหัสอีกครั้งเพื่อกลับไปยังไคลเอนต์

— Bart Silverstrim

"certs ที่ลงชื่อเองให้การเข้ารหัสแก่คุณ แต่ไม่สามารถป้องกันจากมนุษย์ในการโจมตีกลาง [... ]" ยกเว้นว่าผู้ใช้สามารถเชื่อถือใบรับรองที่ลงนามด้วยตนเองเหล่านั้นอย่างชัดเจนโดยกลไก out-of-band ซึ่งเป็น เป็นไปได้จริงสำหรับผู้ใช้ฐานขนาดเล็กที่รู้ว่าคุณผ่านกลไกนอกวง ไม่แน่แน่นอน

— Bruno

หรือหากพวกเขาเชื่อมั่นในครั้งแรกพวกเขาจะได้รับการเตือนหากมีการเปลี่ยนแปลงในอนาคต เช่นเดียวกับลายเซ็น SSH จริงๆ

— mfinni

ในทางเทคนิค SSL / TLS ไม่ต้องการใบรับรองเพื่อรักษาความปลอดภัยช่องทางการสื่อสาร อันที่จริงแล้ว SSL / TLS สามารถใช้กลไกอื่นเพื่อรักษาความปลอดภัยของช่อง: pgp certs, ชื่อผู้ใช้ / รหัสผ่าน, คีย์ที่แชร์ล่วงหน้าหรือ "ไม่ระบุชื่อ" (ไม่มีการรับรองความถูกต้องเลย) SSL / TLS ในทำนองเดียวกันไม่รับประกันการเข้ารหัสมีหลาย cyphers ที่สามารถใช้ได้รวมถึง "null" (ไม่มีการเข้ารหัสเลย) และมีตัวเลือกที่คล้ายกันสำหรับการตรวจสอบสิทธิ์ย่อย นั่นคือทั้งหมดที่ดี แต่สิ่งที่โปรแกรมใช้ใด ๆ ของมัน: โดยทั่วไปไม่มีเลยไม่มีเซิร์ฟเวอร์หลักหรือซอฟต์แวร์เบราว์เซอร์ (พวกเขาทั้งหมดต้องใช้ใบรับรอง)

— Chris S

คำตอบ:

ไม่คุณต้องมีใบรับรอง สามารถลงนามด้วยตนเองได้ แต่ต้องมีคู่คีย์สาธารณะ / ส่วนตัวเพื่อแลกเปลี่ยนคีย์สมมาตรเซสชันระหว่างเซิร์ฟเวอร์และไคลเอนต์เพื่อเข้ารหัสข้อมูล

— Driftpeasant
แหล่งที่มา

ผู้ไม่ประสงค์ออกนาม Diffie-Hellman ดังที่ระบุไว้ในคำตอบอื่นอนุญาตการเชื่อมต่อโดยไม่มีใบรับรอง - แต่รุ่น OpenSSL ที่ทันสมัยมักจะถูกคอมไพล์โดยไม่มีการสนับสนุน ADH

— แบรนดอนโรดส์

กล่าวโดยย่อคือไม่มี แต่อาจมีบางกรณีขึ้นอยู่กับวิธีที่คุณต้องการปรับใช้ระบบ

HTTPS คือ HTTP ผ่าน SSL / TLS และคุณสามารถใช้ SSL / TLS ที่ไม่มีการรับรองหรือมีใบรับรองของประเภทอื่น ๆ กว่า X.509

ชุดรหัสไม่ระบุชื่อ: พวกเขาสามารถให้การเข้ารหัส แต่ไม่มีการรับรองความถูกต้อง ค่อนข้างไร้ประโยชน์เท่าที่มีการรักษาความปลอดภัย ... เพื่ออ้างRFC 4346 : " ไม่ระบุชื่อ Diffie-Hellman เป็นกำลังใจอย่างยิ่งเพราะมันไม่สามารถป้องกันการโจมตีของคนใน --- กลาง "
คีย์ที่แชร์ล่วงหน้า : มีกลไกของตัวเองในการตรวจสอบข้อมูลประจำตัวระยะไกล แต่ลักษณะที่ใช้ร่วมกันของคีย์จะนำชุดของปัญหามาใช้
Kerberos cipher suites : ไคลเอ็นต์สามารถตรวจสอบข้อมูลประจำตัวของเซิร์ฟเวอร์กับชื่อหลักของ Kerberos

การพูดอย่างเคร่งครัดHTTP ผ่าน TLS จะระบุข้อมูลต่อไปนี้:

โดยทั่วไปคำขอ HTTP / TLS ถูกสร้างโดยการยกเลิกการลงทะเบียน URI ดังนั้นชื่อโฮสต์ของเซิร์ฟเวอร์จึงเป็นที่รู้จักสำหรับลูกค้า หากชื่อโฮสต์ใช้ได้ลูกค้าต้องตรวจสอบกับข้อมูลประจำตัวของเซิร์ฟเวอร์ตามที่แสดงในข้อความใบรับรองของเซิร์ฟเวอร์เพื่อป้องกันการโจมตีจากคนกลาง

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

กล่าวโดยย่อมีไว้สำหรับการใช้งานอย่างชัดเจนด้วยใบรับรอง X.509 (อ้างอิงอย่างชัดเจน RFC 2459 ซึ่งต่อมาถูกแทนที่โดย RFC 3280 และ 5280: PKIs พร้อมใบรับรอง X.509)

อาจมีกรณีขอบเมื่อคุณใช้ชุดเลขศูนย์ของ Kerberos การถือบัตรบริการ Kerberos ของเซิร์ฟเวอร์อาจถือว่ามีวัตถุประสงค์เดียวกับใบรับรอง X.509 ใน HTTPS ปกติสำหรับการตรวจสอบตัวตนของบุคคลที่อยู่ห่างไกล ไม่เหมาะสมภายในกฎของ RFC 2818 (แม้ว่าอาจอยู่ภายใต้ " ถ้าลูกค้ามีข้อมูลภายนอกเกี่ยวกับตัวตนที่คาดหวังของเซิร์ฟเวอร์การตรวจสอบชื่อโฮสต์อาจถูกละเว้น ") แต่จะไม่เป็นเช่นนั้น ไร้สาระอย่างสมบูรณ์ สิ่งนี้ถูกกล่าวว่าฉันไม่คิดว่าเบราว์เซอร์ปกติรองรับ TLS Kerberos cipher suites โดยทั่วไป (ตัวเลขสามารถรองรับ Kerberos ผ่านการตรวจสอบสิทธิ์ SPNEGO แต่ไม่เกี่ยวข้อง) นอกจากนี้ยังสามารถใช้งานได้ในสภาพแวดล้อมที่เหมาะสมกับการใช้ Kerberos เท่านั้น

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

— บรูโน่
แหล่งที่มา

คุณไม่สามารถใช้ https โดยไม่มีใบรับรองใด ๆ คุณต้องซื้อใบรับรองที่เชื่อถือได้หรือสร้างใบรับรองด้วยตนเองเพื่อทำการทดสอบ ส่วนหนึ่งของการกำหนดค่าเว็บเซิร์ฟเวอร์ของคุณเพื่อใช้ https คือชี้ไปยังไฟล์คีย์ที่ถูกต้อง แน่นอนสิ่งนี้ใช้ได้กับเว็บเซิร์ฟเวอร์ทั้งหมดไม่เพียง แต่กับ iis

— เลด
แหล่งที่มา

ในการทดสอบว่า OpenSSL ของคุณสามารถรองรับการเชื่อมต่อที่ไม่ใช้ใบรับรองหรือไม่ให้เรียกใช้openssl ciphersและค้นหาADHโปรโตคอลเช่นADH-AES256-SHA- หากมีโปรโตคอลดังกล่าวอยู่คุณสามารถตั้งค่าการเชื่อมต่อทางเทคนิคได้โดยไม่ต้องใช้ใบรับรองใด ๆ

— แบรนดอนโรดส์