Konsekwencje prawa nieuniknionych konsekwencji

Ponieważ rysiek nie daje możliwości komentowania u siebie (a szkoda), będzie krótki wpis. Ryśkowe prawo nieuniknionych konsekwencji mówi o tym, że:

Jeśli coś jest technicznie możliwe,
jest praktycznie nieuniknione.

Zupełnie się z tym zgadzam. Osobiście wyznaję dość podobną zasadę, którą można streścić

Każde zdarzenie o niezerowym prawdopodobieństwie zaistnienia prędzej czy później nastąpi.

Trochę fatalistyczne, fakt (szczególnie w kontekście kolizji ciał w przestrzeni kosmicznej o niepomijalnej masie), ale sprowadzając do komputerów i bezpieczeństwa: każda baza zostanie wykradziona, każde dane prywatne ujawnione, każde hasło zostanie złamane. Prędzej lub później.

W kontekście Diaspory, która jest przytoczona przez ryśka jako remedium na problemy dotyczące ochrony prywatności m.in. na Facebooku

Zwyczajnie nie da się wprowadzić reklam lub sprzedać danych prywatnych wszystkich użytkowników tej sieci jednocześnie. jest to technicznie niemożliwe.

oznacza to, że da się zdobyć dane wszystkich użytkowników tej sieci. Jak? Wystarczy błąd w aplikacji. Jak trafnie zauważa Wiktor:

One wszystkie ze sobą gadają i mają ten sam, możliwy do sprawdzenia kod.

Wystarczy klasyczny 0 day, i jeśli tylko komuś będzie zależało na tych prywatnych danych, to zdobędzie je. Oczywiście nie wszystkie, bo albo jakiś serwer będzie offline, albo będzie nietypowo skonfigurowany, albo zwyczajnie admin zdąży go załatać. Albo nie zdąży zaktualizować do podatnej wersji.

Fakt, że oprogramowanie jest open source nie eliminuje prawdopodobieństwa wystąpienia błędu. Wystarczy wspomnieć błąd z OpenSSL w Debianie. Zresztą, chyba wszyscy pamiętamy o tegorocznym Heartbleed

Należałoby więc raczej mówić jedynie o zmniejszaniu prawdopodobieństwa zaistnienia zdarzenia, nie jego eliminacji. W tej chwili raczej nikt się na dane użytkowników Diaspory nie połasi, ale nie dlatego, że nie może, tylko dlatego, że się po prostu nie opłaca. Użytkowników Diaspory jest zwyczajnie za mało.

Wybory – sytuacja, pomysły

Początkowo z wyborami było trochę śmiesznie (no dobrze, śmiech przez łzy), zrobiło się trochę strasznie (okupacja PKW, nie ma zgody na kwestionowanie wyników przez miłościwie nam panującego, wygrana PSL). Pojawiły się też głosy o konieczności stworzenia otwartego, wolnoźródłowego systemu i inicjatywy w tym temacie. Cieszy, bo oznacza, że to nie moje paranoje i pomysł ma sens.

Trochę na FB pisałem, ale to znika, więc dla pamięci (i szerszego grona). Do głowy przyszedł mi wariant minimum. Zaznaczam, że bazuje na starych procedurach ręcznych (ale cóż więcej trzeba?) i starych, sprawdzonych technologiach, choć korzystając z nowych warunków.

Wystarczyłoby, żeby komisje wysyłały proste tekstowe dokumenty o ustalonym formacie (formatkę, czyli odpowiednik protokołu powinny dostać wcześniej) przy pomocy emaila (stara sprawdzona technologia, dobrze się skalująca). W ramach ustalenia autentyczności i tajności[1] podpisanego/zaszyfrowanego GPG. Oczywiście członkowie komisji (a przynajmniej 2-3 z każdej komisji) musieli by mieć potwierdzone klucze, ale z tym nie ma problemu – i tak są na szkoleniu dla członków komisji. Maila każdy w dzisiejszych czasach ma (wystarczą 2-3 osoby z komisji, powtórzę) i wysłać umie. Czyli tak, wysyłali by wyniki podpisane GPG z dowolnych, nawet prywatnych, darmowych kont. Potwierdzenie dostarczenia jest opcjonalne (delivery notification), ale dostępne w programach pocztowych, czyli komisja wie, czy/kiedy protokół dotarł do serwera poczty PKW. Z nowoczesnych dodatków i zwiększania wiarygodności – można załączyć „skany” papierowego protokołu. Wystarczy smartfon z aparatem (znaczy: smartfon)…

Po stronie serwera email PKW nic specjalnego się nie dzieje. Jeśli chodzi o dalszą część serwerową, to program do liczenia łączy się do serwera poczty, odbiera maila, na podstawie tematu przypisuje do komisji (albo z treści formularza…). Następnie weryfikuje autentyczność podpisu GPG i w przypadku zgodności parsuje plik tekstowy.

Gdyby pliki były wysyłane w dokładnie określonym formacie, to całość jest do naklepania w Perlu w parę godzin. No ale pewnie nie będą, bo maile umożliwiają dość dużą dowolność formatu wysyłki pliku i co program, to wynalazki… (szczególne ukłony w stronę Microsoft). Można się bawić oczywiście w napisanie prostego klienta poczty dla komisji. Zaleta rozwiązania jest taka, że po wyborach PKW może udostępnić publicznie wyniki. Albo wręcz przeforwardować wyniki z danej komisji wszystkim zainteresowanym, którzy np. wcześniej zgłoszą takie zapotrzebowanie.

W kontekście wysokiego wyniku PSL i ponownie sporej ilości głosów nieważnych dla przypomnienia kawałek historii:

wybory 2010 głosy nieważne

Źródło: http://uczciwe-wybory.pl/analiza-glosow-niewaznych-wyborach-parlamentarnych-2005-2007-2011-samorzadowych-2010/

W odpowiedzi na to kolejny pomysł – kamery w komisjach i albo streaming online, albo przynajmniej rejestracja i udostępnienie obywatelom bezpośrednio po wyborach[2]. Jeśli jest podejrzenie fałszowania głosów przez członków komisji (a właśnie o dostawianiu krzyżyków mowa), to powinno to rozwiązać problem. Plus obowiązek przebywania głosów „na oczach kamer” od momentu wyjęcia ich z urny do czasu sporządzenia protokołu przez komisję.

W ten sposób obywatele mieliby możliwość prostego zweryfikowania wyborów ze swojej komisji i nadzorowania pracy (przypomnę, po zamknięciu lokali poza członkami komisji i mężami zaufania obywatele nie mają dostępu do lokali).

[1] Tajność wygląda na zbędną. Wysyłki są dokonywane już po zamknięciu lokali, więc nie ma potrzeby utajniać wyniku.

[2] Zdaję sobie sprawę, że danych jest sporo i nakłady na infrastrukturę (kamery plus streaming) nie są małe. Być może wystarczyłaby możliwość montowania kamer (z publicznym streamingiem) przez obywateli.

Własna strona w sieci Tor

Za sprawą normalnych tradycyjnych stron w sieci Tor zrobiło się ostatnio głośno z powodu Facebooka. Nie dość, że Facebook wystawił stronę oficjalnie do sieci Tor pod adresem .onion, to adres był ciekawy, a całość jest dostępna po HTTPS, czyli w wersji szyfrowanej[1]. Mniejsza o powody, dla których to uczynili. Wydaje się, że nie tyle chodziło im o anonimowość użytkowników (nie miejcie złudzeń), co o ich prywatność i bezpieczeństwo (ukrycie lokalizacji). Plus przy okazji rozwiązali sobie problem false positives przy wykrywaniu włamań, które mieli przy użytkownikach korzystających z tradycyjnych exit node[2]. Będzie zatem o własnej stronie w sieci Tor.

