【図解】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 です。

関連記事

TLS バージョン 1.3 の概要、1.2 との違い 2018 年 8 月に TLS バージョン 1.3 が RFC 8446 として公開されました。1.2 が 2008 年に公開されましたので、実に 10 年ぶりの新バージョンです。 […]

ネットスケープ社の SSL の最終バージョン 3.0 も 2015 年、プロトコル自体に脆弱性が見つかりました

しかしその頃には TLS 1.0 ~ 1.2 はたいていの機器で標準実装されていたため、インターネット上の多くのサーバが 一斉に SSL 3.0 を無効化しはじめました。なので事実上 SSL はその役目を終え、TLS がその役目を引き継いでいます。

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

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 の暗号化通信が可能となります。

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

関連記事

前提 公開鍵暗号方式にはいくつか種類があります。この記事で出てくるのは『RSA』と『Diffie Hellman (DH) 鍵交換』の 2 つです。 RSA 公開鍵/秘密鍵でできること ~暗号化とデジタル署名~ まずは RSA の公開[…]

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

関連記事

TLS バージョン 1.3 の概要、1.2 との違い 2018 年 8 月に TLS バージョン 1.3 が RFC 8446 として公開されました。1.2 が 2008 年に公開されましたので、実に 10 年ぶりの新バージョンです。 […]

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 のシーケンス等詳細については以下を参照下さい。

関連記事

シナリオ 以下のシナリオで L2 認証スイッチでの IEEE802.1x 認証 (PEAP) の動作例を示します。 RedHat Enterprise Linux で FreeRadius、OpenLDAP のサービス 2 つを[…]

TLS の認証の仕組み

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

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

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

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

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

関連記事

前提知識 デジタル証明書 (電子証明書) の理解のためにはまず RSA 公開鍵・秘密鍵について知る必要があります。 簡単に言うと以下がポイントになります。 公開鍵で暗号化すると、秘密鍵でしか復号できない (公開鍵では復号で[…]

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

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

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

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

関連記事

TLSにおけるクライアント認証とは TLSの規格としては、サーバの認証は必須ですが、クライアントの認証はオプション扱いとなっています。サーバの設定によっては、クライアント証明書による認証を強制させることができます。 以下の図の左側は[…]

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



IT/インフラエンジニアの地位とスキル向上のために

関連記事

IT 技術の進化はとどまることを知りません。矢継ぎ早に新たな技術が出てきたり、数年前の技術が時代遅れになったりと、IT エンジニアは勉強し続ける運命のようです。 それをどう思うかはあなた次第。 ビジネスの基本は『付加価値を与える[…]

IMG
関連記事

nesuke の考える NW エンジニアの2つの道 ネットワークエンジニアには 2 つの道があります。 1 つはネットワーク構築一筋で、L4 までをひたすらきっちりと構築していく道。 もう 1 つはネットワークを軸として深堀し[…]

IMG