BEAST attack および Heartbleed bug の後、 POODLE と呼ばれるSSL/TLSの新しい脆弱性について耳にしました。悪用されないようにするにはどうすればよいですか?
この脆弱性を回避する方法の例を教えてください。
SSLは、インターネット上のトランスポートレベルを保護するように設計されています。 「ウェブ」つまりHTTPの場合、これはHTTPSとして知られていますが、他のアプリケーションプロトコルにも使用されます。 SSLv2は最初に広く使用されたトランスポートセキュリティプロトコルでしたが、その後間もなく安全ではないことが判明しました。後継のSSLv3およびTLSv1は現在広くサポートされています。 TLSv1.1とTLSv1.2はより新しく、多くのサポートを獲得しています。 2014年からリリースされたすべてのWebブラウザーではなくても、ほとんどのWebブラウザーがサポートされています。
Googleのエンジニアによる最近の発見は、SSLv3はもはや使用すべきではないことを指摘しています(SSLv2はかなり前に廃止されているように)。サイト/サービスに接続できないクライアントは、おそらく非常に限られています。 CloudFlare 発表済み 訪問者の0.09%未満がまだSSLv3に依存している。
簡単な解決策:SSLv3を無効にします。
はい、 sn-2385-1 を介してSCSV機能を追加しますが、SSLv3とパッチを無効にしないため、問題は完全に軽減されません接続の両側にパッチが適用されている場合にのみ機能します。パッケージマネージャーの通常のセキュリティ更新プログラムで受け取ります。
したがって、まだは、SSLv3を無効にするために自分でアクションを実行する必要があります(構成可能)。クライアント/ブラウザの将来のバージョンは、SSLv3を無効にする可能性が高いでしょう。例えば。 Firefox 34がそうします。
Ubuntuで実装レベルでSSLv3をデフォルトで完全に無効にすると、HTTPS以外のSSLを使用してもそれほど脆弱ではない可能性があるため、メンテナーはそれを行わず、このSCSVパッチのみが適用されると考えられます。
本当に、そのような質問をするのをやめて、いくつかのパラグラフをスキップしてSSLv3を無効にしてください。しかし、あなたが納得していないなら、ここに行きます:
POODLEは、CBC暗号を使用したSSLv3が破損していることを示していますが、SCSVを実装してもそれは変わりません。 SCSVは、通常の場合に必要な中間者攻撃で、必要に応じて一部のTLSプロトコルから下位のTLS/SSLプロトコルにダウングレードしないことのみを確認します。
TLSをまったく提供せず、SSLv3のみを提供するサーバーにアクセスする必要がある場合、ブラウザーは実際には選択肢がなく、SSLv3を使用してサーバーと通信する必要があり、ダウングレード攻撃なしで脆弱です。
TLSv1 +とSSLv3も提供するサーバー(推奨されません)にアクセスする必要があり、接続が攻撃者によってSSLv3にダウングレードされないようにしたい場合は、bothサーバーとクライアントにはこのSCSVパッチが必要です。
問題を完全に軽減するには、SSLv3の無効化で十分であり、ダウングレードされることはありません。また、SSLv3のみのサーバーと通信することはできません。
以下のアプリケーション固有のセクションを参照してください。Firefox、Chrome、Apache、Nginx、およびPostfixについては、今のところ説明します。
サーバーとクライアントの両方がSSLv3を受け入れる場合(ダウングレード攻撃のために両方がTLSv1/TLSv1.1/TLS1.2に対応している場合でも)、脆弱性が存在します。
サーバー管理者として、ユーザーのセキュリティのためにSSLv3nowを無効にする必要があります。
ユーザーは、ブラウザでSSLv3を無効にする必要がありますnow。SSLv3をまだサポートしているWebサイトにアクセスするときに自分を保護します。
いいえ。これはプロトコル(設計)のバグであり、実装のバグではありません。つまり、実際にパッチを適用することはできません(古いSSLv3の設計を変更している場合を除く)。
そして、はい、新しい OpenSSLセキュリティリリース がありますが、以下をお読みください(しかし、私は本当にSSLv3サポートが本当に必要です...理由X、Y、Z!)SSLv3を完全に無効にすることに集中した方がよい理由について。
まあ、はい、おそらく。さらなる考えと作業のために、これを別のブログ投稿に掲載しました。使用できる魔法のiptables
ルールがあるかもしれません!
私のブログ投稿: POODLEのiptablesを使用してネットワークでSSLv3を削除する方法
研究者が示すように、現在の攻撃ベクトルは、被害者のマシンで実行されているJavascriptを使用してサーバーに送信される平文を制御することで機能します。このベクターは、ブラウザーを使用しないHTTPS以外のシナリオには適用されません。
また、通常、SSLクライアントはセッションをSSLv3(ハンドシェイク機能でTLSv1 +を使用)にダウングレードすることを許可しませんが、ブラウザーは非常に下位互換性が必要であり、そうします。プレーンテキストの制御とHTTPヘッダーの特定の構築方法の組み合わせにより、HTTPヘッダーが悪用可能になります。
結論:HTTPSnowのSSLv3を無効にし、次のサービスウィンドウで他のサービスのSSLv3を無効にします。
いいえ、これのために証明書を変更する必要はありません。この脆弱性は、セッションデータからのプレーンテキストリカバリを公開し、シークレット(セッションキーまたは証明書キー)へのアクセスを提供しません。
攻撃者は、 セッションハイジャック を実行するために、セッションCookieなどのプレーンテキストヘッダーのみを盗むことができます。追加の制約は、完全な(アクティブな) MitM攻撃 の必要性です。
ユーザーとして、ブラウザでSSLv3を無効にする以外に、実際にはそうではありません。さて、常に最新のセキュリティ更新プログラムをインストールしてください。
サーバーについては、 MozillaのTLSサーバーガイド に従ってください。 QualysのSSL Labsテスト でテストします。あなたのサイトでA +評価を得るのはそれほど難しくありません。パッケージを更新し、Mozillaのガイドからの推奨事項を実装するだけです。
さて、SSLv3フォールバック保護と呼ばれる、TLSv1対応クライアントのダウングレード攻撃を回避するパッチがあります。 TLSv1 +のセキュリティも改善されます(ダウングレード攻撃は難しく/不可能です)。 Ubuntu Securityアドバイザリ sn-2385-1 の最新のOpenSSLバージョンからのバックポートとして提供されています。
大きな問題:クライアントとサーバーの両方が機能するには、このパッチが必要です。そのため、クライアントとサーバーの両方を更新しているときに、とにかくTLSv1 +にアップグレードする必要があると思います。
ただし、現時点では、ネットワークでSSLv3を廃止してください。セキュリティ標準のアップグレードに努力し、SSLv3を捨ててください。
なんらかの奇妙な理由でSSLv3が本当に必要な場合にのみ、TLSv1 +のセキュリティも向上するので、はい、インストールすることをお勧めします。 Ubuntuは、この機能の更新を sn-2385-1 で提供します。パッケージマネージャーの通常のセキュリティ更新プログラムで受け取ります。
サーバーは、SSLv3をサポートしている場合にのみ脆弱です。ここにいくつかのオプションがあります:
OpenSSL s_clientの場合:
openssl s_client -connect <server>:<port> -ssl3
接続が成功すると、sslv3が有効になります。失敗すると、無効になります。失敗すると、次のように表示されます。
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
nmap
を使用:
nmap --script ssl-enum-ciphers -p 443 myhostname.tld
'SSLv3: No supported ciphers found
'を出力するはずです。ホスト名/ポートを調整します。
cipherscan を使用します。バイナリをクローン/ダウンロードして実行します:
./cipherscan myhostname.tld
'protocols'列の下にSSLv3のあるものをnotリストする必要があります。
about:config
を開き、security.tls.version.min
を見つけて、値を1
に設定します。次に、ブラウザを再起動して、開いているSSL接続をすべて削除します。
バージョン34以降のFirefoxはデフォルトでSSLv3を無効にするため、アクションは不要です( source )。ただし、執筆時点では、33がリリースされ、34は11月25日に設定されています。
/usr/share/applications/google-chrome.desktop
ファイルを編集します。
Sudo nano /usr/share/applications/google-chrome.desktop
Exec=
で始まるすべての行を編集して、--ssl-version-min=tls1
を含めます。
例えば。のような線
Exec=/usr/bin/google-chrome-stable %U
になる
Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U
次に、ブラウザを完全に閉じてください(Chromeアプリがブラウザをバックグラウンドでアクティブに維持している可能性があります!)。
注:この.desktop
ランチャーファイルを上書きして、すべてのgoogle-chromeパッケージの更新を繰り返す必要がある場合があります。デフォルトでSSLv3が無効になっているGoogle ChromeまたはChromiumブラウザーは、執筆時点ではまだ発表されていません。
現在SSLv3を許可しているApache Webサーバーを実行している場合、Apache構成を編集する必要があります。 DebianおよびUbuntuシステムでは、ファイルは/ etc/Apache2/mods-available/ssl.confです。 CentOSおよびFedoraでは、ファイルは/ etc/httpd/conf.d/ssl.confです。他のSSLディレクティブを使用して、Apache構成に次の行を追加する必要があります。
SSLProtocol All -SSLv2 -SSLv3
これにより、SSLv2およびSSLv3を除くすべてのプロトコルが許可されます。
MozillaのTLSサーバーガイド で説明されているように、Webサーバーの暗号スイートの構成を改善することを検討してください。例の追加:
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder on
SSLCompression off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"
次に、新しい構成が正しいかどうかを確認します(入力ミスなどはありません)。
Sudo Apache2ctl configtest
そして、サーバーを再起動します。
Sudo service Apache2 restart
CentOSおよびFedoraの場合:
systemctl restart httpd
詳細: Apacheドキュメント
次にテストします。サイトが公開されている場合は、 QualysのSSL Labsツール を使用してテストします。
Nginxを実行している場合は、他のSSLディレクティブの中の構成に次の行を含めるだけです。
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
MozillaのTLSサーバーガイド で説明されているように、Webサーバーの暗号スイートの構成を改善することを検討してください。例の追加:
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;
そして、サーバーを再起動します。
Sudo service nginx restart
次にテストします。サイトが公開されて利用可能な場合は、 QualysのSSL Labsツール を使用してテストします。
Lighttpdバージョン1.4.28は、SSLv2およびv3を無効にする構成オプションをサポートしています。 1.4.28より前のLighttpdリリースでは、SSLv2のみを無効にできます。 Ubuntu 12.04 LTSおよびそれ以前のバージョンはlighttpd v1.4.28でインストールされるため、これらのディストリビューションでは簡単な修正は利用できません。したがって、この修正はUbuntuバージョン以上でのみ使用してください。 12.04より。
Ubuntuバージョン12.04またはDebian 6の場合、更新されたlighttpdパッケージはopenSUSEリポジトリから入手できます。 http://download.opensuse.org/repositories/server:/http/Debian_6.
このパッケージはDebian 6(squeeze)向けですが、12.04(正確)でも動作します
/etc/lighttpd/lighttpd.conf
ディレクティブを編集して、ssl.engine = "enable"
ディレクティブの後に次の行を追加します
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
次に、Sudo service lighttpd restart
を使用してlighttpdサービスを再起動し、前のセクションで説明したssl3ハンドシェイクテストを実行して、変更が正常に実装されたことを確認する必要があります。
http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL から取得。
「日和見SSL」(暗号化ポリシーが適用されておらず、プレーンも許容されます)の場合、何も変更する必要はありません。 SSLv2でさえプレーンよりも優れているため、サーバーを保護する必要がある場合は、とにかく「必須SSL」モードを使用する必要があります。
既に設定されている「必須SSL」モードの場合、インバウンド接続の smtpd_tls_mandatory_protocols 設定とアウトバウンド接続の smtp_tls_mandatory_protocols を追加/変更するだけです。
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
オプションとして、日和見暗号化に対してSSLv3も無効にする場合(上記で説明したように不要な場合でも)、次のように無効にします。
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3
postfixを再起動します:
Sudo service postfix restart
(匿名ユーザーによる未検証の編集、Sendmailに不満です。検証してください。)
これらのオプションは、LOCAL_CONFIG
のsendmail.mc
セクションで構成されます
LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
Dovecot v2.1 +では、以下を/etc/dovecot/local.conf
(または/etc/dovecot/conf.d
の新しいファイル)に追加します:
ssl_protocols = !SSLv2 !SSLv3
dovecotを再起動します:
Sudo service dovecot restart
古いバージョンの場合、 ソースコードをパッチ する必要があります。
Courier-imapは、Ubuntu 12.04などでデフォルトでSSLv3を許可します。これを無効にし、代わりにSTARTTLSを使用してTLSを強制する必要があります。 /etc/courier/imapd-ssl
構成ファイルを編集して、次の変更を反映します
IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"
SSLはHAProxy> = 1.5でサポートされています。
/etc/haproxy.cfg
ファイルを編集し、bind
行を見つけます。 no-sslv3
を追加します。例えば:
bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3
参照: HAProxyドキュメント
影響を受けていないようです( source )。
OpenVPNはTLSv1.0、または(> = 2.3.3)オプションでTLSv1.2を使用するため、POODLEの影響を受けません。
PuppetはHTTPS over SSLを使用しますが、「ブラウザ」クライアントでは使用されず、表示される攻撃ベクトルに対して脆弱ではないPuppetエージェントのみが使用されます。ただし、SSLv3を無効にすることをお勧めします。
stephenrjohnson/puppetmodule Puppetモジュールを使用して、 SSLv3を強制終了しました のPuppetマスターをセットアップすることをお勧めします。
Ubuntu固有ではないかもしれませんが、Node.jsのPoodleの脆弱性を回避するために、httpsまたはtlsサーバーを作成するときにsecureOptions
をrequire('constants').SSL_OP_NO_SSLv3
に設定できます。
追加情報については、 https://Gist.github.com/3rd-Eden/715522f6950044da45d8 を参照してください
クーリエの「修正」は、tls 1.1およびtls 1.2を無効にします。 tls 1.1以降でcourierを実行する方法はないようです。サーバーのPCIスキャンで推奨事項が表示される場合があります。
サポートされている場合、TLS 1.1またはTLS 1.2のみを使用するようにSSL/TLSサーバーを構成します。ブロック暗号を使用しない暗号スイートのみをサポートするようにSSL/TLSサーバーを構成します。