SSL と TLS の違い
SSL と TLS とは、様々なアプリケーションレイヤ通信 (代表的なものは http) の認証および暗号化/改竄防止を行うプロトコルです。
SSL は TLS の前身となったプロトコルであり、現在使われているのは TLS の方ですが、名前としては SSL が定着しているため、「SSL/TLS」と表現されることも多いです。
SSL/TLS では「(主にサーバの) 認証」「鍵交換」「通信暗号化」「通信の改竄防止」が行われてます。「認証」と「鍵交換」は SSL/TLS ネゴシエーション時に行います。
TLS は保護対象のプロトコルを選びませんが、http を SSL/TLS で保護した https は、現在のインターネット上のセキュリティの根幹を担っており、ショッピングやクレジットカード決済などは、この SSL/TLS 技術の安全性を根拠に行われています。
OSI 参照モデルでは第 5 層のセッション層に当たりますが、IP セットモデルでは TCP と同じくトランスポート層になります。(TCP の上位で動作しますが、PPPoE のように同レイヤプロトコルの組み合わせとなります)
TLS はもともとネットスケープ社の開発した SSL がベースになっており、1999 年、IETF により TLS バージョン 1.0 が RFC2246 で 標準化されました。
2021 年での最新バージョンは TLS バージョン 1.3 です。
ネットスケープ社の SSL の最終バージョン 3.0 も 2015 年、プロトコル自体に脆弱性が見つかりました。
しかしその頃には TLS 1.0 ～ 1.2 はたいていの機器で標準実装されていたため、インターネット上の多くのサーバが 一斉に SSL 3.0 を無効化しはじめました。なので事実上 SSL はその役目を終え、TLS がその役目を引き継いでいます。
しかしながら、「SSL 証明書」や「SSL アクセラレータ」、「SSL-VPN」、「SSL可視化」など、実際には TLS を 使っている場合でも、慣例的に SSL と呼ぶことがあります (2021 年現在でもまだ根強く使われています)。
| SSL | TLS | |
|---|---|---|
| Ver1.0の策定 | 1994年 | 1999年 |
| 開発組織 | ネットスケープ社 | IETF (RFC) |
| バージョン (2020.9現在) | (1.0は開発中に欠陥が見つかり欠番) 2.0 = 1994年 3.0 = 1995年 (以降は TLS へ継承) | 1.0 = 1999年 (RFC2246) 1.1 = 2006年 (RFC4346) 1.2 = 2008年 (RFC5246) 1.3 = 2018年 (RFC8446) |
| 特徴 | SSLは脆弱性があるためまず実装されていない。実際に使われているのはTLS だが、 技術を表す用語としては (なぜか) TLS よりも SSL が根強く使われている。 例)SSL証明書, SSLアクセラレータ, SSL-VPN, SSL可視化, 常時SSL化, 等 | |
TLS のシーケンス (公開鍵暗号と共通鍵暗号のハイブリッド)
https を例に、TLS のシーケンスを以下に示します。
まずは認証/暗号アルゴリズムのネゴシエーションを行います。Client Hello にてクライアント側が対応している認証/暗号アルゴリズムのリストを提示し、Server Hello によりその中でサーバ側が採択したものをクライアントへ提示します。
次に認証を行います。サーバからの Certificate にて『デジタル証明書の署名によるサーバの認証』が行われます。オプションで、クライアントへ『クライアント証明書の提示』を要求し、クライアントの認証を行うこともできます。
最後に Client/Server Key Exchange (TLS v1.3 以降は key_share Extension) により Diffie-Hellman アルゴリズムによる共通鍵交換を行います。
このハンドシェイク完了後に http の暗号化通信が可能となります。
公開鍵・秘密鍵については以下を参照下さい。
なお、2018年8月に公開された TLS v1.3 の v1.2 からの変更点などについては以下を参照してください。
TLS の応用プロトコル
TLS で一番有名な実装は『https』でしょう。
これは TCP 3way handshake 直後から TCP FIN や RST の直前までの http 通信を全て暗号化します。このようなプロトコルは他にも以下のものがあります。
また、TCP の途中から暗号化するものについては以下のものがあります。
SMTPS と STARTTLS の違い
SMTPs が通信の最初から最後までを TLS で暗号化するのに対し、STARTTLS では送信するメールのヘッダ及び本文のみを暗号化します。(HELO 等の制御系通信は暗号化しない)
STARTTLS は RFC3207 にて定義されています。
以下に SMTPs と STARTTLS のシーケンスの違いを示します。
また、FTPs と似たプロトコルで sFTP というものもありますが、これは FTP を ssh で暗号化したものになります。
また、TCP の上位ではなくEthernetという下位層の上に載るケースもあります。例えば IEEE802.1x が有名です。
IEEE802.1x
クライアントと RADIUS サーバ間の認証・認可通信を暗号化します。なお、間に認証スイッチ (Authenticator) が入りますが、このスイッチは EAP メッセージを EAPoL から Radius に乗せ替えるだけで、EAP メッセージ自体はノータッチです。
よくある誤解として、『PEAP を使う場合はデジタル証明書は不要だ』と言うものがありますが、クライアント証明書としてのデジタル証明書は不要ですが、Radius サーバにはサーバ証明書としてのデジタル証明書が必要です。
IEEE802.1x のシーケンス等詳細については以下を参照下さい。
TLS の認証の仕組み
TLS の認証は基本は ITU-T 勧告の X.509 デジタル証明書バージョン 3 が使われます。
単に認証といっても、1 つの TLS 通信の中に以下の 2 つの認証が行われます。
- クライアントがサーバを認証 (サーバが偽者ではないかどうかを確認) する
- サーバがクライアントを認証 (クライアントが偽者ではないかどうかを確認) する
1 の認証についてはサーバにデジタル証明書 (サーバ証明書。このことをよく"SSL 証明書"と呼びます) をインストール、2 の認証についてはクライアントにデジタル証明書 (クライアント証明書) をインストールする必要があります。
デジタル証明書の詳細についてはこちらをご参照下さい。
ただし、証明書を使った認証はどちらも必須ではありません。サーバの認証は PSK (Pre-shared Key) で行うこともできますし、クライアントの認証はそもそも省略されることが多いです。
実装として多い https においては、TLS でのクライアント認証は (セキュリティを堅牢にする必要がある場合を除き)ほとんど行われません。例えば https://www.google.co.jp もクライアント証明書は不要でアクセスできます。
たいていはサーバ証明書だけをインストールし、サーバが正しいことを保証し、もしクライアント側が 正規なユーザかどうかを確認する場合は Web 画面の最初にログイン画面を設け、そこでクライアント認証 (ユーザ認証) を行うことが多いです。
クライアント証明書の詳細については下記を参照下さい。
サーバ証明書の例として https://www.google.co.jp の証明書を見てみます。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント