ทำความเข้าใจอีเมล: มันทำงานอย่างไรเบื้องหลัง

ก่อนอื่น คุณใช้ Mail User Agent (MUA) เพื่ออ่านและส่งอีเมลจากอุปกรณ์ (เช่น Gmail หรือ Mail app บนอุปกรณ์ Apple) โปรแกรมเหล่านี้ทำงานเฉพาะตอนคุณใช้อยู่

โดยทั่วไป พวกมันสื่อสารกับ Mail Transfer Agent (MTA) หรือที่รู้จักว่า mail server, MX host, และ mail exchanger ซึ่งทำหน้าที่รับและจัดเก็บอีเมลของคุณ

อีเมลถูกจัดเก็บระยะไกลจนกว่าคุณจะเปิด MUA เพื่อเช็คเมล อีเมลถูกส่งมอบโดย Mail Delivery Agents (MDA) ซึ่งมักรวมอยู่กับ MTA

อีเมลเคยส่งไป mail server โดยใช้ SMTP (Simple Mail Transfer Protocol) SMTP เป็นโปรโตคอลการสื่อสารสำหรับอีเมล

ถึงตอนนี้ ระบบเฉพาะตัวอย่าง Microsoft Exchange และ webmail อย่าง Gmail ใช้โปรโตคอลของตัวเองภายใน แต่ใช้ SMTP ส่งข้อความนอกระบบ (เช่น user Gmail ส่งไป Outlook client)

เมลจะถูกดาวน์โหลดจากเซิร์ฟเวอร์ด้วย Post Office Protocol (POP3) POP3 เป็น application-layer protocol ให้การเข้าถึงผ่าน IP network สำหรับ user application ติดต่อ mailbox บน mail server สามารถ connect, retrieve messages, จัดเก็บบนคอมพิวเตอร์ client และลบหรือเก็บบนเซิร์ฟเวอร์

ออกแบบมาเพื่อจัดการ temporary internet connections อย่าง dial-up (connect และ retrieve อีเมลตอนเชื่อมต่อ และอ่านข้อความตอนออฟไลน์) นิยมตอน dial-up กว้างขวาง

ตอนนี้ IMAP (Internet Message Access Protocol) แทนที่ POP3 ไปแล้ว IMAP อนุญาตหลาย clients จัดการ mailbox เดียวกัน (อ่านอีเมลจาก desktop, laptop, โทรศัพท์ ฯล฿ ข้อความทั้งหมดอยู่ที่นั่น จัดระเบียบเหมือนกัน)

สุดท้าย Webmail แทนที่ทั้งคู่ Webmail ให้ login เว็บไซต์รับข้อความจากที่ไหนก็ได้ อุปกรณ์ไหนก็ได้ (ยินดี!) แต่ต้องเชื่อมอินเทอร์เน็ตขณะใช้ ถ้าเว็บไซต์ (อย่าง Gmail) เป็น MUA ของคุณ ไม่ต้องรู้ SMTP หรือ IMAP server settings

อีเมลได้รับการรักษาความปลอดภัยอย่างไร?

น่าเสียดาย ความปลอดภัยไม่ได้สร้างเข้าไปใน mail protocols ตั้งแต่ต้น (เหมือน protocol อินเทอร์เน็ตต้นๆ) เซิร์ฟเวอร์คาดหวังรับข้อความจากใครก็ได้ และส่งต่อไปเซิร์ฟเวอร์อื่นที่ช่วย route ไปยังปลายทาง (recipient ใน to: field)

ไม่น่าแปลกที่เมื่ออินเทอร์เน็ตขยายจากไม่กี่กลุ่มรัฐบาล/วิจัย สู่สิ่งที่โลกส่วนใหญ่ใช้ทำทุกอย่าง Spam และ phishing emails กลายเป็น (และคงค้างเป็น) ปัญหาใหญ่

ตอบสนอง เราพยายาม implement มาตรการหลายอย่าง ป้องกันไม่ให้คนอ่านข้อความอื่น (encryption) และ validate ว่าข้อความมาจากผู้ส่งจริง (authentication)

ส่วนใหญ่ใช้ TLS (Transport Layer Security, ตัวแทน SSL) โปรโตคอลเข้ารหัสให้ encryption ในขณะส่ง (in transit) ปกป้องขณะส่ง แต่ไม่ใช่ข้อมูลที่พัก (at rest - เช่นจัดเก็บบนคอมพิวเตอร์)

