はてなブックマーク

CA/Browser ForumおよびMozillaルートプログラムでは、全ての認証局（CA）が画一された要件の遵守と監査を義務付けられています。重要なコンプライアンスやセキュリティ要件の設定を通じて、ウェブサイトの閲覧者を保護しています。 SSLサーバ証明書の仕様なども度々アップデートがされ、OUフィールドの廃止要件の決定、またECC鍵使用の場合のKey Usageに関する追加情報の発表がありました。本記事では、直近の４つのSSLサーバ証明書の仕様変更について解説します。 SSLサーバ証明書の仕様変更 1. 【2021年10月1日～】認証局（CA）はドメイン名及びIPアドレスの審査を証明書発行以前の398日以内に実施 2. 【2021年12月1日～】ページ認証によるワイルドカード発行の禁止 3. 【2021年7月26日～】ECC鍵のKey Usageに対する変更 4. 【2022年8月3

2020年2月にApple社が「2020年9月1日以降に発行されるSSLサーバ証明書で、有効期間が398日を超える証明書をSafariでは無効とする」という発表を、グローバルサインブログで紹介しました。本日はその続報を紹介します。 その後、ブラウザベンダーのアナウンス CA/Browser Forumでは、SSLサーバ証明書の有効期間を398日未満とする、基本ルール(Baseline Requirements)を盛り込むよう、投票に向けた議論を重ねている最中ですが、2020年6月23日にオンライン会合の場で、GoogleやMozillaも相次いでAppleのアナウンスに同意するかたちで、9月1日以降に発行されるSSLサーバ証明書で、398日を超える証明書は無効化することをアナウンスしました。 これは、CA/Browser ForumのBaseline Requirementsの要件にかかわ

数年前と比較すると多くのウェブサイトで導入が進んでいる「常時SSL」。それを加速させている背景には、サイト運営者・運営企業のセキュリティ意識が向上していることもあげられますが、ブラウザでの非SSLサイトへの対応も大きな要因となっています。その中でも、日本国内だけでなく世界中でトップシェアを誇るGoogle Chromeの動向は、ブラウザのバージョンアップ内容が発表される度に大きな注目を集めています。 HTTP接続に関連するGoogle Chromeのアップデートを、2017年から2018年の現時点で発表されている情報でまとめてみました。 2017年のGoogle Chrome 「常時SSL」というワードが「行ったほうがよいもの」として認識されることとなった2017年、Google ChromeのHTTP接続に関連する２つの大きなアップデートがありました。 Chrome 56 リリース日 ア

鍵長が長ければ長いほど、暗号文は解読しにくくなり安全になりますが、計算手順は増えるため暗号化・復号に時間がかかるようになります。 また、極端に短い鍵長の鍵を使用することはセキュリティ上好ましくなく、第三者に解読されてしまう恐れもあります。 GMOグローバルサインで用いているRSAは、公開鍵暗号の1つで、セキュリティ上の脆弱性の観点から、現在では基本的に鍵長2048bit以上のRSA鍵を使用するよう推奨されています。 SSL暗号化通信の流れ クライアント側から通信のリクエストがあると、まずサーバ側から「公開鍵」が送付され、それを元にクライアント側で「共通鍵」が生成され、サーバ側にも送られます。 次にクライアント側が生成された共通鍵を使って暗号化した個人情報や決済情報などのデータをサーバ側に送り、サーバ側は事前にクライアント側から送られた共通鍵を使ってデータを復号します。 接続要求 クライアン

多くの人がインターネットにアクセスしない日はないという昨今、インターネットの安全性は当たり前に求められるものとなっています。そのため、大手有名ウェブサービスは常時SSL化が基本となっていますが、単にSSL化と言っても認証レベルには差があり、サイトに合わせたSSLの選定が必要です。特に近年話題になっている無償SSLは、正しく理解したうえで利用することが推奨されています。 SSLの認証レベル インターネット上の通信を暗号化するSSL（Secure Sockets Layer）サーバ証明書は、大きくドメイン認証（DV：Domain Validation）、企業実在認証（OV：Organization Validation）、EV認証（EV：Extended Validation）の3つのタイプに分類されます。その中でもドメイン認証は更に「有償タイプ」と「無償タイプ」に分かれます。 それぞれの証明

