httpをhttpsにリダイレクトするのは悪いですか？

サーバーにSSL証明書をインストールしました。

次に、ポート80でドメインのすべてのトラフィックにリダイレクトを設定し、ポート443にリダイレクトします。

つまり、すべてのhttp://example.comトラフィックが適切なhttps://example.comバージョンのページにリダイレクトされるようになりました。

リダイレクトは、Apache Virtual Hostsファイルで次のように行われます...

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

私の質問は、SSLを使用することに欠点はありますか？

これは301リダイレクトではないので、検索エンジンのリンクジュース/ランキングが失われhttpsますか？

私は助けに感謝します。SSLを実行するためだけに、サーバー上でSSLを設定したいと常に思っていました。これまでのところうまく機能しているようですが、これをすべてのページで使用するのが良い考えかどうかはわかりません。私のサイトはeコマースではなく、機密データを処理しません。それは主に見た目と学習のためにインストールするスリルのためです。

更新された問題

不思議なことに、BingはHTTPSをどこでも使用しているため、私のサイトからこのスクリーンショットを作成しています...

[R]独自にフラグがある302（リダイレクションMoved Temporarily）。人々があなたのサイトのHTTPSバージョンを使用することを本当に望んでいる場合（ヒント：あなたはそうします）、あなたは[R=301]永続的なリダイレクトに使用する必要があります：

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

A 301は、すべてのgoogle-fuと苦労して獲得したページランクをそのまま保持します。mod_rewrite有効になっていることを確認してください：

a2enmod rewrite

正確な質問に答えるには：

httpをhttpsにリダイレクトするのは悪いですか？

地獄 これはとてもいいです。

SSLのみのサイトのアイデアをサポートしていますが、1つの欠点は、サイトの設計に依存するオーバーヘッドです。たとえば、imgタグで多数の個別の画像を提供している場合、これによりサイトの実行速度が大幅に低下する可能性があります。SSLのみのサーバーを使用している場合は、次のことを確認してください。

1. 内部リンクのサイト全体をチェックし、リンクで独自のドメイン名を指定している場合はすべてHTTPSを使用していることを確認し、独自のリダイレクトを引き起こさないようにします。
2. <meta property="og:url"ドメインのhttpsバージョンを使用してを更新します。
3. <base href=HTTPSを使用するように更新を再度使用する場合。
4. 可能であればSPDYプロトコルをインストールします
5. 可能な場合は、CSS Imageスプライトを使用して、リクエストの数を減らしてください。
6. httpsステータスを示すようにサイトマップを更新して、時間の経過とともにクモがこの変化を知るようにします。
7. Googleウェブマスターツールなどの検索エンジンの設定を変更してHTTPSを優先する
8. 可能であれば、静的メディアをHTTPS CDNサーバーにオフロードします。

上記に対処する場合、多くの問題があるとは思いません。

httpsを設定したら、サイトのあらゆる場所で使用する必要があります。コンテンツが混在する問題のリスクを回避し、必要なツールを用意している場合は、サイト全体を安全にしてください。

httpからhttpsへのリダイレクトに関しては、答えはそれほど単純ではありません。

リダイレクトすると、ユーザーはそれをはるかに簡単に行えるようになり、whateversite.comを入力するだけでhttpsにリダイレクトされます。

しかし。ユーザーが安全でないネットワークにいる場合（またはトロイハントとパイナップルの近くにいる場合）はどうなりますか？その後、ユーザーは古い習慣からhttp://whateversite.comをリクエストします。それはhttpです。それは危険にさらされる可能性があります。リダイレクトはhttps://whateversite.com.some.infrastructure.long.strange.url.hacker.orgを指す場合があります。通常のユーザーには、かなり合法的に見えるでしょう。ただし、トラフィックは傍受できます。

