The security section documents investigations, assessments, and practical observations about security behaviours in real systems. Every piece in this section starts from something observed — network traffic captured, protocol behaviour examined, server configurations tested, or tool limitations exposed through actual use. The goal is not to produce alarmist vulnerability disclosures or abstract threat modelling exercises. It is to document exactly what was found, explain what it means in practice, and provide enough detail for readers to assess the implications for their own systems.

The coverage spans messaging protocol security, firewall tooling for IPv6, browser-based fraud protection, TLS configuration assessment, and the practical experience of deploying Let's Encrypt certificates in production. Each investigation includes the methodology, the observed behaviour, and the context necessary to understand why the finding matters. Where the situation has changed since the original observation — a vendor patched the issue, a protocol was updated, a tool improved — the page notes what shifted and when.

This section pairs naturally with the tech notes on firewall tools and networking internals, and with the practical configuration guides in the how-to section. The topics index collects security-adjacent content from across every section for cross-cutting navigation.

Messaging and protocol security​

Communication security is only as strong as the weakest link in the protocol chain, and the weakest link is not always where you expect it. These investigations examine the practical security of messaging implementations as they actually behave on the wire.

EA Origin Chat Unencrypted​

This investigation documented that EA's Origin gaming platform transmitted chat messages without encryption, sending XMPP traffic in plaintext across the network. The finding was significant not because a gaming platform was the most sensitive communication channel on anyone's machine, but because of what it revealed about how large software companies approached messaging security at the time. The investigation details the observed traffic, the protocol analysis, the implications for users on shared or untrusted networks, and the broader context of plaintext messaging in an era when encryption should have been the default.

The piece remains relevant as a case study in how to identify and document unencrypted communication in desktop applications. The methodology — capturing traffic, identifying the protocol, verifying that the content was readable — applies to any application where you suspect plaintext transmission. If you manage network infrastructure where gaming clients are present, or if you are interested in the practical techniques for traffic analysis, this investigation provides a detailed walkthrough of the process.

Server hardening and firewall management​

Securing a server involves decisions that interact with each other in ways that are not always obvious. Enabling IPv6 on a server doubles the attack surface if the firewall only covers IPv4. A brute-force protection tool that does not understand IPv6 addresses leaves a gap you might not notice until someone exploits it.

fail2ban IPv6​

fail2ban is one of the most widely deployed brute-force protection tools on Linux servers, and for years its IPv6 support was either incomplete or absent depending on the version. This page documents the practical state of fail2ban's IPv6 handling — what works, what does not, how the action system interacts with ip6tables versus nftables, and the configuration adjustments necessary to ensure that IPv6 attackers receive the same treatment as IPv4 attackers.

The problem is more common than it appears. Many server operators enable IPv6 on their hosts, confirm that services are reachable on both protocol families, and assume that their existing fail2ban configuration covers both. It frequently does not. This page walks through the verification steps, the version-specific behaviour differences, and the jail configuration that actually provides dual-stack protection. If your server has an IPv6 address and runs fail2ban, verifying your configuration against this page is worth the few minutes it takes.

Browser security​

Browsers are the primary interface between users and the hostile parts of the internet, and the security features built into them are often the only protection standing between a user and a phishing page, a malicious download, or a compromised advertisement. These investigations examine how browser security features actually perform in practice.

Fraud Protection in Alternate Browsers​

Google Safe Browsing is the dominant phishing and malware protection system on the web, and Chrome implements it with the tightest integration and the fastest update cycle. But what happens when you use a browser that is not Chrome? This investigation tests the fraud protection effectiveness of alternate browsers — examining which browsers use Safe Browsing, which use their own systems, which use nothing at all, and how the protection latency and coverage compare across the field.

The findings are directly relevant to anyone who recommends or uses non-Chrome browsers. Privacy-focused browsers sometimes disable or delay Safe Browsing checks for valid privacy reasons, but the security trade-off is rarely quantified. This page provides the specific comparison data, the testing methodology, and an honest assessment of what you gain and what you give up when you choose a browser with different fraud protection characteristics. It also addresses the question of whether third-party extensions can close the gap, and the practical limits of that approach.

TLS and certificate management​

TLS is the foundation of every secure connection on the web, and the gap between having a certificate and having a properly configured TLS deployment is wider than most administrators realise.

Let's Encrypt Experiences​

Let's Encrypt changed the economics of TLS certificates permanently, but the practical experience of deploying and maintaining Let's Encrypt certificates in production involves a collection of operational details that the getting-started guides do not cover. This page documents the real-world experience: the renewal edge cases, the DNS challenge complexities, the interaction with reverse proxies, the rate limits that matter for large deployments, and the monitoring approach that catches renewal failures before they become outages.

The page is not a setup guide — for that, the official documentation is sufficient. It is a record of what the ongoing operational experience actually looks like, including the problems that only surface after you have been running automated renewals for months and your infrastructure has grown beyond the simple single-server case that the tutorials assume.

TLS Ratings Norwegian Banks​

This investigation assessed the TLS configuration of Norwegian banks' public-facing web services, testing cipher suite selection, protocol version support, certificate chain validity, and the overall security posture as reported by standardised TLS assessment tools. The results revealed significant variation in how financial institutions — entities that should have the highest possible standard for connection security — configured their TLS deployments.

The methodology is repeatable and the assessment criteria are documented, making this page useful both as a snapshot of the Norwegian banking sector's TLS posture at the time of testing and as a template for conducting similar assessments against any set of domains. If you are responsible for TLS configuration on services that handle sensitive data, comparing your deployment against the criteria used here provides a quick sanity check.

What readers usually need​

Security questions tend to be urgent and specific. The most common paths through this section follow a few patterns:

• Checking whether a messaging application encrypts traffic → The EA Origin Chat Unencrypted investigation demonstrates the technique for capturing and analysing application traffic
• fail2ban not blocking IPv6 attackers → fail2ban IPv6 covers the configuration and verification steps for dual-stack protection
• Evaluating browser security outside Chrome → Fraud Protection in Alternate Browsers provides the comparison data
• Let's Encrypt renewal problems → Let's Encrypt Experiences documents the operational edge cases
• Assessing TLS configuration quality → TLS Ratings Norwegian Banks shows the assessment methodology and criteria

For the firewall tooling that underpins server hardening, the UFW vs firewalld tech note provides the comparison. For practical setup procedures, the how-to guides cover the step-by-step work. The topics index connects security content with related material across every section of the site.

The approach to security writing​

Security documentation occupies an awkward space between being helpful and being irresponsible. Providing too little detail makes a page useless for the people who need it. Providing too much detail in the wrong way creates a recipe book for attackers. The approach here leans toward full disclosure of observed behaviours and methodology, because the people who need to understand these findings are the administrators and developers who can fix the problems — and they need enough detail to reproduce and verify what was found.

Every investigation includes the observation, the method, and the context. Nothing is sensationalised. Where a finding was reported to a vendor, the timeline and response are noted. Where a situation has improved, the improvement is documented. The goal is a technical record that remains useful long after the initial observation.