Giải thích cơ chế hoạt động của SSL (Secure Socket Layer): Trong bài viết này mình sẽ cố gắn trình bày một cách giải thích dễ hiểu nhất về cơ chế hoạt động của SSL cho bạn hiểu, vì sao SSL được xem là cơ chế cực kỳ bảo mật và hiện nay có mặt hầu hết ở các giao thức yêu cầu bảo mật truyền tin trong công nghệ: HTTPS 443, SMTP 465/587, POP3 995, FTPS 21/990,...
Nhu cầu kỹ thuật mật mã có từ thời xa xưa:
Bạn hãy nhắm mắt lại để mường tượng viễn cảnh trở về một thời đại xưa cũ, ở nơi ấy không có những thiết bị kỹ thuật liên lạc bình thường như bây giờ: qua điện đàm, phone hay facebook, skype… Thông thường thời xa xưa ấy khi phải đi xa hành tẩu giang hồ chẳng hạn, mọi người thường gửi thư qua bồ câu cho nhau.
Thí dụ anh An muốn gửi bức thư với thông điệp bí mật "tui bi gay roi" cho chị Bích anh viết vào một tờ giấy nhỏ rùi cho bồ cầu gửi đi, giả sử giữa đường có ai nhặt được hay tóm được con bồ câu thì thành ra hỏng bét, họ chỉ cần mở tờ giấy ra là đọc được ngay nội dung gói tin message: "tui bi gay roi"
=> Cái này gọi là truyền gói tin clear text, bắt được là đọc được và khổ là trong thời hiện đại hiện nay cơ chế lồ lộ này vẫn còn rất phổ biến, thường chạy trong các giao thức http://80, smtp://25, ftp://21…
Khi bạn đọc bài viết này chẳng hạn, nếu nó là một trang http:// thì cái gói tin "tui bi gay roi" đang hiển thị trên trình duyệt của bạn cũng đã có thể đã bị một tin tặc đứng giữa bạn và máy chủ web này bắt được và đọc được.
Vậy nên clear text thật là thiếu an toàn, người ta phải nghĩ ra một cách nào đó để có thể mã hóa bức thư lại trước khi nó được truyền, sau đó bên kia nhận được thư thì cứ dùng mật khẩu đã thỏa thuận từ trước để giải mã ra tín hiệu.
Kỹ thuật mật mã sử dụng khóa chung:
Giả sử anh An và chị Bích thỏa thuận trước với nhau trước chẳng hạn là sẽ sử dụng password là "1" để giải mã và mã hóa thông điệp. Họ dùng một bản chữ cái thông thường:
a b c d e f g h i j k l m n o p q r s t u v w x y zNếu thỏa thuận password là "1" thì lệch về sau 1 chữ cái nếu muốn mã hóa hay giải mã:
a b c d e f g h i j k l m n o p q r s t u v w x y z
z a b c d e f g h i j k l m n o p q r s t u v w x yVậy nên anh An lúc này phải viết thông điệp "tui bi gay roi" dưới dạng mã hóa lùi 1 chữ lại như sau: "sth ah fzx qnh" cho chị Bích nhận được rồi chị ngồi so mã trừ 1 để tính ra lại cái thông tin gốc "tui bi gay roi". Còn nếu chẳng may gói tin bị lọt vào tay một ai đó chụp được họ sẽ chỉ có cái cụm: "sth ah fzx qnh" => chả hiểu đó là gì ^_^
=> Cái này gọi là truyền gói tin bằng công nghệ khóa chung, cái gọi là khóa chung ở đây chính là sự nhất trí từ trước giữa anh An và chị Bích sẽ lui 1 ký tự để giải mã, password chung chính là "1", giả sử nếu là "2" thì nó sẽ lại khác nữa:
a b c d e f g h i j k l m n o p q r s t u v w x y z
y z a b c d e f g h i j k l m n o p q r s t u v w x Kỹ thuật mật mã này thường áp dụng vào thực tế cho password wifi, password login phone, nick facebook,… Ở nơi đó bạn và đối tượng cần truy cập (điểm phát wifi chẳng hạn) phải thỏa thuận từ trước, chị Bích phát wifi đặt pass là 1234567890 thì anh An dùng password 1234567890 vào wifi của chị Bích mới thành công.
Kỹ thuật mật mã sử dụng hàm băm:
Xem ra đã an toàn lắm rồi nhỉ nhưng vẫn có vấn đề. Giả sử chị Bích có quá nhiều anh liên hệ, thế chẳng phải phải nhớ pass của rất nhiều anh để mà giải mã, thành ra chị cần ghi vào đâu đó như một cuốn sổ để có cái mà lục ra xem khi cần, đó sẽ là một cuốn sổ chứa list các password của người dùng cất trong nhà
=> Thật bất cẩn nếu lỡ để rơi vào tay kẻ gian nên chúng ta cần một cái gì đó để khắc phục vấn đề này. Và thế là người ta nghĩ ra hàm băm digest, ví dụ nổi tiếng nhất là băm md5
Bạn thử gõ vào dòng lệnh Linux yêu cầu băm các chũi ví dụ "1"; "2" hay "3" sẽ thấy nó hiện ra một chũi mã dài 32 ký tự chữ và số: (Nếu bạn không dùng Linux thì thử vào trang băm md5 online)
root@voduy [~]# echo -n '1' | md5sum | cut -d " " -f 1
c4ca4238a0b923820dcc509a6f75849b
md5(1) là c4ca4238a0b923820dcc509a6f75849b
md5(2) là c81e728d9d4c2f636f067f89cc14862c
md5(3) là eccbc87e4b5ce2fe28308fd9f2a7baf3
...md5() là một công thức xử lý do một số nhà toán học tạo ra với nhu cầu biến một chũi đầu vào cho trước, ví dụ "1" thành một đoạn mã khác "c4ca4..." với 1 yêu cầu không thể dịch ngược được đoạn mã đã băm về lại chũi đầu vào cho trước là "1". Với tính chất đó md5 lại đáp ứng được nhu cầu cần lưu trữ mật khẩu của chúng ta.
Khi bạn đăng nhập vào một máy chủ, ví dụ Windows, Linux… với user admin pasword 123456 chẳng hạn. Bạn nghĩ máy chủ sẽ làm gì để xác định mật khẩu của bạn có đúng hay không? Nó sẽ so sánh vào một file text nào đó lưu trên máy để biết mật khẩu của admin có là 123456 hay không à? Thật ra không phải vậy vì lỡ như để đánh mất cái file đó thì sao, do đó phải lưu mật khẩu dưới dạng ký tự băm ví dụ md5 chẳng hạn.
Khi bạn đặt password cho user admin là 123456 lần đầu tiên chẳng hạn, máy chủ sẽ chẳng quan tâm gì đến 123456 của bạn cả, nó tiến hành băm md5(123456) ra chũi e10a... sau đó nó lưu vào trong file, lần sau bạn đăng nhập user admin pass 654321 nó cũng chẳng quan tâm bạn đăng nhập pass gì nó cứ băm cái pass bạn đã gõ md5(654321) ra c333... so vào file text lưu pass, thấy mã md5 không trùng => nó xác định bạn đã nhập sai pass so với lúc đầu và cứ như thế, đến khi bạn nhập đúng pass 123456 nó sẽ băm ra mã md5, đem so sánh nếu thấy chính xác nó mới cho bạn vào.
Vậy đó, lúc nào chị Bích muốn bảo vệ mật khẩu cứ dùng công thức md5 để băm mật khẩu của cô ấy ra chũi không thể dịch ngược nếu ai đó có đánh cắp được:
Anh An là c4ca4238a0b923820dcc509a6f75849b
Anh Ba là c81e728d9d4c2f636f067f89cc14862c
Anh Cò là eccbc87e4b5ce2fe28308fd9f2a7baf3
...Kỹ thuật mật mã sử dụng cơ chế khóa chung-riêng:
Đến bước này thì có vẻ mọi thứ đã được bảo vệ rất tốt rồi nhưng giả sử tình huống thay đổi một chút, thí dụ anh An bị khiếm thị-thính giác chẳng hạn, và ảnh cũng chưa từng gặp chị Bích trong đời thế thì làm sao ảnh có thể xác định đối tượng ảnh muốn gửi gói tin "sth ah fzx qnh" tới là đúng là chị Bích?
Giống kiểu như một kẻ giả mạo nào đó đi đến gặp anh An và bảo rằng mình là chị Bích rồi yêu cầu cả 2 cùng thỏa thuận ra một khóa chung là password "3" chẳng hạn, sau đó hắn lại đi đến chị Bích và bảo rằng mình là anh An rồi yêu cầu tạo một khóa chung password "3". Thế là đứng ở giữa hắn có thể đọc tin của cả 2 trao đổi qua lại.
Làm sao để có thể khắc phục được nguy cơ trên?
Lúc này cơ chế khóa chung có thỏa thuận từ trước trở nên bất cập, người ta đành phải nghĩ ra một cơ chế khác đối phó, đó là cơ chế khóa chung + khóa riêng, (chú ý đây là cơ chế khác với cơ chế khóa chung ở trên, chúng ta chỉ nhắc lại cơ chế khóa chung ở trên sau khi tìm hiểu xong cơ chế khóa chung + riêng này) cách thức hoạt động của cơ chế này như sau:
Chị Bích tự viết ra một khóa chung và một khóa riêng ngẫu nhiên theo công thức hướng dẫn cho trước, công thức toán học này đảm bảo một điều: khóa chung được sinh ra từ khóa riêng và chỉ khóa riêng duy nhất đó mà thôi. Chị Bích giấu khóa riêng đi và công khai khóa chung ra cho mọi người cùng biết, giả sử chị có 2 tờ giấy:
Tờ khóa riêng ghi 1 mật mã dài 2048 ký tự: aof84kfnk.... (giấu đi)
Tờ khóa chung ghi 1 mật mã dài 2048 ký tự có tương quan đến khóa riêng ở trên: g54hshyy... (công khai)Lúc này anh An muốn biết đối tượng mình cần gửi gói tin "sth ah fzx qnh" tới, có phải là chị Bích hay không trước tiên anh sẽ lấy tờ khóa chung chị Bích về nhà, đồng thời gửi một gói tin ngẫu nhiên tới chị Bích, ví dụ "tào lao bí đao" chẳng hạn, chị Bích sẽ lấy gói tin đó về md5 nó md5(tào lao bí đao) ra một chũi nào đó 73ece… sau đó lại mã hóa cái chũi md5 đó bằng cái khóa riêng mà chị đã giấu kín, rùi gửi kết quả đã mã hóa trả lại cho anh An.
Anh An cầm kết quả mã hóa của cái gói tin ngẫu tin "tào lao bí đao", dùng cái khóa chung đã lấy từ chị Bích giải mã nó ra, nếu ra là thành công suy ra đó là chị Bích vì chỉ có chị giữ được khóa riêng của chị, còn không giải mã ra tức là không phải chị Bích, là một kẻ nào đó không có khóa riêng của chị mà dùng một khóa riêng giả mạo (nhắc lại 1 cặp khóa chung + riêng đi với nhau, khóa chung chỉ được sinh ra từ khóa riêng).
Nếu xác định được quả là kẻ kia đang liên lạc với mình là chị Bích, anh An có thể yên tâm thỏa thuận với chị Bích về password "1" và gói tin mã hóa "sth ah fzx qnh".
Kẻ tấn công ở giữa lúc này có vẻ ngậm ngùi vì không thể chứng minh mình là chị Bích trước anh An nên những gì anh nhận được chỉ là "sth ah fzx qnh" mà không biết giải mã ra làm sao vì không đi thỏa thuận được nên đâu có biết password là "1".
Tuy nhiên kẻ tấn công đâu chịu thua dễ dàng vậy, hắn biết được cơ chế khóa chung khóa riêng đã được áp dụng, và ngay khúc mà anh An gửi gói tin "tào lao bí đao" chẳng hạn, hắn liền bắt lấy gói tin ấy và nhanh chóng sửa nó thành "tào lao bí đao + gói tin kẻ giả mạo", vậy làm sao chị Bích phát hiện ra được gói tin đó đã bị cắt xén? Thành ra bây giờ chị Bích không nên mã hóa cái gói tin ngẫu nhiên "tào lao bí đao" gửi từ anh An lên nữa, chị nên làm như sau:
Chị gửi một thông điệp khác không bị mã hóa, ví dụ "admin voduy.com rất đẹp trai" và md5(admin voduy.com rất đẹp trai) đã được mã hóa thêm 1 tầng bằng khóa riêng của chị Bích. Anh An nhận được 2 cái ấy anh phải tiến hành giải mã cái cụm mã hóa kia bằng khóa công khai của chị Bích, nó sẽ ra chũi md5(admin voduy.com rất đẹp trai) rồi tiến hành băm lại "admin voduy.com rất đẹp trai" so sánh, nếu giống nhau đương nhiên gói tin từ chị Bích gửi về là toàn vẹn, và còn thông qua đó biết được chị Bích thật sự có giữ khóa riêng.
Vậy là ngậm ngùi lần thứ 2 cho kẻ tấn công với cách giải quyết rất thông minh của chị Bích. Để mình liệt kê lại cơ chế ngay từ đầu để bạn hình dung lại:
An gửi Bích: Chào đằng ấy, ai vậy? Tui bị mù!
Bích gửi An: Chào ông tui Bích đây! Đây là khóa chung công khai của tui!
An gửi Bích: Uh, bà chứng minh là bà có khóa riêng bí mật của bà đi!
Bích gửi An: Được, tui gửi ông 2 thứ, ông xem và tính đây này:
"admin voduy.com rất đẹp trai"
hàm-mã-hóa-bằng-khóa-riêng{-----md5(admin voduy.com rất đẹp trai)------}An sẽ tính toán và xác định được đó là chị Bích nếu thấy 2 thứ chị Bích gửi trên sau khi giải mã ra thì giống nhau. Tuy nhiên rắc rối to là sau khi vùi đầu nhức óc kẻ tấn công cũng đã nhìn ra được một mánh lới mới: Hắn cũng sẽ tự sinh ra một cặp khóa chung riêng của riêng mình mà lại lấy danh nghĩa chị Bích (giống như bạn tự tạo chứng chỉ tự ký cho google.com, facebook.com,… vậy) và đi đến gặp anh An để âm mưu lừa đảo ảnh mình là chị Bích. Tất nhiên nếu anh An mà cứ như cũ, lấy khóa chung của hắn rùi gửi gói tin ngẫu nhiên kiểm tra hắn có khóa riêng hay không hắn vẫn sẽ bypass qua hết và anh An lại lầm tưởng hắn là chị Bích sau đó thỏa thuận và trao đổi thông tin của mình.
Kỹ thuật mật mã sử dụng cơ chế khóa chung-riêng cùng sự chứng nhận của bên thứ ba:
Vậy phải giải quyết làm sao? Rất đơn giản anh An lúc này nên tải xuống và dùng Firefox hoặc Chrome,.. mới nhất, nếu dùng trình duyệt đó đánh vào trang https://bich.com chẳng hạn, nó sẽ có khả năng check xem khóa chung của kẻ đang công khai khóa chung là hợp lệ hay không hợp lệ trên toàn thế giới. Khi anh An kết nối đến chị Bích dù thật hay giả mạo, nó cũng sẽ báo đỏ và bảo rằng chứng chỉ khóa chung công khai của chị không hợp lệ, giống như là tự ký tự chứng vậy yêu cầu chị cần đi tìm một nơi trung gian thứ ba để mà chứng chứng chỉ của chị.
Thế là chị Bích lạch bạch chạy đi mua chứng chỉ tại các cơ quan có thẩm quyền cấp Certificate Authority, cái này lại lòi ra một số hãng bán công chứng chứng chỉ trên toàn thế giới Comodo, GlobalSign,… miễn phí thì có Let’s Encrypt, StartSSL,…
Cái việc khi chị tiếp cận nơi chứng chứng chỉ ấy cần phải làm đó là chị phải dẹp cái khóa chung sinh ra từ khóa riêng của chị đi, chỉ giữ lại khóa riêng mà thôi (đặt biệt phải giữ kín dù là nơi bán chứng chỉ cũng không cho họ biết cái khóa riêng của ta) thế nên, do chị không được cho nơi bán SSL biết khóa riêng của mình, chị sẽ tự sinh ra một file .csr từ khóa riêng, file .csr này giống như là cái đơn xin chứng chỉ cho khóa riêng cấp cho bich.com vậy, chị upload cái đấy cho bên bán chứng chỉ, bên bán chứng chỉ có nhiệm vụ phải xác minh xem bà chủ của file .csr mới upload lên có phải là bà Bích hay không, có phải là chủ domain bich.com không, bao gồm cả CMND, vân tay, chữ ký, dòng họ, hoặc gửi mail cho [email protected],…
Đủ cách để xác minh việc Bích có phải chủ nhân domain đó không, nói chung nếu đúng thì tiến hành sinh file khóa chung cho bà Bích và gửi cho bả. Cái file khóa chung công khai mới này – nội dung trong nó bao gồm: khóa chung + giấy chứng nhận từ Certificate Authority (Comodo, Let’s Encrypt…) chẳng hạn và cái khóa chung ấy sinh ra từ file .csr nên nó cũng coi như là sinh ra từ file khóa riêng đang giấu của chị Bích.
Vậy là chị Bích chẳng qua cũng chỉ vẫn có khóa chung + khóa riêng, có điều khóa chung mới xin về lúc này của bả có sự chứng nhận của cơ quan thứ 3 Certificate Authority.
Đem về sử dụng, thế là anh An kết nối đến bằng trình duyệt nhận thấy chị Bích https://bich.com có Certificate Authority xanh lè của Comodo uy tín công chứng chẳng hạn, đã vậy kiểm tra một số bước tiếp theo thấy chị Bích rõ ràng có khóa riêng trong tay => Good, bà chắc chắn là bà Bích!
Kẻ tấn công ngậm ngùi tập 3. Xem trong cái cơ chế này đã chẳng còn một lỗ hổng nào để khai phá, thế nhưng chịu khó gian tà thì trời không phụ lòng kẻ gian. ^_^ Lỗ hổng cũng đã xuất hiện trong hệ thống, kẻ gian nghĩ ra một trò mới mà không lạ: man-in-the-middle (đứng trung gian giả danh cả 2).
Man-in-the-middle và cách chống:
Để mình liệt kê lại cơ chế cho bạn hình dung, (giả định hacker đứng giữa đã có thể kiểm soát lưu lượng gói tin của người dùng):
An gửi Hacker: Chào đằng ấy, ai vậy? Tui bị mù!
Hacker chuyển tiếp cho Bích: Chào đằng ấy, ai vậy? Tui bị mù!
Bích gửi Hacker: Chào ông tui Bích đây! Đây là khóa chung công khai của tui!
Hacker chuyển tiếp cho An: Chào ông tui Bích đây! Đây là khóa chung công khai của tui!
An gửi Hacker: Uh, khóa chung công khai của bà rất chuẩn xanh lè trên toàn thế giới, giờ bà chứng minh là bà có giữ khóa riêng bí mật của khóa chung công khai này đi!
Hacker chuyển tiếp cho Bích: Uh, khóa chung công khai của bà rất chuẩn xanh lè trên toàn thế giới, giờ bà chứng minh là bà có giữ khóa riêng bí mật của khóa chung công khai này đi!
Bích gửi Hacker: Được, tui gửi ông 2 thứ, ông xem và tính đây này:
"admin voduy.com rất đẹp trai"
hàm-mã-hóa-bằng-khóa-riêng{-----md5(admin voduy.com rất đẹp trai)------}
Hacker chuyển tiếp cho An: Được, tui gửi ông 2 thứ, ông xem và tính đây này:
"admin voduy.com rất đẹp trai"
hàm-mã-hóa-bằng-khóa-riêng{-----md5(admin voduy.com rất đẹp trai)------}
An gửi Hacker: Uh, trông có vẻ an toàn rồi, bà là bà Bích chắc cú, đây là mật khẩu chung giữa chúng ta mà tôi đã chọn và đã được mã hóa bằng khóa công khai của bà, bà có khóa riêng của bà Bích thì mới giải mã mà biết được nhé, đây nè {password "1"}khóa-công-khai-của-Bích
Hacker chuyển tiếp cho Bích: Uh, trông có vẻ an toàn rồi, bà là bà Bích chắc cú, đây là mật khẩu chung giữa chúng ta mà tôi đã chọn và đã được mã hóa bằng khóa công khai của bà, bà có khóa riêng của bà Bích thì mới giải mã mà biết được nhé, đây nè {password "1"}khóa-công-khai-của-Bích
Bích gửi Hacker: Ui xời, tui có khóa riêng nên giải ra được mật khẩu chung giữa chúng ta là password "1" chứ gì, đây tui dùng password "1" để mã hóa một gói tin rùi đưa ông giải mã thử nè [nội-dung-tào-lao-bí-đao-của-Bích]{password "1"}
Hacker chuyển tiếp cho An và chèn thêm thứ linh tinh mình thích vào: Ui xời, tui có khóa riêng nên giải ra được mật khẩu chung giữa chúng ta là password "1" chứ gì, đây tui dùng password "1" để mã hóa một gói tin rùi đưa ông giải mã thử nè chèn-thêm-nội-dung-tào-lao-bí-đao-của-hacker[nội-dung-tào-lao-bí-đao-của-Bích]{password "1"}Đấy chính là vấn đề, tức là sau khi An kiếm tra biết được đối tượng mình đang nói chuyện là Bích thì trở nên tin tưởng vào những gì Bích nói sau khi đã xác minh thành công, hacker chỉ cần đứng giữa trung gian và chờ đợi đến lúc họ xác minh xong lẫn nhau hacker có thể tùy quyền chèn thêm dữ liệu xấu vào gói tin gửi về cho An, tức là gói tin dù đã mã hóa bằng password "1" ví dụ: "sth ah fzx qnh" hacker có thể chả hiểu nó nói gì nhưng hacker có thể chèn thêm những thứ mà mình muốn nữa ví dụ thành "sth ah fzx qnh tui may noi cai gi vay"
Vậy cách nào để giải quyết vấn đề này? An và Bích sẽ dùng thêm mã xác thực thông điệp (Message Authentication Code), mã này định nghĩa như sau:
Message Authentication Code = md5(nội-dung-tào-lao-bí-đao-của-Bích, password "1")Tức là dựa vào việc hacker không biết mật khẩu mà An đã chọn là password "1" nên Bích có thể băm (thông tin mà Bích muốn gửi + với mật khẩu mà An đã chọn) để có được một trường kiểm tra tính toàn vẹn của gói tin cho An, An mỗi lần nhận tin thì nên kiểm tra vấn đề này để biết gói tin có toàn vẹn hay đã bị cắt xén, mô hình này giờ diễn ra như sau:
An gửi Hacker: Chào đằng ấy, ai vậy? Tui bị mù!
Hacker chuyển tiếp cho Bích: Chào đằng ấy, ai vậy? Tui bị mù!
Bích gửi Hacker: Chào ông tui Bích đây! Đây là khóa chung công khai của tui!
Hacker chuyển tiếp cho An: Chào ông tui Bích đây! Đây là khóa chung công khai của tui!
An gửi Hacker: Uh, khóa chung công khai của bà rất chuẩn xanh lè trên toàn thế giới, giờ bà chứng minh là bà có giữ khóa riêng bí mật của khóa chung công khai này đi!
Hacker chuyển tiếp cho Bích: Uh, khóa chung công khai của bà rất chuẩn xanh lè trên toàn thế giới, giờ bà chứng minh là bà có giữ khóa riêng bí mật của khóa chung công khai này đi!
Bích gửi Hacker: Được, tui gửi ông 2 thứ, ông xem và tính đây này:
"admin voduy.com rất đẹp trai"
hàm-mã-hóa-bằng-khóa-riêng{-----md5(admin voduy.com rất đẹp trai)------}
Hacker chuyển tiếp cho An: Được, tui gửi ông 2 thứ, ông xem và tính đây này:
"admin voduy.com rất đẹp trai"
hàm-mã-hóa-bằng-khóa-riêng{-----md5(admin voduy.com rất đẹp trai)------}
An gửi Hacker: Uh, trông có vẻ an toàn rồi, bà là bà Bích chắc cú, đây là mật khẩu chung giữa chúng ta mà tôi đã chọn và đã được mã hóa bằng khóa công khai của bà, bà có khóa riêng của bà Bích thì mới giải mã mà biết được nhé, đây nè {password "1"}khóa-công-khai-của-Bích
Hacker chuyển tiếp cho Bích: Uh, trông có vẻ an toàn rồi, bà là bà Bích chắc cú, đây là mật khẩu chung giữa chúng ta mà tôi đã chọn và đã được mã hóa bằng khóa công khai của bà, bà có khóa riêng của bà Bích thì mới giải mã mà biết được nhé, đây nè {password "1"}khóa-công-khai-của-Bích
Bích gửi Hacker: Ui xời, tui có khóa riêng nên giải ra được mật khẩu chung giữa chúng ta là password "1" chứ gì, đây tui dùng password "1" để mã hóa một gói tin rùi đưa ông giải mã thử nè, nhưng có thêm cái mã md5 cho chắc cú để ông kiểm tra tính toàn vẹn gói tin tui gửi: [nội-dung-tào-lao-bí-đao-của-Bích, md5(nội-dung-tào-lao-bí-đao-của-Bích, password "1")]{password "1"}
Hacker chuyển tiếp cho An và chèn thêm thứ linh tinh mình thích vào: Ui xời, tui có khóa riêng nên giải ra được mật khẩu chung giữa chúng ta là password "1" chứ gì, đây tui dùng password "1" để mã hóa một gói tin rùi đưa ông giải mã thử nè, nhưng có thêm cái mã md5 cho chắc cú để ông kiểm tra tính toàn vẹn gói tin tui gửi: chèn-thêm-nội-dung-tào-lao-bí-đao-của-hacker[nội-dung-tào-lao-bí-đao-của-Bích, md5(nội-dung-tào-lao-bí-đao-của-Bích, password "1")]{password "1"}An nhận được gói tin bị chèn của hacker, An tiến hành giải mã bằng password "1" An sẽ phát hiện ra ngay rằng md5(nội-dung-tào-lao-bí-đao-của-Bích, password "1") không hề trùng khớp với md5(nội-dung-tào-lao-bí-đao-của-Bích + chèn-thêm-nội-dung-tào-lao-bí-đao-của-hacker, password "1"). Cụ thể gói tin An nhận được từ hacker là "sth ah fzx qnh tui may noi cai gi vay" chẳng hạn, kiểm tra lại md5(sth ah fzx qnh, password "1") sẽ khác ngay md5(sth ah fzx qnh tui may noi cai gi vay, password "1")
Kết
Tuy là Hacker tạm thời ngậm ngùi tập 4 vì bị tóm gáy nhưng chắc chắn trong tương lai hoặc ở thế giới ngầm hiện tại đâu ai có thể biết được chuyện gì đã đang và sẽ xảy ra, liệu cơ chế SSL có an toàn 100% như nguyên lý hay không?
Mặc dù những bộ óc lỗi lạc nhất thế giới hiện tại đã chấp nhận rằng giao thức này đáp ứng được tất thảy tiêu chuẩn an toàn đầu cuối và đáng tin dùng nhưng chính sự đáng tin cậy của cơ chế SSL này mà thông qua đó lỗ hổng lại có thể xuất hiện, mình giả sử như thế này:
Bạn sử dụng một server mail Google, Hotmail, Facebook,… hoặc giao dịch tại ngân hàng abc.com của bạn, họ có mua chứng chỉ SSL từ Comodo chẳng hạn và bạn tiến hành gửi mail có nội dung rất nhạy cảm trong quốc gia của mình cho ai đó thông qua họ. Mỗi một lần bạn login vào trang duyệt mail của bạn, bạn làm sao có thể chắc chắn đó là trang duyệt mail của server mail Google, Hotmail, Facebook của bạn? Thật ngây thơ khi chỉ dựa vào màu xanh trên trình duyệt ^_^
Giả sử nước Mỹ chẳng hạn họ hoàn toàn dư khả năng và quyền lực tạo ra một đơn vị chứng chứng chỉ Certificate Authority xanh lè trên toàn thế giới, họ chỉ cần tự tạo ra một cặp chứng chỉ và nhờ vào đơn vị cấp chứng chỉ đó chứng thực cho nó xanh lè bởi vì cơ chế kiểm tra chứng chỉ hợp lệ của Chrome và Firefox là chỉ cần một đơn vị nào đó trong nhiều đơn vị đã chứng thực một chứng chỉ là hợp lệ thì không phải cần tất cả các bên khác phải chứng thực.
Ví dụ Let’s Encrypt đã chứng thực một chứng chỉ là xanh thì dù Comodo không chứng thực, chứng chỉ đó vẫn là chứng chỉ hợp lệ xanh mà thôi.
Bạn đã từng nghe những vụ hack vào các bên thứ 3 cung cấp chứng chỉ Certificate Authority xanh lè trên toàn thế giới chưa? Nếu họ hack vào và tự chứng cho một domain bất kỳ thế là họ đã có HTTPS của một website bất kỳ và điều hướng ta đến server giả của họ và khi trình duyệt chúng ta vào nó có màu xanh lè một cách thản nhiên thì liệu bạn có tin tưởng vào website đó không?
Bởi vậy sự tự động không phải lúc nào cũng hoàn hảo, là một người sử dụng thông minh bạn phải tìm hiểu hết tất cả nhưng khả năng có thể xảy ra của những vấn đề công nghệ. Trong trường hợp này nếu không tin vào nước Mỹ hoặc bất kỳ một tổ chức quốc gia nào khác bạn có thể quay về với chứng chỉ tự ký tự chứng của riêng mình, tự tạo chứng chỉ và yêu cầu khách hàng tự add sẳn chứng chỉ mỗi khi giao dịch vào máy chủ của bạn không cần một bên nào chứng cho bạn cả, chỉ có bạn và khách hàng tự chứng thực lẫn nhau.
