HTTPSの証明を無料で発行するLet’s Encryptがベータを終了、年初には同機関自身が悪用を経験

screen-shot-2016-04-12-at-6-00-55-pm

無料のデジタル証明を提供して、より多くのWebサイトが接続を暗号化できるようにしよう、という趣旨のイニシアチブLet’s Encryptが、立ち上げから6か月を過ぎた今日(米国時間4/12)、ベータを終了した。Let’s Encryptの基本的な考え方は、リソースが乏しくて公開鍵の証明を自力でできない小さなサイトに、自動化されたサービスを提供することだ。

支援組織Internet Security Research Group(ISRG)の一員であるMozillaによると、この6か月で同機関は170万あまりの証明を発行し、およそ240万のドメインネームの、HTTPS接続の確保を助けた。最近の例では、WordPressもそんなサイトのひとつだ

暗号化された接続が数百万増えたといっても、しかしそれは、セキュアでないオンラインコンテンツの大海に落ちた水一滴にすぎない。Mozillaによると、2015年12月では、ページビューのわずか40%が暗号化され、オンライントランザクションの65%がセキュアなインターネットプロトコルであるHTTPSを使った。

ISRGに加わった企業や団体は、Mozillaのほかに、Cisco, Akamai, Electronic Frontier Foundation, IdenTrustなどだ。正規会員のほかに、Chrome、Facebookなどスポンサーも多い。

セキュアでないWeb接続にはプライバシーのリスクが当然あるだけでなく、ハッカーたちや、そのほかのタイプののぞき屋からの被害もありえる。Googleは同社のChromeブラウザーでセキュアでない接続を警告して、ユーザーがなるべくHTTPSでないWebサイトにアクセスしないようにしている。また、Webサイトの多くがセキュアな接続に移行するよう、奨励もしている。後者は、Googleの利益にもかなうことだ。

Let’s Encryptはなるべく多くのインターネット接続に鍵をかけるという、有意義な目標を掲げているが、セキュリティ企業のTrend Microが指摘したように、この機関自身も悪用に対する完全な免疫を持っていない。Trend Microが今年の初めに発見したのは、悪意ある広告主たちが‘domain shadowing’ というテクニックを使って、Let’s Encryptを利用して証明されたドメインのサブドメインを作り、そこに、銀行のトロイの木馬をホストしているサイトへのリダイレクトを挿入した、というものだ。

Trend Microはこう言っている: “善意ある技術でも、サイバー犯罪によって悪用されることがありえる。Let’s Encryptのような機関からのデジタル証明も、その例外ではない。証明を自動的に発行する証明機関が、それらのサブドメインの証明をうかつにも発行したため、サイバー犯罪を助けることになった。ドメインのオーナーはその問題に気づかず、予防もできなかった”。

“ユーザーは、‘セキュアな’サイトが必ずしも安全なサイトではないことに、留意すべきである。われわれの見解としては、悪用に対する最良の防御は、ソフトウェアをつねにアップツーデートに保って、悪用されうる脆弱性の数を最小化することである”、とTrend Microは付け加えている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

やっと、ついに、誰もが無料でHTTPSを使えるようになる!…MozillaやEFFが共同プロジェクトを立ち上げ

理想としては、Webサイトへの接続はすべて、HTTPSによるセキュアな接続であるべきだ。そうすれば、空港やコーヒーショップなどで一般に公開されているネットワークを使っていても閲覧内容を覗き見されるおそれがない。でも現実には、小さなWebサイトの多くがこの種のセキュアな接続を提供していない。HTTPS接続に必要な公開鍵の証明を得るための手続きが、相当面倒だからだ。料金も安くない。

でも、このままでよいわけではない。もうじき、MozillaとCisco、Akamai、Electronic Frontier Foundation(EFF)、IdenTrust、およびミシガン大学の研究者たちが作った研究グループInternet Security Research Groupが、Webのドメインを持っている者なら誰もが無料で利用できる証明機関を創設する。サービスの供用開始は、来年の夏を予定している。

今日(米国時間11/18)、EFFは次のように述べている: “HTTPS(およびTLS/SSLのそのほかの利用)は、現状では恐ろしいほどの複雑さと、構造的に機能不全な、認証をめぐる官僚主義に支配されている”。

Let’s Encryptと呼ばれるこのプロジェクトは、証明が無料で得られるだけでなく、できるかぎりそれが容易簡単であることを目指す。どんなサイトでも、たった二つのシンプルなシェルコマンドでHTTPSを有効化できるようにする。証明の発行や取り消しはすべてパブリック(一般公開)とし、そのプロトコルをオープンスタンダードにすることによって、他の証明機関もそれを採用できるようにする。

このサービスをテストしてみたいデベロッパは、GitHubでそのコードを見られるが、それはまだ本番利用用ではないから、その警告を無視して実際に使おうとすると、大量の警告を食らった挙句に、自分のサイトすら見られない結果になるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


『HTTPSをSEOで優遇』 SSL化を推奨するアルゴリズム導入をGoogleが公式発表

昨日、SEOやWeb周りの方々が少しざわめいておりました。話題となっているのがこちらです。

Google ウェブマスター向け公式ブログ: HTTPS をランキング シグナルに使用します

本件につきましてはきっと多くの方からお問い合わせを頂くことが増えるでしょう、ということが明確ですので、あらかじめ記事にまとめさせて頂く次第でございます。

Q: まず、これは一体何の話ですか?

概要としては、SSL化されたWebサイトをSEOの評価として優遇します(=HTTPSであることが、SEO上のプラスになります)、といったものです。

こうした方針を検討している、という旨をGoogleが初めて発表したのが2014年の初頭に行われたイベントにおいてでした。( 参考:Google、安全なSSL導入サイトの検索順位を優遇したい? 実現は難しそうだが・・・ SMX West 2014 )

関係者の間では、当時から変わらず導入の賛否は分かれているように見えます。どちらかというとサイト全体へのSSL対応についても慎重派がマジョリティな印象です

Q: 影響度はどれくらいあるのですか?

冒頭のGoogleの公式記事をそのまま拝借しますが、

全体的に見ると、このシグナルは良質なコンテンツであるといった、その他のシグナルほどウェイトは大きくありません。HTTPS は、優れたユーザー エクスペリエンスを生み出す多くの要素のうちの 1 つです。

 
ということですのでそこまで大げさなものではなく、実際に公式にも検索の全体のうち1%未満にしか影響しません、と言っていますので、数字だけ見れば、決して日常的な変動に比べて「とても大きな変動」という規模ではありません。ですが、

これから長い期間をかけて強化していきます。

 
とあるように、これからどの程度この流れが加速していくかについては不明です。今すぐに導入せずとも、いずれどこかのタイミングで検討するかもしれない、ということは頭の片隅に置いておいて良いでしょう。

Q: この件について、何か懸念事項はありますか?

例えば、規模にもよりますが導入コストはもちろんですが、SEO的な課題では、URLが変更する問題(全て正しくHTTPSに評価を引き継げるか?とか正規化処理ミスは発生しないか?など)が一般的な問題でしょう。そのほかにも、関係者の皆さんの意見として色々あがっておりまして、

とか、同じくリファラー関連の話では

などの懸念も早速上がっていたり。direct増えるというのは確かに解析を専門としている人にとっては結構厄介な話でしょうね。また、

とか、同じような切り口で

とかっていう、無責任な提案も増えそうで(しかもそのとおりになってしまう事案が本当に多そうで)怖いなというのも思います。更に、

これはもう過去にもありましたし本当に色々想像に難くないのですが、「Googleも公認、SEOに絶大な効果」的な宣伝文句でSSL証明書が販売されるということが絶対にあるでしょうね。

結果としてセキュアなWebサイトが増えるというのは悪いことではないのかもしれませんが、きちんとした意味や背景を理解した上で導入するのと、間違った認識で導入するのではやはり意味は違うかなと思います。

Q: なぜGoogleがSSL化されたHTTPSを優遇するのですか?

基本的に、Googleは「ユーザーがより良質なコンテンツに到達できるように」を基本として検索アルゴリズムを改良しています。

しかし、HTTPSであるかどうかはコンテンツの内容そのものの改善ではなく、通信環境の問題です。少なくとも大部分のユーザーが普段から求めていることではないでしょう。

では、これをなぜGoogleがSSL化を大々的に推奨し、ランキングにまで反映させるのか?というのは実際僕もそんなに腑に落ちていないこともありました。が、

と言えば確かにそれなりに納得できますね。また、

サイト運営会社はグーグルの検索結果で上位に入りたいと考えている。このため、グーグルは検索アルゴリズムで開発者の慣行を促進したり阻止したりできる。例えば、読み込みの遅いサイトは検索結果で不利な扱いを受ける一方、質の高いサイトは上位に表示される。

( 引用元:グーグル、検索結果で暗号化サイトを優遇 「HTTPS」増加を期待 )

 
とあるように、インターネット全体をSSL化の動きに促進するのであれば、Googleが自らのランキングアルゴリズムへの反映というのはサイト管理者の大きなモチベーションになりうる、という理屈も理解できます。

Q: この動きに対して、どう対応するべきですか?

SSL化することで検索結果においてどれだけ優位になるのか?が不明確なこと(少なくとも今は微小)、その中でコストやリスクを負うことになるというのはあまり手放しで推奨しにくいものです。

個人的な見解としては、皆さんがこぞって「SEOの目的で」ワサワサと導入する必要はないんじゃないでしょうかとは思っています。

ですので僕からは現時点では積極提案することはありませんが、いやいや、でもせっかくだからこれを期にSSL化しようよ!という意向であればそれはGoogleも本意でしょうし早速導入されて良いと思います。ただしURL引き継ぎの処理などに漏れのないよう、慎重に進められることをお勧めします。

読み返してみたら引用だらけですみません。また追加情報などございましたら追記いたします。

※8/8追記

こちらにより具体的なQ&Aが紹介されています。
HTTPからHTTPSへの移行で出てきた質問に回答 | 海外SEO情報ブログ

非エンジニア向けSSL解説:OpenSSLの脆弱性「HeartBleed」とは?

GoogleのMatt Cutts氏が「SSL(https)のサイトを優遇するかも」のような発言をしたことや、4月にはOpenSSLの致命的な脆弱性についても話題になりました。今回の記事では、非エンジニア向けにSSLや、指摘されている脆弱性「HeartBleed」について解説します。開発室の坂田による執筆です。

2014年は”SSL”が何かと話題に

以前からGoogleが強制的にSSLで接続するようになったり、2014年に入り、GoogleがSSLのサイトを優先しようか検討している、といった話が出てくるなど、SEO関係者の中でもたびたびSSLが話題に出てくるようになりましたね。

今年の4月ごろ、SSLでの通信を可能にしているOpenSSLというソフトウェアに、個人情報などの通信内容がサーバーから流出する重大な欠陥(脆弱性)が見つかったことが話題となりました。

この脆弱性は、サーバーからの情報流出が、心臓(Heart)から出血(bleed)するほど深刻に捉えられたため、「Heartbleed」と呼ばれています。

どんな形であれ個人情報を扱うようなサイトはセキュリティを担保することが求められます。今回は、SSLの仕組みを改めて理解していただいた上で、この脆弱性「Heartbleed」について解説します。

編集者注:冒頭の「GoogleがSSLのサイトを優先」の話は、Googleでも検討が始まったばかりの未確定事項

SSLの役割と仕組み

SSLは、主に2つの機能を提供しています。1つは、信頼性を担保することです。SSLを使用しているウェブサイトはSSLの証明書を有しています。

この証明書は、第三者機関である認証局(CA)によって発行されています。この証明書により、利用者が、ウェブサイトを信頼できることが保証されています。

もう1つは、暗号化により安全性を担保することです。通常のウェブサイトを表示するために使用するhttp通信は暗号化されていません。そのため、第三者に通信が見られた際、通信している情報が容易に読み取られてしまいます。

ここでいう情報の中には、IDやパスワードなどの会員情報や、住所や名前など、お問い合わせの内容など個人に関わる重要な情報が存在します。

こうした情報を第三者に読み取られないように、暗号化する必要があります。SSLは、通信情報を暗号化する機能を有し、安全な通信を確立する役割を担っています。

SSLの説明

OpenSSLの脆弱性「Heartbleed」とは

OpenSSLとは、実際にこの暗号化を行っているプログラムの一つです。SSLを可能にしているソフトウェアはOpenSSLの他にもNSSやGnuTLSといったプログラムの存在しますが、OpenSSLは非常に高いシェアを占めています。

ところがこのOpenSSLの脆弱性が先日指摘され話題になりました。それがHeartbleedです。

SSLに限らず、サーバーは通信を行うと、メモリに通信内容を一時的に記録します。本来メモリに記録されたデータは、通信が終了すると破棄されます。

ところがHeartbleedという”バグ”により、メモリ上のデータが破棄されず、サーバー外部に流出してしまう場合があります。この流出したデータの中に、個人情報が含まれていると、個人情報の流出といった事態になります。

Heartbleedはサーバーの秘密鍵が流出する場合もある

ここで大きく問題なのは、Heartbleedによる影響は、通信データの一部流出にとどまらず、「サーバーの秘密鍵」の流出の恐れがある点です。

詳しい解説はここでは割愛しますが、SSLでは、共通鍵暗号方式と公開鍵暗号方式の2つの暗号方式を利用して安全性を担保しています。

SSLでサーバー送信した情報は、これらの方式を用いて暗号化されます。この情報は、サーバーの秘密鍵という鍵のみで復号化することが可能です。逆に言えば、この「秘密鍵」さえあれば、第三者でも容易に通信内容を読み取ることができます。

情報流出の危険性

サーバーはひとつの秘密鍵を使用しているため、一度秘密鍵が流出してしまうと、ウェブサイトの利用者の通信内容を継続的に読み取られる可能性があります。例えるなら、隣の人にパソコンのパスワードを知られてしまった状態です

対処法

実際の作業はサーバーなどの環境に依存しますので、具体的には触れませんが、以下の手順を取るとよいでしょう。

Heartbleedかどうか調べる

まずは、OpenSSLのバージョンを調べます。この際、以下のバージョンに当てはまる場合、Heartbleedの脆弱性があります。

またこれらのバージョンに該当しなくとも、古いOpenSSLを使用している場合は、他の脆弱性やバグが存在している可能性もあるので、最新のものにバージョンアップすることをおすすめします。

  • OpenSSL 1.0.1 から 1.0.1f
  • OpenSSL 1.0.2-beta から 1.0.2-beta1

Heartbleedを取り除く

OpenSSLのバージョンを確認し、Hearbleedの影響を受けている場合は、早急に取り除くましょう。最も簡単な方法は、OpenSSLのバージョンを最新のものにします。

また、レンタルサーバー等OpenSSLの設定を変えることのできない場合は、サーバーの管理会社に連絡し、この脆弱性を解消してもらう必要があります。

証明書を再発行し、以前の証明書を失効させる

OpenSSL脆弱性を直したら、SSLの証明書を再発行します。主なSSL発行会社は、無償での再発行を受け付けています。証明書を再発行したら、その設定をサーバーに反映させます。最後に、SSL発行会社を通じて古い証明書を失効させましょう。

まとめ

SSLは、個人情報を取り扱うウェブサイトを安全に運営していく上で、重要な役割を担っています。ウェブサイトの利用者が安心して利用できる環境を整えるためにも、SSLだけでなく、利用している技術やその仕組みを理解し、脆弱性やバグに柔軟に対応していくことが重要です。

最後に、私たち開発室もブログを書いておりまして、技術トピックを中心に、幅広い内容を紹介しています。こちらも参考にしてください。
Catcher in the tech – ヴォラーレ株式会社開発室ブログ

ヴォラーレ株式会社 坂田

Tumblrが(ようやく)SSLをサポート。但し有効にするには設定が必要

GoogleFacebook、そしてTwitterなどからずいぶん遅れることとなったが、Tumblrが(ようやく)SSLに対応することとなった。但し、標準状態ではSSLが無効となっている点に注意が必要だ。つまり自分で設定する必要があるのだ。

セキュリティ意識の高い利用者(現代は全員がそうあるべきだと思うのだが)は、このYahooが提供するブロギングサービスサイトでは、ぜひともSSLオプションをオンにしておくべきだろう。もちろん遠からぬうちに標準でもSSLモードになるのではないかと思う。TwitterもSSLに対応した当初は、SSLによる保護を望む人に手作業による「https」入力を促すという仕組みでの対応だった。SSLを利用しなければ、周囲の人に通信内容を傍受されてしまう可能性があるわけで、とくにコーヒーショップや会議場でのオープンなネットワークを利用するときにはぜひともSSLを利用するのが望ましい。

Tumblrによると、SSLについては数週間のテストを行ってきたのだとのこと。その結果を踏まえて設定画面でSSL対応を指定することができるようになった。Tumblrのダッシュボードからアカウント設定画面にいき、そこで「SSLセキュリティを有効にする」というスイッチをオンにすれば良い。

Tumblrが直ちにSSLを標準の方式としなかったのはなぜだろうか。理由はいろいろとあるのだろうが、たとえばXKitが使えなくなるという理由もあるのではなかろうか。非常にメジャーなエクステンションで、多数の便利機能をTumblr上で実現できるとして、多くの人が利用しているものだ。

XKitのブログでは、TumblrのSSL設定をオンにすると利用できなくなる旨の記事が掲載されていた。ブログ記事によれば、SSL下でも動作するバージョンを開発中であるとのこと現在のところはXKitを選ぶのか、SSLを選ぶのかを選ばなければならない。

当然SSLを選ぶべきだと思う。

訳注)XKitブログにはSSLにも対応した旨の記事が公開されています。

原文へ

(翻訳:Maeda, H