Older blog entries for jas (starting at number 7)

IDNA flaws with regard to U+2024

In a bug report against libidn, Erik van der Poel gives an example of an internationalized domain name that is handled differently by different implementation. Another example of one such string is:

‘räksmörgås’ U+2024 ‘com’

If your browser supports Unicode, the string is: räksmörgås․com. Use cut’n'paste of the string into your browser and see what it tries to lookup (please let me know what you notice!).

The problem with this string is that it is on the form “[non-ASCII][DOT-Like code point]com”. Here ‘räksmörgås’ represents the non-ASCII string, which can be any non-ASCII string. Further, the U+2024 represent one character which looks like a dot, there are others that also contain dot-like characters.

The IDNA algorithm (section 3.1) implies that applications should treat the string as one label. The U+2024 character is not one of the dot-like characters that needs to be treated as a label separator. The ASCII string which is output after applying the IDNA algorithm is:


Note that the string contains an ASCII dot ‘.’ (0×0E). If applications are not careful how they resolv the name in the DNS, they will request information in a non-existing top-level domain ‘com-l8as9u’. This is because the DNS do not use ‘.’ to separate labels, but instead uses a length-value pair for each label. Thus the wrong string to lookup would be:


Whereas the right string to lookup would be:


Using DNS master file syntax, the name to lookup is xn--rksmrgs\.com-l8as9u.

What’s interesting here is that some implementations, such as Microsoft Internet Explorer and Firefox implements IDNA not according to the standard. Instead, they compute the following string:


Arguable, this is a better approach than what is specified by RFC 3490. MSIE/Firefox recognize that U+2024 is a “dot-like” character, by using NFKC. What is debatable is whether U+2024 will actually occur in practice, Unicode expert Kenneth Whistler says U+2024 will not be entered accidentally.

As the maintainer of GNU Libidn, I’m not yet sure about what to do about the situation. The conservative approach is to do nothing until the RFCs are updated. I have come up with a patch to add a new IDNA flag that treat U+2024 as a dot-like character early on. This would at least make it possible to produce the same (RFC non-conforming) output that MSIE/Firefox computes.

Syndicated 2008-01-14 15:38:27 from Simon Josefsson's blog

PAM module for Yubico

During the autumn, in Yubico, we have been working on a PAM module for the Yubikey. It allows you to use the Yubikey to login to your machine, to unlock the screensaver, and so on. I decided to let Google Code host this project, which is the first time I’ve used them. It will be interesting to see how working with their site is going to turn out.

ObLink: code.google.com/p/yubico-pam/

You can buy Yubikeys on our web shop. If you have an interesting idea about what can be done with the key, let me know and I may be able to arrange a good deal for you. :)

Syndicated 2008-01-14 10:39:22 from Simon Josefsson's blog

Response to GnuTLS in Exim Debate

Marc Haber blogs about GnuTLS in Exim4, and it suggests there is a long list of technical issues in GnuTLS. Given my involvement in GnuTLS, I decided to analyze each bug to see what we can learn and possibly improve.

I looked at the all bugs tagged with gnutls in the exim4 bug tracker. My impression is that Marc Haber has done a very good job as Exim4 maintainer in dealing with these GnuTLS related problems. Some of the frustration seems to be because submitters don’t respond to questions. Also it seems different problems are discussed at the same time, which makes it very difficult to help isolate and solve the problem. The only serious problem I’ve identified is the entropy depletion problem, and the GnuTLS team will try to address it. To me, the concern seems more of a volunteer time issue than a technical one.

Quick Summary

Bug #348046 is so complex that I cannot judge it. If the submitters are willing, it may be best to re-submit each problem separately. The problem with TheBat is interesting, but given the non-free status of TheBat and no other reports, it doesn’t seem serious. To reduce entropy consumption is something we should work on, but it is a ‘wishlist’ kind of bug, and to some extent may have already been solved by removing the DH generation code which depleats the entropy pool quickly. The rest appears to be already solved or should be tagged as ‘wontfix’.

Bug #316522

When the email client TheBat talks with exim4 4.50-8, gnutls (in exim4) will log (gnutls_handshake): An error was encountered at the TLS Finished packet calculation. Other clients than TheBat reportedly works. An older version of Exim4, specifically 4.32-2, worked though. It is unclear whether the version of GnuTLS changed when exim4 was upgraded from 4.32-2 to 4.50-8. There is no discussion of whether changing to OpenSSL would solve the problem.

Conclusion: The problem with TheBat warrants debugging. However, this do not seem to be a widely reported problem. Further, TheBat is not free software so we cannot help debug it.

Questions: The reported said earlier versions worked, which GnuTLS versions was this? Can the problem be pin-pointed to a specific GnuTLS release or Exim4 release? Does the problem go away with OpenSSL?

Bug #348046

This is a long bug report by several submitters. The initial report from Martin A. Brooks is stalled when he doesn’t respond to the (appropriate and relevant) questions that Marc Haber asks. The problem that Ian Zimmerman reports seems to be different, now GnuTLS clients work fine but OpenSSL clients fail to connect to the Exim4/GnuTLS server. The OpenSSL errors may suggest it only wants to talk SSLv2 for some reason (local configuration?). Debugging the OpenSSL problem further would be the appropriate response, and should likely be treated as an OpenSSL bug (!) until more evidence can be gathered. Later, Andrew McGlashan reports a problem where neither GnuTLS and OpenSSL works against the ‘Incredimail’ MUA.

