List of Tls [text.Baldanders.info]

Go 1.12 がリリースされた

2019-02-26T14:03:40+00:00

Go 1.12 がリリースされた。そういえば2月ももう終わりか。

主な変更点としては TLS 1.3 の暫定的なサポート（有効にするには環境変数の設定が必要）とモジュール・モードの挙動の一部が変わったことだろうか。

たとえば環境変数 $GO111MODULE を on にしておけば mattn さんの jvgrep をインストールする際にも任意のフォルダで

$ go get github.com/mattn/jvgrep@latest

とすればよい。ダミーの go.mod ファイルを作る必要はなくなった。ブラボー！

Go 1.13 からはモジュール・モードが既定になるようで，「GOPATH モードじゃないと困る」とかじゃなければ環境変数 $GO111MODULE は on のままにしてしまえばいいんじゃないのかなぁ。

あと地味だが嬉しい変更としては，並行処理下で正規表現パッケージ regexp を使う際に regexp.Regexp.Copy() でクローンを作らなくてもブロッキングが起きないようになった。

Go 言語はこの 1.12 から 1.13 にかけて大きく変わる予感がする（今のところ後方互換性は確保されるだろうが）。色々と試していって慣れていくのがいいかもしれない。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

[Comment] 著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

[Comment] Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

（不完全ながら） HTTPS 接続に対応した

2019-01-07T08:53:06+00:00

遅まきながら本家サイトの HTTPS 接続に対応した。

いや，随分前に「さくらのレンタルサーバ」で Let’s Encrypt を用いた TLS 設定が簡単になったという話は聞いてたのよ。

ただし，個人的には積極的に HTTPS に切り替える動機はなかった¹ ので放置していた。

ところが Facebook で聞いた話によると米国では ISP が Web の通信に対して何らかの干渉を行う懸念を払拭できないとかで，そういえば米国では「ネットの中立性」は公式に破れているし日本もいずれそうなるだろうとは想像に難くない。

そうであるなら，そういった通信に対する干渉を抑止するためにも HTTPS を有効にしておくのは意味があるだろうと考えを改めることにした。まぁ，ページの広告エリアに採掘コードを差し込むとか，セキュリティと称して HTTPS 通信に中間者攻撃をかまして出歯亀するとかいったことが横行している状況で HTTPS でどこまで安全が担保されるのかは分からないが。

なお，各ページに埋め込まれる他サイトのスクリプトや画像等のマテリアルに HTTPS に対応していないものがあるため不完全な対応になっている点はご了承の程を²。これは徐々に改修していく予定。

このため，当面は HTTP と HTTPS の両方とも有効にして運用し強制的な HTTPS リダイレクトはしない。上述したように，私は HTTPS をデータの機密性および完全性の観点からはあまり信用してないので「やらないよりはマシ」というスタンスで運用することにする。

2019年の目標

実は今年の目標というか TODO として本家サイトの改造を考えていて，具体的には

本家サイトを Hugo ベースに再構築する（ただし URL はできるだけ変えない）
Flickr の写真を引き揚げて本家サイトに移転する

と考えている。今回の HTTP 接続対応はそのついでというわけだ。上の2つのうち 2 に関しては既に全バックアップをとって手元にデータはあるのだが，本家サイトでの公開については 1 の作業と併せて行う予定なので，しばらく先のことになるだろう。

これ以外にもうひとつ問題があって， Amazon アフィリエイト・リンク作成サービスの Amakuri がサービスを終了するらしい。

【Amakuri】来年15日にAmakuriは閉鎖いたします - dadadadoneのメモ帳

G-Tools さんに続いてお宅もか orz

どうしよう。たぶん類似サービスは軒並み閉鎖だよね，これ。自前でツールを用意するしかないのか。それが面倒くさいから人様のサービスを利用してたのに。

ここのブログも HTTPS 接続に対応していた

ここのブログは GitHub Page なのだが，なにもしないのに何時の間にか HTTPS 接続に対応していたらしい。

Custom domains on GitHub Pages gain support for HTTPS | The GitHub Blog

こちらも当面は HTTP と HTTPS の両方とも有効にして運用するが Flickr の写真と Amazon アフィリエイト・リンクの目処が立てば HTTPS 強制にしてもいいかも知れない。

【2019-05-21】 以下を参考に HTTP 強制にしました。

Securing your GitHub Pages site with HTTPS - GitHub Help

【追記1】 e-Words 用語集止めました

ここのブログではページ下部に e-Words 用語集のブログパーツを貼り付けていたのだが，既にメンテナンスされていないようで，かなり前から説明ページが消えてるし，しかも HTTP 接続オンリーで HTTPS なページに貼り付けるとブラウザから reject されるので，今回を機に削除することにした。

本当は Disqus も止めたい。 Disqus の埋め込みコードは Firefox からはトラッキング・コードと見做されているため reject される。設定を緩めればいける³ のだが，それも微妙な気もする。 Twitter か Facebook ページでフィードバックを，という手もあるが…

【追記2】 Amazon 関連の URL 変換

Amazon の商品ページへのリンク URL や書影等のイメージの URL について以下のように変換した。

変換前	変換後
`http://www.amazon.co.jp/`	`https://www.amazon.co.jp/`
`http://ecx.images-amazon.com/`	`https://images-fe.ssl-images-amazon.com/`
`http://images.amazon.com/`
`http://g-images.amazon.com/`

Amazon 関連の URL 変換

ブックマーク

こう言ったら専門家の方には鼻で笑われるだろうが，セキュリティ専門家が言う「木の葉を隠すなら林の中」理論で馬も鹿も HTTPS ってのには首を傾げてしまう。ましてや SEO 対策で HTTPS に切り替えるとか阿呆としか言いようがない。ひとつのドメインやサービスで，ページや状況によって HTTP と HTTPS を使い分けるな，というのならその通りだと思うけれど。まぁ Let’s Encrypt が正式リリースされたし「面倒臭い」以外に HTTPS にしない理由はないので，今回はいい機会になったと考えている。 ↩︎
なにせ1999年以来19年分の垢がこびりついたサイトなので。って今年は（本格的に Web で活動を始めてから）20周年やん！ ↩︎
どうも Firefox 側でホワイトリストまたはブラックリストを持っていて，トラッキング・コードの配信元から有効/無効を判断してるっぽい。ホワイトリスト方式またはブラックリスト方式は運用する側にどうしても恣意が混入してしまう。この辺は spam メール対策で懲りているので賢いやり方に見えない。 ↩︎

Firefox の Cipher Suite

2018-12-16T02:24:32+00:00

J-STAGEがFirefoxでのアクセスを遮断、日本の電子ジャーナルが世界から不可視となった日｜Guest｜note

この記事を読んで以下のように思わなかっただろうか。

「Firefox 側が TLS_RSA_WITH_AES_256_CBC_SHA256 あたりを用意すればええんちゃうん？」

私は思った。 J-STAGE というサイトや運営している JST という組織をよく知らないので，なんでそこまで悪意たっぷりに書かれるのかよく分からないが，もうちょっと書きようがあるだろうに。

TLS Cipher Suite

まず TLS (Transport Layer Security) Version 1.2 の仕様を記した RFC 5246 によると “Mandatory Cipher Suites” というのがあって，この中で TLS_RSA_WITH_AES_128_CBC_SHA を MUST に定めている。したがって，上述のリンク先の記事でこれがないことについて「TLS仕様違反」と断じている点は間違いない。

この場合，サーバ側の対応としては， NSS なら TLS_RSA_WITH_AES_128_CBC_SHA， OpenSSL なら AES128-SHA を有効にすればいいわけだ。

一方， Firefox はどうなっているかというと about:config を開いて “ssl3” で検索すると出てくる。

Cipher Suite in Firefox

ちなみにこれは Firefox Developer Edition 65 の場合である。一応，抜き書きすると

security.ssl3.dhe_rsa_aes_128_sha
security.ssl3.dhe_rsa_aes_256_sha
security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256
security.ssl3.ecdhe_ecdsa_aes_128_sha
security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384
security.ssl3.ecdhe_ecdsa_aes_256_sha
security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256
security.ssl3.ecdhe_rsa_aes_128_gcm_sha256
security.ssl3.ecdhe_rsa_aes_128_sha
security.ssl3.ecdhe_rsa_aes_256_gcm_sha384
security.ssl3.ecdhe_rsa_aes_256_sha
security.ssl3.ecdhe_rsa_chacha20_poly1305_sha256
security.ssl3.rsa_aes_128_sha
security.ssl3.rsa_aes_256_sha
security.ssl3.rsa_des_ede3_sha

