Widespread Weak Keys in Network Devices - factorable.net
We performed a large-scale study of RSA and DSA cryptographic keys in use on the Internet and discovered that significant numbers of keys are insecure due to insufficient randomness. These keys are being used to secure TLS (HTTPS) and SSH connections for hundreds of thousands of hosts. We found that 5.57% of TLS hosts and 9.60% of SSH hosts share public keys in an apparently vulnerable manner, due
Latest OpenSSL bug ‘may be more dangerous than Heartbleed’
Heartbleed was deemed to be one of the most critical internet vulnerabilities ever when it was uncovered in April. OpenSSL is supposed to protect people’s data with digital keys but has been exposed as flawed numerous times in recent months. The latest vulnerability was introduced in 1998 and has been missed by both paid and volunteer developers working on the open-source project for 16 years. Mea
ImperialViolet - Early ChangeCipherSpec Attack
OpenSSL 1.0.1h (and others) were released today with a scary looking security advisiory and that's always an event worth looking into. (Hopefully people are practiced at updating OpenSSL now!) Update: the original reporter has a blog post up. Also, I won't, personally, be answering questions about specific Google services. (I cut this blog post together from notes that I'm writing for internal gro
analysis of openssl freelist reuse
About two days ago, I was poking around with OpenSSL to find a way to mitigate Heartbleed. I soon discovered that in its default config, OpenSSL ships with exploit mitigation countermeasures, and when I disabled the countermeasures, OpenSSL stopped working entirely. That sounds pretty bad, but at the time I was too frustrated to go on. Last night I returned to the scene of the crime. OpenSSL uses
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
Y!J API が止まった日 - GlobalSign の Root 証明書切れから学んだこと - OAuth.jp
昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。 僕もちょっとそういうケース見かけました。 なんか Yahoo! Japan がポカしちゃったの？とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。 が、今回のケース、Yahoo! は全く悪くない！ プライバシーフリークはどうかと思うがな！！ では早速、今回起こったことを、振り返ってみましょう。 Yahoo! API にアクセスできなくなった Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用
スノーデン事件の裏で起きていたSSL秘密鍵を巡る戦い:Geekなぺーじ
今月7日から9日にアリゾナ州で開催されたNANOG 59で、Ladar Levison氏がFBIにサービス全体のSSL秘密鍵を要求された話が公開されていました。 Ladar Levison氏が運営していた、Lavabitという電子メールサービスはスノーデン事件に関連して突如8月8日に閉鎖されています。 閉鎖時には詳細が書かれておらず、様々な憶測が語られていましたが、世界中から多数のネットワークエンジニアが集まるNANOGで、その一部始終が語られました。 この発表は、NANOG 59が開始される前の週に、裁判所が調査対象の氏名以外を機密解除したことによって実現しています。 インターネット上で提供されているサービス事業者にSSL秘密鍵を提出させ、かつ、その事実の公表が違法行為となるようにされてしまっている一方で、こういった内容を公的に語れるように裁判所で戦って、実際にそれを勝ち取るというのは凄
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
JVNVU#94916481: HTTPS レスポンスから暗号化されたデータの一部を推測可能な脆弱性 (BREACH)
圧縮された HTTPS レスポンスの長さを観測することで、攻撃者は HTTPS ストリームの暗号文から、ウェブサイトの認証鍵など (secret) を推測することが可能です。 Salesforce.com の Angelo Prado 氏は、下記の通り報告しています。 Extending the CRIME vulnerability presented at Ekoparty 2012, an attacker can target HTTPS responses to recover data from the response body. While the CRIME attack is currently believed to be mitigated by disabling TLS/SSL/level compression, compressed HTTP respons
SSL/TLS Deployment Best Practices
SSL/TLS Deployment Best Practices Ivan Ristić v1.1 (24 April 2013) Copyright © 2012-2013 Qualys SSL Labs Abstract SSL/TLS is a deceptively simple technology. It is easy to deploy, and it just works…except that it does not, really. The first part is true—SSL is easy to deploy—but it turns out that it is not easy to deploy correctly. To ensure that SSL provides the necessary security, users must put
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
TechCrunch | Startup and Technology News
Unlike Light’s older phones, the Light III sports a larger OLED display and an NFC chip to make way for future payment tools, as well as a camera.
SSLハンドシェイクの仕組み - shibainu55日記
前回(デジタル証明書の中身について)に引き続き、今回はSSLハンドシェイクについて書いていく。まず、SSLハンドシェイクのポイントは以下の2点。 1.クライアントはサーバ証明書によってサーバを認証する。 2.安全度の高い非対称鍵暗号方式を使っているが、それはハンドシェイク時だけ。その後は負荷の低い共有鍵を使用する。共通鍵を非対称鍵暗号方式で交換するため、安全性を維持しながら負荷を低減している。 クライアント認証 SSLでは、サーバがクライアントを認証する「クライアント認証」も可能。この場合、クライアントは自分の証明書である「クライアント証明書」をサーバに提示し、サーバとクライアントが相互に認証手続きを実施する。機密性の高い社内システムやメンバ専用サイト、リモーとアクセスなどで利用されている。実利用例としては、クライアント証明書をUSBキーやICカードに格納し、これをPCに接続しているときだ
Debian JP Project - 最近の話題 - OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等）
OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等） 残念な事に Debian の OpenSSL パッケージに脆弱性が見つかりました。見つかった問題は既に修正されていますが、 今回の問題はパッケージの更新だけで済ませられないものとなっています。 今回の問題は、OpenSSL の乱数生成部分について、Debian の OpenSSL パッケージのメンテナが Valgrind (C/C++ プログラムでのメモリリークなどの問題を見つけるデバッグツール) を使っていて見つけた問題を修正しようとして誤ったパッチを当ててしまった事が原因です。 これによって、乱数が使われずに暗号が非常に弱いものとなってしまう問題が発生しました。 なお、この問題は Debian だけに止まらず Debian をベースとしているディストリビューション (Ubuntu など）やシステムにも影
Debian DSA-1571-1 openssl 予測可能な乱数の生成 - セキュリティホール memo
》 無線LANアダプタが見つからない？ (パソコントラブル出張修理・サポート日記, 5/26)。全角ユーザ名トラブルねた。 》 5月28日22時以降の更新後、ネット接続できない現象について (just-kaspersky.jp, 5/29)。今は直っているらしい。 カスペ方面、なんだかトラブルが続きますねえ。 》 年金・医療・介護に関わる情報を住基カードに載せる(かも) (slashdot.jp, 5/31) 》 有害サイト規制法案に懸念表明 ネット５社とＰＴＡ (asahi.com, 5/31) 》 高１自殺：ネット上に「死ね」と書かれ苦に 北九州 (毎日, 5/31)。 読売新聞報道だと「自分のブログ」になっているなあ。 》 「ケータイ世界の子どもたち」はクリーンヒット (落伍弟子のブログ, 5/26)。奥村先生も推奨しています。 》 フジ佐々木恭子アナのキーボードはトイレよりキレイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Furlでhttpsリクエストがtimeoutになる場合がある件
https://sgddemo.sun.com/tarantella/help/ja-jp/tsp/gettingstarted/secure_ldap.html
Naming and Directory (JNDI) - no support for RSA/ECB/PKCS1Padding after upgrade to 1.5
Java Secure Socket Extension (JSSE) - RSA premaster secret error