Tiny Tiny RSS: Community

Tt-rss.org's SSL configuration


I’ve been playing with my server’s SSL configuration and trying to learn by looking at other sites’ scores on SSL Labs.

Long story short: tt-rss.org gets a B and discourse.tt-rss.org gets an A+. A quick copy-paste of the configuration should fix that.

One thing that’s missing in the discourse site is support for Android 2.3 and Java 6, but I doubt anyone cares about those.


Considering the two sites are hosting completely different software, I seriously doubt a “quick copy-paste” is what is required…


That has never ever gone horribly wrong⸮ No sir safe as can be that is⸮


Sure, but they both use nginx in front of their respective software (at least, they both return Server: nginx header).


to be fair both terminate ssl via nginx

e: looks like it wants a custom dhparam

e2: should be better now



What does your ssl_ciphers directive look like? Just curious, seems like there are a lot suggestions out there.


i copypasted this off some website:


using the default should be fine on any recent enough distro, i think.


In the past I’ve used https://cipherli.st for this sort of thing and Qualys SSL Labs checker to make sure it’s all working.


Hmm… The nginx config seems very weird to me. The first cipher is ECDHE-RSA-AES256-GCM-SHA512 which doesn’t even exist according to IANA. They recommend TLS 1.3 but it’s still draft and not well supported by browsers yet. And no chacha20-poly1305?

If you want a sane configuration, use Mozilla’s generator: https://mozilla.github.io/server-side-tls/ssl-config-generator/

And since I started this thread, I’ll post my configuration when I get a chance (I’m on mobile now).


im seriously not sure this option is even necessary. one of the websites i run uses the default (debian 8) and sslabs says it’s grade A.


My actual config (A+ and works with all clients that support TLS 1.2):

ssl_protocols TLSv1.2;
ssl_ecdh_curve P-256:P-384:P-521;
#ssl_ecdh_curve X25519:P-256:P-384:P-521;

Few notes:

  • CHACHA20-POLY1305 and X25519 require OpenSSL 1.1 which I don’t actually have (I’m using CentOS 7), but I’m keeping them in my config files for the future.
  • the -ECDSA- suites require an ECDSA certificate. Let’s Encrypt supports them, but Certbot doesn’t (you can get one with a custom CSR, but renewing doesn’t work). Besides, the future seems to be EdDSA certificates. So I suggest skipping them unless you like to try things just because they’re there (I know I do).
  • DHE seems to be useless. All clients that support it also support ECDHE. With two exceptions: Android 2.3 and Java 6. And enabling it for Android 2.3 with >=2048 bits breaks Java 6… so if you really need Android 2.3 and Java 6, enable AES128-SHA:AES256-SHA without Forward Secrecy.

Just for fun: The ridiculous 100% config (useless in real life since many clients don’t support it, including Android 6.0):

ssl_ciphers ‘ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384’;
ssl_ecdh_curve P-384:P-521:P-256;


Mine looks like this:


Gets rated A+ by Qualsys, so ¯\_(ツ)_/¯


True, but I hate seeing these “WEAK” ciphers in the list.

And the defaults are probably fine too, but it was more of a learning exercise for me.