Services/Security

Introduction

All services containing sensitive information are protected using cryptography. Whenever possible, we add the necessary configuration to ensure unsecure usages are not possible, to protect your data. Nevertheless, a few things are needed on your side to improve security, that's why we are providing the following notes in order to help you configure your software in a secure fashion.

You can read more about ou security model on the wiki.

Areas of Security

Mails from DC's Administrators

You should not trust mails pretenting to come from us. The only way to be sure a mail is from someone, is to agree on exchanging cryptographically-protected messages. On this page you'll find the list of DC's administrators from which you may receive mails (on the users's mailing-list for example). You could trust their GPG keys directly, but that would not be secure at all. The best way is to meet, live, in a key signing party. If a friend has already signed our key, and is not too far from you, you may also propagate your trust to our keys. Once done, you'll be sure what seems to come from us is really from us.

Talking to the Right Machine/Service

All remote services use an address on the internet, like superservice.duckcorp.org, but if you are connected through an untrusted network (like if you're using a third-party's WIFI), you cannot be sure you'll be connecting to the right machine, and you may disclose important information like your credentials.

TLS/SSL-based Services

Nowadays we use Let's Encrypt certificates for all public-facing services. Your system should already be configured out of the box to support it.

Using DuckCorp's Internal CA

If you need to access internal service like LDAP, then you'll need to configure your system to use DuckCorp's CA with the procedure below.

To ensure you're talking to the right server, and noone pretend to be a DC's server to tricks you, you need to install the following certificate (File:Duckcorp.crt, which was signed by Arnau File:Arnau duckcorp.crt.asc, Pilou File:Pilou duckcorp.crt.asc and Duck File:Duck duckcorp.crt.asc):

• either in your software configuration (for example, to validate HTTP site in your browser, clicking on the link should ask for installation, and you'll just need to confirm you trust it)
  • For Firefox you must manually import the certificate (#316436): Preferences -> Advanced -> Certificates -> View Certificates -> Authorities -> Import.
  • For Chromium too, you must manually import the certificate: Settings -> Show advanced settings -> Manage certificates -> Authorities -> Import.
• or globally on your host by installing the certificate, as root:
  • (method 1, prefered) in /usr/local/share/ca-certificates, and running update-ca-certificates (the ca-certificates package needs to be installed)
  • (method 2, not suitable for GNUTLS-based apps) in /etc/ssl/certs, and running c_rehash (the openssl package needs to be installed)

The certificate and signatures can also be downloaded from the following link: http://ca.duckcorp.org/

Service Locator Security

One possible attack is to alter replies from the machine locator service (DNS) in order to redirect your communication to a nasty machine. Since November 2010, duckcorp.org and milkypond.org domains are cryptographically signed using the DNSSEC system, so you are now able to verify the address returned for the service is the right one. This system is not new, but has recently switched into production, so your operating system may not yet be properly configured to use this protection. Until it is pre-configured in most of them, you may configure it yourself using this procedure.

Beware this protection solves certains security problems but is not sufficient to ensure you're talking to the right machine/service. Nevertheless it ensures:

• the address of the machine/service is the right one
• information related to the domain, list of mail servers, security information on hosts (SSHFP)… are not tampered

Using this security plus certificate verification (see section about TLS/SSL-based Security) would ensure full security.

Secure SSH Connections

In order not to be tricked connecting to a fake server, or to a rooted server (just in case), it is possible to check the SSH key of the server. As this verification is quite boring both for administrators and users, almost nobody on earth does it. Fortunately, it is possible to publish this information in the DNS and have OpenSSH check it for you automatically.

To add this security, you can edit your system configuration (/etc/ssh/ssh_config) or your personal one (~/.ssh/config), and add the folowing:

Host *
  VerifyHostKeyDNS ask

Of course, the DNS replies may be altered, so if you want full security, read the section about Service Locator Security.