My Take on DNSSEC – Part 3: How to configure it in BIND (cancelled)

Just as a quick note here:
I originally planned to do my third part on DNSSEC with configuration hints using the popular DNS server BIND. At the moment I also use BIND for my setup.

Now I discovered the „Advanced Secuity Notifications“ at ISC, which sells prior warnings about security issues in BIND. Personally, I don’t want to support this model.

Instead I am currently migrating to another DNS server implemenation, YADIFA, which I will then write about. But first I need to check my setup using this server.

Update: Maybe I will switch to Knot DNS instead of YADIFA. They seem to be both fairly equal in features. To the outside spectator YADIFA seems to be a dead project, even though they published a release in mid-december. The development is done by EUnic, the guys behind maintaining the .eu-domain. They seem to have some internal development/issue tracking/etc. and they only send the releases to GitHub.
In contrast, Knot DNS, being maintained by cz.nic, is more open in their development.

My Take on DNSSEC – Part 2: How does it work?

As I already explained in Part 1, the current state of DNS is pretty insecure. The goal of DNSSEC is to improve this situation. Here is how that (should) work. I won’t go into cryptographic details here, but just show the general behaviour.

Lets have a look at the domain testmichhartundwild.de. There is a DNS server responsible which provides some general records.

DNS Zone without DNSSEC recordsThere is no DNSSEC here and every record could be manipulated by an attacker.

Now we activate DNSSEC. To do so, we generate cryptographic keys and use these keys to sign the records in the zone. Let’s not talk about why we use multiple keys here. It would work with just one key, but we have reasons to use more than that. (The small green arrows in the images show existing signatures)

DNS zone with isolated DNSSEC signaturesNow this zone is signed by the DNSKEYs and every user could verifiy the signatures against the key. There is still a problem though. How can we trust the keys? The attacker could simply replace the keys and create his own „valid“ signatures.

To overcome this problem we need the cooperation of the „upstream“ domain, in this case „.de“. We publish the fingerprint of the first DNSKEY as a DS record in the TLD. The TLD uses its own key to sign this fingerprint. This leads to a trustworthy DNSKEY in our zone. But that only works if we have a way to trust the keys of the TLD.

DNSSEC secured zone with delegation to TLD Basically we are in the same situation as before, needing a way to verify the keys of the TLD. So we do the same as before and the TLD publishes the fingerprint in the parent root domain.

DNS zone with full DNSSEC hierarchyAnd again we are in the situation of needing to trust the root key. But now we don’t have any parent zone to publish the key fingerprint. The solution is pretty simple. We give everybody the fingerprint of the root key. Every piece of software that wants to verify the dnssec signatures is just preloaded with the root key. For example the bind DNS server has this part in the configuration:

        # ROOT KEY: See 
        # https://data.iana.org/root-anchors/root-anchors.xml
        # for current trust anchor information.
        # NOTE: This key is activated by setting 
        # "dnssec-validation auto;" in named.conf.
        . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";

Now we are able to verify all the records by following the signatures until we reach the root key.

This concludes the general mechanism of DNSSEC. In the next part we are going to have a more technical look on how to configure a DNS server to properly generate DNSSEC signatures and secure their zone.

My take on DNSSEC – Part 1: Why do I need that?

DNS [1] is probably one of the most important protocols on the internet. Everybody uses it countless times each day, usually without even noticing it. Every time somebody visits any website, every time somebody sends a mail, every time somebody wants to do literallly ANYTHING on the internet, a DNS server is involved.

What it does is fairly straightforward: It is a dictionary of domain names (like enbewe.de or example.com) and the associated IP address (like 203.0.113.17 or 2001:DB8::12). If a user wants to access a website at a certain domain, the browser first queries a DNS server for the IP address  of the domain and then connects to the server with that address. Essentially it is a phonebook [2] for the internet.

Sadly the protocol is about as ancient as it can be in the internet, being developed in 1983. During these early days, nobody designed protocols to be protected against malicious attacks. For this reason DNS is horribly insecure and a largs-scale attack on the internet could probably render the entire internet unusable (for some time) [3]. But it can also be compromised in more subtle ways, i.e. directing users to wrong servers for phishing attacks.

To improve the situation, the DNSSEC protocol has been developed. It could be argued that DNSSEC is far from perfect [4] but at least it is a step in the right direction. For this reason I want to talk a bit about DNSSEC, what it does, how I use it on my server and how it can be used in clients.

But that will start in part 2

The Company Strikes Back & Return of the Notebook

For some time now, I haven’t been writing here. But since I was asked how the story about my notebook ended, I thought I should post an update here.

Yes, I got my notebook back. It’s been three month now, that I have been using it, and everything seems to be fine. I wasn’t sure about that, when I received the package, so I documented every step of unboxing. 😉

IMG_20150602_180347 IMG_20150602_180654 IMG_20150602_180746

 

IMG_20150602_180820 IMG_20150602_180840

I reinstalled my Linux after that and I was glad that the problem with the display was gone and that everything worked fine. I have a small problem with standby under Linux but I believe that problem is on the software side.

About two weeks after I received the package, I got a letter from DHL, regarding a lost package. They wanted to know if I could shed some light on the missing package with a notebook inside. In the letter was a list of the contents of the package and my notebook was declared with a value of 150€. I was a bit sad when I saw that.

A new hope

It looks like the DHL managed to pull my notebook back out of the lava pit it fell into. I received a mail from Lenovo that my notebook was returned to them, due to a wrong address. I phoned them and they sent it again.

Currently all I have is a tracking number, but it is not known to the DHL at the moment. I am beginning to hope that I might get my notebook back, but I’m not convinced until I have it in my hands again.

Whatever happened to my Notebook?

Last year, around the end of March, I bought my new Laptop. I wanted a small device with a 11inch screen but with still a bit of punch so I was looking for a 4th generation i5 or i7 and 8GB of ram at least. I was searching for some time and all I came up with was the Apple MacBook Air 11. Ethically I can’t support buying Apple devices, so this was no real option, though I was damn near buying one nonthetless.

That was when I found the Lenovo Yoga 11. It came as a 11inch touchscreen device with a good i5 and 8GB of ram … so almost the perfect fit. The 360° display was no real thing for me, as I was looking for a laptop, but I didn’t object too much. The WiFi is only 2.4 GHz but I only discovered that some time later. I came across a cheap deal for the device, so I bought it.

For about 9 months I was really happy with the device. I even came to use the device in tablet mode sometimes.

Then a defect started to show. The display started to show ghost images on the edges. This was obviously a faulty display and should be fixed by warranty. I wasn’t able to send it to repair at that moment, as I needed the device to write my master thesis. Then, after my thesis was done and I could spare the notebook for some time, I sent it in for repair.

That was the last time I saw that device.

After not receiving any word from the support I phoned them about 3 weeks after sending it in. That must have been on about the 4th of May. The support told me „It’s already fixed and on the way. It should be at your place in the next days.“ – Yay. But nothing arrived.

About a week later I phoned them again. This time I got a tracking number from them. You can check the status here. At the time of writing, this says „Instruction data for this shipment have been received“ … since the 30th of April. About two phone calls later, I got the support to start an inquiry on my shipment.

The inquiry came up with „Should be delivered until end of the week. Otherwise it will come back to us and be sent again.“ – Okay, there is still hope that I will get my laptop back.

My last phone was on monday, when the support employee mentioned the word „replacement“ for the first time. I wasn’t really happy about that.

Today I received an email from Lenovo, stating that the parcel is lost by DHL. Unfortunately, they couldn’t provide me with an adequate replacement. For this reason, they want to give me my money back.

So the magic question is: Where the damned fucking fuck is my notebook? Somebody needs a high five … in the face … with a chair. And I would really like to know who that is.

Damn it, I am pissed!

tldr:

Don’t ever rely on Lenovo support, they will leave you stranded without your hardware.

Mainboardtausch – Status

Nachdem ich im Dezember schonmal von meinem kaputten Mainboard geschrieben habe, hier mal das Update wie es um den Service steht:

mainboard_reparaturIch bin mir sicher, dass der Servicepartner vor Angst schlottert. Schon die zweite automatische Mahnung. Das einzige was ich auch diesem System erfahre ist, dass wohl um 4:30 der Cron-Job die automatischen Mahnungen erzeugt.

Sicherlich gibt es einen Grund warum ein Mainboard nach über einem Monat noch nicht repariert ist, aber dann wäre es auch schön, den zu erfahren. Ich war davon ausgegangen, dass der Schaden recht eindeutig ist. Und inzwischen ist das Mainboard auch problemlos lieferbar, also warum habe ich noch kein neues?

Umstellung von Apache auf Nginx

Statt nur das Serverzertifikat zu wechseln habe ich gleich auch den Webserver von Apache auf Nginx umgestellt. Dabei interessiert mich die angebliche bessere Performance nur nebenbei, mir ging es um die bessere Unterstützung von TLS Ciphers. „Umstellung von Apache auf Nginx“ weiterlesen

Apple und TLS

Auf dem 30C3 habe ich festgestellt, dass meine Homepage auf Apple Geräten nicht geladen wurde. Es wurde eine Verbindung aufgebaut, aber dann kein gültiges Zertifikat ausgetauscht. Seltsamerweise waren bei den üblichen TLS-Testern keine Fehler feststellbar.

Beim Chaostreff habe ich dann erfahren, dass Apple keine 8kB Zertifikate verträgt. (Da gibt es auch schon den einen oder anderen Blogeintrag zu). Und da ich als kleiner Paranoiker ein solches Zertifikat generiert hatte, schlug der Bug dann auch bei mir zu.

Jetzt werde ich also mal die Zertifikate gegen kleinere austauschen müssen. Allerdings wird bei StartSSL kein neues Zertifikat ausgestellt bevor das Alte abgelaufen ist. Somit werde ich dann wohl doch zu CACert wechseln. Somit wird demnächst wohl eine Warnmeldung auftauchen, dass das Zertifikat gewechselt wurde und es jetzt nicht mehr von einer vertrauenswürdigen Stelle ausgestellt ist. Aber generell solltet ihr, sofern noch nicht geschehen, die CACert Stammzertifikate mal bei euch im Browser installieren.