2007.09_Kryptografia–serwery poczty_[Bezpieczenstwo].pdf

bezpieczeństwo

Kryptograia – serwery poczty

– serwery poczty

Radosław Podedworny

Jedną z fundamentalnych cech ludzkości jest potrzeba komunikowania się. Oczywiście, na przestrzeni stuleci

zmieniały się kanały za pomocą których odbywała się wyżej wspomniana komunikacja – jednak pewne

problemy poz ostały ponadczasowe. Dotyczą one zabezpieczenia informacji w taki sposób, aby dostęp do niej

miały tylko osoby do tego uprawnione. Problemy te są tym ważniejsze, iż mniej zaufany jest kanał za pomocą

którego dochodzi do wymiany informacji. W naszym przypadku będzie to Internet, więc globalna sieć w której

powinniśmy i będziemy spodziewać się najgorszego.

asymetryczna, klucz publiczny/prywatny, CA, cer-

tyikat itp. są Ci znane – spokojnie możesz pomi-

nąć ten rozdział. Poniżej znajduje się wprowadzenie

skierowane szczególnie do tych, których wiedza o krypto-

graii jest znikoma bądź praktycznie żadna. Zapoznajmy

się więc z podstawowymi informacjami na temat nauki

odpowiedzialnej za poufność przekazywanych informacji

– kryptograii. Informację będziemy szyfrować za pomo-

cą pewnego przepisu (algorytmu szyfrowania). W obrębie

tego przepisu będziemy używać unikalnej matrycy (klu-

cza) za pomocą której dane zostaną zaszyfrowane. Co cie-

kawe, w zdecydowanie przeważającej liczbie algorytmów

szyfrowania, wspomniany powyżej przepis jest publicznie

znany. Siła algorytmu zależy więc od klucza. Współczesna

kryptograia dzieli się na dwie grupy: symetryczną i asy-

metryczną. Różnica polega na ilości kluczy: w pierwszej

dysponujemy jednym kluczem który odpowiada zarówno

za szyfrowanie jak i deszyfrowanie, w drugiej do każdej

z wymienionych powyżej czynności mamy osobny klucz.

Warto przy okazji nadmienić, iż pierwsza metoda jest zde-

cydowanie szybsza niż druga. Nasuwa się więc pytanie:

po co korzystać z kryptograii asymetrycznej ? Odpowiedź

jest prosta: chodzi o bezpieczeństwo klucza. Zostawmy na

chwilę kryptograię i wyobraźmy sobie dwóch przyjaciół

(Romka i Pawła) mieszkających na dwóch krańcach Pol-

ski, wysyłających do siebie paczki (dodatkowo dla bezpie-

czeństwa zamykane w specjalnych kufrach na klucz). Ku-

fry te są zamykane, gdyż po drodze przechowywane są

u Wojtka, którego negatywną przypadłością jest przeglą-

danie niezabezpieczonych przesyłek. Gdyby nasi przyja-

ciele używali do tego celu mechanizmów z kluczem sy-

metrycznym musieliby (zanim wyślą do siebie pierwszą

paczkę) spotkać się osobiście i ustalić ten klucz. Nie mo-

gliby tego klucza wysłać w zamkniętym kufrze, gdyż po to

właśnie mają się spotkać, aby ustalić wzór klucza, którym

można ten kufer zamykać/otwierać. Opcja z wysłaniem

klucza w kufrze otwartym również odpada: istniało by bo-

wiem niebezpieczeństwo, że po drodze Wojtek go otwo-

rzy (w końcu nie jest zamknięty) i podrobi sobie ten klucz.

Tak podrobionym kluczem będzie mógł otworzyć i przej-

rzeć każdy kufer, który przyjaciele w przyszłości będą

między sobą przesyłać. Rozważmy teraz sytuację, w któ-

rym Panowie będą używać mechanizmów kryptograii

wrzesień 2007

Kryptograia

J eżeli takie pojęcia jak: kryptograia symetryczna/

bezpieczeństwo

Kryptograia – serwery poczty

Rysunek 1. Przykładowy zrzut ekranu wykonany na rzeczywistym koncie CACert

dopiero przez Pawła, przy pomocy jego klu-

cza prywatnego. Analogicznie, w drugą stro-

nę: Paweł zamyka kufer kluczem publicznym

Romka. Po drodze Wojtek jest bezradny gdyż

żaden z posiadanych przez niego kluczy nie

pasuje do zamka. Kufer zostaje więc otwarty

dopiero u Romka jego kluczem prywatnym.

Pozostaje jednak jedno pytanie: co się sta-

nie w sytuacji, kiedy Wojtek również wygene-

ruje swoją parę kluczy, klucz prywatny zosta-

wi u siebie a klucz publiczny wyśle do Rom-

ka, pisząc iż należy on do Pawła. Jeśli rzeczy-

wiście tak zrobi,a Paweł da się nabrać, to za-

mknie on kufer kluczem publicznym Wojtka.

Kufer ten po drodze trai do rąk Wojtka, któ-

ry nie będzie miał problemów z otwarciem

kufra – w końcu będzie posiadał klucz od pa-

ry – swój klucz prywatny. Jest to rzeczywiście

realne zagrożenie, ale w tym miejscu w naszej

opowieści pojawia się kolejna osoba. Kasia (bo

o niej mowa) znana jest w całej Polsce. Uważa-

na jest za wielki autorytet który nigdy nie kła-

mie. Romek i Paweł zaraz po stworzeniu swo-

jego klucza publicznego pokazują go Kasi. Ka-

sia podpisuje te klucze, potwierdzając w spo-

sób jednoznaczny i niepowtarzalny, iż dany

klucz rzeczywiście należy do Romka, drugi

z kolei jest własnością Pawła. Pamiętajmy, iż

Kasia jest bardzo uczciwa – tak więc Wojtko-

wi nie uda się otrzymać od Kasi potwierdze-

nia, że jego klucz publiczny jest kluczem Paw-

ła. Za każdym razem, kiedy ktoś będzie chciał

używać klucza publicznego Romka bądź Paw-

ła będzie musiał zobaczyć, czy klucze te są

asymetrycznej. Załóżmy najpierw, że każdy

z nich dysponuje inną parą kluczy: kluczem

publicznym i kluczem prywatnym. Dodatko-

wo paczki będą przesyłać w kufrach ze spe-

cjalnym zamkiem – takim że można go za-

mknąć tylko kluczem publicznym, natomiast

do otwarcia służy odpowiadający mu klucz

prywatny. Teraz każdy z przyjaciół ogłasza

wszem i wobec jak wygląda jego klucz pu-

bliczny: mówiąc inaczej każdy kto chce może

zdobyć klucz publiczny zarówno jednego jak

i drugiego bez najmniejszego problemu. Co

do klucza prywatnego, to jest on znany tylko

jego właścicielowi. Nawet między sobą przy-

jaciele nie wymieniają się tymi kluczami. Jeśli

teraz Romek chce wysłać coś do Pawła, bie-

rze paczkę, wkłada do kufra a kufer zamyka

kluczem publicznym Pawła (jak napisaliśmy

powyżej klucze publiczne zarówno jednego

jak i drugiego przyjaciela są ogólnodostęp-

ne). Tak zamknięty kufer jedzie na drugi ko-

niec Polski. Po drodze wpada w ręce Wojtka.

Ten dysponuje dwoma kluczami publiczny-

mi (Romka i Pawła) – żaden jednak nie pasu-

je aby otworzyć zamek. Kufer zostaje otwarty

Listing 1. Zawartość pliku csr

-----BEGIN CERTIFICATE REQUEST-----

MIIB1zCCAUACAQAwgZYxCzAJBgNVBAYTAlB

MMRIwEAYDVQQIEwlwb21vcnNraWUx

DzANBgNVBAcTBmdkeW5pYTETMBEGA1UEChM

KTW9qYSBmaXJtYTERMA8GA1UECxMI

ZHppYWwgSVQxFjAUBgNVBAMTDW1vamFkb21

lbmEucGwxIjAgBgkqhkiG9w0BCQEW

E2FkbWluQG1vamFkb21lbmEucGwwgZ8wDQY

JKoZIhvcNAQEBBQADgY0AMIGJAoGB

APa/YQuMcae//cY25IHURJ+gOL4YhBWazRl

HErQmxPkOlcthz6CxUNpGmCD/C1dW

vY60XRTAxiRVEhOlmK2HJIp8wzqtO/N5wqZ

ZlMil4GiNoPjeikZKwLBph6PL66ei

6GQcmm5Mna0wektP9TVjL8SNNXcuugzGZYy

zXdnlaUZFAgMBAAGgADANBgkqhkiG

9w0BAQUFAAOBgQDE/j8HB3c4pozPcIaSvF0

QcdEw+C8/9RqNfzBzKaBUvWTBrH3q

h2eMHh1c9OHDcvlvXlRpWvOVCSGswWn0iET

QgdyJI7Y5VNJmWD94inUBJssmo7mY

gwFtpAJIGGVV7zhHCfuI0AbfLvUcVTvgBfV

dx6nOlAan1UzbIe00U/BUWA==

-----END CERTIFICATE REQUEST-----

Rysunek 2. Generowanie pary kluczy

www.lpmagazine.org

bezpieczeństwo

Kryptograia – serwery poczty

Listing 3. Zmiany w pliku .mc

deine(`CERT_DIR', `/var/secure/

mail')

deine(`confSERVER_CERT', `CERT_DIR/

certs/mailserver_crt.pem')

deine(`confSERVER_KEY', `CERT_DIR/

private/mailserver_key.pem')

deine(`confCLIENT_CERT', `CERT_DIR/

certs/mailserver_crt.pem')

deine(`confCLIENT_KEY', `CERT_DIR/

certs/host.key')

deine(`confCACERT', `CERT_DIR/certs/

cacert.pem')

rze znajduje się główne CA, poniżej po-

średnie CA. Pośrednie CA poświadcza

certyikaty klienckie, samo z kolei jest

poświadczane przez główne CA.

Rysunek 3. Test na poprawność naszej koniguracji

Koniguracja sprzętu testowego:

W niniejszym artykule zajmiemy się zabez-

pieczeniem dwóch najbardziej popularnych

usług w internecie: www oraz pocztą. Całość

testów oparta będzie o następującą konigu-

rację programową – Tabela 1.

potwierdzone przez Kasie – w przeciwnym

przypadku klucz będzie odrzucany jako nie-

wiarygodny. W świecie informatycznym Rom-

kiem jest nasz serwer www lub poczty, Paw-

łem jest użytkownik, który powinien mieć do

tego serwera dostęp, Wojtek jest użytkow-

nikiem który nie powinien mieć tego dostę-

pu, natomiast Kasia jest urzędem certyikacji

(oznaczanym jako CA).

Wyżej opisany (oczywiście w wielkim

uproszczeniu) schemat działania doczekał się

w świecie informatyki własnego standardu:

X.509 . W skrócie opiera się on na następują-

cych założeniach:

rej celem jest potwierdzanie autentyczno-

ści par kluczy (CA),

• CA tworzy certyikat: jest to podpisana

przez CA (za pomocą klucza prywatne-

go) informacja zawierająca między inny-

mi klucz publiczny właściciela certyika-

tu oraz informację o CA podpisującym ten

certyikat.

• standard zakłada hierarchiczna struktu-

rę jednostek będących CA: na samej gó-

Skąd pozyskać CA

Jak już zostało napisane powyżej, po wygene-

rowaniu pary kluczy prywatnego i publiczne-

go będziemy sie ubiegać (za pomocą specjalnej

elektronicznej prośby) o podpis CA tak, aby

• występowanie dwóch kluczy (prywatne-

go i publicznego),

• klucz publiczny służy do szyfrowania

wiadomości bądź do weryikacji podpisu

elektronicznego. Klucz ten jest powszech-

nie dostępny,

• klucz prywatny służy do odszyfrowywa-

nia wiadomości bądź do wykonania pod-

pisu cyfrowego. Klucz ten powinien być

znany tylko właścicielowi,

• występowanie organizacji trzeciej, będą-

cej organizacją powszechnie zaufaną, któ-

Listing 2. Modyikacja pliku koniguracyjnego

dovecota

protocols = pop3s

ssl_disable = no

ssl_cert_ile =/var/secure/mail/

certs/mailserver_crt.pem

ssl_key_ile =/var/secure/mail/

private/mailserver_key.pem

Rysunek 4. Koniguracja klienta poczty Windows Mail

wrzesień 2007

bezpieczeństwo

Kryptograia – serwery poczty

frowanym. Sposób ten omówimy w ostatniej

części przy okazji konigurowania bezpieczne-

go serwera www.

Rysunek 5 Koniguracja klienta poczty Thunderbird – serwer poczty przychodzącej

Serwer poczty

Zajmijmy się więc zabezpieczeniem naszej

poczty. Zaczniemy od zamiany protokołu pop3

na pop3s , później uruchomimy TLS na serwe-

rze sendmail. W tym miejscu zakładam, iż za-

równo sendmail jak i dovecot są już skonigu-

rowane do działania w kanale nieszyfrowa-

nym. W przeciwnym wypadku zrób to i do-

piero poźniej wróć to lektury niniejszego ar-

tykułu. W tym przykładzie posłużymy sie cer-

tyikatem podpisanym przez CACert. Pierw-

szym krokiem do tego celu będzie oczywiście

założenie konta na stronie http://www.cacert.org

Następnie wybieramy Domeny->Dodaj . W tym

oknie wpisujemy oczywiście domenę, dla któ-

rej będziemy generować certyikaty. Następ-

nie należy wskazać adres mailowy w tej dome-

nie na który przyjdzie mail z linkiem potwier-

dzającym domenę. Nie możemy jednak wpisać

dowolnego użytkownika: wybór ogranicza się

do użytkowników zajętych przez administra-

tora. W szczególności do wyboru mamy: root,

hostmaser, postmaster, webmaster oraz admin . Po

wybraniu odpowiedniego maila system podej-

mie próbę wysłania maila ze specjalnym lin-

kiem. Teraz można kliknąć na Domeny->Pod-

gląd . Powinna się pojawić lista domen (może

ich być więcej) przypisanych do danego konta.

Przykładowy zrzut ekranu wykonany na rze-

czywistym koncie wygląda następująco – Ry-

sunek 1. Na powyższym rysunku widać, trzy

domeny: tylko dwie pierwsze (które zostały

dodane wcześniej) są już zweryikowane. Aby

zweryikować trzecią domenę (dodana przez

nas przed chwilą) należy odebrać maila wysła-

nego w procesie dodawania domeny i kliknąć

na znajdujący się w nim link. Teraz musimy za-

logować się na serwerze poczty i wygenerować

specjalne pliki. Zwróćmy uwagę na poniższy

zrzut ekranu – (Rysunek 2.)

W pierwszej kolejności za pomocą po-

lecenia:

Rysunek 6 Koniguracja klienta poczty Thunderbird – serwer poczty wychodzącej

dysponować pełnowartościowym certyika-

tem. Możemy to zrobić na trzy sposoby:

ziom wiarygodności deiniuje się liczbą punk-

tów – im więcej osób poświadczy twoją toż-

samość, tym więcej punktów masz a co za tym

idzie tym bardziej wiarygodny jesteś. Usługi

takie serwuje między innymi CACert (http://

www.cacert.org) oraz Thawte (http://www.

thawte.com) . W niniejszym artykule posłużymy

się pierwszym z nich w koniguracji serwerów

poczty. Trzeci ze wspomnianych sposobów

opiera się nie tyle na wiarygodności samego

certyikatu, co na fakcie iż on istnieje i dzięki

niemu może się odbyć transmisja kanałem szy-

• zwrócić się do irm świadczących takie

usługi komercyjnie.

• Skorzystać z pomocy urzędów certyika-

cji oferujących certyikat za darmo

• samemu stworzyć własne CA, a następ-

nie podpisywać nim nasze certyikaty.

Parę słów o każdym ze sposobów. Pierwszy

oparty jest o wspomnianej wcześniej hierar-

chicznej strukturze. Instytucja ta pobiera pie-

niądze, w zamian za to ma obowiązek spraw-

dzić tożsamość osoby legitymującej sie danym

certyikatem (tak na prawdę robi to przed jego

wystawieniem). Zadaniem CA jest więc zwe-

ryikowanie właściciela przyszłego certyikatu.

Można więc twierdzić, iż traktując certyikat

użytkownika X za wiarygodny wierzysz nie

jemu a instytucji CA, która za niego poświad-

cza. Odmienne podejście reprezentowane jest

przez urzędy certyikacji opierające swoje

działanie na tzw. Sieci zaufania. Tutaj z kolei

użytkownicy weryikują się wzajemnie. Po-

Rysunek 7 Używamy certyikatu podpisanego przez

niezaufanego dostawcę Thunderbird

Rysunek 8 Używamy certyikatu podpisanego przez

niezaufanego dostawcęWindows Mail

www.lpmagazine.org

bezpieczeństwo

Kryptograia – serwery poczty

Jeśli wszystko wykonaliśmy bez błędu

możemy wybrać opcję Certyikaty Serwerów

->Podgląd , kliknąć na wybraną domenę

i pobrać jej certyikat podpisany przez CA-

Cert zapisując go w pliku mailserver.crt .

Rysunek 9 Zakładka „Ośrodki certyikacji”

Koniguracja dovecota

Przenieśmy najpierw w jedno miejsce nasz

certyfikat oraz klucz prywatny (ten ostat-

ni będziemy musieli dodatkowo zabez-

pieczyć nadając mu prawa 600 oraz zmie-

niając właściciela na tego użytkownika,

z konta którego uruchamiany jest dove-

cot).

W naszym przykładzie założono kata-

log: /var/secure/mail a w nim dwa podkata-

logi: private oraz certs . W koniguracji dove-

cota będą potrzebne dwa pliki: plik kluczy

mailserver.key (któremu zmienimy nazwę

na: mailserver_key.pem ) oraz certyikat mail-

server.crt (któremu zmienimy nazwę na ma-

ilserver_crt.pem ). Każdy z plików przeno-

simy do odpowiedniego podkatalogu w /var/

secure/mail : certyikat do certs , klucze do

private .

Na koniec pozostaje modyikacja pliku

koniguracyjnego dovecota – Listing 2.

Po restarcie doevcota, jeśli wszystko zo-

stało wykonanie poprawnie, polecenie:

# netstat -ta|grep pop3s

powinno dać wynik:

Rysunek 10 Wskazanie magazynu zaufanych głównych urzędów certyikacji

tcp 0 0 *:pop3s

*:*

LISTEN

# openssl genrsa -out

mailserver.key 1024

ne oznaczane jako „Distinguished Name” lub

w skrócie: DN . Bardzo ważne jest, aby w polu

hostname wpisać prawdziwą nazwę hosta. Te-

raz kiedy mamy już wygenerowane obydwa

pliki możemy przystąpić do podpisania na-

szego certyikatu. W tym celu z powrotem lo-

gujemy się na stronę CACert, wybieramy Cer-

tyikaty Serwerów->Nowy i zgodnie z opisem

wklejamy do specjalnego okna zawartość pli-

ku csr . W naszym wypadku będzie on wyglą-

dał następująco – Listing 1.

Koniguracja sendmaila

Załóżmy, że certyikat oraz plik kluczy znaj-

dują się w tym samym miejscu co w przy-

kładzie z koniguracji dovecota. Dodatko-

wo możemy zciągnąć certyikat CA. W przy-

padku CACert znajduje się on pod następu-

jącym adresem: http://www.cacert.org/certs/

root.crt

Po zciągnięciu zapisujemy go w katalogu

/var/secure/mail/certs pod nazwą: cacert.pem.

Następnie należy wprowadzić odpo-

wiednie modyikację w pliku sendmail.mc

oraz na jego podstawie zbudować plik send-

mail.cf Zmiany w pliku .mc pokazuje Lis-

ting 3.

Uwaga – w tym miejscu trzeba ko-

niecznie sprawdzić właściciela i pra-

wa dostępu do pliku klucza prywatnego

(patrz: koniguracja dovecota). Jeśli będą

ustawione zbyt liberalnie, sendmail nie

uruchomi TLS'a !

wygenerowaliśmy klucze. W następnej kolej-

ności, poleceniem:

# openssl req -new -key mailserver.key

-out mailserver.csr

stworzyliśmy plik csr (prośba podpisania cer-

tyikatu). Na tym etapie wprowadzamy da-

Tabela 1. Testowa koniguracja programowa

Serwer A (mail) Serwer B (www) Klient A

Klient B

Linux CentOS 5 (inal)

kernel 2.6.18-8el5.xen

Linux CentOS 5 (inal)

kernel 2.6.18-8el5.xen

Linux Fedora Core 6

irefox-2.0.0.3-1.fc6

Windows Vista Business

openssl-0.9.8b-8.3.el5

dovecot-1.0-1.2.rc15.el5

sendmail-8.13.8-2.el5

openssl-0.9.8b-8.3.el5

httpd-2.2.3-6.el5.cen-

tos.1

Mozilla-1.5.0.10.fc6 IE 7.0

Program pocztowy

Windows Mail (następca

popularnego OE)

wrzesień 2007

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: