SSL proxying sur nginx – comportement différent dans différents clients

Je suis en train d'exécuter un service Web requirejs par SSL et j'ai l'intention de changer de fournisseur d'hébergement. Pour éviter les time d'arrêt pour nos users tandis que DNS caches est clair, je prévois les requests de proxy de notre ancien server vers le nouveau pour quelques jours. L'ancien et le nouveau site utilisent nginx et openssl.

J'ai une configuration qui semble fonctionner parfaitement dans Chrome et Firefox, mais échoue dans Safari et curl.

La section de configuration du proxy dans la configuration nginx (1.6.2) de mon ancien server est assez simple:

upstream droplet { server zin.droplets.gimlet.us:443; } server { listn 80; listn 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; } 

(modifier proxy_ssl_protocols et proxy_ssl_session_reuse ne semble pas faire une différence)

Fait intéressant, les requêtes de Safari et curl ne génèrent pas d'inputs de journal dans mes journaux / tmp. Cependant, dans l'erreur principale.log, j'ai une input comme:

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

La sortie de curl -v suggère une bonne poignée de main SSL se produit et quelque chose va mal:

 $ 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 certificatee: * subject: description=e08NImA1P8R1ukwA; C=US; ST=Wisconsin; L=Madison; O=Nathanael Vack; CN=*.gimlet.us; emailAddress=postmaster@gimlet.us * 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 certificatee 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): 

En particulier, en faisant

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

fonctionne bien.

J'ai l'printing de manquer quelque chose de très basique ici. Des suggestions quant à savoir où je peux chercher plus d'idées?

Notant que SSL semblait fonctionner avec d'autres domaines sur le même server, j'ai ajouté plus de directives de configuration SSL. Celui-là:

 ssl_session_cache shared:SSL:10m; 

a guéri les segfaults.

Je crois que ce billet est la question sous-jacente; nginx blesse OpenSSL.

La correction efficace du niveau nginx (et ce que je fais maintenant que je sais ce qui se passe) est de faire votre configuration SSL à l'échelle de Nginx dans le context http plutôt que de le répéter dans un tas de contexts de server .