#059
posted on 2021.11.07

SSL/TLSの基礎知識。

SSLの仕組みや用語の詳細がよく分からなかったので、SSL/TLSを設定するときに最低限必要な前提知識をまとめたメモ。

 

SSL(Secure Sockets Layer) : Webサーバーとクライアント間で暗号化通信を行うために作られたプロトコル。
TLS(Transport Layer Security) : SSLの次世代規格。

 

現在は「TLS」の規格が使用されているが、「SSL」が一般的な呼称として既に定着しているので、実質的に「TLS」の事であっても大抵は「SSL」という表現が使われている。(「SSL/TLS」の表記も多い。)

※ TLS1.2のブラウザ対応状況 Can I use。TLS1.3のブラウザ対応状況 Can I use

 

SSL通信によって保証されるのは以下の2点。

  1. サーバーの信頼性 (「サーバー証明書」で確認される。)
    「実際に接続されたサーバー」が「通信を傍受した第三者に経路改ざんされて接続されたサーバー」ではなく「ドメイン所有権者がドメインの接続先として設定しているサーバー」であることの保証。
  2. 通信の暗号化 (「公開鍵暗号方式」と「共通鍵暗号方式」が使用される。)
    クライアントとサーバー間の通信経路では送信内容が暗号化されていることの保証。

※ サイトのSSL化とは、悪意ある第三者からのリスクを回避するためのもので、サイト自体の安全性やその運営者の合法性などを保証するものではない。

※ サーバー側とクライアント側のそれぞれで、送信前に通信内容を暗号化、受信してから内容を複合する。(通信経路で内容を傍受されても暗号の状態なので情報漏洩のリスクが軽減される。)

SSLを開発していたNetscape社が、セキュリティー専門家を交えた第三者機関で開発するためにインターネット技術タスクフォース(IETF)に技術移管し、SSL3.0を基本設計にして開発されたTLS1.0が1999年にリリースされた。
2014年に「Heartbleed」と呼ばれるOpenSSL(業界標準としてSSL通信の運用に使用されるオープンソースのコマンドラインツール)の重大な脆弱性が発見されたため、SSL規格は2015年に使用が禁止され、現在は、より安全なTLS規格に完全に移行している。

 

 

SSL通信の仕組み

SSL通信は、「サーバー証明書」、「公開鍵」、「秘密鍵」、「ルート証明書」、「共通鍵」によって成り立つ。

 

SSL通信で使用されるもの

[ サーバー ]

「サーバー証明書」、「公開鍵」、「秘密鍵」を保持している。

[ クライアント ]

「ルート証明書」を保持している。(ブラウザや通信端末などに予めインストールされている。)

「共通鍵」は、サーバーの信頼性を確認できた場合にクライアント側で生成され、サーバーにも渡して共有される。

※ 「共通鍵」はセッションごとに生成され、通信を行っているクライアントとサーバーの両方が対応できる中で最も強度の高い暗号方式・鍵長が使用される。(「セッションキー」とも呼ばれる。)

 

ファイルのフォーマット

「証明書」や「鍵」に使用されるデータフォーマット。

  • データフォーマットには、公開鍵基盤の国際標準規格の「X.509」が使用されている。
  • 「証明書」は、使用されるフォーマットから「X.509証明書」とも呼ばれ、サーバーの証明のために作成された「X.509証明書」を「サーバー証明書」、認証局(CA:Certification Authority)の証明のために作成された「X.509証明書」を「CA証明書」と呼ぶ。
  • ファイルの形式には、バイナリデータの「DER形式」と、Base64エンコードでバイナリからASCII文字に変換された証明書や鍵のテキストデータに定形のヘッダーとフッター文を付加したテキストデータの「PEM形式」がある。
  • ファイルの形式や種類が分かるように拡張子には通常、「der」、「pem」、「crt」、「cer」、「key」が使用される。(中身の記述方法に決まりはあるがファイル名に決まりはない。)

 

公開鍵基盤(PKI : Public Key Infrastructure)

「公開鍵」と、その唯一のペアになる「秘密鍵」を利用した暗号化方式。

  • 「公開鍵」で暗号化されたデータは、ペアになっている「秘密鍵」でのみ複合できる。(「公開鍵」自身でも複合できない。)
  • 「秘密鍵」で暗号化されたデータは、ペアになっている「公開鍵」でのみ複合できる。(「秘密鍵」自身でも複合できない。)
  • 「公開鍵」は誰でも取得できるように公開する。(秘匿する必要は無い。)
  • 「秘密鍵」の秘匿が安全性の要点なので、漏洩しないよう厳格に管理する。
  • 「秘密鍵」を失くしてしまった場合、同一のものの再発行や再生成はできない。

※ 「秘密鍵」の保有者のみが「公開鍵」との暗号データのやりとりが可能な点が安全性の仕組みとなる。

※ この「公開鍵暗号方式」は、クライアントがサーバーに「共通鍵」を安全に受け渡す過程に使用され、「共通鍵」の共有以降の通信には「共通鍵暗号方式」が使用される。(「公開鍵暗号方式」は暗号化と複合に時間が掛かるため。)

※ アルゴリズムには、「RSA暗号」や「楕円曲線暗号」などが使われる。

RSA暗号

この方式の安全性は素因数分解の困難性に基づいている。
大きな素数 p, q が与えられたとき、その積 n = pq を計算することは容易である。しかし逆に、2つの大きな素数の積である自然数 n が与えられたとき、n = pq と素因数分解することは難しい。例えば n=21 のとき p=7, q=3 を求めるのは容易だが、鍵の大きさ(すなわち p, q のビット数)が十分に大きければ、素因数分解にはとてつもない時間が掛かる。
暗号化には n を、復号には p と q を必要とするようなうまい仕組みを作っておく。そして、n を公開鍵として公開する。傍受者は n から p, q を割り出そうとするが、これは時間が掛かりすぎて現実的でない。 (Wikipedia)

 

SSL通信の流れ

クライアントがサーバーに「共通鍵」を渡すまでの流れ。

(「共通鍵」を共有する過程を「ハンドシェイク」と呼ぶ。)

  1. クライアントが、サーバーにSSL通信での接続をリクエスト。(クライアント側が使用可能な暗号化仕様の情報も含める。)
  2. サーバーが、クライアントに「サーバー証明書」と「公開鍵」を送信。(この通信で使用する暗号化仕様も決定する。)
  3. クライアントが、受け取った「サーバー証明書」にある署名を「ルート証明書」で検証。(いま接続しているサーバーが第三者に経路改ざんされた接続先ではないことの証明。)
  4. クライアントが、「共通鍵」を生成。
  5. クライアントが、「生成した共通鍵の基となるデータ」を「公開鍵」で暗号化してサーバーに送信。
  6. サーバーが、受け取った「共通鍵の基となるデータ」を「秘密鍵」で複合し、「共通鍵」を生成。
  7. クライアントもサーバーも「共通鍵」を持った状態になるので、以降、このセッションでは、内容を暗号化し、それを「共通鍵」で複合する通信が可能になる。

※ クライアントが「サーバー証明書」を認証できない場合、接続は中止され、エラー通知が表示される。

 

 

サーバー証明書

「サーバー証明書」(Server Certificate)とは、ドメイン使用権の所有を証明する電子証明書で、「認証局」(認証を行う事業者)によって発行される。(「SSL証明書」、「エンドエンティティ証明書」などとも呼ばれる。)

 

申請者がOpenSSLなどのツールを利用して、申請者のサーバー上で「証明書署名要求」を作成して「認証局」に送信し、「認証局」が認証して電子署名することで「サーバー証明書」となり発行される。

一般的に「SSL証明書の購入」とは、「サーバー証明書」を「認証局」から発行してもらうことを指す。

※ ブラウザの鍵マークから、閲覧中のサイトに使われている「サーバー証明書」を発行した「認証局」を確認できる。

 

サーバー証明書の内容

