Ir para conteúdo
  • Cadastre-se

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Comprar

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Comprar

matheusd

Tempo de Inicialização da unit ssl_openssl_lib.pas

Recommended Posts

Olá Pessoal,

Estou rastreando os pontos mais críticos no tempo de inicialização do sistema da empresa onde trabalho. Um dos pontos que achei, foi na unit ssl_openssl_lib.pas, especificamente na inicialização da biblioteca (função initSSLInterface), mais especificamente na chamada da função randScreen().

Nos meus testes, a chamada pra essa única função atrasa a inicialização do sistema em 1 segundo.

Segundo os links abaixo[1,2], essa chamada é legada e não é mais necessária.

Proponho as seguintes alternativas:

1- Eliminar completamente essa chamada
2- Criar um define para selecionar se essa função deve ser executada assim que a biblioteca é inicializada ou não.

Posso mandar um patch para essa alteração caso seja aceita.

Alguém tem algum comentário? A favor? Contra?

Referências:

[1] http://security.stackexchange.com/questions/7718/openssl-rand-poll-good-enough

[2] https://curl.haxx.se/mail/lib-2004-06/0133.html

Compartilhar este post


Link para o post
Compartilhar em outros sites

Boa pegada... isso também sempre me incomodou...

O problema é que essa Unit é do Projeto Synapse... e precisamos avaliar o efeito prático de remover essa linha...

Compartilhar este post


Link para o post
Compartilhar em outros sites

Pelo que li... Rand_Screen é obsoleto e poderíamos substituí-lo por outro método correto?

É essa a sua idéia?

Acho que removê-la simplesmente pode diminuir a segurança do OpenSSL 

Compartilhar este post


Link para o post
Compartilhar em outros sites

@Daniel Simoes

Pedi ajuda ao parceiro nosso e acredito que podemos contribuir para solução descrita no tópico.

Chegamos num consenso que o parâmetro não deve ser removido e sim substituído por outro mais eficiente.

Ainda estamos testando mas o mais promissor até agora foi:

Citar

RAND_bytes( &c, 1 ); 

Vamos continuar nos testes e assim que possível poderemos propor um patch para ajudar na solução da lentidão descrita no método randScreen().

  • Curtir 1

Compartilhar este post


Link para o post
Compartilhar em outros sites

Segundo [1], não é necessário fazer nenhuma inicialização mais. A própria biblioteca do openssl executa a inicialização no primeiro uso de alguma das funções RAND_XXXX.

Ou seja, podemos remover essa inicialização do initOpenSSL porque na hora que qualquer função que precisar de números aleatórios for chamada, a openssl faz a inicialização automaticamente. E aí quem não usa em nenhum lugar, não precisa inicializar desnecessariamente.

