5/4 に Steffen のところで， OpenSSL 1.0.2h でビルドの Apache 2.4.20 が出たので，昨日，更新した。 ChangeLog. Apache2.4 系を初めてインストールするという場合は，「Windows7上にWamp系WebServerを建てる-#1」を，どうぞ。現在，自鯖では VC14 バージョンを使っているが，これには， VC14 が必要である。
カテゴリー
カテゴリー: Vulnerability
カテゴリー
DROWN という脆弱性。
「脆弱性「DROWN」、非推奨のSSLv2に存在することが確認される。HTTPSサーバ全体の3分の1に影響」というのを読んだんで， The DROWN Attack と DROWN Scanner で， o6asan.com のチェックをやってみた。 DROWN て OpenSSL Security Advisory [1st March 2016] の関係のヤツだよね。
カテゴリー
気を付けよう，ランサムウェア。
投稿アップデート情報 追記(12/7) 追記２(12/8)
怖いですねぇ，ランサムウェア。最近，国内で増えてるみたいですね。記事も増えてます。「広告表示したら感染…ソフト最新化を急げ：読売新聞」とか，こんなんとか。大分前にランサムウェアの記事読んだ気がするけど，どこだったかな。昨日はリアルワールドが忙しかったので，今になって探してみたんだけど，これでしたねぇ。 ☞ 2015年6月の呼びかけ
Apache 2.4.12 (httpd-2.4.12-win32-VC14.zip) を 2015.7.9 版にアップデートした。 Alternative chains certificate forgery (CVE-2015-1793) に対処するためである。
2015.7.9 版は ‘IPv6 Crypto apr-1.5.1 apr-util-1.5.4 apr-iconv-1.2.1 openssl-1.0.2d zlib-1.2.8 pcre-8.37 libxml2-2.9.2 lua-5.1.5 expat-2.1.0′ でビルドされている。そんでもって， Changelog。
この版は， Windows® Visual Studio C++ 2015 RC 別名 VC14 がないと動かない。私は， 6/2 から VC14 版 に替えた。 OpenSSL 1.0.2 系を使うためである。そんなわけで，同版を使われる場合は，前もって忘れずに vc_redist_x64/86.exe をインストールのこと。
いつもながら， Steffen には，頭が下がる。本当にありがとうございます。
ところで， phpMyAdmin 4.4.11 と MariaDB 10.0.20 へのアップデートもやった。
phpMyAdmin については 2 つばかり気づいたことがある。 4.4.10 からダウンロード先が， sourceforge.net から phpmyadmin.net に変わった。 4.4.11 からは MD5/SHA1 だけでなく， GPG も利用できるようになった。 sourceforge と phpmyadmin 間でなんかあったんかいネ。
昨日， FireFox 39.0 がやってきた。
これで FireFox も Logjam に対応済みになった。どんな脆弱性が修正されたかは，右ページで確認できる ⇒ Fixed in Firefox 39。
見ての通り，いつもながら数個の脆弱性への対応がなされている。そんなわけで，ブラウザってのは，常に新バージョンに更新しておく必要があるんだよね。まぁ，ブラウザに限った話じゃないけどさ (^^;)。
昨年， jprs.jp から「（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」というのが出て，それについて記事を書いたことがあるのだが，昨日，同件について更新情報が出た。「（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について（2015年5月26日更新）」
今回の更新情報の目新しいところとしては，
（2015年5月26日更新）
（*2）JPドメイン名では2015年1月19日より、レジストリロックサービスの
提供を開始しました。本サービスの提供方法及び提供範囲は、指定事
業者によって異なります。詳細はドメイン名の管理指定事業者にお問
い合わせください。
レジストリロックサービス
<http://jprs.jp/about/dom-rule/registry-lock/>
ということで，リンク先に行くと，レジストリロックサービスの具体例がわかる。
前回のときに，レジストリロックとレジストラロックの違いが分からなくてずいぶん悩んだから，ありがたい。
投稿アップデート情報 追記 追記２(7/7) 追記３(9/2) 追記４(9/5)
昨日， 8 時くらいに帰宅したのだが，今年，初の蛍を見た。まぁ，時刻的問題もあるから，昨日から飛び始めたとは限らないけど。
で，本題。 21 日に “TLSに脆弱性「Logjam」 – 国家レベルなら1024ビットまで盗聴可能” というのを読んで， Guide to Deploying Diffie-Hellman for TLS に行った。特に何も対策せずに，テストしてみたんだけどさ， 2014.Oct.28 (= OpenSSL で作る SANs 対応かつ SHA256 使用の自前認証局) のままで，右図の結果が出た。んで，「まっ，いいか」となった。
その夜，くりくりさんから， Logjam についてのコメントをいただいた。そんで「記事。何とか，がんばってみます」と返信したので，今，がんばってるところ。ヘヘッ。
最初にテストをした時点では，うちのサーバは，下の Cipher Suites をサポートしていた。
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-RSA-AES256-CBC-SHA384
- ECDHE-RSA-AES128-CBC-SHA256
- ECDHE-RSA-AES256-CBC-SHA
- ECDHE-RSA-AES128-CBC-SHA
- DHE-RSA-AES256-GCM-SHA384
- DHE-RSA-AES256-CBC-SHA256
- DHE-RSA-AES256-CBC-SHA
- DHE-RSA-CAMELLIA256-CBC-SHA
- DHE-RSA-AES128-GCM-SHA256
- DHE-RSA-AES128-CBC-SHA256
- DHE-RSA-AES128-CBC-SHA
- DHE-RSA-SEED-CBC-SHA
- DHE-RSA-CAMELLIA128-CBC-SHA
実のところ，ほとんどいらないんだよね，こいつら。だって，うちの 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 チェッカーでやってみたら，⇒みたいになった。
おまけだけど， Apache 2.4 で OpenSSL 1.0.1 以降を使ってる場合は， SSLProtocol all は +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2 の意味になる。 Apache 2.4.7 以降を使っている場合は， aNULL, eNULL and EXP ciphers are always disabled になっているんだそうだ。
いつもながら 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 でアクセスしたときだけである。
注意) この件，他のブラウザおよびバージョンではチェックしていない。
追記２(7/7):
昨日， FireFox 39.0 になりましたね。でもって， Good News! Your browser is safe against the Logjam attack になったでアリンス。
追記３(9/2)：
しばらく，チェックを忘れてて，今日， Google Chrome の 45.0.2454.85 が来たのでチェックしてみたら Good News! Your browser is safe against the Logjam attack になっていた。ウーン，いつなったんだろ，ワカンネ!!
追記４(9/5)：
今 5 日になったばかりだが，久々に SeaMonkey のアップデートが来て， 2.35 になった。でもって，やっと Good News! Your browser is safe against the Logjam attack が出るようになった。
投稿アップデート情報 追記(2/5) 追記２(2/7)
皆さま， Adobe Flash Player の新バージョンが出るまで， Google AdSense を停止することにしました。 Google AdSense に罪はないのですが，ご存知の通り， AdSense は時としてよくないサイトを表示してしまうことがあります。そんなわけで，現時点では― CVE-2015-0313 がゼロデイ攻撃に利用されている今という意味ですが― hxxp://www.retilio.com/skillt.swf の危険を回避するには止めたほうがいいだろうと判断したわけです。Adobe Flashの新たなゼロデイ脆弱性を確認、不正広告に利用。この悪しき swf は Dailymotion などを通して広がっているみたいですね。
Adobe Flash Player の新バージョンでゼロデイが解消されたら， Google AdSense を復帰させるつもりです m(_”_)m。
追記(2/5)：
Adobe Flash Player の新バージョンが出ましたね。今 (16 時), うちの IE， FireFox， Google Chrome 上で version 16.0.0.305 になっているのを確認しました。速やかに，新バージョンに更新しましょう。
2 ・ 3 日うちには， Google AdSense を復帰させるつもりです。今後は， CVE-2015-0313 狙いの悪性 swf に感染したら，それは，皆さん各自の責任ですよぉ（爆）。
追記２(2/7)：
Google AdSense を復帰させました。
投稿アップデート情報 追記(11/7)
昨日，「（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」というのが出ていたので，慌てて， Netowl と eNom を見に行った。見たのは， Netowl のレジストラロックがしっかりかかっているかと，両方の登録データが変わっていないかだけだが。パスワードは，もともとかなり複雑にして使っているので，変えても仕方ないだろうし。変えるタイミングもあるし。レジストラロックというのは，レジストラが提供しているわけで， Netowl のレジストラロックは Netowl が提供しているわけだ。 com ドメインの場合， Netowl はリセラーでレジストラとしては行動しないようだが，その場合でも，ロックは効くんだと思う。判断理由は， Value-Domain のときも Value-Domain はリセラーでレジストラは Key-Systems だったんだが，そのときも同じシステムだったからだ。それに eNom の設定では， Netowl がリセラーとして管理している私のドメインについては，そういう項目はなかったし。もっとも，確認はとっていないから，私が勝手に推測しているだけだ（汗）。
ところで，「（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」で記述のあるロックは，レジストリロックだ。これがよくわからない。記事を書いた時点（11/6）では，脳ミソが勝手に「リ」を「ラ」と読んでいた（滝汗）。レジストリロックというと，レジストリ側でロックをかけるという意味だろう。 com のレジストリというと， InterNIC ですかね。 jp だと， jprs だよな。 jp はともかく com って膨大な数だよ。実際の管理がレジストリ自体で可能なのかね。実は，レジストラやリセラーに管理委託しているとかなるんじゃないのか。
レジストラロックていうのは，多分， clientTransferProhibited の状態のことだと思うんだけど，レジストラロックとレジストリロックってどう違うんですかね。アチコチ読んでもすっきりと納得がいかない。
どなたか，ご指導よろしくお願いいたします m(_”_)m。
この件に関しては，ユーザにできることは限られているから，レジストラや権威 DNS サーバの運営者や CDN サービスなどにしっかりしてもらわないとどうしようもない。今年， eNom に移管するとき，過去の事件が頭をよぎったりしたのだが， jp 国内のドメインでもこういうことの起こる時代になったんだな。狙われるようになったら，国内には危ないところが，いっぱーーいあるんだろうと，戦々恐々である。
「速さにたじろぐ」のときにも書いたが，我が国は結構蚊帳の外だったからねぇ。ありがたくないけど，このあたりもグローバル化の時代を迎えたわけだ。
こんなことなくても，白物家電がゾンビ PC 化したり， USB の設計そのものが悪用されたりと，なんか無力感が甚だしいのになあ。
しかし，関連で名前挙がっている企業がおっきいとこだねえ。大きいとこはピンポイントで狙われるだろうから，その企業が特に弱いということではなく，強度については，どこも変わらんのだろうなあ。
追記(11/7)：
上の追記で，レジストリロックとレジストラロックについて，
> どなたか，ご指導よろしくお願いいたします m(_”_)m。
と書いたのだが，くりくりさんが，「登録情報の誤りによるドメインの停止措置について」というページを教えて下さった。なるほど，これがレジストリロックなんですね。よくわかる。
レジストラロックは，あくまで， Transfer Prohibited ，つまりドメイン移管禁止だもんね。当然ながらユーザが ON/OFF できる（リセラーに頼んで変えてもらうということも含めて）。レジストリロックは，ドメインの期限切れではないのに registrar hold にされることなんだ。ということは，移管どころか，ドメインの使用自体ができなくなってしまうわけだ。対応が遅れるとドメインが削除される可能性もあると。なるほど。
くりくりさん，ありがとうございました m(_”_)m。