DNS: Open Resolvers, Revisited

Long has been the list of failures in ISPs and carriers to force borken DNS servers on their customers, thereby manipulating their customers traffic, or outright censoring what their customers can see. To combat such manipulations, and also to make it harder to observe their customers' behaviour, it has been a pet project for some, also for me at some time, to run an open resolver, that allows random people on the Internet to query your DNS server for an arbitrary name. Unfortunately, the evil guys developed an attack [0] that makes it impractical to run an open resolver. So, while politically desirable, it is unfeasible to run an open resolver, and network operators around the globe strive for shutting them down.

Now, these attacks all rely on the simple fact that, with UDP, you do not have any kind of assurance that the source address in a packet in fact belongs to the sending host. In my opinion, if you are willing to take the effort, there is one obvious way to provide an open resolver that does not have this flaw: For hosts not on your own network, provide DNS over TCP only.

I hope that someone will hack this feature into unbound [1], so people can easily deploy open resolvers in a reasonably safe way, without disrupting the Internet. Currently, unbound's do-udp setting is only a combined setting for incoming and outgoing queries, causing upstream name servers excessive load.

Thank you for reading!

[0]See eg. http://openresolverproject.org/

Back to top

Fixing the Android Update Problem - A Few Thoughts

Time and again, Android has been getting the heat for leaving its users in the lurch in the face of security problems, while fixing such problems only in the most recent version. But in my opinion, not only Google, but also the manufacturers, are to blaim for this situation: They are the ones who aim to lock down the devices with their Frankenstein'ed versions of Android because they think it's their selling point, or at least their way to more revenue.

The following suggestions relies purely on speculation, because I am not privy to any contracts, product design or marketing discussions on behalf of any party. But from all I know, the following approach could be used to alleviate the problem from the user's perspective:

Google should imho

  1. fix such bugs in as many versions of Android as required to achieve 75% market coverage, and
  2. adjust their contracts in a way so that manufacturers who desire early-access and support from Google, as opposed to simply warping AOSP, are required to offer these updates for all handsets that were originally shipped or are currently running with any of the fixed versions of Android, within two weeks time, lest they lose some kind of access to the program, and the right to use the Android logo. Compliance should be determined frequently enough to not water down these requirements.

This would have the following nice side effects:

  • Google gets rid of the blame for not supporting their users (see point 1).
  • The manufacturers can still avoid the huge and profit-eating work of supplying the users with new versions of Android, but are being pressed to at least not leave their users alone (see point 2).

By going this route, the manufacturers are not required to give up a part of their business relationship to Google, which would be hard to argue despite them doing it all the time towards the carriers (let's think about that battle later), while making sure that the users are safe, sort of (and relegate the general security debate about Android to a different debate, too), without making it impossible to market new devices with new versions of Android.

The current situation, which I'd liken to driving a car with broken brakes, would imho warrant compulsory recall actions on behalf the manufacturers, which they would otherwise be legally obligued to perform - at least as far as my understanding of German consumer protection laws goes. It would be somewhat interesting to see such a case being heard before a German court, and I'm far from confident that the Android brand will not be hurt while the problem festers.

I have the nagging feeling that I cannot be the first to have had these ideas, but wanted to state them nonetheless.

Back to top

Firefox 30: Flash Always Plays After Upgrade

Recently, I have upgraded to Firefox 30 in order to profit from the security fixes. I was delighted with its much improved speed as well, but thoroughly aggravated with a number of very nasty bugs. Contrary to my previous experience, Firefox insisted on playing Flash videos instantly, of course despite me having had click-to-play etc. already enabled.

Anyway, to fix it, go to this, go to about:config and change the setting of

plugin.state.flash from the default value of '2' to '1'.

Save, and you're mostly set.

Unfortunately, I have found a number of situations where the browser insists on playing a video regardless, which I have not yet been able to configure away, although I have all obvious things configured to not auto-play.

Back to top

GitLab: Changing the URL

Recently, I had the problem of moving my GitLab installation from one URL to another. I guess the problem will hit many people every once in a while. On StackOverflow, someone posted half of the answer.

Make a backup and stop GitLab first! Then:


  1. In your application.rb file:

    config.relative_url_root = "/gitlab"
  2. In your gitlab.yml file:

    relative_url_root: /gitlab
  3. In your unicorn.rb:

    ENV["RAILS_RELATIVE_URL_ROOT"] = "/gitlab"

You also need to re-configure your web server appripriately.

Now... that does part of the job, but after doing it, I could not properly reach nor use my GitLab site. The two remaining issues are (a) adjusting the URLs in the database, and (b) updating the assets cache. Here are the remaining bits, assuming that you are on MySQL (adapt for other database engines, accordingly):

mysql> update events set data = replace(data, "", "");

Next, as the appropriate user, do this:

$ rake gitlab:satellites:create RAILS_ENV=production
$ rake assets:clean RAILS_ENV=production
$ rake assets:precompile RAILS_ENV=production

Then restart GitLab.

If you omit the recompiling of the assets, that will yield you broken icons, or, if you simply deleted them, a lot of 502s, until Rails was able to compile them.

At this point, you have access to your projects using the web, but SSH access does not yet work. You will see "Access denied" message. To fix that, you have to update your gitlab-shell configuration. Then put this in your config.yml:

gitlab_url: ""

This URL must reflect the new URL you have chosen. After that, re-install gitlab-shell.

Thanks to <rikurrr> for the idea of directly looking into the database.

Back to top

Schengenrouting = Zensur + Stasi + Monopol

Zum Thema Schengen gibt es offensichtlich einige Unklarheiten, was dies technisch und politisch bedeutet. Daher möchte ich auf einige Punkte, die mir bisher nicht klar genug herausgearbeitet zu sein scheinen, eingehen:

Versuch der Monopolbildung bzw. -erhaltung seitens der Deutschen Telekom

Die Behauptung ist, daß dieses Schengenrouting die in vielen Bereichen noch monopolartige Position der Telekom zementieren würde. Ich teile diese Ansicht. Der Mechanismus dazu sieht für mich wie folgt aus:

  1. Kleiner Wettbewerber X möchte (muß) Daten ins Telekomnetz schicken, weil er die Geschäftskunden und die Telekom die Verbraucher, die die Webseiten seiner Kunden ansehen wollen, hat.
  2. Da die Daten nicht mehr "irgendwo" entlangeroutet werden dürfen, muß der Übergang also neuerdings im Schengenraum liegen.
  3. Im Schengenraum hat die Telekom allerdings kartellartige Möglichkeiten, den kostenfreien Datentransport zu unterbinden, und dadurch X dazu zu zwingen, einen solchen Übergang zum Telekomnetz dort zu Freudenhauspreisen zu kaufen. Die Telekom dient hier nur als prominentes Beispiel für die Verweigerungsfront der wenigen Netzanbieter.

Bisher konnte der seine Daten dann notfalls über die USA, Rußland, Japan oder sonstwohin schicken, bis sie irgendwann im Telekom-Netz ankamen, weil die Telekom dort mit anderen ISPs verbunden ist. Diese Möglichkeit soll jetzt per Gesetz unterbunden werden.

Ein Schengen-Netz ermöglicht eine stark vereinfachte Überwachung und Zensur

Die Datenströme würden in einem Schengen-Netz auf deutlich weniger unterschiedlichen Bahnen als bisher fließen und nicht "heimlich" den Schengenraum verlassen dürfen, und wären daher leichter vollständig erfaß- und zusammenführbar. Außerdem bedingt die Konstruktion, daß die Routingentscheidung nun entlang geographischer Grenzen getroffen werden soll, daß man (a) herausfindet, ob die Daten den Schengenraum verlassen dürfen, was (b) eine massive zusätzliche Netzüberwachung und die Etablierung entsprechender Kontrollmöglichkeiten zur Folge hat. Meiner Einschätzung nach läßt sich die bisher geforderte Kontrolle nicht ohne den flächendeckenden Einsatz von DPI realisieren, eine Technik, die in der Vergangenheit bei anderen Anwendern wie eben dem Iran, aber auch Rußland oder China, immer auf das Heftigste kritisiert wurde.

Die teilweise angesprochene Möglichkeit, Datenverkehr mit Zoll zu beaufschlagen, ergibt sich quasi als Nebeneffekt.

Zusammenfassung und Bewertung

Ein solches "Schengen-Routing" hätte zwangsläufig technische Änderungen am Internet zur Folge, die ähnliche Kontrollmechanismen wie etwa im Iran etablieren würden. Diese wecken nach aller bisherigen Erfahrung auch entsprechende Begehrlichkeiten und laden zu Mißbrauch geradezu ein. Unter wirtschaftlichen Aspekten ist aus meiner Sicht offenkundig, daß die genannten kleineren Anbieter dann keine Chance mehr haben, einer Telekom-Zwangsabgabe in erheblicher Höhe - die Preise beginnen hier bei einigen Tausend Euro pro Monat - zu entgehen, was für viele das Aus bedeuten würde. Das Aus würde schon vorher dadurch kommen, daß die besagten Geschäftskunden von vorneherein einen Bogen um die genannten kleinen Anbieter machen würden, weil sie befürchten müßten, daß sie ihre Zielgruppe nicht mehr erreichen.

Wer Wettbewerb will, sollte sich für einen funktionierenden Markt stark machen, und wer stattdessen ein Monopol will, soll das bitteschön ebenfalls klar sagen.

Die Politik sollte es sich sehr gut überlegen, ob sie wirklich dahingehend Gesetze erlassen will, wenn wenigstens einer der Punkte Wettbewerb, Datenschutz oder Vertragsfreiheit mehr als eine reine Worthülse sein soll.

Für generelle weitergehende Informationen zu derartigen Themen empfehle ich ein Besuch beim CCC.

Back to top

Subscribing to Google Groups by Email

Maybe this has been documented somewhere, but at least, I cannot find it on Google's own support pages. So here goes:

Google Groups have become a major mailing list hub. Unfortunately, Google tries to coerce people into using their web interface, which is something I object to for a number of reasons (it's ok to have it as a fall-back, but not as a primary interface). Now, Google Groups can be subscribed to using standard email, and here is how. As an example, I'll use the GitLab mailing list.

  1. Figure out the list address:

    1. The group is at (https://groups.google.com/forum/#!topic/gitlabhq/). In that group, select a random posting, then use the button on the right of the "Sign in to reply" button to open a drop-down menu. Select "Show original".
    2. Locate the "To: " line (maybe another line - see below). For this group, it should read

      To: gitlabhq@googlegroups.com

  2. Subscribe to this group:

    1. Use your email program to send an email to this address:


    2. You will get a confirmation email with a token in the subject line. Reply to it.

    3. You "should" get a welcome message, and be done.

I write "should", as sometimes, Google simply drops the email, and there is no way to figure out, why. Therefore, I tend to use email addresses which I already used in conjunction with Google - they work best.

HTH, and hopefully, Google will get their act together, one day.

Back to top

Paßwörter und andere sensible Daten

Immer wieder schicken mir Leute Paßwörter und andere sensible Daten per Email zu, ohne diese Emails zu verschlüsseln - was problemlos möglich wäre, meine PGP-Schlüssel sind öffentlich verfügbar. Das mag manchmal unvermeidlich sein, wenn etwa Systeme automatisch derartige Emails verschicken, ohne auf Verschlüsselung ausgelegt zu sein, aber wenn Menschen über alternative Kommunikationswege verfügen, wäre es schon wünschenswert, wenn sie diese auch zu benutzen - oder eben ihre Emails mit PGP verschlüsseln.

Insbesondere Berufsgeheimnisträgern kann nur dringend empfohlen werden, derartige Maßnahmen zu ergreifen.

Zum Abschluß möchte ich noch kurz auf die amtliche Position zum Thema hinweisen:

BSI-Hinweis zu Paßwörtern

Back to top