Certificati TLS vincolati alla porta? (1 autofirmato e 1 CA)

Is it possible, to use two different kind of certificates on the servers domain bound to ports?

Sì, è possibile utilizzare certificati diversi su porte diverse.

Do I have to run 2 different http-servers for that on the same machine?

I server Web come nginx o apache supportano lo stesso server su più porte con diversi certificati allo stesso tempo. Ma è anche possibile eseguire server diversi su porte diverse.

Al momento della stesura, i dettagli di TLS Token Binding sono stati attivamente redatti dal IETF "tokbind" Working Group e inizialmente è stato proposto in RFC8471 , "Token Binding Protocol Version 1.0." L'abstract di tale documento RFC afferma: "Il protocollo Token Binding consente alle applicazioni client / server di creare binding TLS longevi e identificabili che attraversano più sessioni e connessioni TLS." Anche se non limita in modo specifico il token a un particolare numero di porta, è chiaro che un binding TLS che si estende su più sessioni / connessioni può naturalmente applicarsi a un particolare numero di porta. In altre parole, il token è associato all'origine (vale a dire, schema-host-port triple) dell'URI in cui il servizio HTTPS è in ascolto. Questo è da aspettarsi dal momento che SOP, a.k.a. Same-Origin-Policy è uno dei più fondamentali concetti di sicurezza delle applicazioni web.

L'implementazione di questo protocollo di binding token richiede il supporto per l'estensione TLS nel software client e server. Secondo RFC8473, "Token Binding su HTTP", Sezione 4 - l'impostazione che stai descrivendo è noto come scenario "first-party" o "same-site". Ciò è in contrasto con uno scenario federato in cui un IdP (provider di identità) lega il token tra più servizi TLS.

Modifiche al livello di applicazione, ad esempio intestazioni HTTP come Include-Referred-Token-Binding-ID e Sec-Token-Binding come definite da RFC8473 non sono necessarie in questo caso, sebbene siano richieste per casi di utilizzo della federazione in cui i client potrebbero avere richieste reindirizzate ai provider di identità. Un caso di utilizzo dello stesso sito / first-party (o come ci si riferiva ad esso, "port-bound") richiede solo il supporto del layer di trasporto per l'estensione ditoken_binding TLS% i cui dati di protocollo sono dettagliati in Sezioni 2 e 3 di RFC8472, "Estensione TLS (Transport Layer Security) per la negoziazione del protocollo token vincolante" . Le unità dati del protocollo TLS ClientHello e ServerHello comunicano il supporto per l'estensione e i relativi parametri chiave.

Per ulteriori informazioni sul protocollo stesso, consultare i documenti RFC di riferimento e l'account TokitBinding GitHub . Esiste anche un mod_token_binding repository pubblicato dall'utente GitHub zmartzone che ha un modulo Apache 2.4 che implementa questa funzione. Inoltre, Google ha pubblicato ngx_token_binding su GitHub, che è un modulo NGINX che supporta l'estensione TLS. In base al documento [Intent to Implement: Token Binding] per Chromium, l'implementazione del browser è suddivisa tra BoringSSL e Chromium SSLClientSocket. Sito Web di Windows IT Pro Center documenta l'associazione token per Windows Server 2016 e Windows 10. Spero che questo aiuti!