In SSL, Web Browser is the SSL client
and Web server is the SSL Server. First Client initiates the SSL connection. In
brief the process looks like following.
Prevoius
Next
Home
Step
1: Client sends Hello
message. As I said, client initiates the connection with server by sending
Hello message. Client Hello message contains following information.
|
Field
|
Description
|
|
Version
|
Client sends the highest version of
SSL it supports.
|
|
RandomNumber
|
It is 32byte random number. 4-byte
number that consists of the client’s date and time plus a 28-byte randomly
generated number that will be used with the server random value to generate a
seed from which the encryption keys will be derived.
|
|
SessionID(If any)
|
SessionId is included to enable the client
to resume the previous session.
|
|
CipherSuites
|
List of cipher suites available on the
client.
Example
TLS_RSA_WITH_DES_CBC_SHA, where TLS is
the protocol version, RSA is the algorithm that will be used for the key
exchange, DES_CBC is the encryption algorithm (using a 56-bit key in CBC
mode), and SHA is the hash function.
|
|
CompressionMethods
|
Specifies the compression algoithms
that client support
|
Following is the example of Client Hell
message.
ClientVersion 3.0
ClientRandom[32]
SessionID: None (new session)
Suggested Cipher Suites:
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Suggested Compression Algorithm: NONE
Note:
TLS used version number
as 3.1
Step
2: Once server receives ClientHello message, Server respond
with ServerHello message. ServerHello message includes following information.
|
Field
|
Description
|
|
Version
|
Server sends the highest number of the
version that both client and server supportd.
|
|
RandomNumber
|
It is 32byte random number. 4-byte
number that consists of the server date and time plus a 28-byte randomly
generated number that will be used with the client random value to generate a
seed from which the encryption keys will be derived.
|
|
SessionId
|
Identifies specific SSL session. It
can have three valid values.
1.
New Session Id: When for a new request (or) when
client don’t want to resume the session, then a new Id is generated.
2. Resumed
Session Id : Client
sends already existing session id, if it wants to resume the session.
3. Null: this is a new session, but the server
is not willing to resume it at a later time so no ID is returned.
|
|
CipherSuite
|
Server selects the cipher suite that
supported by both client and server.
|
|
CompressionMethod
|
Specifies the compression algorithm to
use.
|
Following is the example of ServerHello
message
Version
3.1
ServerRandom[32]
SessionID:c629767869f0e3ebfe6b0c044acb67a63bdcffb0ef58b1b941820a77
ea7bd608
Use
Cipher Suite:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Compression
Algorithm: NONE
Step
3: Server sends the certificate
Server sends its certificate to client. This
certificate is used to authenticate client, that the server is trusted one. The
server certificate contains server public key. By using this public key client
encrypts the secret key and send it to the server.
If you want see a certificate, open
https connection in your browser. On address bar you used to see padlock
symbol, click on that.
Step
4: Server hello done,
and waiting for the response from client.
Step
5: Client generates a
secret key, by using the random values generated by both client and server.
Once key is generated, client encrypts this secret key with server public key,
send it to the server.
Step
6: Client Change Cipher Spec.
This message notifies the server that all messages that follow the Client
Finished message will be encrypted using the keys and algorithms just
negotiated.
Step
7: Server Change Cipher Spec
Message. This message notifies the client that the server will begin encrypting
messages with the keys just negotiated.
Step
8: After sending
“change Cipher Spec” messages, both the systems send finished messages. Once
both client and server able to receive finished messages successfully, then the
negotiation process is finished. Both client and server are ready for secure
communication.
Optional
Cases
1. In some cases, server decides, client
authentication is required. In those scenarios, Server asks CertificateRequest
for the client. Sever sends this request only after sending servers certificate
to the client.
How
to resume previous session
If client wants to resume previous
session, then it sends ClientHello message to server, by specifying the
previous sessionId. Server responds with ServerHello message agreeing to this
sessionID (If server don’t want to resume the session, then it creates new
sessionId and send it in ServerHello message). After this both client and
server exchange ChangeCipherSpec and Finished messages.
X509
Certificates
In cryptography, X.509 is an ITU
Telecommunication Standardization Sector (ITU-T) standard for a public key
infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509
specifies, amongst other things, standard formats for public key certificates, certificate
revocation lists, attribute certificates, and a certification path validation
algorithm.
The structure of an X.509 v3 digital
certificate is as follows:
Certificate
Version
Serial Number
Algorithm ID
Issuer
Validity
Not Before
Not After
Subject
Subject Public
Key Info
Public Key
Algorithm
Subject Public
Key
Issuer Unique
Identifier (optional)
Subject Unique
Identifier (optional)
Extensions
(optional)
...
Certificate
Signature Algorithm
Certificate
Signature
If you want see a certificate, open
https connection in your browser. On address bar you used to see padlock
symbol, click on that.
References
No comments:
Post a Comment