Web 推送协议

我们已经了解了如何使用库来触发推送消息，但这些库到底在做什么？

它们会发出网络请求，同时确保这些请求采用正确的格式。定义此网络请求的规范是 Web 推送协议。

本部分概述了服务器如何使用应用服务器密钥标识自身，以及如何发送加密载荷和关联数据。

这不是 Web 推送的亮点，我也不是加密专家，但让我们逐一了解一下，因为了解这些库在后台执行的操作会很有用。

应用服务器密钥

当用户订阅时，我们会传入一个 applicationServerKey。此密钥会传递给推送服务，用于检查订阅用户的应用是否也是触发推送消息的应用。

触发推送消息时，我们会发送一组标头，以便推送服务对应用进行身份验证。（这由 VAPID 规范定义。）

那么，这一切究竟意味着什么？具体会发生什么？以下是应用服务器身份验证的步骤：

1. 应用服务器使用其应用私钥对一些 JSON 信息进行签名。
2. 这些经过签名的信息会作为 POST 请求中的标头发送到推送服务。
3. 推送服务会使用从 pushManager.subscribe() 收到的已存储公钥，检查收到的信息是否由与该公钥相关的私钥签名。请注意：公钥是传递到订阅调用的 applicationServerKey。
4. 如果签名信息有效，推送服务会将推送消息发送给用户。

下面是此类信息流的一个示例。（请注意左下角的图例，它表示公钥和私钥。）

添加到请求标头中的“签名信息”是 JSON Web 令牌。

JSON Web 令牌

JSON Web 令牌（简称 JWT）是一种向第三方发送消息的方式，以便接收方可以验证发送方。

当第三方收到消息时，他们需要获取发送者的公钥，并使用该公钥验证 JWT 的签名。如果签名有效，则 JWT 必须已使用匹配的私钥进行签名，因此必须来自预期的发送者。

jwt.io/ 上有许多库可以为您执行签名，建议您尽可能使用这些库。为确保完整性，我们来看看如何手动创建签名 JWT。

Web 推送和已签名的 JWT

签名的 JWT 只是一个字符串，但可以将其视为由点连接的三个字符串。

前两个字符串（JWT 信息和 JWT 数据）是经过 base64 编码的 JSON 片段，这意味着它们是公开可读的。

第一个字符串是关于 JWT 本身的信息，指明了创建签名所用的算法。

Web 推送的 JWT 信息必须包含以下信息：

{
  "typ": "JWT",
  "alg": "ES256"
}

第二个字符串是 JWT 数据。这会提供有关 JWT 的发送者、目标对象和有效期的信息。

对于网页推送，数据将采用以下格式：

{
  "aud": "https://some-push-service.org",
  "exp": "1469618703",
  "sub": "mailto:example@web-push-book.org"
}

aud 值是“受众群体”，即 JWT 的目标对象。对于 Web 推送，受众群体是推送服务，因此我们将其设置为推送服务的来源。

exp 值是 JWT 的到期时间，这可以防止窥探者在拦截 JWT 后重复使用它。过期时间是以秒为单位的时间戳，且不得超过 24 小时。

在 Node.js 中，使用以下代码设置到期时间：

Math.floor(Date.now() / 1000) + 12 * 60 * 60;

之所以是 12 小时而不是 24 小时，是为了避免发送应用与推送服务之间因时钟差异而出现任何问题。

最后，sub 值必须是网址或 mailto 电子邮件地址。 这样一来，如果推送服务需要联系发送者，就可以从 JWT 中找到联系信息。（这就是 web-push 库需要电子邮件地址的原因）。

与 JWT 信息一样，JWT 数据也编码为网址安全的 base64 字符串。

第三个字符串（签名）是前两个字符串（JWT 信息和 JWT 数据）通过点字符连接（我们称之为“未签名令牌”）并进行签名的结果。

签名过程需要使用 ES256 对“未签名的令牌”进行加密。根据 JWT 规范，ES256 是“使用 P-256 曲线和 SHA-256 哈希算法的 ECDSA”的简称。使用 Web Crypto，您可以像这样创建签名：

// Utility function for UTF-8 encoding a string to an ArrayBuffer.
const utf8Encoder = new TextEncoder('utf-8');

// The unsigned token is the concatenation of the URL-safe base64 encoded
// header and body.
const unsignedToken = .....;

// Sign the |unsignedToken| using ES256 (SHA-256 over ECDSA).
const key = {
  kty: 'EC',
  crv: 'P-256',
  x: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(1, 33)),
  y: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(33, 65)),
  d: window.uint8ArrayToBase64Url(applicationServerKeys.privateKey),
};

// Sign the |unsignedToken| with the server's private key to generate
// the signature.
return crypto.subtle.importKey('jwk', key, {
  name: 'ECDSA', namedCurve: 'P-256',
}, true, ['sign'])
.then((key) => {
  return crypto.subtle.sign({
    name: 'ECDSA',
    hash: {
      name: 'SHA-256',
    },
  }, key, utf8Encoder.encode(unsignedToken));
})
.then((signature) => {
  console.log('Signature: ', signature);
});

推送服务可以使用应用服务器公钥来验证 JWT，以解密签名并确保解密后的字符串与“未签名令牌”（即 JWT 中的前两个字符串）相同。

已签名的 JWT（即通过英文句点连接的所有三个字符串）会作为 Authorization 标头发送到 Web 推送服务，并在前面加上 WebPush，如下所示：

Authorization: 'WebPush [JWT Info].[JWT Data].[Signature]';

Web 推送协议还规定，必须在 Crypto-Key 标头中以网址安全的 base64 编码字符串形式发送应用服务器公钥，并在其前面加上 p256ecdsa=。

Crypto-Key: p256ecdsa=[URL Safe Base64 Public Application Server Key]

载荷加密

接下来，我们来看看如何通过推送消息发送载荷，以便我们的 Web 应用在收到推送消息时可以访问收到的数据。

任何使用过其他推送服务的人都会提出一个常见问题：为什么需要对 Web 推送载荷进行加密？对于原生应用，推送消息可以纯文本形式发送数据。

Web 推送的优势之一在于，由于所有推送服务都使用相同的 API（Web 推送协议），开发者无需关心推送服务是谁。我们可以以正确的格式发出请求，并期望发送推送消息。这种方法的缺点是，开发者可能会向不可信的推送服务发送消息。通过加密载荷，推送服务无法读取发送的数据。只有浏览器可以解密这些信息。这可以保护用户的数据。

载荷的加密在消息加密规范中定义。

在了解加密推送消息载荷的具体步骤之前，我们应该先介绍一些在加密过程中会用到的技术。（非常感谢 Mat Scales 撰写的关于推送加密的精彩文章。）

ECDH 和 HKDF

ECDH 和 HKDF 都会在整个加密过程中使用，并且都有助于实现加密信息的目的。

ECDH：椭圆曲线迪菲-赫尔曼密钥交换

假设有两个人想要分享信息，分别是 Alice 和 Bob。 Alice 和 Bob 都有自己的公钥和私钥。Alice 和 Bob 彼此共享公钥。

使用 ECDH 生成的密钥有一个实用属性：Alice 可以使用自己的私钥和 Bob 的公钥来创建密钥值“X”。Bob 也可以执行相同的操作，使用自己的私钥和 Alice 的公钥独立创建相同的值“X”。这样，“X”就成了共享密钥，而 Alice 和 Bob 只需共享各自的公钥。现在，Bob 和 Alice 可以使用“X”来加密和解密他们之间的消息。

据我所知，ECDH 定义了曲线的属性，这些属性允许通过“特征”来生成共享密钥“X”。

以上是对 ECDH 的简要说明；如需了解详情，建议您观看更详细的 ECDH 概览视频。

在代码方面，大多数语言/平台都附带了可轻松生成这些密钥的库。

在 Node 中，我们会执行以下操作：

