Let's now examine the HTP protocol it's used for data transfer between clients and web servers.
This is not a problem because most of the data published on the web is open to the public anyway.
It makes no sense to encrypt during the transmission however some information is confidential.
For example log ins and passwords
to protect this information.
The HTP protocol was introduced to use the HTP channel.
You don't have to install anything on the client computer just a simple web browser is enough
when you type an address into the browser.
Type HGT us instead of the standard HTP by sending such a request to the server you can connect to the
default port number four for three
in response.
It'll send back its certificate it contains among other things the public key of the server.
It also contains information uniquely identifying this server including the address of the computer
it was issued for information about the certification center where it can be used for and for how long
it will be valid.
From this moment on the browser must verify this certificate is correct and valid in order to check
whether someone is not trying to carry out the man in the middle attack.
If everything is correct the TTP as protocol will send to the web server selecting cryptographic protocols
and pseudo random strings of data.
This data will be encrypted before sending with the public key for the server.
The public key is available to everyone but only you know the encrypted data because it's been generated
from your computer.
A person listening to the packets won't be able to read them in order to do that.
The private key that matches the public key is needed only the server with the public key has the private
key.
In this way you're able to transmit confidential data over a known trusted channel.
From this point on only you the browser and the server presents the session key no one else knows your
session key.
You know it because you have generated the server also knows that because it had the private key that
matches the public key used to encrypt the session key
with the session key you no longer need to encrypt data using an asymmetric algorithm.
You can use a symmetric algorithm instead.
There's no need for two kilobyte keys as in the case of for example the RSA if everything on the Internet
was encrypted with the RSA algorithm it would take a simple website at least 20 minutes to load asymmetric
encryption is about an order of magnitude slower than symmetric encryption.
It is not suitable for encryption of large data sets.
The first stage is needed to exchange a symmetric sesshin key which allows us to encrypt data symmetrically
designing web applications.
Developers often boast that their application is secure because it uses a for kilobyte RSA key.
After such a complex key is used to exchange the session key the rest is encrypted with the 56 bit D.S.
key anyway.
The safety of the entire application is the sum of all the individual factors.
You should always look for the weakest link.
If the user ignores the warning about the invalid certificate nothing will protect them against the
man in the middle attack.
In the slide you have an example of such a situation you can see captured secure communications that
didn't need decrypting the attacker didn't need to decrypt anything because everything had been encrypted
with his own key.