O protocolo de push na Web

Já vimos como uma biblioteca pode ser usada para acionar mensagens push, mas o que exatamente essas bibliotecas estão fazendo?

Eles estão fazendo solicitações de rede, garantindo que elas tenham o formato correto. A especificação que define essa solicitação de rede é o Protocolo de push da Web.

Diagrama de envio de uma mensagem push do servidor para um serviço push

Esta seção descreve como o servidor pode se identificar com o de servidor e como o payload criptografado e os dados associados são enviados.

Esse não é bem o push da Web, e não sou especialista em criptografia, mas vamos analisar cada parte, já que é útil saber o que essas bibliotecas estão fazendo nos bastidores.

Chaves do servidor de aplicativos

Quando inscrevemos um usuário, transmitimos um applicationServerKey. Essa chave é transmitida para o serviço push e usada para verificar se o aplicativo que inscreveu o usuário também é o que está acionando as mensagens push.

Quando acionamos uma mensagem push, enviamos um conjunto de cabeçalhos que enviamos que permitir que o serviço de push autentique o aplicativo. Isso é definido conforme as especificações VAPID.

O que tudo isso realmente significa e o que acontece exatamente? Bem, estas são as etapas seguidas para Autenticação do servidor de aplicativos:

  1. O servidor de aplicativos assina algumas informações JSON com a chave privada do aplicativo.
  2. Essas informações assinadas são enviadas ao serviço de push como um cabeçalho em uma solicitação POST.
  3. O serviço de push usa a chave pública armazenada da qual recebeu pushManager.subscribe() para verificar se as informações recebidas estão assinadas por a chave privada relacionada à chave pública. Lembre-se: a chave pública é o applicationServerKey transmitido para a chamada de inscrição.
  4. Se as informações assinadas forem válidas, o serviço de push vai enviar a mensagem de push ao usuário.

Confira abaixo um exemplo desse fluxo de informações. Observe a legenda no canto inferior esquerdo para indicar chaves públicas e privadas.

Ilustração de como a chave privada do servidor do aplicativo é usada ao enviar uma mensagem

As "informações assinadas" adicionadas a um cabeçalho na solicitação são um token da Web JSON.

Token da Web JSON

Um token Web JSON (ou JWT, para abreviar) é uma forma de enviar uma mensagem para terceiros, de modo que o destinatário possa validar quem a enviou.

Quando um terceiro recebe uma mensagem, ele precisa solicitar os remetentes chave pública e usá-la para validar a assinatura do JWT. Se o a assinatura é válida, então o JWT deve ter sido assinado com o chave privada, portanto, precisa ser do remetente esperado.

Há várias bibliotecas em https://jwt.io/ (em inglês) que fazer a assinatura por você, e é recomendável conseguem. Para completar, vamos conferir como criar manualmente um JWT assinado.

Web push e JWTs assinados

Um JWT assinado é apenas uma string, mas pode ser entendida como três strings unidas por pontos.

Ilustração das strings em um JSON Web Token

A primeira e a segunda string (as informações e os dados do JWT) são partes do JSON codificadas em base64, o que significa que são legíveis publicamente.

A primeira string são informações sobre o próprio JWT, indicando qual algoritmo foi usado para criar a assinatura.

As informações do JWT para push da Web precisam conter as seguintes informações:

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

A segunda string são os dados JWT. Ele fornece informações sobre o remetente do JWT, para quem ele é destinado e por quanto tempo ele é válido.

Para push na Web, os dados teriam este formato:

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

O valor de aud é o "público-alvo", ou seja, o público-alvo do JWT. Para o push da Web, o público-alvo é o serviço de push. Por isso, definimos como a origem do serviço de push.

O valor exp é a expiração do JWT, isso evita que invasões sejam reutilizar um JWT se interceptá-lo. A expiração é um carimbo de data e hora segundos e não deve ser mais de 24 horas.

No Node.js, a expiração é definida usando:

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

O tempo é de 12 horas, e não 24 horas, para evitar problemas com diferenças de relógio entre o aplicativo de envio e o serviço push.

Por fim, o valor sub precisa ser um URL ou um endereço de e-mail mailto. Dessa forma, se um serviço push precisar entrar em contato com o remetente, ele poderá encontrar dados de contato do JWT. É por isso que a biblioteca de push da Web precisava de um endereço de e-mail.

Assim como as informações do JWT, os dados do JWT são codificados como uma base64 segura de URL fio.

A terceira string, a assinatura, é o resultado de pegar as duas primeiras strings (as informações e os dados do JWT), juntá-las com um caractere de ponto, que vamos chamar de "token não assinado", e assinar.

O processo de assinatura requer a criptografia do "token não assinado" usando ES256. De acordo com a especificação do JWT, ES256 é a abreviação de "ECDSA usando a curva P-256 e o algoritmo de hash SHA-256". Com a criptografia da Web, é possível criar a assinatura da seguinte maneira:

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

