Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Cipherli.st got a big update, your help needed!
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Cipherli.st got a big update, your help needed!

As you might know I've created some SSL related websites, Cipherli.st is one of them. It has a copy-pastable secure configuration for the three major webservers (apache, nginx and Lighttpd) which provide a strong and secure SSL connection, including ciphersuite, key size, headers and such.

I've gotten many requests to also add config for other software besides the three webservers. I've finally made the jump and added config for the following software:

  • haproxy
  • MySQL
  • DirectAdmin
  • Exim
  • Dovecot
  • Proftpd
  • Postfix

I need your help however. I've tested all configuration of course, but I want you guys/gals to also test it. Just to make sure.

And I want pull requests for other software which can have SSL settings configured.

If you know of any or can test some configuration, that would be very nice.

Comments

  • Love it.

    Thanked by 1Raymii
  • I've test this on nginx, very strong A+. Good work!

    But for some legacy / specific browser I'm still using https://mozilla.github.io/server-side-tls/ssl-config-generator/

  • @Raymii I love your tutorials and from time to time I lurk at your site to refresh myself. Thanks for the awesome work.

    Thanked by 1Raymii
  • @vRozenSch00n said:
    Raymii I love your tutorials and from time to time I lurk at your site to refresh myself. Thanks for the awesome work.

    Thanks :D

  • TransNOCTransNOC Member
    edited December 2014

    Raymii,

    I am so deeply disappointed that your sites are not SPDY enabled. The 500ms it took to load your site felt like an eternity.

    • Brad
  • rm_rm_ IPv6 Advocate, Veteran
    edited December 2014

    Don't care about SPDY (it's not in Lighttpd yet, is it?), but others to whom I gave the link today have pointed out that the website is not even on IPv6. Guess can't be "state of the art" on all fronts at the same time?

  • rokokrokok Member
    edited December 2014

    SSL is slow, SPDY is the solution to make it faster on browser, almost major browser support SPDY now.

    Strong Ciphers also not good for seo, imagine google still use ssl3 because they afraid to loose traffic to make it works on all browser even old one.

    example https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96

  • RaymiiRaymii Member
    edited December 2014

    @TransNOC said:
    Raymii,

    I am so deeply disappointed that your sites are not SPDY enabled. The 500ms it took to load your site felt like an eternity.

    • Brad

    When it's enabled by default in NGINX I'll enable it.

    @rm_ said:
    Don't care about SPDY (it's not in Lighttpd yet, is it?), but others to whom I gave the link today have pointed out that the website is not even on IPv6. Guess can't be "state of the art" on all fronts at the same time?

    Raymii.org is IPv6 enabled, Cipherli.st not (yet), it is on DO in a DC without IPv6. Will look into that, maybe I can migrate it.

    @rokok said:
    SSL is slow, SPDY is the solution to make it faster on browser, almost major browser support SPDY now.

    Strong Ciphers also not good for seo, imagine google still use ssl3 because they afraid to loose traffic to make it works on all browser even old one.

    example https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96

    That comment makes no sense. SPDY has underlying SSL encryption. Furthermore, SEO is also bullshit, just as your comment.

    Also, if a website is available via HTTP and HTTPS, it doesn't matter since you can do a MITM downgrade attack to force http...

  • ben78ben78 Member
    edited December 2014

    rokok said:

    Strong Ciphers also not good for seo, imagine google still use ssl3 because they afraid to loose traffic to make it works on all browser even old one.

    Google try to minimise server CPU needed to have https. They don't care if it's strong or not - they want it to look good, and be as cheap as possible / with as little CPU overhead as possible as they handle billions of requests each day, and their goal is to make cash, not to be a privacy paradise...

  • rokokrokok Member
    edited December 2014

    its not bullshit comment, thats reality case, strongest ciphers not gonna compatible for some old browser for sure, people cant open the site, even low volume visitor still traffic!

    in the end, its all webmaster decision to pick the best solution ;p

  • ben78ben78 Member
    edited December 2014

    rokok said: in the end, its all webmaster decision to pick the best solution ;p

    Yes, and it depends the level of 'security' you need.

    An OK approach would be to use a strong cipher if possible, and if not switch to a less-good one, isn't it?..

    https://calomel.org/nginx.html 's config is an interesting read

    they choose to use:

    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-RC4-SHA;

    Explaining it that way:

    ssl_ciphers lists the ciphers in the order our server will negotiate. The server decides which cipher the client and server will use, so always list the strongest ciphers first. Notice in our string of ciphers we list the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) Perfect Forward Secrecy (PFS) ciphers first. Then, since some Redhat Linux machines do not support Elliptic Curve (EC) ciphers we included the TLSv1.2 Galois Counter Mode (GCM) ciphers and some AES 256 bit, SHA 256 bit ciphers afterward. We DO NOT recommend regular RC4-SHA, but your business may not want to deny access to your services for ancient clients like original smart phones or IE8 on Windows XP. The choice is yours, but we suggest never using RC4-SHA or ECDHE-RSA-RC4-SHA equivalent. The command "openssl ciphers -v 'ALL:@STRENGTH'" will show you all of the ciphers your version of OpenSSL supports. Our Guide to Webserver SSL Certificates explains many of the details about ciphers and compatibility models. Also, notice we did NOT include any Diffie-Hellman Ephemeral (DHE) or Triple DES (3DES) ciphers as they are six(6) to ten(10) times slower then ECDHE. Every millisecond counts.

  • ya thats the reason, since there is no universal ssl settings or ciphers, all depends.

    Cipherli.st provide the strong one, i can vouch that its great, but for custom solution better use https://mozilla.github.io/server-side-tls/ssl-config-generator/

    it will shows which software version you use, tweek and aditional option...

  • way too cool dude!

  • iceTwyiceTwy Member
    edited December 2014

    @rokok said:
    ya thats the reason, since there is no universal ssl settings or ciphers, all depends.

    Cipherli.st provide the strong one, i can vouch that its great, but for custom solution

    I stopped reading there.

    Your comment reminds me of a LibreSSL commit where one of the devs had a nice thing to say about OpenSSL:

    Remove this sentence: “The probability that a randomly generated key is weak is -1/2^52, so it is not really worth checking for them.”

    >

    This kind of naively optimistic attitude is not compatible with security.

    >

    — miod

    Pick one of the following: compatibility with shitty old software, security.

    Thanks for the update, Raymii!

  • i just want to say i love cipherli.st its so usful

Sign In or Register to comment.