Bài viết được lấy từ https://truongphuoc.wordpress.com/2024/10/02/tan-man-ve-ssl-tls/

Bài viết này gồm hơn 4000 chữ, hãy đọc trên máy tính để bảo vệ đôi mắt của bạn.

Mở bài

Trong các bài trước, chúng ta đã cùng đi qua từ hệ mật đối xứng, bất đối xứng tới chữ ký điện tử, trao đổi khóa an toàn và hàm băm mật mã. Trong bài viết này chúng ta hãy cùng tìm hiểu về SSL/TLS để làm rõ, sâu sắc hơn về cách thức hai thực thể giao tiếp an toàn trên internet nhé. Bài này là đỉnh cao trong series này rồi, tất cả các bài trước nhằm cung cấp kiến thức cần thiết để phục vụ cho bài này đó.

Để đọc hiểu rõ bài này các bạn cần có kiến thức về mật mã học, khóa đối xứng, bất đối xứng, ký điện tử, trao đổi khóa an toàn và hàm băm mật mã. Tất cả các kiến thức này mình đã giới thiệu ở các bài trước trong series, nếu các bạn đã nắm được các kiến thức trên thì quá tốt rồi, bằng không thì các bạn nên quay trở lại để hiểu rõ những kiến thức trên, sau đó quy lại đọc bài này sau cũng chưa muộn nha.

SSL/TLS là gì?

SSL (Secure Sockets Layer) và TLS (Transport Layer Security) là các giao thức được sử dụng để bảo vệ dữ liệu được truyền qua mạng internet. Nó như là một lớp để bảo vệ thông tin trên môi trường internet. Chúng ta sẽ cùng tìm hiểu chúng bảo vệ thông tin của chúng ta như thế nào, bằng cơ chế nào ngay dưới đây thôi, nhưng trước hết hãy xem xét đôi chút về lịch sử.

Đôi dòng lịch sử

Để hiểu thêm về tên gọi, sự thay đổi tên gọi của SSL và TLS, chúng ta cùng ngược dòng thời gian để quay trở về quá khứ, tìm hiểu đôi chút lịch sử của hai ông thần này nha.

• Năm 1995, SSL 1.0 được phát triển bởi Netscape Communications, nhưng chưa bao giờ được công bố do các vấn đề bảo mật nghiêm trọng.
• Cũng cùng năm 1995, SSL 2.0 được công bố, tuy nhiên nó vẫn có nhiều lỗ hổng về bảo mật.
• Năm 1996, SSL 3.0 được phát hành, nó đã được Netscape cải tiến để khắc phục các lỗ hổng của SSL 2.0. Đây là bản được sử dụng rộng rãi và là cơ sở cho sự phát triển của TLS.
• Kết thúc triều đại SSL
• Năm 1999, TLS 1.0 được Internet Engineering Task Force (IETF) phát triển dựa trên SSL 3.0 . TLS Bảo mật tốt hơn và hỗ trợ nhiều thuật toán mã hóa hơn. Thay đổi nhà phát triển dẫn tới thanh đổi tên luôn đó nha.
• Năm 2006, ra mắt TLS 1.1, cải tiến từ TLS 1.0 với các biện pháp bảo mật tốt hơn, như thêm nonce cho mỗi bản tin nhằm ngăn chặn các cuộc tấn công replay.
• Năm 2008, TLS 1.2 được sinh ra, nó cung cấp các thuật toán mã hóa mạnh hơn và các phương thức bảo mật nâng cao, đồng thời cho phép xác thực và đàm phán thuật toán mã hóa linh hoạt hơn.
• Năm 2018, phát hành TLS 1.3, loại bỏ các thuật toán yếu kém và giảm thiểu các bước trong quá trình bắt tay (handshake) để tăng tốc độ kết nối và bảo mật hơn.

Ngày nay, SSL đã bị khai tử và chúng ta đang sống trong thời đại của TLS. Nhưng do yếu tố lịch sử nên cái tên SSL/TLS vẫn thường được nhắc tới và thường xuyên được hiểu là như nhau.

Trong phần tiếp theo chúng ta sẽ mặc định mọi thứ là TLS nha.

Cuộc chiến bảo mật trên không gian mạng

Chúng ta cùng quay lại câu chuyện của An và Bình, một người ở Việt Nam còn một người ở Mỹ. Hai người muốn trao đổi với nhau trên mạng Internet về việc ký hợp đồng của công ty.

Công, cũng là một chủ công ty, đối thủ cạnh tranh của An và Bình. Công rất muốn biết được nội dung trao đổi giữa An và Bình để tìm đối sách cho công ty mình. Công là một chuyên gia mạng cực kỳ giỏi và giàu kinh nghiệm.

Mời các bạn chứng kiến một trận thư hùng giữa An, Bình và Công về trao đổi an toàn trên không gian mạng nha.

Trận thứ nhất: Thủa sơ khai

An và Bình quyết định trao đổi trực tiếp qua một ứng dụng nhắn tin. Công bắt được nội dung trao đổi của An và Bình, đọc và tìm được đối sách cho công ty.

Kết quả: An Bình thua trận.

Trận thứ hai: Sói ở giữa bầy cừu

An Bình phát hiện ra Công đọc lén dữ liệu. Họ quyết định mã hóa dữ liệu trước khi gửi.

An và Bình trao đổi với nhau và họ quyết định lựa chọn RSA để mã hóa dữ liệu trước khi gửi.

An tạo cặp khóa (privateA, publicA), sau đó gửi publicA cho Bình.

Bình tạo cặp khóa (privateB, publicB), sau đó gửi publicB cho An.

An dùng publicB mã hóa, sau đó gửi nội dung đã mã hóa cho Bình. Bình dùng publicA mã hóa, sau đó gửi nội dung đã mã hóa cho An.

An sử dụng privateA của mình để giải mã, đọc hiểu nội dung. Bình sử dụng privateB của mình để giải mã, đọc hiểu nội dung.

An Bình tưởng như thế là đã bảo mật, họ rất đắc ý với ý tưởng của mình.

Quay trở lại Công. Công ở giữa An và Bình, hắn ta thấy An Bình làm thế thì hắn chơi lại như sau:

Công tạo cặp khóa (privateC, publicC) cho mình.

Khi An gửi publicA cho Bình, Công ở giữa, hắn ta chặn không cho publicA của An gửi cho Bình, thay vào đó hắn gửi publicC của mình cho Bình, giả dạng là An.

Bình không hề biết Công giả dạng An, anh ta gửi publicB cho Công. Công không gửi cho An publicB, mà hắn gửi publicC của mình cho An.

Lúc này An Bình sử dụng publicC của Công để gửi tin, Công sử dụng privateC của mình để giải mã, đọc nội dung tin nhắn. Sau đó mới gửi tin đi.

Kết quả: An Bình thua tiếp trận nữa.

Trận thứ ba: Anh Đảm tương trợ

An và Bình thấy kế trên không linh, bèn tìm cách khác.

An Bình thấy rằng: họ có thể mã hóa dữ liệu để bảo mật thông tin, nhưng họ không biết đối phương có thực sự là chính chủ không. An không biết liệu có phải giao tiếp trực tiếp với Bình không? Bình cũng không biết có phải người mình trao đổi là An hay một người giả mạo.

Họ nghĩ ra một kế: An và Bình sẽ đăng ký với Đảm, ông trùm thế giới mạng, vua của ứng dụng nhắn tin.

An, Bình đăng ký tên, địa chỉ nhận tin, public key của mình. Đảm gửi lại cho họ giấy chứng nhận đã đăng ký kèm theo chữ ký của mình.

Đảm sử dụng ECDSA để ký điện tử vào thông tin An và Bình đã đăng ký. Đảm là vua thế giới mạng, ứng dụng của Đảm có thông tin public key của hắn, để xác định chữ ký của Đảm có chính xác không.

An gửi giấy chứng nhận đăng ký cho Bình. Bình nhờ Đảm (ứng dụng của Đảm có sẵn trong máy) xác nhận giấy đăng ký có đúng không. Đảm xác nhận là đúng. Lúc này Bình có được publicA của An có đi kèm với giấy đăng ký.

Bình gửi giấy chứng nhận đăng ký cho An. An nhờ Đảm xác nhận giấy đăng ký có đúng không. Đảm xác nhận là đúng. Lúc này An có được publicB của Bình có đi kèm với giấy đăng ký.

An sử dụng publicB của Bình để gửi tin, Bình sử dụng PublicA của An để gửi tin.

Quay trở lại với Công. Công ở giữa, hắn ta không thể giả mạo publicA cả An hay publicB của Bình, tại vì hắn không có privateD của Đảm để giả mạo chứng chỉ hay chữ ký của Đảm được. Nếu hắn giả mạo gì thì ứng dụng của Đảm sẽ phát hiện ra ngay, tại vì ứng dụng đó lưu publicD của Đảm trên local, Công không thể làm gì được.

Công bất lực.

An và Bình trao đổi an toàn với nhau.

Kết quả: An Bình thắng.

Trận thứ tư: Nâng cấp cải tiến

Sau một thời gian sử dụng An Bình thấy rằng trao đổi thông tin sử dụng khóa bất đối xứng rất bất tiện, với những dữ liệu text còn dễ xử lý, còn đối với dữ liệu file thì là chết ngỏm luôn. Thế là họ đành phải sử dụng cách khác để mã hóa dữ liệu.

An Bình quyết định sử dụng mã hóa đối xứng để mã hóa dữ liệu, mã hóa dữ liệu với mã hóa đối xứng nhanh hơn, dễ dàng hơn bất đối xứng. Nhưng việc xử dụng mã hóa đối xứng thì phải chia sẻ một khóa chung.

Để giải quyết vấn đề khóa chung có hai cách sau:

Cách thứ nhất: An sử dụng PublicKey của Bình để mã hóa khóa chung, sau đó gửi cho Bình. Chỉ có Bình có PrivateKey của mình để giải mã.

Cách thứ hai: An và Bình sử dụng thuật toán trao đổi khóa an toàn như DH hay ECDH để trao đổi một ShareKey, sau đó từ ShareKey đó tạo ra khóa chung.

Thế là An Bình đã có thể mã hóa một cách dễ dàng và nhanh chóng rồi.

Phần trên là các trận chiến về giao tiếp an toàn trên không gian mạng. Các bạn đã nắm được tổng quan về ý tưởng rồi phải không nào, giờ đi vào chi tiết nhé.

Transport Layer Security (TLS)

Như đã nêu ở trên thì TLS là một tầng, lớp để bảo vệ thông tin của chúng ta, ý tưởng của nó là mọi dữ liệu gửi đi đều phải được mã hóa.

Để người gửi và người nhận có thể hiểu được thông tin mã hóa của nhau, phải có một bước để trao đổi khóa, xác minh thông tin... bước này người ta gọi là cái bắt tay TLS hay TLS Handshake.

Mỗi phiên bản khác nhau của TLS lại có một vài sự khác biệt trong quá trình bắt tay, chúng ta cùng tìm hiểu hai version của TLS phổ biến hiện nay là TLS1.2 và TLS1.3 nha. Trước khi đi vào chi tiết ta hãy điểm qua một vài khái niệm sau

Cipher suite

Đây là liên thuật toán được sử dụng, ví dụ một cipher suite trong TLS 1.2 như sau:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Phân tích

• TLS: Đây là giao thức bảo mật, chính là TLS.
• ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): Đây chính là thuật toán trao đổi khóa an toàn ECDH chúng ta đã đi qua. Với chữ E cuối cùng đại diện cho "Ephemeral" nghĩa là mỗi session thì sẽ tạo lại một khóa mới, thế thôi, vẫn sử dụng ECDH là trao đổi.
• ECDSA (Elliptic Curve Digital Signature Algorithm): Đây là thuật toán chữ ký số ECDSA chúng ta đã học rồi đó nha.
• AES_128_GCM (Advanced Encryption Standard with 128-bit key in Galois/Counter Mode): Đây là thuật toán AES trong chế độ GCM, đã được học rồi nhé.
• SHA256 (Secure Hash Algorithm 256-bit): Đây là thuật toán băm SHA256 cũng đã được trình bày.

