Certyfikaty i ich wykorzystanie – pomocne linki

Na uwagę zasługją dwie wirtyny polskie (obok sławetnego stowarzyszenia PEMI). Jedna to ipsec.pl a druga securitystandard.pl oraz osoba Pana Pawła Krawczyka (pseudo Krawiec). W Polsce najważniejsza strona to http://www.nccert.pl/ncc/home.aspx – Narodowe Centrum Certyfikacji przy NBP, które jest wyznaczone do pełnienia “funkcji głównego urzędu certyfikacji dla infrastruktury bezpiecznego podpisu elektronicznego w Polsce” oraz “prowadzenia rejestru kwalifikowanych podmiotów świadczących usługi certyfikacyjne”. Jak bezpieczna jest strona “https://www.nccert.pl/ncc/home.aspx”? Nie za bardzo, w testach qualsys osiągnęla 81% (ING Bank Śląski uzyskał więcej bo 85%).

NCC prowadzi listę podmiotó świadczących usługi certyfikacyjne. Są to:

1. MobiCert - http://www.mobicert.pl/?page=87 – posługuje się aplikajcą PROTECTOR
2. CenCert - http://www.cencert.pl/ – (enigma i comp.pl)
3. Safe Technologies z Krakowa
4. KIR, CERTUM i SIGILLUM

Materiały Krawczyka (firma ipsec świadczy KOMERCYJNE usługi):

1. http://www.securitystandard.pl/news/327774_6/Podpis.elektroniczny.w.dokumentach.Adobe.PDF.html a tam można znaleźć odnośniki do technicznych stron Adobe:
   1. http://learn.adobe.com/wiki/display/security/Document+Library – parametryzacja przy pomocy wpisów w rejestrze Windows
   2. http://www.adobe.com/devnet/acrobat.html
   3. Słynny odnośnik do paczki z zaświadczeniami polskich urzędów certyfikacyjnych
2. http://ipsec.pl/kwalifikowany-podpis-elektroniczny/praktyka-podpisu-elektronicznego-w-polsce.html
3. Jego doradctwo - http://ipsec.pl/informatyzacja/doradztwo-w-zakresie-podpisu-elektronicznego-bezpieczenstwa-it.html
4. Co z tą eFakturą – interpretacja własna autora - http://ipsec.pl/faktura-elektroniczna-e-faktura/2011/jak-zapewnic-autentycznosc-integralnosc-faktury-elektronicznej.html
5. Biblioteka i bibliografia - http://ipsec.pl/kryptografia/biblioteka-ipsecpl.html
6. Wszystkie (mam nadzieję) ustawy o podpisie - http://ipsec.pl/prawo-polskie/podpis-elektroniczny-w-polskim-prawie.html a wśród nich najważniejsza ustawa o podpisach (jako projekt mający na celu wykonanie prawa Unii Europejskiej) wpłynęła ona do zatwierdzenia do Sejmu RP w dniu 23 listopada 2010, aktualnie sprawa jest niezamknięta (poprawki), jest też uzasadnienie - http://orka.sejm.gov.pl/Druki6ka.nsf/0/6D8DB0ECB92CDB76C12577E6005849C3/$file/3629-uzas.doc

Oficjalna strona MG na temat podpisu - http://www.mg.gov.pl/Wspieranie+przedsiebiorczosci/Dzialalnosc+gospodarcza+i+e-przedsiebiorczosc/Podpis+elektroniczny oraz oficjalny podręcznik do podpisu.

Najnowsze rozporządzenie o efakturze - http://www.mf.gov.pl/dokument.php?const=3&dzial=135&id=232702.

Certyfikaty testowe, darmowe dla osób indywidualnych i płatne (dla firm) - http://www.startssl.com/?app=26

Dalszy przebieg wydarzeń z SSL-em

Na stronach the register pojawiła się wzmianka, że Firefox planuje blokowanie pluginów w Javie (popularnych appletów). Stało się to po tym jak badacze Thai Duong i Juliano Rizzo pokazali jak przy pomocy tej techniki obeszli wymóg SOP (same origin policy) – elementu koniecznego w procesie przeprowadzeniu ataku na SSL. Dlatego planuje się zablokowanie tego frameworku w Firefox tym bardziej, że FF i Chrome nie wspierają TSL 1.1 i wyżej (chyba tylko Opera i IE mają wbudowaną obsługę tego nowego protokołu, ale to nie zawsze pomaga, gdyż w momencie negocjacji połączenia klient - serwer, ten ostatni może wymusić obniżenie bezpieczeństwa poprzez zejście z sugerowanego przez klienta protokołu TSL 1.1 na TLS 1.0).

Konsekwencje blokady są straszne – java plugin to taka wersja ActiveX, która umożliwia “przemycanie” do komputera rozmaitych kodów wykonywalnych pochodzących z zewnątrz (np. z internetu), dzieje się to z obejściem wszelkich zabezpieczeń – sprawdza się tylko czy kod  apletu jest podpisany. Z tego mechanizmu korzysta wielu dostawców oprogramowania np. CISCO “wstrzykuje” na komputer klienta swego AnyConnecta, Facebook umożliwia usługę chat-u itd. Zablokowanie tego może pogorszyć tzw. user expirience ale niestety implementacja SSL w javie stanęła ma 1.0 - http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html. Obecnie w blogu Mozilla Security piszę się aby jako obejście wprost zablokować wtyczkę do Javy w zarządcy wtyczek FF. Nawiasem mówiąc Chrome blokuje uruchamianie wtyczek w Javie. Dalej na stronach Chrome “Chrome and the BEAST” pisze się, że serwery Google od dawna stosują RC4.

Inna strona o tym - http://www.h-online.com/open/news/item/Mozilla-considers-disabling-Java-in-Firefox-1351590.html

Różności o bezpieczeństwie

Z ITWorld – dlaczego strona MySQL została zainfekowana tak, że wysyłała złośliwe oprogramowanie do przeglądarek? Dlatego, że intruz wstrzyknął kod JS, który wykorzystał słabości zainstalowanych u klienta pakietów użytkowych (Adobe Reader, Flash i Java) – “Security vendor Armorize noticed the problem at around 5 a.m. Pacific Time Monday. Hackers had installed JavaScript code that threw a variety of known browser attacks at visitors to the site, so those with out-of-date browsers or unpatched versions of Adobe Flash, Reader or Java on their Windows PCs could have been quietly infected with malicious software.” – przez to zaraził komputery klientów. Potwierdza to fakt, że coraz więcej ataków wykorzystuje źle zaktualizowane programu użytkowe na stacji klienta. PSI firmy Secunia potrafi na bieżąco śledzić stan i wersje takiego oprogramowania – ten monitor jest bezpłatny.

Na temat nowego ataku SSL - http://windowssecrets.com/links/y6pkszr6i9uqd/e0c916h/?url=technet.microsoft.com%2Fen-us%2Fsecurity%2Fadvisory%2F2588513. Atak polega na przechwyceniu ciasteczek sesji w trakcie sesji HTTPS i odszyfrowaniu ich i co za tym idzie ukraść sesję. Atak się udaje w przypadku użycia protokołu TLS 1.0 i wykorzystaniu w nim kodowania CBC. Obejście polega na stosowaniu kodowania RC4 lub przejścia na protokół TLS 1.1 lub wyższy (ale nie wszystkie serwery internetowe go wspierają). W polityce grupowej można nadać RC4 wyższy priorytet - TLS_RSA_WITH_RC4_128_SHA.

Uwaga wg. NetworkWorld: ratunkiem przed potencjalnym atakiem jest ustawienie kolejności (priorytetu) w jakiej UZGADNIANE są algorytmy szyfrowania podczas sesji HTTPS (w czasie negocjacji specyfiki protokołu wymiany między klientem a serwerem). Podatność na atak (znana od 2004 i od 2006 organizacja IETF polecała mocniejszy protokół TLS 1.1, ale uważano, że nie da się jej wykorzystać) polega słabości algorytmu BLOKOWEGO CBC a nie strumieniowego.

Certyfikaty:

1. Na betanews ukazał sie artykuł o wykorzystaniu certyfikatów utworzonych samodzielnie SSC (Self Signed Certificate) ale wykorzystywanych do podpisywania stron internetowych przy korzystaniu z SSL. IE 7 i FF 3.0 wyświetlają ten fakt dość nieprzyjemnie ten fakt informując użytkownika o potencjalnym naruszeniu bezpieczeństwa z uwagi na niezaufanie do urzędzu któy wystawił ten certyfikat. Dodatkowo powodują domyślne przyznanie zaufania do innych stron wymienionych w certyfikacie (alternate sites) a te już mogą być bardzo niebezpieczne. Z drugiej strony posługiwanie się certyfikatem jest podstawą (wymusza) korzystania z SSL do szyfrowania ruchu HTTP, a nie każdego stać na kupno "legalnego" certyfikatu. Witryna StartSSL daje bezpłatny certyfikat klasy 1.

Ciekaw strony:

1. SideJacking - b. niebezpieczne zagrożenie wytypowane w pierwszej 5 zagrożeń 2007. Witryny zwykle szyfrują dane poufne, ale wysyłają "session-id" danej sesji w jawnym tekscie. Trzeba dokładnie poznać "zakamarki" protokołu HTTP/HTTPs oraz narzędzia Wireshark oraz Mozilla cookie editor. Ten obiekt jest przesłany w:
   1. URL jako losowo wybrane dane
   2. jako HTTP cookie, ciasteczka są wysyłane za każdym razem do serwera(chyba, że są zaznaczone jako prywatne)

