Universitatea Transilvania din Brasov

Retele de Calculatoare

Nume: Potorac Raducu Daniel

Anul: IV
Grupa: 4241 EA
 Lucrarea de laborator nr.1.
Lucrul cu analizorul de protocoale de reţea Wireshark

1. Enumeraţi o serie de protocoale care apar în coloana de protocoale nefiltrate de la

pasul 7.
UDP, TLSv1.2, TCP, SSDP, ICMPv7, DNS, ARP, HTTP
2. Care este durata între transmiterea mesajului HTTP GET şi recepţionarea răspunsului
HTTP GET? (În coloana “Time” din lista de pachete se măsoară timpul în secunde
din momentul începerii capturării. Pentru a se afişa timpul current se selectează
submeniul “View/Display Format/Time of day”).
1.46906 ms

3. Care este adresa de Internet pentru standards.ieee.org? Care este adresa de Internet a
computerului dumneavoastră?
Adresa standards.ieee.org: 140.98.193.116
Adresa mea: 192.168.1.3

4. Tipăriţi la imprimantă două mesaje „http” din pasul 9. Pentru aceasta selectaţi “Print”
din meniul „File”, selectaţi „Selected Packet Only” şi „Print as displayed”, după care
daţi comanda OK.
33 13:01:08.786905 192.168.1.3 standards.ieee.org HTTP 962 GET /about/get/802/802.3.html
HTTP/1.1 Frame 33: 962 bytes on wire (7696 bits), 962 bytes captured (7696 bits) on interface
0 Ethernet II, Src: Giga-Byt_82:63:69 (74:d4:35:82:63:69), Dst: Fiberhom_6d:78:c0
(bc:c0:0f:6d:78:c0) Internet Protocol Version 4, Src: 192.168.1.3 (192.168.1.3), Dst:
standards.ieee.org (140.98.193.116) 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes
(5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 948
Identification: 0x423b (16955) Flags: 0x02 (Don't Fragment) Fragment offset: 0 Time to live:
128 Protocol: TCP (6) Header checksum: 0x0000 [validation disabled] [Header checksum status:
Unverified] Source: 192.168.1.3 (192.168.1.3) Destination: standards.ieee.org (140.98.193.116)
[Source GeoIP: Unknown] [Destination GeoIP: Unknown] Transmission Control Protocol, Src Port:
61014, Dst Port: 80, Seq: 1, Ack: 1, Len: 908 Source Port: 61014 Destination Port: 80 [Stream
index: 1] [TCP Segment Len: 908] Sequence number: 1 (relative sequence number) [Next sequence
number: 909 (relative sequence number)] Acknowledgment number: 1 (relative ack number) 0101
.... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) Window size value: 64952
[Calculated window size: 64952] [Window size scaling factor: -2 (no window scaling used)]
Checksum: 0x1329 [unverified] [Checksum Status: Unverified] Urgent pointer: 0 [SEQ/ACK
analysis] TCP payload (908 bytes) Hypertext Transfer Protocol

305 13:01:10.255995 2620:104:c000:8193::112 2a02:2f0e:d460:1389:e16d:113:36c6:9a2e HTTP 1105

HTTP/1.1 200 OK (text/html) Frame 305: 1105 bytes on wire (8840 bits), 1105 bytes captured
(8840 bits) on interface 0 Ethernet II, Src: Fiberhom_6d:78:c0 (bc:c0:0f:6d:78:c0), Dst: Giga-
Byt_82:63:69 (74:d4:35:82:63:69) Internet Protocol Version 6, Src: 2620:104:c000:8193::112
(2620:104:c000:8193::112), Dst: 2a02:2f0e:d460:1389:e16d:113:36c6:9a2e
(2a02:2f0e:d460:1389:e16d:113:36c6:9a2e) Transmission Control Protocol, Src Port: 80, Dst
Port: 61019, Seq: 37001, Ack: 1563, Len: 1031 Source Port: 80 Destination Port: 61019 [Stream
index: 8] [TCP Segment Len: 1031] Sequence number: 37001 (relative sequence number) [Next
sequence number: 38032 (relative sequence number)] Acknowledgment number: 1563 (relative ack
number) 0101 .... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) Window size value:
5798 [Calculated window size: 5798] [Window size scaling factor: -2 (no window scaling used)]
Checksum: 0x647e [unverified] [Checksum Status: Unverified] Urgent pointer: 0 [SEQ/ACK
analysis] TCP payload (1031 bytes) TCP segment data (1031 bytes) [30 Reassembled TCP Segments
(38031 bytes): #250(1412), #251(1412), #252(1412), #255(1412), #256(1412), #257(1412),
#258(1412), #259(1412), #260(144), #268(1412), #269(1412), #270(1412), #272(1412), #273(1412),
#274(1412), #275(1412), #276(] Hypertext Transfer Protocol Line-based text data: text/html
 Lucrarea de laborator nr.2.
Protocolul HTTP

1. Browser-ul este versiunea 1.0 sau 1.1? Ce versiune de HTTP rulează pe server?
Versiunea 1.1. HTTP 1.1
2. Care limbi (dacă există) indică browser-ul că pot fi acceptate de către server?
Engleza

3. Care este adresa IP a calculatorului dvs.? Dar a serverului tc.unitbv.ro?

4. Care este codul “status” întors de la server către browser?

200 OK
5. Când a fost modificat ultima oară pe server, fişierul HTML pe care îl descărcaţi?
Mon, 03 Dec 2012 10:06:32
6. Câţi octeţi de payload sunt returnaţi către browser?
103 octeti
7. Priviţi fereastra “packet content”. Puteţi vedea vreun header în datele care nu sunt
afişate în fereastra packet-listing? Daca da, numiţi unul.
Header Length
8. Priviţi prima cerere HTTP-GET de la browser către server. Vedeţi o linie “IF-
MODIFIED-SINCE” ?

9. Priviţi răspunsul serverului. A întors serverul în mod explicit conţinutul fişierului?

Justificaţi.
10. Acum priviţi a doua cerere HTTP-GET de la browser către server. Vedeţi o linie “IF-
MODIFIED-SINCE” ? Dacă da, ce informaţie urmează după header-ul lui “IF-
MODIFIED-SINCE” ?
Nu am o a doua cerere.
11. Priviţi al doilea răspuns al serverului. A întors serverul în mod explicit conţinutul
fişierului? Justificaţi.
12. Câte mesaje de cerere HTTP GET au fost trimise de către browser?
Un singur mesaj HTTP GET a fost trimis.

13. De câte segmente TCP care conţin date, a fost nevoie pentru a trimite singurul
răspuns HTTP?
14. Care este codul status asociat răspunsului cererii HTTP GET?
200
15. Există vreo linie status HTTP în transmisiunea asociată cu cuvântul “Continuation”
TCP?
Nu exista.
16. Câte mesaje de cerere HTTP GET au fost trimise de către browser? Către care
adresă?
2 measje catre 193.254.231.38 si 193.254.231.113

17. Puteţi spune dacă browser-ul a descărcat cele 2 imagini una după alta, sau au fost
descărcate simultan de la cele două site-uri? Justificaţi.
Au fost desacarcate succesiv
18. Care este răspunsul server-ului la primul mesaj HTTP GET ?

19. Când browser-ul trimite mesajul HTTP GET a doua oară, ce câmp nou apare în
mesaj?
 Lucrarea de laborator nr.3.
Protocolul DNS
1. Rulaţi nslookup pentru a obţine adresa IP a unui web server din Asia.

2. Rulaţi nslookup pentru a determina servere “authoritative” DNS din Europa.

3. Rulaţi nslookup astfel încât unul dintre serverele DNS obţinute la punctul 2 să fie
întrebat în legătură cu serverele de mail al Yahoo! Mail

4. Găsiţi întrebarea DNS şi mesajele de răspuns. Sunt trimise peste UDP sau TCP?
Sunt trimise peste UDP
5. Care este portul destinaţie pentru mesajele cerere DNS? Care este portul sursă
pentru mesajele de răspuns DNS?
POrtul 53 pentru sursa si destinatie
6. La ce adresa IP este trimis mesajul cerere DNS? Folosiţi ipconfig pentru a vedea
adresa serverului dvs local DNS. Apare aceeaşi adresă IP?
7. Examinaţi mesajul cerere DNS. Ce “fel” de întrebare DNS este? Mesajul întrebare
conţine vreun “răspuns”?
Intrebare Type A. fara raspuns.
8. Examinaţi mesajul DNS de răspuns. Câte “răspunsuri” sunt oferite? Ce conţine
fiecare răspuns?

9. Priviţi pachetul TCP SYN trimis ulterior de către host. Adresa IP de destinaţie a
pachetului SYN corespunde vreunei adrese IP oferită în mesajul de răspuns DNS?
Primul pachet SYn e trimis catre 104.20.1.85 care este aceeasi cu adresa din mesajur
DNS de raspuns
10. Această pagină web conţine imagini. Înainte de a descărca fiecare imagine, host-ul
face alte cereri DNS?
Nu contine imagini
11. Care este portul destinaţie pentru mesajul cerere DNS? Care este portul sursă a
mesajului de răspuns DNS?
Port 53.
12. La care adresă IP este mesajul cerere DNS trimis? Este aceasta adresa IP a serverului
DNS local?
Catre 192.168.1.1 adresa DNS proprie
13. Examinaţi mesajul cerere DNS. Ce “fel” de mesaj cerere este? Conţine vreun
“răspuns” ?
Queri type AAAA (IPv6 address)

14. Examinaţi mesajul de răspuns DNS. Câte “răspunsuri” sunt oferite? Ce conţine
fiecare dintre aceste răspunsuri?

16. La care adresă IP este mesajul cerere DNS trimis? Este aceasta adresa IP a serverului
dvs DNS local?

Catre 192.168.1.1 adresa DNS proprie

17. Examinaţi mesajul cerere DNS. Ce “fel” de mesaj cerere este? Conţine vreun
“răspuns” ?

Intrebare type NS, fara raspunsuri.

18. Examinaţi mesajul de răspuns DNS. Ce “nameservere” ale Universităţii oferă mesajul
răspuns? Acest răspuns oferă şi adresele IP ale “nameserverelor” Universităţii?

ns-b.unitbv.ro;
ns.unitbv.ro;
ns-a.unitbv.ro.

Nu contine adresele IP

19. Faceți un screenshot.

20. La care adresă IP este mesajul cerere DNS trimis? Este aceasta adresa IP a serverului
dvs DNS local? Dacă nu, care este corespondenta adresei IP?

DNS-ul e trimis la 193.254.230.2 ns.uitbv.ro

21. Examinaţi mesajul cerere DNS. Ce “fel” de mesaj cerere este? Conţine vreun
“răspuns” ?

Intrebare type AAAA, fara raspunsuri

22. Examinaţi mesajul de răspuns DNS. Câte “răspunsuri” sunt oferite? Ce conţine
fiecare dintre răspunsuri?

23. Faceţi un screenshot.

 Lucrarea de laborator nr.4.
Protocolul TCP

1. Care este adresa IP şi portul TCP folosite de computerul care transferă fişierul către
“tc.unitbv.ro”? Puteţi selecta un mesaj HTTP şi explora detaliile pachetului TCP folosit
pentru a transporta acest mesaj, folosind “details of the selected packet header window”?

2. Care este adresa IP a serverului “tc.unitbv.ro”? Pe care port trimite şi pe care primeşte
segmente TCP pentru această conexiune? Dacă aţi putut să vă faceţi propriul trace,
răspundeţi şi la întrebarea:

3. Care este adresa IP şi portul TCP folosite de computerul dvs. pentru a transfera fişierul la
“tc.unitbv.ro”?
4. Care este numărul secvenţial al segmentului TCP SYN care este folosit pentru a iniţia
conexiunea între computer şi “tc.unitbv.ro”? Ce anume din segment îl identifică drept
un segment SYN?

5. Care este numărul secvenţial al segmentului SYNACK trimis de “tc.unitbv.ro” la

computerul dvs., ca replică la SYN? Care este valoarea câmpului de confirmare în
segmentul SYNACK? Cum a determinat “tc.unitbv.ro” valoarea? Ce anume din segment îl
identifică drept un segment SYNACK?
6. Care este numărul secvenţial al segmentului TCP care conţine comanda HTTP POST?
Pentru aceasta trebuie să căutaţi în “packet content field” şi să căutaţi un segment cu
“POST” în câmpul DATA.
7. Priviţi segmentul TCP care conţine HTTP POST ca fiind primul segment în conexiunea
TCP. Care sunt numerele secvenţiale în conexiunea TCP (inclusiv segmentul cu HTTP
POST) ? La ce oră a fost trimis fiecare segment? Când a fost recepţionat ACK pentru
fiecare segment? Dată fiind diferenţa dintre momentul în care a fost trimis fiecare
segment TCP şi momentul în care i s-a răspuns cu o confirmare, care este valoarea RTT
pentru fiecare dintre cele 6 segmente? Care este “Estimated RTT Value” după recepţia
fiecărui ACK?
8. Care este lungimea fiecăruia dintre cele 6 segmente TCP?

9. Care este valoarea minimă de “buffer space” văzută la recepţie pentru întregul trace?
Datorită faptului că spaţiul buffer-ului este prea mic, transmiţătorul este limitat?
10. Există vreun segment retransmis în trace? Justificaţi răspunsul.
Nu exista segmente retransmise
11. Câtă informaţie confirmă receptorul în ACK? Puteţi identifica cazurile pentru care
receptorul confirmă (ACK) la fiecare segment recepţionat?
 Lucrarea de laborator nr.5.
Protocolul UDP

1. Din câmpul “packet content”, aflaţi lungimea (în biţi) a fiecărui câmp UDP header.
2 bytes
2. A cui lungime o reprezintă valoarea din câmpul “Lungime”? Verificaţi răspunsul cu
pachetul UDP capturat.
8 byres header+ 42 bytes date
3. Care este numărul maxim de biţi care poate fi inclus într-un payload UDP?
(216 – 1) – header bytes(8)= 65535 – 8 = 65527 bytes.
4. Care este cel mai mare număr posibil al source port-ului ?
216 – 1=65535
5. Care este numărul protocolului UDP? Răspundeţi în hexa şi în zecimal (puteţi să vă
uitaţi în header-ul IP).
6. Căutaţi “UDP” în Google şi găsiţi câmpurile de unde se calculează UDP checksum.
https://www.slashroot.in/how-is-tcp-and-udp-checksum-calculated
7. Priviţi o pereche de pachete UDP în care primul pachet este trimis de computerul dvs.
iar al doilea pachet este replica primului pachet. Explicaţi legătura dintre numerele
porturilor din cele 2 pachete.
Portul sursă al pachetului UDP trimis de gazdă este același ca portul de destinație al
pachetului de răspuns și, invers, portul de destinație al pachetului UDP trimis de gazdă
este același ca portul sursă al pachetului de răspuns.
8. Capturaţi un mic pachet UDP. Verificaţi manual checksum-ul acestui pachet. Arătaţi
cum aţi lucrat şi explicaţi fiecare pas.
 Lucrarea de laborator nr.6.
Protocolul IP

1. Selectaţi primul mesaj ICMP Echo Request trimis de computerul dvs. şi extindeţi partea
de Internet Protocol a pachetului. Care este adresa IP a computerului dvs. ?
192.168.1.1
2. Care este valoarea câmpului “upper layer protocol” în header-ul pachetului IP?
ICMP
3. Câţi octeţi sunt în header-ul IP? Câţi octeţi sunt în payload-ul datagramei IP? Justificaţi
răspunsul.
20 de octeti in header IP
56 octeti lungime totala
36 octeti in payload
4. Această datagrama IP a fost fragmentată? Justificaţi răspunsul.
Nu este fragmestat, deoarece “more fragments” din “flags” este setat pe 0
5. Care câmpuri din datagrama IP se schimbă întotdeauna de la o datagramă la
următoarea, în această serie de mesaje ICMP?
Se schimba Identification, time to live , header checksum
6. Care câmpuri rămân constante? Care câmpuri trebuie să rămână constante? Care
câmpuri trebuie să se schimbe? De ce?
Version, header length, source ip, destination ip, differential services, upper layer
protocol raman constant
Se schimba identification. Time to live, header checksum
7. Descrieţi modelul pe care-l vedeţi în valorile din câmpul Identification al datagramei IP.
Modelul este că header-ul IP crește câmpurile Identification cu fiecare cerere ICMP Echo
(ping).
8. Care este valoarea din câmpurile Identification şi TTL?
Valoarea din câmpul Identification este 40316. Valoarea din câmpul TTL este 255.
9. Rămân aceste valori neschimbate pentru toate replicile ICMP TTL-exceeded trimise la
computerul dvs. de la cel mai apropiat router? De ce?
Câmpul Identification se modifică pentru toate replicile ICMP TTL-exceeded, deoarece
câmpul Identification este o valoare unică. Atunci când două sau mai multe datagrame IP
au aceeași valoare de identificare, înseamnă că aceste datagrame IP sunt fragmente ale
unei singure scale datagrame IP.
Câmpul TTL rămâne neschimbat, deoarece TTL pentru primul ruter de hamei este
întotdeauna același.
10. Găsiţi primul mesaj ICMP Echo Request care a fost trimis de către computerul dvs. după
ce aţi schimbat Packet Size la 2000 în pingplotter. A fost acel mesaj fragmentat de-a
 lungul mai multor datagrame IP? (Notă: dacă pachetul dvs. nu a fost fragmentat, folosiţi
fişierul ip-ethereal-trace-1 din arhiva wireshark-traces.zip).
Da a fost fragmentat
11. Tipăriţi primul fragment al datagramei IP fragmentate. Ce informaţie din header-ul IP
indică faptul că datagrama a fost fragmentată? Ce informaţie din header-ul IP indică
dacă acesta este primul sau ultimul fragment? Cât de lungă este această datagramă IP?
Bitul de la câmpul ”More Fragments” din ”Flags” este setat la 1, indicând faptul că
datagrama a fost fragmentată. Deoarece bitul de la câmpul ”Fragment offset” din
”Flags”este setat la 0, știm că acesta este primul fragment. Această primă datagramă are
o lungime totală de 1500, inclusiv header-ul.

12. Tipăriţi al doilea fragment al datagramei. Ce informaţie din header-ul IP indică faptul că
acesta nu este primul fragment? Există mai multe fragmente? Justificaţi răspunsul.
Informația din header-ul IP care ne indică faptul că acesta nu este primul fragment este
”Fragment offset”, care are valoarea 1480. Acesta este ultimul fragment, din moment ce
câmpul ”More fragments” din ”Flags” este setat la 0.
13. Care câmpuri se schimbă în header-ul IP între primul şi al doilea fragment?
Total, legth, flags, fragment offset, header, checksum
14. Câte fragmente au fost create din datagrama originală?
3 fragmente
15. Ce câmpuri s-au schimbat în header-ul IP de la un fragment la altul?
Fragment offset, header checksum, total length, flags, more fragments
 Lucrarea de laborator nr.7.
Protocolul NAT

1. Care este adresa IP a clientului?

Adresa IP a clientului este 192.168.1.100
2. De fapt clientul comunică cu mai multe servere Google diferite pentru a implementa
“safe browsing”. Serverul principal Google care are pagina principală Google, are
adresa IP 64.233.169.104. Pentru a afişa doar cadrele care conţin mesaje HTTP care
sunt trimise la / de la acest server Google, scrieţi “http&&ip.addr==64.233.169.104”
la filtrul Wireshark.

3. Priviţi acum mesajul HTTP GET trimis de la client la serverul Google (al cărui IP este
64.233.169.104) la momentul 7.102967. Care sunt adresele IP şi porturile TCP ale
sursei şi destinaţiei pe datagrama IP care transportă acest HTTP GET?
4. La care moment este recepţionat mesajul corespunzător 200 OK HTTP de la serverul
Google? Care sunt adresele IP şi porturile TCP ale sursei şi destinaţiei pe datagrama
IP care transportă mesajul 200 OK HTTP?
5. Mesajul corespunzător 200 OK HTTP de la serverul Google este recepționat la
momentul 7.158797.
Adresa IP a sursei este 64.233.169.104, iar portul TCP al sursei este 80.
Adresa IP a destinației este 192.168.1.100, iar portul TCP al destinației este 4335.
6. Ştim că înainte ca o comandă GET să poată fi trimisă unui server HTTP, TCP trebuie
întâi să seteze o conexiune folosind “three-way SYN/ACK handshake”. La care
moment este trimis, de la client către server, segmentul TCP SYN care setează
conexiunea folosită de GET la momentul 7.102967 ? Care sunt adresele IP şi porturile
TCP ale sursei şi destinaţiei pentru acest segment TCP SYN ? Care sunt adresele IP şi
porturile TCP ale sursei şi destinaţiei pe datagrama IP ale ACK-ului trimis ca răspuns
lui SYN ? La ce moment este acest ACK recepţionat la client? (Aici trebuie să scrieţi
“tcp” la filtru).

Pentru segmentul TCP SYN:

 a) Segmentul TCP SYN care setează conexiunea folosită de GET la momentul 7.102967
