Elektronická pošta, MIME, bezpečná pošta S/MIME Doc. Ing. Ladislav Hudec, CSc. 1
Elektronická pošta - architektúra q q 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 je v podstate iba špecializovaný textový editor, ktorý: o o o q q Front správ je pravidelne prechádzaný SMTP klientom, ktorý nadväzuje spojenie so vzdialenými SMTP servermi, ktorým správu odovzdá. SMTP server príjme správu a zisťuje, či je určená pre jeho lokálneho používateľa. o o q vie používateľovi zobrazit obsah správy z poštovej schránky 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 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). 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. V prípade, že adresát je lokálnym používateľom systému - SMTP server 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 SMTP server 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 IMAP 4. 2
Elektronická pošta – architektúra, elektronická pošta pri mainframe 3
Elektronická pošta - architektúra q 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 q 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 o q Privátne poštové schránky nie sú obsluhované SMTP serverom 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. 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. 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 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ý). 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
Elektronická pošta - architektúra q Na obrázku je znázornené fungovanie „klasickej“ elektronickej pošty na sálových počítačoch (mainframe): o o q S príchodom osobných počítačov prišiel zvrat i v používaní elektronickej pošty. o q 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. 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. 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). Príjemca si potom môže prijatú správu spracovať svojím poštovým klientom. 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 POP 3 a IMAP 4 6
Elektronická pošta - architektúra q q 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 o q Protokol POP 3. Ide o veľmi jednoduchý protokol, s ktorým pracuje používateľ Off. Line. 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. Protokol IMAP 4. Ide o komplikovaný protokol, ktorý umožňuje nielen pracovať Off. Line, ale i On. Line. 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 IMAP 4 umožňuje tiež pracovať s privátnymi poštovými schránkami priamo z terminála na serveri. Protokolom IMAP 4 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ť POP 3 a kedy IMAP 4. Odpoveď je: ako kedy. o Napr. pre veľkých poskytovateľov internetových služieb je veľmi výhodný protokol POP 3, 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 7 disková kapacita nie je dostatočná pre také ohromné množstvo dát (príležitosť pre malých poskytovateľov).
Elektronická pošta - architektúra o q Naopak pre menšie firmy je výhodný protokol IMAP 4, 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 POP 3 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 SMTP agent (vzdialený systém) SMTP Poštový server Front Privátne poštové SMTP agent schránky Poštová používateľae POP 3 schránka používateľa "INBOX" Používateľ pri PC 9
Elektronická pošta – formát poštovej správy q 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). Záhlavie i telo správy sú tvorené iba ASCII znakmi! o o 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). 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). Najmä v adrese majú dôležitý význam nasledujúce znaky: v v 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 – Prehľad základných hlavičiek z RFC-822 q Príklad: Ø Ø Ø Ø Ø Ø Ø Received: from mh. pvt. cz (mh. pvt. cz [194. 149. 105. 36]) by cbu. pvtnet. cz (8. 8. 5/8. 7. 3) with SMTP id PAA 23028; Wed, 16 Apr 1997 15: 10: 14 +0200 (MET DST) Received: from ncc. ripe. net by mh. pvt. cz with SMTP id AA 08008 (5. 67 b/IDA-1. 5 for <registr@pvt. cz>); Wed, 16 Apr 1997 15: 09 +0200 Received: by ncc. ripe. net id AA 00228 (5. 65 a/NCC-2. 41); Wed, 16 Apr 1997 13: 55: 02 +0200 Received: from mail. freedotnet. net by ncc. ripe. net with SMTP id AA 00215 (5. 65 a/NCC-2. 41); Wed, 16 Apr 1997 13: 55: 00 +0200 Received: from jon. freedotnet. net ([208. 215. 186. 129]) by homer. freedotnet. com (Netscape Mail Server v 2. 02) with ESMTP id AAA 105 for <local-ir@ripe. net>; Wed, 16 Apr 1997 13: 09: 15 +0100 Reply-To: <jon. brody@freedotnet. net> From: "Dr Jon Brody" <jon. brody@freedotnet. net> To: <local-ir@ripe. net> Subject: Re: Role? Date: Wed, 16 Apr 1997 12: 58: 51 +0100 X-Mailer: Microsoft Internet Mail 4. 70. 1155 Text mailu 13
Elektronická pošta – Prehľad základných hlavičiek z RFC-822 q Hlavičky predchádzajúcej správy sa musia rozdeliť na hlavičky začínajúce Received a ostatné hlavičky. Hlavičky Received pridávajú na začiatok správy poštové servery, ktorými správa prechádza. Preto pri hlavičkách Received záleží na poradí. Hlavička Received, ktorú pridal prvý server je posledná. Hlavička Received pred ňou je hlavička, ktorú pridal ďalší server atď. o Ak čítame hlavičky Received zo spodu nahore, potom vidíme, že správa bola odoslaná z počítača jon. freedotnet. net, potom ju spracovával počítač homer. freedotnet. net (počítač mail. freedotnet. net je len iné meno toho istého počítača). Ďalej správa putovala na ncc. ripe. net, který ju odovzdal na mh. pvt. cz a nakoniec skončila na cbu. pvtnet. cz. 14
Elektronická pošta – MIME q q 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 RFC 821. Objavilo sa tak rozšírenie MIME (Multipurpose Internet Mail Extension) dnes specifikované normami RFC-2045 až 2049. o 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 Base 64, 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ť). Táto cesta je pre bežných používateľov neprijateľná. Používateľ si nepraje nejakým kódovaním sa 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 15 prenášaných dat a algoritmus, ktorým boli data pred odoslaním zakódovené do USASCII. Opis dodatočných hlavičiek špecifikuje práve norma MIME.
Elektronická pošta – MIME q 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 o o q q Textový editor pro text Grafický editor pro obrázok 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 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 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 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čkové riadky do poštovej správy, ktoré špecifikujú typ posielaných dat a spôsob ich kódovania. 16
Elektronická pošta – Hlavičky MIME q MIME zavádza hlavičky: o o o o MIME-Version - prítomnosť tejto hlavičky elektronickej pošty indikuje, že je správa zostavená podľa MIME, tj. podľa RFC 2045 až RFC 2049. Content-Type - špecifikuje typ a podtyp dat posielaných v tele správy (text, audio, video, virtuálna realita). 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). Content-ID - identifikácia správy použiteľná v možnom odkaze. Content-Description - textový opis obsahu. Content-reťazec - je rezervované pre budúce použitie v MIME. Content-Disposition – je hlavička špecifikovaná normou RFC-2183. 17
Elektronická pošta – Hlavičky MIME q Hlavička Mime-Version o o o q 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 RFC 2045 až RFC 2049 je verzia 1. 0. V budúcnosti však môžu prísť ďalšie verzie MIME s iným repertoárom hlavičiek. 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. Správa zostavená podľa RFC 2045 až RFC 2049 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 v 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 18 obrázok formátu JPEG.
Elektronická pošta – Hlavičky MIME q Hlavička Content-Type o RFC 2045 až RFC 2049 definuje niekoľko základných typov. Spôsob registrácie ďalších typov je opísaný v RFC 2048. Typy sú dvojakého druhu: v v q 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ľkých častí. Jedná sa napr. o typy: message, multipart, report Hlavička Content-Transfer-Encoding o o o Data, ktoré chceme posielať elektronickou poštou, sú často 8 bitové 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 7 bitového tvaru. Použitý typ kódovania je uvedený práve v hlavičke Content-Transfer-Encoding. 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 (7 bit, 8 bit či binary). MIME definuje dva algoritmy kódovania dat: Quoted-Printable a Base 64. Ďalšie algoritmy môžu byť registrované tiež podľa RFC 2048. Hlavička Content-Transfer. Encoding tak najčastejšie nesie nasledujúce spôsoby kódovania: v v quoted-printable base 64 7 bit – data nie sú kódované, sú v krátkych riadkoch, obsahujú iba znaky US-ASCII 8 bit – data nie sú kódované, riadky sú krátke, ale môžu sa vyskytnúť i znaky, ktoré nie sú US- 19 ASCII
Elektronická pošta – Hlavičky MIME v v o q Hodnoty 8 bit, 7 bit 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ť ne 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: base 64 interpretujeme takto: telo správy je reťazec znakov US-ASCII vzniklých kódovaním base 64. 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 q 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). 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 q 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. 20
Elektronická pošta – Hlavičky MIME q 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: v v v o 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 Príklad (správa nesúca zvuk, ktorý sa má príjemcovi prehrať): v v v v Message-ID: <335 A 2639. C 79@stu. sk> Date: Sun, 20 Apr 1997 16: 20: 41 +0200 From: Jan Biely <biely@stu. sk> X-Mailer: Mozilla 3. 01 Gold (Win. NT; I) MIME-Version: 1. 0 To: biely@stu. sk Subject: (no subject) Content-Type: audio/wav Content-Transfer-Encoding: base 64 Content-Disposition: inline; filename="ding. wav" Ukl. GRk. Yt. AABXQVZFZm 10 IBAAAAABAAEAIl. YAACJWAAABAAg. AZGF 0 YSIt. AACAg. ICAg ICA 21. . .
Elektronická pošta – Hlavičky MIME, kódovanie US-ASCII 22
Elektronická pošta – Hlavičky MIME, kódovanie ISO/IEC 8859 -2 23
Elektronická pošta – Hlavičky MIME, kódovanie ISO/IEC 8859 -2 24
Elektronická pošta – Štandardné kódovacie mechanizmy q Štandardné kódovacie mechanizmy o o q Kódovací mechanizmus prevádza osembitové data na sedembitové (tj. data obsahujúce iba znaky US-ASCII). MIME definuje dva kódovacie mechanizmy: Quoted-printable a Base 64. Pre úplnosť sa zmienime ešte o mechanizme Radix-64, ktorý používa PGP. Quoted-printable o 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ý. Pravidlá kódovania v v v o o Bajty s desiatkovou hodnotou od 33 do 60 a od 62 do 126 vrátane sú nahradené znakmi USASCII (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í „=E 1“. 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álne 76 znakov. Pokiaľ je riadok dlhší použije sa mäkký koniec riadku, tj. vloží sa znak „=“ a konec riadku. Tento spôsob kódovania nie je príliš úsporný. V prípade, že všetky prenášané znaky sú ne US-ASCII, potom sa prenášané data zväčšia na trojnásobok. Príklad: v Reťazec Ján Opička bude kódovaný v quoted-printable ako J=E 1 n Opi=E 8 ka, pretože á je 25 šestnásťkovo E 1 a č je šestnásťkovo E 8
Elektronická pošta – Štandardné kódovacie mechanizmy q Base 64 o o Kódovanie Base 64 je určené pre kódovanie všeobecných binárnych dát, ktoré nemusia byť čitateľné pre človeka. Kódované data sú iba o tretinu dlhšie než dáta pôvodné. Kódovací algoritmus je jednoduchý. v v v o o Používa tabuľku Base 64 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 base 64. 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 base 64. Kóduje sa zľava doprava. Každých 6 bitov je nahradených odpovedajúcim znakom z tabuľky znakov abecedy Base 64 (a ten sa potom prenáša v 7 bitovom kóde US -ASCI). Výstupný - zakódovaný text musí byť usporiadaný do riadkov maximálne dlhých 76 znakov. Všetky znaky pre koniec riadku a iné znaky, ktoré nie sú obsiahnuté v tabuľke Base 64, 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: v Má tiež tri bajty. Nedochádza k žiadnej komplikácii a žiadne znaky „=“ sa na koniec nepridávajú. 26
Elektronická pošta – Štandardné kódovacie mechanizmy v v Má dva bajty (16 bitov), potom sa prvých dvanásť bitov kóduje normálne podľa tabuľky Base 64. Ostatné štyri bity sa doplnia štyrmi binárnymi nulami a výsledok sa kóduje podľa tabuľky Base 64. Avšak na koniec sa pridajú dva znaky „=“ signalizujúce doplnenie výplňou dlhou 4 bity. Má jeden bajt (8 bitov), potom sa prvých 6 bitov kóduje normálne podľa tabuľky Base 64. Ostatné 2 bity sa doplnia dvomi binárnymi nulami na 6 bitov a výsledek se tiež kóduje Base 64. Na koniec sa pridá jeden znak „=“ signalizujúci výplň dlhú 2 bity. 27
Elektronická pošta – Kódovanie Base 64 28
Elektronická pošta – Štandardné kódovacie mechanizmy q Radix-64 o 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 Base 64 o kontrolný súčet. Data sú kódované Base 64. Za Base 64 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ý Base 64. Zdrojový kód algoritmu CRC-24 je uvedený v RFC-2440. Príklad (RFC-2440): v v v v o q -----BEGIN PGP MESSAGE----Version: Open. Privacy 0. 99 y. Dg. BO 22 Wx. BHv 7 O 8 X 7 O/jyg. AEzol 56 i. UKi. Xm. V+Xmp. Ctmpq. QUKi. Qr. Fqcl. Fq. UDBovz. S v. BSFj. NSi. VHsu. AA== =nj. UN -----END PGP MESSAGE----- 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 Base 64 kódovanie. Znaky v hlavičke, ktoré nie sú 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ť. 29
Elektronická pošta – Jednoduché typy dat v hlavičke Content-Type q Jednoduché typy dat v hlavičke Content-Type o 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. Text v v v o Typ text je určený pre textové zprávy. Typ text môže mať o. i. nasledujúce podtypy: plain, Richtext, Enriched, Html, Sgml, c 822 -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-LATIN 2“), Windows-1250 a prípadne IBM 850. Application v v 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 Post. Script. 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. Post. Script - indikuje, že v tele správy je postscriptový dokument. Další podtypy sú okrem iného: sgml, pgp-sinature, pgp-encrypted a pgp-keys, pkcs 7 -mime, pkcs 7 signature a pkcs-10, xml, http, parityfec, msword. 30
Elektronická pošta – Jednoduché typy dat v hlavičke Content-Type q Jednoduché typy dat v hlavičke Content-Type o Image v o Audio v o 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 k. Hz, implicitní podtyp), 32 kadpcm, L 16, telephone-event, tone, mpeg, parityfec, MP 4 A-LATM. Video v o 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. Obsahom tela správy je video, implicitný podtyp je mpeg. Model v Typ model je určený pre viacdimenzionálne štruktúry (napr. pre virtuálnu realitu). 31
Elektronická pošta – Kompozitné typy v Content-Type q Kompozitné typy v Content-Type o 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 ). Teraz sa budeme zaoberať správami zloženými z 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ť: v v v 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). 32
Elektronická pošta – Kompozitné typy v Content-Type q Kompozitné typy v Content-Type o Multipart v v 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. 33
Elektronická pošta – Kompozitné typy v Content-Type q Kompozitné typy v Content-Type o Multipart v Podtypy: Ø Ø Ø o 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 jednu 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/Report - správa tohto typu slúži na potvrdzovanie doručovaných poštových správ. Multipart/Parallel. Klientom majú byť všetky časti prezentované používateľovi súčasne. Napr. zvuk na pozadí obrázku. Multipart/Signed je určený pre elektronicky podpísanú správu; špecifikuje správu skladajúcu sa z dvoch častí: Správy a Elektronického podpisu tejto správy Multipart/Encrypted špecifikuje správu v elektronickej obálke (šifrovanú správu). Skladá sa opäť z dvoch častí: Z informácií o použitom spôsobe šifrovania (napr. verzii šifrovacieho softvéru) a zo šifrovanej správy. Nie je definovaný podtyp pre správy elektronicky podpísané a zároveň šifrované. Na takúto požiadavku je nevyhnutné správu najprv elektronicky podpísať a výsledok potom celý zašifrovať. Príkladom môže byť PGP. Pokiaľ nepoužijete MIME, potom sa všetky informácie ukladajú do datovej časti správy. Takúto správu musíme najprv uložiť do súboru a potom na tento soubor spustiť program PGP. Najmä príjemca musí rozpoznať, že ide o správu, ktorú má spracovať programom PGP. RFC 2015 zavádza typy: application/pgp-encrypted, application/pgp-signature, application/pgp-keys. Message v Tento typ umožňuje odoslať poštovú správu ako telo inej poštovej správy (message/rfc 822), 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). 34
Elektronická pošta – Kompozitné typy v Content-Type q Kompozitné typy v Content-Type o Message v Podtypy okrem iného sú: Ø Ø Ø Message/rfc 822 š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/rfc 822 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). 35
Elektronická pošta – Bezpečná pošta: S/MIME q Bezpečná pošta: S/MIME o o o V Internete bol publikovaný celý rad protokolov špecifikujúcich bezpečnú poštu. Najmä išlo o protokoly PEM a MOSS, ktoré sa však v praxi neujali. Presadil sa protokol PGP, avšak z dnešného pohľadu sa javí jasným favoritom protokol S/MIME. Normy RFC-2632 až RFC-2634 sú už treťou verziou protokolu S/MIME (Secure/Multipurpose Internet Mail Extension). Zatiaľ čo druhá verzia protokolu S/MIME bola orientovaná na algoritmy RSA a MD-5 a správy podľa PKCS#7, tak tretia verzia tieto algoritmy a formát PKCS#7 podporuje len pre zachovanie spätnej komptability a orientuje sa na protokol CMS (Cryptographic Message Standard, RFC-2630). Základnými kryptografickými protokolmi sú: v v v o SHA-1 pre výpočet kontrolného súčtu. DSS pre elektronický podpis. Diffie-Hellmanov algoritmus pre šifrovanie symetrických kľúčov (dohadovanie kľúčov). S/MIME je koncertom niekoľkých protokolov. Jadrom je správa CMS, ktorá je zabalená v MIME správe. Naviac je potrebné s certifikátmi a CRL pracovať s ohľadom na to, že správy môžu byť spracovávané bez prístupu na Internet (Off. Line). Pred tým, než zostavíme S/MIME správu, podívame sa na jednotlivé protokoly, ktoré sa tejto hry zúčastňujú. 36
Elektronická pošta – Správa CMS používaná v S/MIME q Správa CMS používaná v S/MIME o o o S/MIME používa formát správy CMS. Pritom podporuje iba nasledujúce typy CMS správ: Data, Signed. Data a Enveloped. Data, tj. nepodporuje napr. autentizované data opisované tiež v norme CMS. V prípade elektronicky podpisovaných správ musí byť štruktúra signer. Info verzie 1. Prakticky to znamená, že v prípade elektronického podpisu sú podporované iba správy celkom kompatibilné s normou PKCS#7 (čo sa samozrejme netýka správ v elektronickej obálke). S/MIME doporučuje používať nasledujúce tri atribúty CMS správ (uvedené v module o PKI). Ide o podpisované atribúty elektronického podpisu, tj. štruktúry signer. Info v v v o o o signing. Time s. MIMECapabilities s. MIMEEncryption. Key. Preference Podpisované atribúty s. MIMECapabilities a s. MIMEEncryption. Key. Preference zavádza priamo norma S/MIME. Prvý atribút signing. Time obsahuje dátum a čas podpisu správy. Jeho syntax je v module o PKI. Ostatné dva atribúty zavádza priamo norma S/MIME. Atributom s. MIMECapabilities informuje odosielateľ príjemcu o kryptografických a iných algoritmoch, ktoré podporuje (aké algoritmy má použiť vo svojej prípadnej odpovedi). 37
Elektronická pošta – Správa CMS používaná v S/MIME, Certifikáty a CRL q Správa CMS používaná v S/MIME o o q Posledný atribút s. MIMEEncryption. Key. Preference je dôležitý v prípade, že odosielateľ používa iný certifikát na podpisovanie a iný na šifrovanie. Častou praxou totiž je, že odosielateľ elektronicky podpíše správu a ako súčasť elektronicky podpísanej správy (CMS zprávy) pribalí svoj certifikát. Príjemca potom využije tento certifikát na šifrovanie odpovedi. Ťažkosť nastane, ak nie je možné tento certifikát použiť na šifrovanie. To je i prípad kvalifikovaných certifikátov, ktoré majú v rozšírení „použitie kľúča“ nastavené, že sa smú používať iba k elektronickému podpisovaniu. Riešením je, že sa šifrovací certifikát tiež pribalí do CMS správy a jeho identifikácia sa uvedie v atribúte s. MIMEEncryption. Key. Preference. Certifikáty a CRL o o Adresa elektronickej pošty podľa RFC-822 musí byť uvedená v certifikáte, ktorým je dokument podpísaný. Ako softvér odosielateľa, tak softvér príjemcu musí skontrolovať zhodu tejto adresy uvedenej v certifikáte s adresou v hlavičke „From: “ alebo „Sender: “ elektronickej pošty. Tu je priestor pre rôzne žartíky, pretože adresa v hlavičke „From“ (resp. „Sender“) môže obsahovať ľubovoľný reťazec, pokiaľ je v tomto reťazci uvedená adresa v ostrých zátvorkách. MS Outlook však používateľovi zobrazuje práve ten ľubovoľný reťazec (a nie korektnú adresu v ostrých zátvorkách). V certifikáte môže byť uvedená adresa elektronickej pošty buď v predmete certifikátu (jedinečné meno „Common Name“) alebo v rozšírení Subject. Alt. Name. Obe možnosti sú podporované, preferovaná je však adresa v rozšírení Subject. Alt. Name. Pokiaľ používateľ totiž používa viac poštových adries, potom ich všetky môže do tohto rozšírenia uviesť (rozšírenie sa uvedie viacnásobne). 38
Elektronická pošta – Certifikáty a CRL q Certifikáty a CRL o o Inou otázkou sú rozšírenia certifikátu. S/MIME vyžaduje, aby softvér podporoval rozšírenia: Basic Constraints, Key Usage, authority. Key. ID, subject. Key. ID a subject. Alt. Names. Ostatné rozšírenia podporovať iba môže, tj. ostatné rozšírenia nemôžu byť označené ako kritické, aby bolo zaistené, že príslušný softvér pre S/MIME ich bude podporovať a neodmietne celý certifikát. CRL môže byť súčasťou správy CMS, tj. tým pádom i správy S/MIME. Je pochopiteľne pravda, že najefektivnejšie je používať On Line zistenie, ako na tom certifikát je, napr. využitím rozšírenia URI Distribution Points či protokolu OCSP. Avšak mnohokrát požívatelia pracujú tak, že sa pripoja k Internetu, stiahnu si poštu, odpoja sa od Internetu a až potom si čítajú poštu. V takom prípade On Line komunikácia s CA je nemožná a je dobré vziať i CRL zo správy. Softvér klienta by mal umožniť i tieto CRL uložiť v úložišti CRL počítača pre prípadné ďalšie použitie. 39
Elektronická pošta – MIME: Multipart/Signed a Multipart/Encrypted q MIME: Multipart/Signed a Multipart/Encrypted o o o Norma RFC 1847, ktorá zavádza kompozitný typy multipart/signed (pre elektronicky podpísané správy) a multipart/encrypted (pre správy v elektronickej obálke), tj. rozširuje MIME o hlavičky vhodné pre elektronický podpis a šifrovanie zprávy. S/MIME pre niektoré elektronické podpisy používa kompozitný typ multipart/signed, druhý kompozitný typ mulitipart/encrypted S/MIME nepoužíva. Norma RFC 1847 je všeobecnou normou, tj. špecifikuje iba všeobecný tvar správy, ktorá je elektronicky podpísaná alebo zašifrovaná. Kryptografické protokoly sú tu všeobecne vyjadrené iba reťazcom protocol=typ/subtyp. Algoritmus výpočtu kontrolného súčtu pre elektronický podpis sa všeobecne vyjadruje parametrem micalg=algoritmus. Nasledujúce normy potom rozpracovávajú jednotlivé tvary „bezpečných správ“, tj. určujú konkrétne hodnoty dosadené za typ/subtyp. Napr. dnes už temer zabudnutá norma MOSS používá reťazce application/moss-signature a application/mossencrypted všade tam, kde je v RFC 1847 uvedený reťazec typ/subtyp. Jednotlivé časti sa potom skladajú zo záhlavia oddeleného prázdnym riadkom od textu časti správy. Záhlavie je tvorené jednotlivými hlavičkami. Na nasledujúcom obrázku je schématicky znázornený tvar elektronicky podpísanej správy. 40
Elektronická pošta – MIME: Multipart/Signed a Multipart/Encrypted 41
Elektronická pošta – MIME: Multipart/Signed a Multipart/Encrypted q MIME: Multipart/Signed a Multipart/Encrypted o Zaujímavé je si uvedomiť, že hlavička Content-Type sa môže vyskytnúť až trikrát: v v v o V záhlaví celej správy elektronickej pošty, tj. v záhlaví SMTP správy RFC 822 (rozšírenej podľa MIME). Tu sa používa typ Multipart špecifikujúci, že správa je zložená z viacero častí. Ako subtyp sa zadáva informácia, či sa jedná o správu elektronicky podpísanú (Multipart/Signed) prípadne šifrovanú (Multipart/Encrypted). V prípade elektronického podpisu sa parametrom micalg špecifikuje algoritmus na výpočet kontrolného súčtu. V záhlaví prvej časti správy, tj. časti nesúcej text správy. Tu špecifikuje napr. typ znakovej sady a ďalšie parametre (napr. text/html). V záhlaví časti nesúcej elektronický podpis. Tu špecifikuje, že se jedná práve o časť nesúcu elektronický podpis. Ďalej norma RFC 1847 špecifikuje i správu typu Multipart/Encrypted, ktorú protokol S/MIME nevyužíva. 42
Elektronická pošta – S/MIME q S/MIME o Mechanizmus vytvorenia správy protokolu S/MIME je znázornený na obrázku nižšie. Správa je najprv zabezpečená protokolom CMS, potom kódovaná Base 64 do šesťbitového tvaru a nakoniec obalená hlavičkami MIME a SMTP a odoslaná elektronickou poštou. 43
Elektronická pošta – S/MIME q S/MIME o o S/MIME správy buďto podpisuje alebo vkladá do elektronickej obálky (šifruje). Pokiaľ chceme vykonať obe operácie, tj. správu aj podpísať, tak aj šifrovať, tak sa napr. elektronicky podpísaná správa vkladá do elektronickej obálky či naopak. Tj. vytvorí sa elektronicky podpísaná S/MIME správa, ktorá sa ako data vloží do elektronickej obálky – tiež S/MIME správy. Teoreticky norma pripúšťa i opačnú možnosť, tj. správu v elektronickej obálke následne podpísať, ale tento variant sa nedoporučuje. Vždy je totiž lepšie podpisovať data v pôvodnej podobe, a potom ich prípadne zašifrovať, než podpisovať už zašifrované data. Vzťah medzi podpisom a interpretáciou dát potom nemusí byť celkom doložiteľný (napr. pri súde). Vnorenie jednej S/MIME správy do druhej je teoreticky možné opakovať aj viackrát. S/MIME používa najmä jednoduché správy využívajúce typ: Content-Type: application/pkcs 7 -mime a to ako pre elektronicky podpisované správy, tak i pre správy šifrované. Klasický prípad S/MIME správy preto je: From: To: MIME-Version: 1. 0 Content-Type: application/pkcs 7 -mime Content-Transfer-Encoding: base 64 4 VQpfy. F 467 Gh. IGf. Hf. YT 6 j. H 77 n 8 HHGghy. Hh. HUujh. Jh 756 tb. B 9 HGTrfvbnj n 8 HHGTrfvh. Jhj. H 776 tb. B 9 HG 4 VQbnj 7567 Gh. IGf. Hf. YT 6 ghy. Hh. HUujpfy. F 4 7 Gh. IGf. Hf. YT 64 VQbnj 756. . . 44
Elektronická pošta – S/MIME q S/MIME o Typ application/pkcs 7 -mime môže mať niekoľko voliteľných parametrov: Parametrom name môžeme špecifikovať meno souboru (rovnaký význam má i parametr filename v prípadnej hlavičke Content-Disposition). Meno súboru môže mať najviac 8 znakov a 3 znaky rozšírenia. Ako meno súboru sa temer vždy používa „smime“ a rozšírenie môže byť: v v v . p 7 m pre MIME typ „Application/pkcs 7 -mime“ v prípade elektronicky podpísanej správy alebo správy v elektronickej obálke. . p 7 c pre MIME typ „Application/pkcs 7 -mime“ v prípade, že správa obsahuje iba degenerovanú CMS správu obsahujúcu iba certifikáty. . p 7 s pre MIME typ „Application/pkcs 7 -signature“, tj. pre kompozitnú správu. Parameter smime -type obsahuje informáciu o obsahu správy. Tj. špecifikuje, či sa jedná o podpísanú či šifrovanú správu. Áno, táto informácia sa dá poznať z vnútra správy, ale táto hlavička môže uľahčiť prácu poštového klienta pri zobrazovaní rôznych ikon so symbolmi elektronického podpisu či šifrovanie na Vašom PC, bez toho, že by dochádzalo ku komplikovanému rozboru správy. Parameter smime-type nadobúda hodnôt: enveloped-data pre správu v elektronickej obálke, signed-data pre elektronicky podpísané data, certs-only pre degenerovanú správu obsahujúcu iba certifikáty. 45
Elektronická pošta – Aké číhajú nebezpečia na adresáta q Existujú tri typy triviálnych útokov na elektronicky podpísanú správu (útoky na asymetrickú kryptografiu či na symetrické šifry neberieme do úvahy) : o o 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ť. 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 <Jan. Biely@stu. sk>“, avšak nič nebráni napísať: “Prezident republiky <Jan. Biely@stu. sk>” 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. 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í 46 založených na Windows 2000, pretože tie už podporujú CTL (Certificate Trust List).
Elektronická pošta – Aké číhajú nebezpečia na adresáta v o o 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ú. 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. 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. 47
ĎAKUJEM ZA POZORNOSŤ 48
Скачать презентацию Elektronická pošta MIME bezpečná pošta S MIME Doc Ing
9eb90113888d8d4b6323f3167765e0b5.ppt