Diverse versioni SSL / TLS su sottodomini utilizzando un certificato jolly

3

Attualmente sto implementando un sistema di pagamento sicuro. Voglio che questo sistema sia conforme allo standard PCI e che abbia implementato la versione più alta di TLS.

Il sistema così com'è ha diversi sottodomini che utilizzano un certificato con caratteri jolly, gli utenti che accedono al sito utilizzano browser legacy, il che significa che abbiamo una versione leggermente più vecchia di TLS.

È possibile avere un nuovo sottodominio checkout utilizzando il certificato jolly e implementare una versione diversa di TLS su questo nuovo sottodominio checkout (risiederà in un ambiente separato pure)?

Se è possibile è quella l'opzione migliore e più sicura, oppure è consigliabile separarla completamente con il proprio certificato?

    
posta Oliver Cooke 23.03.2017 - 10:19
fonte

2 risposte

3

Questo è assolutamente possibile.

Sia per Apache che per Nginx, puoi definire le opzioni TLS per host virtuale.

Prendendo nginx come esempio, ogni blocco come il seguente (tratto da generatore di configurazione TLS di Mozilla può specificare le proprie opzioni e preferenze TLS:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;


    # modern configuration. tweak to your needs.
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;

    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    resolver <IP DNS resolver>;

    ....
}

Puoi usare qualsiasi cert (si spera valido) all'interno del blocco, incluso riutilizzare un cert tra sottodomini. Le impostazioni TLS sono distinte dai dettagli del certificato e della chiave utilizzata.

Tuttavia, sebbene sia possibile farlo, potrebbe essere sensato prendere in considerazione, almeno, l'utilizzo di certificati diversi: ciò consentirebbe di revocare i certificati per diverse parti del sito in caso di compromissione.

Utilizzando il certificato jolly, se tale chiave è compromessa, l'intero sito sarà offline fino a quando non sarà possibile ottenere un nuovo certificato. Se disponi di certificati di dominio e, eventualmente, di caratteri jolly come ripiego, ti rendi meglio in grado di gestire tale situazione senza necessariamente influire sull'intero servizio.

    
risposta data 23.03.2017 - 10:33
fonte
2

Oltre alla risposta di @ iwaseatenbyagrue, anche se la maggior parte delle versioni SSL / TLS non dovrebbe rappresentare un rischio per il tuo sottodominio extra sicuro , se supporti SSL 2 ovunque allora metterà a rischio qualsiasi connessione utilizzando lo stesso certificato , indipendentemente dalla versione SSL / TLS utilizzata.

In effetti, a causa dei moderni browser che vietano i certificati SHA-1, non ci sono (per quanto ne so) nessun browser in grado di connettersi a qualsiasi sito Web protetto con un certificato SSL pubblicamente attendibile e che non supporta almeno TLS 1.0, quindi non esiste un solo motivo per utilizzare l'obsoleto e non sicuro SSL 3.

    
risposta data 09.05.2017 - 09:56
fonte

Leggi altre domande sui tag