DNS hijacking e Subject Alternative Names

Question

DNS hijacking e Subject Alternative Names

#1 da (1 voti)

0

Il mio sito web è pubblicato su Hosting di Firebase di Google. Possiedo il dominio. Google fornisce un certificato SSL (ultimamente da Lets Encrypt, era qualcun altro). Il certificato è condiviso tra più domini utilizzando i Nomi alternativi oggetto. Non possiedo questi altri domini.

Once domain ownership is verified we will provision an SSL certificate for your domain and deploy it across our global CDN. This process can take several hours.

Domains will be listed as Subject Alternative Names in the FirebaseApp SSL certificate.

La mia domanda è: cosa succederebbe se un attacco di dirottamento DNS reindirizzasse le richieste al mio dominio verso uno degli altri domini che condividono lo stesso certificato? Una richiesta al mio dominio verrebbe ricevuta da uno degli altri servizi che condividono il certificato. Come reagirebbe il server? Il mio browser accetterebbe la risposta? In caso contrario, come è protetto contro?

http dns tls man-in-the-middle san

posta Colonel Panic 07.07.2017 - 17:42

fonte

1 risposta

Leggi altre domande sui tag http dns tls man-in-the-middle san

Password e login verse stringa molto lunga (token) OCSP pinzatura Alice e Bob

score 1 · Accepted Answer

Nel caso più semplice, il tuo dominio su Firebase Hosting condivide lo stesso indirizzo IP con gli altri host menzionati nello stesso certificato, il che significa che non c'è nulla in realtà nello spoofing del DNS.

Se l'indirizzo IP non è sicuro e la risposta DNS può essere falsificata per puntare a un indirizzo IP diverso che serve lo stesso certificato, sia il nome del server all'interno dell'handshake TLS che l'intestazione Host all'interno della richiesta HTTP avranno ancora il tuo dominio in esso. Il modo in cui il server web reagisce alla presenza di un dominio all'interno di queste intestazioni che non è configurato sul server Web dipende dalla configurazione del server, il che significa anche che il comportamento potrebbe cambiare nel tempo. I comportamenti tipici sono risposte sane come un errore a livello TLS (nome_server sconosciuto), un errore a livello HTTP o una risposta folle di dati di ritorno da un altro dominio sul server. Mi aspetterei che il server sia configurato in modo sano ma non abbia modo di testarlo. Ma se sai che lo stesso certificato viene effettivamente utilizzato su diversi indirizzi IP puoi provarlo tu stesso:

$ openssl s_client -connect IP:port -servername example.com
GET / HTTP/1.0
Host: example.com