Tôi biết rằng TLS về cơ bản là một phiên bản SSL mới hơn và nó thường hỗ trợ chuyển đổi kết nối từ không bảo mật sang bảo mật (thường thông qua lệnh STARTTLS).
Điều tôi không hiểu là tại sao TLS lại quan trọng đối với Chuyên gia CNTT và tại sao lại đưa ra lựa chọn tôi sẽ chọn cái khác. Có phải TLS thực sự chỉ là một phiên bản mới hơn, và nếu vậy nó có phải là một giao thức tương thích không?
Là một chuyên gia CNTT: Khi nào tôi sử dụng? Khi nào tôi không sử dụng?
Câu trả lời:
Câu trả lời ngắn:
SSL là tiền thân của TLS. SSL là một giao thức độc quyền được phát triển bởi Netscape Communications, sau đó được chuẩn hóa trong IETF và được đổi tên thành TLS. Nói tóm lại, các phiên bản đi theo thứ tự này: SSLv2, SSLv3, TLSv1.0, TLSv1.1 và TLSv1.2.
Trái với niềm tin tương đối rộng, điều này hoàn toàn không phải là chạy một dịch vụ trên một cổng khác biệt với SSL và có thể trên cùng một cổng với biến thể văn bản đơn giản với TLS. Cả SSL và TLS đều có thể được sử dụng cho hai phương pháp. Đây là về sự khác biệt giữa SSL / TLS khi kết nối (đôi khi được gọi là "SSL / TLS ngầm") và SSL / TLS sau khi lệnh được ban hành ở cấp giao thức, thường STARTTLS(đôi khi được gọi là "SSL / TLS rõ ràng") . Từ khóa trong STARTTLSlà "BẮT ĐẦU", không phải TLS. Đó là một thông báo, ở cấp độ giao thức ứng dụng, để chỉ ra rằng cần phải chuyển sang SSL / TLS, nếu nó chưa được bắt đầu trước khi trao đổi giao thức ứng dụng.
Sử dụng một trong hai chế độ nên tương đương, miễn là máy khách được cấu hình để mong đợi SSL / TLS bằng cách này hay cách khác, để không bị hạ cấp xuống kết nối văn bản thuần túy.
Câu trả lời dài hơn:
Theo như tôi biết, SSLv1 không bao giờ rời khỏi phòng thí nghiệm. SSLv2 và SSLv3 là các giao thức được phát triển bởi Netscape. SSLv2 đã được coi là không an toàn trong một thời gian, vì nó dễ bị hạ cấp các cuộc tấn công. SSLv3 sử dụng nội bộ (3,0)làm số phiên bản của nó (trong ClientHellotin nhắn).
TLS là kết quả của việc tiêu chuẩn hóa như một giao thức mở hơn trong IETF. (Tôi nghĩ rằng tôi đã đọc ở đâu đó, có lẽ trong cuốn sách của E. Rescorla, rằng tên đó đã được chọn theo cách mà tất cả những người tham gia đều không hài lòng với nó, để không ủng hộ một công ty cụ thể: đây là thông lệ khá phổ biến trong các tiêu chuẩn cơ thể.) Những người quan tâm đến cách chuyển đổi đã được thực hiện có thể đọc Câu hỏi thường gặp về Danh sách thảo luận SSL ; có nhiều bản sao của tài liệu này xung quanh, nhưng hầu hết các liên kết (đến ) đã lỗi thời.netscape.com
TLS sử dụng các thông điệp rất giống nhau (đủ khác nhau để làm cho các giao thức không tương thích, mặc dù có thể đàm phán một phiên bản chung ). Các TLS 1.0 , 1.1 và 1.2 ClientHello thông điệp sử dụng (3,1), (3,2), (3,3)để chỉ số phiên bản, trong đó cho thấy rõ sự tiếp nối từ SSL.
Có nhiều chi tiết hơn về sự khác biệt về giao thức trong câu trả lời này .
Khi nào tôi sử dụng cái nào? Khi nào tôi không sử dụng?
Sử dụng phiên bản cao nhất bạn có thể nếu có thể. Trong thực tế, là nhà cung cấp dịch vụ, điều này sẽ yêu cầu người dùng của bạn có khách hàng hỗ trợ các phiên bản này. Như thường lệ, đây luôn là một bài tập đánh giá rủi ro (tốt nhất là được hỗ trợ với trường hợp kinh doanh nếu thích hợp). Điều này đang được nói, hãy cắt SSLv2 bằng mọi giá.
Ngoài ra, lưu ý rằng bảo mật được cung cấp bởi SSL / TLS không chỉ là về phiên bản bạn sử dụng, mà còn về cấu hình phù hợp: chắc chắn nên sử dụng SSLv3 với bộ mật mã mạnh hơn TLSv1.0 với điểm yếu (hoặc bộ mật mã ẩn danh / null-mã hóa. Một số bộ mật mã, được coi là quá yếu, đã bị cấm rõ ràng bởi các phiên bản mới hơn của TLS. Các bảng trong nhà cung cấp Java 7 SunJSSE (và chú thích của chúng) có thể được quan tâm nếu bạn muốn biết thêm chi tiết.
Tốt nhất nên sử dụng TLS 1.1 ít nhất, nhưng không phải tất cả các máy khách đều hỗ trợ chúng một cách đáng tiếc (ví dụ: Java 6). Khi sử dụng phiên bản dưới 1.1, chắc chắn đáng để xem xét giảm thiểu lỗ hổng BEAST .
Nói chung, tôi muốn giới thiệu cuốn sách của Eric Rescorla - SSL và TLS: Thiết kế và xây dựng hệ thống bảo mật, Addison-Wesley, 2001 ISBN 0-201-61598-3 cho những người thực sự muốn biết thêm chi tiết.
Có một truyền thuyết nói rằng TLS cho phép bạn sử dụng cùng một cổng trong khi SSL thì không thể. Điều đó không đúng (và tôi sẽ bỏ qua việc thống nhất cổng cho cuộc thảo luận này). Thật không may, huyền thoại này dường như đã được truyền bá đến người dùng bởi thực tế là một số ứng dụng như MS Outlook đôi khi đưa ra lựa chọn giữa SSL và TLS trong các tùy chọn cấu hình của họ khi chúng thực sự có nghĩa là lựa chọn giữa SSL / TLS ngầm và rõ ràng. (Có các chuyên gia SSL / TLS tại Microsoft, nhưng có vẻ như họ không tham gia vào Giao diện người dùng Outlook.)
Tôi nghĩ lý do tại sao sự nhầm lẫn này xảy ra là do STARTTLSchế độ. Một số người dường như đã hiểu điều này là STARTTLS= TLS, nhưng đây không phải là trường hợp. Từ khóa trong STARTTLSlà "BẮT ĐẦU", không phải TLS. Tại sao điều này không được gọi STARTSSLhoặc STARTSSLORTLSlà bởi vì các tiện ích mở rộng này được chỉ định trong IETF, chỉ sử dụng tên được sử dụng trong thông số kỹ thuật của nó (giả sử rằng tên TLS cuối cùng sẽ là chỗ đứng duy nhất, tôi đoán vậy).
Ngày nay, hầu hết các máy chủ HTTPS có thể xử lý TLS, nhưng một vài năm trước, hầu hết mọi người đã sử dụng SSLv3 cho HTTPS. HTTPS (nói đúng, được chuẩn hóa là HTTP qua TLS ) thường thiết lập kết nối SSL / TLS khi kết nối TCP và sau đó trao đổi thông điệp HTTP qua lớp SSL / TLS. Có một ngoại lệ cho điều này khi sử dụng proxy HTTP ở giữa. Trong trường hợp này, máy khách kết nối với proxy HTTP rõ ràng (thường là trên cổng 3128), sau đó đưa ra CONNECTlệnh HTTP và, với điều kiện phản hồi đã thành công, bắt đầu bắt tay SSL / TLS bằng cách gửi mộtClientHellothông điệp. Tất cả điều này xảy ra trên cùng một cổng liên quan đến kết nối giữa trình duyệt và proxy (rõ ràng không phải giữa proxy và máy chủ đích: nó thậm chí không phải là cùng một máy). Điều này chỉ hoạt động tốt với SSLv3. Nhiều người trong chúng ta trong tình huống đằng sau một proxy sẽ sử dụng điều này với các máy chủ không hỗ trợ ít nhất TLS 1.0.
Điều này rõ ràng là không có thông số kỹ thuật, nhưng trong thực tế, nó thường hoạt động. Nói một cách chính xác các thông số kỹ thuật nói về việc chuyển sang TLS (không phải SSL) sau khi sử dụng lệnh STARTTLS. Trong thực tế, SSL cũng thường hoạt động (giống như thông số "HTTP trên TLS" cũng bao gồm sử dụng SSL thay vì TLS nữa). Bạn có thể thử nó một mình. Giả sử bạn có máy chủ SMTP hoặc IMAP hỗ trợ STARTTLS, sử dụng Thunderbird, đi vào các tùy chọn, tùy chọn nâng cao, trình chỉnh sửa cấu hình và tắt security.enable_tls. Nhiều máy chủ vẫn sẽ chấp nhận kết nối, đơn giản vì việc triển khai của họ ủy quyền lớp SSL / TLS cho thư viện SSL / TLS thường có thể xử lý SSL và TLS theo cách tương tự, trừ khi được định cấu hình không làm như vậy. Như Câu hỏi thường gặp về OpenLDAP , "Mặc dù cơ chế được thiết kế để sử dụng với TLSv1, hầu hết các triển khai sẽ chuyển sang SSLv3 (và SSLv2) nếu cần. ". Nếu bạn không chắc chắn, hãy kiểm tra với một công cụ như Wireshark.
Nhiều khách hàng có thể sử dụng TLS 1.0 (ít nhất) cho các giao thức trong đó biến thể được bảo mật nằm trên một cổng khác. Rõ ràng, có một số trình duyệt và máy chủ web hỗ trợ TLS 1.0 (hoặc cao hơn) cho HTTPS. Tương tự, SMTPS, IMAPS, POPS và LDAPS cũng có thể sử dụng TLS. Chúng không giới hạn ở SSL.
Khi nào tôi sử dụng cái nào? Khi nào tôi không sử dụng?
Giữa SSL / TLS rõ ràng và ẩn, điều đó không thực sự quan trọng. Vấn đề là khách hàng của bạn biết những gì mong đợi và được cấu hình phù hợp để làm như vậy. Quan trọng hơn, nó nên được cấu hình để từ chối các kết nối văn bản đơn giản khi nó mong đợi kết nối SSL / TLS, cho dù đó là ẩn hay rõ ràng .
Sự khác biệt chính giữa SSL / TLS rõ ràng và ẩn sẽ nằm ở sự rõ ràng của cài đặt cấu hình.
Ví dụ, đối với LDAP, nếu máy khách là máy chủ HTTP Apache ( mod_ldap- tài liệu của nó cũng đánh lừa sự khác biệt giữa SSL và TLS, không may), bạn có thể sử dụng SSL / TLS ẩn bằng cách sử dụng ldaps://URL (ví dụ AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) hoặc sử dụng SSL / TLS bằng cách sử dụng một tham số phụ (ví dụ AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS).
Có lẽ nói chung là một nguy cơ hơi ít khi xác định các giao thức bảo mật trong thức truy cập URL ( https, ldaps, ...) so với khi chờ đợi khách hàng để cấu hình cài đặt bổ sung để kích hoạt SSL / TLS, bởi vì họ có thể quên. Điều này là tranh cãi. Cũng có thể có vấn đề về tính chính xác của việc triển khai cái này so với cái kia (ví dụ, tôi nghĩ rằng máy khách Java LDAP không hỗ trợ xác minh tên máy chủ khi sử dụng ldaps://, khi cần, trong khi nó được hỗ trợ với ldap://+ StartTLS).
Nghi ngờ và để tương thích với nhiều khách hàng hơn nếu có thể, dường như không có hại gì khi cung cấp cả hai dịch vụ khi máy chủ hỗ trợ (máy chủ của bạn sẽ chỉ nghe trên hai cổng cùng một lúc). Nhiều triển khai máy chủ cho các giao thức có thể được sử dụng với một trong hai chế độ sẽ hỗ trợ cả hai.
Khách hàng có trách nhiệm không để bản thân bị hạ cấp xuống kết nối văn bản đơn giản. Là quản trị viên máy chủ, về mặt kỹ thuật bạn không thể làm gì để ngăn chặn các cuộc tấn công hạ cấp (ngoài việc yêu cầu chứng chỉ ứng dụng khách có lẽ). Máy khách phải kiểm tra xem SSL / TLS đã được bật chưa, cho dù đó là khi kết nối hay sau STARTTLSlệnh tương tự. Trong cùng một cách như một trình duyệt không nên để bản thân được chuyển hướng từ https://đến http://, một khách hàng cho một giao thức hỗ trợ STARTTLS
nên chắc chắn câu trả lời là tích cực và SSL / TLS kết nối được kích hoạt trước khi tiếp tục. Kẻ tấn công MITM đang hoạt động có thể dễ dàng hạ cấp các kết nối.
Ví dụ: các phiên bản cũ hơn của Thunderbird có một tùy chọn không tốt cho cái gọi là "Sử dụng TLS, nếu có" , về cơ bản ngụ ý rằng nếu kẻ tấn công MITM có thể thay đổi các thông báo máy chủ để nó không quảng cáo hỗ trợ cho STARTTLS, máy khách sẽ âm thầm để bản thân bị hạ cấp xuống một kết nối văn bản đơn giản. (Tùy chọn không an toàn này không còn khả dụng trong Thunderbird.)
TLS là một giao thức mới hơn SSL (nhưng AFAIK, nó tương thích với SSL v3). Thông thường, chỉ có một sự khác biệt bạn cần lo lắng:
Giao thức SSL thường có một cổng riêng - ví dụ: 80 cho HTTP và 443 cho HTTPS (HTTP / SSL). Khi bạn kết nối với cổng SSL, toàn bộ phiên được mã hóa.
TLS mới hơn SSL và nó không yêu cầu một cổng riêng - thay vào đó, nó phải được khách hàng đàm phán .. Ví dụ: bạn có thể chạy IMAP trên cổng 143 và nếu cả máy chủ thư và máy khách đều hỗ trợ TLS, máy khách sẽ gửi một STARTTLSlệnh và chỉ sau đó kích hoạt mã hóa. Bằng cách này, bạn không cần một cổng chỉ dành riêng cho SSL, trong khi vẫn tương thích với các ứng dụng không có SSL.
Tóm tắt:
SSL : Hơi cũ. Các cổng riêng biệt cho các kết nối đơn giản và được mã hóa. Tất cả lưu lượng truy cập trên cổng SSL luôn được mã hóa.
TLS : Cổng đơn cho cả kết nối đơn giản và được mã hóa. Mã hóa chỉ được kích hoạt sau khi máy khách đưa ra STARTTLSlệnh.
STARTTLStrong một số giao thức cho phép chuyển sang TLS trên cùng một kết nối không phải là sự khác biệt giữa SSL và TLS. Về mặt kỹ thuật, bạn có thể chuyển sang SSLv3 theo cách tương tự.
Từ bài viết Cơ sở Kiến thức của Đại học Indiana này:
SSL là viết tắt của Lớp cổng bảo mật. Netscape ban đầu đã phát triển giao thức này để truyền thông tin riêng tư, đảm bảo tính toàn vẹn của thông điệp và đảm bảo nhận dạng máy chủ. SSL hoạt động chủ yếu thông qua việc sử dụng mã hóa khóa công khai / riêng trên dữ liệu. Nó thường được sử dụng trên các trình duyệt web, nhưng SSL cũng có thể được sử dụng với các máy chủ email hoặc bất kỳ loại giao dịch máy khách-máy chủ nào. Ví dụ: một số máy chủ nhắn tin tức thời sử dụng SSL để bảo vệ các cuộc hội thoại.
TLS là viết tắt của Transport Layer Security. Lực lượng đặc nhiệm kỹ thuật Internet (IETF) đã tạo ra TLS với tư cách là người kế thừa SSL. Nó thường được sử dụng như một cài đặt trong các chương trình email, nhưng, giống như SSL, TLS có thể có vai trò trong bất kỳ giao dịch máy khách-máy chủ nào.
Sự khác biệt giữa hai giao thức là rất nhỏ và rất kỹ thuật, nhưng chúng là các tiêu chuẩn khác nhau. TLS sử dụng các thuật toán mã hóa mạnh hơn và có khả năng hoạt động trên các cổng khác nhau. Ngoài ra, TLS phiên bản 1.0 không tương tác với SSL phiên bản 3.0.
TLS là phiên bản mới hơn của SSL. Mặc dù ở một số nơi, những từ này có thể có nghĩa gì đó ngoài các giao thức, vì vậy hãy làm rõ câu hỏi của bạn.