kdnakt blog

hello there.

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

TLSらじお SSL/TLS

2023年6月5日～2023年6月11日に読んだ中で気になったニュースとメモ書き（TLSらじお*1第109回の原稿）です。

[HSTSプリロードの課題]

こちらのツイートから。

リンク先はこちら。

alexsci.com

ChromeはHTTP Strict Transport Security（HSTS）に対応して色々やってるのに、google.comが対応してないのは意外だった。やはり接続できなくなるリスクがあるのを避けているのだろうか...？と思っていたら、記事中で解説が。サブドメインのいくつか、たとえばGoogle MapsやBardなどがHSTSに対応していないため、親のgoogle.comではHSTSを使えない、ということらしい。
ポルノ系サイトについては、プライベートウィンドウ（シークレットウィンドウ）でのアクセスが多く、HSTSの設定が保存されないため、セキュリティの面では問題があると指摘されていた。セキュリティを取るかプライバシーを取るか...悩ましい。
アクセスの多いトップ20ドメインということで、TwitterやFacebookなどのSNSや、YahooやYandexなどの検索エンジンがランクインしてる中、docomo.ne.jpが19位に滑り込んでいたのがちょっと意外だった。

クライアントのHSTS対応状況についてもまとめられていた。ルートトラストストアのようにHSTSのプリロードリストを配布しているOSはなく、ブラウザ以外でサポートしているクライアントはcurlとwgetくらいで、OpenSSLですらHSTSをサポートしていないとのこと。

締めの言葉にあるように、HTTPS専用モードが普及していけば、HSTSプリロードは必要なくなっていくのだろう。

[xTLSいろいろ]

こちらのツイートから。

リンク先はこちら。

https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/

たしかに、RFC 8705とか見ても、Mutual-TLSと書かれているだけで、mTLSとは書かれていない。

datatracker.ietf.org

帯域幅の節約を目指すCompact TLSなんかは、インターネットドラフトの段階でcTLSと正式に略されているので、その部類だと思って普通に使っていた...反省。

datatracker.ietf.org

TLSの暗号処理とネットワーク処理の間にユーザー空間を使わずカーネルだけで処理することで高速化を狙うkernel TLSも、ErlangのフォーラムでkTLSと呼ばれているだけで、そもそも元の論文ではKTLSと全て大文字で表現されていた。

erlangforums.com

用語は正しく使いましょうorz

[その他のニュース]

▼ErlangのHTTPライブラリGunのバグ

こちらのツイートから。

リンク先はこちら。

zenn.dev

TLSのアラートプロトコルのハンドリング難しいな...。Erlangのsslドキュメントにも記載がない動作だったらしい。ドキュメント、大事。

▼マザーボードのアップデート

こちらのツイートから。

リンク先はこちら。

pc.watch.impress.co.jp

卵が先か鶏が先か問題。
TLSのサーバ証明書の失効チェックの際に、OCSPとかCRLの通信がHTTPになっているのと近い問題な気がする。

元のニュースを読むとダウンロードしたファイルの署名検証も追加されているけど、それだけで十分だったのでは...。

www.gigabyte.com

▼フィッシング対策GL改訂

こちらのツイートから。

リンク先はこちら。

www.security-next.com

www.antiphishing.jp

EV証明書の特別扱いがなくなってもう何年も経ちますからね。鍵マークがあるだけでは安全で言えない、書いてあるけど、Chromeは鍵マーク止めるって言ってるしね...。

参考：今週気になったTLS関連のニュース - kdnakt blog

ガイドライン中で、重要情報送信フォームのみHTTPSにして、サイト全体をHTTPSにしていないケースが指摘されている。20世紀じゃあるまいし、今どきそんなサイトあるんだろうか...?

▼HTTP/3の使用状況

こちらのツイートから。

リンク先はこちら。

blog.cloudflare.com

HTTP/3がRFCになって1年が経つらしい。ブラウザのHTTP/3利用は増加傾向とのこと。

CloudflareのAPIトラフィックはまだ大半がHTTP/1.1だが、この1年でHTTP/3の割合が倍増しているらしい。まだまだ割合が小さい理由として、curlなど主要なツールでのHTTP/3対応がexperimental扱いであることが挙げられている。なるほど。

▼QUIC to Mars

こちらのツイートから。

リンク先はこちら。

www.privateoctopus.com

ラウンドトリップタイム(RTT)が1分でテストしてうまくいったけど、実際に火星と通信する場合は最短でも3分以上、最大で22分かかるらしい。
こういう環境だったら、多少のセキュリティを犠牲にしてでも0-RTTを使わないとやってられないかもしれない。

▼Chromeのサーバ側SHA1署名サポート廃止予定

こちらのツイートから。

リンク先はこちら。

groups.google.com

2014年ごろにSHA-1署名の証明書は「安全ではないサイト」扱いとなった。とはいえ、Chromeで接続できなくなった訳ではない。

asnokaze.hatenablog.com

security.googleblog.com

デスクトップ版、Android版のリリース予定はバージョン117（2023年9月）とのこと。鍵アイコンやめるのと同時っぽい。

▼ACME is Uptime

こちらのツイートから。

リンク先はこちら。

www.acmeisuptime.com

トップページの「Why ACME?」のコンテンツの始まりが「Chromeが最近証明書の期限を90日にするって言ってるよ」だった。ACME使わざるを得ないだろうなあ。その前に一度ちゃんとプロトコルの詳細を勉強したいけどRFC読む元気がない...。

certbotとかacme.shなどのおなじみのツールに混じって、HashicorpのVaultがリストアップされていてちょっとびっくりした。APIキーなどのシークレットを保管するだけのツールだと思ってたけど、証明書の管理もできたのか...。

[暗認本：08共通鍵暗号]

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

  • 共通鍵暗号とは
    • 暗号化と復号で同じ秘密鍵を使う：対称鍵暗号とも。
  •  共通鍵暗号に求められる安全性
    • 強秘匿性：平文1ビットの変更が暗号文全体に影響するため、暗号文から平文の一部を推測することが非常に困難である性質
    • 選択平文攻撃への耐性：攻撃者が選んだ平文に対応する暗号文を入手して、別の暗号文の解読を試みる攻撃への耐性（強秘匿性）。古典暗号にはない性質。
  • 共通鍵暗号の種類
    • ブロック暗号とストリーム暗号。詳細は次節以降。

[まとめ]

HSTSの実情とか、ACMEプロトコルの詳細とか、まだまだ知らないことだらけだなあ...。

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

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