Updated: Aug 22 to add that the Postbank now informs their users about the use of the arcot domain.
Updated: Aug 24, some slights textual edits. 

Often people argue that DNS spoofing will not impact peoples ability to do banking and such. With the current practices both with user interfaces as well as the practices that the banks themselves deploy I claim that this is close to nonsense.

The basic attack is that user Alice wants to connect to her website: www.postbank.nl, in order to do a secure transaction the bank will redirect her to a secure website. If Alice is smart she will check the security of the connection by looking at the padlock and verifying if the domain she connects to make sense.

This is not going to work as long as:

• browsers do not display the domain and only a padlock, so users need to actually dig deep before they are aware of possible problems
• and banks happily redirect to domains hosted by unknown 3rd parties so that users are used to providing information to seemingly unrelated parties.

The obvious DNS based attack is to redirect the unsecured postbank.nl site and provide link to postbank.malice.nl that have valid certificates. We all know that getting a certificate for postbank.malice.nl is a trivial matter, it takes an e-mail address and a credit card number.

Below is an example that banks take it for granted that users trust Arcot.com as a middle man for either Mastercard or the Postbank. And personally I have never heard of arcot.com, so what do I know. 

The point I am making is that as long as Banks and Creditcard companies are implementing practices that make users get used to being redirected to completely unrelated, albeit HTTPS secured domains, they will not help to create a mindset where users will understand when they are subject to certain kinds of fraud, like phishing. 

My experience today 

Apparently  there is some new mechanism introduced to secure Internet credit card payments. Its called MasterCard SecureCode. I did not know about this, but that may be because I have not seen the snail mail yet. I was introduced to this new protection mechanism to protect against fraud while trying to pay for a conference. 

The original website redirected me to a site from tripledeal.com for the payment transaction. Even though the original website did not tell me that the transaction was to be handled by triple deal I decided to take the leap of confidence based on prior experience.

So far so good.

At the end of the payment process a new validation step is introduced: I am invited to go to my bank to validate the payment.

So pressing the "To Your Bank" button opens up a new window.

Oh... wait.

This screen asks me about details about my credit card. I need to be extra suspicious about entering information. Let me click on the padlock to verify that I am actually talking to my bank.

Oh.. so an organization called arcot.com is claiming to represent my bank? I do not believe that, anybody could be claiming to be my bank, even with that little padlock in place.

So, there is this new validation scheme I have never heard of, that needs some of my credentials, and that takes me to a site that does not seem to be my bank? What more do I need to suspect that I am subject of an elaborate phishing attack?

Let me read the page once more... Oh it says more information can be found at postbank.nl/SecureCode. So lets go there https://postbank.nl/SecureCode .... timeout. Let me try over a non secure channel and see what I get (depending on trailing/nontrailing slash).

So lets call the bank.

I called the Postbank's creditcard helpdesk I got a perfect explanation about the introduction of the SecureCode technology. I explained that I got a pop-up from postbank.arcot.nl, was put on hold, and was then explained that dealing with Arcot was OK.

The fortunate point was that I did not need to explain that me dealing with arcot.com was in sharp contrast with the anti-phishing policies that the banks deploy, and that the postbank helpdesk person actually understood that the pop-up should have originated from a postbank.nl or maybe mastercard.com domain. But he had no way to escalate the problem and asked me to report in e-mail. 

 Time to write a mail. I plan to post the correspondence in a follow up. 

 

Update Aug 22. 

It seems something happened. The postbank website now mentions:

 * Let op, als u hierop klikt wordt u naar een website geleid die geen Postbank adres heeft. Controleer of het adres begint methttps://postbank.arcot.com. Hiermee heeft u een veilige verbinding om uw SecureCode te registreren.

Which is basically a warning that you will be dealing with arcot.com and that that is OK.

This does partly address the problem

 

1.  Technically this information is posted on a non secure website, a DNS cache poisson could lead to a spoofed site. It would be better if this information would also be accessible via HTTPS which it is not.
2. The problem is still that the bank creates an expectation pattern that it is OK to deal with a domain name that is not rooted in the postbank domain. And that is exactly the thing they should try to avoid.

Who knows there will be a structural solution for this problem.

 

 

 

 

 

Today I upgraded, without any hesitation, my license for Curio that came with version 5 today.

I payed with Pay Pal and got a nice confirmation mail. Being a bit touchy about user interfaces and domain names (see my post earlier today) I post the following without comment.

 

Because I need to do a demonstration for which I need public IP addresses and I am not sure wether I will be behind a NAT box I decided to configure my Mac box to establish a VPN to my FreeBSD server.

The prerequisite is that you actually have public IP addresses to create a tunnel to. I've been using a /28 so my colleagues can make use of the tunnel too.

Setting up PPTPs is a bit involved since it involves understanding the various layers that are involved.

Below is an annotated configuration file /usr/local/etc/mpd5/mpd.conf. 

 In the example below assume that 10.15.22/24 is a piece of public address space. That 10.15.22.177-182 are the addresses assigned to users. 

#################################################################
#
# MPD configuration file for a VPN
#
#
#################################################################

startup:
# set user username password [admin|operator|user]
# This command configures which users are allowed to connect
# to the console. It may be invoked multiple times with
# different usernames.
set user admin secret admin
# set user foo1 bar1
# configure the console
set console self 127.0.0.1 5005
set console open
# configure the web server
set web self 127.0.0.1 5006
set web open

# We define a new interface for eache possible user
default:
load pptp_server




# Anotated Setup for pptp_server
 pptp_server:
# Pool of addresses to be used:
set ippool add LANPOOL 10.15.22.177 10.15.22.182

# Create a bundle template named VPN
create bundle template VPN

# Iterface configuration
# On demand is only useful when we want to make an outgoing
# connection
set iface disable on-demand
set iface idle 0

# Since we do not want to play routing tricks we'll proxy arp
# to the LAN so traffic will find its way to the interace
set iface enable proxy-arp
set iface enable tcpmssfix

# IP options
# TCP header compression
set ipcp yes vjcomp

# Set the IP range
# pick a fixed local address and allow assignment from a shared pool
# To assign a fixed address to a user use something like:
# joe "foobar" 10.15.22.178
# bob "foobar" 10.15.22.179
0 # in the mpd.secrets file
# that would always provide joe with the 178 and bob with the 179 address
set ipcp ranges 10.15.22.48/32 ippool LANPOOL
# This is the resolver that is available on the local lan
set ipcp dns 10.15.22.155

# Set the encryption on the VPN, Mac OSX uses PPTP uses this too.
set bundle enable compression
# Let this bundle use mppc
set ccp yes mppc
# Continue to configure mppc
# Use 128 bit MMPE encryption
set mppc no e40
set mppc yes e128
# Less secure but fastre recovery from lost packets
set mppc yes stateless
# Require Encryption



#Create links

create link template VPNLINK pptp
# Set bundle template to use
set link action bundle VPN
# Multilink adds some overhead, but gives full 1500 MTU.
set link enable multilink
# Enable address and control field compression, and protocol
# field compression
set link yes acfcomp protocomp
# Turn pap and chap type authentication off.
set link no pap chap

# Require CHAP authentication from the peer NB: Use enable The
# use of enable and accept have slightly different meaning in
# the context of PAP and CHAP.
set link enable chap

set link keep-alive 30 300
# We reducing link mtu to avoid GRE packet fragmentation.
set link mtu 1460
# Configure PPTP # This is the address to which you will have to connect using your vpn client
set pptp self 10.15.22.48
# Allow to accept calls
set link enable incoming

 

Troubleshooting

 

Having all configured out of the box things did not work as expected, after establishing a connection (by which the client was assigned 10.15.22.178) I could not forward traffic to the Internet. My suspicion was that proxy arp was not working on the FreeBSD server.  

To troubleshoot proxy-arp you login to a machine that lives on your LAN, different from your client. And ping the address that the client has been assigned.

Then you validate by first pinging and then checking if the arp address points to the interface by which your server is connected to the LAN.

otherbox# ping 10.15.22.178
otherbox# arp 10.15.22.178
? (10.15.22.178) at 0:10:4b:bc:24:1b on en0 [ethernet]
freebsdbox#ifconfig xl0: flags=8843 metric 0 mtu 1500
options=9
ether 00:10:4b:bc:24:1b
...

Those MAC addresses look good.. So proxy-arp was not the problem. What could be another reason why packets from the pptp interface do not make it to the xl0 interface and onto the net? But off course IP forwarding. If you forgot a sysctl net.inet.ip.forwarding=1 on your PPTP server then packets will never make it. So make sure your /etc/sysctl.conf contains such line.

 

Setting up your connection to this VPN server is trivial, just follow the instructions in your apple help instructions. 

Choose Apple > System Preferences, and then click Network.

 

 

With IPv6 deployment I'd like to put my money where my mouth is so after the IETF IPv6 only network experiment I wanted to make sure that my jabber server runs both IPv6 and IPv4.  I ran into a bunch of problems:

OpenFire is documented to run IPv6. It draws its capabilities from the java implementation it runs on.

The default Java virtual machine that comes with the FreeBSD ports is diablo-jdk15. That port does not come with IPv6 enabled. You can test that by using the ListNets program that is available from the Java Tutorial site. Copy and paste the code on that page into a file called ListNets.java and test

$ javac ListNets.java
$ java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01)
Java HotSpot(TM) Client VM (build diablo-1.5.0_07-b01, mixed mode)
$ java ListNets
Display name: lo0
Name: lo0
InetAddress: /127.0.0.1
Display name: rl0
Name: rl0
InetAddress: /213.154.224.4
InetAddress: /213.154.224.1
$

I double checked if there is a compile time configuration option to turn on IPv6 for diablo, there is none. Off to install the jdk1.5 port. Here you have to start with a "make config" in order to enable IPv6 support and compilation will take an hour or so. Once installed the test program will show all interfaces:

$ /usr/local/jdk1.5.0/bin/java -version
java version "1.5.0_14-p8"
Java(TM) 2 Runtime Environment, Standard Edition (build )
Java HotSpot(TM) Client VM (build 1.5.0_14-p8-olaf_28_apr_2008_16_18, mixed mode)
$ /usr/local/jdk1.5.0/bin/java ListNets
Display name: lo0
Name: lo0
InetAddress: /fe80:5:0:0:0:0:0:1
InetAddress: /0:0:0:0:0:0:0:1
InetAddress: /127.0.0.1

Display name: rl0
Name: rl0
InetAddress: /2001:7b8:206:1:0:0:4:53
InetAddress: /2001:7b8:206:1:0:0:0:53
InetAddress: /2001:7b8:206:1:0:0:0:1
InetAddress: /fe80:2:0:0:240:f4ff:fe37:8232
InetAddress: /213.154.224.4
InetAddress: /213.154.224.1

Starting openfire manually, after setting JAVA_HOME to /usr/local/jdk1.5.0/ one can validate that the program actually binds to the tcp6 sockets:

openfire java 96677 11 stream (not connected) openfire java 96677 13 tcp6 *:7777 *:*
openfire java 96677 16 tcp6 *:5269 *:*
openfire java 96677 17 tcp6 *:5229 *:*
openfire java 96677 22 tcp6 *:9090 *:*
openfire java 96677 25 tcp6 *:9091 *:*
openfire java 96677 30 tcp6 *:5222 *:*
openfire java 96677 33 tcp6 *:5223 *:*

Testing the IPv6 connection towards the openfire management interface using "telnet ::1 9090" demonstrates that the IPv6 connection works. However a "telnet 127.0.0.1 9090" fails. So we only have IPv6 and no IPv4 connectivity.

So, why is this?

FreeBSD (and open and net BSD) turn off IPv4 binding to IPv6 sockets by default. This behavior is controlled using the  "net.inet6.ip6.v6only" kernel option. One workaround to solve this problem is to set net.inet6.ip6.v6only=0. However this could lead to cause possible security problems. The security problems in Itojun's draft are the only security issues I am aware off and they can be mitigated by filtering on ::ffff:0:0/96 network traffic e.g. at ones network perimeter. That traffic should not be on the network in the first place (see e.g. informationa RFC number RFC5156 section 2.2).

With  net.inet6.ip6.v6only=1 it is impossible to use AF_INET6 to bind to both IPv6 and IPv4 addresses.

As an alternative I have tried to bind to interfaces explicitly in the openfire.xml configuration but that fails too as it seems that openfire only accepts one instance of the network.interface configuration option. I would argue that on multihomed machines one may want to bind to a subset of the available addresses instead of binding to the wildcard and that allowing for address family agnostic specification of one or more interfaces is the best solution.

Starting two instances of openfire, one on IPv6 and one on IPv4, by specifically binding to the v6 and v4 interfaces is no solution either because the IPv4 server would not know of the presence of clients registered on the IPv6 server.

In order to get a working dual stack openfire running on FreeBSD do the following. 

 

The HOWTO 

 

•  add the following lines to your /etc/rc.conf:

  # Allow IPv4-mapped addresses ipv6_ipv4mapping="YES"

• Make sure your java distribution supports IPv6.
  • /usr/ports/java/diablo-jdk15 does not support IPv6
  • /usr/ports/java/jdk15 and /usr/ports/java/jdk16 do support IPv6, but you have to rune make config and specifically set IPV6 support before building!
• Edit your /usr/local/etc/rc.d/openfire to allow for a different java vm to be used:

  --- /usr/local/etc/rc.d/openfire.bak 2008-05-02 10:22:16.000000000 +0200
  +++ /usr/local/etc/rc.d/openfire 2008-05-02 10:23:00.000000000 +0200
  @@ -20,6 +20,9 @@
  # Set it to java home directory.
  # openfire_javargs (args): Set to -Xmx256M by default.
  # See java -h for available arguments.
  +# openfire_java_home (path): Set to /usr/local by default.
  +# Sets JAVA_HOME before calling java
  +# See javavm(1)
  
  . /etc/rc.subr
  
  @@ -34,6 +37,9 @@
  : ${openfire_libdir:=/usr/local/share/java/classes}
  : ${openfire_home:=/usr/local/share/java/openfire}
  : ${openfire_javargs:='-Xmx256M'}
  +: ${openfire_java_home:=/usr/local}
  +
  +export JAVA_HOME=${openfire_java_home}
  
  pidfile=/var/run/${name}.pid
  
  

  Hopefully the openfire ports maintainer will apply this patch, or offer a similar solution in a forthcoming release.
• Set openfire_java_home in your /etc/rc.conf:

  # Start openfire, make sure to use an IPv6 enabled java engine
  openfire_enable="YES"
  openfire_java_home="/usr/local/jdk1.6.0/"   # or your local variety

• Verify that both IPv4 and IPv6 are being used. Allow openfire a few seconds to bind to the various interfaces en then use sockstat to verify if tcp4 and tcp6 are in use:

  # sockstat | grep openfire
  openfire java 12742 27 stream (not connected)
  openfire java 12742 29 udp46 *:10020 *:*
  openfire java 12742 30 tcp46 *:7777 *:*
  openfire java 12742 31 tcp6 ::1:60235 ::1:60234
  openfire java 12742 33 tcp46 *:5229 *:*
  openfire java 12742 35 tcp46 *:5269 *:*
  openfire java 12742 45 tcp46 *:9990 *:*
  openfire java 12742 49 tcp46 *:9991 *:*
  

• Don't forget to block ::ffff:0:0/96 traffic on your network

 Some Tweaks

In the DNS I pointed the SRV records to a host with both an IPv4 and IPv6 address, something like:

_xmpp-client._tcp.jabber.secret-wg.org. 300 IN SRV 0 0 5222 jabber.secret-wg.org
jabber.secret-wg.org. 3600 IN A 213.154.224.48
                      3600 AAAA 2001:7b8:206:1:0:1234:be21:e31e

 

It turns out that with the clients I tried (iChat and Adium) I was not able to connect to the server while being connected to an IPv6 only network. When specifically connecting to the server by entering jabber-6.secret-wg.org (with AAAA RRs and without A RRs) things work like a charm.

 

Note also that you have to generate a certificate with a number of alt names: jabber.secret-wg.org *.jabber.secret-wg.org, jabber-6.secret-wg.org, and *.jabber-6.secret-wg.org. Create an openssl configuration file with information similar to the following, create a certificate request and get it signed with for instance cacert.

 

commonName = Common Name (eg, YOUR name)
commonName_default = jabber.secret-wg.org
0.subjectAltName = Subject altname
0.subjectAltName_default = DNS:*.jabber.secret-wg.org
1.subjectAltName = Subject altname
1.subjectAltName_default = DNS:jabber-6.secret-wg.org
2.subjectAltName = Subject altname
2.subjectAltName_default = DNS:*.jabber-6.secret-wg.org

 

 

[Edited to clarify a few points on April 30]

[Edited to add the Howto section on May 2]

[Edited to add the Some Tweaks section on May 7]

 

I just read an article on ZDnet. It describes a demo of an exploit on an un-patched XP SP1 machine on an open wireless network. The MS executive was surprised by the ease of the attack.

Nick McGrath, head of platform strategy for Microsoft U.K., was surprised by the incident.

"In the demonstration we saw, it was both enlightening and frightening to witness the seeming ease of the attack on the (Windows) computer," said McGrath. "But the computer was new, not updated, and not patched."

The first sentence makes one wonder on which planet has this man been hiding. The second sentence makes me wonder how machines are sold other than new, not updated, and not patched.

 

My brother in law gave me a late birthday present: The latest Beasty Boys album: The Mix-UP. 

I have had a weak spot for the Beasty Boys for many years. I am not particularly fond of their rap style, its non melodic and almost old-school-cliche they do have 'balls'. Their "Get it together" from the 1994 album "Ill Communication" is one of my all time favorite Rap tunes. The Boys seemed to have managed to merge Rock and Roll and Rap in a credible and sustained way.

 Il communication lead to "The Sound from Way Out", an instrumental album that I enjoyed listening to with great pleasure.

 I was a bit surprised to find the text "Their First-Ever Full Album of All-New Instrumental material", obviously this fine marketing text needs to be close read to understand that its the first album with exclusive new material, in contrast to the Sound from the way out, that contained material from Ill Communication. Anyway, the marketeers have not spoiled the pleasure.

