Delphi w Indy 10: unable to connect via TLS 1.2 w SSL "Best Practices" on the web server

Question

Question:. How can we get Indy 10 to work with a web server that uses the latest TLS 1.2 SSL Best Practices?

The best recommendations are documented by Microsoft: https://technet.microsoft.com/library/security/ms12-006 In fact, the piece of cipher used in several versions of TLS is considered unsafe. Please note that this is kb from mid-2013, long before the poodle.

As a best practice, there are articles from the Delphi community related to the BEAST attack that also offer to disable CBC-based ciphers ( http://www.atozedsoftware.com/Intraweb/Blog/20120905.EN.aspx )

Summary of Best Practices: Major SSL breaches include BEAST and POODLE exploits. The scenario here is not sharp or narrow. This is the middle of the road "How to create a truly modern, reliable SSL client based on Indy10 + OpenSSL." Briefly, these violations indicate that SSL 2/3 should be avoided, and TLS 1.0 is also considered vulnerable in many cases. Many CBC-based ciphers are considered unsafe.

I have to add: this is not hypothetical. Earlier in 2014, we had a pre-poodle consultant that our application servers (for our web application) should only be installed for TLS 1.2 and that all other SSL protocols should be disabled. This consultant is part of a large online security firm, and they advise this in every review they do. I believe that they are the industry standard.

Indy 10 build: gsIdVersion = '10 .6.0.5213 ';

In the code, indy is set to: SSLOptions.SSLVersions: = [sslvSSLv23]

and openssl libs: 1.0.1.10/1.0.1J

Testing on a Win2012-R2 server using ssl cert. We are gradually phasing out SSL on the web server in order to comply with the latest SSL best practices.

We found a problem: Indy 10 cannot connect when we apply only the best practices and only TLS 1.2.

Browsers connect normally.

As we tested:

• Win2012-R2, commercial SSL certificate.
• Using the Nartac Software iis crypto interface to change the SSL configuration (schannel.dll configuration) on the Win2012 server (screenshot below)

Results:

• When we implement only “best practices,” Indy10 can connect perfectly. OpenSSL Log Information:

  SSL Status: "SSL negotiation completed successfully"

  Cipher: name = AES256-SHA; description = AES256-SHA SSLv3 Kx = RSA Au = RSA Enc = AES (256) Mac = SHA1; bit = 256; version = TLSv1 / SSLv3;

• But when we take above, And we disable TLS 1.0 and TLS 1.1, the indy application will no longer be able to connect. Open SSL Logs:

  SSL status: "SSLv2 / v3 write hello client"

  SSL status: "SSLv2 / v3 read server hello" Socket error # 10054 Connection reset using a peer-to-peer network.

Here is the IIS Crypto configuration: (The Best Practices button below offers Microsoft in one click: https://technet.microsoft.com/library/security/ms12-006 )

Answer 1

As Remy notes in the OP comments, the solution is to use the Indy 10 SSLIOHandler CipherList property to set the list of ciphers.

Available ciphers:

https://www.openssl.org/docs/apps/ciphers.html

Some notes:

1) We were not able to get the wildcard examples on the page above to work. for example: ALL :! ADH: @STRENGTH and the like, we won’t be able to work.

2) The correct format is a list of ciphers with a colon delimiter. For instance. AES128-SHA256: AES128-GCM-SHA256: ECDH-RSA-NULL-SHA

3) We found that providing a long list of ciphers (40 or more) actually gave us less connectivity to various ssl servers. (It seems that some may not be compatible on the same list, or that openssl does an imperfect job of negotiating with a remote server.) Subsets of the list gave better results.

4) We have not yet found a solid recommended list.

5) We were told that some ciphers should probably be avoided due to the costly (intensive) nature of some of them. We have not explored this area at this time.

6) To confirm your application in the future, allow the settings or registry entries to change the list of ciphers in the field. (Who knows what will be exploited and disconnected further ... Today SSL v3, tomorrow TLS 1.1 ...)