Atualmente, o Google e seu mecanismo de busca, estão punindo quem não utiliza protocolos de segurança, antes marcando os sites seguros, hoje marcando sites como inseguros e rebaixando-os dos resultados quando um usuário realiza alguma pesquisa. Em futuro breve, os navegadores irão exibir uma página de alerta ao usuário, o que certamente causará o abandono do site pelo usuário leigo.

Toda vez que você entra em um site e realiza algum tipo de login, está dizendo: "sim, eu confio neste site, por isso estou disposto a compartilhar minhas informações pessoais com ele". Esses dados podem incluir seu nome, sexo, endereço físico, endereço de e-mail, geolocalização, dados e atividades feitas nas redes sociais, cartão de crédito, carteiras digitais, dentre outras.

Mas como você sabe que pode confiar em um site específico? Em outras palavras, o que o site está fazendo para proteger sua transação, para que você possa confiar nela?

HTTPS

Por padrão, um site não é seguro se ele usa o protocolo HTTP. Adicionar um certificado configurado através do host do site à rota, pode transformar o site de um site HTTP não seguro em um site HTTPS seguro. O ícone de cadeado geralmente indica que o site está protegido por HTTPS.

HTTP é uma sigla em inglês para Hypertext Transfer Protocol ou "Protocolo de Transferência de Hipertexto". Trata-se, portanto, de um código responsável por fazer a comunicação entre os dados de uma página na internet e quem está fazendo o acesso, geralmente, pela porta 80. Ou seja, é por causa dele que você está lendo este artigo.

O HTTP Over SSL, ou HTTPS, é uma implementação idêntica do HTTP, mas com uma camada adicional, o TLS.

Já vi artigos afirmarem que HTTPS, o S é de Secure (Seguro), mas isto induz ao erro, pois existe o SHTTP que é descrito na RFC, este sim é o "Secure Hypertext Transfer Protocol".

O HTTP Over SSL (HTTPS) é descrito na RFC 2818. Na documentação desta RFC, há uma descrição excelente: "Conceitualmente, HTTP/TLS é muito simples. Basta usar HTTP sobre TLS exatamente como você usaria HTTP sobre TCP"

SSL e TLS

TLS é a geração atual do antigo protocolo SSL (Secure Socket Layer).

O TLS atualmente na versão 1.2 (a mais adotada) está descrito na RFC. Há também o TSL 1.3.

A função do HTTPS é exatamente a mesma do HTTP, porém, o protocolo apresenta uma camada que criptografa os dados e a comunicação entre o servidor e quem está acessando, o SSL geralmente é realizada na porta 443. Desse modo, o servidor que é acessado para repassar os dados das páginas para o seu computador precisa ser autenticado por meio de chaves e certificados digitais para que seja garantida a segurança na conexão à página.

O agente que atua como cliente HTTP, também atua como cliente TLS. Ele deve iniciar uma conexão com o servidor na porta apropriada e, em seguida, envia um "Olá" (é o TLS ClientHello) para iniciar o "aperto de mão" (é o TLS handshake) - (assim ambos se conhecem e se comunicam ba-du-tsss rsrsss). Quando o handshake termina, o cliente inicia a primeira solicitação HTTP. Todos os dados HTTP seguintes SERÃO enviados com o tipo TLS "dados de aplicação", daí o HTTP sobre TLS.

CA

Você que está lendo este artigo confia no certificado que está neste site. O seu Sistema Operacional e/ou seu navegador possui instalado a CA (Autoridade de Certificação) e seu navegador confia nos certificados emitidos por ela. E, através de algumas validações, meu site possui um certificado válido emitido pela CA que seu computador confia.

Uma destas validações é o OCSP (Protocolo de Certificação Online de Estado) descrito na RFC 6960. Outras validações, como invalidação de certificados e autoridades são enviadas ao cliente no formato de atualização (este é um dos motivos da Microsoft ainda enviar atualizações ao Windows Vista e 7 e há bem pouco tempo atrás ao Windows XP).

No Linux, a lista de CA raiz estão em:

• /usr/share/ca-certificates/
• /usr/local/share/ca-certificates/
• /etc/ssl/certs/

Já acessou algum site do Governo Brasileiro e teve erro de TLS/SSL? Pois então, os certificados são gerados pelo órgão criado em 2001, voltado para Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil, porém, a CA raiz desta 'autoridade' não está nos sistemas ou navegadores, ou seja, o cliente não confia! O usuário deve baixar a CA raiz e instalar ele próprio em seu S.O. e/ou navegador para acessar sem erros.

Desde 2008, o ITI (Instituto Nacional de Tecnologia da Informação Brasileiro) tenta incluir a AC raiz brasileira na lista de certificados confiáveis do Firefox, a entidade brasileira ainda carece de uma auditoria exigida pela Mozilla, o que justifica a não inclusão do certificado no navegador. Não consegui dados sobre se existe um processo para inseri-los no Google Chrome.

HSTS

Diversos sites para implementar o HTTPS acabam utilizando o redirect nos servidores, isto era correto até 2012, de lá para cá existe o protocolo HSTS, descrito na RFC 6797. Este protocolo facilmente implementado com 1 linha apenas no Apache, Caddy e Nginx

O HTTP Strict Transport Security (HSTS) é um mecanismo de política de segurança que ajuda a proteger sites contra ataques de downgrade de protocolo e sequestro de cookies. A ativação do HSTS declara que os navegadores da WEB devem interagir apenas com o servidor usando uma conexão HTTPS segura e nunca por meio de uma conexão HTTP insegura. A política especifica um período de tempo durante o qual o servidor deve ser acessado de forma segura.

Ao usar o HSTS, o cliente entende que 100% da comunicação com aquele domínio DEVE ser via HTTPS, e o cache no header informa quando ele deve verificar novamente (ou seja, mesmo desativando o HSTS, o cliente continuará a forçar e usar o HTTPS por 1 ano - tempo médio usado na configuração do cache). Ou seja, com o HSTS, para alguém conseguir algum ataque como envenenar cookies, ou outro tipo de man-in-the-middle, precisaria não somente atacar o servidor do site original e desabilita-lo, mas também esperar 1 ano para poder enviar um http para o cliente alvo.

Para validar o HSTS em um site, basta executar o seguinte comando no terminal:

curl -s -D- https://esli-nux.com/ | grep -i Strict
strict-transport-security: max-age=31536000; includeSubDomains; preload

Para habilitar o HSTS no Apache, Nginx e Caddy:

No Apache:


Para Nginx, adicione o seguinte parâmetro em seu arquivo de configuração:


No Caddy, adicione no Caddyfile:


Para verificar toda a comunicação, pode-se executar no terminal:

openssl s_client -showcerts -connect esli-nux.com:443

Será obtido a lista de certificados, o detalhamento do handshake (cifra, protocolo, sessão...).