SSL /TLS 2023年のベストプラクティス

2023年に、SSL /でWebサイトを保護します。TLS 証明書はオプションではなくなりました、ウェブ上で顧客の機密情報を直接取り扱っていない企業でも。 Googleのような検索エンジンはSEOランキングシグナルとしてサイトセキュリティを使用し、Chromeのような人気のあるウェブブラウザはHTTPSを使用しないウェブサイトにユーザーに警告します。

ただし、SSL /を使用するようにWebサーバーとアプリケーションを設定する可能性があります。TLS 難解な構成や設計の選択がたくさんあるため、プロトコルは正しく気が遠くなるように感じることがあります。 このガイドでは、SSL /を設定する際に留意すべき主なポイントの概要を説明します。TLS セキュリティとパフォーマンスの両方に焦点を当てながら、あなたのウェブサイトのために。 基本事項だけでカバーすることはまだたくさんあるので、それを一連のステップに分解しました。

信頼できる認証局（CA）を選択する

証明書は、証明書を発行するCAと同じくらい信頼できるだけです。 すべての公的に信頼されたCAは、主要なオペレーティングシステムとブラウザのルート証明書プログラムでの地位を維持するために、厳格なサードパーティ監査の対象となりますが、そのステータスを維持するのに優れているCAもあります。 （のようなCAを探します SSL.com):

• 公的に信頼されている分野でほとんどのビジネスを行っています PKI. これらのビジネスは、不十分なセキュリティ慣行が明らかになった場合に失うべきものが最も多く、進化する業界標準に追いつくことで得られるすべてのものを持っています。
• ユーザーのセキュリティとプライバシーに影響を与える脆弱性の発見に効率的かつ効果的に対応します、業界全体など シリアル番号エントロピー 2019年の初めの問題。 mozilla.dev.security.policy 特定のCAが逆境にどのように反応するかについて、良い考えを与えることができます。
• 便利な製品とサービスを提供します、Extended Validation（EV）証明書、直感的な経由での一括/自動証明書発行など API または ACMEプロトコル、簡単な証明書のライフサイクル管理および監視サービス、および サポート サードパーティソリューションの広範なリストとの統合。
• 優れたカスタマーサービスとテクニカルサポートで定評があります。 会社のWebサイトを常に100％安全に保つことが重要であり、問​​題が発生したときに電話で真のエキスパートを得ることができる必要があります。

認証局認証（CAA）

認証局認証（CAA） ドメイン名の証明書の発行を許可されている特定のCAを指定することにより、Webサイトを保護するための標準です。 CAを選択したら、次のことを検討する必要があります。 CAAレコードの構成 それを承認する。

秘密鍵を生成して保護する

　 SSL /TLS 使用する キーのペア IDを認証し、インターネット経由で送信される情報を暗号化します。 これらのXNUMXつ（ 公開鍵）は広く配布されることを意図しており、その他（ 秘密鍵）可能な限り安全に保管する必要があります。 これらのキーは、生成時に一緒に作成されます 証明書署名リクエスト（CSR)。 秘密鍵について覚えておくべきいくつかのポイントを次に示します。

• 強力な秘密鍵を使用する： 鍵が大きいほど解読が難しくなりますが、より多くの計算オーバーヘッドが必要になります。 現在、少なくとも2048ビットのRSAキーまたは256ビットのECDSAキーが推奨されており、ほとんどのWebサイトは、これらの値を使用してパフォーマンスとユーザーエクスペリエンスを最適化しながら、優れたセキュリティを実現できます。
  
  注： これらXNUMXつのアルゴリズムの概要については、SSL.comの記事を参照してください。 ECDSAとRSAの比較.
• 秘密鍵を保護する：
  • 安全で信頼できる環境（できれば、それらが展開されるサーバー、またはFIPSまたはCommon Criteria準拠のデバイス）で独自の秘密鍵を生成します。 決して CA（または他の誰か）があなたに代わって秘密鍵を生成することを許可します。 SSL.comなどの信頼できる公開CAは、安全なハードウェアトークンまたはHSMで生成され、エクスポートできない場合を除いて、秘密鍵の生成または処理を提供することはありません。
  • 必要に応じてのみ秘密鍵へのアクセスを許可します。 新しいキーを生成し、 取り消す 秘密鍵にアクセスできる従業員が会社を辞めるときの古い鍵のすべての証明書。
  • 証明書はできるだけ頻繁に更新し（少なくとも年にXNUMX回は適切です）、できれば毎回新しく生成された秘密鍵を使用します。 のような自動化ツール ACMEプロトコル 頻繁な証明書の更新をスケジュールするのに役立ちます。
  • 秘密鍵が侵害された（または侵害された可能性がある）場合、 取り消す このキーのすべての証明書を作成し、新しいキーペアを生成して、新しいキーペアの新しい証明書を発行します。

