次世代Webカンファレンス 2019:HTTPSセッションが面白かった

以前から気になっていた「次世代 Web カンファレンス 2019」を、ようやく聴きに行くことができました。

たくさんのトークがありましたが、ここではHTTPS (hashtag: #nwc_https)をメモしておきます。なお、このセッションが間違いなく一番アツく、一番面白かったです!

以下、当日参加した、もしくは動画を見たという前提でのメモなので、見てない人はぜひ見ましょう。

PKI

「低レイヤから行きましょう」ということで、はじめはPKI絡み。Symantecのdistrustと、日本のGPKIの話でした。

トーク中に何度か出てきましたが、認証局(厳密にはCAとRAを分けて書くべきですが、どうせみんな一緒なので敢えてこの文章では分けてません。念のため)の基本要件となるCA/Browser ForumのBaseline Requirementsというドキュメントがあります。証明書を扱われる方は一読を。

Symantecのdistrust事件

細かい経緯は既に多く書かれているので省略します。

現在、Google ChromeおよびFirefoxでは、Symantecおよびその関連会社の発行したSSL証明書を利用したWebページは、エラーとなって表示できません。ここでは、Symantecの関連会社であるThawteとGeotrustの例がありましたので紹介しておきます。

これらのページをGoogle ChromeもしくはFirefoxで開くと、証明書エラーとなります。

f:id:ozuma:20190114232041p:plain

なおこのエラー画面のために、FirefoxChromeも、どちらもわざわざ固有のコードを埋め込んで実装しています。特にChromeFirefoxと違いブラウザ内にトラストストアを持っていないので、本来はOSの「信頼されたルート認証局」をトラストアンカーにするのですが、わざわざこのためのエラーコード NET::ERR_CERT_SYMANTEC_LEGACY を定義して証明書をチェックしています。

net_error_list.h:

// The certificate chained to a legacy Symantec root that is no longer trusted.
// https://g.co/chrome/symantecpkicerts
NET_ERROR(CERT_SYMANTEC_LEGACY, -215)

一方、Safari, InternetExplorer, Microsoft Edgeは通常通り表示されます。Googleのdistrust宣言に乗っていないからですね。

f:id:ozuma:20190114232947p:plain

ただしEdgeは将来Chromiumベースとなるため、将来は同じ挙動となります。その頃にはもう、Symantecの証明書はこの世に残っていないと思いますが。

トークでは皆さん遠慮して言ってなかったのですが、たかが(と敢えて書きます)一企業に過ぎないGoogleがdistrust宣言をすることで、巨大CAをあのようにいとも簡単に潰してしまうことが本当に正しいのか。私としては、むしろ「Google怖い」というのが素直な思いです。

この先、未来永劫Googleが正しい判断をして正しい行いをする保証などどこにもありません。Chrome/Chromiumが寡占状態になったとき、Googleに敵対する企業が認証局ビジネスをやっていたら……それでもGoogleは公正にふるまい続けるでしょうか。私にとっては、Certificate Transparencyと合わせて、「Google怖いな」という思いをすり込まれた思い出が残ります。

GPKI

こちらも、詳細はブログにまとめられている方がいらっしゃるのでそちらを紹介します:

GPKIは日本政府謹製の認証局でしたが、そちらの運用が上手く回っておらず、Firefox(というかmozilla)の信頼するroot CAから外されてしまったというものです。ここで問題視されたのは、失効処理(Revoke)です。

Baseline Requirementsでは、認証局は自身の発行する証明書に問題があるのではという報告を受けた場合、24時間以内に調査を実施し、問題があれば失効させなければいけません。しかしGPKI側は、「いや、どうせ待ってればExpireして失効するから、そのままにしておくという」という回答をしてしまいました。これでは認証局として適切な運用がなされていると判断できないため、GPKIはMozillaにroot CAと認められませんでした。

ただこの時のメールのやりとりを見ていると、担当者の方を責める気にはとてもなれません。私もかつてSIerで官公庁周りのシステムを触ったことがありますが、本当に神経を使いますし、そう簡単においそれとシステム変更などできません(証明書入れ替え、という定型作業であっても)。

GPKIがかつて使われていたところは現在、その多くはセコムの証明書を使うことで落ち着いています。実際、認証局の運用をわざわざ官庁でやる必要は感じられませんし、その費用を考えたらセコムから買った方が安いでしょうから、合理的な判断だと思います。

ちなみにアメリカの例では:

となっています。NSAがLet's Encryptというのは面白いですよね。

これからの認証局

司会のjxckさんからは、これからCAはどんどん減っていってしまうのではという意見が出ました。これはmozaic.fmでもおっしゃってましたね。EV証明書もなくなっていくかもしれない、認証局はとても高いセキュリティレベルが求められてちょっとでもミスると徹底的に叩かれる、このような状態で新規参入したいところも無いだろうし寡占状態となるのでは、と。

しかしこれに対して、むしろCAは増えている、というのはちょっと驚きでした。そういえば、確かにAmazonも始めていた。そしてGoogleですが……これはトークでも触れられていましたが、WebブラウザもOSも作っており、Webサービスもやっている企業が、認証局もやるというのはちょっと「おかしい」よなと私も思います。

あとEV証明書については、Stripe Inc、というキーワードだけ挙げておきます:

TLS 1.3

TLS 1.3については、確かに後方互換性を確保するために、これまでに無いパターンで大規模実験しながら作っていたなぁという感想です。実際、導入に乗り気であったFacebookは、わざわざ https://www.tls13.facebook.com/ というTLS 1.3テスト用の環境を用意しました。(これを使っていた人、どのくらいいるかな。RFCドラフト段階でテストするために作られたので、かなり前からあります)。

NW経路途中のファイアウォールやロードバランサなどのアプライアンスを引っくるめ「ミドルボックス」と呼びますが、これで叩き落とされないようにするため、TLS 1.3は一部にちょっと変なところがあります。

f:id:ozuma:20190114235756p:plain

例えばTLS 1.3のServerHelloは、Handshake時のVersionを0x0303(TLS 1.2)と応答します。ただしsupported_versionsというExtensionをくっつけて、この中でVersionを0x0304(TLS 1.3)と指定します。これは、一部のミドルボックスでServerHelloに素直にTLS 1.3と指定すると通らないことが分かったためです。このように、見る人が見ると「ツギハギ」に見えないことも無いのですが、そのぶんTLS 1.3は強力な後方互換性を持っています。

TLS 1.2は、そのまま残す。そしてTLS 1.3は改良していって、TLS 1.4, TLS 1.5...となっていくんじゃないかな」というの初耳で、なるほど~と思いました。一つの理由は、kjurさんのおっしゃったようにIoTデバイスなど。そしてもう一つの理由として、4maさんが強調されていましたが、セキュリティは常にalternativeが必要という観点。

これから先、TLS 1.3のプロトコル自身に致命的な脆弱性が見つからないとも限りません。だから何かが見つかってしまった場合、スイッチするために選択肢は最低2つ無いといけない。TLS 1.2はその命綱として生き続けるでしょう。

ちなみにTLS 1.3利用率の伸びは、kjurさんの作られているSSL Pulseをグラフ化したページで見ることができます。

TLS 1.3は現在10%ほどで、ほとんど横ばいです。ほぼFacebookトラフィックではないか、とのこと。

※上記↑、kjurさんより指摘いただき、「上記SSL Pulseのグラフはトラフィック数ではなく、サイトの数となります」とのことでしたので修正します。

SXG(Signed HTTP Exchange)

これも初めて聞いたときは、「怖い! Googleを批判する記事を、Chromeがわざとエラー出すことできる!」と真っ先に思った技術です。(私は陰謀論者なので、すぐにGoogleと陰謀を結びつけてしまうのです。ただのクセなのであまり本気に取らないでください)(こういう注意を入れないと、面倒な世の中なので)

確かにCDNからの配信でかなりアドバンテージあるとは思うのですが……。証明書がExpireしそうになったときの更新など運用面が、これまでからまるっきり違ってくるので、普及するとどういう世界になるのか正直よく分かりません。

参考リンクとして以下を挙げておきます。Turing Complete FMは面白いのでメッチャおすすめ。

量子コンピュータ

詳しく無いので、jovi0608さんのこのツイートが面白いので貼って済ませます。

素因数分解ができるのでRSA暗号が崩れるというのは有名な話ですね。AESなど対象暗号で、充分bit数を上げれば大丈夫、というのは理解があやふやだったので助かりました。

その他

ごはん

おひるご飯は重要です。大学周辺の飲食店は日祝休みとなるため、靖国通りまで出て前から気になっていた「黄金の塩らぁ麺 ドゥエイタリアン」というラーメン屋に行きました。

f:id:ozuma:20190115001359j:plain

ラーメン屋ですが店内はイタリアン風で、生ハムにチーズたっぷり、オリーブオイル仕立てのラーメンでした。チーズ好きな人は大歓喜でしょうが、私は、なんというか、アレですな、ラーメンは横浜に限りますな。

信頼

最後にjovi0608さんが信頼(Trust)について強調されていたので、誤解される方が出ないよう少し書いておきます。

少なくとも現在、たとえEV証明書であっても、「信頼」はあくまで技術用語としての信頼(すなわち、ある証明書を、ルート認証局の証明書からのチェインでちゃんと検証できる)という意味以上は持ちません。これは誤解を招かないように、CA/Browser ForumのEV SSL Certificate Guidelinesでも、Section 2.1.3の"Excluded Purposes"で、「EV証明書で目的としないこと」という節をわざわざ設けて説明しています。

このSectionでは、EV証明書のSubjectへ以下の4つを保証することを、EV証明書では目的としていない(だから、誤解すんナよお前ら)」と明記されています。

  1. That the Subject named in the EV Certificate is actively engaged in doing business; (実際にビジネスを行っていること:つまり、フィッシング目的などペーパーカンパニーではないこと)
  2. That the Subject named in the EV Certificate complies with applicable laws; (法律に準拠していること)
  3. That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; (信頼できる公正な商取引を行っていること)
  4. That it is “safe” to do business with the Subject named in the EV Certificate. (ビジネスを行って「安全」な相手であること)

(4は1-3で内包される気もするので、ちょっとしつこいですね)

ペットボトル

学生さんへのメッセージですが、見ての通りみんな普通にペットボトル置いてガブガブ飲んでいます。変なマナー講師の言うことを真に受けるのはやめましょう。

終わりに

大変に楽しくエキサイティングなトークでした。聞きに行って良かったです。発表者の皆さま、ありがとうございました。