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では出来
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
「RFC7525: TLSを安全に使うための推奨事項」の改定 - ASnoKaze blog
様々な組織や団体がTLSを安全に利用するためのドキュメントを出してたりする。 IETFでも2015年にRFC7525 「Recommendations for Secure Use of TLS and DTLS」として、使用する上での推奨事項をまとめている。 それについての詳細は、urushima先生の記事を見ていただくと良いと思う。 blog.livedoor.jp 上記のRFC7525から5年が経ち、その間にRFC 8446 TLS1.3の発行などもありました。そのため、IETFではこのRFC7525の改定作業が開始されました RFC7525bis IETFのUTA (Using TLS in Applications) WGでは、RFC7525の改訂版として、次のドキュメントをすでにWG Itemとして扱っている draft-ietf-uta-rfc7525bis ここでは、簡単に
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(攻撃対象): ブラウザで攻撃者のサイトにアクセスすｒ
Cookieのセキュリティを改善する Scheming Cookiesについて - ASnoKaze blog
Chromeが「Cookie の SameSite=Lax をデフォルト化」を進めたことは記憶に新しい。 asnokaze.hatenablog.com Cookieの改善は引き続き議論されており、Cookieの扱いでスキーム（http://やhttps://）を考慮に入れることが検討されている。 Incrementally Better Cookies Cookieのセキュリティ改善を精力的に行っているGoogleのMike West氏は、Secure属性の利用が30%、"__Secure-"プレフィックスの利用が0.18%ほどにとどまっていると述べており(リンク)、セキュリティ改善のためにCookieの扱いを段階的に変更していくことを考えている。 同氏がIETFに提出している「Incrementally Better Cookies」では、Cookieを次のように段階的に改善することを
Cross-Origin-Opener-Policyについて - ASnoKaze blog
Cross-Origin-Opener-Policy (COOP)は現在、ChromeやFirefoxで実装が進められている機能です。 Chrome: Implement Cross-Origin-Opener-Policy firefox: Implement Cross-Origin-Opener-Policy 仕様としては、whatwgで長らく議論がされており、おそらく仕様に入るでしょう Restricting cross-origin WindowProxy access (Cross-Origin-Opener-Policy) · Issue #3740 · whatwg/html · GitHub Cross-Origin-Opener-Policy: provide a clearer spec. · Issue #4580 · whatwg/html · GitHub 面白
新しいユーザエージェント表現 User Agent Client Hints の提案仕様 - ASnoKaze blog
20200116追記 chrome://flags/ より、「Experimental Web Platform features」を有効にすることで使用できます 20191210追記 モバイルブラウザを示すブーリアン値をもつSec-CH-UA-Mobileヘッダが仕様に追加されました。 ユーザエージェントは歴史的背景により、複雑な文字列が使用されています。 iOSでは User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 12_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/69.0.3497.105 Mobile/15E148 Safari/605.1Edgeでは User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64
QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog
[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP
Chromeにおいて非セキュアなHTTPで送信されたCookieの有効期限を短くする議論 - ASnoKaze blog
暗号化してないHTTPで送信されたCookieの有効期限を短くしたいという議論は、Mozillaでも以前から行われてきました。「Intent to ship: Treat cookies set over non-secure HTTP as session cookies」。 もちろん、IETFでもMozillaのMartin Thomson氏らによって同様の提案がされています。 asnokaze.hatenablog.com それに続く形で、Chromeでも非セキュアなHTTPで送信されたCookieの有効期限を短くするかという議論が行われています。 Intent to Deprecate: Nonsecurely delivered cookies. Intent to Deprecate: Nonsecurely delivered cookies この議論は、Webのセキュリティ
HTTP/1.1 (RFC 7230 〜 7235) の改訂作業がはじまる - ASnoKaze blog
2021/10/21 追記。変更点について別記事を書きました。 asnokaze.hatenablog.com HTTP/1.1の仕様は下記の通り、6つのRFCで標準化されています。 rfc7230 rfc7231 rfc7232 rfc7233 rfc7234 rfc7235 これら、HTTPリクエスト・レスポンスヘッダや、ステータスコード、キャッシュや認証の仕組みといったHTTPの意味(セマンティクス)はHTTP/2でもHTTP over QUICでも変わっていません。 つまり、引き続きHTTPのセマンティクスを定義しているこれらのドキュメントは整備(メンテナンス)し続ける必要があります。 また、今回の作業によりHTTP/1.1のシンタックスと、HTTPのセマンティクスの仕様を分離することで、HTTP/3などからはセマンティクスの仕様を参照でき、仕様としてより整理された形となります。
Happy Eyeballs Version 2 の仕様 (RFC8305) - ASnoKaze blog
2017/12/22 RFC8305として標準化されました。 なお、下記内容は標準化中の内容につき一部古いかと思われます。 IPv4とIPv6両方が利用可能なデュアルスタック環境において、通信する際にIPv6とIPv4を並列的に試してより早く通信の確立が出来た方を試す Happy Eyeballs という仕組みがあります。 より環境の良い方を使うだけでなく、IPv6で通信を試みてからうまくいかない場合にIPv4にフォールバックするのでは無いためより早く通信通信の確立ができます。 Happy EyeballsはRFC 6555で標準化されておりますが、Appleの人によって提案されているHappy Eyeballs Version 2の仕様がIETFで議論されているので簡単に読みます。 Happy Eyeballs Version 2 Happy Eyeballs Version 2は、RF
Webページを丸ごとパッケージングする Web Packagingとは - ASnoKaze blog
20180824追記 Loading Signed Exchangesについて記事を書きました Loading Signed Exchangesの仕様 (WebPackaging) - ASnoKaze blog 20180208追記 Bundled HTTP Exchangesについて記事を書きました Bundled HTTP Exchanges とは (WebPackagingの議論より) - ASnoKaze blog 20180121追記 署名の仕組みとして Origin-Signed HTTP Exchanges を利用する方向のようです HTTP/2 クロスオリジン サーバプッシュを可能にする提案仕様 - ASnoKaze blog 20171001追記 IETF99にてユースケースについてまずまとめるべき気というフィードバックが有り、それをうけて「Use Cases and
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/
Cookieの仕様改定版、RFC6265bisの議論 - ASnoKaze blog
追記 10190510 関連して、このような動きもあります。 Cookie の SameSite=Lax をデフォルトにする提案仕様 - ASnoKaze blog Cookieの仕様と拡張仕様 HTTPのCookieの仕様は RFC 6265 - HTTP State Management Mechanism で定義されております。 2015年頃より、IETFのHTTPbisワーキンググループではCookieのセキュリティを向上させる目的で拡張仕様が3つほど議論されていました。 Cookie Prefixes 付与する属性をCookie名に含めることで、変更できなくする(Chrome51, Firefox50) Same-Site Cookies SameSite属性の追加。クロスサイトへのリクエスト時にはCookieヘッダを付けなくなる(Chrome 51) Deprecate mod
XSSを防ぐ新しいXSS-Protectionヘッダ - ASnoKaze blog
evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて
WiresharkでHTTP/2をパケットキャプチャする - ASnoKaze blog
20190417追記 HTTP/3はこちら「WiresharkでのQUICの復号(decrypt) - ASnoKaze blog」 20151030追記 TLSを利用するHTTP/2では、秘密鍵を設定しても通信を復号することは出来ません。 HTTP/2の鍵交換はPFSなので、下記も参考にして下さい 「Wireshark で HTTP/2 over TLS の通信をダンプする方法」 https://gist.github.com/summerwind/a482dd1f8e9887d26199 この記事は HTTP2 Advent Calendar の 9 日目の投稿です。 初めましてゆきと申します。HTTP/2アドベントカレンダーにはガチ勢しかおらず戦々恐々としております。 アドベントカレンダーネタとしては、Push周りを書こうとしてたのですが先日Push周りの素晴らしい記事が投稿されてし
XSSやCSRFリスクを軽減する、Entry Point Regulationとは - ASnoKaze blog
Entry Point Regulation とは 反射型XSS・XSSI・CSRFのリスクを軽減するユーザエージェント上の仕組みとして、W3CでEntry Point Regulationという仕様が策定中です。 Webアプリケーションの口(Entry Point)に幾つかの制限をかけることが出来ます。別オリジンからのリクエストの時に、クエリパラメータやHTTPリクエストボディ(POSTメソッド)が付いていればブロックする、と言った事がマニフェストで指示できるようになりそうです。 EPRにおけるリクエストカテゴリ 各エンドポイント(URL)はどのようなリクエストを受け付けることが可能か指定できます。その時に指定するリクエストは以下に分類されます navigational request：context frame typeは"top-level", "auxiliary", "neste
QUICの仕様(ドラフト)が公開されたので、概要を読む - ASnoKaze blog
新しい仕様の翻訳を公開しました(2018/10/31) QUICの仕様を翻訳していく http://d.hatena.ne.jp/ASnoKaze/20160725/1469374715 2018年追記 最新の状況、概要についてはこちら asnokaze.hatenablog.com QUICの仕様(ドラフト) 5月頃に、Googleのブログでも「Google の試験的トランスポート、QUIC のアップデート」という記事で紹介されたように、QUICというUDPを用いたプロトコルが注目を集めています。 幾つかのドキュメントは存在していたものの、仕様としては未公開でした。 しかし、6/17に2つのInternet-Draftが公開されました 「QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2」 「QUIC Loss Recov
Origin Cookiesとは - ASnoKaze blog
Origin Cookies GoogleのMike West氏による、Cookieに対する拡張が提案されている。 draft-west-origin-cookies-01では、同一生成元ポリシーと同様なセキュリティポリシーでCookieを扱えるように、Cookie(RFC6265)に"Origin"属性を追加し、HTTPヘッダに"Origin-Cookie"ヘッダを新しく定義する。 "Origin-Cookie"はセットされた時のオリジンと一致するオリジンに対してのみ提出される。 （間違いがあるかもしれません、ご注意下さい） 例 Origin Cookieは、set-cookieヘッダにOrigin属性をつけることでセットされる。 Set-Cookie: SID=31d4d96e407aad42; Secure; HttpOnly; Origin コレを受け取ったユーザエージェントは、H
Chromeの「既定のrefererヘッダーの情報量を減らす(reduced-referrer-granularity)」フラグ - ASnoKaze blog
Chromeのchrome://flags/に「既定のrefererヘッダーの情報量を減らす(reduced-referrer-granularity)」フラグがある。 その動作を確認したので簡単にまとめる reduced-referrer-granularity このフラグを有効にした場合、現在のオリジンと別のオリジンへのリクエストをする際、付加されるrefererヘッダはオリジンの情報だけになる。 例えば、http://localhost/hoge/fuga.html?test=1#hash から http://yahoo.comへのリンクをクリックすると flagがない場合 refererはヘッダは「http://localhost/hoge/fuga.html?test=1」となる flagがある場合 refererヘッダは「http://localhost/」となる 同一オリジン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
