{"id":3859,"date":"2015-07-13T08:25:32","date_gmt":"2015-07-13T13:25:32","guid":{"rendered":"http:\/\/www.poweradmin.com\/blog\/?p=3859"},"modified":"2015-07-14T09:23:00","modified_gmt":"2015-07-14T14:23:00","slug":"ssl-and-beyond-part-1-history-and-development","status":"publish","type":"post","link":"https:\/\/www.poweradmin.com\/blog\/ssl-and-beyond-part-1-history-and-development\/","title":{"rendered":"SSL and Beyond, Part 1: History, and Development"},"content":{"rendered":"

\"SSLOnline communications and e-commerce are fast replacing more traditional methods. So there\u2019s a real need for data to be moved around through secure channels. That\u2019s where protocols like the Secure Sockets Layer or SSL have a part to play.
\n<\/span><\/p>\n

This series will consider the evolution of SSL, its current deployment, and options for the future. We\u2019ll start by looking at its origins and development.<\/span><\/p>\n

Security? What\u2019s The Panic, Anyway?<\/b><\/span><\/h2>\n

While legislation like the U.S. government\u2019s Health Insurance Portability and Accountability Act<\/a> (HIPAA<\/a>) can provide a level of protection to sensitive data and give prescriptions for the way it should be handled, it\u2019s tough to legislate for data in transit \u2013 or to protect the computer systems on which it\u2019s kept.<\/span><\/p>\n

Eavesdropping, impersonation, and wiretapping are just some of the methods used by unscrupulous operators to gain access to information in transit. To reduce this risk, one approach is to scramble or encrypt data as it moves between its source and its recipients.<\/span><\/p>\n

On today\u2019s internet, the SSL family is the preferred communications protocol for secure transactions.<\/span><\/p>\n

A Protocol?<\/b><\/span><\/h2>\n

In computing terms, a protocol is simply a set of rules determining the format and transmission of data \u2013 though the rules themselves may not be simple.<\/span><\/p>\n

An API or application programming interface known as SNP (Secure Network Programming) was developed in 1993 to address the lack of strong security measures in existing network applications. This API employed a secure transport layer that was similar to Berkeley sockets.<\/span><\/p>\n

There\u2019s SSL\u2026<\/b><\/span><\/h2>\n

The Secure Sockets Layer protocol was intended to provide a safe platform-and-operating-system-independent path for encrypted data that passes between clients and servers.<\/span><\/p>\n

The project was initiated by Netscape in 1994, at a time when the company was looking to address growing concerns over unsecured communications on the internet. Specifically, the firm was looking to ensure secure links between its own Netscape Navigator browser, and the web servers it would connect to.<\/span><\/p>\n

SSL was designed to use powerful encryption algorithms that would also meet the Advanced Encryption Standard (AES), which had emerged as the yardstick for encrypted communications at that time. SSL can secure the transmission of any data that moves via the Transfer Control Protocol (TCP).<\/span><\/p>\n

As well as encryption, SSL ensures secure communications by the use of authenticated digital certificates. A digital certificate is like a set of official credentials; it establishes the holder\u2019s identity and ensures that they are who they claim to be.<\/span><\/p>\n

Under SSL, a user establishes that the website they are about to exchange data with is on a trusted server once its certificate is verified. Verification of identity helps users to avoid fraudulent websites.<\/span><\/p>\n

Its Various Versions\u2026<\/b><\/span><\/h2>\n

SSL version 1.0 never saw the light of public release.<\/span><\/p>\n

February of 1995 saw the arrival of SSL 2.0. As with any software evolution process<\/a><\/span>, this release contained a number of kinks and some security flaws.<\/span><\/p>\n

In 1996, SSL 3.0 was released. This version improved on the previous ones by adding support for the authentication of digital certificates, and by beefing up its encryption algorithms with SHA-1 based ciphers. It set the standard for internet communications security for several years.<\/span><\/p>\n

Then There\u2019s TLS\u2026<\/b><\/span><\/h2>\n

SSL 3.0 had some weaknesses in the process used to derive its encryption keys, which created security vulnerabilities.<\/span><\/p>\n

The Internet Engineering Task Force (IETF) took over official ownership of the SSL standard, and set up a process to eliminate the weaknesses of previous versions.<\/span><\/p>\n

An upgrade was issued in January 1999, along with a new designation: Transport Layer Security (or TLS). Like SSL, it used symmetric cryptography to scramble elements of network communication above the Transport Layer, and ensured the reliability of messages via authentication codes using public and private keys.<\/span><\/p>\n

TLS 1.0 (sometimes designated as SSL 3.1), while similar in many respects to SSL 3.0, was only backwards-compatible with it. In certain circumstances, a TLS 1.0 connection could be downgraded to SSL 3.0.<\/span><\/p>\n

In April 2006, TLS 1.1 arrived with greater protection from Cipher Block Chaining (CBC) attacks, alterations in the way padding errors were handled, and other slight modifications.<\/span><\/p>\n

TLS 1.2 emerged in August 2008. It was based on the TLS 1.1 model, but with a major overhaul of the encryption algorithms and digital signatures process, and with extended support for authenticated encryption ciphers.<\/span><\/p>\n

Securing Connections<\/b><\/span><\/h2>\n

Secure Sockets Layer combines three aspects, to ensure the security of connections:<\/span><\/p>\n

\u2022 Encryption of data to ensure the privacy of connections<\/span><\/p>\n

\u2022 Authentication of identity through digital certificates<\/span><\/p>\n

\u2022 Checking the integrity of messages to ensure that a secure connection is maintained throughout<\/span><\/p>\n

Laying the Groundwork<\/b><\/span><\/h2>\n

For a user or client system\/application wishing to use SSL to connect securely to a web-based system, the web server must have a valid digital certificate. The server administrator can get one from a recognized Certification Authority (or CA). A certificate allows the web server to identify itself to the client so that communication can proceed.<\/span><\/p>\n

Note that it isn\u2019t essential for the client to have a digital certificate on his\/her machine to connect to a secure server. That\u2019s why it\u2019s possible to check your web-based email account from different machines without having to port a certificate around.<\/span><\/p>\n

Most modern web browsers inherently support the SSL protocol, and this eliminates the need to configure SSL connections on the client\u2019s side of the transaction. Web servers do have to be configured, typically to allow several sites to store their digital certificates on the system. Administrators should be able to identify and verify each application hosted on the server. Users should be able to readily differentiate between each application.<\/span><\/p>\n

The SSL protocol has been known to slow down connections, as encryption keys and other data are exchanged at the start of a communications session. So network administrators are also advised to consider installing SSL accelerators (dedicated PCI cards) to their servers.<\/span><\/p>\n

Encryption of Data: Public and Symmetric Keys<\/b><\/span><\/h2>\n

In private\/public key encryption, the private key is kept secret, while the public one can be distributed to all intended recipients of a communication. Key pairs are built up from prime numbers. The longer a key is, the more difficult it would be for a (malicious) user without access to the key pair to decrypt an encoded message.<\/span><\/p>\n

If you\u2019re a key holder, anyone in the network can send you an encrypted message, which you\u2019ll be able to decrypt. Using a private key, you can confirm that an encrypted message originated from you \u2013 one that can only be decrypted by the associated public key. To get details of your recipient\u2019s public key, you need him\/her to send you a signed message (which won\u2019t be confidential), containing their public key and a valid digital certificate<\/a>.<\/span><\/p>\n

Data encrypted using a combination of a public and private key is deemed to be asymmetric. Information can be scrambled by one key, but it can only be decoded by the other key pair. The functions of the keys can be switched, with one key pair decrypting what the other key has encrypted.<\/span><\/p>\n

Practical difficulties can arise. The other key pair is needed to perform decryption \u2013 and you can\u2019t encrypt and decrypt with the same key.<\/span><\/p>\n

Symmetric keys are used in processes where the same key is used to decrypt and encrypt data. The algorithms are much faster than for private\/public keys, but are inherently insecure. It\u2019s essential to transmit the key to your recipient by putting it inside a message that has been scrambled asymmetrically.<\/span><\/p>\n

For each communication, the symmetric key must be selected randomly. So, if one message is intercepted, the next one will contain a different key.<\/span><\/p>\n

Digital Certificates, and Signatures<\/b><\/span><\/h2>\n

To set up an SSL transaction, an application must have a digital certificate<\/a><\/span> assigned to it by a Certification Authority. The certificate will contain a unique public encryption key, and be sealed by a protective hash \u2013 which is a random number generated by a hash function from a message.<\/span><\/p>\n

Private keys are not contained within a certificate to preserve their security. With the public key, a certificate can send an encrypted transmission to its owner or verify a message signed by its author.<\/span><\/p>\n

The digital certificates used in SSL confirm to web browsers the identity of the website they\u2019re visiting. If a user wishes to transmit sensitive or confidential data to a web server, their browser will first assess the validity of the site\u2019s certificate, before attempting to establish a secure connection. The encryption required to do this will itself refer to the digital certificate to confirm the authenticity of the recipient.<\/span><\/p>\n

Before being issued with a certificate, its owner must first provide basic information about themselves, such as their name, email address, and web address. The certificate will come with conditions of use and a period of validity, and specify a Distinguished Name, which is made up of the certificate owner\u2019s email or website address, together with the certificate ID of the person who has certified or signed all of this information.<\/span><\/p>\n

A user\u2019s web browser or application will have typically pre-loaded an index of root certificates from trusted Certification Authorities (CAs). The CA itself should retain a list of all certificates signed under its authority, and those which have been revoked.<\/span><\/p>\n

Signed certificates can\u2019t be modified, so a certificate with a signature on it is secure, and vice versa. It\u2019s possible to sign a certificate using itself; it\u2019s known as self-signed. This is the case with all root CA certificates.<\/span><\/p>\n

Maintaining Message Integrity: Handshakes and Such<\/b><\/span><\/h2>\n

The Secure Sockets Layer protocol incorporates four layers:<\/span><\/p>\n

1. The Record Layer Protocol<\/b><\/span><\/h3>\n

This is a formatting stage prior to transmission. A header is generated for each message, along with a hash at the end, which derives from a specific Message Authentication Code (MAC). The SSL protocol dictates that any message following the header cannot exceed 16,384 bytes in length.<\/span><\/p>\n

2. The ChangeCipherSpec Protocol<\/b><\/span><\/h3>\n

This layer of the operation consists of a single message, signaling the start of secure communications between client and server. It employs the same format as the Record Layer, but the ChangeCipherSpec message simply uses the value of \u20181\u2019 to indicate a change in the communications protocol.<\/span><\/p>\n

3. The Alert Protocol<\/b><\/span><\/h3>\n

Error messages, warnings, or problems with the connection between client and server are covered by the Alert Protocol. It\u2019s defined by a Severity Level, which takes the value of \u20181\u2019 for a caution or warning. In this case, SSL sends a suggestion to both parties that they should discontinue this session and use a fresh handshake to reconnect. A Severity Level of \u20182\u2019 is fatal, and requires both parties to immediately discontinue the session.<\/span><\/p>\n

To further clarify matters, an Alert Description number is generated at each alert to indicate the specific problem that caused the alert message to be sent. SSL has a scale of 12 numbers and TLS has 23, with each representing different conditions and levels of severity.<\/span><\/p>\n

4. The Handshake Protocol<\/b><\/span><\/h3>\n

The Handshake in an SSL transaction is the passing of messages between client and server to initiate a secure connection.<\/span><\/p>\n

A ClientHello message sets out the options which the client (e.g. your web browser) is prepared to use to communicate with a web server. For example, this might include the version of SSL or TLS to be used, and CompressionMethods employed by the client. At this stage, a 32-byte RandomNumber is generated to help the client set up encryption.<\/span><\/p>\n

In response, the server selects options based on the ClientHello conditions and sends back a ServerHello message.<\/span><\/p>\n

A ServerKeyExchange occurs next, during which information is exchanged between client and server to set out how data is to be encrypted. With no encryption algorithm having been agreed upon at this stage, this information is sent as is. But the server\u2019s public key is used to encrypt a session key, which will later be used to encrypt the data to be transmitted. Digital certificates are examined at this stage to make sure that everyone is who they claim to be.<\/span><\/p>\n

A ServerHelloDone message concludes this stage.<\/span><\/p>\n

ClientKeyExchange is next. This message holds information about the key, which both parties will use to communicate.<\/span><\/p>\n

The transition from insecure to secure data transmission is then signaled by two ChangeCipherSpec messages, as client and server switch to the agreed secure state.<\/span><\/p>\n

Two messages confirm that the SSL Handshake is Finished. Key Information, the content of all previous handshake messages passing between the two systems, and the generation of a unique value to identify the sender as a client or server must all be verified before the handshake<\/a><\/span> concludes.<\/span><\/p>\n

What The User Sees:<\/b><\/span><\/h2>\n

It\u2019s at this point that the familiar padlock symbol appears in the user\u2019s web browser to indicate a secure communication. And the \u2018http\u2019 prefix of the web address changes to \u2018https\u2019.<\/span><\/p>\n

Signing Off<\/b><\/span><\/h3>\n

When all the Handshake information has been verified, secure communications can proceed. A Message Authentication algorithm is attached to the end of each message. It creates a digital summary or hash of the data contained in the message, so that any change in that information will be reflected by a corresponding change in the hash.<\/span><\/p>\n

To sign a message, you first generate its hash, and then use your private key to encrypt the summary. You must then add the encrypted hash and your own digital certificate to the message. Your message hash must be recreated then decrypted by the recipient, who will use your public key (as contained in your digital certificate).<\/span><\/p>\n

The recipient should check that both hashes match, and authenticate the validity of your certificate.<\/span><\/p>\n

A secure method for signatures is to encapsulate a text message inside with delimiters.<\/span><\/p>\n

Signing off is what we\u2019re doing now. In the next installment of this series, we\u2019ll look at how SSL is deployed across various platforms and operating environments. Hope you\u2019ll be here for that.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Online communications and e-commerce are fast replacing more traditional methods. So there\u2019s a real need for data to be moved around through secure channels. That\u2019s where protocols like the Secure Sockets Layer or SSL have a part to play. This series will consider the evolution of SSL, its current deployment, and options for the future. […]<\/p>\n","protected":false},"author":9,"featured_media":3931,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,13,6,9,8],"tags":[],"class_list":["post-3859","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-general-it","category-pc-security","category-tech","category-technical","category-windows"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/posts\/3859","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/comments?post=3859"}],"version-history":[{"count":5,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/posts\/3859\/revisions"}],"predecessor-version":[{"id":3955,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/posts\/3859\/revisions\/3955"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/media\/3931"}],"wp:attachment":[{"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/media?parent=3859"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/categories?post=3859"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/tags?post=3859"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}