10. Hálózati alkalmazások.

Átírás

1 10. Hálózati alkalmazások Elektronikus levelezés Fejlesztési célok A korábbi számítógépes rendszerek is lehetővé tettek kommunikációt a gépek között. Megoldott volt a fájlok cseréje is, tehát a felhasználók levelezhettek is. A napi használat számára ezek a megoldások nem voltak elég kényelmesek. Mi motiválta az új megoldásokat? - Az üzenetnek nem volt szerkezete. - A küldő sohasem tudta, hogy a levele megérkezett-e? - Nehézkes a leveleink kezelését másnak átadni. - Több embernek szeretnénk egyszerre levelet küldeni. -A felhasználói felület és az átviteli rendszer nem volt integrálva. -Nem tudtunk összetett kép (hang) adatállományt továbbítani. A feladatok megoldására több rendszer is létrejött. Egy mindenre kiterjedő, precízen kidolgozott szabvány pl.: az ISO-OSI levelezési és üzenetkezelési rendszere, az X.400-ra alapozott MOTIS (Message Oriented Text Interchange Standard). Bonyolultsága miatt néhány nagy gyártó implementálta csak, és szinte kizárólag az államigazgatásban használják. A hétköznapi gyakorlatban az ajánlásokat megfogalmazó RFC dokumentumok alapján működő rendszerek terjedtek el. Ma közé tehető a használatos levelező rendszerek száma. A különböző rendszerek között van átjárási lehetőség. Nehézséget okoz a címmezők és szolgáltatások különbözősége. Az átjárók csak a közös szolgáitatásokat tudják érvényre juttatni, és még így is megmaradnak az eltérő címzési rendszerből adódó nehézségek. A MOTIS megengedi alternatív formák definiálását, az RFC822 nem. A MOTIS üzenet tartalma lehet fax, teletext, videotext, stb. Lehetséges utasítás pl.: ha az üzenet nem küldhető el -ben, küld el faxként. Az RFC 822-re alapozott rendszerben hasonló kérés nem szolgálható ki, mert a fax kezelés nem része az RFC822-nek. 215

2 A legelterjedtebb levelező rendszerek alapját képező ajánlások: Az e-levél formátuma: Fejléc: (Header) RFC 822 (1982) Tartalom: MIME (Multipurpose Internet Mail Extensions). RFC 1341, 1521, 1522, Átviteli protokollok: Adás és továbbítás az MTA-ek (Mail Transport Agent) között SMTP: Simple Mail Transfer Protocol. RFC 821 (1982) Kézbesítési protokollok: POP3 : Post Office Protocol. RFC 1225 (1991) IMAP4 Interactive Mail Access Protocol. RFC 2060 (1996) DSMP Distributed Mail System Protocol. RFC Architechtúra. A levelező rendszerre tett javaslat alapgondolata az, hogy válasszuk szét a levél megjelenítését, szerkesztését és a továbbítási funkciókat. A két feladatcsoportot két ügynökre bízza a rendszer. Új elem a boríték ( Envelope) bevezetése, ami a tartalom és a címzés különválasztását teszi lehetővé. Felhasználói ügynök ( User Agent ) Üzenetkézbesítő ügynök ( Message Transfer Agent ) 10.1.ábra. Elektronikus levelező rendszer architecturája. 216

3 Funkciók: - szerkesztés ( composition ) - megjelenítés ( Néha speciális kezelő kell, Post Script file, hang, stb ) - kézbesítés ( transfer ) - visszajelzés ( reporting ) A címzett mit tesz az üzenettel ( eldob, elolvas, lement, stb.) Klasszikus példája a levél visszaigazolásának, mikor a címzett visszaírja : sajnos azt a levelet, amiben pénzt kértél nem kaptam meg. Fejlett funkciók - postaládák létrehozása, törlése, állományok törlése, másolatok létrehozása, stb.) - levelezési listák létrehozása és törlése - magas prioritású levelek létrehozása - indigó másolat küldése Az e-levél részei: Boríték (Envelope ) cím prioritás biztonsági szint A tartalom: fejrész törzs A fejrész vezérlőinformációt ad a felhasználói ügynöknek. A szövegrész szól az embernek. 217

