暗号スイートの暗号強度と、公開鍵のビット数の設定、及びRSAとECDHEでサーバ負荷の比較 - Apache 2.4系でHTTP/2対応サーバを構築してみるテスト。
見ず知らずの他人同士が、リーズナブルな計算量で、秘密の通信を行うためには、公開鍵暗号と秘密鍵暗号を組み合わせる必要があります。 この暗号の組み合わせのことを「暗号スイート」と呼びます。 OpenSSLには、多くの暗号スイートが用意されています。どの暗号スイートを選べばいいのか、迷ってしまうと思います。 そして、暗号スイート全体としての暗号強度は、公開鍵の強度も関係してきます。 ここでは、総当たり攻撃の耐性を基準に、暗号スイートと公開鍵の決め方を説明していきます。 以下、私の独断と偏見ですが、なぜGoogleやFacebookが、ECDHE(256bit)-ECDSA(256bit)-AES(128bit)の暗号スイートを使用するのか、ご理解いただけると思います。 併せて、Apache Webサーバ(httpd)のECDHEのビット数の変更方法(P-256, P-386)も、説明しています。
ハートブリード - Wikipedia
ハートブリードのロゴ。ロゴと「心臓出血」の名称はこの問題に衆目を集めて、啓蒙するために作られた[1][2] ハートブリード（英語: Heartbleed）とは、2014年4月に発覚したオープンソース暗号ライブラリ「OpenSSL」のソフトウェア・バグのことである。当時、信頼された認証局から証明書が発行されているインターネット上のWebサーバの約17％（約50万台）で、この脆弱性が存在するHeartbeat拡張が有効になっており、サーバーの秘密鍵や利用者のセッション・クッキーやパスワードを盗み出すことが出来る可能性があった[3][4][5][6][7]。 経緯[編集] OpenSSLの脆弱性がCVSレポジトリに混入したのは2011年12月31日であり、原因はロビン・セゲルマンが提出し[8][9]、OpenSSLの開発チームがレビュー（審査）[10] した善意のパッチ（改善コード）である。脆弱
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記
TL;DR やっぱり書いていたら長文になってしまいました。あまりちゃんと推敲する気力がないので、変な文章になっているかもしれません。ご了承いただける方のみお読みください。 1. はじめに 昨晩未明にOpenSSL-1.0.2d, 1.0.1pがリリースされました。事前に予告されていた通り深刻度高の脆弱性CVE-2015-1793が修正されています。Advisoryを見ると、この脆弱性がiojs/Nodeに影響があるということが判明したので直ちにiojs/Nodeのアップデートを行い、今朝未明に無事脆弱性対応版をリリースしました。 今回が初めてではありませんが、深夜に日欧米のエンジニアがgithub上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア
Apache 2.2.* 系と OpenSSL での HTTPS の利用 - Linux サーバ認証 編 -
Apache 2.2.* 系と OpenSSL での HTTPS の利用 - Linux サーバ認証 編 - ここでは、Apache 2.2.* 系と OpenSSL を使用して HTTPS 通信を行います。 サーバ認証について簡単に説明いたします。 一般的に HTTPS 通信 ( 通信経路の暗号化 ) を使用する場面というのは、 個人情報の送信や クレジットカードの情報などの送信において必要になると思います。 なぜ必要かというと、それらの情報は他に漏れてはいけない情報であり、もし平文で送信したならば、 途中の通信経路のどこかで第三者に、その情報を見られてしまう可能性があり、重大な結果を招きかねません。 そのような結果を防ぐ目的があり、HTTPS 通信を行います。 しかし、ここで以下の条件を満たす必要があります。 ・通信経路の暗号化 ・情報を送信するサーバが本当に実在し、自分が送
OpenSSLの脆弱性(CVE-2014-3511)でTLSプロトコルの基礎を学ぶ - ぼちぼち日記
1. はじめに、 昨日 OpenSSLのバージョンアップがアナウンスされ、９つの脆弱性が公開されました。バージョンアップの数日前にOpenSSLの次期リリース予告がアナウンスされていましたが、ちょうど BlackHat 開催初日にあたることもあり、なんかまた重大な脆弱性の修正が入るんじゃないかとドキドキしていました。蓋を開けてみるとHeatBleed程の大事ではなくホットひと安心です。 昨日公開されたOpenSSLの９つの脆弱性のうち、TLS プロトコルダウングレード攻撃 (CVE-2014-3511)の修正を見ていたところ、これはTLSプロトコルを学ぶいい題材になるなぁとふと思いつき、試しにこのOpensslの脆弱性の詳細をTLSプロトコルの基礎に合わせて書いてみました。 ちょっと長いですが、TLSプロトコルの仕組み（の一部）を知りたい方はお読みください。 2. OpenSSLの脆弱性
OpenSSLのWebサイトに改ざん被害、ソースコードは無事
OpenSSLが使っているプロバイダーのパスワードセキュリティの不備を突いてハイパーバイザーの管理コンソールを制御され、OpenSSLの仮想サーバが操られていたことが分かった。 オープンソースのSSL／TLS実装ツールキット「OpenSSL」のWebサイトが改ざんされる被害に遭った。ハイパーバイザーを通じて攻撃が仕掛けられていたことが判明し、セキュリティ機関などが対策を促している。 OpenSSLのサイトに掲載された1月3日付の告知によると、「www.openssl.org」のホームページ改ざんは2013年12月29日に発生した。数時間後には復旧し、調査と対応に乗り出したという。 OpenSSLは仮想サーバを使っていて、同じインターネットサービスプロバイダー（ISP）の顧客との間でハイパーバイザーを共有しているという。調査の結果、このISPのパスワードセキュリティの不備を突いて攻撃が仕掛け
OpenSSL CSR, 証明書など確認コマンド - tech-memo＠さかにゃ日記
[カテゴリ:others] 秘密鍵の内容を確認 openssl rsa -in key.pem -text CSRの内容を確認 openssl req -inform der -in req.der -text openssl req -in req.pem -text 証明書の内容を確認 openssl x509 -inform der -in cer.der -text openssl x509 -in cer.pem -text CRLの内容を確認 openssl crl -inform der -in crl.der -text openssl crl -in crl.pem -text
OpenSSLで自己認証局と証明書の作成 - bnote
まず、OpenSSLがインストールされているとして進めます。 本来、信頼のある認証局に認証してもらいますが 今回は、自分で認証するための自己認証局を作成します。 CAの作成は、/usr/local/ssl/CAに行います。 あらかじめディレクトリを作成しておきます。 OpenSSLがインストールされているディレクトリにある miscディレクトリにCA.shというスクリプトがあります。 このスクリプトで認証局を構築することができます。 CA.shをCAの作成場所にコピーします。 cp CA.sh /usr/local/ssl/CA 構築する場所等を変更するためスクリプトを少し修正します。 openssl.cnfの[CA_default]-dirも同様に修正します。 DAYS="-day 3650" CATOP=/usr/local/ssl/CA CAKEY=./cakey.pem CACER
OpenSSLでお手軽に自己証明書(2)_opensslコマンド « SawanoBlog.
前回の記事の中で少しだけ言及した、opensslコマンドで自己証明書のキーペアを作成する方法。 ちなみにSSLv3/TLS対応で、IISで使える形式も作れます。 事前にキーペアを作成する手順を簡単にまとめておきます、結構この流れは社内でも新人さんとかよく迷うので。 そう複雑ではないのですけどね。 サーバの秘密鍵を作成する 秘密鍵を基にして証明書要求(CSR)を発行する CSRにサーバ秘密鍵を使いまわして署名、証明書作成 サーバ秘密鍵＋証明書でキーペア完成、CSRはもういらない 要は同じ公開鍵が作れる秘密鍵と証明書の2つがあればSSL通信を設定することができる、というわけですね。 有料の証明書サービスを使う場合は、手順2で作ったCSRを業者さんに渡して、証明書を作ってもらえばOK。 では手順のほうへ。 サーバの秘密鍵を作成する トリプルDESで秘密鍵を作成します、これより弱い方式で
SSLの自己証明書の発行覚書 - stnard.jp
Tweetいつも忘れるのでコマンドだけ貼っとく。 参考：Apache/SSL自己証明書の作成とmod sslの設定 – maruko2 Note. 秘密鍵の作成
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
NISCC-224012: OpenSSL に複数の脆弱性
US-CERT Technical Cyber Security Alert TA04-078A Multiple Vulnerabilities in OpenSSL US-CERT Vulnerability Note VU#288574 OpenSSL contains null-pointer assignment in do_change_cipher_spec() function US-CERT Vulnerability Note VU#484726 OpenSSL contains a flaw in the code that processes SSL/TLS handshakes when configured to use the Kerberos cipher suites US-CERT Vulnerability Note VU#465542 OpenSSL
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「OpenSSL 3.0.0」が公開 ～ライセンスは「Apache License 2.0」に／新しいFIPSモジュールが組み込まれる
/docs/man1.1.0/man1/openssl-s_client.html