TLS: Giao thức đằng sau mỗi biểu tượng ổ khóa

SSL → TLS: câu chuyện theo trình tự thời gian

Netscape Communications đã xây dựng triển khai SSL đầu tiên vào năm 1994 để đảm bảo mua sắm trực tuyến trong trình duyệt Netscape Navigator hoàn toàn mới. SSL 1.0 chưa bao giờ được phát hành công khai vì nó có những lỗi nghiêm trọng. SSL 2.0 được xuất xưởng vào tháng 2 năm 1995, đã nhanh chóng bị phá vỡ, và SSL 3.0 tiếp theo vào năm 1996 gần như được viết lại hoàn toàn.

Năm 1999, IETF tiếp quản giao thức và đổi tên nó thành Transport Layer Security để đánh dấu sự chuyển đổi từ một sản phẩm Netscape sang một tiêu chuẩn mở. Lịch sử phiên bản kể từ:

• TLS 1.0 (Tháng 1 năm 1999, RFC 2246) — về cơ bản là SSL 3.1.
• TLS 1.1 (Tháng 4 năm 2006, RFC 4346) — được bảo vệ khỏi các cuộc tấn công CBC thông qua khởi tạo rõ ràng vectơ.
• TLS 1.2 (tháng 8 năm 2008, RFC 5246) — đã thêm mật mã AEAD, SHA-256, thuật toán chữ ký có thể định cấu hình. Thống trị trong một thập kỷ.
• TLS 1.3 (tháng 8 năm 2018, RFC 8446) — thiết kế lại lớn. Đã xóa hành trình cũ, bí mật bắt buộc về phía trước, giảm độ trễ bắt tay.

SSL 3.0 chính thức không được dùng nữa vào tháng 6 năm 2015 (RFC 7568) sau POODLE. TLS 1.0 và 1.1 đã ngừng hoạt động từ tháng 3 năm 2021 (RFC 8996). Vào năm 2026, các máy chủ hiện đại sẽ từ chối mọi thứ dưới TLS 1.2 và ưu tiên TLS 1.3.

Cách bắt tay thực sự hoạt động

Mỗi kết nối TLS đều bắt đầu bằng một cái bắt tay thực hiện ba điều: đồng ý về bộ mật mã, chứng minh danh tính của máy chủ và lấy ra các khóa chung cho phần còn lại của phiên. Bắt tay

TLS 1.2 (the luồng cổ điển)

1. ClientHello: máy khách gửi các phiên bản TLS được hỗ trợ, bộ mật mã và một số ngẫu nhiên.
2. ServerHello: máy chủ chọn một bộ mật mã, gửi số ngẫu nhiên của nó.
3. Certificate: máy chủ gửi chuỗi chứng chỉ X.509 để khách hàng có thể xác minh danh tính.
4. ServerKeyExchange: máy chủ gửi khóa công khai Diffie-Hellman (để trao đổi khóa tạm thời).
5. ClientKeyExchange: khách hàng gửi khóa công khai DH của mình. Giờ đây, cả hai bên đều có cùng một bí mật được chia sẻ.
6. Finished: cả hai bên xác nhận việc bắt tay bằng cách gửi MAC qua toàn bộ bản ghi.

Đó là hai chuyến đi khứ hồi đầy đủ trước khi byte ứng dụng đầu tiên có thể lưu chuyển. Trên liên kết có độ trễ 100ms, mỗi kết nối HTTPS mới sẽ tiêu tốn 200ms trước khi bất kỳ nội dung thực tế nào di chuyển.

TLS 1.3 bắt tay (luồng hiện đại)

TLS 1.3 thu gọn bắt tay thành một vòng trong trường hợp thông thường:

1. ClientHello: bao gồm khóa công khai DH của khách hàng cho mọi nhóm mật mã mà khách hàng hỗ trợ.
2. ServerHello + mọi thứ khác: máy chủ chọn một nhóm, gửi khóa công khai DH, chứng chỉ và Đã hoàn thành, tất cả trong một chuyến bay.
3. Client xác thực và trả lời bằng Finished của riêng mình.

Một chuyến khứ hồi, hai chuyến bay. Với tính năng tiếp tục phiên (0-RTT), máy khách thậm chí có thể bắt đầu gửi dữ liệu bằng tin nhắn đầu tiên — với chi phí là một số thuộc tính bảo mật chuyển tiếp cho dữ liệu ban đầu đó.

Đã xóa TLS 1.3 nào

TLS 1.3 có một động thái lớn khác là xóa. Đã hết:

• Trao đổi khóa RSA tĩnh (phá vỡ bí mật chuyển tiếp).Mật mã chế độ
• CBC (dễ bị tấn công bởi BEAST và Lucky Thirteen).Mật mã luồng
• RC4 (đã bị hỏng từ lâu).Băm
• MD5 và SHA-1 cho chữ ký.
• Renegotiation (được thay thế bằng xác thực sau bắt tay).
• Compression (lớp tấn công CRIME).
• Thông số Diffie-Hellman tùy chỉnh (sửa lỗi Logjam).

Danh sách bộ mật mã đã tăng từ ~300 trong TLS 1.2 xuống còn 5 in TL 1.3. Ít dây để treo cổ hơn.

Lịch sử tấn công đã định hình TLS

• BEAST (2011) — cuộc tấn công bằng văn bản thuần đã chọn vào chế độ CBC trong TLS 1.0. Đã sửa lỗi trong phiên bản 1.1+ thông qua IV rõ ràng.
• CRIME (2012) — đã sử dụng tính năng nén TLS để khôi phục cookie phiên. Đã khắc phục bằng cách tắt tính năng nén.
• BREACH (2013) — mức nén cấp HTTP tương đương với CRIME. Giảm thiểu bằng cách tắt tính năng nén HTTP đối với các phản hồi nhạy cảm.
• Heartbleed (Tháng 4 năm 2014) — Lỗi OpenSSL, không phải vấn đề về thông số TLS. Bộ nhớ máy chủ bị rò rỉ bao gồm cả khóa riêng. Sự kiện luân chuyển chứng chỉ hàng loạt trên web.
• POODLE (Tháng 10 năm 2014) — khai thác dự phòng SSL 3.0. Đã loại bỏ SSL 3.0 trong các trình duyệt trong vài tuần.
• Logjam (2015) — cho thấy rằng các nhóm Diffie-Hellman nhỏ (đặc biệt là Nhóm 2 1024-bit được sử dụng rộng rãi trong IPsec/IKE) nằm trong tầm tay của những kẻ tấn công quốc gia. Buộc di chuyển toàn ngành sang các nhóm lớn hơn và đường cong elip DH.
• Lucky Thirteen (2013) — tấn công thời gian vào chế độ CBC. Sửa lỗi cấp thư viện trong OpenSSL và các lỗi khác.

Mỗi cuộc tấn công đều thắt chặt giao thức. Theo TLS 1.3, hầu hết các lớp này đều không thể thực hiện được theo thiết kế.

Cơ quan cấp chứng chỉ và vấn đề tin cậy

TLS xác thực dựa trên Cơ quan cấp chứng chỉ (CA) mà trình duyệt tin cậy theo mặc định. Ba thị phần hàng đầu kể từ năm 2019: IdenTrust, DigiCert và Sectigo. Let's Encrypt — CA tự động, miễn phí ra mắt vào năm 2016 — đã thúc đẩy sự thúc đẩy áp dụng lớn nhất trong lịch sử HTTPS.

Điểm yếu về cấu trúc: bất kỳ CA đáng tin cậy nào cũng có thể cấp chứng chỉ cho bất kỳ miền nào. CA bị xâm phạm hoặc bị ép buộc có thể tạo ra chứng chỉ hợp lệ cho ngân hàng của bạn. Nhật ký Certificate Transparency (CT) - bản ghi chỉ bổ sung công khai của mọi chứng chỉ từng được cấp - đã được giới thiệu để phát hiện điều này. Các trình duyệt hiện yêu cầu chứng chỉ phải xuất hiện trong nhật ký CT trước khi chấp nhận chúng.

