Make My Day [IO]

Trying to repair a jura nespresso

Sat, 03 Mar 2018 14:40:04 +0100

A few months ago, a broken Nespresso machine fell into my hands. The first thing you notice when you try to repair a Nespresso machine is that you can’t open it because it has the weirdest screws that you have ever seen. However, everything can be solved when the comunity comes together, as Cristopher M. Lott demonstrates in his awesome post Repairing a Jura Nespresso Machine. It turns out that people started building special tools to turn the oval screws that are found in this machine, and sell it online.

A dead machine: Info gathering

Once I got the tool from ebay I decided to attack the issue and started gathering information about the machine’s behavior. It has two buttons: The red one turns the machine on and off, and the other one is used to make the coffee. Usually, when you press the red (left) button, a LED inside the right (white) button starts blinking until the machine is ready (hot enough) to make coffee.

In my case, when the red button is pressed, the green LED blinks twice and the machine turns off. So I cracked it open and examined it.

One thing I noticed really fast is that the machine actually heats a little when the red button is pressed. Also, after exposing all the connections, nothing seemed like burned or broken. Nothing obvious like a loose wire or a popped capacitor.

When I disconnect what looks like the heat sensor from the main board, the led starts blinking periodically. I asume that’s a good sign. It also means there should be some kind of logical circuit ruling the board. Maybe a programmable one. After removing all the screws I found what I was looking for hidden behind the main board: A PIC16F676 microcontroller. Does this mean that I may be able to reverse and reprogram the machine after repairing it? That would be so cool. But first thing first.

The fix

As I did not see anything obvious I did some internet research, and after some time I found this (spanish) video from reparatumismo.org. It seemed like it could be one or both of the big, blue polyester capacitors. According to the video, it’s a rather usual problem with that particular model, and it can be easily solved by changing the 470nF capacitor by a 680nF one.

So I ordered those on ebay and a few weeks later I replaced it as the video said. Now I have a functioning-nespresso :)

Wonder if I can hack it now…

Making secure backups in GNU/Linux with LUKS and rsync

Sun, 17 Dec 2017 14:04:08 +0200

In today’s post I’m going to explain how to securely backup your files using LUKS and rsync. Please, if you decide to follow the steps depicted here, remember that I’m not responsible for any loss of data that this may cause. Proceed with care: you can easily erase important information if you don’t know what you’re doing.

Let’s say that I want to backup my home directory on an external HDD, but I want my backup to be encrypted, too. There are a couple of alternatives: I can use Veracrypt or I can use Cryptsetup and LUKS. LUKS is the standard for Linux hard disk encryption, and this is the main reason I have decided to go with this one.

Creating and formatting your LUKS partition

First you need to create an empty partition on the external drive, for instance, using gparted. Make sure to make it big enough for the data you want to backup, and keep in mind that size of said data can and probably will be bigger in future backups.

Before we continue. Please, read the following. It’s important:

I’ll refer to this partition as \dev\sdb2 for simplicity, yours may or may not be the same one, so be extra careful if you copy and paste the commands written in this post directly. You may be fucking up your device and erasing the information you intend to backup. I also must warn you, the letter (a,b,c…) of each sd device may change after rebooting the machine, so each time you perform an operation directly on a partition or device, make sure that you are doing it on the right one. sudo fdisk -l or lsblk are your friends here. If you don’t quite grasp the concepts described in this paragraph, please find someone who can help you so you don’t fuck up your computer. You have been warned.

With that said, let’s continue.

If you want extra resilience to forensic analysis, you can fill the partition with noise before formating it. This will make impossible for an attacker to see the total size of the backed up data. This will take some time, so you can skip this step if it’s not necessary for your threat model:

shred --verbose --random-source=/dev/urandom --iterations=1 /dev/sdb2

Then, it’s time to format the partition with cryptsetup:

cryptsetup --verbose --cipher aes-xts-plain64 --key-size 256 --hash sha256 --iter-time 1000 --use-urandom luksFormat /dev/sdb2

These are the default values except for the hash which is more robust (SHA256 instead of SHA1). If you want to check the performance of each algorithm you can run cryptsetup benchmark.

This step will ask you to introduce a pass-phrase. Think of a good one and don’t loose it or you will be never able to unlock the partition again.

After your LUKS partition has been created, it’s time to format it.

Unlock:

cryptsetup open --type luks /dev/sdb2 mybackup

Format:

mkfs.ext4 /dev/mapper/mybackup

Mount:

mount -t ext4 /dev/mapper/mybackup /mnt/test-crypt

Change permissions:

sudo chown youruser:youruser /mnt/test-crypt

Unmount:

sudo umount /mnt/test-crypt

Ease your backups

Ok so, now you have an encrypted partition where you can put your data. But each time you want to perform a backup you need to unlock, mount, sync files, unmount and lock again. Those are a lot of steps, lets ease them.

First, find the UUID of the partition by typing ls -l /dev/disk/by-uuid/.

