🔐

SSL/TLS について改めて理解する

2023/11/19に公開

近年は多くのサイトが「https」化(SSL通信)されていますが、SSL/TSLの通信の仕組みを問われるとイマイチ説明できない…💦ので、調べたことをまとめてみました!

そもそもSSLとは何なのか🤔?

SSL(secure sockets layer)とはインターネットで暗号通信を実現するプロトコル(仕組み)

接続相手のサーバーが信頼できるかどうかを確かめたうえで、データを暗号化してやりとりする。

  1. クライアントがデータを暗号化してインターネットに送信
  2. この暗号化データを受け取ったサーバーが元のデータを取り出す

➡️ 通信途中でやりとりの内容を見られることを防ぐ

アプリケーション(Webブラウザ)とTCPの間に位置する

Webブラウザが「https://」で始まるURLのサーバーあてにデータを送るとき、WebブラウザはTCPではなくSSLにデータを渡す。
そしてSSLは、ブラウザから受け取ったデータを暗号化してから改めてTCPへ渡す。
受信時は、送信時の流れとは逆の流れになる。

TLSとは🤔?

TLS(Transport Layer Security)はSSLの次世代規格。
SSLで重大な脆弱性(一定の条件下であれば暗号解読が可能である)が見つかり、バージョンアップされTLSに代わるようになった。

SSLとTLSの違いは?

現在一般的に「SSL」と呼んでいるものは実質「TLS」を指していることも多く、場合によってはその両方をふまえて「SSL/TLS」と表記されることもある。
厳密に考えると別物だが、いずれも安全に通信をするためのセキュリティプロトコル。

SSL/TLSの歴史📝

Version リリース年
SSL1.0 リリース前に脆弱性が発見され公開されず
SSL2.0 1994年リリース(製品に実装された後に脆弱性が発見)
SSL3.0 1995年リリース(2014年に重大な脆弱性である「POODLE(CVE-2014-3566)」が発見)
TLS1.0 1999年リリース
TLS1.1 2006年リリース
TLS1.2 2008年リリース(ハッシュアルゴリズムにSHA-256(SHA-2)が追加されが、2017年3月にGoogleから衝突に成功したことが報告される。以前からリスクが指摘されていたSHA-1が安全ではなくなったことが証明された。)
TLS1.3 2018年リリース

※現在(2023年)はTLS1.3が最新

SSLの暗号通信の仕組み🖥

SSLは、「共通鍵暗号」と「公開鍵暗号」という二つの暗号方式を組み合わせて利用している。
SSL通信の概要は「公開鍵暗号で共通鍵を安全に送る」ことである。

共通鍵暗号:暗号化と復号に同じ鍵(共通鍵)を使う暗号方式。暗号化と復号の処理が軽い。
共通鍵暗号を使うには、送信側と受信側の両者があらかじめ誰にも知られていない同じ鍵を持っていなければいけないが、鍵をそのままインターネットで送ると他人に盗まれる恐れがあるため公開鍵暗号方式を使う。

公開鍵暗号:公開鍵と秘密鍵と呼ばれるペアの鍵を使う方式。片方の鍵で暗号化したデータはペアとなっているもう片方の鍵でしか復号できない。片方の鍵をインターネットで公開しても、もう片方の鍵を秘密にしておけば目的の相手(公開鍵のペアとなっている秘密鍵を持つ相手)だけに安全にデータを送れることができる。

💡 つまりSSLは開鍵暗号方式を使って「暗号通信で使う共通鍵」を安全に共有し、共有した共通鍵を使って暗号通信をする。
こうして共有した共通鍵を使って、クライアントとサーバーは本来の目的であるアプリケーション間でやりとりするデータの暗号化/復号を高速に処理する。

SSL通信のやりとりの内容・詳細手順について紐解く📖

SSLは大きく下記二つの仕様で成り立っている。

  1. レコード・プロトコル
  2. ハンドシェーク・プロトコル

レコード・プロトコル:メッセージのフォーマット
SSLで運ぶメッセージは「レコード」と呼ばれ、ヘッダー部分とデータ部分に分かれている。

  • ヘッダー:データの種類(タイプ)、バージョン(SSLかTLSか)、データ長の情報を含む
  • データ:ハンドシェーク・プロトコルのメッセージ、暗号通信時の暗号化データを含む

ハンドシェーク・プロトコル:やりとりの手順

  1. クライアントがサーバーに暗号通信で使う暗号方式などを提案する。
  2. サーバーは提案のあった方式から適切なものを一つ選んで返答し、暗号通信時に使う暗号方式を決める。
  3. サーバーはクライアントにCertificateメッセージを使ってサーバー証明書を送り、終えたらクライアントにその旨を通知する。
  4. クライアントは「3」で入手したサーバー証明書からサーバーの公開鍵を取り出す。この公開鍵を使って暗号通信に使う共通鍵の基になる秘密の値(プレマスタ・シークレット)を暗号化して送信する(ClientKeyExchangeメッセージ)
    ※共通鍵を直接やりとりしないことで、漏洩の危険性を低くする。
    サーバーがこの暗号化したデータを自身の秘密鍵で復号するとプレマスタ・シークレットが出てくる。この時点で両者は共通鍵の基となるプレマスタ・シークレットを共有できる。
  5. クライアントはこれまで決めた暗号方式の採用を宣言し、ハンドシェークの終了をサーバーに知らせる。
  6. サーバーも暗号方式の採用を宣言し、ハンドシェークの終了をクライアントに知らせる。
  7. サーバーもハンドシェークの終了をクライアントに知らせる。
  8. これ以降クライアントとサーバーは共有したプレマスタ・シークレットから共通鍵を生成し、その共通鍵を使って暗号通信を実施する。

サーバー証明書とは何なのか📜

サーバー証明書は、サーバー管理者が「認証局」と呼ばれる組織に申請して発行してもらう。
証明書には下記情報が含まれる。

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

認証局の信頼性を確認する仕組み🔑

クライアントにはサーバー証明書と一緒に「署名を施した認証局の証明書」も送られており、
クライアントはまず「認証局(ルート認証局)が信頼できるか」を確認する。

PCにインストールされている「信頼できるルート認証局の証明書」をチェックし、
その中に一致する証明書があったらそのルート認証局の証明書は信頼できると判断する。

次に「署名をルート認証局の公開鍵で復号したデータ」と「サーバー証明書のハッシュ値」が一致するかどうかを確かめる。一致すればそのサーバー証明書は確かにルート認証局から署名を受けたサーバー証明書であることがわかる。
信頼できることが分かれば、クライアントはこの公開鍵を使ってSSL通信を実行する。

まとめ🖍

SSL/TLSとは

  1. インターネット上でデータを安全に通信をするためのセキュリティプロトコル。
  2. 情報が盗み取られるのを防止するため、データを暗号化して送受信する。
  3. 暗号化には「共通鍵暗号」と「公開鍵暗号」という二つの暗号方式を組み合わせている。

今回改めてSSL/TSLの仕組みを調べてみて、通信の安全性を高めるためにこんなにも複雑なやりとりが行われているのだと理解できました。
もし誤りなどがありましたらご指摘いただけたらと思います🙏

参考URL

Discussion