O korzyściach, ale także o ryzykach stosowania HTTP Public Key Pinning (HPKP) wspominałem już na Kryptosferze. Dzisiaj krótka historia o tym jak nieumiejętna konfiguracja HPKP mogła spowodować zablokowanie dostępu do aplikacji mobilnej jednego z największych banków w Wielkiej Brytanii.

Pułapka HPKP

HPKP pozwala na powiązać klucz publiczny z domeną. Tym kluczem może być klucz z wykorzystywanego przez nas certyfikatu SSL. Mamy wtedy pewność, że żaden inny certyfikat niż nasz (np. ten podstawiony przez atakującego nasz serwer) nie zadziała poprawnie w przeglądarkach które HPKP wspierają (wśród desktopowych wydań są to Chrome, Firefox i Opera; wśród mobilnych Android Browser i Chrome dla Androida).

HPKP pozwala także na przypięcie do domeny klucza publicznego certyfikatu urzędu certyfikacji (pośredniego lub głównego). Wtedy mamy gwarancję, że tylko certyfikaty SSL wydane przez konkretny urząd certyfikacji będą mogły spełniać swoją funkcję dla naszego serwera (domeny).

Kliknij, aby powiększyć

Mimo niewątpliwych zalet HPKP z jego wykorzystywaniem wiążę się pewne ryzyko, które już wcześniej opisywałem:

Załóżmy, że zdefiniowaliśmy nagłówek Public-Key-Pins definiując tylko jeden skrót SHA-256 z klucza publicznego certyfikatu. Tylko z tego, który w danej chwili jest zainstalowany na naszej stronie. Przyjmijmy, że parametr max-age ustawiliśmy na 60 dni. Oznacza to, że przeglądarka użytkownika podczas jego pierwszej wizyty na naszej stronie zapamięta, że przez kolejne 60 dni ma odrzucać próby połączenia z naszą stroną w przypadku, gdy serwer przedstawi się innym niż zdefiniowanym przez nas kluczem publicznym.

Wszystko działa dobrze do momentu, gdy nie zajdzie potrzeba wymiany certyfikatu (np. z powodu kompromitacji klucza prywatnego). Co wtedy? W sytuacji, gdy zdefiniowaliśmy tylko jeden – wykorzystywany w momencie konfiguracji nagłówka PKP – skrót z klucza publicznego, który teraz musimy zastąpić innym, pojawia się problem. Przeglądarki zapamiętały dany Pin i przez 60 dni nie pozwolą użytkownikom na połączenie się z daną stroną jeżeli nie odnajdą właściwego klucza publicznego.

I właśnie na tę pułapkę HPKP nabrać dał się Barclays Bank, którego aktualny certyfikat SSL wygasał za 24 godziny.

Z ręką w nocniku…

Barclays Bank zaszył w swojej aplikacji skrót z klucza certyfikatu pośredniego urzędu certyfikacji należącego do Symanteca. Tym samym przypiął go do domeny payliquid.com. Oznaczało to, że tylko certyfikaty podpisane przez klucz prywatny komplementarny z kluczem publicznym, którego skrót został umieszczony w aplikacji, będą przez nią akceptowane.

W tym miejscu można się zatrzymać i zadać sobie pytanie: No dobra, ale w czym problem? Przecież wystarczy, że Barclays odnowi certyfikat w Symentecu. Przypięty w aplikacji klucz będzie wtedy pasował do certyfikatu wystawcy i po sprawie. I trzeba przyznać, że taki tok rozumowania jest w tym przypadku jak najbardziej prawidłowy, a jednak jego realizacja nie była tak prosta jak mogłoby się wydawać. O co więc chodzi?

A o to, że certyfikat pośredni, którego klucz publiczny Barclays zaszył w swojej aplikacji, przestał, ze względów bezpieczeństwa, być wykorzystywany przez Symanteca. Symantec od pewnego czasu po prostu nie wydawał spod niego żadnych nowych certyfikatów SSL. Spowodowane było to tym, że certyfikaty SSL wydawane (podpisywane) przez ten certyfikat pośredni miały sekwencyjne numery seryjne, a taka praktyka jest od niedawna zabroniona zapisami tworzonymi przez CA/Browser Forum:

Effective September 30, 2016, CAs SHALL generate non‐sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG

Certyfikat w promocji

Z jednej strony mamy więc jeden z największych banków w Wielkiej Brytanii z milionami niczego nieświadomych użytkowników, którzy w oczekiwaniu na Black Friday (cała opisywana sytuacja wydarzyła się 24 listopada, a certyfikat wygasał rankiem 25 listopada) tworzyli listę niezbędnych zakupów.  Z drugiej, Symantec ze swoim starym certyfikatem pośrednim (i kilkoma niedawnymi wpadkami na koncie) wydającym certyfikaty SSL, które nie spełniają podstawowych wymogów bezpieczeństwa.

Ostatecznie, biorąc pod uwagę skalę problemu, Symantec zdecydował się wydać certyfikat SSL dla domeny payliquid.com przy wykorzystaniu przestarzałego certyfikatu pośredniego. Ustawiając datę końca ważności tego certyfikatu na 24 stycznia 2017 roku dał Barclays dwa miesiące na rozpowszechnienie nowej, poprawionej, wersji aplikacji mobilnej wśród jej użytkowników.

Cała historia została opisana przez Symanteca na grupie dyskusyjnej CAB Forum.

PS. Pochwały dla Barclays za to, że ich aplikacja w ogóle z HPKP korzysta.