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

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 :

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.

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.