CAA Mandated by CA/Browser Forum | Qualys
Certification Authority Authorization (CAA), specified in RFC 6844 in 2013, is a proposal to improve the strength of the PKI ecosystem with a new control to restrict which CAs can issue certificates for a particular domain name. Although CAA had been in the proposed-standard state for more than 4 years, there was little obvious happening until very recently, with only a hundred or two hundred site
DMM inside
20年越しの大規模リニューアルが進行中。「わくわく時間100%」を目指すDMM通販モダナイズプロジェクトの全貌
SSL証明書をSHA–1からSHA–2に更新する際にはご注意を！ | さくらのナレッジ
現在SSL証明書の署名アルゴリズムがSHA–1からSHA–2へと変更になる過渡期となっています。今後はSSL証明書の新規取得や更新を行う際にはSHA–2の証明書を取得することになると思いますが、いつも通りの慣れた作業と思っていると、思わぬところでハマるかも知れません。 今回は実際に更新作業をした経験を踏まえて取得/更新作業の注意点について簡単にまとめてみました。 そもそもなぜSHA–2に移行する必要があるのか？ 署名アルゴリズムがSHA–1の証明書は非推奨となり、ゆくゆくは廃止となる流れとなっています。基本的にSHA–1の証明書は2017年1月1日以降使えなくなると考えてよいでしょう。そして2016年12月31日までにSHA–2に移行する必要があります。 詳細はここで説明すると長くなりますので、次のようなSSL証明書の発行元のサイトの解説を参照してください。 SHA–1証明書の受付終了とS
HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
自堕落な技術者の日記 : Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS - livedoor Blog（ブログ）
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 先週のInternet Week 2014でHTTPSサーバー設定の話をさせて頂きました。お越し頂いた方、ありがとうございました。マニアックな内容だったのですが、何か参考になる所があれば嬉しいです。 さて、今日はパネルネタで仕込んでおいたのに陽の目を見なかった話をちょっとブログで書こうと思います。SSL/TLS関連で統計データみたいなものを出しているサイトが幾つかあって、そこから世の中の傾向がわかったり、それを元に自分のサーバーはどう設定するかなぁ、などと考えるのに役に立つのではと思い紹介したいと思います。 SSL Pulse まず最初に紹介したいのがSSL Pulseというサイトです。 出典：SSL Pulse https://www.tr
自堕落な技術者の日記 : ChromeのSHA1証明書のアラート表示ポリシの問題点 - livedoor Blog（ブログ）
表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。 今回のChromeのSHA1対応ポリシの問題点 今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。 最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思
How's My SSL?
Your SSL client is Probably Okay. Check out the sections below for information about the SSL/TLS client you used to render this page. Yeah, we really mean "TLS", not "SSL". Version Good Your client is using TLS 1.3, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web. Learn More Ephemeral Key Support Good Ephemeral keys
The POODLE Attack and the End of SSL 3.0 – Mozilla Security Blog
Summary SSL version 3.0 is no longer secure. Browsers and websites need to turn off SSLv3 and use more modern security protocols as soon as possible, in order to avoid compromising users’ private information. We have a plan to turn off SSLv3 in Firefox. This plan was developed with other browser vendors after a team at Google discovered a critical flaw in SSLv3, which can allow an attacker to extr
NASTY SSL 3.0 vuln to be revealed soon – sources (Update: It's POODLE)
Gird your loins, sysadmins: The Register has learned that news of yet another security vulnerability - this time in SSL 3.0 - is probably imminent. (And indeed so it turned out to be - the Poodle vuln. You heard it here first. - Ed) Maintainers have kept quiet about the vulnerability in the lead-up to a patch release, which is expected in in the late European evening, or not far from high noon Pac
Announcing Keyless SSL™: All the Benefits of CloudFlare Without Having to Turn Over Your Private SSL Keys
Announcing Keyless SSL™: All the Benefits of CloudFlare Without Having to Turn Over Your Private SSL Keys2014-09-18 CloudFlare is an engineering-driven company. This is a story we're proud of because it embodies the essence of who we are: when faced with a problem, we found a novel solution. Technical details to follow but, until then, welcome to the no hardware world. (Update: The post with the t
Firefox 32、「Public Key Pinning」を導入へ
Firefox web browser - Faster, more secure & customizable Mozillaは、「Monica at Mozilla: Firefox 32 supports Public Key Pinning」において、Firefox 32からはデフォルトで「Public Key Pinning」機能が有効になると伝えた。「Public Key Pinning」は不正なMan-in-the-Middle攻撃などによって不正なSSL証明書が使われている場合に、それを見抜くことにつながる機能とされており、「Public Key Pinning」に対応したサイトにより安全にアクセスできるようになる。 「Public Key Pinning」に関する説明は「Public Key Pinning Extension for HTTP - draft-ietf-
BlackHat2014USA_Prompt_20140808_J - 暗号プロトコル評価技術コンソーシアム CELLOS
Cryptographic protocol Evaluation toward Long-Lived Outstanding Security Consortium [2014/8/08] Black Hat 2014 USAで発表されたSSL/TLSへの複数の新たな攻撃手法について 2014年8月6日（日本時間8月7日早朝）、Black Hat 2014 USA において Antoine Delignat-Lavaud 氏により SSL/TLS に対する複数の攻撃手法が発表されました [1]。公開された事後資料とデモ [2] では以下の3つのトピックが扱われています。 (1) Cookie Cutter attack : IEEE S&P2014 [3] で発表済み (2) Virtual Host Confusion (3) Triple Handshake : IEEE S&P20
モジラ、グーグルと同様の証明書失効チェック方法を採用へ
Larry Seltzer （Special to ZDNET.com） 翻訳校正： 編集部 2014-08-11 12:05 OpenSSLのソフトウェアバグであるHeartbleedが4月に発覚して以来、証明書の失効確認をめぐる議論が高まってきた。こうした問題ではGoogleの対応が早いことが多いが、MozillaはGoogleの手法に準じて証明書の失効確認方法を改善する計画を公表した。 Heartbleedが厄介視される理由の1つは、セキュリティ対策を施している多数のWebサイトがTSL/SSL証明書の失効と再発行を余儀なくされることだ。これまで公開鍵基盤（PKI）における証明書失効確認には、証明書失効リスト（CRL）とオンライン証明書ステータスプロトコル（OCSP）が使用されてきたが、いずれのシステムも問題を抱え脆弱性の不安を排除しきれなかった。 OCSPはCRLの問題に対処するた
OpenSSLの脆弱性(CVE-2014-3511)でTLSプロトコルの基礎を学ぶ - ぼちぼち日記
1. はじめに、 昨日 OpenSSLのバージョンアップがアナウンスされ、９つの脆弱性が公開されました。バージョンアップの数日前にOpenSSLの次期リリース予告がアナウンスされていましたが、ちょうど BlackHat 開催初日にあたることもあり、なんかまた重大な脆弱性の修正が入るんじゃないかとドキドキしていました。蓋を開けてみるとHeatBleed程の大事ではなくホットひと安心です。 昨日公開されたOpenSSLの９つの脆弱性のうち、TLS プロトコルダウングレード攻撃 (CVE-2014-3511)の修正を見ていたところ、これはTLSプロトコルを学ぶいい題材になるなぁとふと思いつき、試しにこのOpensslの脆弱性の詳細をTLSプロトコルの基礎に合わせて書いてみました。 ちょっと長いですが、TLSプロトコルの仕組み（の一部）を知りたい方はお読みください。 2. OpenSSLの脆弱性
Certificate Transparency
Certificate Transparencyとはなにか 過去に当ブログでDANE, CAA, Certificate Pinningと、SSL/TLSにおける電子証明書の信頼性を高める新たな技術をご紹介してきましたが、今回は同じ目的で考案されたCertificate Transparency(CT)を取り上げたいと思います。 CTはCertificate Pinningと同様Googleによって考案され、2013年にRFC6962としてRFC化されました。 基本的な考え方はCertificate Pinningと同じ「ホワイトリスティング」です。正規に発行された証明書の情報を「Log」として登録し、TLSクライアントがサーバに接続する際にこの「Log」を参照することで証明書の正当性を検証できるようにしようというものです。 CTの特徴として、以下のようなポイントがあります。 Logへの証
「Google Chrome」が「OpenSSL」の使用を中止--「BoringSSL」に切り替え
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 「Google Chrome」の（開発者向け）最新バージョンで、セキュリティプロトコルを実装するソフトウェア「OpenSSL」の使用が中止され、OpenSSLからフォークした独自の「BoringSSL」へと切り替えられた。切り替えに関する詳細な情報は、Chromium Code Reviewsで確認できる。 OpenSSLについては、いわゆる「Heartbleed」脆弱性が4月に発覚し、大きな話題を呼んだ。この脆弱性を突かれると、HTTPSを介して行われたクレジットカード決済の情報などのセキュアなメッセージの中身だけでなく、プライマリおよびセカンダリSSLキー自体も盗み見されてしまう可能性があった。またその後、中間者（MitM）攻撃を可
自社サーバと交信するスマホアプリにおけるサーバ証明書の発行手法について（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なんてあるのかという議論は重要。見知
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SHA-2 Certificates are now available – Gandi News
SSLv3で問題になるフィーチャーフォンの対応 - Qiita
Public Key Pinning Extension for HTTP