Http Strict Transport Security

Published Date: 02 Nov 2017

Abstract

This paper researches and supports the following two (2) propositions:

New initiatives such as incorporating Strict Transport Security into ‘htpp’ may not solve the problem of end user security.

Digital Certificates have been fundamentally compromised by the expansion of the Certificate Authority business worldwide.

The author builds his case by first introducing a brief history of each subject and continues with a study of its functions and applications. In the first topic the evident weaknesses in the HTTP protocol is reviewed together with the use of HTTP Strict Transport Security (HSTS) to protect e-commerce against hackers. Final recommendations will reveal why Strict Transport Security will not solve the problem of end user security.

The second topic describes key security concepts which have been employed in the Information Technology World in an effort to treat the growing concerns about Certificate Authority (CA) business worldwide. The paper formulates the architecture of the Registration Authority, the body that recommends individuals, systems and companies to CA’s requiring certificates, and shows how CAs, like any other business, can be compromised in many ways including weak security and competition. IT analyses how competition can reduce the quality of goods( in this case the certificate) and how fragile CAs and their certificates have become.

Contents

Rational

The Author of this paper constructed a portfolio of research in Information Technology security issues. The two(2) tasks studied are:

New initiatives such as incorporating Strict Transport Security into http may not solve the problem of end user security.

Digital Certificates have been fundamentally compromised by the expansion of the Certificate Authority business worldwide.

INTRODUCTION

Strict Transport Security (STS)

As researched in (Rouse, 2013) HTTP is a series of standards that allow people who use the internet to exchange information between different websites on the World Wide Web; a website tells a browser what protocol should be used to communicate. These standards outline the correct ‘protocol’ for its users and are governed by the International Standards Organization, ISO 2013, who recognized the need for a standard network model. This ensures that the devices and software within a network can only operate within certain criteria so that vendors will create adaptable networks

As the WWW evolved companies began to use this as the main median for e-commerce. E-commerce provided numerous benefits but with every benefit there are cons as in all forms of life weakness were identified and there were those who were wathing to exploit. That accompany. The threats came in the form of hacking. has replaced traditional business. This The Open Systems Interconnection (OSI) as researched in (InetDaemon, 2010) shows that the OSI reference model was released in 1984, which addressed this requirement. The Open Systems Interconnect Model (the OSI Model) is a theoretical model of networking that organizes network functions into seven layers (physical layer, data link layer, network layer, transport layer, session layer, presentation layer and application layer) and specifies the communication interfaces between the OSI Model's layers and the network endpoints utilizing an OSI Model-based protocol suite. HTTP operates at layer seven (7) of the TCP/IP OSI model which the application layer as reviewed and supported in (tech-faq 2013).

Who created HTTP

HTTP was created by Sir Timothy John "Tim" Berners-Lee as reviewed in (Berners-Lee, 2013), a British computer scientist, best known as the inventor of the World Wide Web. He made a proposal for an information management system in March 1989 and he implemented the first successful communication between a Hypertext Transfer Protocol (HTTP) client and server via the Internet.

Some of the most important facts about HTTP was reviewed on (Computer hope, 2013) are:

HTTP commonly utilizes port 80, 8008, or 8080.

HTTP/0.9 was the first version of the HTTP and was introduced in 1991.

HTTP/1.0 is specified in RFC 1945 and introduced in 1996.

HTTP/1.1 is specified in RFC 2616 and officially released in January 1997.

End User Security

One of the core functions of the Internet is use for e-commerce and communication. Since most computer systems communicate with each other, an environment was developed for the presence of rogue elements such as viruses and Trojans. Special precautions were hence required by both the servers transmitting data and users requesting data. Many systems began the implementation of internal virus protection and network edge firewalls.

This resolved the problem with end user and the server security, but it failed to end the ‘man in the middle attack’ and therefore made HTTP vulnerable.

A’ man in the middle attack’ was best described in Microsoft (TechNet, 2011), where an attacker routes all communication between two users (user and Server) through his computer. Whilst this is being done the two end users are ignorant to the fact that their data is being violated.

Weakness of HTTP

HTTP is a protocol that ensures when a client requests information from the server, the version of HTTP operating on the server is compatible with the version of HTTP being used by the requesting client before information is dispatched. There are a number of breaches in security as it is easy to ‘fool’ the serve by imitating a user; by redirecting a user to rogue sites an attacker has full control of that user. This has caused a significant amount of interferences in today’s information technology world. This weakness accounts for a large number of security breaches in the IT world and has caused many websites to strengthen features in HTTP to make it less susceptible to threats.

Another major weakness in HTTP is that username and password are passed over the network in clear text this was reviewed (W3C, 2008). In order to deal with these abnormalities HTTP Strict Transport Security (HSTS) was developed to increase levels of security in websites especially those involved in e-commerce and security.

HTTP Strict Transport Security (HSTS)

HSTS is a policy put in place for sites to communicate via the HTTPS protocol. Strict Transport Security (STS) is implemented as a browser security mechanism. Formally known as HTTP Strict Transport Security, it is a mechanism used in websites where a special header is incorporated into packets and forwarded to a compatible browser. Once this browser receives and accepts, it will only communicate to that site via HTTPS Protocol. One of the newest browsers which use HTTPS is Google Chrome. The following diagram was reviewed on (STS in action, 2013), shows a graphical interpretation of how data is manipulated with and without STS.

Figure Table showing With and without HSTS

HSTS request process diagram

(Department of defence 2013 cited in Defence Signals Directorate, 2013)

HSTS allows all types of websites, to formally advise other sites that they will only communicate with other websites via Hypertext Transfer Protocol Secure (with Secure Socket Layer). STS was created to treat mainly with three categories of threats:

Passive Network Attacker

Active Network attacker

Imperfect web developer

A review in the (Ristic, 2013) Director of the firm Qualys, explained that even though users go to unsecured HTTP sites and get security warnings, most times these warnings are ignored. He stated that 99 per-cent of these cases may not be dangerous but the remaining one per cent can be very dangerous’. With the improvement in HTTPS however, the browser being used will recognise the irregular coding and the connection to the suspected site will be refused.

Hypertext Transfer Protocol Secure

As Reviewed in (ehow, 2013), Netscape Communications Corporation created HTTPS in 1994. Netscape founded another protocol called the Secure Socket Layer (SSL). This deals with the secure aspect of HTTPS, which otherwise is the same as the standard HTTP. In 1999, Netscape handed over the responsibility for the protocol to the Internet Engineering Task Force. The IETF published its definition of HTTPS in the year 2000.

There are two primary differences between an HTTPS and an HTTP connection are:

HTTPS connects on port 443, while HTTP is on port 80

HTTPS encrypts the data sent and received via SSL, while HTTP sends it all as plain text

This was also reviewed and supported in (Anon., 1998-2013)

How HTTPS work:

‘Https’ work to ensure that whatever data is transferred from the client to the server is safe and it cannot be viewed by anyone except the intended end user. The’ S’ in HTTPS defines’ Secure’ also referred to as the Secure Socket Layer (SSL).

Secure Socket Layer

The secure socket layer was developed to ensure that data being sent from a client to a server over the Internet cannot be’ sniffed’ or ‘ciphered’ easily. The objective of these secure services is to ensure that even though data is intercepted, it is only the intended recipient who will be able to interpret the data. There are a series of stages before encrypted data can be transferred; this is commonly referred to as the’ SSL handshake. Although SSL is providing security as reviewed in (goddin, 1998-2013)Researchers have discovered a serious weakness in virtually all websites protected by the secure sockets layer protocol that allows attackers to silently decrypt data that's passing between a webserver and an end-user browser.

An SSL session uses an asymmetric encryption to encrypt privately shared keys. These keys are pair rings with one key being a public key, sent from the servers to the clients and the other one is a private key used to decrypt data sent from the client to the server. Unfortunately, asymmetric encryption includes large overheads and is not feasible for an entire session.

When a client wants to make an HTTPS connection with a server, a request sent to the server creates a digital certificate and sends it to the client. Encapsulated within this certificate is a public key. The client can now create a session key with the server and uses the server public key to encrypt this session key. The server easily decrypts this session with the server’s private key. Data is then encrypted using symmetric inscription. All data transfers will include the encrypted session key.

This has certainly strengthened the confidence to users who wish to perform financial transactions over the Internet and has so made a positive impact in e-commerce.

Companies incorporated HTTPS

There are a number of key companies who had no choice but to implement HTTPS because of the protected nature of the company. Effectively companies had to protect secure data and at the end user, being very reluctant to transfer data over browsers using the HTTP protocol. Some of the companies that incorporated HTTPS successful according to (netcraft, 2013) :

Paypal,

www.noisebridge.net

riseup.net

paycheckrecords.com

market.android.com

lastpass.com

www.lastpass.com

entropia.de

stripe.com

Recommendation: STS will not solve the problem of end user security

STS is a step in the right direction to protecting secure transactions this was reviewed in (Constantin, 2012). Internet security has become a major issue in e-commerce. The Internet and Engineering Task Force (IETF) is responsible Internet. A HSTS specification standard document was prepared and submitted. A draft of this document was prepared by some of the most successful websites engineers in the world names like Jeff Hodges from PayPal, Collin Jackson from Carnegie Mellon University and Adam Barth from Google.

Unfortunately due to lack of company’s knowledge of STS most website doesn’t support it.

According to SSL Pulse (timothy, 2012) , a project that monitors HTTPS implementations on the world's most visited websites, only around 1,700 out of the top 180,000 HTTPS-enabled websites support HSTS.

Another battle against STS security is Hackers. Novice hackers are finding it easy to attack website because of the numerous supply of online hacking tools, security is being severely tested.

To date, there are three major threats to HTTPS which are: Passive Network Attacker, Active Network Attacker, and Imperfect Web Developer. The most dangerous, however is an active network hacker.

There are an increasing amount of reports of tools being used successfully against SSL. One such tool is known as the ‘BEAST’, created by Thai Duong and Juliano Rizzo, which has proven that exploits do exist in browsers and that infiltration is possible. The attacker can steal packets, run algorithms and decrypt and obtain authentication tokens such as the HTTP cookie.

The ‘BEAST’ is just one of the many tools that have proved successful against HTTPS. There are many other attacks which have also proven to be successful such as:

Chosen-plain text attacks

SSLstrip

At a Black hat DC convention this year Moxie Marlinspike presented some new SSL attack techniques. This was reviewed by (Chapple, 2000-2013) one of Moxie attack was to simply removing the SSL from the user's connection! This attack uses a tool called SSLstrip that changes all of the user's requests to HTTP connections, which are passed to the man-in-the-middle attacker in the clear text.

There are many other tools that have been used and are available online. HTTPS in my opinion will not reach the level of comfort required by most individuals. On a daily basis hundreds of secure sites continuously get broken into.

Due to impersonation and user neglect of not accepting HTTPS, request STS is compromised. This has major repercussions with Rogue companies and user impersonation as companies genuinely requesting Digital certificates from Certificate Authorities are negatively affected. In addition is the development of ‘third party’ Certificate Authorities issuing Digital certificated for half the price without sufficient background checks on companies?

Introduction

The paper givesThe following re concise guidelines on Certificate Authorities (CA). It describes the hierarchy of certificates authority functions. The hierarchy is a parent child relationship the parent being the Root CA and the child being the Issuing CA. It gives detail steps how a company or user requesting a digital certificate will apply to a Registration Authority (RA) the functions of the RA. Information Technology has been growing at significant rates and with the demands for Digital certificates CA,s has been expanding at a significant rates. This expansions has major draw-backs with the expansion of CA, s. CA’s competing against each other offering Digital Certificates half the price of what it’s worth. CA’s are not performing comprehensive background check on companies requesting Digital certificates. Certificates are being issued to rogue elements; Rogue CA’s have been formed, calculated attacks on CA’s with proper security. The paper gives it recommendation on the effects of this rapid growth in CA’s business.

Certificate Authority

Certificate Authority (CA) is an organisation that issues digital certificates to websites. Companies/users wishing to conduct e-commerce transaction over the Internet usually is provided with critical information from CA’s about the legitimacy of the website. This is provided in the form of a digital certificate issued from a recognised CA. Companies also wishing to do secure transactions over the internet in an encrypted format is issued a Digital certificate.

Certification Authority Hierarchy Structure

CA’s structure usually supports a hierarchy trust model. At the top of the Hierarchy there is a Root CA which is always at level one, at all other levels there will be issuing CA’s. In many Hierarchy CA’ has a Registration Authority which is an individual authority that does comprehensive background checks on companies requesting Digital Certificates. As researched in (Microsoft TechNet, 2013) Windows 2000 public key infrastructure supports a hierarchical CA trust model, called the certification hierarchy.

Figure Certification Hierarchies

(Microsoft TechNet, 2013)

