Score:0

mTLS: จำกัดใบรับรองไคลเอนต์เฉพาะโดเมนย่อยหรือไม่

ธง pk
Joe

tldr

ด้วย mTLS ฉันกำลังพยายามหาวิธีออกใบรับรองไคลเอ็นต์ที่อนุญาตให้ไคลเอนต์นั้นเข้าถึงโดเมนย่อยที่ระบุเท่านั้น ฉันสงสัยว่ามันเป็นไปไม่ได้ แต่ฉันไม่แน่ใจ

สิ่งที่ฉันพยายามทำให้สำเร็จ

สมมติว่าฉันมีเซิร์ฟเวอร์ที่ฟังสิ่งที่กำหนดเส้นทางไป *.foo.flar.com

ลูกค้าแต่ละรายได้รับการกำหนดโดเมนย่อยของตนเองซึ่งตรงตามไวลด์การ์ดในที่อยู่ของเซิร์ฟเวอร์

ตัวอย่างเช่น, ลูกค้า1 ควรเข้าถึงเซิร์ฟเวอร์ผ่านทาง ลูกค้า1.foo.flar.com, และ ลูกค้า2 ควรเข้าถึงเซิร์ฟเวอร์ผ่านทาง customer2.foo.flar.com.

นอกจากนี้ ลูกค้ารายหนึ่งต้องถูกป้องกันไม่ให้เข้าถึงเซิร์ฟเวอร์โดยใช้โดเมนย่อยของลูกค้ารายอื่น ดังนั้นจึงผิดกฎหมายสำหรับ ลูกค้า1 การร้องขอ customer2.foo.flar.comและควรปฏิเสธคำขอดังกล่าว

ฉันหวังว่าฉันจะทำสิ่งนี้ได้สำเร็จที่เลเยอร์เซสชันผ่าน mTLS และการใช้ใบรับรอง SAN ที่ชาญฉลาด แต่ฉันมีปัญหาในการทำให้มันทำงานได้อย่างถูกต้อง

ฉันมีการตั้งค่าสิ่งต่าง ๆ อย่างไร

ฉันค่อนข้างใหม่ในการเล่น TLS ดังนั้นสิ่งนี้จึงมาจากหลายสิ่งหลายอย่าง คำตอบ SO นี้เกี่ยวกับการกำหนดค่า SAN และ บทความนี้เกี่ยวกับการกำหนดค่า mTLS พื้นฐาน.

ฉันได้ละเว้นบางสิ่งที่นี่ เช่น การสร้างใบรับรอง CA และไคลเอนต์และการสร้าง CSR ของไคลเอ็นต์และเซิร์ฟเวอร์ เพื่อพยายามโฟกัสสิ่งต่างๆ แต่สามารถเพิ่มได้หากต้องการ

ฉันสร้างใบรับรองเซิร์ฟเวอร์โดยใช้สิ่งที่ต้องการ:

opensl x509 \
  -req \
  -extfile <(printf "subjectAltName=DNS:*.foo.flar.com") \
  -วัน 365 \
  -ในเซิร์ฟเวอร์.csr \ 
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -ออก server.crt

จากนั้นฉันสร้างใบรับรองไคลเอนต์โดยใช้สิ่งต่อไปนี้:

opensl x509 \
  -req \
  -extfile <(printf "subjectAltName=DNS:customer1.foo.flar.com") \
  -วัน 365 \
  -ใน client.csr \ 
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -ออก client.crt

เซิร์ฟเวอร์ (เขียนว่า Go) ได้รับการกำหนดค่าให้ต้องการและตรวจสอบใบรับรองไคลเอ็นต์

ปัญหา

ปัญหาคือเมื่อฉันทดสอบการตั้งค่านี้ การเชื่อมต่อจะสำเร็จทั้งที่ฉันคาดว่าจะล้มเหลว

ถ้าฉันมีลูกค้าออก ลูกค้า1 รับรองเรียกเซิร์ฟเวอร์ที่ ลูกค้า1.foo.flar.comการเชื่อมต่อสำเร็จ

อย่างไรก็ตามหากฉันมีลูกค้าออก ลูกค้า1 รับรองเรียกเซิร์ฟเวอร์ที่ customer2.foo.flar.comการเชื่อมต่อนั้นสำเร็จเมื่อฉันคาดว่าจะล้มเหลว

ฉันหวังว่าเมื่อตรวจสอบใบรับรองของลูกค้าแล้ว เซิร์ฟเวอร์จะเห็นสิ่งนั้น ลูกค้า1 ไม่สามารถเข้าถึง ลูกค้า2...และจะปฏิเสธคำขอ แต่สิ่งนี้ดูเหมือนจะไม่เกิดขึ้น

ไอเดีย?

Score:3
ธง se

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

