Domanda:
Devo rifiutare una CSR quando l'host mi ha inviato via email la chiave privata per la richiesta del certificato SSL?
scipilot
2017-04-12 17:16:53 UTC
view on stackexchange narkive permalink

Ho appena richiesto una CSR dal mio provider di hosting web condiviso, per generare un certificato che invierò loro per l'installazione. (Il certificato stesso deve essere generato correttamente da un'organizzazione per cui lavoro che può fornire certificati per il nostro uso ufficiale.) La società di hosting mi ha prontamente inviato il CSR ma anche la chiave privata! Hanno persino mandato in CC qualcun altro, ed è in Gmail, quindi presumibilmente Google lo ha già ingerito per scopi pubblicitari.

A mio modesto parere questa sembra una cosa terribile da fare. Sto per rispondergli rifiutando questo e chiedendo di rinnovare la CSR e questa volta di mantenere la chiave privata - privata.

Prima di prendere in giro me stesso, vorrei confermarlo la chiave privata per un certificato "SSL" (TLS) non dovrebbe mai lasciare il server?

Lavoro da molti anni in settori legati alla sicurezza e sono un programmatore di crittografia, quindi mi sento Conosco un po 'l'argomento, ma so che le cose cambiano nel tempo.

Ho letto questa domanda correlata: Quali problemi sorgono dalla condivisione della chiave privata di un certificato SSL?

Meta Update: mi sono reso conto di aver scritto un formato di domanda di scarsa qualità per Stack Exchange, poiché ora è difficile accettare una risposta specifica. Mi scuso per questo: tutte le risposte coprivano aspetti diversi e ugualmente interessanti. Inizialmente mi chiedevo come esprimerlo a tale scopo, ma ho lasciato uno spazio vuoto.

Aggiornamento: l'ho seguito anche se con l'host e si sono scusati per qualsiasi inconveniente, promesso di mantenere future chiavi private "sicure" e mi hanno rilasciato un nuovo, diverso CSR. Al momento non sono sicuro se sia generato dalla stessa chiave privata esposta. Ora mi chiedo anche, dato che si tratta di un host condiviso, se mi hanno inviato la chiave per l'intero server o se ogni cliente / dominio / host virtuale ottiene una coppia di chiavi.

È una lezione interessante su come tutti la forza crittografica nel mondo può essere resa nulla da un semplice errore umano. Kevin Mitnik annuirà.

Aggiornamento 2: In risposta a una risposta dell'utente @Beau, ho utilizzato i seguenti comandi per verificare che la seconda CSR sia stata generata da una diversa chiave privata segreta.

  openssl rsa -noout -modulus -in pk1. txt | openssl md5openssl req -noout -modulus -in csr1.txt | openssl md5openssl req -noout -modulus -in csr2.txt | openssl md5  

I primi due hash sono identici, il terzo è diverso. Quindi questa è una buona notizia.