Bạn thấy đó, toàn những kiến thức thân quen. Còn với TLS 1.3 thì sao? Lấy một ví dụ nha

TLS_AES_128_GCM_SHA256

Cũng giống như cipher suite của TLS1.2, nhưng bị lược bỏ bớt ECDHE và ECDSA rồi. Để hiểu tại sao lại bỏ bớt, thực sự có bị bỏ không hãy cùng đi tiếp nha 👌

SSL Certificate

Câu hỏi đầu tiên: tại sao là SSL Certificate mà không phải là TLS Certificate. Đây là di sản của chế độ cũ: SSL. Trước khi có TLS thì SSL được sử dụng để trao đổi an toàn, trong có có việc sử dụng SSL Certificate. Khi chuyển SSL sang TLS thì người ta vẫn sử dụng tên SSL Certificate mà không chuyển sang TLS Certificate đó.

SSL Certificate là một chứng chỉ, danh thiếp, căn cước,... hay đại loại thế. Nó được sử dụng để xác thực danh tính của một thực thể, ví dụ một website. Giống như căn cước công dân của chúng ta vậy. Để có thể xác thực được thì SSL Certificate có các thông tin tiêu biểu sau:

• Tên miền: Chứng chỉ SSL bao gồm tên miền (domain name) mà nó bảo vệ.
• Thông tin tổ chức: Thông tin về tổ chức sở hữu chứng chỉ, bao gồm tên, địa chỉ, và vị trí địa lý.
• Khóa công khai: Khóa công khai của thực thể.
• Chữ ký số: Chữ ký số của tổ chức phát hành chứng chỉ (CA - Certificate Authority), để xác nhận tính hợp lệ của chứng chỉ.

Chúng ta có thể xem chứng chỉ của một website trên brower. Cái này các bạn tự search nha, dân Ai Ti mà không biết search thông tin thì có chết không cơ chứ 🤣Ví dụ tổng quan một SSL Certificate như sau.

KeyShare, PreMasterSecret và MasterSecret

KeyShare

Nếu chúng ta sử dụng thuật toán trao đổi khóa như DH hay ECDH, ví dụ An và Bình sử dụng DH để trao đổi khóa, thì An phải gửi cho Bình $A = g^a mod\; p$ và Bình gửi cho An $B = g^b mod\; p$ . A và B được gọi là KeyShare, tương tự với ECDH. Xem lại bài DH và ECDH nếu không nhớ nha.

PreMasterSecret

Đây là giá trị chung được An và Bình sinh ra sau khi đã có KeyShare của đối phương. Nếu sử dụng DH thì $s =s_1 = B^a mod\; p = (g^b)^a mod\; p = s_2~ = A^b mod \;p = (g^a)^b mod \;p$ . Lúc này s chính là PreMasterSecret đó.

MasterSecret

Sau khi đã có PreMasterSecret, An và Bình sẽ phải sử dụng một thuật toán cho trước, mọi người cùng biết để từ PreMasterSecret sẽ sinh ra được khóa chung. Ví dụ sử dụng AES128 để mã hóa và giải mã thì từ PreMasterSecret sẽ phải sinh ra được khóa 128bit cho AES, khóa này được gọi là MasterSecret.

TLS 1.2 Handshake

Về tổng quan thì TLS1.2 Handshake có ba thành phần như sau

Để nói từng phần rồi đi tới ví dụ thì sẽ khó hiểu cho người mới và người hơi hơi mới 🤣 Tốt nhất hãy lấy một ví dụ, rồi vừa giải thích vừa có ví dụ luôn nha.

TLS 1.2 Handshake with RSA KeyExchange

Tiếp tục với bắt tay bắt chân nào. Đầu tiên cứ xem hình trước rồi nói chuyện tiếp

