← RFC Reference

Bảo mật TLS và Email

Cách TLS bảo vệ email trong quá trình truyền tải — STARTTLS, implicit TLS, MTA-STS, DANE, TLSRPT — và tại sao mã hóa cơ hội không đủ.

Vấn đề: SMTP Được Sinh Ra Không Mã Hóa

SMTP được thiết kế năm 1982 (RFC 821) như một giao thức văn bản thuần. Mọi lệnh, mọi phản hồi, mọi tiêu đề, mọi byte nội dung tin nhắn đều truyền trên mạng không mã hóa. Mật khẩu được gửi qua AUTH về cơ bản là được hét lên khắp phòng.

TLS (Transport Layer Security) được lớp phủ lên SMTP để khắc phục điều này. Nhưng không giống HTTPS — nơi TLS là bắt buộc và phổ biến — email TLS đã phát triển thông qua một loạt các thỏa hiệp không hoàn hảo mà ngày nay vẫn đang được giải quyết.

STARTTLS: Mã Hóa Cơ Hội

STARTTLS (RFC 3207) nâng cấp kết nối SMTP văn bản thuần hiện tại lên TLS. Quá trình:

Điểm chính về STARTTLS:

• Kết nối bắt đầu bằng văn bản thuần và nâng cấp giữa luồng. Các lệnh EHLO và STARTTLS ban đầu không được mã hóa.
• Sau khi STARTTLS hoàn thành, khách hàng phải gửi EHLO lại. Máy chủ có thể quảng cáo các khả năng khác nhau qua kết nối được mã hóa.
• STARTTLS được sử dụng trên cổng 25 (máy chủ với máy chủ) và cổng 587 (gửi khách hàng).
• STARTTLS trên cổng 25 là cơ hội theo mặc định: nếu máy chủ không quảng cáo STARTTLS, hoặc nếu bắt tay TLS thất bại, hầu hết các MTA gửi sẽ quay lại văn bản thuần và vẫn gửi tin nhắn.

Tấn công STARTTLS stripping

Vì STARTTLS bắt đầu bằng văn bản thuần, một kẻ tấn công trung gian có thể sửa đổi phản hồi EHLO của máy chủ để xóa quảng cáo STARTTLS. MTA gửi nghĩ rằng máy chủ không hỗ trợ TLS và tiếp tục bằng văn bản thuần. Kẻ tấn công có thể sau đó đọc và sửa đổi tin nhắn.

Đây không phải là một cuộc tấn công lý thuyết. Nó đã được quan sát trong tự nhiên, đặc biệt là ở các quốc gia thực hiện giám sát hàng loạt. STARTTLS cơ hội không cung cấp bảo vệ chống lại các kẻ tấn công chủ động — nó chỉ bảo vệ chống lại nghe lén thụ động.

Implicit TLS: Mã Hóa Từ Byte Đầu Tiên

RFC 8314 khuyến nghị implicit TLS cho gửi mail (khách hàng tới máy chủ). Thay vì bắt đầu bằng văn bản thuần và nâng cấp, kết nối là TLS từ byte đầu tiên.

• Cổng 465: Implicit TLS cho gửi tin nhắn. Khách hàng mở kết nối TLS ngay lập tức. Không có bước STARTTLS. Không có cơ hội stripping.
• Cổng 993: Implicit TLS cho IMAP.
• Cổng 995: Implicit TLS cho POP3.

RFC 8314 rõ ràng khai báo rằng gửi SMTP văn bản thuần trên cổng 587 không có TLS là lỗi thời, và implicit TLS trên cổng 465 là đường gửi ưa thích. Trên thực tế, cổng 587 với STARTTLS vẫn được triển khai rộng rãi, nhưng hướng rõ ràng: implicit TLS là tương lai.

Tuy nhiên, implicit TLS chỉ áp dụng cho đường dẫn gửi (khách hàng của bạn đến máy chủ của bạn). Gửi máy chủ với máy chủ trên cổng 25 vẫn sử dụng STARTTLS vì không có cơ chế được triển khai phổ biến để các máy chủ biết trước rằng MX của người nhận hỗ trợ implicit TLS. Đây là nơi MTA-STS và DANE phát huy tác dụng.

