How to overcome Asymmetric routing in ASA

Introduction

This document provides the basic procedures for identifying, understanding, and mitigating asymmetric routing issues in networks that are protected by the Cisco Adaptive Security Appliance (ASA).

The ASA protects the network by denying traffic unless it can inspect both sides of the flow. To allow the ASA to continue maintaining the security of the network, the correct and ideal solution for asymmetric routing is to resolve the problem that causes the asymmetry elsewhere in the network. However, this document is designed to help identify the problem and provide workarounds until the asymmetry can be fixed.

The term asymmetric routing refers to a packet or connection flow that takes different paths through the network in the forward and reverse directions. For example, a packet may leave the internal network destined for the Internet through ASA1, but the server's response to that packet may return from the Internet and reach the network through ASA2.

Because the ASA keeps track of the active connections passing through the firewall, packets that arrive and that are not part of an existing connection or explicitly permitted by an access list will be dropped when asymmetric routing occurs. In the example from the previous paragraph, the first packet leaving for the Internet through ASA1 will cause ASA1 to build an entry in its connection table. Once this entry is built, all return packets from the Internet that are specific to this connection will be allowed through until the connection is removed from the table. Since ASA2 never saw the 1st packet, no connection is built and thus it is not expecting the response packet from the Internet, which causes the packet to be dropped without an explicit rule to allow it. The following sections in this document will provide alternatives to prevent these packets from being dropped by the ASA.

Examples

Example A - Normal Flow

In order to understand what asymmetric routing looks like from a  diagnostic point of view, it is important to first understand how a  typical packet flow will look. Consider the following simple topology:

When the client wants to send HTTP traffic to the web server at www.cisco.com, it will start a TCP connection by sending its first packet to its default gateway, which is the ASA. The ASA will then route the packet out to the Internet so that it can eventually reach the web server. When the web server receives the request, it will send its response back toward the client, which will eventually arrive at the ASA. Since, having seen the initial request, the ASA knows about this connection, it will allow the response through and forward it back to the client.

Using the packet capture feature of the ASA, it is easy to see that the routing in this topology is symmetric. In the example below, packet #1 arrives on the inside interface of the ASA and leaves on the outside interface of the ASA. Likewise, the response packet, packet #2, returns on the outside interface and is forwarded on through the inside interface. Seeing bidirectional communication on both of the ASA's interfaces is a good sign that everything is working as expected.

ASA inside capture:

1: 11:21:22.385172 802.1Q vlan#301 P0 192.168.1.1.39035 > 198.133.219.25.80: S 1714606600:1714606600(0) win 5840 <mss 1460,sackOK,timestamp 2359218074 0,nop,wscale 7>
2: 11:21:22.461661 802.1Q vlan#301 P0 198.133.219.25.80 > 192.168.1.1.39035: S 830304317:830304317(0) ack 1714606601 win 16384 <mss 1380>

ASA outside capture:

1: 11:21:22.385706 802.1Q vlan#10 P0 192.168.1.1.39035 > 198.133.219.25.80: S 3731327602:3731327602(0) win 5840 <mss 1380,sackOK,timestamp 2359218074 0,nop,wscale 7>
2: 11:21:22.461615 802.1Q vlan#10 P0 198.133.219.25.80 > 192.168.1.1.39035: S 3873337058:3873337058(0) ack 3731327603 win 16384 <mss 1380>

Example B - Multiple Internet Paths

One common example of the asymmetric routing problem occurs when a network has more than one path to the Internet. Depending on the way routing is configured at the network edge or by the ISP, the initial packet may leave through one path but the response returns through a different path as shown in the example below.

ASA inside capture:

1: 11:31:18.914945 802.1Q vlan#301 P0 192.168.1.1.58458 > 198.133.219.25.80: S 2331481362:2331481362(0) win 5840 <mss 1460,sackOK,timestamp 2359730964 0,nop,wscale 7>

2: 11:31:18.991678 802.1Q vlan#301 P0 192.168.1.1.58458 > 198.133.219.25.80: . ack 712296789 win 5840

ASA outside capture:

1: 11:31:18.915434 802.1Q vlan#10 P0 192.168.1.1.58458 > 198.133.219.25.80: S 126872520:126872520(0) win 5840 <mss 1380,sackOK,timestamp 2359730964 0,nop,wscale 7>

Client capture:

10:45:58.734881 IP 192.168.1.1.58458 > 198.133.219.25.80: S 2331481362:2331481362(0) win 5840 <mss 1460,sackOK,timestamp 2359730964 0,nop,wscale 7>
10:45:51.787530 IP 198.133.219.25.80 > 192.168.1.1.58458: S 712296788:712296788(0) ack 126872521 win 16384 <mss 1380>

In this example, the client sends packet #1 to its default gateway, which is the ASA. It is routed through the Internet where it reaches the web server. When the web server responds, routing takes the reply back through the Internet where it arrives on RouterA, who forwards it to RouterB, who sends it directly to the client. Note that because the ASA randomizes the TCP sequence and acknowledgement numbers by default, the server will respond with a SYN ACK packet that has an ACK value of 126872521 (the andomized initial sequence number  from the SYN packet + 1). Because the sequence and acknowledgement numbers are now out of sync, the client will not be able to establish the connection because the client expects the ACK value to be 2331481363.

Example C - Active/Active Failover

Another issue with asymmetric routing can arise when 2 ASAs are configured in Active/Active failover mode.

In this example, ASA1 and ASA2 are connected together in an Active/Active failover mode. There are 2 contexts configured on each unit, ContextA and ContextB. ContextA is active on ASA1 and standby on ASA2, while ContextB is active on ASA2 and standby on ASA1.

When a packet leaves the client destined for www.cisco.com, it arrives at its default gateway of the inside interface of ContextA. ContextA then forwards it on toward the Internet where it reaches the server. Then, the server sends its reply back toward the client. When the response arrives at the Router, it is routed to the outside interface of ContextB, rather than ContextA where the original request came from. Because ContextB never saw the initial request and does not have an existing entry its connection table, the packet is dropped and thus the client is not able to establish a connection with the server. Packet captures on the firewall contexts will clearly illustrate the asymmetry, while the client will simply see no response from the server.

ContextA inside capture:

1: 12:10:44.671657 802.1Q vlan#301 P0 192.168.1.1.40400 > 198.133.219.25.80: S 518915629:518915629(0) win 5840 <mss 1460,sackOK,timestamp 2361776640 0,nop,wscale 7>

2: 12:10:44.671657 802.1Q vlan#301 P0 192.168.1.1.40400 > 198.133.219.25.80: S 518915629:518915629(0) win 5840 <mss 1460,sackOK,timestamp 2361776640 0,nop,wscale 7>

ContextA outside capture:

1: 12:10:44.672145 802.1Q vlan#10 P0 192.168.1.1.40400 > 198.133.219.25.80: S 654525205:654525205(0) win 5840 <mss 1380,sackOK,timestamp 2361776640 0,nop,wscale 7>

2: 12:10:44.672145 802.1Q vlan#10 P0 192.168.1.1.40400 > 198.133.219.25.80: S 654525205:654525205(0) win 5840 <mss 1380,sackOK,timestamp 2361776640 0,nop,wscale 7>

ContextB outside capture:

1: 12:10:44.747931 802.1Q vlan#10 P0 198.133.219.25.80 > 192.168.1.1.40400: S 807750905:807750905(0) ack 654525206 win 16384 <mss 1380>

2: 12:10:44.747931 802.1Q vlan#10 P0 198.133.219.25.80 > 
192.168.1.1.40400: S 807750905:807750905(0) ack 654525206 win 16384 
<mss 1380>

Client capture:

11:25:18.201065 IP 192.168.1.1.40400 > 198.133.219.25.80: S 518915629:518915629(0) win 5840 <mss 1460,sackOK,timestamp 2361776640 0,nop,wscale 7>
11:25:18.201065 IP 192.168.1.1.40400 > 198.133.219.25.80: S 518915629:518915629(0) win 5840 <mss 1460,sackOK,timestamp 2361776640 0,nop,wscale 7>

