(株)東芝でクラウドCoE部門を担当している安次富（あじとみ）と申します。普段はクラウドの活用推進や共通基盤的な社内サービスの企画・整備の旗振り役をしています。現業についてはまた別の機会に語らせて頂くとして、今回は、私が以前関わっていたW3Cの標準化活動について、振り返りと最新動向へのキャッチアップを兼ねて紹介させていただきます。
具体的には、私が７年前にW3C会員企業の有志で立ち上げた「W3C HTTPS in Local Network CG (Community Group)」(実質的には2020年活動停止) で当時考えていたことと、今年おなじ問題意識で立ち上がったW3CとIETFの2つの活動について紹介します。
解決策の方向性も含めて昔おなじようなことを考えていたんだよな、という話です。
はじめに
今年(2024年)9月に開催された W3C (World Wide Web Consortium) というWeb技術の国際標準化団体の年次会合 (W3C TPAC 2024) で以下の提案がなされました。
もう1つ、2024年11月末にはインターネット技術の国際標準化団体 IETF (Internet Engineering Task Force)でも類似のコミュニティ(Non-WG Mailing List) が立ち上がりました。
いずれも標準化の作業グループが正式に立ち上がっているものではないのですが、ローカルネットワーク上で正しくHTTPS/TLS通信を行うための方法を検討したい、という趣旨の提案です。ここで「正しく」と書いたのは、「TLSクライアント（Webブラウザ等）が、接続先のローカルネットワーク上のTLSサーバ（プリンタやホームルータ、IoTデバイス等）を信頼できる形で」ぐらいの意味ですが、この実現がなかなか困難です。
何が問題か
Webブラウザが信頼するサーバ証明書を発行するパブリック認証局は、CA/Browser Forum 規定 により、原則、パブリックDNSで一意性が確認できるサーバ名にしか証明書を発行できません。ローカルネットワーク上のデバイスのドメイン名（192.168.1.1、router.local、printer.home.arpaなど）に一意性はなく、パブリック認証局によるお墨付きをもらえないのです。結果、HTTPS/TLSが使えない、あるいは、Webブラウザ上に「信頼できない云々」の警告が表示されてしまう、という問題に直面してしまうのが現状です。
ローカル開発環境でHTTPSを使う話ではない
手動であれば解決方法はいくらでもあります。Web開発者であれば、自己署名証明書をつくったり、それをWebブラウザの証明書ストアにつっこんで信頼させたり、はたまた、Aレコードを127.0.0.1にしたパブリックドメインを用意し、ACME（Let's Encrypt等）のDNS認証でパブリック認証局から正当な証明書を取得したり、といった方法で、ローカル開発環境でHTTPSを使っているのではないでしょうか？ こういった話はスコープ外です。
一般ユーザでも扱える、ローカルネットワーク上で正しくHTTPS/TLSサーバとして振舞えるプロダクトを作りたい、そのためのプロトコルやシステムによる解決策を検討したい、というのが趣旨です。
7年前、私は同じ問題意識で W3C HTTPS in Local Network CG (Commuinity Group) を立ち上げ、ユースケースと要件 と ソリューション案 のドラフト文書を作りました。以下、この過去の取り組みを改めて振り返り、上記2つの新たな動きと比較してみようと思います。
7年前 ～ W3C HTTPS in Local Network CG
2017年、私が共同チェアの一人として、W3C加盟会社であるSONY、KDDI、ACCESS、そして JPRS（日本レジストリサービス）の有志と、「ローカルネットワーク上で正しくHTTPS/TLS通信ができない問題を解消したい」というモチベーションで W3C HTTPS in Local Network CG を立ち上げました。主な目的を CGチャーター から抜粋・要約します。
- Webブラウザとローカルネットワーク上のデバイス間の通信のセキュリティとプライバシーの向上。ローカルネットワークにおいても、インターネットと同様に、HTTPやWebSocket接続にTLSを適用することで、悪意のある傍受やなりすましを防ぐことが期待できる。
- Secure Contexts で動作するWebアプリケーションからの Fetch や XMLHttpRequest 、WebSockets 等を介したローカルネットワーク上のデバイスとの通信の実現。ローカルネットワーク上のデバイスがTLS通信できないと、Secure Contexts で動作する Webアプリケーションからは Mixed Content の制約により接続できない。Webブラウザが許容できるローカルネットワーク上でのTLS通信の方法を確立し、この制約を緩和したい。
2つとも似たことを言っていますが、後者はWebブラウザ仕様を意識した、クロスオリジンアクセスにフォーカスした書きぶりになっています。ここがポイントで、W3Cで取り上げるべき課題であるとの認識が共有できていた点も、立ち上げの理由としては大きいものでした。つまり、この問題の解決には何らかWebブラウザ関連の標準仕様の変更・拡張が必要なのではないかと考えていたということです。
以降、有志メンバで定期的な議論や勉強会を重ねたり、W3C TPAC（年次会合）で何度かのセッションを開催したりしながら、以下の2つのドキュメントを作成・公開しました。
- Use Cases and Requirements on HTTPS-enabled Local Network Servers
- Approaches to Achieving HTTPS in Local Network
興味のある方は各文書を読んでいただければと思いますが、以下、簡単に紹介します。
Use Cases and Requirements on HTTPS-enabled Local Network Servers
ローカルネットワーク上でHTTPS通信を使いたいユースケース・シナリオと、その裏にある要件をまとめた文書です。
ユースケース・シナリオは、CGの有志メンバで出し合ったものに加え、Github上で同じ問題意識を持つ海外の技術者がインプットしてくれたものも含まれています。全部で8つのシナリオがラインナップされていますが、今読み返しても、ホームルータ等の宅内デバイスが持つ Web設定画面のセキュア化シナリオ（UC-6）、宅内のストレージやメディアサーバをWebサービスのキャッシュに利用するシナリオ（UC-2）は、出来ると面白いのではないかな等と思ったりします。
要件については、機能要件・非機能要件を律儀に抽出・リストアップしています。主要な機能要件としては以下を挙げています。
- デバイスの信頼性保証：証明書検証などでデバイスの信頼性を確保できること
- デバイス識別：ローカルネットワーク内のデバイスを正確に識別できること
- ユーザ通知と同意取得：接続前にユーザに通知し、同意が得られること
- 証明書管理：TLS証明書を適切に管理できること
- デバイス発見（オプション）：ネットワーク内のデバイスを容易に発見できること
ちなみに、Github Issue に、取り込めていない幾つかユースケース・要望が残されたままになっています。また、1つのシナリオの中に本来は分離すべき複数のユースケースがつめこまれているものがある等、エディトリアルな修正が必要な個所もまだ残っており、文書自体もドラフト段階（Draft Community Group Report）という位置づけのままです。
Approaches to Achieving HTTPS in Local Network
本題です。ローカルネットワーク上で正しくHTTPS/TLS通信を行うための技術的なアプローチ（いわば、ソリューション案）をまとめた文書です。前述したユースケースと要件を前提に、スコープを定め、既存ソリューションと、それでは解決できない課題に対処するための3つのアプローチを提案した内容になっています。
既存ソリューション
実は、ローカルネットワーク上のデバイスをHTTPS/TLS通信可能にする既存のソリューションはあります。代表事例としては、PLEX や Mozilla の WebThings Gateway が挙げられます。しかしながら、いずれもパブリックDNSに登録されたグローバルユニークな名前をデバイスに付与する方式であり、以下の問題があります。
-
xxx.localやxxx.home.arpa等のローカルドメインを使いたいケースに適用不可 - パブリックDNSにローカルネットワークのデバイスの名前とローカルアドレスが登録されてしまうプライバシー問題
- インターネットアクセスがない場合のドメイン名解決が不可
- 膨大な数のIoTデバイスへの適用が、パブリックCAやCT (Certificate Transparency)を含むWeb PKIへ与える影響への懸念
この既存ソリューション（具体的には PLEXが採用するローカルデバイス用の中間CAを設ける方法）を CA/Browser Forum 規定上の根拠と共に整理した内容が、[APPROACH-1] です。
[APPROACH-1] Using Technically Constrained Certificates
パブリックCAがデバイスベンダにName Constraintな中間CA証明書を発行し、デバイスベンダが、technically constrainedな中間CA（EKUにserver-authを持ち、かつ、ベンダの管理ドメイン（例えば、.camera.example.com）に限定されたサーバ証明書を発行する中間CA）となることで、発行時にDNS検証を経ない、つまりローカルアドレスに紐づけられたデバイス名（例えば、<device-serial-no>.camera.example.com）への証明書が発行できることになります。PLEXのやり方はなかなか面白いので、興味のある人は上記リンクをご確認ください。
提案アプローチ
既存ソリューションの問題を解決する技術的アプローチが、APPROACH-2、3、4 です。2、3、4 と番号が増えるにつれて、凝った？（デバイスの信頼性の保証が高度になっていく）アプローチになり、自然と実現が困難な（新たに決めるべき標準化の範囲が広い）内容になっています。
[APPROACH-2] Using Shared Secret
一番カジュアルなアプローチです。Webブラウザとローカルネットワーク上のデバイス間のTLS通信の確立にPAKE（Password Authenticated Key Exchange）を使う方法です。
ユーザが Webブラウザでデバイスにアクセスする際に、Webブラウザ上に表示されたダイアログ（下図）に、何らかの方法で取得した（例えば、デバイスの画面に表示された）共有パスフレーズを入力します。Webブラウザは、これを用いて（PAKEベースの暗号スイートで）TLS接続を確立します。これにより、ユーザの明示的な同意を得て安全なHTTPS/TLS通信が行えることになります。
これをクロスオリジンでも行えるようにするためには、PAKEでTLS接続するためのパスワードを渡す Fetch APIへの拡張が必要になると考え、以下のような拡張案を例示しています。
このようなWebブラウザの仕様 や Web API仕様への拡張の必要性が見えていたので、W3Cで扱うべきと考えたところがあります。
[APPROACH-3] Using Application Layer Access Token
今読み直すと、かなりトリッキーというか実現性が微妙なアプローチなのですが一応。このアプローチは、基本的にローカルネットワーク上のWebブラウザで読み込んだWebサービスから、ローカルネットワーク上のデバイスにクロスオリジンアクセスするユースケースを前提としています。
OAuth の枠組みを前提とし、オリジン（Webサービス）がRP（Relying Party）、デバイスが RS（Resource Server）、デバイスベンダが インターネット上で AS（Authorization Server）を提供します。RPが、RSに対するアクセストークンを取得するOAuthフローの中で、アクセストークン（例えば、JWT）と共に、TLS接続に使うデバイスの証明書（デバイスの自己署名証明書など）を取得します（JWTの中に証明書が埋め込まれているイメージ）。
このようなフローを経て取得した証明書を用いたデバイスへのTLS接続を、ユーザ同意を前提に許可する拡張をWebブラウザに施すことで、ローカルネットワーク上でのWebブラウザからデバイスへのHTTPS/TLS通信を実現しようという提案です。
今読むと、面白くはあるのですが無茶な提案です。
[APPROACH-4] Using Device Authority-Issued Certificate
これも APPROACH-3と同様、ローカルネットワーク上でWebブラウザから読み込んだWebサービスから、ローカルネットワーク上のデバイスにクロスオリジンアクセスするユースケースを前提としています。さらに実現性が微妙なのですが、同じくOAuthの枠組みを前提としつつ、デバイスベンダが提供するASが、デバイス(RS)用のプライベートCA（ACMEサーバ）の役割を担い、RPがACMEクライアントの役割を担い、このフローによって発行されたデバイス(RS)の証明書を、RPの Secure Context 内でのみ信頼できるものとして Webブラウザにピン止めしてもらおうという提案です。
こちらも今読むとかなり無茶な提案ですね。
CG活動のクローズと振り返り
本活動の主要なコントリビュータであったKDDIの研究所の共同チェアと私が、本業の所属や役割が変わり、活動が難しくなったため、2020年には活動が休止状態になりました。正式なCGのクローズは2023年。私の場合、所属や役割が変わっても継続可能な立場ではあったのですが、優先度が下がり、次第に興味も薄れ、結果、上記２文書をドラフトのまま放置し、正式なCGレポートとして発行するに至りませんでした。
読み返すと、概ね盛り込みたかった内容は含まれており、多々粗はあるものの、あと少しの努力でCGレポート化できたように思えます。興味が高いうちに一気にアウトプットとしてまとめる動きをとるべきだったかなと今頃になって後悔しています。
一方で、Webブラウザベンダでなく、またWebサービスを事業の柱にしているわけでもない当社の立場でW3Cに貢献することを考えた時に、Webブラウザのユーザとしての立場で、Web業界のメインストリームから外れた困りごとを、ユースケースや要望・要件の形でインプットしていく・知らしめていくような本活動は、モチーフとしては良かったのではないかと考えています。実際、後述する後継の HTTPS for Local Network のセッションを主催したGoogle の技術者は、我々の過去のセッションを聴講してくれていたようですし。何らかのきっかけにはなったはずです。
ちなみに、CG活動は Github で行っていました。主要なディスカッションは各成果物（cg-charter、usecases、proposals）のリポジトリの中に見ることができます。
現在 ～ HTTPS for Local Network & SETTLE
今年新たに立ち上がったW3CとIETFの関連する2つの取り組みについて紹介します。いずれも2024年12月上旬の時点で正式な標準化作業グループになっているわけではなく、今後どうなるかはわかりません。
W3C: HTTPS for Local Network
HTTPS for Local Network は、2024年9月に開催されたW3Cの年次会合(W3C TPAC)のブレークアウトセッションで提案された取り組みです。参加者は、Google Chrome、Apple、Mozillaなど主要ブラウザベンダのエンジニアが多く参加し、活発な議論が行われたようです。
公開されている提案資料 によれば、主に以下の2つのアプローチが提案され、PAKEの方式が支持を集めたようです：
- TOFU (Trust On First Use)：初回信頼モデルで、デバイスが持つ証明書を信頼するかどうかをユーザに判断させるダイアログを表示し、許可を得るだけの方式
- PAKE (Password Authenticated Key Exchanges)：パスワード認証でTLS接続を開始する方式。パスフレーズ入力と同時にデバイスを信頼するかどうかを判断させるダイアログを表示する方式
同じW3Cの中の Second Screen WG でもローカルネットワークの問題を扱った取り組みがあり、このブレークアウトセッションの中でも情報共有がなされたようです。
ちなみに提案書には、以下のように我々の取り組みへの言及がありました。曰く、"かつて同じ問題を扱ったコミュニティグループがあったが、議論は止まっていてグループ自体も2023年にクローズされた。"
IETF: SETTLE (SEcure access with Tls To Local rEsources)
SETTLE (SEcure access with Tls To Local rEsources) は、2024年11月末に IETFで作られた Non-WG Mailing List です。まだ開設されたばかりということもあり、今後どのような議論が行われるか見えないところが多いです。現時点で、メーリングリスト上でのディスカッションから伺えることは以下の通りです。
- 問題のスコープは、HTTPS in Local Network および HTTPS for Local Networksと同じ
- ローカルドメインを対象にしたTLS通信の実現にフォーカスしている。パブリックCAを前提としたグローバルユニークなドメイン名を付与できるケースや、エンタープライズのプライベートPKIを前提としたケースは除外している
- ローカルドメインへの何らかの証明書発行の仕組みを志向している
- 少なくとの志向している参加者がいる
- 想定している典型的なユースケースも、HTTPS in Local Network と同じ
- ローカルネットワーク上のデバイスの管理画面へのHTTPSアクセス等、我々も典型的とみなしたユースケースが挙がっている
- まずはユースケースの収集・整理をする必要があると考えている
このIETF側の取り組みの関係者は、過去の我々の取り組みを知らないように見受けられるので、ユースケース文書やソリューション案の文書を一度シェアすることが何らかの貢献につながるかもしれないと感じました。ここは暇をみつけていずれ。
過去と現在の比較
まず、想定している問題のスコープと活動のゴールは、かつての HTTPS in Local Network も、現在の W3C (HTTPS for Local Networks）と IETF（SETTLE） も同じように見えます。
そして想定している解決策、これは HTTPS for Local Networks が今年の W3C TPACの中で素案として提示し支持得たアプローチは、かつて我々が考えた技術的アプローチの1つ（APPROACH-2）と同じでした。PAKEベースでユーザ同意を求める方式です。
画面イメージはほぼ一致しますね。
7年前：
現在：
一方、IETF（SETTLE）側の議論では証明書を前提とした手法への言及もあり、我々が考えた APPROACH-3 や APPROACH-4 のような、ローカルデバイスの信頼性をより強く担保する証明書ベースの解決策も視野に入ってくるかもしれません。
おわりに
ということで、ローカルネットワーク上で正しくHTTPS/TLS通信が使いたいお話でした。
当社はこれまで MPEG、Bluetooth、HDMI、IETFにおけるIPv6関連等々、符号化・通信・ソフトウェア系の様々な国際標準化に携わってきました。この 東芝 Advent Calender 2024 においても OpenChain Project (The Linux Foundation) への貢献が紹介 されているように、現在も標準化への貢献活動は続いています。
拙稿は、W3Cという当社にとっては本流ではない領域の話ではありましたが、当社の多様な国際標準化活動の一端が伝われば幸いです。