サーバーを構成する

表面で、 SSLのインストール/TLS 証明書 簡単な操作のように見えるかもしれません。 ただし、Webサーバーが高速で安全であり、エンドユーザーがブラウザーのエラーや警告のないスムーズなエクスペリエンスを実現できるようにするために行う必要のある構成上の決定はまだたくさんあります。 SSL /を設定するときに軌道に乗るのに役立ついくつかの構成ポインタを次に示します。TLS サーバー上：

• すべてのホスト名がカバーされていることを確認してください：証明書はサイトのドメイン名をカバーしていますか。 www 接頭辞？ ありますか サブジェクトの別名（SAN） すべてのドメイン名について、証明書は保護することを目的としていますか？
• 完全な証明書チェーンをインストールする：エンドエンティティSSL /TLS 証明書は通常、CAのルートキーではなく中間証明書によって署名されます。 ブラウザに完全な証明書を提供するために、中間証明書がWebサーバーにインストールされていることを確認してください 認定パス エンドユーザーに対する信頼の警告やエラーを回避します。 CAは、必要な中間体を提供することができます。 SSL.comのお客様は 中間証明書のダウンロード 多くのサーバープラットフォームの中間バンドルを取得するページ。
• 現在のSSLを使用/TLS プロトコル（TLS 1.2または1.3）：2018年後半に、すべての主要ブラウザベンダーが非推奨にする計画を発表しました TLS 1.0年前半までに1.1および2020。Google 非推奨の TLS Chrome 1.0 の v1.1 および v72 (30 年 2919 月 84 日リリース)。 Chrome バージョン 14 (2020 年 XNUMX 月 XNUMX 日リリース) 以降では、これらのプロトコルに対するインタースティシャル警告が表示され、サポートが予定されていました。 完全に削除 2021年XNUMX月。以前のSSL /の広範なブラウザサポートTLS SSLv3などのバージョンは長い間使用されていません。 一方 TLS 1.2は、現在最も広く使用されているSSL /のバージョンです。TLS プロトコル、 TLS 1.3（最新バージョン）は すでにサポートされています ほとんどの主要なWebブラウザーの現在のバージョン。
• 安全な暗号スイートの短いリストを使用します。 128ビット以上の暗号化、または可能な場合はより強力な暗号化スイートのみを選択してください。 国立標準技術研究所（NIST）も、 TLS 実装は、DES暗号（またはそのバリアント）を含む暗号スイートからAESを使用する暗号スイートに移行します。 最後に、潜在的に受け入れ可能な暗号スイートの小さなサブセットのみを使用することで、まだ発見されていない脆弱性の攻撃対象領域を最小限に抑えます。 SSL.comの付録 へのガイド TLS 標準準拠 を使用して、最も人気のあるWebサーバープラットフォームの設定例を提供します TLS 1.2.
  
  注： 安全でない、非推奨の暗号（RC4など）を使用すると、次のようなブラウザのセキュリティエラーが発生する可能性があります。 ERR_SSL_VERSION_OR_CIPHER_MISMATCH Google Chrome。
• Forward Secrecy（FS）を使用： またとして知られています 完全転送秘密（PFS）FSは、侵害された秘密鍵が過去のセッション鍵も侵害しないことを保証します。 FSを有効にするには：
  • 構成 TLS 1.2 Elliptic Curve Diffie-Hellman（EDCHE）鍵交換アルゴリズムを使用する （フォールバックとしてDHEを使用）、可能であればRSAキー交換を完全に回避します。
  • 　 TLS 1.3. TLS 1.3 すべての人に前方秘密を提供する TLS 経由のセッション 一時的なDiffie-Hellman（EDHまたはDHE） 鍵交換プロトコル。
• 有効にします TLS セッション再開： キープアライブを使用して永続的なTCP接続を維持するのと同様に、 TLS セッション再開により、Webサーバーは最近ネゴシエートされたSSL /を追跡できます。TLS セッションとネゴシエーションを再開し、セッションキーネゴシエーションの計算オーバーヘッドをバイパスします。
• OCSPステープリングを検討する: OCSPステープリング Webサーバーがキャッシュされた失効情報をクライアントに直接配信できるようにします。つまり、ブラウザーはOCSPサーバーに接続してWebサイトの証明書が失効しているかどうかを確認する必要がありません。 この要求を排除することにより、OCSPステープリングは実際のパフォーマンスを向上させます。 詳細については、私たちの記事を読んでください、 ページ読み込みの最適化：OCSPステープリング.

