アカウント名:
パスワード:
たとえ、脆弱な SSL/TLS 通信であっても HTTP（平文）よりは安全な場合には、アクセス不可にしたり、警告メッセージを表示したりする必要はないでしょう。こういったことがあると、HTTPS から HTTP への移行 [security.srad.jp]が行われるようになり、かえってセキュリティレベルを悪化させます。
どうすれば良いかというと、ブラウザは、脆弱な SSL/TLS に対して鍵マークを表示したりアドレスバーの色を平文通信と変えたりせずに、http（平文）のサイトと全く同じようにユーザーに見せれば良いでしょう。最近のブラウザはアドレスバーをクリックしない限り「http://」を表示しないので、脆弱な https の場合には http に倣って、アドレスバーをクリックするまで「https://」の文字も表示しないようにすれば良いでしょう。そうすれば、ユーザーは http と同様の信頼のサイトとみなすことになるので、セキュリティ上の問題は生じません。
～ここから先は SHA-1 脆弱性対応に関する Google への批判です ～
SHA-2 証明書への移行についても、Google の対応には問題があります。そもそも、SHA-1 → SHA-2 の移行スケジュールについては、2013年11月にMicrosoftが SHA-2 への移行を発表し、かなり前に Microsoft・認証局・業界団体等の間で、
ということでコンセンサスが得られていたはずです。
IE や Mozilla Firefox などのブラウザも、これに従い、2017年1月以降に SHA-1 証明書の拒否（Firefox は加えて、2016年以降に発行された証明書に警告を表示）というスケジュールでの移行を行うとしています。
ところが、Google だけが自己中心的な暴挙に出て、業界のコンセンサスを無視した強行な移行を行おうとして、Chrome 39（2014年11月リリース）で証明書の有効期限が2016年以降のSHA-1証明書のhttps接続の際に、鍵マークを警告アイコンにするといった行為を行いました。
確かに、SHA-1 の脆弱性問題については、数ある SSL/TLS 脆弱性の中でも例外となる珍しいセキュリティ上の問題でして、SHA-1で署名を偽造してSHA-2の署名付き証明書に見せかけることができるため、SHA-1のサポートをブラウザから完全に廃止するしかありません。「http（平文）のサイトと全く同じようにユーザーに見せれば良い」というのも当てはまりません。
しかし、SHA-1 に脆弱性が新たな脆弱性が発見されたのではなく、CPU・GPUの性能向上で解読にかかる時間が徐々に減っているというだけのことで、強度が弱いのは10年以上前からわかっていたことです。業界のコンセンサスから勝手に1年前倒しする理由にはなりません。
また、証明書の移行というのは企業にとっては大がかりなタスクとなります。一部の顧客を切り捨てることになるわけなので、顧客に周知したり、代替手段を用意したりする必要があります。例えば、銀行だったら、普通の脆弱性のように技術部門がパッチをあてて終わりというようなものではなく、かなり上の役職の人が行う会議での議決が必要になるでしょう。また、電話サポートの人員を増やすといった対応も必要となります。スケジュールが急な結果、みずほ銀行のWebサイト（ネットバンキングを除く）は、HTTPS → HTTP のみ → 批判を受けて HTTPS 版を復活 → 最終的に HTTP（平文）のみにするといったことになり、「SHA-2への移行」ではなく「HTTPへの移行」となってしまいました。
Google の暴挙によって、ユーザーは、メガバンクを含む大手金融機関などの有名サイト [mizuhobank.co.jp] でも壊れた鍵アイコンを頻繁に見にすることになりました。それにより、ユーザーはこういったセキュリティ上の警告が表示されることに慣れてしまい、セキュリティ警告が出たとしても気にせず続行するようになってしまいました。例えば、HTTPS 通信の中に広告（外部JavaScript）が含まれていて、その外部JavaScriptがHTTP通信の場合には通信が改竄されると危険が生じるわけですが、そういった暗号化されていないスクリプトが混ざっている場合の「壊れたアイコン」も、殆どのユーザーは気にしなくなったのでは？ 結果として、Google の暴挙は、多くの一般ユーザーを危険に晒すことになりました。
いやいやいや、今回の件は、どう考えてもIIS 5.0とかApache 1.3系/2.0系を使っているサーバーの方が問題でしょう。とっくのとうにサポート切れてますよ。アクセス不可にするのは正解ですって。
そりゃ難癖、言いがかりのレベルだなぁ
もっと早く対処すればいいだけの話でしょ、それこそ昔からわかってたんなら当然コンセンサス？なにそれ。それで誰が救われるのかと言えば業界だけで、ユーザーは救われないじゃん暴挙というならそれ早く死に物狂いでなんとかしろよ、ユーザー守るためにそれをしないならやっぱり無能だし、なんかやってるGoogleが有能ってだけでしょ
ガラケーユーザにも配慮を、、、と携帯会社の中の人が設定変更を拒否したケースがあると聞いたが、、、まぁ人伝なのでガセだろう。
某システム屋ですが、ガラケーからのアクセスを許容しつつ最新化も可能ですよ？
SHA2対応してるガラケーあるにも関わらずSHA2の件でこれ幸いとガラケーサポート切ったところならちらほら知ってます
Twitter とか LINE とか Biglobe とか？
クライアント側でのフォールバックを許すと、中間者攻撃にかなり弱くなりますよ。新しいプロトコルのパケットを妨害することで、強制的に古いプロトコルにフォールバックを起こさせることが可能になるので。
確かに、クライアント側でのフォールバックを許すと、中間者攻撃に対して脆弱です。
しかし、「HTTP（平文）」より危険という訳ではないので、HTTP（平文）で表示されない警告を出したり、接続を拒絶したりする必要はないのでは？
「クライアントサイドでのTLS 1.0へのフォールバックを廃止」して当該サイトへの接続を不可にするのではなく、クライアントサイドでのTLS 1.0へのフォールバックが行われた場合には、ブラウザUI上でユーザーに対してHTTP（平文）と同様の表示を行う（錠アイコンを無しにする、アドレスバーをクリックしない限り「https://」を表示しないなど）という対応で良いと思います。
HTTP（平文）接続の場合、情報を盗み取ることも、改竄することも容易に可能ですが、ユーザーを不安にするような警告ダイアログや、アイコンが表示されることはありません。少なくとも、平文通信と比べて危険という訳ではないのですから、平文通信とUI上の表示を同じにしてしまえば問題が無くなります。安全な通信でないということは「錠アイコンが表示されていない」ことから判別できます。
いや、それではダメです。セッションの途中でTLS 1.0にフォールバックさせられた場合、GETやPOSTのパラメータが予期せず弱いプロトコルで流れてしまいます。やっぱり接続不可は正しいと思いますよ。
HTTPSページからHTTPページにPOST飛ばす時と同じ挙動にすりゃいいだけじゃねぇか。昔IEでは一々警告出てたアレ。HTTPよりは安全だしアレ並にする必要もなさ気だが。
> セッションの途中でTLS 1.0にフォールバックさせられた場合フォールバック先で認証も改竄できるならその懸念も判るけど、そうでなければどこかしら矛盾が出るから検出できるんでない？
そんなことするぐらいなら、現在Firefoxが行っているホワイトリストによる対応の方がはるかにマシですよ。
でも結局、大迷惑なのはこの一件で利用したいサービスが利用出来なくなった利用者な訳で、Google にしてもサービス提供者にしても責任を負うべき。（善悪の判断はこの際置いといて）
たとえばBEASTはTLS 1.1以上で防げるし、Lucky 13はGCMを使った暗号スイート(TLS 1.2が必要)で防げると言っていた人 [security.srad.jp]がいますけど、TLS 1.0へのフォールバックを許していると全く意味がありませんね。まあChromeはBEASTとLucky 13に関しては別の方法で対策していますけど。
平文なサイトもまとめて 「危険なサイトに接続しようとしています」と表示してあげたほうがシンプルで理解しやすいし、親切だと思う。そこから先は自己責任で。
僕もこれが一番だと思う。銀行とかなんで対応遅いんだよってユーザーが意識できるのは良い事。
激しく同意。問題は、最近のブラウザが”自己責任による自由”を悉く認めなくなって来ている事なんだよね。Chrome は言うに及ばず、Firefox も Chrome を真似てそういう方向に傾いて来てるし、Edge は未完成商法で論外だし。
まったくだ。ちょっと訂正するならざっくり「危険」ではなく「通信の安全性が存在しない」とかにしときたいが。
# HTTPの平文→通信の安全性が存在しないサイトに接続しようとしています# 脆弱HTTPS→通信の安全性が低下しているサイトに接続しようとしています# 推奨HTTPS→通信の安全性が確認されているサイトに接続しようとしています# 俺俺証明書→危険なサイトに接続しようとしています# # で、フィンガープリント表示して、正規のものであると確認させてから記録して記憶するオプションも出しておく
#2877544 のドコが「参考になる」んだ？？？
普通の人は、httpsかhttpかの違いしかわからない。(それさえも知らない人多い)httpsだけど危ないかもよ、っていうのがわからない。だからクリックしてhttpsだったらOKになってしまう。
オレオレ証明書の場合は警告でるけど、それと同じような扱いでいいと思うけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
Google の暴挙がユーザーを危険に晒す (スコア:0)
たとえ、脆弱な SSL/TLS 通信であっても HTTP（平文）よりは安全な場合には、アクセス不可にしたり、警告メッセージを表示したりする必要はないでしょう。こういったことがあると、HTTPS から HTTP への移行 [security.srad.jp]が行われるようになり、かえってセキュリティレベルを悪化させます。
どうすれば良いかというと、ブラウザは、脆弱な SSL/TLS に対して鍵マークを表示したりアドレスバーの色を平文通信と変えたりせずに、http（平文）のサイトと全く同じようにユーザーに見せれば良いでしょう。最近のブラウザはアドレスバーをクリックしない限り「http://」を表示しないので、脆弱な https の場合には http に倣って、アドレスバーをクリックするまで「https://」の文字も表示しないようにすれば良いでしょう。そうすれば、ユーザーは http と同様の信頼のサイトとみなすことになるので、セキュリティ上の問題は生じません。
～ここから先は SHA-1 脆弱性対応に関する Google への批判です ～
SHA-2 証明書への移行についても、Google の対応には問題があります。そもそも、SHA-1 → SHA-2 の移行スケジュールについては、2013年11月にMicrosoftが SHA-2 への移行を発表し、かなり前に Microsoft・認証局・業界団体等の間で、
ということでコンセンサスが得られていたはずです。
IE や Mozilla Firefox などのブラウザも、これに従い、2017年1月以降に SHA-1 証明書の拒否（Firefox は加えて、2016年以降に発行された証明書に警告を表示）というスケジュールでの移行を行うとしています。
ところが、Google だけが自己中心的な暴挙に出て、業界のコンセンサスを無視した強行な移行を行おうとして、Chrome 39（2014年11月リリース）で証明書の有効期限が2016年以降のSHA-1証明書のhttps接続の際に、鍵マークを警告アイコンにするといった行為を行いました。
確かに、SHA-1 の脆弱性問題については、数ある SSL/TLS 脆弱性の中でも例外となる珍しいセキュリティ上の問題でして、SHA-1で署名を偽造してSHA-2の署名付き証明書に見せかけることができるため、SHA-1のサポートをブラウザから完全に廃止するしかありません。「http（平文）のサイトと全く同じようにユーザーに見せれば良い」というのも当てはまりません。
しかし、SHA-1 に脆弱性が新たな脆弱性が発見されたのではなく、CPU・GPUの性能向上で解読にかかる時間が徐々に減っているというだけのことで、強度が弱いのは10年以上前からわかっていたことです。業界のコンセンサスから勝手に1年前倒しする理由にはなりません。
また、証明書の移行というのは企業にとっては大がかりなタスクとなります。一部の顧客を切り捨てることになるわけなので、顧客に周知したり、代替手段を用意したりする必要があります。例えば、銀行だったら、普通の脆弱性のように技術部門がパッチをあてて終わりというようなものではなく、かなり上の役職の人が行う会議での議決が必要になるでしょう。また、電話サポートの人員を増やすといった対応も必要となります。スケジュールが急な結果、みずほ銀行のWebサイト（ネットバンキングを除く）は、HTTPS → HTTP のみ → 批判を受けて HTTPS 版を復活 → 最終的に HTTP（平文）のみにするといったことになり、「SHA-2への移行」ではなく「HTTPへの移行」となってしまいました。
Google の暴挙によって、ユーザーは、メガバンクを含む大手金融機関などの有名サイト [mizuhobank.co.jp] でも壊れた鍵アイコンを頻繁に見にすることになりました。それにより、ユーザーはこういったセキュリティ上の警告が表示されることに慣れてしまい、セキュリティ警告が出たとしても気にせず続行するようになってしまいました。例えば、HTTPS 通信の中に広告（外部JavaScript）が含まれていて、その外部JavaScriptがHTTP通信の場合には通信が改竄されると危険が生じるわけですが、そういった暗号化されていないスクリプトが混ざっている場合の「壊れたアイコン」も、殆どのユーザーは気にしなくなったのでは？ 結果として、Google の暴挙は、多くの一般ユーザーを危険に晒すことになりました。
Re:Google の暴挙がユーザーを危険に晒す (スコア:3, すばらしい洞察)
いやいやいや、今回の件は、どう考えてもIIS 5.0とかApache 1.3系/2.0系を使っているサーバーの方が問題でしょう。とっくのとうにサポート切れてますよ。アクセス不可にするのは正解ですって。
Re: (スコア:0)
そりゃ難癖、言いがかりのレベルだなぁ
もっと早く対処すればいいだけの話でしょ、それこそ昔からわかってたんなら当然
コンセンサス？なにそれ。それで誰が救われるのかと言えば業界だけで、ユーザーは救われないじゃん
暴挙というならそれ早く死に物狂いでなんとかしろよ、ユーザー守るために
それをしないならやっぱり無能だし、なんかやってるGoogleが有能ってだけでしょ
Re: (スコア:0)
ガラケーユーザにも配慮を、、、と携帯会社の中の人が設定変更を拒否したケースがあると聞いたが、、、
まぁ人伝なのでガセだろう。
Re: (スコア:0)
某システム屋ですが、ガラケーからのアクセスを許容しつつ最新化も可能ですよ？
Re: (スコア:0)
SHA2対応してるガラケーあるにも関わらず
SHA2の件でこれ幸いとガラケーサポート切ったところならちらほら知ってます
Re: (スコア:0)
Twitter とか LINE とか Biglobe とか？
Re: (スコア:0)
クライアント側でのフォールバックを許すと、中間者攻撃にかなり弱くなりますよ。新しいプロトコルのパケットを妨害することで、強制的に古いプロトコルにフォールバックを起こさせることが可能になるので。
Re:Google の暴挙がユーザーを危険に晒す (スコア:2)
確かに、クライアント側でのフォールバックを許すと、中間者攻撃に対して脆弱です。
しかし、「HTTP（平文）」より危険という訳ではないので、HTTP（平文）で表示されない警告を出したり、接続を拒絶したりする必要はないのでは？
「クライアントサイドでのTLS 1.0へのフォールバックを廃止」して当該サイトへの接続を不可にするのではなく、クライアントサイドでのTLS 1.0へのフォールバックが行われた場合には、ブラウザUI上でユーザーに対してHTTP（平文）と同様の表示を行う（錠アイコンを無しにする、アドレスバーをクリックしない限り「https://」を表示しないなど）という対応で良いと思います。
HTTP（平文）接続の場合、情報を盗み取ることも、改竄することも容易に可能ですが、ユーザーを不安にするような警告ダイアログや、アイコンが表示されることはありません。少なくとも、平文通信と比べて危険という訳ではないのですから、平文通信とUI上の表示を同じにしてしまえば問題が無くなります。安全な通信でないということは「錠アイコンが表示されていない」ことから判別できます。
Re:Google の暴挙がユーザーを危険に晒す (スコア:1)
表示しようとしているページはプライベートな情報を含むんですから、
HTTP より危険じゃないという理由だけでは採用できません。
Re: (スコア:0)
いや、それではダメです。セッションの途中でTLS 1.0にフォールバックさせられた場合、GETやPOSTのパラメータが予期せず弱いプロトコルで流れてしまいます。やっぱり接続不可は正しいと思いますよ。
Re: (スコア:0)
HTTPSページからHTTPページにPOST飛ばす時と同じ挙動にすりゃいいだけじゃねぇか。
昔IEでは一々警告出てたアレ。HTTPよりは安全だしアレ並にする必要もなさ気だが。
> セッションの途中でTLS 1.0にフォールバックさせられた場合
フォールバック先で認証も改竄できるならその懸念も判るけど、
そうでなければどこかしら矛盾が出るから検出できるんでない？
Re: (スコア:0)
そんなことするぐらいなら、現在Firefoxが行っているホワイトリストによる対応の方がはるかにマシですよ。
Re: (スコア:0)
でも結局、大迷惑なのはこの一件で利用したいサービスが利用出来なくなった利用者な訳で、Google にしてもサービス提供者にしても責任を負うべき。
（善悪の判断はこの際置いといて）
Re: (スコア:0)
たとえばBEASTはTLS 1.1以上で防げるし、Lucky 13はGCMを使った暗号スイート(TLS 1.2が必要)で防げると言っていた人 [security.srad.jp]がいますけど、TLS 1.0へのフォールバックを許していると全く意味がありませんね。まあChromeはBEASTとLucky 13に関しては別の方法で対策していますけど。
Re: (スコア:0)
平文なサイトもまとめて
「危険なサイトに接続しようとしています」
と表示してあげたほうがシンプルで理解しやすいし、親切だと思う。
そこから先は自己責任で。
Re: (スコア:0)
僕もこれが一番だと思う。
銀行とかなんで対応遅いんだよってユーザーが意識できるのは良い事。
Re: (スコア:0)
激しく同意。
問題は、最近のブラウザが”自己責任による自由”を悉く認めなくなって来ている事なんだよね。
Chrome は言うに及ばず、Firefox も Chrome を真似てそういう方向に傾いて来てるし、Edge は未完成商法で論外だし。
Re: (スコア:0)
まったくだ。
ちょっと訂正するならざっくり「危険」ではなく「通信の安全性が存在しない」とかにしときたいが。
# HTTPの平文→通信の安全性が存在しないサイトに接続しようとしています
# 脆弱HTTPS→通信の安全性が低下しているサイトに接続しようとしています
# 推奨HTTPS→通信の安全性が確認されているサイトに接続しようとしています
# 俺俺証明書→危険なサイトに接続しようとしています
# # で、フィンガープリント表示して、正規のものであると確認させてから記録して記憶するオプションも出しておく
Re: (スコア:0, オフトピック)
#2877544 のドコが「参考になる」んだ？？？
Re: (スコア:0)
普通の人は、httpsかhttpかの違いしかわからない。(それさえも知らない人多い)
httpsだけど危ないかもよ、っていうのがわからない。だからクリックしてhttpsだったらOKになってしまう。
オレオレ証明書の場合は警告でるけど、それと同じような扱いでいいと思うけどね。
Re: (スコア:0)
> 普通の人は、httpsかhttpかの違いしかわからない。(それさえも知らない人多い)
> httpsだけど危ないかもよ、っていうのがわからない。だからクリックしてhttpsだったらOKになってしまう。
だから、もう使えなくしちゃえば安全になるじゃないかという発想なんでしょう。
そもそも危険なもん公開している方が問題だろう。
というスタンス。
見るための物は無料で手に入る（Chrome以外もある）。
セキュリティを唱えても中途半端に使えると浸透しないのはメールだとかFTPだとか無くならない状況を見ればわかるしね。
癒着と知識不足が多い大企業では（サーバー変更しないととかWebサーバーアプリ買い直さないととか）必要以上に金かかるのでそう簡単な話ではないんだがね（直ちに解決できない現実問題としてね）。
# HTTPS everywhereはいいんだけどSSL証明書つくんのもなにかとめんどくさいし金もかかるしその辺なんとかしてくれんもんかね。