Caddy (serwer WWW)

Nosiciel kijów golfowych
Oryginalni autorzy Mateusza Holta
Pierwsze wydanie 28 kwietnia 2015 ; 7 lat temu ( 2015-04-28 )
Wersja stabilna
2.6.3 / 8 lutego 2023 ; 23 dni temu ( 08.02.2023 )
Magazyn github.com/caddyserver/caddy _ _ _
Napisane w Iść
System operacyjny Warianty BSD , Linux , Plan 9 , macOS i Windows
Platforma IA-32 (i386), x86-64 , ARM , MIPS , S390X
Typ Serwer WWW , odwrotny serwer proxy
Licencja Apache 2
Strona internetowa caddyserver.com _ Edit this at Wikidata

Serwer WWW Caddy to rozszerzalny , wieloplatformowy serwer WWW typu open source napisany w języku Go .

Nazwa „Caddy” odnosi się zarówno do pomocnika w żmudnych zadaniach, jak i sposobu na uporządkowanie wielu części w uproszczony system. Zasadniczo Caddy jest rozszerzalną platformą do wdrażania długotrwałych usług („aplikacji”) przy użyciu jednej, ujednoliconej konfiguracji, którą można aktualizować on-line za pomocą interfejsu API REST . Oficjalne dystrybucje Caddy są dostarczane z zestawem standardowych modułów, które obejmują serwer HTTP , automatyzację TLS i aplikacje PKI . Najbardziej znany jest z automatycznych funkcji HTTPS.

Matthew Holt początkowo zaczął samodzielnie rozwijać Caddy w 2014 r., a następnie w 2015 r. wydał pierwszą publiczną wersję. Oprogramowanie wkrótce stało się publiczną współpracą z setkami współpracowników na GitHub. Aby spełnić wymagania rosnącej społeczności z różnymi przypadkami użycia , ostatecznie Caddy został całkowicie przepisany od podstaw, a wersja 2.0 została wydana 4 maja 2020 r.

Pliki binarne Caddy są oficjalnie dystrybuowane dla systemów Linux , Windows , macOS , BSD i innych systemów operacyjnych na różnych architekturach , w tym x86-64 , ARM , MIPS , S390X i PPC64 . Oficjalne dystrybucje 32-bitowych plików binarnych zostały wycofane, ale Caddy można skompilować ze źródeł dla architektur IA-32 . Utrzymywane są również pakiety dla Debian , CentOS , RedHat i Arch Linux , a także oficjalny obraz Dockera .

Architektura

Architektura Caddy jest podzielona na trzy główne komponenty: komendę , podstawową bibliotekę i moduły konfiguracyjne. Polecenie to rozszerzalny interfejs, za pomocą którego wykonywany jest program ; może również ładować pliki konfiguracyjne , uruchamiać wspólne tryby, zarządzać zainstalowanymi wtyczkami i oferować odpowiednie funkcje narzędziowe. Podstawowa biblioteka zawiera interfejsy API do ładowania, rozładowywania i zarządzania konfiguracją ; ale sam w sobie nie robi nic szczególnie przydatnego. Większość funkcjonalności Caddy jest zapewniana przez moduły , które są wtyczkami rozszerzającymi strukturę konfiguracji Caddy; na przykład serwer HTTP jest modułem. Moduły Caddy wdrażają różne długotrwałe usługi, standardy sieciowe i inne przydatne funkcje.

Dane wejściowe Caddy to dokument konfiguracyjny JSON, który jest odbierany przez otwarte gniazdo za pośrednictwem RESTful HTTP API. W przypadku braku klienta HTTP interfejs wiersza poleceń Caddy może być użyty do załadowania plików konfiguracyjnych. Adaptery konfiguracji mogą służyć do konwertowania innych formatów konfiguracji na format JSON . Istniejące adaptery obejmują plik Caddyfile, który zapewnia pierwszorzędne wsparcie w wierszu poleceń; oraz YAML , TOML , NGINX i kilka innych formatów.

Gdy konfiguracja zostanie odebrana przez gniazdo administracyjne, Caddy dekoduje konfigurację dla wszystkich określonych modułów i rozpoczyna uruchamianie wszystkich modułów aplikacji. Gdy moduły aplikacji są udostępniane, same mogą ładować i udostępniać używane przez siebie moduły. Na przykład serwer HTTP to moduł aplikacji, który używa modułów obsługi HTTP do obsługi żądań HTTP; te programy obsługi mogą używać jeszcze innych modułów do implementacji swojej funkcjonalności i tak dalej. Wszystkie te moduły są udostępniane podczas fazy ładowania konfiguracji.

Wtyczki są instalowane poprzez statyczną kompilację bezpośrednio do pliku binarnego Caddy. Bez wtyczek natywna struktura konfiguracji Caddy ma tylko kilka podstawowych opcji do administrowania i logowania. Wszystkie inne funkcje muszą być dostarczane przez moduły aplikacji. Oficjalne dystrybucje Caddy są dostarczane z dziesiątkami standardowych modułów; inne można dodać ze strony internetowej projektu, używając narzędzia wiersza poleceń xcaddy lub ręcznie kompilując niestandardową kompilację.

Serwer HTTP

Serwer HTTP to moduł aplikacji, który jest standardowo dostarczany z oficjalnymi dystrybucjami Caddy. Jest używany głównie jako statyczny serwer plików i odwrotne proxy z równoważeniem obciążenia. Podczas gdy podstawa funkcji Caddy HTTP wykorzystuje implementację znajdującą się w standardowej bibliotece Go, różne ulepszenia i dostosowania są dostępne jako oprogramowanie pośrednie i ujawniane za pomocą parametrów konfiguracyjnych:

Serwer HTTP firmy Caddy obsługuje żądania zgodnie ze skonfigurowanymi trasami we wzorcu oprogramowania pośredniego. Trasy są definiowane na liście, a każda trasa zgodna z żądaniem jest po kolei stosowana w łańcuchu oprogramowania pośredniego. Żądania można dopasowywać na podstawie różnych parametrów, w tym metody HTTP, nazwy hosta, adresu zdalnego, pól nagłówka, ścieżki, ciągu zapytania, protokołu, wartości zmiennych, istnienia pliku, wyrażeń CEL i innych podanych przez wtyczki. Po dopasowaniu wywoływane są moduły obsługi, które mogą obejmować między innymi serwer plików, oprogramowanie pośrednie do przepisywania, odwrotne proxy, ograniczanie szybkości, manipulowanie nagłówkami i renderowanie szablonów. Dodatkowo trasy można zdefiniować tak, aby wykluczały się wzajemnie z innymi trasami lub terminalami, które kończą łańcuch obsługi.

Domyślnie protokół TLS jest używany automatycznie, jeśli jakiekolwiek trasy mają niepusty element dopasowujący hosta. Zakłada się, że są to nazwy witryn lub adresy IP obsługiwane przez Caddy, więc Caddy automatycznie uzyska i odnowi certyfikaty dla skonfigurowanych nazw hostów i adresów IP. Gdy automatyczny HTTPS zostanie aktywowany w ten sposób, Caddy przekieruje również żądania HTTP do odpowiadającej im lokalizacji HTTPS.

automatyzacja TLS

Aplikacja TLS jest standardowo dostarczana z oficjalnymi dystrybucjami Caddy. Działa jako serwer TLS i jest przeznaczony do automatyzacji. Domyślne ustawienia TLS Caddy są uważane za bezpieczne i nowoczesne. Jeśli chodzi o zabezpieczanie kluczy prywatnych , Caddy nie jest narażony na luki w zabezpieczeniach pamięci, takie jak Heartbleed, ponieważ jest napisany w Go. Jednym z głównych celów tego modułu jest ładowanie certyfikatów TLS do pamięci, aby można było je obsłużyć w celu zakończenia uzgadniania TLS. Pliki certyfikatów i kluczy mogą być ładowane ręcznie na serwer, ale zazwyczaj są one zautomatyzowane poprzez określenie nazw podmiotów. Jeśli ładowane są ręcznie, Caddy nie odnawia ich automatycznie. W przypadku zautomatyzowania ta aplikacja automatycznie uzyska i odnowi certyfikat dla każdej nazwy podmiotu. Dany certyfikat zostanie zautomatyzowany zgodnie z pierwszą dopasowaną polityką automatyzacji dla jego nazwy podmiotu (zwykle jest to nazwa domeny lub adres IP ). Polityka automatyzacji składa się z wystawców oraz różnych certyfikatów i opcji zarządzania, takich jak typ klucza, miejsce przechowywania certyfikatu, zarządzanie certyfikatem „na żądanie” oraz opcje OCSP . Te funkcje automatyzacji działają zarówno w przypadku certyfikatów serwera, jak i certyfikatów klienta. Obsługiwane są certyfikaty wieloznaczne .

