Report On Ssl & Tls

CHAPTER 1 History Behind Internet Security Computers have become ubiquitous and indispensable today. Internet usage has multiplied and is a vital global tool in technology. 1.1 What is Internet Security? This subject came into being with the advent of the Internet. There are three basic issues confidentiality, integrity and availability. When an unauthorized person reads or copies information, it is known as loss of confidentiality. When the information is modified in an irregular manner, it is known as loss of integrity. When the information is erased or becomes inaccessible, it is known as loss of availability. Authentication and authorization are the processes of the Internet security system by which numerous organizations make information available to those who need it and who can be trusted with it. When the means of authentication cannot be refuted later, it is known as non-repudiation. Internet security can be achieved through use of antivirus software, which quarantines or removes malicious software programs. Firewalls can determine which particular websites can be viewed and block deleterious content. 1.2 History of the Internet In the beginning, the Internet did not exist. There were no computer networks to be found. There was no e-mail facility, and people used postal mail or the telephone to communicate. The extremely busy sent telegrams. Few people used ugly names as a euphemism for others whom they had never met. The Internet has dramatically changed all this. The Internet, started as the Advanced Research Projects Agency Network (ARPANET). It was a tiny, isolated and restricted community. By 1996, the Internet connected an estimated 13 million computers in 195 countries on every continent, even Antarctica. The Internet is not a single network, but a worldwide collection of connected networks that are accessible by individual computer hosts by Internet service providers, gateways, routers and dial-up connections. The Internet is accessible to anyone with a computer and a network connection. Individuals and 1

organizations worldwide can reach any point on the network without regard to national or international boundaries or time. Today a local problem can become a global incident within a short span of time.

1.3 History of Internet Security In 1987, the ‘Vienna’ virus emerged. Ralph Burger got a copy of it, disassembled it, and published the result in his book ‘Computer Viruses: a High-tech Disease’. This particular book made the idea of writing viruses popular, explained how to do it, and resulted in creating up hundreds and in thousands of computer viruses implementing concepts from it. On November 2, 1988, Peter Yee at the NASA Ames Research Center sent a note out to the TCP/IP Internet mailing list that said, ‘We are currently under attack from an Internet VIRUS! It has hit Berkeley, UC San Diego, Lawrence Livermore, Stanford, and NASA Ames.’ Of course, this report was the first evidence of what was to be later known as The Morris Worm. Roberts, a 23-year-old Cornell University student, wrote some software code as part of a research project aimed at determining the size of the Internet. The worm was meant to infect computers, in order to see how many connections to the Internet existed. 2

Because of a flaw in the software code, however, it ended up exploiting vulnerabilities in Unix and spread rapidly, infecting multiple machines multiple times and rendering them unusable. In 1994, Russian hacker Vladimir Levin broke into Citibank's cash management system and embezzled $10 million into his own accounts. The stolen accounts were unencrypted and all but $400,000 of the stolen cash was recovered and Levin was arrested He pled guilty to conspiracy to commit computer, wire and bank fraud. On April 11, 1994, a full-scale epidemic broke out, caused by file and boot polymorphic virus called 'Tequila'. In September 1994, the same thing happened with the ‘Amoeba’ virus. In 1996, the ‘Boza’ virus emerged, which was the first virus designed specifically for Windows 95 files. In 1998, the first Java virus ‘Strange Brew’ affected computers. In 2005, the Bropia Worm affected the Internet. It targeted MSN messenger for spreading. The 2007 Storm Worm was a Trojan horse. It included an executable file as an attachment. When the e-mail recipient opened the attachment, he or she unknowingly became part of a botnet (a collection of infected computers) to spread viruses and Spam. Once infected, a computer is called as a bot. It is an instance of adaptive malware. It has been used in different kinds of criminal activities. The authors and the controllers, of the Storm Worm, have not yet been identified. 1.4 General ways of providing security The concept of cryptography helps a lot in the security perspect. There are a lot of Encryption methods (Algorithms) are also using such as RSA. Although these applications need the security:• E-mail Encryption • Web-site Encryption • Application Encryption • Remote user communiaction security by id and password • Digital Signatures •

Using secure version of http (HTTPS) by SSL/TLS connection etc. 3

CHAPTER 2 Introduction 2.1 What is SSL ? Secure Socket Layer (SSL) denotes the predominant security protocol of the Internet for World Wide Web (WWW) services relating to electronic commerce or home banking. The majority of web servers and browsers support SSL as the de-facto standard for secure client-server communication. The Secure Socket Layer protocol builds up point-to-point connections that allow private and unimpaired message exchange between strongly authenticated parties. In the ISO/OSI reference model [ISO7498], SSL resides in the session layer between the transport layer (4) and the application layer (7); with respect to the Internet family of protocols this corresponds to the range between TCP/IP and application protocols such as HTTP, FTP, Telnet, etc. SSL provides no intrinsic synchronization mechanism; it relies on the data link layer below. The SSL protocol allows mutual authentication between a client and server and the establishment of an authenticated and encrypted connection. SSL runs above TCP/IP and below HTTP, LDAP, IMAP, NNTP, and other high-level network protocols. In general : SSL – Secure Socket Layer • It provides a secure transport connection between applications (e.g., a web server and a browser), •

