SSL stands for Secure Socket Layer and is the accepted encryption method of encrypting data on the Internet. SSL is mostly commonly used with HTTP (Web) traffic and referred to as secure HTTP (HTTPS). SSL however is not limited to HTTP and can be used with any of the TCP/IP protocols.
In Indy to use SSL, you must first install the proper SSL DLLs. Indy's SSL support is done in an open fashion, but the only currently implemented SSL library is OpenSSL. The OpenSSL library is available as a set of DLLs and is available for download separately from the main Indy distribution.
The US and other governments in their infinite wisdom and understanding of technology banned the export of certain encryption methods such as SSL. Because of this SSL technology cannot be placed on a website unless certain measures are taken to verify the location of each client wishing to
download the technology. This is not only difficult to implement, but opens the website owners to a lot of legal liability.
The restriction only applied to electronic distributions and did not apply to all forms of printed source code. The restriction also applied only to exportation, not importation.
So for a brief while programmers printed the source code upon such things as T-Shirts, crossed borders, and retyped and compiled such code. After this occurred, countries which did not sign the treaty with the US were free to distribute such encryption in any form and since there was no restriction importation anyone could download the encryption technology in ready to use form.
Many of these issues have since then been solved and some governments have lightened up.
However many export restrictions are still in place and vary from country to country. Because of this, all Indy SSL work is done in Slovenia, and all SSL encryption technology related to Indy is distributed from Slovenia. Slovenia has no restrictions on export of encryption.
In addition to exportation of encryption, some countries have restrictions on use or even possession of encryption technologies. You should check your countries laws before implementing or using SSL.
Countries such as China, Iraq, and others have harsh and even death penalties for even possessing such technology.
18.1 Secure HTTP / HTTPS
Implementing HTTPS in Indy is very easy. Simply pass a secure URL instead of a standard URL, and the Indy HTTP client (TIdHTTP) will do everything automatically. To make a URL secure, simply change the http:// portion to https://.
Note that for a HTTPS session to be established, the web server that will be responding to the request must support SSL and have encryption certificates installed. The Indy HTTP client also does not automatically verify the server certificates, this is your responsibility.
18.2 Other Clients
SSL can easily be implemented with any Indy TCP client by the use of an SSL IOHandler. Normally encryption should be implemented using an Intercept instead of an IOHandler. SSL is implemented in Indy using an IOHandler instead of an Intercept because the SSL libraries actually perform the communications themselves. The data is returned and accepted in unencrypted form directly from the SSL libraries.
Indy in Depth 127
(C) 2003 Atozed Computer Software Ltd.
This book is registered to Constantinos Pitsakis
To make an Indy TCP client use SSL simply add a TIdSSLIOHandlerSocket to your form from the Indy Misc tab. Now set the IOHandler property of your TCP client to the TIdSSLIOHandlerSocket. To support basic SSL, this is all that is required. The TIdSSLIOHandlerSocket does have additional properties for specifying client side certificates and other more advanced SSL options.
18.3 Server SSL
Implementing SSL in a server is a little more complicated than implementing SSL in clients. With clients typically all that is needed is to hook to a TIdTCPClient or descendant to a
TIdSSLIOHandlerSocket instance. This is because the server does the larger share of the SSL work.
To implement SSL in servers a TIdServerIOHandlerSSL is used. The TIdTCPServer's intercept property is used to hook it to a TIdServerIOHandlerSSL. However unlike a TIdSSLIOHandlerSocket (Client), a TIdServerIOHandlerSSL requires some additional steps. Specifically certificates must be installed. These certificates must be provided as files on disk and specified in CertFile, KeyFile, and RootCertFile, all of which are sub properties of the SSLOptions property.
Certificates typically are obtained from a trusted certificate authority. You can make your own
certificates and be your own trusted authority, but none of the browsers will trust your certificates and the browsers will display a warning when connecting to your server. If you wish to deploy to the Internet you must obtain a certificate from a certificate authority that the standard browsers trust.
Verisign is the only authority trusted by all browsers. Thawte can also be used, but not all browsers trust Thawte by default.
If your clients are within your control such as on a intranet or extranet, you may choose to be your own trusted authority. To avoid the warning dialog however, you must install your certificate into each browser that will connect to your server.. This allows the browser to consider the signatures on your certificates as being from a trusted authority.
Note that this only applies to HTTP servers, but SSL is not limited to HTTP. You can implement SSL if you are implementing the client and the server and have full control over trust associations and rules.
18.4 Converting Certificates to PEM Format
Chances are that your certificates were not delivered to you in .pem format. If they are not in .pem you must convert them for use with Indy.
This procedure assumes that you have already received your key and certificate pair from some Certificate Authority (like Verisign or Thawte) and that you have them installed in Microsoft Internet Explorer in Personal Certificates Store.
18.4.1 Exporting the Certificate
Select the certificate and export it as a .pfx file (Personal Exchange Format). You may optionally protect it with a password.
18.4.2 Convert .pfx to .pem
As part of the SSL download, a utility named openssl.exe was included. This utility will be used to convert your .pfx file.
To use openssl.exe, use the following format:
SSL - Secure Sockets 128
openssl.exe pkcs12 –in <your file>.pfx –out <your file>.pem
Openssl.exe will prompt you for a password. Enter it if you used one, or leave it blank if you did not specify one. It will also prompt you for a new password for the .pem file. This is optional, but if you protect it with a password be sure to create a OnGetPassword event in the SSL intercept.
18.4.3 Splitting the .pem File
If you examine the new .pem file with a notepad, you will notice that it consists of two parts. The two parts consist of the private key and the certificate (public key) part. There is also some addition information included. Indy requires that this information be separated into separate files.
18.4.4 Key.pem
Create key.pem with notepad and paste everything between and including these two statements:
---BEGIN RSA PRIVATE ---END RSA PRIVATE
KEY---18.4.5 Cert.pem
Create cert.pem with notepad and paste everything between and including these two statements:
---BEGIN ---END
CERTIFICATE---18.4.6 Root.pem
The final file that Indy requires is the Certificate Authority certificate file. You can obtain this from the Internet Explorer in Trusted Root Certificate Authority dialog. Select the Authority that issued your certificate and export it in Base64 (cer) format. This format is also the same as PEM format so after export simply rename the file to root.pem