http2: support adding never-index header fields

As part of the HTTP2 (and HTTP3) spec, some headers can be sent as Literal Header Field Never Indexed

https://www.rfc-editor.org/rfc/rfc7541.html#section-6.2.3

This can be used for security reasons to avoid CRIME (Compression Ratio Info-leak Made Easy) attacks to expose sensitive information.

Points of interest are:

It'll help diagnose #28632

This is definitely something that was considered early on when I did the initial implementation. It is hampered by the fact that we tried to keep the API for headers in http/2 as close as possible to that of http/1, which uses a simple object to express headers... e.g.

{
  ":method": "GET",
  "content-type": "text/plain",
  "abc": ["value 1", "value 2"]
}

The difficulty here becomes: how do we indicate which headers should not be indexed? Should it be specified per-request? Should it be specified separately from the actual header pairs?

One way we could do this could be to allow a list of never-index header names as options whenever headers are specified... e.g.

stream.respond({
  'content-type': 'text/plain',
  'abc': ['value 1', 'value 2']
}, { neverIndex: ['abc'] });

Each method that accepts headers would need to be updated to accept an options object. This seems like the most ergonomic way to go.

@jasnell

@jasnell Just for context, I am already working on this :)

@jasnell

@jasnell ~~Personally, I prefer option #2.~~ Whoops! Realized there's only one option. 😄 It's similar to HTTP1 and makes never-index an "upgraded" option.

But, I think there's a theoretical possibility that needs to be explored. What if you want some headers to be indexed, and some not that are of the same header-field name? You might want to do:

stream.respond({
  'content-type': 'application/json',
  'set-cookie': myArrayOfRegularCookies
}, {
  waitForTrailers: true,
  sensitiveHeaders: {
    'set-cookie': myArrayOfSensitiveCookies
 }
});

PS: I use the term "sensitive" because one of the names the spec refers to them by:

Implementations can also choose to protect sensitive header fields by not compressing them and instead encoding their value as literals.

If we want to go with that kind of approach, a Symbol-based option may be better...

const { senstiveHeaderSymbol } = require('http2');

stream.respond({
  'content-type': 'text/plain',
  'set-cookie': ['a', 'b'],
  [sensitiveHeaderSymbol]: {
    'set-cookie': ['c', 'd']
  }
}, {
  waitForTrailers: true
});

Fwiw, I’m taking the Symbol-based approach (because I think information about headers should be passed in the headers object), but I’m not sure if we really want this kind of subdivision – if one of the cookie headers is sensitive, it’s probably okay to mark the others as sensitive as well.

http2: add support for sensitive headers

Navigation Menu

Repository navigation

http2: support adding never-index header fields #34091

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

http2: support adding never-index header fields #34091

Description

Activity

jasnell commented on Jun 30, 2020

addaleax commented on Jun 30, 2020

clshortfuse commented on Jun 30, 2020

jasnell commented on Jun 30, 2020

addaleax commented on Jun 30, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions