From dpashkouski at tech-w.com Fri Jan 6 08:37:51 2006 From: dpashkouski at tech-w.com (Dzmitry Pashkouski) Date: Fri, 6 Jan 2006 09:37:51 +0200 Subject: [Help-gnutls] generate a privite key Message-ID: <1487278565.20060106093751@tech-w.com> Hello, I have Debian, testing(the same in stable), package libgnutls11 1.0.16-14 When I run "certtool -p" I get two strings: Generating a private key... Generating a 1024 bit RSA private key... And nothing else happens. It stucks. I have to cancel the program. Why does not it generate a private key? I suppose there is something regarding /dev/random ?? Originally the problem came from exim4 when I tried to make it use ssl. Thanks for any help! -- Best regards, Dzmitry mailto:dpashkouski at tech-w.com From nmav at gnutls.org Fri Jan 6 11:26:14 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 6 Jan 2006 11:26:14 +0100 Subject: [Help-gnutls] generate a privite key In-Reply-To: <1487278565.20060106093751@tech-w.com> References: <1487278565.20060106093751@tech-w.com> Message-ID: <200601061126.15078.nmav@gnutls.org> On Friday 06 January 2006 08:37, Dzmitry Pashkouski wrote: > Generating a private key... > Generating a 1024 bit RSA private key... > And nothing else happens. It stucks. I have to cancel the > program. > Why does not it generate a private key? I suppose there is > something regarding /dev/random ?? Hello, /dev/random is needed to seed the random number generator. It seems that in your system the /dev/random is broken. Check if it is a problem with your kernel version. Alternatively you can compile libgcrypt with a different random generator such as egd or the unix one. -- Nikos Mavrogiannopoulos From smurf at smurf.noris.de Fri Jan 6 18:00:58 2006 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Fri, 6 Jan 2006 18:00:58 +0100 Subject: [Help-gnutls] generate a privite key In-Reply-To: <200601061126.15078.nmav@gnutls.org> References: <1487278565.20060106093751@tech-w.com> <200601061126.15078.nmav@gnutls.org> Message-ID: <20060106170058.GH17399@kiste.smurf.noris.de> Hi, Nikos Mavrogiannopoulos: > > Why does not it generate a private key? I suppose there is > > something regarding /dev/random ?? > Hello, > /dev/random is needed to seed the random number generator. It seems > that in your system the /dev/random is broken. /dev/random is blocking because it oesn't get random bits from anywhere. For networked computers, the most likely error source is a broken Ethernet driver. For computers you're sitting in front of, just switch to a different terminal an bang a few keys. ;-) > Check if it is a problem > with your kernel version. Alternatively you can compile libgcrypt with > a different random generator such as egd or the unix one. > If all else fails, use /dev/urandom, which uses an internal hash function instead of blocking when it runs out of bits. I'd say that for most if not all uses, /dev/urandom is perfectly OK. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf at smurf.noris.de Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - A BELCH IS NOT AN ORAL REPORT -- Bart Simpson on chalkboard in episode BABF11 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jas at extundo.com Thu Jan 12 22:32:03 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu, 12 Jan 2006 22:32:03 +0100 Subject: [Help-gnutls] Experimental: GnuTLS 1.3.3 Message-ID: We are pleased to announce the availability of GnuTLS version 1.3.3, another release on the experimental 1.3.x branch. The goal of 1.3.x will be to add support for TLS Pre-Shared-Keys and TLS Inner Application (TLS/IA). Other planned improvements in 1.3.x are system-independent resume data structures, modularization of the bignum operations, and TLS OpenPGP improvements. So far, the TLS-PSK, TLS/IA and system-independent resume data goals have been met. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. 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. If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ (updated fastest) Here are the compressed sources: http://josefsson.org/gnutls/releases/gnutls-1.3.3.tar.gz (3.1MB) ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.3.3.tar.bz2 (3.1MB) Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.3.3.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.3.3.tar.bz2.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: 1280R/B565716F 2002-05-05 [expires: 2006-02-28] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the build reports for various platforms: http://josefsson.org/autobuild-logs/gnutls.html Here are the SHA-1 checksums: 65e255278632646afc48b284fbe03ddef996551b gnutls-1.3.3.tar.bz2 e4a401b914d4f39f13e5c714b0278b00bb11fef3 gnutls-1.3.3.tar.bz2.sig Enjoy, Nikos and Simon Noteworthy changes since version 1.3.2: ** New API to access the TLS master secret. When possible, you should use the TLS PRF functions instead. Suggested by Jouni Malinen . ** Improved handling when multiple libraries use GnuTLS at the same time. Now gnutls_global_init() can be called multiple times, and gnutls_global_deinit() will only deallocate the structure when it has been called as many times as gnutls_global_init() was called. ** Added a self test of TLS resume functionality. ** Fix crash in TLS resume code, caused by TLS/IA changes. ** Documentation fixes about thread unsafety, prompted by ** discussion with bryanh at giraffe-data.com (Bryan Henderson). In particular, gnutls_global_init() and gnutls_global_deinit() are not thread safe. Careful callers may want to protect the call using a mutex. The problem could also be ignored, which would cause a memory leak under rare conditions when two threads invoke the function roughly at the same time. ** Add 'const' keywords in various places, from Frediano ZIGLIO. ** The code was indented again, including the external header files. ** API and ABI modifications: New functions to retrieve the master secret value: gnutls_session_get_master_secret Add a 'const' keyword to existing API: gnutls_x509_crq_get_challenge_password From fischerk at inf.ethz.ch Sun Jan 15 02:45:45 2006 From: fischerk at inf.ethz.ch (Kaspar Fischer) Date: Sun, 15 Jan 2006 02:45:45 +0100 Subject: [Help-gnutls] Secret key after SRP authentication Message-ID: <72CC43A8-7D55-4C01-B891-FD473241D7D0@inf.ethz.ch> Hi all, I read somewhere that SRP not only provides authentication but results also in the server and client knowing a secret key. How can I obtain this key in the GNU TLS implementation? I could not find anything in the docs and would like to be sure that I am doing the right thing (it's about sec- urity, so I want to be sure). Basically, my client looks like the one described in the documentation, http://www.gnu.org/software/gnutls/manual/html_node/Simple-client- example-with-SRP-authentication.html#Simple-client-example-with-SRP- authentication Thanks for any help, Kaspar From nmav at gnutls.org Sun Jan 15 20:17:40 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 15 Jan 2006 20:17:40 +0100 Subject: [Help-gnutls] Secret key after SRP authentication In-Reply-To: <72CC43A8-7D55-4C01-B891-FD473241D7D0@inf.ethz.ch> References: <72CC43A8-7D55-4C01-B891-FD473241D7D0@inf.ethz.ch> Message-ID: <200601152017.40219.nmav@gnutls.org> On Sunday 15 January 2006 02:45, Kaspar Fischer wrote: > Hi all, > > I read somewhere that SRP not only provides authentication > but results also in the server and client knowing a secret > key. How can I obtain this key in the GNU TLS > implementation? Hello, You mean the negotiated key? No there is no way currently to obtain it. Why do you need it? If you are mixing that key with another protocol, I'd say that in general it could be unsafe to do that. -- Nikos Mavrogiannopoulos From fischerk at inf.ethz.ch Mon Jan 16 11:28:10 2006 From: fischerk at inf.ethz.ch (Kaspar Fischer) Date: Mon, 16 Jan 2006 11:28:10 +0100 Subject: [Help-gnutls] Secret key after SRP authentication In-Reply-To: <200601152017.40219.nmav@gnutls.org> References: <72CC43A8-7D55-4C01-B891-FD473241D7D0@inf.ethz.ch> <200601152017.40219.nmav@gnutls.org> Message-ID: <6ACC0CB3-FE2D-4A0E-BB74-BD8FFB709F9A@inf.ethz.ch> On 15.01.2006, at 20:17, Nikos Mavrogiannopoulos wrote: > Hello, > You mean the negotiated key? No there is no way currently to > obtain it. > Why do you need it? If you are mixing that key with another protocol, > I'd say that in general it could be unsafe to do that. Thanks for your answer. As a matter of fact I made a big confusion. I thought that the example http://www.gnu.org/software/gnutls/manual/html_node/Simple-client- example-with-SRP-authentication.html#Simple-client-example-with-SRP- authentication was only doing authentication -- and NOT encryption. Therefore I was wondering where I could find this negotiated key to use it to initialize an encryption method for encrypted send()/recv(). But (of course!) GNU TLS already does everything for me, meaing that the send()/recv()'s in the above server and client example *are* already encrypted. -- I did not get this at first. Sorry for this. Kaspar From oliverlupton at gmail.com Thu Jan 19 13:20:36 2006 From: oliverlupton at gmail.com (Oliver Lupton) Date: Thu, 19 Jan 2006 12:20:36 +0000 Subject: [Help-gnutls] What actually works? Message-ID: <20060119122036.1993c6b3@honu.gateway.2wire.net> Not meaning to come across as rude, but am I (and everyone else who has tried) making some basic mistake? I originally started using gnutls in an attempt to add SSL support to an IRCd (InspIRCd). Beginning with the version I had installed (The debian package was versioned 1.0.16-14) I tried the examples in the manual, which didn't compile which I thought was because of the docs being for 1.3.3 and me having an old version. I then installed 1.3.3 from source which, while allowing the examples in the docs to compile, I couldn't get it to successfully connect using either my ircd code, the examples in the docs (the X.509 client and the X.509 echo server (I and II)), or the commandline tools gnutls-cli, guntls-cli-debug and gnutls-serv. Everything failed with the same error: Could not negotiate a supported cipher suite (GNUTLS_E_UNKNOWN_CIPHER_SUITE). Suspecting that my Debian install (with multiple versions on the same system) was to blame I tried the commandline tools and my ircd code on another box running FreeBSD and 1.3.(2 or 3) and a friend tried the commandline tools on a Gentoo box with 1.2.3 with the same result. Attached are the source files from the docs I was compiling, and the (very, very alpha) ircd module. Cheers, -ol -- I will live forever, or die trying. -------------- next part -------------- A non-text attachment was scrubbed... Name: testclient.cpp Type: text/x-c++src Size: 2988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testserver.cpp Type: text/x-c++src Size: 7763 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: m_ssl.cpp Type: text/x-c++src Size: 9504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nmav at gnutls.org Fri Jan 20 18:29:39 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Jan 2006 18:29:39 +0100 Subject: [Help-gnutls] What actually works? In-Reply-To: <20060119122036.1993c6b3@honu.gateway.2wire.net> References: <20060119122036.1993c6b3@honu.gateway.2wire.net> Message-ID: <200601201829.40014.nmav@gnutls.org> On Thursday 19 January 2006 13:20, Oliver Lupton wrote: > Not meaning to come across as rude, but am I (and everyone else who > has tried) making some basic mistake? I originally started using > gnutls in an attempt to add SSL support to an IRCd (InspIRCd). > Beginning with the version I had installed (The debian package was > versioned 1.0.16-14) I tried the examples in the manual, which didn't > compile which I thought was because of the docs being for 1.3.3 and > me having an old version. I then installed 1.3.3 from source which, > while allowing the examples in the docs to compile, I couldn't get it > to successfully connect using either my ircd code, the examples in > the docs (the X.509 client and the X.509 echo server (I and II)), or > the commandline tools gnutls-cli, guntls-cli-debug and gnutls-serv. > Everything failed with the same error: 1.3.x is a development version. Use the 1.2.x series unless you need the latest new features. Always read the manual of the series you are using. And yes the 1.3.x manuals do not apply to anything else than the 1.3.x series. -- Nikos Mavrogiannopoulos From oliverlupton at gmail.com Sat Jan 21 22:42:53 2006 From: oliverlupton at gmail.com (Oliver Lupton) Date: Sat, 21 Jan 2006 21:42:53 +0000 Subject: [Help-gnutls] What actually works? In-Reply-To: <200601201829.40014.nmav@gnutls.org> References: <20060119122036.1993c6b3@honu.gateway.2wire.net> <200601201829.40014.nmav@gnutls.org> Message-ID: <20060121214253.73720b09@honu.gateway.2wire.net> On Fri, 20 Jan 2006 18:29:39 +0100 Nikos Mavrogiannopoulos wrote: > On Thursday 19 January 2006 13:20, Oliver Lupton wrote: > > Not meaning to come across as rude, but am I (and everyone else who > > has tried) making some basic mistake? I originally started using > > gnutls in an attempt to add SSL support to an IRCd (InspIRCd). > > Beginning with the version I had installed (The debian package was > > versioned 1.0.16-14) I tried the examples in the manual, which didn't > > compile which I thought was because of the docs being for 1.3.3 and > > me having an old version. I then installed 1.3.3 from source which, > > while allowing the examples in the docs to compile, I couldn't get it > > to successfully connect using either my ircd code, the examples in > > the docs (the X.509 client and the X.509 echo server (I and II)), or > > the commandline tools gnutls-cli, guntls-cli-debug and gnutls-serv. > > Everything failed with the same error: > > 1.3.x is a development version. Use the 1.2.x series unless you need > the latest new features. Always read the manual of the series you are > using. And yes the 1.3.x manuals do not apply to anything else than > the 1.3.x series. > I tried installing 1.2.9 on my system, the install was apparently successful but I hit the same problems. Everything, including the examples and test programs in the tarball, fails with the same error as detailed in my first message. I've since moved towards OpenSSL for the IRCd module, but I, or a friend working on the same project, would be very interested in GnuTLS if we could get anything to work. The API is much nicer than OpenSSL's. So is there anything you can suggest for why everything is failing as it is? :) Cheers, -ol -- I will live forever, or die trying. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nmav at gnutls.org Sat Jan 21 23:57:55 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 21 Jan 2006 23:57:55 +0100 Subject: [Help-gnutls] What actually works? In-Reply-To: <20060121214253.73720b09@honu.gateway.2wire.net> References: <20060119122036.1993c6b3@honu.gateway.2wire.net> <200601201829.40014.nmav@gnutls.org> <20060121214253.73720b09@honu.gateway.2wire.net> Message-ID: <200601212357.55887.nmav@gnutls.org> On Saturday 21 January 2006 22:42, Oliver Lupton wrote: > I tried installing 1.2.9 on my system, the install was apparently > successful but I hit the same problems. Everything, including the > examples and test programs in the tarball, fails with the same error > as detailed in my first message. I've since moved towards OpenSSL for > the IRCd module, but I, or a friend working on the same project, > would be very interested in GnuTLS if we could get anything to work. > The API is much nicer than OpenSSL's. So is there anything you can > suggest for why everything is failing as it is? :) You should note that in the examples there is no error checking. You should add it in a real world application. In your case I guess the failure is because you didn't create the certificate and private key files. If you check the code that you attached, a server needs a certificate and a private key pair in order to work. regards, Nikos From oliverlupton at gmail.com Sun Jan 22 20:42:13 2006 From: oliverlupton at gmail.com (Oliver Lupton) Date: Sun, 22 Jan 2006 19:42:13 +0000 Subject: [Help-gnutls] What actually works? In-Reply-To: <200601212357.55887.nmav@gnutls.org> References: <20060119122036.1993c6b3@honu.gateway.2wire.net> <200601201829.40014.nmav@gnutls.org> <20060121214253.73720b09@honu.gateway.2wire.net> <200601212357.55887.nmav@gnutls.org> Message-ID: <20060122194213.7103840a@honu.gateway.2wire.net> On Sat, 21 Jan 2006 23:57:55 +0100 Nikos Mavrogiannopoulos wrote: > On Saturday 21 January 2006 22:42, Oliver Lupton wrote: > > > I tried installing 1.2.9 on my system, the install was apparently > > successful but I hit the same problems. Everything, including the > > examples and test programs in the tarball, fails with the same error > > as detailed in my first message. I've since moved towards OpenSSL for > > the IRCd module, but I, or a friend working on the same project, > > would be very interested in GnuTLS if we could get anything to work. > > The API is much nicer than OpenSSL's. So is there anything you can > > suggest for why everything is failing as it is? :) > > You should note that in the examples there is no error checking. > You should add it in a real world application. In your case I guess the > failure is because you didn't create the certificate and private key > files. If you check the code that you attached, a server needs a > certificate and a private key pair in order to work. > > regards, > Nikos Thank you, thank you, thank you! (!!!) Embarassing now it was something so simple, but it's all working now :) A million more thanks :) Apologies if I was a little..accusing in my first emails, it wasn't intentional :) Thanks again for a great library with an API so much cleaner than OpenSSL's :) Cheers, -ol -- I will live forever, or die trying. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From whatever at fsrz.net Mon Jan 23 23:11:06 2006 From: whatever at fsrz.net (Rich Fought) Date: Mon, 23 Jan 2006 16:11:06 -0600 Subject: [Help-gnutls] gnutls_record_check_pending Message-ID: <43D5547A.2040503@fsrz.net> Hello, Is it possible to use gnutls_record_check_pending to determine if gnutls_record_recv should be called? I am trying it currently and always get zero ... even when I know that data is being sent from the remote client. Regards, Rich From nmav at gnutls.org Tue Jan 24 18:20:41 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 24 Jan 2006 18:20:41 +0100 Subject: [Help-gnutls] gnutls_record_check_pending In-Reply-To: <43D5547A.2040503@fsrz.net> References: <43D5547A.2040503@fsrz.net> Message-ID: <200601241820.41554.nmav@gnutls.org> On Monday 23 January 2006 23:11, Rich Fought wrote: > Hello, > Is it possible to use gnutls_record_check_pending to determine if > gnutls_record_recv should be called? > I am trying it currently and always get zero ... even when I know > that data is being sent from the remote client. The purpose of gnutls_record_check_pending is to check if there are data in the gnutls buffers. It will not check the TCP buffers. You can check TCP buffers using select() and then call gnutls_record_recv() in a non-blocking way. regards, Nikos From whatever at fsrz.net Tue Jan 24 22:05:03 2006 From: whatever at fsrz.net (Rich Fought) Date: Tue, 24 Jan 2006 15:05:03 -0600 Subject: [Help-gnutls] gnutls_record_check_pending In-Reply-To: <200601241820.41554.nmav@gnutls.org> References: <43D5547A.2040503@fsrz.net> <200601241820.41554.nmav@gnutls.org> Message-ID: <43D6967F.4030902@fsrz.net> Nikos Mavrogiannopoulos wrote: > >> Is it possible to use gnutls_record_check_pending to determine if >> gnutls_record_recv should be called? >> I am trying it currently and always get zero ... even when I know >> that data is being sent from the remote client. >> > > The purpose of gnutls_record_check_pending is to check if there > are data in the gnutls buffers. It will not check the TCP buffers. > You can check TCP buffers using select() and then call > gnutls_record_recv() in a non-blocking way. > > regards, > Nikos > > So the data does not get moved from the TCP buffers to the gnutls buffers until gnutls_record_recv() is called? Rich From nmav at gnutls.org Wed Jan 25 20:50:56 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 25 Jan 2006 20:50:56 +0100 Subject: [Help-gnutls] gnutls_record_check_pending In-Reply-To: <43D6967F.4030902@fsrz.net> References: <43D5547A.2040503@fsrz.net> <200601241820.41554.nmav@gnutls.org> <43D6967F.4030902@fsrz.net> Message-ID: <200601252050.56703.nmav@gnutls.org> On Tuesday 24 January 2006 22:05, Rich Fought wrote: > So the data does not get moved from the TCP buffers to the gnutls > buffers until > gnutls_record_recv() is called? Yes that's the behavior. From whatever at fsrz.net Thu Jan 26 18:52:22 2006 From: whatever at fsrz.net (Rich Fought) Date: Thu, 26 Jan 2006 11:52:22 -0600 Subject: [Help-gnutls] Application Data Spanning Mulitple TLS Records Message-ID: <43D90C56.90202@fsrz.net> I'm sending large messages greater than 16k over TLS, so I'm having to deal with multiple records. Is there any way in GnuTLS to determine how many records constitute a complete message (perhaps an indicator in the record header, for instance), or is this left to the application layer? How is this situation generally handled? Thanks, Rich From jas at extundo.com Fri Jan 27 12:21:53 2006 From: jas at extundo.com (Simon Josefsson) Date: Fri, 27 Jan 2006 12:21:53 +0100 Subject: [Help-gnutls] Re: Application Data Spanning Mulitple TLS Records In-Reply-To: <43D90C56.90202@fsrz.net> (Rich Fought's message of "Thu, 26 Jan 2006 11:52:22 -0600") References: <43D90C56.90202@fsrz.net> Message-ID: Rich Fought writes: > I'm sending large messages greater than 16k over TLS, so I'm having to > deal with multiple records. > > Is there any way in GnuTLS to determine how many records constitute a > complete message > (perhaps an indicator in the record header, for instance), or is this > left to the application layer? I'm not sure I understand exactly what you are looking for and why. Do you want to find out how many record protocol messages is used for some particular application data? I'm not sure it is easy to extract this. Perhaps Nikos will understand more and answer. It would help if you could suggest an API that would solve your problem, then I can see how difficult it would be to implement that API. Regards, Simon From whatever at fsrz.net Fri Jan 27 17:59:10 2006 From: whatever at fsrz.net (Rich Fought) Date: Fri, 27 Jan 2006 10:59:10 -0600 Subject: [Help-gnutls] Re: Application Data Spanning Mulitple TLS Records In-Reply-To: References: <43D90C56.90202@fsrz.net> Message-ID: <43DA515E.5020307@fsrz.net> Hello Simon, I apologize, my question was actually directed more at the TLS specification itself rather than GnuTLS. I did some research and answered my own question. The gist of the question was: since application data can be fragmented across multiple TLS records, is there any way to tell from the TLS protocol what records go together to form a single application-level message, *without actually looking at the application data*. The answer to this question appears to be "no." From the TLS 1.0 RFC: struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; ... fragment The application data. This data is transparent and treated as an independent block to be dealt with by the higher level protocol specified by the type field. So one must analyze the application data inside the records to determine if a record contains a single application-level message or a portion of a fragmented application-level message. I was *hoping* that the TLS protocol might have in indication of which records go together to form a single application-level message, much like TCP/IP. It appears that it does not; as such the thought of a GnuTLS API change is moot. Regards, Rich Simon Josefsson wrote: > Rich Fought writes: > > >> I'm sending large messages greater than 16k over TLS, so I'm having to >> deal with multiple records. >> >> Is there any way in GnuTLS to determine how many records constitute a >> complete message >> (perhaps an indicator in the record header, for instance), or is this >> left to the application layer? >> > > I'm not sure I understand exactly what you are looking for and why. > Do you want to find out how many record protocol messages is used for > some particular application data? I'm not sure it is easy to extract > this. Perhaps Nikos will understand more and answer. > > It would help if you could suggest an API that would solve your > problem, then I can see how difficult it would be to implement that > API. > > Regards, > Simon > > > > > From jas at extundo.com Fri Jan 27 18:09:17 2006 From: jas at extundo.com (Simon Josefsson) Date: Fri, 27 Jan 2006 18:09:17 +0100 Subject: [Help-gnutls] Re: Application Data Spanning Mulitple TLS Records In-Reply-To: <43DA515E.5020307@fsrz.net> (Rich Fought's message of "Fri, 27 Jan 2006 10:59:10 -0600") References: <43D90C56.90202@fsrz.net> <43DA515E.5020307@fsrz.net> Message-ID: Rich Fought writes: > Hello Simon, > > I apologize, my question was actually directed more at the TLS > specification itself rather than GnuTLS. > > I did some research and answered my own question. The gist of the > question was: since application > data can be fragmented across multiple TLS records, is there any way > to tell from the TLS protocol > what records go together to form a single application-level message, > *without actually looking at the > application data*. > > The answer to this question appears to be "no." Hi Rich! I understand now, and I agree with your analysis and answer. Regards, Simon > From the TLS 1.0 RFC: > > struct { > ContentType type; > ProtocolVersion version; > uint16 length; > opaque fragment[TLSPlaintext.length]; > } TLSPlaintext; > > ... > > fragment > The application data. This data is transparent and treated as an > independent block to be dealt with by the higher level protocol > specified by the type field. > > So one must analyze the application data inside the records to > determine if a record contains a > single application-level message or a portion of a fragmented > application-level message. > > I was *hoping* that the TLS protocol might have in indication of which > records go together to > form a single application-level message, much like TCP/IP. It appears > that it does not; as such > the thought of a GnuTLS API change is moot. > > Regards, > Rich > > Simon Josefsson wrote: >> Rich Fought writes: >> >> >>> I'm sending large messages greater than 16k over TLS, so I'm having to >>> deal with multiple records. >>> >>> Is there any way in GnuTLS to determine how many records constitute a >>> complete message >>> (perhaps an indicator in the record header, for instance), or is this >>> left to the application layer? >>> >> >> I'm not sure I understand exactly what you are looking for and why. >> Do you want to find out how many record protocol messages is used for >> some particular application data? I'm not sure it is easy to extract >> this. Perhaps Nikos will understand more and answer. >> >> It would help if you could suggest an API that would solve your >> problem, then I can see how difficult it would be to implement that >> API. >> >> Regards, >> Simon >> >> >> >> >>