Elektronická pošta - architektúra - csirt.gov.sk · tvorené iba ASCII znakmi! o Záhlavie sa...

Elektronická pošta - architektúra

Základná predstava architektúry elektronickej pošty na Internete pochádza z polovice 70. rokov. Dnes je základom poštovej komunikáce na Internete norma RFC-821 z roku 1982 (tvar poštovej správy opisuje RFC-822).

Vtedy používatelia sedeli pri termináli, z ktorých spúšťali poštových klientov (nemá nič spoločného so sieťovou komunikáciou), poštový klient bol v podstate iba špecializovaný textový editor, ktorý:

o vie používateľovi zobrazit obsah správy z poštovej schránky o vie manipulovať so správami v poštovej schránke a to isté vie tiež s privátnymi

poštovými schránkami používateľa o Môže správu vytvoriť a odoslať (opäť odoslaním sa nerozumie žiadna sieťová

komunikácia, ale uloženie správy do frontu správ). Front správ je pravidelne prechádzaný klientom SMTP (Simple Mail Transfer

Protocol), ktorý nadväzuje spojenie so vzdialenými servermi SMTP, ktorým správu odovzdá.

Server SMTP príjme správu a zisťuje, či je určená pre jeho lokálneho používateľa. o V prípade, že nie - správu opät uloží do poštového frontu, ktorý obsluhuje jeho poštový

klient, ktorý se pokúša správu doručiť smerom k adresátovi. o V prípade, že adresát je lokálnym používateľom systému - server SMTP uloží prijatú

správu do poštovej schránky adresáta. Používateľ má v systéme spravidla jednu poštovú schránku INBOX, kam server

SMTP ukladá jeho prichádzajúcu poštu. Poštová schránka sa nemenuje INBOX ako súbor, ale spravidla má meno rovnaké s menom používateľa. Názov INBOX pre ňu používá protokol IMAP4.

2

Elektronická pošta – architektúra, elektronická pošta pri mainframe

3

poštový klient Používateľ A pri termináli Front klient SMTP

poštový klient Používateľ B pri termináli server SMTP

TCP spojenie na port 25

Počítač odosielateľa

Počítač príjemcu

Poštová schránka

používateľa "INBOX"

Privátne poštové schránky

používateľ.

Front

klient SMTP

TCP spojenie na port 25


Okrem toho si používateľ môže zriadiť aj privátne poštové schránky, kam si ukladá zo schránky INBOX došlú poštu.

o Privátne poštové schránky nie sú obsluhované serverom SMTP a bývajú zriaďované v domovskom adresári používateľa. Cieľom je primäť používateľa k tomu, aby v „systémovej“ schránke INBOX prichádzajúcu poštu nearchivoval.

Internetová pošta má vďaka ukladaniu odchádzajúcej pošty do frontu a ukladaniu prichádzajúcej pošty do poštovej schránky jednu zásadnú vlastnosť.

o Používateľ môže „odoslať“ mail, ktorý si príjemca môže vyzdvihnúť zo svojej schránky až bude chcieť. Tj. nie je nevyhnutné okamžite nadväzovať spojenie na príjemcov systém v dobe odosielania pošty.

o Príjemcov systém môže byť i vypnutý v dobe, kedy odosielateľ správu odosiela. Ak sa klientovi SMTP nepodarí odoslať poštu, tak ju ponechá vo fronte. Správa bude vo fronte čakať maximálne dobu, ktorú nastaví správca systému na 2-7 dní. Potom sa pošta vracia odosielateľovi ako nedoručená.

S odosielaním správy je to ešte komplikovanejšie. SMTP klient nemôže odoslať správu z mnoho dôvodov. Je na správnej konfigurácii, aby v podstate rozlišovala medzi dvomi situáciami:

o Momentálne napr. nie je možné poštu ďalej doručiť, ale je pravdepodobné, že za istú dobu to pôjde (napr. meno cieľového systému sa preložilo v DNS, ale systém je nedostupný).

o Správu nie je možné doručiť pre chybu, ktorú nie je možné odstrániť (napr. meno vzdialeného systému je správne, ale uvedený adresát na systéme neexistuje). V takomto prípade je treba správu nedržať vo fronte, ale okamžite vrátiť odosielateľovi. 4


Na obrázku je znázornené fungovanie „klasickej“ elektronickej pošty na sálových počítačoch (mainframe):

o Používateľ A chce odoslať správu elektronickou poštou používateľovi B. Používateľ A pomocou svojho poštového klienta vyhotoví správu a vyhotovenú správu „odošle“, ale odoslanie je iba uloženie správy do frontu.

o Klient SMTP prechádza front až narazí na našu správu. Správu sa pokúsi doručiť na adresátov systém, pokiaľ sa mu to nepodarí, tak správu ponechá vo fronte.

o V prípade, že server správu príjme, potom skúma, či je adresát správy lokálnym požívateľom systému, ak áno - správu uloží do jeho poštovej schránky. V prípade, že nie - správu uloží do frontu na odoslanie ďalej (správu vráti odosielateľovi).

o Príjemca si potom môže prijatú správu spracovať svojím poštovým klientom. S príchodom osobných počítačov prišiel zvrat i v používaní elektronickej pošty.

o Vo svojej podstate elektronická pošta zostala zachovaná, ale používateľ už nechce sedieť pri termináli poštového servera (aj keď emulovaného protokolom Telnet na svojom PC), ale chce využívať aplikácie na svojom PC. Otázkou je, ako z PC poštu odoslať a ako na PC poštu prijať.

Pri odosielaní pošty z PC je možné vcelku bez problému opäť použiť protokol SMTP, tak pre príjem pošty z poštovného servera na PC nie je protokol SMTP tým pravým. Prečo?

o Príjemca má svoje PC zapnuté spravidla iba niekoľko hodín. Mimo tejto doby by zostávala pošta v odosielateľovom fronte a príjemcov systém by sa javil ako nedostupný. Ďalším problémom je, že na príjemcovom PC by musel bežať SMTP server. Zvolila se preto iná stratégie znázornená na nasledujúcom obrázku. 5

Elektronická pošta – architektúra, protokoly POP3 a IMAP4

6

SMTP agent

(vzdialený systém)

Front

poštový klient Používateľ pri termináli

Poštová schránka

používateľa "INBOX"

SMTP agent

SMTP Poštový server

Používateľ pri PC

Privátne poštové

schránky používateľ.

Privátne poštové schránky

používateľa

IMAP4

IMAP4

SMTP POP3/

IMAP4


Používateľ má svoju príchodziu poštovú schránku (INBOX) na poštovom serveri. T.j. z hľadiska protokolu SMTP je poštový server cieľovou stanicou. Zostáva vyriešiť, ako si vyberať INBOX zo svojho PC.

