Hiểu cách https làm việc
Ref:
Nếu bạn thuộc phần còn lại thì tôi nghĩ bạn đã đọc đúng bài báo này bằng tiếng Việt
Tôi sẽ nói vấn đề Http trước và tại sao cần phải loại bỏ ngay khi nếu hệ thống có dùng một phương thức truy cập nào đó mà cần người dùng xác thực.
Tiếp theo sẽ là vấn đề Https mà người dùng tự Generate Cert rồi add vào server và dùng nó như là một Cert bảo mật dữ liệu
Và cuối cùng là HTTPS và tại sao nó lại cần thiết trong internet hiện nay. Bạn phải bắt buộc dùng nó như là một cách bảo mật truy cập hệ thống.
Let's start
1. HTTP
Bạn biết rằng HTTP đã phát triển rất lâu và cho đến thời điểm này các hệ thống vẫn dùng http do một trong những lý do sau (tôi chủ quan liệt kê)
- Một phần là do hệ thống đó chỉ cung cấp tin tức hoặc dữ liệu công khai, không nhạy cảm
- Do người admin hệ thống không hiểu đến bảo mật và tính an toàn cho người dùng hệ thống
- Hoặc do người admin hệ thống đó không am hiểu về việc thiết lập HTTPs
Bạn cũng biết HTTP nó là một giao thức truyền tải dữ liệu qua mạng và điểu nguy hiểm là dữ liệu nó truyền là dữ liệu thô, không mã hóa. Điều này dẫn đến việc dữ liệu người dùng trùyền lên hệ thống hoặc hệ thống trả về đều có thể bị kẻ trung gian đánh cắp hoặc nguy hiểm hơn là bị chỉnh sửa.
Bạn tưởng tượng nếu một Ngân hàng ABCXYZ nào đó dùng HTTP thông thường và cho bạn chuyển khoản trên đó. Và khi bạn chuyển khoản thì kẻ trung gian hoàn toàn có thể bắt gói tin trung gian và chuyển đổi dữ liệu gói tin, thay vì bạn chuyển tới 1 số TK 123xxx thì hacker sẽ sửa sang số của Hacker là 8888xxx. và bạn sẽ mất tiền oan mà không biết gì. Lỗi này hoàn toàn là do phía Ngân hàng không có cơ chế bảo mật đường truyền.
Nên đứng vai trò là người dùng thì bạn cũng nên dùng trí não của mình để nhận biết, nếu trang web dùng HTTP thì bạn không nên dùng trang web đó để thực hiện xác thực cũng như lưu trữ thông tin nhạy cảm.
Dấu hiệu
2. HTTPS tự động generate
Khi bạn dùng HTTPS là đồng nghĩa với việc dữ liệu trên đường truyền của bạn đã được mã hóa tới 99,99% (con số này mang tính tương đối chủ quan của tôi, nó chỉ là tương đối). Nhưng nó không đồng nghĩa với việc bạn an toàn trong 0.01% thông tin bạn truyền đi hoặc nhận được không mã hóa.
Và chính điều đó 0.01% sẽ được hacker họ khai thác và họ sẽ phá tan con số 99,99% an toàn kia của bạn.
Tôi sẽ giải thích cho bạn như sau về cơ chế HTTPS tự generate CERT.
CERT chính là một file mà có chứa Private key và public key sẽ dùng trong hệ thống server và client truy cập hệ thống.
Khi 1 Client bất kì truy cập hệ thống, Server sẽ trả về cho client Public Key. Client sau đó sẽ tạo ra 1 Session Key và mã hóa khóa này bằng Public Key nhận được. Rồi sau đó gửi cái đoạn mã hoá đó lên server. Server nhận được và giải mã bằng Private Key mà chỉ Server biết. Nó sẽ lấy đc Session Key và dùng nó để mã hóa dữ liệu trả về cho Client hoặc để giải mã dữ liệu Client truyền lên trong 1 session.
Về cơ bản là bạn sẽ thấy khá Ok không vấn đề gì. vì dữ liệu đã được mã hóa bằng Session Key mà chỉ Client và Server biết. Hacker có lấy được đoạn thông tin được mã hóa đó cũng không giải mã được. Hoàn toàn chính xác!
Nhưng vấn đề là 0.01% ở chỗ nào???? Nó chính là lúc mà Server gửi Public Key cho Client. ĐIều gì nếu Hacker là kẻ trung gian và lắm được Public Key. vì lúc này Public key chưa được mã hóa nhé.
Sau khi Hacker nó lấy đc Public key thì nó sẽ gửi cho Client 1 Public Key khác của nó.
Sau đó Client nhận được và nghĩ rằng đó là từ Server trả về. Nó dùng để mã hóa Session Key rồi gửi lên Server. Nhưng bản tin lại bị Hacker tóm được. (vì hacker nó nằm ở trung gian là con Router nhà bạn). Hacker giả mã được session key bằng Private Key riêng của hacker và nó lại mã hóa cái Session Key đó bằng Public Key của Server trả mà nó bắt được trước đó. Và Server nhận được cũng tưởng là do Client truyền nên. Và thế là Client và Server đã bị qua mặt rõ ràng.
Như vậy cái 0.01% đó đã bị hacker khai thác. Bạn đã bị mất an toàn khi dùng HTTPS tự generate
Do vậy bạn cũng nên nhớ không nên dùng hệ thống HTTPs tự gen như vậy, Dấu hiện phát hiện là
3. HTTPS có Cert từ CA
Tôi sẽ giải thích tại sao 0.01% được giải quyết khi có CA tham gia hỗ trợ.
1 số CA nổi tiếng mà bạn nên mua SSL CERT từ đó như Comodo, Let's Crypt, ....
Bạn thấy vấn đề là Public Key khi server trả về cho Client chưa được mã hóa. Vậy làm cách nào để mã hóa nó và xác thực đó chính là Public Key của Server bạn đang muốn truy cập chứ không phải là của một kẻ thứ 3 đang đánh lừa.
Bạn nên biết rằng để làm được điều này thì Các trình duyệt hiện đại như Chorme hoặc Firefox đã hợp tác với các cơ quan CA (Chính là các cơ quan mà bạn mua chứng thực SSL bên trên).
Khi 2 bên đã thỏa thuận OK thì sẽ có một cặp Public Key và Private Key được sử dụng
+ phía Trình duyệt sẽ cầm Public Key của cơ quan CA.
+ phía CA sẽ giữ Private Key của riêng họ. (Private Key này dùng để ký chữ ký cho các CERT mà các website đã mua SSL từ CA đó)
Các bước thực hiện như bên dưới.
1. Khi một người truy cập 1 website ví dụ Facebook đã chứng thực SSL bởi 1 CA Comodo
2. Facebook server sẽ trả về một CERT có chứa Public Key của Facebook và chữ ký của CA cho cái Public key đó( Nhớ rằng CA dùng Private Key của riêng họ để ký Public Key của Facebook)
3. Sau đó phía Client sẽ nhận được CERT đó
Giả sử nếu Hacker bắt được Cert và định thay đổi Public Key của Facebook rồi trả lại cho Client, thì nó cần phải biết được Private Key của CA để tạo chữ ký mới. Nhưng điều này là bất khả thi. Vì Private Key của CA đã đc giữ bí mật.
Vậy là Hacker không thể chỉnh sửa được Public Key của Facebook
4. Sau đó Client trình duyệt sẽ dùng Public Key của CA đã thỏa thuận để verify CERT mà nó nhận được
Nếu nó verify chữ ký mà không khớp với Chữ ký trong Cert thì chứng tỏ CERT đã bị thay đổi
Nếu verify thành công thì Client sẽ tạo một Session Key và mã hóa bằng Public Key trong CERT và gửi trả lại Server Facebook
Tình huống này nếu Hacker lại tóm được Session Key đã mã hóa thì nó cũng không thể giải mã được,
Vì Facebook đã nắm giữ Private Key của riêng họ.
Khi 2 bên đã thỏa thuận OK thì sẽ có một cặp Public Key và Private Key được sử dụng
+ phía Trình duyệt sẽ cầm Public Key của cơ quan CA.
+ phía CA sẽ giữ Private Key của riêng họ. (Private Key này dùng để ký chữ ký cho các CERT mà các website đã mua SSL từ CA đó)
Các bước thực hiện như bên dưới.
1. Khi một người truy cập 1 website ví dụ Facebook đã chứng thực SSL bởi 1 CA Comodo
2. Facebook server sẽ trả về một CERT có chứa Public Key của Facebook và chữ ký của CA cho cái Public key đó( Nhớ rằng CA dùng Private Key của riêng họ để ký Public Key của Facebook)
3. Sau đó phía Client sẽ nhận được CERT đó
Giả sử nếu Hacker bắt được Cert và định thay đổi Public Key của Facebook rồi trả lại cho Client, thì nó cần phải biết được Private Key của CA để tạo chữ ký mới. Nhưng điều này là bất khả thi. Vì Private Key của CA đã đc giữ bí mật.
Vậy là Hacker không thể chỉnh sửa được Public Key của Facebook
4. Sau đó Client trình duyệt sẽ dùng Public Key của CA đã thỏa thuận để verify CERT mà nó nhận được
Nếu nó verify chữ ký mà không khớp với Chữ ký trong Cert thì chứng tỏ CERT đã bị thay đổi
Nếu verify thành công thì Client sẽ tạo một Session Key và mã hóa bằng Public Key trong CERT và gửi trả lại Server Facebook
Tình huống này nếu Hacker lại tóm được Session Key đã mã hóa thì nó cũng không thể giải mã được,
Vì Facebook đã nắm giữ Private Key của riêng họ.
--> mọi thứ hoàn hảo khi có CA và trình duyệt hợp tác để lắm giữ Key riêng.
Tóm lại là bạn có thể An toàn với 0.01% còn lại khi bạn truy cập 1 website mà có HTTPS đã chứng thực bởi 1 CA uy tín
Đó là lý do tại sao các Công Ty phải mất tiền để trả cho các cơ quan chứng thực SSL để được an toàn là vậy.
Tuy nhiên thì bạn cũng chỉ nên dùng các trình duyệt nổi tiếng đáng tin cậy nhé. ví dụ như Chorme hoặc Firefox để thực hiện giao dịch
Tuy nhiên thì bạn cũng chỉ nên dùng các trình duyệt nổi tiếng đáng tin cậy nhé. ví dụ như Chorme hoặc Firefox để thực hiện giao dịch
Nếu bạn muốn hiểu hơn về Chữ ký số thì bạn có thể tham khảo tại link sau:
Comments
Post a Comment