Szyfrowanie poczty certyfikatem x5o9

*UPDATED…again*

pamiętam, że na uczelni – czyli ponad dekadę temu – każdy gówniarz, włączając mnie, wiedział co to PGP, miał certyfikat i się tym bawił. oczywiście ponieważ nasze dane były bardziej super fajne niż super tajne, po dwóch-trzech miesiącach każdy się nudził zabawą i certyfikaty poszły w zapomnienie… a było tak:

“

Projekt PGP został zapoczątkowany w 1991 przez Philipa Zimmermanna i rozwijany z pomocą społeczności programistów z całego świata^[1].

Wydarzenie to stało się pewnym przełomem – po raz pierwszy zwykły obywatel dostał do ręki narzędzie chroniące prywatność, wobec którego pozostawały bezradne nawet najlepiej wyposażone służby specjalne.

“

Wikipedia

Ponad 2o lat temu powstała idea, aby przeciętny obywatel mógł zabezpieczyć swoją pocztę.wtedy chodziło o zabezpieczenie się przed rządem – to było jeszcze echo po zimnej wojnie. po tylu latach bezpieczeństwo jest niemal wbudowane w każdy produkt i dostępne wszem i wobec, więc można przyjąć, że bułka z masłem coś takiego skonfigurować…

podstawowym problemem PGP jest zaufanie do certyfikatu, które opiera się na wymianie kluczy – nawzajem lub przez jakieś ‘zaufane miejsca’. mało wygodne przy użyciu ‘publicznym’ – lepiej skorzystać z zaufanych serwerów Root CA, które poświadczają tożsamość. w sumie na oddzielną dywagację, bo standardowy certyfikat można wystawić na “reksia kosmonautę” – i tak nikt nie wyryfiqje tożsamości przy najniższej klasie bezpieczeństwa… ale o nie o taki cel wpisu. chodzi o ideę szyfrowania wiadomości jako-takiego, oraz o weryfikację na ile to jest zadanie proste po 2o latach od rozgłosu, jaki osiągnęło PGP…

testy dotyczyć będą certów x5o9.

Ceryfikat

po pierwsze okazuje się, że zniknęły z rynq praktycznie wszystkie portale wydające darmowe certyfikaty do poczty z firm, które są globalnie w Trusted Root CAs. zostało comodo i masa ‘odsprzedawaczy’ którzy kierują na stronę comodo. jak dłużej się poszuka, znajdzie się “coś tam”:

• CAcert – ale jak można ufać komuś, kto nawet nie potrafi ustawić kodowania znaków na stronie? poza tym RootCA jest dystrybuowany społecznie, a więc trzeba go ręcznie importować
• startssl – początkowo go nie znalazłem, wymaga podania sporej ilości danych, rejestracja nie jest automatyczna.

no więc niech będzie comodo – w sumie co za różnica…. potem przetestowałem na certyfikacie startssl – i nawet się udało… ale to za chwilę.

Klient

po drugie żadna poczta publiczna webmail nie obsługuje certyfikatów – gmail, live/hotmail czy inne wynalazki. a więc pozostaje to poza zasięgiem większości userów. warto byłoby zerknąć na klienty na urządzenia mobilne, ale to zostawiam innym [będę wdzięczny za informacje – może korzystacie z jakiegoś klienta wspierającego szyfrowanie?]. więc przetestujmy na najpopularniejszych stacjonarnych klientach poczty.

dla testu stworzyłem dwa konta na jakieś tam skrzynki i wygenerowałem certyfikaty comodo i startssl. dwa konta w windows, oczywiście zaimportowane na krzyż po certyfikacie prywatnym jednego i publicznym drugiego. bułka z masłem…

[po trzecie] no może nie do końca – nie dla common-usera. ponieważ windows nie pozwala ani przesłać pliku .cer, ani kiedy się go zzipuje, rozpakować. trzeba wejść we właściwości i go odblokować – kolejne utrudnienie, które dla kogoś z IT może być śmieszne, ale dla przeciętnej osoby wymaga sporo wysiłku. pozostaje jeszcze jedna sprawa – skąd taki cer wziąć. i znów – dla mnie oczywiste jak wyeksportować część publiczną – ale nie jest to metoda ‘użytkownikowa’. raczej zaliczyłbym to do ‘zadań administracyjnych’.

idziemy dalej. odpalam Windows Live Mail 2o12 – bez trudu konfiguruje się własny certyfikat. drugi – publiczny, już zaimportowany i sprawdzony – siedzi w other users i wszystko się zgadza, cały łańcuch weryfikowalny, email ok. szyfruję wiadomość, wysyłam… i dupa “Digital ID is missing”. godzina ślęczenia, sprawdzania, bez szans. po prostu się nie da. wszędzie opisy jak wyłączyć szyfrowanie, nigdzie jak je skonfigurować – owszem, gdzieniegdzie opisy jak skonfigurować swój, ale nigdzie jak prawidłowo zaimportować czyjś. brak instrukcji. mam wrażenie, że robię coś źle – więc weryfiqję dalej.

