การบังคับใช้การเข้ารหัสสำหรับ SMTP เป็นความคิดที่ดี (หรือยัง)

ฉันใช้เซิร์ฟเวอร์อีเมลซึ่งปัจจุบันตั้งค่าให้ใช้ TLS ถ้าเป็นไปได้เมื่อส่งและรับอีเมล

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

แต่นี่ยังคงเป็นปัญหาที่เราควรคำนึงถึงหรือปลอดภัยที่จะบอกว่าการบังคับใช้การเข้ารหัสจะไม่เป็นปัญหาอีกต่อไปหรือ

อาจมีผู้ให้บริการรายใหญ่บางรายที่กำลังทำสิ่งนี้อยู่หรือคุณคิดว่าวิธีปฏิบัติที่ดีที่สุดในวันนี้คือ

ปัญหาในทางปฏิบัติคือเซิร์ฟเวอร์ที่ไม่รองรับ SMTP ทุกเครื่อง (RFC ค่อนข้างเก่า) สามารถพูด TLS กับเซิร์ฟเวอร์ของคุณได้ดังนั้นคุณอาจพลาดการรับข้อความอีเมล

ปัญหาเชิงปรัชญาของเรื่องนี้คือเป็นไปไม่ได้ที่จะบอกได้ว่าอีเมลถูกถ่ายทอดหลังจาก (หรือก่อนหน้า) อีเมลมาถึงเซิร์ฟเวอร์ของคุณอย่างไร

ซึ่งหมายความว่าอีเมลอาจถูกส่งเป็นข้อความธรรมดาผ่านรีเลย์เรียบร้อยแล้ว

ใครก็ตามที่จริงจังกับการปกป้องเนื้อหาของอีเมลควรเข้ารหัสร่างกาย ด้วยการเข้ารหัสในเส้นทางมันเป็นไปได้เสมอที่จะถูกส่งในข้อความธรรมดาแล้ว

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

แก้ไข: นี่หมายถึงการบังคับใช้ SMTP สำหรับวัตถุประสงค์ในการส่งต่อไม่ใช่การส่งอีเมล ในการเข้ารหัสการส่งจดหมายควรมีการบังคับใช้เนื่องจากการสนทนา SMTP (ไม่ใช่อีเมลจริง) ที่อาจมีข้อมูลรับรองการตรวจสอบสิทธิ์

ไม่

RFC 821 มีอายุ 33 ปี คุณจะพบอีเมลที่ส่งโดยโปรแกรมที่ไม่สนับสนุน STARTTLS บางครั้งพวกเขาจะเป็นผู้ส่งอีเมลที่ไม่สมบูรณ์ (เช่นสคริปต์ภายใน) บางครั้งระบบที่เต็มรูปแบบซึ่งเก่าแล้วปิดใช้งาน TLS / ไม่ได้รวบรวมในระบบที่ไม่มีเอนโทรปีเพียงพอ ...

ฉันพบเห็นอีเมลขาออกเมื่อไม่นานที่ผ่านมาเนื่องจากการรับปลายทางมีการกำหนดค่าให้อนุญาต SMTP ผ่าน TLS เท่านั้น มันเป็นปัญหาในผู้ส่ง (ไม่ควรใช้การกำหนดค่านั้น) แต่แสดงว่ามันเกิดขึ้น

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

มีhttps://www.eff.org/starttls-everywhereโครงการที่ให้รายชื่อเซิร์ฟเวอร์ smtp ที่คุณสามารถ (ควร?) บังคับใช้การใช้ starttls อย่างมั่นใจ

มันไม่มีจุดหมายอย่างสมบูรณ์และอาจเป็นอันตรายอย่างแข็งขันที่จะปฏิเสธอีเมลจากคนรอบข้างที่ไม่สามารถเข้ารหัสได้

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

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

และอย่างที่คนอื่น ๆ ได้ชี้ให้เห็นการเข้ารหัสลับแบบ on-the-wire และการเข้ารหัสแบบ end-to-end นั้นเป็นสองสิ่งที่แตกต่างกันโดยสิ้นเชิง อย่าสับสนทั้งสอง

นี่เป็นเรื่องนโยบาย

โดยทั่วไปเมื่อมีการบังคับใช้ TLS สำหรับขาเข้า & ขาออกจะทำเพื่อชุดของโดเมนที่ จำกัด ซึ่งได้รับการเห็นชอบจากฝ่ายต่างๆเพื่อตอบสนองความต้องการ (ตัวอย่างเช่นพันธมิตรทางธุรกิจอาจมีข้อตกลงในการเข้ารหัสจดหมายทั้งหมดระหว่าง บริษัท ของพวกเขา)

ยกเว้นว่าข้อตกลงนั้นจะเกิดขึ้นอย่าเปิดโหมดบังคับใช้

ไม่มันเป็นความคิดที่แย่มาก

อันที่จริงแล้วปรากฎว่าเซิร์ฟเวอร์ / ไคลเอนต์STARTTLSส่วนใหญ่ไม่ได้ใช้อัลกอริธึมการลองส่งใหม่โดยไม่ใช้ StartTLS หากการเชื่อมต่อ TLS ล้มเหลวในการเจรจา

ดังนั้นแม้แต่โฆษณา STARTTLS ก็เป็นทางเลือกที่ช่วยลดโอกาสในการได้รับ (และส่ง) อีเมลของคุณ!

เพียงแค่ค้นหาและคุณจะพบว่ามีหลายคนที่ไม่สามารถส่งอีเมลใด ๆ ไปยังโดเมน Microsoft Outlook ที่จัดการโดยคลัสเตอร์ * .protection.outlook.com:

ข้อความ Sendmail ถูกปฏิเสธจาก Microsoft เมื่อใช้ TLS

เหตุผล: 403 4.7.0 การจับมือ TLS ล้มเหลว

ในการสรุปปัญหาที่นำเสนอในสองโพสต์ด้านบน:

• สามารถส่งจดหมายไปยังโฮสต์ใด ๆ นอกเหนือจากที่จัดการโดย Outlook โดยมีหรือไม่มี STARTTLS
• สามารถส่งอีเมลโดยไม่มีใบรับรองไคลเอ็นต์และไม่มี STARTTLS ไปยัง Outlook
• หรือใบรับรองไคลเอนต์ที่มีความยาวเป็นศูนย์
• แต่ไม่ใช่ด้วยใบรับรองที่ Microsoft ไม่ชอบและเมื่อเกิดข้อผิดพลาดลูกค้า (ดีเซิร์ฟเวอร์ที่ทำหน้าที่ในโหมดไคลเอ็นต์) จะไม่พยายามส่งข้อความอีกครั้งโดยไม่ต้อง STARTTLS หากเซิร์ฟเวอร์ของผู้รับโฆษณา STARTTLS!

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

และสิ่งนี้จะเกิดขึ้นค่อนข้างบ่อยกับโดเมนต่าง ๆ ในดินแดน STARTTLS!

น่าเศร้าที่ฉันเคยเป็นผู้สนับสนุน STARTTLS ในอดีตตอนนี้ฉันไม่ได้รับสิทธิ์เลยว่าฉันถูกหลอกโดยโฆษณาที่ปราศจากความเสี่ยงในสิ่งที่ฉันคิดว่าควรจะเป็นการเข้ารหัสแบบฉวยโอกาส

ไม่เพียง แต่คุณไม่จำเป็นต้องใช้ STARTTLS แต่อาจต้องระมัดระวังในการปิดการใช้งานอย่างสมบูรณ์หากคุณต้องการความมั่นใจในการใช้งานร่วมกัน

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

การใช้ TLS แบบฉวยโอกาสนั้นนับเป็นทางออกที่ดีที่สุด มุมของ MITM เป็นข้อถกเถียงกับมันคือปลาเฮอริ่งแดง ท้ายที่สุดดังที่ MH กล่าวไว้ในความคิดเห็นแม้กระทั่ง SMTP "legit" ที่มีการเชื่อมต่อ TLS ก็สามารถ MITM ได้และผู้ใช้ปลายทางก็ไม่ฉลาดเพราะไคลเอ็นต์อีเมลส่วนใหญ่ไม่รบกวนการตรวจสอบใบรับรองควบคู่ไปกับคนส่วนใหญ่ ของ MTAs ที่มีการทำ TLS กำลังใช้ใบรับรองที่ลงนามด้วยตนเอง (อย่างน้อยถ้าคุณไม่ได้ใช้ DNSSEC และ TLSA / DANE) อันเป็นผลมาจากสิ่งนี้และปัจจัยอื่น ๆ มันอาจจะพิสูจน์ได้ว่าจนกว่าคุณและส่วนที่เหลือของโลก ได้ใช้งาน DANE / TLSA และ DNSSEC ซึ่งในขณะที่ใช้งาน TLS แบบฉวยโอกาสมันก็ยังดีกว่าที่จะไม่เปิดใช้งาน diffie-hellman แบบไม่ระบุชื่อ (ในขณะที่ใช้ PFS) ด้วยเช่นกัน เนื่องจากอย่างน้อยส่วนหนึ่งหากไม่ได้เป็นส่วนใหญ่กับความจริงที่ว่ามันจะยังคงเข้ารหัสการจราจรป้องกันผู้สังเกตการณ์ชั่วคราว ในการสนับสนุนการกำหนดค่านี้เพิ่มเติม (พร้อมคำอธิบายที่ละเอียดกว่าเหมือง) โปรดดูความคิดเห็นของ Viktor Dukhovni ในโพสต์นี้ในฟอรัม postfix:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

สำหรับเหตุผลที่ว่าทำไมคนหนึ่งถึงรับข้อเสนอแนะของ Viktor มากกว่าคนอื่นเขาก็เขียนรหัส TLS เช่นเดียวกับ DNSSEC, TLSA / รหัส DANE สำหรับ Postfix MTA และเป็นผู้เขียน IETF ฉบับร่างทั้งสอง DNSSEC และ TLSA / DANE ดังนั้นฉันจะบอกว่าคำพูดของเขาในเรื่องนี้มีน้ำหนักค่อนข้างมากอาจมากกว่าคำพูดส่วนใหญ่

หวังว่านี่จะช่วยได้

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