HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1
[RFC Home] [TEXT|PDF|PS|PDF|HTML] [Tracker] [IPR] [Errata] [Info page] Obsoleted by: 7230, 7231, 7232, 7233, 7234, 7235 DRAFT STANDARD Updated by: 2817, 5785, 6266, 6585 Errata ExistNetwork Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-L
curlでPOST送信する場合に注意しておいた方がいいこと(続・CentOS4系と5系のcurlの違い) - tokuhy’s fraction
以前のエントリで調査したcurlのバージョンの違いについてその後色々調べたので結果をまとめてみる。 おさらい CentOS4系 curl 7.12 CentOS5系 curl 7.15 サーバの移行を行ったところ、curlの通信に著しい遅延が発生した。具体的に言うと1回の通信で2秒かかる。 前回の対策としてはとりあえずCentOS4系のSRPMを持ってきてビルドし、バージョンをダウングレードして対応した。 調査 実は前回のエントリでは環境を正確に書ききっていなかったorz。 今回調査を続けた結果以下の環境でのみこの2秒遅延が起こることが判明した。 環境 curl 7.13以降 POSTデータが1024バイト以上 Poundサーバ経由したときのみ 前回は単純にcurlのバージョンのみが問題だと思って色々調べたんだけど、他のサーバのログや環境を比較しているうちに上記の条件が確認できた。 確認し
Real life usage of the X-Forwarded-Host header?
I've found some interesting reading on the X-Forwarded-* headers, including the Reverse Proxy Request Headers section in the Apache documentation, as well as the Wikipedia article on X-Forwarded-For. I understand that: X-Forwarded-For gives the address of the client which connected to the proxy X-Forwarded-Port gives the port the client connected to on the proxy (e.g. 80 or 443) X-Forwarded-Proto
HTTP 1.1のHost:ヘッダーの保持
HTTP 1.1リクエストには、多くの場合Host:ヘッダーが組み込まれており、クライアント・リクエストのホスト名が含まれます。これは、サーバーが単一のIPアドレスまたはインタフェースを使用して、複数のDNSホスト名に対するリクエストを受け入れることがあるためです。 Host:ヘッダーによって、クライアントがリクエストするサーバーが識別されます。リバース・プロキシがクライアントとターゲット・サーバーの間のHTTP 1.1リクエストをプロキシする際には、リクエスト時にHost:ヘッダーをアウトバウンド・リクエストに追加する必要があります。ターゲット・サーバーに送信されるHost:ヘッダーは、クライアントから受け取ったHost:ヘッダーと同じである必要があります。ターゲット・サーバーに直接アクセスする際のHost:ヘッダーであってはなりません。 アプリケーション・サーバーで、絶対パスの完全修飾
第18回 プロトコルを覚えよう［その2：HTTP編］ | gihyo.jp
今回は前回に続いて、プロトコルについてです。前回はSMTPでしたが、今回はおそらく最もメジャーなプロトコルであるといっても過言ではないHTTPについてです。 「デカいRFC」の読み方 まずHTTPにはバージョンとして1.0と1.1があります。実質、今はほぼ100％のサイトが1.1だと思って良いでしょう。 HTT1.1はRFC2068で提唱され、RFC2616にObsoleteされています。ですのでRFC2616（と、RFC2616をUpdateしているRFC2817とRFC5785）を読めば、HTTP1.1のことが把握できます。とはいってもでかいRFCなので、読むのはちょっと大変かもしれません。ただ、これくらいポピュラーなRFCになると日本語訳もたくさんあるので、原文と一緒に日本語訳も読むと、理解が速いかもしれません（訳だけ読むのはあまりオススメできません）。 また、RFCを読むとき（
HTTP 1.0 vs 1.1
Could somebody give me a brief overview of the differences between HTTP 1.0 and HTTP 1.1? I've spent some time with both of the RFCs, but haven't been able to pull out a lot of difference between them. Wikipedia says this: HTTP/1.1 (1997-1999) Current version; persistent connections enabled by default and works well with proxies. Also supports request pipelining, allowing multiple requests to be s
HTTPSにまつわる7つの誤解
HttpWatch is an HTTP viewer and debugger that integrates with IE and Firefox to provide seamless HTTP and HTTPS monitoring without leaving the browser window. ブラウザの通信内容を解析してグラフィカルに操作できるようにするアドオンHttpWatchのブログに、HTTPSにまつわる7つのよく誤解される内容が掲載されている。HTTPSに関する説明として参考になる。紹介されている誤解は次のとおり。 1. ログインページにだけHTTPSが必要 Firesheepの登場で注目されるようになったように、ログインページにだけHTTPSを使っている場合、パブリックWifiなどを使う場合にHTTPセッションハイジャックを受ける可能性がある。ログインペー
多くのサイトではHTTPよりもHTTPSのほうが速くアクセスできる？ | スラド IT
まず、参照されている元のコンテンツ「HTTP vs HTTPS Test」のテスト内容が錯誤に陥らせる内容なので、それはどうなの?と思います。 (誤) HTTPとHTTPSの比較 (正) HTTPとHTTPS+SPDYの比較 さて、タイトルが齎す錯誤より大きな、このテストの問題は、読み込まれる画像にExpiresヘッダーが入っており、二回目以降の読み込みは、IMS(If-Modified-Since)リクエスト、つまりダウンロードせず、変更確認だけで済む点です。 Firebugを開いた状態で、 https://www.httpvshttps.com/ [httpvshttps.com] を開いてみてください。 もし、既にブラウジングしたことがあるのであれば、Ctrl+F5で、スーパーリロードをさせて、再度コンテンツをダウンロードさせます。 その秒数を確認して下さい。 では、次に、http:
RFC 7386: JSON Merge Patch
Internet Engineering Task Force (IETF) P. Hoffman Request for Comments: 7386 VPN Consortium Category: Standards Track J. Snell ISSN: 2070-1721 October 2014 JSON Merge Patch Abstract This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target r
HTTP/2 入門
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
RFC2616 is Dead
Hi, I’m Mark Nottingham. I usually write here about the Web, protocol design, HTTP, and Internet governance. Find out more. Comments? Let's talk on Mastodon. @mnot@techpolicy.social Saturday, 7 June 2014 HTTP Standards Web Don’t use RFC2616. Delete it from your hard drives, bookmarks, and burn (or responsibly recycle) any copies that are printed out. Since 1999, it has served as the definition of
Please admit defeat (was: Our Schedule) from Poul-Henning Kamp on 2014-05-26 (ietf-http-wg@w3.org from April to June 2014)
From: Poul-Henning Kamp <phk@phk.freebsd.dk> Date: Mon, 26 May 2014 06:34:25 +0000 To: HTTP Working Group <ietf-http-wg@w3.org> Message-ID: <1282.1401086065@critter.freebsd.dk> In message <315A1736-1C33-403D-AC5F-6E488B880FAE@mnot.net>, Mark Nottingham wri tes: >The overwhelming preference expressed in the WG so far has been to work >to a tight schedule. HTTP/3 has already been discussed a bit, be
Developer Calls For HTTP 2.0 To Be Thrown Out - Phoronix
Developer Calls For HTTP 2.0 To Be Thrown Out Written by Michael Larabel in Free Software on 26 May 2014 at 08:35 PM EDT. 7 Comments Open-source developer Poul-Henning Kamp is pushing for the HTTP Working Group to toss out their current work on the HTTP 2.0 standard and to start over. The Danish developer is calling for the HTTP Working Group to abandon their current work on "HTTP/2", admit defeat
Background of HTTP/2.0 // Speaker Deck
All slide content and descriptions are owned by their creators.
Twilio: HTTPリクエストを磨く - ワザノバ | wazanova.jp
https://www.twilio.com/engineering/2013/11/04/http-client スマホアプリ <-> サーバ間や、サーバ <-> 3rd partyツール間でHTTPリクエストを送ることは一般化してますが、その性能をあげるための工夫を、Twilioがエンジニアブログで紹介してます。 サーバの様々なHTTPポートに接続し、エラーパターンをシミュレートして、クライアント側が適切にハンドリングしているかどうか確認するライブラリが、Githubで公開されてます。 1) コネクションエラー サーバが遠隔にあるマシンに接続できない場合、HTTPリクエストが完了しないのでConnectionErrorが返ってくるだけで具体的な理由はわからない。 ここでまずできることは、タイムアウトの設定。connect () は通常即座に完了するか、失敗するかのどちらか。Twilio
GoogleのIlya Grigorikが語るHTTP 2.0の方向性 [Realtime Conf 2013] - ワザノバ | wazanova.jp
[Video] http://www.youtube.com/watch?v=E9FxNzv1Tr8 [Slide] https://docs.google.com/presentation/d/1eqae3OBCxwWswOsaWMAWRpqnmrVVrAfPQclfSqPkXrA/present#slide=id.p19 GoogleのIlya GrigorikがHTTP 2.0の方向性についてRealtime Conf 2013で語ってます。 ちなみに、SPDYとHTML2.0の概要については、こちらのIIJのブログもよくまとまっています。 HTTP 0.9は、確か1993年のはじめ。GET / の後に URL を付けてサーバに送るとリスポンスが返ってくる。ヘッダもメタデータもない1行のプロトコルで現代のウェブのはじまり。nginxとApacheではまだサポートしてるはず。 1997
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TCP.next
第43回HTML5とか勉強会 最新webプロトコル傾向と対策
