"1408F10B: SSL procedures: SSL3_GET_RECORD: invalid call number:" on Indy

Question

I have a web application that often calls TIdHTTP calls to the Google Analytics API (about 25,000-50,000 per day). Everyone so often turns to the API with an error message in the subject line (not often - less than 1 out of 1000 times). I could never find a pattern to make it happen. And retrying the failed call usually works. So it seems completely random.

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

Below is the basic source code for these calls.

Anyone have any idea what this might be?

Will making two simultaneous API calls affect things (this happens in a multi-threaded web application)?

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 keep track of SSL errors.

Solution Turns off sslVSSLv3 changes. I no longer get errors! This is somewhat surprising since most other services use TLS instead.

Answer 1

The problem is resolved by changing this:

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

For this:

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

Instead, you can try TLS 1.0 to avoid SSLv3.

There are two things to consider when using 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 and TLS 1.2 servers.)

First, you must disable compression when using TLS 1.2 and ECDSA. This strange factoid appeared in the discussion of the OpenSSL mailing list in the ECDHE-ECDSA Support section. Here is the support ticket associated with it: Error 3277: missing OpenSSL parameter s_client doc .

Secondly, if you do not use the ChaCha20 / Poly1305 ciphers, then you should remember the backup cipher suites for TLS 1.2. I could never understand this (especially because all DH ephemeral kits must be supported), but I know that this was the case with testing. Therefore, be sure to include the following for backup (this is also necessary for Microsoft servers running IIS 8 (or possibly 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

Answer 2

The problem is resolved by changing this:

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

For this:

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

Surprisingly, most services are switching to TLS.

Answer 3

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

The POODLE attack (which means "Filling Oracle On Downgraded Legacy Encryption") is a man-in-the-middle exploit that takes advantage of clients accessing the Internet and security software in SSL 3.0.

So, if your client receives an error message related to SSLv3, I would contact a network expert to check if this error message could be caused by a man in the middle attack.

It can also be a simple network problem as it does not play.

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