The Root Certificate Authority is a Authority that has a self-signed Digital Certificate. This Certificate usually identifies the company. As researched in (CA, 2013) provides a listing of all trusted Root CA after 2007.

The registration authority (RA) is an authority which mediates between the user and a CA. When a user requires a Digital Certificate it applies to the RA. The RA will then authenticate this person. The same procedure occurs with the computer system where the RA validates the system and provides a specific address’ such as a static IP address. A major problems with the RA is that some CA’s operate as an RA. In this situation there is no separation of bodies and no checking or authorising body.

Currently Microsoft has over one thousand member Certificate Authorities registered with the Billion Dollar Company. All members’ Certificate Authority has to go through strict guidelines and technical requirement to become a member of the Microsoft Certificate Authority. Some of the general and technical requirements are as follows:

Digital Certificate

A Digital certificate is an electronic equivalent to someone’s credit card. It works in a very similar manner for example when someone wants to make a purchase with their credit card the credit card owner has to validate that that he is the owner of the Credit card. A website wishing to send encrypted data applies for a digital certificate from a Certificate Authority (CA). The CA will forward an encrypted Digital certificate with the website public key attached to it. This is not the only information attached to the encrypted Digital Certificate; there is the special identification of the CA as well as the ‘public key’. As reviewed in (Austin, 2013) a digital certificate is a pair of files on your computer that you can use to create the digital equivalent of handwritten signatures and sealed envelopes. Two unique keys can open these files a public key and a private key.

The website can now use the CA’s public key to decrypt the Digital Certificate. Once this certificate has been decrypted, the website can now authenticate the CA. All the other credentials provided by the CA can now be verified.

Once this information is verified, the website can now use the public key provided by the CA. The public key is used to encrypt the data and send to the relevant e-commerce website. One of the most common types of digital certificates as reviewed in (Nadalin, 2006) is the X.509. X.505 (Nadalin, 2006) just like any software there are different versions. The most current version is version 3.

Figure SSL Key ring pair

Hash Function

Before certificates can be transmitted, it needs to be unique and so has to be transformed in a manner where it will be impossible to be outputted into another similar certificate. An algorithm is used to convert this data into this unique format. It must be mentioned that in the past, twenty eight bit (28B) algorithm was used but hackers were easily able to reveal the algorithm (‘birthday attack’). A more sophisticated algorithm was therefore developed using more bits to increase the difficulty of decryption. A one hundred and twenty eight bit (128b) algorithm was created which is called ‘hashing’.

