[翻訳] SSLとTLSの配布のベストプラクティス

SSL / TLS驚くほど簡単な技術です。配布しやすいし、ダメな時以外はただスムースに動作します。ただ、問題は暗号化は普通性格に配布しにくいところです。TLSが適切な保安を保証するためには、システム管理者は必ず正しいサーバー設定とアプリの配布に気を引き締めなくてはなりません。

2009年、TLSがどう使われているか、TLSツールとドキュメントをどうやって改善するかを知るために、私たちはSSL Labsで働き始めました。その結果、いくつかの目標を達成しました。TLS使用に対する世界的な統計とオンライン評価ツールを作りましたが、ドキュメントの不足はまだまだ見えています。この文書はこの問題の解決のための第一歩です。

私たちのゴールは安全なサイトとウェブアプリケーションを配布するために、管理者とプログラマーができる限り最少の時間をかけるように、明確で簡潔なマニュアルを提供することです。明確さのために、私たちは完成度を削って、そして特定のトピックも飛ばしておきます。実用的で習いやすくするのにポイントを置きました。もっと詳しい説明が必要な方には、第6章から役に立つ情報を提供します。

yeon.me TLS

1 秘密鍵と証明書

TLSでもすべての保安は暗号のアイデンティティから始まります。匿名の攻撃をする攻撃者を防ぐために、強力な秘密鍵が要ります。同時に重要なことは、特定のホストネームを表しながら、秘密鍵を承認する、有効で強力な証明書を持つことです。この二つのブロックのどれも欠けては、他のなにも安全は保証できません。

1.1 2048ビット秘密鍵の使用

ほとんどのウェブサイトで、2048RSAキーで提供される保安性で十分です。RSA公開キーアルゴリズムは幅広くサポートされており、この種類のキーは安全な基本選択です。2048ビットのキーでは、112ビットの保安性を提供します。さらに安全になるために、RSAのキーは規模の調整に向いていません。128ビットの保安性を得るために、3072ビットのRSAキーが必要ですが、これは著しく遅いです。少ないものの古いクライアントはECDSAをサポートしていませんが、最近のクライアントはうまくサポートしています。設定に面倒がっていなければ、RSAとECDSAを同時に配布するのが最適の選択です。

1.2 秘密鍵の保護

秘密鍵を重要な構成要素として考え、実際に最小限の人数に公開するようにします。次の製作がおすすめされます。

  • 十分に不確定要素を備えている信頼できるパソコンで秘密鍵を作ります。一部のCAはあなたのための秘密鍵を作ってくれますが、そのようなところはおやめになった方がいいです。
  • バックアップシステムにセーブされるとき、最初から鍵を暗号で保護します。秘密鍵の暗号は生成の時は大して役に立ちませんが、ほとんどの攻撃者はプロセスメモリーから鍵を得るからです。サーバーの損傷の場合にも、秘密鍵の保護ができるハードウェアデバイス(いわゆるハードウェア セキュリティ モジュール、あるいはHSM)がありますが、費用がかかるし、保安条件が厳しい組織に向いています。
  • 新しい証明書の発行後、古い証明書が取り消して、新しい鍵を生成します。
  • 証明書を毎年更新します。自動化できるなら、より頻繁にします。ほとんどのサイトは損傷した証明書を確証的に取り消しできないと仮定しなければなりません。1よって、短い有効期限が進められます。
  • 公開鍵を同じく維持したくなければ、新しい証明書を作るたびに、新しい秘密鍵を生成しなければなりません。

1.3 十分なホストネームの保障

皆様の証明書に使われるすべての名前を含めるようにします。正しくない証明書という警告をユーザーが見ないようにするのが目的です。これはユーザーを惑わし、信頼を無くすことに繋がります。

だった一つのドメイン名のみが使われるのを期待するにしても、ユーザーがサイトにどう接続して、どうリンクするか、これをコントロールする方法はありません。ほとんどの場合、証明書はwwwの有無に関係なく、作動しなければなりません。(例えば、example.comとwww.example.comに両方動作すること) サーバーを安全にする一番重要な法則で、DNSネーミングがすべて正しく構成されていて、サーバーを指していることです。

ワイルドカード証明書はその用途がありますが、だとして巨大なグループ、特にチームや部署を超えて鍵を公開することは避けることです。つまり、少数の人のみに秘密鍵が分かるようにしたほうがいいです。そして、一個以上のウェブサイトやサーバーでの証明書のシェアは、脆弱性もシェアすることを分かることです。(秘密鍵が違っていても)

1.4 信用できるCAから証明書を得る

認証事業と保安で徹底で信用できる認証局(Certification Authority, CA)を選びます。CAを得た部時は次の要素を考えてください。

保安状態 すべてのCAは一般的な審査を実行していますが、一部はほかより徹底しています。これだけを見てどちらがいいと決めつけることはできません。しかし、こういう選択は彼らの保安履歴、そして保安妥協に関する態度、今までのミスからの改善性を示しているところで重要です。

ビジネス重点 CAの事業の相当部分を占めている活動は何か進まなかった場合、すべてがダメになれるし、その結果、認証書部門を怠り、他の事業をしようとしる可能性があります。

サポートできるサービス せめて、CAは証明書失効リスト(CRL)と証明書検証プロトコル(OCSP)で丈夫なネットワークと十分な性能の提供は欠かせません。多くのサイトはドメインの保証で十分だと思うけど、Extended Validation(EV)証明書が必要になるか考えてみるべきです。どんな時でも、公開鍵暗号を選ばなくてはなりません。最近のほとんどのウェブサイトはRSAを使っておりますが、ECDSAは性能の利点のおかげで、今後はさらに重要になってくるでしょう。

 

認証管理オプション 多数の証明書のお持ちの方で、複雑な環境で運用しているなら、すべての一挙に管理できるツールを提供しているCAを選んだ方がいいです。

サポート 必要な時に技術サポートができるCAを選択します。

参考

なるべく、配布する一週間前は証明書を取得してください。こういう行動は(1)正しくない時刻のパソコンでの警告の表示の可能性を下げるし、新しい証明書をOCSPに有効だと広めるのに時間がかかるCAでの取り消し確認失敗を防げます。時間が経つとこのような「ウォームアップ」の時間を1ヶ月から三ヶ月に伸ばします。同じく、証明書を変えるために、証明書の満了を待たないでください。時刻が合わない人のために、何か月はおいてください。

1.5 強力な証明書サイニングアルゴリズムの使用

証明書のセキュリティは(1)証明書をサインするのに使われた秘密鍵のパワーと (2)サインに使われたハッシュ関数の強度に左右されます。最近まで、大半の証明書はSHA1ハッシュに依存していましたが、これはもう安全ではないと判明しました。よって、SHA256に転換はすでに進んでおります。2016年1月の時点で、公開CAからSHA1証明書は獲得できません。すでに存在するSHA1証明書は(一部のブラウザーで警告が出ますが)動作を続けて、2016年の終了後サポートは終了しました。

2 構成

正しいTLSサーバー構成であれば、あなたは資格証明が安全な暗号プリミティブのみを使いながら、脆弱性を解決したユーザーにちゃんと現れることが分かります。

2.1 完全なる認証Chainの使用

ほとんどの配布のシナリオで、サーバー証明書一つだけでは足りません。信頼Chainを完成するには、二つ以上の証明書が要ります。サーバーを公開する時、有効な証明書で必要な中間証明書を使わなかった場合、問題が発生します。こういう状況を控えるためには、CAから提供されたすべての証明書を使わなければなりません。

無効な証明書Chainはサーバー証明書を不正確にレンダリングし、ブラウザの警告に繋がります。この場合、ブラウザによって、こういう現象が起きるか、起きないか分かれてしますので、問題を探り出すことは難しいです。すべてのブラウザは証明書をキャッシュに記憶したまま、再使用しようとします。

2.2 安全なプロトコルの使用

SSL/TLSの中にはSSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2、五つのプロトコルがあります。

SSL v2は安全ではないので、使ってはいけません。プロトコルのバージョンはRSAキー攻撃に使われるし、完全に違うサーバーで同じ名前を使えるので(DROWN攻撃)、最悪です。

  • SSL v3はHTTPで脆弱性があり(POODLE攻撃)、他のプロトコルと一緒に使われるときに割れやすいです。衰えているので使ってはいけません。
  • TLS v1.0は同じく衰えていて、使ってはいけません。しかし、未だに必要です。主要脆弱性(BEAST)は最新のブラウザで解決されましたが、他にもいくつの問題は残っています。
  • TLS v1.1とv1.2の脆弱性は知られていませんが、v1.2のみ最新の暗号化アルゴリズムを提供しています。

最新の認証付き暗号(AEAD)を提供する唯一のバージョンはTLS v1.2ですので、こちらが主要プロトコルになる必要があります。もし、まだTLS v1.2が付いてないなら、セキュリティーの脆弱点と言えます。

古いクライアントをサポートするためには、TLS v1.0とTLS v1.1の両方を持っていなければなりません。しかし、近い未来にTLS v1.0を廃棄する計画を立てる時点です。例えば、PCI DSS標準はクレジットカードをもらっているすべてのサイトで、2018年6月までTLS v1.0のサポートをやめないといけないと言っています。

すべての古いセキュリティーの弱点を排除して、未来の安全な通信に保護するため、TLS v1.3を作る作業は続いています。

2.3 安全な暗号スイートの使用

通信の安全にするには、まずは必要なところにすぐ直結して(盗み聞きなく)通信しているかを確かめなければなりません。SSLとTLSで、暗号スイートはセキュリティー通信がどう建てられるのかを決定します。多様性を通じて、保安を得る人たちにより作られています。何か弱いか、危険が見つかったら、他の二変えられます。

強力な認証と鍵交換、前方秘匿性(forward secrecy)、すくなくとも128ビットの暗号化を提供するAEADスイートを主に使用しなければなりません。他の弱いスイートはまだサポートされているけど、古いクライアントがより良いものをサポートしてない場合のみ使用されます。

ここにある古い暗号プリミティブは避けるべきです。

  • Anonymous Diffie-Hellman(ADH)スイート認証がありません。
  • NULL暗号化スイートは暗号化がありません。
  • EXPORTスイートは安全ではありませんが、より強いスイートを望むサーバーに使用されることがあります。(FREAK攻撃)
  • 弱いセキュリティーのスイート(主に 40 ~ 56ビット)は破れやすい暗号化を使用します。
  • RC4は安全ではありません。
  • 3DESは遅いし、弱いです。

初めに、RSAとECDSA両方に対応できるスイートの設定を使用してください。

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

警告

こういった変更事項を実際に適用するとき、TLS構成を事前環境からまずテストすることをお勧めします。上記のリストは一般的な場合で、すべてのシステム(特に古いもの)をサポートするわけではありません。なので、テストが重要です。

上の例は標準TLSスイートの名称です。一部のプラットフォームは非標準名称を使っています。皆様のプラットフォームのドキュメントをご覧ください。例えば、次のスイートの名前はOpenSSLのケースです。

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

2.4 一番良い暗号化スイートの選択

SSL v3と最新プロトコルバージョンで、クライアントは自分がサポートできるスイートのリストを伝送し、サーバーはコネクションにその一つを使うようになります。しかし、すべてのサーバーがこういう段取りを踏むものではありません。一部はただクライアントのリストの中で、一番最初の物のみ使います。サーバーが能動的に暗号化スイートの中で、一番適せなものを選ぶことがよりいいセキュリティーを得るのに決定的です。

2.5 前方秘匿性(Forward Secrecy)の使用

前方秘匿性(時にはPerfectを付けてPFSとも呼ばれる)はサーバーの秘密鍵に依存しない暗号化通信ができるプロトコルの機能です。前方秘匿性を提供してない暗号化スイートで、誰かがサーバーの秘密鍵を復旧して、予め記録しておいたすべての暗号化通信を復号できます。より幅広いクライアントをサポートするためには、DHEスイートもECDHEの代わりに使えます。RSAの高官はできる限り避けた方がいいです。2.3節の基本構成は前方秘匿性を提供することだけを含んでいます。

2.6 強力な鍵共有使用

パブリックサイトではよくDHEとECDHEの中から鍵共有を選択できます。他の鍵共有アルゴリズムはありますが、普通色んな意味で安全ではありません。RSAの鍵共有は未だに使われていますが、前方秘匿性を提供してくれません。