E já emendando, embora exista a rand_Screen, em nenhum lugar do código do acbr ou da Synapse é usado alguma outra função da família rand_XXXX. A não ser que esteja sendo chamada implicitamente em algum lugar de dentro da biblioteca do openssl (a função rand_bytes não foi nem importada na ssl_openssl_lib.pas.

[1] https://wiki.openssl.org/index.php/Random_Numbers#Initialization

Compartilhar este post


Link para o post
Compartilhar em outros sites

@matheusd

Ainda estamos testando e não definimos a melhor solução, mas acredito que podemos juntos encontrar uma solução seja tecnicamente aceitável e compatível com a versão atual da lib.

Estamos até verificando a possibilidade de atualizar a reader da lib para uma versão mais nova.

Compartilhar este post


Link para o post
Compartilhar em outros sites

@Waldir Paim

O header da synapse continua do mesmo jeito, com o RandScreen() (já conferi lá).

Eu acho que o mais simples e que mantém retrocompatibilidade é a abaixo. Dessa forma, quem não definir a diretiva de compilação OPENSSL_NO_RAND_INIT, continua com o comportamento padrão (inicializar chamando o randPoll que é mais eficiente que o randScreen). Quem quiser definir e entender os riscos (na minha opinião, se estiver usando uma versão atualizada da openssl, nenhum) pode definir essa diretiva na compilação do programa para uma inicialização mais rápida.

 Fontes/Terceiros/synalist/ssl_openssl_lib.pas | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Fontes/Terceiros/synalist/ssl_openssl_lib.pas b/Fontes/Terceiros/synalist/ssl_openssl_lib.pas
index 1f6647d..d8e58b6 100644
--- a/Fontes/Terceiros/synalist/ssl_openssl_lib.pas
+++ b/Fontes/Terceiros/synalist/ssl_openssl_lib.pas
@@ -1997,8 +1997,10 @@ begin
           _SslLoadErrorStrings;
         if assigned(_OPENSSLaddallalgorithms) then
           _OPENSSLaddallalgorithms;
-        if assigned(_RandScreen) then
-          _RandScreen;
+        {$IFNDEF OPENSSL_NO_RAND_INIT}
+        if assigned(_randPoll) then
+          _randPoll();
+        {$ENDIF}
         if assigned(_CRYPTOnumlocks) and assigned(_CRYPTOsetlockingcallback) then
           InitLocks;
 {$ENDIF}

 

Compartilhar este post


Link para o post
Compartilhar em outros sites

@matheusd

Fizemos alguns testes e estudamos o código fonte da  RandScreen.

Ela é realmente lenta pois gera uma imagem do desktop e disso ela gera a randomização.

_randPoll

RandPoll,  realmente é muito mais eficiente e segundo respostas no forum oficial da lib é o mais indicado para essa situação.

Fizemos uma implementação que ficou bem próxima da que você propôs e nos nossos testes mostraram que o processo ficou bem mais rápido.

@Daniel Simoes

Aproveitamos o embalo e fizemos também a correção na finalização da XMLSec que possuía um pequeno bug, pois finalizava alguns métodos fora da ordem.

Se puder analisar ambas units, se precisar de mais algum ajuste estamos a disposição para qualquer duvida.

Segue anexo:

 

ACBrDFeOpenSSL.pas

ssl_openssl_lib.pas

Compartilhar este post


Link para o post
Compartilhar em outros sites

@Daniel Simoes

Essa alteração é para finalizar corretamente a biblioteca XMLSec. O patch segue a mesma sequencia de chamada de funções do exemplo oficial, no link: https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c.

 
Conforme exemplo, as primeiras funções chamadas são xmlSecDSigCtxDestroy() e xmlFreeDoc():
 
 
e a send_file() por sua vez é chamada aqui:
 
 
após ela, são chamadas xmlSecCryptoShutdown(), xmlSecCryptoAppShutdown(), xmlSecShutdown(), xsltCleanupGlobals() e xmlCleanupParser():
 
 
 
 
 
 
Apensar do exemplo ter a chamada a função xsltFreeSecurityPrefs(), preferi não declará-la no patch pois não tenho certeza se o ACBr instancia alguma variável do tipo xsltSecurityPrefsPtr. De qualquer forma, a linha que contém a chamada a essa função, é:
 

 

Compartilhar este post


Link para o post
Compartilhar em outros sites

Não compreendi... o método DestroyCtx, não tem a finalidade de descarregar a biblioteca XMLSec... e sim apenas, destruir o Objeto "xmlSecDSigCtxPtr" já utilizado...

Não acho que seja necessário ou correto, chamar "ShutDownXmlSec", dentro dele... Vou subir sem essa modificação...

Obrigado pelo estudo e pelas alterações...

Compartilhar este post


Link para o post
Compartilhar em outros sites

Pessoal, não sei se alguém pode achar relevante mas escrevi um pequeno artigo sobre o processo que usei pra descobrir onde estavam as demoras de inicialização do meu sistema (inclusive esse do openssl). Talvez seja útil pra mais alguém:

http://matheusd.com/post/Profile_Delphi_Startup/

Código complementar: https://github.com/matheusd/DelphiProfileInit

Até mais.

  • Curtir 1

Compartilhar este post


Link para o post
Compartilhar em outros sites

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora

  • Atenção !!  Este tópico está sem resposta há mais de 120 dias.

×