O SSL/TLS é o protocolo criptográfico mais usado na Internet. Tecnicamente, o TLS é o sucessor do SSL, embora os termos sejam, por vezes, usados alternadamente, como neste documento.
O Transport Layer Security (TLS) é usado para encriptar informações enquanto são enviadas através de uma rede, o que garante a privacidade entre um cliente e um servidor ou um equilibrador de carga. Um balanceador de carga de aplicações ou um balanceador de carga de rede proxy que usa SSL requer, pelo menos, uma chave privada e um certificado SSL.
Método de configuração do certificado
Para balanceadores de carga de aplicações que usam proxies HTTPS de destino, o proxy de destino do balanceador de carga tem de referenciar entre um e 15 certificados SSL do Compute Engine. Cada recurso de certificado SSL do Compute Engine contém a chave privada, o certificado correspondente e, opcionalmente, os certificados da AC.
Apoio técnico do balanceador de carga
A tabela seguinte mostra os métodos de configuração de certificados suportados por cada equilibrador de carga.
Balanceador de carga | Método de configuração do certificado: referências... do proxy de destino | |||
---|---|---|---|---|
Certificados SSL do Compute Engine | Um mapa de certificados do Gestor de certificados | Certificados do Gestor de certificados diretamente | ||
Balanceadores de carga de aplicações (proxies HTTPS de destino) | ||||
Balanceador de carga de aplicações externo regional | Suporta
certificados
regionais Geridos por si Geridos pela Google |
Gerido por si Gerido pela Google |
||
Balanceador de carga de aplicações interno regional | Suporta
certificados
regionais Geridos por si Geridos pela Google |
Gerido por si Gerido pela Google |
Tipos de certificados
Pode criar certificados SSL autogeridos para os seus equilibradores de carga.
Certificados SSL autogeridos
Os certificados SSL autogeridos são certificados que obtém, aprovisiona e renova por si. Os certificados autogeridos podem ser qualquer um destes tipos de certificados de chave pública:
- Validação de domínio (DV)
- Validação da organização (OV)
- Certificados de validação alargada (EV)
Pode criar certificados SSL autogeridos através de recursos de certificados SSL do Compute Engine. Para mais informações, consulte o artigo Use certificados SSL autogeridos.
Tipos de chaves suportados
Os seguintes tipos de chaves são suportados para certificados SSL do Compute Engine autogeridos regionais:
- RSA-2048
- RSA-3072
- RSA-4096
- ECDSA P-256
- ECDSA P-384
Use certificados com chaves ECDSA
Esta secção examina o motivo pelo qual recomendamos o ECDSA em vez do RSA como prática recomendada para chaves de assinatura de certificados.
Que tipo de chave usar
O ECDSA P-256 é a escolha recomendada do tipo de chave para a maioria dos certificados TLS, oferecendo uma forte segurança criptográfica juntamente com um excelente desempenho para operações de assinatura e uma utilização eficiente da largura de banda da rede.
Seguem-se alguns dos possíveis motivos para usar outros tipos de chaves de certificados:
- Se precisar de suportar clientes antigos que não suportam certificados ECDSA, pode fornecer certificados RSA-2048, além de certificados ECDSA P-256.
- Se tiver requisitos de conformidade específicos que exijam a utilização de tamanhos de chaves maiores ou tipos de chaves específicos, pode usar chaves ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.
Por que motivo deve escolher ECDSA em vez de RSA
A principal vantagem do ECDSA reside na sua capacidade de fornecer um nível de segurança criptográfica equivalente com chaves significativamente mais pequenas em comparação com o RSA. Esta eficiência traduz-se em benefícios tangíveis de desempenho e recursos. Uma chave mais pequena não implica uma segurança mais fraca. A ECDSA baseia-se no problema do logaritmo discreto da curva elíptica, que oferece uma segurança mais forte por unidade de chave e, em alguns casos, uma melhor eficiência computacional em comparação com a RSA.
Por exemplo:
- Uma chave ECDSA de 256 bits oferece um nível de segurança semelhante ao de uma chave RSA-3072.
- Uma chave ECDSA de 384 bits oferece um nível de segurança superior ao de qualquer tamanho de chave RSA amplamente suportado.
Principais vantagens do ECDSA:
Desempenho: as operações de assinatura ECDSA são significativamente menos intensivas em termos de computação do que as operações RSA, oferecendo um nível de segurança equivalente. Isto reduz a carga da CPU e a latência, o que é fundamental para sistemas de elevado débito ou sensíveis à latência.
Eficiência: as chaves e as assinaturas mais pequenas requerem menos largura de banda e armazenamento, o que é especialmente benéfico para ambientes com restrições de recursos, como dispositivos móveis e de IdC.
Vários certificados SSL
O proxy de destino de um Application Load Balancer pode referenciar até 15 certificados SSL do Compute Engine. O primeiro recurso de certificado SSL do Compute Engine referenciado é o certificado predefinido (principal) para o proxy de destino.
Para mais informações, consulte os artigos Proxies de destino e Certificados SSL na documentação de equilíbrio de carga.
Processo de seleção de certificados
O seguinte processo de seleção de certificados aplica-se a equilibradores de carga cujos proxies de destino referenciam vários certificados SSL do Compute Engine.
Depois de um cliente se ligar ao balanceador de carga, o cliente e o balanceador de carga negociam uma sessão TLS. Durante a negociação da sessão TLS, o cliente envia ao balanceador de carga uma lista de cifras TLS suportadas (no ClientHello
). O balanceador de carga seleciona um certificado cujo algoritmo de chave pública é compatível com o cliente. O cliente também pode enviar um nome de anfitrião de indicação do nome do servidor (SNI) para o balanceador de carga como parte desta negociação. Por vezes, os dados do nome de anfitrião SNI são usados para ajudar o equilibrador de carga a escolher o certificado que deve enviar para o cliente.
Se o proxy de destino do equilibrador de carga referenciar apenas um certificado, esse certificado é usado e o valor do nome de anfitrião SNI enviado pelo cliente não é relevante.
Se o proxy de destino do balanceador de carga fizer referência a dois ou mais certificados, o balanceador de carga usa o seguinte processo para selecionar um único certificado:
Se o cliente não tiver enviado nenhum nome de anfitrião SNI no respetivo
ClientHello
, o balanceador de carga usa o primeiro certificado na respetiva lista de certificados.Se o cliente enviar um nome de anfitrião SNI que não corresponda a nenhum nome comum (CN) do certificado e que não corresponda a nenhum nome alternativo de entidade (SAN) do certificado, o balanceador de carga usa o primeiro certificado na respetiva lista de certificados.
Em todas as outras situações: o balanceador de carga seleciona um certificado através do seguinte processo de correspondência:
A correspondência é feita pelo sufixo mais longo em relação aos atributos do certificado de nome comum (CN) e nome alternativo de entidade (SAN), com uma preferência por certificados ECDSA em vez de certificados RSA.
Para ilustrar o método de correspondência, considere um proxy de destino que faz referência aos dois certificados seguintes:
Certificado A
- CN:
cats.pets.example.com
- SANs:
cats.pets.example.com
,*.pets.example.com
,*.example.com
- CN:
Certificado B
- CN:
dogs.pets.example.com
- SANs:
dogs.pets.example.com
,*.pets.example.com
,*.example.com
- CN:
Considere agora os seguintes cenários:
- Se o nome de anfitrião SNI enviado pelo cliente for
cats.pets.example.com
, o equilibrador de carga usa o certificado A. - Se o nome de anfitrião SNI enviado pelo cliente for
ferrets.pets.example.com
, não existe uma correspondência exata, pelo que o equilibrador de carga seleciona o certificado A ou o certificado B porque ambos incluem*.pets.example.com
na respetiva lista de SANs. Nesta situação, não pode controlar que certificado é selecionado.
- Se o nome de anfitrião SNI enviado pelo cliente for
Depois de selecionar um certificado, o balanceador de carga envia o certificado ao cliente apenas se o certificado selecionado usar um algoritmo de chave pública compatível com uma cifra enviada pelo cliente no
ClientHello
. A negociação de TLS falha se o cliente não suportar um conjunto de cifras que inclua o algoritmo de chave pública (ECDSA ou RSA) do certificado que o equilibrador de carga selecionou.