headers
Simon Josefsson | 7 Oct 2005 15:27

GnuTLS 1.2.8

We are pleased to announce the availability of GnuTLS version 1.2.8.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.

Noteworthy changes since version 1.2.7:
- Libgcrypt 1.2.2 is required to fix a bug for forking GnuTLS servers.
- Don't install the auxilliary libexamples library used by the
  examples in doc/examples/ on "make install", report and tiny patch
  from Thomas Klausner <tk <at> giga.or.at>.
- If you pass a X.509 CA or PGP trust database to the command line
  tool, it will now abort the connection if the server certificate
  validation fails.  Use the parameter --insecure to continue even
  after certificate validation failures.  Inspired from discussion
  with Alexander Kotelnikov <sacha <at> myxomop.com>.
- The test for socklen_t has been moved to gnulib.
- Link failures for duplicate or missing "program_name" symbol has been fixed,
  patch from Martin Lambers <marlam <at> marlam.de>.
- The command line tool and the examples no longer uses mmap or bzero,
  to make them more portable, patch from Martin Lambers
  <marlam <at> marlam.de>.
- Made the PKCS #12 API handle null passwords. Based on patch by
  Anton Altaparmakov <aia21 <at> cam.ac.uk>.
- The GTK-DOC manual should build with current released tools.
  (But a copy of the output is included, so the tools are not required.)
- The inet_ntop function is now used through gnulib.
- API and ABI modifications:
  No changes since last version.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fran | 25 Oct 2005 23:39
Picon
Picon
Favicon

Why delay generating second and other keys?

If the computer spend 0,1 seconds making a key the first time. Making
second an other keys, the computer can spend 10 or more seconds.

I think that this can be a problem.

¿ Entropy ?
Permalink | Reply | 5 comments |
headers
Nikos Mavrogiannopoulos | 26 Oct 2005 11:09

Re: Why delay generating second and other keys?

On Tuesday 25 October 2005 23:39, Fran wrote:
> If the computer spend 0,1 seconds making a key the first time. Making
> second an other keys, the computer can spend 10 or more seconds.
> I think that this can be a problem.

I suppose you talk about certtool. This is a good thing. The first key 
depletes entropy from /dev/random. The second key the same. The system needs 
some time to gather entropy.

--

-- 
Nikos Mavrogiannopoulos
Permalink | Reply | 4 comments |
headers
Dima Barsky | 26 Oct 2005 22:31

Certificate verification failed

Hello,

I have a small python application which uses pycurl to 
download my bank statements every week. I was using 
pycurl built with openssl until recently and the 
application worked fine. A few days ago I upgraded the 
pycurl and the libcurl packages (they are now built with GnuTLS 1.2.8)
and the application stopped working, it does not accept the bank's
certificate any more. This small script illustrates the problem:

#!/usr/bin/python 
import pycurl 
c = pycurl.Curl() 
c.setopt(c.URL, 'https://www2.net.hsbc.com/') 
c.setopt(c.VERBOSE, 1) 
c.perform() 

Here is the script's output:

    * About to connect() to www2.net.hsbc.com port 443
    *   Trying 205.241.15.110... * connected
    * Connected to www2.net.hsbc.com (205.241.15.110) port 443
    * found 99 certificates in /etc/ssl/certs/ca-certificates.crt
    * server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt
    * Closing connection #0
    Traceback (most recent call last):
      File "test.py", line 6, in ?
        c.perform()
    pycurl.error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt')
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 26 Oct 2005 22:52
Picon
Favicon
Gravatar

Re: Certificate verification failed

On Wed, 26 Oct 2005, Dima Barsky wrote:

>    * found 99 certificates in /etc/ssl/certs/ca-certificates.crt
>    * server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt

...

> $ gnutls-cli -V --x509cafile /etc/ssl/certs/ca-certificates.crt 
> www2.net.hsbc.com

Allow me to just make a note that I believe Dima Barsky is using the latest 
libcurl and thus libcurl is using the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT 
option (as previously discussed on this list).

So it shouldn't fail because of that at least. (For the record: that problem 
was fixed in libcurl 7.14.1)

--

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Permalink | Reply | 1 comment |
headers
Fran | 26 Oct 2005 22:51
Picon
Picon
Favicon

Re: Why delay generating second and other keys?

     I. On Mér, 2005-10-26 at 11:09 +0200, Nikos Mavrogiannopoulos
        wrote:
> On Tuesday 25 October 2005 23:39, Fran wrote:
> > If the computer spend 0,1 seconds making a key the first time. Making
> > second an other keys, the computer can spend 10 or more seconds.
> > I think that this can be a problem.
> 
> I suppose you talk about certtool. This is a good thing. The first key 
> depletes entropy from /dev/random. The second key the same. The system needs 
> some time to gather entropy.

