HTTPS và SSL/TLS - giải thích cho trẻ em 5 tuổi thế nào?

Mình chém gió đấy, trẻ 5 tuổi còn đang tập đọc mà hiểu được cái này thì là thần đồng, là thiên tài, là mình cũng lạy. Nhưng bạn muốn đọc để giải thích cho trẻ 5 tuổi ở cuối bài nhé :D

1. Đầu tiên: client gửi tới server một message hello để bắt đầu tiến trình handshake. Message này sẽ chứa một số thông tin, chẳng hạn như phiên bản SSL, Giải thuật mã hóa mà client support, và một chuỗi bytes ngẫu nhiên gọi là client random. Các bạn lưu ý chuỗi bytes này nhé, tác dụng của nó mình sẽ nói ở phần dưới.

2. Khi nhận được message hello từ client: server cũng sẽ gửi lại cho client một message hello. Trong message này có chứa SSL certificate của server, Giải thuật mã hóa mà server chọn để thống nhất với Client (Cipher), và cả một chuỗi bytes ngẫu nhiên nữa được gọi là server random. (và một số cái linh tinh nữa, mình lược đi cho đỡ rối). Ở đây có một khái niệm mới, đó là SSL certificate.

SSL và SSL certificate là 2 thứ khác nhau nha. SSL thì các bạn biết rồi, còn SSL certificate thì là một file chứa các thông tin của server như tên tuổi địa chỉ.

Certificate này giống như một chiếc chứng minh thư vậy. Bạn đưa chứng minh thư cho một người khác, thì người đó có thể đảm bảo bạn đúng là bạn rồi đúng không? (Đúng không nhỉ? 😦)

3. Khi nhận được SSL certificate của server: phía client sẽ tiến hành xác nhận xem certificate này có “chuẩn” hay không. Từ “chuẩn” có thể dễ gây hiểu nhầm, nên hãy để mình giải thích thêm một chút về mục đích server gửi certificate về cho client.

Như đã nói ở trên, certificate giống như một chiếc chứng minh thư. Tuy nhiên chứng minh thư cũng có chứng minh thư this chứng minh thư that. Cái gì cũng có thể fake được, do đó chưa thể đảm bảo ngay certificate server gửi về là chuẩn.

Để xác định certificate của server có chuẩn hay không, client sẽ cần kiểm tra bên phát hành certificate đó.

Thường bên phát hành certificate là một tổ chức được tin tưởng, và tổ chức này sẽ xác nhận giúp bạn xem certificate của server có chuẩn hay không (chuẩn ở đây là kiểu certificate này đúng là được phát hành cho server “abcxyz.com”, chính tôi (bên thứ 3) là người phát hành), giống như bạn nhờ Nhà Nước xác nhận xem chứng minh thư của anh A anh B có chuẩn không vậy.

Khi bên thứ 3 xác nhận certificate này đúng là của server mà bạn mong muốn, thì bạn có thể tin tưởng server đó và tiến hành các bước tiếp theo rồi.

4. Sau khi thấy certificate đã ok: server đã được client tin tưởng. Bước tiếp theo là 2 bên cần thống nhất một cách mã hoá để chỉ có 1 trong 2 bên mới có thể giải mã được.

Để làm được điều này, client sẽ gửi tiếp lên server một chuỗi bytes nữa, gọi là premaster secret. Premaster secret này đã được mã hoá bằng public key.

Public key ở đâu ra? Hoá ra trong certificate mà server gửi về có chứa luôn 1 public key rồi!

Client sẽ dùng public key này để mã hoá premaster secret.

Để giải mã được premaster secret này thì cần đến private key, và tất nhiên private key này được lưu trữ an toàn ở phía server. Do đó chỉ có server mới có thể giải mã premaster secret.

5. Server tiến hành giải mã premaster secret.

6. Bạn có để ý không? Tại thời điểm này thì cả phía server và client đều đã có:

• Client random
• Server random
• Premaster secret.

Cả 2 bên sẽ dùng 3 key này để tạo ra một key mới bằng giải thuật đã chọn ban đầu (trong Cipher suites), key mới tạo ra gọi là Session key. 

Giải thích cho trẻ 5 tuổi: Bạn có thể tưởng tượng quá trình này như việc trộn 3 màu sơn với nhau vậy. Nếu cả 2 bên đều biết 3 màu sơn đó là gì, thì sẽ trộn ra được màu giống nhau. Nhưng lệch đi một màu thôi thì kết quả sẽ hoàn toàn khác nhau.

Session key này có thể dùng để mã hoá và giải mã luôn.

7. Client đã sẵn sàng: và sẽ gửi một message “finish” tới server. Message này sẽ được mã hoá bởi… bạn cũng đoán ra đúng không? Session key!

8. Server cũng sẵn sàng: và sẽ response lại một message “finish” được mã hoá bởi session key.

9. Handshake hoàn tất!

Từ thời điểm này server và client sẽ giao tiếp với nhau bằng các message được mã hoá bởi session key. Do session key này được tạo ra nhờ cách “trộn sơn” trong quá trình handshake, nên sẽ rất khó để một bên thứ 3 có thể lấy được. Do đó, việc trao đổi thông tin giữa server và client được đảm bảo.

Như vậy, bằng việc sử dụng SSL, chúng ta đảm bảo được mình kết nối đến đúng đối tượng mà mình mong muốn, và sau khi kết nối rồi thì các gói tin qua lại giữa 2 bên cũng được mã hoá một cách an toàn.

Tuy nhiên, vẫn sẽ có cách để bypass SSL.

Như chúng ta vừa tìm hiểu, để client tin tưởng server và tiến hành handshake, thì phía client phải trust SSL certificate của server.

Vậy nếu hacker muốn đứng vào giữa client và server, bắt mọi request từ client và giả mạo làm server để trả response cho client thì sao? Hacker vẫn sẽ phải gửi một SSL certificate về cho client, nhưng client có thể phát hiện ngay certificate này không “chuẩn”, và tiến hành ngắt kết nối.

Tuy nhiên, nếu hacker có thể install certificate của mình vào hệ thống của client, để hệ thống luôn luôn trust certificate này, thì client vẫn sẽ vui vẻ mà tiến hành handshake.

Đây chính là cách mà các phần mềm proxy hoạt động. Nếu các bạn dùng mac, chắc giờ các bạn đã hiểu tại sao proxy luôn yêu cầu bạn cài đặt root certificate đúng không?

Để tránh việc bypass bằng cách install root certificate này, chúng ta có thể sử dụng SSL pinning.

P/s: À nói thêm một chút. Tiêu đề bài viết có cả cụm từ TLS, chắc các bạn cũng hay gặp và đang thắc mắc nó là cái gì. Có thể hiểu SSL ra đời trước, có nhiều nhược điểm, TLS ra đời sau, với cùng mục đích như SSL nhưng xịn hơn. Thực tế hiện nay TLS mới là cái được sử dụng nhiều hơn, SSL đang dần trôi vào quá khứ rồi. SSL handshake bây giờ hầu hết đã là TLS handshake, tuy nhiên do cụm từ SSL thông dụng đã lâu nên người ta vẫn tiếp tục sử dụng cụm từ này.

By: @ha.tuan.thinh - Contributor: @thaopt 

Bài cũ từ 2017: HTTPS hoạt động như thế nào?