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

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

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

บทนำ

เพื่ออำนวยความสะดวกในการทำความเข้าใจ ฉันจะเน้นสามขั้นตอนระดับสูงของการสร้างการเชื่อมต่อระหว่างเมลเซิร์ฟเวอร์

การค้นหาเซิร์ฟเวอร์ เมลของผู้รับกระบวนการค้นหาว่าเซิร์ฟเวอร์เมลใดมีไว้เพื่อรับเมลสำหรับโดเมนของผู้รับที่กำหนด

การ เชื่อมต่อกับเซิร์ฟเวอร์เมลของผู้รับ โดยระบุเซิร์ฟเวอร์เมลที่ถูกต้อง กระบวนการเชื่อมต่อและรักษาความปลอดภัยของการเชื่อมต่อด้วยการเข้ารหัสที่เหมาะสม (หรือที่เรียกว่า TLS)

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

การค้นพบเมลเซิร์ฟเวอร์ของผู้รับ

วิธีนี้ทำได้โดย การค้นหา DNSของระเบียน MX (Mail Exchange) ซึ่งชี้ไปยังที่อยู่ IP ของเซิร์ฟเวอร์อีเมลตั้งแต่หนึ่งรายการขึ้นไปที่มีจุดประสงค์เพื่อรับอีเมลสำหรับโดเมนผู้รับ อย่างไรก็ตาม มีกลไกอื่นๆ เช่น MTA-STS, ระเบียน SRV หรือแม้แต่ระเบียน A เราจะกล่าวถึงองค์ประกอบบางอย่างของ MTA-STS เพิ่มเติมด้านล่าง แต่ไม่รวมถึงแนวทางบันทึก SRV/A (แม้ว่าจะมีจุดอ่อนเหมือนกันก็ตาม)

การค้นหาเซิร์ฟเวอร์อีเมลอาศัยDNSและการสืบค้น DNS ส่วนใหญ่ยังคงใช้แพ็กเก็ต UDP ดังนั้นจึงไม่มีการเชื่อมต่อและไม่ได้เข้ารหัส ทำให้ค่อนข้างง่ายที่จะสกัดกั้นและใส่การตอบสนองที่ปลอมแปลง

แม้ว่าจะมีการใช้งาน DNS ที่ใช้ TCP, TLS และแม้แต่DNS ผ่าน HTTPSก็ตาม สิ่งเหล่านี้ค่อนข้างผิดปกติ แต่ก็ลดศักยภาพในการสกัดกั้นและการฉีดระหว่างไคลเอ็นต์และเซิร์ฟเวอร์

อย่างไรก็ตาม การปรับใช้ TCP/TLS มุ่งเน้นที่การปรับปรุงหรือรักษาความปลอดภัยของการเชื่อมต่อ พวกเขาไม่ได้เตรียมกลไกที่จะรับประกันว่าข้อมูล การตอบสนองต่อการค้นหา DNS เป็นของแท้และไม่ได้ถูกแก้ไข

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

แล้วเดนล่ะ?

• DANE ต้องการ DNSSEC สำหรับการค้นหา DNS ทั้งหมด ซึ่งช่วยลดความเสี่ยงนี้ได้สำเร็จ

• MTA-STS เผยแพร่เซิร์ฟเวอร์อีเมลที่มีสิทธิ์สำหรับโดเมน โดยการแสดงรายการเซิร์ฟเวอร์เหล่านี้ภายในไฟล์นโยบาย MTA-STS ที่โฮสต์บนเว็บเซิร์ฟเวอร์ แม้ว่าการเชื่อมต่อกับเว็บเซิร์ฟเวอร์เองอาจเป็น HTTPS (พร้อมการตรวจสอบใบรับรอง) แต่การค้นหา DNS ของเว็บเซิร์ฟเวอร์นั้นไม่จำเป็นต้องมีความปลอดภัย
• MTA-STS ไม่ได้บังคับให้ใช้ DNSSEC อันที่จริง ความเข้าใจของฉันคือหนึ่งใน 'คุณสมบัติการออกแบบ' ของมันคือมันไม่ได้ขึ้นอยู่กับ DNSSEC

• การค้นหาเซิร์ฟเวอร์อีเมลของโดเมนผู้รับขึ้นอยู่กับ DNS ซึ่งหากไม่มี DNSSEC จะขาดความปลอดภัยในการรับประกันการตอบกลับที่ได้รับ
• DANE กำหนดให้ใช้ DNSSEC ดังนั้นในฐานะที่เป็นส่วนขยายของ SMTP จึงเป็นกลไกที่มีประสิทธิภาพมากที่สุดในการป้องกันความเสี่ยงนี้
• MTA-STS ไม่ได้บังคับให้ใช้ DNSSEC และแม้จะโฮสต์นโยบายบนเซิร์ฟเวอร์ HTTPS ที่ปลอดภัย แต่ก็ยังใช้การค้นหา DNS แบบดั้งเดิม
• อย่างไรก็ตาม MTA-STS สามารถปรับใช้กับ DNSSEC ซึ่งจะช่วยลดความเสี่ยงนี้ได้มาก นี่เป็นคำแนะนำของฉันหากคุณอยู่ในขั้นตอนการปรับใช้ MTA-STS

