kdnakt blog

hello there.

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

TLSらじお SSL/TLS

2023年8月7日～2023年8月13日に読んだ中で気になったニュースとメモ書き（TLSらじお*1第118回の原稿）です。
全文を公開している投銭スタイルです。

[2030年暗号移行問題について]

こちらのツイートから。

リンク先の資料はこちら。

将来の2030年暗号移行問題（120ビット安全性：RSA3072など）を考える前に、2010年暗号移行問題（112ビット安全性：RSA2048、SHA-2など）の振り返りがついていて助かる。
2010年に向けては、RSA1024ビットの証明書が組み込まれたガラケーのサポートの問題があり、移行がなかなか進まなかったらしい。確かに自分がスマホ使い始めたのも2008年前後だった気がする...。暗号技術があらゆるITソリューションに加工されて組み込まれる「産業のコムギ」状態という話が面白かった。
そして、SHA-1からSHA-2の移行は、TLSのサーバー証明書についていえば2015〜2016年ごろまでかかっていたので、なんだかんだ言って予定は遅れるものなんだな...。その当時の話は一応ソフトウェアエンジニアの仕事をしていたので何となく覚えているようないないような。

ひるがえって、2030年問題。RSA2048などはヨーロッパでは2016年時点で既にレガシーメカニズム扱いらしい。とはいえヨーロッパでもまだ使われていて、受け入れ期限が最初の2020年から徐々に延期されているらしい。やはり予定はあくまで予定。

古い端末やOSとの相互運用性を保ちつつ安全性を維持していけるのだろうか...。

ちなみに、CRYPTRECシンポジウム2023では他にも高機能暗号についての講演もあったらしい。これはどのくらいTLSに絡んでくるんだろう...。

www.cryptrec.go.jp

[Q2 2023 Summary from Chrome Security]

こちらのツイートから。

リンク先はこちら。

groups.google.com

ゆきさんが触れている以外にも、HTTPSへのサイレントアップグレードの実験、BoringSSLを通じたハイブリッド鍵交換の実験、Chromeルートストアの安定稼働、e-Tugraルート証明書の削除、などが触れられている。

鍵アイコンもそろそろ見納めか...。

TLSと関係ないけど、個人的にはRustベースの機能が実験され始めているのも気になる。

こちらのツイートによると、2023年8月10日にリリースされた（つまりQ3の）Chromeでは、ハイブリッド鍵交換がフラグなしで利用可能とのこと。Chromiumのブログ記事によると、ClientHelloメッセージに1キロバイト以上のデータが増えることになり、プロキシやファイアウォールなどのTLSミドルボックスがエラーになるケースがあるとのこと。

[証明書のドメイン名詐称]

こちらのツイートから。

リンク先はこちら。

note.activetk.jp

確かに「普通は」ドメイン名を偽造できないけど、いろんな条件が揃えばできなくもない。上記ツイートではCSRのIDN（Internationalized Domain Name）」を利用しているっぽい。

CAを悪用するだけじゃなくて、CAによる誤発行やCAがハッキングされるようなケースもある。

その辺の話は『プロフェッショナルSSL/TLS』の第4章などに詳しい。

[その他のニュース]

▼mitmproxy v10 with HTTP/3

こちらのツイートから。

リンク先はこちら。

mitmproxy.org

あくまで実験的サポート、ということらしい。とはいえ、SSLKEYLOGFILEを出力してWireshark（やChrome, Firefox）と組み合わせて通信を復号できるのは良さそう。

▼MACsecでレイヤー2暗号化

こちらのツイートから。

リンク先はこちら。

aws.amazon.com

レイヤー1の光ファイバーの盗聴については先日取り上げた通り。TLSだけじゃなくて、いろんなレイヤーの盗聴対策があるんだな...。

kdnakt.hatenablog.com

▼TLS1.0/1.1非推奨化の浸透

こちらの記事から。

aws.amazon.com

Amazon Aurora 3.04でTLS1.3がサポートされている。MySQLのドキュメントによるとTLS1.3はMySQL 8.0.16（2019年4月25日リリース）からサポートされているらしいが、Amazon Auroraでのサポートが遅れたのは何か事情があったのだろうか...。

今回のリリースのベースになるMySQL8.0.28（2022年1月18日リリース）では、TLS1.0/1.1がサポートされなくなったらしい。既にMySQL 8.0.26で非推奨化されていたとのこと。RFC 8996が実際に反映されてくるまでに1年近くかかっている感じ。

最近見たところだと、WindowsでのTLS1.0/1.1がデフォルトでオフになったは2022年9月らしい。Microsoft Edgeでは既に2021年9月のバージョン94から無効だったらしいので、実質ほぼ使われることはなかったのでは、とも思う。

blogs.windows.com

▼AmazonのHSTS max-age

こちらのツイートから。

リンク先はこちら。

securityheaders.com

amazon.comのStrict-transport-securityヘッダのmax-ageの値が47474747になっている。何か理由があるはず、というScott Helme氏のツイート。確かに、『プロフェッショナルSSL/TLS』の第10章では1年（365日）＝31536000秒が推奨されている。何か理由がありそう...?
47474747秒は549日と11時間25分47秒に相当するらしい。1年半にはちょっと足りないっぽし、謎。

▼picotlsとfizzのAEGISサポート

こちらのツイートから。

リンク先はこちら。

github.com

picotlsはC言語でTLS1.3を実装したもの。ツイートされている@jedisct1氏がプルリクを出したらしい。AEGISについては先日のIETF 117でも解説があった。
素のAESはもはやあまり利用されず、AEGISやFAESTのように形を変えていくのだろうか...?

こんなツイートも。

FacebookのTLSスタックFizz、存在を知らなかった...。C++14でTLS1.3を実装したものらしい。FacebookアプリとかInstagramアプリとかで使われてたりするんだろうか？

[暗認本：17 暗号文の改竄とリプレイ攻撃]

引き続き、ニュース以外のメインコンテンツとして『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んでいく。
今週はChapter 3 共通鍵暗号から、セクション17をざっとまとめた。

  • 暗号文の改竄
    • 平文m=1010（10進数で10）、秘密鍵s＝0101
    • 排他的論理和を取ると暗号文c=1111
    • 改竄された暗号文c'=0001を復号するとm'=0100（10進数で4）
    • ワンタイムパッド、ストリーム暗号、CTRモードなどを攻撃可能
    • 安全な通信には暗号文改竄攻撃も対策必要
      • メッセージ認証符号、認証付き暗号
  • リプレイ攻撃
    • 攻撃者が暗号文を丸ごと盗聴し再送
      • ログインや購入注文が成立するかも
    • 識別子(通し番号や時刻)のチェックが必要

[まとめ]

TLS1.0/1.1がどんどん使われなくなる一方で、TLS1.3もAEGISやKyberなどの新しい要素技術を取り入れつつあって、日々進歩が感じられます。

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

※以降に文章はありません。投銭スタイルです。

*1:TLSらじおは社内勉強会です。このブログを読み上げつつ弊社サービスの実情を語ったりします。

この続きはcodocで購入