warcraft 3 TFT + ROC, warcraft III,

Replaysowa strzałka Polskie Centrum Replayów - top
Replay Tygodnia / Best Replay
Nie ma żadnych replayów spełniających te wymogi.

SSL, certyfikaty i POLAND[PL]

Podstawy zabezpieczania danych w Internecie, czyli co POLAND[PL] powinien wiedzieć na temat cyfrowych certyfikatów oraz szyfrowania
 
Niedawno na forum pojawił się kolejny wątek zainicjowany przez jednego ze stałych bywalców, można powiedzieć replaysowego lwa salonowego, POLANDA[PL]. Jeśli do tej pory ta postać jest wam nieznana, to powiem tylko tyle, że pochodzi z Polski. W zwyczajowych powitaniach i wymianie uprzejmości zaginął główny wątek całej sprawy. Co dokładnie oznaczał przytoczony komunikat, skąd się wziął, jakie jest jego znaczenie i czy można go bezpiecznie zignorować? Oczywiście sam autor wątku stwierdził, że już sobie z tym poradził, ale czy na pewno? Zależy, czy uznajemy zamiatanie śmieci pod dywan za rozwiązanie.
 
Przeglądając listę tematów na forum, łatwo można dostrzec, że dużą popularnością cieszą się różnorakie teorie spiskowe. Niestety, jak widać skłonności paranoidalne rzadko idą w parze z naturalną ciekawością, która jest potrzebna do rozwiązania tej zagadki – nikt nie pokusił się nawet o hipotezę, skąd się to zjawisko wzięło. Być może zbyt wiele osób było ujętych czarem POLANDA[PL], ale osobiście myślę, że tak naprawdę większość nie wiedziała o co chodzi. Można tak wnioskować na podstawie odpowiedzi ZaBa, który zaproponował zignorowanie komunikatu i dodanie serwera do listy wyjątków. Co dokładnie jest ignorowane w tym przypadku? Czy rzeczywiście jest to dobry pomysł, skoro używana strona to jeden z popularniejszych sklepów ebay.de?
 
Zacznijmy od określenia, czym są certyfikaty i na czym polega szyfrowanie transmisji po Internecie. Podstawą jest tutaj, jak się można spodziewać, dość zaawansowana matematyka. Każdy uczestnik transmisji (serwer i klient) posiada swój zestaw kluczy – prywatny i publiczny. Ze względu na użytą funkcję matematyczną, klucze są ściśle powiązane (prywatny deszyfruje wiadomości kodowane publicznym), ale jednocześnie nie jest znany sposób generacji klucza prywatnego na podstawie klucza publicznego. Dzięki tej ciekawej właściwości można bezpiecznie wysłać klucz publiczny do drugiej osoby, i odszyfrować odesłaną wiadomość u siebie, przy pomocy klucza prywatnego. Efektem ubocznym jest niemożność odszyfrowania wiadomości, nawet przez jej oryginalnego autora (ponieważ posiada on tylko cudzy klucz publiczny – może zaszyfrować, ale nie odszyfrować).
 
Oczywiście z tego powodu potrzeba dwóch różnych par kluczy prywatnych i publicznych, żeby szyfrować bezpiecznie transmisję w obie strony przy pomocy tzw. asymetrycznej kryptografii.
 
W tym momencie szanujący się paranoik powinien jasno stwierdzić – to nie ma prawa działać, bo system jest zbyt skomplikowany. Jeśli POLAND[PL] nie jest w stanie go zrozumieć, to nie ma szans, żeby go zabezpieczał. Niestety, to jest prawda.
 
Co więcej, na pewno istnieje rozwiązanie tego problemu matematycznego i możliwość generowania kluczy prywatnych z publicznych przez agencje rządowe. Prawdopodobnie rozwiązanie posiadali już hitlerowcy, ale nie ujawnili go, bo mieli plan wystawienia figurantów do egzekucji i teraz potajemnie kradną nasze pieniądze. Nikt, kto prowadziłby tak doskonale zorganizowaną maszynę wojenną jak naziści, nie może być idiotą, a nawet są większe szanse wystąpienia nazistowskiego geniusza, niż wśród przeciętnej populacji. Ubermensch, nawet po dostaniu w dupsko, kompletnej porażce i zawieszeniu na sznurku, zawsze zostaje Ubermenschem.
 
Nie wiem jak wy, ale ja posiadam tajny sejf z podstawowymi wiadomościami typu lek na raka, AIDS, algorytm generowania kluczy prywatnych i szczegóły budowy napędu ponadświetlnego, tak jak każdy ważniejszy człowiek na świecie.  Nie ujawniam tych danych, bo nie interesuje mnie nagroda Nobla, zapisanie się na kartach historii, jako zabójca internetowego handlu i podobne przyziemne sprawy. Kogo to może w ogóle obchodzić?
 
W końcu może gdzieś jest sawant, stworzony przez naturę tylko w celu hackowania konta POLAND[PL] na ebay.de, albo coś wie pracowity Chińczyk ukrywany wśród hodowców lam w zapadłej wiosce w Tybecie. W najgorszym wypadku technologię mają Obcy. Prawdziwy zły człowiek przede wszystkim spiskuje, niczego nie ujawnia. Jest skromny i konsekwentnie czeka, aż cały świat będzie uzależniony od tej technologii, żeby wtedy uderzyć... Poza tym drobnym faktem, że już od dłuższego czasu ten moment minął.
 
Wracając do przyziemnych spraw – opracowanych zostało wiele ataków na systemy kryptograficzne, zupełnie realne i codzienne zagrożenie. Wbrew pozorom, niektóre z nich nie wymagają bycia światowej klasy naukowcem. W takim razie, czy jest to bezużyteczna technologia? Nie. Tak samo jak nikt normalny nie wykręca bezpieczników w instalacji elektrycznej, „bo i tak może prąd porazić”, nie powinno się lekkomyślnie rezygnować ze zrozumienia i używania certyfikatów. O ile różne metody profesjonalnej kryptoanalizy nie są dla zwykłego użytkownika ważne (wystarczy zaktualizowane oprogramowanie, o to dbają naukowcy), to zawsze pozostaje kilka furtek, głównie opierających się na założeniu, że użytkownik technologii jej nie rozumie.
 
Jest to niestety założenie słuszne, jak się codziennie okazuje. Od pospolitego phishingu (podstawiania fałszywych stron imitujących legalne sklepy, banki itp.), przez keyloggery zapisujące hasła wpisywane na klawiaturze, aż po ataki oparte na zrozumieniu samej zasady działania systemu kluczy i certyfikatów. Skupię się na ostatnim problemie, bo inne są prawdopodobnie wszystkim dobrze znane. Jest możliwe, jeśli ktoś z was przeczytał i zrozumiał skrótowy opis komunikacji (lub nawet zajrzał na wikipedię i obejrzał rysunki), że gołym okiem zobaczy główną słabość tego systemu – nie ma prostej metody dystrybucji kluczy. Z której strony by do tego nie podchodzić, zawsze musi najpierw istnieć zaufany dystrybutor kluczy publicznych. Na pierwszy rzut oka wydaje się, że jest to zbędne, bo przecież można tym kluczem wyłącznie szyfrować – nic bardziej mylnego, bo nie wiemy kto szyfruje.
 
Ponieważ cała komunikacja po Internecie zachodzi poprzez niezaufane łącza, czyli jest realna możliwość podsłuchania a nawet przechwycenia danych (poprzez hackowanie sieci bezprzewodowych, podszywanie się w zwykłych sieciach lokalnych, hackowanie dns, a nawet zwykłą, ludzką złośliwość i chęć zysku admina jednego z pośredniczących w komunikacji serwerów). Taki atak jest nazywany „man in the middle” (po polsku – pośrednik, człowiek w środku). System kluczy asymetrycznych nie jest bezpieczny bez zaufanego dystrybutora kluczy przed tym atakiem. Prosta sprawa – pośrednik pomiędzy komputerami A i B wysyła im swoje klucze publiczne (podczas wymiany kluczy na samym początku), przez co w całej komunikacji biorą udział tak naprawdę trzy pary kluczy – A, B oraz pośrednika. Ze względu na asymetrię, jest on w stanie odszyfrować wiadomość u siebie (bo oszukał obie strony komunikacji podając im swoje klucze szyfrujące – publiczne, do których posiada prywatne), a jednocześnie, ponieważ zna prawdziwe klucze publiczne, może ponownie wiadomość zaszyfrować, ukrywając tym samym fakt swojego istnienia. Docelowe strony komunikacji używają kluczy pośrednika do szyfrowania i nie są świadome kradzieży (a może nawet podmiany) danych. Śmiesznie proste, wykonalne i wykonywane.
 
Żeby temu zaradzić, istnieją wydawcy certyfikatów (Certification Authority - CA), którzy weryfikują dodatkowo czy obie strony komunikacji używają tego samego zestawu kluczy. Oczywiście można się zastanowić, czy to ma sens – skoro jest możliwy powyższy atak na komunikacje pomiędzy jej uczestnikami, to może również da się przechwycić komunikację do wydawcy certyfikatów? W teorii – tak, jednak jest to niepraktyczne. System operacyjny jest dostarczany z odpowiednimi certyfikatami głównymi (ang. root certificate), którymi można weryfikować tożsamość wydawcy, a nawet niektórych stron producenta systemu. Bardzo często w opcjonalnych aktualizacjach na stronie Windows Update występuje także aktualizacja certyfikatów głównych – polecam ściągać, żeby uniknąć niespodzianek.
 
Dochodzimy do wniosku, że komunikacja jest zabezpieczona, gdy certyfikat strony został zweryfikowany przez głównego wydawcę certyfikatów (transmisja szyfrowana niepodstawionymi kluczami – odporna na atak pośrednika). Proste, ale jest jeszcze kilka kruczków w tym systemie.
 
Teoretycznie komunikacja jest bezpieczna, ale w praktyce, pomimo zaufania obu stron (po zweryfikowaniu kluczy), jest możliwe, że wystąpi fizyczne naruszenie komunikacji – dla domowego użytkownika typowym zagrożeniem jest keylogger. Dla wydawcy certyfikatu lub strony używającej certyfikatu jest to po prostu kradzież lub ataki kryptograficzne (próby zgadnięcia klucza na podstawie wcześniej wysyłanych danych). Założenia dość pesymistyczne, ale realne. W celu utrudnienia takich ataków klucze posiadają ważność – datę wygaśnięcia i datę wystawienia. W ten sposób stare lub kradzione klucze nie mogą później zostać użyte. Dla użytkownika oznacza to dość niezrozumiały komunikat o niezgodności bieżącej daty z datą ważności certyfikatu (przypadek POLAND[PL]). Jest to zazwyczaj spowodowane przestawieniem zegarka, ale jeśli spotkaliśmy się z takim błędem na poważnej stronie, typu sklep lub bank, nie można tego zignorować. W skrajnie pesymistycznym przypadku oznacza to, że ktoś próbuje przechwycić transmisję przy pomocy starych kluczy. Częste na mało zadbanych serwerach uczelnianych i amatorskich.
 
