Falha de handshake TLS com o ambiente de Homologação de NF-e da SEFAZ-SP
By s4pcademy
Introducción
Entre 02/08/2023 y 02/09/2023, a SEFAZ-SP fez algumas alterações de segurança nos webservices de NF-e do ambiente de Homologação. Infelizmente estas mudanças não foram publicadas pela SEFAZ-SP, y desde então nossos ambientes GRC NF-e não têm se conectaron aos serviços para que possamos executar testes, impactando diversos projetos relacionados à NF-e aqui na empresa. Felizmente, o problema está restrito ao ambiente de Homologação, não tendo sido feita nenhuma modificação pela SEFAZ-SP no ambiente de Produção até este momento.
O objetivo deste blog é mostrar un análise do problema, identificação da causa raiz e solução implementada.
O Problema
Dependiendo del ambiente interno de GRC NF-e (DEV, Pre-QA ou QA), entre el 02/08/2023 y el 02/09/2023, una consulta de estado del servicio en SEFAZ-SP de Homologação começou a returnr erro:
Estado de servicio
Inicialmente achei que era uma intermitência temporária, y como o SVC está configurado en todos los ambientes, como Notas Fiscais continuaram sendo processadas em ambiente de Homologação, com exceção do service de Inutilização que não exist no SVC.
Na semana siguiente, em conversa com outras empresas, recebi a confirmação que o problema que estávamos enfrentando também estava ocorrendo em outras empresa, porém confirmei também que outras empresa não estava sofrendo nenhuma indisponibilidade de serviço. Coincidentemente – e isto acabou desviando o foco da análise – as empresas que estavam enfrentando problemas possuem seus servidores GRC NF-e fora do country. Por causa disto, minha primeira suspeita é que a SEFAZ-SP passou a block também em ambiente de Homologação as conexões origins of fora do country.
Para confirmar esto, solicitei ao time de Basis para fazer um traceroute a partir de um dos servidores afectados até o endereço homologacao.nfe.fazenda.sp.gov.br:
trazarruta
Para complicar como coisas, aparentemente o traceroute falhava ao tentar sair da rede interna. Então o que inicialmente parecia ser um problema externo de repente se tornou um problema de infraestructura interna.
Acionei o time de redes y de firewall para analizar o motivo pelo qual o tráfego não saía da rede interna. Depósito de varios días de solución de problemas y análisis, o veredito visto a través de la utilización de la puerta de enlace TCP ferramenta, disponible en Nota SAP 856597. Basicamente o teste que fiz em casa foi install o TCP Gateway em duas machine: a primeira o meu laptop de trabalho, connected à rede da empresa via VPN and acessível pelo GRC NF-e, ea second uma machine pessoal sem nenhuma restrição e firewall e accediendo a SEFAZ-SP sin bloquearlo. Apontei o Canal de Comunicação da consulta de estado de servicio no GRC NF-e para o TCP Gateway da primeira máquina, eo TCP Gateway da primeira máquina para o TCP Gateway da segunda máquina que, por fim, estava apontando para o WebService da SEFAZ. Ao disparar a comunicação pelo GRC NF-e, pude ver que o tráfego estava normal, passando por ambos os TCP Gateways, e mesmo assim não ha via uma comunicação efetiva com a SEFAZ-SP.
Uma vez descartado um possível bloqueio de firewall e também um possível bloqueio de IPs de fora do Brasil pela SEFAZ-SP em Homologação, y considerando que havia empresas em que a counicação estava ocorrendo sem problemas, ficou evidente que era agum problema específico do GRC NF -e, porém causado por algo que se ha mudado na SEFAZ-SP, uma vez que não houve nenhuma modifição implementado recientemente nos ambientes GRC NF-e.
A Causa Raíz
Ativei o trace do Canal de Comunicação a través de ferramenta XPI Inspector (ver Nota SAP 1514898). Ao rodar a interface de Consulta de Status de Serviço com o XPI Inspector ativado, o seguinte trecho do log chamou a minha atenção:
Begin IAIK Debug:
ssl_debug(7821): Starting handshake (iSaSiLk 5.104)...
ssl_debug(7821): Sending v3 client_hello message to homologacao.nfe.fazenda.sp.gov.br:443, requesting version 3.3...
ssl_debug(7821): Sending extensions: renegotiation_info (65281), signature_algorithms (13)
ssl_debug(7821): IOException while handshaking: Connection reset
ssl_debug(7821): Sending alert: Alert Fatal: handshake failure
ssl_debug(7821): Exception sending message: java.net.SocketException: errno: 32 (Broken pipe), error: Write failed (local port 29780 to address 10.38.175.201 (***********.jnj.com), remote host unknown)
ssl_debug(7821): Shutting down SSL layer...
ssl_debug(7821): Closing transport...
End IAIK Debug.
Un análisis de certificados, tanto interno como de SEFAZ-SP, não retornou nenhum erro, porém ainda assim ocorria erro de handshake TLS. Um trecho importante do log é a frase “remote host unknown”, mostrando que durante el protocolo de enlace no se puede identificar el servidor de destino. Basado en esta información, algumas pesquisas na internet me apontaram para uma possível causa do problema, que posteriormente se confirmaram como sendo efetivamente a causa raiz: Cipher Suites.
Em resumen, todas las veces que um serviço se conecta a um servidor usando um protocolo seguro, tal como o HTTPS utilizado pelos webservices das diversos SEFAZ, há uma troca de mensagens inicialmente entre o cliente – no caso, o GRC NF-e – eo servidor – no caso, un SEFAZ-SP. Essas mensagens iniciam com um handshake, através do qual cada parte envolvida na comunicação se “apresenta”. A grosso modo e para fins didáticos, eis o que deveria ocorrer:
Handshake (aperto de mãos) iniciado. Cliente: Olá, servidor. Sou o cliente e falo os seguintes idiomas de segurança: X, Y, Z. Servidor: Olá, cliente. Sou o servidor, e dos idiomas que você fala, o mais adequado para a nossa comunicação é o idioma Y. Vou abrir uma sessão neste idioma para conversarmos com privacidade. Servidor: Envio para você a chave pública de meu certificado digital, bem como toda a cadeia de certificação. Cliente verifica se o certificado é confiável. Cliente: Confio no seu certificado pois o mesmo foi emitido por uma Autoridade Certificadora de minha confiança. Cliente: Envio para você a chave pública de meu certificado digital, bem como toda a cadeia de certificação. Servidor verifica se o certificado é confiável. Servidor: Confio no seu certificado pois o mesmo foi emitido por uma Autoridade Certificadora de minha confiança. Handhsake finalizado. Servidor abre uma sessão no idioma Y, e cliente e servidor trocam mensagens nesta sessão até a mesma ser finalizada.
Básicamente, o que cito acima como “idioma de segurança” são os Cipher Suites, que são um conjunto de altoritmos criptográficos que auxiliam na segurança de uma conexão de rede. E, no log da comunicação do nosso GRC NF-e com a SEFAZ-SP, o server não conseguiu nem mesmo enviar a primeira mensagem pois o server não conseguiu selecionar entre os Cipher Suites listados para el cliente algum soportado.
Com a provável causa raiz detectada, começou o trabalho para mapear a solução.
Una solución
O primeiro passo para mapear a solução era identificar quais os Cipher Suites soportados pela SEFAZ-SP em Homologação. Para tal, utilice el excelente servicio del sitio SSLLabs.com. O trace mais recente para a SEFAZ-SP em Homologação está disponível neste link: Homologación SEFAZ-SP. Do resultado, o trecho mais importante é o abaixo:
Aqui estão enumeradas como Cipher Suites que a SEFAZ-SP Homologação support. Para fines de comparación, na imagem abaixo estão listadas as Cipher Suites compatibles con el entorno de producción de SEFAZ-SP:
Notem que a list of Produção é maior, inclusive apoyando a Cipher Suite TLS_RSA_WITH_AES_128_CBC_SHA que, de acuerdo con RFC 5246 deveria ser mandatória. Por curiosidad, pesquisei mais algumas SEFAZ y todas implementam a Cipher Suite TLS_RSA_WITH_AES_128_CBC_SHA, tanto en Homologação quanto em Produção.
Uma vez tendió una lista de Cipher Suites compatibles con la homologación SEFAZ-SP, fue apenas questão de identificar como mudanças necessárias no GRC NF-e para agregar nuevas Cipher Suites. Infelizmente esta não é uma resposta direta, e precisioni pesquisar diversas Notas SAP para poder mapear como informações necessárias. Aos interesados, sigan como principais Notas SAP estudadas:
Baseado nas informações presentes em algumas das Notas acima, os Cipher Suites soportados por padrão no PI ou PO são:
- TLS_RSA_CON_AES_256_GCM_SHA384
- TLS_RSA_CON_CAMELLIA_256_GCM_SHA384
- TLS_RSA_CON_AES_256_CBC_SHA256
- TLS_RSA_CON_CAMELLIA_256_CBC_SHA256
- TLS_RSA_CON_AES_128_GCM_SHA256
- TLS_RSA_CON_CAMELLIA_128_GCM_SHA256
- TLS_RSA_CON_AES_128_CBC_SHA256
- TLS_RSA_CON_CAMELLIA_128_CBC_SHA256
- TLS_RSA_CON_AES_256_CBC_SHA
- TLS_RSA_CON_CAMELLIA_256_CBC_SHA
- TLS_RSA_CON_AES_128_CBC_SHA
- TLS_RSA_CON_CAMELLIA_128_CBC_SHA
- SSL_RSA_CON_3DES_EDE_CBC_SHA
- SSL_RSA_CON_RC4_128_SHA
Nenhuma das Cipher Suites acima são aceitas pela SEFAZ-SP em Homologação. Siguiendo como orientações das Notas SAP 2604240 y 2616983, preparei um novo arquivo SSLContext.properties com o siguiente conteúdo:
#########################################
# SSLContext properties
# supported since ISASILK 4.4
# Location of configuration file is iaik/security/ssl/SSLContext.properties within CLASSPATH
# It can be redefined with system property iaik.security.ssl.configFile
# e.g.java -Diaik.security.ssl.configFile=file:c:/java/SSLContext.properties
#
#########################################
# allowLegacyRenegotiation is set to true otherwise we cann't communicate with unpatched peers
allowLegacyRenegotiation=true
# unsecure renegotiation is disabled for SSL server but remains allowed for client SSL
server.disableRenegotiation=true
#deactivated to avoid regressions after ISASIK5.102
chainVerifier.checkExtensions=false
#avoid issues with IIS server
extension=signature_algorithms
extension=server_name.noncritical
#default cipher suits
cipherSuite=TLS_RSA_WITH_AES_256_GCM_SHA384
cipherSuite=TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384
cipherSuite=TLS_RSA_WITH_AES_256_CBC_SHA256
cipherSuite=TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
cipherSuite=TLS_RSA_WITH_AES_128_GCM_SHA256
cipherSuite=TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256
cipherSuite=TLS_RSA_WITH_AES_128_CBC_SHA256
cipherSuite=TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
cipherSuite=TLS_RSA_WITH_AES_256_CBC_SHA
cipherSuite=TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
cipherSuite=TLS_RSA_WITH_AES_128_CBC_SHA
cipherSuite=TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
cipherSuite=SSL_RSA_WITH_3DES_EDE_CBC_SHA
cipherSuite=SSL_RSA_WITH_RC4_128_SHA
#custom cipher suites
cipherSuite=TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
cipherSuite=TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
cipherSuite=TLS_DHE_RSA_WITH_AES_256_CBC_SHA
cipherSuite=TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
cipherSuite=TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
cipherSuite=TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Lamentablemente, NetWeaver está en la versión 7.4, y como Cipher Suites que utilizan curvas elípticas solo son compatibles con SAP NetWeaver 7.5 a partir del Support Package 8, y ahora no pude agregar como Cipher Suites más modernas abaixo:
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_CON_CAMELLIA_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
Siguiendo los pasos de la Nota SAP 2569156, Basis salvo u arquivo novo SSLContext.properties no diretório /usr/sap/
Conclusión
Infelizmente do início do problema até a solução foram varias semanas tentando descobrir a causa do problema. Caso a SEFAZ-SP houvesse publicado en su portal uma nota informando a mudança de Cipher Suites, a solução teria sido muito mais rapid.
Espero que esse post auxilie outras empresas que estão passando pelo mesmo problema.
