Caddy (serwer WWW) - Caddy (web server)

Nosiciel kijów golfowych
Ikona kłódki Caddy 2 i logotyp.svg
Pierwotny autor (autorzy) Mateusz Holt
Pierwsze wydanie 28 kwietnia 2015 r .; 6 lat temu ( 28.04.2015 )
Wersja stabilna
2.4.5 / 3 września 2021 r .; 40 dni temu ( 2021-09-03 )
Magazyn github .com /caddyserver /caddy
Napisane w Udać się
System operacyjny Warianty BSD , Linux , Plan 9 , macOS i Windows
Platforma IW-32 (i386), x86-64 , ARM , MIPS , s390x , jabłko krzem
Rodzaj Serwer WWW , odwrotny serwer proxy
Licencja Apache 2
Strona internetowa caddyserver .com Edytuj to na Wikidata

Caddy serwer WWW jest rozciągliwy , cross-platform , open-source serwer www napisany w Go .

Nazwa „Caddy” odnosi się zarówno do pomocnika do żmudnych zadań, jak i sposobu na zorganizowanie wielu części w uproszczony system. U podstaw Caddy jest rozszerzalna platforma 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 rozpoczął samodzielny rozwój Caddy w 2014 roku, a następnie jego pierwsze publiczne wydanie w 2015 roku. Oprogramowanie wkrótce stało się publiczną współpracą z setkami współtwórców na GitHub. Aby spełnić wymagania rosnącej społeczności z różnymi przypadkami użycia , Caddy został ostatecznie napisany od nowa, a wersja 2.0 została wydana 4 maja 2020 roku.

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

Architektura

Architektura Caddy składa się z trzech głównych elementów: polecenia , podstawowej biblioteki i modułów konfiguracyjnych. Polecenie jest rozszerzalnym interfejsem, za pomocą którego wykonywany jest program ; może również ładować pliki konfiguracyjne , uruchamiać typowe tryby, zarządzać zainstalowanymi wtyczkami i oferować odpowiednie funkcje narzędziowe. Podstawowa biblioteka ma interfejsy API do ładowania, rozładowywania i zarządzania konfiguracją ; ale sam w sobie nie robi nic szczególnie użytecznego. Większość funkcjonalności Caddy jest dostarczana przez moduły , które są wtyczkami rozszerzającymi strukturę konfiguracji Caddy; na przykład serwer HTTP jest modułem. Moduły Caddy implementują 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 interfejsu API RESTful HTTP. W przypadku braku klienta HTTP, interfejs wiersza poleceń Caddy może być używany do ładowania plików konfiguracyjnych. Adaptery konfiguracyjne mogą być używane do konwertowania innych formatów konfiguracji na JSON . Istniejące adaptery obejmują Caddyfile, który ma pierwszorzędną obsługę w wierszu poleceń; i 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 uruchamia wszystkie moduły aplikacji. Gdy moduły aplikacji są aprowizowane, same mogą ładować i udostępniać moduły, z których korzystają. Na przykład serwer HTTP jest modułem 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 ich funkcjonalności i tak dalej. Wszystkie te moduły są udostępniane w fazie ładowania konfiguracji.

Wtyczki są instalowane przez statyczne kompilowanie ich 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ć zapewniane przez moduły aplikacji. Oficjalne dystrybucje Caddy są dostarczane z dziesiątkami standardowych modułów; inne można dodać z witryny 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 odwrotny serwer proxy równoważący obciążenie. Podczas gdy podstawy funkcji HTTP Caddy wykorzystują implementację znalezioną w standardowej bibliotece Go, różne ulepszenia i dostosowania są dostępne jako oprogramowanie pośrednie i udostępniane poprzez parametry konfiguracyjne:

Serwer HTTP Caddy obsługuje żądania zgodnie ze skonfigurowanymi trasami we wzorcu oprogramowania pośredniego. Trasy są zdefiniowane na liście, a każda trasa, która pasuje do żądania, jest stosowana w kolejności do łańcucha oprogramowania pośredniczącego. Żądania mogą być dopasowywane z 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średniczące do przepisywania, odwrotny serwer proxy, ograniczanie szybkości, manipulację nagłówkiem i renderowanie szablonów. Dodatkowo można zdefiniować trasy, aby wzajemnie wykluczały się z innymi trasami lub terminalem, który kończy łańcuch obsługi.

Domyślnie TLS jest używany automatycznie, jeśli jakiekolwiek trasy mają niepusty program 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 jest aktywowany w ten sposób, Caddy przekieruje również żądania HTTP do ich równoważnej 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 podatny na luki w zabezpieczeniach pamięci, takie jak Heartbleed, ponieważ jest napisane w Go. Jednym z głównych celów tego modułu jest ładowanie certyfikatów TLS do pamięci, aby można je było obsłużyć w celu ukończenia uzgadniania TLS. Pliki certyfikatów i kluczy mogą być ładowane ręcznie na serwer, ale zwykle są one zautomatyzowane poprzez określenie nazw podmiotów. W przypadku ręcznego ładowania 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ą pasującą zasadą automatyzacji dla jego nazwy podmiotu (zazwyczaj nazwy domeny lub adresu IP ). Zasady automatyzacji składają się z wystawców oraz różnych opcji certyfikatów i zarządzania, takich jak typ klucza, miejsce przechowywania certyfikatu, zarządzanie certyfikatem „na żądanie” oraz opcje OCSP . Te funkcje automatyzacji działają zarówno dla 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, wiązanie kont zewnętrznych (EAB), wiele łańcuchów certyfikatów i inteligentną heurystykę ponawiania prób. Caddy może być również własnym wydawcą dzięki wbudowanym funkcjom PKI. Dla nadmiarowości można określić wielu emitentów; jeśli jeden nie zaoferuje certyfikatu, zostanie wypróbowany następny.

Certyfikaty TLS mogą być przechowywane w konfigurowalnym zapleczu magazynu, którym domyślnie jest lokalny system plików. Wtyczki istnieją dla innych rodzajów zaplecza pamięci masowej, takich jak bazy danych. Instancje Caddy 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. Caddy obsługuje jednak tryb automatyzacji zwany On-Demand TLS, który odracza operacje certyfikatu do momentu, w którym 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 zapyta, czy można uzyskać certyfikat dla danego wskaźnika nazwy serwera (SNI) w trakcie uzgadniania.

Caddy domyślnie implementuje zszywanie OCSP. Wszystkie załadowane certyfikaty, które określają respondenta OCSP w rozszerzeniu dostępu do informacji o urzędach, będą miały odpowiedź OCSP zszytą, zbuforowaną i automatycznie odświeżoną w razie potrzeby. Jeśli odpowiedź OCSP wskazuje status Unieważniony dla zarządzanego certyfikatu, Caddy automatycznie spróbuje zastąpić certyfikat nowym.

Podczas obsługi TLS Caddy automatycznie będzie okresowo zmieniać klucze biletów sesji, aby pomóc zachować idealną tajemnicę 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 magazynie. W konfiguracji tego modułu można dostosować identyfikator urzędu certyfikacji, nazwę zwyczajową i informacje o kluczu. 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ła całkowicie dzięki wolontariatowi bez żadnego wsparcia finansowego, po prostu przyjmując okazjonalne darowizny ze strony internetowej. Wraz ze wzrostem społeczności i wzrostem wymagań dotyczących czasu rozwoju i infrastruktury, ustalono, że projekt musi zostać sfinansowany. Firma Light Code Labs, LLC została utworzona, aby stać się podmiotem prawnym stojącym za Caddy. Z prawnego punktu widzenia, pierwsza forma wsparcia finansowego pochodziła z nagrody programu Mozilla Open Source Support (MOSS) w 2016 roku. Zapewniło to finansowanie przez 6 miesięcy prac rozwojowych i było kluczowe dla rozwoju Caddy na tym etapie.

