¿Por qué se solicita a los usuarios de OSX de mi sitio solo para TLS que proporcionen un certificado de cliente?

1

Compré un certificado Comodo SSL (OV) y configuré la configuración de Apache vhost para que todo el tráfico se reenvíe a 443. De manera intermitente, se solicita a algunos usuarios que proporcionen un certificado de cliente; todos estos usuarios parecen ser usuarios de OSX, pero sucede tanto en Safari como en Chrome. ¿Por qué pasó esto? ¿Por qué solo es OSX y cómo puedo evitar que esto suceda?

Agregué la línea SSLVerifyClient como se muestra como un experimento después de que esto empezara a suceder (el valor predeterminado es ninguno, pero quería intentar ser explícito).

Mi configuración de vhost sigue al final de la publicación.

Estas son algunas de las capturas de pantalla de los usuarios (que, por cierto, es realmente una mala experiencia de usuario; me sorprende que esto se vea en absoluto en OSX):

Aquíestámiconfiguraciónvhost:

<VirtualHost*:80>ServerNamewww.example.comRedirectpermanent/https://www.example.com/</VirtualHost><VirtualHost*:443>HeaderaddStrict-Transport-Security"max-age=15768000"

    ServerAdmin [email protected]
    ServerName www.example.com
    ServerAlias example.com
    SetEnv APPLICATION_ENV production

    SSLEngine on
    SSLCertificateFile    /etc/apache2/ssl/example_com.crt
    SSLCertificateKeyFile /etc/apache2/ssl/example.key
    SSLCertificateChainFile /etc/apache2/ssl/example_com.ca-bundle
    SSLVerifyClient none

    BrowserMatch "MSIE [2-6]" \
            nokeepalive ssl-unclean-shutdown \
            downgrade-1.0 force-response-1.0
    # MSIE 7 and newer should be able to use keepalive
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

    AddHandler php5-fcgi .php
    Action php5-fcgi /php5-fcgi
    Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi -socket /var/run/php5-fpm.sock -pass-header Authorization

    <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
            SSLOptions +StdEnvVars
    </Directory>

    DocumentRoot /usr/local/zend/example/public
    <Directory /usr/local/zend/example/public>
            Options Indexes FollowSymLinks
            AllowOverride All
            allow from all
            php_admin_value open_basedir none
    </Directory>
</VirtualHost>

Hay un .htaccess en el public dir:

RewriteEngine On
RewriteRule ^(.*)\.[\d]{10}\.(css|js)$ $1.$2 [L]

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
    
pregunta confused 17.01.2014 - 21:48
fuente

1 respuesta

1

Un cliente SSL utilizará un certificado de cliente solo si el servidor lo solicita debidamente. Si tanto Chrome como Safari afirman que el servidor solicita un certificado de cliente, esto probablemente significa que el servidor efectivamente solicita un certificado de cliente. Como lo señaló @Ben, es muy posible que el servidor solicite certificados para todos, pero la mayoría de los usuarios que no son OSX no tienen certificados y su navegador responde silenciosamente al servidor que no tienen ningún certificado.

Para asegurarse de que el servidor solicite un certificado, ejecute Wireshark . Debería poder ver los detalles del protocolo de enlace SSL, en particular el mensaje CertificateRequest handshake del servidor. También querrá verificar que el servidor que solicita un certificado de cliente sea realmente suyo: verifique que el mensaje Certificate del servidor contenga el certificado exacto que configuró en su servidor.

En cualquier caso, dado que el protocolo de enlace SSL contiene sumas de comprobación que se calculan sobre todos los mensajes de protocolo de enlace intercambiados, un mensaje CertificateRequest no puede ser contrabandeado en sus protocolos sin interrumpir el procedimiento (el cliente y / o el servidor se quejarán en voz alta).

Desafortunadamente, los dos escenarios sugeridos no funcionan en última instancia:

  • Si hay alguna configuración incorrecta del equilibrador de carga que redirige a algunos clientes a otro servidor, ese otro servidor no debería tener un certificado que coincida con el nombre de su sitio. Los navegadores de los clientes deberían mostrar sus ventanas emergentes de advertencia. Por otro lado, si el otro servidor realmente tiene un certificado con el nombre de su sitio, entonces este es un ataque, y uno muy exitoso; No tendría mucho sentido para el atacante hacer volar su propia portada al pedir estúpidamente certificados de clientes.

  • Si el problema es una mala configuración en su propio servidor (por ejemplo, un archivo .htaccess que anula su configuración de SSLVerifyClient ), entonces el problema no debe ser intermitente . Para una URL determinada, siempre debería suceder, o nunca.

Mi mejor conjetura (no una buena , pero la mejor que puedo ofrecer) es que su sitio incrusta algunos anuncios de un proveedor de anuncios de terceros, y algunos de estos anuncios apuntan a una configuración incorrecta Servidor con SSL. Esto explicaría la parte "intermitente": usted obtiene la ventana emergente del certificado en la ocasión aleatoria en la que el proveedor de anuncios lo apunta a ese servidor mal configurado específico. El análisis de rastreo con Wireshark revelaría que, por cierto: si encuentra un protocolo de enlace SSL con un mensaje CertificateRequest , entonces el mensaje correspondiente Certificate contendrá el certificado del servidor infractor y el nombre del servidor (y también debe encontrarlo como parte de la extensión Indicación del nombre del servidor en el mensaje ClientHello ). Entonces instale Wireshark y compruébelo usted mismo.

(En Windows, Network Monitor de Microsoft funcionaría igual de bien).

    
respondido por el Tom Leek 16.05.2014 - 23:19
fuente

Lea otras preguntas en las etiquetas