RFC 3207 – Tiện ích mở rộng SMTP STARTTLS

Proposed Standard Transport Security Obsoletes RFC 2487 Published March 2026

ELI5: Hãy tưởng tượng bạn đang trò chuyện trong một căn phòng đông đúc. Bất cứ ai cũng có thể lắng nghe. STARTTLS giống như nói "chúng ta hãy bước vào một căn phòng riêng tư" giữa cuộc trò chuyện. Bạn bắt đầu phiên SMTP bằng văn bản thuần túy, sau đó cả hai bên đồng ý chuyển sang liên lạc được mã hóa trước khi trao đổi bất kỳ nội dung nhạy cảm nào. Sau đó, không ai có thể nghe lén email đang được chuyển giao.

Tại sao RFC này tồn tại

Khi SMTP được thiết kế vào năm 1982, mã hóa không được xem xét. Các tin nhắn di chuyển qua internet dưới dạng văn bản thuần túy, và bất kỳ ai có quyền truy cập vào đường dẫn mạng đều có thể đọc được chúng. Khi internet trở nên nguy hiểm hơn, mã hóa email trong quá trình truyền tải trở nên cần thiết.

RFC 3207 xác định phần mở rộng STARTTLS cho SMTP, cho phép nâng cấp kết nối SMTP văn bản thuần túy thành kết nối TLS được mã hóa. Được công bố vào năm 2002, nó thay thế RFC 2487 bằng những làm rõ về các cân nhắc bảo mật và hành vi máy chủ.

STARTTLS là cơ chế chiếm ưu thế để mã hóa lưu lượng email máy chủ-đến-máy chủ (MTA-đến-MTA) trên cổng 25. Để gửi từ máy khách-đến-máy chủ, RFC 8314 hiện khuyên dùng TLS ngầm trên cổng 465, nhưng STARTTLS trên cổng 587 vẫn được sử dụng rộng rãi.

Cách hoạt động

STARTTLS hoạt động như một phần mở rộng SMTP, được thương lượng trong quá trình trao đổi EHLO:

Máy khách kết nối với máy chủ trên cổng 25 (hoặc 587) dưới dạng văn bản thuần túy.
Máy khách gửi EHLO. Máy chủ phản hồi với các khả năng của nó, bao gồm 250-STARTTLS nếu nó hỗ trợ mã hóa.
Máy khách gửi STARTTLS.
Máy chủ phản hồi với 220 Ready to start TLS.
Cả hai bên thực hiện bắt tay TLS, thiết lập một kênh được mã hóa.
Máy khách gửi EHLO mới qua kết nối được mã hóa. Danh sách khả năng của máy chủ có thể thay đổi (ví dụ: AUTH hiện được quảng cáo).
Phiên SMTP tiếp tục bình thường, nhưng tất cả lưu lượng hiện được mã hóa.

Ví dụ SMTP

Thương lượng STARTTLS trong quá trình chuyển máy chủ-đến-máy chủ:

# Kết nối văn bản thuần túy được thiết lập trên cổng 25 S: 220 mx.example.com ESMTP C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-STARTTLS S: 250 ENHANCEDSTATUSCODES # Máy khách thấy STARTTLS có sẵn, yêu cầu nâng cấp C: STARTTLS S: 220 2.0.0 Ready to start TLS # --- Bắt tay TLS xảy ra ở đây --- # Tất cả lưu lượng tiếp theo được mã hóa # Máy khách PHẢI phát hành lại EHLO sau TLS C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-AUTH PLAIN LOGIN S: 250 ENHANCEDSTATUSCODES # Lưu ý: STARTTLS không còn được quảng cáo (đã hoạt động) # Lưu ý: AUTH hiện được quảng cáo (chỉ có sẵn sau TLS) C: MAIL FROM:<alice@sender.example.net> S: 250 2.1.0 OK C: RCPT TO:<bob@example.com> S: 250 2.1.5 OK C: DATA S: 354 Start mail input C: [nội dung tin nhắn...] C: . S: 250 2.0.0 OK

Chi tiết kỹ thuật chính

TLS cơ hội vs. Bắt buộc

Hạn chế quan trọng của STARTTLS như được xác định trong RFC 3207 là nó cơ hội theo mặc định:

TLS cơ hội: Máy khách cố gắng STARTTLS nếu máy chủ quảng cáo nó, nhưng quay lại văn bản thuần túy nếu nó không khả dụng hoặc nếu bắt tay TLS không thành công. Đây là hành vi mặc định cho các kết nối MTA-đến-MTA.
TLS bắt buộc: Máy khách từ chối gửi tin nhắn trừ khi TLS có thể được thiết lập. Điều này có thể được cấu hình cho mỗi miền hoặc được thực thi bằng cách sử dụng MTA-STS (RFC 8461) hoặc DANE (RFC 7672).

TLS cơ hội dễ bị cuộc tấn công giảm thiểu: một kẻ tấn công mạng có thể loại bỏ khả năng STARTTLS khỏi phản hồi EHLO, buộc kết nối ở trạng thái văn bản thuần túy. Máy khách không có cách nào để biết máy chủ hỗ trợ TLS vì thương lượng ban đầu diễn ra dưới dạng văn bản thuần túy.

Xác minh chứng chỉ

RFC 3207 không yêu cầu xác minh chứng chỉ nghiêm ngặt cho các kết nối MTA-đến-MTA. Trong thực tế, nhiều máy chủ sử dụng chứng chỉ tự ký hoặc chứng chỉ không phù hợp với tên máy chủ MX. Lý do: mã hóa cơ hội mà không cần xác minh vẫn tốt hơn không có mã hóa nào cả. Nó bảo vệ chống lại giám sát thụ động ngay cả khi nó không ngăn chặn các cuộc tấn công trung gian hoạt động.

