10

https 接続の方法と理由に関しては、ほとんど何も知りません。明らかに、パスワードや特にクレジット カード情報などの安全なデータを送信する場合、https は重要なツールです。しかし、それについて何を知る必要がありますか? 開発者がプロ​​ジェクトに実装する際に犯す最も一般的な間違いは何ですか? https が単に悪い考えである場合はありますか? ありがとう！

4

7 に答える 7

23

HTTPS（Secure Sockets Layer）証明書はサイトに提供され、通常は認証局（CA）によって署名されます。これは、サイトに関する基本的な詳細を検証し、使用するために認証する信頼できるサードパーティです。ブラウザで。ブラウザがCAを信頼する場合、そのCAによって署名されたすべての証明書を信頼します（これは信頼チェーンと呼ばれます）。

各HTTP（またはHTTPS）要求は、要求と応答の2つの部分で構成されます。HTTPSを介して何かを要求すると、実際にはバックグラウンドでいくつかのことが発生します。

  • クライアント（ブラウザ）は「ハンドシェイク」を実行し、サーバーの公開鍵とIDを要求します。
    • この時点で、ブラウザは有効性を確認できます（サイト名は一致していますか？日付範囲は最新ですか？信頼できるCAによって署名されていますか？）。CAに連絡して、証明書が有効であることを確認することもできます。
  • クライアントは新しいプリマスターシークレットを作成します。これはサーバーの公開鍵を使用して暗号化され（サーバーのみが復号化できます）、サーバーに送信されます。
  • サーバーとクライアントは両方とも、このプレマスターシークレットを使用してマスターシークレットを生成します。マスターシークレットは、実際のデータ交換用の対称セッションキーを作成するために使用されます。
  • 双方がハンドシェイクが完了したことを示すメッセージを送信します
  • 次に、サーバーは要求を通常どおり処理し、セッションキーを使用して応答を暗号化します

接続を開いたままにすると、それぞれに同じ対称鍵が使用されます。

新しい接続が確立され、両側にまだマスターシークレットがある場合は、「省略されたハンドシェイク」で新しいセッションキーを生成できます。通常、ブラウザはマスターシークレットを閉じるまで保存しますが、サーバーはマスターシークレットを数分または数時間保存します（構成によって異なります）。

セッションの長さの詳細については、HTTPS対称鍵の存続期間を参照してください。

証明書とホスト名

証明書には共通名（CN）が割り当てられ、HTTPSの場合はドメイン名になります。CNは正確に一致する必要があります。たとえば、CNが「example.com」の証明書はドメイン「www.example.com」と一致せず、ユーザーはブラウザに警告を表示します。

SNI以前は、1つのIPで複数のドメイン名をホストすることはできませんでした。クライアントが実際のHTTPリクエストを送信する前に証明書がフェッチされ、HTTPリクエストにはサーバーに使用するURLを指示するHost：ヘッダー行が含まれているため、サーバーが特定の証明書に提供する証明書を知る方法はありません。リクエスト。SNIはホスト名をTLSハンドシェイクの一部に追加し、クライアントとサーバーの両方でサポートされている限り（そして、2015年には広くサポートされている限り）、サーバーは正しい証明書を選択できます。

SNIがなくても、複数のホスト名を提供する1つの方法は、サブジェクト代替名（SAN）を含む証明書を使用することです。これは、基本的に証明書が有効な追加ドメインです。たとえば、Googleは単一の証明書を使用してそのサイトの多くを保護しています。

GoogleSSL証明書

もう1つの方法は、ワイルドカード証明書を使用することです。「.example.com」のような証明書を取得することは可能です。その場合、「www.example.com」と「foo.example.com」の両方がその証明書に対して有効になります。ただし、「example.com」は「 .example.com」とは一致せず、「foo.bar.example.com」とも一致しないことに注意してください。証明書に「www.example.com」を使用する場合は、「example.com」のユーザーを「www」にリダイレクトする必要があります。サイト。https://example.comをリクエストした場合、別のIPでホストし、2つの証明書を持っていない限り、証明書エラーが発生します。

もちろん、ワイルドカードとSANの両方を組み合わせて（CAで許可されている限り）、「example.com」とSAN「.example.com」、「example.net」、「たとえば、.example.net」。

フォーム

