Certificate Transparency nabiera rozpędu

Certificate Transparency nabiera rozpędu

W ostatnim czasie mogliśmy przeczytać o kilku wydarzeniach (o jednym z nich nawet pisałem), które przyczynią się do rozwoju mechanizmu Certificate Transparency (CT). W najbliższej przyszłości czeka nas też kilka zmian, które sprawią, że mechanizm zaprojektowany przez Google będzie wykorzystywany na szeroką skalę.

Certificate Transparency w pigułce

Jakie są cele mechanizmu Certificate Transparency? Zgodnie z założeniami jego twórców są to:

  • uniemożliwienie lub znacznie utrudnienie wydania przez CA certyfikatu na domenę bez wiedzy jej właściciela,
  • stworzenie otwartego systemu, który pozwoliłby właścicielowi danej domeny lub też CA na łatwiejsze określenie czy dany certyfikat nie został wydany błędnie,
  • ochrona użytkowników przez konsekwencjami wiążącymi się z nieprawidłowo wydanym certyfikatem.
Zagrożenia PKI (źródło: certificate-transparency.org)

Zagrożenia PKI (źródło: certificate-transparency.org)

W praktyce mechanizm CT może wyglądać tak, że CA wydając certyfikat musi najpierw wydać tzw. precertyfikat i wysłać go do serwera logów. Serwer logów zwraca tzw. znacznik SCT (Signed Certificate Timestamp), a CA dodaje go do struktury certyfikatu w jednym z rozszerzeń.

W poprzednim akapicie celowo użyłem słowa „może”, powodem jest ostatni jego fragment. Otóż, dodanie SCT do struktury certyfikatu jest tylko jedną z trzech możliwości na dostarczenie informacji o tym kiedy i do jakiego serwera logów został dodany certyfikat. Więcej o pozostałych dwóch metodach i innych szczegółach technicznych CT postaram się napisać już wkrótce.

Korzyści CT

Korzyści CT (źródło: certificate-transparency.org)

Kolejne serwery logów

Obecnie na oficjalnej liście projektu CT znajduje się siedem aktywnych serwerów logów, z czego sześć przystosowanych jest do użycia produkcyjnego, a jeden powstał na potrzeby testowe. Z sześciu produkcyjnych, na ten moment, tylko dwa (oba należą do Google) wykorzystywane są w Chrome. W następnej wersji przeglądarki do tej pary powinien dołączyć serwer logów stworzony przez niezależny od Google Urząd Certyfikacji, Digicert.

Wśród oczekujących na zatwierdzenie znajdują się między innymi serwery logów należące do Izenpe i Certly, a zapewne już niedługo w tej kolejce ustawi się serwer przygotowany przez firmę Venafi. Sam proces zatwierdzania danego serwera logów to, oprócz sprawdzenia zgodności z założeniami projektowymi, głównie weryfikacja i potwierdzenie wysokiej jego dostępności.

Póki co tylko Chrome…

Dzisiaj, spośród najpopularniejszych przeglądarek jedynie Chrome weryfikuje czy certyfikat został poddany audytowi przejrzystości (czyt. został wydany zgodnie z założeniami CT) i to polityka zmian wprowadzanych przez Google nadaje tempa całej akcji.

Kolejna wersja Chrome przyniesie zmiany w traktowaniu certyfikatów SSL typu EV (Extended Validation), które zostały wydane po 1 stycznia 2015 (certyfikaty wydane wcześniej zostaną odcięte “grubą kreską” i nie będą uwzględniane w zmianach), a nie przedstawią się znacznikiem SCT. Chrome nie będzie wyświetlał w takim przypadku zielonego paska przy nazwie domeny w pasku adresu. Oznacza to pozbawienie certyfikatów EV SSL dużego przywileju, jakim bez wątpienia jest wspomniany zielony pasek. Na tę chwilę inne niż EV typy certyfikatów SSL nie będą podlegały zmianom.

Podziel się:Share on Facebook
Facebook
0Tweet about this on Twitter
Twitter

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *