From simon at josefsson.org  Thu Jul  1 16:26:35 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 01 Jul 2010 16:26:35 +0200
Subject: Build GnuTLS under VS2010
In-Reply-To: <001101cb160e$9bb896b0$d329c410$@cz> (Big Muscle's message of
	"Sun, 27 Jun 2010 17:37:07 +0200")
References: <001101cb160e$9bb896b0$d329c410$@cz>
Message-ID: <87fx03jn1g.fsf@mocca.josefsson.org>

"Big Muscle" <bigmuscle at centrum.cz> writes:

> Hello,
>
> I would like to ask you whether there is some guide how to compile GnuTLS
> under Visual Studio 2010. I know there is already precompiled binary for
> Windows, but it's not sufficient for our project. We need static library
> (and not DLL) and we also need x64 binary - that's why we need to compile it
> ourselves.
>
> Could you provide us some help? Thank you!

Hi.  I'm not aware of any guides on this.  I think some people have
developed their own VS project files for GnuTLS, but I don't recall any
published ones...  if someone wants to publish a guide on this, it would
be great.

> (I already tried mailing to 'help-gnutls at gnu.org', but I received "You are
> not allowed to post to this mailing list")

The list should be moderated, not sure why that happened.

/Simon



From nmav at gnutls.org  Thu Jul  1 17:22:25 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 01 Jul 2010 17:22:25 +0200
Subject: deallocation in gnutls_*_deinit?
In-Reply-To: <4C2B6270.90709@kiilerich.com>
References: <4C2A8371.7080202@kiilerich.com> <4C2B5663.4070407@gnutls.org>
	<4C2B6270.90709@kiilerich.com>
Message-ID: <4C2CB2B1.9060106@gnutls.org>

Mads Kiilerich wrote:

> What do you recommend: Should I implement a workaround for 2.10.0 (and
> how?) or should I require 2.10.1? Is there a planned/estimated data of a
> release?

The best would be to apply the patch for now. A bugfix release will be
made soon.


regards,
Nikos



From trapni at gentoo.org  Sun Jul  4 19:14:28 2010
From: trapni at gentoo.org (Christian Parpart)
Date: Sun, 4 Jul 2010 19:14:28 +0200
Subject: my gnutls server's handshake results into -32 (insufficient creds 
 for that request)
Message-ID: <2901d64f4ae009753a47d8c18ea762f7.squirrel@mail.trapni.de>

Hey all,

I am about to implement an SSL plugin for my little HTTP server, which
once worked pretty fine, but basic, now I am about to introduce SNI and
all that have to be non-blocking I/O, which made it pretty complicated to
design/implement this feature the generic way.
However, I am now receiving a -32 (GNUTLS_E_INSUFFICIENT_CREDENTIALS),
when calling gnutls_handshake() and I have absolutely no clue what I might
have forgotten to set or register.

As the code is unfortunately not just a 3-liner, I'll provide the debug
output right below:

FYI: I am using the self-signed default certificates for the apache
installation here,
but that shouldn't be the problem. Although, You might encounter the
following names:
- SslDriver: - the GnuTLS I/O driver object, that creates the (ssl) socket
objects
- SslContext: - object that holds the SSL configuration for a specific
(host-)context,
                e.g. x509 cert and key (also in form of gnutls handles)
- SslSocket: - the GnuTLS socket object, that provides my app with
convenient read/write ops and does the handshake stuff, too.
- HttpConnection: the HTTP-connection object

So here we go, with the log:

1278262947.334951: SslContext: SslContext()
1278262947.334951: SslContext: SslContext::setCertFile:
"/etc/ssl/apache2/server.crt"
1278262947.334951: ssl: [2] ASSERT: dn.c:451
1278262947.334951: SslContext: setCertFile: Common Name: "localhost"
1278262947.334951: SslContext: SslContext::setKeyFile:
"/etc/ssl/apache2/server.key"
1278262947.334951: ssl: setupLogLevel(cvar, scope)
1278262947.334951: ssl: setLogLevel: 6
[07/04/2010:19:02:27 +0200] [debug] Enable SSL on host: localhost:8088
1278262947.334951: SslContext: SslContext::setDriver()
1278262947.334951: SslContext: setPriorities: "NORMAL"
[07/04/2010:19:02:27 +0200] [info] Start listening on [0::0]:8089
[07/04/2010:19:02:27 +0200] [info] Start listening on [0::0]:8088 [secure]
[07/04/2010:19:02:27 +0200] [info] Created PID file with value 5631
[/opt/sandbox/var/run/x0d.pid]
1278262950.682260: SslSocket: SslSocket()
1278262950.682260: HttpConnection: HttpConnection(0x1c326c0): fd=12
1278262950.682260: SslSocket: handshake()
1278262950.682260: ssl: [4] REC[0x1c46f00]: Expected Packet[0]
Handshake(22) with length: 1
1278262950.682260: ssl: [4] REC[0x1c46f00]: Received Packet[0]
Handshake(22) with length: 132
1278262950.682260: ssl: [4] REC[0x1c46f00]: Decrypted Packet[0]
Handshake(22) with length: 132
1278262950.682260: ssl: [6] BUF[HSK]: Inserted 132 bytes of Data(22)
1278262950.682260: ssl: [6] BUF[REC][HD]: Read 1 bytes of Data(22)
1278262950.682260: ssl: [6] BUF[REC][HD]: Read 3 bytes of Data(22)
1278262950.682260: ssl: [3] HSK[0x1c46f00]: CLIENT HELLO was received [132
bytes]
1278262950.682260: ssl: [6] BUF[REC][HD]: Read 128 bytes of Data(22)
1278262950.682260: ssl: [6] BUF[HSK]: Inserted 4 bytes of Data
1278262950.682260: ssl: [6] BUF[HSK]: Inserted 128 bytes of Data
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Client's version: 3.3
1278262950.682260: ssl: [2] ASSERT: gnutls_db.c:326
1278262950.682260: ssl: [2] ASSERT: gnutls_db.c:246
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Found extension 'SERVER_NAME/0'
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Found extension
'SAFE_RENEGOTIATION/65281'
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Found extension
'SIGNATURE_ALGORITHMS/13'
1278262950.682260: SslSocket: onClientHello()
1278262950.682260: SslSocket: onClientHello: SNI Name: "localhost"
1278262950.682260: SslContext: bind()
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Found extension 'SERVER_NAME/0'
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Found extension
'SAFE_RENEGOTIATION/65281'
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Found extension
'SIGNATURE_ALGORITHMS/13'
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Found extension 'SERVER_NAME/0'
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Found extension
'SAFE_RENEGOTIATION/65281'
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Found extension
'SIGNATURE_ALGORITHMS/13'
1278262950.682260: SslContext: onRetrieveCert()
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
PSK_SHA_ARCFOUR_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
PSK_SHA_3DES_EDE_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
PSK_SHA_AES_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
PSK_SHA_AES_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_PSK_SHA_ARCFOUR_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_PSK_SHA_3DES_EDE_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_PSK_SHA_AES_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_PSK_SHA_AES_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
SRP_SHA_3DES_EDE_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
SRP_SHA_AES_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
SRP_SHA_AES_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
SRP_SHA_DSS_3DES_EDE_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
SRP_SHA_RSA_3DES_EDE_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
SRP_SHA_DSS_AES_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
SRP_SHA_RSA_AES_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
SRP_SHA_DSS_AES_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
SRP_SHA_RSA_AES_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_DSS_ARCFOUR_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_DSS_3DES_EDE_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_DSS_AES_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_DSS_AES_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_DSS_CAMELLIA_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_DSS_CAMELLIA_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_DSS_AES_128_CBC_SHA256
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Removing ciphersuite:
DHE_DSS_AES_256_CBC_SHA256
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
DHE_RSA_3DES_EDE_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
DHE_RSA_AES_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
DHE_RSA_AES_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
DHE_RSA_CAMELLIA_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
DHE_RSA_CAMELLIA_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
DHE_RSA_AES_128_CBC_SHA256
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
DHE_RSA_AES_256_CBC_SHA256
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
RSA_ARCFOUR_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
RSA_ARCFOUR_MD5
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
RSA_3DES_EDE_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
RSA_AES_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
RSA_AES_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
RSA_CAMELLIA_128_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
RSA_CAMELLIA_256_CBC_SHA1
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
RSA_AES_128_CBC_SHA256
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Keeping ciphersuite:
RSA_AES_256_CBC_SHA256
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Selected cipher suite:
DHE_RSA_AES_128_CBC_SHA256
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Selected Compression Method: NULL
1278262950.682260: ssl: [3] HSK[0x1c46f00]: Safe renegotiation succeeded
1278262950.682260: ssl: [2] EXT[0x1c46f00]: Sending extension
SAFE_RENEGOTIATION
1278262950.682260: ssl: [3] HSK[0x1c46f00]: SessionID:
9b6c855caf8abf3778010fcfaff409ffcc1c4e94128a9018bd3f6a3fd1e357d4
1278262950.682260: ssl: [3] HSK[0x1c46f00]: SERVER HELLO was sent [81 bytes]
1278262950.682260: ssl: [6] BUF[HSK]: Peeked 132 bytes of Data
1278262950.682260: ssl: [6] BUF[HSK]: Emptied buffer
1278262950.682260: ssl: [4] REC[0x1c46f00]: Sending Packet[0]
Handshake(22) with length: 81
1278262950.682260: ssl: [4] REC[0x1c46f00]: Sent Packet[1] Handshake(22)
with length: 86
1278262950.682260: ssl: [3] HSK[0x1c46f00]: CERTIFICATE was sent [739 bytes]
1278262950.682260: ssl: [6] BUF[HSK]: Peeked 0 bytes of Data
1278262950.682260: ssl: [6] BUF[HSK]: Emptied buffer
1278262950.682260: ssl: [4] REC[0x1c46f00]: Sending Packet[1]
Handshake(22) with length: 739
1278262950.682260: ssl: [4] REC[0x1c46f00]: Sent Packet[2] Handshake(22)
with length: 744
1278262950.682260: ssl: [2] ASSERT: gnutls_sig.c:223
1278262950.682260: ssl: [2] ASSERT: auth_dhe.c:156
1278262950.682260: ssl: [2] ASSERT: gnutls_kx.c:218
1278262950.682260: ssl: [2] ASSERT: gnutls_handshake.c:3029
1278262950.682260: ssl: [6] BUF[HSK]: Cleared Data from buffer
1278262950.682260: SslSocket: SSL handshake failed (-32): Insufficient
credentials for that request.

This is the backtrace that caused the -32:


#0  _gnutls_tls_sign (session=0x674140, cert=0x627480, pkey=0x0,
hash_concat=0x7fffffffd440, signature=0x7fffffffd4b0) at gnutls_sig.c:297
#1  0x00007ffff634ecac in _gnutls_handshake_sign_data (session=0x674140,
cert=0x627480, pkey=0x0, params=0x7fffffffd4a0, signature=0x7fffffffd4b0,
sign_algo=0x7fffffffd49c) at gnu
tls_sig.c:220
#2  0x00007ffff6350526 in gen_dhe_server_kx (session=0x674140,
data=0x7fffffffd540) at auth_dhe.c:151
#3  0x00007ffff6337682 in _gnutls_send_server_kx_message
(session=0x674140, again=0) at gnutls_kx.c:206
#4  0x00007ffff633325f in _gnutls_handshake_server (session=0x674140) at
gnutls_handshake.c:3027
#5  0x00007ffff63323c3 in gnutls_handshake (session=0x674140) at
gnutls_handshake.c:2703
#6  0x00007ffff7b655c9 in x0::SslSocket::handshake (this=0x6701d0) at
/home/trapni/projects/x0/src/x0/SslSocket.cpp:88
#7  0x00007ffff7b70ea7 in x0::HttpConnection::start (this=0x670000) at
/home/trapni/projects/x0/src/x0/http/HttpConnection.cpp:211
#8  0x00007ffff7b843b3 in x0::HttpListener::callback (this=0x659760,
watcher=..., revents=1) at
/home/trapni/projects/x0/src/x0/http/HttpListener.cpp:163
#9  0x00007ffff7b8470d in ev::base<ev_io,
ev::io>::method_thunk<x0::HttpListener,
&(x0::HttpListener::callback(ev::io&, int))> (loop=0x7ffff6a02360,
w=0x659760, revents=1) at /usr
/include/ev++.h:469
#10 0x00007ffff67f8880 in ev_invoke_pending (loop=0x7ffff6a02360) at
ev.c:1997
#11 0x00007ffff67fd8c2 in ev_loop (loop=0x7ffff6a02360, flags=2) at ev.c:2359
#12 0x00007ffff7b96d14 in x0::HttpServer::run (this=0x7fffffffda38) at
/home/trapni/projects/x0/src/x0/http/HttpServer.cpp:355
#13 0x00000000004108a9 in x0d::_run (this=0x7fffffffd9f0) at
/home/trapni/projects/x0/src/x0d.cpp:317
#14 0x0000000000410574 in x0d::run (this=0x7fffffffd9f0) at
/home/trapni/projects/x0/src/x0d.cpp:214
#15 0x000000000040e12c in main (argc=1, argv=0x7fffffffdf88) at
/home/trapni/projects/x0/src/x0d.cpp:541

Unfortunately, I have absolutely no idea in what I did wrong,
but I hope I spend enough information for you, to help me out a little :)

Best regards,
Christian Parpart.




From trapni at gentoo.org  Sun Jul  4 20:53:58 2010
From: trapni at gentoo.org (Christian Parpart)
Date: Sun, 4 Jul 2010 20:53:58 +0200
Subject: my gnutls server's handshake results into -32 (insufficient 
 creds  for that request)
In-Reply-To: <2901d64f4ae009753a47d8c18ea762f7.squirrel@mail.trapni.de>
References: <2901d64f4ae009753a47d8c18ea762f7.squirrel@mail.trapni.de>
Message-ID: <a57f4ed616aad12d8d6bd48f31deb938.squirrel@mail.trapni.de>

On Sun, July 4, 2010 7:14 pm, Christian Parpart wrote:
[...]
> Unfortunately, I have absolutely no idea in what I did wrong,
> but I hope I spend enough information for you, to help me out a little :)

Huge analytics, very short answer: I did indeed write code for loading the
x509 key file, but the code that actually opened and read the file's
contents did *silently* fail on the server.key, because the open()
returned EPERM.

I should have had a better error management, but talking helps to
enlighten us each time a little more :)

Thanks,
Christian Parpart.




From simon at cliffestones.demon.co.uk  Mon Jul  5 15:30:10 2010
From: simon at cliffestones.demon.co.uk (Simon Brown)
Date: Mon, 05 Jul 2010 14:30:10 +0100
Subject: Intermediate Certificate problem
Message-ID: <87r5jivyxp.wl%simon@cliffestones.demon.co.uk>

Hi,

I use the Wanderlust email client and the Debian packager, Tatsuya has
recently changed to using GNU TLS from OpenSSL. This has caused a
problem for me as an IMAP server I use seems to have a certificate
problem which either didn't exist before or was ignored by OpenSSL.

The instructions to help diagnose the problem given by Tatsuya the
packager are shown below with the output. The server's administrators
claim there is not a problem as Thunderbird on Win32 has no
problem. Thunderbird does not include the Educational certificate in
its root store

I have worked around the problem by adding the intermediate
certificate to my local store. I would none the less be very grateful
for any help in locating the cause of the problem.

Thanks

Simon

gnutls-cli --port 993 --x509cafile /etc/ssl/certs/ca-certificates.crt imap.student.gla.ac.uk
Resolving 'imap.student.gla.ac.uk'...
Connecting to '130.209.14.155:993'...
- Certificate type: X.509
 - Got a certificate list of 2 certificates.
 - Certificate[0] info:
  - subject `C=GB,ST=Scotland,L=Glasgow,O=University of Glasgow,OU=IT Services,CN=imap.gla.ac.uk', issuer `C=BE,O=Cybertrust,OU=Educational CA,CN=Cybertrust Educational CA', RSA key 2048 bits, signed using RSA-SHA, activated `2009-08-12 14:57:14 UTC', expires `2012-08-12 14:57:14 UTC', SHA-1 fingerprint `41655d6147b0ddaa75cfab94a8a80a4f43ab9091'
 - Certificate[1] info:
  - subject `C=BE,O=Cybertrust,OU=Educational CA,CN=Cybertrust Educational CA', issuer `C=US,O=GTE Corporation,OU=GTE CyberTrust Solutions\, Inc.,CN=GTE CyberTrust Global Root', RSA key 2048 bits, signed using RSA-SHA, activated `2006-03-14 20:30:00 UTC', expires `2013-03-14 23:59:00 UTC', SHA-1 fingerprint `60983654d7ec611d76c2cd5557ca47ad3930c9ca'
- The hostname in the certificate matches 'imap.student.gla.ac.uk'.
- Peer's certificate issuer is not a CA
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
*** Verifying server certificate failed...



From trapni at gentoo.org  Tue Jul  6 10:58:09 2010
From: trapni at gentoo.org (Christian Parpart)
Date: Tue, 6 Jul 2010 10:58:09 +0200
Subject: understanding the SSL I/O model
Message-ID: <b772611851504bba66dae1913717805c.squirrel@mail.trapni.de>

Hey all,

I've got a question I could not actually google for it.
Somebody recently told me, that an SSL write or read operation may also
result in not just a write for write, or read for read, but also, that a
write could also require a read and vice versa.
I have absolutely no idea when and why, except (maybe) for the
rehandshake-part which *seems* to be allowed to be ignored and hope, that
the other side accepts it.

A handshake *will* require read and write operations.
A write operation *will* require sending the plain text encrypted, though,
a write operation at least. but *can* it result into a read?
Same for the read operation.

At what moments should I handle those rehandshake requests from the other
side (and why would he want to rehandshake anyways?)?
Are there any other unexpected events than the rehandshake-request that I
*should* handle during an SSL session?

Many many thanks,
Christian Parpart.




From nmav at gnutls.org  Tue Jul  6 11:23:00 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 6 Jul 2010 11:23:00 +0200
Subject: understanding the SSL I/O model
In-Reply-To: <b772611851504bba66dae1913717805c.squirrel@mail.trapni.de>
References: <b772611851504bba66dae1913717805c.squirrel@mail.trapni.de>
Message-ID: <AANLkTik7FgmsqlItUf6vOkpcYoyRhp40Uf0arhidIWUc@mail.gmail.com>

On Tue, Jul 6, 2010 at 10:58 AM, Christian Parpart <trapni at gentoo.org> wrote:
> Hey all,
> I've got a question I could not actually google for it.
> Somebody recently told me, that an SSL write or read operation may also
> result in not just a write for write, or read for read, but also, that a
> write could also require a read and vice versa.
> I have absolutely no idea when and why, except (maybe) for the
> rehandshake-part which *seems* to be allowed to be ignored and hope, that
> the other side accepts it.

Read and write are independent in TLS (and SSL). Every request for
read needs only to read data, and the same occurs for write. The one
who told you was probably talking about some other protocol.


regards,
Nikos



From paul at darkrain42.org  Tue Jul  6 23:13:18 2010
From: paul at darkrain42.org (Paul Aurich)
Date: Tue, 06 Jul 2010 14:13:18 -0700
Subject: understanding the SSL I/O model
In-Reply-To: <AANLkTik7FgmsqlItUf6vOkpcYoyRhp40Uf0arhidIWUc@mail.gmail.com>
References: <b772611851504bba66dae1913717805c.squirrel@mail.trapni.de>
	<AANLkTik7FgmsqlItUf6vOkpcYoyRhp40Uf0arhidIWUc@mail.gmail.com>
Message-ID: <4C339C6E.6040604@darkrain42.org>

On 2010-07-06 02:23, Nikos Mavrogiannopoulos wrote:
> On Tue, Jul 6, 2010 at 10:58 AM, Christian Parpart <trapni at gentoo.org> wrote:
>> Hey all,
>> I've got a question I could not actually google for it.
>> Somebody recently told me, that an SSL write or read operation may also
>> result in not just a write for write, or read for read, but also, that a
>> write could also require a read and vice versa.
>> I have absolutely no idea when and why, except (maybe) for the
>> rehandshake-part which *seems* to be allowed to be ignored and hope, that
>> the other side accepts it.
> 
> Read and write are independent in TLS (and SSL). Every request for
> read needs only to read data, and the same occurs for write. The one
> who told you was probably talking about some other protocol.