証明書の正当性は、本来階層構造を上位にたどることによってルート証明書にたどり着くことで確認ができます。しかし第三者認証局の階層に参加せずとも、勝手にサーバ証明書を作ることができる「オレオレ証明書」と呼ばれる自己署名証明書も、知識があれば自分で作成することが可能です。しかしこうした正当性が証明できない自己署名証明書を使うことは信頼できないサイトという評価になります。 この記事では、なぜ自己署名証明書が危険なのか信頼のできない証明書であるかについて解説します。 「自己署名証明書」は、なぜ信頼できない証明書といわれてしまうのか把握しよう SSL通信において「電子証明書」は、重要な個人情報や決済情報を暗号化して、万が一途中でデータが盗まれた場合でも、内容が書き換えられないようにしてくれる大切な働きを持っています。 この暗号化をするにあたって、電子証明書は第三者認証局に依頼せずに作成した「自己署名証

添付ファイルを開くためのパスワード別送、この方法での運用を義務付けている企業は本当に安全な電子メール環境を実現できているのでしょうか。想像以上に簡単に復元できてしまう「パスワード別送」の落とし穴と、それに替わる安価で安全な方法をご紹介します。 添付ファイルを開くためのパスワード別送に意味はあるのか？ パスワードを別送で通知する運用を義務付けている企業の落とし穴 重要なファイルをメールで送ることが必要になった時、暗号化してパスワードを別のメールで通知するといった運用を行っている企業は少なくありません。企業によっては社員やスタッフなどそこで働く人たちに、このようなルールを義務付けているところもあります。 しかしPCに詳しい人ほど「この運用方法で本当にセキュリティ的に意味があるのか」と疑問を持っている人は少なくありません。事実、ファイルを添付したメールはもちろん、パスワードが記載されたメールを盗

今や多くのWebサーバ管理者が使用しているSSL/TLS。ネット犯罪などの改ざんを防止する方法として便利な反面、脆弱性の問題は次々と発覚し、その都度移行対応は必須の状態です。今、なぜTLS1.2への移行が必要なのか、SHA-2への移行の問題や既にTLS1.2を有効化した大手企業の現状などをご紹介します。 SSL3.0、TLS1.0、TLS1.1の脆弱性とそれに伴う情報漏えいリスク POODLE、Heartbleed、FREAKなど既に発見されている脆弱性の問題を振り返る ネット通販で何かを購入する時はクレジットカードを使う。10年前はそれを「危険」と感じていた人が多かったにも関わらず、今やネット通販の市場は拡大するばかりで購入者は増えるばかり。その人気を支えているのがSSL/TLSの暗号化通信。送信元のIDやパスワード、住所やクレジットカード番号を暗号化し、第三者がそのデータを閲覧出来ない

ちょっと待って！そのWi-Fi使ってほんとうに大丈夫？公衆・社内・自宅ネットワークの安全性をもう一度点検しよう ノートパソコンやスマートフォンが普及するにつれ、公衆エリア・職場・家庭などでケーブルを使わずにインターネットに接続できる環境が当たり前になってきています。そうした環境でメールやWebサイトに接続することに慣れてしまうと、いちいちケーブルを差し込んで使うのが面倒になってきます。こうした利便性から職場や家庭でのWi-Fi利用は今後もますます拡大し、東京オリンピックの開催もあって公衆スポットにWi-Fiを設置するケースも増加することが予想されています。 しかしWi-Fiは便利な半面、知らないうちに自分の個人情報が盗み取られたり、ウイルスに感染したりする被害に遭う恐れもたくさんあります。便利なWi-Fiを安心して使うために、改めて適切な使い方をマスターしておきましょう。 Wi-Fiの危険

サイトの安全性を担保するために電子署名を用いたSSLを現在では、数多くのWebサイトが利用していると言われています。しかし、その暗号アルゴリズムが破られると通信の安全は保障できなくなり、なりすましやフィッシングに悪用されることが予測されます。 かねてからSHA-1証明書からSHA256証明書への移行は2016年12月31日までが期限と言われていましたが、ここに来てその期限を2016年中頃に前倒しする動きも出てきています。SHA256への移行の背景を改めて説明するとともに、各ブラウザベンダーの動きをご紹介します。 SHA-1証明書の問題と当初の移行期間とは SHA-1証明書は電子的な情報の信頼性を担保するために用いられます。本来、電子情報の信頼性を確保するために電子署名、秘密鍵、公開鍵を使った暗号基盤が利用されています。電子情報に対して電子署名をするためには、RSA暗号と言われる秘密鍵を使っ

