nmav's Blog

The need for SSH-like authentication in TLS

2012-02-18T15:27:00.001+01:00

After the Diginotar CA compromise it is apparent that verifying web sites using only a trusted certificate authority (CA) is not sufficient. Currently a web site's certificate is verified against the CA that issued it and checked for revocation using the OCSP server the CA set up. If the CA is trusted by the user, this process protects against man-in-the-middle attacks when visiting such a web-site, and also against leakage of the web-sites private key (e.g. via OCSP as long as the leakage is reported to the CA). This is an automatic process that does not require the user to be involved, but it comes at a cost. There is a single channel for verification, the CA.

The certificate based web-site verification tries to convert the trust we have in a merchant to the digital world. That is currently done by having "few" authorities that provide certificates to the merchants and based on those certificates we should base our decisions. However, trust in trade requires more than that. For example wouldn't it raise suspicions, a laptop from a merchant who approached you in a parking lot and provided you with a legitimate looking brand card? Would his business or credentials card be the only thing to check? Those heuristics are unfortunately not currently available in the digital world.

If it wasn't for the Chrome browser that implemented a preliminary version of key pinning, the Diginotar compromise might not have been uncovered. In the maliciously-issued certificates, the automatic verification procedure was not reporting any problems. It was the change in public key that triggered the key pinning warning and eventually to the Diginotar issue becoming public. Thus having an additional verification channel to standard PKI proved to be a success.

Key pinning, as of the 01 draft, is mostly server driven. That is, the user has very little control on trusting a particular server key if the server operator doesn't ask to. Another approach is the SSH programs' typical authentication method. The trust on first use. That describes the concept where the public key of the peer is not verified, or verified out-of-bound, but subsequent connections to the same peer require the public key to remain the same. That approach has the advantage that doesn't depend on the server operator setting up anything, but also the disadvantage that the user will be bugged every time the server changes its public key.

In any case having such methods to complement standard certificate verification and revocation checks, provides an additional layer of security. With such a layer, a CA compromise would not be enough for a large-scale man-in-the-middle attack since changes in the public keys would be detected and users would be warned. Such warnings might not be entirely successful in preventing all users from continuing but would raise suspicions for the legitimacy of the server, which might be enough.

For that, we implemented in GnuTLS a framework to be used either by applications that want to use key pinning, or a trust on first use (TOFU) authentication. That consists of three helper functions that store and verify the public keys. They can be seen in the GnuTLS manual. The included program gnutls-cli has also been modified to support a hybrid authentication that includes certificate authentication, TOFU and OCSP if the --tofu and --ocsp arguments are specified. The main idea of its operation is the idea discussed here and is shown in this example code at the manual.

Do we need elliptic curve point compression?

2012-01-01T23:25:00.000+01:00

GnuTLS has recently added support for elliptic curves (ECDSA and Elliptic curve Diffie-Hellman). Elliptic curves are an improvement on public key technologies, mostly in efficiency because they require operations with much smaller integers for equivalent security parameters to RSA or DH. For example a 1248-bit RSA key corresponds to an 160-bit ECDSA key, saving both in space required to store parameters and in time spent for calculations.

However elliptic curve technology is considered a patent minefield and quite some attempts have been made to clarify the status, e.g. IETF made an attempt with RFC6090 to describe only the fundamental algorithms on which all patents are known to have expired. The ECC implementation of ECC is based on this document.

One of the interesting "improvements" that is not included in the fundamental algorithms, and is still patented is point compression. To describe it we need a small (but not detailed) introduction to elliptic curves. An elliptic curve (at least for the needs of TLS protocol) is a set of points (x,y) that satisfy the following relation modulo a large prime p.

y² = x³ + ax + b

This set of points has some properties, i.e., a group law allowing point addition, scalar multiplication etc. Without getting into details those points need to be exchanged during a protocol run and given that the points usually belong to a "large" prime field (e.g. 256-bits), and reducing the exchanged bytes is an improvement. Point compression achieves that goal, so let's see how.

Say we have a point (x₀,y₀) satisfying y₀² = x₀³ + ax₀ + b. If x₀ is known, then the previous relation becomes a second degree polynomial, that has two solutions.

y_1,2 = ±√ x³ + ax + b

And surprisingly that's all about point compression. Instead of sending the tuple (x₀,y₀), only x₀ and a bit identifying the sign of y is sent. The receiver only needs to calculate y_1,2 and then select the appropriate using the sign bit. Of course calculating square roots modulo a prime isn't as simple as in our example, but the idea is similar.

So is this worthwhile? Are implementations like GnuTLS that don't infringe this patent in a disadvantage? While it is a clever idea, it doesn't really add much value in real-world protocols. A 256-bit curve has points of around 32 bytes. Thus the bytes saved per TLS handshake are 64 bytes overall. Such handshake typically contains data of several kilobytes, and saving few bytes isn't going to make a dramatic difference. It wouldn't be a top priority addition even if it wasn't a patented method.

Self-modifying code using GCC

2011-12-15T15:02:00.002+01:00

One of my research topics last year was self-modifying code mainly for obfuscation. Having seen how self-modification is implemented for a variety of programs, I could say that most existing techniques implement the self-modification in assembly, or in the most high level case, in C using inline assembly.

I'm not a good assembly programmer so I always try to move things to "high-level" C. Unfortunately I haven't managed to implement self modification with standard C, but can be done by using an interesting GCC extension. That is the label to pointer or '&&' extension. This provides the address of a C label as a pointer. Using that we can implement self modification without the use of assembler. The idea is demonstrated in the code snippet below.

One of its problems is that if the labels are not used in the code they are removed by the GCC optimizer (even with -O0) and the address to pointer just returns a dummy value. For that the labels have to be used in dummy code. The better the optimizer in GCC becomes the harder the work around. In this test we use the value of argc (any other external value would do) to ensure the labels stay put.

The code was inspired by a self-modifying code example using inline assembly, but unfortunately I can no longer find it in order to provide proper references.

/* 
 * A self-modifying code snippet that uses C
 * and the GCC label to pointer (&&) extension.
 */

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <stdint.h>

int main(int argc, char **argv)
{
 int (*my_printf) (const char *format, ...);
 void (*my_exit) (int);
 void *page =
     (void *) ((unsigned long) (&&checkpoint) &
        ~(getpagesize() - 1));

 /* mark the code section we are going to overwrite
  * as writable.
  */
 mprotect(page, getpagesize(), PROT_READ | PROT_WRITE | PROT_EXEC);

 /* Use the labels to avoid having GCC
  * optimize them out */
 switch (argc) {
   case 33:
     goto checkpoint;
   case 44:
     goto newcode;
   case 55:
     goto newcode_end;
   default:
     break;
 }

 /* Replace code in checkpoint with code from
  * newcode.
  */
 memcpy(&&checkpoint, &&newcode, &&newcode_end - &&newcode);

checkpoint:
 printf("Good morning!\n");
 return 1;

newcode:
 my_printf = &printf;
 (*(my_printf)) ("Good evening\n");

 my_exit = &exit;
 (*(my_exit)) (0);

newcode_end:
 return 2;
}

Dedicated to the anonymous referee who insisted into adding this example to our article.

Generating Diffie-Hellman parameters

2011-12-12T18:30:00.000+01:00

Starting with gnutls 3.0 the Diffie-Hellman parameter generation has been changed. That was mandated by the move from libgcrypt to nettle. Nettle didn't support Diffie-Hellman parameter generation, so I had to implement it within gnutls. For that I generate a prime of the form p=2wq+1, where w and q are also primes and q has the size in bits of the security parameter (could be 160,256 etc. bits, based on the size of p). Then I search for a generator of the q subgroup using an algorithm which typically gives a large generator --few bits less than the size of p.

This method has the advantage that a server when selecting a private key value x, instead of selecting 0 < x < p-1, it can select a smaller x within the multiplicative subgroup of order q, i.e., 0 < x < q-1. The security level of x is that of the security parameter, which in gnutls is calculated as in ECRYPT recommendations. However until now we never wrote the size of the security parameter in the Diffie-Hellman parameters file, so it was impossible for the server to guess the order of q, since the PKCS #3 file only contained the generator and the prime. However PKCS #3 has a privateValueLength field exactly for this purpose, but it is not used by gnutls or any other implementation I'm aware of.

DHParameter ::= SEQUENCE {
  prime INTEGER, -- p
  base INTEGER, -- g
  privateValueLength INTEGER OPTIONAL 
}

By populating and using it, the performance improvement was quite impressive. The following table demonstrates that.

Prime length	Private key length	Transactions/sec with DHE-RSA
1248	1248	122.75
1248	160	189.91

So starting from 3.0.9 gnutls' generated parameters for Diffie-Hellman should perform better. However one question that I had to answer, is what is more important, keeping x small as we do, or having a small generator? Libgcrypt and openssl generate parameters in a way that the generator is kept small, e.g. g=5 or g=2. For that I generated 1248 bit parameters using openssl which happened to have g=2.

Prime length	Generator length	Private key length	Transactions/sec with DHE-RSA
1248	1246 bits	1248	122.75
1248	1246 bits	160	189.91
1248	2 bits	1248	125.94

So it seems keeping the generator small doesn't really have an impact to performance comparing to using a smaller but still secure subgroup.

The price to pay for perfect-forward secrecy

2011-12-08T17:26:00.012+01:00

[EDIT: Tests updated with the smaller SECP192R1 curve, to make results more applicable to todays' used security levels]

Ok, the question seems to be what is perfect forward secrecy? Perfect forward secrecy is a property of a cryptographic protocol, such as SSL (or better TLS). That property ensures that once the cryptographic keys of a participant are leaked the secrecy of past sessions remains. For example if amazon.com private key is leaked your previous transactions with this site remain secure (that would actually be if amazon wouldn't store the sensitive data). So does TLS have this property? That is a yes and a no.

TLS provides the option to use ciphersuites offering perfect forward secrecy (PFS). Those are the ciphersuites that include ephemeral Diffie-Hellman and elliptic curve Diffie-Hellman authentication. However those come at a cost very few web sites are willing to pay for. They involve expensive calculations that put some burden on the server and delay the transaction for few milliseconds. Why would a server bother to protect your data anyway? And this seems to be the current attitude. Most servers totally prohibit the usage of ciphersuites that offer PFS. Try for example to connect to amazon.com using:

$ ./gnutls-cli www.amazon.com --priority NORMAL:-KX-ALL:+DHE-RSA:+ECDHE-RSA
Resolving 'www.amazon.com'...
Connecting to '72.21.214.128:443'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed
*** Handshake has failed

So let's try to evaluate the cost of PFS versus the plain RSA ciphersuites that do not offer PFS, using a simple approach initially. For that we use Diffie-Hellman group parameters of 1024 bits, a 192-bit elliptic curve and a 1024-bit RSA key and a modified gnutls-cli for its benchmark-tls option.

Key exchange	Parameters	Transactions/sec
DHE_RSA	1024-bit RSA key, 1024-bit DH parameters	18.26
ECDHE_RSA	1024-bit RSA key, 192-bit ECDH parameters	57.6
ECDHE_ECDSA	192-bit ECDSA key, 192-bit ECDH parameters	40.8
RSA	1024-bit RSA key	167.27

In this test the ciphersuites DHE_RSA, ECDHE_RSA and ECDHE_ECDSA provide perfect forward secrecy, and use a signed ephemeral (Diffie-Hellman) key exchange. The signature can be RSA or ECDSA, determined by the ciphersuite and the certificate. The plain RSA doesn't offer PFS and utilizes RSA's encryption capability (instead of signing). We can see that the non-PFS ciphersuite is a clear winner with a 3x or 4x factor. The Elliptic curve equivalents of DHE are faster but not dramatically better.

However our security levels are not consistent. An elliptic curve of 192-bits provides 80-bits of security, according to RFC5480, or around 96 according to ECRYPT. Let's assume it is 80, meaning it is equivalent to 1248-bits RSA and DH parameters. So let's do the same experiment with consistent parameters.

Key exchange	Parameters	Transactions/sec
DHE_RSA	1248-bit RSA key, 1248-bit DH parameters	10.71
ECDHE_RSA	1248-bit RSA key, 192-bit ECDH parameters	49.18
ECDHE_ECDSA	192-bit ECDSA key, 192-bit ECDH parameters	40.22
RSA	1248-bit RSA key	113.91

So it seems that increasing the security level to 80-bits degrades performance (don't confuse the bits of an algorithm such as RSA with the bits of the security level, a security level of 80-bits is a medium level of security for today's standards). The Diffie-Hellman key exchange is very slow over a 1248-bit group, and it also includes an RSA signature of 1248-bits. The Elliptic curve equivalent (ECDHE_RSA) is much more efficient, even though it also includes a 1248-bit RSA signature. The clear winner again in performance is plain RSA, but with a factor of around 2x from the second.

It is also worth noting that using an 192-bit ECDSA key does not outperform an 1248-bit RSA key which is of the same security level, if we believe RFC5480.

So although I'd suggest ciphersuites offering PFS for almost everything, they degrade performance, and this should not be underestimated. When it is desired to have PFS, then its shortcomings have to be evaluated against the benefits. For a web server, if the private key in a server is not stored in any kind of a security module then it is likely that at some point someone will get access to it. Protecting the private key with PIN or passwords might be futile as the key will reside unencrypted in the web server's memory. For that reason, if the security of the data exchanged in past transactions must be protected, then only PFS ciphersuites have to be allowed. In other cases, using the RSA ciphersuite might suit better.

Enhancing privacy in comments

2011-11-24T14:39:00.001+01:00

FHEO or "For human eyes only" is a Firefox browser plugin with the goal of enhancing privacy in comments made in social networks or forums. The idea is to counter privacy issues seen mainly in social networks, by using (distorted) images instead of plain text. The two issues it mainly defends against:

Expiration of comments;
Prevention of comments being indexed by web crawlers.

Most social networks do not allow deleting old posts or comments, and if they do it is not an automatic process. Moreover those comments can be easily gathered by a crawler such as google and be used to associate persons based on written comments, political ideas etc.

This is something my colleague Andreas Pashalidis didn't like and proposed a master thesis on a firefox plugin that would counter those issues. This thesis was completed by Xavi Ferrer and Beñat Bermejo under our supervision and resulted to a firefox plugin prototype. Later the plugin and distortions have been enhanced by Andreas (and to a tiny degree me), and now a fully functional plugin is available under the Apache License 2.0.

We'd appreciate your comments and ideas.

2011-09-27T11:27:00.001+02:00

Ovrimos was a greek company making an RDBMS. They tried to compete with giants like Oracle and microsoft SQL, but failed. Having the guts to try was enough for me. They are part of history right now and I'm pretty proud I was a tiny part of it. The history of the company is nicely described by one of the lead engineers at that time.

The problem of cryptographic algorithms & cryptographic accelerators

2011-09-07T15:49:00.000+02:00

There are many ways one could use cryptography in GNU/Linux. There are cryptographic libraries such as the Java crypto API, Botan, OpenSSL, GnuTLS and nettle, that provide access to crypto algorithms. The Linux kernel has also its own cryptographic API to be accessed by the in-kernel IPSec implementation. They all offer a variety of algorithms and each one has its pros and cons. Some implementations might be faster, some slower but such variation is expected.

New generation CPUs contain instruction sets for cryptographic operations, such are VIA's PADLOCK and Intel's AES-NI. Other embedded systems provide a cryptographic accelerator allowing offloading of cryptography. An interesting question is how do the above cryptographic libraries take advantage of the above optimizations?

Cryptographic operations based on the PADLOCK or AES-NI instruction sets require libraries to re-write their AES (for example) implementation using the above instruction sets. They both have special requirements for data and key alignment requiring special care on implementation. Moreover since those instruction sets are not available in all CPUs of the same family, run-time CPU detection has to occur which will enable the optimized versions.

The cryptographic accelerators case is more complicated. Cryptographic libraries cannot access the accelerators without a driver. Until recently there was no generic driver to access them in the Linux kernel. Today we have two. The AF_ALG interface, which is included in the Linux kernel since 2.6.38 and the cryptodev-linux interface which is an interface compatible with OpenBSD's /dev/crypto. Both allow access to the hardware accelerated algorithms included in the Linux kernel. Moreover, in CPUs having the PADLOCK or AES-NI instruction set the Linux kernel includes and uses optimized versions of the crypto algorithms. This allows the kernel interface to be used as a generic interface to access cryptographic accelerators and optimized instruction sets.

However, performance-wise this is not optimal. The kernel interface requires switches from user-space to kernel-space which has a significant performance cost. Thus the usage of the kernel services should be avoided when possible (i.e., in the AES-NI and padlock instruction sets).

So there is no universal interface to take advantage of hardware-accelerated cryptography. But is there one needed? Why have a universal interface to access hardware acceleration when there isn't any to access cryptography?

I believe a universal interface to access hardware accelerated cryptography is needed because not having it involves a massive duplication of work, that is architecture and system specific. Such an interface would allow the crypto libraries to stay architecture or system agnostic and focus on the bigger picture rather than coping with architecture quirks, hardware bug work-arounds etc. Moreover, cryptographic libraries compete on the interface, protocols etc. Libraries competing on hardware support although typical for the 80's and 90's shouldn't be the case in a modern operating system.

How can this be solved? I believe a system-wide library to access accelerated crypto would be the ideal. One that would use the kernel provided cryptography in case of a hardware accelerator, or the relevant CPU-specific instructions if detected. Each cryptographic library could then use it, to provide accelerated cryptography transparently to all applications.

GnuTLS 3.0.0

2011-07-29T23:05:00.000+02:00

GnuTLS 3.0.0 is finally out! The original announcement can be found at the mailing list. The main and most important changes since 2.12.x are:

Support for Datagram TLS 1.0
Support for Elliptic Curves (ECDHE and ECDSA)
Support for AES-GCM
Optimizations for Intel CPUs with the AES instruction set
PKCS #11 support via p11-kit

We also now depend solely on libnettle as a cryptographic back-end. As for documentation we now have in addition to electronic formats a paper copy of the manual available via lulu.com.

Is copyright right?

2011-05-26T12:28:00.002+02:00

For the ones not familiar with copyright, I'll make a short introduction. For a longer description check the wikipedia article. Copyright is a tool invented to foster innovation. It provides the author of literal or artistic work with a monopoly on copying the work. That monopoly can be understood because it is not an easy job to create literal or art works, and authors could use this monopoly to generate income. Today copyright has been extended to provide a monopoly for 70 years.

I am myself a copyright owner of several works of mine, one prominent being the software GnuTLS, a computer security software (or library to be precise). The copyright will remain on me and my descendants for my lifetime and my descendants will hold copyright to the software for 70 years afterwards. So if I could chose, so no-one could profit from that software for more than 100-120 years (if I can last that long). Why has the society granted me the power to deprive her from my work for so long? Moreover I have chosen to distribute my software under the GNU lesser general public license. I like this license because it promotes sharing, but many people do not think so. A big software company's CEO has even argued that this software license is a cancer. He might be right or wrong. If he is right then society has granted me the power to distribute my work only under a cancer-like license for 100 years or so. If I am right then maybe the society could benefit from my software.

But I might always be wrong, not matter what I believe. Why would the society trust authors of work to restrict them for a ridiculus amount of time, after which the works are hardly useful for anything than display on a museum? Now people in France and the World in general are looking for ways to enforce copyright in the digital world. But did we ever answered the question whether copyright as it is today makes sense in the digital era?.

Shouldn't we first balance the cost to the society versus the profits? Is 70 years after the author's death a reasonable time? Is no copyright a reasonable choice? These are the two extremes. I think today we are on the one extreme we should move somewhere closer to a balanced decision.

PS. I wrote that after watching the views of Perry Barlow in e-G8.

PS2. For the pendantics, I have chosen not to keep the copyright of my work in GnuTLS but rather transfer it to Free Software Foundation. This does not alter my arguments in any way as they apply to FSF as well.

using the Belgian ID cards with GnuTLS

2011-05-16T22:59:00.002+02:00

Belgium is among the few countries that provide citizens with a smart-card containing RSA private keys and certificates signed by a national authority. Those keys can be used by GnuTLS as well, so let's explore the possibilities.

Initially you need a smart-card reader, I suppose any supported by opensc would do. I got one from gooze.eu, that also provided me with some smart-cards for free for the development of GnuTLS. Anyway after you have a smart-card reader make sure opensc is installed and is operating. For example in my system I see my reader as:

$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             OmniKey CardMan 3121 00 00

Also make sure that /etc/gnutls/pkcs11.conf contains the line

load=/usr/lib/opensc-pkcs11.so

which instructs GnuTLS to load the opensc PKCS #11 library. If you are wondering what PKCS #11 is, think of it as a common interface to talk to smart-cards. From now on, only GnuTLS (2.12) tools are required.

Initially let's verify the card is present. That would be with the command:

$ ./p11tool --list-tokens
Token 0:
        URL: pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=XXX;model=PKCS%2315;manufacturer=%28unknown%29;library-manufacturer=OpenSC%20%28www%2Eopensc%2Dproject%2Eorg%29;library-description=Smart%20card%20PKCS%2311%20API
        Label: BELPIC (Basic PIN)
        Manufacturer: (unknown)
        Model: PKCS#15
        Serial: XXX

Nice. We see that the card is present. Note that URL on top of the listing. GnuTLS uses PKCS #11 URLs to identify all objects within a token. They might be a bit intimidating because of their size, but they can uniquely and permanently identify an object. But let's now see what's stored inside:

$ ./p11tool --list-all --login
PIN required for token 'BELPIC (Basic PIN)' with URL 'pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=XXX;model=PKCS%2315;manufacturer=%28unknown%29'
Enter PIN: 
Object 0:
        URL: pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=XXX;model=PKCS%2315;manufacturer=%28unknown%29;object=Authentication;objecttype=private;library-manufacturer=OpenSC%20%28www%2Eopensc%2Dproject%2Eorg%29;library-description=Smart%20card%20PKCS%2311%20API;id=%02
        Type: Private key
        Label: Authentication
        ID: 02

Object 1:
        URL: pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=XXX;model=PKCS%2315;manufacturer=%28unknown%29;object=Authentication;objecttype=cert;library-manufacturer=OpenSC%20%28www%2Eopensc%2Dproject%2Eorg%29;library-description=Smart%20card%20PKCS%2311%20API;id=%02
        Type: X.509 Certificate
        Label: Authentication
        ID: 02

Object 2:
        URL: pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=XXX;model=PKCS%2315;manufacturer=%28unknown%29;object=Authentication;objecttype=public;library-manufacturer=OpenSC%20%28www%2Eopensc%2Dproject%2Eorg%29;library-description=Smart%20card%20PKCS%2311%20API;id=%02
        Type: Public key
        Label: Authentication
        ID: 02


[...]

Object 9:
        URL: pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=93FF298DB713225;model=PKCS%2315;manufacturer=%28unknown%29;object=Root;objecttype=public;library-manufacturer=OpenSC%20%28www%2Eopensc%2Dproject%2Eorg%29;library-description=Smart%20card%20PKCS%2311%20API;id=%06
        Type: Public key
        Label: Root
        ID: 06

That's quite some stuff there. As it seems there are a private-public key pair with a certificate to be used for authentication, another pair for signing and few national certificate authorities and their public keys. We can try to export one of the authorities as:

$ ./p11tool --login --export "pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=XXX;model=PKCS%2315;manufacturer=%28unknown%29;object=Root;objecttype=cert;library-manufacturer=OpenSC%20%28www%2Eopensc%2Dproject%2Eorg%29;library-description=Smart%20card%20PKCS%2311%20API;id=%06"|certtool -i
Enter PIN: 
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 2affbe9fa2f0e987
        Issuer: C=BE,CN=Belgium Root CA2
        Validity:
                Not Before: Thu Oct 04 10:00:00 UTC 2007
                Not After: Wed Dec 15 08:00:00 UTC 2021
        Subject: C=BE,CN=Belgium Root CA2
        Subject Public Key Algorithm: RSA
                Modulus (bits 2048):
                        c6:73:42:1e:92:ff:75:0f:8b:bf:74:86:a7:3f:ed:b2
                        18:2d:2d:97:f9:a9:fb:98:4a:23:df:d5:8d:e0:8c:c6
                        32:1c:16:2d:07:42:d6:2d:b6:6e:2f:a7:f5:fc:c6:85
                        82:5d:95:de:b5:22:00:cc:a8:53:40:9f:af:0a:35:a2
                        7a:c7:e1:ca:f7:60:10:67:0e:a7:50:73:17:53:95:9f
                        22:9f:0c:5d:6f:b6:41:bc:8c:eb:da:1d:46:bd:a7:94
                        bf:f3:1a:cb:d4:fb:8d:0e:1e:33:c8:96:d7:ec:8c:53
                        de:93:1e:34:1e:8a:50:71:26:58:b4:5d:c2:88:89:da
                        60:d2:89:21:3f:de:d7:01:18:36:6e:e1:2c:70:03:04
                        65:ef:98:06:2b:5d:1e:62:dc:55:6b:fe:66:64:21:5f
                        f8:2f:e1:d7:9b:29:af:6f:cd:9f:aa:0c:46:d1:88:c5
                        9d:a2:95:9f:ac:3f:15:ae:f2:61:df:ef:c3:6b:9a:22
                        d8:2c:71:fd:58:1d:ec:00:a4:38:20:95:5a:c7:d5:37
                        63:ba:4f:9b:aa:fe:56:46:2e:63:d9:0b:23:d5:8a:fa
                        b5:23:f0:89:1b:a1:14:0d:26:da:41:f0:38:8f:30:ed
                        05:26:79:c1:4b:4e:a1:b8:7e:55:52:3a:69:46:84:75
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Key Usage (critical):
                        Certificate signing.
                        CRL signing.
                Basic Constraints (critical):
                        Certificate Authority (CA): TRUE
                Unknown extension 2.5.29.32 (not critical):
                        ASCII: 0907..`8...0.0,..+........ http://repository.eid.belgium.be
                        Hexdump: 3039303706056038090101302e302c06082b060105050702011620687474703a2f2f7265706f7369746f72792e6569642e62656c6769756d2e6265
                Subject Key Identifier (not critical):
                        858aebf4c5bbbe0e590394ded6800115e3109c39
                Unknown extension 2.16.840.1.113730.1.1 (not critical):
                        ASCII: ....
                        Hexdump: 03020007
                Authority Key Identifier (not critical):
                        858aebf4c5bbbe0e590394ded6800115e3109c39
        Signature Algorithm: RSA-SHA
        Signature:
                51:d8:85:dd:bb:57:6f:cc:a0:6c:b5:a3:20:9c:53:09
                f3:4a:01:0c:74:bf:2b:b3:9a:9a:ba:18:f2:0b:88:ac
                1c:b3:33:af:ce:e5:13:01:27:92:84:58:9a:10:b9:f7
                cc:14:92:6b:74:16:8a:96:e8:51:ef:bf:fa:4a:25:a7
                89:b6:63:2b:5d:94:58:d1:cf:11:72:b6:1e:b9:39:41
                16:4d:29:bc:35:53:0b:da:de:8e:0e:cd:a9:95:77:25
                ca:94:5a:e9:b2:69:ae:d8:c0:13:be:98:fc:96:9c:84
                7f:55:13:e6:3c:87:e3:bc:20:a4:a4:36:68:6b:4d:60
                66:1c:f9:bf:ac:80:94:66:2e:b9:41:8a:d3:65:d3:84
                80:02:ef:50:1d:5e:46:dc:f7:c9:ba:b5:34:7c:2a:f3
                c6:d8:5f:5f:54:9d:db:4d:cd:11:e7:fd:14:02:83:66
                5e:c8:a6:00:12:a0:5f:be:ce:14:fe:bb:1f:a7:61:f7
                ab:4a:f1:06:14:9f:ca:49:42:c2:a9:bc:ed:85:b1:ab
                81:41:e6:0d:c5:42:69:53:87:39:9d:4c:1f:00:0e:3e
                07:0d:75:57:44:a8:53:b4:36:76:64:99:dc:6e:eb:3d
                46:6e:14:5d:5e:47:53:8d:78:4d:e0:27:bb:8e:85:76
Other Information:
        MD5 fingerprint:
                e9ac47cc78b6cf02505ee2481bec95dc
        SHA-1 fingerprint:
                51cca0710af7733d34acdc1945099f435c7fc59f
        Public Key Id:
                b7513777b278676554fc2679b4ff7f6374cef157

-----BEGIN CERTIFICATE-----
MIIDjjCCAnagAwIBAgIIKv++n6Lw6YcwDQYJKoZIhvcNAQEFBQAwKDELMAkGA1UE
BhMCQkUxGTAXBgNVBAMTEEJlbGdpdW0gUm9vdCBDQTIwHhcNMDcxMDA0MTAwMDAw
WhcNMjExMjE1MDgwMDAwWjAoMQswCQYDVQQGEwJCRTEZMBcGA1UEAxMQQmVsZ2l1
bSBSb290IENBMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZzQh6S
/3UPi790hqc/7bIYLS2X+an7mEoj39WN4IzGMhwWLQdC1i22bi+n9fzGhYJdld61
IgDMqFNAn68KNaJ6x+HK92AQZw6nUHMXU5WfIp8MXW+2QbyM69odRr2nlL/zGsvU
+40OHjPIltfsjFPekx40HopQcSZYtF3CiInaYNKJIT/e1wEYNm7hLHADBGXvmAYr
XR5i3FVr/mZkIV/4L+HXmymvb82fqgxG0YjFnaKVn6w/Fa7yYd/vw2uaItgscf1Y
HewApDgglVrH1Tdjuk+bqv5WRi5j2Qsj1Yr6tSPwiRuhFA0m2kHwOI8w7QUmecFL
TqG4flVSOmlGhHUCAwEAAaOBuzCBuDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zBCBgNVHSAEOzA5MDcGBWA4CQEBMC4wLAYIKwYBBQUHAgEWIGh0dHA6
Ly9yZXBvc2l0b3J5LmVpZC5iZWxnaXVtLmJlMB0GA1UdDgQWBBSFiuv0xbu+DlkD
lN7WgAEV4xCcOTARBglghkgBhvhCAQEEBAMCAAcwHwYDVR0jBBgwFoAUhYrr9MW7
vg5ZA5Te1oABFeMQnDkwDQYJKoZIhvcNAQEFBQADggEBAFHYhd27V2/MoGy1oyCc
UwnzSgEMdL8rs5qauhjyC4isHLMzr87lEwEnkoRYmhC598wUkmt0FoqW6FHvv/pK
JaeJtmMrXZRY0c8RcrYeuTlBFk0pvDVTC9rejg7NqZV3JcqUWumyaa7YwBO+mPyW
nIR/VRPmPIfjvCCkpDZoa01gZhz5v6yAlGYuuUGK02XThIAC71AdXkbc98m6tTR8
KvPG2F9fVJ3bTc0R5/0UAoNmXsimABKgX77OFP67H6dh96tK8QYUn8pJQsKpvO2F
sauBQeYNxUJpU4c5nUwfAA4+Bw11V0SoU7Q2dmSZ3G7rPUZuFF1eR1ONeE3gJ7uO
hXY=
-----END CERTIFICATE-----

Ok let's now connect to a site using gnutls-cli. We use the authentication key and certificate we listed before.

$ ./gnutls-cli test.gnutls.org -p 5556 --x509certfile "pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=XXX;model=PKCS%2315;manufacturer=%28unknown%29;object=Authentication;objecttype=cert;library-manufacturer=OpenSC%20%28www%2Eopensc%2Dproject%2Eorg%29;library-description=Smart%20card%20PKCS%2311%20API;id=%02" --x509keyfile "pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=XXX;model=PKCS%2315;manufacturer=%28unknown%29;object=Authentication;objecttype=private;library-manufacturer=OpenSC%20%28www%2Eopensc%2Dproject%2Eorg%29;library-description=Smart%20card%20PKCS%2311%20API;id=%02"

PIN required for token 'BELPIC (Basic PIN)' with URL 'pkcs11:token=BELPIC%20%28Basic%20PIN%29;serial=XXX;model=PKCS%2315;manufacturer=%28unknown%29'
Enter pin:
Processed 1 client X.509 certificates...
Resolving 'test.gnutls.org'...
Connecting to '207.192.75.61:5556'...
- Successfully sent 1 certificate(s) to server.
- Ephemeral Diffie-Hellman parameters
- Using prime: 1024 bits
- Secret key: 1020 bits
- Peer's public key: 1023 bits
- Server has requested a certificate.
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
- subject `O=GnuTLS test server,CN=test.gnutls.org', issuer `CN=GnuTLS test CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2007-04-18 13:29:21 UTC', expires `2008-04-17 13:29:21 UTC', SHA-1 fingerprint `9838d56df8d651c70aea6202bb2e8322f527b2cb'
- The hostname in the certificate matches 'test.gnutls.org'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.1
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

GET / HTTP/1.0
...

The output of the GET command will show us the certificate used for the connection. That was all and I hope it was simple enough.

is really gnutls considered harmful?

2011-05-10T09:38:00.002+02:00

A comment made few years ago by Howard Chu, the developer of openldap, seems to be being repeated by people, ignorant of the issue, as an argument against GnuTLS. It is the sad truth however that this comment is and was wrong back then. I had commented back then stating the facts and why I thought Howard came up to that conclusion.

So what is the issue? Howard claims that GnuTLS makes liberal use of strcpy(), strcat() and strlen(). Those functions are known to be responsible for several attacks via buffer overflows in current programs. In GnuTLS however we had few vulnerabilities (discussed in our security advisories page) but none of them was a buffer overflow. Why is that? Because we don't use strcpy() and strcat() liberally. We don't use them with data originated from the network or the user or without checking boundaries. GnuTLS includes a custom string library, the gnutls_buffer_st interface in gnutls_str, which is used in most of the cases.

So why was Howard concerned about our liberal use of strcpy() and strcat()? We do use those functions, but for static string copying and for strings originating within the library. E.g. our ASN.1 library requires to identify objects a string of the form "PKIX1.CRLDistributionPoints.?1.distributionPoint.fullName" or "PKIX1.CRLDistributionPoints.?5.distributionPoint.fullName". Thus in several occasions we do something like

char str[256];

gnutls_str_cpy(str, sizeof(str), "PKIX1.CRLDistributionPoints.");
gnutls_str_cat(str, sizeof(str), "?1.distributionPoint.fullName");

Our version of strcpy() and strcat() provide a safer wrapper function over the libc function, that will never overflow the destination string. Other cases include strings that are locally generated and controlled. Thus seeing strcpy() or strcat() in a program does not mean that it is vulnerable to buffer overflow attacks. Two things are also required, user or network input to be involved and bound checking not to be done. As far as we know neither is or was true for GnuTLS.

Of course noone is claiming that GnuTLS is perfect and bug-free. No software is bug-free and don't believe anyone claiming it. My claim is that the specific critique is invalid.