Reverse proxy che condivide un certificato per più server usando Subject Alternative Name

Question

Reverse proxy che condivide un certificato per più server usando Subject Alternative Name

#1 da (2 voti)

0

Quello che segue è uno scenario per un attacco in cui un sito Web può impersonare un altro. Mi è stato detto (anche con questa risposta ) che è impossibile, ma mi piacerebbe capire esattamente cosa lo impedisce.

Alice utilizza siti Web che recuperano una risorsa JS attendibile dal server di Bob, utilizzando HTTPS per prevenire attacchi MITM. La risorsa di Bob è popolare e inizia a utilizzare un CDN per distribuirlo. Ora il browser di Alice sta effettuando una connessione HTTPS con un server appartenente al CDN.

Il CDN utilizza Subject Alternative Names per condividere un certificato tra più clienti i cui siti condividono un indirizzo IP sulla CDN. Eve capita di possedere un sito che è sullo stesso certificato di Bob's (1). Eve conosce la caffetteria preferita di Alice e può intercettare i segnali sul wifi lì.

Poiché Eve non ha la chiave privata del certificato, non può leggere il traffico HTTPS di Alice. Invece, attende una richiesta per la risorsa sul sito di Bob (2) e la sostituisce con una richiesta al proprio sito, tramite lo stesso indirizzo IP CDN che trasmette proxy a entrambi i siti. Il server CDN decrittografa la richiesta, recupera una risorsa dannosa dal sito di Eve e la crittografa utilizzando il certificato condiviso. Il browser di Alice vede una risposta valida dall'IP CDN a cui ha inviato la richiesta e apparentemente non ha motivo di non accettarlo. Notare che Eve non ha bisogno di modificare la risposta di MITMing - il server CDN rimanda il contenuto malevolo da un server dietro di esso.

O è in grado di inciderne uno. Uno di questi è destinato ad essere insicuro.
L'URL è crittografato in una richiesta HTTPS? In tal caso, supponiamo che Eve sostituisca tutte le richieste che vanno all'indirizzo IP pertinente e che le scommesse sul rilevamento siano improbabili.

Non ho molta familiarità con SSL, quindi sono disposto a credere che qualcosa in questo non regga, ma non sono sicuro di cosa, esattamente.

tls certificates multi-tenancy

posta Thomas K 06.08.2014 - 00:35

fonte

1 risposta

Leggi altre domande sui tag tls certificates multi-tenancy

richiede alternative di sicurezza a livello di rete a una VPN Nodi di ingresso Tor, PGP e Tor

score 2 · Accepted Answer

In questo caso quando più siti web sono serviti dallo stesso server sulla stessa porta, quel server li differenzia tra loro confrontando l'intestazione Host: nella richiesta HTTP.

Una volta avvenuta la negoziazione TLS, non è possibile leggere nulla all'interno di quella richiesta. Inoltre, non è possibile scambiare tra due connessioni SSL simultanee perché un semplice scambio di chiavi Diffie-Hellman produce una chiave diversa per ciascuna negoziazione.

Questo è il nocciolo del problema: l'intestazione Host: è all'interno della trasmissione crittografata SSL . Pertanto, non è possibile manomettere tale intestazione e non è possibile reindirizzare tale richiesta anche a un altro VirtualHost sulla stessa macchina.

Senza la chiave privata, non c'è molto che puoi fare per rompere SSL.

EDIT: Sì. Quello che stai suggerendo richiederebbe una sorta di manomissione della richiesta. SSL consiste fondamentalmente in un pacchetto TCP con un contenuto completamente confuso e ciò che si vuole fare in questo caso è alterare il contenuto alterato in modo da rendere illecita una diversa risposta dal server. Questo non è possibile senza rompere SSL. L'unica modifica che potresti fare è l'intestazione TCP per cambiare l'IP o la porta di destinazione, ma nel tuo caso ciò non comporterà nulla visto che intendi ancora indirizzare lo stesso servizio su quello stesso server.

Chiarificazione su SSL Negation

La negoziazione SSL utilizza una chiave diversa ogni volta. Fondamentalmente, il client genera un numero casuale e lo crittografa utilizzando la chiave pubblica. Questo può essere decrittografato solo con la chiave privata. A questo punto, solo il client (che ha generato la chiave) e il server (che è stato in grado di decodificarlo con la propria chiave privata) conoscono questo numero casuale.

Non c'è modo per un attaccante di ottenere quel numero. Potresti, in teoria, ripetere lo stesso segreto criptato sul server per aprire una connessione usando la stessa chiave, tuttavia non sapresti ancora il segreto e non saresti in grado di alterare i pacchetti crittografati con esso.

Ciò consentirebbe comunque di utilizzare un attacco di replay (e di ripetere una richiesta come "elimina l'elemento successivo" di nuovo), quindi suppongo che ci siano altre funzionalità all'interno di SSL per mitigare questo rischio.