Có phải là xấu khi chuyển hướng http sang https?

Tôi vừa cài đặt Chứng chỉ SSL trên máy chủ của mình.

Sau đó, nó sẽ thiết lập chuyển hướng cho tất cả lưu lượng truy cập trên miền của tôi trên Cổng 80 để chuyển hướng đến Cổng 443.

Nói cách khác, tất cả http://example.comlưu lượng truy cập của tôi hiện được chuyển hướng đến https://example.comphiên bản phù hợp của trang.

Việc chuyển hướng được thực hiện trong tệp Máy chủ ảo Apache của tôi với nội dung như thế này ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

Câu hỏi của tôi là, có bất kỳ hạn chế nào khi sử dụng SSL không?

Vì đây không phải là Chuyển hướng 301, tôi sẽ mất liên kết / xếp hạng trong công cụ tìm kiếm bằng cách chuyển sang https?

Tôi đánh giá cao sự giúp đỡ. Tôi đã luôn muốn thiết lập SSL trên một máy chủ, chỉ để thực hành nó và cuối cùng tôi đã quyết định làm nó tối nay. Nó dường như đang hoạt động tốt cho đến nay, nhưng tôi không chắc có nên sử dụng điều này trên mỗi trang hay không. Trang web của tôi không phải là Thương mại điện tử và không xử lý dữ liệu nhạy cảm; chủ yếu là về ngoại hình và sự hồi hộp khi cài đặt nó cho việc học.

VẤN ĐỀ CẬP NHẬT

Thật kỳ lạ Bing tạo ảnh chụp màn hình này từ trang web của tôi bây giờ rằng nó đang sử dụng HTTPS ở mọi nơi ...

Các [R]lá cờ riêng của nó là một 302chuyển hướng ( Moved Temporarily). Nếu bạn thực sự muốn mọi người sử dụng phiên bản HTTPS của trang web của bạn (gợi ý: bạn làm), thì bạn nên sử dụng [R=301]để chuyển hướng vĩnh viễn:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

A 301giữ cho tất cả các pageranks google-fu và kiếm được của bạn còn nguyên vẹn . Đảm bảo mod_rewriteđược bật:

a2enmod rewrite

Để trả lời câu hỏi chính xác của bạn:

Có phải là xấu khi chuyển hướng http sang https?

Trời ơi không. Nó rất tốt.

Trong khi tôi ủng hộ ý tưởng về các trang web chỉ SSL, tôi sẽ nói một nhược điểm là chi phí phụ thuộc vào thiết kế trang web của bạn. Ý tôi là ví dụ nếu bạn đang phục vụ nhiều hình ảnh riêng lẻ trong thẻ img, điều này có thể khiến trang web của bạn chạy chậm hơn rất nhiều. Tôi sẽ khuyên bất cứ ai sử dụng máy chủ chỉ SSL để đảm bảo chúng hoạt động như sau.

1. Kiểm tra toàn bộ trang web để biết các liên kết nội bộ và đảm bảo tất cả chúng đều sử dụng HTTPS nếu bạn chỉ định tên miền riêng của mình trong các liên kết, do đó bạn không gây ra chuyển hướng của riêng mình.
2. Cập nhật của bạn <meta property="og:url"để sử dụng phiên bản https của tên miền của bạn.
3. Nếu bạn sử dụng <base href=lại cập nhật để sử dụng HTTPS.
4. Cài đặt giao thức SPDY nếu có thể
5. Đảm bảo sử dụng các hình ảnh CSS Image nếu có thể, để giảm số lượng yêu cầu.
6. Cập nhật sơ đồ trang web của bạn để chỉ ra trạng thái https, do đó, các con nhện theo thời gian tìm hiểu thay đổi này.
7. Thay đổi tùy chọn Công cụ tìm kiếm như Công cụ quản trị trang web của Google để ưu tiên HTTPS
8. Trường hợp có thể giảm tải bất kỳ phương tiện chiến thuật nào đến các máy chủ HTNPS CDN.

Nếu những điều trên được giải quyết, thì tôi nghi ngờ bạn sẽ có nhiều vấn đề.

