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.
Nice post. I only have a comment concerning 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.
This padding of TLS is not to work-around a TLS security problem. It is the CBC padding described in TLS 1.0 which protects TLS record packets against statistical analysis of data. I.e in ARCFOUR (stream) if you transmit 5 bytes, the encrypted data will be 5 bytes. In openssl CBC (which doesn’t use this feature) if you transmit 5 bytes with AES it would output 16 encrypted data. In gnutls the encrypted output varies and can be any number between 16-255 (of course it would be a multiple blocks).
So in that aspect gnutls is more secure than other alternatives in the sense that no eavesdropper can guess anything about the text by looking the size of the ciphertext. This is a standard TLS 1.0 and if a client cannot support this it is a buggy one.