Testando o desempenho do SSL no Nginx

Question

Estou executando o nginx 1.0.0 no CentOS 6 x86_64 com o estoque OpenSSL. Abaixo estão os resultados do benchmarking openssl.

sh# openssl speed aes-256-cbc
OpenSSL 1.0.0-fips 29 Mar 2010
built on: Sat Jun 25 04:58:15 BST 2011
options:bn(64,64) md2(int) rc4(1x,char) des(idx,cisc,16,int) aes(partial) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack 
-DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      51869.80k    54173.06k    54835.11k    54890.84k    55206.96k

O mecanismo AES-NI está ativado (estou usando o Xeon E5620 @ 2.40GHz x 2):

sh# openssl engine -t
(aesni) Intel AES-NI engine
     [ available ]

E eu também recebo o mesmo resultado usando velocidade do openssl -engine aesni aes-256-cbc

Mas quando eu uso o EVP:

sh# openssl speed -evp aes-256-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc     403447.23k   420048.47k   424418.65k   425523.88k   426726.49k

Portanto, o ganho de desempenho é significativo. Eu encontrei artigo sobre outmoded openssl assembly onde Simon testou openssl sem ASM para AES e números são:

[openssl-1.0.0d]# OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh speed aes-256-cbc
OpenSSL 1.0.0d 8 Feb 2011
options:bn(64,64) rc4(1x,char) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H 
-m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DWHIRLPOOL_ASM
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc     107854.91k   111229.18k   112361.56k   112501.08k   112536.23k

Ainda não consegui criar o mecanismo aesni no 1.0.0d para ver a diferença. E o que usa o IPP da Intel requer habilidades para corrigir o openssl.

Então, minhas perguntas são:

Qual é a maneira correta de testar se o nginx está usando o EVP para o AES-256 ou vale a pena compilar o nginx contra o openssl sem o asm para o AES?

Sei que cada nova conexão exigirá a descriptografia RSA para trocar a chave secreta, portanto, o gargalo que deve ser levado em consideração, mas quanto ssl_session_cache compartilhada afeta a reutilização da sessão SSL e ferramentas como ab, siege ou similar simulam tráfego real de tráfego ssl?

    

Answer 1

O que eu investiguei pode ser útil para você. Há um artigo da Intel: link

Eles usam o apache para testar e disseram que não ajustaram nenhuma configuração do apache. Eu acho que para o Nginx é o mesmo.

Eu uso o gdb para rastrear e aqui está o meu resultado:

(gdb) bt
#0  0x00000000004dcd50 in aesni_init_key ()
#1  0x00000000004d8dff in EVP_CipherInit_ex ()
#2  0x0000000000494c5a in ssl3_send_newsession_ticket ()
#3  0x00000000004997e8 in ssl3_accept ()
#4  0x00000000004281af in ngx_ssl_handshake (c=0x7ffff7fad1c0) at src/event/ngx_event_openssl.c:996
#5  0x0000000000428571 in ngx_ssl_handshake_handler (ev=0x8c3770) at src/event/ngx_event_openssl.c:1144
#6  0x0000000000424467 in ngx_epoll_process_events (cycle=0x89b9d0, timer=<value optimized out>, flags=<value optimized out>)
    at src/event/modules/ngx_epoll_module.c:691
#7  0x000000000041bd43 in ngx_process_events_and_timers (cycle=0x89b9d0) at src/event/ngx_event.c:248
#8  0x0000000000421de8 in ngx_single_process_cycle (cycle=0x89b9d0) at src/os/unix/ngx_process_cycle.c:315
#9  0x000000000040519c in main (argc=<value optimized out>, argv=<value optimized out>) at src/core/nginx.c:404

EVP_CipherInit_ex usa ctx- > cifra > init (ctx, chave, iv, enc) para iniciar aesni_init_key (). Os detalhes definidos em openssl / crypto / evp / e_aes.c

 #define BLOCK_CIPHER_generic(nid,keylen,blocksize,ivlen,nmode,mode,MODE,flags) \
static const EVP_CIPHER aesni_##keylen##_##mode = { \
    nid##_##keylen##_##nmode,blocksize,keylen/8,ivlen, \
    flags|EVP_CIPH_##MODE##_MODE,   \
    aesni_init_key,         \
    aesni_##mode##_cipher,      \
    NULL,               \
    sizeof(EVP_AES_KEY),        \
    NULL,NULL,NULL,NULL }; \
static const EVP_CIPHER aes_##keylen##_##mode = { \
    nid##_##keylen##_##nmode,blocksize, \
    keylen/8,ivlen, \
    flags|EVP_CIPH_##MODE##_MODE,   \
    aes_init_key,           \
    aes_##mode##_cipher,        \
    NULL,               \
    sizeof(EVP_AES_KEY),        \
    NULL,NULL,NULL,NULL }; \
const EVP_CIPHER *EVP_aes_##keylen##_##mode(void) \
{ return AESNI_CAPABLE?&aesni_##keylen##_##mode:&aes_##keylen##_##mode; }

AESNI_CAPABLE determina qual função habilita, aes_init_key ou aes_init_key. Isso é concluído na compilação. Mais detalhes, você pode encontrar aqui .

Se sua interface openssl evp habilitou o AESNI, o Nginx também usa isso. Então, para o seu caso, acho que o nginx está usando o AESNI por padrão.

    

Answer 2

Eu não tenho nenhuma resposta para sua pergunta EVP, mas no que diz respeito ao cache de sessão SSL, a resposta é "isso ajuda consideravelmente". Recentemente, eu escrevi um patch para o nginx para implementar o cache de sessão SSL em clusters usando o memcached, e descobri que há um benefício considerável para o cache de sessão SSL - você está salvando várias viagens de ida e volta (que é o mais importante do perspectiva do usuário, porque eles obtêm suas páginas mais rapidamente), bem como uma melhora moderada no uso da CPU (embora seja raro que os servidores modernos estejam limitados à CPU, portanto, normalmente não é um problema).

É fácil testar se você está usando o cache de sessão SSL:

gnutls-cli -V -r HOSTNAME |grep 'Session ID'

Mas fazer testes para ver quanto efeito tem sobre o "tráfego real" é muito difícil, simplesmente porque o "tráfego real" é muito complexo. Dado o baixo risco da alteração da configuração, recomendo coletar algumas boas estatísticas (com base no que você deseja melhorar), depois ativá-las na produção e medir novamente para ver se suas métricas melhoram.