私はこの記事をフォローしています: Android Security:SSL Pinning Android using OkHttp 。
アプリのクライアントはアプリを定期的に更新しないため、約1か月で期限が切れるサーバー証明書(リーフ証明書)を使用してリスクを冒したくありません。
**警告:証明書のピン留めは危険です!**
サーバーチームがTLS証明書を更新する機能を制限します。証明書を固定することで、運用上の複雑さが増し、認証局間での移行が制限されます。サーバーのTLS管理者の祝福なしに証明書のピン留めを使用しないでください!証明書のピン留め
上記の記事では、著者は2つの方法を使用しました。前者はリーフと中間認証を使用しましたが、後者はリーフ認証のみを使用しました。
葉と中間体を使用することは可能ですか?葉が更新されても私のアプリはまだ機能しますか?
中間ピン留めのみを使用しても問題ありませんか?
リーフ、中間CA、またはルートCAを固定できます。すべてが機能しますが、セットアップの詳細に応じて、それぞれに使いやすさとセキュリティのトレードオフが伴います。
あなたがリンクした記事は実際に違いのかなり良い要約を提供します:
リーフ証明書。リーフ証明書に対してピン留めすることで、これが自分の証明書であること、したがってチェーンが有効であることをほぼ100%確実に保証できます。リーフ証明書は有効期限が短い傾向があり、たとえば、秘密鍵が危険にさらされているためにSSL証明書が再発行された場合、更新をプッシュすることができるまでアプリはブリックされます。もちろん、証明書を頻繁に循環させる場合も同じです。
中間証明書。中間証明書に対してピン留めすることにより、その中間認証局がサーバーの証明書を誤って発行しないことを信頼します。これには、同じ証明書プロバイダーを使用している限り、アプリを更新しなくてもリーフ証明書への変更が機能するという利点もあります。
ルート証明書。ルート証明書に対してピン留めすることにより、ルート認証局と、証明書を誤って発行しないことを信頼する仲介者を信頼します。多くの場合、ルート機関と中間機関は同じ会社です。この場合、信頼している人の数に大きな違いはありませんが、常にそうであるとは限りません。
記事で言及していることに加えて、証明書を固定すると、アプリがその証明書を暗黙的に信頼し、ステータス情報を探すことはないため、その証明書を取り消すCAの機能が削除されます。そのロジックにより、CA(中間またはルート)のピン留めには、リーフ証明書が期限切れになると、誤って秘密鍵をgithubなどで公開したためにハッキングされるという利点があります。新しいもの。アプリは引き続き機能します。
個人的には、リーフを固定することは避けます。なぜなら、証明書を証明書にする部分、つまり取り消しと信頼ルートへのチェーンを本質的に削除するからです。 openssl genrsa
と公開鍵をアプリにピン留めします。これは、証明書であることによるメリットがまったく得られないためです。
つまり、CAをピン留めすると、アプリはそのCAによって発行されたすべての証明書を信頼します。あなたはそれで大丈夫かもしれません、それはおそらくそれがあなたのプライベートな企業のCAであるか、または証明書がピン留めされたCAにチェーンされることを保証するために追加の証明書検証ロジックを実装する必要があるかもしれませんand名前はアプリが期待するものと一致します(そして、CAがあなた以外の人にその名前の証明書を誠意を持って発行することは決してないことを確信します)。
概要:リーフ、中間CA、またはルートCAの固定は、多少の賛否両論ありますが、すべて許容可能なプラクティスです。アプリにとって意味のあることは何でもしてください。