Tại sao SMTP qua SSL giữa các máy chủ email không phổ biến? [đóng cửa]


11

Theo hiểu biết của tôi, hầu hết các máy chủ email sử dụng SMTP / POP / IMAP qua SSL để mã hóa email.
Nó hỗ trợ mã hóa khi máy khách (UA) gửi email đến máy chủ (MTA) và UA nhận email từ MTA. Tuy nhiên, không nhiều MTA có thể mã hóa khi họ gửi email giữa MTA đến MTA.
(tôi hiểu thế có đúng không?)

ví dụ: alice@somewhere.com gửi email đến bob@anywhere.org
[Alice's PC] --- được mã hóa (SMTPS) ---> [nơi nào đó máy chủ] --- KHÔNG ĐƯỢC ENCRYPTED (SMTP) ---> [bất cứ nơi nào. máy chủ org] --- được mã hóa (POPS hoặc IMAPS) ---> [Bob's PC]

Nếu sự hiểu biết của tôi là chính xác, tại sao hầu hết các máy chủ email không hỗ trợ SMTP qua SSL giữa các máy chủ email?

Tôi phát triển giao diện tốt hơn (ít phức tạp hơn) để kích hoạt mã hóa email với PGP / GPG, nhưng ngày nay tôi nghĩ có thể sử dụng SMTPS tốt hơn vì PGP / GPG cần ký khóa thủ công để giữ độ tin cậy.


Điều này có liên quan gì đến mã hóa email? Mã hóa email có nghĩa với tôi rằng email được mã hóa theo cách riêng của nó ...
Uwe Plonus

?? Xin lỗi, tôi không hiểu ý của bạn ... Làm thế nào "email được tự mã hóa"? Theo hiểu biết của tôi, email có thể dễ dàng bị chặn nếu bạn gửi email dưới dạng văn bản thuần túy (không có mã hóa).
Jumpei Ogawa

1
Có, nhưng gửi email được mã hóa không liên quan gì đến mã hóa SSL / TLS của máy chủ SMTP.
Uwe Plonus

1
Để chắc chắn rằng bạn chỉ nhận thư trên một kênh được mã hóa trên máy chủ SMTP của bạn, bạn sẽ phải buộc sử dụng TLS. Vì vậy, nếu bên kia không hiểu / hỗ trợ TLS, bạn sẽ không nhận được thư của mình. Nếu bạn cho phép dự phòng giao tiếp không được mã hóa, bạn không đạt được gì. Đây là lý do tại sao mọi người thay vì chọn mã hóa chính thư đó và gửi nó qua một kênh không được mã hóa.
Der Hochstapler

Để làm rõ: "email được mã hóa" đề cập đến việc mã hóa nội dung bằng cách sử dụng một cái gì đó như PGP trước khi bạn gửi nó đến máy chủ thư đi. Điều đó có thêm lợi thế là giữ bí mật với bất kỳ ai điều hành MTA của bạn. Nó không đề cập đến việc mã hóa email giữa các MTA; mã hóa thường chỉ được áp dụng ở cuối, không phải ở giữa. Cũng lưu ý rằng giao tiếp giữa UA và MTA thường liên quan đến việc truyền một số dạng mật khẩu, dù sao cũng nên được mã hóa.
cpast

Câu trả lời:


4

Câu hỏi hay, tôi thực sự chưa thấy con số nào cho việc này. Tôi không chắc chắn, nhưng tôi nghĩ rằng nhiều công ty lớn hiện hỗ trợ SSL / TLS cho việc gửi thư trong và ngoài nước ("MX"). Điều này thường là tùy chọn và có thể được đàm phán qua StartTLS trên cổng 25. Hầu hết các máy chủ SMTP không yêu cầu máy chủ đến máy chủ TLS, tuy nhiên, điều đó có nghĩa là nhiều người sẽ không thể nhận thư từ MTA không hỗ trợ hoặc không được định cấu hình cho TLS.

Nhiều ứng dụng email hỗ trợ TLS giữa UA và MTA - có thể là SMTP / IMAP qua SSL hoặc POP3 qua SSL. Tôi nghĩ ví dụ gmail yêu cầu SSL / TLS cho IMAP và POP3.

Về mã hóa email từ đầu đến cuối thực tế, điều này thường đạt được bằng cách sử dụng S / MIME hoặc PGP. Tuy nhiên, do sự phức tạp trong việc thiết lập và quản lý nó, nó đã không được áp dụng trên diện rộng.


Cảm ơn bạn. Vì vậy, sự hiểu biết của tôi cho trạng thái hiện tại để mã hóa email. Bạn có nghĩa là SMTPS từ máy chủ đến máy chủ không được hỗ trợ trong nhiều máy chủ vì phần mềm máy chủ như postfix không hỗ trợ nó? Nếu hầu hết các máy chủ mail hỗ trợ nó, vấn đề sẽ được giải quyết? (Có lẽ tôi không hiểu chính xác câu trả lời của bạn ...)
Jumpei Ogawa

Ngay cả khi mã hóa được đàm phán, thường thì không có kiểm tra nghiêm ngặt các chứng chỉ được thực hiện bởi vì điều đó sẽ chặn tất cả các máy chủ đó bằng các certs tự ký. Nhưng không cần kiểm tra nghiêm ngặt một cuộc tấn công giữa chừng rất dễ dàng (chưa kể rằng MITM có thể ngăn chặn STARTTLS bằng cách can thiệp vào giai đoạn
xóa

RFC 2487 cấm các máy chủ thư công cộng yêu cầu TLS: "Máy chủ SMTP được tham chiếu công khai KHÔNG PHẢI yêu cầu sử dụng tiện ích mở rộng STARTTLS để gửi thư cục bộ. Quy tắc này ngăn tiện ích mở rộng STARTTLS làm hỏng khả năng tương tác của cơ sở hạ tầng SMTP của Internet."
ARX
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.