“1408F10B:SSL routines:SSL3_GET_RECORD:wrong versi

问题:

I have a web app that makes frequent TIdHTTP calls to the Google Analytics API (around 25,000-50,000 per day). Every so often calls to the API fail with the error message in the subject line (not often - less than 1 out of 1000 times). I have never been able to find a pattern to get it to happen. And retrying the failed call usually works. So it seems entirely random.

I have the latest version of openssl (1.0.2.1 - 03/20/2015). And the latest version of Indy (source code files dated 01/07/2015).

Below is the basic source code for making these calls.

Anyone have any ideas what it could be?

Would making two simultaneous calls to the API affect things (this is taking place in a multi-threaded Web App)?

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

Update 1 update some lines of code to:

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

It works. I will monitor and see if SSL errors go away.

Solution Turns out making the changes to sslVSSLv3 fixed it. I no longer get the errors! This is somewhat surprising seeing that most all other services are adopting TLS instead.

回答1:

Problem solved by changing this:

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

To this:

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

You might want to try TLS 1.0 instead, to avoid SSLv3.

There are two things to be mindful of with Google and TLS 1.2. And some of this may have changed by now. (This discussion is very specific, and it only applies to Google servers and TLS 1.2).

First, you have to disable compression if using TLS 1.2 and ECDSA. This weird factoid showed up in a discussion on the OpenSSL mailing list under ECDHE-ECDSA Support. Here's a related support ticket it generated: Bug 3277: OpenSSL s_client doc missing option.

Second, if your are not using the ChaCha20/Poly1305 ciphers, then you have to be mindful of fallback cipher suites for TLS 1.2. I was never able to figure this one out (especially since all the ephemeral DH suites should be supported), but I know it used to be the case from testing. So be sure to include the following for fallback (this is also needed for Microsoft servers running IIS 8 (or maybe 7) and earlier):

• 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

回答2:

Problem solved by changing this:

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

To this:

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

This is surprising seeing that most services are moving to TLS instead.

回答3:

I doubt that Google still allows access to their servers using SSLv3 (see Poodle attack).

The POODLE attack (which stands for "Padding Oracle On Downgraded Legacy Encryption") is a man-in-the-middle exploit which takes advantage of Internet and security software clients' fallback to SSL 3.0.

So if your client gets a SSLv3 related error message I would contact a network expert to check if this error message can be caused by a man-in-the-middle attack.

It also could be a simple network problem, as it is not reproducible.

For a deeper diagnosis, a Wireshark recording would be helpful (for the expert, not me).