MTA-STS: Thực Thi TLS Dựa Trên Chính Sách

MTA-STS (RFC 8461) giải quyết vấn đề STARTTLS stripping bằng cách cho phép một miền xuất bản chính sách nói rằng "luôn yêu cầu TLS khi gửi mail đến các máy chủ MX của tôi." Chính sách được xuất bản qua HTTPS (không phải DNS), cung cấp xác thực riêng thông qua web PKI.

Cách MTA-STS hoạt động

1. Miền xuất bản bản ghi DNS TXT báo hiệu rằng chính sách MTA-STS tồn tại:

2. MTA gửi tìm nạp chính sách qua HTTPS từ URL được biết đến:

3. Tệp chính sách chỉ định chế độ và tên máy chủ MX hợp lệ:

4. MTA gửi lưu vào bộ nhớ đệm chính sách (trong max_age giây) và thực thi nó trên tất cả các kết nối trong tương lai. Nó sẽ:
   • Yêu cầu STARTTLS trên cổng 25 (không bao giờ quay lại văn bản thuần)
   • Xác thực chứng chỉ TLS của máy chủ so với tên máy chủ MX
   • Chỉ gửi tới các tên máy chủ MX được liệt kê trong chính sách

Các chế độ MTA-STS:

• enforce: Yêu cầu TLS và chứng chỉ hợp lệ. Thất bại gửi nếu không thể thiết lập TLS.
• testing: Cố gắng TLS nhưng gửi dù sao nếu nó thất bại. Gửi báo cáo lỗi qua TLSRPT.
• none: Không có chính sách. Được sử dụng để rõ ràng hủy bỏ chính sách trước đó.

MTA-STS có cùng mô hình tin cậy với web: nó dựa vào các Cơ quan cấp chứng chỉ. Nếu CA bị xâm phạm, kẻ tấn công có thể giả mạo chứng chỉ cho MX của bạn. DANE cung cấp mô hình tin cậy thay thế dựa trên DNSSEC.

DANE: Xác Minh Chứng Chỉ Dựa Trên DNS

DANE (RFC 7672) sử dụng các bản ghi TLSA được ký bằng DNSSEC để liên kết chứng chỉ TLS (hoặc khóa công khai của nó) trực tiếp với tên máy chủ MX. Điều này loại bỏ sự phụ thuộc vào các Cơ quan cấp chứng chỉ.

Các trường bản ghi TLSA:

• 3 (Mục Đích Chứng Chỉ) — Chứng chỉ do miền cấp (không cần CA)
• 1 (Bộ Chọn) — Khớp với khóa công khai chủ đề
• 1 (Loại Khớp) — Mã băm SHA-256 của khóa công khai
• a]b2c3d4e5f6... — Giá trị mã băm

Cách DANE hoạt động cho email

1. MTA gửi phân giải bản ghi MX và nhận mx1.example.com.
2. Nó truy vấn bản ghi TLSA tại _25._tcp.mx1.example.com.
3. Nếu tồn tại bản ghi TLSA được xác thực bằng DNSSEC, MTA biết:
   • TLS là bắt buộc (không quay lại văn bản thuần).
   • Chứng chỉ của máy chủ phải khớp với bản ghi TLSA.
4. MTA kết nối, thực hiện STARTTLS, và xác thực chứng chỉ của máy chủ so với bản ghi TLSA thay vì (hoặc ngoài) hệ thống CA.

Điểm mạnh của DANE: nó không phụ thuộc vào các Cơ quan cấp chứng chỉ. Điểm yếu của nó: nó yêu cầu DNSSEC, mà nhiều miền chưa triển khai. Không có DNSSEC, các bản ghi DANE không thể được tin tưởng (kẻ tấn công có thể thao tác DNS có thể thao tác bản ghi TLSA).

DANE vs. MTA-STS

