Un serveur web est soit un logiciel de service de ressources web (serveur HTTP), soit un serveur informatique (ordinateur) qui répond à des requêtes sur un réseau public ou privé en utilisant principalement le protocole HTTP, ou HTTPS. Caddy est un serveur web écrit en Go, open source et disponible avec HTTPS automatiquement. Il fonctionnera tout aussi bien que n'importe quel autre serveur web en Go.- Par défaut, le serveur web, Caddy sert tous les sites par HTTPS. Nul besoin d’implémenter un certificat pour la sécurité de son site. Caddy sert les adresses IP et les noms d'hôtes locaux/interne sur HTTPS en utilisant des certificats auto-signés qui sont automatiquement reconnus localement (si autorisé) ;
- Le serveur web Caddy sert également les noms DNS publics via HTTPS en utilisant des certificats d'une autorité de certification ACME publique telle que Let's Encrypt ou ZeroSSL. Exemples : exemple.com, sub.exemple.com, *.exemple.com ;
- Caddy maintient le renouvellement de tous les certificats gérés et redirige automatiquement HTTP (port 80 par défaut) vers HTTPS (port 443 par défaut).
Pour le HTTPS local, Caddy peut demander un mot de passe pour installer son certificat racine unique. Cela ne se produit qu'une fois par racine ; et il peut être supprimé à tout moment. Tout client accédant au site sans faire confiance à la racine de Caddy affichera des erreurs de sécurité.
Caddy et les noms de domaine public
Il s'agit d'exigences courantes pour tout site Web de production de base, et pas seulement pour Caddy. La principale différence est de configurer correctement les enregistrements DNS avant de lancer Caddy afin qu'il puisse fournir des certificats.
- si les enregistrements A/AAAA de votre domaine pointent vers votre serveur ;
- les ports 80 et 443 sont ouverts en externe ;
- Caddy peut se lier à ces ports (ou ces ports sont redirigés vers Caddy) ;
- le répertoire de données est accessible en écriture et persistant ;
- le nom de domaine apparaît à un endroit pertinent de la configuration.
Ainsi, comme dit précédemment, les sites seront automatiquement servis en HTTPS. L’administrateur n’a pas besoin de faire quoi que ce soit d'autre à ce sujet. Étant donné que HTTPS utilise une infrastructure partagée et publique, l’administrateur du serveur se doit de comprendre correctement le fonctionnement de Caddy afin d'éviter les problèmes inutiles, de les résoudre lorsqu'ils se produisent et de configurer correctement les déploiements avancés.
Local HTTPS
Pour servir les sites non publics via HTTPS, Caddy génère sa propre autorité de certification (AC) et l'utilise pour signer les certificats. La chaîne de confiance consiste en un certificat racine et un certificat intermédiaire. Les certificats Leaf sont signés par l'intermédiaire. Ils sont stockés dans le répertoire de données de Caddy à pki/authorities/local. L'AC locale de Caddy est alimentée par les bibliothèques Smallstep. Le HTTPS local n'utilise pas ACME et n'effectue pas de validation DNS. Il ne fonctionne que sur la machine locale et n'est fiable que là où le certificat racine de l'AC est installé.
Racine de l'autorité de certification
La clé privée de la racine est générée de manière unique à l'aide d'une source pseudo-aléatoire cryptographiquement sécurisée et persistée dans le stockage avec des autorisations limitées. Elle n'est chargée en mémoire que pour effectuer les tâches de signature, après quoi elle quitte le champ d'application pour être collectée. Bien que Caddy puisse être configuré pour signer avec la racine directement (pour supporter les clients non conformes), ceci est désactivé par défaut, et la clé racine est seulement utilisée pour signer les intermédiaires.
Après l'installation de l'autorité de certification racine de Caddy, vous la verrez dans votre magasin de confiance local sous le nom de Caddy Local Authority (à moins que vous n'ayez configuré un nom différent). Vous pouvez le désinstaller à tout moment si vous le souhaitez (la commande caddy untrust rend cela facile). Notons que l'installation automatique du certificat dans les magasins de confiance locaux est seulement pour la commodité et n'est pas garantie pour fonctionner, particulièrement si des conteneurs sont utilisés ou si Caddy est exécuté comme un service système non privilégié.
En fin de compte, si vous vous appuyez sur une PKI interne, il est de la responsabilité de l'administrateur système de s'assurer que la racine CA de Caddy est correctement ajoutée aux magasins de confiance nécessaires (ceci est en dehors de la portée du serveur web). La première fois qu'une clé racine est utilisée, Caddy essaiera de l'installer dans le(s) magasin(s) de confiance local(aux) du système. S'il n'a pas la permission de le faire, il demandera un mot de passe. Ce comportement peut être désactivé dans la configuration s'il n'est pas souhaité.
TLS à la demande
Caddy a été le pionnier d'une nouvelle technologie que nous appelons On-Demand TLS, qui obtient dynamiquement un nouveau certificat lors de la première poignée de main TLS qui le requiert, plutôt qu'au chargement de la configuration. Il est important de noter que cela ne nécessite pas de spécifier à l'avance les noms de domaine dans votre configuration. De nombreuses entreprises s'appuient sur cette fonctionnalité unique pour faire évoluer leurs déploiements TLS à moindre coût et sans casse-tête opérationnel lorsqu'elles desservent des dizaines de milliers de sites. TLS à la demande est utile si :
- l'utilisateur n'a pas le contrôle des noms de domaine à l'exemple des domaines de clients ;
- l'utilisateur ne connait pas tous les noms de domaine lorsqu'il démande ou recharge sonserveur ;
- les noms de domaine peuvent ne pas être correctement configurés tout de suite (enregistrements DNS pas encore définis).
Lorsque la fonction TLS à la demande est activée, vous n'avez pas besoin de spécifier les noms de domaine dans votre configuration afin d'obtenir des certificats pour eux. Au lieu de cela, lorsqu'une poignée de main TLS est reçue pour un nom de serveur (SNI) pour lequel Caddy n'a pas encore de certificat, la poignée de main est suspendue pendant que Caddy obtient un certificat à utiliser pour compléter la poignée de main. Le délai n'est généralement que de quelques secondes, et seule la première poignée de main est lente. Toutes les poignées de main ultérieures sont rapides car les certificats sont mis en cache et réutilisés, et les renouvellements se font en arrière-plan. Les futures poignées de main peuvent déclencher la maintenance du certificat afin de le renouveler, mais cette maintenance se fait en arrière-plan si le certificat n'a pas encore expiré.
Stockage
Caddy stockera les certificats publics, les clés privées et les autres actifs dans son installation de stockage configurée. La principale chose à savoir en utilisant la configuration par défaut est que le dossier $HOME doit être accessible en écriture et persistant. Pour aider à résoudre les problèmes, Caddy imprime ses variables d'environnement au démarrage si l'option --environ est spécifiée.
Toutes les instances de Caddy qui sont configurées pour utiliser le même stockage partageront automatiquement ces ressources et coordonneront la gestion des certificats comme un cluster. Avant de tenter toute transaction ACME, Caddy testera le stockage configuré pour s'assurer qu'il est accessible en écriture et a une capacité suffisante. Cela permet de réduire les conflits de verrouillage inutiles.
Performances par rapport à Nginx
NGINX est un logiciel libre de serveur Web ainsi qu'un proxy inverse écrit par Igor Sysoev, dont le développement a débuté en 2002 pour les besoins d'un site russe à très fort trafic. Reconnu aujourd’hui pour ses performances élevées, sa stabilité, son ensemble de fonctionnalités avancées, sa configuration simple et sa faible consommation de ressources, Nginx a été conçu initialement comme réponse au problème de performances liés au traitement de 10 000 connexions simultanées dénommé problème C10k. Ce dernier est relatif à un souci d'optimisation des connexions réseau pour gérer un grand nombre de clients en même temps ; Nginx utilise pour cela une architecture asynchrone et événementielle pour gérer ces énormes quantités de connexions.
En termes de performances, Matt Holt, l’auteur du serveur Web de Caddy, semble avoir beaucoup de mal à présenter un résultat convainquant. En effet, l’une des curieuses réponses suite aux recherches sur les performances de Caddy est n fil de discussion du forum Caddy avec une réponse de l'auteur de Caddy : « Caddy est écrit en Go. Il fonctionnera tout aussi bien que n'importe quel autre serveur web Go. Google, Netflix, Cloudflare, Fastly et d'autres grandes entreprises de réseau déploient Go sur leur périphérie ».
Notons que Go vise la rapidité d'exécution, indispensable à la programmation système et considère le multithreading comme le moyen le plus robuste d'assurer sur les processeurs actuels cette rapidité tout en rendant la maintenance facile par séparation de tâches simples exécutées indépendamment. Cette conception permet également le fonctionnement sans réécriture sur des architectures multicœurs en exploitant immédiatement l'augmentation de puissance correspondante. Voici quelques observations présentées par Matt :
- un caddy prêt à l'emploi a fait 1k req/s avec environ 5 % de charge CPU ;
- quelques tests de référence avec Nginx produiraient environ 1k req/s pour une machine à 8 cœurs à 100 %.
Pour FrancisLavoie, programmeur, « les benchmarks officiels pour les serveurs n'ont pas de sens, et non pas que les performances n'ont pas d'importance ». « Faites vos propres tests, pour votre propre cas d'utilisation. Mais tout de même, un serveur devrait rarement être votre goulot d'étranglement. Les E/S de la base de données de votre application le seront », lance le développeur.
Source : Caddy
Et vous ?
Nginx, Apache ou Caddy, lequel de ces serveurs Web utilisez-vous ? Quel est votre avis sur Caddy ? Avez-vous une idée sur les performances de Caddy ? Pensez-vous que Caddy peut être une alternative à Nginx ?Voir aussi :
Caddy 2 est disponible, le serveur Web prend en charge TLS automatiquement et par défaut et posséderait des garanties de sécurité mémoire plus fortes qu'OpenSSL Nginx est maintenant le serveur web le plus utilisé par les sites les plus fréquentés au monde, devant Apache et Microsoft IIS, selon W3Tech Go 1.18, le langage de programmation open source développé par Google, arrive avec la généricité par défaut, elle ouvrira de nouvelles solutions, d'approches et de paradigmes Serveurs Web : Nginx détient désormais un tiers des parts de marché tandis qu'Apache chute en dessous des 50 %, d'après W3Tech