TacAck - My security journey! » Network Information Store

POTD #1 – TCP – Transmission Control Protocol

TacAck — Tue, 08 Sep 2009 09:05:11 +0000

SIZE : 20-60 Bytes ( 20 min + 40 options )

USE : In services which require accuracy and error-checking.

ADVANTAGE : requests retransmission of lost packets, rearranges out-of-order packets, and even helps minimize network congestion, accurate delivery of data , reliable because of acknowledgements.

DISADVANTAGE : Slower, not real-time. Cannot be used for VoIP , streaming ,etc.

PACKET STRUCTURE :

Field		Size( bits )	Significance

Source Port		16	Identifies the sending port
Destinaton Port		16	identifies the receiving port
Sequence number		32	If the SYN flag is set, then this is the initial sequence number. The sequence number of the actual first data byte will then be this sequence number plus 1. If the SYN flag is not set, then this is the sequence number of the first data byte
Ack number		32	if the `ACK` flag is set then the value of this field is the next expected sequence number that the receiver is expecting
Data offest		4	specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.
Reserved		4	for future use and should be set to zero
Flags
	CWR	1	Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the `ECE` flag set and had responded in congestion control mechansim (added to header by RFC 3168).
	ECE	1	indicates that the TCP peer is ECN capable if the `SYN` flag is also set that a packet with Congestion Experienced flag in IP header set is received during normal transmission(added to header by RFC 3168).
	URG	1	indicates that the URGent pointer field is significant
	ACK	1	indicates that the ACKnowledgment field is significant. All packets after the initial `SYN` packet sent by the client should have this flag set
	PSH	1	Push function
	RST	1	Reset the connection
	SYN	1	Synchronize sequence numbers
	FIN	1	No more data from sender
Window Size		16	the size of the receive window, which specifies the number of bytes (beyond the sequence number in the acknowledgment field) that the receiver is currently willing to receive
Checksum		16	The 16-bit checksum field is used for error-checking of the header and data
Urgent Pointer		16	if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte
Options		0-320	The length of this field is determined by the data offset field. Options 0 and 1 are a single byte (8 bits) in length. The remaining options indicate the total length of the option (expressed in bytes) in the second byte.

I’ve mooched everything of Wikipedia.. This would’ve been a personal document, but i thought sharing it would be a better idea.

Tomorrow -> UDP.

Certificates before Certifications! (2/2)

TacAck — Fri, 17 Jul 2009 10:54:16 +0000

Alrighty, we know how certificates work and what they do, yadda yadda… Now Lets’s go into the “CERTIFICATE”. Let’s explore the fields present in a certificate , what they mean and how they’re significant.

A Certificate maybe used for many applications like VPN setup ( a big aloha to fellow CCSP’s ), NAC , s-mime, online banking , etc : but they all comply to the ITU-T X.509 standard. Meaning that the format of the certificate is dictated by X.509. PKI uses X.509 version 3 certificates to achieve this. So i went ahead and tried to learn the fields in the X.509 certificate. I found this . Or better yet, let me take a sample certificate and explain the fields to you.

I have with me here the Ceritificate of Thawte Consultancy. (This is a Root CA )

Field	Value	Meaning

