改めて人に聞かれると説明が微妙に難しいやつ[5] SSL/TLS編
微妙に難しいシリーズ5回目、今回のテーマはこちら
"SSL/TLS"ってなんだ？
よくSSL証明書が〜とかHTTPじゃなくてHTTPSにしないと〜とか、そもそもHTTPSだからって絶対安全ではなくて〜とか、
話だけは耳にするにするものの、設定作業はインフラエンジニアさんに任せっぱなしで実はよく分かってない🙃
HTTPSだとなぜHTTPより安全なのかとか、HTTPSにするのにSSL証明書？が必要らしいけど、そもそもSSLって何のことなの？
ていうかSSLで本とかネットで調べたら "TLS" って言葉が出てきたんだけど、両者の違い？関係？ってどういうものなの？
・・・くらいのレベルからスタートして、SSL/TLSの技術がwebサイト・アプリケーションにとってどのように作用しているのかを解説していきます。
と、その前に記事作成にあたって参考にさせていただいたサイト・書籍について先に紹介します。
参考サイトの紹介
① SSLの仕組み｜情報セキュリティ関連の技術 - 総務省
"SSL"でGoogle検索すると最上位に総務省のサイトが出てきます。[1]
基本的なことだけ知りたい場合はここを読むだけで十分でしょう。
なお、2022年5月にサイトが全面刷新されたようで、刷新後のページはこちら↓
② TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～
こちらは独立行政法人情報処理推進機構（IPA）の資料集です。
総務省のサイトが一般国民向けであれば、こちらはwebエンジニアリングに携わる人向けの内容と言えます。
1.2 本書が対象とする読者
本ガイドラインでは、主に Web に TLS を利用するシステムを対象に、TLS サーバを実際に構築するにあたって具体的な設定を行うサーバ構築者、実際のサーバ管理やサービス提供に責任を持つことになるサーバ管理者、並びに TLS サーバの構築を発注するシステム担当者を想定読者としている。
一部の内容については、ブラウザを使う一般利用者への注意喚起も対象とする。
参考図書の紹介
① 3分間HTTP＆メールプロトコル基礎講座
3分間NetWorkingシリーズの1冊、著者は網野衛二氏です。
2015年初版で若干の古さは気になりますが、他の参考書などで現在の情報と併せて読み替えれば問題なく読める内容になっています。
本書の特徴として、各説明が対話形式になっており図解と併せて非常に理解しやすい作りになっています。
また、今回の内容とは外れますがメールサーバー周りのお仕事に不慣れな場合はまずこれを読めば理解が捗るでしょう💡
なお近著としては2022年6月発売の こちらは未読ですが機会があれば本屋さんに行って買ってみようと思います。
② 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 第2版
独立行政法人情報処理推進機構(IPA)非常勤職員でもある徳丸浩氏の著書です(通称:徳丸本)
前回に引き続き参照させていただきました。
今回は、webサイトのなりすまし・フィッシング対策に関する項目から必要な対策としてのTLS導入について参考にさせていただきました。
あとがき(仮)
ここまでお読みいただきありがとうございました🙏
SSL/TLSに関する参考情報のみ知りたい方は上記を参照いただければ幸いです👍
また、以下は個人的な備忘録となっておりますのでブラウザバックしていただいて構いません。
気になる方のみ、引き続きお付き合いいただければと思います。
本記事では、インフラエンジニアさんが日常的に行なっている専門的な領域を、アプリケーションエンジニアの視点から紐解いていければと思います。
本記事の想定読者
フロントエンド・サーバーサイドエンジニアで、
- SSL/TLSの利用例を知りたい方
- SSL/TLSの仕組みと設定の流れについて知りたい方
※ITエンジニアか否かを問わず、SSL/TLSの概要だけでもまず知りたい方
→ 総務省のサイト をご確認ください
本記事執筆の目的
- webアプリケーションにおける最低限のセキュリティ知識を持ちたい読者の
最初のステップとなる文章であること- 上記で紹介した参考書籍・サイト情報の理解を補助する文章であること
- 筆者自身がより明確に用語(本記事では
TLS,SSL)の意味を理解し
他者への適切な説明能力の獲得出来る取り組みであること
本記事では取り扱わないこと
- 詳細な仕様・暗号技術の仕組みなどの解説
(別記事で取り上げます)
本題
■ 言葉の意味を改めて確認
📗 訳してみる
SSL(Secure Sockets Layer)
Secureはともかく Sockets, Layer(層？) はちょっと怪しいので念の為、例によって英英辞典を参照します。毎度お馴染みのコウビルドエッセンシャル英英辞典からの引用・翻訳はDeepLに手伝ってもらいました。
socket
a hole that something fits into to make a connection
(接続するために何かがはめ込まれる穴のこと)
layer
a substance or a material that covers a surface, or that lies between two other things
(表面を覆う、または他の2つのものの間にある物質または材料)
意訳ですが「安全で堅固な接続のための層」とでも言うべきでしょうか。
TLS(Transport Layer Security)
こちらは私の英語力でもなんとか理解できそうなので辞書は引いていませんが、
「安全に移送するための層」といった意味合いでしょうか。
🖋 ひとまず仮説
SSLとTLS、言葉の意味を比較するだけでは何が違うのかよくわかりませんね。言い回しが違うだけで同じものを指している感じです。両者に違いがあるとして、
- 技術的・仕組み的に異なるものなのか
- 歴史的経緯によって呼び名が変わったのか
- いずれかがもう一方を内包する概念なのか
・・・はて🤔
■ 特徴
では次に技術的な特徴を中心に正体を探ってみましょう。
HTTPSとSSL/TLS
冒頭に紹介した3分間HTTP＆メールプロトコル基礎講座にHTTP/HTTPSの説明がありました。本書の記載によれば、
- HTTP通信の弱点(対策方法はあるものの[2])
- 相手を確かめない
- 平文での通信
- 改ざん防止がない
- HTTPS通信の特徴
- HTTPS(HTTPオーバーSSL)による認証と改ざん防止の設定ができる
- パスワードの暗号化(公開鍵暗号化方式)
- SSLが標準化されてTLSと呼ばれるようになった
- ディジタル証明書を用いたセキュリティ対策が可能[3]
SSLが標準化されてTLSと呼ばれるようになった
🖋 特徴まとめ
なるほど。
HTTP通信を安全にするための要素として登場したのがSSL、
そしてSSLは仕様上の脆弱性を理由に、バージョン3.0を最後に使用の禁止が勧告され、後にTLSが標準化されたようです。[4]
また、現在もなお「SSL証明書」と呼ばれているのは、「SSL」という言葉が広く普及した名残でそのまま通称として使われているということみたいですね(確証は得られませんでしたが)
とはいえ現在はHTTP/3が2022年6月から導入されています[5]ので、本書執筆時とは状況が違うかもしれません。
別な最新情報も併せてチェックしてみましょう。
こちらはHTTP/3開発元のInternet Engineering Task Force(IETF)が公開しているドキュメントです。
以下、ページ内検索"TLS"で引っかかった箇所から一部抜粋です。
httpsスキームでは、クライアントがホストに対して信頼できると考える証明書を所有することで、権限を関連付けます。
URIの権威コンポーネントによって特定されるホストに対して、クライアントが信頼できると考える証明書の所有と関連付けます。
TLSのハンドシェイクにおいて、サーバ証明書を受信した場合、クライアントはサーバ証明書を受け取った場合、クライアントはその証明書がURIと一致するかどうかを検証しなければなりません。
その証明書がURIの発信元サーバと許容できる一致であること [HTTP]のセクション4.3.4で述べられているプロセスを使用して、証明書がURIの発信元サーバーと許容できる一致であることを検証しなければなりません。
もし証明書がURIのオリジンサーバーに関して検証できない場合、クライアントはサーバーに関して証明書を検証できない場合、クライアントはそのサーバーがそのオリジンに対して権威があると見なしてはなりません。
3.1. Discovering an HTTP/3 Endpoint(原文)
The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host identified by the authority component of the URI.
Upon receiving a server certificate in the TLS handshake, the client MUST verify that the certificate is an acceptable match for the URI's origin server using the process described in Section 4.3.4 of [HTTP].
If the certificate cannot be verified with respect to the URI's origin server, the client MUST NOT consider the server authoritative for that origin.
クライアントは、"https"のURIを持つリソースに対して、以下の方法でアクセスを試みることができる。
ホスト識別子をIPアドレスに解決し、指定されたポートでそのアドレスへのQUIC接続を確立し（前述のサーバ証明書の検証を含む）、その安全な接続を介してサーバにURIを対象としたHTTP/3リクエストメッセージを送信する。
HTTP/3を選択するために他のメカニズムが使用されない限り、トークン「h3」はTLSハンドシェイク中のアプリケーション層プロトコル交渉 (ALPN; [RFC7301] 参照)拡張で使用されます。
3.1. Discovering an HTTP/3 Endpoint
A client may attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection.
Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301])
HTTP/3は、基礎となるトランスポートとしてQUICバージョン1に依存しています。 HTTP/3での他のQUICトランスポートバージョンの使用は、将来の仕様で定義されるかもしれません。
QUICバージョン1は、そのハンドシェイクプロトコルとしてTLSバージョン1.3またはそれ以上を使用します。
HTTP/3クライアントは、TLSハンドシェイクの間、サーバーにターゲットホストを示すメカニズムをサポートしなければなりません。
サーバーがドメイン名([DNS-TERMS])で識別される場合、クライアントはターゲットホストを示す代替メカニズムが使用されない限り、サーバー名表示(SNI; [RFC6066])のTLS拡張を送信しなければなりません。
3.2. Connection Establishment
HTTP/3 relies on QUIC version 1 as the underlying transport.
The use of other QUIC transport versions with HTTP/3 MAY be defined by future specifications.
QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol.
HTTP/3 clients MUST support a mechanism to indicate the target host to the server during the TLS handshake.
If the server is identified by a domain name ([DNS-TERMS]), clients MUST send the Server Name Indication (SNI; [RFC6066]) TLS extension unless an alternative mechanism to indicate the target host is used.
🖋 情報を整理する
難解な内容ですが、おおよそこういうことでしょう↓
- クライアント(ユーザーの使用する端末)とサーバーの間の(通信における)信頼証明の検証にTLSが用いられている
- クライアントは、SSL証明書の内容とURIが一致しているかをチェックする
- 検証が失敗した場合(仮にサーバー証明書が存在していたとしても)、クライアントはサーバーに対する信頼証明を行わない
= HTTPS通信を行わない
= ブラウザ上で警告が出るため成りすましサイトを事前に確認できる
クライアントとサーバーの間をTLSが取り持って安全な通信であると判定されれば、結果としてブラウザ上では https://~~~ と表示されるということですね。
これで最新のHTTP/3においても引き続きTLS(1.3)は活躍しているということが確認できました。
🔓 常時SSL化しておけば絶対安全なのか？
最後にこの点について少し触れておきたいと思います。
常時SSL化 とはサイトの特定ページのみをSSL化するのではなく、有効範囲をサイト全体とすることを指します。現在多くのサイトが常時SSL化で対応していますが、
残念ながらSSL証明書を利用したとしても、条件さえクリアすれば攻撃自体は可能です(※当然ながら犯罪行為です)
🍪 Cookieの改ざん
Cookieの解説はいずれ改めて記事にしますが、Cookieとはサーバーから送信されるクライアント側(ユーザー端末)のwebブラウザに保存されるデータを指します。
Cookieに適切な対処がされていない場合やユーザーがどのwebブラウザを使用するか等、
条件さえ揃えば攻撃者はCookieを改ざん・盗聴可能なケースがあります。
上記の攻撃対策としては
- ユーザーは古いwebブラウザを使用しない(=Cookieの上書きを拒絶できないブラウザ)
- 開発者はCookieにそもそも重要な情報を格納しない(盗聴されても問題ないようにする)
- 開発者はCookieにSecure属性を設定する(※盗聴は防止できますが、改変は阻止できません)
※下記記事・動画を参考にさせていただきました
徳丸浩のウェブセキュリティ講座
あとがき
最後の最後までお読みいただき本当にありがとうございます🙏
もう少し掘り下げた内容も書くかどうか悩んだのですが、それはまた別の機会に持ち越そうと思います。
Typo指摘, ここは正しく無いのでは？ 等あればお知らせください。
改めてよろしくお願いいたします。
それでは次のシリーズ記事でまたお会いしましょう。
参考図書の紹介その2
手持ちの書籍で今回のテーマで記事作成に書くにあたって参照した本を紹介します。
いずれもSSL/TLSの専門書ではないのですが、関連知識として紹介されていたので併せて読んでみました。
-
Webを支える技術 HTTP，URI，HTML，そしてREST
p.137, 138 -
めんどうくさいWebセキュリティ
p.84~90
p.195, 196 -
Web API: The Good Parts(oreilly本)
p.157~162 -
Web APIの設計
p.208
Discussion