◇ OpenCyber Academy
Tecnólogo · Capítulo 2 · Português

Capítulo 2 — Redes e serviços de internet

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 2 — Redes e serviços de internet

Mapa da aula

Aula 02 publicada. Mapa, exemplo, EX004.

flowchart TD
  N0["2.1 Como uma requisição viaja"]
  N1["2.2 O que um certificado prova"]
  N2["2.3 Falhas comuns"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX004"]

Desenho lógico

flowchart LR
  N0["2.1 Como uma requisição viaja"]
  N1["2.2 O que um certificado prova"]
  N2["2.3 Falhas comuns"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX004"]
[2.1 Como uma requisição viaja]
    |
    v
[2.2 O que um certificado prova]
    |
    v
[2.3 Falhas comuns]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX004]

Objetivos de aprendizagem

Você vai (1) explicar o DNS, o HTTP e o TLS num serviço web municipal; (2) descrever o que os certificados TLS provam; (3) reconhecer falhas comuns no nível da rede.

2.1 Como uma requisição viaja

Quando um cidadão digita permits.harbourview.example, o navegador pergunta ao DNS o endereço do servidor, abre uma conexão TCP e inicia um handshake TLS antes de enviar qualquer requisição HTTP. Rosa aprende que a ordem importa: as respostas do DNS não são protegidas pelo TLS, de modo que um atacante que envenene o DNS poderia direcionar o navegador para outro lugar, mas as verificações do certificado TLS falhariam então, porque o atacante não consegue apresentar um certificado válido para o nome da prefeitura. É por isso que a validação de certificados é a âncora da segurança na web: ela detecta redirecionamentos que as camadas inferiores não conseguem impedir. Ela pratica o rastreamento dessas etapas num laboratório com domínios de teste.

2.2 O que um certificado prova

Um certificado TLS vincula o nome permits.harbourview.example a uma chave pública, com a assinatura de uma autoridade certificadora em que o navegador confia. A RFC 5280 define os campos, incluindo os nomes alternativos do titular e as datas de validade. O certificado prova que quem conclui o handshake detém a chave privada daquele nome; ele não prova que o site é seguro nem que o código da prefeitura está livre de bugs. Rosa explica isso à equipe de comunicação da prefeitura, que tinha dito aos cidadãos que "o cadeado significa que seus dados estão seguros", e sugere uma redação mais precisa, dizendo que a conexão é privada.

2.3 Falhas comuns

Rosa lista as falhas de rede que vai encontrar: certificados expirados, certificados sem um nome necessário, cadeias incompletas em que o servidor não envia o certificado intermediário, relógios errados nos clientes e clientes antigos que não conseguem negociar as versões modernas do TLS definidas na RFC 8446. Cada uma produz um erro diferente no navegador. Ela monta para a central de atendimento um guia de uma página que associa as mensagens de erro às causas prováveis, para que a equipe de primeiro nível possa coletar os detalhes certos antes de escalar. O guia depois reduz o tempo gasto no diagnóstico de problemas simples de certificado.

Exemplo resolvido

Rosa rastreia o DNS, o TCP e o TLS do site de licenças, corrige a frase "o cadeado significa segurança" e escreve um guia de erros e causas para a central de atendimento.

Caso sintético. Os domínios e as equipes são inventados; a RFC 5280 e a RFC 8446 são reais.

Erros e limites

O TLS sozinho não protege as consultas DNS. Um certificado válido não diz nada sobre a segurança da aplicação.

Exercícios

Síntese

A segurança na web se apoia na validação de certificados sobre camadas que, de outra forma, ficam desprotegidas; conhecer os padrões de falha acelera o diagnóstico.

Continue estudando — aula 02 (capítulo 02 de 30)

← Capítulo 01 · Índice das aulas · Capítulo 03 →

Continue para a próxima aula já escrita.