SSL/TLS: các khái niệm chính và giao thức trong phát triển

SSL/TLS là gì?

SSL (Secure Sockets Layer) và TLS (Transport Layer Security) là các giao thức mật mã đảm bảo truyền dữ liệu an toàn qua mạng. SSL, được phát triển bởi Netscape vào những năm 1990, được coi là lỗi thời sau phiên bản 3.0 do các lỗ hổng POODLE và BEAST. TLS, kế thừa của nó, đã trải qua các phiên bản 1.0, 1.1, 1.2 và 1.3 — chỉ TLS 1.2 và TLS 1.3 được coi là hiện hành. Tất cả các nền tảng di động hiện đại đều yêu cầu TLS cho kết nối mạng, và App Store cùng Google Play kiểm tra điều này trong quá trình xét duyệt.

Tại sao cần TLS cho ứng dụng di động

Nếu không có TLS, lưu lượng truy cập giữa ứng dụng và máy chủ được truyền dưới dạng văn bản thuần túy — bất kỳ ai trên cùng mạng Wi-Fi đều có thể chặn tên đăng nhập, mật khẩu, token và dữ liệu cá nhân của người dùng bằng Wireshark hoặc tcpdump. TLS mã hóa tất cả dữ liệu được truyền (mã hóa ở lớp truyền tải) và xác minh tính xác thực của máy chủ thông qua chuỗi chứng chỉ X.509. Theo IETF (2018), TLS 1.3 chỉ sử dụng các bộ mã hóa AEAD hiện đại (AES-GCM, ChaCha20-Poly1305), loại trừ các thuật toán lỗi thời như RC4 và 3DES.

HTTPS và TLS

HTTPS (HTTP Secure) là HTTP qua TLS. Khi ứng dụng di động thực hiện yêu cầu qua https://, trước tiên nó thiết lập kết nối TLS với máy chủ, sau đó truyền các tiêu đề HTTP và nội dung yêu cầu qua kênh đã mã hóa. Nếu không có HTTPS, không có API nghiêm túc nào nên hoạt động — đó là vệ sinh bảo mật cơ bản. Theo OWASP (2026), các kết nối không an toàn nằm trong top 3 lỗ hổng của ứng dụng di động.

Cách thức hoạt động của TLS Handshake

TLS 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ủ. Các bên thương lượng phiên bản giao thức, chọn bộ mật mã (cipher suite), trao đổi khóa thông qua mật mã bất đối xứng và xác minh chứng chỉ. Trong TLS 1.2, quá trình bắt tay yêu cầu 2 Round Trip Time (2 RTT): máy khách → máy chủ với ClientHello, máy chủ → máy khách với ServerHello và Certificate, sau đó là các thông báo Finished cuối cùng. TLS 1.3 giảm quá trình này xuống còn 1 RTT.

Các giai đoạn chi tiết của bắt tay TLS 1.2

Giai đoạn đầu tiên: ClientHello — máy khách gửi các phiên bản TLS được hỗ trợ, danh sách các bộ mật mã và một số ngẫu nhiên. Máy chủ trả lời bằng ServerHello, chọn phiên bản và bộ mật mã, gửi chứng chỉ X.509 (Certificate) và thông báo ServerHelloDone. Máy khách xác minh chứng chỉ thông qua chuỗi các tổ chức chứng thực (CA) đáng tin cậy, tạo pre-master secret, mã hóa nó bằng khóa công khai từ chứng chỉ và gửi đến máy chủ trong ClientKeyExchange. Sau đó, cả hai bên tạo khóa phiên và trao đổi các thông báo ChangeCipherSpec và Finished. Từ thời điểm này, tất cả dữ liệu được mã hóa đối xứng.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Ví dụ xử lý URLAuthenticationChallenge trên iOS qua URLSessionDelegate. Phương thức này được gọi trong mỗi TLS Handshake, cho phép ứng dụng thực hiện xác minh chứng chỉ máy chủ tùy chỉnh. Để sử dụng trong sản xuất, hãy thêm xác minh chứng chỉ qua SecTrustEvaluateWithError và so sánh với dấu vân tay đã lưu trước — chỉ sau đó gọi useCredential.

TLS 1.2 so với TLS 1.3

TLS 1.3 (RFC 8446, 2018) là bản cập nhật giao thức lớn đầu tiên sau 10 năm. Các cải tiến chính: giảm bắt tay xuống 1 RTT (0 RTT cho kết nối lặp lại), loại bỏ các bộ mật mã lỗi thời (trao đổi khóa RSA, chế độ CBC), bắt buộc Perfect Forward Secrecy (PFS) và bảo vệ khỏi các cuộc tấn công hạ cấp qua signed transcript. Theo Qualys SSL Labs (2026), TLS 1.3 cung cấp khả năng bảo vệ ngay cả khi khóa máy chủ dài hạn bị xâm phạm nhờ PFS.

