From austin.einter at gmail.com  Sat Oct  3 07:47:30 2015
From: austin.einter at gmail.com (Austin Einter)
Date: Sat, 3 Oct 2015 11:17:30 +0530
Subject: [gnutls-help] Fingerprint
Message-ID: <CANXt1k_=c3zmCXAXikiYGgTgRhFHLc9NaP=Y4+cnzdsoAX8tKQ@mail.gmail.com>

Hi All
I am using gnutls in Ubuntu 14 system.
I am try to get fingerprint of certificate.
I have below queries.

1) Before handshake complete can I get the fingerprint of certificate
(local one)
2) If possible what are the steps, I have tried a lot but no luck..

Thanks
Austin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151003/257679e5/attachment.html>

From freddy77 at gmail.com  Sat Oct  3 10:55:55 2015
From: freddy77 at gmail.com (Frediano Ziglio)
Date: Sat, 3 Oct 2015 09:55:55 +0100
Subject: [gnutls-help] OAEP supported?
Message-ID: <CAHt6W4dYo9LC=6W6q68DWmbKw+hCYYYnqBoVtqSwpDoxiA-OEQ@mail.gmail.com>

Hi,
  I'm going mad trying to encrypt/decrypt some data using RSA with OAEP padding.

The detail. I'm trying to implement the part of a database server
(Sybase) to support
sending encrypted password instead of plain one. The server send a
public rsa key in
this format:

-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBANImhdQpGBmwkYveMfMPe0LmWj9vQOuqTdp0SOdQuNRtLEvr53axmV7jTx4ZCLTWnsAX
i2ap524TEMnJdhzRUQeRIk3U7LLfwklq4YOhxgXolqPbDWhjS4YIohmEX2Ldto0pHqRrs8bIWu6H
TvYYQhdiTAFJhQSvq5VoriL0MD+PAgMBAAE=
-----END RSA PUBLIC KEY-----

and some random data.

It uses RSA with OAEP (the message is the random data plus the password).

I would like to implement with GnuTLS but I found some problems:
- gnutls_pubkey_import_x509_raw does not recognizing the format above
as the only prefix it uses
  is "PUBLIC KEY", not "RSA PUBLIC KEY". I'm actually working around using
  gnutls_pem_base64_decode and using directly nettle_rsa_key_from_der_iterator;
- nettle does not support OAEP so the workaround was to implement a
rsa_encrypt_oaep
  instead of the rsa_encrypt_tr.

Now... this solution uses really few GnuTLS but a lot of lower level
functions (nettle and gmp
directly). OAEP is not that new in the RSA world so I think I'm doing
something wrong with
GnuTLS. Is there a way to this stuff with GnuTLS? I don't understand
the relationship between
GnuTLS and p11-kit modules. Looking at the code p11-kit module
supports OAEP but is not clear
how to use this module do to RSA encryption.

Regards,
  Frediano


From nmav at gnutls.org  Mon Oct  5 09:47:23 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 5 Oct 2015 09:47:23 +0200
Subject: [gnutls-help] OAEP supported?
In-Reply-To: <CAHt6W4dYo9LC=6W6q68DWmbKw+hCYYYnqBoVtqSwpDoxiA-OEQ@mail.gmail.com>
References: <CAHt6W4dYo9LC=6W6q68DWmbKw+hCYYYnqBoVtqSwpDoxiA-OEQ@mail.gmail.com>
Message-ID: <CAJU7zaLfDMgADnOKPAtibR2OO7gJ1-9rx40Xaota9d10baeueg@mail.gmail.com>

On Sat, Oct 3, 2015 at 10:55 AM, Frediano Ziglio <freddy77 at gmail.com> wrote:
> Hi,
>   I'm going mad trying to encrypt/decrypt some data using RSA with OAEP padding.
> The detail. I'm trying to implement the part of a database server
> (Sybase) to support
> sending encrypted password instead of plain one. The server send a
> public rsa key in
> this format:
> -----BEGIN RSA PUBLIC KEY-----
> MIGJAoGBANImhdQpGBmwkYveMfMPe0LmWj9vQOuqTdp0SOdQuNRtLEvr53axmV7jTx4ZCLTWnsAX
> i2ap524TEMnJdhzRUQeRIk3U7LLfwklq4YOhxgXolqPbDWhjS4YIohmEX2Ldto0pHqRrs8bIWu6H
> TvYYQhdiTAFJhQSvq5VoriL0MD+PAgMBAAE=
> -----END RSA PUBLIC KEY-----

Hello,
 This format isn't supported by gnutls. Only the SubjectPublicKeyInfo
format is (i.e., the "BEGIN PUBLIC KEY").

It is specified in: http://tools.ietf.org/html/rfc7468#section-13

> and some random data.
> It uses RSA with OAEP (the message is the random data plus the password).
>
> I would like to implement with GnuTLS but I found some problems:
> - gnutls_pubkey_import_x509_raw does not recognizing the format above
> as the only prefix it uses
>   is "PUBLIC KEY", not "RSA PUBLIC KEY". I'm actually working around using
>   gnutls_pem_base64_decode and using directly nettle_rsa_key_from_der_iterator;

We could extend the gnutls_pubkey_import() function to cope with these
public keys, if that's a widely used format. That could be using
header detection as in gnutls_x509_privkey_import(). If you have some
initial patch, I'd be happy to take a look at it.

> - nettle does not support OAEP so the workaround was to implement a
> rsa_encrypt_oaep  instead of the rsa_encrypt_tr.
> Now... this solution uses really few GnuTLS but a lot of lower level
> functions (nettle and gmp
> directly). OAEP is not that new in the RSA world so I think I'm doing
> something wrong with
> GnuTLS. Is there a way to this stuff with GnuTLS? I don't understand
> the relationship between
> GnuTLS and p11-kit modules. Looking at the code p11-kit module
> supports OAEP but is not clear how to use this module do to RSA encryption.

Indeed, RSASSA-PSS and OAEP are missing from nettle (and thus from
gnutls). So far TLS didn't use it so it was ignored. Moreover, because
there are no definitions for it, there is also no way to use it via
gnutls' interface for PKCS #11. I believe the fastest way to use it,
is via extending nettle's low level functions and bypassing gnutls for
that. If you send your nettle's extensions upstream, I would extend
the gnutls' API to use it.

regards,
Nikos


From mattroisang at gmail.com  Wed Oct  7 02:22:54 2015
From: mattroisang at gmail.com (Mat Troi)
Date: Tue, 6 Oct 2015 17:22:54 -0700
Subject: [gnutls-help] Autogen version>5.9 is needed to build gnutls3.4?
Message-ID: <CAA0a8nWJkA9+4CzfbiERmtXX=SNGZautTLrRgdOcTmm-nfE4fQ@mail.gmail.com>

Hi,
I am trying to build gnutls 3.4 from the source and it complains about
autogen 5.9.

/usr/ccs/bin/autogen /work/gnutls-3.4.1/src/ocsptool-args.def
Error in template /usr/share/autogen/optlib.tpl, line 557
        DEFINITIONS ERROR in /usr/share/autogen/optlib.tpl line 557 for
ocsptool-args.c:
        unknown arg type 'file' for infile
Failing Guile command:  = = = = =

(error (string-append "unknown arg type '"
                   (get "arg-type") "' for " flg-name))

It seems if I use 5.16 it is okay.  I can't update the current system to
autogen 5.16, is there a workaround?

Thanks,
Mat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151006/f12ad74a/attachment.html>

From nmav at gnutls.org  Wed Oct  7 19:22:35 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 07 Oct 2015 19:22:35 +0200
Subject: [gnutls-help] Autogen version>5.9 is needed to build gnutls3.4?
In-Reply-To: <CAA0a8nWJkA9+4CzfbiERmtXX=SNGZautTLrRgdOcTmm-nfE4fQ@mail.gmail.com>
References: <CAA0a8nWJkA9+4CzfbiERmtXX=SNGZautTLrRgdOcTmm-nfE4fQ@mail.gmail.com>
Message-ID: <1444238555.1951.1.camel@gnutls.org>

On Tue, 2015-10-06 at 17:22 -0700, Mat Troi wrote:
> Hi,
> I am trying to build gnutls 3.4 from the source and it complains 
> about autogen 5.9.  
> 
> /usr/ccs/bin/autogen /work/gnutls-3.4.1/src/ocsptool-args.def
> Error in template /usr/share/autogen/optlib.tpl, line 557
>         DEFINITIONS ERROR in /usr/share/autogen/optlib.tpl line 557 
> for ocsptool-args.c:
>         unknown arg type 'file' for infile
> Failing Guile command:  = = = = =
> 
> (error (string-append "unknown arg type '"
>                    (get "arg-type") "' for " flg-name))
> 
> It seems if I use 5.16 it is okay.  I can't update the current system 
> to autogen 5.16, is there a workaround?

You don't need autogen to compile from source. Use "--enable-local
-libopts".

regards,
Nikos



From mattroisang at gmail.com  Thu Oct  8 20:31:47 2015
From: mattroisang at gmail.com (Mat Troi)
Date: Thu, 8 Oct 2015 11:31:47 -0700
Subject: [gnutls-help] Autogen version>5.9 is needed to build gnutls3.4?
In-Reply-To: <1444238555.1951.1.camel@gnutls.org>
References: <CAA0a8nWJkA9+4CzfbiERmtXX=SNGZautTLrRgdOcTmm-nfE4fQ@mail.gmail.com>
 <1444238555.1951.1.camel@gnutls.org>
Message-ID: <CAA0a8nWYh03Oa54fdq3DJf5mMxFO-tH12sfQvBvXbzbZgEekWg@mail.gmail.com>

Hi Nikos,

That works.  Thanks.

Regards,
Mat

On Wednesday, October 7, 2015, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:

> On Tue, 2015-10-06 at 17:22 -0700, Mat Troi wrote:
> > Hi,
> > I am trying to build gnutls 3.4 from the source and it complains
> > about autogen 5.9.
> >
> > /usr/ccs/bin/autogen /work/gnutls-3.4.1/src/ocsptool-args.def
> > Error in template /usr/share/autogen/optlib.tpl, line 557
> >         DEFINITIONS ERROR in /usr/share/autogen/optlib.tpl line 557
> > for ocsptool-args.c:
> >         unknown arg type 'file' for infile
> > Failing Guile command:  = = = = =
> >
> > (error (string-append "unknown arg type '"
> >                    (get "arg-type") "' for " flg-name))
> >
> > It seems if I use 5.16 it is okay.  I can't update the current system
> > to autogen 5.16, is there a workaround?
>
> You don't need autogen to compile from source. Use "--enable-local
> -libopts".
>
> regards,
> Nikos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151008/45b0ec39/attachment.html>

From mathstuf at gmail.com  Wed Oct 14 02:55:31 2015
From: mathstuf at gmail.com (Ben Boeckel)
Date: Tue, 13 Oct 2015 20:55:31 -0400
Subject: [gnutls-help] Reliable algorithm string
Message-ID: <20151014005531.GC2191@bronto-burt.dev.benboeckel.net>

Hi,

For a couple projects (right now task[1] and eventd[2]), I'm trying to
get them to use a protocol string to enforce better encryption (or,
rather, disable known-bad encryption). The problem is that the string to
control this is a really bad API stability point. If an algorithm that
is excluded by the string is removed in GnuTLS, the whole string is
considered invalid. For example:

    %SERVER_PRECEDENCE:NORMAL:-VERS-SSL3.0:-VERS-TLS1.0:-3DES-CBC:-ARCFOUR-128:-ARCFOUR-40:-MD5

will fail on newer GnuTLS versions (at least 3.4.5) because ARCFOUR
support has (apparently?) been removed. But it needs to be there to turn
it off on older GnuTLS versions.

Is there a way to construct such a string to be compatible across a wide
range of GnuTLS versions?

(Please keep me CC'd; I am not subscribed.)

Thanks,

--Ben

[1]http://taskwarrior.org/
[2]http://www.eventd.org/


From nmav at gnutls.org  Thu Oct 15 13:34:12 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 15 Oct 2015 13:34:12 +0200
Subject: [gnutls-help] Reliable algorithm string
In-Reply-To: <20151014005531.GC2191@bronto-burt.dev.benboeckel.net>
References: <20151014005531.GC2191@bronto-burt.dev.benboeckel.net>
Message-ID: <CAJU7zaLcqYACHAJvrM4FT014+LFKG784dY2atrHZ2mDhqDSJuA@mail.gmail.com>

On Wed, Oct 14, 2015 at 2:55 AM, Ben Boeckel <mathstuf at gmail.com> wrote:
> Hi,
>
> For a couple projects (right now task[1] and eventd[2]), I'm trying to
> get them to use a protocol string to enforce better encryption (or,
> rather, disable known-bad encryption). The problem is that the string to
> control this is a really bad API stability point. If an algorithm that
> is excluded by the string is removed in GnuTLS, the whole string is
> considered invalid. For example:
>     %SERVER_PRECEDENCE:NORMAL:-VERS-SSL3.0:-VERS-TLS1.0:-3DES-CBC:-ARCFOUR-128:-ARCFOUR-40:-MD5
> will fail on newer GnuTLS versions (at least 3.4.5) because ARCFOUR
> support has (apparently?) been removed. But it needs to be there to turn
> it off on older GnuTLS versions.

Hello Ben,
 That's a correct observation in general, but to the point, I think it
is better to go with the defaults. In that particular example you are
referring to ARCFOUR-40, but this was never enabled by default in the
normal level. Thus there is no need to remove it.

The fact is that all the applications that decide to set some
"reasonable" defaults and not rely on gnutls', end up not working, or
providing insecure defaults after several years, because they don't
actively maintain those defaults. For example an application that set
defaults in 2009 and never touched them again now cannot talk to most
servers because it was explicitly enabling RC4 (due to some attack on
cbc at the time), and only enabling SSL 3.0 and TLS 1.0. So my
recommendation is to use gnutls_set_default_priorities() and let the
version of gnutls you have pick the best, and possibly allow the user
to override the defaults by reading some custom string via command
line of config file.

> Is there a way to construct such a string to be compatible across a wide
> range of GnuTLS versions?

This is tricky to do in a straightforward way. If I disable failure
when an unknown algorithm is disabled, I introduce the risk to not
disable an algorithm due to a typo (e.g, "NORMAL:-EAS-128-CBC"). If
despite my recommendation you'd like to pursue custom settings, what
could be done without introducing new API is the following. Postpone
failure for parsing error when disabling an unknown algorithm, set
everything that can be set with the given priority string and fail at
the function exit. That way the caller could ignore parsing errors if
needed. What do you think?

regards,
Nikos


From mathstuf at gmail.com  Thu Oct 15 14:09:47 2015
From: mathstuf at gmail.com (Ben Boeckel)
Date: Thu, 15 Oct 2015 08:09:47 -0400
Subject: [gnutls-help] Reliable algorithm string
In-Reply-To: <CAJU7zaLcqYACHAJvrM4FT014+LFKG784dY2atrHZ2mDhqDSJuA@mail.gmail.com>
References: <20151014005531.GC2191@bronto-burt.dev.benboeckel.net>
 <CAJU7zaLcqYACHAJvrM4FT014+LFKG784dY2atrHZ2mDhqDSJuA@mail.gmail.com>
Message-ID: <20151015120947.GA12481@bronto-burt.dev.benboeckel.net>

On Thu, Oct 15, 2015 at 13:34:12 +0200, Nikos Mavrogiannopoulos wrote:
>  That's a correct observation in general, but to the point, I think it
> is better to go with the defaults. In that particular example you are
> referring to ARCFOUR-40, but this was never enabled by default in the
> normal level. Thus there is no need to remove it.

First of all, I'm interested in the server-side of things more than the
client side. Clients should usually be set up for compatibility since
it's a zoo out there. Specialized applications should probably set up
higher barriers to use. So my goal is to ensure applications can match
the Intermediate profile here (best would be Modern, but I've found that
GnuTLS doesn't accept specific enough exclusions to exclude an
Intermediate algorithm or two and still have Modern with more than 2 or
3 algorithms):

    https://wiki.mozilla.org/Security/Server_Side_TLS

This is as close as I've been able to come. As for the removals, I only
added them if they caused issues with Intermediate as determined by:

    https://github.com/jvehent/cipherscan

so whatever version my server was running had ARCFOUR-40 somewhere which
needed to be excluded; it may have been an old GnuTLS or had a bug; it's
a FreeBSD 9 machine with GnuTLS from ports.

At a *minimum* %SERVER_PRECEDENCE should really be set for servers;
there's no reason that when GnuTLS gets upgraded to prefer better
algorithms, clients can just force it to back down again.

> The fact is that all the applications that decide to set some
> "reasonable" defaults and not rely on gnutls', end up not working, or
> providing insecure defaults after several years, because they don't
> actively maintain those defaults. For example an application that set

In my cases, all I'd ever be doing is removing algorithms, so how would
the sercurity degrade over time (assuming GnuTLS is suitably upgraded
over that time)?

> defaults in 2009 and never touched them again now cannot talk to most
> servers because it was explicitly enabling RC4 (due to some attack on
> cbc at the time), and only enabling SSL 3.0 and TLS 1.0. So my
> recommendation is to use gnutls_set_default_priorities() and let the
> version of gnutls you have pick the best, and possibly allow the user
> to override the defaults by reading some custom string via command
> line of config file.

Well, even if the application can't set defaults and it should be the
user, now *I* can't set defaults reliably because of underlying version
changes; the ball just gets moved around with this policy.

> This is tricky to do in a straightforward way. If I disable failure
> when an unknown algorithm is disabled, I introduce the risk to not
> disable an algorithm due to a typo (e.g, "NORMAL:-EAS-128-CBC"). If
> despite my recommendation you'd like to pursue custom settings, what
> could be done without introducing new API is the following. Postpone
> failure for parsing error when disabling an unknown algorithm, set
> everything that can be set with the given priority string and fail at
> the function exit. That way the caller could ignore parsing errors if
> needed. What do you think?

That would be suitable I think. Certainly better than falling back to
the default profile.

Actually, even whle replying, it occurred to be that it would be even
better if GnuTLS could provide MOZILLA_OLD, MOZILLA_INTERMEDIATE, and
MOZILLA_MODERN profiles (to replace NORMAL). Then applications wouldn't
need to maintain an exclusion list with a bunch of algorithms anyways.

--Ben


From nmav at gnutls.org  Thu Oct 15 17:49:41 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 15 Oct 2015 17:49:41 +0200
Subject: [gnutls-help] Reliable algorithm string
In-Reply-To: <20151015120947.GA12481@bronto-burt.dev.benboeckel.net>
References: <20151014005531.GC2191@bronto-burt.dev.benboeckel.net>
 <CAJU7zaLcqYACHAJvrM4FT014+LFKG784dY2atrHZ2mDhqDSJuA@mail.gmail.com>
 <20151015120947.GA12481@bronto-burt.dev.benboeckel.net>
Message-ID: <CAJU7zaLjC_kestOHtUXke6s9+e_dSYBuH2ZaeNSQy4iV2fxg5A@mail.gmail.com>

On Thu, Oct 15, 2015 at 2:09 PM, Ben Boeckel <mathstuf at gmail.com> wrote:
> On Thu, Oct 15, 2015 at 13:34:12 +0200, Nikos Mavrogiannopoulos wrote:
>>  That's a correct observation in general, but to the point, I think it
>> is better to go with the defaults. In that particular example you are
>> referring to ARCFOUR-40, but this was never enabled by default in the
>> normal level. Thus there is no need to remove it.
> First of all, I'm interested in the server-side of things more than the
> client side. Clients should usually be set up for compatibility since
> it's a zoo out there. Specialized applications should probably set up
> higher barriers to use. So my goal is to ensure applications can match
> the Intermediate profile here (best would be Modern, but I've found that
> GnuTLS doesn't accept specific enough exclusions to exclude an
> Intermediate algorithm or two and still have Modern with more than 2 or
> 3 algorithms):

I am not sure I follow, could you give an example?

>     https://wiki.mozilla.org/Security/Server_Side_TLS
> This is as close as I've been able to come. As for the removals, I only
> added them if they caused issues with Intermediate as determined by:


>
>     https://github.com/jvehent/cipherscan
> so whatever version my server was running had ARCFOUR-40 somewhere which
> needed to be excluded; it may have been an old GnuTLS or had a bug; it's
> a FreeBSD 9 machine with GnuTLS from ports.

That is more likely to be an issue in the tool that checks
capabilities . GnuTLS never negotiated export ciphers by default. They
had to be enabled separately even at first release that supported
them, and were removed in 2013.

> At a *minimum* %SERVER_PRECEDENCE should really be set for servers;
> there's no reason that when GnuTLS gets upgraded to prefer better
> algorithms, clients can just force it to back down again.

Correct. My argumentation would be, to have it so that the server
prefers the ciphers it has optimized hardware for (e.g., AESNI).

>> The fact is that all the applications that decide to set some
>> "reasonable" defaults and not rely on gnutls', end up not working, or
>> providing insecure defaults after several years, because they don't
>> actively maintain those defaults. For example an application that set
> In my cases, all I'd ever be doing is removing algorithms, so how would
> the sercurity degrade over time (assuming GnuTLS is suitably upgraded
> over that time)?

It wouldn't. Your settings were carefully written.

>> defaults in 2009 and never touched them again now cannot talk to most
>> servers because it was explicitly enabling RC4 (due to some attack on
>> cbc at the time), and only enabling SSL 3.0 and TLS 1.0. So my
>> recommendation is to use gnutls_set_default_priorities() and let the
>> version of gnutls you have pick the best, and possibly allow the user
>> to override the defaults by reading some custom string via command
>> line of config file.
> Well, even if the application can't set defaults and it should be the
> user, now *I* can't set defaults reliably because of underlying version
> changes; the ball just gets moved around with this policy.

Indeed, but a config file or a command line argument doesn't require a
software release to be fixed.

>> This is tricky to do in a straightforward way. If I disable failure
>> when an unknown algorithm is disabled, I introduce the risk to not
>> disable an algorithm due to a typo (e.g, "NORMAL:-EAS-128-CBC"). If
>> despite my recommendation you'd like to pursue custom settings, what
>> could be done without introducing new API is the following. Postpone
>> failure for parsing error when disabling an unknown algorithm, set
>> everything that can be set with the given priority string and fail at
>> the function exit. That way the caller could ignore parsing errors if
>> needed. What do you think?
> That would be suitable I think. Certainly better than falling back to
> the default profile.

Or maybe it is easier to simply ignore algorithms that existed in the
past. That's a bit cleaner and allows backwards compatibility.

> Actually, even whle replying, it occurred to be that it would be even
> better if GnuTLS could provide MOZILLA_OLD, MOZILLA_INTERMEDIATE, and
> MOZILLA_MODERN profiles (to replace NORMAL). Then applications wouldn't
> need to maintain an exclusion list with a bunch of algorithms anyways.

That's not a bad idea to have. Feel free to open an issue at the issue
tracker for that. I am a bit sceptical of it though, because it will
introduce quite some maintenance burden both for gnutls and
applications. Also I don't know whether mozilla will keep up with
these settings. Gnutls' default settings used to be much better than
the ones used by mozilla browser for quite long time, and it may be
better to catch up on the normal level rather than introduce new
strings.

regards,
Nikos


From mathstuf at gmail.com  Thu Oct 15 19:39:17 2015
From: mathstuf at gmail.com (Ben Boeckel)
Date: Thu, 15 Oct 2015 13:39:17 -0400
Subject: [gnutls-help] Reliable algorithm string
In-Reply-To: <CAJU7zaLjC_kestOHtUXke6s9+e_dSYBuH2ZaeNSQy4iV2fxg5A@mail.gmail.com>
References: <20151014005531.GC2191@bronto-burt.dev.benboeckel.net>
 <CAJU7zaLcqYACHAJvrM4FT014+LFKG784dY2atrHZ2mDhqDSJuA@mail.gmail.com>
 <20151015120947.GA12481@bronto-burt.dev.benboeckel.net>
 <CAJU7zaLjC_kestOHtUXke6s9+e_dSYBuH2ZaeNSQy4iV2fxg5A@mail.gmail.com>
Message-ID: <20151015173917.GB13255@megas.khq.kitware.com>

On Thu, Oct 15, 2015 at 17:49:41 +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, Oct 15, 2015 at 2:09 PM, Ben Boeckel <mathstuf at gmail.com> wrote:
> > First of all, I'm interested in the server-side of things more than the
> > client side. Clients should usually be set up for compatibility since
> > it's a zoo out there. Specialized applications should probably set up
> > higher barriers to use. So my goal is to ensure applications can match
> > the Intermediate profile here (best would be Modern, but I've found that
> > GnuTLS doesn't accept specific enough exclusions to exclude an
> > Intermediate algorithm or two and still have Modern with more than 2 or
> > 3 algorithms):
> 
> I am not sure I follow, could you give an example?

For example, I run a taskwarrior sync server which uses client certs and
such to secure the connection; there is no need to support any old
algorithms to include support for systems too much older than the first
release of the sync server.

> That is more likely to be an issue in the tool that checks
> capabilities . GnuTLS never negotiated export ciphers by default. They
> had to be enabled separately even at first release that supported
> them, and were removed in 2013.

Hmm. Maybe I had removed them before trying the rest; it's been 9 months
or so.

> Correct. My argumentation would be, to have it so that the server
> prefers the ciphers it has optimized hardware for (e.g., AESNI).

Sure; I prefer security, but I also run my own hardware which doesn't
have to deal with an absurd number of connections per second as well.

> It wouldn't. Your settings were carefully written.

My settings are synced across a range of devices of varying software
ages (Fedora 21 up to Rawhide). Maintaining patches on top of the base
is possible, but not the most fun thing to do :) .

> Indeed, but a config file or a command line argument doesn't require a
> software release to be fixed.

True.

> Or maybe it is easier to simply ignore algorithms that existed in the
> past. That's a bit cleaner and allows backwards compatibility.

This would be good as well :) .

> > Actually, even whle replying, it occurred to be that it would be even
> > better if GnuTLS could provide MOZILLA_OLD, MOZILLA_INTERMEDIATE, and
> > MOZILLA_MODERN profiles (to replace NORMAL). Then applications wouldn't
> > need to maintain an exclusion list with a bunch of algorithms anyways.
> 
> That's not a bad idea to have. Feel free to open an issue at the issue
> tracker for that.

Will do.

> I am a bit sceptical of it though, because it will
> introduce quite some maintenance burden both for gnutls and
> applications. Also I don't know whether mozilla will keep up with
> these settings. Gnutls' default settings used to be much better than
> the ones used by mozilla browser for quite long time, and it may be
> better to catch up on the normal level rather than introduce new
> strings.

The page is updated rarely. I expect one for the SHA stuff in the not
too distant future, but since the general strategy is to remove old
algorithms, any new algorithms shouldn't be excluded accidentally.

--Ben


From nmav at gnutls.org  Tue Oct 20 18:19:30 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 20 Oct 2015 18:19:30 +0200
Subject: [gnutls-help] gnutls 3.4.6
Message-ID: <1445357970.19238.1.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.4.6. This version fixes bugs and adds
minor features to the next stable branch.


* Version 3.4.6 (released 2015-10-20)

** libgnutls: Added new simple verification functions. That avoids the
   need to install a callback to perform certificate verification. See
   doc/examples/ex-client-x509.c for usage.

** libgnutls: Introduced the security parameter 'future' which is at
   the 256-bit level of security, and 'ultra' was aligned to its 
   documented size at 192-bits.

** libgnutls: When writing a certificate into a PKCS #11 token, ensure
   that CKA_SERIAL_NUMBER and CKA_ISSUER are written. Reported by Sumit
   Bose.

** libgnutls: Allow the presence of legacy ciphers and key exchanges in
   priority strings and consider them a no-op.

** libgnutls: Handle the extended master secret as a mandatory 
   extension. That fixes incompatibility issues with Chromium (#45). 
   Reported by Hubert Kario.

** libgnutls: Added the ability to copy a public key into a PKCS #11
   token.

** tools: Added support for LDAP and XMPP negotiation for STARTTLS.

** p11tool: Allow writing a public key into a PKCS #11 token.

** certtool: Key generation security level was switched to HIGH. That
   is, by default the tool generates 3072 bit keys for RSA and DSA.

** API and ABI modifications:
gnutls_session_set_verify_function: Added
gnutls_session_set_verify_cert: Added
gnutls_session_set_verify_cert2: Added
gnutls_session_get_verify_cert_status: Added
gnutls_pkcs11_copy_pubkey: Added


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.??A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.6.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.6.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.6.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.6.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From marko at pacujo.net  Tue Oct 20 20:23:56 2015
From: marko at pacujo.net (Marko Rauhamaa)
Date: Tue, 20 Oct 2015 21:23:56 +0300
Subject: [gnutls-help] What gives?
Message-ID: <87eggp760z.fsf@elektro.pacujo.net>


I'm trying to get gnutls-cli-debug to talk to gnutls-serv (3.1.28). What
am I doing wrong?

========================================================================
$ gnutls-cli-debug --port=12345 localhost
Resolving 'localhost'...
Connecting to '127.0.0.1:12345'...
Checking for SSL 3.0 support... no
Connecting to '127.0.0.1:12345'...
Checking whether %COMPAT is required... yes
Connecting to '127.0.0.1:12345'...
Checking for TLS 1.0 support... no
Connecting to '127.0.0.1:12345'...
Checking for TLS 1.1 support... no
Connecting to '127.0.0.1:12345'...
Checking fallback from TLS 1.1 to... failed
Connecting to '127.0.0.1:12345'...
Checking for TLS 1.2 support... no
Connecting to '127.0.0.1:12345'...
Checking whether we need to disable TLS 1.2... yes

Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1
========================================================================


========================================================================
$ gnutls-serv --port=12345 --echo --pgpkeyfile=secret.asc \
     --pgpkeyring=ring.asc --pgpcertfile=public.asc \
     --priority=NORMAL:+CTYPE-OPENPGP
Set static Diffie-Hellman parameters, consider --dhparams.
Echo Server listening on IPv4 0.0.0.0 port 12345...done
Echo Server listening on IPv6 :: port 12345...done

* Accepted connection from IPv4 127.0.0.1 port 46409 on Tue Oct 20 21:14
:51 2015
Error in handshake
Error: Could not negotiate a supported cipher suite.
========================================================================


Marko


From BHC at insight.dk  Thu Oct 22 12:15:19 2015
From: BHC at insight.dk (=?iso-8859-1?Q?Bj=F8rn_H=2E_Christensen?=)
Date: Thu, 22 Oct 2015 10:15:19 +0000
Subject: [gnutls-help] Alternative Private keys?
Message-ID: <C834941DD0525940AED2FADEFAA9CBCA01357ECF5E@Shelob.Insight.local>

Hello,


I am looking at alternative ways to provide private keys  for  GnuTLS.

gnutls_privkey_import_ext2 and gnutls_privkey_import_ext3

Both function have a sign_func and decrypt_func defined as follows:

typedef int (*gnutls_privkey_sign_func) (gnutls_privkey_t key,
                                                                                       void *userdata,
                                                                                       const gnutls_datum_t *
                                                                                       raw_data,
                                                                                       gnutls_datum_t * signature);

typedef int (*gnutls_privkey_decrypt_func) (gnutls_privkey_t key,
                                                                                           void *userdata,
                                                                                           const gnutls_datum_t *
                                                                                           ciphertext,
                                                                                           gnutls_datum_t * plaintext);

I would assume (but are not sure) that GnuTLS need to Sign a hash and verify a hash  signature combination.

Are my assumptions wrong? Do GnuTLS actually need to decrypt ciphertext to plaintext, in other cases than verifying a hash signature combination?


/bhc


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151022/3c4b32a2/attachment.html>

From nmav at gnutls.org  Thu Oct 22 13:06:45 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 22 Oct 2015 13:06:45 +0200
Subject: [gnutls-help] Alternative Private keys?
In-Reply-To: <C834941DD0525940AED2FADEFAA9CBCA01357ECF5E@Shelob.Insight.local>
References: <C834941DD0525940AED2FADEFAA9CBCA01357ECF5E@Shelob.Insight.local>
Message-ID: <CAJU7zaJsLgGmFMppLTKbJH7GkowJz=f_xy=prgdwea-pvnVO5g@mail.gmail.com>

On Thu, Oct 22, 2015 at 12:15 PM, Bj?rn H. Christensen <BHC at insight.dk> wrote:
> Hello,
> I am looking at alternative ways to provide private keys  for  GnuTLS.
> gnutls_privkey_import_ext2 and gnutls_privkey_import_ext3
> Both function have a sign_func and decrypt_func defined as follows:
> typedef int (*gnutls_privkey_sign_func) (gnutls_privkey_t key,
> void *userdata,
> const gnutls_datum_t *
> raw_data,
> gnutls_datum_t * signature);
> typedef int (*gnutls_privkey_decrypt_func) (gnutls_privkey_t key,
> void *userdata,
> const gnutls_datum_t *
> ciphertext,
> gnutls_datum_t * plaintext);

> I would assume (but are not sure) that GnuTLS need to Sign a hash and verify
> a hash  signature combination.

If I understand correctly the question is when gnutls does it need the
sign or decrypt function? If yes, then the answer is it depends. For
some ciphersuites (RSA, PSK-RSA) decryption is required, while for the
DHE and ECDHE ciphersuites only signing is required.

regards,
Nikos


From nmav at gnutls.org  Tue Oct 27 15:56:53 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 27 Oct 2015 15:56:53 +0100
Subject: [gnutls-help] CFP: Security Devroom @ FOSDEM'16
Message-ID: <CAJU7zaKQQ1iNn125r36Lw8LmKB6k+9GP6U0LEY-SoM4Kg0oTtg@mail.gmail.com>

[I'll be co-organizing the security devroom, if loyal list members are
around ping me! ]

Next  FOSDEM [1] will, again, have a security devroom, this time on
the topic  of "Security and Privacy in modern software". We'd like to
invite submissions of talks and presentations from developers,
security researchers and other interested representatives of open
source and free software and hardware projects.

This is the call for talks and presentations that will take place in
the Security devroom at FOSDEM 2016.

Our topic this year:
Cryptography has been the foundation of modern crypto software,
however, it is only a small fraction of the technology required to
achieve security and privacy for users. Thus this year's topic is to
focus on the other parts that make software secure: usability,  the
protection against side-channels, message length analysis,
fingerprinting, secure coding practices, code review processes etc. We
welcome presentations of security software and hardware which take
into account these factors, and presentations that analyze other's
solutions.

For up-to-date submission and event information:
https://github.com/security-devroom/fosdem-2016

The security devroom will be held on Sunday 31st of January 2016 in
Brussels, Belgium at ULB.

Feel free to forward this announcement to any relevant FOSS project
mailing list.

[1] https://fosdem.org/2016/
[2] https://github.com/security-devroom/fosdem-2016


From yshvedov at wimarksystems.com  Wed Oct 28 14:12:04 2015
From: yshvedov at wimarksystems.com (Yury Shvedov)
Date: Wed, 28 Oct 2015 16:12:04 +0300
Subject: [gnutls-help] Asynchronous transport
Message-ID: <5630C9A4.4060409@wimarksystems.com>

Hi!

I'm back with my problem, described here: 
(http://lists.gnutls.org/pipermail/gnutls-help/2015-April/003852.html).
The client begins handshake, with NONBLOCK exchange and after receiving 
HELLO VERIFY REQUEST it stops working and seems to waiting for other 
data, calling pull_timeout with non-zero timeout once and then - zero 
timeout endlessly.

Here I have logs of server and client.

Such behaviour I have for both 3.3.17 and 3.4.6 versions.

Thank you!

-- 
Kind regards
Yury Shvedov
WiMark Systems

-------------- next part --------------
[Wed Oct 28 15:26:37 2015]   Log initiated.
[Wed Oct 28 15:26:37 2015] DEBUG:   test-modules.c:63 in main    Kernel init, loading modules
[Wed Oct 28 15:26:37 2015] DEBUG:   ac-module-manager.c:84 in ac_module_manager_load_module    Loading module from `/home/shved/usr/lib/yaocw/try-dtls-client.so'
[Wed Oct 28 15:26:37 2015] DEBUG:   test-modules.c:66 in main    Modules loaded, running kernel
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:69 in on_start    GNUTLS version 3.4.6
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: ASSERT: mpi.c:240
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Allocating epoch #0
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: ASSERT: gnutls_constate.c:588
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Allocating epoch #1
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256 (C0.86)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384 (C0.87)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1 (C0.09)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1 (C0.0A)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256 (C0.72)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384 (C0.73)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CCM (C0.AC)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CCM (C0.AD)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_3DES_EDE_CBC_SHA1 (C0.08)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384 (C0.30)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_CBC_SHA256 (C0.27)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_CBC_SHA384 (C0.28)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_AES_128_GCM_SHA256 (00.9C)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_AES_256_GCM_SHA384 (00.9D)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_GCM_SHA256 (C0.7A)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_GCM_SHA384 (C0.7B)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CBC_SHA1 (00.2F)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CBC_SHA256 (00.3C)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CBC_SHA1 (00.35)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CBC_SHA256 (00.3D)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_CBC_SHA1 (00.41)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_CBC_SHA256 (00.BA)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_CBC_SHA1 (00.84)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_CBC_SHA256 (00.C0)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CCM (C0.9C)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CCM (C0.9D)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_RSA_3DES_EDE_CBC_SHA1 (00.0A)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_GCM_SHA256 (00.9E)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_GCM_SHA384 (00.9F)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.7C)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.7D)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CBC_SHA1 (00.33)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CBC_SHA256 (00.67)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_CBC_SHA1 (00.39)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_CBC_SHA256 (00.6B)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_CBC_SHA1 (00.45)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_CBC_SHA256 (00.BE)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_CBC_SHA1 (00.88)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_CBC_SHA256 (00.C4)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CCM (C0.9E)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_CCM (C0.9F)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: Keeping ciphersuite: GNUTLS_DHE_RSA_3DES_EDE_CBC_SHA1 (00.16)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: Sending extension EXT MASTER SECRET (0 bytes)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: Sending extension ENCRYPT THEN MAC (0 bytes)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: Sending extension STATUS REQUEST (5 bytes)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: Sending extension SAFE RENEGOTIATION (1 bytes)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: Sending extension SESSION TICKET (0 bytes)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: Sending extension SUPPORTED ECC (12 bytes)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (4.1) RSA-SHA256
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (4.3) ECDSA-SHA256
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (5.1) RSA-SHA384
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (5.3) ECDSA-SHA384
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (6.1) RSA-SHA512
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (6.3) ECDSA-SHA512
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (3.1) RSA-SHA224
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (3.3) ECDSA-SHA224
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (2.1) RSA-SHA1
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: sent signature algo (2.3) ECDSA-SHA1
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: EXT[0x653bed0]: Sending extension SIGNATURE ALGORITHMS (22 bytes)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: CLIENT HELLO was queued [236 bytes]
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HWRITE: enqueued [CLIENT HELLO] 236. Total 236 bytes.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HWRITE FLUSH: 236 bytes in buffer.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: DTLS[0x653bed0]: Start of flight transmission.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: DTLS[0x653bed0]: Sending Packet[0] fragment CLIENT HELLO(1) with length: 224, offset: 0, fragment length: 224
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Preparing Packet Handshake(22) with length: 236 and min pad: 0
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: ENC[0x653bed0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: WRITE: enqueued 249 bytes for 0x651f610. Total 249 bytes.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 249
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: WRITE FLUSH: 249 bytes in buffer.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:233 in push    Client: push Data 249
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: WRITE: wrote 249 bytes, 0 bytes left.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:221 in pull_timeout    pull timeout
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: ASSERT: gnutls_dtls.c:415
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:201 in timeout    Timeout 988
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:96 in on_start    Start out
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:123 in handler    Client: Data
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HWRITE FLUSH: 236 bytes in buffer.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: WRITE FLUSH: 0 bytes in buffer.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: ASSERT: gnutls_buffers.c:695
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:221 in pull_timeout    pull timeout
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:242 in pull    Pull: 0x6614ef0
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:248 in pull    Client: pull Data 44 16732
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: READ: Got 44 bytes from 0x651f610
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: READ: read 44 bytes from 0x651f610
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: RB: Have 0 bytes into buffer. Adding 44 bytes.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: RB: Requested 13 bytes
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: SSL 254.255 Handshake packet received. Epoch 0, length: 31
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Expected Packet Handshake(22)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Received Packet Handshake(22) with length: 31
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Decrypted Packet[0.80] Handshake(22) with length: 31
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: BUF[REC]: Inserted 31 bytes of Data(22)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: HSK[0x653bed0]: HELLO VERIFY REQUEST (3) was received. Length 19[19], frag offset 0, frag length: 19, sequence: 151
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: DTLS[0x653bed0]: End of flight transmission.
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: ASSERT: gnutls_buffers.c:1158
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:242 in pull    Pull: (nil)
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: READ: -1 returned from 0x651f610, errno=11
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: ASSERT: gnutls_buffers.c:588
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-client.cpp:201 in timeout    Timeout 843
[Wed Oct 28 15:26:38 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: ASSERT: gnutls_buffers.c:1158
[Wed Oct 28 15:26:38 2015] DEBUG:   try-dtls-client.cpp:242 in pull    Pull: (nil)
[Wed Oct 28 15:26:38 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: READ: -1 returned from 0x651f610, errno=11
[Wed Oct 28 15:26:38 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: ASSERT: gnutls_buffers.c:588
[Wed Oct 28 15:26:38 2015] DEBUG:   try-dtls-client.cpp:201 in timeout    Timeout 0
^C[Wed Oct 28 15:26:43 2015] DEBUG: try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Start of epoch cleanup
[Wed Oct 28 15:26:43 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: End of epoch cleanup
[Wed Oct 28 15:26:43 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Epoch #0 freed
[Wed Oct 28 15:26:43 2015] DEBUG:   try-dtls-client.cpp:261 in gnutls_log    Gnutls: REC[0x653bed0]: Epoch #1 freed
[Wed Oct 28 15:26:43 2015] DEBUG:   test-modules.c:83 in main    Kernel stop

-------------- next part --------------
[Wed Oct 28 15:26:12 2015]   Log initiated.
[Wed Oct 28 15:26:12 2015] DEBUG:   test-modules.c:63 in main    Kernel init, loading modules
[Wed Oct 28 15:26:12 2015] DEBUG:   ac-module-manager.c:84 in ac_module_manager_load_module    Loading module from `/home/shved/usr/lib/yaocw/try-dtls-server.so'
[Wed Oct 28 15:26:12 2015] DEBUG:   test-modules.c:66 in main    Modules loaded, running kernel
[Wed Oct 28 15:26:12 2015] DEBUG:   try-dtls-server.cpp:319 in gnutls_log    Gnutls: ASSERT: mpi.c:240
[Wed Oct 28 15:26:12 2015] DEBUG:   try-dtls-server.cpp:319 in gnutls_log    Gnutls: ASSERT: crl.c:1309
[Wed Oct 28 15:26:12 2015] DEBUG:   try-dtls-server.cpp:319 in gnutls_log    Gnutls: ASSERT: verify-high2.c:103
[Wed Oct 28 15:26:13 2015] DEBUG:   try-dtls-server.cpp:319 in gnutls_log    Gnutls: ASSERT: extensions.c:65
[Wed Oct 28 15:26:13 2015] DEBUG:   try-dtls-server.cpp:205 in generate_dh_params    Generating dh params
[Wed Oct 28 15:26:21 2015] DEBUG:   try-dtls-server.cpp:215 in generate_dh_params    Generating dh params done
[Wed Oct 28 15:26:21 2015] DEBUG:   try-dtls-server.cpp:95 in create_socket    Creating socket on port 6666
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-server.cpp:319 in gnutls_log    Gnutls: ASSERT: gnutls_dtls.c:1024
[Wed Oct 28 15:26:37 2015] DEBUG:   try-dtls-server.cpp:298 in push    Server: push Data 44
[Wed Oct 28 15:26:42 2015] DEBUG: test-modules.c:83 in main    Kernel stop

From yshvedov at wimarksystems.com  Wed Oct 28 15:37:31 2015
From: yshvedov at wimarksystems.com (Yury Shvedov)
Date: Wed, 28 Oct 2015 17:37:31 +0300
Subject: [gnutls-help] Asynchronous transport
In-Reply-To: <5630C9A4.4060409@wimarksystems.com>
References: <5630C9A4.4060409@wimarksystems.com>
Message-ID: <5630DDAB.5000109@wimarksystems.com>

I overcame the issue!

The problem was on the server side: I forgot to initialize the 
prestate(gnutls_dtls_prestate_st) structure.
But in my opinion the case when client side behave the undocumented way 
if server sends garbage is a bug on the client side too.

I haven't reproduce it with exaples but reproduced it with the next code 
on server side:

gnutls_dtls_prestate_st prestate;

memset(&prestate, 0, sizeof(prestate));

prestate.record_seq = 105791312;

prestate.hsk_read_seq = 0;

prestate.hsk_write_seq = 67166359;

No I have the next issue withing handshake.

Gnutls: REC[0x65ddbb0]: INVALID VERSION PACKET: (-1) 254.255

I hope, I will overcame this too.

Kind regards
Yury Shvedov
WiMark Systems

On 10/28/2015 04:12 PM, Yury Shvedov wrote:
> Hi!
>
> I'm back with my problem, described here: 
> (http://lists.gnutls.org/pipermail/gnutls-help/2015-April/003852.html).
> The client begins handshake, with NONBLOCK exchange and after 
> receiving HELLO VERIFY REQUEST it stops working and seems to waiting 
> for other data, calling pull_timeout with non-zero timeout once and 
> then - zero timeout endlessly.
>
> Here I have logs of server and client.
>
> Such behaviour I have for both 3.3.17 and 3.4.6 versions.
>
> Thank you!
>
>
>
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151028/83525526/attachment.html>

From nmav at gnutls.org  Thu Oct 29 09:36:45 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 29 Oct 2015 09:36:45 +0100
Subject: [gnutls-help] Asynchronous transport
In-Reply-To: <5630DDAB.5000109@wimarksystems.com>
References: <5630C9A4.4060409@wimarksystems.com>
 <5630DDAB.5000109@wimarksystems.com>
Message-ID: <CAJU7zaKuiZJPmxDRx+=G8Yn_oxfYEKm14nvKnw2FznFzxeJ_rA@mail.gmail.com>

On Wed, Oct 28, 2015 at 3:37 PM, Yury Shvedov
<yshvedov at wimarksystems.com> wrote:
> I overcame the issue!
>
> The problem was on the server side: I forgot to initialize the
> prestate(gnutls_dtls_prestate_st) structure.
> But in my opinion the case when client side behave the undocumented way if
> server sends garbage is a bug on the client side too.
>
> I haven't reproduce it with exaples but reproduced it with the next code on
> server side:
> gnutls_dtls_prestate_st prestate;
>
> memset(&prestate, 0, sizeof(prestate));
>
> prestate.record_seq = 105791312;
>
> prestate.hsk_read_seq = 0;
>
> prestate.hsk_write_seq = 67166359;

That should be fairly easy to reproduce. If you modify for example
mini-dtls-hello-verify.c from tests/ with that, does it block
indefinitely?

> No I have the next issue withing handshake.
> Gnutls: REC[0x65ddbb0]: INVALID VERSION PACKET: (-1) 254.255

The comment on that error states:
"Reject record packets that have a different version than the one negotiated"

You'd better see with wireshark the versions negotiated and placed in
record packets.

regards,
Nikos


From yshvedov at wimarksystems.com  Thu Oct 29 14:52:22 2015
From: yshvedov at wimarksystems.com (Yury Shvedov)
Date: Thu, 29 Oct 2015 16:52:22 +0300
Subject: [gnutls-help] Asynchronous transport
In-Reply-To: <CAJU7zaKuiZJPmxDRx+=G8Yn_oxfYEKm14nvKnw2FznFzxeJ_rA@mail.gmail.com>
References: <5630C9A4.4060409@wimarksystems.com>
 <5630DDAB.5000109@wimarksystems.com>
 <CAJU7zaKuiZJPmxDRx+=G8Yn_oxfYEKm14nvKnw2FznFzxeJ_rA@mail.gmail.com>
Message-ID: <56322496.70402@wimarksystems.com>


On 10/29/2015 11:36 AM, Nikos Mavrogiannopoulos wrote:
> On Wed, Oct 28, 2015 at 3:37 PM, Yury Shvedov
> <yshvedov at wimarksystems.com> wrote:
>> No I have the next issue withing handshake.
>> Gnutls: REC[0x65ddbb0]: INVALID VERSION PACKET: (-1) 254.255
> The comment on that error states:
> "Reject record packets that have a different version than the one negotiated"
>
> You'd better see with wireshark the versions negotiated and placed in
> record packets.
>
> regards,
> Nikos
Hmm strange, but server partly send dtls 1.0 packets ant partly - 1.2 
packets. The client sends first packet with dtls1.0 packets and then - 
1.2 packets. 99% for that I'm doing something wrong, but I'm luck of 
idea. Maybe you have a couple of minutes glance on the pcap in 
attachment? There are some malformed packets, but I don't know what to 
do with that information.

P.S. I'll compile a code from example in an hour for that and 0-timeout 
issues.

Kind regards
Yury Shvedov
WiMark Systems

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtls.pcapng
Type: application/octet-stream
Size: 13480 bytes
Desc: not available
URL: </pipermail/attachments/20151029/1285828e/attachment-0001.obj>

From yshvedov at wimarksystems.com  Thu Oct 29 15:40:31 2015
From: yshvedov at wimarksystems.com (Yury Shvedov)
Date: Thu, 29 Oct 2015 17:40:31 +0300
Subject: [gnutls-help] Asynchronous transport
In-Reply-To: <CAJU7zaKuiZJPmxDRx+=G8Yn_oxfYEKm14nvKnw2FznFzxeJ_rA@mail.gmail.com>
References: <5630C9A4.4060409@wimarksystems.com>
 <5630DDAB.5000109@wimarksystems.com>
 <CAJU7zaKuiZJPmxDRx+=G8Yn_oxfYEKm14nvKnw2FznFzxeJ_rA@mail.gmail.com>
Message-ID: <56322FDF.6090603@wimarksystems.com>

Yes! So, here my updated examples from doc/examples/ (see 
ex-serv-dtls.c:138) and client seems to hangs forever.

? ?????????,
???? ??????
WiMark Systems

On 10/29/2015 11:36 AM, Nikos Mavrogiannopoulos wrote:
> That should be fairly easy to reproduce. If you modify for example
> mini-dtls-hello-verify.c from tests/ with that, does it block
> indefinitely?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ex-client-dtls.c
Type: text/x-csrc
Size: 4230 bytes
Desc: not available
URL: </pipermail/attachments/20151029/f90e0279/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ex-serv-dtls.c
Type: text/x-csrc
Size: 14830 bytes
Desc: not available
URL: </pipermail/attachments/20151029/f90e0279/attachment-0001.c>

From yshvedov at wimarksystems.com  Thu Oct 29 16:24:50 2015
From: yshvedov at wimarksystems.com (Yury Shvedov)
Date: Thu, 29 Oct 2015 18:24:50 +0300
Subject: [gnutls-help] Asynchronous transport
In-Reply-To: <56322496.70402@wimarksystems.com>
References: <5630C9A4.4060409@wimarksystems.com>
 <5630DDAB.5000109@wimarksystems.com>
 <CAJU7zaKuiZJPmxDRx+=G8Yn_oxfYEKm14nvKnw2FznFzxeJ_rA@mail.gmail.com>
 <56322496.70402@wimarksystems.com>
Message-ID: <56323A42.2040404@wimarksystems.com>

Of course! There was extra coockie verifying in packet handling. So 
thank you for your help and sorry for disturbing. I'll post the client's 
hangs issue to the bugtracker.

Kind regards
Yury Shvedov
WiMark Systems

On 10/29/2015 04:52 PM, Yury Shvedov wrote:
>
> On 10/29/2015 11:36 AM, Nikos Mavrogiannopoulos wrote:
>> On Wed, Oct 28, 2015 at 3:37 PM, Yury Shvedov
>> <yshvedov at wimarksystems.com> wrote:
>>> No I have the next issue withing handshake.
>>> Gnutls: REC[0x65ddbb0]: INVALID VERSION PACKET: (-1) 254.255
>> The comment on that error states:
>> "Reject record packets that have a different version than the one 
>> negotiated"
>>
>> You'd better see with wireshark the versions negotiated and placed in
>> record packets.
>>
>> regards,
>> Nikos
> Hmm strange, but server partly send dtls 1.0 packets ant partly - 1.2 
> packets. The client sends first packet with dtls1.0 packets and then - 
> 1.2 packets. 99% for that I'm doing something wrong, but I'm luck of 
> idea. Maybe you have a couple of minutes glance on the pcap in 
> attachment? There are some malformed packets, but I don't know what to 
> do with that information.
>
> P.S. I'll compile a code from example in an hour for that and 
> 0-timeout issues.
>
> Kind regards
> Yury Shvedov
> WiMark Systems
>
>
>
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151029/7faa2f65/attachment.html>