Author: Mason Moody

What is DROWN: A Vulnerability That Can Imperil Your Encrypted Traffic

Mason Moody March 3, 2016 by under Cloud Hosting 0 Comments

On 1 March 2016, security researchers announced a new vulnerability exploit involving an old security protocol, SSLv2, that affects up to 33% of web servers. Even web servers that do not allow SSLv2 connections might be vulnerable if the RSA private key used on the server is reused on other servers. And, as seems to be de rigueur for major vulnerabilities nowadays, it comes with a simple and foreboding name: DROWN (which is admittedly much easier to remember and reference than its official designation of CVE-2016-0800).
.

How DROWN Works

DROWN imageDROWN (Decrypting RSA using Obsolete and Weakened eNcryption) requires an attacker only have access or ability to sniff network traffic and the ability to query a vulnerable server.

An example scenario would involve an attacker in a Man in the Middle (MitM) position and able to see a client initiate a TLS connection to a web server to establish a secure HTTPS session. The attacker copies this encrypted session, including the encryption negotiation that starts it. The attacker then takes the initial key negotiation and runs a variant of an old attack on SSLv2 connections known as the Bleichenbacher attack (or, the million message attack) on another server that is willing to use SSLv2 and which uses the same RSA private key as the original server. Because of the way that SSLv2 handles session key generation, this attack could allow an attacker to exploit the weaknesses of SSLv2 (which has been considered obsolete and insecure for almost 20 years now) to gain the keys negotiated over the more secure TLS connection.

The researchers were able to “decrypt a TLS 1.2 handshake using 2048-bit RSA in under 8 hours using Amazon EC2, at a cost of $440.” By exploiting a recently patched (in March 2015) vulnerability in OpenSSL, they duplicated similar results “in one minute on a single CPU”.
.

Am I Affected?

The researchers who discovered this exploitation have an online tool that can let you know if your domain or IP is vulnerable. This tool presents positive results culled from scans they performed over February 2016, so it doesn’t represent real-time data. If you’ve recently updated your OpenSSL version or recently made changes that could address vulnerability to DROWN, you could use the scanner utility they have put together to help you verify your exposure.
.

Mitigating Exposure to DROWN

Since SSLv2 is the primary vector for this attack, removing that protocol as an option during any secure connection negotiation is the first step. Consult with the documentation for your applications that use SSL/TLS for the specific configuration settings that disable SSLv2 (and SSLv3, for that matter). Affected applications can include web servers (Apache, Nginx, etc.), mail servers (Postfix, e.g.), and any connection-oriented services, especially anything using the OpenSSL library.

In addition, OpenSSL users should upgrade their OpenSSL to version 1.0.2g or 1.0.1s, depending on whether you are using version 1.0.2 or 1.0.1, respectively. Some earlier versions of OpenSSL may still allow for exploitation of this attack via the use of weak export ciphers even if they are explicitly disabled, so where possible, upgrade is your best option–these versions also contain patches that address other vulnerabilities unrelated to DROWN.

Finally, a more reliable fix would be to use a unique private key on each server that needs to run TLS. With certain certificates, particularly OV and EV certificates, this option does incur additional cost and may be viable to all deployments or situations.
.
.


What is: glibc (GNU C Library) Vulnerability (CVE-2015-7547) Patch and Information

On Tuesday, 16 February 2016, Google security researchers Fermin J. Serna and Kevin Stadmeyer announced the discovery of a vulnerability in the GNU C library (called “glibc” or “libc6”, depending on the specific platform) that underlies many Unix/Linux systems. Similar to the GHOST vulnerability, exploitation of this vulnerability involves a buffer overflow that can cause a system crash or allow an attacker to remotely execute malicious code.

How It Works

When the Google researchers reported the vulnerability to the C library maintainers, they discovered that the bug had previously been reported in July 2015 (hence its 2015 CVE number). Red Hat researchers had been working quietly to understand the full extent of this issue, and they presumably, in conjunction with the Google researchers, waited until they had an effective patch in place before making their announcement public.

In short, this exploit leaves any Linux based cloud server that uses glibc and performs domain name lookups potentially vulnerable to attack. Specifically, the proof-of-concept the researchers have demonstrated employs specially crafted packets that cause the getaddrinfo() function to mishandle certain memory buffers, triggering a buffer overflow (a commonly used tactic among those who look for vulnerabilities to exploit). The publicly available proof-of-concept causes a server to crash; the researchers have withheld the proof-of-concept code that would allow for remote code execution.

Since so many server functions utilize the affected library–including sudo, curl, and ssh, to name a few–patching glibc is the safest path to protect your servers from this sort of exploit. While there is no evidence of this vulnerability being exploited in the wild, any server running version 2.9 or later of glibc should be updated to the patched version as soon as possible (if you are running a version of the C library older than 2.9, your best bet is still to upgrade to address any of the other known vulnerabilities that the intervening upgrades have patched).

How To Identify Your Version of glibc

You can identify your currently running version of the C library you are using on the command line with the following command:

ldd --version

 

Example of output from `ldd --version`

Example of output from `ldd –version`

Patched glibc Versions

Most repositories now have patched versions of the library available through their respective package managers, including the following (likely non-exhaustive) list:

  • CentOS 6: glibc-2.12-1.166.el6_7.7
  • CentOS 7: glibc-2.17-106.el7_2.4
  • Ubuntu 15.10: libc6 2.21-0ubuntu4.1
  • Ubuntu 14.04 LTS: libc6 2.19-0ubuntu6.7
  • Ubuntu 12.04 LTS: libc6 2.15-0ubuntu10.13
  • Debian 6: libc6 2.11.3-4+deb6u11
  • Debian 7: libc6 2.13-38+deb7u10
  • Debian 8: libc6 2.19-18+deb8u3
  • Debian Sid (unstable): libc6 2.21-8
  • Arch Linux: glibc-2.23-1

How To Update the glibc Vulnerability

The simplest way to update will be through your respective package managers.

CentOS/RedHat:

sudo yum update glibc

Ubuntu:

sudo apt-get install libc6

Debian:

sudo apt-get install libc6

Arch:

sudo pacman -S "glibc>=2.23"

Once you install the updated version, you will need to restart each service that uses the C library to ensure they are using the patched version. Your safest bet is to schedule a reboot of your cloud server.

Update (2016-02-18): Edited the Debian package names to correct the name of the C library package from “eglibc” to “libc6”.

Update (2016-02-24): Added the patched glibc version for Arch Linux along with update instructions.

About Atlantic.Net

Atlantic.Net offers top-tier managed hosting services, including HIPAA-compliant cloud hosting.


What Is the Logjam Vulnerability?

Mason Moody May 22, 2015 by under Cloud Hosting 0 Comments
The Logjam Vulnerability

Photo: Sharon Mollerus / licensed under CC BY 2.0

Overview of Logjam

On May 20, 2015, a team of researchers announced a new vulnerability in the protocol that allows web servers to establish secure (HTTPS) connections to web browsers. Calling this exploit the Logjam Attack, the team, made up of computer scientists and security specialists from multiple universities and technology companies, demonstrated how it is possible for a man-in-the-middle attacker to downgrade a vulnerable TLS connection to use an encryption cipher which is “relatively easily” broken. This attack is the latest in a series of cipher downgrade attacks, such as FREAK and POODLE, that target implementations of the HTTPS protocol.

SSL/TLS Overview

To understand how this attack works, it might be helpful to review how TLS (Transport Layer Security, though this protocol is often still referenced by its predecessor’s initialism, SSL, Secure Sockets Layer) protects an HTTPS connection. When a web browser requests a webpage via an HTTPS connection, the host server will first offer its certificate to authenticate its identity, which uses the asymmetric cryptography within the public key infrastructure. Once authenticated, the server then enters into a negotiation with the client browser over which cipher suite they will use for the connection. In most cases, they will use the strongest cipher suite they are able to agree upon. When they determine the encryption algorithm, they then negotiate their shared secret key via a process called the Diffie-Hellman Key Exchange.

Diffie-Hellman Key Exchange

The Diffie-Hellman Key Exchange allows for the secure generation of a new shared key between parties to happen over an insecure medium. The larger the bit-length of the Diffie-Hellman group, the more resilient it is to being cracked by a brute force attack. Groups of 1024 bits are in wide use, though the researchers who discovered the Logjam vulnerability posit that it is within the reach of state-sponsored actors to crack encryption of this strength. The Logjam vulnerability is exploited by forcing the two parties to downgrade the Diffie-Hellman group to a 512-bit group, which can be cracked in minutes.

How Concerned Should We Be?

Exploiting the Logjam vulnerability requires an attacker to be able to occupy a man-in-the-middle position. In other words, an attacker would need to be able to access the same network as the client, server, or any ISP in between. This access, which includes most wired connections, is generally walled off from most garden-variety snoopers. If you access the Internet via an open public wi-fi access point, then you might have cause for concern, whether from an exploit of this vulnerability or a host of others. In that case, your best bet is to utilize a VPN (if you are concerned about security, then this a prudent strategy in any case).

If an attacker is able to pull off this exploit, it’s only the first step. It still requires that attacker to have access to a device with significant computational power to successfully decrypt any intercepted and downgraded encrypted traffic. As such, it’s not the simplest trick to execute, so it’s probably not a vulnerability that one should lose too much sleep over. However, a vulnerability is a vulnerability, so the sooner patched, the sooner you can knock it off the list of things to worry about.

What To Do To Protect Yourself

As of the release of the news of this discovery, only the latest version of Internet Explorer has been patched for this exploit (it should be noted that one of the researchers on this team works for Microsoft Research). Mozilla, Google, and Apple have announced that they are working on patches for their respective browsers, Firefox, Chrome, and Safari. When those patches are released, you should update your browser to those versions to enable protection from this vulnerability. In the meantime, though, if you are concerned about your exposure to this sort of attack, you might want to stick to IE for your secure browsing.

If you administer a web or email server, you can mitigate your vulnerability by removing from your cloud server the list of cipher suites export suites (old, intentionally weakened ciphers that were once the only encryption technology allowed to be exported outside the United States). The group who discovered this exploit also recommend the usage of Elliptic Curve Diffie-Hellman, Ephemeral (ECDHE) as preferred ciphers for their resilience to all known cryptographic attacks. See their site where you can test your server and get guidance on how to make these configuration changes.

Atlantic.Net’s world class cloud hosting solutions and technical staff work around the clock making sure that our customers data is secure and private.   Please feel free to contact our staff and check our community and blog pages for any further updates.


What is Shared Key Exchange (How VPNs Work, Part 3)

Mason Moody May 20, 2015 by under VMware Hosting 0 Comments

This article in the “How VPNs Work” series describes how a shared key exchange works. If you’re already lost, don’t panic! This series of articles is written to explain the concepts and methods behind VPNs without requiring a deep dive into the mathematics that powers them.

