SSLv2に含まれる脆弱性(DROWN)について

ウェブサイトを閲覧するときのお話です。
「http://~」ではなく「https://~」で始まるURLへアクセスすると、なんだか安心感がありますよね。

SSL認証の鍵マーク
SSL認証の鍵マーク

この鍵マークがあれば『サーバーとの通信が暗号化されていますよ』ということなのですが、この暗号化された通信であっても『解読される恐れがある』という脆弱性が発見されました。

あまり不安を煽りすぎるのもどうかと思うのですが、発見された脆弱性を突いて悪意のある第三者が暗号化を解読する可能性があるのは、
・HTTPSサーバーがSSLv2で接続可能な場合
・SSLv2で接続できる他のサーバーで同じ秘密鍵を使い回している場合
であり、現在のWEBサーバーの主たる設定ではありません。
※現在はSSLと表記していても、技術的後継であるTLSに移行しています。

しかしながら…
・未だHTTPSサーバーの17%でSSLv2接続を行って
おり、
・秘密鍵を使い回ししているHTTPSサーバーが16%存在
するそうです。

企業のサーバー管理者の皆様、「SSL/TLSを導入しているから安心」だと思っていませんか?
ご自分の企業のWEBサーバーはお客様へ安心できるセキュリティを提供できているでしょうか?
是非一度ご確認ください。
ご不明な場合はご相談もお承りいたします。

参考リンク:
The DROWN Attack(研究者たちが立ち上げたDROWNに関する情報ページ) → 外部リンク
全HTTPSサイトの33%でSSL/TLSが解読される恐れのある脆弱性「DROWN」、OpenSSLチームは修正パッチを配布 → 外部リンク
SSLの脆弱性で日本の大手サイトを含む全世界1100万以上のHTTPSサイトが攻撃を受け得ると判明 → 外部リンク

The HTTPS-Only Standard

以前から推奨はされていましたが、米国行政管理予算局(Office of Management and Budget:OMB)が正式メモランダムとしてThe HTTPS-Only Standardに署名をしたとのことです。
この覚書により、アメリカ連邦政府のWEBサイトは2016年12月31日までに全てHTTPS通信のみに移行するようです。

皆さんのWEBサイトは、セキュアな環境をお客様に提供できていますか?

The HTTPS-Only Standard
HTTPS通信のみをスタンダードにする

『アメリカ連邦政府のサイトは、暗号化されたWEBサイトの通信のみにする』というCIO.govの掲示

HTTPS-Everywhere for Government
HTTPS – 身近な政府のために

『すべての公的にアクセス可能な連邦のウェブサイトは、2016年12月31日までにHTTPSのみの規格を満たしている必要がある』トニー·スコット 米国最高情報責任者の掲示

貴社から送信されるメールは認証されていますか?

当社のドメインは、弊社代表進藤がコチラにも書いているとおり cast.works です。
が、実は castworks.co.jp という日本国内の企業向け(co.jp)ドメインも他者によるいたずら防止のため、所持しています。

これら二つのドメインはいずれも cast.works のサーバで処理されるようになっているため、同一のコンテンツが表示されています。

最近のレンタルサーバでも、ここまではできるようになってきたサーバが見受けられますが、これ以上となるとなかなか「レンタル」で要件を満たすサーバは借りられません。

さらにタイトルのとおり、認証されたメールを送信可能な「レンタル」サーバはまだ多くありません。

皆さんも日々数多くの迷惑メールを受けとっていると思いますが、この迷惑メールのFromアドレスをよく見てみると、どこかの企業やサイトになりすましたメールが多いことに気がつきます。
電子メールは仕様上、送信元であるFromアドレスを自由に設定し、送信できてしまう仕組みです。
このためフィッシングメールなど、迷惑メールのほとんどは Fromアドレスをなりすまして送信されています。

【送信ドメイン認証とは?】
とは、送信者のアドレスが正規なものであることを証明する技術です。正確に言うと、そのメールアドレスのドメインを見て、それが正規なサーバーから発信されているか否かを検証します。

送信ドメイン認証の技術は、大きく二種類に分けられます。
一つは送信元IPアドレスを根拠に、正規のサーバーから送られたかどうかを検証する技術。
もう一つは、送られたメールの中に電子署名を挿入し、その正当性を検証する技術。
前者には SPF という技術があり、後者には DKIM があります。

総務省が、これらの技術についての普及率を(2014年6月時点)公開していますが、実際には携帯キャリアの数字が大半であろうことから、一般に使用されるメールアドレスにはこれらの数字はあてはまりにくいのではないかと思います。

BtoC や 一部の信用が重要な BtoB の事業では、ますます『メールアドレス(ドメイン)』の正当性に対する重要性が増してきています。
メールを送信しても、顧客のメールソフトにおいて「スパムメール」または「迷惑メール」フォルダにメールが自動で送られ、顧客の目にとまらない…そのような事態をさけるためにも、御社がお持ちのドメインに『送信ドメイン認証』を導入できるサーバーを運用してみませんか?

興味がある方は、お気軽に お問い合わせフォーム からご相談ください。

【注記】ちなみに、弊社のメールアドレスは、info@cast.works でも info@castworks.co.jp でも同一のメールボックスに届くため、別々のメールアドレスを管理する必要はありません。また、両ドメインとも当然ながら SPF・DKIM を別々に設定しているため、どちらのドメインでメールを送信しても「failed」(不正なメール)として扱われることはありません。

WEBサーバのSSL設定

WEBサーバのSSL設定は、デフォルトのまま利用すると今の世の中の現状からするとかなり甘い設定になっています。
デフォルトのまま利用し続けると、セキュリティ上かなり心配です。

Google Chrome の SSL認証鍵マーク
Google Chrome の SSL認証鍵マーク

しかし、一方でガラケーへの対応が必須になっているサイトであったりする場合、むやみやたらとセキュリティを高く設定すると、古いガラケーがサイトに接続できなくなってしまいます。
また一般的なレンタルサーバではこのような設定項目は無く、ホスティング業者さんの設定に任せるしかありません。

利用者の環境とセキュリティの強度という相反する事柄に対応しなければならないため、このあたりの設定はバランスが非常に難しく、いつも悩ましいところです。

右の図は、WEBブラウザ Google Chrome の 当サイトにおける SSL認証時のセキュリティ表示です。

大抵のブラウザにおいて、SSL認証がかかっているページでは URL表示欄右側が緑色に表示されますが、この状態のとき、鍵マークをクリックしてみてください。
このような表示が現れます。

貴社のサイトに「◯◯◯への接続は古い暗号化技術により暗号化されています」等と表示されている場合は、WEBサーバの管理者へ連絡し TLSのバージョンと、CipherSuite の値について設定を見直してもらってください。

※ガラケー対応が必須、特定のバージョンの WEBブラウザへの対応が必要など場合を除いてどうしても対応できない場合もあります。