華麗なる因数分解:FREAK攻撃の仕組み - ぼちぼち日記
1. はじめに ちょうど今朝 OpenSSLをはじめとした様々なTLS実装の脆弱性の詳細が公表されました。 この InriaとMSRのグループは以前からTLSのセキュリティに関して非常にアクティブに調査・検証をしているグループで、今回も驚きの内容でした。 このグループは、TLSのハンドシェイク時の状態遷移を厳密にチェックするツールを開発し、様々なTLS実装の脆弱性を発見・報告を行っていたようです。 特にFREAKと呼ばれるOpenSSLの脆弱性(CVE-2015-0204)に関しては、ちょうど修正直後の1月初めに Only allow ephemeral RSA keys in export ciphersuites で見ていましたが、具体的にどのように攻撃するのかさっぱりイメージできず、あのグループだからまた超絶変態な手法だろうが、まぁそれほど深刻じゃないだろうと見込んでいました。 今回
Superfish/eDellRootが危険な理由 - めもおきば
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
SQLインジェクション対策もれの責任を開発会社に問う判決
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
ブログの完全HTTPS化を完了、HTTPからHTTPSへの移行プロセスを共有
[対象: 上級] 気付いている人もいるかと思いますが、このブログ全体をHTTPSにしました。 この記事では、備忘録を兼ねて、完全HTTPSへの移行を検討しているサイトの参考になるように僕が実行してきたプロセスをまとめます。 実行した主な作業は次のとおりです。 サーバー証明書の取得 HTTPSへのリダイレクト 内部リンクの修正 各種ツール・パーツのHTTPS動作確認 すべてのコンテンツがHTTPSでダウンロードされているかを確認 WordPressの設定変更 rel=”canonical”の更新 ウェブマスターツールへの登録 サイトマップの更新 ソーシャルシェアの引き継ぎ HSTSの設定 外部リンクの更新 高速化 順に説明します。 1. サーバー証明書の取得 サーバー証明書をまず取得します。 手順は利用しているサーバー会社によって変わってきます。 詳しくはお使いのサーバー会社のヘルプを参照し
妻に公開鍵暗号を教えてみた - 西尾泰和のはてなダイアリー
何気なく放送大学をつけていたら公開鍵暗号の話をしていた。 妻「この話、何度聞いてもわかんないのよね」 僕「え、どこがわからない？どこまではわかってる？」 妻「平文はわかるけど、鍵を共有するとか秘密にするとか、署名するとかがよくわからない」 僕「あー、鍵に例えているのが逆効果なのか」 「鍵」をNGワードに指定 僕「じゃあ『鍵』という言葉を使わずに説明してみよう。暗号って『平文を暗号文に変換する方法』で伝えたい文章を暗号文に変えて送り、受け取った人はそれに『暗号文を平文に戻す方法』を使って元の文章を得るわけだ。その目的は、途中の通信文が敵に取られたりしても通信の内容がバレないようにするため。」 妻「うん」 僕「昔の暗号化の方法は、片方の方法がわかるともう片方の方法も分かった。例えば『アルファベットを後ろに1個ずつずらすと平文に戻せます』って教えてもらったら、『なるほど、前に1個ずつずらせば暗号
Canvas Fingerprintingはクッキーより怖いのか技術的に調べてみた｜TechRacho by BPS株式会社
morimorihogeです。最近忙しくて遠征すらおぼつかない状態です。夏イベント資源足りるのかこれ。 なんかはてブ界隈などでCanvas Fingerprintingの話題が出ていて、Cookieより怖い！とか、Adblockみたいに無効にする方法がないのにユーザトラッキングできて怖い！！といったアオリの記事がぽこぽこ出てきているようです。 でも、ざっと調べた限りの日本語のどの記事を読んでも、具体的にどうやってユーザ個々のトラッキングができるようになるのか、技術的に解説されている記事が見つかりませんでした。 というわけで、エンジニアとしてはここは一つキッチリ理解しておきたいと思い、調べた結果をまとめます。 もし僕の読解がおかしくて変なことを言っている部分があれば、はてブやTwitter、コメント欄などで指摘して頂ければ更新していこうと思いますので、マサカリ上等です ;) Canvas F
ベネッセの情報漏えいをまとめてみた。 - piyolog
2014年7月9日、ベネッセホールディングス、ベネッセコーポレーションは同社の顧客情報が漏えいしたと発表を行いました。ここではその関連情報をまとめます。 (1) 公式発表と概要 ベネッセは同社の顧客情報が漏えい、さらに漏えいした情報が第三者に用いられた可能性があるとして7月9日に発表をしました。また7月10日にDM送付を行ったとしてジャストシステムが報じられ、それを受けて同社はコメントを出しています。またさらにその後取引先を対象として名簿を販売したと報じられている文献社もコメント及び対応について発表しています。7月17日にECCでも漏えい情報が含まれた名簿を使ってDMの発送が行われたと発表しています。 ベネッセホールディングス(以下ベネッセHDと表記) (PDF) お客様情報の漏えいについてお詫びとご説明 (PDF) 7月11日付株式会社ジャストシステムのリリースについて (PDF) 個人
CentOS6＋NginxでECDHEを有効にしてForward Secrecy取得までのメモ - 不意に何かを残すブログ
昨日は鍵共有を甘く見て爆死したためCentOS＋NginxのサーバーをWindows環境に対応させてみる。 RPMに慣れていた都合上、主なサーバーにCentOS6を使っている。 CentOS/RHEL6.4では2013年10月時点で、標準のOpenSSLは1.0.0、Nginxは1.0系が導入される。Nginxには公式リポジトリもあるが、openssl-1.0.0を前提にビルドされている。 これらはコミュニティサポートのあるRPMで提供されているものの、NginxでHTTPSサーバーを建てようとすると、TLSはv1.0 まで、対応cipherはDHE-RSA-AES-SHAまでになり、QualsysのSSLテストでは色々と指摘される。 問題点 既存のパッケージで対策不能なのは、TLS1.2対応（兼BEAST対策）とRSA鍵共有。 BEASTは未対策のブラウザがTLSv1.0以前のCBCモー
Lavabit 事件とその余波、そして Forward Secrecy - セキュリティは楽しいかね？ Part 2
Lavabit事件 Lavabitという名前をみなさんご存知だろうか。NSAの監視活動について内部リークを行った Edward Snowden氏が利用していたメールサービスとして今年の夏に一躍有名になったところだ。Snowden氏は香港に滞在して複数のジャーナリストにNSAの内部情報を提供したあと、現在はロシアに一時亡命しているが、亡命が認められる前にモスクワ空港にしばらく滞在していたことがある。7月12日に空港内でプレスカンファレンスを行ったのだが、その時複数の人権団体に送った招待状が “edsnowden@lavabit.com” というメールアドレスからだった。この事が報道されると、「あの」Snowden氏が使っているメールサービスということで、利用希望者が殺到したらしい。(それまで新規登録は 200人/日だったのが、4,000人/日と20倍になった。) しかしそんな表の騒動の影で、
はじめに – まいとう情報通信研究会
ＲＳＡ暗号は、インターネットでも広く利用されている話題の暗号です。 この暗号をはじめとする現代の暗号は、かつて戦時中に一部組織でのみ使用われた暗号とは異なり、情報セキュリティを確保するための基盤技術として、情報ネットワーク社会に生きる我々に安心を与えてくれるものです。無意識のうちに利用している方もいるでしょうし、既にこの社会にとって必要不可欠なものとなっています。 こうした現代暗号には、ＲＳＡ暗号の他にも ＤＥＳ（デス、ディ・イー・エス）やＡＥＳ（エー・イー・エス）など、数多くの方式があります。その多くは複雑な設計であるのに対し、最も特徴的なＲＳＡ暗号のエッセンスは非常に単純かつ興味深い理論によって成り立っています。この「からくり」がどんなものなのかを知らないままでは、何だかもったいなくありませんか？ この読み物は、現代暗号をＲＳＡ暗号を中心に分かり易く解説したものです。詳しい話はこの先を
LINE「独自暗号化」のメリットと安全性について
LINEが使用している「独自の」暗号化手法について、情報が一部開示（参照：LINEの暗号化について « LINE Engineers' Blog）され、Twitterでもやりとりをしたので、まとめてみる。 ■なぜTLSを使わないか TLSではなく、１パスのメッセージ暗号化を使っている理由については、Adopting SPDY in LINE – Part 2: The Details « LINE Engineers' Blogに以下のような記載があり、TLSを使うことによるレイテンシの増加を懸念しているためと考えられる。 3G mobiles networks normally operate at slow speeds. （中略）If the connection changes modes when the user sends a message, we are forced t
もっと安全なメッセンジャーを考える - 雑種路線でいこう
前の記事ではFACTAの記事が事実と仮定した場合に韓国政府が認めたのは韓国国内利用者-日本のLINEデータセンター間の平文通信の傍受で、日本国内での利用を韓国当局が適法に傍受することは難しいと書いた。技術的にはSSL秘密鍵やサーバーに蓄積された情報が狙われ得るものの、日本国内での通信傍受は司法傍受を除いて違法で、事業者が法的手続きを経ずに外国当局に情報提供すれば電気通信事業法の「通信の秘密」に觝触するから、国家間の協議であっさり認めるとは考え難いからだ。 とはいえ諜報の世界では非合法のことも行われている。例えば米国が法律上の権限を超えて広く通信傍受していたことや、中国が民主化運動家のアカウントを嗅ぎ回っていることは広く知られている。従って事業者として絶対に傍受されていないと断言すべきではなく、データセンターの場所や暗号化方式などの事実を説明し、それ以上のことは断言を避けた方が広報上のリスク
OpenSSL #ccsinjection Vulnerability
[English] 最終更新日: Mon, 16 Jun 2014 18:21:23 +0900 CCS Injection Vulnerability 概要 OpenSSLのChangeCipherSpecメッセージの処理に欠陥が発見されました。 この脆弱性を悪用された場合、暗号通信の情報が漏えいする可能性があります。 サーバとクライアントの両方に影響があり、迅速な対応が求められます。 攻撃方法には充分な再現性があり、標的型攻撃等に利用される可能性は非常に高いと考えます。 対策 各ベンダから更新がリリースされると思われるので、それをインストールすることで対策できます。 （随時更新） Ubuntu Debian FreeBSD CentOS Red Hat 5 Red Hat 6 Amazon Linux AMI 原因 OpenSSLのChangeCipherSpecメッセージの処理に発見
セキュリティ、環境変数、そして
5/20 頃に 公開した envchain というツールの紹介記事を、会社の技術ブログに書いた。 OS X キーチェーンから環境変数をセットするツールを作りました - クックパッド開発者ブログ 投下時間の関係もあると思うけど、思いの他結構拡散してびっくりした。まあ、それは置いておいて、本題。 おもしろい。が、ps -Eで他プロセスで環境変数が見えることを考えると、そもそも環境変数に認証情報を入れてる時点で… / “OS X キーチェーンから環境変数をセットするツールを作りました - クックパッド開発者ブログ” http://t.co/n1quG3C4Tx — Kazuho Oku (@kazuho) June 4, 2014 ごもっともだと思います。 実際のところ、わたしはなんか「環境変数やめろ bot かよ」と言われるレベルであまり環境変数に機密情報を入れる事を好んでないです。 なのにこ
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
JavaScriptでセキュアなコーディングをするために気をつけること – cybozu developer network
（著者：サイボウズ kintone開発チーム 天野 祐介） kintoneはJavaScriptを使って自由にカスタマイズすることができます。 カスタマイズにより独自のリッチなUIを構築したり、新しい機能を追加したりできるようになりますが、セキュアなコーディングをしないとクロスサイトスクリプティング脆弱性を作り込んでしまう危険性があります。 この記事では、JavaScriptでセキュアなコーディングをするための基本的な点を解説します。 主な原因 脆弱性を作り込む主な原因になるコードは、要素の動的な生成です。特に、レコード情報などのユーザーが入力した値を使って要素を生成するときに脆弱性が発生しやすくなります。 対策 document.write()やelement.innerHTMLを使って要素を生成するときは、コンテンツとなる文字列をかならずHTMLエスケープするようにしましょう。 以下は
事務局ブログ：「Covert Redirect」についての John Bradley 氏の解説（追記あり）
追記 (5/7 20:30): 本文中に「まともなブラウザーであれば、そのフラグメントを URI の一部にするようなことはないから、オープン・リダイレクターには送られない。」とありますが、少なくとも Chrome と Firefox はリダイレクト時に URI フラグメントをそのまま保つ (i.e. 不十分な redirect_uri チェック & オープン・リダイレクター & インプリシット・フローの場合、アクセス・トークン入りの URI フラグメントを、ブラウザーがそのままリダイレクト先へのリクエストに用いる) とのことです。続報があり次第追記します。 追記2 (5/7 23:50): John Bradley 氏自身によるフォローアップを訳しました。 Covert Redirect and its real impact on OAuth and OpenID Connect を、と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GoogleがWebでのSHA-1の利用停止を急ぐ理由 | POSTD
Sass を今すぐ実務で使おうよ！ « LINE Engineers' Blog
cybozu developer network
