On 01.09.2015 17:08, ekassir wrote:

> Нужна была доступность протокола TLS 1.0, который используется приложениями,
> совместимость с которыми нужно было обеспечить.

> В итоге, пришлось для всего списка сайтой прописать TLS 1.0,
> чтобы он начал поддерживаться на нужном hostname.

> Кто знает, это бага или фича? Как обойти?

Директива ssl_protocols, хоть и указывается в контексте server`а,
на самом деле является свойством listen socket`а, а не server`а.

Потому что клиент сначала устанавливает TLS соединение с сервером,
а только после этого присылает HTTP-запрос в котором указано имя хоста.

Обойти можно просто, сделав различные listen socket`ы
с разными настройками, так чтобы они отличались
или номером порта или IP адресом. Например:

server {
listen 11.11.11.11:443 ssl;
ssl_protocols SSLv3;

}

server {
listen 22.22.22.22:443 ssl;
ssl_protocols TLSv1.1 TLSv1.2;

}

Есть необязательное расширение TLS протокола - Server Name Indication
https://tools.ietf.org/html/rfc6066#section-3

Но нюанс в том, что server_name там присылается
в не-защищенном виде как ClientHello extension,
И это имя ведь может не совпадать с имемен хоста,
который потом будет прислан по зашифрованному HTTP-протоколу.

https://idea.popcount.org/2012-06-16-dissecting-ssl-handshake/

Кроме того, Server Name Indication extension может и не быть.

> Есть идеи, как дебажить?

http://nginx.org/en/docs/debugging_log.html

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru