Configurable Security Email Proxy

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

KONFIGUROVATELN ´

A PROXY PRO ZABEZPE ˇ

CEN´I

ELEKTRONICK ´

E PO ˇ

STY

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

AUTOR PR ´

ACE

STANISLAV ˇ

ZIDEK

AUTHOR

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

KONFIGUROVATELN ´

A PROXY PRO ZABEZPE ˇ

CEN´I

ELEKTRONICK ´

E PO ˇ

STY

CONFIGURABLE SECURITY EMAIL PROXY

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

AUTOR PR ´

ACE

STANISLAV ˇ

ZIDEK

AUTHOR

VEDOUC´I PR ´

ACE

doc. Ing. DANIEL CVR ˇ

CEK, Ph.D.

SUPERVISOR

Zad´

an´ı

Konfigurovateln´

a proxy pro zabezpeˇ

cen´ı

elektronick´

e poˇ

sty

1. Proved’te anal´yzu souˇcasn´ych implementac´ı syst´em˚u pro zabezpeˇcen´ı elektronick´e poˇsty a identifikujte slab´a m´ısta z hlediska pouˇzitelnosti a bezpeˇcnosti.

2. Seznamte se s pˇredchoz´ımi projekty implementuj´ıc´ımi bezpeˇcnou email proxy a iden-tifikujte oblasti, kter´e nejsou ˇreˇseny.

3. Upravte implementaci existuj´ıc´ı proxy tak, aby bylo moˇzn´e je spolehlivˇe pouˇz´ıvat. 4. Navrhnˇete syst´em pro vzd´alenou konfiguraci proxy, pˇr´ıp. s´ıtˇe tˇechto proxy.

5. Implementujte syst´em pro vzd´alenou konfiguraci proxy.

Kategorie: Bezpeˇcnost

Implementaˇcn´ı jazyk: C, C++

Literatura: Gutmann: Cryptographic Security Architecture, Springer, 2002 Datum zad´an´ı: 1. listopadu 2006

Licenˇ

cn´ı smlouva

Licenˇcn´ı smlouva je uloˇzena v archivu Fakulty informaˇcn´ıch technologi´ı Vysok´eho uˇcen´ı technick´eho v Brnˇe.

Abstrakt

Tato bakal´aˇrsk´a pr´ace se zab´yv´a n´avrhem a implementac´ı v´ıceuˇzivatelsk´eho centr´alnˇe kon-figurovateln´eho syst´emu pro zabepeˇcen´ı komunikace elektronickou poˇstou. Velk´y d˚uraz je kladen na moˇznost vzd´alen´e konfigurace. Popisuje souˇcasnˇe pouˇz´ıvan´e protokoly pro komu-nikaci elektronickou poˇstou a nˇekter´e mechanismy slouˇz´ıc´ı k zabezpeˇcen´ı r˚uzn´ych aspekt˚u t´eto komunikace.

Kl´ıˇcov´

a slova

elektronick´a poˇsta, zabezpeˇcen´ı, vzd´alen´a konfigurace, proxy, SMTP, POP3, IMAP, crypt-lib, XML, S/MIME

Abstract

This bachelor thesis deals with design and implementation of multiuser configurable system capable of securing communication via electronic mail. Emphasis is put especially on remote configuration. It also describes existing protocols used for this communication and some of the mechanisms that can secure this communication from different points of view.

Keywords

electronic mail, security, remote configuration, proxy, SMTP, POP3, IMAP, cryptlib, XML, S/MIME

Citace

Stanislav ˇZidek: Konfigurovateln´a proxy pro zabezpeˇcen´ı elektronick´e poˇsty, bakal´aˇrsk´a pr´ace, Brno, FIT VUT v Brnˇe, 2007

Konfigurovateln´

a proxy pro zabezpeˇcen´ı elektronick´e poˇsty

Prohl´

aˇsen´ı

Prohlaˇsuji, ˇze jsem tuto bakal´aˇrskou pr´aci vypracoval samostatnˇe pod veden´ım pana Daniela Cvrˇcka. Uvedl jsem vˇsechny liter´arn´ı prameny a publikace, ze kter´ych jsem ˇcerpal.

. . . . Stanislav ˇZidek 14. kvˇetna 2007

Podˇekov´

an´ı

R´ad bych podˇekoval m´emu vedouc´ımu, Danielu Cvrˇckovi, za dlouhodobou podporu, trpˇelivost a neoceniteln´e rady poskytnut´e pˇri v´yvoji syst´emu a psan´ı bakal´aˇrsk´e pr´ace. Rovnˇeˇz bych r´ad podˇekoval Jakubovi Kubal´ıkovi, kter´y se do v´yvoje zapojil implementac´ı IMAP serveru a jehoˇz pr´ace mˇela v´yznam i pro zbytek syst´emu.

c

Stanislav ˇZidek, 2007.

Tato pr´ace vznikla jako ˇskoln´ı d´ılo na Vysok´em uˇcen´ı technick´em v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Pr´ace je chr´anˇena autorsk´ym z´akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´avnˇen´ı autorem je nez´akonn´e, s v´yjimkou z´akonem definovan´ych pˇr´ıpad˚u.

Obsah

1 Uvod´ 3

2 Elektronick´a poˇsta 5

2.1 Historie . . . 5

2.2 Princip. . . 5

2.3 Form´at zpr´avy . . . 6

2.4 Pouˇz´ıvan´e protokoly . . . 7

2.4.1 SMTP – Simple Mail Transfer Protocol . . . 7

2.4.2 POP3 – Post Office Protocol (version 3) . . . 9

2.4.3 IMAP – Internet Mail Access Protocol . . . 12

3 Zabezpeˇcen´ı elektronick´e poˇsty 14 3.1 Zabezpeˇcen´ı pˇrihlaˇsov´an´ı k serveru . . . 14

3.1.1 Pˇr´ıkaz AUTH(ENTICATE) . . . 14

3.1.2 Pˇr´ıkaz APOP protokolu POP3 . . . 15

3.2 Zabezpeˇcen´ı cel´eho pr˚ubˇehu komunikace . . . 15

3.2.1 Zabezpeˇcen´ı na ´urovni transportn´ı vrstvy, TLS/SSL . . . 15

3.3 Zabezpeˇcen´ı obsahu emailov´ych zpr´av . . . 16

3.3.1 S/MIME – Secure / Multipurpose Internet Mail Extensions . . . 17

3.3.2 PGP – Pretty Good Privacy . . . 18

4 N´avrh 19 4.1 Celkov´a filosofie . . . 19

4.1.1 V´yhody . . . 19

4.1.2 Nev´yhody . . . 20

4.2 C´ılov´e prostˇred´ı. . . 20

4.3 Rozˇsiˇritelnost a modularita . . . 20

4.4 Bezpeˇcnostn´ı politiky . . . 21

5 Implementace 22 5.1 Pouˇzit´e technologie . . . 22

5.2 Struktura . . . 22

5.2.1 Server . . . 23

5.2.2 Datab´aze nastaven´ı (xmlhandle) . . . 24

5.2.3 Kryptografie (cryptography) . . . 25

5.2.4 Zpracov´an´ı emailu (mailhandle) . . . 26

5.2.5 S´ıt’ov´y podsyst´em (network) . . . 26

5.2.7 Zpracov´an´ı chyb (error) . . . 27

5.3 Vzd´alen´a konfigurace. . . 27

5.3.1 Konfiguraˇcn´ı zpr´ava . . . 27

5.3.2 Pˇr´ıkazy . . . 27

6 Dalˇs´ı v´yvoj 30 6.1 Rozv´ıjen´ı moˇznost´ı zabezpeˇcen´ı . . . 30

6.1.1 Zabezpeˇcen´ı protokolem TLS/SSL . . . 30

6.1.2 Doplnˇen´ı rozˇsiˇruj´ıc´ıch funkc´ı poˇstovn´ıch protokol˚u . . . 30

6.2 Zabezpeˇcen´ı konfiguraˇcn´ıho souboru . . . 31

6.3 Portov´an´ı na vestavˇen´y syst´em . . . 31

6.4 V´ymˇena kl´ıˇc˚u . . . 31

6.5 Zabezpeˇcen´ı komunikce klient – proxy . . . 31

6.6 Automatizace nˇekter´ych ˇcinnost´ı . . . 32

6.7 Grafick´a konfiguraˇcn´ı aplikace . . . 32

Kapitola 1

´

Uvod

Elektronick´a poˇsta patˇr´ı mezi nejstarˇs´ı a nejvyuˇz´ıvanˇejˇs´ı sluˇzby internetu. Pr´avˇe kv˚uli sv´e ”dlouhovˇekosti“ s sebou pˇrin´aˇs´ı nˇekter´e neduhy, jeˇz si tehdy prvn´ı uˇzivatel´e a n´avrh´aˇri protokol˚u nedok´azali ani pˇredstavit.

S nar˚ustaj´ıc´ım v´yznamem a objemem komunikace elektronickou poˇstou vznikla a st´ale existuje potˇreba zabezpeˇcit takto pˇren´aˇsen´a data. K tomuto ´uˇcelem existuje mnoho r˚uzn´ych pˇr´ıstup˚u, kter´e umoˇzˇnuj´ı jednotliv´ym uˇzivatel˚um zabezpeˇcit komunikaci mezi sebou navz´ a-jem (pˇr´ıpadnˇe dalˇs´ı aspekty komunikace, napˇr´ıklad vyzrazen´ı hesla).

Tato bakal´aˇrsk´a pr´aci si klade za ´ukol vytvoˇrit z´aklad syt´emu pro zabezpeˇcen´ı ko-munikace pomoc´ı elektronick´e poˇsty s moˇznost´ı vzd´alen´e konfigurace staraj´ıc´ı se o toto zabezpeˇcen´ı. Jednou z nejd˚uleˇzitˇejˇs´ıch funkc´ı je moˇznost centr´aln´ı definice bezpeˇcnostn´ıch politik pro neomezen´y poˇcet uˇzivatel˚u, coˇz lze vyuˇz´ıt napˇr´ıklad ve velk´e firmˇe, kde s mi-nim´aln´ım aktivn´ım zapojen´ım vˇetˇsiny zamˇestnanc˚u kompletnˇe obstar´ame zabezpeˇcen´ı ko-munikace s okol´ım. Centr´aln´ı definice je vhodn´a zejm´ena z toho d˚uvodu, ˇze odst´ın´ı uˇzivatele od vˇec´ı, kter´ym nerozum´ı, a syst´em od chyb z toho vypl´yvaj´ıc´ıch – to pˇrin´aˇs´ı obrovskou v´yhodu v pˇrenesen´ı t´emˇeˇr veˇsker´e zodpovˇednosti z laik˚u (uˇzivatel˚u) na odborn´ıky (admi-nistr´atory). Uˇzivatel se prostˇe o zabezpeˇcen´ı nemus´ı v˚ubec starat, staˇc´ı, ˇze administr´ator spr´avnˇe nastav´ı bezpeˇcnostn´ı politiky pro komunikaci. Jednou z nejd˚uleˇzitˇejˇsich funkc´ı aplikace je pr´avˇe tato moˇznost vynutit urˇcitou bezpeˇcnostn´ı politiku pro dan´y c´ıl emai-lov´e komunikace a t´ım eliminovat potenci´aln´ı z´amˇern´e i ne´umysln´e chyby uˇzivatel˚u pˇri za-bezpeˇcov´an´ı emailov´ych zpr´av, kter´e mohou nastat pˇri pouˇzit´ı jin´ych zp˚usob˚u zabezpeˇcen´ı. Druh´a kapitola pr´ace se zab´yv´a elektronickou poˇstou, jej´ı histori´ı, principem fungov´an´ı a popisem pouˇz´ıvan´ach poˇstovn´ıch protokol˚u.

Kapitola tˇri zkoum´a z r˚uzn´ych pohled˚u existuj´ıc´ı mechanismy urˇcen´e k zabezpeˇcen´ı elektronick´e poˇsty.

Ve ˇctvrt´e kapitole se dost´av´ame k n´avrhu vytv´aˇren´eho syst´emu, jsou zde zhodnoceny v´yhody a nev´yhody pouˇzit´eho pˇr´ıstupu a obecnˇe pops´any d˚uleˇzit´e ˇc´asti n´avrhu syst´emu.

Samotn´a implementace je konkr´etnˇe pops´ana v kapitole p´at´e, jeˇz se podrobnˇeji zab´yv´a jednotliv´ymi podsyst´emy a tak´e vzd´alenou konfigurac´ı.

ˇ

Sest´a kapitola ukazuje smˇery, kter´ymi se m˚uˇze ub´ırat budouc´ı v´yvoj.

Pr´ace navazuje na semestr´aln´ı projekt, jehoˇz c´ılem byla anal´yza problematiky souvisej´ıc´ı s implementac´ı proxy v´ysledn´eho proxy serveru.

Ve sv´e pr´aci jsem tak´e ˇc´asteˇcnˇe vyuˇzil poznatk˚u z diplomov´e pr´ace Dalimila Hra-bovsk´ehoGrafick´e rozhran´ı pro konfiguraci bezpeˇcn´e poˇsty. Bohuˇzel syst´em zabezpeˇcen´ı v n´ı vytvoˇren´y mˇel natolik chud´e moˇznosti definice bezpeˇcnostn´ıch politik, aˇz byl nepouˇziteln´y. [3]

Pozn´amka Souˇc´ast´ı vytvoˇren´eho syst´emu je i proxy server pro protokol IMAP. Ten nen´ı m´ym d´ılem, proto se mu a teorii s n´ım souvisej´ıc´ı budu vˇenovat jen okrajovˇe. Za tˇeˇziˇstˇe pr´ace povaˇzuji zbytek syst´emu – SMTP proxy, POP3 proxy, konfiguraˇcn´ı server a ostatn´ı moduly.

Kapitola 2

Elektronick´

a poˇ

sta

Elektronick´a poˇsta patˇr´ı v souˇcasn´e dobˇe spolu se sluˇzbou WWW (World Wide Web) k nejvyuˇz´ıvanˇejˇs´ım sluˇzb´am internetu. M´a dlouhou historii sahaj´ıc´ı aˇz do poloviny ˇsedes´at´ych let dvac´at´eho stolet´ı.

2.1

Historie

Vznik elektronick´a poˇsty je pˇrirozenˇe spjat s v´yvojem s´ıt’ov´ych moˇznost´ı objevuj´ıc´ıch se bˇehem v´yvoje internetu. Moˇznost v´ymˇeny zpr´av existovala jiˇz od ran´ych poˇc´atk˚u poˇc´ıtaˇc˚u schopn´ych vˇenovat v´ypoˇcetn´ı ˇcas v´ıce uˇzivatel˚um. Email tak, jak jej zn´ame dnes, byl vyvinut pro ARPANET kr´atce po jeho vzniku a rozrostl se do netuˇsen´ych rozmˇer˚u.

V obdob´ı prvn´ıch poˇc´ıtaˇc˚u schopn´ych spouˇstˇet v´ıce proces˚u z´aroveˇn vznikaly prvn´ı programy schopn´e v´ymˇeny textov´ych zpr´av, a dokonce i chatu v re´aln´em ˇcase. Takov´ato komunikace byla ale omezena na uˇzivatele jednoho poˇc´ıtaˇce.

Na poˇc´atku sedmdes´at´ych let dvac´at´eho stolet´ı vznikla prvn´ı aplikace k pˇrenosu elek-tronick´a poˇsty po ARPANETU. Rovnˇeˇz je do tohoto obdob´ı zasazeno vytvoˇren´ı form´atu emailov´e adresy v podobn´e formˇe, v jak´e ji zn´ame dnes (user@host).

V roce 1972 byly do protokolu FTP1 pˇrid´any pˇr´ıkazy urˇcen´e k pˇrenosu email˚u (MAIL a MLFL). Spoˇc´ıvaly v kop´ırov´an´ı soubor˚u pˇres s´ıt’. Tento model se udrˇzel aˇz do poˇc´atku osmdes´at´ych let, kdy vznikl protokol SMTP (viz ˇc´ast 2.4.1).

Sjednocen´ı form´atu emailov´ych zpr´av pˇrineslo RFC 733 (rok 1977) pozdˇeji nahrazen´e RFC 822 (rok 1982). [1]

2.2

Princip

Celou sluˇzbu elektronick´e poˇsty si m˚uˇzeme pˇredstavit jako paralelu k obyˇcenjn´e

”pap´ırov´e“ poˇstˇe. Princip je velmi podobn´y, pouze se liˇs´ı pouˇz´ıvan´e n´astroje a prostˇredky. Stejnˇe jako pˇri vyuˇz´ıv´an´ı norm´aln´ı poˇsty obecnˇe chceme nˇekomu sdˇelit nˇejakou informaci.

Prvn´ım krokem je vytvoˇren´ı zpr´avy. Ovˇsem m´ısto pera, pap´ıru a ob´alky pouˇz´ıjeme poˇc´ıtaˇc a na nˇem pˇr´ısluˇsn´y software, kter´y se naz´yv´a emailov´y klient (nˇekdy ve zkratce MUA – Mail User Agent).

Potom mus´ıme

”zaj´ıt s dopisem na poˇstu“. Udˇel´ame to tak, ˇze zkontaktujeme vhodn´y server pro odes´ıl´an´ı elektronick´e poˇsty (ve zkratce MTA – message transfer agent). T´ım, ˇze

1

poskytneme informaci od koho zpr´ava je a komu je urˇcena, m˚uˇze b´yt pˇri pˇrenosu vytvoˇrena jak´asi ob´alka, ve kter´e je uveden odesilatel a pˇr´ıjemce.

Server supluje funkci poˇsty, dok´aˇze zpr´avu pˇredat aˇz do c´ılov´e schr´anky. Pˇri tomto pr˚uchodu elektronick´ymi kan´aly m˚uˇze zpr´ava proj´ıt pˇres nˇekolik MTA, aˇz je nakonec uloˇzena na poˇzadovan´e m´ısto.

Odtud si

”dojdeme do schr´anky“ a pouˇzijeme k tomu n´am zn´am´y emailov´y klient. Ten um´ı zpr´avu vyzvednout a posl´eze n´am ji pˇredloˇz´ı.

2.3

Form´

at zpr´

avy

Zpr´ava (email) je z´akladn´ı jednotkou komunikace elektronickou poˇstou. Jako cokoliv urˇcen´eho k pˇrenosu mezi poˇc´ıtaˇci m´a pˇresnˇe vymezenou strukturu, kterou mus´ı dodrˇzet, aby ji bylo moˇzno bez probl´emu pˇred´avat elektronick´ymi komunikaˇcn´ımi kan´aly. Form´at je specifikov´an v RFC 2822 [7].

Zpr´ava m˚uˇze obsahovat pouze znaky doln´ı poloviny2znakov´e sady US-ASCII (konkr´etnˇe z rozsahu 1–127). Skl´ad´a se ze dvou ˇc´ast´ı, hlaviˇcky a tˇela. Tyto ˇc´asti jsou pˇri pˇrenosu internetem oddˇeleny pr´azdn´ym ˇr´adkem (podˇretˇezcem CR3 LF4 CR LF).

Hlaviˇcka v sobˇe nese r˚uzn´e informace o zpr´avˇe. Skl´ad´a se z libovoln´eho poˇctu pol´ı, kter´e jsou oddˇeleny konci ˇr´adk˚u (CR LF). Tyto pole se skl´adaj´ı z n´azvu a obsahu, jeˇz jsou oddˇelen´e dvojteˇckou.

Omezen´ı pro obsah hlaviˇcky:

1. Pole nesm´ı obsahovat netisknuteln´e znaky5_. 2. N´azev pole nesm´ı obsahovat znak dvojteˇcka.

3. D´elka ˇr´adku6 nesm´ı pˇres´ahnout 998 znak˚u (doporuˇcuje se nepˇres´ahnout 78 znak˚u) bez CR LF.

Pole specifikuj´ıc´ı pˇredmˇet zpr´avy m˚uˇze vypadat napˇr´ıklad takto: Subject: This is testing email

Hlaviˇcka mus´ı povinnˇe obsahovat poleDatea From.

Omezen´ı pro obsah tˇela:

1. Znaky CR a LF se nesm´ı vyskytnout oddˇelenˇe, pouze spolu za sebou v poˇrad´ı CR LF.

2. D´elka ˇr´adku nesm´ı pˇres´ahnout 998 znak˚u (doporuˇcuje se nepˇres´ahnout 78 znak˚u) bez CR LF.

Velmi kr´atk´a zpr´ava schopna pˇrenosu elektronickou poˇstou pak m˚uˇze vypadat napˇr´ıkald takto:

2_{Toto lze odstranit pouˇzit´ım form´atu MIME – Multipurpose Internet Mail Extensions??.} 3

Carriage return (n´avrat voz´ıku) je znak sady US-ASCII s ordin´aln´ı hodnotou 13.

4_{Line feed (nov´y ˇr´adek) je znak sady US-ASCII s ordin´aln´ı hodnotou 10.} 5

Tisknuteln´e znaky sady US-ASCII jsou od znaku s ordin´aln´ı hodnotou 33 do znaku s hodnotou 126 vˇcetnˇe.

6_ˇ

Date: Wed, 02 May 2007 23:50:46 +0200 (CEST) From: Blacklanner <[email protected]>

Ahoj Stando, posilam Ti seznam, ktery jsi po mne chtel. Pavel

2.4

Pouˇ

z´ıvan´

e protokoly

Pˇri pˇrenosu elektronick´e poˇsty internetem doch´az´ı k pˇred´av´an´ı zpr´av mezi jednotliv´ymi poˇc´ıtaˇci. Stejnˇe tak vyb´ır´an´ı schr´anky na serveru je z´aleˇzitost komunikace poˇc´ıtaˇcov´ych program˚u. Proto mus´ı existovat protokoly, kter´e tuto komunikaci pˇresnˇe specifikuj´ı. V t´eto kapitole pop´ıˇsu dnes pouˇz´ıvan´e protokoly urˇcen´e pro vyuˇzit´ı sluˇzby elektronick´e poˇsty.

Pro odes´ıl´an´ı (komunikace MUA s MTA) a pˇrepos´ıl´an´ı (komunikace MTA s jin´ym MTA) se v dneˇsn´ı dobˇe takˇrka v´yhradnˇe pouˇz´ıv´a protokol SMTP nebo jeho rozˇs´ıˇren´ı (ESMTP). K vyb´ır´an´ı poˇstovn´ı schr´anky slouˇz´ı protokoly POP3 (zat´ım st´ale jeˇstˇe v´ıce pouˇz´ıvan´y) a novˇejˇs´ı protokol IMAP.

2.4.1 SMTP – Simple Mail Transfer Protocol

´

Ukolem tohoto protokolu je spolehlivˇe a efektivnˇe pˇren´aˇset emailov´e zpr´avy. Zajiˇst’uje prak-ticky veˇskerou komunikaci elektronickou poˇstou kromˇe posledn´ıho kroku – vyzvednut´ı zpr´av ze schr´anky.

Historie

Definici protokolu napsal v roce 1982 Jonathan Postel jako RFC 821. Uˇz pˇredt´ım sice prodˇelal urˇcit´y v´yvoj, ale toto byl velk´y mezn´ık v jeho historii. Protokol vznikl jako n´ahrada protokolu MTP (Mail Transfer Protocol), coˇz byl do t´e doby pouˇz´ıvan´y protokol pro pˇrenos elektronick´e poˇsty zaloˇzen´y na FTP (File Transfer Protocol). SMTP byl mnohem ele-gantnˇejˇs´ı, navrˇzen´y jen pro pˇrenos elektronick´e poˇsty – d´ıky tomu mohl obsahovat potˇrebn´e specifick´e vlastnosti, kter´e MTP z podstaty nepodporoval a podporovat nemohl.

Bˇehem osmdes´at´ych let dvac´at´eho stolet´ı se st´aval st´ale obl´ıbenˇejˇs´ım a pouˇz´ıvanˇejˇs´ım, nicm´enˇe neproch´azel ˇz´adn´ym dalˇs´ım v´yvojem.

To se zmˇenilo v ´unoru 1993, kdy bylo vyd´ano RFC 1425 – SMTP Service Extensions. V nˇem byl definov´an zp˚usob pˇrid´av´an´ı rozˇs´ıˇren´ı, aniˇz by t´ım utrpˇela zpˇetn´a kompatibi-lita. SMTP s t´ımto rozˇs´ıˇren´ım se nˇekdy naz´yv´a ESMTP (Extended/Enhanced Simple Mail Transfer Protocol – Rozˇs´ıˇren´y SMTP).

Souˇcasn´y standard je definov´an v RFC 2821 (vyd´ano v dubnu 2001). Toto RFC sdruˇzuje z´aklad protokolu popsan´y v RFC 821 a veˇsker´a do t´e doby definov´ana rozˇs´ıˇren´ı (do t´e doby v RFC 1869). [5]

Popis komunikace

