Hatena::ブログ(Diary)

あすのかぜ Twitter

2016-09-28

Secure Contextsに関する localhost と、IETFでの新提案

Secure Contexts

Service Workers、Web BluetoothといったAPIは、安全に使用するためにセキュリティ上の条件があります。


その条件がSecure Contextと呼ばれるコンテキストであり、W3CのSecure Contexts(URL)というドキュメントで定義されています。


このSecure Contextsの仕様上で localhost. の扱いがどうなっているかというと次のようになっている。RFC6761の定義では「ローカルのリゾルバはlocalhost. 及び .localhost. の内側のドメインを特殊扱いしてもよい、すべき(MAY/SHOULD)」と書かれており、その不確実性のためlocalhostではなく127.0.0.1の場合に特別扱いするとしている。

つまり、localhostのドメインをローカルネットワークDNSに問い合わせても良いため、ループバックアドレスという保証が無いことになる。


新提案

そういった状況に切り込んだのが、W3CのWebAppSecでは大変良く見かけるMike West氏である。


IETFに「Let 'localhost' be localhost.」(URL)という、I-Dを提出している。


この提案では、localhost. はループバックアドレスになるように、localhostの名前解決でSHOULDとなっていた部分をMUSTへ変更する提案です。


必ずlocalhost.を特別扱いし(MUST)、DNSにクエリ送信することも許可されません(MUST NOT)。あわせて、DNSサーバも問い合わせに対してNSレコードを検索しようとしてはいけません(MUST NOT)。既存のlocalhost.の扱いを幾つか変更することで、必ずループバックアドレス扱いになるようにし、Secure Contextsでの問題を解消しようとしています。


提案仕様の最後に、Implementation Considerationsとして、サーバの名前にserver1.localhostといった名前をつけている場合は予期せぬ挙動になるという懸念を挙げています。


引き続き、Secure Contextsとlocalhostの議論は続くと思いますが、個人的には興味深いなと思っています。

2016-09-25

wicgのFace detection API

wicgで議論になっている「Face detection API」の仕様が「Shape Detection in Images」としてwicgのリポジトリで公開されている。


https://wicg.github.io/shape-detection-api/


Shape Detection in Images

HTMLImageElement、HTMLCanvasElement、ImageDataといった画像のデータを与えることで、顔領域の矩形が得られるようである。


現状は、顔を検出する「Face Detection API」と、バーコードを検出する「Barcode Detection API」が定義されている。


具体的にはexampleを見るとわかりやすい

let faceDetector = new FaceDetector({fastMode: true, maxDetectedFaces: 1});
// Assuming |theImage| is e.g. a <img> content, or a Blob.

faceDetector.detect(theImage)
.then(detectedFaces => {
  for (const face of detectedFaces) {
    console.log(' Face @ (${face.boundingBox.x}, ${face.boundingBox.y}),' +
        ' size ${face.boundingBox.width}x${face.boundingBox.height}');
  }
}).catch(() => {
  console.error("Face Detection failed, boo.");
})

2016-09-07

HTTP/2のデバック用情報エンドポイントの仕様

HTTP/2 Implementation Debug State

「HTTP/2 Implementation Debug State」というHTTP/2用のデバッグ情報を表示するエンドポイントの仕様が、IETFに提出されています。

https://tools.ietf.org/html/draft-benfield-http2-debug-state-01


サーバの「.well-known/h2/state」にアクセスすることでそのコネクションの状態を表示するサーバ側のエンドポイント、及びその内容を定義しています。


mod-h2 http2-status

mod-h2のversion 1.6.0より http2-status が、この仕様に準拠したので簡単に動作確認する。


ubuntu16.04(openssl 1.0.2)で、今回は svn のtrunkからビルドする

#nghttp2をインストールしておく
sudo apt-get install -y  libtool libtool-bin libpcre3-dev autoconf libssl-dev libxml2-dev libev-dev build-essential 

svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x httpd-2.4.x
cd ../httpd-2.4.x/
svn co http://svn.apache.org/repos/asf/apr/apr/trunk srclib/apr
./buildconf

./configure
make

証明書の設定及びSSL(TLS)とHTTP/2を有効にし、confにhttp-2statusの設定を加える

   Protocols h2c http/1.1
   <Location "/.well-known/h2/state">
        SetHandler http2-status
   </Location>

結果

/.well-known/h2/state

{
  "version": "draft-01",
  "settings": {
    "SETTINGS_MAX_CONCURRENT_STREAMS": 100,
    "SETTINGS_MAX_FRAME_SIZE": 16384,
    "SETTINGS_INITIAL_WINDOW_SIZE": 65535,
    "SETTINGS_ENABLE_PUSH": 1
  },
  "peerSettings": {
    "SETTINGS_MAX_CONCURRENT_STREAMS": 1000,
    "SETTINGS_MAX_FRAME_SIZE": 16384,
    "SETTINGS_INITIAL_WINDOW_SIZE": 6291456,
    "SETTINGS_ENABLE_PUSH": 1,
    "SETTINGS_HEADER_TABLE_SIZE": 4096,
    "SETTINGS_MAX_HEADER_LIST_SIZE": -1
  },
  "connFlowIn": 2147483647,
  "connFlowOut": 15707901,
  "sentGoAway": 0,
  "streams": {
    "41": {
    "state": "HALF_CLOSED_REMOTE",
    "created": 1473179424.329667,
    "flowIn": 65535,
    "flowOut": 6291456,
    "dataIn": 0,
    "dataOut": 0
    }
  },
  "stats": {
    "in": {
      "requests": 21,
      "resets": 0, 
      "frames": 24,
      "octets": 1250
    },
    "out": {
      "responses": 20,
      "frames": 43,
      "octets": 21712
    },
    "push": {
      "cacheDigest": "AQg",
      "promises": 0,
      "submits": 0,
      "resets": 0
    }
  }
}

幾つかの仕様上でオプショナルな物は表示されない。例えばHPACKのダイナミックテーブルの情報なども仕様上は定義されているが、セキュリティ上の理由により検討して仕様すべきとされている。