este
trimis, de la client către server, la momentul 7.075657.
b) Adresa IP a sursei este 192.168.1.100, iar portul TCP al sursei este 4335.
c) Adresa IP a destinației este 64.233.169.104, iar portul TCP al destinației este 80.

Pentru ACK-ul trimis ca răspuns lui SYN:

a) Adresa IP a sursei este 64.233.169.104, iar portul TCP al sursei este 80.
b) Adresa IP a destinației este 192.168.1.100, iar portul TCP al destinației este 4335.
c) Acest ACK este recepționat la client la momentul 7.108986.

7. În fişierul NAT_ISP_side, mesajul HTTP GET a fost trimis de la client către Google la
7.102967 (unde t = 7.102967 este timpul când mesajul a fost trimis, după cum a fost
înregistrat în trace-ul NAT_home_side). La care moment apare mesajul în trace-ul
NAT_ISP_side ? Care sunt adresele IP şi porturile TCP ale sursei şi destinaţiei pe
datagrama IP care transportă acest HTTP GET (după cum s-a înregistrat în trace-ul
NAT_ISP_side) ? Care dintre aceste câmpuri sunt aceleaşi şi care sunt diferite, faţă de
răspunsul din întrebarea 3. ?
Momentul la care apare mesajul în trace-ul NAT_ISP_side este 6.069168.
Adresa IP a sursei este 71.192.34.104, iar portul TCP al sursei este 4335.
Adresa IP a destinației este 64.233.169.104, iar portul TCP al destinației este 80.
Campuri neschimbate din IP: port TCP sursa, IP destinatie, port tcp destinatie
8. Este vreun câmp din mesajul HTTP GET schimbat ? Care dintre câmpurile următoare
din datagrama IP este schimbat: Version, Header Length, Flags, Checksum? Justificaţi
răspunsurile.
Nu exista nici un camp schimbat
9. În trace-ul NAT_ISP_side, la care moment a fost recepţionat mesajul 200 OK HTTP de
la serverul Google? Care dintre aceste câmpuri sunt la fel, şi care sunt diferite faţă de
răspunsul de la întrebarea 4 ?
Momentul la care a fost recepționat mesajul 200 OK HTTP de la serverul Google este
6.117570.
Campuri neschimbate, adresa ip sursa, port TCP sursasi destinatie