Version	V3	This certificate follows the X.509 v3 hence the Value of “V3”.
Serial Number	00	This field represents the serial number of the certificate generated by the CA. If it’s the first Certificate generated , then the serial no is 00 and so on . Here it’s 00, because this is the CA certificate ( certificate of the CA) which will obviously be the first certificate generated
Signature Algorithm	Md5RSA	This is the algorithm used by the CA to sign the certificate.
Issuer	E = personal-basic@thawte.comCN = Thawte Personal Basic CAOU = Certification Services DivisionO = Thawte Consulting L = Cape Town S = Western Cape C = ZA	This fields represent the details of the CA who has issued this certificate . Here since it’s the CA’s certificate, it is obvious that it has been issued by itself.This Is a distinguished name. E -> Email address of the issuerCN -> Common Name OU -> Organisational Unit?? Unsure! O -> Organization L -> Location ( city ) S -> State C – >Country
Valid from	Monday, January 01, 1996 5:30:00 AM	Date from which the certificate is valid
Valid To	Friday, January 01, 2021 5:29:59 AM	Date until which the certificate is valid
Subject	E = personal-basic@thawte.comCN = Thawte Personal Basic CAOU = Certification Services DivisionO = Thawte Consulting L = Cape Town S = Western Cape C = ZA	This is the details of the owner of the CA. Here this is same as the issuer because for this certificate the issuer and the subject are the same.
Public Key	30 81 89 02 81 81 00 bc bc 93 53 6d c0 50 4f 82 15 e6 48 94 35 a6 5a be 6f 42 fa 0f 47 ee 77 75 72 dd 8d 49 9b 96 57 a0 78 d4 ca 3f 51 b3 69 0b 91 76 17 22 07 97 6a c4 51 93 4b e0 8d ef 37 95 a1 0c 4d da 34 90 1d 17 89 97 e0 35 38 57 4a c0 f4 08 70 e9 3c 44 7b 50 7e 61 9a 90 e3 23 d3 88 11 46 27 f5 0b 07 0e bb dd d1 7f 20 0a 88 b9 56 0b 2e 1c 80 da f1 e3 9e29 ef 14 bd 0a 44 fb 1b 5b 18 d1 bf 23 93 21 02 03 01 00 01	This is the Public key of Thawte Personal Basic A. ( Comparing this to our example in part one, this would be the public key of B used for encryption.)
Thumbprint Algorithm	Sha1	Algorithm used for hashing the certificate. This is to ensure that the certificate has not been tampered with during it’s travel.
Thumbprint	40 e7 8c 1d 52 3d 1c d9 95 4f ac 1a 1a b3 bd 3c ba a1 5b fc	This is the HASH value of the certificate. When A receives this certificate, he does a hash of the certificate and compares it with this hash-value. If it’ s identical the certificate is processed further, otherwise rejected.

There is also another important field in a X.509 v3 certificate which gives the certificate hierarchy. If this certificate was issued by an Intermediate-CA, then the certificate path would contain All the intermediate-CA’s above the issuer along with the topmost ( a.k.a Root CA) . This indicates how the certification process takes place.

I’m in a hurry now, i’m rushing home in a couple of mins, hence the shabby post. I will do some plastic surgery on it once i get back.

Hope you understood atleast half i wanted you to understand. If not, please hit wiki or google .

Certificates before Certifications! (1/2)

TacAck — Fri, 17 Jul 2009 09:45:00 +0000

The concept of certificates was something i thought i was “iffy” about. Meaning-> I’d a fair idea what it was but i wouldn’t dare explain it to anyone. You know the feeling right?! So i sat today and looked through some articles about Certificates. And here are my findings.

The magic question : What are certificates?

The not so magical answer : They are ways of identifying people, devices, websites or institutions.

So we know that certificates are used to verify if the other party are who they claim they are. CA’s are the dudes who act as the “verification reference”. Ok here’s an example. If A wants to talk to B but is not sure if the person responding to his questions are actually B, it asks for some proof. B provides a certificate issued by X ( a person that both A and B trust ). Once A gets this certificate and if the certificate is verified to be issued by X, A starts trusting B. So X here is a Certificate Authority ( because he has the authority to issue certificates ). If this clear lets dive in .

The certificate uses public-key encryption technique. To be specific RSA. I’m assuming that you know PKI is. This comes into play in two places.

1) For A to verify that B is producing a certificate assigned to it by X ( who is trusted by A ), X signs the certificate sent to B with the private-key of X. As soon as A gets the certificate , it decrypts it by using X’s public key. If this decryption is successful, A now knows that X created this certificate and assigned it to B. This is because the public-key can only Decrypt data signed by it’s sister Private-key. The private-key is only and Only known by the person it is created for ( X in this case ). So by decrypting the certificate using X’s public key, A confirms that it was encrypted using X’s private key.

2) Now A has authenticated that the certificate is genuine. In order to start communications with B over a insecure network, it has to encrypt the data. The encryption of data must be done by using B’s public key. This is to ensure that upon receiving the encrypted messages from A, B can decrypt it using B’s Private key. This ensures that data confidentiality is achieved. So you might get the question( if you are understand all of this ) , where the F*** does A get the public key of B from? Answer, B’s certificate. Yes, the public key of B is one of the fields in the certificate that B sends over to A .

Ok, to end the introduction, we can now say that the following things happen

B creates it’s public and private key-pair and sends the public key over the the CA ( X ).
It begs the CA to issue it a certificate ( ok, beg’s a little too dramatic! )
CA verifies that B is who he says he is and issues the certificate to B.
One of the payloads in the certificate is B’s public-key.
This certificate is signed by X’s private-key for verification of X.

If this is all an overload, re-read. Next article we go into X.509 certificates and their fields….