User:Riley.meg/sandbox

Digital Transactions, how can we trust they are secure?
Over the course of the last 20 years people have moved every facet of their lives online. People now do not even blink before sending money using their phones or pushing a button to order a month's supply of laundry detergent, and yet how are the people so sure that their data is secure? The short answer is that all of these interactions handled using secure protocols.

Long Answer
SSL/TLS rely on many underlying technologies in order to provide a secure connection such as X.509 certificates, some method of asymmetric encryption in order confirm that the party they are communicating with is who they say they are, this scheme is also used to generate the keys that will be used to encrypt the data stream during the lifetime of the connection. We will discuss below the various components and entities that play a role in ensuring a stable and secure connection for users to go about their daily lives without so much as a second thought to whether or not their information is safe.

SSL/TLS
The initial protocol to secure our daily interactions on the internet was developed in the mid-90s by Netscape,known as Secure socket layer this became SSL. Today SSL has been superseded in many cases (but not all) by the more secure and more modern Transport Layer Security or TLS. These protocols reside in the application layer and encrypt the data. There are many different implementations of SSL and TLS however they all have same principles and follow a similar (in broad strokes) process to create the connection with the server.

Once the client and server have agreed to use TLS, they negotiate and create a connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security (these parameters are what is known as a cipher suite more on that below) The steps needed to complete the initial handshake are as follows:
 * 1) The process begins when a client connects to a SSL/TLS-enabled server and requests a secure connection
 * 2) The client then presents the server with a list of cipher suites that it is able to support
 * 3) The server send the client its digital certificate
 * 4) Then the server selects from the list a cipher and hash function that it also supports, it notifies the client of this decision
 * 5) The client may contact the CA that issued the certificate in order to  confirm the validity of the certificate before proceeding. (Checking that the certificate is not expired or revoked.)
 * 6) The client selects a random number and encrypts it using the server's public key and it then sends the result to the server. (This is how the client/server relationship begins to negoiate the session key that will be used to encrypt entirety of the 2 parties communications.)
 * 7) From the random number previously sent to the server, both parties generate a 'master secret' and proceed to negotiate a session key for encryption and decryption of the rest of the session.
 * 8) Client sends a verification message ("Finished") which is encrypted and MACed with the derived keys. The server verifies that the Finished message is proper, and sends its own "Finished" message in response. At that point, both client and server have all the symmetric keys they need, and know that the "handshake" has succeeded. The two, the client and server then begin to trade information, and  complete the transactions led to them starting this process.

Once the handshake has been completed there is no public key or certificate involved in the communications. Going forward both sides (client and serve) will secure all their data using symmetric encryption, for many reasons including that it is less computationally expensive.

Note that this description only encompasses the case where the server must authenticate, there are instances and applications that require a client submit its information for the same form of identity checks that the server is subjected to. The failure of any of the steps in this initial phase leads ultimately to a a failure in the TLS handshake. This failure means that the connection is not created, and the negotiation to create the connection must start again. If handshake is complete the user with be unaware any of this is going on in the background, only in the case of failure is the user notified, that there was was an issue. Some browsers present pop-ups to notify the user, others block the page entirely but either way the user is now operating in an insecure say, they have no assurances that their data is secure.

Cipher Suite
During the initial handshake certain "rules of engagement" are decided upon that, that are used going forward to govern the connection going forward, this information is collectively referred to as a "cipher suite". The contents of a cipher suite include:


 * The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake. (most often a method based on a public key exchange)


 * The bulk encryption algorithm is used to encrypt the message stream.
 * The message authentication code (MAC) algorithm which is used to create the message digest, a cryptographic hash of each block of the message stream

Certificates
Ultimately a certificate is a container for a public key. A certificate provides a basis for authenticating the ownership of a public key by the named subject of the certificate. The certificate contains at a minimum the server name, the trusted certificate authority (CA), and the server’s public encryption key. While there are different kinds of certificate formats, the most widely used format is X.509.

There are many different levels and types of certificates. (root..etc)

Certificate Authorities
A certification authority or CA is an independent third party, who is considered trusted by both sides, that issues digital certificates for use by other parties. CA's are considered vital to many public key infrastructure (PKI).

Some times the signer is either the key's owner (a self-signed certificate) or other users who provide endorsements, these users are chosen in the hopes that the person examining the certificate might know and trust. The major certificate authorities are Symantec, Comodo, and GoDaddy, between these 3 issuers they command the majority's share of the market.

Public Key Infrastructure
While the subject of PKI could fill entire books, here only the basics that needed understand the creation of a secure connection will be discussed.

Vulnerabilities
Despite all the layers of security present through the length of keys and third parties verifiying the server, there still exist vulnerabilities throughout this system and if the security does not evolve effectively either from the business side or the user perspective, data can and will be compromised.

Man in the Middle Attacks
There are many different ways for hackers to compromise a client-server connection, however quite a few of them are variations on the man-in-the-middle attack. As a result the MITM and its variants are often considered to be one of the more dangerous threats to specifically financial transaction. However we know that there are other equally high profile cases where individuals and organizations choose to impersonate legitimate websites. One example is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within reception range of an unsecure Wi-Fi wireless hot spot, can insert themselves and listen as a man-in-the-middle.