Hiểu hơn về HTTPS với ví dụ bồ câu đưa thư

Chúng ta đều biết mã hoá là một chủ đề rất khó hiểu. Nó ứng dụng hàng loạt các chứng minh toán học để biến thông tin từ định dạng bình thường sang định dạng thông tin không thể hiểu được nếu như không có phương tiện Giải mã. Nhưng trừ khi bạn thực sự phát triển một hệ thống mã hoá, nếu không thì bạn không cần thiết phải hiểu rõ phần lớn các sự phức tạp mà vẫn có thể hiểu được những gì thực sự đang diễn ra.

Mike, James và chú chim bồ câu

Mọi hoạt động của bạn trên Internet thực chất đều là gửi và nhận các thông điệp giữa thiết bị kết nối internet của bạn (máy tính, điện thoai…) và một máy chủ nào đó. Bạn hãy tưởng tượng những thông điệp đó được truyền tải bởi những chú chim bồ câu đưa thư, cách HTTP hoạt động cũng tương tự như vậy. Thay vì nói về Servers, Clients hay Hackers, chúng ta hãy cùng xem câu chuyện về Mike, James và Faker.

Thuở sơ khai

Nếu Mike muốn gửi một tin nhắn cho James, anh ấy sẽ kẹp mẩu tin nhắn vào chân chú chim bồ câu và chim bồ câu sẽ bay tới chỗ James. James nhận được mẩu tin nhắn, đọc nó và mọi thứ diễn ra đều suôn sẻ.

Nhưng đời không như là mơ, Faker xuất hiện, bẫy được chú chim bồ câu đang bay của Mike và giả mạo tin nhắn? James sẽ không thể biết rằng tin nhắn của Mike đã bị giả mạo bởi Faker trong quá trình chú chim vận chuyển mẩu tin nhắn.

Đây chính là cách thức hoạt động của HTTP. Rất đáng sợ phải không nào?

Mã bí mật

Nhưng Mike và James rất khôn ngoan. Họ bí mật với nhau rằng sẽ dùng một loại mật mã bí mật (Secret code) để gửi tin nhắn cho nhau. Họ sẽ thay đổi mỗi chữ trong bảng chữ cái bằng ký tự thứ 3 đứng trước nó.

Ví dụ: D → A, E → B, F → C, tin nhắn sơ khai”Ahihi do ngok” sẽ được mã hoá thành “Xefef al kdlh”

Bây giờ kể cả khi Faker bắt được bồ câu của Mike, hắn sẽ không thể hiểu được ý nghĩa của tin nhắn vì hắn không biết mật mã để giải mã tin nhắn, còn James có thể giải được mật mã bằng cách làm ngược lại với Mike ( A → D, B → E, C → F). Mật mã “Xefef al kdlh” sẽ được James giải mã thành “Ahihi do ngok”. NGON!

Kỹ thuật này gọi là Mã hoá Đối xứng (symmetric key cryptography), vì nếu bạn biết mã hoá tin nhắn thì bạn cũng có thể giải mã tin nhắn. Trong thực thế, chúng ta dùng những mã hoá phức tạp hơn, nhưng ý tưởng thì vẫn tương tự như thế này. Dễ hiểu phải không?

Thống nhất chìa khóa giải mã (Key)?

Mã hoá Đối xứng sẽ cực kỳ bảo mật nếu không ai ngoài người gửi và người nhận biết key đã được sử dụng, trong cách mã hoá nêu trên, key chính là số thứ tự của ký tự (trong ví dụ trên là 3), số 3 để xác định rằng chúng ta sẽ dùng bao nhiêu ký tự đứng sau chữ cái để giải mã (A → D thì D là chữ cái thứ 3 sau A) ngoài ra chúng ta có thể dùng key là “6” hoặc “9”.

Vấn đề xảy ra ở đây là nếu Mike và James không gặp mặt nhau và có thỏa thuận trước khi gửi tin nhắn qua bồ câu, họ sẽ không biết được key là gì. Nếu họ gửi key trong thư thì Faker sẽ biết được key, giải mã và sẽ lại giả mạo được tin nhắn. Đây là một ví dụ điển hình của hình thức Tấn công xen giữa (Man in the Middle Attack) và cách duy nhất để phòng tránh điều này là cả 2 đầu cùng thay đổi hệ thống mã hoá.

Bồ câu mang hộp

Để bảo mật hơn, Mike và James nghĩ ra một hệ thống tốt hơn. Khi James muốn gửi cho Mike một tin nhắn, anh ấy sẽ làm theo các bước sau:

 James gửi bồ câu không đem theo tin nhắn cho Mike.