Pre prácu s poštovou schránkou používateľa na poštovom serveri sú k dispozícii dva protokoly (oba sú podporované klientami Microsoft a tiež Netscape):

o Protokol POP3. Ide o veľmi jednoduchý protokol, s ktorým pracuje používateľ OffLine. Tj. z poštového servera si používateľ stiahne prichádzajúcu poštu na svoje PC a ukončí TCP spojení so serverom. Až po stiahnutí pošty používateľ pracuje s jednotlivými poštovými správami. V prípade, že chce používateľ poštu odoslať, potom použije protokol SMTP.

o Protokol IMAP4. Ide o komplikovaný protokol, ktorý umožňuje nielen pracovať OffLine, ale i OnLine. Používateľ môže mať nadviazané spojenie s poštovým serverom dlhšiu dobu a byť serverom priebežne informovaný o zmenách vo svojej poštovej schránke. Protokol IMAP4 umožňuje tiež pracovať s privátnymi poštovými schránkami priamo z terminála na serveri. Protokolom IMAP4 je možné tiež synchronizovať poštové schránky na PC a na serveri. Schránky na serveri tak zostávajú zálohou schránok na PC. V prípade, že chce používateľ poštu odoslať, potom tiež použije protokol SMTP. Použitie protokolu IMAP je praktické najmä v prípade, že občas chceme pracovať z PC a občas z terminálu servera.

Otázkou je kedy zvoliť POP3 a kedy IMAP4. Odpoveď je: ako kedy. o Napr. pre veľkých poskytovateľov internetových služieb je veľmi výhodný protokol

POP3, pretože pošta nezostáva na serveri. Používatelia si ju sťahujú na svoje PC. Pri predstave, že sto tisíc používateľov má trvale svoju poštu na serveri, potom žiadna disková kapacita nie je dostatočná pre také ohromné množstvo dát (príležitosť pre malých poskytovateľov).

7


o Naopak pre menšie firmy je výhodný protokol IMAP4, pretože se tým vykonáva záloha poštových schránok. A je jednoduchšie zálohovať jednu diskovú kapacitu, než aby si to robil každý požívateľ sám. Pritom strata obsahu poštovej schránky môže pre vedúceho pracovníka spôsobiť i veľké ekonomické škody. Je proto nevyhnutné pri použití protokolu POP3 dbať na to, aby pošta bola zálohovaná napr. na server, na disky či na magnetickú pásku.

Na obrázkoch nie je uvádzané slovo poštový server, ale SMTP agent. Je to preto, že na poštovom serveri je vždy SMTP klient pre odosielanie pošty a SMTP server pre príjem pošty. Naviac softvér poštového klienta musí v pravidelných intervaloch precházať front a jeho položky sa snažiť odoslať. Tj. jedná sa o službu (resp. démona), ktorý stále beží. A iba v okamžiku odosielania jednej položky frontu sa tento démon chová z hľadiska protokolu TCP ako klient.

8

Elektronická pošta – architektúra, prípad veľkých ISP

9

Front

Poštová

schránka

používateľa

"INBOX"

SMTP agent

SMTP

Poštový server

SMTP agent (vzdialený systém)

Používateľ pri PC

POP3

SMTP

Privátne

poštové

schránky

používateľae

Elektronická pošta – formát poštovej správy

Formát poštovej správy je špecifikovaný normou RFC-822. Správa sa skladá zo záhlavia a tela správy. Záhlavie je od tela správy oddelené jedným prázdnym riadkom (CRLF CRLF). Záhlavie i telo správy sú tvorené iba ASCII znakmi!

o Záhlavie sa skladá z jednotlivých hlavičiek. Hlavička začína kľúčovým slovom ukončeným dvojbodkou. Za kľúčovým slovom môžu nasledovať parametre. Hlavička sa ukončuje koncom riadku, tj. CRLF (Carriage Return Line Feed).

o Medzi jednotlivými časťami hlavičky môžu byť vkladané medzery a tabelátory. Hlavička môže pokračovať na ďalšom riadku. Ďalší riadok však v takomto prípade musí začínať medzerou alebo tabelátorom (kľúčové slovo hlavičky musí byť odsadené od prvej pozície riadku).

o Najmä v adrese majú dôležitý význam nasledujúce znaky: Bodkočiarka a dvojbodka majú význam oddeľovača v zozname. Napr. pri

oddeľovaní jednotlivých adresátov v hlavičke TO. Ostré zátvorky <> majú špeciálny význam v adrese. Ak sa vyskytuje v adrese

reťazec v ostrých zátvorkách, potom sa všetko mimo tento reťazec ignoruje – za adresu sa vezme reťazec z ostrých zátvoriek.

Hranaté zátvorky [ ] majú význam v mene počítače; signalizujú, že meno počítače nemá byť prekladané v DNS.

Do guľatých zátvoriek ( ) sa uzatvára komentár.

10

Elektronická pošta – Prehľad základných hlavičiek z RFC-822

11

Elektronická pošta – Prehľad základných hlavičiek z RFC-822

12

Elektronická pošta – základná štruktúra správy (jednoduchá správa)

Najčastejšie používané hlavičky sú: o From (Od) o To (Komu) o Subject (Predmet) o Date (dátum)

Ďalšou bežne sa vyskytujúcou hlavičkou v záhlaví podľa [RFC 5322] je Message ID (ID správy). Táto hlavička obsahuje jedinečný identifikátor spojený s touto správou.

13

Elektronická pošta – MIME

Formát správ protokolu SMTP definovaný normou RFC-822 umožňoval prenášať data iba vo formáte US-ASCII. Skoro sa však ukázalo, že tento štandard nevyhovuje mnohým požiadavkám používateľov, ktorí chcú elektronickú poštu využiť i na posielanie textu iných znakových sád, formátovaného textu, obrázkov, zvukov, všeobecne binárnych súborov atď. V poslednej dobe potom prišla požiadavka na posielanie zabezpečených správ, tj. šifrovaných správ alebo elektronicky podpísaných správ.

Požiadavky používateľov rýchle prekročili možnosti ponúkané normou RFC821. Objavilo sa tak rozšírenie MIME (Multipurpose Internet Mail Extension) dnes specifikované normami RFC-2045 až 2049.

o Problém ako poslať elektronickou poštou správu obsahujúcu iné data než text v kóde US-ASCII je možné riešiť i bez MIME. Znamená to správu pred odoslaním zakódovať do US-ASCII. Príjemca potom musí najprv správu dekódovať a až potom ju môže spracovať (prečítať). Odosielateľ a príjemca sa musia inou cestou dohodnúť na type kódovaní prenášaných dat do US-ASCII. V praxi sa spravidla používa kódovanie base64, Quoted Printable alebo v UNIXe kódovanie UUENCODE. Skúsený príjemca sa podíva na zakódované data a na prvý pohľad vidí ako sú data zakódované a podľa kódovania sa rozhodne použiť vhodný dekódovací program na prijaté data pred tým, než ich bude spracovávať (napr. čítať).

o Táto cesta je pre bežných používateľov neprijateľná. Používateľ si nepraje sa nejakým kódovaním zaoberať – praje si, aby tieto problémy za neho vyriešil softvér poštového klienta sám. Pre bežného používateľa je tak prijateľná druhá možnosť spočívajúca v myšlienke rozšíriť repertoár hlavičiek správy o hlavičky opisujúce typ prenášaných dat a algoritmus, ktorým boli data pred odoslaním zakódovené do US-ASCII. Opis dodatočných hlavičiek špecifikuje práve norma MIME.

14

Elektronická pošta – MIME

V tomto prípade môže príjemcov softvér z hlavičiek automaticky rozpoznať, ako boli data kódované, a automaticky správu dekódovať. Naviac v hlavičke Content-Type odosielateľov softvér uloží typ prenášaných dat, podľa ktorého príjemcov softvér automaticky rozpozná, akým prehliadačom má data príjemcu zobraziť. Príjemca potom podľa typu prenášaných dat spustí príslušný prehliadač:

o Textový editor pro text o Grafický editor pro obrázok o Príslušný prehrávač pre zvuk, video či animáciu

Tieto dodatočné informácie o prenášaných datach nesú hlavičky začínajúce reťazcom "Content-", ktoré špecifikuje norma MIME. MIME je štandardom, ktorý doplňuje normu RFC-822 a zaisťuje spätnú kompatibilitu. MIME je navhnuté tak, aby mohli byť posielané existujúcim poštovým systémom správy obsahujúce diakritiku, obrázky, zvuk atd.

Tento štandard rieší dve otázky: o Ako vytvoriť zo správy obsahujúcej napr. binárne data správu vyhovujúcej norme RFC-

822 a teda prepraviteľnú používanými prenosovými protokolmi o Ako rozlíšiť jednotlivé druhy správ, tj. zavádza klasifikáciu prenášaných informácií.

Klasifikácia prenášaných informácií sa ukázala veľmi užitočnou i mimo e-mail. Moderné služby Internetu ju preberajú a používajú k rovnakému účelu. MIME zavádza ďalšie hlavičky do poštovej správy, ktoré špecifikujú typ posielaných dat a spôsob ich kódovania.

15

Elektronická pošta – Hlavičky MIME

MIME zavádza hlavičky: o MIME-Version - prítomnosť tejto hlavičky elektronickej pošty indikuje, že je správa

zostavená podľa MIME, tj. podľa RFC2045 až RFC2049. o Content-Type - špecifikuje typ a podtyp dat posielaných v tele správy (text, audio,

video, virtuálna realita). o Content-Transfer-Encoding - špecifikuje použité kódovanie, pomocou ktorého je

správa prevedená do formátu vyhovujúceho prenosovému mechanizmu (do ASCII). o Content-ID - identifikácia správy použiteľná v možnom odkaze. o Content-Description - textový opis obsahu. o Content-reťazec - je rezervované pre budúce použitie v MIME. o Content-Disposition – je hlavička špecifikovaná normou RFC-2183.

Niektoré alebo všetky tieto hlavičky sa môžu objaviť v normálnom záhlaví. Kompliantná implementácia MIME musí podporovať hlavičky MIME-Version,

Content-Type a Content-Transfer-Encoding, hlavičky Content-ID a Content-Description a Content-Disposition sú voliteľné a môže byť príjemcom ignorované.

16


Hlavička Mime-Version o Táto hlavička je jediná hlavička MIME nezačínajúca raťazcom "Content-". Hlavička

špecifikuje verziu normy MIME. Dôvodom zavedenia tejto hlavičky je zaistenie kompatibility. Tj. podľa prítomnosti tejto hlavičky softvér klienta rozpozná, že ide o správu rozšírenú podľa MIME, a ďalej rozpozná verziu MIME, podľa kterej bola správa rozšírená. Rozšírenie MIME podľa RFC2045 až RFC2049 je verzia 1.0. V budúcnosti však môžu prísť ďalšie verzie MIME s iným repertoárom hlavičiek.

o Poznámka: Protokol HTTP používa tiež hlavičky vychádzajúce z filozofie MIME a mnohé rovnako začínajú raťazcom „Content-“, ale sú uspôsobené protokolu HTTP. Práve skutočnosť, že záhlavie HTTP nie je celkom kompatibilné s MIME, je v protokole HTTP signalizované neexistenciou hlavičky Mime-Version v záhlaví HTTP správy.

o Správa zostavená podľa RFC2045 až RFC2049 musí túto hlavičku vždy obsahovať. Teda konkrétny tvar hlavičky vypadá takto: Mime-Version: 1.0 Hlavička musí byť uvedená pred ostatnými hlavičkami MIME.

Hlavička Content-Type o Hlavička opisuje typ dát obsiahnutých v tele správy tak, aby klient, ktorý túto správu

obdrží, mohol zvoliť vhodný spôsob prezentácie obsahu správy. Hlavička má tvar: Content-Type: typ/podtyp; parametre

Hlavička špecifikuje charakter obsahu správy pomocou typu a podtypu a prípadne pomocou doplnkových parametrov. Parametre majú tvar: atribut=hodnota; …Parametrov môže byť i viacej – sú potom oddelené bodkočiarkou a na ich poradí nezáleží. Typ špecifikuje, o aký typ údajov sa jedná, či je v tele správy obsiahnutý text, obrázok (image) alebo napr. všeobecný binárny súbor (octet stream). Podtyp potom špecifikuje konkrétny formát obrázku, textu apod. Napr. hlavička Content-Type: image/jpeg informuje príjemcu o tom, že obsahom správy je obrázok formátu JPEG. 17


Hlavička Content-Type o RFC2045 až RFC2049 definuje niekoľko základných typov. Spôsob registrácie ďalších

typov je opísaný v RFC2048. Typy sú dvojakého druhu: Jednoduché typy opisujúce typ prenášaných dat. Jedná sa napr. o typy: text, application,

image, audio, video, model Kompozitné typy špecifikujúce, že správa sa skladá z niekoľko častí. Jedná sa napr. o typy:

message, multipart, report Hlavička Content-Transfer-Encoding

o Data, ktoré chceme posielať elektronickou poštou, sú často 8bitové alebo binárne. Tieto data nie je možné spravidla poslať priamo. Preto je potrebné definovať mechanizmus prevodu – kódovania, akým sa data prevedú na data, ktorá sú v kóde US-ASCII, tj. sú prevedené do 7bitového tvaru. Použitý typ kódovania je uvedený práve v hlavičke Content-Transfer-Encoding.

o Hlavička Content-Transfer-Encoding v podstate nenesie iba informáciu o tom, akým algoritmom sú prenášané data kódované, ale v prípade, že kódované nie sú, tak nesie informáciu o dátach ako takých: ak sú sedembitové, osemibitové či binárne (7bit, 8bit či binary).

o MIME definuje dva algoritmy kódovania dat: Quoted-Printable a base64. Ďalšie algoritmy môžu byť registrované tiež podľa RFC2048. Hlavička Content-Transfer-Encoding tak najčastejšie nesie nasledujúce spôsoby kódovania:

quoted-printable base64 7bit – data nie sú kódované, sú v krátkych riadkoch, obsahujú iba znaky US-ASCII 8bit – data nie sú kódované, riadky sú krátke, ale môžu sa vyskytnúť i znaky, ktoré nie sú US-

ASCII 18

Elektronická pošta – Hlavičky MIME binary – data nie sú kódované, tok bitov nie je delený na riadky. Celkový počet prenášaných

bitov musí byť deliteľný osmymi. x-rozšírenie - experimentálne kódovánie (určené pre vývojárov).

o Hodnoty 8bit, 7bit a binary nepredstavujú žiadne kódovanie. Tieto hodnoty sú užitočné ako indikácia typu dat. Hlavička Content-Transfer-Encoding sa vzťahuje k celému telu správy. Pokiaľ sa hlavička objaví v konkrétnej časti správy, potom sa vzťahuje iba na túto časť. Problém, ako kódovať non US-ASCII informácie v hlavičke, je opísaný v časti „Znaky v hlavičke, ktoré nie sú US-ASCII“. Kódovací mechanizmus kóduje všetky data do ASCII znakov. Výsledkom kódovánia je teda US-ASCII reťazec. Príklad: Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: base64 interpretujeme takto: telo správy je reťazec znakov US-ASCII vzniklých kódovaním base64. Pôvodné data boli v znakovej sade ISO-8859-2 a musia byť do tejto sady opäť prevedené pri zobrazovaní príjemcovi.

Hlavička Content-ID o Hlavička nesie jednoznačnú identifikáciu obsahu správy. Hlavička je voliteľná, jej

použitie je ale v niektorých prípadoch povinné – napr. v implementáciach používajúcich data typu message/external-body.

Hlavička Content-Description Hlavička obsahuje opisné informácie o prenášanej správe, napr. názov obrázku, ktorý

je ako telo posielaný. Príklad: Content-Description: "Obrazok Bratislavskeho hradu". Opis musí byť v US-ASCII.

19


Hlavička Content-Disposition o Hlavička Content-Disposition určuje, či sú prenášané data určené na automatické

zobrazenie príjemcovi (inline) či nie sú určené k automatickému zobrazeniu príjemcovi (attachment), tj. príjemca ich má spracovávať ručne (napr. sa jedná o súbor, ktorý má byť uložený na lokálnom disku). Ďalej hlavička môže obsahovať ďalšie parametre:

filename=meno súboru creation-date=dátum vytvorenia modification-date=dátum poslednej modifikácie read-date=dátum posledného čítania size=veľkosť prenášaného súboru

o Príklad (správa nesúca zvuk, ktorý sa má príjemcovi prehrať): Message-ID: <[email protected]> Date: Sun, 20 Apr 1997 16:20:41 +0200 From: Jan Biely <[email protected]> X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: [email protected] Subject: (no subject) Content-Type: audio/wav Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ding.wav" UklGRkYtAABXQVZFZm10IBAAAAABAAEAIlYAACJWAAABAAgAZGF0YSItAACAgICAgICAgIC

20

Elektronická pošta – Hlavičky MIME, kódovanie US-ASCII

21

Elektronická pošta – Štandardné kódovacie mechanizmy

Štandardné kódovacie mechanizmy o Kódovací mechanizmus prevádza osembitové data na sedembitové (tj. data

obsahujúce iba znaky US-ASCII). o MIME definuje dva kódovacie mechanizmy: Quoted-printable a base64. Pre úplnosť

sa zmienime ešte o mechanizme Radix-64, ktorý používa PGP. Quoted-printable

o Toto kódovanie je určené pre data, ktorá z väčšej časti obsahujú znaky US-ASCII. Výsledkom kódovania je text, ktorý je i bez dekódovania z veľkej časti pre človeka čitateľný.

o Pravidlá kódovania Bajty s desiatkovou hodnotou od 33 do 60 a od 62 do 126 vrátane sú nahradené znakmi US-

ASCII (od ! do < a od > do ~). Inými slovami: znaky, ktoré sú US-ASCII, se nekódujú, tj. ponechávajú sa bez zmeny. Rovnako konce riadkov sa ponechávajú.

Ostatné bajty se nahradzujú znakom "=" nasledovaným šestnásťkovou hodnotou bajtu. Napr. znak „á“ se nahradí „=E1“.

Bajty s hodnotou 9 a 32 sú nahradené znakmi tabulátor a medzera. Nesmia byť na konci riadku.

Koniec riadku je vyjadrený CRLF. Zakódovaný riadok musí mať maximálně 76 znakov. Pokiaľ je riadok dlhší použije sa mäkký

koniec riadku, tj. vloží sa znak „=“ a konec riadku. o Tento spôsob kódovania nie je príliš úsporný. V prípade, že všetky prenášané znaky sú

non US-ASCII, potom sa prenášané data zväčšia na trojnásobok. o Príklad:

Reťazec Ján Opička bude kódovaný v quoted-printable ako J=E1n Opi=E8ka, pretože á je šestnásťkovo E1 a č je šestnásťkovo E8

22


base64 o Kódovanie base64 je určené pre kódovanie všeobecných binárnych dat, ktoré nemusia

byť čiteteľné pre človeka. Kódované data sú iba o tretinu dlhšie než data pôvodné. o Kódovací algoritmus je jednoduchý.

Používa tabuľku base64 zo 64 znakmi (a znak "="). Pre kódovanie 64 znakov je potreba 6 bitov (26=64). Znak "=" (6510) sa používa na špeciálny účel na označenie výplne na konci textu.

Z hľadiska kódovania sa na správu nehľadí ako na prúd osmíc bitov (bajtov), ale ako na prúd šestíc bitov. Každá šestica sa potom kóduje podľa tabuľky base64. Viď nasledujúci obrázok s tabuľkou kódu.

Na začiatku kódovania sa kódovaný text rozdelí na sekvence 24 bitov (trojica bajtov). Každá trojica bajtov sa rozdelí na 4 šestice bitov. Každá šestica reprezentuje jeden znak v abecede base64. Kóduje sa zľava doprava. Každých 6 bitov je nahradených odpovedajúcim znakom z tabuľky znakov abecedy base64.

o Výstupný - zakódovaný text musí byť usporiadaný do riadkov maximálne dlhých 76 znakov.

o Všetky znaky pre koniec riadku a iné znaky, ktoré nie sú obsiahnuté v tabuľke base64, musia byť dekódovacím programom ignorované, môžu indikovať chybu prenosu. Ak zostane na konci textu po rozdelení menej než 24 bitov, doplnia sa nulové bity sprava. Pridanie na koniec je indikované znakom "=". Problém je v tom, že dĺžka textu, ktorý sa kóduje, nemusí byť deliteľný tromi. Ak sa rozdelí text vstupujúci do kódovania na skupiny po troch bajtoch, potom posledná skupina:

Má tiež tri bajty. Nedochádza k žiadnej komplikácii a žiadne znaky „=“ sa na koniec nepridávajú.

23


Má dva bajty (16 bitov), potom sa prvých dvanásť bitov kóduje normálne podľa tabuľky base64. Ostatné 4 bity sa doplnia dvomi binárnymi nulami na 6 bitov a výsledek se tiež kóduje base64. Avšak na koniec sa pridá jeden znak „=“ signalizujúci doplnenie výplňou dlhou dva bity.

Má jeden bajt (8 bitov), potom sa prvých 6 bitov kóduje normálne podľa tabuľky base64. Ostatné dva bity sa doplnia štyrmi binárnymi nulami a výsledok sa kóduje podľa tabuľky base64. Na koniec sa pridají dva znaky „=“ signalizujúce výplň dlhú 4 bity.

24

Elektronická pošta – Kódovanie base64

25

0

Dvojkovo vyjadrené prenášané data

1. bajt 2. bajt 3. bajt

1 1 0 1 1 0 0 1 0 0 0 0 0 1 1 1 1 1 1 1 1 0 1 0

1. šestica 11011 2 =27 10

2. šestica 10010 2 =18 10

3. šestica 11110 2 =30 10

4. šestica 101010 2 =42 10

27 -> b 18 -> S 30 -> e 42 -> q

S q b e

base64 kódované data


Radix-64 o Kódovánie Radix-64 je opísané v RFC-2440, ktoré špecifikuje formát správy PGP.

Jedná sa o rozšírenie kódovania base64 o kontrolný súčet. Data sú kódované base64. Za base64 kódovanými datami nasleduje nový riadok (CRLF), znak „=“ a 24 bitov dlhý kontrolný súčet z pôvodných nekódovaných dat počítaný algoritmom CRC-24. Sám kontrolný súčet je tiež kódovaný base64. Zdrojový kód algoritmu CRC-24 je uvedený v RFC-2440.

o Príklad (RFC-2440): -----BEGIN PGP MESSAGE----- Version: OpenPrivacy 0.99 yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS vBSFjNSiVHsuAA== =njUN -----END PGP MESSAGE-----

o V prípade, že Váš softvér nepodporuje kódovanie Radix-64, potom stačí vypustiť posledný riadok a data dekódovať bežným softvérom pre base64 kódovanie.

Znaky v hlavičke, ktoré sú non ASCII o Znaky, ktoré nie sú ASCII, by sa v žiadnom prípade nemali vyskytnúť v záhlaví správy.

Na otázku čo sa stane, keď sa tam taký znak vyskytne, nie je jednoznačná odpoveď. Správa môže dôjsť príjemcovi bez problému, správa môže byť nejakým serverom na ceste vrátená alebo sa môže stratiť.

26

Elektronická pošta – Jednoduché typy dat v hlavičke Content-Type

Jednoduché typy dat v hlavičke Content-Type o Jednoduché typy v podstate oznamujú, aký softér má príjemcov poštový klient použiť

na zobrazenie správy adresátovi. Či má správu zobraziť textovým editorom, grafickým editorom, prehrávačom zvuku, videa či snáď dokonce zobraziť ako virtuálnu realitu:

o Text Typ text je určený pre textové zprávy. Typ text môže mať o.i. nasledujúce podtypy: plain,

Richtext, Enriched, Html, Sgml, c822-headers, Css, xml, directory, Calendar, parityfec. Primárny podtyp je plain, ktorý označuje neformátovaný text. Podtypy sa používajú na

formátované texty. Príkladom je napr. podtyp html, kedy text obsahuje príkazy jazyka HTML. Pri type text je možné použiť parameter charset, ktorý indikuje použitú znakovú sadu. Pre nás

sú zaujímavé najmä sady US-ASCII, ISO-8859-2 („ISO-LATIN2“), Windows-1250 a prípadne IBM850.

o Application Tento typ je určený pre data, ktoré je treba spracovať nejakou aplikáciou, aby bola čitateľná

pre používateľa. Sú definované podtypy: octet-stream a PostScript. Všeobecne podtyp býva menom aplikácie, pre ktorú sú data určené. Používateľ musí byť nejakým spôsobom informovaný, ako dotyčné data spracovať, napr. sprievodným listom. Iba z hlavičky sa o ich bližšom charaktere používateľ nemusí dozvedieť všetky informácie.

Podtypy: Octet-Stream - indikuje, že telo obsahuje binárne data. Je možné uviesť parametre:

Type - druh binárnych dat (pre informáciu používateľa) Doporučená akcia pri obdržaní takejto správy je uložiť data do súboru bez dekódovania a použiť aplikáciu.

PostScript - indikuje, že v tele správy je postscriptový dokument. Další podtypy sú okrem iného: sgml, pgp-sinature, pgp-encrypted a pgp-keys, pkcs7-mime, pkcs7-

signature a pkcs-10, xml, http, parityfec, msword.

27

Elektronická pošta – Jednoduché typy dat v hlavičke Content-Type

Jednoduché typy dat v hlavičke Content-Type o Image

Typ image špecifikuje obrázok, tj. obsahom tela správy je obrázok. K jeho prezentácii je treba odpovedajúci prehliadač. Podtypy sú okrem iného: jpeg, gif, tiff.

o Audio Typ audio špecifikuje zvuk. Na prezentáciu je treba odpovedajúci prehrávač. Podtypy okrem