Tôi đã thiết lập https thì bạn nên sử dụng nó ở mọi nơi trên trang web. Bạn sẽ tránh được rủi ro về các vấn đề nội dung hỗn hợp và nếu bạn có sẵn các công cụ cần thiết, tại sao không làm cho toàn bộ trang web an toàn?

Về chuyển hướng từ http sang https, câu trả lời không đơn giản.

Chuyển hướng sẽ giúp người dùng của bạn dễ dàng hơn rất nhiều, họ chỉ cần nhập vào anysite.com và được chuyển hướng đến https.

Nhưng. Điều gì sẽ xảy ra nếu người dùng đôi khi ở trên một mạng không an toàn (hoặc gần với Troy Hunt và Dứa của anh ta )? Sau đó, người dùng sẽ yêu cầu http://whthingsite.com thoát khỏi thói quen cũ. Đó là http. Điều đó có thể bị xâm phạm. Chuyển hướng có thể trỏ đến https://whthingsite.com.some.infr Hạ tầng.long.strange.url.hacker.org . Đối với một người dùng bình thường, nó sẽ trông khá hợp pháp. Nhưng giao thông có thể bị chặn.

Vì vậy, chúng tôi có hai yêu cầu cạnh tranh ở đây: Để thân thiện với người dùng và được an toàn. May mắn thay, có một phương thuốc được gọi là tiêu đề HSTS . Với nó, bạn có thể kích hoạt chuyển hướng. Trình duyệt sẽ chuyển đến trang web bảo mật, nhưng nhờ tiêu đề HSTS cũng nhớ nó. Khi người dùng gõ vào anysite.com ngồi trên mạng không an toàn đó, trình duyệt sẽ truy cập https ngay lập tức mà không chuyển qua chuyển hướng qua http. Trừ khi bạn xử lý dữ liệu rất nhạy cảm, tôi nghĩ đó là sự đánh đổi công bằng giữa bảo mật và khả năng sử dụng cho hầu hết các trang web. (Khi gần đây tôi thiết lập một ứng dụng xử lý hồ sơ y tế, tôi đã truy cập tất cả https mà không cần chuyển hướng). Thật không may, Internet Explorer không hỗ trợ HSTS ( nguồn), vì vậy nếu đối tượng mục tiêu của bạn chủ yếu sử dụng IE và dữ liệu nhạy cảm, bạn có thể muốn tắt chuyển hướng.

Vì vậy, nếu bạn không nhắm mục tiêu người dùng IE, hãy tiếp tục và sử dụng chuyển hướng, nhưng cũng bật tiêu đề HSTS.

Không có gì sai với điều này, và trên thực tế, đó là cách tốt nhất (đối với các trang web nên được phục vụ qua kết nối an toàn). Trên thực tế, những gì bạn đang làm khá giống với cấu hình tôi đang sử dụng:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

Các 301mã trạng thái cho thấy sự vĩnh cửu chuyển hướng, hướng dẫn khách hàng có khả năng sử dụng các URL an toàn cho các kết nối trong tương lai (ví dụ như cập nhật các bookmark).

Nếu bạn sẽ chỉ phục vụ trang web qua TLS / SSL, tôi khuyên bạn nên sử dụng một chỉ thị tiếp theo để bật HTTP Strict Transport Security (HSTS) trong máy chủ ảo an toàn của bạn :

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

Tiêu đề này hướng dẫn các khách hàng có khả năng (hầu hết trong số họ hiện nay, tôi tin rằng) họ chỉ nên sử dụng HTTPS với tên miền được cung cấp ( secure.example.com, trong trường hợp này) trong những 1234giây tiếp theo . Các ; includeSubdomainsphần là tùy chọn và chỉ ra rằng chỉ áp dụng không chỉ để tên miền hiện tại, nhưng bất kỳ dưới nó (ví dụ alpha.secure.example.com). Lưu ý rằng tiêu đề HSTS chỉ được các trình duyệt chấp nhận khi được phân phối qua kết nối SSL / TLS!

Để kiểm tra cấu hình máy chủ của bạn theo thông lệ tốt nhất hiện tại, một tài nguyên miễn phí tốt là dịch vụ Kiểm tra máy chủ SSL của Qualys ; Tôi đang nhắm đến việc đạt ít nhất điểm A- (bạn không thể nhận được nhiều hơn thế với Apache 2.2 do thiếu hỗ trợ cho mã hóa đường cong elip).

Ồ chuyển hướng HTTP sang HTTPS là một điều rất tốt và tôi không thể thấy bất kỳ nhược điểm nào cho việc đó.

Chỉ cần đảm bảo khách hàng của bạn có CA phù hợp để tránh những cảnh báo không thân thiện với người dùng về chứng chỉ trong trình duyệt.

Ngoài ra, cách bạn đã thiết lập Apache để chuyển hướng đến HTTPS có vẻ ổn.

Có phải là xấu khi chuyển hướng http sang https?

Không hoàn toàn không. Trên thực tế, đó là một điều tốt để làm!

Trên chuyển hướng:

Nó có thể hiệu quả hơn, bằng cách loại bỏ hoàn toàn các bản viết lại . Đây là cấu hình của tôi trong một tình huống tương tự ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

HTTPS không chính xác hoàn toàn. Tất nhiên, thông thường buộc HTTPS là một điều tốt. Nó ngăn chặn tội phạm bình thường làm bất cứ điều gì xấu cho người dùng của bạn.

Nhưng hãy nhớ kiểm tra Cài đặt SSL của bạn như cài đặt SSLCiphers. Vô hiệu hóa những thứ như tiền điện tử RC4, giao thức SSLv2 và SSLv3. Ngoài ra, bạn nên tìm hiểu xem liệu các hệ thống mã hóa hệ thống mã hóa của hệ thống của bạn có hỗ trợ TLS1.2 hay không (đó là thứ bạn muốn có;))

Bật SSL, đó là một điều tốt.

Cá nhân tôi hoàn toàn sử dụng SSL để bảo mật các kết nối trên web, tuy nhiên tôi cảm thấy một điểm mà tất cả các câu trả lời khác ở đây đã bỏ lỡ là không phải mọi thiết bị và phần mềm có khả năng kết nối HTTP đều có thể sử dụng SSL, do đó tôi sẽ xem xét việc cung cấp một số cách để người dùng tránh nó nếu nó không được hỗ trợ cho họ. Cũng có thể mọi người ở một số quốc gia nơi công nghệ mã hóa là bất hợp pháp sau đó sẽ không được phép truy cập trang web của bạn. Tôi sẽ xem xét việc thêm một trang đích không được mã hóa với một liên kết để buộc phiên bản không an toàn của trang web nhưng trừ khi người dùng chọn cụ thể như bạn đã nói và chỉ chuyển tiếp chúng đến phiên bản HTTPS.

Dưới đây là một số vấn đề về bàn chải rộng:

• MITM / SSLSTRIP : Đây là một cảnh báo lớn. Nếu bạn sẽ phục vụ trang web của mình qua HTTPS, thì hãy tắt HTTP trên trang web . Mặt khác, bạn để người dùng của mình mở các cuộc tấn công trung gian khác nhau bao gồm SSLSTRIP, sẽ chặn các yêu cầu và lặng lẽ phục vụ họ qua HTTP, chèn tập lệnh phần mềm độc hại của riêng họ vào luồng. Nếu người dùng không thông báo, thì họ sẽ nghĩ rằng phiên của họ an toàn khi thực sự không có.

  • Tuy nhiên, vấn đề với điều này là nếu trang web của bạn là một trang web công cộng và bạn vô hiệu hóa HTTP một cách bất thường, bạn có thể mất rất nhiều khách truy cập. Nó có thể sẽ thậm chí không xảy ra đối với họ để thử HTTPS nếu trang web sẽ không tải với HTTP.

• Nếu trang web của bạn yêu cầu đăng nhập an toàn, thì toàn bộ phiên người dùng sẽ được bảo mật. Không xác thực qua HTTPS, sau đó chuyển hướng người dùng trở lại HTTP. Nếu bạn làm như vậy, một lần nữa, bạn sẽ khiến người dùng của bạn dễ bị tấn công MITM. Cách tiếp cận tiêu chuẩn để xác thực những ngày này là xác thực một lần, sau đó chuyển mã thông báo xác thực qua lại (trong cookie). Nhưng nếu bạn xác thực qua HTTPS thì chuyển hướng sang HTTP thì một người trung gian có thể chặn cookie đó và sử dụng trang web như thể họ là người dùng được xác thực của bạn, bỏ qua bảo mật của bạn.

• Các vấn đề "hiệu suất" với HTTPS dành cho tất cả các mục đích thực tế giới hạn trong việc bắt tay liên quan đến việc tạo kết nối mới. Hãy làm những gì bạn có thể để giảm thiểu nhu cầu cho nhiều kết nối HTTPS từ một URL và bạn sẽ có dặm về phía trước. Và điều đó hoàn toàn đúng ngay cả khi bạn đang phục vụ nội dung của mình qua HTTP. Nếu bạn đọc trên SPDY, bạn sẽ nhận ra rằng mọi thứ nó làm đều hướng đến việc cố gắng phục vụ tất cả nội dung từ một URL qua một kết nối. Có, sử dụng HTTPS ảnh hưởng đến bộ nhớ đệm. Nhưng có bao nhiêu trang web chỉ là nội dung tĩnh, có thể lưu trong bộ nhớ cache ngày nay? Bạn có thể nhận được nhiều tiền hơn cho việc sử dụng bộ nhớ đệm trên máy chủ web của mình để giảm thiểu các truy vấn cơ sở dữ liệu dư thừa, truy xuất dữ liệu không thay đổi nhiều lần và ngăn chặn các đường dẫn mã đắt tiền thực thi thường xuyên hơn mức cần thiết.

Về mặt kỹ thuật, đây không phải là câu trả lời cho câu hỏi ban đầu của bạn, nhưng nếu bạn sử dụng tiện ích mở rộng Google Chrome HTTPSEverywhere (Tôi chắc chắn có các tiện ích mở rộng tương tự trên các trình duyệt khác), tiện ích mở rộng sẽ tự động chuyển hướng các trang web có HTTP sang cùng một trang với HTTPS. Tôi đã sử dụng nó một lúc và tôi không gặp vấn đề gì (ngoại trừ có thể bị chậm lại, nhưng tôi chưa kiểm tra điều đó). HTTPSEverywhere có thể được thay đổi bởi một số quy tắc nhất định ở phía máy chủ, nhưng vì tôi chưa làm được gì nhiều trong khu vực đó, tôi không chắc chắn về các chi tiết chính xác.

Quay trở lại câu hỏi thực tế của bạn, nếu bạn sử dụng một cái gì đó như HTTPSEverywhere, thậm chí còn ít khuyến khích sử dụng chỉ HTTP, mặc dù tôi tưởng tượng rằng thật khó để thiết lập các quy tắc chính xác khi bạn cần chúng.

kỹ thuật duy nhất rút lại cho HTTPS qua HTTP là việc xử lý các yêu cầu HTTPS tốn kém hơn về mặt tính toán so với HTTP đơn giản

Tuy nhiên, do hầu hết các máy chủ hiện đại đều có CPU có công suất cao, tác động này thường không đáng kể trừ khi bạn ở mức lưu lượng cực cao, tại thời điểm đó bạn có nhiều khả năng sử dụng bộ cân bằng tải hơn

Với sự ra đời của các giao thức như SPDY yêu cầu SSL / TLS hoạt động, điều này thực sự chống lại chi phí tính toán đã nói ở trên bằng cách cải thiện hiệu suất đáng kể liên quan đến nhiều yêu cầu và nhận tài sản cho khách hàng nhanh hơn.

Rất tốt để chuyển hướng sang https, nhưng tôi đọc nó cũng phụ thuộc vào cách bạn tổ chức chuyển hướng.

Tạo một máy chủ ảo chuyên dụng để chuyển hướng các yêu cầu http đến kết nối https của bạn như được đề xuất trong câu trả lời trên security.stackexchange.com nghe có vẻ rất thông minh và sẽ đóng một số mối đe dọa bảo mật bổ sung. Một cấu hình trong Apache sẽ trông giống như thế này:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>