Google、ルート証明書発行の独自インフラを構築
ルート認証局はGlobalSign R2とR4を取得した。これまでは、ルート証明書を製品に組み込んで、そうした製品に関連したバージョンが広範に導入されるのを待つ時間がかかっていたが、ルート認証局を取得したことで証明書をタイミング良く発行できるようになると見込んでいる。 下位認証局GIAG2の運営は今後も続ける方針で、ルート認証局の取得やTrust Servicesを通じて新しい独立したインフラへの移行を目指す。 今後はGoogle製品に接続する製品を開発する場合、Google Trust Servicesが運営するルート証明書が必要になる。ただしGoogleは独自のルート認証局を運営しながら、サードパーティーが運営するルートの下で下位認証局を運営する場合もあるとしている。 証明書を巡っては、認証局による不正な証明書の発行が発覚して主要ブラウザが対応を迫られたり、米Symantecの認証局が
カスペルスキー、自社ウイルス対策ソフトの脆弱性に対処--Project Zeroの指摘受け
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます セキュリティ企業のKaspersky Labは米国時間12月28日、同社のウイルス対策ソフトに存在する脆弱性を修正した。Googleのセキュリティチーム「Project Zero」によって発見されていたこの脆弱性は、同製品に含まれているSSLプロキシ機能がMD5ハッシュの先頭32ビットのみを用いて管理していたために、容易にSSL証明書の衝突を引き起こせるというものだ。 Project ZeroのTavis Ormandy氏は、「キー長が32ビットの場合、ブルートフォース攻撃によって数秒で衝突を引き起こすのを防ぐには不十分であるということは、暗号研究者でなくても分かるはずだ」と同プロジェクトのIssueトラッカーに記している。 Orman
Comodo、OCRの誤認識により一部ドメインで正規所有者以外がSSL証明書を取得できる状態だった | スラド セキュリティ
世界最大の認証局ComodoでSSL証明書発行手続きに不備があり、一部のドメインで正規の所有者以外がSSL証明書を取得できる状態にあったそうだ(Incident Report — OCR、 Softpediaの記事、 The Registerの記事、 heise Securityの記事)。 ComodoではSSL証明書のリクエストがあるとWHOISデータベースからドメイン所有者の電子メールアドレスを取得し、確認の電子メールを返信する。一連の処理は自動化されているのだが、一部のTLD(.euおよび.be)に関しては電子メールアドレスがテキストで保存されておらず、画像に書き込まれた状態になっているのだという。 そのため、ComodoではOCRソフトウェアを使用してテキストを抽出し、ドメイン所有者に連絡を行っていたそうだ。しかし、このOCRソフトウェアでは数字の「1」と小文字の「l」、数字の「0
モジラ、中国の認証局WoSignが新たに発行するデジタル証明書のブロックを提案
Mozillaは、WoSignが新たに発行するデジタル証明書をブロックする意向だ。WoSignは、GitHubの偽のHTTPS証明書を発行した中国の認証局（CA）である。 Mozillaはイスラエルに拠点を置く認証局StartComをブロックすることも提案している。WoSignは2015年11月にStartComを買収したが、何らかの理由で、同CAの所有権を取得したことを否定した。 Mozillaは、両認証局が新たに発行する証明書を1年間ブロックすることを提案している。その後、WoSignとStartComはMozillaの信頼プログラムへの参加を再申請しなければならない。WoSignは中国で新たに発行する証明書に関して、今後も信頼性を保証してほしいとMozillaに要請したが、Mozillaはこれを却下した。 ウェブユーザーへの影響を最小限に抑えるため、Mozillaは既存の証明書につい
中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明
by Barney Moss 無料でSSL証明書を発行してくれることで、多くの自宅サーバーユーザーに重宝されている中国最大級の認証局「沃通(WoSign)」が、「偽物の証明書」を大量に発行していたことが明らかになりました。 The story of how WoSign gave me an SSL certificate for GitHub.com | Schrauger.com https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com Thoughts and Observations: Chinese CA WoSign faces revocation after possibly issuing fake certificates of Github,
【セキュリティ ニュース】複数ブラウザでHTTPS通信時にパラメータなど含むURLが漏洩するおそれ（1ページ目 / 全1ページ）：Security NEXT
「WPAD」に対応した複数のブラウザにおいて、HTTPS通信時のURLが第三者へ取得されるおそれがある脆弱性が含まれていることがわかった。URLのパラメータなどに含まれる機密情報が、漏洩するおそれがある。 「WPADプロトコル」によってプロキシを設定するために用いるファイル「proxy.pac」を自動的に取得するブラウザを使用した場合、URLを取得される脆弱性が判明したもの。AppleやGoogle、Mozilla、Operaなどのブラウザが影響を受けることが判明している。 具体的には、攻撃者が用意した「proxy.pac」を読み込んだ場合、マンインザミドル攻撃（MITM攻撃）により、HTTPS通信を行う際のパス情報や、GETリクエストにおけるパラメータなどを取得されるおそれがあるという。 Appleでは、「CVE-2016-1801」として「OS X El Capitan v10.11.
New attack bypasses HTTPS protection on Macs, Windows, and Linux
New attack bypasses HTTPS protection on Macs, Windows, and Linux Hack can be carried out by operators of Wi-Fi hotspots, where HTTPs is needed most. A key guarantee provided by HTTPS encryption is that the addresses of visited websites aren't visible to attackers who may be monitoring an end user's network traffic. Now, researchers have devised an attack that breaks this protection. The attack can
Feature: Squid-in-the-middle SSL Bump
🔗 Feature: Squid-in-the-middle SSL Bump Goal: Enable ICAP inspection of SSL traffic. Version: 3.1 to 3.4. Developer: AlexRousskov, Christos Tsantilas More: See also dynamic SSL certificate generation and origin server certificate mimicking features. 🔗 Details This feature was replaced in Squid-3.5 by peek-n-splice This feature was replaced in Squid-3.3 by server-first Squid-in-the-middle decrypt
ついにやってきた「常時HTTPS」の波、デメリットを再検証
筆者は、今まで何度かにわたってWebサイトやユーザーを守るために「常時SSL」「常時HTTPS」を導入すべきだと提起してきた。 日本の金融機関はなぜ「常時SSL」を実装しないのか？（2013年10月11日） 銀行に期待した「常時SSL」 その後……（2015年2月20日） 「HTTP」前提が崩れる――早く「常時SSL」にすべき理由（2015年5月22日） 「常時SSL」の疑問に答えよう、どうすればできるか（2015年5月29日） そして今年に入り、さまざまな状況が変化してきた。例えば、Yahoo! JAPANは4月から2017年3月にかけて、全てのYahooサービスを常時SSLに対応させると表明している。 また、筆者の本職であるITセキュリティのコンサルタント業務の中で、複数の金融機関と一般企業が予算を確保して「常時SSL対応プロジェクト」を立ち上げたり、その準備に取り組み始めている。一部
Android アプリで意図しないクリアテキスト トラフィックへの逆行を防ぐ
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
Leaving Beta, New Sponsors - Let's Encrypt
Let’s Encrypt is leaving beta today. We’re also excited to announce that founding sponsors Cisco and Akamai have renewed their Platinum sponsorships with 3-year commitments, Gemalto is joining as our newest Gold sponsor, and HP Enterprise, Fastly, Duda and ReliableSite.net are our newest Silver sponsors. Since our beta began in September 2015 we’ve issued more than 1.7 million certificates for mor
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
Disclaimer 本エントリは、近々IETFで標準化される予定の新しいTLSの暗号方式 ChaCha20-Poly1305 について解説したものです。 本来なら、新しい暗号方式を紹介するいうことは、その暗号の安全性についてもちゃんと解説しないといけないかもしれません。しかし一般的に暗号の安全性評価はとても難しく、専門家でない者が暗号の安全性について軽々しく書くわけにはいかないなとも思いました。いろいろ悩みましたが、結局無用な誤解を避けるため、本エントリーでは ChaCha20-Poly1305 の安全性に関する記載を最小限に留めています。 今回紹介する ChaCha20-Poly1305 は、これまでも様々な暗号研究者の評価を受けている暗号方式ですが、まだNISTの標準や某国の推奨暗号リストに掲載されるといった、いわゆる特定機関のお墨付きをもった暗号方式ではありません。記載内容が中途半
GoogleがTLSでの採用を提唱している共通鍵暗号方式「ChaCha」についてまとめた - sonickun.log
ChaCha（チャチャ）という一見ふざけた名前の暗号が最近（自分の中で）話題ということで，勉強がてらに記事にしてみました． 背景 ChaChaの構造 Salsa20 Chacha 初期状態 ラウンド操作 ChaChaの安全性 実装してみた 参考 背景 2016年4月現在，TLSの新しいバージョンとしてTLS 1.3が提案されており，ドラフトが公開されている． draft-ietf-tls-tls13-11 - The Transport Layer Security (TLS) Protocol Version 1.3 TLS 1.2からの大きな変更点として，以下の2つがある． ハンドシェイクの省略によるRTT（Round Trip Time）の削減 危殆化した暗号の廃止 「危殆化した暗号」とは，Forward SecrecyでないCipher Suite（RSAのみを用いたもの）や，認証
グーグル、信頼できない認証局のリストを作成
Liam Tung （Special to ZDNET.com） 翻訳校正： 石橋啓一郎 2016-03-25 17:06 Googleは、信頼できない公開鍵証明書認証局を確認できるようにする仕組みを強化した。 この仕組みは、同社が提案した電子証明書追跡システムで、「Certificate Transparency」（CT、証明書の透明性）と呼ばれている。2015年にSymantecが一部のGoogleドメインに対して発行したような、不正に発行されたSSL証明書からChromeユーザーを守ることができる。 この事件はGoogleから強い反発を呼び、同社はSymantecに対して、2016年6月1日までに、発行するすべての証明書についてGoogleのChromium CTポリシーに準拠する形でCTにログを残すことを要求し、これに応じなければ、同社が発行する証明書を利用するウェブサイトを、Ch
クロスプロトコル攻撃が可能となるSSLv2の脆弱性「DROWN」 | 財経新聞
headless 曰く、 クロスプロトコル攻撃が可能となるSSLv2の脆弱性「DROWN （Decrypting RSA with Obsolete and Weakened eNcryption）」の詳細が公表された（The DROWN Attack、OpenSSL Blog、Red Hat Security Blog、JVNVU#90617353）。 SSLv2の安全性が低いことは知られているが、多くのサーバーでSSLv2のサポートが有効になっている。TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。 DROWNではサーバーとクライアントがTLSで通信していても、攻撃者はSSLv2接続でパディングオラクル攻撃を仕掛けて暗号を解読できる。サ
IoT機器で利用可能なTLS認証技術、富士通研究所らが開発
富士通研究所は、東京大学や東邦大学と共同で、IoT機器向けのTLS認証技術を開発した。従来に比べて認証時間を5分の1に短縮し、IoT機器でも通信時の情報漏えいや不正操作を防ぐ。 富士通研究所は2016年1月19日、東京大学や東邦大学と共同で、IoT（Internet of Things）機器向けに、暗号通信方式「TLS（Transport Layer Security）」の認証にかかる処理時間を、同等の暗号強度をもつ従来の方式と比べて約5分の1に短縮する認証技術を開発したと発表した。 富士通研究所は認証方式の設計と実装を、東京大学は後述のIEEE 1888通信ソフトウェアへの適用と実験環境構築を、東邦大学はベースとなる暗号処理向けオープンソースライブラリ「TEPLA（University of Tsukuba Elliptic Curve and Pairing Library）」の改良を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
通信の安全を守るためにエンジニアができること
SSLでURLフィルタリングは機能するか？
Google、どこでもHTTPSをBloggerにも拡大、blogspotドメインの全ブログにHTTPSバージョン 
「サンドボックスの先を行く技術でハッカーに対抗する」――、チェック・ポイント新社長