Komunikace mezi klientem a serverem prob´ıh´a jako v´ymˇena ˇr´adk˚u s pˇr´ıkazy. Jednotliv´e ˇr´adky jsou ukonˇceny znaky CR LF a jejich d´elka nesm´ı pˇres´ahnout 998 znak˚u.

Bˇehem komunikace se mˇen´ı mnoˇzina pouˇziteln´ych pˇr´ıkaz˚u. Typick´y pr˚ubˇeh komunikace vypad´a asi takto:

1. EHLO – klient se identifikuje, zjist´ı podporovan´a rozˇs´ıˇren´ı 2. MAIL – zaˇcne pˇrenos emailu

3. RCPT – identifikuje pˇr´ıjemce zpr´avy 4. DATA – poˇsle obsah emailu

5. QUIT – vyˇz´ad´a ukonˇcen´ı spojen´ı

Pˇri odesl´ıl´an´ı v´ıce zpr´av se v´ıcekr´at opakuje smyˇckaMAIL→RCPT→DATA. Pokud m´a email v´ıce pˇr´ıjemc˚u, je v´ıcekr´at zad´an pˇr´ıkaz RCPT.

Jednoduch´y pˇr´ıklad odesl´an´ı emailov´e zpr´avy je naznaˇcen v tabulce2.1.

S: 220 Welcome to SMTP server C: HELO pcbuslab9.fit.vutbr.cz S: 250 Hello pcbuslab9.fit.vutbr.cz C: MAIL FROM:<[email protected]> S: 250 Sender OK C: RCPT TO:<[email protected]> S: 250 Recipient OK C: DATA

S: 354 Send mail data, end with CRLF.CRLF C: <Samotn´y email>

C: .

S: 250 Mail OK C: QUIT

S: 250 SMTP server signing off

Tabulka 2.1: Pˇr´ıklad komunikace pomoc´ı protokolu SMTP

Z´akladn´ı mnoˇzina pˇr´ıkaz˚u

Minim´aln´ı mnoˇzinu pˇr´ıkaz˚u tvoˇr´ı pˇr´ıkazy, kter´e mus´ı podporovat kaˇzd´y spr´avnˇe naimple-mentovan´y SMTP server, aby byl kompatibiln´ı s jak´ymkoliv spr´avnˇe naimplementovan´ym klientem.

Tyto pˇr´ıkazy jsou pˇrehlednˇe pops´any v tabulce2.2. Pˇr´ıkaz V´yznam

EHLO zaˇcne komunikaci, identifikuje klienta, signalizuje podporu ESMTP na stranˇe klienta

HELO zaˇcne komunikaci, identifikuje klienta MAIL zapoˇcne doruˇcov´an´ı emailu

RCPT urˇc´ı pˇr´ıjemce emailu

DATA odstartuje pos´ıl´an´ı obsahu emailu RSET zruˇs´ı prov´adˇen´y pˇrenos emailu NOOP nedˇel´a nic

QUIT ukonˇc´ı spojen´ı

VRFY vyˇz´ad´a potvrzen´ı, ˇze jeho argument identifikuje uˇzivatele ˇci poˇstovn´ı schr´anku Tabulka 2.2: Minim´aln´ı mnoˇzina pˇr´ıkaz˚u protokolu SMTP

Rozˇs´ıˇren´ı protokolu

P˚uvodn´ı protokol SMTP byl schopen poskytnout pouze omezen´e mnoˇzstv´ı pˇresnˇe defi-novan´ych sluˇzeb a funkc´ı. Elektronick´a poˇsta a t´ım p´adem i zp˚usoby a moˇznosti jej´ıho doruˇcov´an´ı se vˇsak neust´ale vyv´ıj´ı a mˇen´ı, a proto vznikla potˇreba vytvoˇrit obecn´y mecha-nismus, kter´ym by se dal protokol rozˇsiˇrovat o nov´e funkce bez ztr´aty funkˇcnosti starˇs´ıch klientsk´ych program˚u.

ˇ

