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のルート証明書のチェーンの証明書も指定すれば今で
追記: その後の動きについて書きました → 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証明書の有効期限を監視できるようになりました URL外形監視にて、SSL証明書の有効期限を監視するための設定が新たに追加されました。 SSL証明書の有効期限までの日数が、Warning条件, Critical条件それぞれに設定された日数を下回った際にアラートが通知されます。 また、SSL証明書のアラート発報中にステータスコードやレスポンスタイムなどの異常を検知した際は、アラートの状態が変更されたとみなしてアラートは再通知されます。 詳しくはURL外形監視のヘルプをご覧ください。 mackerel.io これらの設定はAPIからも可能です。 mackerel.io 監視
シンジです。AWSに新機能「AWS Certificate Manager」が追加されました。SSL証明書がまさかの無料発行！ただしAWSのELBとCloudfrontに限る制限付きだけど！なので、EC2だけ〜とかでは使えませんのでご注意を。とはいえELBを挟むのもCloudfront使うのもありがちな構成なので、さくっとSSL暗号化通信したいときは無料だし便利ですよね。無料でワイルドカード使えるのはかなり便利。 ソースはこちら New – AWS Certificate Manager – Deploy SSL/TLS-Based Apps on AWS | AWS Official Blog https://aws.amazon.com/jp/blogs/aws/new-aws-certificate-manager-deploy-ssltls-based-apps-on-aws/ や
数年前、Webは全体的に暗号化されていませんでした。HTTPSはWebページの最も重要な部分だけのために確保されていました。暗号化が必要なのは大切なユーザデータだけで、Webページの公開される部分は暗号化せずに送ってもいいということで意見が一致していました。 しかし、 今は 状況 が 違います 。現在では、どんなWebトラフィックでも暗号化されていないのは良くないということが分かっているので、Webサイトを運営する誰もがコンテンツに関係なく強固なHTTPSを設定しなければなりません。 お恥ずかしい話ですが、私自身のWebサイトは2年近くも全くHTTPSをサポートしていませんでした ^(1) 。 Eric Mill の 今すぐ無料でHTTPSに切り替えよう という素晴らしい記事が最終的に私に喝を入れてくれました。私は休暇中、HTTPSをセットアップして Qualys SSL Report で
Googleのセキュリティチームは米国時間10月14日、Secure Sockets Layer（SSL） 3.0に深刻なセキュリティ脆弱性があることを明らかにした。SSL 3.0はかなり前に導入された暗号化プロトコルでありながら、依然として多く使用されている。 同チームのBodo Möller氏によると、「この脆弱性により、セキュアな接続のプレーンテキストがネットワーク攻撃者によって割り出される恐れがある」という。 SSL 3.0はTLS 1.0、TLS 1.1、TLS 1.2に引き継がれてきたが、TLS実装の多くがレガシーシステムに対応し、ユーザーエクスペリエンスを円滑化するために、SSL 3.0との下位互換性を維持している。 通常、このセキュリティプロトコルのハンドシェークは、認証されたバージョンのネゴシエーションを行う。このようにして、クライアントとサーバの両方に共通する最新のプロ
表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。 今回のChromeのSHA1対応ポリシの問題点 今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。 最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思
こんにちは。CTOの馬場です。 昨晩1/28 21:00JSTにRHEL5/CentOS5にインストールされているルート証明書のうち、GlobalSignの有効期限が切れました。 伴ってREHL5/CentOS5からのHTTPS(SSL)接続にてGlobalSignの証明書を使っているサイトへの接続がエラーになるようになりました。 私の確認している範囲では、 curlコマンドやPHPのcurlライブラリなどでの接続時に接続エラーとなることに起因して以下のような影響が出ています。 ※接続される側ではなくて、接続する側での問題です※ oauthなどの外部認証が不可 決済などの外部連携が不可 対策 RHEL5の場合、errataが公開されているのでupdateしましょう。 Red Hat Customer Portal https://rhn.redhat.com/errata/RHEA-201
NSA（米国家安全保障局）やGCHQ（英国政府通信本部）は、「HTTPS」や「SSL」などを含むインターネット上の暗号化通信を解読可能であると、2013年9月5日に英ガーディアン紙や米ニューヨークタイムズ紙などが報じた。エドワード・スノーデン氏がガーディアンに提供した秘密文書から判明したとする。商用ソフトウエアにバックドアを設けるなどして、解読しているという。 NSAやGCHQは、スーパーコンピュータを用いたブルートフォース型の暗号解読を行ったり、商用ソフトに設けたバックドアを使ったりすることで、暗号化通信を解読しているという。NSAのこれらプロジェクトは「Bullrun」と呼び、HTTPSやVoIP、SSLなど、インターネット上で広く使われている技術を対象としている。 NSAは10年前からこれら暗号解読技術の開発を進めており、2010年に大量の通信を解読可能になったという。NSAは同技術
CA(Certificate Authority / 認証局)であるDigiNotarがクラックされて偽のSSL証明書を発行していた問題で、偽のSSL証明書はGoogleだけではなく、現時点で531にのぼることがわかったようです。 Computerworld: Hackers steal SSL certificates for CIA, MI6, Mossad Computer Worldの記事によると、現在わかっている偽造された531のSSL証明書に、 CIA、MI6、モサド、Microsoft、Yahoo、Skype、Facebook、Twitter、MicrosoftのWindows Updateサービスなどが含まれているとあります。 現時点では、主要WebブラウザがDigiNotar社のSSL証明書を信頼しなくなっています。 関連 イランからGoogleへのSSL通信が傍受されて
多くのユーザがSSL通信(https)の中身を傍受されていた可能性があるようです。 今回、この問題が報告されたのはイラン国内からのGoogleへの通信を行った場合です。 約2ヶ月間にわたってイラン国内からのSSL通信で、検索結果、Gmailに含まれるメールの中身、その他情報が傍受されていたかも知れません。 EFF: Iranian Man-in-the-Middle Attack Against Google Demonstrates Dangerous Weakness of Certificate Authorities Google Online Security Blog: An update on attempted man-in-the-middle attacks 傍受の手法 本来、暗号化されたSSL通信の傍受は困難です。 今回利用された方法はMan-In-The-Middl
SSL認証局Comodoに対するハッキング攻撃を仕掛けたとする人物が名乗り出て、犯行の手口などを明らかにしたという。 SSL認証局のComodoから大手サイト用の不正なSSL証明書が発行されていた問題で、この攻撃を仕掛けたとする人物が名乗り出て、犯行の手口などを明らかにしたと、セキュリティ企業の英Sophosがブログで伝えた。 Sophosによると、問題の人物は当初SSLのルート認証システムをハッキングする目的でRSAアルゴリズムを破ろうとしたが、この過程でComodoのパートナーである「GlobalTrust.it」「InstantSSL.it」のハッキングに成功したと称している。 さらに、InstantSSL.itが証明書署名リクエスト（CSR）提出用のサイトに使っているDLLを見つけ、このDLLを解析する過程で、テキスト形式のユーザー名とパスワードがCSR提出プロセスの一部に使われて
SSL認証局のComodoから偽のSSL証明書が発行され、Microsoft、Google、Yahoo!など大手各社のWebサイトが影響を受ける恐れがある。攻撃を防ぐためにWindowsやFirefoxのアップデートが公開された。 SSL認証局のComodo Groupが偽のSSL証明書を発行し、Microsoft、Google、Yahoo!など大手各社のWebサイトが影響を受ける恐れがあることが分かった。MicrosoftやMozillaはアップデートを配信し、攻撃を防止する措置を取っている。 Microsoftによると、Comodoは偽のSSL証明書を9件発行したという。影響を受けるのは、Hotmailのログインに使われている「login.live.com」のほか、Googleの「mail.google.com」「www.google.com」、Yahoo!の「login.yahoo.
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
Apacheのバージョン2.2.12以降では、SNI（Server Name Indication）という、SSLプロトコルに対する拡張機能がサポートされているため、名前ベースのHTTPサイトを設定する場合と同じように名前ベースのHTTPSサイトを設定することが可能になっている。本記事では、Apacheのこの機能について紹介する。 Apache Webサーバがバージョンアップし、成熟していくに伴い、新機能の追加やバグの修正が行われてきている。そして、バージョン2.2.12で追加された機能のうち、最も重要なものはおそらく、単一IPアドレス上で複数のSSLサイトを運用できるようにするという、長らく持ち望まれていた機能だろう。 これまでは、特定のIPアドレスに対してSSL対応のWebサイトを割り当てた場合、そのサイト1つしかSSL対応のWebサイトを運用することができなかった。つまり、IPアドレ
2009/07/31 SSLの実装に問題 Black Hat 開催で新たな問題が公表された。DNSの脆弱性発見で名を馳せたDan Kaminsky氏とMoxie Marlinspike氏は、ブラウザにはSSLなどX.509を利用する公開鍵システムの実装上の問題があることを発見したそうだ。ヌル文字で終わる証明書を利用することで、Webサイトを偽装することができるという (自身の名前、Moxie Marlinspike 攻撃と呼んでいる)。攻撃者(badguy.com)はベリサインなどから自身の証明書を得る。攻撃者はPaypal.com\0.badguy.com のような自身のサブドメインの証明書を合法的に得ることができる。そうすると、多くのブラウザはヌル文字 "\0" で名前の読み込みを止めてしまうため、この場合Paypal.comと認識されてしまい、Webサイトが偽装されることとなる。攻撃
セキュリティ企業の米Symantecは7月8日のブログで、詐欺サイトが正規のSSL証明書を使い、正規サイトを装う手口が見つかったと伝えた。ユーザーはSSLがあるために安心して個人情報などを入力してしまうという。 Symantecによると、SSL証明書を悪用した詐欺サイトは過去1カ月の間に急増した。攻撃側は、SSL証明書を取得したWebサーバを1つ乗っ取れば、そのサーバを使って多数のフィッシング詐欺サイトを運営することが可能になり、情報詐取の成功率も高まる。SSLが使われ鍵のアイコンが表示されるために、ユーザーは正規サイトだと思い込んでしまうという。 この手口を使って実際に、大手サイトを装うフィッシング詐欺が発生している。詐欺サイトかどうかを見分けるためにはSSL証明書をチェックするか、認証機能を強化したEV（Extended Validation） SSLをあてにするしかないという。 旧バ
■ EV SSLを緑色だというだけで信用してはいけない実例 EV SSLに関して以前から懸念されていたことが既に現実になっていた。一時期、EV証明書を発行する一部のCA事業者が、EV SSLの宣伝で「緑色になったら安全」などといいかげんな広告を打っていて、誤った理解が広まりかねないと心配されていたわけだが、「緑色になったら安全」という理解がなぜ駄目なのか、その理由の一つは、いわゆる「共用SSL」サービスにEV SSLが使われかねないという懸念だった。 そして、その実例が既に存在していたことに気付いた。図1は私が作ったWebページである。 アドレスバーは緑色になっているが、ここに入力されたデータは私宛にメールで送信*1されてくる。（このページは既に閉鎖している。） 悪意ある者がこうしたページを作成*2し、何らかの方法でこのページに人々を誘導*3すれば、フィッシングの被害が出るおそれがある。
先日、携帯端末向けにSSL証明書を発行するサービス『SSLモバイル』をリリースしました。 「SSLモバイル」は、ジオトラスト社が発行する、国内の携帯電話に対応したSSL証明書です。ドコモ、au、ソフトバンク社の携帯端末以外にも、ウィルコムやイーモバイル、iPhone、Google Androidなどのスマートフォン端末にも対応しています。 お求めやすい価格で、技術サポートや再発行手数料無料など、高品質で安全なシステムの構築にご利用頂けます。 以下、アシアル株式会社が提供する、SSLモバイル証明書の特徴になります。 ・主要３キャリアの携帯端末に対応 ・弊社スタッフによる、日本での購入、技術サポート ・ほぼすべてのPCブラウザにも対応 ・ジオトラスト社により発行される、信頼性の高いシングル・ルート証明書を使用 ・7日間の完全返金保証やSSL証明書の再発行など高品質なアフターサポート 【料金】
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く