ウェブサーバのTLS ChaCha20-Poly1305で通信させたい

以前にECDSAな証明書を作成したときにP-256を使ったけど、P-256は根拠は無いがなんか信用できないという人がいるのも確か。そこで来たるべくTLSv1.3時代を見据えてChaCha20-Poly1305やX25119にも対応させてみたい。速いらしいし。

サーバーOSは例によってFreeBSD、ウェブサーバはNginx、TLSに使うのはLibreSSLではなくOpenSSLとする。

OpenSSLの置き換え

X25519を使用するにはOpenSSL 1.1.0以上が必要だがFreeBSDのportsでOpenSSL(security/openssl)をインストールしている場合は1.0.xの筈なので非対応。security/openssl-devに変えなければならない。つい2ヶ月ほど前まではsecurity/openssl-devをインストールしようとすると多くの関連portsがビルドエラーになっていたが、急速に対応状況が改善していて2018年6月11日時点ではOpenSSLに依存しているportsの殆どがsecurity/openssl-dev対応になっている。一部非対応portsも残っているので油断はできないが。

/etc/make.conf(1行変更)
1
2
3
4
5
(変更前)
DEFAULT_VERSIONS+=ssl=openssl

(変更後)
DEFAULT_VERSIONS+=ssl=openssl-devel
OpenSSL ports置き換え手順 (portsツリー更新は省略)
### OpenSSLのオリジン替え
# portupgrade -o security/openssl-devel security/openssl
### 上のコマンドで反応しない場合はこちら、上で更新されたら↓の1コマンドは不要
# portupgrade -f -o security/openssl-devel security/openssl

### OpenSSLに依存しているportsを全て更新 (時間かかる)
# portupgrade -fr security/openssl-devel

Nginxの設定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
server {
    listen 443 ssl http2;
    listen [::]:443  ssl http2;
    server_name hoge.example.com;

中略

    #RSAの証明書
    ssl_certificate      /path/rsa.pem;
    ssl_certificate_key  /path/rsa-key.pem;

    #ECDSAの証明書
    ssl_certificate      /path/ecdsa.pem;
    ssl_certificate_key  /path/ecdsa.key;

    #DHパラメータファイル (この記事の設定的には不要な筈だが、無いとNginxがエラーになる筈)
    ssl_dhparam          /path/dhparam4096.pem;
    
    ssl_protocols        TLSv1.2;
    ssl_prefer_server_ciphers  on;
    ssl_ciphers          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
    ssl_ecdh_curve       X25519:prime256v1;

中略

}

ECDSAの証明書が 無い or 使わない ならECDSA証明書の項目は削除でssl_cipherでECDSAを含む暗号スイートを削る。(半分になる)
今回は趣味でChaCha20-Poly1305を先頭に置いたが、サーバー側のCPUがIntelやAMDでAES-NIを効かせた処理速度を考えるとAESを優先させたいところ。逆にスマートフォンの閲覧者が多いサイトであれば(サーバー側が多少ツラくても) 非AES-NI環境で高速なChaCha20-Poly1305を優先してやると良いかも。
P-256が嫌いならssl_ecdh_curveから :prime256v1 を削るか別のに変える。

Nginxの再起動

###設定が致命的に間違っていないことを確認する
# service nginx configtest

###エラーが出ないならNginxを再起動する。
# service nginx restart

ブラウザで接続してみる

RSAの証明書のサイトでChaCha20-Poly1305 X25519 1
証明書がRSAなサイトでChaCha20-Poly1305 X25519な接続になるとブラウザではこのような表示。
(Chromeではページを表示して[F12]でデベロッパツールを開き[Security]タブを選択する)
ちなみに上の画像は「がとらぼ」をPC版のChromeで表示したもの。(2018年6月11日現在)

RSAの証明書のサイトでChaCha20-Poly1305 X25519 1
証明書がECDSAなサイトでChaCha20-Poly1305 X25519な接続になるとブラウザではこのような表示。
これは「がとらぼ」ではない別なサイトをECDHE-ECDSA-CHACHA20-POLY1305を最優先にして試したもの。

RSAの証明書のサイトでChaCha20-Poly1305 X25519 1
証明書がRSAなサイト(ここのこと)をQualysSSL LabsのSSL Server Testで見たもの。暗号スイートの優先順位も上の設定例で意図したとおりになっている。

ChaCha20って速いのかしら

###AES-NL有効化状態で計測
% openssl speed -elapsed -evp chacha20
% openssl speed -elapsed -evp aes-128-gcm
% openssl speed -elapsed -evp aes-256-gcm
% openssl speed -elapsed -evp aes-128-cbc

###AES-NL無効化状態で計測
% setenv OPENSSL_ia32cap "~0x200000200000000"      ←(tcsh用環境変数セット)
% openssl speed -elapsed -evp chacha20
% openssl speed -elapsed -evp aes-128-gcm
% openssl speed -elapsed -evp aes-256-gcm
% openssl speed -elapsed -evp aes-128-cbc

上のコマンドをIntel Pentium G630T 2.3GHzという非常に非力なPCで実行してで比較してみた。aes-128-cbcはAES-NLが効きやすいので有効化・無効化の差をはっきりと示す為の参考程度で。
逆に言うといまどきのセキュリティ重視な設定のウェブサーバ用途ではAES-NLは以前と違いあまり恩恵がない?ハードウエアの性能によるかしら。

速度比較AES-NLオン 1
AES-NLを有効化した計測結果。3秒で何回計算したかというもの。緑が参考値のaes-128-cbcだが、AES-NL有効でChaCha20とほぼ同じくらいを出せたのは16バイトのブロックの場合だけ。もっとaes-128-cbcが高い値になると思っていたので意外。
他のサイズではChaCha20が圧倒。ざっくり見てaes-128-gcmの3倍の値を出している。

速度比較AES-NLオン 2
AES-NLを有効化した計測結果。上のグラフの結果から計算回数とブロックの大きさを掛けて速度にしたもの。(実際にはコマンド実行で両方の数値が表示される)
効率からみると8192バイトのブロックが最も良い数値になるのかしら。こちらもaes-128-cbcがChaCha20と対等だったのは16バイトのブロックのときだけ。他はChaCha20が圧倒。そして、256バイト以上のサイズのブロックではaes128-gcm, aes-256-gcm, aes-128-cbcで大して変わらないことに。

速度比較AES-NLオフ 1
AES-NLを無効化した計測結果。3秒で何回計算したかというもの。AES-NLが効いてないので緑のaes128-cbcが1/3ほどに低下している。他のaes128-gcmやaes128-gcmも激減というほど酷くはないものの数値の低下はある。

速度比較AES-NLオフ 2
AES-NLを無効化した計測結果。上のグラフの結果から計算回数とブロックの大きさを掛けて速度にしたもの。(実際にはコマンド実行で両方の数値が表示される)
圧倒的な差を見せつけてChaCha20が勝利。

今回はCPUがショボイというのもあってか「がとらぼ」の中の人の思惑通りというか都合良くもChaCha20以外の選択肢はないだろというような圧倒的な結果になったが、サーバのマシンの性能によっては必ずこうなるとは限らない筈なのでウェブサーバで実際に試してみて安全で効率の良さそうな暗号スイートの優先度を上げるというのもアリかも。もちろん閲覧者の皆がメジャーブラウザの新しいバージョンを使っているとは限らないのでどうしても接続互換性重視ということであればChaCha20-Poly1305が最優先ということにはならないだろうけど。

日本の銀行のSSL/TLS対応状況 2018年6月

セキュリティ基準であるPCI DSSのv3.2では2018年6月30日、つまり今月末をもって脆弱性のあるSSL3.0とTLSv1.0の実装(使用)を無効化しなければならないとなっている。TLSv1.1にも脆弱性があって非推奨になってる筈だけどPCI DSSでは1.1以上にしろということなので1.1は使えるのね。

最近ではYahoo! JAPANが2018年6月1日以降TLS1.0/1.1のサポートを順次終了っていうのがニュースになってたけど、これが本来のあり方で他のウェブサイトも倣って欲しいところだけど、PCI DSSでそうなってるから仕方なくといった感じでTLSv1.0だけ無効化してる業者をチラホラ見る程度。むしろ、うちはPCI DSS関係ないからって逃げてる企業が殆ど?

