[ Pobierz całość w formacie PDF ]
connect().
#include
#include
#include
#include
int spc_mysql_real_connect(MYSQL *mysql, const char *host, const char *pw,
const char *db, unsigned int flags) {
int port = 0, result = 0;
char *host_copy = 0, *p;
const char *socket = 0, *user = 0;
if (host) {
if (!(host_copy = strdup(host))) return 0;
if ((p = strchr(host_copy, '@')) != 0) {
user = host_copy;
*p++ = 0;
host = p;
}
if ((p = strchr((p ? p : host_copy), ':')) != 0) {
*p++ = 0;
port = atoi(p);
}
if (*host == '/') {
socket = host;
host = 0;
}
}
/* poniższy znacznik wystarczy do aktywowania obsługi protokołu SSL w ramach połączeń */
flags |= CLIENT_SSL;
if (mysql_real_connect(mysql, host, user, pw, db, port, socket, flags))
result = 1;
514 | Rozdział 9. Komunikacja sieciowa
if (host_copy) free(host_copy);
return result;
}
Jeżeli serwer skonfigurowano tak, aby wymagany był certyfikat, może on wraz z kluczem zo-
stać określony w pliku my.cnf i należy wówczas użyć funkcji mysql_options() z opcją MYSQL_
READ_DEFAULT_GROUP w celu odczytania odpowiedniej grupy konfiguracji dla swojej aplikacji.
Opcje związane z używanym certyfikatem i kluczem to, odpowiednio, ssl-cert oraz ssl-key.
Ponadto można użyć opcji ssl-ca oraz ssl-capath w celu określenia pliku lub katalogu za-
wierającego zaufane certyfikaty, które mają być używane w czasie procesu weryfikacji. Ostatnią
opcją jest ssl-cipher, której można użyć w celu określenia używanego szyfru lub zestawu
szyfrów. Wszystkie te opcje mają również zastosowanie w przypadku konfiguracji serwera.
Innym rozwiązaniem jest użycie nieudokumentowanej funkcji mysql_ssl_set() w celu
ustawienia klucza, certyfikatu, pliku zaufanego certyfikatu, katalogu zaufanego certyfikatu
oraz szyfru. Ze względu na fakt, że funkcja ta jest nieudokumentowana, jest prawdopodobne,
że zostanie ona w przyszłości usunięta lub zmieniona bez ostrzeżenia2. Prototyp tej funkcji
zdefiniowano w pliku mysql.h i ma on następującą postać:
int STDCALL mysql_ssl_set(MYSQL *mysql, const char *key, const char *cert,
const char *ca, const char *capath, const char *cipher);
Wreszcie należy zauważyć, że przejrzenie kodu zródłowego MySQL-4.0.10.-gamma (najnowszej
wersji w czasie pisania tej książki) pozwala odkryć, że jeśli ustawi się certyfikat używając opcji
pliku konfiguracyjnego lub nieudokumentowanej funkcji mysql_ssl_set(), klient będzie
podejmował próby łączenia się z serwerem z wykorzystaniem SSL bez względu na określenie
lub nie znacznika CLIENT_SSL przekazywanego do funkcji mysql_real_connect().
PostgreSQL
Domyślnie w trakcie konsolidacji serwera PostgreSQL obsługa protokołu SSL jest wyłączona.
W celu zapewnienia obsługi pakietu OpenSSL należy określić opcję --with-openssl
w wierszu poleceń dla skryptu konfiguracyjnego. Nawet w przypadku serwera PostgreSQL
skonsolidowanego z opcją obsługi SSL domyślnym postępowaniem jest nieuwzględnianie
tego protokołu. W tym celu należy ustawić parametr ssl na wartość on w pliku konfiguracyj-
nym postgresql.conf. W razie aktywacji protokołu SSL należy zapewnić, aby pliki server.key
oraz server.crt zawierały, odpowiednio, klucz prywatny oraz certyfikat serwera. PostgreSQL
będzie poszukiwał tych dwóch plików w słowniku danych i muszą one być obecne, aby serwer
mógł wystartować.
W przypadku konfiguracji domyślnej PostgreSQL nie wymaga od klientów, aby łączyły się
z serwerem poprzez protokół SSL jego użycie to opcja ściśle związana z klientem. Jednakże
można wymagać od klientów użycia SSL, wykorzystując format rekordu hostssl w pliku
pg_hba.conf.
Funkcja PGconnectdb() interfejsu API C serwera PostgreSQL wymaga, aby obiekt conninfo
był wypełniony oraz przekazany do niej w celu zestawienia połączenia z serwerem. Jednym
z pól w strukturze conninfo jest pole całkowitoliczbowe o nazwie requiressl, które pozwala
2
Wersje MySQL wcześniejsze niż 4.00 wydają się przynajmniej częściowo obsługiwać połączenia SSL, jednak nie
istnieją żadne opcje konfiguracyjne, które pozwoliłyby na ich aktywowanie. Funkcja mysql_ssl_set() istnieje
w wersji 3.23 i prawdopodobnie również we wcześniejszych wersjach, ale jej sygnatura różni się od występującej
w wersji 4.00.
Zabezpieczanie połączeń bazodanowych | 515
zdecydować klientowi, czy w ramach połączenia powinien być używany protokół SSL. W razie
ustawienia jego wartości na 1 połączenie zakończy się niepowodzeniem, jeżeli serwer nie będzie
obsługiwał SSL. W przeciwnym razie użycie SSL zostanie wynegocjowane w trakcie procesu
wymiany potwierdzeń. W tym ostatnim przypadku protokół SSL będzie używany tylko
wówczas, gdy w pliku pg_hba.conf istnieje rekord hostssl wymuszający używanie przez
klientów protokołu SSL.
Zobacz również
Receptura 9.5.
9.11. Używanie wirtualnych sieci prywatnych
w celu zabezpieczenia połączeń sieciowych
Używanie wirtualnych sieci prywatnych w celu zabezpieczenia połączeń sieciowych
Problem
Nasz program działa w sieci i współpracuje z istniejącą infrastrukturą, która nie zapewnia
żadnego wsparcia dla bezpiecznej komunikacji, takiej jak w ramach SSL. Jest pewne, że program
będzie używany tylko przez określoną grupę użytkowników i zachodzi potrzeba zabezpiecze-
nia ruchu sieciowego przed atakami podsłuchu i przechwytywania połączeń.
Rozwiązanie
W przypadku tego rodzaju problemów wystarczy użycie rozwiązania tunelującego SSL (takie-
go jak program Stunnel), jednak wymagania odnośnie do certyfikatów oraz ograniczone opcje
weryfikacji oferowane przez Stunnel mogą nie spełniać stawianych wymagań. Ponadto niektó-
re protokoły sieciowe nie dopuszczają tunelowania SSL (takim protokołem jest na przykład FTP,
gdyż może używać losowych portów w przypadku komunikacji w obu kierunkach). Alternatyw-
nym rozwiązaniem jest użycie wirtualnej sieci prywatnej (ang. virtual private network, VPN) w za-
kresie usług sieciowych, których wymaga program.
Analiza
Zadanie konfigurowania i uruchomienia wirtualnych sieci prywatnych może niekiedy okazać
się niebanalne. Może występować wiele problemów związanych ze współpracą różnych plat-
form, jednak sieci VPN stanowią eleganckie rozwiązanie o tyle, że wymagają mniejszej liczby
modyfikacji reguł zapory sieciowej (szczególnie, jeśli wchodzi w grę wiele niezabezpieczonych
usług sieciowych), wiążą się z mniejszymi kosztami związanymi z wdrożeniem oprogramowa-
nia tunelującego oraz mniejszymi wymaganiami co do konserwacji. Dodanie lub usunięcie
usług stanowi kwestię jej włączenia lub wyłączenia nie są wymagane żadne zmiany w konfi-
guracji zapory sieciowej lub mechanizmu tunelowania. Kiedy sieć VPN zostanie skonfiguro-
wana i uruchomiona, zasadniczo sama dba o swoje prawidłowe działanie.
Choć warto rozważyć możliwość użycia sieci VPN w przypadku, gdy inne zaprezentowane
dotąd rozwiązania nie wchodzą w rachubę, pełne omówienie tego rodzaju metody znacznie
516 | Rozdział 9. Komunikacja sieciowa
wykracza poza ramy niniejszej książki. Zagadnieniu temu poświęcono całe tomy i najlepszym
rozwiązaniem jest tu sięgnięcie po któryś z nich. Dobrym punktem wyjścia może być pozycja
Building & Managing Virtual Private Networks autorstwa Dave a Kosiura (John Wiley & Sons).
9.12. Tworzenie uwierzytelnionych bezpiecznych
kanałów bez użycia SSL
Tworzenie uwierzytelnionych bezpiecznych kanałów bez użycia SSL
Problem
Chcemy szyfrować komunikację między dwoma węzłami bez użycia protokołu SSL oraz związa-
nego z tym narzutu. Ze względu na fakt, że zwykle błędem jest szyfrowanie bez kontroli spójno-
[ Pobierz całość w formacie PDF ]