I need to communicate with a device that uses SSL. It used to use socket to communicate with my Delphi app, but now I'd like to use security communication with the device.
So, is there a TServerSocket and TClientSocket equivalent component that I can use SSL?
There's no built-in direct equivalent in Delphi. You can use Indy with either OpenSSL or SecureBlackbox SSL classes however Indy is not a drop-in replacement for TServerSocket/TClientSocket, as they use very different coding models. Or you can use TElSecureClientSocket and TElSecureServerSocket classes of SecureBlackbox - they are descendants and direct replacements for TClientSocket and TServerSocket respectively. Note: SecureBlackbox is our product.
ICS from François Piette is a excellent open source library with SSL support.
Related
I'm writing a download manager in Delphi with some custom features like resumable downloads and downloading through proxies.
I'm studing different component solutions: Indy and NetHTTP, both seem very close.
TNetHTTPClient seem to be an interface of winhttp.dll.
TIdHTTP seem to be an interface of wininet.dll (but i'm not sure).
TIdHTTP seems like a very old component (maybe very stable/tested) and has tons of documentation online.
TNetHTTPClient seems to be a very recent component, and doesn't have good documentation online.
I'm a bit undecided... which one to choose?
The point is: what is the main difference between these two components?
My question is a bit disputable (primarily opinion-based), but I haven't found any practical comparison between these two components.
TNetHTTPClient was introduced in Delphi XE8.
The most important benefit of TNetHTTPClient is that it allows your application to support HTTPS without having to provide your own support for SSL/TLS. TNetHTTPClient relies on the SSL/TLS support provided by the operating system.
This means you don't have to update your application whenever new vulnerabilities are discovered. Your customers will get these updates as part of their operating system updates. Less work for you and better security for your customers (if they believe their operating system vendor to be better at updating SSL/TLS libraries than you are).
It also means the code that encrypts and decrypts the HTTPS traffic is not in your application. So your application is not affected by restrictions on importing or exporting encryption algorithms.
TIdHTTP relies on OpenSSL to support HTTPS. You'll have to ship two DLLs with your application. OpenSSL is an open source project. Some organizations have issues with software that contains open source components. One of our products uses TIdFTP and OpenSSL to support FTPS. Every now and then we have users asking if the product will work without these DLLs (it will, but without FTPS), because their presence makes it more difficult to get the software approved for use at their organization.
I believe that all this was also Embarcadero's motivation for creating TNetHTTPClient (even though they already had TIdHTTP). It moves the onus of making sure HTTPS is secure from the developer to the operating system.
Indy DOES NOT use WinInet/WinHTTP at all. It uses cross-platform BSD/POSIX based socket APIs directly (like WinSock on Windows), implementing Internet protocols (like HTTP) completely from scratch.
TIdHTTP is a manual HTTP implementation.
TNetHTTPClient, on the other hand, wraps system-provided HTTP APIs instead (like WinInet/WinHTTP on Windows).
Could someone please explain their differences? Are they same and work the same way? Which one is better than the other components?
They are NOT the same, and they DO NOT work the same way. They take very different approaches to socket API interactions, event handling, error handling, etc.
TClientSocket and TServerSocket are the original VCL-based (Windows-specific) socket components. They were deprecated in Delphi 7 and are no longer installed by default, but are still available for manual install if you want to use them.
TTcpClient and TTcpServer were originally introduced in Delphi 6 as a cross-platform socket solution for Kylix (which is a dead product). They were removed from Delphi in XE6, downgraded to demo status, not even official components anymore.
In my opinion, TTcpClient and TTcpServer are horrible components, you should stay away from them. They use a very minimalistic "least common demoninator" approach to cross-platform programming, catering only to a few basic functions that multiple platforms support, not leveraging any platform-specific features or even higher-level functions. They have a very basic interface that is badly designed. They are very difficult to work with, have bad error handling, and are not very flexible to use.
If you need to write new socket code, TClientSocket and TServerSocket work great if you are only interested in supporting Windows, but if you need to support cross-platform then you should use a third-party socket library, such as Indy (TIdTCPClient/TIdTCPServer), ICS (TWSocket/TWSocketServer), Synapse (TTCPBlockSocket), etc.
Indy is not enough for me, it must support SSL and be rock solid, can be commercial also
Indy 10's SMTP component supports SSL. What problems are you having with it?
Icsn (and Ics-ssl) components at :
http://www.overbyte.be/frame_index.html
I've used IP*Works SMTP component before. I didn't do anything involved with them, I used them to send an email with error information basically. I have never used the SSL version either.
I don't believe you can purchase the components individually either.
http://nsoftware.com/ipworks/components.aspx
I use Synapse library. It works very well with SSL/TLS. There is public wiki with information on "How To Use SMTP with TLS". It works with Delphi (I use Turbo that is based on 2006) and FPC. It is "normal" library, not component and in my opinion this is advantage for command line utilities or server applications.
SMTP is so trivial protocol (unless you use SASL or other exotic authentication methods) that any component would work. Of course, I would recommend our SecureBlackbox product. Freeware libraries such as Indy, ICS, Synapse to get SSL have bindings to OpenSSL DLL and also to SecureBlackbox (none of the listed has own SSL implementation).
I'm a C++ programmer, but my question is about the Delphi network socket library Indy.
Essentially as Microsoft crippled raw sockets with WinXP SP2 so that TCP data cannot be sent over them, does this then also apply to Indy? One of my friends recommended it to me rather then using the WinSock API.
If not, then is the only way to use raw TCP sockets using the WinPCap API?
If it doesn't, I know that synapse for Delphi does. The latest version now supports D2009 and it is being actively supported.
As you can see from the other answers there are a lot of Delphi libraries to simplify network programming. However, AFAIK they all provide a friendlier layer over the WinSock API (on Windows, over the standard socket API on other OSs) and thus are not able to do anything that the WinSock API isn't able to do. In particular they may or may not support raw socket access, but if the OS fails to send data over the socket the libraries will only return errors as well.
For more information about the limitations of raw sockets on most recent Windows OS versions see this MSDN page, in particular the section "Limitations on Raw Sockets". It states quite clearly that
To get around these issues, it may be required to write a Windows network protocol driver (device driver) for the specific network protocol.
Neither of the Delphi network programming libraries comes with its own network protocol driver AFAIK. And neither will help you with permission issues on limited user accounts, or the interference of the Windows Firewall.
As you mention WinPcap in your question you know it is capable of doing what you want. There are Delphi wrappers for it, like Magenta Systems Internet Packet Monitoring Components. However, as a C++ programmer you may be better off to use the library directly from C++, as Delphi adds nothing in regard to the socket programming you want to do. In particular you won't need the extra layer to hide platform differences that some of the Delphi libraries provide, as you will be programming directly against the libpcap API.
Indy works quite well. I use it quite a bit with few problems.
If your looking for more basic socket interaction you could use these other components:
TTCPClient
TCPServer
TClientSocket
TServerSocket
All of these components also ship with Delphi.
Don't know about winpcap directly, but I believe there is a delphi wrapper for it. I don't currently know where I've seen it but it shouldn't be hard to find using Google code search.
you should check ICS components
ICS is a free internet component
library for all Delphi, C++Builder,
BDS and RAD Studio versions (win32).
It includes TCP, UDP, raw sockets,
clients, servers, as well as many high
level protocols such as FTP, SMTP,
POP3, NNTP, HTTP and more.
http://www.overbyte.be/
I would rather prefer synapse over than Indy, it's architecture is more simpler thus easier to understand.
Hallo, Does anyone perhaps know how to interface with a MemCached server (linux) from within a Delphi win32 application?
I am unable to find a general C DLL client, or perhaps delphi code to communicate to the server.
Any suggestions/help would be appreciated.
Thanks
Eric Grobler
A Delphi client for Memcached can be found on google code:
http://code.google.com/p/delphimemcache/
Since the protocol is fairly simple, just about any library which handles telnet should be able to handle communication with the server. This includes Indy, Synapse, and ICS. I based this off of the protocol documentation.
My preference would be to implement using Synapse. Synapse uses an object model rather than a component model, and is very easy to use and extend. The latest developers version (available via SVN) supports Delphi 2009 and I would expect soon to support Delphi 2010.
Thanks for your feedback, I will try a telnet communication.
(and have a look at Synapse)
Regards
Eric