🚶🏿 👩🏽‍⚕️ 🏭 Uma introdução ao TLS para Patrik Patrick (Parte 1) 🤴🏾 🌚 🙌🏾

Como você já deve saber, este é Patrick. Ele é uma estrela do mar, o que significa que é possível, sem insultá-lo, dizer que suas mãos estão crescendo de um só lugar. Patrick também é muito prático e imediatamente esquece tudo o que ele não precisa - mas se ele precisar de algo, ele quer saber (porque ele precisa!). Spoiler: aqui Patrick está tentando fazer um TLS Handshake.

Este artigo foi escrito para Patrick e pessoas como ele. Ela nasceu de uma apresentação mostrada pela primeira vez no Plesk TechTalk educacional interno, onde os funcionários, de forma acessível, compartilham informações entre si sobre tecnologias, processos e soluções interessantes. Portanto, as imagens deste artigo terão a aparência de slides :) O autor do texto original do relatório é o gerente do programa, Plesk Ruslan Kosolapov .

Normalmente, todo o material TLS cobre algum aspecto pequeno, mas não o quadro geral. Isso não é muito prático e Patrick tem uma dor de cabeça com isso. Tudo será diferente aqui: brevemente, aplicável "na vida cotidiana" e o mais exaustivamente possível.

O que é TLS e por que é para Patrick

TLS (Transport Layer Security) é um protocolo de proteção de camada de transporte. É necessário para que ninguém possa "ouvi-lo" e descobrir algumas informações importantes (na maioria das vezes senhas, se falarmos sobre trabalhar na rede). E também para se protegerem de falsificação e modificação de tráfego durante a transmissão. É nessas duas coisas que reside o objetivo do TLS.

Para maior clareza, vamos considerar o handshake TLS como uma chamada para Patrick Bob Esponja. Durante uma chamada, alguém pode escutar a conversa (ao lado de Patrick ou ligando no meio da linha), e geralmente o Bob Esponja pode não estar do outro lado - todos esses problemas são relevantes. E para resolvê-los, Patrick quer usar o TLS.

Em resumo, o aperto de mão de nível superior é assim:

Patrick: Eu quero usar o TLS, as versões cifradas são assim.
Bob Esponja: Ok, vamos usar versões cifradas como essas.

Depois disso, Bob Esponja envia o certificado, Patrick verifica, diz que está tudo bem, a chave da sessão está pronta (na verdade existem dois deles, mas isso não importa). Por que usar uma chave de sessão em vez de criptografia assimétrica - porque é mais rápida. Depois disso, eles começam a falar um idioma incompreensível para descriptografar. Assim, tudo está protegido.

Tudo parece ser simples. Como ele funciona no hardware não é tão importante para nós. Mas se você começar a pensar - e Patrick começa a pensar! - isso levanta a questão de como geralmente concordamos que usaremos o TLS? Afinal, uma vez que não havia TLS, havia apenas protocolos comuns - SMTP, HTTP. Como dizer o que é necessário no TLS? E aqui em nossa indústria tudo está como sempre - há muitas maneiras!

Inicialmente, eles queriam usar uma porta específica, o que implicaria o uso de TLS nela. Quais são as desvantagens disso? E por que então o método explícito (explícito) para iniciar uma sessão TLS apareceu? Existem várias razões:

Você precisa de muitas portas - e as portas são uma coisa que você não deseja gastar. Como quanto mais existem, mais difícil é configurar o firewall.
O servidor pode ignorar isso - ele se conectou à porta 443 e não há TLS lá, apenas HTTP sem HTTPS.
Antes de a conexão ser estabelecida, não é possível descobrir se o servidor TLS é suportado ou não.

Tudo isso levou ao surgimento de um método explícito - quando nos conectamos a uma porta regular e, em seguida, atualizamos nossa sessão para TLS. Para serviços diferentes, o protocolo possui comandos diferentes, por exemplo, para SMTP, existe um comando separado no nível do protocolo SMTP - STARTTLS . O HTTP também tem uma piada, chamada Upgrade: TLS / 1.0 . No nível do protocolo, é mais fácil entender se um servidor TLS é suportado ou não.

Vamos nos aprofundar um pouco mais nos diferentes tipos de conexões e em como as coisas estão com o TLS para elas.

Conectar: HTTP

