it-swarm-es.com

"1408F10B: rutinas SSL: SSL3_GET_RECORD: llamada de número de versión incorrecta:" en Indy

Tengo una aplicación web que realiza llamadas frecuentes TIdHTTP a la API de Google Analytics (alrededor de 25,000-50,000 por día). De vez en cuando, las llamadas a la API fallan con el mensaje de error en la línea de asunto (con poca frecuencia, menos de 1 de cada 1000 veces). Nunca he podido encontrar un patrón para que suceda. Y volver a intentar la llamada fallida generalmente funciona. Entonces parece completamente al azar.

Tengo la última versión de openssl (1.0.2.1 - 20/03/2015). Y la última versión de Indy (archivos de código fuente del 01/07/2015).

A continuación se muestra el código fuente básico para realizar estas llamadas.

Alguien tiene alguna idea de lo que podría ser?

¿Hacer dos llamadas simultáneas a la API afectaría las cosas (esto está teniendo lugar en una aplicación web multiproceso)?

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=..........');

Actualización 1 actualizar algunas líneas de código para:

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

Funciona. Monitorearé y veré si los errores SSL desaparecen.

Solución Resulta que los cambios en sslVSSLv3 lo arreglaron. ¡Ya no recibo los errores! Esto es algo sorprendente, ya que la mayoría de los demás servicios están adoptando TLS en su lugar.

6
M Schenkel

Problema resuelto cambiando esto:

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

A esto:

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

Es posible que desee probar TLS 1.0 en su lugar, para evitar SSLv3.

Hay dos cosas a tener en cuenta con Google y TLS 1.2. Y algo de esto puede haber cambiado por ahora. (Esta discusión es muy específica y solo se aplica a los servidores de Google y TLS 1.2).

Primero, debe deshabilitar la compresión si usa TLS 1.2 y ECDSA. Este extraño hecho apareció en una discusión sobre la lista de correo de OpenSSL en Soporte ECDHE-ECDSA . Aquí hay un ticket de soporte relacionado que generó: Error 3277: Opción de falta de documento de OpenSSL s_client .

En segundo lugar, si no está utilizando los cifrados ChaCha20/Poly1305, debe tener en cuenta los conjuntos de cifrado alternativo para TLS 1.2. Nunca pude resolver esto (especialmente porque todas las suites DH efímeras deberían ser compatibles), pero sé que se usó para ser el caso de pruebas. Por lo tanto, asegúrese de incluir lo siguiente para el respaldo (esto también es necesario para los servidores de Microsoft que ejecutan IIS 8 (o tal vez 7) y 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 resuelto cambiando esto:

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

A esto:

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

Esto es sorprendente al ver que la mayoría de los servicios se están moviendo a TLS.

2
M Schenkel

Dudo que Google todavía permita el acceso a sus servidores usando SSLv3 (ver Poodle ataque).

El ataque POODLE (que significa "Relleno de Oracle en cifrado heredado degradado") es un exploit man-in-the-middle que aprovecha el respaldo de los clientes de software de Internet y seguridad a SSL 3.0.

Entonces, si su cliente recibe un mensaje de error relacionado con SSLv3, me pondría en contacto con un experto de la red para verificar si este mensaje de error puede ser causado por un ataque de intermediario.

También podría ser un simple problema de red, ya que no es reproducible.

Para un diagnóstico más profundo, una grabación de Wireshark sería útil (para el experto, no para mí).

0
mjn