Acesta este capitolul 11 | Aplicat,ii^ n ret,ele | al edit,iei ...rlupsa/works/retele/retele-aplicatii.pdf · rlupsa/works/retele.pdf. c 2008, Radu-Lucian Lups,a 357 Capitolul 11

Acesta este capitolul 11 — Aplicat,ii ın ret,ele — al edit,iei electronice a cart,iiRet,ele de calculatoare, publicata la Casa Cart,ii de S, tiint,a, ın 2008, ISBN: 978-973-133-377-9.

Drepturile de autor apart,in subsemnatului, Radu-Lucian Lups,a.Subsemnatul, Radu-Lucian Lups,a, acord oricui dores,te dreptul de a copia

cont,inutul acestei cart,i, integral sau part,ial, cu condit,ia atribuirii corecte autorului s,ia pastrarii acestei notit,e.

Cartea, integrala, poate fi descarcata gratuit de la adresahttp://www.cs.ubbcluj.ro/~rlupsa/works/retele.pdf

c© 2008, Radu-Lucian Lups,a

357

Capitolul 11

Aplicat,ii ın ret,ele

11.1. Pos,ta electronica

Pos,ta electronica serves,te la transferul de mesaje electronice ıntreutilizatori aflat,i pe sisteme diferite. Protocolul a fost creat init,ial pentrumesaje text s,i a fost modificat ulterior pentru a permite transferul de fis,ierecu cont,inut arbitrar. Sistemul este conceput ın ideea ca este acceptabil catransferul mesajului sa dureze cateva ore, pentru a putea funct,iona pe sistemece nu dispun de o legatura permanenta ın ret,ea.

Pos,ta electronica este una dintre primele aplicat,ii ale ret,elelor decalculatoare s,i a fost dezvoltata ın aceeas,i perioada cu Internet-ul. Ca urmare,protocolul cuprinde prevederi create ın ideea transferului prin alte mijloacedecat o legatura prin protocol Internet.

Arhitectura sistemului cuprinde urmatoarele elemente (vezi fig. 11.1):

• Un proces de tip mail user agent (MUA), controlat de utilizatorul cedores,te expedierea mesajului. Acesta interact,ioneaza cu utilizatorulpentru a-l asista ın compunerea mesajului s,i stabilirea adresei desti-natarului. La final, mail user agent-ul trimite mesajul unui proces detip mail transfer agent (MTA). Transferul este init,iat de MUA-ul uti-lizatorului expeditor s,i utilizeaza protocolul SMTP (§ 11.1.2.1).

• O serie de procese de tip mail transfer agent care trimit fiecare urmato-rului mesajul. Transferul este init,iat de MTA-ul emit,ator s,i utilizeazatot protocolul SMTP.

• De fiecare adresa destinat,ie este raspunzator un mail transfer agent carememoreaza mesajele destinate acelei adrese. Odata mesajul ajuns la


358 11.1. Pos,ta electronica

SMTP POP3 sau IMAP

Destinatar

Mail transfer

agent (MTA)

agent (MUA)

Mail transfer

agent (MUA)

Mail userMail user

Expeditor

Mail transfer

agent (MTA) agent (MTA)

responsabil de

adresa dest.

SMTP SMTP

Figura 11.1: Elementele sistemului de transmitere a pos,tei electronice. Saget,ilearata sensul ın care se init,iaza comunicat,ia (de la client spre server), nu sensul ın carese transfera mesajul de pos,ta electronica.

mail transfer agent-ul raspunzator de adresa destinat,ie, el este memo-rat local (afara de cazul ın care are loc aici o rescriere de adresa, vezi§ 11.1.2.3).

• Utilizatorul destinat,ie cites,te mesajul cu ajutorul unui proces de tip mailuser agent. Acesta contacteaza mail transfer agent-ul responsabil deadresa utilizatorului destinat,ie s,i recupereaza mesajul de la el. Trans-ferul este init,iat de MUA (adica de receptor). Exista doua protocoaleutilizate pentru transfer: POP3 s,i IMAP.

11.1.1. Formatul mesajelorFormatul mesajelor este definit ın [RFC 2822, 2001] (care ınlocuies,te

,,clasicul“ [RFC 822, 1982]). Fiecare mesaj ıncepe cu un antet cuprinzandadresa expeditorului, adresa destinatarului, data s,i alte cateva informat,ii.Dupa antet urmeaza corpul mesajului, care cont,ine mesajul propriu-zis.

Intreg mesajul este de tip text ASCII. Randurile sunt delimitate prinsecvent,e formate din caracterul carriage return (cod 13) urmat de line feed(cod 10). Randurile nu au voie sa aiba lungime mai mare de 998 caractere s,i serecomanda sa nu aiba mai mult de 78 de caractere. Caracterele de control (cucodul ıntre 0 s,i 31 sau egal cu 127) nu sunt permise, cu except,ia secvent,elor

carriage return – line feed care separa randurile. In particular, caracterecarriage return izolate sau caractere line feed izolate nu sunt permise.


Capitolul 11. Aplicat,ii ın ret,ele 359

Pentru a permite transmiterea mesajelor prin linii seriale incapabilesa transmita caractere de 8 bit,i (ci doar caractere de 7 bit,i), este recomandabilca mesajele sa nu cont,ina caractere cu codul ıntre 128 s,i 255.

Datorita unor protocoale folosite pentru transmiterea s,i pentru sto-carea mesajelor, se impun urmatoarele restrict,ii suplimentare asupra cont,inutuluimesajelor:

• nici un rand sa nu constea doar dintr-un caracter punct;

• un rand ce urmeaza dupa un rand vid sa nu ınceapa cu cuvantul From.

De ment,ionat ca ın protocolul de comunicat,ie dintre doua mail trans-fer agent-uri sunt transferate informat,ii privind adresa expeditorului s,i adresadestinatarului, independente de cele plasate ın antetul mesajului. Acesteinformat,ii formeaza as,a-numitul plic (engl. envelope) al mesajului. Expedi-torul s,i destinatarul date ın antetul mesajului sunt informat,ii pentru utiliza-torul uman; informat,iile de pe plic sunt cele utilizate efectiv ın transmitereamesajului.

11.1.1.1. Antetul mesajelor

Antetul mesajelor este constituit dintr-un numar de campuri, fiecarecamp avand un nume s,i o valoare. De principiu, fiecare camp este un randseparat cont,inand numele, caracterul doua puncte (:) s,i valoarea; secvent,acarriage return urmat de line feed act,ioneaza ca separator ıntre campuri. An-tentul se termina cu doua secvent,e carriage return – line feed consecutive.

Daca un camp este prea lung pentru a ıncape ıntr-un rand (standardulrecomanda ca randurile sa nu depas,easca 78 de caractere s,i interzice randurilemai lungi de 998 caractere), campul poate fi continuat pe randurile urmatoare,care trebuie sa ınceapa cu spat,iu sau tab; spat,iile s,i tab-urile de la ınceputulrandurilor urmatoare se considera ca facand parte din camp.

Exemplul 11.1: Un posibil document (vezi mai jos explicat,iile privind sem-nificat,iile diverselor campuri):

From: Radu Lupsa <[email protected]>

To: Test User <[email protected]>

Date: Sat, 1 Sep 2007 10:12:20 +0300

Message-ID: [email protected]

Subject: Un mesaj dat ca

exemplu

Salut,

Mesajul acesta este doar un exemplu.



Principalele campuri ce pot apare ıntr-un mesaj sunt:

• To, Cc s,i Bcc reprezinta adresele la care trebuie livrat mesajul.Adresele din campul To reprezinta persoanele carora le este adresat

mesajul.Adresele din campul Cc reprezinta persoane ce trebuie informate

de trimiterea mesajului; de exemplu, ın corespondent,a oficiala ıntre unangajat al unei firme s,i un client al firmei, angajatul va pune adresaclientului ın campul To (deoarece acestuia ıi este destinat mesajul), iarın campul Cc va pune adresa s,efului (care trebuie informat cu privire lacomunicat,ie).

Adresele din campul Bcc reprezinta pesoane carora le va fi livratmesajul, fara ca ceilalt,i destinatari sa fie informat,i despre aceasta. CampulBcc este completat de catre mail user agent s,i este eliminat de catreprimul mail transfer agent de pe traseu.

• From, Sender s,i Reply-to reprezinta adresa expeditorului s,i adresa lacare trebuie raspuns.

In condit,ii obis,nuite, un mesaj cont,ine doar campul From, reprezentandadresa expeditorului mesajului s,i totodata adresa la care trebuie trimisun eventual raspuns.

Campul Sender este utilizat atunci cand o persoana trimite unmesaj ın numele altei persoane sau ın numele unei organizat,ii pe care oreprezinta. Exista doua situat,ii practice care conduc la aceasta situat,ie:Daca mesajul provine de la s,ef, dar este scris s,i trimis efectiv de secre-tara s,efului, atunci adresa s,efului este pusa ın campul From, iar adresasecretarei ın campul Sender. Daca o persoana trimite un mesaj ın nu-mele unei organizat,ii, atunci adresa organizat,iei va fi trecuta ın campulFrom s,i adresa persoanei ce scrie mesajul va fi plasata ın campul Sender.

In fine, campul Reply-to reprezinta adresa la care trebuie trimisun eventual raspuns la mesaj, daca aceasta adresa este diferita de adresadin campul From. Daca destinatarul raspunde la un mesaj primit, uti-lizand funct,ionalitatea de reply amail user agent-ului sau, MUA-ul oferaimplicit, ca adresa destinat,ie a mesajului de raspuns, adresa preluata din

campul Reply-to a mesajului original. In lipsa unui camp Reply-to,MUA-ul ofera adresa din campul From. De asemenea, chiar ın prezent,aunui camp Reply-to, este bine ca MUA-ul sa ofere posibilitatea de-atrimite raspunsul la adresa din campul From.

Un exemplu de utilizare a campului Reply-to este urmatorul:un mesaj adresat unei liste de discut,ii are ca From adresa autorului



mesajului s,i ca To adresa listei. Mesajul se transmite centrului dedistribut,ie al listei (un mail transfer agent), care retransmite mesajulcatre abonat,ii listei. Mesajul retransmis catre abonat,i va avea adaugatun camp Reply-to indicand adresa listei. Astfel, mesajul primit deabonat are From autorul mesajului, To adresa listei s,i Reply-to totadresa listei. Abonatul listei va raspunde foarte us,or pe adresa listeideoarece mail user agent-ul sau va prelua adresa listei din Reply-to s,io va pune ca adresa destinat,ie ın mesajul de raspuns. Totus,i, e bine cautilizatorul sa nu foloseasca orbes,te aceasta facilitate, ıntrucat uneoriraspunsul este bine sa ajunga doar la autorul mesajului original, nu latoata lista. . .

• Received s,i Return-path au ca rol diagnosticarea sistemului de livrare amesajelor. Fiecare mail transfer agent de pe traseul mesajului adaugaın fat,a mesajului un camp Received ın care scrie numele mas,inii sale,numele s,i adresa IP a mail transfer agent-ului care i-a trimis mesajul,data s,i ora curenta s,i emit,atorul s,i destinatarul mesajului conform cereriimail transfer agent-ului care ıi transmite mesajul (cei indicat,i pe ,,plicul“mesajului, nu cei din campurile To sau From). Astfel, un mesaj ıncepecu un s,ir de antete Received cont,inand, ın ordine inversa, nodurile princare a trecut mesajul.

Ultimul mail transfer agent adauga un camp Return-path, con-t,inand adresa sursa a mesajului conform plicului (datele furnizate deMTA-ul sursa).

Campurile Received s,i Return-path sunt utilizate pentru a re-turna un mesaj la autorul sau ın cazul ın care apar probleme la livrareamesajului. De notat diferent,a ıntre Reply-to, care reprezinta desti-natarul unui eventual raspuns dat de utilizator la mesaj, s,i Return-path,care reprezinta destinatarul unui eventual mesaj de eroare.

• Date reprezinta data generarii mesajului. Este ın mod normal completatde mail user agent-ul expeditorului mesajului. Are un format standard,cuprinzand data s,i ora locala a expeditorului precum s,i indicativul fusu-lui orar pe care se gases,te expeditorul. Formatul cuprinde: ziua dinsaptamana (prescurtare de trei litere din limba engleza), un caractervirgula, ziua din luna, luna (prescurtarea de trei litere din limba en-gleza), anul, ora, un caracter doua puncte, minutul, opt,ional ınca uncaracter doua puncte urmat de secunda s,i ın final indicativul fusuluiorar. Indicativul fusului orar cuprinde diferent,a, ın ore s,i minute, ıntreora locala s,i ora universala coordonata (UTC ; vezi § 7.3.1 pentru de-talii). Faptul ca ora locala este ora de vara sau nu apare ın indicativul



de fus orar. Romania are ın timpul iernii ora locala egala cu UTC+2h,iar ın timpul verii UTC+3h.

• Subject reprezinta o scurta descriere (cat mai sugestiva) a mesajului,data de autorul mesajului.

• Message-ID, In-reply-to, Reference servesc la identificarea mesajelor.Valoarea campului Message-ID este un s,ir de caractere care identificaunic mesajul. El este construit de catre mail user agent-ul expeditoruluipornind de la numele calculatorului, de la ora curenta s,i de la nis,tenumere aleatoare, astfel ıncat sa fie extrem de improbabil ca doua mesajesa aiba acelas,i Message-ID.

In cazul raspunsului la un mesaj prin funct,ia reply a mail useragent-ului, mesajul de raspuns cont,ine un camp In-reply-to avand cavaloare Message-ID-ul mesajului la care se raspunde. Valoarea campuluiReference se creaza din campurile Reference s,i Message-ID ale mesaju-lui la care se raspunde. Campurile Reference s,i Message-ID pot fifolosite de exemplu pentru afis,area, de catremail user agent-ul destinat,ie,a succesiunilor de mesaje legate de o anumita problema s,i date fiecareca replica la precedentul.

• Resent-from, Resent-sender, Resent-to, Resent-cc, Resent-bcc,Resent-date s,i Resent-msg-id sunt utilizate daca destinatarul unuimesaj dores,te sa retrimita mesajul, fara modificari, catre altcineva. Oastfel de retrimitere se poate efectua printr-o comanda bounce sau re-send a MUA-ului. In acest caz, campurile din antetul mesajului original(inclusiv From, To sau Date) sunt pastrate, reflectand expeditorul, desti-natarii s,i data trimiterii mesajului original. Pentru informat,iile privindretransmiterea (adresa utilizatorului ce efectueaza retransmiterea, des-tinatarii mesajului retransmis, data retransmiterii, etc.), se utilizeazacampurile Resent-. . . enumerate mai sus. Semnificat,ia fiecaruia dintreaceste campuri Resent-. . . este identica cu semnificat,ia campului faraResent- corespunzator, dar se refera la retransmitere, nu la mesajuloriginal.

11.1.1.2. Extensii MIME

Standardul original pentru mesaje de pos,ta electronica (rfc 822) asuferit o serie de extensii. Acestea sunt cunoscute sub numele Multipur-pose Internet Mail Extension (MIME ) s,i sunt descrise ın [RFC 2045, 1996],[RFC 2046, 1996] s,i [RFC 2047, 1996].



Extensiile MIME servesc ın principal pentru a putea transmite fis,iereatas,ate unui mesaj de pos,ta electronica.

Un mesaj conform standardului MIME trebuie sa aiba un camp ınantet cu numele Mime-version. Valoarea campului este versiunea standardu-lui MIME ın conformitate cu care a fost creat mesajul.

11.1.1.3. Atas,area fis,ierelor s,i mesaje din mai multe part,iStandardul MIME ofera posibilitatea atas,arii unor fis,iere la un mesaj

de pos,ta electronica. Mecanismul se ıncadreaza ıntr-unul mai general, carepermite formarea unui mesaj din mai multe part,i. Un mesaj cu atas,amenteeste dat ın exemplul 11.2.

Fiecare mesaj are ın antet un camp, Content-type, care arata cetip de date cont,ine s,i ın ce format sunt ele reprezentate. Exemple de tipurisunt: text/plain (text normal), text/html (document HTML), image/jpeg(imagine ın format JPEG), etc.

De regula, partea din fat,a caracterului slash (/) arata tipul de docu-ment, iar partea a doua arata formatul (codificarea) utilizata. Astfel, o imag-ine va avea Content-type de forma image/format ; de exemplu, image/gif,image/jpeg, etc.

Mesajele ce cont,in doar text obis,nuit trebuie sa aiba Content-type:

text/plain. Acesta este dealtfel tipul implicit ın cazul absent,ei campuluiContent-type.

Mesajele cu atas,amente au Content-type: multipart/mixed. Ingeneral, un mesaj de tip multipart/subtip este format de fapt din mai multe,,fis,iere“ (oarecum ca un fis,ier arhiva zip). Intr-un mesaj multipart/mixed,de obicei una dintre part,i este mesajul propriu-zis, iar fiecare dintre celelaltepart,i este cate un fis,ier atas,at.

Fiecare parte a unui mesaj multipart are un antet s,i un corp, similarcu un mesaj de sine statator. Antetul part,ii poate cont,ine doar campurispecificeMIME. Astfel, fiecare parte are propriul tip, care poate fi ın particularchiar un multipart.

Cele mai importante subtipuri ale tipului multipart sunt:

• multipart/mixed ınseamna pur s,i simplu mai multe componente puseımpreuna, ca un fis,ier arhiva.

• multipart/alternative arata ca part,ile sunt variante echivalente aleaceluias,i document, ın formate diferite.

Separarea part,ilor unui mesaj de tip multipart se face printr-unrand ce cont,ine un anumit text, ce nu apare ın nici una dintre part,ile mesaju-lui. Textul utilizat ca separator este plasat ın campul Content-type dupa



multipart/subtip. Este scris sub forma (utilizabila s,i ın alte campuri s,i pen-tru alte informat,ii) unui s,ir boundary=s,ir situat dupa s,irul multipart/subtips,i separat prin punct s,i virgula fat,a de aceasta. Exemplu:

Content-type: multipart/mixed; boundary="abcdxxxx"

Corpul mesajului multipart este separat dupa cum urmeaza:

• ın fat,a primei part,i precum s,i ıntre fiecare doua part,i consecutive segases,te un rand format doar din textul de dupa boundary= precedat dedoua caractere minus (--);

• dupa ultima parte se gases,te un rand format doar din textul de dupaboundary=.

Fiecare parte a unui mesaj de tip multipart/mixed are un campContent-disposition [RFC 2183, 1997]. Valoarea acestui camp arata cetrebuie sa faca mail user agent-ul destinat,ie cu partea de mesaj ın care segases,te acest antet. Valori posibile sunt:

• inline arata ca mesajul sau partea de mesaj trebuie sa fie afis,ata uti-lizatorului;

• attachment arata ca mesajul sau partea de mesaj nu trebuie afis,atadecat la cerere. Un astfel de camp poate avea ın continuare o informat,iesuplimentara, filename=nume, arata numele sugerat pentru salvareapart,ii respective. De notat ca, din motive de securitate, mail user agent-ul destinat,ie trebuie sa nu salveze orbes,te partea de mesaj sub numele

extras din mesaj, ci sa ceara mai ıntai permisiunea utilizatorului. In cazcontrar, un adversar poate sa trimita un fis,ier avand atas,at un anumitfis,ier, cu care sa suprascrie un fis,ier al destinatarului.

11.1.1.4. Codificarea corpului mesajului s,i a atas,amentelorStandardul original al formatului mesajelor prevede ca mesajele con-

t,in doar text ASCII, cu utilizare restrict,ionata a caracterelor de control. Sin-gurele caractere de control (cele cu codurile ıntre 0 s,i 31) admise sunt carriagereturn (cod 13) s,i line feed (cod 10), utilizate pentru separarea randurilor dinmesaj. De asemenea, se recomanda sa nu se utilizeze caracterele cu coduriıntre 128 s,i 255, datorita imposibilitat,ii transmisiei lor ın unele sisteme.

Ca urmare, transmiterea unui fis,ier arbitrar (inclusiv a unui textISO-8859) nu este posibila direct.

Transmiterea unui cont,inut arbitrar se face printr-o recodificare aacestuia utilizand doar caracterele permise ın corpul mesajului. Ca urmare,



mesajele apar, fat,a de mail transfer agent-uri, identice cu cele conforme for-matului original. Un mail user agent vechi, conform standardului original, nuva fi capabil sa transmita un mesaj cu extensii MIME, iar ın cazul primirii unuiastfel de mesaj ıl va afis,a ıntr-un mod mai put,in inteligibil pentru utilizator.

Recodificarea este aplicata doar asupra corpului mesajului, nu s,iasupra antetului. Antetul cont,ine un camp, Content-transfer-encoding,a carui valoare arata daca s,i ce recodificare s-a aplicat asupra cont,inutului.Codificarile definite de [RFC 2045, 1996] sunt:

• 7bit — ınseamna de fapt lipsa oricarei recodificari. In plus, arata camesajul nu cont,ine decat caractere ASCII (cu codurile cuprinse ıntre 0s,i 127).

• 8bit — arata ca mesajul nu a fost recodificat, dar poate cont,ine oricecaractere (cu coduri ıntre 0 s,i 255).

• quoted-printables — arata ca fiecare caracter de control s,i fiecare car-acter egal (=) a fost recodificat ca o secvent,a de trei caractere, formatadintr-un caracter egal (=) urmat de doua cifre hexa; acestea din urmareprezinta codul caracterului original. De exemplu, caracterul egal serecodifica =3D, iar caracterul escape (cod 27) se recodifica =1B. Restulcaracterelor pot fi scrise direct sau pot fi recodificate ca s,i caracterelespeciale; de exemplu litera a poate fi scrisa a sau =61.

• base64 — corpul mesajului a fost recodificat ın baza 64 (vezi § 7.4.2).

In lipsa vreunui antet Content-transfer-encoding, se presupunecodificarea 7bit.

Pentru un mesaj (sau o parte de mesaj) de tip multipart, mesajul(respectiv partea) nu este permis sa fie codificat decat 7bit sau 8bit, ınsafiecare parte a unui multipart poate fi codificata independent de restul. Inmod curent, un mesaj cu atas,amente are corpul mesajului codificat 7bit,partea corespunzatoare mesajului propriu-zis este codificata 7bit sau quoted-printables,iar part,ile corespunzatoare atas,amentelor sunt codificate base64.

Exemplul 11.2: Un mesaj cu fis,iere atas,ate este dat ın continuare:

From: Radu Lupsa <[email protected]>

To: Test User <[email protected]>

Date: Sat, 1 Sep 2007 10:12:20 +0300


Subject: Un mesaj cu fisiere atasate

MIME-Version: 1.0

Content-transfer-encoding: 7bit

Content-type: multipart/mixed; boundary="qwertyuiop"



--qwertyuiop

Content-type: text/plain

Content-transfer-encoding: 7bit

Content-disposition: inline

Acesta este mesajul propriu-zis.

--qwertyuiop

Content-type: application/octet-stream

Content-disposition: attachment; filename="test.dat"

Content-transfer-encoding: base64

eAAXLRQ=

--qwertyuiop

Content-type: text/plain; charset=utf-8

Content-disposition: attachment; filename="test.txt"

Content-transfer-encoding: quoted-printables

=C8=98i =C3=AEnc=C4=83 un text.

qwertyuiop

11.1.2. Transmiterea mesajelorAs,a cum am vazut, mesajele sunt transmise din aproape ın aproape,

fiecare mesaj parcurgand un lant, de MTA-uri. Fiecare MTA, cu except,iaultimului, determina urmatorul MTA s,i-i paseaza mesajul.

11.1.2.1. Protocolul SMTP

Protocolul utilizat pentru transmiterea mesajelor de la un MTA laurmatorul este protocolul Simple Mail Transfer Protocol — SMTP . Este unprotocol de tip text, construit de obicei peste o conexiune TCP.

Rolul de client SMTP ıl are MTA-ul ce are mesajul de trimis maideparte; rolul de server apart,ine MTA-ului ce primes,te mesajul. Clientuldeschide o conexiune TCP catre portul 25 al serverului.

Dupa deschiderea conexiunii, serverul trimite un mesaj cont,inand un

cod de raspuns urmat de numele serverului. In continuare, clientul trimite cateo cerere, la care serverul raspunde cu un cod ce arata daca cererea a fost exe-cutata cu succes sau nu, urmat de un text explicativ. Cererile sunt formate deregula dintr-un cuvant-cheie urmat de eventuali parametri s,i se ıncheie printr-o secvent,a carriage return – line feed. Raspunsurile sunt formate dintr-unnumar, transmis ca secvent,a de cifre, urmat de un text explicativ. Numarul



arata, ıntr-o forma us,or de procesat de catre calculator, daca cererea s-a exe-cutat cu succes sau nu s,i cauza erorii. Textul cuprinde informat,ii suplimentarepentru diagnosticarea manuala a transmiterii mesajelor.

Clientul trebuie sa ınceapa printr-o cerere HELO care are ca parametrunumele mas,inii clientului. Prin aceasta clientul se identifica fat,a de server. Denotat ca nu exista posibilitatea autentificarii clientului de catre server; serveruleste nevoit sa ,,ia de bun“ numele transmis de client.

Dupa identificarea prin cererea HELO, clientul poate transmite serveru-lui mai multe mesaje de pos,ta electronica.

Transmiterea fiecarui mesaj va ıncepe printr-o cerere MAIL FROM:,avand ca parametru adresa expeditorului mesajului. Dupa acceptarea decatre server a comenzii MAIL FROM:, clientul va trimite una sau mai multecereri RCPT TO:; fiecare cerere are ca parametru o adresa destinat,ie. Fiecarecerere RCPT TO: poate fi acceptata sau refuzata de catre server independentde celelalte. Serverul va transmite mesajul fiecareia dintre adresele destinat,ie

acceptate. In final, clientul trimite o cerere DATA fara parametrii. Serverulraspunde, ın mod normal cu un cod de succes. In caz de succes, clientul trim-ite corpul mesajului, ıncheiat cu un rand pe care se gases,te doar caracterulpunct. Dupa primirea corpului mesajului, serverul trimite ınca un raspuns.

Mesajele primite de MTA sunt plasate ıntr-o coada de as,teptare, sto-cata de obicei ın fis,iere pe disc. MTA-ul receptor ıncearca imediat sa trimitamai departe fiecare mesaj primit. Daca trimiterea mai departe nu este posi-bila imediat, mesajul este pastrat ın coada s,i MTA-ul reıncearca periodic sa-ltrimita. Dupa un numar de ıncercari es,uate sau ın cazul unei erori netempo-rare (de exemplu, daca nu exista adresa destinat,ie), MTA-ul abandoneaza s,iıncearca trimiterea unui mesaj (e-mail) de eroare ınapoi catre expeditor.

Daca adresa destinat,ie este locala, MTA-ul plaseaza mesajul ın fis,ierulcorespunzator cutiei pos,tale a destinatarului.

De notat ca ın trimiterea mai departe, livrarea locala sau trimitereaunui mesaj de eroare, MTA-ul utilizeaza doar informat,iile de pe plic, adicaparametrii comenzilor MAIL FROM: s,i RCPT TO:, s,i nu valorile campurilor Fromsau To din antetul mesajului.

Exemplul 11.3: Fie mesajul din exemplul 11.1. Transmiterea lui de la MTA-ul de pe cs.ubbcluj.ro catre example.com decurge astfel (randurile trans-mise de la cs.ubbcluj.ro la example.com sunt precedate de o sageata ladreapta, iar randurile transmise ın sens invers de o sageata la stanga):

← 220 example.com

→ HELO nessie.cs.ubbcluj.ro



← 250 example.com

→ MAIL FROM: <[email protected]>

← 250 Ok

→ RCPT TO: <[email protected]>

← 250 Ok

→ DATA

← 354 End data with <CR><LF>.<CR><LF>

→ From: Radu Lupsa <[email protected]>

→ To: Test User <[email protected]>

→ Date: Sat, 1 Sep 2007 10:12:20 +0300

→ Message-ID: [email protected]

→ Subject: Un mesaj dat ca

→ exemplu

→ Salut,

→ Mesajul acesta este doar un exemplu.

→ .

← 250 Ok: queued

→ QUIT

← 221 Bye

Exemplul 11.4: Urmatorul mesaj ilustreaza utilizarea campurilor ın cazulunui mesaj transmis unei liste de utilizatori. Mesajul este reprodus as,a cumajunge la un abonat al listei, avand adresa [email protected]. Mesajul ilus-treaza, de asemenea, utilizarea campului Sender de catre cineva care transmiteun mesaj ın numele altcuiva s,i a campului Cc.

Return-path: [email protected]

Received: from server27.comunitati-online.example

by example.com for [email protected]; 31 Aug 2007 22:09:23 -0700

Reply-to: Forumul OZN <[email protected]>

Received: from roswell.greenmen.example

by server27.comunitati-online.example

for [email protected]; 1 Sep 2007 05:09:21 +0000

Received: from localhost by roswell.greenmen.example

for [email protected]; 1 Sep 2007 08:09:20 +0300

From: Organizatia omuletilor verzi <[email protected]>

Sender: Ion Ionescu <[email protected]>

To: Forumul OZN <[email protected]>

Cc: Organizatia omuletilor verzi <[email protected]>

Date: Sat, 1 Sep 2007 10:12:20 +0300


In-reply-to: [email protected]



Subject: Re: Incident

Organizatiei omuletilor verzi anunta ca nu a avut

nici un amestec in incidentul de la balul anual E.T.

Ion Ionescu,

Presedintele Organizatiei omuletilor verzi

11.1.2.2. Determinarea urmatorului MTA

Un MTA care are un mesaj de transmis catre o anumita adresa de-termina urmatorul MTA caruia trebuie sa-i transmita mesajul astfel:

1. MTA-ul cauta mai ıntai, printre informat,iile sale de configurare (vezi§ 11.1.2.3), daca are vreo regula privind adresa destinat,ie. Daca MTA-ul este responsabil de adresa destinat,ie a mesajului, ıl memoreaza lo-cal. Daca MTA-ul este poarta de intrare a mesajelor pentru MTA-uriledin ret,eaua locala, transmite mesajul catre MTA-ul determinat conformconfigurarii.

2. Daca nu exista informat,ii de configurare pentru adresa destinat,ie, MTA-ul cauta ın DNS o ınregistrare cu tipul MX pentru numele de dome-niu din adresa destinat,ie. O astfel de ınregistrare cont,ine una sau maimulte nume de servere SMTP capabile sa preia mesajele destinate uneiadrese din acel domeniu. Daca gases,te o astfel de ınregistrare, MTA-ulcontacteaza una din mas,inile specificate ın ınregistrarile MX gasite s,i-itransmite mesajul.

