From cheako+gnutls at mikemestnik.net  Thu Dec  3 02:54:13 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Wed, 2 Dec 2015 19:54:13 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
Message-ID: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>

I'm writing an example application using gnutls and I'm wondering how
to get SSL support for RFC 6091, as found in gnutls.

https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b

# This gives the same error as [1]perl, so I'm thinking I've a genuine
problem with my implementation of the echo server.
gnutls-cli -p 4458 --pgpkeyfile=example/openpgp-secret.txt
--pgpcertfile=example/openpgp-server.txt localhost

See also:
1. http://www.perlmonks.org/?node_id=1149241


From nmav at gnutls.org  Thu Dec  3 10:57:40 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 3 Dec 2015 10:57:40 +0100
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
Message-ID: <CAJU7zaL9XWTjDwCrdjXi4d3Vj3WJ1q-xAVgrvPUsDvLKUW9gig@mail.gmail.com>

On Thu, Dec 3, 2015 at 2:54 AM, Mike Mestnik
<cheako+gnutls at mikemestnik.net> wrote:
> I'm writing an example application using gnutls and I'm wondering how
> to get SSL support for RFC 6091, as found in gnutls.
> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b

Which version of gnutls are you using? Could it be that you are using
certificates with DSA signatures? These are not enabled by default in
new gnutls versions.

regards,
Nikos


From cheako+gnutls at mikemestnik.net  Thu Dec  3 19:14:10 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Thu, 3 Dec 2015 12:14:10 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAJU7zaL9XWTjDwCrdjXi4d3Vj3WJ1q-xAVgrvPUsDvLKUW9gig@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAJU7zaL9XWTjDwCrdjXi4d3Vj3WJ1q-xAVgrvPUsDvLKUW9gig@mail.gmail.com>
Message-ID: <CAF8px5461U7_q3=nq9QAdVJgxMdi9qxdK1Wis2jnSiPi7SB5QQ@mail.gmail.com>

Thanks for the quick reply.  I believe the cert is RSA, the key and
cert can be found in git:
https://github.com/cheako/ihlt/tree/gpgme/example

libgnutls28-dev/experimental 3.4.7-1

On Thu, Dec 3, 2015 at 3:57 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Thu, Dec 3, 2015 at 2:54 AM, Mike Mestnik
> <cheako+gnutls at mikemestnik.net> wrote:
>> I'm writing an example application using gnutls and I'm wondering how
>> to get SSL support for RFC 6091, as found in gnutls.
>> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>
> Which version of gnutls are you using? Could it be that you are using
> certificates with DSA signatures? These are not enabled by default in
> new gnutls versions.
>
> regards,
> Nikos


From cheako+gnutls at mikemestnik.net  Fri Dec  4 06:56:02 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Thu, 3 Dec 2015 23:56:02 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAF8px5461U7_q3=nq9QAdVJgxMdi9qxdK1Wis2jnSiPi7SB5QQ@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAJU7zaL9XWTjDwCrdjXi4d3Vj3WJ1q-xAVgrvPUsDvLKUW9gig@mail.gmail.com>
 <CAF8px5461U7_q3=nq9QAdVJgxMdi9qxdK1Wis2jnSiPi7SB5QQ@mail.gmail.com>
Message-ID: <CAF8px57+vSnxQgo6kTNKrPprHn7GRxPvA9eQaRWGQ-+OEAzpXQ@mail.gmail.com>

Here is an example:
https://travis-ci.org/cheako/ihlt/builds/94805386

If there is anything else you need to help figure this out, let me know.
The gnutls version is from wily 3.3.15-5ubuntu2, clicking on befour_install.4.

On Thu, Dec 3, 2015 at 12:14 PM, Mike Mestnik
<cheako+gnutls at mikemestnik.net> wrote:
> Thanks for the quick reply.  I believe the cert is RSA, the key and
> cert can be found in git:
> https://github.com/cheako/ihlt/tree/gpgme/example
>
> libgnutls28-dev/experimental 3.4.7-1
>
> On Thu, Dec 3, 2015 at 3:57 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> On Thu, Dec 3, 2015 at 2:54 AM, Mike Mestnik
>> <cheako+gnutls at mikemestnik.net> wrote:
>>> I'm writing an example application using gnutls and I'm wondering how
>>> to get SSL support for RFC 6091, as found in gnutls.
>>> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>>
>> Which version of gnutls are you using? Could it be that you are using
>> certificates with DSA signatures? These are not enabled by default in
>> new gnutls versions.
>>
>> regards,
>> Nikos


From nmav at gnutls.org  Fri Dec  4 16:48:08 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 4 Dec 2015 16:48:08 +0100
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAF8px5461U7_q3=nq9QAdVJgxMdi9qxdK1Wis2jnSiPi7SB5QQ@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAJU7zaL9XWTjDwCrdjXi4d3Vj3WJ1q-xAVgrvPUsDvLKUW9gig@mail.gmail.com>
 <CAF8px5461U7_q3=nq9QAdVJgxMdi9qxdK1Wis2jnSiPi7SB5QQ@mail.gmail.com>
Message-ID: <CAJU7zaKS_O9NwcpsnVTg58uKuhOxs=fdoX+7phfpuWj=39U4tA@mail.gmail.com>

I can refer you to the tests in our test suite which run sessions with
TLS-openpgp:
e.g., https://gitlab.com/gnutls/gnutls/blob/master/tests/openpgp-auth.c

On Thu, Dec 3, 2015 at 7:14 PM, Mike Mestnik
<cheako+gnutls at mikemestnik.net> wrote:
> Thanks for the quick reply.  I believe the cert is RSA, the key and
> cert can be found in git:
> https://github.com/cheako/ihlt/tree/gpgme/example
>
> libgnutls28-dev/experimental 3.4.7-1
>
> On Thu, Dec 3, 2015 at 3:57 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> On Thu, Dec 3, 2015 at 2:54 AM, Mike Mestnik
>> <cheako+gnutls at mikemestnik.net> wrote:
>>> I'm writing an example application using gnutls and I'm wondering how
>>> to get SSL support for RFC 6091, as found in gnutls.
>>> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>>
>> Which version of gnutls are you using? Could it be that you are using
>> certificates with DSA signatures? These are not enabled by default in
>> new gnutls versions.
>>
>> regards,
>> Nikos


From cheako+gnutls at mikemestnik.net  Fri Dec  4 20:15:21 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Fri, 4 Dec 2015 13:15:21 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAJU7zaKS_O9NwcpsnVTg58uKuhOxs=fdoX+7phfpuWj=39U4tA@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAJU7zaL9XWTjDwCrdjXi4d3Vj3WJ1q-xAVgrvPUsDvLKUW9gig@mail.gmail.com>
 <CAF8px5461U7_q3=nq9QAdVJgxMdi9qxdK1Wis2jnSiPi7SB5QQ@mail.gmail.com>
 <CAJU7zaKS_O9NwcpsnVTg58uKuhOxs=fdoX+7phfpuWj=39U4tA@mail.gmail.com>
Message-ID: <CAF8px55ET+41F1FLe8kyhpC4X2PcrPUj21vwsRSwuQ68905dXA@mail.gmail.com>

That example had debug logging, level 5??, so I added that to my test.
[ 3374| 3] ASSERT: stream.c:952
[ 3374| 3] ASSERT: stream.c:952
[ 3374| 3] ASSERT: pgp.c:166
[ 3374| 3] ASSERT: stream.c:952
[ 3374| 3] ASSERT: privkey.c:1230
[ 3374| 3] ASSERT: privkey.c:1230
[ 3374| 3] ASSERT: pgp.c:166
[ 3374| 3] ASSERT: pgp.c:1644
[ 3374| 3] ASSERT: pgp.c:1644
[ 3374| 3] ASSERT: privkey.c:1230
[ 3374| 3] ASSERT: privkey.c:1230
[ 3374| 3] ASSERT: privkey.c:1230
[ 3374| 5] REC[0x4629640]: Allocating epoch #0
[ 3374| 3] ASSERT: gnutls_constate.c:588
[ 3374| 5] REC[0x4629640]: Allocating epoch #1
[ 3374| 3] ASSERT: gnutls_buffers.c:1154
[ 3374| 5] REC[0x4629640]: SSL 3.1 Handshake packet received. Epoch 0,
length: 205
[ 3374| 5] REC[0x4629640]: Expected Packet Handshake(22)
[ 3374| 5] REC[0x4629640]: Received Packet Handshake(22) with length: 205
[ 3374| 5] REC[0x4629640]: Decrypted Packet[0] Handshake(22) with length: 205
[ 3374| 4] HSK[0x4629640]: CLIENT HELLO (1) was received. Length
201[201], frag offset 0, frag length: 201, sequence: 0
[ 3374| 4] HSK[0x4629640]: Client's version: 3.3
[ 3374| 4] HSK[0x4629640]: Selected version TLS1.2
[ 3374| 3] ASSERT: gnutls_db.c:263
[ 3374| 4] EXT[0x4629640]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
[ 3374| 4] EXT[0x4629640]: Found extension 'SUPPORTED ECC/10'
[ 3374| 4] EXT[0x4629640]: Found extension 'SESSION TICKET/35'
[ 3374| 4] EXT[0x4629640]: Found extension 'SIGNATURE ALGORITHMS/13'
[ 3374| 4] EXT[0x4629640]: Found extension 'STATUS REQUEST/5'
[ 3374| 4] EXT[0x4629640]: Found extension '(null)/15'
[ 3374| 4] EXT[0x4629640]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
[ 3374| 4] EXT[0x4629640]: Found extension 'SUPPORTED ECC/10'
[ 3374| 4] EXT[0x4629640]: Parsing extension 'SESSION TICKET/35' (0 bytes)
[ 3374| 4] EXT[0x4629640]: Found extension 'SIGNATURE ALGORITHMS/13'
[ 3374| 4] EXT[0x4629640]: Found extension 'STATUS REQUEST/5'
[ 3374| 4] EXT[0x4629640]: Found extension '(null)/15'
[ 3374| 4] EXT[0x4629640]: Parsing extension 'SUPPORTED ECC POINT
FORMATS/11' (4 bytes)
[ 3374| 4] EXT[0x4629640]: Parsing extension 'SUPPORTED ECC/10' (52 bytes)
[ 3374| 4] HSK[0x4629640]: Selected ECC curve SECP521R1 (4)
[ 3374| 4] EXT[0x4629640]: Found extension 'SESSION TICKET/35'
[ 3374| 4] EXT[0x4629640]: Parsing extension 'SIGNATURE ALGORITHMS/13'
(32 bytes)
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (6.1) RSA-SHA512
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (6.2) DSA-SHA512
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (6.3) ECDSA-SHA512
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (5.1) RSA-SHA384
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (5.2) DSA-SHA384
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (5.3) ECDSA-SHA384
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (4.1) RSA-SHA256
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (4.2) DSA-SHA256
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (4.3) ECDSA-SHA256
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (3.1) RSA-SHA224
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (3.2) DSA-SHA224
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (3.3) ECDSA-SHA224
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (2.1) RSA-SHA1
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (2.2) DSA-SHA1
[ 3374| 4] EXT[0x4629640]: rcvd signature algo (2.3) ECDSA-SHA1
[ 3374| 4] EXT[0x4629640]: Parsing extension 'STATUS REQUEST/5' (5 bytes)
[ 3374| 4] EXT[0x4629640]: Found extension '(null)/15'
[ 3374| 4] HSK[0x4629640]: Received safe renegotiation CS
[ 3374| 3] ASSERT: server_name.c:307
[ 3374| 4] HSK[0x4629640]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
[ 3374| 4] HSK[0x4629640]: Requested PK algorithm: RSA (1) -- ctype: X.509 (1)
[ 3374| 4] HSK[0x4629640]: Requested PK algorithm: DSA (2) -- ctype: X.509 (1)
[ 3374| 3] ASSERT: cert.c:2059
[ 3374| 3] ASSERT: ciphersuites.c:1355
[ 3374| 2] Could not find an appropriate certificate: Insufficient
credentials for that request.
[ 3374| 3] ASSERT: ciphersuites.c:1430
[ 3374| 3] ASSERT: gnutls_handshake.c:964
[ 3374| 3] ASSERT: gnutls_handshake.c:665
[ 3374| 3] ASSERT: gnutls_handshake.c:2277
[ 3374| 3] ASSERT: gnutls_handshake.c:1481
[ 3374| 3] ASSERT: gnutls_handshake.c:3125
# Connection 1 try 1:

