@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
Debugger Exception Notification
Project dyld_sim raised exception class EIdSocketError with message 'Socket Error # 49Cannot assign requested address.'.
Break Continue Help
Francesco Marano may have given me a solution in the forums.. the thread starts here:
https://forums.embarcadero.com/message.jspa?messageID=887844&tstart=0
https://forums.embarcadero.com/message.jspa?messageID=887844&tstart=0
I neglected to consider that the IPMCast classes have their own IPVersion property, as well as MulticastGroup property.. doh
It fails when setting the client active
TIdStackVCLPosix.GetLocalAddressList fails to retrieve any addresses for me on my Android 7 device, so I've created this Gist, in case it's of any use:
https://gist.github.com/DelphiWorlds/0733b6611707c8d5725ee42fd1ae01fd
https://gist.github.com/DelphiWorlds/0733b6611707c8d5725ee42fd1ae01fd
@DelphiWorlds TIdStackVCLPosix.GetLocalAddressList() being broken on Android is a known issue. There are comments to that effect in the code. I stay away from using Embarcadero's JNI Bridge interfaces because 1) they are not portable (they only work in Delphi, not in FreePascal), and 2) there are threading issues related to accessing Java objects in native code, so I try to stick with native solutions. Which I have not implemented for Android yet.
procedure TForm1.SendBroadcast(const AServer: TIdIPMCastServer; const ABroadcast: string);
var
I: Integer;
begin
for I := 0 to FLocalAddresses.Count - 1 do
begin
if FLocalAddresses[I].IPVersion = AServer.IPVersion then
begin
AServer.Active := False;
AServer.BoundIP := FLocalAddresses[I].IPAddress;
AServer.BoundPort := AServer.Port;
AServer.Active := True;
AServer.Send(ABroadcast);
end;
end;
end;