keter-hosted ssl websites fail ssl labs tests -- allow more control over warp-tls from keter config

[jgreve-github]

reference for a demo project:

https://www.ssllabs.com/ssltest/analyze.html?d=phreeknet.de&hideResults=on

Yes, since the website's certificate is signed by CACert and thus not trusted by ssl labs, the test will never be passed; yet all other issues are a keter or warp-tls problem, I think.

[creichert]

Can you outline each issue you are interested in discussing here? I see the errors on the ssllabs site but I think they should specifically be mentioned here for discussion.

[jgreve-github]

Okay then:

• This server is vulnerable to MITM attacks because it supports insecure renegotiation
• This server accepts the RC4 cipher, which is weak.
• There is no support for secure renegotiation.
• The server does not support Forward Secrecy with the reference browsers

[creichert]

This server accepts the RC4 cipher, which is weak.

This could be modified here but I'm not sure of the implications:

https://github.com/yesodweb/wai/blob/master/warp-tls/Network/Wai/Handler/WarpTLS.hs#L133

[creichert]

I see two primary issues here:

1. This server is vulnerable to MITM attacks because it supports insecure renegotiation
2. The server does not support Forward Secrecy with the reference browsers

It might help if we can find any existing issues in WAI or Keter which reference these issues.

[snoyberg]

@vincenthz commented on some of this previously at: https://github.com/yesodweb/wai/issues/297. Overall: these issues are not really in Keter at all, but in the tls and warp-tls packages, which is probably a more direct place to file such issues.

[jgreve-github]

@snoyberg, @creichert, https is always tricky; to allow for maximum security in a server, some clients might have to be excluded from the service. Thus, warp-tls should offer appropriate configuration options to let the administrators of the instance decide and control respectively, maybe use optimal settings as default.

Besides that, keter using warp-tls should expose those settings as well, as to allow users to modify warp-tls's settings without hacking it into the keter source where the warp instance is launched.

I suspected that warp-tls and tls allowed such configuration and only keter didn't allow configuration; if that's not the case, another issue within the warp-tls repo might be of need?

[snoyberg]

If this issue is actually becoming "allow more control of warp-tls settings from keter," I'm definitely in favor of such a change. But I don't want us to confuse two completely separate points. If there are security vulnerabilities with warp-tls or tls, then they should be addressed in those repos.

[jgreve-github]

@snoyberg, you might be more qualified to decide whether this is a warp-tls or tls problem or both and create an appropriate issue. I will modify this issue accordingly.

[creichert]

I made a brief mention for something like this in the "Features Wishlist" area of the wiki. My preference would be to model nginx where we can:

To get the ball rolling, should we add new options to the keter-config.yaml?:

    - host: "*4"
      port: 443
      key: key.pem
      certificate: certificate.pem
      protocols:  TLSv1 TLSv1.1 TLSv1.2
      prefer_server_ciphers: True
      ciphers 'AES128+EECDH:AES128+EDH:ANOTHER_CIPHER'

These should map almost directly to the Warp TLS options (https://github.com/yesodweb/wai/blob/master/warp-tls/Network/Wai/Handler/WarpTLS.hs#L105-L135).

Those parameters should fix the RC4 warning for those who want to configure that way.

Now, for Forward Secrecy we would need an option like:

dhparam /etc/ssl/certs/dhparam.pem;

@snoyberg Does WarpTLS support forward secrecy yet?

[snoyberg]

I'm in favor of some kind of settings like you describe. I have no idea about forward secrecy, I haven't followed up on TLS capabilities.

[creichert]

Do you think the ssl settings should have their own block or be set on a per-host basis like above?

Forward-Secrecy might require support in warp-tls. I'll look into a bit and open an issue there if needed.

@jgreve-github Is there anything here you would want to help code?

[snoyberg]

We could do SSL settings in both ways: have a "global" set of settings and then allow each host to override. I'm not sure if that's something anyone would ever care to do though.

[jgreve-github]

@creichert, thanks for the offer :) Yet, I'd be of no help, since my coding time is extremly limited and my haskell production experience is almost zero.

[tolysz]

There is a growing number of SSL related settings, I would suggest merging them under some common config.

- host: "*4"
  port: 443
  ssl:
    - enabled: true
      required: true
      certificate: cert.pem
      key: cert.pem
      ca_chain:
            -L1.pem
            -L2.pem
            -L3.pem
      protocols:  TLSv1 TLSv1.1 TLSv1.2
      prefer_server_ciphers: True
      ciphers: 'AES128+EECDH:AES128+EDH:ANOTHER_CIPHER'
      dhparam: /etc/ssl/certs/dhparam.pem

[tolysz]

Just to update on the issue. I added support for SNI (PR: https://github.com/snoyberg/keter/pull/144 ) until we have late sni checks (PR: https://github.com/vincenthz/hs-tls/pull/147 ) the ciphers from main certificate needs to be a superset of those added via SNI server hooks.

   # ssl: true
      ssl:
        key: /opt/keter/etc/cert/hello.key
        certificate: /opt/keter/etc/cert/hello.crt
        chain-certificates:
          - /opt/keter/etc/middle.crt
          - /opt/keter/etc/root.crt

Which is extending stanzas (currently only webapp); i.e. if we say simply true the main cert is used; but if we add cert details as above the new specified will be used. This requires some work: make cert paths relative; lookup star nested cets; etc..

I have basic a DH.Param implementation, hope to add PR for that soon; Just need to think on how configuration should look like. Basic one will be to generate prime where we only specify how many bits; the more advanced once will be reading (saving) prime from/to file.

dh-params:
   prime-bits: 2048
   generator: 2
   # file: "dhprime.bin"
   #auto-reload: true
   #auto-save: false

The last 2 options would be useful in multi-Instance.

And will be looking into SSL sessions (to start with keter running as a single instance). I am still looking into how I want to configure it. Basic option is to use memory cache eg:

ssl-session:
   mode: single-instance
   backend: memory