Jakby było mało skomplikowania, dochodzi tu jeszcze jedna kwestia – pieniądze. Wydawca certyfikatów, taki jak VeriSign albo Thawte, nie udostępnia swoich usług za darmo! Dlatego większość amatorskich lub niekomercyjnych stron posiada jeszcze jeden komunikat o kłopocie z certyfikatem. Niestety, tak jak wszystkie informacje o stanie połączenia, nie ma tu żadnego standardu. Wiadomość nie jest generowana przez system operacyjny, lecz przez każdą przeglądarkę samodzielnie. Pod Chrome otrzymujemy wiadomość (przykładowa strona https://www.openrce.org):

No właśnie, co się stało się? Kontynuować, czy nie? Firefox wyświetla:

Lepiej, bo przynajmniej wiemy, że połączenie nie jest zabezpieczone. Jak widać nie tylko powoduje to problem w zrozumieniu, co się właściwie dzieje, ale także nie podaje dokładnie przyczyny. Na szczęście wyjaśnienie jest bardzo proste – podany certyfikat strony https://www.openrce.org jest nie tylko przeterminowany, ale również samopodpisany. Są to dwa podstawowe przypadki problemów z certyfikatami, oba nie powinny być zignorowane, jeśli potrzebujemy bezpiecznej transmisji (sklep, bank itd.).
 
Według mnie najlepszy komunikat podaje Internet Explorer 8:

Po pierwsze jasno wiemy, że wystąpił problem (a nie wygląda to jak komunikat informacyjny jak w Chrome). Podkreślony jest lepszy wybór (zamknij stronę domyślnie), ale jednocześnie nie ma przesadnej komplikacji ominięcia błędnego certyfikatu jak w Firefoksie (po co tworzyć regułę wyjątku dla jednorazowo odwiedzonej strony?). Dodatkowo nie występuje zduplikowanie informacji o problemach i jest chyba najlepsze wyjaśnienie sensu komunikatu. Osobiście uważam, że próby przełożenia technicznego problemu na język „zwykłych ludzi” jak w Chrome są zbędne. Przez takie zabiegi późniejsze wyszukiwanie problemu na Google jest utrudnione, a i tak nikt tego nie zrozumie.
 
Samopodpisany (ang. self signed) certyfikat jest po prostu wynikiem rezygnacji właściciela strony z kosztownych usług wydawcy certyfikatów (IE8 – „not issued by trusted certificate authority” tłum. nie wydany przez zaufanego wydawcę certyfikatów). Jest też możliwe, że wybrany został inny model dystrybucji i weryfikacji certyfikatów (np. w firmie można zainstalować zaufane certyfikaty przy pomocy administratora). Oczywiście w przypadku komputera domowego, samopodpisany certyfikat oznacza, że transmisja nie została zabezpieczona przed atakiem pośrednika.
 
Battle.net i inne niepowiązane ciekawostki z dziedziny szyfrowania danych w Internecie
 
Jako ciekawostkę można przyjrzeć się systemowi weryfikacji hasła na Battle.necie. Łatwo można się przekonać, że dane gry są niezaszyfrowane, podsłuchując ruch w sieci programem WinPCap. Jakim cudem nie dochodzi codziennie do kradzieży haseł? Otóż samo hasło nigdy nie jest przesyłane do serwera. Brzmi to nieco nielogicznie, ale ponownie wyjaśnienie tkwi w matematyce. Połączenia HTTP są chronione przez protokół SSL (stąd często https przed nazwą szyfrowanego połączenia), który od negocjacji kluczy szyfruje całą transmisję.
Battle.net nie korzysta z takiego kompletnego rozwiązania, prawdopodobnie w celu oszczędności zasobów. Jedynie faza początkowa negocjacji połączenia jest w pewnym sensie zaszyfrowana – bezpieczna. Podobnie jak z kluczy publicznych nie da się wygenerować szybko prywatnych, istnieją inne możliwości wykorzystania funkcji z ciekawymi właściwościami. Battle.net korzysta z protokołu SRP (Secure Remote Password – bezpieczne hasło zdalne). Po sieci wędruje wyłącznie wynik specjalnych funkcji, które w ostateczności pozwalają uwierzytelnić klienta (gracza) i serwer (Battle.net). Żaden z nich nie jest jednak łatwo odwracalny do postaci pozwalającej poznać lub zgadnąć hasło. Można powiedzieć, że obie strony przedstawiają dowód znajomości hasła, bez przesyłania samego hasła.
 
Drugą ciekawostką w tej dziedzinie są połączenia z serwerami pocztowymi. Ponieważ pochodzą one z „dawnych”, niezbyt wymagających od strony bezpieczeństwa czasów, hasła są zazwyczaj wysyłane w formie zwykłego tekstu. Dlatego większość dostawców poczty pozwala na zaszyfrowanie całego połączenia przez SSL – jednak domyślnie jest ono wyłączone na przykład w programie OE! W szczególności dla najpopularniejszego protokołu POP3, rzadko która darmowa poczta zezwala na bezpieczne uwierzytelnianie hasła (nieco podobne do wcześniej wspomnianego SRP), więc dbający o bezpieczeństwo użytkownik powinien zawsze korzystać z SSL do odbierania i wysyłania poczty. Użytkownicy poczty na stronach WWW są nieco bezpieczniejsi, bo chyba wszyscy więksi znani dostawcy pozwalają na połączenie przez https. Jeśli korzystamy z programu klienta poczty, to ten fragment konfiguracji konta jest pozostawiony użytkownikowi. Oczywiście nie zmieni to faktu, że sam dostawca zazwyczaj skanuje pocztę dla celów reklamowych…
 
Podsumowanie
 
Jeśli żądamy bezpiecznej transmisji, to nie można zignorować błędów certyfikatów. Żaden szanujący się sklep lub bank nie posiada samopodpisanych lub przeterminowanych certyfikatów. Oczywiście zawsze na początku należy się upewnić, że mamy ustawioną poprawną datę na swoim komputerze.
 
Przyczyną całego zamętu jest konieczność weryfikacji kluczy przez głównego wydawcę. Ponieważ kosztuje to realne pieniądze, a nie wprowadzono jako standardu odmowy połączenia przez programy, gdy certyfikat jest zły (niespełniający wszystkich kryteriów bezpieczeństwa), użytkownik łatwo może wpaść w pułapkę.
 
Jeśli kusi was zignorowanie tych komunikatów, to pamiętajcie, że jest to równoważne z rezygnacją z szyfrowania transmisji.

Zamieścił: pyton, dnia: 17:29:46, Sunday 05. April 2009

Komentarze:

1: BLIZZARD, です
[19:32:17, Sunday 05. April 2009] , Zgłoś do moderacji
Nice art ;)

