Cache HTTPS não transparente com expiração do último acesso

Question

Gostaria de configurar um servidor de cache para arquivos baixados. Uma torção é que eu quero que ele trabalhe com HTTPS (incluindo redirecionamentos de HTTP para HTTPS). Eu entendo os problemas habituais com isso, mas a diferença para mim é que isso não precisa ser um proxy transparente. Por exemplo:

# Usually you'd do something like this:
curl --proxy myserver:8080 https://example.com/file.tar.gz

# But it's fine for our scripts to call something like this instead:
curl myserver:8080 --data-raw https://example.com/file.tar.gz

Note que aqui o cliente está direcionando especificamente sua requisição para o myserver, então ele não tentará verificar se a resposta vem de example.com . (Meu servidor deve embora!)

A outra diferença é que isso só será usado para arquivos que nunca mudam (as URLs incluem o número da versão), então as coisas usuais sobre a atualização do cache não se aplicam. Se o arquivo (ou resposta de redirecionamento) for armazenado em cache, ele deverá ser retornado sem verificar a Internet. A cópia em cache deve ser excluída por um período fixo depois de última solicitação, independentemente de quando baixada pela primeira vez em nosso final.

Pergunta: Eu esperava usar um proxy HTTP como o Squid, mas não consigo ver como configurá-lo para fazer algo assim. Alternativamente, escrever um pouco de código é uma opção, mas prefiro evitar isso. O que eu poderia fazer para estabelecer um cache como esse?

Plano de fundo: ele deve ser usado principalmente para bibliotecas de terceiros que usaremos em nosso código-fonte, ao criar imagens do Docker e quando os desenvolvedores estiverem criando fora dos contêineres. Às vezes, atualmente, verificamos o código de terceiros para nossos próprios repositórios, mas isso não é o ideal. Tenho certeza de que não somos as únicas pessoas que enfrentam esse problema, mas não consigo encontrar uma boa solução na Web ... talvez esteja perdendo o termo de pesquisa correto.

    

Answer 1

Isso é possível e requer três alterações de configuração:

1. Configure o SSL Bump para executar a descriptografia man-in-the-middle, a fim de tornar o conteúdo disponível para armazenamento em cache
2. Use o parâmetro refresh_pattern do Squid para garantir que o Squid armazene (e armazene) os objetos que você deseja armazenar
3. Ajuste o parâmetro maximum_object_size para que seja pelo menos tão grande quanto o arquivo máximo que você planeja fazer o download .

Você deve estar ciente de que depois de configurar o bump SSL, o Squid criará & Emita um certificado auto-assinado para cada domínio que está configurado para colidir. Seu cliente deve aceitar este certificado para que a transferência ocorra. O cURL pode fazer isso com o parâmetro --cacert (permitindo que ele aceite CAs cuja chave pública apareça na lista) ou o parâmetro -k (desabilita a verificação SSL completamente).

Além disso, há uma diferença sutil (mas importante) na maneira como os dois comandos cURL que você mencionou acima funcionam. O primeiro fará com que o cURL abra uma conexão como se estivesse falando com um proxy, ou seja, abra a porta, emita uma instrução "CONNECT", espere que o handshake SSL ocorra e comece a falar em HTTP. A segunda chamada fará com que o cURL abra uma conexão e tente o handshake SSL imediatamente. Nesse caso, o host (executando o Squid) deve descobrir qual host se conectar, geralmente da parte SNI do handshake. O Squid pode fazer isso, mas você precisa configurá-lo com a declaração link . Eu recomendaria fazê-lo através do primeiro método se você puder, já que requer menos configuração no lado do Squid, e deixa claro no lado do cliente que um proxy está envolvido.