This integration is currently not supported due to the end of life of oqs-openssl111. Feel free to vote this back into supported state by visiting the discussion on the topic.
This directory contains a Dockerfile that builds haproxy with the OQS OpenSSL 1.1.1 fork, which allows haproxy to negotiate quantum-safe keys and use quantum-safe authentication in TLS 1.3.
Install Docker and run the following commands in this directory:
docker build --build-arg SIG_ALG=<SIG> --tag oqs-haproxy-img .(<SIG>can be any of the authentication algorithms listed here). An alternative, simplified build instruction isdocker build -t oqs-haproxy-img .: This will generate the image with a default QSC algorithm (dilithium3 -- see Dockerfile to change this).docker run --detach --rm --name oqs-haproxy -p 4433:4433 oqs-haproxy-img
This will start a docker container that has haproxy listening for TLS 1.3 connections on port 4433. Actual data will be served via a load-balanced lighttpd server running on ports 8181 and 8182.
Complete information how to use the image is available in the separate file USAGE.md.
The Dockerfile provided allows for significant customization of the image built:
This permits changing the build options for the underlying library with the quantum safe algorithms. All possible options are documented here.
By default, the image is built such as to have maximum portability regardless of CPU type and optimizations available, i.e. to run on the widest possible range of cloud machines.
This defines the quantum-safe cryptographic signature algorithm for the internally generated (demonstration) CA and server certificates.
The default value is 'dilithium3' but can be set to any value documented here.
This defines the resultant location of the haproxy installation.
By default this is '/opt/haproxy'. It is recommended to not change this. Also, all usage documentation assumes this path.
This defines the haproxy software version to be build into the image. By default, this is an LTS version.
The default version set is known to work OK but one could try any value available for download.
Allow setting parameters to make operation, e.g., '-j nnn' where nnn defines the number of jobs run in parallel during build.
The default is conservative and known not to overload normal machines. If one has a very powerful (many cores, >64GB RAM) machine, passing larger numbers (or only '-j' for maximum parallelism) speeds up building considerably.