Um serviço push pode validar um JWT usando a chave pública do servidor de aplicativos para descriptografar a assinatura e garantir que a string descriptografada seja a mesma como o "token não assinado", Ou seja, as duas primeiras strings no JWT.

O JWT assinado (ou seja, as três strings unidas por pontos) é enviado para a Web push como o cabeçalho Authorization com WebPush como prefixo:

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

O protocolo de push da Web também declara que a chave do servidor de aplicativos pública precisa ser enviada no cabeçalho Crypto-Key como uma string codificada em base64 segura para URL com p256ecdsa= no início.

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

A criptografia de payload

A seguir, vamos analisar como podemos enviar um payload com uma mensagem push para que, quando nosso app da Web recebe uma mensagem push, ele pode acessar os dados recebidos.

Uma pergunta comum que surge de quem já usou outros serviços de push é por que o payload de push da Web precisa ser criptografado? Com apps nativos, as mensagens push podem enviar dados como texto simples.

Parte da beleza do push da Web é que, como todos os serviços de push usam a mesma API (o protocolo de push da Web), os desenvolvedores não precisam se preocupar com quem é o serviço de push. Podemos fazer uma solicitação no formato correto e esperar que uma mensagem de push seja enviada. A desvantagem disso é que os desenvolvedores podem enviar mensagens para um serviço push que não é confiável. Ao cifrar o payload, um serviço push não pode ler os dados enviados. Somente o navegador pode descriptografar as informações. Isso protege os dados dados.

A criptografia do payload é definida no pacote Message Encryption spec.

Antes de conferir as etapas específicas para criptografar um payload de mensagens push, vamos abordar algumas técnicas que serão usadas na de desenvolvimento de software. (Grande ponta do chapéu para Mat Scales por seu excelente artigo sobre push encryption.)

ECDH e HKDF

O ECDH e o HKDF são usados durante o processo de criptografia e oferecem benefícios para criptografar informações.

ECDH: troca de chaves de curva elíptica Diffie-Hellman

Imagine que você tem duas pessoas que querem compartilhar informações, Alice e Bob. Alice e Bob têm chaves públicas e privadas próprias. Alice e Bob compartilham as chaves públicas entre si.

A propriedade útil das chaves geradas com ECDH é que Alice pode usar chave privada e a chave pública de Bob para criar o valor secreto "X". Bob pode fazer o mesmo, usando a chave privada dele e a chave pública de Alice para criar de forma independente o mesmo valor "X". Isso faz com que "X" seja um segredo compartilhado, e Alice e Bob só precisam compartilhar a chave pública. Agora Bob e Alice podem usar "X" para criptografar e descriptografar mensagens entre eles.

Até onde sei, o ECDH define as propriedades das curvas que permitem esse "atributo" de criar uma senha secreta "X".

Esta é uma explicação de alto nível sobre ECDH. Se quiser saber mais, recomendo assistir este vídeo.

Em termos de código, a maioria das linguagens / plataformas vem com bibliotecas para facilitar fácil de gerar essas chaves.

No nó, faremos o seguinte:

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

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

HKDF: função de derivação de chaves baseada em HMAC

A Wikipédia tem uma descrição sucinta da HKDF:

HKDF é uma função de derivação de chaves baseada em HMAC que transforma qualquer chave fraca em materiais de chave com criptografia forte. Ele pode ser usado, por exemplo, para converter chaves secretas compartilhadas trocadas por Diffie-Hellman em material de chave adequado para uso em criptografia, verificação de integridade ou autenticação.

Em essência, o HKDF vai usar entradas que não são particularmente seguras e as tornar mais seguras.

A especificação que define essa criptografia exige o uso do SHA-256 como nosso algoritmo de hash. e as chaves resultantes de HKDF no push da Web não podem ter mais de 256 bits (32 bytes).

No node, isso pode ser implementado assim:

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

Dica para o artigo de Mat Scale para este código de exemplo.

Isso cobre vagamente o ECDH. e HKDF.

O ECDH é uma maneira segura de compartilhar chaves públicas e gerar uma senha secreta. O HKDF é uma maneira de tornar o material não seguro seguro.

Ele será usado durante a criptografia do payload. A seguir, vamos conferir o que consideramos e como eles são criptografados.

Entradas

Para enviar uma mensagem push a um usuário com um payload, precisamos de três entradas:

  1. O payload em si.
  2. O secret auth do PushSubscription.
  3. A chave p256dh do PushSubscription.

Vimos os valores auth e p256dh serem recuperados de um PushSubscription, mas para uma Lembre-se, para uma assinatura, precisaríamos destes valores:

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

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

O valor auth precisa ser tratado como um secret e não ser compartilhado fora do aplicativo.

A chave p256dh é uma chave pública, às vezes chamada de chave pública do cliente. Aqui chamaremos p256dh de chave pública de assinatura. A chave pública de assinatura é gerada pelo navegador. O navegador manterá a chave privada em segredo e a usará para descriptografar a payload.

Esses três valores, auth, p256dh e payload, são necessários como entradas, e o resultado do processo de criptografia será o payload criptografado, um valor de sal e uma chave pública usada apenas para criptografar os dados.

Sal

O "salt" precisa ter 16 bytes de dados aleatórios. No NodeJS, faríamos o seguinte para criar um sal:

const salt = crypto.randomBytes(16);

Chaves públicas / privadas

As chaves pública e privada precisam ser geradas usando uma curva elíptica P-256, o que faremos no Node desta forma:

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

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

Chamaremos essas chaves de "chaves locais". Elas são usadas apenas para criptografia e têm não há nada a ver com chaves do servidor de aplicativos.

Com o payload, o secret de autenticação e a chave pública de assinatura como entradas e um novo sal e conjunto de chaves locais, estamos prontos para realizar a criptografia.

Chave secreta compartilhada

A primeira etapa é criar um segredo compartilhado usando a chave pública da assinatura e nossa nova chave privada (lembra da explicação do ECDH com Alice e Bob? Simples assim).

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

Isso é usado na próxima etapa para calcular a chave pseudoaleatória (PRK).

Chave pseudoaleatória

A chave pseudoaleatória (PRK, na sigla em inglês) é a combinação do código de autenticação da assinatura de push e a senha que acabamos de criar.

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

Você pode estar se perguntando para que serve a string Content-Encoding: auth\0. Em resumo, ele não tem uma finalidade clara, embora os navegadores possam descriptografar uma mensagem recebida e procurar a codificação de conteúdo esperada. O \0 adiciona um byte com um valor de 0 ao final do buffer. Isso é esperado pelos navegadores que descriptografam a mensagem, que esperam tantos bytes para a codificação de conteúdo, seguidos de um byte com valor 0, seguido dos dados criptografados.

Nossa chave pseudoaleatória simplesmente executa a autenticação, a senha secreta compartilhada e uma parte das informações de codificação por HKDF (ou seja, tornando-a mais forte criptograficamente).

Contexto

O "contexto" é um conjunto de bytes usado para calcular dois valores mais tarde no navegador de criptografia. Essencialmente, é uma matriz de bytes contendo a chave pública de assinatura e o chave pública local.

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,
]);

O buffer de contexto final é um rótulo, o número de bytes na chave pública da assinatura, seguida pela própria chave, pelo número de bytes da chave pública local e pela chave por conta própria.

Com esse valor de contexto, podemos usá-lo na criação de um valor de uso único e uma chave de criptografia de conteúdo (CEK).

Chave de criptografia de conteúdo e valor de uso único

Um valor de uso único é um valor que impede a repetição porque ele só deve ser usado uma vez.

A chave de criptografia de conteúdo (CEK, na sigla em inglês) é a chave que vai ser usada para criptografar nosso payload.

Primeiro, precisamos criar os bytes de dados para o valor de uso único e a CEK, que é simplesmente uma string de codificação de conteúdo seguida pelo buffer de contexto que acabamos de calcular:

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

Essa informação é executada pelo HKDF combinando o sal e PRK com o nonceInfo e 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);

Isso nos dá a chave de nonce e de criptografia de conteúdo.

Executar a criptografia

Agora que temos nossa chave de criptografia de conteúdo, podemos criptografar o payload.

Criamos uma cifra AES128 usando a chave de criptografia de conteúdo como a chave, e o valor de uso único é um vetor de inicialização.

No Node, isso é feito assim:

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

Antes de criptografar nosso payload, precisamos definir quanto padding queremos. para adicionar à frente do payload. O motivo pelo qual queremos adicionar padding é que impede o risco de que os bisbilhoteiros determinem "tipos" de mensagens com base no tamanho do payload.

Você precisa adicionar dois bytes de padding para indicar o comprimento de qualquer padding adicional.

Por exemplo, se você não tiver adicionado padding, terá dois bytes com valor 0, ou seja, não haverá padding, depois deles você lerá o payload. Se você tiver adicionado 5 bytes de preenchimento, os dois primeiros bytes terão um valor 5. Assim, o consumidor lerá cinco bytes adicionais e começará a ler o payload.

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

Em seguida, executamos o preenchimento e o payload por meio dessa cifra.

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()]);

Agora temos nosso payload criptografado. Eba!

Tudo o que resta é determinar como essa carga é enviada para o serviço de push.

Cabeçalhos e corpo do payload criptografado

Para enviar este payload criptografado ao serviço push, precisamos definir alguns cabeçalhos diferentes em nossa solicitação POST.

Cabeçalho de criptografia

A "criptografia" O cabeçalho precisa conter o salt usado para criptografar o payload.

O sal de 16 bytes precisa ser codificado em base64 e adicionado ao cabeçalho de criptografia, como este:

Encryption: salt=[URL Safe Base64 Encoded Salt]

Cabeçalho "Crypto-Key"

O cabeçalho Crypto-Key é usado na seção "Chaves do servidor do aplicativo" para conter a chave pública do servidor do aplicativo.

Esse cabeçalho também é usado para compartilhar a chave pública local usada para criptografar o payload.

O cabeçalho resultante vai ficar assim:

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

Cabeçalhos de tipo, comprimento e codificação de conteúdo

O cabeçalho Content-Length é o número de bytes no bloco payload. "Content-Type" e "Content-Encoding" os cabeçalhos são valores fixos. Confira abaixo.

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

Com esses cabeçalhos definidos, precisamos enviar o payload criptografado como o corpo da solicitação. O Content-Type está definido como application/octet-stream. Isso ocorre porque o payload criptografado precisa ser enviados como um fluxo de bytes.

No NodeJS, faremos isso da seguinte forma:

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

Mais cabeçalhos?

Cobrimos os cabeçalhos usados para JWT / chaves de servidor de aplicativos (ou seja, como identificar a aplicativo com o serviço de push) e abordamos os cabeçalhos usados para enviar uma mensagem payload.

Há outros cabeçalhos que os serviços de push usam para alterar o comportamento das mensagens enviadas. Alguns desses cabeçalhos são obrigatórios, e outros são opcionais.

Cabeçalho TTL

Obrigatório

TTL (ou time to live) é um número inteiro que especifica o número de segundos. você quer que a mensagem push fique no serviço de push antes de ser entregues. Quando o TTL expirar, a mensagem será removida do fila do serviço push e ele não será entregue.

TTL: [Time to live in seconds]

Se você definir um TTL como zero, o serviço de push vai tentar entregar a mensagem imediatamente. No entanto, se o dispositivo não puder ser alcançado, a mensagem será removida imediatamente da fila do serviço de push.

Tecnicamente, um serviço de push pode reduzir o TTL de uma mensagem push se deseja. Para saber se isso aconteceu, examine o cabeçalho TTL na resposta de um serviço push.

Tópico

Opcional

Tópicos são strings que podem ser usadas para substituir mensagens pendentes por uma nova mensagem se tiverem nomes de tópicos correspondentes.

Isso é útil nos casos em que várias mensagens são enviadas enquanto uma dispositivo está off-line e você realmente quer que um usuário veja apenas o último quando o dispositivo estiver ligado.

Urgência

Opcional

A urgência indica ao serviço de push a importância de uma mensagem para o usuário. Isso pode ser usado pelo serviço push para ajudar a conservar a duração da bateria do dispositivo de um usuário, acordando apenas para mensagens importantes quando a bateria estiver fraca.

O valor do cabeçalho é definido conforme mostrado abaixo. O valor padrão é normal.

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

Tudo junto

Se você tiver outras dúvidas sobre como tudo isso funciona, confira como as bibliotecas acionam mensagens push no web-push-libs org.

Quando você tiver um payload criptografado e os cabeçalhos acima, basta fazer uma solicitação POST. ao endpoint em uma PushSubscription.

O que fazemos com a resposta a essa solicitação POST?

Resposta do serviço de push

Depois de fazer uma solicitação para um serviço push, você precisa verificar o código de status da resposta, que vai informar se a solicitação foi bem-sucedida ou não.

Código de status Descrição
201 Criado. A solicitação para enviar uma mensagem push foi recebida e aceita.
429 Excesso de solicitações. Isso significa que o servidor de aplicativos atingiu uma taxa com um serviço de push. O serviço de push precisa incluir um cabeçalho "Retry-After" para indicar quanto tempo antes de outra solicitação ser feita.
400 Solicitação inválida. Isso geralmente significa que um dos cabeçalhos é inválido ou está formatado incorretamente.
404 Não encontrado Essa é uma indicação de que a assinatura expirou e não pode ser usado. Nesse caso, exclua "PushSubscription" e aguarde o cliente reinscrever o usuário.
410 Desapareceu. A assinatura não é mais válida e precisa ser removida do servidor de aplicativos. Isso pode ser reproduzido chamando `unsubscribe()` em uma `PushSubscription`.
413 O tamanho do payload é muito grande. O payload de tamanho mínimo que um serviço de push precisa O suporte é de 4.096 bytes (ou 4 kb).

Consulte também o padrão Web Push (RFC8030) para mais informações sobre os códigos de status HTTP.

A seguir

Codelabs