A C library which extends the standard RPC (remote procedure calls) library, to allow the RPC communication to take place over an SSL transport. Thus, encryption and authentication is provided by the SSL layer.
This project is kindly hosted by Source Forge. The SF project page is here.
ONC-RPC or RPC is a open protocol for making service calls across the network. The RPC protocol provides a lightweight, flexible architecture for clients/servers communications on the network. The first implementation was developed by Sun and given away under an open-source licence. The RPC implementation is freely available on many operating systems including Linux. Initially RPC provided little support for strong encryption and authentication, but mechanisms do exist. GSS-API provides a framework for plugging in many encryption/security mechanisms.
SSL is an open protocol supporting secure authentication and encryption of a stream. The OpenSSL library is a widely used open source implementation of SSL.
Here, you will find a library which allows the Sun RPC library to operate over an SSL transport. SSL is a very popular transport for security/authentication, it being the transport which is used for secure web (HTTPS). The authentication mechanism, which uses X.509 certificates is already in use in many enterprises, and so RPC calls using the SSL transport have the potential to be extremely useful. I'm using OpenSSL for the SSL layer.
RPC is seen as rather "out of date" - it lacks features which are considered essential for building network applications in the enterprise environment. People see Java/RMI, CORBA, SOAP, XML-RPC or .NET architectures as "current" technology. RPC still has plenty of potential for applications where performance, latency or throughput is important. People still have legacy applications built using RPC, and could benefit from improving the security without having to re-engineer the application.
C RPC implementations are all (or mostly?) based on Sun's releases of the RPC library. Sun's initial release is known as "Sun RPC", and was released while SunOS was current. Sun RPC is compatible with BSD operating systems, and a variant of this is included in the GNU C library (glibc). Sun RPC is thus included with Linux. Sun RPC uses the socket interface for network communication.
Sun's later released a version of the RPC code called TI-RPC. This code uses the XLI interfaces for network communication as opposed to sockets. Later UNIX operating systems use the XLI interfaces as standard network interfaces. This is a big different between SVR4 UNIX and Linux - SVR4 uses XLI as standard, offering a socket interface for backward compatibility. Linux uses sockets and has no XLI interface. I believe there are TI-RPC and XLI for Linux but they are not shipped with Linux distributions as standard. Linux software thus doesn't genereally use TI-RPC.
This library works with Sun RPC, and so works on Linux (which is what it has been developed on), probably BSD, but not UNIXes which use TLI and TI-RPC. (Let me know if it works on non-Linux systems.)
TI-RPC is not drastically different in structure to Sun RPC, and it should be relatively straightforward to port this work to TI-RPC, but I have no development environment in which to do this.
The library is very small. It provides two functions: one for the server, one for the client. Example clients and servers are provided.
Existing RPC applications are built to operate over TCP or UDP protocols.
For an RPC server using TCP, the server may create a service handle using the
svctcp_create function:
SVCXPRT *svctcp_create(int sock, u_int send_size, u_int recv_size);
The rpcssl library provides an equivalent function:
SVCXPRT *svcssl_create(int sock, u_int send_size, u_int recv_size, SSL_CTX *ctx);
This function creates a service handle which will expect clients to connect
to it using the SSL library. The rpcssl library expects the SSL context to
provide all SSL resources necessary. The caller should have configured the
key/certificates and configured the ciphers to use. Once the service handle
is created, existing RPC library calls can be made. For instance, the service
may likely call svc_register and then svc_run.
For an RPC client using TCP, the client may create a client handle using the
clnttcp_create function:
CLIENT *clnttcp_create(struct sockaddr_in *addr, u_long prognum, u_long versnum, int sockp, u_int sendsz, u_int recvsz);
The rpcssl library provides an equivalent function:
CLIENT *clntssl_create(struct sockaddr_in *raddr, u_long prog, u_long vers, int *sockp, u_int sendsz, u_int recvsz, SSL_CTX *ctx);
This function creates a client handle which will make RPC calls over an
SSL transport using the SSL library.
The rpcssl library expects the SSL context to
provide all SSL resources necessary. The caller should have configured the
key/certificates and configured the ciphers to use. Once the client handle
is created, existing RPC library calls can be made. For instance, the client
may likely call clnt_call to make a call to the server.
The rpcssl library currently only support the Sun RPC implementation. There is a newer RPC implementation called TI-RPC, and the rpcssl library will not work with this implementation. Sun RPC is widely available: it is part of the GNU C-library, and is thus included on every modern Linux distribution. ONC-RPC is not included on Solaris. This code may work on the BSD operating systems.
On systems which already have RPC, all you need to do is install the library, modify your application to call the clntssl_create and svcssl_create functions, and link with the library.
portmap or rpcbind processes are registrars for RPC services. The rpcbind
is provided in TI-RPC, and so doesn't exist on Linux.
The portmap process
stores a mapping of (RPC program, RPC version, protocol) to port number
where protocol is the IP protocol number. The TCP protocol number, 6 is used
to indicate a service created using svctcp_create. The SSL
communications also go over TCP. Rather than use the TCP protocol number, 6,
I'm using 255 (reserved) to indicate an SSL communication. This allows the
standard TCP service and the SSL service to co-exist. A server could choose
to implement a standard TCP service, and SSL-based service and register both.
The portmap
process supports any protocol number in the protocol field, and there is no
IP protocol number 255, so we should be safe here.
The library is a tiny library and includes some simple sample applications. Download on the downloads page. BSD licence on it. It's based on Sun's code, and their copyright also applies. Unpack the tar file, type make, and put the library and include file somewhere where you can use them.
For further info, contact