4 Egy példa a fejrészre: A továbbítást végző szerverek ügynökei (MTA) által hozzáadott részek: Return-Path: <anett@morpheus.pte.hu> Delivered-To: oktato@axelero.hu Received: (qmail invoked from network); 6 Nov :40: Received: from fe03.axelero.hu (HELO darmachakra.axelero.hu) ([ ]) (envelope-sender <anett@morpheus.pte.hu>) by be03.mail.axelero.hu (qmail-ldap-1.03) with SMTP for <oktato@axelero.hu>; 6 Nov :40: Received: from localhost (localhost-05 [ ]) by darmachakra.axelero.hu ( / ) with SMTP id ha6beogb for <oktato@axelero.hu>; Thu, 6 Nov :40: (CET) Received: from fe03.axelero.hu [ ] via SMTP gateway by darmachakra.axelero.hu [ ]; id A031DA8B8DA at Thu, 06 Nov :40: Received: from morpheus.pte.hu (morpheus.pte.hu [ ]) by fe03.axelero.hu ( / ) with ESMTP id ha6beofb for <oktato@axelero.hu>; Thu, 6 Nov :40: (CET) Received: by morpheus.pte.hu (Postfix, from userid 16) id 1BD948907; Thu, 6 Nov :17: (CET) Received: from morpheus.pte.hu (localhost.localnetwork [ ]) by morpheus.pte.hu (Postfix) with ESMTP id 6ED8E87B1 for <oktato@axelero.hu>; Thu, 6 Nov :17: (CET) A küldő USER AGENT-je által hozzáadott részek: From: "=?ISO ?Q?Nagyv=E1radi?= Anett" <anett@morpheus.pte.hu> To: "Pandur" <oktato@axelero.hu> Subject: zh lista ETR Date: Thu, 6 Nov :17: Message-Id: < M58521@morpheus.pte.hu> X-Mailer: Open WebMail X-OriginatingIP: (anett) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=openwebmail_att_ " X-Spam-Checker-Version: SpamAssassin 2.50 ( exp) This is a multi-part message in MIME format =OPENWEBMAIL_ATT_ Content-Type: text/plain; charset=iso Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by fe03.axelero.hu id ha6beofb

5 A fejrész egyetlen ASC karakter sorozat. Csak angol karaktert tartalmazhat. Részei: From : levél szerzője To : címzett Cc : másodlagos címzettek Bcc : vak indigómásolat címzettje (i) Sender: aki tényleg feladta (pl.: a titkárnő) Received: minden üzenetkézbesítő ügynök hozzáad egy sort Return Path. a visszavezető útra mutat A recevied mezőtől abban különbözik, hogy tartalmazza a feladó postafiókját. Fontos, hogy a Cc-ben szereplő címeket mindenki látja. A Bcc-vel megadott címek a vevőoldalon törlődnek, és nem jelennek meg. Komoly titoksértés lehet az eredménye egy rosszul paraméterezett levélnek. Megjelenhet pl.: a cég ügyfél listája egy mindenkinek szóló üzenet esetén. A fejrész kiegészíthető új mezőkkel, ezeket a mezőket X-el kezdődő mezőnév jelöli. (A példánkban is van több ilyen mező.) A felhasználói ügynöknek szóló részek: Date Reply- to Message- ID In Reply to annak az üzenetnek az azonosítója, amire válaszolunk. References : más, kapcsolódó levelek ID-i Keywords : felhasználó által választott kulcsszavak Subjekt : tartalom összefoglalása E levelek olvasása. A felhasználói ügynök feladataí: megnézi van-e új levél megjeleníti a kivonatokat.. 219

6 Azt, hogy melyik mező legyen látható a kivonatban a felhasználói profilban adható meg. Lehetséges mezők : üzenetszám olvasottság válasz van-e? feladták-e a levél másolatát? levél mérete küldő tárgy (tartalom ) Az üzenetek továbbítása Protokollok: SMTP: továbbítja az üzeneteket a MTA között Megbízható és hatékony átvitel Hibajelzés POP3: a leveleket lehozza a szerverről a felhasználó gépére. Hitelesíti a felhasználót Olvassa a leveleket, és aktualizálja a szerveren a postafiókot. IMAP4: A levélek a szerveren adatbázis jelleggel tárolódnak, nem töltődnek le a felhasználó gépére (de letölthetők). Mód van megjelenítési feltételek megadására. Akkor előnyös, ha a felhasználó különböző gépekről akarja elérni a leveleit. A szolgáltatások bővebbek mint a POP3 esetén. (Több postafiókot használhatunk egyidőben, és javítottak biztonsági funkciókon is.) DSMP: Lehetőség van arra, hogy leveleink több szerveren legyenek. Definiálhatunk szűrőfeltételeket és a megjelenítésre is adhatunk szabályokat. Átirányíthatjuk leveleinket egy másik szerverre. Értesítést tud generálni általában egy levél, vagy meghatározott feladótól származó levél érkezéséről. 220

7 10.2.ábra. Levelezési protokollok. A legfontosabb SMTP parancsok: 10.1.ábra. SMTP parancsok. 221