Poszukując długoterminowego zrównoważonego rozwoju, firma Light Code Labs wkrótce zaoferowała dwa opcjonalne produkty dla firm i profesjonalistów: pakiet inżynieryjny i sponsoring, które zapewniają klientom dostęp do zasobów deweloperskich i reklamy. Z niewielkim sukcesem zdecydowano, że stopniowe wycofywanie tych produktów na rzecz dystrybucji oficjalnych plików binarnych przeznaczonych do użytku komercyjnego na podstawie licencji własnościowej może zwiększyć zrównoważony rozwój, wymagając od firm płacenia za prawo do używania 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, aby każdy mógł swobodnie używać, a jednocześnie nadal byłby w stanie uzyskać pewne wsparcie finansowe od zdolnych firm jako klientów.

Choć bardziej zrównoważone, podejście to było powszechnie postrzegane z pogardą, aw ciągu następnych kilku lat spotkało się z zamieszaniem i kontrowersją. Oferty produktów zostały dostosowane w celu wyjaśnienia warunków, zdobycia szacunku społeczności i lepszego ujęcia sektora komercyjnego. W 2019 roku firma Light Code Labs nawiązała współpracę z Ardan Studios, aby zaprojektować i zbudować zupełnie nową wersję Caddy, która może być łatwiej wykorzystywana w środowiskach korporacyjnych: Caddy Enterprise. Jednak 3 października 2019 r. obie firmy ogłosiły plany wycofania wszystkich planów dotyczących licencji komercyjnych, które obejmowały:

  • potwierdzając, że Caddy nadal będzie i zawsze było projektem open source na licencji Apache,
  • porzucenie wszelkich licencji własnościowych i usunięcie ograniczeń biznesowych przypadków użycia z oficjalnych plików binarnych,
  • rezygnacja z planów dla funkcji tylko dla przedsiębiorstw,
  • rebranding nowej wersji Caddy na po prostu Caddy 2,
  • oraz wyeliminowanie wszystkich innych istniejących produktów, subskrypcji i usług przeznaczonych wyłącznie dla firm.

Ardan Studios przystąpiło do oferowania profesjonalnego szkolenia, rozwoju Caddy i wsparcia dla przedsiębiorstw, a także zapewniło finansowanie w pełnym wymiarze czasu wolnego rozwoju projektu Caddy przez prawie rok. Krótko przed pierwszym wydaniem Caddy 2, Light Code Labs i Ardan Studios podpisały umowę na projekt Caddy (wraz z CertMagic , podstawową biblioteką automatyzacji TLS Caddy), który ma zostać przejęty przez API Layer, GmbH (później Stack Holdings, GmbH) . Przeniesienie własności zostało ogłoszone później we wrześniu 2020 roku wraz z dwuletnią umową deweloperską. Ta wymiana nie zmieniła statusu open source ani cyklu rozwojowego projektu.

Od 2021 r. niezbędne wsparcie finansowe dla projektu Caddy jest kontynuowane poprzez sponsoring za pośrednictwem sponsorów GitHub , przy czym ZeroSSL (spółka 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 Mika Giebena z forka Caddy v1, który został zmodyfikowany do obsługi DNS zamiast HTTPS. Wykorzystał format konfiguracji Caddyfile Caddy, architekturę wtyczek i język Go.

Cloudflare wdrożył 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 w tworzeniu ostatecznej specyfikacji TLS 1.3.

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

Caddy brał udział w wielu pracach naukowych i umożliwił różne badania w Internecie. Odniesiono się do niego w odniesieniu do:

  • walidacja wykonalności protokołu ACME na serwerach produkcyjnych,
  • wdrożenie QUIC na skalę internetową,
  • framework testowy dla mechanizmów cloud failover,
  • mierzenie szkód w bezpieczeństwie skrótów kryptograficznych TLS,
  • występowanie w sprawie domyślnie bezpiecznego TLS,
  • oraz poprawę użyteczności wdrażania protokołu HTTPS.

Bibliografia

Zewnętrzne linki