Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

SSL/TLSの基本

More than 1 year has passed since last update.

まとめ

  • SSL/TLSの機能ってなに?
    • 通信相手を識別し、なりすましを防ぐ「認証」
      ※識別できても通信内容を差し替えられると意味がないので「改ざん検知」もある
    • 通信内容の漏洩を防ぐ「暗号化」
  • SSL/TLSってどんな技術?
    • 鍵交換・認証・暗号化・メッセージ認証コードの4要素のハイブリッド暗号
    • 認証のために、サーバ証明書 ( サーバ用の公開鍵証明書、SSL証明書とも ) を使用する
    • サーバ証明書の信頼性を担保するPKIの仕組みも考えると全部で5要素
    • 公開鍵暗号と共通鍵暗号のハイブリッド? そう覚えている人は一旦忘れた方がいい
  • SSL/TLSで意識することってなに?
    • 大事なのはドメイン名。なぜなら認証・PKIで「通信相手がドメイン名通りのサイトであること」を保証する技術だから
    • DVとかEVとか色々あるけど、証明書の種類は正直割とどうでもいい
    • サーバ証明書は「ドメイン名の示すサイトの本物のサーバ」であることを示す、文字通り身分証明書のようなものであって、サイト自体の信頼性とは関係ない
      ※証明書を発行する認証局は信用調査会社じゃない

SSL/TLSってどんな技術?

導入

世間一般的には「公開鍵暗号と共通鍵暗号のハイブリッド」とよく言われます。
しかし、そこから想像される仕組みは大体間違っています( 或いは部分的なものでしかありません )。
そう覚えてる人は、一回忘れましょう

代わりに分かり易い指標があります。
老舗の暗号ライブラリ・ツールであるOpenSSLでは、SSL/TLSを4つの要素で整理しています。

これは、Linux等でopensslコマンドのciphersサブコマンドを実行することで見られます。

CentOS7(OpenSSL1.0.2k)でのciphers
$ openssl ciphers -v
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
…
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
…
DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AESGCM(256) Mac=AEAD
…
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
…

ciphersサブコマンドの出力は、Cipher Suite ( 暗号スイート ) という、SSL/TLSでの暗号方式の組み合わせをリストアップしたものです。
この出力にあるように、OpenSSLではKx, Au, Enc, Mac という4要素として整理をしているのです。

4つ要素の詳細

では、このKx, Au, Enc, Macの4つの要素についてです。ちょっと順番を変えていきます。

  • Enc ( Encryption: 暗号化 )
    • 文字通り、暗号化による通信データの秘匿を行う機能。
    • サーバ・クライアントでお互いに送信するデータを暗号化し、逆に受信側で復号を行う。
    • AES等の共通鍵暗号を用いる。
  • Mac ( Message Authentication Code: メッセージ認証コード )
    • 通信データの改ざんがないかどうかを調べる機能。
    • 確認用のデータである「メッセージ認証コード」を付与してデータを送信し、受信側で整合性を見る。
    • 以前は、データと共通鍵を混合してハッシュを計算する、HMAC ( Hash-based MAC ) が使われていた。
    • 近年は、Encの共通鍵暗号がMacの機能も兼ねる AEAD ( Authenticated Encryption with Associated Data: 認証付き暗号 ) として、AES-GCM等が使われる。
  • Kx ( Key e-Xchange: 鍵交換 )
    • Enc,Macに使用する共通鍵の元になるデータを秘密裏に共有する機能。
    • 主にECDH等の鍵交換 ( 公開鍵暗号の1種 ) を用いる。
  • Au ( Authentication: 認証 )
    • 鍵交換とも連携し、サーバ側がなりすましでないことを確認する機能。
    • ECDSAやRSA署名等の電子署名 ( 公開鍵暗号の1種 ) を主に用いる。
    • サーバ証明書の正当な所有者であることを、証明書に含まれる公開鍵に対応する秘密鍵を使って証明する。
    • 電子署名の場合、署名を送ることで秘密鍵自体を提示することなく、秘密鍵の所有を証明する。
      ※署名を作れるのは秘密鍵の所有者のみという理屈

この4要素の中で、Enc,Macは共通鍵を使った技術であり、Kx,Auは公開鍵暗号を利用するものです。
※公開鍵暗号については、記事「2つの公開鍵暗号」で紹介しています。

なお、5つ目の要素であるPKIは、公開鍵暗号の1種である電子署名を利用して、サーバ証明書の保証を行うものです。その保証とは、SSL/TLSの場合はサイト(ドメイン名)と公開鍵が確かに対応していることについてです。
PKIそのものの詳細については、記事「2つの公開鍵暗号」のPKI(公開鍵基盤)をご覧ください。
このサーバ証明書に含まれる公開鍵はAu(認証)の手続きのために使用します。

各要素の位置づけ

上で挙げた各要素の位置づけ・関連を図示すると次のようになります。

image.png

近年のAEADを使う方式だと、以下のように、EncとMacがひとまとめになります。

image.png

認証と証明書

サーバ証明書の役割

上で説明した通り、サーバ証明書の役割は次の2つです。

  • 認証の手続きで使用する公開鍵を提供すること
  • その公開鍵とサイト(ドメイン名)の対応を保証すること

これはちょうど、身分証明 ( と、自動車の運転資格の証明 ) に使われる「運転免許証」に類似しています。
運転免許証が、ある人に対して、その人を見分けるための情報 ( 顔写真 ) を示すのに対し、サーバ証明書は、あるドメイン名に対して、認証に使う公開鍵を示します。

image.png
※画像はイメージです

もちろん運転免許証とサーバ証明書は別のものですので、以下の表のように色々違いがあります。

項目 運転免許証 サーバ証明書
識別子 運転者の氏名 サイトのドメイン名
※複数あるいはパターン指定可能
本人確認用情報 顔写真 認証用の公開鍵
発行者 各地の公安委員会
※委員会印の印影付き
認証局という種類の組織
※認証局による電子署名付き
目的 運転できる自動車の種類を示す 公開鍵がサーバ認証用途であることを示す
※一般の公開鍵証明書には様々な用途がある

なお、サイトの識別をドメイン名で行うようになっているのはHTTPS(HTTP over SSL/TLS)がそのように要請しているからであって、SSL/TLSそのもののきまりではありません。が、HTTPS以外であっても状況は似たようなものと考えられるため、一緒くたにして説明しています。
※細かいことを言うと、IPアドレスにより識別する方法もあります。

このドメイン名は、証明書のSANs(Subject Alternative Names)という項目で管理します。
この項目では、複数のドメイン名や、ワイルドカード ( アスタリスク ) によるドメイン名パターンを指定することができ、1つの証明書を複数のドメインで共有することができます。
もしSANsがない場合は、伝統的に CN(Common Name) の内容がドメイン名とみなされます。
例えばこの qiita.com の証明書の場合、Windowsの証明書ビューアで以下のように見えます。
※ブラウザでサイト閲覧する場合は、ブラウザがURLのドメイン名と突き合わせて自動的にチェックしますので、あえて手動で確認する必要はありません。

image.png

認証と鍵交換の連携

さて、Au(認証)では公開鍵暗号の1種である「電子署名」を使うのが基本です。
次のように、正しい署名が作れるのは秘密鍵の持ち主だけということを利用し、秘密鍵そのものを提示することなく秘密鍵の所有を証明します。

image.png

ただし、ここで問題となるのが、上の図中の「認証用データ」です。
サーバは通信のたびに「正しい」署名データを各所にばらまくことになるので、認証用データを都合よく決めることができてしまうと、署名の流用でなりすましされるおそれがあります。
これは電子署名単独では解決できない問題です。

一方で、Kx(鍵交換)に使う公開鍵暗号の「鍵交換」単独では問題があります。
それは、鍵交換用のお互いの公開鍵が第三者にすり替えられると中間者攻撃(MITM)という介入を許すという問題です。
※鍵交換用の公開鍵・秘密鍵は都度使い捨てにしますし、そもそもPKIの保証の範囲外にあります。

そこで、Au(認証)とKx(鍵交換)を連携させることで、これらの問題に対処しています。
それは、次の図のように鍵交換用の公開鍵の一方から認証用データを作り署名対象とすることです。

image.png

このようにすることで、それぞれの問題への対処になっているのです。

  • 署名の流用への対処
    認証用データが鍵交換用の公開鍵に紐づいているので、署名を流用しようとしても鍵交換が成立しない。
    ※鍵交換用の秘密鍵は表に出ないので、鍵交換用公開鍵・秘密鍵と署名の3点を揃えることはできない
  • 鍵交換用公開鍵のすり替えへの対処
    一方の公開鍵が署名によって保護される形になり、すり替えを検知することができる。
    ※両方保護しなくても、一方のみで十分

なお、どちらの鍵交換用公開鍵を使うかは、SSL/TLSのバージョンによって異なります。
TLSv1.2まではサーバ側の公開鍵、TLSv1.3ではクライアント側の公開鍵を使います。

サーバ証明書の種類

上で、サーバ証明書を運転免許証に喩えました。
ここで、運転免許証の発行を受ける際、道交法の知識と運転技術に関する審査がありますが、サーバ証明書にそういった資格審査があるわけではありません。
認証局が行うのは、あくまで申告されたドメイン名のサイトの運営者かどうかという身分確認に過ぎません。

ただ、その身分確認には3つの段階があり、それにより証明書にも、DV,OV,EV の3種類があります。

以下、その種類の話となりますが、先に注意事項として、この種類の違いをユーザが気にする必要はほとんどありません。( EVだけは例外で、若干の意味がある場合があります )
そのことは、ブラウザでの各証明書の扱いにも現れていて、パッと見ではほとんど違いがないのです。もちろん、わざわざ手動で詳細を確認する意味もありません。

では、それぞれの種類の概要です。

  • DV ( Domain Validation )
    認証局は、申請者が申告されたドメイン名のサイトの運営者であることのみ確認します。
  • OV ( Organization Validation )
    DVの確認に加え、認証局は、申請する組織の実在情報も確認します。
    証明書に組織情報が記載されます。
  • EV ( Extended Validation )
    OVと類似していますが、実在情報の確認が更に厳しく行われます。
    ブラウザで組織情報が表示されるようになります。

以下、実際のブラウザ ( Google Chrome ) での表示の違いです。
※証明書情報は、証明書表示ウインドウを別途出して確認しています。

image.pngimage.pngimage.png

「種類の違いをユーザが気にする必要はほとんどありません」という点について、もう少し補足します。
なぜ気にする必要がないかというと、サイトを識別するのがドメイン名であることから、そのドメイン名のサイトの運営者かどうかが最重要ポイントであって、組織情報はあくまで付加的なものでしかないからです。
それでもEVの場合は、組織情報「も」正しいサイトかどうかの判断材料に使えるという点で、意味があるとは言えます。ただしこれはある程度有名な組織でないと意味がないため、どのサイトでも採用できるものではありませんし、組織名はドメイン名に比べて精度の低い情報であるため、組織名に過度に頼ってドメイン名をおざなりにするのでは本末転倒です。
※もちろん、サイトの正しいドメイン名を事前に確認するのが大前提です。

余談

電子署名以外の認証

上では、鍵交換→公開鍵暗号の「鍵交換」、認証→公開鍵暗号の「電子署名」が基本だと説明しましたが、TLSv1.2までは、両者を兼用する方式もありました。
丁度次の図のようなイメージになります。

image.png

これは、公開鍵暗号の「暗号化 ( 狭義公開鍵暗号 )」あるいは「鍵交換」を、サーバ証明書にある公開鍵で行うことでKx(鍵交換)をまかない、Kx(鍵交換)が正しく成立したことをチェックしてAu(認証)とするものです。
※鍵交換+電子署名の場合、鍵交換用の公開鍵・秘密鍵は使い捨てであることに注意してください。

「暗号化」を使用する方式については、記事「2つの公開鍵暗号」の狭義公開鍵暗号にある「(狭義)公開鍵暗号に基づく鍵交換」をご覧ください。

この方式は長らく使われていたものの、もともと証明書に対応する秘密鍵が漏洩すると過去の通信のKx(鍵交換)が解読され通信データの漏洩につながるという問題があり、数年前から使われなくなりました。そしてTLSv1.3で廃止となっています。
※以前使われていたのは、この問題が現実的な脅威と見なされていなかったことや、処理性能上有利であったことが原因であると考えられます。

よくある誤解

以下、SSL/TLSに関する説明でよくある誤解について紹介します。

  • 証明書に含まれる公開鍵で共通鍵を暗号化する
    これは、上の電子署名以外の認証で紹介している方式の簡易版の説明と言えます。しかし、鍵交換+電子署名という基本の方式を忘れている上に、今では廃止されているものです。
    大昔のSSLv2の説明ならまだしも、いい加減ボツにすべきと言えるでしょう。
  • SSLやサーバ証明書はサイトの信頼性を保証するもの
    SSL/TLSは接続先が意図したドメイン名のサイトかどうかを保証するものであって、サイトの信頼性 ( 運営者の善性、フィッシングサイトでないこと、有害コンテンツがないこと ) の保証とは無関係です。
    加えて、証明書を発行する認証局も、そのサイトや運営者の信用調査を業とする組織ではありません
    ※フィッシングサイト/マルウェアチェックを独自に行う認証局もありますが、ユーザがわざわざ手間をかけて、認証局と実施しているサービスを調べ、その信頼度を判断するのは無理があります。
  • EVの証明書の方が(DV,OVに比べ)信頼性がある
    サイトの正当な運営者かどうかという意味ではDV,OV,EVどれも変わりません。
    もちろん、EVの方が証明書発行のコストは大きくなります。が、コストをかけているから信頼できると考えるのは短絡的だと言えます。
    ※統計上は違いは出るかも知れませんが、「今アクセスしているサイトがどうか」の判断とは別物です

終わりに

記事「2つの公開鍵暗号」で書ききれなかったハイブリッド暗号の事例として、SSL/TLSを取り上げました。
そろそろステレオタイプな伝言ゲームでなく、正しい理解に基づく情報が広まることを願ってやみません。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away