http2: support adding never-index header fields

[clshortfuse]

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:

• What flag to set for nghttp2
• How we compile a header from JS
• How we submit responses to nghttp2

It'll help diagnose #28632

[jasnell]

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.

[addaleax]

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

[clshortfuse]

@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.

[jasnell]

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
});

[addaleax]

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.