Um servidor proxy pode armazenar GETs SSL em cache?Caso contrário, a criptografia do corpo de resposta seria suficiente?

Question

Um (||qualquer) servidor proxy pode armazenar em cache o conteúdo solicitado por um cliente por meio de https?Como o servidor proxy não consegue ver a string de consulta ou os cabeçalhos http, acho que eles não conseguem.

Estou considerando um aplicativo de desktop, executado por várias pessoas por trás do proxy de suas empresas.Este aplicativo pode acessar serviços pela Internet e eu gostaria de aproveitar as vantagens da infraestrutura de cache da Internet integrada para 'leituras'.Se os servidores proxy de cache não puderem armazenar em cache o conteúdo entregue por SSL, simplesmente criptografar o conteúdo de uma resposta seria uma opção viável?

Estou considerando que todas as solicitações GET que desejamos armazenar em cache sejam solicitadas por http com o corpo criptografado usando criptografia assimétrica, onde cada cliente possui a chave de descriptografia.Sempre que desejarmos realizar uma operação GET que não seja armazenável em cache, ou uma operação POST, ela será realizada através de SSL.

Answer 1

Não, não é possível armazenar https diretamente em cache.Toda a comunicação entre o cliente e o servidor é criptografada.Um proxy fica entre o servidor e o cliente, para armazená-lo em cache, você precisa ser capaz de lê-lo, ou seja, descriptografar a criptografia.

Você pode fazer algo para armazená-lo em cache.Você basicamente faz o SSL no seu proxy, interceptando o SSL enviado ao cliente.Basicamente, os dados são criptografados entre o cliente e seu proxy, são descriptografados, lidos e armazenados em cache, e os dados são criptografados e enviados no servidor.A resposta do servidor também é descriptografada, lida e criptografada.Não tenho certeza de como você faz isso nos principais softwares proxy (como o squid), mas é possível.

O único problema com esta abordagem é que o proxy terá que usar um certificado autoassinado para criptografá-lo para o cliente.O cliente poderá saber que um proxy intermediário leu os dados, pois o certificado não será do site original.

Answer 2

O comentário de Rory de que o proxy teria que usar um certificado autoassinado se não fosse estritamente verdadeiro.

O proxy pode ser implementado para gerar um novo certificado para cada novo host SSL com o qual for solicitado e assiná-lo com um certificado raiz comum.No cenário do OP de um ambiente corporativo, o certificado de assinatura comum pode ser facilmente instalado como uma CA confiável nas máquinas clientes e eles aceitarão com prazer esses certificados SSL "falsificados" para o tráfego que está sendo proxy, pois não haverá incompatibilidade de nome de host.

Na verdade, é exatamente assim que softwares como o Proxy de depuração da Web Charles permitir a inspeção do tráfego SSL sem causar erros de segurança no navegador, etc.

Answer 3

Eu acho que você deveria apenas usar SSL e contar com uma biblioteca cliente HTTP que faz cache (Ex:WinInet no Windows).É difícil imaginar que os benefícios do cache em toda a empresa compensem a dor de escrever um esquema de criptografia de segurança personalizado ou um certificado divertido no proxy.Pior ainda, no esquema de criptografia que você mencionou, fazer cifras assimétricas no corpo da entidade parece um grande impacto no desempenho no lado do servidor do seu aplicativo;há uma razão pela qual o SSL usa cifras simétricas para a carga útil real da conexão.

O aplicativo em questão não é um aplicativo de navegador, é um aplicativo de desktop que extrai dados da Internet.O que vai acontecer é que todas as instâncias do aplicativo extrairão a mesma parte mais ou menos ao mesmo tempo.Esses dados precisam ser protegidos, mas espero aumentar o desempenho fazendo com que algumas instâncias do aplicativo obtenham uma versão em cache do servidor proxy corporativo.

Os blocos de dados são pequenos, mas podem ser solicitados com frequência.Essencialmente, todas as instâncias de aplicativos solicitarão os mesmos dados ao mesmo tempo.

O corpo dos dados/mensagem no lado do servidor será pré-criptografado e armazenado em cache em uma tabela hash distribuída na memória.A criptografia não será realizada por solicitação.

Também estou investigando o uso de um barramento de mensagens, como o NServiceBus.

Answer 4

Confira www.bluecoat.com é um proxy comercial que na verdade PODE fazer interceptação de https para bloquear sites, restringir conteúdo, inspecionar vírus e conteúdo de cache (GETs)

Answer 5

Eu acho que você deveria apenas usar SSL e contar com uma biblioteca cliente HTTP que faz cache (Ex:WinInet no Windows).É difícil imaginar que os benefícios do cache em toda a empresa compensem o trabalho de escrever um esquema de criptografia de segurança personalizado ou um certificado divertido no proxy.Pior ainda, no esquema de criptografia que você mencionou, fazer cifras assimétricas no corpo da entidade parece um grande impacto no desempenho no lado do servidor do seu aplicativo;há uma razão pela qual o SSL usa cifras simétricas para a carga útil real da conexão.

Answer 6

Que tal configurar um cache de servidor no servidor de aplicação por trás do componente que criptografa as respostas https?Isso pode ser útil se você tiver uma configuração de proxy reverso.

Estou pensando em algo assim:

application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)