The sound of The Mix-Up is remarkably similar to the sound of the Sound from the way out. It seems (probably not by accident) that not much care have been taken to production value; 8-track, bedroom recordings is  my first impression. The seemingly low production  is the charm of the album; clean drum sounds, Hammond organ, wah-wah guitar, and bongo. Melodic music, with strong Bass and Guitar riffs and almost trivial melodies. Like the music that folk from the neighborhood are playing in the local community center.

To me the charm of the album is that it sounds like the music that I would like and could technically play. A couple of guys making fun without pretense, it is inspiring, and it comes close to what I think what Rock and Roll is all about.

EDITED July 12 2007

The text below is an update from the original post (June 18, 2007), that original post turned out to contain a few errors.

---

 

We have an asterisk server installed back at work and for the teleconferencing purposes I got myself a  SNOM300 SIP phone. I configured the phone to do all its NAT magic using STUN and  tested that with my  linux based homebrewed NAT box.

That worked, but the setup did not migrate to a NATted network behind my new Speedtouch 780.

Turns out that in order to use SIP behind a Speedtouch 780, that has a SIP aware application level gateway that does all kind of weird tricks to your packets. 

Having configured your SNOM to find its way through a NAT using Stun and the ALG in the Speedtouch does not work well, and generates weird timing issues that manifest themselves as 'Authorization error" in the Sytem Information panel of the SNOM phone.

The degug output on asterisk (connect using asterisk -rc and use "sip set debug") shows something of an explanation when following the SIP dialogue.

After the first registration attempt the server sends back a 401 Unauthorized message with all the parameters needed for proper authorization, including a so called 'nonce'

<--- Transmitting (NAT) to <public-ip>:52899 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 
(...skip...)
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3d58a314"
Content-Length: 0

The response to that reply is a new request from the client, without any authentication info. And the reponse from the server is again a 401 reply, with a new nonce...

<--- Transmitting (NAT) to <public-ip>:52896 --->
SIP/2.0 401 Unauthorized
(... skip ...) CSeq: 2 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="1aa0547a"
Content-Length: 0

Only at the 3rd try the client registers with the authentication code... but it uses the nonce that was returned for the first request

<--- SIP read from <public-ip>:52899 --->
REGISTER sip:nlnetlabs.nl SIP/2.0
(...skip...)
CSeq: 3 REGISTER
Max-Forwards: 70
Contact: ;q=1.0;flow-id=1;+sip.instance="";audio;mobility="fixed";duplex="full";description="snom300";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"(...skip...(...
(...skip...)
Authorization: Digest username="username",realm="asterisk",nonce="3d58a314",uri="sip:nlnetlabs.nl",response="somehexcode",algorithm=md5Expires: 3600
Content-Length: 0

At that moment the Asterisk debug output will show some critical information

<------------>[Jul 11 12:01:48] NOTICE[89797]: chan_sip.c:8167 check_auth: Correct auth, but based on stale nonce received from '"username" '

What is probably relevant is that you see this happen when you turn on "Stun" and that the frequency of the registration attempts is correlated to the Stun interval you configure in the NAT settings for a the identity on your SNOM phone. Also the port on which the dialogue happen jumps for each Cseq.

After seeing this I've tried a number of permutations of settings, on the snom phone I tried all sorts of timing parameters and in the asterisk configuration I turned the NAT settings on and off. All with variable results.

Turns out that one can turn off the SIP ALG in the speedtouch 780, which solves the problem. You have to use the command line interface of your speedtouch. The CLI reference guide is available on-line.

 The magic words are: 

{Administrator}[connection]=>appconfig application=SIP SIP_ALG=disabled

NB: I have not been able to find a way to tell if the SIP_ALG is enabled or disabled using appinfo or any other command in the CLI, but I have not really been looking hard.

As soon as the SIP application level gateway has been disabled you are in business as long as:

 

• You configured NAT=yes for this particular user in your Asterisk's sip.conf
• You have configured a stun server in the NAT settings (under the identity settings) on your SNOM phone.

In other words. Do not rely on the intelligence of the ALG in the speedtouch modem, use 'classic' nat traversal. The meta problem here seems to be that all components in the chain try to apply their own hacks to traverse through the NAT and they do not really work nice together.

 One of these days I have to figure out if I can make the SNOM, the SpeedTouch, and the Asterisk server run over IPv6 (I hear evil laughter somewhere, because AFAIK at least two of these components will not work on IPv6 natively yet).  Life would be good if the ADSL modem would be able terminate a V6 tunnel,   do IPv6 route advertisements or DHCP6 and would not be using silly NAT tricks.

The benefit of this particular setup is that the RTP traffic from the phone will terminate at the Asterisk server, that will therefore act as a natural IPv6/IPv4 application gateway.

Keywords: NAT, Speedtouch 780, SNOM300, SIP, Asterisk 

 

We recently bought a house and we are now in the proces of painting it. Some walls need a little more than just a bit of paint. They need patching and fixing and, and that is really bad, removal of texture. I bought myself a grinder to perform the first step. The second step is where ARDEX commes in.

 ARDEX is a plaster/synthetic material  that you apply to your walls or ceilings. I am completely unexperienced in plastering but this stuff works like a charm.

Its hard to get though. I had to call 5 hardware stores to find an 'obscure' specialized store that carried it.

 I didn't know I could be so enthousiastic about a bag of powder.

I use a Unix based OS which means that I get laid as often as I reboot my computer. (More)

I run a dual boot PC back home. Today I was mucking around with grub and accidentally typed "grub-install /dev/hda1". Kids, never try adding a partition number to the device name. It screwed up my NTFS partition.

I probably could have restored the partition using what seems to be an excelent procedure but I decided to install windows XP from scratch. That is probably the best way to get rid of that rootkit Sony gave me a couple of months ago.

Besides I felt comfortable doing this because I had just back-upped all my important data (documents, application settigs, etc) a few days ago. Its just great that one can write backupscripts with rsync and tar and run them in cygwin. Now it is just a matter of getting some registry settings back. Still an evening worth of work *sigh*.

this blog used plog as its back-end since we started. It is a nice piece of open source software that can do with some support.

Al the more reason to spread the word that the new name for "plog" is "Lifetype".

Yesterday I presented a column at het Domeinnaamdebat 2006. It was intended to start a discussion on the use of IDN within the Dutch top-level-domain. Although I am very supportive of the IDN technology I do not think it is needed for functional use of web, mail, voip and all those other fine Internet protocols under the .NL domain. Introduction causes more pain than worth.

If .NL were to deploy IDN we should allow more than only the few characters that are currently recommended by SIDN. In one should introduce Arabic, Cyrillic, Chinese and other scripts too. The restrictions to the current character set are artificial and arbritrary.

The text is in Dutch, I actually needed to introduce a new locale into the blogging software in order to cut and paste the UTF8 based text. I hope all characters are presented properly on all browsers.

Ik ben gevraagd om de discussie over IDN met een column in te leiden. Ik noem mijzelf soms DNS protocolspecialist en een technische presentatie over Unicode, Nampeprep, stringprep en normalisatie zou dus voor de hand liggen. Dit wordt niet zo'n presentatie. Ik neem als uitgangspunt de aanbeveling van SIDN en stel hardop wat vragen. Ik chargeer zo nu en dan een beetje, het blijft tenslotte een column.

Veel protocollen op het Internet gaan uit van 'hostnames'. Hostnames hebben de restrictie dat ze worden uitgedrukt door 26 Latijnse letters, 10 cijfers, en een streepje. De namen van webservers zijn 'hostnames', de namen aan de rechterzijde van het apenstaartje in een e-mail adres zijn 'hostnames'. Hostnames zijn een deel verzameling der domeinnamen, maar dat is een technisch detail waar ik niet verder op in ga. Wordt niet verward doordat de termen domein en hostname door elkaar gebruikt worden.

Het International Domain Names, of IDN, protocol is uitgevonden om 'hostnames' weer te geven in een schrift dat afwijkt van 26 Latijnse letters, 10 cijfers en een streepje. Er zijn nogal wat schriften die afwijken van die beperkte karakterset; Japans, Chinees, Linear B, Zweeds, Russisch, &c, &c. IDN maakt het mogelijk om domeinnamen op in verschillende schriften te representeren en voorziet daarmee in een economisch behoefte. Niet voor de gebruikers van Linear-B maar voor Japans en Mandarijn des te meer.

IDN is een afspraak over hoe ingetypte tekst in een 'vreemd' schrift wordt omgezet naar tekens die mogen voorkomen in een 'hostname'. Het definieert ook hoe de 'hostname' weer naar de oorspronkelijke set glyphen wordt terug getransformeerd. IDN wordt geïmplementeerd op applicatie niveau. Voor gebruikers van een applicatie zonder IDN ziet de domeinnaam er ook uit als een klassieke domeinnaam die de combinatie "xn--" en wat onbegrijpelijke letter combinaties bevat.

Men zou alle denkbare karakters kunnen toelaten. Dat is niet echt praktisch, het lijkt dus redelijk om keuzes te maken met betrekking tot het gebruik van de karaktersets. Die keuzes zijn commercieel, economisch en cultureel.

Ten eerste zullen we moeten kiezen welke schriften we gebruiken.

In haar aanbeveling stelt SIDN dat het zijn afbakening definieert ten behoeve van de Nederlandse Internet gemeenschap. Ik weet niet waar die Nederlandse Internet gemeenschap uit bestaat. Zijn dat de mensen die surfen naar Nederlandse domeinnamen, de mensen die een account hebben bij een Nederlandse provider, de mensen die in het Nederlands communiceren, de mensen die in Nederland zaken doen, de mensen met een Nederlands paspoort die zich op het Internet begeven? U begrijpt dat iedereen die zich aan een dergelijke definitie waagt een goed politicus moet zijn.

Uitgaande van de Nederlandse taal wordt er gekozen voor het 'Latin' schrift. Dat schrift bevat inderdaad alle karakters die we het Nederlands, het Frysk, het Haags en het Limburgs gebruiken. Het omvat zelfs karakters die in het Turks gebruikelijk zijn. Maar waar moet nou de islamitische slagerij om de hoek terecht? Kan hij zijn bedrijfsnaam registreren in het schrift wat zijn klanten appelleert: Arabisch. Mijn islamitische slagerij is ingeschreven in de kamer van koophandel, heeft een Nederlandse Internet provider, slacht Nederlandse geiten en is bovendien oud-Hollandsch goedkoop. Is hij geen deel van de Nederlandse Internet gemeenschap? Al is een keuze voor 'Latin' is niet geheel onlogisch, er wordt wel een culturele grens getrokken die misschien opgerekt moet worden. Wie neemt de verantwoording voor die keuze?

Als er dan al voor een bepaald schrift is gekozen, zijn we dan klaar voor de komende 10 jaar? Kan een toekomstige Europese richtlijn over het gebruik van schriften binnen de lidstaten worden uitgesloten? Het lijkt me geen slecht idee om als randvoorwaarde aan de invoering van IDN te stellen dat nieuwe schriften later kunnen worden ingevoerd.

Welke schriften, één of meer, we ook kiezen we kunnen een aantal karakters uitsluiten dankzij technische limitaties van het IDN protocol: geen spaties, samengestelde karakters, &c. Daarnaast worden de hoofdletters die de door IDN gedefinieerde transformatie niet overleven uitgesloten. Het ruimt lekker op en er is wat mij betreft weinig willekeur in deze keuze.

Niet technische keuzes komen weer om de hoek kijken als we de visueel verwarrende karakters uitsluiten. Die karakters worden in het Engels homoglyphen genoemd. Een Nederlandse variant van dit Latinisme heb ik niet kunnen achterhalen. Maar dat terzijde.

ICANN beveelt aan dat verschillende schriften niet door elkaar gebruikt mogen worden.

Dat de uitbaters van undutchables.nl daardoor hun merknaam niet als UИDUTÇABLΣS.nl onder kunnen registreren is jammer, maar we kunnen de schuld bij de ICANN aanbeveling leggen. Er moet wel tussen verschillende varianten van het Latin schrift worden gekozen, dat is een detail.

Blijft de angst dat er homoglyphen binnen een karakterset voorkomen. "paypal" en "pąypal" (geschreven met een 'a' met 'ogonek') lijken veel op elkaar. Dat verschil kan door booswichten wordt uitgebuit. Op basis van mogelijke verwarring en het niet aanwezig zijn van karakters in het Nederlands wordt in de aanbeveling van SIDN de hele "Extended Latin A" karakterset weggestreept. Sluiten we daardoor de Nederlandse Internet gebruiker uit? Ik weet het niet, ik weet immers niet wie die gebruiker is. Is de restrictie terecht, ook dat weet ik niet.

Met het uitsluiten van de 'Extended Latin A' karakters is de angst voor misbruik van homoglyphen niet uit de lucht. Daarom worden in de SIDN aanbeveling, mijns inziens volstrekt willekeurig, nog een aantal karakters weggegooid. Daaronder de ø, de o met de schuine streep. Dat maakt registratie van bløf.nl onmogelijk. Ik vraag me af of de leden van Bløf zich lid van de Nederlandse Internet gemeenschap voelen of niet. Ze zingen in ieder geval wel bloedmooie Nederlandse liedjes. Kunnen de leden van het 'anhangerschap Normaal' nu niet de domeinnaam 'høken.nl' registreren?

