アカウント名:
パスワード:
コンテンツは最適化と言う名の改ざんはできませんよね
※できたら大事
twitterみたいに既にクラウド側で最適化圧縮行うのもあるし
グーグル先生のサービスはどうなんだろう。
端末にあらかじめルート証明書入れればできるでしょ
そりゃ、証明書とURLのチェックでばれるでしょ
証明書を注意深く見れば分かるけどルート証明書がインストールされているので警告はでないし中間者攻撃だからURLは変わらずに送られてくるファイルの内容を改ざんできる
Firefoxでも駄目なの？あれって独自の証明書ストア持ってるよね。
うそを書くなよ。
クライアントとサーバー間でセキュアに通信しているんで、そのデータを間引きできるわけがない。たとえできたとしてもサーバー側でエラーになるよ。
https://www.example.com/ [example.com] と通信するとしよう。普通は www.example.com の HTTPS サーバは、信頼されたルート証明機関、たとえばシマンテックへつながる証明書を送ってくる。端末（ブラウザ）は、自分が信じる「この証明機関は信頼できる」とされる証明機関であるシマンテックへつながる署名があるから、「現在接続している "www.example.com" と名乗るサーバは本物である」と推定する。
ここで、キャリアが独自のルート証明書、"Carrier CA" を出荷時に端末の証明書ストアに入れておくとしよう。ブラウザは www.example.com と思われるホストと通信をし、最終的に "CAREER CA" へつながる署名を確認した。Carrier CA はシマンテック同様に「信頼できる証明機関」だから警告は何も表示しない。通信の両端に居る「"www.example.com" のサーバ」も「クライアント（ブラウザ）」も正常に通信できる（何のエラーも発生しない）。
待て、この通信は本当にセキュアだろうか？
この通信の実態はこう。クライアントは www.example.com につないでいるつもりだったが、実は "Carrier" のサーバと通信している。"Carrier" のサーバはクライアントのつもりになって www.example.com と通信をする。"Carrier" のサーバで一回デコードしてから暗号をかけなおして送信しているわけ（送受信両方とも）。通常ならこういう乗っ取りをやると証明書が信頼されなくなるのでブラウザはエラーを吐くが、 "Carrier CA" は信頼された証明機関なのでブラウザは特に問題ないと判断する。
さて、キャリアである "Carrier CA" が可逆・不可逆圧縮あるいはもっと悪意のある盗聴をおこなっていた場合、利用者（よほど注意深い利用者以外）は気づくだろうか。
というのが #2838996 [mobile.srad.jp] や #2838997 [mobile.srad.jp] や Superfish 、証明機関の事故の話。
利用者が直接気付くのは難しいだろうという点は同意しますが、それでも、今ならCertificate Transparency (CT)があるので、Carrier CAが証明書を偽造していることはすぐに発覚するはずです。そのため、現在のいわゆる「通信の最適化」のように黙って実施することはないと期待して良いのではないでしょうか。
CTが生まれたきっかけも、偽造証明書の事故（DigiNotarのときの）ですし。CT（Certificate Transparency：透かし入り証明書）の現状 [digicert.ne.jp]
この事件が、Googleのエンジニアたちに証明書の偽装に関する新しい解決策の確立を迫りました。Googleは議論の末、ベン・ローリーとアダム・ラングリーという二人のエンジニアが考えたCT（Certificate Transparency：透かし入り証明書）のアイデアを、オープンソース・プロジェクトとして開始しました。
一個だけある「"CAREER CA"」は「"Carrier CA"」の間違いです。「そこだけ違うから信頼できない」という話ではありません。
君が問題を理解できていないのはよくわかったから、ちょっと黙っていてくれないか。その間に「MITM問題」というキーワードをググって勉強しておいてくれたまえ。
キャリア謹製のSuperFish。入れられたら本当に気づかないと思う
そこでHTTP Public Key Pinningですよ
OSの提供するAPIにセキュア通信を丸投げしている場合は使われてるルート証明書のチェックとかしない。こういう加工をやる場合中間パス含めて差し替え(偽造)用の物を作ってパスも再現したりするし、結局アプリが自前で正しい証明書を別の経路で取得してそれと比較するしか無い。そしてセキュア通信APIと証明書をゴニョゴニョするなりOpenSSLなり乗っける必要もあるので結構面倒。# 当然の話なんだけど同じURLで偽装されるんでURLチェックは無意味です。
とりあえずこのタイプの事象に限って言うならMIME偽造だのポート番号変更だので対抗したほうが楽かなぁ…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
とは言ってもセキュア通信の (スコア:0)
コンテンツは最適化と言う名の改ざんはできませんよね
※できたら大事
twitterみたいに既にクラウド側で最適化圧縮行うのもあるし
グーグル先生のサービスはどうなんだろう。
Re:とは言ってもセキュア通信の (スコア:0)
端末にあらかじめルート証明書入れればできるでしょ
Re: (スコア:0)
そりゃ、証明書とURLのチェックでばれるでしょ
Re: (スコア:0)
証明書を注意深く見れば分かるけどルート証明書がインストールされているので警告はでないし
中間者攻撃だからURLは変わらずに送られてくるファイルの内容を改ざんできる
Re: (スコア:0)
Firefoxでも駄目なの？
あれって独自の証明書ストア持ってるよね。
Re: (スコア:0)
うそを書くなよ。
クライアントとサーバー間でセキュアに通信しているんで、
そのデータを間引きできるわけがない。たとえできたとして
もサーバー側でエラーになるよ。
Re:とは言ってもセキュア通信の (スコア:5, 参考になる)
https://www.example.com/ [example.com] と通信するとしよう。
普通は www.example.com の HTTPS サーバは、信頼されたルート証明機関、たとえばシマンテックへつながる証明書を送ってくる。
端末（ブラウザ）は、自分が信じる「この証明機関は信頼できる」とされる証明機関であるシマンテックへつながる署名があるから、「現在接続している "www.example.com" と名乗るサーバは本物である」と推定する。
ここで、キャリアが独自のルート証明書、"Carrier CA" を出荷時に端末の証明書ストアに入れておくとしよう。
ブラウザは www.example.com と思われるホストと通信をし、最終的に "CAREER CA" へつながる署名を確認した。
Carrier CA はシマンテック同様に「信頼できる証明機関」だから警告は何も表示しない。
通信の両端に居る「"www.example.com" のサーバ」も「クライアント（ブラウザ）」も正常に通信できる（何のエラーも発生しない）。
待て、この通信は本当にセキュアだろうか？
この通信の実態はこう。
クライアントは www.example.com につないでいるつもりだったが、実は "Carrier" のサーバと通信している。
"Carrier" のサーバはクライアントのつもりになって www.example.com と通信をする。
"Carrier" のサーバで一回デコードしてから暗号をかけなおして送信しているわけ（送受信両方とも）。
通常ならこういう乗っ取りをやると証明書が信頼されなくなるのでブラウザはエラーを吐くが、 "Carrier CA" は信頼された証明機関なのでブラウザは特に問題ないと判断する。
さて、キャリアである "Carrier CA" が可逆・不可逆圧縮あるいはもっと悪意のある盗聴をおこなっていた場合、利用者（よほど注意深い利用者以外）は気づくだろうか。
というのが #2838996 [mobile.srad.jp] や #2838997 [mobile.srad.jp] や Superfish 、証明機関の事故の話。
Re:とは言ってもセキュア通信の (スコア:1)
利用者が直接気付くのは難しいだろうという点は同意しますが、それでも、今ならCertificate Transparency (CT)があるので、Carrier CAが証明書を偽造していることはすぐに発覚するはずです。そのため、現在のいわゆる「通信の最適化」のように黙って実施することはないと期待して良いのではないでしょうか。
CTが生まれたきっかけも、偽造証明書の事故（DigiNotarのときの）ですし。
CT（Certificate Transparency：透かし入り証明書）の現状 [digicert.ne.jp]
Re: (スコア:0)
一個だけある「"CAREER CA"」は「"Carrier CA"」の間違いです。「そこだけ違うから信頼できない」という話ではありません。
Re: (スコア:0)
君が問題を理解できていないのはよくわかったから、ちょっと黙っていてくれないか。
その間に「MITM問題」というキーワードをググって勉強しておいてくれたまえ。
Re: (スコア:0)
Re: (スコア:0)
キャリア謹製のSuperFish。入れられたら本当に気づかないと思う
Re: (スコア:0)
そこでHTTP Public Key Pinningですよ
Re: (スコア:0)
OSの提供するAPIにセキュア通信を丸投げしている場合は使われてるルート証明書のチェックとかしない。
こういう加工をやる場合中間パス含めて差し替え(偽造)用の物を作ってパスも再現したりするし、
結局アプリが自前で正しい証明書を別の経路で取得してそれと比較するしか無い。
そしてセキュア通信APIと証明書をゴニョゴニョするなりOpenSSLなり乗っける必要もあるので結構面倒。
# 当然の話なんだけど同じURLで偽装されるんでURLチェックは無意味です。
とりあえずこのタイプの事象に限って言うならMIME偽造だのポート番号変更だので対抗したほうが楽かなぁ…