Cả hai cơ chế có thể tồn tại. Một miền có thể xuất bản cả chính sách MTA-STS và DANE. Những người gửi hỗ trợ DANE sử dụng nó; những người không hỗ trợ có thể quay lại MTA-STS.

TLSRPT: Báo Cáo TLS

SMTP TLS Reporting (RFC 8460) cho phép một miền nhận báo cáo về các lỗi kết nối TLS từ các máy chủ gửi. Nó tương đương với báo cáo tổng hợp DMARC cho TLS.

Các MTA gửi hỗ trợ TLSRPT sẽ gửi báo cáo JSON hàng ngày chi tiết:

• Tổng số lần thử kết nối tới MX của bạn
• Các cuộc đàm phán TLS thành công
• Các cuộc đàm phán TLS thất bại (và tại sao: lỗi chứng chỉ, lỗi STARTTLS, vi phạm chính sách MTA-STS)
• Các kết nối quay lại văn bản thuần

TLSRPT rất cần thiết trong quá trình triển khai MTA-STS. Bắt đầu với mode: testing trong chính sách MTA-STS của bạn và giám sát báo cáo TLSRPT. Khi bạn thấy không có (hoặc có thể chấp nhận được) lỗi, chuyển sang mode: enforce.

Quản Lý Chứng Chỉ

TLS yêu cầu chứng chỉ, và quản lý chứng chỉ là một trong những điểm lỗi hoạt động phổ biến nhất trong bảo mật email.

Chứng chỉ cho máy chủ mail