SSL was developed by Netscape, – V2 1994 netscape – V3 1996 netscape

•

SSL version 3.0 has been implemented in many web browsers (e.g., Netscape Navigator and MS Internet Explorer) and web servers and widely used on the Internet.

•

A protocol widely used on the Web –

Operates between the application and transport layers. 4

HTTP, FTP,SMTP SSL TCP IP Data Link Physical

•

Operations of SSL – Negotiation for PKI Server and browser negotiate to select cryptographic algorithm and create a session secret key. – Communications. Encrypted by using the key that was negotiated.

2.2 Evolution of SSL ? Netscape developed the first specification of SSL in 1994, but only publicly released and deployed the next version, SSLv2, in the same year [SSL2]. With respect to public key cryptography, it relies mainly on RSA encryption (RSA cryptosystem) and X.509compliant certificates. Block ciphers, such as DES, Triple DES (3DES), and RC4, along with hash functions like MD5 and SHA, complement the suite of algorithms. SSLv3 5

followed in 1995, adding cryptographic methods such as Diffie-Hellman key agreement (DH), support for the FORTEZZA key token, and the Digital Signature Standard (DSS) scheme [SSL3]. The most recent draft of the SSL 3.0 specification was published in November of 1996 by Netscape. The intent was to be a “security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.” The goals included cryptographic security, interoperability, extensibility, and relative efficiency. Interoperability was a goal so that applications could be written to the standard and expected to work with any other applications written to the standard. Interoperability, it was noted, does not imply that two programs will always be able to connect. One might not have the correct algorithm support or credentials necessary for the connection to the other. Extensibility was descried as providing “a framework into which new public key and bulk encryption methods can be incorporated as necessary.” It was noted that this should prevent the need to implement a new security protocol entirely should a weakness be found in one of the current encryption methods. Cryptography, obviously, causes a higher CPU load than sending the data unencrypted. Still, they made some effort to minimize the network traffic and allow for session caching. 2.2.1 SSL v2.0 Released by Netscape Communications in 1994. The main goal of this protocol was to provide security for transactions over the World Wide Web. Unfortunately, very quickly a number of security weaknesses were found in this initial version of the SSL protocol, thus making it less reliable for commercial use: o

weak MAC construction

o

possibility of forcing parties to use weaker encryption

o

no protection for handshakes

possibility of an attacker performing truncation attacks. 2.2.2 PCT v1.0

6

Developed in 1995 by Microsoft. Privacy Communication Technology (PCT) v1.0 addressed some weaknesses of SSL v2.0, and was aimed to replace SSL. However, this protocol has never gained as much popularity as SSL v3.0.

2.2.3 SSL v3.0 Released in 1996 by Netscape Communications. SSL v3.0 solved most of the SSL v2.0 problems, and incorporated many of the features of PCT. Pretty quickly become the most popular protocol for securing communication over WWW. 2.2.4 TLS v1.0 (also known as SSL v3.1) Published by IETF in 1999 (RFC 2246). This protocol is based on SSL v3.0 and PCT and harmonizes both Netscape's and Microsoft's approaches. It is important to note that although TLS is based on SSL, it is not a 100% backward compatible with its predecessor. IETF did some security improvements, such as using HMAC instead of MAC, using a different calculation of the master secret and key material, adding additional alert codes, no support for Fortezza cipher suites, and so on. The end result of these improvements is that these protocols don't fully interoperate. Fortunately enough, TLS has also got a mode to fall back to SSL v3.0. re version numbers: Both SSL2 and SSL3 have 16-bit (two-byte) version number fields. SSL2 interprets this as a single 16-bit integer, and the official number is 2, e.g. 0x0002. SSL3 interprets two-byte version numbers as a one byte "major" number and a one byte "minor" (or fractional) number. So the value 0x0002 is interpret by SSL3 as version 0.2, not 2.0.

2.3 What is TLS ? SSL 3.0 was the basis for the TLS 1.0 (RFC 2246) specification published by the Internet Engineering Task force (IETF) in 1999. In actual TLS was just a minor modification in SSL.

7

In general : TLS – Transport Layer Security •

TLS can be viewed as SSL v3.1,

•

SSL v3.0 was specified in an Internet Draft (1996), it evolved into RFC 2246 and was renamed to TLS (Transport Layer Security),

•

V1.0 1999 RFC2246 IETF minor update from SSL v3.0,

•

V1.1 April 2006 RFC4346 updates to prevent specific security attacks.

2.4 Evolution of TLS ? SSL v3.0 was actually renamed into TLS. SSL version 3.0 and its designated successor protocol Transport Layer Security (TLS) 1.0, which the Internet Engineering Task Force (IETF) published for the first time in 1999 [RFC2246]. The IETF published the most recent Internet-Draft for TLS 1.1 in Oct. 2002 [TLS]. The TLS 1.0 specification described itself as being similar to but not backwards compatible with the SSL 3.0 specification. It did include a fallback mechanism for SSL 3.0 if TLS was not available. The IETF made some small changes and clarifications and published RFC4346 in 2006 detailing TLS 1.1. There is currently a working draft for TLS 1.2 (RFC Draft 4346) which expired in September 2007.

2.5 SSL/TLS Architecture : SSL/TLS has 4 underlying protocols: Handshake, Record, Change Cipher Spec, and Alert. All other SSL/TLS protocols reside inside of the Record protocol. This is laid out as:

8

Protocol Architecture :

9

CHAPTER 3 SSL/TLS working and description 3.1 SSL layers and working? SSL splits into distinct layers and message types.SSL/TLS has 4 underlying protocols: Handshake, Record, Change Cipher Spec, and Alert. The working of these layers as follows:3.1.1 SSL Handshake protocol :The handshake message sequence initiates the communication, establishes a set of common parameters like the protocol version, applicable cryptographic algorithms (cipher suites), and assures the validity of the message sequence. During the handshake, the participants accomplish the negotiated authentication and derive the session key material. In this way Handshake protocol does :•

Negotiation of security algorithms and parameters,

•

Key exchange,

•

Server authentication and optionally client authentication.

TLS connections begin with a 6-way handshake. The handshake protocol structure is:

The allowed values for type are as follows:

10

0 HelloRequest 1 ClientHello 2 ServerHello 11 Certificate 12 ServerKeyExchange 13 CertificateRequest 14 ServerHelloDone 15 CertificateVerify 16 ClientKeyExchange 20 Finished 3.1.2 SSL Record protocol :The record layer fragments the full data stream into records with a maximum size of 214 bytes and envelopes them cryptographically under the current session keys. Records contain a keyed message authentication code (HMAC). The initial handshake presupposes a NULL cipher suite applying no encryption and no HMAC. The record layer fully provides the use of compression. However, for patent reasons the core specifications name no method explicitly, except for the mandatory NULL algorithm, which practically makes compression an incompatible, implementation-dependent feature. The basic layer structre and message is as follows:

11

Application Layer SSL / TLS Protocol Handshake Messages

Application Messages

ChangeCipherSpec Message Alert Messages

Record Layer

Transport Layer  SSL Layer and Message Structure

In this way the Record protocol does:•

Fragmentation,

•

Compression,

•

Message authentication and integrity protection,

•

Encryption.

3.1.3 SSL Change Cipher Spec Protocol:It is a single message that indicates the end of the SSL handshake. The change cipher can understood as follows:

12

State Changes

Here Operating state – currently used state. Pending state – state to be used, – built using the current state.

3.1.4 SSL Alert Protocol:Alert messages inform on exceptional protocol conditions (fatal alerts and warnings) or on a participant’s request to end the communication (closure alert). Each alert message consists of 2 fields (bytes) 1. first field (byte): “warning” or “fatal”

2. second field (byte): – fatal • unexpected_message • bad_record_MAC • decompression_failure • handshake_failure • illegal_parameter – warning 13

• close_notify • no_certificate • bad_certificate • unsupported_certificate • certificate_revoked • certificate_expired • certificate_unknown •

In case of a fatal alert –

connection is terminated,

–

session ID is invalidated,

–

no new connection can be established within this session.

3.2 SSL Encryption and Header ? SSL can use following Encrption and Header types:3.2.1 Encryption:It supports following algorithms:– block ciphers (in CBC mode) • RC2_40 • DES_40 • DES_56 • 3DES_168 • IDEA_128 • Fortezza_80 – stream ciphers • RC4_40 • RC4_128 If a block cipher is used, than padding is applied, last byte of the padding is the padding length. 3.2.2 Header :It supports following header types:• change_cipher_spec • alert 14

• handshake • application_data The higher level protocol used to process the enclosed fragment. Length (in bytes) of the enclosed fragment or compressed fragment max value is 214+ 2048. 3.3 SSL Working ? The working of SSL can be show as following:The SSL handshake accomplishes three goals. Firstly, both parties agree on a cipher suite, i.e. the set of cryptographic algorithms that they intend to use for application data protection. Secondly, they establish a common master_ secret in order to derive their session key material. Thirdly, the participant’s identities are authenticated. Although the SSL specification permits anonymous, server-only and mutual authentication, it is customary to only assert the server’s identity. This Figure gives an overview of the SSL protocol variants. It comprises four different handshake sequences, each identified by a capital letter: S,C,E,R which denotes:•

S denotes the server-authenticated message flow.

•

C marks the sequence with additional client authentication.

•

E shows the handshake variant with ephemeral Diffie-Hellman key agreement.

•

R stands for the handshake of resumed sessions. Note, that the message pairs.

ChangeCipherSpec / Finished of client and server are drawn in reverse order; the server message pair follows ServerHello immediately. Process :First the client sends the Client Hello message which includes a 32-bit Unix format timestamp and a 28-byte random number. The client may also specify a session identifier of a current or previous session. Doing this allows for multiple secure connections without going through the entire handshake process each time, although both Hello, the Change Cipher Spec, and both Finished messages must still be exchanged and be valid.

15

SSL Protocol Sequence

The client then includes a list of acceptable Cipher Suites and Compression Methods. Each cipher suite defines the algorithm for key exchange, the bulk encryption algorithm with secret key and length, and the message authentication code (MAC). The server then responds to this with the Server Hello message. The server hello message will have the following data: • The version number being used: the lower of the server’s highest supported version and the version in the client hello. • A random number generated by the server. • The session identifier: if the Session ID is recognized, then a short handshake is used and the following fields are filled in with the values from the previous connection. Otherwise, the Server Hello generates a new Session ID. • The cipher suite chosen by the server, and 16

• The compression method chosen by the server. If the server can not find an acceptable cipher suite and compression method, it will respond with a handshake failure alert. Unless the key exchange method is anonymous, the server will send out a Certificate immediately after sending the Server Hello. The certificate is generally a X.509v3 certificate public key and unless otherwise specified uses the same key exchange method and signing algorithm previously decided on. After the server’s certificate, certificates from all the up line servers necessary to get to one that the client trusts must be included. The order of these should be such that each certificate validates the one before it. If the server Certificate does not contain enough data for a premaster secret, then a Server Key Exchange is sent with either a RSA public, or a Diffie-Hellman public key. (This is the case for DHE_DSS, DHE_RSA, and DH_anon; but not for RSA, DH_DSS, and DH_RSA key exchange methods.) If it is appropriate, the server may request a certificate from the client with a Certificate Request. This would immediately follow the Server Certificate, or if present the Server Key Exchange. The Certificate request would specify the types of certificates the server will accept and the Certificate Authorities the server trusts. The client, after receiving the Server Hello Done would respond with a message identical in format to the Server Certificate. The Server Hello Done indicates to the client that server is done sending data and the client should now verify the certificates and whatnot it has received. If a Certificate Request was received, the client would now send the Certificate. If RSA is used, the Client Key Exchange message includes an encrypted pre-master secret which consists of a 48-bit number that is encrypted with the server’s public key. If Diffie-Hellman is used, but not Fixed Diffie-Hellman, then the public key parameters are sent here. If the client sent a certificate, then it would send a Certificate Verify message hat this point, in most cases. This would include a signature in the same format as defined for the Server Key Message as well as an md5 sum of all of the previous messages and a SHA hash of all of the previous messages.

17

The Client sends the Change Cipher Spec message indicating that all future traffic will be computed with the Master Secret. The random numbers and the pre master secret are used by both systems in a pseudorandom function to calculate the master secret. The change cipher spec protocol is a single byte that will always have a value of 1. It is encrypted and compressed under the current cipher (the pre master secret) and compression method. The client now sends the Finished Message. This consists of the master secret, the finished label, an md5 of all previous messages and an SHA of all previous messages. All of this is encrypted with the master secret. If the server can read all of this, then the server knows that the key generation was successful. The server responds with its own Change Cipher Spec and Finished messages which verify to the client that the key generation was successful. If any warning or fatal errors occur, an alert is sent. Alerts consist of a byte that defines whether it’s a warning (1) or a fatal (2) alert, and a byte that indicates the specific alert.

The following alerts (with their values in parenthesis) are fatal: • unexpected_message(10), • bad_record_mac(20), • decryption_failed(21), • record_overflow(22), • decompression_failure(30), • handshake_failure(40), • illegal_parameter(47), • unknown_ca(48), • access_denied(49), • decode_error(50), • export_restriction_RESERVED(60), • protocol_version(70), • insufficient_security(71), 18

• internal_error(80), • user_canceled(90), These messages may not be fatal: • close_notify(0), • no_certificate_RESERVED (41), - this is SSL 3.0 only • bad_certificate(42), • unsupported_certificate(43), • certificate_revoked(44), • certificate_expired(45), • certificate_unknown(46), • decrypt_error(51), • no_renegotiation(100) When the master secret is computed, data may be sent encapsulated inside of record protocol. This data will be encrypted and compressed in the agreed upon methods and can be reliably read by the other end but not likely anyone in-between.

19