testuje outlooka 2o1o. qrva – to samo! nie do wiary. nie mówiąc o tym, że sama konfiguracja czy szyfrowanie wymaga trochę umiejętności, ze względu na to przez ile okien trzeba się przeklikać w outlooku żeby to skonfigurować – przeciętny user się obsra a tego nie znajdzie. no ale to raczej korpo-aplikacja.
może głupi jestem – nie wykluczam, poza tym jest późno, a ja pracuje 17tą godzinę [ale update piszę następnego dnia i nadal nie jestem pewien – co robię źle?]… jeszcze jeden test:

‘by the book’, czyli tak, jak w zamyśle powinna wyglądać wymiana kluczy… najpierw z certami comodo.
wysyłam z jednego konta podpisaną wiadomość. dochodzi do nadawcy i .. jest prawidłowo zweryfikowana. dodaję kontakt do książki adresowej przez opcje tegoż zweryfikowanego kontaktu… – już trochę mniej oczywiste i trzeba się nieźle przeklikiwać ale w końcu działa! nic dodać nic ująć – super intuicyjny system, security w każdym domu! no to teraz to samo w drugą stronę – dla Live Mail… podpisuje wiadomość, wysyłam, przychodzi, zweryfikowana, przekilqje się przez info o certach i znajduję opcję “dodaj do książki”… i dupa. kontakt jest ale certu nie ma. następnego dnia zrobiłem ten sam test ale z certami startssl: ZADZIAŁAŁO! i to z Live Maile po obu stronach. nie będę już testował czy wczoraj coś namodziłem, czy certy comodo są do d. ale jest jedna rzecz, która mnie bardzo zastanawia: czemu zaimportowany cer nie jest rozpoznawany??

postanowiłem wyciągnąć ciężką artylerię. stawiam własny CA i tworzę template dla szyfrowania poczty. generuję cert z tym samym mailem, exportuję część publiczną instaluję… nie ma żadnych problemów z importem – zarówno outlook jak live mail łykają taki cert bez mrugnięcia ekranem. porównuję certy żeby zobaczyć różnicę:

• key usage: dla comodo digital signature i key encipherment; dla mojego – tylko key encipherment.
• enhanced key usage: w obu Secure Email. comodo ma jeszcze własny OID do logowania na swoich stronach. nieważne.
• CN – ten sam, czyli E=email
• Application policies: brak w certach z zewnętrznych CA. MCA dodaje ‘Secure Email’

o co c’mon? certutil weryfikuje bez zajęknięcia. jedyna różnica jaką znalazłem to to, że w wygenerowanym przez MCA jest Application Policy, którego nie ma w certach zewnętrznych – ale to nie powinno mieć znaczenia. tej części nie udało mi się rozwiązać.

na koniec biorę pod młotek thunderbirda…

nie lubię tego produktu – jest toporny, brzydki i nie korzysta z systemowego cert stora. o ile kojarzę to dodatkowo TB i FF mają oddzielne cert story! ale pal to licho – nie o to chodzi. próbuję dodać publiczny email cert – dupa. niezaufany. okazuje się, że brakuje ostatniego ogniwa zaufania – dla COMODO email. exportuję ze stora systemowego, dodaję do TB. działa.

Konkluzja

na jakim poziomie trzeba być userem, żeby zacząć korzystać z szyfrowania poczty? można x5o9 zastąpić openpgp czy GNUPG i szyfrowanie wiadomości z linii poleceń. tak, wiem, jest jakiś dodatek do systraya, który jakoś to automatyzuje – ale co z tego? target użycia pozostaje ten sam. zresztą opinię czy jest łatwiejsze czy trudniejsze pozostawię – może będę miał siłę to przetestować?

pomimo dwóch dekad – szyfrowanie poczty pozostaje instytucjom i zdesperowanym. zwykłym, ani nawet trochę mniej zwykłym userom, po prostu się to nie uda. być może drążyłbym jakąś teorię spisq – ale raczej projektu opensource typu mozilla nie podejrzewałbym o przyłączenie się do niego. żaden klient nie ułatwia wymiany kluczy, o ile w ogóle je obsługuje… a może nie ma się co dziwić? ostatnio częściej się słyszy o uzależnieniu od porali społecznościach – ludzi, którzy mają na bieżąco publikowane swoje położenie odczytane z GPS, każda myśl przelana od razu pro publico… ale czy bono to już wątpię. ‘jestem na wakacjach’, ‘właśnie wylało mi się mleko, cholera ale się pobrudziłem’, ‘ale walnąłem kloca! [+zdjęcie]’ … minęło 2o lat i ze skrajnej paranoi i strachu przez rządem, ludzie przenieśli się w epokę totalnej publikacji siebie.

tego nie rozumiałem wczoraj, będąc zmęczony, a dziś wydaje mi się oczywiste – nie ma popytu – nie ma podaży. kto potrzebuje – kupi, albo się nauczy.

eN.