0-RTT (Zero Round Trip Time) là một tính năng của TLS 1.3 cho phép máy khách gửi dữ liệu ngay lập tức cùng với ClientHello trong kết nối lặp lại qua PSK (Pre-Shared Key). Điều này tăng tốc tải các màn hình tiếp theo trong ứng dụng di động, đặc biệt với các yêu cầu thường xuyên đến cùng một máy chủ. Tuy nhiên, dữ liệu 0-RTT không được bảo vệ khỏi các cuộc tấn công phát lại — nó có thể bị chặn và gửi lại. Chỉ sử dụng 0-RTT cho các yêu cầu đẳng năng (GET, PUT) không có tác dụng phụ.

TLS trên iOS: App Transport Security

App Transport Security (ATS) là cơ chế của Apple yêu cầu kết nối HTTPS với TLS 1.2 trở lên, được bật theo mặc định từ iOS 9. ATS chặn tất cả các kết nối HTTP và HTTPS với TLS dưới 1.2. Nhà phát triển có thể cấu hình ngoại lệ trong Info.plist qua NSAppTransportSecurity cho các tên miền cụ thể, nhưng Apple khuyến nghị giảm thiểu ngoại lệ và sử dụng HTTPS ở mọi nơi. Vi phạm yêu cầu ATS là lý do từ chối ứng dụng trong quá trình xét duyệt App Store.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

Cấu hình ATS trong Info.plist. NSAllowsArbitraryLoads được đặt thành false — tất cả các kết nối phải sử dụng HTTPS. Cho tên miền cdn.example.com, phiên bản TLS tối thiểu 1.2 được chỉ định, NSAllowsLocalNetworking=true cho phép HTTP cho mạng cục bộ (hữu ích cho máy chủ phát triển). Apple khuyến nghị mạnh mẽ không bật NSAllowsArbitraryLoads mà không có NSExceptionDomains — đây nên là một ngoại lệ, không phải quy tắc chung.

TLS trên Android: Network Security Config

Network Security Config là cơ chế của Android để cấu hình HTTPS và TLS mà không cần thay đổi mã Java/Kotlin. Cấu hình được chỉ định trong tệp network_security_config.xml và được kết nối trong AndroidManifest qua thuộc tính android:networkSecurityConfig. Hỗ trợ cấu hình chứng chỉ đáng tin cậy (CA người dùng và hệ thống), Certificate Pinning, vô hiệu hóa HTTP văn bản thuần túy, ghi đè gỡ lỗi và chuyển hướng lưu lượng.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config cho Android. Base-config chặn lưu lượng văn bản thuần túy và chỉ tin tưởng chứng chỉ CA hệ thống (không có chứng chỉ người dùng — bảo vệ khỏi việc cài đặt chứng chỉ MitM bởi người dùng). Domain-config cho api.example.com chứa pin-set với dấu vân tay SHA-256 của chứng chỉ. Nếu chứng chỉ máy chủ thay đổi trước ngày hết hạn được chỉ định, kết nối sẽ bị từ chối — đây là hình thức nghiêm ngặt của Certificate Pinning.

Certificate Pinning và bảo mật

Certificate Pinning là kỹ thuật cố định chứng chỉ hoặc khóa công khai của máy chủ trong mã ứng dụng. Trong mỗi TLS Handshake, máy khách so sánh chứng chỉ máy chủ với dấu vân tay đã lưu trước (băm SHA-256). Ngay cả khi kẻ tấn công có được chứng chỉ CA đáng tin cậy hoặc xâm phạm tổ chức chứng thực, chúng không thể thực hiện tấn công MitM — ứng dụng kiểm tra dấu vân tay cụ thể, không phải chuỗi CA. Điều này đặc biệt quan trọng đối với ứng dụng tài chính và ứng dụng xử lý dữ liệu nhạy cảm.

Rủi ro và giải pháp thay thế cho Pinning

Certificate Pinning đòi hỏi thận trọng: khi chứng chỉ máy chủ thay đổi, tất cả phiên bản cũ của ứng dụng sẽ ngừng kết nối. Nên lưu trữ nhiều dấu vân tay dự phòng (chính + dự phòng), chỉ định ngày hết hạn pin-set và triển khai cơ chế dự phòng qua xác minh CA tiêu chuẩn. Một giải pháp thay thế là Trust On First Use (TOFU), nơi ứng dụng ghi nhớ chứng chỉ ở lần kết nối đầu tiên và cảnh báo người dùng khi nó thay đổi. Theo OWASP (2026), việc thiếu Certificate Pinning nằm trong top 3 lỗ hổng ứng dụng di động (M3: Giao tiếp không an toàn).

Triển khai Pinning trong Alamofire

Trong Alamofire 5+, Certificate Pinning được cấu hình qua ServerTrustManager với PinnedCertificatesTrustEvaluator (kiểm tra toàn bộ chứng chỉ) hoặc PublicKeysTrustEvaluator (chỉ khóa công khai). Khóa công khai được ưu tiên hơn — nó không thay đổi khi gia hạn chứng chỉ với cùng CA. Tạo ServerTrustManager với từ điển [host: evaluator], chuyển nó cho Session và sử dụng cho tất cả yêu cầu đến API được bảo vệ.