_ "ed è in Gmail, quindi Google lo ha presumibilmente già ingerito per scopi pubblicitari." _ Ti rendi conto che Google gestisce la propria CA e potrebbe inserire praticamente qualsiasi certificato CA che preferisce in Chrome?In questo scenario, Google è probabilmente una delle parti meno interessate / interessanti.
Sì, non sono preoccupato per Google in sé (ho affidato la mia vita a loro!), Ma solo evidenziando i viaggi extra che i nostri contenuti personali percorrono al giorno d'oggi, anche dopo l'apparente arrivo a destinazione.
La chiave privata è crittografata?
@DavidSchwartz No, non sembrava così.
Mi scuso per non aver postato questo come commento: non ho abbastanza rappresentanti.Ma puoi confrontare la tua nuova CSR con la chiave privata originale con alcuni comandi openssl: https://www.sslshopper.com/certificate-key-matcher.html.Se il modulo per ciascuno è diverso, allora dovresti essere a posto.Tuttavia, non sono sicuro che mi fiderei delle pratiche di sicurezza del fornitore.La sicurezza è tutta una questione di fiducia, dopo tutto.
È molto utile Beau: ho usato questi comandi per dimostrare che il nuovo SR che hanno fornito è stato generato con una chiave privata diversa, il che è una buona notizia, poiché non devo rifiutarlo anch'io.
Non scusarti, penso che sia colpa mia se scrivo domande sull'opinione: questa domanda si sta trasformando in un prezioso articolo wiki :)
A proposito, è abbastanza (non) divertente che la pagina sslshopper.com abbia un campo "carica chiave privata"!E un grande avvertimento a non usarlo.
A questo punto, passare a un'azienda che * effettivamente comprende * la natura di una chiave * privata * potrebbe avere più senso, IMHO.Un emittente di certificati che invia felicemente chiavi private via e-mail a diversi destinatari * non * sembra sapere cosa sta facendo e si è dimostrato non altrettanto competente.L'uso di [certbot] (https://certbot.eff.org/) è un problema?Questo è quello che uso per il mio server.
@BaileyS Google, l'azienda potrebbe non essere interessata, ma Dave, il dipendente di Google con accesso al server di posta elettronica, potrebbe esserlo.Ci sono stati casi in cui i dipendenti di Google hanno abusato del loro accesso agli account Gmail delle persone
@Pharap il valore delle informazioni private di un individuo è altamente sopravvalutato.Davvero, a nessuno interessano i segreti che potresti tenere così cari, le cotte di Facebook, i registri delle chat e probabili nudi memorizzati sul tuo backup di WhatsApp.È difficile ammettere che non siamo così interessanti e la maggior parte di noi è semplicemente noiosa.Il valore reale viene fornito con enormi quantità di dati aggregati, in cui la tua individualità si dissolve nel nulla rispetto al set di dati.A meno che, ovviamente, tu non sia la bella ragazza adolescente di Putin o un CEO di F500, i nostri dati privati individuali non valgono alcuno sforzo.
@hlecuanda Bene.[questo ragazzo] (http://gawker.com/5637234/gcreep-google-engineer-stalked-teens-spied-on-chats) certamente lo era.Sono lieto di sapere che le mie comunicazioni basate su Gmail con i miei amici hacker del pentagono sono comunque al sicuro.Mi assicurerò di dire a Betty di stare attenta, qualcuno potrebbe aver capito con quale capo di stato ha organizzato il collegamento della camera d'albergo.
Sei risposte:
dr_
2017-04-12 17:52:09 UTC
view on stackexchange narkive permalink

Sì, dovresti assolutamente rifiutare la CSR. Inoltre, dovresti cambiare il tuo provider di hosting perché sembra che non sappiano cosa stanno facendo.

È già abbastanza grave che ti abbiano inviato la chiave privata via e-mail, cioè tramite un mezzo non sicuro . Tuttavia, l'hanno anche mandato a qualcun altro, il che rappresenta una completa violazione della riservatezza.

Inoltre, mi chiedo perché ti hanno inviato la chiave privata: dovrebbe essere installata sul server, cosa che possono fare da soli.

Hanno messo in copia l'altro contatto sull'account (non tecnico).E sì, mi chiedevo anche perché, questa era davvero la mia domanda.Non c'è ancora alcun motivo - assicurandomi di non aver perso un promemoria qui.
Ok, quindi non è come se avessero inviato la chiave privata a qualcuno a te sconosciuto.Tuttavia, il punto principale è valido.
@dr01 Certo che l'hanno fatto.Tutti gli amministratori del server di posta, gli amministratori del router e gli amministratori del firewall che erano lungo il percorso della posta e volevano leggerla.
@DRF Volevo dire che * volontariamente * ha divulgato la chiave privata a terzi.
Mi chiedo se la chiave privata venga utilizzata per l'intero server condiviso, nel qual caso saresti in grado di impersonare non solo il tuo dominio ma chiunque altro utilizzi lo stesso server.
@dr01 Penso che se invii informazioni tramite posta elettronica, a meno che non siano crittografate, le stai volontariamente rivelando a tutti i computer da cui rimbalza finché non raggiunge la sua destinazione.
+1 per aver detto a OP di cambiare fornitore, che ha dimostrato il proprio livello di ignoranza nel proprio campo.
@AaronHall È volontario solo se sai come funziona la posta elettronica, altrimenti è beata ignoranza.Penso che abbiamo stabilito che il provider di hosting è gestito da incompetenti.
vakus
2017-04-12 17:40:50 UTC
view on stackexchange narkive permalink

Se fossi al tuo posto, rifiuterei di accettare questo certificato SSL. Il motivo è che se qualcuno entrasse in una delle email che ha ricevuto la chiave privata, sarebbe in grado di scaricarlo e quindi impersonare il server in diversi attacchi ai client, come man in the middle o simili. Anche nel caso in cui uno degli indirizzi email di ricezione fosse scritto in modo errato, qualcuno potrebbe già avere la chiave privata. Probabilmente esistono anche molti altri scenari in cui questa chiave privata potrebbe essere scaricata e utilizzata da un utente malintenzionato.

Anche la notifica all'azienda di non condividere la chiave privata dovrebbe essere importante, per assicurarsi che l'azienda non ha inviato la chiave privata altrove: la chiave privata è stata inviata a te e ad altri CC in questa email, ma non puoi sapere se l'azienda non ha inviato un'e-mail separata con la chiave privata da qualche altra parte.

C'è un motivo per cui la chiave privata è chiamata chiave privata

Tieni presente che questa è principalmente la mia opinione personale e che non sono un esperto di SSL.

Sì, buon punto di educarli.
A questo punto, passare a un'azienda che comprende effettivamente la natura di una chiave privata non avrebbe più senso?Un emittente di certificati che invia felicemente chiavi private via e-mail a diversi destinatari * non * sembra sapere cosa sta facendo e ha dimostrato di non essere altrettanto competente, IMHO.
@ray bene se cambi azienda, allora sei più sicuro, ma se invece li istruisci, tutti i loro clienti saranno al sicuro.Se educarli non aiuta, allora sì, sarebbe ragionevole cambiare compagnia, ma a questo punto sembrerebbe ovvio
@vakus Se vuoi investire nell'istruzione di qualcuno che dovrebbe già conoscere meglio, dipende da te.Ricorda solo che la scarsa pratica di sicurezza a te visibile, essendo al di fuori dell'azienda, suggerisce problemi più profondi che potresti non scoprire mai (es. Come fai a sapere che non hanno ricevuto in Ccn quella chiave per altri indirizzi, o peggio?) E, quindi, incapaciper istruirli.Devi decidere quanto rischio intendi mettere * i * tuoi * clienti per "istruirli".Educarli non significa che devi rimanere come loro cliente.Andarsene potrebbe dare loro più incentivi per aggiustarsi effettivamente
Lie Ryan
2017-04-12 20:25:21 UTC
view on stackexchange narkive permalink

Sì, dovresti assolutamente rifiutare la CSR.

Se devi riconsiderare il provider di hosting, dipende.

Hanno persino contattato qualcun altro,

C'è qualche motivo per cui la società di hosting dovrebbe conoscere la struttura interna della tua azienda? La persona che fa questo è un account manager designato che è stato specificamente assegnato alla tua azienda e ha la responsabilità di sapere chi è chi nella tua azienda? La tua azienda ha fornito informazioni sufficienti all'account manager su come è strutturata la tua azienda e chi è autorizzato a fare cosa? In caso contrario, potrebbe essere in parte colpa tua (azienda) per non aver chiarito loro come dovrebbero inviarti la chiave.

Nella maggior parte degli account di hosting, se non hai un account designato manager che ha familiarità con il tuo settore di attività, avresti dovuto rendere molto esplicito al loro supporto tecnico come inviarti le chiavi, chi dovrebbe riceverle e se desideri o meno ricevere la chiave in primo luogo. Non dare per scontato che un personale di supporto tecnico conosca la situazione della tua azienda e non dare mai per scontato che un personale di supporto tecnico che non è il tuo account manager designato ricordi chi sei da una precedente interazione.

ed è in Gmail

Ti rendi conto che anche l'invio di una CSR tramite e-mail non è molto sicuro, giusto? È abbastanza possibile che qualcuno (un insider che lavora in Gmail o in un APT), intercetti l'email contenente il CSR, sostituisca il CSR che l'host ti invia con il proprio CSR e firmi la CSR della società di hosting alla società di hosting stessa. Ciò consentirebbe loro di utilizzare in seguito i certificati contraffatti per MITM tra te, i tuoi utenti e la società di hosting.

Un CSR deve essere consegnato su un canale autenticato (ad esempio, inviano il certificato a un sito HTTPS che controlli o dovrebbero firmare il CSR con una chiave GPG che pubblicano sul loro sito), o almeno dovresti fare un'impronta digitale verifica e sia tu che il tuo host dovete avere un modo per identificare e autenticare l'altra parte. La configurazione di un canale autenticato può essere un processo piuttosto complicato e non è qualcosa che sarà disponibile in provider di hosting a basso costo o in quelli che non sono specializzati in hosting aziendale ad alta sicurezza.

Se non lo fai Non specificare come la tua azienda richiede che la CSR venga consegnata, e soprattutto se non sei gestito da un account manager che dovrebbe sapere che tipo di attività stai facendo, allora la maggior parte delle società di hosting presumerebbe ragionevolmente che tu sia una società di sicurezza minima. La maggior parte delle persone che lavorano in una società di sicurezza minima considererebbe avere una copia della chiave privata un valore più elevato rispetto alla sicurezza di non controllare la chiave, non è irragionevole che lo dica da te.

`È abbastanza possibile che qualcuno ... intercetti l'email contenente il CSR` - Hai un link o qualcosa con maggiori dettagli su questo?Sto cercando di seguire come funzionerebbe.
@Zoredache È semplicissimo.Lavori in Google.Esegui uno script per cercare nel database di Gmail i messaggi di posta elettronica non recapitati che sono stati inviati agli utenti negli ultimi 5 minuti e che contengono quelli che sembrano essere payload di chiavi private.Sposti temporaneamente questa email in un'area di staging in modo che non venga consegnata, quindi crea il payload alternativo.Quindi rimetti l'email modificata con il tuo payload dannoso nel database, dove l'utente la vedrà come un'altra email buona e prevista.
HTTPS non aiuterà nulla a meno che non abbia l'autenticazione del client, a quel punto potresti anche firmare il CSR con il certificato del client e avere meno lavoro.L'unico modo sicuro per fornire una CSR è utilizzare l'autenticazione fuori banda.A seconda di quanto vuoi che sia sicuro, potrebbe essere facile come una telefonata e leggere l'impronta digitale o fastidioso come doverti presentare di persona.
@ErikE Certo, se la chiave privata viene inviata, c'è un problema, ma la risposta di LieRyan dice che un CSR da solo in un'e-mail può essere abusato.Non sto seguendo come potresti usare MITM dato solo un CSR.A meno che non si pensi che l'aggressore possa intercettare la CSR e sia anche impostato su MITM tutti gli accessi al server per cui viene effettivamente rilasciato il certificato.
@Zoredache Il trasferimento di una CSR (senza chiave privata, ovviamente) di per sé non rappresenta un rischio per la sicurezza.Il richiedente ha generato una coppia di chiavi pubblica-privata che desidera associare a un'entità da proteggere (ad esempio, utilizzare con un sito https per www.example.com) e chiede gentilmente a un firmatario di fiducia di firmare e quindi confermare cheesiste questa connessione tra la chiave pubblica e l'entità associata.Ciò che deve avvenire in modo sicuro fuori banda è piuttosto il processo di verifica che la CSR sia stata emessa da qualcuno che ha il controllo affidabile dell'entità da proteggere.
Sì, mi rendo conto che la normale posta elettronica stessa è anche inaccettabilmente insicura, sembra che oggigiorno la posta elettronica sia meno apprezzata dalle persone e l'accettazione dell'accesso di terze parti è più normale.In passato erano solo i postmaster / gli amministratori di sistema che avevano accesso ai contenuti della posta mentre erano in coda, nella semplice posta tradizionale.Ora è molto più complesso con molte più superfici di attacco e un livello inferiore di personale con potenziale accesso (credo).Con Gmail intendevo anche webmail, quindi ad es.Ad Block Pro e tutti gli altri plugin del browser probabilmente "leggono" le mie e-mail.
È un punto molto buono e originale che non ho specificato loro come consegnarlo.Probabilmente hai ragione, ho impostato il livello implicitamente basso.Ma ho chiesto loro solo la CSR, che credo sia condivisibile, quindi questo non ha aumentato il mio normale livello di consapevolezza, ad esin passato ho chiesto agli host di salvare le credenziali in un file nell'ambiente ospitato a cui posso accedere (tramite SCP).
Avrei dovuto menzionare che la persona in cc è il "titolare del conto" e io sono il "contatto tecnico", quindi sembra che li facciano sempre in cc.Non ho addestrato quella persona, perché non mi aspettavo un problema.
@Zoredache: sì, mi riferivo a qualcuno che può anche configurare un MITM, come un amministratore di qualsiasi sistema nel datacenter del web host / percorso di rete a monte, o qualcuno che esegue un [DNS pubblico ampiamente utilizzato] (https: // sviluppatori.google.com/speed/public-dns/).Qualcuno che può intercettare le tue e-mail potrebbe almeno modificare la tua e-mail in modo che contenga due CSR, quello vero e uno contraffatto, e raccontarti una storia di copertina plausibile come avere un bilanciatore del carico ridondante in cui installa un certificato separato e che l'HSM nosupporta l'esportazione della chiave privata.
"La configurazione di un canale autenticato può essere un processo piuttosto complicato" - Considera keybase.io come un canale autenticato?
Peter Green
2017-04-13 02:59:57 UTC
view on stackexchange narkive permalink

Prima di prendere in giro me stesso, vorrei confermare che la chiave privata per un certificato "SSL" (TLS) non deve mai lasciare il server?

Dipende, ci possono essere buone ragioni per lasciare il server. Ad esempio, potresti voler utilizzare lo stesso certificato su server server o potresti volere una chiave di backup per il blocco della chiave.

Ma assolutamente dovrebbe essere trattato come un prezioso segreto, solo memorizzati su macchine di cui ti fidi e se ha bisogno di spostarsi tra i sistemi, dovrebbe essere fatto in modo adeguatamente protetto.

Il mio consiglio sarebbe di allontanarti immediatamente da questi pagliacci.

Buon punto, l'ho fatto anche io in passato.Mi sentivo adeguatamente nervoso nel farlo e ho usato SSH per trasferirlo direttamente al secondo host.
trognanders
2017-04-13 03:33:08 UTC
view on stackexchange narkive permalink

Probabilmente volevano che tu avessi l'intera coppia chiave / certificato nel caso in cui volessi usarla altrove.

Avere la chiave privata fluttuante è una preoccupazione legittima per la sicurezza, soprattutto se non la utilizzerai. Spiega che questo certificato è solo per il provider di hosting e chiedi loro di riemettere il CSR e inviarlo senza una chiave privata. Verifica che l'identificazione personale CSR cambi.

Sembra che trattino il certificato come un modo per far apparire un lucchetto verde più che come un dispositivo di sicurezza, che è probabilmente un segnale di avvertimento. Considera un hosting diverso se possibile e / o se il tuo sito gestisce informazioni molto sensibili.

Marquis of Lorne
2017-04-13 05:47:10 UTC
view on stackexchange narkive permalink

Sono assolutamente incompetenti in materia di sicurezza. Una chiave privata è, err, privata, per definizione. Serve per identificare legalmente il suo proprietario. Hanno reso possibile la falsificazione e il furto d'identità.

Tu dovresti inviare a loro la CSR, dopo averla generata tu stesso da la tua coppia di chiavi privata / pubblica e loro dovrebbero inviarti il ​​certificato firmato e la sua catena di autenticazione. Nient'altro.

Se ti stanno inviando chiavi private e CSR, il loro intero modello è rotto.

Cambia provider e ricevi indietro i tuoi soldi. meno. Hanno compromesso la tua sicurezza, quindi un'azione per perdita e danni potrebbe mentire. Almeno puoi minacciarli con esso per facilitare il processo di rimborso.

Sono abbastanza sicuro che non identifichi _legalmente_ il suo proprietario, solo tecnologicamente.
Penso che tu abbia frainteso il ruolo del provider qui (a meno che io non l'abbia fatto): non stanno emettendo il certificato, lo stanno installando su un server a cui l'OP ha solo accesso limitato.L'OP non può generare la coppia di chiavi, perché non ha accesso per installare la chiave privata nella configurazione del server web.Se lo facessero, * loro * avrebbero bisogno di trasmettere la chiave privata * all'host *.L'host che genera la coppia di chiavi e invia la CSR sembra essere assolutamente il processo giusto, ma ha perso il punto condividendo la chiave privata.
@QPaysTaxes Una firma digitale con chiave privata è legalmente applicabile come del tutto equivalente a una firma personale su un contratto o assegno.
@IMSoP Se più di una persona ha la chiave privata, non è privata.Se il ruolo del provider è interpretato in questo modo, è radicalmente insicuro.Mandarlo in giro viola del tutto PKI.
@EJP Eh, non ne avevo idea.È davvero fantastico!Per curiosità, puoi citare una legge / sentenza specifica che l'ha resa tale?È globale, o diffuso o specifico per gli Stati Uniti?
@QPaysTaxes È lo * scopo * delle firme digitali essere legali.È una legge ben consolidata negli Stati Uniti, in Australia, nel Regno Unito, ... Non sono un avvocato e non posso fornire i riferimenti che cerchi.
@EJP Sì, ho capito.Ma hai perso il punto nella domanda originale che l'unica persona che dovrebbe detenere questa particolare chiave privata è l'host web.Siamo tutti d'accordo sul fatto che abbiano sbagliato condividendolo, ma il tuo suggerimento che l'OP dovrebbe generare la propria coppia di chiavi non ha senso, perché la chiave privata deve finire nella configurazione del server, a cui solo la società di hosting ha accesso.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...