News items for tag web - Koos van den Hout

After the recent work on updating the TLS settings for the webservers at home there was one element missing: TLSv1.3 support.

This needed an upgrade of openssl and the 'easy' way to get there was a full upgrade of the server running the external facing proxy. So I took that step yesterday evening. Made a snapshot first and started upgrading devuan ascii to beowulf.

After the update a lot of things were broken: I defined a non-standard location for bind9 logging and AppArmor disagreed. Without a working nameserver a lot of stuff breaks internally! So after managing to get on the upgraded system with console I changed the AppArmor rules to allow it. After that things started again.

For the next time I manage to break the resolving nameserver: I should remember that avahi/multicast dns works on most systems even when DNS resolving fails. I checked and I can use .local names to get to the right equipment.

After checking how everything is running for about a day I threw out the old snapshot.

I'm currently following the course The Best TLS and PKI Training Course in the World and learning even more about the workings of encryption, TLS and certificates.

One of the things I learned is to balance security with performance. And I directly used this new insight on my own webservers. The connection which brought you this page from https://idefix.net/ is still encrypted but I saved a few milliseconds on the encrypted setup by switching from a big (4096 bit) RSA private key to a 384 bit ECDSA key which are comparable in cryptographic strength. But the calculations with the ECDSA key are less CPU intense. And yes, I have statistics on page loading times before and after the changeover of the key.

It was a good moment to change private keys anyway, the old keys were more than a year old.

This is one of those areas where I like having my knowledge hands-on. Actually understanding what is happening and why.

In looking for something different I noticed requests for old urls for rss.php urls on a site. But that site was rewritten in a different programming language and I use a generic .cgi extension.

I had to look up how to do redirects with paramaters again because a RewriteRule directive in apache normally only uses the url, not the parameters. The page Redirecting and Remapping with mod_rewrite - Apache HTTP Server Version 2.4 gave me some hints, and I ended with:

    RewriteCond "%{QUERY_STRING}" "(.+)"
    RewriteRule "^/rss.php" /rss.cgi?%1 [R]

Which does exactly what I want.

A while ago the YouTube suggestion algorithm came up with a video about a TV journalist / cameraperson who decided to live and work full-time on a narrowboat in the canals of England. The suggested video: TV Journalist Quits His Job to Live on a Tiny House Boat & Cruise UK Canals Full-Time.

I guess the suggestion was in relation to some videos I watched about people with expedition vehicles.

After that video I checked out the YouTube channel mentioned in the video: Cruising the Cut and I got addicted. By now I have watched more than two-thirds of the videos in the channel. David Johns describes the first steps in buying the boat, getting the boat ready to live on and the journeys along the canal network in England. The exact measures of the narrowboat are to make it fit in the canals that were dug in England as the first way to move goods when the industrial revolution allowed centralized production. The boats are 2.08 meter (6 feet 10 inches) wide to fit in all the canals and locks. The canals were dug by hand, so they are no wider and deeper than needed to transport goods.

I did ask David about the term 'the Cut' because I couldn't find a good explanation for it. It is the term for the canal, because the canals were cut out of the land by hand.

For my Dutch readers who wonder about canals in a not completely flat landscape: canals in England have lots of locks, tunnels and aqueducts to deal with those.

Somehow this idea of a moveable home is nice to me. At the same time I am not a person for living on the water, and with all the plans for long cycling tours I still want to return to a nice home with all the comforts.

One note: I do notice that David Johns comes from a background in television. Great quality video. And yes, I am fully aware that takes a lot of editing.

• Cruising the Cut youtube channel
• Cruising The Cut website

It's the christmas holiday and that gives me some time to fix things that have been on the wishlist for a while. This includes some parts of the scripts that make up my homepage.

The update was a learning process, I found out getting caching right is still very hard and I learned about preformatted text and the CSS grid which worked differently than expected. All fixed now.

This is now fixed, and I may find more things to fix in the (near) future.

Changes include:

• The pages are now using a CSS grid
• Pages have a usable righthandside
• Updates to the footer have been made on all pages
• The history function of the newstag page has been fixed to give usable permanent urls
• The IPv6 check is active on more pages

I found out the mobile version of my homepage was a lot wider than the desktop version (which tries to fit on the screen). This didn't show when I learned about the CSS grid for Camp Wireless.

The difference is that my homepage regularly uses log samples which are displayed as preformatted text. I used the grid width 1fr which allows for the full width of <pre> items. Changing this to 100% fixed it. The desktop version uses two columns and those are already split using percentages of the full screen width.

After switching my websites to https I found out caching works differently on https (for good reasons) and files included by lots of pages got reloaded a lot.

So I added some caching hints. I especially did not want the stylesheet to be reloaded constantly. So I added an ExpiresByType directive to cache stylesheets for a week.

But on the change of camp-wireless to a new stylesheet and programming language I got bitten by this: some browsers had the old css code cached and saw no reason to check for updates. The site looked strange (but wasn't really broken).

I recently made some changes to parts of my homepage too, also going to the CSS grid model, just like the changes in Camp Wireless to the CSS grid model. And I had the same problems with the CSS in the production version. It took a bit of searching to find the source of the Expires statement, it was in the .htaccess file.

Now fixed to a much shorter cache time, it is quite possible to have versions of the pagecode and CSS differ in the browser.

Back when I started with world wide web things I created my own links page. For my own use, so I had my web links available on all my computers.

With the rise of 'search engine optimization' I started to receive requests to add certain links. First as bulk 'link exchange' mails but later as automated "personal" requests which have their own special rant.

The "personal" requests sometimes used interesting backstories such as a school project where the children had found such a good resource together and the teacher hoped to bring a smile to the childrens' faces by having the suggestion from the schoolchildren actually implemented.

So I added a line at the beginning of the page:

If you want to mail me to notify me about your very special link that really needs to be here to help children all over the world, enable world peace, would be the best resource ever or simply increase your pagerank: Don't. These are my links.

and this seems to help. For now.

I noticed the certificate for idefix.net was expired according to my webbrowser. I dug up the reason and found out the scripts to maintain the ocsp files managed to confuse the Makefile to keep the haproxy certificates updated.

The ocsp responses have more updates than the certificates, but a certificate update needs to be processed anyway.

So I updated the Makefile in the previous post. The dependency is now certificate-stamp depends on installed certificates, installed certificates depend on copied certificates. And installing the certificate also updates the ocsp response.

I have one Apache server exposed to the outside world for IPv6 clients (because of a history in hostnames going back to the 20th century). So after enabling OCSP for haproxy I decided to have a look at OCSP stapling for Apache 2.4. That's even easier than haproxy since Apache 2.4 will fetch the ocsp data itself. I followed Apache 2.4 SSL/TLS Strong Encryption: How-To OCSP Stapling and it works.

So now the current score at the Qualys SSL server test for koos.idefix.net is A+ both via IPv4 and IPv6.