022.2 Lição 1

Em comunicações na web, é crucial distinguir entre protocolos de texto simples (plain text) e criptografia de transporte. Os protocolos de texto simples enviam dados em um formato legível, o que significa que as informações podem ser facilmente interceptadas e visualizadas por agentes maliciosos. O HTTP (Protocolo de Transferência de Hipertexto) é um protocolo de texto simples, onde todos os dados são transmitidos sem qualquer forma de criptografia, tornando-os vulneráveis à escuta e à adulteração.

O HTTP define como os clientes da web (por exemplo, navegadores) se comunicam com os servidores web. Como um protocolo de camada de aplicação, o HTTP é independente dos protocolos de camada de transporte ou de sessão subjacentes (HTTP como parte da pilha da internet). No entanto, em sua forma original, o HTTP transmite dados como texto simples, encapsulados em segmentos de transporte (como TCP) sem criptografia, tornando-os suscetíveis à interceptação.

A criptografia de transporte oferece uma solução ao codificar os dados durante a transmissão, convertendo-os em um formato ilegível. Mesmo que os dados sejam interceptados, eles não podem ser decifrados sem as chaves de descriptografia corretas. Essa abordagem garante a confidencialidade e a integridade dos dados, prevenindo o acesso e a modificação não autorizados. O Transport Layer Security (TLS) é o protocolo mais amplamente utilizado para criptografia de transporte, fornecendo a base para a versão segura do HTTP, conhecida como HTTPS.

À medida que a internet evoluiu para lidar com transações sensíveis e comerciais, surgiu a necessidade de um protocolo para proteger esses dados. O Secure Sockets Layer (SSL), introduzido na década de 1990, serviu a esse propósito, mas foi substituído por seu sucessor, o Transport Layer Security (TLS). O TLS continua a ser o padrão para garantir a comunicação entre clientes e servidores em canais inseguros.

O TLS é composto por vários elementos-chave, incluindo protocolos de criptografia, certificados digitais para verificação da identidade do servidor e dois protocolos principais do TLS: o protocolo de handshake TLS e o protocolo de registro TLS. Esses componentes trabalham juntos para fornecer uma conexão segura entre o cliente e o servidor (Protocolos TLS como parte da pilha da internet).

O protocolo de handshake TLS é responsável pela autenticação inicial entre o cliente e o servidor, durante a qual eles trocam chaves criptográficas e concordam com um algoritmo de criptografia. O handshake TLS garante que a conexão seja segura antes que qualquer dado da aplicação seja trocado. A autenticação bem-sucedida requer que o servidor apresente um certificado digital assinado por uma Autoridade Certificadora (CA) confiável, confirmando sua identidade.

O TLS também inclui o protocolo de registro TLS, que encapsula protocolos de nível superior e fornece privacidade e integridade dos dados. A privacidade é alcançada por meio da criptografia simétrica, enquanto a integridade dos dados é garantida pela incorporação de um Código de Autenticação de Mensagem (Message Authentication Code - MAC, na sigla em inglês) para detectar adulterações durante a transmissão. Essa abordagem em duas camadas garante que as comunicações permaneçam privadas e seguras.

O HTTPS, ou Protocolo de Transferência de Hipertexto Seguro, é simplesmente o HTTP executado sobre o TLS (HTTPS como parte da pilha de protocolos da internet). O objetivo do HTTPS é proteger os dados transmitidos entre o navegador de um visitante e um servidor web, criptografando-os e verificando a identidade do servidor.

Quando um visitante solicita acesso a um site usando HTTPS, o servidor apresenta um certificado digital X.509 ao navegador. Esse certificado, emitido por uma Autoridade Certificadora (CA) confiável, autentica a identidade do servidor. Uma vez verificado, o navegador estabelece uma conexão segura usando criptografia simétrica, frequentemente facilitada por métodos de troca de chaves, como Diffie-Hellman ou Elliptic Curve Diffie-Hellman (ECDH).

A principal vantagem do HTTPS é que ele fornece confidencialidade, integridade e autenticação para as comunicações na web. Os dados transmitidos via HTTPS estão protegidos contra interceptação ou adulteração, e a identidade do servidor é verificada para evitar que os visitantes interajam inadvertidamente com sites maliciosos.

Os navegadores modernos oferecem indicadores visuais, como um ícone de cadeado na barra de endereços, para sinalizar que um site está usando HTTPS. No entanto, se o certificado estiver expirado, mal configurado ou não confiável, os navegadores podem exibir mensagens de aviso para informar os visitantes sobre possíveis riscos de segurança. Esses avisos ajudam a prevenir ataques, como interceptações de man-in-the-middle, alertando os visitantes quando a conexão pode estar comprometida.

A transição do HTTP para o HTTPS foi impulsionada pela crescente demanda por privacidade e segurança na web. A maioria dos navegadores e motores de busca agora prioriza sites habilitados para HTTPS, refletindo a importância da comunicação segura no cenário digital atual.

A porta padrão para comunicação HTTPS é a TCP 443, enquanto o HTTP utiliza a TCP 80. A diferença nos números das portas permite que os servidores distinguam entre tráfego seguro e inseguro. Quando um navegador solicita uma página da web via HTTPS, a conexão inicial envolve o handshake TLS, durante o qual a identidade do servidor é autenticada e as chaves de criptografia são trocadas.

Uma vez que o handshake TLS está completo, o navegador envia a primeira solicitação HTTP, e todas as trocas de dados subsequentes são criptografadas, garantindo que informações sensíveis, como credenciais de login ou detalhes de pagamento, permaneçam seguras durante toda a sessão.

Muitos sites estão configurados para redirecionar automaticamente os visitantes do HTTP para o HTTPS, a fim de impor conexões seguras. Por exemplo, se um visitante solicitar http://www.example.com, o servidor pode redirecioná-lo para https://www.example.com, garantindo que a comunicação seja criptografada e segura.

A autenticação de servidor HTTPS depende de certificados digitais, especificamente certificados X.509, para verificar a identidade do servidor. Quando um visitante insere uma URL, o navegador recupera o certificado digital do servidor, que contém a chave pública e informações de identidade. Este certificado é assinado por uma Autoridade Certificadora (CA) confiável, garantindo que o servidor seja legítimo.

Os certificados X.509, também conhecidos como certificados SSL ou TLS, vinculam uma chave pública à identidade do servidor, referida como o Sujeito (Subject) do certificado. A assinatura digital da CA confirma a validade desse vínculo, que é armazenado no campo signatureValue do certificado.

O padrão X.509 define a estrutura dos certificados digitais. A Versão 3 (X.509v3) introduziu a capacidade de adicionar extensões aos certificados, permitindo a inclusão de informações adicionais, como nomes alternativos para o servidor.

A extensão Subject Alternative Name (SAN) permite que um certificado associe múltiplas identidades, como nomes DNS ou endereços IP, ao mesmo servidor. Essa flexibilidade é crucial para servidores que operam sob vários nomes de domínio ou endereços IP, pois permite que um único certificado cubra todas as identidades relevantes.

O processo de verificação de um certificado envolve checar o Subject ou o Subject Alternative Name contra a identidade do servidor. Se uma correspondência for encontrada, o certificado é considerado válido. Coringas, como *.example.com, também podem ser usados para corresponder a vários subdomínios, proporcionando maior flexibilidade na gestão de certificados.

Os certificados são emitidos por CAs intermediárias, que fazem parte de uma cadeia de confiança que leva de volta a uma CA Raiz confiável. O navegador verifica a cadeia de confiança comparando o campo Issuer de cada certificado com o Subject do próximo certificado na cadeia, alcançando, por fim, uma CA Raiz confiável.

Os certificados possuem um período de validade (validity period) definido, que indica o intervalo de tempo durante o qual o certificado é válido. Se um certificado se tornar comprometido antes de sua expiração, a CA pode revogá-lo e publicar seu número de série em uma Lista de Revogação de Certificados (Certificate Revocation List - CRL, na sigla em inglês). Os navegadores utilizam as CRLs para verificar o estado do certificado e garantir que ele não tenha sido revogado.

Os servidores HTTPS são frequentemente configurados para redirecionar automaticamente o tráfego HTTP para HTTPS. Suponha que o cliente da web nessa situação, como um navegador da internet, envie uma solicitação para o seguinte URI, especificando HTTP:

O servidor HTTPS redirecionaria o cliente para um URI especificando HTTPS, como:

Quando um navegador da web se conecta a um site usando HTTPS, ele realiza várias verificações de validade essenciais no certificado X.509 do site para garantir que a conexão seja segura e confiável. Essas verificações checam a autenticidade do certificado, confirmam a identidade do site e protegem os visitantes contra potenciais ameaças de segurança, como ataques de man-in-the-middle. O navegador realiza uma série de etapas para avaliar a validade do certificado.

O formato dos certificados de chave pública é definido pelo padrão X.509, que foi publicado pela primeira vez em 1988. O formato de certificado X.509 versão 3 (v3), desenvolvido em 1996, estende o formato ao adicionar a possibilidade de campos adicionais de Extensões (Certificado X.509 v3).

O campo Subject do certificado de chave pública identifica o servidor HTTPS associado à chave pública armazenada no campo Subject Public Key Info. O campo Extensions pode transmitir dados adicionais, como informações de identificação da entidade.

A extensão Subject Alternative Name ao padrão X.509 permite que identidades adicionais sejam vinculadas ao sujeito do certificado. As opções de Subject Alternative Name podem incluir um nome de host DNS, um endereço IP, dentre outras informações.

O nome do sujeito pode ser incluído no campo Subject, na extensão Subject Alternative Name, ou em ambos. Se uma extensão SAN do tipo DNS Name estiver presente, ela é usada como o identificador do servidor. Caso contrário, o campo Common Name mais específico no campo Subject do certificado é utilizado como a identidade.

Se mais de uma identidade de um tipo específico estiver presente no certificado — por exemplo, mais de um campo DNS Name (Nome DNS) — uma correspondência em qualquer campo do conjunto é considerada aceitável. Os nomes podem conter o caractere curinga * (asterisco) para corresponder a qualquer componente único do nome de domínio ou fragmento de componente. Assim, se o URI for https://www.example.com/~carol/home.html e o certificado do servidor contiver *.basket.com, abcd.com e *.example.com como opções de DNS Name, há uma correspondência aceitável: o nome *.example.com corresponde a www.example.com. Esse nome curinga não corresponderia a basket.carol.example.com porque o nome de domínio posterior contém um componente adicional.

Da mesma forma, c*.com corresponde a carol.com porque o asterisco pode corresponder a um fragmento de um componente, mas não corresponde a basket.com.

Se o campo de host do URI incluir um endereço IP, como https://8.8.8.8, em vez de um nome de host, o cliente verifica o campo IP Address da extensão Subject Alternative Name. O campo IP Address deve estar presente no certificado e deve corresponder exatamente ao endereço IP no URI.

Em seguida, o navegador verifica a cadeia de confiança do certificado. Ele confirma se o certificado foi emitido e assinado por uma Autoridade Certificadora (CA) confiável. Isso envolve rastrear a cadeia do certificado do site, passando pelos certificados intermediários até chegar a uma CA raiz confiável, que está incluída no repositório de certificados raiz pré-instalado do navegador. Se qualquer certificado nessa cadeia não for válido ou tiver sido emitido por uma CA não confiável, o navegador sinaliza a conexão como insegura, alertando o visitante.

Outra verificação crítica envolve o período de validade do certificado. Todo certificado X.509 especifica um período de tempo durante o qual é válido, definido pelos campos notBefore (não antes) e notAfter (não depois). O navegador verifica a data e hora atuais em relação a esse período de validade. Se o certificado estiver expirado ou ainda não for válido, o navegador alerta o visitante, sugerindo que a conexão pode não ser segura. Esse processo garante que os certificados sejam renovados regularmente para manter a comunicação segura.

Além disso, os navegadores realizam verificações para determinar se o certificado foi revogado pela CA. Isso é feito por meio de métodos como consultar uma Lista de Revogação de Certificados (Certificate Revocation List - CRL, na sigla em inglês) ou usar o Protocolo de Status de Certificado Online (Online Certificate Status Protocol - OCSP, na sigla em inglês). Se o certificado tiver sido revogado devido a razões como uma chave comprometida ou emissão indevida, o navegador alerta o visitante de que o certificado não é mais confiável e que a conexão pode ser insegura.

