0

I am recompiling a Delphi XE3 application in Delphi XE8.

The application sends messages to Amazon SES (tried Ireland and North Virginia) using a TIdSMTP object.

These are some of the attributes set in the TIdSMTP component (UPDATE: more fields added):

  • IOHandler is IdSSLIOHandlerSocketOpenSSL with the following subfields: Destination is email-smtp.eu-west-1.amazonaws.com:25, Host is email-smtp.eu-west-1.amazonaws.com, IPVersion is Id_IPv4, MaxLineAction is maException, MaxLineLength is 16384, Port is 25, ReadTimeOut is -1, RecvBufferSize is 32768, ReuseSocket is rsOSDependent, SendBufferSize is 32768, SSLOptions.Method is sslvTLSv1, SSLOptions.Mode is sslmUnassigned, SSLOptions.SSLVersions is [sslvTLSv1], TransparentProxy is IdSSLIOHandlerSocketOpenSSL., TransparentProxy.Autentication is NoAuthentication, TransparentProxy.IPVersion is Id_IPv4, TransparentProxy.Port is 1080, TransparentProxy.Version is svNoSocks, UseNagle is True

  • Port is 25

  • UseTLS is utUseExplicitTLS
  • "About Indy" is 10.6.2.5263

With XE8, I get an "SSL negotiation failed." exception at line handler.Send(msg); in the following code. The exact same code works fine with XE3, so I guess it might be somehow related to the Indy update.

var
  handler: TIdSMTP;
.
.
handler.

handler.Connect;
handler.Send(msg);

Why am I getting this exception in XE8? The machine where now XE8 is installed is the same where XE3 was installed, and the SSL dlls are still in the respective Degug and Release output directories. XE8 for now only uses the Debug output directory and the old XE3 executable works fine still from the Release output directory.

UPDATE: The issue was fixed simply by updating old SSL DLLs in the Dev machine. Apparently the latest Indy disables by default unsecure stuff.

Pep
  • 1,957
  • 2
  • 24
  • 40
  • This is not enough information to diagnose the problem. An SSL/TLS handshake can fail for any number of reasons. What are the actual settings of your `TIdSSLIOHandlerSocketOpenSSL` component? Also, have tried using port `587` or `2587` instead of `25`? Alternatively, you can use `utUseImplicitTLS` on port `465` or `2465` instead. – Remy Lebeau Apr 09 '15 at 00:58
  • Double check that the SSL DLL's are on path – Jens Borrisholt Apr 09 '15 at 05:24
  • 1
    Also, what version of OpenSSL are you using (and loading)? Remember some unsecure SSL version of the protocols should be now disabled by default. – LDS Apr 09 '15 at 09:36
  • @RemyLebeau I added more detailed information on the component. I still have not tried ports other than 25 because I need to ask IT to open these ports (they lock down anything remotely related to SMTP to minimize risks of IP banning by SpamHouse and family.) – Pep Apr 09 '15 at 09:44
  • @LDS I'm using the same DLLs I was using with XE3. Their timestamp is September 26, 2006 so they do not look as the very latest. I'll double check. Could you expand on what is exactly disabled by default and how do I manually re-enable it? – Pep Apr 09 '15 at 09:48
  • 1
    @LDS updating the DLLs from 2006 to 2015 fixed the issue. Thanks! – Pep Apr 09 '15 at 10:06
  • 1
    @Pep: glad it helped, probably something changed in their use or default between XE3 and XE8. Anyway, **keep OpenSSL DLLs updated**!! There have been a large number of big and small vulnerabilities discovered in OpenSSL in the past months, and it's going under a deep code audit, so more can surface. There have been also design flaws in some of the SSL suite of protocols themselves. Always check for OpenSSL known vulnerabilities, and deploy/update your applications with the last "safe" ones. – LDS Apr 09 '15 at 10:31

0 Answers0