Współczesne komunikatory internetowe chwalą się bezpieczeństwem i prywatnością ich użytkowników. A użytkownicy w to wierzą. Ale czasem firmy tworzące te komunikatory zawodzą w swoich obietnicach. Problem w tym, że użytkownik nie ma żadnej kontroli nad poufnością jego prywatnych wiadomości – zajmuje się tym dostawca danej usługi.
W większości przypadków ten schemat działa całkiem nieźle: użytkownik A wysyła prywatną wiadomość przez zaszyfrowane połączenie do serwera, a serwer przesyła ją dalej (również przez inne zaszyfrowane połączenie) do użytkownika B. Problem występuje wtedy, gdy firma pośrednicząca w wymianie takich wiadomości pozwoli na wyciek takiej wiadomości – przez błąd w oprogramowaniu lub nieuczciwego pracownika.
Zaszyfrowanie samej wiadomości przez użytkownika A wydaje się być właściwym rozwiązaniem problemu, ale to powoduje kolejne problemy. Aby użytkownik A był w stanie zaszyfrować wiadomość dla B, musi uzyskać jego klucz publiczny. Ale jak go uzyskać w sposób bezpieczny? Co, jeżeli B straci swój klucz, używany przez dłuższy czas do szyfrowania swoich rozmów? Poza tym, aby użytkownik B był pewny, że to A wysłał wiadomość, ten drugi musi ją podpisać. Ale co, jeżeli A powie B w zaufaniu coś kompromitującego, a ten upubliczni wiadomość i wykorzysta ją przeciw A? Wiadomość jest podpisana przez A, więc jest dowód, że to on ją napisał.
I tutaj się pojawia protokół rozmów Off-the-Record. Jego cel to umożliwienie prawdziwie prywatnych rozmów przesyłanych z użyciem dowolnej sieci (takiej jak Gadu-Gadu, xmpp, ICQ) w prosty do użycia sposób. Zapewnia cztery aspekty prywatności:
- szyfrowanie, dzięki czemu nikt poza A lub B nie jest w stanie odczytać ich wiadomości;
- uwierzytelnianie drugiego rozmówcy, aby mieć pewność że rozmawiamy z właściwą osobą;
- zaprzeczalność faktu wysłania danej wiadomości, ponieważ te nie posiadają cyfrowych podpisów – druga strona rozmowy nie może udowodnić, że wiadomości które otrzymała są wysłane przez Ciebie (ale sama może być tego pewna);
- doskonała poufność przekazu – jeżeli ktoś ukradnie Twój klucz prywatny, nie będzie w stanie odszyfrować żadnych wcześniejszych rozmów.
OTR i Pidgin/libpurple
Jest wtyczka do Pidgina, implementująca rozmowy OTR – pidgin-otr. Niestety, użytkownik musi ją zaintalować samodzielnie, więc nie jest to tak łatwe w użyciu jak w innych komunikatorach. Zostałem więc poproszony o włączenie tej wtyczki do oficjalnego wydania Pidgina.
Zdecydowałem jednak uczynić to zadanie odrobinę bardziej wymagającym. Pidgin-otr jest wtyczką tylko dla interfejsu graficznego Pidgina, więc nie jest dostępna dla innych klientów korzystających z libpurple. Niektóre z nich (Adium) implementują OTR samodzielnie, a niektóre (Finch) nie oferują takiej funkcji w ogóle. Zdecydowałem się przepisać tę wtyczkę jako korzystającą tylko z libpurple, aby umożliwić korzystanie z niej we wszystkich klientach używających libpurple. Na szczęście, pidgin-otr jest całkiem nieźle zaprojektowany, więc musiałem przepisać jedynie te części kodu, które są bezpośrednio związane z interfejsem użytkownika.
W przeszłości było już podobne podejście do tematu, w postaci projektu purple-otr. Jego głównym problemem był bardzo wybrakowany interfejs użytkownika – jego autor korzystał z bardzo ograniczonego Request API z libpurple2 do tworzenia okien dialogowych, więc nie był w stanie sklonować całej funkcjonalności pidgin-otr. Moja sytuacja jest dużo bardziej komfortowa, ponieważ jestem jednym z programistów Pidgina (czyli mam bezpośredni wpływ na jego kod), pracującym nad wersją 3.0.0 (która łamie API, więc nie muszę się martwić kompatybilnością). To znaczy, że byłem w stanie rozszerzyć funkcjonalność libpurple na tyle, żeby dobrze pasowała do potrzeb wtyczki OTR. Niektóre ze zmian w API libpurple, które sprawiły, że było to możliwe:
- API dla wtyczek umożliwiających szyfrowanie end-to-end pozwoliło na prezentowanie (niezależnie od protokołu szyfrującego) poziomu bezpieczeństwa rozmów. Wcześniej, pidgin-otr i podobne wtyczki umieszczały własne wskaźniki w różnych miejscach okna rozmów, teraz jest to ustandaryzowane.
- Request API usprawnione z użyciem struktury PurpleRequestCommonParameters, która sprawia, że to API jest łatwo rozszerzalne.
- Użycie PurpleRequestCommonParameters do implementacji nowych funkcji, takich jak możliwość podania treści komunikatów w formie HTML, możliwości zmiany ikonki okna dialogowego oraz zwiększenia kontroli nad przyciskami w oknach dialogowych.
- Dodania nowego rodzaju okna: „proszę czekać” z możliwością anulowania danej operacji, z opcjonalnym wskaźnikiem postępu.
Te zmiany mogą nie wyglądać na przełomowe. W rzeczywistości, bez nich port pidgin-otr dla libpurple mógłby wyglądać naprawdę skąpo, lub nawet dziwnie.
W tym momencie, cały kod dotyczący rozmów jest gotowy i da się go wygodnie używać. Jeszcze nie napisałem okien konfiguracyjnych (to jest moje kolejne zadanie) ani nie przystosowałem komunikatora Finch do nowego API, więc nie da się w nim jeszcze używać OTR (ale to nie będzie nic trudnego).
Niestety, nie ma możliwości przetestowania tych funkcji w tym momencie. Poprawki dotyczące libpurple są w publicznym repozytorium, ale te dotyczące wtyczki pidgin-otr są w niepublicznej gałęzi w repozytorium autorów OTR.