文京区立図書館サイト、メンテ明け直後に何かが起きていた?

図書館の利用カードや、Web サイトのログイン用 ID に関しては、なんらアナウンスがなかったので、単純なバージョンアップなのだろう、と思っていた、文京区立図書館の Web サイト。特に、目立った不具合もなく再開されました。

実際にサービス再開後に、サイトにアクセスしてみたところ、認証周りの画面遷移が変更されていたり、蔵書検索画面などでログイン状況が表示されるようになっていたり、スマホ専用画面が用意されていたりと、細かく変更がかかっていました。

ただ、チョット注意深く確認をしてみたところ、どうも裏でドタバタがあったんじゃないかというのが、推測されるような証拠がちらほら。

今回のメンテの目玉は、サーバ証明書の SHA-2 化だったわけですが…

アナウンスにもある通り、今回のメンテナンスにおける最大のポイントは、 SSL/TLS 接続で使われるサーバ証明書を SHA-2 対応に変えるというものだったわけですけど、どうもこの辺りの設定に関してサービス再開後にも変更が行われた形跡があるんですよね…。

まず、メンテ期間中の 1 月 4 日から 1 月 8 日の間に、サーバ証明書の入れ替えが行われたことが確認できています。
Qualys SSL Labs で提供されている SSL Server Test での診断結果の一部ですが、左が 1 月 4 日時点で、右が 1月 8 日時点。

SSL Server Testでの診断結果 2016/1/4時点SSL Server Testでの診断結果 2016/1/4時点

まぁ、Rating の低さは気になりましたけど、再オープンまでにはちゃんと対処されるんだろうなぁ、と思っていたんですが…。
#この時点で、TLS 1.0 しか有効になってないのとか、気にはなっていなかったわけではない。


サービス再開後の 1 月 9 日の夜に、色々とチェックしている過程で、HTTP ヘッダを見ていて気がついたのですが…。

root@vps2:~# curl -vIL https://www.lib.city.bunkyo.tokyo.jp/
* Trying 218.40.15.133...
* Connected to www.lib.city.bunkyo.tokyo.jp (218.40.15.133) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 696 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* gnutls_handshake() warning: The server name sent was not recognized
* SSL connection using TLS1.0 / ECDHE_RSA_AES_256_CBC_SHA1
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: www.lib.city.bunkyo.tokyo.jp (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=JP,ST=Tokyo,L=bunkyo,O=Bunkyo City,OU=Bunkyo City Public Library,CN=www.lib.city.bunkyo.tokyo.jp
* start date: Mon, 21 Dec 2015 00:00:00 GMT
* expire date: Sat, 07 Jan 2017 23:59:59 GMT
* issuer: C=US,O=Symantec Corporation,OU=Symantec Trust Network,CN=Symantec Class 3 Secure Server CA - G4
* compression: NULL
* ALPN, server did not agree to a protocol
> HEAD / HTTP/1.1
> Host: www.lib.city.bunkyo.tokyo.jp
> User-Agent: curl/7.46.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Sat, 09 Jan 2016 13:22:42 GMT
Date: Sat, 09 Jan 2016 13:22:42 GMT
< Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.5.30
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.5.30
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Content-Type: text/html; charset=None
Content-Type: text/html; charset=None

< * Connection #0 to host www.lib.city.bunkyo.tokyo.jp left intact

「"SSL connection using TLS1.0 / ECDHE_RSA_AES_256_CBC_SHA1" って、どういうこと?マズくね、これ…。」と…。
これ見て、しばらくモヤモヤした気持ちになっていたわけですが、1 月 10 日になって再度 SSL Server Test で診断してみたところ…。

SSL Server Testでの診断結果 2016/1/10時点

「あ、あれ?色々と直ってる…。」

直ったことは良いとしても…

Rating が大きく向上している通り、 9 日時点では TLS1.0 にしか対応してなかったものが、どこかのタイミングで TLS 1.2 まで有効とする設定への変更を実施したようなのですよ。

サービス再開の時点で、 TLS 1.2 に対応した状態になっていることが理想的状況だったはずなのだと思うのですが、誰がどのタイミングで設定変更の必要性を認識し、どのように対処をしたのか、行政側も承知の上で行われたものなのか、というのが気になるわけです。
おそらく、サービス再開直後のトラブル対応のために行政サイド、ベンダサイドともに担当者が待機していたでしょう。だとすれば、待機チームの中で、これらの変更に関する協議が行われ、その記録が何らかの形で残っているはず、と考えられるわけで、やはり情報開示請求を掛けてみる、というのが良さそうな感じですね。

さ〜て、どうしたもんかな…。

トラックバック(1)

前に突っ込み入れていたとおり、昨年末から今年年初にかけて行われていた、図書館システムのリニューアルに関連する Web サイトの SHA2 対応のためのサ... 続きを読む

コメントする