3. Daca nu exista nici ınregistrari MX, MTA-ul contacteaza mas,ina cunumele de domeniu din adresa destinat,ie s,i-i transmite mesajul.

4. Daca nu exista nici un server cu numele de domeniu din adresa destinat,ie,adica daca toate cele trei variante de mai sus es,ueaza, atunci MTA-uldeclara ca mesajul este nelivrabil s,i transmite ınapoi spre emit,ator unmesaj de eroare.

Un MUA lucreaza, de obicei, mult mai simplu. Acest lucru duce lasimplificarea MUA-ului prin separarea clara a rolurilor: MUA-ul trebuie saofere facilitat,i de editare s,i sa prezinte utilizatorului o interfat,a prietenoasa,iar MTA-ul are toate complicat,iile legate de livrarea mesajelor. Pentru trans-miterea oricarui mesaj, un MUA contacteaza un acelas,i MTA, a carui adresaeste configurata ın opt,iunile MUA-ului. Pe sistemele de tip UNIX, MUA-urilecontacteaza implicit MTA-ul de pe mas,ina locala (localhost).



11.1.2.3. Configurarea unui MTADe cele mai multe ori, un MTA este resposnabil de adresele utiliza-

torilor calculatoarelor dintr-o ret,ea locala. In acest caz, MTA-ul memoreazalocal mesajele adresate acestor utilizatori s,i le ofera acestora posibilitatea dea le citi prin IMAP sau POP3. De asemenea, MTA-ul preia s,i transmite spreexterior mesajele utilizatorilor, generate de MUA-urile ce ruleaza pe calcula-toarele din ret,eaua locala.

In configurat,ii mai complicate, un MTA act,ioneaza ca punct de tre-cere pentru mesajele care pleaca sau sosesc la un grup de MTA-uri dintr-oret,ea locala. El preia mesajele de la toate MTA-urile din ret,eaua locala ınscopul retransmiterii lor catre exterior. De asemenea, preia mesajele din exte-rior destinate tuturor adreselor din ret,eaua locala s,i le retrimite MTA-urilor,din ret,eaua locala, responsabile. Un astfel de MTA este numit mail gateway.Un mail gateway poate fi util ca unic filtru contra virus,ilor s,i spam-urilor pen-tru o ıntreaga ret,ea locala (ın opozit,ie cu a configura fiecare MTA din ret,eaualocala ca filtru).

Un MTA trebuie configurat cu privire la urmatoarele aspecte:

• care sunt adresele locale s,i cum se livreaza mesajele destinate acestoradrese;

• care sunt mas,inile (ın principiu, doar din ret,eaua locala) de la care seaccepta mesaje spre a fi trimise mai departe spre Internet;

• ce transformari trebuie aplicate mesajelor.

Implicit, un MTA considera ca fiind adrese locale acele adrese careau numele de domeniu identic cu numele mas,inii pe care ruleaza MTA-ul s,iavand partea de utilizator identica cu un nume de utilizator al mas,inii locale.Pe sistemele de operare de tip UNIX, un mesaj adresat unui utilizator localeste adaugat la finalul unui fis,ier avand ca nume numele utilizatorului s,i situatın directorul /var/mail.

MTA-ul responsabil de o anumita adresa destinat,ie poate fi configuratde catre utilizatorul destinatar sa execute anumite prelucrari asupra mesajuluiprimit. Pe sistemele de tip UNIX, aceasta configurare se face prin directiveplasate ın fis,ierele .forward s,i .procmailrc din directorul personal al utiliza-torului.

Fis,ierul .forward cont,ine un s,ir de adrese la care trebuie retrimismesajul ın loc sa fie livrat local ın /var/mail/user.

Fis,ierul .procmailrc cuprinde instruct,iuni mai complexe de proce-sare a mesajelor primite: ın funct,ie de aparit,ia unor s,iruri, descrise prin ex-presii regulare, ın mesajul primit, mesajul poate fi plasat ın fis,iere specificate



ın .procmailrc sau poate fi pasat unor comenzi care sa-l proceseze.Pentru cazuri mai complicate, un MTA poate fi configurat de catre

administrator sa execute lucruri mai complicate:

• Este posibil sa se configureze adrese de pos,ta, situate ın domeniul numeluimas,inii locale, care sa fie considerate valide chiar daca nu exista utiliza-tori cu acele nume. Pentru fiecare astfel de adresa trebuie definita o listade adrese, de regula locale, la care se va distribui fiecare mesaj primit.Ca exemplu, adresa [email protected] este configurata ın acest fel;un mesaj trimis la aceasta adresa nu este plasat ın /var/mail/root cieste retrimis utilizatorilor (configurat,i ın fis,ierul /etc/aliases) care seocupa de administrarea sistemului.

• Un MTA poate fi configurat sa se considere responsabil de mai multedomenii, ale caror nume nu au nimic comun cu numele mas,inii MTA-ului.De exemplu, se poate configura MTA-ul de pe nessie.cs.ubbcluj.ro

sa accepte mesajele destinate lui [email protected] s,i sa le livreze uti-lizatorului local gheorghe. Desigur, pentru ca un mesaj destinat [email protected] sa poata fi livrat, mai trebuie ca mesajul sa ajungapana la nessie.cs.ubbcluj.ro. Pentru aceasta, trebuie ca MUA-ul ex-peditor sau un MTA de pe traseu sa determine ca urmator MTA mas,inanessie.cs.ubbcluj.ro, lucru care se ıntampla daca ın DNS se puneo ınregistrare MX pentru numele de domeniu example.com indicandcatre nessie.cs.ubbcluj.ro. Un astfel de mecanism este utilizat ınmod curent de furnizorii de servicii Internet pentru a gazdui pos,ta elec-tronica a unor client,i care au nume propriu de domeniu dar nu det,inservere de pos,ta electronica care sa preia pos,ta adresata adreselor dindomeniul respectiv.

• Daca utilizatorii expediaza mesaje de pe mai multe mas,ini dintr-o ret,ealocala, nu este de dorit ca numele mas,inii interne sa apara ın adresa depos,ta electronica. De exemplu, daca un acelas,i utilizator are cont pemai multe mas,ini, nu este de dorit ca adresa expeditorului sa depindade mas,ina de pe care utilizatorul scrie efectiv mesajul. De exemplu, nueste de dorit ca daca scrie un mesaj pe mas,ina linux.scs.ubbcluj.ro

mesajul sa apara avand adresa sursa From: [email protected],iar daca ıl scrie de pe freebsd.scs.ubbcluj.ro sa apara cu adresaFrom: [email protected]. Pentru aceasta, MTA-ul carese ocupa de livrarea spre exterior a mesajelor generate ın ret,eaua in-terna va schimba, atat ın antetul mesajului (valoarea campului From)cat s,i pe ,,plic“ (valoarea parametrului comenzii SMTP MAIL FROM:),adresa expeditorului, eliminand numele mas,inii locale s,i pastrand doar



restul componentelor numelui de domeniu. In exemplul de mai sus, dinadresa ramane doar [email protected]. Modificarea poate fi maicomplexa: astfel, daca nessie.cs.ubbcluj.ro este configurat sa ac-cepte mesajele destinate lui [email protected] s,i sa le livreze utilizatoru-lui local gheorghe, este probabil de dorit ca pentru mesajele compusede utilizatorul local gheorghe sa faca transformarea adresei sursa [email protected] ın [email protected].

• Un alt element important de configurare prives,te decizia unui MTA de a

accepta sau nu spre livrare un mesaj. In mod normal, un MTA trebuie saaccepte mesajele generate de calculatoarele din ret,eaua locala s,i mesajeledestinate adreselor locale, dar sa nu accepte trimiterea mai departe amesajelor provenite din exterior s,i destinate ın exterior. Un MTA careaccepta spre livrare orice mesaje este numit ın mod curent open relay.Un open relay este privit de obicei ca un risc pentru securitate, deoareceeste adesea utilizat de utilizatori rau-voitori pentru a trimite mesajeascunzandu-s,i identitatea.

11.1.3. Securitatea pos,tei electronicePrincipalele probleme privind securitatea sunt:

• spoofing-ul — falsificarea adresei sursa (From sau Sender);

• spam-urile — mesaje, de obicei publicitare, trimise unui numar mare depersoane s,i fara a fi legate de informat,ii pe care destinatarii le-ar dori;

• virus,ii — programe executabile sau documente, atas,ate unui mesaj elec-tronic, a caror execut,ie sau respectiv vizualizare duce la trimiterea demesaje electronice catre alt,i destinatari.

Falsificarea adresei sursa este extrem de simpla deoarece, ın trans-miterea obis,nuita a mesajelor, nu este luata nici o masura de autentificare aexpeditorului.

Falsificarea adresei sursa (spoofing) poate fi depistata ın anumitecazuri examinand campurile Received din antetul mesajului s,i verificand dacaexista neconcordant,e ıntre numele declarat prin HELO a unui client SMTPs,i adresa sa IP sau neconcordant,e ıntre numele primului MTA s,i partea dedomeniu din adresa expeditorului. De notat ca anumite neconcordant,e pot filegitime, ın cazul ın care casut,ele pos,tale dintr-un domeniu sunt t,inute de uncalculator al carui nume nu face parte din acel domeniu (vezi § 11.1.2.3).

O metoda mai eficienta pentru depistarea falsurilor este utilizareasemnaturii electronice. Exista doua standarde de semnatura electronica uti-lizate, OpenPGP [RFC 2440, 2007, RFC 3156, 2001] s,i S-MIME [S/MIME, ].



Verificarea semnaturii necesita ınsa ca destinatarul sa dispuna de cheia publicaautentica a expeditorului. Pana la generalizarea utilizarii mesajelor semnate,sistemul de pos,ta electronica trebuie sa asigure livrarea mesajelor nesemnates,i ın consecint,a cu risc de a fi falsificate.

Us,urint,a falsificarii adresei sursa s,i us,urint,a pastrarii anonimatuluiautorului unui mesaj a dus la proliferarea excrocheriilor. Adesea excrocheriileconstau ın trimiterea de mesaje unui numar mare de utilizatori (acest faptın sine este spam) ın sperant,a de-a gasi printre aces,tia unii care sa se lasepacalit,i.

Spam-urile dauneaza deoarece consuma ın mod inutil timpul desti-natarului. In plus, exista riscul ca un mesaj legitim, ,,ıngropat“ ıntre multespam-uri, sa fie s,ters din gres,eala.

Exista detectoare automate de spam-uri, bazate pe diferite metodedin domeniul inteligent,ei artificiale. Astfel de detectoare se instaleaza peMTA-uri s,i resping sau marcheaza prin antete speciale mesajele detectate caspam-uri. Un MTA care detecteaza s,i respinge sau marcheaza spam-urile senumes,te filtru anti-spam.

De ment,ionat filtrele anti-spam nu pot fi facute 100% sigure deoarecenu exista un criteriu clar de diferent,iere. Ca urmare, orice filtru anti-spam valasa sa treaca un anumit numar de spam-uri s,i exista s,i riscul de-a respingemesaje legitime.

Majoritatea furnizorilor de servicii Internet nu permit, prin contract,client,ilor sa trimita spam-uri s,i depun eforturi pentru depistarea s,i penalizarea

autorilor. In acest scop, ei primesc sesizari s,i ıntret,in liste cu adresele de lacare provin spam-urile (liste negre — blacklist).

Trimiterea spam-urilor necesita recoltarea, de catre autorul spam-urilor, a unui numar mare de adrese valide de pos,ta electronica. Acest lucruse realizeaza cel mai us,or prin cautarea, ın paginile web, a tot ceea ce arataa adresa de pos,ta electronica. Contramasura la aceasta recoltare este scriereaadreselor, din paginile web, doar ın forme dificil de procesat automat — deexemplu, ca imagine (ıntr-un fis,ier jpeg, gif sau png).

Termenul de virus poate desemna mai multe lucruri, ınrudite dar dis-tincte. In general, un virus informatic este un fragment de program a caruiexecut,ie duce la inserarea unor copii ale sale ın alte programe de pe calcula-torul pe care se executa virusul. Impropriu, prin virus se mai desemneaza unfragment, inserat ıntr-un program util, care executa act,iuni nocive utilizatoru-lui ın contul caruia se executa acel program. Denumirea corecta pentru unastfel de program este aceea de cal troian. Denumirea de virus poate fi data,corect, doar fragmentelor de program capabile sa se reproduca (sa-s,i insereze



copii ın alte programe).

In contextul pos,tei electronice, un virus este un fragment dintr-unprogram plasat ca fis,ier atas,at la un mesaj electronic. Virusul se poate repro-duce fie prin mijloace independente de pos,ta electronica, fie prin expedierea,

catre alt,i utilizatori, a unor copii ale mesajului. In acest al doilea caz, virusulutilizeaza, de obicei, adrese extrase din lista, t,inuta de MUA, a adreselorpartenerilor de corespondent,a ai utilizatorului care primes,te mesajul virusat.

Indiferent de forma de propagare (infectarea fis,ierelor locale sau trans-miterea de mesaje spre alt,i utilizatori), pentru a-s,i realiza scopul, un virustrebuie sa ajunga sa determine execut,ia, cu drepturile utilizatorului victima, aunei secvent,e de instruct,iuni aleasa de autorul virusului. Acest lucru se poateıntampla ın doua moduri:

• Virusul se gases,te ıntr-un program executabil, pe care utilizatorul ıl exe-cuta.

• Virusul este un document astfel construit ıncat, exploatand o eroare dinprogramul utilizat pentru vizualizarea documentului, sa determine pro-gramul de vizualizare sa execute act,iunea dorita de autorul virusului.

Pentru a pacali destinatarul s,i a-l determina sa execute sau sa vizual-izeze fis,ierul atas,t, corpul mesajului este construit astfel ıncat sa cas,tige ıncredereautilizatorului. Astfel, mesajul este adesea construit ca s,i cand ar proveni dela administratorul de sistem sau de la un prieten al destinatarului.

Metodele de prevenire a virus,ilor de pos,ta electronica sunt aceleas,ica s,i metodele de prevenire a virus,ilor ın general. Pentru programele exe-cutabile, daca utilizatorul are ıncredere ın autorul declarat al programului (deexemplu, autorul este o firma de soft de ıncredere), atunci programul poate fisemnat electronic, iar utilizatorul poate verifica aceasta semnatura pentru a seconvinge de autenticitatea programului. Pentru programe provenite din sursece nu sunt de ıncredere, execut,ia lor se poate face ıntr-un mediu controlat,de exemplu dintr-un cont separat, cu drepturi minime, sau prin intermediulunui interpretor care sa nu execute instruct,iunile potent,ial nocive. Aceastadin urma abordare este utilizata de applet-urile Java.

Pe langa aceste metode de prevenire, exista cateva act,iuni care mics,o-reaza riscul sau consecint,ele execut,iei unui virus. Una dintre ele este reducereala minimul necesar a lucrului din cont de administrator. Alta masura pre-ventiva este aceea de a nu vizualiza sau executa fis,ierele atas,ate unui mesajsuspect; pentru aceasta, este bine ca expeditorul unui mesaj sa nu trimitaniciodata un mesaj numai cu fis,iere atas,ate, ci sa scrie un mic text explicativ,care sa-i permita destinatarului sa identifice autorul s,i scopul fis,ierelor atas,ate.



11.2. Sesiuni interactive la distant,a

O sesiune interactiva locala a unui utilizator (vezi fig. 11.2) presupuneca tastatura, ecranul s,i eventual alte dispozitive cu ajutorul carora utilizatorulinteract,ioneaza cu sistemul de calcul (mouse, difuzoare, etc.) sunt conectatedirect la calculatorul pe care se desfas,oara sesiunea utilizatorului. Conectareaeste realizata printr-o interfat,a hardware de conectare a dispozitivelor per-iferice (RS232, PS/2, VGA, USB, DVI), care permite legaturi pe distant,e decel mult cateva zeci de metri. Un dispozitiv (tastatura, ecran, etc.) este conec-tat la un singur calculator, mutarea lui de la un calculator la altul putandu-seface fie prin mutarea fizica a conectorului, fie prin comutatoare speciale (KVMswitch).

bashlogin

driver

terminal

hard

S. O.

Terminal

fizic

Figura 11.2: Componentele implicate ıntr-o sesiune interactiva locala

In general ne gandim ca pe un astfel de sistem lucreaza un singur uti-lizator la un moment dat. Totus,i, exista s,i posibilitatea de-a conecta mai multeansambluri tastatura–ecran la un acelas,i calculator, ın felul acesta lucrand si-multan mai mult,i utilizatori. Acest mecanism s-a utilizat masiv ın anii 1970,sistemele fiind numite cu time-sharig. PC-urile au repetat, pana la un punct,istoria calculatoarelor mari: au ınceput ca sisteme monoutilizator, monotask-ing (sistemul DOS), au continuat cu un multitasking primitiv, bazat pe solut,iiad-hoc (deturnarea ıntreruperilor ın DOS, sistemul Windows pana la versiu-nile 3.x), sisteme multitasking fara protect,ie ıntre utilizatori (Windows 9x s,iME) s,i ın final sisteme multitasking propriu-zise (Windows NT/2000/XP s,isistemele de tip UNIX — Linux s,i porturile FreeBSD, Solaris, etc).

Linux (prin mecanismul consolelor virtuale) s,i Windows XP (prinmecanismul switch user) permit deschiderea simultana a mai multor sesiunilocale de la acelas,i ansamblu tastatura–ecran, pentru acelas,i utilizator saupentru utilizatori distinct,i. O singura sesiune poate fi activa la un momentdat, celelalte fiind ,,ınghet,ate“. Sistemul permite comutarea ıntre sesiuni.


376 11.2. Sesiuni interactive la distant,a

In cazul unei sesiuni la distant,a, ın locul unui terminal, conectatprintr-o interfat,a specializata la calculatorul pe care se desfas,oara sesiunea,se utilizeaza un calculator, conectat prin ret,ea la calculatorul pe care se

desfas,oara sesiunea. In felul acesta, un utilizator aflat ın fat,a unui calcu-lator conectat la Internet poate deschide o sesiune la distant,a catre orice altcalculator din Internet (bineınt,eles, cu condit,ia sa aiba un cont acolo). Prin-cipial, numarul de sesiuni deschise simultan catre un calculator este limitatdoar de resursele calculatorului (memorie s,i viteza de procesare).

Deschiderea unei sesiuni prin mecanismul de sesiune la distant,a sepoate face s,i catre calculatorul local. Acest mecanism poate fi utilizat pentrudeschiderea unei sesiuni ca alt utilizator, fara a ınchide prima sesiune.

login bash

driver

hard

S. O.

telnet

server

driver

terminal

hard

S. O.

telnet

client

Ret,ea

pseudoterminal

Calculator

server

Calculator

client

Terminal

fizic

Figura 11.3: Componentele implicate ıntr-o sesiune interactiva la distant,a.

Sistemul pentru deschiderea sesiunilor la distant,a (vezi fig. 11.3)consta din doua componente majore:

• Pe sistemul la care este conectat fizic utilizatorul ruleaza o aplicat,ie caretrimite prin ret,ea ceea ce utilizatorul introduce de la tastatura s,i afis,eazape ecran ceea ce trimite sistemul de la distant,a. Afis,area se poate face petot ecranul sau ıntr-o fereastra. Aceasta aplicat,ie deschide ın mod activconexiunea la deschiderea sesiunii, motiv pentru care este un client.

• Pe sistemul de la distant,a, pe care are loc sesiunea, ruleaza o aplicat,iecare primes,te prin ret,ea datele trimise de aplicat,ia client s,i le livreazaproceselor ce ruleaza ın cadrul sesiunii. De asemenea, preia datele deies,ire ale acestor procese — datele care ın cazul unei sesiuni locale s-arafis,a pe ecran — s,i le trimite prin ret,ea clientului. Aceasta aplicat,ie estelansata la pornirea sistemului s,i as,teapta conexiuni — fiind ın acest sensun server. La conectarea unui client, aplicat,ia server autentifica clientuldupa care (ın cazul unei autentificari cu succes) lanseaza procesele care



sunt lansate ın mod normal la deschiderea unei sesiuni. De exemplu,ın cazul unui sistem de tip UNIX, serverul lanseaza ın execut,ie un shellruland ın contul utilizatorului.

Pentru ca serverul sa comunice cu procesele din cadrul sesiunii,este necesar ca sistemul de operare sa ofere un mecanism adecvat decomunicat,ie ıntre procese. Mecanismul de comunicat,ie trebuie sa aparafat,a de procesele din sesiunea utilizatorului ca s,i cand ar fi tastatura

s,i ecranul adevarate. In cazul sistemelor de tip UNIX, acest mecanismeste mecanismul pseudoterminalelor . De notat ca mecanismul pipe nueste adecvat deoarece un pipe nu apare procesului ca un terminal s,inu permite, de exemplu, unui editor de texte, ce ar rula ın sesiuneautilizatorului, sa solicite primirea fiecarui caracter tastat ın parte. Denotat ca, ın mod normal, un proces primes,te cate o linie ın momentulın care utilizatorul apasa enter ; pana atunci nucleul sistemului permiteutilizatorului editarea liniei.

11.2.1. Protocolul sshProtocolul ssh a fost dezvoltat ca o alternativa, protejata criptografic,

la telnet. Protocolul ssh este ınsa extensibil, permit,and tunelarea protejatacriptografic a conexiunilor TCP pentru alte aplicat,ii.

Protocolul ssh este construit pe mai multe nivele. Nivelul cel maide jos [RFC 4253, 2006] realizeaza protejarea criptografica a conexiunii s,i sebazeaza pe serviciile de conexiune TCP oferite de sistemul de operare. Nivelulurmator realizeaza multiplexarea conexiunii protejate criptografic. Nivelul celmai de deasupra cuprinde aplicat,ia propriu-zisa s,i permite sesiuni de lucru,interactive sau nu, ın mod text, catre sisteme de tip UNIX, tunelarea unorconexiuni TCP arbitrare, transferul de fis,iere s,i transmiterea informat,iilor deautentificare criptografica pentru alte sesiuni ssh.

11.2.1.1. Conexiunea ssh protejata criptograficDescriem ın continuare modul ın care ssh realizeaza protejarea crip-

tografica a conexiunii. Protocolul este un exemplu instructiv de utilizare prac-tica a primitivelor criptografice.

In secvent,a de init,ializare a conexiunii — care va fi descrisa mai jos— clientul s,i serverul stabilesc un identificator de sesiune s,i, pentru fiecaresens, o cheie de criptare s,i o cheie de autentificare. De asemenea, se stabilescalgoritmii de criptare simetrica, compresie s,i dispersie cu cheie utilizat,i pentrufiecare sens al comunicat,iei. Comunicat,ia decurge complet independent ın celedoua sensuri.



Pentru fiecare sens, datele de transmis sunt grupate ın pachete, dedimensiune variabila. Pentru fiecare pachet de date utile, se construies,te s,i setransmite pe conexiune un pachet generat astfel:

1. Datele utile sunt comprimate utilizand algoritmul de compresie curentpentru sensul de comunicat,ie curent.

2. Se adauga, dupa datele comprimate, un s,ir de octet,i aleatori, iar ın fat,alor se adauga un octet reprezentand lungimea s,irului aleator. Apoi, ınfat,a s,irului astfel obt,inut, se adauga lungimea totala a s,irului, reprezen-tata pe patru octet,i. Numarul de octet,i aleatori adaugat,i trebuie astfelales ıncat sa rezulte ın urma concatenarii un s,ir de lungime multiplu delungimea blocului cifrului utilizat.

3. Rezultatul pasului precedent se cripteaza.

4. In fat,a blocului (necriptat) rezultat din pasul 2 se adauga numarulde ordine al pachetului curent, dupa care din rezultatul concatenariise calculeaza dispersia cu cheia de autentificare curenta. Numarul deordine ıncepe de la 0 s,i cres,te cu 1 la fiecare pachet independent deeventuala schimbare a cheilor sau algoritmilor criptografici utilizat,i.

5. Pachetul transmis efectiv este rezultatul concatenarii pachetului criptat(rezultat din pasul 3) cu dispersia cu cheie (rezultata din pasul 4).

Rolul acestor transformari este urmatorul. Pe de o parte, compresiacres,te entropia datelor de criptat, facand mai dificila spargerea cifrului. Octet,iiadaugat,i la finalul blocului fac ca ın cazul repetarii aceluias,i bloc de dateutile sa rezulte blocuri criptate diferite. Lungimea completarii aleatoare estes,i ea criptata, facand dificila determinarea lungimii datelor utile din bloculcriptat. Pe de alta parte, dispersia criptografica cu cheie se calculeaza dintr-un bloc cont,inand datele utile s,i numarul de ordine al blocului, fapt ce permitereceptorului sa verifice ca datele sunt autentice s,i ca sunt proaspete — numarulde ordine al blocului primit este cel as,teptat. Numarul de ordine al bloculuifiind cunoscut receptorului, nu este nevoie sa fie trimis efectiv.

In cazul vreunei nepotriviri privitoare la dispersia criptografica cucheie a unui bloc, conexiunea este abandonata. Remarcam faptul ca o astfelde nepotrivire poate fi cauzata doar de o tentativa de modificare a datelorde catre un adversar activ, nivelul TCP s,i nivelele inferioare corectand erorilede transmisie la nivel fizic s,i eventualele pierderi de pachete IP datorate uneicongestii ın ret,ea.

La deschiderea conexiunii ssh, compresia, criptarea s,i dispersia cucheie sunt dezactivate. Negocierea primului set de chei s,i a algoritmilor decompresie, criptare s,i dispersie cu cheie se face ın clar. O data alese cheile



s,i algoritmii, acestea sunt activate s,i se poate ıncepe comunicat,ia ın folosulaplicat,iilor. Algoritmii s,i cheile pot fi renegociate ulterior oridecateori unadintre part,i (clientul sau serverul) o solicita.

Negocierea cheilor s,i algoritmilor se face dupa cum urmeaza. Fiecareparte trimite liste, ın ordinea descrescatoare a preferint,ei, cu algoritmii decriptare, compresie, dispersie cu cheie, semnatura digitala s,i schimb de chei su-portate. Algoritmul utilizat, pentru fiecare categorie, este primul algoritm depe lista clientului care se regases,te s,i ın lista serverului (adica cel mai favorabilclientului, dintre cei acceptat,i de server). Urmeaza schimbul de mesaje con-form protocolului Diffie-Hellman (ssh nu are definite deocamdata alte metodede schimb de chei). Din informat,ia secreta construita prin schimbul Diffie-Hellman se construiesc (pe baza unor funct,ii de dispersie fara cheie) cheilesecrete pentru criptare s,i pentru autentificare pentru fiecare sens.

Mai ramane de autentificat schimbul Diffie-Hellman, despre care amvazut ca, singur, este vulnerabil la atacul unui adversar activ. Autentifi-carea cheii fat,a de client (adica autentificarea, fat,a de client, a serverului cucare comunica acesta) se face dupa cum urmeaza. Serverul are o pereche dechei pentru semnatura electronica. Clientul trebuie sa aiba cheia publica aserverului. Dupa realizarea schimbului Diffie-Hellman, serverul trimite clien-tului o semnatura, calculata cu cheia sa secreta, asupra ıntregului schimb deinformat,ie de pana atunci — adica listele de algoritmi suportat,i s,i pachetelecorespunzatoare protocolul Diffie-Hellman, emise de ambele part,i. Prin ver-ificarea semnaturii, clientul se asigura ca negocierea a avut loc ıntr-adevarcu serverul autentic. Autentificarea clientului fat,a de server se face ulterior,existand ın acest scop mai multe mecanisme posibile (vezi § 11.2.1.2).

Pentru facilitarea raspandirii utilizarii protocolului ssh, serverul trans-mite la deschiderea conexiunii cheia sa publica catre client. Notam ca, deoarecetransmisia cheii publice a serverului nu poate fi ınca autentificata, utilizarea decatre client a cheii publice transmise de server prezinta riscul ca un adversaractiv sa se dea drept serverul autentic. Daca ınsa adversarul n-a modificatcheia publica transmisa de server, restul comunicat,iei este sigur. Mai mult,la prima conectare, clientul stocheaza local cheia primita de la server. Laurmatoarele conectari, clientul compara cheia primita de la server cu cea sto-cata locat; daca sunt diferite, avertizeaza utilizatorul. In acest fel, daca laprima conectare cheia primita de client de la server este cea autentica, oriceatac ulterior din partea unui adversar activ este descoperita.

La prima conectare a programului client ssh la un server nou, clientulavertizeaza utilizatorul cu privire la faptul ca nu poate verifica cheia serverului.La aceasta prima conectare, ımpiedicarea unui atac al unui eventual adversar



se poate face ın doua moduri:

• Inainte de prima conectare, utilizatorul copiaza, de pe mas,ina serversau dintr-o sursa autentificata, cheia publica a serverului s,i o introduce

manual ın lista de chei memorate local de programul client ssh. In acestfel, clientul ssh poate verifica cheia serverului chiar de la prima sesiune,ıntocmai ca ın cazul unei sesiuni ulterioare.

• Utilizatorul obt,ine, dintr-o sursa autentificata (de exemplu, vorbind latelefon cu administratorul mas,inii server), dispersia criptografica a cheiipublice a serverului. La prima conectare, utilizatorul compara dispersiaastfel obt,inuta cu dispersia cheii trimise de server (aceasta este afis,atade clientul ssh ımpreuna cu mesajul de avertisment prin care anunt,aimposibilitatea verificarii cheii). Daca cele doua dispersii coincid, cheiatrimisa de server este autentica.

Pe sistemele de tip UNIX, cheile publice ale serverului (pentru diferiteleprotocoale de semnatura) se gasesc ın directorul /etc/ssh, ın fis,ierele ssh_host_rsa_key.pub,respectiv ssh_host_dsa_key.pub. Aceste fis,iere pot fi citite de orice utilizatoral sistemului. Amprenta cheii dintr-un astfel de fis,ier se determina cu comandassh-keygen -l -f fis,ier. Cleintul ssh memoreaza cheile serverelor ın fis,ierul~/.ssh/known_hosts.

11.2.1.2. Metode de autentificare ın ssh

In ssh, exista autentificare reciproca ıntre client s,i server.

As,a cum am vazut, serverul se autentifica fat,a de client cu ajutorulunui mecanism cu cheie privata s,i cheie publica.

Dupa init,ializarea mecanismului de protect,ie criptografica a conexiu-nii, este randul clientului sa-s,i declare identitatea (numele de utilizator) s,i sase autentifice.

Clientul poate fi autentificat de server prin mai multe metode. Celemai comune sunt autentificarea prin parola s,i autentificarea prin semnaturadigitala (numita s,i autentificare cu cheie publica).

Autentificarea prin parola presupune trimiterea de catre client a parolei.Este esent,ial faptul ca serverul este deja autentificat s,i confident,ialitatea, in-tegritatea s,i prospet,imea comunicat,iei sunt protejate. Ca urmare clientulnu risca sa trimita parola unui adversar s,i nici ca un adversar ce capteazacomunicat,ia criptata sa retrimita datele interceptate pentru a repeta o sesiunelegitima.

Autentificarea prin semnatura digitala presupune ca ın faza de init,i-alizare utilizatorul sa configureze pe server o cheie publica, corespunzatoare



cheii sale secrete. La conectare, clientul se autentifica trimit,and semnatura, cucheia sa secreta, asupra identificatorului de sesiune creat ın faza de stabilirea comunicat,iei protejate criptografic. Serverul verifica semnatura utilizandcheia publica ce a fost configurata.

Configurarea autentificarii cu cheie publica, pe sistemele de tip UNIXavand server OpenSSH, este descrisa ın continuare.

Perechile de chei se genereaza cu ajutorul utilitarului ssh-keygen.

Cheia publica admisibila pentru conectarea ın contul unui utilizatorse scrie ın fis,ierul ~/.ssh/authorized_keys (sub directorul personal al uti-lizatorului). Deoarece acest fis,ier poate fi modificat doar de catre posesorulcontului, doar posesorul contului poate stabili cheia admisibila pentru aut-entificare. Fis,ierul ~/.ssh/autthorized_keys poate cont,ine mai multe chei.

In acest caz, oricare dintre cheile secrete corespunzatoare este valida pentruautentificare. Este posibil ca, pentru anumite chei, sa se configureze lansareaunei anumite aplicat,ii; ın acest caz, daca clientul utilizeaza cheia pereche pen-tru autentificare, i se va lansa automat aplicat,ia respectiva s,i nu o sesiunenerestrict,ionata.

Pentru schimbarea cheii, de exemplu ın cazul compromiterii cheii se-crete, utilizatorul trebuie sa genereze o noua pereche de chei, sa scrie nouacheie publica ın fis,ierul ~/.ssh/authorized_keys, sa s,tearga vechea cheiepublica din acest fis,ier s,i sa furnizeze noua cheie secreta clientului ssh laconectarile ulterioare. Deoarece cheia publica nu este o informat,ie secreta,compromiterea sistemului server nu duce la compromiterea, s,i deci la nece-sitatea schimbarii, cheii. Acesta este un avantaj fat,a de cazul autentificariiprin parole, unde compromiterea serverului duce la compromiterea parolei s,ila necesitatea schimbarii parolei nu numai pe acel sistem ci s,i pe alte sistemepe care utilizatorul avea aceeas,i parola.

Pentru furnizarea cheii secrete catre clientul ssh, exista doua posi-bilitat,i. Prima posibilitate este ca fis,ierul cu cheia secreta sa fie facut disponi-bil clientului ssh. Daca fis,ierul cont,ine cheia secreta ca atare, conectarea seface fara ca utilizatorul sa mai dea vreo parola. Daca utilizatorul dores,te sase conecteze de pe mas,ini (client) diferite, trebuie fie sa poarte cheia cu el peun suport amovibil, fie sa puna copii ale cheii secrete pe fiecare sistem, fie sautilizeze chei diferite pentru conectarea de pe fiecare sistem. Ultima solut,ieofera avantajul ca, ın cazul compromiterii unuia dintre sistemele client, estenecesara schimbarea cheii secrete doar de pe acel sistem.

Deoarece compromiterea unui sistem client duce, ın cazul stocarii caatare a cheii secrete, la compromiterea imediata a contului utilizatorului, cheilesecrete se stocheaza, ın mod obis,nuit, ın forma criptata ın fis,iere. Criptarea



se realizeaza printr-un algoritm simetric cu ajutorul unei chei derivate dintr-oparola aleasa de utilizator. Stocarea cheii numai ın forma criptata ofera unplus de sigurant,a (un intrus trebuie sa obt,ina atat fis,ierul cu cheia secreta, cats,i parola de decriptare a acestuia), ınsa duce la necesitatea de a da clientuluissh parola de decriptare la fiecare utilizare.

A doua posibilitate de a furniza aplicat,iei client accesul la cheia se-creta este prin intermediul unui program numit agent de autentificare. Agen-tul de autentificare este un proces server care are ın memorie cheia secreta autilizatorului, ın forma decriptata. Clientul ssh se conecteaza la agentul deautentificare pentru a obt,ine accesul la cheie.

Agentul de autentificare, avand ca nume de executabil ssh-agent, selanseaza de regula la deschiderea sesiunii pe mas,ina client. Cheile secrete seıncarca ın agentul de autentificare cu ajutorul unui program numit ssh-add.Acest program permite s,i listarea s,i s,tergerea cheilor secrete. Daca cheia se-creta este stocata criptat, ssh-add solicita utilizatorului parola de decriptare.Cheia secreta decriptata se gases,te doar ın memoria agentului de autentificare,nu se stocheaza pe disc.

La lansare, clientul ssh cauta sa vada daca pe mas,ina locala ruleazaun agent de autentificare. Daca da, contacteaza agentul de autentificare s,i-i so-licita accesul la cheile secrete stocate de acesta. Clientul ssh paseaza agentuluiidentificatorul de sesiune s,i primes,te ınapoi semnatura cu cheia secreta asupra

acestuia. In acest fel, clientul ssh nu ajunge sa cunoasca efectiv cheia secreta.Deschiderea sesiunii catre mas,ina server se face fara a solicita utilizatoruluivreo parola.

Comunicat,ia dintre clientul ssh sau utilitarul ssh-add s,i agentul deautentificare se face printr-un socket de tip UNIX, al carui nume este pus ınvariabila de mediu SSH_AUTH_SOCK. Comunicat,ia fiind locala, ea nu poate fiinterceptata sau modificata. Autentificarea clientului (ssh sau ssh-add) se faceprin aceea ca drepturile de acces la socket-ul corespunzator sunt acordate doarproprietarului agentului de autentificare.

Protocolul ssh permite construct,ia unei conexiuni securizate dinspre

mas,ina server ssh spre agentul de autentificare de pe mas,ina client ssh. Inacest caz, la deschiderea sesiunii, serverul ssh act,ioneaza s,i ca un agent deautentificare. Cererile de semnatura primite de serverul ssh sunt trimise princonexiunea ssh catre client, iar clientul le trimite agentului local (de pe mas,inaclient). Prelungirea nu se poate face ın lipsa unui agent de autentificare pemas,ina client.

Analizand securitatea prelungirii conexiunii la agentul de autentifi-care, observam ca serverul nu obt,ine efectiv cheia secreta, ınsa, pe durata



conexiunii, poate deschide sesiuni ın numele clientului catre orice mas,ina careaccepta cheile stocate ın agentul de autentificare. Din acest motiv, clientulssh nu face prelungirea conexiunii la agentul de autentificare decat la cerereaexplicita a utilizatorului.

11.2.1.3. Multiplexarea conexiunii, tunelarea s,i aplicat,ii

O data deschisa conexiunea s,i realizata autentificarea clientului, clien-tul ssh poate solicita serverului deschiderea unei sesiuni de lucru, adica ınesent,a lansarea unui shell ın contul utilizatorului autentificat. Tot la solic-itarea clientului, canalul de comunicat,ie creat de server ıntre server s,i shell -ullansat poate fi realizat printr-un pseudoterminal (cazul obis,nuit al unei sesiuniinteractive) sau printr-o pereche de pipe-uri. A doua varianta se utilizeaza ıncazul ın care utilizatorul a lansat clientul ssh cu specificarea unei comenzi deexecutat pe server. In acest caz, comanda specificata de utilizator este trans-misa serverului s,i acesta o executa cu intrarea s,i ies,irea redirect,ionate catreserver s,i prelungite prin conexiunea securizata catre client. Redirect,ionand peclient intrarea sau ies,irea standard a comenzii ssh, se realizeaza, per ansam-blu, redirect,ionarea intrarii sau ies,irii standard catre fis,iere sau pipe-uri de pemas,ina locala pentru comanda executata la distant,a.

Exemplul 11.5: Comanda

ssh [email protected] ls -l > lista

are ca efect final crearea, pe mas,ina locala, a unui fis,ier lista, cont,inandlista numelor de fis,iere de pe mas,ina nessie.cs.ubbcluj.ro din directorulpersonal al utilizatorului rlupsa.

11.2.2. Sistemul X-WindowSistemul X-Window, dezvoltat de Massachuttes Institute of Technol-

ogy pe la mijlocul anilor 1980, este un sistem ce permite stabilirea de sesiunila distant,a ın mod grafic.

Descriem ın continuare arhitectura X Window. Ment,ionam ca estediferita fat,a de sistemele studiate pana aici. Diferent,a provine ın primul randdin faptul ca sistemul X Window are s,i scopul de-a asigura proceselor acces laecranul grafic local.

O prima componenta a sistemului este serverul X. Acesta este unproces, avand de regula acces privilegiat la sistem, care gestioneaza tastaturas,i ecranul local. O aplicat,ie ce are nevoie de acces la un ecran grafic s,i la



tastatura atas,ata se numes,te client X. Un client X se conecteaza la serverul Xs,i, dupa autetificare, poate:

• sa ceara serverului sa deseneze diverse lucruri pe ecran;

• sa solicite sa primeasca informari cu privire la tastele apasate de utilizators,i la mis,carile mouse-ului.

La un server se pot conecta simultan mai mult,i client,i, inclusiv de pe calcula-toare diferite.

Serverul t,ine evident,a unor ferestre, fiecare operat,ie de desenare a-vand specificata o fereastra ın care sa deseneze. Ecranul cu totul este consid-erat o fereastra, iar ın fiecare fereastra se pot deschide subferestre. Serverult,ine evident,a modului ın care se suprapun ferestrele s,i determina ce parte dindesenul efectuat ıntr-o fereastra este vizibil s,i trebuie desenat pe ecran.

Un client autentificat are acces deplin la tastatura s,i ecranul gestion-ate de server. Asta ınseamna, de exemplu, ca un client poate sa desenezeıntr-o fereastra deschisa de alt client s,i poate sa capteze tot ceea ce tasteazautilizatorul ın acea fereastra. De principiu, sunt admise la un moment dat sase conecteze doar aplicat,ii ruland ın contul aceluias,i utilizator.

Pentru ca aplicat,ii distincte sa nu se ıncurce reciproc, exista nis,te

convent,ii pe care aplicat,iile se recomanda sa le respecte. In linii mari, acesteaprevad ca o aplicat,ie sa nu deseneze ın ferestrele deschise de alta aplicat,ie s,isa nu capteze tastele cand nu este activa.

Comutarea ıntre aplicat,ii, precum s,i mutarea s,i redimensionarea fer-estrelor principale ale aplicat,iilor, cad ın sarcina unui client mai special numitwindow manager . Window manager -ul se conecteaza s,i se autentifica ca unclient obis,nuit, dupa care solicita serverului sa fie informat de cererile de de-schidere de ferestre trimise de ceilalt,i client,i. La fiecare fereastra principala de-schisa, window manager -ul adauga bara de titlu s,i marginile. Deoarece oricumnu exista protect,ie ıntre client,ii conectat,i la un server X, un client nu are nevoiede privilegii speciale ca sa act,ioneze ca window manager. Totus,i, cateva din-tre operat,iile de care are nevoie un window manager ca sa funct,ioneze suntacordate de serverul X doar unui client la un moment dat. Ca urmare, nu potexista doua window manager -e simultan.

11.3. Transferul fis,ierelor ın ret,ea

Cerint,a de-a transfera fis,iere ın ret,ea poate avea diferite particu-laritat,i. Exista mai multe protocoale s,i mai multe aplicat,ii pentru transferulfis,ierelor ın ret,ea, adaptate pentru diferite necesitat,i.



O prima categorie de protocoale s,i aplicat,ii prives,te, ın principal,transferul fis,ierelor unui utilizator de pe o mas,ina pe alta, ın condit,iile ın careutilizatorul are cont pe ambele mas,ini. Protocoalele construite pentru aceastasunt ftp s,i ssh. De notat ca s,i pos,ta electronica poate servi ca mecanism detransfer de fis,iere.

O a doua categorie prives,te transferul fis,ierelor publice de la un cal-culator ce stocheaza astfel de fis,iere la calculatorul unui utilizator ce dores,tesa citeasca fis,ierele respective. Init,ial se utiliza protocolul ftp ın acest scop.Protocolul utilizat ın mod curent este ınsa http.

O a treia categorie pives,te accesul proceselor de pe un calculator lafis,iere stocate pe alt calculator ca s,i cand fis,ierele ar fi locale. De principiufis,ierele respective sunt private, ca s,i pentru prima categorie de protocoale.Protocoalele din aceasta categorie trebuie sa satisfaca doua cerint,e specifice(fat,a de prima categorie): sa permita transferul doar a unei part,i mici dintr-un fis,ier s,i sa permita controlul partajarii fis,ierului ıntre procese. Protocoaleleutilizate aici sunt SMB (utilizat ın ret,elele Windows) s,i NFS.

11.3.1. Protocolul ftpDescriem pe scurt conceptele de baza ale protocolului ftp. Pentru

detalii, a se vedea [RFC 765, 1985].

Clientul deschide o conexiune TCP catre portul 21 al serverului;aceasta conexiune se numes,te conexiune de control. Prin conexiunea de con-trol, clientul transmite comenzi ın format text, cate o comanda pe o linie.Fiecare comanda ıncepe cu numele comenzii urmat de eventuali parametrii.Parametrii sunt separat,i prin spat,ii, atat fat,a de numele comenzii cat s,i ıntreei. Serverul raspunde tot ın format text, fiecare raspuns ıncepand cu un codcare arata daca comanda s-a executat cu succes sau ce erori s-au produs, dupacare urmeaza un text ce descrie, ın limbaj natural, rezultatul execut,iei comen-zii. Cu o singura except,ie (ın cazul comenzii PASV, descrisa mai jos), textuldin raspuns nu este interpretat de catre aplicat,ia client. El este ınsa afis,at, deobicei, pe ecran utilizatorului aplicat,iei client.

Autentificarea se face la solicitarea clientului. Clientul trimite suc-cesiv doua comenzi, USER s,i PASS, avand ca parametrii respectiv numele uti-lizatorului s,i parola acestuia. Serverul refuza execut,ia majoritat,ii comenzilorclientului ınainte de autentificarea cu succes a acestuia. Dupa autentificare,serverul accepta sa efectueze operat,iile cerute de client doar daca utilizatorulın contul caruia s-a facut autentificarea are dreptul la operat,iile respective.Pe sistemele de tip UNIX, reglementarea drepturilor de acces se face de obiceiastfel: la lansare, serverul ruleaza din contul root; la conectarea unui client,


386 11.3. Transferul fis,ierelor ın ret,ea

serverul creaza (prin apelul sistem fork()) un proces fiu care se ocupa deacel client; dupa autentificare, procesul fiu trece ın contul utilizatorului aut-entificat (prin apelul setuid()); ın continuare, serverul accepta orice comenzide la client s,i ıncearca sa le execute, iar verificarea drepturilor de acces estefacuta de nucleul sistemului de operare ın momentul ın care procesul serverfiu ıncearca sa acceseze sistemul de fis,iere.

Pentru transferul de fis,iere publice, serverul este configurat sa accepteautentificare cu numele de utilizator ftp sau anonymous fara sa solicite parolasau acceptand orice s,ir de caractere pe post de parola. In vremurile de ınceputale Internet-ului, se obis,nuia ca un utilizator ce dorea acces la fis,iere publice sa-s,i dea, pe post de parola, adresa sa de pos,ta electronica. O data cu raspandireaspam-urilor, s-a renunt,at la acest obicei.

Transferul fis,ierelor se cere prin comenzile SEND (dinspre client spreserver) s,i RETR (dinspre server spre client). Comenzile au ca argument numelede pe server al fis,ierului de transferat. Transferul propriu-zis are loc printr-oconexiune separata, numita conexiune de date. Pentru fiecare fis,ier se deschideo noua conexiune de date, care se ınchide la finalul transferului fis,ierului.Dimensiunea fis,ierului nu este specificata explicit nicaieri, receptorul fis,ieruluiobt,inand lungimea din faptul ca emit,atorul ınchide conexiunea de date lafinalul fis,ierului.

Exista doua moduri de deschidere a conexiunii de date:

• Modul activ prevede ca serverul deschide conexiunea de date ca o cone-xiune TCP dinspre portul 20 al serverului catre un port specificat declient. Clientul specifica portul pe care as,teapta conexiunea prin co-manda PORT. Conexiunea se deschide ca urmare a comenzii de transfer(SEND sau RETR), nu imediat dupa primirea comenzii PORT.

• Modul pasiv prevede deschiderea conexiunii de date de catre client, din-spre un port oarecare al sau, catre un port specificat de server. Portulspecificat de server se obt,ine ca raspuns al comenzii PASV date de client.Acesta este singurul caz ın care clientul interpreteaza din raspunsulserverului s,i altceva decat codul returnat.

Listarea fis,ierelor de pe server este solicitata de client prin comandaLIST. Trasnferul listei de fis,iere se face tot printr-o conexiune de date, ca s,i ıncazul comenzii RETR.

11.3.2. Protocolul HTTPHyperText Transmission Protocol(HTTP) este un protocol elaborat

pentru transferul dinspre server spre client a fis,ierelor cu informat,ii disponibile



public. El ınlocuies,te protocolul ftp utilizat cu conectare ca utilizator anony-mous. Des,i numele protocolului face referire la hipertext, el poate fi utilizatpentru a transfera orice fel de cont,inut.

Protocolul de baza consta ın trimiterea de catre client a unei cereri,ın care informat,ia principala este numele fis,ierului cerut. Raspunsul serveruluicont,ine nis,te informat,ii despre fis,ier s,i cont,inutul efectiv al fis,ierului. Implicit,conexiunea se ınchide dupa transferul unui fis,ier. Daca clientul dores,te maimulte fis,iere de pe acelas,i server, va trebui sa deschida cate o conexiune pentrufiecare fis,ier.

Protocolul a fost ınsa extins, ajungand sa fie folosit ca protocol detransfer de date pentru aplicat,ii de orice tip.

11.3.2.1. Structura cererilor s,i a raspunsurilor

Formatul comunicat,iei este mixt, atat la cereri cat s,i la raspunsuri.Partea de ınceput este text, iar cont,inutul fis,ierului este binar.

Cererea cuprinde, pe prima linie, un cuvant reprezentand numeleoperat,iei ceruta. Pentru solicitarea unui fis,ier public de pe server, numele esteGET. Dupa numele operat,iei urmeaza numele fis,ierului s,i apoi identificareaversiunii de protocol ın conformitate cu care este formata cererea. Cele treielemente sunt separate prin cate un spat,iu.

Urmatoarele linii sunt de forma nume:valoare, similar cu antetul unuimesaj de pos,ta electronica. Dupa ultima linie de antet urmeaza o linie vida.

Pentru unele tipuri de cereri, dupa linia goala se gases,te un cont,inut. In acestcaz, una dintre liniile din antet are numele Content-length s,i are ca valoarelungimea cont,inutului, data ca s,ir de cifre zecimale.

Raspunsul este structurat similar cu cererea. Pe prima linie se aflaidentificatorul versiunii HTTP, numar de trei cifre s,i un text. Numarul aratadaca cererea a fost satisfacuta cu succes sau nu, iar textul, neinterpretatde client, este o descriere ın cuvinte a semnificat,iei codului de trei cifre.Urmatoarele linii sunt de forma nume:valoare s,i dau informat,ii despre fis,ierulsolicitat. Dupa ultima linie de antet urmeaza o linie vida s,i apoi cont,inutul

(binar) al fis,ierului. In antet se gases,te o linie cu numele Content-length

avand ca valoare lungimea fis,ierului. Determinarea sfars,itului cont,inutuluipropriu-zis de catre client trebuie facuta prin numarea octet,ilor din partea decont,inut.

Adesea, mai multe servere HTTP sunt gazduite fizic pe acelas,i cal-

culator. In acest caz, fie numele serverelor corespund, prin DNS, unor adreseIP diferite, dar apart,inand aceluias,i calculator, caz ın care serverul este con-figurat sa raspunda ın funct,ie de IP-ul catre care a fost deschisa conexiunea,



fie numele serverelor corespund aceleias,i adrese IP, caz ın care este necesar caın cererea HTTP sa fie specificat serverul dorit. Acest lucru se realizeaza prinaceea ca, ın cererea clientului, se plaseaza un antet cu numele Host s,i avandca valoare numele de server dorit.

11.3.2.2. URL-urile

O pagina web este ın general un fis,ier scris ın HyperText MarkupLanguage (HTTP) s,i oferit ın acces public prin protocolul HTTP.

O pagina web consta, de obicei, din mai multe fis,iere. Exista un fis,ierde baza, scris ın limbajul HTML, s,i alte fis,iere, cont,inand anumite elemente alepaginii: imagini (ın fis,iere separate ın formate specifice — JPEG, PNG, GIF),applet-uri (Java), specificari de formatare a paginii (fis,iere Cascading StyleSheet — CSS). De asemenea, o pagina cont,ine ın general legaturi (link -uri)spre alte pagini. Toate acestea necesita referiri dintr-un fis,ier HTML catre altefis,iere disponibile ın acces public. Referirea acestor fis,iere se face prin numecare sa permita regasirea lor us,oara.

Un Universal Resource Locator (URL) este un nume prin care sepoate identifica s,i cu ajutorul carora se potate regasi o resursa disponibile ınInternet. URL-urile au aparut ca un format standard de scriere a numelorfis,ierelor referite din paginile web; ele permit ınsa utilizari mult mai vaste.

Un URL este alcatuit ın general din trei componente:

• Tipul identifica protocolul utilizat. Exemple mai cunoscute sunt: http,ftp, https, mailto.

• Numele mas,inii este numele de domeniu sau adresa IP a mas,inii pe carese gases,te resursa (fis,ierul).

Pe langa numele mas,inii, ın cadrul acestei componente se poateadauga numele de utilizator ın contul caruia trebuie sa se autentifice unclient pentru a obt,ine accesul dorit la resursa. Numele de utilizator seda ın fat,a numelui sau adresei mas,inii, separat de acesta prin caracterul@. Standardul original prevedea s,i posibilitatea de-a scrie ın URL parolanecesara conectarii. Aceasta utilizare este nerecomandata.

• Calea identifica resursa (fis,ierul) ın cadrul serverului care o gazduies,te. Inprincipiu, ea este calea completa a fis,ierului cerut, relativa la un directorde baza, fixat, al documentelor publice.

URL-urile se pot utiliza s,i se utilizeaza efectiv ın multe alte scopuridecat identificarea paginilor web. De exemplu, sistemul SubVersion (SVN)utilizeaza URL-uri de forma svn://mas,ina/cale pentru a referi fis,ierele dintr-un repository.



11.3.2.3. Alte facilitat,i HTTP

Antetul raspunsului HTTP ofera mai multe informat,ii despre fis,ierulreturnat:

• Tipul cont,inutului fis,ierului este specificat de catre server prin intermediulunui antet cu numale Content-type s,i cu valoarea construita ca s,i ıncazul antetului Mime-type de la pos,ta electronica. Tot ca s,i ın cazul luiMime-type, tipul cont,inutului poate fi urmat de specificarea codificariiutilizate pentru text; de exemplu,

Content-type: text/html; charset=utf-8

ınseamna ca fis,ierul este de tip HTML, iar codificarea utilizata pentrucaractere este UTF-8.

• Data ultimei modificari a fis,ierului este specificata prin valoarea antetuluicu numele Date.

• Tipul de compresie utilizat (daca fis,ierul returnat este comprimat) estedat ca valoare a antetului Content-transfer-encoding.

• Limba ın care este scris textul din fis,ier (daca este cazul) este returnataca valoare a antetului Language:.

Este posibil ca unui URL sa-i corespunda mai multe fis,iere pe server,avand cont,inut echivalent, dar ın diverse formate, limbi sau codificari. Pentrua select,iona varianta dorita, clientul poate anunt,a posibilitat,ile s,i preferint,elesale cu privire la tipul de fis,ier, limba s,i codificare. Antetele corespunzatoare,din cererea clientului, sunt: Accept, Accept-language s,i Accept-encoding.Fiecare dintre acestea are ca valoare o lista de variante, ın ordinea preferint,ei.De exemplu,

Accept-language: ro,en,fr

solicita serverului, de preferint,a, varianta ın limba romana a textului. Daca ovarianta ın limba romana nu este disponibila, se solicita una ın limba engleza,iar ın lipsa acesteia una ın limba franceza.

Protocolul HTTP permite formularea de cereri condit,ionate sau par-t,iale. O cerere part,iala este utila daca fis,ierul cerut este mare s,i clientul dores,tesa-l aduca din bucat,i sau daca la o cerere precedenta a cazut legatura dupatransferul unei part,i din fis,ier. O cerere condit,ionata determina serverul satransmita clientului fis,ierul numai daca este ındeplinita o anumita condit,ie, celmai adesea daca a fost modificat mai recent decat o anumita data specificata



de client. Daca nu este ındeplinita condit,ia, serverul da un raspuns formatdoar din antet, fara cont,inutul propriu-zis. Aceasta facilitate este utila dacaclientul det,ine o copie a unui fis,ier s,i dores,te ımprospatarea acesteia. Cerereapart,iala se specifica de catre client prin intermediul antetului Range; cerereacondit,ionata se specifica prin antetul If-modified-since.

Pentru optimizarea traficului, ın cazul ın care un client dores,te maimulte fis,iere de pe acelas,i server (aceasta se ıntampla adesea ın cazul ın careclientul aduce un fis,ier html, iar apoi are de adus imaginile s,i eventual alteobiecte din document), este prevazuta posibilitatea de-a pastra conexiuneadeschisa pe durata mai multor cereri. In acest scop, clientul cere pastrareaconexiunii deschise, plasand ın cerere antetul

Connection: keep-alive

Pentru a nu permite unor client,i sa deschida o conexiune s,i apoi sa o lasedeschisa la nesfars,it, t,inand ocupate resurse pe server, serverul trebuie config-urat sa ınchida automat conexiunea daca nu se transfera date o perioada detimp.

Este uneori util ca un utilizator care acceseaza un URL sa fie redirec-t,ionat automat catre alt URL. Aceasta se ıntampla daca administratorul sait-ului decide o reorganizare a paginilor s,i dores,te ca utilizatorii care au ret,inutURL-uri desfiint,ate ın urma reorganizarii sa fie redirect,ionat,i catre paginilecorespunzatoare din noua organizare. Aceasta redirectionare se face prin trim-iterea de catre server a unui antet cu numele Location s,i avand drept cont,inut

URL-ul spre care se dores,te redirect,ionarea clientului. In acest caz, programulclient nu afis,eaza cont,inutul returnat de server (cont,inut care ın mod normallipses,te complet), ci cere s,i afis,eaza cont,inutul de la URL-ul indicat ın antetulLocation.

11.3.2.4. Proxy HTTP

Un proxy HTTP este un proces care, fat,a de un client HTTP, act,io-neaza aproape ca un server HTTP, iar pentru satisfacerea cererii contacteazaserverul solicitat de client s,i act,ioneaza, fat,a de acest server, ca un client.

Un proxy HTTP este utilizat ın mod normal pentru urmatoarelefunct,ii:

• daca dintr-o ret,ea locala exista s,anse mari ca mai mult,i utilizatori sa

acceseze aceleas,i pagini web: In acest caz, client,ii HTTP ai calcula-toarelor din ret,ea se configureaza sa utilizeze un acelas,i proxy HTTPdin ret,eaua locala. Daca exista mai multe cereri pentru aceeas,i pagina,



la prima cerere proxy-ul memoreaza pagina adusa, iar la urmatoarelecereri o serves,te client,ilor din memoria locala.

• daca ıntr-o ret,ea se utilizeaza adrese IP locale (vezi § 10.2.4.1 s,i § 10.7.2) s,inu se dores,te configurarea unui mecanism de translat,ie de adrese (NAT,

§ 10.7.3): In acest caz, se instaleaza un proxy HTTP pe un calculatordin ret,eaua locala dar avand s,i adresa IP publica. Clientul acceseazaproxy-ul prin ret,eaua locala, iar proxy-ul, avand adresa publica, poateaccesa fara restrict,ii serverul dorit.

• daca este de dorit un control fin asupra paginilor ce pot fi accesate dintr-o ret,ea locala (de exemplu, pentru a restrict,iona accesul angajat,ilor la

saituri nelegate de activitatea lor normala). In acest caz, se config-ureaza un proxy ın care se configureaza toate restrict,iile de acces dorite.Apoi, pentru a ımpiedica accesul direct, prin evitarea proxy-ului, peruterul ce leaga ret,eaua interna la Internet se configureaza un filtru depachete (§ 10.7.1) care sa blocheze pachetele adresate portului TCP 80al serverelor exterioare.

O diferent,a ıntre protocolul de comunicat,ie dintre un client s,i unproxy fat,a de protocolul client-server este ca, dupa o cerere (de exemplu, GET),la protocolul client-server urmeaza calea locala din URL, iar la protocolulclient-proxy urmeaza URL-ul solicitat (inclusiv numele protocolului s,i numeleserverului).

O a doua diferent,a este data de existent,a unei cereri, CONNECT, cepoate fi adresata doar unui proxy. La primirea unei cereri CONNECT, proxy-ul deschide o conexiune catre serverul specificat ın comanda CONNECT s,i apoiretrimite datele dinspre client direct spre server s,i, reciproc, dinspre server

ınapoi spre client. In cazul unei cereri CONNECT, proxy-ul nu se implica maideparte ın comunicat,ia dintre client s,i server. Ca urmare, ın acest caz proxy-ulnu mai memoreaza paginile aduse s,i nu permite filtrarea cererilor decat dupaserverul s,i portul la care se conecteaza, ın schimb permite tunelarea oricaruiprotocol (nu numai a protocolului HTTP) ıntre un client dintr-o ret,ea cuadrese interne s,i un server din Internet.

11.3.2.5. Conexiuni securizate: SSL/TLS

SSL — Secure Sockets Layer , rom. nivelul conexiunilor securizate— este un protocol pentru securizarea conexiunilor. A fost creat de firmaNetscape ın vederea securizarii comunicat,iei ıntre clientul s,i serverul HTTP.Protocolul este ınsa suficient de flexibil pentru a permite oricarei aplicat,ii cecomunica prin conexiuni sa-l foloseasca. TLS [RFC 4346, 2006] — Transport



Layer Security, rom. securitate la nivel transport — este derivat din SSL ver-siunea 3, dar dezvoltat de IETF (Internet Engineering Task Force). In cele ceurmeaza, vom discuta doar despre TLS, ınsa toate chestiunile prezentate suntvalabile s,i pentru SSL.

Protocolul TLS presupune existent,a unei legaturi nesecurizate ıntreun client (entitatea care init,iaza activ comunicat,ia) s,i un server (entitateacare as,teapta sa fie contactata de catre client). Legatura nesecurizata este,ın mod obis,nuit, o conexiune TCP. Protocolul TLS ofera un serviciu de tipconexiune. TLS asigura confident,ialitatea s,i autenticitatea datelor utile trans-portate. Datele utile transportate de TLS pot apart,ine oricarui protocol. Pro-tocolul ale carui date sunt transportate ca date utile de catre TLS este numittunelat prin TLS.

In cadrul init,ierii unei conexiuni TLS, se realizeaza stabilirea uneichei de sesiune care este utilizata ın continuare pentru securizarea transportu-lui datelor utile. Autentificarea stabilirii cheii poate fi unilaterala, doar clien-tul autentificand serverul cu care a realizat negocierea cheii de sesiune, saubilaterala. In cazul autentificarii unilaterale, se poate utiliza o autentificare aclientului fat,a de server ın cadrul protocolului tunelat. In acest caz, deoareceserverul este deja autentificat, autentificarea clientului poate fi facuta prinparola, fara riscul ca parola sa fie transmisa unui adversar.

Autentificarea stabilirii cheii de sesiune se face printr-un mecanismde semnatura digitala. Pentru distribuirea sigura a cheilor publice, utilizateın cadrul autentificarii, se utilizeaza certificate (§ 6.3.4).

Serverul trebuie sa aiba o pereche de chei pentru semnatura digitalas,i un certificat, semnat de o autoritate ın care clientul are ıncredere, pentrucheia publica. La init,ierea conexiunii TLS, serverul transmite clientului certi-ficatul sau Clientul verifica faptul ca numele din certificat coincide cu numeleserverului la care dorea conectarea, ca semnatura autoritat,ii de certificareasupra certificatului este valida, ca autoritatea de certificare este de ıncrederes,i, ın final, utilizeaza cheia publica din certificatul clientului pentru a auten-tifica stabilirea cheii de sesiune. Daca se dores,te s,i autentificarea clientuluifat,a de server tot prin TLS, atunci clientul trebuie sa aiba, la randul sau, opereche de chei s,i un certificat.

In vederea verificarii semnaturii din certificat s,i a faptului ca sem-natarul (autoritatea de certificare) este de ıncredere, fiecare dintre parteneritrebuie sa aiba o lista cu cheile autoritat,ilor de certificare de ıncredere. Cheiaunei autoritat,i de certificare este, ın mod obis,nuit, plasata tot ıntr-un certifi-cat.

Certificatul unei autoritat,i de certificare poate fi semnat de catre o



alta autoritate de certificare sau chiar de catre autoritatea posesoare a certi-ficatului. In acest din urma caz, certificatul se numes,te certificat autosemnat

(engl. self-signed certificate) sau certificat radacina (engl. root certificate). Inmajoritatea cazurilor, clientul are o mult,ime de certificate autosemnate aleautoritat,ilor ın care are ıncredere.

Exista mai multe produse soft pentru crearea perechilor de chei s,ipentru crearea s,i semnarea certificatelor. Un astfel de produs este OpenSSL,disponibil pe sistemele de tip UNIX.

11.3.2.6. Utilizarea TLS pentru webTransferul securizat al paginilor web se realizeaza prin tunelarea pro-

tocolului HTTP peste SSL sau TLS. Construct,ia realizata se numes,te HTTPS.URL-urile resurselor accesibile prin conexiuni securizate au, ca nume

al protocolului, s,irul de caractere https (ın loc de http).Un navigator web care are de adus o pagina a carei URL are, ın

partea de protocol, https, executa urmatoarele:

• Afara de cazul ın care URL-ul specifica explicit un numar de port, clientuldeschide conexiunea catre portul 443 al serverului (ın loc de portul 80,implicit pentru HTTP).

• Daca, ın locul contactarii directe a serverului web, se utilizeaza un proxy,clientul trimite serverului proxy o cerere CONNECT pentru stabilirea co-nexiunii spre server. Prin aceasta conexiune, stabilita prin intermediulproxy-ului, se transmit mesajele SSL sau TLS, ın cadrul carora se trans-mit datele HTTP.

• La deschiderea conexiunii (fie conexiune TCP directa, fie un lant, de co-nexiuni TCP prin intermediul proxy-ului), are loc mai ıntai schimbul demesaje legat de stabilirea cheii SSL sau TLS. Dupa init,ializarea cone-xiunii securizate, prin canalul securizat are loc un dialog conform proto-colului HTTP. Cu alte cuvinte, cererile s,i raspunsurile HTTP constituiedate utile pentru nivelul SSL sau TLS.

Autentificarea serverului, ın cadrul protocolului TLS, necesita, as,acum am vazut, ca navigatorul web sa dispuna de certificatele autoritat,ilor de

certificare de ıncredere. In general, producatorii de navigatoare ıncorporeazaın acestea nis,te certificate, ale unor autoritat,i de certificare larg recunoscute.Utilizatorul poate ınsa sa dezactiveze oricare dintre aceste certificate, precums,i sa adauge alte certificate.

Atragem atent,ia asupra unor particularitat,i legate de utilizarea HTTPS:

• Deoarece autentificarea serverului, prin mecanismul TLS, se face ınaintea



trimiterii cererii HTTP, certificatul trimis de server nu poate depindede antetul Host transmis de catre client. Ca urmare, daca mai multesaituri web securizate sunt gazduite de un acelas,i calculator, este nece-sar ca aceste saituri sa fie distinse prin adresa IP sau prin numarul deport. In cazul ın care s-ar utiliza doar antetul Host pentru ca serverul sadetermine saitul cerut de client, serverul ar trimite acelas,i certificat in-diferent de saitul dorit de client. Ca urmare, ar exista o nepotrivire ıntrenumele din certificat s,i numele saitului solicitat de client. In consecint,a,clientul ar declara saitul ca fiind unul fals.

• O pagina web este formata, ın mod obis,nuit, din mai multe obiecte, cuURL-uri diferite (pagina HTML propriu-zisa s,i imaginile din pagina).

In aceste condit,ii, este posibil ca, ıntr-o aceeas,i pagina, unele dintre ele-mente sa fie securizate s,i celelalte elemente sa fie nesecurizate. De aseme-nea, este posibil ca diferite elemente sa provina de pe saituri diferite,autentificate prin certificate diferite. Intr-un astfel de caz, navigatorulweb trebuie sa avertizeze utilizatorul.

11.4. PGP/GPG

Preety Good Privacy (PGP) este un program pentru criptarea s,isemnarea digitala a mesajelor de pos,ta electronica s,i a fis,ierelor ın general.

Gnu Privacy Guard, abreviatGPG sauGnuPG, este o reimplementarea PGP, cu statut de soft liber.

Prezentam ın continuare principalele concepte legate de construct,ias,i funct,ionarea GnuPG.

11.4.1. Structura cheilor GnuPGPGP cripteaza mesajele, utilizand metode simetrice s,i chei efemere,

transmite cheile efemere prin criptare asimetrica s,i creaza semnaturi electron-ice asupra mesajelor.

In acest scop, fiecare utilizator GnuPG trebuie sa aiba nis,te perechide chei pentru criptare asimetrica s,i pentru semnatura.

GnuPG memoreaza, ın nis,te fis,iere gestionate de el, cheile publice s,iprivate ale utilizatorului ce executa comanda gpg, precum s,i cheile publice alepartenerilor utilizatorului ce executa gpg.

Descriem ın continuare structura cheilor GnuPG, precum s,i operat,iilece pot fi executate asupra cheilor memorate local. Transmiterea cheilor publiceıntre utilizatori va fi descrisa ın § 11.4.2.



Afis,area cheilor publice din fis,ierele gestionate de GnuPG se face princomanda

gpg --list-keys

Afis,area cheilor secrete se face prin comanda

gpg --list-secret-keys

11.4.1.1. Chei primare s,i subcheiCheile GnuPG sunt de doua tipuri: chei primare s,i subchei. O cheie

primara (de fapt, o pereche primara de chei) este ıntotdeauna o pereche dechei pentru semnatura digitala. O subcheie (de fapt, sub-pereche de chei) estesubordonata unei anumite perechi primare. Fiecare subcheie poate fi cheie decriptare sau cheie de semnatura.

Fiecare utilizator are o cheie primara s,i, subordonate acesteia, zero

sau mai multe subchei. In modul cel mai simplu de lucru, fiecare utilizatorGnuPG are asociate, doua perechi de chei: o pereche primara de chei pen-tru semnatura digitala s,i o sub-pereche de chei pentru criptare asimetrica.Perechea de chei de criptare este folosita pentru a trimite mesaje secrete pos-esorului perechii de chei. Perechea de chei de semnatura este folosita atuncicand posesorul trimite mesaje semnate.

Fiecare cheie publica are asociata as,a-numita amprenta a cheii (engl.key fingerprint). Aceasta este un s,ir de bit,i, calculat,i, printr-o funct,ie dedispersie criptografica, din cheia publica respectiva.

Pentru a ne putea referi la o pereche de chei, fiecare pereche de chei(fie ea primara sau subcheie) are asociate doi identificatori de cheie (engl. keyID):

• Identificatorul lung (engl. long key ID) este format din 16 cifre hexa.S,ansele ca doua chei distincte sa aiba acelas,i identificator lung suntextrem de mici, astfel ıncat identificatorul lung este suficient pentru aidentifica unic orice cheie. Totus,i, identificatorul lung nu este utilizabil,ın locul amprentei cheii, pentru verificarea autenticitat,ii acesteia.

• Identificatorul scurt (engl. short key ID) este format din ultimele 8 cifrehexa ale identificatorului lung. Daca, ıntr-un anumit context, nu existadoua chei cu acelas,i identificator scurt, el poate fi folosit pentru a nereferi la o cheie.

Identificatorul unei perechi de chei este calculat, printr-o funct,ie de dispersie,din cheia publica din pereche.

Identificatorii scurt,i ai cheilor pot fi listat,i prin comanda


396 11.4. PGP/GPG

gpg --list-keys

Pentru a lista identificatorii lungi, se poate da comanda

gpg --with-colons --list-keys

Amprenta unei chei primare se poate afla prin comanda

gpg --fingerprint id-cheie

unde id-cheie este fie identificatorul scurt sau lung al cheii primare sau al uneisubchei subordonate acesteia, fie numele real, adresa de pos,ta electronica saunumele complet al proprietarului cheii.

11.4.1.2. Utilizatori s,i identitat,iFiecarei chei primare ıi este asociata una sau mai multe identitat,i.

Fiecare identitate este un nume complet de utilizator, format din trei com-ponente: numele real (numele s,i prenumele persoanei), adresa de pos,ta elec-

tronica s,i, opt,ional, un comentariu. In scrierea numelui complet, adresa depos,ta electronica se scrie ıntre semne mai mic s,i mai mare, iar comentariul sescrie ıntre paranteze. Exemple:

Ion Popescu <[email protected]>

Gheorghe Ionescu (Presedinte ONG) <[email protected]>

Este posibil ca o cheie primara sa aiba asociate mai multe identitat,i.Acest lucru este util daca un utilizator are mai multe adrese de pos,ta elec-tronica s,i dores,te asocierea tuturor acestora cu aceeas,i cheie.

Reciproc, un acelas,i nume complet poate fi asociat mai multor cheiprimare. Acest lucru se ıntampla deoarece nu poate nimeni sa ımpiedice doiutilizatori sa genereze doua chei s,i sa le asocieze acelas,i nume complet.

Mai mult, aceasta posibilitate este utilizata frecvent ın situat,ia ın care

cheia primara a unui utilizator expira sau este revocata. In aceasta situat,ie,utilizatorul poate crea o noua cheie primara careia sa-i asocieze acelas,i numecomplet.

11.4.1.3. Generarea s,i modificarea cheilorGenerarea unei chei primare se face cu comanda

gpg --gen-key

Comanda este interactiva, solicitand utilizatorului urmatoarele informat,ii: tipulcheilor generate s,i dimensiunea acestora, durata de valabilitate a cheilor, nu-mele complet al utilizatorului s,i parola utilizata pentru criptarea cheii secrete.



Comanda genereaza o pereche primara de chei (de semnatura) s,i ıiasociaza o identitate. Opt,ional, comanda poate genera s,i o sub-pereche dechei de criptare, subordonata perechii primare. Ulterior, se pot adauga noisubchei s,i identitat,i sau se pot s,terge subcheile s,i identitat,ile asociate.

La generarea cheilor, GnuPG afis,eaza amprenta a cheii primare gen-erate. Este bine ca utilizatorul sa noteze amprenta cheii generate. Acest lucrueste util la transmiterea cheii publice catre partenerii de comunicat,ie.

Pentru o cheie primara data, proprietarul ei poate crea (s,i, eventual,s,terge) subchei. Pentru acestea, se lanseaza comanda

gpg --edit-key cheie

La lansarea acestei comenzi, gpg as,teapta, de la utilizatori, subcomenzi pentrumodificarea unor date privitoare la cheia primara identificata prin parametrulcheie. Terminarea seriei de subcomenzi se face dand, mai ıntai, subcomandasave pentru a memora efectiv modificarile efectuate, urmata de subcomandaquit.

Crearea unei noi subchei se face cu subcomanda addkey. Subcheiacreata poate fi o cheie de criptare sau o cheie de semnatura.

La s,tergerea unei subchei se utilizeaza subcomenzile key s,i delkey.S, tergerea unei subchei este utila doar daca subcheia nu a fost ınca transmisanimanui. Nu exista o metoda simpla de a propaga s,tergerea asupra copiilorsubcheii respective. Ca urmare, daca proprietarul dores,te ca o subcheie, dejatransmisa partenerilor sai, sa nu mai fie utilizata, solut,ia este revocarea sub-cheii s,i nu s,tergerea ei.

Pentru a adauga, s,terge sau revoca o identitate asociata unei chei, selanseaza comanda


s,i apoi se utilizeaza subcomenzile: adduid, uid, deluid, revuid, primary.Dupa modificarea identitat,ilor asociate unei chei primare, este necesara re-transmiterea cheii spre partenerii de comunicat,ie (vezi § 11.4.2.1).

11.4.1.4. Controlul perioadei de valabilitate a cheilor

Valabilitatea unei chei sau subchei este controlata pe doua cai: prinfixarea unei perioade de valabilitate, dupa expirarea careia cheia nu mai estevalida, s,i prin revocarea cheii. Controlul valabilitat,ii unei chei este necesarpentru a preıntampina utilizarea unei chei publice ın cazul ın care cheia secretacorespunzatoare a fost aflata de o persoana neautorizata.


398 11.4. PGP/GPG

Perioada de valabilitate a unei chei sau subchei se fixeaza la generareaacesteia. Ulterior, perioada de valabilitate poate fi modificata cu comanda


cu subcomenzile key s,i expire.Pentru revocarea unei chei primare, se creaza un certificat de revocare,

semnat de proprietarul cheii primare. Certificatul de revocare se transmiteapoi partenerilor de comunicat,ie.

Generarea certificatului de revocare se face prin comanda

gpg -a -o fis,ier --edit-key cheie

Certificatul de revocare este scris ın fis,ierul cu nume fis,ier. Pentru ca revocareasa aiba efect, certificatul de revocare trebuie importat prin comanda

gpg --import fis,ier