O navegador também valida a assinatura digital do certificado para confirmar que ele não foi adulterado desde sua emissão. Isso envolve verificar a assinatura criptográfica da CA emissora. Se a verificação da assinatura falhar, isso sugere que o certificado pode ter sido alterado ou falsificado, levando o navegador a bloquear a conexão para garantir a segurança do visitante.

Finalmente, os navegadores revisam quaisquer campos de uso de chave ou de extensões dentro do certificado. Esses campos especificam os propósitos pretendidos do certificado, como autenticação de servidor ou assinatura de código. O navegador garante que o certificado esteja sendo utilizado de acordo com esses propósitos definidos. Se o certificado estiver sendo usado para um propósito fora do escopo permitido, o navegador emite um alerta para o visitante.

Essas verificações garantem coletivamente a segurança das comunicações na web ao validar a autenticidade, integridade e uso adequado dos certificados X.509. Se alguma dessas verificações falhar, o navegador exibe um aviso de segurança ou mensagem de erro, aconselhando o visitante a proceder com cautela ou a evitar o site completamente. Esse rigoroso processo de validação desempenha um papel crítico na manutenção da confiabilidade das interações online e ajuda a prevenir que entidades maliciosas se façam passar por sites legítimos.

Determinar se um site está criptografado é um passo crucial para garantir a comunicação segura entre o navegador de um visitante e o servidor do site. Sites criptografados usam HTTPS, que fornece criptografia por meio do protocolo TLS, garantindo que os dados trocados entre o visitante e o site permaneçam privados e protegidos contra escuta ou adulteração.

Para determinar se um site está criptografado, os visitantes podem contar com alguns indicadores visuais fornecidos pelos navegadores da web. O indicador mais comum é o ícone de cadeado que aparece na barra de endereços do navegador, à esquerda da URL. Se o site estiver usando HTTPS, o cadeado aparecerá fechado ou travado, sinalizando que a conexão é segura. Em alguns navegadores, clicar no ícone do cadeado exibirá informações mais detalhadas sobre a criptografia do site, como o tipo de criptografia utilizada e a CA emissora.

Além do cadeado, a própria URL é outro indicador de se um site está criptografado. Sites seguros começam com https://, enquanto sites não criptografados usam http://. A presença de https:// indica que a conexão está protegida pela criptografia TLS. Alguns navegadores também podem destacar isso mudando a cor da barra de endereços quando uma conexão segura é estabelecida.

Quando um site não utiliza criptografia, navegadores modernos frequentemente exibem uma mensagem de aviso para informar os visitantes sobre os riscos potenciais. Por exemplo, quando um visitante tenta acessar um site usando HTTP simples (sem criptografia), o navegador pode mostrar uma mensagem como “Not Secure” (não seguro) na barra de endereços. Em alguns casos, os navegadores podem exibir um aviso mais proeminente, alertando o visitante de que a “connection is not private” (conexão não é privada) e aconselhando-o a evitar inserir informações sensíveis, como senhas ou números de cartões de crédito. Navegadores como Google Chrome, Mozilla Firefox e Microsoft Edge têm sido cada vez mais rigorosos em sinalizar sites não criptografados, especialmente em páginas onde os visitantes são solicitados a enviar informações pessoais.

Se a configuração HTTPS de um site for inválida ou mal configurada, os navegadores fornecem mensagens de aviso adicionais. Por exemplo, se um site tiver um certificado “expired” (expirado), “misconfigured” (mal configurado) ou “untrusted” (não confiável), o navegador pode apresentar uma mensagem de aviso em tela cheia com uma descrição do problema. Mensagens como “Your connection is not private” (Sua conexão não é privada) ou “Potential Security Risk Ahead” (Risco de Segurança Potencial à Frente) indicam que o certificado está expirado, revogado ou assinado por uma CA não confiável. Esses avisos geralmente recomendam que os visitantes voltem para a segurança, evitando prosseguir para o site, embora frequentemente ofereçam uma opção para continuar, por conta e risco do visitante.

Determinar se um site está criptografado envolve verificar indicadores visuais, como o ícone de cadeado e https:// na URL. Os navegadores também exibem avisos claros quando um site não é seguro, garantindo que os visitantes sejam informados sobre os riscos potenciais associados a conexões não criptografadas ou mal configuradas. Compreender essas mensagens do navegador é essencial para uma navegação segura e para evitar a exposição a ameaças de segurança.