SSL Pinningについて

アプリケーション内部にSSL証明書の検知手段を持つことを SSL Pinning(証明書のピン留め)というようだ。

『Gmail』公式アプリにセキュリティ上の弱点が見つかる。不正プロファイルで通信傍受の恐れ。
http://www.appbank.net/2014/07/16/iphone-news/857025.php

このニュースで議論が持ち上がったと思われる。

“そこで、通常は『証明書のピン留め』という機能をアプリに追加します。”

と言われているが、本当に”通常”の実装なのか、という疑問はある。
また、上記記事ではアプリの脆弱性のように言われているが、果たして『Gmail』アプリの脆弱性として扱うべきなのか。

というのも、2012年時点ではOSでなく、アプリケーション独自でのSSLの検証機構は
アプリケーションの範囲ではない、少なくとも脆弱性ではない、と主張されていた。
======================================================
○スマートフォンアプリケーションでSSLを使わないのは脆弱性か
http://blog.tokumaru.org/2012/02/is-smartphone-application-without-ssl.html

結論としては平文なら告知しなければ脆弱性、という見解。
ブラウザのように平文か暗号化通信かが鍵マークでわからないため、という理由
なので、平文なら基本的には脆弱性に繋がると見て良い、という結論(公開情報
であっても)。
また、SSL通信をユーザ自身や監査機構が傍受して読み取れるようにするのも
潔白の証明にもなる、という考え方。

○スマートフォンアプリのSSLとか
http://togetter.com/li/253510

SSLが防ぐのは通信経路の暗号化、第三者による傍受というところであり、
端末自体の改ざん(root化など)によるアプリケーションの通信内容の
解析/傍受は”アプリケーションの”脆弱性ではないとする。
そもそもSSLにその部分を防ぐ役割はない。
逆に通信内容をユーザ自身が確認しようと思えばできる、ということも
メリットであり、アプリ利用者の権利でないか。

○スマートフォンアプリのSSLとかの解説っぽいもの
http://togetter.com/li/253658

Googleの事例は認証局のクラックによるもの。
OSは信用しているみたいだが、アプリケーションでは信用しない状況は
かなり稀有な例で、そのために通信内容を過剰に秘匿するのは
ユーザの権利を損なっているという考え方。
======================================================

しかし、今は多少潮流が変わってきている気もする。

======================================================
○自社サーバと交信するスマホアプリにおけるサーバ証明書の発行手法について
(SSL Pinningと独自CA再考)
http://blog.kazuhooku.com/2014/07/ssl-pinningca.html

“情報漏洩の防止と利用者の同意に基づいた傍受の容易さを比較した場合、
前者を優先すべきなのは当然だと思うし、SSLにおけるpinningの実装手法に
おいて後者への配慮が望ましいとしても、それがpinningすべきでない
という理由にはならない”

======================================================

2012年時点、そして現在でも、それを希望するユーザに対してはアプリの通信内容を
検証できるようにする、というのは重要なことと思われる。
しかし、実際、CAのクラックだろうが、オペミスによる偽CAの発行であろうが
情報漏洩してしまっている事例があり、かつその可能性も今後もゼロではない以上、
上記の主張に対しては反論しづらいところがある。

Pinningを実装した場合、検証目的でユーザが追加した場合はそれを許可し、
それ以外の場合はAlertを上げて通信を行わないのが理想的な実装ではないだろうか。

ブログでは自社サーバとしか通信しないアプリについては、そもそも他社のCA自体も信用せず、
自社でCAを発行管理してしまえばいい、という案もある。

しかし、スマホアプリとウェブアプリで通信先サーバ(使用証明書)を変えているとか、
スマホアプリしかないならアリだと思うが、ウェブブラウザからの通信もあるなら
現実的ではないだろう。

“SSL Pinningについて、サーバ証明書とCA証明書のどちらをpinすべきかという
点については、前者は鍵の追加・廃止・更新が困難(heartbleedのような場合に
ユーザ側での対応が必要)という可用性の問題が、後者はCAによる誤発行のリス
クをゼロにできないという問題がある”

仕組みがわかっていないのがモロバレではあるが、これによると、CA証明書の方を
アプリ内に”ピン留め”しておけば、サーバ証明書の方を更新しても問題ない可能性がある。

“ピン留め”の問題点はサーバサイドの証明書の変更などによって同時にアプリ側の
アップデートも必要になることだと思っていた。
証明書が変更された際、アプリ側は更新を促すような作りにしなければならないし、
通常Alertと区別するための判別方法を用意しなければならない。
iOSは審査にかなり時間を要するし、Android側もアプリ審査についてはiOS側に
近づいているような気もするので今のような素早いアプリのアップデートは行えなく
なるかもしれない。
そうなると、証明書を先に更新してしまうとアプリリリースまで通信できなく
なってしまう。
アプリを先にリリースしておき、新旧両方の証明書でPinningしておいて、古い方は
有効期限が切れた時点で無効化する実装にしておく、という感じだろうか。

証明書が更新されているかどうかアプリ起動時にサーバに確認するというのは笑い話になると思う。

いずれにしろ、ここまで話が広がっていると、情報漏洩してしまってから、
“スマホの仕様のせいです”、”認証局がクラックされたせいです” という言い訳は、
使いづらい。

重要な情報をサーバと通信するアプリを作るときは、Pinningを要件として組み込むかどうか、
そのリスクを説明した上で事前に確認しておく必要があるということだろう。

現時点ではPinningしていなくても、自分の端末以外の利用者のデータを
傍受する方法は認証局クラックや偽証明書インストールぐらいしか可能性がない気もするので、
個人的にはこれから流行るかどうかわからないようなアプリにはオーバーな対策だと感じる。

偽証明書インストールは、リモートに限らず、「ちょっとスマホ貸して」などでも起こるかも
しれないが、root化は必要だと思うのでちょっと難しい。
冒頭のiPhoneなら構成プロファイルという形なので簡単そうだけど。

カテゴリー: 未分類   パーマリンク

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です