2

My platform is this

  • OS X Yosemite 10.10.5
  • newest Indy (10.6.2.0, download 2016 March 13 - Indy10_5346.zip)
  • Lazarus 1.4.4

Concerning OpenSSL versions I have tried:

  • HomeBrew OpenSSL installed like this: "brew install openssl --universal"
  • Built-in (0.9.8) OS X supplied in /usr/lib/

I am getting error:

EIdOSSLConnecError Error connecting with SSL - EOF was observed that violates the protocol

In file Protocols/IdSSLOpenSSLHeaders.pas at line 19418

However, as I am using newest of everything - why am I be getting this error?

(Happens in call to OpenEncodedConnection)

Here's how I setup my Indy HTTP client OpenSSL handler:

FIOHandlerOpenSSL := TIdSSLIOHandlerSocketOpenSSL.Create;
FIOHandlerOpenSSL.SSLOptions.SSLVersions := [sslvSSLv23,sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2]
FIOHandlerOpenSSL.Mode := sslmClient;
FIOHandlerOpenSSL.VerifyMode := [];
FIOHandlerOpenSSL.VerifyDepth := 0;
Tom
  • 3,587
  • 9
  • 69
  • 124
  • Have a look at the answer Remy Lebeau gave here - https://forums.embarcadero.com/message.jspa?messageID=682440 – RBA Mar 14 '16 at 12:55
  • Will try (thanks!) I will also post some more code – Tom Mar 14 '16 at 13:16
  • No luck so far... I believe I use all the recommended settings now – Tom Mar 14 '16 at 14:09
  • Please edit your title to something more descriptive. You've simply regurgitated all of the tags used. Your title should describe the problem you've encountered or the question you're asking. Simply repeating the tags does neither. – Ken White Mar 14 '16 at 15:12
  • If anyone has any ideas what more to try - please suggest :) I have now tried with two different versions of OpenSSL as well. – Tom Mar 14 '16 at 15:31
  • @KenWhite I have adjusted the title now, but I am not sure how to make the title more descriptive of the problem and situation? – Tom Mar 14 '16 at 15:37
  • 1
    `FIOHandlerOpenSSL.SSLOptions.SSLVersions[sslvSSLv23,sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2]` is not valid code syntax. You need the `:=` operator. And do not specify `sslvSSLv23`: `FIOHandlerOpenSSL.SSLOptions.SSLVersions := [sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2]` – Remy Lebeau Mar 14 '16 at 15:46
  • Well, you could always try using the actual error message (if a post with that title doesn't exist already), to make it easier for future readers here to find an answer to a similar problem. – Ken White Mar 14 '16 at 16:09
  • @RemyLebeau Won't some servers require sslvSSLv23 instead of sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2? Or is that a minority? – Tom Mar 14 '16 at 17:46
  • 1
    SSLv23 is a wildcard in the OpenSSL API, it is not an actual protocol version sent over the wire. It is a mechanism that encompasses the other versions and provides version negotiation over the wire. If a server is not using SSLv23 on its end, it cannot negotiate versions with clients. The client needs to match its `SSLVersions` setup to match what the server is actually using. – Remy Lebeau Mar 14 '16 at 18:40

2 Answers2

7

EOF means the connection was closed unexpectedly, in this case during the handshake. You are enabling multiple SSLVersions, which means Indy will use SSLv23 internally to connect. That will only work if the server is using SSLv23 to listen, thus allowing the client and server to negotiate a compatible SSL/TLS version. If the server is using a specific SSL/TLS version instead of SSLv23, SSLv23 will not work on the client side. You would have to use the same specific SSL/TLS version on the client side to match.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • I will try them all separately then. Does this mean I should write code that automatically tries them all? Or is there a better way? I will run some experiments and report back – Tom Mar 14 '16 at 16:27
  • sslvTLSv1_2 alone works - I will accept answer soon - thanks! – Tom Mar 14 '16 at 17:35
  • Will it be enough to first try with FIOHandlerOpenSSL.SSLOptions.SSLVersions := [sslvSSLv23] and then if hat fails try with FIOHandlerOpenSSL.SSLOptions.SSLVersions := [sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2] – Tom Mar 14 '16 at 17:43
  • 2
    It won't really make any difference in that case. If you specify `sslvSSLv23` by itself, the IOHandler will use the SSLv23 API and enable all supported SSL/TLS versions. If you omit `sslvSSLv23` but still specify multiple SSL/TLS versions, the IOHandler will still use the SSLv23 API but enable only the versions specified. If you specify any one specific SSL/TLS version by itself, the IOHandler will use that version's specific API. So, you have to be careful how you configure `SSLVersions`, you need to know what the server is really expecting - a specific version, or version negotiation. – Remy Lebeau Mar 14 '16 at 18:47
  • This is for a crawler, so I can never know before what the website/webserver - but I can test and just options. For my given test website, just specifying sslvSSLv23 did not work, but sslvTLSv1_2 did – Tom Mar 14 '16 at 21:58
  • 6
    To support multiple servers when you don't know their configurations, you may have to try connecting several times. Connect with `[tlsv1,tlsv1_1,tlsv1_2]`, if that fails then connect with just `[tlsv1_2]`, then just `[tlsv1_1]`, and so on. – Remy Lebeau Mar 14 '16 at 22:09
  • Yes, I was informed that "As of the publication date, the version of TLS in use is version 1.2. Additionally the policy for the eClaims service is not to allow the protocol version negotiation to a lower level." – user734781 Jan 15 '17 at 00:22
  • And yes I did try all the connection options! – user734781 Jan 15 '17 at 00:29
  • Remy, Tom: I fond the problem, apparently an outdated SSL version. I appreciate your help! – user734781 Jan 15 '17 at 00:57
0

Another cause of this problem can be a timeout.

After analysis it was finally identified the problem was due to a timeout in milliseconds, rather than seconds. Once fixed, the problem resolved itself.

Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321