– Mike gửi lại bồ câu với một chiếc hộp có ổ khoá đang mở (ổ khóa này có thể khóa lại mà không cần chìa khóa), nhưng Mike vẫn giữ lại chìa khoá của chiếc hộp.

– James cho tin nhắn vào hộp, đóng ổ khoá lại và gửi lại cho Mike.

– Mike nhận chiếc hộp, mở ra bằng chìa khoá và đọc tin nhắn.

Bằng cách này Faker không thể can thiệp vào bồ câu đưa thư vì hắn ta không có chìa khoá.

Tương tự quá trình trên Mike sẽ gửi lại tin nhắn cho James.

Mike và James vừa dùng một cách thức gọi là Mã hóa KHÔNG đối xứng (asymmetric key cryptography). Gọi là không đối xứng vì nếu bạn mã hoá tin nhắn (khoá chiếc hộp lại) thì bạn sẽ không thể mở nó (vì bạn không có chìa khoá). Về mặt kỹ thuật, chiếc hộp giống như là public key và chìa khoá để mở hộp có thể coi là private key.

Faker cũng có thể giả mạo chiếc hộp mà!

Nếu chú ý, bạn sẽ nhận ra rằng chúng ta vẫn còn một vấn đề nữa. Khi James nhận được chiếc hộp, làm cách nào để James đảm bảo chiếc hộp đó là của Mike và chắc chắn rằng chiếc hộp đó không bị Faker tráo với một chiếc hộp khác của hắn?

Mike quyết định rằng anh ấy sẽ ký vào chiếc hộp, bằng cách này khi James nhận được chiếc hộp anh ấy sẽ kiểm tra xem có đúng là chữ ký của Mike hay không để xác nhận chiếc hộp. Nhưng.. như thế này đã ổn chưa nhỉ?

Chắc chắn các bạn sẽ thắc mắc: làm cách nào để James biết được đó là chữ ký của Mike khi lần đầu nhận chiếc hộp? Hay lắm! Cả Mike và James đều gặp vấn đề này, nên họ quyết định rằng, thay vì Mike ký vào chiếc hộp thì sẽ để cho Tim ký nó.

Tim là ai? Tim là một người nổi tiếng, được biết là một người đáng tin. Tim ký cho mọi người và mọi người tin tưởng rằng anh ta sẽ chỉ ký vào những chiếc hộp của những người đáng tin cậy.

Tim sẽ chỉ ký vào chiếc hộp của Mike nếu anh ta biết chắc rằng người yêu cầu ký là Mike. Vì vậy, Faker sẽ không thể giả mạo được chiếc hộp của Mike đã được ký bởi Tim vì Tim chỉ ký hộp cho những người đã xác minh danh tính của họ. Về mặt kỹ thuật đây gọi là “Chứng nhận thẩm quyền” (Certification Authority).

Khi bạn kết nối đến một Website lần đầu tiên, bạn tin chiếc hộp của nó là thật vì bạn tin Tim và Tim đảm bảo với bạn rằng chiếc hộp là thật.

Những chiếc hộp rất nặng! (Chú chim than thở…)

Mike và James giờ đây đã có một hệ thống tin cậy để truyền tin (toàn bộ quá trình trên chính là mô phỏng tương tự như giao thức HTTPS), nhưng họ nhận ra những chú chim bồ câu mang tin chậm hơn trước vì phải mang theo những chiếc hộp và chúng nặng hơn những mẩu tin bình thường rất nhiều.

Họ quyết định chỉ dùng những chiếc hộp (Mã hoá không đối xứng) để trao đổi key, sau khi đã thống nhất được key, họ tiếp tục truyền tin sử dụng mật mã đối xứng ( A → D, key là 3) (Mã hóa đối xứng).

Bằng cách này họ đã áp dụng cả 2 loại mã hoá (Mã hoá đối xứng và Mã hoá không đối xứng). Sự tin cậy của mã hoá không đối xứng và ưu điểm tốc độ nhanh hơn của mã hoá đối xứng.

Thực tế sẽ không có những chú chim bồ câu chậm (chỉ có những chú chim bồ câu yếu.. ), nhưng mã hoá tin nhắn sử dụng mã hoá không đối xứng vẫn sẽ chậm hơn so với việc sử dụng mã hoá đối xứng, nên chúng ta sẽ chỉ dùng mã hoá không đối xứng để trao đổi các key với nhau.