kdnakt blog

hello there.

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

TLSらじお SSL/TLS

2023年1月23日～2023年1月29日に読んだ中で気になったニュースとメモ書き（TLSらじお第90回の前半用原稿）です。

[その証明書、安全ですか？]

こちらのツイートから。

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

eng-blog.iij.ad.jp

HTTPSが一般的にはなってきたものの、本当に安全か？という話。

オレオレ証明書を信用してしまったMyEtherWalletの件、証明書発行時の認証経路をハイジャックしたCeler BridgeとKLAYswapの件、ドメインがハイジャックされたCoincheckの件、いずれも2018年から2022年と最近の事例で、仮想通貨事業者がターゲットになっている点が興味深い。わざわざ手の込んだことをするからには、やはりお金が目的ということか。
MyEtherWalletのケースはともかくとして、本物の証明書が使われているCeler BridgeとKLAYswapのケースは自分も引っかからない自信がない...。

それにしても、経路ハイジャックはBotが毎日検出してTwitterにつぶやいてるなんて意外だった。恐ろしや。

[RSAの安全性評価]

こちらのツイートから。

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

pr.fujitsu.com

この記事を受けて、海外のサイトでもこんな記事が。

arstechnica.com

今回使われた量子シミュレータは39量子ビットらしい。

現在一般的な鍵長（注3）2,048ビットのRSA暗号の解読には、およそ1万の量子ビットと、およそ2兆2,300億の量子ゲートもの膨大な規模を有する誤り耐性量子コンピュータが必要なことが判明しました。これは、試算すると約104日の間、量子ビットを誤りなく保持する必要があり、現状、このような大規模かつ長時間にわたり安定稼働する量子コンピュータの実現は短期的には困難であることから、RSA暗号がショアのアルゴリズムに対して安全であることが定量的に証明できました。

とはいえ、IBMのロードマップでは2025年に4000量子ビットという話だったので、CRYPTRECの資料にあるように、2030年までにはやはり2048ビットのRSA鍵の証明書はやめておいた方が無難そうに思う。近年のAIの加速的な発展をみていると、同じような展開が暗号の分野でもないとは言い切れなそうなので。

qiita.com

英語の記事の方では、2020年のCraig GidneyとMartin Ekeråの研究と比較して、今回の富士通の発表の量子ビットが、論理量子ビットなのか物理量子ビットなのかで評価が変わってくると書かれていた。「（何十年も先なので）我々が生きてる間には問題ないだろう」とも。とはいえいつか終わりを迎えるのなら、早めに見切りをつけておいても悪くないはず。20年後ならまだ普通に仕事してそうだし...。

[その他のニュース]

▼CVE-2022-34689続報

こちらのツイートから。

リンク先はこちら。

www.akamai.com

2022年の11月に取り上げたWindows CryptoAPIの脆弱性を悪用する手法が発見されたとのこと。証明書を一度検証した後で、MD5ハッシュをキャッシュのキーにしてしまったため、衝突が起きる証明書で証明書検証を突破できるらしい。
パッチは2022年8月に提供されているのであまり問題はないと思うが...。

kdnakt.hatenablog.com

▼新しいRRの増加

こちらのツイートから。

SVCB/HTTPS RR (ドラフト)然り、CAA RR (RFC 8659)然り、TLSA RR (ドラフト)然り。2009年にRFC 5507でTXT RRを使わないで新しいRRを作ろうという話になったので登場したらしい。
その割にメールの認証で使われるDMARC (RFC 7489)はTXT RRを使っている。関連するSPF (RFC 4408, 7208)がTXT RRだからそちらに合わせたのだろうか。

▼OpenSSLのRFC 7250サポート予定

こちらのツイートから。

リンク先はこちら。まだドラフトのプルリク。

github.com

RFC7250はTLSのハンドシェイクプロトコルのCertificateメッセージで、X.509以外にも生の公開鍵を直接送信できるようにする仕様。従来オレオレ証明書が仕方なく使われていたようなケースで、公開鍵を直接利用できるようにしたもの。
確かにこの仕様の前のTLS1.2と後のTLS1.3でCertificateメッセージの形がかなり変わっていた*1。

// TLS1.2
opaque ASN.1Cert<1..2^24-1>;

struct {
  ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;

// TLS1.3
enum {
  X509(0),
  RawPublicKey(2),
  (255)
} CertificateType;

struct {
  select (certificate_type) {
    case RawPublicKey:
      /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
      opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
    case X509:
      opaque cert_data<1..2^24-1>;
  };
  Extension extensions<0..2^16-1>;
} CertificateEntry;

struct {
  opaque certificate_request_context<0..2^8-1>;
  CertificateEntry certificate_list<0..2^24-1>;
} Certificate;

▼TLS接続の分類

こちらのツイートから。

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

https://www.sciencedirect.com/science/article/pii/S1389128622005011

暗号化されたTLS接続の大規模なデータセットを作り、ニューラルネットワークを利用して未知のWebサービスへの接続を見極められるようになった、らしい。正解のデータはTLSのSNI情報を元にラベル付けしたとか。
Encrypted Client Helloへの対応としては、TLS復号プロキシなどでデータセットを集める必要があるとのこと。企業内ネットワークでのマルウェア対策とかには良さそう。

[まとめ]

証明書まわり、やっぱり全然理解できてないなあ...。

*1:昔はX.509の他にOpenPGPも利用できたが、TLS1.3では使えなくなっている。