File Relay vs. Encryption

When using File Relay in combination with encryption there are many things going on behind the scenes.

In this example, we will let The Base Agent 2 communicate with Frontend server 2. Frontend server 2 will relay all file requests to the inside of the DMZ to Frontend server 1 because it does not have access to a management server and therefore cannot serve any files.

Before the Base Agent, 2 can request or retrieve any files, it needs to construct an Authorization header. The Base Agent and Front-end server have two common Authorization formats; The x-capa-rsa and the x-capa-rsa-aes format.

Http requests/responses are built like this;

It consists of a header section and a body. The header section holds various information forth and back between client and server, such a format that the client can understand, a range of a file if only a part is required or an authorization header, used by the base agent to persuade the server into meaningful conversation authenticate itself.

The content is encrypted using the Front-end's 2048 bit public RSA key, which is requested on  http://server.domaincom:<port>/cifrontend/info. The result could look like this;

The first health bit is necessary for the base agent to engage in any further communication. It tells the base agent, that the service has the server running (arguably irrelevant, since the request was responded to), but also that the server does have an active SQL-connection, and that there are free threads available.

The next part is a signal to the base agent whether encryption of data (the body) is required on the port (with aes). 

Lastly, the public key is presented. This key is used to encrypt the header, and it ensures that only this Front-end server can decrypt it (using its private key)

Now that the client knows whether it should work with aes encrypted payloads (the body), it can construct the Authorization header.

If the encryption property was false, an x-capa-rsa authorization header will suffice. Otherwise, an x-capa-rsa-aes header must be supplied. Both header type contains the UUID of the client and a timestamp which is corrected for the possible time difference between the server and the client. In the case of encryption requirements, the client must include the two aes keys that;

• It has encrypted the body with (an upload)
• and/or it wants the server to encrypt the response with.

The UUID is matched against the SQL server and the timestamp is checked to be in a narrow interval (seconds). Because time changes, the content of the header is different every time, it is sent. This is an extra security measure because an authorization cannot be used twice.

After constructing the content of the header, it is encrypted with the public key.

So, back to the situation at hand:

The Base Agent 2 has constructed an authorization header, destined for Frontend Server 2 (FS2) in Verona. The FS2 decrypts the header with its own private key. If the request from the base agent was not a file, the server starts to check the header;

• Can a match be found in the SQL server?
• Is the time stamp recent?
• Has this exact header been used before on this server?
• If encryption is enabled on the port on which the request is received, does the request contain an x-capa-rsa-aes header.
• If the header is an x-capa-rsa-aes header, does it contain the two aes keys.
  
  

The response is then computed and returned to the client.

In the case, that this was a file request (up- or down-load) the request must be relayed to the inside of the DMZ to Frontend Server 1 (FS1). Because private/public keys come in pairs, the private key of the two servers is different. This means re-encrypting the header with the public key of the FS1 (on the inside of the DMZ) so that FS1 can decrypt the header with its own private key. To do away with timeouts in the network, the timestamp is refreshed before encryption.

After this, a new request is created with the same HTTP method as the Request that the server just received (GET, PUT, POST). Any headers on the initial request are duplicated into the new request. The body of the initial request is also copied into the new request, and the request is then sent off to FS1 which will detect the request as if it was coming directly from the base agent.

The FS1 decrypts the header with its own private key and starts to check the header;

• Can a match be found in the SQL server?
• Is the time stamp recent?
• Has this exact header been used before on this server?
• If encryption is enabled on the port on which the request is received, does the request contain an x-capa-rsa-aes header.
• If the header is an x-capa-rsa-aes header, does it contain the two aes keys.

These steps are an exact copy of the ones that FS2 just made (for non-file-requests).

• If the request is a PUT or a POST (upload), then the request is validated (the server path is held within the URL of the request), and the output stream of the request is then decrypted with the aes and hmac keys from the authorization header. The decrypted data is saved in the container corresponding to the point of the base agent, and a response is generated and returned with the right status code.
• In the case of a GET, the request is validated (again the server path is held within the url of the request) and the requested file is encrypted with the aes and hmac keys from the authorization while being copied into the body of the new response.

The new response (RS1) is then returned to FS2 where headers and bodies are duplicated into a new response (RS2). The new response (RS2) is then finally returned to the Base Agent 2 with the same status code as RS1.