ZeroSSL ならIPアドレスのサーバ証明書が取得できる - ASnoKaze blog
IPアドレスのサーバ証明書が欲しい場合があります。そうすれば、ドメインを取得せずともサーバとHTTPS通信ができるようになります。 その他にも例えばDNS over HTTPSではIPアドレスでアクセス出来るように、有効な証明書がセットされていたりします。 https://1.1.1.1 https://8.8.8.8 しかし、Let's Encryptでは、IPアドレスのサーバ証明書は取得できません ~$ sudo certbot certonly --nginx -d 160.16.124.39 Requested name 160.16.124.39 is an IP address. The Let's Encrypt certificateauthority will not issue certificates for a bare IP address.ZeroSSLでは出来
Cookieの新しい属性、SameParty属性について - ASnoKaze blog
ChromeでCookieのSameParty属性の開発が進められている (コミット)。 現在のところ「SameParty cookie attribute explainer」に説明が書かれている。 今回は、CookieのSameParty属性について簡単にメモしていく。 背景 トラッキング対策、プライバシーの観点でサードパーティクッキーは制限する方向に進んでいる。その制限をSame Partyの場合に緩和する仕組みを提供するのがSameParty属性の話である。 例えば、同一主体により運営されているドメインの異なるサイト (例えば、google.co.jp, google.co.uk) 間においては、いわゆる(cross-site contextsで送られる)サードパーティクッキーを許可しようという話です。 もともとは、First-Party Setsを活用しSameSite属性にFi
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
NAT Slipstreaming攻撃とブラウザ側の対策 - ASnoKaze blog
2021/01/29 NAT Slipstreaming v2が公開されたので、追加記事を書きました https://asnokaze.hatenablog.com/entry/2021/01/29/014759 2020年10月31日に「NAT Slipstreaming」という攻撃手法が発見されてます samy.pl これは簡単に言うと 罠サイトを踏ませることで、SIPのApplication Level Gateway機能を持つNATの内側に居るクライアントに対して、外側からそのクライアントの任意のTCP/UDPポートに接続できる。という攻撃のようです。 この攻撃はさまざなテクニックを使用しており大変面白いです。調査過程も含め詳細は上記のサイトに書かれているので、そちらを読むことを強く推奨します。 ざっくり 登場人物 victim(攻撃対象): ブラウザで攻撃者のサイトにアクセスすｒ
ChromeのSecure context restriction for external requests - ASnoKaze blog
[目次] 概要 Secure context restriction for external requests CORS-RFC1918 非セキュアコンテキストなWebサイトからプライベートアドレスへのHTTPリクエストをブロックする「Secure context restriction for external requests」の導入が進められています。 概要 インターネットに公開されているWebサイトから、プライベートアドレスに対するCSRF攻撃が問題になっています。ネットワーク機器やプリンタの管理画面で使われるプライベートアドレスにリクエストを行わせることで、攻撃が行われます。 例えば下記のリンクを埋め込むことで、プライベートネットワークを指すrouter.local にHTTPリクエストを行わせます。 <iframe href="https://admin:admin@rout
オリジン全体にポリシーを適応するOrigin PolicyをChromeで試す - ASnoKaze blog
目次 Origin Policy 有効にさせる方法 試してみる Chromeがオリジン全体にポリシーを適応する「Origin Policy」という仕様をサポートしてるようなので、簡単に試してみる。(現在は Chrome Canaryのみの模様) おそらく仕様及び実装も変わりうるので注意が必要です（極力仕様の変更があったら、記事を更新するようにします） Origin Policy Content-Security-PolicyやFeature-Policyといった、ブラウザがページを表示する際に機能を制限したりセキュリティ上の制限を与える機能があります。これらの機能はレスポンスヘッダに該当のヘッダを付けることでポリシーを適応させることができます。 そのため、これらの機能をもれなく適応するにはレスポンスの都度きちんとこれらのヘッダーを付加しなければなりません。 また、CSPやFeature-P
HTTPメッセージに署名をするSignatureヘッダの標準化 - ASnoKaze blog
HTTPメッセージに署名をするSignatureヘッダを定義する「Signing HTTP Messages」という仕様が提案されています。 HTTPメッセージへの署名は、様々なところで行われていますが、それぞれ独自の方式で行われています。例えば、AWS APIを叩く際に利用する「Signature Version 4 Signing」や、OAuth2.0 DPoPなどでHTTPメッセージへの署名が行われています。 その他にも、WebPackagingで使用される「Signed HTTP Exchanges」といったところでも署名が行われています。 一方でTLSではだめなのかという話もありますが、TLSを用いることでHTTPメッセージの機密性および完全性は保護されますが、TLS終端プロキシなどを経由するとそれ移行の部分で通信の完全性は担保されません。クライアントとサーバ間でHTTPメッセー
処理中のPOSTリクエストを別のサーバで引き継ぐPartial POST Replayについて - ASnoKaze blog
なんらかの理由でWebサーバを停止する場合に、処理中のPOSTリクエストをそのまま別のサーバで引き継げるようにする「HTTP Partial POST Replay」という仕様がFacebookのAlan Frindell氏から提出されています (HTTP Workshopの資料はこちら)。 スポットインスタンスを利用していたり、サーバの設定を変えて再起動したい場合、新しいリクエストは受け付けないようにし、すでに来ているリクエストのみ処理をするのは一般的です。それでも大きなファイルをアップロードしているPOSTリクエストは処理が終わるまで時間がかかってしまう場合がありあります。 やむをえずPOSTリクエストの処理を中断してしまうと、ユーザは再度大きなファイルをアップロードしなおす必要があり、とてもストレスがかかります。 「HTTP Partial POST Replay」では、ユーザの接続
WiresharkでのQUICの復号(decrypt) - ASnoKaze blog
2019/5/17追記 QUICの暗号化について説明を書きました asnokaze.hatenablog.com 2020/09/16「WiresharkがHTTP/3に対応した - ASnoKaze blog」 WiresharkはIETF版 QUICパケットのdecryptに対応しているので、やってみる。 Wiresharkの細かい対応状況については以下の通りです。 Tools · quicwg/base-drafts Wiki · GitHub 最新のソースコード内に書かれているTODOとしては、以下の通り。 * to-do list: * DONE key update via KEY_PHASE bit (untested) * TODO 0-RTT decryptionhttps://github.com/wireshark/wireshark/blob/master/epan
Fake SNIという提案仕様について - ASnoKaze blog
SNIを用いた通信のブロッキング及び、「Encrypted SNI拡張」のブロッキングについてはIETFのTLS WGでも話題となりました（(TLS) SK filtering on SNI, blocking ESNI）。 Encrypted SNIはSNIを暗号化する一方で、ClientHelloにencrypted_server_name拡張をつけます。そのため、経路上の観測者はEncrypted SNIが使われていることを検知できます。 それを回避するために、ニセのSNIをつける「Fake Server Name Indication」というdraftが提出されています。 初版のdraftであり、これから議論のあるところだとは思うが、とりあえず面白そうなので読んでみる。 Fake SNI Fake SNIを利用するサービスは事前に、偽のホスト名を公表します。DNSを利用することを想
Chrome 71で検討されている iframeへのPermission Delegation - ASnoKaze blog
Webサイトがカメラや位置情報をアクセスする際にパーミッションを要求する場合がある。iframeで埋め込んだページでも同じようにパーミッション要求が行える。 Chrome 71で導入が検討されている「Permission Delegation」では、iframeで埋め込まれたページでのパーミッション要求の仕組みがわかりやすくなる。(iframe内のドメインからパーミッション要求されても、普通のユーザにはわかりにくい) iframe内でパーミッションが必要になった際、top level origin(URLバーに表示されているサイト)がパーミッションを要求し、その権限を移譲する形になる。 その結果各パーミッションはtop level originに紐づくため、ユーザは権限の管理が行いやすくなる。 例 https://asnokaze.com/pd.html は以下のように、iframeを埋め
DNS over HTTPSサーバを見つけるためのTXTレコードの提案仕様 - ASnoKaze blog
20190821 追記 この提案は廃案されました https://mailarchive.ietf.org/arch/msg/doh/qkmhh93Id6XIngH3LJwp-HokH_Y DNS over HTTPS(DoH)の標準化が進められており、引き続き注目を集めている。 asnokaze.hatenablog.com 一方で、DoHサーバをどのように見つけるか、見に行かせるかの議論が始まっています。 JPNIC Blog :: DNS over HTTPSとDHCP －IETF102における議論－ で紹介されている通り、先月行われたIETF102でもDNSリゾルバの識別子と利用についてのBoFがありました。 例えば、設定ファイルだったり、DHCPでDNSサーバを設定する際にDoHサーバを設定する際にどうすればいいか、どのようディスカバリさせるかといった議論です。 その流れで、Do
Cookieにかわる Sec-HTTP-State ヘッダの提案 - ASnoKaze blog
20190424 追記 IETFに提案仕様が提出されました https://tools.ietf.org/html/draft-west-http-state-tokens-00 Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から「Tightening HTTP State Management」というCookieに変わるHTTPにおいてステートを扱う仕組みが提案されています。 現在はIETFのHTTPbis WGのMLに投稿されただけで仕様が正式にinternet-draftとして提出されたものではありません。まだまだどうなるかは全然わからない状態です。 この提案では、現在のCookieはセキュリティと非効率性とプライバシーの問題があると言っています。 現在のcookieは、Same-Origin-Policyとは異なりオリジンを超えて
NginxがHTTP2サーバプッシュに対応したので試す - ASnoKaze blog
追記 [nginx-announce] nginx-1.13.9 http://mailman.nginx.org/pipermail/nginx-announce/2018/000207.html 1.13.9でサーバプッシュがサポートされました 先程、Nginxでサーバプッシュをサポートするコミットが入ったので試す。 HTTP/2: server push. http://hg.nginx.org/nginx/rev/641306096f5b ビルド $ git clone https://github.com/nginx/nginx.git $ cd ./nginx $ ./auto/configure --with-http_ssl_module --with-http_v2_module $ make $ sudo make install #一旦インストールしてしまう 設定 一
Nginxで、リクエストを複製するmirrorモジュールが標準搭載された - ASnoKaze blog
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
Nginxのリバースプロキシでバックエンドとhttp2通信する - ASnoKaze blog
以前書いたとおり、ApacheではリバースプロキシでバックエンドとHTTP2通信することができます。 asnokaze.hatenablog.com Nginxの場合は、開発者のメーリングリストでGoogleの人が書いてる「ngx_http_v2_upstream」パッチを利用することでバックエンド(upstream)とHTTP2通信することが出来るようになります。 パッチ [PATCH 01 of 14] Output chain: propagate last_buf flag to c->send_chain() [PATCH 02 of 14] Upstream keepalive: preserve c->data [PATCH 03 of 14] HTTP/2: add debug logging of control frames [PATCH 04 of 14] HTTP/
HTTP over マルチキャストQUIC とは - ASnoKaze blog
2022/05/16 動きがあったため、記事を新しく書きました asnokaze.hatenablog.com 「Hypertext Transfer Protocol (HTTP) over multicast QUIC」で、マルチキャストのQUIC上でHTTP通信を行う仕様が提案されている。マルチキャストQUICは単方向通信であり、その上でサーバプッシュを行う感じである。 現状QUICの仕様ではIPマルチキャストの利用は想定されていない(もちろん双方向通信)ため、この仕様ではQUICのトランスポートレイヤ、HTTPレイヤを利用しつつも、IPマルチキャストを利用できるように一部の変更(制限)を加えている。 BBC Researchの方が書かれているので、主に動画像配信での利用を考えているんだと思う。 ざっと仕様を読んだのでかいつまんで特徴を紹介する。 また、QUICの仕様はまだ変わる可能
WiresharkのTLS1.3対応 動いた - ASnoKaze blog
TLS1.3動いたシリーズの第3回目(?) WiresharkはTLSの実装一覧ページ(URL)では、以前よりTLS1.3対応をうたっていたがあまり出来は芳しくなかった。しかし、先日 TLS1.3絡みのコミットが幾つか入ったので、実際に改善されていることを確認した コミットログ(URL)を見る限りdecryptにも対応しているようなので、復号もできそうだが、TLS1.3になって復号に必要なパラメータが変わったため SSLKEYLOGFILEまわりの仕組みがどうなってるかはよくわからない。picotlsだと、うまくいくかもしれない(URL) 2019年5月追記: すでに復号対応しております。SSLKEYLOGFILEを食わせれば復号できる。 ビルド 今回は簡単に、CUI版であるTsharkをtrustyでビルドする sudo apt-get install -y flex libglib2.
googleの新しい時刻同期プロトコル Roughtimeとは - ASnoKaze blog
[追記] 2020年1月時点の動向について、新しく記事を書きました asnokaze.hatenablog.com Googleの「Adam Langley氏のブログ」で、新しい時刻同期プロトコルについて紹介されている。このRoughtimeは特定のタイムサーバに依存しないセキュアな方法で時刻同期を行うことを目的としたプロトコルです。すでに、googleのサーバで動作しており、roughtime.sandbox.google.com:2002に向けて公開されている専用クライアントで接続できる。 現在のセキュリティは現在の時刻に依存しており、その重要性はましています。証明書の有効期限や、OCSPレスポンス、Kerberosのチケット、DNSSECの応用やPGP鍵といった機能でも重要です。しかし、Chromeの証明書エラーのうち25%はローカルの時刻に起因するとしているとしています。 現在、最
プライベートネットワークへのCSRFを緩和する仕様の提案 (CORS-RFC1918) - ASnoKaze blog
GoogleのMike West氏によって、Chromiumのメーリングリスト上で「インターネットからイントラネットへのCORSの厳格化」に関する提案が行われている。 「CORS and RFC1918」として提案している仕様も公開されているが、個人のリポジトリであり、W3Cのドキュメントにはなっていない。 背景 「プライベート網のアドレス割当(RFC1918)」で記述されているように、プライベートとパブリックのアドレスは区別されています。しかし、ユーザエージェントはそれらを分離して扱っていません。 悪意を持ったPublicなWebサイトは、クライアントにローカルのプライベートネットワークのデバイス・サーバに対してリクエストを送らせることが出来ます(CSRF攻撃)。 以下のドキュメントに記述されているような、ネットワーク内のルータに対するCSRF攻撃などもありました。これらの幾つかは、プリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