Webアプリケーション設計のベストプラクティスを使用する

セキュリティを考慮してWebアプリケーションを設計することは、サーバーを正しく構成することと同じくらい重要です。 これらは、ユーザーが公開されないようにするための最も重要なポイントです 真ん中の男 攻撃、およびアプリケーションが優れたセキュリティ慣行に伴うSEOのメリットを享受すること：

• 混合コンテンツを排除： JavaScriptファイル、画像、CSSファイルは を SSL /でアクセスするTLS。 SSL.comの記事で概説されているように、 どこでもHTTPS、サービング 混合コンテンツ は、Webサイトのパフォーマンスを向上させるための許容できる方法ではなくなり、ブラウザのセキュリティ警告やSEOの問題が発生する可能性があります。
• 安全なCookieを使用する： 設定する Secure Cookieのフラグは、安全なチャネル（HTTPSなど）での送信を強制します。 また、クライアント側のJavaScriptがを介してCookieにアクセスしないようにすることもできます。 HttpOnly フラグを設定し、Cookieのクロスサイト使用を SameSite フラグ。
• サードパーティコードの評価： 不注意で脆弱性や悪意のあるコードを導入する可能性など、Webサイトでサードパーティライブラリを使用することの潜在的なリスクを必ず理解してください。 常にサードパーティの信頼性を最大限に検証し、HTTPSを使用してすべてのサードパーティコードにリンクします。 最後に、Webサイト上のサードパーティ要素からの利益がリスクに見合うものであることを確認してください。

診断ツールで作業を確認する

SSLを設定した後/TLS サーバーやWebサイトで、または構成を変更する場合は、すべてが正しくセットアップされ、システムが安全であることを確認することが重要です。 サイトのSSL /をチェックするために多数の診断ツールが利用可能ですTLS。 たとえば、SSLショッパーの SSLチェッカー 証明書が正しくインストールされているかどうか、いつ期限切れになるかを通知し、証明書の 信頼の連鎖.

混合コンテンツのようなセキュリティ問題をチェックしてサイトをクロールする他のオンラインツールとアプリケーションが利用可能です。 組み込みの開発者ツールを使用して、Webブラウザーで混合コンテンツを確認することもできます。

どのツールを選択する場合でも、SSL /をチェックするスケジュールを設定することも重要です。TLS インストールと構成。 あなたのCAもこれであなたを助けることができるかもしれません。 たとえば、SSL.comは、お客様の便宜のために、証明書の有効期限が迫っていることを自動的に通知します。

HTTP Strict Transport Security (HSTS) の実装

HTTP Strict Transport Security (HSTS) は、プロトコル ダウングレード攻撃や Cookie ハイジャックから Web サイトを保護するのに役立つセキュリティ ポリシー メカニズムです。 これにより、Web サーバーは、Web ブラウザ (またはその他の準拠するユーザー エージェント) が安全な HTTPS 接続のみを使用して対話し、安全でない HTTP プロトコルを介して通信しないことを宣言できます。 このポリシーは、「Strict-Transport-Security」という名前の HTTP 応答ヘッダー フィールドを介してサーバーからユーザー エージェントに伝達されます。

実装する HTTP Strict Transport Security（HSTS）を使用するには、Web サーバーの構成に特別な応答ヘッダーを追加する必要があります。

ステップバイステップガイドは次のとおりです。

1. サイトが HTTPS をサポートしていることを確認してください: HSTS を有効にする前に、サイトに有効な SSL証明書 HTTPS 経由でコンテンツを提供できるようになります。 サイトがまだ HTTPS 用に構成されていない場合は、次のことを行う必要があります。 SSL証明書を取得する そしてそれを使用するようにサーバーを設定します。

ヘッダーは常に Strict-Transport-Security "max-age=31536000; includeSubDomains" を設定します

_{この行は、すべてのサブドメインを含め、今後 31,536,000 年間 (XNUMX 秒) サイトで常に HTTPS を使用するようにブラウザーに指示します。}

