!!! Overview
Following the [ClientKeyExchange] both sides now know the 48 byte (256 bit) [Premaster Secret] 

Now the [user-agent] and Server can generate the [Master Secret] independently as [Per the specification|RFC 2246] by using:
%%prettify 
{{{
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)
}}} /%

Where The [Premaster Secret] is the value from the [User-agent] sent earlier. The [Master Secret] is simply a concatenation of:
* [Premaster Secret] - is the value from the [User-agent] sent in the [ClientKeyExchange]
* "master secret" - ASCII Text
* [ClientHello].random - The random value sent in the [ClientHello]
* [ServerHello].random - The random value sent in the [ServerHello]
* [PRF] -  The [Pseudorandom function] that is defined the specification for [TLS 1.0]. 

The [TLS] [Pseudorandom function] combines the data we give it by using the [keyed-Hash Message Authentication Code] ([HMAC]) versions of both [MD5] and [SHA-1] [hash Functions]. Half of the input is sent to each hash function. This is clever because it is quite resistant to attack, even in the face of [Cryptographically Weak] [hash Functions] for [MD5] and [SHA-1]. This process can feedback on itself and iterate forever to generate as many bytes as we need.

!! [Cryptographically Weak]
There have been several [Exploits] against [SSL]-[TLS] and often they are a result of [Cryptographically Weak] [Pseudorandom generators] functions.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [summarizing-pki-certificate-validation|http://..../|target='_blank'] - based on information obtained 2013-04-10