STARTTLS: การสื่อสาร SMTP ที่ปลอดภัยด้วย Opportunistic TLS

กลไกการทำงาน

กระบวนการเริ่มจาก SMTP handshake แบบข้อความธรรมดามาตรฐาน เซิร์ฟเวอร์ประกาศว่ารองรับ STARTTLS ในการตอบกลับ EHLO จากนั้นไคลเอนต์ส่งคำสั่ง STARTTLS หากเซิร์ฟเวอร์ยอมรับ ทั้งสองฝ่ายจะทำ TLS handshake เพื่อสร้างการเข้ารหัส เมื่อชั้นความปลอดภัยทำงานแล้ว เซสชันจะดำเนินต่อด้วยคำสั่ง SMTP มาตรฐาน แต่ข้อมูลทั้งหมดหลังจากนั้นถูกเข้ารหัส

ความสำคัญต่อผู้ส่ง

STARTTLS ป้องกันการดักฟังและการโจมตีแบบ man in the middle ด้วยการเข้ารหัสเส้นทางการสื่อสารระหว่างเซิร์ฟเวอร์เมล หากไม่มี ทราฟฟิก SMTP จะเดินทางเป็นข้อความธรรมดา เปิดเผยเนื้อหาข้อความที่สำคัญและข้อมูลเข้าสู่ระบบแก่ผู้ที่ตรวจสอบเส้นทางเครือข่าย เซิร์ฟเวอร์ปลายทางสมัยใหม่ส่วนใหญ่ให้ความสำคัญหรือกำหนดให้ต้องเชื่อมต่อแบบเข้ารหัสจึงจะรับอีเมล

ข้อพิจารณาในการใช้งานจริง

ความเสี่ยงสำคัญคือ downgrade attack ที่ผู้โจมตีตัดคำสั่ง STARTTLS ออกจากการตอบกลับของเซิร์ฟเวอร์ ทำให้ไคลเอนต์ต้องส่งอีเมลเป็นข้อความธรรมดา เพื่อป้องกัน ผู้ดูแลระบบใช้ MTA-STS หรือกำหนดค่า TLS แบบบังคับได้ การใช้เครื่องมือฟรีของ SendHQ (https://sendhq.cc/tools) ช่วยตรวจสอบการตั้งค่าโดเมนทั่วไปของคุณเพื่อการส่งถึงที่ดีขึ้น

ข้อผิดพลาดที่พบบ่อยในการนำไปใช้

ข้อผิดพลาดที่พบบ่อยคือสับสนระหว่าง STARTTLS กับ Implicit TLS STARTTLS เริ่มบนพอร์ตข้อความธรรมดา (เช่น 587) แล้วอัปเกรด ส่วน Implicit TLS (พอร์ต 465) ต้องทำ handshake ที่ปลอดภัยก่อนส่งคำสั่ง SMTP ใด ๆ การตั้งค่าพอร์ตผิดหรือไม่มีใบรับรอง SSL ที่ถูกต้องจะทำให้เชื่อมต่อล้มเหลวหรือถอยไปส่งแบบไม่ปลอดภัย

ตัวอย่างที่เป็นรูปธรรม

ไคลเอนต์เชื่อมต่อกับพอร์ต 587 และส่ง EHLO เซิร์ฟเวอร์ตอบ 250-STARTTLS ไคลเอนต์ส่ง STARTTLS เซิร์ฟเวอร์ตอบ 220 Ready to start TLS ไคลเอนต์และเซิร์ฟเวอร์เจรจาคีย์และเข้ารหัสเซสชัน จากนั้นไคลเอนต์ส่ง AUTH LOGIN เพื่อให้ข้อมูลรับรองอย่างปลอดภัยโดยไม่เปิดเผยต่อเครือข่าย

คำถามที่ทีมมักถาม

แหล่งข้อมูลหลัก

• ข้อกำหนด RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security — RFC Editor
• ข้อกำหนด RFC 8314: Cleartext Considerations for Post-SMTP Email Protocols — RFC Editor