■ GlobalSign 失効騒ぎ _ 先週 GlobalSign がやらかした障害について 詳細な報告書が出てた。一読してだいたい理解できたけど、字ばっかで図がないのでやっぱりわかりづらい。わかりやすくしてみる。 _ 障害発生前の状態。 +----------+ +--------+ +----------+ | Root(R1) |-----| 中間CA |------| EE証明書 | +----------+ +--------+ +----------+ | +----------+ +---------+ | Root(R2) |-----|crossroot| +----------+ +---------+ EE(エンドエンティティ)証明書ってのはサーバ証明書とかクライアント証明書とかコード署名証明書とか、要するに一般ユーザが買う証明書のこと。通常は EE - 中間 CA
弊社のような認証局(CA)にとりまして失効に関する「通常業務」の一環として、ルート証明書(R2)から署名された証明書失効リスト(CRL)を10月7日に発行しました。そのリストにはシリアルナンバー「040000000001444ef0464e」のクロスルート証明書及び、シリアルナンバー「0400000000011256ad5fb2」の中間CA証明書を記載していました。シリアルナンバー「0400000000011256ad5fb2」の中間証明書は、寿命(EOL)を迎えた中間CAに対して発行されており、そのCAは以前SHA-1 EV SSLを発行していました。上記クロスルート証明書、中間CA証明書ともに、秘密鍵に関連するリスクもなく、通常の手順以外でCRLを発行する必要がなかったため、リーズンコードは双方で「運用停止」としていました。新しいCRLは弊社のCDNのフロントエンドを通して、そのまま利
今回の障害に関する詳細につきましては、『10月13日に発生した証明書エラーについてのご報告(続報)』をご覧ください。 平素は弊社サービスをご利用くださいまして、誠にありがとうございます。 弊社の中間CA証明書が誤って一部OSおよびブラウザにより一時的に除外されておりました。 現在復旧をしておりますが、環境によってはキャッシュの影響によりエラーが表示される場合がございます。 ご利用のお客様には多大なるご迷惑をお掛けいたしまして、誠に申し訳ございません。 ■対象 ・クイック認証SSL ・企業認証SSL ・Alpha SSL ・クラウドSSL ■発生時刻 2016年10月13日(木)18:00 16:00頃 ~ 2016年10月13日(木)20:30頃 ※障害発生時刻に誤りがありました。謹んでお詫び申し上げます。 ■影響範囲 中間CA証明書失効エラー ■背景 グローバルサインでは複数のルート証明
■ サブドメイン管理者が親ドメインの SSL 証明書を取得する _ 中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明。サブドメインの管理権限がある人が親ドメインの SSL 証明書が取得できちゃったんだって。この問題、他の CA でもあるんだよね、実は。 _ 具体的に言うと Let's Encrypt がそれ。 この記述。example.com ドメインの所有者かどうか判断する方法のひとつとして、_acme-challenge.example.com の TXT レコードに指定のトークンを記述せよ、というのが挙げられている。ということで、ユーザが自由にサブドメインを作れるサービス上で _acme-challenge というサブドメインを作成すれば親ドメインの証明書を発行してもらえる。今回の WoSign の件のように任意のサブドメインでいけるわけではなく、ラベルにアン
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 昨今「インターネット分離」という言葉をよく耳にします。 インターネット分離とは、業務で使う社内端末や基幹系システムをインターネットと分離することであり、総務省が推奨していることもあってこのコンセプトが注目されています。 仮想デスクトップ(VDI)導入 業務端末をインターネットから分離する場合でも、メールのやり取り、ウェブブラウザでの情報検索、ウェブベースの業務アプリケーションなどインターネットを使わないと仕事にならない業務が多いのが現状です。そこで仮想デスクトップ(VDI)環境を導入し、インターネットを使う業務は業務端末からV
攻撃を受ければ暗号を解除され、通信の内容を傍受される恐れがある。影響を受けるWebサイトには、日本の大手も含まれる。 インターネットの通信暗号化に使われるSSL/TLSプロトコルを使って通信を暗号化しているHTTPSサイトなどに深刻な脆弱性が発見された。研究チームはこの脆弱性を「DROWN」と命名し、3月1日に詳しい情報を公開。全HTTPSサイトの33%が影響を受けるとして、管理者に対応を急ぐよう呼び掛けている。 研究チームが専用サイトを通じて公開した情報によると、DROWN攻撃の脆弱性は、多くのサーバがTLSに移行しながら、設定ミスが原因で依然としてTLSの前身であるSSLv2もサポートしていることに起因する。 これまでは、SSLv2をサポートしているだけではセキュリティ問題が生じるとは考えられていなかったが、調査の結果、簡単に攻撃できてしまうことが判明し、サーバやクライアントが危険にさ
SSL/TLSによって通信を暗号化しているHTTPSサイトに簡単に攻撃される脆弱性があることがセキュリティ研究者によって発表されました。この脆弱性をついた攻撃「DROWN」を受ける可能性があるサイトには、毎日新聞、任天堂、はてな、LINEなどの日本の大手サイトも含まれています。 DROWN: Breaking TLS using SSLv2.pdf (PDFファイル)https://drownattack.com/drown-attack-paper.pdf DROWN Attack https://drownattack.com/ 「Decrypting RSA with Obsolete and Weakened eNcryption(DROWN)」はSSLv2に含まれる脆弱性で、この脆弱性を悪用されるとクロスプロトコル攻撃によってTLSセッションの暗号化が解除(復号)されて通信が傍受
2016年3月1日(現地時間)、OpenSSL プロジェクトは脆弱性の愛称「DROWN」や「CacheBleed」を含む8件の脆弱性情報を公開し、これら影響を受けるものの修正を行った最新版をリリースしました。ここでは関連情報をまとめます。 脆弱性情報概要 注意喚起 OpenSSL の複数の脆弱性に関する注意喚起 - JPCERT/CC SSLv2 DROWN Attack - US-CERT OpenSSL Projectの公開情報 Forthcoming OpenSSL releases OpenSSL Security Advisory [1st March 2016] OpenSSL version 1.0.1s published OpenSSL version 1.0.2g published An OpenSSL User’s Guide to DROWN 2016年3月1日公
+1 ボタン 2 AMP 11 API 3 App Indexing 8 CAPTCHA 1 Chrome 2 First Click Free 1 Google アシスタント 1 Google ニュース 1 Google プレイス 2 Javascript 1 Lighthouse 4 Merchant Center 8 NoHacked 4 PageSpeed Insights 1 reCAPTCHA v3 1 Search Console 101 speed 1 イベント 25 ウェブマスターガイドライン 57 ウェブマスタークイズ 2 ウェブマスターツール 83 ウェブマスターフォーラム 10 オートコンプリート 1 お知らせ 69 クロールとインデックス 75 サイトクリニック 4 サイトマップ 15 しごと検索 1 スマートフォン 11 セーフブラウジング 5 セキュリティ 1
さくらVPSで、Let’s Encryptのサーバ証明書を使って、SSL対応のサイトを作る設定手順 注意 以下はあくまで結城の個人的なメモです。 前提 さくらVPSを使ってWebサイトを運用している。 独自ドメインを持っている。 VirtualHostを使っている。 目標 いままで http://www.example.com で運用していたサービスを https://www.example.com で運用したい。 無料で使えるLet’s Encryptを試す。 方法 作業はすべてSSHで接続したさくらVPS上で行っています。 注意: 以下の内容は古いです。インストールについては Apache on CentOS/RHEL 7 を参照してください。 $ cd $ sudo /etc/rc.d/init.d/httpd stop $ sudo yum update $ git clone h
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Dell製PCで確認された勝手ルート証明書問題(Superfish2.0とも呼称されている)の関連情報をまとめます。 Dellの公式見解・サポート情報 更新:弊社PC証明書脆弱性について(eDellRoot証明書ならびにDSDTestProvider証明書) 弊社PC証明書脆弱性について(eDellRoot証明書) Dell System Detect Security Update Response to Concerns Regarding eDellroot Certificate Information on the eDellRoot certificate and how to remove it from your Dell PC Information on the eDellRoot and DSDTestProvider certificates and how to
やっと、ついに、誰もが無料でHTTPSを使えるようになる!…MozillaやEFFが共同プロジェクトを立ち上げ - TechCrunchだが、ブコメ欄で「フィッシングサイトが見分けられなくなる」と勘違いしている向きがあるようなので、ちょっと書いておく。 このLet's Encryptだが、Let’s Encrypt: Delivering SSL/TLS Everywhereに説明が書かれている。そもそも上のTechCrunchの記事ではLet's Encryptがどういうものか分からない。この記事では何ができて何ができないかを書いていないし。 TechCrunchの記事はオレが見た時点(2014/11/20 5:00)ですごいブクマ数(792ユーザ)なんだけど、本体の説明のブクマ数は4ユーザ、オレがブックマークしたので5ユーザである。ちょっと調べてからコメントすればいいのに。 下記のほう
1. はじめに ちょうど今朝 OpenSSLをはじめとした様々なTLS実装の脆弱性の詳細が公表されました。 この InriaとMSRのグループは以前からTLSのセキュリティに関して非常にアクティブに調査・検証をしているグループで、今回も驚きの内容でした。 このグループは、TLSのハンドシェイク時の状態遷移を厳密にチェックするツールを開発し、様々なTLS実装の脆弱性を発見・報告を行っていたようです。 特にFREAKと呼ばれるOpenSSLの脆弱性(CVE-2015-0204)に関しては、ちょうど修正直後の1月初めに Only allow ephemeral RSA keys in export ciphersuites で見ていましたが、具体的にどのように攻撃するのかさっぱりイメージできず、あのグループだからまた超絶変態な手法だろうが、まぁそれほど深刻じゃないだろうと見込んでいました。 今回
輸出グレードのRSA暗号をサポートしていたことに起因する脆弱性FREAKに関する情報について関連情報をまとめます。 脆弱性概要 脆弱性の概要情報は次の通り。 愛称 FREAK (Factoring attack on RSA-EXPORT Keysの略) 輸出グレード暗号の強制使用に関する呼称 アイコン 無し CVE OpenSSL:CVE-2015-0204 Apple:CVE-2015-1067 Microsoft:CVE-2015-1637 発見者名 miTLS Inria(フランス国立情報学自動制御研究所)とMicrosoft Researchの合同チーム FREAK Attackの概要 中間者攻撃が行われるまでのFREAK Attackの流れは次の通り。(3月6日更新) MITMの攻撃成立条件 以下の条件が成立する場合、通信内容の盗聴や改ざんの影響を受ける可能性がある。 接続元・
Steven J. Vaughan-Nichols (Special to ZDNET.com) 翻訳校正: 編集部 2015-03-04 16:45 1990年代の初めには名案のように感じられたのかもしれない。Secure-Socket Layer(SSL)という暗号化技術が産声を上げた当時、米国家安全保障局(NSA)は外国でやり取りされる「セキュア」なウェブトラフィックの内容を確実に傍受したいと考えていた。このためNSAは「Netscape Navigator」のインターナショナル版には40ビット暗号を使用し、より安全な128ビット暗号は米国版でのみ使用するようNetscapeを説き伏せた。その後、2000年1月に暗号輸出管理規則が改正され、どのようなブラウザでもよりセキュアなSSLを使用できるようになった。しかし、旧来のセキュアでないコードは、15年が経過した今でも使用されており、わ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く