What happens if, in the processing of read data, GnuTLS encounters an
invalid record and generates a TLS fatal alert?  Presumably that needs
to actually be sent to the remote end of the connection.

~Paul


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100706/b91a2ecb/attachment.pgp>

From nmav at gnutls.org  Wed Jul  7 00:27:29 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 07 Jul 2010 00:27:29 +0200
Subject: understanding the SSL I/O model
In-Reply-To: <4C339C6E.6040604@darkrain42.org>
References: <b772611851504bba66dae1913717805c.squirrel@mail.trapni.de>
	<AANLkTik7FgmsqlItUf6vOkpcYoyRhp40Uf0arhidIWUc@mail.gmail.com>
	<4C339C6E.6040604@darkrain42.org>
Message-ID: <4C33ADD1.3060500@gnutls.org>

Paul Aurich wrote:

>> Read and write are independent in TLS (and SSL). Every request for
>> read needs only to read data, and the same occurs for write. The one
>> who told you was probably talking about some other protocol.
> What happens if, in the processing of read data, GnuTLS encounters an
> invalid record and generates a TLS fatal alert?  Presumably that needs
> to actually be sent to the remote end of the connection.

gnutls is not that high level. It will not send anything unless
explicitly told to. Applications can chose to send alerts or not.

regards,
Nikos



From nmav at gnutls.org  Thu Jul  8 17:59:28 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 08 Jul 2010 17:59:28 +0200
Subject: Intermediate Certificate problem
In-Reply-To: <87r5jivyxp.wl%simon@cliffestones.demon.co.uk>
References: <87r5jivyxp.wl%simon@cliffestones.demon.co.uk>
Message-ID: <4C35F5E0.9080900@gnutls.org>

Simon Brown wrote:
> Hi,

> I use the Wanderlust email client and the Debian packager, Tatsuya has
> recently changed to using GNU TLS from OpenSSL. This has caused a
> problem for me as an IMAP server I use seems to have a certificate
> problem which either didn't exist before or was ignored by OpenSSL.
> The instructions to help diagnose the problem given by Tatsuya the
> packager are shown below with the output. The server's administrators
> claim there is not a problem as Thunderbird on Win32 has no
> problem. Thunderbird does not include the Educational certificate in
> its root store

It seems that the program you are using should set the verification flag
to allow X.509 V.1 certificates. This is done with the
gnutls_certificate_set_verify_flags(xcred,
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);

call. For some reason it wasn't default in gnutls-cli as well. I've set
it now.

> I have worked around the problem by adding the intermediate
> certificate to my local store. I would none the less be very grateful
> for any help in locating the cause of the problem.

By default we disable version 1 certificates since it is not possible to
distinguish CA certificates from end-user (server) certificates. If one
is sure that his trusted certificate storage only contains CA
certificates, then this flag should be specified.

regards,
Nikos



From simon at cliffestones.demon.co.uk  Thu Jul  8 18:37:21 2010
From: simon at cliffestones.demon.co.uk (Simon Brown)
Date: Thu, 08 Jul 2010 17:37:21 +0100
Subject: Intermediate Certificate problem
In-Reply-To: <4C35F5E0.9080900@gnutls.org>
References: <87r5jivyxp.wl%simon@cliffestones.demon.co.uk>
	<4C35F5E0.9080900@gnutls.org>
Message-ID: <87wrt6x73y.wl%simon@cliffestones.demon.co.uk>

At Thu, 08 Jul 2010 17:59:28 +0200,
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> It seems that the program you are using should set the verification flag
> to allow X.509 V.1 certificates. This is done with the
> gnutls_certificate_set_verify_flags(xcred,
> GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);
> 
> call. For some reason it wasn't default in gnutls-cli as well. I've set
> it now.
Wanderlust is an emacs application, I believe it was using gnutls-cli
directly rather than calling library code.

I shall pass this onto the Wanderlust packager and perhaps the gnutls-cli
packager as a patch is needed.

> By default we disable version 1 certificates since it is not possible to
> distinguish CA certificates from end-user (server) certificates. If one
> is sure that his trusted certificate storage only contains CA
> certificates, then this flag should be specified.

Thanks,

Simon



From nmav at gnutls.org  Sat Jul 10 23:44:15 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 10 Jul 2010 23:44:15 +0200
Subject: select + record_recv
Message-ID: <4C38E9AF.2000706@gnutls.org>

In the early versions of GnuTLS I implemented a hack in order to use
select() to check whether there are data to read from the gnutls
session. Is this feature actually used? If you want to check for data in
a gnutls_session how do you do it?


regards,
Nikos



From mrsam at courier-mta.com  Sat Jul 10 22:53:18 2010
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sat, 10 Jul 2010 16:53:18 -0400
Subject: select + record_recv
References: <4C38E9AF.2000706@gnutls.org>
Message-ID: <cone.1278795198.486961.5886.500@commodore.email-scan.com>

Nikos Mavrogiannopoulos writes:

> In the early versions of GnuTLS I implemented a hack in order to use
> select() to check whether there are data to read from the gnutls
> session. Is this feature actually used? If you want to check for data in
> a gnutls_session how do you do it?

I always thought that the correct logic is:

1) Non-blocking sockets are a must.

2) Check what gnutls_record_check_pending() tells you, first.

23 If there's nothing pending, poll() or select(), and if it indicates that 
data is available, try gnutls_record_recv().

Now, if gnutls_record_recv() hands you back some data, you do have to 
consume it. However, this logic seems to work reliably for me, in 
event-driven situations.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20100710/c74978d5/attachment.pgp>

From nmav at gnutls.org  Sun Jul 11 12:34:21 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 11 Jul 2010 12:34:21 +0200
Subject: select + record_recv
In-Reply-To: <cone.1278795198.486961.5886.500@commodore.email-scan.com>
References: <4C38E9AF.2000706@gnutls.org>
	<cone.1278795198.486961.5886.500@commodore.email-scan.com>
Message-ID: <4C399E2D.7070700@gnutls.org>

Sam Varshavchik wrote:
> Nikos Mavrogiannopoulos writes:
> 
>> In the early versions of GnuTLS I implemented a hack in order to use
>> select() to check whether there are data to read from the gnutls
>> session. Is this feature actually used? If you want to check for data in
>> a gnutls_session how do you do it?
> 
> I always thought that the correct logic is:
> 
> 1) Non-blocking sockets are a must.
> 
> 2) Check what gnutls_record_check_pending() tells you, first.

So do you traverse over all gnutls sessions and use the pending function?

> 23 If there's nothing pending, poll() or select(), and if it indicates
> that data is available, try gnutls_record_recv().
> 
> Now, if gnutls_record_recv() hands you back some data, you do have to
> consume it. However, this logic seems to work reliably for me, in
> event-driven situations.

Indeed this looks to be the correct approach.


regards,
Nikos



From mrsam at courier-mta.com  Sun Jul 11 14:12:04 2010
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sun, 11 Jul 2010 08:12:04 -0400
Subject: select + record_recv
References: <4C38E9AF.2000706@gnutls.org>
	<cone.1278795198.486961.5886.500@commodore.email-scan.com>
	<4C399E2D.7070700@gnutls.org>
Message-ID: <cone.1278850324.323779.11270.500@commodore.email-scan.com>

Nikos Mavrogiannopoulos writes:

> Sam Varshavchik wrote:
>> Nikos Mavrogiannopoulos writes:
>> 
>>> In the early versions of GnuTLS I implemented a hack in order to use
>>> select() to check whether there are data to read from the gnutls
>>> session. Is this feature actually used? If you want to check for data in
>>> a gnutls_session how do you do it?
>> 
>> I always thought that the correct logic is:
>> 
>> 1) Non-blocking sockets are a must.
>> 
>> 2) Check what gnutls_record_check_pending() tells you, first.
> 
> So do you traverse over all gnutls sessions and use the pending function?

Yes.

> 
>> 23 If there's nothing pending, poll() or select(), and if it indicates
>> that data is available, try gnutls_record_recv().
>> 
>> Now, if gnutls_record_recv() hands you back some data, you do have to
>> consume it. However, this logic seems to work reliably for me, in
>> event-driven situations.
> 
> Indeed this looks to be the correct approach.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20100711/1391baa7/attachment.pgp>

From lfinsto at gwdg.de  Wed Jul 14 12:20:31 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 14 Jul 2010 12:20:31 +0200
Subject: select + record_recv
In-Reply-To: <4C38E9AF.2000706@gnutls.org>
References: <4C38E9AF.2000706@gnutls.org>
Message-ID: <3efbe096ec41e19422b0e79be8aea00d.squirrel@mailbox.gwdg.de>


On Sat, July 10, 2010 11:44 pm, Nikos Mavrogiannopoulos wrote:
> In the early versions of GnuTLS I implemented a hack in order to use
> select() to check whether there are data to read from the gnutls
> session. Is this feature actually used? If you want to check for data in
> a gnutls_session how do you do it?

No, I don't use it, but I probably would have, if I'd known about it.  I
must have missed it in the documentation.

Instead, I've taken some trouble to ensure that the client and server are
"synchronized" in the sense that server always gets a message from the
client when it's waiting for one and vice versa.  In a couple of places,
it's necessary for one or the other to signal the peer to stop waiting. 
It does this by sending a single null byte.  In this case, the message is
not processed.  Otherwise, if there's data, it is passed to the respective
parser function.  The server's parser function has a rule for "Client
finished" and the client's parser function has a rule for "Server
finished".  Normally, the client will end the connection when it's
finished and the server has told the client that it's finished.  Handling
error conditions is somewhat more complicated, but the connection should
never just be broken off.

This approach seems to work well and I wouldn't change it for one that
uses polling at this point. With my application, connections shouldn't
normally be left open for a long time with wide gaps between messages from
one peer to the other.

Laurence


>
>
> regards,
> Nikos
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From pedro.pereira at tut.fi  Wed Jul 14 18:25:11 2010
From: pedro.pereira at tut.fi (Pedro Pereira)
Date: Wed, 14 Jul 2010 19:25:11 +0300
Subject: GnuTLS-2.10.0 instalation problem ("make check" tests failed)
Message-ID: <20100714192511.157753gwt8j6qsiw@webmail.tut.fi>

Hi all,

It seems that When I was trying to install the new version  
GnuTLS-2.10.0, I got some errors when I was doing the make check.

libgcrypt-1.4.6 and libtasn1-2.7 has been installed by default:
./configure; make; make check (no errors); sudo make install;

GnuTLS-2.10.0 has been installed by default:
./configure; make; make check;

Everything was going fine with the "make check" until here:

...
Self test `./mini-eagain' finished with 0 errors
PASS: mini-eagain
Self test `./nul-in-x509-names' finished with 0 errors
PASS: nul-in-x509-names
Self test `./x509_altname' finished with 0 errors
PASS: x509_altname
Self test `./pkcs12_encode' finished with 0 errors
PASS: pkcs12_encode
PASS: mini-x509
PASS: mini-x509-rehandshake
Self test `./openssl' finished with 0 errors
PASS: openssl
Self test `./openpgp-keyring' finished with 0 errors
PASS: openpgp-keyring
PASS: pgps2kgnu
bind: Address already in use
server: bind failed
Self test `./x509self' finished with 1 errors
FAIL: x509self
bind: Address already in use
server: bind failed
Self test `./x509signself' finished with 1 errors
FAIL: x509signself
bind: Address already in use
server: bind failed
Self test `./x509dn' finished with 1 errors
FAIL: x509dn
bind: Address already in use
server: bind failed
Self test `./anonself' finished with 1 errors
FAIL: anonself
bind: Address already in use
server: bind failed
Self test `./pskself' finished with 1 errors
FAIL: pskself
bind: Address already in use
server: bind failed
Self test `./dhepskself' finished with 1 errors
FAIL: dhepskself
bind: Address already in use
server: bind failed
Self test `./tlsia' finished with 1 errors
FAIL: tlsia
bind: Address already in use
server: bind failed
Self test `./resume' finished with 1 errors
FAIL: resume
Self test `./netconf-psk' finished with 0 errors
PASS: netconf-psk
PASS: setcredcrash
bind: Address already in use
server: bind failed
Self test `./openpgpself' finished with 1 errors
FAIL: openpgpself
PASS: rfc2253-escape-test
===================================
9 of 45 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory  
`/home/pedro/workspace/gnutls-install/gnutls-2.10.0/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory  
`/home/pedro/workspace/gnutls-install/gnutls-2.10.0/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory  
`/home/pedro/workspace/gnutls-install/gnutls-2.10.0/tests'
make: *** [check-recursive] Error 1

Anyone knows what's happening here? Am I missing something?

Regards,
Pedro




From mads at kiilerich.com  Tue Jul 20 01:14:33 2010
From: mads at kiilerich.com (Mads Kiilerich)
Date: Tue, 20 Jul 2010 01:14:33 +0200
Subject: Working around wrong algorithm specification in certificates
Message-ID: <4C44DC59.40602@kiilerich.com>

  Hi

I am trying to use GnuTLS in an application where I for interoperability 
need to read the public key of x509 certificates.

But gnutls_x509_crt_get_pk_rsa_raw fails - because 
gnutls_x509_crt_get_pk_algorithm returns GNUTLS_PK_UNKNOWN, because the 
public key oid is SIG_RSA_MD5_OID 1.2.840.113549.1.1.4 instead of the 
PK_PKIX1_RSA_OID 1.2.840.113549.1.1.1 it should have been.

Do you have any idea how I can workaround that? In NSS and openssl it is 
possible to patch the parsed cert, but it seems like that isn't possible 
with GnuTLS?

What would be the least ugly hack I can use? To somehow call 
asn1_write_value to set the right OID? Or _gnutls_x509_read_value and 
_gnutls_x509_read_rsa_params ?

/Mads



From nmav at gnutls.org  Tue Jul 20 09:48:12 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 20 Jul 2010 09:48:12 +0200
Subject: Working around wrong algorithm specification in certificates
In-Reply-To: <4C44DC59.40602@kiilerich.com>
References: <4C44DC59.40602@kiilerich.com>
Message-ID: <AANLkTilK8oI3LqCVu1CIqBKrj6PvGlyZfTMezQMC5ZSl@mail.gmail.com>

On Tue, Jul 20, 2010 at 1:14 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
> ?Hi
>
> I am trying to use GnuTLS in an application where I for interoperability
> need to read the public key of x509 certificates.
>
> But gnutls_x509_crt_get_pk_rsa_raw fails - because
> gnutls_x509_crt_get_pk_algorithm returns GNUTLS_PK_UNKNOWN, because the
> public key oid is SIG_RSA_MD5_OID 1.2.840.113549.1.1.4 instead of the
> PK_PKIX1_RSA_OID 1.2.840.113549.1.1.1 it should have been.
> Do you have any idea how I can workaround that? In NSS and openssl it is
> possible to patch the parsed cert, but it seems like that isn't possible
> with GnuTLS?

Do you want to fix the certificate or just read it? If you want to
read it open gnutls_algorithms.c and add an extra entry to
pk_algorithms structure for RSA with the OID you describe. Then you
should be able to read the key. If you want to "fix" it I think this
is as easy as regenerating it.

regards,
Nikos



From mads at kiilerich.com  Tue Jul 20 13:07:34 2010
From: mads at kiilerich.com (Mads Kiilerich)
Date: Tue, 20 Jul 2010 13:07:34 +0200
Subject: Working around wrong algorithm specification in certificates
In-Reply-To: <AANLkTilK8oI3LqCVu1CIqBKrj6PvGlyZfTMezQMC5ZSl@mail.gmail.com>
References: <4C44DC59.40602@kiilerich.com>
	<AANLkTilK8oI3LqCVu1CIqBKrj6PvGlyZfTMezQMC5ZSl@mail.gmail.com>
Message-ID: <4C458376.5080906@kiilerich.com>

  Nikos Mavrogiannopoulos wrote, On 07/20/2010 09:48 AM:
> On Tue, Jul 20, 2010 at 1:14 AM, Mads Kiilerich<mads at kiilerich.com>  wrote:
>>   Hi
>>
>> I am trying to use GnuTLS in an application where I for interoperability
>> need to read the public key of x509 certificates.
>>
>> But gnutls_x509_crt_get_pk_rsa_raw fails - because
>> gnutls_x509_crt_get_pk_algorithm returns GNUTLS_PK_UNKNOWN, because the
>> public key oid is SIG_RSA_MD5_OID 1.2.840.113549.1.1.4 instead of the
>> PK_PKIX1_RSA_OID 1.2.840.113549.1.1.1 it should have been.
>> Do you have any idea how I can workaround that? In NSS and openssl it is
>> possible to patch the parsed cert, but it seems like that isn't possible
>> with GnuTLS?
> Do you want to fix the certificate or just read it? If you want to
> read it open gnutls_algorithms.c and add an extra entry to
> pk_algorithms structure for RSA with the OID you describe. Then you
> should be able to read the key. If you want to "fix" it I think this
> is as easy as regenerating it.

The application has to be able to read such certificates. That is how 
windows creates certificates for terminal services...

I would like to able to use the gnutls library installed on the system, 
so patching gnutls source isn't really an option. There is no other way 
to do it? You don't want to pollute your code with workarounds or 
flexibility for stupid bugs like this?

/Mads



From nmav at gnutls.org  Tue Jul 20 13:33:20 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 20 Jul 2010 13:33:20 +0200
Subject: Working around wrong algorithm specification in certificates
In-Reply-To: <4C458376.5080906@kiilerich.com>
References: <4C44DC59.40602@kiilerich.com>
	<AANLkTilK8oI3LqCVu1CIqBKrj6PvGlyZfTMezQMC5ZSl@mail.gmail.com>
	<4C458376.5080906@kiilerich.com>
Message-ID: <AANLkTil5fm2-x10yXyCxsbqh9Epi0_HzCsyMQLOHX2EG@mail.gmail.com>

On Tue, Jul 20, 2010 at 1:07 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> Do you want to fix the certificate or just read it? If you want to
>> read it open gnutls_algorithms.c and add an extra entry to
>> pk_algorithms structure for RSA with the OID you describe. Then you
>> should be able to read the key. If you want to "fix" it I think this
>> is as easy as regenerating it.
>
> The application has to be able to read such certificates. That is how
> windows creates certificates for terminal services...
> I would like to able to use the gnutls library installed on the system, so
> patching gnutls source isn't really an option. There is no other way to do
> it?
Since it is a certificate you cannot modify it without breaking the
signature. The most straightforward way to fix that is to (1) fix the
one who is generating the wrong certificates, (2) fix the one who is
reading them to account for the broken ones.

> You don't want to pollute your code with workarounds or flexibility for
> stupid bugs like this?
I was thinking about your copy of gnutls :) If the fix works and the
problem is general the workaround might be included in the gnutls code
as well. I've seen quite some implementations putting wrong OIDs here
and there, and working around those practices is not that exceptional
any more.

regards,
Nikos



From trapni at gentoo.org  Tue Jul 20 23:51:27 2010
From: trapni at gentoo.org (Christian Parpart)
Date: Tue, 20 Jul 2010 23:51:27 +0200
Subject: handshake fails (unimplemented/disabled feature requested?)
Message-ID: <c703e5f194dd89a9a967bd1ddd364ffc.squirrel@mail.trapni.de>

Hey all,

I've written a little http server, also providing SSL,
but while the ssl andshake, I now get the following
(it once worked but sometimes failed with the trace below):

1279662272.980041: SslSocket: handshake()
1279662272.980041: ssl: gnutls [4] REC[0x22845d0]: Expected Packet[0]
Handshake(22) with length: 1
1279662272.980041: ssl: gnutls [4] REC[0x22845d0]: Received Packet[0]
Handshake(22) with length: 85
1279662272.980041: ssl: gnutls [4] REC[0x22845d0]: Decrypted Packet[0]
Handshake(22) with length: 85
1279662272.980041: ssl: gnutls [6] BUF[HSK]: Inserted 85 bytes of Data(22)
1279662272.980041: ssl: gnutls [6] BUF[REC][HD]: Read 1 bytes of Data(22)
1279662272.980041: ssl: gnutls [6] BUF[REC][HD]: Read 3 bytes of Data(22)
1279662272.980041: ssl: gnutls [3] HSK[0x22845d0]: CLIENT HELLO was
received [85 bytes]
1279662272.980041: ssl: gnutls [6] BUF[REC][HD]: Read 81 bytes of Data(22)
1279662272.980041: ssl: gnutls [6] BUF[HSK]: Inserted 4 bytes of Data
1279662272.980041: ssl: gnutls [6] BUF[HSK]: Inserted 81 bytes of Data
1279662272.980041: ssl: gnutls [3] HSK[0x22845d0]: Client's version: 3.0
1279662272.980041: ssl: gnutls [2] ASSERT: gnutls_db.c:326
1279662272.980041: ssl: gnutls [2] ASSERT: gnutls_db.c:246
1279662272.980041: ssl: gnutls [2] ASSERT: gnutls_extensions.c:140
1279662272.980041: SslSocket: onClientHello()
1279662272.980041: ssl: gnutls [2] ASSERT: gnutls_handshake.c:376
1279662272.980041: ssl: gnutls [2] ASSERT: gnutls_handshake.c:535
1279662272.980041: ssl: gnutls [2] ASSERT: gnutls_handshake.c:2335
1279662272.980041: ssl: gnutls [2] ASSERT: gnutls_handshake.c:3000
1279662272.980041: ssl: gnutls [6] BUF[HSK]: Cleared Data from buffer
1279662272.980041: SslSocket: SSL handshake failed (-1250): An
unimplemented or disabled feature has been requested.


What did I do wrong? Well, I at least know, that I've successfully
declared the algorithm
priorities to { tls1.2, tls1.1, tls1.0, ssl3 }, so this can't be it. but
what feature is gnutls
here saying, which I am missing (possibly not enabled)?

Many thanks in advance,
Christian Parpart.




From trapni at gentoo.org  Wed Jul 21 00:34:43 2010
From: trapni at gentoo.org (Christian Parpart)
Date: Wed, 21 Jul 2010 00:34:43 +0200
Subject: handshake fails (unimplemented/disabled feature requested?)
In-Reply-To: <c703e5f194dd89a9a967bd1ddd364ffc.squirrel@mail.trapni.de>
References: <c703e5f194dd89a9a967bd1ddd364ffc.squirrel@mail.trapni.de>
Message-ID: <7df57a083d67f0fb7e711270273c6916.squirrel@mail.trapni.de>

On Tue, July 20, 2010 11:51 pm, Christian Parpart wrote:
> Hey all,
>
> I've written a little http server, also providing SSL,
> but while the ssl andshake, I now get the following
> (it once worked but sometimes failed with the trace below):
[....]

I found out, that this was due to an unresolved SNI name, however, I was
lucky in finding the reason.
So now I am back in my *old* behaviour of "unimplemented/disabled feature
requested"-message, that only happens when using chromium/chrome:
1279664834.087054: ssl: gnutls [3] HSK[0x24a4e70]: CLIENT HELLO was
received [193 bytes]
1279664834.087054: ssl: gnutls [3] HSK[0x24a4e70]: Client's version: 3.1
1279664834.087054: ssl: gnutls [2] EXT[0x24a4e70]: Found extension
'SERVER_NAME/0'
1279664834.087054: ssl: gnutls [2] EXT[0x24a4e70]: Found extension
'SAFE_RENEGOTIATION/65281'
1279664834.087054: ssl: gnutls [2] EXT[0x24a4e70]: Found extension
'(null)/10'
1279664834.087054: ssl: gnutls [2] EXT[0x24a4e70]: Found extension
'(null)/11'
1279664834.087054: ssl: gnutls [2] EXT[0x24a4e70]: Found extension
'SESSION_TICKET/35'
1279664834.087054: ssl: gnutls [2] ASSERT: gnutls_handshake.c:376
1279664834.087054: ssl: gnutls [2] ASSERT: gnutls_handshake.c:2335
1279664834.087054: ssl: gnutls [2] ASSERT: gnutls_handshake.c:3000
1279664834.087054: SslSocket: SSL handshake failed (-1250): An
unimplemented or disabled feature has been requested.
1279664834.088050: ssl: gnutls [3] HSK[0x24a4e70]: CLIENT HELLO was
received [85 bytes]
1279664834.088050: ssl: gnutls [3] HSK[0x24a4e70]: Client's version: 3.0
1279664834.088050: ssl: gnutls [2] ASSERT: gnutls_db.c:326
1279664834.088050: ssl: gnutls [2] ASSERT: gnutls_db.c:246
1279664834.088050: ssl: gnutls [2] ASSERT: gnutls_extensions.c:140
1279664834.088050: ssl: gnutls [2] ASSERT: gnutls_handshake.c:376
1279664834.088050: ssl: gnutls [2] ASSERT: gnutls_handshake.c:535
1279664834.088050: ssl: gnutls [2] ASSERT: gnutls_handshake.c:2335
1279664834.088050: ssl: gnutls [2] ASSERT: gnutls_handshake.c:3000
1279664834.088050: SslSocket: SSL handshake failed (-1250): An
unimplemented or disabled feature has been requested.


Now, pressing F5 (once or twice) on the same resource results into the
expected result:

1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: CLIENT HELLO was
received [161 bytes]
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Client's version: 3.1
1279664874.629215: ssl: gnutls [2] ASSERT: gnutls_db.c:326
1279664874.629215: ssl: gnutls [2] ASSERT: gnutls_db.c:246
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'SERVER_NAME/0'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'SAFE_RENEGOTIATION/65281'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'(null)/10'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'(null)/11'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'SESSION_TICKET/35'
1279664874.629215: ssl: select SslContext: CN:trapni.de, dnsName:shougar
1279664874.629215: SslContext: bind() (cn="trapni.de")
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'SERVER_NAME/0'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'SAFE_RENEGOTIATION/65281'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'(null)/10'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'(null)/11'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'SESSION_TICKET/35'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'SERVER_NAME/0'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'SAFE_RENEGOTIATION/65281'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'(null)/10'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'(null)/11'
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Found extension
'SESSION_TICKET/35'
1279664874.629215: SslContext: onRetrieveCert()
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Removing ciphersuite:
PSK_SHA_ARCFOUR_SHA1
[ ............. ]
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Keeping ciphersuite:
RSA_CAMELLIA_256_CBC_SHA1
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Selected cipher suite:
DHE_RSA_CAMELLIA_256_CBC_SHA1
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Selected Compression
Method: NULL
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Safe renegotiation
succeeded
1279664874.629215: ssl: gnutls [2] EXT[0x24b0470]: Sending extension
SAFE_RENEGOTIATION
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: SessionID:
b98d970db54203e916cc873a53deddcbe3cda7364aa2e78045346912181a679e
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: SERVER HELLO was sent
[81 bytes]
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: CERTIFICATE was sent
[1027 bytes]
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: SERVER KEY EXCHANGE was
sent [525 bytes]
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: SERVER HELLO DONE was
sent [4 bytes]
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: CLIENT KEY EXCHANGE was
received [134 bytes]
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Cipher Suite:
DHE_RSA_CAMELLIA_256_CBC_SHA1
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Initializing internal
[read] cipher sessions
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: FINISHED was received
[16 bytes]
1279664874.629215: ssl: gnutls [3] REC[0x24b0470]: Sent ChangeCipherSpec
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Cipher Suite:
DHE_RSA_CAMELLIA_256_CBC_SHA1
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: Initializing internal
[write] cipher sessions
1279664874.629215: ssl: gnutls [3] HSK[0x24b0470]: FINISHED was sent [16
bytes]

FYI: When using curl for querying my https server, everything works fine
(no gnutls errors).
I also see two of the error messages in my first log fragment, I guess
that there are two
different kinds reuested that I (maybe) did not enable explicitely. But
which one...

Sorry for the wrong debug prints in my prior mail. :)

> What did I do wrong? Well, I at least know, that I've successfully
> declared the algorithm
> priorities to { tls1.2, tls1.1, tls1.0, ssl3 }, so this can't be it. but
> what feature is gnutls
> here saying, which I am missing (possibly not enabled)?

Many thanks in advance,
Christian Parpart.





From mads at kiilerich.com  Wed Jul 21 00:58:12 2010
From: mads at kiilerich.com (Mads Kiilerich)
Date: Wed, 21 Jul 2010 00:58:12 +0200
Subject: Working around wrong algorithm specification in certificates
In-Reply-To: <AANLkTil5fm2-x10yXyCxsbqh9Epi0_HzCsyMQLOHX2EG@mail.gmail.com>
References: <4C44DC59.40602@kiilerich.com>	<AANLkTilK8oI3LqCVu1CIqBKrj6PvGlyZfTMezQMC5ZSl@mail.gmail.com>	<4C458376.5080906@kiilerich.com>
	<AANLkTil5fm2-x10yXyCxsbqh9Epi0_HzCsyMQLOHX2EG@mail.gmail.com>
Message-ID: <4C462A04.5080403@kiilerich.com>

  Nikos Mavrogiannopoulos wrote, On 07/20/2010 01:33 PM:
> On Tue, Jul 20, 2010 at 1:07 PM, Mads Kiilerich<mads at kiilerich.com>  wrote:
>>> Do you want to fix the certificate or just read it? If you want to
>>> read it open gnutls_algorithms.c and add an extra entry to
>>> pk_algorithms structure for RSA with the OID you describe. Then you
>>> should be able to read the key. If you want to "fix" it I think this
>>> is as easy as regenerating it.
>> The application has to be able to read such certificates. That is how
>> windows creates certificates for terminal services...
>> I would like to able to use the gnutls library installed on the system, so
>> patching gnutls source isn't really an option. There is no other way to do
>> it?
> Since it is a certificate you cannot modify it without breaking the
> signature.

Right. But the challenge is to convince gnutls to parse it and tell me 
what it parsed. If that involves making a copy and hacking it so it 
breaks then that is fine - as long as it reveals the key.

> The most straightforward way to fix that is to (1) fix the
> one who is generating the wrong certificates, (2) fix the one who is
> reading them to account for the broken ones.

1 is unfortunately not an option.

My goal is to do 2 by using gnutls as it is installed as shared library 
on systems. Requiring 2.10.1 would be OK ;-)

>> You don't want to pollute your code with workarounds or flexibility for
>> stupid bugs like this?
> I was thinking about your copy of gnutls :) If the fix works and the
> problem is general the workaround might be included in the gnutls code
> as well. I've seen quite some implementations putting wrong OIDs here
> and there, and working around those practices is not that exceptional
> any more.

This patch works for me and 2.10.0:

--- gnutls-2.10.0/lib/gnutls_algorithms.c.org   2010-07-20 
22:57:35.000000000 +0200
+++ gnutls-2.10.0/lib/gnutls_algorithms.c       2010-07-20 
22:57:07.000000000 +0200
@@ -2125,6 +2125,7 @@
    {"DSA", PK_DSA_OID, GNUTLS_PK_DSA},
    {"GOST R 34.10-2001", PK_GOST_R3410_2001_OID, 0},
    {"GOST R 34.10-94", PK_GOST_R3410_94_OID, 0},
+  {"RSA (MD5)", SIG_RSA_MD5_OID, GNUTLS_PK_RSA},
    {0, 0, 0}
  };

I can see that you added PK_X509_RSA_OID since 2.10.0. Could this 
perhaps be added too?

There is also anecdotical evidence that SIG_RSA_SHA1_OID needs the same 
treatment. I haven't seen that, but getting both fixed at once could be 
great.

/Mads



From nmav at gnutls.org  Wed Jul 21 09:11:36 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 21 Jul 2010 09:11:36 +0200
Subject: handshake fails (unimplemented/disabled feature requested?)
In-Reply-To: <7df57a083d67f0fb7e711270273c6916.squirrel@mail.trapni.de>
References: <c703e5f194dd89a9a967bd1ddd364ffc.squirrel@mail.trapni.de>
	<7df57a083d67f0fb7e711270273c6916.squirrel@mail.trapni.de>
Message-ID: <4C469DA8.2020201@gnutls.org>

Christian Parpart wrote:
> On Tue, July 20, 2010 11:51 pm, Christian Parpart wrote:
>> Hey all,
>>
>> I've written a little http server, also providing SSL,
>> but while the ssl andshake, I now get the following
>> (it once worked but sometimes failed with the trace below):
> [....]
> 
> I found out, that this was due to an unresolved SNI name, however, I was
> lucky in finding the reason.
> So now I am back in my *old* behaviour of "unimplemented/disabled feature
> requested"-message, that only happens when using chromium/chrome:
[...]
> 1279664834.087054: ssl: gnutls [2] ASSERT: gnutls_handshake.c:376

It seems you use the gnutls_handshake_set_post_client_hello_function(),
and your callback function returns the error you see. If this is not the
case, then provide the smallest server the exhibits this error.

regards,
Nikos



From nmav at gnutls.org  Wed Jul 21 09:23:52 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 21 Jul 2010 09:23:52 +0200
Subject: Working around wrong algorithm specification in certificates
In-Reply-To: <4C462A04.5080403@kiilerich.com>
References: <4C44DC59.40602@kiilerich.com>	<AANLkTilK8oI3LqCVu1CIqBKrj6PvGlyZfTMezQMC5ZSl@mail.gmail.com>	<4C458376.5080906@kiilerich.com>
	<AANLkTil5fm2-x10yXyCxsbqh9Epi0_HzCsyMQLOHX2EG@mail.gmail.com>
	<4C462A04.5080403@kiilerich.com>
Message-ID: <4C46A088.60003@gnutls.org>

Mads Kiilerich wrote:

>>> You don't want to pollute your code with workarounds or flexibility for
>>> stupid bugs like this?
>> I was thinking about your copy of gnutls :) If the fix works and the
>> problem is general the workaround might be included in the gnutls code
>> as well. I've seen quite some implementations putting wrong OIDs here
>> and there, and working around those practices is not that exceptional
>> any more.
> 
> This patch works for me and 2.10.0:
> 
> --- gnutls-2.10.0/lib/gnutls_algorithms.c.org   2010-07-20
> 22:57:35.000000000 +0200
> +++ gnutls-2.10.0/lib/gnutls_algorithms.c       2010-07-20
> 22:57:07.000000000 +0200
> @@ -2125,6 +2125,7 @@
>    {"DSA", PK_DSA_OID, GNUTLS_PK_DSA},
>    {"GOST R 34.10-2001", PK_GOST_R3410_2001_OID, 0},
>    {"GOST R 34.10-94", PK_GOST_R3410_94_OID, 0},
> +  {"RSA (MD5)", SIG_RSA_MD5_OID, GNUTLS_PK_RSA},
>    {0, 0, 0}
>  };
> 
> I can see that you added PK_X509_RSA_OID since 2.10.0. Could this
> perhaps be added too?
> There is also anecdotical evidence that SIG_RSA_SHA1_OID needs the same
> treatment. I haven't seen that, but getting both fixed at once could be
> great.

I've added them to the 2.10.x branch. I've not added the SHA1_OID but if
you have some certificates using it, I'll add it. Clearly this OID
shouldn't have been there!

regards,
Nikos



From nmav at gnutls.org  Wed Jul 21 22:04:21 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 21 Jul 2010 22:04:21 +0200
Subject: GnuTLS-2.10.0 instalation problem ("make check" tests failed)
In-Reply-To: <20100714192511.157753gwt8j6qsiw@webmail.tut.fi>
References: <20100714192511.157753gwt8j6qsiw@webmail.tut.fi>
Message-ID: <4C4752C5.8000504@gnutls.org>

Pedro Pereira wrote:
> Hi all,
> 
> It seems that When I was trying to install the new version
> GnuTLS-2.10.0, I got some errors when I was doing the make check.
[...]
> FAIL: anonself
> bind: Address already in use
> server: bind failed
> Self test `./pskself' finished with 1 errors
> FAIL: pskself
> bind: Address already in use