Each UUID points to a block device. We are interested on the one that points to our encrypted partition /dev/sdb2. It should look like:

lrwxrwxrwx 1 root root 2 Feb  1 10:22 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -> ../../sdb2

Add the following line to /etc/crypttab, using the UUID that you just found

crypt_backup UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none luks,noauto

Also add the following line to /etc/fstab:

/dev/mapper/crypt_backup /media/crypt_backup ext4 defaults,noauto,user 0  0

Now you can use the following script to backup your files (the ones contained in your home directory, in this example). You may need to reboot first.

#!/bin/sh
udisksctl unlock -b /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx && \
mount /media/crypt_backup && \
rsync -avP --delete-after /home/your-user/ /media/crypt_backup/name-of-your-backup/ \
umount /media/crypt_backup \
udisksctl lock -b /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Run it each time you want to backup your files.

Rhino Hunt (Part 1)

Tue, 12 Sep 2017 19:52:02 +0200

Lately I’ve been getting into digital forensics investigation and in order to train myself I’ve been looking for some challenges. I found this awesome website which has a great compilation of challenges, research results and CTFs.

I skimmed over the different options and decided to challenge myself with The Rhino Hunt, developed by NIST.

Context

The Rhino Hunt data set requires examination of a small image file and three network traces.

This image was contributed by Dr. Golden G. Richard III, and was originally used in the DFRWS 2005 RODEO CHALLENGE.

Scenario:

The city of New Orleans passed a law in 2004 making possession of nine or more unique rhinoceros images a serious crime. The network administrator at the University of New Orleans recently alerted police when his instance of RHINOVORE flagged illegal rhino traffic. Evidence in the case includes a computer and USB key seized from one of the University’s labs. Unfortunately, the computer had no hard drive. The USB key was imaged and a copy of the dd image is on the CD-ROM you’ve been given.

In addition to the USB key drive image, three network traces are also available—these were provided by the network administrator and involve the machine with the missing hard drive. The suspect is the primary user of this machine, who has been pursuing his Ph.D. at the University since 1972.

For the purpose of solving this challenge, I have to do the following task:

Recover at least nine rhino pictures from the available evidence and include them in a brief report. In your report, provide answers to as many of the following questions as possible:

Who gave the accused a telnet/ftp account?

What’s the username/password for the account?

What relevant file transfers appear in the network traces?

What happened to the hard drive in the computer? Where is it now?

What happened to the USB key?

What is recoverable from the dd image of the USB key?

Is there any evidence that connects the USB key and the network traces? If so, what?

Let’s begin!

The USB key image

First I check the integrity of the image file that I have been given. The MD5 checksum of said file can be found in the challenge’s formulation.

80348c58eec4c328ef1f7709adc56a54 RHINOUSB.dd

We acknowledge that the checksum of our file is the same:

$ md5sum RHINOUSB.dd
80348c58eec4c328ef1f7709adc56a54  RHINOUSB.dd

Now we know we are dealing with an untampered image file. Let’s gather some more information of the file:

$ fsstat RHINOUSB.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT16

OEM Name: mkdosfs
Volume ID: 0x4092d9d1
Volume Label (Boot Sector):            
Volume Label (Root Directory):
File System Type Label: FAT16   

Sectors before file system: 0

File System Layout (in sectors)
Total Range: 0 - 506847
* Reserved: 0 - 0
** Boot Sector: 0
* FAT 0: 1 - 248
* FAT 1: 249 - 496
* Data Area: 497 - 506847
** Root Directory: 497 - 528
** Cluster Area: 529 - 506840
** Non-clustered: 506841 - 506847

METADATA INFORMATION
--------------------------------------------
Range: 2 - 8101622
Root Directory: 2

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 2 - 63290

FAT CONTENTS (in sectors)
--------------------------------------------
529-536 (8) -> EOF
537-544 (8) -> EOF

Before I perform any file recovery or string search on the image, I open it with a hex editor. I wanna take a look at it. The root directory of the FAT filesystem begins on sector 497, at 512 bytes per sector, this means that the offset is 254464. I find that the USB key had only two allocated files. gumbo1.txt and gumbo2.txt

A huge portion of the file is filled with the same bytes over and over. It’s like part of the disk has been manually overwritten with the message “SORRY” and “CHARLIE” (Coincidence? :P)

Ok, time to recover some data, I will be using PhotoRec, and see what I can retrieve from this weirdo.

After going through the whole image file, PhotoRec has retrieved 134 files:

1 .doc file
7 .jpg files
2 .gif files
124 .txt files

So… have I found the 9 rhino images yet? Sadly, no. There are 4 rhino images, and 5 alligator images. I proceed to document the images found by computing the MD5 checksum.

Ok, so the next logical step is to take a look at the other recovered files, staring by the .doc file, which title is

f0335017_She_died_in_February_at_the_age_of_74.doc

This seems to be some sort of personal diary. I skim over them, I’m looking for a lead. And I find it in the las two entries:

This piece of evidence shows that the suspect freaked out and got rid of the hard drive of the computer. This makes sense as the computer was found without a hard drive. Also, this leads point to the existence of more hidden pictures in the USB. The accused then formatted the USB drive, thinking that such action would erase the contents of the memory. The suspect also talks about changing a password of a “gnome account” that Jeremy gave him/her. I should take a look at the network traces and see if I can find activity related to this sentence. But first, let’s take a look at the .txt files.

At first glance, the .txt can be grouped as follows:

Two files containing recipes
One 53MB file, filled with the message “SORRY” over and over
One 116.8MB file, filled with the message “CHARLIE” over and over
120 files of different sizes filled with the message “CHARLIE” and one last character.

I suspect that there must be a lead embedded somehow in this files. But I’m not familiar with the stego technique that may have been used. I can only guess. Also, speaking about stego… Is it possible that the alligator pictures contain rhino images or secret messages embedded in them? It would make sense, but I have no clue of which algorithm could have been used.

Maybe it’s time to look at the network traces and see if I can get any relevant data from them. The suspect had to use some script or program to hide the images and maybe I can find the download among the trace.

First network trace

I first check the integrity of the files rhino.log, rhino2.log and rhino3.log. Once I’ve done this, I proceed to open the first file with Wireshark.

It looks like the IP address used by the suspect’s machine is 137.30.122.253. This first trace contains 6557 captured packets. I decide to filter by the TELNET protocol. The TELNET communication happens between the suspect machine and a machine with IP address 137.30.120.40. There seems to be two TELNET sessions in this trace.

First TELNET session

The session starts by exchanging some parameters and the remote maching asking for a username and a password. The suspect enters the following credentials.

Username: gnome
Password: gnome123

After the login, the user gnome starts executing some commands on the shell: ls, du, df… and then, passwd. He wants to change his password. The first try was gnome1234 but the terminal prompted “passwd: Old and new passwords must differ by at least 3 positions.”, so he tried gnome12345. The program then exits with the message “Permission denied”.

Then the user tried to logout twice with the non-existing command “logout”, after which he wrote “exit” and successfully logged out from the remote machine.

Second TELNET session

The session starts by exchanging some parameters and the remote machine asking for a username and a password. The user tries to login with the username “golden” but fails. The user then logs in with the same credentials as the first session and then executes:

cat > JOHNREADME

And starts typing:

I tried to hack Golden’s account but the password was wrong.

- Georgia

It looks like someone is leaving a message for John. After saving the file, Georgia executes ls -l and something catches my attention. I did not mention it, but during the first session, when the user gnome executed ls -l there was only three files and now there are 7. This is a screenshot of the first session:

And here’s a screenshot of the second one:

Here are some suspicious files: rhino1.jpg, rhino3.jpg and contraband.zip. Someone must have uploaded them between the first and the second session.

After that last command the user tries to logout with the non-existing command “logout” (again), after which she wrote “exit” and successfully logged out from the remote machine.

Someone uploaded the files to the remote machine… If this has been done using the same machine that the suspect uses, there are several protocols that he could have used. But something tells me it’s gonna be FTP.

FTP session

My hypothesis was right. Just after the first TELNET session, a FTP session is started and the user gnome uploads the file rhino1.jpg

The file rhino3.jpg is uploaded right after.

The file contraband.zip on the other hand, is uploaded right before the second TELNET session.

I should be able to retrieve the files from the network packets, I’ll begin with rhino1.jpg.

First we have to find the packet with the beginning of the file. I find right after the STOR request has been accepted.

The file signature of a JPEG file is composed of two bytes: FF D8 as can be seen in the screenshot. In order to extract the whole file, I only have to right-click the packet and select Follow->TCP Stream. The We just save the data as RAW with the name “rhino1.jpg”

Looks like I found the fifth rhino! I repeat the process with the file rhino3.jpg and obtain the following image:

Now I can recover the file contraband.zip, following the same steps. But after I do it, I find that it has been encrypted. There’s only one file in it, called rhino2.jpg. What could the password be?

Second network trace

This trace contains HTTP traffic. I take a look at the HTTP objects and see that two more rhino images have been transfered. The images have been downloaded to a machine with IP 137.30.123.234 from a machine with IP 137.30.120.37 and hostname www.cs.uno.edu. The route of the images at the remote machine is: /~gnome. The names of the pictures are rhino4.jpg and rhino5.gif.

Third network trace

This trace also contains HTTP traffic. The user has downloaded an executable program called rhino.exe from a machine with IP 137.30.120.37 and hostname www.cs.uno.edu to a machine with IP 137.30.123.234. This program is maybe the one that the suspect has used to hide rhino images among those TXT files.

Second round

Let’s list all the loose ends that we still have:

We have found an encrypted rhino picture inside a zip container, but don’t know the password.
We have a bunch of TXT files and alligator pictures that may or may not hide relevant data.
We have an .exe file which purpose we so far ignore.