となっている。これを見ると TLS_RSA_... から始まる古い cipher suite は殆ど対応していないことが分かる（mandatory cipher suites を除けば2つのみ）。 Firefox 側の思惑は不明だが，古い cipher suite は PFS (Perfect Forward Secrecy) に対応してない（できない）ため意図的に外してる可能性もある。

Cipher Suites for Modern Browser

（おそらくもうサポートされていない）古いブラウザを切り捨てていいのであれば，以下の cipher suite をサポートしておけば問題ないらしい。

HEX	IANA	OpenSSL
0xC0,0x2C	`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`	`ECDHE-ECDSA-AES256-GCM-SHA384`
0xC0,0x30	`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`	`ECDHE-RSA-AES256-GCM-SHA384`
0xCC,0xA9	`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256`	`ECDHE-ECDSA-CHACHA20-POLY1305`
0xCC,0xA8	`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256`	`ECDHE-RSA-CHACHA20-POLY1305`
0xC0,0x2B	`TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`	`ECDHE-ECDSA-AES128-GCM-SHA256`
0xC0,0x2F	`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`	`ECDHE-RSA-AES128-GCM-SHA256`
0xC0,0x24	`TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384`	`ECDHE-ECDSA-AES256-SHA384`
0xC0,0x28	`TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384`	`ECDHE-RSA-AES256-SHA384`
0xC0,0x23	`TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256`	`ECDHE-ECDSA-AES128-SHA256`
0xC0,0x27	`TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`	`ECDHE-RSA-AES128-SHA256`

これらの cipher suite は Firefox 27 以降, Chrome 30 以降, IE 11 以降, Edge, Opera 17 以降, Safari 9 以降, Android 5.0 以降, Java 8 以降であれば対応している。

たまには Firefox のことも思い出してあげてください

以前も書いたが，携帯端末も含めれば Chrome/Chromium と Safari/WebKit でほぼ寡占状態と言ってよい。そういった状況の中で Firefox も対応しろと言われてもかったるいかもしれないし，実際に私が関わったことのある案件でも Chrome や Edge での動作確認はするのに Firefox はスルーするところも結構あったりした。特定企業への依存度が減るんだから，むしろ Firefox は推奨されていいと思うんだけどねぇ。

少なくとも HTTPS 接続で Firefox を村八分 (ハブ) にする理由はないと思うので，是非ともよろしくお願いします。

ブックマーク

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

HTTPS 通信監視機器のリスク

2017-03-21T11:32:28+00:00

2015年の CERT/CC ブログ記事 “The Risks of SSL Inspection” に関する注意喚起が今更ながら出ている。

The Risks of SSL Inspection

「HTTPS 通信監視機器」というのは，ぶっちゃけていうと， HTTPS 暗号通信¹ に「中間者攻撃（man-in-the-middle attack）」を仕掛けて通信を傍受し malware 等を検出・排除する「セキュリティ製品」である。

HTTPS 通信監視機器のいくつかにはセキュリティ上の問題が存在する。 “The Risks of SSL Inspection” から抜き出してみよう。

Incomplete validation of upstream certificate validity
Not conveying validation of upstream certificate to the client
Overloading of certificate Canonical Name (CN) field
Use of the application layer to convey certificate validity
Use of a User-Agent HTTP header to determine when to validate a certificate
Communication before warning
Same root CA certificate

これらの問題があると推測される製品のリストが “The Risks of SSL Inspection” に挙がっているので該当者は確認してみるとよいだろう。また以下のサイトからも確認できる。

badssl.com

“The Risks of SSL Inspection” では以下のように結論付けている。

SSL and TLS do not provide the level of end-to-end security that users may expect. Even in absence of SSL inspection, there are problems with how well browsers are conveying SSL information to users. The fact that "SSL inspection" is a phrase that exists, should be a blazing red flag that what you think SSL is doing for you is fundamentally broken.

via The Risks of SSL Inspection

以前も書いたが，HTTPS 通信監視機器（あるいは HTTPS Deep Inspection）の存在自体がインターネットの “End to End” 原則を崩すものであり，ひいては「ネットの中立性」に楔を入れるものである。しかし「馬も鹿も暗号化する時代」にこの原則は風前の灯である。たとえば CMS の面倒すらろくすっぽ見られないユーザが「うちも Let’s la Encrypt」とか言い出して脆弱性だらけのサイトを暗号化したらどうなるのか。

ネットワーク・セキュリティ専門家から企業あるいは私たち個人に至るまで，場当たりな対処に満足するのではなく，この「現実」にきちんと向き合うべきだと思うのだが，どうだろう。

【おまけの追記】公開鍵基盤が担保するもの

他の事象だが同じ公開鍵基盤（Public Key Infrastructure; PKI）に関連している事柄なので，おまけの追記ということで。

「Symantecが再びGoogleの信頼を失った件についてのメモ」にもあるように Symantec （傘下の Thawte）は既に前科持ちなので「またか（sigh）」って感じなのだが…

X.509 型の公開鍵基盤は認証局（Certification Authority; CA）が信頼できることが絶対条件で，これが崩れると機能しなくなる。

喩えるならお金と銀行の関係と似ている。銀行はお金の価値を担保するが銀行が信用できないのならお金の価値を担保するものがなくなる。同じく認証局が管理する証明書は認証局が安全性を担保できているからこそ意味がある。そうでなければオレオレ証明書またはそれ以下の価値しかない。

この問題は Symantec と Google の2者間の喧嘩だと思ったら物事を見誤る。現在 Web を支配している公開鍵基盤の根幹に関わる問題なのである。

それにしても，昔「EV SSL は『屋上屋を架す』ようにしか見えない」と書いたが，まったくもってその通りだったな（笑）

ブックマーク

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

念のため簡単に説明しておくと， HTTPS (Hypertext Transfer Protocol Secure) 暗号通信は WWW (World Wide Web) におけるクライアント-サーバ間の通信経路を暗号化する仕組みである。具体的には TLS (Transport Layer Security) 等のプロトコルを用い公開鍵暗号方式を使ってセッション鍵を生成する。また公開鍵暗号方式の公開鍵は X.509 方式の公開鍵基盤によって管理される。 ↩︎

NIST SP800-52 Rev.1 の邦訳が登場

2017-02-01T14:06:06+00:00

IPA は NIST のセキュリティ関連文書の邦訳を積極的に行っているが，SP800-52 Rev.1 の邦訳が登場したようだ。

古い話になるが，2013年までに RC4 の危殆化や SSL/TLS の攻略コードがいくつか「開発」されたことにより TLS 1.2 への移行が強く推奨されることになった。それを受けての SP800-52 改訂だったのだが，その後の SSL/TLS やその実装である OpenSSL 等のソフトウェアへの攻撃の激しさはみなさんご存じのとおりである。

そうそう。 IPA と言えば最近になってヤバい注意喚起が上がっている。

【注意喚起】SQLインジェクションをはじめとしたウェブサイトの脆弱性の再点検と速やかな改修を：IPA 独立行政法人情報処理推進機構

また2014年に大騒ぎになった Heartbleed 脆弱性をいまだに放置しているサイトもあるようだ。

「Heartbleed」脆弱性、多くのサイトやサーバでいまだに存在–Shodan Report - ZDNet Japan

攻撃者は既知の攻撃は当然のように試す。先延ばししていいことは何もない。いや，マジでお願いしますよ，サイト運用者の方々。

ブックマーク

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

SSLv2 を有効にしている TLS 実装の脆弱性 ― 馬も鹿も暗号化する時代のセキュリティ

2016-03-02T15:30:52+00:00

脆弱性の内容

いい加減 SSL 周りの脆弱性にはうんざりなのだが， OpenSSL をはじめとする SSL/TLS 暗号通信の実装に複数のセキュリティ脆弱性あり。

CVE	脆弱性内容
CVE-2016-0800	Cross-protocol attack on TLS using SSLv2 (DROWN)
CVE-2016-0705	Double-free in DSA code
CVE-2016-0798	Memory leak in SRP database lookups
CVE-2016-0797	BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption
CVE-2016-0799	Fix memory issues in BIO_*printf functions
CVE-2016-0702	Side channel attack on modular exponentiation
CVE-2016-0703	Divide-and-conquer session key recovery in SSLv2
CVE-2016-0704	Bleichenbacher oracle in SSLv2

このうち特に CVE-2016-0800 のリスクが高いので紹介する。

CVE-2016-0800 : Cross-protocol attack on TLS using SSLv2 (DROWN)

通称 DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) 攻撃。

A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note that traffic between clients and non-vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server. This vulnerability is known as DROWN (CVE-2016-0800).

via OpenSSL Security Advisory [1st March 2016]

OpenSSL などで SSLv2 を有効にしている場合， SSL を使用していなくても TLS 暗号通信を中間者攻撃で攻略することができるらしい¹。ポイントは SSL サーバのみでなくサーバとネットで繋がっている他のマシンにも影響をおよぼす可能性があることだ。

CVE-2016-0702 : Side channel attack on modular exponentiation

リスクは低いが， CVE-2016-0702 についても一応紹介しておく。通称 CacheBleed と呼ばれる side-channel 攻撃の一種である。

A side-channel attack was found which makes use of cache-bank conflicts on the Intel Sandy-Bridge microarchitecture which could lead to the recovery of RSA keys. The ability to exploit this issue is limited as it relies on an attacker who has control of code in a thread running on the same hyper-threaded core as the victim thread which is performing decryptions.

via OpenSSL Security Advisory [1st March 2016]

どうもこれ，2013年の GnuPG の脆弱性のバリエーションらしい。

Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack （当時書いた拙文）

Side-channel 攻撃は成立条件が特殊なので，一般的にリスクは高くない。 CVSSv2 基本評価値は 2.6 (AV:L/AC:H/Au:N/C:P/I:P/A:N) なので，こういう攻略法もあるといった程度に覚えておくといいだろう。

影響度（CVSS）

CVSSv2 基本評価値 7.1 (AV:N/AC:H/Au:N/C:C/I:C/A:N)

“Vulnerability Note VU#583776 - Network traffic encrypted using RSA-based SSL certificates over SSLv2 may be decrypted by the DROWN attack” より

基本評価基準	評価値
攻撃元区分（AV）	ネットワーク（N）
攻撃条件の複雑さ（AC）	高（H）
攻撃前の認証要否（Au）	不要（N）
情報漏えいの可能性（機密性への影響, C）	全面的（C）
情報改ざんの可能性（完全性への影響, I）	全面的（C）
業務停止の可能性（可用性への影響, A）	なし（N）

CVSSv3 基本評価値 7.4 (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)

「JVNVU#90617353: SSLv2 の暗号通信を解読可能な脆弱性 (DROWN 攻撃)」より

基本評価基準	評価値
攻撃元区分（AV）	ネットワーク（N）
攻撃条件の複雑さ（AC）	高（H）
必要な特権レベル（PR）	不要（N）
ユーザ関与レベル（UI）	不要（N）
スコープ（S）	変更なし（U）
情報漏えいの可能性（機密性への影響, C）	高（H）
情報改ざんの可能性（完全性への影響, I）	高（H）
業務停止の可能性（可用性への影響, A）	なし（N）

CVSS については解説ページを参照のこと。

影響を受ける製品

OpenSSL 1.0.1r およびそれ以前の 1.0.1 系列
OpenSSL 1.0.2f およびそれ以前の 1.0.2 系列

また，このバージョンの OpenSSL を利用している製品（Apache, Postfix, Nginx 等）も影響を受ける。なお，公開されているサーバが DROWN の影響を受けているかどうかテストするサイトがある。

test.drownattack.com

OpenSSL 以外にも SSLv2 が有効になっている場合は今回の脆弱性の影響を受ける可能性があり，以下の製品・バージョンについて警告されている。

Microsoft IIS (Windows Server) : バージョン 7 以降は既定で SSLv2 が無効化されている
MNetwork Security Services (NSS) : バージョン 3.13 以降は既定で SSLv2 が無効化されている

LibreSSL は DROWN の影響を受けないそうだ。

LibreSSL not affected by DROWN attack

対策・回避策

OpenSSL に関しては最新バージョンで対策されている。

OpenSSL 1.0.1s
OpenSSL 1.0.2g

SSL は既に仕様上の脆弱性を抱えており，可能な限り無効にすることをお薦めする。

SSL/TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～：IPA 独立行政法人情報処理推進機構

どうしても SSLv2 を有効にしなければならない場合，証明書を分けて，他のプロトコルと共用しないようにすること。

ブックマーク

【余談】馬も鹿も暗号化する時代のセキュリティ

一千万規模か。意外と少ないな。まぁ2014年に大騒ぎになった SSL 関連の脆弱性のおかげで SSL を無効にしたところも多かろう。

更新：SSL 3.0 の脆弱性対策について(CVE-2014-3566)：IPA 独立行政法人情報処理推進機構

SSL を無効に出来ないサイトの多くは古い PC やケータイを考慮しているのだろうけど，もう考慮の余地はないと思う。セキュリティを気にせざるを得ない他のユーザに迷惑をかけるからだ。

Web サイトを全て暗号化すべきという意見があって，セキュリティ専門家でも賛同者が多いが，私は懐疑的だ。現在はセキュリティ要件が2,3年単位で変化し追従できないサービスやユーザも多い。問題なのは，サイトが乗っ取らるなどして，暗号通信下で malware の活動を許してしまうことで，セキュリティ管理のいい加減なサービスが暗号通信を行うのはむしろ有害とさえ言える。

今だに SSLv2 や SSLv3 を有効にしているサイトがあるというのなら，そのサイトはセキュリティ上は全く信用できないと断言していいと思う。脆弱な暗号通信を使うくらいなら，いっそ暗号化していない限定機能の HTTP サイトを用意して古いマシンのユーザは（安全でないことを警告したうえで）そちらに誘導する方がよい。個人的な感覚では Web サービス全体の 2/3 程度が暗号化できていれば充分だと思う。

馬も鹿も暗号化するこの時代。国家や企業の戯れ言に耳を貸す気はないが，それが本当は何を守ってるのか，そろそろ真面目に考えないといけないのではないのだろうか。

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

TLS と SSLv3 で同じ証明書を使用している場合。 ↩︎

[security] Go 1.5.3 is released

2016-01-24T06:24:23+00:00

2週間前の話ですみません。 1月14日に Go 言語コンパイラ 1.5.3 が出ています。メインは math/big パッケージの不具合修正です。

リスクとしては大したことはないですが， Web アプリケーションまたは TLS の実装を Go 言語で行っている方は要更新です。

This issue can affect RSA computations in crypto/rsa, which is used by crypto/tls. TLS servers on 32-bit systems could plausibly leak their RSA private key due to this issue. Other protocol implementations that create many RSA signatures could also be impacted in the same way.
Specifically, incorrect results in one part of the RSA Chinese Remainder computation can cause the result to be incorrect in such a way that it leaks one of the primes. While RSA blinding should prevent an attacker from crafting specific inputs that trigger the bug, on 32-bit systems the bug can be expected to occur at random around one in 2^26 times. Thus collecting around 64 million signatures (of known data) from an affected server should be enough to extract the private key used.
On 64-bit systems, the frequency of the bug is so low (less than one in 2^50) that it would be very difficult to exploit. Nonetheless, everyone is strongly encouraged to upgrade.

via [security] Go 1.5.3 is released - Google グループ

CVE-2015-8618 Carry propagation in Int.Exp Montgomery code in math/big library

CVSSv2 基本評価値 2.6 (AV:N/AC:H/Au:N/C:P/I:N/A:N) （Redhat による評価）

基本評価基準	評価値
攻撃元区分（AV）	ネットワーク（N）
攻撃条件の複雑さ（AC）	高（H）
攻撃前の認証要否（Au）	不要（N）
情報漏えいの可能性（機密性への影響, C）	部分的（P）
情報改ざんの可能性（完全性への影響, I）	なし（N）
業務停止の可能性（可用性への影響, A）	なし（N）

List of Tls [text.Baldanders.info]

Go 1.12 がリリースされた

ブックマーク

参考図書

（不完全ながら） HTTPS 接続に対応した

2019年の目標

ここのブログも HTTPS 接続に対応していた

【追記1】 e-Words 用語集止めました

【追記2】 Amazon 関連の URL 変換

ブックマーク

Firefox の Cipher Suite

TLS Cipher Suite

Cipher Suites for Modern Browser

たまには Firefox のことも思い出してあげてください

ブックマーク

参考図書

HTTPS 通信監視機器のリスク

【おまけの追記】公開鍵基盤が担保するもの

ブックマーク

参考図書

NIST SP800-52 Rev.1 の邦訳が登場

ブックマーク

参考図書

SSLv2 を有効にしている TLS 実装の脆弱性 ― 馬も鹿も暗号化する時代のセキュリティ

脆弱性の内容

CVE-2016-0800 : Cross-protocol attack on TLS using SSLv2 (DROWN)

CVE-2016-0702 : Side channel attack on modular exponentiation

影響度（CVSS）

影響を受ける製品

対策・回避策

ブックマーク

【余談】 馬も鹿も暗号化する時代のセキュリティ

[security] Go 1.5.3 is released

CVE-2015-8618 Carry propagation in Int.Exp Montgomery code in math/big library

【余談】馬も鹿も暗号化する時代のセキュリティ