Chứng chỉ SSL nên chứa tên máy chủ nào cho máy chủ SMTP?

Tôi có một máy chủ foo.example.com tại 192.0.2.1

Nó chạy exim để nhận e-mail cho một số tên miền của tôi.

Mỗi tên miền của tôi đều có bản ghi MX trỏ đến mx.example.com, phân giải thành 192.0.2.1

Nếu tôi muốn thực hiện mã hóa TLS cung cấp exim cho các kết nối e-mail đến, tôi nên đặt tên máy chủ nào trong chứng chỉ SSL?

• foo.example.com bởi vì đó là những gì máy chủ sẽ nói trong Helo?
• mx.example.com vì đó là tên máy chủ mà khách hàng sẽ kết nối với?

http://www.checktls.com gợi ý rằng cái sau là đúng, nhưng tôi không thể tìm thấy câu trả lời dứt khoát.

Điều này thực sự không được xác định rõ ràng ở bất cứ đâu, và liệu máy chủ có nên được "tin cậy" hay không phụ thuộc vào máy khách (tất nhiên có thể là một máy chủ thư khác) kết nối với nó; trích dẫn từ RFC có liên quan ( RFC 2487 ):

Nếu ứng dụng khách SMTP quyết định rằng mức độ xác thực hoặc
quyền riêng tư không đủ cao để tiếp tục, thì nó NÊN đưa ra
lệnh SMTP QUIT ngay sau khi đàm phán TLS hoàn tất.
Nếu máy chủ SMTP quyết định mức độ xác thực hoặc
quyền riêng tư không đủ cao để tiếp tục, thì nó NÊN trả lời
mọi lệnh SMTP từ máy khách (trừ lệnh QUIT) bằng
mã trả lời 554 (với chuỗi văn bản có thể như vậy như "Lệnh
từ chối do thiếu an ninh").

Quyết định có hay không tin vào tính xác thực của
bên kia trong một cuộc đàm phán TLS là một vấn đề địa phương. Tuy nhiên, một số
quy tắc chung cho các quyết định là:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

Điều này về cơ bản có nghĩa là, khi máy chủ cung cấp mã hóa TLS bằng chứng chỉ đã cho, quyết định chấp nhận hoặc từ chối hoàn toàn phụ thuộc vào phần khác, có thể sẽ muốn tên trên chứng chỉ giống với tên mà nó được kết nối, nhưng có thể rất tốt chấp nhận nó ngay cả khi nó không phù hợp.

Nhưng xin chờ chút nữa. Trích dẫn lại từ cùng một RFC:

Sau khi hoàn thành bắt tay TLS, giao thức SMTP được đặt lại về
trạng thái ban đầu (trạng thái trong SMTP sau khi máy chủ đưa ra
lời chào sẵn sàng dịch vụ 220 ). Máy chủ PHẢI loại bỏ bất kỳ kiến ​​thức nào
thu được từ máy khách, chẳng hạn như đối số với lệnh EHLO,
không được lấy từ chính cuộc đàm phán TLS. Máy khách
PHẢI loại bỏ bất kỳ kiến ​​thức nào thu được từ máy chủ, chẳng hạn như danh sách
các phần mở rộng dịch vụ SMTP, không được lấy từ
chính cuộc đàm phán TLS . Máy khách NÊN gửi lệnh EHLO làm lệnh
đầu tiên sau khi đàm phán TLS thành công.

Vì vậy, những gì máy chủ đang nói để đáp lại Helo / EHLO trước khi bắt tay TLS dường như không thực sự quan trọng.

Theo kinh nghiệm của tôi, chứng chỉ tự ký hoạt động khá tốt trên các máy chủ thư đối mặt với Internet, điều đó có nghĩa là các máy chủ thư khác thậm chí không bận tâm đến việc xác thực chúng, họ sẽ vui vẻ chấp nhận mọi thứ có thể cung cấp mã hóa TLS, bất kể việc phát hành thẩm quyền hoặc tên chủ đề.

Một MTA chuyển thư đến miền của bạn sẽ tra cứu bản ghi MX (sẽ mang lại tên máy chủ), sau đó tra cứu bản ghi A cho tên máy chủ đó. Do đó, tên máy chủ mà nó đang kết nối là tên máy chủ MX và đó là tên sẽ được xác minh theo tên chung của chứng chỉ SSL. Xác minh tên máy chủ của Helo không có ý nghĩa vì máy chủ có thể cung cấp bất kỳ tên máy chủ nào của Helo mà nó muốn - nó không cung cấp bảo mật bổ sung.

Điều đó nói rằng, việc xác minh nghiêm ngặt các chứng chỉ SSL khi gửi thư hiện tại không đặc biệt hữu ích, vì các MTA sẽ (hầu như luôn luôn) chuyển sang phân phối không SSL, vì đó là cách mà SMTP hoạt động vào lúc này. Do đó, cấu hình hợp lý là sử dụng SSL nếu máy chủ MX cung cấp nó, bất kể chứng chỉ SSL có xác minh hay không (vì mã hóa mà không cần xác thực sẽ tốt hơn không mã hóa và không xác thực). Do đó, bạn cũng có thể sử dụng chứng chỉ tự ký cho mục đích này.

Nhiệm vụ xác minh chứng chỉ máy chủ và nó phù hợp với tên máy chủ của máy chủ hoàn toàn là vai trò của máy khách, đối với mọi giao thức sử dụng SSL / TLS.

Như vậy, tên máy chủ trong chứng chỉ phải khớp với tên mà máy khách đang cố truy cập.

Khi kết nối SSL / TLS được bắt đầu trước (SMTPS), máy chủ không có cách nào để xem thông báo của Helo nói gì trước khi kết nối được thiết lập, do đó, nó phải sử dụng kết nối mà nó đưa ra yêu cầu.

Khi sử dụng SSL / TLS sau đó STARTTLS, máy khách vẫn có ý định nói chuyện với máy chủ được cấu hình, vì vậy đó vẫn là những gì cần kiểm tra. Không thể thực hiện các cuộc tấn công MITM:

• C-> S: Xin chào, tôi là Alice, tôi muốn nói chuyện với Bob.
• S-> C: Xin chào, tôi là Chuck, đây là chứng chỉ của tôi dành cho Chuck.
• C-> S: Ồ vâng, chứng chỉ của bạn thực sự hợp lệ đối với Chuck. Hãy tiếp tục.
• ... Tất nhiên là có một lỗ hổng, vì Alice muốn liên lạc an toàn với Bob.

Trong cả hai trường hợp, đó là địa chỉ MX nên được sử dụng.

Các quy tắc khớp tên máy chủ gần đây đã được tập hợp trên các giao thức trong RFC 6125 , nhưng rất ít khách hàng thực hiện đầy đủ (đó là một RFC thực hành tốt nhất hơn là thay đổi hoàn toàn, và nó vẫn còn khá gần đây).

Trong phần phụ lục của nó , nó tóm tắt những gì đã tồn tại về SMTP trước đây (lấy từ RFC 3207 và RFC 4954 ). Cụ thể là " Máy khách KHÔNG được sử dụng bất kỳ hình thức nào của tên máy chủ được lấy từ nguồn từ xa không an toàn (ví dụ: tra cứu DNS không an toàn). " (Tất nhiên áp dụng cho biểu ngữ của máy chủ). Ngoài ra, các quy tắc di sản SMTP là nhiều hơn một chút nới lỏng hơn HTTPS về Subject Alternative Names ( nên thay vì phải được sử dụng).

Cách hiện đại chắc chắn là đặt tên máy chủ trong mục nhập DNS Tên chủ đề thay thế. Việc sử dụng ký tự đại diện cũng không được khuyến khích .

Tôi nghĩ rằng tốt nhất sẽ là sao chép những gì được thực hiện trong thực tế. Tôi đã kiểm tra một địa chỉ email yahoo.com bằng cách sử dụng http://checktls.com Hy vọng, tại yahoo, họ đã sử dụng một tên miền khác cho tên máy chủ của họ và cho tên miền mx của họ. Vì vậy, tên máy chủ của họ là một yahoo.com và tên miền mx của họ kết thúc bằng yahoodns.net

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

Kết quả kiểm tra: chứng chỉ SSL CN = tên miền MX (* .yahoodns.net)

Tôi đã làm như vậy với cisco và tôi đã có kết quả tương tự.

Để mã hóa SSL / TLS, khách hàng luôn kiểm tra sự tương ứng giữa tên máy chủ "thực" / "được khai báo" trên máy từ xa và thông tin có trong chứng nhận.

Vì vậy, có lẽ bạn nên đặt foo.example.com hoặc tạo chứng chỉ ký tự đại diện ;-)