OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記
TL;DR やっぱり書いていたら長文になってしまいました。あまりちゃんと推敲する気力がないので、変な文章になっているかもしれません。ご了承いただける方のみお読みください。 1. はじめに 昨晩未明にOpenSSL-1.0.2d, 1.0.1pがリリースされました。事前に予告されていた通り深刻度高の脆弱性CVE-2015-1793が修正されています。Advisoryを見ると、この脆弱性がiojs/Nodeに影響があるということが判明したので直ちにiojs/Nodeのアップデートを行い、今朝未明に無事脆弱性対応版をリリースしました。 今回が初めてではありませんが、深夜に日欧米のエンジニアがgithub上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア
AWS / CVE-2014-3566 Advisory
2015 年 1 月 7 日午前 8 時 30 分 (大洋平標準時) - 更新 Amazon CloudFront: デフォルトの CloudFront ドメイン名 (*.cloudfront.net) で SSL を使用するすべてのお客様に対して SSLv3 を無効にしました。 ---------------------------------------------------------------------------------------- 2014 年 10 月 24 日午後 7 時 30 分 (大洋平標準時) - 更新 Amazon CloudFront: 本日、専用 IP カスタム SSL 証明書の SSLv3 を無効または有効にできる機能を開始しました。この機能の起動前に作成された既存のディストリビューションでは、引き続きデフォルトで SSLv3 が許可されます。専用
r/crypto - OpenSSL bug allows RSA 1024 key factorization in 20 minutes
Thankfully it's very easy to tell whether it's real. If anyone can publish the two, non-trivial factors of this number (where neither is 1!) then they'll have my attention: 0xe5c30e1286c41c7137dc06194199dde641120de591c1b7392de35ef6a961d6d29faa3bcdb7603d42768a90322197a7a46fa2cf23f6f10de5554db6e7322ba35e858f576f840347c795c8782c3f4ef9f530d2fd1f6b5c275ce49404958f0decddd0b53386d12c745891d5eeca1f265bdf8
OpenSSL #ccsinjection Vulnerability
[Japanese] Last update: Mon, 16 Jun 2014 18:21:23 +0900 CCS Injection Vulnerability Overview OpenSSL’s ChangeCipherSpec processing has a serious vulnerability. This vulnerability allows malicious intermediate nodes to intercept encrypted data and decrypt them while forcing SSL clients to use weak keys which are exposed to the malicious nodes. Because both of servers and clients are affected by thi
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
AWS News Blog
AWS Weekly Roundup – AWS AppSync, AWS CodePipeline, Events and More – August 21, 2023 In a few days, I will board a plane towards the south. My tour around Latin America starts. But I won’t be alone in this adventure, you can find some other News Blog authors, like Jeff or Seb, speaking at AWS Community Days and local events in Peru, Argentina, Chile, and Uruguay. If you see […] New – Amazon EC2 H
Heartbleed Bug
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private network
Apache/SSL自己証明書の作成とmod sslの設定 - maruko2 Note.
Apache/SSL自己証明書の作成とmod sslの設定 提供：maruko2 Note. < Apache 移動： 案内, 検索 目次 1 手順 2 秘密鍵の作成 (server.key) 3 CSR（証明書の基になる情報）の作成 (server.csr) 3.1 入力項目の例 4 証明書（公開鍵）の作成 (server.crt) 5 Apache mod_ssl の設定 6 Apache 起動時にパスフレーズの入力を省略する 6.1 秘密鍵 (server.key) ファイルをあらかじめ復号化しておく方法 6.2 Apache起動時のパスフレーズ入力を自動化する方法 7 参考ページ 8 Apache 関連のページ 手順 2017年1月1日以降、SSL 証明書の署名アルゴリズムとして SHA-1 を使用している証明書は SSL 通信ができなくなる。 これは、Windows製品、Goog
iOSアプリで自己証明書を使ったhttps通信
iOS NSURLSession https 通信 のくみあわせで自己署名証明書 (self-signed certificate) を使う場合の話。 allowsAnyHTTPSCertificateForHost: を override するとかいうマヌケなことはしないこと。 (昔のクソ blog などによく書かれていた完全に間違った方法。このご時世では使えなくなっている気がするが未確認) 1. TN2232 を読む 2. TN2326 にある手順で Certificates を作成 3. server.crt を変換 (CA の certificate のはそのままで OK) openssl x509 -in server.crt -outform DER -out server.der 4. DER 形式の ceriticate (2 つ) を xcode の project に
sshd[2001]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
sshd[2001]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use. 又、子供にサーバの電源を落された。で、そこ時に気付いたのだが、/var/log/secureに sshd[2001]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use. とエラーが記録されている。過去のログを調べてみると、どうも3月末くらいから、実はリブートのたびに発生していたようだ。 ちょっと調べてみるとSea-Bird.orgさんのOpenSSL/ OpenSSH(SSH1) の設定に関するメモによると、 使用するボートが既に使用されていた場合 使用するポートが既に使用されていた場合、以下のエラーメッセージが表示されます。 error: Bind to
OpenSSL で作ったサーバ証明書を IIS にインストールする方法
SSL で通信するためには、 - OpenSSL や apache 等で csr と key を作る - csr を証明機関に送る - 署名してもらった crt を受けとる - key と crt をサーバに読みこませてやる という手順を踏む。 ところが IIS に key と crt 読みこませてやろうとすると、 IIS は、鍵の作成を自分でやることが前提の仕組みになっているので、 わりとはまる。 Windows は、いじってるうちになんかうまいことできることがあるので、 なにかできるんじゃないか、とあれこれいじるわけなんだけど、 全然糸口は見付からないのよね。 しかもウェブにもあんまり有用な情報がなかったり。 で、どうするか、なんだけど、 key と crt から PKCS#12 形式の証明書ファイルを作る、 というのが正解。 その形式になってれば右クリックでインストールできて、 II
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Alternative chains certificate forgery (CVE-2015-1793) | OpenSSL Security Advisory [9 Jul 2015]
GitHub - titanous/heartbleeder: OpenSSL CVE-2014-0160 Heartbleed vulnerability test
Heartbleed OpenSSL extension testing tool, CVE-2014-0160