Multi-tenancy, certificati SSL e nome alternativo soggetto

Se ogni inquilino ha una copia della chiave privata, beh, lo hanno tutti, il che significa che possono falsificarsi a vicenda. Possono anche decrittografare il traffico tra altri tenant e i loro client, a meno che non utilizzino le suite di crittografia "DHE" di SSL, che rimuove questo problema specifico; questo è noto come Perfect Forward Secrecy . DHE non fa nulla contro il problema dello spoofing e può essere utilizzato solo se il software client è d'accordo.

Il trucco è, quindi, non per fornire la chiave privata a ciascun titolare. Invece di farli condividere lo stesso certificato , falli condividere lo stesso server SSL . Esegui un singolo server HTTPS affidabile che utilizza il certificato e quindi inoltra il traffico HTTP decrittografato al tenant rilevante (il cui nome è specificato nell'intestazione HTTP - non è necessario per SNI supporto qui). Effettivamente, una situazione delega inversa . Tale configurazione è sicura (gli inquilini non ricevono nulla); tuttavia, richiede ai tenant di fidarsi del server SSL condiviso (è ancora meglio che richiedere agli affittuari di fidarsi l'uno dell'altro), e interferirà con (in pratica, prevenire) l'uso di client certificati.

Sì, è rischioso come sembra. Non hai torto, e, AFAIK, non penso che ti manchi qualcosa.

Più entità che condividono lo stesso certificato che firma una chiave pubblica, significa che condividono la stessa chiave privata. Not A Good Thing ^TM . Se site1.com non si fida di site2.com , non devono essere configurati per utilizzare un nome alternativo soggetto ( SAN ) certificato.

Una buona CA verificherà che l'entità che richiede un certificato abbia la proprietà sui soggetti definiti nella SAN (nome di dominio, indirizzo IP, indirizzo email, ecc.)

Quindi in conclusione, i certificati SAN dovrebbero essere usati solo quando i soggetti coperti si fidano l'uno dell'altro. Un buon esempio di siti diversi che utilizzano lo stesso certificato (uno menzionato nella DMZ ), è il caso di siti SE. Anche se stackoverflow.com è un sito diverso da superuser.com , si fidano ancora l'uno dell'altro e appartengono alla stessa entità.

@Adnan e @Thomas Pornin toccano entrambi la prima parte del treppiede: se la chiave è accessibile solo dal provider condiviso (ad esempio, un CDN), la sicurezza non è necessariamente inferiore e se è condivisa da non connesso parti quindi la sicurezza è ridicolmente inferiore.

C'è una seconda gamba per il treppiede, che è la manutenzione. Supponiamo che la chiave sia detenuta solo dal provider condiviso (HostCo), quindi la sicurezza non è un problema. HostCo ha 20 tenant che inserisce nella chiave usando Subject Alternative Names (SAN). Grande! Giugno passa, luglio arriva, 3 inquilini se ne vanno e ne appaiono 4 nuovi. Ops! È tempo di ottenere un nuovo certificato emesso che rifletta gli add-on / cambiamenti. Grande. Ops! Agosto arriva ... vedi dove sta andando? Il mantenimento del ripristino di un certificato con più SAN è stupido nel tempo, a meno che il pool di nomi che si trova su una SAN non sia statico.

La terza parte del treppiede è denaro. Potrebbe essere più economico per HostCo utilizzare un certificato SAN piuttosto che uscire e acquistare 20 certificati. Questa gamba non ha senso, in realtà, dato che gli inquilini sono unità veramente scollegate che non si fidano l'una dell'altra, HostCo sta solo per passare i costi dei singoli certificati. Non c'è lo stesso incentivo economico che, ad esempio, Massive Dynamic deve risparmiare sul cert per il sito web che tutte le 273 delle sue filiali sono servite da.

Ecco tre gambe notevolmente traballanti. Non mi siederò su quello sgabello dato l'opzione.