CHAPTER 4 SSL/TLS Certificates and Practical Implementation 4.1 What is SSL and what are Certificates? The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works. 1. A browser requests a secure page (usually https://). 2. The web server sends its public key with its certificate. 3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted. 4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data. 5. The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data. 6. The web server sends back the requested html document and http data encrypted with the symmetric key. 7. The browser decrypts the http data and html document using the symmetric key and displays the information. 4.1.1 What is https? Hyper Text Transfer Protocol Secure (HTTPS) is a secure version of the Hyper Text Transfer Protocol (http). HTTPS allows secure ecommerce transactions, such as online banking. 20

Web browsers such as Internet Explorer and Firefox display a padlock icon to indicate that the website is secure, as it also displays https:// in the address bar. When a user connects to a website via HTTPS, the website encrypts the session with a digital certificate. A user can tell if they are connected to a secure website if the website URL begins with https:// instead of http://. HTTPS is effectively HTTP using SSL (Secure Sockets Layer). SSL merely encrypts the content of the packets before being sent from the server to client. 4.1.2 Concepts behind Certificates? Following concepts are used in identification and validation of SSL certificates:4.1.2.1 Private Key/Public Key: The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. This is sometime hard to understand, but believe me it works. The keys are similar in nature and can be used alternatively: what one key emcrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs. The trick in a key pair is to keep one key secret (the private key) and to distribute the other key (the public key) to everybody. Anybody can send you an encrypted message, that only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite , you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secured you have only signed it. Everybody has the public key, remember! One of the problem left is to know the public key of your correspondent. Usually you will ask him to send you a non confidential signed message that will contains his publick key as well as a certificate. Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message

4.1.2.2 The Certificate: 21

A SSL certificate does following tasks:1. An SSL Certificate enables encryption of sensitive information during online

transactions. 2. Each SSL Certificate contains unique, authenticated information about the certificate

owner. 3. A Certificate Authority verifies the identity of the certificate owner when it is issued.

4.1.2.2.1 who need SSL certificate ?: SSL should be used by any organization wishing to: •

Secure online creditcard transactions

•

Secure online systemlogins, web forms, web mail, control panels or protected areas of web sites

•

Secure the transfer of files over https and FTP services such as web site owners updating new pages to their web sites

•

Secure the connection between an email client such as Microsoft Outlook and an email server such as Microsoft Exchange

•

Secure intranet basedtraffic such as intranets, extranets and database connections

The e-commerce business is all about making money and then finding ways to make more money. Of course, it's hard to make (more) money, when consumers don't feel safe executing a transaction on your Web site. That's where SSL (Secure Socket Layer) comes into play. 4.1.2.2.2 working of certificate ?: SSL is all about encryption. SSL encrypts data, like credit cards numbers (as well other personally identifiable information), which prevents the "bad guys" from stealing your information for malicious intent. You know that you're on an SSL protected page when the address begins with "https" and there is a padlock icon at the bottom of the page (and in the Mozilla

Firefox

in

the

address

bar

as

well).

The browser encrypts the data and sends to the receiving Web site using either 40-bit or 12822

bit encryption. Your browser alone cannot secure the whole transaction and that's why it's incumbent upon e-commerce site builders to do their part. At the other end of the equation, and of greatest importance to e-commerce site builders, is the SSL certificate. The SSL certificate sits on a secure server and is used to encrypt the data and to identify the Web site. The SSL certificate helps to prove the site belongs to who it says it belongs to and contains information about the certificate holder, the domain that the certificate was issued to, the name of the Certificate Authority who issued the certificate, the root

and

the

country

it

was

issued

in.

SSL certificates come in 40-bit and 128-bit varieties, though 40-bit encryption has been hacked. As such, you definitely should be looking at getting a 128-bit certificate. Though there a wide variety of ways in which you could potentially acquire a 128-bit certificate, there is one key element that is often overlooked in order for full two-way 128bit encryption to occur. According to SSL certificate vendor VeriSign, in order to have 128bit encryption you need a certificate that has SGC (server grade cryptography) capabilities. How Encryption Works :Imagine sending mail through the postal system in a clear envelope. Anyone with access to it can see the data. If it looks valuable, they might take it or change it. An SSL Certificate establishes a private communication channel enabling encryption of the data during transmission. Encryption scrambles the data, essentially creating an envelope for message privacy. Each SSL Certificate consists of a public key and a private key. The public key is used to encrypt information and the private key is used to decipher it. When a Web browser points to a secured domain, a Secure Sockets Layer handshake authenticates the server (Web site) and the client (Web browser). An encryption method is established with a unique session key and secure transmission can begin. True 128-bit SSL Certificates enable every site visitor to experience the strongest SSL encryption available to them. How Authentication Works :Imagine receiving an envelope with no return address and a form asking for your bank account number. Every VeriSign SSL Certificate is created for a particular server in a specific domain for a verified business entity. When the SSL handshake occurs, the browser 23

requires authentication information from the server. By clicking the closed padlock in the browser window or certain SSL trust marks (such as the VeriSign Secured Seal), the Web site visitor sees the authenticated organization name. In high-security browsers, the authenticated organization name is prominently displayed and the address bar turns green when an Extended Validation SSL Certificate is detected. If the information does not match or the certificate has expired, the browser displays an error message or warning. Why Authentication Matters :Like a passport or a driver’s license, an SSL Certificate is issued by a trusted source, known as the Certificate Authority (CA). Many CAs simply verify the domain name and issue the certificate. VeriSign verifies the existence of your business, the ownership of your domain name, and your authority to apply for the certificate, a higher standard of authentication. VeriSign Extended Validation (EV) SSL Certificates meet the highest standard in the Internet security industry for Web site authentication as required by CA/Browser Forum. EV SSL Certificates give high-security Web browsers information to clearly display a Web site’s organizational identity. The high-security Web browser’s address bar turns green and reveals the name of the organization that owns the SSL Certificate and the SSL Certificate Authority that issued it. Because VeriSign is the most recognized name in online security, VeriSign SSL Certificates with Extended Validation will give Web site visitors an easy and reliable way to establish trust online. 4.1.2.2.3 Who can issue SSL Certificates?: SSL Certificates can be issued by anybody using freely available software such as Open SSL or Microsoft's Certificate Services manager. Such SSL Certificates are known as "selfsigned" Certificates. However, self-signed SSL Certificates are not inherently trusted by customer's browsers and whilst they can still be used for encryption they will cause browsers to display "warning messages" - informing the user that the Certificate has not been issued by an entity the user has chosen to trust. Such warnings are undesirable for commercial sites - they will drive away customers. In order to avoid such warnings the SSL Certificate must be issued by a "trusted certifying authority" - trusted third party Certification Authorities that utilize their trusted position to make available "trusted" SSL Certificates. 24

Warning message IE users will see from a self-signed SSL Certificate

Warning message Netscape users will see from a self-signed SSL Certificate

4.1.2.2.4 What is a Certification Authority? Browsers and Operating Systems come with a pre-installed list of trusted Certification Authorities, known as the Trusted Root CA store. As Microsoft and Netscape provide the major operating systems and browsers, they have elected whether to include the Certification Authority into the Trusted Root CA store, thereby giving trusted status. Microsoft and Netscape determine which organizations are Certification Authorities.

25

The Microsoft trusted root CA store

The Netscape trusted root CA store

SSL certificates issued by trusted Certification Authorities do not display a warning and establish a secure link between website and browser transparently. In such circumstances, the padlock signifies the user has an encrypted link with a company who has been issued a trusted SSL Certificate from a trusted Certificate Authority. Microsoft and Netscape have therefore determined the role of the Certification Authority to use their trusted status to "pass trust" to websites whom ordinarily would not be trusted by a customer. The key issue must now be addressed - before passing such trust, how does the CA know the website can be trusted? All SSL Certificates are not equal! The value of SSL is protected by the strength of a standard two-point validation process: Step 1: Verify that the applicant owns, or has legal right to use, the domain

26

Name featured in the application. Step 2: Verify that the applicant is a legitimate and legally accountable entity. The compromise of either step endangers the message of trust and legitimacy provided to the end consumer. Companies such as GeoTrust, through its QuickSSL and FreeSSL products, and IPSCA, the Spanish SSL Provider, perform only the first stage of the two-step validation process (as employed by all other SSL Providers) by only verifying that the applicant owns the domain name provided during Certificate application. This validation step relies on the use of Domain Name Registrar details to validate ownership of a domain name and then a challenge email is sent to the listed administrator of the domain name. If the challenge is met with a successful reply, the Certificate will be issued.

4.1.2.2 The Symmetric key: Well, Private Key/Public Key encryption algorithms are great, but they are not usually practical. It is asymmetric because you need the other key pair to decrypt. You can't use the same key to encrypt and decrypt. An algorithm using the same key to decrypt and encrypt is deemed to have a symmetric key. A symmetric algorithm is much faster in doing its job than an asymmetric algorithm. But a symmetric key is potentially highly insecure. If the enemy gets hold of the key then you have no more secret information. You must therefore transmit the key to the other party without the enemy getting its hands on it. As you know, nothing is secure on the Internet. The solution is to encapsulate the symmetric key inside a message encrypted with an asymmetric algorithm. You have never transmitted your private key to anybody, then the message encrypted with the public key is secure (relatively secure, nothing is certain except death and taxes). The symmetric key is also chosen randomly, so that if the symmetric secret key is discovered then the next transaction will be totally different. Symetric Key-->[Public Key]-->Encrypted Symetric Key-->[Private Key]-->Symetric Key

4.1.2.3 Encryption algorithm:

27

There are several encryption algorithms available, using symmetric or asymmetric methods, with keys of various lengths. Usually, algorithms cannot be patented, if Henri Poincare had patented his algorithms, then he would have been able to sue Albert Einstein... So algorithms cannot be patented except mainly in USA. OpenSSL is developed in a country where algorithms cannot be patented and where encryption technology is not reserved to state agencies like military and secret services. During the negotiation between browser and web server, the applications will indicate to each other a list of algorithms that can be understood ranked by order of preference. The common preferred algorithm is then chosen. OpenSSL can be compiled with or without certain algorithms, so that it can be used in many countries where restrictions apply.

4.1.2.4 The Hash: A hash is a number given by a hash function from a message. This is a one way function, it means that it is impossible to get the original message knowing the hash. However the hash will drastically change even for the slightest modification in the message. It is therefore extremely difficult to modify a message while keeping its original hash. It is also called a message digest. Hash functions are used in password mechanisms, in certifying that applications are original (MD5 sum), and in general in ensuring that any message has not been tampered with. It seems that the Internet Enginering Task Force (IETF) prefers SHA1 over MD5 for a number of technical reasons. 4.1.2.5 Signing: Signing a message, means authentifying that you have yourself assured the authenticity of the message (most of the time it means you are the author, but not neccesarily). The message can be a text message, or someone else's certificate. To sign a message, you create its hash, and then encrypt the hash with your private key, you then add the encrypted hash and your signed certificate with the message. The recipient will recreate the message hash, decrypts the encrypted hash using your well known public key stored in your signed certificate, check that both hash are equals and finally check the certificate.

28

The other advantage of signing your messages is that you transmit your public key and certificate automatically to all your recipients. There are usually 2 ways to sign, encapsulating the text message inside the signature (with delimiters), or encoding the message altogether with the signature. This later form is a very simple encryption form as any software can decrypt it if it can read the embedded public key. The advantage of the first form is that the message is human readable allowing any non complaint client to pass the message as is for the user to read, while the second form does not even allow to read part of the message if it has been tampered with. 4.1.2.6 PassPhrase: “A passprase is like a password except it is longer”. In the early days passwords on Unix system were limited to 8 characters, so the term passphrase for longer passwords. Longer is the password harder it is to guess. Nowadays Unix systems use MD5 hashes which have no limitation in length of the password. 4.1.2.7 Public Key Infrastructure : The Public Key Infrastructure (PKI) is the software management system and database system that allows to sign certifcate, keep a list of revoked certificates, distribute public key,... You can usually access it via a website and/or ldap server. There will be also some people checking that you are who you are... For securing individual applications, you can use any well known commercial PKI as their root CA certificate is most likely to be inside your browser/application. The problem is for securing e-mail, either you get a generic type certificate for your e-mail or you must pay about USD100 a year per certificate/e-mail address. There is also no way to find someone's public key if you have never received a prior e-mail with his certificate (including his public key). 4.2 SSL Softwares These are most useful SSL software:•

OpenSSL: a free implementation (BSD license with some extensions).

•

GnuTLS: a free implementation (LGPL licensed).

•

JSSE: a Java implementation included in the Java Runtime Environment.

•

Network Security Services (NSS): FIPS 140 validated open source library. 29

Openssl is a very popular SSL software.It is described as :Openssl :OpenSSL is an open source implementation of the SSL and TLS protocols. The core library (written in the C programming language) implements the basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available. Versions are available for most Unix-like operating systems (including Solaris, Linux, Mac OS X and the four open source BSD operating systems), OpenVMS and Microsoft Windows. IBM provides a port for the System i (iSeries/AS400). OpenSSL is based on SSLeay by Eric A. Young and Tim Hudson, development of which unofficially ended around December 1998, when Tim and Eric both moved to work for RSA Security. Algorithms :OpenSSL supports a number of different cryptographic algorithms: 1. Ciphers •

Blowfish, Camellia, DES, RC2, RC4, RC5, IDEA, AES

2. Cryptographic hash functions •

MD5, MD2, SHA, MDC-2

3. Public-key cryptography •

RSA, DSA, Diffie-Hellman key exchange, Elliptic curve

4.3 SSL Practical Implementation The practically SSL is implemented for Apache 2.0 in this way :4.3.1 Installing Apache with SSL/TLS support :The first step in order to install Apache with SSL/TLS support is to configure and install the Apache 2 web server, and create a user and group named "apache". A secure way of installing Apache's 2.0 has already been published on SecurityFocus in the article Securing Apache 2.0: Step-by-Step. The only difference to that process is to enable mod_ssl and mod_setenvif, which is required to provide compatibility with some versions of MS Internet Explorer, as follows (changes shown in bold): 30

./configure \ --prefix=/usr/local/apache2 \ --with-mpm=prefork \ --enable-ssl \ --disable-charset-lite \ --disable-include \ --disable-env \ --enable-setenvif \ --disable-status \ --disable-autoindex \ --disable-asis \ --disable-cgi \ --disable-negotiation \ --disable-imap \ --disable-actions \ --disable-userdir \ --disable-alias \ --disable-so After configuring, we can install Apache into the destination directory: make su umask 022 make install chown -R root:sys /usr/local/apache2

4.3.2 Configuring SSL/TLS :Basically SSL default port number is 443. Before running Apache for a first time, we need also to provide an initial configuration and prepare some sample web content. As a minimum, we need to go through the following steps (as root): 1. Create some sample web content, which will be served up via TLS/SSL: 2.

Replace

the

default

Apache

configuration

file

(normally

found

in

/usr/local/apache2/conf/httpd.conf) with the new one, using the following content (optimized with respect to security and performance). 3. Prepare the directory structure for web server's private keys, certificates and certification revocation lists (CRLs): 31

4. Create a self-signed server certificate (it should be used only for test purposes -- your real certificate should come from a valid CA such as Verisign): 4.3.3 Testing the installation :At this point we can start Apache with SSL/TLS support, as follows: /usr/local/apache2/bin/apachectl startssl Apache/2.0.52 mod_ssl/2.0.52 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server 127.0.0.1:443 (RSA) Enter pass phrase:************* Ok: Pass Phrase Dialog successful.

After the server starts, we can try to connect to it by pointing the web browser to the URL of the form: https://name.of.the.web.server.In few moments, we should see a warning message saying that there is problem with verifying the authentication of the web server we want to access. The occurrence of the above warning is perfectly correct. We should receive this message because of two reasons: •

The web browser does not know the Certificate Authority which issued the web server's certificate (and cannot know, because we are using self-signed certificate)

•

The CN (Common Name) attribute of the certificate does not match the name of the website - at the moment it is "Test-Only Certificate", and it should be the fully qualified domain name of the web server

there is a yellow lock at the bottom of the web browsers, which means that the SSL connection has been successfully established. The value "128-bit" says that the symmetric key that that is being used to encrypt the communication has the length of 128 bits, which is strong enough (at least for the moment) to protect the traffic from unauthorized access. If we double click the lock icon, we will see the properties of website's certificate. 32

4.4 SSL Standards The current approved version is 1.2, which is specified in: •

RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.

The current standard obsoletes these former versions: •

RFC 2246: “The TLS Protocol Version 1.0”.

•

RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”.

Other RFCs subsequently extended TLS, including: •

RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. Specifies an extension to the IMAP, POP3 and ACAP services that allow the server and client to use transport-layer security to provide private, authenticated communication over the Internet.

•

RFC 2712: “Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)”. The 40-bit ciphersuites defined in this memo appear only for the purpose of documenting the fact that those ciphersuite codes have already been assigned.

