1. 18
  1.  

  2. 6

    The fact this is plausibly useful is a sad comment on the state of software engineering.

    1. 2

      How would you describe the alternative desired state? That insecure protocols don’t exist? That engineers would have deeper knowledge of cryptography?

      1. 8

        Distributions of major server software would come with good configurations out of the box, alleviating every developer from being responsible for configuring things.

        https://caddyserver.com/ is a great example of this; you configure it to do what your app needs, all the TLS defaults are well curated.

        1. 4

          While I agree that a “reasonably secure default” should be standard, mostly you have to find a trade-off between security and compatibility. If you need support for IE8, there’s no way around SHA. If you want to support Windows XP or Android 2, there’s no hope at all. If you want it more secure (as of today) you fence out most Androids (but 4.x), Javas, IEs, Mobile Phones, non-up-to-date browsers. Unfortunately, there is no one size fits all.

          1. 3

            On the other hand, compatibility with older software is very easy to figure out (people see an error message), whereas insecure configuration appears to work perfectly fine. I also believe developers are more likely to know that they need to support some obsolete software (modern web development doesn’t “just work” on IE8 or Android 2) than about the newest TLS configuration options.

            1. 2

              I think if you want that, we ought to have APIs that express things in terms of goals, instead of implementation details: ssl_ciphers +modern +ie8 maybe. Then it’s clear what needs to be changed to drop a platform, instead of it being a guessing game.

              1. 2

                This would be great. This is exactly what I’m trying to provide the user with the snippets in nginx.vim: Choose between ciphers-paranoid, ciphers-modern, ciphers-compat, ciphers-low cipher suites.

      2. 4

        First thought: didn’t I see this in the new nginx vim-syntax posted here a while ago?

        Ah.. it’s by the same author.

        Nice work, ch4r. It helped me get rid of a couple I had in my 2014 nginx ssl config. Hat tip.

        1. 2

          Good catch :)

          sslsecure.vim is actually trying to get some of the security features from nginx.vim to work with other configuration files and source code as well.

          Good to hear it actually helped you re-securing your config!