Transport Layer Securityとは？

TLS規約は、ビジネスやウェブアプリにとってどんな意味があるのか？

TLS接続の確立には複雑なプロセスが必要となるため、一定の時間と計算リソースが消費されます。クライアントとサーバは、データを送受信する前に何度も通信する必要があり、その結果、ウェブアプリでは大きな遅延が発生し、両者に負荷がかかります。

とはいえ、TLSハンドシェイクによる遅延を調整するための改善策がいくつか提案されています。ひとつは TLS False Start で、サーバとクライアントがハンドシェイク完了前にデータ送信を開始できるものです。もうひとつは TLS Session Resumption で、すでに接続済みのクライアントとサーバが簡略化されたハンドシェイクを用いることを可能にします。

‍

TLSの歴史

TLSは、Netscape Communications Corpの Secure Sockets Layer (SSL) プロトコルから発展し、以降SSLに取って代わりました。ただし、SSLやSSL/TLSという用語が使われることもあります。IETFは、オープンな標準化のためにSSLの管理権を引き継ぎ、1999年に SSL 3.1 を TLS 1.0 として改定しました。このプロトコルは、Netscapeが自社のウェブアプリでSSLを中核に据えていたことから距離を置くために改名されたのです。

プロトコルの仕様によれば、TLSは TLS レコードプロトコルと TLS ハンドシェイクプロトコルの2層から構成されています。レコードプロトコルは通信の安全性を確保し、ハンドシェイクプロトコルはサーバとクライアントが互いに確認し、暗号アルゴリズムや鍵について合意するためのものです。

最新のTLSバージョンである1.3は、2018年にIETFによって正式に確定されました。従来のバージョンに比べ、TLS 1.3は暗号化機能が向上し、クライアントとサーバ間のハンドシェイクがより速くなるという大きな利点があります。従来のTLSも暗号化を行っていましたが、TLS 1.3はハンドシェイクの早い段階から接続を暗号化する仕組みを採用しています。

また、ハンドシェイクを完了するための手順が減少し、クライアントとサーバ間でデータの送受信を開始するまでの時間が大幅に短縮されています。

TLSはどのように機能するのか？

安全にデータを送受信する際、TLSは対称暗号と非対称暗号を組み合わせ、性能と安全性のバランスを実現しています。

データは、送信者と受信者が共有する秘密鍵を用いた対称暗号で暗号化・復号化されます。通常は128ビット、理想的には256ビットが使用され、80ビット未満は弱いとされています。

対称暗号は高速ですが、秘密鍵の適切な管理が必要です。

非対称暗号では、公開鍵と秘密鍵のペアが用いられます。公開鍵は秘密鍵と数学的に関連付けられていますが、十分な鍵長があれば公開鍵から秘密鍵を導き出すことは現実的ではありません。これにより、送信者は受信者の公開鍵を使ってデータを暗号化し、受信者は秘密鍵で復号化します。

公開鍵と秘密鍵の数学的な関連から、より大きな鍵サイズが必要になりますが、非対称暗号の利点は、暗号鍵の交換手順自体を厳重に守る必要がない点にあります。推奨される最低鍵長は1024ビットですが、2048ビットが望ましく、2048ビットの非対称鍵は同程度の強度の対称鍵（例: 112ビット）と比べて計算負荷が高く、特定の用途では非対称暗号の処理が遅くなることもあります。

その後、TLSは非対称暗号を用いてセッション鍵を安全に交換します。セッション鍵は、各パーティがデータを暗号化・復号するために使用され、セッション終了後は破棄されます。

また、TLSではクライアントがサーバの公開鍵を確認することも重要です。通常、認証局（CA）によって発行されるX.509デジタル証明書が利用され、公開鍵の真正性が保証されます。

ブラウザが自署証明書を使用する場合、クライアントが明示的に信頼する必要があります（未承認の証明書が使用された場合、警告が表示されるべきです）。プライベートネットワークや安全な証明書管理が可能な場合には許容されることもありますが、広く信頼されたCAによる証明書を利用することが強く推奨されます。

暗号化:

データは、クライアントとサーバ間で送受信される際に暗号化され、不正な第三者による傍受や解読から守られます。

認証:

認証により、通信の双方が相手の真正性を確認できます。

完全性:

TLSは、暗号化、送信、復号の各段階でデータが失われたり、損なわれたり、改ざんされたりしないことを保証します。

TLSのメリット

TLSを利用するか否かで、その利点は明らかです。前述の通り、TLSベースの通信は安全な認証基盤、データ暗号化、そしてデータ完全性の検証を実現します。また、他の認証・暗号化プロトコル、例えばIPsecと比べても、TLSには追加のメリットがあり、多くの企業でIPsecからTLSへ移行が進んでいる理由となっています。

• セキュリティが各アプリに組み込まれているため、IPsecトンネルを構築する外部のソフトウェアやハードウェアが不要です。
• 送信機器間で端から端までしっかりとした暗号化（E2EE）が実現されています。
• ネットワーク上で送受信できるデータを細かく制御できます。
• TLSはOSI参照モデルの上位層で動作するため、IPsecに固有のNAT（接続アドレス変換）の問題が発生しません。
• プロトコルに組み込まれたログ記録や監視機能を備えています。

TLS 1.2 対 TLS 1.3

1999年1月に定義されて以来、Transport Layer Securityは幾度もの改訂を経ています。最新バージョンのTLS 1.3は2018年8月に導入され、TLS 1.2と1.3の違いは、性能と安全性の双方で大きく改善が図られている点にあります。しかし、既知の脆弱性がないことや大規模な企業用途に適しているため、TLS 1.2は今なお広く利用されています。TLS 1.3へのアップグレード時期や必要性は、組織ごとに検討事項となるでしょう。

TLS 1.3は、特に高速なハンドシェイクや、よりシンプルで安全な暗号スイートといった改善をもたらします。Zero Round-Trip Time (0-RTT) の鍵交換により、ハンドシェイクはさらにスムーズになります。これらの変更により、性能の向上と堅牢な安全性が実現されます。

1. 高速なTLSハンドシェイク

TLSでの暗号化やSSLの復号はCPUの処理時間を要し、ネットワーク通信に遅延を発生させ、パフォーマンスに影響を与えていました。TLS 1.2では初期ハンドシェイクが平文で行われたため、暗号化と復号の処理が重なり、クライアントとサーバ間で5～7個のパケットがやり取りされることから、相当な負荷がかかっていました。TLS 1.3では、サーバ側の暗号化が標準搭載され、0～3個のパケットでハンドシェイクを完了できるため、この負荷が大幅に軽減され、より迅速で反応性の高い通信が可能となります。

2. 簡素で強力な暗号スイート

TLSハンドシェイクでのパケット数削減と同様に、バージョン1.3では暗号化に用いる暗号スイート自体も簡素化されています。TLS 1.2以前では、暗号的に弱い暗号の使用が安全性のリスクとなる場合がありました。TLS 1.3は、既知の脆弱性がないアルゴリズムのみをサポートし、Perfect Forward Secrecy (PFS) を提供しないものは排除しています。

また、既存のTLS接続で新たなパラメータや鍵を交換する「再交渉」機能も廃止され、安全性のリスクが減少しました。

3. Zero Round-Trip Time (0-RTT)

TLSはSSLと同様、鍵交換により安全な接続を確立します。当初、ハンドシェイク中は静的RSA鍵またはDiffie-Hellman鍵のいずれかで交換が行われていましたが、TLS 1.3ではRSAおよび静的（PFS非対応）鍵交換が廃止され、エフェメラルなDiffie-Hellman鍵のみが使用されます。これにより、静的鍵に伴うリスクが排除され、Diffie-Hellman方式のみを利用することで、クライアントは「hello」メッセージ内で鍵生成に必要なランダム値などを送信できるようになりました。

これによりハンドシェイクの往復が不要となり、時間が節約され、全体的なサイトのパフォーマンスが向上します。さらに、以前接続したサイトにアクセスする際には、前回の接続で得た事前共有鍵 (PSK) を用いて初期メッセージをサーバに送信する、いわゆる「0-RTT」が実現されます。

TLS 対 SSL

その前身である Secure Sockets Layer (SSL) もまた、HTTPを拡張してウェブ通信の安全性を高め、データ送受信時に暗号化やSSL復号を可能にする暗号プロトコルです。実際、TLSはSSLの直後を継ぎ、旧プロトコルの多くの安全上の問題に対応しています。両者の違いは微妙で、TLSでは改良された暗号計算や異なるポートでの動作が可能となっています。用語はしばしば混同されますが、現在ではSSLはすべて非推奨となっており、ほとんどの最新システムではサポートされていません。

知識 - SSLとは何か?

TLS規約に対する弱点と攻撃

TLS暗号化実装には性能面の問題が常に懸念されており、TLSも例外ではありません。一般的に非常に安全とされるTLSですが、脆弱性が発見され悪用された事例も存在します。

ただし、以下に挙げる脆弱性はTLS 1.2以前のものであり、BEAST、CRIME、及びプロトコル制限攻撃など、従来のTLSに存在した既知の脆弱性はバージョンアップにより解消されています。大規模な攻撃や侵入事例としては、次のようなものがあります：

• 悪名高い Heartbleed バグは、OpenSSLがTLSハートビート機能を実装する際に発生した些細なバグが原因で、この機能はデータが送受信されていなくとも接続を維持するために用いられます。
• TLSは全てのパディングバイトが同一で検証されるためPOODLE攻撃には脆弱ではありませんが、一部の実装において暗号パディングの規定が厳格に適用されない場合、その点を突かれることがあります。
• 2011年に発見された BEAST 攻撃は、TLS 1.0に影響を与え、プロトコルのCBC（ブロック暗号連鎖）部分の脆弱性を標的として、通信中のデータの傍受と復号を可能にしました。
• TLSに内蔵されたデータ圧縮機能が原因でCRIMEと呼ばれる脆弱性が発生し、ブルートフォース攻撃によりセッション内の通信が突破され、攻撃者が暗号化された通信に介入する可能性があります。
• また、HTTP圧縮を標的とする BREACH 脆弱性も、CRIME同様に圧縮機能を悪用する攻撃ですが、TLS圧縮ではなくHTTP圧縮が対象となる点が異なります。それでも、TLS圧縮が無効の場合でも攻撃の可能性は残ります。