2. 構成をテストする: HSTS ヘッダーを追加した後、サイトをテストして、サイトが正しく動作していることを確認する必要があります。 これを行うには、サイトにアクセスし、ブラウザの開発者ツールを使用して応答ヘッダーを確認します。 設定した値を含む Strict-Transport-Security ヘッダーが表示されるはずです。
3. サイトを HSTS プリロード リストに追加することを検討してください。: HSTS プリロード リストは、HSTS 対応としてブラウザにハードコーディングされているサイトのリストです。 これにより、HSTS ヘッダーを受信する前であっても、サイトへの最初の接続が安全であることが保証されるため、追加レベルの保護が提供されます。 hstspreload.org の HSTS プリロード リストにサイトを送信できます。

Use Case: ニュース Web サイトでは、ユーザーが URL に誤って「https」ではなく「http」と入力したとしても、常に安全に接続できるようにしたいと考えています。 この Web サイトは、サーバー構成に Strict-Transport-Security ヘッダーを追加し、長い max-age を設定し、すべてのサブドメインを含めることによって HSTS を使用します。 これにより、ユーザー エージェントは常に HTTPS を使用して接続するように指示され、接続を HTTP にダウングレードして Cookie を盗もうとする攻撃からユーザーを保護します。 この Web サイトは、追加の保護のために HSTS プリロード リストにも登録されています。

HTTP 公開キーのピン留め (HPKP) を実装する

HTTP 公開キー ピンニング (HPKP) は、Web サーバーが特定の暗号化公開キーをそれ自体に関連付けることを可能にするセキュリティ機能で、 中間者（MITM）攻撃 偽造証明書付き。

使用方法の概要は次のとおりです。

1. ピン留め情報の生成: HPKP 実装の最初のステップは、ピン留め情報を生成することでした。 これには、証明書の公開キー、または中間証明書またはルート証明書の公開キーの暗号化ハッシュの作成が含まれます。
2. Webサーバーを構成する: 次のステップは、Web サーバーを構成して、 公開鍵ピン HTTP 応答のヘッダー。 このヘッダーには、公開キー (「ピン」) のハッシュ、有効期限 (ブラウザーが情報を記憶する期間)、およびオプションでレポート URI (ブラウザーがピン検証失敗のレポートを送信する場所) が含まれています。
3. ピン検証の失敗を処理する: HPKP をサポートするブラウザーが、ピン留めされた公開キーの少なくとも XNUMX つを含まない証明書チェーンを受信した場合、その接続は信頼できないと見なされます。 レポート URI が指定されている場合、ブラウザは失敗のレポートもその URI に送信します。

ただし、悪用のリスクとサービス拒否を引き起こす可能性があるため、HPKP はほとんどのブラウザーで非推奨となり、推奨される方法ではなくなりました。 HPKP の構成が間違っていると、Web サイトにアクセスできなくなる状況が発生する可能性があります。

Use Case: 以前、テクノロジー企業は HPKP を使用して公開鍵をサーバーに固定していました。 これにより、認証局 (CA) が侵害され、そのドメインに対して証明書が誤って発行された場合、固定されたキーの XNUMX つと一致する公開キーを持っていない限り、ブラウザーはその証明書を信頼しないことが保証されました。 ただし、固定されたキーへのアクセスを失うと Web サイトにアクセスできなくなる可能性があるため、細心の注意を払う必要がありました。 また、キャッシュされたピン情報によってユーザーがサイトにアクセスできなくなることを避けるために、ピンが期限切れになる前にピンをローテーションするプロセスを確実に導入する必要がありました。

　 TLS フォールバック SCSV によるプロトコル ダウングレード攻撃の防止

TLS フォールバック SCSV (シグナリング暗号スイートの値) は、プロトコル ダウングレード攻撃を防ぐために導入されたメカニズムです。 これらの攻撃は、攻撃者が接続セットアップ プロセスを妨害し、クライアントとサーバーをだまして、実際にサポートしているプロトコルよりも安全性の低いバージョンのプロトコルを使用させるときに発生します。

実装方法は次のとおりです TLS フォールバック SCSV:

1. サーバーの SSL を更新する/TLS 図書館: 最初のステップは、サーバーの SSL/TLS ライブラリはサポートします TLS フォールバック SCSV。 この機能は、OpenSSL 1.0.1j、1.0.0o、および 0.9.8zc で導入されました。 別の SSL/を使用している場合TLS ライブラリを参照するには、ドキュメントを確認するか、開発者に問い合わせてください。
2. サーバーを構成する: サーバーの SSL/TLS ライブラリはサポートします TLS フォールバック SCSV。それを使用するようにサーバーを構成する必要がある場合があります。 正確な手順はサーバー ソフトウェアによって異なります。 たとえば、Apache では、構成ファイルに次のような行を追加または変更する必要がある場合があります。

SSLプロトコル すべて -SSLv2 -SSLv3

この行は、SSLv2 と SSLv3 を除くすべてのプロトコル バージョンを使用するようにサーバーに指示します。 クライアントとサーバーの両方がサポートしている場合 TLS 1.2 ですが、クライアントは使用しようとしています TLS 1.1 では (おそらく攻撃者の干渉のため)、サーバーはこれをフォールバック試行として認識し、接続を拒否します。

3. サーバーをテストする: サーバーを構成した後、サーバーをテストして、サーバーが正しく実装されていることを確認する必要があります。 TLS フォールバック SCSV。 SSL Labs Server Test など、これに役立つさまざまなオンライン ツールがあります。

Use Case: グローバル企業が使用 TLS SCSV をフォールバックして内部通信を保護します。 これにより、攻撃者がプロトコルのダウングレードを強制しようとした場合、サーバーはこれを認識して接続を拒否し、企業の機密データを保護します。 企業の IT チームはサーバーの SSL/TLS ライブラリと構成を使用して最新のセキュリティ機能を使用していることを確認し、オンライン ツールを使用してサーバーをテストし、正しく実装されていることを確認します。 TLS フォールバック SCSV。

混合コンテンツの問題を回避する

混合コンテンツは、安全な HTTPS 接続経由で読み込まれる Web ページに、安全でない HTTP 接続経由で読み込まれる画像、ビデオ、スタイルシート、スクリプトなどのリソースが含まれている場合に発生するセキュリティ リスクです。 ブラウザーはこの混合コンテンツをブロックしたり、ユーザーに警告を表示したりする可能性があり、サイトのセキュリティに対するユーザーの認識を損なう可能性があります。

混合コンテンツの問題を回避する方法は次のとおりです。

1. すべてのリソースに HTTPS を使用する: コンテンツの混合を回避する最も簡単な方法は、サイト上のすべてのリソースが HTTPS 経由で読み込まれるようにすることです。 これには、画像、スクリプト、スタイルシート、iframe、AJAX リクエスト、およびサイトで使用されるその他のリソースが含まれます。
2. サイトのコードを更新する: サイトのコードにリソースのハードコーディングされた HTTP URL が含まれている場合は、代わりに HTTPS を使用するようにこれらを更新する必要があります。 リソースが HTTPS をサポートしていないサーバーでホストされている場合は、独自のサーバーでリソースをホストするか、HTTPS 経由でロードできる代替リソースを見つける必要がある場合があります。
3. Content-Security-Policy ヘッダーを送信するようにサーバーを構成する: Content-Security-Policy (CSP) HTTP ヘッダーを使用すると、サイトでどのリソースの読み込みを許可するかを制御できます。 HTTPS リソースのみを許可する CSP ヘッダーを設定することで、サイトに混合コンテンツが誤って含まれないようにすることができます。

Use Case: オンライン マガジンでは、画像やスクリプトを含むすべてのコンテンツが HTTPS 経由でロードされることが保証されます。 これにより、攻撃者がこれらのリソースを改ざんしたり、悪意のあるコンテンツを挿入したりする可能性を防ぎます。 雑誌の Web 開発者は定期的にサイトのコードをレビューして、すべてのリソースが HTTPS 経由で読み込まれることを確認し、厳格な Content-Security-Policy ヘッダーを送信するようにサーバーを構成します。 また、オンライン ツールを使用して、サイトをスキャンして混合コンテンツの問題がないか確認し、見つかった問題を修正します。

複数のサイトをホストするためにサーバー名表示 (SNI) を利用する

サーバー名表示（SNI） への拡張です TLS サーバーが同じ IP アドレスとポート番号で複数の証明書を提示できるようにするプロトコル。 これは、それぞれ独自の SSL 証明書を持つ複数の安全な Web サイトを同じサーバー上でホストする必要がある Web ホスティング プロバイダーにとって特に便利です。

SNI の使用方法は次のとおりです。

1. サーバー ソフトウェアが SNI をサポートしていることを確認してください: 最初のステップは、サーバー ソフトウェアが SNI をサポートしていることを確認することです。 Apache、Nginx、IIS などのほとんどの最新の Web サーバーは SNI をサポートしています。
2. サーバーを構成する: 次のステップは、SNI を使用するようにサーバーを構成することです。 これには通常、サーバー上でホストするサイトごとに個別の構成ブロックを追加し、 SSL証明書 サイトごとに使用します。 正確な手順はサーバー ソフトウェアによって異なります。
3. 構成をテストする: サーバーを構成したら、サーバーが SNI を正しく使用していることを確認するためにテストする必要があります。 これを行うには、サーバー上でホストしている各サイトにアクセスし、正しい SSL 証明書が使用されていることを確認します。

