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
1. はじめに、 昨日 OpenSSLのバージョンアップがアナウンスされ、９つの脆弱性が公開されました。バージョンアップの数日前にOpenSSLの次期リリース予告がアナウンスされていましたが、ちょうど BlackHat 開催初日にあたることもあり、なんかまた重大な脆弱性の修正が入るんじゃないかとドキドキしていました。蓋を開けてみるとHeatBleed程の大事ではなくホットひと安心です。 昨日公開されたOpenSSLの９つの脆弱性のうち、TLS プロトコルダウングレード攻撃 (CVE-2014-3511)の修正を見ていたところ、これはTLSプロトコルを学ぶいい題材になるなぁとふと思いつき、試しにこのOpensslの脆弱性の詳細をTLSプロトコルの基礎に合わせて書いてみました。 ちょっと長いですが、TLSプロトコルの仕組み（の一部）を知りたい方はお読みください。 2. OpenSSLの脆弱性
クライアント証明書で認証しているサイトに対して、wgetでアクセスする方法を紹介します。 クライアント認証を要求するサイトにアクセスしたい場合、通常であればクライアント証明書をWebブラウザに登録して利用します。 これをwgetで利用する場合、秘密鍵・CA証明書・クライアント証明書の3つを別々のファイルとして取り出す必要があります。 利用するクライアント証明書はPKCS12フォーマットのclient-cert.p12であるとしましょう。この場合に秘密鍵と証明書を取り出す方法は次の通りです。 $ openssl pkcs12 -in client-cert.p12 -clcerts -nokeys -out client-cert.crt.pem Enter Import Password: MAC verified OK $ openssl pkcs12 -in client-cert.p
Modern Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES1
三菱UFJニコスのWebサイトが不正アクセスを受け、会員情報が不正に閲覧されたと発表しました。ここでは関連する情報をまとめます。 概要 2014年4月11日に三菱UFJニコスが自社Webサイトで不正なアクセスを検知し、Webサイトを停止。その後詳細な調査結果として、4月18日に第3報を公開し、そこでOpenSSLの脆弱性(恐らくCVE-2014-0160)を悪用した不正アクセスであったことを報告。 三菱UFJニコスの不正アクセスに関連した発表 2014/4/11 弊社Webサイトへの不正アクセスについて(PDF) 2014/4/12 不正アクセスに伴い停止させていただいた弊社Webサービス再開のお知らせと会員様へのお願い(PDF) 2014/4/18 弊社会員専用WEBサービスへの不正アクセスにより一部のお客さま情報が不正閲覧された件(PDF) (1) 被害状況 不正閲覧会員数 894名(
Microsoftの中の人で、OSSとWeb技術を推進するScott Hanselmanが書いたブログ記事 "Open Source is a thankless job. We do it anyway." を勝手に翻訳。 オープンソースは難しい。 セキュリティは難しい OpenSSLの最近の "Heartbleed" バグに関する記事がたくさん出回っている。技術的な分析をすべて読んだら丸一日つぶれてしまうだろうが、 その中にこれはと思う見出しがあった。『OpenSSLはオープンソースの大きな問題を示している。資金不足、人員不足』だ。インターネットを織りなす基本の部分は、ほとんどの場合たった一人によるもので、あとはたくさんのボランティアだ。 〝魅惑的で気が遠くなるような事実とは、ネットワークインフラストラクチャにはこのように重大な部品が存在していて、インターネットの大部分で実際に動いてい
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
サーバに設定されている証明書を確認する方法 ブラウザからの接続では、中間CA証明書が正しく設定されているかなどの詳細を確認することができないため、詳細を確認するにはopensslコマンドが有効です。 コマンドの例 openssl s_client -connect ssl.example.org:443 -showcerts デフォルトのポート番号は以下のとおりです。 HTTPS 443 POP over SSL 995 SMTP over SSL 465 IMAPS 993 出力結果の例 グローバルサインのサーバ証明書は3階層ですので、ルート証明書の下には2枚の証明書が存在しています。 [-----BEGIN CERTIFICATE-----] から [-----END CERTIFICATE-----] までが証明書です。 1枚目はお客様の証明書、2枚目は中間CA証明書であるこ
OpenSSLを使うと、次のようにして2048bitのRSA鍵が作成できる。 $ openssl genrsa 2048 Generating RSA private key, 2048 bit long modulus ......................+++ .................+++ e is 65537 (0x10001) -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAui/OeOYeMrLv+U2w13hQkL204OQVlB05nksKa5LaNE6mT3WY (snip) -----END RSA PRIVATE KEY----- ここで出力される内容は、ASN.1という構文規則で表現された情報をDERと呼ばれるバイナリ形式にし、それをさらにBase64エンコードしたものになっている。 このフォーマット
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
