DEV Community: Nikhil ponnuru

What if your laptop or hard drive with sensitive data is stolen or you lost it?

Nikhil ponnuru — Sun, 21 Jul 2019 09:54:42 +0000

Web privacy and security of the data is an area with constant limelight, but what about data that is locally on our systems?

Encryption is the way to achieve data protection on disk. This is especially needed if you are working at an enterprise and are storing sensitive business information.

We at our company wanted to encrypt our laptops and hence I did this below survey of all the available methods and a brief overview of how they work internally.

Need for system-level encryption:

To protect the data in case of accidental loss or theft of the disk/ device.
To protect the data from physical access by unauthorized people.
Disk/ device when discarded after the end of their life.

Encryption ensures that files are always stored on disk in an encrypted form. The files only become available to the operating system and applications in readable form while the system is running and unlocked by a trusted user. An unauthorized person looking at the disk contents directly will only find garbled random-looking data instead of the actual files.

Level's of encryption:

User space:

Application level encryption

Kernel space:

Filesystem encryption
Full disk/ HDD encryption
Volume encryption
Partition encryption

AES is the default encryption algorithm used in almost all types of below encryptions which is a symmetric block cipher encryption. Hence all the below encryptions work based on a passphrase/ password (single key).

Since it uses passphrase/ password entered by the user to generate the encryption key, if the user forgets it, it's the end of the story!

Does the encryption (especially full disk one) reduce the lifetime of the HDD or SSD?

In general, No. As you can see from the above picture, there is no need to perform extra reads or writes because the encryption module encrypts the data before the data is written to the platters and decrypts before it is sent to the process that performed the read. This is because most of these encryption algorithms use block ciphers (which is basically using blocks of data instead of one character to encrypt/ decrypt).

Filesystem encryption:

Filesystem-level encryption or file/folder encryption is a form of disk encryption where individual files or directories are encrypted by the file system itself.

The common way of achieving this is by Stacked filesystem encryption solution. These are implemented as a layer that stacks on top of an existing filesystem, causing all files written to an encryption-enabled folder to be encrypted on-the-fly before the underlying filesystem writes them to disk, and decrypted whenever the filesystem reads them from disk. This way, the files are stored in the host filesystem in encrypted form (meaning that their contents, and usually also their file/folder names, are replaced by random-looking data of roughly the same length), but other than that they still exist in that filesystem as they would without encryption, as normal files/ symlinks/ hardlinks, etc.

Home folder encryption is the most common file encryption, in which everything in HOME folder will be encrypted and decrypted on system login (boot time). From Ubuntu 18.04 support for this is stopped and only full disk encryption works.

Available solutions are eCryptfs(used by Ubuntu (until 16.04) and by chrome OS) and EncFS.

Disadvantages:

Cannot encrypt swap partitions, /tmp, /var, etc. system directories which may store sensitive user data.
File metadata (number of files, dir structure, file sizes, permissions, etc.) is not encrypted but names of files and folders are.

Read more:

The way it is implemented, is that to unlock the folder storing the raw encrypted files in the host filesystem ("lower directory"), it is mounted (using a special stacked pseudo-filesystem) onto itself or optionally a different location ("upper directory"), where the same files then appear in readable form - until it is unmounted again, or the system is turned off.

Full Disk encryption:

Full Disk Encryption is the process by which every bit of data that goes on a disk is encrypted. Everything on a disk, including the operating system, is encrypted. MBR(Master boot record which is responsible to load the OS) is not encrypted. Some hardware-based full disk encryption systems can truly encrypt an entire boot disk, including the MBR.

Operates below the filesystem layer. Doesn't care whether the content of the encrypted block device is a filesystem, a partition table, a LVM(Logical volume manager used to manage partitions) setup, or anything else.

Available solutions are: Loop-AES, dm-crypt +/- LUKS, VeraCrypt. Ubuntu(in fact most Linux systems) by default uses dm-crypt+LUKS. All of these are block device encryptions.

Advantages:

Can be done during OS installation.
Everything including the swap space and the temporary files are encrypted, ensuring no confidential data is inadvertently left unprotected.
The decision of which files to encrypt is not left up to users.
Installation of keyloggers or other Trojan horses becomes difficult with full disk encryption even with full system physical access.
Immediate data destruction, such as simply destroying the cryptographic keys (crypto-shredding), renders the contained data useless. Although physical destruction an option available always.

Disadvantages:

Attackers can break into the system over the internet or other ways after we have unlocked and mounted the encrypted parts of the disk and while it is running. (also a cold boot attack is possible)
A government entity may simply force the individual to give up the keys/ passphrases.
Cannot be done after installing the operating system. Need to enable/ setup only during OS installation process.
No proper GUI (except when using Veracrypt which is a 3rd party software for full disk encryption.)