Hacker może podejrzeć session-id i uzyskać dostęp do konta i np. odczytać zawartość poczty .

1. Więcej na te tematy - http://blog.icir.org/2008/02/sidejacking-forced-sidejacking-and.html
2. Uwaga: ciasteczka mogą być zaznaczone jako secure ) GX - wtedy należy stosować SSL (wymuszony jest)

Znowu SSL
Ale w szerszym zakresie. SSL stosuje elementy kryptografii a właściwie kodowanie trzech typów:

1. hash - kodowanie w jedną stronę, służy do sprawdzenie nienaruszalności danych, jest to algorytm obliczający skrót jakiegoś długiego dokumentu. Skrót ten ma być unikalny. Każdy inny dokument daje w wyniku inny skrót. Zwykle ten skrót poddaje się szyfrowaniu. Odbiorca odszyfrowuje skrót ponownie i oblicza skrót na podstawie otrzymanej wiadomości. Oba te skróty powinny być jednakowe.
   
2. symetryczne - do szyfrowanie treści służy jeden i ten sam klucz. Obliczenia związane z szyfrowaniem kluczem symetrycznym są szybkie i służą do szyfrowania dużych treści przesyłanych informacji. Problem jest jednak z wymianą tego klucza (dostarczeniem) do nadawcy i odbiorcy tak aby haker nie mógł go przechwycić.
   
3. asymetryczne - stosowane są dwa klucze: prywatny (u nadawcy-autora) i publiczny (dostępny wszystkim). Do szyfrowania mogą służyć oba klucze. Szyfrując kluczem publicznym kogoś powodujemy, że tylko on może odczytać wiadomość. Szyfrując swoim kluczem prywatnym wszyscy inni mogą wiadomość odczytać. Problem jest jednak weryfikacją kto stoi za tym kluczem.

Ten ostatni problem rozwiązują certyfikaty właściciela. Są wydawane przez tzw. zaufane urzędy i stanowią paczkę informacji (klucz publiczny właściciela, informację o nim oraz informację o wystawcy/wystawcach certyfikatu oraz dodatkowo klucz publiczny urzędu wystawiającego).
Certyfikat jest zaszyfrowany kluczem prywatnym tego urzędu. Kiedy odbiorca odczytuje certyfikat przy pomocy klucza publicznego urzędu to wie, że dane pochodzą od tego urzędu, a dane te to informacja o nadawcy.
W celu zapanowania nad wydanymi certyfikatami każdy z nich ma okres ważności (dlatego trzeba go odnawiać) i stworzono listę certyfikatów odwołanych (CRL).
Urzędy certyfikacyjne są wbudowane w przeglądarki internetowe i podczas aktualizacji przeglądarek mogą być dodane lub usunięte.
Jak to działa razem?

• Połączenie inicjuje klient i podaje serwerowi swoje możliwości kodowania
• Serwer odpowiada wysyłając do klienta swoje możliwości i swój certyfikat oraz losowe dane
  
• Klient sprawdza certyfikat czy jest ważny i zaufany
• Gdy certyfikat serwera jest OK to klient wysyła losowo wygenerowany klucz sesji i koduje go kluczem publicznym serwera (może też wysłać dane autentykujące go zakodowane też kluczem pub. serwera)
• Serwer to odbiera i rozkodowuje swoim kluczem prywatnym, teraz ma klucz od klienta tzw. master key (mają dzięki temu ten sam klucz). Posłuży on do generowanie klucz sesji

Źródło: TechRepublic

Linki ciekawe:

1. Tworzenie aplikacji wykorzystujacej open-source: http://www.onjava.com/pub/a/onjava/2004/04/07/wiringwebapps.html
2. jsc for C#
3. Baldwin Java - Servlets
4. Przeechowywanie stanu i or-mapping bez Hibernate - doskonaly przyklad - http://www.ibm.com/developerworks/java/library/j-db4o4.html?ca=drs-
5. OnJava - Google Gears p. 1.
6. RH i MS rozmawiają o interoperability - http://www.eweek.com/article2/0,1759,2154521,00.asp?kc=EWRSS03129TX1K0000616
7. Jak to jest z zabezpieczeniem SSL - http://webdesign.about.com/od/ecommerce/a/aa070407.htm
8. Blog na temat J2EE - servlet v. 3.0 - http://java.sun.com/javaee/community/blogs/?feed=JSC
9. Wreszczcie JSF 2 - http://www.oreillynet.com/onjava/blog/2007/05/jsf_20_is_here_1.html
10. Języki dynamiczne w srodowisku Java - http://www.oreillynet.com/onjava/blog/2007/06/scripting_language_for_the_jav.html
11. Szpiegowanie klas - reflection- http://www.onjava.com/pub/a/onjava/2007/03/15/reflections-on-java-reflection doskonały przykład.
12. Doskonały serwis o Javie - http://www.onjava.com/
13.