個人情報を取り扱う企業なら知っておくべきセキュリティ基準が「PCI DSS」です。このセキュリティ基準は定期的に更新されており、2015年4月15日にv3.1が公開され、2016年にはv3.2が公開される予定となっています。ここではこのPCI DSSの基本的な知識から最新のv3.1やv3.2の概要のほか、古いPCI DSSから新しいPCI DSSに移行する必要性やSSLとの関係性についても説明します。 情報化社会が浸透していくにつれて個人情報の安全な取り扱いは企業にとっての至上命題です。ここでその基本について理解しておきましょう。 クレジットカードの国際セキュリティ基準「PCI DSS」 PCI DSSとは一体何なのか？ PCI DSSはPayment Card Industry Data Security Standardsの略称で、加盟店やサービスプロバイダがクレジットカードの個人情報

SSL/TLS証明書無料化は進むか？～Let's Encryptに見る無料SSL/TLS証明書の台頭とその注意点～ オンラインショッピングやネットバンキングが一般的になりつつある今、同時に「なりすまし」や「盗聴」「改ざん」などが世界的に問題になりつつあります。そこで2014年11月にElectronic Frontier Foundation（EFF）の他、MozillaやCisco Systems、ミシガン大学などが協同で「Let's Encrypt」と呼ばれる無料SSLプロジェクトを立ち上げました。ここではSSL/TLSとはそもそもどんな役割を持っているのかというところから、Let's Encryptの登場に見る無料SSL/TLS証明書の台頭とその注意点について解説します。 SSL/TLSの役割は「暗号化」と「認証」 SSL/TLSが担っている役割 SSLはSecure Sockets

Googleは、2014年9月にGoogle ChromeのSHA-1取扱いに関する指針を公開しました。 さらに2015年に入り、バージョン45および46からアドレスバーの表示を変更したり、メッセージを出して閲覧できなくする等、サイトのセキュリティに関する仕様を変更しました。 SSLサーバ証明書で利用されているハッシュアルゴリズムSHA-1について、CAブラウザフォーラムは、有効期限が2017年1月1日以降のSHA-1を使用したSSLサーバ証明書は利用しないという方針を発表しました。最新のGoogle Chromeを使用している場合、2017年1月1日以降の有効期限を持つ、SHA-1ハッシュアルゴリズムを利用したSSLサーバ証明書を設定してるウェブサイトを表示させた場合に、警告マークを表示させるという、より踏み込んだ対応を行いました。 このChromeの措置もあり、弊社では正しくSSLサー

SSL/TLSの拡張仕様の1つであるSNI（Server Name Indication）に注目が集まっています。 これまでは「1台のサーバ（グローバルIPアドレス）につきSSL証明書は1ドメイン」でしたが、SNIを利用すれば、「1台のサーバで異なる証明書」を使い分けることができるようになります。 それでは、SNIの利用方法やその必要性について確認していきましょう。 SNI（Server Name Indication）とは何だろう？ SSL/TLSでは「同じサーバ（同じグローバルIPアドレスを利用する複数のユーザ）は1つのSSLサーバ証明書しか使えない」のが基本です。そのため、このままだと不便な場合もあります。 たとえばレンタルサーバサービスを例として考えると、「同じサーバを複数のユーザが利用し、なおかつユーザごとに異なるドメインを利用する」という場合もあるでしょう（名前ベースバーチャル

Copyright © 2011 Blue Lock by Kilayla Pilon, on Flickr 前回に引き続き、SSLに関連する新しい技術についてご紹介したいと思います。 今回ご紹介するのは 「DNS Certification Authority Authorization (CAA)」です。 DANEとCAAの違い CAAの基本的な考え方は、DNSレコードの中にそのドメインに対して証明書を発行できる認証局の情報を記述し、意図しない認証局からの証明書の誤発行を防ごうというものです。この考え方は前回ご紹介したDANEに非常によく似ています。 では、DANEとCAAの間にはどのような違いがあるのでしょうか。 CAAは今年(2013年)の1月にRFC6844としてRFC化されていますが、この中にDANEとCAAの違いを説明する記述がありますので、ちょっと長くなりますが引用しましょ

