先週に続き、2022年6月27日～7月3日に読んだ中で気になったニュースとメモ書き（TLSらじお第63回の前半用原稿）です。
[AWSのTLS1.0/1.1廃止予定]
こちらのツイートから。
At AWS we almost never turn anything off, but TLS1.0 and TLS1.1 are on the chopping block!🪓Very few customers still use these versions, and you can check CloudTrail logs to see if you have any requests using them. https://t.co/9RYGuASrZU
— Colm MacCárthaigh (@colmmacc) 2022年6月28日
リンク先のこちら。
2023年6月28日でTLS1.0/1.1をAWSのエンドポイントについて利用できなくなるとのこと。まだサポートしてたんだ、というのも驚きではある。本文中の記載を信じるならば、95%がTLS1.2を利用しているとのことなので、あまり影響はなさそう。
それにしても、PCI DSSとかどうしてるんだろう？カード情報を扱うエンドポイントだけTLS1.2にしたとかなんだろうか。*1
CloudTrailのtlsDetailsフィールドでAWS API接続に利用されているTLSバージョンを確認できるので、影響の有無を確認しておこう。
[最近のTLS事情]
こちらのツイートから。
After last year’s insightful TLS report, @Scott_Helme takes another deep dive and provides us with his latest findings.
— Venafi (@Venafi) 2022年6月30日
Take a look at what's changed in the last 6 months and see if there are any new trends that have emerged ⤵️https://t.co/pw6susu8mZ#tls #cybersecurity pic.twitter.com/iodAWP3HLd
リンク先の記事はこちら。
この半年間での色々な変化が解説されている。
HTTPSが導入されていないサイトが25%程度あるらしい。意外と多い。
証明書についてはLet's EncryptのECDSA中間証明書からの証明書発行数が伸びているとか。
TLSバージョンの変化でいうと、TLS1.2の割合が減っているらしい。うちも早く対応しないとな...。
[Bulletproof TLS Newsletter #90]
新しいニュースレターが公開された。
トップニュースは先日取り上げたHertzbleed脆弱性だが、TLSへの具体的な影響などは書かれていなかった。気になる...。
細かいニュースはちゃんと読めていないが、いくつかはうちでも取り上げた内容が含まれていた。
[rakumail.jpの問題]
こちらのツイートから。
自由に取れそうでわろてる pic.twitter.com/JkouMkslcA
— ろ。まのふ (@kamiya344) 2022年7月1日
これはまさに『プロフェッショナルSSL/TLS』第4章で紹介されていた脆弱性で、SSL証明書の自動発行に使えるメールアドレスが簡単に取得できてしまいそう。
こちらのブログで危険なメールアドレスについて説明されているが、仕様としてまとまっているわけではなく、まだドラフト段階の様子。
[その他のニュース]
▼OpenSSLのリモートメモリ破壊脆弱性
こちらのツイートから。
OpenSSL version 3.0.4, released on June 21th 2022, is susceptible to remote memory corruption which can be triggered trivially by an attacker. https://t.co/1v2m6tzwIh
— Frank ⚡ (@jedisct1) 2022年6月27日
リンク先の記事はこちら。
何度目かの脆弱性修正版がリリースされたところに、さらに追加が...。OpenSSLで（特にその最新版で）HTTPSのサイト運用するのってかなり辛そう。
BoringSSLやLibreSSL、OpenSSL1.1.1は影響を受けないらしい。フォークされたOSSが多いとその辺の影響確認も大変そう...。
日本語でも記事が出ていた。
▼OCSPレスポンダのHTTPS化
こちらのツイートから。
プライバシー保護のためApple Developer IDのOCSPレスポンダがhttp[:]//ocsp[.]apple[.]comからhttps[:]//ocsp2[.]apple[.]comにHTTPS化されてたのね。知らんかった。 https://t.co/Jz23BSloBa
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年6月28日
リンク先のサイトはこちら。
接続先サイトの証明書の失効確認を行うためのプロトコルOCSPがHTTPSでなくHTTPであることによるプライバシーの問題については『プロフェッショナルSSL/TLS』でも指摘されていた。しかしHTTPSの安全性を確認するためにHTTPSを使う、となるとこのOCSPレスポンダの証明書の失効確認は一体どうやればいいんだ...?
macOSの中で特別に別口で失効情報を配信する仕組みでもあるんだろうか。
▼Hertzbleed解説
こちらのツイートから。
Hertzbleed explained https://t.co/QWUqe2DAYi 明日読む
— V (@voluntas) 2022年6月28日
リンク先のブログはこちら。
データによって計算量・電力使用量が異なる、というのがぼんやりとしかイメージできていなかったが記事中の画像（以下に引用）を見ると、スッと理解できた（気がする）。
▼同一の因数をもつRSA鍵
こちらのツイートから。
『Finding shared RSA factors in the Certificate Transparency logs』https://t.co/nwYHY441Xe (pdf)
— ゆき (@flano_yuki) 2022年7月2日
CTログから1億5900万の公開鍵を収集し、同一の因数を持つ鍵を探した。同じ因数をもつ8つの鍵をみつけたそうな。
リンク先のPDFはこちら。
意外と多いような、そうでもないような。
同じ因数を持つ鍵が漏洩すると自分のところも影響を受けるので、そういうのを気にしないといけないのは困る....。
[まとめ]
rakumail.jpの問題は見つけた時思わずツイートしてしまった。
sslcertificates@〜とかにするとドメインの証明書が発行できちゃうやつだコレ…プロフェッショナルSSL/TLSで読んだな https://t.co/2SP1aCXSuw
— KIDANI Akito (@kdnakt) 2022年7月1日
