Fiz um levantamento sem maiores pretensões, diga-se logo, e sem o rigor necessário, o rigor científico requerido para este tipo de levantamento. Mas apenas é ilustrativo de certas tendências na adoção de algoritmos criptográficos para sessões SSL. Se observarmos as maiores empresas de tecnologia da informação, sites de redes sociais e bancos, poderemos, de imediato, perceber que a criptografia de curvas elípticas (ECC) é ainda bastante minoritária. E, por outro lado, o RSA como solução é fortemente dominante.

A tabela abaixo apresenta uma singela amostragem de uso de soluções de algoritmos usados para criptografar uma sessão web e o algoritmo usado para troca de chaves1. O levantamento foi feito basicamente de empresas de Tecnologia da Informação (IBM, Google, Microsoft, HP, etc.), Bancos (Chase, Santander, etc.) e redes sociais (Facebook, Twitter, etc.). A abordagem do OpenSSL ajuda bastante a captura das informações básicas e detalhes de uma sessão SSL, usando o comando openssl s_client -connect URL:PORTA. Por exemplo aqui o site da empresa HP usando um certificado digital Verisign:

[wc_box color="inverse" text_align="left"]

$ openssl s_client -connect www.hp.com:443 CONNECTED(00000003) depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority verify return:1 depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify return:1 depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)10, CN = VeriSign Class 3 Secure Server CA - G3 verify return:1 depth=0 C = US, ST = CALIFORNIA, L = Palo Alto, O = Hewlett-Packard, OU = Operations, CN = www.hp.com verify return:1 [...]

[/wc_box]

Eliminamos aqui boa parte das informações ecoadas na tela. Ali pode-se capturar como dissemos o certificado do servidor propriamente dito, e até mesmo o "tíquete" da sessão TLS... Aqui vemos informações como o algoritmo suportado (RC4 com SHA), tamanho de chave, etc.

[wc_box color="inverse" text_align="left"]

SSL handshake has read 4932 bytes and written 563 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: 9CEA3B3DDE8014D70A31D2D77F1D6E409E6F5A84CF18A7B4A65CE2909EA8A79D Session-ID-ctx: Master-Key: 858E070479836EC29D9E9CF9059C1768FBC10DBE919A5B4194941ECA4BB9D9B233732E6508EF7CCB1848ACF713DB97E

[/wc_box]

Este recurso do OpenSSL permite uma captura automatizada da sessão criptografada, que nossos browsers geralmente apresentam, ainda que em parte e sem grande detalhes técnicos, de modo gráfico. Por exemplo, o dumping do certificado digital do Google, um dos poucos a usarem ECC em seu site web, permite-nos observar o OID da curva utilizada como comentamos em outro artigo. Vejamos uma parte da estrutura em ASN.1 do certificado Google; aqui aparecem dois OIDs do (1) ecPublicKey e o (2) prime256v1:

[wc_box color="inverse" text_align="left"]

249 89: SEQUENCE { 251 19: SEQUENCE { 253 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 262 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) : } 272 66: BIT STRING : 04 02 B6 50 59 6D 64 3E 1E A4 D1 CB B2 12 67 69 : FE DE AF FC 6C 2A 0A 58 75 14 2D 01 7E 35 8B 7B : DF 86 7D BF 13 A2 54 16 44 A5 CF 88 EE C2 2C 93 : F8 E6 AD FD 82 4E 3D E2 14 E4 DF 8D D7 03 80 EA : 49 : }

[/wc_box]

O OID "1 2 840 10045 3 1 7" identifica uma curva de 256-bit da família prime padronizada pelo "Accredited Standards Committee X9" ANSI X92, designada pelo OpenSSL como sendo prime256v1: X9.62/SECG curve over a 256 bit prime field. Note-se que, portanto, o Google não usa aqui uma curva NIST... Abaixo a representação do certificado Google no browser chrome.

Apresentação do certificado Google...

Apresentação do certificado Google...

O RFC 44923 introduz uma série de algoritmos para troca ou agreements de chaves. A tabela abaixo mostra a série de algoritmos de troca de chaves e suas verientes segundo o RFC citado:

[wc_box color="inverse" text_align="left"]

Algoritmos de troca de chaves Descrição
ECDH_ECDSA ECDH fixo com certificados assinados ECDSA.
ECDHE_ECDSA ECDH efêmero com assinaturas ECDSA.
ECDH_RSA ECDH fixo certificados assinados RSA.
ECDHE_RSA ECDH efêmero com assinaturas RSA.
ECDH_anon ECDH anônimo, sem assinaturas.

[/wc_box]

Eles podem usar, por exemplo, um certificado de servidor RSA com chaves de longa duração, mas durante o TLS/SSL handshake em vez de enviar send over numa chave pública transiente (por isso ECDH + ephemeral) para fazer a negociação de chaves. Por isso a autenticidade de longo termo é confirmada através do certificado do servidor RSA, todavia as chaves transientes/efêmeras são derivadas atras de chaves ECC, que por sua vez irão gerar a chave simétrica4.

[wc_tabgroup][wc_tab title="(1) Cripto"] [wc_skillbar title="AES_CBC_256" percentage="45" color="#6adcfa"] [wc_skillbar title="RC4_128" percentage="36" color="#d3e8da"] [wc_skillbar title="AES_128_GCM" percentage="13" color="#f2ccbb"] [wc_skillbar title="3DES_EDE_CBC" percentage="1" color="#fdff9b"] [/wc_tab][wc_tab title="(2) Troca de chaves"] [wc_skillbar title="RSA" percentage="81" color="#6adcfa"] [wc_skillbar title="DHE_RSA" percentage="4.5" color="#d3e8da"] [wc_skillbar title="ECDHE_ECDSA" percentage="4.5" color="#f2ccbb"] [wc_skillbar title="ECDHE_RSA" percentage="9" color="#fdff9b"] [/wc_tab][/wc_tabgroup]

 
Revisão v. 1.30
 
  1. Ver: "Comparison of TLS implementations". []
  2. "The Accredited Standards Committee X9, Inc. or more simply X9, is the leader in developing technical financial industry standards. Our mission is to develop, establish, maintain and promote standards for the Financial Services Industry to facilitate delivery of financial services and products": http://x9.org. []
  3. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)". []
  4. "The ECDH_RSA mechanism requires a server to acquire an ECC certificate, but the certificate issuer can still use an existing RSA key for signing. This eliminates the need to update the keys of trusted certification authorities accepted by TLS clients. The ECDH_ECDSA mechanism requires ECC keys for the server as well as the certification authority and is best suited for constrained devices unable to support RSA", RFC 4492, p.4. []