Perché gli utenti OSX del mio sito solo TLS vengono invitati a fornire un certificato client?

1

Ho acquistato un certificato SSL Comodo (OV) e ho configurato la configurazione di vhost di Apache in modo che tutto il traffico sia inoltrato a 443. A intermittenza alcuni utenti vengono invitati a fornire un certificato client; questi utenti sembrano tutti utenti OSX, ma succede sia su Safari che su Chrome. Perché succede? Perché è solo OSX e come posso evitare che ciò accada?

Ho aggiunto la riga SSLVerifyClient come mostrato in un esperimento dopo che questo ha avuto inizio (il valore predefinito è none, ma volevo provare ad essere esplicito).

La configurazione del mio vhost segue alla fine del post.

Ecco alcuni degli screenshot degli utenti (che, guarda caso, è davvero un brutto UX - mi sorprende che questo si mostri affatto in OSX):

Eccolamiaconfigurazionedivhost:

<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>

Esiste un .htaccess nella directory public :

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]
    
posta confused 17.01.2014 - 21:48
fonte

1 risposta

1

Un client SSL utilizzerà un certificato client solo se richiesto dal server. Se sia Chrome che Safari affermano che il server richiede un certificato client, questo probabilmente significa che il server infatti richiede un certificato client. Come è stato sottolineato da @ Ben, è abbastanza probabile che il server richieda certificati per tutti, ma la maggior parte degli utenti non OSX non ha affatto certificati e il loro browser risponde silenziosamente al server che non hanno alcun certificato.

Per essere sicuri che un certificato sia effettivamente richiesto dal server, esegui Wireshark . Dovresti essere in grado di vedere i dettagli dell'handshake SSL, in particolare il messaggio di% handshake% co_de dal server. Dovrai anche verificare che il server che richiede un certificato client sia effettivamente tuo: verifica che il messaggio CertificateRequest dal server contenga il certificato esatto configurato sul tuo server.

In ogni caso, poiché l'handshake SSL contiene checksum che vengono calcolati su tutti i messaggi di handshake scambiati, un messaggio Certificate non può essere contrabbandato nelle stringhe di mano senza interrompere la procedura (il client e / o il server si lamenteranno rumorosamente). p>

Sfortunatamente, i due scenari suggeriti non funzionano in definitiva:

  • Se c'è qualche errore di bilanciamento del bilanciamento del carico che reindirizza alcuni client su un altro server, quell'altro server non dovrebbe avere un certificato che corrisponda al nome del tuo sito. I browser client dovrebbero mostrare i loro popup di avvertimento spaventosi. D'altra parte, se l'altro server ha effettivamente un certificato con il nome del tuo sito, allora si tratta di un attacco, e di grande successo; non avrebbe molto senso che l'aggressore soffiasse sulla sua copertina chiedendo stupidamente i certificati dei clienti.

  • Se il problema è una configurazione errata sul tuo server (ad esempio un file CertificateRequest che sostituisce l'impostazione .htaccess ), il problema non dovrebbe essere intermittente . Per un dato URL, dovrebbe sempre succedere, o mai.

La mia ipotesi migliore (non una buona ipotesi, ma la migliore che posso offrire) è che il tuo sito incorpori alcuni annunci da un fornitore di annunci di terze parti, e alcuni di questi annunci puntano a una configurazione errata Server con tecnologia SSL. Ciò spiegherebbe la parte "intermittente": si ottiene il popup del certificato nell'occasione casuale in cui il provider di annunci punta a quel server configurato in modo errato. L'analisi delle tracce con Wireshark rivelerebbe che, a proposito: se trovi un handshake SSL con un messaggio SSLVerifyClient , il corrispondente messaggio CertificateRequest conterrà il certificato del server incriminato e il nome del server (e dovresti trovarlo anche come parte dell'estensione Nome del server nel messaggio Certificate ). Quindi vai su Wireshark e vedi di persona.

(Su Windows, il Monitor di rete di Microsoft funzionerebbe altrettanto bene.)

    
risposta data 16.05.2014 - 23:19
fonte

Leggi altre domande sui tag