Odata importat un certificat de revocare pentru o cheie primara, semnaturilecreate cu acea cheie primara sau cu o subcheie a acesteia sunt considerateinvalide s,i, ın general, la orice utilizare a acelei chei sau a unei subchei gpg daun avertisment. De asemenea, atunci cand acea cheie primara este transmisaspre alt,i utilizatori (vezi § 11.4.2.1), certificatul de revocare este transmisımpreuna cu cheia revocata.

Ca utilizare recomandabila, este bine ca, la crearea unei chei primare,proprietarul ei sa genereze imediat un certificat de revocare pe care sa-l t,ina

ıntr-un loc sigur. In cazul ın care pierde cheia sau banuies,te ca acea cheiesecreta a fost aflata de un adversar, proprietarul transmite partenerilor saicertificatul de revocare. Inainte de revocare, certificatul de revocare trebuie sanu poata fi citit de nimeni; ın caz contrar, un adversar care obtine certificatulde revocare poate provoca neplaceri proprietarului revocandu-i cheia.

Revocarea unei subchei consta ın adaugarea la subcheie a unui mar-caj, semnat de proprietarul subcheii, prin care se anunt,a ca acea subcheietrebuie sa nu mai fie utilizata. O subcheie revocata este tratata similar cu osubcheie sau cheie expirata: daca se ıncearca utilizarea ei, gpg da un mesajde avertisment.

Revocarea unei subchei se face cu ajutorul comenzii


cu subcomenzile key s,i revkey.De notat ca, dupa revocarea sau schimbarea perioadei de valabilitate

a unei subchei, subcheia modificata trebuie sa ajunga la partenerii propri-etarului cheii (vezi § 11.4.2.1).



11.4.1.5. Gestiunea cheilor secreteGnuPG plaseaza cheile secrete ıntr-un fis,ier gestionat de GnuPG.

Acest fis,ier este creat cu drepturi de citire (ın sistemul de operare) doar pentruutilizatorul curent.

Cheile sunt, ın mod normal, criptate cu o parola data de utilizator.Parola de criptare poate fi schimbata cu comanda


subcomanda passwd.Cheile secrete pot fi exportate, prin comanda

gpg -a -o fis,ier --export-secret-keys cheie

Aceasta comanda exporta cheia secreta primara identificata prin parametrulcheie, precum s,i subcheile sale secrete. Cheile secrete pot fi importate princomanda


Acest lucru este util daca utilizatorul lucreaza pe mai multe calculatoare s,idores,te sa utilizeze aceeas,i chei pe mai multe calculatoare. Cheia secreta esteexportata ın forma criptata.

Exista posibilitatea de-a exporta doar subcheile secrete ale unei cheiprimare. Acest lucru se face prin comanda

gpg -a -o fis,ier --export-secret-subkeys cheie

Cu ajutorul acestei comenzi, un utilizator poate t,ine cheia primara secretape un calculator sigur s,i poate transmite subcheile secrete catre un calculator

mai put,in sigur pe care ıl utilizeaza frecvent. In acest mod, el poate utilizacalculatorul mai nesigur pentru transmite mesaje semnate s,i primi mesajecriptate utilizand subcheile, fara ınsa a risca compromiterea cheii primare ıncazul ın care cineva ar sparge acel calculator. Pentru o astfel de utilizare,subcheile se creaza cu durata de valabilitate scurta s,i se revoca la nevoie.Cheia primara este bine sa aiba durata lunga de utilizare pentru a beneficiade semnaturile obt,inute de la alt,i utilizatori asupra ei (vezi § 11.4.2.2).

11.4.2. Transmiterea s,i certificarea cheilor publice

11.4.2.1. Transmiterea cheilor publiceCheile publice primare, identitat,ile asociate, semnaturile asupra iden-

titat,ilor (vezi § 11.4.2.2), subcheile publice subordonate cheilor primare s,i cer-tificatele de revocare ale cheilor primare sau subcheilor sunt memorate ıntr-unfis,ier gestionat de GnuPG.


400 11.4. PGP/GPG

Transmiterea acestor obiecte de la un utilizator la altul se poate faceprin doua metode:

• prin fis,iere (transmise, de exemplu, prin pos,ta electronica sau prin web);

• prin servere de chei.

La transmiterea prin fis,iere, un utilizator exporta una sau mai multechei primare, ımpreuna cu identitat,ile, semnaturile, subcheile s,i certificatelede revocare asociate acelor chei primare, ıntr-un fis,ier. Celalalt utilizatorprimes,te fis,ierul (transmis prin pos,ta electronica, web, pe o discheta sau prinalte mijloace) s,i ıi importa cont,inutul ın GnuPG-ul local.

Exportul unei chei publice primare, ımpreuna cu toate identitat,ile,subcheile publice, semnaturile s,i certificatele de revocare asociate, se face princomanda

gpg -a -o fis,ier --export cheie

unde parametrul cheie este identificatorul cheii sau a uneia dintre subcheisau numele utilizatorului careia ıi apart,ine, iar parametrul fis,ier reprezintafis,ierul ın care se vor scrie datele. Parametrul cheie poate lipsi sau poate sanu identifice o unica cheie primara; ın acest caz, toate cheile primare respectivesunt exportate.

Importarea unei chei dintr-un fis,ier se face prin comanda


Prin operat,ia de import, cheile s,i celelalte obiecte din fis,ierul importatsunt adaugate celor locale sau, eventual, le modifica pe acestea. Niciodata ınsanu sunt s,terse obiecte locale pe motiv ca nu se regasesc ın fis,ierul importat. Dinacest motiv, s,tergerea unei chei primare, subchei, identitat,i sau semnaturi nupoate fi transmisa asupra partenerilor de comunicat,ie. Invalidarea unei chei,identitat,i sau semnaturi se poate face doar prin revocarea acesteia s,i apoitransmiterea certificatului de revocare.

La transmiterea prin servere de chei, primul utilizator ıncarca, pe unserver de chei, cheile s,i celelalte obiecte de transmis, iar celalalt utilizator ledescarca de pe serverul de chei.

Transmiterea unei chei primare s,i a obiectelor asociate catre un serverde chei se face prin comanda

gpg --keyserver server --send-key cheie

Descarcarea unei chei s,i a obiectelor asociate de pe un server de cheise face prin comanda

gpg --keyserver server --recv-key cheie



unde cheie este identificatorul unei chei (nu poate fi numele posesorului cheii).Aflarea identificatorului cheii unui utilizator se poate face prin comanda

gpg --keyserver server --search-key nume-utilizator

Este important de notat ca, implicit, GnuPG nu considera o cheieproaspat importata ca fiind autentica. La utilizarea unei chei publice a careiautenticitate nu a putut fi verificata, GnuPG da un mesaj de avertizare. Ver-ificarea autenticitat,ii este descrisa ın paragraful urmator.

11.4.2.2. Verificarea autenticitat,ii cheilor

GnuPG verifica automat, ınainte de utilizarea unei chei publice, aut-enticitatea acesteia. Autenticitatea cheilor se verifica cu ajutorul certificatelor(vezi § 6.3.4). In terminologia GnuPG, un certificat este numit semnaturaasupra unei chei.

O sub-cheie este ın mod normal semnata cu cheia primara careia ıieste subordonata. O sub-cheie a carei semnatura este valida este considerataautentica daca s,i numai daca cheia primara coresunzatoare este considerata

autentica. In consecint,a, daca se importa noi sub-chei pentru o cheie primaradeclarata autentica, sub-cheile respective sunt imediat considerate autentice.

Restul paragrafului de fat,a trateaza doar cheile primare. Reamintimca o cheie primara este ıntotdeauna o cheie de semnatura.

O cheie publica pentru care GnuPG dispune de cheia secreta core-spunzatoare este automat considerata autentica. De asemenea, este consid-erata autentica orice cheie specificata printr-o opt,iune

--trusted-key cheie

fie la execut,ia comenzii gpg, fie ın fis,ierul cu opt,iunile implicite. In afaraacestor doua cazuri, GnuPG considera o cheie autentica numai daca dispunede un certificat valid pentru ea s,i mai sunt ındeplinite urmatoarele condit,ii:

• cheia cu care este semnat certificatul este deja declarata ca autentica,

• semnatatul certificatului este considerat de ıncredere.

GnuPG ret,ine, asociate fiecarei chei primare, doua informat,ii (inde-pendente una de alta):

• daca autenticitatea ei este verificata sau nu;

• nivelul de ıncredere, acordat de utilizatorul care executa gpg, proprietaru-lui acelei chei.


402 11.4. PGP/GPG

Un utilizator poate acorda proprietarului unei chei:

• ıncredere deplina (full trusting) — semnatura acelui utilizator asupraunei identitat,i este suficienta pentru ca acea identitate sa fie considerataverificata;

• ıncredere minimala (marginally trusting) — o identitate semnata doar deutilizatori de ıncredere minimala sa fie considerata verificata este necesarun anumit numar de astfel de semnaturi (implicit 3).

• zero ıncredere (no trusting) — semnatura unui astfel de utilizator nu esteluata ın considerare.

Nivelul de ıncredere acordat proprietarului unei chei este implicit zero. Elpoate fi modificat cu comanda


s,i subcomanda trust a acesteia.Implicit, GnuPG are ıncredere deplina ın proprietarul unei chei pen-

tru care dispune de cheia secreta corespunzatoare (altfel spus, ın utilizatorulcare lanseaza comanda gpg), precum s,i ın proprietarii cheilor specificate prinopt,iunea --trusted-key.

Crearea, de catre utilizatorul ce executa gpg, a unei semnaturi asupraunei identitat,i asociate unei chei se face prin comanda

gpg --sign-key cheie

saugpg --lsign-key cheie

In cazul primeia dintre comenzi, semnatura poate fi transmisa s,i altor utiliza-tori GnuPG (vezi § 11.4.2.1). A doua comanda creaza o semnatura pentru uzlocal.

Este esent,ial, pentru securitatea sistemului, ca un utilizator sa nusemneze un set de chei fara sa-i verifice mai ıntai autenticitatea. Autenticitateasetului de chei se poate asigura ın doua moduri:

• Fis,ierul din care se importa setul de chei este adus pe o cale sigura, deexemplu printr-o discheta data personal de catre proprietarul cheii saueste descarcat de pe un sait web securizat (https) s,i de ıncredere.

• Intai, amprenta cheii primare este transmisa pe o cale sigura, de exem-plu pe un bilet scris de catre proprietarul cheii sau printr-o convorbiretelefonica cu proprietarul cheii. Apoi, la importarea s,i semnarea setuluide chei, utilizatorul verifica amprenta cheii primare din set.



11.4.3. Transmiterea mesajelor criptate sau semnateCrearea unui mesaj criptat s,i semnat se face astfel:

gpg -o fis,-ies,ire -r cheie-dest -se fis,-intrare

sau

gpg -a -o fis,-ies,ire -r cheie-dest -se fis,-intrare

unde fis,-intrare este fis,ierul ce trebuie semnat s,i criptat, fis,-ies,ire este fis,ierul ıncare comanda gpg va pune datele criptate s,i semnate, iar cheie-dest reprezintanumele utilizatorului destinat,ie sau identificatorul cheii de criptare de utilizate.Cea de-a doua varianta produce un fis,ier text ASCII, prin recodificare ın baza64.

Un mesaj poate fi adresat mai multor destinatari; pentru aceasta,se pot da, ın comanda gpg, mai multe opt,iuni -r, fiecare urmata de numeleunui utilizator destinat,ie. Oricare dintre destinatarii astfel specificat,i poatesa decripteze mesajul criptat.

La criptarea unui mesaj, GnuPG genereaza aleator o cheie efemera,cripteaza textul clar utilizand cheia efemera, iar apoi cripteaza cheia efemerautilizand cheia publica a destinatarului. Daca sunt mai mult,i destinatari,GnuPG cripteaza, pentru fiecare destinatar, cate o copie a cheii efemere, uti-lizand cheia publica a acelui destinatar.

Decriptarea unui mesaj se face prin comanda

gpg -o fis,-ies,ire --decrypt fis,-intrare

unde fis,-intrare este fis,ierul semnat s,i criptat, iar fis,-ies,ire este fis,ierul ın carecomanda gpg va pune rezultatul decriptarii. Comanda verifica s,i semnaturas,i afis,eaza pe ecran rezultatul verificarii.

Se pot genera mesaje numai criptate sau numai semnate.

Transmiterea unui mesaj criptat dar nesemnat nu este recomandabila,deoarece destinatarul nu poate avea nici un fel de certitudine asupra auten-ticitat,ii mesajului. Comanda de criptare este similara cu cea pentru criptares,i semnare, dar cu -e ın loc de -se. Comanda de decriptare este identica cucea pentru un mesaj criptat s,i semnat.

Pentru generarea unui mesaj semnat dar necriptat exista trei posi-bilitat,i: semnatura inclusa ın mesaj, semnatura detas,ata s,i semnatura ın clar.

Semnatura inclusa se genereaza similar cu generarea unui mesaj crip-tat s,i semnat, dar lipsesc destinatarii (opt,iunile -r) s,i ın loc de -se se da doar-s. Fis,ierul generat cont,ine datele originale s,i semnatura. Extragerea datelor


404 11.4. PGP/GPG

s,i verificarea semnaturii se face exact ca ın cazul unui mesaj criptat s,i semnat,adica prin comanda:

gpg -o fis,-ies,ire --decrypt fis,-intrare

Semnatura detas,ata se genereaza prin comanda

gpg -a -o fis,-sign --detach-sign fis,-date

Rezultatul comenzii este scrierea ın fis,ierul fis,-sign a semnaturii cont,inutuluifis,ierului fis,-date. Fis,ierul produs, fis,-sign, este mic s,i cont,ine doar semnatura;datele utile nu pot fi recuperate din el. Verificarea semnaturii se face princomanda:

gpg --verify fis,-sign fis,-date

Semnatura detas,ata este utila deoarece pastreaza intact fis,ierul dedate, nefiind nevoie de gpg pentru recuperarea datelor. De asemenea, permitemai multor utilizatori sa semneze un acelas,i fis,ier de date.

In fine, semnatura ın clar se poate utiliza doar daca datele sunt textASCII. Semnatura se genereaza prin comanda:

gpg -o fis,-ies,ire --clearsing fis,-intrare

Fis,ierul astfel produs este un fis,ier text, care poate fi citit us,or de catre uti-lizatorul uman. Textul original este pus ıntre nis,te marcaje, iar semnaturaeste adaugata la sfars,it. Verificarea semnaturii se face prin comanda:

gpg --verify fis,

Semnatura ın clar este utila pentru semnarea documentelor text.Acestea raman us,or de citit de catre om s,i, spre deosebire de semnaturadetas,ata, datele utile s,i semnatura sunt puse ıntr-un singur fis,ier.

Daca GnuPG are mai multe chei secrete (inclusiv subchei, § 11.4.1.1)utilizabile pentru semnatura, se poate specifica ce cheie trebuie utilizata pentrucrearea semnaturii. Specificarea cheii se face adaugand opt,iunea

-u cheie

GnuPG se utilizeaza curent pentru autentificarea softului liber. Inacest scop, alaturi de programul distribuit, se distribuie un fis,ier ce cont,inesemnatura detas,ata a fis,ierului ce cont,ine programul.

Documents

Acesta este capitolul 11 | Aplicat,ii^ n ret,ele | al edit,iei ...rlupsa/works/retele/retele-aplicatii.pdf · rlupsa/works/retele.pdf. c 2008, Radu-Lucian Lups,a 357 Capitolul 11