Those test programs use a TCP port (5556 or 1234 etc). Probably
something else in your system also uses this port and this seems to be
the reason it fails.

regards,
Nikos



From mads at kiilerich.com  Sat Jul 24 03:06:49 2010
From: mads at kiilerich.com (Mads Kiilerich)
Date: Sat, 24 Jul 2010 03:06:49 +0200
Subject: Working around wrong algorithm specification in certificates
In-Reply-To: <4C46A088.60003@gnutls.org>
References: <4C44DC59.40602@kiilerich.com>	<AANLkTilK8oI3LqCVu1CIqBKrj6PvGlyZfTMezQMC5ZSl@mail.gmail.com>	<4C458376.5080906@kiilerich.com>
	<AANLkTil5fm2-x10yXyCxsbqh9Epi0_HzCsyMQLOHX2EG@mail.gmail.com>
	<4C462A04.5080403@kiilerich.com> <4C46A088.60003@gnutls.org>
Message-ID: <4C4A3CA9.8050207@kiilerich.com>

  Nikos Mavrogiannopoulos wrote, On 07/21/2010 09:23 AM:
> Mads Kiilerich wrote:
>
>>>> You don't want to pollute your code with workarounds or flexibility for
>>>> stupid bugs like this?
>>> I was thinking about your copy of gnutls :) If the fix works and the
>>> problem is general the workaround might be included in the gnutls code
>>> as well. I've seen quite some implementations putting wrong OIDs here
>>> and there, and working around those practices is not that exceptional
>>> any more.
>> This patch works for me and 2.10.0:
>>
>> --- gnutls-2.10.0/lib/gnutls_algorithms.c.org   2010-07-20
>> 22:57:35.000000000 +0200
>> +++ gnutls-2.10.0/lib/gnutls_algorithms.c       2010-07-20
>> 22:57:07.000000000 +0200
>> @@ -2125,6 +2125,7 @@
>>     {"DSA", PK_DSA_OID, GNUTLS_PK_DSA},
>>     {"GOST R 34.10-2001", PK_GOST_R3410_2001_OID, 0},
>>     {"GOST R 34.10-94", PK_GOST_R3410_94_OID, 0},
>> +  {"RSA (MD5)", SIG_RSA_MD5_OID, GNUTLS_PK_RSA},
>>     {0, 0, 0}
>>   };
>>
>> I can see that you added PK_X509_RSA_OID since 2.10.0. Could this
>> perhaps be added too?
>> There is also anecdotical evidence that SIG_RSA_SHA1_OID needs the same
>> treatment. I haven't seen that, but getting both fixed at once could be
>> great.
> I've added them to the 2.10.x branch. I've not added the SHA1_OID but if
> you have some certificates using it, I'll add it. Clearly this OID
> shouldn't have been there!

Thanks!

The anecdote of the need for SIG_RSA_SHA1_OID could be tracked down to 
the comments on 
http://sourceforge.net/tracker/index.php?func=detail&aid=1744033&group_id=24366&atid=381349 
. But the BER encoded certificate on 
https://developer.mozilla.org/en/Introduction_to_Public-Key_Cryptography#A_Typical_Certificate 
(which despite the text _not_ is what is displayed) also uses 
tbsCertificate.subjectPublicKeyInfo.algorithm=sha1WithRSAEncryption. 
Please consider adding support for that too.

If you are going to make a release from gnutls_2_10_x then I hope you 
will include "Correctly deinitialize crypto API handles." as well.

However, according to NEWS you have released 2.11.0 already - but it is 
not on ftp://ftp.gnu.org/pub/gnu/gnutls/ ?

/Mads




From mads at kiilerich.com  Sat Jul 24 03:07:34 2010
From: mads at kiilerich.com (Mads Kiilerich)
Date: Sat, 24 Jul 2010 03:07:34 +0200
Subject: Raw RSA encryption
Message-ID: <4C4A3CD6.9020304@kiilerich.com>

  Hi

The new gnutls/crypto.h exposes fine functionality for using 
stream/block ciphers and hash algorithms directly.

But I also need raw RSA encryption and can't figure out how to do it - 
or if it is possible. I just need the basic modulo-exponentiation, for 
example with values from gnutls_x509_crt_get_pk_rsa_raw.

