Come rilevare i certificati SSL "falsi" dal server web

Se capisco correttamente la domanda, mi chiedi se è possibile rilevare (sul lato server di una connessione HTTPS) se la connessione proviene da un server proxy o da un client reale (un browser)?

(Inizialmente non ero riuscito a vedere come il certificato avrebbe fornito informazioni preziose, ma ora mi rendo conto di cosa mi mancava prima. Quello che è stato suggerito è di fornire all'utente un javascript, attivarlo tramite il codice HTML e l'utente rimanda i dati estratti dal certificato SSL come sarebbe il certificato fornito dal proxy Sì, dovrebbe funzionare e sembra alquanto improbabile che il proxy-server possa filtrare tali "azioni" dal javascript. ! )

Analizzare quanto segue può aiutare a scoprire l'originatore di una connessione:

• Ordinamento intestazione HTTP
• Intestazioni HTTP specifiche per browser
• Valori del cookie HTTP
• Comportamento HTTP

Ordinamento di intestazione HTTP - Il rilevamento dell'originatore della connessione dovrebbe essere teoricamente possibile analizzando l'ordine delle intestazioni HTTP. I browser tendono a strutturare i loro header HTTP in specifici "pattern", utilizzando questa conoscenza può essere possibile:

1. Crea un'impronta digitale univoca per il proxy determinando in che modo il proxy organizza le intestazioni HTTP.
2. Con "in anticipo" sapere in che modo i browser comuni ordinano le intestazioni HTTP e confrontarle con l'ordine della richiesta corrente. (Chiaramente non è la migliore idea ...)

Intestazioni HTTP specifiche per browser - Potrebbe essere possibile che il server proxy includa intestazioni HTTP specifiche che un browser non avrebbe. Questi potrebbero essere per il bilanciamento del carico o il reindirizzamento del tipo di richiesta e così via.

Valori del cookie HTTP - È anche plausibile che il proxy inserisca un valore di cookie specifico per avviare una connessione a un server specifico se viene utilizzato il bilanciamento del carico o il clustering.

Comportamento HTTP - Sebbene non sia esattamente facile da implementare, potrebbe essere possibile rilevare la presenza di un proxy avviando un numero di codici di ritorno specifici per HTTP e analizzando in che modo il "client" risponde alle richieste. Forse questo potrebbe consentire il rilevamento di un comportamento insolito che sarebbe considerato non comune per i normali browser.

Supponendo un server HTTP Apache potrebbe essere possibile utilizzare le regole mod_security per ottenere alcuni dei precedenti.

Qualche altro modo, probabilmente improbabile e inaffidabile, di rilevare l'origine di una connessione è quello di ispezionare campi specifici del protocollo (IP / TCP) come timestamp, opzioni IP. Questi possono cambiare in modo particolare assumendo l'origine di un server proxy.

Potrebbe anche essere possibile determinare l'origine in base ai tempi, nonostante siano soggetti a un po 'di jitter e rumore, in teoria potrebbe essere determinato se un proxy intercetta la connessione. Non sto suggerendo che questo sarebbe affatto affidabile o addirittura possibile, ma un po 'può essere determinato attraverso i tempi.

L'unico modo che posso vedere è di aprire un XMLHTTPRequest su SSL e di estrarre il certificato da quella connessione:

• MDN: Come verificare lo stato di sicurezza di un XMLHTTPRequest su SSL ( archivio )

Questo non funziona da una pagina Web, ma è necessario che venga eseguito da un'estensione.

Come già sottolineato, il proxy può facilmente cambiare il javascript per eliminarlo.

Se il server utilizza l'autenticazione client basata su certificato (cioè il client ha anche un certificato e usa la sua chiave privata per autenticarsi), allora il server rileverà l'intercettatore - perché in quel caso il client firma un valore hash calcolato sui messaggi handshake ricevuti in precedenza, che includono il certificato del server come visualizzato dal client. In presenza dell'intercettore, il client firma il valore sbagliato e l'intercettore non può correggerlo.

Una soluzione alternativa è utilizzare TLS con SRP , in cui l'autenticazione non è basata su certificati ma basata su password e reciproca.

Altrimenti, no.

Per convenzione, un proxy standard dovrebbe includere la richiesta X-Forwarded-For HTTP intestazione , anche se non si trova nella RFC , è considerato di fatto lo standard.

Detto questo, se il proxy vuole nascondere la sua esistenza, non c'è alcun problema a ignorare semplicemente inserendo questa intestazione.

Queste risposte sono un po 'datate e i seguenti sviluppi recenti dovrebbero essere rilevanti:

link

A Pin is a relationship between a hostname and a cryptographic identity (in this document, 1 or more of the public keys in a chain of X.509 certificates). Pin Validation is the process a UA performs to ensure that a host is in fact authenticated with its previously- established Pin.

Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to
perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)

The UA will not be able to detect and thwart a MITM attacking the
UA's first connection to the host. (However, the requirement that
the MITM provide an X.509 certificate chain that can pass the UA's
validation requirements, without error, mitigates this risk
somewhat.) Worse, such a MITM can inject its own PKP header into the HTTP stream, and pin the UA to its own keys. To avoid post facto
detection, the attacker would have to be in a position to intercept
all future requests to the host from that UA.

Thus, key pinning as described in this document is not a perfect
defense against MITM attackers capable of passing certificate chain
validation procedures -- nothing short of pre-shared keys can be.
However, it provides significant value by allowing host operators to
limit the number of certification authorities than can vouch for the host's identity, and allows UAs to detect in-process MITM attacks
after the initial communication.

...

2.1.4. The report-uri Directive

The OPTIONAL report-uri directive indicates the URI to which the UA SHOULD report Pin Validation failures (Section 2.6). The UA POSTs
the reports to the given URI as described in Section 3.

Oltre ad essere standardizzato, credo che al momento sia supportato da almeno Chrome e Firefox, ma dovrebbe essere controllato.