PHP7.0.3 が出たので，一昨日アップデートした。 ChangeLog はここね。自鯖は Windows7 HE SP1 x86 なので， php-7.0.3-Win32-VC14-x86.zip をダウンロードした。
新 php.ini-production の変更点はコメント文のみ。 php.ini について，もっと詳しい情報をという方は，「本家のお世話-#109。（PHP 5.5.16 から PHP 5.6.0 への移行）」をご覧ください。
phpMyAdmin も 4.5.4.1 に更新した。初めて phpMyAdmin をインストールする場合は，「Windows7上にWamp系WebServerを建てる-#3」や「phpMyAdmin 環境保管領域」を参照してください。
年頭から phpMyAdmin のリリースマネージャーが Isaac Bennetch になった。というわけで旧い keyring はアップデートしないとファイルの検証ができない。 Verifying phpMyAdmin releases 参照のこと。
OpenSSL Security Advisory [28th Jan 2016] を読んだ後，ちょっと SSL/TLS 関連事項を弄っていた。まぁ，今回の Advisory には ‘Severity: Critical’ は含まれていなかったんだけどね。自鯖の Cipher Suites をもう少し改善しようと思ったわけだ。
HTTP/2 をサポート後， ‘AESGCM:HIGH:MEDIUM:!MD5:!RC4’ の設定で自鯖を動かしてきた。これで使用可能な Cipher Suites の一覧がこれなんだが，これには SSLv3 レベルも含まれている。勿論，自鯖では SSLv3 プロトコルは使えなくしているけど。
そんなわけで，このリストから SSLv3 cipher suites と HTTP/2 の仕様ページの TLS 1.2 Cipher Suite Black List に掲載されているものを除いてみた。こんな感じ。
この結果，下記の chiper suites が残った。
| ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 DHE-DSS-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 DHE-DSS-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 |
これに ECDHE-RSA-AES256-SHA を加えたものを新しい SSLCipherSuite にした。 ECDHE-RSA-AES256-SHA は Android 4.3 以下対策である。ログで訪問者にそういう方がおられるもんで。そんなわけで， ssl.conf の SSLCipherSuite の値はこんな感じ☟。
| ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA |
’openssl ciphers -v ～’ コマンドは， cipher suites リストを OpenSSL 形式で表示するが， TLS 1.2 Cipher Suite Black List には関連仕様書の形式で載っている。その辺に詳しくない場合は， TLS v1.2 cipher suites を見に行くと対照表があるので，幸せになれるよ（笑）。
ところで，くりくりさんが， OCSP Stapling という記事を書いておられたので， ‘openssl s_client -connect ～’ をやってみた。我が家も， StartSSL の証明書になって以来， OCSP Stapling を使っているし。まぁ，自前認証局では， CRL でいくしかないからね。結果が，これ。 handshakes が成功したら， head は TLS のバージョンにかかわらずおんなじ。
「覚え書-#28。」への6件の返信
こんにちは
>これに近いものを消してしまった私の「ガックリ」をお察しください（笑）。
しかも夜中ですか？（ｗ
失礼ながら、o6asanさんのことでたまに笑ってしまうことがあります。
年末でphpの脆弱性を調べていたら
TODOSからメールでハンドルネームが間違えられるし
メール見て吹いちゃいました。
さて、ssl_ciphersですが、
最初の印象はサイト製作者はこのようなことをかんがえなくていいのだから、https移行が難しいとか何いってるんだといいたいですな
話がずれましたが、ssl_ciphersはlogjam以来何もしていません（ｗ まぁ暗号スイートとかは確認サイトで定期的に確認するようにしてるだけですね。
ブラックリストまであるとは・・・。
まったくしりませんでした。よくこういうのをみつけられますよね。
OCSP Staplingも古い技術ですが、知りませんでした。
なんか漏れがないか今も探してる所です。
くりくりさん，こんばんは。
（笑）を提供できてよかった＼(^o^)／。
帰宅してから，改めて眺めてみたら，記事としてはそれほど長くないですね。でも，コメントとしてはかなり長かったんですよ，これにさらに KB2952664 の話なんかも入っていたわけで，ハハ。
> よくこういうのをみつけられますよね。
これは，昨年， HTTP/2 の仕様を調べたときに気づきました。
そういうことでいえば，「くりくりさんはよく新しい話題に気づくなぁ，やっぱり本職だな」とか，私はいつも思ってますよ。
ところで， https://tools.keycdn.com/http2-test って新しい h2 に対応していないんでしょうか。今日見つけて，ふとやってみたら， not supported かつ ALPN is not supported になりました。
nghttp -v だと（バージョンは 1.6.0 です），
[ 0.022] Connected
The negotiated protocol: h2
[ 0.072] recv SETTINGS frame
(niv=1)
[SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
[ 0.072] recv WINDOW_UPDATE frame
(window_size_increment=2147418112)
[ 0.072] send SETTINGS frame
(niv=2)
[SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
になるし，
curl -v –http2 だと（バージョンは 7.47.0 です），
・・・・・・・
* ALPN, offering h2
* ALPN, offering http/1.1
・・・・・・・
* ALPN, server accepted to use h2
になるので，間違いなくサポートできてると思うんですがねぇ。
追記(2/22)：
今日やったら，我が家が，「Yeah! o6asan.com supports HTTP/2.0.」「ALPN supported.」になりました。くりくりさんのところも。くりくりさんのところは，「Yeah! www .superweibu.com supports Brotli compression.」も出ましたヨ。
今晩は
この手のサイトはあんまり信用しないほうがいいかなとおもいます。
http/2をチェックできるサイトとかあったのですが、
俺のは未対応になっていたしそのサイトはいつの間にかきえています。
下記にアクセスしてyesになってれば問題ないですね。
https://www.ssllabs.com/ssltest/
Application-Layer Protocol Negotiation (ALPN) Yes
くりくりさん，こんにちは。
> この手のサイトはあんまり信用しないほうがいいかなとおもいます。
そうですね。 SPDY と HTTP/2 の話のところに， H2 というのが出てくるので，そのあたり，新しくやり直してるのかなと思ったんですが。 h2 ではなくて，大文字での表記のままというのが問題かな？
SSLLABS はバージョンが 1.21.13 に変わって ALPN に対応したんですね。昨年の 11 月にチェックしたのもでは， NPN の表示しかなかったんですが，さっき確認したら，確かに ALPN の表示もありました。いつ変わったんだろう？気づきませんでした。
そういえば，くりくりさんのところの結果では，一番下あたりの SSL 2 handshake compatibility は何になっていますか？うちでは yes になっていて，大概調べたんですが，どこが原因かわかりません。 Community の質問に SSL 2 handshake compatibility というのがあって，それの回答に Ivan Ristić が心配しなくても問題ないから見たいなことを書いているのですが， yes になる理由としては， source code の手直しやコンパイルのし直しがないからだろうと書いているんですよね。そんなわけで，他のディストリのファイルを使っている方の結果が気になりました。
今晩は
ssl handはyesになっています。
>他のディストリのファイルを使っている方
結構有名なhttpsサイトを何個かしらべましたが
全部ついてました。
あんまり気にする必要はないとおもいますよ。
くりくりさん，こんにちは。
お返事が遅くなりまして，どうも。
朝から出ていて，今，帰ってきました。
> あんまり気にする必要はないとおもいますよ。
気になったのは，安全かどうかということよりも， yes が出る原因の方なんです。他のディストリの有名どころのサイトでも同じような結果ということは，やはり，ソースコードやコンパイルのオプションに原因があるんでしょうね。私のレベルでは手の出しようがない部分のようです。
調べていただき，ありがとうございました。