kdnakt blog

hello there.

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

TLSらじお SSL/TLS

2024年1月15日～2024年1月21日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第140回分。

[TLS ALPS: ACCEPT_CH]

こちらのツイートから。

リンク先はこちら。

groups.google.com

2020年に提案されそのまま期限切れを迎えたインターネットドラフトTLS ALPS（TLS Application-Layer Protocol Settings Extension）がある。

datatracker.ietf.org

詳細は@flano_yukiさんがブログにまとめてくれている。

asnokaze.hatenablog.com

通常、TLSのFinishedメッセージを送信してハンドシェイクを終えるまでHTTPなどアプリケーションレイヤに関連するデータをやりとりできない。ので、これをTLSハンドシェイク中で先にやりとりすることでスムーズにアプリケーションレイヤのやりとりができるようになるという。

ALPN（Application Layer Protocol Negotiation）というTLSの後に利用するアプリケーションレイヤのプロトコルを決定するためのTLS拡張がある。ALPSはこれとあわせて使う必要がある。実際の設定値はClientApplicationSettingsハンドシェイクメッセージで送信されるらしい。

今回Chromeに実装されようとしているACCEPT_CH（Client Hint）はWebページを表示するためのヒントとして、ユーザーエージェント情報などをクライアントからサーバに送るためのもの。

asnokaze.hatenablog.com 

ALPSドラフトは期限切れ以降動きがなさそうだけど、実装は色々と進んでいるっぽい。ハンドシェイクメッセージ増え過ぎててわけわからん...。

[Chrome Root Program 1.5]

こちらのツイートから。

リンク先はこちら。

docs.google.com

www.chromium.org

2024年2月15日以降、ルート認証局としてChrome Root Programに追加されるには自動化された証明書発行の方法（ACME）に対応していないといけないらしい。ただし、非自動の発行方法を禁止しているわけではなく、ウェブサイト運営者が自動化された方法を利用するのが必須というわけでもないとのこと。

 

[その他のニュース]

▼TLSでの認証付き暗号の限界

こちらのツイートから。

リンク先はこちらの論文。

TLS1.3の仕様策定前の論文で、認証付き暗号だけだと限界があるから鍵更新の仕組みがTLSに必要だって話らしい。the draft of TLS 1.3って出てきてて、引用されてる論文も2016年以前のものばかりだから、多分当時の議論だと思うんだけど、なぜ今出てきたのかは謎。

▼ひとくちPKI #63

こちらのツイートから。

リンク先はこちら。

podcasters.spotify.com

ちょうど1/23-26に、ひとくちPKIのホストの@hitok_さんが以下のシンポジウムで発表するらしい。耐量子暗号、軽量暗号、機械学習や深層学習による攻撃、などなど面白そうなテーマがたくさん。

www.iwsec.org

▼イギリスのオンライン安全法

こちらのツイートから。

リンク先はこちら。

www.nikkei.com

そういえばEUではeIDASが話題だったけど、イギリスは2020年にEUから離脱したんだった。社会のテスト間違えそう...。

▼CTログ新方式の提案

こちらのツイートから。

リンク先はこちら。

docs.google.com

Merkle Tree形式を使う部分は変えずに、Treeをログタイルとして分割することでより効率的に扱えるAPIを提供しようとする試みのよう。Merkle Treeなのは変わらないので、結局変な証明書が紛れ込んでCTログ全体がダメになるって事象は発生しそう...。

▼SSH3 with ACME

こちらのツイートから。

SSHは初回接続時に接続先ホストを確認する必要があるが、HTTP/3ベースのSSH3であればサーバ証明書での認証ができるので、初回接続のホスト確認が不要になるらしい。なるほど。

▼Fastly: OpenSSL to BoringSSL

こちらの記事から。

www.fastly.com

FastlyがOpenSSLからBoringSSL（GoogleがフォークしたOpenSSL）に移行したらしい。
BoringSSLはOpenSSLよりコード行数が半分くらいになってるのは驚き。やっぱりコード行数が少ない方が保守はしやすいよなあ...。

OpenSSLとの違いとして、リリースサイクルの差とかだけでなく、OCSPステープリングやCBCモードのサポート、TLSセッションの管理など機能的な差異にも言及されていた。

▼Firefox nightlyでハイブリッド鍵交換

こちらのツイートから。

Firefox nightlyで耐量子暗号と楕円曲線暗号のハイブリッド鍵交換が利用できるようになったとのこと。

ただ、Chromeの同じ機能が動くUbuntu 22.04では動作しない場合があったとの報告も。

▼AWS NLBの証明書サポート追加

こちらのツイートから。

リンク先はこちら。

aws.amazon.com

ALBだと4096ビットのRSA証明書もサポートされてるのに、NLBだと3072ビットまでっぽい。なんでだろう...。

docs.aws.amazon.com

[暗認本：39 前方秘匿性]

『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』より、Chapter 7 TLSのセクション39をまとめた。

  • 盗聴と秘密鍵の漏洩
    • RSAとAESのハイブリッド暗号を考える
      • ボブがRSA公開鍵を事前にアリスに共有
      • アリスがAES秘密鍵をRSA公開鍵で暗号化しボブに共有
      • アリスがAES秘密鍵で暗号化した平文をボブに送信
      • ボブはRSA秘密鍵で復号したAES秘密鍵を利用して平文を取得
    • RSAの秘密鍵が漏洩すると、過去の通信も復号されてしまう
    • 2013年エドワード・スノーデンがNSA(アメリカ国家安全保障局)による盗聴・保存・解析を暴露（PRISMプログラム）
      • FBIはスノーデンのメールを復号すべく事業者に秘密鍵提出を要求
    • 秘密鍵が漏洩しても過去の暗号文が保護される性質＝前方秘匿性Forward Secrecyが重視されるように
  • 前方秘匿性
    • DH鍵共有：毎回新しい秘密鍵を生成する
    • 1回のDH鍵共有の秘密鍵が漏洩しても過去の通信に影響はない
    • TLS1.3ではPRISMプログラムを受け前方秘匿性のない暗号スイートが削除された
      • ※0-RTTを利用する場合前方秘匿性がないケースがあるので注意

[まとめ]

HTTPもちゃんと勉強しないとダメかな...。

www.publickey1.jp

ランキング参加中
プログラミング