Security Model » History » Version 3

Marc Dequènes, 2020-04-06 14:31

1 2 Marc Dequènes
h1. Security Model
2 1 Marc Dequènes
3 2 Marc Dequènes
h2. Status in DuckCorp
4 1 Marc Dequènes
5 2 Marc Dequènes
h3. DNS
6 1 Marc Dequènes
7 2 Marc Dequènes
We would prefer not to have to trust the DNS hierarchy, but, it is convenient for most users and alternative systems at the moment did not solve the problem in a satisfactory manner.
8 1 Marc Dequènes
9 3 Marc Dequènes
Our [[DNS#DNSSEC|zones are secured using DNSSEC]]. Tenants' zones will be signed when handling the KSK rollover with the parent zone is smooth enough (and fully automated, WIP).
10 2 Marc Dequènes
11 3 Marc Dequènes
h3. PKI
12 2 Marc Dequènes
13 3 Marc Dequènes
The "DuckCorp CA: was created when usage of HTTPS was not very common and certificates very expensive. Time also proved we cannot trust the top CAs and their "broken security model":
14 1 Marc Dequènes
15 3 Marc Dequènes
Nowadays it is no more viable to operate a self-signed CAs as all softwares and providers rejects them. Moreover, it is quite inconvenient to setup a custom CA for non-technical users and it makes our life difficult to communicate and exchange with external entities through our infrastructure. That is why we decided to trust "Let's Encrypt": to generate certificates. The root of the problem is not solved but at least the validation process is sound and open. It is also automated, using Free Softwares, so we can handle certificate management by ourselves. We keep using our CA for internal services but public-facing ones now use Let's encrypt (#676).
16 1 Marc Dequènes
17 3 Marc Dequènes
To counteract the loss in security we use another system (DANE, see below); it requires trusting the DNS hierarchy, but there are less players involved and it has proved more reliable. Unfortunately DANE adoption is quite slow; nevertheless we decided to implement it.
Initially we only used our own CA and published TLSA records for all services. Since we now use Let's Encrypt, TLSA publication has been reworked to play nice together. It is fully automated (compared to renewal with our own CA) but currently not deployed for all services yet (#675).
20 1 Marc Dequènes
21 2 Marc Dequènes
22 1 Marc Dequènes
23 2 Marc Dequènes
h2. DANE
h3. Introduction
"DANE": is a security protocol used to reinforce TLS certificate validation by publishing certain information in the DNS. It requires your DNS zones to be secured using "DNSSEC":
h3. Checking DANE
33 1 Marc Dequènes
The "danetls": tool is not packaged but there is a web service called "danecheck": by the same author.
35 2 Marc Dequènes
h3. DANE adoption
36 1 Marc Dequènes
These are just notes to check on DANE adoption in various client software.
39 2 Marc Dequènes
* HTTPS: "plugins for majors browsers were developed and abandoned": because necessary API support in the browsers vanished and there is no replacement
40 1 Marc Dequènes
* SMTP: seems to have gained traction, suggested by the various checkers, Postfix supports it and we support it (see [[Mail]])
* IMAP/POP3: "Thunderbird integration was refused": because it needs to be integrated in Firefox core first, but the "Firefox integration": does not seem to go anywhere
* IRC: "Weechat integration": is not making much progress despite a patch being available
* XMPP-c2s: ???
* XMPP-s2s: Prodosy has an "experimental module": but it is unmaintained and supposed to crash sometimes (according to the known issues)