サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
TL;DR やっぱり書いていたら長文になってしまいました。あまりちゃんと推敲する気力がないので、変な文章になっているかもしれません。ご了承いただける方のみお読みください。 1. はじめに 昨晩未明にOpenSSL-1.0.2d, 1.0.1pがリリースされました。事前に予告されていた通り深刻度高の脆弱性CVE-2015-1793が修正されています。Advisoryを見ると、この脆弱性がiojs/Nodeに影響があるということが判明したので直ちにiojs/Nodeのアップデートを行い、今朝未明に無事脆弱性対応版をリリースしました。 今回が初めてではありませんが、深夜に日欧米のエンジニアがgithub上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア
AWS / CVE-2014-3566 Advisory2015/01/07 8:30 AM PST - Update -Amazon CloudFront: We have disabled SSLv3 for all customers who use SSL with the default CloudFrontdomain name (*.cloudfront.net). ---------------------------------------------------------------------------------------- 2014/10/24 7:30PM PDT - Update -Amazon CloudFront: Today, we launched the feature that allows customers to disable or enable SSLv3 for Dedicate
[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
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも)SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
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 NewsBlog authors, like Jeff or Seb, speaking atAWS Community Days and local events in Peru, Argentina, Chile, and Uruguay. If you see […] New –Amazon EC2 H
The Heartbleed Bug is a serious vulnerability in the popular OpenSSLcryptographic 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 communicationsecurity andprivacy over the Internet for applications such as web,email, instant messaging (IM) and some virtual privatenetwork
Apache/SSL自己証明書の作成とmod sslの設定 提供：maruko2Note. < 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 NSURLSession https 通信 のくみあわせで自己署名証明書 (self-signedcertificate) を使う場合の話。 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
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ページを開く
