6
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

SSL/TLSの理解が曖昧な方向けの記事

Last updated at Posted at 2021-05-03

はじめに

SSL化がどうのこうのという話を現場の同僚としたのですが、会話についていけず焦ったので学び直すことにしました。
SSL/TLSについてあまり詳しくない初心者の方向けの記事になっています。

SSL/TLSとは

SSL(Secure Sockets Layer)/TLS(Transport Layer Security)とは、インターネット上で通信を暗号化する技術です。
SSLとTLSは表記が異なるだけで同じ機能を指しており、SSLは3.0までバージョンアップを重ねた後、TLS 1.0という名称に変更されました。

SSL/TLSの一番重要な役割は通信の暗号化による盗聴の防止です。
共通鍵暗号方式によってデータを暗号化してサーバとクライアントがデータをやりとりします。

また、SSL/TLSは改ざんとなりすましの防止においても重要な役割を果たします。
認証局がサーバ証明書をドメインの所有者に発行して、サーバから改ざんやなりすましのないデータが送られることを認証します(ドメイン認証)。

公開鍵暗号基盤(PKI)によるドメイン認証

SSL/TLSのドメイン認証は、公開鍵暗号方式と認証局で構成された公開鍵暗号基盤(Public Key Infrastructure = PKI)によって行われます。

まずはサーバ側でサーバ証明書を認証局に発行してもらう必要があります。
手順は以下のようになります。

  1. サーバ内で秘密鍵とペアになるCSR(公開鍵)をつくる
  2. サーバ証明書の発行申請のため認証局へCSRを送る
  3. 認証局でCSRを秘密鍵で署名しサーバ証明書をつくる
  4. 申請者(サーバ)へサーバ証明書を送る

スクリーンショット 2021-05-03 9.16.21.png

共通鍵暗号方式によるデータやり取り

ドメイン認証はPKIで行いますが、Webサイトとのやりとりには共通鍵暗号方式が使われます。

公開鍵暗号方式で安全に暗号化通信を行おうとすると、鍵長(RSAで2048ビット以上)が長くなり、鍵長が長くなると復号に時間と負荷がかかってパフォーマンスが悪くなってしまいます。
そのため、HTMLファイルなどのやりとりをする際には、サーバとクライアントで共通の鍵を使って暗号化と復号を行います。
暗号化のアルゴリズムはAESがメジャーで、鍵長は128~256ビットのものがよく使われます。

暗号化通信の流れと使用する暗号化のアルゴリズムは以下のようになります。

  1. クライアントがサーバにSSL/TLS通信をリクエスト
  2. サーバがクライアントにサーバ証明書(公開鍵)、中間CA証明書(公開鍵)、暗号スイート(暗号方式の設定)などを送信
  3. 公開鍵暗号基盤を用いてクライアント内でドメイン認証 → RSA, ECDSA
  4. 鍵交換用のアルゴリズムを使って共通鍵の素を交換しお互いに共通鍵を生成 → DHE, ECDHE
  5. サーバが共通鍵で暗号化したデータを送信 → AES, ChaCha20
  6. クライアントが暗号化されたデータを共通鍵で復号

「3. 公開鍵暗号基盤を用いてクライアント内でドメイン認証」の補足

クライアントにおけるドメイン認証の流れについては以下のようになります。

  1. サーバから取得したサーバ証明書(公開鍵)が中間CA証明書(秘密鍵)で署名されていることを中間CA証明書(公開鍵)で検証
  2. 中間CA証明書がクライアント(PC, スマホ)内のルート証明書で署名されていることを検証
  3. 認証局へサーバ証明書の有効性を確認(実施方法はブラウザに依存)
  4. サーバ証明書記載のドメインと通信先のドメインが一致していればドメイン認証完了(有効性を確認)

スクリーンショット 2021-05-14 7.43.53.png

SSL証明書の種類

暗号化通信の流れの中に、サーバ証明書と中間CA証明書というものがでてきましたが、これらはSSL証明書に含まれます。
Webサイトで利用するSSL証明書には、他にもルート証明書といったものがあります。

ルート証明書

ルート証明書はPCやスマホなどのクライアントにインストールされた状態で存在しています。
ルート証明書は他者の署名はされておらず、厳格な審査を経たルート認証局によって発行される自己署名の証明書となります。

中間CA証明書

ルート証明書の秘密鍵は秘匿性が高く、オンラインでアクセスできるところにはおけません。
そのため、サーバ証明書の発行時に利用するのは現実的ではありません。

そこでルート証明書の署名で発行された中間CA証明書を利用します。
中間CA証明書のおかげで、ルート認証局から認定を受けた企業がSSL証明書を発行できるようになります。

サーバ証明書

サーバ証明書は中間CA証明書で署名される証明書です。
ルート証明書と結びつきはありませんが、中間CA証明書がルート証明書によって発行されているので、結果的にサーバ証明書もルート証明書から信頼されていることになります。

この信頼の連鎖をトラストチェーン、信頼の起点となるルート証明書をトラストアンカーと呼びます。
中間CA証明書の設定し忘れなどをしてしまうと、トラストチェーンが崩れてドメイン認証は失敗してしまいます。

それぞれのSSL証明書の性質を理解した上でクライアント内のドメイン認証の過程を整理すると以下のようになります。

  1. サーバから取得したサーバ証明書(公開鍵)が中間CA証明書(秘密鍵)で署名されていることを中間CA証明書(公開鍵)で検証
  2. 中間CA証明書(公開鍵)がクライアント(PC, スマホ)内のルート証明書により署名されていることを検証
  3. 認証局へサーバ証明書の有効性を確認
  4. サーバ証明書記載のドメインと通信先ドメインが一致し、有効性が確認される

おわりに

応用情報の試験勉強で学んだときよりもSSL/TLSに関する理解が深まりました。

参考資料

6
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?