← RFC Reference

RFC 5751: Thông số kỹ thuật Thư S/MIME 3.2

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

Bảo mật tầng vận chuyển (TLS, STARTTLS) bảo vệ email giữa các bước chuyển, nhưng nó có giới hạn:

• Người quản lý máy chủ có thể đọc email của bạn. TLS chấm dứt ở mỗi máy chủ. Máy chủ gửi, máy chủ nhận và bất kỳ trung gian nào đều thấy nội dung văn bản thuần.
• Không đảm bảo nguồn gốc. DKIM chứng minh một miền đã xử lý tin nhắn, nhưng không chứng minh người nào tạo ra nó.
• Không phát hiện được sự giả mạo sau khi gửi. Khi một tin nhắn được lưu trữ trên máy chủ, chữ ký DKIM có thể bị hỏng nếu tin nhắn được sửa đổi. Chữ ký S/MIME bảo vệ nội dung.

S/MIME cung cấp mã hóa đầu cuối (chỉ người nhận có thể giải mã) và chữ ký số (người nhận có thể xác minh danh tính của người gửi và nội dung không bị thay đổi). Nó sử dụng chứng chỉ X.509 từ cơ sở hạ tầng PKI tương tự bảo vệ HTTPS.

Cách Nó Hoạt Động

Hai Hoạt Động

S/MIME bao bọc các tin nhắn MIME chuẩn trong các phong bì mã hóa bằng CMS (Cryptographic Message Syntax):

Bạn có thể ký chỉ, mã hóa chỉ hoặc ký rồi mã hóa (tổ hợp phổ biến nhất).

Ký Một Tin Nhắn

Người gửi sử dụng khóa riêng của họ để tạo chữ ký số trên nội dung tin nhắn. Hai định dạng tồn tại:

• Ký mở (multipart/signed): Tin nhắn gốc có thể đọc được bởi bất kỳ máy khách nào. Chữ ký là một phần MIME riêng biệt. Các máy khách không phải S/MIME sẽ thấy tin nhắn bình thường và bỏ qua chữ ký.
• Ký không minh bạch (application/pkcs7-mime): Tin nhắn và chữ ký được gộp lại với nhau. Chỉ các máy khách S/MIME mới có thể trích xuất nội dung.

-- Cấu trúc tin nhắn ký mở --
Content-Type: multipart/signed;
  protocol="application/pkcs7-signature";
  micalg=sha-256; boundary="----sig"

------sig
Content-Type: text/plain

Đây là nội dung tin nhắn gốc.
Nó có thể đọc được bởi bất kỳ máy khách email nào.

------sig
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBgl...
(CMS SignedData được mã hóa base64)
------sig--

Mã Hóa Một Tin Nhắn

Người gửi mã hóa bằng khóa công khai của người nhận (từ chứng chỉ X.509 của họ). Chỉ khóa riêng tương ứng của người nhận có thể giải mã:

-- Cấu trúc tin nhắn được mã hóa --
Content-Type: application/pkcs7-mime;
  smime-type=enveloped-data;
  name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

MIAGCSqGSIb3DQEHA6CAMIA...
(CMS EnvelopedData được mã hóa base64)

Trong thực tế, S/MIME sử dụng mã hóa lai: một khóa đối xứng ngẫu nhiên (ví dụ: AES-128-CBC) mã hóa tin nhắn, và khóa công khai RSA/EC của người nhận mã hóa khóa đối xứng đó.

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

Yêu Cầu Chứng Chỉ

S/MIME dựa vào chứng chỉ X.509 được cấp bởi Cơ Quan Cấp Chứng Chỉ (CA). Chứng chỉ phải:

• Bao gồm địa chỉ email của người gửi trong Subject Alternative Name (SAN) hoặc trường Subject.
• Có emailProtection Extended Key Usage (EKU).
• Được cấp bởi CA mà máy khách của người nhận tin tưởng.

Đây là rào cản thực tế lớn nhất đối với việc áp dụng S/MIME: mỗi người gửi cần một chứng chỉ, và mỗi người nhận cần chứng chỉ công khai của người gửi để xác minh chữ ký hoặc gửi phản hồi được mã hóa.

