アカウント名:
パスワード:
多くの解説サイトや書籍が、TLS (や既に過去の遺物である SSL) と HTTP Over TLS [ietf.org] (所謂 https) というレイヤーの全く違う規格を混同した記事を書いているせいか、誤解している人が多いようですが、 TLS として正しく「サーバ証明書の検証」 [wikipedia.org] したとしても HTTP Over TLS における成り済まし攻撃は防げません。
もっと具体的にいうと、OpenSSL を使っているならSSL_CTX_set_verify [openssl.org] で、TLS としての「サーバ証明書の検証」ができますし、これで TLS としての「サーバ証明書」の検証が終わったことになりますが、それだけでは不十分なのです。何故ならば、通信を改ざんした悪意のある第三者が、別の証明書（悪意
要約：HTTPS等はTLSの証明書チェーンの検証に加えてCommonNameをチェックしないと通信が他所を向いたとき等に大穴があくので、みんなWarnings About Using SSLSocket Directly [android.com]を参考にチェックするコード書いてね。
多分、自分所のサーバーで使ってる証明書の一部をアプリに持たせて検証させたほうが簡単で早いね。どーせアプリ自体が改竄されたらそのクライアントは諦めるしか無いんだし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
https を使うなら 「サーバの証明書の検証」だけでは不十分 (スコア:2)
多くの解説サイトや書籍が、TLS (や既に過去の遺物である SSL) と HTTP Over TLS [ietf.org] (所謂 https) というレイヤーの全く違う規格を混同した記事を書いているせいか、誤解している人が多いようですが、 TLS として正しく「サーバ証明書の検証」 [wikipedia.org] したとしても HTTP Over TLS における成り済まし攻撃は防げません。
もっと具体的にいうと、OpenSSL を使っているならSSL_CTX_set_verify [openssl.org] で、TLS としての「サーバ証明書の検証」ができますし、これで TLS としての「サーバ証明書」の検証が終わったことになりますが、それだけでは不十分なのです。何故ならば、通信を改ざんした悪意のある第三者が、別の証明書（悪意
Re:https を使うなら 「サーバの証明書の検証」だけでは不十分 (スコア:2, 参考になる)
要約：HTTPS等はTLSの証明書チェーンの検証に加えてCommonNameをチェックしないと通信が他所を向いたとき等に大穴があくので、みんなWarnings About Using SSLSocket Directly [android.com]を参考にチェックするコード書いてね。
Re: (スコア:0)
多分、自分所のサーバーで使ってる証明書の一部をアプリに持たせて検証させたほうが簡単で早いね。
どーせアプリ自体が改竄されたらそのクライアントは諦めるしか無いんだし。