Autenticazione reciproca: autenticazione client sul server tramite IP / FQDN?

Is there any way to implement client authentication on the server's side based on the IP / FQDN presented by the client ?

Sì, questo può essere fatto. Per il certificato del server, il client verifica non solo la catena di certificati del certificato dei server, ma controlla anche l'oggetto rispetto al nome host dell'URL. Con i certificati client il server dovrebbe eseguire controlli simili, ovvero verificare l'oggetto del certificato rispetto all'oggetto previsto.

Ma la domanda rimane quello che dovrebbe essere il soggetto previsto. Nel caso di una VPN questo potrebbe essere l'indirizzo IP del client o il nome FQDN determinato da una inoltro confermato alla ricerca DNS inversa . O il server potrebbe avere una configurazione specifica che si aspetta da ogni endpoint VPN. Oppure se questa è solo una VPN per connettere un singolo client alla società, il certificato del cliente potrebbe contenere l'e-mail o il nome dell'account dell'utente.

Quindi in sintesi: sì, questo può essere fatto ma non esiste un unico vero modo. Invece, come dovrebbe essere fatto il soggetto dipende da come verrà utilizzato il prodotto e diversi prodotti offrono diversi modi di controllare l'oggetto del certificato.

Il modo in cui autenticare i certificati di un peer nell'autenticazione TLS reciproca non è, a rigor di termini, parte di TLS stesso, ma è parte del criterio dell'applicazione.

In che modo l'applicazione verifica l'autenticità del certificato, ad es. controllando che il FQDN / IP del peer corrisponda a quanto scritto nel campo C (omonimo) N (ame) o S (ubject) A (alternativo) (ame) o O (rganizational) U (nit) o verificando l'O (rganizzazione) ) per un valore specifico o la verifica dei vincoli di utilizzo della chiave estesa, sono specifici dell'applicazione.

Per la maggior parte delle applicazioni, è sufficiente autenticare il certificato client affidando il CN e l'Emittente. Ciò significa che devi scrivere la autorizzazione basata sul criterio CN del certificato. Ciò consente ai client di essere mobili (per spostarsi su indirizzi IP diversi) senza che la CA debba riemettere i nuovi certificati e che la CA rinnovi i certificati del client senza che il server debba aggiornare le autorizzazioni.

L'asimmetria qui è dovuta al fatto che nella maggior parte delle implementazioni VPN, ci si aspetta generalmente che i server rimangano in un posto, mentre i client dovrebbero essere mobili.

In alcune distribuzioni, se ritieni ragionevolmente che il client non sarà molto mobile, potresti voler limitare ulteriormente che un determinato CN può solo connettersi da un determinato intervallo di indirizzi IP. Questo può essere parte della politica di autenticazione della distribuzione e può essere eseguita al di fuori del certificato x.509. È sufficiente disporre di una tabella di CN e degli indirizzi IP a cui il CN è autorizzato a connettersi nell'applicazione / terminatore TLS. Non vedo alcun vantaggio di scrivere l'indirizzo IP consentito nel certificato stesso.

Is there any way to implement client authentication on the server's side based on the IP / FQDN presented by the client ?

Potrebbe essere fatto.

Il certificato del client REAL spesso non contiene alcuna informazione IP / FQDN. Per i certificati personali di solito è un nome e un identificatore, per le applicazioni di solito è un nome di sistema / nome dell'applicazione. In effetti puoi creare un certificato client contenente un nome host / IP.

Per quanto riguarda il TLS, il server convalida solo la validità del certificato (se il server si fida del certificato o di qualsiasi CA nella catena). È normale che le applicazioni (sopra il TLS) impongano un filtro per convalidare il certificato fornito sia accettabile .

I'm asking also because several SSL VPN remote access solutions mention TLS1.2 mutual authentication - but technically I have the feeling that the way server and client are authenticating each other is somehow asymmetrical.

Per lo stesso SSL, il nome host non è così importante. Per il lato server, il nome host viene comunemente convalidato, ma è compito del cliente decidere se fidarsi o meno (solo un buon esempio sono i record CNAME DNS, il client viene effettivamente reindirizzato - dovrebbe fidarsi del nuovo nome host o no ?).

La tua intuizione è giusta, i client (principalmente per le persone) non possono imporre l'IP statico o il nome host. È possibile specificarlo nel certificato, ma il server in realtà non lo controlla (spesso non ha mezzi per farlo, ad esempio l'indirizzo IP fornito è spesso il proxy o VPN).