Tempo de Inicialização da unit ssl_openssl_lib.pas

[matheusd]

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

[Daniel Simoes]

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...

[Daniel Simoes]

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 

[Waldir Paim]

@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().

[matheusd]

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

[Waldir Paim]

@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.

[matheusd]

@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}

 

[Waldir Paim]

@matheusd

Fizemos uma pergunta no forum oficial da openssl e estamos aguardando a resposta deles.

Assim que recebermos uma resposta lá conseguimos colaborar de forma segura.

[Waldir Paim]

@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

[matheusd]

@Waldir Paim

Fiz o teste aqui do randPoll() e está ok!

[Daniel Simoes]

Waldir,

Não compreendi a modificação em "procedure TDFeOpenSSL.DestroyCtx;"

 

 

[Waldir Paim]

@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():

 

https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c#L204

 

https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c#L208

 

e a send_file() por sua vez é chamada aqui:

 

https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c#L113

 

após ela, são chamadas xmlSecCryptoShutdown(), xmlSecCryptoAppShutdown(), xmlSecShutdown(), xsltCleanupGlobals() e xmlCleanupParser():

 

https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c#L118

 

https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c#L121

 

https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c#L124

 

https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c#L129

 

https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c#L131

 

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, é:

 

https://github.com/lsh123/xmlsec/blob/master/examples/sign1.c#L128

 

[Daniel Simoes]

Mas o DestroyCTX, é chamado várias vezes, durante a operação do DFeOpenSSL... e não apenas na sua finalização...

[Waldir Paim]

@Daniel Simoes

A finalização proposta está correta e o funcionamento também.

A implementação existente gerava um leak interno na lib pois não obedece a ordem de finalização.

[Daniel Simoes]

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...

[Waldir Paim]

Sem problemas, estamos ai para ajudar no que for preciso.

[Daniel Simoes]

Já no SVN... obrigado a todos...

 

PS: Estou implementando o suporte a TLS 1.2 nessa Unit...  devo concluir em breve...

[matheusd]

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.