Relevant retrieved data (so far)

Four rhino images (1 - 4) have been found stored on the USB drive. These images had been deleted, but have been recovered from the unallocated space. Two images (5 - 6) have been recovered from the rhino.log trace. Two images (7 - 8) have been recovered from the rhino2.log trace.

f0106393.jpg with MD5sum ca03f2eed3db06a82a8a31b3a3defa24
f0106409.jpg with MD5sum ed870202082ea4fd8f5488533a561b35
f0106865.gif with MD5sum 76610b7bdb85e5f65e96df3f7e417a74
f0106889.gif with MD5sum d03dc23d4ec39e4d16da3c46d2932d62
rhino1.jpg with MD5sum d5a83cde0131c3a034e5a0d3bd94b3c9
rhino3.jpg with MD5sum b058218ea0060092d4e01ef3d7a3b815
rhino4.jpg with MD5sum aa64102afff71b93ed61fb100af8d52a
rhino5.gif with MD5sum 1e90b7f70b2ecb605898524a88269029

I’ll continue the hunt in the next post!

Lessons learned from building a Magic Hoodie

Fri, 28 Jul 2017 20:45:19 +0200

Earlier this month we were able to finish our magic hoodie project. It’s been a cool thing to build with the kids. Maybe a bit complicated, specially regarding the TCS3200 part, but they really liked the result. It worked pretty well with the poor code we developed. But I’m sure that they learned a lot.

The effect is rather magic: “Oh! Nice shirt, I like the color, let me copy it.”, one tocuh and BAM! the LEDs light the same color. However, being this my (our) first wereable project, I’ve learned some things that I want to share.

Connections are fragile

Yes, wereable electronics are for wearing (duh) them. This means the piece you have made will be dressed, moved, undressed and folded. This means that whatever you have soldered will break if not protected correctly. I learned this the hard way. First I was like: “Sure, some tape will do it”.

No, it doesn’t. LEDs stopped working randomly because the wires kept breaking.

So after that, we tried protecting the soldered connections with hot glue, and it’s safe to say it does the trick. However, LED stripes are not made to be bended constantly. Some of the internal lines of the strip broke, and as a consequence, some LEDs of the strip don’t light up. This is something to be taken into consideration: You have to treat the piece of clothing with care.

Using a 12V LED strip may be overkill

I chose to use a 12V strip because I read that 5V strips have powering issues when using more than 1m of the strip. Initially, I did not know how much of the strip I would use, so 12V looked like the best option. I ended up using 120cm of the strip so now I wonder if a 5V strip would have been enough (I am almost certain). The other problem of using a 12V power source is that the Arduino transforms a big part of the energy into heat.

Sewing properly is important

I used 8-wire telephone cable to connect the TCS3200 color sensor to the Arduino UNO hidden in the pocket of the hoodie. The cable keeps moving and although we tried to sew it directly several times, the thread kept breaking. Next time we should use sew a piece of fabric that holds the telephone cable on its place.

Conclusion

We made a very cool hoodie, but next time we’ll be extra careful with the connections, the strip and the sewing part, so we make a wereable electronics piece of clothing that also can last (at least more than 15 days). But it was a fun project.

Code can be found here

Playing with the TCS3200 Color Sensor

Fri, 19 May 2017 11:23:30 +0200

I’m working in really cool project with some of my students. We want to make a magic hoodie. The idea is simple: We take a basic hoodie, some LEDs, a color sensor, and an Arduino board. We decorate the hoodie with the LEDs, and try to make them mimic the color detected with the sensor. But the TCS3200 sensor is trickier than I first thought, so in order to understand it better, I’ve written this post. Hope it’s useful.

The sensor

The TCS3200 is a color sensor that comes with 4 white LEDs. It has an array of photodetectors with different filters (red, green, blue, clear). Inside the chip there’s an oscillator which produces a square-wave output whose frequency is proportional to the intensity of the chosen color.

Specs

Single-Supply Operation (2.7V to 5.5V)
High-Resolution Conversion of Light Intensity to Frequency
Programmable Color and Full-Scale Output Frequency
Power Down Feature
Communicates Directly to Microcontroller
S0~S1: Output frequency scaling selection inputs
S2~S3: Photodiode type selection inputs
OUT Pin: Output frequency
OE Pin: Output frequency enable pin (active low), can be impending when using
Support LED lamp light supplement control
Size: 28.4x28.4mm

Filters and frequencies

The TCS3200 allows the microcontroller to activate the different filters and also lets it scale the output frequency (fo). For this purpose, the S0, S1, S2 and S3 pins are used. The microcontroller can set the pins to HIGH or LOW in order to obtain the desired results.

To control de output frequency:

S0	S1	OUTPUT FREQUENCY SCALING
L	L	Power down
L	H	2%
H	L	20%
H	H	100%

To control the color filters:

S2	S3	PHOTODIODE TYPE
L	L	RED
L	H	BLUE
H	L	Clear
H	H	GREEN