It seems like it is possible to register such a function with 
gnutls_crypto_pk_register2, but there is no way to retrieve the internal 
implementation? Or is it OK to use _gnutls_pk_ops.encrypt?

Or should I access gcrypt directly, possibly by duplicating the content 
of _wrap_gcry_pk_encrypt?

(In either case it seems like I need to figure out how the simple 
bigendian format of gnutls_datum_t from gnutls_x509_crt_get_pk_rsa_raw 
relates to bigint_t?)

/Mads




From nmav at gnutls.org  Sat Jul 24 10:55:50 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 24 Jul 2010 10:55:50 +0200
Subject: Working around wrong algorithm specification in certificates
In-Reply-To: <4C4A3CA9.8050207@kiilerich.com>
References: <4C44DC59.40602@kiilerich.com>	<AANLkTilK8oI3LqCVu1CIqBKrj6PvGlyZfTMezQMC5ZSl@mail.gmail.com>	<4C458376.5080906@kiilerich.com>
	<AANLkTil5fm2-x10yXyCxsbqh9Epi0_HzCsyMQLOHX2EG@mail.gmail.com>
	<4C462A04.5080403@kiilerich.com> <4C46A088.60003@gnutls.org>
	<4C4A3CA9.8050207@kiilerich.com>
Message-ID: <4C4AAA96.5090003@gnutls.org>

On 07/24/2010 03:06 AM, Mads Kiilerich wrote:

>>> I can see that you added PK_X509_RSA_OID since 2.10.0. Could this
>>> perhaps be added too?
>>> There is also anecdotical evidence that SIG_RSA_SHA1_OID needs the same
>>> treatment. I haven't seen that, but getting both fixed at once could be
>>> great.
>> I've added them to the 2.10.x branch. I've not added the SHA1_OID but if
>> you have some certificates using it, I'll add it. Clearly this OID
>> shouldn't have been there!
> 
> Thanks!
> 
> The anecdote of the need for SIG_RSA_SHA1_OID could be tracked down to
> the comments on
> http://sourceforge.net/tracker/index.php?func=detail&aid=1744033&group_id=24366&atid=381349
> . But the BER encoded certificate on
> https://developer.mozilla.org/en/Introduction_to_Public-Key_Cryptography#A_Typical_Certificate
> (which despite the text _not_ is what is displayed) also uses
> tbsCertificate.subjectPublicKeyInfo.algorithm=sha1WithRSAEncryption.
> Please consider adding support for that too.
I've added that too.

> If you are going to make a release from gnutls_2_10_x then I hope you
> will include "Correctly deinitialize crypto API handles." as well.
The fix is already there so it will be included.

> However, according to NEWS you have released 2.11.0 already - but it is
> not on ftp://ftp.gnu.org/pub/gnu/gnutls/ ?
It is development release so it is available on alpha.gnu.org (not yet)
and ftp.gnutls.org/pub/gnutls/devel only.

regards,
Nikos



From nmav at gnutls.org  Sat Jul 24 11:05:53 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 24 Jul 2010 11:05:53 +0200
Subject: Raw RSA encryption
In-Reply-To: <4C4A3CD6.9020304@kiilerich.com>
References: <4C4A3CD6.9020304@kiilerich.com>
Message-ID: <4C4AACF1.9010409@gnutls.org>

On 07/24/2010 03:07 AM, Mads Kiilerich wrote:
>  Hi
> 
> The new gnutls/crypto.h exposes fine functionality for using
> stream/block ciphers and hash algorithms directly.
> But I also need raw RSA encryption and can't figure out how to do it -
> or if it is possible. I just need the basic modulo-exponentiation, for
> example with values from gnutls_x509_crt_get_pk_rsa_raw.

I question might be, why you want to do that? GnuTLS tries to hide that
by providing high level functions to manage certificates and keys.

> It seems like it is possible to register such a function with
> gnutls_crypto_pk_register2, but there is no way to retrieve the internal
> implementation? Or is it OK to use _gnutls_pk_ops.encrypt?

There is no exported API for that. It is probably possible to do it, but
it is not trivial, and would require a big deal of new API functions and
datatypes to maintain.

> Or should I access gcrypt directly, possibly by duplicating the content
> of _wrap_gcry_pk_encrypt?
> (In either case it seems like I need to figure out how the simple
> bigendian format of gnutls_datum_t from gnutls_x509_crt_get_pk_rsa_raw
> relates to bigint_t?)

The gnutls_datum_t contains the big integer in an unsigned format that
is importable by almost all crypto libraries (and thus libgcrypt). The
bigint_t is the gnutls crypto library's internal representation of that.

regards,
Nikos



From mads at kiilerich.com  Sun Jul 25 04:33:26 2010
From: mads at kiilerich.com (Mads Kiilerich)
Date: Sun, 25 Jul 2010 04:33:26 +0200
Subject: Raw RSA encryption
In-Reply-To: <4C4AACF1.9010409@gnutls.org>
References: <4C4A3CD6.9020304@kiilerich.com> <4C4AACF1.9010409@gnutls.org>
Message-ID: <4C4BA276.5080004@kiilerich.com>

  Nikos Mavrogiannopoulos wrote, On 07/24/2010 11:05 AM:
> On 07/24/2010 03:07 AM, Mads Kiilerich wrote:
>>   Hi
>>
>> The new gnutls/crypto.h exposes fine functionality for using
>> stream/block ciphers and hash algorithms directly.
>> But I also need raw RSA encryption and can't figure out how to do it -
>> or if it is possible. I just need the basic modulo-exponentiation, for
>> example with values from gnutls_x509_crt_get_pk_rsa_raw.
> I question might be, why you want to do that? GnuTLS tries to hide that
> by providing high level functions to manage certificates and keys.

I'm trying to use GnuTLS for the MS RDP protocol which both have a TLS 
mode and a homebrew mode where certificates and rc4 and md5 and sha and 
RSA is used in a different way.

I'm obviously trying to use GnuTLS for something it wasn't intended for. 
I assume that the new crypto.h stuff also don't have any use if GnuTLS 
is used for what it was intended to be used for through high level 
functions. Apparently PK stuff was left out from crypto.h. I wonder why 
you stopped there, but it is fair enough if that is how you want it.

>> It seems like it is possible to register such a function with
>> gnutls_crypto_pk_register2, but there is no way to retrieve the internal
>> implementation? Or is it OK to use _gnutls_pk_ops.encrypt?
> There is no exported API for that. It is probably possible to do it, but
> it is not trivial, and would require a big deal of new API functions and
> datatypes to maintain.

It seems to me like you already have the needed datatypes and that the 
API wouldn't have to be more complex than what already has been done for 
hash and ciphers. But I don't know which problems you see.

>> Or should I access gcrypt directly, possibly by duplicating the content
>> of _wrap_gcry_pk_encrypt?
>> (In either case it seems like I need to figure out how the simple
>> bigendian format of gnutls_datum_t from gnutls_x509_crt_get_pk_rsa_raw
>> relates to bigint_t?)
> The gnutls_datum_t contains the big integer in an unsigned format that
> is importable by almost all crypto libraries (and thus libgcrypt). The
> bigint_t is the gnutls crypto library's internal representation of that.

I will try something like that. Thanks.

/Mads




From nmav at gnutls.org  Sun Jul 25 09:41:40 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 25 Jul 2010 09:41:40 +0200
Subject: Raw RSA encryption
In-Reply-To: <4C4BA276.5080004@kiilerich.com>
References: <4C4A3CD6.9020304@kiilerich.com> <4C4AACF1.9010409@gnutls.org>
	<4C4BA276.5080004@kiilerich.com>
Message-ID: <4C4BEAB4.2070602@gnutls.org>

On 07/25/2010 04:33 AM, Mads Kiilerich wrote:

>>> The new gnutls/crypto.h exposes fine functionality for using
>>> stream/block ciphers and hash algorithms directly.
>>> But I also need raw RSA encryption and can't figure out how to do it -
>>> or if it is possible. I just need the basic modulo-exponentiation, for
>>> example with values from gnutls_x509_crt_get_pk_rsa_raw.
>> I question might be, why you want to do that? GnuTLS tries to hide that
>> by providing high level functions to manage certificates and keys.
> 
> I'm trying to use GnuTLS for the MS RDP protocol which both have a TLS
> mode and a homebrew mode where certificates and rc4 and md5 and sha and
> RSA is used in a different way.
> 
> I'm obviously trying to use GnuTLS for something it wasn't intended for.
> I assume that the new crypto.h stuff also don't have any use if GnuTLS
> is used for what it was intended to be used for through high level
> functions. Apparently PK stuff was left out from crypto.h. I wonder why
> you stopped there, but it is fair enough if that is how you want it.

If the internal API is good for you and you send me some wrappers over
that I'll include them.

regards,
Nikos




From simon at josefsson.org  Sun Jul 25 13:59:08 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 25 Jul 2010 13:59:08 +0200
Subject: GnuTLS 2.10.1 released
Message-ID: <87d3ub7oxf.fsf@mocca.josefsson.org>

We are proud to announce a new stable GnuTLS release: Version 2.10.1.

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
library (which contains TLS/IA support, LZO compression and Libgcrypt
FIPS-mode handler), the OpenSSL compatibility library, the self tests
and the command line tools are all distributed under the GNU General
Public License version 3.0 (or later).  The manual is distributed
under the GNU Free Documentation License version 1.3 (or later).

The project page of the library is available at:
  http://www.gnu.org/software/gnutls/

What's New
==========

** libgnutls: Added support for broken certificates that indicate RSA
with strange OIDs.

** gnutls-cli: Allow verification using V1 CAs.

** libgnutls: gnutls_x509_privkey_import() will fallback to
gnutls_x509_privkey_import_pkcs8() without a password, if it
is unable to decode the key.

** libgnutls: Correctly deinitialize crypto API functions to prevent
a memory leak. Reported by Mads Kiilerich.

** certtool: If asked to generate DSA keys of size more than 1024 bits,
issue a warning, that the output key might not be working everywhere.

** certtool: The --pkcs-cipher is taken into account when generating a
private key. The default cipher used now is aes-128. The old behavior can
be simulated by specifying "--pkcs-cipher 3des-pkcs12".