2015年、研究者はDHEに対する新しい攻撃を発見しました。ログジャム攻撃(Logjam attack)とも知られております。研究者は低い強度のDH鍵共有(768ビットなど)は簡単に破られるし、知られている1024ビットDHグループも政府側から破られることを確認しました。安全を保つには、DHEの配布の時、すくなくとも2048ビットの保安もともに構成しなければなりません。昔のクライアント(Java 6など)はこれに対応できません。性能上の理由で、ほとんどのサーバーはより強いし素早いECDHEの方をお勧めします。secp256r1と名付けられたEC暗号(P-256としても知られています)がこの場合のいい選択です。

2.7 よく知られている問題のソリューション

SSLとTLSは近年、ひどい攻撃に遭ったことがありましたが、最新のソフトウェアを使っていて、このガイドさえ守れば、皆さまは心配することはありません。(それ以外に、SSL Labsでのテストがおすすめられます)しかし、必ず安全だとは言えないので、保安ニュースに耳を傾けることが大事です。ヴェンダーの修正パッチが出たら、すぐ適用するか、それとも問題の解決のための方法が必要となります。

3 性能

この文書の中点はセキュリティーですが、性能にも注目が必要です。性能が不十分だったら、どれだけ安全だとしても、余儀なく拒否されるでしょう。正しい構成であれば、TLSはかなり早いです。(HTTP/2のような)最新のプロトコルは平文コミュニケーションより早いはずです。

3.1 やりすぎのセキュリティーを避ける

ハンドシェイクは保安コネクションを建てる過程ですが、秘密鍵の長さによって難易度が左右されます。あまりにも短い鍵は危険で、逆に長すぎる鍵はセキュリティーは高くても、遅すぎます。一般のウェブサイトで、2048ビットより長いRSA鍵と256ビットより強力なECDSA鍵はCPUのリソースを浪費し、ユーザーの経験を悪化する余地があります。同時に、臨時鍵共有をDHEで2048ビット, ECDHEで256ビットより高めるのは、性能上の利点がほとんどありません。128ビット以上の暗号化は特にメリットがありません。

3.2 セッション再開の使用

セッション再開(TLS resumption)とは、費用がかかる暗号化過程をセーブして、再使用の期間を延ばせる性能の最適化技術です。解除しておいたり、機能していないセッション再開システムによって、少なくない性能の低下がある恐れがあります。

3.3 WAN最適化とHTTP/2の使用

最近、TLSのオーバーヘッドはCPUが要る暗号化過程ではなく、ネットワーク関係で現れます。TLSハンドシェイクハTCPのハンドシェイクの後に始まり、より多いパケットとサーバーのリソースを必要とします。こういった遅延を減らすには、新しいコネクションがいい方法です。つまり、コネクションを長く維持することです。(keep-alive) HTTP/2を含む最新プロトコルのサポートを含めることや(CDNを通じる)WAN最適化のような技術がいい結果をもたらします。

3.4 公開コンテンツのキャッシュ

TLSのすべての通信は最新情報が必要だとブラウザは想定しています。特定メモリーはキャッシュすることがありますが、一旦ブラウザを閉じてからはすべての内容を無くします。性能を上げて、一部のリソースに長時間キャッシュを許容するために、(イメージのような)公開資源を公開に設定した方がいいです。

3.5 OCSP Staplingの使用

OCSP Staplingとは、サーバーから直接TLSのハンドシェイクのパートで、取り消し情報を伝えるOCSPプロトコルの拡張です。その結果、クライアントは有効性の検証のため、OCSPサーバーと通信するTLSコネクションの時間を大きく減らせます。OCSP Staplingは重要な最適化技術ですが、すべてのウェブサーバーがOCSP Staplingを具現していないことに気を付きましょう。遅いか、信頼できないOCSP代理者が一緒に構成されている場合、ウェブサーバーが性能の問題を起こせます。ベストの結果のために、探索に妨げになるか、失敗の時条件をテストしてください。

3.6 速い暗号プリミティブの使用

上のおすすめの暗号化スイートの構成は最上のセキュリティーを提供するだけではなく、最上の性能も提供します。できるなら、ハードウェア加速AESができるCPUを使い、より激しい性能の向上のために(普段のサイトでは必要ありませんが)ECDSAの使用も考慮してください。

4 HTTPやアプリのセキュリティー

