SSL/TLS — định nghĩa, giao thức và nguyên lý hoạt động của mã hóa

SSL/TLS là gì?

SSL (Secure Sockets Layer) là một giao thức được Netscape phát triển vào năm 1995 để bảo vệ lưu lượng web. Phiên bản đầu tiên SSL 1.0 chưa bao giờ được công bố; SSL 2.0 (1995) và SSL 3.0 (1996) được sử dụng cho đến đầu những năm 2000 nhưng chứa các lỗ hổng nghiêm trọng. SSL được kế thừa bởi TLS (Transport Layer Security) — một phiên bản cải tiến được IETF chuẩn hóa. TLS 1.0 (1999) dựa trên SSL 3.0, trong khi các phiên bản sau TLS 1.1 (2006), TLS 1.2 (2008) và TLS 1.3 (2018) dần dần tách khỏi kiến trúc ban đầu, thêm các thuật toán mã hóa mới và sửa lỗ hổng. Ngày nay, SSL được coi là lỗi thời và tất cả các hệ thống hiện đại đều sử dụng TLS, mặc dù cả hai giao thức thường được nhắc đến cùng nhau như SSL/TLS theo thói quen.

Lịch sử của giao thức

Lịch sử của SSL/TLS bắt đầu với nhu cầu truyền dữ liệu an toàn trên web sơ khai. Năm 1994, Netscape đã phát triển SSL 1.0 cho trình duyệt Navigator của mình, nhưng giao thức này chưa bao giờ được công bố do các vấn đề bảo mật nghiêm trọng. SSL 2.0 được phát hành vào năm 1995 và được sử dụng thực tế, nhưng chứa nhiều lỗ hổng: thiếu bảo vệ chống tấn công Man-in-the-Middle, thuật toán mã hóa yếu và dễ bị tấn công cắt ngắn. SSL 3.0 (1996) đã sửa hầu hết các vấn đề, nhưng đến năm 2014, lỗ hổng POODLE được phát hiện, sau đó IETF chính thức tuyên bố tất cả các phiên bản SSL đều lỗi thời. TLS 1.0–1.3 đã cải thiện dần dần độ mạnh mật mã, hiệu suất và quyền riêng tư, với TLS 1.3 giảm bắt tay từ hai vòng xuống một vòng — điều cực kỳ quan trọng cho các ứng dụng di động có kết nối không ổn định.

Bắt tay SSL/TLS hoạt động như thế nào

Bắt tay (Handshake) là quá trình thiết lập kết nối an toàn giữa máy khách và máy chủ. Nó bao gồm một số bước tuần tự trong đó các bên thống nhất về phiên bản giao thức, chọn thuật toán mã hóa, trao đổi khóa và xác thực lẫn nhau. Trong TLS 1.3, bắt tay chỉ mất một vòng mạng (1-RTT), trong khi TLS 1.2 cần hai vòng (2-RTT).

Bước đầu tiên là máy khách gửi ClientHello — một thông điệp chứa danh sách các phiên bản TLS được hỗ trợ, bộ mã hóa và một số ngẫu nhiên. Máy chủ trả lời bằng ServerHello với phiên bản và bộ mã hóa đã chọn, chứng chỉ X.509 và chữ ký số. Máy khách xác minh chứng chỉ qua chuỗi cơ quan cấp chứng chỉ (CA), tạo khóa phiên và gửi nó được mã hóa bằng khóa công khai của máy chủ từ chứng chỉ. Sau khi máy chủ xác nhận, việc truyền dữ liệu an toàn bắt đầu. Toàn bộ quá trình bắt tay mất 1–3 mili giây trên các thiết bị hiện đại, khiến nó không thể nhận thấy đối với người dùng.

Chứng chỉ X.509 và chuỗi tin cậy

Nền tảng của xác thực TLS là Cơ sở hạ tầng khóa công khai (PKI) được xây dựng trên các chứng chỉ định dạng X.509. Mỗi chứng chỉ chứa: tên miền (Common Name hoặc Subject Alternative Name), khóa công khai của máy chủ, tên nhà phát hành (Cơ quan cấp chứng chỉ), ngày hết hạn và chữ ký số của CA. Máy khách xác minh chứng chỉ của máy chủ dọc theo chuỗi tin cậy: từ chứng chỉ máy chủ đến CA gốc, chứng chỉ của CA này được nhúng trong hệ điều hành. Trên thiết bị Android, chứng chỉ gốc được lưu trữ trong kho khóa hệ thống, được cập nhật qua Google Play Services; trên iOS — qua các bản cập nhật iOS. Nếu bất kỳ mắt xích nào trong chuỗi bị đứt (chứng chỉ hết hạn, không khớp tên miền, CA không xác định), máy khách sẽ ngắt kết nối. Đối với chứng chỉ tự ký (được sử dụng trong phát triển), cần có sự tin cậy rõ ràng — trên Android qua Network Security Config, trên iOS qua NSExceptionDomains trong Info.plist. Quá trình xác thực chuỗi chứng chỉ cũng bao gồm kiểm tra trạng thái thu hồi qua CRL (Danh sách thu hồi chứng chỉ) hoặc OCSP (Giao thức trạng thái chứng chỉ trực tuyến), mặc dù trên thiết bị di động, các yêu cầu OCSP thường bị bỏ qua để tăng tốc kết nối — đây là sự đánh đổi giữa bảo mật và hiệu suất mà các kiến trúc sư cần cân nhắc.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()