Úvod

Elektronická pošta patří k nejvyužívanějším službám internetu. Kromě standardního používání dochází k jejímu různému zneužívání: falšování odesilatele, hromadné rozesílání nevyžádané pošty, padělání obsahu zprávy aj. V tomto článku představíme některé postupy zabezpečení zpráv při odesílání z klientského programu na odesílající poštovní server. Cesta dopisu zpravidla vede z odesílajícího serveru na cílový, takže zabezpečení prvního úseku neznamená zabezpečení dopisu na celé jeho cestě, tj. od odesilatele až k příjemci.

Vysvětlení komunikace jsou doprovozena praktickými příklady, které slouží k ověření vlastního porozumění specifikovaným protokolům a k ověření deklarovaného chování poštovních aplikací.

Obecně o zabezpečení elektronické pošty

Přístup k poště můžeme rozdělit na dvě části: odesílání a příjem zpráv. Těmto částem odpovídají různé protokoly. Rozvoj webu vedl k zavedení webového rozhraní k poště (WebMail). Toto rozhraní využívá kombinace protokolů HTTP (HTTPS) a (E)SMTP.

Prakticky všechny protokoly musí řešit otázku ověřitelnosti totožnosti serveru a klienta, zabezpečení přenosu dat proti odposlechu šifrováním, a problém integrity (neporušenosti a totožnosti zpráv) - kontrolní součty, resp. otisky.

Protokoly SMTP a (E)SMTP nejsou v zásadě dosti bezpečné: nevyžadují ověření totožnosti odesilatele a nebrání jeho falšování. Obsah zprávy je přenášen v otevřeném (nezašifrovaném) tvaru a při nesprávné konfiguraci (E)SMTP serveru je možné zprávy rozesílat anonymně nebo pod falešným jménem na mnoho míst. Složitější formáty zprávy podle protokolu MIME mohou být zneužity k šíření virů a makrovirů.

Protokoly POP3 a IMAP pro přijímání zpráv ověřují totožnost uživatele, takže není možno ke schránce přistoupit anonymně. V základní podobě jde o nezašifrovanou komunikaci, proto je možné uživatelské heslo odposlechem zachytit.

Ochrana poštovní komunikace pomocí protokolů

V současné době existují protokoly a jejich realizace, které chrání komunikaci mezi poštovním klientem a poštovním serverem nebo poštovními servery navzájem.

Zabezpečení má chránit před:

• falšováním totožnosti serveru,
• odposlechem,
• pozměněním zprávy.

Ochrana je založena na různých kombinacích šifrování zpráv a ověřování totožnosti uživatele a serveru. Přitom se využívají nové porty. Zabezpečení je možné odstupňovat v závislosti na konkrétním prostředí a přijaté bezpečnostní politice.

Kromě šifrování a ověřování totožnosti odesilatele lze pro zabezpečení poštovní komunikace využít i umístění počítače v místní síti na základě IP adresy nebo doménového jména. Na odesílajícím poštovním serveru lze zvolit množinu IP adres, z nichž bude odesílání zpráv povoleno nebo zakázáno a ověřování totožnosti odesilatele nebude vyžadováno. Tato kontrola IP adresou však nemusí stačit.

Protokol ESMTP pro odesílání zpráv na portu 25 se využívá s ověřováním totožnosti (SASL), ale bez šifrování celé komunikace. Častější je odesílání zpráv s ověřováním totožnosti a šifrováním celé komunikace pomocí protokolu SSL/TLS na portu 465.

Pro příjem (stahování) zpráv se místo nezabezpečených verzí protokolu POP3 a IMAP užívají jejich zabezpečené (šifrované) varianty. Místo portu 110 se využívá port 995, místo portu 143 port 993, místo HTTP na portu 80 se užívá HTTPS na portu 443.

V dalším ukážeme na příkladech možnosti zabezpečení při přijímání a odesílání zpráv. Začneme bezpečnostními prvky obsaženými v protokolech POP3 a IMAP, protože jejich představení, zejména v protokolu POP3, je snazší.

Protokol POP3

Protokol POP3 umožňuje klientskému programu počítače, který není trvale připojen k internetu, stahovat nevyzvednutou poštu z POP3 serveru, který má přístup k poštovní schránce majitele účtu. Jiné složky než "došlá pošta" (inbox) nejsou přístupné.

Protokol je textový, používá se port TCP/110 a komunikace není šifrovaná. Po navázání spojení je nutné přihlášení jménem a heslem.

Hlavní příkazy POP3

Protokol lze realizovat ručně. Po navázání spojení s POP3 serverem se přihlásíme příkazem USER a vložíme heslo příkazem PASS. Prokázání totožnosti lze provést jedním příkazem APOP. První parametr je jméno uživatele a druhý je otisk MD5; vytváří se z identifikace relace a sdíleného hesla. Tím končí fáze ověření totožnosti.

V příkladu příkaz LIST vypíše seznam dopisů ve schránce, příkazem RETR získáme dopis a příkazem QUIT klient končí spojení. Příkaz LIST zahajuje fázi transakční. Když navíc zadáme DELE x, pak po QUIT přejde server do fáze aktualizace a odstraní zprávu ze schránky. Kladné odpovědi serveru se označují +OK, záporné -ERR.

Příklad

. . .

S: +OK pop.iol.cz POP3 server (Internet on Line) <44707571.b7c5f54@pop2>

K: USER opinkas

S: +OK password required for user   


K: PASS *********

S: +OK Maildrop ready

K: LIST

S: +OK scan listing follows

S: 1 1708

S: 2 1531

S: . . .

S: 9 4260

K: RETR 1

K: QUIT

Protokol IMAP

Tento protokol byl navržen pro práci se vzdálenou poštovní schránkou. Umožňuje zakládat a rušit složky, manipulovat s jednotlivými dopisy a přenášet dopisy podle výběru na místní počítač. Používá se port TCP/143 a komunikace není šifrovaná.

Protokol je textový a lze ho realizovat ručně. Po navázání spojení je nutné se k IMAP serveru přihlásit jménem a heslem.

Vzhledem ke složitosti protokolu se spokojíme jen s touto obecnou charakteristikou.

Odesílání zpráv bez zabezpečeného spojení s ověřením uživatele

Ověřování totožnosti v protokolu ESMTP - metody příkazu AUTH

Existují prostředky pro zabezpečení poštovní komunikace na portu 25 (mechanismus SASL) nebo šifrované spojení pomocí SSL/TLS na portu 465. Výborný výukový materiál věnovaný SMTP autentifikaci je přístupný na stránce FEHCOM.

Základní myšlenka je založena na ověření uživatele a jeho hesla. Uživatel musí být na SMTP serveru zaregistrován. Správce vytvoří účet, který zahrnuje jeho uživatelské jméno a heslo, poštovní adresu, občanské jméno a další kontaktní údaje.

Při komunikaci mezi klientem a serverem se na začátku ověřuje pomocí účtu, zda klient má právo poštovní server využívat. Vyhodnocuje se jméno a heslo. V záporném případě server komunikaci přeruší a vyzve k opravě zadaných údajů.

Jen ověřený uživatel může prostřednictvím svého ESMTP serveru poslat dopis do libovolné sítě a z libovolné sítě dopis přijmout. A to nezávisle na IP adrese počítače.

Ověření totožnosti je odstupňované podle míry zabezpečení jména a hesla. Příkaz AUTH má tyto metody: PLAIN, LOGIN, CRAM-MD5 a DIGEST-MD5.

Metody AUTH LOGIN a PLAIN

Metody AUTH LOGIN, resp. PLAIN jsou založeny na překódování uživatelského jména a hesla do base64. Metoda LOGIN je popsána v RFC 2554.

Metoda AUTH PLAIN (podle RFC 2595) používá jen jeden příkaz obsahující řetězec "authid\0userid\0passwd", kde \0 je slabika obsahující 8 bitových nul. Celý řetězec se potom zakóduje pomocí base64. Tento příkaz zasílá klient serveru jako jedinou řádku. "Authid" označuje ověřovací metodu, význam dalších proměnných je zřejmý.

Metody CRAM-MD5 a DIGEST-MD5 umožňují ověřit totožnost obou komunikujících stran. Vlastní obsah zprávy se přenáší na nezabezpečeném spojení.

Příklad ověření uživatele metodou LOGIN na nezabezpečeném spojení - port 25

. . .

(1) S: 250-AUTH=LOGIN

(2) S: 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5

(3) S: 250-8BITMIME

(4) S: 250 EHLO

(5) K: AUTH LOGIN

(6) S: 334 VXNlcm5hbWU6

(7) K: eXBpbmthcw==

(8) S: 334 UGFzc3dvcmQ6

(9) ***************

(10) 535 authentication failed: incorrect password or account name

. . .

Server oznamuje podporované metody ověření totožnosti (2). Vybrali jsme metodu LOGIN (5). Server vyzval (6) v kódování base64 k zadání uživatelského jména řetězcem VXNlcm5hbWU6 - po dekódování Username:. Klient v kódování base64 zaslal přihlašovací jméno (7), server v (8) poslal kódovaně výzvu Password: (UGFzc3dvcmQ6) a klient poslal heslo zakódované v base64 (9). Pokus o ověření totožnosti nebyl úspěšný (10). Neúspěch byl způsoben tím, že poštovní server své jednoduché bezpečnostní metody oznamoval, ale fakticky je nepřipouštěl. Správcům právem připadaly slabé.

Nevýhodou metod PLAIN a LOGIN je, že se heslo přenáší nezabezpečeným spojením jako čistý text. Spojení lze odposlechnout a získané heslo zneužít. Mají-li se obě metody použít, je třeba použít šifrovaný přenos mezi klientem a serverem, který zabezpečí všechna přenášená data, včetně hesla. Chceme-li bez šifrování celého spojení na portu 25 použít nějakou bezpečnější metodu ověření totožnosti, musíme zvolit metodu CRAM-MD5 nebo DIGEST-MD5.

Metoda ověření totožnosti CRAM-MD5

Metoda CRAM-MD5 podle RFC 2195 patří do skupiny "výzva/odpověď". Výzvy zasílá server. V každé relaci vytvoří výzvu, což je jedinečný text přiřazený relaci a zaslaný klientu v kódování base64.

Klient vytvoří kontrolní součet z hesla uživatele (klíč nebo také sdílené tajemství) a výzvy. Dále vytvoří kontrolní součet ze samotného hesla. Nakonec vytvoří kontrolní součet z obou dílčích výsledků a tak vznikne celkový kontrolní součet. Jako odpověď pak zašle v base64 nešifrované jméno uživatele spojené pomocí oddělovače \0 s kontrolním součtem.

Poštovní klient i poštovní server musí metodu CRAM-MD5 podporovat. Klient Kmail ji podporuje, a tak se podařilo odeslat dopis na školní poštovní server. V zásadě je možné celou komunikaci vysledovat, omezíme se jen na některé důležité údaje.

. . .

(5) K: AUTH CRAM-MD5

(6) S: 334 PDE0MjgzNi4xMTg0ODU4ODA4QHZzZS5jej4=           (výzva base64)

. . .

Řetězec PDE0MjgzNi4xMTg0ODU4ODA4QHZzZS5jej4= je výzvou serveru k zadání odpovědi. Po dekódování dostaneme <142836.1184858808@vse.cz>.

Výzva má dvě části: první je jednoznačný a náhodně vygenerovaný číselný identifikátor (před @), druhá má být úplné označení počítače; v tomto případě je uvedeno jen jméno domény.

Identifikátor se často vytváří z čísla běžícího procesu a časového razítka. Celá výzva je jednorázová a je svázána s daným spojením (relací). Nové spojení bude mít novou jedinečnou výzvu.

V tomto okamžiku sdílejí server i klient jednu společnou tajnou informaci, tj. výzvu. Mají i další, tou je heslo uživatele (klíč). Pomocí hashovací funkce, často MD5, klient spočítá kontrolní součet (jinak také otisk, miniatura) z hesla uživatele a výzvy. Dále vytvoří kontrolní součet ze samotného hesla. A nakonec spočítá kontrolní součet z obou dílčích kontrolních součtů.

Odpovědí klienta na obdrženou výzvu bude jméno uživatele spojené s celkovým kontrolním součtem v kódování base64.

Server odpověď klienta ověří. Zkontroluje jméno uživatele a spočítá kontrolní součet. Z účtu získá heslo, výzvu sám odeslal a přiřadil relaci, metoda výpočtu kontrolního součtu byla dohodnuta. Jestliže je kontrolní součet zaslaný klientem a vypočítaný serverem shodný, je totožnost uživatele prokázána a relace pokračuje.

Z uvedeného popisu plyne, že se heslo nepřenáší, tj. zůstává skryto, což je hlavním cílem těchto metod.

Obecný tvar vzorce pro výpočet kontrolního součtu podle příkladu z RFC je tento:

digest = MD5(('secret' XOR opad), MD5(('secret' XOR ipad), challenge))

Kontrolní součet (digest) je jedinečný řetězec 128 bitů (16 bytů) pro každou zpracovanou zprávu. Řetězec 'secret' je heslem. Challenge je výzva (nedekódovaná). XOR je logická operace, která má výsledek "pravda", jen když jeden výrok je pravdivý a druhý nepravdivý. Opad a ipad jsou znaky pro doplnění hesla na stanovenou délku. Pro RFC 2104 jsou různé.

V našem případě zašle klient kontrolní součet dlouhý 16 bytů s hodnotou vypočtenou podle vzorce:

kontrolní součet = MD5(('tajemstvi' XOR opad), MD5(('tajemstvi' XOR ipad), <  
>))

Zabezpečení přenosu zpráv pomocí SSL/TLS

Pomocí metody CRAM-MD5 ověříme totožnost uživatele a kontrolním součtem se vyhneme přenosu jeho hesla, ale vlastní obsah zprávy se přenáší nešifrovaně, tj. zpráva není chráněna proti odposlechu.

Již v r. 1996 společnost Netscape zveřejnila specifikaci SSL 3.0, která měla obecně řešit přenos aplikačních dat zabezpečeným kanálem. Cílem bylo zabezpečit hlavně obchodní a bankovní operace před podvržením identity, odposlechem zpráv a před změnou jejich obsahu. Zabezpečení přenášených dat se dociluje šifrováním komunikace mezi klientem a serverem.

Protokol SSL (secure socket layer) představuje novou vrstvu mezi vrstvou aplikačních protokol a přenosových protokolů pro přenos dat (pro nás TCP). Sám je také vrstevnatý: horní vrstva se jmenuje Handshake Protocol (HP), spodní Record Protocol (RP). První vrstva je doplněna o pomocné protokoly Change Cipher Spec Protocol a Alert Protocol.

SSL Handshake Protocol – vyjednávání bezpečnostních parametrů

Úkolem HP je vytvořit bezpečnou SSL relaci mezi komunikujícími stranami. Jedná se o vyjednání a nastavení bezpečnostních parametrů klienta a serveru. Vyjednávání probíhá v několika fázích:

1. Ověření totožnosti (důvěryhodnosti) serveru.
2. Volba vzájemně přijatelných šifrovacích algoritmů.
3. Prokázání totožnosti (důvěryhodnosti) klienta – nepovinná operace.
4. Pomocí šifrování s použitím veřejných klíčů si klient a server vymění šifrovací parametry (sdílené tajemství).
5. Zahájení SSL relace.

SSL protokol má dva hlavní stavy: SSL relace a SSL spojení.

SSL relace je charakterizována parametry:

• Stav relace (session ID): jeden byte pro označení stavu SSL relace.
• Certifikát: certifikát druhé strany podle X509.v3
• Kompresní metoda: metoda zhušťování přenášených dat.
• Šifrovací algoritmy: výčet šifrovacích algoritmů a algoritmů pro výpočet kontrolních součtů pro použití při přenosu aplikačních dat.
• Hlavní tajemství (master secret): data sdílená jen klientem a serverem – slouží k určení dalších odvozených tajných hodnot.
• Znovupoužitelnost: příznak, zda mohou být nastavené bezpečnosti parametry použity i v dalších SSL spojeních.

SSL spojení je charakterizováno parametry:

• Náhodné číslo vygenerované serverem a náhodné číslo vygenerované klientem.
• Tajemství pro výpočet kontrolního součtu používané serverem (server write MAC secret).
• Tajemství pro výpočet kontrolního součtu používané klientem (klient write MAC secret).
• Symetrický šifrovací klíč, kterým šifruje server (server write key).
• Symetrický šifrovací klíč, kterým šifruje klient (klient write key).
• Inicializační vektory (IV) používané pro blokové šifry.
• Číslo přijaté a číslo odeslané zprávy.

Jedna SSL relace se může skládat z několika SSL spojení. To znamená, že se používají stejné parametry SSL relace (kompresní metoda, šifrovací algoritmy, hlavní tajemství) v různých spojeních, ale mohou se měnit tajemství pro výpočet kontrolních součtů nebo symetrické šifrovací klíče v jednotlivých spojeních.

Každá SSL relace má čtyři možné stavy. Rozlišují se přípravný a aktuální stav. V přípravném stavu jsou nastaveny hodnoty parametrů pro výběr šifrovacích algoritmů a výběr metod pro výpočet kontrolních součtů. V aktuálním stavu se právě uvedené hodnoty parametrů nenabízejí. Změnu nabídky šifrovacích algoritmů obstarává pomocný protokol Change Cipher Spec. V okamžiku ukončení HP se přípravný stav stane stavem aktuálním.

Zprávy protokolu HP

Seznámili jsme se s hlavními fázemi protokolu HP. Každá z nich je realizována určitými příkazy – zprávami. Příkazy mají svá jména a specifické parametry, např. Client-Hello a Server-Hello. Zpráva se skládá z částí: typ, délka a obsah. Typ označuje druh zprávy, např. Client-Hello.

Client-Hello

V první fázi klient SSL zahajuje relaci příkazem Client-Hello. Předává serveru:

• nejvyšší jím podporovanou verzi protokolu SSL,
• identifikátor SSL relace,
• náhodně jím vygenerované číslo,
• seznam jím podporovaných algoritmů pro symetrické a asymetrické šifrování a hashovacích funkcí,
• seznam jím podporovaných kompresních algoritmů.

Jedná se vlastně o nabídku klienta serveru, z níž si server vybere tak, aby obě strany používaly v komunikaci stejné prostředky. Zpráva není šifrovaná.

Server-Hello

Odpověď serveru Server-Hello je zpráva, která má prakticky stejné parametry jako zahajovací zpráva klienta. Server posílá svůj výběr hodnot parametrů z nabídky klienta a své náhodné číslo. Položky seznamu šifrovacích algoritmů, hashovacích funkcí a seznamu kompresních metod budou využívány pro nastavení konkrétního spojení.

Server certificate

Po počátečním „pozdravu“ server prokazuje klientu svou totožnost zprávou „server certificate“. Součástí certifikátu je doménové jméno serveru a jeho veřejný klíč. Server může požádat klienta o prokázání jeho totožnosti, ale klient tuto povinnost nemá. Své představení server ukončí zprávou „server hello done“.

Client_key_exchange

Nevyžaduje-li server od klienta zaslání jeho certifikátu, klient může odpovědět hned zprávou „client_key_exchange“. Ta obsahuje „pracovní tajemství“ (pre-master-secret) vytvořené klientem. Protože jde o tajemství obou stran, musí být tato zpráva šifrována. Klient využije veřejný klíč serveru a pomocí dohodnutého algoritmu „pracovní tajemství“ zašifruje a zprávu odešle. Server dešifruje obsah zprávy svým soukromým klíčem.

Nyní mají obě strany k dispozici tajnou šifrovanou informaci. Ta se stává součástí vzorce pro výpočet hlavního tajemství (master secret). Hlavní tajemství je vlastně kontrolní součet, který si každá strana vypočítá z údajů vlastních a z údajů obdržených od svého protějšku. Součástí vzorce pro výpočet hlavního tajemství jsou hashovací funkce (MD5 a SHA), náhodně generovaná čísla z Hello obou stran a „pracovní tajemství“ (pre-master-secret).

Hlavní tajemství se spolu s náhodnými čísly z příkazů ClientHello a ServerHello využívá k výpočtu bloku klíčů (key-block). Z tohoto bloku klíčů klient i server oddělují své části. Tajemství pro výpočet kontrolního součtu klientem podepisovaného bloku dat (client-write-MAC-key) a serverem podepisovaného bloku dat (server-write-MAC-key). Dále se oddělí šifrovací klíč klienta (client-write-key) a šifrovací klíč serveru (server-write-key) a nakonec inicializační vektory.

Po rozdělení bloku klíčů mají klient i server k dispozici svá tajemství pro výpočet kontrolního součtu podepisovaného bloku dat a své šifrovací klíče pro šifrování dat. Klíče jsou klíči symetrické kryptografie, takže stejný klíč slouží k šifrování i dešifrování zprávy.

Pomocí zprávy typu „změna specifikace klíče“ se klient i server navzájem informují, že příští zprávy od klienta/serveru budou šifrovány symetrickým klíčem. Zpráva „finished“ zaslaná klientem po zprávě „změna specifikace klíče“ oznamuje, že nastavení parametrů SSL relace bylo dokončeno. Svou zprávu typu „změna specifikace klíče“ následovanou zprávou „finished“ zašle také server.

Když server šifruje data odesílaná klientovi, používá svůj symetrický klíč. Obdobně i klient. Algoritmy symetrického šifrování umožňují pomocí jednoho klíče šifrovat i dešifrovat zprávu.

Přenos dat v SSL - Record Protocol (RP)

Struktura věty

Všechna přenášená data v SSL je nutno přenášet po větách. Věta se skládá ze záhlaví a vlastních dat. Záhlaví obsahuje pole typ, verze a délka věty. Pole „typ“ udává povahu dat: change_cipher_spec, alert, handshake, application_data. Pole „verze“ obsahuje označení hlavní a vedlejší verze protokolu SSL. Pole „délka“ vyjadřuje délku celé věty. Její maximální délka je omezena s ohledem na potřeby šifrování.

Datová část věty

Aplikační data se pro potřeby přenosu v RP upravují:

• dělí se na kratší části - fragmenty,
• fragmenty se mohou komprimovat,
• k fragmentu se připojí jeho ověřovací kód,
• fragment s ověřovacím kódem se zašifruje.

Dělení dat se provádí na nezašifrovaném (prostém) textu a maximální délka části je menší nebo rovna 2¹⁴bytů (16384). Každé části je přiřazeno pořadové číslo. Část se může komprimovat takovým algoritmem, který byl zvolen během počátečního dialogu v HP.

Připojení ověřovacího kódu části dat

Jedná se o dynamicky vytvořený kód. Každá část má svůj jedinečný kód, který se vypočítává podle vzorce s více komponentami. Výsledkem je vlastně kontrolní součet části dat.

Během výpočtu ověřovacího kódu se několikrát použije hashovací algoritmus. Do výpočtu vstupuje tajemství pro výpočet kontrolního součtu klientem podepisovaného bloku dat dohodnuté během HP. Hashovací algoritmus je ten, který byl přijat ve fázi HP. Používají se algoritmy MD5 nebo SHA, jejichž kontrolní součty jsou dlouhé 128 a 160 bitů. Ve vzorci se vyskytují ještě další zpracovávané údaje (např. doplňovací znak pro blokové šifrování, pořadové číslo části dat, aj.).

Každá věta protokolu RP s ověřovacím kódem se podle potřeby doplní na pevnou délku a následně zašifruje.

Symetrické šifrování

Symetrické šifrování rozeznává šifrování dat po blocích nebo v proudu. Šifrování po blocích převádí jeden blok pevné délky nešifrovaného textu na zašifrovaný blok stejné délky. Šifrovací algoritmus používá tajný klíč definovaný uživatelem. Pro většinu šifrovacích algoritmů je délka bloku 64 nebo 128 bitů. Existují různé algoritmy symetrického šifrování po blocích, které používají klíče různé délky. Příklady: IDEA (128 bitů), DES (40, resp. 56 bitů), 3DES (168 bitů). Algoritmus pro proudové šifrování RC4 používá klíče délky 40 nebo 128 bitů.

Jestliže se šifruje po blocích, může nastat situace, že poslední blok dat má délku 1. V takovém případě se doplní zvoleným znakem na délku bloku. Doplněný koncový blok se pak snadněji dešifruje.

V SSL se převádějí na věty RP i zprávy protokolu HP a CCSP, tj. řídící příkazy pro nastavení komunikačních parametrů SSL a stanovení bezpečnostních prvků. Výpočty ověřovacího kódu dat, doplňování bloků a šifrování se však neprovádí.

Ověření uživatele metodou LOGIN a ruční odeslání dopisu na zabezpečeném spojení - port 465

Praktické ověření možnosti ručního odeslání dopisu pomocí protokolu ESMTP s použití jednoduchého zabezpečení metodou AUTH LOGIN na portu 25 se nám v předchozím příkladu nezdařilo. Nový pokus je založen na použití nového nástroje, programu „openssl“, který podporuje SSL. Místo portu 25 je nastaven port 465.

Zpracování probíhá v několika krocích:

1. Navázání spojení ze stanice lokální sítě na server „veverka“ na portu 465.
2. Přijetí certifikátu serveru a ohlášení chyby – pro klienta není došlý certifikát na seznamu důvěryhodných certifikátů a klient se nemůže odvolat na platný řetěz certifikačních autorit.
3. Přijetí zpráv SSL – vytvoření relace.
4. Představení klienta ESMTP a pokus o autentifikaci AUTH LOGIN.
5. Zpráva serveru s kódem 235 o úspěšném ověření totožnosti uživatele.
6. Vkládání příkazů ESMTP pro odeslání dopisu na zabezpečeném kanálu.

