Downtime for an Upgrade

An extensive upgrade to the machine which hosts this Web-server, in which 106 packages were brought up to their new version, took place between 20h25 and 20h45 tonight. Hence, the site would have been unavailable during that time, and because the Web-server itself was offline, it was not possible to display a Maintenance Mode screen, belonging to this blog.

The upgrade took place uneventfully, not breaking anything apparent so far, and leaving the computer fully functional.



Print Friendly, PDF & Email

I can make simple mistakes, configuring Linux services.

One of the things which I do, is to operate an ‘OpenVPN’ server, the sole intention of which it is, to give myself access to resources on my LAN, while I am someplace else, let us say with my tablet as a client. This OpenVPN server uses encryption to secure access to my LAN, including a private and a public RSA key-set. And one of the abilities which I would like to have, is to revoke a client public key, in case one of my tablets was ever to get stolen or otherwise compromised.

The way this works with OpenVPN, is that the file which stores the CRL needs to be identified to the server at start-up, but after that, any public keys added to that file are effective immediately, because OpenVPN will check this file, every time a client logs in, assuming again, that this file was recognized once, when the server was started.

And so I added the following specification to my VPN config file some time ago, to prepare my CRL for eventual use:

crl-verfiy /usr/share/easy-rsa/(...)

I was disappointed to find, that once, as a part of my log-rotations, my OpenVPN server was restarted on April 1, it simply refused to restart. The reason had something to do with this specification. And so I actually searched high and low to find an external reason.

One reason some users give for this not working, is the fact that on their systems, OpenVPN runs as a user different from ‘root‘, and that on those systems, the file ‘crl.pem‘ needs to be made readable by the username which OpenVPN runs under. But the way my distribution is set up, OpenVPN simply runs as root. And so this frequent recital of a reason on the Web, for which this specification might not work, actually slowed down how long it took me, to find the reason, which applies to my system.

It took me more than an hour, to see that I had mistyped something, in that I had entered an ‘f’ and and ‘i’ in the wrong order. So once I corrected this typo, the server restarted fine.

But the world of Linux is still such a place, in which such a typo on the part of the user can stubbornly prevent something from working, until the source of the error is uncovered. This does not change core ideas I have about how the world works. It simply reminds me, that I should not make careless mistakes such as this one.

And it reminds me, that in theory things might seem easier to do, than they sometimes are in practice.



Print Friendly, PDF & Email

Microsoft has Not actually Excluded Linux from UEFI.

This posting was the result of an error on my part, which led to more errors, in more postings.

My problem was, that even though the Linux version in question can be installed in UEFI mode, doing so without the Secure Boot option, disables all cryptographic checks on the booted image. Doing so simply installs the Linux version to use the UEFI BIOS system rather than Legacy, but without providing any EFI signatures for the image.

I apologize for the error.



Print Friendly, PDF & Email

Some Notes on the Merits of Hybrid Encryption

In my most recent postings, I sort of took the perspective, that ‘RSA’ is the only form of public key cryptography. But in reality, this is far from true.

As far as the actual public-key methods go, there is also ‘El-Gamal’ and ‘Diffie-Hellman’ in public use, as well as ‘DSA’. The last of those is only useful for signing, not for encrypting. But what that means in practice, requires that people understand another concept in public-key cryptography, which is called ‘hybrid encryption’, which marries one of the public key exchanges with strong, symmetrical encryption. Symmetrical encryption is any scheme where the same key can be used to decrypt, which was used to encrypt. Symmetrical methods in use include ‘AES’ and ‘Blowfish’, and several others.

A concept which exists purely with RSA, is that a sender of a message can use the public key of the recipient to encrypt, so that only the recipient will be able to decrypt, using his own private key.

Well, if we consider SSL-secured Web-sites, we do not see that our Web-browser needs to build any public and private key-pairs. And so according to that, it might be imaginable that the server has a public key to receive data with securely, but it is not obvious how the browser receives data securely from the server. And what actually happens with SSL, is that a pseudo-random key is built essentially by the client, and is then sent to the server securely via RSA. That key is then used by both peers, to send and receive the actual user data via strong, symmetrical encryption. And this idea, of only using public key-exchange to encrypt a strong, symmetrical key once per session, is referred to as hybrid encryption.

This also makes sense from the standpoint, that a single public-key, RSA encryption requires much more CPU time, than the repeated use of AES aor Blowfish.

TLS key exchange is based on methods, that more closely resemble Diffie-Hellman than RSA, but again forms a basis of hybrid encryption.

And this is also why SSH, which is also known as ‘Secure Shell Protocol’, only requires that the client have a DSA key. Given that an SSH client uses his public key to authenticate himself, in theory an SSH server can be set to allow RSA authentication, but then all the client must do is to encrypt a piece of data which he cannot control, using his private key, to prove to the server that he is in fact the owner of a stated public key.

Hence, for SSH authentication, DSA works just as well for the client to use.



Print Friendly, PDF & Email