厳密に言えば、フォームを送信する場合、送信URLがhttps：// URLである限り、フォームページ自体が暗号化されていなくてもかまいません。実際には、ユーザーは（少なくとも理論的には）小さな「ロックアイコン」が表示されない限りページを送信しないようにトレーニングされているため、これを取得するには、フォーム自体もHTTPS経由で提供する必要があります。

トラフィックとサーバーの負荷

HTTPSトラフィックは、同等のHTTPトラフィックよりもはるかに大きく（暗号化と証明書のオーバーヘッドのため）、サーバーに大きな負担をかけます（暗号化と復号化）。負荷の高いサーバーを使用している場合は、HTTPSを使用して提供されるコンテンツを非常に選択することが望ましい場合があります。

ベストプラクティス

  • サイト全体でHTTPSを使用しているだけではない場合は、必要に応じて自動的にHTTPSにリダイレクトする必要があります。ユーザーがログインするときは常にHTTPSを使用する必要があり、セッションCookieを使用している場合は、Cookieにセキュアフラグが設定されている必要があります。これにより、セッションCookieの傍受が防止されます。これは、オープンな（暗号化されていない）Wi-Fiネットワークの人気を考えると特に重要です。

  • ページ上のすべてのリソースは、ページに使用されているのと同じスキームからのものである必要があります。ページにHTTPSが読み込まれているときに、http：//から画像を取得しようとすると、ユーザーにセキュリティ警告が表示されます。完全修飾URLを使用するか、ホスト名を含まない絶対URL（src = "/ images / foo.png"など）を使用するのが簡単な方法です。これらは両方で機能するためです。

    • これには外部リソース（Google Analyticsなど）が含まれます

  • HTTPSからHTTPに変更するときは、POST（フォーム送信）を行わないでください。ほとんどのブラウザは、これをセキュリティ警告としてフラグ付けします。

于 2008-09-15T22:46:27.217 に答える
6

一般的に SSL について深く掘り下げるつもりはありませんが、gregmac はそれについて素晴らしい仕事をしました。

ただし、SSL/TLS の使用に関して (特に PHP ではなく) 犯す最も一般的な (そして重大な) 間違いのいくつかは次のとおりです。

  1. HTTPS を強制する必要がある場合に HTTP を許可する
  2. HTTPS ページから HTTP 経由で一部のリソースを取得する (例: 画像、IFRAME など)

  3. 意図せずに HTTPS ページから HTTP ページに移動する - これには「about:blank」などの「偽の」ページが含まれることに注意してください (私はこれが IFRAME プレースホルダーとして使用されているのを見てきました)、これは不必要かつ不愉快に警告をポップアップ表示します。

  4. 古い安全でないバージョンの SSL をサポートするように構成された Web サーバー (たとえば、SSL v2 は一般的ですが、ひどく壊れています) (わかりました、これは正確にはプログラマーの問題ではありませんが、他の誰もそれを処理しない場合もあります...)

  5. 安全でない暗号スイートをサポートするように構成された Web サーバー (基本的にまったく暗号化を提供しない NULL 暗号のみが使用されているのを見てきました) (同上)

  6. 自己署名証明書 - ユーザーがサイトの身元を確認できないようにします。

  7. HTTPS ページに送信する場合でも、HTTP ページからユーザーの資格情報を要求する。繰り返しますが、これにより、ユーザーはパスワードを与える前にサーバーの身元を検証できなくなります...パスワードが暗号化されて送信されたとしても、ユーザーは自分が偽のサイトにいるかどうか、または暗号化されるかどうかを知る方法がありません.

  8. 非セキュア cookie - セキュリティ関連の cookie (sessionId、認証トークン、アクセス トークンなど)は、「secure」属性を設定して設定する必要があります。これは重要！セキュアに設定されていない場合、SessionId などのセキュリティ Cookie が HTTP 経由で送信される可能性があり (!)、攻撃者はこれが確実に行われるようにすることができ、セッションのハイジャックなどが可能になります。関連)、Cookie にも HttpOnly 属性を設定します (一部の XSS を軽減するのに役立ちます)。

  9. 過度に寛容な証明書 - 複数のサブドメインがあるが、それらのすべてが同じ信頼レベルにあるとは限りません。たとえば、www.yourdomain.com、dowload.yourdomain.com、および publicaccess.yourdomain.com があります。したがって、ワイルドカード証明書を使用することを考えるかもしれません....しかし、別のサーバーであっても、secure.yourdomain.comまたはfinance.yourdomain.comもあります。publicaccess.yourdomain.com は、secure.yourdomain.com になりすますことができます。これで問題ない場合もありますが、通常は、権限をある程度分離する必要があります...

