i am learning the basics.......!

Sunday, December 31, 2006

SOCKS

SOCKS protocol can be used in situations where hosts on one side of the network needs to access hosts on the other side without direct IP reachability.

The main components are SOCKS client and SOCKS Proxy Server.

SOCKS Client works in the layer between Application layer and Transport Layer. SOCKS Proxy Server works in the application layer.

It works in this way:
  • SOCKS client makes connection request and sends the authentication methods supported
  • SOCKS Proxy Server selects the authentication method
  • SOCKS client gets authenticated with server
  • It sends SOCKS CONNECT request for setting up Proxy circuits
  • Relays Application Data
SOCKS protocol is traditionally used for hosts to traverse a firewall from inside to access Servers outside. But it is also used in VPN like scenarious where a client from outside uses SOCKS to communicate to the servers inside the network.

Please go throught this good site which details SOCKS overview, control flow, references - Socks Permeo

Wednesday, December 27, 2006

HTTP CONNECT

HTTP Connect is used for proxying HTTPS traffic. It tells the proxy that it should not interfere with the traffic, but merely forward the data to the destination. The proxy does not interfere with the HTTPS traffic as it would violate the SSL/TLS end-to-end security.

So proxy does not verify that the traffic being spoken is HTTPS itself. This introduces vulnerability that someone can take advantage of:

More details can be obtained at:
Hypertext Transfer Protocol -- HTTP/1.1
Tunneling TCP based protocols through Web proxy servers
HTTP proxy default configurations allow arbitrary TCP connections

I just got interested in this as I saw in some code that allows another protocol traffic through Proxy by using HTTP CONNECT. So I was wondering why Proxy is not looking for HTTPS headers in the packets. But this explains my query.

Wednesday, December 20, 2006

Client authentication - SSL Handshake

Client authentication is an optional step in SSL Handshake.

If client authentication is requested, then after verifying Server certificate, Client sends "Client Certificate" along with the encrypted pre-master secret ( encrypted using public key from Server Certificate).

One more info is send by client along with this request. Client encrypts a "data" which is known to both Client and Server using Client's private key. When Server receives the request it can validate the public key of client by decrypting this.

Then Server proceeds further by authenticating the Client Certificate. This is done as follows:
1. validity (expiration date) of client certificate is checked.
2. Is the issuing authority of the certificate is a trusted CA by Server. If not.., Server checks whether any CA in the certificate chain of the client certificate is among the trusted CA of server.
3. Then it validates the integrity of the certificate. This is done by hashing the Certificate Message and comparing it with the hash obtained by decrypting the digital signature by CA's public key. Both should be same.

The Client is now authenticated. Now it can check for the resources which client is authorised to access by checking the ACL ( access control lists).

Tuesday, December 19, 2006

SSL - Secure Sockets Layer

As a part of study, wanted to dig into one protocol which uses Certificates for hanshake. Selected SSL. SSL works above transport layer. Protocols like HTTPS uses HTTP over SSL for secure communications. VPNs like OpenVPN also uses SSL as the underlying protocol.

SSL uses
stage 1. Assymetric encrption for intial handshake - authentication and privacy
stage 2. and later moves to faster symmetric encryption for further communication using the Master Key generated during the first stage.

Brief Idea on how the protocol works is:
1. Client sends HELLO to Server ( and details like Cipher suites, session data etc)
2. Server sends back ACK ( Session specific data and Cipher Suites and SERVER CERTIFICATE)

3. Now Client verifies the Server Certificate... Only if it is ok the client proceeds further.

4. Now client sends data encrypted by Server's PUBLIC Key. Client sends the pre-master secret key to the Server.

5. Now the mystery part ( Its still a mystery to me). Client and Server uses the pre-master secret to generate a master secret. Using Master Secret Client and Server generates Session Keys...

6. Now Client sends an encrypted message to Server saying that hanshake is completed. Server also sends a similar message to the client..

7. Now on all data between client and server is encrypted by the session keys..