iného sú: basic (mono so vzorkovacím kmitočtom 8 kHz, implicitní podtyp), 32kadpcm, L16, telephone-event, tone, mpeg, parityfec, MP4A-LATM.

o Video Obsahom tela správy je video, implicitný podtyp je mpeg.

o Model Typ model je určený pre viacdimenzionálne štruktúry (napr. pre virtuálnu realitu).

28

Elektronická pošta – Kompozitné typy v Content-Type

Kompozitné typy v Content-Type o Doposiaľ sme sa zaoberali iba jednoduchými správami, tj. správami, ktoré se skladali z

jednej časti (viď obrázok - Štruktúra štandardnej správy podľa RFC-822 ). o Teraz sa budeme zaoberať správami zloženými s viacerých jednotlivých správ. Každá

jednotlivá správa sa môže opäť skladať z dielčich správ alebo už môže byť jednoduchou správou. Správa môže vo svojom tele niesť:

Niekoľko dielčich správ, potom je použitá hlavička (Content-Type: multipart). Dlhá správa môže byť transportovaná ako niekoľko kratších (Content-Type: message). Iným prípadom je situácia, že poštový server z nejakej príčiny nemôže poštovú správu

odovzdať ďalej smerom k adresátovi pre chybu v doručovaní správy. V takomto prípade poštové servery často túto skutočnosť signalizujú adresátovi poštovou správou, ktorá se skladá zo dvoch častí: z časti špecifikujúcej chybu a časti obsahujúcej pôvodnú správu (alebo aspoň začiatok pôvodnej správy).

29


Kompozitné typy v Content-Type o Multipart

Telo správy tohto typu obsahuje niekoľko rôznych častí - niekoľko dielčich správ. Každá časť tela celkovej správy začína úvodným oddeľovačom, potom nasledujú hlavičky tejto časti, prázdny riadok a vlastné telo dielčej správy. Posledná časť je ukončená koncovým oddeľovačom.

Jednotlivé dielčie správy nie sú interpretované podľa RFC-822. Môžu, ale tiež nemusia obsahovať hlavičky (prázdny riadok za záhlavím však musí byť vždy uvedený). Pokiaľ nie sú hlavičky pri častiach uvedené, uplatnia sa implicitné hlavičky zo záhlavia celej správy. Oddeľovač je špeciálna sekvencia znakov, která sa nesmie vyskytnúť nikde vo vnútri časti. Oddeľovač sa definuje v záhlaví celej správy v hlavičke Content-Type parametrom boundary. Parameter má tvar boundary=raťazec. Oddeľovač je potom riadok, ktorý začína dvomi pomlčkami "- -", potom nasleduje reťazec z parametra. Maximálna dĺžka oddeľovače je 70 znakov.

30


Príklad štruktúry správy typu multipart s podtypom mixed

31


Kompozitné typy v Content-Type o Multipart

Podtypy: Multipart/Mixed - je primárnym podtypom. Je určený pre správy, ktoré obsahujú nezávislé časti, ktoré

je potrebné zviazať v danom konkrétnom poradí. Klasickým prípadom podtypu multipart/mixed je správa elektronickej pošty obsahujúca jeden alebo viacero príloh.

Multipart/Alternative - správa tohto typu obsahuje niekoľko častí, pritom všetky časti obsahujú zhodné informácie, iba tvar je odlišný. Napr. Tá istá správa raz napísaná v US-ASCII, potom v ISO-8859-2 a nakoniec trebárs nahovorená, tj. audio. Najlepšia prezentácia informácií je uvádzaná ako posledná časť. Príjemcov softvér musí rozpoznať, ktoré formy je schopný zobraziť, a vybrať z nich tú najlepšiu.

Multipart/Digest - používa sa vtedy, keď každá z častí tela je interpretovaná ako správa so záhlavím. Tento podtyp umožňuje konštrukciu správy, ktorej časti sú individuálne správy. Napríklad moderátor skupiny zbiera správy elektronickej pošty od účastníkov, spojí tieto správy a pošle ich v jednej zapúzdrenej správe MIME.

Multipart/Parallel. Klientom majú byť všetky časti prezentované používateľovi súčasne. Napr. zvuk na pozadí obrázku.

o Message Tento typ umožňuje odoslať poštovú správu ako telo inej poštovej správy (message/rfc822) dlhú správu odoslať ako niekoľko kratších (message/partial) alebo namiesto tela správy odoslať iba informácie, že sa správa nachádza na nejakom serveri

(message/external-body).

32


Kompozitné typy v Content-Type o Message

Podtypy okrem iného sú: Message/rfc822 špecifikuje, že telo obsahuje vnorenú správu, ktorá má syntax podľa

RFC-822. Na rozdiel od správy definovanej v RFC-822 nie je nevyhnutné, aby každé telo správy typu message/rfc822 obsahovalo hlavičky From, Subject a To. Vnorená správa môže byť i MIME správa.

Message/Partial je definovaný preto, aby bylo možné posielať dlhé správy ako niekoľko kratších a príjemcov softvér ich mohol automaticky zobraziť ako jednu (zlúčenú) správu.

Message/External-Body špecifikuje iba informácie o správe, ktorá je uložená mimo vlastnej správy. Miesto, kde sú data správy uložené, je špecifikované pomocou parametrov:

Parameter acces-type špecifikuje, o aký server (protokol) sa jedná. Najčastejšie typy serverov sú ftp, anon-ftp (anonymný FTP-server), mail-server (list server) a local-file (súbor na lokálnom počítači).

name - meno súboru site - meno počítača (servera so súborom) directory - adresár, v ktorom súbor leží expiration - čas, do kedy tam súbor bude (do kedy bude aktuálny).

33

Bezpečná pošta: S/MIME

Bezpečná pošta: S/MIME ponúka možnosť podpísania a/alebo šifrovania správ prostredníctvom týchto funkcií:

o Enveloped data (obálkované údaje): Skladá sa zo zašifrovaného obsahu lubovoľného typu a zašifrovaného kľúča (ktorým sa zašifroval obsah) a to pre každého príjemcu.

o Signed data (podpísané údaje): Digitálny podpis je vytvorený tak, že sa vytvorí kontrolná suma podpisovaného obsahu a tento kontrolný súčet sa zašifruje privátnym kľúčom podpisovateľa. Obsah a podpis sú potom zakódované pomocou schémy base64. Správu s podpísaným obsahom môže vidieť iba príjemca s funkcionalitou S/MIME.

o Clear-signed data (iba podpísané údaje): Je vytvorený digitálny podpis obsahu rovnako ako pri podpísaných údajoch. V tomto prípade je iba digitálny podpis kódovaný pomocou schémy base64. Výsledkom je, že príjemcovia bez funkcionalít S/MIME sú schopní prečítať obsahu správy aj keď nemôže overiť podpis.

