Vì sao SSL được đổi tên thành TLS vào cuối thập niên 90
(tim.dierks.org)- Giữa cuộc chiến trình duyệt vào giữa thập niên 1990, khi khả năng SSL của Netscape và PCT của Microsoft rẽ nhánh ngày càng lớn, ngành công nghiệp đã cố gắng gom chúng vào một tiêu chuẩn mở duy nhất
- SSL ban đầu có lỗi nên không được phát hành; phiên bản đầu tiên được dùng thực tế là SSL 2 cũng được sử dụng trong vài năm nhưng có các hạn chế về mật mã học và tính thực tiễn
- PCT của Microsoft là phần mở rộng riêng dựa trên SSL 2, được điều chỉnh cho IE và IIS; Netscape đáp lại bằng SSL 3.0 để không đánh mất quyền dẫn dắt tiêu chuẩn
- Netscape và Microsoft đã đồng ý với quy trình tiêu chuẩn hóa mở của IETF, nhưng cần tránh để trông như IETF chỉ phê chuẩn nguyên trạng giao thức của Netscape
- Cuối cùng, SSL 3.0 được đưa vào một số thay đổi và cũng được đổi tên; TLS 1.0 thực chất khởi đầu dưới dạng gần với SSL 3.1
SSL và PCT trong cuộc chiến trình duyệt
- Cuộc cạnh tranh trình duyệt giữa Netscape và Microsoft vào giữa thập niên 1990 cũng ảnh hưởng đến việc tiêu chuẩn hóa giao thức bảo mật
- Netscape đã phát triển giao thức SSL
- Phiên bản ban đầu nhanh chóng bị phá vỡ do lỗi mật mã học và không được phát hành
- Phiên bản production đầu tiên là SSL 2 và đã được sử dụng trong vài năm
- SSL 2 có các lỗi về mật mã học và thực tiễn, nhưng chưa phải là một cuộc khủng hoảng nghiêm trọng đến mức phải thay thế ngay lập tức
- Microsoft đã sửa đổi SSL 2, thêm các phần riêng của mình và định nghĩa PCT
- PCT là giao thức phái sinh từ SSL 2
- Phạm vi hỗ trợ chỉ giới hạn ở IE và IIS
- Netscape cũng muốn sửa các vấn đề của SSL 2, nhưng không muốn rơi vào tình huống Microsoft giành quyền lãnh đạo hoặc quyền sở hữu tiêu chuẩn
- Kết quả là họ phát triển SSL 3.0 với những thay đổi lớn hơn
Tiêu chuẩn hóa IETF và cái tên TLS
- Nhiều người trong ngành và cộng đồng muốn tránh tình trạng giao thức bị fork
- Consensus Development đã tổ chức một cuộc họp có đại diện của Netscape và Microsoft tham dự
- Tim Dierks khi đó làm việc tại Consensus Development cùng Christopher Allen
- Ông đã viết bản triển khai tham chiếu SSL 3.0 theo hợp đồng với Netscape
- Bruce Schneier tham dự cuộc họp; Paul Kocher, người thiết kế giao thức SSL 3, có lẽ cũng tham dự; phía Microsoft do Barbara Fox đại diện
- Kết quả đàm phán là Microsoft và Netscape đồng ý để IETF tiếp nhận giao thức và tiêu chuẩn hóa theo quy trình mở
- Quá trình này dẫn đến việc Tim Dierks biên tập RFC
- Trong quá trình tiêu chuẩn hóa, SSL 3.0 được đưa vào một số thay đổi
- Mục đích là để tránh việc trông như IETF chỉ đơn giản phê chuẩn giao thức của Netscape
- Vì lý do tương tự, tên giao thức cũng được đổi
- TLS 1.0 ra đời như vậy thực tế là một phiên bản gần với SSL 3.1
1 bình luận
Các ý kiến trên Hacker News
Số phiên bản không thể hiện rõ khác biệt giữa các giao thức, nên càng dễ gây nhầm lẫn
SSLv2 là SSL đầu tiên được triển khai rộng rãi nhưng có nhiều vấn đề, còn SSLv3 gần như là một giao thức mới
TLS 1.0 tương tự SSLv3 nhưng được chỉnh sửa đôi chút trong quá trình chuẩn hóa của IETF, còn TLS 1.1 là một bản sửa đổi rất nhỏ nhằm khắc phục vấn đề trong cách dùng mã khối
TLS 1.2 là bản sửa đổi quy mô trung bình, bổ sung các hàm băm mới và bộ mã AEAD như AES-GCM để ứng phó với điểm yếu của MD5 và SHA-1, còn TLS 1.3 tuy tái sử dụng một số yếu tố trước TLS 1.2 nhưng phần lớn gần như là một giao thức mới
Tất cả các giao thức này đều được thiết kế để có thể tự động thương lượng phiên bản, nhờ đó client và server có thể nâng cấp độc lập mà không mất khả năng kết nối
Một trong số đó là session ticket, cho phép phía server khôi phục phiên mà không cần lưu trạng thái đồng bộ giữa các server; một cái khác là Server Name Indication, cho phép server dùng nhiều hơn một chứng chỉ
Việc đặt các phiên bản sau thành v1.1, v1.2, v1.3 trông cũng giống như sự cố chấp không muốn thừa nhận rằng việc reset số phiên bản là sai một cách khách quan
Microsoft thời đó là một con thú hoàn toàn khác, nên sự lẫn lộn tên gọi SSL/TLS cũng không có gì quá lạ
M$ thời ấy cố kiểm soát mọi thứ, và tôi cho rằng họ vẫn chưa ngừng các nỗ lực làm chậm công nghệ Internet mã nguồn mở cho đến tận đầu thập niên 2010
Tôi nghĩ họ đã thành công trong việc giết Java Applet, đồng thời cũng khiến JavaScript và CSS nói chung tụt hậu nhiều năm
Đầu những năm 2000, công ty gây áp lực buộc chúng tôi hỗ trợ “công nghệ” mới nhất của IE, nhưng ngay khi các lỗi JS cốt lõi được sửa, chúng tôi bắt đầu hỗ trợ Mozilla 3.0, và về sau đó hóa ra là một quyết định tốt khi một công ty Fortune 500 dùng Mozilla/Firefox cho ứng dụng nội bộ từ rất lâu trước khi nó trở nên phổ biến
Nó luôn hoạt động trong IE, và đó gần như là con đường duy nhất mà Microsoft có thể gây ảnh hưởng
Applet thất bại vì trở thành ví dụ điển hình cho câu “Java chậm”; dù nói chung nhận định đó không hẳn đúng, nhưng với Applet thì đúng vì phải chờ tải xuống và chờ JVM khởi động
Cuối cùng HTML/JS làm tốt hơn các tính năng động mà trước đây cần Applet, còn phần còn lại mà HTML chưa đáp ứng được thì Flash chiếm lấy, nên Applet biến mất
Chỉ để chạy một animation vụn vặt mà thời gian khởi động JRE đã dài đến vô lý; theo tiêu chuẩn thời đó, yêu cầu bộ nhớ và tình trạng crash cũng rất nặng, và các vấn đề tương thích ở những bản phát hành đầu của nền tảng Java cũng kỳ quặc
Mô hình bảo mật dựa trên giả định rằng các thực thể có thể nhận chứng chỉ CA sẽ là người tốt cũng nực cười, và công nghệ sandbox của trình duyệt nói chung, không chỉ IE, khi đó cũng còn non nớt
Tôi từng kỳ vọng nhiều vào s2n, nhưng có vẻ nó không chiếm được chỗ đứng đáng kể bên ngoài AWS
Những người phân biệt rạch ròi TLS và SSL là người biết khác biệt giữa chúng và cho rằng đối phương cũng nên biết, nhưng trong thực tế thì nó giống khác biệt giữa .doc và .docx
Về căn bản là khác nhau, nhưng với người dùng phổ thông thì trông có vẻ có thể dùng thay thế cho nhau, và ngoài hiện trường thì phần lớn chỉ quan tâm HTTPS có chạy hay không, chứ không mấy để ý bên trong hoạt động thế nào
Tôi nhớ đã tranh luận khá nhiều với những người nghĩ rằng số càng lớn thì càng tốt
Sẽ dễ hơn nhiều nếu gọi mọi lưu lượng mạng mã hóa hiện đại là TLS, và chỉ gọi là SSL khi thật sự phải dùng SSL vì hệ thống legacy
Tôi vừa nhận ra rằng trong vô thức đầu óc mình vẫn thấy khó phân biệt SSL và TLS
Sau 20 năm cuối cùng tôi mới hiểu vì sao lại như vậy
Sau 15 năm trong ngành này tôi mới thật sự nhận ra ssl và tls là cùng một thứ, cảm giác như mình thành thằng ngốc
Cơ duyên là việc trong Java, ngay cả khi dùng TLSv1.3 ngày nay, để bắt đầu một kết nối mã hóa vẫn dùng SSLSocket
“Transport Layer Security” đúng là tên hay hơn
Nói “TLS” cũng ổn, còn SSL với hai chữ S liền nhau nghe như tiếng rắn
Transport Layer Security được ghi nhận rộng rãi là bắt đầu từ năm 1999, còn “Thread Local Storage” có tài liệu ít nhất từ tận năm 1996
Khi đó thuật ngữ này phổ biến hơn ở phía Microsoft, có lẽ cả IBM/OS/2, còn trong Pthreads và Unix nói chung thì có xu hướng gọi là “thread-specific data”
Tài liệu Itanium ABI năm 2001 có thể đã phổ biến thuật ngữ này rộng hơn trong thế giới Unix, nhưng có vẻ Sun cũng đã dùng thuật ngữ này từ trước trong Solaris và Java
Về lý thuyết, TLS có thể là một cơ chế bảo mật tầng vận chuyển cho phép đặt tùy ý giao thức lên trên, như IPSec, nhưng trên thực tế nó gần như bị gắn với socket TCP
Các biến thể cho UDP như DTLS hay QUIC cũng không phải một phần của đặc tả TLS, và dù có kernel TLS của Linux hay hạ tầng tương tự trên Windows, việc bật TLS cũng không dễ đến mức chỉ đặt một socket flag
Tôi tò mò khi nói với ai đó rằng họ cần truy cập một trang web một cách an toàn, hoặc trong tình huống đáng dùng thuật ngữ TLS/SSL, mọi người thường nói gì
Trong một thời gian dài tôi thậm chí không biết TLS có phải là “cùng một thứ” không, và dù giờ đã biết thì 9 trên 10 lần tôi vẫn gọi là SSL
Tôi 38 tuổi và bắt đầu đi làm năm 2011, nhưng lần đầu làm lập trình mạng là khoảng 2004~2005
Vừa nhìn sang màn hình khác thì thấy một hàm tôi thêm câu lệnh if vài phút trước cũng đang dùng tên
sslCertNotBeforeTôi nghĩ một phần vấn đề là lập trình viên thường không trực tiếp xử lý TLS
Tôi từng xây dựng một hệ thống trích xuất thông tin chứng chỉ chi tiết từ kết nối HTTPS, và việc lôi các thông tin cần thiết ra từ thư viện chuẩn Java khá vất vả
Khi mọi thứ được xử lý tự động và vô hình thì khó mắc lỗi hơn, nhưng việc biến nó thành hộp đen lại không giúp lan tỏa hiểu biết sâu về cách TLS thực sự hoạt động
Bao gồm OpenSSL thống trị nhất, cũng như BoringSSL, LibreSSL, wolfSSL, v.v.
Các thư viện có TLS trong tên gồm GnuTLS, mbedTLS, s2n-tls, RustTLS, nhưng tương đối ít được dùng hơn
Vì nó dễ được hiểu hơn so với TLS chính xác hơn, và giờ chẳng còn ai dùng SSL 3.0 thật nữa
Tên các thư viện kinh điển như OpenSSL cũng có SSL
Tuy nhiên đó cũng có thể là thói quen từ thời tôi học SSL trong giai đoạn chiến tranh mật mã những năm 1990, khi muốn dùng mã hóa SSL đúng nghĩa thì phải kiếm phiên bản Netscape “US only”
Vì đôi khi cả người bình thường cũng biết nó nghĩa là gì
Dù vậy đôi khi SSL vẫn buột miệng
Tôi 51 tuổi và bắt đầu làm IT vào giữa thập niên 90
Tôi nghĩ TLS 1.0 không phải đã chứa khá nhiều cải tiến lớn so với SSL 3.0 sao
Chỉ đọc bài thì trông như họ chỉ sửa vài thứ để trông khác đi
Khi có thông tin tiết lộ trước rằng tấn công POODLE chỉ ảnh hưởng đến SSL3 chứ không ảnh hưởng TLS1.0, chỉ riêng thông tin đó cũng đủ để dự đoán đây sẽ là padding oracle
Hai thứ khá giống nhau, và nói rằng có vài “bản sửa lỗi” được đưa vào là công bằng
Chuyện đã lâu nên có thể tôi đã quên vài thứ, và vì SSL3 và TLS1.0 luôn được triển khai cùng nhau nên có thể tôi đã bỏ sót chi tiết
Nhìn chung giống việc IETF không phê chuẩn nguyên xi giao thức SSL 3.0 mà đánh dấu lãnh địa của mình hơn
Một bài liên quan là “Randomness and the Netscape Browser” trên Dr. Dobb's Journal tháng 1 năm 1996
https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
Bài viết được viết năm 1996, nhưng ngôn ngữ dùng trong đó đã có cảm giác khá khác với các ấn phẩm ngày nay, khiến tôi thấy mình già đi
Cũng như năm 1996, các bài trên LWN ngày nay [1] đọc vẫn có văn phong khá tương tự
Dù vậy có thể chúng nhắm đến độc giả phổ thông hơn một chút nên bớt cứng hơn đôi chút
[1] https://lwn.net/
Tôi nhớ cuốn “SSL and TLS: Designing and Building Secure Systems” của Eric Rescorla thật sự hữu ích để hiểu lịch sử của TLS và quá trình nó đi đến hiện nay
Sách xuất bản năm 2001, đã cảnh báo một số vấn đề mà sau này trở thành CVE, và cũng có thể mua sách cũ với giá vài đô la
Vào khoảng năm 2014, tôi nghĩ đồng thuận rằng SSL 2.0 có lỗi nghiêm trọng đã rất vững chắc
Ngay cả handshake cũng không được xác thực đúng cách