h3artbl33d.nl

OpenSSH is the de-facto SSH implementation. It allows easy and secure management of remote systems. Seasoned SysOps (like yours truly) are suckers for a SSH config file - it can save an incredible amount of time and effort.

Why you should use a config file

• Shorter commands: Imagine being able to run ssh exq-masto rather than ssh -p 2222 -i ~/.ssh/exquisite h3artbl33d@exquisite.social.
• Per-host identities: No need to remember which keypair you setup on a remote system or what username you need to use.
• Security posture: Enforce strong ciphers and algorithms.
• Jumphosts: Seamless ProxyJump/ProxyCommand

Getting started

You will need the .ssh directory and the .ssh/config file. On OpenBSD, the .ssh directory is within the profile skeleton - meaning that you very likely already have it in your homedir. This is different on a number of Linux distributions. You should be aware that permissions matter. ssh(1) ignores insecure files and directories. If you don't have the .ssh directory, it can be created the following way:

mkdir ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config
chmod 700 ~/.ssh

For the most secure setup, you will need to use keypairs, rather than a password. You should encrypt the private file, by entering a password when prompted for it. A keypair can be generated like this (for ed25519):

ssh-keygen -t ed25519 -a 500 -f ~/.ssh/test -C "Fill in a comment"

This key is then stored as ~/.ssh/test. You might want to generate a unique key per remote host, or per group of remote hosts.

Enforcing the use of keypairs and disabling passwords is done in sshd_config(5) on the remote machine/server. That is out of scope for this article, all the details can be found in the sshd_config manpage.

Config file anatomy

An SSH config file is comprised of hosts and options for them. Like this:

Host $name
    Option 1
    Option 2
    Option etc

Basic config file

Say you want to shorten the command you have to enter, connecting to a host on the local network. In this example, we'll shorten the name to local-masto, which will connect to the IP address 192.168.1.2, port 2222, username h3artbl33d and an unique keypair. That will give the following config:

Host local-masto
    HostName 192.168.1.2
    Port 2222
    User h3artbl33d
    IdentityFile ~/.ssh/local-mastodon

Adding those lines to the config file (~/.ssh/config) will mean that we can connect to this machine by entering the command ssh local-masto. Behind the scenes, it reads the config file, gets the options from there and connects to it.

If you did it correctly and applied the private key encryption, you will be prompted to enter the passphrase each time you connect. You can use ssh-add(1) to 'remember' the password for the duration of your session (until you logout from your computer, that is). See the corresponding manpage.

Full config file

Below you'll find the example of a full config file, which might offer some inspiration and insights. For different options or what the below ones do, please refer to the ssh_config manpage.

Host exq-masto
    HostName exquisite.social
    Port 2222
    Username h3artbl33d
    IdentityFile ~/.ssh/exquisite
    IdentitiesOnly yes
    Ciphers chacha20-poly1305@openssh.com
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com
    HostkeyAlgorithms ssh-ed25519
    PubkeyAcceptedKeyTypes ssh-ed25519

Host local-masto
    HostName 172.16.42.2
    Port 1337

Host socks-proxy
    HostName 1.2.3.4
    Port 8081
    DynamicForward 8080

Host local-*
    User h3artbl33d
    IdentityFile ~/.ssh/localnet
    ProxyJump bastionhost

Host *
    ForwardAgent no
    Compression no
    IdentitiesOnly yes
    AddKeysToAgent yes
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m

Remarks:

• The order of ssh_config(5) matters. According to the manpage: "Since the first obtained value for each parameter is used, more host specific declarations should be given near the beginning of the file, and general defaults at the end." Thank you to @hucste@framapiaf.org for this pointer.
• The post-quantum key exchange algorithm sntrup761x25519-sha512@openssh.com is the default for ssh(1) and sshd(8) since OpenSSH 9.0. Since OpenSSH 10.1 both the client and server now produce a warning when a non-post quantum kex was negotiated.

As some of you might reckon, I ran a number of privacy-friendly services, front-ends for big tech platforms: the already defunct Nitter for Twitter/X, Jouwbuis for Youtube, Redlib for Reddit and Koekel/Searx for search engines. But no more. It has become way too much of a constant cat and mouse game and the instances had more issues than they were actually available for use.

This will free both some time and mindspace on my side, that I like to throw at the Fediverse and actually building stuff that is the future, rather than fighting big tech that won't be around anymore in a couple of decades. It has been a wild ride - but the time has come to step up and do the right thing - contributing towards humanity, rather than wasting it on ductaping the shit of big tech gazillionares together.

There are some alternatives:

• Reddit/Redlib: list of public instances - can be selfhosted relatively easy, including on OpenBSD
• Youtube/Jouwbuis: Piped (list of public instances, can be selfhosted through Docker), Cloudtube (official instance, can be selfhosted on OpenBSD, docs), Invidious (list of public instances, can be selfhosted). The most sustainable model is to use a client - in order to prevent Youtube blocking due to too much concurrent traffic. A good client for Android is PipePipe and Yattee for Apple devices. The latter one does need some configuration.
• Search: SearXNG (list of public instances, can be selfhosted), Whoogle (list of public instances).

Thank you for the fish - and hoping we'll meet again in a brighter future without big tech silos.

I have been using Ungoogled Chromium as my main (and mostly sole) browser for years. The Chromium codebase is more modern and secure than the alternatives. Ungoogled Chromium does not just rip Google out of the browser, it has some neat patches integrated that benefit security and privacy. Three of them expose flags that, when enabled, help to frustrate fingerprinting. Those flags are disabled by default, so you might want to consider enabling them:

chrome://flags/#fingerprinting-canvas-image-data-noise
chrome://flags/#fingerprinting-canvas-measuretext-noise
chrome://flags/#fingerprinting-client-rects-noise

While these flags do not prevent fingerprinting, they do randomize some of the output that is used to fingerprint.

Today, we live in an increasingly interconnected world. People and their devices are continuously in communication with one another. This enables us to reach out to beloved ones in mere seconds - something that was unthinkable a century before. Rather than writing a letter, sending it by snailmail and waiting weeks for its arrival, we are now able to grab our cellphone from our pocket, talk or start a videochat.

Every friend and relative is always within arm's reach thanks to this virtual and continuous connection, but it also presents some unique challenges. Constant dangers loom in the background, waiting for a moment of thoughtlessness to sway us into doing something we otherwise wouldn't have done. Within this virtual space, adversaries are constantly trying to eavesdrop on our private conversations and activities. One of the tools available to mitigate this, are secure messengers. They allow to have private conversations with others, by making sure there are no unwanted parties eavesdropping in.

However, these secure messengers aren't created equal.

Table of Contents

• Encryption
• Background
• Fundamentally broken
  • By default, chats are not end-to-end encrypted
  • Telegram uses non-standard encryption protocols
  • Telegram 'steals' the contacts
  • Weird storage of the chats and disclosures to LE
  • Location leaks
  • Succesful attacks
  • Durov
  • Other issues
• Conclusion
• References

Encryption

A technology that helps safeguarding against eavesdropping and abuse of data is encryption. Secure messengers often employ a more thorough form - called 'end-to-end encryption' (or E2EE).

The architecture of E2EE is designed to have the devices of conversation participants agree on a 'secret' that is being used to encrypt the messages send back and forth. The agreed-upon 'secret' can be compared to a physical key; only the key is able to open the lock, just as the key in the E2EE is the only means to decipher the messages. E2EE is unique in the sense that this key never leaves the device. Thus, while the messages are being sent over the internet, the messages can't be read. Just like any data, it can be intercepted, copied and eavesdropped upon, but without the key, it will be nothing more than seemingly random gibberish.

End-to-end encryption is a crucial piece of technology that enables completely confidential communication between dissidents, whistleblowers, journalists and many others. One could argue that E2EE is essential to protecting democracy. Unfortunately, not all end-to-end encryption is created equally. The strength relies on various factors, like the ciphers, key exchanges, protocols - and the implementation.

Shortly put: encryption is the technogical means to enforce confidentiality. And E2EE is the superior way of doing it, as it requires much less trust in other parties. With properly implemented E2EE, it just requires trust in the parties you are communicating with - plus your and their devices.

Background

WhatsApp might be the most popular instant messaging application, worldwide. It is certainly not the only one. One of the alternatives, dubbed Telegram, is frequently touted as a highly secure and private alternative, facilitating communication between users without the eavesdropping that is purportedly occurring at WhatsApp.

---

Pavel Durov, 39, is a Russian-born entrepreneur who has spent the majority of his life in Italy, where his father (a well-known classist) worked1 . In 2006, he received his Ph.D. in Philology from Saint Petersburg State University. Following that, he founded VKontakte, a social media platform influenced by Facebook2 .

Durov resigned from the VKontakte board in 2014, stating that he had no plans to return to Russia. He had been occupied with his new venture, Telegram. The company, which was founded in Berlin and then transferred to Dubai, developed a secure messaging application with the same name.

---

In the modern day era, the ability to exchange messages is critical. Sharing thoughts and ideas in private - from sending over a lovely recipe to a family member to sending your lover a sensual selfie without others being able to eavesdrop in. It is not always that innocent though. Journalists, dissidents, whistleblowers lawyers and politicians have more at stake. Their life could very well depend on the confidentiality of a conversation. Thus, it is paramount that a 'highly secure' messenger lives up to the promise of being secure.

Fundamentally broken