8 Üzenetkézbesítés SMTP Simple Mail Transfer Protocol A forrásgép a célgép 25-ös portjával lép kapcsolatba. Megvárja amíg a fogadó szerver gép megszólal, és elküld egy egysoros azonosító üzenetet. Ha nincs válasz, később újra próbálkozik. A küldő gép elküld egy HELO vagy EHLO üzenetet. A fogadó EHLO választ csak akkor küld, ha tudja fogadni a kiterjesztett protokollt. A client elküldi a feladó címét. A szerver ellenőrzi, hogy küldő postafiók létezik-e, és visszaigazolja. Hasonló módon ellenőrzik a fogadó postafiók létét is. Ha nem találja a postafiókot, akkor a feladó visszakapja a fejrészt, és a hibakódot. Az adattovábbítás után mindkét oldal megvizsgálja, hogy van-e további üzenet. Ha nincs, akkor bontják az összeköttetést. Semmiféle ellenőrzőösszeg nem képződik! A tartalom ellenőrzése a felhasználói program feladata. Az SMTP protokollnak van egy kiterjesztett változata,az extended SMTP-ESMTP (RFC1451). Az első SMTP parancs, a HELO vagy EHLO elfogadása mutatja meg, hogy a szerver feldolgozza-e kiterjesztett protokollt. Ha a szerver az EHLO-ra nem válaszol, akkor nem tudja feldolgozni az ESMTP protokollt, csak SMTP használható. Néhány SMTP üzenet: SMTP replies (selection) 220 <domain> Service ready 221 <domain> Service closing transmission channel 250 Requested mail action okay, completed 251 User not local; will forward to <forward-path> 354 Start mail input; end with <CRLF>.<CRLF> 421 <domain> Service not available, closing transmission channel 450 Requested mail action not taken: mailbox unavailable 451 Requested action aborted: local error in processing 452 Requested action not taken: insufficient system storage 500 Syntax error, command unrecognized 501 Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented 551 User not local; please try <forward-path> 554 Transaction failed 222

9 Az üzenetek szövege lényegtelen, megváltoztatható. A rendszer az üzenetek kódját használja csak. Példa egy SMTP üzenetváltásra: Az anett@morpheus.pte.hu küld üzenetet az oktato@axelero.hu címre. SMTP client TCP TCP SMTP server TCP connection setup: client port X, server port 25 SMTP replay: 220 axelero.hu SMTP service ready SMTP command: HELO morpheus.pte.hu SMTP replay: 250 axelero.hu Hello morpheus.pte.hu,nice to meet you SMTP command: MAIL from: < anett@morpheus.pte.hu> SMTP replay: 250 <anett@morhheus.pte.hu> Sender..OK. SMTP command:rcpt To: <oktato@axelero.hu> SMTP command: DATA Mail contents SMTP command: QUIT SMTP replay: 250 <oktato@axelero.hu> Recipient OK. SMTP reply: 354 Enter mail, end with"." SMTP replay: 250 Mail accepted SMTP replay: 221 axelero.hu delivering mail TCP connections close 10.1.ábra. SMTP üzenetváltás. 223

10 A kézbesítés során néhány nehézség előfordulhat. A régebbi rendszerek nem mindegyike kezeli a 64KB-ot meghaladó leveleket. Ilyen esetben a levelek darabolása megoldást jelent. Előfordulhat a Time out ok különbözősége, ami az összeköttetés váratlan megszakításához vezethet. Vannak olyan (egyébként hibátlan) beállítások, melyek végtelen levélforgalmat tudnak generálni. Ha két hoszt kölcsönösen tartalmaz egymásra mutató automatikus továbbküldési listát, akkor előfordulhat ez a (nem túl gyakori) probléma Üzenet formátumok Az elektronikus levelek korábban csak ASCII karaktereket tartalmaztak. Az RFC822 a tartalomra csak annyi megkötést tartalmaz, hogy ASCII karakterekből állhat, és a sorhossz nem lehet nagyobb 1000 karakternél. Amíg nem akartak ékezetes karaktereket használni, és bináris adatokat továbbítani, a rendszer megfelelőnek mutatkozott. Az RFC1521 ben javasolt megoldás, a MIME (Multipurpose Internet Mail Extension) lehetővé teszi tetszőleges adatok továbbítását a korábbi levelező rendszerekkel és protokollokkal. A küldő és fogadó programok megváltoztatására van csak szükség. A MIME üzenet csak 7 bites ASCII karaktereket tartalmaz, és a kódolás biztosítja a bináris adatok átvitelét. A MIME öt új fejléc típust határoz meg. Fejrész mező MIME-Version Content-Descriription Content-ID Content-Transfer-Encoding Content-Type Jelentés Azonosítja a MIME verziót Szövegesen olvasható leírás atartalomról Egyedi azonosító A szövegrész csomagolásának módját adja meg Az üzenet jellegét adja meg 224

