mrk's techblog

Mając do dyspozycji certyfikat kwalifikowany, chciałem użyć go do silnego uwierzytelniania do serwisu www. Nie spodziewałem się większych problemów, jednak okazało się, że sprawa nie jest taka prosta jak się na początku wydawało - i stąd ta notka.

Nie będę pisał o samym uwierzytelnianiu za pomocą certyfikatów klienta - w sieci napisano na ten temat sporo. Skupię się na problemach specyficznych dla polskich certyfikatów kwalifikowanych.

Po pierwsze, apache musi mieć ustawiony certyfikat Narodowego Centrum Certyfikacji za pomocą dyrektywy SSLCACertificateFile lub SSLCACertificatePath w pliku konfiguracyjnym. Certyfikaty można pobrać stąd. Po restarcie apache'a w logach SSL'a na poziomie debug powinniśmy mieć informację:

[debug] ssl_engine_init.c(1092): CA certificate: /C=PL/O=CZiC Centrast SA w imieniu Ministra Gospodarki/CN=CZiC Centrast SA
[debug] ssl_engine_init.c(1092): CA certificate: /C=PL/O=Minister wlasciwy do spraw gospodarki/CN=Narodowe Centrum Certyfikacji (NCCert)
[

Pierwszy problem - na początku żadna ze sprawdzanych przeze mnie przeglądarek nie chciała użyć (zaprezentować) certyfikatu serwerowi, pomimo, że był widoczny dla samej przeglądarki (pod IE jako certyfikat osobisty w Opcje internetowe / Zawartość / Certyfikaty, w FF Opcje/zaawansowane/szyfrowanie/certyfikaty).

W FF sprawa okazała się prosta - wystarczyło zarejestrować w przeglądarce certyfikaty wystawców (CA). W IE niestety to nie pomogło - przeglądarka pokazywała listę wyboru certyfikatu, ale pustą. Przyczyna, dla jakiej IE ignorował certyfikat, okazała się dość poważna i miała mieć jeszcze dość poważne następstwa - mianowicie rozszerzenie KeyUsage, definiujące możliwości użycia klucza, w certyfikacie kwalifikowanym ma ustawiony jedynie bit nonRepudation, i nie ma ustawionego bitu digitalSignature, wymaganego m.in. do uwierzytelniania klienta. Trochę więcej przeczytać o tym można np. tutaj. W skrócie - bit nonRepudation ustawiony w KeyUsage - określa użycie certyfikatu (a dokładniej klucza prywatnego) do typowego podpisu elektronicznego pod dokumentem, czyli w celu potwierdzenia "niezaprzeczalności" Natomiast bit digitalSignature zezwala użycie klucza w pozostałych przypadkach, m.in. w celu uwierzytelnienia w systemie informatycznym. Takie rozdzielenie ma sens, jeśli chodzi o zapewnienie większego bezpieczeństwa użycia naszego podpisu elektronicznego - bez tego mechanizmu można sobie wyobrazić "zły" serwer, który przy okazji uwierzytelniania klienta za pomocą certyfikatu klienta podsyła nam zamiast losowych wartości challenge skróty jakichś dokumentów, które byśmy nieświadomie podpisywali naszym e-podpisem...

Okazuje się, że w IE można jednak wymusić użycie certyfikatu bez bitu digitalSignature w KeyUsage do autoryzacji klienta, aplikując do rejestru:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl]
"FEATURE_CLIENTAUTHCERTFILTER"=dword:00000001

Po zaaplikowaniu powyższego wpisu do rejestru IE powinien pozwolić na wybranie certyfikatu kwalifikowanego do uwierzytelniania.

Niestety, pomimo że zarówno FF jak i IE pozwalały wybrać certyfikat, Apache dalej odmawiał posłuszeństwa. Dalsze śledztwo wykazało, że z dwóch powodów. Po pierwsze - brak bitu digitalSignature w KeyUsage - Apache honoruje to rozszerzenie i odrzuca certyfikaty klienta nie mające ustawionego bitu digitalSignature. Po drugie - Apache odrzuca certyfikaty mające nieznane rozszerzenia oznaczone jako "krytyczne" - a posiadany przeze mnie certyfikat kwalifikowany takowe posiadał. Rozwiązanie - poniższy patch, powodujący ignorowanie powyższych błędów.

