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.
Thursday, May 26, 2011
Monday, May 16, 2011
using the Belgian ID cards with GnuTLS
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.
Also make sure that /etc/gnutls/pkcs11.conf contains the line
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.
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.
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.
Tuesday, May 10, 2011
is really gnutls considered harmful?
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
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.
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.
Subscribe to:
Posts (Atom)