2023年12月25日～2024年1月7日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第138回分。
- [Cryptography & Security Newsletter #108]
- [DCV Inspector]
- [TLS1.3 Extended Key Update]
- [その他のニュース]
- [暗認本：37 TLS]
- [まとめ]
[Cryptography & Security Newsletter #108]
こちらのツイートから。
Bulletproof TLS Newsletter is now Cryptography & Security Newsletter! We'll bring you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. Issue 108 is now out!https://t.co/sKf0Mml2f0
— Feisty Duck (@feistyduck) 2023年12月29日
リンク先はこちら。
お馴染みBulletproof TLS NewsletterあらためCryptography & Security Newsletterという名前になった模様。今回のトップニュースはTerrapin攻撃とノルウェーのCAであるBuypassのインシデントの件。Buypassの件は、手動でドメイン検証をしたのが原因っぽい。発行される証明書の0.5%未満が手動によるものだ、と言われているが...。
今回のショートニュースで、取り上げてなかったのは以下のもの。毎週のニュースでだいぶカバーできてた。
[DCV Inspector]
こちらのツイートから。
It looks like @__agwa has given the WebPKI another gift. His new tool https://t.co/9Nn1cfnwz4 allows you to easily inspect the DNS, HTTP, and SMTP requests made by a certificate authority during domain validation.
— Ryan Hurst (@rmhrisk) 2023年12月31日
This is significant not only because we know some CAs fail to…
リンク先はこちら。
数々のCAのインシデントを検知してきた@__agwaさんの新作ツールDCV Inspector。「Start New Test」ボタンを押すとテスト用のドメインを生成してくれるので、そのドメインの証明書を対象のCAに発行依頼することで、CAによるドメイン検証時のDNSクエリやHTTPリクエストを調査できるらしい。
以下の画像はLet's Encryptによるドメイン検証の実行結果の一例。
開発の背景には、Cryptography & Security Newsletter #108で取り上げられていた、BuypassのACME処理が外部DNSリゾルバを利用した件が関係していそう。外部DNSリゾルバが委任された第三者機関（Delegated Third Party）なのが問題だと書かれていて、Delegated Third Partyという用語は証明書発行の要求事項を定めたBaseline Requirementsにも出てくる。が、具体的にどの条項に違反しているのかまでは読み解けなかった...。
Unfortunately, the majority of CAs are difficult to test. As a result, a lot of badness may be flying under the radar. Considerhttps://t.co/SLi2qug9Lu which was only detected because the CA offers a free ACME endpoint.
— Ryan Hurst (@rmhrisk) 2023年12月31日
[TLS1.3 Extended Key Update]
こちらのツイートから。
『Extended Key Update for TLS 1.3』
— ゆき (@flano_yuki) 2024年1月4日
PFSのあるKey Update方式の提案。ふむ。https://t.co/RB20IhST4u#yuki_id
リンク先はこちら。
新しいインターネットドラフトが出た。DH鍵交換を利用した前方秘匿性(PFS)のある鍵更新を利用できるようにする提案。産業用IoT機器などの長期間セッションが継続する環境などでは、application_traffic_secret_N（N番目のシークレット）が侵害された場合それ以降のトラフィックが盗聴される可能性があるため。
別途ドラフトとして提案中であるTLS Flags拡張をベースにしている。
TLS FlagsとしてExtended_Key_Updateフラグを追加し、KeyUpdateメッセージの代わりに新しいハンドシェイクメッセージの1つであるExtendedKeyUpdateメッセージを送信してDHパラメータをやりとりして鍵更新を行う。
トラフィックシークレットは以下のようになっている。ラベル（以下ではtraffic upd 2となっている部分）の仕様がいまいちよくわかんないけど...。
sk = HKDF-Extract(0, dh-secret)
application_traffic_secret_N+1 =
Derive-Secret(sk,"traffic upd 2",
application_traffic_secret_N)
ハイブリッド鍵交換のドラフトにも対応した仕様になっているっぽい。
[その他のニュース]
▼CT in reality
こちらのツイートから。
Now up, part II in my series about transparency systems: Certificate Transparency in Realityhttps://t.co/up36DIlLM3
— Eric Rescorla (@ekr____) 2023年12月25日
Of possible interest to: @estark37 @rmhrisk @sleevi_@Dennis__Jackson
リンク先はこちら。
Signed Tree HeadとかMaximum Merge DelayとかCT関連の用語の勉強になる。CTv2がRFC 9162として公開されて2年ちょっとが経ったが、ブログの筆者の知る限り誰も実装していないらしい。どうして...。RFC、たまにこう言うのがあるから困る。
▼ErlangでmTLSできない話
こちらのツイートから。
Erlang/OTP 26.2.1 で ssl ライブラリで TLS 1.3 と TLS 1.2 を指定して mTLS を利用すると接続できない場合がある https://t.co/syPTeWE98s 今年最後にしんどいバグを引いた話をまとめた。
— V (@voluntas) 2023年12月25日
リンク先はこちら。
TLSのバージョンごとに異なる署名アルゴリズムをもっていて、クライアントとサーバでTLSのバージョンがずれている場合に、署名アルゴリズムのチェックに失敗してクライアント証明書が送れないと言うことっぽい。デバッグ大変そう...。
▼QWAC or not QWAC
こちらのツイートから。
これは、後で熟読
— 松本 泰 (@yas_matsu) 2023年12月25日
QWAC or not QWAC is that the question?https://t.co/8Bzpv992or
新しいeIDAS規制に関するトリローグでの合意は先週達成されました。また、国際ブラウザのQWACを受け入れる義務も含まれています。これは、Mozilla、Googleなどでは受け入れられないと思われる義務です。
リンク先はこちら。
eIDASの信頼フレームワークを解説してくれてるけど全然頭に入ってこなかった...。
▼1409次元Classic McEliece解読
こちらのツイートから。
めちゃくちゃ削減してきたぞっ
— 菅野 哲 / GMOイエラエ 取締役CTO (@satorukanno) 2023年12月26日
---
世界初、KDDIが1409次元の暗号を解読。耐量子暗号に活用へ(アスキー)#Yahooニュースhttps://t.co/OMxbKBxGUO
リンク先はこちら。
耐量子暗号としてのClassic McElieceは3488次元以上がNISTの標準化候補になっている模様。
▼e-commerce monitoring GmbHのインシデント
こちらのツイートから。
In the context of eIDAS here is a nice self-labeled example of the "European approach" to incident responses in the WebPKI. https://t.co/GGFHUSCSkY But don't worry, the root cause is "no root affected".
— Ryan Hurst (@rmhrisk) 2023年12月26日
リンク先はこちら。
2023年2月に、e-commerce monitoring GmbHと言う認証局？がCTの事前証明書にSCT拡張を含めて登録してしまいRFC 6962に違反したとのこと。根本原因が問われているが対応が雑な感じ。これがeIDASを定めているEuropean approachなのか？とも...。
とりあえず、問題になってるルート証明書はMacBook Proのキーチェーンには入ってなかったのでヨシ。
▼HSTS対応状況2023.12
こちらのツイートから。
HSTSの対応状況って、どうなんだろう？と気になったので、ChatGPTに日本、EU、アメリカで主要な銀行をそれぞれ10組織を抽出してもらい、休憩がてら調査しました。
— 菅野 哲 / GMOイエラエ 取締役CTO (@satorukanno) 2023年12月27日
HSTSの対応状況をまとめると、日本60%、EU100%、アメリカ80%という結果になりました〜。
危なく組織名を晒すスクショを準備してたｗ… https://t.co/vdKj756psL pic.twitter.com/UmKljWXu13
確認ありがとうございます。
— 菅野 哲 / GMOイエラエ 取締役CTO (@satorukanno) 2023年12月27日
ご指摘のとおり、ヘッダだけ見て作成しておりpreloadは含んでないです。
EUの主要銀行を抽出したところHSTS（HTTP Strict Transport Security）対応状況は100%らしい。
▼QUICのWebサイトフィンガープリンティング
こちらのツイートから。
「QUIC website fingerprinting based on automated machine learning」
— ゆき (@flano_yuki) 2023年12月30日
暗号化されたトラフィックを観測して見てるサイト当てるやつ、QUICでもできるというペーパーhttps://t.co/VYwft2uaoF
リンク先はこちら。
https://www.sciencedirect.com/science/article/pii/S2405959523001662
パケット数やパケットサイズなどの特徴を元に、QUICのトラフィックを機械学習でどのWebサイトか特定することができるらしい。ECH（Encrypted Client Hello）でSNI（Server Name Indication）を暗号化しても、プライバシーの問題は完全には解決しなそう...。
▼Ethernet over HTTPS
こちらのツイートから。
いやーちょっとそれはやりすぎでは / “Ethernet over HTTPS Protocol” https://t.co/KHAHfmxj7n
— matsuu (@matsuu) 2024年1月2日
高度な認証の仕組みを使えることをメリットとしてるようですが、ブロードキャストフレームどうすんのとか色々気になるところではあります
— matsuu (@matsuu) 2024年1月2日
リンク先はこちら。
必要なのかなあ...。
▼災害時無料公衆無線LAN
こちらのツイートから。
災害時無料公衆無線LANの利用がNHKで紹介され、Wi-Fi暗号化がされていないことから「クレジットカード情報やパスワードなどの入力は極力、避けるよう」と呼び掛けられているが、10年前と違い、WebのHTTPS化がほぼ完了し、アプリのHTTPS通信もマストになっている現在、それを避ける必要はありません。 https://t.co/roINLCLZQz
— Hiromitsu Takagi (@HiromitsuTakagi) 2024年1月2日
フリーWi-Fiで攻撃を成立させる為の攻撃側の前提条件のハードルの高さと、攻撃される側がどれだけ無防備である必要があるかって徳丸先生の記事を引っ張ってきて、フリーWi-Fiは危険ってコミュニティノートを付けようとしてて、必死だなぁって思う。
— しの (@SH1N0) 2024年1月3日
攻撃の方法はいろいろあるけど、現実的な攻撃はHarvest now, decrypt laterくらいじゃないかしら。別に公衆無線LANに限った話じゃないし...。
ブラウザやOSのアップデートしてないケースだと危ない気もするけど、普通に新しめのスマホ使ってれば問題ないような。
この記事も読んだけど、公衆無線LANだから特に危険だってポイントはなかった気がする。
▼iPhoneアプリのTLS必須要件
こちらのツイートから。
急募。AppleがiPhoneアプリ審査の要件にTLS通信を必須にした時期。
— Hiromitsu Takagi (@HiromitsuTakagi) 2024年1月2日
初報では「2016年末を目処に」でしたが、このpostで準備期間を延ばすとしていました。実際に必須化された時期は未確認です。 https://t.co/VPOEjxidZh
— 某川(BOD 4.9mg/L)のフナ (@nknskn) 2024年1月2日
Arbitrary connection exceptions (NSAllowsArbitraryLoads)を使えば、現在でもATSを無効にできます。
— つっつー (@tu_no_tu) 2024年1月2日
ただし、App Store のレビュー中に、その設定が正当な理由を指定する必要があります。https://t.co/nFWLGd61j0
モバイルアプリのTLS通信の要件とかあるんだなー（それはそうか...）。全然知らなかった。
▼書評プロフェッショナルTLS&PKI
こちらのツイートから。
書評を書きました。 HTTPSへの安全意識が高まっている今だからこそ『プロフェッショナルTLS&PKI』を読みましょう。
— Shigeki Ohtsu (@jovi0608) 2024年1月5日
書評 プロフェッショナルTLS&PKI 改題第2版 (PR)https://t.co/f6DsYiQcXU
リンク先はこちら。
最近のTLS事情も併せて解説されていてわかりやすい。2016年とか、自分がTLSに興味持ってなかった時代のツイートやブログも引用されていて興味深い。
リアルTLSハンドシェイク演習、ちょっと面白そう。
▼IETFプロトコルバッジ
こちらのツイートから。
IETFプロトコルバッジのページ出来てたhttps://t.co/tEerWQVdTs pic.twitter.com/dF1LCDVx69
— ゆき (@flano_yuki) 2024年1月5日
リンク先はこちら。
IETF標準（RFCとか）の開発に貢献してる場合とか、プロトコルを実装した製品やサービスのプロモーションに利用できるらしい。同人誌とかに使っていいのかは謎。
[暗認本：37 TLS]
『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』より、Chapter 7 TLSのセクション37をまとめた。
- HTTPとHTTPS
- SSL/TLSの歴史
- Netscape Navigatorが開発したSSLが一般に普及
- 現在はTLS1.2が広く利用、それ以前のバージョンはブラウザで無効化
- TLS1.3が2018年に策定
- TLS1.3の特長
- 性能の向上 + 安全性の向上
- ハンドシェイクの効率化
- RTT回数の削減：TLS1.3ではServerHello直後から暗号化開始
- 暗号化されたメッセージの増加（EncryptedExtensions, Certificate）
- 暗号アルゴリズムの整備
- 新しい鍵導出アルゴリズム
- HKDF：HMAC-based Key Derivation Function
- HKDF-ExtractとHKDF-Expand(Derive Secret)を繰り返し、0-RTT用の鍵、クライアント/サーバ用それぞれのハンドシェイク鍵、アプリケーションデータ用鍵などを生成
- 型式手法formal methodによる安全性検証
- プロトコルをモデル化し、自動検証ツールで安全性検証（ProVerifなどのツール
- 定理証明：コンピュータと人間が対話しながら安全性証明（EasyCryptなどのツール
[まとめ]
年末から溜め込んだニュースが多くてまとめるのに一苦労。
暗号に絡めたクリスマスジョークが流れてきてたので共有。
A reminder to use HTTPS this holiday. https://t.co/vVHyRNFZFg
— David Adrian (@davidcadrian) 2023年12月24日