2014年10月15日、「お客様への重要なお知らせ」にてご報告した『SSL 3.0に関する脆弱性について (Padding Oracle On Downgraded Legacy Encryption)』では、SSL 3.0プロトコルにのみ影響があるとされていました。しかし、このたび一部のTLS 1.0 / TLS 1.1においても、SSLで保護されたウェブサイトとブラウザの間で、ハッカーの通信傍受や暗号解読が可能であることがわかりました。 TLSパケット内で利用されているパディング構成を適切にチェックしていない実装がされている場合、この脆弱性の影響を受けます。今のところ、F5ネットワークスとA10ネットワークスのロードバランサでTLS接続をハンドルしているウェブサイトで、この脆弱性が発見されています。 より技術的な知見はGoogleセキュリティエンジニアAdam Langleyの投稿『T

GoogleがSHA-1 SSL証明書に関する新たなポリシーを発表 GMOグローバルサインは以前お知らせにて、お客様が利用するSSL証明書に最新のハッシュアルゴリズムを選択いただくことの重要性をお伝えすると共に、業界全体でSHA-1からSHA256へのアルゴリズム移行を進めていることをご紹介しました。 最近Googleが、SHA-1 SSL証明書のインストールされたウェブサイトへアクセスしたユーザに、証明書の有効性が低いと表示する、という新たなポリシーを発表したことにより、アルゴリズムの移行を速やかに行うことがより重要性を増してきました。Googleの動きは、より安全なセキュリティレベルへの移行を促進するポジティブな一歩と言えますが、これはSSL証明書をご利用いただいている皆様にとって何を意味することになるのでしょうか？ 2014年9月5日付　Googleオンラインセキュリティブログ: G

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への証

※こちらの記事は2013年8月14日に投稿されたものを、GMOグローバルサインスタッフが翻訳したものです。 この記事を読んでくれている読者の中には、SSLデジタル証明書の使用方法については詳しい人もいるかもしれませんがSSLの歴史についてはあまり詳しくない人もいるかもしれません。今回はデジタル証明書の使い方の前に、デジタル証明書の核の部分について、あまり踏み込まないところを伝えていきたいと思います。 デジタル証明書とは鍵に資格情報(エンティティの ID に関する情報および識別を裏付ける他の情報)と制約情報を結合したもので、例として、”この証明書に関連した秘密鍵の所有者(エンティティ)はEmailに対して(制約情報)、ライアン・ハーストと署名する権利がある(資格情報)”と言い換えることができます。デジタル証明書の構想段階では、人やリソースといった主体（サブジェクト）と、ディレクトリ内の表示と

Chromeではgoogle.comに発行する正規な認証局をPinningしています。たとえ、信頼されたルート証明機関ストアに含まれた認証局からgoogle.comの証明書が発行されたとしても、Pinning のリストにない場合は警告表示が行われます。ほとんどの人はこの件が起きるまで、この技術がChromeに実装されていることを知りませんでした。 この件がきっかけでPinningの有効性は十分に認知され、Pinningをアプリケーション側に実装することでCA側による危殆化による不正な発行、または誤発行によるトラブルの拡大を防げることは実証されました。今後はPinningのリストを拡大していくことが課題かと思いますが、IETFのドラフトにおいても拡大には問題があると提示されています。 今後の動き Pinningをユーザーエージェント提供側にてハードコード化し、展開していくには慎重な対応が要求

2011年に起こったComodo社/DigiNotar社の認証局からの証明書の不正発行事件を契機として、証明書発行時の審査方法やSSLにおける証明書の有効性の検証方法についての議論が盛んに行われるようになりました。 これらの議論から出てきた技術要素の中から、標準化に向けた議論が進んでいるものや、すでに一部のアプリケーションに実装されているものも出てきています。 今回から数回に分け、これらの技術要素の中から、いくつかピックアップして解説していきたいと思います。 DANEが考案された背景 今回ご紹介するのがDNS-based Authentication of Named Entities（DANE)です。ちなみにこれ、どう発音するのか、ぱっと見わかりづらいのですが、"デーン"と発音するのが正しいようです。 この技術が出てきた背景として、現在のSSLの標準的な実装である「信頼された認証局（トラ