poivron.org - passé/futur

Sécurité, architecture, esthétique et premiers choix

Il est coutume, sur bien des serveurs, de créer un sous-domaine DNS pour chaque service un peu majeur, tel que: mail.riseup.net, irc.indymedia.org, www.squat.net, ftp.tanneries.taz, etc. Cette habitude peut relever de choix ou de nécessités purement techniques. En effet, il est courant qu'un serveur subissant de fortes charges (ayant par exemple de très nombreux utilisateurs, et/ou des contenus très populaires) répartisse ses services sur des machines différentes. Au sein du même réseau, une machine peut alors être consacrée aux requêtes web, une autre aux services de courrier, une autre aux bases de données, et ainsi de suite. C'est notamment le cas du réseau Indymedia, dont les ressources sont réparties dans le monde entier. Ainsi, l'assignation d'un sous-domaine à chaque service prend tout son sens, puisque mail.riseup.net, par exemple, désigne une autre machine que riseup.net tout court, et est donc traduit en une adresse IP différente.

Cependant, cette mesure initialement technique est vite devenue sexy. Dès lors, elle fut appliquée par nombre d'administrateurs, créant spontanément autant de sous-domaines (conséquemment appelés virtual hosts - machines virtuelles) que de services, quand bien même ceux-ci seraient tous hébergés sur un seul et même ordinateur. Ne cachons pas que poivron.org faillit céder à la tentation. Mais une très bonne raison nous en a empêché: la certification.

Décidés à protéger nos connexions cryptées, à ne pas précipiter les utilisateurs et utilisatrices de poivron dans la mauvaise habitude de cliquer "accepter" sans se soucier, à conscientiser ces mêmes personnes, tant que possible, aux enjeux de la sécurité, nous avons voulu faire certifier poivron par l'"autorité" CA Cert. Or, un certificat ne peut être délivré que pour un seul domaine [1]. S'il certifie "poivron.org", il ne certifie pas pour autant "www.poivron.org" ou "mail.poivron.org", car il peut s'agir de machines différentes. Aussi l'utilisation de protocoles cryptés (comme https, imaps, pop3s, etc.) sur divers sous-domaines nécessite-t-elle, pour se dérouler dans de bonnes conditions de sécurité, la génération d'un certificat pour chaque sous-domaine [2].

Dans notre cas, généralisable à un certain nombre de serveurs de petite ou moyenne taille, nous ne disposons que d'une seule machine, rassemblant les divers services cryptés. Il serait inutilement coûteux d'utiliser autant de sous-domaines que de services, puisque cela nous contraindrait à obtenir autant de certificats auprès d'une autorité de certification. Aussi, par soucis d'optimisation, avons-nous concentré les divers services proposés sur le domaine poivron.org, ces derniers partageant un seul et même certificat, validé par cacert.org.

À vous de voir, donc, si vous souhaitez n'avoir à gérer qu'un certificat pour les divers services de votre machine, ou si vous préférez la très esthétique assignation de sous-domaines à chacun de vos services, avec les contraintes que cela engage. Si vous prévoyez d'élargir votre parc de serveurs, et de distribuer les services sur plusieurs machines par là suite, cette question n'a pas court, car plusieurs certificats vous seront de toutes façons nécessaires.

Générer une clef et une demande de certificat

Pour mettre en place des services cryptés sur votre serveur, il vous faut dans tous les cas commencer par générer une paire de clefs. Pour ce faire, placez vous dans un répertoire "de confiance" (non public) et entrez:

$ openssl req -nodes -new -keyout exemple.poivron.org.key -out exemple.poivron.org.csr

Une série de questions vous est alors posée. Seul le champ Common Name doit impérativement être rempli, et vous pouvez entrer '.' en guise de réponse pour toutes les autres questions. N'entrez rien dans les deux derniers champs (mot de passe). Cela doit ressembler à ceci:

Generating a 1024 bit RSA private key
....................................++++++
..++++++
writing new private key to 'private.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:exemple.poivron.org
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Si tout se passe bien, votre répertoire contient désormais deux fichiers: exemple.poivron.org.key (la clef privée, à ne diffuser sous aucun prétexte) et exemple.poivron.org.csr (la demande de certificat, à communiquer à votre autorité de certification - cacert.org ;).

Le fichier .csr doit ressembler à quelque chose comme ça:

-----BEGIN CERTIFICATE REQUEST-----
MIIBXTCBxwIBADAeMRwwGgYDVQQDExNleGVtcGxlLnBvaXZyb24ub3JnMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyo4DM7bVmAyjBR7KFcn539pij4zhXmPb4
sQpDtQ6HBi0wU4d+1C6S1OyB1eZ+6M5nHfPT9okuRd5Qfx+otUVv0YYC8aKM5+Gy
tlEXLHXAnfG0Q8z1IQPkULQ1+4nMIOYW9ChLHMI/vyT9R4Mkf1UWC8TpSz6VnO8L
H3HiPVvPKQIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEAHcBBrz3dEkUiaw79PXCs
GWcgDGqaMzaVTZZbzGvHN2cqITRnl5IGZgfliNbGdtl+RkGAkW/xV9GtndYlx6fy
K5RVHoxcasQpcn18RrLsWUMCsE02SLv2NSg+VgRAKA5w7D8JPo6KJUQSSkm6EiqV
6gOZVurhZ5aG5jpNh+FM0Xs=
-----END CERTIFICATE REQUEST-----

Certification par cacert.org

CA Cert est une autorité de certification alternative, gratuite et non-profit, à l'opposé des nombreuses entreprises qui tirent d'effarants profits de la vente de pareil vide.

