Câu hỏi Sự khác biệt giữa SSL & TLS


Theo wikipedia: http://en.wikipedia.org/wiki/Transport_Layer_Security

Có vẻ như TLS là một thay thế cho SSL, nhưng hầu hết các trang web vẫn đang sử dụng SSL?


76
2017-09-11 11:05


gốc


"hầu hết các trang web vẫn đang sử dụng SSL". Đây là một khảo sát tốt về hỗ trợ giao thức trustworthyinternet.org/ssl-pulse/#chart-protocol-support - Colonel Panic
Câu hỏi phổ biến hơn: security.stackexchange.com/questions/5126/… - Vadzim


Các câu trả lời:


Tóm lại, TLSv1.0 ít nhiều là SSLv3.1. Bạn có thể tìm thêm chi tiết trong câu hỏi này trên ServerFault.

Hầu hết các trang web thực sự hỗ trợ cả SSLv3 và TLSv1.0 ít nhất, như nghiên cứu này chỉ ra (Lee, Malkin, và giấy của Nahum: Cường độ mã hóa của máy chủ SSL / TLS: Thực tiễn hiện tại và gần đây, IMC 2007) (liên kết thu được từ Danh sách IETF TLS). Hơn 98% hỗ trợ TLSv1 +.

Tôi nghĩ rằng lý do tại sao SSLv3 vẫn còn được sử dụng là để hỗ trợ di sản (mặc dù hầu hết các trình duyệt hỗ trợ TLSv1 và một số TLSv1.1 hoặc thậm chí TLSv1.2 ngày nay). Cho đến cách đây không lâu, một số bản phân phối vẫn có SSLv2 (được coi là không an toàn) theo mặc định cùng với những người khác.

(Bạn cũng có thể tìm thấy câu hỏi này thú vị, mặc dù đó là về mô hình sử dụng của TLS chứ không phải là SSL so với TLS (bạn có thể thực sự có cùng mẫu với SSL). Tuy nhiên, điều này không áp dụng cho HTTPS, vì HTTPS sử dụng SSL / TLS từ đầu kết nối.)


52
2017-09-12 00:55





Từ http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

Vào đầu những năm 90, vào buổi bình minh của World Wide Web, một số kỹ sư tại Netscape đã phát triển một giao thức để thực hiện các yêu cầu HTTP an toàn và những gì họ đã đưa ra được gọi là SSL. Do kiến ​​thức tương đối khan hiếm về các giao thức an toàn vào thời điểm đó, cũng như áp lực mãnh liệt tất cả mọi người ở Netscape đều đang làm việc, những nỗ lực của họ chỉ có thể được xem là cực kỳ anh hùng. Thật tuyệt vời khi SSL đã phải chịu đựng miễn là nó có, trái ngược với một số giao thức khác từ cùng một cổ điển. Tuy nhiên, chúng tôi đã học được rất nhiều điều, nhưng điều về giao thức và API là có rất ít sự trở lại.

Có hai cập nhật chính cho giao thức SSL, SSL 2 (1995) và SSL 3 (1996). Chúng được thực hiện một cách cẩn thận để tương thích ngược, để dễ dàng áp dụng. Tuy nhiên khả năng tương thích ngược là một ràng buộc đối với một giao thức bảo mật mà nó có thể có nghĩa là dễ bị tổn thương ngược.

Vì vậy, nó đã được quyết định để phá vỡ tính tương thích ngược, và giao thức mới có tên TLS 1.0 (1999). (Trong nhận thức muộn màng, có thể rõ ràng hơn khi đặt tên là TLS 4)

Sự khác biệt giữa giao thức này và SSL 3.0 không đáng kể, nhưng chúng đủ quan trọng để TLS 1.0 và SSL 3.0 không tương thích.

TLS đã được sửa đổi hai lần, TLS 1.1 (2006) và TLS 1.2 (2008).

Tính đến năm 2015, tất cả các phiên bản SSL bị hỏng và không an toàn (cuộc tấn công POODLE) và các trình duyệt đang xóa hỗ trợ. TLS 1.0 có mặt khắp mọi nơi, nhưng chỉ 60% trang web hỗ trợ TLS 1.1 và 1.2, một tình trạng xin lỗi.


Nếu bạn quan tâm đến công cụ này, tôi khuyên bạn nên nói chuyện thông minh và hài hước của Moxie Marlinspike tại https://www.youtube.com/watch?v=Z7Wl2FW2TcA 


22
2017-07-22 19:45



Tôi nhớ một tin tức Usenet: comp.sources.unix gửi tên là Secure Sockets Layer vào cuối những năm 1980. Tôi nghi ngờ nó có nhiều nếu có bất kỳ mối quan hệ nào với những gì Netscape đã làm ngoài tên. - user207421


tls1.0 có nghĩa là sslv3.1

tls1.1 có nghĩa là sslv3.2

tls1.2 có nghĩa là sslv3.3

các rfc chỉ thay đổi tên, bạn có thể tìm thấy mã hex của tls1.0 là 0x0301, có nghĩa là sslv3.1


9
2017-08-20 05:46





TLS duy trì tính tương thích ngược với SSL và do đó giao thức truyền thông gần như giống hệt nhau trong bất kỳ phiên bản nào được đề cập ở đây. Hai khác biệt quan trọng giữa SSL v.3, TLS 1.0 và TLS 1.2, là hàm giả ngẫu nhiên (PRF) và hàm băm HMAC (SHA, MD5, bắt tay), được sử dụng để xây dựng khối khóa đối xứng cho Mã hóa dữ liệu ứng dụng (khóa máy chủ + khóa ứng dụng khách + IV). Sự khác biệt lớn giữa TLS 1.1 và TLS 1.2 là 1.2 yêu cầu sử dụng "rõ ràng" IV để bảo vệ chống lại các cuộc tấn công CBC, mặc dù không có thay đổi đối với PRF hoặc giao thức cần thiết cho việc này. TLS 1.2 PRF là bộ mã hóa cụ thể, có nghĩa là PRF có thể được thương lượng trong quá trình bắt tay. SSL ban đầu được phát triển bởi Netscape Communications (lịch sử) và sau đó được duy trì bởi Internet Engineering Task Force (IETF, hiện tại). TLS được duy trì bởi Nhóm làm việc mạng. Đây là sự khác biệt giữa các hàm PRF HMAC trong TLS:

TLS 1.0 và 1.1

PRF (bí mật, nhãn, hạt giống) = P_MD5 (S1, nhãn + hạt giống) XOR P_SHA-1 (S2, nhãn + hạt giống);

TLS 1.2

PRF (bí mật, nhãn, hạt giống) = P_hash (bí mật, nhãn + hạt giống)


2
2017-08-24 22:03





"Nếu nó không bị hỏng, đừng chạm vào nó". SSL3 hoạt động tốt trong hầu hết các kịch bản (có một lỗ hổng cơ bản được tìm thấy trong giao thức SSL / TLS vào tháng 10, nhưng đây là một lỗ hổng của các ứng dụng nhiều hơn bản thân procol), vì vậy các nhà phát triển không vội vàng nâng cấp các mô-đun SSL của họ. TLS mang lại một số phần mở rộng hữu ích và các thuật toán bảo mật, nhưng chúng là tiện ích bổ sung và không phải là một. Vì vậy, TLS trên hầu hết các máy chủ vẫn là một lựa chọn. Nếu cả máy chủ và máy khách đều hỗ trợ nó, nó sẽ được sử dụng.

Cập nhật: trong '2016 SSL 3, và thậm chí TLS lên đến 1,2 được tìm thấy là dễ bị tấn công khác nhau và di chuyển đến TLS 1.2 được khuyến khích. Có tồn tại các cuộc tấn công vào việc triển khai TLS 1.2, mặc dù chúng phụ thuộc vào máy chủ. TLS 1.3 hiện đang được phát triển. Và bây giờ TLS 1.2 là phải.


1
2017-09-11 12:16



Không, đây là lỗ hổng giao thức và nhà phát triển nên nâng cấp ngăn xếp SSL của mình. Điều này đang được nói, có các nguyên tắc để sử dụng phần mở rộng đàm phán lại trong RFC 5746 cho SSLv3, ngoài ra đối với TLS. - Bruno
Nếu bạn giết ai đó bằng con dao, đây không phải là lỗ hổng của con dao, mà là một bộ não của bạn. Tương tự ở đây. Nếu giao thức được sử dụng theo cách nó không được thiết kế, nó không phải là một lỗ hổng của giao thức. - Eugene Mayevski 'Allied Bits
Giao thức được thiết kế theo cách ứng dụng trên đầu nó nên coi nó như một ổ cắm bình thường càng nhiều càng tốt. Vấn đề đàm phán lại, không có phần mở rộng mới, nhận thức lực lượng của lớp ứng dụng (ví dụ: HTTP). Có một chủ đề quan tâm về chủ đề này trong danh sách gửi thư của IETF TLS: ietf.org/mail-archive/web/tls/current/msg04000.html - Bruno
Tôi đồng ý một số điều nên được thực hiện ở cấp ứng dụng, nhưng tôi không biết về bất kỳ triển khai và giao thức nào có tính đến điều đó. Các ngăn xếp thường có thể đối phó với đàm phán lại rằng họ bắt đầu hợp pháp, nhưng không quá nhiều nếu một MITM khởi tạo nó (đó là vấn đề). Đó là lý do tại sao nhóm ILSF TLS chọn khắc phục nó ở cấp TLS, và đó cũng là lý do tại sao mọi người thực sự nên bật tiện ích mở rộng đó hoặc vô hiệu hóa đàm phán lại hoàn toàn. - Bruno
Có nhiều vấn đề cơ bản hơn trong SSL 3.0 so với vấn đề bạn đề cập. Ví dụ: oracle padding CBC, cũng như việc tái sử dụng IV hoặc bản ghi trước đó. TLS trước đây vẫn là bệnh dịch hạch nhưng có thể được làm việc xung quanh, trong khi sau này được cố định trên TLS 1.1. - Nikos


https://hpbn.co/transport-layer-security-tls/ là một bài giới thiệu hay

Giao thức SSL ban đầu được phát triển tại Netscape để cho phép bảo mật giao dịch thương mại điện tử trên Web, yêu cầu mã hóa để bảo vệ dữ liệu cá nhân của khách hàng cũng như bảo đảm xác thực và toàn vẹn để đảm bảo giao dịch an toàn. Để đạt được điều này, giao thức SSL đã được triển khai ở tầng ứng dụng, trực tiếp trên đỉnh của TCP (Hình 4-1), cho phép các giao thức trên nó (HTTP, email, tin nhắn tức thì và nhiều giao thức khác) hoạt động không thay đổi giao tiếp qua mạng.

Khi SSL được sử dụng đúng, người quan sát bên thứ ba chỉ có thể phỏng đoán điểm cuối kết nối, loại mã hóa, cũng như tần suất và số lượng dữ liệu gần đúng được gửi, nhưng không thể đọc hoặc sửa đổi bất kỳ dữ liệu thực tế nào.

SSL 2.0 là phiên bản phát hành công khai đầu tiên của giao thức, nhưng nó đã nhanh chóng được thay thế bằng SSL 3.0 do một số lỗi bảo mật được phát hiện. Bởi vì giao thức SSL là độc quyền đối với Netscape, IETF đã hình thành một nỗ lực để chuẩn hóa giao thức, kết quả là RFC 2246, được xuất bản vào tháng 1 năm 1999 và được gọi là TLS 1.0. Kể từ đó, IETF đã tiếp tục lặp đi lặp lại trên giao thức để giải quyết các lỗ hổng bảo mật, cũng như mở rộng khả năng của nó: TLS 1.1 (RFC 2246) được xuất bản vào tháng 4 năm 2006, TLS 1.2 (RFC 5246) vào tháng 8 năm 2008 và hiện đang hoạt động đang tiến hành để xác định TLS 1.3.


0
2018-01-17 14:30