0

In a commercial Delphi library, WinSock API functions like WinSock.connect and WinSock.send are used to upload files to a HTTP server. Is there a way to support HTTPS? I found http://www.rohitab.com/discuss/topic/36630-ssl-through-winsock/ which says:

You will need to choose one of the following methods:

  • A. Use WinINet Library.
  • B. Use normal sockets and WinCrypt's RSA support to match the SSL spec.
  • C. Use openssl or another library.
mjn
  • 36,362
  • 28
  • 176
  • 378

3 Answers3

2

Yes, certainly. By far the easiest for you will be to use WinInet as he'll do all the required SSL handshaking for you.

Implementing SSL on top of a socket is certainly doable but will be (a whole lot) more work. If you go down that path, I'd suggest OpenSSL; that's what we've used in the past when we've had to hand-roll SSL.

Just throwing this out here: another approach, if you own both the client and server side and can't use Wininet for some reason, is to encrypt the file on the client prior to upload. You'll still have the same vulnerabilities you have without SSL (e.g., traffic sniffing, man in the middle, replay attacks, etc) but at least the file data will be safe...provided your encryption key itself isn't transmitted.

There are examples on SO of using Wininet from Delphi; see How to send a HTTP POST Request in Delphi using WinInet api

Community
  • 1
  • 1
Will Chesterfield
  • 1,780
  • 12
  • 15
2

HTTPS is easily implemented in Delphi with Indy's TIdHTTP and TIdSSLIOHandlerSocketOpenSSL components and OpenSSL. You'll be dependent on including OpenSSL libraries.

There are also native Delphi solutions like SecureBlackBox from Eldos and IPWorks SSL From N Software.

To implement your own is not that difficult as long as you have the required components. You could even brew your own replacement easy enough if you don't need to support the TLS and SSL standards, but you'll still need some form of asymmetric and symmetric encryption algorithms and a way to verify the certificate if you're wanting to do something as cryptographically secure.

Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
1

Add to your (perhaps deprecated) list of HTTPS-compliant solutions:

D. Use the WinHTTP api instead of WinINet.

Both WinHttp and WinINet APIs are very close. But WinHttp is much faster than WinINet.

Here is how Microsoft defines WinHTTP:

Microsoft Windows HTTP Services (WinHTTP) provides developers with a server-supported, high-level interface to the HTTP/1.1 Internet protocol. WinHTTP is designed to be used primarily in server-based scenarios by server applications that communicate with HTTP servers.

WinINet was designed as an HTTP client platform for interactive desktop applications, such as Microsoft Internet Explorer, Microsoft Office, and Microsoft Money. WinINet displays a user interface for some operations such as collecting user credentials. WinHTTP, however, handles these operations programmatically. Server applications that require HTTP client services should use WinHTTP instead of WinINet. For more information, see Porting WinINet Applications to WinHTTP.

WinHTTP is also designed for use in system services and HTTP-based client applications. However, single-user applications that require FTP protocol functionality, cookie persistence, caching, automatic credential dialog handling, Internet Explorer compatibility, or downlevel platform support should consider using WinINet.

You can directly use the WinHTTP COM object (via late binding), or use low level API (very close to the WinINet one). See for instance our Open Source unit (Delphi 5 up to XE2). This link has a pros and cons table to refer to.

Just to emphasize the interrest of WinHTTP: as far as I discovered, the WCF implementation by Microsoft uses it for all its HTTP/1.1 communication (also take a look at http.sys kernel mode for the Server side in our very same unit - which is used also by WCF).

Arnaud Bouchez
  • 42,305
  • 3
  • 71
  • 159