At this point I had some doubts:

What’s the order of the frequency?
What’s the output frequency proportion?
What’s the proportion between different colors?

Figuring out how it works

Time to look at the datasheet!

Ok, here I can see the frequency values that I can expect when exposing the sensor to different colors. By looking at this information I can start thinking about a proper algorithm to measure color. I need to generate 8-bit RGB values that I can use to set the colors of the LED strip. I could measure the frequency with the clear filter first and then with the rest in order to generate this values consistently, as it seems that the frequency obtained with the color filters are dependent on the one obtained with the clear one.

Yes, I can break down the steps now:

Measure the four frequencies.
Compute the percentage of the clear frequency obtained by each color.
Transform (I’ll start by mapping), the percentages obtained to a 8-bit scale
Set the colors to the LED strip. (I’ve used a setup similar to this one).

I feel like writing a small library for this, It will ease everything.

Testing

It turned out that reading the datasheet and trying to decide the color from it just wasn’t enough. I needed to take some samples and watch the output for myself, so I wrote a very simple code (using my newly created library) that gave me the measured frequency for each filter as an output (the average of ten samples) and then tested it with different colors. These were the results:

With this data I was able to write a second iteration of my code, in particular, a generateRGB function which was able to translate the input provided by the sensor into 8-bit RGB values that I could use for the led strip. I used the graphs shown above to discuss with my students how could we approach this problem and they were very surprised of the results of their guessing. They had engineered a solution, and it worked!

The solution consisted on looking at the dominant color and then guessing the possible color “family” depending on the other values, in order to correctly mp the inputs to the outputs. In the following code, the array values contains the “clear frequency”, the % of red, % of green and % of blue. By % of [color] I mean the frequency obtained with that color filter expressed as a percentage of the clear one. The rgb array is an array containing the resulting 8-bit values: red, green and blue.

void Hoodie::generateRGB(int rgb[3], unsigned long values[4]) {
  // Begin with red. If >40 means it's the dominant color
  if (values[1] > 40) {
    // Red, Orange, yellow, Fucsia, pink...
    // Check blue
    if (values[3] > 30 ) {
      //Mix of red and blue: Fucsia / Pink
      rgb[0] = 255; // Max value
      rgb[1] = map(values[2], 18, 23, 0, 100); // For pink
      rgb[2] = 100;
    } else {
      // Mix of red and green: Yellow - Orange - Red
      rgb[0] = 255;
      rgb[1] = map(values[2], 17, 34, 0, 255); //min: red, max: yellow
      rgb[2] = 0; // We don't want any blue
    }
  // If not, check Blue
  } else if (values[3] > 40) {
    //check red
    if (values[1] < 30) {
      // No red: Blue colors / Turquoise
      rgb[0] = 0; // No red
      rgb[1] = map(values[2], 23, 30, 0, 100);
      rgb[2] = map(values[3], 40, 50, 0, 100) ;
    } else {
      // No green: Purple colors
      rgb[0] = map(values[1], 16, 39, 0, 100);
      rgb[1] = 0; // No green
      rgb[2] = 255;
    }
  // If not, check green
  } else if (values[2] > 30) {
    //check red
    if (values[1] < 30) {
      //Mix of green and blue
      rgb[0] = 0; // No red
      rgb[1] = 255;
      rgb[2] = map(values[3], 23, 34, 0, 100);
    } else {
      //Mix of green and red
      rgb[0] = map(values[1], 27, 34, 0, 100);
      rgb[1] = 255;
      rgb[2] = 0; // No blue
    }
  } else {
    // White / black
    if ( values[0] > 70000) {
      rgb[0] = 255;
      rgb[1] = 255;
      rgb[2] = 255;
    } else if (values[0] < 15000) {
      rgb[0] = 0;
      rgb[1] = 0;
      rgb[2] = 0;
    }
  }
}

Yes, it could be better, but it solves the problem for this project. The next step will be putting the pieces together in the hoodie and perform tests in different conditions :D

Setting up a Let's Encrypt SSL Certificate

Tue, 25 Apr 2017 14:04:00 +0200

Since I first thought of creating this site I wanted to set up an SSL certificate and to use HTTPS by default. Enabling HTTPS on your website enhances the security of your users in several ways:

Confidentiality: The messages between the clients (web browsers) and the web server are encrypted so no third party can read them.
Integrity: Not only the messages are secret, but they also have integrity protections, so no one can modify them or inject messages in the conversation between your browser and the server.
Authenticity: There’s another word for this. Trust. SSL provides a way for your browser to verify the identity the web server and trust it by using the so called SSL certificates.

Let’s take a look on SSL/TLS so we can add some light to how this is done:

SSL/TLS

SSL and TLS are cryptographic protocols that aim to provide privacy and integrity of communications. SSL is the predecessor of TLS but sometimes they are both called SSL. The goals of the TLS protocol are:

Cryptographic security: Secure communications between two parties
Interoperability: Applications using TLS built by different programmers should be able to exchange cryptographic messages.
Extensibility: TLS is a framework into which other methods can be incorporated. This means tat other protocols, like HTTP, can be used on top of TLS.
Relative efficiency: TLS tries to minimize CPU use, given that cryptographic operations tend to be highly CPU intensive.

How SSL Certificates work

Ok, so you can connect securely to an HTTP server using TLS (HTTPS) but you need a way to verify that the messages that you receive come in fact, from said server, and you’re not receiveing/sending messages from/to someone else. The server will have a private/public key pair, so it can sign a message and you can verify the signature. But how do you trust the public key that the server is handing to you? It could be handed by a man-in-the-middle attacker!

This is where the SSL certificate, and the Certificate Authorities (CA) play their role. You need a trusted Certificate Authority to sign the certificate of your web server if you want browsers to trust your public key (AKA show the green lock next to your URL). So basically, a SSL certificate proves the ownership of the public key. The key is signed by someone your browser trusts (CA), and therefore, it trusts the key as well. The CA is the responsible of verifying that the public key belongs to the owner of the domain, in order to sign it.

I decided to use Let’s Encrypt, a free and automated CA created by the ISRG. Next, I’ll show you how I generated and installed my Let’s Encrypt certificate on an NGINX server, and how I configured it to get an A+ rating on the Qualys SSL Server test.

Setting up the certificate with NGINX on Debian Jessie

Let’s Encrypt issues its certificates using the ACME protocol. This protocol allows a server to obtain a browser-trusted SSL certificate without human intervention. You can see how it’s done here.

So, the next thing I need is an ACME client that interacts with Let’s Encrypt server, in order to generate the certificate. I’ve chosen to use Certbot, because it’s the one recommended by Let’s Encrypt. If Certbot does not fit your needs, there are many more ACME clients.

1. Installing certbot

First, I needed to enable the Jessie Backports repository by adding the following line to /etc/apt/sources.list.

deb http://ftp.debian.org/debian jessie-backports main

Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates) in a stable environment so that they will run without new libraries (whenever it is possible) on a Debian stable distribution.

In order to install certbot

$ sudo apt-get install certbot -t jessie-backports

And we have successfully installed the client.

2. Obtaining a valid certificate

For the most part, next steps have been done following this and this.

There are many ways to obtain a valid SSL certificate with certbot. I’ve used the Webroot plugin. This plugin places a special file under the ./well-known directory in the root directory of your web server.

Certbot generates a key pair, then sends the public key to the Let’s Encrypt server and says something like “I’m the ACME agent of the domain yourdomain.com and this is my key. Challenge me!”.
Let’s Encrypt sends a nonce to certbot.
Certbot signs the nonce with the private key and places it under the ./well-known directory. Then it notifies Let’s Encrtypt again.
The CA then downloads the signed nonce placed in the public directory and verifies the signature.
If the signature is valid, then certbot is authorized to do the certificate management. The key pair becomes “authorized” and then it can send certificate management messages to Let’s Encrypt.
Then, certbot proceeds to ask the CA to issue a valid certificate for the domains it has proved ownership. This is done by generating a Certificate Signing Request (CSR). Certbot generates a new key pair. The CSR contains information about the domain, the recently generated public key and a signature with the associated private key. Certbot signs the CSR with its authorized private key and sends it to the CA.
The CA then verifies the signatures. If everything is ok, it issues a new certificate for the domain with the public key that was contained in the CSR.

Let’s see how to do this: In order to let certbot access ./well-known, you have to modify your nginx configuration file, usually under /etc/nginx/sites-available/default. Find the server block, and add the following lines between its brackets:

location ~ /.well-known {
    allow all;
}

You can test your changes with

$ sudo nginx -t

and restart nginx to load the new configuration

$ sudo service nginx restart

Now you are ready to obtain your SSL certificate!

$ certbot certonly --webroot -w /var/www/example -d yoursite.com -d www.yoursite.com -w /var/www/thing -d thing.is -d m.thing.is

In the example above, you will obtain a unique SSL certificate for yoursite.com, www.yoursite.com, thing.is and m.thing.is. It’s very intuitive, you use -w to point where the root directory of your site is and -d to point out the domains and subdomains used by the site. The webroot plugin will generate a challenge in each of the root deractories to check the ownership of the domains.

3. Server configuration

After executing certbot as described above, the following files have been generated under /etc/letsencrypt/live/yoursite.com:

cert.pem: The domain’s certificate
chain.pem: The Let’s Encrypt chain certificate
fullchain.pem: cert.pem and chain.pem combined
privkey.pem: The certificate’s private key

Once we have obtained the certificate we need to properly configure the server to use it. First, let’s install openSSL

sudo apt-get install openssl

Not only we want to use TLS, but we want to do it the right way. First, we should generate strong Diffie-Hellman parameters. Why? take a look. This can be done using the following command:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Next, we will configure nginx to:

Use these parameters
Use strong ciphers only, ensuring Perfect Forward Secrecy.
Use only TLS, not allowing SSLv3.
Use Strict Transport Security.

Again, we look for the server block in the nginx configuration file, and replace these lines:

listen 80 default_server;
listen [::]:80 default_server ipv6only=on;

with

listen 443 ssl; # SSL/TLS port

server_name yoursite.com www.yoursite.com; # REPLACE WITH YOUR DOMAINS
        
###
# SSL Settings 
###

# Certificate and key
ssl_certificate /etc/letsencrypt/live/yoursite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yoursite.com/privkey.pem;

# Protect your users by not using SSLv3 and previous protocols  
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;    

# WeakDH project recommended configuration for the supported ciphers
ssl_prefer_server_ciphers on;           
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
				
# Use strong DH parameters
ssl_dhparam /etc/ssl/certs/dhparam.pem;

# Other optimizations
ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 1h;
ssl_stapling on; 
ssl_stapling_verify on;

# Tell your clients that your site ONLY suports HTTPS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

If you want to learn more about how to properly configure TLS in NGNIX I recommend you to read this article.

Finally, in order to redirect port 80 to port 443, we add another server block with the following lines:

server {
    listen 80;
    server_name yoursite.com www.yoursite.com;
    return 301 https://$host$request_uri;
}

We can now test the syntax errors

$ sudo nginx -t

and then restart the server to load the new configuration:

$ sudo service nginx restart

Now you can test it! Visit https://www.ssllabs.com/ssltest/ and you’ll be able to see if you have properly configured your server.

4. Automated renewal

There’s a very simple command to renew a Letsencrypt certficate:

certbot renew

If you run this command, certbot will attept to renew every SSL certificate. But if the certificate is due in more than 30 days, it will return this message:

Cert not yet due for renewal

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/yoursite.com/fullchain.pem (skipped)
  No renewals were attempted.

If the certificate is due in less than 30 days, then it will renew it for 90 more days. I have created a cronjob that will try to renew the certficates every two weeks at 3 AM and then another one that will reload the nginx configuration 5 minutes later.

First I hit

$ sudo crontab -e

Then I add

0 3 1,15 * * /usr/bin/certbot renew >> /var/log/letsencrypt-renew.log
5 3 1,15 * * /etc/init.d/nginx reload

And there it is. A properly configured (A+) HTTPS web server with a SSL certificate that will be atuomatically renewed.

The battle of transfer protocols or "How do I update this site"

Sat, 15 Apr 2017 14:55:59 +0200

All right, so as you may know, this website is made with Hugo, the awesome static web generator created in go. I have also used the amazing base16 theme by Hylke Visser. I have tweaked it a lil’ bit so it fits my needs. Actually, after going through the documentation, I want to try and learn go. Next time, I guess.

Today I’m going to talk about how I update this static website.

One thing I really like about Hugo is that it comes with a tiny webserver so you can actually build your website in your local machine and see how your last update looks like. You can use, for example:

$ hugo server --buildDrafts

And your machine starts serving the website on port 1313. This is something I find really cool, because it means that you have a development and a testing environment all together. I like the simplicity of developing/testing locally and then uploading the updates to the production server. Check hugo’s quickstart guide to see how easily you can generate a static site with this tool.

Each time you’re done updating your site, you can just hit:

$ hugo

And volià! Your static website has been generated under the /public directory. Now you can upload it anywhere. But as always, there are different ways I could think about, namely ftp, scp, sftp and rsync. Lets take a look at them, shall we?

FTP

Ok, to be fair, I was not even considering this one. Mainly because all the transmissions in the File Transfer Protocol are in plaintext. It just amazes me how many hosting companies offer only this system to manage remote files. Just take a quick look at the Wikipedia article and you’ll get my point. It’s fine to use it when you’re connecting both machines through a VPN but I’m not creating a VPN just so I can use FTP instead of the multiple alternatives.

But what about FTPS?

FTPS is an extension of FTP. It adds support for TLS/SSL. This gives me a security layer that would meet my goals. There’s only one problem and it is that I have to install a FTP server that supports FTPS (like the FileZilla server), and then configure it to only use secure connections.

But I already have a SSH server running on the remote machine, and there are many ways to transfer a file over SSH… so what’s the point of adding another server? After all, SSH is a cryptographic protocol, not an extension of a non-cryptographic one, so there’s no way you can mess up in this aspect. Therefore, let’s see what options I can use over SSH.

SFTP, SCP, RSYNC

Here’s where I started doubting. In the beggining, every one of these options looked good to me. They all work over SSH, so there’s no need to install new software on the remote machine. I’ve used all of them for different purposes, such as backing up my data, accessing my smartphone files remotely or copying certain files quickly from/to a raspberry pi. At that point I could say they were all good enough for me, but as the goal of this blog is to learn new things (and do them right), I’ve done a little research to find the differences between these three programs in order to decide which one is the best to use by default.

