【図解】SSL/TLSの概要 〜シーケンスや応用プロトコル,デジタル証明書について〜

SSL/TLS とは

SSL/TLS とは、様々なアプリケーションレイヤ通信 (代表的なものは http ) の認証および暗号化を行うプロトコルです。 OSI 参照モデルでは第 5 層のセッション層に当たりますが、IP セットモデルでは TCP と同じくトランスポート層になります。 (TCP の上位で動作しますが、PPPoE のように同レイヤプロトコルの組み合わせとなります)

TLS はもともとネットスケープ社の開発した SSL がベースになっており、1999年、IETF により TLS バージョン 1.0 が RFC2246 で 標準化されました。

2019年での最新バージョンは TLS バージョン 1.3 です。

【図解】TLSv1.3の仕組みとシーケンス ~QUICに向けた0-RTT, key_shareやHelloRetryRequest, NewSessionTicketとPSKの関係, コネクションとセッションの違い~
【図解】TLSv1.3の仕組みとシーケンス ~QUICに向けた0-RTT, key_shareやHelloRetryRequest, NewSessionTicketとPSKの関係, コネクションとセッションの違い~
TLS バージョン 1.3 の概要、1.2 との違い 2018年8月に TLS ...

ネットスケープ社の SSL の最終バージョン 3.0 も 2015 年、プロトコル自体に脆弱性が見つかりました。 しかしその頃には TLS 1.0 ~ 1.2 はたいていの機器で標準実装されていたため、インターネット上の多くのサーバが 一斉に SSL 3.0 を無効化しはじめました。なので事実上 SSL はその役目を終え、TLS がその役目を引き継いでいます

しかしながら、「SSL 証明書」や「SSL アクセラレータ」、「SSL-VPN」、「SSL可視化」など、実際には TLS を 使っている場合でも、慣例的に SSL と呼ぶことがあります (2019年現在ではむしろ多いです)。

TLS のシーケンス

https を例に、TLS のシーケンスを以下に示します。

まずは認証/暗号アルゴリズムのネゴシエーションを行います。Client Hello にてクライアント側が対応している認証/暗号アルゴリズムのリストを提示し、Server Hello によりその中でサーバ側が採択したものをクライアントへ提示します。

次に認証を行います。サーバからの Certificate にて『デジタル証明書の署名によるサーバの認証』が行われます。オプションで、クライアントへ『クライアント証明書の提示』を要求し、クライアントの認証を行うこともできます。

最後に Client/Server Key Exchange (TLS v1.3 以降は key_share Extension) により Diffie-Hellman アルゴリズムによる共通鍵交換を行います。

以前は共通鍵の素を、デジタル証明書の公開鍵で暗号化してサーバへ送付する方式も使われていましたが、スノーデン氏による国家レベルの盗聴告発を期に、前方秘匿性のある DHE や ECDHE の利用が当たり前になりました。そして TLS v1.3 においては公開鍵による共通鍵の素の提示は禁止されました。

このハンドシェイク完了後に http の暗号化通信が可能となります。

公開鍵・秘密鍵については以下を参照下さい。

【図解】初心者も分かる"公開鍵/秘密鍵"の仕組み~公開鍵暗号方式の身近で具体的な利用例やメリット〜
【図解】初心者も分かる"公開鍵/秘密鍵"の仕組み~公開鍵暗号方式の身近で具体的な利用例やメリット〜
公開鍵・秘密鍵でできること ~暗号化とデジタル署名~ 特定のサーバ A が秘密...

なお、2018年8月に公開された TLS v1.3 の v1.2 からの変更点などについては以下を参照してください。

【図解】TLSv1.3の仕組みとシーケンス ~QUICに向けた0-RTT, key_shareやHelloRetryRequest, NewSessionTicketとPSKの関係, コネクションとセッションの違い~
【図解】TLSv1.3の仕組みとシーケンス ~QUICに向けた0-RTT, key_shareやHelloRetryRequest, NewSessionTicketとPSKの関係, コネクションとセッションの違い~
TLS バージョン 1.3 の概要、1.2 との違い 2018年8月に TLS ...