したがって、ここには2つの競合する要件があります。ユーザーフレンドリーで安全であるためです。幸い、HSTSヘッダーと呼ばれる救済策があります。これにより、リダイレクトを有効にできます。ブラウザは安全なサイトに移動しますが、HSTSヘッダーのおかげでそれも覚えています。ユーザーがその安全でないネットワーク上にあるwhateversite.comを入力すると、ブラウザはhttp経由でリダイレクトをジャンプすることなくすぐにhttpsに移動します。非常に機密性の高いデータを扱う場合を除き、これはほとんどのサイトのセキュリティと使いやすさの間の公正なトレードオフだと思います。（最近、医療記録を処理するアプリケーションをセットアップしたとき、リダイレクトなしですべてhttpsにアクセスしました）。残念ながら、Internet ExplorerはHSTSをサポートしていません（ソース）、ターゲットオーディエンスのほとんどがIEを使用しており、データが機密である場合、リダイレクトを無効にすることができます。

したがって、IEユーザーをターゲットにしない場合は、リダイレクトを使用しますが、HSTSヘッダーも有効にします。

これには何の問題もありません。実際、ベストプラクティスです（セキュリティで保護された接続でサービスを提供する必要があるサイトの場合）。実際、あなたがしていることは、私が使用している構成にかなり似ています：

<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 :)

301ステータスコードは示して永久（例えば、ブックマークを更新）今後の接続のための安全なURLを使用することが可能なクライアントを指示し、リダイレクトを。

TLS / SSLを介してのみサイトを提供する場合は、安全な仮想ホストでHTTP Strict Transport Security（HSTS）を有効にするための追加のディレクティブをお勧めします。

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

このヘッダーは、有能なクライアント（最近ではほとんどの人が信じている）に、指定されたドメイン（この場合は）でHTTPSをsecure.example.com次の1234数秒間だけ使用するよう指示します。この; includeSubdomains部分はオプションで、ディレクティブが現在のドメインだけでなく、その下のドメインにも適用されることを示します（例：）alpha.secure.example.com。HSTSヘッダーは、SSL / TLS接続を介して提供される場合にのみブラウザで受け入れられることに注意してください！

現在のベストプラクティスに対してサーバー構成をテストするには、QualysのSSLサーバーテストサービスが適切な無料リソースです。私は少なくともA-を獲得することを目指しています（楕円曲線暗号化のサポートがないため、Apache 2.2ではそれ以上は得られません）。

うわー ！HTTPをHTTPSにリダイレクトすることは非常に良いことであり、そのための欠点は見当たりません。

ブラウザーの証明書に関するユーザーフレンドリーでない警告を避けるために、クライアントに適切なCAがあることを確認してください。

さらに、HTTPSにリダイレクトするようにApacheをセットアップした方法は問題ないようです。

httpをhttpsにリダイレクトするのは悪いですか？

いいえ、まったくありません。実際、それは良いことです！

リダイレクト時：

rewritesを完全に排除することで、より効率的になります。同様の状況での私の設定は次のとおりです...

<VirtualHost *:80>
  ServerName domainname.com

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

HTTPSは完全に万全ではありません。もちろん、通常はHTTPSを強制するのは良いことです。通常の犯罪者がユーザーに悪いことをすることを防ぎます。

ただし、SSLCiphers設定などのSSL設定を必ず確認してください。RC4暗号、SSLv2およびSSLv3プロトコルなどを無効にします。また、システムの暗号システムライブラリがTLS1.2をサポートしているかどうかを確認する必要があります（これが必要なものです;））

SSLを有効にしてください。これは良いことです。

個人的に私はSSLを使用してWeb上の接続を保護することに賛成していますが、ここで他のすべての回答が見落としている点は、HTTP接続が可能なすべてのデバイスとソフトウェアがSSLを使用できるわけではないという点です。したがって、ユーザーがサポートされていない場合、ユーザーがそれを回避する方法を提供することを検討します。また、暗号化技術が違法である国では、サイトへのアクセスが許可されない可能性もあります。安全でないバージョンのサイトを強制するリンクを含む暗号化されていないランディングページを追加することを検討します。ただし、ユーザーが具体的にあなたが言ったように行うことを選択し、HTTPSバージョンに転送する場合を除きます。

広範なブラシストロークの問題の一部を次に示します。

