OpenSSLのTLSv1.3正式対応が秒読みかという頃になってOpenSSLからLibreSSLに替えるなんていうととち狂ってるのかと思われるかもしれないが、すぐにTLSv1.3対応は要らないだろうと思われるFreeBSDホスト数台をOpenSSLより安全性が高く無駄な贅肉を落としたLibreSSLに替えてみた。いままで替えてなかったのがバカみたいなんだけど。
FreeBSDのportsではsecurity/opensslがOpenSSL 1.0.x系、security/openssl-develが1.1.0xとなっている。(2018年8月17日現在)
おそらく、TLSv1.3対応のOpenSSL 1.1.1が(正式に)リリースされたらsecurity/openssl-develがそれになるのかなと思っている。
現在はウェブサーバをChaCha20-Poly1305に対応させたいということでOpenSSL 1.1.0系であるsecurity/openssl-develを利用しているので、今後もOpenSSLを使い続ける予定のホストについてはsecurity/openssl-develにOpenSSL 1.1.1が来てくれるとTLSv1.3対応で苦労しなくても済むのかなという期待をしている。
しかし、FreeBSDのportsのsecurity/openssl-develは(というかOpenSSL 1.1.0系は)一部のアプリケーションと相性が悪くて自分でパッチ当てでもしなければ正常に動かない。
特に、意外とよく使うPythonのTLS系が全滅なので、それが非常に困る。パッチ無しで使おうと思ったら最悪security/opensslをインストールしているホストから/usr/local/lib/python2.7/site-packages以下から必要なファイルをコピーしてきて置き換えるという方法も使えるが、ゴマカシはあまりよろしくはないと思う。
LibreSSLのFreeBSD用portsはsecurity/libresslとsecurity/libressl-develで、2018年8月17日時点ではsecurity/libresslがLibreSSL 2.7.4、security/libressl-develがLibre2.8.0となっている。OpenSSL 1.1 API対応はLibreSSL 2.7系からなのでどちらでも良さそう。
security/libressl, security/libressl-develともに他のportsとの相性は目立って悪いということは無い様子。PythonのTLS関係も正常に動くっぽい。
そこで、今回はsecurity/libressl-develを採用。
インストール済みportsをLibreSSL対応に再ビルド
/etc/make.conf (変更)#DEFAULT_VERSIONS+=ssl=openssl-devel DEFAULT_VERSIONS+=ssl=libressl-devel #OPENSSL_PORT=security/openssl-devel OPENSSL_PORT=security/libressl-devel
# pkg update && portsnap fetch update && portsdb -uU パッケージ情報とportsツリーを最新状態に更新 # portupgrade -fo security/libressl-devel security/openssl-devel これでOpensslからLibreSSLに切り替え # portupgrade -fr libressl-devel LibreSSLとLibreSSLに依存するportsを更新
curlの再ビルド
おそらくcurlは再ビルドに失敗するはず。(インストールしていたらだけど)
/etc/make.conf (追記1行)ftp_curl_UNSET= TLS_SRP
# portupgrade -fr curl curlとcurlに依存するportsを更新
上のportsupgradeが失敗する場合は以下。
# rm -R /var/db/ports/ftp_curl # pkg delete curl ここでcurlに依存するportsも削除するメッセージが出るのでそのportsリストをメモる。 削除するにはy で同意する。 # cd /usr/ports/ftp/curl # make install ビルドオプションは基本的には変更無しで 同様に先ほど削除した他のportsをインストールする。
portsをアンインストールしても基本的には設定ファイルやデータは残っているので再インストール後もそのまま利用できる筈だが、どうしても心配ならアンインストール前にバックアップしておく。
Pythonとそのモジュールも強制再帰更新 portupgrade -fr hoge しておくのが無難かも。
必要なports更新が全部完了したら少なくともウェブサーバやメールサーバなどTLSに関係しそうなサービスを再起動する。面倒ならシステム再起動。
このときLibreSSLの依存関係を適切に満たさないままサービスを再起動しようとすると起動に失敗し、適切な再ビルド対応が終わるまで長時間のサービスのダウンタイム発生に繋がるのでports更新漏れや更新失敗が発生していないか目を光らせておく。
同じ理由で、ports更新前にサービスを停めてからports更新しようとすると大きなダウンタイム発生になるので更新し終わるまでサービスを停めない。
ただし、デーモンとして動くプログラムではなく、バッチ処理のスクリプト等や処理中にコマンドを呼び出して実行するプログラムがあって、その呼び出される側が更新対象に入っているなら呼び出す側を更新前に停めておく方が安全。(←とても迂闊な「がとらぼ」の中の人への言い聞かせ用)
