เหตุใด CA รูตใบรับรองทั้งหมดที่ลงชื่อ SHA-1 (เนื่องจาก SHA-1 เลิกใช้แล้ว)

67

ฉันเข้าใจว่าใบรับรอง SSL ไม่สามารถลงชื่อโดยใช้ SHA-1 ได้อีกต่อไป แต่ใบรับรองหลัก CA ทั้งหมดนั้นลงนามใน SHA-1 (ส่วนใหญ่) หมายความว่าอัลกอริทึมแบบเดียวกันที่ไม่น่าเชื่อถือสำหรับ "you grandma SSL shop" อีกต่อไปนั้นใช้ได้สำหรับใบรับรองที่ปลอดภัยที่สุดในโลกหรือไม่?

ฉันพลาดอะไรไปรึเปล่า? (การใช้คีย์? ขนาดสำคัญ?)

ssl ssl-certificate certificate-authority

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

9

ไม่เป็นความจริงเลยว่าใบรับรอง root CA "ทั้งหมด" นั้นเป็น SHA1

— Greg Askew

5

ใบรับรองหลักเปรียบเสมือนการเริ่มต้นสมมติฐานในมุมมองโลก ต้องใช้ศรัทธาเพื่อไว้วางใจพวกเขา

— Roy Tinker

@RoyTinker ยกเว้นผลรวม cogito (ดูข้อสงสัยอย่างรุนแรงและเป็นคำตอบ: สงสัยคาร์ทีเซียน )?

— Nick T

1

Cross-stack: security.stackexchange.com/questions/120301/…และsuperuser.com/questions/1122069/…

— dave_thompson_085

6

@NickT: เล่นอย่างปลอดภัย - cogito ergo cogito ;-)

— tonysdg

106

ลายเซ็นของใบรับรอง CA หลักไม่สำคัญเลยเนื่องจากไม่จำเป็นต้องตรวจสอบ พวกเขาทั้งหมดลงนามด้วยตนเอง

หากคุณเชื่อถือใบรับรองรูท CA ไม่จำเป็นต้องตรวจสอบลายเซ็น หากคุณไม่ไว้วางใจลายเซ็นนั้นไม่มีค่าสำหรับคุณ

แก้ไข: มีความคิดเห็นที่เกี่ยวข้องบางอย่างด้านล่าง ฉันไม่รู้สึกสะดวกสบายในการคัดลอกหรือใช้ถ้อยคำใหม่และให้เครดิตแทนพวกเขา แต่ฉันยินดีต้อนรับผู้คนเพื่อเพิ่มคำอธิบายให้กับคำตอบนี้

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

3

นำคำถามที่ว่าทำไมพวกเขาถึงลงนามเลย

— Richard Tingle

42

เนื่องจากระบบไม่รองรับใบรับรองที่ไม่ได้ลงนาม

— OrangeDog

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

— Dewi Morgan

20

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

— Jörg W Mittag

13

@DewiMorgan คุณไม่สามารถ "ถอดรหัส" ใบรับรองหลักที่มีการชนกันของข้อมูลแบบแฮชเนื่องจากไคลเอนต์เชื่อถือใบรับรองเองไม่ใช่ลายเซ็น (ด้วยตนเอง) คุณจะต้องกู้คืนคีย์ส่วนตัวซึ่งเป็นการโจมตี RSA ไม่ใช่ในอัลกอริทึมแฮช

— zwol

46

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

ใบรับรองเหล่านี้ (และ บริษัท ที่ลงชื่อด้วยตนเอง) นั้น (อ้างว่าหวังว่า) จะตรวจสอบอย่างละเอียดด้วยวิธีการอื่นนอกเหนือจากลายเซ็นของพวกเขา

— มาร์คเฮนเดอร์สัน
แหล่งที่มา

2

ไม่ต้องพูดถึงการอัปเดตใบรับรองหลักนั้นต้องดำเนินการผ่านกระบวนการนอกวงดนตรีอีกครั้ง

— Kaithar

4

+1 สำหรับ "นัยว่าหวังว่า"

— นาธานออสมัน

6

กรณีเดียวที่มีความสำคัญในกรณีนี้คือหากมีการลงนามในรากโดย SHA-1 SHA-1 สามารถเพิกถอนได้ นั่นคือใครบางคนที่สามารถโจมตี SHA-1 สามารถสร้างการเพิกถอนสำหรับราก และฉันแน่ใจว่าเบราว์เซอร์ไม่ทราบวิธีการยืนยันเพื่อให้ประเทศเดนมาร์กประสบความสำเร็จไม่ยิ่งหย่อนไปกว่าการเชื่อมต่อ SSL ง่อย

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

