SSL/TLSの基礎と最新動向Grafana LokiではじめるKubernetesロギングハンズオン（NTT Tech Conference #4 ハンズオン資料）NTT DATA Technology & Innovation
OpenSSLの脆弱性(CVE-2014-3511)でTLSプロトコルの基礎を学ぶ - ぼちぼち日記
1. はじめに、 昨日 OpenSSLのバージョンアップがアナウンスされ、９つの脆弱性が公開されました。バージョンアップの数日前にOpenSSLの次期リリース予告がアナウンスされていましたが、ちょうど BlackHat 開催初日にあたることもあり、なんかまた重大な脆弱性の修正が入るんじゃないかとドキドキしていました。蓋を開けてみるとHeatBleed程の大事ではなくホットひと安心です。 昨日公開されたOpenSSLの９つの脆弱性のうち、TLS プロトコルダウングレード攻撃 (CVE-2014-3511)の修正を見ていたところ、これはTLSプロトコルを学ぶいい題材になるなぁとふと思いつき、試しにこのOpensslの脆弱性の詳細をTLSプロトコルの基礎に合わせて書いてみました。 ちょっと長いですが、TLSプロトコルの仕組み（の一部）を知りたい方はお読みください。 2. OpenSSLの脆弱性
自社サーバと交信するスマホアプリにおけるサーバ証明書の発行手法について（SSL Pinningと独自CA再考）
■背景 自社のサーバと通信する自社アプリについて、本来不要であるにも関わらず他社であるCAに認証情報の管理を委託することが多いわけですが、CAが証明書を誤発行した結果情報漏洩が発生したとして、その責任は自社にはないと主張できるのか、もう一度考えなおしたほうがいいんじゃないかと思うんです — Kazuho Oku (@kazuho) July 15, 2014 .@ockeghem @smbd @ando_Tw スマホアプリの提供においてはコードの署名鍵を安全に管理することが求められますが、その前提において通信相手の認証管理をCAに委託することにどれほどの意味があるんでしょう — Kazuho Oku (@kazuho) July 14, 2014 ■他社CAは信頼できるのか 特定のCAにpinningするのはしないより安全だけど、そもそも誤発行しないCAなんてあるのかという議論は重要。見知
OpenSSLにはこんなに問題が! LibreSSL開発者が発表 - BSDCan2014
The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system. OpenBSDプロジェクトの開発者でありLibreSSLの開発に携わっているBob Beck氏は5月17日(カナダ時間)、「BSDCan2014: LibreSSL」においてLibreSSLの開発がはじまってからのおおよそ30日間のできごとを伝えた。なぜOpenSSLからLibreSSLを派生させ別プロジェクトとして取り組むことにしたのか、具体的にどういった変更を実施したのかなどが説明された。プロジェクトを立ち上げるきっかけはHeartbleed脆弱性が決め手だったのではなく、そのあとに取り組んだ作業によって別プロジェクトにするという判断が決定的なものになったと説明があった。懸念された点は特に次のとおり。
SSL/TLSライブラリの正しい使い方（もしくは、コモンネームの検証について）
スマホアプリの市場拡大に伴い、直接SSL/TLSライブラリを使用するプログラムを書く機会も増えてきている今日この頃かと思います。 SSL/TLSライブラリを使う際には、接続確立時にサーバの認証を正しく行う必要があります。具体的には、クライアントプログラムで以下の２種類の検証を行うことになります。 SSL/TLSライブラリがサーバの証明書の検証に成功したこと サーバの証明書に含まれるコモンネーム注1が接続しようとしたサーバと同一であること 前者については、OpenSSLの場合はSSL_CTX_set_verifyの引数にSSL_VERIFY_PEERを指定するなどして、ライブラリ側で処理を行わせることが可能です（証明書の検証に失敗した場合はSSL_connectがエラーを返します）。 一方、後者についてはSSL/TLSライブラリによって差があり、検証機能を有効にするために特別な呼出が必要だっ
Lavabit 事件とその余波、そして Forward Secrecy - セキュリティは楽しいかね？ Part 2
Lavabit事件 Lavabitという名前をみなさんご存知だろうか。NSAの監視活動について内部リークを行った Edward Snowden氏が利用していたメールサービスとして今年の夏に一躍有名になったところだ。Snowden氏は香港に滞在して複数のジャーナリストにNSAの内部情報を提供したあと、現在はロシアに一時亡命しているが、亡命が認められる前にモスクワ空港にしばらく滞在していたことがある。7月12日に空港内でプレスカンファレンスを行ったのだが、その時複数の人権団体に送った招待状が “edsnowden@lavabit.com” というメールアドレスからだった。この事が報道されると、「あの」Snowden氏が使っているメールサービスということで、利用希望者が殺到したらしい。(それまで新規登録は 200人/日だったのが、4,000人/日と20倍になった。) しかしそんな表の騒動の影で、
SSL is not about encryption
これはTroy Hunt氏によるSSL is not about encryptionの和訳である。@ten_forward氏による翻訳もあるが訳がわかりづらいので、ほとんど参考にせずに翻訳し直した。 SSL is not about encryption. は The basic purpose of SSL is not encryption. のように訳す。同様な文例に Copyright is not about copying. がある。@ten_forward氏による「SSLは暗号化のためのものではありません」は誤訳である。ここでは「主目的ではない」と訳す。 SSLの主目的は暗号化ではない SSLの主目的は保証することである。サイトが本物であることにある程度の信頼性を与えることで、データの送受信を行う際にデータが横取りされることも改ざんされることもなく意図した相手に届くと確信で
スマートフォンアプリケーションでSSLを使わないのは脆弱性か
このエントリでは、スマートフォンアプリケーションの通信暗号化の必要性について議論します。 はじめに 先日、スマートフォンアプリケーションのセキュリティに関するセミナーを聴講しました（2月8日追記。講演者からの依頼によりセミナーのサイトへのリンクをもうけました）。この際に、スマートフォンアプリケーションの脅威に対する共通認識がまだないという課題を改めて感じました。その課題を痛感できたという点で、セミナーは私にとっては有益でした。 このため、当ブログではスマートフォンアプリケーションの話題をあまり取り上げていませんでしたが、今後は、とりあげようと思います。まずは、スマートフォンアプリケーションでは暗号化を必須とするべきかという話題です。この話題は、前記セミナーでもとりあげられていました。 暗号化の目的は何か まず、暗号化の必要性を論じるためには、暗号化の目的を明確にする必要があります。前記セミ
SSL認証局問題が再び発覚、MicrosoftとMozillaが対応表明
米MicrosoftとFirefoxブラウザ開発元のMozillaは11月3日、マレーシアのSSL認証局が発行した証明書に問題があることが分かったとして、この認証局が発行する証明書を失効させると表明した。 両社によると、問題が発覚したのは米Entrust傘下の認証局DigiCert Sdn. Bhdが発行した証明書。暗号強度が不十分な512ビットのRSA鍵を使用した証明書を22件発行していたほか、同社の発行した証明書には複数の技術的問題があることも判明したという。 問題の証明書はマレーシア政府機関のWebサイト用に発行されたもので、現時点で不正に利用された痕跡はないとされる。しかし、攻撃者がこの証明書の問題を悪用すれば、ユーザーをだまして不正なWebサイトを正規サイトだと思わせることが可能になる。 Microsoft、MozillaともEntrustからの連絡を受けて、DigiCert S
【レポート】「SSLだから安心」は間違い - セキュリティセミナー 大塚氏 | エンタープライズ | マイコミジャーナル
6月に開催された「2011 Webセキュリティセミナー」(マイコミジャーナル主催)で、日本ベリサイン SSL製品本部 ダイレクトマーケティング部 マネージャーの大塚雅弘氏は、「今、Webサイトを守るために必要な対策とは ～ソーシャルメディアや最新事例から読み解く今後のセキュリティ対策～」と題する講演を行った。大塚氏は、現在のWebを取り巻くセキュリティ事情を概観しつつ、ユーザーが安心してサイトを利用できるように、EV SSL証明書などを使って"セキュリティの見える化"をすることが重要だと主張した。 インターネットは悪用しやすいメディア 日本ベリサイン SSL製品本部 ダイレクトマーケティング部 マネージャーの大塚雅弘氏 大塚氏はまず、GmailやFacebook、Twitterといったインターネットの新しい潮流について触れながら、「インターネットはオープンで便利なメディアで利用者も多いが、
みずほダイレクトの謎 - ockeghem's blog
ソフトバンク携帯電話のSSL方式変更に伴い、みずほ銀行のモバイルバンキングが一部使えなくなっていましたが、昨日復旧したようです。 7月3日時点では、みずほダイレクトのトップに以下のように表示されていました。URLは魚拓のものです。 現在、ソフトバンクの携帯電話からアクセスいただいた、みずほダイレクト（モバイルバンキング）の［ネット決済振込サービス］および［Pay-easy（ペイジー）税金・料金払込みサービス］において、一部のお取引がご利用いただけません。「ご利用の端末のユーザーIDを「ON」に設定し、再度アクセスしてください。」と表示された場合には、パソコンなどでご利用ください。 お客さまには大変ご迷惑をおかけしておりますことをお詫び申しあげます。 （原因につきましては現在調査中です。） http://megalodon.jp/2011-0703-0032-51/www.mizuhoban
yebo blog: SSL証明書で不適合な名前を使っている問題
2011/04/07 SSL証明書で不適合な名前を使っている問題 コモド事件でSSLの信頼が揺らいでいるが、threatpostによれば、EFFがウェブで使われるSSL証明書を集めたSSLオブザーバトリー・データベースを調査したところ、合法な証明書の3万7千以上に、コモンネームが'localhost'、'mail' のような一般名が使われているという問題が見付かったそうだ[slashdot]。コモンネームはURL(FQDNあるいはIPアドレス)を入れる必要があるが、このような一般名だとMITM攻撃の危険が大きくなる。Unqualified Name PatternValid Certificates Observed“localhost”2,201“exchange”806“exchange” with characters on either side, e.g. “exchange01
高木浩光＠自宅の日記 - 「VeriSignシール」という幻想
■ 「VeriSignシール」という幻想 オレオレ証明書ではないSSLサーバ証明書は、2つの独立した機能を果たしていると言える。1つ目は、SSLプロトコルによるサーバとクライアント間の暗号化通信のために不可欠な役割であり、2つ目は当該サイト運営者の実在証明の機能である。ただし、今日では、後者を含まない、前者だけのサーバ証明書もある。 後者の実在証明は、かつては認証局サービスを提供する各事業者がそれぞれの独自の基準で、サイト運営者の実在性を確認、認証していたが、それでは利用者にわかりにくいことから、認証の際の実在性確認の方法が標準化され、誕生したのがEV SSLであった。 その結果、VeriSignなど、古くから実在証明に力を入れていた認証局サービスでは、EVのものとEVでない実在証明付きサーバ証明書の2種類が存在することとなった。VeriSignでは、EV証明書の提供開始後も、EVでない実
高木浩光＠自宅の日記 - 共用SSLサーバの危険性が理解されていない
■ 共用SSLサーバの危険性が理解されていない さくらインターネットの公式FAQに次の記述があるのに気づいた。 [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか？, さくらインターネット よくある質問（FAQ）, 2010年2月10日更新（初出日不明） Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。 （略） 上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管
WebメールのHTTP通信の危険性 | Security.GS Magazine
本日から開始されたドコモwebメールを触ってみたが、パスワードを送信する一瞬だけSSL通信を使うものの、ログイン画面や、ログイン後のウェブメールの画面では一切SSL通信が使われておらず、公衆ネットワークやプロキシ接続環境で閲覧した場合は、メール本文が流出する可能性があることに気付いた。 ドコモwebメールで注意が必要なのは、設定によっては普段ドコモの携帯電話で送受信しているiモードメールも、ドコモwebメールで閲覧できるため、携帯での送受信メールが流出するのと同義だということ。 また、ドコモwebメールのベースとなっているgooメールやYahoo!メール、Hotmailなどもログイン以外はSSL通信を行っていない。Gmailでは常時SSL通信を行う設定を確認できた。 ちなみに、盗聴やプロキシ接続などで通信を傍受された場合、下記のような事象でメールを読みやすく取得できる。 【認証時はSSL通
このURLは存在しません。
■ なぜ一流企業はhttpsでの閲覧をさせないようにするのか 「かんたんログイン」などという似非認証方式は、たとえIPアドレス制限を実装したとしても安全でない。仕様が公開されていないからという点の他に、技術的な理由として、少なくとも次の2つがある。 「IPアドレス帯域」と俗称される重要情報が安全に配布されていない。 SSLを必要とするケータイサイトでは、通信経路上の攻撃によってなりすましログインされてしまう。*1 2番目には解決策がない。 1番目については解決策はあるだろうが、携帯電話事業者がサボタージュしていて、実現される見通しがない。これについては、2008年7月27日の日記にも書いたが、その後どうなったかを調べてみたところ、ソフトバンクモバイル以外は、何ら改善されておらず、当時のままだった。 NTTドコモ 「iモードセンタのIPアドレス帯域」のページをhttps:// でアクセスする
CERT/CC Vulnerability Note VU#261869
Clientless SSL VPN products break web browser domain-based security models Vulnerability Note VU#261869 Original Release Date: 2009-11-30 | Last Revised: 2013-06-20 Clientless SSL VPN products from multiple vendors operate in a way that breaks fundamental browser security mechanisms. An attacker could use these devices to bypass authentication or conduct other web-based attacks. Web browsers enfor
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さくらインターネット、年額1500円で利用できるドメイン認証SSL「ラピッドSSL」 
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
Google、SSL暗号化対応の検索ページを発表