Hình trên nêu chi tiết các bước trong mỗi phần của TLS1.2, ta cùng đi qua từng bước từng bước nào

1. Client Hello: đây là bước đầu tiên, client gửi một tin nhắn xin chào bao gồm các thông tin:
   • Client Version: TLS version client đang sử dụng.
   • Cipher suites: Danh sách các Cipher Suite mà client có hỗ trợ.
   • Client Random: Một chuỗi bit ngẫu nhiên để sử dụng để sử dụng cho việc sinh ra MasterSecret sau này.
2. Server Hello: nhận được lời chào từ client, server đáp lại với tin nhắn xin chào cùng các thông tin sau:
   • Server version: TLS version server đang sử dụng.
   • Selected Cipher suite: Một Cipher Suite mà server chọn từ danh sách client gửi trước đó.
   • Server Random: Một chuỗi bit ngẫu nhiên để sử dụng cho việc sinh ra MasterSecret sau này.
3. Server Certificate: Server gửi thông tin SSL Certificate của mình cho client, client xác thực xem chứng chỉ này có hợp lệ hay không. Nếu hợp lệ thì đi tiếp.
4. Server Hello Done: Server thông báo rằng các tin nhắn xin chào đã kết thúc.
5. Client Key Exchange: Client tạo một PreMasterSecret ngẫu nhiên, rồi sau đó sử dụng Public Key có sẵn trong SSL Certificate để mã hóa PreMasterSecret này và gửi cho Server.
   • Tại vì chỉ có server mới có Private Key để giải mã lấy được PreMasterSecret, nên xác minh server là đúng với SSL Certificate.
   • Cả server và client đều có PreMasterSecret nên họ có thể sử dụng nó để tạo ra được MasterSecret, đây là khóa dùng trong thuật toán mã hóa như AES.
6. Client Change Cipher Spec: client thông báo rằng nó đã tính được MasterSecret, các tin nhắn sau sẽ được mã hóa.
7. Client Handshake Finished: client gửi tin nhắn kết thúc quá trình handshake, tin nhắn này đã được mã hóa.
8. Server Change Cipher Spec: server thông báo rằng nó đã tính được MasterSecret, các tin nhắn sau sẽ được mã hóa.
9. Server Handshake Finished: server gửi tin nhắn kết thúc quá trình handshake, tin nhắn này đã được mã hóa.

Vì sử dụng trực tiếp Public Key của server có trong SSL Certificate để truyền PreMasterSecret, mà trước đây Public Key này thường là RSA, nên người ta gọi đây là RSA KeyExchange có nghĩa là trao đổi khóa bằng RSA. Tiếp theo chúng ta đến với ưu nhược điểm của thằng này nha.

Ưu nhược điểm của TLS1.2 with RSA Key EXchange

Ưu điểm: Khá bảo mật, dễ hiểu, straightforward.

Nhược điểm: Nếu Private Key của server mà bị lộ thì sẽ bị lộ hết thông tin. Tại vì sử dụng Public Key của server để mã hóa PreMasterSecret mà, nếu Private Key mà bị lộ thì kẻ gian là Công sẽ giải mã được hết PreMasterSecret sau đó tính được MasterSecret, lục lại lịch sử trao đổi và giải mã được hết nội dung.

TLS 1.2 Handshake with DH KeyExchange

Để giải quyết vấn đề sử dụng một cặp public/private key của server để mã hóa giải mã, chúng ta sẽ làm như sau:

• Mỗi session trao đổi giữa client và server, chúng ta sẽ sử dụng một MasterSecret khác nhau
• Không được sử dụng một cặp public/private key của server để mã hóa PreMasterSecret nữa.
• Để trao đổi MasterSecret chúng ta có sử dụng thuật toán họ Diffie-Hellman như DH hay ECDH hay thuật toán tương tự.

Nói tiếp về DH và ECDH, chúng ta thường thấy DHE và ECDHE, thế thêm chữ E làm gì? Chữ E cuối cùng đại diện cho "Ephemeral" nghĩa là mỗi session thì sẽ tạo lại một khóa mới, có nghĩa là client và server thống nhất với nhau sử dụng DH để trao đổi khóa, mỗi session lại tạo ra khóa mới trao đổi một lần, thế thôi đó.