11 A Content-Transfer-Encoding mezőben adhatjuk meg a csomagolás módját, és azt is, ha a kódolás nem ASC-II. Ha a küldő gép pl. EBCDIC kódolást használ, akkor az SMTP szervernek kell kanonikus ASC-II formátumra átalakítani az üzenetet, hogy a leveles ládában egységes legyen a formátum. A feladatot elvileg megoldhatná a küldő gép is, de nem biztos, hogy megteszi, mert az azonos rendszerek közötti forgalomban felesleges. Az SMTP szerver nem ismeri a célállomás kódolását, így csak valami egységes formátumot küldhet ki, amit felhasználói ügynök fog a lokális szintaktikához alakítani. Az üzenetek jellegének megfelelően többféle kódolási eljárás is rendelkezésre áll. A bináris üzenetek továbbítását a base64 kódolás (base64 encoding) teszi lehetővé. Kódolási séma: Az üzenteket 24 bites csoportokra osztjuk A 24 bites csoportokat 4x6 bitre osztjuk A 6 bit bináris értékéhez egy legális ASC karaktert rendelünk. A felel meg a 0 értéknek, B az 1 számértéknek, és így tovább az angol abc szabályai szerit. A + jel 62 nek felel meg, a / jel 63. A kocsi-viszza és a soremelés nem fejez ki értéket. A sorok tördelésére használhatók, hogy ne lépjük túl a maximális 1000 karakteres sorhosszt. A majdnem ASC II formátumú dokumentumok átvitelére a base64 nem gazdaságos. Ilyen dokumentumok átvitelére használatos az idézett nyomtatható karakteres kódolás (quoted-printable encoding). A 7 bites,127 alatti kódok normális módon továbbítódnak. A 127 feletti értékeknél egy egyenlőségjelet követő két hexadecimális szám kódolja a karaktert. A Content-Type a tartalom jellegére utaló, az ajánlásban folyamatosan bővülő lista. Az üzenetben a főtípus mellett meg kell adnunk az altípust is. Pl.: Video / mpeg. A főtípus és az altípus per jellel elválasztandó. (Videó fájl, mpeg kódolással). Az átvitel mindig egyetlen típust képvisel. Tehát lehet szöveg, kép, videó, de csak egyféle, és a különböző típusokat egymás után kell továbbítani. 225

12 A videó képhez például a hangot külön kell hozzáadnunk. A többrészes üzenetek altípusaiban meglehet adni, hogy ez egy több önálló részből álló üzenet (multipart/digest), vagy egyidőben megjelenítendő (multipart/parallel), mint összetartozó kép és hang. Mód van szövegformázó parancsok beépítésére is. A text/richtext típusban használhatunk SGML (Standard Generalized Markup Language) jelölő nyelvet. Például: A <bold> halak </bold> éjféli <italic>éneke</italic> Megjelenítve: A halak éjféli éneke A fogadó oldal feladata a Content-Type alapján a megfelelő megjelenítési módszer kiválasztása. E- levél átjárók Az E -levél akkor működik a legjobban, ha mindkét fél Internetre van bekapcsolva, és közös protokollokat használnak. Elképzelhető azonban, hogy az egyik fél, vagy mindkettő gyártó- specifikus programot használ. Ilyen esetekben az alkalmazási rétegbeli átjárók segíthetnek. Az átjárók használata a vártnál több problémát vet fel a gyakorlatban, de az ismertebb rendszerek alapvető szolgáltatásai működnek E-levéllel kapcsolatos személyiségi jogok Az elektronikus levél általunk nem ismert útvonalon halad, és olyan szervereken is áthalad, ahol a tartalmat esetleg megnézik, elemzik. A továbbítás közbeni védelemre a titkosító algoritmusok alkalmasak. Az egyik gyakran alkalmazott ingyenes eljárás a PGP (Pretty Good Privacy)- elég jól biztosított személyiségi jog. A PGP meglévő eljárásokat ötvöz. Felhasználja az RSA IDEA MD5 algoritmusokat. 226

13 Az RSA működéséhez szükség van egy nyilvános adatbázisra, ahol a küldő elhelyezi a nyilvános kulcsait. A biztonság javítása érdekében mindenki több kulcsot használ. A kulcsok az u.n. nyilvános kulcsgyűrűn vannak tárolva. Több kulcs használata esetén a kulcsokat meg kell tudnunk nevezni. A kulcsot a kulcs alsó 64 bitje azonosítja. Az aktuálisan választott kulcs azonosítóját az üzenet tartalmazza. A PGP a 348 bit, 512 bit és az1024 bit hosszúságú kulcsokat támogatja. A teljes üzenetet a sebesség növelése érdekében nem kódoljuk RSA-val, csak az IDEA kulcsát. A kódolás folyamata: 10.5 ábra. PGP kódolás folyamata Az 10.5 ábrán "oktató" küld üzenetet "jnagy"-nak. Oktató és jnagy nyilvános RSA kulcsa kölcsönösen ismert. A kódolás lépései: Az eredeti üzenetből oktató PGP program meghívásával, MD5 algoritmussal legyártja Phash értékét. A Phash értéket kódolja "oktató" saját titkos kulcsával. Összefűzzük az eredeti üzenetet és a kódolt kivonatot. Tömörítjük Ziv-Lempel eljárással (P1.Z) Oktató begépel egy véletlen karakter sorozatot az IDEA számára. Az IDEA algorimus előállít egy 128 bites kulcsot A kulcsot "jnagy" nyilvános RSA kulcsával kódoljuk. IDEA-val kódoljuk P1.Z bitsorozatot A két kódsort összefűzzük 227

14 Base-64 eljárással kódolva továbbítjuk. Az üzenet szerkezete: 10.7 ábra. PGP üzenet szerkezete A megérkezett üzenet base-64-el visszakódolható. Az üzenetből leválasztható a kulcsot tartalmazó sáv, ami "jnagy" titkos kulcsával megfejthető. A kulcs birtokában visszakaphatjuk P1.Z-t, ebből pedig az eredeti üzenetet, és az aláírást. Az aláírás rész leválasztható, ebből Phash értéke oktató nyilvános kulcsával visszaállítható. Az eredeti üzenetre alkalmazva MD5 algoritmust szintén megkapjuk Phash értékét. Ha a két érték megegyezik, biztosak lehetünk benne, hogy az üzenet csak az "oktató"-tól származhat, és csak "jnagy" tudja elolvasni. Az eljárás gyengéje, hogy a kulcsok nem hitelesítettek. (Ez lehet erősség is, ha nem bízunk a hitelesítő szervezetekben). PEM - Megnövelt személyiségi jogokat biztosító levél. (Privacy Enhanced Mail) A PEM az RFC ajánlásokon alapul, az Internet szabványügyi bizottsága dolgozta ki. A kulcs -hitelesség problémáját egy kétszintű igazoló szervezet létrehozásával kívánja megoldani. A probléma az, hogy magukat kulcshitelesítőnek mondó szervezetek is lehetnek csalók, vagy gondatlanok. A kulcsok hitelességét igazoló szervezeteket, a PCA-kat ( Policy Certification Authority ) is ellenőrzi egy további hatóság, az internetes irányvonal nyilvántartó hivatal, az IPRA ( Internet Policy Registration Authority). A hatóság azt vizsgálja, hogy a hozzá bejelentkező PCA betartja-e azokat az irányelveket, amelyek a megbízható és titkos kulcskezeléshez szükségesek. A vizsgálati eredményeket közzéteszi, és a nyilvánosság szűri ki az alkalmatlanokat. 228

15 A hatósági jelleg előnye, hogy a kulcsok jogilag bizonyító erejűek, és a kompromittált kulcsok visszavonhatók. Egy visszavont kulccsal készült irat nem bizonyító erejű, mert az aláírás érvénytelen. A nyilvántartó hatóságok létével azonban az eredeti cél, a személyes jogok védelme került hátrányba. A hatóság megfelelő körülmények (bírói határozat, állami érdek) esetén a kulcsokat kiadhatja. A használat tehát annak a függvénye, hogy bízunk-e kulcshitelesítő szervezetek megfelelő működésében. Az üzenet előállítása Az eredeti üzenetet kanonikus formába hozzuk. Ennek az a célja, hogy a vezérlőkarakterek eltérő használatából adódó különbségeket a hash képzés előtt kiszűrje. MD5 (vagy MD2) segítségével elkészül az aláírás (Phash). Az üzenetet és a hash értékét összefűzzük. A megnövelt üzenetet DES algoritmussal kódoljuk. A DES kulcsot RSA-val kódoljuk, és hozzá fűzzük. Base 64-el kódolva elküldjük. A kódolás a DES gyengesége ( 56 bit ) miatt nem megfejthetetlen, de a polgári alkalmazások számára kielégítő védelmet nyújt. 229