I see /dev/random code an seems that extract data from mouse, keyboard,
interrupts, etc.
If mouse and keyboard do not affect to the PC, the random number is
gathered very slow (very slow).
This is a problem of enclosure (deterministic system, low precision),
and only should be solved with special device (hardware) with precision
that see the caos of real world (more liberty degree).
Nothing to be done.

Another question:
Libcrypt use exit() in functions.

The function 
> gnutls_x509_privkey_generate (key, key_type, bits, 0)

does not return any value because libcrypt function use exit(). For this reason a program that have this
function can not known which is the problem.
For example if 
> gnutls_global_init();
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dima Barsky | 26 Oct 2005 22:57

Re: Certificate verification failed

On Wed, 26 Oct 2005, Daniel Stenberg wrote:

> Allow me to just make a note that I believe Dima Barsky is using the latest 
> libcurl and thus libcurl is using the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT 
> option (as previously discussed on this list).

That's correct, I'm using libcurl 7.15.0. Sorry, should've mentioned
this.

Anyway, it looks like it has nothing to do with libcurl, as
gnutls-cli also fails to verify this certificate.

Regards,
Dima.
Permalink | Reply | 0 comments |
headers
Nikos Mavrogiannopoulos | 26 Oct 2005 23:15

Re: Why delay generating second and other keys?

On Wednesday 26 October 2005 22:51, Fran wrote:

> > I suppose you talk about certtool. This is a good thing. The first key
> > depletes entropy from /dev/random. The second key the same. The system
> > needs some time to gather entropy.
> I see /dev/random code an seems that extract data from mouse, keyboard,
> interrupts, etc.
> If mouse and keyboard do not affect to the PC, the random number is
> gathered very slow (very slow).
> This is a problem of enclosure (deterministic system, low precision),
> and only should be solved with special device (hardware) with precision
> that see the caos of real world (more liberty degree).
> Nothing to be done.

If you generate the keys in one process then the libgcrypt random generator 
will optimize things a bit, since less reads from /dev/random will be 
required.

> Another question:
> Libcrypt use exit() in functions.
This looks like a bug in libgcrypt.
I will forward this to the libgcrypt list.

--

-- 
Nikos Mavrogiannopoulos
Permalink | Reply | 2 comments |
headers
Nikos Mavrogiannopoulos | 26 Oct 2005 23:30

Re: Certificate verification failed

On Wednesday 26 October 2005 22:31, Dima Barsky wrote:
> Hello,
> I have a small python application which uses pycurl to
> download my bank statements every week. I was using
> pycurl built with openssl until recently and the
> application worked fine. A few days ago I upgraded the
> pycurl and the libcurl packages (they are now built with GnuTLS 1.2.8)
> and the application stopped working, it does not accept the bank's
> certificate any more. This small script illustrates the problem:

Hi,
 I've run this server's certificates through certtool:

$ certtool -e -d 2 <list

[...]

Certificate[1]: O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign 
International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. 
LIABILITY LTD.(c)97 VeriSign
        Issued by: O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign 
International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. 
LIABILITY LTD.(c)97 VeriSign
        Verifying against certificate[2].
|<2>| ASSERT: verify.c:129
|<2>| ASSERT: verify.c:252
        Verification output: Not verified, Issuer is not a CA.
^^^^^^^^^^^^
This can be solved by upgrading your libcurl.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nikos Mavrogiannopoulos | 27 Oct 2005 11:29

Re: Certificate verification failed

On Thursday 27 October 2005 10:56, Simon Josefsson wrote:

> > This cannot be solved. This certificate uses MD2 which is not included in
> > libgcrypt as yet. I don't know if there are plans to include it in the
> > future though.
> We could add a MD2 implementation to gnulib, to make GnuTLS support
> this when MD2 is not available through libgcrypt.  I'm working on this
> now.
That would be nice to have. 

> However, I am skeptical about supporting MD2, and even MD5, by
> default.  I know GnuTLS certtool print a warning about MD5, but the
> library does not, and most GnuTLS library users probably doesn't
> either.
Hmmm... about MD5 we are going to get a bunch of complaints if it is not 
enabled by default. But that would be the right way to do given that is not 
that hard to generate colliding certificates:
http://www.win.tue.nl/~bdeweger/CollidingCertificates/index.html

>
> I think we should disable both MD2 and MD5, and introduce an API to
> modify gnutls_certificate_verify_peers2, a'la
>   gnutls_enable_insecure_algorithm (&session, GNUTLS_SIGN_RSA_MD2)
This will not be necessary if we introduce the flags below. verify_peers2  
will use the flags from gnutls_certificate_set_verify_flags().

> and a new gnutls_certificate_verify_flags enumeration type, for
> gnutls_x509_crt_verify calls, e.g.:
>   GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2
>   GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5
(Continue reading)

Permalink | Reply | 0 comments |

Gmane