[PDF] HEIST: HTTP Encrypted Information can be Stolen through TCP-windows
HTTP! Encrypted! Information can be! Stolen through! TCP-windows by! Mathy Vanhoef & Tom Van Goethem HEIST Agenda • Technical background! • Same-Origin Policy! • Compression-based attacks! • SSL/TLS & TCP! • Nitty gritty HEIST details! • Demo! • Countermeasures 2 HEIST Same-Origin Policy 3 Mr. Sniffles https://bunnehbank.com GET /vault HEIST Same-Origin Policy 3 Mr. Sniffles https://bunnehbank.com
HTTPS でも Full URL が漏れる？OAuth の code も漏れるんじゃね？？ - OAuth.jp
なんですかこれは！ New attack bypasses HTTPS protection on Macs, Windows, and Linux DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって？ Web Proxy Autodiscovery ですって？ チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
Let's EncryptとnginxでHTTP/2サーバを立てる - pixiv inside [archive]
この記事は ピクシブ株式会社 Advent Calendar 2015 10日目の記事です。 qiita.com こんにちは。Androidアプリエンジニアのいとおちゃんです。 高校生の頃からアルバイトとしてピクシブに入社してから4年目になりました。昨年は若手アルバイトと名乗っていましたが、気づいたらもう大学生です。最近はpixivマンガアプリの開発をしています。 今回はAndroidアプリ開発の話ではなく、個人的に最もアツいと感じているLet's Encryptを使ってnginxでHTTP/2サーバを立てる話をします。 Let’s Encryptを使おう Let's Encryptを利用すると、無料で認証されたSSL証明書を簡単に発行することができ、ここ最近話題を集めています。今月、Let's EncryptはようやくPublic Betaになりました。そこで、まさに今が旬ともいえるLe
![Let's EncryptとnginxでHTTP/2サーバを立てる - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c4567d7f0adf50228a21ca960797fc34b9d5e6d7/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fi%2Fitochan315%2F20151209%2F20151209202000.png)
Cookie InjectionによるHTTPSハイジャックについて調べてみる - ももいろテクノロジー
中間者攻撃のもとでのCookie InjectionによるHTTPSの盗聴・ハイジャックについて、次のようなアナウンスが出ている。 Vulnerability Note VU#804060 - Cookies set via HTTP requests may be used to bypass HTTPS and reveal private information JVNVU#92999848: HTTP リクエスト経由で設定された Cookie によって HTTPS 接続がバイパスされたり情報漏えいが発生する問題 ここでは、アナウンスで参照されている論文の内容を簡単にまとめてみる。 Cookies Lack Integrity: Real-World Implications (USENIX Security 2015) Cookie Injectionとは HTTPは本来ステートレ
非セキュアなオリジンから'secure'クッキーの変更を廃止する提案 - ASnoKaze blog
先日、HTTPSでsecure属性を付加した場合でも改変できると話が話題になりました。 クッキーの脆弱性が判明： HTTPS のセキュリティを突破する、攻撃が成り立ってしまう！ HTTPSを使ってもCookieの改変は防げないことを実験で試してみた(2013/9/30) Cookies Lack Integrity: Real-World Implications(PDF) そういったリスクを軽減するために、HTTPのオリジンからはsecure属性の付いたクッキーをセット, 上書きを廃止する仕様が提出されている。Googleの人がAuthorな点も興味深い。 提案 提案されている仕様は以下である。 「Deprecate modification of 'secure' cookies from non-secure origins」 とても短い仕様であり、既存の仕組みを先に述べたように変更
Cookieの属性を制限する Cookie Prefixesという仕様 - ASnoKaze blog
"$Origin-"プレフィックスは削除され、"$Host-"プレフィックスが追加されました。 (2015/10/13追記)(2015/10/17 記事更新) 背景の、domain属性の指定に誤りがあったため修正しました。「domain=my-example.com」-> 「domain=example.com」(2015/10/14追記) draft 05よりプレフィックスが$から__に変更されました(2015/12/1追記) Googleの方によって「Cookie Prefixes」という仕様が提案されています（draft-west-cookie-prefixes-01） 以下のCookieに関する仕様を提案しているMike West氏による提案である Origin Cookies Deprecate modification of ’secure’ cookies from non-
HTTP/2時代のバックエンド通信検討メモ - ぼちぼち日記
1. はじめに、 今朝、こんな返事を元に kazuho さんとIPsec/TLS等バックエンド通信について議論する機会を得ました。 せっかくだから現時点での自分の考えを整理してメモとして残しておきます。 普段ちゃんとしたストーリをもったエントリーしか書いていないのですが、今回は時間がないのでちゃんとした論理的文章になっていないメモ程度のものです、あしからず。 以下、フロント側に HTTP/2 を導入した場合のバックエンド通信をどう考えるかのメモです。 2. 性能的観点 フロントにHTTP/2を導入したということは、ブラウザのHTTP HoLブロック解消が目的の一つだと思う。HTTP/2の多重化通信によってクライアントからこれまで以上の同時リクエストをさばかないといけない（だいたい初期値は同時100接続ぐらいに制限されていると思う）。 他方バックエンド側通信は、クライアント側がブラウザではな
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
Upgrade Insecure Resource Requests (A Collection of Interesting Ideas)
This document defines a mechanism which allows authors to instruct a user agent to upgrade a priori insecure resource requests to secure transport before fetching them. This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in pr
Certificate pinningの実装におけるPrivate trust anchorの判定について調べてみる - ももいろテクノロジー
Lenovoのコンシューマ向けPCにプリインストールされたSuperfishと呼ばれるアプリケーションが、システムに独自のルート証明書をインストールしSSL MITM（Man-in-the-Middle）を行っていたことが発覚し、話題になっている（Lenovoによるプレスリリース）。 この件に関して、「Certificate pinningでは防げない」といった内容が書かれた記事がある。 この記事の中で参照されているChromiumのSecurity FAQでは、デバッグ用プロクシやファイアウォールなどのセキュリティ機器によるSSL MITMを許すため、「private trust anchor」の場合はpinningが無効になると書かれている。 Security FAQ - The Chromium Projects # How does key pinning interact wit
不正なSSL証明書を見破るPublic Key Pinningを試す - ぼちぼち日記
先日のエントリー 「TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説)」で予告した通り、今回不正なSSL証明書を見破る Public Key Pinningの機能について解説します。 Public Key Pinning は2種類の方法があります。あらかじめブラウザーのソースコードに公開鍵情報を埋め込む Pre-loaded public key pinning と、サーバからHTTPヘッダでブラウザに公開鍵情報を通知するHTTP-based public key pinning (HPKP)の２つです。 Chromeは既に両者の機能を実装済ですが、ちょうど近日リリースされる Firefox 32 の Stable バージョンから Pre-loaded public key pinning が実装されました。Firefox32リリース記念と
自堕落な技術者の日記 : TwitterのPerfect Forward Secrecy(PFS)対応 - livedoor Blog（ブログ）
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 SSL/TLS CipherSuiteウォッチャーの@kjurです。 TechCrunch JPに昨日こんな記事が掲載されました。 Twitterが将来の暗号解読を防ぐため全サイトにわたってPerfect Forward Secrecyを採用 (2013年11月23日) http://jp.techcrunch.com/2013/11/23/20131122twitter-enables-perfect-forward-secrecy-across-sites-to-protect-user-data-against-future-decryption/ 最近、SSL/TLS のCipherSuiteについて、いろいろ趣味で調べているんですが
Detectify Blog – HTTP Strict Transport Security (HSTS)
HTTP Strict Transport Security (HSTS) HTTP Strict Transport Security, or just HSTS, is a security mechanism for websites and browsers. HSTS is used when web servers want to tell its clients that they should only use HTTPS, and not HTTP. This mechanism is useful, because loads and loads of websites have a lazy encryption discipline, and while most of the website is loaded with HTTPS, some resources
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PDF] Crippling HTTPS with unholy PAC
[PDF] HEIST: HTTP Encrypted Information can be Stolen through TCP-windows
MXR is retired
src.chromium.org SVN
Public Key Pinning Extension for HTTP
Sign in - Google Accounts