•

RFC 2817: “Upgrading to TLS Within HTTP/1.1”, explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443).

•

RFC 2818: “HTTP Over TLS”, distinguishes secured traffic from insecure traffic by the use of a different 'server port'. 33

•

RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer Security”. Specifies an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet.

•

RFC 3268: “AES Ciphersuites for TLS”. Adds Advanced Encryption Standard (AES) ciphersuites to the previously existing symmetric ciphers.

•

RFC 3546: “Transport Layer Security (TLS) Extensions”, adds a mechanism for negotiating protocol extensions during session initialisation and defines some extensions. Made obsolete by RFC 4366.

•

RFC 3749: “Transport Layer Security Protocol Compression Methods”, specifies the framework for compression methods and the DEFLATE compression method.

•

RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using LempelZiv-Stac (LZS)”.

•

RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.

•

RFC 4162: “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”.

•

RFC 4217: “Securing FTP with TLS”.

•

RFC 4279: “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)”, adds three sets of new ciphersuites for the TLS protocol to support authentication based on pre-shared keys.

•

RFC 4347: “Datagram Transport Layer Security” specifies a TLS variant that works over datagram protocols (such as UDP).

•

RFC 4366: “Transport Layer Security (TLS) Extensions” describes both a set of specific extensions, and a generic extension mechanism.