o Signed and enveloped data (podpísané a obálkované údaje): iba podpísané a iba šifrované entity môžu byť vnorené. To znamená, že zašifrované údaje môžu byť podpísané (pozor – podpisovateľ by mal vidieť čo podpisuje, princíp what you see is what you sign) a podpísané údaje alebo iba podpísané údaje môžu byť zašifrované.

S/MIME zavádza niekoľko nových typov obsahu MIME. Všetky nové typy aplikácií používajú označenie PKCS (špecifikácie kryptografie s verejným kľúčom vydaných spoločnosťou RSA Laboratories a sprístupnené pre S/MIME). (PKCS #7 bolo zovšeobecnené odporúčaním CMS – Cryptographic Message Syntax)

34

Bezpečná pošta S/MIME

S/MIME zabezpečuje entity MIME pomocou podpisu, šifrovaním alebo obojím. o Entita MIME môže byť celá správa (s výnimkou záhlaví [RFC 5322]) alebo ak typ

obsahu MIME je multipart, potom entita MIME je jedna alebo viac podčastí správy. o Entita MIME je vytvorená podľa štandardných pravidiel vytvárania správ MIME. Potom

entita MIME plus niektoré údaje súvisiace s bezpečnosťou (identifikácia algoritmov a certifikáty) sú spracované S/MIME s výsledkom vytvorenia PKCS objektu. S PKCS objektom sa potom zaobchádza ako s obsahom správy a je zabalený do MIME (vybavená vhodnými hlavičkami MIME).

Použitie kódovania prenosu si vyžaduje osobitnú pozornosť. Vo väčšine prípadov bude výsledkom použitia bezpečnostného algoritmu vytvorený objekt, ktorý je čiastočne alebo úplne vyjadrený ako ľubovoľné binárne údaje. Tento objekt bude potom zabalený vo vonkajšej správe MIME a kódovanie prenosu môže byť použité v tomto bode, štandardne base64. Avšak v prípade správy multipart/signed je obsah správy v jednej z podčastí bezpečnostným procesom nezmenený. Ak nie je tento obsah 7 bitový, prenos by mal byť kódovaný schémou base64 alebo quoted-printable tak, aby nebolo žiadne nebezpečenstvo zmeny obsahu, na ktorý bol aplikovaný podpis.

35

MIME

Správa PKCS#7 CMS

base64 MIME SMTP

Bezpečná pošta S/MIME

Základné typy obsahu S/MIME sú: o Pre typ multipart je podtyp Signed: iba podpísaná správa, ktorá sa skladá z dvoch

častí. Prvá časť je správa a druhá je podpis. o Pre typ application je podtyp pkcs7-signature: typ obsahu pre podčasť podpisu správy

multipart/signed. o Pre typ application je podtyp pkcs7-mime. Bližšiu špecifikáciu určuje parameter

smime. Parameter smime=signedData označuje podpísanú entitu S/MIME. Parameter smime=envelopedData označuje zašifrovanú entitu S/MIME. Parameter smime= degenerate signedData označuje, že entita S/MIME obsahuje iba certifikáty.

Podtyp application/pkcs7-mime sa používa pre jednu z troch kategórií spracovania S/MIME, každú s jedinečným parametrom smime-type (parameter smime-type nadobúda hodnoty signedData, envelopedData, degenerate signedData). Vo všetkých prípadoch výsledná entita (ďalej len objekt) je reprezentovaná vo forme známej ako BER (Basic Encoding Rules), ktorá je definovaná v ITU-T Odporúčaniach X.209. Formát BER sa skladá z ľubovoľných oktetových reťazcov a predstavuje teda binárne dáta. Takýto objekt by mal byť kódovaný pri prenose schémou base64 vo vonkajšej správe MIME.

36

Bezpečná pošta S/MIME – postup vytvorenia typu envelopedData

Postup na vytvorenie entity MIME typu envelopedData je: o Generuj pseudonáhodný relačný kľúč pre konkrétny symetrický šifrovací algoritmus

(napríklad triple DES). o Pre každého príjemcu zašifruj relačný kľúč jeho verejným kľúčom z certifikátu. Pre

každého príjemcu sa vytvorí blok označený RecipientInfo, ktorý obsahuje identifikátor (ID) certifikátu verejného kľúča príjemcu, identifikátor (ID) algoritmu použitého na zašifrovanie relačného kľúča a zašifrovaný relačný kľúč.

o Zašifruj obsah správy relačným kľúčom a vlož do štruktúry envelopedData.Pre typ application je podtyp pkcs7-signature: typ obsahu pre podčasť podpisu správy multipart/signed.

Bloky RecipientInfo sú nasledované zašifrovaným obsahom a vytvárajú envelopedData. Táto informácia je potom zakódovaná schémou base64. Na nasledujúcom obrázku je znázornená schéma vytvorenia entity typu envelopedData pre dvoch príjemcov.

Na znovuzískanie zašifrovanej správy príjemca najprv dešifruje správu podľa schémy base64. Potom príjemca použije svoj privátny kľúč a dešifruje relačný kľúč. Nakoniec je obsah správy dešifrovaný relačným kľúčom.

37

Bezpečná pošta S/MIME – postup vytvorenia typu envelopedData

38

Bezpečná pošta S/MIME – postup vytvorenia typu signedData

Typ smime označený signedData (parameter smime-type=signedData) môže byť použitý s jedným alebo viacerými podpisovateľmi. Pre názornosť sa uvedie opis prípadu s jedným podpisovateľom. Postup na vytvorenie entity MIME typu signedData je: o Vyber algoritmus na vytvorenie kontrolného súčtu (napríklad SHA2) a vypočítaj

kontrolnú sumu (hash hodnotu) obsahu, ktorý má byť podpísaný. o Zašifrujte kontrolnú sumu privátnym kľúčom podpisovateľa. o Priprav blok označený ako SignerInfo, ktorý obsahuje certifikát verejného kľúča

podpisovateľa, identifikáciu algoritmu na výpočet kontrolnej sumy, identifikátor šifrovacieho algoritmu kontrolnej sumy a zašifrovanú kontrolnú sumu.

Entita signedData sa skladá z radu blokov vrátane identifikátora algoritmu na výpočet kontrolnej sumy správy, podpísanej správy a SignerInfo. Entita signedData môže ešte obsahovať sadu certifikátov verejných kľúčov od dôveryhodnej alebo koreňovej certifikačnej autority, ktoré sú potrebné na overenie platnosti podpisu. Táto informácia je potom zakódovaná schémou base64.

Na obnovenie podpísanej správy a overenie podpisu, príjemca najprv odkóduje base64. Potom príjemca overí platnosť podpisu tak, že overí platnosť certifikátu a verejným kľúčom dešifruje zašifrovanú kontrolnú sumu správy. Ďalej vypočíta kontrolný súčet podpísanej správy. Ak sa rovnajú kontrolné súčty, jeden vytvorený príjemcom z podpísanej správa a druhý zistený dešifrovaním zašifrovaného kontrolného súčtu podpísanej správy, potom je podpis správy overený.

39

Bezpečná pošta S/MIME – správa clear-signed

Iba podpísanie (clear-signed) je dosiahnuté pomocou typu obsahu multipart a podtypu signed. Ako už bolo spomenuté, tento proces podpisovania nezahŕňa transformáciu správy, ktorá je podpísaná, takže správa je odoslaná v pôvodnom tvare a príjemcovia s funkciami MIME, ale nie s funkciami S/MIME, sú schopní prečítať prichádzajúcu správu.

Správa multipart/signed má dve časti. Prvá časť môže byť akýkoľvek typ MIME, ale musí byť vytvorená tak, že sa nebude meniť v počas prenosu od zdroja k cieľu. To znamená, že ak prvá časť nie je 7 bitová, potom je potrebné, aby sa prvá časť zakódovala schémou base64 alebo quoted-printable. Potom je táto časť spracovaná rovnakým spôsobom ako signedData, ale v tomto prípade je vytvorený objekt vo formáte signedData, ktorý má prázdne pole obsahu správy. Tento objekt je oddelený podpis. Potom je kódovaný na prenos schémou base64 a stane sa druhou časťou správy multipart/signed. Táto druhá časť má type obsahu MIME application a podtyp pkcs7-signature. Na nasledujúcom obrázku je ukážka štruktúry správy.

Parameter protocol označuje, že sa jedná o entitu iba podpísanú (clear-signed) s dvomi časťami. Parameter micalg udáva typ použitej funkcie na výpočet kontrolného súčtu. Príjemca môže overiť podpis tým, že vypočíta kontrolný súčet prvej časti a porovnaním ho s kontrolným súčtom získaným z druhej časti.

40

Bezpečná pošta S/MIME – správa clear-signed

41

Elektronická pošta – Aké číhajú nebezpečia na adresáta

Existujú tri typy triviálnych útokov na elektronicky podpísanú správu (útoky na asymetrickú kryptografiu či na symetrické šifry neberieme do úvahy) :

o Pokiaľ je správa iba elektronicky podpísaná a nie šifrovaná, potom z nej je možné získať text správy a pôvodnú elektronicky podpísanú správu zahodiť (nedoručiť adresátovi). V prípade, že správu adresát očakáva, potom môžeme pozmeniť obsah pôvodnej správy v náš prospech a nepodpísanú ju odovzdať adresátovi. Adresát správe uverí a bude si myslieť, že ju odesielateľ iba zabudol podpísať.

o Využijete vlastnosti adresy elektronickej pošty, ktorá sa môže skladať z ľubovoľného reťazca, ktorý v sebe niekedy v ostrých zátvorkách obsahuje adresu podľa RFC-822. Spravidla adresu píšeme: “Jan Biely <[email protected]>“, avšak nič nebráni napísať: “Prezident republiky <[email protected]>” a na prvý pohľad sa príjemcovi zobrazí, že mail prišiel od „Prezident republiky“ a obsahuje platný elektronický podpis. Pri ďalšom skúmaní na to ale ľahko prídeme, že sa jedná o podvrh.

o Použijeme nedôveryhodnú certifikačnú autoritu. Existuje celý rad testovacích CA, ktoré vydávajú automatizovane certifikáty na akúkoľvek žiadosť (tieto CA sú dôležité pre vývoj, ale nedôveryhodné z hľadiska údajov uvedených v certifikáte). Jednou z takýchto CA je i testovacia CA Verisignu. Tá má tu vlastnosť, že jej certifikát je tč. distribuovaný ako súčasť softvéru, tj. automaticky jej náš softvér verí po inštalácii napr. MS Outlook. Takže stačí si na podnikovom poštovom serveri nechať zriadiť účet vypadajúci ako účet generálneho riaditeľa. Z tohoto účtu si necháte vydať na testovacej CA certifikát (napr. na testovacej CA Verisign) a už sa môžete hrať so svojími spolupracovníkmi (podpisujete sa veselo pod neuveriteľné príkazy ako generálny riaditeľ, a adresátovi sa javí elektronický podpis jako dôveryhodný). Tejto zábavy si ale neužijú používatelia sietí založených napríklad na Windows 2000, pretože tie už podporujú CTL (Certificate Trust List).

42

Elektronická pošta – Aké číhajú nebezpečia na adresáta

CTL je elektronicky podpísaný zoznam dôveryhodných CA, ktorý sa distribuuje v rámci firmy, tj. neverí sa automaticky každej CA. V každom prípade je útok tohto typu spôsobený chybnou implementáciou PKI v organizáci. Pokiaľ totiž má byť elektronický podpis skutočne vážne používaný, musia organizačné postupy zaistiť, že používatelia budú mať na svojich PC označené ako dôveryhodné iba tie certifikačné autority, ktoré nimi z hľadiska organizácie skutočne sú.

o Základné nebezpečie číhajúce na S/MIME správy spočíva v podvrhnutí certifikátu aj s reťazcom certifikátov až ku koreňovému certifikátu. Súčasťou S/MIME správy totiž môže byť celý tento reťazec vrátane koreňového certifikátu. Je preto na softvéri poštového klienta, aby koreňovým certifikátom, ktoré sú posialané ako súčasť správy automaticky neveril. Toto nebezpečie sa ešte zosiluje v období, kedy sa obnovuje certifikát koreňovej CA.

o Koreňový certifikát musí byť distribuovaný a je treba, aby používateľ tento certifikát akceptoval, iba pokiaľ je distribuovaný dôveryhodnou cestou, tj. napr. je podpísaný starým (ešte platným) koreňovým certifikátom. Ak nie je žiadna z týchto ciest technicky možná, potom je treba, aby si používateľ napr. telefonicky na CA overil kontrolný súčet certifikátu označovaný tiež ako odtlačok certifikátu.

43

Elektronická pošta - architektúra - csirt.gov.sk · tvorené iba ASCII znakmi! o Záhlavie sa...

Documents

Transcript of Elektronická pošta - architektúra - csirt.gov.sk · tvorené iba ASCII znakmi! o Záhlavie sa...