These are chat archives for IndySockets/Indy

21st
Jan 2019
Valmeras
@Valmeras
Jan 21 00:22
I am using Indy Rad Studio Tokyo 10.2 with Indy 10. Indy components used are TIdSMTP, TIdMessage and TIdSSLIOHandlerSocketOpenSSL. The SSL version I am using for connection TLSv1_2. When I try to connect to the server smtp.gmail.com on port 587, I am getting an "Unknown CA" error message. What can be the reason ?
Valmeras
@Valmeras
Jan 21 02:08
SSL status: "before/connect initialization"
AType = Handshake StartMessage = before/connect initialization
SSL status: "before/connect initialization"
AType = Connect LoopMessage = before/connect initialization
SSL status: "SSLv3 write client hello A"
AType = Connect LoopMessage = SSLv3 write client hello A
SSL status: "SSLv3 read server hello A"
AType = Connect LoopMessage = SSLv3 read server hello A
SSL status: "SSLv3 read server certificate B"
AType = fatal Write AlertMessage = unknown CA
SSL status: "error"
AType = Connect ErrorMessage = error
SSL negotiation failed.
mezen
@mezen
Jan 21 10:40
OpenSSL does not use the windows certificate store, so you have to tell OpenSSL which CAs are trustworthy. Or you disable the certification verification (most insecure) and every certificate will be accepted
Remy Lebeau
@rlebeau
Jan 21 18:02
@pilotkid there are no tutorials, and I am not aware of any demos for TIdFTPServer specifically, so you will have to search through various online discussion forums, or just ask questions here or at https://www.atozed.com/forums/ as needed.
@Valmeras mezen is correct. If you want to perform validation then you need to give OpenSSL certificates to validate against. Though peer validation is disabled by default, and I've never needed to specify any CA certificates when connecting to Gmail. But yes, it is technically less secure as it does not avoid MITM attacks. You need to validate who you are connected to in order to avoid that
mezen
@mezen
Jan 21 18:07
I have the following situation: TIdTCPClient connects to a TCP Server, the server sends some data and disconnects (as simple example - in reality there are more communications). If I use TIdTCPClient.Connected, the result is True, because the InputBuffer is not empty. But using TIdTCPClient.CheckForData tells False, because the connection is terminated. Now the question: What is the best nonblocking way to detect: Oh there is data to read.
Remy Lebeau
@rlebeau
Jan 21 18:12
@mezen CheckForDataOnSource() ignores the InputBuffer and goes right to the "source" (ie, the socket). What you need to do is check InputBufferIsEmpty() first, and only if True then check CheckForDataOnSource() and CheckForDisconnect(), for example:
if IdTCPClient1.IOHandler.InputBufferIsEmpty then
begin
  IdTCPClient1.IOHandler.CheckForDataOnSource(0);
  IdTCPClient1.IOHandler.CheckForDisconnect;
  if IdTCPClient1.IOHandler.InputBufferIsEmpty then Exit;
end;
// input buffer is not empty here, read as needed...
mezen
@mezen
Jan 21 18:17
Thx, will test it tommorow :)