注意が必要なSSLエンドサーバーの脆弱性

注意が必要なSSLエンドサーバーの脆弱性

SSLエンドサーバーの脆弱性は、ドメインサーバーのSSLプロトコル構成が不適切なために発生します。
以下は、注意すべき脆弱性のリストです。

21項目あります。

1. BEAST
SSL/TLSに対するブラウザの悪用（BEAST）は暗号ブロック連鎖（CBC）を弱めることでSSLやTLSプロトコルに影響を与えるブラウザを悪用します。

影響
BEAST脆弱性の影響はセッションのハイジャックからデータの悪用、暗号化関連の問題にまで及びます。

解決策
この脆弱性を防ぐには、次の方法を取ります。

      1. サーバーでTLS 1.1以上を対応させる
      2. TLS v 1.0とSSL v3、SSL v2を取り除く
      3. 安全でない暗号スイートを取り除く

2. POODLE
The Padding Oracle On Downgraded Legacy Encryption（POODLE）脆弱性はTLSの実装に影響を与え、TLSパケットで使用されるパディングが安全でなくなります。

影響
POODLE脆弱性は中間者（MITM）攻撃やセッションハイジャックの恐れが発生します。

解決策
この脆弱性を防止するには次の方法があります。

      1. SSL v3や低いプロトコルの使用を避ける
      2. 安全でない暗号スイートの使用を避ける

3. POODLE（TLS）
POODLE（TLS）は古い形式の暗号化を悪用するプロトコルダウングレードです。

中間者攻撃者がパブリックなホットスポットでルーターのコントロール権を得て、新しい現代のTLSから強制的にユーザーのブラウザーをSSL 3.0（古いプロトコル）にダウングレードさせて、ユーザーのブラウザーセッションをハイジャックします。

影響
この脆弱性は中間者攻撃や、ユーザーとWebサイト間でのスプーフィングパケットをディスパッチして、プロトコルのダウングレードを強制的に行います。

解決策
この脆弱性を防止するには次の方法があります。

      1. CBC暗号化暗号の無効化
      2. TLS v1.3プロトコルの有効化

4. 再ネゴシエーションの脆弱性
この脆弱性により、SSLおよびTLSプロトコルに再ネゴシエーション要求を行えるようになり、攻撃者がプレーンテキストをアプリケーションのプロトコルストリームに挿入することができるようになります。

影響
この脆弱性により、セッションハイジャックやプレーンテキストコマンドインジェクション、MITM攻撃が引き起こされます。

解決策
この脆弱性を防止するには次の方法があります。

      1. SSL v3以下のプロトコルの使用を避ける
      2. TLS v 1.2以上のバージョンを使用する

5. ROBOT
RSA暗号による鍵交換実装（ROBOT）脆弱性はRSA暗号化鍵交換方式を使用しているWebサーバーに影響を及ぼします。ハッカーは、脆弱性を悪用することにより、さまざまなセッションで使用されているセッションキーを回復し、Webサーバーとの通信を復号化できます。

影響
MITM攻撃、トラフィックの記録、既存データの解読が引き起こされます。

解決策
この脆弱性を防止するには次の方法があります。

      1. RSA暗号の使用を避ける
      2. 古いプロトコルの使用を避ける

6. RC4脆弱性
RC4（The Rivest Cipher 4）脆弱性はTLSに対する脆弱性である、RC4暗号化が使用されている場合に、攻撃者はTLS接続から一定量のプレーンテキストを回復できます。
RC4アルゴリズムによって作成されたキーストリームでの問題は、同じテキストが頻繁に暗号化されるときにTLS暗号テキストで明らかとなり、攻撃されやすくなります。

影響
RC4脆弱性により、攻撃者はネットワークトラフィックの取得や、そのネットワークからのメッセージの解読、関連Cookieへのアクセスを行えるようになります。

解決策
このタイプの脆弱性を防ぐには次の方法があります。
   
        1. RC暗号の使用を避ける
       2. SSL v3以下のプロトコルの使用を避ける

7. CBC脆弱性
CBCモードを使用するセキュアシェル（SSH）メッセージに脆弱性が存在すると、攻撃者が暗号文のブロックからプレーンテキストを復元できます。CBC暗号は安全性の低い暗号です。

影響
この脆弱性はPOODLE脆弱性につながります。

解決策
この脆弱性を防止するには次の方法があります。

      1. CBC暗号の使用を避ける
      2. TLS v1.1以下のプロトコルの使用を避ける

8. AEAD
AEADは暗号文と認証済みデータの整合性を確認するためのメッセージ認証コード利用によるものです。TLSのAEAD暗号スイートは、AES-GCMおよびChaCha20-Poly1305アルゴリズムが使用されています。

アルゴリズムが最も安全で、実際にTLS v1.3,AEADをサポートしている唯一の機能です。

影響
この脆弱性は多くのセキュリティ問題を引き起こします。

解決策
この脆弱性を防止するには次の方法があります。

      1. 安全でない暗号の使用を避ける
      2. AEAD暗号を安全に使用する

9. 前方秘匿性
前方秘匿性（FS）はサーバーの秘密鍵が危険にさらされた場合でも、セッション鍵が妨害されないことを保証する鍵合意プロトコル機能です。前方秘匿性を使用すると、過去に行われた暗号化通信やセッションを取得して復号化することはできません。

影響
この脆弱性によりセッションハイジャックや安全認証の問題が引き起こされます。

解決策
この脆弱性を防止するには次の方法があります。

      1. 安全でない暗号の使用を避ける
      2. 古いプロトコルの使用を避ける
      3. ECDH暗号を安全認証やセッションの維持に使用する

10. FREAK脆弱性
FREAK脆弱性により、攻撃者はクライアントとサーバー間のトランザクションを表示することができ、プライベートな通信に侵入できます。この脆弱性は主にOpenSSLクライアントソフトウェアのバグにより起こります。これによりクライアントとサーバーの両方に危険が及びます。

影響
このタイプの脆弱性は暗号化スイートを無効にすることなく、TLSを使用するブラウザ信頼の多数サイト、組込みシステム、ソフトウェア製品に影響を与えます。

解決策
この脆弱性を防止するには次の方法があります。

      1. 出力暗号の使用を避ける
      2. 低いプロトコルバージョンの使用を避ける

11．DROWN
廃止された脆弱な暗号化を使用したRSAの復号化は、HTTPSおよびSSL、TLSに依存するサービスにも影響を与える深刻な脆弱性です。この脆弱性により、攻撃者は暗号化を解き、パスワード、クレジットカード番号、企業秘密、財務データなどの機密通信情報の読み取りなどを行えます。

影響
この脆弱性により、MITM攻撃や、名前やパスワードなどのユーザー関連の情報の盗撮を攻撃者に行えるようにします。

解決策
この脆弱性を防止するには次の方法があります。

      1. SSL v2の使用を避ける
      2. 安全でない暗号スイートの使用を避ける

12. Logjam脆弱性
Logjam脆弱性はTLS、IPセキュリティ（IPsec）、SSHなどのもっとも一般的な通信暗号化サービスに影響を与えます。これにより、中間者攻撃が安全な接続を512ビットのエクスポートグレードの暗号化にダウングレードすることができます。こうすることで、安全に暗号化されたデータの表示など行えます。

影響
この脆弱性により、中間者攻撃やデータ取得のための暗号化ダウングレードを引き起こします。

解決策
この脆弱性を防止するには次の方法があります。

      1. エクスポート暗号の使用を避ける
      2. DH暗号化暗号の使用を避ける
      3. 古いバージョンのプロトコルの使用を避ける

13. Heartbleed
ユーザーの認証情報やシークレットキーといった重要なデータが、TLSハートビート拡張の不正なメモリ操作を経由したリモート攻撃者に流出します。

影響
この脆弱性により中間者攻撃やセッションハイジャックが引き起こされて、その結果、ユーザーの認証情報が流出します。

解決策
この脆弱性を防止するには次の方法があります。

      1, 安全でない暗号の使用を避ける
      2. 低いバージョンのプロトコルの使用を避ける
      3. 古いOpenSSLバージョンの使用を避ける

14. Fallback SCSV
Fallback SCSVはプロトコルのダウングレードや中間者攻撃を防ぎます。

15. CHACHA20
CHACHAは入力ワードから初期化される16個の32ビットワードで動作するストリーム暗号です。カラムラウンドと対角ラウンドが20ラウンド交互に繰り返されて構成されています。

CHACHAは優れたセキュリティを提供し、ほとんどのSSL攻撃を防止します。

16. 自己署名証明書
自己署名証明書は認証エンティティ自体によって署名された証明書です。独自の秘密鍵で署名された証明書です。

17. SSLブラックリスト
SSLブラックリスト（SSLBL）は特定のサイバー脅威に関連したIPアドレスとSHA-1フィンガープリントに基づいたブラックリストです。ユーザーは、証明書の一般名、発行者の名前、SSLバージョン、関連するマルウェアバイナリ、ブラックリストに登録された理由など、さまざまな情報にアクセスできます。

18. 安全でないキーSSL
SSHを用いたパブリックキー認証はパスワード認証よりも安全で、より強力なスクリーニングを提供します。認証には、秘密鍵と正しいパスフレーズの両方が必要です。

19. 失効
失効エラーはWindowsがセキュリティ証明書失効サーバーに接続できない際に起こります。失効エラーの場合、ユーザーは証明書の失効日を確認する必要があります。失効している場合、Webサイトの管理者に報告する必要があります。

どのようにして起こるか
ユーザーの秘密鍵が侵害された場合、または証明書の発行に異常があった場合、証明書は取り消される可能性があります。

20. チェーンの無効
"証明書が信頼されていない"エラーがホスティングサイトのサーバーで証明書のインストールが正常に完了していない際に起こります。

原因
      1. 自己署名証明書
      2. 中間証明書の問題

解決策
この脆弱性を防止するには次の方法があります。

      1. 自己署名証明書の使用を避ける
      2. フリーSSL証明書の使用を避ける

21. 一般名の不一致
このエラーは一般名（コモンネーム）やSSL/TLS証明書のSANがドメインやアドレスバーにブラウザー内で一致しない際に起こります。これは、たとえば、https://www.example.comではなくhttps://example.comにアクセスしたときに、証明書のSANに両方のサイトをリストしない際に発生します。

原因
      1. 一般名にWebサイトのアドレスがない
      2. WebサイトにSSLがないが他のサイトに共有されている
      3. サーバーやファイアーウォールの設定ミス

影響
Webサイトと証明書がロードされず、接続が安全でなくなります。




    • Related Articles

    • Apache Log4j脆弱性の影響

      2021年12月10日に公開されたApache Log4jに関する脆弱性への本サービスの対応状況を記載します。 〇Apache Log4jとその脆弱性について Javaベースの広く利用されているログ出力ライブラリのことで、Apache Log4jが動作するサーバーで第三者が、 本脆弱性を悪用するデータを送信することで任意のコードが実行される可能性があります。 〇Site24x7での対応状況 ・Apache Log4jの使用状況 ...

    • ステータスページのカスタムドメインでHTTPSドメインのSSL/TLS証明書を受け取る方法

      ステータスページのカスタムドメインアクセスはHTTPSで行われます。そのため、HTTPのカスタムドメインからアクセスすると、SSL証明書エラーが表示されます。 HTTPドメインの場合、それら全ては当社ロードバランサー上のHTTPSサービスに転送されます。 HTTPS向けにSSL/TLS証明書を取得するには次の情報を記載の上、保守サポート窓口までお問い合わせください。 ・対象のカスタムドメイン名 ...

    • SSLv3プロトコルを使用して、Site24x7サーバーと通信を行う

      セキュアソケットレイヤー バージョン3 (SSLv3)は、HTTP、FTP、SIP、SMTP、NNTP、XMPPといったセキュアなアプリケーションプロトコルで使用されるプロトコルです。 SSLv3には脆弱性があり、中間者攻撃により、このプロトコルを使用してサーバーに送信されたリクエストが全て破棄されるといった、セキュリティの脅威があります。 ...

    • SSL接続エラーの検知

      サーバーログを解析することにより、SSL接続についての問題を検知できます。ターゲットサーバーへの接続を確立しているときに、多くの場合、SSL接続エラーが発生します。 ダウン時間が発生したときのエラーの原因についてはサーバーのアクセスログをご確認ください。

    • Windows Server 2008 R2、2012、Windows 7でのTLS 1.2更新方法

      次の手順でTLS 1.2への更新を行ってください。 サービスパック1をWindows 7と2008 R2サーバーにインストールします。 Microsoft更新カタログ kb3140245をインストールし、レジストリを有効にします。 Microsoftのドキュメントを参照し、TLS 1.2を有効にします。 TLS1.2が有効になっているか確認する方法は、こちらを参照してください サーバーを再起動します。 次のレジストリパスの値が、0x00000A00に設定されていることを確認します。 ...