If you’re completely new to the concept of VPNs, check out this introduction. If you already know a little about the how VPNs work and want to know a little more, this series is for you. Each article addresses one aspect of the means by which a VPN helps to secure data by telling a story which serves as a metaphor of the logical mechanisms involved. These stories involve two people, Adam and Burt, trying to keep a secret and a third person, Cesar, trying to nefariously discover their secret. Since VPNs have no perfect physical world equivalent, there may be some elements that stretch the bounds of credibility (for example, Cesar has access to a duplicator ray). Remember, it’s just a story…

Each article also has expandable sections (indicated with the gear icon) which contain a slightly more in-depth explanation that is somewhat more technical but still avoids getting too lost in the mathematics. These sections tie the events of the story a little more to the components or steps of encryption or authentication but are not required to get a basic understanding of the topic.

Shared Key Exchange

Shared Key ExchangeIn earlier adventures, our friends Adam and Burt have tried to keep their comic book project secret from Cesar’s snooping by securing the messages they exchange with a shared key and a more elaborate public-/private-key pair system. Each system has its strengths and weaknesses. But the boys need a break from this project, and lucky for them, there’s a fair going on nearby. They enter the chili cook-off, and, because they love keeping their creations secret, they devise a way of keeping their recipe secret, even as they prepare it in front of onlookers. In fact, the recipe will be so secure, even they won’t know it!

A Well-Known Starting Point

To pull this feat off, Adam and Burt will each need to come up with a portion of the recipe without knowing anything about what the other has contributed. If neither of them knows the whole recipe, neither can reveal it. They do, though, agree on a common base of ingredients (a mixture of tomato base, chili seasoning, beef, and beans). There’s no need to keep this part secret–most of the other contestants start with a similar base, so they gain little in spending the effort to obscure these ingredients.

The fact that the two parties can start with this negotiation over an insecure, public medium is one of the core and clever ideas behind this method of initiating encryption. Before any encryption can occur, there needs to be some unencrypted traffic between peers, otherwise, neither will know how to decrypt any future messages. This initial step lets one host tell another that it wishes to begin a negotiation of an encryption method by offering a couple of initial values to a well-known mathematical formula (which, in this example, is the base of the chili). The real magic comes in the next steps.

 

Seeding the Key

Diffie-Hellman key exchange startAdam and Burt have independently and secretly prepared a portion of seasoning and additional ingredients sealed in an opaque, rice-paper pouch that will dissolve once immersed in the chili. In this cook-off, Adam’s pouch contains tomatillos, chipotles, cayenne pepper, and cinnamon; Burt’s contains Cajun seasoning, beer, cumin, oregano, and Worcester sauce*. Adam tosses his packet into his pot and stirs, tasting his chili until he is sure the pouch has dissolved and released its ingredients. Burt does the same with his pot. At this point, Adam and Burt have two different chilis.

* (in case you are wondering why this isn’t already dissolving from the beer, let’s say that Burt has pre-frozen any liquids prior to placing them in the dissolvable pouch.)

 

In the actual key exchange process, these “ingredients” are actually very large prime numbers. In the key-exchange process, these large prime numbers are randomly generated. The larger the numbers used to input into this key exchange, the more difficult it is to use brute-force techniques to crack. The size of these numbers is called a bit group. A group of prime numbers of the same length in binary bits (e.g., 1024 or 2048 or even larger bit lengths) all belong to the same group. The larger the bit group, the more robust this key exchange process becomes and the more resistant it becomes to analysis and potential compromise.

 

Completing the Exchange

Diffie-Hellman key exchange completionNow they switch the pots they are tending to, so Burt is at the pot Adam started, and vice versa. They each take another pouch identical to the one they started with and add this second pouch to the pot that the other had started (so Adam adds his tomatillos, chipotles, cayenne pepper, and cinammon to the pot Burt started with the Cajun seasoning, beer, cumin, oregano, and Worcester sauce; and Burt adds his pouch to the pot Adam started). After each of them stirs their respective pots and dissolves the pouches to release the secret ingredients, they can be sure that each pot now contains identical chilis.

In mathematical terms, the algorithm governing shared key exchange is commutative–it can be performed in any order and get to the same result. Also, note that neither Adam nor Burt have the means to reconstruct the key alone. Each of them only know the random value each contributed to the algorithm. And, since each also generates a copy of the key upon completion of the negotiation, each also has a copy of the final key without its having had been transmitted over a network.

This shared key exchange or negotiation is called the Diffie-Hellman Key Exchange, named for the authors of the paper that first detailed this method, Whitfield Diffie and Martin Hellman. Their work built upon previous work done by Ralph Merkle, so it has been suggested (by Hellman himself) this method be called the Diffie-Hellman-Merkle Key Exchange. In actual configurations, you will often see this method applied as DH Groups, different groups corresponding to keys of different lengths in binary bits.

 

Complex Tastes

During the preparation, any of the judges could have seen and sampled from the starting pots or the intermediate pots. Even if Cesar, intent on learning the secret recipe, poses as a judge, he wouldn’t be able to reliably reconstruct the final recipe Adam and Burt used. (This example assumes that Cesar doesn’t have the ability to distinguish all the individual flavors included in the chili and that to attempt to identify the ingredients and their amounts via laboratory analysis would be expensive enough in time and energy invested to make it infeasible.)

If an attacker wanted to compromise any communication encrypted with this key, a typical man-in-the-middle eavesdropping attack would be insufficient. An attacker could, however, insert himself as a transit man-in-the-middle. If an attacker set himself up so that all communication between the two hosts had to go through him, he could perform a Diffie-Hellman negotiation with each peer. Each side of the connection would only know whether a successful key is negotiated, but not with whom. In this position, the man-in-the-middle would be able to see the whole conversation–in fact, he’d have to decrypt incoming traffic and re-encrypt it before sending it out the other side to maintain the impression that each end still has its “secure” connection.

It’s also possible for an attacker to attempt to stage a man-in-the-middle attack to downgrade the DH group to a group whose bit length is much smaller and less secure. That attacker could then collect the weakly encrypted data and perform an offline brute force attack against the encryption to crack it in a reasonable amount of time. Attacks such as FREAK and Logjam use some sort of downgrade methodology to weaken the Diffie-Hellman key exchange.

 

More in the How VPNs Work Series:

Part 1: Symmetrical Encryption Algorithms
Part 2: Public Key Cryptography
Learn more about services from Atlantic.Net, including VMware hosting.


What Is the VENOM Security Vulnerability?

Mason Moody May 14, 2015 by under Cloud Hosting 0 Comments

Overview

What Is a VENOM?On May 13, 2015, security researcher Jason Geffner of CrowdStrike publicly disclosed a vulnerability in some virtualization platforms that could allow an attacker to jump out of the sandbox of a virtual machine (VM) and gain access to the protected virtualization host. The vulnerability has been christened “VENOM”, for Virtualized Environment Neglected Operations Manipulation (CVE-2015-345) and affects any unpatched virtualization host built on the open source QEMU emulator, including Xen, KVM, and Oracle’s VirtualBox. Technologies that don’t employ QEMU, such as VMWare, Microsoft’s Hyper-V, and Bochs, are unaffected.

Virtualization Primer

Virtualization, in broad terms, is a technology implementation which allows one large computer to subdivide its resources (processor, memory, hard drive space, e.g.) to run many smaller, virtual computers. Each of these VMs runs as though it is a discrete system, isolated from the other VMs running on the same host. This architecture allows server operators to more easily manage and deploy servers, since they can create a new VM in much less time than it would take to build out a physical version. It also allows data center operators and hosting providers to make more efficient use of their resources. A virtualization host running, for example, 10 VMs uses a fraction of the space, power, and cooling that 10 equivalent physical machines use.

What Can an Exploit Against VENOM Do?

One of the other benefits of a virtualization platform is the ability to segregate VMs. So, even though they may use the same shared hardware, the VMs are isolated. Such isolation allows a server administrator to provision different VMs, running different operating systems, for different customers. Those customers would never know that they were sharing resources on a virtualization host with other customers. And even if they had root or administrator privileges on their VMs, the containment prevents them from doing anything that would affect any other VM.

This siloed infrastructure concept is what makes the idea of a vulnerability like VENOM so concerning. As Geffner describes on the CrowdStrike website:

This vulnerability may allow an attacker to escape from the confines of an affected virtual machine (VM) guest and potentially obtain code-execution access to the host. Absent mitigation, this VM escape could open access to the host system and all other VMs running on that host, potentially giving adversaries significant elevated access to the host’s local network and adjacent systems.

For a provider who has relied on the security of VM isolation, such a vulnerability can cause quite a bit of alarm.

How Much Alarm?

While the announcement of this vulnerability has been compared, in some media outlets, to Heartbleed, it’s important to weigh what is known against what is possible and probable.

According to Geffner, the “VENOM vulnerability has existed since 2004”, though no known exploit (as of this writing) has been documented in the wild. Geffner shared his findings with the major virtualization vendors who utilize QEMU on April 20, 2015. Once a patch was developed, he published his findings on the CrowdStrike website on May 13, 2015.

To date, though, there has been no public proof of concept demonstrated. We don’t currently know how simple or difficult it is to craft code that can exploit VENOM. Since VENOM leaves a system open to attack via the hacker’s old friend, the buffer overflow, it could, at its simplest, be exploited to cause the host machine to crash, resulting in a denial of service. With more care and cleverness, an attacker could potentially gain access to the virtualization host itself and be able to compromise the other VMs running on that same host.

What Can We Do To Protect Ourselves?

Since VENOM was disclosed responsibly, giving the vendors time to produce a patch, it’s incumbent upon virtualization host administrators to apply the patch as quickly as they are able. Individuals whose services run on VMs running on a shared virtualization platform can do little on their own. They can, however, visit their provider’s website to see if they are vulnerable and what steps are being taken to address the vulnerability. If necessary, they can apply pressure to push their administrators to patch their systems before this potential threat becomes a functional exploit in wide use by the darker side of the Internet.

To follow more about what Atlantic.Net is doing to address the VENOM vulnerability, check out our blog for the latest.  We constantly strive to offer the most secure cloud Servers offering the very best in one-click install applications like cPanel Hosting, among others.

Updated May 15, 2015, to include Atlantic.Net blog link


What is Public Key Cryptography (How VPNs Work, Part 2)

Mason Moody May 13, 2015 by under VMware Hosting 0 Comments

This article in the “How VPNs Work” series describes how public key cryptography (asymmetric encryption) works. If you’re already lost, don’t panic! This series of articles is written to explain the concepts and methods behind VPNs without requiring a deep dive into the mathematics that powers them.

If you’re completely new to the concept of VPNs, check out this introduction. If you already know a little about the how VPNs work and want to know a little more, this series is for you. Each article addresses one aspect of the means by which a VPN helps to secure data by telling a story which serves as a metaphor of the logical mechanisms involved. These stories involve two people, Adam and Burt, trying to keep a secret and a third person, Cesar, trying to nefariously discover their secret. Since VPNs have no perfect physical world equivalent, there may be some elements that stretch the bounds of credibility (for example, Cesar has access to a duplicator ray). Remember, it’s just a story…