Telegram doesn't hold up to the promise of being private, nor secure. The end-to-end encryption is opt-in, only applies to one-on-one conversations and uses a controversial 'homebrewn' encryption algorithm. The rest of this article outlines some of the fundamentally broken aspects of Telegram.

By default, chats are not end-to-end encrypted

Naturally, users would expect a communication platform that portrays itself as fundamentally secure and private to at least enforce a high level of confidentiality using industry standard procedures. But with Telegram, this is not the case. End-to-end encryption is not used by default for conversations on the platform. Conversations are stored in plain-text on the Telegram servers, meaning that Telegram, its employees and adversaries with access to the servers (eg, through a breach) can read the conversations, view the shared media, etc. Telegram does, however, provide E2EE through an opt-in mechanism dubbed 'secret chats'. This feature employs a fully custom encryption algorithm, dubbed MTProto. Secret chats are not available for groups - but solely for one-on-one conversations.

The fact that the 'secret chats' are opt-in and only available for one-on-one interactions is peculiar and inappropriate, to put it midly. Furthermore, this functionality is hard to use for novices and comes with multiple caveats. As Matthew D. Green blogged3 :

As a kind of a weird bonus, activating end-to-end encryption in Telegram is oddly difficult for non-expert users to actually do.

Secret chats can only be initiated in the mobile application and cannot be synchronised to different devices. As a consequence, secret chats aren't usable from the desktop application.

Tl;dr: Telegram having no E2EE by default means that there is no real confidentiality

Telegram uses non-standard encryption protocols

Telegram created MTProto in-house. Custom encryption is strongly discouraged for obvious reasons - and is an extreme understatement. Large vendors like IBM4 have advised against it for decades. In the words of cryptographer, computer security expert and writer Bruce Schneier:

Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break.

This statement became later known as "Schneiers Law", a term coined by Cory Doctorow5 , whom is a journalist, author and editor. The same mantra is often rephrased as "don't roll your own crypto". Yet, Telegram completely ignored it and cooked up MTProto. Telegram announced a contest, promising a reward of $200,000 USD for breaking the protocol. This seemingly good initiative, however, was flawed. As Crypto Fails puts it 6:

Unfortunately, the contest is useless. Neither users nor Telegram developers will learn anything from it. But Telegram will still be able to point to it and say, “Look! No one has won the contest, so our software is secure!” Naive users will believe it, and they will feel safe using dangerously broken encryption.

The article continues on to explain why the contest is flawed and how it does nothing to attest the security of MTProto. Matthew D. Green, a prominent cryptography expert and professor at John Hopkins University, has stated the following7 :

There are so many things wrong with it. Check out their MTProto authenticated encryption. It's like using bacon to build a house.

Another statement from Green8 :

The crypto is like being stabbed in the eye with a fork.

In an academic research paper named "On the Cryptographic Fragility of the Telegram Ecosystem", researchers Theo von Arx and Kenneth G. Paterson - both affiliated with ETH Zurich, draw the following conclusion9 :

We have shown replay and reordering attacks against the Pyrogram, Telethon, and GramJS Telegram clients. The attacks are practical and can be exploited by running a malicious Wi-Fi access point, for example. The attacks are powerful in that they allow an attacker to significantly alter the view of a conversation for any participant that uses a vulnerable client Most important, we have explained why our attacks should not be viewed as isolated vulnerabilities, but how they highlight the need for action on a deeper level to improve the security of the Telegram ecosystem. The fact that developers systematically fail to implement MTProto 2.0 correctly [..]

Tl;dr: Telegrams flawed encryption protocol results in broken confidentiality

Telegram 'steals' the contacts

According to the Telegram privacy disclaimer 10:

Telegram uses phone numbers as unique identifiers so that it is easy for you to switch from SMS and other messaging apps and retain your social graph. We ask your permission before syncing your contacts. We store your up-to-date contacts in order to notify you as soon as one of your contacts signs up for Telegram and to properly display names in notifications. We only need the number and name (first and last) for this to work and store no other data about your contacts.

Thus, granting the permission, infers that the contact's name and phone number are uploaded to Telegram. The privacy disclaimer fails to state if and what measures are taken to protect this data. I am therefor assuming that there aren't any, other than encryption in transit (TLS / HTTPS). In conclusion, this data is accessible by Telegram, its employees and other parties with access to the servers - whether intentional or not. In short, Telegram has a list of all contacts their users have - including the contacts name and their phone number.

Tl;dr: Telegram uploads the addressbook (phone number, first and last name) to themselves, without encryption

Weird storage of the chats and disclosures to LE

Quoting from the Telegram FAQ11 :

To protect the data that is not covered by end-to-end encryption, Telegram uses a distributed infrastructure. Cloud chat data is stored in multiple data centers around the globe that are controlled by different legal entities spread across different jurisdictions. The relevant decryption keys are split into parts and are never kept in the same place as the data they protect. As a result, several court orders from different jurisdictions are required to force us to give up any data.

