it-swarm.dev

Quali vulnerabilità potrebbero essere causate da un certificato SSL jolly?

In un commento su questa risposta , AviD dice:

"Esistono numerosi problemi di sicurezza con certificati SSL con caratteri jolly."

Quindi, quali sono i problemi? Comprendo che la stessa chiave privata viene utilizzata in più contesti, ma dato che potrei ospitare tutte le mie applicazioni con lo stesso nome host, non vedo questo come un "nuovo" problema introdotto dai certificati jolly.

46
user185

Un "certificato jolly" è un certificato che contiene, come possibile nome del server, un nome che contiene un "* "carattere. I dettagli sono in RFC 2818, sezione 3.1 . La linea di fondo: quando il certificato del server contiene *.example.com, sarà accettato dai client come certificato valido per qualsiasi server il cui nome apparente corrisponde a quel nome.

Nel settore della certificazione per siti Web, ci sono quattro attori principali:

  • Il server SSL stesso.
  • Il fornitore del browser Web che verrà utilizzato dal client.
  • L'utente umano, che controlla in una certa misura ciò che farà il browser client.
  • L'autorità di certificazione che ha emesso il certificato sul server.

I certificati jolly non implicano vulnerabilità extra per il server SSL; infatti, il server SSL non ha interesse a guardare il proprio certificato. Tale certificato è a vantaggio dei clienti, per convincerli che la chiave pubblica contenuta nel certificato è effettivamente la chiave pubblica del server SSL originale. Il server SSL lo sa la sua coppia di chiavi pubblica/privata e non deve essere convinto al riguardo.

L'utente umano non ha idea di cosa sia una chiave pubblica. Ciò che vede è un'icona a forma di lucchetto e, cosa più importante, il nome server previsto : questo è il nome a destra di "https:// "e prima del prossimo" / ". Il browser Web è supposto per gestire i dettagli tecnici della verifica della correttezza del nome, ovvero della convalida del certificato del server e della verifica che il nome corrisponda a quello scritto nella detto certificato. Se il browser non svolge questo lavoro, verrà visualizzato come trascurato e non assumerà il suo ruolo, che può avere gravi conseguenze commerciali, possibilmente anche legali. Allo stesso modo, la CA è vincolata contrattualmente a seguire le procedure definite per identificare SSL proprietari di server in modo che sia difficile ottenere certificati falsi per gli aggressori (il contratto è tra la CA e la sua über-CA, ricorsivamente, fino alla CA principale che è a sua volta vincolata da un patto con il sistema operativo o il fornitore del browser, che ha accettato di includere la chiave CA principale nel sistema operativo o nel browser in condizioni definite).

Ciò equivale a dire che browser e [~ # ~] ca [~ # ~] devono, in pratica, coccolare l'utente attraverso il processo di verifica. Sono più o meno obbligati (per legge o, ancora più rigorosamente, per considerazioni commerciali) a impedire che l'utente venga truffato attraverso siti falsi che sembrano legittimi. Il confine tra il lavoro dell'utente e il lavoro del browser/CA non è chiaramente definito e si è storicamente spostato. In Days of Yore, intendo circa dieci anni fa, i browser hanno appena stampato l'URL non elaborato ed è compito dell'utente umano trovare il nome del server in esso. Questo ha indotto i gestori di siti (ad esempio "siti di phishing") a utilizzare URL tecnicamente validi, ma fuorvianti, come questo:

https://www.Paypal.com:[email protected]/confirm.html

Dato che gli utenti umani sono, beh, umani e la maggior parte di essi legge da sinistra a destra (la maggior parte degli obiettivi di truffa ricchi e creduloni sono ancora nei paesi occidentali), inizieranno a sinistra, vedi www.Paypal.com, fermati al segno dei due punti ("troppo tecnico") e fatti truffare.

In reazione, i venditori di browser hanno riconosciuto che le capacità di analisi degli URL degli utenti umani non sono buone come inizialmente ipotizzato, e quindi i browser recenti evidenziano la parte del dominio. Nel caso sopra, questo sarebbe xcvhjvb.com, e certamente niente con Paypal.com dentro. Ora arriva la parte in cui certificati jolly entrano nel gioco. Se il proprietario di xcvhjvb.com acquista un certificato con caratteri jolly contenente "*.xcvhjvb.com ", quindi può impostare un sito di phishing chiamato:

https://Paypal-payment-interface-login-session.xcvhjvb.com/confirm.html

che verrà accettato dal browser (corrisponde al nome jolly) ed è ancora probabile che catturi utenti indesiderati (e ce ne sono molti ...). Questo nome potrebbe è stato acquistato dall'aggressore senza ricorrere a caratteri jolly, ma i dipendenti della CA avrebbero visto il nome con evidente tentativo fraudolento (buona CA do una convalida umana di ogni richiesta di certificati, o almeno generare avvisi per nomi che sono molto lunghi e/o che contengono nomi bancari noti in essi).

Pertanto, i certificati jolly riducono l'efficacia delle misure di contenimento delle frodi sul lato CA . È come una firma vuota della CA. Se i tentativi di phishing basati su caratteri jolly diventano più comuni, ci si può aspettare che una o più delle seguenti misure entrino in vigore:

  • I browser evidenziano solo le parti del nome di dominio che corrispondono agli elementi non jolly nel certificato.
  • CA richiede documenti e contratti più pesanti per i certificati jolly (e questi saranno più costosi).
  • I browser disattivano del tutto il supporto per i certificati con caratteri jolly.

In realtà mi aspetto che tutte e tre le misure vengano applicate nei prossimi anni. Potrei sbagliarmi totalmente (questo è il problema con la previsione del futuro) ma questo è ancora il mio istinto.


Nitpickingly, possiamo anche sottolineare che i certificati jolly sono utili per condividere la stessa coppia di chiavi tra server diversi nomi, il che rende più probabile che la chiave privata verrà condivisa tra server diversi Macchine. Le chiavi private in viaggio rappresentano un rischio per la sicurezza a sé stante; più una chiave privata vaga, meno rimane "privata".

35
Thomas Pornin

È una pratica scorretta diffondere la stessa chiave privata su più server fornendo servizi diversi: qualsiasi problema di sicurezza sfruttato in qualsiasi servizio rivelerà la chiave privata utilizzata per tutto.

Ma è comune utilizzare certificati con caratteri jolly per isolare il contenuto Web fornito dagli utenti nei sottodomini specifici dell'utente per sfruttare la stessa politica di origine. Lo stesso approccio viene comunemente utilizzato per il rendering di portlet non attendibili. Fa parte del Open Social "standard".

Nel mio posto di lavoro sviluppiamo un software che contiene un'implementazione social aperta e utilizza la configurazione con caratteri jolly. Le installazioni dei clienti sono state sottoposte a test di penetrazione. L'impostazione dei caratteri jolly non è stata criticata.

18

Alla fine, molte delle vulnerabilità rilevate in queste risposte provengono dal mescolare i livelli di fiducia. Ma se capisci come funzionano i certificati jolly, puoi mitigare queste vulnerabilità per casi d'uso particolari. Penso che spiegarlo in modo più dettagliato migliorerà l'utilità di questa domanda e delle sue risposte.

A meno che tutti i sistemi nel tuo dominio non abbiano lo stesso livello di attendibilità, è una cattiva idea usare un certificato jolly per coprire tutti i sistemi sotto il tuo controllo. Ma puoi utilizzare i sottodomini DNS come strumento di segmentazione. Come ha detto Hendrik, poiché i caratteri jolly non attraversano i sottodomini, è possibile limitare un certificato jolly a uno spazio dei nomi specifico. Ad esempio, se avessi una farm CDN, potresti jolly solo *.cdn.example.com. Ciò mantiene gli host in example.com stesso (come www.example.com) separato e potresti emettere un certificato separato per www.example.com.

Come ha affermato AviD da OWASP: le workstation interne, i sistemi di sviluppo ecc. Appartengono a livelli di affidabilità inferiori. Tuttavia, host come questi dovrebbero trovarsi comunque nel proprio spazio di dominio interno (come prv.example.com). Poiché i caratteri jolly non attraversano i sottodomini, un *.example.com cert non può essere applicato a prv.example.com host. (Ciò manterrebbe le proprietà pubbliche e private separate, ma ovviamente non separa le proprietà private le une dalle altre. È possibile utilizzare altri caratteri jolly del sottodominio, mappati su livelli di attendibilità appropriati).

Mentre questo articolo eWeek nota che la chiave privata può essere condivisa su più host, questa confutazione SSLShopper dice che alcuni emittenti (come DigiCert) ti consentono di generare chiavi private separate per ogni Host con caratteri jolly. Ciò riduce parte dell'utilità dei certificati jolly, ma mitiga definitivamente il problema delle chiavi private-condivise e potrebbe essere utile in alcune circostanze. Altrimenti, questo articolo di Entrust e il white paper PDF a cui fa riferimento discute le migliori pratiche per la gestione delle chiavi private se utilizzate con certificati jolly.

Infine, ricorrendo all'argomento dell'autorità ... se Google utilizza i caratteri jolly per alcune delle loro proprietà , non devono essere universalmente cattivi:

Qualys SSL Labs screenshot for youtube.com cert

:-)

9
Royce Williams

Idealmente, l'elenco di servizi che un certificato/chiave può essere utilizzato per impersonare dovrebbe essere lo stesso dell'elenco di servizi per cui il certificato/chiave è destinato.

Diciamo che hai un dominio example.com. Hai impostato vari nomi host sotto quel dominio www.example.com catpictures.example.com users.example.com. Tutti sono ospitati sullo stesso server in modo da ottenere un certificato per coprirli tutti.

Ora supponiamo che tu abbia impostato secure.example.com su un server più altamente protetto. Diciamo che hai un certificato separato per quel server.

Ora considera cosa succede se la chiave privata corrispondente al certificato sul primo server viene rubata.

Se si trattava di un certificato per * .example.com (un certificato jolly), gli aggressori possono usarlo per impersonare secure.example.com

Se si trattava di un certificato per www.example.com catpictures.example.com e users.example.com, gli aggressori non possono utilizzarlo per impersonare secure.example.com

4
Peter Green