preocupações com segurança SSL SNI

Question

Basta saber se o SNI é útil para segregar conteúdo público de conteúdo privado. Consegui configurar nosso servidor para servir /foo para cada cliente, mas veiculando /bar apenas para clientes da intranet, especificando o nome do host que é resolvido somente da intranet.

Então a configuração é como: (despojada para parte muito essencial)

NameVirtualHost *:443
# JkWorkersFile must be global so including it here
JkWorkersFile workers.properties

<VirtualHost *:443>
  ServerName public.foo.com
  JkMountFile uriworkermap-pub.properties
</VirtualHost>

<VirtualHost *:443>
  ServerName private-foo
  JkMountFile uriworkermap-priv.properties
</VirtualHost>

<VirtualHost *:443>
  ServerName 10.1.2.3
  JkMountFile uriworkermap-priv.properties
</VirtualHost>

O problema é que, se você adicionar esse nome ao arquivo hosts para resolver o IP público, o SNI resolverá resolvê-lo da mesma maneira como se fosse uma solicitação válida da intranet.

Eu brinquei com o pensamento de usar apenas IP numérico ao invés de nomes (por exemplo, 10.1.2.3 ) mas presumo que o mesmo pode ser enganado se o cliente tiver o mesmo IP em sua própria sub-rede (por exemplo, um host Linux que encaminha portas para o IP público do meu servidor web.

O nó fica atrás de um firewall no qual não tenho influência. Ele tem apenas um IP (o interno), mas, se necessário, eu provavelmente posso fazer dois.

A questão prática é: como você evita esse vazamento? Por meio de htaccess por exemplo? Especificando diferentes endereços IP? Ou não há outra maneira de criar uma instância de servidor separada e esquecer o SNI?

    

Answer 1

Se você precisar restringir o conteúdo com base na origem dos visitantes do site, use essas informações como o controle de acesso primário (e não apenas o nome do recurso que você está tentando proteger).

Com o Apache 2.2, seria o Allow Directiva.

<VirtualHost *:443>
  ServerName private-foo
  <Location />
    Order Deny,Allow
    Deny from all
    # Allow from the internal subnet 10.1.2.0/24
    Allow from 10.1.2
  </Location>
  ...

Geralmente, em seu cenário, um servidor teria um endereço IP interno e um endereço IP público e, como os usuários internos só usariam esse endereço IP interno, você ligaria o host virtual apenas a esse IP interno, por exemplo, <VirtualHost 10.1.2.3:443> em vez de ouvir todos os IPs

Além disso, sua observação em relação ao .htaccess acionou minha implicância, citada no manual no .htaccess arquivos:

You should avoid using .htaccess files completely if you have access to httpd main server config file. Using .htaccess files slows down your Apache http server. Any directive that you can include in a .htaccess file is better set in a Directory block in the main Apache configuration file(s), as it will have the same effect with better performance.

    

Answer 2

O que você está tentando é chamado de "segurança através da obscuridade" - você não conseguiu garantir o recurso, você está apenas esperando que ninguém saiba procurá-lo a menos que seja de dentro da sua empresa.

Além disso, o SNI não tem nada a ver com esse problema. Você teria exatamente o mesmo problema se o conteúdo fosse veiculado por HTTP sem nenhum certificado e tentasse bloquear o conteúdo, ocultando-o usando nomes de host separados.

Isso não é realmente seguro.

Se você quiser pré-acessar o recurso, precisará fazê-lo de alguma outra forma. Uma maneira seria configurar uma instância de servidor separada, em um IP separado e usar firewalls para proteger essa instância. Outra seria usar um bloco baseado em IP no servidor virtual que contém o conteúdo restrito ou o diretório. Ou você pode combiná-lo com a exigência de que o cliente use um certificado emitido pela sua CA interna, se tiver um. Ou praticamente qualquer outra maneira de combinar autenticação com autorização.

Mas esperar que ninguém fora de sua empresa tente usar o nome de host "secreto" não é uma medida de segurança válida, independentemente de você usar SSL / SNI ou não.