PCI DSSはクレジットカード業界用なので銀行には関係ないっちゃ関係ないんだけど、銀行も全く無関心ではなかった筈。そこで銀行コード1000番以下で信託銀行や外国の銀行を除いたものに「ゆうちょ銀行」を加えた銀行で「個人顧客向けのオンラインバンキングのログイン画面」のページを表示したときに使われているSSL/TLSがどうなっているか調べてみた。

銀行名 SSL
3.0
TLS
v1.0
TLS
v1.1
TLS
v1.2
ホスト名 その他
みずほ銀行 表示 弱いのしかない, RC4
三菱東京UFJ銀行 表示 一応普通 順序が一部変
三井住友銀行 表示 弱いのしかない, RC4
りそな銀行 表示 優先順が酷い 使われるのは弱いかも, RC4
埼玉りそな銀行 表示 優先順が酷い 使われるのは弱いかも RC4
ジャパンネット銀行 表示 普通だがRC4あり
セブン銀行 表示 普通
ソニー銀行 表示 普通だがRC4あり
楽天銀行 表示 普通
住信SBIネット銀行 表示 一応普通 順序が一部変
じぶん銀行 表示 普通
イオン銀行 表示 危険, 再ネゴ
大和ネクスト銀行 表示 普通
北海道銀行 表示 弱い順
青森銀行 表示 弱い順
みちのく銀行 表示 弱い順
秋田銀行 表示 弱い順, 秋田銀行ドメインは弱い+ssl3
北都銀行 表示 弱い順
荘内銀行 表示 弱い順
山形銀行 表示 弱いのしかない, RC4
岩手銀行 表示 弱い順
東北銀行 表示 弱い順
七十七銀行 表示 弱い順
東邦銀行 表示 弱い順
群馬銀行 表示 弱い順
足利銀行 表示 弱い順
常陽銀行 表示 普通だが弱め
筑波銀行 表示 弱いのしかない, RC4
武蔵野銀行 表示 弱いのしかない, RC4
千葉銀行 表示 弱い順
千葉興業銀行 表示 弱い順
きらぼし銀行 表示 弱い順
横浜銀行 表示 弱い順
第四銀行 表示 弱いのしかない, RC4
北越銀行 表示 弱い順
山梨中央銀行 表示 弱い順
八十二銀行 表示 弱いのしかない, RC4
北陸銀行 表示 弱い順
富山銀行 表示 弱い順
北國銀行 表示 弱いのしかない, RC4
福井銀行 表示 弱い順
静岡銀行 表示 弱い順
スルガ銀行 表示 弱い順, RC4
清水銀行 表示 弱い順
大垣共立銀行 表示 弱いのしかない, RC4, ROBOT
十六銀行 表示 普通
三重銀行 表示 弱い順
百五銀行 表示 弱い順, RC4
滋賀銀行 表示 弱い順
京都銀行 表示 弱い順
近畿大阪銀行 表示 優先順が酷い 使われるのは弱いかも, RC4
池田泉州銀行 表示 弱い順
南都銀行 表示 普通だが弱め
紀陽銀行 表示 弱い順
但馬銀行 表示 弱い順
鳥取銀行 表示 弱い順
山陰合同銀行 Windows IE以外で利用不能のため調査できず
中国銀行 表示 弱いのしかない, RC4
広島銀行 表示 弱いのしかない, RC4
山口銀行 表示 普通
阿波銀行 表示 弱いのしかない, RC4
百十四銀行 表示 弱いのしかない, RC4, POODLE
伊予銀行 表示 弱い順
四国銀行 表示 弱い順
福岡銀行 表示 弱い順
筑邦銀行 表示 弱い順
佐賀銀行 表示 弱い順
十八銀行 表示 弱いのしかない, ROBOT
親和銀行 表示 弱い順
肥後銀行 表示 弱い順
大分銀行 表示 弱い順
宮崎銀行 表示 弱いのしかない, RC4
鹿児島銀行 表示 弱い順 RC4
琉球銀行 表示 弱いのしかない, RC4
沖縄銀行 表示 弱い順
西日本シティ銀行 表示 弱い順
北九州銀行 表示 普通
新生銀行 表示 順は良いがRC4あり, POODLE
あおぞら銀行 表示 弱い順
北洋銀行 表示 弱い順
きらやか銀行 表示 弱い順
北日本銀行 表示 弱い順
仙台銀行 表示 弱い順
福島銀行 表示 弱い順
大東銀行 表示 弱い順
東和銀行 表示 弱い順
栃木銀行 表示 弱い順
京葉銀行 表示 弱い順
東日本銀行 表示 弱い順
東京スター銀行 表示 弱い順
神奈川銀行 表示 弱い順
大光銀行 表示 弱い順
長野銀行 表示 弱い順
富山第一銀行 表示 弱い順
福邦銀行 表示 弱い順
静岡中央銀行 表示 弱い順
愛知銀行 表示 弱い順
名古屋銀行 表示 弱いのしかない, RC4, ROBOT
中京銀行 表示 弱い順
第三銀行 表示 弱い順
関西アーバン銀行 表示 弱い順
大正銀行 表示 弱い順
みなと銀行 表示 弱い順, RC4
島根銀行 表示 弱い順
トマト銀行 表示 弱い順
もみじ銀行 表示 普通
西京銀行 表示 弱い順
徳島銀行 表示 弱い順
香川銀行 表示 弱い順
愛媛銀行 表示 弱い順
高知銀行 表示 弱い順
福岡中央銀行 表示 弱い順
佐賀共栄銀行 表示 弱い順
長崎銀行 表示 弱い順
熊本銀行 表示 弱い順
豊和銀行 表示 弱い順
宮崎太陽銀行 表示 弱い順
南日本銀行 表示 弱い順
沖縄海邦銀行 表示 弱い順
きらぼし銀行の旧八千代銀行用 表示 弱い順
ゆうちょ銀行 表示 弱いのしかない, ROBOT

リスト幅の制限でホスト名の「表示」にマウスカーソルを合わせるとホスト名を表示するようにした。クリックしちゃダメ。

これがまぁ驚いたことに6月8日の時点ではTLSv1.0を無効化しているところは1行も無い。それどころかいまだにSSL3.0を有効化しているのが2行、何をお考えなのかTLSv1.0だけを有効化しているのが1行というありさま。とりあえずこの3行のオンラインバンキングは滅べ。

TLSv1.1は本当は無効化が望ましいけどTLSv1.0を有効化している時点でもうどっちでも良い。でも、少なくともTLSv1.2は有効化しとけと言いたいのが百十四銀行。

採用している暗号スイートは銀行・オンラインバンキングを請け負ってる業者によってまちまちだけど、「普通」な設定(暗号強度の高いものを含み強度の高いものの優先順位を高くする)というのが意外と少なくて、弱い暗号スイートしか無いとか、強い暗号スイートが含まれるけど優先順位が弱い順なのでまず使われないというのが殆ど。これは銀行の変な横並び意識なのか金融庁の意味不明なご指導による賜物なのかは不明。
最初はIPAの「SSL/TLS暗号設定ガイドライン」のいうところの「セキュリティ例外型」にしてるのかと思ったけど、意味のある接続互換性優先でもなんでもなくて単に利用者全員が低い暗号強度で通信するようになってるだけなのよね。

で、接続互換性を大切にしてより多くの種類の端末・OS・ブラウザでオンラインバンキングを利用できるようにしているのかと思いきや、WindowsとIEを推奨とか、怪しいソフトウエアをインストールしないとダメ、その怪しいアプリはWindows専用だったり、酷いとWindows+IEでないとログインページに辿り着けないとか、どことはいわないけど山陰合同銀行とかもう何をしたいのか意味分かんない。
セキュリティ重視なら本来は強度が高く安全なプロトコル・暗号スイートを使える端末しか接続させるべきではなく、そういう方向で古いOS・ブラウザの切り捨てをすべき。

あと、銀行のサイトではフィッシング対策だとして怪しいアプリのインストールを推奨・強制するクセに、そして「フィッシング詐欺にお気をつけ下さい」「フィッシングサイトへの誘導にお気をつけ下さい」とさかんに警告するクセに、オンラインバンキングを利用しようとするとドメインが銀行のウェブサイトとは違う他所にあるところに案内も警告もなく移動させてログイン情報を入力させるのは、フィッシングサイトへの誘導と何ら変わらないんだけど銀行さんはどうお考えなのでしょうか。
ページを移動したらドメインが変わるというのに利用者が慣れてマヒするように仕向けてどうするよ?

Up