it-swarm-vi.com

Những bước nào làm Gmail, Yahoo! Mail và Hotmail dùng để ngăn chặn việc nghe lén email?

Tôi muốn hỏi điều gì xảy ra khi một email được gửi từ các dịch vụ email công cộng gmail, yahoo hoặc hotmail?

Tôi không hiểu chi tiết các giao thức email, nhưng theo tôi biết lưu lượng email không được mã hóa và các thư được truyền dọc theo nhiều máy chủ thư (bằng văn bản thuần túy) trước khi đến máy chủ đích của chúng. Tuy nhiên, điều này đã bị người khác nghi ngờ gần đây và quan điểm của họ là nếu một trong những nhà cung cấp lớn được sử dụng, các thông điệp email sẽ được mã hóa và không cần phải lo lắng về bảo mật.

Bạn có biết họ có đúng về điều này không và email có an toàn vừa phải không? Cảm ơn bạn!

34
luben

Một phiên SMTP giữa hai máy chủ thư may được mã hóa, nhưng chỉ nếu cả hai đầu đều hỗ trợ nó và if cả hai đầu chọn sử dụng nó. Vì vậy, nếu bạn đang gửi thư từ Gmail đến example.net, thì Google chỉ có thể mã hóa nếu example.net đã sẵn sàng và sẵn sàng. Vì lý do này, bạn không thể tin tưởng email sẽ được bảo mật vừa phải ở lớp vận chuyển. (Phương pháp đầu cuối an toàn duy nhất là mã hóa email của bạn bằng S/MIME hoặc PGP, nhưng những người bạn đang trao đổi email cũng cần phải ở trên tàu ... giống như các máy chủ thư).

Về việc ba ông lớn có thực hiện STARTTLS cơ hội hay không, tôi chưa thấy bằng chứng nào về việc này, nhưng tôi dành ít thời gian hơn để đọc nhật ký máy chủ thư của mình so với trước đây. Và nếu có, họ vẫn chỉ là một nửa của mọi kết nối SMTP họ thực hiện và không thể đảm bảo việc sử dụng mã hóa.

Cập nhật:

Tôi chỉ banner các máy chủ MX đã thử nghiệm cho gmail.com, yahoo.com và hotmail.com. Chỉ gmail quảng cáo STARTTLS, nghĩa là, chỉ gmail mới sẵn sàng mã hóa phiên SMTP nếu bên kia muốn.

Tôi đã kiểm tra gmail gửi đi bằng cách gửi thư đến máy chủ mà tôi sở hữu và xem dây; Google thực sự tận dụng lợi thế của STARTTLS nếu nó được cung cấp và mã hóa giao dịch SMTP khi người dùng gmail đang gửi thư. Đạo cụ cho Google.

Cho đến khi "gửi" mã hóa email đi: Google 1, Yahoo 0, Microsoft 0.


Theo các bình luận bên dưới, nếu bạn muốn tự mình kiểm tra những điều này, thì rất đơn giản:

  1. Xác định máy chủ MX (Mail eXchangers) cho miền
  2. Telnet đến cổng 25 trên một trong số họ
  3. Nhập "ehlo yourhostname.domain.com"
  4. Nếu bạn không xem "250-STARTTLS" là một trong những câu trả lời, họ không hỗ trợ mã hóa cơ hội.

Như thế này:

$ Host -t mx yahoo.com
yahoo.com mail is handled by 1 mta5.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta7.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta6.am0.yahoodns.net.
$ telnet mta5.am0.yahoodns.net 25
Trying 66.196.118.35...
Connected to mta5.am0.yahoodns.net.
Escape character is '^]'.
220 mta1315.mail.bf1.yahoo.com ESMTP YSmtpProxy service ready
ehlo myhost.linode.com
250-mta1315.mail.bf1.yahoo.com
250-8BITMIME
250-SIZE 41943040
250 PIPELINING
quit
221 mta1315.mail.bf1.yahoo.com
Connection closed by foreign Host.
$

Là một lưu ý phụ, Yahoo sẽ đóng kết nối nếu bạn không ehlo ngay lập tức. Tôi đã phải cắt và dán ehlo của mình vì gõ nó mất quá nhiều thời gian.

CẬP NHẬT THÊM:

Kể từ tháng 1 năm 2014, Yahoo hiện đang mã hóa - tôi mới thử nghiệm (như trên) và xác minh. Tuy nhiên, cả Đăng kýThế giới máy tính đang báo cáo rằng các nội dung của thiết lập SSL (như Bảo mật Chuyển tiếp Hoàn hảo) để lại rất nhiều mong muốn như được thực hiện bởi Yahoo.

NGAY CẬP NHẬT MORER:

Google hiện bao gồm dữ liệu mã hóa SMTP trong phần Email báo cáo minh bạch an toàn hơn . Họ đang chia sẻ dữ liệu của họ về những người khác sẵn sàng mã hóa và bạn có thể xem các số hàng đầu cũng như truy vấn các tên miền riêng lẻ.

Phụ lục:

@SlashNetwork chỉ ra rằng có thể định cấu hình máy chủ thư thành yêu cầu rằng TLS phải được đàm phán trước khi trao đổi thư. Điều này đúng, nhưng để trích dẫn Tài liệu Postfix :

