MON BLOG

Ce blog est d'abord un pense bete, qui peut aussi servir à ceux qui aiment bien regarder dans les tuyaux.

This blog is primarily a reminder that may be used to those like me who like to look in the pipes.






Article created on : August 2016.

RFC 793 PART 2

Exemple : HTTPS

HTTPS is a protocol for secure communication over a computer network which is widely used on the Internet.
When we do:

https://www.exemple.com

and at the same time :

tcpdump -vvv host exemple.com

The result of the traces is very different because it is an encrypted Secure protocol

However, we observe even the synchronization data, part of the metadata.

A problem of the secured protocols is that metadata are transmitted in clear anyway

We can see the request of synchronization (flag S)
Provider is the name of the FAI of exemple.com, and cluster11 is the name of a computer cluster.

10:09:14.637057 IP (tos 0x0, ttl 64, id 37729, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.65.59336 > cluster011.provider.net.https: Flags [S], cksum 0xb8fa (incorrect -> 0xb447), seq 2272313246, win 29200, options [mss 1460,sackOK,TS val 189410559 ecr 0,nop,wscale 7], length 0

And here's the answer from the server with the positive acknowledgment (ACK)

10:09:14.666919 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 60)
cluster011.provider.net.https > 192.168.1.65.59336: Flags [S.], cksum 0x1438 (correct), seq 299992791, ack 2272313247, win 17520, options [mss 1460,sackOK,wscale 12,TS val 23 ecr 189410559,eol], length 0
10:09:14.666987 IP (tos 0x0, ttl 64, id 37730, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.65.59336 > cluster011.provider.net.https: Flags [.], cksum 0xb8f2 (incorrect -> 0xbb57), seq 1, ack 1, win 229, options [nop,nop,TS val 189410566 ecr 23], length 0
10:09:14.697545 IP (tos 0x0, ttl 64, id 37731, offset 0, flags [DF], proto TCP (6), length 254)


Here we see a significant amount of data is transmitted (seq 1:203) but we know nothing more because the information is encrypted

192.168.1.65.59336 > cluster011.provider.net.https: Flags [P.], cksum 0xb9bc (incorrect -> 0xabe8), seq 1:203, ack 1, win 229, options [nop,nop,TS val 189410574 ecr 23], length 202
10:09:14.750856 IP (tos 0x0, ttl 59, id 30543, offset 0, flags [DF], proto TCP (6), length 1500)
cluster011.provider.net.https > 192.168.1.65.59336: Flags [.], cksum 0x4c83 (correct), seq 1:1449, ack 203, win 512, options [nop,nop,TS val 126087588 ecr 189410574], length 1448
10:09:14.750939 IP (tos 0x0, ttl 64, id 37732, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.65.59336 > cluster011.provider.net.https: Flags [.], cksum 0xb8f2 (incorrect -> 0xbba9), seq 203, ack 1449, win 251, options [nop,nop,TS val 189410587 ecr 126087588], length 0

10:09:18.447749 IP (tos 0x0, ttl 64, id 39539, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.65.59344 > cluster011.provider.net.https: Flags [.], cksum 0xb8f2 (incorrect -> 0x778e), seq 3896, ack 74898, win 1374, options [nop,nop,TS val 189411512 ecr 126088512], length 0
10:09:18.481632 IP (tos 0x0, ttl 64, id 28696, offset 0, flags [DF], proto TCP (6), length 440)

Here the customer makes a request using the GET method request to retrieve the application data but here we get into the details of the HTTP protocol that we will see soon

192.168.1.65.50070 > cluster011.provider.net.http: Flags [P.], cksum 0xba76 (incorrect -> 0xd150), seq 1:389, ack 1, win 229, options [nop,nop,TS val 189411520 ecr 126334447], length 388: HTTP, length: 388
GET /site/wp-content/uploads/logo_wiki.png HTTP/1.1
Host: www.exemple.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: sc_is_visitor_unique=rx9787249.1477040457.4DBF27945A4F4F9CC588162C73CCBFE4.10.9.6.6.6.6.5.4.4
Connection: keep-alive

10:09:18.481670 IP (tos 0x0, ttl 64, id 46896, offset 0, flags [DF], proto TCP (6), length 431)
192.168.1.65.50068 > cluster011.provider.net.http: Flags [P.], cksum 0xba6d (incorrect -> 0xe524), seq 1:380, ack 1, win 229, options [nop,nop,TS val 189411520 ecr 126334447], length 379: HTTP, length: 379
GET /site/wp-content/uploads/logo_contact.png HTTP/1.1
Host: www.exemple.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: sc_is_visitor_unique=rx9787249.1477040457.4DBF27945A4F4F9CC588162C73CCBFE4.10.9.6.6.6.6.5.4.4
Connection: keep-alive




Article created on : June 2016

RFC 793 PART 1

The RFC 793 Transmission Control Protocol is about tcp and describes the functions to be performed by the Transmission Control Protocol, the program that implements it, and its interface to programs or users that require its services

The RFC explain the motivations :
Computer communication systems are playing an increasingly important role in military, government, and civilian environments. (We are in 1981 !)
The RFC focuses its attention primarily on military computer communication requirements, especially robustness in the presence of communication unreliability and availability in the presence of congestion, but many of these problems are found in the civilian and government sector as well.

In general, the TCPs decide when to block and forward data at their own convenience.
Sometimes users need to be sure that all the data they have submitted to the TCP has been transmitted. For this purpose a push function is defined. To assure that data submitted to a TCP is actually transmitted the sending user indicates that it should be pushed through to the receiving user.

The TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. This is achieved by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted.

This is the general format of a sequence :

Source Port: 16 bits
Destination Port: 16 bits
Sequence Number: 32 bits

The sequence number of the first data octet in this segment (except when SYN is present). If SYN is present the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1.

Acknowledgment Number: 32 bits

If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent.

Data Offset: 4 bits
Reserved: 6 bits
Control Bits: 6 bits
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender

Window: 16 bits
Checksum: 16 bits

We use the sniffer tcpdump.

Tcpdump prints out a description of the contents of packets on a network interface with -v option for verbose output.

Example : tcpdump -vvv host caporali.fr

Tcpdump prints out only the packets in relation with caporali.fr in verbose mode.

Exemple de connexion TCP

The requested service is a telnet connexion, on port 80.
Telnet is a very old (and non secure) protocol used on the Internet or local area networks to provide a communication facility using a virtual terminal connection.
The connection is created and is then interrupted by the customer via Ctrl-C

telnet caporali.fr 80
Trying 178.32.221.75...
Connected to caporali.fr.
Escape character is '^]'.
^Connection closed by foreign host.

There is connection request.
The source machine is the 192.168.1.65, the destination server is : caporali.fr. We can see (in bold) the flag S.

10:15:06.081409 IP (tos 0x10, ttl 64, id 51021, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.65.51922 > caporali.fr.http: Flags [S], cksum 0x6a52 (incorrect -> 0x528b), seq 316620153, win 29200, options [mss 1460,sackOK,TS val 59898420 ecr 0,nop,wscale 7], length 0

The destination server responds me with the flag S and a positive acknowledgment (ACK) of 316620154
The number of ACK is the previous sequence number plus one which is normal

10:15:06.115215 IP (tos 0x0, ttl 58, id 64389, offset 0, flags [DF], proto TCP (6), length 60)
caporali.fr.http > 192.168.1.65.51922: Flags [S.], cksum 0x1b57 (correct), seq 4126018830, ack 316620154, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 1977299036 e cr 59898420], length 0

The connection has succeeded.

10:15:06.115271 IP (tos 0x10, ttl 64, id 51022, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.65.51922 > caporali.fr.http: Flags [.], cksum 0x6a4a (incorrect -> 0x4935), seq 1, ack 1, win 229, options [nop,nop,TS val 59898428 ecr 1977299036], length 0

Here the data starts to be transmitted.
. Seq 1: 6 means that there are 6 sequences of transmitted data

10:15:07.578831 IP (tos 0x10, ttl 64, id 51023, offset 0, flags [DF], proto TCP (6), length 57)
192.168.1.65.51922 > caporali.fr.http: Flags [P.], cksum 0x6a4f (incorrect -> 0x41c7),seq 1:6, ack 1, win 229, options [nop,nop,TS val 59898794 ecr 1977299036], length 5: HT TP

Then information is transmitted at the application level: we will see soon an article about HTTP

10:15:07.613469 IP (tos 0x0, ttl 58, id 64391, offset 0, flags [DF], proto TCP (6), length 377)
caporali.http > 192.168.1.65.51922: Flags [P.], cksum 0x9cb4 (correct), seq 1:326, ack 6, win 1040, options [nop,nop,TS val 1977300533 ecr 59898794], length 325: HTTP, len gth: 325
HTTP/1.1 400 Bad Request
Server: nginx/1.10.1
Date: Tue, 18 Jul 2016 08:33:20 GMT
Content-Type: text/html
Content-Length: 173
Connection: close

10:15:07.613558 IP (tos 0x10, ttl 64, id 51024, offset 0, flags [DF], proto TCP (6), length 52)

192.168.1.65.51922 > exemple.com.http: Flags [.], cksum 0x6a4a (incorrect -> 0x4093), seq 6, ack 326, win 237, options [nop,nop,TS val 59898803 ecr 1977300533], length 0

Following the loss of connection with ctrl-c, the server is sending the end flag : F

10:15:07.613571 IP (tos 0x0, ttl 58, id 64392, offset 0, flags [DF], proto TCP (6), length 52)

caporali.fr.http > 192.168.1.65.51922: Flags [F.], cksum 0x3d78 (correct), seq 326, ack 6, win 1040, options [nop,nop,TS val 1977300533 ecr 59898794], length 0

10:15:07.613670 IP (tos 0x10, ttl 64, id 51025, offset 0, flags [DF], proto TCP (6), length 52)

The client responds with the end flag

192.168.1.65.51922 > caporali.fr.http: Flags [F.], cksum 0x6a4a (incorrect -> 0x4091), seq 6, ack 327, win 237, options [nop,nop,TS val 59898803 ecr 1977300533], length 0

10:15:07.649095 IP (tos 0x0, ttl 58, id 64393, offset 0, flags [DF], proto TCP (6), length 52)
caporali.fr.http > 192.168.1.65.51922: Flags [.], cksum 0x3d4a (correct), seq 327, ack 7, win 1040, options [nop,nop,TS val 1977300569 ecr 59898803], length 0