" tls Archives - Page 5 of 10 - LuxSci

Posts Tagged ‘tls’

Neutralizing and protecting against rogue TLS certificates in the wild

Thursday, August 17th, 2017

Techniques for fighting mis-issuance of TLS certificates

The web has reached the tipping point where encrypted traffic – connections protected by HTTPS, which is HTTP over SSL/TLS – has overtaken unencrypted (HTTP) traffic. There are many reasons for this change, variously called HTTPS Everywhere or Always-On SSL, which we described in a previous FYI blog post. While this move certainly improves the security and privacy of interactions on the web, there still remains the Achilles’ heel of this ecosystem – the problem of mis-issuance of cryptographically legitimate certificates to rogue site operators. This blog post describes recent steps taken to guard against such occurrences, using techniques which can raise the necessary alarms before much harm propagates.

The Achilles’ heel of internet security is the mis-issuance of cryptographically legitimate certificates to rogue site operators.

 

SSL and TLS Certificates

The entire edifice of SSL/TLS-based security rests on certificates issued to the legitimate operators of websites, so that browser indicators (the secure lock icon, for example) based on various cryptographic checks can reassure users that they are communicating with their intended destination. Mis-issued certificates, whether available through lax procedures at a certificate authority (CA) or by a malignant act, removes that critical trust. A browser’s cryptographic checks cannot distinguish a duly-vetted legitimate server from a man-in-the-middle that has improperly obtained a cryptographically valid certificate. The latter might arise owing to the (mis)placed trust in a compromised root CA embedded in the browser or one issued by a corrupted intermediate CA that is in a legitimate chain of trusted certificates.  This is, for example, why Google is reducing trust in SSL certificates issued by Symantec and why even Microsoft is the latest and last browser vendor to no longer going to trust anything issued by the WoSign/StartCom certificate authorities.

Some CAs make mistakes and fix them; some have a habit not well controlling certificate issuance.  This seriously damages our trust in a secure internet.

Read the rest of this post »

Why Choose OV TLS Certificates? The dilemma of the middle child

Wednesday, August 9th, 2017

Choosing amongst the different certificate types

Imagine three brothers. The youngest is nimble, outgoing, and popular. He’s also growing very rapidly and will soon be the tallest in the family. The oldest is steady, thoughtful, and circumspect. He’s a high achiever, in a job with lots of responsibilities and makes loads of money. But what about the middle sibling? The classic middle child syndrome would have him struggling to find his niche between these two exemplars.

It’s much the same (as far as analogies go) with the three types of SSL/TLS certificates – Domain Validation (DV), Organization Validation (OV) and Extended Validation (EV) – available for use in the internet security ecosystem.

TLS Certificate Validity

First, just like siblings, all three share the same genes. That is, from a cryptographic point of view, all three certificates provide exactly the same level of confidentiality and integrity protection of the communications channel by using standard security technologies (private/public keys, cipher suites, encryption algorithms, etc.) in exactly the same way using SSL/TLS. The difference, as with siblings, is how they interact with their environment and take advantage of the opportunities presented to create and project their public persona. The choice of a certificate type for a website aims at projecting a particular image of its trustworthiness and dependability.  Is the site trustworthy enough to interact with for the purposes the end user has in mind?     

Read the rest of this post »

What’s the latest with HTTPS and SSL/TLS Certificates?

Wednesday, August 2nd, 2017

We’ve written quite a lot in past FYI Blog posts about SSL/TLS certificates, the critical building block to secure communication on the Internet. We described what such certificates were, their use in securing the communications channel between a client (browser) and a server, different types of certificates and the pros and cons of using each.

Given the changes in the Internet landscape over the past five years, we feel it is time to revisit these topics. The technical details described in the earlier posts remain unchanged. What has changed, though, are the traffic patterns for HTTPS-based communications, additional vulnerabilities arising as a consequence and ways to mitigate these. This post will provide a general overview of certain changes in the Internet landscape over the past few years, while subsequent blog posts will describe some of the topics identified here in greater detail.SSL TLS Certificates

Read the rest of this post »

Email Encryption Options: SMTP TLS vs PGP vs S/MIME vs Portal Pickup

Monday, May 29th, 2017

While messaging apps may have become more popular over the last ten or so years, email remains an essential method of communication, particularly for businesses. Despite its widespread use, there are many security problems associated with regular email:

Message Tampering

False messages are a significant threat, particularly regarding business and legal issues. Imagine someone else sends an email from your account – how can you prove it wasn’t you? Many viruses spread in this way, and with regular email, there is no concrete way to tell whether a message is false or not.

Email Encryption

Regular emails can also be modified by anyone with system-administrator access to the SMTP servers that your emails pass through. They can alter or completely delete the message, and the recipient has no way of knowing if the message has been tampered with or not.

In the same way, messages can be saved by the SMTP system administrator, then altered and sent again at a later time. This means that subsequent messages may appear valid, even if they are just copies that have been faked.

Repudiation

On the other side, there is message repudiation. As we have just discussed, emails can be faked. If you receive a message, how can you prove that it is legitimate? The sender can try to claim that it was a false message, and it can be challenging to deduce who is telling the truth.

Eavesdropping

In a world where governments and hackers continue to develop powerful tools, eavesdropping is incredibly easy against unsecured email. Snoopers can capture and read emails traveling through the network, allowing them to look through your secrets.

Privacy Invasion

Emails transmitted over SMTP can reveal important information, such as IP addresses and locations. IMAP, POP, and WebMail don’t reveal IP addresses, but there are other privacy issues to consider when using these forms of unsecured email.

Unprotected Backups

Unencrypted messages are stored in plaintext on SMTP servers. Any backups will also be in plaintext, so anyone accessing these backups can also read messages. One of the most significant issues is that these unprotected backups can be kept around for years, even after email accounts are deleted.

Identity Theft

Hackers can capture login details if email servers aren’t accessed over an encrypted connection. They can then use these to access email accounts, read messages and even send new ones while impersonating the administrator. Identity theft can devastate your professional and personal life, making it one of the key reasons to consider using encrypted email.

Fight the Threats to Email with Encryption Options

Each of these possible abuses poses a significant threat. To protect yourself and your business, it’s essential to implement an adequate email encryption strategy. Several significant types of email encryption exist, including SMTP TLS, PGP, S/MIME, and Portal Pickup. Each has its advantages and disadvantages, including the level of security, ease of use, and compatibility. No single option is suitable for all situations, so you need to consider each option carefully to find out which is right for your individual use case.

SMTP TLS

Simple Mail Transport Protocol (SMTP) is the protocol under which computers and servers transport emails from the origin to the destination. Transport Layer Security (TLS) is the encryption protocol that provides secure connections for much of the internet (such as HTTPS websites).

Together, these technologies provide an encrypted tunnel for both inbound and outbound email traffic. The messages are encrypted as they travel, which prevents spoofing between the servers. It is an easy form of encryption to use, but it is not quite as secure as PGP or S/MIME.

How Does SMTP TLS Work?

SMTP TLS relies on hashing algorithms for endpoint authentication, which are generally orchestrated by your email provider using SSL certificates. Certificate Authorities are trusted third parties that do the necessary checks to ensure that they only grant certificates to those who have the right to them.

This type of email encryption uses both asymmetric and symmetric-key encryption techniques. The server proves its authenticity with its private key, which lets you know that you aren’t facing a man-in-the-middle attack. Then the server is sent the public key, which it uses to generate and return a key to you. This shared key enables secure communications through symmetric-key encryption, which is faster than asymmetric encryption.

When both the sending and receiving servers support opportunistic TLS, they negotiate a TLS-encrypted connection to transmit emails. This allows for secure delivery from server to server. While this is great, not all email providers support opportunistic TLS. Messages will be sent in an insecure fashion if they travel over servers that do not support TLS, if they are stored, or if there is a failure in the security setup. Despite this, TLS protects the login details, which can help to keep them safe from identity theft.

LuxSci supports Forced TLS, which can prevent an email from being delivered unless TLS is functioning between the servers. If the recipient server does not support opportunistic TLS, a different form of encryption can be used instead.

TLS is simple to set up and use. In most email clients, only a few settings must be changed for implementation. One of the other significant benefits of TLS is that the recipients don’t need to personally set anything special up, which gives it more versatility than rivals such as PGP or S/MIME. As is often the case with technologies that are easy to use, it does not secure the email to the same degree as its rivals.

PGP

While the name Pretty Good Privacy might not seem so inspiring, PGP has been relied on for email encryption since 1991. It uses public and private-key encryption to offer a high degree of security. However, its difficulty can often lead to user errors that can potentially expose confidential messages. Current versions are considered secure when used correctly, but earlier versions were shown to have some theoretical vulnerabilities.

PGP has been around for a long time and has a broad user base. This makes it a helpful protocol, even though it is not compatible with other protocols, and your recipient will also need to set up PGP.

There are both open source and commercial options available, and they can be used with most email accounts. You can download the free GNU Privacy Guard (GPG) to start with PGP.

How Does PGP Work?

PGP allows you to generate a public and private key pair, which turn plaintext into ciphertext. The public key is used to encrypt a message, so you first need to find the key of your recipient. These can be found on public key exchanges, or you can ask for them through standard email. Once you have their public key, you use it to encrypt the text you want to send. Once encrypted, it can only be decrypted with the recipient’s private key.

When someone wants to send you an encrypted message, they first need to encrypt it with your public key. Once you receive the encrypted message, you can use your private key to revert the ciphertext into plaintext.

What Are Digital Signatures?

PGP also allows users to sign their messages with digital signatures, which can be used to prove that the message is authentic and hasn’t been tampered with. Anyone can use the sender’s public key to verify that the message has not been altered. If the message has been changed, the signature will not be valid.

Web of Trust

For emails to be secure, it is essential to trust that recipients are who they say they are. Traditionally PGP has handled this through the web of trust. Public keys are distributed through identity certificates, vetted by other users who confirm the association between the key and the individual.

This system has some advantages over hierarchical systems such as the one used in S/MIME, although it also burdens users to verify the certificates. Because of this, a system of trust signatures that operates similarly to Certificate Authorities has also been developed.

Problems with PGP

Despite the high level of security when PGP is appropriately used, there are also several negatives. One of the biggest stumbling blocks is its complexity of use, which can send messages insecurely. This is particularly problematic for new users. Another issue is that it does not integrate seamlessly with email clients.

Adding to these problems is the fact that it is not compatible with other protocols. For messages to be sent and received with PGP encryption, both the sender and recipient must use the PGP protocol. The public key of the recipient also needs to be known beforehand. If it is not readily available on a key exchange, it can make it more challenging to get in touch with them securely.

Getting the Most Out of PGP

While PGP is an excellent technology for encrypting the body of a message, it does not encrypt the metadata or the headers (including the sender, recipients, and subject). If you only use PGP, snoopers can glean a lot of information from email exchanges. You can protect your login details, headers, and metadata using PGP combined with TLS.

S/MIME

Secure/Multipurpose Internet Mail Extensions (S/MIME) is another encryption standard similar to PGP. However, some aspects make it easier to use. S/MIME can’t be used with other protocols, but it is integrated into most email clients. All you need to do is acquire a certificate and adjust your settings.

Certificate Authorities

One of the critical differences between PGP and S/MIME is that instead of using the web of trust to confirm the validity of a user’s email and certificate, it relies on Certificate Authorities (CAs) who issue S/MIME certificates, instead. These organizations provide oversight, but users still need to be able to trust the CAs for the system to work.

There are two classes of certificates. Class 1 certificates only declare that the sender owns the email address to that you received the message. Class 2 requires a more detailed verification from the CA, which connects the sender’s identity to the email. Certificates typically last one year and can be stored on your computer or a smartcard. When a user acquires a certificate, they receive public and private keys that work the same way as PGP keys.

How Does S/MIME Work?

Once you have your certificate, you may need to import it into your email client. Most clients that detect a certificate will have a menu option that allows you to encrypt and sign messages whenever you compose them.

When sending and receiving messages, the encryption works similarly to PGP in that the sender’s email client encrypts them with the public key, and the recipient decrypts them with their private key. An encrypted message will open normally if the private key has already been entered into the email client. If it hasn’t, it will appear as cipher text.

S/MIME digital signing also works similarly to PGP. It proves the sender’s authenticity and that the message has not been altered. You can only send someone an encrypted email if you already have their certificate, but you can send them a digitally-signed message without it. You can send your public key to a recipient with a signed email, and they can do the same. This allows you to exchange encrypted messages.

Issues with S/MIME

Like all forms of email encryption, S/MIME also has some drawbacks. Despite its ease of use with email clients, it is best not to use it with WebMail. This is because best security practices recommend keeping your private key away from WebMail’s server (this best practice applies equally to PGP).

CAs also bring problems to S/MIME. For the system to work, you have to be able to trust them. In the past, there have been issues that have made users question the integrity of specific CAs, so some may not want to involve a central authority in their encryption process.

Another hassle is that certificates expire, typically after one year. If a certificate is lost or deleted, it means that messages that were encrypted with its key cannot be decrypted.

Getting the Most Out of S/MIME

Like with PGP, S/MIME only encrypts the body of a message rather than the metadata or headers. For a higher level of security, it is also best to use TLS. This will protect your metadata, headers, and your login details.

Portal Pickup

Portal Pickup, also known as Secure Message Pickup or Escrow, is one of the easiest ways to send encrypted messages. It does not require (but may include options for) authentication or registration, which is a considerable strength from a usability perspective.

It is universally compatible, so anyone with an email address can receive these messages without additional software. This makes it useful for securely sending email messages to people you have not previously communicated with.

How Does Portal Pickup Work?

The sender goes to a third party’s (such as LuxSci’s SecureLine) service over a secure connection. The third-party validates the sender and enables them to create their message. The sender chooses how the recipient will verify their identity from various options. These can include login credentials, a security question, or a password.

The third party then encrypts the message before storing it on its server. It sends an email to the recipient containing a secure link to the portal and a unique password that is part of the encryption key. The third-party deletes this password, so the message cannot be decrypted until the recipient enters the password.

The recipient receives the email from the third party, then uses the link to connect to the web portal. They then verify their identity according to the sender’s specifications and enter the password. This allows the third party to decrypt the message so the recipient can read it.

Benefits of Portal Pickup

The main advantages of Portal Pickup are that it is relatively easy for both the sender and recipient, and it can be delivered to anyone with an email address. The messages are also hosted on a secure portal rather than sent over the internet. They are encrypted at storage and kept until they are deleted by the recipient, retracted by the sender, or expired. Access to the message can also be logged, so it is possible to see if and when it has been viewed.

Problems with Portal Pickup

One of the potential vulnerabilities of Portal Pickup is that it requires trust in a third party. If you are using an unreliable service, there could be significant security issues. The system is secure and straightforward to use if the provider is trustworthy.

Other Email Encryption Options

Internet users should be cautious of other forms of email encryption, particularly if they use major WebMail services. While parts of the journey will be encrypted, your carrier is unlikely to offer end-to-end encryption that keeps your communications completely secure.

One of the main reasons for this is that these companies often make money from data mining. If they were to encrypt your emails from end-to-end, they wouldn’t be able to capture and sell your data. Another worry is that government agencies can lean on these companies to provide data for criminal or other cases.

Which Email Encryption Option Is Right for You?

Each email encryption option has its advantages and disadvantages, depending on how you intend to use them. While SMTP TLS offers transparent encryption, it only does so part of the way. PGP and S/MIME also leave gaps in their security, so those with a high-risk level are often better off combining these technologies.

PGP can be difficult to use but is also the most flexible. For this reason, it is generally recommended for more advanced users because small mistakes can have enormous ramifications for the privacy of your communications. S/MIME is easier to set up and use, but it involves having to put your faith in Certificate Authorities, which some users may not want to do. Portal pickup is excellent because it is relatively easy and can be sent to anyone, but it also involves trusting a third party.

To find the right email encryption strategy for your business or personal use, you first need to think about your use cases and your technical abilities. While standard email is insecure and shouldn’t be used for sensitive or high-value communications, these technologies can only protect you if used properly.

What is really protected by SSL and TLS?

Saturday, April 8th, 2017

This question came in via Ask Erik:

Hi Erik,

I stumbled upon your blog while trying to learn a little about SSL/TLS in the context of client/server e-mail sessions, i.e. not web mail which I understand to be an HTTP session.  I am just an ordinary user with no special security needs but I find all this news about corporate and government surveillance to be troubling for both philosophical and practical reasons.  In any case my questions is quite simple.

My e-mail client, apple mail, and my e-mail service provider both support SSL so my e-mail exchanges between my computer and the server are encrypted.  I understand that I can’t control what happens with other e-mail servers.  What I am trying to understand is what does it mean to be encrypted?  When an e-mail leaves my computer how much of the message is encrypted?   Are the e-mail headers encrypted including the sender and recipient e-mail addresses.  I would assume so but nobody talks about the details.  What metadata trail does a user leave when using SSL/TLS.  Is it is as simple as the destination and sending IP address with everything else encrypted?  Reading Data and Goliath right now by Bruce Schneider which talks about a lot of this stuff but again doesn’t give quite enough detail.  At the end of the day I am trying to understand how much protection SSL really provides.

SSL (now TLS) protects data as it travels across the Internet. To understand in detail how SSL works, we recommend reading: How does Secure Socket Layer (SSL andTLS) work?  However, looking at how the protocol works can leave answers to some of these fundamental questions a little unclear.  Lets address them one by one.

SSL and TLS Security

Read the rest of this post »