22decembre en Full TLS maintenant !
Vendredi, j’ai lu cet article où il était question d’une AC fournissant des certificats SSL/TLS gratuitement. Youhou !
Bon, il y a [Let’s Encrypt]({{ < ref “lets-encrypt.fr.md” > }}) et je les attends avec impatience, mais on peut compter qu’ils essuient quelques plâtres. Donc pourquoi ne pas profiter de cette AC chinoise en attendant ?
C’est justement pour cette raison que j’ai fait l’[upgrade]({{ < ref “upgrade57.fr.md” > }}) au même moment, ou presque.
Alors, je tiens à vous prévenir, pour avoir utiliser leur site web, c’est bien chinois. C’est lent, ça doit être truffé de bugs ou ça a du mal à passer la grande muraille de Chine.
Comme il y a des courriels à recevoir, j’ai désactivé l’anti-spam durant tout ce temps, histoire d’éviter qu’une conf’ foireuse d’un serveur mail chinois fasse ralentir le truc. Et oui, leur serveur mail a bien une conf’ foireuse. C’est pas du racisme de bas étage.
Mais au final, j’ai eu mon certificat ! Et donc je viens d’activer TLS sur tous mes sites web. Il s’agit juste de l’adaptation de ma configuration précédente. Sauf que cet fois-ci l’utilisation du chiffrement est obligatoire.
Sécurité des certificats
Pour accroître mon niveau de sécurité, j’ai créé un groupe d’utilisateurs système pour qu’eux seuls aient accès aux certificats et à la clé privée, et ce en lecture seule.
Sont donc membres de ce groupe: _smtpd, _smtpq, spamd, www.
Est-ce utile ? J’en suis pas sûr.
Mais ça ne coûte presque rien (il faut quand même bouger les doigts sur le clavier… Quand même !) . Donc pourquoi ne pas le faire ?
Httpd
Comme écris dans l’article d’hier, je réutilise la même configuration tls partout à travers le httpd.conf en la mettant dans un fichier d’include. Il faut être fainéant à bon escient. C’est aussi gage de facilité de maintenance et d’efficacité.
Entre l’article d’hier, aujourd’hui et la page de manuel - faites gaffe à la version, vous devez avoir une bonne idée des possibilités de configuration du nouveau serveur web d’OpenBSD.
httpd.tls
listen on * tls port 443
listen on :: tls port 443
tls key "/etc/ssl/private/server.key"
tls certificate "/etc/ssl/server.crt"
tls protocols "TLSv1.1,TLSv1.2"
tls ciphers "AES256+EECDH:AES256+EDH"
Le certificat vient avec une chaîne complète. Donc en fait, j’ai concaténé tous les crt en un seul, qui est donc le server.crt indiqué ci-dessus.
cat 3_user.crt 2_issuer.crt 1_intermediate.crt root.crt >> server.crt
Je n’arrive pas encore à utiliser les options tls pointues telles que dhe et ecdhe.
J’utilise aussi TLSv1 et 2. Parce que je veux laisser des gens avec des conf’ pas hyper récentes visiter mon blog. En revanche, j’ai bannis TLSv1.0 et SSL. J’ai quand même un excellent classement sur SSLlabs.
Edit/MàJ
L’utilisation des deux lignes listen permet de garantir l’écoute sur les deux protocoles, inet et inet6. Lors de la redaction de l’article, j’utiliasis egress. Bizarrement, ça n’écoutais pas sur inet6. Idem si on utilise *.
Le choix des suites de chiffrement est compliqué. En desepoir de cause, je me suis rabattu sur la conf’ ssl que j’avais indiqué dans les liens ssl
Merci aux dev’ d’OpenBSD pour les options sécurisées par défaut.
httpd.conf
server "www.22decembre.eu" {
alias "22decembre.eu"
include "/etc/httpd.tls"
root "/pelican"
location "/bibliotheque/" { block return 301 "https://biblib.22decembre.eu" }
location "/biblib/" { block return 301 "https://www.22decembre.eu/2013/12/17/softwares-projects-en/" }
location "/drafts/*" { directory auto index }
location "/downloads/*" { directory auto index }
location "*/feed/" { directory index atom.xml }
location match "/2012/02/27/*" { block return 301 "https://www.22decembre.eu/2015/03/31/5-sign-mail-fr/" }
}
server "www.22decembre.eu" {
listen on * port 80
listen on :: port 80
block return 301 "https://$SERVER_NAME$REQUEST_URI"
}
Je n’ai pas réussi non plus à utiliser la directive server match pattern. Ça aurait été cool pour faire une redirection massive de tous les sites http vers leurs versions https. Idem pour la directive hsts.
Je pensais à un truc comme:
server match "*.22decembre.eu" {
listen on * port 80
listen on :: port 80
block return 301 "https://$SERVER_NAME$REQUEST_URI"
}
Au lieu de cela, je dois faire un bloc de redirection pour obliger à la connection en https, pour chacun des sites web. C’est laborieux, mais ça marche.
On verra bien. Je suppose que Reyk, le devellopeur, ou d’autres personnes, publieront de plus amples détails, avec des exemples de leurs conf’ hyper puissantes. Si c’est le cas, j’éditerais cet article après avoir adapté ma propre installation.
Courriel
Dovecot
# SSL/TLS support: yes, no, required. <doc/wiki/SSL.txt>
ssl = required
# PEM encoded X.509 SSL/TLS certificate and private key. They're opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Included doc/mkcert.sh can be used to easily generate self-signed
# certificate, just make sure to update the domains in dovecot-openssl.cnf
ssl_cert= </etc/ssl/server.crt
ssl_key = </etc/ssl/private/server.key
# How often to regenerate the SSL parameters file. Generation is quite CPU
# intensive operation. The value is in hours, 0 disables regeneration
# entirely.
ssl_parameters_regenerate = 168 hours
ssl_dh_parameters_length = 1024
# SSL protocols to use
ssl_protocols = !SSlv2 !SSLv3
# SSL ciphers to use
ssl_cipher_list = AES256+EECDH:AES256+EDH
ssl_prefer_server_ciphers = yes
Il est à noter que je ne suis pas sûr de ma configuration. Pour être sûr, allez voir la documentation de Dovecot. Les paramètres ssl sont très peu détaillés.
Comme les certificats sont lus avant l’abandon des privilèges par le démon, celui-ci n’a pas besoin d’être membre du groupe tls.
Smtpd
Je n’utilise pas les certificats concaténés dans le cas du serveur SMTP. Juste le certificat final, enregistré dans le fichier seul.crt.
La configuration de smtpd reste très simple en ce qui concerne tls :
pki blackblock.22decembre.eu key "/etc/ssl/private/server.key"
pki blackblock.22decembre.eu certificate "/etc/ssl/seul.crt"
pki blackblock.22decembre.eu dhparams "/etc/mail/certs/dh4096.pem"
J’utilise les options de dhparams. Ce n’est pas grand chose à faire, donc pourquoi pas ? Du point de vue de l’administrateur, c’est comme de générer une nouvelle clé:
openssl dhparam -out dh4096.pem -outform PEM -2 4096
Spamd
Spamd écoute maintenant avec TLS ! Mais on ne lui indique pas quels fichiers tls utiliser dans son fichier de configuration, mais bien via sa commande d’initialisation !
En fait, dans rc.conf.local, vous devez avoir ceci maintenant :
spamd_flags="-v -G 25:4:864 -C /etc/ssl/seul.crt -K /etc/ssl/private/server.key"
J’indique le fichier de certificat avec -C et -K pour la clé. -G indique simplement les temps de greylisting.
DANE
Finalement, on peut publier des enregistrements TLSA. En fait, comme on utilise partout le même certificat, ce sera le même enregistrement partout. Les certificats concaténés ou seul donne le même résultat.
Mais dans les faits, seuls Spamd et Smtpd doivent impérativement partager le même certificat. D’ailleurs, comme DANE commence à être bien utilisé et reconnu par Postfix, serveur de courrier très populaire, c’est une très bonne chose.
Par contre il n’est reconnu nativement par aucun navigateur web. Il vous faut un plugin pour cela pour l’instant.
La syntaxe des enregistrements TLSA est décrite ici, par exemple.
openssl x509 -noout -fingerprint -sha256 < seul.crt | tr -d :
Par exemple, dans le fichier de zone DNS :
_587._tcp.blackblock.22decembre.eu. IN TLSA 3 0 1 ( 69169B52DBC4C5E2875E1DD9F573A15C7B607566E41395C3C22EE0D141522302 )
_25._tcp.blackblock.22decembre.eu. IN TLSA 3 0 1 ( 69169B52DBC4C5E2875E1DD9F573A15C7B607566E41395C3C22EE0D141522302 )
_443._tcp.blackblock.22decembre.eu. IN TLSA 3 0 1 ( 69169B52DBC4C5E2875E1DD9F573A15C7B607566E41395C3C22EE0D141522302 )
_443._tcp.www.22decembre.eu. IN TLSA 3 0 1 ( 69169B52DBC4C5E2875E1DD9F573A15C7B607566E41395C3C22EE0D141522302 )