Each article also has expandable sections (indicated with the gear icon) which contain a slightly more in-depth explanation that is somewhat more technical but still avoids getting too lost in the mathematics. These sections tie the events of the story a little more to the components or steps of encryption or authentication but are not required to get a basic understanding of the topic.

Adam and Burt have already discovered the weakness in using a lockbox with a shared symmetric key to keep things secure. So, Burt proposes they try a new method in which each of them has their own unique set of keys (asymmetric encryption).

Public Key Cryptography

Public Key Cryptography is an asymmetric encryption methodology that seeks to maintain confidentiality without having to ever share a secret key over an insecure channel (such as unencrypted email). In this explanation, Adam and Burt each have a unique lock, but for the remainder of this example, we’ll cover Burt’s lock and keys (Adam’s lock and keys will work in the same fashion). Each lock has two special properties: first, the lock has two distinct and related keys that can work with it, and second, each key that works with the lock can only turn in the lock in one direction–for the sake of this example, they only turn clockwise.

Paired Keys

Public KeyThe two keys in this asymmetric system only work as a pair. If Burt were to re-key this lock, he’d need to create two new keys. To make it simpler to distinguish the two keys, Burt color-codes them. One he makes green and the other red. Burt keeps the red key secured (his private key), but he can make the green key widely available to anyone who wants it (his public key). This may sound counterintuitive. But an important feature of these keys is that while they are related, it is virtually impossible to figure out one key based on knowledge of the the other. As such, one key can be made publicly available without revealing anything about its counterpart.

 

Private KeyThese keys are, in actual use, called the public and private keys (the color designations are to help make the explanation a little easier to follow). The generation of these keys involves some pretty nifty and complicated mathematics. (These algorithms begin with calculations involving the product of two very large prime numbers and is far beyond the scope of this example.) Common algorithms used in public key cryptography include RSA (named for its creators, Rivest, Shamir, and Adleman), DSA/DSS (Digital Signature Algorithm/Digital Signature Standard), and ECDSA (Elliptic Curve Digital Signature Algorithm). This latter algorithm instead utilizes the mathematics around elliptic curves and is at least as intimidating to the math-averse as the RSA algorithm.

The Clockwise Lock (How the Keys Work)

Private KeyBesides only working as part of a pair, these keys also only work in the lock in one direction. For example, Burt uses the green (public) key to secure the lock, which requires a half-turn in the lock. Since the lock only works in one direction, the green key can’t unlock the lock by reversing direction like an ordinary lock. At this point, because of the special nature of this locking mechanism, the only way to unlock it is to use the paired red (private) key.

In this fashion, when the lock is secured with the green (public) key, only the person who possesses the red (private) key can open it. This is how Burt can make the green key widely available to the public. He can send a copy of the green key to Adam (he could even make a copy available for public pickup or duplication). Anyone who has a copy of this green key can lock this lock, and at that point, only Burt–assuming he keeps his red (private) key secure–can open the lock. Now, when Adam wants to securely send something to Burt, he can use Burt’s green (public) key. Similarly, Adam would have his own key pair, and he could also make his green key available for Burt (or anyone else) to use.

Now, if our ne’er-do-well Cesar were to try to crack this method of security, he’d need to crack two different locks in order to get the whole conversation. Even if he were able to get past just one, he’d only be able to see one half of the conversation.

This usage of one-way encryption is employed in some secure email exchanges, such as with the use of PGP (Pretty Good Privacy) or GPG (Gnu Privacy Guard). If you’ve ever seen mention of someone’s PGP or GPG public key (and likely a block of random-looking text that was the key itself), you can see why it can be published as a part of an email signature or a publicly accessible website. With that key, anyone can encrypt an email that only the possessor of the private key (the recipient) can decrypt.

A Twice-Locked Box

A Twice-Locked BoxHere’s where Burt gets a clever idea. He places some artwork for the comic book he and Adam are working on in a box, places his lock on the box, and secures it with his green (public) key. Now, he’s the only person (since he has the only copy of the red key) that can unlock this box. He sends this box to Adam.

Adam, not having a copy of Burt’s red (private) key, can’t unlock the lock. But he can place his own lock on the box. He secures this lock with his own green (public) key. Adam sends this twice-locked box back to Burt.

Burt gets the box, and the only way he can open it is if he has both his own red key and Adam’s red key. But Adam is keeping his red key just as secret as Burt keeps his own red key, so Burt won’t be able to open the box. Burt, though, doesn’t want to open the box–remember, he started this process, so he wants Adam to get the art contained within the box. He can, though, unlock his own lock with his own red (private) key. When he does this, the only security on the box is the lock that Adam secured.

Burt sends the box back to Adam, and now Adam, using his red key, unlocks the remaining lock. Burt has successfully and securely sent this package. This method adds a couple of layers of security, in that there are two layers of locking/encryption and in the fact that no shared key needs to ever be exchanged via a potentially insecure medium. However, it isn’t a very efficient system if they need to send more secure messages back and forth in a more timely manner.

This ability is one of the interesting features of the mathematics behind public key cryptography. A message can be encrypted multiple times; then, when decrypting it, that decryption can be done in any order. It works in a commutative way the way some simple mathematic functions work. For example, if you were to start with the number 10 and add three other numbers–say, 3, 5, and 7 (so, 10 + 3 + 5 + 7 to get 25), you could then subtract them from your total in any order to get back to the same original number (25 – 5 – 7 – 3 = 10). Of course, the mathematics behind this cryptography is significantly more intricate.

 