[20:07:10, Sunday 05. April 2009] , Zgłoś do moderacji
gj : )

[12:01:27, Monday 06. April 2009] , Zgłoś do moderacji
Jak zwykle dobra robota :)

4: Prezesozord, moderator
[16:52:44, Monday 06. April 2009] , Zgłoś do moderacji

[22:51:34, Tuesday 07. April 2009] , Zgłoś do moderacji
xDD :D

6: Lex
[17:54:35, Thursday 09. April 2009] , Zgłoś do moderacji
hahaha Poland[PL] NICE ! HAHA

[23:48:58, Saturday 25. April 2009] , Zgłoś do moderacji

Więcej?

Chcesz znaleźć informacje na konkretny temat? Przejrzyj hasła, których najczęściej dotyczą dodane ostatnio nowości! WC3L, TURNIEJ, WCG, NETWARS, LCW, WORLD CYBER GAMES, TERROR, DOTA, GRUBBY, MYM, PALADYN, WYWIAD, REPPACK, WARCRAFT, BLIZZARD, MOON, PORADNIK, POL-TEAM, BIOT, POLSKA, ESL, KONKURS, LIGA, WORLD ELITE, FUZJA, NGL-ONE, ENC, NGL, TOD, TDEL, SPQR, SLH, MOUZ, PGS, TOUR, GFO, WILQ, BRONZE, KODE5, WILDA, PATCH, TEAM FIGHTING, LADDER, REPREZENTACJA, SILVER, HEADSHOT, EXTREME MASTERS, HEYAH, FLY100%, VOODOO, LYN, KUJA, BIOHAZARD-TEAM, BVG, WICKED, ESWC, ALMOST, TH000, ACIS, KWAKI, CYKLOP, SHOW, KLIMO, REPLAYPACK, INCUP, CLAN BASE, HOORAI, SASE, ELIMINACJE, FINAłY, FNATIC, POLTEAM, SHOWMATCH, WCG 2006, IEST, SRS, FINAł, CYBERSPORT, WE.EU, PLD, SKY, PRAE, REMIND, JAGR, CASIN, LAN, REPLAYS.PL, CHALLENGE, ANIMATOR, 2007, BATTLENET, CARMAC, HAPPY, NATIONS, STARCRAFT, PEDAL, KONKURSIWO, W3ARENA

Copyright © Wszelkie prawa zastrzeżone,
kopiowanie tylko za zgodą właściciela.
2003/2007 by: CyklOP, Muzami, Julas [ Mapa Strony ]
Replayów w bazie: 19538 Kont użytkowników: 11428

Pomysł, oskryptowanie, administracja: CyklOP [jak kupić zagraniczne akcje] [Jak wypełnić W-8BEN] [Jak tanio wymienić walutę] [deutschtests]
Design: Muzami, art w topie strony nadesłał Z4buZa
Skrypt obsługujacy replaye: Juliusz 'Julas' Gonera [ Replay Parser ]
Wykonano w czasie 0.41328692436218 sekund