** API and ABI modifications:
No changes since last version.

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (7.2MB):

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.1.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.1.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.1.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.1.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.10.1.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2011-03-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <jas at extundo.com>
uid                  Simon Josefsson <simon at josefsson.org>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

507ff8ad7c1e042f8ecaa4314f32777e74caf0d3  gnutls-2.10.1.tar.bz2

4024b69acc70cb7e105742f8ad26bf68b7dc0e07657efbbaaf23d0bd  gnutls-2.10.1.tar.bz2

Documentation
=============

The manual is available online at:

  http://www.gnu.org/software/gnutls/documentation.html

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  HTML: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html
  PDF: http://www.gnu.org/software/gnutls/reference/gnutls.pdf

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

  http://lists.gnu.org/mailman/listinfo/help-gnutls

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:

  http://lists.gnu.org/mailman/listinfo/gnutls-devel

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer
contains libgpg-error v1.8, libgcrypt v1.4.6, libtasn1 v2.7, and
GnuTLS v2.10.1.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.10.1.exe (17MB)
  http://josefsson.org/gnutls4win/gnutls-2.10.1.exe.sig

The checksum values for SHA-1 and SHA-224 are:

f4f0c86ef9761c65941fc53713d17938ac450b3c  gnutls-2.10.1.exe

cd2f69c8e271e26187cb3e64dc179df5f28e8d1b7e5f9d97a7e222fc  gnutls-2.10.1.exe

A ZIP archive containing the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.10.1.zip (5.6MB)
  http://josefsson.org/gnutls4win/gnutls-2.10.1.zip.sig

A Debian mingw32 package is also available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.7.10-1_all.deb (5.0MB)

The checksum values for SHA-1 and SHA-224 are:

fb6dbcabe30010e761c47589ef86869fb21f82be  gnutls-2.10.1.zip

3a2b2457836dca9e1f8af86101d9a434a966abc544db1493c22797e4  gnutls-2.10.1.zip

0ff1c0c1ded86a5054dd7bcd7b29629afe3169a9  mingw32-gnutls_2.10.1-1_all.deb

066502f2fae542e6c80433090070ef46f02e5a71c80ca4f53b450ac9  mingw32-gnutls_2.10.1-1_all.deb

Internationalization
====================

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Italian, Malay, Polish, Simplified Chinese, Swedish,
and Vietnamese.  We welcome the addition of more translations.

Support
=======

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

The GnuTLS service directory is available at:

  http://www.gnu.org/software/gnutls/commercial.html

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 420 bytes
Desc: not available
URL: </pipermail/attachments/20100725/444650af/attachment.pgp>

From mads at kiilerich.com  Mon Jul 26 01:52:58 2010
From: mads at kiilerich.com (Mads Kiilerich)
Date: Mon, 26 Jul 2010 01:52:58 +0200
Subject: Raw RSA encryption
In-Reply-To: <4C4AACF1.9010409@gnutls.org>
References: <4C4A3CD6.9020304@kiilerich.com> <4C4AACF1.9010409@gnutls.org>
Message-ID: <4C4CCE5A.9060000@kiilerich.com>

  Nikos Mavrogiannopoulos wrote, On 07/24/2010 11:05 AM:
> On 07/24/2010 03:07 AM, Mads Kiilerich wrote:
>> (In either case it seems like I need to figure out how the simple
>> bigendian format of gnutls_datum_t from gnutls_x509_crt_get_pk_rsa_raw
>> relates to bigint_t?)
> The gnutls_datum_t contains the big integer in an unsigned format that
> is importable by almost all crypto libraries (and thus libgcrypt). The
> bigint_t is the gnutls crypto library's internal representation of that.

Is it correct that there is no simple way to create a 
gnutls_pk_params_st ? gnutls_pk_params_init and gnutls_pk_params_release 
is all there is?

gnutls_rsa_params_t and gnutls_x509_privkey_t seems to be very similar 
to gnutls_pk_params_st, but the types seems be held very separate with 
no simple conversions?

It seems like it could be nice to use something like a cousin of 
gnutls_rsa_params_import_raw. Or how could you imagine that 
gnutls_pk_params_st based RSA keys could be handled?

/Mads



From nredden at ccinet.us  Mon Jul 26 02:57:36 2010
From: nredden at ccinet.us (Nathan Redden)
Date: Mon, 26 Jul 2010 00:57:36 +0000
Subject: TLS_RSA_NULL_MD5
Message-ID: <W569617498321001280105856@webmail39>

I have been implementing a TLS 1.2 implementation using the GnuTLS library. I have a requirement to be able to use no data encryption. The cipher suite TLS_RSA_NULL_MD5 is listed in the supported cipher suites, but I cannot figure out how to force GnuTLS to only negotiate this. I have tried all of the Common keywords and eliminated all ciphers and starting from NONE adding in the key exchange, compression, and MAC. I have tried compatibility mode as well.

The handshake will either negotiate a cipher suite with a cipher or fail, I cannot determine a method to force TLS_RSA_NULL_MD5 to be selected.

Thanks for the help,
Nathan Redden
Application Developer
Convergent Communications Inc (CCI)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100726/5cbd37de/attachment.htm>

From nmav at gnutls.org  Mon Jul 26 12:11:40 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 26 Jul 2010 12:11:40 +0200
Subject: TLS_RSA_NULL_MD5
In-Reply-To: <W569617498321001280105856@webmail39>
References: <W569617498321001280105856@webmail39>
Message-ID: <AANLkTimvaEDHvQOLDSTn8+v10jwM_A56=yDmveeLaPSk@mail.gmail.com>

On Mon, Jul 26, 2010 at 2:57 AM, Nathan Redden <nredden at ccinet.us> wrote:
>
> I have been implementing a TLS 1.2 implementation using the GnuTLS library.? I have a requirement to be able to use no data encryption.? The cipher suite
> TLS_RSA_NULL_MD5 is listed in the supported cipher suites, but I cannot figure out how to force GnuTLS to only negotiate this.? I have tried all of the?Common keywords?and
> eliminated all ciphers and starting from NONE adding in the key exchange, compression, and MAC.? I have tried compatibility mode as well.

You must have been the first one using this ciphersuite. It never
seemed to work. To get it apply the attached patch, and verify it
using the priority string
"NONE:+RSA:+MD5:+NULL:+VERS-TLS1.0:+COMP-NULL".

regards,
Nikos
-------------- next part --------------
diff -ur gnutls-2.11.0.orig/lib/gnutls_algorithms.c gnutls-2.11.0/lib/gnutls_algorithms.c
--- gnutls-2.11.0.orig/lib/gnutls_algorithms.c	2010-07-21 09:16:07.000000000 +0200
+++ gnutls-2.11.0/lib/gnutls_algorithms.c	2010-07-26 12:07:08.000000000 +0200
@@ -236,7 +236,7 @@
   {"SHA512", HASH_OID_SHA512, GNUTLS_MAC_SHA512, 64},
   {"MD2", HASH_OID_MD2, GNUTLS_MAC_MD2, 0},	/* not used as MAC */
   {"RIPEMD160", HASH_OID_RMD160, GNUTLS_MAC_RMD160, 20},
-  {"NULL", NULL, GNUTLS_MAC_NULL, 0},
+  {"MAC-NULL", NULL, GNUTLS_MAC_NULL, 0},
   {0, 0, 0, 0}
 };
 

From nredden at ccinet.us  Mon Jul 26 17:02:51 2010
From: nredden at ccinet.us (Nathan Redden)
Date: Mon, 26 Jul 2010 15:02:51 +0000
Subject: TLS_RSA_NULL_MD5
Message-ID: <W558422796941511280156571@webmail33>

Thank you for your quick response to this problem, but I do not know how to build the library in Windows. I am building a cross-platform library for Windows and Linux, (which is one of the reasons GnuTLS was chosen), and have started on the Windows side. I did not build the Windows libraries, I just downloaded and installed the pre-built binaries. 

I looked at the instructions on the download page, but I do not have a 'make' program installed with Visual Studio 2008 which I am currently using. I tried to substitute the 'nmake', but it did not work. Can you send me instructions on what compiler you are using and how to build under Windows? 

Thanks again,
Nathan Redden
-----Original Message-----
From: Nikos Mavrogiannopoulos [mailto:nmav at gnutls.org]
Sent: Monday, July 26, 2010 06:11 AM
To: 'Nathan Redden'
Cc: help-gnutls at gnu.org
Subject: Re: TLS_RSA_NULL_MD5

On Mon, Jul 26, 2010 at 2:57 AM, Nathan Redden wrote: > > I have been implementing a TLS 1.2 implementation using the GnuTLS library. I have a requirement to be able to use no data encryption. The cipher suite > TLS_RSA_NULL_MD5 is listed in the supported cipher suites, but I cannot figure out how to force GnuTLS to only negotiate this. I have tried all of the Common keywords and > eliminated all ciphers and starting from NONE adding in the key exchange, compression, and MAC. I have tried compatibility mode as well. You must have been the first one using this ciphersuite. It never seemed to work. To get it apply the attached patch, and verify it using the priority string "NONE:+RSA:+MD5:+NULL:+VERS-TLS1.0:+COMP-NULL". regards, Nikos 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100726/66d2457a/attachment.htm>

From nmav at gnutls.org  Mon Jul 26 22:36:43 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 26 Jul 2010 22:36:43 +0200
Subject: TLS_RSA_NULL_MD5
In-Reply-To: <W558422796941511280156571@webmail33>
References: <W558422796941511280156571@webmail33>
Message-ID: <4C4DF1DB.30105@gnutls.org>

On 07/26/2010 05:02 PM, Nathan Redden wrote:
> Thank you for your quick response to this problem, but I do not know how to build the library in Windows. I am building a cross-platform library for Windows and Linux, (which is one of the reasons GnuTLS was chosen), and have started on the Windows side. I did not build the Windows libraries, I just downloaded and installed the pre-built binaries. 
> 
> I looked at the instructions on the download page, but I do not have a 'make' program installed with Visual Studio 2008 which I am currently using. I tried to substitute the 'nmake', but it did not work. Can you send me instructions on what compiler you are using and how to build under Windows? 

There is this site with instructions on how to build on windows:
http://josefsson.org/gnutls4win/

or you can just wait for the next bugfix release.

regards,
Nikos