HTTPS経由の認証はアプリケーションを遅くしますか？

WebアプリケーションとRESTful Webサービスを構築しています。

Webサービスへのリクエストを認証する最良の方法に関するさまざまな記事を読んでいます。

私にとって最良のオプションは、HTTP基本認証を使用することです。私が読んだほとんどすべての記事は、認証はSSLまたは同等のもので暗号化されるべきだと言っています。

私はこれが何を含むのか完全にはわかりません。これは、Webサービス全体が安全なサーバー上にある必要があるということですか？これは遅くなりますか？

まず、SSL（HTTPS）およびHTTP認証の仕組みを理解してください。

通常のHTTP認証方法（ダイジェスト、基本、およびHTTP上に実装できるすべてのフォーム+ Cookieベースの認証スキーム）は、認証情報を多かれ少なかれクリアテキストで送信するため、それ自体では安全ではありません。データがPOSTフィールドまたはヘッダーにあるかどうか、およびbase64エンコードが適用されるかどうかは、この点ではまったく関係ありません。パスワードは、ネットワークトラフィックにアクセスできるすべてのユーザーに明確に表示されます。これは、信頼できないチャネルを介したHTTP認証は価値がないことを意味します。攻撃者がパスワードを読み取るのに必要なのは、ネットワークスニッフィングです。

SSLは、本質的に安全でないチャネル上に安全な通信チャネルを実装します。これは大まかに次のように機能します。

1. サーバーは署名付き証明書を送信します
2. クライアントは、既知の適切な署名キーのリストに対して証明書を検証します。証明書の署名はチェーン化できるため、各ノードは「私に署名する署名が良ければ、私もそうだ」と言うことができますが、最終的に、チェーンはクライアント上で事前設定された少数の信頼できる機関の1つに解決する必要があります。
3. クライアントはサーバーの公開暗号化キーを使用して共有シークレットを送信します
4. サーバーは秘密鍵を使用して共有秘密を解読します（正当なサーバーのみが秘密鍵を持っているため、他のサーバーは共有秘密を解読できません）
5. クライアントは、共有シークレットを使用して暗号化された実際の要求データを送信します
6. サーバーは要求データを解読し、暗号化された応答を送信します
7. クライアントは応答を解読し、ユーザーに提示します。

ここでいくつかの重要な点に注意してください。

• 証明書チェーンを使用すると、クライアントは、通信しているサーバーが、リクエストを傍受する誰かではなく、実際のサーバーであることを確認できます。これが、実際のSSL証明書を購入する必要がある理由であり、無効な証明書、期限切れの証明書、または間違った証明書を使用するサイトにアクセスすると、ブラウザーが恐ろしい警告を投げる理由です。間違った人と話しています。
• シークレットの交換に使用されるパブリック/プライベート暗号化により、正常な通信がこの特定のクライアントとサーバーのペア間でのみ機能するようになります。スニッフィングされたネットワークパケットは暗号化され、データを取得するにはサーバーのプライベートキーが必要になります。
• 対称暗号化は、秘密鍵/公開鍵暗号化よりもパフォーマンスオーバーヘッドがはるかに低いため、要求の大部分に使用されます。ただし、キー（共有シークレット）は秘密/公開キー暗号化を使用して交換されます。これは、それが安全な方法でそれを行う唯一の方法であるためです（宅配サービスなどの別のチャネルで転送する場合を除く）。

明らかに、いくらかのオーバーヘッドが含まれますが、それはあなたが考えるほど悪くはありません-絶対に大量のトラフィックを準備している場合を除き、ほとんどの場合「より多くのハードウェアを投げる」が適切な応答である規模ですGoogleやFacebookなど）。通常の状況、つまり一般的なWebアプリケーションの使用状況では、SSLオーバーヘッドは無視できるため、機密データを入手したらすぐに、リソースを含むすべてをSSLで実行することをお勧めします。SSLは、HTTPトラフィックを保護する唯一の実行可能な方法でもあります。他の方法は単純に標準化されていないため広くサポートされておらず、これらを自分で実装することは絶対に望まないでしょう。

TL; DR：はい、SSL +基本認証は良い考えです。はい、安全なサーバー（および有効な証明書）が必要です。はい、少し遅くなります今。

HTTPS（SSL）はユーザー認証ではありません。2つのエンドポイント間の暗号化を提供するだけです。

