ชื่อโฮสต์ใดที่ใบรับรอง SSL สำหรับเซิร์ฟเวอร์ SMTP ควรมี

ฉันมีเซิร์ฟเวอร์ foo.example.com ที่ 192.0.2.1

มันทำงาน exim เพื่อรับอีเมลสำหรับหลาย ๆ โดเมนของฉัน

แต่ละโดเมนของฉันมีระเบียน MX ที่ชี้ไปที่ mx.example.com ซึ่งแก้ไขเป็น 192.0.2.1

หากฉันต้องการทำการเข้ารหัส TLS ของ exim ให้สำหรับการเชื่อมต่ออีเมลขาเข้าฉันควรใส่ชื่อโฮสต์ใดในใบรับรอง SSL

• foo.example.com เพราะนั่นคือสิ่งที่เซิร์ฟเวอร์จะพูดใน HELO หรือไม่
• mx.example.com เพราะนั่นคือชื่อโฮสต์ที่ไคลเอ็นต์จะเชื่อมต่อหรือ

http://www.checktls.comแนะนำว่าแบบหลังนั้นถูกต้อง แต่ฉันไม่พบคำตอบที่ชัดเจน

นี่ไม่ได้กำหนดไว้อย่างชัดเจนที่ใดและเซิร์ฟเวอร์ควร "เชื่อถือ" หรือไม่นั้นขึ้นอยู่กับไคลเอนต์ (ซึ่งอาจเป็นเซิร์ฟเวอร์เมลอื่น) ที่เชื่อมต่อกับเซิร์ฟเวอร์ ข้อความอ้างอิงจาก RFC ที่เกี่ยวข้อง ( RFC 2487 ):

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

การตัดสินใจว่าจะเชื่อความถูกต้องของ
อีกฝ่ายในการเจรจา TLS หรือไม่นั้นเป็นเรื่องท้องถิ่น อย่างไรก็ตาม
กฎทั่วไปบางประการสำหรับการตัดสินใจคือ:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

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

แต่เดี๋ยวก่อนยังมีอีกมาก การอ้างอิงอีกครั้งจาก RFC เดียวกัน:

เมื่อการจับมือ TLS เสร็จสมบูรณ์โปรโตคอล SMTP จะถูกรีเซ็ต
เป็นสถานะเริ่มต้น (สถานะใน SMTP หลังจากเซิร์ฟเวอร์ออก
คำทักทายพร้อมบริการ220 ) เซิร์ฟเวอร์ต้องทิ้งความรู้ใด ๆ ที่
ได้รับจากลูกค้าเช่นอาร์กิวเมนต์ไปยังคำสั่ง EHLO
ซึ่งไม่ได้รับจากการเจรจา TLS ลูกค้าจะ
ต้องทิ้งความรู้ที่ได้รับจากเซิร์ฟเวอร์เช่นรายการ
ส่วนขยายบริการ SMTP ซึ่งไม่ได้รับจากการ
เจรจาTLS เอง ลูกค้าควรส่งคำสั่ง EHLO เป็น
คำสั่งแรกหลังจากการเจรจา TLS สำเร็จ

ดังนั้นสิ่งที่เซิร์ฟเวอร์กำลังพูดเพื่อตอบสนองต่อ HELO / EHLO ก่อนการจับมือ TLS ดูเหมือนจะไม่สำคัญเลย

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

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

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

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

ดังนั้นชื่อโฮสต์ในใบรับรองควรตรงกับชื่อที่ลูกค้าพยายามเข้าถึง

เมื่อเริ่มต้นการเชื่อมต่อ SSL / TLS ล่วงหน้า (SMTPS) เซิร์ฟเวอร์จะไม่มีทางเห็นสิ่งที่ข้อความ HELO พูดก่อนที่จะสร้างการเชื่อมต่อดังนั้นจึงต้องใช้สิ่งที่ร้องขอ

เมื่อใช้ SSL / TLS หลังจากSTARTTLSไคลเอนต์ยังคงตั้งใจที่จะพูดคุยกับเซิร์ฟเวอร์ที่มีการกำหนดค่าดังนั้นจึงยังคงเป็นสิ่งที่ควรตรวจสอบ ความล้มเหลวที่จะทำให้การโจมตี MITM เป็นไปได้:

• C-> S: สวัสดีฉันชื่ออลิซฉันอยากคุยกับบ๊อบ
• S-> C: สวัสดีฉันชัคนี่คือใบรับรองสำหรับชัคของฉัน
• C-> S: โอ้ใช่ใบรับรองของคุณใช้ได้กับชัคแน่นอน มาเริ่มกันเลยดีกว่า
• ... มีข้อบกพร่องแน่นอนเนื่องจากอลิซต้องการการสื่อสารที่ปลอดภัยกับบ๊อบ

ในทั้งสองกรณีเป็นที่อยู่ MX ที่ควรใช้

กฎการจับคู่ชื่อโฮสต์เพิ่งได้รับการรวบรวมข้ามโปรโตคอลในRFC 6125แต่มีลูกค้าเพียงไม่กี่รายที่ใช้งานได้อย่างสมบูรณ์ (เป็นวิธีปฏิบัติที่ดีที่สุดของ RFC มากกว่าการเปลี่ยนแปลงทั้งหมด

ในภาคผนวกจะสรุปสิ่งที่มีอยู่เกี่ยวกับ SMTP ก่อน (นำมาจากRFC 3207และRFC 4954 ) โดยเฉพาะอย่างยิ่ง " ลูกค้าจะต้องไม่ใช้รูปแบบใด ๆ ของชื่อโฮสต์เซิร์ฟเวอร์ที่ได้มาจากแหล่งข้อมูลระยะไกลที่ไม่ปลอดภัย (เช่นการค้นหา DNS ที่ไม่ปลอดภัย) " (ซึ่งใช้กับแบนเนอร์ของเซิร์ฟเวอร์แน่นอน) นอกจากนี้กฎมรดกของ SMTP เป็นบิตผ่อนคลายมากขึ้นกว่า HTTPS เกี่ยวกับเรื่องชื่อทางเลือก ( ควรแทนจะต้องนำมาใช้)

วิธีที่ทันสมัยคือการใส่ชื่อโฮสต์ในรายการ Subject Alternative Name DNS การใช้สัญลักษณ์ยังเป็นกำลังใจ

ฉันคิดว่าสิ่งที่ดีที่สุดคือการคัดลอกสิ่งที่ทำในทางปฏิบัติ ฉันตรวจสอบที่อยู่อีเมล yahoo.com โดยใช้http://checktls.com หวังว่าที่ yahoo พวกเขาใช้โดเมนอื่นสำหรับชื่อโฮสต์และโดเมน mx ของพวกเขา ดังนั้นชื่อโฮสต์ของพวกเขาคือ yahoo.com และโดเมน mx ของพวกเขาลงท้ายด้วย yahoodns.net

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

ผลลัพธ์ของการตรวจสอบ: ใบรับรอง SSL CN = MX โดเมน (* .yahoodns.net)

ฉันทำเช่นเดียวกันกับซิสโก้และฉันก็มีผลลัพธ์เหมือนกัน

ในการเข้ารหัส SSL / TLS ไคลเอนต์จะตรวจสอบความสอดคล้องกันระหว่างชื่อโฮสต์ "ของจริง" / "ประกาศ" บนเครื่องระยะไกลและข้อมูลที่มีอยู่ในหนังสือรับรอง

ดังนั้นคุณควรตั้ง foo.example.com หรือสร้างใบรับรองไวด์การ์ด ;-)