Web 推送协议

Matt Gaunt

我们已经了解了如何使用库触发推送消息,但这些库究竟在做什么?

它们会发出网络请求,同时确保此类请求的格式正确无误。定义此网络请求的规范是 Web 推送协议

从服务器向推送服务发送推送消息的示意图

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

这不是 Web Push 的亮点,我也不是加密方面的专家,但我们还是来看看各个部分,因为了解这些库在后台执行的操作很有用。

应用服务器密钥

为用户订阅时,我们会传入 applicationServerKey。此键会传递给推送服务,并用于检查订阅用户的应用是否也是触发推送消息的应用。

在触发推送消息时,我们会发送一组标头,以允许推送服务对应用进行身份验证。(这由 VAPID 规范定义。)

这究竟意味着什么?到底发生了什么?这些就是 应用服务器身份验证:

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

下面是此信息流的示例。(请注意左下角用于指示公钥和私钥的图例。)

发送
消息

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

JSON Web 令牌

JSON 网络令牌(简称 JWT)是一种 向第三方发送消息,以便接收方可以验证 发件人

第三方收到消息后,需要获取发件人公钥,并使用该公钥验证 JWT 的签名。如果 签名有效,则 JWT 必须使用匹配的签名 因此必须来自预期的发送者。

https://jwt.io/ 上有很多库 可以为您执行签名,我建议您 。为完整起见,我们来看看如何手动创建已签名的 JWT。

Web 推送和已签名的 JWT

已签名的 JWT 只是一个字符串,但可以将其视为由连接在一起的三个字符串 以英文句点表示

一张插图,显示 JSON Web 令牌中的字符串

第一个和第二个字符串(JWT 信息和 JWT 数据)是经过 base64 编码的 JSON 片段,这意味着它们是可供公开读取的。

第一个字符串是与 JWT 本身相关的信息,表明哪种算法 用于创建签名。

网络推送的 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 推送 audience 是推送服务,因此我们将其设置为推送的源站 服务

exp 值是 JWT 的失效时间,这可防止窥探者在拦截 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 spec,ES256 是“使用 P-256 曲线和 “SHA-256 哈希算法”。您可以使用网络加密来创建签名,如下所示:

// 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(即三个字符串,以点连接)作为带有 WebPush 前缀的 Authorization 标头发送到 Web 推送服务,如下所示:

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

网络推送协议还规定了应用服务器公钥 在 Crypto-Key 标头中以可在网址中安全使用的 base64 编码字符串形式发送, p256ecdsa= 前缀。

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

载荷加密

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

使用过其他推送服务的用户都会有一个常见问题,即为什么需要对网站推送载荷进行加密?对于原生应用,推送消息可以以纯文本形式发送数据。

Web Push 的优点之一在于,由于所有推送服务都使用相同的 API(Web Push 协议),因此开发者无需关心推送服务的提供方。我们可以使用正确的格式发出请求,并期望系统发送推送消息。缺点是,开发者可能会向不可信的推送服务发送消息。修改者 加密载荷,推送服务将无法读取发送的数据。 只有浏览器才能解密此类信息。这可以保护用户的 数据。

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

在介绍加密推送消息载荷的具体步骤之前, 我们应该介绍在加密过程中使用的一些技术 过程。(马特·斯凯尔斯发表了一篇关于推杆的优秀文章,向 Mat Scales 致敬 encryption.)

ECDH 和 HKDF

整个加密过程中都会用到 ECDH 和 HKDF, 目的是加密信息

ECDH:椭圆曲线 Diffie-Hellman 密钥交换

假设您有两个人想要共享信息,爱丽丝和小刚。 Alice 和 Bob 都有自己的公钥和私钥。Alice 和 Bob 彼此共享其公钥。

使用 ECDH 生成的密钥的有用属性是,Alice 可以使用她的 私钥和 Bob 的公钥来创建密钥值“X”。Bob 可以执行的操作 同样地,它会将他的私钥和 Alice 的公钥 创建相同的值“X”。这就使得“X”共享密钥 而爱丽丝和鲍勃只需分享他们的公钥即可。现在,Bob 和 Alice 可以使用“X”来加密和解密两者之间的消息。

据我所知,ECDH 定义了支持此“特征”的曲线的属性 创建共享密钥“X”的流程

以上是对 ECDH 的概要说明。如需了解详情,建议您观看此视频

在代码方面:大多数语言 / 平台都自带相应的库 可以轻松生成这些密钥。

在节点中,我们会执行以下操作:

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

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

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

维基百科对 HKDF 进行了简要说明:

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

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

定义此加密的规范要求使用 SHA-256 作为我们的哈希算法 并且在 Web 推送中生成的 HKDF 键不应超过 256 位 (32 个字节)。

在节点中,可以按如下方式实现:

// 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 Secret。
  3. PushSubscription 中的 p256dh 键。

我们已经看到了从 PushSubscription 检索 authp256dh 值的过程,但在此提醒一下,对于订阅,我们需要以下值:

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

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

auth 值应被视为机密信息,不得在应用之外分享。

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

这三个值(authp256dhpayload)需要作为输入和 加密的载荷、盐值和仅用于测试的公钥 对数据进行加密

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 的字节,接着是 加密数据。

我们的伪随机密钥只是运行身份验证、共享密钥和一段编码信息。 (即提高加密强度)。

上下文

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

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 和内容加密密钥。

执行加密

现在,我们有了内容加密密钥,可以对载荷进行加密了。

我们使用内容加密密钥作为密钥创建 AES128 加密算法,而 Nonce 是初始化矢量。

在 Node 中,可以通过以下方式实现:

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

在对载荷进行加密之前,我们需要定义要向载荷前面添加多少填充。我们想要添加内边距的原因 那就是可以防止窃听者确定 "类型"根据负载大小调整消息数量。

您必须添加两个填充字节,以指示任何额外填充的长度。

例如,如果未添加任何填充,则将有两个值为 0 的字节(即不存在任何填充),在这两个字节之后将读取载荷。如果您添加了 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()]);

现在,我们已经有了加密的载荷。耶!

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

加密载荷标头和正文

为了将此加密的载荷发送到推送服务,我们需要定义一些 使用不同的标头

加密标头

“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-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]

整合一切

如果您对所有这些工作原理还有其他疑问,可以随时访问 web-push-libs org,了解库如何触发推送消息。

有了加密的载荷和上述标头后,您只需发出 POST 请求即可 传递给 PushSubscription 中的 endpoint

那么,我们该如何处理对此 POST 请求的响应?

来自推送服务的响应

向推送服务发出请求后,您需要检查 因为这能看出请求是否成功 。

状态代码 说明
201 已创建。系统已收到并接受发送推送消息的请求。
429 请求数量过多。这意味着您的应用服务器已达到某个速率 使用推送服务进行限制推送服务应包含“重试之后”操作 标头来指示多久才能发出另一个请求。
400 请求无效。这通常表明您的某个标头无效 或格式不正确
404 未找到。这表示订阅已过期 因此无法使用。在这种情况下,您应该删除“PushSubscription” 并等待客户端重新订阅该用户。
410 已消失。订阅已失效,应从应用服务器中移除。您可以通过对 `PushSubscription` 调用 `unsubscribe()` 来重现此问题。
413 有效负载过大。推送服务必须支持的载荷大小下限为 4096 字节(或 4kb)。

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

下一步做什么

Codelab