しかし、はい、そこからわずかなオーバーヘッドがあります（ただし、計画/ハードウェアの変更を保証するには十分ではありません）。こちらをご覧ください：

/programming/548029/how-much-overhead-does-ssl-impose

HTTP基本認証では、ユーザーが提供するユーザー名とパスワードは、サーバーへのすべての要求とと​​もに送信されます。これは、サイトの必ずしも安全である必要のない領域であってもプレーンテキストであることを意味します。明らかに、ここでSSLを使用してユーザーを安全に保つ必要があります。

理論的には、Cookie認証を使用して、ログインページ（ユーザー名とパスワードが送信される）にのみSSLを配置できます。Cookieがリプレイ攻撃に対してきちんと安全で安全であれば、攻撃者はそれを取得できたとしても何もできません。

基本認証では、httpリクエストのヘッダーにユーザー名とパスワードを設定します。SSLまたは同等のものを使用しない場合、そのユーザー名とパスワードはプレーンテキストで送信され、盗むのは簡単です。

現在、ほとんどのWebサーバーはデフォルトでHTTPSをサポートしていますが、すべての呼び出しにオーバーヘッドが追加されますが、オーバーヘッドは最小限です。

他のエンドポイントではなく、一部のエンドポイントを保護できます（つまり、他の呼び出しに使用できるトークンを生成する認証エンドポイントを使用できます）。はるかに安全なので、サービス全体にSSLを強くお勧めします。（他に何もなければ、機密データの傍受を停止します）

ジェフ・アトウッドは、完全な暗号化が道であるかどうかについて、少し前に短いブログ投稿を書きました。彼はいくつかの実際の例を説明し、パフォーマンスの考慮事項についてもいくつかの行を持っています。

また、彼はGmailのケーススタディに関するこの記事を参照し、次のように引用しています。

今年（2010年）1月、GmailはデフォルトですべてにHTTPSを使用するように切り替えました。以前はオプションとして導入されていましたが、現在ではすべてのユーザーが常にHTTPSを使用してブラウザとGoogleの間でメールを保護しています。これを行うには、追加のマシンや特別なハードウェアを配置する必要がありませんでした。運用フロントエンドマシンでは、SSL / TLSがCPU負荷の1％未満、接続あたりのメモリが10KB未満、ネットワークオーバーヘッドが2％未満です。多くの人々は、SSLには多くのCPU時間を要すると信じており、上記の数値（初めて公開）がそれを払拭するのに役立つことを願っています。

彼はまた、ブラウザによるHTTPSを介したページのクライアント側キャッシュの当時の改良についても言及しています。

これにもかかわらず、彼は、他のペナルティがあり、それらのほとんどがパフォーマンスではなく実装コストであると指摘しています：

• ソフトウェアの品質を維持しながら、すでに忙しいチームに複雑さを追加し、
• プロキシキャッシュは適切に設定するのがはるかに難しく、コードの変更も必要です。
• さまざまなソースからのコンテンツのマッシュアップに対して適切なセキュリティを確保することは困難です。
• ローエンドモバイルデバイスは暗号化に苦労する場合があります。

独自のセッション処理を行わないHTTP基本認証では、おそらくクロスサイトリクエストフォージェリ攻撃にさらされることになります。おそらく、独自のセッション処理と組み合わせれば使用できますが、クリーンな「ログアウト」機能を提供するのに苦労するかもしれません。

認証に使用するものに関係なく、HTTPSを使用して接続を暗号化する必要があります（Webアプリケーションが制御された安全なネットワークでのみアクセスされる場合を除く）。それは少し遅くなるかもしれません（接続の確立は高価ですが、ブラウザはしばらく接続を維持する傾向があります）が、安全なアプリケーションが必要な場合は、とにかくそれを避けることができないので、あなたは本当に必要ありませんそれを心配する。

注：「タイトルで言及した」「HTTPS認証」は誤解を招く可能性があります-SSLクライアント証明書認証を指す場合があります。これは質問のテキストとはほとんど関係がなく、独自の利点と問題があります。あなたはおそらくそれに触れたくないでしょう。

基本認証をどのように達成しますか？
ハードコードされたユーザー名/パスワードであり、それを行うためにWebサーバーの組み込み機能を使用している場合、ほとんど影響はありません。データベースなどでおかしなことをするのをやめた場合、影響があるかもしれません。

他の人がここで述べたように、SSLと余分なヘッダーの送信は技術的に速度を遅くしますが、決して重要ではありません。