Convalida nome host per certificato lato server

È una tua decisione. Pro e contro su entrambi i lati.

Se applichi controlli rigorosi, allora questa è un'altra cosa che può rompersi. Se non ti interessa la crittografia dal servizio di bilanciamento del carico al server back-end, lasciala fuori. Questo è qualcosa che puoi scegliere di fare se hai deciso che il lato LAN del LB è abbastanza sicuro per te.

• Se decidi che devi preoccuparti degli attaccanti ACTIVE lato LAN, allora assolutamente, ricodificarlo (o forse non decrittarlo mai e fare solo un bilanciamento del carico limitato) ed essere severo su di esso.

• Se decidi che devi preoccuparti degli intercettatori PASSIVI solo lato LAN, allora la crittografia senza autenticazione lo farà.

• Se decidi che non devi preoccuparti di nessun attaccante lato LAN, allora non hai bisogno di crittografia lì.

E come per il tipo di cliente: "client automatizzato". Gli utenti devono / devono non essere consapevoli di qualsiasi bilanciamento del carico anche esistente nel percorso di rete.

Dipende:

• Se si prevede un certificato specifico, il modo più sicuro consiste nel configurare il proxy inverso che prevede esattamente questo certificato. In questo caso l'oggetto effettivo del certificato non ha importanza e può anche essere autofirmato, in quanto il proxy inverso non accetterà altro che questo certificato.
• Se invece si accetta un certificato purché sia firmato da una CA attendibile, è necessario verificare ulteriormente l'oggetto. In caso contrario, un attacco man-in-the-middle potrebbe essere eseguito da qualsiasi altro certificato emesso da una CA attendibile e, almeno se si utilizza la CA pubblica, questi certificati sono facili da ottenere senza alcun tipo di hacking.

Per i certificati firmati da una CA pubblica solitamente il nome in subjectAltName / CN viene verificato rispetto al nome host effettivo del server (dall'URL) perché questa è considerata sufficientemente specifica e si prevede che nessuno possa ottenere un certificato per un hostname (s) che non possiede. Se disponi di un'altra proprietà che può essere utilizzata come identificatore sicuro con le stesse proprietà di quella che potrebbe essere utilizzata, la CA pubblica di solito desidera il nome host.

Come si propagano gli errori nel caso in cui il certificato non corrisponda dipende dal design esatto della propria applicazione. Ma di solito il reverse proxy fa parte del lato server e in questo caso gli errori nella validazione significano che c'è qualcosa di sbagliato sul lato server che deve essere corretto lì. Quindi potresti dire al cliente che qualcosa non va, ma i dettagli reali probabilmente non dovrebbero essere comunicati al cliente.

Innanzi tutto, un proxy inverso è per definizione un attaccante man-in-the-middle.

Notate Eccezioni: quando si utilizza Dove i pacchetti TLS / SSL non sono ispezionati.

Come altri hanno già detto, è una tua decisione ma non ci può essere REAL SECURITY per una comunicazione quando è presente un reverse-proxy.

-Jim