มั่นใจว่าข้อความไม่ถูกแก้ไขหรือขโมยขณะเดินทาง MTA ไป MTA แต่ไม่ verify ว่าข้อความไม่ถูกแก้ไขระหว่างทาง

เช่น อีเมลผ่านหลาย mail servers ก่อนถึงปลายทาง TLS จะ ensure เข้ารหัสระหว่างเซิร์ฟเวอร์ แต่อย่างไรก็ตามแต่ละเซิร์ฟเวอร์อาจแก้ไขเนื้อหาได้ เพื่อแก้ปัญหานี้ สร้าง SPF, DKIM, และ DMARC

SPF (Sender Policy Framework)

SPF ให้เจ้าของโดเมน (เช่น google.com) ตั้ง TXT record ใน DNS ระบุว่าเซิร์ฟเวอร์ไหนได้ส่งเมลจากโดเมนนั้น (ดูวิธีทำสำหรับ hosting providers ต่างๆ ที่นี่)

ทำงานอย่างไร?

ระเบียนนี้รายการอุปกรณ์ (โดยปกติเป็น IP) ที่อนุญาต และลงท้ายด้วยตัวเลือก:

-all = ถ้า check fail (แหล่งอีเมลไม่ใช่อุปกรณ์ในรายการ) ผลคือ HardFail ระบบเมลส่วนใหญ่ mark ว่า spam

?all = ถ้า check fail ผลคือ neutral ใช้สำหรับ testing ไม่ใช่ production domains

~all = ถ้า check fail ผลคือ SoftFail หมายถึงข้อความน่าสงสัย แต่ไม่ใช่ known bad บางระบบ mark spam แต่ส่วนใหญ่ไม่

SPF headers ช่วยเซิร์ฟเวอร์ตอนประมวลผลเมล เช่น เซิร์ฟเวอร์ขอบเครือข่าย รู้ว่าเมลที่รับควรมาจากเซิร์ฟเวอร์ใน SPF record ของผู้ส่ง ช่วยเซิร์ฟเวอร์กำจัด spam เร็วขึ้น แต่น่าเสียดาย SPF มีปัญหาใหญ่หลายอย่าง:

1. SPF ไม่บอก mail server ว่าทำไงกับข้อความ - หมายถึงเมลล้มเหลว SPF check อาจส่งมอบได้
2. SPF record ไม่ดู 'from' address ที่ user เห็น ดู 'return-path' แทน - เทียบเท่าที่อยู่ส่งกลับบนจดหมาย บอก mail server ว่าส่งกลับไหน (เก็บใน email headers - ข้อมูลเทคนิคเซิร์ฟเวอร์ใช้ประมวลผลเมล) หมายถึงฉันใส่อะไรก็ได้ใน from: address ไม่กระทบ SPF check ทั้งสองอีเมล address สามารถ spoof ได้เพราะไม่มี encryption SPF headers ไว้วิ้วใจไม่ได้เต็มที่
3. SPF records ต้อง update ตลอดเวลา ยากในองค์กรใหญ่ที่เปลี่ยนแปลง
4. Forwarding ทำลาย SPF เพราะถ้าอีเมลจาก google.com ถูก forward โดย bob@bobsburgers.com envelope sender ไม่เปลี่ยน (from ยังว่า google.com) เซิร์ฟเวอร์รับคิดว่าเดินทางมาจาก google.com แต่มาจาก bobsburgers.com fail SPF check (แม้เมลมาจาก google.com จริง)

อ่านเพิ่มเกี่ยว SPF ที่นี่ เช็คว่า domain ไหนมี SPF และ DMARC records ที่นี่

DKIM (DomainKeys Identified Mail)

DKIM คล้าย SPF ใช้ TXT records ใน DNS ของ sending domain และให้ authentication บางส่วนของข้อความ พยายาม verify ว่าข้อความไม่ถูกแก้ไขระหว่างทาง

ทำงานอย่างไร?

Sending domain สร้าง public/private key pair ใส่ public key ใน DNS TXT record ของโดเมน (ถ้าไม่รู้ public/private key pair อ่านบทความ cryptography ที่นี่)

ต่อมา mail servers ของโดเมน (ขอบนอก - เซิร์ฟเวอร์ส่งเมลนอกโดเมน เช่น gmail.com ไป outlook.com) ใช้ private key สร้าง signature ของทั้ง message body รวม headers

