クライアント証明書による認証とHMAC

Question

非常に限られた数の信頼されたクライアント（おそらくサーバークラスター）での使用を目的としたAPIを設計しています。 APIはHTTPSを介してのみアクセスできます。クライアントを認証するために、3つの方法を検討しています。

TLSクライアント証明書。サーバーとクライアントの両方が同じ組織によって運営されているため、証明書は内部で発行される場合があります。
一部のデータアイテムに対するHMAC-SHA1：リクエストごとにリクエストされたURL、日時など。 MACはHTTPヘッダーに配置されます。つまり、 Amazon S3のより単純なバージョンREST authentication です。
事前共有のユーザー名とパスワードによるHTTP基本認証。

私の理解に：

TLS証明書は3つのうち「最も安全」ですが、HTTP基本認証は「最も安全ではありません」です。「最も安全な」とは、この方法が他の人によっても保護されているすべての攻撃に対する保護を提供するという意味です。
HMAC-SHA1はリプレイ攻撃に対して脆弱ですが、とにかく通信はTLSによって保護されるため、問題はありません。
HTTP基本認証では、共有シークレットが常時（TLSで保護されていますが）回線上に置かれているため、（根拠のない）懸念がいくつかあります。

私のポイントは正しいですか？他に知っておくべきセキュリティ上の問題はありますか？

Gabor Lengyel · Accepted Answer

うまくまとめたと思います。

これらのソリューションの技術的なセキュリティを超えたいくつかの追加ポイント：

TLS証明書には管理が必要で、期限切れなどがあります。証明書の管理（ある程度自動化できる）リソースがあるかどうかを検討する必要があります。かなり悪いシナリオは、IT運用がすべての問題にうんざりしていて、証明書の検証を無効にしている場合ですそれが機能するだけです。 ;）
HMAC-SHA1署名の実装も適度に優れており、リプレイの時間枠を制限できます（また、TLSでは問題ありません）。ただし、実装は他よりも複雑です。コードを保守するのが大規模なチームである場合、特に実装を時々変更する必要がある場合は、問題が発生する可能性が高くなります。他の2つは、作成する必要があるソースコードの点ではるかに単純です。
HTTP Basicは非常にシンプルで、TLSでも問題ないかもしれませんが、あなたが言ったように、3つのうちで最も安全性が低いと言えます。多くの人々はまだそれが多くの目的のために十分であると考えています、それはあなたが何を保護したいかによります。 TLSはMitM攻撃者に対して安全であると見なされています。最大の利点は単純さだと思います。迷うことはあまりありません。

kubanczyk · Answer

それは私にとって非常に簡単です：TLSクライアント側の証明書。それらは最も速く、最も安全で、最低限の自作であり、あなたはあなたが言うすでにTLSライブラリを使用しています。また、実装の点でHMACオプションよりもかなり単純です。

公開キー基盤（PKI）のことは行わないでください。単にクライアント側に100年間有効な自己署名証明書を生成させ、CAではないものとしてマークします。サーバー上のその証明書を信頼します。 PKI、YAGNIを作成する理由はありません...それはあなたの問題を解決しません、それはCRLまたはOCSPの問題、SHA1クラスの問題および他の多くの副作用をもたらします。自己署名証明書を単なるRSA公開鍵と考えてください。これは実際には1つです。

クライアントとサーバーの両方がTLSセッションをキャッシュすることを確認します。これにより、非常に高速なTLS接続が可能になります。（サーバー側の証明書のみを持っている場合、これはメリットがあります。クライアント側の証明書を追加すると、2倍のメリットがあります。）

これを使用したプログラミングはほとんどありません。これには、いくつかのテキスト（使用するトラストストアファイルの場所など）を渡す単純なテキスト設定オプションを実装する必要があるだけです。残りは管理スタッフが行います。また、openssl s_clientなどを使用して、自分でテストすることもできます。

将来の脆弱性は管理上（たとえば、openssl ugpradeまたはJDKアップグレードを介して）処理できます。

HMACソリューションは、管理者にとってブラックボックスです。問題はプログラマーが解決する必要があります。

HTTP基本認証では、奇妙な仕事をしています。あなたstillはTLSを実装し、X509証明書を設定する必要があります（たとえば、クライアントはデフォルトのパブリックCA以外のものを信頼する可能性が最も高いです）、それでもまだそれを管理し、アップグレードします。しかし、あなたは半分の仕事をし、残りの半分は完全に異なるメカニズムを使用します。それは有効に見えますが、少し悪臭があります。

kaidentity · Answer

サーバー証明書の信頼チェーンを検証できない場合、または他のTLSセキュリティ問題が発生した場合にクライアントが接続を終了するという厳格なポリシーがある限り、あなたの仮定は正しいと思います。 TLSを信頼していれば、リプレイなどに対して安全です。

ただし、認証情報が危険にさらされた場合にどれだけ迅速に対応できるかという質問にいくつかの考えを費やすこともできます。ここで、共有キーへの切り替えは、クライアント証明書をCRLに配置する場合に比べて、はるかに簡単または難しい場合があります。これは、環境に完全に依存します。 TLSはネットワーク経由のデータ送信を適切に保護しますが、説明するオプションは、認証情報を取り消す際に、異なるレベルの快適性/信頼性/セキュリティを提供する可能性があります。