さて、これについて新しい情報がでてきたのでお知らせです。
関連情報
- Gradually sunsetting SHA-1（Google Online Security Blog: 2014年9月5日）
- An update on SHA-1 certificates in Chrome（Google Online Security Blog: 2015年12月18日）
- ChromeのSHA-1証明書サポートに関する最新情報（バッキーの日々是爆食）
フェーズ１ 新規 SHA-1証明書をブロック
- 2016年1月1日以降に公的認証局（public CA）にて発行した SHA-1証明書を使ったSSLサイトは、Chrome 48以降ではアクセス出来なくなります。
ということなので、来年からはSHA-1証明書をやめましょうということ。
Microsoftでも、「マイクロソフト、SHA-1廃止の前倒しに言及（ZDNet Japan）」などの記事を見ると、SHA-1証明書のサポート終了日を前倒しにすることを検討しているとか。流れ的にはSHA-1証明書は廃止の方向へ行っているので、それに合わせていくのがよいかなと思います。
まぁ、そもそも公的証明局（public CA）で、 SHA-1証明書を発行してもらえないようになるとは思うので、まだ影響は軽微なのじゃないかなーとは思います。
フェーズ２ 全 SHA-1証明書をブロック
2017年1月１日より、全ブロックとのことです。
具体的には公的認証局にて発行したSHA-1証明書を使ったSSLサイトへのアクセスは、致命的なネットワークエラーになってアクセスできないということです。
同時に、Microsoft EdgeやFirefoxも、2017年1月1日（前倒しの可能性あり）を視野に廃止に向けて移行をすすめているということなので、この段階までには SHA-256証明書への移行を完了しておくことが必須になりそうですね！
Chrome 48より、RC4暗号スイートを使ったTLS接続もブロック
そんなに影響は出ないと思いますが、2016年1月以降の早期にリリースされる Chrome 48にしたとたん、アクセスできないサイトが出てくるかもしれません。まぁ RC4をストップされたとしても、他の暗号スイートも合わせて設定しているはずで、問題はでないと思いたい。
RC4が使われているかどうかは
でチェックするとよいでしょう（RC4 yes とか赤文字で書かれてたらアウト。セッションハイジャックの手法も公開されているようなので、本件に関わらずRC4無効化推奨）。
ウェブ管理者でApacheなら「SSLCipherSuite」にてRC4を設定していないかチェックするとよいと思います。
どのような設定がよいのか、ちょっと１年前の情報になってしまいますが
- サーバーのSSL/TLS設定のツボ（Internet Week 2014セッション）
が参考になるかなと思います。
もちろん、TLS 1.2プロトコル対応し、ECDHE_RSA_WITH_AES_128_GCMの暗号強度があればいいのですが、それなりに古いサーバーではそういうわけにもいきませんので、そのあたりは出来る限り対応しておくということにはなるかなと思います。
2015年12月22日 @kimipooh
0 件のコメント:
コメントを投稿