Client-Cert HTTP Header - Transmitir informações do certificado do cliente da TLS terminando proxies reversos para aplicativos do servidor origin

Abstract

Este documento define o campo de cabeçalho HTTP que permite que um TLS rescindindo o proxy reverso transmita informações sobre o certificado cliente de uma conexão TLS autenticada mutuamente a um servidor de origem de forma comum e previsível.Client-Cert

Status deste Memorando

Este Rascunho da Internet é submetido em total conformidade com as disposições do BCP 78 e BCP 79.

Os rascunhos da Internet são documentos de trabalho da Força-Tarefa de Engenharia da Internet (IETF). Observe que outros grupos também podem distribuir documentos de trabalho como Rascunhos da Internet. A lista de Rascunhos da Internet atuais está em https://datatracker.ietf.org/drafts/current/.

Os rascunhos da Internet são documentos de rascunho válidos por um período máximo de seis meses e podem ser atualizados, substituídos ou obsoletos por outros documentos a qualquer momento. É inapropriado usar os Rascunhos da Internet como material de referência ou citá-los além de “trabalhar em andamento”.

Este Rascunho da Internet expirará em 18 de julho de 2020.

Aviso de Direitos Autorais

Direitos autorais (c) 2020 IETF Trust e as pessoas identificadas como autores do documento. Todos os direitos reservados.