pk flag
Joe
ดังนั้น การตั้งค่า SAN ในใบรับรองไคลเอ็นต์จึงเป็นข้อมูลเพียงอย่างเดียวและไม่มีผลกระทบอย่างอื่นใช่หรือไม่
pk flag
Joe
ที่จริงตอนนี้ฉันคิดถึงมันมากขึ้นฉันคิดว่ามันสมเหตุสมผลแล้ว เนื่องจาก TLS handshake เกิดขึ้นก่อนที่เซิร์ฟเวอร์จะรู้ว่ากำลังร้องขอทรัพยากรใด จึงไม่มีทางที่ TLS จะดำเนินการที่มีความหมายได้
Nikita Kipriyanov avatar
za flag
อะไรทำให้ใบรับรองไม่ซ้ำใคร อะไรเพียงพอที่จะแยกแยะใบรับรองจากผู้อื่น เช่น การรับรองความถูกต้อง ค่า "ลงนาม" จริงในใบรับรอง thе คือคีย์สาธารณะ และสิ่งที่ทำให้เป็นใบรับรองคือลายเซ็น CA ซึ่งครอบคลุมคีย์นี้คีย์มีความสำคัญเนื่องจากใช้ในการเข้ารหัสแบบอสมมาตรที่แท้จริง ส่วนที่เหลือทั้งหมดเป็น "ข้อมูลล้วน ๆ" อย่างไรก็ตามองค์ประกอบบางอย่างเช่น DN นั้นใช้งานได้ง่ายกว่าและเป็นไปได้ที่จะทำให้เป็นเอกลักษณ์ เช่น มีสิทธิ์ในการรับรองความถูกต้อง
Steffen Ullrich avatar
se flag
@NikitaKipriyanov: * อย่างอื่นเป็น "ข้อมูลล้วนๆ"* - ฉันไม่เห็นด้วย นอกเหนือจากคีย์สาธารณะแล้ว ยังมีข้อจำกัดในการใช้คีย์ วัตถุประสงค์ของใบรับรอง ... ซึ่งมีความหมายและมาตรฐานที่ชัดเจนว่าจะจัดการอย่างไร นอกจากนี้ยังมี SAN (และเก่ากว่า: CN) ซึ่งมีความหมายที่ชัดเจนและเป็นมาตรฐานในบริบทของใบรับรองเซิร์ฟเวอร์และโปรโตคอล เช่น HTTPS, SMTP, IMAP, ... ไม่มีมาตรฐานดังกล่าวสำหรับการจำกัดใบรับรองไคลเอ็นต์เป็นโดเมน
Nikita Kipriyanov avatar
za flag
*การรับรองความถูกต้อง* ตามจริง ซึ่งหมายถึงกระบวนการประเมินตัวตนของนักแสดงนั้นเชื่อมโยงทางคณิตศาสตร์กับคีย์และ *เฉพาะ* กับคีย์เท่านั้น คีย์ส่วนตัวถูกเก็บเป็นความลับโดยบางเอนทิตี และเนื่องจากนักแสดงสามารถถอดรหัสความท้าทายที่เราเข้ารหัสด้วยคีย์สาธารณะของพวกเขา หมายความว่าพวกเขาคือเอนทิตีนี้ ประเภทของเอนทิตีจะถูกบันทึกไว้ในใบรับรอง และความถูกต้องของข้อมูลนี้ได้รับการลงนามโดย CA ในกรณีที่ข้อมูลประจำตัวของเว็บไซต์คือชื่อ ดังนั้น เราจึงเซ็นชื่อร่วมกันโดยคีย์และ SAN ในกรณีของใบรับรองไคลเอ็นต์ เราสามารถใช้คีย์เป็นตัวระบุเอนทิตีได้ เช่นเดียวกับ SSH
Nikita Kipriyanov avatar
za flag
วัตถุประสงค์ของใบรับรอง ข้อจำกัดการใช้คีย์ และอื่นๆ ไม่มีบทบาทใดๆ ในกระบวนการตรวจสอบสิทธิ์ หากการท้าทายถูกถอดรหัสอย่างถูกต้อง เรารู้แน่ว่าอีกฝ่ายมีรหัสส่วนตัว หากใครก็ตามสามารถสร้างตัวตนของคีย์สาธารณะได้ (เช่น โดยใช้บางฟิลด์ของใบรับรอง เช่น SAN) พวกเขาก็จะตรวจสอบความถูกต้องของอีกฝั่งหนึ่ง ฟิลด์อื่นๆ ทั้งหมดเป็นข้อมูลที่เกี่ยวกับการให้สิทธิ์มากกว่า และคุณพูดถูก (ในคำตอบ) ขึ้นอยู่กับอีกฝ่ายว่าพวกเขาจะใช้ประโยชน์จากข้อมูลนั้นได้หรือไม่

โพสต์คำตอบ

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