Projeto para testar o uso do recurso TLS Session Resumption e medir o desempenho com e sem o recurso ativado
No arquivo index.js, edite as variáveis host, port, endpoint, reuseSession e counter para atender ao seu cenário de teste.
- host: hostname do servidor onde será aberta a conexão
- port: porta ssl/tls (geralmente 443)
- endpoint: endpoint para realização de um GET e medição da performance. Recomendado que seja um conteúdo estático, como uma página HTML pura ou uma imagem.
- reuseSession: indica se o programa deve reutilizar a sessão (TLS Session Resumption) ou não
- counter: número de conexões que serão abertas contra o host informado
Caso seu host esteja configurado para obrigar o mTLS, copie chave pública e privada de conexão para o diretório raiz deste projeto, nomeando os arquivos conforme abaixo.
- Chave pública: client-cert.pem
- Chave privada: client-key.pem
node index.js
TLS Session Resumption é um recurso que, uma vez configurado no servidor que está recebendo a conexão, possibilita ao cliente a reutilização da sessão em conexões posteriores, diminuindo do tempo do TLS Handshake no estabelecimento da conexão.
Essa diminuição do tempo dá-se devido a possibilidade de "pular" algumas etapas do handshake quando a sessão é reaproveitada. Essas etapas que "puladas" podem ser notadas nos prints abaixo extraídos da monitoria da conexão via wireshark.
As linhas ou itens riscados são as etapas que não existem em uma conexão com a utilização do TLS Session Resumption
Foi configurado um servidor Nginx para receber as conexões e 3 configurações distintas foram realizadas e em cada uma delas o programa foi executado para realização da medição da performance. Nos logs do Nginx, foi adicionada a variável $ssl_session_reused, que indica quando uma conexão é derivada de uma sessão existente ou não.
No Nginx foi configurado os valores abaixo para desativação completa do TLS Session Resumption.
ssl_session_tickets off;
ssl_session_cache off;
No Nginx foi configurado os valores abaixo para desativação completa do TLS Session Resumption.
ssl_session_tickets off;
ssl_session_cache shared:SSL:10m;
No Nginx foi configurado os valores abaixo para desativação completa do TLS Session Resumption.
ssl_session_tickets on;
ssl_session_cache off;
Para cada um dos cenários abaixo foram realizadas 100 conexões.
The connection time average is: 528.18
The request time average is: 166.31
The connection time average is: 345.68 (35% mais rápido)
The request time average is: 166.86
The connection time average is: 338.39 (36% mais rápido)
The request time average is: 160.02
O ganho de desempenho dá-se apenas no processo de abertura de conexão, não no tempo total da requisição. No exemplo acima, como o maior tempo gasto é o tempo de conexão, há um ganho médio de 186 milisegundos por conexão.
Esse ganho é constante nas conexões, portanto em um cenário onde uma API demore 2.5 segundos para a resposta total, sendo 500 milisegundos para o estabelecimento da conexão e 2 segundos para obtenção e retorno dos dados em sua infraestrutura interna, com o TLS Session Resumption ativado, essa API retornaria em aprox. 2.3 segundos, reduzindo o tempo de estabelecimento de conexão para 300 milisegundos e mantendo os 2 segundos para obtenção e retorno dos dados em sua infraestrutura interna.
É preciso enfatizar que a utilização da reutilização da sessão é uma liberdade do cliente (receptor), ou seja, a habilitação do lado servidor (transmissor) não obriga o cliente a utilizar o recurso TLS Session Resumption.
Foi notado que a reutilização da sessão não é um recurso nativo do lado cliente em NodeJS, e talvez também não o seja em outras linguagens, portanto a tendência é que a ativação do recurso por parte dos servidores (transmissoras) causará impacto ínfimo nas métricas atuais do ecossistema.
Do ponto de vista de segurança, a ativação do recurso não traz novos riscos, pois o TLS Session Resumption não pula as etapas do mTLS, ou seja, mesmo nas conexões reutilizadas, a utilização das chaves públicas e privadas continua necessária para realização das chamadas. Dessa forma, no caso de uma eventual perda/interceptação das sessões (session id ou session ticket), o interceptador não conseguiria tirar proveito da sessão uma vez que ele não possui as chaves públicas e privadas para realização do mTLS.
Quanto ao consumo de CPU, é notório que há redução de utilização da CPU com a diminuição das etapas de handshake, no entanto, é necessário considerar também que no caso da utilização do TLS Session Resumption com Session ID em ambientes clusterizados, será necessário adicionar componentes que podem utilizar mais CPU e latência (ex: banco de dados para armazenar as sessões e compartilhar entre os nós do cluster). No caso do TLS Session Resumption com Session Ticket, há a criptografia e decriptografia do ticket, o que pode tornar a diminuição do uso de CPU não tão vantajosa se comparado com as etapas de handshake.