Digamos que eu administre uma empresa "Example Inc" e tenha um site em:
Agora, porque estou preocupado com a segurança, estou usando https e gostaria de definir o cabeçalho HSTS para forçar seu uso. Eu também incluiria Subdomínios por muito tempo, digamos um ano.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Agora também sou um bom proprietário de site, então configurei o seguinte com redirecionamentos 301 para o site acima:
O último também possui o cabeçalho HSTS, bem como um site https.
Isso, pelo que entendi, é a configuração recomendada para executar um site https (além de muitas outras configurações, obviamente) e seria bastante comum.
Até agora tudo bem.
Agora internamente, na intranet da empresa, e não disponível na Internet, tenho muitos servidores e uso o domínio example.com. Então eu tenho:
- machine1.example.com
- machine2.example.com ...etc
Agora, supondo que algumas dessas máquinas executem servidores da Web e nem todas sejam https.
Isso não significa que, se algum de meus funcionários visitar https://example.com , o navegador definirá o cabeçalho HSTS e se recusará a acessar http para quaisquer subdomínios e, portanto, não poderá mais acessar alguns desses http-internos apenas servidores web?
Qual é a maneira de contornar isso?
Devo comprometer a segurança do meu site externo não usando a configuração includeSubDomains? Pelo menos não no site https://example.com ? Parece errado comprometer a segurança externa por uma questão interna.
Devo forçar todos os meus aplicativos internos a serem https também? Isso é mais fácil dizer do que fazer.
Devo usar um domínio diferente internamente? Por exemplo, machine1.intraexample.com? Parece um desperdício de um domínio e alguns itens (por exemplo, servidor de e-mail) precisarão estar no domínio principal, embora possivelmente possam ser limitados a https apenas servidores da web, se eles precisarem executá-los.
Quaisquer outros pensamentos?
Além disso, acho que isso pode causar um grande problema para uma empresa e possivelmente deve ser mais destacado na especificação e em outros lugares. Muitos proprietários de sites não têm configurações separadas para a versão não www e, portanto, podem definir inadvertidamente o sinalizador includeSubDomain no domínio de nível superior. Foi somente ao pensar nesse cenário antes da implementação que evitei isso. Vou definir o vencimento muito baixo inicialmente (um dia) para resolver esses problemas também, o que também poderia ser sugerido com mais força IMHO. Isso poderia facilmente ter sido perdido e causado problemas estranhos para muitos usuários.
Editar junho de 2015 E aqui está um exemplo do mundo real de um site fazendo exatamente isso errado: https://github.com/NuGet/NuGetGallery/issues/2535
Editar outubro de 2015 Um artigo que sugere que você realmente deve usar includeSubDomains em TLD para corrigir falhas em cookies: http://www.kb.cert.org/vuls/id/804060 . Isso é verdade (um hacker com acesso DNS poderia criar um subdomínio fictício e usá-lo para definir um cookie no nível TLD). No entanto, o risco acima de auto DoSing sites internos somente HTTP ainda existe com isso, e isso só fornecerá proteção de você ir para TLD ou pré-carregar HSTS.