A popular hashing algorithm as reviewed in (Friedl's, 2005) is Message Digest Algorithm-5 (MD5) and MD2 but because of the complexity of hackers and the availability of data on attacking hash function, both MD2 and MD5 have already been compromised.

MD5 has been compromised by experts who recreated certificates mirroring websites MD5 certificate so that an unsuspecting individual will be redirected to the rogue websites. Newer versions of hashing functions have been developed Known as Secure Hash Algorithm-1 (SHA-1).

Figure How MD5 works

(Unixwiz.net Tech Tips, cited in Fidel’s, 2005)

SHA-1 is recognised by most CA’s as a secure cryptographic hash algorithm. SHA-1 was created by the NSA using functions from MD2 and MD5. SHA-1 uses a one hundred and sixty bit (160B) output called a message digest .Diagram 2 depicts the operation of SHA-1 This information was reviewed in Federal Information

Processing Standards (Publication 180-1, 2013) and (Burrows, 1995 )

Figure SHA -1

http://www.itl.nist.gov/fipspubs/fip180-1.gif

(Secure Hash Standard 1995 cited in Burrows, 2013)

The main component of a digital Certificate which is issued by a CA includes:

A unique identification of the User

Signature CA, issuing the certificate so it will be known

Type of Digital keys is being used (asymmetric)

Contains serial numbers

Issuer’s name

Version

Validation period

Any extensions

How Certificate works

An SSL handshake is first initiated.

Client browser requests communication with the server.

The server will send the Server certificate to authenticate itself.

Within the client browser, resides a database of all certificates or key ring pairs.

The browser reconciles whether the certificate issued is authenticate or does not exist.

Once the certificate is authorised, the client uses the server public key available in the certificate to encrypt and decrypt data from that specific server.

Data is decrypted by the server when private key is received.

Certificate Authority Compromised

There are many instances where the CA’s has been compromised. Four (4) distinct attacks which threaten the very existence of CA’s business throughout the world have been identified. These are explained as follows.

Impersonation: This describes when someone or the system itself impersonates a client ‘fools’ the Registration Authority. The RA will hence authorise the CA to issue a certificate with a public key to a rogue person or system. This person/system is now capable of conducting illegal business transactions on behalf of the genuine entity.

Registration Authority Compromised: An attacker is able to break into the RA defences and forward the approved request to the CA for certificates.

CA System Compromise: The attacker gets access to the CA’s system and is now capable of issuing certificates, revoking certificates, editing logs; basically capable of having administrative privileges. This is a huge threat faced by Certificate Authortiies worldwide with grave and far reaching repercussions.

CA Signing Key Compromise: An attacker gains a copy of a Certificate Authority signing key. Imagine using someone's credit card and being able to sign as the owner! This issue is significant where CA’s around the world are using less sophisticated machinery and software that generate weak algorithms. Hackers prey on CA’s of this nature.

As indicated earlier in paragraph 5.0, it is the Registration Authority that will research the companies/individual requesting the certificate. Once approved, guidance is given to the Certificate Authorities to issue as appropriate. However, with most Registration authorities, the Certificate Authority is located in many countries and proves to be a major drawback in CA business worldwide.

Another downfall in CAs is competition for business. Like any other business, profitable sales are necessary to keep companies afloat. Most companies will reduce prices to attract more customers and this reduction has a significant negative impact on the quality. The average cost of a Certificate from Verisigns is estimated at twenty four hundred US (2,400 USD) with a lease that is valid for three (3) years and has a one hundred and twenty eight bit (128B) inscription certificate

‘GoDaddy’ is an example of a company that competes with Verisigns by reducing its prices whilst sacrificing the quality of Certificates issued. The limited research on companies or individuals requesting certificates introduces much vulnerability to the security in Information Technology.

CAs have neglected key areas in the IT world such as Internet security for one’s own company. Hacker’s thrive on these inadequacies by connecting to LAN’s or insecure wireless access points. Once connected, they will run hacking tools that are geared to extract weak administrative authentications.

Certificate Authority Exploited

One of the earliest Certificates Authority was Verisigns (Now Semantic). Others authority include Microsoft, Geo Soft, Thawte, and RapidSSL.

In December 2012, Google, one of the largest browsers in the world, detected and blocked a suspected certificate. Investigations were conducted and it was found that the certificate was produced by an intermediate Certificate Authority. The rogue certificate was linked to TURKTRUST a Turkish Certificate Authority.

‘Intermediate’ CA certificates carry the full authority of the CA and so can be used to create a certificate for any website they wish to impersonate.

Recommendation Digital Certificates have been fundamentally compromised

I agree with the conclusion that Digital certificates have been fundamentally compromised by the expansion of the CA’s business worldwide. Certificate Authorities are Businesses and subject to economic competition. As a result price competition leading to questionable quality contributes to significant risks in security. As reviewed and supported in ( (Prins, 2011) the company DigiNotar B.V. provides digital certificate services to a number of CA,’s on August 29th 2011 DigiNotar B.V provided rogue certificates to a number of users in Iran to google.com. The rogue certificates impersonation of Google had one thing in mind for the purpose of stealing credentials.

Illegitimate individuals/ companies apply to the legitimate CA’s for Digital Certificates. Unfortunately certificates are issued without comprehensive background checks or research and impersonation has become rampant. Data becomes easily extracted from e-commerce companies and an overall suspicion of even reputable CAs is sadly developing. As reviewed in ( Hewlett-Packard Development Company, 2013) legitimate organizations who have had their organizational certificate issued from a hacked Root CA find themselves immediately (once the CA is invalidated globally) with an invalid SSL certificate, which causes added confusion, downtime.

Certificate Authorities were designed for heightened security but in many cases it can be seen that it has accomplished just the opposite. Well-known CAs have employed weak security within their own IT infrastructure, making it very easy for hackers to penetrate their defences and access sensitive data such as the Administrator password. As reviewed in (Soulskill, 2011) four CA’s attacked one of which is DigiNotar the attack had totally compromised the CA’s infrastructure. The CA was unable to survive after its certificates were cancelled globally. All attached browser vendrs had their certificates revoked from DigiNotar. Diginotar ha to eventually close down.