10. În fişierul NAT_ISP_side, la care moment a fost capturat segmentul client-to-server

TCP SYN ţi segmentul server-to-client TCP ACK corespunzătoare segmentelor din
întrebarea 5? Care sunt adresele IP şi porturile TCP ale sursei şi destinaţiei pentru
aceste segmente? Care dintre aceste câmpuri sunt la fel şi care sunt diferite faţă de
răspunsul la întrebarea 5? 10. Folosindu-vă de răspunsurile de la întrebările 1-8,
completați tabela de translaţie NAT pentru conexiunea HTTP din întrebările de mai
sus.

Pentru segmentul TCP SYN:

a) Momentul la care a fost capturat segmentul client-to-server TCP SYN este 6.035475.
b) Adresa IP a sursei este 71.192.34.104, iar portul TCP al sursei este 4335.
c) Adresa IP a destinației este 64.233.169.104, iar portul TCP al destinației este 80.
 d) Câmpurile neschimbate sunt:
port TCP sursa si destinatie, adresa IP destinatie
e) Adresele IP ale surselor sunt diferite: 192.168.1.100 la întrebarea 5 și 71.192.34.104 la
întrebarea 9.

Pentru segmentul TCP ACK:

a) Momentul la care a fost capturat segmentul server-to-client TCP ACK este 6.067775.
b) Adresa IP a sursei este 64.233.169.104, iar portul TCP al sursei este 80.
c) Adresa IP a destinației este 71.192.34.104, iar portul TCP al destinației este 4335.
d) Câmpurile neschimbate sunt:
Adresa IP a sursei;
Portul TCP al sursei;
Portul TCP al destinației;
e) Adresele IP ale destinațiilor sunt diferite: 192.168.1.100 la întrebarea 5 și
71.192.34.104 la întrebarea 9.
 Lucrarea de laborator nr.8.
Protocolul ICMP

1.Care este adresa IP a computerului dvs? Care este adresa IP a destinaţiei?

destinatie 154.67.228.152
eu 192.168.1.1
2.De ce un pachet ICMP nu are numere de porturi pentru sursă şi destinaţie?
Deoarece a fost proiectat să comunice informațiile din nivelul Rețea între host-uri și
servere
3.Priviţi un pachet ping de cerere trimis de computerul dvs. Care sunt tipul şi
codul numerelor de ICMP? Ce alte câmpuri mai are acest pachet ICMP? Câți octeţi sunt
în câmpurile “checksum”, “sequence number” şi “identifier” ?
Tipul ICMP 8, numar cod ICMP 0
pachetul icmp are:
checksum, identifier BE si LE, sequence number BE si LE, data
avem 2 octeti in checksum, sequence number si identifier
4.Priviţi pachetul corespunzător ping de răspuns. Care sunt tipul şi codul
numerelor de ICMP? Ce alte câmpuri mai are acest pachet ICMP? Câţi octeţi sunt în
câmpurile “checksum”, “sequence number” şi “identifier” ?
Numărul tipului de ICMP este 0, iar numărul codului de ICMP este 0.
pachetul contine checksum, identifier BE si LE, sequence number BE si LE, data
avem 2 octeti in checksum, sequence number si identifier
 5..Care este adresa IP a computerului dvs? Care este adresa IP a destinaţiei?
eu 192.168.1.1
destinatie 160.45.170.10
6.Dacă ICMP a trimis pachete UDP (ca în Unix/Linux), ar mai fi numărul
protocolului IP, 01 pentru pachetele de probă? Daca nu, care ar fi?
Nu. Dacă ICMP a trimis pachete UDP, atunci numărul protocolului IP ar trebui să
fie 0x11.
7.Priviţi pachetul “ICMP echo” din imaginea dvs. Este diferit faţă de pachetele
ICMP ping de cerere din prima parte a laboratorului? Dacă da, în ce fel?
nu este diferit
8.Priviţi pachetul “ICMP error” din imaginea dvs. Are mai multe câmpuri decât pachetul ICMP
echo. Ce este inclus în aceste câmpuri?
Acest pachet conține header-ul IP și primii 8 octeți ai pachetului ICMP original
9.Priviţi ultimele 3 pachete ICMP primite de către PC-ul sursă. În ce fel sunt aceste pachete
diferite de pachetele “ICMP error”? De ce sunt diferite?
Ultimele trei pachete ICMP sunt mesaje de tipul 0 (răspunsul la ecou) și nu 11 (TTL expirat). Ele sunt
diferite, deoarece datagramele au făcut tot drumul către host-ul destinație înainte ca TTL-ul să
expire.
10.În măsurătorile tracert, există vreun link a cărui întârziere este mult mai lungă
decât a celorlalte? Priviți imaginea a patra, există acolo un link a cărui întârziere este mai
lungă decât a altora? Bazându-vă pe numele routere-lor puteţi spune locaţia celor două
routere de la capătul link-ului?
Intre masuratoarea 3 si 4 brasov si Frankfurt
 Lucrarea de laborator nr.9.
Protocoalele Ethernet şi ARP

1. Care este adresa Ethernet pe 48b a computerului dvs?

2. Care este adresa destinaţie pe 48b din cadrul Ethernet? Este aceasta adresa
Ethernet pentru “tc.unitbv.ro”? (Indiciu: răspunsul este nu). Ce dispozitiv are
această adresă ca adresă pentru Ethernet? Atenţie la această întrebare !!!
Bc:c0:of:6d:78:co
3. Scrieţi valoarea hexazecimală pentru câmpul de 2B “Frame-type”. Ce reprezintă
în câmpul „flag” biţii a căror valoare este 0 (dar 1)?
4. Câţi octeţi de la începutul cadrului Ethernet apar până la simbolul “G” în ASCII,
din “GET” în cadrul Ethernet?
40 de octeti
5. Care este valoarea hexazecimală a câmpului CRC în acest cadru Ethernet?
NU existe valoare hexa
6. Care este valoarea adresei sursă Ethernet? Este aceasta adresa computerului
dvs, sau a lui “tc.unitbv.ro” (Indiciu: răspunsul este nu). Ce dispozitiv are aceasta
drept adresa sa Ethernet?
00:0e:2e:59:33:f7. Adresa routerului
7. Care este valoarea adresei sursa Ethernet? Este această adresă Ethernet, adresa
computerului dvs?
54:ee:75:c9:8a:f8. Adresa Ethernet a PC-ului
8. Scrieţi valoarea hexazecimală a câmpului de 2B “Frame type”’. În câmpul „flag”,
ce înseamnă biţii a căror valoare este 0 (dar 1)?
Frame type” este 0x0800.
9. Câţi octeţi de la începutul cadrului Ethernet apar până la simbolul ASCII “O”, din
“OK” (de exemplu în HTTP response code), în acest cadru Ethernet?
54 de octeti
10. Care este valoarea hexazecimală a câmpului CRC în acest cadru Ethernet?
Nu există valoarea hexazecimală pentru CRC
 11. Scrieţi conţinutul cache-ului ARP. Ce reprezintă valoarea fiecărei coloane?
Coloana ”Internet Address” conține adresele IP, coloana ”Physical Address” conține
adresele MAC, iar coloana ”Type” indică tipul protocolului.
12. . Care sunt valorile hexazecimale pentru adresele sursă şi destinaţie din cadrul
Ethernet care conţine mesajul de cerere ARP?
Valoarea hexazecimală pentru adresa sursă este b8:70:f4:f9:da:77, iar valoarea
hexazecimală pentru adresa destinație este ff:ff:ff:ff:ff:ff.
13. Scrieţi valoarea hexazecimală pentru câmpul de 2B Ethernet Frame type. Ce
reprezintă biţii a căror valoare este 1 ?
Frame type este 0x0806.
14. Descărcaţi specificaţiile ARP de la ftp://ftp.rfc-editor.org/innotes/std/std37.txt. Un alt
studiu se afla şi la http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/arp.html
a) Cu câți octeţi începe câmpul ARP opcode de la începutul cadrului Ethernet?
20 de octeti
b) Care este valoarea câmpului opcode din porţiunea ARP-payload a cadrului
Ethernet, prin care se face cererea ARP?
Valoarea 1
c) Mesajul ARP conţine adresa IP a transmiţătorului?
Adresa IP a transmițătorului este 192.168.8.18.
d) Unde apare “întrebarea” – adresa Ethernet a computerului a cărui adresă IP corespunzătoare
este interogată? - în cererea ARP?
În cererea ARP, ”întrebarea” – adresa Ethernet a computerului a cărui adresă IP corespunzătoare (în
cazul meu 192.168.8.1) este interogată - apare în câmpul ”Target MAC Address”, care este setat la
00:00:00:00:00:00.
15. Acum găsiţi replica ARP care a fost trimisă ca răspuns cererii ARP.
a) Cu câți octeţi începe câmpul ARP opcode de la începutul cadrului Ethernet?
20 de octeti
b) Care este valoarea câmpului opcode din porţiunea ARP-payload a cadrului Ethernet, prin care
se face răspunsul ARP?
Valoarea câmpului opcode din porțiunea ARP-payload a cadrului Etherney este 2
c) Unde, în mesajul ARP, apare “răspunsul” la cererea ARP precedentă – adresa IP a
computerului care are adresa Ethernet a cărui adresă IP corespunzătoare este interogată?
În mesajul ARP, ”răspunsul” la cererea ARP precedentă – adresa IP a computerului care are adresa
Ethernet a cărui adresă IP corespunzătoare (în cazul meu 192.168.8.1) este interogată - apare în
câmpul ”Sender MAC Address”, care are adresa Ethernet 00:30:05:82:84:b6.
16. Care sunt valorile hexazecimale pentru adresele sursă şi destinaţie din cadrul Ethernet care
conţine mesajul „ARP reply”?

Valoarea hexazecimală pentru adresa sursă este: 00:30:05:82:84:b6.

Valoarea hexazecimală pentru adresa destinație este: b8:70:f4:f9:da:77.

17. Deschideţi fişierul ethernet-trace-1 de pe CD). Primele două pachete ARP din acest trace
corespund unei cereri ARP trimisă de computerul pe care rulează Wireshark, şi replicii ARP
trimisă către computerul cu Wireshark de către computerul cu “ARP-requested Ethernet address”.
Dar mai există încă un computer în această reţea, după cum indică pachetul 6 – altă cerere ARP.
De ce nu există o replică ARP (trimisă ca răspuns cererii ARP din pachetul 6) în trace?

Apare cererea ARP la pachetul nr. 64, iar răspunsul apare la următorul pachet (nr. 65).
 Lucrarea de laborator nr.10.
Protocolul wireless 802.11

1. Care sunt SSID-urile celor două AP-uri care livrează cele mai multe dintre cadrele jalon
din acest trace?
SSID-ul primului AP este ”30 Munroe St.”, iar SSID-ul celui de-al doilea AP este ”linksys12”.

2. Care sunt intervalurile de timp dintre transmisia cadrelor jalon ale AP-ului Linksys_ses_24086?
Dar pentru AP-ul 30 Munroe St.? (indiciu: acest interval este conţinut chiar în cadrul jalon)

Intervalul jalon pentru ambele AP-uri sunt raportate în ”Beacon Interval” din ”IEEE 802.11 wireless
LAN management frame” ca fiind de 0.1024 secunde.

3. Care (în notația hexa) este adresa MAC sursă a cadrului jalon din 30 Munroe St.? Reţineţi că
sursa, destinaţia şi BSS-ul sunt 3 adrese folosite într-un cadru 802.11.

Adresa MAC sursă a cadrului jalon din 30 Munroe St. este 00:16:b6:f7:1d:51.

4. Care (în notaţia hexa) este adresa MAC destinaţie a cadrului jalon din 30 Munroe St.?

Adresa MAC destinație a cadrului jalon din 30 Munroe St. este ff:ff:ff:ff:ff:ff.

5. Care (în notaţia hexa) este ID-ul MAC BSS a cadrului jalon din 30 Munroe St.?

ID-ul MAC BSS a cadrului jalon din 30 Munroe St. este 00:16:b6:f7:1d:51.

6. Cadrele jalon din AP-ul 30 Munroe St anunţă faptul că AP-ul poate suporta 4 “data rates” şi 8
“extended support rates” adiţionale. Ce sunt aceste “rates” ?

Cele 4 “data rates” pe care le poate suporta AP-ul 30 Munroe St. sunt 1, 2, 5.5 și 11 Mbps.
Cele 8 “extended support rates” pe care le poate suporta AP-ul AP-ul 30 Munroe St. sunt 6, 9, 12, 18,
24, 36, 48 și 54 Mbps.

7. Găsiţi cadrul 802.11 care conţine segmentul SYN TCP pentru această primă sesiune TCP (care
descarcă alice.txt). Care sunt trei câmpuri de adrese MAC din cadrul 802.11? Care adresă MAC
din acest cadru corespunde host-ului wireless (daţi reprezentarea hexa a adresei MAC pentru
host)? Dar AP-ului? Dar primului router (first-hop router)? Care este adresa IP a host-ului
wireless care trimite acest segment TCP? Care este adresa IP destinaţie? Această adresă IP
destinaţie corespunde host-ului, AP-ului, primului router, sau unui altui dispozitiv ataşat la
rețea? Justificaţi răspunsul.

Cele trei câmpuri de adrese MAC din cadrul 802.11 sunt: BSS id, source address, destination address

Adresa MAC care corespunde host-ului wireless este cea a sursei (00:13:02:d1:b6:4f).
Adresa MAC care corespunde AP-ului este cea a lui BSS (00:16:b6:f7:1d:51).
Adresa MAC care corespunde primului router (first-hop router) este cea a destinației
(00:16:b6:f4:eb:a8).
Adresa IP a host-ului wireless care trimite acest segment este TCP este 192.168.1.109.
Adresa IP destinație este: 128.119.245.12.
Această adresă IP destinație corespunde serverului gaia.cs.umass.edu.
Adresa MAC destinație a cadrului care conține SYN este diferită de adresa IP de destinație a
pachetului IP conținut în acest cadru.

8. Găsiți cadrul 802.11 care conţine segmentul SYN ACK pentru această sesiune TCP. Care sunt
trei câmpuri de adrese MAC din cadrul 802.11? Care adresă MAC din acest cadru corespunde
host-ului? Dar AP-ului? Dar primului router? Adresa MAC a transmiţătorului din cadru
corespunde adresei IP a dispozitivului care a trimis segmentul TCP încapsulat în această
datagramă?

Cele trei câmpuri de adrese MAC din cadrul 802.11 sunt: BSS id, source address, destination address

Adresa MAC care corespunde host-ului este cea a destinației (91:2a:b0:49:b6:4f).

Adresa MAC care corespunde AP-ului este cea a lui BSS (00:16:b6:f7:1d:51).
Adresa MAC care corespunde primului router este cea a sursei (00:16:b6:f4:eb:a8).
Adresa IP a server-ului care a trimis segmentul TCP încapsulat este 128.199.245.12.
Nu, adresa MAC a transmițătorului din cadru nu corespunde adresei IP a dispozitivului care a trimis
segmentul TCP încapsulat în această datagramă.

9. Care două acţiuni sunt făcute (de exemplu cadre trimise) de către host în trace-ul imediat
după t=49, pentru a termina asocierea cu AP-ul 30 Munroe St care a fost iniţial activ atunci când
a început captura trace-ului? (indiciu: una este o acţiune de layer IP, iar alta este de layer
802.11). Privind specificaţiile 802.11, există vreun alt cadru pe care v-aţi fi aşteptat să-l vedeți,
dar care nu se vede aici?

La t = 49.583615 un release DHCP este trimis de către gazdă către serverul DHCP (a cărui adresă IP
este 192.168.1.1) în rețeaua pe care o părăsește host-ul. La t = 49.609617, host-ul trimite un cadru
DEAUTHENTICATION (Type = Management frame (0), Subtype = 12). S-ar fi putut aștepta să fie
trimisă o cerere de DISASSOCIATION.

10. Priviţi trace-ul şi căutaţi cadrele AUTHENTICATION trimise de la host către AP şi viceversa.
Câte mesaje AUTHENTICATION sunt trimise de la host-ul wireless către AP-ul Linksys_ses_24086
(care are adresa MAC Cisco_Li_f5:ba:bb) care începe în jurul lui t=49?

Primul mesaj AUTHENTICATION trimis de la host-ul wireless către AP-ul Linksys_ses_24086 este la
momentul t = 49.638857 și, în total, sunt trimise 19 mesaje.

11. Se vede o replică AUTHENTICATION de la AP-ul Linksys_ses_24086 în trace?

Nu se vede.
12. Acum să studiem ce se întâmplă dacă host-ul renunţă la a mai încerca să se
asocieze cu AP-ul Linksys_ses_24086 şi acum încearcă să se asocieze cu AP-ul 30
Munroe St. Căutaţi cadrele AUTHENTICATION trimise de la host către ţi
viceversa. La care momente de timp apare un cadru AUTHENTICATION de la
 host către AP-ul 30 Munroe St, şi când apare un răspuns AUTHENTICATION
