個人証明書を作ろう～S/MIMEでメールに電子署名と暗号化を、サーバーにはクライアント認証を～
～S/MIMEでメールに電子署名と暗号化を、サーバーにはクライアント認証を～ 個人証明書を作成しましょう。 この個人証明書で電子メールの代表的な暗号化方式S/MIME(Secure MIME)を利用できるようになります。 PostfixのSSL化でもメールの暗号化は行われましたが、S/MIMEとは本質が違います。 メールサーバーのSSL化というのは、あくまでもメール経路の暗号化に過ぎません。 ですからユーザーからサーバー間は暗号化できますが、サーバーから相手サーバー、相手サーバーからメールの送信相手までの経路は暗号化されていなかったわけです。 これに対しS/MIMEの場合はメールそのものを添付ファイルまで含めて暗号化しますから、相手が復号するまでは完全に暗号化されています。 S/MIMEを利用できれば、メール本文に関してはPostfixのSSL化は必要ないと言えます。（でもSMTP-AUT
オレオレ証明書を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/ ディレクトリに設置
opensslでRSA暗号と遊ぶ - ろば電子が詰まつてゐる
opensslとRSA暗号についてちょっと調べてみようかな、と思った。 まずRSA暗号とは、 公開鍵暗号方式の実装のひとつである 2つの素数の積(ケタ数が大きい場合の素因数分解の困難さ)を利用している ってことを理屈としては理解しているけど、実際にopensslコマンドで作った鍵ファイルの中身がどうなっているのか? ということまで踏み込んだことが無かった。 というわけで、ちょっとその辺をコマンド叩きながら遊んでみることにする。 はじめに：opensslの操作について opensslコマンドは増築に増築を重ねすぎており、もはやそびえ立つ××のようである。ヤヴァいことになったレベルで機能てんこ盛りのコマンドなので、サブコマンドとして機能名を指定して使うことになる。 openssl command [ command_opts ] [ command_args ]上例の「command」には、R
理解してるつもりの 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
Androidアプリの多くにSSLセキュリティ脆弱性 - MITM攻撃が可能な状態
FireEyeは8月20日(米国時間)、「SSL Vulnerabilities: Who listens when Android applications talk?｜FireEye Blog」において、人気のあるAndroidアプリ1,000個に関して調査を実施したところ、そのうち約68%にSSL関連の何らかのセキュリティ脆弱性が存在していたと伝えた。これらセキュリティ脆弱性を利用されるとMan-in-the-Middle攻撃(MITM)を受ける危険性があるとされている。 アプリの中には機能や利便性を優先させるためにホスト名のチェックを無効にしているものがあったりSSL関連のエラーを無視しているものがあったと説明がある。Man-in-the-Middle攻撃を受けると、攻撃者は通信内容を傍受することができるほか、接続先をほかのサイトへ変更するといったことができる。 記事ではこうした問
史上最悪のネットセキュリティ危機と騒がれてる「Heartbleed」問題に関するメモ（よくわかっていない素人レベル） - The Midnight Seminar
※2014/4/15 すこし追記 数日前から話題になりまくっているように、Heartbleedと呼ばれるインターネット史上最悪ともいわれるセキュリティ危機が起きているらしい。 私はインターネットの技術をよく分かってないので、具体的に何がやばくて何をしたらいいのかがあまり理解できないのだが、放置するのもあれなので、関連する一般向けの記事だけは読んでみた。 で、結局のところ、われわれにできることとしてはパスワードを変えるぐらいしか対策はなく、あとは将来に向けてセキュリティ意識を高めましょうぐらいのことしか言えないみたいなので、深く考えるのはやめたのだが、とりあえず読んだものについてはまとめておくことにした。 このエントリの前半はリンクの羅列ですが、後半はド素人が自分の大まかな理解を確認するために書いてるような感じなので、内容は信用しないで、専門家の説明を読みにいってください。*1 まず、とにか
ウェブを襲った最悪のセキュリティ災害「Heartbleed」から自分の身を守る方法 | readwrite.jp
インターネット上での買い物や財産管理、電子メールの送受信などにおけるプライバシーを守ってくれるはずのセキュリティ・ソフトに関する重大なバグ、「Heartbleed」が最近発見された。今のところ、このバグによる実際のファイナンス情報やアカウント情報その他に関する傍受や盗難に繋がるような被害は報告されていないが、恐らくそれは時間の問題だ。 良いニュースは、こうした傍受や盗難から自分の情報を保護する方法があるということ。悪いニュースは、それらの対策は単純だが必ずしも簡単ではないということだ。 なぜ Heartbleed は深刻なのかまず簡単に背景を説明しよう。ハッカーなどの攻撃者が Heartbleed バグを悪用した場合、サイト上のウェブ・コミュニケーションを保護してくれるはずの、OpenSSLと呼ばれるオープンソースの暗号化セキュリティ技術を迂回できてしまう。このバグによって攻撃者はウェブサ
ネット上のサイトの約66％が使用するOpenSSLに重大なバグが発見される
By Nguyen Hung Vu インターネット上で標準的に利用される暗号通信プロトコルのSSL/TLSを実装したオープンソースのライブラリ「OpenSSL」に、SSL/TLSの暗号化によって保護されている情報が特殊な環境下でなくても盗まれてしまう脆弱性が発覚しました。 Heartbleed Bug http://heartbleed.com/ 「Heartbleed Bug」と名付けられた脆弱性は、OpenSSLの1.0.1から1.0.1fまでのバージョンで発見されたもので、脆弱性が悪用されると、これらの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ページを開く
3時間で分かるこれからの電子認証—Internet Week 2009レポート | レンタルサーバー完全ガイド