const keyCurve = crypto.createECDH('prime256v1');
keyCurve.generateKeys();

const publicKey = keyCurve.getPublicKey();
const privateKey = keyCurve.getPrivateKey();

HKDF：基于 HMAC 的密钥派生函数

维基百科对 HKDF 有简要说明：

HKDF 是一种基于 HMAC 的密钥派生函数，可将任何弱密钥材料转换为强加密密钥材料。例如，它可用于将 Diffie Hellman 交换的共享密钥转换为适合用于加密、完整性检查或身份验证的密钥材料。

从本质上讲，HKDF 会接受不太安全的输入，并使其更安全。

定义此加密的规范要求使用 SHA-256 作为哈希算法，并且 Web 推送中 HKDF 的生成密钥不应超过 256 位（32 字节）。

在 Node 中，可以按如下方式实现：

// Simplified HKDF, returning keys up to 32 bytes long
function hkdf(salt, ikm, info, length) {
  // Extract
  const keyHmac = crypto.createHmac('sha256', salt);
  keyHmac.update(ikm);
  const key = keyHmac.digest();

  // Expand
  const infoHmac = crypto.createHmac('sha256', key);
  infoHmac.update(info);

  // A one byte long buffer containing only 0x01
  const ONE_BUFFER = new Buffer(1).fill(1);
  infoHmac.update(ONE_BUFFER);

  return infoHmac.digest().slice(0, length);
}

感谢 Mat Scale 的文章提供了此示例代码。

这大致涵盖了 ECDH 和 HKDF。

ECDH 是一种安全地共享公钥并生成共享密钥的方法。HKDF 是一种将不安全材料 转换为安全材料的方法

这将在加密载荷期间使用。接下来，我们来看看输入内容以及加密方式。

输入

如果我们想向用户发送包含载荷的推送消息，需要以下三个输入：

1. 载荷本身。
2. PushSubscription 中的 auth 密钥。
3. PushSubscription 中的 p256dh 键。

我们已经看到从 PushSubscription 中检索 auth 和 p256dh 值，但为了快速提醒，对于订阅，我们需要以下值：

subscription.toJSON().keys.auth;
subscription.toJSON().keys.p256dh;

subscription.getKey('auth');
subscription.getKey('p256dh');

auth 值应被视为密钥，不得在应用外部共享。

p256dh 密钥是公钥，有时称为客户端公钥。在这里，我们将 p256dh 称为订阅公钥。订阅公钥由浏览器生成。浏览器会保密私钥，并使用私钥解密载荷。

这三个值（auth、p256dh 和 payload）需要作为输入，加密过程的结果将是加密的载荷、salt 值和仅用于加密数据的公钥。

Salt

盐需要是 16 字节的随机数据。在 NodeJS 中，我们会执行以下操作来创建盐：

const salt = crypto.randomBytes(16);

公钥/私钥

公钥和私钥应使用 P-256 椭圆曲线生成，我们在 Node 中可以这样做：

const localKeysCurve = crypto.createECDH('prime256v1');
localKeysCurve.generateKeys();

const localPublicKey = localKeysCurve.getPublicKey();
const localPrivateKey = localKeysCurve.getPrivateKey();

我们将这些密钥称为“本地密钥”。它们仅用于加密，与应用服务器密钥无关。

有了载荷、身份验证密钥和订阅公钥作为输入，再加上新生成的盐和一组本地密钥，我们就可以开始进行加密了。

共享密钥

第一步是使用订阅公钥和我们的新私钥创建共享密钥（还记得 Alice 和 Bob 的 ECDH 解释吗？就是这么简单）。

const sharedSecret = localKeysCurve.computeSecret(
  subscription.keys.p256dh,
  'base64',
);

此密钥将在下一步中用于计算伪随机密钥 (PRK)。

伪随机密钥

伪随机密钥 (PRK) 是推送订阅的身份验证密钥和我们刚刚创建的共享密钥的组合。

