Establishing a community working group for ssl-config-generator

[gene1wood]

I'm @gene1wood . I work in the Security Assurance team at Mozilla. I first created the SSL Config Generator in 2014 and my colleague @april rewrote it from scratch in 2019. I've been the maintainer of it since 2020, but haven't had success at getting support for dedicating more time in my day job to it. As a result, response to issues and merging of PRs has been slow.

I've proposed to Mozilla management exploring if establishing a community working group to take over maintenance of the project would work and have gotten approval for doing so.

Here's what I'm envisioning

• Establish a governance model and capture that in the repo
• Identify community members that have an interest in maintaining the project
• Get those folks setup as Mozilla community members and added into the Mozilla NDA group (not that I can imagine any need for sharing non-public information, but just to make it easier to communicate)
• Grant those community members write access to the repo which will enable them to merge PRs, make changes to the code and see those changes automatically deployed to https://ssl-config.mozilla.org/
• I stay on with admin rights to grant community members write access

My question to the community

This all depends on there being any community members that have an interest in contributing to the SSL Config Generator project. I think that this is the case but could be wrong. I'd like to find out if this sounds like a good idea to those folks that have already contributed to the project :

• @april
• @mholt
• @Manawyrm
• @simonkrenger
• @sonicdoe
• @IAmATeaPot418
• @crispygoth
• @gstrauss
• @FiloSottile
• @fabiopozzi
• @bokub
• @IceCodeNew
• @wevsty
• @jax7778
• @nmxcgeo
• @JGoutin
• @rugk
• @HLFH
• @janbrasna

Do any of you, previous contributors, have an interest in stepping into a role as a maintainer for this project? I'm hoping that a few people would have an interest in helping out.

This would involve

• Addressing issues that are opened in the repo
• Reviewing PRs and merging, requesting changes or rejecting them
• Setting project direction
• Deciding on the governance model (I'm happy to do the work on this and bring you options)

Motivations that I can imagine are

• you use the SSL Config Generator and want it to work well
• you maintain one of the servers that the generator creates configurations for and want to ensure that those configurations are up to date
• you maintain systems or documentation that references or depends on the SSL Config Generator and you want to make sure it continues as a useful tool
• you care about ensuring that good web security is accessible to everyone, including those not technically savvy enough to determine the most secure configuration for their server

[JGoutin]

Hello,

I am interested in maintaining this project.

[gstrauss]

I am also interested in being one of the maintainers of this project. (The more qualified contributors, the merrier. 😄 )

[janbrasna]

I'd also like to kindly loop in @tomato42, @jvehent or @rgacogne who authored the foundations back in the day when this was part of @mozilla/server-side-tls as their TLS knowledge could be very beneficial for reviewing any upcoming changes, or the direction towards the future of the config generator and/or the recommendation JSONs it's based upon.

There are others who've engaged with the project in the past as @szepeviktor, @thestinger or @polarathene who might not have added any actual lines of code to the configs, but have shown great understanding of the real world interoperability (in tricky domains as mailservers — that honestly need some serious improvement here) which is also needed to keep the configs relevant in 2024 and on…

[polarathene]

TL;DR: Thanks for the ping ❤️ While I can't afford to take on new commitments, I have shared some insights below that might assist future maintainers 👍

---

or @polarathene who might not have added any actual lines of code to the configs

At a glance, my engagement within the projects was fairly low:

• https://github.com/mozilla/ssl-config-generator/issues?q=commenter%3Apolarathene
• https://github.com/mozilla/server-side-tls/issues?q=commenter%3Apolarathene

mozilla/server-side-tls does have two comments with plenty of reference links cited for cipher suite compatibility. Not sure if they're that useful in 2024+ though 🤷‍♂️

---

At the time I was doing quite a bit of research to extensively document cipher suite compatibility and an appropriate selection for securing mail servers with (since client/server support lags behind browsers). I never found time to complete the document and publish it, but was quite close to completion IIRC. I shared a portion of it following this Dovecot/Postfix config audit comment.

I still have that WIP document on disk but it'd be a little out of date since it's been untouched for over 3 years 😓

• RHEL6 will end it's extended support later this year AFAIK.
• Other software compatibility concerns with Windows / IE I believe is already EOL.
• I recall the official macOS mail client lacking TLS 1.2 support (should be covered better in my old WIP doc among other clients).
• Some users still have devices / clients active that depend on TLS 1.0/1.1 for connecting to mail servers, but simply configuring the software to support these deprecated (since March 2021) versions of TLS can be insufficient if the server software depends on an external dependency like OpenSSL, which must be configured as well (for OpenSSL, I believe the 3.0 release also adjusted the required security level to be set a notch lower).

---

needed to keep the configs relevant in 2024 and on…

I don't have much insights on what the current state of TLS is like, but imagine many connections are TLS 1.3 these days or capable of using AEAD ciphers from TLS 1.2?

Apart from accommodating changes like those I mentioned above, it'd be interesting to know more context for the client connections that need broader cipher support. They tend to be devices or deployments that cannot be easily updated but still relied upon, yet often within the context that they could probably leverage a proxy to mediate a secure connection for their server/client rather than lowering than lowering security on the other end.

That is a different context than what was traditionally a concern with servers needing to support a wider demographic of clients. The latter, especially with web browsers becomes less relevant as their CA trust store expires (as has been the case for smart TV products around a decade old), more so when the user cannot update that to verify certificate trust.

---

On the topic of TLS certificates and context:

• I think this project may prefer to follow the guidelines/advice from organizations on key length/size, as it's easier to satisfy compliance policies.
• I sometimes see less experienced users advocating for excessive security (like 4096/8192 bit RSA often misunderstood as only 2-4x in strength of RSA-2048, or misunderstanding how impractical quantum attacks are resource-wise). I have discussed the details of entropy a few times over the years for why 128-bit symmetric strength is plenty (and for RSA or DH parameters, 2048-bit modulus / 112-bit symmetric is still quite solid due to cost). While maintainers here likely understand these details already, it may be helpful for referring contributors to that do not.

---

you care about ensuring that good web security is accessible to everyone, including those not technically savvy enough to determine the most secure configuration for their server

I do, and have invested a significant amount of time towards being informed so others do not need to worry about such as much 👍

Do any of you, previous contributors, have an interest in stepping into a role as a maintainer for this project

Despite my interest in security I unfortunately need to avoid taking on any new commitments.

• I'm trying to step away from these responsibilities already as I've been serving the open-source community for about 5 years now and I can't sustain that financially for much longer 😓
• I do hope the information I've provided above can be helpful to those that do step up as new maintainers. Once my OSS commitments start to settle down, if anyone is interested in the document I was working on in 2020 I can look into digging that up, but I get the impression with each year passing it becomes less relevant.. 😅

[IAmATeaPot418]

I would love to help out maintaining this as well!

[IceCodeNew]

I am also interested in being one of the maintainers of this project.

[gene1wood]

@JGoutin @gstrauss @janbrasna @IAmATeaPot418 @IceCodeNew
Thank you for speaking up!

Jérémy, Glenn, Jamie, I'll email you directly, see if we can coordinate a time to chat/video conference and meet each other, chat about a plan.

@IceCodeNew and @janbrasna, would you email me with your preferred email address and your full name so we can start the conversation? You can reach me at gene at mozilla.com

I'll close this issue for the time being, but may open it later if we want to look for additional folks who are interested.

I'll also make sure to comment here and to update the repo documentation with the maintainer plan once we have it.

[gene1wood]

@janbrasna I still need you to email me. Would you do so? gene at mozilla.com

[gstrauss]

@gene1wood would you please briefly update on status? Thanks.

[gstrauss]

@gene1wood would you please briefly update on status? Thanks.