← RFC Reference

RFC 8314: Văn bản thường được coi là lỗi thời

Tại Sao Điều Này Tồn Tại

Email trong lịch sử đã sử dụng ba cổng cleartext cho giao tiếp client-to-server:

Cả bốn đều bắt đầu dưới dạng kết nối cleartext. STARTTLS được bổ sung để nâng cấp những kết nối này thành TLS mid-stream. Nhưng STARTTLS có những điểm yếu hệ thống:

• Tấn công hạ cấp. Kẻ tấn công có thể xóa khả năng STARTTLS khỏi phản hồi của máy chủ, và nhiều client sẽ im lặng quay lại cleartext.
• Tiêm lệnh trước TLS. Giai đoạn cleartext trước khi STARTTLS hoàn tất cho phép kẻ tấn công tiêm các lệnh SMTP mà máy chủ xử lý sau khi bắt tay TLS.
• Lộ lọ thông tin xác thực. Nếu STARTTLS thất bại hoặc bị xóa, client có thể gửi thông tin xác thực AUTH (tên người dùng và mật khẩu) dưới dạng cleartext.

RFC 8314 tuyên bố những kết nối cleartext này lỗi thời cho việc gửi email và truy cập hộp thư, và bắt buộc sử dụng TLS ẩn làm giải pháp thay thế.

Cách Hoạt Động

TLS Ẩn so với STARTTLS

STARTTLS (cách cũ): Kết nối trên cổng cleartext, trao đổi lời chào dưới dạng văn bản thuần, gửi lệnh STARTTLS, thương lượng TLS, rồi tiếp tục với phiên được mã hóa.

-- STARTTLS trên cổng 587 (submission) --
220 mail.example.com ESMTP          ← lời chào cleartext
EHLO client.example.com             ← cleartext
250-mail.example.com                ← cleartext
250-STARTTLS                        ← kẻ tấn công có thể xóa dòng này
250 OK
STARTTLS                            ← cleartext
220 Go ahead                        ← cleartext
-- Bắt tay TLS xảy ra ở đây --
EHLO client.example.com             ← giờ đã được mã hóa
AUTH PLAIN dXNlcjpwYXNz            ← được mã hóa (an toàn)

TLS Ẩn (cách RFC 8314): Kết nối với cổng TLS chuyên dụng. Bắt tay TLS là điều đầu tiên xảy ra. Không có giai đoạn cleartext nào cả.

-- TLS Ẩn trên cổng 465 (submissions) --
-- Bắt tay TLS xảy ra ngay khi kết nối --
220 mail.example.com ESMTP          ← được mã hóa từ byte đầu tiên
EHLO client.example.com             ← được mã hóa
AUTH PLAIN dXNlcjpwYXNz            ← được mã hóa

Gán Cổng Mới

Cổng 465 có lịch sử phức tạp. Ban đầu nó được gán cho "SMTPS" vào cuối những năm 1990, sau đó bị thu hồi để ưu tiên STARTTLS trên 587. RFC 8314 gán lại nó thành submissions (lưu ý dấu 's') cho gửi TLS ẩn. Lần này nó chính thức và vĩnh viễn.

Cổng 25 Thì Sao?

Cổng 25 dành cho chuyển tiếp server-to-server, không phải gửi client. RFC 8314 không thay đổi hành vi của cổng 25. SMTP server-to-server vẫn sử dụng STARTTLS cơ hội, với MTA-STS hoặc DANE cung cấp thực thi. Sự phân biệt này quan trọng: client xác thực bằng thông tin xác thực (phải được bảo vệ), trong khi máy chủ xác thực qua DNS, DKIM và SPF.

Chi Tiết Kỹ Thuật Chính

Yêu Cầu Phiên Bản TLS

RFC 8314 yêu cầu TLS 1.2 trở lên. TLS 1.0 và 1.1 bị gỗ hóa bởi RFC 8996. Trong thực tế, bạn nên yêu cầu tối thiểu TLS 1.2 và ưu tiên TLS 1.3.

Xác Thực Chứng Chỉ

