昨日， 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 チェッカーでやってみたら，⇒みたいになった。
いつもながら 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 が出るようになった。
「遅ればせながら， Logjam の話。」への6件の返信
おはようございます。
Xserverは、
Warning! This site uses a commonly-shared 1024-bit Diffie-Hellman group, and might be in range of being broken by a nation-state. It might be a good idea to generate a unique, 2048-bit group for the site.
と出てきます。
サポートに要望した方が良いかしらね？
りりさん，おはようございます(?)。
Xserverは，私が調べた某銀行さんやくりくりさんの会社の旧サーバと同じ状態だと思います。 https://tools.keycdn.com/logjam でチェックすれば， Safe! The domain 某銀行さん:443 is not vulnerable to TLS Logjam attacks. が戻ってくる状態でしょう。つまり， Disable Export Cipher Suites と Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE) はできている状態ですね。
Xserver の場合は，他の POODLE, FREAK 等への対策がなされていれば，上記 2 つで特に問題ないのではないかと，私は思いますが……某銀行さんは， 2048bit 対応してほしいです（苦笑）。
こんにちは
>今年，初の蛍を見た。
早いですね。もう初夏でしょうか？
>記事。何とか，がんばってみます
イヤーお疲れ様です。
医者いってきました。微熱で37.2度あったのはびっくり
市販薬なんかより、最初からこっち行ったほうがよかった・・・
SSLOpenSSLConfCmdの指定は2.4.8でしたね。
俺の方も修正しておきました。
会社の方はopensslもあげられないしもともともFreak対策していたのでそのまま1024bitでがんばりますｗ
くりくりさん，こんにちは。
>> 今年，初の蛍を見た。
> 早いですね。もう初夏でしょうか？
去年蛍の記事を書いたのは，シーズンの終わりごろでしたから，今ぐらいの時期が，始まりなんでしょうかネ。
> 医者いってきました。微熱で37.2度あったのはびっくり
それは，素早い。 37.2℃くらいって，一番気分の悪いレベルですね。どうぞ，お大事に!!
> SSLOpenSSLConfCmdの指定は2.4.8でしたね。
これ，うちの場合， Apache は 2.4.12 でクリアしているのですが， OpenSSL が 1.0.1 系列なんです。Apache Lounge で 1 月に「Also OpenSSL 1.0.2 is around the corner.」って言ってたのに， 1.0.2 系でのビルドバイナリが出ないよなぁとか思っていたら，なんか手こずっているみたいです。フォーラムでコントリビュータの書き込みを見ると，成功している人もいるようなので，そのうち出ると期待してます。 Windows のビルドってやったことないけど，難しそうですね。
こんにちは
Let`s Encryptをしらべていました。
従来のやり方とまったく違う方法で
証明書を発行していたのがとても面白いです。
この方法ならhttpsが一気にすすむかも？
くりくりさん，こんばんは。
ちょっと，長くなりました。ご容赦。
Let’s Encrypt の件，確か前に一度お話されていましたよね。今回，公式に行って，少しだけ覘いてみました。今年の中ごろに，本式にスタートするようなことを書いてありますね。 2015.5.21 のブログの記事は，「Let’s Encrypt 利用者契約草案」という題名なので，これは，読んでみないといけないでしょう……といいつつ，全然読めてませんが（汗）。
Major Sponsors がこんなことになってますから， Mozilla の Deprecating Non-Secure HTTP なんていう動きとも関係あるんでしょう。ご存知のように， Google とかもどんどん secure サイトに重きを置く方向に変わってきてますし。
「でも，今のままこの方向にどんどん進んでいくと，私なんかはどうしたらいいんだろう？」と思っていましたが， Let’s Encrypt が進水すれば，これを使えばいいわけですネ。ここの証明書はレベルとしては自前認証局と同レベルだと思います。つまり， DV サーバ証明書レベルという意味。(追記 : DV と同レベルと言ってしまうと，ちと，語弊がありますかネ。意図するところは解っていただけると思いますが（汗）)
まぁ， DV というのは，その証明書を使っている組織の実在性は証明してくれませんが，通信は暗号化してくれるわけで，これは私が現在自前認証局に望んでいるのと同じレベルになります。これを達成するために，「OpenSSL で作る SANs 対応かつ SHA256 使用の自前認証局」みたいに必死にならなくても， lets-encrypt のインストールと lets-encrypt example.com の設定だけで，やれるわけですから，大助かりですよね。
こういうプロジェクトがうまくいけば，無料 Wi-Fi なんぞも盗聴を気にせずに使えるようになるのかもしれないです。もしかして，その辺も目指しているのでしょうか？この辺の話，公式のブログをしっかり読めばわかるのだろうか。
もっとも，それは， Major Sponsors に入っている組織や Board のメンバーが，どの程度信頼できるのかというシビアな問題にもつながってくるのですが……