it-swarm.dev

Quali problemi sorgono dalla condivisione della chiave privata di un certificato SSL?

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 CSR sul mio server e ho inviato il CSR a S in modo che possano inviarlo alla propria CA.

Tuttavia, come tutti i clienti, S è economico. Non vogliono spendere soldi per un nuovo certificato. Invece, vogliono darmi il loro certificato SSL esistente per *.s.com e la chiave privata corrispondente. Questo certificato e questa chiave sono già in uso da parte di S e di alcuni 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?

22
josh3736

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

  • La stessa chiave privata deve funzionare su sistemi con livelli di sicurezza diversi, quindi la chiave è valida solo come il sistema meno protetto. Distribuirlo a fornitori di terze parti è davvero cattiva idea, poiché sfugge completamente al tuo controllo.
  • Devi conservare record meticolosi che mostrano esattamente dove è installata la tua chiave privata jolly, in modo che quando devi sostituirla, non devi giocare "Where is Waldo" su tutti i tuoi siti.
  • Soprattutto, se la chiave privata e il certificato jolly vengono rubati in qualsiasi momento, gli aggressori possono quindi impersonare il sistema any in quello spazio jolly. L'errore comune è di dire "useremo certs con caratteri jolly su sistemi a bassa sicurezza, ma denomineremo certs su tutti i sistemi importanti" - devi fare esattamente il contrario! Se gli aggressori hanno * .s.com, possono impersonare qualsiasi dominio nello spazio .s.com, indipendentemente dal fatto che stia utilizzando altri certificati. Quindi, se si dispone di "www.s.com" con un carattere jolly e "login.s.com" con un certificato una tantum, gli aggressori possono impersonare "login.s.com" indipendentemente da ciò che si trova in "login.s.com" .
  • Il modo più semplice per sfruttare le chiavi jolly rubate è avvelenamento da DNS o tramite AP wireless non autorizzati.

Detto questo, devi valutare i rischi. Se il tuo amico S sta già distribuendo questo cert jolly e questa chiave a tutti i fornitori, il rifiuto di accettarlo non riduce i suoi rischi in modo significativo. Apparirai ostinato e poco collaborativo e perderai i suoi affari. Fai del tuo meglio per educare, ma capisci anche che ad alcune persone non importa.

Se, tuttavia, è tenuto a conformarsi a PCI-DSS, allora sono abbastanza sicuro che non sia conforme, poiché penso che dovresti avere registri con tutti gli accessi alle chiavi di crittografia private. Lascerò che altri più familiari con PCI-DSS si espandano su questo.

25
mricon

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

  • Rappresenta qualsiasi server con un nome corrispondente a quello iscritto nel certificato.
  • Decifrare le sessioni che sono state passivamente intercettate (a meno che la sessione SSL non utilizzi 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 loro tutti e farli fidare l'uno dell'altro. Ricorda che "qualcuno di cui ti fidi" è un'espressione che in realtà significa "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, deve annullare tutto (revocare il certificato, crearne uno nuovo con una nuova chiave e distribuirla) - in alternativa, S può salire di un livello nella scala della creduloneria e solo supporre che tutti siano onesti e competente e che i fornitori con i quali non intrattengono più alcun rapporto commerciale si prenderanno comunque cura della propria chiave privata, non facendola trapelare attraverso un nastro di backup o un interno indelicato.

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

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

12
Thomas Pornin

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

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

  • È più difficile conoscere una violazione: se molte persone/macchine hanno il certificato, la probabilità di una violazione aumenta e diminuisce la probabilità di scoprire la violazione. Se S.com è un obiettivo di valore relativamente elevato, l'utilizzo dello stesso certificato su tutti i servizi significa anche che i potenziali hacker possono 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 rifiutino. Ciò significa anche che il client potrebbe non voler revocare il certificato (poiché "causerebbe troppa seccatura"). Se fornitori diversi avessero certificati diversi, solo il certificato trapelato dovrebbe essere revocato e solo quel singolo fornitore dovrebbe installare un nuovo certificato.

7
Joel L