Security

Despite the fact that Wi-Fi is a trademark owned by the Wi-Fi Alliance, an organization committed to certifying that Wi-Fi equipment fulfills the IEEE's set of 802.11 wireless standards, the name ‘Wi-Fi’ is associated with wireless access in general nowadays.

These specifications, which include 802.11b (pronounced "Eight-O-Two-Eleven-Bee," omitting the "dot") and 802.11ac, are part of a family of specifications that began in the 1990s, which is still growing today. Improvements to wireless speed and range, as well as the usage of additional frequencies as they become available, are codified in the 802.11 standards.

What do those standards represent?

The IEEE 802.11 standard is a collection of technological advancements that have been created over a long period of time. Each new breakthrough is specified by a one- or two-letter suffix to "802.11," which represents the modification to the standard. Only the 2.4-GHz band was supported by the initial 802.11 standard, which allowed for speeds of up to 2 Mbps. New coding algorithms were implemented to 802.11b to enhance the speed to 6 Mbps. 802.11a included 5-GHz support and Orthogonal Frequency Division Multiplexing (OFDM) coding techniques, boosting speed to 54 Mbps. The 802.11g standard brought OFDM from the 802.11a standard to the 2.4-GHz range. 802.11n introduced a slew of high-throughput enhancements that increased throughput by a factor of ten, allowing high-end business access points to reach signaling throughputs of 450 Mbps.

As you may have noticed, the IEEE naming method for the standard is a little confusing, so the Wi-Fi Alliance has come up with some shorter names to make it easier to comprehend.

The alliance refers to 802.11ax Wi-Fi as Wi-Fi 6 — the current emerging standard. Wi-Fi 5 is now 802.11ac, while Wi-Fi 4 is now 802.11n. According to the Wi-Fi Alliance, the goal is to make it easier for the end-user to navigate through the myriads of routers and client devices.

Meanwhile, it's crucial to note that the Wi-Fi Alliance hasn't come up with new names for all of the 802.11 standards, so familiarity with the old ones is essential. Furthermore, the IEEE, which is still working on further versions of 802.11, has not accepted these new names, making it more difficult to find out information about them using the new names.

How secure is it?

The authentication security protocols defined by the Wireless Alliance, such as Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA), are used to secure wireless security. There are now four wireless security protocols available:

• Wired Equivalent Privacy (WEP);
• Wi-Fi Protected Access (WPA);
• Wi-Fi Protected Access 2 (WPA 2);
• Wi-Fi Protected Access 3 (WPA 3).

To be sure your network is secure, you must first identify which network yours falls under.

WEP

The first security protocol to be implemented was Wired Equivalent Privacy (WEP). It was designed in 1997 and is now outdated, however, it is still used with older devices in present times.

WEP employs a data encryption technique based on a mix of user and system-generated key values. However, hackers have devised strategies for reverse-engineering and breaking the encryption mechanism, making WEP the least secure network type.

WPA

The Wi-Fi Protected Access (WPA) protocol was created to address the weaknesses in the WEP protocol. WPA includes features like the Temporal Key Integrity Protocol (TKIP), a dynamic 128-bit key that proved more difficult to crack than WEP's static, unchanging key.

It also had encryption features like the Message Integrity Check, which looked for any tampered packets transmitted by hackers and the Pre-shared key (PSK), among others.

As detailed in this article, both WEP and WPA are very hackable, so please, take our advice and never use them.

WPA2

WPA2 introduced substantial updates and new features to the wireless security gambit in 2004. WPA2 substituted TKIP with the Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP), which is a significantly more sophisticated kind of encryption technology.

Since its creation, WPA2 has represented the industry standard; on March 13, 2006, the Wi-Fi Alliance specified that any future products using the Wi-Fi trademark must employ WPA2.

WPA2-PSK

To connect to a wireless network, WPA2-PSK requires only one password. It's often assumed that using a single password to access Wi-Fi is safe, but only if you trust the people who use it. This is obviously not very secure, considering the fact that this key may fall into wrong hands. As a result, this protocol is most commonly used for home or open Wi-Fi networks.

To encrypt a network with WPA2-PSK, you ought to provide your router with a plain-English password between 8 and 63 characters long, rather than an encryption key. CCMP is used to create unique encryption keys for each wireless client using that passcode and the network SSID. Moreover, the encryption keys are updated on a regular basis.

WPA3

WPA3 is the most recent (and improved) version of WPA2, which has been in use since 2004. In 2018, the Wi-Fi Alliance began certifying WPA3-approved equipment.

