Dlaczego nie zweryfikować samopodpisanych certyfikatów za pomocą rekordu DNS zamiast letsencrypt

16

Właśnie się zastanawiałem. Używamy wielu certyfikatów SSL. Obecnie prawie wyłącznie używamy letsencrypt (dzięki!). Najważniejsze w tych certyfikatach jest to, że dowód własności nazw domen na certyfikacie pochodzi z możliwości manipulowania rekordami DNS lub witryną pod tymi domenami. Dowód DNS pochodzi z dodania klucza (podanego przez letsencrypt) jako rekordu TXT do DNS.

Więc jeśli wystarczający dowód, aby móc zmienić rekordy DNS dla domeny, dlaczego nie skorzystać z samopodpisanych certyfikatów z odciskiem palca w DNS?

Powiedziałbym, że daje to dokładnie tyle samo zaufania co procedura letsencrypt (i innych urzędów certyfikacji) oparta na DNS:

  1. Utwórz samopodpisany urząd certyfikacji (po prostu postępuj zgodnie z instrukcjami różnych instrukcji)
  2. Utwórz certyfikat dla niektórych domen
  3. Podpisaj certyfikat z kroku 2 przy pomocy urzędu certyfikacji z kroku 1. Masz teraz certyfikat podstawowy podpisany przez niezaufany urząd certyfikacji
  4. Dodaj rekord TXT (lub dedykowany) do DNS każdej z domen, stwierdzając: podpisaliśmy certyfikat tej domeny za pomocą tego urzędu certyfikacji. Na przykład: „CA = -palec CA”
  5. Przeglądarka pobiera certyfikat i weryfikuje go poprzez porównanie odcisku palca certyfikatu CA / CA z danymi w DNS dla danej domeny.

Umożliwiłoby to tworzenie zaufanych certyfikatów samopodpisanych bez ingerencji strony trzeciej, na tym samym poziomie zaufania, co każdy podstawowy certyfikat SSL. Tak długo, jak masz dostęp do DNS, twój certyfikat jest ważny. Można nawet dodać szyfrowanie DNSSEC, np. Utworzyć skrót z urzędu certyfikacji i rekord SOA, aby upewnić się, że zaufanie zniknie po zmianach w rekordzie DNS.

Czy zostało to wcześniej rozważone?

Jelmer

Jelmer Jellema
źródło
3
Ważne: tools.ietf.org/html/rfc6698
Håkan Lindqvist
Dzięki Håkan! Dzięki aktualizacji znalazłem termin DANE dla tego RFC. Ostatnia wersja RFC: tools.ietf.org/html/rfc7671 Zobacz także: en.wikipedia.org/wiki/… (przeczytam później).
Jelmer Jellema
2
„Dlaczego nie” jest również uwzględnione w powiązanym RFC Håkan: bez DNSSEC, niezawodność całego modelu jest zagrożona z powodu podatności związanych z DNS. Należy również zauważyć, że DNSSEC nie robi nic, aby zabezpieczyć ruch między klientami a systemami rekurencyjnymi, co pozostaje podatne na ataki w środkowym fałszowaniu.
Andrew B,
Andrew, widzę problem z DNSSEC i MIDM, gdy DNSSEC nie jest wymuszony dla domeny, a wymuszenie można wykonać tylko wtedy, gdy każde wyszukiwanie jest wykonywane przez sprawdzenie serwera domeny root dla tld. Problem w tym, że: chcemy autoryzować użycie niektórych certyfikatów DV, podając stan właściciela, że ​​jest ważny, ale nie możemy ufać DNS z powodu jego hierarchicznej natury. Fakt, że DNS jest podatny na fałszowanie i ataki MIDM, sprawia, że ​​certyfikaty DV są jakby zewnętrzną weryfikacją wpisu domeny. Hmm, będę nadal myśleć ...
Jelmer Jellema

Odpowiedzi:

18

Podstawowa infrastruktura, która by to umożliwiała, istnieje i nazywa się uwierzytelnianiem nazwanych podmiotów (DANE) na podstawie DNS i jest określona w RFC6698 . Działa za pomocą TLSArekordu zasobu, który określa certyfikat lub jego klucz publiczny jednostki końcowej lub jednego z jego urzędów certyfikacji w łańcuchu (W rzeczywistości istnieją cztery różne typy, szczegółowe informacje można znaleźć w dokumencie RFC).

Adopcja

DANE nie spotkało się jeszcze z powszechnym przyjęciem. VeriSign monitoruje adopcję DNSSEC i DANE i śledzi jej rozwój w czasie :

Wdrożenie na całym świecie TLSA między 17 czerwca

Dla porównania, według VeriSign, istnieje około 2,7 miliona stref DNS, co oznacza, że ​​nieco ponad 1% wszystkich stref ma co najmniej jeden rekord TLSA.

Nie mogę udzielić żadnej wiarygodnej odpowiedzi, dlaczego DANE, ale oto moje spekulacje:

DANE cierpi na ten sam problem, co listy odwołania certyfikatów (CRL) i protokół statusu certyfikatu online (OCSP). W celu weryfikacji ważności przedstawionego certyfikatu należy skontaktować się z osobą trzecią. Hanno Böck daje dobry przegląd , dlaczego jest to duży problem w praktyce. Sprowadza się to do tego, co robić, gdy nie możesz skontaktować się z osobą trzecią. Dostawcy przeglądarek zdecydowali się na soft-fail (aka zezwolenie) w tym przypadku, co sprawiło, że całość była raczej bezcelowa, a Chrome ostatecznie zdecydował się wyłączyć OCSP w 2012 roku.

DNSSEC

Prawdopodobnie DNS oferuje znacznie lepszą dostępność niż serwery CRL i OCSP urzędów certyfikacji, ale nadal uniemożliwia weryfikację offline. Ponadto DANE, powinien być używany tylko w połączeniu z DNSSEC. Ponieważ normalny DNS działa na nieuwierzytelnionym UDP, jest dość podatny na fałszowanie, ataki MITM itp. Przyjęcie DNSSEC jest znacznie lepsze niż przyjęcie DANE, ale wciąż jest dalekie od wszechobecnego.

A dzięki DNSSEC ponownie napotykamy problem miękkiej awarii. O ile mi wiadomo, żaden główny system operacyjny serwera / klienta domyślnie nie zapewnia sprawdzania poprawności DNSSEC.

Następnie pojawia się również kwestia odwołania. DNSSEC nie ma mechanizmu odwoływania i zamiast tego polega na kluczach krótkotrwałych.

Wsparcie oprogramowania

Całe oprogramowanie uczestniczące musi implementować obsługę DANE.

Teoretycznie może się wydawać, że byłoby to zadaniem bibliotek kryptograficznych, a twórcy aplikacji nie musieliby wiele robić, ale faktem jest, że biblioteki kryptograficzne zwykle dostarczają tylko prymitywów, a aplikacje same muszą wykonać wiele konfiguracji i konfiguracji (i niestety istnieje wiele sposobów, aby naprawić błędy).

Nie wiem, czy jakikolwiek większy serwer WWW (np. Apache lub nginx) na przykład zaimplementował DANE lub planuje to zrobić. Serwery sieciowe mają tutaj szczególne znaczenie, ponieważ coraz więcej rzeczy opiera się na technologiach internetowych, dlatego często są one pierwszymi, w których rzeczy są wdrażane.

Kiedy porównamy CRL, OCSP i OCSP Stapling, możemy być w stanie wywnioskować, jak potoczy się historia adopcji DANE. Tylko niektóre aplikacje korzystające z OpenSSL, libnss, GnuTLS itp. Obsługują te funkcje. Zajęło to trochę czasu, zanim główne oprogramowanie, takie jak Apache lub nginx, wspierało go i ponownie powracając do artykułu Hanno Böcka, źle zrozumieli i ich implementacja jest wadliwa. Inne duże projekty oprogramowania, takie jak Postfix lub Dovecot , nie obsługują OCSPi mają bardzo ograniczoną funkcjonalność CRL, zasadniczo wskazując na plik w systemie plików (który niekoniecznie musi być ponownie odczytywany regularnie, więc trzeba będzie ręcznie przeładowywać serwer itp.). Pamiętaj, że są to projekty, które często korzystają z TLS. Następnie możesz zacząć szukać rzeczy, w których TLS jest znacznie mniej powszechny, na przykład PostgreSQL / MySQL, a może oferują one w najlepszym razie listy CRL.

