昨日, FireFox 39.0 がやってきた。
これで FireFox も Logjam に対応済みになった。どんな脆弱性が修正されたかは,右ページで確認できる ⇒ Fixed in Firefox 39。
見ての通り,いつもながら数個の脆弱性への対応がなされている。そんなわけで,ブラウザってのは,常に新バージョンに更新しておく必要があるんだよね。まぁ,ブラウザに限った話じゃないけどさ (^^;)。
昨日, FireFox 39.0 がやってきた。
これで FireFox も Logjam に対応済みになった。どんな脆弱性が修正されたかは,右ページで確認できる ⇒ Fixed in Firefox 39。
見ての通り,いつもながら数個の脆弱性への対応がなされている。そんなわけで,ブラウザってのは,常に新バージョンに更新しておく必要があるんだよね。まぁ,ブラウザに限った話じゃないけどさ (^^;)。
昨日, 8 時くらいに帰宅したのだが,今年,初の蛍を見た。まぁ,時刻的問題もあるから,昨日から飛び始めたとは限らないけど。
で,本題。 21 日に “TLSに脆弱性「Logjam」 – 国家レベルなら1024ビットまで盗聴可能” というのを読んで, Guide to Deploying Diffie-Hellman for TLS に行った。特に何も対策せずに,テストしてみたんだけどさ, 2014.Oct.28 (= OpenSSL で作る SANs 対応かつ SHA256 使用の自前認証局) のままで,右図の結果が出た。んで,「まっ,いいか」となった。
その夜,くりくりさんから, Logjam についてのコメントをいただいた。そんで「記事。何とか,がんばってみます」と返信したので,今,がんばってるところ。ヘヘッ。
最初にテストをした時点では,うちのサーバは,下の Cipher Suites をサポートしていた。
実のところ,ほとんどいらないんだよね,こいつら。だって,うちの SSL サーバのユーザは私だけで,私は,最新のブラウザしか使わんのだもん。ホンでもって,使ってるのは ECDHE-RSA-AES128-GCM-SHA256 だけなんス。この際, SSLCipherSuite を下に書き換えることにした(爆)。
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256
当たり前だけど,このコンフィグは,ほかの人の役には立たない。現実的にコンフィグを知りたい人は, Guide to Deploying Diffie-Hellman for TLS を見に行ってくだされ。 Apache 2.4.8 以降と OpenSSL 1.0.2 以降を使っている場合は, SSLOpenSSLConfCmdor ディレクティブで,直接 DH params ファイルを指定できる。そうでない場合には, SSLCipherSuite と SSLProtocol を代わりに使ってやって, Logjam attack を回避することになる。
実のとこ, ApacheLounge の HTTPD はいまだに OpenSSL 1.0.1 なんだよね。というわけで, SSLOpenSSLConfCmd は使えんかった。まぁ, SSLCipherSuite が上記のようにキチガイじみてる(汗)ので,変更後のテスト結果は,右図のような感じになった。
別の Logjam Attack チェッカーでやってみたら,⇒みたいになった。
いつもながら piyolog さんのまとめが出てましたね。「Logjam Attackについてまとめてみた」
追記:
The Logjam Attack page には, Google Chrome (含 Android ブラウザ), Mozilla Firefox, Microsoft Internet Explorer, 及び Apple Safari はすべて Logjam attack に対して修正を配備と書いてあるのだが,現時点でも (午前 9:45),当該ページに FireFox 38.0.1, Google Chrome 43.0.2357.65 あるいは SeaMonkey 2.33.1 でアクセスすると Warning! Your web browser is vulnerable to Logjam and can be tricked into using weak encryption. You should update your browser が出る。 Good News! Your browser is safe against the Logjam attack が戻ってくるのは, Internet Explorer 11.0.19 でアクセスしたときだけである。
注意) この件,他のブラウザおよびバージョンではチェックしていない。
追記2(7/7):
昨日, FireFox 39.0 になりましたね。でもって, Good News! Your browser is safe against the Logjam attack になったでアリンス。
追記3(9/2):
しばらく,チェックを忘れてて,今日, Google Chrome の 45.0.2454.85 が来たのでチェックしてみたら Good News! Your browser is safe against the Logjam attack になっていた。ウーン,いつなったんだろ,ワカンネ!!
追記4(9/5):
今 5 日になったばかりだが,久々に SeaMonkey のアップデートが来て, 2.35 になった。でもって,やっと Good News! Your browser is safe against the Logjam attack が出るようになった。
Apache HTTP Server 2.4.12 が出た。 CVE-2014-3583, CVE-2014-3581, CVE-2014-8109, CVE-2013-5704 のパッチが入ってる模様。 httpd-ssl.conf に下記の行が追加されている。 2.4.11 はリリースされず,欠番になった。
# Define a relatively small cache for OCSP Stapling using
# the same mechanism that is used for the SSL session cache
# above. If stapling is used with more than a few certificates,
# the size may need to be increased. (AH01929 will be logged.)
#SSLStaplingCache “shmcb:c:/Apache24/logs/ssl_stapling(32768)”
# Seconds before valid OCSP responses are expired from the cache
#SSLStaplingStandardCacheTimeout 3600
# Seconds before invalid OCSP responses are expired from the cache
#SSLStaplingErrorCacheTimeout 600
このバージョンは, openssl-1.0.1l とともにビルドされているので, OpenSSL Security Advisory [08 Jan 2015] 関連の問題も対処済みになった。
VC11 用の httpd-2.4.12-win32-VC11.zip を我が家用 ( Windows7 x86 ) にダウンロード。 Apache 2.4.x conf 情報が必要な方は,「Windows7上にWamp系WebServerを建てる-#1。」を見てください。
今回の騒ぎで “Qualys SSL Labs – Projects / SSL Server Test” をやったとき,テスト結果に赤やらオレンジやらが乱舞していた (^_^;)。
||赤いの||
というわけで,赤いのについては何もやらなくてよし。
||オレンジの||
オレンジのについては, 1, 2, 5, 6 について対処する必要がありそうだ。まずは, 5 と 6 から。 1 と 2 は証明書そのものを作り変えないといけないので,後回し。
HIGH:MEDIUM:!aNULL:!MD5
EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256
EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP
!PSK !SRP !DSS
EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH
EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
この作業後,テストしたら, “Downgrade attack prevention : Yes, TLS_FALLBACK_SCSV supported” と “Forward Secrecy : Yes (with most browsers) ROBUST” に変わった。
次は, 1 と 2。
1 は自前認証局の Common Name が o6asan.com だけだからだ。で,新しいのは, o6asan.com も www.o6asan.com もサポートさせないといけない。しかし,我が家の SSL サーバ用の IP は,一つしか割り当てる気がないよという問題がある。これに対処するために, SNI(Server Name Indication) を使う。 8 月ごろに,くりくりさんが取り組まれていた。まあ,まだすべての OS/browser がサポート完了しているわけではないが……それでも,かなりましになってきたのは確か。ワイルドカード証明書か SAN かということになるが, SANs で行くことにした。だって,うちの SSL サーバに任意のサブドメインを受け入れさせる必要はないでしょ。これについては Apache からも制限できるとはいえ,必要のない扉を大きく開けるのはポリシーに反する。
2 は前の証明書を作ったときに OpenSSL の default を使ったからである。デフォルトだと,今もかわらず SHA1 を使うようになっている。今回は, default_md = sha256
にして,こさえるワ。
28 日,改めて Server Name Indication を読み込んでいたのだが, SNI と ワイルドカード証明書か SAN は次元の違う話のようだ。難しいなぁ。
openssl.cnf (← この標準の名称のままで行く) を Apche24conf から c:openssl-1.0.1x-winxxssl (← OpenSSL をフルでインストールすると,ここがデフォルト) にコピーして,以下のようにカスタマイズする。
dir = ./demoCA
—->> dir = X:/demoCA
<<----絶対パスdefault_crl_days = 30
—->> default_crl_days = 365
default_md = default
—->> default_md = sha256
default_bits = 1024
—->> default_bits = 2048
# req_extensions = v3_req
—->> req_extensions = v3_req
subjectAltName = @alt_names
を追加。[ alt_names ]
DNS.1 = example.com
DNS.2 = www.example.com
[ ssl_client ]
basicConstraints = CA:FALSE
nsCertType = client
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
nsComment = "OpenSSL Certificate for SSL Client"
さて,新自前認証局の作成をしよう。(参考 : 本家のお世話-#68)
pushd X:myCA
echo 01 > serial
openssl req -new -keyout privatecakey.pem -out careq.pem
openssl ca -selfsign -in careq.pem -extensions v3_ca -out cacert.pem
copy cacert.pem (Drive_SV):Apache24confssl.crt
copy cacert.pem my_ca.crt
注)(Drive_SV) というのは,自宅サーバ上のサーバウェア用パーティションである。
pushd X:myCA
openssl genrsa -out server.key 2048
openssl req -new -out server.csr -key server.key
openssl req -text -noout -in server.csr
openssl ca -in server.csr -out server.crt -extensions v3_req
copy server.key cp_server.key
openssl rsa <cp_server.key> server.key
copy server.key (Drive_SV):Apache24conf
copy server.crt (Drive_SV):Apache24conf
pushd X:myCA
openssl req -new -keyout client.key -out client.csr
openssl ca -policy policy_anything -extensions ssl_client -in client.csr -out client.crt
openssl pkcs12 -export -in client.crt -inkey client.key -out clientcert.p12
SANs 作成参考リンク : FAQ/subjectAltName (SAN), Multiple Names on One Certificate.
やっと,「 SANs 対応かつ SHA256 使用の自前認証局」が出来た。満足じゃ!!
前記事で, “POODLE” の件を書いた。その後, SSLv3 fallback attack POODLE というのを読んで, WordPress 上の cURL のことが気になりだした。
curl_setopt( $handle, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);
というオプションを curl_setopt で見つけたが, WordPress Core Scripts のどこに入れるのが一番いいのかがわからない。で, WordPress Forums に topic を建ててきた。現在,回答待ちです。
追記(10/26):
cURL が確かに TLSv1.2 を使っていることを確認できたので,さっき, topic を [resolved] にしてきた。 Apache の SSL のログに %{SSL_PROTOCOL} を入れて調べた。 class-http.php に CURL_SSLVERSION_TLSv1 on the file を入れる必要はないようだ。サーバのコンフィグがちゃんと出来てれば,クライアントは安全にアクセスできるんだね。もちろん,クライアントのソフトが TLS に対応してないとかじゃ話にならんけど。
何はともあれ,(*´▽`*)。
もう, “POODLE” 問題(つまり, CVE-2014-3566)には,対処した? OpenSSL のオフィシャルでも, OpenSSL Security Advisory [15 Oct 2014] が出てる。
サーバ管理者としては下記のことをやった。
今のところ, 1.0.1j でビルドされた Apache Lounge 版の Zip が手に入らないので, “SSL v3 goes to the dogs – POODLE kills off protocol” にあった回避策をやった。
httpd-ssl.conf に SSLProtocol All -SSLv3
を書き加えて, httpd.exe をリスタートした。やる前は, SSL Server Test で “This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C” だったが,回避策後は, “This server is not vulnerable to the POODLE attack because it doesn’t support SSL 3” になった。実のところ,うちでは, Apache 2.4 と OpenSSL 1.0.1 を使っているので,うちの mod_ssl の場合, ‘SSLProtocol all’ は ‘SSLProtocol +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2’ ということになる。これは SSLProtocol Directive に記述がある。
ユーザとしては,ブラウザで SSLv3 を停めた。
やり方は,これも How to protect your browser にあった。英文だが,図もあってわかりやすい。日本語のサイトでは, IE, FireFox, Chrome の 3 つともの説明があるところを見つけられなかった。
追記(10/18):
PHP 5.6.1 —>> PHP 5.6.2 ChangeLog.
phpMyAdmin 4.2.9.1 —>> phpMyAdmin 4.2.10 ChangeLog.
表題の件,我々一般人には,一見関係なさそうに見えるが,怪しいアプリをうかつに使わないとか,メールアカウントやパスワードの管理をしっかりするとかいうことでは,同じなんじゃないかと思う。
そういえば,昨日,「ネット競売、消せぬ情報 大手3社、履歴・カード番号保存 利用者「流出が心配」」というのもあったな。えって,思うかもしれないけど,結構そういうとこ多い。だって,登録させる側からいえば,データの不正使用をする気はなくても,ユーザ側の無料版の反復利用を防ぐためだけでも,元情報は必要なわけだから,良心的であっても,罰則がないなら,データを保持するほうが妥当だと思う。どのくらい保持するとかで口を拭ってる様子は感じられるが……。知識の欠如から対応がいい加減なところもあるにはあるけどね。
登録データの削除については,簡単/困難/不能をまとめたこんなサイトがある。 justdelete.me 。
このサイトは, bitly.com (有名どころだが,日本語対応がないみたいなので, twitter そのものの短縮リンクが向上してからは,使うのをやめようとしたのだ) のアカウントを削除しようと四苦八苦しているときに発見した。
まぁ, justdelete.me の一覧を見ると,サイトの性質から考えても, HARD あるいは impossible で当然だなと思うところもたくさんあるけど……。 justdelete.me ,日本語でも似たものがあるのかな。
やっと,本題。
29 日に JVN から Android 版アプリ Kindle における SSL サーバ証明書の検証不備の脆弱性というのが出ていて,セキュリティホール memo さんが「そのうち徳丸さんから解説が出るだろう」と書いておられた解説が出た。「Android版KindleにおけるSSLサーバ証明書の検証不備の脆弱性CVE-2014-3908」。読んでみたけど,難しくて,よくわからん。
証明書を作るときに「コモンネームをちゃんとやってねー」というのはよく聞く。一致してない場合は,アクセスさせてくれないからだと,理解していた。これは,自前証明局の話ね。
でも,奥さんの記事「SSL/TLSライブラリの正しい使い方(もしくは、コモンネームの検証について)」を読むと,多数の人がアクセスするアプリの場合,コモンネームの検証の実装はそれほど単純なものではないみたいだ。うちの自宅サーバレベルは蚊帳の外みたい(爆)。
徳丸さんの解説は難しくて 100% 理解しているとはいいがたいのだが,それでも「コモンネームの検証が漏れてる場合があるって,超ヤバいじゃん」ということくらいは十分わかる。
8月初めには,「App Storeのアプリが盗まれた」って話もあったし,スマホが一気に普及して,それ関係の悪事も花盛りだな。
徳丸さんの記事の件は,実際に悪用されてるかどうかは現時点で不明なようだが,持っている方は,既に対応バージョンが出ているようだし, 「Kindle – Google Play の Android アプリ」でアップデートしておこう。
「App Storeのアプリが盗まれた」の件については,セキュリティホール memo さんによると,いたのくまんぼうさんとこが,有用みたい。「注意喚起:アプリ乗っ取り犯の手口判明。ITCアカウントの入力を求めるアプリには注意!」
昔は, Windows update というとほぼ毎回不具合があって,少し落ち着くまで更新を控えたりしたものだが,今回のドタバタは久しぶりだった気がする。皆さんはどう思われますか? (^_~)
追記(8/28):
MS14-045 関連の不具合更新プログラム, KB2993651 が出てますな。詳しくは,[MS14-045] 更新プログラム 2982791 の問題を解決する更新プログラム 2993651 を公開。
WordPress 3.7 から ca-bundle.crt が含まれるようになったんだが,その後,「Upgrade Network」のときにエラーが出るようになった。ところで,「Warning! Problem updating https://SITENAME.」というのを1つのサイトだけおかしいんだと勘違いしていたのだが,一番初めに調べたサイトでエラーが出てるんだから,あとは調べてないわけだよな(汗)。
はじめのエラーは,「Error message: SSL certificate problem: self signed certificate in certificate chain」というので,これは自前認証局を使ってるせいだったんだが, Oiram の教えてくれた通り, ca-bundle.crt に自前の CA のデータを書き加えてやったら,よくなった。
で,次が「“Error message: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure」。これに2か月以上手を焼いていたが,本日,やっと,解決した \(^o^)/。
振り返ってみると,結局のところ3つのポイントがあったようだ。
[ ssl_client ]
basicConstraints = CA:FALSE
nsCertType = client
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
nsComment = “OpenSSL Certificate for SSL Client”
でもって, ssl_client extension を使って client.crt を作り直した。
>openssl ca -config openssl.cnf -policy policy_anything -extensions ssl_client -in client.csr -out client.crt
curl_setopt( $handle, CURLOPT_SSLCERT, 'clientcert.pem の絶対パス' );
curl_setopt( $handle, CURLOPT_SSLKEY, 'clientkey.pem の絶対パス' );
WordPress の core スクリプトを書き換えるのは嫌なので,何とかほかの方法でやろうと頑張ったのだが,どうしてもうまくいかなくて,結局, class-http.php をいじることにした。
clientcert.pem と clientkey.pem をサーバ上のどこか,外部のものがネット経由でアクセスできない,より安全な場所にコピーする。
参考サイトは, Client URL Library。
自前認証局の作り方は,「本家のお世話-#68。(WordPress SSL ログイン-#1)」をどうぞ。
エラーが消えたよ。満足じゃ。パチパチ!!
OpenSSL Security Advisory [6月5日] になんかいろいろと挙がっていて,どうするかなと思っていたら,さっそく Steffen が対処してくれたので, Apache 2.4.9 の 2014 5 Jun version を落として,アップデート。
新バージョンは, ‘IPv6 Crypto apr-1.5.0 apr-util-1.5.3 apr-iconv-1.2.1 openssl-1.0.1h zlib-1.2.8 pcre-8.34 libxml2-2.9.1 lua-5.1.5 expat-2.1.0’ と openssl-1.0.1h でのビルドとなっている。
アップデートのやり方自体はいつもと同じ。そんでもって,Changelog
いつも, Steffen への感謝の念に堪えない m(_”_)m。
追記(6/9):
こんなんあったんで,貼っときます。
ハートブリード脆弱性から 2 か月で公開された OpenSSL の重大な脆弱性修正パッチ