Secure Sockets Layer, or SSL (pronounced as separate letters), is a protocol which is used to communicate over the Internet in a secure fashion. It was replaced by Transport Layer Security, or TLS, in 1999. Today, the term SSL is still widely used, although in practice SSL has been fully replaced by TLS.
So lets start to understand how TLS work.
The Main porpuse of TLS is to encrypt and secure our data.
There are 2 options to encrypt the data. using “symmetric encryption” or “asymmetric encryption”
Symmetric Encryption :
Symmetric encryption incorporates only one key for encryption as well as decryption. Symmetric encryption is a simple technique and its working very fast.
Algorithms Employed : RC4, AES, DES, 3DES, QUAD
Asymmetric Encryption :
Asymmetric Encryption consists of two cryptographic keys. These keys are regarded as Public Key and Private Key.
Because of encryption and decryption by two separate keys and the process of comparing them make it a tad slow procedure.
Algorithms Employed: RSA, Diffie-Hellman, ECC, El Gamal, DSA
You understand what is asymmetric encryption and symmetric encryption. Let’s make sure you do…
Asymmetric encryption When I send information to a remote server I encrypt the information with his public key and he decrypt using his private key
Symmetric encryption – that we using only one password to encrypt and decrypt
I recommend to watch this video before continue with this POST.
You must have questions now like…
Where do certificates come into the picture and why?
Where does he get the public key?
when the server sends me back encrypted data how do I decrypt it when I do not have the private key?
So let’s answer the first 2 questions…
The Certificate is there to ensure us that we get the right public key and that the site that we create session with him is trusted.
The certificate is signed by the Issuing Certificate authority, and this it what guarantees the keys.
Now when someone wants your public keys, you send them the certificate, they verify the signature on the certificate, and if it verifies, then they can trust your keys.
To illustrate we will look at a typical web browser and web server connection using SSL. (https).
This connection is used on the Internet to send email in Gmail etc and when doing online banking,shopping etc.
Browser connects to server Using SSL (https)
Server Responds with Server Certificate containing the public key of the web server.
Browser verifies the certificate by checking the signature of the CA. To do this the CA certificate needs to be in the browser’s trusted store
Browser uses this Public Key to agree a session key with the server.
Web Browser and server encrypt data over the connection using the session key.
To Understand Certificate and the Digital Signature i recommend to watch this video.
So, for now, we understand that public key is coming from the certificate and the certificate come from the server when we create TLS session with him.
So now let’s answer the 3 questions…
Let me tell you little secret TLS uses both asymmetric encryption and symmetric encryption. Its called hybrid Encryption.
I will explain.!
First, let’s look at this.
In this section the client needs to create a symmetric key using these protocols RSA, Diffie-Hellman to create a session key. the client then encrypts this symmetric session key using the servers public key and sends it to the server. the server decrypts it using its private key ( which is only known to the server) and both the client and the server use this session key for the rest of the communication.
A maximum transmission unit (MTU)is the largest packet or frame size, specified in octets (eight-bit bytes) that can be sent in a packet- or frame-based network such as the internet. The internet’s transmission control protocol (TCP) uses the MTU to determine the maximum size of each packet in any transmission. MTU is usually associated with the Ethernet protocol, where a 1500-byte packet is the largest allowed in it (and hence over most of the internet).
One of the most common problems related to MTU is that sometimes higher-level protocols may create packets larger than a particular link supports, and you’ll need to make adjustments to make it work.
To get around this issue, IPv4 allows fragmentation which divides the datagram into pieces. Each piece is small enough to pass over the single link that it is being fragmented for, using the MTU parameter configured for that interface. This fragmentation process takes place at the IP layer (OSI layer 3) and marks the packets it fragments as such. This ensures the IP layer of the destination host knows it should reassemble the packets into the original datagram.
Fragmentation is sometimes not supported by applications, and is something we should avoid if possible. The best way to avoid fragmentation is to adjust the maximum segment size or TCP MSS so the segment will adjust its size before reaching the data link layer.
Before we look at TCP MSS, it helps to understand the build of the “unit” that’s being sent over the internet.
As mentioned, the common value of MTU in the internet is 1500 bytes.
As you can see in the figure above, the MTU is built from payload (also referred as data) and the TCP and the IP header, 20 bytes each. The total value of the IP and the TCP header is 40 bytes and mandatory for each packet, which leaves us 1460 bytes for our data.
Now, imagine that we are using the GRE protocol in our network, encapsulating the original packet and adding 24 bytes for the GRE header.
The total size of this kind of packet will be 1524 bytes, exceeding the 1500 bytes MTU value. The “data” size in this packet is 1460, but we can and should decrease it in order to make sure the total size will be 1500 bytes or less. And this is where TCP MSS comes into the picture.
TCP MSS, the maximum segment size, is a parameter of the options field of the TCP header that specifies the largest amount of data, specified in bytes, that a computer or communications device can receive in a single TCP segment. It does not include the TCP header or the IP header. This value will dictate the maximum size of the “data” part of the packet. In the following case for the GRE tunnel, we will set the tcp mss value to be 1436 or lower, while the default size is 1460.
The MSS announcement (often mistakenly called a negotiation) is sent during the three-way handshake by both sides, saying: “I can accept TCP segments up to size x”. The size (x) may be larger or smaller than the default. The MSS can be used completely independently in each direction of data flow.
Since the end device will not always know about high level protocols that will be added to this packet along the way, like GRE packets for example, it won’t usually adjust the TCP MSS value. As a result the network devices have the option to rewrite the value of TCP MSS packets that are processed through them. For example, in a Cisco Router the command “ip tcp mss-adjust 1436” in the interface level will rewrite the value of the TCP MSS of any SYN packet that will go via this interface.
Virtual Private Networks (VPNs) provides a secure tunnel across a public (and thus, insecure) network. This provides a mechanism for organizations to connect users and offices together, without the high costs of dedicated leased lines. VPNs are most often used across the Internet, the world’s largest public network, providing users with access to email, documents, printers, and systems as if they were actually at their central office. VPNs are generally used for two purposes:
• Client VPNs – connect home or “roaming” users to an office.
• Site-to-Site VPNs – connect remote offices to a main office.
What is IPSEC?
IPSEC, short for IP Security, is a suite of protocols, standards, and algorithms to secure traffic over an untrusted network, such as the Internet. IPSEC is supported on both Cisco IOS devices and PIX Firewalls. IPSEC provides three core services:
• Confidentiality – prevents the theft of data, using encryption.
• Integrity – ensures that data is not tampered or altered, using a hashing algorithm. • Authentication – confirms the identity of the host sending data, using pre-shared keys or a Certificate Authority (CA).
• Anti-replay – prevents duplication of encrypted packets, by assigning a unique sequencing number.
The IPSEC Protocols:
IPSEC uses one of two protocol headers for securing data:
• Authentication Header (AH)
• Encapsulation Security Payload (ESP)
Authentication Header (AH), or IP protocol 51, provides no confidentiality of data. It does not encrypt any data at all. However, AH provides both authentication and integrity services. Because AH does not perform encryption, it is a quicker standard than ESP.
AH uses a hash algorithm to compute a hash value on both the payload and header of a packet, ensuring integrity of the packet. However, this causes a very specific problem. AH will not work through a NATed device.
NAT changes the IP header of a packet during translation, but the hash value is not changed. Thus, the receiving device will believe the packet has been altered in transit, and reject the packet.
Encapsulation Security Payload (ESP), or IP protocol 50, performs confidentiality, authentication, and integrity services. Thus, ESP does perform encryption, and is inherently more secure than AH. ESP introduces both an additional header and trailer to a packet. ESP also uses a hash algorithm for data integrity. However, the hash does not include the IP header of the packet, and thus ESP will (usually) work through a NATed device. ESP and AH can be used separately, or used in conjunction with each other.
Consider what happens when you run IPSec with GRE. The end station sends a data packet, the GRE adds additional header information (as it encapsulates the original data packet into the GRE packet) and IPSec adds additional header information. So if the end station sends a large packet (say for example 1500 which is the max size for Ethernet) and you add the header information for GRE and the header information for IPSec, there is now a packet much larger than 1500 and it must be fragmented by routers along the path. Also consider that some applications send the TCP packet with the Do Not Fragment bit set so that the router can not fragment the packet but the packet is too large to go accross the link. So the application does not work.
Transport vs. Tunnel Modes
Each IPSEC protocol (AH or ESP) can operate in one of two modes:
• Transport mode – Original IP headers are left intact. Used when securing communication from one device to another single device.
– IPsec header is inserted into the IP packet
– No new packet is created
– Works well in networks where increasing a packet’s size could cause an issue
– Frequently used for remote-access VPNs
• Tunnel mode – the entire original packet is hashed and/or encrypted, including both the payload and any original headers. A temporary IP header is applied to the packet during transit. Used to tunnel traffic from one site to another.
– Entire IP packet is encrypted and becomes the data component of a new (and larger) IP packet.
– Frequently used in an IPsec site-to-site VPN
Security Associations (SA)
IPSEC VPN peers establish a Security Association (SA), a “connection” or “policy” between the two endpoints of the VPN tunnel. An SA is a one-way virtual tunnel between the VPN peers. Thus, for full communication to occur, two SA’s must be established, one for each direction
Before the SA can be established, several parameters must be negotiated between VPN peers, and keys must be both created and exchanged. The Internet Key Exchange (IKE) protocol controls this negotiation process, on UDP port 500. IKE Policy Sets are created to negotiate several parameters, including:
• The encryption algorithm (such as DES, 3DES, or AES)
• The hashing algorithm (such as MD5 or SHA-1)
• The authentication method (such as shared keys or RSA signatures)
• The Diffie-Hellman (D-H) group for creating and sharing keys
• The SA Lifetime, measured in seconds or in kilobytes sen
How to Set Up an SA:
– Sometimes referred to as “manual keying” – You configure on each node:
• Participating nodes (I.e. traffic selectors)
• AH and/or ESP [tunnel or transport]
• Cryptographic algorithm and key
• Automatically – Using IKE (Internet Key Exchange)
There are two phases to this negotiation process:
IKE Phase 1 establishes the initial tunnel (referred to as the IKE or ISAKMP SA). Peers are authenticated, encryption and hashing algorithms are negotiated, and keys are exchanged based on the IKE Policy Sets. Two modes can be used for Phase 1 negotiation:
• Main Mode – slower, but more secure
• Aggressive Mode – faster, but less secure
IKE Phase 2 establishes the IPSEC tunnel (IPSEC SA), which details the AH or ESP parameters for securing data. These parameters are contained in an IPSEC Transform Set. IKE Phase 1 negotiates parameters for the tunnel (key exchange) itself, while IKE Phase 2 negotiates parameters for the data traversing that tunnel.
VLAN Trunk Protocol (VTP) reduces administration in a switched network. When you configure a new VLAN on one VTP server, the VLAN is distributed through all switches in the domain. This reduces the need to configure the same VLAN everywhere. VTP is a Cisco-proprietary protocol that is available on most of the Cisco Catalyst series products.
You can configure a switch to operate in any one of these VTP modes:
Server—In VTP server mode, you can create, modify, and delete VLANs and specify other configuration parameters, such as VTP version and VTP pruning, for the entire VTP domain. VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize their VLAN configuration with other switches based on advertisements received over trunk links. VTP server is the default mode.
Client—VTP clients behave the same way as VTP servers, but you cannot create, change, or delete VLANs on a VTP client.
Transparent—VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements, but transparent switches do forward VTP advertisements that they receive out their trunk ports in VTP Version 2.
Off (configurable only in CatOS switches)—In the three described modes, VTP advertisements are received and transmitted as soon as the switch enters the management domain state. In the VTP off mode, switches behave the same as in VTP transparent mode with the exception that VTP advertisements are not forwarded.
VTP Configuration Guidelines
VTP defaults for the Cisco Catalyst switch:
VTP domain name: None
VTP mode: Server mode
VTP pruning: Enabled or disabled (model specific)
VTP password: Null
VTP version: Version 2
1. A new switch can automatically become part of a domain once it receives an advertisement from a server
2. A VTP client can overwrite a VTP server database if the client has a higher revision number
3. A domain name cannot be removed after it is assigned; it can only be reassigned
Important! When you connect new switch to the network make sure that his revision number is set 0. if the new switch revision number is greater than the server revision number all the VTP clients switch will update their VLAN database from the new switch. it can cause a wipe of all your VLANs in your network!
So how can I reset the new switch revision number to zero?
it’s easy just change the VTP MODE in the new switch from server to a transpernt mode and back to client mode.
What is VTP Pruning?
VTP pruning is disabled by default in Cisco switches. VTP pruning helps to send broadcasts only to those trunk links that actually needs the information. For example, if switch A does not have a port configured for VLAN 7, and broadcast is sent throughout VLAN 7, that broadcast or traffic will not pass through the trunk link to switch A
Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.