const authEncBuff = new Buffer('Content-Encoding: auth\0', 'utf8');
const prk = hkdf(subscription.keys.auth, sharedSecret, authEncBuff, 32);

您可能想知道 Content-Encoding: auth\0 字符串有什么用。 简而言之，它没有明确的用途，尽管浏览器可以解密收到的消息并查找预期的内容编码。\0 会向缓冲区末尾添加一个值为 0 的字节。这是解密消息的浏览器所期望的，浏览器会期望内容编码有这么多字节，后跟一个值为 0 的字节，再后跟加密数据。

我们的伪随机密钥只是通过 HKDF 运行身份验证、共享密钥和一段编码信息（即使其加密强度更高）。

上下文

“上下文”是一组字节，稍后会在加密浏览器中用于计算两个值。它本质上是一个字节数组，其中包含订阅公钥和本地公钥。

const keyLabel = new Buffer('P-256\0', 'utf8');

// Convert subscription public key into a buffer.
const subscriptionPubKey = new Buffer(subscription.keys.p256dh, 'base64');

const subscriptionPubKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = subscriptionPubKey.length;

const localPublicKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = localPublicKey.length;

const contextBuffer = Buffer.concat([
  keyLabel,
  subscriptionPubKeyLength.buffer,
  subscriptionPubKey,
  localPublicKeyLength.buffer,
  localPublicKey,
]);

最终的上下文缓冲区是一个标签、订阅公钥中的字节数、密钥本身、本地公钥中的字节数，然后是密钥本身。

有了这个上下文值，我们就可以在创建 Nonce 和内容加密密钥 (CEK) 时使用它。

内容加密密钥和 Nonce

nonce 是一个可防止重放攻击的值，因为它只能使用一次。

内容加密密钥 (CEK) 是最终用于加密载荷的密钥。

首先，我们需要为 Nonce 和 CEK 创建数据字节，这只是一个内容编码字符串，后跟我们刚刚计算的上下文缓冲区：

const nonceEncBuffer = new Buffer('Content-Encoding: nonce\0', 'utf8');
const nonceInfo = Buffer.concat([nonceEncBuffer, contextBuffer]);

const cekEncBuffer = new Buffer('Content-Encoding: aesgcm\0');
const cekInfo = Buffer.concat([cekEncBuffer, contextBuffer]);

此信息通过 HKDF 运行，将盐和 PRK 与 nonceInfo 和 cekInfo 结合使用：

// The nonce should be 12 bytes long
const nonce = hkdf(salt, prk, nonceInfo, 12);

// The CEK should be 16 bytes long
const contentEncryptionKey = hkdf(salt, prk, cekInfo, 16);

这样，我们就可以获得 Nonce 和内容加密密钥。

执行加密

现在我们有了内容加密密钥，可以加密载荷了。

我们使用内容加密密钥作为密钥，并使用 Nonce 作为初始化向量，创建一个 AES128 加密。

在 Node 中，此操作如下所示：

const cipher = crypto.createCipheriv(
  'id-aes128-GCM',
  contentEncryptionKey,
  nonce,
);

在加密载荷之前，我们需要定义要添加到载荷前面的填充量。我们之所以要添加填充，是因为这样可以防止窃听者根据载荷大小确定消息“类型”。

您必须添加两个字节的内边距，以指示任何额外内边距的长度。

例如，如果您未添加任何填充，则会有两个值为 0 的字节，即不存在填充，在这两个字节之后，您将读取载荷。如果您添加了 5 个字节的填充，则前两个字节的值将为 5，因此使用方将再读取 5 个字节，然后开始读取载荷。

const padding = new Buffer(2 + paddingLength);
// The buffer must be only zeros, except the length
padding.fill(0);
padding.writeUInt16BE(paddingLength, 0);

然后，我们通过此密码运行填充和载荷。

const result = cipher.update(Buffer.concat(padding, payload));
cipher.final();

// Append the auth tag to the result -
// https://nodejs.org/api/crypto.html#crypto_cipher_getauthtag
const encryptedPayload = Buffer.concat([result, cipher.getAuthTag()]);

