en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Delegowane poświadczenia dla TLS

Zakończenie a TLS połączenie wymaga użycia klucza prywatnego certyfikatu. W rezultacie klucz prywatny musi być przechowywany na każdym serwerze używanym przez usługę. Ochrona tajemnicy tego klucza prywatnego ma kluczowe znaczenie dla sprawnego działania schematu Infrastruktury Klucza Publicznego. Podmiot posiadający klucz prywatny może przeprowadzać ataki typu man-in-the-middle przez pozostały okres ważności certyfikatu. Zazwyczaj, gdy osoba atakująca złamie klucz prywatny, certyfikat skojarzony z tym kluczem jest unieważniany i wystawiany jest nowy. Jednak w przypadku przedsiębiorstw korzystających z wielu serwerów, takich jak Facebook lub Sieci dostarczania treści, kluczowe kompromisy, zwłaszcza w serwerach brzegowych, nie są łatwe do wykrycia, co zagraża całej sieci. Delegowane poświadczenia pozwalają serwerom działać TLS uściski dłoni, a klucz prywatny certyfikatu jest przechowywany w bezpiecznej lokalizacji.

Delegowane poświadczenia to podpisane cyfrowo struktury danych składające się z dwóch części: przedziału ważności i klucza publicznego (wraz z powiązanym algorytmem podpisu). Służą jako „pełnomocnictwo”dla serwerów wskazujących, że są upoważnieni do zakończyć TLS połączenia. Proces wydawania delegowanych danych uwierzytelniających jest obecnie w trakcie standaryzacji i zdefiniowany w niniejszym Wersja robocza IEFT. Projekt definiuje użycie delegowanych poświadczeń w następujący sposób:
 
„Ograniczony mechanizm delegowania, który umożliwia TLS peer do wystawiania własnych poświadczeń w zakresie certyfikatu wystawionego przez zewnętrzny urząd certyfikacji. Te poświadczenia umożliwiają tylko odbiorcy delegacji wypowiadanie się w imieniu autoryzowanych przez urząd certyfikacji”.
Poświadczenia delegowane zostały zaprojektowane w celu zwiększenia bezpieczeństwa. W związku z tym posiadają pewne cechy, określone w projekcie IEFT.
  • Maksymalny okres ważności delegowanego poświadczenia to siedem (7) dni w celu zminimalizowania narażenia, jeśli klucz prywatny zostanie naruszony. Krótki okres ważności nie oznacza, że ​​należy lekceważyć bezpieczeństwo delegowanych danych uwierzytelniających. Środki podjęte w celu ochrony klucza prywatnego certyfikatu podmiotu końcowego powinny mieć również zastosowanie do ochrony DC. Obejmują one między innymi kontrolę systemu plików, zabezpieczenia fizyczne i moduły zabezpieczeń sprzętowych. Ponadto delegowane poświadczenia powinny być używane tylko między stronami, które dzielą ze sobą pewną relację zaufania.
  • Delegowane poświadczenia to związany kryptograficznie do certyfikatu podmiotu końcowego. W szczególności klucz prywatny certyfikatu jednostki końcowej jest używany do obliczania podpisu kontrolera domeny za pomocą algorytmu określonego przez poświadczenie. Podpis skutecznie wiąże kontroler domeny z nazwami certyfikatu jednostki końcowej.
  • Poświadczenia delegowane są wydawane przez klienta, co jest znacznie łatwiejsze niż tworzenie certyfikatu podpisanego przez CA. Certyfikaty wydawane przez klienta są również pomocne w utrzymaniu działania usługi nawet w przypadku przestojów urzędu certyfikacji. Ponadto organizacje mogą eksperymentować z algorytmami, które nie są oficjalnie obsługiwane przez urząd certyfikacji, bez narażania bezpieczeństwa certyfikatu jednostki końcowej. 
  • Poświadczenia delegowane mają z definicji krótkie okresy ważności. Podczas ustawiania okresu istnienia delegowanych poświadczeń serwery muszą wziąć pod uwagę przesunięcie zegara klienta, aby uniknąć odrzucenia certyfikatów. Przekrzywienie zegara klienta jest również ważne dla oryginalnego certyfikatu, ale ma kluczowe znaczenie dla krótkotrwałego delegowanego klucza prywatnego. Należy wziąć pod uwagę przesunięcie zegara klienta zarówno na początku, jak i na końcu okresu ważności.
  • Nie ma mechanizmu odwołania poświadczeń delegowanych. Tracą ważność po upływie okresu ważności. Jednak odwołanie klucza prywatnego certyfikatu jednostki końcowej (który jest używany do podpisywania delegowanych poświadczeń) niejawnie odwołuje delegowane poświadczenia. 
  • Poświadczenia delegowane są przeznaczone do użytku w TLS 1.3 lub później. Istnieje znana luka w zabezpieczeniach, gdy TLS Serwery 1.2 obsługują wymianę kluczy RSA, umożliwiając sfałszowanie podpisu RSA na dowolnej wiadomości. Załóżmy, że atakujący jest w stanie sfałszować podpis. W takim przypadku mogą tworzyć sfałszowane poświadczenia delegowane na cały okres ważności certyfikatu jednostki końcowej. Ta podatność nie występuje w implementacjach TLS 1.3 lub nowszy. Podatność nie dotyczy również certyfikatów z kryptografią krzywych eliptycznych, które: SSL.com zapewnia. 
  • Organizacje mogą korzystać z istniejących interfejsów API automatycznego wystawiania, takich jak ACME, do dostarczania delegowanych danych uwierzytelniających. W tym przypadku wykorzystywane są tylko algorytmy obsługiwane przez urząd certyfikacji, ale taka praktyka ogranicza możliwość kluczowych kompromisów. SSL.com popiera tę praktykę. 
  • Poświadczeń delegowanych nie można ponownie używać w wielu kontekstach. Strony wystawiające obliczają podpis przy użyciu ciągu kontekstowego unikalnego dla zamierzonej roli (klienta lub serwera), uniemożliwiając w ten sposób użycie tego samego delegowanego poświadczenia do uwierzytelniania klienta i serwera. 
SSL.com obsługuje korzystanie z delegowanych poświadczeń dla wszystkich klientów. Wydawanie certyfikatów obsługujących dane uwierzytelniające delegowane może odbywać się za pomocą interfejsów API do automatyzacji przy użyciu protokołu ACME. Odkąd SSL.com wykorzystuje ECDSA do wdrożenia PKI oferowane do klientów, delegowane dane uwierzytelniające wydane przez naszych klientów nie są podatne na ataki polegające na fałszowaniu sygnatur, jak opisano powyżej. 

Powiązane artykuły

Subskrybuj biuletyn SSL.com

Co to jest SSL /TLS?

Odtwórz wideo

Subskrybuj biuletyn SSL.com

Nie przegap nowych artykułów i aktualizacji z SSL.com