Security Policies

(Ben Kochie) #1

Hello Caddy Developers,

I’m part of the Prometheus Team, we have a long standing policy for “not doing security”, because we have a very small team, and getting security “right” is difficult.

We’ve been having some internal discussions about changing this policy, and officially supporting TLS with some authentication as a recommended way to secure communication between the Prometheus server and metrics targets.

I was wondering if there was anyone on the Caddy team that deals specifically with security issues that would be willing to chat about your policies.

Thanks,
Ben Kochie
Prometheus Team

1 Like
(Matt Holt) #2

Hey Ben,

Myself, Cory, and some of the contributors wear many hats in this project. :slight_smile: So you can ask here if you’d like.

If you’re just looking for a decent TLS configuration to use, Caddy’s defaults are pretty sane for most things. If you need two-way authentication at the connection level (which is awesome when it works), you can set up TLS client auth so the clients must present a key to the server as well as the server presenting a key to the client.

Anyway, I commend you for considering security!

Letsee, and I know that @miekg has experience with Prometheus specifically.

(Ben Kochie) #3

Thanks,

What we’re mostly discussing is policy related.

How to deal with upstream security issues?
How do you communicate issues with users?
How do you deal with patching previous releases?
What timeframes do you consider to implement changes to TLS features? New protocols, removing insecure ones, cipher combinations?
Do you allow users to even change the defaults for some TLS features?

The technical pieces are pretty easy to solve, the documentation and communication issues are things we’re still thinking about.

(Matt Holt) #4

Good questions, they’re very general – here’s my (unofficial) recommendations. I’m still gaining lots of experience with these kinds of things, so take these at face value (“use at your own risk” kind of thing). But if nothing else it might be something to think about or consider more deeply.

I’m not really sure what you mean by this; but if you find a vulnerability, typically disclose it privately until it’s fixed and deployed (if applicable). If you are talking about the other way around, be conservative when taking on new dependencies – you get code for free, yes, but you also are taking a risk that the upstream library might stop being developed or be found to be vulnerable or even compromised (owner’s password is guessed and doesn’t have 2FA, etc.). If worse comes to worst, fork the upstream, fix it yourself, and update your own software. Either that or find a different dependency that doesn’t have the same problem and switch.

Do it at the right time: make sure you know as much about the issue as you can. Be real. Make the length of the communication proportional to the severity of the issue. If you produce a 5-page writeup about something that’s not a big deal or only affected ~1% of users, there might still be technical value there, but it might also scare a lot of people unnecessarily.

As in, how do you encourage people to update? Do your best to communicate the new version is available and why people should update (without overreacting of course). A casual, but professional, tone is more approachable and will intrigue more people and invite them to update. I think auto-update mechanisms (like what browsers have), when done properly, have extreme value here. But they’re hard to do right. I maintain a mailing list with basic information about updates and always refer people to the full release notes. (Also, pre-1.0 might be different than post-1.0; with pre-1.0 I expect people to always read release notes. And I try to communicate that. Post-1.0, users should be able to trust that 1.1.2 -> 1.1.3 won’t break them.)

With Caddy, we adopt new protocol versions as soon as possible for their security and performance merits. If they’re not yet stable or totally reliable, we make them opt-in (like QUIC currently is). We remove old/broken ones immediately and without regard for old clients. It’s harsh, but hitting the ground running like this we might be able to pull it off. We do keep some selected old cipher still available if users really want to enable them, but we discourage it in the docs… you kind of have to find the right balance. Even post-1.0, I’m betting our compatibility guarantee will make an exception for security protocols.

Nope, in Caddy, some TLS features can’t be changed by the user. For example, we don’t let them remove TLS_FALLBACK_SCSV from the cipher suites.

And yeah, these are all hard problems. A lot depends on your situation; your goals, how important security vs. productivity, usability, customizability, etc. are to you.

2 Likes
(system) closed #5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.