These are chat archives for IndySockets/Indy

21st
Oct 2016
marbles99
@marbles99
Oct 21 2016 08:43
Hi. Hope someone might be able to help me out here. Having a bit of an issue with connecting to an API of our webstore platform (ECWID). For legacy reasons, I am afraid I am still using INDY9 on D2007 (it's a grid component that is not available passed D2007 that holds us back a little). Anyway, we use HTTP/SSL to connect and process through the API. On Oct 11th this stopped working for no reason our end. Nothing changed here for a few months with this software so I know it was not here. Eventually, ECWID developer support admitted the had disabled an unsafe cipher on Oct 11th, so that matched up. They renabled it and the software worked again. But they disabled it immediately as they say it is unsafe. But it breaks our software. I thought it might be just a case of updating the SSL libraries. But the latest ones won't seem to load with Indy 9. The latest I can get to load still will not connect. Is there anything I can do to get this working? Any suggestions? I know ideally, Indy 10 might be the answer but in this instance it is just not possible.
This message was deleted
My other thought was to create a processor utility in Seattle/Indy10 (which I have at work) or Berlin/Indy10 (which I have at home). But I can't get this to work either. A very simple program just to use HTTP/SSL and a simple GET. Using the lastest SSL libraries (from Fulgan) just keeps coming up with an error (see below). I don't really want to go down this route though, I would rather be able to get the original programme working with calls within rather than have to call an external 'processor'.
marbles99
@marbles99
Oct 21 2016 08:49
blob
Indy 9 version I am using which won't connect to the shop is 9.0.50 and Seattle version which erros as above is 10.6.2.5298
Ludwig Behm
@lbehm
Oct 21 2016 14:17
Which ciphers and tls protocols does the API support?
marbles99
@marbles99
Oct 21 2016 14:55
So they have told me, this is the cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
TLS1 and above
Thanks.
marbles99
@marbles99
Oct 21 2016 15:08
I suspect this might be an SSL issue. I have tried creating a Synapse version of the call and on an older SSL it failed. Using the lastest, it worked. So guess the dilemma looks like not being able to use a later version of SSL that is compatible with the API ciphers in Indy 9. It may be I have to abandon Indy for this project and revert to Synapse if there is not an easy fix, which I suspect it isn't.
Remy Lebeau
@rlebeau
Oct 21 2016 16:41
Indy 9 uses customized versions of the OpenSSL DLLs and thus cannot utilize newer OpenSSL versions. You need Indy 10 for that. Indy 9 does support TLS 1.0, though, so I would think turning off 1 cipher would not break as long as the other ciphers are available. If you use a packet sniffer like Wireshark, you can see the cipher list that your app's version of OpenSSL is offering to the server during the handshake.
Another option would be to move your TCP logic to a DLL and update your app to use that, and then write the DLL using Indy 10. Along those same lines, you might consider moving your business logic out of your app to a separate DLL/process so it can be written in a modern Delphi version, and just leave the UI by itself written in D2007.