SSL and IPSec Technologies

What required for tunnels?
Confidentiality, Integrity, and Authentication
SSL and TLS: primarily used for RA
Secure socket layer
Transport Layer Security
IPsec: primarily used for site to site
On top of TCP, we will have SSL

With symmetrical encryption like RC4, AES, and DES we use the same key for encryption and decryption.

With Asymmetrical encryption, we have a key pair. One key that encrypts and other key that decrypts . Its other way true as well.

How SSL verify the authenticity of a peer in case of asymmetric and verify session key in case of symmetric encryption?

Digital Signature
Messages is hashed with SHA or MD5 algorithm. The hash value can be 128 or 160 bits long. Sender encrypts the hash using sender’s private key. The encrypted hash is known as the digital signature of the sender.

At receiver, we have email message without encryption and digital signature .
To verify if the message is from right source, the receiver uses the sender’s public key to decrypt the signature which will result a Hash say H1.

Also, we generate our own hash from email message received say H2. If H1 = H2, This proves that sender is the right person who has send this message.

In SSL/TLS (Secure Sockets Layer/Transport Layer Security) protocol, the authenticity of a peer is verified differently depending on whether asymmetric or symmetric encryption is used:

1. **Asymmetric Encryption (Public Key Cryptography)**:

   - During the SSL/TLS handshake process, the server presents its digital certificate to the client. The certificate includes the server's public key and is signed by a trusted Certificate Authority (CA).

   - The client verifies the authenticity of the server by checking the digital signature on the server's certificate using the CA's public key, which is pre-installed or obtained through a trusted source.

   - If the digital signature is valid and the certificate has not expired or been revoked, the client can trust the authenticity of the server.

   - Optionally, the server can request the client to provide its own certificate for mutual authentication, in which case the server verifies the client's certificate using a similar process.

2. **Symmetric Encryption**:

   - In symmetric encryption, a shared secret key is used for both encryption and decryption. There is no inherent public-private key pair as in asymmetric encryption.

   - During the SSL/TLS handshake, the client and server negotiate a shared secret key using asymmetric encryption techniques (such as RSA) to securely exchange a session key.

   - Once the session key is established, symmetric encryption (such as AES) is used for encrypting and decrypting the actual data transmitted between the client and server.

   - The authenticity of the session key is ensured during the SSL/TLS handshake, where the client and server use asymmetric encryption to securely exchange and verify the session key. As long as this handshake process is secure and authenticated (as described above), both parties can trust the authenticity and confidentiality of the session key.

In summary, SSL/TLS ensures the authenticity of a peer using asymmetric encryption during the handshake process, while the authenticity of the session key in symmetric encryption is verified during the same handshake process using the exchanged public keys and digital signatures.

How this works with SSL?

Before client and server (ACME) ever communicate, the server will generate a key pair. Server will share it's public key by including it on Digital certificate. To share public key ACME need digital certificate. ACME will request for digital certificate from any CA say Go-daddy which implements on PKI. To issue digital certificate to ACME, Go-daddy will verify ACME’s details and takes ACME’s public key. Go daddy will generate digital certificate for ACME server.

Now anybody can verify this certificate if they have Go-daddy’s public key since Go-daddy has signed this certificate.

Now how SSL authenticate here?
Client  ———client SSL Hello, List of Ciphers ——> Server
Server ——Server SSL Hello, Certificate, Done—> Client

How client believes server digital certificate?
Based on validity date
Whether signed by trusted CA

Next is session keys?
Now we need session key to transmit data back and forth using symmetric encryption.
Client comes up with with one key say keyx, client will encrypt the key with server public key and send it to server . Now server can only de-crypt that key using its own private key. Now both will have same session key.

Client —— Cleint Key Exchange. Change Cipher Spec. (begin to encrypt) —> Server
Server ——Change Cipher Spec (begin to encrypt) —> Client

Results is :
—————> encrypted SSL session <————————

How server authenticate client?
prompting for  username and password
if client have identity certificate or if they both have certificate issued by same CA.

IPsec versions :
1. RA - this use SSL and TLS
2. Site to Site

IKE Phase 1: 
this is kind of control channel
negotiation for session and peer authentication happens here
Hash
Authentication
Group
Lifetime
Encrypt

IKE phase 1 use UDP protocol over port 500

If NAT device is involved in between ASA’s we use NAT -T which use port 4500. Also, we can do tunneling on TCP using port 10000

Once authenticated, both peer can securely communicate with each other.

IKE Phase 2 or IPsec
actual transmit of data will happen here.
Following negotiation will happen in phase 2
Encryption
DH if required once again called as PFS
Lifetime
Hash MAC

Ipsec protocol no: 50

IKEv2 :
works with cisco Anyconnect Client and for site to site as well.
Same functionality. Built-in NAT-T and dead peer detection
Thin Layer
Ikev2 can fall back to Ikev1