โลกเปลี่ยนไปใช้ HTTPS ในพริบตาเดียว ทุกวันนี้พบเว็บไซต์ที่ไม่รองรับ HTTPS (แม้แต่เว็บไซต์ที่ไม่ใช้รายละเอียดบัตรเครดิตของคุณ) เป็นเรื่องผิดปกติอย่างมาก อย่างไรก็ตาม อีเมลไม่เห็นการเปลี่ยนแปลงขั้นตอนเดียวกันในเรื่องความปลอดภัย และยังคงอาศัยสิ่งที่เราเรียกว่า “TLS ฉวยโอกาส” ใน TLS ที่ฉวยโอกาส เซิร์ฟเวอร์จะสร้างการเชื่อมต่อที่ไม่ปลอดภัยก่อน จากนั้นจึงพยายามเจรจาและอัปเกรดการเชื่อมต่อเป็น TLS แต่จะดำเนินการต่อไปอย่างมีความสุขโดยไม่มี TLS หากพวกเขาไม่เห็นด้วย ไม่ว่าจะด้วยเหตุผลใดก็ตาม

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

ทั้งสองฝ่ายในการเชื่อมต่อ TLS ใช้ใบรับรอง PKI ซึ่งสามารถใช้เพื่อเพิ่มระดับของความไว้วางใจว่าคู่สัญญาคือบุคคลที่พวกเขากล่าวว่าตนเป็นจริงๆ และตรวจสอบได้โดยอิสระผ่านทางtrust anchor อย่างไรก็ตาม เนื่องจากความง่ายในการรับใบรับรองจากผู้ให้บริการเช่น LetsEncrypt ทำให้มีความน่าเชื่อถือน้อยลง

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

แล้ว MTA-STS ล่ะ?

• MTA-STS จัดการกับความเสี่ยงนี้โดย (และสมมติว่าคุณไม่ได้อยู่ในโหมด 'ทดสอบ') กำหนดโดยปริยายว่าต้องสร้างการเชื่อมต่อ TLS สำหรับการแลกเปลี่ยนอีเมล

• DANE บังคับใช้ข้อกำหนดโดยปริยายสำหรับการเชื่อมต่อ TLS และเพื่อลดความเสี่ยงนี้

• TLS ที่ฉวยโอกาสอาศัยการเชื่อมต่อที่ไม่ได้เข้ารหัสเพื่อสร้างความเป็นไปได้ในการอัปเกรดเป็น TLS ดังนั้นจึงเสี่ยงต่อการถูกโจมตีของ MITM
• ทั้ง DANE และ MTA-STS จำเป็นต้องมีการเชื่อมต่อ TLS โดยปริยายก่อนที่จะมีการแลกเปลี่ยนอีเมล เพื่อให้มั่นใจว่ามีการสร้างการเชื่อมต่อ TLS ขั้นพื้นฐานเป็นอย่างน้อย
• TLS เพียงอย่างเดียวไม่เพียงพอที่จะแนะนำว่าการเชื่อมต่อมีความปลอดภัย/เข้ารหัสเพียงพอ โปรโตคอลและชุดการเข้ารหัสจำนวนมากที่ใช้งานภายใน TLS ถือว่าไม่ปลอดภัย นี่เป็นหัวข้อทั้งหมดในตัวเองซึ่งเราจะกล่าวถึงในบทความถัดไป

นี่เป็นขั้นตอนในกระบวนการสร้างการเชื่อมต่อที่ปลอดภัยระหว่างเมลเซิร์ฟเวอร์ อย่างไรก็ตามในมุมมองของฉัน มันเป็นองค์ประกอบสำคัญที่สมควรได้รับในส่วนของมันเอง

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

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

แล้วเดนล่ะ?

• การตรวจสอบความถูกต้องของใบรับรองเซิร์ฟเวอร์กับระเบียน TLSA ที่ปลอดภัยของ DNSSEC นั้นมีอยู่ใน DANE และเป็นการยืนยันขั้นสุดท้ายในการอนุมัติเพื่อรับรองการเชื่อมต่อ

• MTA-STS ไม่ได้ไปไกลถึงเพียงนี้ จุดประสงค์มุ่งเน้นไปที่การรับประกันว่าการเชื่อมต่อ TLS เป็นสิ่งที่จำเป็น และไม่รวมถึงการตรวจสอบสิทธิ์ของเซิร์ฟเวอร์อีเมล

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

MTA-STS ให้การปรับปรุงที่สำคัญบางประการเกี่ยวกับปัญหาของ TLS ที่ฉวยโอกาส แต่ยังไม่สามารถแก้ไขจุดอ่อนทั้งหมดได้ การเพิ่ม DNSSEC ใน MTA-STS จะช่วยลดความเสี่ยงบางอย่างและเป็นคำแนะนำของฉัน (หาก DANE ไม่ใช่ตัวเลือกสำหรับคุณ)

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

มีการจดทะเบียนชื่อโดเมนประมาณ 365 ล้านชื่อทั่วโลก และมีเพียง 3.7 ล้านโดเมนเท่านั้นที่นำ DANE ไปใช้ (ประมาณ 1%)

หากเราดูที่ผู้ให้บริการอีเมลรายใหญ่ที่สุด เราทราบว่า Gmail ได้ใช้งาน MTA-STS แล้ว แต่ยังไม่ได้ใช้งาน DANE หรือแม้แต่ DNSSEC

ในทำนองเดียวกัน Microsoft ได้ปรับใช้ MTA-STS กับ Exchange Online ในปีนี้และได้ประกาศความตั้งใจที่จะให้บริการ DANE ในอนาคต แต่น่าจะใช้เวลาอีกสองสามปีก่อนที่พวกเขาจะรองรับทั้งขาออกและขาเข้า