HTTPSを介した認証でアプリケーションが遅くなりますか？
WebアプリケーションとRESTful Webサービスを構築しています。
Webサービスへのリクエストを認証するための最良の方法に関するさまざまな記事を読んでいます。
私にとって最良のオプションは、HTTP基本認証を使用することです。読んだほとんどすべての記事は、認証はSSLまたは同等のものを介して暗号化されるべきであると述べています。
私はこれが何を伴うのか完全にはわかりません。これは、私のWebサービス全体が安全なサーバー上になければならないことを意味しますか？これは遅くなりますか？
まず、SSL（HTTPS）とHTTP認証のしくみを理解してください。
通常のHTTP認証メソッド（ダイジェスト、ベーシック、およびHTTPに実装できるフォームとCookieベースの認証スキーム）は、認証情報を多かれ少なかれクリアテキストで送信するため、それ自体では安全ではありません。データがPOST=フィールドまたはヘッダーにあるかどうか、およびbase64-encodingが適用されているかどうかは、この点ではまったく問題ではありません。ネットワークトラフィックにアクセスできるすべての人がパスワードを明確に見ることができます。これは、信頼されていないチャネルを介したHTTP認証は役に立たないことを意味します。攻撃者がパスワードを読み取るために必要なのは、少しのネットワーク盗聴だけです。
[〜＃〜] ssl [〜＃〜]は、本質的に安全でないチャネル上に安全な通信チャネルを実装します。これは、大まかに次のように機能します。
- サーバーが署名済み証明書を送信する
- クライアントは、既知の適切な署名鍵のリストに対して証明書を検証します。証明書の署名はチェーン化できるため、各ノードは「私に署名する署名が適切であれば、私もそうだ」と言いますが、最終的には、チェーンはクライアントで事前構成された少数の信頼できる機関の1つに解決する必要があります。
- クライアントはサーバーの公開暗号鍵を使用して共有秘密を送信します
- サーバーは秘密鍵を使用して共有秘密を復号化します（正当なサーバーだけが秘密鍵を持っているため、他のサーバーは共有秘密を復号化できません）
- クライアントは、共有シークレットを使用して暗号化された実際の要求データを送信します
- サーバーは要求データを復号化し、暗号化された応答を送信します
- クライアントは応答を復号化してユーザーに提示します。
ここでいくつかの重要な点に注意してください：
- 証明書チェーンを使用すると、クライアントは、通信先のサーバーが本物のサーバーであることを確認できます。リクエストを傍受するユーザーではありません。これが、実際のSSL証明書を購入する必要がある理由であり、無効、期限切れ、またはその他の不正な証明書を使用するサイトにアクセスすると、ブラウザーが恐ろしい警告をスローする理由です：世界のすべての暗号化は、間違った人と話しています。
- シークレットの交換に使用されるパブリック/プライベート暗号化により、正常な通信がこの特定のクライアントとサーバー間でのみ機能することが保証されます。スニッフィングされたネットワークパケットは暗号化され、データを取得するにはサーバーのプライベートキーが必要になります。
- 対称暗号化は、秘密鍵/公開鍵暗号化よりもパフォーマンスのオーバーヘッドがはるかに低いため、要求の大部分に使用されます。キー（共有シークレット）は、秘密/公開キー暗号化を使用して交換されます。これは、安全な方法でそれを行う唯一の方法だからです（宅配便などの別のチャネルで転送する場合を除く）。
明らかに、それに伴うオーバーヘッドがいくつかありますが、あなたが考えるほど悪くはありません-絶対に大量のトラフィックを準備しない限り、「ハードウェアを追加する」ことが適切な応答であるスケールがほとんどです（ GoogleやFacebookだと思う）。通常の状況、つまり一般的なWebアプリケーションの使用状況では、SSLのオーバーヘッドは無視できる程度であるため、機密データがすべてあるとすぐに、リソースを含めてすべてをSSLで実行するのが最善です。 SSLは、HTTPトラフィックを保護するための唯一の実行可能な方法でもあります。他のメソッドは標準化されていないため、広くサポートされていません。また、これらのことを自分で実装することは絶対に望まないでしょう。正直なところ、間違ってしまうのは簡単すぎるためです。
TL; DR：はい、SSL +基本認証は良い考えです、はい、安全なサーバーが必要です（そして有効な証明書）、はい、少し遅くなりますが、いいえ、これは現在心配する必要はありません。
HTTPS（SSL）はユーザー認証ではありません。 2つのエンドポイント間の暗号化を提供するだけです。
しかし、そうです、そこにはわずかなオーバーヘッドがあります（ただし、計画/ハードウェアの変更を保証するのに十分ではありません）。こちらをご覧ください：
https://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
HTTP基本認証では、ユーザーが提供するユーザー名とパスワードは、すべての要求と共にサーバーに送信されます。これは、必ずしも安全である必要のないサイトの領域であっても、プレーンテキストであることを意味します。明らかに、ユーザーを安全に保つためにここでSSLが必要になります。
理論的には、Cookie認証を使用して、ログインページ（ユーザー名とパスワードが送信される場所）にのみSSLを配置できます。 Cookieがきちんと安全で、リプレイ攻撃に対して安全である場合、攻撃者がCookieを取得できたとしても、攻撃者はそれらを使用して何もできません。
基本認証では、httpリクエストのヘッダーにユーザー名とパスワードを設定します。 SSLまたは同等のものを使用しない場合、そのユーザー名とパスワードはプレーンテキストで送信され、だれでも簡単に盗むことができます。
現在、ほとんどのWebサーバーは標準でHTTPSをサポートしていますが、すべての呼び出しにオーバーヘッドを追加しますが、オーバーヘッドは最小限です。
一部のエンドポイントを保護し、他のエンドポイントを保護することはできません（つまり、他の呼び出しに使用できるトークンを生成する認証エンドポイントがあります）。 SSLの方がはるかに安全ですが、サービス全体にSSLを強くお勧めします。 （他に何もない場合は、機密データの傍受を停止します）
Jeff Atwoodは、完全暗号化が可能かどうかについて、それほど前に 簡単なブログ投稿 を書いています。彼はいくつかの実際の例を説明し、パフォーマンスの考慮事項についても数行あります。
また、彼はGmailのケーススタディに関する this 記事を参照し、次のように引用しています。
今年（2010年）1月に、GmailはデフォルトですべてにHTTPSを使用するように切り替えました。以前はオプションとして導入されていましたが、現在ではすべてのユーザーがHTTPSを使用して、ブラウザーとGoogleの間で常に電子メールを保護しています。これを行うために、追加のマシンや特別なハードウェアを配備する必要はありませんでした。本番環境のフロントエンドマシンでは、SSL/TLSはCPU負荷の1％未満、接続あたり10KB未満のメモリ、およびネットワークオーバーヘッドの2％未満を占めます。多くの人々は、SSLはCPU時間を多く消費すると信じており、上記の数値（初めて公開）がそれを払拭するのに役立つことを願っています。
彼はまた ブラウザ によるHTTPSを介したページのクライアント側キャッシングの最近のいくつかの改善について言及しています。
これにもかかわらず、彼は指摘し、他のペナルティがあり、それらのほとんどはパフォーマンスではなく実装コストです：
- ソフトウェアの品質を維持しながら、すでに忙しいチームにさらに複雑さを加え、
- プロキシキャッシングは適切に構成するのがはるかに難しく、コードの変更も必要です。
- さまざまなソースからのコンテンツのマッシュアップに対してセキュリティを確保するのは困難です。
- ローエンドのモバイルデバイスは暗号化に苦労する可能性があります。
基本認証をどのように達成しますか？
ハードコードされたユーザー名/パスワードであり、Webサーバーの組み込み機能を使用して実行している場合、影響はほとんどありません。データベースなどでクレイジーなことをしているのであれば、そうです、影響があるかもしれません。
他の人がここで述べたように、SSLと追加のヘッダーを送信すると、技術的に速度が遅くなりますが、意味がありません。
独自のセッション処理を行わないHTTP基本認証では、おそらくクロスサイトリクエストフォージェリ攻撃にさらされることになります。独自のセッション処理と組み合わせれば、おそらくそれを使用できますが、クリーンな「ログアウト」機能を提供するのに問題があるかもしれません。
認証に何を使用する場合でも、接続を暗号化するにはHTTPSを使用する必要があります（Webアプリケーションが制御された安全なネットワークでのみアクセスされる場合を除く）。 少し遅くなる可能性があります（接続の確立にはコストがかかりますが、ブラウザはしばらくの間接続を維持する傾向があります）ただし、安全なアプリケーションが必要な場合は、とにかくそれを避けるので、あなたは本当にそれを心配する必要はありません。
注：「タイトルに記載した「HTTPS認証」は誤解を招く可能性があります。SSLクライアント証明書認証を指す場合があります。これは、質問のテキストとはほとんど関係がなく、独自の利点と問題があります。あなたはおそらくそれに触れたくないでしょう。