Tại sao chuyển email giữa các máy chủ thư thường không được mã hóa?

Người dùng thường có thể chọn nếu họ muốn truy cập nhà cung cấp email của mình (như Gmail) bằng kênh bảo mật (ví dụ: sử dụng HTTPS).

Tuy nhiên, theo sự hiểu biết tốt nhất của tôi, khi nói đến giao tiếp giữa máy chủ đến máy chủ, hầu hết các email vẫn được chuyển bằng văn bản thuần túy và không được mã hóa, cho phép mọi người trên mạng có thể đọc nội dung của họ.

Có công nghệ nào cung cấp cho người dùng một số đảm bảo rằng email của anh ta được gửi an toàn từ đầu đến cuối không? Tại sao không cho người dùng biết khi mã hóa không được hỗ trợ và để anh ta chọn nếu anh ta muốn email của mình vẫn được gửi?

Tuy nhiên, theo sự hiểu biết tốt nhất của tôi, khi nói đến giao tiếp giữa máy chủ đến máy chủ, hầu hết các email vẫn được chuyển bằng văn bản thuần túy và không được mã hóa, cho phép mọi người trên mạng có thể đọc nội dung của họ.

Chính xác. SMTP, giống như HTTP, là văn bản đơn giản theo mặc định.

Ngày nay, nhiều máy chủ thư hỗ trợ TLS (trước đây gọi là SSL) cho SMTP. (Điều này bao gồm Gmail.) Tuy nhiên, nó có cùng các vấn đề như với HTTP [S]: chứng chỉ được cấp bởi các CA nổi tiếng phải trả tiền và những người tự ký là vô giá trị ¹ để bảo vệ chống lại các cuộc tấn công của MitM . Nếu máy chủ thư của bạn xác thực nghiêm ngặt chứng chỉ của người nhận (giống như trình duyệt web), thì có thể không gửi được thư đến các máy chủ đang sử dụng chứng chỉ tự ký hoặc CA nội bộ. Nếu không , thì không thể chắc chắn rằng nó đang nói chuyện với đúng máy chủ chứ không phải kẻ mạo danh .

Ngoài ra, TLS là một bổ sung tương đối gần đây của SMTP, vì vậy ngay cả khi máy chủ thư của người nhận hỗ trợ TLS, người gửi có thể không hoặc có thể bị tắt theo mặc định.

¹ (Trừ khi máy chủ gửi hỗ trợ Dane (TLSA) và quản trị viên của máy chủ nhận quan tâm để xuất bản các bản ghi TLSA trong DNS. Điều này hiếm khi được thực hiện và hơi tẻ nhạt.)

Có công nghệ nào cung cấp cho người dùng một số đảm bảo rằng email của anh ta được gửi an toàn từ đầu đến cuối không?

Hai tiêu chuẩn bảo mật email phổ biến nhất:

• OpenPGP , dựa trên web tin cậy và miễn phí sử dụng. Việc triển khai mã nguồn mở là GnuPG ( cho Windows , cho Thunderbird ) và PGP ban đầu đã phát triển thành PGP Desktop thương mại .

  Đối với các ứng dụng email khách dựa trên web, FireGPG là một khả năng - chết tiệt

• S / MIME , dựa trên cơ sở hạ tầng X.509. Được thực hiện bởi hầu hết các máy khách để bàn (bao gồm Outlook, Thunderbird, Mail.app). Tuy nhiên, tương đối không phổ biến do cấu trúc dựa trên thẩm quyền tương tự như TLS / SSL: chứng chỉ đã ký có chi phí và những người tự ký có thể được xác nhận một cách đáng tin cậy.

Trong cả hai trường hợp, mã hóa yêu cầu người nhận phải đang sử dụng hệ thống và đã tạo / thu được khóa. (Để ký , cặp khóa của người gửi được sử dụng. Cách làm thông thường là cả ký và mã hóa tin nhắn.)

Tại sao không cho người dùng biết khi mã hóa không được hỗ trợ và để anh ta chọn nếu anh ta muốn email của mình vẫn được gửi?

Thông thường các tin nhắn được gửi được xếp hàng và cả người dùng và MTA đều không thể biết liệu bước nhảy tiếp theo có hỗ trợ TLS hay không - cho đến khi tin nhắn được gửi , tại thời điểm đó không có cách nào đáng tin cậy để yêu cầu người dùng xác nhận. (Chúng có thể là AFK, ngoại tuyến, ngủ hoặc kịch bản / chương trình. Nếu tôi đã gửi tin nhắn, tôi muốn nó được gửi càng sớm càng tốt.)

Bên cạnh đó, với SMTP bạn không bao giờ biết liệu bước nhảy tiếp theo là cuối cùng hay liệu nó sẽ chỉ chuyển tiếp thư ở một nơi khác. Không có gì lạ khi một MX dự phòng nằm trên một mạng hoàn toàn khác.

Vì thế. bảo mật đầu cuối chỉ có thể khi cả hai bên đang sử dụng OpenPGP hoặc S / MIME.

Lưu lượng email thực tế thường được mã hóa (TLS) nhưng có một số vấn đề khác:

• Một số ứng dụng webmail hiển thị tin nhắn HTML có thể không an toàn mặc dù chúng sử dụng HTTPS, chẳng hạn như không có sự phân tách cứng giữa mã và dữ liệu trong HTML (các yếu tố trực quan và javascript -> tấn công tiêm chích)

  • webmail cũng giữ email trên máy chủ thay vì tải xuống và lưu trữ nó vào máy tính cục bộ

• Bạn không có cách nào để biết liệu TLS / SSL đã được sử dụng giữa mỗi bước hay chưa, các máy chủ rất nhỏ KHÔNG CÓ chứng chỉ phù hợp

  • người gửi ít nhất có thể chỉ định chấp nhận hay không gửi email bằng kênh không an toàn

• Email nằm trên máy chủ không được mã hóa hoặc mã hóa bởi máy chủ

  • bạn sẽ phải tin tưởng MỌI máy chủ giữa bạn và người nhận

• Email có thể được chuyển bằng bất kỳ tuyến nào, bạn không thể chỉ định máy chủ nào bạn tin tưởng (phạm vi địa chỉ ip, ASes, quốc gia, tên miền ..)

• Các máy chủ email lớn không sử dụng nhiều chứng chỉ khác nhau và không thay đổi chúng thường xuyên đủ (?)

  • nó có thể có giá trị / có thể để vũ phu họ (như Hoa Kỳ / Vương quốc Anh, v.v. đã thử chưa?)

• bằng cách theo dõi lưu lượng truy cập, họ biết khi email được gửi và một cái gì đó về người nhận (máy chủ nào giao tiếp với nhau)

  • bóng tối che giấu những mối tương quan

• triển khai openssl là / là một mớ hỗn độn

  • có thể có lỗi

• bạn phải tin tưởng vào cơ quan cấp chứng chỉ ký chứng chỉ

Họ đang. Hoặc họ rất thường xuyên.

Hoặc thông qua SSL, hoặc TLS .

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

Hoặc nếu bạn thực sự hoang tưởng thì có PGP hoặc GPG.