Ook de ï, een i met een trema, wordt weggemieterd. Dat is jammer want 'goed-geïmplementeerd.nl' zou ik zelf een interessante domeinnaam vinden. En waarom wordt een i met een trema wel gezien als homoglyph en een a met trema niet? Voor een nietsvermoedende surfer ziet "äbnamro.nl" er waarschijnlijk hetzelfde uit als "abnamro.nl". Als de gebruiker al naar de adresbalk van zijn browser kijkt. En waar blijft de "ç", de c met cedille? Waar moeten we heen met onze in het Turks geschreven namen (de schoolklas van mijn zoon zit er vol mee).

Over de adresbalk gesproken. IDN heeft alleen betrekking over wat er in een adresveld van een applicatie wordt ingetypt. Niet op de tekst in de browser, of in een e-mail.

Wie heeft er recent nog een domeinnaam in getypt in zijn adresbalk? Wie heeft er in één keer foutloos www.domeinnaamdebat2006.nl in zijn browser getypt en wie heeft er voor "domein debat .nl 2006" ge-googled?

Daarnaast vraag ik me af hoeveel mensen er weten hoe je een é, û of een ï moet typen? Heeft invoering van IDN wel nut als je bijna zeker weet dat een groot deel van de Nederlanders Café zonder accent aigu schrijft. Overleeft www.tête-à-tête.nl een radio commercial? Bovendien heeft die adres balk uiteindelijk weinig te maken met wat er in de browser wordt gepresenteerd.

Mijn islamitische slagerij heeft voor zijn Arabisch schrijvende klanten een link staan vanaf een portal voor Arabisch schrijvende Nederlanders. Ik kan die link gewoon volgen zonder dat ik een letter Arabisch in type. Een uurtje willekeurig rondklikken op sites die Japans schrift gebruiken kan ook erg opwindend zijn. Ik kan mijn IJslandse collega Guðmundsson gewoon correct adresseren door te clicken op een link in mijn adresboek. Mijn punt is dat ik een bepaald schrift niet in de adres balk hoeft te kunnen typen om in je eigen schrift te kunnen mailen en surfen. Die adresbalk is zo belangrijk niet.

Maar laten we dit nu eens allemaal terzijde schuiven en eens kijken naar de economische zijde van het verhaal.

Hoeveel gaat de invoering van IDN kosten? Een paar zaken die in ieder geval geld gaan kosten is de intergratie in de Whois Database,in de Whois clients, in het Billing systeem, in de systemen waarmede de leden met SIDN communiceren en in de systemen waarmee de leden zaken doen met hun klanten. Al deze systemen moeten zo gebouwd worden dat andere karakters op termijn moeten worden kunnen ingevoerd. Met andere woorden op bijna alle systemen moet IDN worden geïmplementeerd.

Juridische kosten gaan omhoog, ook al probeer je homoglyphen uit te sluiten je gaat te maken krijgen met homografen. Zijn "cafe-bluf" en "café-bløf" verschillende merken, betekenen ze hetzelfde? De invoering van meer variatie in het schrift zal leiden tot meer variatie in interpretatie en dus in hogere juridische rekeningen.

Stel we gaan al die kosten naar rato omslaan naar die enkele web site houder die IDN gaat gebruiken. Is de prijs van een domeinnaam dan nog wel reëel? Hoeveel betaald u voor "reëel.nl"? Gaan we er met zijn allen voor betalen? Is er een economische behoefte of gaat het alleen om het weergeven van beeldmerken in het adresveld van e-mail programma's en browsers?

U begrijpt het van mij hoeft het niet zo nodig. Hebben we ons overigens al afgevraagd welk probleem we proberen op te lossen? Waarom we het in de eerste plaats over IDN hebben?

In a recent post on the SONY DRM Hell Bruce Schneier refers to a statistical analysis done by Dan Kaminsky.

The premissis is that all that query for these addresses are interested in downloading the patch. But later on in the article Schneier writes

In many of these blogs some of the above addresses are linked and it would not surprise me if blog-readers following these links are a significant fraction of the query sources.

Even though I follow the instructions on the PLog 1.0/XMLRPC page, I have problems getting pLog and ecto to work with pictures.

After including a thumbnail with the 'iphoto' interface button and publishing the message Ecto responds with a "Could not parse response" message.

What I notice is that:

• The original image is uploaded to the resource album but the thumbnail is not.
• The console log shows an empty response.

I had some hope that Paul's time sink would contain some hints but was not able to find anything there.

Doing the pictures manually is such a pain.

I would love to build myself a very silent computer. But I'm affraid that in my hands such machine would become a little messy.