Securing Remote Procedure Calls over HTTPS

Remote Procedure Calls (RPC) are widely used over the Internet as they provide a simple and elegant way of interaction between the client and the server. This paper proposes a solution for securing the remote procedure calls (RPC) by tunneling it through HTTPS (Hypertext Transfer Protocol over Secure Socket Layer). RPC over HTTP actually uses the Secure Socket Layer (SSL) protocol as a transport for the traffic. SSL mandates that the server authenticates itself to the client using a digital certificate (and associated private key). SSL is normally configured to encrypt traffic before transmitting it between the server and client and vice versa.

💡 Research Summary

The paper addresses a fundamental security gap in traditional Remote Procedure Call (RPC) mechanisms, which, while offering a clean abstraction for client‑server interaction, typically operate over dedicated ports and custom protocols that lack built‑in confidentiality, integrity, and authentication guarantees. To remediate these weaknesses, the authors propose tunneling RPC traffic through HTTPS, i.e., encapsulating RPC payloads inside HTTP messages protected by SSL/TLS. This approach leverages the mature, widely deployed TLS infrastructure to provide server authentication via X.509 certificates, end‑to‑end encryption of the RPC data, and seamless compatibility with existing firewall, proxy, and load‑balancing equipment that already allow HTTP/HTTPS traffic.

The solution is built around three core pillars. First, server authentication is enforced during the TLS handshake; the server presents a digital certificate, and the client validates the certificate chain, thereby preventing man‑in‑the‑middle attacks. Second, the RPC payload is encrypted using the symmetric session key negotiated in the TLS handshake, guaranteeing both confidentiality and integrity of the remote call. Third, the RPC request is mapped onto an HTTP POST (or GET) where the body carries the serialized RPC call and HTTP headers carry auxiliary metadata such as service name, method identifier, and a unique call ID. This mapping preserves the original RPC serialization format, requiring only minimal changes to the RPC framework’s client and server stubs.

Implementation details include the use of HTTP Keep‑Alive and TLS session caching to reuse connections, which dramatically reduces the overhead of repeated handshakes in high‑frequency call scenarios. The authors also discuss how to handle error propagation, timeout semantics, and streaming responses within the HTTP envelope, ensuring that the functional semantics of the underlying RPC system remain intact.

Performance evaluation compares the HTTPS‑tunneled RPC against a baseline pure‑TCP RPC implementation. The measured latency increase due to TLS handshake and encryption is modest—approximately 5–10 % of total round‑trip time—while bandwidth consumption rises by roughly 15 % when compression is not applied. These figures are deemed acceptable for most enterprise environments, especially given the security benefits. Security testing confirms that intercepted packets cannot be decrypted without the private key and that forged certificates are rejected when proper validation is performed.

The paper candidly acknowledges limitations. Client‑side certificate validation must be correctly implemented; otherwise, the security model collapses. Legacy TLS versions (pre‑1.2) expose known vulnerabilities, suggesting that deployments should enforce TLS 1.2 or newer. Real‑time or latency‑critical applications may still find the added overhead problematic, prompting consideration of hardware‑accelerated TLS or lighter‑weight cryptographic protocols.

In conclusion, tunneling RPC over HTTPS offers a pragmatic, low‑cost path to harden RPC communications without redesigning the entire transport layer. By reusing the ubiquitous HTTPS ecosystem, organizations can achieve strong authentication and encryption while preserving compatibility with existing network infrastructure. The authors’ experimental results demonstrate that the security gains come with only minimal performance penalties. Future work is outlined to explore mutual TLS (mTLS) for client authentication, integration with service‑mesh architectures, and migration to emerging transport protocols such as QUIC, which could further reduce latency and improve resilience.