Để có những bảo đảm mạnh mẽ hơn, hãy sử dụng:

DANE (RFC 7672) — xuất bản chứng chỉ TLS của máy chủ trong DNS thông qua các bản ghi TLSA, được bảo mật bởi DNSSEC.
MTA-STS (RFC 8461) — xuất bản một chính sách yêu cầu TLS với xác minh chứng chỉ, được lưu vào bộ đệm bởi các máy chủ gửi.

Re-EHLO sau STARTTLS

Sau khi bắt tay TLS hoàn tất, máy khách PHẢI phát hành một lệnh EHLO mới. Danh sách khả năng của máy chủ từ trước TLS phải bị loại bỏ. Điều này rất quan trọng vì:

Máy chủ có thể quảng cáo các khả năng khác nhau sau khi mã hóa được thiết lập (ví dụ: AUTH).
Máy chủ không nên quảng cáo STARTTLS vì mã hóa đã hoạt động.
Kẻ tấn công có thể đã sửa đổi phản hồi EHLO trước TLS.

STARTTLS trên các cổng khác nhau

Cổng	Giao thức	Hành vi TLS
25	Chuyển tiếp SMTP	STARTTLS (cơ hội cho MTA-đến-MTA)
587	Gửi	STARTTLS (thực tế bắt buộc — AUTH yêu cầu nó)
465	Gửi	TLS ngầm (bắt tay TLS trước bất kỳ lệnh SMTP nào)

Báo cáo TLS

RFC 8460 xác định Báo cáo TLS SMTP (TLSRPT), cho phép chủ sở hữu miền nhận các báo cáo về lỗi kết nối TLS. Đây là tương đương STARTTLS của các báo cáo tổng hợp DMARC — nó cho bạn biết khi nào các kết nối với máy chủ của bạn không thành công trong thương lượng TLS.

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Những sai lầm phổ biến

Giả định STARTTLS có nghĩa là tin nhắn được mã hóa end-to-end. STARTTLS chỉ mã hóa kết nối giữa hai máy chủ liền kề. Nếu một tin nhắn đi qua nhiều lần nhảy, mỗi lần nhảy sẽ thương lượng TLS độc lập. Một tin nhắn có thể được mã hóa cho một lần nhảy và văn bản thuần túy cho lần nhảy tiếp theo.
Không phát hành lại EHLO sau STARTTLS. Không gửi EHLO mới sau bắt tay TLS là vi phạm giao thức. Bạn sẽ làm việc với dữ liệu khả năng cũ và có thể bỏ lỡ các tính năng mới khả dụng như AUTH.
Coi sự cố STARTTLS là lỗi vĩnh viễn. Nếu thương lượng STARTTLS không thành công, kết nối ở trạng thái không xác định. Đóng kết nối và bắt đầu kết nối mới. Không cố gắng tiếp tục với văn bản thuần túy trên cùng một kết nối.
Quảng cáo STARTTLS nhưng sử dụng chứng chỉ hết hạn hoặc cấu hình sai. Mặc dù nhiều máy khách sẽ tiếp tục bất chấp lỗi chứng chỉ, một số máy khách ngày càng nghiêm ngặt (và các chính sách MTA-STS/DANE) sẽ từ chối. Giữ cho chứng chỉ TLS của bạn hợp lệ và được cấu hình đúng.
Chỉ dựa vào STARTTLS để bảo mật. Vì STARTTLS cơ hội và dễ bị tấn công giảm thiểu, nó nên được bổ sung với MTA-STS hoặc DANE cho các miền nơi mã hóa rất quan trọng.
Quên STARTTLS trên cổng 587. Để gửi, máy khách luôn nên STARTTLS trước khi xác thực. Gửi thông tin xác thực AUTH dưới dạng văn bản thuần túy sẽ làm lộ mật khẩu SMTP của bạn cho bất kỳ ai giám sát kết nối.

Tác động khả năng giao hàng

Google và các nhà cung cấp lớn đánh dấu thư không được mã hóa. Gmail hiển thị biểu tượng khóa mở màu đỏ cho các tin nhắn nhận được mà không có mã hóa TLS. Điều này báo hiệu cho người nhận rằng tin nhắn có thể đã bị chặn trong quá trình vận chuyển, giảm niềm tin.
Áp dụng TLS gần như phổ biến. Kể từ năm 2025, hơn 95% email được gửi đến Gmail được mã hóa bằng TLS. Không hỗ trợ STARTTLS trên cơ sở hạ tầng gửi của bạn khiến bạn trở thành một ngoại lệ và có thể ảnh hưởng tiêu cực đến danh tiếng người gửi của bạn.
Thực thi MTA-STS đang phát triển. Các nhà cung cấp lớn xuất bản các chính sách MTA-STS yêu cầu TLS với xác minh chứng chỉ. Nếu máy chủ gửi của bạn không thể thương lượng thành công TLS bằng chứng chỉ hợp lệ, việc giao hàng đến các miền này sẽ không thành công.
Báo cáo TLS lộ ra vấn đề. Nếu bạn xuất bản bản ghi TLSRPT và máy chủ của bạn gặp vấn đề TLS, bạn sẽ nhận được báo cáo. Nếu bạn không xuất bản TLSRPT, bạn đang bay mù về lỗi kết nối.
Yêu cầu tuân thủ. HIPAA, GDPR, PCI-DSS và các quy định khác ngày càng yêu cầu mã hóa trong quá trình truyền tải cho email. STARTTLS là cơ chế cơ sở đáp ứng yêu cầu này cho email máy chủ-đến-máy chủ.