• Chứng chỉ phải khớp với tên máy chủ MX. Nếu bản ghi MX của bạn trỏ đến mx1.example.com, chứng chỉ phải có hiệu lực cho mx1.example.com. Chứng chỉ cho example.com hoặc www.example.com sẽ không hoạt động.
• Sử dụng chứng chỉ từ CA công khai. Let's Encrypt hoạt động hoàn hảo cho máy chủ mail. Chứng chỉ tự ký sẽ gây ra lỗi xác thực TLS cho những người gửi kiểm tra (bao gồm bất kỳ ai sử dụng MTA-STS hoặc DANE).
• Tự động gia hạn. Hết hạn chứng chỉ là lỗi TLS phổ biến nhất. Sử dụng ACME (Let's Encrypt) hoặc tự động hóa của CA để đảm bảo chứng chỉ được gia hạn tốt trước khi hết hạn.
• Bao gồm tất cả tên máy chủ MX. Nếu bạn có nhiều máy chủ MX, mỗi máy chủ cần chứng chỉ hợp lệ cho tên máy chủ của nó. Chứng chỉ SAN (Tên Thay Thế Chủ Đề) có thể bao gồm nhiều tên máy chủ.

Lỗi chứng chỉ và ảnh hưởng của chúng

Bảng này tiết lộ vấn đề cốt lõi với TLS cơ hội: không có MTA-STS hoặc DANE, hầu hết lỗi chứng chỉ được bỏ qua im lặng. Kết nối được mã hóa, nhưng không được xác thực — bạn có thể đang mã hóa tin nhắn của mình cho máy chủ của kẻ tấn công.

Trạng Thái Mã Hóa Email

Mã hóa email tồn tại ở hai cấp, và chúng thường bị nhầm lẫn:

Mã hóa vận chuyển (TLS)

TLS mã hóa kết nối giữa các máy chủ. Nó bảo vệ chống lại nghe lén trong khi tin nhắn đang truyền giữa hai điểm bất kỳ. Khi tin nhắn đến máy chủ đích, nó được giải mã và lưu trữ bằng văn bản thuần (thường). TLS bảo vệ vận chuyển, không phải tin nhắn.

Mã hóa vận chuyển là từng bước: tin nhắn được mã hóa giữa máy chủ của bạn và máy chủ tiếp theo, sau đó được giải mã, sau đó được mã hóa lại cho bước tiếp theo. Mỗi máy chủ trung gian có quyền truy cập vào tin nhắn văn bản thuần.

Mã hóa end-to-end (S/MIME, PGP)

Mã hóa end-to-end (S/MIME theo RFC 8551, hoặc PGP/OpenPGP) mã hóa chính nội dung tin nhắn, để chỉ người nhận dự định có khóa riêng chính xác mới có thể giải mã nó. Tin nhắn vẫn được mã hóa khi lưu trữ trên máy chủ và trong mỗi bước vận chuyển.

Tỷ lệ áp dụng mã hóa end-to-end trong email vẫn cực kỳ thấp. Các lý do là thực tế:

• Quản lý khóa rất khó khăn. Cả người gửi và người nhận phải quản lý các khóa mã hóa. Không có thư mục khóa phổ quát.
• Khả năng sử dụng rất kém. Hầu hết các ứng dụng email làm cho mã hóa cumbersome. Người dùng trung bình không thể (và không cần phải) quản lý các khóa PGP.
• Các tính năng máy chủ bị hỏng. Nếu máy chủ không thể đọc tin nhắn, nó không thể lập chỉ mục, tìm kiếm, lọc thư rác, hoặc áp dụng quy tắc.
• Khả năng tương tác bị giới hạn. S/MIME và PGP không tương thích với nhau.

Đối với hầu hết email, TLS ở cấp vận chuyển là lớp mã hóa thực tế. Mã hóa end-to-end vẫn là kỳ lạ, được sử dụng trong các môi trường bảo mật cao nơi gánh nặng hoạt động được biện minh.

Yêu Cầu TLS (RFC 8689)

RFC 8689 định nghĩa cơ chế theo tin nhắn để yêu cầu TLS. Người gửi thêm phần mở rộng SMTP REQUIRETLS vào các tin nhắn riêng lẻ:

Khi REQUIRETLS được đặt:

• Máy chủ nhận phải sử dụng TLS để gửi hoặc chuyển tiếp tin nhắn. Nếu TLS không khả dụng tại bước tiếp theo, tin nhắn sẽ bị trả lại thay vì được gửi bằng văn bản thuần.
• Xác thực chứng chỉ TLS phải thành công.
• Tất cả các bước tiếp theo phải hỗ trợ và tuân thủ REQUIRETLS.

REQUIRETLS là ở mức tin nhắn — bạn có thể sử dụng nó cho các tin nhắn nhạy cảm mà không yêu cầu TLS cho tất cả mail. Tuy nhiên, tỷ lệ áp dụng vẫn còn hạn chế. Hầu hết các máy chủ chưa hỗ trợ nó.

Hướng Dẫn Triển Khai Thực Tế

Dưới đây là chuỗi được khuyến nghị để triển khai TLS cho email của miền bạn:

Bước 1: Đảm Bảo TLS Trên Máy Chủ MX Của Bạn

Lấy chứng chỉ hợp lệ từ CA công khai cho mỗi tên máy chủ MX. Tự động hóa gia hạn. Kiểm tra rằng STARTTLS hoạt động chính xác từ những người gửi bên ngoài.

Bước 2: Triển Khai TLSRPT

Xuất bản bản ghi TXT _smtp._tls để nhận báo cáo lỗi TLS. Bắt đầu giám sát trước khi bạn thực thi bất cứ điều gì.

Bước 3: Triển Khai MTA-STS Ở Chế Độ Kiểm Tra

Xuất bản bản ghi TXT DNS và tệp chính sách HTTPS với mode: testing. Giám sát báo cáo TLSRPT để tìm lỗi. Điều tra và khắc phục mọi sự cố.

Bước 4: Di Chuyển MTA-STS Sang Chế Độ Thực Thi

Khi báo cáo TLSRPT cho thấy kết quả sạch, thay đổi chế độ thành enforce. Tăng id trong bản ghi TXT DNS để báo hiệu thay đổi chính sách.

Bước 5: Xem Xét DANE (Nếu Bạn Sử Dụng DNSSEC)

Nếu miền của bạn được ký DNSSEC, xuất bản bản ghi TLSA cho các máy chủ MX của bạn. Điều này cung cấp một lớp pinning chứng chỉ bổ sung độc lập với hệ thống CA.

Điều Gì Có Thể Sai

Chứng chỉ hết hạn gây lỗi gửi

Chứng chỉ máy chủ MX của bạn hết hạn. Không có MTA-STS, hầu hết những người gửi bỏ qua lỗi và gửi dù sao (không an toàn nhưng có chức năng). Với MTA-STS ở chế độ enforce, những người gửi xác thực chứng chỉ sẽ hoãn gửi. Tin nhắn sắp xếp hàng đợi ở phía người gửi. Nếu bạn không khắc phục nó trong cửa sổ thử lại của người gửi (thường là 4–5 ngày), tin nhắn sẽ bị trả lại. Sửa chữa: tự động hóa gia hạn chứng chỉ với Let's Encrypt / ACME.

Chính sách MTA-STS không khớp sau khi thay đổi MX

Bạn thêm máy chủ MX mới (mx3.example.com) nhưng quên thêm nó vào tệp chính sách MTA-STS của bạn. Những người gửi đã lưu vào bộ nhớ đệm chính sách cũ từ chối kết nối với MX mới vì nó không nằm trong danh sách được phép của chính sách. Sửa chữa: luôn cập nhật tệp chính sách MTA-STS trước khi thêm bản ghi MX mới và tăng id chính sách trong DNS.

STARTTLS stripping không được phát hiện

Không có MTA-STS hoặc DANE, kẻ tấn công loại bỏ STARTTLS từ phản hồi EHLO của máy chủ. Tin nhắn được gửi bằng văn bản thuần. Cả người gửi cũng như người nhận đều không nhận biết. Sửa chữa: triển khai MTA-STS để làm cho STARTTLS stripping có thể phát hiện và ngăn chặn được.

Bản ghi TLSA DANE trở nên cũ

Bạn xoay vòng chứng chỉ TLS của bạn nhưng quên cập nhật bản ghi TLSA trong DNS. Những người gửi xác thực DANE thấy sự không khớp và từ chối gửi. Sửa chữa: luôn cập nhật bản ghi TLSA trước khi triển khai chứng chỉ mới. Sử dụng tự động hóa phối hợp triển khai chứng chỉ với cập nhật DNS.

Những Điểm Chính

• Opportunistic STARTTLS tốt hơn không có gì, nhưng không cung cấp bảo vệ chống lại các kẻ tấn công chủ động. Kẻ tấn công có thể sửa đổi lưu lượng mạng có thể loại bỏ TLS khỏi kết nối.
• MTA-STS ngăn chặn TLS stripping bằng cách xuất bản chính sách mà những người gửi lưu vào bộ nhớ đệm và thực thi. Nó dựa vào web PKI (Các Cơ quan cấp chứng chỉ).
• DANE ngăn chặn TLS stripping bằng cách xuất bản dữ liệu chứng chỉ trong các bản ghi DNS được ký bằng DNSSEC. Nó không phụ thuộc vào CA nhưng yêu cầu DNSSEC.
• Triển khai cả hai nếu có thể. MTA-STS có hỗ trợ người gửi rộng hơn; DANE mạnh hơn nhưng yêu cầu DNSSEC. Cùng nhau họ bao gồm hầu hết địa hạt.
• TLSRPT rất cần thiết để có khả năng hiển thị. Không có nó, bạn không biết lỗi TLS xảy ra bao lần cho email đến miền của bạn.
• Quản lý chứng chỉ là mối quan tâm hoạt động. Tự động hóa gia hạn. Khớp chứng chỉ với tên máy chủ MX. Phối hợp xoay vòng chứng chỉ với cập nhật TLSA DANE.
• TLS bảo vệ vận chuyển, không phải nội dung. Để mã hóa tin nhắn end-to-end, bạn cần S/MIME hoặc PGP — nhưng các rào cản khả năng sử dụng và áp dụng vẫn cao.
• Implicit TLS (cổng 465) là tương lai cho gửi. Để gửi máy chủ với máy chủ, STARTTLS với thực thi MTA-STS/DANE là thực tế tốt nhất hiện tại.

Đọc Thêm

Related RFCs