Giải ngố WWW – Phần 4: 3 điều tối quan trọng về việc tạo và sử dụng Certificate trong quá trình truy cập HTTPS Website

Còn nhớ cái đoạn khi tôi nói “…Server gửi Response chứa Server Certificate. Certificate sẽ bao gồm cái Public Key của Server…” thuộc Mục #3 Điều gì xảy ra khi truy cập HTTPS website trong Giải ngố WWW – Phần 3: HTTPS có gì ngon hơn HTTP không? Cách tôi nói đơn giản như trên có thể khiến bạn hiểu nhầm là việc này dễ ăn, không cần bàn cãi gì thêm. Tuy nhiên, trên thực tế ở điểm này, khi xem xét chi tiết bạn sẽ thấy việc tạo và sử dụng cái Certificate đầy vất vả này chính là “linh hồn” cho quá trình hoạt động của HTTPS.

#1. Đào đâu ra mấy cái Certificate này

#1.1 Public Key Infrastructure – PKI

Trước khi bàn về Certificate tôi cần nói nhanh qua về Public Key Infrastructure – PKI (tạm dịch là hạ tầng khóa công cộng). PKI là nhóm công nghệ dùng để yêu cầu, tạo, quản lý, lưu trữ, phân phối và thu hồi các Digital Certificate (chứng chỉ số). Và như tôi đã nhai đi nhai lại rất nhiều lần, Asymetric Encryption sẽ hoạt động dựa trên các Certificate này để cung cấp giải pháp như bảo vệ email và Internet với SSL/TLS.

Mục đích cơ bản của PKI là cho phép 2 người hoặc tổ chức liên lạc với nhau một cách bảo mật mà không cần phải quen biết trước. Nghĩa là thực hiện liên lạc một cách bảo mật trên nền tảng không bảo mật như Internet.

Ví dụ như khi bạn thực hiện một phiên kết nối bảo mật đến Tiki, Web Server bên đó sẽ gửi cho bạn 1 cái Certificate với hàm ý chứng minh “Ê ku, anh là Tiki chính chủ nè”. Vấn đề là Web Server lấy cái Certificate này ở đâu ra?

Nhắc lại chỗ này tí để bạn dễ hình dung vấn đề. Trong cái Certificate này sẽ có chứa Public Key trong cặp Public/Private Key do Web Server Tiki tạo ra. Với việc lấy cái Certificate có chứa Public Key này, bạn sẽ có thể thực hiện liên lạc bảo mật với ông Web Server đã khởi tạo cặp Public/Private Key nói trên.

Góc trợ giúp: Nếu chưa biết tạo Public/Private Key thì bạn xem thêm nội dung Giải ngố Pretty Good Privacy (PGP) – Phần 3: Sử dụng PGP trong xác thực và chữ ký số như thế nào

Với nguyên lý hoạt động trình bày ở Giải ngố WWW – Phần 3: HTTPS có gì ngon hơn HTTP, bạn thấy đấy, mọi thứ có vẻ rất rõ ràng và chuẩn cmn mực. Tuy nhiên, đời không như mơ, lúc nào mà chẳng có thằng muốn chọc ngoáy vô nồi cơm của người khác.

Tạm gác đi một số yếu tố kỹ thuật phức tạp, giả sử Mr. X có khả năng dựng lên một trang web có giao diện tương tự Tiki, và cũng khởi tạo cặp Public/Private Key rồi gửi cho bạn cái Certificate và dõng dạc tuyên bố “Ê, đây mới là Tiki chính chủ nè”.

Thế trong hoàn cảnh éo le cuộc tình này bạn biết chọn ai? Rất may cho bạn, trong tình huống này bạn sẽ có quyền trợ giúp từ một nhân vật có tên gọi là Certificate Authority.

#1.2 Certificate Authority

Certificate Authority – CA (tạm hiểu là cơ quan cấp chứng chỉ) sẽ có trách nhiệm phát hành, quản lý, xác thực và thu hồi các Certificate. Tùy theo mục đích sử dụng, bạn sẽ có thể gặp các loại:

– Public CA: cung cấp dịch vụ cho cộng đồng ví dụ như DigiCert, Sectigo, GoDaddy,…

– Private CA: cung cấp dịch vụ trong các mạng riêng

Trong phạm vi bài viết này, tôi sẽ tập trung vào nhóm Public CA. CA này sẽ đóng vai trò như quan tòa để xác định cho bạn đâu là Tiki chính chủ.

Và theo logic thông thường, đến đây, một câu hỏi khác sẽ xuất hiện: “Sao biết thằng CA này đáng tin? Lỡ nó là người nhà Mr. X thì sao?”. Đó sẽ là vấn đề tôi sẽ đề cập ngay sau đây.

#2. Mô hình xác thực CA và Certificate

#2.1 Làm sao biết ông CA nào đáng tin

Để trả lời câu hỏi này, mô hình xác thực phổ biến nhất được các giang hồ sử dụng là Hierarchical Trust Model (hay còn gọi là Centralized Trust Model). Mô hình này kiểu như bán hàng đa cấp ấy, lúc này sẽ có “Big Boss” và mấy thằng đệ cấp dưới của nó. Cụ thể CA sẽ phát hành cái Root Certificate để xác minh chính nó trước khi xác thực cho mấy thằng đệ Intermediate/Child CA. Sau đó Intermediate/Child CA sẽ phát hành Certificate cho Web Server. Trường hợp CA quy mô nhỏ thì nó sẽ vừa làm sếp vừa làm lính thôi.

