• Home
    • Solutions
    • Services
    • Products Catalog
    • Contact Us
  • Domains
    • New Domain TLDs >
      • List of New Domains
    • Transfer Domains
    • International Domains
    • Private Domain Registration >
      • Public Vs Private Domain Registration.
    • Business Registration >
      • Sample Business Registration
    • Certified Domains >
      • Domain Certification Process
      • Sample - Certified Domains
      • Why do I need Certified Domains?
    • Deluxe Domains
    • Premium DNS for Domains >
      • Features - Premium DNS
      • DNS Overview
      • Premium DNS - How it Works?
      • Premium DNS- Ours Vs Theirs
    • Domain Appraisals & Evaluations >
      • Appraisal Process
      • Appraisal Factors
      • Premium Listings
    • Domain Backorder & Alert Pro >
      • Domain Alert Backorder & Monitoring - Plans
      • Domain Alert - Investor's Edge for Domainers
    • Domain Forwarding & Masking >
      • Domain Forwarding- Process
    • Free Domain Apps
  • Hosting
    • Shared Hosting >
      • Web Hosting Control Panels
      • Compare Linux Hosting
      • Compare Windows Hosting
      • Install Free Software on Hosting
    • Virtual Dedicated Server >
      • Popular VPS Operating Systems
      • cPanel Vs Parallels Plesk >
        • Parallels Plesk Hosting Control Panel
        • cPanel Hosting Control Panel
      • Frequently Asked Questions (VPS) >
        • What is a Managed Virtual Private Server?
        • OpenSSL/Heartbleed Information for Your Server
        • Setting up your virtual private server
        • What software is installed on my virtual private server?
        • Installing an SSL Certificate on your virtual private server
        • What can I install on my virtual private server?
        • What name servers do I use with my virtual private server?
    • Dedicated Server >
      • Popular OS Details
      • Free Apps >
        • Google® AdWords® Credit
        • Bing™ / Yahoo!® Search Credits
        • Facebook® Ad Credits
        • Fotolia® Photo Credits
        • TippingPoint™ Intrusion Prevention Systems
        • Bandwidth Overage Protection
      • Getting Started Guide
    • Dedicated IP
    • SEO Hosting
    • Support
  • Security
    • SSL Certificate >
      • SSL Certificates - Quick Tour
      • SSL Certificates - How SSL Works?
      • SSL Certificates - Frequently Asked Questions
    • Site Scanner >
      • Site Scanner- How It Works
      • Common Threats to your Site
      • Site Scanner- Ours Vs. Theirs
    • Code Signing Certificate >
      • Code Signing- FAQs
  • Email
    • Hosted Exchange
    • Email Quick Tour
  • Web Tools
    • Search Engine Visibility >
      • SEO Vs. PPC
      • Standard Plan >
        • SEO Quick Tour
      • Premium >
        • PPC Quick Tour
      • SEO - Compare Plans
      • SEO - Ours Vs. Thiers
    • Express Email Marketing >
      • Features & Process
      • Email Marketing- Ours Vs. Thiers
      • Why Email & Social?
    • Merchant Accounts >
      • Merchant Accounts- How it Works?
    • Shopping Cart >
      • Shopping Cart- Features
      • Shopping Cart- How It Works?
    • Fax Thru Email >
      • Faxing Features
    • Quick Blog >
      • Blogcast Overview
    • Calendar
    • Online Storage >
      • Online Storage Features
  • Web Design
    • e-Commerce Web Design >
      • Features
    • Web Design Services >
      • Facebook Page Designer
      • How It Works?
    • Website Builder >
      • How It Works?
      • Website Builder Features
    • Quick Content

About SSL Certificate

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provides security to data transfer over the Internet. SSL Certificates encrypts the segments of network connections at the Application Layer for the Transport Layer, using asymmetric cryptography for key exchange, symmetric encryption for privacy, and message authentication codes for message integrity. Several versions of the protocols are in widespread use in applications such as web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP).

TLS is an IETF standards track protocol, last updated in RFC 5246, and is based on the earlier SSL specifications developed by Netscape Communications.
Description
The TLS protocol allows client-server applications to communicate across a network in a way designed to prevent eavesdropping and tampering.

Since most protocols can be used either with or without TLS (or SSL) it is necessary to indicate to the server whether the client is making a TLS connection or not. There are two main ways of achieving this, one option is to use a different port number for TLS connections (for example port 443 for HTTPS). The other is to use the regular port number and have the client request that the server switch the connection to TLS using a protocol specific mechanism (for example STARTTLS for mail and news protocols).

Once the client and server have decided to use TLS they negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security.
  1. The client sends the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.
  2. The server sends the client the server's SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client's certificate.
  3. The client uses the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to step 4.
  4. Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher being used) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.
  5. If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
  6. If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
  7. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
  8. The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.
  9. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.

The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (either automation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.

If any one of the above steps fails, the TLS handshake fails and the connection is not created.
Applications
In applications design, TLS is usually implemented on top of any of the Transport Layer protocols, encapsulating the application-specific protocols such as HTTP, FTP, SMTP, NNTP and XMPP. Historically it has been used primarily with reliable transport protocols such as the Transmission Control Protocol (TCP). However, it has also been implemented with datagram-oriented transport protocols, such as the User Datagram Protocol (UDP) and the Datagram Congestion Control Protocol (DCCP), usage which has been standardized independently using the term Datagram Transport Layer Security (DTLS).

A prominent use of TLS is for securing World Wide Web traffic carried by HTTP to form HTTPS. Notable applications are electronic commerce and asset management. Increasingly, the Simple Mail Transfer Protocol (SMTP) is also protected by TLS. These applications use public key certificates to verify the identity of endpoints.

TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with OpenVPN. Many vendors now marry TLS's encryption and authentication capabilities with authorization. There has also been substantial development since the late 1990s in creating client technology outside of the browser to enable support for client/server applications. When compared against traditional IPsec VPN technologies, TLS has some inherent advantages in firewall and NAT traversal that make it easier to administer for large remote-access populations.

TLS is also a standard method to protect Session Initiation Protocol (SIP) application signaling. TLS can be used to provide authentication and encryption of the SIP signaling associated with VoIP and other SIP-based applications.

Security
TLS has a variety of security measures:
  • Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite.
  • Numbering subsequent Application records with a sequence number and using this sequence number in the message authentication codes (MACs).
  • Using a message digest enhanced with a key (so only a key-holder can check the MAC). The HMAC construction used by most TLS cipher suites is specified in RFC 2104 (SSL 3.0 used a different hash-based MAC).
  • The message that ends the handshake ("Finished") sends a hash of all the exchanged handshake messages seen by both parties.
  • The pseudorandom function splits the input data in half and processes each one with a different hashing algorithm (MD5 and SHA-1), then XORs them together to create the MAC. This provides protection even if one of these algorithms is found to be vulnerable. TLS only.
  • SSL 3.0 improved upon SSL 2.0 by adding SHA-1 based ciphers and support for certificate authentication.

From a security standpoint, SSL 3.0 should be considered less desirable than TLS 1.0. The SSL 3.0 cipher suites have a weaker key derivation process; half of the master key that is established is fully dependent on the MD5 hash function, which is not resistant to collisions and is, therefore, not considered secure. Under TLS 1.0, the master key that is established depends on both MD5 and SHA-1 so its derivation process is not currently considered weak. It is for this reason that SSL 3.0 implementations cannot be validated under FIPS 140-2.

Implementations
SSL and TLS have been widely implemented in several free and open source software projects. Programmers may use the PolarSSL, CyaSSL, OpenSSL, MatrixSSL, NSS, or GnuTLS libraries for SSL/TLS functionality. Microsoft Windows includes an implementation of SSL and TLS as part of its Secure Channel package. Delphi programmers may use a library called Indy. Comparison of TLS Implementations provides a brief comparison of features of different implementations.

Browser implementations
All the most recent web browsers support TLS:
  • Apple's Safari supports TLS, but it’s not officially specified which version. On operating systems (Safari uses the TLS implementation of the underlying OS) like Mac OS X 10.5.8, Mac OS X 10.6.6, Windows XP, Windows Vista or Windows 7, Safari 5 has been reported to support TLS 1.0.
  • Mozilla Firefox, versions 2 and above, support TLS 1.0. As of January 2012 Firefox does not support TLS 1.1 or 1.2.
  • Microsoft Internet Explorer always uses the TLS implementation of the underlying Microsoft Windows Operating System, a service called SChannel Security Service Provider. Internet Explorer 8 in Windows 7 and Windows Server 2008 R2 supports TLS 1.2. Windows 7 and Windows Server 2008 R2 use the same code (Microsoft Windows Version 6.1 (build 7600)) similar to how Windows Vista SP1 uses the same code as Windows 2008 Server.
  • As of Presto 2.2, featured in Opera 10, Opera supports TLS 1.2.
  • Google's Chrome browser supports TLS 1.0, and TLS 1.1 (but not TLS 1.2) from version 21 and higher.
Buy SSL Certificate

iwebslog products

Picture
Picture
Picture
Picture
Picture
Powered by Create your own unique website with customizable templates.