Với cách này thì khi một khóa trong một session bị lộ, thì chỉ có thông tin trong session đó bị lộ thôi, còn các session khác vẫn được bảo mật.

Xem hình minh họa nè

Các bước trong Establishing Connection Parameters và Secure Symmetric Encryption Established là như RSA KeyExchange, mình sẽ không viết lại nữa, chỉ trong Authentication And Key Exchange thôi nha

1. Client Hello
2. Server Hello
3. Server Certificate: Server gửi thông tin SSL Certificate của mình cho client, client xác thực xem chứng chỉ này có hợp lệ hay không. Nếu hợp lệ thì đi tiếp.
4. Server Key Exchange: Server gửi KeyShare và Server Signature cho client
   • KeyShare được sử dụng để sinh ra PreMasterSecret, đã nói phần trên.
   • Server Signature: Tại vì không sử dụng Public Key của server trong SSL Certificate để trao đổi khóa nữa, nên server phải tự chứng minh mình đúng là người trong Certificate bằng cách sử dụng Private Key của mình để ký vào thông tin đại loại như Mã băm của Server Random + Client Random (thực tế nhiều hơn nha). Client có thể sử dụng Public Key trong SSL Certificate để xác thực có đúng hay không.
5. Server Hello Done: Server thông báo rằng các tin nhắn xin chào đã kết thúc.
6. Client Key Exchange: Client gửi KeyShare cho server.
   • Lúc này Server và Client đều có KeyShare, họ sẽ sử dụng nó để tạo ra PreMasterSecret sau đó là MasterSecret.
   • Với mỗi session thì quá trình Key Exchange lại lặp lại nhằm tạo ra một MasterSecret mới.
7. Client Change Cipher Spec
8. Client Handshake Finished
9. Server Change Cipher Spec
10. Server Handshake Finished

Ưu nhược điểm của TLS1.2 with DH Key EXchange

Ưu điểm: Bảo mật cao, sử dụng mỗi session một MasterSecret khác nhau nên không sợ bị lộ hết thông tin.

Nhược điểm: Rất rườm rà, dài dòng, nhiều bước dẫn tới việc tốn thời gian bắt tay nhiều.

TLS 1.3 Handshake

Vấn đề của TLS 1.2 Handshake là nó có quá nhiều bước, dẫn tới việc bắt tay trở nên rườm rà và tốn thời gian. Đồng thời TLS 1.2 cũng có nhiều thuật toán không được bảo mật. Trong TLS 1.3 các thuật toán được lược bớt đi, không còn Handshake with RSA nữa (tham khảo), đồng thời cắt bước các bước bắt tay đi, hãy xem hình sau

1. Client Hello: Client gửi tin nhắn xin chào tới server, bao gồm
   • Client version: Version client sử dụng là TLS 1.3
   • Cipher Suites: Danh sách các cipher suite mà client hỗ trợ, tại vì TLS 1.3 được giảm bớt các thuật toán không bảo mật đi, nên số lượng cipher suite là giới hạn sau
     • TLS_AES_128_GCM_SHA256
     • TLS_AES_256_GCM_SHA384
     • TLS_CHACHA20_POLY1305_SHA256
     • TLS_AES_128_CCM_SHA256
     • TLS_AES_128_CCM_8_SHA256
   • Client Random: Một chuỗi bit ngẫu nhiên để sử dụng để sử dụng cho việc sinh ra MasterSecret sau này.
   • KeyShare: tại vì RSA handshake bị loại bỏ, đồng thời số lượng thuật toán có hạn (tham khảo) nên client dự đoán luôn Key Exchange algorithm được sử dụng và gửi KeyShare cho Server.
