*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.

-o((:: sprEad the l0ve ::))o-

Comments (14)

  1. kojn

    Odpowiedz

    Mnie to się jakoś układa.
    Usłyszałem na jednej z konferencji MS dawno temu (odnośnie innego produktu) ale pasuje od lat …”nie rozwijamy tego, bo chcemy dać szansę naszym partnerom”…
    i tak
    Iron Port to nic innego jak PGP
    http://www.cisco.com/en/US/prod/vpndevc/ps10128/ps10154/pxe_encryption.html
    Obudowane ładnie przez Cisco
    http://www.cisco.com/en/US/products/ps10606/index.html
    cennika nie znam, ale na penwo drogie …
    I tak .. IT jest zarobione … manager idzie na zakrapianą konferencję, wraca i wie że jak wdroży security coś tam, to nie dość że się wykaże, to sie jeszcze wdrożeniem pochwali to i może i nagrodę dostanie jakąś, albo puchar innowatora security … piewcy bezpieczeństwa czy co tam dają. A za rok na konferencję to już na pewno zaproszą …
    Do tego odpowiedzialność można zrzucić na integratora lub vendora i pozamiatane. Co z tego że chłopaki mogą zrobić to za friko … trzeba by ich sprawdzać, poganiać itp … a tu tylko jedna FV i pozamiatane ;P

    cholera … jak to się czyta … ide się napić …

  2. nn

    Odpowiedz

    Witam, czy przypadkiem nie dochodzi do pomieszania przez autora PGP z PKI? bo PGP/OpenPGP to jak dla mnie właśnie brak jakotakiego łańcuszka certyfikatów a właśnie coś w stylu web of trust z keyserverami. Tak mi się przynajmniej wydaje jak kiedyś robiłem rozeznanie :P Klucz GPG/PGP możemy sobie sami zrobić i nikt nam nie zarzuci niepoprawnego łańcuszka do verisignu :P

  3. Odpowiedz

    @darek&kaluza: starssl’owy też nie działa. znaczy po wysłaniu części publicznej nie da się go dodać jako cert osoby /:

    @nn: zupełnie nie mylę. PKI to bardzo szerokie pojęcie dotyczące całej infrastruktury klucza publicznego czyli polityka backupu i przechowywnia, polityka wydawania certów, konfiguracja cert chaina, zasady zaufania, szablony certyfikatów i tak dalej i tak dalej… PKI ma się tak do PGP jak Active Directory ma się do domowego komputera z dwoma kontami użytkownika.

    @kojn:tutaj myślę, że inne czynniki wygrały. podaż – popyt. zabrakło popytu oraz kogoś, kto by się o to zatroszczył. to co piszesz to korpo wdrożenia, a mi chodzi o PGP – czyli 'dla ludzi’. soc-idea.

  4. kojn

    Odpowiedz

    @nexor – czyli dla ludzi … jak to jest z szyfrowanie od strony legalnej / nielegalnej, bo przecież jak kupujesz jakiś sprzęt z „dużą” enkrypcją np. jakiś checkPoing VPN coś tam … to musisz go zgłosić w ABW. Czy jak generujesz sobie klucz i kodujesz to musisz to gdzieś zgłaszac?

  5. kojn

    Odpowiedz

    I jeszcze jedno bo doczytałem update towojej nierównej walki i rozważań ;) – uzewnętrznienie siebie jest tak duże, że w trakcie ataku na chałupine Bin Ladena Biały Dom miał NA ŻYWO!!! informacje o nastrojach dotyczących tego faktu na Fejsie i twiterze. Mógł podjąć decyzję o zabić / ocalić na podstawie negatywnych i pozytywnych komentrzy dotyczących relacji. Wieć jak w języku arabskim było na nie a w angielskim na tak … nie jestem w stanie znaleźć zródla tego co napisałem … więc poprostu, gdzieś czytałem. Jak znajdę to wrzucę

  6. mwd

    Odpowiedz

    nxr: oj, chyba jednak mylisz pgp i pki… pgp nie potrzebuje certchainów i pozwala właśnie na proste stworzenie pary kluczy, wymianę publików i wygodną pracę. Bez certyfikatów! Więc plz, nie mów PGP w jednym akapicie, potem opisując jak pochrzanione PKI potrafi być, by podsumować jak głupie jest PGP…

    Trochę ludzi tego nadal używa. Jest trochę softu do spinania tego z klientami poczty (gpg4o, gpg4win, enigmail), jest trochę softu do ładnego okienkowego obsługiwania tego (gpg4win, gpgshell).

  7. nn

    Odpowiedz

    Być może nie do końca poprawnie użyłem określenia PKI ale miałem na myśli x.509 itp itd, ktore ewidentnie i jednoznacznie są alternatywą dla PGP/GPG i całej kryptografii dla ludzi, bez urzędów certyfikacji, łańcuszków i całej tej zabawy. w GPG generujesz sobie wszystko sam i ewentualnie publiczny klucz udostępniasz publicznie na ogólnodostępnych serwerach np. http://pgp.mit.edu/ aby każdy mógł do Ciebie coś wysłać bez wcześniejszego konsultowania klucza :) Prosta idea, która faktycznie działa, tylko wymaga oprogramowania do obsługi kluczy.

  8. nn

    Odpowiedz

    Dodam jeszcze, że z Wikipedii którą cytujesz jakbyś doczytał to „Weryfikacja kluczy opiera się o sieć zaufania (web of trust).” a z artykułu o WOT: Sieć zaufania (ang. web of trust) to zdecentralizowana metoda uwierzytelniania osób, w której nie ma hierarchicznej struktury organizacji uwierzytelniających, a zaufanie do poszczególnych certyfikatów jest sumą podpisów złożonych przez innych uczestników sieci.
    jest to przeciwieństwo scentralizowanego certyfikatu, gdzie wystarczy podpis jednej organizacji, która ma łańcuszek abyś był poprawny dla wszystkich :P

  9. Odpowiedz

    @mwd&nn: damn, you right! byłem przekonany, że PGP korzysta z x5o9 w wersji self-signed+społecznościowy serwer publikacji certów… taki odłam od urzędów certyfikacji…
    no nic. trzeba będzie znów przerobić – dzięki za sprostowanie!

  10. Odpowiedz

    panowie recenzenci – teraz jest ok? (:
    swoją drogą jak korzystacie z GPG czy innego wynalzq to może oszczędzicie mi pracy i napiszecie czy to 'dla usera’?

  11. mwd

    Odpowiedz

    Jest ok. :)

    Z GPG czasem korzystam. Rzadko, ale raz na jakiś czas się trafi. Pod windą używam GPGShell’a. W trayu sobie siedzi i potrafi obsłużyć każde okno — podpinasz skrót klawiszowy albo klikasz myszą, jak wolisz. Użycie jest banalne — owszem, czasem konsolowe okienko się pojawia, jak trzeba wpisać hasło w jakimś specyficznym przypadku. A poza tym to prowadzi za rączkę.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Time limit is exhausted. Please reload CAPTCHA.