Stavo guardando il certificato del mio sito Web della banca e ho scoperto che è stato pubblicato su più siti Web e il nome di dominio della banca è elencato solo tra molti altri domini nel campo "nomi alternativi".
Questa è considerata una cattiva pratica? A quali rischi sono soggetti i loro clienti? (uomo nel mezzo? rappresentazione?)
È un certificato di rete di consegna dei contenuti - una società statunitense Incapsula Inc. - che intercetta la tua intera comunicazione con il banca. Il certificato in sé non rappresenta un rischio diretto per i dati dei clienti, ma:
Is this considered a bad practice?
Diversamente da altro risposte , direi che non è normale e la situazione indica un certo livello di incompetenza da parte della banca.
Secondo i piani tariffari di Incapsula, la tua banca potrebbe utilizzare $ 59 al mese, mentre l'azienda offre SSL personalizzato per $ 299 / mese (funzione "Supporta certificati SSL personalizzati") e un piano reale per le imprese.
Anche se la banca paga di più per CDN, la banca utilizza le funzionalità rivolte ai blog professionali e non utilizza le funzionalità offerte dal piano / dall'accordo.
La tua banca potrebbe violare le leggi sulla privacy nel tuo paese consentendo a un'azienda di un altro paese, in base a una diversa legislatura, di elaborare i dati personali identificativi dei clienti.
What risks are their customers are subjected to? (man in the middle? impersonation?)
I dati in una crittografia tra il browser e l'endpoint della CDN. La chiave privata è (si spera) memorizzata solo sui server di CDN, quindi non vi è alcun rischio che altre società dell'elenco possano impersonare la banca.
Fintanto che gli standard di sicurezza sono soddisfatti su un collegamento tra CDN e banca, il MitM non è tecnicamente possibile neanche.
Avviso incapsula.com nell'oggetto. Incapsula è un'azienda che offre sicurezza delle applicazioni Web che include WAF, protezione DDOS e alcuni altri servizi.
La mia ipotesi è che il tuo sito web delle banche sia effettivamente trasmesso attraverso il loro server e così tutti gli altri siti. Quel server rilascia lo stesso certificato su tutti quei siti perché sono tutti effettivamente inviati tramite lo stesso server.
Non c'è motivo di preoccuparsi qui.
Può essere normale.
Le banche spesso consolidano, acquistano, cross-market e fanno ogni sorta di cose che significano che stanno rispondendo a più di un nome. Non è insolito per una banca avere numerose voci SAN per consentire a tutti i loro vari clienti di accedere al loro sito web, anche se sono clienti di una banca acquistata da una banca acquistata da una banca acquistato da una banca che è stata acquistata da una banca che hanno acquisito.
Potresti voler controllare se quegli altri nomi elencati si risolvono con lo stesso indirizzo IP e / o sono serviti da siti web che usano lo stesso certificato. Se questi domini condividono veramente un proprietario comune, questo può essere un po 'normale.
In termini di sicurezza, è potenzialmente peggio - se la chiave privata è condivisa su numerosi server, numerosi amministratori - ma non definitivamente . Non ne sai abbastanza su ciò che sta effettivamente accadendo dietro le quinte da dire.
Non necessariamente un concreto rischio per la sicurezza, non appena tu (l'amministratore IT) sei preparato ai nuovi rischi.
Se disponi di un singolo certificato per molti domini, è un singolo punto di errore e il ring più debole. È necessario applicare costose procedure IT per mantenere la sua chiave privata "solo occhi" o meglio "solo server HTTPS". Il compromesso della singola chiave avrà un impatto su tutti i servizi contemporaneamente. L'intera attività dipende da un numero lungo di sigle 4096-bit
Quando una singola chiave è condivisa tra diversi servizi in una CDN, il suo compromesso porterà l'intero CDN in basso per il periodo di rinnovo della chiave. L'aggiunta di un nuovo dominio per il servizio comporta la riemissione del certificato con il tempo di inattività associato.
C'è un vantaggio nell'usare tali certificati condivisi. In una rete CDN, puoi efficace configurare i proxy HTTPS. Questa è una pratica ampiamente utilizzata e offre grandi vantaggi in termini di prestazioni.
Fondamentalmente il tuo DMZ ospita un set di server proxy reverse bilanciati in carico che riceveranno il traffico HTTPS, lo decrittografano e inoltreranno il traffico HTTP (notice, no S) ai veri server all'interno della rete CDN . Ciò richiede una strong configurazione della rete interna per garantire la sicurezza dei pacchetti, ma ci sono professionisti che lavorano a questo, e ricorda che i flussi di traffico non crittografati solo all'interno di una zona di fiducia.
Quindi perché bilanciare il carico? Perché se il tuo CDN ospita 1000 siti e alcuni di essi ottengono un aumento del traffico, non è necessario eseguire il provisioning dei computer. Puoi lasciare che i proxy funzionino come round-robin.
C'è una ragione tecnica dietro i certificati con più alias ed è che il CDN non vuole richiedere SNI (identificazione del nome del server) dai client. Soprattutto nel mondo finanziario / aziendale, i browser di alcune persone potrebbero essere troppo vecchi per supportare SNI.
Il provisioning di un nuovo certificato per ogni nuovo servizio, con una chiave privata diversa, è una buona pratica di sicurezza.
Sono con Imperva Incapsula Team.
Sembra che ci sia molta confusione, quindi vorrei sottolineare alcuni fatti:
Ma soprattutto - non è un pericolo per la sicurezza. In ogni modo.
Prendi tutti i commenti qui con una grossa fetta di sale.
Ritengo sia importante affermare che questi commenti (anche se scritti con buone intenzioni) sono infondati, fuorviati e falsi:
HTH
Per quanto riguarda la sicurezza, no. Come notato da diverse persone, i CDN proteggono la chiave privata con maggiore sicurezza rispetto a quanto faranno le organizzazioni.
Ma il rischio può essere più di un'apparenza. Ad esempio, ABC Bank potrebbe non voler condividere un certificato con le pistole e le munizioni XYX. È un problema di apparenza.
Leggi altre domande sui tag tls certificates