2.4. Processing Rules (Regole di elaborazione)

2.4. Processing Rules (Regole di elaborazione)

Questa sezione delinea le regole di elaborazione applicabili per un TTRP che ha negoziato una connessione TLS mutuamente autenticata per trasmettere il certificato client da quella connessione ai server di origine backend. Questa tecnica deve essere utilizzata come opzione di configurazione o deployment, e le regole di elaborazione descritte qui sono per server che operano con tale opzione abilitata.

Un TTRP negozia l'uso di una connessione TLS mutuamente autenticata con il client, come descritto in [TLS] o [TLS1.2], e valida il certificato client secondo la sua politica e le autorità di certificazione fidate. Ogni richiesta HTTP sulla connessione TLS sottostante viene distribuita al server di origine con le seguenti modifiche:

1. Il certificato client viene posizionato nel campo di intestazione Client-Cert della richiesta distribuita, come descritto nella Sezione 2.2.

2. Se così configurato, la catena di validazione del certificato client viene posizionata nel campo di intestazione Client-Cert-Chain della richiesta, come descritto nella Sezione 2.3.

3. Qualsiasi occorrenza dei campi di intestazione Client-Cert o Client-Cert-Chain nella richiesta in entrata originale DEVE essere rimossa o sovrascritta prima di inoltrare la richiesta. Una richiesta in entrata che ha un campo di intestazione Client-Cert o Client-Cert-Chain PUÒ essere rifiutata con una risposta HTTP 400.

Le richieste al TTRP effettuate su una connessione TLS in cui l'uso dell'autenticazione tramite certificato client non è stato negoziato DEVONO essere sanificate rimuovendo tutte le occorrenze dei campi di intestazione Client-Cert e Client-Cert-Chain prima di distribuire la richiesta al server backend.

I server di origine backend possono quindi utilizzare il campo di intestazione Client-Cert della richiesta per determinare se la connessione dal client al TTRP è stata mutuamente autenticata e, in tal caso, il certificato così presentato dal client. Le decisioni di controllo degli accessi basate sul certificato client (o sulla sua mancanza) possono essere trasmesse selezionando il contenuto della risposta in modo appropriato o con una risposta HTTP 403, se il certificato è ritenuto inaccettabile per il contesto dato. Si noti che i client TLS che si basano su indicazioni di errore a livello TLS per un certificato inaccettabile non riceveranno tali segnali.

Quando il valore del campo di intestazione della richiesta Client-Cert viene utilizzato per selezionare una risposta (ad esempio, il contenuto della risposta è controllato dall'accesso), la risposta DEVE essere non memorizzabile nella cache (ad esempio, inviando Cache-Control: no-store) o essere designata per il riutilizzo selettivo solo per le richieste successive con lo stesso valore del campo di intestazione Client-Cert inviando un'intestazione di risposta Vary: Client-Cert. Se un TTRP incontra una risposta con Client-Cert o Client-Cert-Chain nel campo di intestazione Vary (Sezione 12.5.5 di [HTTP]), DOVREBBE impedire all'user agent di memorizzare nella cache la risposta trasformando il valore del campo di intestazione della risposta Vary in *.

I proxy diretti e altri intermediari NON DEVONO aggiungere i campi di intestazione Client-Cert o Client-Cert-Chain alle richieste o modificare un campo di intestazione Client-Cert o Client-Cert-Chain esistente. Allo stesso modo, i client NON DEVONO utilizzare il campo di intestazione Client-Cert o Client-Cert-Chain nelle richieste.