読者です 読者をやめる 読者になる 読者になる

SanshouSichimiYa

備忘録の為のブログ

SSLの基本の報告

図解で学ぶネットワークの基礎: SSL編を読んだ内容を書き留めます。

SSL通信

webブラウザのステータスバーに錠前マークが出ているとSSL通信をしている。

また、アドレスがhttps://...というURLだった場合にもSSL通信をしている状態。

機能と位置付け

機能は大きくわけて2つ

  • データの暗号化
  • 通信相手が信頼できることの確認(認証)

データの暗号化と信頼の確認

SSLはインターネット上でやり取りするデータの暗号化を行う。

個人情報やクレジットカードの情報などをインターネットでやり取りする際に、データが見られてしまってもわからなくするように暗号化をして途中で盗み見られる事を防止している。

サーバー証明書」を利用しての信頼性の確認

データを送るサーバーが信頼できるかどうかをクライアントがサーバーから「サーバー証明書」を受け取り、検証をすることによって信頼できるかどうかの判断ができる。

SSLの通信全体から見た立ち位置

SSLはWebブラウザとTCPの間に位置する。

通信の流れは以下のようになる。

  1. Webブラウザがhttps://...宛のサーバーにデータを送る
  2. WebブラウザはTCPでは無くSSLにデータを渡す
  3. SSLはブラウザから受け取ったデータを暗号化してTCPへ渡す
  4. 暗号化データを受け取ったTCPはパケットに443port宛と明記する
  5. このデータがIP、イーサネットとわたって回線上に送り出される

※受信時は送信時の流れとは逆になる

SSLの概要

共通鍵暗号」「公開鍵暗号

SSLは「共通鍵暗号」と「公開鍵暗号」の2つの暗号方式を使う

共通鍵暗号」方式

  • 暗号化と復号に同じ鍵を使う
  • 暗号化と復号の処理が軽い
  • 送信側と受信側があらかじめ同じ鍵をもっていなければならない
  • 通信相手を特定していないインターネット通信で同じ鍵を事前に持つことが不可能
  • 鍵をやりとりする際に盗まれる可能性がある

公開鍵暗号」方式

  • 公開鍵と秘密鍵のペアの鍵を使う
  • 片方の鍵で暗号化したデータは、ペアの鍵でしか復号できない
  • 片方の鍵をインターネットで公開してももう片方の鍵を秘密にしておけば安全にデータを送れる

公開鍵暗号」で「共通鍵」を安全におくる

ふたつを組み合わせた通信のやりとりがSSL通信の概要である。

  1. クライアントがサーバーにSSL通信の要求を送る
  2. サーバーは自身の公開鍵が入った証明書をクライアントに返信
  3. クライアントはサーバーの公開鍵を使って共通鍵を暗号化してサーバーに送る
  4. 共通鍵を使ってクライアントとサーバーは本来の目的であるデータの暗号化/復号を高速・軽量に処理できるようになる

SSLの全貌

2つの仕様で構成

SSLで運ぶメッセージはレコードと呼ばれている。

  • レコード・プロトコル :メッセージフォーマット
  • ハンドシェーク・プロトコル :メッセージを使って暗号通信を実現するまでの手順

レコード・プロトコル

  • レコードの構成するそのもの
  • レコードはヘッダー部分とデータ部分に分かれている
  • データ部分にハンドシェーク・プロトコルが入る

ハンドシェーク・プロトコル

  • データ部分に入る
  • メッセージや、暗号通信時の暗号化データが入る
  • 暗号通信をするにあたっての必要な情報をやりとりする際に使われる
  • ここのメッセージは種類が決まっている
    • ClientHello
    • ServerHello

一般的なやりとり

以下のやりとりを行い、それ以降はクライアントとサーバーは共通鍵を使って暗号化通信を実施する

  1. 暗号通信時に使う暗号方式を決める
    • クライアントがサーバーに暗号通信で使う暗号通信方式などを提案する
      • 暗号方式だけでなく,サーバー認証の方式,鍵交換の方式,ハッシュ関数の種類など
    • サーバーは提案のあった方式から適切なものを選択して返答する
  2. Certificateメッセージの利用
  3. ClientKeyExchangeメッセージの送信
    • クライアントは入手したサーバー証明書からサーバーの公開鍵を取り出す
    • クライアントは公開鍵使って暗号通信に使う共通鍵の基になる秘密の値(プレマスタ・シークレット)を暗号化して送信する
      • 実際のSSL通信において、共通鍵を直接やりとりするのではなく、共有鍵の基になるプレマスタ/シークレットをやりとりし、そこからクライアントとサーバーが互いに共通鍵を生成する仕組み
  4. ハンドシェーク終了
    • クライアントはこれまで決めた暗号方式の採用を宣言し、ハンドシェークの終了をサーバーに知らせる
    • サーバーの動作もクライアントと同様にハンドシェークの終了をクライアントに知らせる
    • ハンドシェーク終了

通信相手のサーバーが信頼できるかの検証

証明書の「署名」

サーバー証明書はサーバーの管理者が「認証局」に申請して発行してもらう。

サーバー証明書の中にある情報

  • サーバー運営者の組織名
  • 認証局の組織名
  • 証明書の有効期限
  • サーバーの公開鍵
  • 認証局の署名
    • 署名は、証明書の内容をハッシュした値を認証局秘密鍵で暗号化したデータ

認証局の信頼性の判断

  1. ルート認証局の証明書の取得
    1. サーバー証明書と同時に署名を施した認証局の証明書もクライアントに送られる
    2. 認証局が他の認証局から署名を受けていた場合はさらにその署名を受けた認証局の証明書も送られる
    3. 最終的に一番上位に位置する「ルート認証局」の証明書が必ず送られる
  2. ルート認証局の確認
    1. PCにあらかじめインストールされている信頼できるルート認証局の証明書によって判断する