「サーバー証明書」の主要な内容は下記。

  • サイト所有者の情報(サーバーの運営者の組織名など)
  • 公開鍵
  • 署名データ(証明書を発行した認証局事業者の名前などの情報)
  • 証明書の有効期限

※ 「署名データ」は、「発行した認証局の秘密鍵」によって暗号化されている。

※ この他に、X.509のバージョン情報、使用されているアルゴリズム、任意の情報を設定する拡張領域などが含まれている。

※ X.509 v3でのデジタル証明書の構造(Wikipedia)。

 

認証レベル

発行する際の審査基準により、「サーバー証明書」には3種類の認証レベルが存在する。

  • ドメイン認証型(DV: Domain Validation) : ドメイン使用権のみを確認。
  • 企業認証型(OV: Organization Validation) : ドメイン使用権と運営組織の法的実在性を確認。
  • EV(Extended Validation) : ドメイン使用権と運営組織の法的・物理的実在性を国際基準で確認。

※ 「ドメイン認証型」は、ドメイン使用権を所有していれば機械的な処理によって発行される。(個人でも取得できる。)

※ 「ドメイン認証型」以外は第三者機関による情報照会などの審査がある。(法人でなければ取得できない。)

※ 無償SSLとしてよく利用されている「Let’s Encrypt」は「ドメイン認証型サーバー証明書」。

 

証明書署名要求(CSR : Certificate Signing Request)

「証明書署名要求」(CSR : Certificate Signing Request)とは、「サーバー証明書」の発行を「認証局」に要求するために、申請者が該当のサーバー上から送信する申請書ファイルのこと。

  • 「CSR」は、OpenSSLなどを利用して、申請者がサーバー上で生成して送信するもの。
  • 申請者は、「CSR」を作成する前に、まず「公開鍵」と「秘密鍵」のペアを生成し、「秘密鍵」を秘匿する。
  • 「CSR」は暗号化されたテキストファイルで、認証に必要な申請者の識別情報や「申請者の公開鍵」などが記載されていて、「申請者の秘密鍵」で電子署名されて「認証局」に送信される。
  • 要求が成功する(認証される)と、「認証局」が「CSR」に「認証局の秘密鍵」で署名して「サーバー証明書」として返送する。

 

 

認証局

「認証局」(CA:Certification Authority)とは、「サーバー証明書」の登録、発行、失効をおこなう第三者認証機関のこと。

「ルート認証局」(root CA)と、「中間認証局」(intermediate CA)の2種類がある。

 

[ ルート認証局(root CA) ]

「ルート認証局」とは、厳しい監査に通過し、信頼の最上位にある「ルート認証局」として認められた認証局のこと。

  • 「ルート認証局」は、自分の正当性を自身で証明している「自己署名証明書」を保持している。
  • 「ルート認証局」は、「中間認証局」の信頼性を証明する「中間CA証明書」を発行する。

※ 規格のルールとして証明書には署名が必要なので、「ルート認証局」は自身のための「証明書」に自己署名する。

 

[ 中間認証局(intermediate CA) ]

「中間認証局」とは、「ルート認証局」(または自分より上位の「中間認証局」)から発行された「中間CA証明書」で自身を証明することで、「サーバー証明書」を発行する認証局のこと。

「中間認証局によるサーバー証明書の発行」とは、「中間CA証明書と、その公開鍵のペアである中間認証局の秘密鍵を使ってサーバー証明書に署名する」ことを指す。

 

トラストチェーン(信頼の連鎖)

「ルート証明書」が「中間CA証明書」を認証し、「中間CA証明書」が「サーバー証明書」を認証することで、信頼の起点である「ルート証明書」がドメインの正当性を保証している。これを「トラストチェーン」(信頼の連鎖)と呼ぶ。

SSL通信の際、クライアントでは、「サーバー証明書」の署名から「中間CA証明書」を遡ってトラストチェーンの起点となる「ルート証明書」を確認し、クライアントが保持する「ルート証明書」でその「ルート証明書」を検証する。

 

