2023/12/23 追記: RFC 9520 になりました == 「Negative Caching of DNS Resolution Failures」という提案が、Verisignの方らによって提案されています。 DNSの名前解決の結果はつぎのいずれかです。 1) 要求されたデータを含む応答 2) 要求されたデータが存在しないことを示す応答 3) ネットワークエラーや、データ不整合などの、有用な情報が得られない(失敗) 今回の提案では、(3)のエラーについても最低5秒間ネガティブキャッシュするよう要求します(5分以上キャッシュしてはいけない)。 RFC2308 「Negative Caching of DNS Queries」では、サーバが落ちていたり接続できない場合に、オプショナルでキャッシュする事が記述されてはいます。 モチベーション 提案仕様のなかで、DNSのエラーが起こり、

ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)

3rd パーティクッキーの廃止計画が世間を賑わせています。一方で、3rdパーティクッキーには、トラッキング目的でないユースケースもあります。それらのために、3rdパーティクッキーの制限を緩和する「Cookies Having Independent Partitioned State (CHIPS)」という仕組みが検討されています。 この仕組みに則っていれば、制限のもと3rdパーティクッキーを使えるようになります。 もちろん、これはトラッキングが出来ないようになっています。 仕様: https://github.com/WICG/CHIPS Chromeの実装計画: 「Intent to Prototype: Cookies Having Independent Partitioned State (CHIPS)」 ユースケースについては、仕様の中で述べられていますのでそちらを参照ください

2011年頃、ドメイン所持者が意図せぬ形で、認証局よりサーバ証明書がご発行される事件がありました。この対策として、Certificate Transparency (CT) という仕組みが導入されました。 CTの仕組み CTの利用の流れは幾つかありますが、一例を示します。 1. 認証局が証明書を発行する際に第三者が運営するCTログサーバにプレ証明書を登録します。登録時に、登録の証左となるSigned Certificate Timestamp (SCT)が認証局に渡されます。 2. 認証局は、登録時に得られるSigned Certificate Timestamp (SCT)を証明書に付与して発行します。 3. ブラウザ(PC版Chrome)がWebサイトにアクセスする際、証明書にSCTがついてない場合は、エラー画面を表示します。 ( https://no-sct.badssl.com/

2022年7月追記: この記事は古くなっています。現在の最新仕様では、拡張CONNECTメソッドを使うことになってます asnokaze.hatenablog.com 確立したHTTP/3コネクションをVPNのように使う、MASQUEという仕組みがIETFで議論されています。 以前書いた記事では、UDPパケットをProxyさせるCONNECT-UDPという提案仕様を紹介しました。 asnokaze.hatenablog.com その後、同様に確立されたHTTP/3コネクション上で、IPパケットをトンネリング可能にする「The CONNECT-IP HTTP Method」という仕様が提案されています。 CONNECT-UDPと同様に経路上の第三者にはただのHTTP/3通信を行っているようにしか見えないため、検閲やブロッキングに対して耐性があると思われます。 それでは簡単に見ていきましょう。

IETFで、TLS1.0とTLS1.1を正式に非推奨にする「RFC 8996 Deprecating TLS 1.0 and TLS 1.1」が公開されました。 新しいプロトコルへの移行期間は十分であるとし、TLS1.0, TLS1.1, DTLS1.0は廃止となり、TLS 1.2, TLS1.3, DTLS 1.2のみが使用できます。表現としても、MUST NOTで利用を禁止しています。 TLS 1.0 MUST NOT be used TLS 1.1 MUST NOT be used 2015年に公開された、TLS利用時の推奨事項を定めたRFC7525がありますが、今回の禁止内容も含めて改定作業が開始されています。詳細については以前書いたとおり asnokaze.hatenablog.com 更新されるRFC RFC 8996では、既存のRFCについても言及しており TLS1.2以上で

今使っているDNSサーバがDNS over HTTPS (RFC8484)に対応しているか確認する方法は標準化されていません。 例えばChromeでは、どのDNSサーバがDoHをサポートしているかソースコード(URL)にハードコードされています。 通常、DHCPや、IPv6 Router AdvertisementsでDNSサーバを指定する場合はIPアドレスで指定されます。それが、DoHやDoTに対応しているか識別出来るようにするというのが今回の話です（ちなみに、HTTPSで繋いでみるという方法はうまくいきません） この問題を解決するために「Discovery of Designated Resolvers」という提案仕様が出ています。すでにADD WGにAdoptionされております。 今回はこの仕様を簡単に読んでいこうかと思います。 Discovery of Designated Re

2024/02/13 に、下記記事を書き直しました！ asnokaze.hatenablog.com =========== ユーザのトラッキングを防ぐ「Oblivious HTTP」という仕様が、Mozilla及びCloudFlareの方らの共著でIETFに提出されています。この仕様では、ユーザのIPアドレスを隠す仕組みを提供します。これによって、サーバが受信した複数のリクエストが同一ゆーざのものであるかわかりにくします。 先行して、CloudFlareは「Oblivious DoH」という仕組みを提案している。これはDNS over HTTPSのクライアントIPアドレスを隠蔽する仕組みである。その仕組をHTTPに適応したのがOblivious HTTPである。 blog.cloudflare.com Googleが別途提唱している「Privacy Sandbox」でも、IPアドレスはユ

外側から、NAT内の端末の任意ポートにアクセスするNAT Slipstreamingという攻撃があります。 このNAT Slipstreamingについては、以前ブログに書いたとおりです。 asnokaze.hatenablog.com 2021年01月26日に、Armisの研究者らがNAT Slipstreaming v2として新しい攻撃手法を公開しました。 簡単にv1との違いを眺めていこうかと思います。 v2の違い v2も攻撃の大きな流れは同様です。罠サイトを踏んだNAT内のブラウザに、ALGをご作動させるようなパケットを送らせることで、NATの穴あけを行う。v1はすでにブラウザで対応されていたが、v2ではその対応では不十分だった。 v2の違いを簡単にかいつまむと v1では罠サイトを踏んだ端末のみに外部からアクセス可能だったが、v2では罠サイトを踏んだ端末以外にもアクセス可能 H.32

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では出来

Webサイトのセキュリティリスクを発見したものの、連絡先が適切に公開されていないがために、結局報告されず脆弱性が放置されるケースがあるようだ(国内だと、IPA脆弱性関連情報の届出受付もあるが) 発見者が脆弱性等の報告を出来るような情報を、Web作成者が提供できるようにする仕様がIETFに提出されている。 この「A Method for Web Security Policies」という提案仕様では、security.txtをドメイン直下のURLに配置し、連絡先などを記述するようになっている。 security.txt security.txtは例えば以下のとおりである # Our security address Contact: security@example.com Contact: +1-201-555-0123 Contact: https://example.com/secur