Skip to content

SSL (TLS) config set "old" no longer valid or applicable (OpenSSL 3.x onward) #303

@berndjkjp-web

Description

@berndjkjp-web

Mozilla org SSL Config generator and the connected wiki does not specifically acknowledge that we are
supposed to use OpenSSL 3.x - type TLS stacks ONLY since. There is urgent need for a general overhaul of
the content.

(in-support currently : Open SSL 3.5 LTS and the releases from/after 3.1 to 3.5)

OpenSSL 3.1 LTS is OUT of support, and also everything earlier.

OpenSSL 1.1.1 and everything earlier is also long out of support and also should be no longer selectable as an configuration option.
Just leave it away, out, for good. Using old TLS stacks always means leaving a server potentially insecure, unpatched, vulnerable
towards various attacks, unmitigated. Problems are left unpatched. "Backward compatibility" is no longer an option because
this is simply setting the wrong operational priorities. It is simply inadequate for servers facing the public internet.

OpenSSL 1.1.1 also still does NOT take care of the RFC 8996. (which deprecates old TLS protocols - to be considered mandatory).
which means these protocols are to be considered "dead". No longer to be proposed anywhere, not even optional)

Suites with RC4 and 3DES (EDE3_DES) : to be taken entirely out of use.
They are insecure and are already deprecated as per RFC 8429 - "Deprecate Triple-DES (3DES) and RC4 ...".
so we please refrain from proposing them. Everywhere. It is no longer existing. Also not along with TLS 1.2. For good.

So we do please not use and also not recommend these old stack versions and oldstyle-configurations anymore. Nowhere.

Why this is important - and we are supposed to look forward only in the wake of today's security requirements :

Standard compile level is 2 (this means we comply with RFC 8446 and RFC 8996 very strictly, which means "by design")
OpenSSL 3.1 LTS and onward is at least observing these two RFCs strictly and by default.
Also for TLS 1.2, as the RFC 8446 applies to it since, obsoleting the original RFC for TLS 1.2 !

  1. configuration Syntax related :
    SSLProtocols does not need any parameters anymore to have TLS1.3 and TLS1.2 enabled, it even can be left out entirely.
    Enabling TLS via SSLEngine on is enough in fact to have both protocols enabled by default with the default set of ciphers.
    The only purpose of this option to be used is to exclude one of these protocols in specific use-cases.

  2. concerning the config option : "old configuration". This does longer exist in reality anymore for OpenSSL 3.x stacks.
    It is obsolete. Deprecated.
    Because RFC 8996 is being observed by design (in compile level 2 strict, even in compile level 0 by default) :

    In a standard complile (Level 2) version of OpenSSL 3.x :
    SSLProtocols alone can NOT be used to re-enable old TLS protocols. This is no longer supported in standard compiles
    of OpenSSL 3.x (the "legacy provider" is disabled here, and enabling it only works in level 0 compiles and implies
    many other additional configuration options to be set to intentionally re-enable old TLS protocols and ciphersuites !)
    OpenSSL3 only enables ciphersuites which are still allowed in RFC 8446 by default.

    Syntax-related:
    ciphersuite inclusions (old/legacy ciphers) will not work. Cipher exclusions (for old/legacy ciphers) also unneeded here.

  3. MODERN configuration should - if you want it to be most secure and up-to-date
    only use the following ciphersuite definition (applies to TLS 1.2 specifically) : DEFAULT:!SHA:!kRSA:!CBC:!DHE

    For the "intermediate" config I recommend to just use OpenSSL 3 defaults here.
    ensuring proper and performant handshake. Which offers elliptical handshake exclusively, but is allowing modern ciphermodes only.
    Also from my standpoint, finite-field DHE - nonephemeral - is to be announced off. No longer recommended. Vulnerable from the
    point of view today where attackers & adversaries have large bandwidths accessible. DHE is time-consuming.
    So says IANA as well (DHE is "weak").
    Also seeing the draft which is long underway already to abolish all old handshake mechanisms altogether in TLS 1.2

  4. HSTS should cover the entire domain to be actually effective on the whole domain (all existing subdomains) for which it is meant to be
    not only the server's single subdomain. The parameter for covering subdomains should be recommended.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions