Kazuho's Weblog: 次世代プロトコル（QUIC etc.）のセキュリティとプライバシー @ #builderscon
９月６日より開催中の builderscon 2018 において、登壇の機会をいただき、インターネットのトランスポート層プロトコルについてセキュリティやプライバシーに関わる設計がどのように進めてられているか、TLS と QUIC を中心に発表しました。 QUIC のハンドシェイクプロトコルとパケット番号暗号化、TLS の Encrypted SNI 拡張は、いずれも僕が提案した機能あるいは方式が採用される予定のものなので、背景にある動機や意義を含め、整理して発表する機会をもらえたことをありがたく感じています。 聴講いただいた方々、また、スライドをご覧になる方々と、次世代プロトコルの暗号応用の手法のみならず意義を含め共有し、理解と議論を深めることができれば、これに勝る喜びはありません。 PS. QUIC のハンドシェイクプロトコルと Encrypted SNI 拡張については、以下のブログ記
なぜ今、新しいHTTPサーバが必要なのか - H2O について勉強会で話したこと
先月末の話になりますが、SAPジャパンさんを会場に開催されたデータ転送ミドルウェア勉強会で、私が中心になって開発しているHTTPサーバ「H2O」について話す機会をいただき、登壇してきました。 以下は当日使用したスライドです。なぜ今H2Oを開発しているのか、その背景にある現状認識と将来の方針について、日本語で説明してあるので、興味ある方はご覧ください。 発表の機会をくださった@repeatedlyさんと@frsyukiさん、会場を提供してくださったSAPジャパンさん、ありがとうございました。 H2Oの開発は順調に進んでおり、HTTP/2サーバプッシュへの対応も完了し、まもなく次のバージョンがリリースできるかと思います。今後ともよろしくお願いいたします。
HTTP/2がIESGのラストコール。早ければ数週間でRFCのProposed Standardに
次バージョンのHTTPとしてIETFで標準化作業が進んでいるHTTP/2の仕様が、HTTPbisワーキンググループのラストコールを経てIETFのステアリンググループであるIESGによって受諾され、IESGのラストコールへと移行したようです。 Last Call: (Hypertext Transfer Protocol version 2) to Proposed Standard from The IESG on 2014-12-31 ([email protected] from October to December 2014) W3Cのメーリングリストに先週12月31日、IESGから「Last Call: (Hypertext Transfer Protocol version 2) to Proposed Standard」というメッセージが投稿されました。 このメールには次のよ
サイトパフォーマンス: 1000msを目指す取組み - ワザノバ | wazanova
Guardian誌のPatrick HamannがLondon Web Performance Meetupで、モバイルサイトのパフォーマンス向上の取組みについて講演しています。 まずは、Web Performance TodayのeCommerceに関する調査で、 ユーザの期待するページ読込み時間は、2000年の8秒から、2012年には2秒を切るレベルまで下がってきている。 ことを挙げ、1秒以下を達成するには、 3Gネットワークでは、DNS Lookup / TCP Connection / HTTP Request & Responseで 600ms （Guardianのある英国ではそれ以上）はかかる。残りの400msで、Server Response TimeとClient-side Renderingを最適化する必要がある。 というGoogleのPageInsightの分析結果を紹
なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT
『WindowsXPからの通信をProxyサーバでブロック その1 (squid)』
ぼぶろぐ以前は、あいらぶLinux♪というタイトルでしたが、 最近はLinux以外のことも書いているので、タイトルを変更しました。 ぼぶちゃんのぶろぐでぼぶろぐです。 WindowsXPのサポートが切れるまであと1ヶ月ほどとなりました。 - Windows XP および、Office 2003 のサポート終了についてのご案内 https://www.microsoft.com/ja-jp/windows/lifecycle/sp3eos.aspx ですが、おそらくまだ職場でWindowsXPを使っている人はいると思います。 Windows7などに買い替えるのが最もよい方法とは思いますが、 できるだけセキュリティリスクを減らすために、Proxyサーバで制御をかけます。 (例えば、野良XPがいきなり社内LANにつながった時など) きっかけは某セキュリティスペシャリストの方にWindowsXPか
HTTP/2.0のALPN利用に伴うSSL負荷分散装置の不具合にご注意下さい - ぼちぼち日記
1. はじめに、 ただ今IETF-88@バンクーバーの開催が真っただ中です。スノーデン事件の余波もあり、インターネット技術（特にセキュリティ関連）の議論は熱くなっています。 ちょうど今朝未明（バンクバーでは11/5朝）に HTTP/2.0の標準化を進める httpbis ワーキンググループとセキュリティエリアの合同セッションが開催されました。合同セッションでは、ヘッダ圧縮技術(HPACK)のセキュリティや、HTTP接続(HTTPSではない）で通信の暗号化を行ったらどうか、といった興味深い議論が行われました。このうち将来HTTP/2.0の展開に重要な ALPN(Application Layer Protocol Negotiation) は、このミーティングで最終的な仕様を確定させる段階での議論でした。議論の中で、ALPNの導入によってブラウザから既存の実サービスへの接続に(少なからず)影
HTTP/1.1 の Transfer-Encoding: chunked をビジュアライズするツール書いてみた - blog.nomadscafe.jp
Chunked Transferとは 一般にHTTP KeepAliveを利用するには、レスポンスのボディがどこで終わり、次のレスポンスがどこから始まるかをクライアントが知る必要があります、そのためHTTP/1.0ではKeepAliveを行う為にボディの長さをContent-Lengthをヘッダに入れなければなりませんでしたが、サイズを測るためにデータをすべてメモリに読み込むなどの処理が必要になり、レスポンス開始までの時間もかかります。（一般的なアプリケーションにはあまり影響がありませんが） そこでHTTP/1.1ではChunked Transferという仕組みが入っていて、事前に全体のレスポンスの長さが分からなくても、chunk=固まり毎にサイズを記してレスポンスを返していき、最後に0byteと送信することで、コンテンツの切れ目がわかるようになっています。 HTTP/1.1 200 OK
オリジン間リソース共有 (CORS) - HTTP | MDN
HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection サイトの安全化 HTTP Observatory HTTP アクセス制御 (CORS) HTTP 認証 HTTP キャッシュ HTTP の圧縮 HTT
SPDY Protocol - Draft 3 日本語訳
この文書は「SPDY Protocol - Draft 3」の日本語訳です。 原文の最新版 は、この日本語訳が参照した版から更新されている可能性があります。 この日本語訳は参考情報であり、正式な文書ではないことに注意してください。また、翻訳において生じた誤りが含まれる可能性があるため、必ず原文もあわせて参照することを推奨します。 公開日: 2013-02-11 更新日: 2013-08-21 翻訳者: Moto Ishizawa <[email protected]> 翻訳協力: Shigeki Ohtsu 1. 概要 HTTP 実装のボトルネックの1つに、並列処理のために複数コネクションを必要とすることがあります。これは、接続確立のために追加で発生するラウンドトリップや、スロースタートによる遅延、そして1つのサーバーに対して複数の接続をおこなうことを避けるためのクライアントによるコネクシ
HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏:Geekなぺーじ
TOP > ブログ > HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏 昨年後半、IETFのhttpbisワーキンググループでHTTP 2.0標準化に向けた動きが開始されました。 そのhttpbisワーキンググループのチェアであるMark Nottingham氏(Akamai)に対するインタビューの機会を頂けました。 Mark Nottingham氏は、HTTP 2.0標準化の舵取りをしている方です。 非常に興味深い最新状況を伺えたので、可能な限り生に近い情報をお届けします(日本語に翻訳する前の英語版はこちら)。 お楽しみ頂ければ幸いです。 Q: HTTP 2.0標準化開始の経緯を教えて下さい HTTP 1.1とHTTP 1.0には、よく知られた制限があります。 特に顕著なのが、ひとつのコネクションでリクエストを出してレス
Outbound Port 80 blocking のご提案
Outbound Port 80 blocking ⽵竹 <takesako@shibuya.pm.org> http://www.janog.gr.jp/meeting/janog31/program/OP80B.html [ ] � MacBook Air ⾏行行 � [ ] � ⾏行行 ⼈人 � [ ] � ⼊入 � [ ] � ⼈人 � [ ] � ⽤用 Google Wireshark ⾯面⼈人 Firesheep � 2010 10⽉月 �Firefox � �Eric Butler⽒氏 � LAN facebook Twitter ⽂文 HTTP Cookie � �PoC⽰示 Firesheep ⾯面 Eric Butler⽒氏⽤用 Firesheep � Web �Amazon.com CNET dropbox Evernote Facebook Flickr Gith
500,000 requests/sec – Modern HTTP servers are fast
A modern HTTP server running on somewhat recent hardware is capable of servicing a huge number of requests with very low latency. Here’s a plot showing requests per second vs. number of concurrent connections for the default index.html page included with nginx 1.0.14. With this particular hardware & software combination the server quickly reaches over 500,000 requests/sec and sustains that with gr
Apache HTTP Serverの脆弱性を突く「Apache Killer」――パッチは48時間以内にリリース予定 | OSDN Magazine
Apache HTTP Serverの開発チームは8月24日、同Webサーバーの脆弱性を突くDDoS攻撃ツール「Apache Killer」が出回っていると警告した。該当するApacheは1.3系および2系の全バージョン。パッチ発行までユーザーはおのおので対応を講じるよう呼びかけている。 Apache KillerはFull-disclosureというメーリングリストで先週公開された。問題となっているのは「Range header DoS」と呼ばれる脆弱性。リモートから多数のRange指定を含むリクエストを送ることで、ターゲットシステムのメモリとCPUを消費させるというもの。バージョン1.3系および2系のすべてがこの脆弱性を持つという。デフォルト設定ではこの攻撃に対し脆弱で、現在この脆弱性を修正するパッチやリリースはない。Apache Killerではこの脆弱性が悪用され、多数のリクエスト
HTTPで疎通やレイテンシを確認する「httping」 - 元RX-7乗りの適当な日々
少し前に、某所のサーバ(自分たちで管理)で、通常時は問題ないのだけど、時々HTTPレスポンスで数秒かかる現象が見受けられたので、再現させるときに目視確認でひたすらHTTPリクエストが送れてレイテンシが確認できる「httping」を利用しました。 httpingは、所謂"ping"のHTTP版。HTTPリクエストでポーリングしてくれるコマンドです。ICMPは受け付けないけどHTTPはOK、そんなサーバにも監視などで使えます。 インストール Ubuntuでは、aptでインストールできました。簡単。 $ sudo apt-get install httpingこれだけです。 簡単な使い方 $ httping (URLまたはIPアドレス)で、実行可能です。以下、実行例。 $ httping http://xxx.xxx.xxx.xxx/ PING xxx.xxx.xxx.xxx:80 (http:
Life beyond HTTP 1.1: Google's SPDY - igvita.com
By Ilya Grigorik on April 07, 2011 Tim Berners-Lee rightfully deserves all the credit for his early work around URI, HTTP and HTML. His efforts ultimately led to the official HTTP 1.0 (RFC 1945) specification in 1996, the HTTP 1.1 proposal (RFC 2068) in 1997 and consequently the official HTTP 1.1 spec (RFC 2616) in 1999. The web as we know it wouldn't exist without these protocols. However, more t
Charles Web Debugging Proxy • HTTP Monitor / HTTP Proxy / HTTPS & SSL Proxy / Reverse Proxy
Web Debugging Proxy Application for Windows, Mac OS and Linux Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet. This includes requests, responses and the HTTP headers (which contain the cookies and caching information). Read More Recent Developments For discussion on the latest ch
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2 入門
【HTTP2.0最新動向】第1回：HTTP/2.0の策定、ついに始まる 
WebSocketでリアルタイム通信