Więc nie wdrożyłem go nawet w nowoczesnych serwerach sieciowych, a większość innych programów nawet nie wdrożyła OCSP i CRL, powodzenia z 5-letnią aplikacją lub urządzeniem dla przedsiębiorstw.

Potencjalne aplikacje

Więc gdzie właściwie możesz użyć DANE? Na razie nie w ogólnym Internecie. Jeśli kontrolujesz serwer i klienta, być może jest to opcja, ale w tym przypadku często możesz skorzystać z przypinania klucza publicznego.

W przestrzeni pocztowej DANE zyskuje pewną trakcję, ponieważ SMTP przez długi czas nie miał żadnego uwierzytelnionego szyfrowania transportowego. Serwery SMTP czasami używały TLS między sobą, ale nie weryfikowały, czy nazwy w certyfikatach rzeczywiście pasowały, teraz zaczynają to sprawdzać za pośrednictwem DANE.

Sebastian Schrader
źródło
6
Myślę, że twoje ostatnie zdanie zostało ucięte.
8bittree,
Dziękuję Sebastianowi, twoja reakcja jest bardzo pomocna. Proszę zobaczyć komentarze mojego i Andrzeja w OP.
Jelmer Jellema
3
Dlaczego serwery WWW muszą to zaimplementować? Mogę dodać samopodpisany certyfikat do konfiguracji Apache i sam wprowadzić odcisk palca w DNS, prawda?
Jelmer Jellema
1
Występują również problemy z wydajnością i skalowalnością w stosunku do DNSSEC vs. DNS: zwykły DNS może używać odpowiedzi „w puszce”, ale DNSSEC musi wykonać szyfrowanie dla każdego żądania, a wokół jest mnóstwo żądań DNS. Na przykład dużo żądań DNS.
Joker_vD
4
@Joker_vD DNSSEC podpisuje dane, a nie ruch. To znaczy, na autorytatywnym końcu możesz podpisać swoją strefę i nie mieć więcej „kryptodancji” przez cały okres życia podpisów (lub do czasu zmiany danych strefy); po stronie walidatora (po stronie klienta) musi wystąpić „kryptodancja” na żądanie Zarówno dodatkowe dane, jak i status DNSSEC są zgodne z ogólnym modelem buforowania dla DNS.
Håkan Lindqvist
5

Różne rodzaje procedur sprawdzania poprawności certyfikatów

W przypadku zwykłych certyfikatów podpisanych przez urząd certyfikacji istnieje kilka poziomów sprawdzania poprawności certyfikatów:

  • Sprawdzanie poprawności domeny (DV) Sprawdzane jest
    tylko prawo własności do domeny, tylko nazwa domeny jest wyświetlana jako „Temat” na certyfikacie
  • Sprawdzanie poprawności organizacji (OV)
    Nazwa domeny i nazwa właściciela są sprawdzane, nazwa domeny i nazwa właściciela są wyświetlane w certyfikacie jako „podmiot”
  • Rozszerzona walidacja (EV)
    Bardziej rygorystyczne sprawdzanie poprawności jednostki właściciela, nazwy domeny i nazwy właściciela pokazuje się w certyfikacie jako „podmiot”, zielony pasek z nazwą właściciela

Proces, który opisujesz i proponujesz zamianę, dotyczy tylko najniższego poziomu, Walidacji Domeny (DV).

DV to poziom, na którym walidacja jest stosunkowo łatwa do zautomatyzowania, na przykład to, co zrobiła LetsEncrypt, i zapewnia podobny poziom zaufania, co DNS mógłby zapewnić, gdyby był używany jako jedyne źródło kotwicy zaufania (implikacje interfejsu użytkownika, cert mogą zaufaj, ale zawierają dodatkowe dane, które nie są w żaden sposób sprawdzane).

Uwierzytelnianie nazwanych podmiotów na podstawie DNS (DANE)

DANE opiera się na DNSSEC (ponieważ autentyczność danych DNS jest kluczowa), aby publikować informacje kotwicy zaufania dla klientów TLS w DNS.

Wykorzystuje TLSAtyp RR i może być używany do identyfikacji certyfikatu lub klucza publicznego ( selektora ) jednostki końcowej lub urzędu certyfikacji, z wymaganiem lub bez regularnego sprawdzania poprawności łańcucha certyfikatów ( użycie certyfikatu ) oraz w jaki sposób certyfikat Dane klucza / są reprezentowane w rekordzie ( typ dopasowania ).

TLSANazwa właściciela rekordu ma prefiks, który wskazuje port i protokół (np _443._tcp) i RData wskazuje cert usage, selectori matching typetryby oprócz CERT / kluczowe dane na mecz. Szczegółowe informacje na temat tych parametrów znajdują się w sekcji 2.1 RFC6698 .

TLSAMożna nagrywać na przykład wyglądać tak:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

W trybach użytkowania 2lub 3(wskazuje na użycie samej kotwicy zaufania TLSA) klient obsługujący DANE zaakceptowałby certyfikat, który nie jest podpisany przez ogólnie zaufany urząd certyfikacji, ale pasuje do TLSArekordu.
Jest to koncepcyjnie to samo, co proponujesz w swoim pytaniu.

Haczyk? Klienci obsługujący DANE są obecnie mniej lub bardziej nieistniejący, jednym z problemów jest to, że sam DNSSEC nie jest tak szeroko wdrażany (szczególnie sprawdzanie poprawności na komputerze klienckim), jak to prawdopodobnie byłoby wymagane, aby DANE mógł wystartować. Prawdopodobnie trochę problemu z kurczakiem i jajami, biorąc pod uwagę, że DANE jest jednym z pierwszych potencjalnie dużych nowych przypadków użycia, które opierają się na uwierzytelnionych danych DNS.

Istnieje wtyczka do przeglądarki, która dodaje sprawdzanie poprawności DNSSEC i DANE , poza tym, że w tym momencie nie ma prawie nic, co jest blisko głównego nurtu. Jako że jest to wtyczka, a nie natywna obsługa, służy ona bardziej jako dowód koncepcji niż cokolwiek innego, jeśli chodzi o ogólne zastosowanie.


Da się zrobić. Zostało to rozważone. Może się to zdarzyć, ale ruch nie był duży.

Håkan Lindqvist
źródło
Dzięki Håkan. Jak Andrew wskazuje w moim OP, istnieje problem z DNS i DNSSEC, ponieważ DNSSEC nie jest wymuszony (nawet, gdy klucze znajdują się na d DNS TLD, chyba) serwery DNS po drodze mogą sfałszować informacje DANE , dobrze? Dlatego DNSSEC powinien być zobowiązany do zachowania ważności rekordów DANE, co z kolei oznacza, że ​​każda kontrola musi również sprawdzać klucze na serwerze TLD.
Jelmer Jellema
5
@JelmerJellema Jak zauważyłem w mojej odpowiedzi, DNSSEC musi zostać zweryfikowany na kliencie (nie robienie tego jest problemem, na który wskazał Andrew) i można używać tylko pomyślnie potwierdzonych podpisanych rekordów TLSA. Ten problem, o którym mówisz, nie jest problemem w zakresie projektowania, jest to problem w zakresie wsparcia w głównym oprogramowaniu.
Håkan Lindqvist
2
Chociaż nie jest to idealne, coraz więcej rekurencyjnych serwerów nazw u dostawców usług internetowych lub otwartych, takich jak 8.8.8.8 lub 9.9.9.9, sprawdza poprawność DNSSEC. dnssec-trigger zbudowany na niezwiązanych i / lub takich rzeczach, jak skrót, pozwoliłby na pełną weryfikację DNSSEC na klientach bez koniecznej pełnej weryfikacji DNS na kliencie. Ale rzeczywiście daleko nam do tego ...
Patrick Mevzek