SSL Sobject Alternativo Nome e Uomo in attacchi Medio

La mia azienda "ourcompany" possiede un nome a dominio DNS di livello 2: ourcompany.org . Attualmente utilizziamo questo dominio, nonché www.ourcompany.org e feature1.ourcompany.org e disponiamo di un certificato SSL generato per entrambi i domini di terzo livello.

Poi abbiamo sottoscritto un servizio ospitato da terze parti, ospitato presso ourcompany.thirdparty.org . Essi gestiscono SSL e hanno un certificato il cui sobject è thirdparty.org e possiede il nome sobject alternativo *.thirdparty.org .

Questa società di terze parti fornisce anche una funzionalità per aggiungere un dominio personalizzato. Quindi abbiamo aggiunto un record CNAME nella nostra configuration DNS, e ora abbiamo feature2.ourcompany.org punta a ourcompany.thirdparty.org . Ovviamente a questo punto SSL non funziona quando accede a feature2.ourcompany.org .

Poi la società di terze parti ci ha chiesto anche di immettere le voci DNS di TXT per dimostrare di essere proprietari del dominio e sono stati in qualche modo in grado di aggiornare il proprio certificato SSL e aggiungere i seguenti nomi alternativi di soggetti: ourcompany.org e *.ourcompany.org .

  • Come non è una potenziale fonte di attacco Uomo in mezzo? (la compagnia di terze parti può ora impersonarci in uno qualsiasi dei nostri domini)
  • Come può una società di terze parti arbitraria generare certificati SSL validi tra cui SAN che punta a un dominio che non possiede? (la loro SAN comprende molte più cose rispetto al record di dominio CNAME che abbiamo aggiunto)
  • L'autorità di certificazione ha autorizzato i nostri domini come SAN a causa del record CNAME che indica il proprio dominio (in questo caso, come venga inclusa la modalità SAN più domini di solo feature2.ourcompany.org ) o perché la voce TXT (in questo caso , qualcuno potrebbe dirmi una risorsa che spiega questo process)?

2 Solutions collect form web for “SSL Sobject Alternativo Nome e Uomo in attacchi Medio”

Dopo aver esaminato la nostra configuration DNS, sembra che l'autorità di certificazione validationsse le voci SAN nel certificato della società di terze parti a causa di una delle voci TXT che ci hanno chiesto di aggiungere: globalsign-domain-verification=XXXXXXX , where XXXXXXX è una chiave fornita da GlobalSign alla società di terze parti (la documentazione su questa funzionalità GlobalSign è difficile da trovare, ma potrei trovare qualcosa qui ). Questo risponde alla seconda e alla terza questione.

Quanto al primo, sembra che la voce TXT sia impostata sul dominio di secondo livello, la società di terze parti è ora autorizzata a includere il dominio di secondo livello nonché qualsiasi dominio di terzo livello sotto le voci SAN del proprio certificato.

l'azienda di terzi ha probabilmente bisogno di una verifica per dimostrare di avere accesso al dominio (come godaddy verifica su semplici ssl certs)

questo non significa che abbiano accesso al tuo nome di dominio e / o possa assumere i tuoi domini. anche questo non significa che possano fare un mitimo sulle connessioni stabilite tramite il proprio cert. è solo un certificato separato e quando si punta con un record dns corrispondente ai loro server verrà fornito il certificato. la gestione di molti certs su un singolo host / indirizzo è piuttosto commin dato che lo sni (nome del nome del server) è ben supportto oggi.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.