「Google Chrome」、緑の鍵アイコンと「Secure」ラベルを段階的に廃止へ
Googleは、「Chrome」でURLの隣に表示される緑色の鍵アイコンと「Secure（保護された通信）」ラベルを段階的に廃止する。インターネットでは安全なウェブサイトが標準であるべきだというわけだ。 現在は、Chromeブラウザでページを訪問する場合に、すべてのHTTPS対応サイトにこうしたアイコンとラベルが表示される。これで、暗号化され、サイバー攻撃から守られている安全なページを訪問中だとわかる。Googleの目標は、インターネット上のページをすべてHTTPS化することで、今のところ、この目標にかなり近づいている。 米国時間5月12日の時点で、Windowsを使用してChromeでブラウジングするユーザーの訪問サイトのうち、83％がHTTPSページだった。Chromeでは、保護されていないページよりHTTPSページを訪問する可能性のほうがはるかに高い段階に達している。 そうした考え方
Android P で TLS のデフォルト化によるユーザー保護
.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
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
SSL/TLS暗号設定ガイドライン 第2.0版の公開 | CRYPTREC
トピックス SSL/TLS暗号設定ガイドライン 第2.0版の公開 平成30年5月8日 国立研究開発法人 情報通信研究機構 独立行政法人 情報処理推進機構 国立研究開発法人情報通信研究機構 (略称NICT) と独立行政法人情報処理推進機構 (略称IPA) が共同で運営する「暗号技術活用委員会」の2017年度の活動成果として、SSL/TLS暗号設定ガイドライン 第2.0版を改訂しましたので、公開いたします。 「SSL/TLS暗号設定ガイドライン」第2.0版 本報告書に対するお問い合わせは、下記までお願いいたします。 問い合わせ等の受付はe-mailのみといたします。 CRYPTREC事務局 E-mail :
「SSL/TLS暗号設定ガイドライン 第2.0版」を読んで - ぼちぼち日記
1. はじめに 昨日「SSL/TLS暗号設定ガイドライン 第2.0版」が公開されました。 前回から約3年経って今回はCRYPTREC暗号技術活用委員会で検討作業が行われたようです。 普段、TLS/HTTPSの記事を書いたり発表したりしている立場上、これを見逃すわけにはいけません。 本文冒頭では、 「本ガイドラインは、2018 年 3 月時点における、SSL/TLS 通信での安全性と可用性（相互接続性）のバランスを踏まえた SSL/TLS サーバの設定方法を示すものである。」 ということなので、できたてほっかほっかの最新ガイドラインを読ませていただきました。 読み進めてみるとChangelogが細かく書いてなく、以前のバージョンとどこがどう変わったのかよくわかりません。TLS1.3とかは絶対に新しく入った内容なんですが、細かいところはどうだろう… それでも全部(SSL-VPNを除く)をざっと
自堕落な技術者の日記 : 最近の証明書の話題(1) 韓国政府PKIのマズいワイルドカード証明書発行 - livedoor Blog（ブログ）
どうも、証明書ハンターです。最近、個人的におもしろい証明書の話題がポンポン出てきたので、何回かに分けてご紹介したいと思います。 山賀さんのFacebookのフィードを見ていたら、 韓国政府PKIでまずい証明書を発行したというニュース(Google翻訳で読んでくださいw)を教えていただきまして、ハンターとしてはゲットしてコレクションに加えておきたいところ。 その問題というのは、韓国政府PKIが慶尚南道教育庁に不適切なワイルドカードSSLサーバー証明書を発行してしまったというもの。 慶尚南道は韓国の南東、釜山のすぐ北にあるのだそうです。 韓国のサイトは日本と同じでセカンドレベルを組織種別とする属性型ドメイン名を採用していて、政府系ドメインは「go.kr」のようになっていますが、以下のドメインに対してワイルドカードSSLサーバー証明書を発行してしまいました。 *.hs.kr - 高校 *.ms.
「HTTPSで暗号化されているから安全！」とまだ信じているあなたへ
かつてこの世は、闇によって支配されていました。人々は常に、IDやパスワードを掠め取る悪の化身「フィッシング」の恐怖におびえながら暮らしていたのです。そんな世界にさっそうと現れたのが、額に鍵マークを宿した正義の戦士「エッチ・テーテーピー・エス（HTTPS）」でした。敢然と悪と戦うエッチ・テーテーピー・エスは、徐々に闇を駆逐して世界に光を取り戻し、やがてこの世は再び平和を取り戻したとさ。めでたしめでたし。 しかしエッチテーテーピーエスって、名前が長ったらしいね。何とか短く略せないのかね、「ハットゥプゥスッ！」みたいな感じに……逆に読みにくいか。 ともあれ、かつてはこんな“夢物語”が現実に信じられていた時代もありました。この世のサイトが全て常時SSL化されれば、フィッシングをはじめ、さまざまなセキュリティ問題が解決するのではないかと。 そしてそれは、やはり夢と終わりました。そう、夢は覚めてしまっ
小悪魔女子大生のサーバエンジニア日記 » Blog Archive » Baseline Requirementとは？
09.05.12 / 未分類 / Author: aico 2011年に偽造証明書が発行されるという事件がありました。 発行されてしまったのはComodo社とDigiNotar社の偽造証明書。 Comodo社のケースではGmailやskypeなどの偽造証明書が、 DigiNotar社のケースではなんと531件の偽造証明書が発行されてしまい、 DigiNotar社は事業継続が困難になり倒産に追い込まれてしまいました。 どうしてそのような事件が起きてしまったのでしょう？ まずComodo社のケースから見てみましょう。 認証局(CA)は、 申請者の情報を確認し発行する前の審査を行う登録局(RA)と 審査の結果を受けて証明書発行のみ行う発行局(IA)に分かれます。 1つの認証局が両方を行う場合もありますが、 Comodo社では事件の起きた2011年時点では登録局の業務を外部に委託しており、 Com
Firefoxが政府認証基盤のルート証明書を認めず、「ユーザーのセキュリティを害する」
Webブラウザー「Firefox」を開発する米モジラ（Mozilla）は2018年2月末までに、日本の政府認証基盤（GPKI）が提出していたルート証明書のプレインストールの申請を認めない決定を下した。
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
SSL/TLSについてまとめ2018 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに SSL/TLSについて改めて理解を深めたい思い、関連する技術についてまとめました。 本記事はTLSに関すること主題として、HTTPS、暗号化、Apache、OpenSSL等について記載しています。 SSL/TLSの通信は色々なプロトコルや暗号化方式が組み合わされ補いあってできています。暗号化の仕組みはパズルのようで面白いです。一つ一つを読み取り理解が深まるごとで、SSL/TLSって本当によくできると思いました。フレームワークの意味について考えさられます。 HTTPSの通信 HTTPSの通信はTCP/IPプロトコルスイートとして
第４９４号コラム「常時ＳＳＬ／ＴＬＳ通信のもたらすもの」 | デジタル・フォレンジック研究会
第４９４号コラム：上原 哲太郎 副会長 （立命館大学 情報理工学部 セキュリティ・ネットワークコース 教授） 題：「常時ＳＳＬ／ＴＬＳ通信のもたらすもの」 インターネットはかつて、通信に関しては原則として暗号化はオプションであって必須としないという方向で標準化されてきました。電子メールもWebも、基本となるプロトコルは全て暗号化も利用者認証もない状態で標準化されており、パスワード送信など限られた重要な場面でのみ通信路を暗号化するという方向で運用されてきました。ところが、インターネットにおける標準を事実上決めているIETFでは、このところ通信の全てを暗号化しようとする議論が盛んです。その流れを作ったのは２０１３年のPRISM騒動でした。Edward Snowden氏が米国NSAの広範な諜報活動を告発したことにより、国家権力による通信監視が現実の脅威であるという危機感がIETFを覆ったのです。
中央省庁の8割が非対応、常時SSL化の実態を独自調査
常時SSL化は2010年代に入って必要性が認識され始めた。サーバーを直接攻撃せず、通信途中に第三者が割り込んで通信内容を変更する「中間者攻撃」が発達したからだ。 公衆無線LANの普及が中間者攻撃の危険性をさらに高め、サイト内容の書き換え、利用者が送る情報の改ざんやなりすまし、閲覧履歴の盗み見などの被害に遭いやすくなった。マルウエア（悪意のあるソフトウエア）が仕込まれたWebサイトに誘導されるリスクも潜む。 常時SSL化に対応したサイトはわずか2割 日経コンピュータと日本経済新聞が2017年9月下旬から10月下旬まで調べたところ、中央省庁37機関のうち常時SSL化を終えているのは内閣官房や国家公安委員会、国税庁など9機関。残る28機関は問い合わせや電子申請の画面など対応は一部にとどまる。独立行政法人など政府系106機関のうちでも常時SSL化が完了しているのは2割強だった。 中央省庁で常時SS
authrootseq.txt authrootstl.cab
インターネットってのは原理的には盗聴し放題だったり いつどこから誰がアクセスしてくるかも分からなかったりするので 盗聴とかユーザー認証とかするのに暗号技術ってのは基本リテラシーです 新版暗号技術入門とか分かりやすい で、Windows の場合 CryptoAPI っていう API を持っていて (Linux だと OpenSSL がスタンダードですかね) 暗号・PKI 関係を処理してくれています capi とか capi2 とかいうみたいです http://msdn.microsoft.com/en-us/library/aa380255(VS.85).aspx こっから辿れば色々分かるのかな テクノロジーは日々進歩して 結果 XP と Vista では CryptoAPI も大きく変わっているそうで (2008 -> 2008 R2 でも随分と変わっているらしいけど) 例えば XP も
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
OpenSSLをSSL/TLSクライアントとして使ってみる
$ openssl s_client -connect servername:443 で SSL 接続 HTTP の接続を確認したくて telnet を使うことがある。 たとえば、 telnet で http://www.google.com:80/ に GET するには以下のコマンドを実行する。 $ telnet www.google.com 80 Trying 173.194.117.145... Connected to www.google.com. Escape character is '^]'. GET / HTTP/1.1 host: www.google.com HTTP/1.1 302 Found Cache-Control: private Content-Type: text/html; charset=UTF-8 Location: http://www.goog
サイトの「HTTPS化」が世界的に進んで大きなターニングポイントを迎える
By Sean MacEntee 通信の内容を暗号化することでセキュアなインターネット通信を実現するHTTPSへの対応が全世界的に進められています。セキュリティ関連の専門家であるトロイ・ハント氏はこの状況について、変化の動きが急激に大きくなるティッピングポイントに達したと指摘しています。 Troy Hunt: HTTPS adoption has reached the tipping point https://www.troyhunt.com/https-adoption-has-reached-the-tipping-point/ ハント氏はまず、2016年10月にネットのトラフィックをモニタリングしているMozilla Telemetryにおいて、HTTPS経由で送信されたページリクエストが全体の50%を超えたことを挙げて潮目の変化を示しています。 Yesterday, for t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoft Trusted Root Certificate Program: Audit Requirements for Certificate Authorities | Microsoft Docs
そのSSL/TLS証明書は大丈夫？ Google Chromeからhttpsサイトとして信頼してもらえなくなる場合も!? Symantecのサーバー証明書の件について、DigiCert日本法人に聞いたFAQ的まとめ
中央省庁サイト、8割に改ざん・盗み見リスク - 日本経済新聞
