Trong Thunderbird (và tôi cũng giả sử ở nhiều khách hàng khác), tôi có tùy chọn để chọn giữa "SSL / TLS" và "STARTTLS".
Theo như tôi hiểu, "STARTTLS" có nghĩa đơn giản là "mã hóa nếu cả hai đầu đều hỗ trợ TLS, nếu không thì không mã hóa chuyển khoản" . Và "SSL / TLS" có nghĩa là những từ đơn giản "luôn mã hóa hoặc hoàn toàn không kết nối" . Điều này có đúng không?
Hay nói cách khác:
STARTTLS có kém an toàn hơn SSL / TLS không, vì nó có thể chuyển sang bản rõ mà không thông báo cho tôi?
Câu trả lời:
Câu trả lời, dựa trên STARTTLS RFC cho SMTP ( RFC 3207 ) là:
Thay vì tự nói chuyện, tôi sẽ cho phép RFC tự nói, với bốn bit có liên quan được tô sáng trong BÓNG :
Một cuộc tấn công trung gian có thể được khởi chạy bằng cách xóa phản hồi "250 STARTTLS" khỏi máy chủ. Điều này sẽ khiến khách hàng không cố gắng bắt đầu một phiên TLS. Một cuộc tấn công trung gian khác là cho phép máy chủ thông báo khả năng STARTTLS của mình, nhưng để thay đổi yêu cầu của khách hàng để bắt đầu TLS và phản hồi của máy chủ. Để bảo vệ chống lại các cuộc tấn công như vậy, cả máy khách và máy chủ PHẢI có thể được cấu hình để yêu cầu đàm phán TLS thành công một bộ mật mã thích hợp cho các máy chủ được chọn trước khi tin nhắn có thể được chuyển thành công. Tùy chọn bổ sung sử dụng TLS khi có thể NÊN cũng được cung cấp. Một triển khai CÓ THỂ cung cấp khả năng ghi lại rằng TLS đã được sử dụng trong giao tiếp với một máy ngang hàng nhất định và tạo cảnh báo nếu nó không được sử dụng trong phiên sau đó.
Nếu đàm phán TLS thất bại hoặc nếu khách hàng nhận được phản hồi 454, khách hàng phải quyết định làm gì tiếp theo. Có ba lựa chọn chính: tiếp tục với phần còn lại của phiên SMTP , [...]
Như bạn có thể thấy, chính RFC tuyên bố (không rõ ràng lắm, nhưng đủ rõ ràng) rằng KHÔNG CÓ yêu cầu khách hàng thiết lập kết nối an toàn và thông báo cho người dùng nếu kết nối an toàn không thành công. Nó rõ ràng cung cấp cho khách hàng tùy chọn để âm thầm thiết lập các kết nối văn bản thuần túy .
Không có sự khác biệt trong bảo mật giữa hai tùy chọn.
SSL / TLS mở kết nối SSL / TLS trước, sau đó bắt đầu giao dịch SMTP. Điều này phải xảy ra trên một cổng không có máy chủ SMTP không SSL / TLS đang chạy; không thể cấu hình một cổng duy nhất để xử lý cả văn bản thuần túy và kết nối được mã hóa do bản chất của các giao thức.
STARTTLS bắt đầu giao dịch SMTP và tìm kiếm hỗ trợ từ đầu kia cho TLS để đáp ứng với EHLO. Nếu khách hàng thấy STARTTLS trong danh sách lệnh được hỗ trợ, thì nó sẽ gửi STARTTLS và bắt đầu đàm phán để mã hóa. Tất cả điều này có thể (và thường xảy ra) xảy ra trên cổng SMTP tiêu chuẩn 25, một phần để tương thích ngược, nhưng cũng cho phép mã hóa cơ hội giữa các điểm cuối hỗ trợ cả hai nhưng không nhất thiết phải yêu cầu.
Nói chung, SSL / TLS chỉ được sử dụng giữa máy khách cuối và máy chủ. STARTTLS được sử dụng phổ biến hơn giữa các MTA để bảo đảm vận chuyển giữa các máy chủ.
Với hai triển khai đó, STARTTLS có thể được hiểu là không an toàn nếu người dùng hoặc quản trị viên cho rằng kết nối được mã hóa nhưng thực tế không được cấu hình để yêu cầu mã hóa. Tuy nhiên, mã hóa được sử dụng hoàn toàn giống với SSL / TLS và do đó, không ít nhiều dễ bị tổn thương trước một cuộc tấn công Man-in-the-Middle ngoài loại lỗi cấu hình này.
Đối với email nói riêng, vào tháng 1 năm 2018, RFC 8314 đã được phát hành, trong đó khuyến nghị rõ ràng rằng "TLS tiềm ẩn" được sử dụng để ưu tiên cho cơ chế STARTTLS cho các lần gửi IMAP, POP3 và SMTP.
Tóm lại, bản ghi nhớ này hiện khuyến nghị rằng:
- TLS phiên bản 1.2 trở lên được sử dụng cho tất cả lưu lượng giữa MUA và Máy chủ gửi thư và cả giữa Máy chủ MUA và Máy chủ truy cập thư.
- MUA và Nhà cung cấp dịch vụ thư (MSP) (a) không khuyến khích sử dụng các giao thức Cleartext để truy cập thư và gửi thư và (b) không sử dụng các giao thức Cleartext cho các mục đích này càng sớm càng tốt.
- Kết nối với Máy chủ gửi thư và Máy chủ truy cập thư được thực hiện bằng cách sử dụng "TLS tiềm ẩn" (như được định nghĩa dưới đây), để kết nối với cổng "Cleartext" và đàm phán TLS bằng lệnh STARTTLS hoặc lệnh tương tự.
(nhấn mạnh thêm)
Câu trả lời phụ thuộc vào một mức độ nào đó về ý nghĩa của "an toàn".
Đầu tiên, tóm tắt của bạn không nắm bắt được sự khác biệt giữa SSL / TLS và STARTTLS.
Nếu máy khách được cấu hình để yêu cầu TLS, hai cách tiếp cận ít nhiều an toàn như nhau. Nhưng có một số sự tinh tế về cách STARTTLS phải được sử dụng để làm cho nó an toàn và việc triển khai STARTTLS khó hơn một chút để có được những chi tiết đó đúng.
Mặt khác, nếu máy khách được cấu hình để chỉ sử dụng TLS khi TLS khả dụng và sử dụng Cleartext khi TLS không khả dụng, trước tiên khách hàng có thể làm gì để thử kết nối với cổng SSL được sử dụng bởi giao thức và nếu điều đó không thành công, sau đó kết nối với cổng Cleartext và thử sử dụng STARTTLS, và cuối cùng quay lại Cleartext nếu TLS không khả dụng trong cả hai trường hợp. Kẻ tấn công khá dễ dàng khiến kết nối cổng SSL bị lỗi (tất cả chỉ là một số gói TCP RST được định thời gian tốt hoặc chặn cổng SSL). Khó hơn một chút - nhưng chỉ một chút thôi - để kẻ tấn công đánh bại cuộc đàm phán STARTTLS và khiến lưu lượng truy cập ở trạng thái rõ ràng. Và sau đó, kẻ tấn công không chỉ được đọc email của bạn mà còn có thể chiếm được tên người dùng / mật khẩu của bạn để sử dụng trong tương lai.
Vì vậy, câu trả lời đơn giản là nếu bạn đang kết nối với máy chủ mà bạn đã biết hỗ trợ TLS (như trường hợp bạn đang gửi hoặc đọc email), bạn nên sử dụng SSL / TLS. Nếu kết nối bị tấn công, nỗ lực kết nối sẽ thất bại, nhưng mật khẩu và email của bạn sẽ không bị xâm phạm.
Mặt khác, nếu bạn đang kết nối với một số dịch vụ mà bạn không biết liệu nó có hỗ trợ TLS hay không, STARTTLS có thể tốt hơn một chút.
Khi STARTTLS được phát minh, các cuộc tấn công chỉ nghe "thụ động" là rất phổ biến, các cuộc tấn công "chủ động" trong đó kẻ tấn công sẽ tiêm lưu lượng để cố gắng bảo mật thấp hơn là ít phổ biến hơn. Trong khoảng 20 năm kể từ đó, các cuộc tấn công tích cực đã trở nên khả thi và phổ biến hơn.
Ví dụ: nếu bạn đang cố gắng sử dụng máy tính xách tay trong sân bay hoặc một nơi công cộng khác và cố gắng đọc thư của bạn qua wifi được cung cấp ở đó, bạn không biết mạng wifi đó đang làm gì với lưu lượng truy cập của mình. Rất phổ biến đối với các mạng wifi để định tuyến một số loại lưu lượng truy cập nhất định đến "proxy" xen kẽ giữa các ứng dụng khách của bạn và các máy chủ mà chúng đang cố gắng nói chuyện. Việc các proxy đó vô hiệu hóa cả STARTTLS và "thử một cổng rồi đến cổng khác" là một nỗ lực để khiến khách hàng của bạn quay trở lại với văn bản rõ ràng. Vâng, điều này xảy ra và đó chỉ là một ví dụ về cách lưu lượng truy cập của bạn có thể được theo dõi bởi một mạng. Và các cuộc tấn công như vậy không giới hạn ở các cơ quan ba nhà nước hỗ trợ,
Vâng, bạn có những điều cơ bản đúng. Và vâng, STARTTLS chắc chắn là kém an toàn. Nó không chỉ có thể chuyển sang bản rõ mà không cần thông báo, mà bởi vì nó phải chịu các cuộc tấn công trung gian. Vì kết nối bắt đầu rõ ràng, một MitM có thể loại bỏ lệnh STARTTLS và ngăn chặn việc mã hóa không bao giờ xảy ra. Tuy nhiên, tôi tin rằng người gửi thư có thể chỉ định rằng việc chuyển tiền chỉ xảy ra sau khi đường hầm được mã hóa được thiết lập. Vì vậy, bạn có thể làm việc xung quanh này.
Vậy tại sao một thứ như vậy thậm chí còn tồn tại? Vì lý do tương thích. Nếu một trong hai bên không hỗ trợ mã hóa, bạn vẫn có thể muốn kết nối hoàn tất đúng cách.
Đồng ý với @Greg. Những cuộc tấn công là có thể. Tuy nhiên, các MTA có thể được cấu hình (tùy thuộc vào MTA) để sử dụng "TLS bắt buộc", chứ không phải "TLS cơ hội". Điều này có nghĩa là TLS và chỉ TLS được sử dụng (điều này cũng bao gồm STARTTLS) cho các giao dịch email. Nếu MTA từ xa không hỗ trợ STARTTLS, email sẽ bị trả về.
Không, nó không kém an toàn, khi ứng dụng của bạn xử lý chính xác.
Có bốn cách để xử lý TLS và nhiều chương trình cho phép bạn chọn:
starttls, sử dụng kết nối không được mã hóa khi không thành công)starttlsvà không thành công nếu nó không hoạt động)Ưu điểm của TLS trên một cổng chuyên dụng là, bạn có thể chắc chắn rằng không có dự phòng khi bạn sử dụng chương trình mà bạn chưa biết hoặc không hiển thị các cài đặt chi tiết để xử lý lỗi trong trình hướng dẫn khởi động đầu tiên.
Nhưng nói chung, bảo mật phụ thuộc vào việc xử lý các lỗi bảo mật. Một chương trình có thể quyết định chuyển sang cổng plaintext khi TLS trên TLS-Port cũng bị lỗi. Bạn cần biết những gì nó sẽ làm và chọn cài đặt an toàn. Và các chương trình nên sử dụng mặc định an toàn.