はじめに
こんにちは！Product Unit SINIS for X 開発チームの西野です。
今回は私たちがインターネットを利用する上で欠かせない技術であるSSL/TLSについて、それがセキュリティ的にどのような役割を担っているのかお話します。
さらに、2024年10月現在最新のTLS 1.3（RFC8446）を対象に具体的な通信の流れを解説します。
なお本記事の執筆にあたって、主に書籍では暗号技術入門 第3版を、TLS 1.3については以下の文献を参考にしております。
- https://datatracker.ietf.org/doc/html/rfc8446
- https://www.ipa.go.jp/security/crypto/guideline/gmcbt80000005ufv-att/ipa-cryptrec-gl-3001-3.1.0.pdf
イントロダクション
対象読者
SSL/TLSとは？
よく『SSL/TLS』とひとまとめにして表記されますが、実際にはSSL（Secure Socket Layer）とTLS（Transport Layer Security）はそれぞれ別のプロトコルです。
より正確には、TLSはSSL 3.0*1を元にした新しいプロトコルであり、現在ではセキュアなプロトコルとしてTLSが広く一般的に利用されています。
具体的なところで言うと、例えばHTTPによる通信をSSL/TLSを利用して保護することによってHTTPSの仕組みが実現されます。
SSL/TLSはHTTP以外の様々な通信方法でも利用されますが、今回はHTTP通信におけるSSL/TLSのユースケース、特にTLS 1.3にフォーカスして話をします。
話さないこと
- 個々の暗号技術についての具体的な理論
SSL/TLSの役割
例えば筆者がA社でネットショッピングをする時のことを考えます。
商品を購入するための支払いにクレジットカードを利用したいと考えており、そのためには自身のクレジットカード情報をA社に正しく伝える必要があります。
また、配送を依頼するにあたって氏名や住所も伝えなければなりません。
これらの個人情報について、当然関係のない第三者には知られたくありません。
しかし、この情報を伝えるためには自身が利用しているPC（Webブラウザ）からA社のサーバーへの通信が必要となります。
この過程で以下の問題が発生します。
- 機密性の問題
- 正真性の問題
- 認証の問題
それぞれ解説します。
機密性の問題
HTTPでは平文で通信をおこないます。この際、通信が盗聴されてしまうとその内容が第三者に知れ渡ってしまいます。
そこで、通信の内容を暗号化することによって盗聴された場合でも元の内容が第三者には伝わらないようにする必要があります。
SSL/TLSではこの機密性を確保するための暗号技術として、共通鍵暗号と公開鍵暗号を組み合わせたハイブリッド暗号を用います。
正真性の問題
筆者が送った通信がA社に届くまでの間に、攻撃者によって内容を改竄されてしまう可能性があるという問題です。
SSL/TLSは改竄を検知して正真性を担保するための暗号技術として、一方向ハッシュ関数によるメッセージ認証コードを用います。
認証の問題
筆者が個人情報を入力しようとしているWebページが実は攻撃者によって偽装された偽物で、その先にあるサーバーもA社のものではない偽物であるといったようなリスクを含む問題です。
SSL/TLSは通信相手が本物であることを認証するための暗号技術として、デジタル署名をつけた証明書を利用します。
フレームワークとしてのSSL/TLS
それぞれの仕組みを組み合わせたフレームワークを提供するものです。
これによって、個々の暗号技術に脆弱性が発見された場合でもSSL/TLS自体が脆弱になることを防ぎます。
SSL/TLSではこれらの暗号アルゴリズムの組み合わせを暗号スイートという形で提供します。
例として、TLS 1.3の暗号スイートは以下の5つです*2。
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_CCM_SHA256
- TLS_AES_128_CCM_8_SHA256
（出典: https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.4）
暗号スイートは通信をおこなうクライアントとサーバーが互いに対応しているものしか利用できないため、SSL/TLSのバージョンやそれぞれの対応状況によっては強度の低い暗号を利用して通信をおこなう可能性があることには注意する必要があります*3。
TLS 1.3を使った通信
具体的にTLS 1.3を利用した通信の手順について解説します。
TLSプロトコルはやり取りする暗号方式の決定などをおこない通信を開始するためのTLSハンドシェイクプロトコルと、メッセージを暗号化して通信をおこなうTLSレコードプロトコルの2層で構成されます。
TLSハンドシェイクプロトコル
TLSハンドシェイクプロトコルは更に複数のサブプロトコルを含みますが、ここではその中で中核を成すハンドシェイクプロトコルについてその流れを説明します。
以下はハンドシェイクプロトコルの流れを図示したものです。
(1) ClientHello および (2) Server Hello の通信は暗号化されておらず、ここで利用する暗号方式の取り決めとDiffie-Hellman鍵交換を利用した鍵の共有*4をおこないます。
以降の通信については上記のステップで交換した情報をもとにして暗号化されます。
(5) Certificate ~ (7) Finished でサーバーの証明書の送付及びハンドシェイク終了のメッセージがクライアントに向けて送られます。
クライアント認証が求められる場合は併せて (4) CertificateRequest が送られ、(8) Certificate 及び (9) CertificateVerify でクライアントの証明書がサーバーに送付されます。
加えて (10) Finished でクライアントからサーバーへのハンドシェイク終了メッセージを送ります。
以上がTLS 1.3のハンドシェイクプロトコルの流れとなります*5。
以降はTLSレコードプロトコル上で実際の通信内容のやり取りをおこないます。
TLSレコードプロトコル
TLSレコードプロトコルではメッセージを複数のフラグメントに分割し、それぞれに対して暗号化を施した上でヘッダを付与して送信データとします。
SSL/TLSで対応できないリスク
SSL/TLSを利用した通信をおこなっているからといって必ずしも安全であるとは限りません。
証明書がある = 信頼できるというわけではない
あくまで証明書は認証局が確認した本物のサーバーであることを証明するためのものであり、そのサーバーを管理している相手が信頼に足ることを保証するものではありません。
ネットショッピングをする場合であれば、取引相手のA社が信用できるかどうかは自身で判断する必要があります。
通信をおこなう前のデータは守られない
当然ですが、Webサイト上で入力されているデータはまだ暗号化されておらずソーシャルエンジニアリングの危険性があります。
他にもパスワードの管理方法がずさんであれば、通信とは関係ない部分で機密情報が盗まれてしまう可能性などがあります。
通信をおこなった後のデータは守られない
ネットショッピングの例で言うと通信をおこなった後、住所やクレジットカード情報などはA社のサーバーに保存されます。
その後のデータの管理についてはA社の責任であり、SSL/TLSの預かり知るところではありません。
セキュリティの脆弱性を突かれたことによる個人情報漏洩のニュースは後を絶えません。
これについてはA社の管理体制に対する信用の話になるでしょう。
まとめ
安全な通信を実現する上で、SSL/TLSは非常に重要な役割を担っています。
また、利用される個々の暗号アルゴリズムについて時代とともにコンピューターが発達していくことによっていずれ危胎化していくため、それらの動向に気を配ることも大切です。
ただし、セキュリティの問題を語る上で最も懸念となるのは常に人間です。
人間によるセキュリティ上のリスクを完全に排除することは事実上不可能であると言えますが、システムを作る立場にある我々としてはできる限り最大限の努力と対策を継続していく必要があると考えます。
テテマーチでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ herp.careers
エンジニアチームガイドはこちら！ tetemarche01.notion.site
