ในธันเดอร์เบิร์ด (และฉันถือว่าอยู่ในไคลเอนต์อื่น ๆ ด้วย) ฉันมีตัวเลือกให้เลือกระหว่าง "SSL / TLS" และ "STARTTLS"
เท่าที่ผมเข้าใจมัน "STARTTLS" หมายถึงในคำง่ายๆ"เข้ารหัสถ้าปลายทั้งสองสนับสนุน TLS อย่างอื่นไม่เข้ารหัสโอน" และ "SSL / TLS" หมายถึงในคำง่ายๆ"เสมอเข้ารหัสหรือไม่ได้เชื่อมต่อที่ทุกคน" ถูกต้องหรือไม่
หรือในคำอื่น ๆ :
STARTTLS ปลอดภัยน้อยกว่า SSL / TLS หรือไม่เพราะสามารถย้อนกลับมาเป็นข้อความธรรมดาโดยไม่แจ้งให้ฉันทราบ
คำตอบ:
คำตอบที่อิงตาม STARTTLS RFC สำหรับ SMTP ( RFC 3207 ) คือ:
แทนที่จะพูดด้วยตัวเองฉันจะอนุญาตให้ RFC พูดด้วยตัวเองโดยมีบิตที่เกี่ยวข้องสี่รายการที่ไฮไลต์ในBOLD :
การโจมตีแบบ man-in-the-the-middle สามารถเริ่มต้นได้โดยการลบการตอบสนอง "250 STARTTLS" จากเซิร์ฟเวอร์ นี่จะทำให้ไคลเอ็นต์ไม่พยายามเริ่มเซสชัน TLS การโจมตีแบบ Man-in-the-middle อื่น ๆ คือการอนุญาตให้เซิร์ฟเวอร์ประกาศความสามารถของ STARTTLS แต่เพื่อเปลี่ยนแปลงคำขอของลูกค้าเพื่อเริ่มต้น TLS และการตอบสนองของเซิร์ฟเวอร์ เพื่อป้องกันการโจมตีดังกล่าวทั้งไคลเอนต์และเซิร์ฟเวอร์จะต้องสามารถกำหนดค่าให้ต้องการการเจรจา TLS ที่ประสบความสำเร็จของชุดรหัสที่เหมาะสมสำหรับโฮสต์ที่เลือกก่อนที่ข้อความจะสามารถถ่ายโอนได้สำเร็จ ตัวเลือกเพิ่มเติมของการใช้ TLS เมื่อเป็นไปได้ควรมีให้ การใช้งานอาจ จัดเตรียมความสามารถในการบันทึกว่า TLS ถูกใช้ในการสื่อสารกับเพื่อนที่กำหนดและสร้างคำเตือนหากไม่ได้ใช้ในเซสชันภายหลัง
หากการเจรจา TLS ล้มเหลวหรือหากลูกค้าได้รับการตอบกลับ 454 ลูกค้าจะต้องตัดสินใจว่าจะทำอย่างไรต่อไป มีสามตัวเลือกหลัก: ไปข้างหน้ากับส่วนที่เหลือของเซสชัน SMTP , [... ]
อย่างที่คุณเห็น RFC เองแจ้ง (ไม่ชัดเจน แต่ชัดเจนเพียงพอ) ว่าไม่มีสิ่งใดที่ลูกค้าต้องการสร้างการเชื่อมต่อที่ปลอดภัยและแจ้งให้ผู้ใช้ทราบหากการเชื่อมต่อที่ปลอดภัยล้มเหลว มันชัดเจนจะช่วยให้ลูกค้าเลือกที่จะเงียบสร้างข้อความธรรมดาเชื่อมต่อ
ไม่มีความแตกต่างในความปลอดภัยระหว่างสองตัวเลือก
SSL / TLS เปิดการเชื่อมต่อ SSL / TLS ก่อนจากนั้นจึงเริ่มทำธุรกรรม SMTP สิ่งนี้จะต้องเกิดขึ้นบนพอร์ตที่ไม่มีเซิร์ฟเวอร์ SSL / TLS SMTP ที่ไม่ทำงานอยู่แล้ว เป็นไปไม่ได้ที่จะกำหนดค่าพอร์ตเดียวเพื่อจัดการทั้งข้อความธรรมดาและการเชื่อมต่อที่เข้ารหัสเนื่องจากลักษณะของโปรโตคอล
STARTTLS เริ่มทำธุรกรรม SMTP และค้นหาการสนับสนุนจาก TLS อื่น ๆ เพื่อตอบสนองต่อ EHLO หากลูกค้าเห็น STARTTLS ในรายการคำสั่งที่รองรับก็จะส่ง STARTTLS และเริ่มการเจรจาเพื่อทำการเข้ารหัส ทั้งหมดนี้สามารถ (และมักจะเกิดขึ้น) ที่พอร์ต SMTP มาตรฐานที่ 25 ส่วนหนึ่งเพื่อความเข้ากันได้แบบย้อนหลัง แต่ยังอนุญาตการเข้ารหัสแบบฉวยโอกาสระหว่างปลายทางที่ทั้งสองรองรับ แต่ไม่จำเป็นต้องใช้
โดยทั่วไป SSL / TLS จะใช้เฉพาะระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ STARTTLS ใช้กันอย่างแพร่หลายระหว่าง MTA เพื่อความปลอดภัยในการขนส่งระหว่างเซิร์ฟเวอร์
จากการใช้งานทั้งสองแบบนั้น STARTTLS อาจถูกตีความว่าไม่ปลอดภัยหากผู้ใช้หรือผู้ดูแลระบบสันนิษฐานว่าการเชื่อมต่อนั้นได้รับการเข้ารหัส แต่ยังไม่ได้กำหนดค่าให้ต้องมีการเข้ารหัส อย่างไรก็ตามการเข้ารหัสที่ใช้นั้นเหมือนกับ SSL / TLS ดังนั้นจึงไม่มีความเสี่ยงในการโจมตี Man-in-the-Middle มากไปกว่าข้อผิดพลาดการกำหนดค่าประเภทนี้
สำหรับอีเมลโดยเฉพาะในเดือนมกราคม 2018 RFC 8314เปิดตัวซึ่งแนะนำอย่างชัดเจนว่า "Implicit TLS" ถูกนำมาใช้ในการตั้งค่าตามกลไก STARTTLS สำหรับการส่ง IMAP, POP3 และ SMTP
โดยสังเขปตอนนี้บันทึกนี้แนะนำว่า:
- TLS เวอร์ชัน 1.2 ขึ้นไปจะใช้สำหรับการรับส่งข้อมูลทั้งหมดระหว่าง MUAs และเซิร์ฟเวอร์การส่งเมลและระหว่างเซิร์ฟเวอร์การเข้าถึงเมลและเซิร์ฟเวอร์การเข้าถึงเมล
- MUAs และผู้ให้บริการเมล (MSP) (a) ไม่สนับสนุนการใช้โปรโตคอล cleartext สำหรับการเข้าถึงจดหมายและการส่งจดหมายและ (b) เลิกใช้โปรโตคอล cleartext เพื่อวัตถุประสงค์เหล่านี้โดยเร็วที่สุด
- การเชื่อมต่อกับเซิร์ฟเวอร์การส่งเมลและเซิร์ฟเวอร์การเข้าถึงเมลทำได้โดยใช้ "Implicit TLS" (ตามที่กำหนดไว้ด้านล่าง) เพื่อ เชื่อมต่อกับพอร์ต "cleartext" และต่อรอง TLS โดยใช้คำสั่ง STARTTLSหรือคำสั่งที่คล้ายกัน
(เน้นเพิ่ม)
คำตอบนั้นขึ้นอยู่กับระดับความปลอดภัยของคุณ
ก่อนอื่นข้อมูลสรุปของคุณไม่ได้จับความแตกต่างระหว่าง SSL / TLS และ STARTTLS
หากไคลเอ็นต์ได้รับการกำหนดค่าให้ต้องใช้ TLS ทั้งสองวิธีจะมีความปลอดภัยเท่าเทียมกันมากขึ้นหรือน้อยลง แต่มีรายละเอียดปลีกย่อยเกี่ยวกับวิธีการที่ต้องใช้ STARTTLS เพื่อให้ปลอดภัยและเป็นการยากยิ่งขึ้นสำหรับการใช้งาน STARTTLS เพื่อให้ได้รายละเอียดเหล่านั้นถูกต้อง
ในทางกลับกันหากลูกค้าได้รับการกำหนดค่าให้ใช้ TLS เฉพาะเมื่อ TLS พร้อมใช้งานและใช้ cleartext เมื่อไม่มี TLS สิ่งที่ไคลเอ็นต์อาจทำคือพยายามเชื่อมต่อกับพอร์ต SSL ที่ใช้โดยโปรโตคอลก่อนและหากเป็นเช่นนั้น ล้มเหลวจากนั้นเชื่อมต่อกับพอร์ต cleartext และลองใช้ STARTTLS และในที่สุดก็กลับไปที่ cleartext หาก TLS ไม่สามารถใช้ได้ในทั้งสองกรณี เป็นเรื่องง่ายสำหรับผู้โจมตีที่จะทำให้การเชื่อมต่อพอร์ต SSL ล้มเหลว (สิ่งที่ต้องทำคือแพ็คเก็ต TCP RST ที่หมดเวลาหรือบล็อกพอร์ต SSL) มันยากขึ้นนิดหน่อย - แต่เพียงเล็กน้อยเท่านั้น - สำหรับผู้โจมตีที่จะเอาชนะการเจรจา STARTTLS และทำให้ปริมาณการใช้ข้อมูลยังคงอยู่ในข้อความที่ชัดเจน จากนั้นผู้โจมตีไม่เพียง แต่จะอ่านอีเมลของคุณเท่านั้น แต่ยังสามารถเก็บชื่อผู้ใช้ / รหัสผ่านของคุณเพื่อใช้ในอนาคต
ดังนั้นคำตอบง่ายๆคือถ้าคุณกำลังเชื่อมต่อกับเซิร์ฟเวอร์ที่คุณรู้อยู่แล้วว่ารองรับ TLS (เช่นในกรณีที่คุณกำลังส่งหรืออ่านอีเมล) คุณควรใช้ SSL / TLS หากการเชื่อมต่อถูกโจมตีความพยายามในการเชื่อมต่อจะล้มเหลว แต่รหัสผ่านและอีเมลของคุณจะไม่ถูกบุกรุก
ในทางกลับกันหากคุณกำลังเชื่อมต่อกับบริการบางอย่างที่คุณไม่ทราบว่ารองรับ TLS หรือไม่ STARTTLS อาจดีกว่าเล็กน้อย
เมื่อมีการคิดค้น STARTTLS การโจมตีแบบฟังอย่างเดียวเท่านั้นที่เป็นเรื่องปกติการโจมตี "ที่ใช้งาน" ซึ่งผู้โจมตีจะฉีดทราฟฟิกเพื่อพยายามลดความปลอดภัยให้น้อยลง ใน 20 ปีหรือมากกว่านั้นการโจมตีที่แอคทีฟกลายเป็นไปได้และเป็นเรื่องปกติ
ตัวอย่างเช่นหากคุณกำลังพยายามใช้แล็ปท็อปในสนามบินหรือสถานที่สาธารณะอื่น ๆ และลองอ่านจดหมายของคุณผ่าน wifi ที่มีให้คุณไม่ทราบว่าเครือข่าย wifi กำลังทำอะไรกับการจราจรของคุณ เป็นเรื่องธรรมดามากสำหรับเครือข่าย wifi ที่กำหนดเส้นทางการรับส่งข้อมูลบางประเภทไปยัง "พร็อกซี" ที่แทรกซึมระหว่างแอปพลิเคชันไคลเอนต์ของคุณและเซิร์ฟเวอร์ที่พวกเขากำลังพยายามคุยด้วย มันเป็นเรื่องธรรมดาสำหรับพร็อกซี่เหล่านั้นที่จะปิดการใช้งานทั้ง STARTTLS และ "ลองหนึ่งพอร์ตแล้วลองอีกครั้ง" เพื่อพยายามให้ลูกค้าของคุณถอยกลับไปเป็นข้อความธรรมดา ใช่เกิดขึ้นและเป็นเพียงตัวอย่างหนึ่งของวิธีที่การจราจรของคุณสามารถถูกสอดแนมในเครือข่าย และการโจมตีดังกล่าวไม่ได้ จำกัด อยู่ที่หน่วยงานที่ได้รับการสนับสนุนจากรัฐสามตัวอักษร
ใช่คุณมีพื้นฐานที่ถูกต้อง และใช่ STARTTLS ปลอดภัยน้อยกว่าแน่นอน ไม่เพียง แต่จะสามารถย้อนกลับมาเป็นข้อความธรรมดาโดยไม่ต้องแจ้งให้ทราบเท่านั้น แต่เป็นเพราะการโจมตีแบบกลางคน เนื่องจากการเชื่อมต่อเริ่มต้นในที่ชัดเจน MitM สามารถตัดคำสั่ง STARTTLS ออกและป้องกันการเข้ารหัสที่เกิดขึ้น อย่างไรก็ตามฉันเชื่อว่าเซิร์ฟเวอร์อีเมลสามารถระบุได้ว่าการถ่ายโอนเกิดขึ้นหลังจากอุโมงค์ที่เข้ารหัสได้รับการตั้งค่าแล้ว ดังนั้นคุณสามารถหลีกเลี่ยงปัญหานี้
แล้วทำไมเรื่องแบบนี้ถึงมีอยู่จริง? สำหรับเหตุผลที่เข้ากันได้ หากด้านใดด้านหนึ่งไม่รองรับการเข้ารหัสคุณอาจยังต้องการให้การเชื่อมต่อเสร็จสมบูรณ์อย่างถูกต้อง
เห็นด้วยกับ @Greg การโจมตีเหล่านั้นเป็นไปได้ อย่างไรก็ตาม MTA สามารถกำหนดค่าได้ (ขึ้นอยู่กับ MTA) เพื่อใช้ "ข้อบังคับ TLS" ไม่ใช่ "ฉวยโอกาส TLS" สิ่งนี้หมายความว่า TLS และใช้ TLS เท่านั้น (ซึ่งรวมถึง STARTTLS) สำหรับธุรกรรมอีเมล หาก MTA ระยะไกลไม่รองรับ STARTTLS อีเมลจะถูกตีกลับ
ไม่มันไม่ปลอดภัยน้อยกว่าเมื่อแอปพลิเคชันของคุณจัดการอย่างถูกต้อง
มีสี่วิธีในการจัดการ TLS และหลายโปรแกรมให้คุณเลือก:
starttlsใช้การเชื่อมต่อที่ไม่เข้ารหัสเมื่อล้มเหลว)starttlsและล้มเหลวหากไม่ได้ผล)ข้อดีของ TLS บนพอร์ตเฉพาะคือคุณสามารถมั่นใจได้ว่าจะไม่มีทางเลือกเมื่อคุณใช้โปรแกรมที่คุณยังไม่รู้หรือที่ไม่ได้เปิดเผยการตั้งค่ารายละเอียดสำหรับการจัดการข้อผิดพลาดในตัวช่วยเริ่มแรก
แต่โดยทั่วไปความปลอดภัยขึ้นอยู่กับการจัดการข้อผิดพลาดด้านความปลอดภัย โปรแกรมสามารถตัดสินใจที่จะสลับไปยังพอร์ตธรรมดาเมื่อ TLS บน TLS- พอร์ตล้มเหลวเช่นกัน คุณจำเป็นต้องรู้ว่ามันจะทำอะไรและเลือกการตั้งค่าที่ปลอดภัย และโปรแกรมควรใช้ค่าเริ่มต้นที่ปลอดภัย