Although WPA3 is more secure than WPA2, the Wi-Fi Alliance will continue to maintain and enhance WPA2 for the foreseeable future. When compared to WPA2, WPA3 includes the following noteworthy features:

• Stronger brute force attack protection: WPA3 defends against offline password guesses by allowing only one guess per user and forcing them to engage directly with the Wi-Fi equipment, requiring them to be physically present each time they wish to guess the password. In public open networks, WPA2 lacks built-in encryption and privacy, making brute force attacks a significant danger;
• Simultaneous Authentication of Equals protocol (SAE): This protocol is used to provide a secure handshake between a network device and a wireless access point, in which both devices interact to verify authentication and connection. Even if a user's password is weak, WPA3 uses Wi-Fi DPP to give a more secure handshake;
• Individualized data encryption: When connecting to a public network, WPA3 uses a mechanism other than a shared password to sign up a new device. WPA3 employs the Wi-Fi Device Provisioning Protocol (DPP), which allows users to let devices onto the network via NFC tags or QR codes. WPA3 security also employs GCMP-256 encryption instead of 128-bit encryption.

WPA3 functionality will not be extended to all devices automatically. Users who want to use WPA3-approved devices must either purchase new routers that enable WPA3 or hope that the device's manufacturer implements updates to support the new protocol.

We, at Passwork, highly recommend using the latest security protocols while constantly updating your router’s firmware. When you ignore critical updates, you risk exposing holes in your security that allow hackers to take control of your network. Use sophisticated and long passwords at all times. Even if we’re talking about your home Wi-Fi network – remember, if your password is ‘12345678’, your neighbours can easily hack into your network and spoof the data.

The Secure Sockets Layer (SSL) and the Transport Layer Security (TLS) cryptographic protocols have seen their share of flaws, like every other technology. In this article, we would like to list the most commonly-known vulnerabilities of these protocols. Most of them affect the outdated versions of these protocols (TLS 1.2 and below), although one major vulnerability was found that affects TLS 1.3.

POODLE

This cute name should not misguide you – it stands for Padding Oracle On Downgraded Legacy Encryption. Not that nice after all, right? It was published in October 2014 and it takes advantage of two peculiar facts. The first one is that some servers/clients still support SSL 3.0 for interoperability and compatibility with legacy systems. The second one is a vulnerability related to block padding that appears in SSL 3.0. Here is a link to that vulnerability on the NIST NVD database.

How does it work?

As mentioned before, this vulnerability comes from the Cipher Block Chaining (CBC) mode. Those block ciphers use blocks of a fixed length, so if the data in the last block is shorter than the block’s size, it is filled by padding. The server, of course, ignores such padding by default, it only checks whether the length is correct and verifies the Message Authentication Code (MAC) of the plaintext. In practice, this means that the server cannot verify if the content inside the padding has been altered in any way.

An attacker is able to modify padding data and then simply waits for the server’s response. Attackers can recover the contents byte-by-byte by watching server responses and altering the input. It usually takes no more than 256 attempts to reveal one byte of a cookie, which equates to a maximum of 4096 queries for a 16-bit cookie. Just by using automated scripts, the hacker may retrieve the plaintext char by char. Such a plaintext may be anything from a password to a cookie or a session. So, without even knowing the encryption method or key, a sniffer may easily decipher a block.

BEAST

The Browser Exploit Against SSL/TLS attacks was disclosed in September 2011. It affects browsers that support TLS 1.0, because this early version of the protocol has a vulnerability when it comes to the implementation of the above-mentioned CBC mode. Here’s a link to it in the NIST NVD database.

How does it work?

This kind of attack is usually client-side, so in order for it to succeed, an attacker should, in one way or another, have some control of the clients’ browser. After getting access to a browser, the attacker would typically use MITM to inject packets into the TLS stream. After such an injection, the only thing left is to guess the Initialization Vector (IV) – a random block of data that makes each message unique. This is used with the injected message and then simply compared with the results of the needed block.

CRIME

The Compression Ratio Info-leak Made Easy (CRIME) vulnerability affects TLS compression. The Client Hello message optionally uses the DEFLATE compression method, which was introduced to SSL/TLS to reduce bandwidth. The main method used by any compression algorithm is to replace repeated byte patterns with a pointer to the first instance of such sequences. As a result – the bigger the repeated sequences, the more effective such a compression is. You can visit this link to locate this vulnerability in the NIST NVD database.