การสร้าง signature มักต้อง hash และ encrypt ข้อความ (รายละเอียดกระบวนที่นี่)

Receiving mail servers ใช้ public key ใน DNS TXT record ถอดรหัส signature และ hash message และ headers ที่เกี่ยวข้อง (headers ที่สร้างขณะเมลอยู่ใน infrastructure ของผู้ส่ง - เช่นหลาย gmail servers ประมวลผลก่อนส่งออก outlook.com)

เซิร์ฟเวอร์ตรวจสอบว่า hash ทั้งสองตรงกัน ถ้าตรง ข้อความน่าจะไม่ถูกแก้ไข (เว้นแต่ private key ของผู้ส่งโดนแฮก) และมาจากผู้ส่งจริง ถ้าไม่ตรง ข้อความอาจไม่ใช่จากผู้ส่งที่อ้าง หรือถูกแก้ไขโดยเซิร์ฟเวอร์อื่นระหว่างทาง หรือทั้งคู่

DKIM ทำได้ดีมากที่งานเฉพาะ - ตอบคำถาม 'อีเมลนี้ถูกแก้ไขระหว่างทางหรือไม่ใช่จากผู้ส่งจริง?' แค่นั้น ไม่บอกจัดการยังไงกับเมลที่ fail test, เซิร์ฟเวอร์ไหนแก้ไข, หรือแก้ไขอะไร

DKIM ยังถูก ISPs บางแห่งใช้決定 domain reputation (ส่ง spam มาก? engagement ต่ำ? bounce บ่อย?)

อ่านเพิ่ม DKIM ที่นี่ Validate DKIM record ที่นี่

DMARC (Domain-Based Message Authentication, Reporting, and Conformance)

DMARC เป็นคำสั่งให้ mail servers จัดการ SPF และ DKIM records ไม่ทำ test เอง แต่บอก mail servers ว่าจัดการ checks ของ SPF และ DKIM อย่างไร

ISPs ที่ร่วมมือจะดู DMARC records ที่เผยแพร่ ใช้决定จัดการ DKIM หรือ SPF fails เช่น brand ที่ถูก spoof บ่อย อาจเผยแพร่ DMARC record บอกว่าถ้า DKIM หรือ SPF fail ให้ drop message

ISPs บ่อยครั้งส่งรายงานกิจกรรมโดเมนให้คุณ พร้อมแหล่งอีเมล และ pass/fail DKIM/SPF หมายถึงคุณจะรู้ตอนคน spoof (อ้างว่าส่งจาก) โดเมนคุณ หรือแก้ไขข้อความ

เพื่อ implement DMARC ต้องสร้าง DMARC record ตามความต้องการ (จาก monitor email traffic หา email sources ทั้งหมด จนถึงขอ action อย่าง reject emails ที่ fail DKIM หรือ SPF) เรียนรู้เพิ่มที่นี่และที่นี่

อ่านเพิ่ม DMARC ที่นี่ เช็ค domain ว่ามี SPF และ DMARC records ที่นี่

สรุป

มาตรการความปลอดภัยเหล่านี้ไม่มีอะไรสมบูรณ์ แต่ร่วมกันทำงานได้ดีพอที่ช่วยปรับปรุงความปลอดภัยระบบอีเมลทั่วโลก

ยิ่งองค์กรมากขึ้น adopt มาตรการเหล่านี้ (ใช้ open source หรือจ่ายซื้อผลิตภัณฑ์) ยิ่งทุกคนได้ประโยชน์ Security ที่เพิ่มหลัง protocol หรือผลิตภัณฑ์พัฒนาแล้ว มักมีค่าใช้จ่ายสูงกว่า น้อยผลกว่า และยากกว่า security ที่สร้างในผลิตภัณฑ์ตั้งแต่ต้น

แต่ protocol ส่วนใหญ่ที่อินเทอร์เน็ตปัจจุบันพึ่งพา ออกแบบสำหรับอินเทอร์เน็ตต้นๆ - กลุ่มเล็กๆ enthusiasts, นักวิทยาศาสตร์, ข้าราชการ - ไม่ใช่ network ทั่วโลกที่รันอาคาร, smart devices, ขนส่งสาธารณะ, โรงไฟฟ้านิวเคลียร์(!) ฯล฿

ดังนั้น เมื่ออินเทอร์เน็ตขยายต่อไป เราต้องปรับตัวและพัฒนาวิธีใหม่รักษาความปลอดภัยระบบที่เราพึ่งพา