Firebase Hostingへのデプロイサイト、SSL LabsでWEAKの暗号スイート検出されたけど大丈夫か!?
結論
- Firebase Hostingにデプロイした場合、TLS1.2の暗号スイートにWEAKが検出される
- Firebase Hostingにおいて、暗号スイートを変更する機能は用意されていない
- WEAKな暗号スイートの検出が即座に深刻なセキュリティリスクとなるわけではない[1]
- 静的なコンテンツを配信するだけのサイトならば、WEAKな暗号スイートが使われていても問題ない場合がある
- ログイン機能や個人情報の送信がある場合は、WEAKな暗号スイートを使わないような構成変更を実施することが望ましい
はじめに
Firebase Hostingにデプロイしたサイトにおいて、SSL/TLSハンドシェイクで使われている暗号スイートの調査を行いました。
Firebase Hosting にデプロイした場合、TLS 1.3
と TLS 1.2
が自動的に有効になる[2]のですが、SSL Labs で確認すると TLS 1.2
の暗号スイートに一部「WEAK」の指摘が検出されます。
「WEAK」と聞くと、セキュリティリスクがあるのではないかと心配になりますが、色々と調べると、WEAKな暗号スイートがあることが即座に深刻なセキュリティリスクとなるわけではないことがわかりました。本記事はこうした結論に至るまでの調査したSSL/TLS周りの内容についてまとめています。
暗号スイート(Cipher Suites)とは
細かい部分は後ほど解説しますが、SSL/TLS1.2 や 1.3 でWebサイトと通信する際に、クライアント(ブラウザなど)とサーバーで「この暗号プロトコルで通信するぜ」と事前に取り決めをします。(SSL/TLSハンドシェイク)
通信する暗号方式が定まらないと、データの復号化もできそうにないですよね?
- クライアント:この方式で通信したい
- サーバー:この方式で通信可能だよ
という情報をもとに通信する方式を決めています。先程の画像でいえば、
TLS1.3は、「TLS_AES_128_GCM_SHA256」や「TLS_AES_256_GCM_SHA384」を使った方式で通信できるよということです。
TLS_...
から始まる文字列で定義されている部分を暗号スイートといいます。
暗号スイート詳細
- TLS 1.3: TLS_AES_128_GCM_SHA256
- TLS 1.2:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
先ほどの画像でこういった文字列が並んでいました。これらが暗号スイートです。
TLS1.2の場合は、「鍵交換_署名_暗号化_ハッシュ関数」を並べています。例えば、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
には以下のような意味があります。(細かいアルゴリズムについては割愛)。
- TLS:Transport Layer Security (通信の暗号化プロトコル)を利用
- ECDHE:「鍵交換アルゴリズム」にECDHEを利用
- ECDSA:「デジタル署名アルゴリズム」にECDSAを利用
- AES_128_GCM:「暗号化鍵」に128ビット長のAESを使う
- SHA256:「メッセージ認証用のハッシュ関数」にSHA256を使う
TLS・SSLでは、複数の技術の組み合わせで通信しています。この技術の組み合わせを暗号スイート(ここでのsuiteはパッケージの意ですね)として定義しているわけです。
TLS1.3の場合は、鍵交換アルゴリズムは常に Ephemeral を使用、デジタル署名アルゴリズムは signature_algorithms 拡張で別途指定となっており、暗号スイート名からは省略されています。
TLS_AES_128_GCM_SHA256
の場合
- TLS:TLSだよ
- AES_128_GCM:暗号化鍵
- SHA256:メッセージ認証のハッシュ関数
- TLS1.2と比べて省略されているもの
- 鍵交換アルゴリズム
- デジタル署名アルゴリズム
SSL・TLSハンドシェイクってなんだ?
図はIPAの資料より。
SSL・TLSハンドシェイクは、クライアントとサーバが暗号化通信を始める前に、お互いの身元確認と使用する暗号化方式の取り決めを行う準備作業のプロセスです。
ここで重要なのは、「クライアント」が「利用可能な暗号スイートをサーバーに渡している」という点です。サーバはそのリストと、自分が提供可能なリストをもとに暗号スイートを決めています。
- クライアント:「これとこれとこれの暗号スイート使えます!」
- サーバー:「その中でこの暗号スイートなら使えるよ。これで通信しよう」
てなかんじです。
クライアントからリクエストしている暗号スイートをサーバー側サポートしていないと通信ができません。(これ重要)
なぜ WEAK がでるのか?
たとえば、TLS1.2の暗号スイート:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
にはWEAK マークがついています。
これは、暗号スイートの構成要素に脆弱性のあるものが含まれているからです。具体的には以下です。
- 暗号化鍵: AES_128_CBC の部分
- ハッシュ関数: SHA-1(SHAはSHA-1のこと)
これらがなぜ危険なのかについての詳細は割愛しますが、概要としては暗号文の解読・メッセージの改ざんが可能だったり、ハッシュが衝突して認証を突破できてしまうといった危険性があります。
暗号スイートにWEAKがあると問題あるのか?基本的にはYesだが…
基本的にはYesで使わないにこしたことがないです。
とはいえ今回はFirebase HostingにデプロイしたサイトでWEAKの指摘がでています。Firebase Hostingでは暗号スイートの変更機能は用意されておらず、すべてGoogleが自動的に用意します。そのためWEAKが検出されつつも、それで問題ないかどうかを考える必要があります。
SSL LAbaの結果ですが、TLS1.2には優先順位が設定されています。
TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ← こいつがWEAK
...
TLSの暗号スイートには優先順位が設定されているので、安全なものから利用され、WEAKな暗号スイートでの通信の可能性を減らすことができます。
余談ですが、今回のキャプチャはGoogleのFirebase Hostingにデプロイしたサイトに対してSSL Labsでセキュリティチェックをかけた結果です。つまり、Googleが一般的にWEAKだと考えられている暗号スイートをサポートしているわけです。ではなぜGoogleがわざわざWEAKな暗号スイートをサポートしているのかといえば、後方互換性のためだと思われます。
そもそもTLS1.2をサポートしていないクライアントや、TLS1.2のWEAKな暗号スイートでしか通信できないクライアントが世の中にはあります。(Android4系とかIE11とか)。こうした古いクライアントからのアクセスでも通信できるように、WEAKな方式もサポートしていると考えられます。
こう考えると、古いクライアント(ブラウザ、スマートフォン)を使わず新しいものを使いましょうう、という主張がより理解できます。(そもそもAndroidの4系やIEを使う人がどれくらいいるのかって話ですが)
例)Android4系はTLS1.0が使われている
さて、ここまでの話で分かってきたようにWEAKな暗号スイートで通信する場合は、ハッシュ衝突や改ざんの可能性が理論的には存在します。
結局のところ
- リスクがあるAndroidの4系やIEを使う人がどの程度いるのか?(アクセス空間が限定されるならそのままでもいいと思う)
- サービス特性としてコンテンツ配信だけなのか、ログイン等個人情報の取扱があるか?(静的コンテンツ配信ならリスクは限りなく低いと思う)
などを考慮して決める話になってくると思います。
なお、VercelにデプロイしたサイトでもSSL Labsを回してみましたが、古い端末からのアクセスはサポートしていませんでした。後方互換とはいえ、かなり古い端末たちなのでGoogleも安全な通信に限定してくれればよかったのですが…
まとめ
Firebase HostingにデプロイしたサイトでWEAKの暗号スイート検出されたことを起点に、SSL/TLSハンドシェイクや暗号スイートについて解説してきました。
「大丈夫化!?」という問いに対して、まぁケースバイケースだよね、というつまらない結論になってしまいました。
WEAKな暗号スイートを使わないことに越したことはないです。
ただ、そもそもそうした内容をよく理解していないし、気にしたくないという理由でFirebase Hostingを採用する人も多いとは思います。
WEAKな暗号スイートの利用がありつつも、どういうリスクがあって、どういう場合なら問題ないのか?などの検討材料になれば幸いです。
参考文献
- # TLS | SSLハンドシェイクのプロセスは?
- TLS/SSL (Schannel SSP) の暗号スイート
-
TLS暗号設定ガイドライン
- IPAが出している資料
- セキュリティの歴史的な変遷や、SSL1.2とSSL1.3の違い(どの通信から暗号化するか等)がわかりやすい
Discussion