SCP

SCP stands for “Secure Copy”. It works like the UNIX command cp but over SSH. You can either use it to copy files in a local machine or to/from a remote host. It’s a very simple command-line utility, and you can specify a few options. After a quick search I found some issues with this tool:

If the transfer is interrupted, it can’t be resumed
It makes a plain copy from A to B, regardless of the files in B.

Hence, this tool makes sense for a first upload, but not for the following updates, as I don’t want to be uploading the whole website each time.

SFTP

SFTP stands for “SSH File Transfer Protocol”. This protocol allows for many more operations than SCP. The program sftp is interactive, it allows you to navigate through the directories of the remote machine, and to put or get what you want. Even if this system would easily allow me to see what’s on the remote machine and quickly upload only what I want… it just looks too complex. I want something that allows me to update my files on the remote machine, without uploading them all again, and without having to check manually what do I have to upload. Something I can script once, then execute and zoop, it’s done.

RSYNC

Rsync is a copying tool. As SCP, it can copy both locally and to/from another host. It works over remote shell protocols or by using its own daemon. The thing that I find interesting about this program is the fact that it’s very versatile and allows for a lot of fine tunning. But there’s more. It uses a delta-transfer algorithm, which only sends the differences between the source files and the destination files. Also, it allows me to write my own filter rules, so I can script ahead what directories I want to update, delete or preserve. It looks like the perfect tool for what I want to do.

Final setup

In order to make my life easier, I use SSH public-key authentication. I also have written the following (trivial) script which I call zoop.sh

#!/bin/bash
# This script should be placed in the hugo working directory
hugo && rsync -rtuv \
	--delete-after \
	--exclude='not-hugo/' \ 
	public/ foo@remotemachine:/path/to/website/directory/

The script generates the static site with hugo and then calls rsync with the following options:

-r: Copy directories recursively.
-t: Preserve timestamps.
-u: Skips files which are newer on the destination than on the source.
-v: Verbose.
–delete-after: Delete files that no longer exist on the source after updating.
–exclude=‘not-hugo/’: Prevents rsync from deleting certain files, in this example, the not-hugo directory.

And that’s it! Once I’ve made and tested my changes to the site, I just call zoop.sh, hit my passphrase and the site is updated secrurely and efficiently :)

About

Sun, 09 Apr 2017 19:08:32 +0200

Welcome to Make My Day [IO], you’re probably wondering what you’re looking at. This is a personal blog. Who I am is not really relevant, just call me Charlie.

This is the place I’ve created to document my journey walking the path of hacking/making/tinkering with electronics, programming and much more. I love learning new things, playing with devices, cracking them open, looking at how things work. I am just a very curious person looking for a place to write about the things that make me happy. The things that make my day.

I’m by no means an expert, I am an eternal apprentice. However, I hope that what I share here helps you, just as what many others share openly helps me to better understand technology.

If you want to contact me, feel free to send an email to . For more information about how did I get here, read the first post.

PRIVACY

This website does not use cookies nor trackers of any kind and it uses HTTPS by default.

If you want to follow the updates of the blog, you can subscribe to rhe RSS feed of the site.

You can also follow them on my rather inactive Twitter account

First post

Fri, 07 Apr 2017 21:25:35 +0200

During 2016 I decided to join the Barcelona Hub project, created by the Inceptum Foundation. The Hub is a collaborative workplace, with different areas, including office and coworking space. The goal of Inceptum is to help and promote projects (from personal to corporate) with a special interest in those with a social purpose, non-profits, free software and STEM education projects.

But what made me join them is their workshop. The place I like to call The Makerspace. I came here with just one idea in my mind: Spend my days hacking and making things, learning about the stuff that I like: DIY, electronics, Linux, coding and security. It’s been a tough start, mainly because I’m a quite a chaotic being. So far I’ve been able to:

Create an emergency exit system based on an Adafruit Trinket by hacking a wireless-triggered alarm system.
Create a crappy, Raspberry Pi-based home surveillance system using a PIR sensor, a camera, a relay and a lamp.
Create a full-length smart mirror, using a Raspberry Pi and by repairing a broken 22” TV that I got for 10€.
Build a Prusa i3 3D printer.
Create an interactive art project using Processing, Arduino and the capacitance of the human body.
Make the most awesome marriage proposition by mixing my skills in videogames, networking, 3D printing, RFID, electronics and programming.
Repair my bike several times, saving some money.
Do a lot of microprojects that I’m putting together in order to create my first on-line course on programming, electronics and Arduino (in spanish).
Create this website using Hugo!

So I thought… Why am I not documenting these? I am constantly discovering things that I find useful and could be useful to others. I have always admired those who publish their projects and share them with everyone. Lots of anonymous people have helped me by sharing their experience and knowledge openly. I always wanted to do it. I finally feel confident that what I do may be handy to others, to you, maybe :) What I share in this place are the things that I like the most, my interests, the silly things that make my day.