Indy Delphi 10.1 Berlin.
My customer had the HTTPS connection checked (using Qualys SSL Labs). The report states: "This server supports SSL 2" plus other warnings but I guess they are related to this.
The code used is as follows:
SSLIOhandler:=TIdServerIOHandlerSSLOpenSSL.Create(NIL);
SSLIOhandler.SSLOptions.Method:=sslvTLSv1_2;
SSLIOhandler.SSLOptions.Mode:=sslmServer;
SSLIOhandler.OnVerifyPeer:=OnVerifyPeer;
SSLIOhandler.SSLOptions.SSLVersions:=[sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2];
HTTPServer:=TIdHTTPServer.Create(NIL);
HTTPServer.IOhandler:=SSLIOhandler;
I have read various posts but this area remains pretty much abacadabra to me. I limited the SSLVersions to just [sslvTLSv1_2] but the warning remains. What else can I do?
Update: Sorry to waste time. The Qualys test site apparently did not reload. I've restarted and retested and indeed it no longer complains about SSL2.
Next step is to pass its complaints about the ciphers, starting with TLS_RSA_WITH_DES_CBC_SHA. I have a list of ciphers but can't find how to assign them. When I use e.g.
SSLOptions.CipherList:='TLS_RSA_WITH_3DES_EDE_CBC_SHA';
I get an error: "SetCipher failed".
Related
I use Indy TidHTTPServer and TidServerIOHandlerSSLOpenSSL on my server component to handle HTTPS request for command & control.
There are situations where - without any logged errors on the server - client receive an error "SSL handshake failed". I see no reasons on the server and - funny enough - fixes itself sometimes after some time.
Where can I step into the Indy components to see where the problem is? Which events can I use to maybe see something?
Update1 (29.05.2021): An exeption I found throught he handlers suggested by Remy Lebeau is "Error accepting connection with SSL. EOF was observed that violates the protocol". I still cant tell what is causing this, though...
I have had this (or similar) errors in the past when I forgot to put the OpenSSL dll files in the same folder as the executable. You need ssleay32.dll and libeay32.dll.
You can find them on the Indy page (link at the very bottom): https://www.indyproject.org/download/ssl/
I am encountering some problems using some code that worked for ages involving Indy and the download of a web page. I use RAD Studio 10.2 Tokyo.
The web page is as follows:
https://donet.rfi.it/RFIPlatform/showDoc.do?compartimentoHidden=AN&docTypeHidden=CC
The code I am using is part of an application which has the same code since 2011 and it always worked well. The code is as follows:
IDHTTP1.Get('https://donet.rfi.it/RFIPlatform/showDoc.do?compartimentoHidden=AN&docTypeHidden=CC');
I am getting a "Connection Reset by Peer 10054" error since the website went down, some days ago, and when it came up again, the code did not work anymore.
The aforementioned web page can be called from the browser, can even be downloaded with WGET, but Indy is failing.
I tried to play with various options (Cookie Handling, Handle Redirects, HTTPOptions, etc...) and I also updated the SSL libraries to 1.0.2q (Indy cannot use OpenSSL 1.1.0 yet), but the whole thing just doesn't want to work.
Can someone help me figure out what is going on? It has to be for sure something on the website, since the code I use is the same since 2011 and it has always worked. And before that, the same code worked in a similar application since 2008.
Indy's TIdSSLIOHandlerSocketOpenSSL component enables only TLS 1.0 by default. The website in question (https://donet.rfi.it) does not accept TLS 1.0 anymore (probably why it went offline, to update its software), it will accept only TLS 1.1+ now.
TIdHTTP is able to successfully establish a TCP/IP connection to donet.rfi.it:443, but as soon as TIdSSLIOHandlerSocketOpenSSL sends a TLS 1.0 handshake request, the server forcibly closes the TCP connection. You are getting the "connection reset by peer" error while TIdSSLIOHandlerSocketOpenSSL is trying to read the server's handshake response.
You need to configure TIdSSLIOHandlerSocketOpenSSL to enable TLS 1.1 and/or 1.2. You can do that via its SSLOptions.SSLVersions property. Then TIdHTTP.Get() will work again (I tested it).
I am trying to run my app on iOS 9 -- Xcode 7 beta 5. Although my URLs are https, NSURL connection is still throwing an error:
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)
I am trying to avoid using an exception to get this working. My server supports the required protocols: https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/index.html
Thanks...
UPDATE: the release notes indicate that they have dropped default support of DHE_RSA ciphers:
"DHE_RSA cipher suites are now disabled by default in Secure Transport for TLS clients. This may cause failure to connect to TLS servers that only support DHE_RSA cipher suites. Apps that explicitly enable cipher suites using SSLSetEnabledCiphers are not affected and will still use DHE_RSA cipher suites if explicitly enabled."
These are the ciphers supported by my server. See the full list here:
https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/index.html
So I guess I need to use SSLSetEnabledCiphers for every NSURLConnection, or upgrade my server to support the DHE_ECDSA ciphers. Or use the exception mechanism for now.
Anything I've missed? And anyone got sample code for using SSLSetEnabledCiphers?
Thanks.
Here's the deal. The innocuous language about DHE_RSA cipher suites not being supported by default is a pretty big change by Apple in beta 5. A lot of servers out there don't support ECDHE_ECDSA ciphers by default. In order to support those ciphers on my server, it looks like I will have to upgrade something or several somethings. Or even recompile something. Ack.
And I assumed that I would just have to ensure all URLs were HTTPS!
Specifically I was able to support HTTPS-only links to my server by using the "NSExceptionRequiresForwardSecrecy = NO" key in info.plist. Also not forgetting the "NSIncludesSubdomains = YES" key if necessary.
Useful background, especially if Diffie-Helmen Exchange, Elliptical Curve and Forward Secrecy are not familiar to you:
http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
http://blog.lowsnr.net/2014/10/26/configuring-apache-2-2-ssltls-for-forward-secrecy/
I'm new to dealing with cookies and not sure if my code or maybe Indy version is the problem based on researching other posts.
Using Delphi 2010 and Indy 10.5.5.
Have set up a cookiemanager at design time. I can send an initial login request (using the POST method) to the server that is successful (get a "success" code back from the server app) and the cookie manager shows that it has accepted a cookie from the server.
When I try to reply to the server (again using POST) to get the next set of information, I get an error code back from the server app which indicates an authorization failure and I'm being told by the server tech support people to check the cookie being sent with the reply.
How can I check the contents of the cookie header that is being sent back to the server?
Also, in another post I saw that Indy 10 IdCookieManager.pas and IdCookie.pas have been updated in 2011. Should I update my Indy to the latest version as this might be my problem?
Thanks in advance.
Here is some more info:
Thank you for your previous assistance; I appear to be getting closer to reinstalling Indy10.
I purged my system of all Indy stuff except the most recent version (10.5.8) which I downloaded yesterday. [Actually I just moved the old stuff into a directory with an unusual name.]
Now I get a clean compile on all 5 packages.
I was able to add the two main packages (the ones starting with dcl) to my program's project list.
But I get "[DCC Fatal Error] E2202 Required Package IndyCore not found." when I try to compile my main program.
I tried removing and reinstalling the dcl packages to my project. When I removed them, I got the message that IndyCore and 3 other packages would also be removed - so it seems to know that dclIndyCode140 uses IndyCore140.
I've added some directories to my search path and tried placing the 5 bpl's in different directories. None of that had any effect and at this point I am stumped.
Ideas? Suggestions?
Steve
Upgrading to the latest release is definate recommended. Links are on Indy`s website. Yes, cookie support was broken in earlier Indy 10 releases but it working again now.
As for your other question, to see what TIdHTTP is sending, you have a few choices:
Look at the TIdHTTP.Request.RawHeaders property after sending a request.
Attach one of Indy's TIdLog... components to TIdHTTP, such as TIdLogFile, and look at the output.
Use an external packet sniffer, such as Wireshark.
I'm using the latest indy snapshot (installed yesterday) and newest SSL libraries.
When trying to send a mail using idSMTP, the first time the component connects, I get an exception:
Could't load the SSL libraries
. Funny thing is, a retry works always. Debugging I found that the problem is in IsSSLOpenSSLHeader, function Loaad: boolean, line
#OpenSSL_add_all_algorithms := LoadFunctionCLib('OpenSSL_add_all_algorithms');
Why does it fail the first time and not the second is still a mystery to me, but before I go on investigating I would like to as if anybody knows the solution to this problem.
The code you are using is NOT the latest snapshot. That bug was fixed a couple of weeks ago. The line you quote is NOT in the latest code, it has been replaced with the following:
fn_OPENSSL_add_all_algorithms_noconf = 'OPENSSL_add_all_algorithms_noconf';
fn_OpenSSL_add_all_algorithms = 'OpenSSL_add_all_algorithms';
#OpenSSL_add_all_algorithms := LoadOldCLib(fn_OpenSSL_add_all_algorithms, fn_OPENSSL_add_all_algorithms_noconf);
I'm using Delphi XE-1 on Win 7/64, with the SSL and Indy that are installed by default. This week I had to do some work with SMTP and SSL, and I ran into the same problem you reported. Our application is somewhat complex and is already live and deployed in several locations and it uses Indy at several points in the code, so installing a newer version of Indy and rebuilding etc, was not very palatable.
Since the problem only arises on the first pass, I traced through some of the code and came up with this simple, painless workaround:
smtpClient.connect;
smtpClient.disconnect;
smtpClient.connect;
if not smtpClient.Authenticate then
raise ...
smtpClient.Send(msg);
Once you call connnect and then disconnect, the SSL libraries are loaded, so on your second call to connect you're good to go.
Works fine.