Conclusion: The bug should really be forked into several problems, one for the initial reports where the submitter stopped responding, one for the OpenSSL problem, and one for the Incredimail problem (and as Incredimail isn’t a Debian package, it’s not Debian’s problem). Caveat: I may have missunderstood some parts of this bug report because different problems are discussed at the same time. Once that is done we can try to address each problem separetely.

Bug #338319

Report about an old version of exim4, seems to have been solved by removing the (buggy) exim4 code to re-generate DH parameters file needlessly. Last message says it will be closed in a few weeks.

Conclusion: Solved.

Bug #343085

Seems the same as the previous one, about exim4 in sarge. Not clear why this is open?

Conclusion: Solved.

Bug #390712

Appears to be triggered by GnuTLS implementing MAC padding to solve a security problem in TLS. OpenSSL reportedly does not implement the same work around, and would thus appear to be vulnerable to that problem.

Conclusion: Appears to be a ‘wontfix’ bug. Personally, I think GnuTLS could provide a simpler mechanism to disable MAC padding if applications deem this necessary. Someone could double check how important the MAC padding security concern is.

Bug #426013

Appears to be an unreprodicible problem with a specific certificate/key which the user cannot reveal. Another certificate/key from the same CA works fine. Theory: could it be CRLF problems? Other non-ASCII characters in the file? Nothing indicates a real GnuTLS problem here.

Conclusion: Likely not a GnuTLS problem.

Bug #446036

There is two technical claims here: that GnuTLS consumes too much entropy, and this would be a wishlist item that we could work on. The other claim is that ‘openssl actually supports full certificate chain lookups, so you can be guaranteed that this cert was signed was signed by that ca. gnutls does not, to the best of my knowledge.’. As far as I can understand with Stephen Gran refers to, that is simply false. It is suggested that GnuTLS’ performce is worse than OpenSSL, but there is no measurements to support that.

Syndicated 2007-11-09 11:00:14 from Simon Josefsson's blog


A free software conference in Sweden? That’s a rare one. Organized by the FSFE and Henrik Sandklef, it will be held on the 7-8 December 2007. I hope we’ll see more of this in Sweden. I’m proud to have been invited to talk about both GnuTLS and OpenID. I’m happy to see that there is a OpenMoko talk as well. If you want to participate, there is an early bird discount if you register now. If someone is going and would like to chat, drop me an email.

Syndicated 2007-10-23 10:29:02 from Simon Josefsson's blog


The TLS-AUTHZ document (protocol spec here) describes a mechanism to add support for authorization in the TLS protocol. The idea is part of a patent application, see the patent notification to the IETF. The protocol has a complicated history in the IETF. Right now a third last call is open to request feedback from the community. I’ve written about TLS-AUTHZ before.

RedPhoneSecurity is now trying to circumvent the IETF standardization process by trying to get the document published as an ‘experimental standard’. The document earlier failed to get consensus for publication on the standards track.

The responsible IETF Area Director, Tim Polk, argues that because there exists independent implementations, the community benefits from having the document published. The argument is silly because the only independent implementation is mine and I’m opposed to publication of the standard. Further, the document will remain accessible to anyone in the community with access to the Internet since it has been published as an Internet Draft. To clarify that we have no interest in a standard with patent claims, we have decided to remove the tls-authz implementation from GnuTLS. Together with the FSF we came up with the following statement which is part of the GnuTLS 2.0.2 release announcement:

** TLS authorization support removed.
This technique may be patented in the future, and it is not of crucial importance for the Internet community. After deliberation we have concluded that the best thing we can do in this situation is to encourage society not to adopt this technique. We have decided to lead the way with our own actions.

If you are concerned about having patented standards adopted by the IETF, now is a very good time to make your voice heard! The last call ends on October 23th. Please read about the issue, and familiarize yourself with the IETF process (RFC 2026, with updates related to patents in RFC 3989) and send your feedback to ietf@ietf.org.

Syndicated 2007-10-18 14:23:15 from Simon Josefsson's blog

Home Audio Server

Procrastinating real work, I documented my home audio server setup. I needed a cross-platform solution, and as a first step, I settled with MPD. The setup is only a few days old, and I may decide to change software eventually. But the current setup works under Gnome, Windows, Mac OS X and even on my Nokia 6233.

Home Audio Server

What may be missing is FM/DAB Radio and streaming of TV, but I’m not sure the little NSLU2 is up to it. We’ll see.

The writeup on how to do this is long, so I put it at a separate page:

(This is a continuation of my series to document the devices that run my home, the first was the internet setup).

Syndicated 2007-09-25 19:19:43 from Simon Josefsson's blog

GnuTLS v2.0

I released GnuTLS v2.0 yesterday, the announcement is available.

So now we can start thinking of nice stuff to have in the v2.1.x series. Integrating the PKCS#11 support is one. ECC support? TLS 1.2 may go into v2.0.x. Opaque PRF input support is planned. Some benchmarking and optimization could be interesting. Other ideas?

Syndicated 2007-09-05 07:08:58 from Simon Josefsson's blog

Building GnuTLS and GNU SASL without running ./configure

Sometimes it can be useful to build things without the autoconf ./configure machinery, and just use a simple and hand-maintained makefile and config.h. This is needed to build things in older uClinux environments. I wrote some instructions on how to build GnuTLS and GNU SASL, and their dependencies (libgpg-error, libgcrypt, libtasn1) without running ./configure, see:


The makefile/config.h aren’t specific to uClinux, so if you for some reason need to build these projects in some other environment, without autoconf, the files may be useful.

(Although if you want to build GnuTLS/GSASL properly under a modern uClinux, you’ll be better of reading an earlier post.)

Syndicated 2007-08-21 12:26:16 from Simon Josefsson's blog

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!