A Complicated, Robust Lock

Robust LockSo while Adam and Burt now have worked out a public-key cryptography method, it’s not without its drawbacks. This twice-locked box method of keeping communication secure takes three times as long per message. In addition, public-key cryptography methods tend to be more work-intensive when it comes to carrying out the encryption or decryption. In the example above, imagine that instead of each key turning in the lock one half turn, it requires 10 full rotations. That would mean 40 rotations (Burt locks (10) + Adam locks (10) + Burt unlocks (10) + Adam unlocks (10)) per message!

There is, however, one advantage to this inefficiency. If Cesar were to use a device that could simulate any key, and assuming that to open one of these locks requires the full 10 rotations just to see if that key works, then the time it would take him to try every key combination (a brute force attack) goes up by a factor of 10 as well.

The length of an encryption key is measured in bits. The larger the bit length of the key, the more resistant that key is being discovered via brute-force cracking attempts. The larger the bit length of the key also means that the work required to perform encryption or decryption increases. However, since asymmetric and symmetric encryption algorithms work in different ways, their key lengths aren’t directly comparable. For example, an RSA (asymmetric) 1024-bit key has about the same strength as an 80-bit symmetric key. There are tools available to compare relative key lengths across the different encryption methods, such as the one maintained by BlueKrypt, that can help illuminate the difference in computational cost between these methods.

These differences highlight one of the primary conundrums of computer security: security vs. convenience. Work done to improve one often comes at the expense of the other. Increasing the bit-length of the encryption key increases its strength, but it also means that it will take longer to perform that encryption and decryption. When measures are made to improve convenience, such as increasing computing power or reducing the length of the key, those same measures also mean it requires less work to successfully guess the key through brute-force methods.

 

More in the “How VPNs Work” Series

Part 1: Symmetrical Encryption Algorithms
Part 3: Shared Key Exchange
Learn more about services from Atlantic.Net, including VMware hosting.


What is Symmetric-Key Encryption (How VPNs Work, Part 1)

Mason Moody April 24, 2015 by under VMware Hosting 0 Comments

This article in the “How VPNs Work” series describes how symmetric-key encryption works. If you’re already lost, don’t panic! This series of articles is written to explain the concepts and methods behind VPNs without requiring a deep dive into the mathematics that powers them.

If you’re completely new to the concept of VPNs, check out this introduction. If you already know a little about the how VPNs work and want to know a little more, this series is for you. Each article addresses one aspect of the means by which a VPN helps to secure data by telling a story which serves as a metaphor of the logical mechanisms involved. These stories involve two people, Adam and Burt, trying to keep a secret and a third person, Cesar, trying to nefariously discover their secret. Since VPNs have no perfect physical world equivalent, there may be some elements that stretch the bounds of credibility (for example, Cesar has access to a duplicator ray). Remember, it’s just a story….

Each article also has expandable sections (indicated with the gear icon) which contain a slightly more in-depth explanation that is somewhat more technical but still avoids getting too lost in the mathematics. These sections tie the events of the story a little more to the components or steps of encryption or authentication but are not required to get a basic understanding of the topic.

Basic Symmetric-Key Encryption

Adam_symmetric_keyLet’s suppose that Adam and Burt are writing a comic book. Since they live in nearby towns and can’t meet in person all that often, they send drafts of their book to each other via the Greater Metropolitan Area Post Office. They don’t want anyone getting a peek at their book before it’s finished, so they use a lockbox (encryption) and make a copy of the key (encryption key) for each of them. Now, when Adam finishes a script, he can send it to Burt in this lockbox and be sure that only Burt can unlock it when he gets it in the mail.

This mechanism is analogous to one of the earliest widely-used encryption standards for computer data, DES (Digital Encryption Standard). DES is a symmetric-key encryption algorithm, meaning that the key that is used to encrypt the data is also used to decrypt it. On a simplified level, a symmetrical-key encryption algorithm is a method of applying a series of predefined mathematical steps, and the key is a sort of pivotal variable (one might say, a “key” variable) that plugs into that method to produce unique output–the encrypted data. This process can also be reversed by applying the same method in reverse, again with the same key.

 

The Threat

Burt_symmetric_keyNow, Cesar enters the picture. Cesar is obsessed with Adam and Burt’s comic book and can’t wait to learn more about it. For the sake of this story, Cesar has a duplicator ray. He is also a master of disguise, so he uses his talents to pose as a postal worker. His ultimate goal is to find a way to intercept the box Adam and Burt send back and forth to get a peek inside. Soon Cesar insinuates his way deeply enough into the Greater Metropolitan Area Post Office that he gains access to the central mail sorting room, and he spots the box from Adam to Burt. Cesar doesn’t want to arouse suspicion from either Adam or Burt from a delayed delivery, so he uses his duplicator ray to make a copy of the box. Sadly for Cesar, this box is also locked (encrypted), the same as the original. But, among his talents, he is a journeyman locksmith, so he takes this duplicate box to his lair to attempt to bypass the lock.

Network traffic is sent in discrete units called packets. So, whether you are sending something small (a short email) or something large (a video), the data will be segmented into easily managed packets before being transmitted. It’s the equivalent of sending a jigsaw puzzle to someone a piece at a time. Once it arrives at its destination, it will be reassembled.

This process of examining network traffic in transit is called “packet inspection” (sometimes more informally called “packet sniffing” or “sniffing the wire”). Packet inspection allows network administrators to identify and block much hostile traffic on their network. It can also be quite useful to help troubleshoot connectivity issues within a network.

It can also be used for less constructive purposes, such as eavesdropping. In these circumstances, this sort of use is often called a Man-in-the-Middle (MitM) attack. For someone like Cesar, who manages to insert himself in the transit path these messages take, this attack allows an interloper to copy all passing traffic (without delaying it and potentially alerting either end that something might be amiss) in order to analyze it later. Traffic that is not encrypted can be easily reassembled, allowing anyone with the proper tools to read the email or see the web page requested. Encrypted data would require knowing or discovering the key to decrypt each packet before reassembling it.

 

Brute Force Crack

Cesar_symmetric_keyLet us say, then, that Cesar spends time working on this lock and manages to finally pick the lock. After some practice, he learns to cut this time down significantly. Then, he intercepts the next package Burt sends back to Adam, copies it, and sends the original back on its way to Adam. Now, Cesar can pick the lock at his leisure, and, since Adam received the package without delay, he and Burt have no idea anything could be amiss. So imagine their surprise and dismay when Cesar posts all the spoiler details of their new comic book on his blog (called, naturally, “The Cesarian Section”).

Adam and Burt realize they will need to come up with a better way to securely exchange messages. If they were to re-key the lock, it would likely not take Cesar long to learn how to pick this new lock. They decide to invest in a lock with a much more complicated key (a stronger symmetric-key encryption algorithm). But how long might it take Cesar to crack this lock?

DES is no longer considered a strong means of encryption, implemented on its own. In 2008, SciEngines GmbH announced they were able to break DES in less than a day.

A variation called Triple Digital Encryption Standard (abbreviated 3DES, usually pronounced “triple-dez”) has, in many instances, supplanted DES. As its name implies, it functions using the DES algorithm but run three times. The key is three times as long, and in its strongest implementation, it is made up of three different DES keys, one for each iteration of the DES algorithm. It can be helpful to imagine this algorithm functioning as if it were an intricate puzzle box. The first key might be the combination of twists and machinations (as with a Rubik’s Cube) required to reveal a sliding-tile style puzzle, which, when solved (the second key), would expose a keyhole for your key (the third key).

An even stronger symmetric-key encryption algorithm is AES (Advanced Encryption Standard, though you may also sometimes see it referred to by its original name “Rijndael”, pronounced “rain-doll”). The strength of these sorts of algorithms is measured by the effective lengths of their keys (in bits). 3DES uses 168-bit keys (in its strongest implementation), though certain attacks have been shown to reduce that strength equivalent to an 80-bit key. AES can use 128-, 192-, and 256-bit keys. As the length of each of these keys goes up, so does its associated strength and computational requirements.

 

The Evolution of Encryption

strong symmetric-key encryptionNaturally, Adam and Burt have concerns that maintaining this lockbox solution, even if it is top-of-the-line, may not be as secure as they would like. A ne’er-do-well such as Cesar has several means to attempt to defeat this system. He can attempt to illicitly obtain a copy of the key from either Adam or Burt, or from the means they use to exchange the key in the first place (especially if this exchange is over an unsecured medium). Finally, he may, after practice and/or technological advance, discover a way to more efficiently “guess” the key. If they want to stay ahead of Cesar, they’ll need to find some new ways to make it much more difficult for him to find a way around or through.

More in the How VPNs Work Series:

Part 2: Public Key Cryptography
Part 3: Shared Key Exchange
Learn more about services from Atlantic.Net, including VMware hosting.


What Is a VPN?

Mason Moody April 22, 2015 by under VMware Hosting 0 Comments

What Is a VPN?So what is a VPN? Maybe you’ve heard some of your tech-savvy friends or co-workers talk about a VPN. Perhaps you even use one and want to know a little bit about what a VPN is and how it works. (If you already know the basics and would like to know more about the algorithms and cryptography underlying VPNs, check out the links below.)

VPN is short for Virtual Private Network. Let’s unpack each of those terms. We’ll start with the last word first. (Each of these sections provides a very basic overview of each term accompanied by a more in-depth explanation indicated by the icon. Just click on that icon to expand that section.)

 

Network (The “N” in VPN)

A network, in the context of computing, is a collection of devices which all share a membership in the same group. For example, all computers and related equipment in an office might comprise a network.

In the example of a company, different departments might exist within this one company, and each of these could be considered subnetworks (in computer networking, this term is usually shortened to “subnet”). If the employees of this company needed to interact with employees from another company, they might form a relationship, an inter-network. Inter-network can be shortened to “internet”, which, when capitalized, refers to the Internet most of us are familiar with. The Internet is an inter-network of thousands of distinct, connected computer networks and subnetworks.

 

Private (The “P” in VPN)

When we refer to a network being Private, we are often referring to a local segment of a network, sometimes called a Local Area Network (LAN). A network is usually kept private by setting it up behind a device called a firewall, which helps to protect the LAN from the public Internet.

To understand what a private network is, it might help to think of the difference between sending a report to a colleague at your office versus sending a report to a colleague in a remote office in another city. If you need to send a report to your work colleague in the same office, you might just address it to that person by name, maybe department. Anyone in your office would probably know how to get that report to “Julie in Accounting”, for example. But if you wanted to mail that report to “Eartha in Accounting” at your remote office, you’ll need a different addressing scheme if you wanted someone to successfully deliver your report.