Este documento está sujeito ao BCP 78 e às disposições legais do IETF Trust relativas aos documentos do IETF (https://trustee.ietf.org/license-info), em vigor na data de publicação deste documento. Por favor, revise esses documentos cuidadosamente, pois eles descrevem seus direitos e restrições em relação a este documento. Os componentes de código extraídos deste documento devem incluir o texto da Licença BSD Simplificada, conforme descrito na Seção 4.e das Disposições Legais de Confiança e são fornecidos sem garantia conforme descrito na Licença BSD Simplificada.

1. Introdução

Um padrão de implantação bastante comum para aplicativos HTTPS é ter a origem dos servidores de aplicativos HTTP sentados atrás de um proxy reverso que encerra as conexões TLS dos clientes. O proxy é acessível à internet e despacha solicitações do cliente para o servidor de origem apropriado dentro de uma rede privada ou protegida. Os servidores de origem não são diretamente acessíveis pelos clientes e só são acessíveis através do proxy reverso. Os detalhes de backend deste tipo de implantação são tipicamente opacos para clientes que fazem solicitações ao servidor proxy e vêem respostas como se tivessem se originado do próprio servidor proxy. Embora o HTTPS também seja geralmente empregado entre o proxy e o servidor de origem, a conexão TLS que o cliente estabelece para HTTPS é apenas entre si e o servidor proxy reverso.

O padrão de implantação é encontrado em várias variedades, como arquiteturas de nível n, redes de entrega de conteúdo, serviços de balanceamento de carga de aplicativos e controladores de entrada.

Embora não seja extremamente prevalente, a autenticação do certificado de cliente TLS às vezes é empregada e, nesses casos, o servidor de origem muitas vezes requer informações sobre o certificado do cliente para sua lógica de aplicação. Tal lógica pode incluir decisões de controle de acesso, registro de auditoria e vinculação de tokens ou cookies emitidos a um certificado e a respectiva validação de tais vinculações. Os detalhes específicos do certificado necessário também variam de acordo com os requisitos de inscrição. Para que esses tipos de implantações de aplicativos funcionem na prática, o proxy reverso precisa transmitir informações sobre o certificado do cliente para o servidor de aplicativos de origem. Uma maneira comum de essas informações serem transmitidas na prática hoje é usando cabeçalhos não padronizados para transportar o certificado (em alguma codificação) ou partes individuais da sua na solicitação HTTP que é despachada para o servidor de origem. Esta solução funciona até certo ponto, mas a interoperabilidade entre componentes desenvolvidos independentemente pode ser complicada ou até impossível dependendo das escolhas de implementação feitas respectivamente (como quais nomes de cabeçalho são usados ou são configuráveis, quais partes do certificado são expostas ou como o certificado é codificado). Uma abordagem padronizada para essa funcionalidade comumente poderia melhorar e simplificar a interoperabilidade entre as implementações.

Este documento aspira a padronizar um campo de cabeçalho HTTP chamado que um proxy reverso terminante TLS adiciona às solicitações que ele envia para os servidores de origem ou backend. O valor do cabeçalho contém o certificado do cliente da conexão TLS autenticada mutuamente entre o cliente e o proxy reverso, o que permite que o servidor de origem backend utilize o certificado em sua lógica de aplicação. O uso do cabeçalho, tanto o proxy reverso adicionando o cabeçalho quanto o servidor de origem que depende do cabeçalho para a lógica do aplicativo, devem ser opções de configuração dos respectivos sistemas, pois nem sempre serão aplicáveis.Client-Cert

1.1. Notação e Convenções de Requisitos

As palavras-chave “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHOULD”, “SHOULD”, “SHOULD”, “SHOULD”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY” e “OPTIONAL” neste documento devem ser interpretadas conforme descrito no BCP 14 [RFC2119] [RFC8174] quando, e somente quando, eles aparecem em todas as capitais, como mostrado aqui.

1.2. Terminologia

Frases como autenticação de certificado de cliente TLS ou TLS autenticada mutuamente são usadas ao longo deste documento para se referir ao processo pelo qual, além da autenticação normal do servidor TLS com um certificado, um cliente apresenta seu certificado X.509 [RFC5280] e comprova a posse da chave privada correspondente a um servidor ao negociar uma sessão TLS. Em versões contemporâneas do TLS [RFC8446] [RFC5246] isso exige que o cliente envie as mensagens Certificados e CertificadosVerificar durante o aperto de mão e que o servidor verifique as mensagens CertificateVerify e Finished.

2. HTTP Header Field and Processing Rules

2.1. Codificação

Os valores de campo do cabeçalho HTTP definidos aqui utilizam o seguinte formulário codificado.

Um certificado é representado no texto como um , que é o base64-codificado (Seção 4 de EncodedCertificate[RFC4648]) DER [ITU. X690] Certificado PKIX. O valor codificado NÃO deve incluir quaisquer quebras de linha, espaço branco ou outros caracteres adicionais. ABNF [RFC5234] sintaxe para é mostrado na figura abaixo.EncodedCertificate

 EncodedCertificate = 1*( DIGIT / ALPHA / "+" / "/" ) 0*2"=" 

 DIGIT = <Defined in Section B.1 of [RFC5234]>  ; A-Z / a-z
 ALPHA = <Defined in Section B.1 of [RFC5234]>  ; 0-9  

### 2.2. Campo de cabeçalho CLIENTE-Cert HTTP

No contexto de uma implantação de TTRP (Reverse Proxy, proxy reverso) do TLS, o TTRP disponibiliza o certificado de cliente TLS para o aplicativo backend com o seguinte campo de cabeçalho.

Cliente-Cert O certificado de cliente de entidade final como um valor.EncodedCertificate

O campo de cabeçalho definido aqui é apenas para uso em solicitações HTTP e NÃO deve ser usado em respostas HTTP. É um único valor de campo de cabeçalho HTTP definido na Seção 3.2 de Client-Cert[RFC7230], que NÃO deve ter uma lista de valores ou ocorrer várias vezes em uma solicitação.

2.3. Regras de processamento

Esta seção descreve as regras de processamento aplicáveis para um TTRP (Reverse Proxy, proxy reverso) que negociou uma conexão TLS autenticada mutuamente para transmitir o certificado do cliente a partir dessa conexão para os servidores de origem backend. O uso da técnica é ser uma opção de configuração ou implantação e as regras de processamento aqui descritas são para servidores que operam com essa opção habilitada.

Um TTRP negocia o uso de uma conexão TLS autenticada mutuamente com o cliente, como é descrito em [RFC8446] ou [RFC5246], e valida o certificado do cliente por sua apólice e autoridades de certificados confiáveis. Cada solicitação HTTP na conexão TLS subjacente são enviadas para o servidor de origem com as seguintes modificações:

• O certificado do cliente é colocado no campo de cabeçalho da solicitação despachada conforme definido na Seção 2.2.Client-Cert
• Qualquer ocorrência do cabeçalho na solicitação de entrada original DEVE ser removida ou substituída antes de encaminhar a solicitação.Client-Cert

Solicitações feitas sobre uma conexão TLS onde o uso da autenticação do certificado do cliente não foi negociado Deve ser higienizado removendo todo e qualquer campo de cabeçalho de ocorrências antes de despachar a solicitação para o servidor backend.Client-Cert

Proxies avançados e outros intermediários NÃO devem adicionar o cabeçalho às solicitações.Client-Cert

Os servidores de origem backend podem então usar o cabeçalho da solicitação para determinar se a conexão do cliente com o TTRP foi autenticada mutuamente e, se for o caso, o certificado apresentado pelo cliente.Client-Cert

3. Considerações de segurança

O cabeçalho descrito aqui permite que um servidor proxy reverso e backend ou origin funcione em conjunto como se, do ponto de vista do cliente, eles fossem uma única implantação do lado do servidor lógico de HTTPS sobre uma conexão TLS autenticada mutuamente. O uso do cabeçalho fora do caso de uso pretendido, no entanto, pode prejudicar as proteções oferecidas pela autenticação do certificado de cliente TLS. Portanto, devem ser tomadas medidas para evitar o uso não intencional, tanto no envio do cabeçalho quanto na dependência de seu valor.Client-Cert

Produzir e consumir o cabeçalho DEVE ser uma opção configurável, respectivamente, em um servidor proxy e backend reverso (ou aplicativo individual naquele servidor). A configuração padrão para ambos deve ser não usar o cabeçalho, exigindo assim um “opt-in” para a funcionalidade.Client-CertClient-Cert

Para evitar a injeção de cabeçalho, os servidores backend devem apenas aceitar o cabeçalho de proxies reversos confiáveis. E proxies reversos DEVEM higienizar a solicitação recebida antes de encaminhá-la, removendo ou substituindo quaisquer instâncias existentes do cabeçalho. Caso contrário, clientes arbitrários podem controlar o valor do cabeçalho como visto e usado pelo servidor backend. É importante notar que negligenciar a injeção de cabeçalho não “falha seguro” na medida em que a funcionalidade nominal ainda funcionará como esperado mesmo quando ações maliciosas forem possíveis. Como tal, recomenda-se um cuidado extra para garantir que o saneamento adequado do cabeçalho esteja em vigor.Client-Cert

A comunicação entre um servidor proxy reverso e backend precisa ser protegida contra escutas e modificações por partes não intencionais.

As opções de configuração e a higienização de solicitações são necessariamente funcionalmente dos respectivos servidores. Os outros requisitos podem ser atendidos de várias maneiras, que variam de acordo com implantações específicas. A comunicação entre um proxy reverso e um servidor de backend ou origem, por exemplo, pode ser autenticada de alguma forma com a inserção e o consumo do cabeçalho ocorrendo apenas nessa conexão. Alternativamente, a topologia de rede pode ditar uma rede privada de modo que o aplicativo backend só seja capaz de aceitar solicitações do proxy reverso e o proxy só pode fazer solicitações para esse servidor. Outras implantações que atendam aos requisitos aqui estabelecidos também são possíveis.Client-Cert

4. Considerações IANA

[[TBD se este rascunho progredir, registre o campo de cabeçalho HTTP no registro “Nomes permanentes de campo de cabeçalho de mensagem” definido em Client-Cert[RFC3864] ]]

5. Referências Normativas

6. Referências Informativas

Apêndice A. Exemplo

Em um exemplo hipotético em que um cliente TLS apresenta o cliente e o certificado intermediário da Figura 1 ao estabelecer uma conexão TLS autenticada mutuamente com o proxy reverso, o proxy enviaria o cabeçalho mostrado em {#example-header} para o backend. Observe que as quebras de linha e o espaço branco foram adicionados ao valor do campo de cabeçalho na Figura 2 apenas para fins de exibição e formatação.Client-Cert

-----BEGIN CERTIFICATE-----
MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJMZXQncyBB
dXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0yMDAx
MTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p
5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIw
ADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMC
BsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1w
bGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMje
SkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQswCQYDVQQGEwJVUzEbMBkG
A1UECgwSTGV0J3MgQXV0aGVudGljYXRlMSowKAYDVQQDDCFMZXQncyBBdXRoZW50
aWNhdGUgUm9vdCBBdXRob3JpdHkwHhcNMjAwMTE0MjEzMjMwWhcNMzAwMTExMjEz
MjMwWjA6MRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxB
IEludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJf+aA54
RC5pyLAR5yfXVYmNpgd+CGUTDp2KOGhc0gK91zxhHesEYkdXkpS2UN8Kati+yHtW
CV3kkhCngGyv7RqjZjBkMB0GA1UdDgQWBBRm3WjLa38lbEYCuiCPct0ZaSED2DAf
BgNVHSMEGDAWgBTEA2Q6eecKu9g9yb5glbkhhVINGDASBgNVHRMBAf8ECDAGAQH/
AgEAMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjOPQQDAgNJADBGAiEA5pLvaFwRRkxo
mIAtDIwg9D7gC1xzxBl4r28EzmSO1pcCIQCJUShpSXO9HDIQMUgH69fNDEMHXD3R
RX5gP7kuu2KGMg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICBjCCAaygAwIBAgIJAKS0yiqKtlhoMAoGCCqGSM49BAMCMFYxCzAJBgNVBAYT
AlVTMRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdGUxKjAoBgNVBAMMIUxldCdz
IEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvcml0eTAeFw0yMDAxMTQyMTI1NDVaFw00
MDAxMDkyMTI1NDVaMFYxCzAJBgNVBAYTAlVTMRswGQYDVQQKDBJMZXQncyBBdXRo
ZW50aWNhdGUxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRpY2F0ZSBSb290IEF1dGhv
cml0eTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABFoaHU+Z5bPKmGzlYXtCf+E6
HYj62fORaHDOrt+yyh3H/rTcs7ynFfGn+gyFsrSP3Ez88rajv+U2NfD0o0uZ4Pmj
YzBhMB0GA1UdDgQWBBTEA2Q6eecKu9g9yb5glbkhhVINGDAfBgNVHSMEGDAWgBTE
A2Q6eecKu9g9yb5glbkhhVINGDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQE
AwIBhjAKBggqhkjOPQQDAgNIADBFAiEAmAeg1ycKHriqHnaD4M/UDBpQRpkmdcRF
YGMg1Qyrkx4CIB4ivz3wQcQkGhcsUZ1SOImd/lq1Q0FLf09rGfLQPWDc
-----END CERTIFICATE-----

Figura 1: Cadeia de Certificados (com certificado de cliente em primeiro lugar)

Client-Cert: MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJM
 ZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0y
 MDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZI
 zj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p5Be5
 F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIwADAfBgNV
 HSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMCBsAwEwYDVR0l
 BAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1wbGUuY29tMAoGCCqG
 SM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMjeSkC3dFCOOB8TAiEAx/kH
 SB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=

Figura 2: Cabeçalho em HTTP Request to Origin Server

Apêndice B. Considerações Consideradas

B.1. Injeção de cabeçalho

Este rascunho exige que o proxy reverso higienize os cabeçalhos da solicitação recebida removendo ou substituindo quaisquer instâncias existentes do cabeçalho antes de despachar essa solicitação para o aplicativo backend. Caso contrário, um cliente poderia injetar seu próprio cabeçalho que pareceria ter vindo do proxy reverso. Embora inúmeros outros métodos de detecção/prevenção da injeção de cabeçalho sejam possíveis; como o uso de um valor secreto único como parte do nome ou valor do cabeçalho ou da aplicação de uma assinatura, HMAC ou AEAD, não há um mecanismo comum padronizado geral. O problema potencial da injeção de cabeçalho do cliente não é de todo exclusivo da funcionalidade deste rascunho e seria inapropriado para este rascunho definir uma solução única. Na ausência de uma solução padronizada genérica existente atualmente, despir/higienizar os cabeçalhos é o meio de proteção contra injeção de cabeçalho na prática atual. Higienizar os cabeçalhos é suficiente quando implementado corretamente e é requisito normativo da Seção 3.Client-CertClient-Cert

B.2. A extensão HTTP encaminhada

O campo de cabeçalho HTTP definido em Forwarded[RFC7239] permite que componentes proxy divulguem informações perdidas no processo de proxying. As informações de certificado do cliente TLS de preocupação com este rascunho poderiam ter sido comunicadas com um parâmetro de extensão para o campo de cabeçalho, no entanto, fazê-lo teria algumas desvantagens que este rascunho se esforçou para evitar. A sintaxe do cabeçalho permite informações sobre uma cadeia completa de solicitações HTTP proxied, enquanto o cabeçalho deste documento está preocupado apenas em transmitir informações sobre o certificado apresentado pelo cliente originário na conexão TLS com o proxy reverso (que aparece como o servidor da perspectiva desse cliente) para backend aplicativos. A sintaxe multi-hop do cabeçalho é expressiva, mas também mais complicada, o que tornaria o processamento mais complicado e, mais importante, tornaria adequadamente higienizar seu conteúdo conforme exigido pela Seção 3 para evitar a injeção de cabeçalho consideravelmente mais difícil e propensa a erros. Assim, este rascunho optou pela estrutura mais plana e direta de um único cabeçalho.ForwardedForwardedClient-CertForwardedClient-Cert

B.3. O Certificado Completo e Somente o Certificado Completo

Diferentes aplicativos terão requisitos variados sobre quais informações do certificado do cliente são necessárias, como nome distinto do assunto e/ou emissor, nome alternativo do assunto, número de série, informações de chave pública, impressão digital, etc.. Além disso, algumas aplicações como [I-D.ietf-oauth-mtls] fazer uso de todo o certificado. A fim de acomodar este último e garantir ampla aplicabilidade, não tentando escolher informações específicas do certificado, este rascunho optou por passar o certificado codificado completo como o valor do cabeçalho.Client-Cert

O aperto de mão e a validação do certificado (cadeia) do cliente da conexão TLS autenticada mutuamente é realizado por proxy reverso. Com a responsabilidade de validação do certificado caindo sobre o proxy, apenas o certificado de entidade final é passado para o backend - a Autoridade de Certificado raiz não está incluída nem são intermediários.

Apêndice C. Agradecimentos

O autor gostaria de agradecer aos seguintes indivíduos que contribuíram de várias maneiras que vão desde apenas ser geralmente favorável a trazer o rascunho para fornecer feedback ou conteúdo específico: Annabelle Backman, Benjamin Kaduk, Torsten Lodderstedt, Kathleen Moriarty, Mike Ounsworth, Matt Peterson, Justin Richer, Rich Salz, Rifaat Shekh-Yusef, Travis Spencer e Hans Zandbelt.

[[Por favor, deixe-me saber se você foi erroneamente omitido ou se você prefere não ser nomeado

Apêndice D. Histórico de documentos

[[Para ser removido pelo Editor RFC antes da publicação como um RFC (caso isso venha a acontecer) ]]

rascunho-bdc-algo-algo-certificado-01

• Use o formato RFC v3 ou morra tentando

rascunho-bdc-algo-algo-certificado-00

• Rascunho inicial após um tempo constrangido e apressado apresentação de secdispatch no IETF 106 em Cingapura com a recomendação de escrever um rascunho (no final da ata) e algumas pessoas expressando interesse apesar da apresentação bastante ruim

Endereço do autor

• Brian Campbell
• Ping Identity
• Email: bcampbell@pingidentity.com

Artigo Original