ti-enxame.com

"1408F10B: Rotinas SSL: SSL3_GET_RECORD: chamada errada do número da versão:" em Indy

Eu tenho um aplicativo da web que faz chamadas freqüentes TIdHTTP para a API do Google Analytics (em torno de 25.000 a 50.000 por dia). De vez em quando, as chamadas para a API falham com a mensagem de erro na linha de assunto (não frequentemente - menos de 1 em 1.000 vezes). Eu nunca fui capaz de encontrar um padrão para que isso aconteça. E tentar novamente a chamada com falha geralmente funciona. Então parece inteiramente aleatório.

Eu tenho a última versão do openssl (1.0.2.1 - 20/03/2015). E a última versão do Indy (arquivos de código fonte datados de 01/07/2015).

Abaixo está o código-fonte básico para fazer essas chamadas.

Alguém tem alguma idéia do que poderia ser? 

Será que duas chamadas simultâneas à API afetariam as coisas (isso está ocorrendo em um Web App de vários segmentos)?

IdSSLIOHandlerSocket1 := TIdSSLIOHandlerSocketOpenSSL.create(nil);
IdSSLIOHandlerSocket1.PassThrough := True;
IdHTTP := TIdHTTP.create(nil);
IdHTTP.reusesocket := rsTrue;
IdSSLIOHandlerSocket1.reusesocket := rsTrue;
idhttp.handleredirects := True;
with IdSSLIOHandlerSocket1 do begin
  SSLOptions.Method := sslvTLSv1_2;
  SSLOptions.SSLVersions := [sslvTLSv1_2];
  SSLOptions.VerifyMode := [];
  SSLOptions.VerifyDepth := 2;
end;
with IdHTTP do begin
  IOHandler := IdSSLIOHandlerSocket1;
  ProxyParams.BasicAuthentication := False;
  Request.UserAgent := 'EmbeddedAnalytics API Interface';
  Request.ContentType := 'text/html';
  request.connection := 'close';
  Request.Accept := 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8';
  Request.BasicAuthentication := False;
  Request.UserAgent := 'Mozilla/3.0 (compatible; Indy Library)';
  HTTPOptions := [hoForceEncodeParams];
  Request.AcceptEncoding := 'gzip,deflate';
  Request.CustomHeaders.Add('Accept-Language: en-us,en;q=0.5');
  idhttp.Request.CustomHeaders.Add('Authorization: Bearer '+FToken);
end;
idhttp.get(':https://www.googleapis.com/analytics/v3/data/realtime?ids=..........');

Atualização 1 atualize algumas linhas de código para:

SSLOptions.Method := sslvSSLv3;
SSLOptions.SSLVersions := [sslvSSLv3];

Funciona. Vou monitorar e ver se os erros de SSL desaparecem.

Solução Acontece que as mudanças para o sslVSSLv3 o corrigiram. Eu já não recebo os erros! Isso é um pouco surpreendente, já que a maioria dos outros serviços está adotando o TLS.

6
M Schenkel

Problema resolvido alterando isso:

SSLOptions.Method := sslvTLSv1_2;
SSLOptions.SSLVersions := [sslvTLSv1_2];

Para isso:

SSLOptions.Method := sslvSSLv3;
SSLOptions.SSLVersions := [sslvSSLv3];

Você pode querer tentar o TLS 1.0, para evitar o SSLv3.

Há duas coisas a serem lembradas com o Google e o TLS 1.2. E parte disso pode ter mudado até agora. (Esta discussão é muito específica e só se aplica aos servidores do Google e ao TLS 1.2). 

Primeiro, você precisa desativar a compactação se estiver usando o TLS 1.2 e o ECDSA. Este estranho fatoide apareceu em uma discussão sobre a lista de discussão do OpenSSL sob ECDHE-ECDSA Support . Aqui está um ticket de suporte relacionado que ele gerou: Bug 3277: Opção do OpenSSL s_client doc missing .

Em segundo lugar, se você não estiver usando as cifras ChaCha20/Poly1305, deve estar ciente dos conjuntos de cifras de fallback para o TLS 1.2. Eu nunca fui capaz de descobrir isso (especialmente desde que todas as efêmeras suítes DH devem ser suportadas), mas eu sei disso usado para ser o caso do teste. Portanto, certifique-se de incluir o seguinte para fallback (isso também é necessário para servidores Microsoft executando IIS 8 (ou talvez 7) e anteriores):

  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
5
jww

Problema resolvido alterando isso:

SSLOptions.Method := sslvTLSv1_2;
SSLOptions.SSLVersions := [sslvTLSv1_2];

Para isso:

SSLOptions.Method := sslvSSLv3;
SSLOptions.SSLVersions := [sslvSSLv3];

Isso é surpreendente, já que a maioria dos serviços está migrando para o TLS.

2
M Schenkel

Duvido que o Google ainda permita o acesso a seus servidores usando o SSLv3 (veja Poodle attack).

O ataque POODLE (que significa "Enchimento de Oracle em desatualizado Legacy Encryption") é uma exploração man-in-the-middle que leva Vantagem de clientes de software de segurança e de Internet para SSL 3.0.

Portanto, se o seu cliente receber uma mensagem de erro relacionada ao SSLv3, entrarei em contato com um especialista da rede para verificar se essa mensagem de erro pode ser causada por um ataque man-in-the-middle.

Também pode ser um problema de rede simples, pois não é reproduzível.

Para um diagnóstico mais profundo, uma gravação do Wireshark seria útil (para o especialista, não para mim).

0
mjn