SHA-1はHMACで使う分にはまだ危殆化していないというのは記事の通り(その上でHMACでもSHA-2への移行を進める動きはある)
"In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition)."が原文なんですが、J-STAGEがそれに準拠するつもりがあった可能性は(恐らく)ないものの、例えばNSA Suite BやCNSA Suite準拠だとTLS_RSA_WITH_AES_128_CBC_SHAを外せる(はず。Mozillaのガイドラインがapplication profile standardと呼べるかどうかはともかく、NSAのそれは案件によってはapplication profile standardそのもの)
J-STAGEの件、TLS 1.2のSection 9でMUST implementとされているTLS_RSA_WITH_AES_256_CBC_SHAをサポートしていないのが問題と先程の記事には書かれていて、実際それをサポートしていればFirefoxでも接続できるらしいんですが、実は他ならぬMozillaのServer Side TLS Modern compatibility profileにもTLS_RSA_WITH_AES_256_CBC_SHAが入っていない(別にこの組み合わせが特に危険で外されているわけではなく、現在のModernだとECDHEを使わない組み合わせは一切含まれていない)
J-STAGEの件、Firefoxとの互換性云々はさておくとしても、forward secrecyが話題になってから何年か経ったのにDHE(TLS 1.2自身に含まれている)をサポートしない一方でAESのGCMモード(後から追加された)をサポートしていて若干謎
うーん、変えるならハードウェア出す前にという理屈はわかるけれどbitstreamのstabilizeとは一体という気持ちになる
AV1の互換性が早速飛ばされる可能性があるというソース
https://www.cnews.cz/video-kodek-av1-nahradi-nova-verze-av1-1-0-neni-kompatibilni/
セキュリティ強化なるほど
J-STAGEがFirefoxでのアクセスを遮断、日本の電子ジャーナルが世界から不可視となった日|Guest|note https://note.mu/note_s/n/n517ff243e083
Santa Clara に bridge, well, lake, cove 当たり全部あったりして