Tudo seria fácil se, como sempre, não houvesse nuances. No caso do HTTP, os crescentes requisitos de segurança fornecem uma evolução constante do processo de trabalho com o TLS. No início, houve um redirecionamento para HTTPS, e isso foi feito simplesmente no cabeçalho. Isso deixou uma brecha para vulnerabilidades, então o Google criou o HSTS (HTTP Strict Transport Security). Este é um cabeçalho na resposta HTTP que informa ao navegador: “lembre-se de que, quando você chegar a esse domínio, vá diretamente para HTTPS, mesmo que a pessoa tenha lhe dito para acessar HTTP”. Assim, não há redirecionamento e tudo acontece muito mais seguro. Além disso, o Google tem outra iniciativa - você pode deixar uma solicitação para que seu site seja adicionado à lista do Google Chrome "Sempre use HTTPS", independentemente de qualquer cabeçalho.

Resumidamente: O HSTS resolve o redirecionamento das vulnerabilidades HTTP para HTTPS, então quase todos os navegadores oferecem suporte ao HSTS, o que é bom.

Connect: exotic (novas versões do HTTP e não apenas)

No HTTP / 2, as coisas são boas com o TLS: ele sempre é usado (como os navegadores são criados agora). Além disso, o TLS no HTTP / 2 deve ser novo - ou seja, ter a versão 1.2+.

Provavelmente, muito em breve o Google venderá o amplo uso do HTTP / 3, agora ele é adotado pelo padrão da IANA. A história de sua aparência e desenvolvimento é bastante confusa; A principal coisa a lembrar Patrick:

O HTTP / 3 é sempre o TLS 1.3+.
O HTTP / 3 é baseado no QUIC - é um protocolo sobre UDP, que, segundo o Google, é melhor que o TCP. Na verdade, antes que o nome HTTP / 3 fosse finalmente aprovado, o protocolo era chamado HTTP-over-QUIC.

Ainda existe um protocolo SCTP interessante, usado principalmente em telecomunicações. Acima dele, TLS e DTLS são usados (esse é o TLS para UDP).

Resumidamente: em 2 anos, o QUIC (ou seja, HTTP / 3) será usado em qualquer lugar, mas agora já deve haver HTTP / 2 em todos os lugares, mas, na realidade, não está em todo lugar.

Connect: Mail

Muitos clientes acreditam que deve haver TLS na porta 587, mas também há nuances aqui: alguém espera o TLS por padrão e alguém espera uma solicitação STARTTLS explícita do cliente. Por isso, várias combinações de servidor e cliente de email às vezes causam efeitos indesejados. Por exemplo, um cliente entra na porta 587, esperando que haja TLS, enquanto o servidor aguarda o cliente solicitar explicitamente STARTTLS . Não tendo recebido nada, o cliente volta para a porta 25. O resultado é uma troca silenciosa para uma conexão SMTP não segura. Ao testar e desenvolver, vale a pena lembrar sobre esses efeitos das combinações cliente-servidor. O Autodiscaver possui várias opções para especificar o TLS: como deve ser, o que é esperado e o que fazer. Muitos clientes de email entendem essas coisas.

Resumidamente: com o suporte a TLS em servidores e clientes de correio, tudo está bem em geral, mas em casos especiais, pode haver problemas e as extensões TLS não são muito bem suportadas.

Conectar: FTP

Pouco pode ser dito aqui. O principal problema é o SNI (é quando domínios diferentes estão no mesmo IP). No nível do FTP, o nome do domínio não é transferido. Em uma versão explícita, não pode funcionar, porque não há onde escrevê-lo. Existem várias opções de solução - algumas oferecem, outras, uma solução geral ainda não foi adotada, não existe um padrão.

Resumidamente: existe algum tipo de suporte TLS para FTP (FTPS, SFTP - um análogo do FTP implementado através do SSH), mas alguns aspectos não são abordados devido às limitações técnicas do próprio FTP.

TLS Handshake

Então, agora sabemos como iniciar a comunicação usando o TLS em diferentes conexões, e Patrick conseguiu comunicar seu desejo ao Bob Esponja. Depois que eles concordam em usar o TLS, o TLS Handshake é produzido. Seu resultado deve ser um acordo entre o cliente e o servidor sobre como eles criptografam tudo. Além disso, o cliente deve garantir que o servidor seja o necessário. Às vezes, o servidor também verifica o cliente (mas com muito menos frequência).

Cifras e versões

Como já mencionado, o primeiro passo é escolher qual versão do TLS e quais cifras serão usadas para criptografia. Normalmente, a cifra fica assim:

O conjunto de cifras está no registro da IANA e no protocolo TLS, na forma binária, é apenas seu ID. Como você pode ver na figura, aqui não é apenas (e não apenas) a cifra, mas também o modo de operação e outros detalhes necessários para o handshake TLS. Patrick não precisa entrar em detalhes. Tudo o que é importante nesta fase é lembrar que essas cartas são boas (e as demais são ruins):

DHE
ECDhe
AES128
AES256
RSA
Ecdsa
Cbc
Gcm
SHA256
SHA383
CHACHA20
POLY1308

Imagem para lembrar boas cifras:

Se for difícil lembrar, existem bons serviços que podem lhe informar, por exemplo, um serviço do Mozilla ssl-config.mozilla.org .

Você pode ver imediatamente onde e como ele é suportado - é isso que os caras da Mozilla estão tentando seguir.

Um detalhe interessante: o cliente transfere as cifras em ordem de prioridade, de acordo com suas preferências, mas o servidor fica com a decisão - seleciona a cifra que parece ser a melhor da lista de clientes suportados.

Ambos os lados também indicam a versão máxima suportada do protocolo - nesse caso, Patrick é mais avançado que Bob Esponja.

Certificado de verdade

Juntamente com a resposta "Vamos fazer assim", o servidor envia seu certificado ou certificados - pode haver muitos deles.

O que é um certificado? Esse é um relacionamento de informações (assunto) - geralmente é o nome de um domínio ou organização - e uma chave pública (chave pública). Ou seja, o certificado diz: “Cara, minha chave pública é assim. Agora, com a ajuda dele, concordaremos com as chaves da sessão. ” Além disso, com sua ajuda, você pode verificar a assinatura de certificados ou outra coisa. Ou seja, em princípio, seria possível usar não certificados, mas registros onde esse relacionamento é indicado. De fato, as etapas nessa direção continuam, porque o mecanismo da Autoridade de Certificação é considerado não muito bom, simplesmente não há mais nada.

Portanto, o certificado é a estrutura de 'Subject: Public key' mais a assinatura desse ishyuer (o emissor em transliteração para o russo parece péssimo, mas o sinônimo mais próximo aqui não está muito próximo do "emissor") em que este certificado foi emitido. Ishüyer também tem um certificado e a conexão de alguém com alguma coisa. Você pode verificar a exatidão do certificado, pegando a chave pública do ishyuere e verificando a assinatura. Como resultado, nada pode ser falsificado aqui.

Vamos revisar o certificado e ver quais problemas ele pode ter.

Em primeiro lugar, o número de série implica exclusividade apenas dentro dos limites do ishyuere, embora alguns softwares considerem que ele é único em todo o universo. Felizmente, mais frequentemente do que não, é verdadeiramente completamente único.

O certificado também indica quais algoritmos são usados para criptografia e assinatura: RSA ou ECDSA - ou seja, qual criptografia usar para trabalhar com essa chave pública. A principal diferença entre o RSA e o ECDSA é que o princípio matemático do ECDSA é baseado em curvas elípticas, e o RSA é simplesmente números naturais, por isso é mais lento e são usados bits de chaves grandes (3-4.000) para evitar que sejam quebrados . E para ECDSA, uma chave de 300 bits é suficiente e funciona mais rapidamente. Portanto, muitos estão mudando para o ECDSA - o aperto de mão em si é pesado e eu quero reduzi-lo. A ECDSA pode ser solicitada ao emitir um certificado e, se o prospector o apoiar, ele fará isso por você. Mas a assinatura do certificado depende da chave privada que o ishuiur possui atualmente e não da solicitação da ECDSA ou da RSA.Portanto, os navegadores podem mostrar que um está na assinatura e o outro na chave pública, e não é necessário ter medo se a assinatura não for ECDSA.

Como obter um certificado?

Em resumo - assim:

Patrick diz à Autoridade de certificação: Eu preciso de um certificado. Essa pessoa (ou organização) verifica se é Patrick. Os cheques podem ser muito diferentes. Obviamente, Patrick como cliente pode não ter um certificado, mas se o servidor não tiver um certificado, não haverá TLS. É verificado se tudo está indicado corretamente no pedido de certificado, se Patrick realmente é o proprietário do assunto para o qual está solicitando um certificado. Isso é feito por centros superiores da Autoridade Certificadora - pessoas condicionais em quem todos acreditam. Para emitir um certificado, é necessário elaborar um CSR (solicitação de assinatura de certificado, uma solicitação de certificado).

Essa também é uma estrutura, difícil de trabalhar, porque existem poucos serviços que permitem definir, especificar, verificar e ver tudo.

No total, geramos um par de chave pública: chave privada, mas damos apenas o público e ocultamos o privado. Em seguida, geramos uma solicitação de assinatura de certificado e a assinamos com nossa chave privada. Enviamos tudo isso para a autoridade de certificação e ela inicia a verificação. Pode ser diferente, para certificados especialmente legais, existem procedimentos complicados especiais, mas vamos nos concentrar no caso geral.

CAA RR

Existe um problema que pessoas que todos acreditam que às vezes não são muito boas. Uma das razões pelas quais a Symantec se tornou parte do DigiCert é porque (a Symantec) emitiu certificados sem perguntar aos proprietários do domínio. Você não pode fazer isso, foi um insulto a todos, mas principalmente à própria Symantec, porque você teve que vender seus negócios. Para tornar o servidor menos dependente de camaradas inescrupulosos, existe o registro CAA RR - um registro no DNS, onde diz quem o proprietário permite emitir certificados para seu domínio. Esse recurso também está no Plesk, é pouco usado até o momento, aproximadamente como o DNSSec, mas mesmo assim. Todas as autoridades de certificação concordaram em verificar esta entrada e, se disser que essa autoridade de certificação não pode ser emitida, dirá: "você não passou na validação, está escrito no CAA RR,que não posso escrever um certificado para você "- e não vou escrever. Se não houver entrada, você poderá. Agora, o Google está adotando a iniciativa para que os clientes verifiquem o certificado que receberam em conformidade com os registros CAA RR. O debate ainda está em andamento.

Além disso, o CAA RR a partir do momento em que expandimos o suporte no Plesk, indicando métodos de validação (ou seja, você também pode indicar aqui por qual método você valida que esse domínio é seu) e o URI da conta (Identificador Uniforme de Recursos). Popular entre os usuários O Plesk Let's Encrypt já suporta tudo isso (muito bem!).

Tudo isso funciona para qualquer tipo de certificado e, como falaremos sobre as diferenças mais tarde, é hora de falar sobre os tipos com mais detalhes.

Tipos de certificado

Há três deles:

Validação de domínio

O assunto é um domínio, ou seja, aqui só o verificamos. Anteriormente, quando não havia validadores automáticos, a validação era realizada principalmente por e-mail através do serviço Whois. Este foi considerado um motivo suficiente para acreditar que você é o proprietário deste domínio. Então eles pensaram em checar o DNS - eles escreveram para você por e-mail: “e adicionam esse e aquele registro ao DNS”. Mais tarde, métodos automáticos apareceram (falaremos um pouco mais sobre o ACME).

Validação da organização

No campo "assunto", além do nome do domínio, o nome da organização também é indicado. A verificação consiste em validar se o domínio pertence a esta organização e se a pessoa que veio para o certificado trabalha lá. Como isso é feito: eles procuram organizações nos registros, ligam, pedem que algo seja feito (o telefone estava correto, a pessoa certa atendeu, o que significa que provavelmente tudo está bem).

Validação estendida

O mesmo que OV, apenas mais frio. Tudo é muito regulamentado aqui - um documento de 40 páginas no espírito de "no parágrafo 5.6.8 deve ser o seguinte: ...", etc. Muitas coisas são verificadas - o país, o departamento (se indicado no aplicativo) e, às vezes, uma pessoa especial sai para ver com os olhos. Qual é a diferença prática? Quase todos os navegadores deixaram de distinguir entre OV e DV, e isso é ruim, porque nesse caso o nome da organização não é exibido. Como resultado, ninguém se preocupa em criar um domínio aliepxress.ru, desenhe a mesma página e roube cartões de crédito. E será absolutamente legítimo criar um domínio desse tipo e obter um certificado DV nele.

Exemplo com EV - o nome da organização é visível aqui; portanto, se alguém roubar algo, o usuário saberá que era a corporação Valve Corp, e registrar a corporação é um pouco mais difícil que o domínio (mais verificações).

No entanto, tudo vai até o ponto em que o VE deixará de ser diferente; em dispositivos móveis, ele não é mais visível e você precisa pressionar um botão separado, e também no Safari. O Google Chrome ainda está em espera (UPD - não mais! Eu tive que criar uma tela do IE). A argumentação daqueles que não mostram: “se você está preocupado, clique e olhe”, mas ninguém pressiona naturalmente.

Obtendo um certificado: automação

Agora vamos falar sobre o recebimento automatizado de certificados DV. Para maior clareza, vamos ver como o nosso Let's Encrypt favorito faz. Ele geralmente tem boa documentação, se alguém estiver interessado, e até mesmo em russo.

ACME

O ACME (ambiente de gerenciamento automático de certificados) é um protocolo projetado para automatizar e padronizar o processo de obtenção de um certificado.

Como a ACME prova que você é proprietário de um domínio? Você diz: Quero um certificado e indique o tipo de validação automática - por exemplo, ACME HTTP-01. O Let's Encrypt pede para você colocar os dados em um arquivo e, se você puder colocar os arquivos no seu domínio (e o Let's Encrypt puder buscá-los a partir daí via HTTP), provavelmente você é o proprietário. Agora, essa abordagem é criticada, inclusive do Google, porque não protege contra phishing. Ou seja, com a validação manual, é provável que o domínio aliepxress.ru suscite suspeitas, mas o Let's Let Criptografar até agora não sabe como (ou pode, mas muito).

Desafio de DNS

Além do ACME, também há um desafio de DNS. Por exemplo, eles dizem a você: insira um registro txt na sua zona DNS, coloque os dados nele. Existem outras maneiras, mas não comuns, e uma foi cancelada por completo, porque se mostrou vulnerável. O que temos no Plesk: certificados curinga (que podem ser emitidos apenas pelo desafio do DNS) não funcionam para muitas pessoas, porque muitas vezes o Plesk não gerencia zonas e extensões DNS do domínio. Vamos criptografar não pode automatizar a criação de um registro na zona DNS .

Mais duas palavras sobre Let's Encrypt

Um aspecto importante ao trabalhar com os certificados Let's Encrypt é o limite. Em caso de dúvida (ou suspeita de que foram alcançados), é melhor seguir o link: letsencrypt.org/docs/rate-limits

Às vezes, eles são atualizados. Existem limites não óbvios que as pessoas esquecem: na maioria das vezes, a julgar pelos pedidos de suporte, eles enfrentam um limite de 100 nomes de domínio no certificado. O Let's Encrypt também possui um servidor intermediário e há mais limites, mas esses certificados são considerados não confiáveis e, para o navegador, são semelhantes aos autoassinados. Na prática, com um limite de 100 nomes, eles raramente chegam até nós (apesar do fato de os sites no Plesk terem um total de 1.300.000 certificados Let's Encrypt). A mediana, de acordo com nossas estatísticas, é de 20 nomes por certificado. Portanto, se algo não funcionar, veja - talvez o limite seja atingido. Vamos criptografar possui um bom relatório de erros, e geralmente você pode entender o que aconteceu.

Qual é o próximo?

Portanto, depois que o certificado é recebido, o servidor transmite os dados da chave da sessão - é isso que será usado para criptografia. Se o servidor considerar que é necessário autenticar o cliente (por exemplo, o acesso é aberto apenas para um certo círculo de pessoas), ele poderá perguntar: o cliente, quem é você? E então o cliente precisará enviar seu certificado. Depois de receber a mensagem ServerHelloDone, o cliente percebe que é hora de verificar os certificados e trabalhar com as chaves.

Tudo sobre o que falamos, antes do TLS 1.3 passar por um canal aberto, e qualquer um pode ver todas essas coisas. Existem vários ataques interessantes que você pode ler sobre si mesmo.
Na segunda ~~série~~ do artigo, aprenderemos como o cliente verifica o certificado.

Uma introdução ao TLS para Patrik Patrick (Parte 1)