On Fri, Dec 4, 2015 at 9:48 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> I can refer you to the tests in our test suite which run sessions with
> TLS-openpgp:
> e.g., https://gitlab.com/gnutls/gnutls/blob/master/tests/openpgp-auth.c
>
> On Thu, Dec 3, 2015 at 7:14 PM, Mike Mestnik
> <cheako+gnutls at mikemestnik.net> wrote:
>> Thanks for the quick reply.  I believe the cert is RSA, the key and
>> cert can be found in git:
>> https://github.com/cheako/ihlt/tree/gpgme/example
>>
>> libgnutls28-dev/experimental 3.4.7-1
>>
>> On Thu, Dec 3, 2015 at 3:57 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>>> On Thu, Dec 3, 2015 at 2:54 AM, Mike Mestnik
>>> <cheako+gnutls at mikemestnik.net> wrote:
>>>> I'm writing an example application using gnutls and I'm wondering how
>>>> to get SSL support for RFC 6091, as found in gnutls.
>>>> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>>>
>>> Which version of gnutls are you using? Could it be that you are using
>>> certificates with DSA signatures? These are not enabled by default in
>>> new gnutls versions.
>>>
>>> regards,
>>> Nikos


From cheako+gnutls at mikemestnik.net  Sun Dec  6 00:51:24 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Sat, 5 Dec 2015 17:51:24 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAJU7zaKS_O9NwcpsnVTg58uKuhOxs=fdoX+7phfpuWj=39U4tA@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAJU7zaL9XWTjDwCrdjXi4d3Vj3WJ1q-xAVgrvPUsDvLKUW9gig@mail.gmail.com>
 <CAF8px5461U7_q3=nq9QAdVJgxMdi9qxdK1Wis2jnSiPi7SB5QQ@mail.gmail.com>
 <CAJU7zaKS_O9NwcpsnVTg58uKuhOxs=fdoX+7phfpuWj=39U4tA@mail.gmail.com>
Message-ID: <CAF8px56VAGcpJjgcS0DF0h-M42Hu+Dve4MfXTkoQKC8=MnDNwg@mail.gmail.com>

Thanks for the tip.  Note the test requires 3.4.0 so one might assume
that this feature didn't work prior to then?

I've duplicated the test as close as I can, with no luck.  Perhaps
this doesn't work outside of the test case.  It would be encouraging
if the test was against the command line gnutls-cli and/or perl as my
test is.

https://travis-ci.org/cheako/ihlt/builds/95117420

Let me know if there is something strange with my implementation.

On Fri, Dec 4, 2015 at 9:48 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> I can refer you to the tests in our test suite which run sessions with
> TLS-openpgp:
> e.g., https://gitlab.com/gnutls/gnutls/blob/master/tests/openpgp-auth.c
>
> On Thu, Dec 3, 2015 at 7:14 PM, Mike Mestnik
> <cheako+gnutls at mikemestnik.net> wrote:
>> Thanks for the quick reply.  I believe the cert is RSA, the key and
>> cert can be found in git:
>> https://github.com/cheako/ihlt/tree/gpgme/example
>>
>> libgnutls28-dev/experimental 3.4.7-1
>>
>> On Thu, Dec 3, 2015 at 3:57 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>>> On Thu, Dec 3, 2015 at 2:54 AM, Mike Mestnik
>>> <cheako+gnutls at mikemestnik.net> wrote:
>>>> I'm writing an example application using gnutls and I'm wondering how
>>>> to get SSL support for RFC 6091, as found in gnutls.
>>>> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>>>
>>> Which version of gnutls are you using? Could it be that you are using
>>> certificates with DSA signatures? These are not enabled by default in
>>> new gnutls versions.
>>>
>>> regards,
>>> Nikos


From cheako+gnutls at mikemestnik.net  Mon Dec  7 07:49:02 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Mon, 7 Dec 2015 00:49:02 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
Message-ID: <CAF8px56=MwK7yWPtCicJ8-Fw1y3Gsc_4rX0QUj+ZBhj=MbKt2A@mail.gmail.com>

>From a tip on IRC, I've included the results of a test from the
gnutls-cli application.  This is to rule out an issue where a non cert
type supporting client might be causing problems.

https://travis-ci.org/cheako/ihlt/builds/95292899

At the end, when the other connections from perl fail, there is a test
from gnutls-client.  Same failure.

Is there an issue with non cert type clients?  Would that also be
mapped to "No supported cipher suites..." error?  Can i have a patch
where this error has it's own message?

On Wed, Dec 2, 2015 at 7:54 PM, Mike Mestnik
<cheako+gnutls at mikemestnik.net> wrote:
> I'm writing an example application using gnutls and I'm wondering how
> to get SSL support for RFC 6091, as found in gnutls.
>
> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>
> # This gives the same error as [1]perl, so I'm thinking I've a genuine
> problem with my implementation of the echo server.
> gnutls-cli -p 4458 --pgpkeyfile=example/openpgp-secret.txt
> --pgpcertfile=example/openpgp-server.txt localhost
>
> See also:
> 1. http://www.perlmonks.org/?node_id=1149241


From nmav at gnutls.org  Mon Dec  7 09:30:33 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 7 Dec 2015 09:30:33 +0100
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAF8px56=MwK7yWPtCicJ8-Fw1y3Gsc_4rX0QUj+ZBhj=MbKt2A@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAF8px56=MwK7yWPtCicJ8-Fw1y3Gsc_4rX0QUj+ZBhj=MbKt2A@mail.gmail.com>
Message-ID: <CAJU7zaKn2TcGYLaSM+kwq1OvOSmFtmjefM1dvwbQKwHR82w_og@mail.gmail.com>

You can test gnutls-serv and gnutls-cli in the gnutls distribution
with the following options:
cd doc/credentials && ./../src/gnutls-serv --pgpkeyfile
openpgp/sec.asc --pgpcertfile openpgp/pub.asc --dhparams params.pem
--priority "NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:+CTYPE-OPENPGP"

cd src && ./gnutls-cli localhost -p 5556 --insecure --priority
"NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:+CTYPE-OPENPGP"


regards,
Nikos

On Mon, Dec 7, 2015 at 7:49 AM, Mike Mestnik
<cheako+gnutls at mikemestnik.net> wrote:
> From a tip on IRC, I've included the results of a test from the
> gnutls-cli application.  This is to rule out an issue where a non cert
> type supporting client might be causing problems.
>
> https://travis-ci.org/cheako/ihlt/builds/95292899
>
> At the end, when the other connections from perl fail, there is a test
> from gnutls-client.  Same failure.
>
> Is there an issue with non cert type clients?  Would that also be
> mapped to "No supported cipher suites..." error?  Can i have a patch
> where this error has it's own message?
>
> On Wed, Dec 2, 2015 at 7:54 PM, Mike Mestnik
> <cheako+gnutls at mikemestnik.net> wrote:
>> I'm writing an example application using gnutls and I'm wondering how
>> to get SSL support for RFC 6091, as found in gnutls.
>>
>> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>>
>> # This gives the same error as [1]perl, so I'm thinking I've a genuine
>> problem with my implementation of the echo server.
>> gnutls-cli -p 4458 --pgpkeyfile=example/openpgp-secret.txt
>> --pgpcertfile=example/openpgp-server.txt localhost
>>
>> See also:
>> 1. http://www.perlmonks.org/?node_id=1149241
>
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help


From cheako+gnutls at mikemestnik.net  Mon Dec  7 10:09:28 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Mon, 7 Dec 2015 03:09:28 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAJU7zaKn2TcGYLaSM+kwq1OvOSmFtmjefM1dvwbQKwHR82w_og@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAF8px56=MwK7yWPtCicJ8-Fw1y3Gsc_4rX0QUj+ZBhj=MbKt2A@mail.gmail.com>
 <CAJU7zaKn2TcGYLaSM+kwq1OvOSmFtmjefM1dvwbQKwHR82w_og@mail.gmail.com>
Message-ID: <CAF8px5620W77DnwS8oHNaQ_mT5=mY5WXoOKq=gkkCcVkJA1jhQ@mail.gmail.com>

Thanks for the tip.  I've changed my test to match this example and
have had no change in results.

Are there any examples of a server in C /w a gnutls-cli connecting?
That is a working one I can compare my example too.

This shows the clients error, and on the server the error out put was buffered.
https://travis-ci.org/cheako/ihlt/builds/95305836#L534
https://travis-ci.org/cheako/ihlt/builds/95305836#L550

Note that the fifth and last connection try from perl is not shown.

The valgrind error, invalid free server.c:L424, is also not anything of note:
https://github.com/cheako/ihlt/blob/4437c7872bebc333198e7fa77c4ed2b8aaf63b95/src/server.c#L424

It's just the last line prior to receiving a kill.

On Mon, Dec 7, 2015 at 2:30 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> You can test gnutls-serv and gnutls-cli in the gnutls distribution
> with the following options:
> cd doc/credentials && ./../src/gnutls-serv --pgpkeyfile
> openpgp/sec.asc --pgpcertfile openpgp/pub.asc --dhparams params.pem
> --priority "NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:+CTYPE-OPENPGP"
>
> cd src && ./gnutls-cli localhost -p 5556 --insecure --priority
> "NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:+CTYPE-OPENPGP"
>
>
> regards,
> Nikos
>
> On Mon, Dec 7, 2015 at 7:49 AM, Mike Mestnik
> <cheako+gnutls at mikemestnik.net> wrote:
>> From a tip on IRC, I've included the results of a test from the
>> gnutls-cli application.  This is to rule out an issue where a non cert
>> type supporting client might be causing problems.
>>
>> https://travis-ci.org/cheako/ihlt/builds/95292899
>>
>> At the end, when the other connections from perl fail, there is a test
>> from gnutls-client.  Same failure.
>>
>> Is there an issue with non cert type clients?  Would that also be
>> mapped to "No supported cipher suites..." error?  Can i have a patch
>> where this error has it's own message?
>>
>> On Wed, Dec 2, 2015 at 7:54 PM, Mike Mestnik
>> <cheako+gnutls at mikemestnik.net> wrote:
>>> I'm writing an example application using gnutls and I'm wondering how
>>> to get SSL support for RFC 6091, as found in gnutls.
>>>
>>> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>>>
>>> # This gives the same error as [1]perl, so I'm thinking I've a genuine
>>> problem with my implementation of the echo server.
>>> gnutls-cli -p 4458 --pgpkeyfile=example/openpgp-secret.txt
>>> --pgpcertfile=example/openpgp-server.txt localhost
>>>
>>> See also:
>>> 1. http://www.perlmonks.org/?node_id=1149241
>>
>> _______________________________________________
>> Gnutls-help mailing list
>> Gnutls-help at lists.gnutls.org
>> http://lists.gnupg.org/mailman/listinfo/gnutls-help


From cheako+gnutls at mikemestnik.net  Fri Dec 11 21:22:13 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Fri, 11 Dec 2015 14:22:13 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAJU7zaKn2TcGYLaSM+kwq1OvOSmFtmjefM1dvwbQKwHR82w_og@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAF8px56=MwK7yWPtCicJ8-Fw1y3Gsc_4rX0QUj+ZBhj=MbKt2A@mail.gmail.com>
 <CAJU7zaKn2TcGYLaSM+kwq1OvOSmFtmjefM1dvwbQKwHR82w_og@mail.gmail.com>
Message-ID: <CAF8px56pVAvDTqyqTwyeVmZXRUndc6pwEoY9E+wCzRx6fyWWsg@mail.gmail.com>

Is there a way to figure out more specifically what is wrong with a
ClientHello?  I've been toying with the idea of implementing the
handshake portion in perl, but currently I've no working client to
copy and no way of knowing what's wrong it would be pointless.

Here is what I have so far:
#!/usr/bin/env perl

use IO::Socket::INET;

my $socket = new IO::Socket::INET(
PeerHost => '127.0.0.1',
PeerPort => '4458',
Proto    => 'tcp',
);

sub r{rand()*0xffffffff};

my$a=sprintf'\x3\x3%s\x0%s%s\x0%s%s',pack('NL7',time(),r(),r(),r(),r(),r(),r(),r()),
pack("n",8),sprintf'\x0\x40\x0\x6a\x0\x9',pack('C',1),sprintf'';
my$b=sprintf'\x1\x0%s%s',pack('n',length$a),$a;
$socket->send(sprintf'\x16\x3\x3%s%s',pack('n',length$b),$b);
$socket->recv(my$r,4096);
print $r;

=pod
000005e0  16 03 01 00 fc 01 00 00  f8 03 03 56 69 bf 40 cc  |...........Vi. at .|
000005f0  ef 1c b1 5e 81 af cc 3c  4f a9 ca fe 05 a6 6c 0c  |...^...<O.....l.|
00000600  ae e5 24 fc 18 38 5f a0  bd 2b db 00 00 6c c0 2b  |..$..8_..+...l.+|
00000610  c0 2c c0 86 c0 87 c0 09  c0 23 c0 0a c0 24 c0 72  |.,.......#...$.r|
00000620  c0 73 c0 ac c0 ad c0 08  c0 2f c0 30 c0 8a c0 8b  |.s......./.0....|
00000630  c0 13 c0 27 c0 14 c0 28  c0 76 c0 77 c0 12 00 9c  |...'...(.v.w....|
00000640  00 9d c0 7a c0 7b 00 2f  00 3c 00 35 00 3d 00 41  |...z.{./.<.5.=.A|
00000650  00 ba 00 84 00 c0 c0 9c  c0 9d 00 0a 00 9e 00 9f  |................|
00000660  c0 7c c0 7d 00 33 00 67  00 39 00 6b 00 45 00 be  |.|.}.3.g.9.k.E..|
00000670  00 88 00 c4 c0 9e c0 9f  00 16 01 00 00 63 00 17  |.............c..|
00000680  00 00 00 16 00 00 00 05  00 05 01 00 00 00 00 00  |................|
00000690  09 00 03 02 00 01 00 00  00 0e 00 0c 00 00 09 6c  |...............l|
000006a0  6f 63 61 6c 68 6f 73 74  ff 01 00 01 00 00 23 00  |ocalhost......#.|
000006b0  00 00 0a 00 0c 00 0a 00  17 00 18 00 19 00 15 00  |................|
000006c0  13 00 0b 00 02 01 00 00  0d 00 16 00 14 04 01 04  |................|
000006d0  03 05 01 05 03 06 01 06  03 03 01 03 03 02 01 02  |................|
000006e0  03 00 00


On Mon, Dec 7, 2015 at 2:30 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> You can test gnutls-serv and gnutls-cli in the gnutls distribution
> with the following options:
> cd doc/credentials && ./../src/gnutls-serv --pgpkeyfile
> openpgp/sec.asc --pgpcertfile openpgp/pub.asc --dhparams params.pem
> --priority "NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:+CTYPE-OPENPGP"
>
> cd src && ./gnutls-cli localhost -p 5556 --insecure --priority
> "NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:+CTYPE-OPENPGP"
>
>
> regards,
> Nikos
>
> On Mon, Dec 7, 2015 at 7:49 AM, Mike Mestnik
> <cheako+gnutls at mikemestnik.net> wrote:
>> From a tip on IRC, I've included the results of a test from the
>> gnutls-cli application.  This is to rule out an issue where a non cert
>> type supporting client might be causing problems.
>>
>> https://travis-ci.org/cheako/ihlt/builds/95292899
>>
>> At the end, when the other connections from perl fail, there is a test
>> from gnutls-client.  Same failure.
>>
>> Is there an issue with non cert type clients?  Would that also be
>> mapped to "No supported cipher suites..." error?  Can i have a patch
>> where this error has it's own message?
>>
>> On Wed, Dec 2, 2015 at 7:54 PM, Mike Mestnik
>> <cheako+gnutls at mikemestnik.net> wrote:
>>> I'm writing an example application using gnutls and I'm wondering how
>>> to get SSL support for RFC 6091, as found in gnutls.
>>>
>>> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>>>
>>> # This gives the same error as [1]perl, so I'm thinking I've a genuine
>>> problem with my implementation of the echo server.
>>> gnutls-cli -p 4458 --pgpkeyfile=example/openpgp-secret.txt
>>> --pgpcertfile=example/openpgp-server.txt localhost
>>>
>>> See also:
>>> 1. http://www.perlmonks.org/?node_id=1149241
>>
>> _______________________________________________
>> Gnutls-help mailing list
>> Gnutls-help at lists.gnutls.org
>> http://lists.gnupg.org/mailman/listinfo/gnutls-help


From cheako+gnutls at mikemestnik.net  Sun Dec 13 00:29:10 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Sat, 12 Dec 2015 17:29:10 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAF8px56pVAvDTqyqTwyeVmZXRUndc6pwEoY9E+wCzRx6fyWWsg@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAF8px56=MwK7yWPtCicJ8-Fw1y3Gsc_4rX0QUj+ZBhj=MbKt2A@mail.gmail.com>
 <CAJU7zaKn2TcGYLaSM+kwq1OvOSmFtmjefM1dvwbQKwHR82w_og@mail.gmail.com>
 <CAF8px56pVAvDTqyqTwyeVmZXRUndc6pwEoY9E+wCzRx6fyWWsg@mail.gmail.com>
Message-ID: <CAF8px569Wy4gi+ZS4yOnBETjoqQK2gNS6v3K2uJA8vkjQaT+Vg@mail.gmail.com>

Still chipping away at this and I've found a way to get more information.

Here is the Client Hello I'm sending:
Data::Hexdumper: data length isn't an integer multiple of lines
so has been padded with NULLs at the end.
  0x0000 : 16 03 03 00 35 01 00 00 31 03 03 56 6C 90 CA C5 : ....5...1..Vl...
  0x0010 : C5 4D 73 22 ED E3 D9 0E 86 53 CB 94 E6 35 2C 2B : .Ms".....S...5,+
  0x0020 : 91 6F 6D A7 35 D5 2E 6D 7E D6 47 00 00 02 00 2F : .om.5..m~.G..../
  0x0030 : 01 00 00 06 00 09 00 02 01 01 00 00 00 00 00 00 : ................

and the resulting log level 99:
[ 4718| 3] ASSERT: mpi.c:240
[ 4718| 3] ASSERT: gnutls_dh.c:332
[ 4718|13] armor filter: decode
[ 4718| 3] ASSERT: stream.c:952
[ 4718|13] free armor filter
[ 4718|13] armor filter: decode
[ 4718| 3] ASSERT: stream.c:952
[ 4718|13] free armor filter
[ 4718| 3] ASSERT: pgp.c:166
[ 4718| 3] ASSERT: stream.c:952
[ 4718| 3] ASSERT: privkey.c:1230
[ 4718| 3] ASSERT: privkey.c:1230
[ 4718| 3] ASSERT: pgp.c:166
[ 4718| 3] ASSERT: pgp.c:1644
[ 4718| 3] ASSERT: pgp.c:1644
[ 4718| 3] ASSERT: privkey.c:1230
[ 4718| 3] ASSERT: privkey.c:1230
[ 4718| 9] Signing using master PGP key
[ 4718| 3] ASSERT: privkey.c:1230