Bạn có thể THỰC HIỆN việc sử dụng TLS, để máy chủ Postfix SMTP thông báo STARTTLS và không chấp nhận thư mà không cần mã hóa TLS, bằng cách đặt "smtpd_tls_security_level = mã hóa". Theo RFC 2487, điều này KHÔNG PHẢI được áp dụng trong trường hợp máy chủ Postfix SMTP được tham chiếu công khai. Tùy chọn này được tắt theo mặc định và chỉ hiếm khi được sử dụng.

Bây giờ, thế giới có đầy đủ các triển khai vi phạm RFC, nhưng loại điều này - ví dụ, một thứ có thể phá vỡ chức năng cần thiết thông thường như chấp nhận trả lại và gửi thư cho bưu điện - có thể có nhiều hậu quả tiêu cực.

Một giải pháp tốt hơn mà các cổng thư thường cho phép là áp đặt yêu cầu TLS trên cơ sở chính sách cho mỗi tên miền . Ví dụ: thường có thể nói "Yêu cầu TLS với Chứng chỉ hợp lệ được ký bởi Entrust khi nói chuyện với example.com". Điều này thường được thực hiện giữa các tổ chức là một phần của cùng một công ty mẹ nhưng có cơ sở hạ tầng khác nhau (nghĩ: mua lại) hoặc các tổ chức có mối quan hệ kinh doanh (nghĩ: ACME, Inc., và công ty trung tâm hỗ trợ thuê ngoài của họ). Điều này có lợi thế là đảm bảo rằng các tập hợp con cụ thể của thư mà bạn quan tâm được mã hóa, nhưng không phá vỡ kiến ​​trúc mở (chấp nhận từ bất kỳ ai theo mặc định) của email SMTP.

Phụ lục ++

Google đã công bố gmail sẽ tô màu thông tin về bảo mật nếu đường dẫn thư đến người đọc . Vì vậy, các bước mã hóa hậu trường này sẽ được đưa đến thông báo của người dùng thêm một chút nữa.

(Có lẽ vẫn không quan tâm đến xuất xứ chứng chỉ; chỉ là một chỉ số mã hóa bit).

53
gowenfawr

Có ba điểm trong chuỗi bạn cần xem xét: Vận chuyển giữa các máy chủ thư (ví dụ: giữa Google và example.org), vận chuyển giữa máy chủ thư và máy khách và chính máy chủ thư.

Lưu lượng giữa các máy chủ thư có thể hoặc không thể được mã hóa; bạn không nên dựa vào nó và AFAIK, không có cách nào để thực thi nó từ máy khách.

Lưu lượng giữa máy khách và máy chủ thư có thể hoặc không thể được mã hóa; nếu bạn kết nối qua SSL (thông qua giao diện web hoặc SMTP), phần cuối của chuỗi của bạn được bảo mật, nhưng bạn không thể nói bất cứ điều gì về người nhận. Ngược lại, nếu bạn là người nhận, bạn có thể tìm nạp thư một cách an toàn, nhưng nếu người gửi (hoặc bất kỳ ai trong CC/BCC) không làm như vậy, thì đó là sự rò rỉ của bạn.

Và cuối cùng, có các máy chủ mail. Nếu ai đó xâm nhập vào họ hoặc các kỹ sư xã hội theo cách của họ và máy chủ thư lưu trữ nội dung không được mã hóa, thì một lần nữa bạn sẽ không gặp may.

TL; DR: Trừ khi bạn kiểm soát toàn bộ chuỗi (cả máy khách và tất cả các máy chủ thư có liên quan), thực tế không bao giờ như vậy, cách duy nhất để gửi email với bảo mật đáng tin cậy là mã hóa và giải mã cục bộ, sử dụng cái gì đó như PGP.

11
tdammers

Có hai câu hỏi khác nhau ở đây:

  1. Hệ thống email có cho phép email được gửi tới kênh qua kênh được mã hóa và gửi email dọc theo kênh được mã hóa khi máy chủ thư của người nhận hỗ trợ hay không.
  2. Hệ thống email có mã hóa nội dung của hộp thư khi hiển thị cho chủ sở hữu không.

địa chỉ áo choàng (1) tốt.

Gmail mã hóa qua mặc định cho (2) vì vậy khi xem thư của bạn, theo mặc định, nó được thực hiện qua HTTPS, do đó, một kẻ rình mò sẽ không thể quan sát gmail gửi thư đến trình duyệt của bạn. Tôi tin rằng những người khác chưa theo bộ. (Tiết lộ đầy đủ, tôi làm việc cho Google).

Gmail được đặt để sử dụng cài đặt 'Luôn sử dụng https' theo mặc định, ...

"Làm cho thư trên web của bạn an toàn hơn" có hướng dẫn để tránh đọc văn bản đơn giản của hộp thư cho một số nhà cung cấp dịch vụ webmail lớn, nhưng tôi không thể đảm bảo rằng nó được cập nhật.

10
Mike Samuel

Bạn có thể tự kiểm tra bằng cách sử dụng các trang web được đề cập tại Kiểm tra cấu hình STARTTLS của máy chủ SMTP . Hãy chắc chắn để kiểm tra cả nhận và gửi.

2
MrBrian