Let's EncryptがはまったGolangの落とし穴 - ぼちぼち日記
0. 短いまとめ 300万以上の証明書の失効を迫られたLet's Encryptのインシデントは「Golangでよくある間違い」と書かれているようなバグが原因でした。 1. はじめに、 Let's Encryptは、無料でサーバ証明書を自動化して発行するサービスを行う非営利団体として2014年に設立されました。 2015年にサービス開始されると証明書の発行数はぐんぐん伸び、先月末のプレスリリースでは累計10億枚のサーバ証明書を発行したことがアナウンスされました「Let's Encrypt Has Issued a Billion Certificates」。CTLogの調査から、2020年2月末の時点では有効な全証明書の38.4%がLet's Encryptの証明書であるとみられています「Certificate Validity Dates」。 無料の証明書を提供してもらえるのは非常に嬉し
Google Chrome EV表示の終焉 - ぼちぼち日記
1. Chrome でEV証明書の組織名表示がなくなる ついにGoogleからChromeのURLバーからEV表示を削除する正式なアナウンスが出ました。 Upcoming Change to Chrome's Identity Indicators EV UI Moving to Page Info 現在(2019年8月) StableのChrome76では、以下の様にURLバー左側にEV証明書を利用していることを示す「組織名+国名」表示が付いています。 Chrome76のEV表示 2019年9月10日Stableリリース予定のChrome77からはEV表示がURLバーから削除され、鍵アイコンをクリックして表示されるPage Infoに「組織名＋国名」が表示されるようになります。 Googleのアナウンスでは、 "on certain websites" と書いてあることから一気にではなく
GitHub - google/ssl_logger: Decrypts and logs a process's SSL traffic.
geffner@ubuntu:~$ # Make a local pipe for input to our openssl client geffner@ubuntu:~$ mkfifo pipe geffner@ubuntu:~$ # Create our openssl client, which will receive input from our pipe geffner@ubuntu:~$ openssl s_client -ign_eof -connect example.org:443 > /dev/null 2> /dev/null < pipe & [1] 98954 geffner@ubuntu:~$ # Begin writing the request to our pipe geffner@ubuntu:~$ printf "GET / HTTP/1.0\nH
書評：プロフェッショナルSSL/TLS - ぼちぼち日記
ごめんなさい、書いてたら長くなってしまいました。長文嫌いな方は避けて下さい。 鹿野さんの名前を間違えてました。大変失礼しました。（＿O＿） 1. はじめに。日本語翻訳版刊行によせて、 昨年10月、Vさんから 「 Bulletproof SSL and TLS 翻訳本のレビューします？時雨堂が出資してる出版会社が翻訳権を勝ち取ったのです。」 とお誘いを受けたのが、そもそもの始まりでした。 「とうとうあれの日本語翻訳が出るのか、でもホント大丈夫か？ 内容の濃さもさることながらあの分量とクオリティ、記述の正確さや厳密さに対して特に高いものが要求されるセキュリティ分野。しかも初心者向けではないエキスパート向け。この本の翻訳を出すとは… なんと大胆、少し無謀なことではないか？」 との思いが正直頭をよぎりました。 自分もちょうど17年半勤めた前職を辞めて転職した直後。新任早々こんなことしても許されるの
プロフェッショナルSSL/TLS
こちらは改訂前の旧版のページです。改題第2版の商品ページをご覧ください Webセキュリティ解説の決定版 "Bulletproof SSL and TLS" の全訳（原書2017年版へのアップグレード済み） Ivan Ristić 著、齋藤孝道 監訳 520ページ B5判 ISBN：978-4-908686-00-9 電子書籍の形式：PDF 2020年7月4日 第1版第5刷 発行（原書2017年版アップグレード対応済み） 本サイトにてユーザ登録のうえ購入いただくと、原著改訂第2版に収録されるTLS 1.3の解説章を付録として含んだ特別版PDFがお読みいただけます 現代生活を支えるネットワークにとって、通信の暗号化は不可欠の機能です。しかし、実際のインターネットで暗号化通信を利用できるようにするには、暗号化アルゴリズムの知識だけでなく、セキュリティプロトコルとその実装技術、さらに、基盤となる信
docker で全自動 Let's encrypt - Qiita
https-portal があまり知られてないようなので紹介記事だけ書いとく。 https://github.com/SteveLTN/https-portal あなたがすでにhttpで動作するサービスのdockerコンテナを持ってるなら、こいつを docker-compose に加えるだけで https 対応は完了。 え？ 加えるだけで完了。 まじです。 https-portal は何をするものか 基本的には https のリクエストを受け取り、他のコンテナの http へ転送するリバースプロキシとして動作する nginx である。 ところで https を提供するには証明書の取得、設定などが必要だが、こいつはそれを全自動でやってくれる。 え？ 証明書の取得、設定を全自動でやってくれる。 まじです。 期間延長も自動でやってくれるらしい。 まあとにかく便利なので、 Let's encryp
錆びついたTLSを滑らかに、GoogleによるGREASE試験 - ぼちぼち日記
0. 短いまとめ 長い間、TLSのクライアント・サーバ間で使用するTLSバージョンを合意する際に、 不完全なサーバ実装によって version intolerance が発生することが問題になっていました。 TLS1.3ではこの version intolerance の影響を最小化するため、新しい version negotiation の仕組みを取り入れました。 Googleは、GREASE(Generate Random Extensions And Sustain Extensibility)という仕様をChromeに実装し、TLSサーバのバグで通らない拡張やフィールド値で問題が発生しないか試験を始めました。 パケットキャプチャが好きな人は、Chromeが 0x[0-f]a0x[0-f]a の見慣れない値をCipherSuiteやTLS拡張に使っているのを見つけても驚かないよう気を
TCP serverをSSL/TLS化するのに nginx の stream_ssl_module/stream_proxy_module が便利 - たごもりすメモ
最近 Fluentd の通信プロトコルまわりをアップデートするためにあれこれいじっている*1んだけど、これはおおむね fluent-plugin-secure-forward がサポートしていた内容を Fluentd 組込みの forward plugin でもサポートしますよ、というものになる。 んで問題なのが secure-forward は SSL/TLS での接続のみしかサポートしてなかったんだけど forward では生の TCP で通信する*2ので、本当に secure-forward と forward それぞれの実装間で互換性が保たれているのか、直接的には確認する手段がない、ということになってしまう。 TCP server の SSL/TLS 化 一方世の中には SSL/TLS ターミネータという機能があって、たとえばロードバランサなんかがこの機能を持っている。何をやるかと
let's encrypt で複数ホスト名対応な証明書を作る - 日記
let’s encrypt で複数ホスト名対応な証明書を作る タイトル通りですが、割と簡単に複数のホスト名に対応した証明書が取得できるので、やってみました。 今回は ansible playbook のおまけ付きです。 let’s encrypt の困った問題 let’s encrypt ではワイルドカード証明書が無いので、複数のホスト名を1台のサーバでホスティングできないため、ちょっと困っていました。 ググって調べてみたら、let’s encrypt は SAN 対応の証明書だったら発行できる、と言うことだったので実際にやってみました。 その前に、SAN って何よ？ ワイルドカード証明書だと良く聞くと思うのですが、 SAN って何よ？と思う人も多いと思います。 SAN とは Subject Alternative Name の略称で、サブジェクトの別名です。 ん？サブジェクトってなに？
let's encrypt の revoke とドメイン管理 - 日記
前回の続きで、もう少し let's encrypt tnamao.hatenablog.com 証明書の破棄 前回のエントリで作成した証明書の破棄を試してみたいと思います。 証明書を破棄するときも、letsencrypt-auto コマンドを使います。 破棄する証明書がある $ sudo supervisorctl stop nginx $ ./git/letsencrypt/letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/test.tnamao.net/fullchain.pem $ sudo supervisorctl start nginx 発行や更新のときと一緒で、nginx を止めてから、letsencrypt-auto コマンドを実行します。 そして、ブラウザから証明書を確認すると…。 破棄できた！＼(^o^)
URL外形監視にてSSL証明書の有効期限を監視できるようになりました - Mackerel ブログ #mackerelio
先日、京都で今年初の雪が降りました。 京都で雪が降ると、インターネット上に金閣寺の写真がたくさんアップされますね。 寒い日が続きますが、体調など崩さないよう気をつけたいものです。 今週のアップデート情報をお届けします。 SSL証明書の有効期限を監視できるようになりました URL外形監視にて、SSL証明書の有効期限を監視するための設定が新たに追加されました。 SSL証明書の有効期限までの日数が、Warning条件, Critical条件それぞれに設定された日数を下回った際にアラートが通知されます。 また、SSL証明書のアラート発報中にステータスコードやレスポンスタイムなどの異常を検知した際は、アラートの状態が変更されたとみなしてアラートは再通知されます。 詳しくはURL外形監視のヘルプをご覧ください。 mackerel.io これらの設定はAPIからも可能です。 mackerel.io 監視
理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
前方秘匿性 (forward secrecy) をもつウェブサイトの正しい設定方法
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
注目の集まるSNI導入の必要性とは
SSL/TLSの拡張仕様の1つであるSNI（Server Name Indication）に注目が集まっています。 これまでは「1台のサーバ（グローバルIPアドレス）につきSSL証明書は1ドメイン」でしたが、SNIを利用すれば、「1台のサーバで異なる証明書」を使い分けることができるようになります。 それでは、SNIの利用方法やその必要性について確認していきましょう。 SNI（Server Name Indication）とは何だろう？ SSL/TLSでは「同じサーバ（同じグローバルIPアドレスを利用する複数のユーザ）は1つのSSLサーバ証明書しか使えない」のが基本です。そのため、このままだと不便な場合もあります。 たとえばレンタルサーバサービスを例として考えると、「同じサーバを複数のユーザが利用し、なおかつユーザごとに異なるドメインを利用する」という場合もあるでしょう（名前ベースバーチャル
自堕落な技術者の日記 : 「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項」の公開 - livedoor Blog（ブログ）
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 2015年5月7日に「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項(Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS))」が公開されました。 昨年あたり、SSL/TLSで使われる暗号アルゴリズム、プロトコルや実装にいろいろな問題が見つかり、製品をそのままデフォルトで使っているとロクなことが無いわけですが、どんなことに注意しながら実装や設定をしなければならないかをベストカレントプラクティス(現時点での最良の慣行)としてまとめたRFCだそうです。 最近、SSL/T
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The foundation of a more secure web
Acmesmith (http2study8)
Linuxユーザーと公開鍵を統合管理するサーバ&クライアントを書いた[更新] | ten-snapon.com![Linuxユーザーと公開鍵を統合管理するサーバ&クライアントを書いた[更新] | ten-snapon.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/a23b4c4b4227656786e43a9672a23ce5b14a4992/height=288;version=1;width=512/https%3A%2F%2Ften-snapon.com%2Fwp-content%2Fuploads%2F2018%2F07%2FDSC09532.jpg)
SSL/TLSの基礎と最新動向
Node.js HTTPS 400 Error - 'UNABLE_TO_VERIFY_LEAF_SIGNATURE'