NỘI DUNG
Như đã hứa hẹn trong Giải ngố WWW – Phần 2: 4 điều cơ bản phải biết về HTTP, kỳ này tôi sẽ bàn về cái Hypertext Transfer Protocol Secure – HTTPS (Giao thức truyền tải siêu văn bản bảo mật). Vấn đề tôi muốn tập trung ở đây là cái chữ `Secure`, có thêm cái chữ `S` này thì được cái gì. Và quan trọng nhất là cái gì xảy ra khi bạn truy cập vào một website HTTPS.
#1. Con đường đi lên HTTPS của HTTP
#1.1 Nguyên lý hoạt động của HTTPS
HTTP sử dụng giao thức TCP đơn thuần làm cơ chế vận chuyển. HTTPS thì lại kiểu như VPN (bạn có thể xem thêm về Sê-ri VPN nếu cần), nghĩa là cái luồng HTTP thay vì đi nghênh ngang đầy hớ hênh ngoài đường thì giờ nó chui vô một cái “đường hầm” của cơ chế vận chuyển bảo mật có tên gọi là Secure Sockets Layer – SSL hay cập nhật hơn Transport Layer Security – TLS. Cơ chế này có nghĩa vụ cao cả là để bảo vệ tính riêng tư cũng như toàn vẹn của dữ liệu đang được vận chuyển. Ngoài cái vụ “đường hầm” này, các nội dung quan trọng khác như HTTP Request và HTTP Response vẫn như hoạt động như khi không có SSL/TLS.
#1.2 So sánh HTTP và HTTPS
Có nhiều vấn đề về sự khác biệt của HTTP và HTTPS , nhưng tôi nghĩ các điểm quan trọng cần lưu ý bao gồm.
Thông tin | HTTP | HTTPS |
Cổng mặc định | 80 | 443 |
Khả năng đáp ứng | Đáp ứng cho các trang web thông thường chỉ xem thông tin. | Tối quan trọng khi tương tác với những trang web cần trao đổi các thông tin nhạy cảm như thông tin cá nhân, thông tin thanh toán, thông tin đăng nhập
|
Mã hóa dữ liệu | Không | Có |
Vấn đề bảo mật | Dễ bị các đối tượng bên ngoài chọc ngoáy vào dữ liệu đang vận chuyển | Khó bị các đối tượng bên ngoài chọc ngoáy vào dữ liệu đang vận chuyển |
#2. SSL và TLS
#2.1 SSL và TLS có phải là bà con họ hàng không?
Cái SSL này nguyên thủy là hàng “thủ công mỹ nghệ” của công ty Netscape hướng tới phục vụ cho Web Browser của ổng. Dù ông Netscape đã banh rồi nhưng SSL vẫn được đông đảo người hâm mộ sử dụng. Do vậy, tổ chức Internet Engineering Task Force – IETF đã nhận nhiệm vụ cao cả là chuẩn hóa các cải tiến cho SSL để tạo ra TLS.
Như vậy, hiểu đơn giản thì TLS là phiên bản cập nhật cho SSL ví dụ TLS 1.0 là bản cập nhật của SSL 3.0 nên có thể xem là SSL 3.1. Dù hiện tại SSL đã bị thay thế bởi TLS tuy nhiên có thể do quen tay nên bạn vẫn thấy người ta hay ghi SSL hoặc SSL/TLS thay vì chỉ đơn thuần là TLS.
Chuyện bên lề:
*1: Công ty Netscape thuộc hàng gạo cội trong lĩnh vực công nghệ thời kỳ đầu của Internet (chắc cũng cỡ Google/Microsoft/Amazon trong giai đoạn hiện nay), còn giờ thì ổng chỉ còn là dĩ vãng thôi.
*2: IETF không phải chỉ có mỗi “tác phẩm” TLS, bạn có thể tìm được cả tỉ thứ hay ho như các chuẩn về Internet ở link https://www.ietf.org.
#2.2 Nguyên lý hoạt động của SSL/TLS
SSL/TLS là giao thức sử dụng để mã hóa data-in-transit (dữ liệu trong quá trình vận chuyển) nói chung. Như vậy bạn cần nhớ ngoài HTTPS, SSL/TLS vẫn có thể sử dụng cho các giao thức khác như File Transfer Protocol Secure – FTPS (Truyền tải file bảo mật).
Về cơ bản, SSL và TLS đều thuộc dạng xác thực Certificate-based (yêu cầu phải có Certificate Authorities – CAs phát hành và quản lý các Certificate). SSL/TLS mã hóa bằng cách sử dụng kết hợp Symmetric và Asymmetric Encryption như sau:
– Sử dụng Asymmetric Encryption để trao đổi Sesion Key (khóa cho phiên làm việc này thuộc nhóm Symmetric Encryption Key);
– Sử dụng Symmetric Encryption Key đã trao đổi để mã hóa dữ liệu hiển thị trên trang web cũng như trong quá trình vận chuyển dữ liệu thuộc 1 phiên làm việc.
Bạn có thể xem kỹ hơn về Symmetric và Asymmetric Encryption như tôi tóm lược ở nội dung Giải ngố Blockchain – Phần 3: Nguyên lý cơ bản của Elliptic Curve Cryptography và vấn đề mã hóa.
#3. Điều gì xảy ra khi truy cập HTTPS website
Sử dụng nguyên lý trình bày ở Mục #2.2, quá trình chi tiết các bước khi bạn truy cập HTTPS website như sau:
Nguồn: CompTIA Security+ Get Certified Get Ahead
– Bước 1: Client gửi Request một HTTPS Session thông qua việc nhập URL hay click vào HTTPS link;
– Bước 2: Server gửi Response chứa Server Certificate. Certificate sẽ bao gồm cái Public Key của Server. Đây là lúc mà Server trao đổi Asymmetric Encryption Key (nó chính là cái Public Key nói trên) với Client để sử dụng cho các bước tiếp theo;
– Bước 3: Client tạo Symmetric Encryption Key sau đó mã hóa cái key này bằng cái Public Key của Server. Trong hình minh họa trên, cái Symmetric Encryption Key đã mã hóa là `UcaNP@$$ `. Đồng thời, cái Symmetric Encryption Key này cũng sẽ được sử dụng để mã hóa dữ liệu trong một HTTPS Session (do vậy nó còn được gọi là Session Key);
– Bước 4: Client gửi cái Session Key đã mã hóa (`UcaNP@$$ `) đến Server;
– Bước 5: Lúc này, Server sử dụng Private Key tương ứng với cái Publick Key đã gửi ở Bước 1 để giải mã cái Session Key đã mã hóa. Đây chính là điểm then chốt để bảo vệ luồng dữ liệu trao đổi giữa Client và Server trước các cặp mắt thèm thuồng của các thế lực hắc ám trên Internet. Như vậy đến đây, cả Client và Server đều đã có Session Key cho phiên làm việc;
– Bước 6: Client và Server bắt đầu phiên làm việc và trao đổi dữ liệu mã hóa với Session Key.
Góc trợ giúp:
Nếu bạn thấy rối não với cặp Public/Private Key này quá thì có thể xem thêm về cái Sê-ri Pretty Good Privacy này cho rõ.
Bạn thấy đấy, ngay sau khi bạn nhập URL và nhấn Enter hay Click chuột vô HTTPS link, Client và Server phải è cổ ra xử lý cả đống thứ để phục vụ bạn. Vậy nên, lần tới truy cập các HTTPS website, nếu tốc độ tải trang không nhanh như mong đợi thì ráng sống chậm tí chứ đừng chửi đổng lên nhé.
3 thoughts on “Giải ngố WWW – Phần 3: HTTPS có gì ngon hơn HTTP”