Enjoy Architecting

Twitter: @taisho6339

これだけは知っておこうTLS

セキュリティ

記事について

セキュリティのためにTLSを導入しようとはよく聞くが、 そもそもTLSは何を担保するものなのかを整理する。

前提として知っておくべきこと

  • デジタル署名
    • 署名者の秘密鍵で対象データ（のハッシュ値）を暗号化したものがデジタル署名
    • 秘密鍵は署名者しか知り得ないはずなので、署名者が確実に署名したことを証明できる
    • 署名データを署名者の公開鍵で復号し、実データのハッシュ値と同等になるかを検証することで、改ざんされていないことを証明できる
  • デジタル証明書
    • 公開鍵をデジタル署名 + 公開鍵をラッピングしたもの
    • これによって、正しいところからの公開鍵を使い、暗号化して通信していることを担保する
    • 通常、認証局が登録された公開鍵に署名することで、証明書が確実に公開鍵の持ち主のものであることを担保する
    • これに対していわゆる自己証明書は自分自身で作った公開鍵を自身で署名したもの
      • 自分自身で署名しているので、man in the middle 攻撃対策にならず、TLS通信をする意味がなくなってしまう。

TLSは何を担保するのか？

下記の3つを担保する。 つまるところ、man in the middle攻撃への対策となる。

  • 正真性
    • 改ざんがなされていないこと
  • 機密性
    • 通信盗聴されても大丈夫なよう暗号化されていること
  • 認証
    • 正しい相手と通信をしていること

TLSの通信の流れ

引用: SSL暗号化通信の仕組み 引用: SSL暗号化通信の仕組み

  1. クライアント -> サーバ

    • 接続要求をおこなう

  2. サーバ -> クライアント

  3. クライアント

    • 認証局の公開鍵を使って証明書に含まれる署名を復号する
    • 復号したデータと証明書に含まれるサーバの公開鍵のハッシュ値が等しいかを検証する
    • 検証が通ったら、セッション鍵を生成し、サーバの公開鍵を使って暗号化した後サーバへ送る

  4. サーバ

    • サーバの秘密鍵を使ってセッション鍵を取り出し、以降はセッション鍵を用いて暗号化した通信を行う
    • このときに Message Authentication Codeという、データのハッシュ値を付与することでデータが改ざんされていないことを担保する

どうやって３つの目的を担保しているか？

  • 認証
    • デジタル証明書と共通鍵によって想定通りの相手と通信していることを担保する
  • 機密性
    • セッション鍵による共通鍵方式の暗号化通信により、機密性を担保する
  • 正真性
    • 暗号化されたデータにMessage Authentication Codeというデータのハッシュ値を付与し、これを受け取った側がハッシュ比較することで担保する

mTLSについて

厳密には上記のTLS通信だけでは認証の要件を担保できないこともある。 たとえば、企業間の外部公開されていないシステムを連携させるような、少しセキュリティ要件の高いケースなど、 サーバにアクセスしてくるクライアントもちゃんと保証したいようなケースである。 そのときに使うのが相互TLS通信というものである。(以下mTLS) mTLSはサーバに加えて、クライアントにも証明書を要求することでクライアントの身元を保証することができる。

ルート証明書、中間証明書、サーバ証明書