RPC over HTTP

What is Remote Procedure Call over HTTP (RPC over HTTP)?

Remote Procedure Call over HTTP (RPC over HTTP) is a Microsoft protocol that enables Microsoft Outlook clients to access Microsoft Exchange servers over HTTP. It is used to communicate RPC traffic over an HTTP connection.

Through RPC over HTTP, RPC clients can efficiently and securely connect to RPC server programs across the internet and execute Remote Procedure Calls. The client and server communicate through an RPC Proxy which functions as an intermediary.

RPC over HTTP explained

For most internet browser applications, HTTP is the primary means of accessing and browsing the world wide web. Microsoft uses HTTP to extend the capabilities of its Internet Information Server (IIS) to enable remote procedure call services via the RPC over HTTP protocol.

RPC clients can execute procedures provided by server programs on remote networks with the help of the RPC Proxy, which runs on an IIS server. It executes the following procedure calls:

• accepts RPC requests coming from the internet;
• performs various checks on these requests, including access, authentication and validation;
• forwards the request to the RPC server for processing if the request passes all tests; and
• sends the server's replies back to the client application across the internet.

The RPC over HTTP protocol uses two long-lived HTTP connections: one for request data and another for response data. The protocol can tunnel multiple requests and responses in a single HTTP request.

The need for RPC over HTTP

RPC over HTTP plays a key role in connecting an authorized Outlook user outside the corporate network (i.e., a remote user) with the internal Exchange server. To establish this connection, the client accesses a reverse proxy (e.g., WebSEAL) using an HTTP connection.

The connection terminates inside the network and a configured IIS relays the RPC commands to the Exchange server. This allows the remote user to access the internal Exchange server.

How RPC over HTTP works

The goal of RPC over HTTP is to allow client programs to effectively execute procedures provided by server programs on remote networks using the internet. The protocol accomplishes this by tunneling its calls through an established HTTP port, which allows calls to cross network firewalls across both client and server networks. The RPC proxy on the RPC server's network plays an important role in enabling remote access and remote procedure execution.

Here's how the process works:

1. The RPC client executes a remote procedure and routes the call to its network firewall/proxy.
2. This network firewall/proxy sends the remote procedure call to the RPC server's network over the internet.
3. The RPC server's network firewall receives this remote procedure call.
4. When the call is received, the network firewall transfers the call to the IIS server.
5. The IIS server sends the call to the RPC server.
6. The RPC server executes the call and sends a reply to the IIS server.
7. The IIS server sends the reply to the network firewall.
8. The RPC server's network firewall forwards the reply to the client network over the internet.
9. The client's firewall/proxy receives the reply.
10. The client's firewall/proxy transfers the RPC server program's reply to the RPC client application, completing the cycle.

If either the server or the client gets disconnected, the RPC Proxy detects it and terminates the RPC session. If the session continues, the RPC Proxy will:

• maintain its connections to the client and the server;
• forward remote procedure calls from the client to the server; and
• send replies from the server to the client.

If the client network has a firewall, a proxy server program such as Microsoft Proxy Server is required for RPC over HTTP to operate.

Versions of RPC over HTTP

Microsoft offers two versions of RPC over HTTP: Version 1 and Version 2, which have different capabilities and limited interoperability.

Version 1, or RPC over HTTP v1, is supported through Windows XP. Version 1 of the RPC Proxy is supported through Windows 2000. To use this protocol, SSL tunneling must be enabled on all HTTP proxies/firewalls between the RPC over HTTP client and the RPC Proxy. Also, v1 cannot authenticate to the RPC Proxy.

Version 2, or RPC over HTTP v2, is the current version of the protocol. It doesn't require SSL tunneling to be enabled on all HTTP proxies/firewalls between the RPC over HTTP client and the RPC Proxy. Additionally, it can send all RPC over HTTP traffic within an SSL session and requires authentication to the RPC Proxy by default.

Another difference between the two versions is how the RPC Proxy operates in a web farm. If the RPC Proxy v1 is installed on an IIS machine that is part of a web farm, it will not operate correctly. RPC proxy v2 operates correctly.

Security in RPC over HTTP

In addition to standard RPC security mechanisms, RPC over HTTP provides the following types of security:

• IIS authentication;
• traffic encryption; and
• restricting RPC over HTTP calls to certain devices.

These additional security features ensure that RPC over HTTP traffic is protected both by RPC and the protocol's tunneling mechanism. It is this tunneling mechanism that provides double-layered security to standard RPC security by:

• leveraging the authentication mechanism of IIS (for RPC over HTTP v2 only);
• encrypting traffic between the RPC over HTTP client and the RPC proxy with SSL (for RPC over HTTP v2 only);
• ensuring that the RPC proxy cannot access the data being sent; and
• restricting RPC Proxy levels and limiting which machines on the server network can receive RPC over HTTP calls.

See also: Outlook Anywhere, gRPC, SOAP, Network Information System