kdnakt blog

hello there.

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

TLSらじお SSL/TLS

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

[TLSと商標]

こちらのツイートから。

SSLは多分最初の開発元のNetscape社の商標だったっぽい。以下の質問サイトの回答で、商標の問題があったため、IETFがSSL3.0を独自の標準として定める際にTLSという新たな名前を付ける必要があったのではないか、と言われている。

serverfault.com

プロフェッショナルTLS＆PKI 改題第2版ではSSLからTLSへの名前変更について、以下のサイトを引用してマイクロソフトの意向で名前を変えた、と書かれている。商標の話には言及がなかったので気にしたことなかったけど、商標問題も関係していたのかもしれない。

tim.dierks.org

[X.509の代替公開鍵/署名]

こちらのツイートから。

リンク先はこちら。

wolfssl.jp

subjectAltPublicKeyInfo、altSignatureAlgorithm、altSignatureValueなどの拡張で、2つの署名アルゴリズムを耐量子暗号への移行に利用できるとのこと。これをwolfSSLの最新版でサポートしたらしい。

ハイブリッド証明書のインターネットドラフトで似たような拡張が提案されていたような？と思っていたら、ちょうど2023年10月にドラフトが更新されていて、IETFじゃなくてX.509規格を定める国連期間ITU-Tの方で2019年に上記の拡張が部分的に採用されていた。X.509何もわからん...。

datatracker.ietf.org

しかもITU-TのX.509の資料はなぜか厚生労働省のサイトで公開されている。謎だ...。

[その他のニュース]

▼OpenGFW

こちらのツイートから。 

リンク先はこちら。

github.com

中国のGreat FirewallをGoで実装したOSS。TLSハンドシェイクのSNI情報やHTTPリクエストのHostヘッダを見て特定のサイトへの接続をブロックしたりできる。

▼ECS Service Connectの暗号化

こちらのツイートから。

リンク先はこちら。

aws.amazon.com

ACMのプライベートCAを利用してECSのサービス間通信を暗号化できる機能がリリースされた。

docs.aws.amazon.com

こちらのドキュメントによるとTLS1.3のみのサポートで、TLS1.2はサポートされないらしい。

▼OpenSSL CVE-2024-0727

こちらのツイートから。

リンク先はこちら。

www.openwall.com

PKCS12形式、そんなに使われてないこともないと思うんだけど、なぜ修正前に公表されたのかは謎。

▼pure-Rust X.509 validator for Python

こちらのツイートから。

リンク先はこちら。

blog.trailofbits.com

OpenSSLでもたまにバグが出てる証明書まわりの実装を、RustでやってPythonで使えるようにしたとのこと。pyo3というクレートを使うと、Rustの関数をPythonで呼べるようになるらしい。謎技術だ...。

github.com

▼Matter証明書の失効サポート

こちらのツイートから。

リンク先はこちら。

aws.amazon.com

Matter証明書の失効をサポートするようになった、とあるがそもそもMatterプロトコルとは...？Wikipediaによると、IoTの相互接続性のための規格っぽい。デバイスを識別するための証明書があって、それを失効させるということらしい。IoT機器の証明書管理とかどうなってるんだろう....。

ja.wikipedia.org

▼古いメールクライアント

こちらのツイートから。

リンク先はこちら。

www.value-domain.com

TLS1.1以下の古いプロトコルが現役だったらしい。まあdocomoでも2023年9月までは使えていたし、やはり互換性の方が重視されるんだな...。

www.docomo.ne.jp

▼Chrome/Firefox on iOS

こちらのツイートから。

リンク先はこちら。

gigazine.net

EUの要請でレンダリングエンジンがWebkit以外のものを利用するようになるとか。証明書ストアもChrome独自のものになるのだろうか？

▼Q4 2023 Summary from Chrome Security

こちらのツイートから。

リンク先はこちら。

groups.google.com

TLS関連だとこの辺の話題が。

Chromium Blog: Protecting Chrome Traffic with Hybrid Kyber KEM

TLS Trust Expressions

draft-davidben-tls-merkle-tree-certs-01 - Merkle Tree Certificates for TLS

Chromium Blog: Towards HTTPS by default

[暗認本：40 DNS]

『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』より、Chapter 8 ネットワークセキュリティのセクション40をまとめた。

  • 権威DNSサーバとキャッシュDNSサーバ
    • DNSは階層的にドメイン名とIPアドレスを管理
    • ルートサーバ：TLDを振り分け
    • 権威DNSサーバ：jpやco.jpを管轄する
    • キャッシュDNSサーバ：権威DNSサーバの問い合わせ結果をキャッシュとして保持
  • キャッシュ・ポイズニング
    • DNSでは主にUDPを利用（平文、誤り検出機能なし）
    • ドメイン名に対応する偽のIPアドレスを送ってキャッシュをコントロールする攻撃
    • 2008年Kaminskyによって効率的な攻撃が発見
  • DNSSEC
    • DNS応答が正しい（ポイズニングされていない）ことを確認する技術
    • 権威DNSサーバが返す値に署名を付与、キャッシュDNSサーバが署名を検証
  • パブリックDNSサーバ
    • 自宅では通常ISPのDNSサーバを利用
    • 会社などでは組織限定のDNSサーバが稼働
    • GoogleやCloudflareはパブリックDNSサーバを提供
    • パブリックDNSではプライバシーの問題がある。また、国ごとのフィルタリングや経路最適化が難しい
  • DoTとDoH
    • DNSSECでカバーされないクライアント=キャッシュDNSサーバ間通信に秘匿性・完全性を導入する技術
    • DNS over TLS（RFC 7858, 2016年）とDNS over HTTPS（RFC 8484, 2018年）
    • DoTはポート853を利用、ファイアウォールに検知される
  • ESNIとECH
    • ClientHelloのSNI拡張でアクセスするサーバ名を伝えるが、暗号化されていない
    • DoT/DoHで接続したいドメイン名を暗号化してもClientHelloからバレる
    • 2018年CloudflareがEntrypted SNIを導入
    • 2021年現在、Encrypted ClientHelloの標準化進行中
    • 暗号化のためにHTTPSリソースレコードで公開鍵を共有
    • 2020年中国やロシアはTLS1.3+ESNIをブロック 
  • HPKE：Hybrid Public Key Encryption
    • ECDH鍵共有＋鍵導出関数(HKDF)＋AEADで構成
    • 1.ボブとアリスで楕円曲線の点Pを共有
    • 2.ボブは秘密鍵bから公開鍵bPを作りアリスに送る
    • 3.(鍵カプセル化)アリスは一時的乱数tを生成し共有秘密鍵をHKDF(tbP,tP,bP)とし、tPをボブに送る
    • 4.(鍵デカプセル化)ボブは共有秘密鍵を計算
    • 5.keyをAEADの鍵とする

[まとめ]

赤ちゃん向け暗号絵本があるらしい。

バースデーケーキの材料を混ぜて焼くのはハッシュ化...なるほど。

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