•

RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”.

•

RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side State”.

•

RFC 4680: “TLS Handshake Message for Supplemental Data”.

•

RFC 4681: “TLS User Mapping Extension”.

•

RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”.

34

CHAPTER 5 CONCLUSIONS & FUTURE SCOPE

Presently, SSL/TLS become backbone of not only in E-commerce but in any secured information exchange across Internet. Although the working advance TLS protocol provides a better security mechnism then ssl but it still has some limitation which needs to overcome. The limitations of using TLS/SSL:5.1 Increased processor load This is the most significant limitation to implementing TLS/SSL. Cryptography, specifically public key operations, is CPU-intensive. As a result, performance varies when you are using SSL. Unfortunately, there is no way to know how much performance you will lose. The performance varies, depending on how often connections are established and how long they last. TLS uses the greatest resources while it is setting up connections. 5.2 Administrative overhead A TLS/SSL environment is complex and requires maintenance; the system administrator must configure the system and manage certificates.

5.3 Limitation of SSL/TLS with REBOL/Command 2.0 REBOL/Command 2.0 and higher support client-side data encryption across a TCP channel using the Secure Socket Layer (SSL) and Transport Layer Security (TLS) standards. REBOL provides two ways of using this feature: The HTTPS protocol (SSL for HTTP) exists as a predefined scheme. Other schemes (e.g. SMTP across SSL/TLS or POP3 across SSL/TLS) can be implemented based on the ssl:// and tls:// schemes, which implement SSL and TLS on top of TCP sockets. In its current version the REBOL SSL/TLS implementation has the following limitations. Future versions of REBOL may add support for these features. • SSL/TLS server mode is not supported. 35

• Certificate handling is not supported. REBOL does check the validity of server certificates internally, but no mechanism exists to access the certificate chain from REBOL scripts, and client certificates cannot be defined. 5.4 Limitations of SSL/TLS with FTP • The FTP server must support SSL. • FTP cannot be eliminated from the enterprise environment. • Administration is more complex because the required authentication uses certificates. • By default, FTP with SSL/TLS does not provides user authentication, only host authentication. 5.5 Limitations in TLS authentication The following are limitations to authenticating strangers on the Internet using TLS client/server authentication: •

Certificates are exchanged in plain text during the initial TLS handshake.

•

The client and the server are limited to disclosing a single certificate chain to each other. containing those attributes.

•

The server specifies a list of distinguished names of certifying authorities that the server trusts when it requests a client certificate.

In contrast, the client has

no such opportunity. 5.6 Limitations in Software prospective • The software used for testing is of course available for others to use,under a BSD licence [sslperf]. •

Find out why the Apache server refuses to reuse sessions.And whether it can shut down SSL properly (bugfix).

• Integrate with Globus GSI libraries. •

Use different public key algorithms (e.g., DSA, elliptic curves).

•

Investigate other types of authentication or message confidentiality,c.f., [Message level vs SSL layer].

5.7 Other future directions Improved Certificate Management 36

• Certificate chains • Longer RSA keys for server certificates • PKCS #7, PEM certificate formats In the next version above mentioned limitation needs to be corrected sothat secure transmission of information can be gurrented.

37

REFERENCES

Websites:1. 2. 3. 4. 5.

www.google.com www.pdfcoke.com http://en.wikipedia.org/wiki/Ssl www.openssl.org/ www.VeriSign.com

1. 2. 3. 4.

SSL & TLS Essentials- by Stephen A. Thomas HTTP Essentials- by Stephen Thomas Network Security with OpenSSL- by John Viega, et al

Books:-

SSL and TLS- by Eric Rescorla (Author)

38