Come configurare il servizio di bilanciamento del carico F5 e il server di back-end entrambi con certificati SSL

Naviga le tue risposte
2

Possiedo un servizio di bilanciamento del carico F5 e un server back-end . Il bilanciamento del carico è www.example.com . Il server di backend è server1.example.com . Dispongo del bilanciamento del carico F5 con SSL Profile (client) e SSL Profile (server) abilitato e SSL certs sul server di bilanciamento del carico e back-end. Quindi sembra questo:

Client (laptop) --> HTTPS/SSL --> F5 Load Balancer (www.example.com) --> HTTPS/SSL --> Backend server (server1.example.com)

Il server di backend è in esecuzione Windows 2012 / IIS 8.5 . Nei binding, il campo Nome host è vuoto.

Mi aspettavo che una richiesta di www.example.com fallisse perché il CERT SSL del server back-end è per server1.example.com . In realtà ha successo. Non capisco perché funzioni.

Se imposto il Nome host nei collegamenti IIS a server1.example.com , la richiesta non riesce. Se lo lasci in bianco o lo imposti su www.example.com , la richiesta ha esito positivo. Non so perché. Non ha senso.

Capisco che F5 LB agisca da client nell'handshake tra se stesso e il server di backend. Ma la mia comprensione è che la F5 sta inviando una richiesta per www.example.com (nome host) al server di back-end. Il certificato SSL back-end è per server1.esempio.com . Pertanto, la richiesta non dovrebbe essere eseguita poiché il nome host inviato da F5 non corrisponde al nome host associato al certificato SSL del server back-end. Cioè www.example.com! = Server1.example.com .

Per favore dimmi dove mi sbaglio nella mia logica, perché ovviamente lo sono. Semplicemente non capisco perché funzioni.

Grazie.

    
posta user3621633 21.10.2016 - 18:11
fonte

1 risposta

1

I understand the F5 LB is acting as the client in the handshake between itself and the backend server. But my understanding is the F5 is sending a request for www.example.com (host name) to the backend server. The backend SSL cert is for server1.example.com. Therefore, the request should fail because the host name being sent by the F5 does not match the host name associated with the backend server SSL cert. That is, www.example.com != server1.example.com.

Non sono sicuro di cosa intendi con "la richiesta dovrebbe fallire". Quale agente avrebbe fallito? Il server non convalida il certificato SSL con il nome host; il client (in questo caso, il LB) fa.

Poiché è il LB responsabile della convalida del certificato, può capire in modo intelligente cosa sta succedendo e validare rispetto al nome host corretto piuttosto che al nome host del singolo nodo del server.

Quindi ecco approssimativamente cosa succede:

  1. Browser cerca l'indirizzo IP associato a www.esempio.com
  2. Il browser stabilisce una connessione TCP / IP all'indirizzo
  3. Il browser stabilisce una connessione TLS su TCP / IP, recuperando così il certificato dall'LB (www.example.com)
  4. Il browser convalida l'oggetto del certificato contro il nome di dominio presentato al punto 1 sopra; se non corrispondono, ricevi un avviso di phishing
  5. Il browser invia il payload HTTP su TCP / IP + TLS per caricare il bilanciatore. Questo payload include un'intestazione HTTP "Host: www.example.com"
  6. LB valuta le regole di bilanciamento del carico e seleziona un server back-end a cui indirizzare la richiesta. L'output di questo è un nome del server o un indirizzo IP, a seconda di come è stato impostato.
    • Se si tratta di un nome host, viene utilizzato solo per la ricerca IP; viene scartato immediatamente dopo, perché il nome del nodo server non significa nulla per il sistema in generale.
    • Se si tratta di un indirizzo IP, il LB lo userà semplicemente. Si noti che in questa configurazione, il LB non impara mai nemmeno che il nome del server back-end è server1.example.com; in effetti non ha idea di quale sia il suo nome.
  7. LB stabilisce la connessione TCP / IP al server back-end
  8. LB stabilisce la connessione TLS al server back-end, recuperando in tal modo il certificato dal server back-end (www.example.com)
  9. LB convalida l'oggetto del cert back-end con l'intestazione host fornita dal client originale, nel passaggio 5 (www.example.com)
  10. LB crittografa nuovamente il payload HTTP e lo inoltra al server back-end. Include l'intestazione HTTP "Host: www.example.com" e può anche includere intestazioni aggiuntive come x-forwarded-for.

Non dovresti mai avere un'intestazione host che dice server1.example.com, né verrà mai usato quel nome host per la convalida del certificato SSL.

    
risposta data 22.10.2016 - 01:54
fonte

Leggi altre domande sui tag

Impostazione dell'intestazione HTTP X-Frame-Options DENY per le risorse statiche Passi successivi dopo l'utilizzo dell'iniezione SQL cieca