Đọc lại cái chỗ “…phát hành cái Root Certificate để xác minh chính nó…” tôi nghĩ chắc bạn sẽ phụt ngay ra câu “Thế éo nào!”. Vâng thực ra, cái Root Certificate là cơ sở để thực hiện công việc xác minh và phát hành Certificate đến Web Server thôi. Để tin tưởng được CA bạn sẽ dựa vào các yếu tố khác tương tự như khi bạn tin tưởng mua hàng trên Amazon. Điểm mấu chốt để có thể tin tưởng CA ở đây là:

– CA thực hiện dịch vụ kinh doanh liên quan đến Certificate nên sẽ phải bị ràng buộc về mặt pháp lý về sản phẩm dịch vụ của mình.

– Việc cung cấp dịch vụ xác thực và phát hành Certificate là cần câu cơm của CA nên khả năng cấu kết với Mr. X lừa ăn vài trăm Mỹ kim của bạn để rồi dính phốt đóng cửa kinh doanh là rất thấp.

Đấy chính là đáp áp cho câu hỏi “Sao biết thằng CA này đáng tin? Lỡ nó là người nhà Mr. X thì sao?” (hiển nhiên cũng cần kiểm tra thông tin của ông CA trước khi làm ăn chứ không phải cứ nhắm mắt vơ vào mấy ông giá rẻ).

Lưu ý: CA sẽ phải làm việc với Web Browser Developers để đưa các các thể loại trong dòng họ Root Certificate này vào Web Browser.

#2.2 Xác thực Certificate

Trong ví dụ với Tiki nói trên, công việc xác thực cấp Certificate sẽ được tiến hành như sau:

– Tiki và Mr. X sẽ tạo một Certificate Signing Request – CSR và gửi đến một ông CA nào đó;

– Ông CA thực hiện kiểm tra thông tin để xác nhận CSR có chính xác hay không

– CA (DigiCert theo như thông tin hiện tại) công bố Certificate của Tiki chính chủ cho bạn (và đòi Tiki tiền cấp Certificate)

Lưu ý:

(*) Certificate Signing Request bao gồm thông tin: mục đích của Certificate, website, public key và thông tin về đối tượng đang tạo CSR. Thông thường CSR sẽ được định dạng theo template chuẩn Public-Key Cryptography Standards (PKCS) #10 của các CA

(**) Ở bước CA kiểm tra thông tin xác nhận CSR ngoài cái Domain Validated – DV (Xác thực tên miền) phổ biến còn có thể liên quan đến Organization Validation – OV và Extended Validation – EV. Cái này tôi thấy khá hay nên có thể nói riêng vào dịp khác

#3. Thu hồi và sử dụng Certificate

#3.1 Thu hồi Certificate

Mỗi chứng chỉ sẽ có thời gian hiệu lực nhất định, tuy nhiên vẫn có trường hợp Certificate bị thu hồi (Revoke) trước thời hạn. Lý do thì có nhiều nhưng có 2 trường hợp bạn cần đặc biệt lưu ý:

– Thông tin về Private Key tương ứng của Certificate bằng cách nào đó đã thành tài sản công cộng thay vì chỉ mỗi chủ nó sở hữu như thiết kế;

– CA làm ăn bẩn bựa bị rò rỉ thông tin hoặc bị hack làm ảnh hưởng đến độ tin cậy của Certificate.

Theo quy trình chuẩn, CA sẽ sử dụng Certificate Revocation Lists – CRLs để thu hồi Certificate (tôi sẽ nói kỹ hơn bên dưới). Tuy nhiên, bạn cũng nên lưu tâm đến Private Key của mình và tình trạng của CA đang sử dụng để còn biết đường mà chữa cháy kịp thời.

#3.2 Sử dụng Certificate

Quay lại thời điểm Web Server gửi Certificate (do CA cấp) đến Client Browser để thiết lập SSL/TLS. Lúc này, theo nguyên lý chung, Client Browser sẽ phải truy vấn đến CA để kiểm tra xem cái Certificate này có nằm trong diện thu hồi CRLs không.

Vì CA phải quản lý một lượng lớn Certificate đã phát hành và mỗi Certificate tương ứng với một Website có thể truy cập bởi nhiều Client Browser cùng lúc. Do vậy, nếu thằng Client Browser nào cũng hỏi thì CA sẽ banh sớm. Để khắc phục vấn đề này, sau lần hỏi đầu tiên, Client Browser có thể lưu Cache để dùng cho các lần sau để giảm thời gian chờ phản hồi cũng như hạn chế việc truy vấn đến CA quá nhiều lần.

Với cách trên, hiển nhiên Client Browser phải có thông tin kiểm soát hạn sử dụng Cache để đảm bảo việc cập nhật CRLs đồng bộ với CA. Đây là khoảng thời gian chết nguy hiểm khiến Client đối mặt với rủi ro tin sai Certificate.

Do vậy, một phương án xử lý theo thời gian thực có tên gọi là Online Certificate Status Protocol – OCSP được sử dụng thay thế. Để tránh việc hỏi CA liên tục, OCSP được cải tiến với giải pháp có tên gọi OSCP stapling. Theo cách này, CA sẽ “kẹp” thêm một cái “timestamp” (tạm dịch là nhãn thời gian) vào các OSCP Response và ký với Digital Signature trước khi gửi đi qua Web Server. Sau đó ông Web Server sẽ chuyển Certificate kèm theo cái Timestamped OCSP Respond nói trên đến Client trong quá trình thiết lập SSL/TLS.

Phù! Thế là bạn biết cách để xử lý các việc xác thực, tạo và gửi Certificate trong trong quá trình thiết lập SSL/TLS cho HTTPS rồi đấy. Và nhắc lại điều tôi đã nói trong phần trước, đừng nôn nóng khi Browser của bạn phản hồi hơi chậm, có cả đống thứ đang phải xử lý và việc của bạn chỉ đơn giản là ngồi chờ thôi mà!