Zahájení relace s poštovním serverem pomocí programu OpenSSL

C:\>openssl s_client -connect veverka.vse.cz:465

Zprávy o certifikátech a certifikát poštovního serveru

Loading 'screen' into random state - done

CONNECTED (00000780)

depth=0   
/C=CZ/ST=Czech republic/L=Prague/

O=University of Economics/OU=Vypocetni centrum/CN=veverka.vse.cz

verify error:num=20:unable to get local issuer certificate

. . .

Certificate chain

0 s:  
/C=CZ/ST=Czech republic/L=Prague/

O=University of Economics/OU=Vypocetni centrum/CN=veverka.vse.cz

i:  
/C=CZ/ST=Czech republic/L=Prague/

O=University of Economics/OU=Certification Authority/CN=VSE CA

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIEuDCCA6CgAwIBAgIKcaFwygABAAACUjANBgkqhkiG9w0BAQUFADCBpjEYMBYG

Oam58EahkWkJ/szmAjw/KRt9c/Oo+SVxD0rOIfCHy4pwr8d8RJhMe6A0PZ/P7GLH

. . .

Mk6AEXh7cXn0Oae0nFYm+GHgK/5gAZUN9BQtJ/e5OB4k9xMP7AL+eO6RlKZuQ0Hx

1HmNzph59epwyM9H

-----END CERTIFICATE-----

---

No client certificate CA names sent

Nastavení parametrů relace v SSL

SSL handshake has read 1366 bytes and written 250 bytes

---

New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA

Server public key is 512 bit

SSL-Session:

Protocol  : TLSv1

Cipher    : DES-CBC3-SHA

Session-ID: 0003B2D7468B6A67535353535353535353535353535353535353535353535353

Session-ID-ctx:

Master-Key: C51EBE53A37AC6FC164E9504568A46369F0089ACC458019894D6E49C7563D9EE241CDAF729329B3E5BD1B44DA107D835

Key-Arg   : None

Start Time: 1183541862

Timeout   : 300 (sec)

Verify return code: 21 (unable to verify the first certificate)

Příkazy ESMTP, ověření uživatele a odeslání dopisu na zabezpečeném kanálu

220 vse.cz ESMTP CommuniGate Pro

EHLO nb371h04.znet.vse.cz

250-vse.cz is pleased to meet you

250-HELP

250-PIPELINING

. . .

250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5

250-8BITMIME

250 EHLO

auth login

334 VXNlcm5hbWU6

eXBpbmthcw==

334 UGFzc3dvcmQ6

bWlzcjE5dHJz

235 ypinkas relaying authenticated

mail from:   


250   
 sender accepted

rcpt to:   


250   
 will forward

data

354 Enter mail, end with "." on a line by itself

from:   


to:  


date: Jul 4, 2007

subject: as na vev ruc port 465 openssl

Posílám dopis z as přes veverku na pinkas at vse.cz. OpenSSL port 465.

.

250 27359748 message accepted for delivery

.

QUIT

DONE

Závěr

Odesílání zpráv z poštovního klienta na ESMTP server na základě ověření totožnosti odesilatele zabraňuje šíření zpráv pod falešným jménem dále do internetu. Jednoduchá autentizace jménem a heslem (AUTH LOGIN nebo PLAIN) s využitím kódování base64 nestačí. Je-li však kombinována s protokolem SSL/TLS, pak bývá podporována, protože po počátečním vyjednávání se ověří totožnost přinejmenším serveru a celá komunikace je zašifrovaná.

Bezpečnější formu ověřování totožnosti představuje mechanismus CRAM-MD5. Na základě metody výzva/odpověď přenáší pouze kontrolní součet z informací známých jen oběma stranám: heslo se v prosté podobě na komunikačním kanálu vůbec neobjeví. Pomocí metody CRAM-MD5 se podařil přenos dopisu na ESMTP server na tradičním portu 25.

Pokusy s autentizací a zasíláním zabezpečených zpráv v konkrétních podmínkách umožňují provádět volně šiřitelné programy jako PuTTY nebo OpenSSL.