Reˇsen´ı tohoto probl´emu pˇrineslo RFC 1425 a jeho n´asledn´ıci (1651, 1869, 28217, kter´e definuj´ı:

• pˇr´ıkaz EHLO, n´ahradu dˇr´ıvˇejˇs´ıho HELO, • registry rozˇs´ıˇren´ı protokolu SMTP • dalˇs´ı parametry pˇr´ıkaz˚u MAILa RCPT

• voliteln´e n´ahrady pˇr´ıkaz˚u SMTP, napˇr´ıklad DATA pro pˇrenos znak˚u jin´ych neˇz US-ASCII

Takto

”vylepˇsen´y“ protkol SMTP se naz´yv´a ESMTP (Extended/Enhanced Simple Mail Transfer Protocol – Rozˇs´ıˇren´y SMTP).

Je navrˇzen tak, aby byl zpˇetnˇe kompatibiln´ı s p˚uvodn´ım, nerozˇs´ıˇren´ym SMTP. Zav´ad´ı nov´y pˇr´ıkaz,EHLO(tj. Extended HELO), j´ımˇz klient oznamuje, ˇze by r´ad komunikoval pr´avˇe t´ımto rozˇs´ıˇren´ym protokolem. Pokud ESMTP podporuje i server, po tomto pozdravu zaˇsle v´ıceˇr´adkovou odpovˇed’, ve kter´e sdˇel´ı, kter´e sluˇzby podporuje. Pokud server ESMTP nezn´a, potom nerozpozn´a ani pˇr´ıkaz EHLO, vyd´a hl´aˇsen´ı o chybˇe a klient m˚uˇze zkusit obyˇcejn´y pozdravHELO. Pro pˇr´ıklad viz tabulky 2.3a 2.4.

S: 220 Welcome to ESMTP server C: EHLO pcbuslab9.fit.vutbr.cz S: 250-Hello pcbuslab9.fit.vutbr.cz S: 250-8BITMIME

S: 250-SIZE

S: 250-AUTH CRAM-MD5 DIGEST-MD5 S: 250-DSN

S: 250 HELP

C: <klient m˚uˇze v dalˇs´ı komunikaci vyuˇz´ıt deklarovan´e rozˇs´ıˇren´ı (8BITMIME, SIZE, AUTH, DSN a HELP)>

Tabulka 2.3: Pˇr´ıklad ´uspˇeˇsn´eho pozdravu EHLO

Server ozn´am´ı, kter´a rozˇs´ıˇren´ı podporuje, pomoc´ı v´ıceˇr´adkov´e odpovˇedi na pˇr´ıkazEHLO (viz tabulku2.3). Kaˇzd´y ˇr´adek t´eto odpovˇedi kromˇe prvn´ıho obsahuje n´azevjednoho pod-porovan´eho rozˇs´ıˇren´ı s pˇr´ıpadn´ymi parametry.

Pˇrehled nˇekter´ych zn´am´ych rozˇs´ıˇren´ı je v tabulce 2.5[8].

2.4.2 POP3 – Post Office Protocol (version 3)

Protokol POP3 je v souˇcasn´e dobˇe nejrozˇs´ıˇrenˇejˇs´ı protokol slouˇz´ıc´ı k pˇrenosu zpr´av z poˇstovn´ı schr´anky na vzd´alen´em serveru do poˇc´ıtaˇce klienta. Pouˇz´ıv´a se k offline pˇr´ıstupu

7

S: 220 Welcome to SMTP server C: EHLO pcbuslab9.fit.vutbr.cz S: 500 Error, unrecognized command C: HELO pcbuslab9.fit.vutbr.cz S: 250 Hello pcbuslab9.fit.vutbr.cz

C: <komunikace pokraˇcuje jako obyˇcejnˇe protokolem SMTP>

Tabulka 2.4: Pˇr´ıklad ne´uspˇeˇsn´eho pozdravu EHLO a n´asledn´y pozdrav obyˇcejn´y 8BITMIME Pˇrenos osmibitov´ych znak˚u RFC 1652 ATRN Pˇrepos´ıl´an´ı emailov´ych zpr´av na poˇz´ad´an´ı RFC 2645

AUTH Autentizace RFC 2554

CHUNKING Pˇrenos velk´ych a bin´arn´ıch MIME zpr´av RFC 3030

DSN Ozn´amen´ı o stavu doruˇcen´ı RFC 1891

ETRN Razen´ı zpr´ˇ av do front RFC 1985

HELP Poskytov´an´ı pomocn´ych informac´ı RFC 821 PIPELINING Zˇretˇezen´ı pˇr´ıkaz˚u RFC 2920

SIZE Deklarace velikosti zpr´avy RFC 1870

STARTTLS Bezpeˇcnost na ´urovni transportn´ı vrstvy RFC 3207 Tabulka 2.5: Seznam nejzn´amˇejˇs´ıch rozˇs´ıˇren´ı SMTP. [8]

ke zpr´av´am, kter´y je vhodn´y pˇredevˇs´ım proto, ˇze kaˇzd´y pˇr´ıjemce poˇsty nemus´ı na sv´e pra-covn´ı stanici nech´avat bˇeˇzet proces poskytuj´ıc´ı sluˇzby SMTP serveru s funkc´ı lok´aln´ıho doruˇcov´an´ı (ukl´ad´an´ı) zpr´av.

Historie

Offline pˇr´ıstup k email˚um zaˇc´ın´a sv˚uj v´yvoj na zaˇc´atku osmdes´at´ych let dvac´at´eho sto-let´ı. V´yvojaˇri si uˇz tehdy uvˇedomili v´yhody stahov´an´ı poˇsty do lok´aln´ıho poˇc´ıtaˇce (oproti pˇr´ıstupu na serveru pomoc´ı telnetu nebo NFS8) a vytvoˇrili specifikaci protokolu POP (Post Office Protocol) v RFC 981 (rok 1984). D˚uraz byl kladen pˇredevˇs´ım na jednoduchost. Cel´e RFC 981 je 5 str´anek dlouh´e a v podstatˇe ˇr´ık´a to, ˇze uˇzivatel poˇsle sv´e jm´eno, heslo a n´aslednˇe mu server odeˇslecel´yobsah jeho schr´anky.

Tento pˇr´ıstup mˇel ovˇsem onu z´asadn´ı nev´yhodu neust´al´eho stahov´an´ı veˇsker´eho obsahu, a proto v roce 1985 byl v RFC 987 definov´an protokol POP2 (Post Office Protocol – Version 2), kter´y pˇrinesl moˇznost stahovat pouze konkr´etn´ı zpr´avu.

Tyto dva protokoly byly pouˇz´ıv´any bˇehem osmdes´at´ych let, avˇsak ne pˇr´ıliˇs ˇsiroce. Of-fline pˇr´ıstup k email˚um nebyl jeˇstˇe tehdy tak nutn´y, internet pouˇz´ıval zanedbateln´y poˇcet uˇzivatel˚u.

V roce 1988 vzniklo RFC 1081 definuj´ıc´ı protokol POP3 (Post Office Protocol – Version 3). V t´eto dobˇe doch´azelo k velk´emu n´ar˚ustu v´yznamu osobn´ıch poˇc´ıtaˇc˚u (PC – Personal Computer). POP3 zdokonalil a rozˇs´ıˇril moˇznosti POP2 a poskytl osobn´ım poˇc´ıtaˇc˚um i jin´ym klient˚um dobr´y zp˚usob pˇr´ısupu a stahov´an´ı emailov´ych zpr´av.

V´yvoj pokraˇcoval d´ale v devades´at´ych letech, co p´ar let bylo vyd´ano nov´e RFC (po-stupnˇe to byly 1225, 1460, 1725 a 1939). I pˇres tento pomˇernˇe velk´y poˇcet reviz´ı se pro-tokol samotn´y od roku 1988 v podstatˇe nezmˇenil a od roku 1996, kdy byl vyd´an posledn´ı

8

jmenovan´y dokument, RFC 1939, nebyl mˇenˇen v˚ubec. Vznikaly pouze definice voliteln´ych rozˇs´ıˇren´ı, jako napˇr´ıklad alternativn´ı autentizaˇcn´ı mechanismus.

Cel´y v´yvoj se nesl v duchu myˇslenky jednoduchosti, pˇr´ımoˇcarosti a rychlosti. [4] Popis komunikace

POP3 je pˇr´ımoˇcar´y tˇr´ıstavov´y protokol. Obsahuje relativnˇe mal´y poˇcet pˇr´ıkaz˚u urˇcen´ych k jednoduch´ym ´ukon˚um.

Komunikace se m˚uˇze nach´azet ve tˇrech stavech: autorizaˇcn´ım (authorization state), transakˇcn´ım (transaction state) a aktualizaˇcn´ım (update state). Postupnˇe si tyto stavy rozebereme.

Authorization state V tomto stavu je po klientovi poˇzadov´ano, aby se autentizoval. K tomu slouˇz´ı kombinace pˇr´ıkaz˚u USER a PASS nebo pˇr´ıkaz APOP. Server mus´ı podporovat alespoˇn jeden z tˇechto zp˚usob˚u. Nav´ıc m˚uˇze b´yt v tomto stavu vyd´an jen pˇr´ıkaz QUIT k ukonˇcen´ı komunikace. Pokud se klient ´uspˇeˇsnˇe autentizuje, sezen´ı pˇrech´az´ı do transakˇcn´ıho stavu.

Transaction state V tuto chv´ıli m´a klient otevˇrenu svou schr´anku s exkluzivn´ım pˇr´ıstupem. Nejd˚uleˇzitˇejˇs´ı pˇr´ıkazy v tomto stavu jsou bezesporuLIST, vracej´ıc´ı seznam zpr´av a pˇr´ıpadnˇe jejich velikosti, a RETR, slouˇz´ıc´ı ke staˇzen´ı urˇcen´e zpr´avy. Rovnˇeˇz lze pouˇz´ıt (mimo jin´e) pˇr´ıkazDELE(oznaˇc´ı zpr´avu jako urˇcenou ke smaz´an´ı) ˇciRSET(zruˇs´ı oznaˇcen´ı zpr´av urˇcen´ych ke smaz´an´ı). Tento stav se ukonˇc´ı pˇr´ıkazemQUIT a sezen´ı pˇrejde do aktualizaˇcn´ıho stavu. Update state V tomto stavu jsou vˇsechny zpr´avy urˇcen´e ke smaz´an´ı skuteˇcnˇe smaz´any. T´ım je zajiˇstˇeno, ˇze pokud komunikace neskonˇc´ı korektnˇe (posl´an´ım QUIT), ˇz´adn´e emaily odstranˇeny nebudou.

Jednoduch´y pˇr´ıklad staˇzen´ı zpr´avy ze serveru je uveden v tabulce2.6.

Z´akladn´ı mnoˇzina pˇr´ıkaz˚u

V tabulce2.7jsou shrnuty z´akladn´ı pˇr´ıkazy protokolu POP3.

Rozˇs´ıˇren´ı protokolu

Protokol POP3 obsahuje pˇr´ıkazy, kter´e nejsou naprosto nutn´e ke komunikaci, ale mohou ji usnadnit, popˇr´ıpadˇe pomoci zabezpeˇcit. Viz tabulku ??.

Jako nevyhnuteln´y krok ve v´yvoji protokolu (stejnˇe jako u SMTP) pˇriˇsla moˇznost defi-novat r˚uzn´a rozˇs´ıˇren´ı. V protokolu POP3 je toto zajiˇstˇeno pomoc´ı pˇr´ıkazuCAPA a registro-van´eho seznamu rozˇs´ıˇren´ı.

Pˇr´ıkazCAPA Tento pˇr´ıkaz je definov´an v RFC 2449 (POP3 Extension Mechanism). M˚uˇze b´yt posl´an v autentizaˇcn´ım i transakˇcn´ım stavu. Jako odpovˇed’ server poˇsle seznam

” schop-nost´ı“ (capabilities), kter´ymi disponuje. Klient pot´e m˚uˇze tyto vyuˇz´ıvat.

Z´akladn´ı mnoˇzina tˇechto capabilities je definov´ana pˇr´ımo ve stejn´em RFC. Jejich pˇrehled se nach´az´ı v tabulce 2.9.

Definice dalˇs´ıch rozˇs´ıˇren´ı nen´ı doporuˇcov´ana z d˚uvodu zachov´an´ı jednoduchosti proto-kolu.

C: <nav´az´an´ı spojen´ı> S: +OK POP3 server ready C: USER john

S: +OK Enter your password please C: PASS heslo

S: +OK You can work now C: STAT

S: +OK 1 130 C: LIST

S: +OK 1 message (130 octets) S: 1 130 S: . C: RETR 1 S: +OK 130 octets S: <Samotn´y email> S: . C: QUIT

S: +OK POP3 server signing off C: <odpojen´ı>

Tabulka 2.6: Pˇr´ıklad komunikace pomoc´ı protokolu POP3

2.4.3 IMAP – Internet Mail Access Protocol

Tento protokol m´a stejn´y ´uˇcel jako pˇredchoz´ı. Velk´y rozd´ıl ovˇsem je v celkov´em pojet´ı. Zat´ımco POP3 je po celou dobu sv´eho v´yvoje smˇerov´an k pokud moˇzno co nejvˇetˇs´ı jednoduchosti, nˇekdy na ´ukor moˇznosti vyuˇzit´ı pokroˇcil´ych funkc´ı, IMAP se vydal pr´avˇe druhou cestou.

Pˇrin´aˇs´ı mnoho v´yhod, jmenujme za vˇsechny jen hierarchickou strukturu poˇstovn´ı schr´anky, moˇznost pracovat s poˇstou pˇr´ımo na serveru (netˇreba ji stahovat do lok´aln´ıho poˇc´ıtaˇce) nebo moˇznost stahovat jen vybran´e ˇc´asti zpr´avy.

Pˇr´ıkaz V´yznam Stav USER name zad´a uˇzivatelsk´e jm´eno autorizaˇcn´ı PASS string zad´a uˇzivatelovo heslo autorizaˇcn´ı STAT vr´at´ı celkov´y poˇcet a celkovou velikost zpr´av transakˇcn´ı LIST [msg] vyp´ıˇse velikost zadan´e zpr´avy nebo postupnˇe vˇsech zpr´av transakˇcn´ı RETR msg poˇsle obsah zpr´avy s ˇc´ıslemmsg transakˇcn´ı DELE msg oznaˇc´ı zpr´avu s ˇc´ıslemmsgjako urˇcenou ke smaz´an´ı transakˇcn´ı

NOOP nedˇel´a nic transakˇcn´ı

RSET zruˇs´ı oznaˇcen´ı zpr´av urˇcen´ych ke smaz´an´ı transakˇcn´ı

QUIT ukonˇc´ı spojen´ı kter´ykoliv

Tabulka 2.7: Minim´aln´ı mnoˇzina pˇr´ıkaz˚u protokolu POP3

APOP zabezpeˇcen´e pˇrihlaˇsov´an´ı, viz 3.1.2 autentizaˇcn´ı TOP msg n poˇsle hlaviˇcku anˇr´adk˚u tˇela zpr´avy s ˇc´ıslem msg transakˇcn´ı UIDL [msg] vr´at´ı unik´atn´ı identifik´ator zpr´avy s ˇc´ıslemmsgnebo vˇsech

zpr´av

transakˇcn´ı

Tabulka 2.8: Dalˇs´ı pˇr´ıkazy protokolu POP3

CAPAˇst´ıtek Pˇridan´e pˇr´ıkazy V´yznam

TOP TOP podpora pˇr´ıkazuTOP(viz tabulku 2.8)

USER USER, PASS podpora autentizaˇcn´ıho mechanismuUSER/PASS SASL AUTH podpora r˚uzn´ych autentizaˇcn´ıch mechanism˚u RESP-CODES rozˇs´ıˇren´e moˇznosti n´avratov´ych k´od˚u

LOGIN-DELAY zav´ad´ı minim´aln´ı ˇcas mezi pokusy o pˇrihl´aˇsen´ı PIPELINING zˇretˇezen´ı pˇr´ıkaz˚u

EXPIRE umoˇzˇnuje serveru ozn´amit, jak dlouho uchov´a zpr´avy pˇred automatick´ym smaz´an´ım

UIDL UIDL podpora pˇr´ıkazuUIDL (viz tabulku 2.8) IMPLEMENTATION umoˇzˇnuje serveru sdˇelit svou implementaci

Kapitola 3

Zabezpeˇ

cen´ı elektronick´

e poˇ

sty

Elektronick´a poˇsta je jednou z nejstarˇs´ıch sluˇzeb internetu. Bˇehem sv´eho pˇredlouh´eho v´yvoje, ve kter´em dospˇela aˇz k dneˇsn´ımu velmi masov´emu rozˇs´ıˇren´ı, se vyskytlo mnoho nov´ych poˇzadavk˚u a jedn´ım z nich bylo i zabezpeˇcen´ı. Mnoho se zmˇenilo od dob, kdy elektro-nickou poˇstu pouˇz´ıvalo p´ar nadˇsenc˚u a nˇekolik univerzitn´ıch nebo arm´adn´ıch zamˇestnanc˚u. Dnes ji pouˇz´ıvaj´ı t´emˇeˇr vˇsichni uˇzivatel´e internetu a pos´ılaj´ı pˇres n´ı ˇsirok´e spektrum infor-mac´ı, od ˇretˇezov´ych dopis˚u aˇz po citliv´e firemn´ı ´udaje. D´ıky tomu je pro nˇekter´e uˇzivatele potˇreba zabezpeˇcen´ı velmi kritick´a.

V t´eto kapitole se pod´ıv´ame na existuj´ıc´ı zp˚usoby zabezpeˇcen´ı elektronick´e poˇsty.

3.1

Zabezpeˇ

cen´ı pˇ

rihlaˇ

sov´

an´ı k serveru

Poˇstovn´ı protokoly na tom zpoˇc´atku byly velmi ˇspatnˇe z hlediska autentizaˇcn´ıch mecha-nism˚u – bud’ nemˇely v˚ubec ˇz´adn´e (SMTP), nebo mˇely, ale nevhodn´e (POP3 a heslo pos´ılan´e v otevˇren´em textu). Kv˚uli tomu existovalo a existuje nebezpeˇc´ı, ˇze se k serveru pˇrihlaˇsuje nˇekdo jin´y neˇz m´a, napˇr´ıklad ´utoˇcn´ık, kter´emu se podaˇrilo odposlechnout heslo pˇri komu-nikaci protokolem POP3.

Tyto chab´e moˇznosti autentizace s sebou pˇrin´aˇsej´ı bezpeˇcnostn´ı rizika, a to napˇr´ıklad: • Utoˇ´ cn´ık se m˚uˇze vyd´avat za nˇekoho, k´ym nen´ı (napˇr´ıklad pouˇzije heslo pro pˇr´ıstup k

WWW rozhran´ı nebo k zabezpeˇcen´emu SMTP serveru). • Utoˇ´ cn´ık si m˚uˇze ˇc´ıst veˇsker´e zpr´avy uloˇzen´e na serveru.

• Utoˇ´ cn´ık m˚uˇze zpr´avy na serveru smazat, nedostanou se k zam´yˇslen´emu pˇr´ıjemci. • Utoˇ´ cn´ık m˚uˇze vyuˇz´ıt heslo ke zmˇenˇe na jin´e a t´ım odˇr´ıznout pr´avoplatn´eho uˇzivatele

od schr´anky.

Prvn´ı dva body m˚uˇzeme vyˇreˇsit pouˇzit´ım zabezpeˇcen´ı na aplikaˇcn´ı ´urovni (viz3.3), ale t´ım st´ale nevyˇreˇs´ıme vˇse. Jako obrana pˇred tˇemito ´utoky byly do protokol˚u pˇrid´any r˚uzn´e (vˇetˇsinou ovˇsem nepovinn´e) autentizaˇcn´ı mechanismy.

3.1.1 Pˇr´ıkaz AUTH(ENTICATE)

Jde o rozˇs´ıˇren´ı vytvoˇren´e pro protokoly SMTP, POP3 i IMAP, slouˇz´ıc´ı k zabezpeˇcn´emu pˇrihlaˇsov´an´ı k serveru.

Server ohl´as´ı, kter´e autentizaˇcn´ı algoritmy podporuje (jak, to z´aleˇz´ı na protokolu, pro princip to je nepodstatn´e). Klient si pot´e nˇekter´y z nich vybere a sdˇel´ı ho serveru jako parametr pˇr´ıkazu AUTH (nebo AUTHENTICATE v pˇr´ıpadˇe protokolu IMAP) – napˇr´ıklad AUTH CRAM-MD51. Pot´e n´asleduje v´ymˇena ˇretˇezc˚u k´odovan´ych pomoc´ı base64, kter´ymi se navz´ajem klient a server autentizuj´ı.

Po ´uspˇeˇsn´em ovˇeˇren´ı komunikace prob´ıha komunikace d´ale norm´aln´ım zp˚usobem (srov-nejte s3.2.1).

Pˇr´ıkaz AUTH protokolu ESMTP

Extended/Enhanced Simple Mail Transfer Protocol (rozˇs´ıˇren´y SMTP protokol) nab´ız´ı moˇznost autentizace odesilatele pomoc´ı pˇr´ıkazu AUTH.

Bohuˇzel m´a tento pˇr´ıkaz pouze ˇc´asteˇcn´e vyuˇzit´ı. Protoˇze pˇr´ıjemce zpr´avy nev´ı, zda byl odesilatel autentizov´an, a protoˇze nijak neˇreˇs´ı, zda se autentizoval uˇzivatel, kter´y je u dopisu uveden v poli hlaviˇckyFrom:, slouˇz´ı v podstatˇe jen pro boj s nevyˇz´adanou poˇstou. [9]

3.1.2 Pˇr´ıkaz APOP protokolu POP3

Velk´y probl´em pˇripojov´an´ı k poˇstovn´ı schr´ance protokolem POP3 je pos´ıl´an´ı hesla v prost´em textu. Toto m˚uˇze b´yt pomˇernˇe uspokojivˇe vyˇreˇseno rozˇs´ıˇren´ım protokolu o pˇr´ıkaz APOP.

V praxi to vypad´a tak, ˇze se uˇzivatel neautentizuje pomoc´ı pˇrikaz˚u USER a PASS, ale pouˇzije m´ısto toho jen jeden, APOP. Server v tomto pˇr´ıpadˇe mus´ı do sv´eho pozdravu zahrnout pokud moˇzno jedineˇcn´y ˇretˇezec. Ten klient vyuˇzije tak, ˇze jej konkatenuje s heslem a ze vznikl´eho ˇretˇezce vytvoˇr´ı hash algoritmem MD5 (viz pˇr´ıklad3.1).

S: +OK POP3 server ready <unique string> C: APOP username md5(<unique string>password)

Tabulka 3.1: Sch´ema autentizace pˇr´ıkazem APOP

Nev´yhodou tohoto ˇreˇsen´ı je nutnost uchov´avat na serveru hesla v otevˇren´em textu (pˇri autentizaci pˇr´ıkazy USER/PASS bohatˇe staˇc´ı otisky vytvoˇren´e vhodnou rozptylovac´ı funkc´ı (MD5, SHA1)).

3.2

Zabezpeˇ

cen´ı cel´

eho pr˚

ubˇ

ehu komunikace

V tomto pˇr´ıpadˇe prov´ad´ıme ˇsifrov´an´ı veˇsker´e komunikace mezi klientem a serverem. Jed-noznaˇcnou volbou v t´eto oblasti je protkol TLS/SSL.

3.2.1 Zabezpeˇcen´ı na ´urovni transportn´ı vrstvy, TLS/SSL

Protokol TLS (Transport Layer Security, n´astupce protokolu SSL – Secure Sockets Layer) slouˇz´ı k obecnˇe k zabezpeˇcen´ı jak´ekoliv komunikace (tedy nejen elektronick´e poˇsty) na ´

urovni transportn´ı vrstvy.

Takto by bylo moˇzno vyˇreˇsit probl´em zat´ım odsunut´y do pozad´ı, a to je zabezpeˇcen´ı pˇrihlaˇsovac´ıch ´udaj˚u. Jejich vyzrazen´ı sice nen´ı ´uplnˇe kl´ıˇcov´e, ´utoˇcn´ık, kter´y by se k nim

1

Napˇr´ıklad tento algoritmus je sv´ym principem velmi podobn´y pr˚ubˇehu autentizace pomoc´ı pˇr´ıkazu APOP, nav´ıc ale nevyˇzaduje uloˇzen´ı hesel v otevˇren´em textu.

dostal, si m˚uˇze pˇreˇc´ıst (v ide´aln´ım pˇr´ıpadˇe) pouze zaˇsifrovan´e zpr´avy uloˇzen´e ve schr´ance, ale i tak je schopen zp˚usobit jist´e pot´ıˇze.

R´ad bych jeˇstˇe podotknul, ˇze rozhodnˇe nejde o n´ahradu zabezpeˇcen´ı obsahu emailov´ych zpr´av a nenahrazuje syst´emy k tomu urˇcen´e (PGP, S/MIME. . . ).

Nev´yhody pouˇzit´ı TLS [2]:

• potenci´aln´ı v´ypoˇcetn´ı n´aroˇcnost pˇri vˇetˇs´ım poˇctu pˇr´ıchoz´ıch spojen´ı, kter´a m˚uˇze vy´ustit v nutnost pouˇzit´ı hardwaru urychluj´ıc´ıho ˇsifrovac´ı operace ˇci celkovˇe velmi v´ykonn´eho

• pro pouˇzit´ı se vˇsemi klienty nutnost podporovat jak samotn´e TLS na dan´em portu, tak pˇr´ıkaz rozˇsiˇruj´ıc´ı aplikaˇcn´ı protokol (STARTTLS)

• nutnost spravovat datab´azi certifik´at˚u, pˇr´ıpadnˇe je kupovat

• faleˇsn´y pocit bezpeˇc´ı uˇzivatel˚u – opravdunejdeo n´ahradu ˇsifrov´an´ı obsahu email˚u Existuj´ı dva zp˚usoby pouˇzit´ı TLS, kter´e nyn´ı rozeberu.

TLS jako zabezpeˇcen´ı na ´urovni transportn´ı vrstvy

Prvn´ım je klasick´e ˇsifrov´an´ı na ´urovni transportn´ı vrstvy. V tomto pˇr´ıpadˇe komunikace prob´ıh´a na jin´em portu neˇz obyˇcejnˇe (viz tabulku 3.2 [6]) a jde v podstatˇe o zapouzdˇren´ı cel´e komunikace poˇstovn´ımi protokoly.

Protokol Port (bez TLS) Port (TLS)

SMTP 25 465 (odvol´ano2)

POP3 110 995

IMAP 143 993

Tabulka 3.2: ˇC´ısla protokol˚u pˇri zabezpeˇcen´ı komunikace pomoc´ı TLS

Nev´yhodou tohoto ˇreˇsen´ı je pr´avˇe nutnost dvou port˚u, s t´ım souvisej´ıc´ı problematiˇcnost a dlouhodobost zaveden´ı pˇr´ısluˇsn´ych standard˚u.

TLS jako rozˇs´ıˇren´ı aplikaˇcn´ıch protokol˚u

Jako alternativa k pˇredchoz´ımu bylo zavedeno zaˇclenˇen´ı TLS pˇr´ımo do aplikaˇcn´ıch proto-kol˚u jako rozˇs´ıˇren´ı. Toto je novˇejˇs´ı zp˚usob, prosazovn´y napˇr´ıklad i IETF pˇredevˇs´ım kv˚uli nedostatku ˇc´ısel port˚u.

Vypad´a to tak, ˇze se klient pˇripoj´ı pomoc´ı SMTP, respektive POP3 protokolu k ser-veru a v urˇcitou (pomˇernˇe pˇresnˇe danou) chv´ıli poˇz´ad´a o zmˇenu zp˚usobu komunikace na zabezpeˇcenou TLS pomoc´ı pˇr´ıkazu STARTTLS, respektive STLS.

3.3

Zabezpeˇ

cen´ı obsahu emailov´

ych zpr´

av

I kdyˇz pouˇz´ıv´ame nezabezpeˇcen´e poˇstovn´ı protokoly, jsme schopni obsah zpr´av zabezpeˇcit. V podstatˇe jde o to, ˇze pouˇzijeme ˇsifrov´an´ı nebo podepisov´an´ı na tˇelo emailov´e zpr´avy a t´ım ji ochr´an´ıme pˇred neˇz´adouc´ımi ˇcten´aˇri nebo potvrd´ıme sv´e autorstv´ı.

Tato oblast zabezpeˇcen´ı pˇr´ısluˇs´ı aplikaˇcn´ı ´urovni. ´Uloha zabezpeˇcen´ı je zde vˇetˇsinou d´ana do rukou koncov´ym uˇzivatel˚um, kteˇr´ı spol´ehaj´ı na vlastn´ı moˇznosti zabezpeˇcen´ı ob-sahu zpr´avy.

V´yhody:

• Nevad´ı n´am nezabezpeˇcen´e poˇstovn´ı protokoly.

• Nepotˇrebujeme ˇz´adnou speci´aln´ı podporu ze strany server˚u, kterou bychom si eventu´alnˇe nemˇeli moˇznost u jin´ych zp˚usob˚u vynutit.

• Nikdo nepovolan´y si naˇsi citlivou informaci nepˇreˇcte na serveru, kde je pˇri pouˇzit´ı jin´ych zp˚usob˚u zabezpeˇcen´ı vˇzdy uchov´av´ana nezaˇsifrovanˇe.

Nev´yhody:

• Nijak neˇreˇs´ı moˇznost vyzrazen´ı hesla pro pˇr´ıstup ke schr´ance.

• Toto ˇreˇsen´ı je sp´ıˇse individu´aln´ı neˇz aplikovateln´e na ˇsirˇs´ı skupinu lid´ı. Pokud bychom chtˇeli donutit celou firmu pouˇz´ıvat nˇeco takov´eho, pˇrineslo by to velmi obt´ıˇznˇe ˇreˇsiteln´e probl´emy.

• Zabezpeˇcen´ım cel´eho obsahu m˚uˇzeme znemoˇznit nalezen´ı potencion´aln´ıho malware3, pokud je skenov´an´ı prov´adˇeno kdekoliv jinde neˇz na koncov´ych stanic´ıch.

Teoreticky bychom tedy mohli vz´ıt obsah kaˇzd´e zpr´avy, kterou budeme odes´ılat, zaˇsifrovat ji domluven´ym algoritmem a kl´ıˇcem (podle pˇr´ıjemce) a poslat ji. V praxi se ale pouˇz´ıvaj´ı urˇcit´e standardizovan´e metody, jeˇz uˇsetˇr´ı hodnˇe pr´ace a starost´ı s nekompatibilitou. Zmiˇnme si tedy nejpouˇz´ıvanˇejˇs´ı syst´emy.

3.3.1 S/MIME – Secure / Multipurpose Internet Mail Extensions

S/MIME je standard pro zabezpeˇcen´ı emailov´ych zpr´av zaloˇzen´y na kryptografii pomoc´ı veˇrejn´eho kl´ıˇce; pouˇz´ıv´a/rozˇsiˇruje form´at zpr´av MIME.

P˚uvodnˇe byl vyvinut spoleˇcnost´ı RSA Data Security Inc. jako syst´em zaloˇzen´y na form´atu MIME a PKCS #7 (Public Key Cryptography Standards). Posl´eze byl pˇrevzat IETF a uˇcinˇen souˇc´ast´ı CMS (Cryptografic Message Syntax), coˇz je de facto ve vˇsech pod-statn´ych ohledech dvojn´ık PKCS #7.

Syst´em funguje tak, ˇze vezme celou MIME entitu4, aplikuje na n´ı poˇzadovanou ope-raci (ˇsifrov´an´ı, digit´aln´ı podeps´an´ı) a vznikl´a data vloˇz´ı do nov´e MIME entity s obsahem deklarovan´ym jako application/pkcs7-mime.

Jde ve sv´em n´avrhu o centralizovan´y syst´em, kter´y ke sv´emu chodu potˇrebuje certifikaˇcn´ı autoritu5 (CA – Certificate Authority). Bezpeˇcnost komunikace je d´ana t´ım, ˇze obˇe strany vˇeˇr´ı certifikaˇcn´ı autoritˇe, od kter´e si vyˇz´adaj´ı veˇrejn´y kl´ıˇc druh´e strany. Nev´yhodou tohoto pˇr´ıstupu je, ˇze pokud je CA kompromitov´ana, m´a to dopad na vˇsechny uˇzivatele, kteˇr´ı j´ı vˇeˇr´ı.

3

Malware – MALicious softWARE, ˇskodliv´y sowtware, jako napˇr´ıklad viry, trojˇst´ı konˇe, ˇcervi, spyware, adware. . .

4

MIME entita je emailov´a zpr´ava, pˇr´ıpadnˇe jej´ı tˇelo.

3.3.2 PGP – Pretty Good Privacy

PGP je poˇc´ıtaˇcov´y program urˇcen´y k ˇsifrov´an´ı a podepisov´an´ı obecnˇe jak´ychkoliv dat. Byl vytvoˇren roku 1991 Philipem Zimmermannem. D´ıky sv´emu velk´emu rozˇs´ıˇren´ı byly pro potˇrebu komunikace elektornickou poˇstou vytvoˇreny standardy RFC 2015 (MIME Security with Pretty Good Privacy) a RFC 2440 (OpenPGP Message Format).

K ovˇeˇren´ı, zda veˇrejn´y kl´ıˇc patˇr´ı skuteˇcnˇe zm´yˇslen´emu pˇr´ıjemci, m´a PGP dva mecha-nismy.

Web of trust Starˇs´ı zp˚usob ovˇeˇren´ı pouˇz´ıv´a takzvanou

”pavuˇcinu d˚uvˇery“. Vypad´a to tak, ˇze jednotliv´ı uˇzivatel´e se mohou rozhodnout vˇeˇrit tomu, ˇze dan´y veˇrejn´y kl´ıˇc patˇr´ı tomu, komu hl´as´a. Pak tento kl´ıˇc s informacemi, komu patˇr´ı, podep´ıˇs´ı sv´ym podpisem a takto daj´ı svou d˚uvˇeru najevo ostatn´ım uˇzivatel˚um. T´ım vznikne jak´asi distribuovan´a s´ıt’, ve kter´e si jednotlivci navz´ajem v´ıce ˇci m´enˇe vˇeˇr´ı. M´ıra d˚uvˇery v urˇcit´y kl´ıˇc se pak pˇrepoˇc´ıt´ava pˇri kaˇzd´e zmˇenˇe v sadˇe kl´ıˇc˚u, kter´ym d˚uvˇeˇruji.

Certifikaˇcn´ı autority Ve specifikaci OpenPGP existuje moˇznost vytvoˇrit takzvan´etrust signatures, kter´e umoˇzˇnuj´ı tvorbu certifikaˇcn´ıch autorit. Pokud kl´ıˇc podep´ıˇsu pomoc´ıtrust signature, znaˇc´ı to mou d˚uvˇeru v to, ˇze kl´ıˇc patˇr´ı ud´avan´emu vlastn´ıkovi a z´aroveˇn ˇze tomuto vlastn´ıkovi vˇeˇr´ım v ot´azce podpisu jin´ych kl´ıˇc˚u. Podpis nult´e ´urovnˇe je podobn´y uˇz zmiˇnovan´e

”pavuˇcinˇe d˚uvˇery“, indikuje, ˇze vˇeˇr´ım pouze identitˇe vlastn´ıka. Podpis prvn´ı ´

urovnˇe je analogick´y d˚uvˇeˇre v certifikaˇcn´ı autoritu, takto podepsan´emu kl´ıˇci vˇeˇr´ım kaˇzd´y kl´ıˇc nult´e ´urovnˇe, kter´y podep´ıˇse. Existuje jeˇstˇe podpis druh´e ´urovnˇe – kl´ıˇc, kter´y takto podep´ıˇsu, pro mˇe vlastnˇe m˚uˇze vytv´aˇret certifikaˇcn´ı autority.

Kapitola 4

N´

avrh

C´ılem t´eto bakal´aˇrsk´e pr´ace bylo vylepˇsit existuj´ıc´ı implementaci emailov´e proxy a rozˇs´ıˇrit ji o moˇznost vzd´alen´e konfigurace. V t´eto kapitole pop´ıˇsu, jak byl cel´y syst´em navrˇzen, proˇc zrovna tak, jeho v´yhody a nev´yhody, c´ılov´e prostˇred´ı pro nasazen´ı a podobnˇe.

4.1

Celkov´

a filosofie

Cel´y syst´em funguje jako proxy server1. M´a za ´ukol zabezpeˇcit veˇskerou komunikaci, kter´a pˇres nˇej proch´az´ı, podle definovan´ych politik.

Zabezpeˇcen´ı se dˇeje na ´urovni obsahu zpr´av, tedy na aplikaˇcn´ı ´urovni. Syst´em je scho-pen odchytit zpr´avu, jeˇz je pˇres nˇej odes´ıl´ana serveru nebo doruˇcov´ana klientovi, a jej´ı obsah patˇriˇcnˇe pozmˇenit. Pokud jde o odes´ıl´an´ı, pak zpr´ava m˚uˇze b´yt (podle nastaven´ı pˇr´ısluˇsn´ych politik mezi odesilatelem a pˇr´ıjemcem) zaˇsifrov´ana a podeps´ana. Pˇri doruˇcov´an´ı probˇehne opaˇcn´y proces, je ovˇeˇren podpis, zpr´ava je rozˇsifrov´ana a v otevˇren´em textu pˇred´ana pˇr´ıjemci.

4.1.1 V´yhody

Asi nejvˇetˇs´ı v´yhodou takov´ehoto syst´emu je poˇzadovan´e zapojen´ı uˇzivatele a n´aroky na jeho znalosti, kter´e jsou prakticky nulov´e. O vˇse podstatn´e se star´a proxy server a jeho administr´ator.

D´ale je syst´em pro koncov´eho uˇzivatele prakticky neviditeln´y. V podstatˇe jedinou vˇec´ı, jak na sebe proxy upozorˇnuje, jsou potenci´aln´ı varov´an´ı o nesed´ıc´ım podpisu nebo nemoˇznosti rozˇsifrov´an´ı.

Velmi d˚uleˇzit´a je moˇznost vytv´aˇren´ı pomˇernˇe komplexn´ıch politik zabezpeˇcen´ı na nˇekolika r˚uznˇe prioritn´ıch ´urovn´ıch (napˇr´ıklad celkov´e nastaven´ı proxy m˚uˇze pˇreb´ıt nastaven´ı uˇzivatelovo).

V´yhodou je tak´e moˇznost vzd´alen´e konfigurace, kter´a umoˇzn´ı proxy serveru bˇeˇzet na jakkoli nedosaˇziteln´em m´ıstˇe, k nˇemuˇz administr´ator v˚ubec nemus´ı m´ıt fyzick´y pˇr´ıstup.

Syst´em je tak´e pomˇernˇe modul´arn´ı. Vˇetˇsinu komponent lze bez vˇetˇs´ıch probl´em˚u na-hradit jejich jinak ˇreˇsen´ymi ekvivalenty, jedin´y poˇzadavek je dodrˇzen´ı rozhran´ı. Napˇr´ıklad pokud se n´am nel´ıb´ı, ˇze se nastaven´ı ukl´ad´a do XML, m˚uˇzeme si ho uloˇzit kamkoliv, od textov´eho souboru po SQL datab´azi; jedinou podm´ınkou je uˇz zm´ınˇen´e zachov´an´ı rozhran´ı. Celkov´e pojet´ı tak´e pˇrin´aˇs´ı velkou v´yhodu v moˇznosti pˇridat k proxy serveru dalˇs´ı dnes ˇ

z´adan´e funkce, jako napˇr´ıklad testov´an´ı na obsah malware nebo filtrov´an´ı nevyˇz´adan´e poˇsty. 1

Proxy server je server obsluhuj´ıc´ı sv´e klienty pos´ıl´an´ım ˇz´adost´ı a pˇrij´ım´an´ım odpovˇed´ı od jin´ych server˚u. V podstatˇe se v komunikaci nach´az´ı mezi klientem a serverem, veˇsker´a data proch´azej´ı pˇres nˇej.

Pokud by se zabezpeˇcen´ı dˇelo uˇz na klientsk´ych poˇc´ıtaˇc´ıch, toto by v ˇz´adn´em pˇr´ıpadˇe nebylo moˇzn´e.

4.1.2 Nev´yhody

Proxy zat´ım nijak neˇreˇs´ı zabezpeˇcen´ı konfiguraˇcn´ıho souboru. Pokud by se ´utoˇcn´ık dostal k zapnut´emu poˇc´ıtaˇci, na kter´em proxy bˇeˇz´ı, mohl by pomˇernˇe snadno naruˇsit celou ko-munikaci, napˇr´ıklad zak´az´an´ım ˇsifrov´an´ı. Nebo m˚uˇze zmˇenit veˇrejn´e kl´ıˇce uˇzivatel˚u, coˇz s sebou pˇrinese tu sv´ızel, ˇze m´ısto zam´yˇslen´eho pˇrijemce si ˇsifrovan´e emaily bude ˇc´ıst pr´avˇe ´

utoˇcn´ık, pˇr´ıpadnˇe n´am bude pos´ılat zpr´avy, kter´e budou naoko podeps´any nˇek´ym jin´ym. Podobn´ym probl´emem je i uloˇzen´ı soukrom´ych kl´ıˇc˚u. Jsou uloˇzeny v souboru a chr´anˇeny heslem, bohuˇzel ale k nim proxy mus´ı m´ıt kdykoliv pˇr´ıstup a proto si toto heslo mus´ı nˇekde ukl´adat. Pokud by se tento soubor dostal do rukou ´utoˇcn´ıkovi (i kdyby bez potˇrebn´ych hesel), znamenalo by to doslova katastrofu.

Dalˇs´ı oblast´ı, na kter´e by se dalo zapracovat, je vyuˇzit´ı lepˇs´ıch autentizaˇcn´ıch mecha-nism˚u, kter´e by zabr´anily ´utoˇcn´ıkovi z´ıskat hesla uˇzivatel˚u.

Proxy server se tak´e zat´ım ned´a pouˇz´ıt spolu s SMTP serverem vyˇzaduj´ıc´ım autentizaci, coˇz souvis´ı s pˇredchoz´ım bodem. Existuje tedy v podstatˇe nutnost m´ıt ve vnitˇrn´ı s´ıti vlastn´ı SMTP server, kter´y bude proxy vˇeˇrit bez autentizace, servery v internetu toto nedˇelaj´ı kv˚uli boji s nevyˇz´adanou poˇstou (spammem).

Syst´em potˇrebuje neust´ale bˇeˇz´ıc´ı poˇc´ıtaˇc, na kter´em m˚uˇze fungovat. Nen´ı pˇr´ıliˇs vhodn´e pouˇz´ıvat jej na poˇc´ıtaˇci, na kter´em se dˇeje i jin´a uˇzivatelsk´a pr´ace, at’ uˇz z hlediska nutnosti spouˇstˇen´ı jako uˇzivatele root, kv˚uli obˇcasn´ym nutn´ym restart˚um (kdo nemusel pˇri pr´aci nikdy restartovat poˇc´ıtaˇc. . . ) nebo napˇr´ıklad pro omezen´ı v´ykonu. V podstatˇe si takto vyˇzaduje jeden poˇc´ıtaˇc s´am pro sebe, coˇz m˚uˇze b´yt dalˇs´ı finanˇcn´ı z´atˇeˇz. ˇReˇsen´ı navrhuje podkapitola 6.3.

4.2

C´ılov´

e prostˇ

red´ı

Syst´em je obecnˇe navrˇzen k pouˇzit´ı v´ıce uˇzivateli sd´ılej´ıc´ımi spoleˇcnoubezpeˇcnou s´ıt’, kter´a m´a pˇr´ıstup k internetu (jinak bychom nemohli nic pos´ılat).

Jako ide´aln´ı pˇr´ıpad se jev´ı napˇr´ıklad velk´a firma pouˇz´ıvaj´ıc´ı elektronickou poˇstu k pos´ıl´an´ı citliv´ych informac´ı. Zde m˚uˇze syst´em uˇsetˇrit mnoho starost´ı souvisej´ıc´ıch s ne-pouˇcenost´ı uˇzivatel˚u, viz podkapitola 4.1.1.

Nic nebr´an´ı ani tomu m´ıt proxy server spuˇstˇen´y na lok´aln´ım poˇc´ıtaˇci a vyuˇz´ıvat ho jen pro sebe. T´ım ale nebudeme schopni vyuˇz´ıt mnoho sluˇzeb, kter´e poskytuje, cel´y mechanis-mus definice bezpeˇcnostn´ıch politik se degraduje na vyuˇz´ıv´an´ı pouze jeho zlomku. Nicm´enˇe vyuˇz´ıt syst´em takto je tak´e moˇzn´e.

4.3

Rozˇ

siˇ

ritelnost a modularita

Cel´y syst´em je navrˇzen pokud moˇzno co nejv´ıce modul´arnˇe, pˇredevˇs´ım z d˚uvod˚u snadn´e rozˇsiˇritelnosti, moˇznosti zmˇeny implementace podsyst´em˚u, pˇrehlednosti a udrˇzovatelnosti. Rozˇsiˇritelnost J´adro syst´emu poskytuje pomˇernˇe obecn´e funkce, jeˇz mohou b´yt vyuˇzity pro zabezpeˇcen´ı emailov´e komunikace prob´ıhaj´ıc´ı t´emˇeˇr jak´ymkoliv protokolem. Proto napˇr´ıklad nen´ı velk´ym probl´emem pˇridat dalˇs´ı modul zabezpeˇcuj´ıc´ı komunikaci dosud nepouˇz´ıvan´ym protokolem.

Modularita Syst´em byl navrˇzen tak, aby se pokud moˇzno co nejv´ıce zjednoduˇsila komu-nikace mezi jednotliv´ymi moduly. Ne vˇzdy to je sice moˇzn´e stoprocentnˇe dodrˇzet (napˇr´ıklad v datab´azi je velmi mnoho druh˚u ´udaj˚u a proto je potˇreba v´ıce funkc´ı pro pˇr´ıstup k nim), nese to s sebou urˇcit´e komplikace (napˇr´ıklad z hlediska v´ykonu), ale celkovˇe jde o dle m´eho n´azoru dobr´y pˇr´ıstup zvyˇsuj´ıc´ı ˇcitelnost a znovupouˇzitelnost k´odu, potenci´aln´ı bu-douc´ı v´yvoj´aˇri se d´ıky tomu nemus´ı starat o jin´e moduly neˇz ty, na kter´ych opravdu chtˇej´ı pracovat.

4.4

Bezpeˇ

cnostn´ı politiky

Dost kl´ıˇcovou ˇc´ast´ı je moˇznost nadefinovat si r˚uzn´e bezpeˇcnostn´ı politiky pro r˚uzn´e trasy dopis˚u. Celkov´y n´avrh o tomto ˇr´ık´a pouze to, ˇze je moˇzn´e tuto politku definovat dvakr´at, jednou pro jednotliv´e uˇzivatele a podruh´e pro cel´e dom´eny. V´ıce o tomto v popisu konkr´etn´ı implementace v ˇc´asti5.2.2.

Kapitola 5

Implementace

V t´eto kapitole pop´ıˇsu skuteˇcnou implementaci syst´emu, pouˇzit´e technologie, strukturu aplikace. Velmi d˚uleˇzit´a je i vzd´alen´a konfigurace.

5.1

Pouˇ

zit´

e technologie

Pro implementaci byl zvolen programovac´ı jazyk C a (prim´arnˇe) prostˇred´ı operaˇcn´ıho syst´emu GNU/Linux. Jazyk C pˇredevˇs´ım kv˚uli sv´emu velk´emu rozˇs´ıˇren´ı, jednoduchosti, rychlosti a pˇrenositelnosti. Operaˇcn´ı syt´em GNU/Linux je s jazykem C velmi ´uzce sv´az´an uˇz od poˇc´atk˚u sv´eho v´yvoje, poskytuje skvˇel´e n´astroje vhodn´e pro ladˇen´ı a kontrolu chyb (gdb, ddd, valgrind) a jsou v nˇem jednoduˇse pouˇziteln´e zvolen´e pomocn´e knihovny.

Z d˚uleˇzit´ych nestandardn´ıch knihoven bych r´ad jmenoval hlavnˇe cryptlib (velmi mocn´a kryptografick´a knihovna s pomˇernˇe jednoduch´ym pouˇzit´ım) a libxml2 (knihovna urˇcen´a pro pr´aci s XML).

5.2

Struktura

V t´eto kapitole se koneˇcnˇe dost´av´ame k popisu jednotliv´ych podsyst´em˚u/modul˚u. Pro z´akladn´ı pˇrehled viz obr´azek5.1, podrobnˇejˇs´ı popis jednotliv´ych ˇc´ast´ı n´asleduje. Pˇri tomto popisu se snaˇz´ım i trochu naznaˇcit rozhran´ı, kter´e pouˇz´ıvaj´ı jednotliv´e moduly pro vz´ajemnou domluvu.

5.2.1 Server

Toto je jedna z nejd˚uleˇzitˇejˇs´ıch ˇc´ast´ı syst´emu. Obecnˇe jde o jak´ykoliv server, kter´y bude vuyˇz´ıvat moˇznost´ı poskytovan´e zbytkem syst´emu. V naˇsem konkr´etn´ım pˇr´ıpadˇe na m´ıstˇe obecn´eho serveru bˇeˇz´ı SMTP, POP3 a IMAP proxy server plus server konfiguraˇcn´ı.

SMTP proxy (smtp)

V tomto modulu je naimplementov´an klasick´y konkurentn´ı server1. Obsluhuje pˇripojen´ı od r˚uzn´ych klient˚u, vlastnˇe jim pˇredst´ır´a jednoduch´y SMTP server, a zpr´avy, kter´e mu poˇslou, upravuje podle definovan´ych politik a pos´ıl´a nyn´ı uˇz skuteˇcn´ym SMTP server˚um.

Vyuˇz´ıv´a pˇredevˇs´ım funkciProcessOutgoingEmailz modulumailhandle(viz ˇc´ast5.2.4), kter´a je schopn´a prov´est veˇsker´e nutn´e transformace.

POP3 proxy (pop3)

Tento modul je myˇslenkou velmi podobn´y SMTP proxy. Rozd´ıl je v tom, ˇze tolik nemˇen´ı komunikaci klienta se serverem, velkou ˇc´ast nech´av´a proj´ıt beze zmˇeny narozd´ıl od SMTP proxy.

Do komunikace se vloˇz´ı jen ve dvou m´ıstech.

1. Pˇri autentizaci (pˇr´ıkazy USER a PASS) mus´ı zjistit, ke kter´emu POP3 serveru dan´y uˇzivatel n´aleˇz´ı. To nen´ı tak jednoduch´e, protoˇze se uˇzivatel identifikuje jen uˇzivatelsk´ym jm´enem. ˇReˇs´ım to tak, ˇze bud’ se uˇzivatel˚uv MUA nastav´ı tak, aby se identifikoval celou emailovou adresou, nebo se v datab´azi hled´a jen pˇrihlaˇsovac´ı jm´eno pouˇziteln´e jen v pˇr´ıpadˇe, ˇze nedojde ke kolizi (dva uˇzivatel´e mohou m´ıt stejn´e jm´eno, pokud pouˇz´ıvaji r˚uzn´e POP3 servery).

2. Pokud je posl´an pˇr´ıkazRETR msg, odpovˇed´ı na nˇej je poˇzadovan´a zpr´ava. Tu mus´ıme odchytit a pˇr´ıpadnˇe rozˇsifrovat a ovˇeˇrit podpis. K tomu slouˇz´ı funkceProcessIncomingEmail z modulumailhandle (viz ˇc´ast 5.2.4).

IMAP proxy (imap)

Sv´ym principem je tato ˇc´ast podobn´a POP3 proxy (viz podkapitolu5.2.1). Protokol IMAP m´a pouze mnohem v´ıc funkc´ı, coˇz s sebou pˇrin´aˇs´ı vˇetˇs´ı n´aroˇcnost. Ke zpracov´an´ı zpr´avy slouˇz´ı opˇet funkce ProcessIncomingEmail z modulu mailhandle (viz ˇc´ast 5.2.4). V´ıce se touto ˇc´ast´ı zab´yvat nebudu.

Konfiguraˇcn´ı server (config)

Konfiguraˇcn´ı server m´a pomˇernˇe jednoduchou ´ulohu. V zadan´ych ˇcasov´ych intervalech kon-troluje urˇcenou emailovou schr´anku na pˇr´ıtomnost nov´eho konfiguraˇcn´ıho emailu. Pokud ta-kov´y objev´ı, st´ahne jej (pomoc´ı protokolu POP3) a zavol´a funkciProcessConfigurationEmail. Pokud tato funkce vr´at´ı ukazatel r˚uzn´y od NULL, pak jako odpovˇed’ na kofiguraˇcn´ı email poˇsle pr´avˇe zpr´avu, na kterou zm´ınˇen´y ukazatel m´ıˇr´ı. V´ıce o vzd´alen´e konfiguraci v podka-pitole5.3.

1

5.2.2 Datab´aze nastaven´ı (xmlhandle)

Pro form´at datab´aze byl zvolen XML soubor, a to pˇredevˇs´ım z d˚uvodu kompromisu mezi ˇ

citelnost´ı lidsk´ym okem a rychlost´ı strojov´eho zpracov´an´ı. Toto se uk´azalo jako dobr´a volba i z pohledu jednoduch´eho ˇreˇsen´ı vzd´alen´e konfigurace (viz ˇc´ast 5.3).

Datab´aze je rozdˇelena na ˇctyˇri ˇc´asti, kter´e postupnˇe rozeberu. Uˇzivatel´e

Tato ˇc´ast obsahuje nastaven´ı pro jednotliv´e uˇzivatele. Z ´udaj˚u uchov´avan´ych u kaˇzd´eho uˇzivatele stoj´ı za zm´ınky pˇredevˇs´ım tyto:

• pˇrihlaˇsovac´ı jm´eno na POP3 server • emailov´a adresa

• adresa SMTP serveru a ˇc´ıslo portu • adresa POP3 serveru a ˇc´ıslo portu • adresa IMAP serveru a ˇc´ıslo portu • otisk hesla pro v´ymˇenu kl´ıˇc˚u2

• nastaven´ı politik v kompetenci uˇzivatel˚u

• soubor kl´ıˇc˚u – veˇrejn´e a soukrom´e kliˇce uˇzivatele; jeden je urˇcen jako univerz´aln´ı, u (pˇr´ıpadn´ych dalˇs´ıch je urˇceno, pro komunikaci s kter´ymi uˇzivateli jsou urˇceny) Nastaven´ı politik se m˚uˇze skl´adat z nastaven´ı pro jednotliv´e uˇzivatele a ze skupinov´ych politik. U kaˇzd´e politiky je t´ımto urˇceno, pro komunikaci s k´ym je urˇcena. D´ale toto nasta-ven´ı obsahuje poˇzadavky na komunikaci s dan´ym uˇzivatelem nebo skupinou, a to:

• zda se m´a ˇsifrovat • zda se m´a podepisovat • co z toho se m´a dˇelat dˇr´ıve

• co se m´a dˇelat, kdyˇz se nˇeco nepovede, zda poslat nezabezpeˇcenˇe, nebo neposlat v˚ubec Dom´eny

V tˇeto sekci jsou nastaven´ı pro jednotliv´e dom´eny. Opˇet se pod´ıvejme na uchov´avan´e ´udaje: • adresa dom´eny

• seznam administr´ator˚u – uˇrivatel˚u opr´avnˇen´ych mˇenit nastaven´ı pro celou dom´enu • nastaven´ı politik v kompetenci dom´en

• soubor kl´ıˇc˚u – veˇrejn´e a soukrom´e kl´ıˇce uˇzivatele; jeden je urˇcen jako univerz´aln´ı, u (pˇr´ıpadn´ych dalˇsich je urˇceno, pro komunikaci s kter´ymi uˇzivateli jsou urˇceny) Nastaven´ı politik je podobn´e tomu u uˇzivatel˚u. Z´asadn´ım rozd´ılem ale je to, ˇze jde o nastaven´ı ne pro komunikaci s jednotliv´ymi uˇzivateli, ale s cel´ymi dom´enami.

2

Proxy

V t´eto ˇc´asti se nach´az´ı nastaven´ı pro proxy server a t´ım p´adem i pro cel´y zde popisovan´y syst´em.

• porty, na kter´ych bˇeˇz´ı jednotliv´e

”faleˇsn´e“ servery pro komunikci s uˇzivateli • seznam uˇzivatel˚u – administr´ator˚u proxy

• informace t´ykaj´ıc´ı se vzd´alen´e konfigurace – zda je povolena, ´udaje o poˇstovn´ı schr´ance, informace o serveru odchoz´ı poˇsty (pouˇz´ıvan´y pro odpovˇedi a zaznamen´av´an´ı ud´alost´ı, logov´an´ı)

• seznam m´ıst, kam zapisovat logy

• centr´aln´ı definice politik, maj´ıc´ı nejvyˇsˇs´ı prioritu

• jedin´y p´ar kl´ıˇc˚u, slouˇz´ıc´ı pˇredevˇs´ım k zabezpeˇcen´ı konfiguraˇcn´ıch zpr´av Definice politik je v tomto pˇr´ıpadˇe ponˇekud sloˇzitˇejˇs´ı. Kromˇe toho

”kam“ si mus´ıme uchov´avat i

”odkud“ (pˇredt´ım to bylo jasn´e, vˇzdy se vych´azelo od aktu´aln´ıho uˇzivatele nebo dom´eny). Toto nastaven´ı je rozdˇeleno na dvˇe ˇc´asti, uˇzivatelskou a dom´enovou, v kaˇzd´e ˇc´asti lze definovat i politiky skupinov´e. Rovnˇeˇz zde existuje mechanismus urˇcen´ı smˇeru komunikace, na kter´y se m´a dan´a politika aplikovat (od prvn´ıho k druh´emu, naopak, v obou smˇerech). Pro podrobnosti odkazuji ˇcten´aˇre pˇr´ımo do konfiguraˇcn´ıho souboru, je pomˇernˇe n´azorn´y a pochopiteln´y.

Veˇrejn´e kl´ıˇce

V t´eto ˇc´asti se nach´az´ı veˇrejn´e kl´ıˇce tˇech uˇzivatel˚u nebo dom´en, kteˇr´ı nespadaj´ı pˇr´ımo pod dan´y proxy server a tedy nem´ame jejich soukrom´y kl´ıˇc. Forma tohoto odd´ılu je velmi po-dobn´a seznamu kl´ıˇc˚u u jednotliv´ych uˇzivatel˚u nebo dom´en, aˇz na to, ˇze zde nejsou informace o veˇrejn´ych kl´ıˇc´ıch.

5.2.3 Kryptografie (cryptography)

Tento modul poskytuje jednoduch´a rozhran´ı pro ˇsifrov´an´ı (s vyuˇzit´ım knihovnycryptlib) a potˇrebn´e k´odov´an´ı. Pro pˇrehled viz tabulku5.1

N´azev Funkce

Encrypt zaˇsifruje data Decrypt rozˇsifruje data Sign podep´ıˇse data

Verify ovˇeˇr´ı podepsan´a data

EncodeBase64 zak´oduje data algoritmem base64

DecodeBase64 rozk´oduje data zak´odovan´a algoritmem base64 Tabulka 5.1: Funkce kryptografick´eho modulu

Zaj´ımav´y zde je zp˚usob pˇred´av´an´ı kl´ıˇc˚u. Kv˚uli poˇzadovan´e nez´avislosti modul˚u na sobˇe navz´ajem nebylo moˇzn´e pouˇz´ıt vnitˇrn´ı form´atcryptlibu. M´ısto toho se pouˇz´ıv´a v pˇr´ıpadˇe veˇrejn´ych kl´ıˇc˚u exportovan´y certifik´at a v pˇr´ıpadˇe soukrom´ych kl´ıˇc˚u ˇretˇezec obsahuj´ıc´ı n´azev

keysetu3 _{a n´azev kl´ıˇce (tyto dvˇe informace jsou oddˇeleny dvojteˇckou, pˇr´ıpadn´a dvojteˇcka v} n´azvu se zdvoj´ı).

5.2.4 Zpracov´an´ı emailu (mailhandle)

Tento modul je v podstatˇe centrem cel´eho syst´emu, na kter´e jsou napojeny skoro vˇsechny ostatn´ı moduly (viz sch´ema 5.1). Pr´avˇe zde se dˇeje zpracov´an´ı emailov´ych zpr´av podle zadan´e politiky.

Toto maj´ı za ´ukol jiˇz zm´ınˇen´e funkce ProcessOutgoingEmail (pro odchoz´ı zpr´avy), ProcessIncomingEmail (pro pˇr´ıchoz´ı) a ProcessConfigurationEmail (pro konfiguraˇcn´ı zpr´avy).

ProcessOutgoingEmail pracuje tak, ˇze si funkc´ıGetPolicy zjist´ı politiku pro dan´eho odesilatele a pˇr´ıjemce. Podle toho zpr´avu m˚uˇze zaˇsifrovat a podepsat. Takto upravenou zpr´avu vr´at´ı volaj´ıc´ımu.

U funkce ProcessIncomingEmailje to trochu sloˇzitˇejˇs´ı, nem˚uˇzeme ´uplnˇe pˇresnˇe vˇedˇet, co se se zpr´avou dˇelo. V´ıme ale, jak´y n´asleduj´ıc´ı krok m´ame prov´est, a to d´ıky tomu, ˇze pˇri ˇsifrov´an´ı a podepisov´an´ı se k v´ysledn´e zpr´avˇe pˇrid´avaj´ı hlaviˇcky ud´avaj´ıc´ı obsah zpr´avy (zaˇsifrovan´a/podepsan´a data). Dokud tedy ve zpr´avˇe nal´ez´ame takovou hlaviˇcku, prov´ad´ıme v cyklu pr´avˇe udanou operaci (deˇsifrov´an´ı nebo ovˇeˇren´ı podpisu) – t´ım vznikne vˇzdy nov´a zpr´ava s pˇr´ıpadnˇe jinou hlaviˇckou.

ProcessConfigurationEmail slouˇz´ı ovˇeˇren´ı, zda odesilatel m˚uˇze prov´adˇet danou kon-figuraˇcn´ı akci a pˇr´ıpadnˇe k vytvoˇren´ı odpovˇedi na ni. V´ıce o vzd´alen´e konfiguraci v ˇc´asti

5.3.

5.2.5 S´ıt’ov´y podsyst´em (network)

Toto je v podstatˇe pomocn´y modul pro nˇekter´e operace se s´ıt´ı. Asi nejvyuˇz´ıvanˇejˇs´ı zde defi-novan´e funkce jsouReadLineaWriteLine, jeˇz jsou d˚uleˇzit´e pˇredevˇs´ım z d˚uvodu

”ˇr´adkov´e filosofie“ poˇstovn´ıch protokol˚u. Z dalˇs´ıch d˚uleˇzit´ych funkcn´ı zmiˇnme jeˇstˇe snad ty urˇcen´e k pˇripojen´ı ke klientovi nebo k serveru.

5.2.6 Logov´an´ı (logger)

Tato ˇc´ast syst´emu slouˇz´ı k zaznamen´av´an´ı urˇcit´ych v´yznamn´ych ud´alost´ı na nastaven´a m´ısta. Konkr´etnˇe tˇemito m´ısty mohou b´yt textov´y soubor nebo emailov´a adresa.

U kaˇzd´eho takov´ehoto m´ısta je urˇcena minim´aln´ı priorita zpr´av, kter´e akceptuje, aby se napˇr´ıklad kv˚uli ozn´amen´ı nepodstatn´ych maliˇckost´ı nemusela hned pos´ılat zpr´ava. Pro pˇrehled priorit viz tabulku 5.2.

D˚uleˇzitost Pˇr´ıklad

1. Kritick´a nedostatek pamˇeti

2. Vysok´a pokus o podvrˇzen´ı podpisu

3. N´ızk´a ˇspatn´y form´at konfiguraˇcn´ı zpr´avy 4. Informace pˇripojen´ı klienta

5. Z´ˇadn´a pro lad´ıc´ı ´uˇcely

Tabulka 5.2: Pˇrehled priorit zpr´av k zaznamen´av´an´ı (ˇrazeno od nejvyˇsˇs´ı) 3

5.2.7 Zpracov´an´ı chyb (error)

V tomto modulu je vytvoˇren centr´aln´ı syst´em pro spr´avu chyb. Kaˇzd´a m´a sv˚uj jednoznaˇcn´y identifik´ator, kter´y m˚uˇze slouˇzit ke zkvalitnˇen´ı hl´aˇsen´ı o probl´emech. Tento syst´em jeˇstˇe nen´ı zaveden v cel´e aplikaci, tedy se zat´ım pˇr´ıliˇs nepouˇz´ıv´a, proto se j´ım v´ıce nebudu zab´yvat a odk´aˇzu ˇcten´aˇre na zdrojov´e texty a pˇr´ıpadnˇe na dalˇs´ı verze aplikace.

5.3

Vzd´

alen´

a konfigurace

Vzd´alen´a konfigurace je v t´eto implementaci pomˇernˇe silnˇe sv´az´ana s XML form´atem da-tab´aze. Pˇrin´aˇs´ı to velkou v´yhodu v jednoduchosti implementace, kdy si staˇc´ı exportovat ˇ

c´ast stromu dokumentu do ˇretˇezce a tyto ˇretˇezce jednoduˇse porovn´avat. Nev´yhoda je ta-kov´a, ˇze je t´ımto pˇredepsan´y form´at konfiguraˇcn´ıho emailu a pˇri zmˇenˇe datab´aze bude nutn´e pˇrepracovat i cel´y tento syst´em.

5.3.1 Konfiguraˇcn´ı zpr´ava

Pro konfiguraˇcn´ı email existuje nˇekolik pˇresnˇe dan´ych z´aleˇzitost´ı, kter´e mus´ı dodrˇzet: • Jeho pˇredmˇet mus´ı m´ıt pevnˇe dan´y obsah, a to CONFIG EMAIL.

• Pˇredevˇs´ım mus´ı m´ıt poˇzadovan´e zabezpeˇcen´ı, tj. b´yt podeps´an uˇzivatelem opr´avnˇen´ym spravovat dan´e nastaven´ı a b´yt zaˇsifrov´an veˇrejn´ym kl´ıˇcem proxy.

• Rovnˇeˇz po odˇsifrov´an´ı a ovˇeˇren´ı podpisu m´a zpr´ava pˇredepsanou strukturu, ta uˇz se ale liˇs´ı podle konkr´etn´ıho pˇr´ıkazu (viz n´asleduj´ıc´ı ˇc´ast).

5.3.2 Pˇr´ıkazy

Existuj´ı tˇri pˇr´ıkazy, kter´e lze vzd´alenˇe prov´est, a sice read, create a modify, kter´e jsou pops´any v n´asleduj´ıc´ıch podkapitol´ach.

´

Uroveˇn XML dokumentu, na kter´e prob´ıh´a konfigurace Funkce vzd´alen´e konfigu-race z d˚uvodu pˇr´ıliˇsn´e sloˇzitosti implementace neumoˇzˇnuje konfigurovat vˇsechny elementy XML dokumentu, ale je urˇcena ´uroveˇn, na kter´e zmˇeny prob´ıhaj´ı. Je moˇzn´e mˇenit jednou zpr´avou zmˇenit jeden element, konkr´etnˇe jeden z tˇechto:<user setting>,<domain setting>, <proxy setting>,<user keys> a <domain keys>.

Read

Tento pˇr´ıkaz slouˇz´ı k pˇreˇcten´ı specifikovan´eho elementu. Jako odpovˇed’ je textovˇe expor-tov´ana cel´a ˇc´ast stromu XML dokumentu. Napˇr´ıklad chceme-li pˇreˇc´ıst nastaven´ı urˇcit´eho uˇzivatele, funkce ProcessConfigurationEmailvr´at´ı textovˇe cel´y tag <user setting>.

Je vhodn´y zejm´ena pro spolupr´aci s pˇr´ıkazem modify, kter´y u modifikovan´eho tagu vyˇzaduje i starou verzi.

Tˇelo konfiguraˇcn´ıho emailu zde m˚uˇze vypadat napˇr´ıklad takto: <read>

<user>[email protected]</user> </read>

Create

Posl´an´ım tohoto pˇr´ıkazu m˚uˇzeme vytvoˇrit nov´eho uˇzivatele, dom´enu nebo veˇrejn´y kl´ıˇc. V pˇr´ıpadˇe ´uspˇechu vr´at´ı kladnou odpovˇed’ informuj´ıc´ı o ´uspˇeˇsn´em vytvoˇren´ı.

Pˇr´ıklad tˇela n´asleduje: <create> <user>[email protected]</user> <user_setting> <author>ADMINISTRATOR_EMAIL</author> <name>EP</name> <login>emperor.palpatin</login> <email>[email protected]</email> ... </user_setting> </create> Modify

Tento pˇr´ıkaz je ze vˇsech tˇr´ı nejsloˇzitˇejˇs´ı. Obsahuje identifikaci mˇenˇen´eho tagu, jeho p˚uvodn´ı verzi a jeho poˇzadovanou novou verzi. Informace o p˚uvodn´ı verzi zde je pˇredvˇs´ım z toho d˚uvodu, ˇze kdyby se jinak dva administr´atoˇri z´aroveˇn pokouˇseli zmˇenit ten sam´y tag, mˇelo by to velmi nepˇredv´ıdateln´e d˚usledky – oba by si mysleli, ˇze jejich nastaven´ı bylo aplikov´ano, ovˇsem v jednom pˇr´ıpadˇe by to nebyla pravda.

Tˇelo konfiguraˇcn´ıho emailu by mohlo vypadat napˇr´ıklad takto: <modify> <user>[email protected]</user> <old> <user_setting> <author>ADMINISTRATOR_EMAIL</author> <name>EP</name> <login>emperor.palpatin</login> <email>[email protected]</email> ... </user_setting> </old> <new> <user_setting> <author>ADMINISTRATOR_EMAIL</author> <name>EP</name> <login>emperor.palpatin</login> <email>[email protected]</email> ... </user_setting> </new> </modify>

Tag <author> Kaˇzd´y tag nastven´ı, kter´y m˚uˇze b´yt mˇenˇen, ma jako sv´eho potomka tag <author>. V nˇem mus´ı b´yt uvedena emailov´a adresa administr´atora, kter´y provedl posledn´ı zmˇenu.

Z´alohov´an´ı star´ych verz´ı konfiguraˇcn´ıho souboru Pˇri kaˇzd´e zmˇenˇe se XML soubor pro jistotu z´alohuje.