Việc thực thi mã hóa cho SMTP có phải là một ý tưởng tốt (chưa)?

Tôi đang chạy một máy chủ email hiện được thiết lập để sử dụng TLS nếu có thể, khi gửi và nhận email.

Khi bạn đọc trong tài liệu về điều này, cũng có tùy chọn để thực thi TLS và không chấp nhận truyền email văn bản đơn giản. Nó cũng cảnh báo bạn rằng một số máy chủ thư có thể chưa hỗ trợ mã hóa và việc thực thi mã hóa có thể chặn các máy chủ này.

Nhưng đây có còn là vấn đề người ta nên suy nghĩ hay có an toàn không khi nói rằng việc thực thi mã hóa sẽ không còn là vấn đề nữa?

Có thể có một số nhà cung cấp lớn đã làm điều này hoặc những gì bạn xem xét thực hành tốt nhất những ngày này?

Vấn đề thực tế là không phải mọi máy chủ tương thích với SMTP (RFC khá cũ) đều có thể nói TLS với máy chủ của bạn, vì vậy bạn có thể bỏ lỡ việc nhận một số thông báo email.

Vấn đề triết học với điều này là không thể biết được email được chuyển tiếp như thế nào sau (hoặc trước đó) đến máy chủ của bạn.

Điều này có nghĩa là email có thể đã được truyền bằng văn bản thuần thông qua chuyển tiếp.

Bất cứ ai nghiêm túc về việc bảo vệ nội dung email của họ nên thực sự mã hóa cơ thể. Với mã hóa trên đường đi, nó luôn luôn hợp lý, nó đã được truyền đi dưới dạng văn bản thuần túy.

Vì vậy, để trả lời câu hỏi của bạn khi thực thi mã hóa ở lớp SMTP có lẽ là vô nghĩa, làm tăng khả năng bạn bị thiếu email và không có khoản thanh toán có lợi được đảm bảo.

Chỉnh sửa: Điều này đề cập đến việc thực thi SMTP cho mục đích chuyển tiếp, không gửi email. Trong mã hóa đệ trình thư phải được thực thi do cuộc hội thoại SMTP (không phải email thực tế) có thể chứa thông tin xác thực.

Không

RFC 821 33 tuổi. Bạn sẽ tìm thấy các email được chuyển tiếp bởi các chương trình không hỗ trợ STARTTLS. Đôi khi, họ sẽ còn sơ khai người gửi email (ví dụ: tập lệnh nội bộ), đôi khi các hệ thống hoàn chỉnh đã cũ, đã tắt TLS / không được biên dịch trong các hệ thống mà không có đủ entropy.

Tôi đã chứng kiến ​​cách đây không lâu các email gửi đi không thành công vì đầu nhận đã được cấu hình để chỉ cho phép SMTP qua TLS. Đó là một vấn đề trong người gửi (không nên sử dụng cấu hình đó), nhưng cho thấy điều đó xảy ra.

Tôi sẽ chỉ hạn chế các tin nhắn đến từ các địa chỉ IP được cấu hình thủ công. Nếu bộ xử lý thẻ tín dụng của bạn không khởi động STARTTLS, có lẽ bạn muốn hủy kết nối (và trang quản trị viên cục bộ để anh ta có thể cảnh báo họ!) Hơn là nhận dữ liệu (có khả năng nhạy cảm) không được mã hóa. Đối với các tin nhắn gửi đi, nếu bạn đã kết nối với máy chủ đó bằng STARTTLS trước đó, bạn có thể không muốn làm điều đó một cách không an toàn nữa, thay vào đó coi đó là một sự thỏa hiệp tiềm năng. Bạn cũng có thể có một danh sách các máy chủ STARTTLS đã biết sử dụng, như gmail hoặc yahoo.

Có https://www.eff.org/starttls-everywhere dự án cung cấp danh sách các máy chủ smtp mà bạn có thể (nên?) Tự tin thực thi việc sử dụng starttls.

Việc từ chối email từ các đồng nghiệp không có khả năng mã hóa là hoàn toàn vô nghĩa.

Miễn là máy chủ của bạn được thiết lập để thực hiện mã hóa cơ hội với bất kỳ máy ngang hàng nào cung cấp nó, bạn sẽ có được cả hai thế giới tốt nhất: mã hóa khi có sẵn và gửi email qua bản rõ khi không có.

Miễn là có máy chủ không hỗ trợ mã hóa, bắt buộc đơn giản là họ không thể nói chuyện với bạn; Điều đó thật xấu. Một khi mọi người đều ủng hộ nó, không có sự khác biệt giữa mã hóa cơ hội và bắt buộc.

Và như những người khác đã chỉ ra, mã hóa trực tuyến và mã hóa đầu cuối là hai điều hoàn toàn khác nhau, giải quyết các mô hình mối đe dọa khác nhau. Đừng nhầm lẫn giữa hai.

Đây là một vấn đề chính sách.

Nói chung, khi TLS được thi hành cho trong và ngoài nước, nó được thực hiện cho một tập hợp các miền hạn chế được các bên thỏa thuận để đáp ứng nhu cầu (ví dụ: các đối tác kinh doanh có thể có thỏa thuận mã hóa tất cả thư giữa các công ty của họ).

Trừ khi có thỏa thuận như vậy, không được bật chế độ thực thi.

Không, đó là một ý tưởng rất xấu.

Trong thực tế, hóa ra, hầu hết các máy chủ / máy khách STARTTLS không thực hiện bất kỳ loại thuật toán thử lại nào nếu không có StartTLS nếu kết nối TLS không thể đàm phán.

Như vậy, ngay cả quảng cáo STARTTLS như một tùy chọn đã làm giảm cơ hội nhận (và gửi) email của bạn!

Chỉ cần tìm kiếm và bạn sẽ thấy nhiều người không thể gửi BẤT K email email nào đến các miền Microsoft Outlook được xử lý bởi cụm * .protection.outlook.com:

Tin nhắn Sendmail bị từ chối từ Microsoft khi sử dụng TLS

Lý do: Bắt tay 403 4.7.0 TLS không thành công

Để tóm tắt các vấn đề được trình bày trong hai bài viết trên:

• có thể gửi bất kỳ thư nào đến bất kỳ máy chủ nào ngoài những máy chủ được Outlook xử lý, có hoặc không có STARTTLS,
• có thể gửi thư mà không cần chứng chỉ ứng dụng khách và không có STARTTLS cho Outlook,
• hoặc với chứng chỉ ứng dụng khách có độ dài bằng không,
• nhưng không phải với chứng chỉ mà Microsoft không thích và khi gặp sự cố, các máy khách (tốt, máy chủ hoạt động ở chế độ máy khách) sẽ không gửi lại tin nhắn mà không có STARTTLS nếu máy chủ của người nhận quảng cáo STARTTLS!

Tương tự, khi máy chủ của bạn hoạt động như một máy chủ, một tình huống tương tự có thể xảy ra ngoài tầm kiểm soát của bạn nếu bạn quyết định bật STARTTLS - khi máy chủ của khách hàng thấy rằng máy chủ của bạn ở chế độ máy chủ cung cấp STARTTLS, họ sẽ cố gắng đàm phán TLS, nhưng nếu đàm phán không thành công , họ chỉ cần chờ đợi và thử lại các bước tương tự, tiếp tục thất bại cho đến khi tin nhắn phải được gửi lại cho người gửi!

Và điều này xảy ra khá thường xuyên với các miền khác nhau trong vùng đất STARTTLS!

Đáng buồn thay, trước đây tôi từng là một người ủng hộ STARTTLS, bây giờ tôi rất không biết rằng tôi đã bị lừa bởi quảng cáo không rủi ro về những gì tôi nghĩ là được mã hóa cơ hội.

Bạn không chỉ không nên yêu cầu STARTTLS, mà thậm chí có thể thận trọng để vô hiệu hóa nó hoàn toàn, nếu bạn muốn đảm bảo khả năng tương tác.

Tôi phải đồng ý về ý tưởng sử dụng TLS cơ hội. Mặc dù, tôi có một số để thêm vào ý tưởng là tốt. Một số có thể sẽ bị làm phiền bởi các đề xuất, tuy nhiên, vì các đề xuất của tôi ở đây không được đưa ra một cách nhẹ nhàng và không có sự cân nhắc thích đáng, trước khi đưa ra phán xét, tôi yêu cầu bạn vui lòng đọc toàn bộ thảo luận từ liên kết đính kèm.

Sử dụng TLS cơ hội là một giải pháp tốt nhất. Góc MITM như một lập luận chống lại nó là một cá trích đỏ. Rốt cuộc, như MH đã đề cập trong một bình luận, ngay cả một SMTP "hợp pháp" với kết nối TLS cũng có thể là MITM'd và người dùng cuối không phải là người khôn ngoan hơn do phần lớn các ứng dụng thư không bận tâm đến việc xác nhận chứng chỉ cùng với đại đa số trong số các MTA ngoài đó đang thực hiện TLS đang sử dụng chứng chỉ tự ký (ít nhất là nếu bạn không sử dụng DNSSEC và TLSA / Dane.) Do kết quả của điều này và có thể các yếu tố khác, thậm chí còn có thể tranh cãi rằng cho đến khi cả bạn và phần còn lại của thế giới đã triển khai Dane / TLSA và DNSSEC, rằng trong khi chạy TLS cơ hội, tốt hơn hết là không nên sử dụng diffie-hellman ẩn danh (đồng thời sử dụng PFS). Do ít nhất một phần nếu không chủ yếu là thực tế là nó vẫn sẽ mã hóa lưu lượng bảo vệ chống lại người quan sát thông thường. Để hỗ trợ thêm cho cấu hình này (với lời giải thích phức tạp hơn nhiều so với của tôi), vui lòng xem các bình luận của Viktor Dukhovni trong bài đăng này trong một diễn đàn postfix:http://postfix.1071664.n5.nabble.com/Diseac-Anonymous-Diffie-Hellman-td67965.html

Về lý do tại sao người ta có thể lấy các đề xuất của Viktor so với các đề xuất của người khác, anh ta đã viết mã TLS cũng như mã DNSSEC, mã TLSA / Dane cho MTA Postfix ngoài việc là người đã viết các bản nháp IETF trên cả DNSSEC và TLSA / Dane. Như vậy, tôi sẽ nói rằng những lời của anh ấy về vấn đề này có trọng lượng khá lớn, có lẽ nhiều hơn những gì hầu hết.

Hi vọng điêu nay co ich.

Từ góc độ tiếp thị qua email, việc sử dụng TLS là cách thực hành tốt và an toàn khi bạn biết rằng nó được thực hiện thông qua toàn bộ chuỗi phân phối. Tuy nhiên, nếu bảo mật là yêu cầu hàng đầu của bạn thì hãy mã hóa email trước khi gửi nó là tùy chọn an toàn nhất (ví dụ với PGP).