Specification of DNS over Dedicated QUIC Connections

Specification of DNS over Dedicated QUIC Connections

While a lot of people debate DNS-over-https (and it’s dependencies), IETF has a specification for DNS-over-QUIC on it’s standards track.

This document describes the use of QUIC to provide transport privacy for DNS. The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient error corrections than UDP. DNS over QUIC (DNS/QUIC) has privacy properties similar to DNS over TLS specified in RFC7858, and performance similar to classic DNS over UDP.

Source: Specification of DNS over Dedicated QUIC Connections

Infosec community

Gerade brennt eine Security Diskussion darum, dass Videolan Updates für seinen Mediaplayer nur über http:// ausliefert. Auch meiner Meinung nach entspricht das nicht dem Standard von 2019, aber hey. Wohl hatten die Entwickler verschiedene Argumente, an dem Verfahren festzuhalten. Signaturen via gpg, Maintenance, Aufwand und so.

Jedenfalls eröffnet die Situation eine spannende Diskussion darüber was denn nun das richtige Vorgehen ist und vor allem: wer denn nun Recht hat. Die Videolan Community jedenfalls scheint die Kollegen von Infosec nicht sehr sympathisch wahrzunehmen.

Aus meiner professionellen Erfahrung muss ich leider konstatieren: auch anderswo gibt es keineswegs einen Zusammenhalt von Dev und Sec. Die Wahrnehmung wird in vielen Softwareentwicklungsteams sehr ähnlich sein. Viel mehr ist das ein ständiges sich gegenseitig sich anpöbeln. Ganz ähnlich wie in der beschriebenen Fall.

Das ist sogar nachvollziehbar weil es zwei Parteien sind, die individuelle Interessen vertreten. Und es gibt aus der Situation in der Regel auch keinen vernünftigen Ausweg, weil die Incentivierung der Teams nicht das gleiche Ziel anstreben. Security ist damit Teil eines Problems und nicht Teil einer Lösung.

“So könnt Ihr das nicht machen” eröffnen die einen, deren Auftrag es ist, Fehler in Software zu finden. “Hey, wir haben uns da Monatelang was dabei gedacht” halten Entwickler dann dagegen und schon ist die Debatte in vollem Gang.

Gerade weil in der Regel das Aufgabengebiet der Security Kollegen sich darauf beschränkt, Fehler aufzuzeigen, ist es für die gegenüber stehende Partei nur nachvollziehbar, jedes Audit als Quelle für zusätzliche, oft kaum nachvollziehbare Arbeit oder sogar Schikane wahrzunehmen.

Wenn Infosec auch einen Weg aufzeigen kann, der mit der Situation der Entwickler vereinbar ist, gelingt es sichere Software zu schreiben. Nur Fehler aufzuzeigen ist dafür zu wenig.

Im Fall von Videolan wird die Debatte nun öffentlich geführt, was nicht sehr schön zu verfolgen ist, aber es ist eine notwendige Debatte für jede tiefere Integration von Development und Security.

ssl and https with letsencrypt!

nomorecubes.net now (finally) leverages https!

It has a certificate from letsencrypt, automatically verified by the service, maintained and deployed by docker-letsencrypt-nginx-proxy-companion.

The deployment has been considerably easy through docker-compose, adding the container to the existing nginx-proxy like this:

version: '2'

services:nginx-proxy:
 image: jwilder/nginx-proxy
 container_name: nginx-proxy
 ports:
 - "80:80"
 - "443:443"
 volumes:
 - "./certs:/etc/nginx/certs:ro"
 - "/etc/nginx/vhost.d"
 - "/etc/nginx/conf.d"
 - "/usr/share/nginx/html"
 - "/var/run/docker.sock:/tmp/docker.sock:ro"
 letsencrypt:
 image: jrcs/letsencrypt-nginx-proxy-companion
 volumes:
 - "/var/run/docker.sock:/var/run/docker.sock:ro"
 - "./certs:/etc/nginx/certs:rw"
 volumes_from:
 - nginx-proxy