A Middlebox for verification of encrypted FaaS traffic

TLS brought significant improvements to the security of network communications, but it hinders the ability of middleboxes to analyze and verify encrypted traffic. Many works and technologies have been developed to allow middleboxes to access part or all of the plaintext for traffic inspection or other purposes, such as CDN offloading. This thesis focuses on the analysis and verification of encrypted traffic in the context of FaaS function calls. Two functionally equivalent middlebox implementations are developed, resolving the problem of plaintext access using two different and already existing solutions: the Transport Layer Middlebox Security Protocol (TLMSP) and the Delegated Credentials (DC) extension of the TLS protocol. An original component is introduced, which from the retrieved plaintext is able to authenticate the client using the OpenID Connect standard, and verify the function calls with a set of checks using a configuration specific to the deployed FaaS application. These checks validate that the request method and URL correspond to an existing function and that the body has the correct format, that the function call is allowed within the context of the previous calls, and that the request includes a random code provided by the middlebox in the previous response. If the authentication or any of these checks fail, the request is not sent to the server. A full test system is developed in the form of a client-middlebox-server architecture, with a deployment of the Hello, Retail! sample project on the OpenFaaS server, to evaluate the latency introduced by the two middlebox implementations, differentiating between the impact of the validation functions and that of the TLMSP or DC proxy-like executables. The results show that the TLMSP middlebox has an additional average latency of 599.72ms, subdivided in 199.78ms for the TLMSP proxy and 399.94ms for the validation functions, orders of magnitude higher than the baseline of around 20ms, due to the prototype nature of the TLMSP executables and the inefficient startup of the validation program. The DC middlebox has an additional average latency of 5.01ms, with 2.9ms for the DC proxy and 2.11ms for the validation functions, which is a much more acceptable overhead, due to the more efficient calling of the validation functions and the usage of a standard TLS proxy supporting the DC extension. This solution is suitable for a real-world scenario.

TLS ha portato importanti miglioramenti alla sicurezza delle comunicazioni di rete, ma ostacola la capacità delle middlebox di analizzare e verificare il traffico crittografato. Vari lavori e tecnologie sono stati sviluppati per consentire alle middlebox di accedere al plaintext o a parte di esso per ispezionare il traffico o per altri scopi, come l'offload su CDN. Questa tesi si concentra sull'analisi e la verifica del traffico crittografato nel contesto delle chiamate di funzioni FaaS. Sono sviluppate due implementazioni di middlebox funzionalmente equivalenti, risolvendo il problema dell'accesso al plaintext utilizzando due soluzioni diverse e già esistenti: il Transport Layer Middlebox Security Protocol (TLMSP) e le Delegated Credentials (DC), estensione del protocollo TLS. Viene introdotto un componente originale, che dal plaintext estratto è in grado di autenticare il client utilizzando lo standard OpenID Connect e di verificare le chiamate a funzione con un insieme di controlli che utilizzano una configurazione specifica per l'applicazione FaaS implementata. Questi controlli validano che il metodo della richiesta e l'URL corrispondano a una funzione esistente e che il corpo abbia il formato corretto, che la chiamata a funzione sia consentita con il contesto delle chiamate precedenti, e che la richiesta includa un codice casuale fornito dalla middlebox nella risposta precedente. Se l'autenticazione o uno di questi controlli falliscono, la richiesta non è inviata al server. Un sistema di test completo è sviluppato con un'architettura client-middlebox-server, con un deployment del progetto di esempio Hello, Retail! sul server OpenFaaS, per valutare la latenza introdotta dalle due implementazioni delle middlebox, differenziando tra l'impatto delle funzioni di validazione e quello dei programmi di proxy TLMSP o DC. I risultati mostrano che la middlebox TLMSP ha una latenza media aggiuntiva di 599.72ms, suddivisa in 199.78ms per il proxy TLMSP e 399.94ms per le funzioni di validazione, di ordini di grandezza più alti rispetto alla base di circa 20ms, a causa della natura prototipale degli eseguibili TLMSP e dell'avvio inefficiente del programma di validazione. La middlebox DC ha una latenza media aggiuntiva di 5.01ms, con 2.9ms per il proxy DC e 2.11ms per le funzioni di validazione, un overhead molto più accettabile grazie alla chiamata più efficiente delle funzioni di validazione e all'uso di un proxy TLS standard che supporta l'estensione DC. Questa soluzione è adatta per scenari nel mondo reale.