今思い出せるのはここまで、あとで編集し直すかもしれません...

SSL / TLSを使用するのが悪い考えである場合-特定の聴衆（単一のユーザーまたは登録メンバーのいずれか）を対象としていない公開情報があり、それらが特にそれを取得することに特にこだわっていない場合適切なソース (たとえば、株式ティッカー値は認証されたソースから取得する必要があります...) - オーバーヘッドが発生する本当の理由はありません (パフォーマンスだけでなく... dev/test/cert/etc)。

ただし、サイトと別のより機密性の高いサイトとの間でリソース (同じサーバーなど) を共有している場合は、より機密性の高いサイトがここでルールを設定する必要があります。

また、パスワード (およびその他の資格情報)、クレジット カード情報などは、常に SSL/TLS を使用する必要があります。

于 2008-09-16T08:46:33.890 に答える
1

HTTPSページでは、ページ上のすべての要素がHTTPSアドレスからのものであることを確認してください。つまり、プロトコルが継承されるように、要素には相対パス（ "/images/banner.jpg"など）が必要です。または、プロトコルを見つけるためにすべてのページでチェックを行い、それをすべての要素に使用する必要があります。

注意：これには、すべての外部リソース（Google Analytics javascriptファイルなど）が含まれます。

私が考えることができる唯一の欠点は、ブラウザとサーバーの処理時間が（ほとんど無視できる程度に）追加されることです。必要な転送のみを暗号化することをお勧めします。

于 2008-09-15T17:00:10.110 に答える
1

SSL対応サイトで作業する際の最も一般的な間違いは次のとおりです。

  1. このサイトは、誤ってユーザーをhttpsとしてページからhttpにリダイレクトします
  2. 必要なときにサイトが自動的にhttpsに切り替わらない
  3. httpsページの画像やその他のアセットはhttp経由で読み込まれ、ブラウザからセキュリティアラートがトリガーされます。すべてのアセットがhttpsを指定する完全修飾URIを使用していることを確認してください。
  4. セキュリティ証明書は1つのサブドメイン（wwwなど）に対してのみ機能しますが、サイトは実際には複数のサブドメインを使用しています。必要に応じて、必ずワイルドカード証明書を取得してください。
于 2008-09-15T17:02:10.353 に答える
0

ユーザーデータがデータベースに保存されて通信されるときはいつでも、httpsを使用することをお勧めします。ユーザーデータがありふれたものであっても、この要件を考慮してください。これらのありふれた詳細の多くでさえ、他のWebサイトで自分自身を識別するためにそのユーザーによって使用されるためです。あなたの銀行があなたに尋ねるすべてのランダムなセキュリティの質問を考慮してください（あなたはどの通りに住んでいますか？）。これは、アドレスフィールドから非常に簡単に取得できます。この場合、データはパスワードと見なされるものではありませんが、そうである可能性もあります。さらに、他の場所でセキュリティの質問に使用されるユーザーデータを予測することはできません。また、平均的なWebユーザー（祖母を考えてください）のインテリジェンスを使用すると、その情報がそのユーザーのパスワードの一部を別の場所で構成している可能性があることも予想できます。

httpsを使用する場合は1つのポインター

ユーザーが http://www.website-that-needs-https.com/etc/yadda.php と入力すると、自動的に https://www.website-that-needs-https.comにリダイレクトされるようにします。 /etc/yadda.php （個人的なペットピーブ）

ただし、単純なhtml Webページを実行しているだけの場合は、基本的にサーバーからユーザーへの情報の一方向の送信になります。心配する必要はありません。

于 2008-09-15T17:01:53.723 に答える
0

ここにすべての非常に良いヒント...しかし、私は何かを追加したいだけです..
httpログインページを提供し、ユーザー名/パスを投稿した後にのみhttpsにリダイレクトするサイトを見たことがあります..これは、ユーザー名がで送信されることを意味しますhttps接続が確立される前にクリアします。

つまり、sslページに投稿するのではなく、sslからログインするページを作成します。

于 2008-09-15T22:51:24.397 に答える
0

<link>存在しないスタイル シートを使用しようとすると、セキュリティ警告も発生することがわかりました。正しいパスを使用すると、ロック アイコンが表示されました。

于 2008-10-16T20:56:04.170 に答える