OpenSSLで作ったオレオレ証明書を使ったHTTPS通信をのぞいてみる。 - それマグで！
このエントリがおもしろそうだったのでOSX でやってみた。 オレオレ証明書をopensslで作る（詳細版） WiresharkでSSL通信の中身を覗いてみる 実際にやったこと。 openssl の自己証明を使って、HTTPSの実験サーバーを作る。 HTTPSの通信の中身をのぞいてみまみる Apache+mod_sslを openssl で用意しました。 オレオレ証明書を使ってHTTPSサーバーを作った 今回はOSX の組み込みApacheの設定変更で対応することにする。 本来、cert (certification)は、認証局に署名して貰うのだが、今回は自分で自分を証明する。オレオレ証明書を使う 秘密鍵（server.key）の作成 openssl genrsa 2048 > server.key 公開鍵（server.csr）の作成 openssl req -new -key serve
opensslでRSA暗号と遊ぶ - ろば電子が詰まつてゐる
opensslとRSA暗号についてちょっと調べてみようかな、と思った。 まずRSA暗号とは、 公開鍵暗号方式の実装のひとつである 2つの素数の積(ケタ数が大きい場合の素因数分解の困難さ)を利用している ってことを理屈としては理解しているけど、実際にopensslコマンドで作った鍵ファイルの中身がどうなっているのか? ということまで踏み込んだことが無かった。 というわけで、ちょっとその辺をコマンド叩きながら遊んでみることにする。 はじめに：opensslの操作について opensslコマンドは増築に増築を重ねすぎており、もはやそびえ立つ××のようである。ヤヴァいことになったレベルで機能てんこ盛りのコマンドなので、サブコマンドとして機能名を指定して使うことになる。 openssl command [ command_opts ] [ command_args ]上例の「command」には、R
オレオレ証明書をopensslで作る（詳細版） - ろば電子が詰まつてゐる
前回のopensslでRSA暗号と遊ぶでRSA暗号や秘密鍵について中身を色々といじってみた。続いて今回は、Apacheで使うオレオレ証明書を作ってみる。 細かいことはいいから、オレオレ証明書を作るコマンドだけ知りたい お急ぎの方は、以下3つだけやれば良い。これで10年間(3650日)有効なオレオレ証明書ができあがる。 $ openssl genrsa 2048 > server.key $ openssl req -new -key server.key > server.csr $ openssl x509 -days 3650 -req -signkey server.key < server.csr > server.crtできあがったserver.crtとserver.keyを、例えば/etc/httpd/conf/ 配下のssl.crt/ と ssl.key/ ディレクトリに設置
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
コンピュータに詳しくない人へ。インターネット史上最悪のOpenSSLの脆弱性のニュースをわかりやすく書いてみました。ほとんどすべての人に影響します。 - 非天マザー by B-CHAN
インターネットで使われる鍵（カギ） みなさん、こんにちは！ こんなニュースが発表され、世界に衝撃を与えています。 ↓ Gmail、YouTubeにも影響。壊滅的なOpenSSLの脆弱性、「Heartbleed」問題とは « WIRED.jp コンピュータ関係者は大騒ぎですが、ボクたち一般人はどうすればいいのでしょうか？ コンピュータに詳しくない人に、なるべくわかりやすく書いてみます。 まず、インターネットのいろんなサービスを利用するにはIDとパスワードが必要ですよね。 例えば、Amazonや楽天市場で買物をするには、Amazonや楽天市場のIDとパスワードを入力する必要があります。 どちらかが欠けても買い物はできません。 あなた以外の第三者があなたのIDを知ったとしてもパスワードがわからなければ、あなたの名前で勝手に買い物をすることはできないわけです。 これによって安全が守られているわけで
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 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の脆弱性で想定されるリスクとして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
