Introduction to the Redwax Server
Over time, a significant number of protocols, technologies and mechanisms have been developed in the security landscape, and security has become more difficult than it needs to be.
One common thread has emerged with many of the security technologies - they all rely to some extent on the World Wide Web and HTTP protocol for their design.
Many of the available security products have been built to serve a very particular security niche, and when the need does not quite fit the product, security can be difficult to deploy. Many of the available products have been built with an extensive set of features. When those features are not needed, it can be very difficult and expensive to navigate around unwanted features to deploy just the needs you have.
The Redwax Server attempts to bridge these gaps by allowing you to understand, configure and deploy as much or as little of the server as you require.
The Redwax Server Is...
The goals of the Redwax server.
Modular
The Apache HTTP Server has very similar goals to Redwax, in the webserver space. Many webserver products have been built to serve a particular niche, however Apache's modular architecture allows you to just deploy the parts of the server you need, while physically removing the parts that you don't.
As a result of these common goals, Redwax Server has been implemented as an extended set of modules for the Apache HTTP Server.
What You Need and No More
It is time consuming and overwhelming to be presented with features and capabilities that go beyond what is needed.
Deploy the features you need, and ignore the features you don't. If you don't load the module, the feature will not exist.
Hardened
You cannot hack what isn't there.
Through the modular architecture of both Apache HTTP Server and the Redwax Server modules, you are able to deploy the modules you need, and ignore the modules you don't.
Sanitised
Inputs are passed as standard X509 Certificates and Certificate Sign Requests.
As a result, all inputs are correctly escaped and unescaped as required before being passed on to the next component in the system.
Where do certificates come from, and how do they get here?
Choose a frontend, pair it with a backend.
Backend Modules
Certificates can be generated in a host of different ways.
Certificates might be generated immediately, or might be generated after some time has passed, including with human intervention.
Certificates might be signed by a key local to the machine, or might be signed by a hardware device like a smartcard.
Redwax Server gives you backend modules to pick and choose the behaviour you are looking for.
Frontend Modules
Certificates can arrive at the client in a number of different ways.
The client might generate a public / private key pair, and then send proof of possession of the private key to the server using protocols like the Simple Certificate Enrollment Protocol (SCEP), Signed Public Key and Challenge (SPKAC), or the delivery of a Certificate Sign Request.
The client may choose alternatively to allow the server to generate the public / private key pair for the client, and deliver both together in a PKCS12 bundle.
The client may need to take advantage of additional services, like the serving of a Certificate Revocation List, or the verification of a certificate via the Online Certificate Status Protocol.
Redwax Server gives you frontend modules to pick and choose the behaviour you are looking for.