From dbreiser at gmail.com Sat Nov 3 02:02:34 2007 From: dbreiser at gmail.com (David Reiser) Date: Fri, 2 Nov 2007 21:02:34 -0400 Subject: [Help-gnutls] gnutls 1.6.3, Mac os x 10.4.10, and https connection Message-ID: <69812df90711021802w2dfe2171ue3f6d3688a54687c@mail.gmail.com> I'm hoping someone can recognize this behavior without the normal amount of detail -- since I don't know how to supply more at the moment. A utility I use (aqbanking and gwenhywfar) is switching from openssl to gnutls. The new version works on Linux, but not on macs. The behavior I'm seeing in wireshark logs is that my mac is sending a TCP FIN immediately after sending the Client Hello. Then it responds with RST to the server's Server Hello and attempts to establish handshaking. Naturally, I never complete a connection under these conditions. The wireshark logs also indicate that I'm sending Client Hello using SSL. Under the gwenhywfar that uses openssl, the Client Hello is sent using SSLv2. Remember, though, that the new stuff works on Linux. Does anyone have either troubleshooting advice or a fix? Thanks. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbreiser at gmail.com Sat Nov 3 02:04:22 2007 From: dbreiser at gmail.com (David Reiser) Date: Fri, 2 Nov 2007 21:04:22 -0400 Subject: [Help-gnutls] compiling gnutls 2.0.2 on Mac OS X 10.4.10 Message-ID: <69812df90711021804n2321f3dbwf8b11712ee8df0b6@mail.gmail.com> When I try to compile gnutls 2.0.2 on my mac, the build fails with: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lgl -I../lgl -I../lib -I../includes -I../includes -I../lib/minitasn1 -I./openpgp -I/sw/include -I/sw/include -I/sw/include -I./opencdk -I/sw/include -D_REENTRANT -D_THREAD_SAFE -I/sw/include -I/sw/include -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -c gnutls_openpgp.c -fno-common -DPIC -o .libs/gnutls_openpgp.o gnutls_openpgp.c: In function 'kbx_to_keydb': gnutls_openpgp.c:151: warning: implicit declaration of function 'cdk_keydb_new_from_file' gnutls_openpgp.c:155: warning: implicit declaration of function 'cdk_keydb_new_from_mem' gnutls_openpgp.c: In function 'openpgp_pk_to_gnutls_cert': gnutls_openpgp.c:264: error: 'CDK_KEY_USG_SIGN' undeclared (first use in this function) gnutls_openpgp.c:264: error: (Each undeclared identifier is reported only once gnutls_openpgp.c:264: error: for each function it appears in.) gnutls_openpgp.c:266: error: 'CDK_KEY_USG_ENCR' undeclared (first use in this function) gnutls_openpgp.c:282: warning: passing argument 4 of 'cdk_pk_get_mpi' makes pointer from integer without a cast gnutls_openpgp.c:282: error: too many arguments to function 'cdk_pk_get_mpi' gnutls_openpgp.c: In function '_gnutls_openpgp_raw_privkey_to_gkey': gnutls_openpgp.c:327: warning: implicit declaration of function 'cdk_stream_tmp_new' gnutls_openpgp.c:366: warning: passing argument 4 of 'cdk_pk_get_mpi' makes pointer from integer without a cast gnutls_openpgp.c:366: error: too many arguments to function 'cdk_pk_get_mpi' gnutls_openpgp.c:380: warning: passing argument 4 of 'cdk_sk_get_mpi' makes pointer from integer without a cast gnutls_openpgp.c:380: error: too many arguments to function 'cdk_sk_get_mpi' gnutls_openpgp.c: In function 'gnutls_openpgp_get_key': gnutls_openpgp.c:511: warning: implicit declaration of function 'cdk_kbnode_write_to_mem_alloc' gnutls_openpgp.c: In function 'gnutls_certificate_set_openpgp_key_mem': gnutls_openpgp.c:582: error: too many arguments to function 'cdk_stream_tmp_from_mem' gnutls_openpgp.c:582: warning: assignment makes integer from pointer without a cast gnutls_openpgp.c:675: error: too many arguments to function 'cdk_stream_tmp_from_mem' gnutls_openpgp.c:675: warning: assignment makes integer from pointer without a cast gnutls_openpgp.c: In function 'gnutls_certificate_set_openpgp_keyring_mem': gnutls_openpgp.c:952: error: too many arguments to function 'cdk_stream_tmp_from_mem' gnutls_openpgp.c:952: warning: assignment makes integer from pointer without a cast make[3]: *** [gnutls_openpgp.lo] Error 1 Is this a bug, or am I missing a dependency? Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Sat Nov 3 08:35:00 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 3 Nov 2007 09:35:00 +0200 Subject: [Help-gnutls] compiling gnutls 2.0.2 on Mac OS X 10.4.10 In-Reply-To: <69812df90711021804n2321f3dbwf8b11712ee8df0b6@mail.gmail.com> References: <69812df90711021804n2321f3dbwf8b11712ee8df0b6@mail.gmail.com> Message-ID: <200711030935.00988.nmav@gnutls.org> On Saturday 03 November 2007, David Reiser wrote: > When I try to compile gnutls 2.0.2 on my mac, the build fails with: > gnutls_openpgp.c:675: error: too many arguments to function > 'cdk_stream_tmp_from_mem' > gnutls_openpgp.c:675: warning: assignment makes integer from pointer > without a cast > gnutls_openpgp.c: In function 'gnutls_certificate_set_openpgp_keyring_mem': > gnutls_openpgp.c:952: error: too many arguments to function > 'cdk_stream_tmp_from_mem' > gnutls_openpgp.c:952: warning: assignment makes integer from pointer > without a cast > make[3]: *** [gnutls_openpgp.lo] Error 1 > > > Is this a bug, or am I missing a dependency? It seems you're missing opencdk or you have an old version of it. Try the latest (0.6.5). regards, Nikos From cibyr at cibyr.com Sun Nov 4 11:48:47 2007 From: cibyr at cibyr.com (Ian Cullinan) Date: Sun, 4 Nov 2007 20:48:47 +1000 Subject: [Help-gnutls] GnuTLS and Qt Message-ID: I'm trying to get to grips with GnuTLS and Qt, so what I'm doing is building a very simple "chat" program. I've defined: extern "C" int gcry_qthread_init() { return 0; } extern "C" int gcry_qmutex_init(void** priv) { *priv = (void*)(new QMutex()); return 0; } extern "C" int gcry_qmutex_destroy(void** priv) { delete (QMutex*)(*priv); return 0; } extern "C" int gcry_qmutex_lock(void** priv) { ((QMutex*)(*priv))->lock(); return 0; } extern "C" int gcry_qmutex_unlock(void** priv) { ((QMutex*)(*priv))->unlock(); return 0; } struct gcry_thread_cbs gcry_threads_qt = { GCRY_THREAD_OPTION_USER, gcry_qthread_init, gcry_qmutex_init, gcry_qmutex_destroy, gcry_qmutex_lock, gcry_qmutex_unlock, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL}; and I'm calling gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_qt); gnutls_global_init(); from the constructor of my main window. Which leads me to my first question(s): do I need to do that? Or does it not really matter, even though Qt make pretty heavy use of threads? Have I done something wrong there? Should I be providing something for the select, waitpid, accept, etc parts of that struct? Then, I've defined: extern "C" ssize_t gnutls_qt_pull(gnutls_transport_ptr_t transPtr, void* buf, size_t len) { QTcpSocket* sock = (QTcpSocket*)transPtr; int ret = sock->read((char*)buf, (qint64)len); if (ret == -1) { cerr << "ERROR: " << sock->errorString().toStdString() << endl; } return ret; } extern "C" ssize_t gnutls_qt_push(gnutls_transport_ptr_t transPtr, const void* data, size_t len) { QTcpSocket* sock = (QTcpSocket*)transPtr; int ret = sock->write((const char*)data, (qint64)len); if (ret == -1) { cerr << "ERROR: " << sock->errorString().toStdString() << endl; } return ret; } When my "listen" button is clicked I do: gnutls_anon_allocate_server_credentials(&servercred); gnutls_dh_params_init(&dh_params); gnutls_dh_params_generate2(dh_params, DH_BITS); gnutls_anon_set_server_dh_params(servercred, dh_params); tcpServer = new QTcpServer(this); if (!tcpServer->listen(QHostAddress::Any, (quint16)ui.listenPortSpinBox->value())) { QMessageBox::critical(this, "Error listening", tcpServer->errorString()); delete tcpServer; return; } connect(tcpServer, SIGNAL(newConnection()), this, SLOT(handleNewConnection())); So on an incoming connection, handleNewConnection() gets called. void tls_chat::handleNewConnection() { QTcpSocket* tcpSocket = tcpServer->nextPendingConnection(); gnutls_session_t session; const int kx_prio[] = { GNUTLS_KX_ANON_DH, 0 }; gnutls_init(&session, GNUTLS_SERVER); gnutls_set_default_priority(session); gnutls_kx_set_priority(session, kx_prio); gnutls_credentials_set(session, GNUTLS_CRD_ANON, servercred); gnutls_dh_set_prime_bits(session, DH_BITS); gnutls_transport_set_ptr(session, (gnutls_transport_ptr_t)tcpSocket); gnutls_transport_set_pull_function(session, gnutls_qt_pull); gnutls_transport_set_push_function(session, gnutls_qt_push); int ret; do { ret = gnutls_handshake(session); } while (ret == GNUTLS_E_AGAIN); if(ret < 0) { QMessageBox::critical(this, "Error", QString("TLS Handshake failed with error: ") + QString(gnutls_strerror(ret)), QMessageBox::Ok, QMessageBox::NoButton); gnutls_bye(session, GNUTLS_SHUT_RDWR); tcpSocket->close(); gnutls_deinit(session); delete tcpSocket; return; } chatWindow* window = new chatWindow(tcpSocket, session); window->show(); } On any incoming connection (from my own code, or form gnutls-cli, I get "A TLS packet with unexpected length was received." Nothing appears in my console, so I don't think QTcpSocket is giving errors. What am I missing here? I've copied the "Echo Server with Anonymous Authentication" example almost exactly. Am I taking the right approach by wrapping QMutex and QTcpSocket? I'd really appreciate any help or advice, so thanks in advance and apologies for this long, code-heavy message. If it helps any, I'm on windows XP with gnutls 2.0.2, Qt 4.3.2 and MinGW 5.1.3 Cheers, Ian Cullinan From nmav at gnutls.org Sun Nov 4 13:28:13 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 4 Nov 2007 14:28:13 +0200 Subject: [Help-gnutls] GnuTLS and Qt In-Reply-To: References: Message-ID: <200711041428.13755.nmav@gnutls.org> On Sunday 04 November 2007, Ian Cullinan wrote: > I'm trying to get to grips with GnuTLS and Qt, so what I'm doing is > building a very simple "chat" program. I've defined: [...] > struct gcry_thread_cbs gcry_threads_qt = { > GCRY_THREAD_OPTION_USER, gcry_qthread_init, gcry_qmutex_init, > gcry_qmutex_destroy, gcry_qmutex_lock, gcry_qmutex_unlock, > NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL}; These should be sufficient to allow exclusive access to the random number generator. > and I'm calling > gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_qt); > gnutls_global_init(); > from the constructor of my main window. Which leads me to my first > question(s): do I need to do that? Or does it not really matter, even > though Qt make pretty heavy use of threads? Have I done something > wrong there? Should I be providing something for the select, waitpid, > accept, etc parts of that struct? No. > On any incoming connection (from my own code, or form gnutls-cli, I > get "A TLS packet with unexpected length was received." Nothing > appears in my console, so I don't think QTcpSocket is giving errors. > What am I missing here? I've copied the "Echo Server with Anonymous > Authentication" example almost exactly. Am I taking the right approach > by wrapping QMutex and QTcpSocket? A way to debug this would be by checking the TLS packets exchanged using wireshark (ethereal) or ssldump. You should also enable the gnutls debugging options using gnutls_global_set_log_function() and gnutls_global_set_log_level() to see where this error occured. regards, Nikos From martine at danga.com Sun Nov 4 22:29:08 2007 From: martine at danga.com (Evan Martin) Date: Sun, 4 Nov 2007 13:29:08 -0800 Subject: [Help-gnutls] unable to get gnutls-serv and -cli to communicate Message-ID: <3a6f89fc0711041329s5c3301dem93ad989e4572fbe@mail.gmail.com> I'm trying to get a simple case of gnutls-serv and -cli communicating with an x509 cert, but it's failing. Following the examples in the "invoking certtool" section of the manual, I created a private key and cert: $ certtool --generate-privkey --outfile priv $ head -1 priv -----BEGIN RSA PRIVATE KEY----- $ certtool --generate-self-signed --load-privkey priv --outfile cert [...many questions here, maybe I answered some wrong?...] $ head -1 cert -----BEGIN CERTIFICATE----- Then I ran gnutls-serv with this and tried to connect with gnutls-cli-debug: $ gnutls-serv --x509keyfile priv --x509certfile cert Echo Server ready. Listening to port '5556'. [and in another window] $ gnutls-cli-debug -p 5556 localhost Resolving 'localhost'... Connecting to '127.0.0.1:5556'... Checking for TLS 1.1 support... no Checking fallback from TLS 1.1 to... failed Checking for TLS 1.0 support... no Checking for SSL 3.0 support... no Server does not support none of SSL 3.0, TLS 1.0 and TLS 1.1 The server says: Error in handshake Error: The request is invalid. I found an old mailing list thread that suggested generating DH params could help: $ certtool --generate-dh-params > dh $ gnutls-serv --dhparams dh --x509keyfile priv --x509certfile cert But it didn't. What am I doing wrong? I also tried the debug flags but they didn't print anything I understood. In case it matters: $ dpkg -s gnutls-bin | grep Version Version: 1.6.3-1build1 (PS: I last mailed this list regarding an unrelated gnutls/Windows problem and Simon asked me to try something and report; since then I've lost my Windows machine and haven't yet been able to see if it worked.) From cibyr at cibyr.com Mon Nov 5 09:13:15 2007 From: cibyr at cibyr.com (Ian Cullinan) Date: Mon, 5 Nov 2007 18:13:15 +1000 Subject: Fwd: [Help-gnutls] GnuTLS and Qt In-Reply-To: References: <200711041428.13755.nmav@gnutls.org> Message-ID: Thank you very much, that helped a lot. The fix: extern "C" ssize_t gnutls_qt_pull(gnutls_transport_ptr_t transPtr, void* buf, size_t len) { QTcpSocket* sock = (QTcpSocket*)transPtr; if (!sock->bytesAvailable()) { if (!sock->waitForReadyRead(-1)) { cerr << "PULL ERROR: (waiting for read) " << sock->errorString().toStdString() << endl; } } int ret = sock->read((char*)buf, (qint64)len); if (ret == -1) { cerr << "PULL ERROR: " << sock->errorString().toStdString() << endl; } return ret; } extern "C" ssize_t gnutls_qt_push(gnutls_transport_ptr_t transPtr, const void* data, size_t len) { QTcpSocket* sock = (QTcpSocket*)transPtr; int ret = sock->write((const char*)data, (qint64)len); if (ret == -1 || (sock->bytesToWrite() && !sock->waitForBytesWritten(-1))) { cerr << "PUSH ERROR: " << sock->errorString().toStdString() << endl; } return ret; } Having non-infinite timeouts, and modular error reporting/logging would probably be a good idea as well, but I'll probably write a class that actually does things properly later on. The cool thing is this should work that Qt and GnuTLS do, without any #ifdef messiness :) Cheers, Ian PS. And here's me silly enough not to send this to the group. From bortzmeyer at nic.fr Mon Nov 5 12:00:04 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 5 Nov 2007 12:00:04 +0100 Subject: [Help-gnutls] RFC 5081 on Using OpenPGP Keys for Transport Layer Security (TLS) Authentication Message-ID: <20071105110004.GA11165@nic.fr> Congratulations to the author, TLS with PGP is now a RFC document. As far as I know, only GnuTLS implements this RFC? -------------- next part -------------- An embedded message was scrubbed... From: rfc-editor at rfc-editor.org Subject: RFC 5081 on Using OpenPGP Keys for Transport Layer Security (TLS) Authentication Date: Fri, 2 Nov 2007 18:29:58 -0700 (PDT) Size: 5859 URL: From nmav at gnutls.org Mon Nov 5 20:11:36 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 5 Nov 2007 21:11:36 +0200 Subject: [Help-gnutls] RFC 5081 on Using OpenPGP Keys for Transport Layer Security (TLS) Authentication In-Reply-To: <20071105110004.GA11165@nic.fr> References: <20071105110004.GA11165@nic.fr> Message-ID: <200711052111.36961.nmav@gnutls.org> On Monday 05 November 2007, Stephane Bortzmeyer wrote: > Congratulations to the author, TLS with PGP is now a RFC document. > As far as I know, only GnuTLS implements this RFC? I'm also not aware of other implementations. We plan to have a fully-working and supported implementation for the gnutls 2.2 release[0]. If there are people interested in implementing this technology, I'd suggest to use gnutls-2.1.5 and later versions. There are cleanups and updates to conform to the latest document. regards, Nikos [0]. The code is already there but more testing is required. From pavan.puri at gmail.com Thu Nov 8 08:12:23 2007 From: pavan.puri at gmail.com (Pavan Puri) Date: Thu, 8 Nov 2007 12:42:23 +0530 Subject: [Help-gnutls] Large Data Support through Gnu TLS Message-ID: <8d1c6bc90711072312s304ff433i41c433b5de07ae2e@mail.gmail.com> Hi, We are trying to send large (upto 2 MB) through gnu TLS using the API gnutls_record_send(). This API is failing to send data over 16384 bytes. We have also tried using API gnutls_record_set_max_size() but tjis API is also failing to increase data size over 16Kb approx. Please let us know how can we configure to send/receive large data through Gnu TLS session. Best Regards Pavan From fweimer at bfk.de Thu Nov 8 12:07:28 2007 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 08 Nov 2007 12:07:28 +0100 Subject: [Help-gnutls] Large Data Support through Gnu TLS In-Reply-To: <8d1c6bc90711072312s304ff433i41c433b5de07ae2e@mail.gmail.com> (Pavan Puri's message of "Thu, 8 Nov 2007 12:42:23 +0530") References: <8d1c6bc90711072312s304ff433i41c433b5de07ae2e@mail.gmail.com> Message-ID: <824pfxgfm7.fsf@mid.bfk.de> * Pavan Puri: > We are trying to send large (upto 2 MB) through gnu TLS using the API > gnutls_record_send(). > This API is failing to send data over 16384 bytes. You need to check the return value and keep sending the remaining part of the buffer in a loop, just like you would do when you use write() or send() on a TCP socket. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From martine at danga.com Sat Nov 10 19:08:31 2007 From: martine at danga.com (Evan Martin) Date: Sat, 10 Nov 2007 10:08:31 -0800 Subject: [Help-gnutls] Re: unable to get gnutls-serv and -cli to communicate In-Reply-To: <3a6f89fc0711041329s5c3301dem93ad989e4572fbe@mail.gmail.com> References: <3a6f89fc0711041329s5c3301dem93ad989e4572fbe@mail.gmail.com> Message-ID: <3a6f89fc0711101008i1280664ejef4fd77bd102ae43@mail.gmail.com> On Nov 4, 2007 1:29 PM, Evan Martin wrote: > I'm trying to get a simple case of gnutls-serv and -cli communicating > with an x509 cert, but it's failing. For future readers of the list: I figured this out. I think my problem was a combination of the wrong cert settings and not using DH params. I've amended my notes below. > Following the examples in the "invoking certtool" section of the > manual, I created a private key and cert: > $ certtool --generate-privkey --outfile priv > $ head -1 priv > -----BEGIN RSA PRIVATE KEY----- > $ certtool --generate-self-signed --load-privkey priv --outfile cert You can just hit enter (answering "no") to every question except the cert lifetime (how many days) as well as "Will the certificate be used for signing (required for TLS)? (Y/N)", to which you obviously answer yes. > $ head -1 cert > -----BEGIN CERTIFICATE----- This is now enough to make communcation work if you use those files with "openssl s_server". However, for gnutls-serv, you also need Diffie-Hellman params. You can either generate those with "certtool --generate-dh-params" and load them with "gnutls-serv --dhparams", or just run gnutls-serv with "--generate" to generate them. > In case it matters: > $ dpkg -s gnutls-bin | grep Version > Version: 1.6.3-1build1 From simon at josefsson.org Sat Nov 10 19:47:57 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 10 Nov 2007 19:47:57 +0100 Subject: [Help-gnutls] GnuTLS 2.0.3 Message-ID: <87ode2ueci.fsf@mocca.josefsson.org> We are pleased to announce a new stable GnuTLS release: Version 2.0.3. GnuTLS is a modern C library that implement 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 core GnuTLS library is distribute under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS libraries -- which contains OpenPGP and TLS/IA support, LZO2 compression, the OpenSSL compatibility library -- and the self tests and command line tools are distributed under the GNU General Public License version 2.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ What's New ========== The following changes have been made since GnuTLS 2.0.2: ** This version backports several fixes from the 2.1.x branch. ** Fixed PKCS #3 parameter export. ** Added gnutls_record_disable_padding() to allow servers talking to buggy clients that complain if the TLS 1.0 record protocol padding is used. ** Introduced gnutls_session_enable_compatibility_mode() to allow enabling all supported compatibility options (like disabling padding). ** Corrected bug which did not allow a server to run without supporting certificates. ** API and ABI modifications: gnutls_session_enable_compatibility_mode: ADDED gnutls_record_disable_padding: ADDED Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Note, that GnuPG is not available at ftp.gnu.org. Here are the BZIP2 compressed sources (4.7MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.3.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.0.3.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.3.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-2.0.3.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.0.3.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: 2008-06-30] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2008-06-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: e329e30f7f80ee905809012cad132eab8f6e9a87 gnutls-2.0.3.tar.bz2 bafea053cee216ac67e83a5a1e9c7a66a384d49b022fa2c5726484ef gnutls-2.0.3.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: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: . 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 consists of libgpg-error 1.5, libgcrypt 1.3.0, libtasn1 1.1, opencdk 0.6.4, and GnuTLS 2.0.2. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ Internationalization ==================== GnuTLS messages have been translated into German, Malay, Polish and Swedish. 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, 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: 419 bytes Desc: not available URL: From pavan.puri at gmail.com Mon Nov 12 06:43:38 2007 From: pavan.puri at gmail.com (Pavan Puri) Date: Mon, 12 Nov 2007 11:13:38 +0530 Subject: [Help-gnutls] Large Data Support through Gnu TLS In-Reply-To: <824pfxgfm7.fsf@mid.bfk.de> References: <8d1c6bc90711072312s304ff433i41c433b5de07ae2e@mail.gmail.com> <824pfxgfm7.fsf@mid.bfk.de> Message-ID: <8d1c6bc90711112143u1464eed4kb1b176326e2b5e8f@mail.gmail.com> Hi Florian, Thanks for the quick reply. Is there some kind of configurable option like blocking send in tls using which we can configure tls session to send whole data in loop (and return failure on permanent error). "If the socket does not have enough buffer space available to hold the message being sent, send() blocks, unless the socket has been placed in non-blocking I/O mode." Best Regards Pavan On 11/8/07, Florian Weimer wrote: > * Pavan Puri: > > > We are trying to send large (upto 2 MB) through gnu TLS using the API > > gnutls_record_send(). > > This API is failing to send data over 16384 bytes. > > You need to check the return value and keep sending the remaining part > of the buffer in a loop, just like you would do when you use write() > or send() on a TCP socket. > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > From fweimer at bfk.de Mon Nov 12 10:20:02 2007 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 12 Nov 2007 10:20:02 +0100 Subject: [Help-gnutls] Large Data Support through Gnu TLS In-Reply-To: <8d1c6bc90711112143u1464eed4kb1b176326e2b5e8f@mail.gmail.com> (Pavan Puri's message of "Mon, 12 Nov 2007 11:13:38 +0530") References: <8d1c6bc90711072312s304ff433i41c433b5de07ae2e@mail.gmail.com> <824pfxgfm7.fsf@mid.bfk.de> <8d1c6bc90711112143u1464eed4kb1b176326e2b5e8f@mail.gmail.com> Message-ID: <82y7d3akhp.fsf@mid.bfk.de> * Pavan Puri: > Is there some kind of configurable option like blocking send in tls > using which we can configure tls session to send whole data in loop > (and return failure on permanent error). You just need to wrap the call in a loop, like you do with write() or send(). > "If the socket does not have enough buffer space available to > hold the message being sent, send() blocks, unless the > socket has been placed in non-blocking I/O mode." Where did you get this information? It is incorrect. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pavan.puri at gmail.com Tue Nov 13 07:12:53 2007 From: pavan.puri at gmail.com (Pavan Puri) Date: Tue, 13 Nov 2007 11:42:53 +0530 Subject: [Help-gnutls] Large Data Support through Gnu TLS In-Reply-To: <82y7d3akhp.fsf@mid.bfk.de> References: <8d1c6bc90711072312s304ff433i41c433b5de07ae2e@mail.gmail.com> <824pfxgfm7.fsf@mid.bfk.de> <8d1c6bc90711112143u1464eed4kb1b176326e2b5e8f@mail.gmail.com> <82y7d3akhp.fsf@mid.bfk.de> Message-ID: <8d1c6bc90711122212k70eca1b4m2b51187c8f342511@mail.gmail.com> Hi Florian, I got this information from man page of send() command on Linux and Solaris Machines. We have even tested/verified this by sending data of size upto 1.6 MB using TCP send(). Best Regards Pavan On 11/12/07, Florian Weimer wrote: > * Pavan Puri: > > > Is there some kind of configurable option like blocking send in tls > > using which we can configure tls session to send whole data in loop > > (and return failure on permanent error). > > You just need to wrap the call in a loop, like you do with write() or > send(). > > > "If the socket does not have enough buffer space available to > > hold the message being sent, send() blocks, unless the > > socket has been placed in non-blocking I/O mode." > > Where did you get this information? It is incorrect. > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > From simon at josefsson.org Fri Nov 16 16:01:52 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 16 Nov 2007 16:01:52 +0100 Subject: [Help-gnutls] GnuTLS 2.0.4 Message-ID: <87wssigrof.fsf@mocca.josefsson.org> We are pleased to announce a new stable GnuTLS release: Version 2.0.4. This is a minor bug fix release. GnuTLS is a modern C library that implement 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 core GnuTLS library is distribute under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS libraries -- which contains OpenPGP and TLS/IA support, LZO2 compression, the OpenSSL compatibility library -- and the self tests and command line tools are distributed under the GNU General Public License version 2.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ What's New ========== The following changes have been made since GnuTLS 2.0.3: ** Corrected bug in decompression of expanded compression data. ** 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 . The list of mirrors can be found at . Note, that GnuPG is not available at ftp.gnu.org. Here are the BZIP2 compressed sources (4.7MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.4.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.0.4.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.4.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-2.0.4.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.0.4.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: 2008-06-30] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2008-06-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: 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: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: . 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 consists of libgpg-error 1.5, libgcrypt 1.3.0, libtasn1 1.1, opencdk 0.6.4, and GnuTLS 2.0.2. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ Internationalization ==================== GnuTLS messages have been translated into German, Malay, Polish and Swedish. 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, 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: 419 bytes Desc: not available URL: From angus at uducat.com Thu Nov 22 22:17:05 2007 From: angus at uducat.com (Angus) Date: Thu, 22 Nov 2007 16:17:05 -0500 Subject: [Help-gnutls] PGP api Message-ID: <200711221617.05278.angus@uducat.com> I need a C (or C++) API to PGP encrypt stuff. Unfortunately, I have no experience with public key encryption, and I'm having a hard time figuring out what available APIs even do this. OpenCDK looks like it might, but the documentation on it is very hard to find. Is OpenCDK what I should be using? If not, what would be, and how do I find useful documentation for it? From bradh at frogmouth.net Fri Nov 23 00:27:49 2007 From: bradh at frogmouth.net (Brad Hards) Date: Fri, 23 Nov 2007 10:27:49 +1100 Subject: [Help-gnutls] PGP api In-Reply-To: <200711221617.05278.angus@uducat.com> References: <200711221617.05278.angus@uducat.com> Message-ID: <200711231027.49890.bradh@frogmouth.net> On Friday 23 November 2007 08:17:05 am Angus wrote: > I need a C (or C++) API to PGP encrypt stuff. Unfortunately, I have no > experience with public key encryption, and I'm having a hard time figuring > out what available APIs even do this. I'm not sure what you are asking. Are you trying to do PGP with TLS? If you are just trying to encrypt a file, why not just use GPGME: http://www.gnupg.org/related_software/gpgme/ It is a library that talks to the gnupg binary over a special machine interface. There are also C++ bindings for GPGME (in the KDE SVN as part of kdepimlibs, not sure what the release state is - may not be a separate release) If you are using Qt, then QCA has PGP support (also using the gnupg binary). I guess there are commercial options too. No experience with those. Brad From michael.bell at cms.hu-berlin.de Fri Nov 23 12:03:08 2007 From: michael.bell at cms.hu-berlin.de (Michael Bell) Date: Fri, 23 Nov 2007 12:03:08 +0100 Subject: [Help-gnutls] Peer verification Message-ID: <4746B36C.6060006@cms.hu-berlin.de> Hi, I try to get a correct validation for a https server. My problem is that certtool says that everthing is find and gnutls-cli fails. Configuration: - server cert + intermediate ca + root ca - server sends only the server cert and the intermediate CA - server sends additionally several other CA certs - server does not send the root CA cert - CA file with both CA certs certtool: - certtool -e --infile /tmp/certs.pem - certs.pem contains all three certificates - certtool verifies all certs with "Verification output: Verified." gnutls-cli: - gnutls-cli --x509cafile /tmp/calist.pem kalender.cms.hu-berlin.de - tested with all certs, only the CAs and only the root in calist.pem - all certificates in calist.pem are correctly detected - all certs send by the server are correctly recognized - nevertheless "Peer's certificate is NOT trusted" Any ideas what's the problem? Browsers can verify the server correctly but perhaps the missing CA cert in the send cert list of the server is a problem. FYI I found this problem while debugging opensync/libsoup which uses gnutls. Thanks in advance Michael -- _______________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 michael.bell at cms.hu-berlin.de D-10099 Berlin _______________________________________________________________ X.509 CA Certificates / Wurzelzertifikate http://ra.pki.hu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5664 bytes Desc: S/MIME Cryptographic Signature URL: From michael.bell at cms.hu-berlin.de Fri Nov 23 14:48:52 2007 From: michael.bell at cms.hu-berlin.de (Michael Bell) Date: Fri, 23 Nov 2007 14:48:52 +0100 Subject: [Help-gnutls] Peer verification In-Reply-To: References: <4746B36C.6060006@cms.hu-berlin.de> Message-ID: <4746DA44.2090106@cms.hu-berlin.de> Nikos Mavrogiannopoulos schrieb: > Could you use the -d 3 switch to gnutls-cli and send the output? Yes, please see attachment. Best regards Michael -- _______________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 michael.bell at cms.hu-berlin.de D-10099 Berlin _______________________________________________________________ X.509 CA Certificates / Wurzelzertifikate http://ra.pki.hu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_cli.log Type: text/x-log Size: 6322 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5664 bytes Desc: S/MIME Cryptographic Signature URL: From angus at uducat.com Fri Nov 23 15:21:33 2007 From: angus at uducat.com (Angus) Date: Fri, 23 Nov 2007 09:21:33 -0500 Subject: [Help-gnutls] PGP api In-Reply-To: <200711231027.49890.bradh@frogmouth.net> References: <200711221617.05278.angus@uducat.com> <200711231027.49890.bradh@frogmouth.net> Message-ID: <200711230921.33324.angus@uducat.com> On Thursday 22 November 2007 18:27, Brad Hards wrote: > On Friday 23 November 2007 08:17:05 am Angus wrote: > > I need a C (or C++) API to PGP encrypt stuff. Unfortunately, I have no > > experience with public key encryption, and I'm having a hard time > > figuring out what available APIs even do this. > > I'm not sure what you are asking. Are you trying to do PGP with TLS? From what I can tell, OpenCDK falls under TLS, so yes. > If you are just trying to encrypt a file, why not just use GPGME: > http://www.gnupg.org/related_software/gpgme/ > It is a library that talks to the gnupg binary over a special machine > interface. I'm looking at GPGME, and it looks a little too DIY. From what I can tell, all it does is open a socket to an algorithmic backend, and pipes data to and from it--no place to insert things like public and private keys and whatever else PGP needs. From bradh at frogmouth.net Sat Nov 24 00:40:40 2007 From: bradh at frogmouth.net (Brad Hards) Date: Sat, 24 Nov 2007 10:40:40 +1100 Subject: [Help-gnutls] PGP api In-Reply-To: <200711230921.33324.angus@uducat.com> References: <200711221617.05278.angus@uducat.com> <200711231027.49890.bradh@frogmouth.net> <200711230921.33324.angus@uducat.com> Message-ID: <200711241040.41048.bradh@frogmouth.net> Sorry, I'm still not sure what you are trying to accomplish. On Saturday 24 November 2007 01:21:33 am Angus wrote: > On Thursday 22 November 2007 18:27, Brad Hards wrote: > > On Friday 23 November 2007 08:17:05 am Angus wrote: > > > I need a C (or C++) API to PGP encrypt stuff. Unfortunately, I have no > > > experience with public key encryption, and I'm having a hard time > > > figuring out what available APIs even do this. > > > > I'm not sure what you are asking. Are you trying to do PGP with TLS? > > From what I can tell, OpenCDK falls under TLS, so yes. Lets not worry about the implementation stuff just yet. When you said "PGP encrypt stuff", can you explain exactly what you are trying to do? In particular, are you trying to use PGP to authenticate a TLS connection (as described in RFC5081 - http://www.rfc-editor.org/rfc/rfc5081.txt) or are you trying to encrypt a file (as described in RFC4880, Section 3.1)? > > If you are just trying to encrypt a file, why not just use GPGME: > > http://www.gnupg.org/related_software/gpgme/ > > It is a library that talks to the gnupg binary over a special machine > > interface. > > I'm looking at GPGME, and it looks a little too DIY. From what I can tell, > all it does is open a socket to an algorithmic backend, and pipes data to > and from it--no place to insert things like public and private keys and > whatever else PGP needs. GPGME is designed to support mail user agents handled PGP encryped/signed messages. Use of it for something wildly different is going to be messy. I can't help you with a better suggestion unless you can explain what you are trying to do. Are you trying to generate the keys yourself, or do you already have them? How are you planning on transferring the private key? Are you trying to back-up, or transfer a file? More detail please. Brad From nmav at gnutls.org Sun Nov 25 10:14:25 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 25 Nov 2007 11:14:25 +0200 Subject: [Help-gnutls] Peer verification In-Reply-To: <4746B36C.6060006@cms.hu-berlin.de> References: <4746B36C.6060006@cms.hu-berlin.de> Message-ID: <200711251114.26001.nmav@gnutls.org> On Friday 23 November 2007, Michael Bell wrote: > Hi, > > I try to get a correct validation for a https server. My problem is that > certtool says that everthing is find and gnutls-cli fails. > > Configuration: > - server cert + intermediate ca + root ca > - server sends only the server cert and the intermediate CA As I can see in the output you sent me the server is sending 6 certificates and they do not form a certificate chain. In TLS a certificate chain is formed by having a list where the next certificate certifies the previous. Thus the issuer's DN in certificate [0] should be the same as the subject's DN in certificate [1] and so on. So I believe it is normal for verification to fail. regards, Nikos - Certificate[0] info: # The hostname in the certificate matches 'kalender.cms.hu-berlin.de'. # valid since: Tue Apr 10 09:56:31 CEST 2007 # expires at: Thu Apr 9 09:56:31 CEST 2009 # fingerprint: 04:6D:38:E9:AE:50:3B:FE:68:F6:A1:B7:6A:BD:35:3A # Subject's DN: C=DE,O=Humboldt-Universitaet zu Berlin,OU=Computer- und Medienservice,CN=(kalender|kalender1|kalender2).cms.hu-berlin.de # Issuer's DN: C=DE,O=Humboldt-Universitaet zu Berlin,OU=HU-CA,CN=HU-CA 4 - Certificate[1] info: # valid since: Sat Dec 1 13:11:16 CET 2001 # expires at: Sun Jan 31 13:11:16 CET 2010 # fingerprint: 3E:1F:9E:E6:4C:6E:F0:22:08:25:DA:91:23:08:05:03 # Subject's DN: C=DE,O=Deutsches Forschungsnetz,OU=DFN-CERT GmbH,OU=DFN-PCA,CN=DFN Toplevel Certification Authority,EMAIL=certify at pca.dfn.de # Issuer's DN: C=DE,O=Deutsches Forschungsnetz,OU=DFN-CERT GmbH,OU=DFN-PCA,CN=DFN Toplevel Certification Authority,EMAIL=certify at pca.dfn.de - Certificate[2] info: # valid since: Wed Dec 12 19:20:36 CET 2001 # expires at: Mon Dec 12 19:20:36 CET 2005 # fingerprint: 1E:42:77:7F:98:C7:BD:52:C5:EC:47:0A:36:5C:5E:10 # Subject's DN: C=DE,O=Humboldt-Universitaet zu Berlin,CN=HU-CA [sign only],EMAIL=hu-ca at rz.hu-berlin.de # Issuer's DN: C=DE,O=Deutsches Forschungsnetz,OU=DFN-CERT GmbH,OU=DFN-PCA,CN=DFN Toplevel Certification Authority,EMAIL=certify at pca.dfn.de - Certificate[3] info: # valid since: Mon Oct 18 16:19:09 CEST 2004 # expires at: Sat Oct 18 16:19:09 CEST 2008 # fingerprint: 44:88:A0:5E:93:12:1D:EA:56:E4:00:F6:98:87:58:A4 # Subject's DN: C=DE,O=Humboldt-Universitaet zu Berlin,OU=HU-CA,CN=HU-CA 1 # Issuer's DN: C=DE,O=Deutsches Forschungsnetz,OU=DFN-CERT GmbH,OU=DFN-PCA,CN=DFN Toplevel Certification Authority,EMAIL=certify at pca.dfn.de - Certificate[4] info: # valid since: Mon Oct 24 13:53:26 CEST 2005 # expires at: Wed Oct 24 13:53:26 CEST 2007 # fingerprint: EA:6E:02:BC:38:91:F2:47:21:9A:0E:9D:F9:E8:3A:BD # Subject's DN: C=DE,O=Humboldt-Universitaet zu Berlin,OU=HU-CA,CN=HU-DCA 3 # Issuer's DN: C=DE,O=Humboldt-Universitaet zu Berlin,OU=HU-CA,CN=HU-CA 1 - Certificate[5] info: # valid since: Wed Oct 11 16:19:18 CEST 2006 # expires at: Sun Oct 10 16:19:18 CEST 2010 # fingerprint: 41:0C:13:A7:80:BF:FC:41:A6:68:6E:41:42:E7:CD:35 # Subject's DN: C=DE,O=Humboldt-Universitaet zu Berlin,OU=HU-CA,CN=HU-CA 4 # Issuer's DN: C=DE,O=DFN-Verein,OU=DFN-PKI,CN=DFN-Verein PCA Classic - G01 From michael.bell at cms.hu-berlin.de Mon Nov 26 10:17:13 2007 From: michael.bell at cms.hu-berlin.de (Michael Bell) Date: Mon, 26 Nov 2007 10:17:13 +0100 Subject: [Help-gnutls] Peer verification In-Reply-To: <200711251114.26001.nmav@gnutls.org> References: <4746B36C.6060006@cms.hu-berlin.de> <200711251114.26001.nmav@gnutls.org> Message-ID: <474A8F19.7010606@cms.hu-berlin.de> Nikos Mavrogiannopoulos schrieb: > On Friday 23 November 2007, Michael Bell wrote: >> I try to get a correct validation for a https server. My problem is that >> certtool says that everthing is find and gnutls-cli fails. >> >> Configuration: >> - server cert + intermediate ca + root ca >> - server sends only the server cert and the intermediate CA > > As I can see in the output you sent me the server is sending 6 certificates > and they do not form a certificate chain. In TLS a certificate chain is > formed by having a list where the next certificate certifies the previous. > Thus the issuer's DN in certificate [0] should be the same as the subject's > DN in certificate [1] and so on. So I believe it is normal for verification to > fail. The server must only send its own cert. Any other information like intermediate and root CA certs are opional. The server has not to send a complete chain. Therefore the browsers have no problem with this page because they know the root CA cert and mostly the intermediate CA cert. So actually I think it's a bug in GnuTLS - especially because the other clients are able to verify the server. Nevertheless I initiated a reconfiguration of the server (luckily we control the server). Best regards Michael -- _______________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 michael.bell at cms.hu-berlin.de D-10099 Berlin _______________________________________________________________ X.509 CA Certificates / Wurzelzertifikate http://ra.pki.hu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5664 bytes Desc: S/MIME Cryptographic Signature URL: From nmav at gnutls.org Mon Nov 26 13:14:41 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 26 Nov 2007 14:14:41 +0200 Subject: [Help-gnutls] Peer verification In-Reply-To: References: <4746B36C.6060006@cms.hu-berlin.de> <200711251114.26001.nmav@gnutls.org> <474A8F19.7010606@cms.hu-berlin.de> Message-ID: On Nov 26, 2007 11:17 AM, Michael Bell wrote: > Nikos Mavrogiannopoulos schrieb: > > On Friday 23 November 2007, Michael Bell wrote: > > >> I try to get a correct validation for a https server. My problem is that > >> certtool says that everthing is find and gnutls-cli fails. > >> > >> Configuration: > >> - server cert + intermediate ca + root ca > >> - server sends only the server cert and the intermediate CA > > > > As I can see in the output you sent me the server is sending 6 certificates > > and they do not form a certificate chain. In TLS a certificate chain is > > formed by having a list where the next certificate certifies the previous. > > Thus the issuer's DN in certificate [0] should be the same as the subject's > > DN in certificate [1] and so on. So I believe it is normal for verification to > > fail. > > The server must only send its own cert. Any other information like > intermediate and root CA certs are opional. The server has not to send a > complete chain. According to which protocol? In TLS the server has to either send his certificate, or his certificate and a complete chain (see section 7.4.2 of RFC2246). > So actually I think it's a bug in GnuTLS - especially because the other > clients are able to verify the server. Nevertheless I initiated a > reconfiguration of the server (luckily we control the server). This doesn't seem to be a gnutls issue. It looks like a server misconfiguration. regards, Nikos From angus at uducat.com Mon Nov 26 15:41:53 2007 From: angus at uducat.com (Angus) Date: Mon, 26 Nov 2007 09:41:53 -0500 Subject: [Help-gnutls] PGP api In-Reply-To: <200711241040.41048.bradh@frogmouth.net> References: <200711221617.05278.angus@uducat.com> <200711230921.33324.angus@uducat.com> <200711241040.41048.bradh@frogmouth.net> Message-ID: <200711260941.53346.angus@uducat.com> On Friday 23 November 2007 18:40, Brad Hards wrote: > Sorry, I'm still not sure what you are trying to accomplish. > > On Saturday 24 November 2007 01:21:33 am Angus wrote: > > On Thursday 22 November 2007 18:27, Brad Hards wrote: > > > On Friday 23 November 2007 08:17:05 am Angus wrote: > > > > I need a C (or C++) API to PGP encrypt stuff. Unfortunately, I have > > > > no experience with public key encryption, and I'm having a hard time > > > > figuring out what available APIs even do this. > > > > > > I'm not sure what you are asking. Are you trying to do PGP with TLS? > > > > From what I can tell, OpenCDK falls under TLS, so yes. > > Lets not worry about the implementation stuff just yet. > > When you said "PGP encrypt stuff", can you explain exactly what you are > trying to do? In particular, are you trying to use PGP to authenticate a > TLS connection (as described in RFC5081 - > http://www.rfc-editor.org/rfc/rfc5081.txt) or are you trying to encrypt a > file (as described in RFC4880, Section 3.1)? I'm not trying to authenticate, but section 3.1 doesn't specify or generalize what I'm trying to do either. I'm sorry, I don't have much experience with public key encryption. I just had the idea that the contents of e-mails could be encrypted with PGP, and the more popular mail clients had the facilities to decrypt such e-mails. > > > If you are just trying to encrypt a file, why not just use GPGME: > > > http://www.gnupg.org/related_software/gpgme/ > > > It is a library that talks to the gnupg binary over a special machine > > > interface. > > > > I'm looking at GPGME, and it looks a little too DIY. From what I can > > tell, all it does is open a socket to an algorithmic backend, and pipes > > data to and from it--no place to insert things like public and private > > keys and whatever else PGP needs. > > GPGME is designed to support mail user agents handled PGP encryped/signed > messages. Use of it for something wildly different is going to be messy. That does like what I'm trying to do. I have my own mail-sending daemon, you see. It can do things like attach files, include special X- headers, and now I want to encrypt the contents of these e-mails. > I can't help you with a better suggestion unless you can explain what you > are trying to do. Are you trying to generate the keys yourself, or do you > already have them? How are you planning on transferring the private key? I don't understand. From what I thought I knew about PGP, the private key shouldn't enter into the encryption of anything. I imagined the encryption algorithm would just take the content to encrypt, the public key, and let the recipient worry about the private key. > Are you trying to back-up, or transfer a file? More detail please. I'm not trying to back anything up, but a file could be attached, but it might not be. I would have to be ready for either case. From michael.bell at cms.hu-berlin.de Tue Nov 27 11:22:09 2007 From: michael.bell at cms.hu-berlin.de (Michael Bell) Date: Tue, 27 Nov 2007 11:22:09 +0100 Subject: [Help-gnutls] Peer verification In-Reply-To: <200711262058.02331.nmav@gnutls.org> References: <4746B36C.6060006@cms.hu-berlin.de> <474AE32E.6070109@cms.hu-berlin.de> <200711262058.02331.nmav@gnutls.org> Message-ID: <474BEFD1.5060603@cms.hu-berlin.de> Nikos Mavrogiannopoulos schrieb: > In your logs I see that the certificate [1] is the root certificate. This > looks wrong. The chain should be [0] = server certificate > [1] = intermediate > [2] = root I read RFC 2246 TLS and it looks like the certificate chain must be in the correct order but it looks like Apache and all clients simply ignore this part of the specification and create the order by themselves. So if GnuTLS has something like a wishlist then I would like to add a more tolerant behaviour because OpenSSL (and by this way Apache) and all the other clients simply accept this behaviour and so the most servers will never take care about such issues. BTW is there a FAQ or WiKi where I can document this for other users? I think this could be helpful because neither Apache nor OpenSSL s_client report/log any problems with such servers/configurations. Sorry for the trouble Michael -- _______________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 michael.bell at cms.hu-berlin.de D-10099 Berlin _______________________________________________________________ X.509 CA Certificates / Wurzelzertifikate http://ra.pki.hu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5664 bytes Desc: S/MIME Cryptographic Signature URL: From bradh at frogmouth.net Tue Nov 27 12:36:40 2007 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 27 Nov 2007 22:36:40 +1100 Subject: [Help-gnutls] PGP api In-Reply-To: <200711260941.53346.angus@uducat.com> References: <200711221617.05278.angus@uducat.com> <200711241040.41048.bradh@frogmouth.net> <200711260941.53346.angus@uducat.com> Message-ID: <200711272236.40400.bradh@frogmouth.net> On Tuesday 27 November 2007 01:41:53 am Angus wrote: > I'm not trying to authenticate, but section 3.1 doesn't specify or > generalize what I'm trying to do either. I'm sorry, I don't have much > experience with public key encryption. I just had the idea that the > contents of e-mails could be encrypted with PGP, and the more popular mail > clients had the facilities to decrypt such e-mails. This looks reasonable, but GnuTLS (or OpenCDK) probably is not the tool to do it. So this is probably off-topic. > > > I'm looking at GPGME, and it looks a little too DIY. From what I can > > > tell, all it does is open a socket to an algorithmic backend, and pipes > > > data to and from it--no place to insert things like public and private > > > keys and whatever else PGP needs. > > > > GPGME is designed to support mail user agents handled PGP encryped/signed > > messages. Use of it for something wildly different is going to be messy. > > That does like what I'm trying to do. I have my own mail-sending daemon, > you see. It can do things like attach files, include special X- headers, > and now I want to encrypt the contents of these e-mails. OK. I still suggest gpgme. It does have reasonable key handling - read the info pages a few times. Note that it isn't just a PGP library - it also does X.509 based certificate operations. That makes some of the function names a bit abstract, and not all functions are OpenPGP related. Also, what you are trying to do is not trivial, and doing any crypto work without really solid understanding of the technology and the tools is at least a bit dangerous. > > I can't help you with a better suggestion unless you can explain what you > > are trying to do. Are you trying to generate the keys yourself, or do you > > already have them? How are you planning on transferring the private key? > > I don't understand. From what I thought I knew about PGP, the private key > shouldn't enter into the encryption of anything. I imagined the encryption > algorithm would just take the content to encrypt, the public key, and let > the recipient worry about the private key. Sorry, from the context, I thought you were going to do a file transfer. You're obviously going to need the public key to encrypt, and the private key to decrypt. You still need to figure out the key management concept though (like how to reliably transfer the public key from the intended recipient, and manage the association of key to recipient). Good luck. From simon at josefsson.org Tue Nov 27 14:38:12 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 27 Nov 2007 14:38:12 +0100 Subject: [Help-gnutls] Re: Peer verification In-Reply-To: <474BEFD1.5060603@cms.hu-berlin.de> (Michael Bell's message of "Tue, 27 Nov 2007 11:22:09 +0100") References: <4746B36C.6060006@cms.hu-berlin.de> <474AE32E.6070109@cms.hu-berlin.de> <200711262058.02331.nmav@gnutls.org> <474BEFD1.5060603@cms.hu-berlin.de> Message-ID: <87lk8j6c6z.fsf@mocca.josefsson.org> Michael Bell writes: > Nikos Mavrogiannopoulos schrieb: > >> In your logs I see that the certificate [1] is the root >> certificate. This looks wrong. The chain should be [0] = server >> certificate >> [1] = intermediate >> [2] = root > > I read RFC 2246 TLS and it looks like the certificate chain must be in > the correct order but it looks like Apache and all clients simply > ignore this part of the specification and create the order by > themselves. So if GnuTLS has something like a wishlist then I would > like to add a more tolerant behaviour because OpenSSL (and by this way > Apache) and all the other clients simply accept this behaviour and so > the most servers will never take care about such issues. > > BTW is there a FAQ or WiKi where I can document this for other users? > I think this could be helpful because neither Apache nor OpenSSL > s_client report/log any problems with such servers/configurations. Try . Feel free to add a wiki page about this, maybe we can organize a FAQ there as well eventually. If you want, you could also file a wishlist ticket about this. Unless we get more report about this problem, I don't think we should modify GnuTLS here. It seems we follow the protocol. /Simon From angus at uducat.com Tue Nov 27 15:09:46 2007 From: angus at uducat.com (Angus) Date: Tue, 27 Nov 2007 09:09:46 -0500 Subject: [Help-gnutls] PGP api In-Reply-To: <200711272236.40400.bradh@frogmouth.net> References: <200711221617.05278.angus@uducat.com> <200711260941.53346.angus@uducat.com> <200711272236.40400.bradh@frogmouth.net> Message-ID: <200711270909.46119.angus@uducat.com> On Tuesday 27 November 2007 06:36, Brad Hards wrote: > On Tuesday 27 November 2007 01:41:53 am Angus wrote: > > I'm not trying to authenticate, but section 3.1 doesn't specify or > > generalize what I'm trying to do either. I'm sorry, I don't have much > > experience with public key encryption. I just had the idea that the > > contents of e-mails could be encrypted with PGP, and the more popular > > mail clients had the facilities to decrypt such e-mails. > > This looks reasonable, but GnuTLS (or OpenCDK) probably is not the tool to > do it. So this is probably off-topic. > > > > > I'm looking at GPGME, and it looks a little too DIY. From what I can > > > > tell, all it does is open a socket to an algorithmic backend, and > > > > pipes data to and from it--no place to insert things like public and > > > > private keys and whatever else PGP needs. > > > > > > GPGME is designed to support mail user agents handled PGP > > > encryped/signed messages. Use of it for something wildly different is > > > going to be messy. > > > > That does like what I'm trying to do. I have my own mail-sending daemon, > > you see. It can do things like attach files, include special X- headers, > > and now I want to encrypt the contents of these e-mails. > > OK. I still suggest gpgme. It does have reasonable key handling - read the > info pages a few times. Note that it isn't just a PGP library - it also > does X.509 based certificate operations. That makes some of the function > names a bit abstract, and not all functions are OpenPGP related. Ok, thanks for your help. I'll goto the GPGME mailing list from here.