Yêu Cầu Thuật Toán (S/MIME 3.2)

SHA-1 và 3DES vẫn được tham chiếu để tương thích ngược nhưng được coi là yếu. S/MIME 4.0 cập nhật các yêu cầu này một cách đáng kể.

Khám Phá Chứng Chỉ

Để mã hóa, người gửi cần chứng chỉ của người nhận. Phương pháp khám phá phổ biến:

• Thư từ trước: Trích xuất chứng chỉ từ tin nhắn đã ký mà người nhận gửi cho bạn.
• Thư mục LDAP: Nhiều tổ chức công bố chứng chỉ trong thư mục LDAP.
• DNS (SMIMEA/DANE): RFC 8162 định nghĩa khám phá chứng chỉ dựa trên DNS qua các bản ghi SMIMEA.
• Máy chủ khóa hoặc cổng: Cổng S/MIME doanh nghiệp quản lý chứng chỉ một cách tập trung.

Những Sai Lầm Phổ Biến

• Nhầm S/MIME với TLS. TLS bảo vệ kết nối giữa các máy chủ. S/MIME bảo vệ nội dung tin nhắn đầu cuối. Chúng giải quyết các vấn đề khác nhau và nên được sử dụng cùng nhau.
• Sử dụng SHA-1 cho chữ ký. SHA-1 bị hỏng về mặt mật mã để chống va chạm. Luôn sử dụng SHA-256 hoặc mạnh hơn.
• Mã hóa mà không ký. Tin nhắn được mã hóa nhưng không được ký không chứng minh gì về danh tính của người gửi. Luôn ký trước khi mã hóa để xác thực mã hóa.
• Quên phân phối chứng chỉ. Bạn không thể gửi email được mã hóa cho ai đó nếu bạn không có chứng chỉ công khai của họ. Lên kế hoạch trao đổi chứng chỉ trước khi triển khai S/MIME.
• Sử dụng chứng chỉ tự ký. Máy khách của người nhận sẽ hiển thị cảnh báo tin tưởng. Sử dụng chứng chỉ từ CA được công nhận để tương tác.
• Không xử lý người nhận hỗn hợp. Nếu một số người nhận có chứng chỉ S/MIME và những người khác thì không, bạn cần gửi tin nhắn hai lần: được mã hóa cho những người có chứng chỉ, trơn cho những người không.
• Phá vỡ DKIM bằng ký không minh bạch. Tin nhắn ký không minh bạch tái cấu trúc phần thân MIME, điều này có thể làm vô hiệu hóa hàm băm phần thân DKIM. Tin nhắn ký mở an toàn hơn để tương thích DKIM.

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

• Chữ ký S/MIME có thể cải thiện niềm tin. Một số cổng thư doanh nghiệp xác minh chữ ký S/MIME và xử lý các tin nhắn được ký tích cực hơn. Microsoft Outlook hiển thị nổi bật một dải tin tưởng cho chữ ký S/MIME hợp lệ.
• Nội dung được mã hóa không minh bạch đối với bộ lọc spam. Bộ lọc spam không thể kiểm tra phần thân tin nhắn được mã hóa. Một số bộ lọc có thể coi tin nhắn được mã hóa với sự nghi ngờ, trong khi những bộ lọc khác cho phép chúng đi qua. Để gửi email hàng loạt, mã hóa S/MIME thường không thực tế.
• Không phải là sự thay thế cho SPF/DKIM/DMARC. S/MIME hoạt động ở cấp người dùng; SPF, DKIM, và DMARC hoạt động ở cấp miền. Cả hai lớp phục vụ các mục đích khác nhau. S/MIME chứng minh danh tính cá nhân; DKIM chứng minh sự ủy quyền của miền.
• Tuân thủ doanh nghiệp. Các ngành được quy định (tài chính, chăm sóc sức khỏe, chính phủ) thường yêu cầu S/MIME. Hỗ trợ chữ ký S/MIME trên email giao dịch có thể là một điểm khác biệt cho người nhận nhạy cảm về tuân thủ.

Related RFCs