Buộc toàn bộ trang web https mà không chuyển hướng http sang https


14

Có rất nhiều cuộc thảo luận trong khi tôi đang nghiên cứu cách tạo toàn bộ trang web của mình https. Câu trả lời nhiều nhất là chuyển hướng http sang https (tệp .htaccess), điều này không tốt, vì không tốt khi thực hiện cùng một công việc hai lần (hai yêu cầu). Ngoài ra, "người đàn ông ở giữa" đầu tiên có http và tôi muốn trang web của tôi truy cập trực tiếp trên https. Có cách nào khác để tạo toàn bộ trang web của bạn https không và làm thế nào để làm điều này? Ví dụ: khi người dùng nhập vào example.com, example.com đó sẽ tự động chuyển sang https, mà không chuyển hướng từ http hoặc bất cứ điều gì khác trước?


nếu bạn không muốn mọi người được chuyển hướng đến https, thay vào đó bạn muốn điều gì xảy ra?
Michael Hampton

@MichaelHampton Có thể tôi đang hỏi người mới, nhưng thực tế tôi muốn "xóa" http, và điều duy nhất tồn tại là https. Hoặc nếu điều này là không thể, tôi chỉ có thể sử dụng chuyển hướng nếu nó đủ tốt để bảo mật. Tôi nghe nói rằng chuyển hướng http-> https không tốt lắm vì nó vẫn là http và lưu lượng có thể bị chặn trong quá trình chuyển hướng.
Marko Tamburic

Chuyển hướng vĩnh viễn HTTP 301 là bạn của bạn, chỉ cần đừng quên đặt hết hạn.
Marcel

Bạn chỉ có thể xóa http. Nhưng sau đó, người dùng chỉ nhận được một tin nhắn từ chối kết nối, nếu cô ấy không nhập https: // Đối với một số trang web thì điều này tốt hơn, vì bảo mật cao hơn. Nếu có sẵn phiên bản http, có thể xảy ra việc cookie được gửi với yêu cầu đầu tiên không được mã hóa. Đối với những thứ như hệ thống thư của công ty chỉ có https + đào tạo người dùng là ổn, đối với một trang web chung, bạn có thể sẽ mất rất nhiều khách truy cập.
Josef nói Phục hồi Monica

Afaik có thể thực hiện được với HTTP2, tuy nhiên nó vẫn không tránh được cuộc tấn công ssl dải (được mô tả trong các câu trả lời bên dưới).
peterh - Phục hồi Monica

Câu trả lời:



22

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security cho phép máy chủ của bạn chỉ ra rằng tên miền chỉ nên được truy cập qua HTTPS. Điều này chỉ áp dụng cho các yêu cầu tiếp theo, do đó sẽ có tải HTTP ban đầu, nhưng các yêu cầu trong tương lai sẽ tải HTTPS ngay cả khi ai đó đã gõ HTTP rõ ràng.

IE chưa hỗ trợ, nhưng tất cả các chuyên ngành khác đều có.


Nó vẫn không bảo vệ chống lại yêu cầu đầu tiên.
Jenny D

3
@JennyD Tôi đã nói chính xác điều đó trong câu trả lời của tôi rồi.
ceejayoz

@JennyD Ý bạn là gì khi "bảo vệ"? Một MiM không thể làm bất cứ điều gì chống lại chuyển hướng http -> https, trừ khi chúng gây rối với dns / định tuyến cục bộ và giả mạo toàn bộ miền của bạn. Trong trường hợp đó, việc bạn làm không thực sự quan trọng, vì máy chủ của bạn không bao giờ được truy cập.
Báo động đỏ

2
@JennyD Chà, HSTS thực sự là một giải pháp tốt hơn bài đăng của bạn, trong đó nói rằng "chuyển hướng là cách để làm điều đó". Chuyển hướng có thể là MITMed bất cứ lúc nào. Chuyển hướng với HSTS chỉ có thể là MITMed mỗi năm một lần cho mỗi người dùng + trình duyệt (hoặc bất kể thời gian hết hạn trên tiêu đề) - tất cả các lần khác không được yêu cầu.
ceejayoz

1
@MarkoTamburic Không có lý do gì bạn không thể kết hợp cả hai.
ceejayoz

7

