Testy na produkcji, czyli jak przez 3 lata byłam swoim CA

Tydzień temu zakończył się mój w zasadzie nieplanowany eksperyment w naturze, który trwał trzy lata. Zakończył się tak samo nieoczekiwanie jak się rozpoczął. Przez trzy lata byłam dla siebie CA - dla tego serwera, który używa wyłącznie adresu IP. W czasie, kiedy zaczynałam zabawę z hostowaniem czegokolwiek w internecie (marzec/kwiecień 2019) nie miałam za bardzo innych możliwości działania w takim przypadku. Przez pierwsze miesiące po prostu używałam certyfikatów self-signed – i kiedy zaczęłam mieć na serwerze jakiekolwiek usługi na prywatny użytek, trochę rzeczy nie działało.

Latem 2019 miałam lokalnie swoje CA na własny wewnętrzny użytek i do testów. Zainspirowana rzeczami, z którymi w tamtym czasie miałam do czynienia w pracy, próbowałam aktywować funkcję kart inteligentnych w Yubikey. Robiłam też inne, równie nieszkodliwe eksperymenty w celach samokształcenia i zaspokajania ciekawości, nie mające większego znaczenia.
Problem pojawił się w październiku 2019, kiedy przeczytałam, że przeglądarka Google Chrome w niedalekiej przyszłości zacznie blokować mieszaną zawartość (mixed content) na stronach. W tamtym czasie linkowałam niektóre swoje treści, głównie grafikę, w co najmniej jednym miejscu, używając do tego dodatkowego, nie szyfrowanego kanału. Niepokoiło mnie, że mogę zostać wycięta z forum, próbowałam zatem znaleźć sposób jak przetrwać do czasu, kiedy będę mogła zapewnić sobie szyfrowanie oficjalną drogą.

W 2019 zespół Let’s Encrypt w wątkach w swoich repozytoriach na GitHubie dawał do zrozumienia, że taką funkcję zamierzają wprowadzić w przyszłości. Produkcyjnie nadal tego nie implementowali.

Jednym z pomysłów, jaki wtedy wpadł mi do głowy, było udostępnienie głównego klucza publicznego mojego CA, żeby inne osoby mogły go pobrać i importować. Jednocześnie miałam go zacząć używać produkcyjnie do generowania certyfikatów dla stron na swoim serwerze. Przy mojej ówczesnej wiedzy na temat TLS nie byłam pewna, czy to pomoże i przyznaję, że byłam w lekkim szoku, kiedy w testach na ochotnikach okazało się, że to rzeczywiście rozwiązywało – czy może raczej obchodziło problem. Zadowolona, że znalazłam względnie stabilne obejście, zaczęłam rozpowszechniać mój główny klucz publiczny wśród rodziny i niektórych znajomych, osób, które miały regularny kontakt z treściami albo usługami na moim serwerze. Wszystko dzięki temu “działało” bez większych problemów i utrudnień.

Dotarło do mnie, że to przestały być tylko niewinne radosne testy. Stałam się odpowiedzialna za osoby, które importowały mój klucz publiczny. Wraz ze wzrostem wiedzy i świadomości, coraz bardziej uważałam i zastanawiałam się, co robię. Nie chciałam doprowadzić do sytuacji, w której zaszkodziłabym grupie osób poprzez potencjalny backdoor. Niebezpieczne możliwości, jakie potencjalnie dawała taka sytuacja, połowę tego czasu znałam tylko w teorii. Później faktycznie w ramach zupełnie niezależnych eksperymentów nauczyłam się przeprowadzać ataki MITM (man-in-the-middle) ale nigdy NIE WYKORZYSTYWAŁAM hipotetycznych szans, jakie czasem się pojawiały. Nigdy nikogo nie podsłuchiwałam ani podstępnie nie weszłam w posiadanie danych innych osób. Nieraz zdarzało mi się słyszeć takie zarzuty, zupełnie niesłusznie i niesprawiedliwie. W rzeczywistości im lepiej wiedziałam co robię i jakie mogą być potencjalne konsekwencje, tym bardziej byłam zdeterminowana nie dopuścić, żeby cokolwiek się stało. Mogę z czystym sumieniem powiedzieć, że nie wyrządziłam żadnych szkód ani przez celowe działania, ani przez utratę kontroli.

Rozwiązanie – już nie obejście – problemu pojawiło się w sytuacji, kiedy nawet się tego nie spodziewałam. Dostałam nagle namiary na informację, że ZeroSSL obsługuje takie przypadki i postanowiłam spróbować. Udało się od razu.

Podejrzewam, że gdyby mój eksperyment musiał trwać dłużej, brutalny kres wyznaczyłoby mu rozpowszechnienie się Androida 11, gdzie proces importowania certyfikatów jest bardziej skomplikowany. To, co do tej pory rozpowszechniłam, samo w końcu zaniknie z “otoczenia” wraz z wymianą sprzętów i systemów, ich aktualizacjami i reinstalacjami. Sprawa rozwiąże się samoistnie bez żadnego dodatkowego niebezpieczeństwa, niezależnie jak długo będzie to trwało.

TAK, moje klucze prywatne były (i są, moja infrastruktura istnieje dalej, nawet jeśli znowu będzie do wewnętrznego użytku) chronione sprzętowo i nie groził mi ich wyciek. Swoją drogą, mimo iż Nitrokey HSM ma opublikowane w sieci całkiem dobre instrukcje, nie są one pełne i ostatecznie musiałam dojść metodą prób i błędów do tego, jak zmodyfikować swoje pliki konfiguracyjne openssl, żeby to wszystko chciało ze sobą współpracować.
NIE, okazuje się, że nie wszystkie aplikacje magicznie zaczynają współpracować z różnymi usługami na takim niezweryfikowanym serwerze po importowaniu kluczy publicznych CA do systemu. Wielu rzeczy do samego końca nie byłam w stanie skłonić do współpracy.
NIE, to nie kwestie techniczne były w tym wszystkim najbardziej “skomplikowane”. To dawało się bez problemu opanować, kiedy już poznało się odpowiednie komendy w terminalu i miało się kilka plików konfiguracyjnych. Znacznie więcej zastanowienia wymagało ustalenie co powinnam – czy może czego NIE powinnam robić. Złośliwi mogliby powiedzieć, że najlepiej było, kiedy po prostu trzymałam się z daleka od swoich kluczy prywatnych. Drugim czynnikiem utrudniającym były właśnie złośliwe komentarze i niesłuszne oskarżenia o podsłuchiwanie i szpiegostwo.
NIE, nie żałuję, że zostałam postawiona w takiej sytuacji, wręcz cieszę się i jestem wdzięczna, że dane mi było tego doświadczyć. Dzięki temu musiałam zdobyć wiedzę, która już ze mną zostanie i którą może w przyszłości wykorzystam do czegoś jeszcze. Tkwiąc w tym od środka mogłam też głębiej zrozumieć kryptografię od strony bardziej “filozoficznej”… cóż, w czasach kiedy robi się z niej sprawę polityczną, to też może mieć znaczenie…