ocasionais erros SSL no nginx 1.13.8 com vamos criptografar o cert

Question

Estou usando um nginx / 1.13.8 auto-compilado com os módulos adicionais brotli e headers-more-nginx-module, mas meu bug ocorre independentemente da ativação do brotli ou não. O servidor está executando o Debian 9. Na maioria das vezes, tudo funciona, mas às vezes uma ou algumas solicitações (por exemplo, css / js ressources) resultam nos seguintes erros. Todos os pedidos são servidos através de http / 2:

chrome : ERR_SPDY_PROTOCOL_ERROR

firefox : falha no carregamento

safari : kCFErrorDomainCFNetwork-Fehler 303

edge : (mesmo bug, não pode testá-lo agora; vai atualizar isso mais tarde)

Meu nginx SSL Config (que parece estar bem (A +) de acordo com o ssllabs):

ssl_certificate      "/etc/letsencrypt/live/***/fullchain.pem";
ssl_certificate_key  "/etc/letsencrypt/live/***/privkey.pem";
ssl_protocols TLSv1.2;
ssl_dhparam /etc/ssl/dhparam.pem;

ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;

    #raymii.org/s/tutorials/Strong_SSL_Secruity_On_nginx.html
ssl_ciphers  'EECDH-AESGCM:EDH+ESGCM:AES256+EECDH:AES256+EDH';
    ssl_prefer_server_ciphers  on;

Como sou novo em servidores e gerenciamento de servidores, não tenho ideia de como posso depurar esse problema. Tudo o que sei é que o erro mais provável não aconteceu com o nginx do repositório debian, mas não tenho certeza.

Meu palpite é que isso tem algo a ver com as cifras, porque desde que eu as mudei de seu último valor, o erro ocorre com menos frequência. Server-Log parece bem: por exemplo:

**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /portal HTTP/2.0" 200 383 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /styles.a01bb74b47d88d296c44.bundle.css HTTP/2.0" 200 24238 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /inline.bfe190f13378e2257d4e.bundle.js HTTP/2.0" 200 731 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /polyfills.74b809925dee18bd9f89.bundle.js HTTP/2.0" 200 19182 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /scripts.1cd17589767e3c3fbdfe.bundle.js HTTP/2.0" 200 40807 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"

**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /main.c0a6975cd3e3b14f7b2a.bundle.js HTTP/2.0" 200 0 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
--> The one that failed in this case! - looks fine?

A propósito, isso acontece em diferentes dispositivos com diferentes sistemas operacionais.

    

Answer 1

Acho que encontrei a solução (mas não tenho 100% de certeza!). Como o log de erros diz (veja meu comentário na pergunta), há problemas de permissão negada em /var/lib/nginx/proxy/** . todos os diretórios e arquivos pertenciam a "nobody" enquanto nginx estava sendo executado como "nginx". Eu mudei o dono do processo nginx para "nobody", agora funciona.

De qualquer forma, como poderia funcionar 90% do tempo e 10% do tempo que caiu? Na minha opinião, a permissão negada deve ou acertar o tempo todo ou nunca ... mas às vezes?

    

Answer 2

Dependendo do tamanho do arquivo que está sendo proxied, o nginx pode armazenar em buffer no disco.

Meu palpite é que os arquivos com falha são maiores do que os que são bem-sucedidos. Então, apenas nesses casos, ele tenta armazená-lo em buffer e falha nele.

O que você está recebendo não são erros de SSL, mas erros de protocolo http / spdy. O mais provável é que o tamanho definido no cabeçalho de duração do conteúdo seja incompatível com o valor transferido. Espero que responda à sua pergunta sobre o motivo da falha.