• MITM / SSLSTRIP：これは大きな警告です。HTTPSでサイトを提供する場合は、サイトでHTTPを無効にします。それ以外の場合、ユーザーはSSLSTRIPを含むさまざまな中間者攻撃に対して無防備になります。SSLSTRIPはリクエストを傍受し、HTTPを介して静かにサービスを提供し、独自のマルウェアスクリプトをストリームに挿入します。ユーザーが気付かない場合、実際にはそうではないのにセッションは安全であると考えるでしょう。

  • ただし、これに関する問題は、サイトが公開サイトであり、HTTPを不意に無効にした場合、多くの訪問者が失われる可能性があることです。おそらくないだろう起こるサイトがHTTPでロードされない場合は、HTTPSをしようとする彼らに。

• サイトで安全なログインが必要な場合は、ユーザーセッション全体を保護する必要があります。HTTPSで認証しないで、ユーザーをHTTPにリダイレクトします。繰り返しになりますが、ユーザーはMITM攻撃に対して脆弱なままです。最近の認証の標準的なアプローチは、一度認証してから、認証トークンを（Cookieで）やり取りすることです。ただし、HTTPSで認証してからHTTPにリダイレクトすると、中間者はそのCookieをインターセプトし、認証されたユーザーであるかのようにサイトを使用して、セキュリティをバイパスできます。

• HTTPSの「パフォーマンス」の問題は、すべての実用的な目的で、新しい接続の作成に関係するハンドシェイクに限定されます。URLからの複数のHTTPS接続の必要性を最小限に抑えるためにできることを行うと、何マイルも先に進むでしょう。また、HTTP経由でコンテンツを提供している場合でも、それは率直に言えます。SPDYを読んでいると、SPDYが行うことはすべて、単一の接続を介して単一のURLからすべてのコンテンツを提供しようとしていることに気付くでしょう。はい、HTTPSの使用はキャッシュに影響します。しかし、とにかく、最近は静的でキャッシュ可能なコンテンツがいくつあるのでしょうか？Webサーバーのキャッシュを使用して、変更されていないデータを何度も取得する冗長なデータベースクエリを最小限に抑え、高価なコードパスが必要以上に実行されるのを防ぐことで、費用を節約できます。

これは元々の質問に対する技術的な答えではありませんが、Google Chrome拡張機能HTTPSEverywhere（他のブラウザーにも同様の拡張機能があると確信しています）を使用すると、拡張機能はHTTPを使用するサイトをHTTPSを使用する同じサイトに自動的にリダイレクトします。私はしばらくそれを使っていて、何の問題もありませんでした（おそらくスローダウンを除いて、私はそれをテストしていません）。HTTPSEverywhereは、サーバー側の特定のルールによって変更できますが、その領域ではあまり行っていないので、正確な詳細はわかりません。

実際の質問に戻ると、HTTPSEverywhereのようなものを使用する場合、HTTPのみを使用するインセンティブはさらに少なくなりますが、必要なときに正しいルールを設定するのは難しいと思います。

HTTPS over HTTPに戻る唯一の技術的な欠点は、プレーンなHTTPよりもHTTPSリクエストを処理するのに計算コストがかかることです。

ただし、最新のサーバーのほとんどは高出力CPUを搭載しているため、ロードバランサーを使用する可能性が非常に高いトラフィックのレベルにない限り、この影響は通常無視できます。

SSL / TLSが動作することを必要とするSPDYのようなプロトコルの出現により、これは複数のリクエストに関してパフォーマンスを大幅に改善し、クライアントへのアセットの全体的な高速化により、前述の計算オーバーヘッドを実際に打ち消します。

httpsにリダイレクトすることは非常に良いことですが、私はそれをどのようにリダイレクトを整理するかにも依存します。

security.stackexchange.comの回答で提案されている ように、着信HTTPリクエストをhttps接続にリダイレクトする専用の仮想サーバーを作成することは非常に賢明であり、いくつかの追加のセキュリティ脅威を閉じます。Apacheの構成は次のようになります。

# 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>