In the default mode, only Server is authenticated. But Client side certification can also be given. In this case, client will also send its certificate in the step 4 mentioned and Server verifies it.

Assymetric algorithms used are : RSA, Diffie Hellman
Symmetric Ciphers: Triple DES, RC4, RC2, DES

Monday, December 18, 2006

Contents of a Digital Certificate

I was trying to study what all info a digital certificate contains.. I decided to look at the site I freqeuently visit for buying movie tickets - Sathyam Cinemas.

The Certificate shows it was issued by Verisign. It is issued to "tickets.sathyamcinemas.com. But the name of their site is "thecinema.in". So it gives some warnings to the user.



I went to look at the contents. It says in detail - Issuer, Issued to, Validity Period, Algorithm used etc etc. Also we can see that the "Public Key" of Sathyam Cinemas is send along with the Certificate.



Further Details:



The certificate chain shown here. Who is the signing authority of the certificate can be seen here



The digital certificate will contain the digital certificate. It is the encrypted hashed value of the message. It is encrypted using Issuing Authority's private key.


Saturday, December 16, 2006

Usage of Digital signature

I would like to refine the "case example" i said in previous post.

There are cases where the full privacy of message is important that we have to fully encrypt the message.

In some other scenarious the importance will be on several other factors. say;
1. Authentication
2. Non-repudiation
3. Integrity

Authentication: When Anoop sends a message to Biju. Biju should be able to verify that it is send by Anoop. He can do that by decrypting with Anoop's public key.

Non-repudiation: Nobody has Anoop's private key. So there will be no chance that anybody else will use Anoop's private key. So Anoop cannot deny that he has not send the message.

Integrity: The integrity of the message has to be validated. If somebody alters the message in between, the recepient should be able to detect it.
This is done by using digital signature: what it does is -> The sender will take the message contents, and will hash the message. This message will be encrypted by issuing authority's private key. The encrypted hash message is called digital signature.
On Receiving side: The recepient will take the message and hash it. Also he will take the encrypted hash and decrypt it with issuing authority's public key. The two hashes obtained can be compared and if same the message is ok for "integrity"

!!!
Disclaimer: Hi.., my readers. Better will be to read wikipedia. I am still learning the concepts!

Friday, December 15, 2006

Public key cryptography

Usually we close our doors with a key and then we can open that back only with the same key...

In Public key cryptography there are two keys - key1 and key2. If we close with key1, then we can open only with key2. And if we close with key2, we can open with only key1. Nice assymetry!

One key we dont disclose and keep it as secret - its Private key as name denotes, other key we can give to Public, and hence named Public key..

Some examples where i can use:
case1: say i want to send a mail to biju and i want only Biju to read that mail. So i can encrypt with Biju's public key and send. Only Biju will be able to decrypt the message (with his privatekey).

case2: in another case, i want to send a message, but i want Biju to be sure that its me who has send this message. Then i can encrypt with my private key. Biju will be able to properly decrypt that only(with my Public key).

So Biju and me are happy!

Monday, December 04, 2006

Hubs, Bridges and Routers

Hubs or Repeaters, are devices which are used to extend a single LAN. It acts like an amplifier. Whatever noise and signals arrives at, it amplifies and forwards to the rest of nodes. It just extends the network.

Bridges, can be used to connect two LANs together to make it a single LAN. The most important point of a Bridge is that it separates collision domain ( in case of Ethernet). Collisions occur when two hosts talk at the same time. But two hosts separated by a Bridge can talk at the same time, as Bridge separates the "electric part".

Routers, connects multiple LANs together. Routers acts as the boundary for broadcast domain. A broadcast should reach all machines in the LAN, but not beyond. Routers thus significantly increases bandwidth.

A Hub or Repeater, is a physical layer device.
A Bridge is a data link layer (L2) device.
A Router is a network layer (L3) device.

About Me

My photo
Predictably Unpredicatble, lazy, careless, sincere, honest, caring, Trouble maker, emotional, likeable