1

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

— Peter Oehlert

1

ในฐานะที่เป็นหมายเหตุเกี่ยวกับหนึ่งนี้CA บางแห่งได้รับการปรับปรุงใบรับรองหลักและใบรับรองระดับกลางเป็น SHA256 แล้ว

ฉันรู้ว่าปีที่แล้ว GlobalSign อัปเดตใบรับรองของพวกเขาเนื่องจากเรากำลังอัปเดตใบรับรองการลงนามรหัสของเราดังนั้นฉันจึงต้องเพิ่มเชนใหม่ของพวกเขาให้กับใบรับรองเหล่านั้นด้วย

คุณสามารถตรวจสอบใบรับรองเฉพาะที่ได้รับการอัปเดตและใบรับรองใดที่อัปเดต แต่ยังทิ้งใบรับรอง SHA1 ดั้งเดิมไว้ที่นี่ => 1

หวังว่าจะช่วย

— B.Kaatz
แหล่งที่มา

0

สำหรับรูท CA คุณให้ความไว้วางใจกับพับลิกคีย์ของ CA- ซึ่งรวมอยู่ใน CRT - ไม่ว่าจะเป็นลายเซ็นต์ตนเอง

การอธิบาย CA โดยใช้รูปแบบไฟล์. CRT แทนที่จะเป็นพับลิกคีย์สาธารณะ. PEM อนุญาตให้รวมรายละเอียดเพิ่มเติมในนั้น - เช่นชื่อ CA - (แต่อีกครั้งลายเซ็นไม่มีค่า)

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

-1

มีเก่ามากส่วนใหญ่ปี 2006 หรือก่อนหน้านี้เชื่อถือได้แล้วใบรับรอง PIN ของ SHA1 ที่ตรึงไว้ที่เบราว์เซอร์ยอมรับ แต่ไม่ใช่ใบรับรองที่ใหม่กว่า จำได้ไหมว่าเมื่อ Firefox และ Chrome ได้รับการกำหนดเวอร์ชันโดยใช้ตัวเลขหลักเดียว?

ใบรับรองล้มเหลวหากรูท CA ใช้ใบรับรอง SHA1 โดยมีการตั้งค่า Not Before เป็นบางอย่างหลังจากปี 2014 ข้อ จำกัด วันที่จริงขึ้นอยู่กับเบราว์เซอร์หรือแอปพลิเคชันอื่น ห้องโดยสาร WebCA ทำให้สิ่งนี้ชัดเจนเมื่อหลายปีก่อน ทดสอบด้วยตัวเองโดย:

สร้างโครงสร้างพื้นฐานของผู้ให้บริการออกใบรับรองส่วนตัวที่ลงนามด้วย SHA1 เรียกว่า rootSHA1
ให้ rootSHA1 สร้าง CA ที่ "ออก" หรือ CA ระดับ "กลาง" ที่ออกใบรับรองโดยมีการผูกมัดใบรับรองไว้กับรูท เรียกมันว่าสื่อกลาง SHA256
ให้ตัวกลางที่ออก CAS2525 ออก CA สร้างใบรับรองที่เซ็นชื่อด้วยแฮช sha256 หรือสูงกว่า เรียกว่า webServerSHA256
ติดตั้ง webServerSHA256 ลงใน webServerSHA56.mydomain.com
ติดตั้งใบรับรอง rootSHA1, middleSHA256 และ webServerSHA256 ในตำแหน่งที่เหมาะสมใน Google Chrome ติดตั้งรูทไปที่ Trusted Root Certificate Authorities และอื่น ๆ ด้วยเชนใบรับรอง
ไปที่ Google Chrome เพื่อhttps://webServerSHA256.mydomain.com/และตรวจสอบว่าไม่มีกุญแจสีเขียวสำหรับ webServerSHA256 การทดสอบล้มเหลว

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

มันค่อนข้างผิด certs ระดับกลาง (และ EE./leaf certs) จำเป็นต้องใช้ SHA2 แต่ไม่สามารถรูทได้ certs ของ Google ส่งผ่าน CA ส่วนตัว (Google Internet Authority G3) ไปยัง GlobalSign Root CA R2 ซึ่งก็คือ SHA1 และ Chrome ไม่ยอมรับเลย

— dave_thompson_085

ใช่ยอมรับใบรับรอง SHA1 ที่ตรึงไว้แล้ว แต่ไม่ใช่ใบรับรองหลักของ SHA1 ใด ๆ แม้ว่าคุณจะเพิ่มในที่เก็บใบรับรองหลักที่เชื่อถือได้ของคุณเอง เพิ่มกรณีทดสอบลงในคำตอบของฉัน

— rjt