One solution to the above disadvantages can be using Hardware-based full disk encryption (especially to the above first disadvantage) which removes the computer memory as a potential attack vector.

How to accommodate multiple users in one system in case of encryption?

Passphrase/ keys should be shared.

What if the OS crashes or something else gets corrupted, how to retrieve the encrypted data on hard-disk?

Taking regular backups of the important data is the easy and recommended way.

What if the user forgets passphrase/ password?

End of the story. Although we can employ recover mechanisms, then it doesn't truly serve the purpose of the encryption.

How to change the passphrase/ password?

For full disk encryption:
Using a utility called cryptsetup

For file/ folder encryption:
ecryptfs-mount-private command (if encrypted using ecryptfs which is common way in ubuntu until 16.04)

How to choose a secured passphrase/ password?

Check out these articles which gives a good insight on how to choose one.

Where to store the keys (passphrase/ password)?

Key management software.
Password managers.
Muscle memory.
An HSM or other hardware key management appliance, which provides the highest level of physical security.

Is the passphrase/ password we enter is the key to encrypt the entire data?

No. Firstly since this is symmetric encryption, there is one Master Key (No, not the passphrase you enter) that can decrypt's everything. The Master key is generated during the encryption time and is stored in encrypted form along with encrypted data on the disk (yes side by side with data).

The entropy(randomness) of the key is of utmost importance for the security of the encryption. A randomly generated byte string 32 bytes (256 bits) has desired properties. But can you remember 32 letters of a passphrase? Which is why passphrase is not the master key.

This is what happens after you enter the passphrase:

step 1: User enter's passphrase at mount time

step 2: A Key derivation function is applied to this Mount passphrase (e.g PBKDF2 also used by Django along with salt) which generates a Mount key.

step 3: This above Mount Key is used to decrypt the encrypted Master key generated during the process of File system/ Full disk encryption.

step 4: This decrypted Master Key decrypts everything now.

This is a slow process but as it only happens during mount time, so won't be significant.

Interesting fact about file system encryption using eCryptfs or encFs:

Each and every file is encrypted with a unique, randomly generated key called the 'fek' (which is stored in the header of the file, and wrapped with the MOUNT passphrase). What this means is that two cleartext files that are binary equivalent encrypt to two completely different ciphertexts.

Make a request between frontend and backend locally running on different ports without CORS issue

Nikhil ponnuru — Mon, 17 Jun 2019 11:36:35 +0000

Whenever you run frontend and backend in the same system in 2 different ports, you may soon find yourself facing a CORS error.

What is CORS?

From MDN

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.

What is an Origin?

Web content's origin is defined by the scheme (protocol), host (domain), and port of the URL used to access it. Two objects have the same origin only when the scheme, host, and port all match.

For e.g: If you make a request for a resource in www.xyz.com from www.abc.com site, it leads to a call for CORS by the browser since the origin is different.

Running both frontend and backend servers locally:

When running a project locally on your system, you may have to start servers of both frontend (like nodejs etc..) and backend (like python, go-lang etc..). To run these two servers on same system you need to have two different ports assigned to them. (since one port at a time can only accommodate one process).

For e.g frontend server can be running on localhost:8001 and backend server on localhost:8002.

Whenever we make a request from localhost:8001 (frontend) to localhost:8002 (backend), since they both are two different origins, leads to a CORS issue. How to solve this issue?

Some ways of handling this:

1) Server side: check this. Use "Access-Control-Allow-Origin" headers in response from various servers to tell the browser that the current request for cross origin is allowed. (remember CORS is the way of telling browser using http headers that the cross origin request made for the resource is fine and can be allowed)

2) Client side: check this.

3) Using Reverse Proxy:
I have explained what is a reverse proxy here . Do check it out before reading further.

I feel using a reverse proxy like Nginx is a pretty neat solution than the above two ways.

Steps to use reverse proxy for this usecase:

I have tried and tested the below steps using Nginx.

step 1) Run the frontend at say port 8001.

step 2) Run the backend at say port 8002.

step 3) Let's say all the backend requests are separated from frontend URL's by '/api/' or any other such seperation.

step 4) Run the reverse proxy at a port say 8000

Sample Nginx configuration: server block

server {
        listen       8000; 
        server_name  localhost;
        location / {
       proxy_pass http://localhost:8001;
        }
        location /api/ {
           proxy_pass http://localhost:8002;

        }
}

If you are not familiar with reverse proxy, check my post explaining it.

