O que é SSL/TLS e por que seu site precisa

Quando você abre um site com https://, o navegador e o servidor combinam uma chave secreta antes de trocar qualquer página, senha ou token. Sem isso, tudo viaja em texto puro: o Wi-Fi do café, o provedor de internet e qualquer equipamento no caminho conseguem ler e alterar o conteúdo. O protocolo que faz essa combinação é o TLS.

"SSL" ainda é o nome que todo mundo busca e que aparece em painéis de hospedagem, mas o protocolo SSL em si saiu de uso: o que roda hoje é o TLS. Entender como ele funciona ajuda a colocar HTTPS no seu site, no painel do seu bot ou na sua API, e a diagnosticar quando o certificado dá erro.

O que é SSL/TLS?#

TLS (Transport Layer Security) é um protocolo que fica entre o TCP e a aplicação (HTTP, SMTP, bancos de dados e outros). Ele entrega três garantias:

• Confidencialidade: os dados são criptografados, então quem intercepta o tráfego só vê bytes sem sentido.
• Integridade: qualquer alteração no meio do caminho é detectada.
• Autenticação: o cliente confirma, por meio de um certificado, que está falando com o servidor do domínio que digitou.

O SSL (Secure Sockets Layer) foi criado pela Netscape nos anos 1990. O SSL 3.0 foi proibido pela RFC 7568 por falhas de segurança, e o TLS 1.0 e 1.1 foram descontinuados pela RFC 8996. As versões em uso hoje são o TLS 1.2 e o TLS 1.3 (RFC 8446). Quando alguém diz "certificado SSL", quase sempre quer dizer o certificado usado pelo TLS.

Como funciona o handshake TLS?#

O handshake é a negociação que acontece depois da conexão TCP e antes dos dados da aplicação. De forma simplificada, no TLS 1.3:

1. ClientHello. O navegador envia as versões e conjuntos de criptografia que aceita, o nome do domínio (extensão SNI) e sua parte da troca de chaves.
2. ServerHello e certificado. O servidor escolhe os parâmetros, devolve sua parte da troca de chaves e envia o certificado, junto com uma prova de que possui a chave privada correspondente.
3. Verificação. O navegador checa se o certificado é válido para o domínio, se não expirou e se foi assinado por uma autoridade em que ele confia.
4. Chave de sessão. Os dois lados calculam a mesma chave simétrica sem nunca enviá-la pela rede. A partir daí, tudo é criptografado com ela.

O TLS 1.3 conclui tudo isso em uma ida e volta de rede, uma a menos que o TLS 1.2, o que reduz a latência de cada nova conexão. A criptografia de chave pública só é usada para estabelecer a chave; os dados em si usam criptografia simétrica, que é muito mais rápida.

O que é um certificado e quem o assina?#

O certificado é um arquivo que liga uma chave pública a um nome de domínio. Ele contém o domínio (ou domínios), a chave pública, as datas de validade e a assinatura de quem o emitiu.

Essa assinatura vem de uma autoridade certificadora (CA). O sistema operacional e o navegador já trazem uma lista de CAs raiz confiáveis. Na prática, o servidor envia uma cadeia: o certificado do site, assinado por uma CA intermediária, que é assinada pela raiz. Se a cadeia termina numa raiz conhecida, o navegador confia no certificado.

A maioria dos certificados de sites é do tipo DV (Domain Validation): a CA só confirma que quem pediu controla o domínio. Os tipos OV e EV verificam também a empresa. Para a maioria dos projetos, o DV basta, e o Let's Encrypt emite esse tipo de certificado sem custo. Para comparar as opções, veja certificado SSL pago ou gratuito.

Certificados têm validade limitada, e esse prazo vem encolhendo: o Let's Encrypt, por exemplo, publicou um cronograma que reduz em etapas os 90 dias que foram por anos o padrão dele. Por isso a renovação precisa ser automática.

Como verificar o certificado de um domínio?#

No terminal, com o OpenSSL:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

A saída mostra para quem foi emitido (subject), quem emitiu (issuer) e o período de validade (notBefore e notAfter). A opção -servername envia o SNI, necessário quando vários domínios dividem o mesmo IP.

Com o curl, você vê a versão do TLS negociada:

curl -vI https://example.com 2>&1 | grep -E "SSL connection|TLSv|expire date|issuer"

Se algo falhar, a mensagem de erro costuma apontar o caminho. Para os casos mais comuns, veja erros de certificado SSL.

Onde o TLS termina na sua arquitetura?#

Nem sempre é o seu app que lida com o TLS. É comum que um proxy reverso, um balanceador de carga ou uma CDN receba a conexão HTTPS, decifre o tráfego ali (a chamada terminação TLS) e repasse a requisição ao app. Assim, certificados e chaves ficam fora do seu código.

Na prática, seu app pode receber HTTP puro por trás do proxy. Para saber se o acesso original foi HTTPS, leia o cabeçalho X-Forwarded-Proto (com a configuração de proxy confiável do seu framework), em vez de deduzir pelo esquema da conexão local.

Quando o TLS não basta?#

O TLS protege os dados em trânsito, nada além disso. Ele não impede SQL injection, não valida o que o usuário envia, não protege senhas guardadas e não garante que o dono do site seja honesto. Também não esconde tudo: o IP do servidor e, na maioria dos casos, o nome do domínio acessado ainda são visíveis para quem observa a rede.

Como fazer isso na Square Cloud#

Na Square Cloud, o TLS fica na frente da sua aplicação, como na arquitetura da seção anterior: o app escuta em HTTP, em 0.0.0.0 na porta da variável PORT, e a plataforma publica o tráfego por HTTPS. Certificado e chave privada não entram no seu código.

Toda aplicação web recebe um subdomínio *.squareweb.app com HTTPS, em todo plano. O certificado DV é emitido e renovado sozinho, então os prazos de validade cada vez mais curtos não viram tarefa sua. Requisições em HTTP são redirecionadas para HTTPS, e os cabeçalhos que a aplicação envia, como o HSTS, passam intactos.

Para usar seu próprio domínio, disponível a partir do plano Standard (a partir de R$ 44,99 por mês), você cria no seu registrador os registros DNS que o painel mostra e acompanha a validação em tempo real. O certificado sai automaticamente depois que o domínio resolve. A rede ainda inclui HTTP/3, WAF e mitigação de DDoS. Veja o passo a passo em domínios personalizados e os detalhes da rede em rede e CDN.