Is is possible to apply custom encryption to Microsoft Web API?

Question

We are using Web API 2.0 to serve clients in a context where SSL can't be used (no public internet access, clients can't be expected to trust a self-signed certificate). To secure content moving between the client and server, we'd like to be able to encrypt it. We're OK with un-encrypted HTTP headers (only need to encrypt payload). The question is: is there a way to insert a custom handler into both the request and response message pipelines so that we can apply a decryption as a request pre-processing step and an encryption as a response post-processing step?

We are using the built-in features of Web API to serialize/de-serialize between JSON and model classes, and don't want to have to refactor any of that existing code. So an encryption handler would have to be inserted at the very start/end of the request/response pipeline. Is this possible, and if so, what is the technique to insert custom request/response content pre/post processing?

The network is "public" in that users bring their own devices, but the network is isolated from the public internet. Clients will only use a custom application we are developing to consume our Web API service, so we can address implementation issues of a custom encryption scheme on both client and server side.

Answer 1

If you control the client application, you can hard-code the SSL certificate that the server is expected to return, which means that it doesn't have to validate through the normal PKI means (sometimes called certificate pinning ). Most other approach will result in you attempting to re-invent SSL, but with some fatal flaw.

To be explicit, I think you are seeing a conflict between "a context where SSL can't be used (no public internet access, clients can't be expected to trust a self-signed certificate)" and "Clients will only use a custom application we are developing" where one doesn't necessarily exist. The user doesn't have to know that the certificate is self-signed, and self-signed does not always imply untrusted.