It can be inferred that the majority of discussions taking place in Telegram are not "covered by end-to-end encryption" given that the default is a chat without E2EE. According to Telegram, user data is encrypted on the server and the encryption key is segmented through different jurisdictions (countries).

Verification of these assertions is not possible because the source code for the Telegram server is kept secret. A technical objection to the solution is that the dispersed keys need to be connected at some point for the functionality to be useful. However, it should be noted that the same FAQ article states the following:

To this day, we have disclosed 0 bytes of user data to third parties, including governments.

This is disputed by the reputable German news outlet Der Spiegel 12. An English summary of the piece can be found at various sources, inluding AndroidPolice 13. According to DerSpiegel, Telegram has handed over user data to German authorities, involving terror and child abuse cases. If Telegram has in fact handed over data to authorities, this statement is blatently false.

Tl;dr: Telegram has a broken method of storing sensitive data and likely discloses data to law enforcement agencies

Location leaks

Telegram boasts functionality dubbed "People Nearby", allowing its users to easily find other Telegram users nearby. However, this functionality allows adversaries to triangulate the exact location. The Telegram security team stated that "this is not an issue"14 . That, in and by itself is a delusional perception of reality. Location data shows travelling patterns and can be abused for nefarious purposes. For instance - the "People Nearby" functionality can be abused to scan in sensitive and/or restricted areas. Stalkers nearby a womens shelter, personnel on army bases, journalists meeting up with sources, etc.

What makes this even worse is that the defaults in Telegram display everything publicly. The contact directory doesn't need an exact match and autocompletes. As a consequence, users can be found by simply entering a partial username or guess thereof.

Tl;dr: Telegram shares the location with other users nearby

Succesful attacks

Telegram portrays itself as being secure and thwarting attacks - but deeper research indicates otherwise. There are weaknesses in Telegram that are more of a theoretical nature15 - but doesn't stop there. In the course of a few years, Telegram has leaked personal data of millions of users, including their phone numbers16 and e-mail addresses17.

Most secure messengers do require personal identifiable registration during the signup - like a phone number or e-mail address. There are, however, ways to store this securely, so that an eventual data brach doesn't result in this data leaking.

Tl;dr: Telegram has had data leaks before - which might occur again

Durov

The sole factor influencing Telegram, its architecture, policies and politics is the founder - Pavel Durov. He maintains a controversial strategy for evading discussion about Telegrams shortcomings18.

So right from the start Durov starts with what is called "pivot and deflect": Shift from original disliked question (why doesn't Telegram use E2EE) and draw attention to something you want to cast attention to: "Instead of answering why Telegram isn't E2EE by default, let's discuss a single competing product and its problems regarding its E2EE."

Durov was arrested in France19, on 24 august 2024 on 12 different charges. These charges can be summarized into four categories20:

1. Telegram’s founder has been charged with being complicit in storing and distributing CSAM content, facilitating drug trafficking and facilitating organized fraud and other illegal transactions.
2. The court claims that Telegram refuses to cooperate with law enforcement when they file a formal request for information or documents.
3. Durov faces several charges related to Telegram’s cryptographic features as they haven’t been formally declared or certified by French authorities. These seem to be minor offenses according to professor of law Florence G’sell.
4. Durov is accused of taking part in a “criminal association with a view to committing a crime or an offense punishable by 5 or more years of imprisonment,” as well as money laundering.

The first and fourth category is likely because Telegram is in the technical position to perform content moderation but flatout refuses to do so. In comparison, most other secure messengers are unable to corporate with requests and court orders, because they apply E2EE. For instance, Signal is able to hand over the registration and last activity date - and to kick an account off its platform21. Signal is not able to produce other data, including metadata and the social graph on users of their platform.

Other issues

• Telegram shows the original author when forwarding a message. When Alice sends a message to Bob and Bob subsequently forwards it to Carol, then Carol sees that Alice is the original author of that message.
• The EU is investigating whether Telegram downplayed their usercount to avoid regulation 22.

Conclusion

Due to the flaws and concerns described above, a fair conclusion is that Telegram is fundamentally broken - and labelling it as a secure and/or private messenger is incorrect.Telegram, its employees and adversaries have access to most conversations and shared files/media. Telegram has leaked data before, from millions of its users.

Aside from the technical flaws, there are other serious factors that should be weighed in. Telegram is used as a tool by oppressive regimes to find, jail and kill dissidents. The app boasts functionality that can be (and is) abused by stalkers, criminals and others. Management doesn't seem to care, often ignoring requests and court orders and blowing off security disclosures as "being not an issue".

Hence, Telegram touting itself as private and secure is complete misinformation.

Ask yourself this: "when you send a message to someone you generate both a message and metadata. who do you trust to keep both of them secure?".

With Signal, you have to trust yourself and the recipient and the devices both of you use. WhatsApp adds one additional factor: Meta is responsible to keep the metadata secure. With Telegram, you have to trust yourself, the recipient, the devices and Telegram - to keep the metadata and the messages itself secure. Even if you get all the stars aligned, use a secret chat, it'll still be insecure because of Telegram's choice of encryption.

References

---

1. Is Pavel Durov, Russia's Zuckerberg, a Kremlin Target?, archived on 2016-03-07 and archive copy. ↩

2. Once Celebrated in Russia, the Programmer Pavel Durov Chooses Exile, archived on 2015-02-08 and archive copy. ↩

3. Is Telegram really an encrypted messaging app?, archived on 2024-08-30 and archive copy. ↩

4. IBM: never roll your own cryptography, archived on 2003-06-29 ↩

5. Schneier's Law, archived on 2011-04-18 and archive copy. ↩

6. Crypto Fails - Telegram’s Cryptanalysis Contest, archived on 2013-12-23 and archive copy. ↩

7. Matthew Green: There are so many things wrong with it. Check out their MTProto authenticated encryption. It's like using bacon to build a house., archived on 2024-01-14 and archive copy. ↩

8. Matthew Green: The UX is nice. The crypto is like being stabbed in the eye with a fork., archived on 2018-12-27 and archive copy. ↩

9. On the Cryptographic Fragility of the Telegram Ecosystem, archived on 2022-05-17 and archive copy. ↩

10. Telegram FAQ, archived on 2022-06-25 and archive copy. ↩

11. Telegram Privacy Policy, archived on 2024-01-13 and archive copy. ↩

12. Telegram hält sich neuerdings an Gesetze, zumindest ein bisschen - DerSpiegel, archived on 2022-06-23 and archive copy. ↩

13. Telegram reportedly gives user data to German authorities - AndroidCentral, archived on 2022-06-18 and archive copy. ↩

14. Telegram's People Nearby feature reveals exact user locations through triangulation, archived on 2022-05-24 and archive copy. ↩

15. Four cryptographic vulnerabilities in Telegram, archived on 2021--7-16 and archive copy. ↩

16. Data Breach Affects Millions of Telegram Users, archived on 2022-09-26 and archive copy. ↩

17. Telegram: Breach Exposed Millions Of Users’ Data, archived on 2020-06-26 and archive copy. ↩

18. Why you should stop reading Durov's blog posts, archived on 2020-11-11 and archive copy. ↩

19. Telegram Founder Charged With Wide Range of Crimes in France, archived on 2024-08-28 and archive copy. ↩

20. Paris court explains why it’s arrested Telegram founder Pavel Durov, archived on 2024-08-27 and archive copy. ↩

21. Signal - Government Communication, archived on 2024-08-30 and archive copy. ↩

22. EU investigating if Telegram played down user numbers to avoid regulation, archived on 2024-08-29 and archive copy. ↩

A couple of months ago, I scored a pretty good deal on a server rental (hexa-core Xeon-D, 32G DDR4, two 250GB SSDs) for 22 pops each month. Ideal for tinkering and hacking with geographical redundancy, as this server is located in Paris. There were some challenges to overcome first and foremost.

Jailbreaking

After the provider has kicked the server online, the user is supposed to select the desired OS that is automatically installed. That list does not include OpenBSD. Even though the provider offers on-demand access to IPMI/BMC (and thus KVM over IP), there wasn't an option to mount a custom image, either locally or remotely. The same scenario goes for a number of cloud providers (like Hetzner and Gandi) and cloud platforms (like OpenStack).

Fortunately, this can be worked around by (what I call) jailbreaking the machine. The basic idea is simple: install one of the supported OSes, slap the ramdisk installer somewhere and make the machine boot to it. Bringing this into practice may seem a little daunting at first - but it is not that difficult.

You will first need to install an OS to the machine. Ever since the inception of systemd it has been assimilating everything in such a way that the Borg envy. It has been consuming much more than just the init system - nowadays there is systemd-boot too. For this to work, I recommend picking a Linux distro that uses GRUB. Debian 11 (or earlier) is a solid choice. Whether the distribution is EOL is irrelevant, as we put Linux to full utilization: a mere bootloader for the OpenBSD installer.

Continuing, you will need the UUID of the root device. The partitions and the UUIDs can be easily listed issuing:

lsblk --fs

Write down the UUID of the root partition (the one with the / mountpoint) and make sure to have it ready. Also write down any and all network settings (IPv4 & IPv6 addressing, subnets, gateways, etc). Make sure to get root permissions for the next steps (either su - or sudo -i).

Lets switch to the root and throw the ramdisk image there:

cd / && curl -O https://cdn.openbsd.org/pub/OpenBSD/7.6/amd64/bsd.rd

Now we have to edit the GRUB config, which is twofold. Open /etc/grub.d/40_custom with your favorite text editor (mg, vi, ed, nano, etc) and add the following lines, replacing $UUID with the actual UUID of the root partition on two occassions:

menuentry "free-the-fish" {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod ext2
    if [ x$feature_platform_search_hint = xy ]; then
        search --no-floppy --fs-uuid --set=root  $UUID
    else
        search --no-floppy --fs-uuid --set=root $UUID
    fi
    kopenbsd /bsd.rd
}

Save the file and exit your favorite editor. Now, repeat the process for /etc/default/grub and add or edit the GRUB_DEFAULT parameter:

GRUB_DEFAULT="free-the-fish"

The last step is to update GRUB to reach the full potential of Linux: boot to OpenBSD. This is easily done with:

upgrade-grub

Or, if it doesn't know that command:

grub-mkconfig -o /boot/grub/grub.cfg

I was actually incorrect there for a moment - that wasn't the actual last step. The last step: grab yourself a nice cup of coffee and reboot the machine. The OpenBSD installer will be greeting you once it it rebooted.

Installing OpenBSD

Now, I won't hold your hand through the OpenBSD installer, because it is relatively foolproof and there is already enough documentation. I will add this: always encrypt all data and the storage holding it. Especially so if you are not the owner of the machine - which is the case with rentals and the cloud.

Setting up IPv6 on Scaleway

One of the challenges I ran into was that the IPv6 stack of Scaleway only permits addressing through DHCP. Setting a static IPv6 address won't work unfortunately. If you require this: consider going with OpenBSD.Amsterdam with is a way better choice regardless. If you are anything like me and love to have some infra running in every corner of the world, then read on :)

Since static addressing won't work, we'll need something to handle the IPv6 DHCP for us. The easiest would be to use DHCPCd. Install it with a simple:

pkg_add dhcpcd

Configure the client daemon by adding the following options to /etc/dhcpcd.conf:

ipv6only
noipv6rs
allowinterfaces em0
duid
slaac hwaddr
interface em0
    ipv6rs
    iaid 1
    dhcp6
        ia_na 1

Make sure that your /etc/hostname.em0 does not have any lines with inet6 (as that would cause both OpenBSD itself and DHCPCd fetching an IPv6 address). Set some flags for DHCPCd:

rcctl set dhcpcd flags -C resolv.conf -c /etc/dhcpcd_up.sh

This makes DHCPcd ignore resolv.conf and hooks in our script after getting an IPv6 lease. Ofcourse, we will need to create that script. Open /etc/dhcpcd_up.sh with your text editor and throw in (replacing $IP6 with your actual IPv6 address):

route sourceaddr -inet6 $IP6

Make the script executable:

chmod +x /etc/dhcpcd_up.sh

Enable and start DHCPCd:

rcctl enable dhcpcd
rcctl start dhcpcd

Now you should have a working IPv6 configuration. Congratulations! If you have customized pf.conf you'll need the following rules:

# Allow ICMP6 traffic; utterly insecure allowing all ICMP6 traffic, you should narrow this down
pass on any inet6 proto icmp6 all

# Allow the provider to send DHCPv6 packets
pass in on em0 inet6 proto udp from fe80::/10 port dhcpv6-server \
  to fe80::/10 port dhcpv6-client no state

Closing thoughts

Hopefully either you or someone else benefits from this how-to. In case it has helped even one person, it was well worth writing it. As always, you can reach out to me through the Fediverse or through mail. Have a lovely day - until we meet again in the next blogpost!

I feel a bit ashamed to admit that, despite using OpenBSD on a daily basis for nearly twenty years, I have never attended EuroBSDcon. Fortunately, there is a first time for everything - I went to EuroBSDcon 2022 in Vienna.

Because of environmental reasons (and the airport being nothing short of a complete clusterfuck), we took the Nightjet to Vienna. Scheduled to board it wednesday evening, we (me and three of the best travel companions) set out to meet a bit earlier, to grab a coffee and share our enthusiasm. Once boarded, we discovered that the bunks were harder than our heads - which was kind of unfortunate and resulted in a 'slight' deprivation of rest. Luckily, the nightly hours passed by quickly. After the arrival at Vienna HBF, we quickly spotted a familiar face: Philip Jocks. We walked to our hotels together, to drop off the luggage and get a refreshing shower. Mischa and I set out for two days of checking out Vienna and some hacking, while the remaining two travel companions attended a tutorial.

Later on thursday, we bumped into Philipp Bühler, whom shared his ongoing work to get Jitsi running on OpenBSD, for his talk on sunday. We took a somewhat quiet place to help Philipp work on it (emotional support and OpenBSD.Amsterdam donated the infrastructure to set it up). Due to the Java involved, this resulted in Henning Brauer calling us out as 'perverts' - which is, in fact, a joke. I think it's an awesome photo! Having ran a Jitsi server for more than a year, I was impressed by the work of Philipp, Aisha and others to port it to OpenBSD - I'll migrate my server from HardenedBSD to OpenBSD soon. On Friday, I met Tom Smyth face-to-face after years of communicating irregularly on social media. Nice to finally put a face to the words and avatar.

Fast forward to saturday, when the official conference was kicked off: the first talk was from Frank Karlitschek (the Nextcloud CEO) about the key benefits of decentralisation. Interesting, even though it was somewhat preaching to the choir. Alexander Bluhm gave a talk about increasing the network performance in OpenBSD, Theo Buehler about recent LibreSSL progress, Allan Jude about scaling ZFS for NVMe and Ken Westerback about filesystems on OpenBSD. There were plenty more - see the program for more details. Throughout the day, we met Mohammad, an awesome Dutch fellow.

In the evening, there was the 'social event', which was kept a big surprise. The city of Vienna invited the attendee's for a bite, drink and to interact with one another at the town hal;l. The evening was kicked off by a city representative, explaining on how open source (and BSD in general) overlaps with human rights. I suspect that there was some coaching involved by Henning ;). I met Marc Espie, Alexander Bluhm, Theo Buhler and others. After the 'social event' we went to two different venues and partied late - which made getting up on sunday somewhat of a hassle. For me a bit more - as there was lovely wine served at the social event.

On sunday, I've been to the talks of Tom Smyth (nsh), Philipp Bühler (Jitsi), Marc Espie (Ports), Landry Breuil (pledging and unveiling Firefox) and Samuel Aubertin (the 'backdoor' in make). Joined once again by the travel fellows, we went out for a nice burger and boarded the train back home. With a delay of three/four hours, we eventually arrived back in Utrecht and went back home, satisfied, happy and tired.

Thank you all - including the persons I am forgetting to mention (sorry!). I can't express my gratitude (without sounding like a toddler that got his first game console) - see you all next year!

Despite being an older piece, I'd like to recommend this longread on Brian Acton and how he, as a former WhatsApp founder, gave the middle finger to Facebook. Thank you so much, Brian, for making the better choice and to protect the human rights of others!

EDIT: this is actually a repost of a blogpiece I've published years back but got lost over time

I love open source. Opposed to proprietary software, open source software is extendable, auditable and customizeable. Often, it is the result of hard labor and effort by hundreds or thousand of enthusiastic, passionate developers collaborating on an idea or shared goal. Together, they make the world a better place, bit by bit.

Open source forms the fundamentals for modern technology. Your computer, tablet and smartphone, your household devices and screen-based entertainment, the ability to do a transaction within a second - with merely a plastic card - or to contact your beloved ones - it is all powered by open source. Either directly or indirectly. Open source was used in the origins of computers, the internet and the world wide web. If there was no open source, we probably wouldn’t have the technology we use every single day. Often, we don’t give it much thought - though this really fascinates me.

As a security and privacy evangelist, I use open source software - due to being auditable and verifiable. This leads me to my favorite open source project: the 25-year-old OpenBSD operating system.

The origins of my love story

Ever since we got our first computer - when I was six, I have been fascinated by the technology powering the device. We had some really fun games on it, but I was more interested in the two processors, the harddisk of 45MB, 4MB RAM and the software that made this device run. I quickly began to master MS-DOS, QBasic and later on Windows for Workgroups 3.11, which I got from a teacher at my elementary school. As a scholar, I traded games and applications, instead of marbles like most scholars did.

Years later, when I left my elementary school for a high school, I met and befriended Giel, who introduced me to one of the first Red Hat releases. At the time, I was unfamiliar with the concept of open source, and this got me hooked from the first second. I can’t exactly remember the order, but I switched a lot of distributions from that moment on: SuSE, Mandrake, and eventually ended up with Slackware. Once the notion of open source fully sank in with me, I began to feel blessed. Blessed to be using the product of thousands of volunteers worldwide. It was a true honor.

From Linux to BSD

From that moment, I spend nearly all my spare time on IRC channels and Usenet, gathering knowledge, participating in discussions and exchanging ideas. Somewhere along the way, I read about BSD. About how it was not another Linux distribution, but a completely different operating system with different goals, ideas, and less organic grown.

I flirted with FreeBSD first, but it didn’t felt right, so I switched back to Linux. But then I stumbled upon OpenBSD. It wasn’t love at the first sight, perhaps. I was accustomed to Linux too much to just make the switch. However, I did install a dual-boot (OpenBSD/Linux) and began liking it more and more as weeks progressed, right up to the point where I ditched Linux in favor of OpenBSD. By the time I turned seventeen, I was a fulltime OpenBSD user.

The advantages of OpenBSD

I do consider myself an OpenBSD evangelist. The operating system has some very impressing advantages when compared to other systems:

• It's extremely secure: OpenBSD has an excellent track record when it comes to security. The default install has only had two remote code execution vulnerabilities in almost twenty years. Compare that to Windows, Linux or FreeBSD, which have had many more, and the conclusion is quite clear. Moreover, OpenBSD is the leader when it comes to exploit mitigation techniques. Last but not least, they did develop OpenSSH and an exhaustive list of impressive programs, concepts, and projects.
• It's well documented: everything within OpenBSD is documented very, very well. The man-pages are the one stop shop if you need information on the syntax of a program, it’s functions, etc.
• It's open source: this might seem a somewhat strange point, as I’ve made it abundantly clear in the beginning of this piece. But, I’d like to talk about this a bit more. Whereas most operating systems include proprietary, closed source drivers, OpenBSD by default does not. Closed source drivers can’t be audited, thus forming an unknown attack vector. For all we know, these closed-source drivers might be bug-ridden, vulnerable, or in violation of software license agreements.
• It's neat and clean: OpenBSD is clean, without much in the way of bloat. It doesn’t ship with thousand of packages like, for example, Linux does. This becomes evident during the installation process. The installer asks whether to enable SSH, or whether you intent on running a graphical interface. Since choice and freedom are two of OpenBSD’s elegances, you’re free to install any bloat you wish (try pkg_add gnome).

The installation process if very straight forward. From booting the installer to booting the installed OpenBSD for the first time, it all takes a mere ten minutes. And there are many other advantages of using OpenBSD. Be sure to check out the project goals. Oh, and less serious but perhaps worth mentioning, every OpenBSD release has awesome artwork and one or more songs!

My take on OpenBSD

I use OpenBSD on a daily basis, as my desktop operating systems, servers and various other machines. One might say that I have a blatantly preference for OpenBSD.

If you're new to computers, OpenBSD serves as an excellent starting point. It will help you better understand how your computer works. If I could go back in time and begin my experience with computers with OpenBSD, doing so would be a no-brainer! If you are ready to get started with OpenBSD, here are the installation instructions.

The evil empire known as Google is experimenting with yet another clusterfuck of a technology, known as FLoC (Federated Learning of Cohorts) - which is basically a technique to track visitors on the web, without the requirement of cookies. The Electronic Frontier Foundation explains pretty well why it is terrible.

In the current implementation, Chrome users can disable partaking in the experiment by disabling third party cookies (not just in Incognito, but enabling third party cookies in general). Moreover, server and website operators can disable FLoC by adding a header to the response. I've 'misused' my SysOp hat and rolled it out over several hundreds server - thereby effectively adding it to thousands of websites. If you operate a webserver or website I recommend doing the same. Here is how you can add the header to a number of different configs:

Relayd

If you are using relayd, you can add the following line to the http protocol section:

match response header set "Permissions-Policy" value "interest-cohort=()"

Nginx

For nginx the following line can be either set serverwide or in the server {} context:

add_header Permissions-Policy "interest-cohort=()" always;

lighttpd

setenv.add-response-header += (
  "Permissions-Policy" => "interest-cohort=()" 
)

HAproxy

Add the following line and reload HAproxy:

http-response set-header Permissions-Policy interest-cohort=()

rocket-nginx

Open /etc/nginx/rocket-nginx/rocket-nginx.ini with your favorite text editor, scroll down to line 43 and insert the following line:

http_header[Permissions-Policy] = "interest-cohort=()"

Run the parser (php rocket-parser.php) and restart nginx.

Apache httpd

With Apache httpd, the following lines can be set in the .htaccess file in the document root - or add it to the serverwide context:

<IfModule mod_headers.c>
    Header always set Permissions-Policy "interest-cohort=()"
</IfModule>

Albeit having a strong preference for Jitsi Meet, I had to get Skype working on OpenBSD to meet online with a client. Due to some strange, borderline-psychotic logic, Skype Web doesn't support audio or video calls out of the box on 'unsupported systems'. After some online searching, multiple sources recommend changing the user-agent to mimic Chrome on Windows, which unfortunately wasn't the fix. It still would have those audio/video buttons greyed out.

After some tinkering, I managed to get it working. The trick is stupid simple: use preview.web.skype.com, rather than web.skype.com.

Mind you, this can break at any given time - if Redmond decides to block the 'unsupported systems' on the preview version, you are out of luck. But right now, it does work. Verified it with some test calls.

As the case with OpenBSD, you do need to enable the microphone and webcam explicitly in order to use it. This can be achieved by setting two sysctl's (on -current and the upcoming 6.9 release):

# sysctl kern.audio.record=1
# sysctl kern.video.record=1

...and then either making the $USER a member of the video group or by changing the privileges to the device: # chmod 666 /dev/video0. While these options can be set as a system-wide default, I would recommend against it - it tends to be a good practice to having recording and the webcam disabled by default.