グーグル、「Chrome 67」でHPKPのサポートを廃止へ
Googleは、ブラウザの「Chrome」でHTTP Public Key Pinning（HPKP：HTTP公開鍵ピンニング）のサポートを取りやめることを明らかにした。HPKPは、Googleのエンジニアがインターネット標準化団体のInternet Engineering Task Force（IETF）を通じて発表した標準規格だが、今では悪影響もあると考えられている。 HPKPは「IETF 7469」として定められた標準規格で、認証局（CA）がハッキングされ、サイトのデジタル証明書が悪用されるリスクを減らすために考案された。このような悪用によって、攻撃者は暗号化されたTransport Layer Security（TLS）接続で中間者攻撃を実行できるようになる。 HPKPを利用すると、ウェブサイトはブラウザに対し、特定のウェブサイトに属する公開鍵を一定の期間記憶（ピン止め）するよう指
事実上最後のJSON仕様「RFC 8259」と「ECMA-404 2nd Editon」公開。UTF-8エンコード必須に
RESTful APIのデータフォーマットなどで広く使われているJSON。IETFはJSON仕様「RFC 8259」を発表。従来の仕様をブラッシュアップしつつECMAの仕様との統一も実現した、事実上最後のJSON仕様になると見られる。 IETFからJSON（ジェイソン）の仕様を示した「RFC 8259」（The JavaScript Object Notation (JSON) Data Interchange Format）が公開されました。 IETFにおけるJSON仕様は、これまで「RFC 7159」が参照されていましたが、RFC 8259の公開によりRFC 7159は廃止（Obsolete）となりました。 RFC 8259は、多数の実装と十分な運用実績を積み重ねたインターネット標準「STD 90」としても参照されます。 ECMAとの統一を実現。事実上最後のJSON仕様になると見られる
DOTSプロトコルを使ってDDoS対策を自動化してみたい！ - Qiita
NTTコミュニケーションズアドベントカレンダー 12日目。 今日は、荒ぶるDDoS攻撃1からサービスを防御するための新しいプロトコル DOTS (DDoS Open Threat Signaling)を紹介します。 DOTSプロトコルについての詳しい日本語の記事は初めてなのではないかと思います。 DOTSとは？ DOTSとはIETFで策定中のDDoS対策のためのプロトコル DDoS対策の自動化と標準化を実現するよ OSSによる実装がでているよ この記事では、OSS実装である go-dots を使って、DOTSプロトコルの利用方法を紹介します。 これからのDDoS対策の話をしよう DDoS攻撃は2つの方向で脅威が進化しています。 大規模化: Arbor社によると、2016年のリオオリンピックでは、500Gbpsを超えるDDoS攻撃があったとのことです。IoTなどインターネットに接続される機器
パスワードマネージャが適切にパスワードを生成できるようにするポリシーの提案仕様 - ASnoKaze blog
パスワードの管理に、1PasswordやLastPassといったパスワードマネージャを使うのは一般的になってきています。 そのようなパスワードマネージャはランダムなパスワードを生成しますが、Webサービスによって使える文字の種類や、長さというのはマチマチです。 そこで、Webサービス側からパスワードの要件について記述できるようにする仕様がIETFに提出されています。 どこのWGで議論するのか、標準化が進むのかよくわからないが、とりあえず読んでおく。 Open Password Automation Recipe Protocol パスワード自動生成出来るように提案されている仕様は「Open Password Automation Recipe (OPAR) Protocol」というタイトルです。 Webサービスはページ内に下記のようなJSONをOPAR_Policyという変数で埋め込むこと
セキュリティの報告先を記述する、security.txtの提案仕様 (RFC9116) - ASnoKaze blog
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
QUICのヘッダ圧縮QPACKとは (旧QPACK) - ASnoKaze blog
20190408追記 最新版について記事を書きました asnokaze.hatenablog.com QUICのヘッダ圧縮であるQPACKについて 現在のQUICの策定中仕様の一つである「Hypertext Transfer Protocol (HTTP) over QUIC」では、QUICでもHTTPヘッダの圧縮にHPACKを使用することになっていますが、新しくQUIC用のヘッダ圧縮方式として「HTTP over QUIC - Mapping and Header Compression」という仕様でQPACKなるものが提案されています。 背景 QUICとHPACK HTTP/2ではヘッダ圧縮方式としてHPACKと呼ばれる方式を利用します。HPACKはRFC 7541「HPACK: Header Compression for HTTP/2」で標準化されています。 HPACKはヘッダ名と
Feature Policy、ブラウザの特定機能を無効にする仕様 - ASnoKaze blog
W3CでFeature Policyという仕様が議論されています。仕様は著者であるGoogleのIlya Grigorik氏のリポジトリ(URL)より確認できます。 このドキュメントはまだW3C公式のドキュメントとはなってはいませんが、先月行われたFace-to-Faceのミーティングでも議論がされています(議事録) Feature Policy セキュリティやパフォーマンスの観点で、Webデベロッパーがブラウザの特定のAPI（機能）を無効にしたい場合もあります。 そこで、 Feature-Policyヘッダを用いて以下のようにブラウザの機能を制限できるようにするのがこの仕様です。 また、このFeature-Policyヘッダは現在IETFで議論が行われている"A JSON Encoding for HTTP Header Field Values"(URL)というHTTPヘッダ値にjso
ネットの3巨人、村井純氏、ティム・バーナーズ＝リー氏、ヴィントン・サーフ氏が札幌で討論。W3CとIETFの協調を模索するべきではないか？ W3C TPAC 2015
［ゲストブロガー：矢倉眞隆氏 執筆］ W3Cの年次イベント「W3C Technical Plenary / Advisory Committee Meeting Week」、通称「TPAC（ティーパック）」が2015年10月26日から10月30日まで、北海道札幌市で開催されました。 TPACは、毎年秋に一週間かけて行われる、W3Cの「技術総会」（Technical Plenary）と「諮問委員会」（Advisory Committee）の会合、そして仕様を策定する各ワーキンググループのミーティングを同時に行う、W3C最大のイベントです。通常はどのミーティングも各々が必要に応じて行うので、それらが同時に行われるTPACは、様々な観点から価値を共有できる貴重な機会です。 さて、諮問委員会の会合はW3Cの運営を、ワーキンググループのミーティングは仕様の策定をそれぞれ扱うと説明できますが、技術総会
HTTP/2は流行らないけど広く使われるものだと思う。 - ぼちぼち日記
まずは Disclaimer、 「あくまでも個人の感想であり、HTTP/2の効能を保証するものではありませんw」 1. はじめに、 先日、HTTP/2, HPACKのRFC(7540,7541)が無事発行されました。2年余りHTTP/2の標準化活動に参加してきたのですが、もうすっかり昔の事のような感じがします。 今日、Scutumの開発をされている金床さんの「HTTP/2のRFCを読んだ感想」のエントリーが公開され、読ませて頂きました。今回初めてHTTP/2の仕様書を読まれた感想ということで、長くかかわってきた立場から見ると非常に新鮮な内容でした。 実は「HTTP/2が流行らない」という指摘は、１年半ほど前に私も同じことを書いていました。 HTTP/2.0がもたらす�Webサービスの進化(後半） また、偶然なのかわかりませんが、同じ Proxy製品 vanish varnish *1 の開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IETF QUICに至るプロトコルの透過性問題とその対策