trimis de la acel AP către host? (puteţi folosi expresiile de filtrare
“wlan.fc.subtype == 11 si wlan.fc.type == 0 şi wlan.addr == IntelCor_d1:b6:4f”
pentru a afişa doar cadrele AUTHENTICATION)
La t = 63.168087 există un cadru AUTHENTICATION trimis de la 00:13:02:d1:b6:4f
(host) la 00:16:b7:f7:1d:51 (AP). La t = 63.169071 există un cadru AUTHENTICATION
trimis din direcția inversă de la AP la host.
13. Un cadru ASSOCIATE REQUEST şi un cadru ASSOCIATE RESPONSE corespunzător
de la AP la host sunt folosite pentru ca hostul să se asocieze cu un AP. La care
moment de timp apare un ASSOCIATE REQUEST de la host la AP-ul 30 Munroe
St? Când este trimis cadrul ASSOCIATE REPLY corespunzător? (puteţi folosi
expresiile de filtrare wlan.fc.subtype<2 si wlan.fc.type == 0 si wlan.addr ==
IntelCor_d1:b6:4f p entru a a fişa d oar c adrele A SSOCIATE R EQUEST ş i
ASSOCIATE RESPONSE)

La t = 63.169910 există un cadru ASSOCIATE REQUEST trimis de la 00:13:02:d1:b6:4f (host) la

00:16:b7:f7:1d:51 (AP). La t = 63.192101 există un cadru ASSOCIATE RESPONSE trimis în direcția
inversă de la AP la host.

14. Ce rate de transmisie doreşte host-ul să folosească? Dar AP-ul? Pentru a

răspunde la aceste întrebări, trebuie să căutaţi în câmpurile de parametri ai
cadrului de management 802.11 wireless LAN.

Ratele de transmisie pe care hostul dorește să le folosească sunt următoarele: 1, 2, 5.5, 11, 6, 9, 12,
18, 24, 36, 48 și 54 Mbps. Aceste rate de transmisie sunt aceleași și la AP.

15. Care sunt adresele de BSS ID MAC ale transmiţătorului şi receptorului din aceste
cadre? Care este scopul acestor două tipuri de cadre? (este bine să consultaţi
aici referinţele online citate în acest laborator).

La t = 2.297613 există un PROBE REQUEST trimis cu sursa 00:12:f0:1f:57:13, destinația ff:ff:ff:ff:ff:ff și

BSS ID ff:ff:ff:ff:ff:ff. La t = 2.300697 există un PROBE RESPONSE trimis cu sursa 00:16:b6:f7:1d:51,
destinația 00:12:f0:1f:57:13și BSS ID 00:16:b6:f7:1d:51. Un PROBE REQUEST este folosit de un host în
scanare activă pentru a găsi un AP. Un PROBE RESPONSE este trimis de către AP către host-ul care
trimite cererea
 Lucrarea de laborator nr.11.
Protocolul DHCP

1. Mesajele DHCP sunt trimise peste UDP sau peste TCP?

Mesajele DHCP sunt trimise peste UDP.

2. Desenaţi o datagramă temporală ilustrând succesiunea primelor 4 pachete

Discover/Offer/Request/ACK DHCP între client şi server. La fiecare pachet indicaţi
porturile sursă şi destinaţie. Sunt aceleaşi porturi ca în exemplul de mai sus?
Da, sunt aceleași porturi.
3. Care este adresa link-layer (de exemplu Ethernet) a computerului?
Adresa link-layer a computerului este 54:ee:75:c9:8a:f8.
4. Ce valori din mesajul DHCP Discover diferenţiază acest mesaj de mesajul DHCP Request?
Valoarea din mesajul DHCP care diferențiază acest mesaj de mesajul DHCP Request este cea
de la Option: (53) DHCP Message Type.

5. Care este valoarea „Transaction-ID-ului” pentru fiecare dintre primele 4 mesaje

(Discover/Offer/Request/ACK) DHCP ? Care este valoarea „Transaction-ID-ului pentru al doilea
set (Request/ACK) de mesaje DHCP? Care este scopul câmpului Transaction-ID?

Valoarea „Transaction-ID-ului” pentru fiecare dintre primele 4 mesaje (Discover/Offer/Request/ACK)

DHCP este 0xf186db36.
Valoarea „Transaction-ID-ului” pentru al doilea set (Request/ACK) de mesaje DHCP este 0x5db53f5a.
Un „Transaction-ID” este utilizat astfel încât serverul DHCP să poată face diferența între cererile clientului
în timpul procesului de solicitare.

5. Un computer foloseşte DHCP pentru a obţine, printre altele, o adresă IP. Dar IP-ul unui
computer nu este confirmat până la sfârșitul schimbului de 4 mesaje! Dacă adresa IP nu
este setată până la sfârșitul schimbului celor 4 mesaje, atunci ce valori sunt folosite în
datagramele IP în respectivul schimb? La fiecare dintre cele 4 mesaje DHCP
(Discover/Offer/Request/ACK) indicaţi porturile sursă şi destinaţie care sunt
transportate în datagrama IP.
6. Clientul și serverul DHCP folosesc ambele 255.255.255.255 ca adresă destinație. Clientul
utilizează adresa IP sursă 0.0.0.0, în timp ce serverul utilizează adresa IP actuală ca sursă.
La mesajele DHCP Discover şi DHCP Request avem:
- Portul sursă: 68;
- Portul destinaţie: 67.

La mesajele DHCP Offer şi DHCP ACK avem:

- Portul sursă: 67;
- Portul destinaţie: 68.

7. Care este adresa IP a serverului DHCP?

Adresa IP a serverului DHCP este 192.168.0.1.
8. Ce adresă IP oferă serverul DHCP computerului dvs în mesajul DHCP Offer? Indicaţi care
mesaj DHCP conţine adresa IP oferită.
Serverul DHCP oferă computerului meu adresa IP 192.168.0.100. Mesajul DHCP cu ”DHCP
Message Type *DHCP: Offer (2)+” conține adresa IP dorită.
9. În imaginea de mai sus, nu există “relay agent” între computer şi serverul DHCP. Care
valori din trace indică absenţa unui “relay agent”? Există un “relay agent” în experiment?
Dacă da, care este IP-ul lui?
Adresa IP al “relay agent”-ului este 0.0.0.0, ceea ce indică absența unui “relay agent”. Nu, nu
există niciun “relay agent” în experiment.s
10. Explicaţi scopul router-ului şi a măștii din mesajul DHCP Offer.

Linia ”Option: (3) Router” indică clientului ce ar trebui să fie gateway-ul său implicit. Linia
”Option: (1) Subnet Mask” îi spune clientului care mască de subrețea ar trebui să o utilizeze.

