kdnakt blog

hello there.

今週気になったTLS関連のニュース

TLSらじお SSL/TLS

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

 

 

[AdGuard DNSの部分的ダウン]

こちらのツイートから。

リンク先の記事はこちら。

adguard.com

AdGuardは広告ブロックツールを提供している会社。同社の提供している広告ブロック型DNSであるAdGuard DNSが部分的にダウンした原因がTLS証明書にあるという。
AdGuard DNSはGoで実装されており、新しくデプロイされた証明書がRSAだった結果、パフォーマンスに問題が発生したとのこと。おそらく下記の未解決のissueのものと思われる（起票は2017年、Go1.8の時代）。

github.com

TLSセッションは通常使い回されるので、最初は問題がなかったものの、BGP設定変更やサーバー再起動などの結果TLSハンドシェイクを伴うトラフィックが増大し、障害に至ったという。
記事では他に、AndroidのDoT（DNS over TLS）実装について、ネットワーク変更やエラーからの復旧の際に複数のテストクエリを実行する点にも問題があったとされている。
原因の特定から1時間ちょっとでDoT停止＋ECDSA証明書適用で復旧を完了していてすごい。

 

[curl-7.87.0：CVE-2022-43551]

こちらの記事から。

daniel.haxx.se

curlにIDN（Internationalized Domain Names、国際化ドメイン名）経由でHSTS（HTTP Strict Transport Security）を迂回する脆弱性があった模様。詳細はこちら。

curl.se

国際化ドメイン名といえば先日のOpenSSL 3.0系のCriticalの誤報の件を思い出す。

kdnakt.hatenablog.com

 

[その他のニュース]

▼Zig言語のTLS対応

こちらのツイートから。

Zigのissueはこちら。失敗しているビルドもあり、TODOもまだたくさんありそうなので、リリースは2023年になりそう（あるいはもっと先？）。

github.com

言語の発展に貢献していてとてもすごい。元になった時雨堂のリポジトリはこちら。

github.com

 

▼Chromiumのenforce_anchor_constraintsフラグ

こちらのツイートから。

リンク先はこちら。

chromium.googlesource.com

デフォルトではオフになっているenforce_anchor_constraintsフラグ（？）の挙動を変更し、basicConstraintsがある場合はCA=trueを必須としたらしい。
Chrome（108.0.5359.124, arm64）のフラグページ（chrome://flags）を見てもそれらしいフラグはなかったし、サーバー証明書の場合普通はCA=falseのはずなので、どういうタイミングで必要になるのかよく分からない...と思ったけど、トラストアンカー（ルート証明書）の検証時に利用されるソースっぽい。
フラグがオンになった場合、オレオレ証明書を使っているサイトで問題になりそう。

 

▼OpenSSL 3.1.0-beta1

こちらのツイートから。

リンク先はこちら。

mta.openssl.org

3.0.0からの変更として、コンパイル時の-DOPENSSL_TLS_SECURITY_LEVELを0に設定しないとTLS1.1以下が利用できなくなる模様。まあもう本番環境では使わないだろうし...。

www.openssl.org

レベルは最高で5まであり、レベル1＝80ビット安全性、レベル2=112ビット、レベル3＝128ビット、レベル4=192ビット、レベル5=256ビットとなっている。現在一般的な2048ビットのRSA証明書はレベル2相当。レベル5だとRSA鍵で15360ビット、ECC鍵で512ビットが必要となる。

(CRYPTRECの暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準 v1.0より)

 

▼RFC 9336

こちらのツイートから。

リンク先はこちら。

www.rfc-editor.org

拡張鍵用途（Extended Key Usage、EKU）にドキュメント署名（id-kp-documentSigning）を設定できるようになったとのこと。これまで、id-kp-emailProtectionやid-kp-codeSigning、ベンダーの独自定義のKeyPurposeIdを利用していたものを置き換える狙い。 
元になったRFC 5280はX.509証明書とCRLの仕様を定めたもので、拡張鍵用途として以下がリストアップされ、それぞれ対応する必須の鍵用途（Key Usage）としてデジタル署名や否認防止が挙げられている。

  • id-kp-serverAuth
  • id-kp-clientAuth
  • id-kp-codeSigning
  • id-kp-emailProtection
  • id-kp-timeStamping
  • id-kp-OCSPSigning

 

▼robot-detect

Bulletproof TLS and PKI, Second Edition、より。

github.com

2018年に問題が明らかとなったROBOT Attack（Return Of Bleichenbacher's Oracle Threat）の自動診断ツールがあるらしい。

robotattack.org

ROBOT AttackはRSA鍵交換におけるPKCS #1 v1.5のパディングエラーをオラクル（ヒント）として利用し、TLSサーバー証明書の秘密鍵を明らかにするもの。やはり前方秘匿性は大事ですね...。

 

▼イベント情報

こんな勉強会があったみたい。時間的に無理だから参加できなかったけど...CA/B Forum最新動向気になる。

他にはこんなイベントもあるみたい。2023年2月25日とちょっと先だけど、土曜日なのでライブストリーミングを聞けるかもしれない（忘れてなかったら）。

 

[まとめ]

2023年もTLSらじおをよろしくお願いします。