web-dev-qa-db-ja.com

TwitterのHTTPレスポンスとGoogleのHTTPレスポンス

私はHTTP応答フォーム https://Twitter.com および https://encrypted.google.com を見ていました。これら2つの応答には、セキュリティ定義に興味深い類似点と相違点があります。

TwitterとGoogleの両方に、セキュリティの目的でこれらのヘッダー要素が共通しています。

X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Server: *custom*
Expires: *in the past*
Cache-Control: private***

ただし、Twitterにはより広範なcache-control宣言があり、HSTSを使用しています。

cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
strict-transport-security: max-age=631138519

質問：

  1. HSTSを使用しない理由はありますか？ Googleは HSTSプリロード に依存しており、「通常の」WebアプリケーションはHSTSを有効にする必要がありますか？
  2. cache-controlの定義が異なるため、GoogleユーザーはTwitterユーザーよりもキャッシュ関連情報の開示を受けやすくなりますか？

完全を期すために、両方のサイトの完全なHTTPヘッダーを含めました。

https://encrypted.google.com からのHTTP応答：

HTTP/1.1 200 OK
Date: Sun, 06 Oct 2013 19:27:33 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=REMOVED
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alternate-Protocol: 443:quic
Content-Length: 100392

https://Twitter.com からのHTTP応答：

HTTP/1.1 200 OK
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Content-Length: 50221
content-type: text/html;charset=utf-8
date: Sun, 06 Oct 2013 19:33:08 GMT
expires: Tue, 31 Mar 1981 05:00:00 GMT
last-modified: Sun, 06 Oct 2013 19:33:08 GMT
ms: S
pragma: no-cache
server: tfe
set-cookie: _Twitter_sess=REMOVED
status: 200 OK
strict-transport-security: max-age=631138519
x-frame-options: SAMEORIGIN
x-transaction: 699d2669d76b27f5
x-ua-compatible: IE=10,chrome=1
x-xss-protection: 1; mode=block
tlshttphsts
16
rook

GoogleはHSTS施行を使用していません。プリロードでもヘッダーでもありません。 Chrome=のプリロードされたHSTSエントリは "OPPORTUNISTIC"に設定されています。これは基本的に "非強制"を意味しますが、MITMを防ぐために許可された証明書ハッシュのセットが含まれています。

Googleのhttpsへのリダイレクトは、ユーザーエージェントなどのブラウザー検出基準に依存します。彼らがチェックする基準は正確にはわかりませんが、たとえば Links を使用してgoogle.comを参照するとhttpsにリダイレクトされず、Chromeは（302で）httpsにリダイレクトされます。さらに、ドメイン上の多くのURLは、使用するブラウザに関係なくhttpsにリダイレクトされません。例： http://www.google.com/services /

SSLを必要としない理由はどこにも明示的に文書化されていませんが、おそらく記述が不十分であるとしても、そうすることで「物事が壊れる」可能性があるという事実と関係があります。現在の軌道は、すべてのGoogleをSSLに移行する方向を向いているようですが、それらは一度に1つずつ行っています。私の推測では、5年以内にHSTSの施行が見込まれます。

キャッシュ制御の違いは、Googleのホームページが静的であるのに対し、Twitterは常に新しいツイートで更新されているという事実を反映しています。 Googleでは、ブラウザが（プライベートに）検索ボックスのスプラッシュページを一定期間キャッシュすることを許可していますが、Twitterのすべての友人から最新の哲学的洞察を取得するには、Twitterをリロードする必要があります。

キャッシュ関連の情報開示については、私は何も知りません。 Googleホームページには個人情報が含まれていないため、HTTPS経由で配信される場合（その場合、上部にバーが表示されます）、開示の可能性が制限されます。

9
tylerl

私の知る限り、サイトがすでに他の手段を使用してTLSを実施している場合は、HSTSを使用しない理由はありません。非準拠のユーザーエージェントは単にヘッダーを無視するため、問題はありません。 HSTSはホストの負荷を軽減しますか？準拠ユーザーエージェントがhttps：// URIに直接移動するため、リダイレクトを提供し続ける必要がなくなりました。 HSTSプリローディングは多くのユーザーをカバーしますが、あなたが述べているようにすべてではありません。HSTSポリシーを発行しないのは少し奇妙です。

2番はごめんなさい。

3
Scott Helme