WEB+DB Press vol.110 の特集3 をベースに、サーバサイドエンジニアが知っておいて損のない TLS 1.3 についてまとめます。
TLS 1.3 は重大な脆弱性が発見されない限り息の長いプロトコルになりそうなので、今からトラックしておくのがおすすめです。
要約
変わること
- 安全ではないアルゴリズムは使えなくなる(MD5, SHA1, ...)
- 初回通信時のパフォーマンスが向上する(往復回数の削減)
- HTTP/3(QUIC) でも使われるようになる予定
- = 息の長いプロトコルになりそう
- IoT などを意識したパフォーマンスが考えられている(ARM 最適化など)
- 来年くらいには TLS 1.3 でサーブすることを考え出してもいいかも(今はまだブラウザサポートが微妙)
- TLS 1.1 の(ブラウザ)サポートが 2020 年内に終了予定
- TLS 1.0 はもうサポート終了しているはず
変わらないこと
- TCP プロトコル以下
- HTTP プロトコル以上(TLS に乗っているだけなので)
- TLS 1.2(当分は 1.2 のサポートはある)
背景
- Web 界隈は
https = 暗号化通信をスタンダードとするようになってきた- Google の検索ランクに影響
- ブラウザで非暗号化通信時に警告するように
- https じゃないと使えない Web API の増加
- 現在暗号化通信は TLS 1.0, 1.1, 1.2 が主流
- SSL は TLS の前に使われていた技術の名前(3.0 まであったが、脆弱性があるのでもう使われていない)
- SSL/TLS は改善されてきたが、同時に負の遺産も作られてきた
- 4 年の議論で負の遺産を回収した「良い感じの TLS」として 1.3 が 2018/08 に RFC 8446 として策定された
暗号化アルゴリズムの選別
MD5 や SHA-1 など、暗号化レベルの低い(ハックされやすい)アルゴリズムは全てなくなり、 TLS 1.2 で追加された AEAD 一種類のみになりました。
↑現在はサーバサイドの設定で MD5 を使わない、などの対策が必要な状態です。 TLS 1.3 のみのサーバであれば対策不要になります。
完全な前方秘匿性
完全な前方秘匿性(Perfect Forward Secrecy) が必須になりました。
これは、暗号化された通信データを保存しておいても、後から復号化出来ないようにする仕組みです(具体的には、セッションごとに必要な情報を破棄して、後からそれらの情報を取得出来ないようにする)。
プロトコル自体の改良
TLS のプロトコルは、最初に HandShake と呼ばれる鍵交換や認証などを行います。そのため、通信が確立するまでに複数(2~3)回の通信をする必要がありました。
TLS 1.3 では 1 往復で通信を開始出来るようになり、セッション再開時は最短 0 往復で、最初の通信からデータを送受信できるようになります。つまり、待ち時間が削減されパフォーマンスが向上するという話です。
IoT など、通信遅延が大きくなる場所において特に効果を発揮します。
2020 年 TLS 1.1 サポート終了
ブラウザベンダー各社は 2020 年中に TLS 1.0, 1.1 のサポートを終了することを表明しています。今後は TLS 1.2 及び 1.3 を使うことになります。
TLS 1.3 対応状況
多くの環境で TLS 実装として利用されている OpenSSL は、 v1.1.1 から TLS 1.3 を利用出来ます。
Apache は 2.4.37 から、 nginx は 1.15.6 から OpenSSL 1.1.1 を採用しているため、利用出来ます。
クライアントとして、ブラウザは iOS Safari 12.2 から、 Chrome 70, Firefox 63 からサポートされているので、最新環境では使えるようになり始めています。実際にプロダクションで使うにはまだ少し早いですね。
HTTP/3 と TLS 1.3
UDP プロトコルベースになる HTTP/3(QUIC) は、通信暗号化機能として TLS1.3 を利用します。今後 TLS1.3 に重大な脆弱性が発見されない限りは、息の長いプロトコルバージョンになること間違いなしです。
量子コンピュータ
量子コンピュータの登場により、現在使われているアルゴリズムが解読可能になってしまうという危険性も示唆されています。 2026 年頃に量子コンピュータの計算にも耐えられるアルゴリズムを標準化する計画もあるようです。