From nmav at gnutls.org Sun May 2 19:45:24 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun, 02 May 2004 20:45:24 +0300 Subject: [gnutls-dev] Re: [Help-gnutls] Self-signed certificates vs Opera In-Reply-To: <4094B8AE.2020400@goodadvice.pages.de> References: <409148B3.8090702@goodadvice.pages.de> <200404300010.46360.nmav@gnutls.org> <4094B8AE.2020400@goodadvice.pages.de> Message-ID: <200405022045.24811.nmav@gnutls.org> On Sunday 02 May 2004 12:00, you wrote: > Hi, > > I'm not sure it's a gnutls problem, but anyway with that information > > there is not much I can do. Try running "gnutls-http-serv -d 3" in the > > src/ directory, connect with opera on it and send me the output. > attached. Actually the error seems to be nonfatal, the page is shown > afterwards. So I was a bit to fast in my 'does not work'. > Yet the output may be somewhat interesting for you. Yes, it seems that the opera connects once using an SSL version 2 hello, for some reason that connection fails, and then connects again using a TLSv1 hello and succeds. I don't know why this happens but it seems like a hack to the opera browser, to make it work with specific servers (and probably gnutls is one of them). I will try to check about it. > hand > Philipp -- Nikos Mavroyanopoulos From nmav at gnutls.org Sun May 2 23:41:56 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon, 03 May 2004 00:41:56 +0300 Subject: [gnutls-dev] Re: [Help-gnutls] Self-signed certificates vs Opera In-Reply-To: <200405022045.24811.nmav@gnutls.org> References: <409148B3.8090702@goodadvice.pages.de> <4094B8AE.2020400@goodadvice.pages.de> <200405022045.24811.nmav@gnutls.org> Message-ID: <200405030041.56292.nmav@gnutls.org> On Sunday 02 May 2004 20:45, Nikos Mavroyanopoulos wrote: > > > I'm not sure it's a gnutls problem, but anyway with that information > > > there is not much I can do. Try running "gnutls-http-serv -d 3" in the > > > src/ directory, connect with opera on it and send me the output. > > attached. Actually the error seems to be nonfatal, the page is shown > > afterwards. So I was a bit to fast in my 'does not work'. > > Yet the output may be somewhat interesting for you. > Yes, it seems that the opera connects once using an SSL version 2 > hello, for some reason that connection fails, and then connects > again using a TLSv1 hello and succeds. I don't know why this happens > but it seems like a hack to the opera browser, to make it work with > specific servers (and probably gnutls is one of them). I will try to check > about it. Well it seems that the first opera connection is a bit strange. No certificate message is sent even if a certificate request is sent (this does not happen in the second connection), and the finished packet calculation is different This looks like a compatibility mode connection. This is probably a bug to be filed to opera developers. > > hand > > Philipp -- Nikos Mavroyanopoulos From wk at gnupg.org Tue May 11 12:31:32 2004 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 May 2004 12:31:32 +0200 Subject: [gnutls-dev] GnuTLS OpenPGP key support In-Reply-To: <200404110235.40117.nmav@gnutls.org> (Nikos Mavroyanopoulos's message of "Sun, 11 Apr 2004 02:35:39 +0300") References: <200404091655.11047.nmav@gnutls.org> <200404110235.40117.nmav@gnutls.org> Message-ID: <87hdunfe63.fsf@vigenere.g10code.de> On Sun, 11 Apr 2004 02:35:39 +0300, Nikos Mavroyanopoulos said: > Currently it would help having a second implementation of the openpgp draft. Did you asked the Caudium or Roxen folks? Shalom-Salam, Werner From nmav at gnutls.org Tue May 11 13:34:46 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue, 11 May 2004 14:34:46 +0300 Subject: [gnutls-dev] GnuTLS OpenPGP key support In-Reply-To: <87hdunfe63.fsf@vigenere.g10code.de> References: <200404110235.40117.nmav@gnutls.org> <87hdunfe63.fsf@vigenere.g10code.de> Message-ID: <200405111434.46511.nmav@gnutls.org> On Tuesday 11 May 2004 13:31, Werner Koch wrote: > On Sun, 11 Apr 2004 02:35:39 +0300, Nikos Mavroyanopoulos said: > > Currently it would help having a second implementation of the openpgp > > draft. > Did you asked the Caudium or Roxen folks? No. I don't know them. > Shalom-Salam, > Werner -- Nikos Mavroyanopoulos From nmav at gnutls.org Tue May 11 13:47:55 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue, 11 May 2004 14:47:55 +0300 Subject: [gnutls-dev] programs that use gnutls Message-ID: <200405111447.55259.nmav@gnutls.org> Hello, I'll create a list of programs that use gnutls to be put in the gnutls' site. I'd appreciate if you have such a program to send me, the name, an URL, and a one-two line description of it, to be included. Thank you. -- Nikos Mavroyanopoulos From wk at gnupg.org Tue May 11 14:05:59 2004 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 May 2004 14:05:59 +0200 Subject: [gnutls-dev] GnuTLS OpenPGP key support In-Reply-To: <200405111434.46511.nmav@gnutls.org> (Nikos Mavroyanopoulos's message of "Tue, 11 May 2004 14:34:46 +0300") References: <200404110235.40117.nmav@gnutls.org> <87hdunfe63.fsf@vigenere.g10code.de> <200405111434.46511.nmav@gnutls.org> Message-ID: <87u0yndv88.fsf@vigenere.g10code.de> On Tue, 11 May 2004 14:34:46 +0300, Nikos Mavroyanopoulos said: > On Tuesday 11 May 2004 13:31, Werner Koch wrote: >> On Sun, 11 Apr 2004 02:35:39 +0300, Nikos Mavroyanopoulos said: >> > Currently it would help having a second implementation of the openpgp >> > draft. >> Did you asked the Caudium or Roxen folks? > No. I don't know them. There is a mailing list caudium-general at caudium.net and other stuff as well. www.gnupg.org runs Caudium. Caudium and Rozen both use their own SSL implementation which comes with the Pike language. Below is some documentation on Pike's SSL. Salam-Shalom, Werner === snip === Overview of the SSL implementation. FILES alert.pike: Used for creating the alert packets we transmit. cipher.pike: Encryption and MAC algorithms used in SSL. connection.pike: SSL packet layer. Inherits handshake. Described below. constants.pike: Protocol constants. context.pike: "Context" state (see below). handshake.pike: SSL handshake and key exchange. https.pike: Dummy https-server. (*) packet.pike: Handle formatting and parsing of packets. server.pike: Not used. session.pike: Session state (see below). sslfile.pike: Interface similar to Stdio.File. Inherits connection and Stdio.File. sslport.pike: Interface similar to Stdio.Port. (*) state.pike: Encryption state. (*) These files are not currently used by Roxen, and may suffer some bit-decay. STATE There's lot of state in an SSL-server, at several levels. We start at the top. SSL.context keeps the state that is shared by all SSL-connections for one server (or one port). It includes policy configuration, a server certificate, the server's private key(s), etc. It also includes the session cache. SSL.session: The most important information in a session object is a choice of encryption algorithms and a "master secret" created by keyexchange with a client. Each connection can either do a full key exchange to established a new session, or reuse a previously established session. That is why we have the session abstraction and the session cache. Each session is used by one or more connections, in sequence or simultaneously. It is also possible to change to a new session in the middle of a connection. SSL.handshake keeps the state relevant for SSL handshaking. This includes a pointer to a context object (which doesn't change), various buffers, a pointer to a session object (reuse or created as appropriate), and pending read and write states being negotiated. Each connection will have two sets or read and write state: The current read and write states used for encryption, and pending read and write states to be taken into use when the current keyexchange handshake is finished. SSL.connection inherits SSL.handshake, and in addition to the state in the handshake super class, it contains the current read and write states, packet queues. This object is responsible for receiving and sending packets, processing handshake packets, and providing a clear text packages for some application. SSL.state: At last, the state objects. As described above, a connection switches from one set of state objects to another, one or more times during its lifetime. Each state object handles a one-way stream of packets, and operates in either decryption or encryption mode. METHODS and ATTRIBUTES When describing these classes in more detail, let's start from the other end. SSL.state object session For information about the used algorithms. object mac Message Authentication Code object crypt Encryption or decryption object object seq_num 64-bit sequence number object decrypt_packet(object packet) Decrypts a packet (including inflating and MAC-verification, if needed). On success, returns the decrypted packet. On failure, returns an alert packet. These cases are distinguished by looking at the is_alert attribute of the returned packet. object encrypt_packet(object packet) Encrypts a packet (including deflating and MAC-generation). SSL.session (inherits cipher) string identity Session identifier int compression_algorithm Always COMPRESSION_null. int cipher_suite Constant defining a choice of keyexchenge, encryption and mac algorithm. object cipher_spec Information about the encryption method derived from the cipher_suite. int ke_method Key exchange method, also derived from the cipher_suite. string master_secret Secret shared with the client. Used for deriving the actual keys. void set_cipher_suite(int suite) void set_compression_method(int compr) array new_server_states(string client_random, string server_random) Computes a new set of encryption stetes, derived from the client_random, server_random and master_secret strings. Returns an array ({ read_state, write_state }). array new_client_states(string client_random, string server_random) Similar function for the client end. SSL.context object rsa The server's private key object long_rsa object short_rsa Temporary, non-certified, private keys, used with a server_key_exchange message. The rules are as follows: If the negotiated cipher_suite has the "exportable" property, and short_rsa is not zero, send a server_key_exchange message with the (public part of) the short_rsa key. If the negotiated cipher_suite does not have the exportable property, and long_rsa is not zero, send a server_key_exchange message with the (public part of) the long_rsa key. Otherwise, dont send any server_key_exchange message. function(int:string) random; Used to generate random cookies for the hello-message. If we use the RSA keyexchange method, and this is a server, this random number generator is not used for generating the master_secret. array(string) certificates; The server's certificate, or a chain of certificates, with the server's certificate first and root certificate last. array(int) preferred_auth_methods For client authentication. Used only if auth_level is AUTH_ask or AUTH_require. array(int) preferred_suites Cipher suites we want the server to support, best first. array(int) preferred_compressors Always ({ COMPRESSION_null }) int use_cache Non-zero to enable cahing of sessions int session_lifetime Sessions are removed from the cache when they are older than this limit (in seconds). Sessions are also removed from the cache if a connection using the session dies unexpectedly. void export_mode() Change the preferred_suites variable to use only exportable algorithms. object new_session() Create a new session. void record_session(object s) Add a session to the cache (if caching is enabled). void purge_session(object s) Remove a session from the cache. object lookup_session(string id) Lookup a session identifier in the cache. Returns the corresponding session, or zero if it is not found or caching is disabled. SSL.handshake int auth_level Policy for client authentication. One of AUTHLEVEL_none, AUTHLEVEL_ask and AUTHLEVEL_require. array(string) authorities Array of authorities that are accepted for client certificates. The client will only send certificates that are signed by any of these authorities. The string is the DER-encoded issuer. object session object context object pending_read_state object pending_write_state int handshake_state int certificate_state int expect_change_cipher string my_random string other_random Random cookies, sent and received with the hello-messages. void send_packet(object packet, int|void fatal) Prototype. Must be defined in inheriting classes, i.e. SSL.connection. int handle_handshake(int type, string data, string raw) Do handshake processing. Type is one of HANDSHAKE_*, data is the contents of the packet, and raw is the raw packet received (needed for supporting SSLv2 hello messages). This function returns 0 if hadshake is in progress, 0 if handshake is finished, and -1 if a fatal error occured. It uses the send_packet() function to trasnmit packets. void create(int is_server) Only create(1) is implemented. SSL.connection (inherits SSL.handshake) object current_read_state object current_write_state void create(int is_server) void set_alert_callback(function(object,int|object,string:void) callback) Installs a callback that is called if a bad packet is received. Used to implement Roxen's https->http fallback redirect. object recv_packet(string data) Low-level recieve handler. Returns a packet, an alert, or zero if more data is needed to get a complete packet. void send_packet(object packet, int|void priority) Queues a packet for write. string|int got_data(string s) Main receive handler. Returns a string of received application data, or 1 if a close was received, or -1 if an error occured. This function is intended to be called from an i/o read callback. string|int to_write() Extracts data from the packet queues. Returns "" if there are no pending packets, 1 of the connection is being closed politely, and -1 if the connection died unexpectedly. This function is intended to be called from an i/o write callback. void send_close() Initiate close. From gray at Mirddin.farlep.net Tue May 11 19:15:41 2004 From: gray at Mirddin.farlep.net (Sergey Poznyakoff) Date: Tue, 11 May 2004 20:15:41 +0300 Subject: [gnutls-dev] programs that use gnutls In-Reply-To: Your message of Tue, 11 May 2004 14:47:55 +0300 <200405111447.55259.nmav@gnutls.org> References: <200405111447.55259.nmav@gnutls.org> Message-ID: <200405111715.i4BHFfh03138@Mirddin.farlep.net> Kalimera Nikos! > I'll create a list of programs that use gnutls to be put > in the gnutls' site. I'd appreciate if you have such a program > to send me, the name, an URL, and a one-two line description > of it, to be included. * GNU Anubis GNU Anubis is an outgoing mail processor. It goes between the MUA (Mail User Agent) and the MTA (Mail Transport Agent), and performs various operations on outgoing messages, such as on-the-fly editing, changing headers, PGP signing etc. http://www.gnu.org/directory/anubis.html http://www.gnu.org/software/anubis http://savannah.gnu.org/projects/anubis * GNU Mailutils GNU Mailutils is a collection of mail-related utilities. It contains a general-purpose library for developing mail-related applications. It also includes many useful utilities for handling e-mail, among them pop3d, imap4d, comsatd, mail, frm, messages and sieve. http://www.gnu.org/directory/mailutils.html http://www.gnu.org/software/mailutils http://savannah.gnu.org/projects/mailutils Regards, Sergey From nmav at gnutls.org Tue May 18 13:00:42 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue, 18 May 2004 14:00:42 +0300 Subject: [gnutls-dev] libtasn 0.2.10 Message-ID: <200405181400.42029.nmav@gnutls.org> Hello, Libtasn1 0.2.10 was just released. This version fixes a serious bug in the DER decoder, and adds a version detection script. -- Nikos Mavroyanopoulos From jerry.lundstrom at it.su.se Tue May 18 13:25:06 2004 From: jerry.lundstrom at it.su.se (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Tue, 18 May 2004 13:25:06 +0200 Subject: [gnutls-dev] libtasn 0.2.10 In-Reply-To: <200405181400.42029.nmav@gnutls.org> References: <200405181400.42029.nmav@gnutls.org> Message-ID: <40A9F292.2080009@it.su.se> Nikos Mavroyanopoulos wrote: > Hello, > Libtasn1 0.2.10 was just released. This version fixes a serious bug in > the DER decoder, and adds a version detection script. > Please update MD5/gpg on the ftp and/or include them also in the mail. Thanks From nmav at gnutls.org Tue May 18 13:39:59 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue, 18 May 2004 14:39:59 +0300 Subject: [gnutls-dev] libtasn 0.2.10 In-Reply-To: <40A9F292.2080009@it.su.se> References: <200405181400.42029.nmav@gnutls.org> <40A9F292.2080009@it.su.se> Message-ID: <200405181439.59383.nmav@gnutls.org> On Tuesday 18 May 2004 14:25, Jerry Lundstr?m wrote: > Nikos Mavroyanopoulos wrote: > > Hello, > > Libtasn1 0.2.10 was just released. This version fixes a serious bug in > > the DER decoder, and adds a version detection script. > Please update MD5/gpg on the ftp and/or include them also in the mail. I've just added the signature file. > Thanks -- Nikos Mavroyanopoulos From mak at greenhills.co.uk Wed May 19 04:02:45 2004 From: mak at greenhills.co.uk (Martijn Koster) Date: Wed, 19 May 2004 02:02:45 -0000 Subject: [gnutls-dev] gnutls_pk.c uninitialised memory Message-ID: <1084889639.22399.92.camel@yoda.home.greenhills.co.uk> Hi all, I was using valgrind on gnutls-cli-debug, and it found a bug. I tested gnutls-1.0.8, but that code has not changed in HEAD. valgrind --tool=memcheck \ `which gnutls-cli-debug` pics.half.ebay.com reported: Conditional jump or move depends on uninitialised value(s) at 0x3C294E16: _gnutls_pkcs1_rsa_encrypt (gnutls_pk.c:122) by 0x3C2938B1: _gnutls_gen_rsa_client_kx (auth_rsa.c:313) by 0x3C28D76C: _gnutls_send_client_kx_message (gnutls_kx.c:187) by 0x3C28846F: _gnutls_handshake_client (gnutls_handshake.c:2035) by 0x3C2880A7: gnutls_handshake (gnutls_handshake.c:1897) That refers to the last line of this code: opaque rnd[3]; /* Read three random bytes that will be * used to replace the zeros. */ if ( (ret=_gnutls_get_random( rnd, 3, GNUTLS_STRONG_RANDOM)) < 0) { gnutls_assert(); gnutls_afree(edata); return ret; } /* use non zero values for * the first two. */ if (rnd[0]==0) rnd[0] = 0xaf; if (rnd[1]==0) rnd[1] = 0xae; if (ps[i] == 0) { /* If the first one is zero then set it to rnd[0]. * If the second one is zero then set it to rnd[1]. * Otherwise add (mod 256) the two previous ones plus rnd[3], or use * rnd[1] if the value == 0. */ if (i<2) ps[i] = rnd[i]; else ps[i] = GMAX( rnd[3] + ps[i-1] + ps[i-2], rnd[1]); rnd is a 3-byte array, and get_random fills it with 3 bytes, but then in the last line rnd[3] is used, which is outside the array, and uninitialised. Current code in CVS has the same thing: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/gnutls/lib/gnutls_pk.c?rev=HEAD&cvsroot=GNU+TLS+Library&content-type=text/vnd.viewcvs-markup I presume that rnd[3] should be rnd[2]? With that change the warning goes away. But I don't know what this code does, so I don't know if it's the right fix. I've appended a patch. Regards, -- Martijn --- gnutls_pk.c.orig 2004-05-18 14:58:03.569633016 +0100 +++ gnutls_pk.c 2004-05-18 14:58:27.360016328 +0100 @@ -115,11 +115,11 @@ if (ps[i] == 0) { /* If the first one is zero then set it to rnd[0]. * If the second one is zero then set it to rnd[1]. - * Otherwise add (mod 256) the two previous ones plus rnd[3], or use + * Otherwise add (mod 256) the two previous ones plus rnd[2], or use * rnd[1] if the value == 0. */ if (i<2) ps[i] = rnd[i]; - else ps[i] = GMAX( rnd[3] + ps[i-1] + ps[i-2], rnd[1]); + else ps[i] = GMAX( rnd[2] + ps[i-1] + ps[i-2], rnd[1]); } } break;