何故、SSL/TLS通信は安全なのか？ ～ TLS1.3 の仕組み ～

皆さん、こんにちは。技術開発グループのn-ozawanです。
2月3日は節分の日ですね。もともと節分は「季節を分ける」の意味で、立春、立夏、立秋、立冬の前日を指しており、年に4回あったそうです。

本題です。
前回はTLS1.2についてお話ししました。TLS1.2が発表されたのは2008年、TLS1.3の発表は2018年ですので10年もの歳月があります。TLS1.2から1.3で何が変わったのでしょうか？今回はTLS1.3の仕組みをお話しします。

TLS 1.3

TLS1.2との違い

TLS1.2と1.3の主な違いは、セキュリティ強度がより高い暗号方式を要求することと、ハンドシェイクシーケンスの大幅な見直しになります。他にもセッション再開に関する仕組みも変更されています。

TLS1.2では多くの暗号方式が利用可能でしたが、組み合わせやその運用によっては脆弱性となるリスクがあるため、TLS1.3では利用可能な暗号方式が限定されています。鍵共有に関してはDH鍵共有となり、RSAによる鍵共有は非対応となりました。また、暗号通信においても従来のCBCモードなどは非対応となり、GCMモードなどのAEAD（認証付き暗号）方式のみとなりました。

TLSハンドシェイク

ハンドシェイクのシーケンスがTLS1.2から大幅に変更されています。TLS1.3では３つのフェーズに分かれています。

第１フェーズでは利用する暗号方式の決定と鍵共有を同時に行います。TLS1.2では第１フェーズで利用する暗号方式を決定し、第２フェーズおよび第３フェーズで鍵共有を行いましたが、TLS1.3ではクライアントからサーバーへ利用可能な暗号方式の提示と同時に鍵共有も行います。

第２フェーズではサーバーからクライアントへ、TLSの拡張機能を送信します。この拡張機能はこれまでの暗号方式を決定するプロセスには影響しません。

第３フェーズではサーバーからクライアントへ、公開鍵証明書を提示します。クライアントは提示された公開鍵証明書が妥当かデジタル署名を検証します。クライアントはサーバーから求められれば、クライアント側の公開鍵証明書を提示します。

TLS1.2では公開鍵証明書に記述された公開鍵は、RSA鍵共有などに利用されていました。しかしTLS1.3ではDH鍵共有に置き換えられたため、公開鍵証明書に記述された公開鍵が使われることはなくなりました。公開鍵証明書の用途はなりすまし防止のみとなっています。

TLSレコード

TLS1.3では圧縮がなくなりました。また暗号方式もGCMモードなどのAEAD（認証付き暗号）方式のみとなりましたので、TLS1.2にあるようなMAC値を付与することもなくなりました。

おわりに

昨年、ChromeブラウザでSSL/TLS通信をしているサイトのアイコンが、南京錠から変更されたのをご存じでしょうか？変更された理由は「SSL/TLSで通信をしたからと言って、本当に安全とは言えないから」です。

SSL/TLSは相手との通信内容を暗号化し、第３者への漏洩を防ぎます。しかし、SSL/TLSは通信した相手が安全かどうかまでは保障してくれません。もしかしたら相手はフィッシング詐欺を働く業者かもしれませんし、簡単に第３者に情報を売るような悪徳業者かもしれないのです。

ここ十数年でSSL/TLSは広く普及し、SSL/TLSで暗号化していないサーバーを探す方が難しい時代となりました。誰もがSSL/TLSを利用して通信するようになった、そういった背景からChromeは「南京錠というアイコンが誤った安心を与えかねない」という懸念によりアイコンの変更に踏み切ったとのことです。

当ブログでは昨年の８月ごろから暗号技術に関する記事を投稿して、暗号技術が何故安全と言えるのかをお話してきました。しかし、暗号技術だけで全ての情報漏洩を防ぐことは出来ません。暗号技術に安心せず、常に情報漏洩をしないようにセキュリティ意識を高めて行動する必要があります。

ではまた。