Posted by arlene

Server Authentication

The client first checks whether the server’s digital certificate is valid for the date of the transaction: the certificate could have expired. Next the server checks whether the certification authority that issued the digital certificate associated with the server is a trusted authority. Usually the client will have a list of trusted authorities and will consult these in order to carry out this validation.

Man-in-the-middle attacks

SSL is potentially susceptible to an attack known as the man-in-the-middle attack. Here an intruder interposes another computer or program between the client and the server. The rogue computer or program engages in a handshake with the client computer and develops a rogue master secret and hence two rogue session keys. These keys are then used to encrypt and decrypt information which should be travelling from the client to the real server; this information can then be read by an intruder.

The next step is to validate the digital signature of the certificate’s issuer. The key which is used for this is found in the details of certificate issuers stored on the client. If this process succeeds then the client can have a high confidence that the server certificate is valid.

The next step is to check that the domain name in the server’s certificate matches the domain name of the server. This is done to ensure that a man-in-the-middle attack has not taken place. Once this step is complete the client can be authorised (this is an optional step).

SSL Server Client Authentication

If client authentication is required the client sends the server a digital certificate and a signed piece of digital data to identify itself. The digest of the data is then encrypted with the private key which is associated with the public key in the client’s digital certificate. This acts as a digital signature. The server then authenticates the client in a number of steps.

The first step is to check that the user’s public key validates the signature that has been sent. The next step is to check that today’s date lies within the client certificate’s time period. The third step is to check that the issuer of the digital certificate is a trusted issuer; in order to do this the server will carry out the same processes that the client carries out when authenticating the server certificate, which includes checking that the certificate issuer’s public key validates the issuer’s digital signature found on its own digital certificate.

An optional step is to check that the certificate is listed by a computer known as a directory server. This directory server keeps track of the resources and users of a distributed system. If the organisation that owns the client has revoked the certificate then the directory server will inform the server which is trying to authenticate the client and the server will not authorise the transaction between the client and itself.

Finally, the server checks that the client is authorised to carry out the transaction that it is attempting to make. If so, the transaction takes place. This transaction uses symmetric key cryptography with parameters such as keys generated by the initial handshake.

This, then, is SSL. Like most practical transmission schemes it uses public key cryptography to establish the cryptographic parameters of the data transfer — the keys used and the algorithms employed — and then employs symmetric key encryption and decryption for the bulk transfer of data.

Possibly related posts: (automatically generated)
SSL Server (Secure Sockets Layer) continue…

• Using Information in the Digital Certificate to Prevent Interception Attacks
• Web Servers and System Hardening
• Dedicated Server with Canadian Web Hosting
• Internet Security, Public Key Encryption and Digital Certificates
• Java Database, J2EE Framework
• Setting Up Your PC as a Web
• Network Sniffers Do Not See All Packets
• Taking BOOTP One Step Further: DHCP
• Public Key Renewal
• Primary, Secondary, and Caching-Only Name Servers