O que este app já está prometendo

Uma linha no config/environments/production.rb:

config.force_ssl = true

O curso de SSL disse que isso liga três coisas: o redirecionamento, os cookies seguros e o Strict-Transport-Security. Este curso é sobre o terceiro. E sobre com o que os valores padrão dele comprometem você, que é mais do que a maioria de quem escreveu aquela linha acredita.

O padrão, conferido

O ActionDispatch::SSL do Rails guarda os padrões, e eles são:

ActionDispatch::SSL.default_hsts_options
# => { expires: 63072000, subdomains: true, preload: false }

63.072.000 segundos são dois anos. E subdomains: true.

Então esta aplicação, com force_ssl = true e sem opções de HSTS definidas, envia:

Strict-Transport-Security: max-age=63072000; includeSubDomains

O Rails monta isso no build_hsts_header, acrescentando ; includeSubDomains quando subdomains é true e ; preload quando preload é. E o preload tem padrão false, que é a única escolha conservadora do conjunto.

O que isso significa

Todo navegador que visitou esta aplicação por HTTPS registrou uma regra. Pelos próximos dois anos, use HTTPS para este host e para todo subdomínio dele, e não ofereça à pessoa um jeito de contornar um erro de certificado.

Três consequências, todas já em vigor:

Todo subdomínio precisa servir HTTPS válido. Não os que existem hoje: todo um que alguém possa visitar. Uma ferramenta interna em metrics.nor.app com certificado autoassinado fica inalcançável para quem visitou o site principal, sem opção de prosseguir.

Isso não é desfeito removendo o cabeçalho. Os navegadores já têm a regra. Apagar a linha impede novos visitantes de recebê-la e não faz nada por quem já a tem, por até dois anos. A aula 4 é sobre o procedimento que funciona.

Um erro de certificado vira uma indisponibilidade. Sem HSTS, um certificado expirado mostra um aviso que alguém determinado consegue atravessar. Com ele, o navegador recusa, e não há como prosseguir, que é o objetivo, e remove a saída de emergência com que você talvez contasse.

flowchart TB
  F["config.force_ssl = true"] --> D["default_hsts_options do Rails"]
  D --> H["max-age=63072000; includeSubDomains"]
  H --> B["O navegador de toda visita registra"]
  B --> S["Todo subdomínio precisa ser HTTPS, por 2 anos"]
  B --> C["Um erro de certificado agora é falha dura"]
  B --> R["Remover a linha não desfaz"]

Esse é o ajuste certo?

Quase sempre sim, e vale deixar claro que ele foi um padrão e não uma decisão.

Dois anos é o valor forte padrão. A lista de preload exige pelo menos um ano, e o hstspreload.org recomenda dois. Ninguém sério defende um valor permanente menor; o argumento por um menor é sobre a rampa durante a implantação, que é a aula 4.

O includeSubDomains é o padrão certo e o caro. É o que torna o HSTS significativo (um cookie de sessão com escopo em .nor.app é tão seguro quanto o subdomínio menos seguro) e é também a cláusula que transforma uma ferramenta interna sem relação numa indisponibilidade. A aula 3 é o inventário que ela obriga a manter.

O que seria errado é não saber. Uma aplicação que herdou dois anos de imposição de HTTPS em todos os subdomínios a partir de um padrão de framework. E cujo time acredita ter ligado "um redirecionamento", assumiu um compromisso que ninguém na sala consegue descrever.

Definindo explicitamente

config.ssl_options = {
  redirect: { exclude: ->(request) { request.path == "/up" } },
  hsts: { expires: 2.years, subdomains: true, preload: false }
}

Os mesmos valores, escritos. Essa é a mudança que vale fazer antes de tudo neste curso. Não porque o comportamento muda, mas porque a próxima pessoa a ler o arquivo aprende o que a aplicação promete sem precisar conhecer um padrão de framework.

O que este curso cobre

1. O que este app já está prometendo (esta aula).
2. Como o HSTS funciona.
3. includeSubDomains e o inventário que ele obriga.
4. Subindo o max-age, e desligando.
5. A lista de preload.
6. HSTS em contexto.
7. Juntando tudo: um plano de HSTS.

Pontos-chave

• O force_ssl = true envia max-age=63072000; includeSubDomains (dois anos, todos os subdomínios) pelos padrões do Rails.
• O preload tem padrão false, que é o único padrão conservador do conjunto.
• O compromisso já está em todo navegador que visitou e não é desfeito apagando a linha.
• Todo subdomínio que alguém possa visitar precisa servir HTTPS válido, e um erro de certificado vira falha dura sem escapatória.
• Escreva as opções explicitamente, para a promessa ser legível sem conhecer um padrão de framework.