[ 4718| 5] REC[0x93332b0]: Allocating epoch #0
New connection from localhost on socket 6 index 0
[ 4718| 3] ASSERT: gnutls_constate.c:588
[ 4718| 5] REC[0x93332b0]: Allocating epoch #1
[ 4718| 3] ASSERT: gnutls_buffers.c:1154
[ 4718|10] READ: Got 5 bytes from 0x6
[ 4718|10] READ: read 5 bytes from 0x6
[ 4718|10] RB: Have 0 bytes into buffer. Adding 5 bytes.
[ 4718|10] RB: Requested 5 bytes
[ 4718| 5] REC[0x93332b0]: SSL 3.3 Handshake packet received. Epoch 0,
length: 53
[ 4718| 5] REC[0x93332b0]: Expected Packet Handshake(22)
[ 4718| 5] REC[0x93332b0]: Received Packet Handshake(22) with length: 53
[ 4718|10] READ: Got 53 bytes from 0x6
[ 4718|10] READ: read 53 bytes from 0x6
[ 4718|10] RB: Have 5 bytes into buffer. Adding 53 bytes.
[ 4718|10] RB: Requested 58 bytes
[ 4718| 5] REC[0x93332b0]: Decrypted Packet[0] Handshake(22) with length: 53
[ 4718|13] BUF[REC]: Inserted 53 bytes of Data(22)
[ 4718| 4] HSK[0x93332b0]: CLIENT HELLO (1) was received. Length
49[49], frag offset 0, frag length: 49, sequence: 0
[ 4718| 4] HSK[0x93332b0]: Client's version: 3.3
[ 4718| 4] HSK[0x93332b0]: Selected version TLS1.2
[ 4718| 3] ASSERT: gnutls_db.c:263
[ 4718| 4] EXT[0x93332b0]: Found extension 'CERT TYPE/9'
[ 4718| 4] EXT[0x93332b0]: Found extension 'CERT TYPE/9'
[ 4718| 4] EXT[0x93332b0]: Parsing extension 'CERT TYPE/9' (2 bytes)
[ 4718| 3] ASSERT: cert_type.c:120
[ 4718| 3] ASSERT: cert_type.c:136
[ 4718| 3] ASSERT: server_name.c:307
[ 4718| 4] HSK[0x93332b0]: Requested PK algorithm: RSA (1) -- ctype: X.509 (1)
[ 4718| 3] ASSERT: cert.c:2059
[ 4718| 3] ASSERT: ciphersuites.c:1355
[ 4718| 2] Could not find an appropriate certificate: Insufficient
credentials for that request.
[ 4718| 3] ASSERT: ciphersuites.c:1430
[ 4718| 3] ASSERT: gnutls_handshake.c:964
[ 4718| 3] ASSERT: gnutls_handshake.c:665
[ 4718| 3] ASSERT: gnutls_handshake.c:2277
[ 4718| 3] ASSERT: gnutls_handshake.c:1481
[ 4718| 3] ASSERT: gnutls_handshake.c:3125
[ 4718| 5] REC[0x93332b0]: Start of epoch cleanup
[ 4718| 5] REC[0x93332b0]: End of epoch cleanup
[ 4718| 5] REC[0x93332b0]: Epoch #0 freed
[ 4718| 5] REC[0x93332b0]: Epoch #1 freed


Thus it looks like \x1 isn't a currently loaded cert type.  How can I
tell what type of cert is loaded into the session's credentials?

On Fri, Dec 11, 2015 at 2:22 PM, Mike Mestnik
<cheako+gnutls at mikemestnik.net> wrote:
> Is there a way to figure out more specifically what is wrong with a
> ClientHello?  I've been toying with the idea of implementing the
> handshake portion in perl, but currently I've no working client to
> copy and no way of knowing what's wrong it would be pointless.
>
> Here is what I have so far:
> #!/usr/bin/env perl
>
> use IO::Socket::INET;
>
> my $socket = new IO::Socket::INET(
> PeerHost => '127.0.0.1',
> PeerPort => '4458',
> Proto    => 'tcp',
> );
>
> sub r{rand()*0xffffffff};
>
> my$a=sprintf'\x3\x3%s\x0%s%s\x0%s%s',pack('NL7',time(),r(),r(),r(),r(),r(),r(),r()),
> pack("n",8),sprintf'\x0\x40\x0\x6a\x0\x9',pack('C',1),sprintf'';
> my$b=sprintf'\x1\x0%s%s',pack('n',length$a),$a;
> $socket->send(sprintf'\x16\x3\x3%s%s',pack('n',length$b),$b);
> $socket->recv(my$r,4096);
> print $r;
>
> =pod
> 000005e0  16 03 01 00 fc 01 00 00  f8 03 03 56 69 bf 40 cc  |...........Vi. at .|
> 000005f0  ef 1c b1 5e 81 af cc 3c  4f a9 ca fe 05 a6 6c 0c  |...^...<O.....l.|
> 00000600  ae e5 24 fc 18 38 5f a0  bd 2b db 00 00 6c c0 2b  |..$..8_..+...l.+|
> 00000610  c0 2c c0 86 c0 87 c0 09  c0 23 c0 0a c0 24 c0 72  |.,.......#...$.r|
> 00000620  c0 73 c0 ac c0 ad c0 08  c0 2f c0 30 c0 8a c0 8b  |.s......./.0....|
> 00000630  c0 13 c0 27 c0 14 c0 28  c0 76 c0 77 c0 12 00 9c  |...'...(.v.w....|
> 00000640  00 9d c0 7a c0 7b 00 2f  00 3c 00 35 00 3d 00 41  |...z.{./.<.5.=.A|
> 00000650  00 ba 00 84 00 c0 c0 9c  c0 9d 00 0a 00 9e 00 9f  |................|
> 00000660  c0 7c c0 7d 00 33 00 67  00 39 00 6b 00 45 00 be  |.|.}.3.g.9.k.E..|
> 00000670  00 88 00 c4 c0 9e c0 9f  00 16 01 00 00 63 00 17  |.............c..|
> 00000680  00 00 00 16 00 00 00 05  00 05 01 00 00 00 00 00  |................|
> 00000690  09 00 03 02 00 01 00 00  00 0e 00 0c 00 00 09 6c  |...............l|
> 000006a0  6f 63 61 6c 68 6f 73 74  ff 01 00 01 00 00 23 00  |ocalhost......#.|
> 000006b0  00 00 0a 00 0c 00 0a 00  17 00 18 00 19 00 15 00  |................|
> 000006c0  13 00 0b 00 02 01 00 00  0d 00 16 00 14 04 01 04  |................|
> 000006d0  03 05 01 05 03 06 01 06  03 03 01 03 03 02 01 02  |................|
> 000006e0  03 00 00
>
>
> On Mon, Dec 7, 2015 at 2:30 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> You can test gnutls-serv and gnutls-cli in the gnutls distribution
>> with the following options:
>> cd doc/credentials && ./../src/gnutls-serv --pgpkeyfile
>> openpgp/sec.asc --pgpcertfile openpgp/pub.asc --dhparams params.pem
>> --priority "NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:+CTYPE-OPENPGP"
>>
>> cd src && ./gnutls-cli localhost -p 5556 --insecure --priority
>> "NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:+CTYPE-OPENPGP"
>>
>>
>> regards,
>> Nikos
>>
>> On Mon, Dec 7, 2015 at 7:49 AM, Mike Mestnik
>> <cheako+gnutls at mikemestnik.net> wrote:
>>> From a tip on IRC, I've included the results of a test from the
>>> gnutls-cli application.  This is to rule out an issue where a non cert
>>> type supporting client might be causing problems.
>>>
>>> https://travis-ci.org/cheako/ihlt/builds/95292899
>>>
>>> At the end, when the other connections from perl fail, there is a test
>>> from gnutls-client.  Same failure.
>>>
>>> Is there an issue with non cert type clients?  Would that also be
>>> mapped to "No supported cipher suites..." error?  Can i have a patch
>>> where this error has it's own message?
>>>
>>> On Wed, Dec 2, 2015 at 7:54 PM, Mike Mestnik
>>> <cheako+gnutls at mikemestnik.net> wrote:
>>>> I'm writing an example application using gnutls and I'm wondering how
>>>> to get SSL support for RFC 6091, as found in gnutls.
>>>>
>>>> https://github.com/cheako/ihlt/tree/24f6f08cf7c4c118550858718f0a3bb07d3bfa6b
>>>>
>>>> # This gives the same error as [1]perl, so I'm thinking I've a genuine
>>>> problem with my implementation of the echo server.
>>>> gnutls-cli -p 4458 --pgpkeyfile=example/openpgp-secret.txt
>>>> --pgpcertfile=example/openpgp-server.txt localhost
>>>>
>>>> See also:
>>>> 1. http://www.perlmonks.org/?node_id=1149241
>>>
>>> _______________________________________________
>>> Gnutls-help mailing list
>>> Gnutls-help at lists.gnutls.org
>>> http://lists.gnupg.org/mailman/listinfo/gnutls-help


From nmav at gnutls.org  Sun Dec 13 17:41:27 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 13 Dec 2015 17:41:27 +0100
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAF8px569Wy4gi+ZS4yOnBETjoqQK2gNS6v3K2uJA8vkjQaT+Vg@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAF8px56=MwK7yWPtCicJ8-Fw1y3Gsc_4rX0QUj+ZBhj=MbKt2A@mail.gmail.com>
 <CAJU7zaKn2TcGYLaSM+kwq1OvOSmFtmjefM1dvwbQKwHR82w_og@mail.gmail.com>
 <CAF8px56pVAvDTqyqTwyeVmZXRUndc6pwEoY9E+wCzRx6fyWWsg@mail.gmail.com>
 <CAF8px569Wy4gi+ZS4yOnBETjoqQK2gNS6v3K2uJA8vkjQaT+Vg@mail.gmail.com>
Message-ID: <1450024887.31642.3.camel@gnutls.org>

On Sat, 2015-12-12 at 17:29 -0600, Mike Mestnik wrote:
> Still chipping away at this and I've found a way to get more 
> information.
> 
> Here is the Client Hello I'm sending:
> Data::Hexdumper: data length isn't an integer multiple of lines
> so has been padded with NULLs at the end.

I'd suggest to try to make the minimal program needed to replicate that
behavior you see. I referred you to the test programs because they are
small programs that utilize openpgp authentication. You can also start
from the examples in the documentation.

> [ 4718| 9] Signing using master PGP key
> [ 4718| 3] ASSERT: privkey.c:1230

That's already a hint. Have you tried specifying the exact subkey to
use for signing?

regards,
Nikos




From cheako+gnutls at mikemestnik.net  Sun Dec 13 19:26:06 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Sun, 13 Dec 2015 12:26:06 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <1450024887.31642.3.camel@gnutls.org>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAF8px56=MwK7yWPtCicJ8-Fw1y3Gsc_4rX0QUj+ZBhj=MbKt2A@mail.gmail.com>
 <CAJU7zaKn2TcGYLaSM+kwq1OvOSmFtmjefM1dvwbQKwHR82w_og@mail.gmail.com>
 <CAF8px56pVAvDTqyqTwyeVmZXRUndc6pwEoY9E+wCzRx6fyWWsg@mail.gmail.com>
 <CAF8px569Wy4gi+ZS4yOnBETjoqQK2gNS6v3K2uJA8vkjQaT+Vg@mail.gmail.com>
 <1450024887.31642.3.camel@gnutls.org>
Message-ID: <CAF8px55t8FM8NvzLASvPdty_38rb8OPFG99K_q6-rB2MssAZxQ@mail.gmail.com>

On Sun, Dec 13, 2015 at 10:41 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Sat, 2015-12-12 at 17:29 -0600, Mike Mestnik wrote:
>> Still chipping away at this and I've found a way to get more
>> information.
>>
>> Here is the Client Hello I'm sending:
>> Data::Hexdumper: data length isn't an integer multiple of lines
>> so has been padded with NULLs at the end.
>
> I'd suggest to try to make the minimal program needed to replicate that
> behavior you see. I referred you to the test programs because they are
> small programs that utilize openpgp authentication. You can also start
> from the examples in the documentation.
>
I'll work on this.

One issue with the test is that it uses sockpair and fork to connect
the client and server, so it'll require some doing to be able to test
this against another server or client.

>> [ 4718| 9] Signing using master PGP key
>> [ 4718| 3] ASSERT: privkey.c:1230
>
> That's already a hint. Have you tried specifying the exact subkey to
> use for signing?
>
I'm copying the command line example, keys and all.  This includes
using gnutls_certificate_set_openpgp_key_file and thus the master PGP
key.

The reason to copy this example is that it was simple to connect it's
client portion to the server I'm working on.

> regards,
> Nikos
>
>


From cheako+gnutls at mikemestnik.net  Sun Dec 13 20:17:56 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Sun, 13 Dec 2015 13:17:56 -0600
Subject: [gnutls-help] No supported cipher suites have been found.
In-Reply-To: <CAF8px55t8FM8NvzLASvPdty_38rb8OPFG99K_q6-rB2MssAZxQ@mail.gmail.com>
References: <CAF8px54KkKnQc4+h4hWbFgdo5gTp3jNWyET_5-OUjDr01AL5jw@mail.gmail.com>
 <CAF8px56=MwK7yWPtCicJ8-Fw1y3Gsc_4rX0QUj+ZBhj=MbKt2A@mail.gmail.com>
 <CAJU7zaKn2TcGYLaSM+kwq1OvOSmFtmjefM1dvwbQKwHR82w_og@mail.gmail.com>
 <CAF8px56pVAvDTqyqTwyeVmZXRUndc6pwEoY9E+wCzRx6fyWWsg@mail.gmail.com>
 <CAF8px569Wy4gi+ZS4yOnBETjoqQK2gNS6v3K2uJA8vkjQaT+Vg@mail.gmail.com>
 <1450024887.31642.3.camel@gnutls.org>
 <CAF8px55t8FM8NvzLASvPdty_38rb8OPFG99K_q6-rB2MssAZxQ@mail.gmail.com>
Message-ID: <CAF8px54D=EK094Psy2iAXsd_bSm7maQri3GjaM0PBkz8So33Mg@mail.gmail.com>

After patching openpgp_auth.c to work with the new example keys, it
exhibits the same using master key message.

On Sun, Dec 13, 2015 at 12:26 PM, Mike Mestnik
<cheako+gnutls at mikemestnik.net> wrote:
> On Sun, Dec 13, 2015 at 10:41 AM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
>> On Sat, 2015-12-12 at 17:29 -0600, Mike Mestnik wrote:
>>> Still chipping away at this and I've found a way to get more
>>> information.
>>>
>>> Here is the Client Hello I'm sending:
>>> Data::Hexdumper: data length isn't an integer multiple of lines
>>> so has been padded with NULLs at the end.
>>
>> I'd suggest to try to make the minimal program needed to replicate that
>> behavior you see. I referred you to the test programs because they are
>> small programs that utilize openpgp authentication. You can also start
>> from the examples in the documentation.
>>
> I'll work on this.
>
> One issue with the test is that it uses sockpair and fork to connect
> the client and server, so it'll require some doing to be able to test
> this against another server or client.
>
>>> [ 4718| 9] Signing using master PGP key
>>> [ 4718| 3] ASSERT: privkey.c:1230
>>
>> That's already a hint. Have you tried specifying the exact subkey to
>> use for signing?
>>
> I'm copying the command line example, keys and all.  This includes
> using gnutls_certificate_set_openpgp_key_file and thus the master PGP
> key.
>
> The reason to copy this example is that it was simple to connect it's
> client portion to the server I'm working on.
>
>> regards,
>> Nikos
>>
>>
-------------- next part --------------
diff --git a/example/openpgp-auth.c b/example/openpgp-auth.c
index 1ce29bd..e2a8a22 100644
--- a/example/openpgp-auth.c
+++ b/example/openpgp-auth.c
@@ -81,12 +81,11 @@ void check_loaded_key(gnutls_certificate_credentials_t cred)
 	if (err != 0)
 		fail("get openpgp key %s\n",
 		     gnutls_strerror(err));
-
 #if GNUTLS_VERSION_NUMBER >= 0x030400
 	gnutls_openpgp_privkey_get_subkey_id(key, 0, keyid);
-	if (keyid[0] != 0xf3 || keyid[1] != 0x0f || keyid[2] != 0xd4 || keyid[3] != 0x23 ||
-	    keyid[4] != 0xc1 || keyid[5] != 0x43 || keyid[6] != 0xe7 || keyid[7] != 0xba)
-		fail("incorrect key id (privkey)\n");
+	if (keyid[0] != 0x83 || keyid[1] != 0x7b || keyid[2] != 0x6f || keyid[3] != 0xb4 ||
+	    keyid[4] != 0x2e || keyid[5] != 0x0f || keyid[6] != 0xe1 || keyid[7] != 0x76)
+		fail("\n\nincorrect key id (privkey)\n");
 
 	err = gnutls_certificate_get_openpgp_crt(cred, 0, &crts, &n_crts);
 	if (err != 0)
@@ -98,8 +97,8 @@ void check_loaded_key(gnutls_certificate_credentials_t cred)
 		fail("openpgp n_crts != 1\n");
 
 	gnutls_openpgp_crt_get_subkey_id(crts[0], 0, keyid);
-	if (keyid[0] != 0xf3 || keyid[1] != 0x0f || keyid[2] != 0xd4 || keyid[3] != 0x23 ||
-	    keyid[4] != 0xc1 || keyid[5] != 0x43 || keyid[6] != 0xe7 || keyid[7] != 0xba)
+	if (keyid[0] != 0x83 || keyid[1] != 0x7b || keyid[2] != 0x6f || keyid[3] != 0xb4 ||
+	    keyid[4] != 0x2e || keyid[5] != 0x0f || keyid[6] != 0xe1 || keyid[7] != 0x76)
 		fail("incorrect key id (pubkey)\n");
 
 	for (i = 0; i < n_crts; ++i)
@@ -126,10 +125,10 @@ void doit(void)
 		else if (i == 2)
 			key_id = "auto";	/* test auto */
 		else if (i >= 3)
-			key_id = "f30fd423c143e7ba";
+			key_id = "837b6fb42e0fe176";
 
 		if (debug) {
-			gnutls_global_set_log_level(5);
+			gnutls_global_set_log_level(9999);
 			gnutls_global_set_log_function(log_message);
 		}
 
@@ -172,11 +171,11 @@ void doit(void)
 
 			if (i == 0)	/* we use the primary key which is RSA. Test the RSA ciphersuite */
 				gnutls_priority_set_direct(session,
-							   "NONE:+VERS-TLS1.0:+CIPHER-ALL:+MAC-ALL:+SIGN-ALL:+COMP-ALL:+RSA:+CTYPE-OPENPGP",
+							   "NORMAL:+CTYPE-OPENPGP",
 							   NULL);
 			else
 				gnutls_priority_set_direct(session,
-							   "NONE:+VERS-TLS1.0:+CIPHER-ALL:+MAC-ALL:+SIGN-ALL:+COMP-ALL:+DHE-DSS:+DHE-RSA:+CTYPE-OPENPGP",
+							   "NORMAL:+CTYPE-OPENPGP",
 							   NULL);
 			gnutls_transport_set_int(session, sockets[0]);
 
@@ -257,7 +256,7 @@ void doit(void)
 				fail("server session %d\n", err);
 
 			gnutls_priority_set_direct(session,
-						   "NONE:+VERS-TLS1.0:+CIPHER-ALL:+MAC-ALL:+SIGN-ALL:+COMP-ALL:+DHE-DSS:+DHE-RSA:+RSA:+CTYPE-OPENPGP",
+						   "NORMAL:+CTYPE-OPENPGP",
 						   NULL);
 			gnutls_transport_set_int(session, sockets[1]);
 

From tobbe.se at gmail.com  Sun Dec 13 21:34:20 2015
From: tobbe.se at gmail.com (Tobias ---)
Date: Sun, 13 Dec 2015 21:34:20 +0100
Subject: [gnutls-help] certtool - key encipherment (X.509v3 extension)
Message-ID: <CAEOz=K1U3UkeTfMJsjX=NhDt9mt+p6Rn=F5=UB2z8neoc4qQuQ@mail.gmail.com>

Hello!

I'm trying to create a certificate that contains the necessary options to
let libvirtd service work to as intended with remote control over TLS.

I have created my own CA using certtool and the problem that I'm having is
with the server certificate.
The template that I'm using when I create the CSR is as follows:

organization = "Local libvirtd"
unit = "libvirtd server"
cn = "oink"
country = "SE"
state = "Sweden"
expiration_days = 1095
tls_www_server
signing_key
encryption_key

I've also tried to make certtool honour the extensions which it does to a
certain degree. The "encryption_key" is not honored even if I try to
enforce it using the "honour_crq_extensions" option as well as using the
above template when I sign the CSR with the CA. The resulting PEM-encoded
certificate generates the following error during startup of libvirtd:

dec 13 20:58:20 oink libvirtd[15630]: Certificate
/etc/pki/libvirt/servercert.pem usage does not permit key encipherment

When I verify the certificates then I get no indications that something is
missing. When I inspect the certificates then the encryption_key extension
is missing and the only options that show up in the certificate are the
tls_www_server and signing_key options. I'm trying to use encryption_key
because libvirtd expects it and the manual for libvirtd also indicates that
it's needed ( http://libvirt.org/remote.html ).

I am able to get around this issue by telling libivirtd to skip sanity
check of its own certificates, but the missing key encipherment usage
option in the certificate is missing.

Is this behaviour expected?

The current version of certtool is 3.4.7, running on a up-to-date install
of Arch Linux.

Thanks in advance,
Tobias Dahlberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151213/1c66b421/attachment.html>

From nmav at gnutls.org  Mon Dec 14 09:43:37 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 14 Dec 2015 09:43:37 +0100
Subject: [gnutls-help] certtool - key encipherment (X.509v3 extension)
In-Reply-To: <CAEOz=K1U3UkeTfMJsjX=NhDt9mt+p6Rn=F5=UB2z8neoc4qQuQ@mail.gmail.com>
References: <CAEOz=K1U3UkeTfMJsjX=NhDt9mt+p6Rn=F5=UB2z8neoc4qQuQ@mail.gmail.com>
Message-ID: <CAJU7za+rFjRnxkpFMiUjY_63GA_uRMbP1GbUK-QVGo=YoM=RTQ@mail.gmail.com>

On Sun, Dec 13, 2015 at 9:34 PM, Tobias --- <tobbe.se at gmail.com> wrote:
> Hello!
>
> I'm trying to create a certificate that contains the necessary options to
> let libvirtd service work to as intended with remote control over TLS.
>
> I have created my own CA using certtool and the problem that I'm having is
> with the server certificate.
> The template that I'm using when I create the CSR is as follows:
> organization = "Local libvirtd"
> unit = "libvirtd server"
> cn = "oink"
> country = "SE"
> state = "Sweden"
> expiration_days = 1095
> tls_www_server
> signing_key
> encryption_key
> I've also tried to make certtool honour the extensions which it does to a
> certain degree. The "encryption_key" is not honored even if I try to enforce
> it using the "honour_crq_extensions" option as well as using the above
> template when I sign the CSR with the CA. The resulting PEM-encoded
> certificate generates the following error during startup of libvirtd:

Hi,
 Could you send the command set that reproduces that? Note however,
that if you have access to the CA key you don't need to go through a
CSR to generate a certificate. You can generate it directly from the
template.

regards,
Nikos