※ サーバーに「サーバー証明書」を設定する場合、「サーバー証明書」と、その「サーバー証明書」を認証している「中間CA証明書」を一緒に設定する必要がある。(「中間CA証明書」を認証している上位の「中間CA証明書」がある場合はすべて設定する必要がある。)

 

 

ルート証明書

「ルート証明書」(Root Certificate)とは、「ルート認証局」(信頼できる最上位の認証局)として登録されている「認証局」であることを証明するもの。(「CA証明書」、「ルートCA証明書」とも呼ばれる。)

  • クライアントが、SSL通信の際に「サーバー証明書」を発行している「認証局」の検証に使用する。
  • クライアント側での認証作業に必須なので、ブラウザや通信端末などのクライアントに予めインストールされている。
  • ブラウザベンダー、通信キャリア、家電機器メーカーなどが独自に「ルート認証局」の信頼性を審査して、「ルート証明書」をクライアントに組み込んでいる。
  • クライアントの所有者が、「ルート認証局」とし見做す「認証局」を自分で追加することもできる。
  • クライアントの「ルート証明書」が保存されている場所を「証明書ストア」、「ルートストア」、「ルートトラストストア」などと呼ぶ。
  • 有効期限は長いが、更新は必要。

※ ブラウザが独自に「ルート証明書」を保持している場合と、OSにインストールされている「ルート証明書」をブラウザが利用している場合とがあるので、同じOS環境内でもブラウザの違いでSSLサイトの閲覧可否が異なることがありえる。

※ 有効期限切れの「ルート証明書」では認証できないので、SSLサイトはエラーになって閲覧できない。

 

クライアントでの処理の流れ

「サーバー証明書」の発行元の「認証局」を「ルート証明書」で検証する処理の流れ。

  1. サーバーから「サーバー証明書」を受け取る。
  2. 受け取った「サーバー証明書」の「署名データ」を確認する。
  3. 「認証局の秘密鍵」によって暗号化されている「署名データ」を「認証局の公開鍵」で複合する。
  4. 署名のトラストチェーンを辿り、起点である「ルート認証局」を確認する。
  5. この「ルート認証局」を「ルート証明書」で検証する。
  6. 発行元の起点である「ルート認証局」が信頼できれば「サーバー証明書」も信頼できるので、現在接続しているサーバーも信頼される。

※ 「秘密鍵」で暗号化したデータは、ペアとなっている「公開鍵」でしか複合できないことを利用して「署名データ」が偽造されていないことを確認する。(「秘密鍵」の保有者しか暗号化できない。)

 

「ルート証明書」の更新

  • 登録されている認証局や暗号アルゴリズムの変更などがあるので、「ルート証明書」は定期的な更新が必要。
  • 適切に「ルート証明書」が更新されていないと、「サーバー証明書」の検証ができず、SSLサイトの閲覧ができない可能性がある。
  • ブラウザが独自に保有している場合は、ブラウザのバージョンアップで自動的に更新される。
  • OSが保有している場合は、OSのバージョンアップで自動的に更新される。
  • 「ルート証明書」の有効期限は、通信端末などのハードウェアのライフサイクルに紐付いているので、数年や十数年単位でかなり長い。

 

 

この記事をシェア
この記事のURL

https://memo.ag2works.tokyo/post-3104/

コピー
この記事のタイトル

SSL/TLSの基礎知識。 | memo メモ [AG2WORKS]

コピー
この記事のリンクタグ

<a href="https://memo.ag2works.tokyo/post-3104/" target="_blank" rel="noopener">SSL/TLSの基礎知識。 | memo メモ [AG2WORKS]</a>

コピー
※ フィールドをクリックでコピーするテキストの編集ができます。

この記事へのコメント

コメントの書き込みはまだありません。

  • コメント内のタグはエスケープ処理され、文字列として出力されます。
  • セキュリティーのため、投稿者のIPアドレスは取得されます。
  • 管理者が内容を不適切と判断したコメントは削除されます。
  • このフォームにはスパム対策として、Googleの提供するreCAPTCHAシステムが導入されています。
    (Google Privacy Policy and Terms of Service.)