SRE 兼よろず屋の id:sora_h です。最近は本社移転プロジェクト をやっています。趣味は Web *1 です。
さて、クックパッドでは 2020 年 12 月に TLS 1.0 および TLS 1.1 (以後 "Legacy TLS") を廃止しました。
Legacy TLS は RFC 7457 でまとめられているような既知の脆弱性の存在などから、Chrome, Firefox といった主要ブラウザを含め各所でのサポートが打ち切られつつあります。また、現在では IETF においても Legacy TLS は deprecated と RFC 8996 にて宣言されました。
クックパッドでもセキュリティ対策およびレガシーな技術と向き合う一環で廃止を進めました。我々は歴史の長いサービスも提供しているため、古い Android や Internet Explorer などからのアクセスもありましたが、トラフィック傾向や各種ベンダーによるサポート状況を見ながら慎重に進めていきました。
全サービスでの廃止にあたっては関わる人数や影響範囲も大きくなるため、丁寧に進める必要があります。それはモチベーションの整理から新しい TLS 設定の検討といった下準備、design doc の作成とステークホルダーへの提案、そして実際の廃止作業といった短くない道のりを辿りました。本稿ではこの一連のプロセスについて振り返ります。
廃止のモチベーション
まず、Legacy TLS を廃止したいモチベーションとしては下記が挙げられます。
セキュリティ上のリスク: Legacy TLS は RFC 7457 に挙げられているように既知の脆弱性が存在する。その上、新たに深刻な脆弱性が発見された場合のリスクは低くない。コスト最適化: 一部サービスは非 SNI サポートに有償オプション *2 を必要としている。これは TLS 1.2 以上を前提とすることで、クライアントの SNI サポートも前提とできるため、Legacy TLS 無効化によりそのオプションを廃止できる。最新の技術やサービスを利用できない潜在的なリスク: TLS 1.2 以上や SNI を前提とする技術やサービスはこれから増え続けていくと考えられる。
特にセキュリティ上のリスクは現状よりも今後新たな脆弱性が発見された際のリスクを高く評価しました。2017 年に完全 HTTPS 化を行った際の理由 でも触れられていますが、我々はユーザーさんにセキュアなサービスを提供したいと考えています。
その一環として、2014 年に公開された SSL 3.0 の POODLE 攻撃 に対する対応を振り返ります。クックパッドでは脆弱性情報の公開後、速やかに SSL 3.0 を無効化しました。しかし、当時のトラフィック状況では唐突にサポートを打ち切るには時期尚早で、ユーザーさんへの影響が想定以上に発生してしまいました。そのため、再度有効化の上あらためて無効化に向けて動く対応を行ったことがあります。
この POODLE の教訓から、今後 Legacy TLS に重大な脆弱性が新たに見つかった時、我々は迅速にユーザー影響なしに無効化できるのか、という疑問が発生しました。セキュアなサービスを提供し続けることを考えれば無効化はせざるを得ませんが、一方で脆弱性の対応により突然クックパッドのサービスを利用できなくなってしまうユーザーさんの発生も避けたいです。そのため、早期に準備して Legacy TLS の廃止を進めるべきだと考えました。
また、最新の技術やサービスが利用できないことも大きな足枷となります。特にクックパッドのグローバル向けサービスでは Fastly をサイト全体の CDN として利用しており、Fastly がサービス全体での Legacy TLS 廃止を進めていたこと、また TLS 1.3 と Legacy TLS が排他だったのは大きな決め手でした *3 。
そして実トラフィックを確認すると、Legacy TLS の利用率は 2017 年で 3% だったところ廃止を提案した 2020 年 8 月頃では 0.5% まで減少していました。
また、同じ頃にクライアント (ブラウザ) でも Legacy TLS のサポートを打ち切る計画 *4 があり、徐々に無効化され始めていました *5 。これらも廃止を後押しする理由となります。
廃止のための準備
まずは前節で述べた理由を元に社内ブログへ所信表明を投稿しました。廃止のためにはエンジニアリングチームを含めビジネスサイドのステークホルダーの説得、またサポートチームの協力を得る必要があります。まずはやっていき宣言を発出した後、準備を整えて協力や意思決定を貰いに行くことにします。
トラフィック状況のモニタツールを用意
一言で廃止すると言っても、クックパッドは複数のサービスを提供していて、システムはその数以上に存在します。
Legacy TLS の利用状況についても、 Internet Explorer や古い Android からのトラフィックが存在しないような歴史の浅いサービスから、そうではないサービス、はたまた toB 向けに提供していて Chrome, Firefox, Edge といったモダンブラウザの割合が少ないサービスまで存在し、全体で一気に廃止するというのは良い判断ではありません。
そこでまずは SRE で状況を把握するため、また最終的にはエンジニアリングチームが各々判断できるようにするため、各システムのトラフィック状況をモニタするための社内ツール TLSitrep *6 を作成しました。
https://twitter.com/sora_h/status/1285189591096410112
TLSitrep では週次で ELB ログを集計し、その結果を閲覧できるようになっています。これはほぼ全てのシステムが AWS 上で稼動しロードバランサーとして ELB を利用していて、また全 ELB のアクセスログを Amazon Athena でクエリできるようテーブルとパーティションを自動で維持してくれる社内システムが存在しており、サクッと実装することができて便利でした。
新しい TLS 設定ポリシーと移行ガイドの作成
次に、廃止後に設定する cipher suite の方針などを決定しました。TLS 1.2/1.3 で利用することができる cipher suite から、Mozilla の Server Side TLS ポリシー , CRYPTREC GL-3001-3.0.1 *7 , NIST SP 800-52 Rev. 2 等を参考に検討します。具体的には下記のように定義しました。
Modern TLS: TLS 1.2+, AEAD (AES-GCM, ChaCha20-Poly1305), Forward Secrecy (TLS 1.2: ECDHE, 1.3: any)Moderate TLS: TLS 1.2, 非 AEAD, Forward SecrecyLegacy TLS: (Insecure TLS を除く) TLS 1.0/1.1, 非 AEAD, 非 Forward SecrecyInsecure TLS: SSL 3.0 以下 or AES/ChaCha20-Poly1305以外 or AEAD/HMAC-SHA256,384以外
ただし、実際には ALB では規定のポリシー の中から選択することになる他、CloudFront など CDN でも同様 となるため、この基準をそれにマッピングすると下記の通りです:
Modern: ELBSecurityPolicy-FS-1-2-Res-2019-08Moderate (推奨): ELBSecurityPolicy-TLS-1-2-2017-01Legacy: ELBSecurityPolicy-2016-08
TLSitrep においてもこの基準で集計しています。そして、変更した際のインパクトを把握しつつ移行先のポリシーがサジェストされるようにしました:
図: 表示される移行先ポリシーの提案 図: Cipher Suite 単位のアクセス傾向
また、ポリシーの策定にあたっては実際のクライアントからの接続可否と、影響の大きさを調査するため、 testssl.sh を用いて実際に各種 security policy を設定した ALB にテストを行い、念の為に実際の古い Windows や IE からもテストを行います。
実際のところ、ALB デフォルトの ELBSecurityPolicy-2016-08 から ELBSecurityPolicy-TLS-1-2-2017-01 へ移行した場合のインパクトは下記の通りとなりました:
Windows: 2009 年以前の PC は接続不可 (Windows Vista 以前)。
macOS: 2013 年 10 月以前は接続不可 (macOS 10.8 以前)。ただし同年リリースの Chrome/Firefox から TLS 1.2 が有効なので 10.8 以前でも OK の場合あり。
Android: 2013 年以前は接続不可 (Android 4.4.2 以前)。
iOS: 2011 年以前は接続不可 (iOS 5)。
iOS/Android 向けアプリ版ともに影響を受ける端末はすでにサポート対象外ですが、やはり実際のトラフィックでは初期の Android 4.x 系や古い Internet Explorer からのアクセスが影響範囲として目立つことが分かりました *8 。
また、前述のようにシステムによって傾向が違うことも明らかになりました。例えば cookpad storeTV の関連システムでは販売店舗等からのアクセスが多いためか、古い Internet Explorer や OS など Legacy TLS や非 FS/AEAD cipher suite の利用率が他と比べて目立っていたなどが挙げられます。
説明と説得のための design doc の作成
各所へ説明するため、モチベーションや移行手段、新しい TLS 設定について記載した design doc を作成しました *9 。この時点で、社内のセキュリティチームからもレビューを貰っています。
筆が乗ってしっかりした文章になってしまった *10 ため、最終的には事業部から「ここまでやってもらったらやるだけですね」などと評価されたようで、ちゃんと書いてよかったなと思っています。
また、国内他社事例などもできる限り調査して現状を記載しました。その際、 Yahoo! JAPAN さんの廃止 などはかなり参考にさせていただきました。
図: 用意した design doc の ToC と冒頭部分
アナウンスと説得
前節で用意した design doc を元に筆者が主体的にエンジニアリングチームやステークホルダーへ提案、意思決定を仰ぎました。
幸いにも Legacy TLS のトラフィックレートが十分低下しており、そして design doc でリスクと利点を説明、その他の準備でサービスチームの作業も最低限にしたことからスムーズに受け入れてもらえました。また、自分が動かずとも doc を抱えて他チームのマネージャが意思決定者まで話を持っていってくれる、事業側のエンジニアリングチームが実際の影響ユーザー数の算出を行ってくれるといった協力を貰う事ができたので、備えて良かったなと感じます。
cookpad.com ドメインでの廃止作業
無事に廃止が決まったため、残るは設定の移行作業となります。ここまでくれば技術的にはやるだけです。
基本的に design doc 上で合意済みの対応方針と移行方法をベースに全社へアナウンスをし、各チームに対応を一任しました。また、新規システムがデフォルトで利用する TLS 設定もこのタイミングで切り替えました。
その結果、速やかに無効化されていったようです (筆者はそれを毎週確認しているだけでした)。TLSitrep が変更先の設定を提案するようにした他、ポリシーも分かりやすく提示したため、変更作業としてはアナウンス通りに ALB 設定変更のデプロイで済むことがほとんどでした。前述のように廃止については受け入れられていたため、スムーズに廃止が進行しました。
そして、関わるチーム数が多い cookpad.com ドメインおよび PC およびスマートフォンブラウザ版クックパッド (以後 "レシピサービス") については筆者が実作業も担当しました。この節では以降、レシピサービスにおける Legacy TLS 廃止について説明します。
対象のユーザーさんへ警告を表示するための仕組み
まず、レシピサービスが他サービスと比較して大きなユーザー影響が見込まれたため、ユーザーさんへの告知が必要でした。
クックパッドのサービスは全て常時 HTTPS となっており、 Legacy TLS 廃止後は非対応の環境から完全に接続できなくなります。そのため、実際に接続できなくなるユーザーさんに対して、サポート外になる警告を表示しました。
具体的には、Legacy TLS 廃止後の SecurityPolicy を設定した ALB と CloudFront distribution を用意して、CloudFront への接続に失敗した場合 ALB へ接続試行、その結果を元に警告を表示する JavaScript を準備しました。
図: 警告のイメージ (実際にリリースした際は廃止日時が記載されていました)
この検証作業や前述の SecurityPolicy 接続テストの一環で Windows XP/IE6 や Vista/IE7 の環境も構築してみたんですが、Windows Update さえ実施できず本当に何もできない感じだったのが記憶に残っています。最新のパッチまで当ててたらもう少し何か出来たりするのかな.........。
サポートチームとの連携
以上の変更を抱えてサポートチームへも相談し、文言や問合せ等の対応方針を検討しました。ここでも最初の design doc で背景を理解してもらうのがスムーズに進み、やはり文章は便利だなという気持ちが強まります。
グローバルチームとの連携
cookpad.com ドメインはクックパッドのグローバル向けサービス と共有しているため、このドメインの Legacy TLS 廃止にあたってはグローバル側のサービスチームとも連携が必要でした。
こちらは歴史も浅く Web フロントエンドが古いプラットフォームでそもそも動かなかったりする他、iOS/Android アプリについても日本国内版に比べ古い OS のサポートを早期に打ち切っている関係で背景の説明をするまでもなく合意を得ることができました。
なお、日本国外からの cookpad.com ドメインへのアクセスは CDN として Fastly を経由するようになっているため、Fastly 側での設定変更を行いました。Fastly は CloudFront ほど柔軟な設定はなく、基本的に cipher suite についてはお任せとなります。TLS 1.0/1.1 を無効化し 1.2/1.3 のみとなった設定を準備しました。
Legacy TLS の無効化
告知から一定期間置いて、順次 Legacy TLS を無効化する設定をデプロイしました。念の為ブラウザ版で表示している告知へ誘導するため iOS/Android 版クックパッドアプリで利用されている API から先に無効化を進めましたが、幸い大きな混乱はなく廃止完了となりました。
cookpad.com ドメインにおける廃止が終わる頃には、他システムでも既に廃止が完了していたため、cookpad.com での廃止を以てクックパッドが提供するほぼ全てのサービス *11 で Legacy TLS の廃止が完了したことになります。
まとめ
図: Qualys SSL Labs にて A を獲得することができた様子
そして、このプロジェクトで用意した TLSitrep については維持し、ALB の SecurityPolicy が更新された場合速やかに新しい推奨設定を検討できるようにしています。直近では ALB の TLS 1.3 サポート *12 、非 AEAD/FS を許容する TLS 1.2 only の policy が来ないかな、などど思いながら過ごしています。
最後に繰り返しとなりますが、レガシーな環境や設定の存在はサービス提供者とユーザーさん双方のリスクとなるだけでなく新しい技術の足枷となりかねません。クックパッドは先に述べたように歴史の長いサービスで、サーバーサイドからクライアントサイドまでそれが起きやすい環境です。そんなクックパッドではレガシーな環境に立ち向かいながら新しい技術や industry standard へ積極的に追従する仲間を募集しています。 https://cookpad.jobs
謝辞
本プロジェクトは複数のチームの協力によって成り立ちました。また、特に古い環境向けの JavaScript をサクッと書いてくれた id:hokaccha 、TLS 設定や対応方針のレビューをしてくれたセキュリティチームの id:kani_b と id:mztnex (@m_mizutani ) にこの場を借りて感謝します。
