kdnakt blog

hello there.

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

TLSらじお SSL/TLS

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

[Timing Oracle in RSA Decryption (CVE-2022-4304)]

こちらのツイートから。

リンク先はこちら。

mta.openssl.org

RSA証明書が利用されている場合、クライアントは生成したプリマスターシークレットをサーバの公開鍵で暗号化してClientKeyExchangeメッセージで送信する。
このとき、ネットワーク上でパケットを観察できる攻撃者は、パケットを加工してサーバに送信し、レスポンスの処理時間を計測することで、プリマスターシークレットを復号できるらしい。相当回数の試行が必要そうだが、成功した場合、通信内容が丸見えになってしまう...。

他にも、OpenSSLをクラッシュさせる脆弱性がいくつかと、メモリへのアクセス可能な脆弱性があったらしい。

という話もある。文脈は違うが、以下のツイートが思い出された。

[Certificates without PKIX]

こちらのツイートから。

ワーキンググループのサイトはこちら。MLのやりとりなどが閲覧できる。

www.ietf.org

CBORは知らなかったけどRFC 7049で定められたConcise Binary Object Representationのことらしい。
以下の記事によればJSONと違ってバイナリなので高速化されIoTの世界などで役立つらしい。

qiita.com

CBOR Playgroundで遊んでみたところ、こういう感じに変換された。

WGのメーリスでのやり取りを見ていると、IoTの世界でもECDSA/EdDSAの証明書にしてサイズを小さくすることで十分やっていけてるという意見もあるみたい。あとは既存のX.509証明書との互換性などを気にする意見も。

どうなることやら...。kjurさんはちょっと違う意見みたい。

[ChromeのTLS拡張ランダム化]

こちらの記事から。

www.fastly.com

TLSフィンガープリントについては2022年9月5日の本ニュースで触れた。

kdnakt.hatenablog.com

ChromeがTLS拡張の送信順序をランダムにする予定であると発表した点については、本家のBulletproof TLS Newsletterで取り上げられたのをピックアップしていた（2022年12月12日）。しかしこういう影響があるとは考えていなかった...不覚。Chrome 110でリリースされる予定だったのが、Chrome 108で有効化されたらしい。
記事の筆者によれば、ランダム化を考慮してTLSフィンガープリントを特定する新しいアルゴリズムが開発されるかもしれない、とのこと。

Firefoxも同様のオプションの実装を計画しているとのこと。

bugzilla.mozilla.org

[その他のニュース]

▼韓国の銀行TLS事情

こちらの記事から。

palant.info

2023年1月9日の本ニュースの続報。銀行のセキュリティアプリがOSのトラストストアに独自の認証局を追加しているので悪用が心配とのこと。
中には2099年まで有効なルート証明書も入っていて、通常はWebサーバ認証やクライアント認証といった必要最低限のもののみ指定されるExtended Key Usage拡張はフル指定になっており、メール署名やタイムスタンプにも利用できるとのこと。
しかも該当のアプリをアンインストールしてもトラストストアからは証明書が削除されないらしい。お行儀がよろしくない...。

基本的にローカルで動作するWebサーバのための証明書を発行するためのものなので、インストール時に秘密鍵を生成するなどの対策が望ましい、とのこと。なるほど。

▼QUICでDPDK

こちらのツイートから。

リンク先はこちら。CSの修士論文ってこういうことやるんだなあ（文系の感想）。

dial.uclouvain.be

Data Plane Development Kitの略で、オープンソースとして公開されている高速パケット処理用のライブラリとネットワークドライバのセットです。（略）DPDKで作成したアプリケーションは、システムコールを介することなく直接ハードウェアを制御できるため、より高速に動作することができます。

www.ntt-tx.co.jp

本論文では、古典的なクライアント/サーバ構成のQUIC接続が3倍高速化された（20GBのダウンロードのスループットが5 Gbpsから15.6 Gbpsへ改善された）とのこと。いろんな高速化手法があるなあ...。
しかし、QUICの名前の割にTCP+TLSスタックの方が早いってのはちょっと驚き。

▼軽量暗号Ascon

こちらのツイートから。

NISTの発表はこちら。

www.nist.gov

csrc.nist.gov

軽量暗号というのは、そもそも現行のNIST標準で定められた暗号の性能が許容できないほど悪いようなIoTなどの実行環境のためのAEAD（authenticated encryption with associated data）およびハッシュ機能を持つアルゴリズムらしい。インプラントのデバイスや、車のキーレスエントリーでの使用が想定されているとのこと。

Asconのサイトはこちら。

ascon.iaik.tugraz.at

2014年に開発されたAsconは、既にGitHub上でCやJavaなど各言語の実装が公開されている。

github.com

▼SSLErrorOverrideAllowed

こちらの記事から。

learn.microsoft.com

Edgeはセキュリティポリシーを配布することで、SSL証明書に関する警告を無視できなくできるらしい。

追加でSSLErrorOverrideAllowedForOriginsという設定を変更すると、特定のサイトのみ警告を無視できるようになるとか。それやるくらいなら真っ当な証明書用意するかSSL復号プロキシとか入れた方がいい気がするけど...。

▼NginxのQUIC+HTTP/3プレビュー

こちらのツイートから。

リンク先はこちら。意外とまだサポートされてなかったんだな...という気分。

www.nginx.com

nginx.confの設定例は以下の通り。

server {
    # for better compatibility we recommend
    # using the same port number for QUIC and TCP
    listen 443 http3 reuseport; # QUIC
    listen 443 ssl;             # TCP

    ssl_certificate     certs/example.com.crt;
    ssl_certificate_key certs/example.com.key;
    ssl_protocols       TLSv1.3;

    location / {
        # advertise that QUIC is available on the configured port
        add_header Alt-Svc 'h3=":$server_port"; ma=86400';
                
        #proxy_pass <upstream_group>; 
        #root       /<root_directory>; 
    }
}

[まとめ]

MITM攻撃で何ラーメン頼んだかバレちゃう...。