どこでSSLを有効にすればよいのでしょうか?

https://stackoverflow.com/questions/107566

01-07-2019
|

質問

私の最近の 2 つのプロジェクトには、製品/サービスを販売する Web サイトが含まれており、ユーザーがクレジットカード情報などを入力する「チェックアウト」プロセスが必要です。もちろん、セキュリティの確保に加え、お客様に安心感を与えるために SSL 証明書を取得しました。しかし、私はその微妙な点、そして最も重要なことに、Web サイトのどの部分で証明書を「使用」すべきかについては、少し分かりません。

たとえば、私はホームページにアクセスした瞬間に https に切り替わる Web サイト (主に銀行サイト) を訪れたことがありますが、最終的にチェックアウトするときにのみ https に切り替わる Web サイトもあります。銀行レベルの何かを扱わない場合、Web サイト全体を https で実行するのはやりすぎでしょうか?チェックアウトページのみを https にすればよいですか?全力を尽くした場合のパフォーマンスはどの程度ですか?

解決

私は個人的には「SSL from go to woe」を選択します。

ユーザーがクレジットカード番号を入力しない場合は、当然 SSL は使用されません。

しかし、Cookie の再生には本質的にセキュリティ漏洩の可能性があります。

ユーザーがサイトにアクセスすると、Cookie が割り当てられます。
ユーザーがサイトを閲覧し、カートにデータを追加します (Cookie を使用)
ユーザーはCookieを使用して支払いページに進みます。

ここで問題が発生します。特に、支払い交渉を自分で行わなければならない場合です。

保護の保証がない状態で、非安全なドメインから安全なドメインに情報を送信し、再度送り返す必要があります。

安全な場合と同じ Cookie を安全でない場合と共有するような愚かなことをすると、ブラウザによっては (当然のことながら) 落とす セキュリティのために Cookie を完全に (Safari で) 使用しないでください。誰かがその Cookie を公の場で盗聴すると、偽造してセキュアモードで使用して、素晴らしい SSL セキュリティを 0 に低下させ、カードの詳細が漏えいする可能性があるからです。セッションに一時的に保存されている場合でも、危険なリークが発生する可能性があります。

あなたのソフトウェアにこれらの弱点がないかどうか確信が持てない場合は、最初から SSL を使用して、最初の Cookie が安全に送信されるようにすることをお勧めします。

他のヒント

サイトが公開目的の場合は、おそらく公開部分を HTTP に置く必要があります。これにより、スパイダーや一般ユーザーにとって作業がより簡単かつ効率的になります。HTTP リクエストは HTTPS よりも開始がはるかに速く、これは特に画像がたくさんあるサイトでは非常に顕著です。

ブラウザーには、HTTP とは異なる HTTPS のキャッシュポリシーが適用される場合もあります。

ただし、ログオン直後、またはその直前に HTTPS に接続しても問題ありません。サイトがパーソナライズされて非匿名になった時点で、それ以降は HTTPS になる可能性があります。

ログオンページ自体やその他のフォームには HTTPS を使用することをお勧めします。HTTPS を使用すると、情報を入力する前に南京錠が使用できるため、安心感が得られます。

私はいつもウェブサイト全体でそれを行ってきました。

私もずっと HTTPS を使います。これはパフォーマンスに大きな影響を与えず (ブラウザは最初の接続後にネゴシエートされた対称キーをキャッシュするため)、スニッフィングから保護します。

スニッフィングは、（ハブを使用したネットワークとは対照的に）完全にスイッチ化された有線ネットワークのせいでかつては廃れつつありましたが、（ハブを使用したネットワークとは対照的に）他の人のトラフィックをキャプチャするには特別な努力が必要になりますが、無線ネットワークのせいで戻りつつあります。ブロードキャストメディアを使用すると、トラフィックが暗号化されない限り、セッションハイジャックが簡単になります。

経験則としては、機密情報が送信される可能性がある場所には必ず SSL を強制することだと思います。例えば：私はウェスコム信用組合の会員です。フロントページには、オンライン銀行口座にログオンできるセクションがあります。したがって、ルートページでは SSL が強制されます。

このように考えてください:機密性の高い個人情報が送信されることはありますか?「はい」の場合は、SSL を有効にします。それ以外の場合は大丈夫です。

私たちの組織では、アプリケーションを 3 つの分類に分類しています。

ビジネスへの影響が低い - PII なし、平文保存、平文送信、アクセス制限なし。
ビジネスへの影響が中程度 - 非トランザクション PII 例:電子メールアドレス。クリアテキストストレージ、データセンターからクライアントへの SSL、データセンター内のクリアテキスト、限定されたストレージアクセス。
ビジネスへの高い影響 - トランザクションデータなどSSN、クレジットカードなどデータセンターの内外での SSL。暗号化および監査されたストレージ。監査されたアプリケーション。

これらの基準を使用して、データのパーティション分割と、サイトのどの部分に SSL が必要かを決定します。SSL の計算はサーバー上で実行されるか、Netscaler などのアクセラレータを介して実行されます。PII のレベルが増加するにつれて、監査と脅威のモデリングも複雑になります。

ご想像のとおり、私たちは LBI アプリケーションを実行することを好みます。

ケントはそれを成功させた。ちょっとコメントしておきたいのですが、Amazon はこれに関してはうまくやっていると思います。サイトのほとんどは http ですが、チェックアウトするときは再度ログインする必要があります (ワンクリックは少し異なります)。その時点ではおそらく別の Cookie が存在します。他のコメントも同じことを言っていると思いますが、具体的な例を挙げたかっただけです。

一般に、機密データや個人データを送信する場合は常に SSL を使用する必要があります。バスケットに商品を追加する場合はおそらく SSL は必要ありません。ユーザー名/パスワードを使用してログインするか、CC の詳細を入力する場合は暗号化する必要があります。

完全版には大きな欠点が 1 つあります https サイトであり、それは速度ではありません（それで大丈夫です）。

安全でないという警告が表示されずに YouTube や「いいね！」ボックスなどを実行するのは非常に困難です。

私たちはもう 2 年間、全力で安全なウェブサイトとショップを運営していますが、これが最大の欠点です。Youtube をなんとか動作させることができましたが、「これを追加」はまだ大きな課題です。そして、彼らがプロトコルに何かを変更した場合、すべての YouTube ムービーが空白になる可能性があります...

私は、ユーザーに機密情報の入力が必要な場合にのみ、サイトを SSL にリダイレクトします。ショッピングカートでは、個人情報やクレジットカードの詳細をページに入力する必要があるとすぐに、SSL ページにリダイレクトします。サイトの残りの部分では、コマースサイト上の情報や商品を閲覧するだけの場合は、おそらく必要ありません。

SSL はかなりの計算量を必要とするため、大量のデータの送信にはできるだけ使用しないでください。したがって、ユーザーが機密情報を送信することになるチェックアウト段階でこれを有効にすることをお勧めします。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow