Set-Up “Let’s Encrypt” for Hiawatha Web-Server

Google announced that starting with Chrome version 68 they will gradually mark HTTP-connections as “not secure”. “Let’s Encrypt” is a free service for web-masters to obtain certificates in an easy manner. Work on “Let’s Encrypt” started in 2014.

Setting up “Let’s Encrypt” with Hiawatha web-server is quite easy, although there are some pitfalls. I used the ArchLinux package for Hiawatha. There is also a ArchWiki page for Hiawatha.

Another detailed description is: Let’s Encrypt with Hiawatha by Chris Wadge.

1. Unpacking and production-server setting. After installing the ArchLinux package I unpacked the file /usr/share/hiawatha/letsencrypt.tar.gz. You have to edit letsencrypt.conf at three places:

ACCOUNT_EMAIL_ADDRESS = your@mail.address
HIAWATHA_CERT_DIR = {HIAWATHA_CONFIG_DIR}/tls
LE_CA_HOSTNAME = acme-v01.api.letsencrypt.org           # Production

I struggled with the last variable LE_CA_HOSTNAME. This has to be the productive “Let’s Encrypt” server. Although you might register with the testing-server, you apparently cannot do anything else with the testing-server. So delete the testing-server. The rest of the configuration file is obvious to change.

2. Configuration file. Now check your hiawatha.conf file:

Binding {
        Port = 443
        #TLScertFile = tls/hiawatha.pem
        TLScertFile = /etc/hiawatha/tls/www.eklausmeier.tk.pem
        Interface = 0.0.0.0
        MaxRequestSize = 2048
        TimeForRequest = 30
}
...
VirtualHost {
        Hostname = www.eklausmeier.tk, eklausmeier.tk, 192.168.178.24, klm.no-ip.org, klm.ddns.net, edh.no-ip.org, edh.ddns.net, klmport.no-ip.org, borussia
        ...
}

Advertisements

Set-Up Hiawatha Web-Server

I stumbled upon Hiawatha web-server when I read about a web-server for a houseboat by Ronald Scheckelhoff, WB8LZR. I had used Apache, thttpd, Lighttp, NGINX, and others before. Now I use Hiawatha web-server.

Hiawatha has three objectives, which are nicely met:

1. Security: Hiawatha resisted Heartbleed and Slowloris attacks
2. Ease of use: use the man-pages for configuring the web-server, no extensive Googling
3. Lightweight on resources

Also see Hiawatha – the best webserver you’ve never heard of.

The following diagram shows the number of source code lines using

wc `find . -iname \*.c -o -iname \*.h -o -iname \*akefile\* `

for each web-server.

Below configuration mostly follows the example configuration and provides Perl and PHP as CGI:

ServerId = http
ConnectionsTotal = 1000
ConnectionsPerIP = 25
SystemLogfile = /var/log/hiawatha/system.log
GarbageLogfile = /var/log/hiawatha/garbage.log

Binding {
        Port = 80
        MaxRequestSize = 1572864
        MaxUploadSize = 2047
        TimeForRequest = 90,180
}

CGIhandler = /usr/bin/perl:pl
CGIhandler = /usr/bin/php-cgi:php

Directory {
        DirectoryID = DownloadArea
        Path = /Download
        ShowIndex = yes
}

Directory {
        DirectoryID = WebPresence
        Path = /
        ExecuteCGI = yes
}

Hostname = 127.0.0.1
WebsiteRoot = /srv/http

VirtualHost {
        Hostname = www.eklausmeier.tk, eklausmeier.tk, 192.168.178.24, klm.no-ip.org, klm.ddns.net, edh.no-ip.org, edh.ddns.net, klmport.no-ip.org, borussia.no-ip.org
        WebsiteRoot = /srv/http
        FollowSymlinks = yes
        UseDirectory = WebPresence, DownloadArea
}

So I have a directory where Hiawatha shows a graphical representation of some files I can download. And it has an ordinary directory where I serve HTML and PHP files. I had to change MaxRequestSize and MaxUploadSize as I sometimes upload large chunks of data.

Since the 2014 Microsoft shotgun attack on No-IP.org I have many different DNS names to better withstand this vandalism.

Enabling GD for PHP is described here: php-gd — just uncomment extension=gd.

Towards web-based delta synchronization for cloud storage systems

Very interesting article.

Some remarkable excerpts:

To isolate performance issues to the JavaScript VM, the authors rebuilt the client side of WebRsync using the Chrome native client support and C++. It’s much faster.

Replacing MD5 with SipHash reduces computation complexity by almost 5x. As a fail-safe mechanism in case of hash collisions, WebRsync+ also uses a lightweight full content hash check. If this check fails then the sync will be re-started using MD5 chunk fingerprinting instead.

The client side of WebR2sync+ is 1700 lines of JavaScript. The server side is based on node.js (about 500 loc) and a set of C processing modules (a further 1000 loc).

the morning paper

Towards web-based delta synchronization for cloud storage systems Xiao et al., FAST’18

If you use Dropbox (or an equivalent service) to synchronise file between your Mac or PC and the cloud, then it uses an efficient delta-sync (rsync) protocol to only upload the parts of a file that have changed. If you use a web interface to synchronise the same files though, the entire file will be uploaded. This situation seems to hold across a wide range of popular services:

Given the universal presence of the web browser, why can’t we have efficient delta syncing for web clients? That’s the question Xiao et al. set out to investigate: they built an rsync implementation for the web, and found out it performed terribly. Having tried everything to improve the performance within the original rsync design parameters, then they resorted to a redesign which moved more of the heavy lifting back to…

View original post 728 more words