Wystawca jest źródłem certyfikatu i zazwyczaj jest to urząd certyfikacji ACME . Caddy w pełni obsługuje protokół ACME, w tym wyzwania HTTP, TLS-ALPN i DNS, powiązanie konta zewnętrznego (EAB), wiele łańcuchów certyfikatów i heurystykę inteligentnych ponowień. Caddy może być również swoim własnym emitentem dzięki wbudowanym infrastrukturze PKI. W celu zapewnienia nadmiarowości można określić wielu emitentów; jeśli jeden nie przedstawi certyfikatu, następny zostanie wypróbowany.

Certyfikaty TLS można przechowywać w konfigurowalnym zapleczu magazynu, którym jest domyślnie lokalny system plików. Istnieją wtyczki dla innych rodzajów zaplecza pamięci masowej, takich jak bazy danych. Instancje Caddy, które są skonfigurowane do korzystania z tego samego zaplecza pamięci masowej, będą automatycznie działać jako część klastra i udostępniać certyfikaty oraz zasoby OCSP, w tym koordynować uzyskiwanie i odnawianie certyfikatów.

Zazwyczaj certyfikaty są zarządzane podczas uruchamiania, gdy ładowana jest konfiguracja. Jednak Caddy obsługuje tryb automatyzacji o nazwie On-Demand TLS , który odracza operacje na certyfikacie do momentu, gdy certyfikat jest potrzebny, podczas uzgadniania TLS. Jest to odpowiednie w przypadkach użycia, w których właściciel witryny nie kontroluje nazw domen obsługiwanych przez serwer. Aby zabezpieczyć się przed nadużyciami w sieci publicznej, właściciel witryny powinien skonfigurować punkt końcowy, do którego Caddy będzie wysyłał zapytanie, czy można uzyskać certyfikat dla danego wskazania nazwy serwera (SNI) w uzgadnianiu.

Caddy domyślnie implementuje zszywanie OCSP. Odpowiedzi OCSP dla wszystkich załadowanych certyfikatów, które określają obiekt odpowiadający OCSP w rozszerzeniu dostępu do informacji o urzędzie, zostaną zszyte, zapisane w pamięci podręcznej i automatycznie odświeżane w razie potrzeby. Jeśli odpowiedź OCSP wskazuje status Unieważniony dla zarządzanego certyfikatu, Caddy automatycznie podejmie próbę zastąpienia certyfikatu nowym.

Podczas obsługi TLS Caddy będzie okresowo automatycznie zmieniać klucze biletów sesji, aby pomóc zachować idealną poufność przekazywania. Te klucze mogą być również przechowywane w konfigurowalnym zapleczu i używane przez klaster instancji w celu poprawy wydajności w sposób rozproszony.

obiekty PKI

Aplikacja PKI jest standardowo dostarczana z oficjalnymi dystrybucjami Caddy. Jego głównym celem jest zarządzanie urzędami certyfikacji (CA), które mogą podpisywać certyfikaty. Każdy urząd certyfikacji składa się z pary kluczy głównego i pośredniego, które są utrwalane w pamięci masowej. Identyfikator urzędu certyfikacji, nazwa zwyczajowa i kluczowe informacje można dostosować w konfiguracji tego modułu. Ta aplikacja jest używana głównie przez inne moduły, gdy potrzebne są certyfikaty z podpisem własnym.

Wsparcie finansowe

Do 2016 roku Caddy działał całkowicie w ramach wolontariatu, bez żadnego wsparcia finansowego, po prostu przyjmując okazjonalne datki ze strony internetowej. Wraz z rozwojem społeczności i rosnącymi wymaganiami dotyczącymi czasu i infrastruktury na rozwój, zdecydowano, że projekt wymaga finansowania. Light Code Labs, LLC została utworzona, aby stać się podmiotem prawnym stojącym za Caddy. Mając legitymację prawną, pierwsza forma wsparcia finansowego pochodziła z Mozilla Open Source Support (MOSS) w 2016 r. Zapewniło to finansowanie na 6 miesięcy prac programistycznych i było kluczowe dla rozwoju Caddy na tym etapie.

Poszukując długoterminowej stabilności, Light Code Labs wkrótce zaoferowało dwa opcjonalne produkty dla firm i profesjonalistów: Pakiet Inżynieryjny i Sponsoring, które zapewniały klientom dostęp do zasobów dla programistów i reklamę. Z niewielkim sukcesem zdecydowano, że wycofanie tych produktów na rzecz dystrybucji oficjalnych plików binarnych przeznaczonych do użytku komercyjnego na licencji zastrzeżonej może zwiększyć zrównoważony rozwój poprzez wymaganie od firm płacenia za prawo do korzystania ze specjalnie oferowanych, wstępnie skompilowanych plików binarnych Caddy, które napędzał ich biznes. To pozostawiłoby kod źródłowy Caddy na licencji Apache , z którego każdy mógłby swobodnie korzystać, a jednocześnie nadal mógłby uzyskać wsparcie finansowe od zdolnych firm jako klientów.

