@klsyzzz you can always use the parameter AError in OnVerifyPeer to see what exactly error you got. A documentation can be found in https://wiki.openssl.org/index.php/Manual:Verify(1) (and Indy also declares the const for avoiding magic numbers)
@rlebeau yup, that is a problem from Embarcadero, it was only FYI. And there already exist a QP Entry: https://quality.embarcadero.com/browse/RSP-18094
@rlebeau When you have time, can you clarify something for me? Using another (Windows) NNTP client, I get this error when attempting to connect:
"Error connecting with SSL. - error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small"
When I researched this earlier, it seems to indicate that EMBT have not updated their SSL libraries on the forums server. I'd like to be able to send a rocket their way and have someone fix it, if that is indeed the case
"Error connecting with SSL. - error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small"
When I researched this earlier, it seems to indicate that EMBT have not updated their SSL libraries on the forums server. I'd like to be able to send a rocket their way and have someone fix it, if that is indeed the case
(If it isn't clear: I mean connecting to EMBTs newsgroups)
@DelphiWorlds The DH error is a known issue, and a simple workaround: https://forums.embarcadero.com/thread.jspa?threadID=249192#884029 "A simple client fix is to change the OpenSSL cipher list to exclude DH ciphers, by adding
:!DH: within the existing cipher list, I've just changed mine to: 'ALL:!ADH:!DH:RC4+RSA:+SSLv2:@STRENGTH' and now the latest OpenSSL 1.1.0e connects". You can use the TIdSSLIOHandlerSocketOpenSSL.SSLOptions.CipherList property for that.
@DelphiWorlds The link I gave you above should jump right to the specific message that explains the issue and the CipherList workaround (the jump works fine for me). If your browser is not jumping to that message, your browser is being stupid. Just read the message from Angus Robertson on Apr 20 2017, it explains the DH issue and gives the workaround
@DelphiWorlds Yes, per the discussion: "The essential issue is the server is using DHParams with less than 768
bits, which are needed to support DH ciphers. To prevent the Logjam attack, OpenSSL 1.0.2e and later will not connect
with DHParams less than 768 bits, giving dh key too small... The proper fix would be to create new DHParams for the Jive server,
with 1,024 bits or later"
bits, which are needed to support DH ciphers. To prevent the Logjam attack, OpenSSL 1.0.2e and later will not connect
with DHParams less than 768 bits, giving dh key too small... The proper fix would be to create new DHParams for the Jive server,
with 1,024 bits or later"
Does the proxy authentification in IdHTTP work with NTLM? And if, what have I to do? Just simple put Username and Password to IdHttp1.ProxyParams.ProxyUsername and IdHttp1.ProxyParams.ProxyPassword? For my bad I have no proxy with ntlm authentification here for testing and it seems that setting up a squid with ntlm is a little bit complicated :(
@mezen Proxy auhentication uses the same mechanism as normal HTTP authentication - Indy's TIdAuthentication classes. TIdHTTP only supports BASIC authentication (TIdBasicAuthentication) by default, but adding additional IdAuthentication... units to your uses clause will activate other classes. NTLM is handled by the TIdNTLMAuthentication class in the IdAuthenticationNTLM unit, which is actually untested and thus is not registered in the IDE by default, but you can try adding it to your projct manually and see if it works.
(My Target Platform is only Win32, maybe Win64 someday in a far future)
I am trying to add client certificates to a solution using TIdTCPServer that already has SSL connections - based on an answer given in Embarcadero forums. I have setup
OnVerifyPeer events, and set VerifyMode to [sslvrfPeer], but it is currently allowing connections when there is no client certificate. What have I done wrong / missed ?
sslvrPeer: A Request from a client certificate will be sent to the client. The client may opt to ignore the request, but if a certificate is sent back, it will be verified.sslvrfFailIfNoPeerCert: only used for server when sslvrPeeris set. Use of this flag will cause the handshake to terminate immendiatly if no certificate is provided by the client.sslvrfClientOnce: only used for server when sslvrPeeris set. Use of this flag will prevent the server from requesting a certificate from the client in the case of renegotiation. A certificate will still be requested during the initial handshake
@mmarquee so you have to set
VerifyMode to [sslvrfPeer, sslvrfFailIfNoPeerCert]
Good source is https://wiki.openssl.org/index.php/Manual:SSL_CTX_set_verify(3)
SSL_VERIFY_NONE is VerifyMode := [];
I have an application that "advertises" itself by way of a UDP broadcast.. if I call Broadcast on TIdUDPClient, is it supposed to broadcast on all bindable IP addresses, or does it just pick the first one, or something else? Is using UDP an advisable way of doing this in the first place? I note that for IPv6 networks I'll have to use multicast anyway
Note that the comms is (for now) just happening on the local network
Not sure what value I should be putting for MulticastGroup in the server, either
@DelphiWorlds Sending a UDP broadcast will go out on a single IP interface of the OS's choosing, unless you bind the socket to a specific interface beforehand, or use the broadcast IP of a specific subnet rather than the generic 255.255.255.255 broadcast address. If you want to broadcast on all available interfaces, you have to send a broadcast to each one individually.
@DelphiWorlds I can't comment on your 10049 error without seeing how you are binding the IPs to begin with. The MulticastGroup is the network multicast IP address that you want to send/receive packets on (the IP that routers watch for on packets), which is different than the local IP address that you bind sockets to. IPv4 multicast group addresses are in the 224.x.x.x to 239.x.x.x range. IPv6 multicast group addresses are in the FF0x:x:x:x:x:x:x:x range
I think I may be on the right track with this:
https://stackoverflow.com/questions/37045719/udp-broadcasting-with-indy-sockets-how-to-select-the-right-interface
https://stackoverflow.com/questions/37045719/udp-broadcasting-with-indy-sockets-how-to-select-the-right-interface
I need to loop through the available IPs and send on each
procedure TNetworkingModel.ConfigureUDPBindings(const AListener: TIdIPMCastClient);
var
LHandle: TIdSocketHandle;
I: Integer;
begin
AListener.Bindings.Clear;
for I := 0 to FLocalAddresses.Count - 1 do
begin
LHandle := AListener.Bindings.Add;
LHandle.IPVersion := FLocalAddresses.Addresses[I].IPVersion;
LHandle.IP := FLocalAddresses.Addresses[I].IPAddress;
LHandle.Port := AListener.DefaultPort;
end;
end;
var
LHandle: TIdSocketHandle;
I: Integer;
begin
AListener.Bindings.Clear;
for I := 0 to FLocalAddresses.Count - 1 do
begin
LHandle := AListener.Bindings.Add;
LHandle.IPVersion := FLocalAddresses.Addresses[I].IPVersion;
LHandle.IP := FLocalAddresses.Addresses[I].IPAddress;
LHandle.Port := AListener.DefaultPort;
end;
end;
oops
not that good with gitter
procedure TNetworkingModel.ConfigureUDPBindings(const AListener: TIdIPMCastClient);
var
LHandle: TIdSocketHandle;
I: Integer;
begin
AListener.Bindings.Clear;
for I := 0 to FLocalAddresses.Count - 1 do
begin
LHandle := AListener.Bindings.Add;
LHandle.IPVersion := FLocalAddresses.Addresses[I].IPVersion;
LHandle.IP := FLocalAddresses.Addresses[I].IPAddress;
LHandle.Port := AListener.DefaultPort;
end;
end;
that's how I'm configuring the bindings