LuxSciLuxSci
Secure Email,
Web and Form Solutions
Phone: 800-441-6612
sales@luxsci.com
support@luxsci.com

How Does Secure Socket Layer (SSL or TLS) Work?

The Secure Socket Layer, SSL for short, is a protocol by which many services that communicate over the Internet can do so in a secure fashion. Before we discuss how SSL works and what kinds of security it provides, let us first see what happens without SSL.

Life on the Internet without SSL

Let us compare communications between computers on the Internet and communications between people over the telephone. Without SSL, your computer-to-computer communications suffer from the same security problems from which your telephone communications suffer:

  • Who are you talking to? In a phone conversation, how can you be sure that the person who picks up the phone at the other end is really the person you are trying to call (especially if you have never spoken to them before)? What if your phone call is intercepted or re-routed, or what if someone else is answering your call recipient’s phone?There really is no way to be sure you have reached the right person, especially if they are actively trying to fool you.
  • Eavesdropping? As you are aware of from watching TV or reading, it is very easy to “tap” phone lines: the government and spies do this all the time to covertly gather information (e.g. the NSA PRISM and other surveillance programs). It is not easy to impossible to detect if your lines are tapped.The same applies with communications over the Internet — how can you be sure that your communications are not being “tapped” and recorded?  This is especially problematic in public wifi hotspots or when communicating through large public corporations like Google or AOL?

This results in two very real security issues for communications over the Internet: 1. knowing for sure that you are connecting to the intended servers  (i.e. those at your bank and not those at a hacker’s or phisher’s web site), and 2. knowing that your data is safe from prying eyes during transit to those computers. This is where SSL comes in.

Enter the Secure Socket Layer (SSL)

To solve these problems to a large degree, most Internet services support use of SSL as a mechanism for securing communications. To illustrate how SSL works, let us use another analogy.

Jason wants to communicate with a company to send important information back and forth. Jason wants to be 100% sure that he is communicating with this particular company and that no one can eavesdrop on or intercept the communications. How can he do this?

  1. Jason sends a courier to the company’s address.
  2. The company has envelopes that, when closed, can only be opened by the company. The company and the courier go together to a trusted third party — a notary — which makes the company provide documentation to prove its identity. The notary certifies the company’s identity and it’s secure envelopes and the courier takes these envelops back to the Jason.
  3. Jason gets the envelopes and, if he trusts the notary’s reputation, can be sure that they are actually from the company indicated.
  4. Jason also has secure envelopes that, once sealed, only Jason can open. He puts some of these in one of the company’s secure envelopes and sends them back to the company.
  5. The company gets the sealed secure envelope. It opens the envelope (as only it can). It now has Jason’s secure envelopes.
  6. The company has another kind of envelope that can be opened and sealed only by using a special combination. The company puts this special combination-envelope, together with the appropriate combination, into one of Jason’s secure envelopes. The company seals the envelope.
  7. The company has another type of secure envelope that anyone can open, but which only the company can seal. If you open one of these sealed envelopes, you know for sure that it was sent by the company. The company puts the whole package inside this and sends it to Jason.
  8. When Jason gets the secure envelope, he opens it and thus knows that it came from the company. He then opens the next secure envelope inside that can only be opened by Jason. Inside, Jason finds the combination-envelope and the combination itself.
  9. Jason puts his data in the combination envelope, seals it and sends it to the company.
  10. The company receives it, opens it, and puts the response in the same secure envelope and sends it back.
  11. The procedure is repeated as often as necessary for required communications.

SSL relies on the concept of “public key cryptography” to accomplish these same tasks. In normal “symmetric” encryption, the two parties communicating share a “password” and that password is used to both encrypt and decrypt messages. While this is fast and efficient, how do you communicate the shared passwords to people you have not yet met in a way that is itself secure?

In “public key cryptography”, each person has two keys — a “public” key and a “private” key. Anything encrypted with the person’s public key can only be decrypted with the private key and vice versa. Each person then tells the world what his public key is and keeps his private key safe, secure, and, well, private.

If Jason sends Mary a message encrypted with Mary’s public key, then only Mary can open it, as only she has her private key. This is like an envelope that anyone can seal but which only Mary can open.

If Jason sends Mary a message encrypted with John’s private key, then anyone can open it, as everyone has access to John’s public key. However, successfully opening the message proves that it was sent by John and no one else, as only John has access to his private key. This is like an envelope that only John can seal, but which anyone can open and thus prove that John sealed it.

SSL in Action

So, let’s see how SSL actually works for securing your communications over the Internet. Before the communications occur, the following takes place:

  1. A company wishes to secure communications to their web server company.com.
  2. They create a public and private key for company.com (this is also known as as “SSL Certificate“).
  3. They go to a trusted third party company such as Thawte or Verisign: Thawte makes the company prove its identity and right to use the company.com domain. This usually involves a lot of paperwork and paying a hefty fee.
  4. Once the verification is complete, Thawte gives the company a new public key that has some additional information in it. This information is the certification from Thawte that this public key is for the company and company.com and that this is verified by Thawte. This certification information is encrypted using Thawte’s own private key… we will see why below.

Then, when Jason wishes to communicate with the company at company.com,

  1. Jason makes a connection to company.com with its computer (e.g. from his web browser if this is a web site). This connection is made to a special “port” (address) on company.com that is set up for SSL communications only (alternately, Jason could connect to a non-secure port and the initiate a secure connection after the fact … see SSL vs TLS – what’s the difference).
  2. Jason connects to company.com on its SSL-secured port, the company sends back its public key (and some other information, like what Ciphers it supports).
  3. Jason gets the public key and decides if it is “OK”…
    1. If the public key has expired, this could be a problem (these are only valid for a certain number of years before they have to be re-verified)
    2. If the public key claims to be for some domain that is not company.com that could be a significant problem.
    3. Jason has the public key for Thawte (and many other third party companies) stored in its computer — because these come with the computer. Thus, Jason can decrypt the validation information, prove the validation is actually from Thawte, and verify that the public key is certified by Thawte. If Jason trusts Thawte, then he can trust that he is really communicating with Company. If Jason doesn’t trust Thawte, or whatever Third Party verification company is actually being used, then the identity of who is running the servers to which Jason is connecting is suspect.
  4. If Jason doesn’t trust the server, then the communication is terminated before anything sensitive is communicated.
    1. Note: If Jason has his own SSL certificate, he may send that to the server at this point to see if the server trusts Jason.  These “Client-side SSL certificates” are not commonly used, but provide a good way for users like Jason to authenticate themselves with a server without using a username or password (or in addition to doing so, as a second factor).  In cases where this is used, the server would have to already know about the Jason’s certificate and verify it in a similar way to how the client verified the server.  If this fails, the connection is terminated.  If a client-side certificate is not needed, this step is skipped.
  5. Once Jason is happy with the server (and the server with Jason, if needed), then he can  choose an SSL Cipher to use from the list of encryption methods provided by the server, and generates a “symmetric key” (a password) for use with that Cipher.  Jason encrypts this password using the server’s public key and sends it back to the server.  The server (and only the server) can decrypt this message and get this password, which is now shared by both Jason and server.
  6. Jason will then start communicating with the company by encrypting all data using this password and the chosen Cipher.  Normal “symmetric” (password-based) encryption takes place from this point forward because it is much faster than using the public and private keys for everything. These keys were needed to enable the company (and possibly Jason to prove its identity and right to domain.com and to enable Jason and server to generate and securely communicate the unique, shared password.

So, Are there Limitations to This Process?

This all sounds great — what are the down sides? There are a few.

Key Length:

The statement that “only someone with the private key can decrypt something encrypted with the public key” is true so long as the private key cannot be “guessed”. Hackers may try to do this by trying all possible private key combinations or by using tricks which involve knowing something about the communications (e.g. some of the plain text, or many different encryptions of the same unknown plain text, etc.). Older short keys can be broken by trial and error if one has access to significant computer resources and a good amount of time. These days, keys used certificates for SSL are generally 2048 bit or greater to make them safe from such attacks, for a while still.  Similarly, ciphers used for symmetric encryption used in SSL are 128bit or better. There are so many possible passwords with 128bit that it would take significantly longer than the age of the universe to “guess” one.  The real danger is the cipher and not the key length.

Trust:

While use of SSL ensures that your communications cannot be spied on, it comes down to trust to ensure that you are actually communicating with your intended company. This is reflected in the validation of company.com and your trust of the third party organization doing that. Some “secure sites” do not bother to get a third party’s approval and have their keys approved by “themselves”. Others use third parties that are almost free and which spend very little effort in validating the company. In these cases, SSL provides you with no real assurance that you are really talking to your intended company and not some hacker trying to forge their identity to communicate with you in a manner in which you think you are safe.

For defensive use of the web, you should pay attention to warnings generated by SSL when you connect to secure sites. Such warnings include “expired certificates”, “domain name mismatches” — where the domain name presented by the company is different than the one to which you are connecting, and “non trusted certificates” — where the public key (certificate) presented by the company was not validated by a third party that your computer trusts. In all of these cases, you should be wary.

Ciphers:

SSL uses one of a large variety of possible “ciphers” (encryption algorithms) to perform the symmetric encryption.

Use of a poor/weak cipher can result in fast SSL that is easily compromised.  Currently, it is recommended that one use 128-bit or stronger AES encryption as your cipher for SSL in general.  See: 256-bit AES Encryption for SSL and TLS: Maximal Security.  For SSL for web sites, the BEAST attack currently makes use of AES and similar ciphers not ideal; a better alternative currently is RC4.

What Services Can be Protected With SSL?

Almost any Internet service can be protected with SSL. Common ones include WebMail and other secure web sites such as banking sites and corporate sites, MySQL, POP, IMAP, and SMTP. LuxSci provides SSL services to protect your username, password, and communications over all of these and other services.

References

31 Responses to “How Does Secure Socket Layer (SSL or TLS) Work?”

  1. What HIPAA Says about Email Security | LuxSci FYI Says:

    [...] SSL/TLS solutions encrypt the message during transport to and from LuxSci’s servers and your personal computer. [...]

  2. Access Your Calendars var Public iCal Links | LuxSci FYI Says:

    [...] use of SSL (i.e. a link over [...]

  3. Instant Internal Blogs with WebAides | LuxSci FYI Says:

    [...] Blog content via an RSS v2.0 feed.  This feed can be password protected and can be secured over SSL.  You decide if it contains full post content or plain text summaries, and if it contains all [...]

  4. LuxSci Outbound Email: 5 Sending Options Compared! | LuxSci FYI Says:

    [...] for sending email using your choice TLS or SSL for transmission security; this can be forced to only send messages using transport [...]

  5. Dave Hugo Says:

    This is the most understandable explanation of the SSL/TLS exchange process I have seen. Thank you for breaking this down in a way I can actually follow.

    But I do have a question. In the “SSL in Action” section, after the Client receives the company’s public key and decides whether to trust it, you say “If client decides to trust the public key, then Client will send to the company the Client’s public key.” Above that, when using the “envelope” metaphor, the article says: “The client also has secure envelopes that, once sealed, only the client can open.”

    My question is, where does the Client’s public key come from? I connect to secure sites all the time and was never aware that I had a public key, or a public/private key pair. I certainly never generated one knowingly. So that part of the process still seems mysterious.

    Thanks again for the article.

  6. Erik Kangas Says:

    The article was mentioning client-side certificates without discussing how they come into play and then was not stating how the shared password was communicated in the general case where there is no client-side certificate. I have updated that section of the article to remove the confusing text and to add a discussion of how client-side certificates come into play and to be more specific on how the password for the symmetric Cipher is communicated.

    Thanks for pointing out this confusing content!

  7. Dom Says:

    Thanks for the article! I’ve been tasked with creating SSL backup documentation for my company, but I had very little understanding of how it all worked up until now. Your article has cleared things up for me, and allowed me to do my job.

    Thanks again!

  8. nikhil ithape Says:

    u have displayed very important content for ssl.
    i got very important information from this thank u very much for u r service

  9. HIPAA Email Security, SSL & PGP Encryption, Secure Email & Communications | LuxSci FYI Says:

    [...] For more information on SSL, see How Does Secure Socket Layer (SSL) Work? [...]

  10. Secure TLS Email for Bank of America Partners | LuxSci FYI Says:

    [...] email servers must always use TLS (Transport Layer Security) to encrypt all messages that will be delivered to any of Bank of America’s email servers (or [...]

  11. Suranjana Says:

    This is very well explained. A perfect article to start learning SSL. Thanks!!

  12. Web Site Forms or PDF Forms: Pros and Cons | LuxSci FYI Says:

    [...] be secured by an SSL certificate if sensitive data is to be [...]

  13. Secure Web Pages and Secure Web Forms: Steps to Security | LuxSci FYI Says:

    [...] See also : How Does Secure Socket Layer (SSL or TLS) Work? [...]

  14. Does sending email using BCC make it HIPAA Compliant? | LuxSci FYI Says:

    [...] that your email provider supports TLS encryption of email messages that you send, it is possible to determine if individual recipients of yours also [...]

  15. Understanding Email Services: What are they and what do you need? | LuxSci FYI Says:

    [...] services described below) encrypts the communication between your computer and the server using TLS or SSL such that no one can eavesdrop and detect your username, password, or message contents – the [...]

  16. Case for Email Security and SSL, PGP Encryption, SSL, and S/MIME | LuxSci FYI Says:

    [...] » The LuxSci FYI Blog « How Does Secure Socket Layer (SSL or TLS) Work? Understanding Email Services: What are they and what do you need? [...]

  17. MX Logic Enhancements and Branding Changes | LuxSci FYI Says:

    [...] TLS: MX Logic is launching Enforced TLS (Transport Layer Security), which will provide customers with the option to force inbound or outbound delivery of mail via [...]

  18. SecureForm Now Support SMTP TLS for Secure Form Email Delivery | LuxSci FYI Says:

    [...] the emailed form data can be secured using PGP or S/MIME.  This, combined with enforced use of SSL, ensures that the form data is secured from end-to-end … from submission by the end user to [...]

  19. John Belushi Says:

    This is a pretty good article, but you’ve got some incorrect information. For example:
    (i) You state: “They create a public and private key for company.com (this is also known as a “certificate”)”. Not true. The “certificate” does not contain the private key. It contains only the public key of the entity (along with a digital signature of the CA and other useful identifying information).
    (ii) You state: “Once the verification is complete, Thawte gives the company a new public key that has some additional information in it…” Again, not true. You’re confusing the public key with the digital certificate here. A public key has only one corresponding private key. If a “new public key” was issued, the existing private key would no longer work. Thawte would provide company.com with a digitally signed certificate certifying that company.com’s public key (which company.com provided to Thawte) is in fact their public key. There is no need for anyone at Thawte to see company.com’s private key.

  20. Erik Kangas Says:

    Thanks for your comments. However, the terminology here is targeted at the newbie and is thus errors on the side of common parlance versus being explicitly technically accurate. Most people refer to needing an “SSL certificate” or buying an “SSL Certificate” and by this they mean the public key, private key, and even the signing of the public key by the authority. While “certificate” technically means only the signed public key, people generally use it inclusively and thay is why it was used as such here.

    This is the same reason why we state that Thawte gives back a new “public key with more information”. True, the key itself is the same, but the file is modified with more information. For a common, simple description of the process, this gets the point across.

    That you for your clarifications, however.

  21. Is Blackberry HIPAA Compliant? What You Need To Know | LuxSci FYI Says:

    [...] email over POP or IMAP on your Blackberry as long as your email provider supports secure, SSL-enabled POP and IMAP connections, and can ensure that the Blackberry will not be permitted to make insecure [...]

  22. Eitam Doodai Says:

    There is another mistake, It is stated that Thawte’s public key is stored on the computer of the client. This does not mean that the computer can decrypt messages encrypted by Thawte with their private key.

    It may be the other way around, but it’s most surly not like it’s mentioned right now.

  23. Erik Kangas Says:

    Not correct. In public key cryptography, any message encrypted with a private key can be decrypted only with the public key and any message encrypted with the public key can be decrypted only with the private key. Encrypting with the private key allows anyone to open it, but the process of opening it proves it was sent by someone with the private key, and thus validates identity. Encrypting with the public key ensures that only someone with the private one can open it, and thus ensures security (only the recipient can open it).

    Used together, these mechanisms permit validation and prevent eavesdroppng, among other things.

  24. Dan Rogers Says:

    Thanks for the great article!

    Could you please explain the difference between the following two terminologies and if they are related in any way

    1028 – 2048 bit keys
    128 – 256 bit encryption

    i know that the 128 & 256 is the encryption level that the client-server agree on using, what about the term 1024 or 2048, where dose this fit in?

    Thanks

  25. Erik Kangas Says:

    For SSL and other asymmetric encryption systems, there are two keys involved. The key built into the SSL certificate is the asymmetric key. Due to how the math works, the asymmetric keys are easier to break than symmetric encryption keys. As a result, asymmetric keys must be longer (have larger bit lengths, like 1024, 2048, or more).

    The asymmetric key is used together with the asymmetric encryption algorithm during the initial client-server communications. During that phase, identity is checked and verified, etc. Also, because asymmetric encryption is much slower than symmetric encryption, the client and server agree on a symmetric encryption algorithm and new symmetric key to use for the remainder of their communications session. They then switch from asymmetric to symmetric encryption (using something like AES) for the rest of the session. The 128bit or 256bit encryption key is that used for the specific symmetric encryption session.

    So:
    * The 1024+ key is the asymmetric key used for all initial communications over SSL with a specific server.
    * The 128-256 bit key is the symmetric encryption session key used for a single specific session of encrypted communications between client and server. It is negotiated during the start of the session, that communication protected using the asymmetric encryption.
    * Because of the mathematical nature of asymmetric encryption, the key length for asymmetric keys must be much longer than that for symmetric keys to ensure security

  26. Steps for Protecting Your Passwords from Theft | LuxSci FYI Says:

    [...] should always use connections encrypted using SSL or TLS, so no one can eavesdrop on you.  This is especially true in public places, like wifi hot [...]

  27. iPhone Security Apps and Configuration Tips | LuxSci FYI Says:

    [...] your iPhone for general access to email (sending or receiving), be sure that your provider supports SSL or TLS for POP/IMAP/SMTP access.  Without use of  SSL or TLS, your usernames, passwords, and message [...]

  28. Configuring Outlook 2010 for Secure IMAP Access to LuxSci | LuxSci Videos Says:

    [...] you how to configure Microsoft Outlook 2010 to connect to LuxSci using Secure IMAP and Secure SMTP (using SSL) on an alternate port.  For more assistance, please see the Outlook 2010 section of our email [...]

  29. Configuring Thunderbird for Secure IMAP Access to LuxSci | LuxSci Videos Says:

    [...] how to configure Microsoft Outlook 2010 to connect to LuxSci using Secure IMAP and Secure SMTP (using SSL) on an alternate port.  For more assistance, please see the Outlook 2010 section of our email [...]

  30. Configuring Mac Mail for Secure IMAP Access to LuxSci | LuxSci Videos Says:

    [...] shows you how to configure Max Mail to connect to LuxSci using Secure IMAP and Secure SMTP (using SSL) on an alternate port.  For more assistance, please see the Mac Mail section of our email [...]

  31. Configuring Samsung Galaxy S3 for Secure IMAP Access to LuxSci | LuxSci Videos Says:

    [...] you how to configure Samsung Galaxy S3 to connect to LuxSci using Secure IMAP and Secure SMTP (using SSL) on an alternate port.  For more assistance, please see the respective section of our email [...]

Leave a Comment

You must be logged in to post a comment.

TRUSTe EU Safe Harbor Thawte Extended Validation SSL Certificate McAfee Secure Authorize.net Merchant
• Access Anywhere
• Fast and Robust
• Super Secure
• Tons of Features
• Customizable
• Mobile Friendly

Send and receive email from your favorite programs, including:

 Microsoft Outlook
 Mozilla Thunderbird
 Apple Mail
 Windows Mail

... Virtually any program that supports POP, IMAP, or SMTP

Keep your email, contacts, and calendars in sync:

 Apple iPhone and iPad
 Android Devices
 BlackBerry
 Windows Phone

... Any device with Exchange ActiveSync (EAS) support

Relay your server's mail through LuxSci via smarthost:

• Resolve issues with ISP sending limits and restrictions
• Improve deliverability with better IP reputation and IP masking
• Take advantage of Email Archival and HIPAA Compliance
• Even setup smarthosting from Google Apps!

Free web site hosting with any email account:

• Start with up to 10 web sites and MySQL databases
• DNS services for one domain included
• Tons of features and fully HIPAA capable

LuxSci's focus on security and privacy:

• Read The Case for Email Security
• Read Mitigating Security & Privacy Threats
• Review our Privacy Policy

The most accurate, flexible, and trusted filters in the business:

• Premium protection with Intel Security Saas
• Realtime virus database guards against the latest threats
• Seven-day quarantine lets you put eyes on every filtered email
• Supplement with our Basic Spam Filter for even more features

End-to-end secure email encryption — to anyone, from anyone:

• No setup required — encryption is automatic and easy to use
• Secure outbound email with TLS, PGP, S/MIME, or Escrow
• Free inbound encryption via our SecureSend portal
• Independent of your recipient's level of email security
• Widely compatible and fully HIPAA Compliant

Add an extra layer of security with an SSL Certificate:

• Secure your web site
• Debrand LuxSci WebMail with your own secure domain
• Access secure email services via your own secure domain

Encrypt your service traffic via secure tunnel:

• Add another layer of security to your SSL connections
• WebMail, POP, IMAP, SMTP, web/database access
• SecureForm posts, SecureLine Escrow, SecureSend access
• Restrict your account to VPN access only

Secure long-term message archival:

• Immutable, tamperproof email retention with audit trails
• No system requirements — minimal setup, even less upkeep
• Realtime archival of all inbound and outbound messages
• Works anywhere — even with non-LuxSci email hosting

Free data backups included with all email hosting accounts:

• Automatic backups of all email, WebAides, web/database data
• Seven daily backups and up to four weekly backups
• Unlimited restores included at no additional cost
• Custom backup schedules for dedicated servers

Automate your email management:

• Save messages to specific folders or to LuxSci WebAides
• Advanced text scanning with regular expressions
• Tag messages, alter subject lines, or add custom headers
• Filter by message charset, type, TLS status, DKIM status
• Chain filters together for even more complex actions

• Bulk add and edit users, aliases and more
• Control sharing and access globally or on a granular level
• Delegate user roles through permissions
• Configure account-wide taglines, sending restrictions, and more
• Remotely administer account via SOAP API

Share, collaborate, organize, synchronize:

• Calendars, Contacts, Documents, Notes, Widgets, Workspaces
• Fine-grained access control and security
• Access anywhere via secure web portal or smartphone
• Save over solutions like Microsoft Exchange

Free folder sharing for all email hosting accounts:

• Share mail folders with other users in your account
• Subscribe to only the folders you want to see
• Set read-only or read-write access control
• View all personal and shared folders via unified web interface

Color code and label your email messages:

• Define and assign multiple IMAP keywords to each message
• Filter, search, and sort by tags
• Compatible and synchronizes with any IMAP email client
• Also usable with WebAide entries