Digamos que eu gerencie uma empresa "Example Inc" e tenha um website em:
link
Agora, porque tenho consciência de segurança, estou usando https e gostaria de definir o cabeçalho HSTS para forçar seu uso. Eu também incluo o Subdomínio por um longo tempo, digamos um ano.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Agora, também sou um bom dono de site, por isso configurei o seguinte com redirecionamentos 301 para o site acima:
O último também tem o cabeçalho HSTS, bem como um site https.
Isso, no meu entender, é a configuração recomendada para a execução de um site https (além de muitas outras configurações, obviamente) e seria bastante comum.
Até aí tudo bem.
Agora, internamente, na intranet da empresa e não disponível na Internet, tenho muitos servidores e uso o domínio exemplo.com. Então eu tenho:
- machine1.example.com
- machine2.example.com
... etc
Agora, suponhamos que algumas dessas máquinas executem servidores da web e nem todas sejam https.
Isso não significa que, se algum dos meus funcionários visitar o link , o navegador definirá o cabeçalho da HSTS e recusará o acesso a http qualquer sub-domínio e, portanto, não pode mais acessar alguns desses servidores internos apenas http?
Qual é o caminho disso?
Devo comprometer a segurança do meu site externo ao não usar a configuração includeSubDomains? Pelo menos não no site link ? Isso parece errado em comprometer a segurança externa para um problema interno.
Devo forçar todos os meus aplicativos internos a serem https também? É mais fácil falar 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 apenas servidores da Web baseados em https, caso precisem executá-los.
Algum outro pensamento?
Além disso, pense que isso poderia causar um grande problema para uma empresa e, possivelmente, deve ser destacado mais 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, por isso, podem definir inadvertidamente o sinalizador includeSubDomain no domínio de nível superior. Foi só quando pensei neste cenário antes da implementação que evitei isso. Vou definir a expiração muito baixa 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 recebendo esta coisa errada:
link
Editar outubro de 2015
Um artigo que sugere que você realmente deve usar includeSubDomains no TLD para solucionar as falhas nos cookies: link . Isso é verdade (um hacker com acesso ao DNS poderia criar um subdomínio fictício e usá-lo para definir um cookie no nível de TLD). No entanto, acima do risco de auto-sites internos somente HTTP DoSing ainda existe com isso, e isso só irá fornecer proteção de você ir para o TLD ou pré-carregar HSTS.