Diagnosing/Troubleshooting

Packet Captures

Packet captures on the ASA can help easily identify asymmetric routing issues. For example, if you see only one-way traffic (i.e. only client to server traffic), asymmetric routing may be present.

It is important to setup the captures on the ASA to be both bidirectional (i.e. client to server, and server to client) and simultaneous on both sides of the firewall (i.e. both the inside and outside interfaces). For more information on using the ASA's packet capture utility, please see the following document:

https://supportforums.cisco.com/docs/DOC-1222

Syslogs

Syslogs are another useful indication of asymmetric routing. For example, if asymmetric routing exists and the ASA only sees one side of a given connection, a successful connection will never be established and thus many packets will be denied for this reason. In this example, the ASA will log the following message at the informational level:

%ASA-6-106015: Deny TCP (no connection) from 198.133.219.25/80 to 192.168.1.1/40400 flags SYN ACK on interface outside

Mitigation

The following sections outline the available mitigation techniques when the ASA drops packets due to asymmetric routing.

Routing configuration

One of the best, and perhaps most obvious, solutions is to simply fix the routing configuration in the packet's path so that the ASA sees both sides of the connection. In Example B above, RouterA's routing table should send all packets destined for the client to the ASA's outside interface, rather than sending them to RouterB.

Unfortunately, this solution is not always available to network administrators. In some cases, the asymmetry could be caused by devices outside the administrator's control, such as routers managed by an ISP or 3rd party vendor. When this occurs, it is still usually best to contact the responsible organization and work with them to resolve the issue, but the remaining mitigation techniques on the ASA may also be used.

ASR Groups

For situations similar to Example C above, ASA's that are configured for Active/Active Stateful Failover can put their interfaces into ASR groups:

ASA/ContextA(config)# interface Vlan 101

ASA/ContextA(config-if)# nameif outside

ASA/ContextA(config-if)# asr-group 1

ASA/ContextB(config)# interface Vlan201

ASA/ContextB(config-if)# nameif outside

ASA/ContextB(config-if)# asr-group 1

When an interface that is not in an ASR group receives a packet that it does not have an established connection for, it will normally drop it. However, when an interface is in an ASR group, the ASA checks the connection information for all other interfaces in the same group. If the ASA finds another context that has connection information that would match the received packet, the Layer 2 header information is rewritten and the packet is redirected to the appropriate context for processing.

TCP State Bypass

Specifically for TCP-based connections, disabling stateful TCP checks can help mitigate asymmetric routing. When TCP state checks are disabled, the ASA can allow packets in a TCP connection even if the ASA didn't see the entire TCP 3-way handshake. This feature is called TCP State Bypass (introduced in ASA 8.2).

ASA(config)# access-list tcp_bypass extended permit tcp 192.168.1.0 255.255.255.0 any
ASA(config)# class-map tcp_bypass
ASA(config-cmap)# match access-list tcp_bypass
ASA(config-cmap)# policy-map tcp_bypass_policy
ASA(config-pmap)# class tcp_bypass
ASA(config-pmap-c)# set connection advanced-options tcp-state-bypass
ASA(config-pmap-c)# set connection timeout idle 0:10:00
ASA(config-pmap-c)# service-policy tcp_bypass_policy inside

For ASA's running software versions prior to 8.2, similar functionality can be enabled using the 'norandomseq nailed' option at the end of a static statement. For more information on this configuration, see the following document:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/s8.html#wp1414075

Please note that using TCP State Bypass (or the 'nailed' option) will also disable all TCP-based security checks and application inspection. Also, until the fix for enhancement CSCtk84429 is implemented, it is recommended that when TCP State Bypass is enabled an explicitly lower idle timeout is configured to prevent the ASA from reaching its resource limit in high connection environments. This is because the ASA no longer removes a TCP connection from its table based on a TCP FIN teardown (since TCP state checking no longer occurs). As a result, the ASA will have to wait until the global idle timer expires (1 hour by default) before the connection is removed.

Summary

The ASA protects the network by blocking traffic flows unless it is able to inspect the entire (both sides) of the connection. Using tools such as packet captures and syslogs, the ASA can also be a useful troubleshooting tool in identifying asymmetric routing problems. Although the ASA keeps the network secure by blocking this traffic, the above workarounds can be used to allow traffic through the firewall until the problem can be solved permanently.

How to configure Cisco Router with IOS Firewall Functionality – CBAC

For a low budget firewall functionality, a Cisco router with the proper IOS version can work as a network firewall providing stateful protocol inspection using the Context-Based Access Control (CBAC) feature. Many people use normal Access Control Lists on Cisco routers for traffic filtering and protection. However, a normal ACL is just a static packet filtering mechanism and nothing else. With a CBAC configuration, the router acts like a firewall. That is, it inspects protocols and sessions and keeps a state of the connection in memory. This means that an outbound packet (from inside the network to the outside) is inspected and a connection state of the session is kept in memory. The reply packet which belongs to the original outbound connection is allowed to pass through the router/firewall and reach the internal system which originated the connection. This stateful functionality is achieved by the IOS Firewall CBAC mechanism by opening temporary holes on an Access List in order to allow the reply packets.
A normal ACL checks traffic up to the transport layer. CBAC on the other hand inspects traffic up to the application layer to learn about the state of the session and to apply firewall filtering on the specific application. The protocols supported by CBAC for inspection are the following:
CUSeeMe Protocol, ftp, h323, http, rcmd, realaudio, rpc, smtp, sqlnet, streamworks, tcp, tftp, udp, vdolive. CBAC helps to protect also against DoS attacks such as SYN-floods or fragmentation attacks.
CBAC is applied either inbound or outbound on a specific router interface. CBAC applied “Inbound” on an interface inspects traffic entering the interface and CBAC applied “Outbound” on an interface inspects traffic exiting the interface. CBAC cooperates with an ACL applied on the same interface in order to provide the firewall stateful functionality that we described above. Lets see a simple example below.

In the figure above, assume that there is an inbound ACL applied on S0 on the router. The ACL is configured to block Telnet traffic initiated from the outside. Assume also that there is a CBAC rule applied “outbound” on S0. An internal user (User1) initiates a Telnet session from inside to outside. When the connection request for User1′s Telnet session passes through the firewall, CBAC inspects the Telnet traffic when exits interface S0 and creates a temporary opening in the inbound access list at S0 to permit returning Telnet traffic for User1′s Telnet session. (If the same access list is applied to both S0 and S1, the same opening would appear at both interfaces.)
Important Note: CBAC which inspects outbound traffic from an interface, will create temporary openings on the Access List which is applied Inbound on the interface. This is required to allow the return packets to pass through the ACL.
Let us see a configuration example below to get a better picture.
Configuration Example:
Refer to the diagram below for our configuration example:

We have a border Cisco router connecting the internal LAN 192.168.1.0/24 to the Internet. We have a static public IP address 50.50.50.1 on interface Serial0/0. Also, we have a DMZ segment (interface FE0/0) hosting a DMZ Web Server 10.1.1.1. We want to allow access from Internet towards the Web Server only. We use static NAT to hide the Web server private address behind our public address. Also, we use PAT on interface S0/0 for all outbound communication from the internal LAN towards the internet.
Lets see a snapshot of the configuration below:
! Create the outbound CBAC inspection rules
ip inspect name CBAC-IN-OUT tcp
ip inspect name CBAC-IN-OUT ftp
ip inspect name CBAC-IN-OUT h323
ip inspect name CBAC-IN-OUT rcmd
ip inspect name CBAC-IN-OUT http
ip inspect name CBAC-IN-OUT netshow
ip inspect name CBAC-IN-OUT realaudio
ip inspect name CBAC-IN-OUT rtsp
ip inspect name CBAC-IN-OUT sqlnet
ip inspect name CBAC-IN-OUT streamworks
ip inspect name CBAC-IN-OUT tftp
ip inspect name CBAC-IN-OUT udp
ip inspect name CBAC-IN-OUT vdolive
! Create the inbound CBAC to inspect inbound HTTP
ip inspect name CBAC-OUT-IN http
! DMZ interface
interface FastEthernet0/0
ip address 10.1.1.254 255.255.255.0
ip nat inside
full-duplex
no cdp enable
!
! Internal LAN interface
interface FastEthernet0/1
ip address 192.168.1.254 255.255.255.0
ip nat inside
full-duplex
no cdp enable
!
! External Internet Interface
! Notice that we apply an inbound ACL and CBAC rules for both in and out inspection
interface Serial0/0
description CONNECTED TO INTERNET
bandwidth 1024
ip address 50.50.50.1 255.255.255.252
ip access-group FIREWALL in
ip nat outside
ip inspect CBAC-OUT-IN in
ip inspect CBAC-IN-OUT out
ip nat inside source list 122 interface Serial0/0 overload
ip nat inside source static tcp 10.1.1.1 80 50.50.50.1 80 extendable no-alias
ip classless
ip route 0.0.0.0 0.0.0.0 50.50.50.2
! This ACL will be used by the CBAC out rule to open temporary holes for return traffic
ip access-list extended FIREWALL
permit icmp any any echo-reply
permit tcp any host 50.50.50.1 eq 80
deny   ip any any log
access-list 122 permit ip 192.168.1.0 0.0.0.255 any

Similar examples that are usefull:
https://supportforums.cisco.com/document/12249406/cbac-context-based-access-control-configuration-example
http://packetlife.net/blog/2009/mar/10/ios-context-based-access-control-cbac/

EXPLORING HTTP AND PKI

This blog article is an attempt to present the upper layers of OSI reference model from the perspective of network studies. The three upper layers of OSI reference model – Session, Presentation and Application are also sometimes combined into One as Application Layer in general but some protocols make use of each of this layer in-depth.  Also, these layers are mostly ignored when studying for the network certifications. Understanding of these layers is important as you design your network for the applications running at these layers. In this blog article I will be just writing briefly about the working of HTTP. Also at the end of this article there is a brief description of how public key infrastructure works.

HTTP:

HTTP is a text-based protocol and each line terminates with a Carriage Return – Line Feed (CRLF).

By design HTTP is stateless, but it can use cookies to maintain client state across TCP connections between clients and servers. HTTP 1.1 is the currently widely deployed  and it is backward compatible with the earlier HTTP 1.0

Some Common HTTP Methods

GET:    Is used to Retrieve the requested URI (Both headers and Body)

HEAD:     Is used to Retrieve only the Headers of the requested URI. (Headers Only)

POST:     Is used to send information to the server in html forms.

PUT:     Is used to upload a file to the server

DELETE:     Deletes a URI from a server

URI = Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource

Some of the Common HTTP Return Codes from the Server are listed at the end of this article.

HTTP Connection Persistence

When a Client asks information from the server, it opens a TCP connection to the server. The Client and Server agree on the TCP Connection with a TCP 3 Way Handshake and once the connection is established, the Server sends the requested content to the client on the same TCP Session.

So this is like a 3 step process

1. Open a TCP Connection
2. Complete the HTTP Transaction
3. Close the TCP Connection

I. Open TCP Connection:

Client ———- SYN —————> Server

Client <———SYN/ACK———-Server

Client———– ACK—————> Server

II. Complete the HTMl Transaction

Client (Request) ————– HTTP GET 1.1——————————> Server

Client <————————-HTTP 200 OK—————— (Response) Server

III. Close the TCP Connection

Client —————- RST/FIN——————> Server

IV. Start over From Step-1

For each URL in the HTTP File  and repeat the process until all the content is downloaded

HTTP Persistence:

Webpages may have multiple URLs in the html file, each URL pointing to a different embedded object like images, videos etc.  Each different URL for the embedded files will create a different TCP Connection,  thus the number of TCP connections from each client to the server will increase drastically. To avoid these duplicate TCP Connections, HTTP 1.0 introduced the concept of Persistent Connections. By using Persistent Connections the extra overhead of creating multiple TCP connections is reduced.

Now With HTTP  Persistence The new Flow Looks simpler and only one TCP Connection is open between the Client and the Server to complete all HTTP transactions.

HTTP Persistence is achieved with the keep alive feature which is default ON in HTTP 1.1, but has to be negotiated in HTTP 1.0. The client and server agree of the Connection Keepalive to keep the TCP Connection active until the HTTP transactions are complete.

I. Open TCP Connection:

Client ———- SYN —————> Server

Client <———SYN/ACK———-Server

Client———– ACK—————> Server

II. Complete multiple HTMl Transactions using the Keepalive Features

Client (x.Request) ————– HTTP GET 1.1——————————> Server

Client <————————-HTTP 200 OK—————— (Response) Server

Client (y.Request) ————– HTTP GET 1.1——————————> Server

Client <————————-HTTP 200 OK—————— (Response) Server

Client (z.Request) ————– HTTP GET 1.1——————————> Server

Client <————————-HTTP 200 OK—————— (Response) Server

III. Close the TCP Connection

Client —————- RST/FIN——————> Server

HTTP Pipelining

HTTP 1.1 Supports  Pipelining the HTTP requests, but the implementation is optional and is not implemented by default.

With HTTP Pipelining, the Client can send multiple HTTP Requests for different URLs before getting a response from the Server.

1. Open a TCP Connection
2. Request multiple URLS, without waiting for Response from Server
3. Server Response
4. Close TCP Connection.
5. 
   

Maintaining Client Side State with HTTP Cookies

Since HTTP 1.1 is stateless, the use of cookies enables the client and server to maintain the state of the HTTP Session.

HTTP Cookies are always created by the Server. There are 2 types of cookies which the Servers can create

1. Session Cookies

2. Persistent Cookies

Session Cookies:

Web Browsers Store the cookies only for the life of the Session.

If the Session ends or Web Browser is closed – the Session cookie is deleted.

Session Cookies are useful for keeping track of user information as they browse from page to page on a website.

Persistent Cookies:

Web Browsers store the cookie on the hard disk for the amount of time indicated by the server in the cookie value.

The cookie is not removed even if session ends or web browser is closed.

the cookie only expires when the time to live of the cookie as specified by the server ends.

Cookies are Set by the Server using the “Set-Cookie:” in the header.

If the Cookie is set by the server but the expiration time is not given, then its a Session Cookie.

If the Cookie is set by the server with the expiration time then these are Persistent Cookies.

Example (Session Cookie):

Set-cookie: Session-ID=0123456789

When the client sends a request for a URI, the Server sets the Session Cookie  and responds with the “Set-Cookie:” header set to a unique value to identify the session. The client will then use this value in the subsequent HTTP transactions with the server.

Example (Persistent-Cookie):

Set-Cookie: name=somevalue; expires=DATE;

The server sets the expiry date of the cookie and client stores the cookie in the hard disk for the amount of time specified by the server.  The client uses this cookie in HTTP GET when contacting the server every time.

HTTP Authentication

HTTP 1.1 uses the MD5 Authentication, which is far more superior than the Base64 encoding used in HTTP 1.0

Any password encoded with Base64 can be easily decoded with many online tools available today over internet.

How MD5 works with HTTP 1.1

1. The server challenges the browser with a nonce value.

2. The browser uses this nonce, along with the supplied username and password , as input to a hash algorithm.

3. The browser encrypts login credentials by computing a message digest before sending them over the network.

Note:

1. A nonce is a one-time random number that HTTP 1.1 uses to prevent replay attacks.

2. To generate nonce values, servers normally use the current timestamp in conjunction with its private key (if it has a private key) and the “ETag:” HTTP headers in the client’s requests.

3. A hash function is a function that takes input values and performs a mathematical computation, resulting in a single (smaller) value that is impossible to determine the original values from. These functions are also called one-way hash functions because they are considered impossible to reverse. You can use Message Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA-1) hash algorithms for your web applications to compute public keys from private keys. MD5 provides hashes 128 bits in length, and SHA-1 provides 168-bit hashes.

Moving on to the second part of this blog which gives some brief introduction on how the PKI works.

Public Key Infrastructure (PKI)

PKI deals with keeping the data between clients and servers confidential, maintain data integrity and address authentication when traversing over the public insecure networks like internet. PKI addresses data confidentiality, data integrity and authentication issues. For data confidentiality PKI uses cryptography. Cryptography addresses the issues of keeping data confidential when its traversing over the public networks. Cryptography comes in two forms

1. Secret Key Cryptography

2. Public Key Cryptography

Secret Key Cryptography

1. Both Client and Server each uses their own private  secret key, which they agree upon before any encryption happens ( that is they have to exchange it somehow to agree on)

2. Each uses their own secret key (private) to both encrypt and decrypt the data exchanged.

3. They Keys are either same or one of them is originated by applying some mathematical function to the other key, therefore  this is also called as Symmetric key cryptography and some of the common ones are DES, 3DES, where DES stands for Data Encryption Standard.

With Secret key Cryptography, two forms of ciphers can be used to encrypt the data

1. Stream Ciphers, which enable the network devices to encrypt individual bytes of data stream

2. Block Ciphers, enable network devices to encrypt blocks od data containing many bytes – DES/3DES.

The big challenge with Secret Key Cryptography is to exchange the private keys between client and server over public networks

Public Key Cryptography

One of the big advantages of public key cryptography is that you do not have to exchange the private key for secure communication ( a big challenge in secret key cryptography)

So in Public Key Cryptography, the server generates a pair of keys

1. Private key

2. Public key

The Server keeps the private key secure and keeps it secret and it also makes the public key available to everyone. With these pair of keys in place you can decrypt the information using a public key or a private key. that is information encrypted by private key can be decrypted using the public key and information encrypted using a public key can be decrypted using a private key.

These Private and Public keys are asymmetric which allows to derive the public key from the private key using a hash function, but not the other way, that is you cannot derive the private key using a hash function on the public key.  The common algorithms which run Public key Cryptography are – RSA (Rivest Shamir Adleman) and DSA (Digital Signature Algorithm).

Server A generates a private/public key pair

Server A sends the public key to client C

Client C encrypts a message using Server A’s public key and sends it over to Server A.

Now only Server A can decrypt the message because only it has the private secret key.

The public keys needs to be very large to be really secure since they are distributed to everyone over the pubic insecure networks. To process these large keys both client and server resources have a high utilization so it is not always practical to use this structure. therefor many deployments today use a combination of both Secret key and public key cryptography.

This is a sample of of things can work in an hybrid approach utilizing both secret key and public key approach.

1. Server- “S” generates a pair of private and public keys

2. “S” then sends the public key to client “C”

3. “C” then generates a random number  message and encrypts it using the public key of “S”, and it sends this to “S”.

4. “S” decrypts the message using its private key and uses this random number to generate a Symmetric key for data encryption and decryption.

5. Next all two-way communication between “S” and “C” takes place using this secret symmetric key, which is based on the random number generated by “C”.

Using Certificates

Certificates are used on the servers to guard the identity of the clients and prevent clients from being connected to any malicious server which poses  it self as the legitimate server.

A malicious server on the public insecure network can pose itself as a legitimate server for a resource and generate a its own private and public keys and then distribute the public key to the clients. The clients unaware of this malicious server and believing this to be a legitimate server can connect to it and become a target of confidential information theft.

To prevent this identity theft,  certificates are available to verify the authenticity of the public key owners.

The Certificate Authority (CA) generates a certificate to avoid a possibility of a malicious third party server posing as a real server and clients connecting to it.

1. When the Server generates the Private and Public keys pair, it also generates a Certificate Signing Request (CSR) which contains the public key and other information proving the identity of the originator.

2. The CSR is then sent to the CA manually or via web.

3. The CA verifies the CSR with Registration Authority (RA). If RA verifies and approves the request, then the CA will sign the CSR to vouch for the server that generated the CSR.

4. The CA will then issue a certificate for public use which includes an expiration time of the certificate.

5. The Certificate is then installed on the server.

6. When a client accesses the server, the server sends the certificate to the client, so client can verify the public key actually belongs to the server.

Below is the process which client “C” and server “S” use with the CA signed certificates to verify the authenticity of the legitimate server and to exchange the confidential information using symmetric keys

1. “C” downloads the CA-signed certificate from “S”

2. Then “C” runs the same hash function that the CA ran on the certificate contents during the signing process

3. “C” decrypts the CA’s signature using the CA’s public key and compares its hash to that of the CA, if the two hash values have to match.

4. If the two hash values matched, then “C” extracts the public key of “S” from the certificate

5. Now “C” generates a random number and encrypts it with the public key of “S” and sends it over to “S”. “C” also generates the symmetric key at this time.

6. “S” decrypts the random number sent by “C” using its own private key and it also generate a symmetric key.

7. Now that both “C” and “S” have a symmetric key generated, they exchange their confidential information over public insecure networks using the symmetric secret keys.

SSL – Secure Socket Layer

SSL is a PKI protocol that applications like HTTP, SMTP and FTP use for data integrity and data confidentiality. SSL uses Symmetric key encryption to encrypt packets and appends a Message Authentication Code (MAC) to the SSL packet header. MAC helps ensure the data integrity. From the OSI Reference model perspective SSL lives in the Session layer

SSL is further subdivided into two sub-layers

1. SSL handshake layer

2. SSL Record layer

SSL Handshake Layer

SSL Handshake negotiates session information between the client and the Server, the session information contains

1. Shared Secret: Is a random number used to create symmetric keys for encrypting data.

2. Session Identifier: Is used to identify an SSL session

3. Certificates:  Certificates installed by Servers and Clients

4. Cipher Suite:  Uses protocols TLS or SSL. Asymmetric algorithm is used for key exchange and symmetric algorithm is used for data encryption. Also a hash algorithm used for data integrity (MD5 or SHA-1).

SSL Change Cipher Spec Protocol:

This is used by clients and servers during the full handshake to indicate each other to use the negotiated keys for the current session or to resume an idle session.

SSL Record Protocol: Does the data encryption using the shared secret established in handshake process

SSL Alert Protocol: Signals problems with SSL session and terminates the SSL connection.

SSL handshake:

SSL handshake is a four step process to start a new connection and a 3 step process to resume an idle session.

Step-1. Client Sends a Hello to the Server to initiate a Session which contains the SSL version number, random number and supported cipher suites

Step-2. Server Responds with Hello and its server certificate. If the Server certificate does not contain a public key then the Server key Exchange can contain a temporary key for the client to encrypt the master secret.

Step-3. The client now computes the master secret key using its random number and the random number received from the server hello. the client then encrypts the master secret with the Server’s public key located in the certificate. If there is not public key in the certificate then client uses the temporary key from server for the encryption. Client sends this back to Server so both parties now have the master  key which they use to derive symmetric key for further data encryption used by the record protocol

Step-4. Both Client and Server now send to each other a Change cipher Spec message and a Finish message. the record protocol from now on performs data encryption using the symmetric keys.

Below are Some common HTTP Return codes from the Server which indicate the status of the client -Server HTTP transaction, like any code returned with 4xx indicates the client error and any starting with 5xx indicate the error on the server side.

Some Common HTTP Return Codes

1xx :     Informational

100:     Continue

101:    Switching Protocols

2xx:     Successful

200:    OK

201:    Created

202:    Accepted

203:    Non-Authoritative Information

204:    No Content

205:    Reset Content

206:    Partial Content

3xx:    Redirection

300:    Multiple Choices

301:    Moved Permanently

302:    Found

303:    See Other

304:    Not Modified

305:    Use Proxy

4xx:    Client Error

400:    Bad Request

401:    Unauthorized

402:    Payment Required

403:    Forbidden

404:    Not Found

405:    Method Not Allowed

406:    Not Acceptable

407:    Proxy Authentication Required

408:    Request Timeout

409:    Conflict

410:    Gone

411:    Length Required

412:    Precondition Failed

413:    Request Entity Too Large

414:    Request URI Too Long

415:    Unsupported Media Type

416:    Requested Range Not Satisfiable

417:    Expectation Failed

5xx:    Server Error

500:    Internal Server Error

501:    Not Implemented

502:    Bad gateway

503:     Service Unavailable

504:    Gateway Timeout

505:    HTTP Version Not Supported