11. În imaginile de mai sus, computerul cere adresa IP oferită în mesajul DHCP Request . Ce
se întâmplă în experimentul vostru?
În experimentul meu, host-ul solicită adresa IP oferită în mesajul DHCP Request.
12. Ce scop are “lease time” (timpul de închiriere)? Cât de mare este el în experimentul dvs?
Timpul de închiriere reprezintă perioada în care serverul DHCP atribuie o adresă IP unui
client. În timpul perioadei de închiriere, serverul DHCP nu va atribui IP-ul acordat clientului
unui alt client, decât dacă este eliberat de client. Odată ce termenul de închiriere a expirat,
adresa IP poate fi refolosită de serverul DHCP pentru a da unui alt client. În experimentul
meu, timpul de închiriere este de 7 zile.
13. Care este scopul mesajului DHCP Release? Serverul DHCP oferă vreo confirmare a
primirii cererii clientului? Ce s-ar întâmpla dacă mesajul DHCP release al clientului, s-ar
pierde?
Clientul trimite un mesaj DHCP Release pentru a-și anula leasing-ul pe adresa IP dată de
serverul DHCP. Serverul DHCP nu trimite un mesaj înapoi către client, confirmând mesajul
DHCP Release. Dacă mesajul DHCP Release de la client este pierdut, serverul DHCP va trebui
să aștepte până când perioada de leasing va fi terminată pentru acea adresă IP până când nu
ar putea fi reutilizată pentru alt client.
14. Ştergeţi filtrul bootp din Wireshark. A fost vreun pachet ARP trimis sau primit în perioada
schimbului de pachete DHCP? Dacă da, explicaţi scopul pentru care există aceste
pachete ARP.
Nu, nu a fost trimis sau primit niciun pachet ARP în perioada schimbului de pachete DHCP.
 Lucrarea de laborator nr.12.
Protocolul SSL

1. Pentru fiecare dintre cele 8 cadre Ethernet, specificaţi sursa cadrului (client sau server),
determinaţi numărul de tipuri de înregistrări SSL care sunt incluse în cadru, şi listaţi
tipurile de înregistrări SSL care sunt incluse în cadru. Desenaţi o diagramă temporală
între client şi server, cu o săgeată pentru fiecare înregistrare SSL.

2. Fiecare din înregistrările SSL începe cu aceleaşi 3 câmpuri (posibil cu valori diferite). Unul
dintre aceste câmpuri este “content type” şi are lungimea de un octet. Listaţi toate 3
câmpurile şi lungimile lor.

Content Type – 1 octet;

Version – 2 octeți;
Length – 2 octeți.

3. Extindeţi înregistrarea „ClientHello” ( dacă trace-ul conţine mai multe înregistrări

“ClientHello”, extindeţi-o pe prima). Care este valoarea lui “content type”?
”content type” este 22.
4. Înregistrarea „ClientHello” conţine un “nonce” (sau “challenge”) ? Dacă da, care este
valoarea challenge-ului în notaţia hexazecimală?
Valoarea challenge-ului în notația hexazecimală este 66df784c048cd60435dc448989469909
 5. Înregistrarea „ClientHello” face cunoscută “cyber suites” pe care le suportă? Dacă da, în
prima suită listată, care sunt: algoritmul public-key, algoritmul symmetric-key şi
algoritmul hash?
Da. În prima suită listată, avem RSA (public-key), RC4 (symmetric-key) și MD5 (hash).

6. Găsiţi înregistrarea „ServerHello”. Există aici vreo informaţie care spune ce “cipher suite”
s-a folosit? Care sunt algoritmii folosiți în suita care s-a ales?
Da. În suita care s-a ales, avem RSA (public-key), RC4 (symmetric-key) și MD5 (hash).

7. Această înregistrare include un “nonce”? Dacă da, cât de lung este? Care este scopul
nonce-urilor clientului şi serverului în SSL?
Da, sub câmpul ”Random”. ”Nonce”-ul este lung de 32 de octeți (4 octeți pentru timp și 28
octeți pentru date). Scopul este de a preveni un atac de reluare.

8. Această înregistrare include un ID de sesiune. Care este scopul acestui ID?

Scopul acestui ID este acela de oferi un identificator persistent unic pentru sesiunea
SSL care este trimisă în mod clar. Clientul poate relua aceeași sesiune mai târziu utilizând ID-
ul de sesiune furnizat de server când trimite ”ClientHello”.

9. Această înregistrare conţine o certificare, sau este această certificare inclusă într-o
înregistrare separată? Încape această certificare într-un singur cadru Ethernet?

Această înregistrare nu conține nici o certificare. Această certificare este inclusă într-
o înregistrare separată. Da, această certificare încape într-un singur cadru Ethernet.

10. Găsiţi înregistrarea “Client Key Exchange”. Conţine această înregistrare un secret
“pre-master” ? La ce este folosit acest secret ? Este criptat? Daca da, cum? Cat de
lung este acest secret?

Da, această înregistrare conține un secret “pre-master”. Acest secret este folosit atât de server cât și
de client pentru a face un secret ”master”, care este folosit pentru a genera chei de sesiune pentru
MAC și criptare. Secretul este criptat folosind cheia publică a serverului, pe care clientul o extrage
din certificatul trimis de server. Secretul are o lungime de 132 octeți.

11. Care este scopul înregistrării „Change Cipher Spec”? Câţi octeţi are înregistrarea din trace-ul
vostru?

Scopul înregistrării „Change Cipher Spec” este acela de a indica că conținutul

următoarelor înregistrări SSL trimise de client (date, nu header) va fi criptat. Această
înregistrare are o lungime de 6 octeți.
 12. În înregistrarea encrypted handshake, ce anume este criptat? Cum?
În „Encrypted Handshake”, este generat și trimis pe server un MAC al concatenării
tuturor mesajelor handshake anterioare trimise de la acest client.

13. Serverul trimite şi o înregistrare change cipher şi o înregistrare encrypted

handshake către client? În ce fel sunt aceste înregistrări diferite de cele trimise de către
client?
Da. Înregistrarea encrypted handshake a serverului este diferită de cea trimisă de
client, deoarece conține concatenarea tuturor mesajelor handshake trimise de la server de
la client. În caz contrar, înregistrările ar fi la fel.

14. Cum este criptată “application data”? Înregistrările care conţin “application
data” includ un MAC? Wireshark poate distinge între “application data” care este
criptată şi MAC?
“Application data” este criptată utilizând algoritmul de criptare ”symmetric-key” ales
în faza handshake (RC4), utilizând cheile generate folosind cheia ”pre-master” și ”nonces”-
urile de la client și server. Cheia de criptare a clientului este utilizată pentru a cripta datele
trimise de la client la server, iar cheia de criptare a serverului este utilizată pentru a cripta
datele trimise de la server către client.
15. Comentaţi şi explicaţi orice altceva ce vi s-a părut interesant în trace.
Versiunea SSL a folosit modificările de la SSLv2 din mesajul ”ClientHello” inițial la SSLv3
în toate schimburile de mesaje care urmează.
De asemenea, în timpul reluării, procesul de handshake este ușor diferit de cel inițial. Clientul
nu are nevoie de alt argument, astfel încât serverul să nu îl trimită niciodată. Trebuie să
trimită un nou ”nonce” urmat de înregistrările ”Change Cipher Spec” și ”Encrypted
Handshake” de la server la client. După răspunsul clientului, datele de aplicație pot fi trimise