Diễn đàn CA/Trình duyệt đã phê duyệt việc giảm hiệu lực tối đa của chứng chỉ xuống 47 ngày vào năm 2029, thắt chặt khoảng thời gian mà CA bị xâm nhập có thể gây thiệt hại.

Encrypted Client Hello (ECH)

Một điều rò rỉ TLS cổ điển: trường Chỉ báo tên máy chủ (SNI) trong ClientHello, thông báo cho máy chủ biết tên máy chủ bạn đang kết nối để máy chủ có thể xuất trình chứng chỉ phù hợp. SNI là văn bản thuần túy, do đó, những người quan sát mạng sẽ tìm hiểu mọi miền bạn truy cập ngay cả khi phần còn lại của kết nối đã được mã hóa.

Encrypted Client Hello (ECH) — một sự phát triển của đề xuất ESNI trước đó — mã hóa SNI bằng khóa chung mà đích xuất bản qua DNS. Cloudflare và Apple đã hỗ trợ ECH; Firefox và Chrome đã triển khai tính năng này cho đến năm 2024 và đang tiến tới chế độ bật mặc định. Đối với người dùng trên các mạng thù địch, ECH là bản nâng cấp quyền riêng tư tiếp theo sau HTTPS phổ biến.

DTLS — TLS cho UDP

DTLS (Datagram TLS) là biến thể TLS hoạt động trên UDP. Nó hỗ trợ WebRTC (video/giọng nói của trình duyệt), bảo mật cơ bản của QUIC và một số giao thức VPN. DTLS 1.3 (RFC 9147, 2022) phù hợp với quá trình hiện đại hóa mật mã và bắt tay của TLS 1.3.

Trao đổi khóa hậu lượng tử TLS

Diffie-Hellman — cơ sở của bảo mật chuyển tiếp TLS — có thể bị phá vỡ bởi một máy tính lượng tử đủ lớn. Cách khắc phục là trao đổi khóa kết hợp kết hợp thuật toán cổ điển (X25519) với một ứng cử viên hậu lượng tử (thường là ML-KEM-768, trước đây gọi là Kyber).

Chrome đã bật kết hợp X25519MLKEM768 theo mặc định vào cuối năm 2024. Cloudflare, Apple iCloud và một số nhà cung cấp VPN đã vận chuyển nó đến hết năm 2025. Việc triển khai rộng rãi hơn sẽ bảo vệ lưu lượng truy cập ngày nay khỏi "thu hoạch" bây giờ, giải mã sau" cuộc tấn công — một đối thủ ghi lại lưu lượng truy cập được mã hóa ngày hôm nay, chờ máy tính lượng tử, sau đó giải mã trong lịch sử.

Cách xác minh TLS mà trình duyệt của bạn thực sự đang sử dụng

Nhấp vào ổ khóa trên thanh địa chỉ của trình duyệt. Các trình duyệt hiện đại hiển thị phiên bản giao thức, bộ mật mã và chi tiết chứng chỉ. Nếu bạn thấy TLS 1.0 hoặc 1.1 thì trang web đó đang sử dụng các cấu hình không được dùng nữa. Nếu bạn thấy TLS 1.3 với AES-256-GCM hoặc ChaCha20-Poly1305 thì bạn đang sử dụng tiền điện tử hiện đại.

Công nghệ đồng hành HTTPS — có trong trình giải thích HTTPS của chúng tôi — là công nghệ bao bọc web trong TLS. Hai thuật ngữ này thường được sử dụng thay thế cho nhau một cách thông tục, nhưng TLS là giao thức mã hóa cơ bản; HTTPS chỉ là HTTP-over-TLS.