Như những người khác đã nói, bạn không thể buộc người dùng chọn giao thức phù hợp. Nhưng khi người dùng cố gắng sử dụng HTTP, bạn nên làm gì? Chuyển hướng cũng không đủ, bởi vì kẻ tấn công ngồi giữa bạn và khách hàng có thể chặn chuyển hướng, vì vậy khách hàng không bao giờ nhìn thấy nó. Máy khách sẽ tiếp tục gửi HTTP đơn giản và kẻ tấn công sẽ loại bỏ lớp SSL khỏi máy chủ ( tấn công tước SSL ).

Cách chắc chắn duy nhất để ngăn chặn điều đó là không phục vụ HTTP . Không trả lời trên cổng 80, ngoại trừ có thể phục vụ trang văn bản đơn giản hướng người dùng thử lại bằng HTTPS (nhưng không cung cấp liên kết mà kẻ tấn công có thể thao túng). Điều này sẽ buộc người dùng nhập https://vào trình duyệt của họ, vì vậy họ sẽ bắt đầu kết nối với SSL và ngăn chặn cuộc tấn công MITM.


3
Tuy nhiên, đó là một sự đánh đổi vì hầu hết người dùng sẽ không gõ https://. Thay vào đó, họ sẽ nói "huh, trang web bị hỏng" và rời đi. Kịch bản trường hợp tốt nhất có thể có www.example.comphản hồi với cả HTTP và HTTPS, nhưng có ứng dụng tự chạy trên một cái gì đó giống như admin.example.comchỉ với HTTPS.
ceejayoz

Đã đồng ý. Trong thực tế, hầu như không ai làm điều này.
Andrew Schulman

Tôi thực sự không thấy làm thế nào mà nó sẽ trở thành bằng chứng MiM nữa. Nếu người đàn ông ở giữa có thể sửa đổi siêu liên kết của bạn để chỉ ra một nơi khác, điều đó có nghĩa là anh ta đang kiểm soát các gói đến của người dùng. Anh ta có thể dễ dàng chuyển hướng đến trang web của mình hoặc thêm bất kỳ siêu liên kết nào anh ta muốn, bất kể trang web đó trông như thế nào.
Báo động đỏ

Nhưng về mặt lý thuyết, không, nếu máy khách khởi tạo kết nối với SSL.
Andrew Schulman

3
điều đó đúng - nhưng nếu khách hàng khởi tạo SSL, OP không có vấn đề gì. Vấn đề của anh ta là khi họ khởi xướng mà không có SSL, và không có cách nào đáng tin cậy để đưa họ đến SSL nếu có một MiM chủ động phá hoại điều đó.
Báo động đỏ


1

ceejayoz có câu trả lời tốt nhất để ngăn chặn cuộc tấn công được đề cập cụ thể ở đây nhưng tôi cũng muốn chỉ ra những gì nhiều người ở đây đang thiếu mà về cơ bản là HTTP đã có phần khác. Bạn muốn làm một chuyển hướng 301 vĩnh viễn. Điều này nói với khách hàng để thực hiện thêm yêu cầu đến địa chỉ mới. Vì vậy, nếu ai đó gõ URL sai, họ sẽ thực hiện 2 yêu cầu NHƯNG, trong tương lai, một khách hàng tốt có nghĩa vụ phát hiện các yêu cầu tới URL đó và thực hiện yêu cầu chính xác thay vì để ngăn chặn mọi yêu cầu lãng phí hơn. Vấn đề là điều này chỉ dành cho URL chính xác đó. HSTS cải thiện sơ đồ này bằng cách nói, 'trong n giây tiếp theo cũng không cho phép bất kỳ kết nối không an toàn nào từ miền này'.

Người dùng không nên truy cập các trang web nhạy cảm tại các địa điểm không an toàn. Họ đặc biệt không nên đăng ký cho họ ở những địa điểm không an toàn. Đây là những nguyên tắc bảo mật người dùng cơ bản nên được dạy giống như, 'không mở tệp đính kèm từ các nguồn không đáng tin cậy'. Đó thực sự là câu trả lời tốt nhất để ngăn chặn các cuộc tấn công MiM cho các trang web chưa từng được truy cập.

Một lưu ý phụ, một số trình duyệt cải thiện điều này bằng cách nói rằng một số trang web đã biết luôn sử dụng HSTS. Thật không may, bạn không thể dễ dàng thêm mình vào danh sách này một cách dễ dàng.

Đọc thêm: http://coderrr.wordpress.com/2010/12/27/canonical-redirect-pitfall-with-http-strict-transport-security-and-some-solutions/

http://dev.chromium.org/sts

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.