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" と書いてあることから一気にではなく
mixed contents 対応を促進する CSP ディレクティブ | blog.jxck.io
Intro HTTPS 移行の問題点の一つに、mixed contents への対応がある。 逆に mixed contents の発生を恐れ、HTTPS に移行できないサービスもあるだろう。 本エントリでは mixed contents の正しい理解と、その検出や解消に利用できる可能性のある、CSP の Upgrade-Insecure-Request および、Block-All-Mixed-Contents を解説する。 mixed contents HTTPS で配信されたコンテンツが、サブリソースとして HTTP のコンテンツを含む場合、これを mixed contents という。 HTTPS は MITM に対する耐性があるが、HTTP は MITM への耐性がないため、mixed contents の状態ではサブリソースを起点にメインコンテンツへの改ざんが成立してしまう可能性
YAPC::Hokkaido 2016 - iOS/AndroidアプリにおけるAPIサーバーのいろは
すべての API は SSL にすべし！ 2016 end らへんからiOS は App Transport Security (ATS) によって SSL にすることが推奨されている 実際にはアプリ申請の際に詳細な理由を書くことにより、審査を通過する可能性はある HTTP/2 の台頭により、今後 SSL 化の波は避けて通れない SSL ではない通信は内容の傍受が容易でありセキュアとは言い難い ユーザーに安心して利用してもらいたい！ すべての API は SSL にすべし！ SSL アクセスで利用するプロトコルはどうするか？ すべての API は SSL にすべし！ SSL アクセスで利用するプロトコルはどうするか？ 現時点では HTTPS でよいと考えている すべての API は SSL にすべし！ SSL アクセスで利用するプロトコルはどうするか？ 現時点では HTTPS でよいと考え
Web over HTTPS
Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/0
Google Public DNS over HTTPS を試す | IIJ Engineers Blog
【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
Geolocation API removed from unsecured origins in Chrome 50 | Web Updates - Google Developers
Chrome has public intent to deprecate powerful features like geolocation on non-secure origins, and we hope that others will follow. Starting with Chrome 50, Chrome no longer supports obtaining the user's location using the HTML5 Geolocation API from pages delivered by non-secure connections. This means that the page that's making the Geolocation API call must be served from a secure context such
Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
Modern Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES1
無料のSSL証明書StartSSLを活用する - Qiita
背景 自前のサービスでhttps通信をサポートするには、SSL証明書が必要になります。 自分で使用するだけなら、SSL証明書も自前で作成するいわゆるオレオレ証明書を用いても良いのですが、外部に公開するサービスの場合そうとも行きません。 SSL証明書というと値段が高い印象がありましたが、StartSSLというサービスで無料でSSL証明書の発行を受けられると言うことで試してみました。 StartSSLにユーザー登録する 証明書の発行を行う前に、StartSSLにユーザー登録する必要があります。 StartSSLから、"StartSSL Free (Class1)"を選択します。 Certificate Control Panelを選択。 Sign-upに進みます。 名前、住所、メールアドレスなど 個人情報の登録を行います。 登録したメールアドレスに本人確認のメールが届くので、受信したメールのa
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
cookpad.com 全 HTTPS 化の軌跡
The foundation of a more secure web