News items for tag campwireless - Koos van den Hout

As someone interested in security I'm also busy with securing the websites I develop and run. I'm looking at Content-Security-Policy headers and I notice those seem 'easier' for sites that have one task and one source of development like Camp Wireless and somewhat harder for sites that collect pages/scripts/materials over the years like idefix.net.

Although Camp Wireless can have some advertising, which suddenly turns the whole thing around since advertising scripts can load other advertising scripts completely dynamic. Searching for 'google adwords' and 'Content-Security-Policy' gave me Can Content Security Policy be made compatible with Google Analytics and AdSense? and the answer seems to be either "no" or "with a lot of work which you have to keep updating".

Update: I temporarily added a Content-Security-Policy-Report-Only directive to get an idea what kind of problems I will run into (with my own reporting backend). A lot of them. All inline javascript is suddenly a problem. So a 'fully secured' Content Security Policy header is already hard for single task, single source websites, let alone websites with a lot of history in the pages.

The new Camp Wireless that looks almost the same, but is completely rewritten is on-line.

It should look and work better on mobile devices. According to the statistics about half of the visitors is using a mobile device, so that is an important part.

I am a great fan of not breaking existing links, so they will keep working. There is a change in the url scheme for the site, but all old links redirect to the correct new location.

The details: Camp Wireless was completely written in PHP since the start of Camp Wireless in June 2004. But I didn't update the code a lot over the last years because I wasn't using PHP anymore and doing all my newer webprojects in modperl. This was becoming a risk, I didn't like updating the code anymore. I had to fix several things when I moved from the old homeserver to the new one because the new system came with PHP 7.

Since the url design of Camp Wireless was 'technology neutral' from the start (the main urls do not include .php or other hints to the used technology) it was possible to rewrite it in another language, as long as it could handle all the urls the same way.

I made one change to the url scheme: in the old setup the directory of campsites had urls with /database/region/ and /database/site/. Although there is indeed a database behind the site, the better term to use is directory, so I developed with /directory/region/ and /directory/site/ urls. And wrote a rewrite rule handler to redirect all the old links, because I don't like breaking old links.

I rewrote the site it in modperl. It was hosted on the development webserver and after implementing and testing each function I committed the result to version control. I still use cvs because that's what I once dove into.

After testing for a while with an acceptance version I finally made the switch today. After that I found a few functions missing so I added those promptly. Still using version control, so I know what I changed when and why.

In the last few weeks I had actual time to work on the planned rewrite of Camp Wireless in perl.

I rewrote it in perl and redid a small part of the CSS to use the CSS grid model to optimize Camp Wireless based on screen size. In the coming days I will create an 'acceptance' version of the site using the production version of the database, to iron out the last errors.

I still need to finish the correct 404 generation from within mod_perl scripts, advertising and some specific cases. And it's a good idea to run a website security scan on my work.

The look and feel hasn't changed a lot. I decided to present the same information in the same order and maintain most of the screenlayout.

A special feature I realized when working with the CSS grids is that I can change the order in which objects are displayed based on screen width. Or whether they appear at all on small screens.

So now I'm working on stylesheets that change the grid to what works better on a mobile device. Which is what a lot of the visitors to Camp Wireless use!

On a small screen I want the important content to come first. There is not enough space for the extras at the top, and a mobile visitor wants fast answers to the question "where can I find a campsite".

In my todo-list is a rewrite of Camp Wireless to stop maintaining PHP and make it more mobile-device friendly.

The reason to stop maintaining php is because I don't like it anymore which gives me a risk of having insecure code, which would be really bad for me. I'm rewriting it in Perl which isn't todays choice in web development either but it is what I can program good enough to avoid security errors.

The reason to make it more mobile-device friendly is that over half of the visitors to the site are using mobile devices. They want to find a campsite while travelling with a smartphone or other mobile device.

I was already using a media selector CSS, with variations for printer, I'm now looking at CSS grids which allows me to device the page into regions that move place depending on the available screensize. This makes separating content from page layout even easier.

On 25 december 2004 there was a special deal giving me the .info names camp-wireless.info and campwireless.info for free for the first year. Since that moment I kept the names registered and redirected all web traffic to the right version: https://www.camp-wireless.org/. So the deal worked from a 'selling domain names' perspective: Christmas is a bad moment to review the need for domain names, so the easy solution is to renew it. My decision to stop with these names was made in January 2018.

Traffic to the .info versions is very minimal. With the cost of the domain registration I decided to stop doing that and devised an exit strategy which would result in a domain name that attracts no traffic and is not linked to my other webprojects. On the next renewal date the domain will expire. I have done this before in a different context: when we ended the students personal webspace at www.students.cs.uu.nl.

