OpenSSL s_client не может подключиться к Tomcat 7 через APR

Question

Я сейчас в процессе обновления моих серверов Tomcat до Tomcat 7, используя соединитель APR с отключенным SSLv3. Вот мой соединитель:

<Connector port="8443" maxHttpHeaderSize="8192" 
      maxThreads="150" 
      enableLookups="false" disableUploadTimeout="true" 
      acceptCount="100" scheme="https" secure="true" 
      SSLEnabled="true" 
      SSLProtocol="TLSv1" 
      SSLCertificateFile="${CP_ROOT}/security/tomcat.crt" 
      SSLCertificateKeyFile="${CP_ROOT}/security/tomcat.key" /> 

Все, кажется, работает должным образом ... например. переход на страницу через HTTPS соответствует этой странице правильно. Однако мы используем балансировщик нагрузки F5, и как только я отключил SSLv3, настроенный монитор работоспособности начал работать с ошибкой для этого узла/порта. После некоторого поиска неисправностей на стороне F5, я решил попытаться диагностировать с помощью OpenSSL:

$ openssl s_client -connect casrept2.tc.columbia.edu:8443/cas/monitor.jsp  
CONNECTED(00000003) 
write:errno=54 

Проделав то же самое, но заставляя TLSv1 (-tls1), я могу подключить правильно:

$ openssl s_client -connect casrept2.tc.columbia.edu:8443/cas/monitor.jsp -tls1 
CONNECTED(00000003) 
... cert chain, etc, etc 

Мне интересно, если это приведет к сбою монитора работоспособности. В любом случае, мне любопытно, почему мне нужно специально заставить -tls1 для этого работать. Я бы предположил, что он должен автоматически согласовать правильный протокол?

Answer 1

Какая версия openssl вы используете для s_client? Если это серия 0.9.8, то по умолчанию используются протоколы ssl2, ssl3, tls1 (.0), для которых требуется использовать SSL2-формат ClientHello (но с содержимым, которое может договариваться до tls1.0). сервер openssl в Tomcat/APR с указанным только tls1 (вместо автоматического определения) будет либо вести переговоры, либо давать предупреждение в соответствующем для формата SSL3 +, но для формата SSL2 он просто закрывает TCP-соединение - и в по крайней мере, в Windows он делает это «ненормально» с помощью RST, который вызывает s_client, чтобы получить ошибку syscall и отобразить сообщение, которое вы видите. (Хотя 54 - это значение errno, которое я не помню для RST, можете сказать, какую ОС?)

Указывая s_client -tls1, вы вызываете его использование формата SSL3 +, содержащего версию 3.1 = TLS1.0, и это работает. Если вы используете -ssl3, он не может договориться, но он получает несколько более конкретный alert handshake failure, а не только ошибку TCP. Если вы используете -no_ssl2, который использует формат SSL3 + и согласовывает TLS1.0, хотя это менее удобно здесь, чем -tls1.

Если вы используете версии openssl 1.0.0 или 1.0.1 для s_client, они должны по умолчанию использовать минимальный SSL3 и (таким образом) SSL3 + приветственный формат и работать, если только что-то необычное не было сделано в процессе сборки.

Я не знаю, что делает монитор F5 здесь - или может это сделать - но это меня не удивит, если он попробует приветствовать формат SSL2 по теории, которая есть или в прошлом была - максимально взаимодействовать. Если это так, что приведет к сбою подключения, которое будет понятно интерпретировать как проблему с сервером. Вы можете пометить трассировку, такую ​​как www.wireshark.org или подобное на (или рядом) вашем сервере, и посмотреть, что именно отправляет F5, и подтвердить, что ваш сервер отвечает RST.