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をセットアップすることを望んでおり、それを行うための練習をするために、私は最終的に今夜それを行うことにしました。今のところうまく機能しているようですが、すべてのページでこれを使用するのが良いアイデアかどうかはわかりません。私のサイトはeコマースではなく、機密データを処理しません。それは主にルックスとそれを学習のためにインストールするスリルのためです。
更新された問題
不思議なことに、ビングは私のサイトからこのスクリーンショットを作成しています。
[R]フラグ自体は302リダイレクト（Moved Temporarily）。あなたが本当にあなたのサイトのHTTPSバージョンを使用したいのであれば（ヒント：あなたはそうします）、あなたは[R=301]永続的なリダイレクトの場合：
RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_Host}/$1 [NC,R=301,L]
301は、すべてのgoogle-fuおよびハード獲得したページランク intact を保持します。確認してください mod_rewrite 有効になっています：
a2enmod rewrite
正確な質問に答えるには：
Httpをhttpsにリダイレクトするのは悪いことですか？
地獄。これはとてもいいです。
私はSSLのみのサイトのアイデアをサポートしていますが、サイトの設計によってはオーバーヘッドが1つあるという欠点があります。たとえば、imgタグで多数の個別の画像を提供している場合、サイトの実行速度が大幅に低下する可能性があります。 SSLのみのサーバーを使用している場合は、次のように動作することを確認してください。
- リンクで独自のドメイン名を指定する場合は、サイト全体の内部リンクを確認し、すべてHTTPSを使用していることを確認してください。これにより、独自のリダイレクトが発生しなくなります。
- ドメインのhttpsバージョンを使用するように
<meta property="og:url"を更新してください。 <base href=を使用する場合は、HTTPSを使用するようにもう一度更新してください。- 可能であればインストールSPDYプロトコル
- リクエストの数を減らすために、可能な限りCSS Imageスプライトを使用してください。
- サイトマップを更新してhttpsステータスを示すと、スパイダーが時間の経過とともにこの変更を知ることができます。
- Googleウェブマスターツールなどの検索エンジンの設定を変更してHTTPSを優先する
- 可能な場合は、戦術メディアを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（ source ）をサポートしていないため、ターゲットユーザーが主にIEを使用しており、データが機密である場合は、リダイレクトを無効にすることをお勧めします。
したがって、IEユーザーをターゲットにしていない場合は、先に進んでリダイレクトを使用しますが、HSTSヘッダーも有効にします。
これには何の問題もありません。実際には、ベストプラクティスです（安全な接続でを提供する必要があるサイトの場合）。実際、あなたがやっていることは、私が使用している構成とかなり似ています。
<VirtualHost 10.2.3.40:80>
ServerAdmin [email protected]
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）をsecure仮想ホスト：
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>
このヘッダーは、有能なクライアント（最近のほとんどは、私は信じています）に、HTTPS提供されたドメイン（secure.example.com、この場合）次の1234秒。 ; includeSubdomains部分はoptionalであり、ディレクティブが現在のドメインだけでなく、その下のドメインにも適用されることを示します（例：alpha.secure.example.com）。 HSTSヘッダーはonlyであることに注意してください。
現在のベストプラクティスに対してサーバー構成をテストするには、無料のリソースとして QualysのSSLサーバーテスト サービスをお勧めします。私は少なくともA-を獲得することを目指しています（Apache 2.2では、楕円曲線暗号のサポートがないため、それ以上は得られません）。
Httpをhttpsにリダイレクトするのは悪いことですか？
いいえ、まったくありません。実際、それは良いことです！
リダイレクト時：
書き換えを完全に削除するのほうが効率的です。これは同様の状況での私の設定です...
<VirtualHost *:80>
ServerName domainname.com
<IfModule mod_alias.c>
Redirect permanent / https://domainname.com/
</IfModule>
</VirtualHost>
うわー ！ HTTPをHTTPSにリダイレクトすることは非常に良いことであり、その欠点はありません。
ブラウザの証明書に関するユーザーフレンドリーではない警告を回避するために、クライアントに適切なCAがあることを確認してください。
さらに、ApacheをHTTPSにリダイレクトするように設定する方法は問題ないようです。
HTTPSは完全に完全というわけではありません。もちろん、通常HTTPSを強制するのは良いことです。通常の犯罪者がユーザーに悪影響を及ぼすことを防ぎます。
ただし、SSLCiphers設定のようなSSL設定を必ず確認してください。 RC4暗号、SSLv2およびSSLv3プロトコルなどを無効にします。また、システムの暗号化システムライブラリがTLS1.2をサポートしているかどうかも確認する必要があります（これは、必要なものです;））
SSLを有効にします。これは良いことです。
広範なブラシストロークの問題のいくつかを次に示します。
MITM/SSLSTRIP：これは大きな警告です。 HTTPS経由でサイトを提供する場合は、次にサイトでHTTPを無効にします。それ以外の場合は、SSLSTRIPを含むさまざまな中間者攻撃に対してユーザーを開放したままにします。SSLSTRIPは、リクエストを傍受してHTTP経由で静かに提供し、独自のマルウェアスクリプトをストリームに挿入します。ユーザーが気付かない場合は、実際にはそうではないのに、セッションが安全だと思います。
- ただし、これの問題は、サイトがパブリックサイトであり、HTTPを無許可で無効にした場合、多くの訪問者を失う可能性があることです。サイトがHTTPでロードされない場合、HTTPSを試すことはoccurすることもおそらくないでしょう。
サイトで安全なログインが必要な場合は、ユーザーセッション全体を保護する必要があります。 HTTPS経由で認証しないで、ユーザーをHTTPにリダイレクトします。その場合も、ユーザーはMITM攻撃に対して脆弱なままです。最近の認証の標準的なアプローチは、一度認証すると、認証トークンを（Cookieで）やり取りすることです。ただし、HTTPS経由で認証してからHTTPにリダイレクトすると、中間者がそのCookieを傍受して、認証されたユーザーであるかのようにサイトを使用し、セキュリティをバイパスすることができます。
HTTPSの「パフォーマンス」の問題は、すべての実用的な目的が、新しい接続の作成に関係するハンドシェイクに限定されています。 URLからの複数のHTTPS接続の必要性を最小限に抑えるためにできることを行うと、はるか先に進むことができます。そして、HTTP経由でコンテンツを提供している場合でも、それは率直に言って真実です。 SPDYについて読むと、SPDYが行うすべてのことは、単一の接続を介して単一のURLからすべてのコンテンツを提供しようとすることに向けられていることに気付くでしょう。はい、HTTPSを使用するとキャッシュに影響します。しかし、とにかく最近、どれだけのWebサイトが静的でキャッシュ可能なコンテンツなのでしょうか。 Webサーバーのキャッシングを使用して、変更されていないデータを何度も取得する冗長なデータベースクエリを最小限に抑え、高価なコードパスが必要以上に実行されるのを防ぐために、費用がかさみます。
個人的に私はSSLを使用してWeb上の接続を保護することに全力を尽くしていますが、ここにある他のすべての答えが見落としているのは、HTTP接続が可能なすべてのデバイスとソフトウェアがSSLを使用できるわけではないということです。したがって、サポートされていない場合は、ユーザーが回避できる方法を提供することを検討します。また、暗号化技術が違法である一部の国では、サイトへのアクセスが許可されない可能性もあります。安全でないバージョンのサイトを強制するためのリンクを含む暗号化されていないランディングページを追加することを検討しますが、ユーザーがあなたが言ったようにそうするために特にそうすることを選択し、HTTPSバージョンに転送する場合を除きます。
hTTPS over HTTPの唯一の技術的な欠点は、プレーンなHTTPよりもHTTPSリクエストを処理する方が計算コストが高いことです。
ただし、最新のサーバーのほとんどは高出力CPUを備えているため、トラフィックのレベルが非常に高く、ロードバランサーを使用している可能性が高い場合を除いて、この影響は通常無視できます。
SSL/TLSが機能する必要があるSPDYのようなプロトコルの出現により、これは実際に、複数のリクエストに関してパフォーマンスを大幅に改善し、全体的にクライアントにアセットをより速く提供することにより、前述の計算オーバーヘッドを打ち消します。
Httpsにリダイレクトするのは非常に良いですが、リダイレクトの構成方法にも依存します。
security.stackexchange.com は非常に賢く聞こえ、いくつかの追加のセキュリティ脅威を閉じます。 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>
これは厳密には元の質問への回答ではありませんが、Google Chrome extension HTTPSEverywhere（私は他のブラウザにも同様の拡張機能があると確信しています）を使用している場合、拡張機能はサイトを自動的にリダイレクトしますHTTPSを使用して同じサイトにHTTPを送信します。これをしばらく使用しており、問題は発生していません（スローダウンを除いて、ただしテストを行っていません）。HTTPSEverywhereは、サーバー側の特定のルールによって変更できます、しかし私はその領域で多くのことをしていないので、正確な詳細はわかりません。
実際の質問に戻ると、HTTPSEverywhereなどを使用している場合、HTTPのみを使用するインセンティブはさらに低くなりますが、必要なときに適切なルールを設定するのは難しいと思います。