How would I implement customer DH parameters for DHE ciphers

[df-mreidel]

I'm asking upfront before creating a pull-request. We need to pass in custom DH parameters by supplying ssl_dhparam <file> to the nginx config. I could create a patch that simply supports setting ssl_dhparam and it would then require the user to make sure he mounts <file> into the container at the given location.

On the other hand, you might prefer that the value to ssl-dhparam/nginx.org/ssl-dhparam is not a filename, but rather the name of a namespace/secret and we look for the key dhparam.pem - very much like certificates are handled right now. So let's explain by examples.

Variant 1: filename

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress
  namespace: kube-system
data:
  ssl-dhparam: ciphers/dh4096.pem

And then mount that file to /etc/nginx/ciphers/dh4096/pem in the DaemonSet or Deployment

Variant 2: reference to a secret

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress
  namespace: kube-system
data:
  ssl-dhparam: kube-system/dh-params

apiVersion: v1
kind: Secret
metadata:
  name: dh-params
  namespace: kube-system
type: Opaque
data:
  dhparam.pem: ABC==

The second variant would require the controller to automagically create the file from the reference, but it would also allow for a seamless update of these parameters - for whatever reason.

Of course variant 1 is easier to implement, so I would like to know, which version you prefer?

[pleshakov]

It'd be great if you could implement the Variant 2!

For future extensions that support similar directives that require a file, we can have a similar approach deploying the file in a Kubernetes resource and we can reuse this implementation.

It makes more sense to me to deploy a dh-params file in a ConfigMap resource, since this file is not secret.

[df-mreidel]

Referencing a ConfigMap from inside a ConfigMap seems rather unnecessary. Shall I then treat the value as the content of the file to write? Like this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress
  namespace: kube-system
data:
  ssl-dhparam: |
    -----BEGIN DH PARAMETERS-----
    ABC==
    -----END DH PARAMETERS-----

Are you really sure dhparams don't need to be kept secret?

[pleshakov]

@df-mreidel

Referencing a ConfigMap from inside a ConfigMap seems rather unnecessary. Shall I then treat the value as the content of the file to write?

I like referencing a ConfigMap for the following reasons:

• Typically a ssl-dhparam file is ~2KB, so putting it in a separate Configap doesn't clutter the main ConfigMap
• I assume we'll have more features in the Ingress controller that need to reference a file. If we don't embed files inside the ConfigMap, we won't end up with one big ConfigMap.

However, embedding a ssl-dhparam in the main ConfigMap is easier and can be a temporal solution.

Are you really sure dhparams don't need to be kept secret?

Yes

[thetechnick]

@pleshakov
I would like to add this together with other settings needed for perfect forward secrecy.
This would include these nginx directives:
ssl_protocols,ssl_prefer_server_ciphers,ssl_ciphers and ssl_dhparam

Configmap

data:
  ssl-protocols: TLSv1 TLSv1.1 TLSv1.2
  ssl-prefer-server-ciphers: "true" #default false
  ssl-ciphers: >
    EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
    EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4
    EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !MEDIUM"
  ssl-dhparam-file:
    -----BEGIN DH PARAMETERS-----
    ABC==
    -----END DH PARAMETERS-----

For now I would also add the dhparam content as a string here.
If we need the functionality to use references to other configmaps/secrets for other configs too, we can add a new option ssl-dhparam: default/dhparam or similar.

[pleshakov]

@thetechnick looks good!