Tor logoŹródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

Tak czy inaczej, wygląda, że Tor został dostrzeżony przez dużych w z właściwej perspektywy, czyli po prostu jako medium transmisji, a nie odrębna sieć, używana przez złoczyńców[3]. Myślę, że można spodziewać się kolejnych naśladowców.

Warto zauważyć, że to co zrobił Facebook to nie jest typowy hidden service w sieci Tor. W typowym chodzi o ukrycie tożsamości właściciela, miejsca hostowania itp. Czyli masa pracy poświęcona uszczelnianiu systemu i serwera WWW, która nie jest przedmiotem tego wpisu. Na stronie projektu Tor też się tym nie zajmują, ale zainteresowani znajdą tam ogólne wskazówki. Tu przeciwnie – wszystko jest dostępne, a tożsamość jest potwierdzona certyfikatem SSL, czyli wersja znacznie łatwiejsza w wykonaniu.

I właśnie takim przypadkiem zajmę się w tym wpisie. Całość opisana jest dokładnie na stronie projektu Tor. Widzę jednak, że pojawiają się pytania jak to zrobić, więc zamieszczę wersję skróconą i uproszczoną. Tak naprawdę całość sprowadza się do dwóch linii w pliku konfiguracyjnym. Zakładam, że Tor jest już skonfigurowany jako relay node lub bridge node. I nawet nie do napisania, tylko do odhashowania/edycji.

Przede wszystkim w pliku konfiguracyjnym[4] szukamy sekcji dotyczącej hidden services, zaczynającej się od linii:

############### This section is just for location-hidden services ###

Następnie odhashowujemy/edytujemy dwie linie:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 IP_SERWERA_WWW:80

Pierwsza musi wskazywać na katalog, który musi mieć prawa odczytu i zapisu dla użytkownika na którym działa demon Tor. W Debianie wystarczy odhashować.

Druga to wskazanie który port chcemy przekierowywać i na jaki adres oraz port. IPv4 działa na pewno, IPv6 nie udało mi się skłonić do działania. Jedyna zmiana, czy też wymóg konfiguracji po stronie serwera WWW, jest taki, że musi on pozwalać na dostęp do zasobów po IP, bez podania domeny (vhosta)[5].

Następnie należy zrestartować demona Tor i… gotowe. Pozostało jeszcze tylko sprawdzić, jaki adres ma nasz hidden service:

cat /var/lib/tor/hidden_service/hostname

Potem można już tylko zweryfikować działania serwisu za pośrednictwem adresu .onion. Jeśli nie mamy pod ręką normalnego dostępu do Tora, można posiłkować się bramką Tor2web.

[1] I całe szczęście, bo przypominam, że Tor nie szyfruje użycie Tora nie oznacza automatycznie szyfrowania danych. Co więcej, każdy węzeł, ma możliwość przechwycenia całej (co prawda zaszyfrowanej) transmisji. A exit node, jest w stanie podsłuchać nieszyfrowaną transmisję do końcowego hosta.

[2] Więcej w tym wpisie (ANG).

[3] Nie ukrywajmy, typowy użytkownik Tora kojarzył się do tej pory z nielegalnymi działaniami.

[4] W Debianie jest to /etc/tor/torrc, pewnie w Ubuntu i innych pochodnych jest analogicznie.

[5] Tu uwaga dla chcących stawiać bramki hidden service – z punktu widzenia zewnętrznego serwisu (i tylko jego, i tylko w przypadku połączeń poprzez adres .onion) mój klient Tor IP jest teraz exit node! W przypadku nadużyć za pośrednictwem sieci Tor i adresu .onion może się to skończyć wizytą policji. W przypadku serwisów, których nie jesteśmy właścicielami bezwzględnie należy mieć zgodę właściciela serwisu.