Conexões SSL NGINX Tempo limite

Question

Estou tentando fazer com que o software do servidor da Web seja executado em algumas caixas ARM que temos. Consegui fazer com que o NGINX funcionasse exatamente como esperado ao usar HTTP, mas quando tento alternar a configuração para usar HTTPS, o tempo limite das conexões é excedido.

As caixas ARM estão usando o Linux 2.6 (eu sei ...) e não tem muita memória, então é totalmente possível que o uso de SSL não seja viável se houver requisitos de recursos.

Aqui está a parte relevante do / etc / nginx / sites-available / mysite (que é um link simbólico para sites habilitados / mysite):

server {
    #listen *:443 ssl default_server;
    listen *:80 default_server;

    server_name <box IP address>;

    root /var/www/myserver;

    proxy_buffering off;

    #ssl on;

    #ssl_session_cache shared:SSL:10m;

    #ssl_protocols TLSv1.2;
    #ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    #ssl_prefer_server_ciphers on;

    #ssl_certificate /etc/nginx/ssl/myserver.crt;
    #ssl_certificate_key /etc/nginx/ssl/myserver.key;

    location /htdocs {
            autoindex on;
            try_files $uri $uri/ =404;
    }
}

E o /etc/nginx/nginx.conf tem principalmente os padrões:

user  www-data;
worker_processes  auto;

error_log  /var/log/nginx/error.log debug;

pid        /run/nginx/nginx.pid;

events {
    worker_connections  64;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    include /etc/nginx/sites-enabled/*;
}

Quando a configuração acima é usada, eu posso acessar a caixa em seu endereço IP e ela serve corretamente documentos em / var / www / myserver / htdocs /. No entanto, quando eu descompartilhar todas as linhas comentadas em sites / mysite disponíveis e comento a linha listen *:80 default_server , todas as tentativas de conexão HTTPS expirarão. Os logs de erro e acesso não possuem entradas para as conexões com tempo limite. Estou usando um certificado autoassinado por enquanto, mas não acho que isso faça alguma diferença. Solicitações com wget e curl de outro host também atingem o tempo limite.

Não há um firewall ativo, portanto, a porta 443 não está sendo bloqueada. Eu posso ver a ligação NGINX à porta 443 na caixa ARM. Eu também posso ver que a tentativa de conexão do meu computador para a porta 443 na caixa é ESTABLISHED, em netstat.

Estou usando o NGINX 1.12.2 criado a partir do código-fonte. Estes são os argumentos de configuração:

--prefix=/usr --conf-path=/etc/nginx/nginx.conf --pid-path=/run/nginx/nginx.pid --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --with-pcre=../pcre-8.41 --with-zlib=../zlib-1.2.11 --with-http_ssl_module --with-stream --user=www-data --group=www-data --with-http_v2_module

A caixa ARM tem o OpenSSL 1.0.2l instalado, que também construí da fonte.

Existe um culpado óbvio que causa o tempo limite do NGINX em conexões SSL? Se não for óbvio, quais são os passos que posso dar para depurar as conexões?

Atualização:

Quando eu executo o NGINX manualmente (depois de adicionar daemon off; na configuração), recebo um comportamento estranho que pode ser uma dica. Estas são as etapas que estou seguindo:

1. inicie o NGINX na caixa ARM ( sudo nginx )
2. use o Curl em outra máquina para tentar uma solicitação ( curl -v -k https://<box IP>/htdocs/css/main.css )
3. pressione Ctrl + C na caixa ARM para matar o NGINX

Na etapa 2, o curl aguarda a resposta, mas nada acontece. Em seguida, na etapa 3, o curl exibe o arquivo solicitado. É como se a resposta do Nginx estivesse sendo armazenada em buffer e esse buffer não estivesse sendo liberado até o processo NGINX terminar. Isso também mostra que o NGINX está concluindo o handshake SSL, mas não está enviando a resposta.