Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々
tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらい Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で
Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる | おそらくはそれさえも平凡な日々
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
日本の銀行のSSL/TLS対応状況 2018年6月
これがまぁ驚いたことに6月8日の時点ではTLSv1.0を無効化しているところは1行も無い。それどころかいまだにSSL3.0を有効化しているのが2行、何をお考えなのかTLSv1.0だけを有効化しているのが1行というありさま。とりあえずこの3行のオンラインバンキングは滅べ。 TLSv1.1は本当は無効化が望ましいけどTLSv1.0を有効化している時点でもうどっちでも良い。でも、少なくともTLSv1.2は有効化しとけと言いたいのが百十四銀行。 採用している暗号スイートは銀行・オンラインバンキングを請け負ってる業者によってまちまちだけど、「普通」な設定(暗号強度の高いものを含み強度の高いものの優先順位を高くする)というのが意外と少なくて、弱い暗号スイートしか無いとか、強い暗号スイートが含まれるけど優先順位が弱い順なのでまず使われないというのが殆ど。これは銀行の変な横並び意識なのか金融庁の意味不明な
モバイルアプリ開発者のための mitmproxy 入門 - Qiita
はじめに モバイルアプリを開発しているときに、アプリとサーバー間の通信を確認したいときがあります。たとえば、期待通りの HTTP リクエストが送られているか調べたり、サーバーからのレスポンスが間違っていないか確認したりする必要が生じます。 そんなときに、いちいちデバッガで止めても良いのですが、プロキシをはさめば簡単に通信を覗くことができます。しかも、レスポンスを改竄して、わざと不正なレスポンスにしてアプリがクラッシュしないかテストしたり、特定のリクエストだけブロックしてサーバー障害を擬似的に再現することができます。 mitmproxy とは mitmproxy は man-in-the-middle 型のプロキシサーバーのツールです。OS X や Windows、Linux 上で動作し、対話式の CUI を持ちます。SSL サポートをしている点が特長になります。 公式サイト: http:/
Android エミュレータ上で動いているアプリの HTTP / HTTPS 通信の中身を見る方法 - horolog
今回は Android エミュレータでアプリを動かして、アプリが行う HTTP / HTTPS 通信の中身を覗いてみます。 環境&ツール Windows 10 Android Studio のエミュレータ (v3.2.1) mitmproxy (v4.0) 準備 ツールのインストール Android Studio と mitmproxy をインストールしてください。 仮想デバイスの作成 私は以下の構成で仮想デバイスを作成しました。 ハードウェア Pixel 2 システムイメージ API Level : 28 ABI : x86 Target : Android9.0 (Google APIs) ※ Android9.0 (Google Play) と書かれたイメージだと adb root が使えないで、 Android9.0 (Google APIs) と書かれたイメージを選択してください
Mozilla、Symantecが発行した証明書の信頼性回復に関する議論に参戦 | スラド IT
Google ChromeでSymantecが発行したSSL証明書の有効期限短縮やEVステータス無効化を提案する [security.srad.jp] など、大手認証局の問題点を指摘していること自体は、Google 自身もルート認証局 [mynavi.jp] なことから中立性に疑問はあるものの、指摘の内容は今のところは評価できます。 しかし、その一方で、ここ最近（数か月～1年前ぐらい?）のアップデートで、Google Chrome (Windows 版) から、ユーザーが認証局名（証明書）を確認するための UI が削除されてしまいました。 どの認証局を信頼するかの決定権は、ブラウザベンダーではなく、ユーザーにあるべきです。にも関わらず、わざわざアップデートでユーザーが認証局名を簡単に確認できなくした Google の対応には大きな問題があると思います。ブラウザベンダーであり、自身もルート認
OCN利用者はメールソフトのSSL設定をオンにしてください パスワードが漏洩します
Hiromitsu Takagi @HiromitsuTakagi 解説 メール受信には90年代からAPOPプロトコルが使われてきた。これは、パスワードを生で送信せずチャレンジレスポンス方式でMD5ハッシュして送信するもので、ネットワークが盗聴されても大丈夫なものとされてきた。そのため、メール送受信にSSLを使わないのが普通という時代が続いた。 Hiromitsu Takagi @HiromitsuTakagi 公衆Wi-Fiの普及で盗聴リスクが高まり、メール送受信にもSSLをとの機運が高まり、メールソフト側の対応も済んでいたのに、日本のISPはなかなかSSL化を進めなかった。彼らの言い分は、メールはどのみち暗号化されずに流れるし、パスワードはAPOPで保護されているというものだった。 Hiromitsu Takagi @HiromitsuTakagi その後、電通大の研究グループによりA
自堕落な技術者の日記 : Certificate TransparencyでわかったというThawteによるgoogle.com証明書の不正発行？？？ - livedoor Blog（ブログ）
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 2015年9月19日(土)に「Symantec caught issuing rogue Google.com certificates」 という記事が飛び込んできて、認証局、証明書、SSL関係のインシデントだと わくわくして飛びつくわけですが、ざっと読んでみると 大手セキュリティベンダーのSymantecの子会社で低価な証明書の発行サービスをやっている Thawteが、2015年9月14日にgoogle.com、www.google.com用のEV SSL証明書を、Googleに了解なく 不正に発行していたことが、証明書の公開監査記録(Certificate Transparency)によりわかった。 という事のようです。厳格な審査で発行さ
Symantecの証明書発行に不手際、Googleが対応を要求
米Symantecの認証局が手違いにより、「google.com」などのドメイン向けのテスト証明書をドメイン所有者が知らないうちに発行していたことが分かり、米Googleは10月28日、同社に対して対応を要求した。Symantecの対応次第では、Google製品でSymantecの証明書が安全とみなされなくなる可能性もあると警告している。 Symantecが10月2日に発表したインシデント報告書で、GoogleやOperaなど5組織向けのテスト証明書23件がドメイン所有者の知らないうちに発行されていたと報告した。これに対してGoogleは、不審な証明書はそれ以外にも存在すると指摘。その後、Symantecは10月12日に出した更新版の報告書で、さらに76ドメイン向けの証明書164件と、未登録ドメイン向けの証明書2458件が見つかったと発表した。 GoogleはこうしたSymantecの対応
【悲報】Superfish複数の重大な脆弱性のあるSSL接続も提供してたことが判明 - Windows 2000 Blog
Lenovo製PCに入っている極悪アドウェア「Superfish」はどれだけヤバイのか？ - GIGAZINE VisualDiscovery | SimilarProducts - Monetize Visually Superfish - Visual Search and Image Recognition | ABOUT US 巷では Superfishが話題になってるようなのですが、皆さんおなかいっぱいだと思うので、別の視点から切り込んでみました。 取り敢えず調査のため、SuperfishをPCにインストールしてみようと思ったんだけど、 Windows 8専用だった。 しかたないのでWin8の仮想環境 証明書、ほんとに自己証明だった(笑) ドライバ入ってるんだけど、こっちの証明書どうなってるんだよ！ っておもったら、こっちは Thawte Code Signing をSymant
【悲報】Google、シマンテック発行のSSL証明書を問答無用でブロックへ : IT速報
Googleは、シマンテック発行のSSL証明証に対し、厳しい処罰を検討しているという。 シマンテックまたはその証明書の再販業者がSSL証明書を不適切に発行したという重大な事件について、Googleは厳しい処罰を検討しています。 提案された計画は、会社にすべての顧客の証明書を置き換え、それを持っているユーザーの拡張された検証（EV）ステータスの認識を停止することです。 シマンテックは、2015年のNetcraft調査によると、ウェブ上で使用される3つのSSL証明書のそれぞれについて約1つを担当し、世界最大の商用証明書の発行者となっています。数年にわたり買収した結果、VeriSign、GeoTrust、Thawte、RapidSSLなどの以前のスタンドアロン認証局のルート証明書を管理しています。 SSL / TLS証明書は、ブラウザとHTTPS対応のWebサイトとの間の接続を暗号化し、ユーザー
中国最大級の認証局「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,
無償SSLサーバー証明書Let’s Encryptの普及とHTTP/2および常時SSL化 | OSDN Magazine
Webサイトの暗号化（SSL化、HTTPS対応）はこれまでEコマースやプライバシを守る目的で部分的に導入されてきたが、SHA1からSHA2への切り替え、モバイル端末の普及やHTTP/2の登場によって、サイト全体を常にHTTPS通信にする常時SSL化の動きが活発になっている。さらにSSLサーバー証明書を無償で入手可能なLet’s Encryptのサービス開始や主要なWebサーバーソフトウェアの安定版でHTTP/2が利用できるようになったことでその動きは加速している。本稿ではSSL化を取り巻く最近の状況を整理し、NginxとLet’s EncryptによるHTTP/2＆SSL化の実装例も紹介していく。 これまで証明書の無償入手は限定的 HTTPSのWebサイトを運用するには通常、商用の認証局にSSLサーバー証明書の発行を申し込み、必ず費用が発生するものだった。一部限定した目的では無償で利用でき
エンジニアなら知っておきたい、絵で見てわかるセキュア通信の基本 - Qiita
TLS 1.3は現在策定中ですが、 前方秘匿性 の問題から RSAのみ を用いた鍵委共有が禁止になる見込みです。(詳細は後述します) HTTPSとは 次に、HTTPSです。 HTTPS - Wikipedia HTTPS（Hypertext Transfer Protocol Secure）は、HTTPによる通信を安全に（セキュアに）行うためのプロトコルおよびURIスキームである。 厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供される セキュアな接続の上でHTTP通信を行うこと をHTTPSと呼んでいる。 とのことです。 HTTPの説明を割愛するとすれば、「SSL/TLSでセキュアにHTTPをやる」というだけの説明で済んでしまいます。 最近では個人情報等の観点から全てのサイトをHTTPSにするような動きが見られますが、元々HTTPSが使われやすかった
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
Disclaimer 本エントリは、近々IETFで標準化される予定の新しいTLSの暗号方式 ChaCha20-Poly1305 について解説したものです。 本来なら、新しい暗号方式を紹介するいうことは、その暗号の安全性についてもちゃんと解説しないといけないかもしれません。しかし一般的に暗号の安全性評価はとても難しく、専門家でない者が暗号の安全性について軽々しく書くわけにはいかないなとも思いました。いろいろ悩みましたが、結局無用な誤解を避けるため、本エントリーでは ChaCha20-Poly1305 の安全性に関する記載を最小限に留めています。 今回紹介する ChaCha20-Poly1305 は、これまでも様々な暗号研究者の評価を受けている暗号方式ですが、まだNISTの標準や某国の推奨暗号リストに掲載されるといった、いわゆる特定機関のお墨付きをもった暗号方式ではありません。記載内容が中途半
ハッシュ衝突でTLSを破るSLOTH攻撃(CVE-2015-7575)とは何か - ぼちぼち日記
0. 簡単なSLOTH攻撃のまとめ 最初に簡単なまとめを書いておきます。長文になりそうなので、読むのが大変な方はここだけ見ておいてください。 MD5ハッシュは既に安全ではなく、証明書の署名方式での利用は停止されていたが、後方互換のためハンドシェイクデータの署名方式にRSA-MD5が今でも利用できるTLS実装が幾つか存在していた(Firefox NSS, Java等)。 先週、INRIAグループからハッシュ衝突を利用して実際にTLSを破る攻撃(SLOTH)が公開された。それを受け、いくつかの実装でRSA-MD5を完全に利用不能にする修正が行われた(CVE-2015-7575)。 SLOTHでは、SHA1やTLS、IKE、SSHに対する攻撃についても評価を行い、幾つかは全く現実的に不可能なレベルではないことが示された。MD5とSHA-1でTLSハンドシェイクの完全性を担保しているTLS1.0/
Dell製PCで確認されたeDellRoot証明書の関連情報をまとめてみた - piyolog
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
DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か
米DellのノートPCに不審なルート証明書がプリインストールされているのを見付けたというユーザーの報告が、11月22日ごろにかけて相次いだ。Lenovoのコンピュータで発覚した「Superfish」と同様に、偽の証明書発行に利用され、HTTPS通信に割り込む攻撃に悪用される恐れも指摘されている。 問題になっているのは、Dellのマシンにプリインストールされている自己署名ルート証明書の「eDellRoot」。同社の「Inspiron 5000」を購入したというジョエル・ナード氏は、セットアップの過程でこの証明書を発見。不審に思って調べたところ、eDellRootは信頼できるルート証明書とされ、使用期限は2039年、用途は「All」と記載されていたという。 さらに、「あなたはこの証明書に対応した秘密鍵を持っています」という記載を発見し、ナード氏の疑念は一層深まった。 Redditでこの問題を報
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
東京都主税局が民間企業に.LG.JPドメイン名を切り売りする前代未聞の暴挙に——EV SSLの「東京都」も
通信の安全を守るためにエンジニアができること