The solution is to start returing HTTP state 410 Gone for search engines while at the same time returning a somewhat user-friendly error page.

Relevant bit of apache 2.4 configuration:

<VirtualHost *:80>
    ServerName www.camp-wireless.info
    ServerAlias www.campwireless.info
    ServerAlias camp-wireless.info
    ServerAlias campwireless.info

	DocumentRoot /home/httpd/campwireless-expire/html

    <Directory "/home/httpd/campwireless-expire/html">
        Require all granted
    </Directory>

    RewriteEngine On
    RedirectMatch 410 ^/(?!gone.html|robots.txt)
    ErrorDocument 410 /gone.html
</VirtualHost>

The gone page is simple: It has an explanation for human visitors and a meta refresh tag to redirect the browser eventually. But to a search engine the status 410 on almost any url will give a clear flag the page is gone and should be flushed from the cache.

I am slowly gaining trust in my Let's Encrypt setup and today I renewed my certificate. One thing I noticed on the first tries was that the whole process left me with a .well-known/acme-challenge directory in every website. Solution: use the options for a general configuration item available in Apache which is then inherited by all virtual hosts. So now I have in the general configuration in /etc/apache2/apache2.conf:

Alias /.well-known/acme-challenge/ "/home/httpd/html/.well-known/acme-challenge/"

<Directory "/home/httpd/html/.well-known/acme-challenge/">
        AllowOverride None
        Order allow,deny
        Allow from all
</Directory>

So now there is only one directory filling up with challenge-response files which is easier to clean out. I have seen filenames for challenge response with a - at the start so rm * started to complain.

The first complete change to https is on Camp Wireless, Wireless Internet access on campsites.

On Camp Wireless and The Virtual Bookcase I see the following pattern in the access logs:

2620:108:700f::36bc:aade - - [27/Mar/2015:13:27:11 +0100] "GET / HTTP/1.1" 302 298 "-" "curl/7.36.0"
2406:da00:ff00::36e2:d963 - - [27/Mar/2015:13:27:38 +0100] "GET / HTTP/1.1" 302 298 "-" "curl/7.36.0"

Constant requests, 2 or 3 per minute from Amazon EC2 IPv6 addresses just requesting the / using curl. Over the day I now see 1334 unique addresses with at most 5 requests from one url.

The same pattern as described in Stange stream of HTTP GET requests in apache logs, from amazon ec2 instances - Server Fault with no real answer to the why.

It's not a problematic amount of traffic, I'd just like to understand what is happenning!

Time to count IPv6 visitor percentage to different websites again:

Site	July 2009	July 2010	July 2011	July 2012	July 2014
http://idefix.net/ my homepage	1%	2%	2%	3%	4%
http://netwerk.pcgg.nl/ hcc!pcgg netwerkgroep	2%	2%	2%	3%	1%
http://weather.idefix.net/ weather maps	< 1%	5%	6%	7%	6%
http://bbs.idefix.net/ BBS files		1%	1%	1%	3%
http://webcam.idefix.net/ the webcam	< 1%	1%	< 1%	2%	2%
http://www.virtualbookcase.com/ The Virtual Bookcase	< 1%	1%	1%	4%	87%
http://www.camp-wireless.org/ Camp Wireless	< 1%	1%	1%	3%	70%
http://weatherstation.idefix.net/ Weather station Utrecht Overvecht					1%

Interesting numbers. Results for The Virtual Bookcase and Camp Wireless are totally skewed thanks to some IPv6 bot constantly checking the site from constantly changing IPv6 addresses .. but without privacy extensions enabled.

Method: unique IPv6 addresses seen in the whole month / total unique addresses seen in the whole month.

Time to count IPv6 visitor percentage to different websites again:

Site	July 2009	July 2010	July 2011	July 2012
http://idefix.net/ my homepage	1%	2%	2%	3%
http://weather.idefix.net/ weather maps	< 1%	5%	6%	7%
http://netwerk.pcgg.nl/ hcc!pcgg netwerkgroep	2%	2%	2%	3%
http://bbs.idefix.net/ BBS files		1%	1%	1%
http://webcam.idefix.net/ the webcam	< 1%	1%	< 1%	2%
http://www.virtualbookcase.com/ The Virtual Bookcase	< 1%	1%	1%	4%
http://www.camp-wireless.org/ Camp Wireless	< 1%	1%	1%	3%

Interesting numbers. Websites with a more 'general' audience are now also growing this year.

Method: unique IPv6 addresses seen in the whole month / total unique addresses seen in the whole month.