--- apache2-2.2.8/modules/ssl/ssl_engine_kernel.c.orig  2006-07-12 05:38:44.000000000 +0200
+++ apache2-2.2.8/modules/ssl/ssl_engine_kernel.c       2009-10-28 17:19:26.000000000 +0100
@@ -1285,6 +1285,16 @@
     /*
      * And finally signal OpenSSL the (perhaps changed) state
      */
+
+    if(errnum == X509_V_ERR_UNHANDLED_CRITICAL_EXTENSION || errnum == X509_V_ERR_INVALID_PURPOSE) {
+      ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, "ignoring unhandled critical extension or invalid certificate purpose");
+      sslconn->verify_error = NULL;
+      ctx->error = X509_V_OK;
+      SSL_set_verify_result(ssl, X509_V_OK);
+      ok = TRUE;
+    }
+
+
     return ok;
 }

Powyższy patch nie jest chyba zbyt dużym gwałtem na bezpieczeństwo apache'a - powyższy kod wywoływany jest tylko dla certyfikatów klienta, ignorowane są jedynie nieznane rozszerzenia w certyfikacie i rozszerzenie KeyUsage

Konkluzja - certyfikatów kwalifikowanych niestety nie powinno używać się do uwierzytelniania klienta via SSL ale jak ktoś się wyjątkowo uprze to się da :)

I na koniec KONKURS. Tutaj stoi sobie poprawiony j.w. apache, wpuszczający tylko za okazaniem certyfikatu kwalifikowanego. Pierwszej osobie która powie w komentarzu co znajduje się na podanej stronie stawiam piwo :)

Podczas próby zmniejszenia partycji ntfs, gparted zaskoczył mnie komunikatem:

Jak widać współpracy odmówił program ntfsresize, ponieważ znalazł 'zamarkowane' bad sektory. Rozwiązanie - mały wrapper na ntfsresize, który wywoła oryginalną binarkę z opcją "--bad-sectors":

#!/bin/bash
if test "$#" -gt 0; then
  exec ntfsresize.orig --bad-sectors "$@"
else
  exec ntfsresize.orig
fi

Zmieniamy nazwę oryginalnego ntfsresize na ntfsresize.orig, a powyższy kod umieszczamy w tym samym katalogu w pliku ntfsresize, nadając mu oczywiście atrybuty wykonywania. Przed operacją zmiany rozmiaru warto jeszcze wykonać spod Windows "chkdsk /r /p", jak zresztą ntfsresize lojalnie nas uprzedza.

Jak wiadomo, implemetacja OpenID google nie jest najłatwiejsza w użyciu. Google używa tzw. "Directed Identity" z OpenID 2.0 - do logowania używany jest ten sam dla wszystkich url, właściwy identyfikator OpenID użytkownika ustalany jest po uwierzytelnieniu u dostawcy OpenID. Identyfikator OpenID dla google to https://www.google.com/accounts/o8/id - jak widać średnio wygodny do zapamiętania i wpisywania. I właśnie dlatego powstała niniejsza skryptozakładka - szuka na stronie formularza logowania, ustawia identyfikator OpenID i wysyła formularz. Oczywiście można użyć dla dowolnego innego dostawcy OpenID, zmieniając URL.

Tutaj gotowa skryptozakładka: Google OpenID

A tak wygląda w bardziej strawnej postaci:

 
(function() {
  var inputs=document.getElementsByTagName('input');
  for(i=0;i<inputs.length;i++){
    if(inputs[i].type=="text" && inputs[i].name.indexOf('openid')>=0) {
      var f = inputs[i];
      f.value = 'https://www.google.com/accounts/o8/id';
      while(f && f.tagName!='FORM') f=f.parentNode;
      if(f) f.submit();
      return;
    }
  }
  alert('Brak formularza OpenID');
})();
 

Skryptozakładka sprawdzona w FF3.5 i Chromium.

