Lossless JPEG rotation

JPEG is a lossy format, and naive rotation results in a loss of quality. JPEG does allow some lossless operations, such as rotation by 90 degrees and flipping, on the basic blocks (MCUs) that compromise the image. It also allows re-arranging those blocks. Using this lossless operation, it is possible to preform a lossless JPEG rotation. To do so, the rotated image mus meet some basic criteria like having it size a multiple of the MCU size (usually 16×16).

Not all programs preform a lossless JPEG rotation, so it is useful to be aware which does. I check a couple of commonly used program to see if they indeed preform lossless rotation. The testing procedure was:

  1. Start with the original JPEG photo.
  2. Rotate it once to the right using each program.
  3. Rotate a copy of the rotated photo back to the right using the same program.
  4. Compare using ImageMagick (compare -metric ae) the results.

Results

Gnome’s Image Viewer 3.14.1 is lossless
Digikam (4.4.0) is lossless, however rotating with Digikam’s Image Editor is lossy.
Shotwell (0.20.1) does lossy rotation.

en_IL: English locale for Israel

Update: The new locale was committed to glibc and should be part of glibc-2.24.

Most Israelis are literate in English, and for a large percentage of them, English is also the preferred language when it comes to computers. They prefer English, as it solves right-to-left issues and general inconsistencies (it might be annoying when some programs are translated ands some not). The downside is, that currently, the existing English locales are not suitable for Israel, as there are cultural differences:

  • American English spelling is more common in Israel.
  • The metric system is used, along with the relevant paper sizes (“A4” instead of Letter).
  • Dates are written in dd/mm/YYYY format, unlike in the USA.
  • The first day of week, and also the first workday is Sunday.
  • The currency used is ILS (₪).

So, up until now users had to choose locales such as en_US or en_GB and compromise on some stuff. To solve this issue, and create a truly suitable English locale for Israel, I wrote a localedef file for the en_IL locale.

To install the new locale, copy the en_IL file from the gist below and place under /usr/share/i18n/locales/en_IL (no extension). Next

# echo "en_IL.UTF-8 UTF-8" >> /usr/local/share/i18n/SUPPORTED

Now, complete the installation by running dpkg-reconfigure locales and enable en_IL.UTF-8 from the list, and set it as the default locale.

nginx and SNI

Server name indication (SNI) allows you serve multiple sites with different TLS/SSL certificates using a single IP address. Nginx has support for SNI for quite some time and actually setting it up is easy, simply add server entries for the corresponding sites. There is one caveat, the server_name entry must come before the server_certificate in order for SNI to be activated:

server {
    listen          443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}

is good, but

server {
    listen          443 ssl;
    ssl_certificate www.example.com.crt;
    server_name     www.example.com;
    ...
}

server {
    listen          443 ssl;
    ssl_certificate www.example.org.crt;
    server_name     www.example.org;
    ...
}

will serve the wrong certificate for www.example.org.

WordPress.com Login Loop

Sometimes, when I try to use certain functions on wordpress.com, I get redirected to a login page. After I sign-in, I get redirect again to the same login page. This repeats in an endless loop. It usually doesn’t bother me, as I self-host my blog, but for some things, like the yearly annual report that came in about two weeks ago, it does bother. I looked up into the matter, and the issue turned up to be due to blocking third-party cookies. To resolve the endless login loop, you need to add https://wordpress.com (note the https) to the exception list of accepted third-party cookies (In Firefox it’s under Preferences -> Privacy -> Exceptions).

Skip Updates When Using the Let’s Encrypt `letsencrypt-auto` Client

To use Let’s Encrypt CA to issue free certificates, you need to use their client. The recommended method to install it is to use letsencrypt-auto, a script that automatically fetches and installs all the required dependencies. There is no doubt, that the letsencrypt-auto is the fastest and simplest way to get a Let’s Encrypted client up and running. I’ve used it myself, when I wrote a guide to get Let’s Encrypt up and running easily.

Automatically updating required dependencies, has its downside. As letsencrypt-auto does it every time you run it, it quickly gets annoying. Running a simple ./letsencrypt-auto --help takes a whopping 15 seconds, just figuring out that there are no updates available. Supposing that you know that no update are available, and you wish to save some time, you can run the letsencrypt executable directly, skipping the updating process of lestencrypt-auto:

~/.local/share/letsencrypt/bin/letsencrypt

Most of the actions require you to be root, so you might need to run it with sudo.

You can expect this issue to be resolved in the future. There is already an open issue for it and an active work that will resolve it.

Installing Debian Unstable’s source Packages in Debian Jessie

Sometimes a package that you need is not available for Debian Jessie, but you can find it for Sid (unstable). You may be tempted to try to install it manually, by downloading the binary deb package, but it will most likely fail due to binary incompatibilities with different libraries’ versions you have. The better method will be to get the source package used to build the binary package, and build it yourself. Most of the time the process is not as hard as it sounds.

First, a short preliminary setup is needed Add the following lines to /etc/apt/sources.list:

deb http://http.debian.net/debian jessie-backports main
deb-src http://httpredir.debian.org/debian unstable main contrib

You can replace unstable with testing if you prefer to use packages from testing. Update the lists of packages

sudo apt-get update

Next you need, to get the build dependencies for your package. The example below uses the package lyx:

sudo apt-get build-dep lyx/unstable

Now you are ready to fetch and build the source package:

sudo apt-get source -b lyx/unstable

Finally, you will see in the current directory the resulting DEBs. Simply install them:

sudo gdebi lyx-common_2.1.4-2_all.deb
sudo gdebi lyx_2.1.4-2_amd64.deb

You can later mark the dependecies that you manually installed as automatic:

sudo apt-mark auto lyx-common

Installing the latest version of Iceweasel (Firefox) on Debian Jessie

The jessie-backports repository does not have the latest Iceweasel builds. However, the Debian Mozilla team releases its own backports. To use their backports follow the steps below:

# apt-get install pkg-mozilla-archive-keyring
# echo "deb http://mozilla.debian.net/ jessie-backports iceweasel-release" >> /etc/apt/sources.list
# apt-get install -t jessie-backports iceweasel

At the time of writing this post, the Mozilla team’s repository provides Iceweasel 42, compared with 38.4 with the regular Jessie repository.

Getting Started with Let’s Encrypt – Tutorial

A few days ago I got my invitation to Let’s Encrypt Beta Program. For those of you who are not familiar with Let’s encrypt:

Let’s Encrypt is a new free certificate authority, built on a foundation of cooperation and openness, that lets everyone be up and running with basic server certificates for their domains through a simple one-click process.

This short tutorial is intended to get you up and running with your own Let’s Encrypt signed certificates.

The first thing is to get the Let’s Encrypt client:

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

The main command we will be working with is ./letsencrypt-auto. The first time you will run it, it will also ask for sudo, install various dependencies using your package manager and setup a virtualenv environment.

The next step is to issue the certificate and prove to Let’s Encrypt that you have some control over the domain. The client supports two methods to perform the validation. The first one is the standalone server. It works by setting up a webserver on port 443, and responding to a challenge from the Let’s Encrypt servers. However, if you already have your own web-server running on port 443 (the default for TLS/SSL), you would have to temporarily shut it down. To use the standalone method run:

./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory certonly

The second method is called Webroot authentication. It works by placing a folder (.well-known/acme-challenge) in the document root of your server with files corresponding to responses for challenges.

./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory -a webroot --webroot-path /var/www/html/ certonly

Whatever method you chose, it will ask for a list of domains you want to validate and your email address. You can write multiple domains. The first one will be the Common Name (CN) and the rest will appear in the Subject Alt Name field.

This slideshow requires JavaScript.

The newly generated certificates will be placed in

/etc/letsencrypt/live/yourdomain.com/

The important files in this directory are fullchain.pem which contain the full certificate chain to be served to the browser and privkey.pem which is the private key.

An example Nginx configuration will now look like:

        listen 443 ssl;
        ssl_certificate /etc/letsencrypt/live/guyrutenberg.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/guyrutenberg.com/privkey.pem;

Just don’t forget to reload the web-server so configuration changes take effect. No more government snooping on my blog 😉 .

certificate

Gnome `Alt+Shift` and `Alt+Shift+Tab`

After installing Debian Jessie with Gnome 3.14, I noticed an annoying bug: When I tried to switch windows using Alt+Tab it worked as it should, but when I tried to switch in reverse order, using Alt+shit+Tab it did not work. I quickly figured out that the problem lies in the frequently used shortcut, Alt+Shift for switching keyboard layouts. Indeed, when I tried cycling through windows, I switched keyboard layouts instead.

The gist of the solution was found after some searching in Stack Exchange albeit it needs some adjustment for newer version of Gnome: Start the Gnome’s Tweak Tool and select Typing from the Tweaks menu. Under “Miscellaneous compatibility options” select “Shift cancels Caps Lock”.

alt-shift

This fixed the issue for me, without any side-effects. I don’t need to use Shift-Alt instead of Alt-Shift as suggested in the original solution and neither the Shift key cancels the Caps Lock as may be suggested by this option.

Securing Access using TLS/SSL Client Certificates

This tutorial will guide you in setting up authentication using TLS/SSL Client Certificates. It is a simple one as it would not delve into details about integration with server-side apps. Instead, it simply gives you instructions on how to set up Client Certificate as means to prevent unwanted parties from accessing your website.

For example, one such scenario where it may come useful, is limiting access to sensitive things on the server, like phpMyAdmin. phpMyAdmin for example handles sensitive data (such as database authentication) and does in plain HTTP, which may pose several security risks. Even if the data would be encrypted, someone with access to the application, might find vulnerabilities in it and exploit the relatively high-privileges it got to compromise the server. The solution to this, is also limit who has access to the application at all. A possible solution, which I’ve used, is to limit access to only to the local machine and using SSH or a VPN Tunnel to access phpMyAdmin. A better solution would be to use TLS/SSL Client Certificates. They operate on the connection level and provide both encryption and authentication. They are easier to setup than VPN tunnels and easier to use.

Note that limiting access based on TLS/SSL Client Certificate can only be done on the sub-domain level, because it happens as part of the connection, before any specific HTTP request can be made.

Most of the tutorial is not HTTP server-specific, however the server configuration part relates to Nginx. As other servers (such as Lighttpd) use a very similar configuration for Client Certificates, adapting the instruction should be straightforward.

Creating a CA

The two commands below will create CA private key and a corresponding self-signed certificate for you to sign the TLS client certificates with.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -aes-128-cbc -out ca.key
openssl req -new -x509 -days 365 -sha256 -key ca.key -out ca.pem

The first command will ask you for a pass phrase for the key. It is used to protect access to the private key. You can decide to not use one by dropping the -aes-128-cbc option from the command.

The second command will ask you to provide some details to be included in the certificate. Those details will be sent to the browser by the web-server to let it know which client certificate to send back when authenticating.

Server Configuration

Upload the ca.pem that was just generated to your server. You should not upload the private key (ca.key).

The following instructions are for Nginx

ssl_client_certificate /path/to/ca.pem;
ssl_verify_client on; # we require client certificates to access

Assuming you already enabled TLS/SSL for the specific sub-domain, your configuration should look something like this:

server {
        server_name subdomain.example.com;

        # SSL configuration
        #
        listen 443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/nginx/example.pem;
        ssl_certificate_key /etc/nginx/example.key;

        ssl_client_certificate /etc/ngingx/ca.pem;
        ssl_verify_client on;

After reloading the server, check that everything is configured correctly by trying to access your site via HTTPS. It should report “400 Bad Request” and say that “No required SSL certificate was sent”.

Creating a Client Certificate

The following commands will create the private key used for the client certificate (client.key) and a corresponding Certificate Signing Request (client.csr) which the owner of the CA certificate can sign (which in the case of this tutorial will be you.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out client.key
openssl req -new -key client.key -sha256 -out client.csr

You will be asked again to provide some details, this time about you. Those details will be available to server once your browser sends it the client certificate. You can safely leave the “challenge password” empty1.

You can add the flag -aes-128-cbc to the first command if you want the private key for the client certificate to be encrypted. If you opt for it, you will be prompted for a pass phrase just like before.

Signing a Client Certificate

The next step is to sign the certificate signing request from the last step. It is a good practice to overview it and make sure all the details are as expected, so you do not sign anything you would not intend to.

openssl req -in client.csr -text -verify -noout | less

If everything looks just fine, you can sign it with the following command.

openssl x509 -req -days 365 -in client.csr -CA ca.pem -CAkey ca.key \
    -set_serial 0x`openssl rand 16 -hex` -sha256 -out client.pem

You will be prompted for your pass phrase for ca.key if you chose one in the first step.

Installing Client Key

Now comes the final part, where we take the signed client certificate, client.pem and combine it with the private key so in can be installed in our browser.

openssl pkcs12 -export -in client.pem -inkey client.key -name "Sub-domain certificate for some name" -out client.p12

Adjust the -name parameter to your liking. It will be used to identify the certificate in various places such as the browser. If your private key was encrypted, you will be prompted to enter a pass phrase for it. Encrytion for certificates in p12 format is mandatory, so you will be prompted to enter a password for the generated file as well. It is OK to reuse the same password here, as those files are practically equivalent. Once imported to you browser, you would not need the password for normal usage, until you would like to import it to another browser.

GlobalSign provides instruction on how to actually install the p12 client certificate for browsers in Linux and Windows.

References


  1. It is used to “enhance” the security of certificate revocation request, by requiring not only knowledge of the private key, but also the challenge password. Thus, someone who got hold of your private key cannot revoke the certificate by himself. However, this is also the reason why this option is not used more often: When someone steals your private key, usually they will prefer the certificate not to be revoked.