Similarly, computers that are a part of a network will have an address. Addresses for devices on a network (called “IP addresses”) are made up of a series of digits that looks a bit like a phone number, except in the format of “nnn.nnn.nnn.nnn”. So, for example, a well known Google IP address is “8.8.8.8”. This address is a public address, the computer equivalent of a mailing address. So if you wanted to send a packet (in our post office metaphor, think of a packet like an envelope) to that address, any device that is properly connected to the Internet should know how to get it there.

There are certain IP address ranges, though, that are set aside and never used as a part of the public Internet. These are reserved, instead, for private use. If you’ve ever set up a home router, you’ve probably seen an example of this sort of private address (something like “192.168.0.1” or “192.168.1.1”). In the example above, “Julie in Accounting” would be the equivalent of a private address.

 

Virtual (The “V” in VPN)

Virtual TunnelOften a private network is physically self-contained. All devices that are part of the same network might be in the same geographical area (maybe a computer closet, a cabinet in a data center, or even an entire building, for example). It is possible, though, to create a private network between devices which might be within separated areas, such as different rooms in a building, different buildings in a city, or even different locations around the globe. This is where the “virtual” part comes into play, via a process called “encapsulation”. Data on a virtual private network can be sent to another private target by disguising it to appear to be public traffic. (This encapsulation process also often involves encryption to further protect it.) You might also hear a VPN referred to as a “tunnel”. In a sense, private messages are being sent within a public network as though it were traversing a private tunnel within that public network.

Imagine that you work in a building whose security department is in the basement. You have just been transferred to security, and on your tour of the department, they show you that there is a tunnel leading to another section of the security department that is located in the basement of a nearby but separate building. This tunnel acts to link these two separate buildings so, from the point of view of someone who works in this security department, the whole security section is one unit (a “network”). And since only authorized security personnel are allowed in this department, it can be considered a private tunnel. This example, though, features a physical tunnel. How do you make that virtual?

Creating a “virtual” tunnel involves a form of encapsulation. In most cases, this means that private traffic, before leaving one portion of a private network, is encapsulated to look like ordinary traffic on the publicly accessible Internet. When it reaches the destination specified in its encapsulation data, it sheds that encapsulation and resumes its travel to its final destination on this separate portion of the private network. In our example with the security department, imagine that we open a new security office across town. It wouldn’t be practical to build a physical tunnel all the way across town, but we could utilize a delivery service to send private messages there, similarly to how inter-office mail between geographically separate remote offices works. So, for example, we would place a report in an envelope addressed to “Burgess in Remote Security Services”, and then we could place that envelope in a larger package (encapsulating it) addressed to our remote security office with its full mailing address. We send the package via a courier to the remote office, and once it gets there, Frank the mail clerk opens the package (de-encapsulation), and he can then deliver the envelope to “Burgess in Remote Security Services” (private address). It could be said that we have “tunneled” this message through the courier service.

Also, since our department is concerned with security, we’d want to be sure that our message to Burgess isn’t tampered with or peaked at while it’s in transit. We might place a lock (which only we and our colleagues at the remote office could unlock) on the package before handing it over to the courier. The “lock” for traffic on a VPN would be an encryption algorithm. In VPN terminology, the device that handles the encapsulation and any encryption is called a “VPN gateway” or “VPN peer”. Not every VPN utilizes encryption, but it is prevalent when it’s important to keep data secure or private.

 

Putting It Together

Broadly speaking, a VPN keeps data traffic “within” a private network while it is sent over a public network. It is addressed so that it can be delivered over the Internet (encapsulation) and gets locked so no one can peek at the contents while it’s in transit (encryption).

Why Use a VPN?

The example above demonstrates one way VPNs are employed to maintain private communication over a public network. VPNs can also be used to offer a degree of privacy on a public network.

Ordinarily, your Internet Service Provider (ISP) assigns to your connection a public address so that the sites and services you request online can know how to send information back to you. This public address can be used to provide an approximate location for your Internet connection. It is also possible that anyone with the appropriate means can see the websites you are going to, as well as the content you are requesting (especially when you visit a website whose URL begins with “http:” and whose contents are sent unencrypted).

So another use of a VPN is to offer a degree of privacy from snooping. In this case, rather than having both ends of a tunnel linking two ends of a private network, it’s possible to have one end act as a public access point to the Internet. In this way, someone who directly connects to the Internet in Chicago can appear to be accessing it from New York, for example.

VPN encryption techniques involve some pretty complicated mathematics, but if you’d like to read a little more about these techniques–and don’t have the time to earn an advance mathematics degree–check out these articles:

Additional Articles

Part 1: Symmetrical Encryption Algorithms
Part 2: Public Key Cryptography
Part 3: Shared Key Exchange
Learn more about services from Atlantic.Net, including VMware hosting.


New York, NY

100 Delawanna Ave, Suite 1

Clifton, NJ 07014

United States

San Francisco, CA

2820 Northwestern Pkwy,

Santa Clara, CA 95051

United States

Dallas, TX

2323 Bryan Street,

Dallas, Texas 75201

United States

Ashburn, VA

1807 Michael Faraday Ct,

Reston, VA 20190

United States

Orlando, FL

440 W Kennedy Blvd, Suite 3

Orlando, FL 32810

United States

Toronto, Canada

20 Pullman Ct, Scarborough,

Ontario M1X 1E4

Canada

London, UK

14 Liverpool Road, Slough,

Berkshire SL1 4QZ

United Kingdom

Resources

We use cookies for advertising, social media and analytics purposes. Read about how we use cookies in our updated Privacy Policy. If you continue to use this site, you consent to our use of cookies and our Privacy Policy.