がとらぼ

日本の銀行のSSL/TLS対応状況 2018年9月初旬

先月の結果では例のSymantecのクソ証明書を使っていて、いよいよヤバくね？というところが結構たくさん。
今回はそこに特化して確認してみた。全部の銀行を確認するの大変すぎるので前回の7月末に証明書がNGだった分のみ。

  • みずほ銀行: 証明書更新確認
  • セブン銀行: 証明書更新確認
  • 大和ネクスト銀行: 証明書更新確認
  • 山形銀行: 証明書更新確認
  • 武蔵野銀行: 証明書更新確認
  • 八十二銀行: NG ヤバい証明書
  • 北國銀行: NG ヤバい証明書
  • スルガ銀行: 証明書更新確認
  • 三重銀行: 証明書更新確認
  • 中国銀行: NGヤバい証明書
  • 広島銀行: NGヤバい証明書 ※1
  • 阿波銀行: 証明書更新確認
  • 百十四銀行: 証明書更新確認 ※2
  • 肥後銀行: 証明書更新確認
  • 鹿児島銀行: 証明書更新確認
  • あおぞら銀行: 証明書更新確認
  • 東京スター銀行: 証明書更新確認 ※3
  • 愛知銀行: 証明書更新確認
  • 愛媛銀行: 証明書更新確認
  • インターネットバンキングにwww.parasol.anser.ne.jpを使ってる43の銀行: 証明書更新確認

前回はNGだった上のリストの銀行の多くは8月中に対応したみたい(当然だよね)。
いよいよ証明書がヤバいのは残り4行。
Chromeブラウザリリースが予定どおりなら、できたら今夜あたり、最悪でも来週末には証明書の更新対応をしないとマズいでしょ。(Chrome 70betaの予定が9月13日とすると。stableは10月？)

※1 広島銀行
広島銀行はもうすぐリリースされるであろうChromeやFirefoxの次期最新版で利用できなくなる証明書だしTLS1.0, 1.1の暗号スイートは安全でなくTLS1.2の場合だけかろうじて危険ではないけど弱い暗号スイートで接続できる状態。しかも弱い順序指定。TLSの通信に対する意識はかなり低い銀行らしいんだけど、何故かブラウザの制限だけは無駄に強い。(次へ)

ひろぎん 利用不能
(Linuxだけど)PC版のChromeで広島銀行のインターネットバンキングに接続しようとしたら全く利用させてもらえないらしい。
どういう目的かわからないけどブラウザのバージョンを確認しろとのこと。いや、そんなことをしても全く解決につながらないよね。

Chromeバージョン確認
一応、メッセージに従ってブラウザのバージョンを確認してみました。
Chrome 68のオフィシャル版ですが、なにか？

ちなみにAndroidの最新版 Chrome 68から試してみたところ、推奨環境ではないというメッセージがポップアップ表示されるもののサービスを利用することは可能みたい。

「このブラウザで正常に利用できることを確認しましたよ」という表示をすることについては文句はないけど、制限することに何の意味があるとお考えなのでしょうか。しかも、最新バージョンに対応するということをしないのであればその制限は害悪でしかないよね。
ひろぎんのページで対応ブラウザを見ると例えばWindows10でChrome 46と書かれてる。3年も前のブラウザを使えということかしら。担当者の頭を開けて中に何が詰まってるのか確認させて貰いたいくらいですわ。

ActiveXコントロールのようなブラウザ依存の仕組みを使っているのでなければ、または、わざわざブラウザ依存のタグやCSSを使うのでなければ、または、正常に表示されないとかとんでもない脆弱性の存在が確認された等を除いて、積極的にブラウザを制限する必要はない筈。

※2 百十四銀行
百十四銀行のインターネットバンキングは8月に「114ダイレクト」というのに変わったらしい。インターネットバンキング入り口のURLは変わらず。
対応プロトコルはTLS1.0, 1.1, 1.2。つまりTLS1.1と1.2が追加になった。 既にTLS1.0と1.1は外して欲しいよねという時代ではあるけど互換性を捨てるという決断まではできなかったんでしょうね。どっちにしてもTLS1.1は要らんかったよね。
利用可能な暗号スイートと優先順位が大いに改善(ただし弱いの残る)。強度の評価としては「普通」レベルだと思うけど、日本の銀行が総じて評価低いのでこれで一気に上位へランクアップというところ。ちなみに前回までの評価は実質最下位ランクでした。

※3 東京スター銀行
前回の7月末と比較すると、利用可能な暗号スイートと優先順位の指定がまともになっているように見える。(ただし弱いの残る)。証明書の更新に合わせて改善されたのでしょうか。

Elastic Stackを6.3.2に更新する

Elastic Stack

FreeBSDのportsでElastic Stackを6.2系から6.3系に更新してみた。それなりに変わっているので油断せずに更新した方が良い筈。

更新

# service kibana stop    #Kibanaは必ず停める
# service logstash stop  #Logstash はここで停めずに最後に再起動でも良いかも
# service elasticsearch  #elasticsearch はここで停めずに最後に再起動でも良いかも

# portupgrade elasticsearch
# portupgrade logstash
# pkg delete kibana6     #Kibanaはデータを持ってないので削除するのは躊躇不要
# pkg delete node6       #Kibana6.3は Node.js 8を使うのでNode.js 6を削除
# cd /usr/ports/www/node8 
# make install
    たとえばLibreSSLなどを利用している場合はconfigオプションでBUNDLED_SSLにチェックすること
# cd /usr/ports/textproc/kibana6
# make install

# 以下3行はやった方がよさ気
# cd /usr/local/lib/elasticsearch/config
# mv jvm.options jvm.options.BAK
# cp jvm.options.sample jvm.options   #必要に応じて修正 (-Xmsや-Xmxなど)

# 以下3行は不要かな
# cd /usr/local/etc/logstash
# mv jvm.options jvm.options.BAK
# cp jvm.options.sample jvm.options   #必要に応じて修正

# portupgrade beats     #このホストでBeatsを利用しているなら合わせて更新

X-Packの更新

Elasticsearch 6.3.2からX-Packのインストールは不要になったらしい。ただし、elasticsearchを更新した場合は旧バージョンのX-Packが残ったままになっているのでそれを削除してやる必要があるみたい。
LogstashとKibanaはおそらく旧X-Packを削除しなくて良さそう。
これまでElastic Stackの更新を行おうとするとそれぞれのX-Packの更新で時間を取られて大きなダウンタイムが発生していたけど今後は簡単に素早く更新出来そう。

# /usr/local/lib/elasticsearch/bin/elasticsearch-plugin list           #インストール済みのプラグインを確認する
# /usr/local/lib/elasticsearch/bin/elasticsearch-plugin remove x-pack    #X-Packを削除する

# /usr/local/lib/elasticsearch/bin/elasticsearch-plugin install x-pack      #仮にX-Packをインストールしようとしても弾かれる
ERROR: this distribution of Elasticsearch contains X-Pack by default

# /usr/local/logstash/bin/logstash-plugin install x-pack      #仮にX-Packをインストールしようとしても弾かれる
Logstash now contains X-Pack by default, there is no longer any need to install
it as it is already present.
ERROR: Invalid pack for: x-pack, reason: x-pack not an installable plugin, message: x-pack not an installable plugin

# /usr/local/www/kibana6/bin/kibana-plugin install x-pack      #仮にX-Packをインストールしようとしても弾かれる
Plugin installation was unsuccessful due to error "Kibana now contains X-Pack by default, there is no longer any need to install it as it is already present."

他のプラグインを利用している場合はそれらも必要に応じて更新する。

設定ファイルの変更

/usr/local/etc/logstash/logstash.yml (1行変更)
xpack.monitoring.elasticsearch.url: ["http://es1:9200", "http://es2:9200"]

行頭の#を取るのとelasticsearchが動いているホスト名に変更。これはやっておかないとKibanaのモニタリングにLogstashが表示されない筈。

サービスの再起動・起動

# service elasticsearch restart    #再起動
# service logstash restart         #再起動
# service kibana start             #起動
# service metricbeat restart       #再起動  以下2行はbeatsを更新した場合且つ稼働しているとする
# service filebeat restart         #再起動

それぞれログを見てエラーが出ていないこと、勝手に停止しないことを確認する。
しばらく監視してメモリを食い尽くされないことも確認しておかないと怖いよ。

Kibana モニタリング
KibanaのMonitoringにLogstashが表示されることも確認しておく。

Beats

6.2系から6.3系に変更したところ、hostの出力がhost:hogeではなくhost: { name: hoge } という嫌らしい構造に変わっている。KibanaのVisualizerのGUIによるFilter追加でひっかからなくて困るのでbeat.hostnameに切り替えた方が良さげ。ただし、beatsの出力やLogstashのFilterでbeat.hogeをdropしていないこと。dropしているなら要修正。
なお、beats7.0-alphaではhost:hogeに戻ってるような・・・(自分でビルドした分で確認)

関連記事:
Up