2. Server Hello & Server Finished: Sau khi nhận được tin xin chào của client, server trả về một tin xin chào, đồng thời cũng là tin kết thúc luôn, bao gồm các thông tin sau
   • Server version: version TLS server hỗ trợ là TLS 1.3
   • Selected Cipher suite: Một Cipher Suite mà server chọn từ danh sách client gửi trước đó.
   • Server Random: Một chuỗi bit ngẫu nhiên để sử dụng cho việc sinh ra MasterSecret sau này.
   • SSL Certificate: Server gửi thông tin SSL Certificate của mình cho client.
   • KeyShare: được sử dụng để sinh ra PreMasterSecret, đã nói phần trên.
   • Server Signature: Tại vì không sử dụng Public Key của server trong SSL Certificate để trao đổi khóa nữa, nên server phải tự chứng minh mình đúng là người trong Certificate bằng cách sử dụng Private Key của mình để ký vào thông tin đại loại như Mã băm của Server Random + Client Random (thực tế nhiều hơn nha). Client có thể sử dụng Public Key trong SSL Certificate để xác thực có đúng hay không.
3. Client Finished: client gửi tin nhắn kết thúc quá trình handshake, tin nhắn này đã được mã hóa.

Bạn thấy đó, chỉ còn có 3 tin được gửi đi thay vì 10 tin với TLS 1.2, dẫn tới việc bắt tay nhanh hơn.

Cách Brower xác thực SSL Certificate

Cuối cùng chúng ta cùng tìm hiểu xem cách mà một brower xác thực SSL Certificate thế nào nhé.

Đầu tiên phải nói lại là, SSL Certificate là một bản thông tin được ký xác thực bởi các tổ chức phát hành chứng chỉ Certificate Authority (CA). CA có thể sử dụng ECDSA hoặc RSA để ký. Nếu bạn nào chưa đọc bài viết có thể đọc lại ECDSA và RSA nha.

Để xác thực chữ ký này là hợp lệ thì brower phải có Public key của CA. Nếu brower mà quay sang hỏi CA (qua internet) thì lại trở về bài toán trao đổi an toàn rồi. Lúc này một người ở giữa brower và CA có thể giả mạo CA để đưa ra Public key giả mạo

Để tránh việc này thì các brower đã được lưu Public key của những CA nổi tiếng ở local luôn. Đến khi gặp Certificate của CA nào thì có sẵn Public Key của CA đó để xác thực.

Chúng ta có thể xem, xóa, thêm CA thủ công trên brower được nha, đối với Chrome thì như sau:

1. Các bạn vào Settings
2. Search: Manage certificates
3. Sẽ thấy một kết quả trong Privacy and security > Security > Manage certificates
4. Click vào Manage certificates sẽ hiện popup đại loại như sau

Các bạn có thể vọc để tìm hiểu thêm nha.

Tại vì lưu local nên có một vài trường hợp có brower cổ đại, lâu ngày không được update sẽ "không tin" những SSL Certificate của website được CA quá mới cấp đó nha 🤣, tại vì brower chưa cập nhật Public Key của CA mà.

Kết bài

Thế là chúng ta đã đi qua được TLS rồi, sau khi xong bài này chúng ta thực sự hiểu được cách hai người có thể trao đổi an toàn trên internet. Client và Server giống như An và Bình vậy. Chúng ta cũng học được cách áp dụng những thuật toán mà chúng ta đã học vào trong thực tế rồi.

Đây có lẽ cũng là bài cuối cùng trong chuỗi bài cryptography. Hi vọng sau loạt bài này mọi người có cái nhìn rõ ràng hơn về mật mã, biết được cách thức nó bảo vệ mọi người trên môi trường mở như là internet.

Cuối cùng là quà cho các bạn đã đọc tới đây, các bạn có thể xem chi tiết từng byte của TLS 1.2 tại đây:
https://tls12.xargs.org/
và TLS 1.3 tại đây:
https://tls13.xargs.org/

Tài liệu tham khảo

1. https://tls12.xargs.org/
2. https://tls13.xargs.org/
3. https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art080
4. https://en.wikipedia.org/wiki/Transport_Layer_Security

Nguồn bài viết https://truongphuoc.wordpress.com/2024/10/02/tan-man-ve-ssl-tls/