现在，我们已经获得了加密载荷。耶！

剩下的就是确定如何将此载荷发送到推送服务。

加密的载荷标头和正文

如需将此加密载荷发送到推送服务，我们需要在 POST 请求中定义一些不同的标头。

加密标头

“Encryption”标头必须包含用于加密载荷的盐。

16 字节的盐应采用 base64 网址安全编码，并添加到 Encryption 标头中，如下所示：

Encryption: salt=[URL Safe Base64 Encoded Salt]

Crypto-Key 标头

我们看到，在“应用服务器密钥”部分下，Crypto-Key 标头用于包含应用服务器公钥。

此标头还用于共享用于加密载荷的本地公钥。

生成的标头如下所示：

Crypto-Key: dh=[URL Safe Base64 Encoded Local Public Key String]; p256ecdsa=[URL Safe Base64 Encoded Public Application Server Key]

内容类型、长度和编码标头

Content-Length 标头是加密载荷中的字节数。“Content-Type”和“Content-Encoding”标头是固定值。 如下所示。

Content-Length: [Number of Bytes in Encrypted Payload]
Content-Type: 'application/octet-stream'
Content-Encoding: 'aesgcm'

设置这些标头后，我们需要将加密载荷作为请求的正文发送。请注意，Content-Type 设置为 application/octet-stream。这是因为加密载荷必须作为字节流发送。

在 NodeJS 中，我们会这样做：

const pushRequest = https.request(httpsOptions, function(pushResponse) {
pushRequest.write(encryptedPayload);
pushRequest.end();

还有其他标头？

我们已经介绍了用于 JWT/应用服务器密钥的标头（即如何通过推送服务识别应用），以及用于发送加密载荷的标头。

推送服务还会使用其他标头来更改已发送邮件的行为。其中一些标头是必需的，而其他标头是可选的。

TTL 标头

必需

TTL（或存留时间）是一个整数，用于指定您希望推送消息在推送服务中存留多少秒后再传送。TTL 过期后，消息将从推送服务队列中移除，并且不会递送。

TTL: [Time to live in seconds]

如果您将 TTL 设置为零，推送服务会尝试立即传送消息，但如果无法访问设备，您的消息会立即从推送服务队列中丢弃。

从技术上讲，推送服务可以根据需要缩短推送消息的 TTL。您可以通过检查推送服务响应中的 TTL 标头来判断是否发生了这种情况。

主题

可选

主题是字符串，如果待处理消息与新消息的主题名称匹配，则可以使用新消息替换待处理消息。

在设备离线时发送多条消息，而您只希望用户在设备开机时看到最新消息的情况下，此功能非常有用。

紧急情况

可选

紧急程度向推送服务表明消息对用户的重要性。推送服务可以使用此信息，在电池电量不足时仅针对重要消息唤醒设备，从而帮助延长用户设备的电池续航时间。

标头值的定义如下所示。默认值为 normal。

Urgency: [very-low | low | normal | high]

Everything together

如果您对这一切的工作原理还有其他疑问，可以随时在 web-push-libs 组织中查看库如何触发推送消息。

获得加密载荷和上述标头后，您只需在 PushSubscription 中向 endpoint 发出 POST 请求即可。

那么，我们该如何处理此 POST 请求的响应呢？

推送服务的响应

向推送服务发出请求后，您需要检查响应的状态代码，因为该代码会告诉您请求是否成功。

您还可以参阅网络推送标准 (RFC8030)，详细了解 HTTP 状态代码。

下一步做什么

• Web 推送通知概览
• 推送的工作原理
• 为用户订阅
• 权限用户体验
• 使用 Web 推送库发送消息
• Web 推送协议
• 处理推送事件
• 显示通知
• 通知行为
• 常见通知模式
• 推送通知常见问题解答
• 常见问题和报告错误

Codelab

• 构建推送通知客户端
• 构建推送通知服务器