Versión del protocolo de alerta tlsv1 cuando se conecta a través de SSL al servidor OS X

¿Cómo puedo volver a habilitar TLS 1.1 y 1.0 en el servidor 5.3 con macOS 10.12.4 a corto plazo mientras evalúo todos los clientes que no están listos para TLS 1.2?

Si salta al final, los intentos de cambiar los archivos de configuración han fallado hasta ahora para restaurar la compatibilidad con versiones anteriores.

SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2

Después de haber actualizado nuestro servidor a macOS 12.4 y la aplicación del servidor a la versión 5.3, el uso curlpara conectarse a un sitio https del servidor macOS desde una máquina Linux dejó de funcionar, emitiendo los siguientes mensajes en el lado del cliente:

$ curl -v --insecure -o "output.file" https://myserver.domain/path/page.php
* About to connect() to myserver.domain port 443 (#0)
*   Trying 192.168.xxx.xxx... connected
* Connected to myserver.domain (192.168.xxx.xxx) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
* Closing connection #0

La conexión funcionó bien antes de la actualización del servidor macOS. Entonces parece que la actualización desactivó una opción de conexión en la que curlse basa. Busqué mucho en Google, pero todavía no estoy seguro de cuál es exactamente la causa.

El mismo curlcomando funciona cuando se ejecuta desde otra Mac. La máquina Linux tiene

$ curl --version
curl 7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

mientras está en el cliente de Mac

$ curl --version
curl 7.51.0 (x86_64-apple-darwin16.0) libcurl/7.51.0 SecureTransport zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets 

Desafortunadamente, no es una opción intentar actualizar curlen la máquina Linux.

Algunos recursos afirman que los conjuntos de cifrado incompatibles son la causa, pero después de algunas pruebas, no he podido encontrar una solución usando la --ciphersopción, y tampoco estoy seguro de cómo encontrar un conjunto de cifrado compatible.

He intentado averiguar qué cambió con macOS Server 5.3, pero el registro de cambios de Apple no me da ninguna pista al respecto. Entonces la pregunta es:

¿Qué ha cambiado en macOS 12.4 y/o macOS Server 5.3 y cómo puedo reconfigurar mi servidor macOS para que la curlconexión vuelva a funcionar?

Actualización 1:

He expuesto temporalmente el puerto 443 al público, para poder realizar las pruebas de SSL Labs . Los resultados muestran que mi servidor macOS solo admite TLS 1.2 y nada más. Para varios clientes simulados, el informe de prueba Server sent fatal alert: protocol_version, incluidos, por ejemplo, IE8-10/Win7 y Java7u25.

He intentado reactivar TLS 1 y 1.1 en

  • /library/server/web/config/apache2/sites/0000_127.0.0.1_34543_myserver.domain.conf
  • /library/server/web/config/apache2/httpd.conf
  • /library/server/web/config/apache2/httpd_server_app.conf
  • /library/server/web/config/proxy/apache_serviceproxy.conf(múltiples instancias aquí)

cambiando

SSLProtocol -all +TLSv1.2

en

SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2

o incluso

SSLProtocol All

pero no hizo ninguna diferencia al obtener la URL con curl.

Actualización 2:

El registro de errores del proxy del servicio muestra

[datetime] [ssl:info] [pid n] [client x.x.x.x:38805] AH02008: SSL library error 1 in handshake (server myserver.domain:443)
[datetime] [ssl:info] [pid n] SSL Library Error: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
[datetime] [ssl:info] [pid n] [client x.x.x.x:38805] AH01998: Connection closed to child 11 with abortive shutdown (server myserver.domain:443)

Para mí, parece que mis intentos de activar TLS v1 no funcionan.

Entonces la pregunta es: ¿ Cómo puedo reactivar TLS v1 en macOS Server Apache?

Respuestas (3)

curl 7.19.0 ... OpenSSL/0.9.8h

Esta es una versión muy antigua (y no compatible) de OpenSSL que está utilizando aquí y que no admite protocolos modernos como TLS 1.2 y cifrados ECDHE modernos. Hay muchas posibilidades de que después de la actualización, su servidor ahora requiera dicho protocolo y/o cifrado y, por lo tanto, la conexión con su versión anterior de OpenSSL fallará.

* SSLv3, TLS handshake, Client hello (1):

Esto también podría indicar que su cliente está tratando de usar SSL 3.0, que generalmente está deshabilitado hoy en día porque es un protocolo inseguro. Puede intentar forzar el uso de TLS 1.0 (que es compatible con OpenSSL 0.9.8) utilizando curl -1o curl --tls1con la esperanza de que el servidor aún admita TLS 1.0 y tenga cifrados configurados para que la versión anterior de OpenSSL pueda utilizarlos.

curl 7.19 puede ser antiguo, pero aún se conecta bien con cualquier otro sitio web https que haya probado (google.com, etc.). De acuerdo con los archivos de configuración httpd, el servidor macOS admite TLS 1, 1.1 y 1.2, pero usar -1 con curl no ayudaría. La salida de seguimiento de curl no parece ser muy útil. ¿Tiene alguna otra idea de cómo localizar la causa de los problemas de conexión?
@not2savvy: mirar los mensajes de registro en el servidor podría ayudar, ya que el servidor es el que envía la alerta TLS porque no le gusta algo que el cliente ha enviado. Si su servidor es público, también puede compararlo con SSLLabs , que también muestra el comportamiento con clientes o bibliotecas específicos.
No hay mensajes en el registro de apache. El servidor no es público. Lo intenté openssl s_client -connect myserver.domain:443desde mi Mac, pero da como resultado CONNECTED(00000003) 16140:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_lib.c:185:. Y si agrego -tls1, obtengo 31629:error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version:s3_pkt.c:1053:SSL alert number 70además de los mensajes anteriores.
Logré ejecutar las pruebas de SSLLabs en nuestro servidor. He actualizado mi pregunta con los resultados.
@not2savvy: entonces mi suposición con la versión TLS era correcta. ¿Reinició el servidor después de realizar el cambio de configuración para permitir TLS 1.0? ¿Y volvió a verificar con SSLLabs porque tal vez ahora TLS 1.0 ya no sea el problema sino los cifrados?
Sí, reinicié el servidor web y volví a verificar con SSL Labs, pero todavía no está activo ningún otro protocolo que no sea TLS v1.2. Parece que todavía no he encontrado el archivo de configuración correcto.
Encontré un mensaje de error en el registro del proxy del servicio. Consulte mi pregunta actualizada.
@not2savvy: desafortunadamente, aunque conozco los problemas de SSL, no tengo idea de qué archivos de configuración usa el servidor MacOS y no veo ninguna documentación al respecto.
Su respuesta no se ajusta a mi pregunta, por lo que no puedo aceptarla, pero la voté porque ayudó a identificar el problema.

Para volver a habilitar TLSv1 (u otros protocolos), se requiere modificar la configuración del proxy en /Library/Server/Web/config/proxy/apache_serviceproxy.conf, agregando el protocolo requerido a la <VirtualHost *:443>sección así:

<VirtualHost *:443>
  ProxyPreserveHost On
 SetEnv proxy-chain-auth on
 RequestHeader set X-Forwarded-Proto "https"
 RequestHeader set X-Forwarded-Port "443"
 RequestHeader unset Proxy early
 <IfModule mod_ssl.c>
   SSLEngine On
   SSLCertificateFile "/etc/certificates/${CERT_ID}.cert.pem"
   SSLCertificateKeyFile "/etc/certificates/${CERT_ID}.key.pem"
   SSLCertificateChainFile "/etc/certificates/${CERT_ID}.chain.pem"
   SSLCipherSuite "HIGH:MEDIUM:!MD5:!RC4:!3DES"
   SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
   SSLProxyEngine On
   SSLProxyProtocol -all +TLSv1.2
   SSLProxyCheckPeerCN off
   SSLProxyCheckPeerName off
 </IfModule>
 [...]
</VirtualHost>

Según mis pruebas, SSLProxyProtocolno necesita ser modificado. Además, los cambios en los otros archivos mencionados en la pregunta no tienen efecto, por lo que no es necesario tocarlos.

Advertencia : la actualización de su aplicación de servidor probablemente siempre sobrescribirá /Library/Server/Web/config/proxy/apache_serviceproxy.conf. Después de una actualización, deberá volver a aplicar la modificación.


Nota: He intentado mover los cambios a un archivo de configuración personalizado separado apache_serviceproxy_customsites_myserver.domain.conf, lo que debería evitar que las actualizaciones del servidor reviertan estas modificaciones. Además de eso, el cambio de protocolo podría limitarse a un dominio específico. Pero eso no pareció funcionar, todavía investigando por qué.


Para asegurarse de que se utilicen sus modificaciones, parece necesario reiniciar macOS ( sudo shutdown -r), no solo el servidor web ( sudo serveradmin stop/start web) para reiniciar el servicio de proxy.

Una verificación realizada por la prueba del servidor SSL Labs informa que TLS 1.0, 1.1 y 1.2 ahora están disponibles, mientras que SSL 2 y 3 no lo están.

También necesito habilitar TLS 1.1 en Sienna Server 5.3. Hay algunos correos electrónicos que no llegan debido a esto.

/library/server/web/config/apache2/sites/0000_127.0.0.1_34543_myserver.domain.conf

/library/server/web/config/apache2/httpd.conf
ARCHIVO NO EN MI SERVIDOR

/library/server/web/config/apache2/httpd_server_app.conf
editar (en negrita) y reiniciar no hizo nada

IfModule mod_ssl.c
SSLProtocol -all +TLSv1.1 +TLSv1.2 --NO FUNCIONÓ
SSLProtocol All --NO FUNCIONÓ

/library/server/web/config/proxy/apache_serviceproxy.conf (múltiples instancias aquí)

lo siento, no estoy usando este derecho, pero espero que cuando termine sea una respuesta real

Sí, mira mi respuesta. Los archivos que cambié se enumeran en la pregunta. Pero no debe crear una respuesta, si en realidad está solicitando más información.