Now the beauty of using a reverse proxy is you can run the frontend and backend at the same port 8000. But didn't we learn that a single port is bound to one process? well whenever you make a request to the endpoint with localhost:8000/api/*, the reverse proxy redirects it to 8002 (backend) and all requests without '/api' are redirected to 8001 (frontend).

This solves CORS issue since the origin is same, which is 8000 here.

Understanding Proxy, Reverse Proxy, Load balancer and more.

Nikhil ponnuru — Fri, 14 Jun 2019 14:21:10 +0000

The word proxy means to act on behalf of someone else.
When it comes to web there are 2 kinds of proxies. Forward proxy and Reverse proxy.

Forward proxy or just Proxy:

Let's consider few scenarios:

i) You want to surf the internet without your IP address being visible to any website out there.

ii) You want to access Geographically blocked or restricted content.

iii) You are an admin to some firm or school and want to restrict the users from accessing some malicious websites or a some specific websites.

One solution to these kinds of scenarios is to use forward proxy. A forward proxy sits infront of the user and forwards the traffic from to internet.

How a forward proxy helps in above scenarios

i) A forward proxy, which itself is a server (a network node) will have its own address. Now this IP address of proxy will be visible to the websites or applications but not the user's IP address.

ii) Geo-blocking or a location based restriction is done using a users IP address. Yes, your IP address is more than numbers. It can provide the approximate address of your location. But how does our IP addresses can give away our location? If you go to services like this, you get to see your country, state and city. It sources its info from databases provided by ipinfo or ip2location services which provides mapping between a particular IP address and the location details. But how does this database get's filled? Well entities like ISP, Regional Internet Registry or some other data sources like a weather website when you type your pincode/ zip number which will then be linked to your IP address. so the list continues.

So if a service want to Geo-block or restrict you all they need to do is use this database provided by Geo-tracking services and blacklist these IP address.
A proxy here can help you to surpass this if it is in the region of the whitelisted IPs.

Should Geo-tracking using IP address be considered a worrisome issue? The answer mostly is No. They are used for many serious business use cases. For e.g a bank can use this to prevent suspecting transactions, fraud detection, a browser may use your IP address to set a default search engine etc.. good use cases are many! but that cannot be ruled out from them being misused.

iii) You can have filters in your forward proxies that can drop the outgoing traffic to certain websites which you as an admin want to achieve. (Does it sound like a firewall? well its the opposite of the firewall)

Forward Proxy: (User <--> Forward Proxy) <--> Internet <--> (Application/ servers)

Reverse Proxy:

Let's consider the scenarios:

i) Users are accessing some resources frequently, like some static assets.

ii) You want to compress the response of your server before sending it to the users.

A reverse proxy sits infront of the servers unlike forward proxy which sits infront of the users. A reverse proxy handles the incoming traffic to servers before hitting servers and sends back the responses.

How a reverse proxy helps in above scenarios:

i) A reverse proxy server can act like a caching server. A user request first hits the revers proxy which then can serve if it has the necessary data else forward it to server behind it.

ii) You want to compress the response but the compression logic can be heavy on the regular server depending on the payload size of the response. This logic can be safely separated from the actual server to a reverse proxy.

Other users: For doing SSL encryption and decryption, for Load Balancing (well then what's the difference between reverse proxy and a load balancer?)

examples: Nginx

Reverse Proxy: User <--> Internet <--> (Reverse Proxy <--> Application/ servers)

Load Balancer:

From Nginx website:

Load balancers are most commonly deployed when a site needs multiple servers because the volume of requests is too much for a single server to handle efficiently. Deploying multiple servers also eliminates a single point of failure, making the website more reliable. Most commonly, the servers all host the same content, and the load balancer’s job is to distribute the workload in a way that makes the best use of each server’s capacity, prevents overload on any server, and results in the fastest possible response to the client.

So in simple terms a load balancer is like a traffic police that diverts the traffic to number of servers in order to scale the traffic horizontally.

Well 2 interesting questions can arise here

Q1) What's the difference between Reverse proxy and a Load balancer?
A) A Load balancer as said is meant to balance the traffic between servers but a reverse proxy will/ can do Caching, Security, SSL encryption decryption etc. along with load balancing the traffic.

Q2) If a Load balancer diverts the traffic to number of servers behind it then how does it maintain the session? will it mess up with the session data that we store in between 2 http requests by passing the traffic to server 1 once and server 2 next?
A) This is a problem handled by the load balancers :). For example Nginx does it through Session persistence.

examples of Load balancers: HA Proxy, Nginx.

In my next post I discussed an interesting usage of Nginx as a reverse Proxy.