How does it work?

Let’s imagine that a hacker is targeting cookies. He knows that the targeted website creates a cookie for each session named ‘ss’. The DEFLATE compression method replaces repeated bytes and our antagonist knows that. Therefore, he injects Cookie:adn=0 to the victim’s cookie. The server would, of course, append 0 to the compressed response, because Cookie:adn= has been already sent, so it is repeated.

After that, the only thing for an attacker to do is to inject different characters and then monitor the size of the response.

The injected character is contained in the cookie value if the answer is shorter than the first one, hence the compression. The response will be longer if the character is not in the cookie value. Using this strategy, an attacker can recreate the cookie value using the server's feedback.

By the way, the BREACH attack is very similar to CRIME, but it targets HTTP compression instead.

Heartbleed

Heartbleed was a major vulnerability discovered in the OpenSSL (1.0.1) library's heartbeat extension. This extension is used to maintain a connection so long as both participants are online. Here is its link on our beloved NIST NVD database.

How does it work?

The client sends the server a heartbeat message with a payload containing data and its size + padding. The server will respond with the same heartbeat request as the client.

The vulnerability comes from the fact that if the client sent a false data length, the server would respond with a heartbeat response containing not only the data received by the client but, because it needs to fill the length of the message, also with random data from its memory. A very unfortunate technical solution, isn’t it?

Leaking such unencrypted data may result in a disaster. It is well-documented that by using such a technique, an intruder may obtain a private key to the server. Moreover, if the attacker has the private key – well, that means he’s able to decrypt all the traffic to the server. I guess we don’t need to tell you why that’s no good, right?

The entire list of vulnerabilities may be found in this wonderful report by the Health Sector Cybercecurity Coordination Center. It not only lists all above-mentioned techniques in a very informative manner but also provides a very neat table of all ‘Known Threats to TLS/SLS’ (pp. 24-26).

Instead of a long conclusion, let’s just look at the last page of that report:

The green cell of the chart explicitly states how to get rid of most known vulnerabilities. Indeed, if you’re not interested in trawling through the nooks and crannies of the Library of Alexandria’s floor on Cybersecurity, the best way to track existing SSL/TLS vulnerabilities is by visiting csrc.nist.gov once in a while. You might even consider making it your homepage.

Security, security, security… There is no way one can underestimate the importance of it when it comes to caring for private files and sensitive data. As long as the world of cybersecurity is privy to the constant conflict between hackers and programmers, fully protecting yourself and your business will forever be impossible. But, as we know, hackers aren’t always using state-of-the-art techniques. Often, they’re still getting in by guessing your username and password.

Most popular kinds of technology are under a constant barrage of hacking attempts, which is why it is so important to follow simple protocols to save yourself both time and money. One of such technologies is SSL/TLS. It is used on almost every web service, and even though it may seem straightforward to set up, there are many arcane configurations and design choices that need to be made to get it ‘just right’.

This guide will provide you with a short ‘checklist’ to keep in mind when setting up or maintaining SSL/TLS with a focus on security. All information is accurate and up to date as of December 2021 and is based on both our experience and other guides made on this topic.

Track all your certificates

First and foremost, you should check up on all existing certificates that are used by you and your organisation. This covers all information about them, such as their owners, locations, expiration dates, domains, cipher suites, and TLS versions.

If you don’t know about, or don’t track existing certificates as well as weak keys and cipher suites, you expose yourself to security breaches connected to expiring certificates.

An easy way to list all your certificates is to get them from your CA. This may not work if you used self-signed certificates, which require additional attention in terms of tracking/listing. The second way, which is typically quite effective, is to obtain certificates using network scanners. Hopefully, the enormous number of certifications that you were unaware of will not surprise you. Your certificate ‘inventory’ should focus on details such as OS and applications like Apache, just because your organization could be vulnerable to exploits that attack specific versions of things like OpenSSL (i.e., Heartbleed).

So, your list of certificates should include:

1. Certificates issued
   • Certificate types
   • Key sizes
   • Algorithms
   • Expiration dates
2. Certificate locations
3. Certificate owners
4. Web server configurations
   • O/S versions
   • Application versions
   • TLS versions
   • Cipher suites

Don’t use weak keys, cipher suites or hashes

Every certificate has a public key and a signature, both of which may be vulnerable if they were created with outdated technology. On public web servers, certificates with key lengths of less than 2048 bit or those that employ older hashing algorithms like MD5 or SHA-1 are no longer allowed. These may, however, be found on your internal services. If that's the case, you'll need to upgrade them.

The requirement to check TLS/SSL versions and cipher suites supported on your web servers is much more crucial than finding certificates with weak keys or hashes.

The following versions are outdated and must never be used:
• SSL v2
• SSL v3
• TLS 1.0
• TLS 1.1
Instead, enable TLS 1.2 and TLS 1.3.

The following cipher suites are vulnerable, and must be disabled:
• DES
• 3DES
• RC4
Instead, use modern ciphers like AES.

Install and renew all certificates on time

We recommend renewing a certificate at least 15 days before it expires to allow time for testing and reverting to the prior certificate if any problems arise.

Users should be notified when certificates expire, regardless of the mechanism you employ. Before expiration, the system should alert users automatically and at regular intervals (e.g., 90 days). Self-signed certificates should never have an expiration date of more than 30 days.

Never reuse key pairs for new certificates

By the same token, never reuse CSRs (Certificate Signing Requests) — this will automatically reuse the private key. Reusing keys leads to key pair vulnerability. Don’t be lazy when it comes to your security.

Review the CA that you use

Your certificates are only as trustworthy as the CA that issues them. All publicly trusted CAs are subject to rigorous third-party audits to maintain their position in major operating system and browser root certificate programs, but some are better at maintaining that status than others.

Use Forward Secrecy (FS)

Also known as perfect forward secrecy (PFS), FS assures that a compromised private key will not also compromise past session keys. To enable it, use at least TLS 1.2 and configure it to use the Elliptic Curve Diffie-Hellman (EDCHE) key exchange algorithm. The best practice here would be to use TLS 1.3 as it provides forward secrecy for all TLS sessions using the Ephemeral Diffie-Hellman key exchange protocol ‘out of the box’.

Use DNS CAA

DNS CAA is a standard that allows domain name owners to restrict which CAs can issue certificates for their domains. In September 2017, the CA/Browser Forum mandated CAA support as part of its certificate issuance standard baseline requirements. The surface area prone to attack is certainly shrunk with CAA in place, effectively making sites more secure. If CAs have an automated mechanism in place for certificate issuance, they should check for DNS CAA records to prevent certificates from being issued incorrectly. It is advised that you add a CAA record to your certificate to whitelist a CA. Add certificate authorities (CAs) that you trust.

Keep in mind that encryption is not an option.

Enforce encryption across your entire infrastructure — no 'bald spots' should remain. Leaving elements of your infrastructure unprotected is like forgetting to lock the door when you leave — it's not a good idea.

The practices that we’ve mentioned in this list are more about common sense, rather than knowledge acquired through the ultra-secret bureau. When it comes to security, you should always keep your infrastructure up-to-date. New vulnerabilities pop up every day, but still, we, humans, pose the biggest threat of all. In other words, human error has more to answer for than we might first believe. Because of this, double-check everything you do. Security protocols should be easy to follow not only by the person who creates them but also by everyone who interacts with your infrastructure — users and employees alike.

With such a checklist, it’s impossible to shine a light on each and every nook and cranny, so for those of you who want to ensure that you’re following all best practices, consider checking out this list.

Imagine you’re a system administrator at Home Depot. Just as you’re about to head home, you notice that your network has just authorized the connection of a new air-conditioner. Nothing too peculiar, right? The next morning, you wake up to find that terabytes of data including logins, passwords and customer credit card information have been transferred to hackers. Well, that’s exactly what happened in 2014, when a group of hackers, under the guise of an unassuming HVAC system, landed an attack that cost Home Depot over $17.5 million dollars, all over an incorrectly configured PKI. In this article, we’ll be conducting a crash course in PKI management.

So, what’s a PKI?

‘Public key infrastructure’ is a term that relates to a set of measures and policies that allow one to deploy and manage one of the most common forms of online encryption – public-key encryption. Apart from being a key-keeper for your browser, the PKI also secures a variety of different infrastructures, including internal communication within organizations, Internet of Things (IoT), peer to peer connection, and so on. There are two main types of PKIs:

•   The Web PKI, also known as the “Internet PKI”, has been defined by RFC 5280 and refined by the CA/Browser Forum. It works by default with browsers and pretty much everything else that uses TLS (you probably use it every day).

•   An Internal PKI – is the one you run for your own needs. We’re talking about encrypted local networks, data containers, enterprise IT applications or corporate endpoints like laptops and phones. Generally speaking, it can be used for anything that you want to identify.

At its core, PKI has a public cryptographic key that is used not to encrypt your data, but rather to authenticate the identities of the communicating parties. It’s like the bouncer outside an up-market club in Mayfair – you’re not getting in if you’re not on the list. However, without this ‘bouncer’, the concept of trustworthy online communication would be thrown to the wind.

So, how does it work?

PKI is built around two main concepts – keys and certificates. As with an Enigma machine, where the machine’s settings are used to encrypt a message (or establish a secure protocol), a key within a PKI is a long string of bits used to encrypt or decrypt encoded data. The main difference between the Enigma machine and a PKI is that with the latter, you have to somehow let your recipient know the settings used to encode the encrypted message.

The PKI gets its name because each party in a secured connection has two keys: public and private. A generic cipher protocol on the other hand, usually only uses a private one.

The public key is known to everyone and is used throughout the network to encode data, but the data cannot be accessed without a private key, which is used for decoding. These two keys are bound by complex mathematical functions which are difficult to reverse-engineer or crack by brute force. By the way, this principle is an epitome of asymmetrical cryptography.

So, this is how data is encrypted within a public key infrastructure. But let’s not forget that identity verification is just as important when dealing with PKIs – that’s where certificates come into play.

Digital Identity

PKI certificates are most commonly seen as digital passports containing lots of assigned data. One of the most important pieces of information in such a certificate relates to the public key: the certificate is the mechanism by which that key is shared – just like your Taxpayer Identification Number (TIN) or driver’s license, for instance.

But it’s not really valid unless it has been issued by some kind of entrusted authority. In our case, this is the certificate authority (CA). Here, there is an attestation from a trusted source that the entity is who they claim to be.

With this in mind, it becomes very easy to grasp what the PKI consists of:

•      A certificate authority, which issues digital certificates, signs them with its public key and stores them in a repository for reference;

•      A registration authority, which verifies the identities of those requesting digital certificates. A CA can act as its registration authority or can use a third party to do so;

•      A certificate database that stores both the certificates, their metadata and, most importantly, their expiration dates;

•      A certificate policy outlining the PKI's procedures (this is basically a set of instructions that allows others to judge how trustworthy a PKI is).

What is a PKI used for?

A PKI is great for securing web traffic – data flowing through the open internet can be easily intercepted and read if it isn't encrypted. Moreover, it can be difficult to trust a sender’s identity if there isn’t some kind of verification procedure in place.

But even though SSL/TLS certificates (that secure browsing activities) may demonstrate the most widespread implementation of PKI, the list doesn’t end there. PKI can also be used for:

•       Digital signatures on software;

•       Restricted access to enterprise intranets and VPNs;

•       Password-free Wifi access based on device ownership;

•       Email and data encryption procedures.

PKI use is taking off exponentially; even a microwave can connect to Instagram nowadays. This emerging world of IoT devices brings us new challenges and even devices seemingly existing in closed environments now require security. Taking the ‘evil air conditioner’ that we spoke about in the introduction as an example – gone are the days where we can take a piece of kit for face value. Some of the most compelling PKI use cases today centre around IoT. Auto manufacturers and medical device manufacturers are two prime examples of industries currently introducing PKI for IoT devices. Edison’s Electronic Health Check-up System would be a very good example here, but we’ll save that for a future deep-dive.

Is PKI a cure-all?

As with any technology – execution is sometimes more important than the design itself. A recent study by the Ponemon Institute surveyed nearly 603 IT and security professionals across 14 industries to understand the current state of PKI and digital certificate management practices. This study revealed widespread gaps and challenges, for example:

•       73% of security professionals admit that digital certificates still cause unplanned downtime and application outages;

•       71% of security professionals state that migration to the cloud demands significant changes to their PKI practices;

•       76% of security professionals say that failure to secure keys and certificates undermines the trust their organization relies upon to operate.

The biggest issue, however, is that most organizations lack the resources to support PKI. Moreover, only 38% of respondents claim they have the staff to properly maintain PKI. So for most organisations PKI maintenance becomes a burden rather than a cure-all.

To sum up, PKI is a silent guard that secures the privacy of ordinary online content consumers. However, in the hands of true professionals, it becomes a power tool that creates an encryption infrastructure that is almost infinitely scalable. It lives in your browser, your phone, your wifi access point, throughout the web and beyond. Most importantly, however, a correctly-configured PKI is the distance between your business and an imposter air conditioner that wants your hard-earned cash.