Certificate Pinning: nó là gì, các phương pháp gắn kết chứng chỉ và cách triển khai

Ưu điểm và nhược điểm của Certificate Pinning

Certificate Pinning tăng cường đáng kể bảo mật ứng dụng di động nhưng đặt gánh nặng vận hành lên nhóm phát triển. Điều quan trọng là cân nhắc lợi ích bảo mật so với rủi ro chặn kết nối do triển khai không đúng cách.

Ưu điểm chính là bảo vệ chống lại các cuộc tấn công Man-in-the-Middle, bao gồm các trường hợp xâm phạm CA. Pinning làm cho các chứng chỉ giả do kẻ tấn công phát hành trở nên vô dụng: ngay cả khi CA đã ký một chứng chỉ giả mạo, ứng dụng sẽ từ chối nó. Một lợi ích bổ sung là bảo vệ chống lại các máy chủ proxy doanh nghiệp thay thế chứng chỉ để kiểm tra lưu lượng. Theo Google Security Blog (2023), các ứng dụng có pinning có khả năng bị xâm phạm thông qua chặn lưu lượng thấp hơn 86% so với các ứng dụng chỉ sử dụng kiểm tra TLS tiêu chuẩn.

Nhược điểm chính của pinning là rủi ro tự chặn: nếu chứng chỉ máy chủ thay đổi (gia hạn, thay đổi nhà cung cấp, luân chuyển khóa) trước khi bản cập nhật ứng dụng được phát hành, người dùng mất quyền truy cập vào máy chủ. Nhược điểm bổ sung: độ phức tạp gỡ lỗi (mọi thay đổi cấu hình đều yêu cầu cập nhật pin), tăng kích thước APK thêm 5–15 KB khi sử dụng TrustKit và không thể khôi phục thay đổi nhanh chóng mà không có bản phát hành mới. Để giảm thiểu rủi ro, các pin dự phòng, luân chuyển tự động 2–3 tháng một lần và thời gian gia hạn được sử dụng, trong đó ứng dụng chấp nhận cả chứng chỉ cũ và mới. Cũng cần xem xét rằng trong quá trình phát triển với pinning được bật, các công cụ proxy (Burp Suite, Charles) không thể được sử dụng để gỡ lỗi các yêu cầu mạng — cho các bản dựng phát triển, pinning phải được tắt thông qua cờ BuildConfig.DEBUG và kiểm thử QA phải được thực hiện trên chữ ký phát hành với bảo vệ được bật. Một số nhóm sử dụng tên miền staging với chứng chỉ pinning riêng cho môi trường phát triển để duy trì bảo vệ ngay cả trong quá trình phát triển.

Triển khai Certificate Pinning trên Android

Hãy xem xét một ví dụ về triển khai Certificate Pinning trên Android sử dụng OkHttp — thư viện tiêu chuẩn cho các yêu cầu mạng. OkHttp cung cấp CertificatePinner tích hợp chấp nhận các hàm băm SHA-256 của khóa công khai.

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .add(
        "api.example.com",
        "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Trong mã trên, chúng tôi thêm hai pin cho tên miền api.example.com: pin chính (chứng chỉ hiện tại) và pin dự phòng (cho luân chuyển). OkHttp tự động xác minh rằng chứng chỉ của máy chủ khớp với một trong các dấu vân tay SHA-256 được chỉ định. Để lấy dấu vân tay SHA-256 của chứng chỉ, sử dụng lệnh: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Điều quan trọng là lưu trữ dấu vân tay không phải dưới dạng văn bản thuần trong mã, mà được mã hóa hoặc làm rối: phân tích tĩnh MobSF dễ dàng tìm thấy các chuỗi SHA-256 thô trong tệp DEX. Nên lưu trữ pin trong tài nguyên res/raw, được mã hóa qua AES và giải mã khi khởi động ứng dụng thông qua mã gốc (NDK/JNI).

Triển khai trên iOS qua TrustKit

Trên iOS, công cụ chính cho Certificate Pinning là thư viện mã nguồn mở TrustKit. Không giống như OkHttp, TrustKit được cấu hình khai báo thông qua Info.plist, cho phép thay đổi pin mà không cần biên dịch lại ứng dụng. Cấu hình bao gồm một từ điển với các tên miền và một mảng các dấu vân tay SHA-256 của khóa công khai. TrustKit tự động chặn các yêu cầu NSURLSession và xác minh chứng chỉ trước khi bắt đầu truyền dữ liệu. Một tính năng quan trọng của TrustKit là hỗ trợ báo cáo xác thực pin: thư viện có thể gửi báo cáo đến một điểm cuối được chỉ định khi xảy ra không khớp pin, cho phép phản ứng nhanh với các bất thường của chứng chỉ. Apple cũng cung cấp cơ chế gốc NSPinnedDomains trong Info.plist từ iOS 14, nhưng TrustKit vẫn là lựa chọn ưa thích do cấu hình linh hoạt hơn, hỗ trợ báo cáo và khả năng trao đổi pin nóng mà không cần cập nhật hệ điều hành. Điều quan trọng cần lưu ý là TrustKit tích hợp với URLSession thông qua delegate didReceiveChallenge, trả về .performDefaultHandling khi xác thực pin thành công và .cancelAuthenticationChallenge khi không khớp. Để giám sát các báo cáo xác thực pin, nên thiết lập một điểm cuối riêng phân tích tần suất lỗi: nếu số lượng báo cáo tăng mạnh — điều này có thể chỉ ra một cuộc tấn công MitM hoặc chứng chỉ sắp hết hạn yêu cầu cập nhật pin ngay lập tức.