Với TLS ẩn, client phải xác thực chứng chỉ máy chủ so với tên máy chủ dự kiến bằng cách sử dụng các quy tắc Web PKI tiêu chuẩn. Đây là một thay đổi đáng kể so với thời kỳ STARTTLS khi nhiều client chấp nhận bất kỳ chứng chỉ nào. Chứng chỉ phải:

• Được cấp bởi Cơ Quan Cấp Chứng Chỉ đáng tin cậy.
• Khớp với tên máy chủ (tên client kết nối, không nhất thiết là tên máy chủ MX).
• Không hết hạn hoặc bị thu hồi.

Bản Ghi SRV cho Khám Phá Dịch Vụ

RFC 8314 hoạt động cùng với RFC 6186 để tự động cấu hình client thông qua bản ghi SRV:

Cấu Hình Client

Đối với các nhà phát triển ứng dụng tích hợp gửi SMTP:

# Ví dụ Python: TLS ẩn trên cổng 465
import smtplib

# Đúng: SMTP_SSL kết nối với TLS ngay lập tức
with smtplib.SMTP_SSL('mail.example.com', 465) as smtp:
    smtp.login('user', 'password')
    smtp.send_message(msg)

# Tránh: STARTTLS trên cổng 587 (cũ)
# with smtplib.SMTP('mail.example.com', 587) as smtp:
#     smtp.starttls()
#     smtp.login('user', 'password')

Sai Lầm Phổ Biến

• Nhầm lẫn cổng 465 với cổng 25. Cổng 465 dành cho gửi client với TLS ẩn. Cổng 25 dành cho chuyển tiếp server-to-server. Không bao giờ sử dụng cổng 465 cho gửi MX.
• Vẫn cung cấp cleartext trên cổng 587 mà không thực thi STARTTLS. Nếu bạn phải hỗ trợ cổng 587, yêu cầu STARTTLS trước AUTH. Không bao giờ cho phép thông tin xác thực qua kết nối cleartext.
• Vô hiệu hóa xác minh chứng chỉ. TLS ẩn yêu cầu xác thực chứng chỉ thích hợp. Đặt verify=False hoặc tương tự sẽ làm mất đi mục đích hoàn toàn. Hãy sửa chứng chỉ thay thế.
• Sử dụng TLS 1.0 hoặc 1.1. Những phiên bản này bị gỗ hóa chính thức. Cấu hình máy chủ của bạn để chỉ chấp nhận TLS 1.2+ trở lên.
• Coi cổng 465 như "SMTPS" (phiên bản những năm 1990). SMTPS cũ đã bị thu hồi. Cổng 465 hiện là submissions theo RFC 8314 — hành vi cơ bản giống nhau (TLS ẩn), nhưng được chuẩn hóa chính thức với đăng ký IANA thích hợp.
• Không xuất bản bản ghi SRV. Không có bản ghi SRV _submissions._tcp, client không thể tự động khám phá điểm cuối TLS ẩn của bạn. Nhiều bản vẫn mặc định STARTTLS trên 587.

Tác Động Khả Năng Gửi

• Bảo vệ thông tin xác thực của người gửi. Đối với các ứng dụng sử dụng gửi SMTP (ứng dụng của bạn kết nối với Mailer To Go, chẳng hạn), TLS ẩn trên cổng 465 đảm bảo thông tin xác thực API của bạn không bao giờ đi qua mạng dưới dạng cleartext — thậm chí không phải một cách ngắn gọn trong khi nâng cấp STARTTLS.
• Thiết lập kết nối nhanh hơn. TLS ẩn tiết kiệm một round-trip so với STARTTLS (không có trao đổi EHLO cleartext + STARTTLS). Đối với những người gửi khối lượng cao, điều này cộng lại.
• Yêu cầu của các nhà cung cấp chính. Google Workspace và Microsoft 365 đều hỗ trợ TLS ẩn trên cổng 465. Đây là phương pháp gửi được khuyến nghị cho các tích hợp mới.
• Loại bỏ một loại tấn công. Tấn công xóa STARTTLS, tiêm lệnh và sniffing thông tin xác thực đều không thể xảy ra với TLS ẩn. Đối với các môi trường nhạy cảm về tuân thủ, điều này quan trọng.

Related RFCs