Blocks Everywhere

11/05/17 — capitol


We have made our own JSON web tokens, with AES and blocks! And without JSON.

Access the puzzle here:

telnet 2a02:ed06::2033 12348

or here

telnet 12348

Happy hacking!

Creating a fast blog

08/05/17 — capitol


Let us go over the stack we use to power this blog and why it’s both easy to use and fast for our visitors.

The goal is to serve the blog as fast as possible, while avoiding the constant stream of security holes that wordpress exposes its users to.

We achieve this by serving static content only, that is updated every time that someone pushes new content to the git repository that backs the blog.

We serve the content over http/2 and both IPv4 and Ipv6, in order to take advantage of the improvements in the new protocols.


Debian Jessie

We use debian jessie as a base distribution, they do a reasonable good job of patching security issues and have almost all the software we need packaged.

In regard to security, we think that the most likely attack is that someone reuse a known exploit rather than burn a 0-day on us. So the most important thing is to not have any unpatched software in our stack. In order to achieve this we have configured apt to automatically download and install security patches, as described here.


We use nginx as our web server of choice. It’s fast and quite flexible, it lacks a good module system but we don’t need any esoteric features.

We installed nginx from the jessie-backports repository, in order to get a version of nginx that supports http/2.

The configuration file for nginx looks like this:

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;


        ssl_certificate /etc/letsencrypt/live/;
        ssl_certificate_key /etc/letsencrypt/live/;

        ssl_protocols TLSv1.2;
        ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
        ssl_dhparam /etc/ssl/certs/dhparam.pem;

        add_header Strict-Transport-Security "max-age=63072000; ";
        add_header X-Frame-Options "DENY";

        root /home/blog/blog-static/;

        location /images/ {
                expires 30d;

We configure the server to listen to both IPv4 and IPv6, supporting IPv6 means that mobile devices doesn’t have to go through a carrier grade NAT (CGN) in order to reach the site. CGN’s can add significant amount of latency when the conditions are bad.

The TLS protocol is limited to only TLSv1.2 as all modern browsers have supported it for a long time, the protocol was released in 2008. If there is someone out there that still can’t use it, they need to seriously rethink how they manage their software.

The list of ciphers are chosen in order to avoid a number of cryptographic attacks.

The Strict-Transport-Security header tells the browser that it should only use https in order to access the site in the future.

We also configure the caching of images to be 30 days, so that returning readers of the blog will have a better experience.

Let’s encrypt

The Let’s encrypt project is our TLS certificate provider, they have enabled the world to move away from the insecure http protocol.

Let’s encrypt lets us automate the signing of the certificate that TLS uses. We use certbot in standalone mode for this.

The openssl package needs to be installed from jessie backports also, since nginx was installed from there.


The engine that powers the blog is jekyll, it takes our blog posts that are written in markdown and compiles them into html pages.

The source of the blog lives on github and each blog post is it’s own file under _posts/ prefixed with the date it will be published.

On the server we have a simple bash script that monitors github for new content and regenerates the static files by running:

jekyll build --source /home/blog/blog --destination /home/blog/blog-static/

Jekyll is installed from source, since the version in debian is too old and there isn’t an updated version in backports.

TOR at hackeriet in 2016

01/05/17 — capitol


We at hackeriet started our tor node one year ago, with help from the NUUG foundation.

The node is still happily churning out encrypted data to different parts of the internet, as can be seen on out network graphs.

Our setup


We started the project with a dedicated 1U rack machine, a HP ProLiant DL160 G5 Server, it had four cores and 20 gig of ram.

This turned out to be way more iron than what we needed in order to power to node, so in september the machine was converted to a virtual machine in our proxmox cluster.


The machine was installed with Debian 8 and setup to automatically install security updates. The tor software was installed with the help of debian packages.

The machine have both ipv4 and ipv6 addresses, and we accept connections to tor from both.

The munin monitoring software ran on a separate machine.

What happened

We had a hardware failure on the machine that hosted the munin graphs, and as those were complimentary we didn’t have backups of them.

We also had a series of 5 power outages in the end of summer, most likely due to faulty hardware in one machine. As the problem was hard to reproduce and intermittent we never managed to conclude that the hardware we suspected was the culprit, but the problems stopped occurring when it was removed.

We opted into becoming a fallback directory mirror as our node is quite stable.

Right now the latest stable version of tor have just been released and we are in the process of upgrading to it.

What we learned

There has been a lot of drama in the tor project during 2016, one of the main activists resigned due to committing acts of sexual harassment.

There has also been multiple different attempts as FUD, mainly due to the fact that a lot of the funding for the development of the project comes from the american military.

There were also an attack on the tor network performed by FBI And Carnegie Mellon University in 2014, more information on the circumstances was published and combed over by the community.

What will happen now

We will continue to host our entry node, as tor is still one of the best projects for ensuring freedom from some of those that want to monitor your network traffic.

We almost understand RSA now

27/04/17 — capitol


After intense study of the RSA algorithm, we think that we have almost managed to implement it correctly.

Can any of you break our encryption scheme?

telnet 2a02:ed06::2033 12347

telnet 12347

Happy hacking!

Resources for becoming a better hacker - Part 2, ethics

19/04/17 — capitol


The second topic for our series on learning material will cover a slightly unorthodox subject regarding hacking, the ethical aspect of the hobby.

It’s easy to just disregard the subject, either from the viewpoint that all hacking is criminal and therefore unethical, or from the standpoint that if it can be done then it should be done and therefore ethical.

The truth is of course somewhere in between, and it’s quite personal where you land in the spectrum. I would therefore like to present a reading list on the subject, so that you can come to your own conclusions.

Lets start with a classic from the book Hackers: Heroes of the Computer Revolution: Hacker ethics.

And a critique of it here.

It doesn’t really have anything to with computer security, but its still quite important to have read.

Lets start touching on the security aspect of hacking with some jargon.

There can be many reasons to investigate the security of a system, one is hacktivism, a loaded word that was first coined by Cult of the Dead Cow, the original paper can be interesting to read.

Or a hacker might be working within a academic or business context that need a code of conduct.

If you are more academically inclined, then this is a good read and here is an overview of other papers.

There is also very different attitudes on what to do with found security holes. A spook or a black hat might want to keep the information secret, in order to weaponize it, while a white hat will report it.