Quali problemi sorgono dalla condivisione di una chiave privata del certificato SSL?

21

Scenario: sto ospitando un sito Web per un mio cliente, che chiameremo S. S possiede il dominio s.com e possiedo i server che ospitano effettivamente il sito web. S ora vuole abilitare SSL sul proprio sito Web.

Ho generato una chiave privata e una CSR sul mio server, e ho inviato il CSR a S in modo che possano inviarlo alla loro CA.

Tuttavia, come tutti i clienti, S è economico. Non vogliono spendere i soldi per un nuovo certificato. Invece, vogliono darmi il loro certificato SSL esistente per *.s.com e la sua chiave privata corrispondente. Questo certificato e chiave sono già in uso da S e da alcuni degli altri fornitori di S.

So già che questa è una cattiva idea, ma perché? Quali problemi provoca questo ora e potenzialmente in futuro?

Per i punti bonus, la condivisione di una chiave privata come questa causa problemi nel contesto degli standard PCI?

    
posta josh3736 14.12.2012 - 18:00
fonte

3 risposte

24

Esistono diversi motivi per cui i certificati con caratteri jolly non sono validi:

  • La stessa chiave privata deve andare sui sistemi che hanno diversi livelli di sicurezza, quindi la tua chiave è valida quanto il tuo sistema meno protetto. Distribuirlo a fornitori di terze parti è davvero una cattiva idea , in quanto poi sfugge completamente al tuo controllo.
  • Devi mantenere record meticolosi che mostrano esattamente dove è installata la tua chiave privata jolly, in modo che quando devi sostituirlo, non devi giocare "Dove è Waldo" su tutti i tuoi siti.
  • Soprattutto, se la chiave privata e il certificato con caratteri jolly vengono rubati in qualsiasi momento, gli aggressori possono impersonare qualsiasi sistema in quello spazio jolly. Un errore comune è dire "useremo i caratteri jolly sui sistemi a bassa sicurezza, ma chiameremo i certificati su tutti i sistemi importanti" - devi fare l'esatto opposto! Se gli utenti malintenzionati hanno * .s.com, possono impersonare qualsiasi dominio nello spazio .s.com, indipendentemente dal fatto che stia utilizzando altri certificati. Quindi se hai "www.s.com" con un carattere jolly e "login.s.com" con un certificato one-off, gli autori di attacchi possono impersonare "login.s.com" indipendentemente da cosa sia su "login.s.com" .
  • Il modo più semplice per trarre vantaggio dalle chiavi jolly rubate è tramite avvelenamento DNS o tramite AP wireless rogue.

Tutto ciò detto, devi valutare i rischi. Se il tuo amico S sta già distribuendo questo certificato jolly e la chiave a tutti i venditori, allora rifiutare di accettarlo non riduce i suoi rischi in alcun modo significativo. Sembrerai ostinato e poco collaborativo e perderai la sua attività. Fai del tuo meglio per educare, ma capisci anche che alcune persone semplicemente non gli interesseranno.

Se, tuttavia, è obbligato a conformarsi a PCI-DSS, allora sono abbastanza sicuro che non è conforme, poiché penso che si supponga di avere registri di tutti gli accessi alle chiavi di crittografia private. Permetterò agli altri di familiarizzare con l'espansione di PCI-DSS su questo.

    
risposta data 14.12.2012 - 18:58
fonte
11

Chiunque abbia accesso alla chiave privata utilizzata da un server SSL ha il potere tecnico di:

  • Impersonare qualsiasi server con un nome corrispondente a quello che è inscritto nel certificato.
  • Decrittografare le sessioni che sono state passivamente intercettate (a meno che la sessione SSL non usi una delle suite di crittografia "DHE" che forniscono perfetto segreto in avanti , ma tali suite sono raramente selezionate per impostazione predefinita, qualcuno deve configurarle esplicitamente).

Quindi dare la stessa chiave privata a molte persone è davvero fidarsi di tutti, e far sì che si fidino l'uno dell'altro. Ricorda che "qualcuno di cui ti fidi" è un'espressione che significa davvero "qualcuno che ha il potere di tradirti".

In generale, una volta che un valore segreto è conosciuto da più di due persone, allora non è più segreto, solo un po 'discreto. Inoltre, non puoi forzare l'oblio, quindi se il tuo cliente S vuole smettere di fare affari con uno dei venditori a cui S ha dato una copia della chiave privata, devono cancellare tutto (revocare il certificato, crearne uno nuovo con una nuova chiave, e distribuirla) - in alternativa, S può salire di un livello sulla scala della creduloneria, e solo assumere che tutti sono onesti e competenti, e che i fornitori con cui non hanno più qualsiasi rapporto d'affari si prenderà comunque cura della loro chiave privata, non avendo fatto filtrare attraverso un nastro di backup o uno stagista indelicato.

Inoltre, il supporto per i certificati jolly è noto per essere un po 'instabile, dal momento che sono stati storicamente una fonte di guai (non di per sé, ma amplificano il potere di fastidio di un malfattore che arriva a rubare la chiave privata corrispondente) . I venditori di browser tendono a restringerli in modi arbitrari e mutevoli.

Esistono CA che forniscono certificati server SSL gratuitamente . Quanto devi essere economico per trovare i certificati gratuiti troppo costosi?

    
risposta data 28.12.2012 - 15:50
fonte
7

L'uso dello stesso certificato su molti server (fidati) non causa problemi da solo.

Il problema principale sarà nel caso in cui la chiave privata cada nelle mani sbagliate (da uno qualsiasi dei molti fornitori inclusi).

  • È più difficile sapere di una violazione: se molte persone / macchine hanno il certificato, la probabilità di una violazione aumenta e la probabilità di scoprire la violazione diminuisce. Se S.com è un obiettivo di valore relativamente elevato, l'uso della stessa certificazione su tutti i servizi significa anche che i potenziali hacker possono scegliere e scegliere il server più debole da sfruttare.

  • Quando il certificato deve essere revocato, tutti i fornitori devono immediatamente sostituire il certificato con uno nuovo per evitare che i clienti lo respingano. Ciò significa anche che il client potrebbe non voler revocare il certificato (poiché "causerebbe troppa seccatura"). Se diversi produttori avevano certificazioni diverse, solo il certificato trapelato avrebbe dovuto essere revocato e solo quel singolo fornitore avrebbe dovuto installare un nuovo certificato.

risposta data 14.12.2012 - 18:41
fonte

Leggi altre domande sui tag