From tobbe.se at gmail.com  Mon Dec 14 10:31:07 2015
From: tobbe.se at gmail.com (Tobias ---)
Date: Mon, 14 Dec 2015 10:31:07 +0100
Subject: [gnutls-help] certtool - key encipherment (X.509v3 extension)
In-Reply-To: <CAJU7za+rFjRnxkpFMiUjY_63GA_uRMbP1GbUK-QVGo=YoM=RTQ@mail.gmail.com>
References: <CAEOz=K1U3UkeTfMJsjX=NhDt9mt+p6Rn=F5=UB2z8neoc4qQuQ@mail.gmail.com>
 <CAJU7za+rFjRnxkpFMiUjY_63GA_uRMbP1GbUK-QVGo=YoM=RTQ@mail.gmail.com>
Message-ID: <CAEOz=K0WVKLWKRtarqX4whSNSihNa4P51209O+Kfq6LgHu5DOg@mail.gmail.com>

2015-12-14 9:43 GMT+01:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Sun, Dec 13, 2015 at 9:34 PM, Tobias --- <tobbe.se at gmail.com> wrote:
> > Hello!
> >
> > I'm trying to create a certificate that contains the necessary options to
> > let libvirtd service work to as intended with remote control over TLS.
> >
> > I have created my own CA using certtool and the problem that I'm having
> is
> > with the server certificate.
> > The template that I'm using when I create the CSR is as follows:
> > organization = "Local libvirtd"
> > unit = "libvirtd server"
> > cn = "oink"
> > country = "SE"
> > state = "Sweden"
> > expiration_days = 1095
> > tls_www_server
> > signing_key
> > encryption_key
> > I've also tried to make certtool honour the extensions which it does to a
> > certain degree. The "encryption_key" is not honored even if I try to
> enforce
> > it using the "honour_crq_extensions" option as well as using the above
> > template when I sign the CSR with the CA. The resulting PEM-encoded
> > certificate generates the following error during startup of libvirtd:
>
> Hi,
>  Could you send the command set that reproduces that? Note however,
> that if you have access to the CA key you don't need to go through a
> CSR to generate a certificate. You can generate it directly from the
> template.
>
> regards,
> Nikos
>

Hi!

The reason that I'm creating a CSR and then a CRT is because I'm going to
create multilple certificates. I need to create certificates for my client
to so I want to do it the same way for both server and client. I am aware
that I can create the certificate in one go. The commands that I use are as
follow:

certtool --generate-request --load-privkey serverkey.pem --template
server.info --outfile servercsr.pem --hash=sha512
# The template "server.info" is what I pasted in the first post.

certtool --generate-certificate --load-ca-certificate cacert.pem
--load-ca-privkey cakey.pem --template server.info --load-request
servercsr.pem --outfile servercert.pem --hash=sha512
# If I give it the template here then I don't get a bunch of questions. If
I don't then I get what I specified for the CSR but if I answer YES to the
question about TLS web server then I get that extension listed twice in the
certificate. If I omit the template and answer the questions then I don't
get any question regarding key encipherment and I still get the same
result. I get the same result regardless of what I do.

Best regards,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151214/b3a212f4/attachment.html>

From nmav at gnutls.org  Tue Dec 15 11:55:52 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 15 Dec 2015 11:55:52 +0100
Subject: [gnutls-help] certtool - key encipherment (X.509v3 extension)
In-Reply-To: <CAEOz=K0WVKLWKRtarqX4whSNSihNa4P51209O+Kfq6LgHu5DOg@mail.gmail.com>
References: <CAEOz=K1U3UkeTfMJsjX=NhDt9mt+p6Rn=F5=UB2z8neoc4qQuQ@mail.gmail.com>
 <CAJU7za+rFjRnxkpFMiUjY_63GA_uRMbP1GbUK-QVGo=YoM=RTQ@mail.gmail.com>
 <CAEOz=K0WVKLWKRtarqX4whSNSihNa4P51209O+Kfq6LgHu5DOg@mail.gmail.com>
Message-ID: <CAJU7zaJpMK87WwkJR_dbTOfWy5Lbyv3+yTXNeAJiVGCpb0kL2Q@mail.gmail.com>

On Mon, Dec 14, 2015 at 10:31 AM, Tobias --- <tobbe.se at gmail.com> wrote:
> 2015-12-14 9:43 GMT+01:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:
>>
>> On Sun, Dec 13, 2015 at 9:34 PM, Tobias --- <tobbe.se at gmail.com> wrote:
>> > Hello!
>> >
>> > I'm trying to create a certificate that contains the necessary options
>> > to
>> > let libvirtd service work to as intended with remote control over TLS.
>> >
>> > I have created my own CA using certtool and the problem that I'm having
>> > is
>> > with the server certificate.
>> > The template that I'm using when I create the CSR is as follows:
>> > organization = "Local libvirtd"
>> > unit = "libvirtd server"
>> > cn = "oink"
>> > country = "SE"
>> > state = "Sweden"
>> > expiration_days = 1095
>> > tls_www_server
>> > signing_key
>> > encryption_key
>> > I've also tried to make certtool honour the extensions which it does to
>> > a
>> > certain degree. The "encryption_key" is not honored even if I try to
>> > enforce
>> > it using the "honour_crq_extensions" option as well as using the above
>> > template when I sign the CSR with the CA. The resulting PEM-encoded
>> > certificate generates the following error during startup of libvirtd:

Note that the option is honor_crq_extensions.

> The reason that I'm creating a CSR and then a CRT is because I'm going to
> create multilple certificates. I need to create certificates for my client
> to so I want to do it the same way for both server and client. I am aware
> that I can create the certificate in one go. The commands that I use are as
> follow:
> certtool --generate-request --load-privkey serverkey.pem --template
> server.info --outfile servercsr.pem --hash=sha512
> # The template "server.info" is what I pasted in the first post.
>
> certtool --generate-certificate --load-ca-certificate cacert.pem
> --load-ca-privkey cakey.pem --template server.info --load-request
> servercsr.pem --outfile servercert.pem --hash=sha512
> # If I give it the template here then I don't get a bunch of questions. If I
> don't then I get what I specified for the CSR but if I answer YES to the
> question about TLS web server then I get that extension listed twice in the
> certificate.

Key purposes are not overwritten but appended so if it is already
specified by the client and set by the server you'll see it twice.

> If I omit the template and answer the questions then I don't
> get any question regarding key encipherment and I still get the same result.
> I get the same result regardless of what I do.

I cannot however reproduce (with honor_crq_extensions) your issue. I
see both Digital signature and Key encipherment in the generated
certificate.

regards,
Nikos


From tobbe.se at gmail.com  Tue Dec 15 17:36:57 2015
From: tobbe.se at gmail.com (Tobias ---)
Date: Tue, 15 Dec 2015 17:36:57 +0100
Subject: [gnutls-help] certtool - key encipherment (X.509v3 extension)
In-Reply-To: <CAJU7zaJpMK87WwkJR_dbTOfWy5Lbyv3+yTXNeAJiVGCpb0kL2Q@mail.gmail.com>
References: <CAEOz=K1U3UkeTfMJsjX=NhDt9mt+p6Rn=F5=UB2z8neoc4qQuQ@mail.gmail.com>
 <CAJU7za+rFjRnxkpFMiUjY_63GA_uRMbP1GbUK-QVGo=YoM=RTQ@mail.gmail.com>
 <CAEOz=K0WVKLWKRtarqX4whSNSihNa4P51209O+Kfq6LgHu5DOg@mail.gmail.com>
 <CAJU7zaJpMK87WwkJR_dbTOfWy5Lbyv3+yTXNeAJiVGCpb0kL2Q@mail.gmail.com>
Message-ID: <CAEOz=K1yQHrHKjdH4HTjEg2S1r+Prc8Lkb5WduC4wJbQJ0GjLA@mail.gmail.com>

2015-12-15 11:55 GMT+01:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Mon, Dec 14, 2015 at 10:31 AM, Tobias --- <tobbe.se at gmail.com> wrote:
> > 2015-12-14 9:43 GMT+01:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:
> >>
> >> On Sun, Dec 13, 2015 at 9:34 PM, Tobias --- <tobbe.se at gmail.com> wrote:
> >> > Hello!
> >> >
> >> > I'm trying to create a certificate that contains the necessary options
> >> > to
> >> > let libvirtd service work to as intended with remote control over TLS.
> >> >
> >> > I have created my own CA using certtool and the problem that I'm
> having
> >> > is
> >> > with the server certificate.
> >> > The template that I'm using when I create the CSR is as follows:
> >> > organization = "Local libvirtd"
> >> > unit = "libvirtd server"
> >> > cn = "oink"
> >> > country = "SE"
> >> > state = "Sweden"
> >> > expiration_days = 1095
> >> > tls_www_server
> >> > signing_key
> >> > encryption_key
> >> > I've also tried to make certtool honour the extensions which it does
> to
> >> > a
> >> > certain degree. The "encryption_key" is not honored even if I try to
> >> > enforce
> >> > it using the "honour_crq_extensions" option as well as using the above
> >> > template when I sign the CSR with the CA. The resulting PEM-encoded
> >> > certificate generates the following error during startup of libvirtd:
>
> Note that the option is honor_crq_extensions.
>
> > The reason that I'm creating a CSR and then a CRT is because I'm going to
> > create multilple certificates. I need to create certificates for my
> client
> > to so I want to do it the same way for both server and client. I am aware
> > that I can create the certificate in one go. The commands that I use are
> as
> > follow:
> > certtool --generate-request --load-privkey serverkey.pem --template
> > server.info --outfile servercsr.pem --hash=sha512
> > # The template "server.info" is what I pasted in the first post.
> >
> > certtool --generate-certificate --load-ca-certificate cacert.pem
> > --load-ca-privkey cakey.pem --template server.info --load-request
> > servercsr.pem --outfile servercert.pem --hash=sha512
> > # If I give it the template here then I don't get a bunch of questions.
> If I
> > don't then I get what I specified for the CSR but if I answer YES to the
> > question about TLS web server then I get that extension listed twice in
> the
> > certificate.
>
> Key purposes are not overwritten but appended so if it is already
> specified by the client and set by the server you'll see it twice.
>
> > If I omit the template and answer the questions then I don't
> > get any question regarding key encipherment and I still get the same
> result.
> > I get the same result regardless of what I do.
>
> I cannot however reproduce (with honor_crq_extensions) your issue. I
> see both Digital signature and Key encipherment in the generated
> certificate.
>
> regards,
> Nikos
>

I did write honor_crq_extensions. I just got confused when I read "honour"
somewhere else regarding this subject.

I've made additional attempts. The CSR doesn't contain the key encipherment
extension either. It only contains the other two extensions. I even copy
that extension straight out of the certtool manpage and it still won't
accept the extension. I wrote a separate template that contained
honor_crq_exntesions and encryption_key but it didn't produce the desired
result.
Does it matter that I use ECDSA?

Any suggestions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151215/6fba02be/attachment-0001.html>

From nmav at gnutls.org  Tue Dec 15 17:46:29 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 15 Dec 2015 17:46:29 +0100
Subject: [gnutls-help] certtool - key encipherment (X.509v3 extension)
In-Reply-To: <CAEOz=K1yQHrHKjdH4HTjEg2S1r+Prc8Lkb5WduC4wJbQJ0GjLA@mail.gmail.com>
References: <CAEOz=K1U3UkeTfMJsjX=NhDt9mt+p6Rn=F5=UB2z8neoc4qQuQ@mail.gmail.com>
 <CAJU7za+rFjRnxkpFMiUjY_63GA_uRMbP1GbUK-QVGo=YoM=RTQ@mail.gmail.com>
 <CAEOz=K0WVKLWKRtarqX4whSNSihNa4P51209O+Kfq6LgHu5DOg@mail.gmail.com>
 <CAJU7zaJpMK87WwkJR_dbTOfWy5Lbyv3+yTXNeAJiVGCpb0kL2Q@mail.gmail.com>
 <CAEOz=K1yQHrHKjdH4HTjEg2S1r+Prc8Lkb5WduC4wJbQJ0GjLA@mail.gmail.com>
Message-ID: <CAJU7zaLsFotGzg3jWvQoO_JYA-zziPFFqE5dXkBVTL6P0+dt_g@mail.gmail.com>

On Tue, Dec 15, 2015 at 5:36 PM, Tobias --- <tobbe.se at gmail.com> wrote:
> I did write honor_crq_extensions. I just got confused when I read "honour"
> somewhere else regarding this subject.
> I've made additional attempts. The CSR doesn't contain the key encipherment
> extension either. It only contains the other two extensions. I even copy
> that extension straight out of the certtool manpage and it still won't
> accept the extension. I wrote a separate template that contained
> honor_crq_exntesions and encryption_key but it didn't produce the desired
> result.
> Does it matter that I use ECDSA?

Yes, you cannot encrypt with ECDSA keys. They are signing keys.

regards,
Nikos


From tobbe.se at gmail.com  Tue Dec 15 18:48:11 2015
From: tobbe.se at gmail.com (Tobias ---)
Date: Tue, 15 Dec 2015 18:48:11 +0100
Subject: [gnutls-help] certtool - key encipherment (X.509v3 extension)
In-Reply-To: <CAJU7zaLsFotGzg3jWvQoO_JYA-zziPFFqE5dXkBVTL6P0+dt_g@mail.gmail.com>
References: <CAEOz=K1U3UkeTfMJsjX=NhDt9mt+p6Rn=F5=UB2z8neoc4qQuQ@mail.gmail.com>
 <CAJU7za+rFjRnxkpFMiUjY_63GA_uRMbP1GbUK-QVGo=YoM=RTQ@mail.gmail.com>
 <CAEOz=K0WVKLWKRtarqX4whSNSihNa4P51209O+Kfq6LgHu5DOg@mail.gmail.com>
 <CAJU7zaJpMK87WwkJR_dbTOfWy5Lbyv3+yTXNeAJiVGCpb0kL2Q@mail.gmail.com>
 <CAEOz=K1yQHrHKjdH4HTjEg2S1r+Prc8Lkb5WduC4wJbQJ0GjLA@mail.gmail.com>
 <CAJU7zaLsFotGzg3jWvQoO_JYA-zziPFFqE5dXkBVTL6P0+dt_g@mail.gmail.com>
Message-ID: <CAEOz=K3n-wvsvrsWmVjBpAENaYE_R=dSnasY-sa=dS3-r26pcA@mail.gmail.com>

Ooops, I see. I'm new to the elliptical curve things. Now I feel dumb.

I let the CA use ECDSA secp521r1 and I let clients and servers use RSA,
3072 bits (It appears to be the default). It all works now!

It would be nice if certtool would return errors or warnings when
extensions and keys aren't compatible, instead of just omitting the
incompatible extensions.

Thanks for the quick reply!

2015-12-15 17:46 GMT+01:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Tue, Dec 15, 2015 at 5:36 PM, Tobias --- <tobbe.se at gmail.com> wrote:
> > I did write honor_crq_extensions. I just got confused when I read
> "honour"
> > somewhere else regarding this subject.
> > I've made additional attempts. The CSR doesn't contain the key
> encipherment
> > extension either. It only contains the other two extensions. I even copy
> > that extension straight out of the certtool manpage and it still won't
> > accept the extension. I wrote a separate template that contained
> > honor_crq_exntesions and encryption_key but it didn't produce the desired
> > result.
> > Does it matter that I use ECDSA?
>
> Yes, you cannot encrypt with ECDSA keys. They are signing keys.
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151215/e1792203/attachment.html>

From erkan77 at gmail.com  Wed Dec 16 04:46:48 2015
From: erkan77 at gmail.com (Erkan Yilmaz)
Date: Wed, 16 Dec 2015 04:46:48 +0100
Subject: [gnutls-help] 3.3.x version: how long supported ?
Message-ID: <CAD3HTdczLePoPwOxSpgHS2fAOmXPWkkhhAFPvA=pRHF9hNGHpQ@mail.gmail.com>

Hello,

since about 2 weeks ago the version 3.4.x was marked as stable version (1),

I'd like to know if there will be still updates (e.g. security fixes) for
the 3.3.x version ?
If there would be updates, how long will this be then max.?
(e.g. in case some LTS exists? end of life?)

Thank you,
Erkan

(1) http://lists.gnutls.org/pipermail/gnutls-devel/2015-November/007801.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151216/55e6e60e/attachment.html>

From cheako+gnutls at mikemestnik.net  Thu Dec 17 00:18:27 2015
From: cheako+gnutls at mikemestnik.net (Mike Mestnik)
Date: Wed, 16 Dec 2015 17:18:27 -0600
Subject: [gnutls-help] _gnutls_remove_unwanted_ciphersuites: Looking for
	function definition.
Message-ID: <CAF8px55Gi=ZKTAuyL0HJqb=e7ad2eXqD0+VjGqPhZeeGbyt9gw@mail.gmail.com>

I'm tracing down why a ciphersuite is being rejected and I need to
locate where the definition of this function is.

I see the prototype in multiple header files:
lib/algorithms.h
lib/gnutls_handshake.h


From nmav at gnutls.org  Thu Dec 17 10:04:15 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Dec 2015 10:04:15 +0100
Subject: [gnutls-help] 3.3.x version: how long supported ?
In-Reply-To: <CAD3HTdczLePoPwOxSpgHS2fAOmXPWkkhhAFPvA=pRHF9hNGHpQ@mail.gmail.com>
References: <CAD3HTdczLePoPwOxSpgHS2fAOmXPWkkhhAFPvA=pRHF9hNGHpQ@mail.gmail.com>
Message-ID: <CAJU7za+7E2sMqJpmv+wYdNfkqXi3pKk9eGZObXVfW2GzhjwiTg@mail.gmail.com>

On Wed, Dec 16, 2015 at 4:46 AM, Erkan Yilmaz <erkan77 at gmail.com> wrote:
> Hello,
> since about 2 weeks ago the version 3.4.x was marked as stable version (1),
> I'd like to know if there will be still updates (e.g. security fixes) for
> the 3.3.x version ?
> If there would be updates, how long will this be then max.?
> (e.g. in case some LTS exists? end of life?)

There is no policy at the moment. However it would make sense to make
a best effort policy which will be something like:
on an ABI breakage the (stable) release will be updated with security
fixes for at least X years.

The number I have for X in my mind is something between 2 and 4. That
will of course be a statement of intention, which will depend on the
project's resources at each time. If you are looking for a contract or
so, you should check: http://www.gnutls.org/commercial.html

regards,
Nikos


From rick at openfortress.nl  Thu Dec 17 11:54:41 2015
From: rick at openfortress.nl (Rick van Rein)
Date: Thu, 17 Dec 2015 11:54:41 +0100
Subject: [gnutls-help] Signing an X.509 cert with a PKCS #11 privkey
Message-ID: <56729471.3080602@openfortress.nl>

Hello,

I'm trying to create an X.509 certificate and then sign it using
gnutls_x509_crt_sign2().  That call however, requires the issuer key to
be a gnutls_x509_privkey_t.  The signing that I have however, is a PKCS
#11 key located with a pkcs11: URI.

I can find a path from both X.509 private keys and PKCS #11 private keys
to the abstract form gnutls_privkey_t, but I cannot find the way to sign
the certificate with the PKCS #11 key.  Am I overlooking functions or
paths connecting them?

I am using GnuTLS 3.4.7 and have looked through the online API
documentation and the code.  Interestingly, but not surprisingly, the
only thing that gnutls_x509_crt_sign2()  does is convert the private key
to the gnutls_privkey_t that I already have.

Thanks,
 -Rick


From rick at openfortress.nl  Thu Dec 17 12:00:36 2015
From: rick at openfortress.nl (Rick van Rein)
Date: Thu, 17 Dec 2015 12:00:36 +0100
Subject: [gnutls-help] Signing an X.509 cert with a PKCS #11 privkey
In-Reply-To: <56729471.3080602@openfortress.nl>
References: <56729471.3080602@openfortress.nl>
Message-ID: <567295D4.6060501@openfortress.nl>

Ah,

I found the solution while writing this: gnutls_x509_crt_privkey_sign()
but sorry, I did not properly stop this message from being sent.

-Rick


From dbreiser at gmail.com  Fri Dec 18 05:50:11 2015
From: dbreiser at gmail.com (David Reiser)
Date: Thu, 17 Dec 2015 23:50:11 -0500
Subject: [gnutls-help] gnutls 3.4.7 failing make check in no-signal
Message-ID: <DDF7A27B-845D-459C-BAA2-D82AB5D79D70@gmail.com>

I?m trying to build gnutls 3.4.7 in OS X 10.11.2, and make check fails in tests/no-signal

The no-signal.log file says ?sigpipe received? and nothing else. Other than 2 skipped tests, all other tests pass.

Suggestions?
--
David Reiser
dbreiser at gmail.com





From nmav at gnutls.org  Fri Dec 18 10:25:58 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Dec 2015 10:25:58 +0100
Subject: [gnutls-help] gnutls 3.4.7 failing make check in no-signal
In-Reply-To: <DDF7A27B-845D-459C-BAA2-D82AB5D79D70@gmail.com>
References: <DDF7A27B-845D-459C-BAA2-D82AB5D79D70@gmail.com>
Message-ID: <CAJU7za+XpNYpow4=6mxcmaF1dg3TEcu=_=T5poisqXj3V9GD7g@mail.gmail.com>

On Fri, Dec 18, 2015 at 5:50 AM, David Reiser <dbreiser at gmail.com> wrote:
> I?m trying to build gnutls 3.4.7 in OS X 10.11.2, and make check fails in tests/no-signal
>
> The no-signal.log file says ?sigpipe received? and nothing else. Other than 2 skipped tests, all other tests pass.

It seems that macosx doesn't support the MSG_NOSIGNAL flag. With the
attached patch you can skip this test.


regards,
Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-tests-don-t-run-the-no-signal-test-in-systems-which-.patch
Type: text/x-diff
Size: 1246 bytes
Desc: not available
URL: </pipermail/attachments/20151218/9931daa3/attachment.patch>

From seyeong.kim at canonical.com  Wed Dec 23 03:17:06 2015
From: seyeong.kim at canonical.com (Seyeong Kim)
Date: Wed, 23 Dec 2015 11:17:06 +0900
Subject: [gnutls-help] issue with Windows 2008r2 Ldap
Message-ID: <4F530303-4053-4DC7-A5F2-60CDEE674020@canonical.com>

Hello

I have an issue with gnutls ( maybe not ) and Windows 2008r2 Ldap

when I tried to ldapsearch to windows ldap, I got below message


TLS: can't connect: A TLS packet with unexpected length was received.. 


there are two AD, 2008r2, 2012r2 and I could only see this error on 2012r2 + ubuntu 14.xx combination

I checked gnutls version 

libgnutls26 | 2.12.23-12ubuntu2.3

libgnutls-deb0-28 | 3.3.8-3ubuntu3   | vivid


Is there any commits I can refer to this issue?

I know there are large differences between two versions. so I need an advice.

Thanks 




From nmav at gnutls.org  Thu Dec 24 11:01:21 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 24 Dec 2015 12:01:21 +0200
Subject: [gnutls-help] issue with Windows 2008r2 Ldap
In-Reply-To: <4F530303-4053-4DC7-A5F2-60CDEE674020@canonical.com>
References: <4F530303-4053-4DC7-A5F2-60CDEE674020@canonical.com>
Message-ID: <CAJU7zaJ9WYzHggs9B1VuC_iiYZ6_AuAQmi32J0-A21QMqTHimQ@mail.gmail.com>

On Wed, Dec 23, 2015 at 4:17 AM, Seyeong Kim <seyeong.kim at canonical.com> wrote:
> Hello
> I have an issue with gnutls ( maybe not ) and Windows 2008r2 Ldap
> when I tried to ldapsearch to windows ldap, I got below message
> TLS: can't connect: A TLS packet with unexpected length was received..

Most likely you are connecting to a port which doesn't support TLS.


From andre at liechti.net  Mon Dec 28 11:03:35 2015
From: andre at liechti.net (Hilitec)
Date: Mon, 28 Dec 2015 10:03:35 +0000 (UTC)
Subject: [gnutls-help] issue with Windows 2008r2 Ldap
References: <4F530303-4053-4DC7-A5F2-60CDEE674020@canonical.com>
Message-ID: <loom.20151228T104537-354@post.gmane.org>

Seyeong Kim <seyeong.kim <at> canonical.com> writes:

> 
> Hello
> 
> I have an issue with gnutls ( maybe not ) and Windows 2008r2 Ldap
> 
> when I tried to ldapsearch to windows ldap, I got below message
> 
> TLS: can't connect: A TLS packet with unexpected length was received.. 
> 
> there are two AD, 2008r2, 2012r2 and I could only see this error on 2012r2
+ ubuntu 14.xx combination
> 
> I checked gnutls version 
> 
> libgnutls26 | 2.12.23-12ubuntu2.3
> 
> libgnutls-deb0-28 | 3.3.8-3ubuntu3   | vivid
> 
> Is there any commits I can refer to this issue?
> 
> I know there are large differences between two versions. so I need an advice.
> 
> Thanks 
> 

Hello,

GnuTLS and SChannel (Microsoft) implementations are not (yet) compatible for
TLS 1.2 negotiation during AD/LDAPS binding.

The trick is to disable TLS1.2 for OpenLDAP like this:
export LDAPTLS_CIPHER_SUITE=NORMAL:!VERS-TLS1.2

If you are binding AD/LDAP from PHP, you can do something like that:
putenv(?LDAPTLS_CIPHER_SUITE=NORMAL:!VERS-TLS1.2?);

Hope it helps

Best regards,

Andre

From nmav at gnutls.org  Tue Dec 29 14:04:09 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 29 Dec 2015 15:04:09 +0200
Subject: [gnutls-help] issue with Windows 2008r2 Ldap
In-Reply-To: <loom.20151228T104537-354@post.gmane.org>
References: <4F530303-4053-4DC7-A5F2-60CDEE674020@canonical.com>
 <loom.20151228T104537-354@post.gmane.org>
Message-ID: <CAJU7zaKr7GiFygvZzr5VHbuG4g=OWpAw5HZ2owYBKfSvy=p_bw@mail.gmail.com>

On Mon, Dec 28, 2015 at 12:03 PM, Hilitec <andre at liechti.net> wrote:
> Seyeong Kim <seyeong.kim <at> canonical.com> writes:
>> Hello
>> I have an issue with gnutls ( maybe not ) and Windows 2008r2 Ldap
>> when I tried to ldapsearch to windows ldap, I got below message
>> TLS: can't connect: A TLS packet with unexpected length was received..
>> there are two AD, 2008r2, 2012r2 and I could only see this error on 2012r2
> + ubuntu 14.xx combination
>> I checked gnutls version
>> libgnutls26 | 2.12.23-12ubuntu2.3
>> libgnutls-deb0-28 | 3.3.8-3ubuntu3   | vivid
>> Is there any commits I can refer to this issue?
>> I know there are large differences between two versions. so I need an advice.
> GnuTLS and SChannel (Microsoft) implementations are not (yet) compatible for
> TLS 1.2 negotiation during AD/LDAPS binding.

That's the first time I see something like that. As far as I know
schannel and gnutls are fully compatible with TLS 1.2. Is there any
bug report or more information on that incompatibility that you
mention?

regards,
Nikos


From nmav at gnutls.org  Wed Dec 30 11:13:31 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Dec 2015 12:13:31 +0200
Subject: [gnutls-help] issue with Windows 2008r2 Ldap
In-Reply-To: <003801d14261$80ea1360$82be3a20$@liechti.net>
References: <4F530303-4053-4DC7-A5F2-60CDEE674020@canonical.com>
 <loom.20151228T104537-354@post.gmane.org>
 <CAJU7zaKr7GiFygvZzr5VHbuG4g=OWpAw5HZ2owYBKfSvy=p_bw@mail.gmail.com>
 <003801d14261$80ea1360$82be3a20$@liechti.net>
Message-ID: <CAJU7zaKeLtku5q=hrm5n21kOLvgs7pz-8LJBPH8n1-894XS97g@mail.gmail.com>

On Tue, Dec 29, 2015 at 7:51 PM, Andr? Liechti <andre at liechti.net> wrote:
> Like other people, I had this issue, and I had to fix it as soon as possible.
> I dug a little bit, I put the Windows 2012R2 server in debug mode for Schannel (https://support.microsoft.com/en-us/kb/260729), and I tried to bind using ldaps, with the following errors:
> - An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.
> - A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.
> Found on Microsoft forum:
> "When OpenSSL establishes the connection to AD LDAP it sends its client cipher list, but TLSv1.2 allows for a longer cipher list than earlier versions, AD LDAP doesn't seem to accept this. When the longer list gets sent AD believes its a corrupted packet so drops the connection." (https://social.technet.microsoft.com/Forums/windows/en-US/b6ffa278-4a04-4609-ac35-8390f5ba9cb6/ldap-over-ssl-on-windows-2012r2-server-dcs-tls-12-not-working?forum=winserversecurity)
> After disabling the TLS1.2 support, I was able to bind using ldaps:
> -An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.
> - Protocol: TLS 1.1
> - CipherSuite: 0x2F
> - Exchange strength: 1024
> I don't know exactly which cipher suite has a problem, but currently it's enough for me to work with TLS 1.1.

That's interesting. As I understand it, it means that the client hello
is larger than some limit required by this server. Does disabling some
legacy ciphersuites has the same effect as disabling TLS 1.2? e.g. a
priority string such as
"NORMAL:-ARCFOUR128:-DHE-DSS:-SIGN-DSA-SHA256:-SIGN-DSA-SHA1"?


From andre at liechti.net  Tue Dec 29 19:15:39 2015
From: andre at liechti.net (=?utf-8?Q?Andr=C3=A9_Liechti?=)
Date: Tue, 29 Dec 2015 18:15:39 -0000
Subject: [gnutls-help] issue with Windows 2008r2 Ldap
In-Reply-To: <CAJU7zaKr7GiFygvZzr5VHbuG4g=OWpAw5HZ2owYBKfSvy=p_bw@mail.gmail.com>
References: <4F530303-4053-4DC7-A5F2-60CDEE674020@canonical.com>
 <loom.20151228T104537-354@post.gmane.org>
 <CAJU7zaKr7GiFygvZzr5VHbuG4g=OWpAw5HZ2owYBKfSvy=p_bw@mail.gmail.com>
Message-ID: <003801d14261$80ea1360$82be3a20$@liechti.net>

Like other people, I had this issue, and I had to fix it as soon as possible.

I dug a little bit, I put the Windows 2012R2 server in debug mode for Schannel (https://support.microsoft.com/en-us/kb/260729), and I tried to bind using ldaps, with the following errors:
- An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.
- A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.

Found on Microsoft forum:
"When OpenSSL establishes the connection to AD LDAP it sends its client cipher list, but TLSv1.2 allows for a longer cipher list than earlier versions, AD LDAP doesn't seem to accept this. When the longer list gets sent AD believes its a corrupted packet so drops the connection." (https://social.technet.microsoft.com/Forums/windows/en-US/b6ffa278-4a04-4609-ac35-8390f5ba9cb6/ldap-over-ssl-on-windows-2012r2-server-dcs-tls-12-not-working?forum=winserversecurity)

After disabling the TLS1.2 support, I was able to bind using ldaps:
-An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.
- Protocol: TLS 1.1
- CipherSuite: 0x2F
- Exchange strength: 1024

I don't know exactly which cipher suite has a problem, but currently it's enough for me to work with TLS 1.1.

Regards,
Andre


-----Message d'origine-----
De : n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] De la part de Nikos Mavrogiannopoulos
Envoy? : mardi 29 d?cembre 2015 14:04
? : Hilitec
Cc : GnuTLS mailing list
Objet : Re: [gnutls-help] issue with Windows 2008r2 Ldap

On Mon, Dec 28, 2015 at 12:03 PM, Hilitec <andre at liechti.net> wrote:
> Seyeong Kim <seyeong.kim <at> canonical.com> writes:
>> Hello
>> I have an issue with gnutls ( maybe not ) and Windows 2008r2 Ldap 
>> when I tried to ldapsearch to windows ldap, I got below message
>> TLS: can't connect: A TLS packet with unexpected length was received..
>> there are two AD, 2008r2, 2012r2 and I could only see this error on 
>> 2012r2
> + ubuntu 14.xx combination
>> I checked gnutls version
>> libgnutls26 | 2.12.23-12ubuntu2.3
>> libgnutls-deb0-28 | 3.3.8-3ubuntu3   | vivid
>> Is there any commits I can refer to this issue?
>> I know there are large differences between two versions. so I need an advice.
> GnuTLS and SChannel (Microsoft) implementations are not (yet) 
> compatible for TLS 1.2 negotiation during AD/LDAPS binding.

That's the first time I see something like that. As far as I know schannel and gnutls are fully compatible with TLS 1.2. Is there any bug report or more information on that incompatibility that you mention?

regards,
Nikos