Trang này được dịch bởi Cloud Translation API.

Gây nhầm lẫn cho những bên trung gian độc hại nhờ khả năng bảo mật truyền tải nghiêm ngặt HTTPS và HTTP

Mike West

Với lượng dữ liệu cá nhân lưu chuyển qua một loạt hệ thống lớn liên quan đến Internet, việc mã hoá không phải là điều mà chúng ta có thể hoặc nên bỏ qua. Các trình duyệt hiện đại cung cấp một số cơ chế mà bạn có thể sử dụng để đảm bảo dữ liệu của người dùng được bảo mật trong khi truyền: cookie bảo mật và Bảo mật truyền tải nghiêm ngặt là hai trong số những cơ chế quan trọng nhất. Các API này cho phép bạn bảo vệ người dùng một cách liền mạch, nâng cấp kết nối của họ lên HTTPS và đảm bảo rằng dữ liệu người dùng không bao giờ được gửi đi một cách rõ ràng.

Tại sao bạn nên quan tâm? Hãy cân nhắc những gợi ý sau:

Việc cung cấp một trang web qua kết nối HTTP chưa mã hoá cũng giống như việc đưa một phong bì chưa niêm phong cho người đầu tiên mà bạn nhìn thấy trên đường, người trông giống như cô đang đi theo hướng bưu điện. Nếu bạn may mắn, cô ấy có thể tự mình đi tới đó hoặc chuyển nó cho người tiếp theo mà cô ấy thấy đang đi đúng hướng. Người đó có thể làm tương tự và cứ tiếp tục như vậy.

Hầu hết những người lạ trong chuỗi thư ngẫu nhiên này đều đáng tin cậy và sẽ không bao giờ xem nhanh hoặc thay đổi thư ngỏ của bạn. Tuy nhiên, càng nhiều lần thư đổi tay thì số người có quyền truy cập đầy đủ vào thư bạn gửi càng lớn. Cuối cùng, có nhiều khả năng người nhận thư của bạn sẽ nhận được một điều gì đó qua thư, nhưng liệu điều đó có giống một điều gì đó mà bạn đã chuyển giao lúc đầu thì là một câu hỏi mở. Có lẽ anh nên niêm phong phong bì đó...

Người trung gian

Dù nhiều hay ít thì mạng Internet đều phụ thuộc vào sự đáng tin cậy của người đi đường. Các máy chủ không được kết nối trực tiếp với nhau nhưng truyền các yêu cầu và phản hồi từ bộ định tuyến đến bộ định tuyến trong một trò chơi Điện thoại khổng lồ.

Bạn có thể xem các bước này trong thực tế bằng traceroute. Tuyến đường từ máy tính của tôi đến HTML5Rocks trông giống như sau:

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

13 bước nhảy không tệ lắm. Tuy nhiên, nếu tôi đang gửi yêu cầu qua HTTP, thì mỗi bộ định tuyến trung gian đó sẽ có toàn quyền truy cập vào các yêu cầu của tôi và đến phản hồi của máy chủ. Tất cả dữ liệu đang được chuyển dưới dạng văn bản thuần tuý không mã hoá và bất kỳ bên trung gian nào trong số đó cũng có thể đóng vai trò là Người đứng giữa, đọc dữ liệu của tôi hay thậm chí là thao túng dữ liệu đó trong quá trình truyền.

Tệ hơn, kiểu can thiệp này gần như không thể phát hiện được. Phản hồi HTTP bị sửa đổi độc hại trông giống hệt như một phản hồi hợp lệ, vì không có cơ chế nào cho phép bạn đảm bảo rằng dữ liệu nhận được đúng _dữ liệu đã gửi. Nếu ai đó quyết định lật ngược mạng Internet của tôi để có những tiếng cười, thì tôi sẽ ít gặp may mắn hơn.

Đây có phải là đường dây an toàn không?

Việc chuyển từ HTTP văn bản thuần tuý sang kết nối HTTPS bảo mật sẽ mang lại khả năng bảo vệ tốt nhất trước những bên trung gian. Các kết nối HTTPS mã hoá hai đầu toàn bộ kênh trước khi bất kỳ dữ liệu nào được gửi, khiến các máy giữa bạn và đích đến không thể đọc hoặc sửa đổi dữ liệu trong quá trình truyền.

Thanh địa chỉ của Chrome cung cấp khá nhiều chi tiết về trạng thái của kết nối. — Thanh địa chỉ của Chrome cung cấp khá nhiều thông tin chi tiết về trạng thái của kết nối.

Phương thức bảo mật mà HTTPS cung cấp bắt nguồn từ khái niệm khoá mã hoá công khai và riêng tư. Việc thảo luận sâu về các chi tiết (rất vui) nằm ngoài phạm vi của bài viết này, nhưng tiền đề cốt lõi thì khá đơn giản: dữ liệu được mã hoá bằng một khoá công khai nhất định chỉ có thể được giải mã bằng khoá riêng tư tương ứng. Khi trình duyệt khởi động quá trình bắt tay HTTPS để tạo kênh bảo mật, máy chủ sẽ cung cấp một chứng chỉ, giúp cung cấp cho trình duyệt tất cả thông tin cần thiết nhằm xác minh danh tính bằng cách kiểm tra để đảm bảo rằng máy chủ đang sở hữu khoá riêng tư thích hợp. Mọi hoạt động giao tiếp từ điểm đó trở đi đều được mã hoá theo cách chứng minh rằng các yêu cầu được gửi đến và phản hồi nhận được từ máy chủ đã xác thực.

Do đó, HTTPS đảm bảo rằng bạn đang trò chuyện với máy chủ mà bạn nghĩ là mình đang nói chuyện và không có ai khác đang lắng nghe hoặc chuyển các bit trên dây. Loại hình mã hoá này là điều kiện tiên quyết tuyệt đối để bảo mật trên web; nếu ứng dụng của bạn hiện không được phân phối qua HTTPS, thì ứng dụng đó rất dễ bị tấn công. Khắc phục. Ars Technica có một hướng dẫn rất hữu ích để lấy và cài đặt chứng chỉ (miễn phí) mà bạn nên xem để biết thông tin kỹ thuật. Cấu hình sẽ khác nhau giữa các nhà cung cấp và máy chủ này, nhưng quy trình yêu cầu chứng chỉ đều giống nhau ở mọi nơi.

Bảo mật là điều tất yếu

Sau khi yêu cầu và cài đặt chứng chỉ, hãy đảm bảo người dùng của bạn được hưởng lợi từ công việc khó khăn của bạn: di chuyển người dùng hiện tại của bạn sang kết nối HTTPS một cách minh bạch thông qua sự kỳ diệu của lệnh chuyển hướng HTTP và đảm bảo rằng cookie chỉ được phân phối qua kết nối an toàn.

Bằng cách này, vui lòng

Khi người dùng truy cập http://example.com/, hãy chuyển hướng họ đến https://example.com/ bằng cách gửi phản hồi 301 Moved Permanently có tiêu đề Location thích hợp:

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

Bạn có thể dễ dàng thiết lập cách chuyển hướng này trong các máy chủ như Apache hoặc Nginx. Ví dụ: một cấu hình Nginx chuyển hướng từ http://example.com/ đến https://example.com/ sẽ có dạng như sau:

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

Khoá hộp bánh quy

Cookie cho phép chúng tôi cung cấp cho người dùng trải nghiệm đăng nhập liền mạch qua giao thức HTTP không có trạng thái. Dữ liệu được lưu trữ trong cookie, bao gồm cả thông tin nhạy cảm như mã phiên, được gửi cùng với mọi yêu cầu, cho phép máy chủ biết được người dùng nào đang phản hồi tại thời điểm này. Sau khi chắc chắn rằng người dùng truy cập trang web của chúng tôi qua HTTPS, chúng tôi cũng phải đảm bảo rằng dữ liệu nhạy cảm lưu trữ trong cookie chỉ được chuyển qua một kết nối an toàn, chứ không bao giờ được gửi một cách rõ ràng.

Việc đặt cookie thường liên quan đến tiêu đề HTTP có dạng như sau:

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

Bạn có thể hướng dẫn trình duyệt hạn chế việc sử dụng cookie cho các phiên bảo mật bằng cách xử lý một từ khoá:

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

Những cookie được đặt bằng từ khoá bảo mật sẽ không được gửi qua HTTP.

Đóng cửa sổ đang mở

Việc chuyển hướng minh bạch sang HTTPS có nghĩa là phần lớn thời gian người dùng truy cập vào trang web của bạn đều sử dụng một kết nối an toàn. Tuy nhiên, việc này sẽ để lại một khoảng thời gian nhỏ cơ hội cho các cuộc tấn công: kết nối HTTP ban đầu đang mở rộng, dễ bị loại bỏ SSL và các cuộc tấn công liên quan. Vì một người đàn ông ở giữa có toàn quyền truy cập vào yêu cầu HTTP ban đầu, nên mã này có thể hoạt động như một proxy giữa bạn và máy chủ, giúp bạn duy trì kết nối HTTP không an toàn bất kể ý định của máy chủ là gì.

Bạn có thể giảm thiểu rủi ro của loại tấn công này bằng cách yêu cầu trình duyệt thực thi Bảo mật truyền tải nghiêm ngặt HTTP (HSTS). Việc gửi tiêu đề HTTP Strict-Transport-Security sẽ hướng dẫn trình duyệt thực hiện lệnh chuyển hướng HTTP sang HTTPS phía máy khách mà không cần chạm vào mạng (điều này cũng có thể giúp cải thiện hiệu suất; tốt nhất là bạn không cần phải đưa ra yêu cầu):

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

Các trình duyệt hỗ trợ tiêu đề này (hiện là Firefox, Chrome và Opera: caniuse có thông tin chi tiết) sẽ lưu ý rằng trang web cụ thể này đã yêu cầu quyền truy cập chỉ HTTPS, nghĩa là bất kể người dùng truy cập vào trang web bằng cách nào, họ sẽ truy cập qua HTTPS. Ngay cả khi nhập http://example.com/ vào trình duyệt, trẻ sẽ chuyển đến HTTPS mà không cần kết nối HTTP. Hơn thế, nếu trình duyệt phát hiện thấy một chứng chỉ không hợp lệ (có thể đang cố giả mạo danh tính của máy chủ), thì người dùng sẽ không được phép tiếp tục qua HTTP; tất cả đều không có gì hoặc không có gì xảy ra.

Trình duyệt sẽ hết hạn trạng thái HSTS của máy chủ sau max-age giây (trong ví dụ này khoảng một tháng); hãy đặt giá trị này ở mức hợp lý cao.

Bạn cũng có thể đảm bảo rằng tất cả miền con của một nguồn gốc đều được bảo vệ bằng cách thêm lệnh includeSubDomains vào tiêu đề:

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

Tiếp tục thật an toàn

HTTPS là cách duy nhất để đảm bảo từ xa rằng dữ liệu mà bạn gửi sẽ tiếp cận được người nhận mong muốn. Bạn nên thiết lập kết nối bảo mật cho trang web và ứng dụng của mình ngay hôm nay. Đây là một quy trình khá đơn giản và sẽ giúp giữ an toàn cho dữ liệu của khách hàng. Sau khi thiết lập một kênh được mã hoá tại chỗ, bạn nên chuyển hướng người dùng đến kết nối an toàn này một cách rõ ràng, bất kể họ truy cập vào trang web của bạn bằng cách nào bằng cách gửi phản hồi HTTP 301. Sau đó, hãy đảm bảo rằng tất cả thông tin về phiên nhạy cảm của người dùng chỉ sử dụng kết nối bảo mật đó bằng cách thêm từ khoá bảo mật khi đặt cookie. Sau khi làm xong, hãy đảm bảo rằng người dùng không bao giờ vô tình rời khỏi xe buýt: hãy bảo vệ họ bằng cách đảm bảo rằng trình duyệt của họ thực hiện đúng việc bằng cách gửi tiêu đề Strict-Transport-Security.

Việc thiết lập HTTPS không mất nhiều công sức và mang lại lợi ích to lớn cho trang web của bạn cũng như người dùng trang web. Hoàn toàn xứng đáng với nỗ lực đó.

Tài nguyên

StartSSL cung cấp các chứng chỉ miễn phí được xác minh bằng miền. Bạn không thể nào miễn phí được. Tất nhiên, việc nâng cấp lên cấp xác minh cao hơn tất nhiên là có thể và với mức giá hợp lý.
Kiểm tra máy chủ SSL: Sau khi đã thiết lập HTTPS cho máy chủ của mình, hãy xác minh rằng bạn đã thiết lập đúng cách bằng cách chạy giao thức này thông qua quy trình kiểm tra máy chủ của Phòng thí nghiệm SSL. Bạn sẽ nhận được báo cáo chi tiết đẹp cho biết liệu bạn có thực sự đang chạy hay không.
Bạn nên đọc bài viết "Bảo mật máy chủ web của bạn bằng SSL/TLS" gần đây để biết thêm thông tin cơ bản về các yếu tố cần thiết khi thiết lập máy chủ.
Bản đặc tả bảo mật truyền tải nghiêm ngặt HTTP (RFC6797) đáng để bạn đọc lướt tất cả thông tin kỹ thuật về tiêu đề Strict-Transport-Security mà có thể bạn muốn biết.
Khi bạn thực sự biết mình đang làm gì, một bước tiếp theo có thể là quảng cáo rằng trang web của bạn chỉ có thể truy cập được qua một bộ chứng chỉ cụ thể. Có một số công việc đang được triển khai tại IETF cho phép bạn thực hiện việc đó thông qua tiêu đề Public-Key-Pins; vẫn còn mới mẻ, nhưng vẫn thú vị và đáng theo dõi.