Use Case: ホスティング プロバイダーは SNI を使用して、同じ IP アドレスから複数の Web サイトにサービスを提供します。 これにより、IP アドレス空間を効率的に使用し、ネットワーク構成を簡素化できます。 サイトごとに異なる SSL 証明書を使用するようにサーバーを構成し、定期的に構成をテストして、サイトごとに正しい証明書が使用されていることを確認します。 これにより、すべてのサイトが同じ IP アドレスからサービスを受けている場合でも、各サイトに安全で信頼できる接続が確保されます。

セッション再開によるパフォーマンスの最適化

セッションの再開は、 TLS このプロトコルにより、クライアントとサーバーが複数のセッションにわたって同じ暗号化キーを使用できるようになり、毎回新しい安全な接続を確立するオーバーヘッドが削減されます。 これにより、特にクライアントが頻繁に切断と再接続を行うアプリケーションのパフォーマンスが大幅に向上します。

 セッション再開の使用方法は次のとおりです。

1. サーバー ソフトウェアがセッション再開をサポートしていることを確認する: 最初のステップは、サーバー ソフトウェアがセッションの再開をサポートしていることを確認することです。 Apache、Nginx、IIS などのほとんどの最新の Web サーバーは、この機能をサポートしています。
2. サーバーを構成する: 次のステップは、セッション再開を使用するようにサーバーを構成することです。 これには通常、セッション キャッシュを有効にし、キャッシュのタイムアウト値を設定することが含まれます。 正確な手順はサーバー ソフトウェアによって異なります。
3. 構成をテストする: サーバーを構成した後、サーバーをテストして、セッション再開が正しく使用されていることを確認する必要があります。 これを行うには、 TLS サーバーへの接続、切断、再接続。 セッションの再開が正しく機能している場合、XNUMX 番目の接続は最初の接続よりも速く確立されるはずです。

Use Case: モバイル アプリはセッション再開を使用して、高速で安全な接続を維持します。 これは、ドロップアウト後にアプリが安全な接続を迅速に再確立できるため、ネットワーク カバレッジが不安定なエリアでアプリを使用する場合に特に便利です。 アプリの開発者はセッション再開を使用するようにサーバーを構成し、定期的に機能をテストして正しく動作していることを確認します。 これにより、困難なネットワーク条件下でも、アプリはユーザーに高速でシームレスなエクスペリエンスを提供できるようになります。

OCSP ステープリングで証明書の有効性を確保

Online Certificate Status Protocol (OCSP) ステープリングは、SSL/TLS 接続のセキュリティを維持しながら。 これにより、サーバーは認証局 (CA) から独自の証明書の現在のステータスを取得し、そのステータスをクライアントに配信できます。 TLS ハンドシェーク。

OCSP ステープル留めを実装する方法は次のとおりです。

1. サーバー ソフトウェアが OCSP ステープリングをサポートしていることを確認してください: 最初のステップは、サーバー ソフトウェアが OCSP ステープルをサポートしていることを確認することです。 Apache、Nginx、IIS などのほとんどの最新の Web サーバーは、この機能をサポートしています。
2. サーバーを構成する: 次のステップは、OCSP ステープリングを使用するようにサーバーを構成することです。 これには通常、サーバーの SSL/ で機能を有効にすることが含まれます。TLS 構成を変更し、サーバーが OCSP 応答を保存する場所を指定します。 正確な手順はサーバー ソフトウェアによって異なります。
3. 構成をテストする: サーバーを構成した後、サーバーをテストして、OCSP ステープリングが正しく使用されていることを確認する必要があります。 これを行うには、 TLS サーバーに接続し、サーバーに OCSP 応答が含まれていることを確認します。 TLS ハンドシェーク。

Use Case：オンライン小売業者は、OCSP ステープル留めを使用して、SSL 証明書のステータスを迅速に確認します。 これにより、顧客は常に安全な接続が確保され、データが安全であると信頼できるようになります。 小売業者の IT チームは、OCSP ステープル留めを使用するようにサーバーを構成し、定期的に機能をテストして、正しく動作していることを確認します。 これは、顧客の信頼を維持し、機密データを保護するのに役立ちます。

無効にします TLS CRIME 攻撃を軽減するための圧縮

TLS 圧縮は、SSL のパフォーマンスを向上させる機能です。TLS ネットワーク経由で送信する必要があるデータの量を減らすことによって。 ただし、接続が CRIME (Compression Ratio Info-leak Made Easy) 攻撃に対して脆弱になる可能性もあり、攻撃者が暗号化されたトラフィックの内容を推測できるようになる可能性があります。

無効にする方法は次のとおりです TLS 圧縮： 

1. サーバー ソフトウェアが無効化をサポートしていることを確認してください TLS 圧縮: 最初のステップは、サーバー ソフトウェアが無効化をサポートしていることを確認することです。 TLS 圧縮。 Apache、Nginx、IIS などのほとんどの最新の Web サーバーは、この機能をサポートしています。
2. サーバーを構成する: 次のステップは、サーバーを無効にするように設定することです。 TLS 圧縮。 正確な手順はサーバー ソフトウェアによって異なります。 たとえば、Apache では、構成ファイルに次のような行を追加できます。

SSL圧縮オフ

この行は、SSL/に圧縮を使用しないようにサーバーに指示します。TLS 接続。

3. 構成をテストする: サーバーを構成した後、サーバーをテストして、正しく無効になっていることを確認する必要があります。 TLS 圧縮。 これを行うには、 TLS サーバーに接続し、接続で圧縮が使用されていないことを確認します。

Use Case：金融機関が無効化 TLS CRIME 攻撃から保護するためにサーバー上で圧縮を行います。 これは、口座番号や取引の詳細などの機密性の高い財務データの機密性を確保するのに役立ちます。 教育機関の IT チームは、サーバーを無効にするように構成しています。 TLS サーバーを定期的にテストして、このセキュリティ対策が正しく実装されていることを確認します。 これは、機関の顧客を保護し、信頼を維持するのに役立ちます。

実施する TLS セッションチケットを正しく発行する

TLS セッションチケットは TLS 完全なハンドシェイクを実行する必要なく、クライアントとサーバーが以前のセッションを再開できるようにすることで、パフォーマンスを向上させることができるプロトコルです。 ただし、潜在的なセキュリティ問題を回避するには、正しく実装する必要があります。

正しく実装する方法は次のとおりです TLS セッションチケット:

1. サーバー ソフトウェアがサポートしていることを確認する TLS セッションチケット: 最初のステップは、サーバー ソフトウェアがサポートしていることを確認することです。 TLS セッションチケット。 Apache、Nginx、IIS などのほとんどの最新の Web サーバーは、この機能をサポートしています。
2. サーバーを構成する: 次のステップは、使用するようにサーバーを設定することです。 TLS セッションチケット。 これには通常、サーバーの SSL/ で機能を有効にすることが含まれます。TLS 構成。 正確な手順はサーバー ソフトウェアによって異なります。
3. 固有のセッション チケット キーを使用する: 潜在的なセキュリティ問題を防ぐために、各サーバーは一意のセッション チケット キーを使用する必要があります。 ロード バランサーを使用している場合は、あるサーバーが発行したセッション チケットをクライアントが使用して別のサーバーとのセッションを確立できるようにするのではなく、セッション チケットに基づいてクライアントを分散するようにロード バランサーを構成する必要があります。
4. セッションチケットキーを定期的にローテーションする: セキュリティをさらに強化するには、セッション チケット キーを定期的にローテーションする必要があります。 多くの場合、これはサーバー ソフトウェアまたは別のキー管理システムを使用して自動化できます。

Use Case: 複数のサーバーを備えた大手テクノロジー企業では、各サーバーが固有のセッション チケット キーを使用していることを確認しています。 これにより、攻撃者があるサーバーのセッション チケットを使用して、別のサーバーのユーザーになりすますことができなくなります。 会社の IT チームは、使用するようにサーバーを構成します。 TLS セッション チケットを作成し、セッション チケット キーを定期的にローテーションするシステムをセットアップします。 また、セッション チケットに基づいてクライアントを分散するようにロード バランサーを構成し、システムのセキュリティをさらに強化します。

安全な再ネゴシエーションを有効にする

安全な再ネゴシエーションは SSL/TLS クライアントまたはサーバーが新しいリクエストを許可するプロトコル TLS セッションの途中での握手。 これは、暗号化キーの更新や暗号化レベルの変更など、さまざまな理由で役立ちます。 ただし、安全に処理しないと、攻撃者によって悪用されて、暗号化された通信に平文が挿入される可能性があります。

安全な再ネゴシエーションを有効にする方法は次のとおりです。

2. サーバー ソフトウェアが安全な再ネゴシエーションをサポートしていることを確認する: 最初のステップは、サーバー ソフトウェアが安全な再ネゴシエーションをサポートしていることを確認することです。 Apache、Nginx、IIS などのほとんどの最新の Web サーバーは、この機能をサポートしています。
3. サーバーを構成する: 次のステップは、安全な再ネゴシエーションを使用するようにサーバーを構成することです。 これには通常、サーバーの SSL/ で機能を有効にすることが含まれます。TLS 構成。 正確な手順はサーバー ソフトウェアによって異なります。
4. 構成をテストする: サーバーを構成した後、サーバーをテストして、安全な再ネゴシエーションが正しく使用されていることを確認する必要があります。 これを行うには、 TLS サーバーに接続してから、接続の再ネゴシエーションを試行します。

Use Case: ソーシャル メディア プラットフォームにより、安全な再ネゴシエーションが可能になり、ユーザー データが保護されます。 これにより、攻撃者がユーザーとサーバー間の暗号化通信に悪意のあるコンテンツを挿入することができなくなります。 プラットフォームの IT チームは、安全な再ネゴシエーションを使用するようにサーバーを構成し、定期的にサーバーをテストして、このセキュリティ対策が正しく実装されていることを確認します。 これは、プラットフォームのユーザーを保護し、信頼を維持するのに役立ちます。

DoS 攻撃を防ぐためにクライアント開始の再ネゴシエーションを無効にする

クライアントが開始する再ネゴシエーションは、SSL/TLS クライアントが新しいリクエストを許可するプロトコル TLS セッションの途中での握手。 ただし、攻撃者がサーバーにセッションの継続的な再ネゴシエーションを強制できる場合、過剰なリソースが消費され、サービス拒否 (DoS) 攻撃につながる可能性があります。

クライアントが開始した再ネゴシエーションを無効にする方法は次のとおりです。

1. サーバー ソフトウェアがクライアント開始の再ネゴシエーションの無効化をサポートしていることを確認してください: 最初のステップは、サーバー ソフトウェアがクライアント開始の再ネゴシエーションの無効化をサポートしていることを確認することです。 Apache、Nginx、IIS などのほとんどの最新の Web サーバーは、この機能をサポートしています。
2. サーバーを構成する: 次のステップは、クライアントが開始した再ネゴシエーションを無効にするようにサーバーを構成することです。 これには通常、サーバーの SSL/ にディレクティブを追加することが含まれます。TLS 構成。 正確な手順はサーバー ソフトウェアによって異なります。
3. 構成をテストする: サーバーを構成した後、サーバーをテストして、クライアントが開始した再ネゴシエーションが正しく無効になっていることを確認する必要があります。 これを行うには、 TLS サーバーに接続してから、接続の再ネゴシエーションを試行します。 サーバーが再ネゴシエーション要求を正しく拒否した場合、サーバーは正しく構成されています。

Use Case: オンライン ゲーム プラットフォームは、潜在的な DoS 攻撃から保護するために、クライアントが開始する再ネゴシエーションを無効にします。 これにより、潜在的な攻撃に直面した場合でも、ユーザーが引き続きプラットフォームを利用できるようになります。 プラットフォームの IT チームは、クライアントが開始する再ネゴシエーションを無効にするようにサーバーを構成し、定期的にサーバーをテストして、このセキュリティ対策が正しく実装されていることを確認します。 これは、プラットフォームのユーザーを保護し、信頼を維持するのに役立ちます。

新しい脆弱性に注意を払う

Webセキュリティは常に変化するターゲットであり、常に次の攻撃に注意を払い、サーバーにセキュリティパッチを迅速に適用する必要があります。 これは、情報セキュリティに関して今何が起こっているのかを読んで連絡を取り合うことと、ソフトウェアの更新、特に重要な更新を把握することを意味します。 SSL.comのウェブサイト （あなたが今これを読んでいるところ）はSSL /の最新情報を入手するための素晴らしい情報源ですTLS と情報セキュリティ。

しかし、何について…？

このガイドで取り上げられているトピックのいずれかについて詳しく知り、発生した新しい問題やテクノロジーについて知りたい場合は、SSL.comを参照して検索することから始めることができます。 知識ベース、SSL /の分野での新しい開発で毎週更新されますTLS & PKI。 また、いつでもメールでサポートスタッフに連絡することもできます。 Support@SSL.com、電話で 1-877-SSL-Secure、またはこのページの右下にあるチャットリンクをクリックします。

SSL 証明書に関する専門家のアドバイスが得られます。
相談フォームに記入してください。