Microsoft が延期していた Internet Explorer (IE) と EdgeHTML のTLS 1.0 / 1.1 デフォルト無効化をついに実施するそうだ (Microsoft Edge Blog の記事、 Neowin の記事、 Softpedia の記事)。 メジャーブラウザーは 2018 年 10 月、TLS 1.0 / 1.1 を 2020 年前半にデフォルト無効化する計画を一斉に発表したが、COVID-19 パンデミックの影響で各社それぞれ実施スケジュールを変更している。 Microsoft が再設定したスケジュールでは 2020 年 7 月に Microsoft Edge 84 (Chromiumベース) でデフォルト無効化し、2020 年 9 月に IE とレガシー Edge (EdgeHTML ベース) でデフォルト無効化する計画だった。しかし、予定通り無

TLS 1.2の後継として検討が進められているTLS 1.3だが、大きな仕様変更が加えられることからその名称を「TLS 2.0」にすることが検討されているようだ（名称変更に関するプルリクエスト）。 なお、TLS 1.3では暗号化方式の変更にとどまらず、ハンドシェイクの改善や性能向上など多数の変更が加えられるようだ。多くの変更が加わっているにも関わらず「TLS 2.0」ではなく「TLS 1.3」として検討が進められていたのは、既存のクライアント/サーバーとの互換性を保つためだったとのこと（IIJ・大津氏による技術解説スライド）。

Let's Encryptが11日、ほかのユーザーの電子メールアドレスを記載した電子メールをユーザーに送信していたことを発表、謝罪した（Let's Encryptの報告、Register）。 この電子メールは、電子メールアドレスを登録しているすべてのアクティブサブスクライバーに対し、サブスクライバー契約書の内容変更を知らせる内容で、自動送信システムにより送信された。しかし、プログラムのバグにより、前に送信した送信先が次々と本文に付加されていったのだという。問題に気付いたLet's Encryptは全体のおよそ1.9%にあたる7,618通を送信したところでシステムを停止させたが、0～7,618件（件数は原文ママ）の電子メールアドレスが記載された電子メールが送信されてしまったとのこと。 Let's Encryptでは原因を調査し、再発防止に努めるとしており、調査結果を後日発表するとのこと。また

一昨年に起きたベネッセからの個人情報流出事件について、東京地裁は29日、情報を持ち出した元システムエンジニアの男性に不正競争防止法違反（営業秘密の複製、開示）による懲役3年6か月、罰金300万円の実刑判決を下した（読売新聞、TBS、ウォール・ストリート・ジャーナル）。弁護側は即日控訴した。 ベネッセから一千万件にも上る大量の個人情報が流出したこの事件では、当時顧客DBの保守管理を行っていた30代の派遣SEが情報を持ち出したとして逮捕されていた（逮捕時の記事）。弁護側は持ち出しは認めつつもコピーされた情報は営業秘密に当たらないとして無罪を主張したものの、会社側が情報へアクセスできる人員を限定するなど機密保持を行っていたことを根拠に営業秘密に当たると判断された。 被告は持ち出した個人情報を名簿業者に売却、競艇などに散財していたとみられており、判決では厳しく非難されている。この事件では、ベネッセ

認証局業者は未だに「SSL」という名称にこだわりつづけているようです。Symantec [symantec.com] も GlobalSign [globalsign.com] もトップページに「TLS」という文字すら存在しない (ツイートの表示部分を除く) という異常な状況です。「TLS」を「SSL」を呼ぶことが技術的に誤りなのは明確ですし、「SSL」が安全だと錯覚させ「TLS」への移行を遅らせることになりますので、古い名称にこだわり続けることは有害だと思います。一方、Wikipedia では「SSL」のページを廃止して「TLS」にリダイレクトするようにしており [wikipedia.org]、素晴らしい対応だと思います。 SSLでググる [google.co.jp]と、認証局業者の広告が山ほど表示され、不自然な程に「SSL」というキーワードを散りばめた人間から見たら異常な認証局業者のW

「パスワードの強度を判定」するツールやサービスはいくつかあるが、それらによる判定結果に一貫性がないことがReadWriteで取り上げられている。 コンコルディア大学の研究者らが行った調査結果によると、こうしたツールではたとえば小文字の「l」を数字の「1」に置き換えるような、「破られやすいパターン」を無視することがあるという。さらに、実際にさまざまなツールやサービスを使って検証したところ、ほぼ同一のパスワードでまったく異なる結果が出た例もあるそうだ。 サイトによって異なる基準で強度を判定しているのが原因だそうで、またその判定基準もほとんど公開されていない点も問題だとしている。また、Dropbox（と同様のアルゴリズムを採用しているKeePass）だけは例外で、そのアルゴリズム「zxcvbn」はオープンソースで公開されており、その判定基準は非常に効果的だという。

先日、SSL3.0の脆弱性（通称「POODLE」）が発見されたが、この脆弱性がTLSにも影響する可能性があることが明らかになった（JVNVU#98283300、CNET Japan）。 TLS通信においても、Padding Bytesの検証処理が行われていない実装の場合、この脆弱性の影響を受ける可能性があるとのこと。実際に影響を受けるTLS実装も確認されている模様。

アメリカの国土安全保障省（DHS）は、オープンソースのコードをチェックし、セキュリティホールやバグを発見するためのサービス「Software Assurance Marketplace（SWAMP）」の提供を開始した（ZDnet、Slashdot）。 SWAMPのプロジェクトマネージャであるPatrick Beyer氏によると、オープンソースソフトウェアの人気が高まるとともに、政府機関がオープンソースのコードを使用する機会が増えてきた。しかし、コードの安全と品質に関しては多くの心配が残っている。そこでコードにチェックするための場所の1つとしてSWAMPの提供を始めたのだという。 SWAMPではいくつかの分析ツールが利用され、プログラムを実行しなくても、ソースコードから潜在的なセキュリティ欠陥が存在するかどうかを分析できるという。

マサチューセッツ大学のサイバー犯罪捜査の専門家チームが、Google Glassやwebカメラなどのデバイスで撮影された動画を用いて、スマートフォンやタブレットに入力されたパスワードや暗証番号を盗むことのできるソフトウェアを開発したとのこと（CNN）。 このソフトウェアは、スマートフォンやタブレット端末に暗証番号を入力する指先の影を監視し、タッチした部分から暗証番号を割り出すことができるのだそうだ。実験では、動画の撮影にGoogle Glassや携帯電話、Webカメラなど用いられ、Apple iPadやGoogleのNexus 7タブレット、iPhone5に入力された暗証番号を割り出すことができたとのこと。 さすがに、銀行の暗証番号を入力している最中にビデオカメラを向けられれば用心するだろうが、Google Glassやスマートウォッチといったデバイスで密かに撮影されれば気がつかないかもし