Jamie Scaife - United Kingdom 🇬🇧 

Introduction to BGP Routing Security - Prelude: Connecting to the DN42 Overlay Network

Tuesday 31st March 2020

Decentralized Network 42, known as DN42, is a private overlay network built using thousands of distict nodes interconnected with each other via VPN tunnels. DN42 employs routing protocols such as BGP and OSPF in order to route packets, allowing users to deploy services such as websites, IRC servers and DNS servers in a way very similar to the real internet.

The landing page for DN42, available at dn42.us.

The DN42 network is primarily used by network and security engineers in order to provide a safe and accessible environment to practise using network technologies, as well as allowing isolated networks, such as those behind strict firewalls or NAT, to communicate with each other directly.

However, the primary selling-point for DN42 is that it provides free and realistic access to a production-like BGP environment, which is something usually reserved for network operators responsible for large enterprise networks or ISPs who are also often paying expensive registry fees. Continue reading...

BGP DN42 Guide

Restricting Who Can Issue Certificates for Your Domain with CAA

Thursday 13th February 2020

Certificate Authority Authorisation (CAA) is a security control that can be used to restrict the Certificate Authorities (CAs) that are permitted to issue certificates for your domain. The purpose of this is to help ensure that only explicitly whitelisted CAs are able to issue certificates, and also to report on any attempted violations of this policy.

CAA policies are set using the CAA DNS resource record type, and it has been mandatory for issuing CAs to check for and comply with CAA policies since 8th September 2017. The CAA specification is defined in RFC8659.

The following sample CAA policy marks Let's Encrypt as the only CA authorised to issue certificates for example.com, while requesting that violations are reported to the caa-violations@example.com mailbox:

example.com IN CAA 0 issue "letsencrypt.org"
example.com IN CAA 0 iodef "mailto:caa-violations@example.com"

This policy will then be checked by CAs when a certificate request is submitted for your domain. Continue reading...

Security TLS RFC

Testing Your Ability at Spotting Lookalike Domain Names

Sunday 12th January 2020

I have created a web-based JavaScript app/game which allows you test your ability at spotting potential lookalike or phishing domains in real-time.

A screenshot of the Lookalike Domain Names Test app.

The app displays the domain name of a well-known website, with a random set of permutations applied to it. You must then select whether the domain is 'Real' or a potential 'Lookalike'.

Lookalike domain names are a very effective phishing technique, as they exploit the natural way that the human brain interprets writing. The brain will automatically make assumptions and fill in gaps when reading, allowing users to be easily fooled if a phishing domain looks almost identical to the legitimate domain. Continue reading...

Security Domain Names

Securing Inbound Email Transport with MTA-STS and STARTTLS-Everywhere

Friday 27th December 2019

The web security ecosystem has matured significantly over the past few years, partly thanks to organisations like Let's Encrypt and the ACME protocol, as well as because of encouragement from browser vendors for websites to implement HTTPS and other security controls such as Content Security Policy.

However, the email ecosystem unfortunately hasn't seen such levels of development. Existing technologies for securely transporting emails, such as STARTTLS, are not as resistant to attacks as their web-based counterparts, and the implementation methods available to sysadmins are far more limited.

In this blog post I'm going to talk about three new email security technologies: MTA-STS, TLSRPT and STARTTLS-Everywhere. These allow you to have greater control and insight into how your emails are securely transported. In this post I will focus on security and reporting for inbound/incoming emails, however in the future I may also cover outbound/outgoing emails. Continue reading...

Security TLS RFC