Download presentation
Presentation is loading. Please wait.
1
Elektronická pošta, MIME, bezpečná pošta S/MIME
Doc. Ing. Ladislav Hudec, CSc. 1
2
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 je v podstate iba špecializovaný textový editor, ktorý: 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). 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. 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 IMAP4. 2
3
Elektronická pošta – architektúra, elektronická pošta pri mainframe
3
4
Elektronická pošta - architektúra
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. 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. 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ť. 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: 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
5
Elektronická pošta - architektúra
Na obrázku je znázornené fungovanie „klasickej“ elektronickej pošty na sálových počítačoch (mainframe): 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. S príchodom osobných počítačov prišiel zvrat i v používaní elektronickej pošty. 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? 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
6
Elektronická pošta – architektúra, protokoly POP3 a IMAP4
6
7
Elektronická pošta - architektúra
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): 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. 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. 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
8
Elektronická pošta - architektúra
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
9
Elektronická pošta – architektúra, prípad veľkých ISP
Front Poštová schránka používateľa "INBOX" SMTP agent SMTP Poštový server (vzdialený systém) Používateľ pri PC POP3 Privátne poštové schránky používateľae 9
10
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! 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: 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
11
Elektronická pošta – Prehľad základných hlavičiek z RFC-822
11
12
Elektronická pošta – Prehľad základných hlavičiek z RFC-822
12
13
Elektronická pošta – Prehľad základných hlavičiek z RFC-822
Príklad: Received: from mh.pvt.cz (mh.pvt.cz [ ]) by cbu.pvtnet.cz (8.8.5/8.7.3) with SMTP id PAA23028; Wed, 16 Apr :10: (MET DST) Received: from ncc.ripe.net by mh.pvt.cz with SMTP id AA08008 (5.67b/IDA-1.5 for Wed, 16 Apr :05: Received: by ncc.ripe.net id AA00228 (5.65a/NCC-2.41); Wed, 16 Apr :55: Received: from mail.freedotnet.net by ncc.ripe.net with SMTP id AA00215 (5.65a/NCC-2.41); Wed, 16 Apr :55: Received: from jon.freedotnet.net ([ ]) by homer.freedotnet.com (Netscape Mail Server v2.02) with ESMTP id AAA105 for Wed, 16 Apr :09: Reply-To: From: "Dr Jon Brody" To: Subject: Re: Role? Date: Wed, 16 Apr :58: X-Mailer: Microsoft Internet Mail Text mailu 13
14
Elektronická pošta – Prehľad základných hlavičiek z RFC-822
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ď. 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
15
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. 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ť). 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 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. 15
16
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č: 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. 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: 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 . 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
17
Elektronická pošta – Hlavičky MIME
MIME zavádza hlavičky: 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. 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
18
Elektronická pošta – Hlavičky MIME
Hlavička Mime-Version 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. 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 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 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. 18
19
Elektronická pošta – Hlavičky MIME
Hlavička Content-Type 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ľkých častí. Jedná sa napr. o typy: message, multipart, report Hlavička Content-Transfer-Encoding 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. 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). 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 19
20
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). 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ť 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 Content-Transfer-Encoding: base 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 a musia byť do tejto sady opäť prevedené pri zobrazovaní príjemcovi. Hlavička Content-ID 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. 20
21
Elektronická pošta – Hlavičky MIME
Hlavička Content-Disposition 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 Príklad (správa nesúca zvuk, ktorý sa má príjemcovi prehrať): Message-ID: Date: Sun, 20 Apr :20: From: Jan Biely X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: Subject: (no subject) Content-Type: audio/wav Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ding.wav" UklGRkYtAABXQVZFZm10IBAAAAABAAEAIlYAACJWAAABAAgAZGF0YSItAACAgICAgICAgICA ... 21
22
Elektronická pošta – Hlavičky MIME, kódovanie US-ASCII
22
23
Elektronická pošta – Hlavičky MIME, kódovanie ISO/IEC 8859-2
23
24
Elektronická pošta – Hlavičky MIME, kódovanie ISO/IEC 8859-2
24
25
Elektronická pošta – Štandardné kódovacie mechanizmy
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 Base64. Pre úplnosť sa zmienime ešte o mechanizme Radix-64, ktorý používa PGP. Quoted-printable 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 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á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: 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 25
26
Elektronická pošta – Štandardné kódovacie mechanizmy
Base64 Kódovanie Base64 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ý. 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 (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 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ú. 26
27
Elektronická pošta – Štandardné kódovacie mechanizmy
Má dva bajty (16 bitov), potom sa prvých dvanásť bitov kóduje normálne podľa tabuľky Base64. Ostatné štyri bity sa doplnia štyrmi binárnymi nulami a výsledok sa kóduje podľa tabuľky Base64. 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 Base64. Ostatné 2 bity sa doplnia dvomi binárnymi nulami na 6 bitov a výsledek se tiež kóduje Base64. Na koniec sa pridá jeden znak „=“ signalizujúci výplň dlhú 2 bity. 27
28
Elektronická pošta – Kódovanie Base64
28
29
Elektronická pošta – Štandardné kódovacie mechanizmy
Radix-64 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. Príklad (RFC-2440): -----BEGIN PGP MESSAGE----- Version: OpenPrivacy 0.99 yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS vBSFjNSiVHsuAA== =njUN -----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 Base64 kódovanie. Znaky v hlavičke, ktoré nie sú ASCII 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
30
Elektronická pošta – Jednoduché typy dat v hlavičke Content-Type
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 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 („ISO-LATIN2“), Windows-1250 a prípadne IBM850. 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. 30
31
Elektronická pošta – Jednoduché typy dat v hlavičke Content-Type
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. 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. Video Obsahom tela správy je video, implicitný podtyp je mpeg. Model Typ model je určený pre viacdimenzionálne štruktúry (napr. pre virtuálnu realitu). 31
32
Elektronická pošta – Kompozitné typy v Content-Type
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ť: 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
33
Elektronická pošta – Kompozitné typy v Content-Type
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. 33
34
Elektronická pošta – Kompozitné typy v Content-Type
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 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 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. RFC2015 zavádza typy: application/pgp-encrypted, application/pgp-signature, application/pgp-keys. 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). 34
35
Elektronická pošta – Kompozitné typy v Content-Type
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). 35
36
Elektronická pošta – Bezpečná pošta: S/MIME
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ú: 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 (OffLine). Pred tým, než zostavíme S/MIME správu, podívame sa na jednotlivé protokoly, ktoré sa tejto hry zúčastňujú. 36
37
Elektronická pošta – Správa CMS používaná v S/MIME
S/MIME používa formát správy CMS. Pritom podporuje iba nasledujúce typy CMS správ: Data, SignedData a EnvelopedData, tj. nepodporuje napr. autentizované data opisované tiež v norme CMS. V prípade elektronicky podpisovaných správ musí byť štruktúra signerInfo 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 signerInfo signingTime sMIMECapabilities sMIMEEncryptionKeyPreference Podpisované atribúty sMIMECapabilities a sMIMEEncryptionKeyPreference zavádza priamo norma S/MIME. Prvý atribút signingTime 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 sMIMECapabilities informuje odosielateľ príjemcu o kryptografických a iných algoritmoch, ktoré podporuje (aké algoritmy má použiť vo svojej prípadnej odpovedi). 37
38
Elektronická pošta – Správa CMS používaná v S/MIME, Certifikáty a CRL
Posledný atribút sMIMEEncryptionKeyPreference 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 sMIMEEncryptionKeyPreference. Certifikáty a CRL 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í SubjectAltName. Obe možnosti sú podporované, preferovaná je však adresa v rozšírení SubjectAltName. 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
39
Elektronická pošta – Certifikáty a CRL
Inou otázkou sú rozšírenia certifikátu. S/MIME vyžaduje, aby softvér podporoval rozšírenia: Basic Constraints, Key Usage, authorityKeyID, subjectKeyID a subjectAltNames. 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
40
Elektronická pošta – MIME: Multipart/Signed a Multipart/Encrypted
Norma RFC1847, 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 RFC1847 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/moss-encrypted všade tam, kde je v RFC1847 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
41
Elektronická pošta – MIME: Multipart/Signed a Multipart/Encrypted
41
42
Elektronická pošta – MIME: Multipart/Signed a Multipart/Encrypted
Zaujímavé je si uvedomiť, že hlavička Content-Type sa môže vyskytnúť až trikrát: V záhlaví celej správy elektronickej pošty, tj. v záhlaví SMTP správy RFC822 (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 RFC1847 špecifikuje i správu typu Multipart/Encrypted, ktorú protokol S/MIME nevyužíva. 42
43
Elektronická pošta – S/MIME
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á Base64 do šesťbitového tvaru a nakoniec obalená hlavičkami MIME a SMTP a odoslaná elektronickou poštou. 43
44
Elektronická pošta – S/MIME
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/pkcs7-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/pkcs7-mime Content-Transfer-Encoding: base VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj 44
45
Elektronická pošta – S/MIME
Typ application/pkcs7-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ť: .p7m pre MIME typ „Application/pkcs7-mime“ v prípade elektronicky podpísanej správy alebo správy v elektronickej obálke. .p7c pre MIME typ „Application/pkcs7-mime“ v prípade, že správa obsahuje iba degenerovanú CMS správu obsahujúcu iba certifikáty. .p7s pre MIME typ „Application/pkcs7-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
46
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) : 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 avšak nič nebráni napísať: “Prezident republiky 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í založených na Windows 2000, pretože tie už podporujú CTL (Certificate Trust List). 46
47
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ú. 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
48
ĎAKUJEM ZA POZORNOSŤ 48
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.