Takie tam przemyślenia

Dlaczego przesyłając poufne dokumenty pocztą analogową zabezpieczamy je przynajmniej kopertą? Dlaczego nie przesyłamy ich jak kartki pocztowe tak, aby każdy mógł zapoznać się z ich zawartością? Dlatego, że chronimy swoją prywatność lub nasze tajemnice? Dobra odpowiedź. Więc dlaczego przesyłając poufne informacje pocztą elektroniczną nie pakujemy ich w koperty lecz wysyłamy „pocztówki”? Dlaczego stosujemy szyfrowania poczty elektronicznej, co stanowiłoby (dużo lepszy) odpowiednik koperty?

Jedna z teorii głosi, że to jest kłopotliwe. Czyżby? Wysyłając list również musimy więcej się napracować niż w przypadku pocztówek – musimy zakleić kopertę. Podobny nakład pracy związany jest z zabezpieczeniem poczty elektronicznej, lecz dodatkowo przerzucony jest on na odbiorcę który musi podać hasło aby odszyfrować wiadomość.

Inna teoria mówi „A po co? Przecież nikt mnie nie będzie podsłuchiwał”. Zwykle nie. Ale kiedyś ktoś może zacząć. A kto? Ktokolwiek! Administrator sieci lokalnej lub osiedlowej, będący w zasięgu WiFi włamywacz amator… To może być każdy! Kiedy? Wtedy kiedy najmniej się tego spodziewamy.

Podobnie się ma sprawa z zamykaniem mieszkania na klucz. Dlaczego to robimy? Przecież jeśli nie zamkniemy drzwi na klucz i wyjdziemy do sklepu to po powrocie z pewnością zastaniemy wszystko na swoim miejscu!

Zamykamy drzwi na wszelki wypadek. Zamykamy po to, aby zabezpieczyć się przed tą „jedną taką szansą na sto”. W tym samym celu powinniśmy szyfrować pocztę. Z tego samego powodu strony logowania portali i serwisów internetowych powinny oferować szyfrowane połączenie. Często tego nie robią. Dlaczego? Bo pewnie właścicielowi serwisu szkoda pieniędzy na certyfikat SSL. Ale może skorzystać z alternatywnych rozwiązań, takich jak OpenID – dobry dostawca OpenID z pewnością ma szyfrowane połączenia i nasze hasło, które jest takie samo do poczty, kilku forów i naszej-klasy nie wpadnie w łapska sąsiada włamywacza.

Pewna organizacja przesyła dane osobowe swoich członków nieszyfrowaną pocztą elektroniczną: deklaracje członkowskie, hasła do ich konta pocztowego. Wszystko jest fajnie dopóki coś ktoś nie podsłucha (lub w inny sposób usyzka dostęp do) tych informacji. Wtedy mamy ślicznie nazywany „wyciek danych osobowych”. Ciekawe co na to GIODO?

Serwer pocztowy co prawda udostępnia szyfrowanie, ale certyfikat (samopodpisany) jest wystawiony na nazwę „localhost”, co skutecznie drażni programy pocztowe. Stanowisko administratora (zewnętrzna firma) jest takie, że „przecież szyfrowanie jest. Jak chcecie inny certyfikat to możecie zapłacić”. A wystarczyłoby zrobić certyfikat samopodpisany z rzeczywistą nazwą maszyny! Nie jest to szczyt zabezpieczeń ale lepsze to niż „localhost”.
Ten sam człowiek, mówi mi potem, że „Z kryptografią sytuacja jest bardzo prosta, którą można podsumować zdaniem ‘Bezpieczeństwo, Koszt, Wygoda – wybierz 2’”. Ja wybieram trzy! Bezpieczeństwo obowiązkowo! Samopodpisany certyfikat z nazwą maszyny kosztuje tyle samo co na „localhost”, więc koszt jest równy zero. A wygoda? Program pocztowy łączy się automatycznie używając szyfrowania jak i bez niego! Wystarczy, że nie kwestionuje niezgodności nazw.

A szyfrowanie samej poczty? Wybieramy więc: Bezpieczeństwo, bo o to w tym chodzi. Wybieram (niski) Koszt, czyli instaluję sobie oprogramowanie GnuPG i publikuję swój klucz w internecie tak, żeby każdy zainteresowany mógł go pobrać. Wybieram Wygodę – program pocztowy załatwi za mnie wszystko: pobierze klucz z serwera, zaszyfruje i odszyfruje.

Niewygodna konieczność podania hasła? Nikt nie mówi, że zamykanie drzwi na klucz jest niewygodne…

Artykuł

Pilne zadanie: sprawdzić czy aplikacja klienta będzie działała pod kontrolą maszyny wirtualnej jamvm

Niby proste. Zmieniam wywołanie w skrypcie na jamvm i uruchamiam:

gnu.xml.dom.ls.DomLSException: no root element: U+ffffffff
   at gnu.xml.dom.ls.DomLSParser.doParse(DomLSParser.java:320)
   at gnu.xml.dom.ls.DomLSParser.parse(DomLSParser.java:159)
   at gnu.xml.dom.ls.DomLSParser.parseURI(DomLSParser.java:175)
   at gnu.xml.dom.DomDocumentBuilder.parse(DomDocumentBuilder.java:165)
   at TestXMLParse.main(TestXMLParse.java:25)

Fajnie… Szukam i widzę że to wina starego Gnu Classpath. Biorę nowe i podmieniam.
To samo. Wrrrrrrrrr…..

No to może spróbuję innej JVM? Ok! Kaffe Ten sam błąd. No to podmiana biblioteki. Pomogło.

Dlaczego podmiana nie działa na jamvm???

Na szczęście aplikacja poszła bez proglemów z użyciem gij

Następnie napisałem prosty programik parsujący 60kb plik XML. Oto czasy wykonania:
sun java: 121ms

jamvm: wrrrrrrrrr

kaffe: 8370ms

gij: 6301ms

skompilowane gcj: 6303ms