CA Cert fonctionne selon un principe de réseau de confiance ouvert, rassemblant des acteurs et actrices qui bénéficient de divers "niveaux de confiance", et peuvent gagner en confiance par la rencontre physique d'autres membres de CA Cert. Contre vérification d'identité et accumulation de "points de confiance", il est possible de devenir "assureur" et de distribuer des certificats. Par défaut, il n'est possible d'obtenir de certificat que pour une durée de 6 mois. Il faudra être parrainé par un "assureur" à même de procéder à des vérifications pour obtenir des certificats d'une durée de 2 ans.

À moins que vous ne soyez déjà en contact avec un tel "assureur", il vous faut commencer par vous inscrire sur le site de CA Cert. Il vous faudra ensuite ajouter le domaine pour lequel vous désirez obtenir un certificat à votre compte. Un mail de vérification vous sera alors envoyé, à l'un des contacts disponibles dans le whois du domaine en question. Il contiendra un lien qu'il vous faudra visiter avec un navigateur, avant que vous ne puissiez soumettre votre demande de certificat à CA Cert (fichier .csr, comme exemple.poivron.org.csr que nous avons généré précédemment). Vous recevrez alors le certificat signé, sous la forme d'un fichier .crt, qu'il suffira de renommer exemple.poivron.crt et d'intégrer aux configurations du serveur.

Intégration du certificat à Apache et Postfix

Copiez les fichiers exemple.poivron.key (clef privée, qui ne doit être lisible que par root), exemple.poivron.csr (demande de certificat) et exemple.poivron.crt (le certificat) dans /etc/ssl/ ou autre endroit de votre choix. Placez-y également une copie du root certificate de CA Cert, disponible sur http://www.cacert.org/certs/root.crt.

Il s'agit alors de configurer les services cryptés pour qu'ils utilisent le certificat généré par CA Cert.

Pour Apache 2, il suffit d'ajouter dans la section du VirtualHost https correspondant:

SSLEngine On
SSLCACertificateFile /etc/ssl/root.crt
SSLCertificateFile /etc/ssl/exemple.poivron.org.crt
SSLCertificateKeyFile /etc/ssl/exemple.poivron.org.key

Le MTA Postfix peut utiliser l'extension TLS (Transport Layer Security), et ainsi chiffrer ses communications avec les autres serveurs SMTP supportant cette option (sous réserve d'avoir installé le paquetage Debian postfix-ssl). Pour ce faire, ajouter les lignes suivantes à /etc/postfix/main.cf:

### Transport Layer Security ###

# Server side TLS
smtpd_use_tls = yes
smtpd_tls_CAfile = /etc/ssl/root.crt
smtpd_tls_key_file = /etc/ssl/exemple.poivron.org.key
smtpd_tls_cert_file = /etc/ssl/exemple.poivron.org.crt
smtpd_tls_received_header = yes

# Client side TLS
smtp_use_tls = yes
smtp_tls_CAfile = /etc/ssl/root.crt
smtp_tls_key_file = /etc/ssl/exemple.poivron.org.key
smtp_tls_cert_file = /etc/ssl/exemple.poivron.org.crt

# Misc TLS
tls_random_source = dev:/dev/urandom

Un serveur IMAP & POP comme Dovecot gère très bien les protocoles chiffrés IMAPS et POP3S, définis par une simple variable de configuration dans /etc/dovecot.conf:

protocols =  imap imaps pop3 pop3s

Pour intégrer le certificat, ajouter, dans le même fichier:

ssl_cert_file = /etc/ssl/exemple.poivron.org.crt
ssl_key_file = /etc/ssl/exemple.poivron.org.key

Si vous utilisez d'autres logiciels pour POP & IMAP, enrobés par sslwrap pour la couche crypto et que vous lancez ce dernier via inetd, éditez /etc/inetd.conf et ajustez-y/ajoutez-y les lignes suivantes:

imaps   stream  tcp nowait  root    /usr/sbin/tcpd  /usr/sbin/sslwrap \
                                    -cert /etc/ssl/exemple.poivron.org.crt \
                                    -key /etc/ssl/exemple.poivron.org.key \
                                    -addr 127.0.0.1 -port 143

pop3s   stream  tcp nowait  root    /usr/sbin/tcpd  /usr/sbin/sslwrap \
                                    -cert /etc/ssl/exemple.poivron.org.crt \
                                    -key /etc/ssl/exemple.poivron.org.key \
                                    -addr 127.0.0.1 -port 110

Redémarrez vos services, et testez ;) Un navigateur devrait suffire pour le https, mais je conseille l'utilisation de mutt pour tester efficacement et rapidement l'intégration du certificat aux services pop3s et imaps:

mutt -f imaps://user@exemple.poivron.org/INBOX

Voilà.

À partir de ces quelques exemples, il devrait être très facile d'intégrer le certificat aux divers services de votre machine. Reste le plus important, soit sensibiliser vos utilisateurs et utilisatrices à la question, en les encourageant à importer le root certificate de CA Cert dans leur navigateur ou client mail! Pour ce faire, voir poivron.org, cacert.org & certificat: c'est quoi, pourquoi, comment? qui présente de manière simple ces quelques pas. En espérant que cela aide à ce que chacun-e cerne un peu mieux "ce qui se cache derrière son navigateur"!

Notes:

[1] Il est possible de générer des certificats contenant un masque, comme *.poivron.org. Cependant, ceux-ci sont loin d'être reconnus par tous les navigateurs, et leur utilisation est donc déconseillée pour le moment.

[2] En pratique, il est possible d'utiliser un même certificat pour divers domaines, en ce sens que la connexion cryptée demeure possible, au prix d'un message d'erreur ou avertissement, mais la vérification de l'identité de l'hôte que permet la certification n'aura plus court.