2022年11月7日～11月13日に読んだ中で気になったニュースとメモ書き（TLSらじお第80回の前半用原稿）です。

[偽CA TrustCor?]

こちらのツイートから。

Oh look: a fake CA tied to a surveillance company. Nothing to see here. https://t.co/9pryrBMwvt
— Matthew Green (@matthew_d_green) 2022年11月8日

リンク先はこちら。

www.washingtonpost.com

ChromeやSafari、Firefoxのルート証明書ストアに名前を連ねているTrustCor Systemsという会社がある。自分のMacBook Proにも関連するルート証明書が3つ入っていた。

が、この会社の登録情報がスパイウェア企業のものと同じだったことがわかったらしい。既に10年以上アメリカの政府機関と取引があるとか。
同社はE2E暗号化をうたうMsgSafeというEメールサービスを提供しているが、そもそも暗号化されておらず、アメリカ政府にテロ容疑者に関する情報を提供していたとされている。
同社のVP of Operationsを名乗る人物によればこれは根拠のない主張だ、ということらしい。

ワシントンポストの記事中では、似たようなケースとして、2019年のUAE政府直轄のDarkMatterという会社が中間認証局からルート認証局になろうとした件や、プロフェッショナルSSL/TLSでも取り上げられているCNNIC（中国のルート認証局）がGoogleを騙る証明書を発行した件が触れられていた。

Mozillaが同社に対して対応を求めているらしいが、対応によってはルートストアから排除されたりするのだろうか。今後が気になるところ。

[サーバー証明書サイズ問題]

こちらのツイートから。

CTのための余計な情報入れるからですよ、、、、と、おっと誰かが来たようだ、、、、みなさんECC証明書使ってね、、、と。FQDN大量列挙のクラウドホスティング証明書もサイズがデカいですよね。 https://t.co/njUC6b13Xv
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年11月10日

リンク先はこちら。

arxiv.org

amplification limitってなにかと思ったらトラフィック増幅攻撃への防衛策として、QUICサーバはリクエストの3倍までしか最初にレスポンスに乗せることができないらしい。そのせいで証明書がレスポンスに入りきらず、35%のサーバーで無駄なラウンドトリップが発生しているとのこと。

datatracker.ietf.org

RFC 8879: TLS Certificate Compressionの背景にはその辺りもありそう。

[EV証明書の減少傾向]

こちらのツイートから。

Google intentionally killing EV certificates, illustrated: pic.twitter.com/VZ2YkS34HB
— Sam (@sam280) 2022年11月10日

引用元はこちらの資料の9ページ目。

https://www.enisa.europa.eu/events/trust-services-forum-ca-day-2022/presentations/chris-bailey-enisa-trust-services-forum-2022.pdf

EV証明書に対するブラウザの取り扱いについて、あまりちゃんと変化を認識できていなかったけどアドレスバーのグリーンがなくなったのと同時に組織名の表示がなくなった訳ではなかったっぽい。

[IETF115]

こちらのツイートから。

IETF 115 木曜日は、Supply Chain Integrity, Transparency, and Trust (scitt)と Transport Layer Security (tls) のザッピングで開始しております。

IETF115 scitt WG materials: https://t.co/p9EYBY37aO

IETF115 tls WG materials: https://t.co/MhqT8oKPdH
— 菅野哲 / GMOサイバーセキュリティbyイエラエ取締役CTO (@satorukanno) 2022年11月10日

TLSについてのアジェンダがこちら。

https://datatracker.ietf.org/meeting/115/materials/agenda-115-tls-06

TLS1.3の修正版RFCが検討されているっぽい。これにはTLS1.2実装に対する追加の要件も含まれている。extended_master_secretの拡張がextended_main_secretにリネームされたり。

ECHの設定を公開するための仕様も検討されていた。そういえばECHはまだドラフトのようだけど...。

SSLKEYLOGFILEの件も話されているみたい。

asnokaze.hatenablog.com

[その他のニュース]

そういえば出てました。トップはOpenSSLの脆弱性の件。

www.feistyduck.com

Office365のEメールのメッセージ暗号化でECBモードを使っていた問題が明らかになった。同じ平文が毎回同じ暗号文になってしまうため、ブロック暗号の中でも一番ダメなやつ...。でもMSは特に脆弱性とは認めておらず、修正予定もなく、CVEも発番されていないらしい。

DHEat attackが紹介されていた。

SHA-3のバッファオーバーフローの脆弱性があるらしい。PHP、Python、Rubyなどの実装の問題とのこと。

OpenSSL、LibreSSL、BoringSSLのパフォーマンス比較まとめが公開されていた。全般的に後発のBoringSSLが性能が良さそう。

▼ACMのECDSA証明書サポート

こちらの記事から。

aws.amazon.com

サポートしてなかったんだ...意外。
確かに昔のBlackBeltの資料を見ると署名アルゴリズムはRSA 2048のみとなっている。
インポートすればECDSA証明書も利用できたみたい。

プライベートCAでは元々できてたっぽい？謎...。

▼WordPressのis_ssl()関数

こちらの記事から。

thedailywtf.com

問題のコードはこれっぽい。

github.com

サーバー変数HTTPSの値が1かonの場合にHTTPSと判定しているが、PHPのドキュメントには空文字の場合にHTTPSと書かれている。残念な感じ...。

▼LibreSSLのQUICサポート

こちらのツイートから。

LibreSSL now supports QUIC. https://t.co/sl5eJo5lBu what TLS stack doesn't? OpenSSL, sigh. C'mon, guys (and they are all males).
— Rich Salz (@RichSalz) 2022年11月9日

WolfSSLに続いて、LibreSSLがQUICをサポートした。

undeadly.org

LibreSSLはBoringSSLと同じQUIC APIを実験的にサポートしたらしい。本家のOpenSSLだけが取り残された感じになっている。