Jakiś czas temu kupiłem uniwersalną "przejściówkę" ATA / mini ATA / SATA na usb. W komplecie znajduję się także zasilacz +5/+12V do zasilenia dysków 3.5" oraz dysków SATA - dyski ATA 2.5 cala nie potrzebują oddzielnego zasilania, ponieważ 4 dodatkowe piny na złączu mini ATA dostarczają zasilanie. I stąd pomysł, by zasilić 2.5" dysk sata ze złącza mini ATA

Uwaga - wskazana najwyższa ostrożność. Pomyłka grozi spaleniem dysku, przejściówki, portu USB w komputerze ew. puszczeniem z dymem całego komputera

Przerabiamy standardową przejściówkę do zasilania SATA: (przepraszam za niską jakość zdjęć - e51 nie nadaję się stanowczo do zdjęć makro)

Podłączamy ją do pinów 41 (+5V) i 43 (masa): (wyprowadzenia ATA 44)

Uwagi:

• Najlepiej by było użyć pełnego złącza mini ATA 44pin, co uniemożliwiło by odwrotne podłączenie zasilania - niestety takim nie dysponowałem i dlatego podwójny gold-pin - trzeba mocno uważać by nie podłączyć zasilania dysku odwrotnie !
• Dobrze zwrócić uwagę na zapotrzebowanie na prąd dysku - mój chce 0.6A, co nie jest wielkim nadużyciem w stosunku do standardu (0.5A / port) i nie powinno grozić przepaleniem ścieżek zasilających USB, ale zasilenie w taki sposób dysku 3.5" może skończyć się źle

Zaglądasz codziennie na pudelka, plotka czy inną naszą-klasę ;) i musisz tłumaczyć się potem kumplom z kompromitującej historii w firefoksie (eh ten awesome bar) ?

Rozwiązanie: trigger w sqlite o takiej postaci:

 
CREATE TRIGGER history_guard_trigger 
BEFORE INSERT ON moz_places 
WHEN new.url IN ('http://pudelek.pl/', 'http://www.plotek.pl/') 
BEGIN  SELECT RAISE(ROLLBACK,'bez takich mi tu'); END
 

Wrzucić można za pomocą świetnego rozszerzenia SQLite Manager, baza 'places.sqlite', polecenie Execute SQL.

P.S. Tak, wiem, że jest niejedno rozszerzenie które daje podobną funkcjonalność, ale tak jest na pewno bardziej geekowsko ;) Poza tym takie rozwiązanie jest prawdopodobnie lżejsze niż instalowanie kolejnego rozszerzenia...

Od jakiegoś czasu chodziło mi po głowie, żeby dodać sobie do Google Apps własny serwer OpenID - korzystając oczywiście z dobrodziejstw Google AppEngine. Podstawowa zaleta w stosunku do serwera zewnętrznego - jedno hasło do pamiętania mniej, uwierzytelniamy się bowiem za pomocą naszego konta w Google Apps.

Okazało się, że sprawa jest prostsza niż na początku się wydawało - w przykładowym kodzie źródłowym do appengine są źródła providera openid, które praktycznie bez zmian można uruchomić na appengine (pamiętając tylko o ustawieniu uwierzytelniania tylko dla swojej domeny). Niestety - kod ten jest od prawie roku nie rozwijany i użyta tam biblioteka openid jest delikatnie mówiąc archaiczna (obsługa tylko openid 1.0).

Wziąłem się więc do roboty i po dwóch dniach poznawania python-openid, kodowania i debugowania udało się uruchomić provider'a na ostatniej wersji python-openid (2.1.1)

Funkcjonalność na razie jest tylko podstawowa - można się logować :) W podstawowy sposób obsługiwane jest także rozszerzenie Simple Registration - pola nickname i email

Źródła do pobrania na stronie projektu.

Tutaj natomiast gotowa do testowania aplikacja id-provider, z uwierzytelnianiem ustawionym dla wszystkich kont google.

Zapraszam do testowania i zgłaszania uwag / błędów i patchy.

W planach dorobienie funkcjonalności typowej dla dostawców openid - edycja profilu użytkownika (danych przesyłanych podczas Simple Registration), pamiętanie po stonie serwera decyzji w sprawie automatycznego logowania (na razie używane są ciasteczka), itd.

Dzisiaj miałem okazję pomagać w procedurze uzyskania certyfikatu kwalifikowanego (wysyłka dokumentów do ZUS). Jako centrum certyfikacji wybraliśmy CERTUM. Przez internet został zamówiony zestaw "CERTUM Standard" - zawierający czytnik kart (podłączany przez USB), kartę kryptograficzną i oprogramowanie.

Mając niejakie pojęcie o kryptografii asymetrycznej, spodziewałem się procedury generowania CSR (Certificate Signing Request), połączonego z generowaniem klucza prywatnego na karcie. Nic z tego jednak - okazuje się, że dostajemy kartę z już wygenerowanym kluczem prywatnym. Na rewersie karty jest 16-cyfrowa liczba, która służy do identyfikacji karty przez CERTUM - i jak zrozumiałem na jej podstawie są w stanie wygenerować mi certyfikat - czyli już znają mój klucz publiczny. I teraz pytanie najważniejszsze: jaką mam gwarancję że nikt nie zna mojego klucza prywatnego? Konsultant CERTUM zapewniał mnie co prawda, że klucz jest co prawda generowany u nich, jednak następuje to na karcie i karta nie umożliwia exportu tego klucza - pozostaje wierzyć na słowo.

Dlaczego klucz nie jest generowany w momencie wypełniania wniosku o certyfikat - jak chyba nakazuje dobra praktyka w takich przypadkach? Ucięło by to możliwość spekulacji na temat prywatności klucza prywatnego...

Ciekawy jestem jak sprawa wygląda u pozostałych dwóch dostawców certyfikatów kwalifikowanych? Jak macie jakieś informacje na ten temat dajcie znać w komentarzach...

PS. Na koniec jeszcze ciekawostka - byłem w tzw. Punkcie Sprawdzania Tożsamości CERTUM w moim mieście - człowiek zapytany o klucz prywatny stwierdził, że nie ma tam żadnego klucza prywatnego tylko certyfikat. Nazwy firmy przez grzeczność nie wymienię :)

Z racji że pracuję w kafejce internetowej, mam okazję zajrzeć na pamięci USB klientów. Z moich obserwacji wynika, że jakieś 90% pendrive'ów przeciętnych zjadaczy chleba zawiera dodatki, o których zainteresowani niestety nie wiedzą. Staram się uświadamiać jak tylko potrafię, ale to kropla w morzu... Ale dzisiaj wpadłem na szatański pomysł. Jak dotrzeć szybko do milionów posiadaczy zainfekowanych pendrive'ów? Puścić edukacyjny łańcuszek na gg :) Jestem oczywiście przeciwnikiem tego typu tworów, ale cel uświęca środki. Mam nadzieję, że pomożecie w komentarzach w edycji formy i treści tego "edukacyjnego łańcuszka". A może mnie po prostu odwiedziecie od tego pomysłu...

Łańcuszek edukacyjny

Wytoczmy wojnę zawirusowanym pendrive'om

1. Otwórz "Mój komputer"
2. Wybierz z menu "Narzędzia/Opcje folderów", potem zakładkę "Widok"
3. W oknie "Ustawienia zaawansowane" włącz "Pokaż ukryte pliki i foldery" oraz koniecznie odznacz "Ukryj rozszerzenia znanych typów plików"
4. Zajrzyj na swojego pendrive'a. Jeżeli znajdziesz tam jakieś pliki z końcówką exe lub com, których sam tam nie nagrałeś(aś) i dodatkowo masz plik autorun.inf, jesteś NOSICIELEM !!! Możesz spróbować skasować te pliki, ale nie zdziw się jak magicznie pojawią się ponownie. Bardzo możliwe, że potrzebna będzie wizyta u specjalisty :(

5. Tak więc zrób co uważasz za słuszne. Wyślij tą wiadomość do wszystkich znajomych, a więcej nie ugoszczą Cię wirusem. Nie przesyłaj wiadomości tym, których sam byś chętnie zaraził :)

   -- 
   Życzliwy Informatyk