TLS の応用プロトコル

TLS で一番有名な実装は『https』でしょう。これは TCP 3way handshake 直後から TCP FIN や RST の直前までの http 通信を全て暗号化します。このようなプロトコルは他にも以下のものがあります。

POP3s, IMAP4s, LDAPs, SMTPs, FTPs

また、TCP の途中から暗号化するものについては以下のものがあります。

STARTTLS (SMTP)

SMTPs が通信の最初から最後までを TLS で暗号化するのに対し、STARTTLS では送信するメールのヘッダ及び本文のみを暗号化します。(HELO 等の制御系通信は暗号化しない)

また、FTPs と似たプロトコルで sFTP というものもありますが、これは FTP を ssh で暗号化したものになります。

また、TCP の上位ではなくEthernetという下位層の上に載るケースもあります。例えば IEEE802.1x が有名です。

IEEE802.1x

クライアントと RADIUS サーバ間の認証・認可通信を暗号化します。なお、間に認証スイッチ (Authenticator) が入りますが、このスイッチは EAP メッセージを EAPoL から Radius に乗せ替えるだけで、EAP メッセージ自体はノータッチです。

よくある誤解として、『PEAP を使う場合はデジタル証明書は不要だ』と言う人もいますが、クライアント証明書としてのデジタル証明書は不要ですが、Radius サーバにはサーバ証明書としてのデジタル証明書が必要です。

IEEE802.1x のシーケンス等詳細については以下を参照下さい。

【図解】IEEE802.1x認証の仕組みとシーケンス 〜認証スイッチ+FreeRadius(+証明書)+OpenLDAPの例〜
【図解】IEEE802.1x認証の仕組みとシーケンス 〜認証スイッチ+FreeRadius(+証明書)+OpenLDAPの例〜
シナリオ 以下のシナリオで L2 認証スイッチでの IEEE802.1x 認証...

TLS の認証の仕組み

TLS の認証は基本は ITU-T 勧告の X.509 デジタル証明書バージョン 3 が使われます。

単に認証といっても、1つの TLS 通信の中に以下の 2 つの認証が行われます。

  1. クライアントがサーバを認証(サーバが偽者ではないかどうかを確認)する
  2. サーバがクライアントを認証(クライアントが偽者ではないかどうかを確認)する

1 の認証についてはサーバにデジタル証明書(サーバ証明書。このことをよく"SSL証明書"と呼びます)をインストール、 2 の認証についてはクライアントにデジタル証明書(クライアント証明書)をインストールする必要があります。

デジタル証明書の詳細についてはこちらをご参照下さい。

【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜
【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜
前提知識 デジタル証明書(電子証明書)の理解のためにはまず公開鍵・秘密鍵につい...

ただし、証明書を使った認証はどちらも必須ではありません。サーバの認証は PSK (Pre-shared Key) で行うこともできますし、クライアントの認証はそもそも省略されることが多いです。

実装として多い https においては、TLS でのクライアント認証は (セキュリティを堅牢にする必要がある場合を除き)ほとんど行われません。例えば https://www.google.co.jp もクライアント証明書は不要でアクセスできます。

たいていはサーバ証明書だけをインストールし、サーバが正しいことを保証し、もしクライアント側が 正規なユーザかどうかを確認する場合は Web 画面の最初にログイン画面を設け、そこでクライアント認証(ユーザ認証)を行うことが多いです

クライアント証明書の詳細については下記を参照下さい。

【図解】クライアント証明書の仕組み~シーケンス、クライアント認証、メリット 〜
【図解】クライアント証明書の仕組み~シーケンス、クライアント認証、メリット 〜
TLSにおけるクライアント認証とは TLSの規格としては、サーバの認証は必須で...

サーバ証明書の例として https://www.google.co.jp の証明書を見てみます。