1

この非常に興味深い記事「標準化された REST 認証の原則」を読みましたが、SSL を使用している場合でも REST クエリに署名する必要があるのはなぜでしょうか。私の理解では、REST クエリに署名することで、サーバーは信頼できるクライアントからのリクエストを確実に受け取ることができます。

そうは言っても、SSLが中間者攻撃からも保護することを考えると、署名は本当に必要なのでしょうか?

4

2 に答える 2

1

HTTPS に関するウィキペディアの記事に記載されているとおり:

[...] HTTPS は、通信している Web サイトと関連する Web サーバーの認証を提供し、中間者攻撃から保護します。さらに、クライアントとサーバー間の通信の双方向暗号化を提供し、通信内容の盗聴や改ざん、および/または偽造から保護します。実際には、これにより、ユーザーとサイト間の通信内容が読み取られたり、偽造されたりすることがないように保証するだけでなく、(なりすましではなく) 通信しようとしている Web サイトと正確に通信しているという合理的な保証が提供されます。第三者による。[...]

これが、クライアントが要求が適切な宛先に送信されることを「確信」できるように、HTTPS が必要な理由です。リンクした記事には、次のようにも書かれています。

サーバーの SSL 証明書を検証していない場合、誰が REST クエリを受信して​​いるかわかりません。

ただし、相互認証を実行するためにクライアントから証明書を要求するようにサーバーを構成しない限り、通常、HTTPS はクライアントを認証しません。リンクした投稿のコメントを読むと、これについて言及している人々が表示されます。

https を使用する場合は、https を完全に使用して、クライアント側の証明書も要求してみませんか? 次に、クライアントとサーバーが接続層で認証され、認証を URI レベルに持ち込む必要がないため、完全な RESTful 認証方法を取得します。

ただし、クライアント側の証明書を使用する HTTPS はより高価で複雑なため、ほとんどの API プロバイダーは「通常の」HTTPS を保持してサーバーを識別し、より軽いメカニズムである API キーを使用してクライアントを識別します。API キーは基本的に、公開されている名前 (「Johnny」など) と非公開の秘密鍵 (ランダムに生成された長い文字列など) で構成されます。

サーバーにリクエストを送信するときは、URL に「Johnny」という名前を含めて、サーバーがリクエストの送信者を認識できるようにします。しかし、サーバーはあなたが「ジョニー」であることを盲目的に信頼するだけではありません。秘密鍵は秘密であるため、本物の「ジョニー」だけが知っている秘密鍵でリクエストに署名することによって証明する必要があります。

于 2013-10-25T21:07:54.143 に答える
1

デジタル署名には、否認防止などの法的な意味があり、これはあらゆる価値のある取引で要求される必要があります。認証だけの問題ではありません。実際の取引のデジタル署名は、法廷での「この会話は相互認証を使用して SSL 経由で行われたため、被告人であるに違いない」よりもはるかに強力な証拠となります。

于 2013-10-26T00:04:43.277 に答える