Chociaż bardziej zrównoważone, podejście to było powszechnie postrzegane z pogardą i spotkało się z zamieszaniem i kontrowersjami w ciągu następnych kilku lat. Oferty produktów zostały dostosowane, aby wyjaśnić warunki, zdobyć szacunek społeczności i lepiej uchwycić sektor komercyjny. W 2019 roku firma Light Code Labs nawiązała współpracę z Ardan Studios w celu zaprojektowania i zbudowania całkowicie nowej wersji Caddy, która mogłaby być łatwiej wykorzystywana w środowiskach korporacyjnych: Caddy Enterprise. Jednak 3 października 2019 roku obie firmy ogłosiły plany zamiast tego cofnięcia wszystkich planów dotyczących licencji komercyjnych, które obejmowały:

  • potwierdzając, że Caddy nadal będzie i zawsze był projektem open source na licencji Apache,
  • zrezygnowanie z wszelkich prawnie zastrzeżonych licencji i usunięcie ograniczeń przypadków użycia biznesowego z oficjalnych plików binarnych,
  • rezygnacja z planów dotyczących funkcji tylko dla przedsiębiorstw,
  • rebranding nowej wersji Caddy po prostu jako Caddy 2,
  • oraz eliminując wszystkie inne istniejące produkty, subskrypcje i usługi przeznaczone wyłącznie dla firm.

Ardan Studios oferowało firmom profesjonalne szkolenia, rozwój Caddy i wsparcie dla przedsiębiorstw, a także zapewniało fundusze na pełnoetatowy rozwój projektu Caddy typu open source przez prawie rok. Krótko przed pierwszym wydaniem Caddy 2, Light Code Labs i Ardan Studios podpisały umowę dotyczącą przejęcia projektu Caddy (wraz z CertMagic , podstawową biblioteką automatyzacji TLS Caddy) przez API Layer, GmbH (później Stack Holdings, GmbH) . Przeniesienie własności zostało ogłoszone jeszcze w tym samym roku, we wrześniu 2020 roku, wraz z dwuletnią umową deweloperską. Ta wymiana nie zmieniła statusu open source ani cyklu rozwojowego projektu.

Od 2021 roku niezbędne wsparcie finansowe dla projektu Caddy jest kontynuowane w formie sponsoringu za pośrednictwem GitHub Sponsors, przy czym ZeroSSL (firma należąca do Stack Holdings) jest głównym sponsorem wykonawczym.

Wpływ

Caddy był używany jako podstawa dla innych projektów oprogramowania i usług komercyjnych, a jego zasięg rozciąga się na badania akademickie i dyskusje branżowe.

CoreDNS został stworzony przez Mieka Giebena z rozwidlenia Caddy v1, który został zmodyfikowany tak, aby obsługiwał DNS zamiast HTTPS. Wykorzystał format konfiguracji Caddyfile firmy Caddy, architekturę wtyczek i użycie języka Go.

Cloudflare zaimplementował usługę wykrywania machine-in-the-middle (MITM), pierwotnie opartą na Caddy, wykorzystującą natywne możliwości wykrywania MITM. Ta sama firma wykorzystała również Caddy do obsługi eksperymentalnej implementacji TLS 1.3, uczestnicząc jednocześnie w tworzeniu ostatecznej specyfikacji TLS 1.3.

Let's Encrypt uważa implementację ACME przez Caddy za złoty standard klientów ACME, a Caddy stał się wzorem do naśladowania dla podobnego oprogramowania.

Caddy brał udział w wielu pracach naukowych i umożliwił różne badania w Internecie. Powołano się na to w związku z:

  • walidacja wykonalności protokołu ACME na serwerach produkcyjnych,
  • QUIC na skalę internetową ,
  • framework testowy dla mechanizmów przełączania awaryjnego w chmurze,
  • mierzenie szkodliwości bezpieczeństwa skrótów kryptograficznych TLS,
  • opowiadanie się za bezpiecznym domyślnie TLS,
  • oraz poprawa użyteczności wdrażania protokołu HTTPS.

Linki zewnętrzne