HTTPプロトコルを含め、関係あるウェブアプリはSSLが登場した以降、目覚しく進歩がありました。その結果、プラットフォームは暗号化を破壊するようになりました。このページでそういう機能を調べて、安全に使う方法に一緒に探しましょう。

4.1 全部暗号化

暗号化が選択項目だというのが一番セキュリティーの問題です。次のような問題をよく見られます。

  • サイトに必要なTLSがない
  • TLSはあっても、強制していない
  • TLSと暗号化していない内容が同時に存在、時々同じページの中にある
  • TLSを無効にするプログラミングエラー

たとえ、問題に気づいていろいろ解決する他の方法もあるとしても、信頼できるようにサイトを保護する唯一の方法は、例外なく暗号化するように強制することです。

4.2 混在コンテンツの無くす

混在コンテンツはTLSを通じないリソース(JavaScript ファイル、イメージ、CSSファイルなど)を含めた内容をTLSを通じて届けることです。そういうページは安全ではありません。活性化した中間者攻撃(MITM)の攻撃者は例えば、保護されていないJavaScriptに乗っかって、すべてのユーザーセッションの操作が可能です。それに、上記のすべての指示通りに従ったとしても、第三者サイトから暗号化されていないリソースをもらっている可能性があります。

4.3 第三者の信頼を理解して、承認する

ウェブサイトは他のサーバーからダウンロードされたJavaScriptコードにより提供された第三者サービスを主に使用しています。例示としていいものは、Google Analyticsで、これはウェブで重要な役割を持っています。こういった第三者コードの包含は、潜在的に皆様のウェブサイトに対する制御権を渡す信頼関係を作ります。

第三者自体は怪しくありませんが、そういうサービスは狙われやすいです。理由はたんじゅんです。大型プロバイダーが攻撃されると、攻撃者はそのサービスに依存するすべてのサイトでの権限も得られるからです。

4.2節の通りに従ったならば、すくなくとも第三者リンクは暗号化され、よって中間者攻撃から安全です。しかし、皆さまはそれ以上に備える必要があります。どんなサービスを使うか、消すかを知って、より安全なサービスに変えるか、使い続けるのに危険を受け入れます。サブリソース統合(SRI)という新しい技術が第三者リソースによる潜在的露出を減らしてくれるでしょう。

4.4 安全なクッキー

ウェブサイトがTLSを要求すれば、安全のためにクッキーも生成されるとき、安全だと記録されます。クッキーの保安失敗は100%暗号化が完了したウェブサイトですら、通常を超えるトリックにより中間者攻撃のターゲットになる情報を露出することになります。ベストの結果のため、暗号の検証統合を追加したり、クッキーの暗号化も考えてみてください。

4.5 安全なHTTP圧縮

2012 CRIME攻撃TLSが安全に具現されてないことを見せます。唯一の解決策はTLSの圧縮をオフにすることです。翌年、二つの追加攻撃が続きました。TIMEとBREACHはHTTPの圧縮を使うHTTPレスポンス本文の秘密に集中しました。TLSの圧縮と違って、HTTPの圧縮は必要であり、消せません。よって、こういう攻撃の解決には、プログラムのコードを修正しなければなりません。

TIMEとBREACH攻撃は難しいことですが、誰か使う動機すらあれば、衝撃はCSRFの攻撃と同じくらいだと見られています。

4.6 HSTSで配布

HTTP Strict Transport Security(HSTS)はTLSの安全網です。 この機能は構成問題、具現エラーがあっても、保安を保つように設計されました。HSTS保護を有効にするためには、ウェブサイトのレスポンスヘッダーに追加が必要です。そして、HSTS支援ブラウザ(今の最新ブラウザ)を使わせます。

HSTSの目標は単純です。有効にしてから、すべての平文リンクを安全なものに変更します。ついでに、証明書の警告を無視できません。(証明書警告は中間者攻撃の発生を表します。リサーチによれば、大体のユーザーはこの警告を無視してクリックするため、許容しない方がいいです。)

HSTSに対するサポートの追加は、ウェブサイトのTLSセキュリティー改善の重要な事項中一つです。新しいサイトはHSTS下でデザインされ、それをサポートするために、古くなったサイトもいつでも活性化できるようにします。ベストのセキュリティーのため、最新ブラウザのHSTS構成に皆様のウェブサイトを内蔵して、初コネクションから暗号化するHSTSプリロードの使用はいかがですか。

次の構成はメインホストネーム、サブドメインを共に1年間HSTSを有効にする例示です。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

4.7 配布内容製作

コンテンツ保安製作(CSP)はウェブサイトがブラウザの動作を制限できる保安作業です。もともとはドメイン間でのスクリプティング(XSS)を表すためでしたが、CSPはまだまだ進歩中で、TLS階層を改善するのに必要な機能を提供します。特に、HSTSが動作しない第三者ウェブサイトの混在コンテンツを制限するのに使えます。

混在した第三者コンテンツを防止するために、CSPを配布するなら、次の構成が必要です。

Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval';
                         connect-src https: wss:

参考

これはCSPを配布するベストプラクティスではありません。混在コンテンツを除いて、破れない例示のために、基本セキュリティーを一部消しました。時間に経つにつれて、CSPに分かるようになったら、製作を変更する必要があります。

4.8 敏感な内容をキャッシュに入れない

すべての敏感なコンテンツは意図した当事者のみに伝わることで、すべての装置に合わせて適切に処理しなければなりません。プロクシーが暗号化したトラフィックを見られない、ユーザーの間で共有できない、アプリの配布プラットフォームに基づいたクラウトの使用が増えていますが、この中の何が公開で、何がそうではないか、明確にすることに慎重になる理由になります。

4.9 他の危険

TLSはセキュリティーの一面で、ユーザーとユーザーの間での機密性や無欠性だけを処理するように設計されていますが、他にも対処すべき危険はあります。ほとんどの場合、これはウェブサイトに他の脆弱性がないことを意味します。

5 確認

数多い構成のプロパティが調整の対象ですが、どんな違いでなんの影響を与えるか、正確に知ることは難しいです。それに、変化は突然出ます。ソフトウェアのアップグレードは自動に変更事項を導入できます。したがって、最初は包括的なSSL/TLS評価ツールを使用し、構成を確認して、安全なのか、その後も確認する方がいいです。公開ウェブサイトに対して、私たちは無料のSSL Labsサーバーテストをお勧めします。

6 エキストラ

次の追加話題は私たちのガイドの範囲外です。SSL/TLSと公開鍵基盤(PKI)についての深い理解が必要で、専門家によって、相変わらず議論の余地があります。

6.1 公開鍵固定 (Public Key Pinning)

公開鍵固定はウェブサイトの運営者に自分のウェブサイトの証明書を発給できるCAを制限する手段を提供します。これはGoogleによって配布され(Chromeにハードコードされている)、攻撃を防げたことで、人々に知らされました。

2014年、Firefoxもハードコードした固定のサポートを導入しました。標準HTTP公開鍵固定拡張がこれから可能です。公開鍵固定はPKIの大きい脆弱点(どんなCAもどんなウェブサイトに証明書を発給できること)を解決しますが、対価があります。配布に相当な努力と専門知識が必要で、サイトの制御権限を無くす危険があります。(間違った構成を固定した場合)詐欺の証明書を通して現実的に攻撃される可能性があるサイトの場合のみ、固定を考慮する必要があります。

6.2 DNSSECとDANE

ドメインネーム

DNSSECはドメイン ネーム システムとの統合を追加する技術です。最近労働てきネットワーク攻撃者は簡単にDNS要請を横取り、レスポンスを偽造できます。DNSSECを使えば、すべてのレスポンスをDNSルーツでまた暗号化して、追跡できます。ネームエンティティのDNS基盤認証(DANE)はDNSSEC上に作る別の標準であり、DNSとTLSの間のコネクションを提供します。DANEはCA基盤PKI環境のセキュリティーを強化するか迂回するのに使用できます。

すべての人がDNSSECがインターネットのいい方向だと同意しているわけではありませんが、これに対するサポートは改善しつつあります。ブラウザはまだDNSSECやDANE(よりHSTSとHPKPを好む)がサポートしていませんが、メールの伝送でのセキュリティーの向上のために使い始めたという意見があります。

 

출처: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

Footnotes

  1. つまり、手を離れた証明書は誤用される可能性があり、取り消しが難しいので、異常状態に備えて短くすることです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です