SSL proxying no nginx - comportamento diferente em diferentes clientes

Question

Estou executando um serviço da Web requerido por SSL e planejando alternar os provedores de hospedagem. Para evitar o tempo de inatividade de nossos usuários enquanto os caches de DNS estão limpos, planejo fazer proxy de solicitações do nosso servidor antigo para o novo por alguns dias. Tanto o site antigo quanto o novo estão rodando nginx e openssl.

Eu tenho uma configuração que parece funcionar perfeitamente no Chrome e no Firefox, mas falha no Safari e no curl.

A seção de configuração do proxy na configuração nginx (1.6.2) do meu servidor antigo é bem simples:

upstream droplet {
    server zin.droplets.gimlet.us:443;
}

server {
    listen   80;
        listen   443 ssl;
        server_name demo.gimlet.us;
#   proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#   proxy_ssl_session_reuse off;
    proxy_set_header Host       $host;
    location / {
        proxy_pass https://droplet;
    }
    error_log /tmp/proxy_error.log;
    access_log /tmp/proxy_access.log;
}

(alterar proxy_ssl_protocols e proxy_ssl_session_reuse não parece fazer diferença)

Curiosamente, as solicitações do Safari e do curl não geram entradas de log nos meus logs / tmp. No entanto, no error.log principal, recebo uma entrada como:

2014/11/21 17:02:08 [alert] 2937#0: worker process 13634 exited on signal 11

A saída de curl -v sugere que um bom handshake SSL acontece e, então, algo dá errado:

$ curl -v https://demo.gimlet.us/favicon.ico
* About to connect() to demo.gimlet.us port 443 (#0)
*   Trying 74.50.48.201...
* connected
* Connected to demo.gimlet.us (74.50.48.201) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: description=e08NImA1P8R1ukwA; C=US; ST=Wisconsin; L=Madison; O=Nathanael Vack; CN=*.gimlet.us; [email protected]
*    start date: 2014-04-10 16:59:37 GMT
*    expire date: 2016-04-11 09:29:37 GMT
*    subjectAltName: demo.gimlet.us matched
*    issuer: C=IL; O=StartCom Ltd.; OU=Secure Digital Certificate Signing; CN=StartCom Class 2 Primary Intermediate Server CA
*    SSL certificate verify ok.
> GET /favicon.ico HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8z zlib/1.2.5
> Host: demo.gimlet.us
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host demo.gimlet.us left intact
curl: (52) Empty reply from server
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

Também notavelmente, fazendo

$ curl http://demo.gimlet.us/favicon.ico

funciona bem.

Eu sinto que estou sentindo falta de algo muito básico aqui. Alguma sugestão de onde posso procurar mais ideias?

    

Answer 1

Ao notar que o SSL parecia funcionar com outros domínios no mesmo servidor, adicionei mais diretivas de configuração SSL. Este aqui:

ssl_session_cache shared:SSL:10m;

curou os segfaults.

Acredito que este tíquete é a questão subjacente; O nginx culpa o OpenSSL.

A correção efetiva do nível nginx (e o que estou fazendo agora que sei o que está acontecendo) é fazer sua configuração SSL em todo o nginx no contexto http , em vez de repeti-la em vários contextosserver .