From mk at cognitivedissonance.ca  Tue Oct  1 17:41:41 2013
From: mk at cognitivedissonance.ca (MK)
Date: Tue, 1 Oct 2013 11:41:41 -0400
Subject: [gnutls-help] Chrome and GNUTLS_E_PREMATURE_TERMINATION
Message-ID: <20131001114141.60ec3b1d762973b07932c7fe@cognitivedissonance.ca>

I have an HTTP server under development using gnuTLS, and notice a
strange issue when testing with Chrome specifically -- the first
gnutls_record_recv() on a new connection will frequently fail with
GNUTLS_E_PREMATURE_TERMINATION.

Chrome retries until it gets what it is looking for, so this is not
noticeable to the user, but it means there are extra wasted
connections made, as opposed to firefox which does not do this.

Has anyone else experienced this?

Sincerely, MK

-- 
"You are lost in the Real." -- Jean Baudrillard


From nmav at gnutls.org  Wed Oct  2 00:28:55 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 02 Oct 2013 00:28:55 +0200
Subject: [gnutls-help] Chrome and GNUTLS_E_PREMATURE_TERMINATION
In-Reply-To: <20131001114141.60ec3b1d762973b07932c7fe@cognitivedissonance.ca>
References: <20131001114141.60ec3b1d762973b07932c7fe@cognitivedissonance.ca>
Message-ID: <524B4CA7.60701@gnutls.org>

On 10/01/2013 05:41 PM, MK wrote:
> I have an HTTP server under development using gnuTLS, and notice a
> strange issue when testing with Chrome specifically -- the first
> gnutls_record_recv() on a new connection will frequently fail with
> GNUTLS_E_PREMATURE_TERMINATION.

Hello,
 That means that the other party terminated the connection.

> Chrome retries until it gets what it is looking for, so this is not
> noticeable to the user, but it means there are extra wasted
> connections made, as opposed to firefox which does not do this.
> Has anyone else experienced this?

You may see what chrome is looking for by checking the connections using
wireshark. I suspect that chrome is trying to determine the highest TLS
version number supported by the server.

regards,
Nikos



From mk at cognitivedissonance.ca  Thu Oct  3 14:16:35 2013
From: mk at cognitivedissonance.ca (MK)
Date: Thu, 3 Oct 2013 08:16:35 -0400
Subject: [gnutls-help] Chrome and GNUTLS_E_PREMATURE_TERMINATION
In-Reply-To: <524B4CA7.60701@gnutls.org>
References: <20131001114141.60ec3b1d762973b07932c7fe@cognitivedissonance.ca>
 <524B4CA7.60701@gnutls.org>
Message-ID: <20131003081635.3ef4c0f86f590ea965bf03e5@cognitivedissonance.ca>

On Wed, 02 Oct 2013 00:28:55 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 10/01/2013 05:41 PM, MK wrote:
>> I have an HTTP server under development using gnuTLS, and notice a
>> strange issue when testing with Chrome specifically -- the first
>> gnutls_record_recv() on a new connection will frequently fail with
>> GNUTLS_E_PREMATURE_TERMINATION.
> 
>  That means that the other party terminated the connection.
>
>> Chrome retries until it gets what it is looking for, so this is not
>>noticeable to the user, 
> 
> You may see what chrome is looking for by checking the connections
> using wireshark. I suspect that chrome is trying to determine the
> highest TLS version number supported by the server.

Actually what I meant by "retries until gets what it is looking for" is
the web page; what it's looking for beyond/before that with the
"improperly terminated connections" I dunno.  Here's an example of what
happens in wireshark: 

1) Chrome initiates a connection (actually, it usually initiates *two*
connections simultaneously, but they both do the same thing -- this
appears interleaved as both client and server are otherwise idle). That
goes through a normal SYN, SYN, ACK shake then there is a TLS 1.1 Client
Hello.  The server says Hello in return with a certificate, then Server
Hello Done.

2) Client sends Client Key Exchange together with a Change Cipher Spec
and Encrypted Handshake.  The server responds with a Change Cipher Spec
and Encrypted Handshake.

3) The client sends a FIN.  The server sends an ACK back but no FIN --
instead there is a TLS "Encryption Alert".

4) The client sends a RST.  It then initiates a new connection, which
goes through #1 and #2 but then proceeds properly.

Is this consistent with what you have said about trying to determine
the TLS version?

MK

-- 
"You are lost in the Real." -- Jean Baudrillard


From dkg at fifthhorseman.net  Thu Oct  3 15:33:05 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 03 Oct 2013 09:33:05 -0400
Subject: [gnutls-help] Chrome and GNUTLS_E_PREMATURE_TERMINATION
In-Reply-To: <20131003081635.3ef4c0f86f590ea965bf03e5@cognitivedissonance.ca>
References: <20131001114141.60ec3b1d762973b07932c7fe@cognitivedissonance.ca>
 <524B4CA7.60701@gnutls.org>
 <20131003081635.3ef4c0f86f590ea965bf03e5@cognitivedissonance.ca>
Message-ID: <524D7211.9000400@fifthhorseman.net>

On 10/03/2013 08:16 AM, MK wrote:
> Actually what I meant by "retries until gets what it is looking for" is
> the web page; what it's looking for beyond/before that with the
> "improperly terminated connections" I dunno.  Here's an example of what
> happens in wireshark: 


> 1) Chrome initiates a connection (actually, it usually initiates *two*
> connections simultaneously, but they both do the same thing -- this
> appears interleaved as both client and server are otherwise idle). That
> goes through a normal SYN, SYN, ACK shake then there is a TLS 1.1 Client
> Hello.  The server says Hello in return with a certificate, then Server
> Hello Done.
> 
> 2) Client sends Client Key Exchange together with a Change Cipher Spec
> and Encrypted Handshake.  The server responds with a Change Cipher Spec
> and Encrypted Handshake.
> 
> 3) The client sends a FIN.  The server sends an ACK back but no FIN --
> instead there is a TLS "Encryption Alert".
> 
> 4) The client sends a RST.  It then initiates a new connection, which
> goes through #1 and #2 but then proceeds properly.

I think you want to compare the details of the TLS version numbers and
the cipher suites offered in the Server and Client Hellos from stages
(1) and (4) to see what chrome is doing differently on the second
attempt.  You may also want to examine if there are changes in the TLS
extensions offered.

hth,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131003/3c2d94a1/attachment.sig>

From bry8star at yahoo.com  Tue Oct  8 08:47:39 2013
From: bry8star at yahoo.com (Bry8 Star)
Date: Mon, 07 Oct 2013 23:47:39 -0700
Subject: [gnutls-help] GnuTLS based AES tunnel, SOCKS 5/4A support, TAP
Message-ID: <5253AA8B.9070506@yahoo.com>

Hi,
How would i create GnuTLS based AES-encrypted port-forwarding
tunnels from Cmp1 to Cmp2 ?

Please first see/read the below four QUESTION sections/paragraphs
mentioned below.
For details you may read other paragraphs.

Cmp = Computer.
IP = IP-Address (ipv4).

Both/all side/hosts will use Linux, (for example, Fedora (or other
distro), or Mac OS X. (Pls do not tell me to goto fedora
mailing-list now, Thanks)).

Frontside --> GnuTLS tunnel --> Backend :
host1.example1.org -> GnuTLS tunnel -> host2.example2.org :
I want to create AES (256 bit) encrypted (port-forwarding) tunnel(s)
for following listening ports: 25 (SMTP), 53 (DNS), 80 (HTTP), 443
(HTTPS), 554 (RTSP), 587 (SUBMISSION), 993 (IMAPS), 5004 (RTP), 5005
(RTCP), 5060 (SIP), 5061 (SIPS), 5070, 6697 (IRC SSL), etc from
Cmp1's (host1.example1.org or it's Internet IP-Address), toward Cmp2
(host2.example2.org or it's Internet IP-Address), like shown in
above.  And then AGAIN traffic/packets will be forwarded toward the
Cmp2-side's 127.0.0.1 local loopback address.
So its also like this:
host1_IP -> gnutls tunnel -> host2_IP -> 127.0.0.1

Another, Frontside --> GnuTLS tunnel --> Backend :
host3.example1.org -> gnutls tunnel -> host4.example2.org :
Above mentioned system configuration will be applied on host3 and
host4, like shown in above line.
(host3_IP --> host4_IP).

host1 and host3 are used by users coming from internet side to
"example1.org". They do not know about host2 or host4 or about
"example2.org" (primary-backend).

host2, host4 : BackEnd Servers :
Actual server software will run from inside host2, and, host4.  The
example1.org domain-name's self-signed/own TLS cert's private-key
portion, (related to above mentioned ports and related network and
internet services), will reside/remain inside host2, and, host4
(primary-backend).  Services will run inside chroot jail or LXC
container inside host2 and host4.

Basically, i'm using the host1 and host3 as traffic reflector (or as
front-side), and these are obtained from Hosting Service Provider
company(s).

And ultimate objective here is to keep my own self-signed various
certificate's and key's private/secret key portion (related to main
services) on my own server(s), which are host2 and host4 (primary
backend), i do not want to keep private/secret key on such remote
servers which may/can view/copy private/secret key portion.

Instead of using SSH tunnel (which uses openssl), i'm looking for a
solution based on GnuTLS based tunnel, because, it has such as these
extra features not available in openssl yet : DTLS, DANE/TLSA,
DNSSEC, etc. To me it seems, GnuTLS is able to do more/extra
authentications, so its more secured (against more attacks/exploits).

QUESTION (1) : So how can i create port-forwarding encrypted tunnel
(which is configured to support only: AES CBC/GCM, 256-bit, SHA512
MAC, TLS 1.2, etc) similar to SSH tunnel, by using GnuTLS, for
linking Computer1 with Computer2 ?  How to create related AES key
(PSK) or TLS certificate/cert/key (using GnuTLS) ?  If gnutls itself
do not have tools for such mentioned purposes, can someone pls
show/point-to very simple WORKING code snipets (preferably based on
C or C++ and/or perl) for client-side and server-side ?
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384
TLS_ECDHE_PSK_AES_256_CBC_SHA384

host5 --> SOCKS5-proxy tunnel --> host6 :
I will also have other local host(s) with private domains, for
example: host5.example3.org which will be available only inside a
LAN, (in another remote secondary location's LAN based computers).
This host5 server computer will have to be configured to forward
above mentioned (service) ports from that LAN side host5_IP, toward
the remote destination host6.example4.org, via using a SOCKS5-proxy
tunnel.  SOCKS5-proxy is running inside host5's loopback interface
127.0.0.1:1080

Mentioned in above, those secondary locations (where i'm providing
services) will only allow traffic from their host5 into internet via
their own SOCKS proxy. Its their policy.  And their SOCKS tunnel
ends in their primary location's SOCKS server, then traffic is
finally allowed to go out into Internet, toward my server
host6.example4.org.  I guess, they are using such SOCKS related
tools/server : dante (BSD/CMU) (server), SS5 (GPL), sSocks (MIT),
Srelay (BSD), etc.

DNSSEC & DANE : All of those mentioned internet hosts and all hosts
inside LAN, are using full DNSSEC supported local DNS-Server.  All
internet domain-names are fully DNSSEC signed,  and, each service's
server software's TLS/SSL cert's hash-code is also declared for
public's usage, via TLSA/DANE DNS record, (for each TLS supported port).

PKIX Certificates :
My own Root-CA cert --> Intermediate DomainName cert --> Server or
Service cert :
Root-CA is self-signed by me(server operator), then --> Intermediate
Cert, for each of these domain-names: example1.org, example2.org,
etc, then --> under each domain-name, i have created different
service related cert for each different service port (or created
cert for same server-host for same-service, running on multiple
host).  Server or service which is using TLS cert, such cert's hash
code is declared on related port via TLSA/DANE dns record.

QUESTION (2) : So how can i create port-forwarding tunnels using
GnuTLS, that can connect with and go through SOCKS v5 or v4A proxy ?
 If TLS cert will be used for encryption, and if such cert's hash
was added into TLSA DNS, then, How can i indicate to such tunnel to
check for TLSA/DANE and use DANE+DNSSEC authenticated connection ?
If gnutls itself do not have tools for such mentioned purposes, can
someone pls show/point-to very simple working code snipets
(preferably based on C or C++ and/or perl) for client-side and
server-side ?

QUESTION (3) : how to create those gnutls port-forwarding tunnels
inside chroot jail or LXC container ?
Which portion of command-line will vary ?

TAP to TAP : (or TUN to TUN, if SIP not implemented)

eth0 <-> \					/ <-> eth0
	host7 <-> gnutls encrypted link <-> host8
tap0 <-> /					\ <-> tap0

I have created virtual/tap network interface (Network Layer 2
virtual device) using other tools, not OpenVPN. For example:
eth0(host7) has 192.168.10.10, so i have assigned a different subnet
based IP 192.168.11.110 to tap0(host7). I do not need that tap's IP
be one from that LAN's subnet, for using the tap interface as a
Server IP.  I do not want computer's local/internal traffic reaching
all other computers in that LAN side, server-related traffic only
need to goto Server's IP.  I do not want to bridge eth0 and tap0
either, to prevent server-related traffic going/spreading into all
other computers in that LAN.  And, eth0(host8) has 192.168.10.11, so
i have assigned 192.168.11.111 to tap0(host8).  (At later stage,
eth0 & tap0 will be bridged so that all others in LAN-side can also
use the server behind virtual/tap interface).

QUESTION (4) : How to link two virtual/TAP network interface located
inside two different computers (in two different location), using a
GnuTLS based bi-directional encrypted tunnel ? (not asking for
bridged network interfaces)

Like this:
tap0(host7) <-> host7 <-> gnutls tunnel <-> internet/LAN <->
gnutls-tunnel <-> host8 <-> tap0(host8).

Expecting such behavior, for example: a DNS-client software/app will
send traffic toward tap0(host7)_IP:port53, such traffic will travel
encryptedly through gnutls tap tunnel and will be decrypted at the
other side of the tap-link to tap0(host8)_IP:port53 tap network
interface:port, and on that other side a DNS-Server software is
listening on tap0(host8)_IP:port53, will receive DNS query from DNS
client side, and then DNS-Server will send DNS query-result back to
DNS client on tap0(host7) side, via tap link.  And at the same time,
another server software is listening on a specific port of
tap0(host7)_IP interface side, and a client software from
tap0(host8) side will connect with server in tap0(host7) side, to
use server's service.

So i think: all incoming traffic coming/connecting on different
ports in tap(host7) network interface will have to be multiplexed
and then (gnutls) encrypted, and then send through (gnutls)
encryption based tunnel, and on the other side of the tunnel,
encrypted traffic will be decrypted, and then those incoming traffic
will be de-multiplexed toward the same as origin port and connected
with same port of tap0(host8) interface, and ready for delivery to a
listening app/software, if one is running.  Same process will happen
for incoming traffic of tap(host8) interface, traffic will travel to
other side same port of tap0(host7) interface, other side.

Please show me few COMMAND-LINES and usage scenario related to my
topology/design.

And if gnutls cannot perform mentioned tasks/steps/functions, then
please show/point me to such tools (free, GPL/MIT/BSD, etc licensed
based), which can perform such functions.

I hope i mentioned related all info, so that this message's
responder(s) can answer easily.  And, instead of a full IP-Address
with numbers, pls use just Host_IP or something similar in your
shown command-lines, i guess that will be enough for understanding.

When i will understand basics of it better, then i can & want to
fine-tune each tunnel based on port or protocol/service type. For
example, using DTLS based tunnel for DNS and DNSSEC based packets
for port 53.  Using TCP based TLS tunnel for HTTPS, SMPTS, IMAPS,
etc.  Using SRTP optimized/based TLS tunnel for SIP Voip, etc.

I have already done most of these functionality using various other
alternative tools, some of which i have mentioned, and some i have
not, because i'm looking for a viable solution based on GnuTLS.

Such should help many users to use GnuTLS based encrypted tunnel,
and not always depend on SSH (or VPN) etc tunnels.  GnuTLS available
by-default in (almost) all Linux and (almost doing nothing or) used
for (very) limited cases ! Why is that ?

Many many thanks in advance,
-- Bright Star.


References:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
http://www.gnutls.org/
https://en.wikipedia.org/wiki/GnuTLS
http://www.gnutls.org/manual/gnutls.html
https://en.wikipedia.org/wiki/SOCKS
http://ss5.sourceforge.net/
http://sourceforge.net/projects/ssocks/
http://sourceforge.net/projects/socks-relay/
http://backreference.org/2010/03/26/tuntap-interface-tutorial/
VTun (Tun/Tap) : http://vtun.sourceforge.net/
http://vtun.sourceforge.net/tun/index.html
http://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
http://virt.kernelnewbies.org/MacVTap
http://tuntaposx.sourceforge.net/
https://code.google.com/p/badvpn/wiki/tun2socks
http://support.microsoft.com/kb/839013
http://tinc-vpn.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x576C10EC.asc
Type: application/pgp-keys
Size: 4192 bytes
Desc: not available
URL: </pipermail/attachments/20131007/85fd2eb2/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131007/85fd2eb2/attachment.sig>

From n.mavrogiannopoulos at gmail.com  Sun Oct 13 17:23:41 2013
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 13 Oct 2013 17:23:41 +0200
Subject: [gnutls-help] Fwd: faq
In-Reply-To: <CAJU7zaJ=hMTxobTCubkzDmn6_7j2Q-LX5Z1qs4Lrn+bFUaZU4A@mail.gmail.com>
References: <CAJU7zaJ=hMTxobTCubkzDmn6_7j2Q-LX5Z1qs4Lrn+bFUaZU4A@mail.gmail.com>
Message-ID: <CAJU7za+kC5oTbaB6Qev5ZqwXbmCa=uSY-szxjdman_B8VCknxQ@mail.gmail.com>

I think this may be relevant here as well.


---------- Forwarded message ----------
From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com>
Date: Sun, Oct 13, 2013 at 5:12 PM
Subject: faq
To: GnuTLS development list <gnutls-devel at lists.gnutls.org>


Hello,
 I've added a small faq [0] with two questions that are being asked
over the years to client software developers that use gnutls. If you
are aware of other common questions or any comments on the answers,
let me know.

regards,
Nikos

[0]. http://www.gnutls.org/faq.html


From bry8star at yahoo.com  Mon Oct 14 08:26:42 2013
From: bry8star at yahoo.com (Bry8 Star)
Date: Sun, 13 Oct 2013 23:26:42 -0700
Subject: [gnutls-help] GnuTLS based AES tunnel, SOCKS 5/4A support, TAP, 2
Message-ID: <525B8EA2.4060909@yahoo.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,
How would i create GnuTLS based AES-encrypted port-forwarding
tunnels from Cmp1 to Cmp2 ?

Please first see/read the below four QUESTION sections/paragraphs
mentioned below.
For details you may read other paragraphs.

Cmp = Computer.
IP = IP-Address (ipv4).

Both/all side/hosts will use Linux, for example, Fedora (or other
distro), or Mac OS X.

Frontside --> GnuTLS tunnel --> Backend :
host1.example1.org -> GnuTLS tunnel -> host2.example2.org :
I want to create AES (256 bit) encrypted (port-forwarding) tunnel(s)
for following listening ports: 25 (SMTP), 53 (DNS), 80 (HTTP), 443
(HTTPS), 554 (RTSP), 587 (SUBMISSION), 993 (IMAPS), 5004 (RTP), 5005
(RTCP), 5060 (SIP), 5061 (SIPS), 5070, 6697 (IRC SSL), etc from
Cmp1's (host1.example1.org or it's Internet IP-Address), toward Cmp2
(host2.example2.org or it's Internet IP-Address), like shown in
above.  And then AGAIN traffic/packets will be forwarded toward the
Cmp2-side's 127.0.0.1 local loopback address.
So its also like this:
host1_IP -> gnutls tunnel -> host2_IP -> 127.0.0.1

Another, Frontside --> GnuTLS tunnel --> Backend :
host3.example1.org -> gnutls tunnel -> host4.example2.org :
Above mentioned system configuration will be applied on host3 and
host4, like shown in above line.
(host3_IP --> host4_IP).

host1 and host3 are used by users coming from internet side to
"example1.org". They do not know about host2 or host4 or about
"example2.org" (primary-backend).

host2, host4 : BackEnd Servers :
Actual server software will run from inside host2, and, host4.  The
example1.org domain-name's self-signed/own TLS cert's private-key
portion, (related to above mentioned ports and related network and
internet services), will reside/remain inside host2, and, host4
(primary-backend).  Services will run inside chroot jail or LXC
container inside host2 and host4.

BASICALLY, i'm using the host1 and host3 as traffic reflector (or as
front-side), and these are obtained from Hosting Service Provider
company(s).

And ultimate objective here is to keep my own self-signed various
certificate's and key's private/secret key portion (related to main
services) on my own server(s), which are host2 and host4 (primary
backend), i do not want to keep private/secret key on such remote
servers which may/can view/copy private/secret key portion.

Instead of using SSH tunnel (which uses openssl), i'm looking for a
solution based on GnuTLS based tunnel, because, it has such as these
extra features not available in openssl yet : DTLS, DANE/TLSA,
DNSSEC, etc. To me it seems, GnuTLS is able to do more/extra
authentications, so its more secured (against more attacks/exploits).

QUESTION (1) : So how can i create port-forwarding encrypted tunnel
(which is configured to support only: AES CBC/GCM, 256-bit, SHA512
MAC, TLS 1.2, etc) similar to SSH tunnel, by using GnuTLS, for
linking Computer1 with Computer2 ?  How to create related AES key
(PSK) or TLS certificate/cert/key (using GnuTLS) ?  If gnutls itself
do not have tools for such mentioned purposes, can someone pls
show/point-to very simple WORKING code snipets (preferably based on
C or C++ and/or perl) for client-side and server-side ?
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384
TLS_ECDHE_PSK_AES_256_CBC_SHA384

host5 --> SOCKS5-proxy tunnel --> host6 :
I will also have other local host(s) with private domains, for
example: host5.example3.org which will be available only inside a
LAN, (in another remote secondary location's LAN based computers).
This host5 server computer will have to be configured to forward
above mentioned (service) ports from that LAN side host5_IP, toward
the remote destination host6.example4.org, via using a SOCKS5-proxy
tunnel.  SOCKS5-proxy is running inside host5's loopback interface
127.0.0.1:1080

Mentioned in above, those secondary locations (where i'm providing
services) will only allow traffic from their host5 into internet via
their own SOCKS proxy. Its their policy.  And their SOCKS tunnel
ends in their primary location's SOCKS server, then traffic is
finally allowed to go out into Internet, toward my server
host6.example4.org.  I guess, they are using such SOCKS related
tools/server : dante (BSD/CMU) (server), SS5 (GPL), sSocks (MIT),
Srelay (BSD), etc.

DNSSEC & DANE : All of those mentioned internet hosts and all hosts
inside LAN, are using full DNSSEC supported local DNS-Server.  All
internet domain-names are fully DNSSEC signed,  and, each service's
server software's TLS/SSL cert's hash-code is also declared for
public's usage, via TLSA/DANE DNS record, (for each TLS supported port).

PKIX Certificates :
My own Root-CA cert --> Intermediate DomainName cert --> Server or
Service cert :
Root-CA is self-signed by me(server operator), then --> Intermediate
Cert, for each of these domain-names: example1.org, example2.org,
etc, then --> under each domain-name, i have created different
service related cert for each different service port (or created
cert for same server-host for same-service, running on multiple
host).  Server or service which is using TLS cert, such cert's hash
code is declared on related port via TLSA/DANE dns record.

QUESTION (2) : So how can i create port-forwarding tunnels using
GnuTLS, that can connect with and go through SOCKS v5 or v4A proxy ?
 If TLS cert will be used for encryption, and if such cert's hash
was added into TLSA DNS, then, How can i indicate to such tunnel to
check for TLSA/DANE and use DANE+DNSSEC authenticated connection ?
If gnutls itself do not have tools for such mentioned purposes, can
someone pls show/point-to very simple working code snipets
(preferably based on C or C++ and/or perl) for client-side and
server-side ?

QUESTION (3) : how to create those gnutls port-forwarding tunnels
inside chroot jail or LXC container ?
Which portion of command-line will vary ?

TAP to TAP : (or TUN to TUN, if SIP not implemented)

eth0 <-> \					/ <-> eth0
	host7 <-> gnutls encrypted link <-> host8
tap0 <-> /					\ <-> tap0

I have created virtual/tap network interface (Network Layer 2
virtual device) using other tools, not OpenVPN. For example:
eth0(host7) has 192.168.10.10, so i have assigned a different subnet
based IP 192.168.11.110 to tap0(host7). I do not need that tap's IP
be one from that LAN's subnet, for using the tap interface as a
Server IP.  I do not want computer's local/internal traffic reaching
all other computers in that LAN side, server-related traffic only
need to goto Server's IP.  I do not want to bridge eth0 and tap0
either, to prevent server-related traffic going/spreading into all
other computers in that LAN.  And, eth0(host8) has 192.168.10.11, so
i have assigned 192.168.11.111 to tap0(host8).  (At later stage,
eth0 & tap0 will be bridged so that all others in LAN-side can also
use the server behind virtual/tap interface).

QUESTION (4) : How to link two virtual/TAP network interface located
inside two different computers (in two different location), using a
GnuTLS based bi-directional encrypted tunnel ? (not asking for
bridged network interfaces)

Like this:
tap0(host7) <-> host7 <-> gnutls tunnel <-> internet/LAN <->
gnutls-tunnel <-> host8 <-> tap0(host8).

Expecting such behavior, for example: a DNS-client software/app will
send traffic toward tap0(host7)_IP:port53, such traffic will travel
encryptedly through gnutls tap tunnel and will be decrypted at the
other side of the tap-link to tap0(host8)_IP:port53 tap network
interface:port, and on that other side a DNS-Server software is
listening on tap0(host8)_IP:port53, will receive DNS query from DNS
client side, and then DNS-Server will send DNS query-result back to
DNS client on tap0(host7) side, via tap link.  And at the same time,
another server software is listening on a specific port of
tap0(host7)_IP interface side, and a client software from
tap0(host8) side will connect with server in tap0(host7) side, to
use server's service.

So i think: all incoming traffic coming/connecting on different
ports in tap(host7) network interface will have to be multiplexed
and then (gnutls) encrypted, and then send through (gnutls)
encryption based tunnel, and on the other side of the tunnel,
encrypted traffic will be decrypted, and then those incoming traffic
will be de-multiplexed toward the same as origin port and connected
with same port of tap0(host8) interface, and ready for delivery to a
listening app/software, if one is running.  Same process will happen
for incoming traffic of tap(host8) interface, traffic will travel to
other side same port of tap0(host7) interface, other side.

Please show me few COMMAND-LINES and usage scenario related to my
topology/design.

And if gnutls cannot perform mentioned tasks/steps/functions, then
please show/point me to such tools (free, GPL/MIT/BSD, etc licensed
based), which can perform such functions.

I hope i mentioned related all info, so that this message's
responder(s) can answer easily.  And, instead of a full IP-Address
with numbers, pls use just Host_IP or something similar in your
shown command-lines, i guess that will be enough for understanding.

When i will understand basics of it better, then i can & want to
fine-tune each tunnel based on port or protocol/service type. For
example, using DTLS based tunnel for DNS and DNSSEC based packets
for port 53.  Using TCP based TLS tunnel for HTTPS, SMPTS, IMAPS,
etc.  Using SRTP optimized/based TLS tunnel for SIP Voip, etc.

I have already done most of these functionality using various other
alternative tools, some of which i have mentioned, and some i have
not, because i'm looking for a viable solution based on GnuTLS.

Such should help many users to use GnuTLS based encrypted tunnel,
and not always depend on SSH (or VPN) etc tunnels.  GnuTLS available
by-default in (almost) all Linux and (almost doing nothing or) used
for (very) limited cases ! Why is that ?

Many many thanks in advance,
- -- Bright Star.


References:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
http://www.gnutls.org/
https://en.wikipedia.org/wiki/GnuTLS
http://www.gnutls.org/manual/gnutls.html
https://en.wikipedia.org/wiki/SOCKS
http://ss5.sourceforge.net/
http://sourceforge.net/projects/ssocks/
http://sourceforge.net/projects/socks-relay/
http://backreference.org/2010/03/26/tuntap-interface-tutorial/
VTun (Tun/Tap) : http://vtun.sourceforge.net/
http://vtun.sourceforge.net/tun/index.html
http://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
http://virt.kernelnewbies.org/MacVTap
http://tuntaposx.sourceforge.net/
https://code.google.com/p/badvpn/wiki/tun2socks
http://support.microsoft.com/kb/839013
http://tinc-vpn.org/

My pub PGP-Key:

- -----BEGIN PGP PUBLIC KEY BLOCK-----

mQMuBFBuiDgRCAC1rfewUls1ynwYSMroPqGPNbnK6CdeFpisP0N6ZT/tGrHEg/2o
IC0WBSOqSMp50gE4muIOm7cz4suHRmDhqaeyvOQqHP2/7cWSpzQRgt5x94KMtuDs
hXohCAPmZMQIxgSYQQ1iWZQ9LlxWESRgudMgr2v0IZFgN8a5mL0yPqvJp2Nl+hMj
obk5qiRjEvHR8MIOtt212PIOkgW1EUEVRBCaf65cuHmWwV3criC2aYnQjb88WejP
6UpGgH7KNL6aeM5wK+f/9FwCaXZGuX+pgeSjudDPqW+O5C/A4XUtMW+iUf3SgjzG
2b4pIjrQgrGzeuvpNqv3W4svfMiwFs2QvrWHAQDuP7GJM+052JUvPO7PPqoKSD2k
5dCtBtvC92VVr+8NSQgAoK0uajEvJQwCUrT7N4fpXDmEEEKFF62lIjGLJHzpg7l9
ZwxN+N2L8sMVIT93GBpn0nCFhdYVL1VkzZdJ+vjZEuhSrUj/ya2WO2fJagjZnd0X
Y/SEEsoexm3aMBZSPeLQU+aQ7Nq3JZQ4xPVdP5YHGMJgGPtfKMqUfQ8XaqvYzbT4
M4ZROK3g51a6ggziaBFWWc7gpNgWo8KKbzWo/0ucyIdQAPqexmU7fE9GMwO0MOPe
fIfIZgucnEPd/9VY8tvwcVLfXpsGLQdrkOpMTuTng0RX0iZKJ6aMIwGNLjekejVP
3fEVy4R9Y1xHG/gR3xOkjtzMCT4fsYjqzKuZTDXV2AgAlHGdlfNyn4XcxirYbVsV
kr6I0IwfOucrjFh93Of98rO3Q1PYroVqoym7ES62+U4gWOrbqDC3uJyZ7TWAzztS
De+Chc78HMkP4+5WpW/Uf8of9M35eHIzuJxYUvaMg9k4idLU8mLe693iRlt7ty1c
dhiESe4wa/fgNL7QU6POYeUlDl6bv1GZhnTjYpbQPaWOmgsgHL37WVpjitIHPmB3
SRoUZFxBP2/XJzVEi0Qxt4T7t9x9d7/Yc4Siymi9sdASYvCSnNyqFSLGe/9uZrEz
lcbyFOmIQ17XBtQ2BLduTkcARpM3td7JjAbmrXvFJntr8RN1SXIOSMiKNoTNQsBC
PbQgQnJpZ2h0IFN0YXIgPGJyeThzdGFyQHlhaG9vLmNvbT6IgwQTEQgAKwIbIwUJ
A8G7eAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlFWS74CGQEACgkQiDbbolds
EOxAYgEAgXIIGowFBnteQN2ATV+QC8aXiI31hi4nPZ/yBE7vXfYA/3QJjB87fzlr
7GqMyedZXXP/fEH34xtGtqLTF3CkstNriQIcBBMBAgAGBQJRfJxuAAoJEID2ikYf
WSP69mEP/1uYW29+0uUT/aB8Hyo39H6WZ6H8dDEnRO24jZW5Eoyp8m6mW3XrG6yn
hPfI/GiSuvVKy365P+aMHY5ERf3UOBdYaPYqGqzQGWl/uo8hxjP4VGFyL6BJGxnG
zulGjcy+WMYWQd5BvOL66Zia2vwAthsN3epY7HtvRzDQkYMtnYMKuEJo0Xa4Bf/v
dOSAt92fAo08ptwgaFZhK0ZWqpyE8fP70bVpeLKEt4512UipcuWd2mt9NPwmo+I3
giaCj5690VmwF8zKfPHXLFlKKHccNNcm6p+G1QCSa990jAHzprlaTIdtlHdCubzq
A6aQalIIE+qh5y4n01sI7M0RbVhoZif7LOlVpEZN0kaeXWybd24jB8tgHta79Zx9
mlHwtsHqPSXkE7kYveeP//6xOMyiiB0RYcteL6+GWpmVeULciI853R7m3pY9XuWW
1WX3X3nDb/UpUo1Y8R6nJ7dOLRZuhojxGh3X4hm860a8YxTP1dNN2EVmF8uMz73q
pVKIj3v6QMVhKIbWc30L0ZyQjgxqeDCNP/g2pfTMWPUlGLMp/1fcZHi/e/mpWVXh
M0vPCUZW1sE8BrBXQbxbJC04h1Jv3ke3RUnN1csfs4jLlFQ/tp/IhVtHxEBpZtDc
X/YbSZrmcw2Ed/BGljD0E6PJC8jhOWpiETEZXQLF72p1hJu1t5B3tCBCcmlnaHQg
U3RhciA8YnJ5OHN0YXJAZ21haWwuY29tPoiABBMRCAAoBQJRVks0AhsjBQkDwbt4
BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCINtuiV2wQ7CeCAQDKQ/aLmp//
eca5ps7xVEGIkq2m42m9bT8EMFvKFRECmgEA2m3W8oKMLextBe6Xw1WKfpgxJZjX
ob1YRRzujlDgmKSJAhwEEwECAAYFAlF8nG4ACgkQgPaKRh9ZI/qEcA/+JsLrQtfJ
lFF3ZMXHUd6a8JzXuAJMK4kDPxS/4sCm2oFAzzUopX8odsvdRvGtaquaTs6rEJEo
+7dh+RYn/JgJqd8llXlb1zQ9DyhcMSfqYFR0cC3V3GkU4cLhUvREv2zT3qOoOdhp
SXljhXqUkXgEHxfQtQ/xZig1FXEiqgn+7YNOHEnfE8DCVOOTwGWXCVel5TDZ0e3x
QllOywAsZ+6t4CM4OsZYIPrYBQ6KcO7X1NVzD7owYpLcBcFTAIhe1tgEFPsomF0k
GCGIerQnl7LF0boDRZMn/aY7zfPWuHEPPN92hVFfpC96GP7jHw7DDX9WikACIU2a
B3Muk5+GsuJWNUVD9j2DaUePRXENfuHq/5wOCQAmm3iLuchywPvERuY2HKwSkvii
eRbNfUMM45z+6uN7mCcrslB7tFikeFTyzU7FTLSfjItAy3525LltF6HU45bAIDub
UOjVP6C1QenmWJiS4D4/UKMcavUcfWegfW/3Tu9mLn5RPJT31kduOr43IcOHmpEk
W8Gjnd/qkELE0VV6qdPBJv1AZZtDv/zCzSPcbeurFRqdSh94GptOy/tGWondQdYy
AF9L1ih4qkPB+XIRqzskr4F/QWZlHGE5vKKPuEtiSSIqZVGCexr+oA3HsDLfjmE1
ygX/BcFId23rdhis5RrGfiflfsFzklDDlmO0JEJyaWdodCBTdGFyIDxicnk4c3Rh
ckBpbnZlbnRhdGkub3JnPoiABBMRCAAoBQJRfJ0GAhsjBQkDwbt4BgsJCAcDAgYV
CAIJCgsEFgIDAQIeAQIXgAAKCRCINtuiV2wQ7OqQAP0X6DDHwgmLZrkwurohtg5b
eZkjAkdXn/UjEhcSxJA9LAEA2BNUTFX/qhRW25bbQUhOr+5V7njvVOYm83qOtFsj
GNi5Ag0EUG6IOBAIAM96hYWIwIpBeQ/6NGzTOPYvMUde8Y3wwBLhWg4fmsGkpKwy
ZQT77EGv3m4wD35Byj5RZ1dB7AmsUe8dDyhkjPyzXGZW5Xt09/Fe5v3wpWCsCqwz
n88xgZX1XzYbhHgU4hj/HzZSMNUMYzr/nH3z995ecTGYU5S7Mqa0RKWOxQbo3nUy
/S1Vl9AjKDFBhdexH+d4ZJSfbADC58A9OodIGnz7AN8NmG153cbK/yg/Ob6DAqQE
FLzWF6TaLa4BBbPW/MoapRKgA/Ls1/aWTi0yPBQJkq6NAm9xHL0ZlHQXCw2x95Y0
9P01nLVxHUCnb9Hdsm4+Cas46riBDa6NfoGxTOcAAwUIAJ/N0crFf/Df6ArQ9/Qm
Ki9B0LPwvGfF7l7ityxW/LO6EPx0G4vFmhcR1wR75Jr4lR3tk+tubCNvL4hPJLMg
GLyZf1LpiNbSyPtbwb+ewAsiNgi1yDXmPWEOyMLRua6BTqJlOa+n0XtWyDCxnfGf
ytDbN56954UC1JqLhxuu7B1EKfKedlYZOt1ZU5lma1J08WleAEhTJIjuor4KqX0T
KluX0QApS36SB3cJSxh9uZ/gVcfWiLSII4KxVsvnTSgvQ5ed87k/z8neWDswyNMR
lSS1eDalvT6SsIsQ3Vw6GdJa1O4JKx13KjTvWilRH48/cC13YeldnaQJONZCqgJW
8GKIZwQYEQgADwUCUG6IOAIbDAUJA8G7eAAKCRCINtuiV2wQ7A+HAP94o2galwpb
85ptdDa2TYxPAKfJihPGzrUx6MGDJ6vDlAD+PAs2Ylb24EEmP8juhfmDzICV2G94
YKBOGQaTY+WFPo0=
=WaWd
- -----END PGP PUBLIC KEY BLOCK-----

Fingerprint: 12B7 7F2C 92BF 25C8 38C6 4D9C 8836 DBA2 576C 10EC.
My Key ID: 0x576C10EC.

-----BEGIN PGP SIGNATURE-----

iF4EAREKAAYFAlJbjqEACgkQiDbboldsEOyowwD+L6pqa75Esp8kPBwjC7sNihKS
Cu/Evbl5gCGB6umBJtgA/Auofx85URuSM/bnwb5INTZCPvkqoawcCdg5xFHvvd61
=X+fc
-----END PGP SIGNATURE-----


From jonathan.roudiere at gmail.com  Mon Oct 14 11:23:15 2013
From: jonathan.roudiere at gmail.com (Jonathan Roudiere)
Date: Mon, 14 Oct 2013 11:23:15 +0200
Subject: [gnutls-help] gnutls_error_is_fatal() return value
Message-ID: <CAD5bOtzk2Uf-pAQVDGnfAHG0K+M01LxJpWKhR89gQwoGk+nXoA@mail.gmail.com>

Hello,

Help says that the gnutls_error_is_fatal() function returns -1 for
unknown error value but code doesn't seem to do that.

Is the code shouldn't be modified like in the following patch ?

diff --git a/lib/gnutls_errors.c b/lib/gnutls_errors.c
index 7dd6499..77b4b71 100644
--- a/lib/gnutls_errors.c
+++ b/lib/gnutls_errors.c
@@ -345,7 +345,7 @@ static const gnutls_error_entry error_algorithms[] = {
 int
 gnutls_error_is_fatal (int error)
 {
-  int ret = 1;
+  int ret = -1;
   const gnutls_error_entry *p;

   /* Input sanitzation.  Positive values are not errors at all, and

Thanks,
Joe


From jmiscaro at gmail.com  Wed Oct 16 17:02:37 2013
From: jmiscaro at gmail.com (Juan Miscaro)
Date: Wed, 16 Oct 2013 11:02:37 -0400
Subject: [gnutls-help] Generating multi-layer certificates
Message-ID: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>

Hello.  Would someone be so kind as to provide assistance in generating
multi-layer certificates?  I am doing some research and would like to
generate a self-signed CA, a few intermediate certificates, and then a
server certificate.  Most of what I've seen on the internet has to do with
the openssl command but I want to use the certtool command.  Thanks for any
help in this important matter.

-- 
/jm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20131016/9c365ff0/attachment.html>

From dkg at fifthhorseman.net  Wed Oct 16 19:00:23 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Oct 2013 13:00:23 -0400
Subject: [gnutls-help] Generating multi-layer certificates
In-Reply-To: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>
References: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>
Message-ID: <525EC627.7030108@fifthhorseman.net>

On 10/16/2013 11:02 AM, Juan Miscaro wrote:
> Hello.  Would someone be so kind as to provide assistance in generating
> multi-layer certificates?  I am doing some research and would like to
> generate a self-signed CA, a few intermediate certificates, and then a
> server certificate.  Most of what I've seen on the internet has to do with
> the openssl command but I want to use the certtool command.  Thanks for any
> help in this important matter.

If you're controlling all the keys, you don't need to bother with CSRs,
and can just make the certificates directly.

You can generate a secret key with:

 certtool --generate-privkey

This will print the PEM-encoded key to stdout, so redirect that to the
file you want to create.

for example:

 certtool --generate-privkey > root-ca.key
 certtool --generate-privkey > intermediate-ca.key
 certtool --generate-privkey > end-entity.key

extract the public keys from the intermediate and the EE and set them aside:

 certtool --load-privkey intermediate-ca.key \
    --pubkey-info > intermediate-ca.pubkey
 certtool --load-privkey end-entity.key \
    --pubkey-info > end-entity.pubkey

For the root CA, you want to create a self-signed cert:

 certtool --load-privkey=root-ca.key --generate-self-signed >root-ca.pem

You will be prompted to answer some questions.  feel free to leave the
irrelevant ones blank, or choose the defaults.  Make sure you answer "y"
to "Does the certificate belong to an authority?" and "Will the
certificate be used to sign other certificates?"

To create the certificate for the intermediate CA, you want to want to
issue it with the root CA's key:

 certtool --load-ca-privkey=root-ca.key \
   --load-ca-certificate=root-ca.pem \
   --load-pubkey=intermediate-ca.pubkey \
   > intermediate-ca.pem

You will also be prompted to answer some questions here.

Now you can create the end entity's certificate, using the intermediate
CA's key:

 certtool --load-ca-privkey=intermediate-ca.key \
   --load-ca-certificate=intermediate-ca.pem \
   --load-pubkey=end-entity.pubkey \
   > end-entity.pem

answer the questions appropriate for the end-entity. in particular, you
probably want the Common Name to be the server's canonical name (e.g.
"example.com", without the quotes), and you want to enter a "dnsName"
for each and every name the server is addressed by, including the
canonical name (e.g. "example.com" and then when prompted again,
"www.example.com" -- you can keep adding subjectAltNames like this until
you enter a blank name, and then the prompting will continue).

If you want to automate much of this, or you don't want to deal with the
prompting, you can supply a template file to any of these commands with
--template=FILENAME.  Check out the example template file in
/usr/share/doc/gnutls-bin/examples/certtool.cfg (or wherever your
distribution places it) to see the structure and format of the file.

hth,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131016/5d96e578/attachment.sig>

From jmiscaro at gmail.com  Wed Oct 16 21:05:04 2013
From: jmiscaro at gmail.com (Juan Miscaro)
Date: Wed, 16 Oct 2013 15:05:04 -0400
Subject: [gnutls-help] Generating multi-layer certificates
In-Reply-To: <525EC627.7030108@fifthhorseman.net>
References: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>
 <525EC627.7030108@fifthhorseman.net>
Message-ID: <CADEbCm+f3w_6rrrFiUcQU3g4KQdrju0GmgsRXZxToTuthbj9gg@mail.gmail.com>

>
>
> extract the public keys from the intermediate and the EE and set them
> aside:
>
>  certtool --load-privkey intermediate-ca.key \
>     --pubkey-info > intermediate-ca.pubkey
>  certtool --load-privkey end-entity.key \
>     --pubkey-info > end-entity.pubkey
>
>
Thank you sir but I don't see the --pubkey-info option in the certtool man
page.

-- 
/jm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20131016/57be8dbd/attachment.html>

From dkg at fifthhorseman.net  Wed Oct 16 22:25:21 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Oct 2013 16:25:21 -0400
Subject: [gnutls-help] Generating multi-layer certificates
In-Reply-To: <CADEbCm+f3w_6rrrFiUcQU3g4KQdrju0GmgsRXZxToTuthbj9gg@mail.gmail.com>
References: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>
 <525EC627.7030108@fifthhorseman.net>
 <CADEbCm+f3w_6rrrFiUcQU3g4KQdrju0GmgsRXZxToTuthbj9gg@mail.gmail.com>
Message-ID: <525EF631.7000102@fifthhorseman.net>

On 10/16/2013 03:05 PM, Juan Miscaro wrote:

>> extract the public keys from the intermediate and the EE and set them
>> aside:
>>
>>  certtool --load-privkey intermediate-ca.key \
>>     --pubkey-info > intermediate-ca.pubkey
>>  certtool --load-privkey end-entity.key \
>>     --pubkey-info > end-entity.pubkey
>>
>>
> Thank you sir but I don't see the --pubkey-info option in the certtool man
> page.

what version of gnutls are you using?  you can find the answer with
"certtool --version"

the above examples were tested with 3.2.4.

Regards,

	--dkg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131016/078f0523/attachment.sig>

From jmiscaro at gmail.com  Wed Oct 16 23:49:48 2013
From: jmiscaro at gmail.com (Juan Miscaro)
Date: Wed, 16 Oct 2013 17:49:48 -0400
Subject: [gnutls-help] Generating multi-layer certificates
In-Reply-To: <525EF631.7000102@fifthhorseman.net>
References: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>
 <525EC627.7030108@fifthhorseman.net>
 <CADEbCm+f3w_6rrrFiUcQU3g4KQdrju0GmgsRXZxToTuthbj9gg@mail.gmail.com>
 <525EF631.7000102@fifthhorseman.net>
Message-ID: <CADEbCmKhrThr2dRJOXLpARBkdkLCjYdN_26C_QVBzMjkFTouuw@mail.gmail.com>

On 16 October 2013 16:25, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> On 10/16/2013 03:05 PM, Juan Miscaro wrote:
>
>
> > Thank you sir but I don't see the --pubkey-info option in the certtool
> man
> > page.
>
> what version of gnutls are you using?  you can find the answer with
> "certtool --version"
>
> the above examples were tested with 3.2.4.
>
>
My Debian research system has but only 2.12.14.  I have access to a more
modern chassis but it still has only 2.12.23 .


-- 
/jm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20131016/da4b9577/attachment.html>

From joaotavora at gmail.com  Thu Oct 17 17:30:09 2013
From: joaotavora at gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=)
Date: Thu, 17 Oct 2013 16:30:09 +0100
Subject: [gnutls-help] "Error in the push function" using gnutls >= 3.2.1-w32
Message-ID: <jjbk3hb3ofy.fsf@gmail.com>

   [I'm sorry for any crossposting, I also sent this to bugs at gnutls.org
    but this might be just some support issue]

Hi,

I'm on Microsoft Windows XP. Using gnutls 3.1.8-w32, I get in some
servers, but not others:

   $ ./gnutls-cli -p 443 siscog.campfirenow.com
   Processed 154 CA certificate(s).
   Resolving 'siscog.campfirenow.com'...
   Connecting to '204.62.114.183:443'...
   *** Fatal error: An illegal TLS extension was received.
   *** Handshake has failed
   GnuTLS error: An illegal TLS extension was received.

I had to switch to gnutls >= 3.2.1 since it is the first one supporting
the ECC cypher, which appears to be TLS extension required by this
server (but not by github.com, apparently). However I get an even
weirder error:

   $ ./gnutls-cli -p 443 siscog.campfirenow.com
   Processed 154 CA certificate(s).
   Resolving 'siscog.campfirenow.com'...
   Connecting to '204.62.114.183:443'...
   *** Fatal error: Error in the push function.
   *** Handshake has failed
   GnuTLS error: Error in the push function.

This bit of detail might be interesting, I haven't dug into the source:

   *** Fatal error: Error in the push function.
   |<4>| REC: Sending Alert[2|80] - Internal error
   |<7>| WRITE FLUSH: 233 bytes in buffer.
   |<2>| errno: 5
   |<2>| ASSERT: gnutls_buffers.c:171
   |<7>| WRITE error: code -53, 233 bytes left.
   |<2>| ASSERT: gnutls_buffers.c:644
   |<2>| ASSERT: gnutls_record.c:573
   *** Handshake has failed

If you're curious, I originally discovered this using gnutls embedded in
Emacs, but apparently it's reproducible using gnutls-cli. Also FWIW, w32
version of curl and openssl work.

Thanks,
Jo?o



From dkg at fifthhorseman.net  Thu Oct 17 20:15:20 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 17 Oct 2013 14:15:20 -0400
Subject: [gnutls-help] "Error in the push function" using gnutls >=
	3.2.1-w32
In-Reply-To: <jjbk3hb3ofy.fsf@gmail.com>
References: <jjbk3hb3ofy.fsf@gmail.com>
Message-ID: <87r4bjg3wn.fsf@alice.fifthhorseman.net>

On Thu 2013-10-17 11:30:09 -0400, Jo?o T?vora <joaotavora at gmail.com> wrote:
> I'm on Microsoft Windows XP. Using gnutls 3.1.8-w32, I get in some
> servers, but not others:
>
>    $ ./gnutls-cli -p 443 siscog.campfirenow.com


trying with this server using gnutls 3.2.4 on debian:

0 dkg at alice:~$ gnutls-cli --debug 9999 siscog.campfirenow.com
[...]
|<3>| HSK[0xf5fec0]: SERVER HELLO (2) was received. Length 95[95], frag offset 0, frag length: 95, sequence: 0
|<3>| HSK[0xf5fec0]: Server's version: 3.3
|<3>| HSK[0xf5fec0]: SessionID length: 32
|<3>| HSK[0xf5fec0]: SessionID: 8380f0fd7f664bef694585d3a5ecab256a5b10adf2fa3206c684832c88d20371
|<3>| HSK[0xf5fec0]: Selected cipher suite: ECDHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0xf5fec0]: Selected compression method: NULL (0)
|<3>| EXT[0xf5fec0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
|<3>| EXT[0xf5fec0]: Parsing extension 'SERVER NAME/0' (0 bytes)
|<3>| EXT[0xf5fec0]: Parsing extension 'SUPPORTED ECC/10' (4 bytes)
|<2>| ASSERT: ecc.c:95
|<2>| ASSERT: gnutls_extensions.c:207
|<2>| ASSERT: gnutls_handshake.c:1801
|<2>| ASSERT: gnutls_handshake.c:2225
|<2>| ASSERT: gnutls_handshake.c:1442
|<2>| ASSERT: gnutls_handshake.c:2701
*** Fatal error: An illegal TLS extension was received.
|<4>| REC: Sending Alert[2|110] - An unsupported extension was sent
|<4>| REC[0xf5fec0]: Preparing Packet Alert(21) with length: 2 and target length: 2
|<9>| ENC[0xf5fec0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes.
|<7>| WRITE FLUSH: 7 bytes in buffer.
|<7>| WRITE: wrote 7 bytes, 0 bytes left.
|<4>| REC[0xf5fec0]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
*** Handshake has failed
GnuTLS error: An illegal TLS extension was received.
|<4>| REC[0xf5fec0]: Start of epoch cleanup
|<4>| REC[0xf5fec0]: End of epoch cleanup
|<4>| REC[0xf5fec0]: Epoch #0 freed
|<4>| REC[0xf5fec0]: Epoch #1 freed
1 dkg at alice:~$

So the server is sending the "Supported Elliptic Curves" extension,
which should only be sent by the client:

  https://tools.ietf.org/html/rfc4492#section-5.1

lib/ext/ecc.c:95  shows the assertion:

0 dkg at alice:~/src/gnutls/gnutls$ cat -n lib/ext/ecc.c | head -n 100 | tail -n 26
    75	/* 
    76	 * In case of a server: if a SUPPORTED_ECC extension type is received then it stores
    77	 * into the session security parameters the new value. The server may use gnutls_session_certificate_type_get(),
    78	 * to access it.
    79	 *
    80	 * In case of a client: If a supported_eccs have been specified then we send the extension.
    81	 *
    82	 */
    83	static int
    84	_gnutls_supported_ecc_recv_params (gnutls_session_t session,
    85	                               const uint8_t * data, size_t _data_size)
    86	{
    87	  int new_type = -1, ret, i;
    88	  ssize_t data_size = _data_size;
    89	  uint16_t len;
    90	  const uint8_t* p = data;
    91	
    92	  if (session->security_parameters.entity == GNUTLS_CLIENT)
    93	    {
    94	      /* A client shouldn't receive this extension */
    95	      return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_EXTENSION);
    96	    }
    97	  else
    98	    { /* SERVER SIDE - we must check if the sent supported ecc type is the right one 
    99	       */
   100	      if (data_size < 2)
0 dkg at alice:~/src/gnutls/gnutls$ 

Maybe GnuTLS should be more permissive here, and just ignore this
extension (maybe emitting a warning) if it comes from the server?


> I had to switch to gnutls >= 3.2.1 since it is the first one supporting
> the ECC cypher, which appears to be TLS extension required by this
> server (but not by github.com, apparently). However I get an even
> weirder error:

This shouldn't be necessary; testing from another machine, i was able to
connect with gnutls-cli from version 2.12.20, which doesn't support ECC
at all, and i was also able to connect with a priority string that
disables all ECC, which apparently means the buggy server won't try to
send the extension it wasn't supposed to send in the first place:

 gnutls --priority NORMAL:-CURVE-ALL siscog.campfirenow.com



hth,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: </pipermail/attachments/20131017/c80c64ef/attachment.sig>

From jmiscaro at gmail.com  Fri Oct 18 00:22:40 2013
From: jmiscaro at gmail.com (Juan Miscaro)
Date: Thu, 17 Oct 2013 18:22:40 -0400
Subject: [gnutls-help] Generating multi-layer certificates
In-Reply-To: <CADEbCmKhrThr2dRJOXLpARBkdkLCjYdN_26C_QVBzMjkFTouuw@mail.gmail.com>
References: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>
 <525EC627.7030108@fifthhorseman.net>
 <CADEbCm+f3w_6rrrFiUcQU3g4KQdrju0GmgsRXZxToTuthbj9gg@mail.gmail.com>
 <525EF631.7000102@fifthhorseman.net>
 <CADEbCmKhrThr2dRJOXLpARBkdkLCjYdN_26C_QVBzMjkFTouuw@mail.gmail.com>
Message-ID: <CADEbCmJ-VHTdZDwOi+SRqNV5mFi9Czn+HAzzcMGPwxWXjQhFVg@mail.gmail.com>

On 16 October 2013 17:49, Juan Miscaro <jmiscaro at gmail.com> wrote:

>
>
>
> On 16 October 2013 16:25, Daniel Kahn Gillmor <dkg at fifthhorseman.net>wrote:
>
>> On 10/16/2013 03:05 PM, Juan Miscaro wrote:
>>
>>
>> > Thank you sir but I don't see the --pubkey-info option in the certtool
>> man
>> > page.
>>
>> what version of gnutls are you using?  you can find the answer with
>> "certtool --version"
>>
>> the above examples were tested with 3.2.4.
>>
>>
> My Debian research system has but only 2.12.14.  I have access to a more
> modern chassis but it still has only 2.12.23 .
>
>
>
Am I a goner?  It seems there must be a way to do what I want without
installing Gentoo or whatever?

-- 
/jm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20131017/68a3b715/attachment.html>

From dkg at fifthhorseman.net  Fri Oct 18 01:27:11 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 17 Oct 2013 19:27:11 -0400
Subject: [gnutls-help] Generating multi-layer certificates
In-Reply-To: <525EC627.7030108@fifthhorseman.net>
References: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>
 <525EC627.7030108@fifthhorseman.net>
Message-ID: <5260724F.8000304@fifthhorseman.net>

On 10/16/2013 01:00 PM, Daniel Kahn Gillmor wrote:
>  certtool --load-ca-privkey=root-ca.key \
>    --load-ca-certificate=root-ca.pem \
>    --load-pubkey=intermediate-ca.pubkey \
>    > intermediate-ca.pem
> 
> You will also be prompted to answer some questions here.
> 
> Now you can create the end entity's certificate, using the intermediate
> CA's key:
> 
>  certtool --load-ca-privkey=intermediate-ca.key \
>    --load-ca-certificate=intermediate-ca.pem \
>    --load-pubkey=end-entity.pubkey \
>    > end-entity.pem

Sigh.  The above two commands both are missing the relevant action
argument, which is --generate-certificate.  i'm not sure how i missed
that :)

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131017/6b21b12b/attachment.sig>

From dkg at fifthhorseman.net  Fri Oct 18 01:30:02 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 17 Oct 2013 19:30:02 -0400
Subject: [gnutls-help] Generating multi-layer certificates
In-Reply-To: <CADEbCmKhrThr2dRJOXLpARBkdkLCjYdN_26C_QVBzMjkFTouuw@mail.gmail.com>
References: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>
 <525EC627.7030108@fifthhorseman.net>
 <CADEbCm+f3w_6rrrFiUcQU3g4KQdrju0GmgsRXZxToTuthbj9gg@mail.gmail.com>
 <525EF631.7000102@fifthhorseman.net>
 <CADEbCmKhrThr2dRJOXLpARBkdkLCjYdN_26C_QVBzMjkFTouuw@mail.gmail.com>
Message-ID: <526072FA.3040503@fifthhorseman.net>

On 10/16/2013 05:49 PM, Juan Miscaro wrote:
> On 16 October 2013 16:25, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
>> On 10/16/2013 03:05 PM, Juan Miscaro wrote:
>>
>>
>>> Thank you sir but I don't see the --pubkey-info option in the certtool
>> man
>>> page.
>>
>> what version of gnutls are you using?  you can find the answer with
>> "certtool --version"
>>
>> the above examples were tested with 3.2.4.
>>
>>
> My Debian research system has but only 2.12.14.  I have access to a more
> modern chassis but it still has only 2.12.23 .

if you're using a version from the 2.12 branch, then you'll want to
create certificate requests for the intermediate ca and the end entity
instead of explicitly extracting their public keys.   you can do this
with (for example, you can sort out the other options:

 certtool --load-privkey intermediate-ca.key \
   --generate-request > intermediate-ca.crq

and answer the various questions.

then, when doing the --generate-certificate command to make the
intermediate CA's cert, instead of:

 --load-pubkey intermediate-ca.pubkey

you should use:

 --load-request intermediate-ca.crq

follow the same pattern for the end entity.

make sense?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131017/2e6e2915/attachment.sig>

From jmiscaro at gmail.com  Sat Oct 19 16:55:33 2013
From: jmiscaro at gmail.com (Juan Miscaro)
Date: Sat, 19 Oct 2013 10:55:33 -0400
Subject: [gnutls-help] Generating multi-layer certificates
In-Reply-To: <526072FA.3040503@fifthhorseman.net>
References: <CADEbCmJAUsvfy7iAet9KqFTsw4vDpkKTv2wTcykesThKRLB-Hw@mail.gmail.com>
 <525EC627.7030108@fifthhorseman.net>
 <CADEbCm+f3w_6rrrFiUcQU3g4KQdrju0GmgsRXZxToTuthbj9gg@mail.gmail.com>
 <525EF631.7000102@fifthhorseman.net>
 <CADEbCmKhrThr2dRJOXLpARBkdkLCjYdN_26C_QVBzMjkFTouuw@mail.gmail.com>
 <526072FA.3040503@fifthhorseman.net>
Message-ID: <CADEbCmLKNnwd_r_S6FNeUdKEhxYoh7JeunzzXkZ0_Rwyd8SBNA@mail.gmail.com>

On 17 October 2013 19:30, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> On 10/16/2013 05:49 PM, Juan Miscaro wrote:
> > On 16 October 2013 16:25, Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> wrote:
> >
> >> On 10/16/2013 03:05 PM, Juan Miscaro wrote:
> >>
> >>
> >>> Thank you sir but I don't see the --pubkey-info option in the certtool
> >> man
> >>> page.
> >>
> >> what version of gnutls are you using?  you can find the answer with
> >> "certtool --version"
> >>
> >> the above examples were tested with 3.2.4.
> >>
> >>
> > My Debian research system has but only 2.12.14.  I have access to a more
> > modern chassis but it still has only 2.12.23 .
>
> if you're using a version from the 2.12 branch, then you'll want to
> create certificate requests for the intermediate ca and the end entity
> instead of explicitly extracting their public keys.   you can do this
> with (for example, you can sort out the other options:
>
>  certtool --load-privkey intermediate-ca.key \
>    --generate-request > intermediate-ca.crq
>
> and answer the various questions.
>
> then, when doing the --generate-certificate command to make the
> intermediate CA's cert, instead of:
>
>  --load-pubkey intermediate-ca.pubkey
>
> you should use:
>
>  --load-request intermediate-ca.crq
>
> follow the same pattern for the end entity.
>
> make sense?
>

Indeed it does!  Thank you for your time.

God bless,

-- 
/jm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20131019/c73ed866/attachment-0001.html>

From nmav at gnutls.org  Mon Oct 21 12:54:58 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 21 Oct 2013 12:54:58 +0200
Subject: [gnutls-help] gnutls_error_is_fatal() return value
In-Reply-To: <CAD5bOtzk2Uf-pAQVDGnfAHG0K+M01LxJpWKhR89gQwoGk+nXoA@mail.gmail.com>
References: <CAD5bOtzk2Uf-pAQVDGnfAHG0K+M01LxJpWKhR89gQwoGk+nXoA@mail.gmail.com>
Message-ID: <52650802.8060002@gnutls.org>

On 10/14/2013 11:23 AM, Jonathan Roudiere wrote:
> Hello,
> 
> Help says that the gnutls_error_is_fatal() function returns -1 for
> unknown error value but code doesn't seem to do that.
> 
> Is the code shouldn't be modified like in the following patch ?

Helo Jonathan,
 I am wondering that since this issue exists for several years, does it
make sense to fix it? Shouldn't we fix instead the documentation, or do
you need that functionality?

regards,
Nikos




From nmav at gnutls.org  Mon Oct 21 20:19:01 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 21 Oct 2013 20:19:01 +0200
Subject: [gnutls-help] "Error in the push function" using gnutls >=
	3.2.1-w32
In-Reply-To: <87r4bjg3wn.fsf@alice.fifthhorseman.net>
References: <jjbk3hb3ofy.fsf@gmail.com>
 <87r4bjg3wn.fsf@alice.fifthhorseman.net>
Message-ID: <52657015.3070209@gnutls.org>

On 10/17/2013 08:15 PM, Daniel Kahn Gillmor wrote:
> On Thu 2013-10-17 11:30:09 -0400, Jo?o T?vora <joaotavora at gmail.com> wrote:
>> I'm on Microsoft Windows XP. Using gnutls 3.1.8-w32, I get in some
>> servers, but not others:
>>
>>    $ ./gnutls-cli -p 443 siscog.campfirenow.com
> 
> 
> trying with this server using gnutls 3.2.4 on debian:
[...]
> Maybe GnuTLS should be more permissive here, and just ignore this
> extension (maybe emitting a warning) if it comes from the server?

That looks pretty dangerous. The protocol is strict on that. Is that
some experimental server?

regards,
Nikos


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131021/ea22317f/attachment.sig>

From nmav at gnutls.org  Wed Oct 23 13:24:40 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 23 Oct 2013 13:24:40 +0200
Subject: [gnutls-help] gnutls 3.1.15
Message-ID: <5267B1F8.1070603@gnutls.org>

Hello,
 I've just released gnutls 3.1.15. This is a bug-fix release on the
 current stable branch.
* Version 3.1.15 (released 2013-10-23)

** srptool: Fixed index command line option. Patch by Attila Molnar.

** certtool: pathlen constraint is now read correctly. Reported by
Christoph Seitz.

** libdane: Added interfaces to allow initialization of dane_query_t from
external DNS resolutions, and to allow direct verification of a certificate
chain against a dane_query_t. Contributed by Christian Grothoff.

** libdane: Fixed a buffer overflow in dane_query_tlsa(). This could be
triggered by a DNS server supplying more than 4 DANE records. Report and
fix by Christian Grothoff.

** API and ABI modifications:
dane_verify_crt_raw: Added
dane_raw_tlsa: 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.1/gnutls-3.1.15.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.15.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.15.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.15.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 nmav at gnutls.org  Wed Oct 23 13:33:20 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 23 Oct 2013 13:33:20 +0200
Subject: [gnutls-help] gnutls 3.2.5
Message-ID: <5267B400.2080609@gnutls.org>

Hello,
 I've just released gnutls 3.2.5. This is a bug-fix release on the
next stable branch.

* Version 3.2.5 (released 2013-10-23)

** libgnutls: Documentation and build-time fixes.

** libgnutls: Allow the generation of DH groups of less than 700 bits.

** libgnutls: Added several combinations of ciphersuites with SHA256 and
SHA384 as MAC, as well as Camellia with GCM.

** libdane: Added interfaces to allow initialization of dane_query_t
from external DNS resolutions, and to allow direct verification of a
certificate chain against a dane_query_t. Contributed by Christian Grothoff.

** libdane: Fixed a buffer overflow in dane_query_tlsa(). This could be
triggered by a DNS server supplying more than 4 DANE records. Report and
fix by Christian Grothoff.

** srptool: Fixed index command line option. Patch by Attila Molnar.

** gnutls-cli: Added support for inline commands, using the
--inline-commands-prefix and --inline-commands options. Patch by Raj Raman.	

** certtool: pathlen constraint is now read correctly. Reported by
Christoph Seitz.

** API and ABI modifications:
gnutls_certificate_get_crt_raw: Added
dane_verify_crt_raw: Added
dane_raw_tlsa: 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.2/gnutls-3.2.5.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.5.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.5.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.5.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 tobias-lists at 23.gs  Fri Oct 25 16:43:18 2013
From: tobias-lists at 23.gs (Tobias Gruetzmacher)
Date: Fri, 25 Oct 2013 16:43:18 +0200
Subject: [gnutls-help] Suport for signature algorithm 1.3.14.3.2.29
	(sha1WithRSA)
Message-ID: <db050ae8f9d91db88d2eb71eff63e49a@heapsort.de>

Hi,

while working with a self-signed certificate I got from a client, I 
noticed, certtool will spit out:

	Signature Algorithm: unknown
warning: signed using a broken signature algorithm that can be forged.

while OpenSSL detects this correctly as:

     Signature Algorithm: sha1WithRSA

When I activate debugging I get this additional message:

|<2>| Unknown SIGN OID: '1.3.14.3.2.29'

Would it be possible for GnuTLS to detect this correctly?

Regards, Tobias


From nmav at gnutls.org  Fri Oct 25 20:07:09 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 25 Oct 2013 20:07:09 +0200
Subject: [gnutls-help] Suport for signature algorithm 1.3.14.3.2.29
	(sha1WithRSA)
In-Reply-To: <db050ae8f9d91db88d2eb71eff63e49a@heapsort.de>
References: <db050ae8f9d91db88d2eb71eff63e49a@heapsort.de>
Message-ID: <526AB34D.2060002@gnutls.org>

On 10/25/2013 04:43 PM, Tobias Gruetzmacher wrote:
> Hi,
> 
> while working with a self-signed certificate I got from a client, I
> noticed, certtool will spit out:
> 
>     Signature Algorithm: unknown
> warning: signed using a broken signature algorithm that can be forged.
> 
> while OpenSSL detects this correctly as:
> 
>     Signature Algorithm: sha1WithRSA
> 
> When I activate debugging I get this additional message:
> 
> |<2>| Unknown SIGN OID: '1.3.14.3.2.29'
> 
> Would it be possible for GnuTLS to detect this correctly?

Interesting. The usual OID to use in a certificate is 2.5.8.1.1.
However, we have already some fallback when some strange OIDs are
encountered. I'll also add your OID to the list. Could you send me the
certificate to test it is recognized?

regards,
Nikos



From dkg at fifthhorseman.net  Fri Oct 25 20:09:48 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 25 Oct 2013 14:09:48 -0400
Subject: [gnutls-help] Suport for signature algorithm 1.3.14.3.2.29
	(sha1WithRSA)
In-Reply-To: <db050ae8f9d91db88d2eb71eff63e49a@heapsort.de>
References: <db050ae8f9d91db88d2eb71eff63e49a@heapsort.de>
Message-ID: <526AB3EC.2090108@fifthhorseman.net>

On 10/25/2013 10:43 AM, Tobias Gruetzmacher wrote:

> while working with a self-signed certificate I got from a client, I
> noticed, certtool will spit out:
> 
>     Signature Algorithm: unknown
> warning: signed using a broken signature algorithm that can be forged.
> 
> while OpenSSL detects this correctly as:
> 
>     Signature Algorithm: sha1WithRSA


that's odd.  SHA1 with RSA would normally be: 1.2.840.113549.1.1.5

> When I activate debugging I get this additional message:
> 
> |<2>| Unknown SIGN OID: '1.3.14.3.2.29'

how was this generated?

https://bugzilla.mozilla.org/show_bug.cgi?id=405966#c1

snd follow-on remarks suggest that this is a duplicate of the PKCS#1 OID
definitions.  I think that libNSS interprets this as a synonym.  maybe
gnutls should do the same?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131025/70277ec3/attachment-0001.sig>

From grin at grin.hu  Thu Oct 17 23:11:09 2013
From: grin at grin.hu (Peter Gervai)
Date: Thu, 17 Oct 2013 23:11:09 +0200
Subject: [gnutls-help] Fwd: TLS1.2 fail,
	Could not negotiate a supported cipher suite, 
In-Reply-To: <CAAWNVq_6CeTpPTTrD3Ujznb73PMH7wCbG=FuHxRUcSk=LhxwDg@mail.gmail.com>
References: <CAAWNVq_6CeTpPTTrD3Ujznb73PMH7wCbG=FuHxRUcSk=LhxwDg@mail.gmail.com>
Message-ID: <CAAWNVq9VXtwKvX5c5JNobg1L5R5-Jf8jBQzpmFRDCnudHkLYog@mail.gmail.com>

Hello,

Regardless of the numerous advice to recompile exim to use openssl I'm
rather here. :-) I kind of avoided the problem but it's not
prefect.... later on that .

A mailserver running Exim on Debian stable (wheezy) acts unfriendly
towards TLS users, and spews too much "Could not negotiate a supported
cipher suite." errors.

Exim is 4.80-7 (exim4-daemon-heavy) and libgnutls26 is 2.12.20-7. The
problem is that this is the same as many other servers running happily
and without significant problems.

Using annoyingly much
gnutls-cli mail.* -p 25 -s -d 5  --no-ca-verification --priority
NORMAL:-VERS-TLS-ALL:+VERS-TLS1.1
kind of commands, varying the priority it turned out that TLS1.2 will
not work no matter what I try to do, even restricting it to the one
known working RSA_AES-128-CBC_SHA1
(NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2:-CIPHER-ALL:-MAC-ALL:-KX-ALL:+RSA:+AES-128-CBC:+SHA1:-SIGN-ALL:+SIGN-RSA-SHA1:%COMPAT)
or by trying various compatibility or breakage flags.

|<2>| ASSERT: gnutls_constate.c:581
|<4>| REC[0x2453120]: Allocating epoch #1
|<3>| HSK[0x2453120]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<3>| HSK[0x2453120]: CLIENT HELLO was queued [47 bytes]
|<4>| REC[0x2453120]: Preparing Packet Handshake(22) with length: 47
and target length: 47
|<4>| REC[0x2453120]: Sent Packet[1] Handshake(22) in epoch 0 and length: 52
|<2>| ASSERT: gnutls_buffers.c:1018
|<4>| REC[0x2453120]: SSL 3.2 Handshake packet received. Epoch 0, length: 81
|<4>| REC[0x2453120]: Expected Packet Handshake(22)
|<4>| REC[0x2453120]: Received Packet Handshake(22) with length: 81
|<4>| REC[0x2453120]: Decrypted Packet[0] Handshake(22) with length: 81
|<3>| HSK[0x2453120]: SERVER HELLO (2) was received. Length 77[77],
frag offset 0, frag length: 77, sequence: 0
|<3>| HSK[0x2453120]: Server's version: 3.2
|<2>| ASSERT: gnutls_handshake.c:1721
|<2>| ASSERT: gnutls_handshake.c:2225
|<2>| ASSERT: gnutls_handshake.c:1442
|<2>| ASSERT: gnutls_handshake.c:2701
*** Fatal error: A record packet with illegal version was received.
|<4>| REC: Sending Alert[2|70] - Error in protocol version
|<4>| REC[0x2453120]: Preparing Packet Alert(21) with length: 2 and
target length: 2
|<4>| REC[0x2453120]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
*** Handshake has failed

And the other side logs no suitable cipher suite.

Pulling the server back to TLS1.1 makes it kind of work but some
clients are not happy:
"A TLS fatal alert has been received."
which probably means "I want to talk TLS1.2 dammit".

The cert is using an internal CA but it's the same CA issuing the
certs for the other servers working happily. Still, there seem to be
little difference apart from the key/cert, the ca-certificates.conf
(whcih is supposed not to be used anyway since we don't vrify the
certs), or possibly something seemingly unrelated libs around the
server.

[...]  time passes [...]

In my experience one of the best things of asking help is that I have
to gather all the info in one place, and try to make it coherent. In
the process sometimes it just happens that I happen to find the
solution. I guess a web-searchable documentation is still due, so here
you all are, googling this.

The problem is the "same old" problem happens from time to time to
gnutls installs: certs generated by openssl. These certs may work, or
may not work, or somewhere inbetween generating various horrible side
effects, including the one you have observed above. These otherwise
perfectly work with anything which is not gnutls. ;-)

The solution was generating the cert with certtool (which is a pain in
the ass since openssl is smart enough to realise that I want it to ask
for the password but use the rest of the template while certtool is
either full-interactive or non-interactive, never inbetween), and it
works.

The solution was partly helped by
gnutls_serv --debug 5 --port 1234  --x509keyfile server.key
--x509certfile server.crt
but only partially since it's almost impossible to figure out what the
bloody message means:

Could not find an appropriate certificate: Insufficient credentials
for that request.

I guess now (after knowing the solution) that it would like to convey
the message that the certificate does not allow the method I try to
use it for, or that it is missing the required extension (for example
"Key Encipherment"), or that the extension is not understood by
gnutls. If I knew that I would have suspected problems with the
certificate. But the message is so cryptic that not even
google-my-friend was able to figure it out. (Partially helped by
gnutls documentation which says not a word more explaining the
problem.)

But being able to reliably regenerate the problem resulted fast
trials, and among them was a newly generated key/cert pair (not
working), then suspecting old family feuds trying gnutls tools instead
of openssl. And bingo.

Since then it seems to work without any errors whatsoever.

Thanks for watching. ;-)

Peter


From tobias at 23.gs  Sun Oct 27 17:53:45 2013
From: tobias at 23.gs (Tobias Gruetzmacher)
Date: Sun, 27 Oct 2013 17:53:45 +0100
Subject: [gnutls-help] Suport for signature algorithm 1.3.14.3.2.29
 (sha1WithRSA)
In-Reply-To: <526AB3EC.2090108@fifthhorseman.net>
References: <db050ae8f9d91db88d2eb71eff63e49a@heapsort.de>
 <526AB3EC.2090108@fifthhorseman.net>
Message-ID: <20131027165345.GB21577@23.gs>

Hi,

On Fri, Oct 25, 2013 at 02:09:48PM -0400, Daniel Kahn Gillmor wrote:
> how was this generated?

I really don't know. It came from a partner organisation and they use it
to secure their API server with it. I could try to ask, but don't hold
your breath...

Regards, Tobias

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/attachments/20131027/6760a2d9/attachment.sig>

From nmav at gnutls.org  Sun Oct 27 19:35:50 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Oct 2013 19:35:50 +0100
Subject: [gnutls-help] Fwd: TLS1.2 fail,
 Could not negotiate a supported cipher suite, 
In-Reply-To: <CAAWNVq9VXtwKvX5c5JNobg1L5R5-Jf8jBQzpmFRDCnudHkLYog@mail.gmail.com>
References: <CAAWNVq_6CeTpPTTrD3Ujznb73PMH7wCbG=FuHxRUcSk=LhxwDg@mail.gmail.com>
 <CAAWNVq9VXtwKvX5c5JNobg1L5R5-Jf8jBQzpmFRDCnudHkLYog@mail.gmail.com>
Message-ID: <526D5D06.9000301@gnutls.org>

On 10/17/2013 11:11 PM, Peter Gervai wrote:

> Regardless of the numerous advice to recompile exim to use openssl I'm
> rather here. :-) I kind of avoided the problem but it's not
> prefect.... later on that .
> A mailserver running Exim on Debian stable (wheezy) acts unfriendly
> towards TLS users, and spews too much "Could not negotiate a supported
> cipher suite." errors.
> Exim is 4.80-7 (exim4-daemon-heavy) and libgnutls26 is 2.12.20-7. The
> problem is that this is the same as many other servers running happily
> and without significant problems.

Hello Peter,
 This is a very old libgnutls version. It also looks like it is
custom-patched as the lines of code in the log you attach below don't
correspond to lines in any released version. I'd suggest to upgrade to a
most recent gnutls version.

> The problem is the "same old" problem happens from time to time to
> gnutls installs: certs generated by openssl. These certs may work, or
> may not work, or somewhere inbetween generating various horrible side
> effects, including the one you have observed above. These otherwise
> perfectly work with anything which is not gnutls. ;-)

Are you sure you are not in one of the cases below?
http://www.gnutls.org/faq.html

There are implementations that ignore the flags in a certificate. GnuTLS
doesn't. Why set flags there if you don't want them to be used?

> The solution was partly helped by
> gnutls_serv --debug 5 --port 1234  --x509keyfile server.key
> --x509certfile server.crt
> but only partially since it's almost impossible to figure out what the
> bloody message means:
> Could not find an appropriate certificate: Insufficient credentials
> for that request.

It means there is an issue in the credentials entered (in your case
certificate). Most probably the certificate you are using doesn't allow
for the TLS ciphersuites you are using.

> I guess now (after knowing the solution) that it would like to convey
> the message that the certificate does not allow the method I try to
> use it for, or that it is missing the required extension (for example
> "Key Encipherment"), or that the extension is not understood by
> gnutls. If I knew that I would have suspected problems with the
> certificate. But the message is so cryptic that not even
> google-my-friend was able to figure it out. (Partially helped by
> gnutls documentation which says not a word more explaining the
> problem.)

Ok it seems you figured it out. You are in case
http://www.gnutls.org/faq.html#key-usage-violation
I'll add another faq entry for the server side.

In order to use the RSA ciphersuites in TLS your certificate must either
have no key usage extension, or if it has it, it must allow for Key
Encipherment. When you generate a certificate with certtool it should
mention that this is needed.

regards,
Nikos



From John.van.Kemenade at concepts.nl  Wed Oct 30 19:38:10 2013
From: John.van.Kemenade at concepts.nl (John van Kemenade)
Date: Wed, 30 Oct 2013 18:38:10 +0000
Subject: [gnutls-help] Setting up secure SMTP connection
Message-ID: <em5739b154-24e7-4f86-acf9-cc002ba8347a@john-laptop>

Hi,

My provider requires a secure SMTP connection before authentication can 
be issued.
The script I am using to send SMTP messages to my provider doesn't have 
this functionality yet.
For debugging I am using gnutls-cli to setup the connection, but I get 
the error: *** Fatal error: Error in the certificate.

Since all this certificate thing is very new to me, I have now clue 
where to start looking. Is there something wrong with my self-signed 
certificate, I am using the right cli paramters etc.
Any help or pointers in the right direction will be appreciated.

0. I am using a slackware 14 distro with GnuTLS 3.0.23

1. I created a self-signed certificate using the commands provided here: 
http://www.virtualmin.com/node/12051
openssl genrsa -des3 -out your.servername.com.key 1024
openssl req -new -key your.servername.com.key -out 
your.servername.com.csr
cp your.servername.com.key your.servername.com.key.org
openssl rsa -in your.servername.com.key.org -out your.servername.com.key
openssl x509 -req -days 365 -in your.servername.com.csr -signkey 
your.servername.com.key -out your.servername.com.crt

where your.servername.com has been subsituted by the FQDN of my machine

2. command issued to setup the connection to the SMTP server:
gnutls-cli -d 10 --starttls --x509certfile 
demeter.kemenade.no-ip.org.crt --port 587 smtp.concepts.nl

3. results
|<2>| ASSERT: pkcs11.c:459
Processed 151 CA certificate(s).
Processed 1 client X.509 certificates...
Resolving 'smtp.concepts.nl'...
Connecting to '213.197.24.111:587'...
|<4>| REC[0x1f72080]: Allocating epoch #0

- Simple Client Mode:

220-smtp-4.concepts.nl ESMTP Exim 4.72 Wed, 30 Oct 2013 19:29:55 +0100
220- Sending spam or unsolicited commercial e-mail to this server is 
strictly
220- prohibited by our NO UBE / NO UCE policy. Abuse will be prosecuted 
and/or
220  charged per attempted recipient at international postal rates.
ehlo john
250-smtp-4.concepts.nl Hello 5571f416.ftth.concepts.nl [85.113.244.22]
250-SIZE 52428800
250-PIPELINING
250-STARTTLS
250 HELP
starttls
220 TLS go ahead
*** Starting TLS handshake
|<2>| ASSERT: gnutls_constate.c:717
|<4>| REC[0x1f72080]: Allocating epoch #1
|<3>| HSK[0x1f72080]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 
(C0.09)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: 
ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: 
ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 
(C0.0A)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: 
ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: 
ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 
(C0.08)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 
(C0.13)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 
(C0.27)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 
(C0.2F)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 
(C0.14)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 
(C0.30)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 
(C0.12)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 
(00.33)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 
(00.67)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 
(00.45)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256 
(00.9E)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 
(00.39)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 
(00.6B)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 
(00.88)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 
(00.16)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 
(00.32)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256 
(00.40)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 
(00.44)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_DSS_AES_128_GCM_SHA256 
(00.A2)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 
(00.38)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256 
(00.6A)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 
(00.87)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 
(00.13)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 (00.66)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 
(00.3C)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 
(00.41)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 
(00.9C)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 
(00.3D)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 
(00.84)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 (00.05)
|<3>| HSK[0x1f72080]: Keeping ciphersuite: RSA_ARCFOUR_MD5 (00.04)
|<3>| EXT[0x1f72080]: Sending extension SERVER NAME (21 bytes)
|<3>| EXT[0x1f72080]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<3>| EXT[0x1f72080]: Sending extension SUPPORTED ECC (12 bytes)
|<3>| EXT[0x1f72080]: Sending extension SUPPORTED ECC POINT FORMATS (2 
bytes)
|<3>| EXT[0x1f72080]: sent signature algo (4.1) RSA-SHA256
|<3>| EXT[0x1f72080]: sent signature algo (4.2) DSA-SHA256
|<3>| EXT[0x1f72080]: sent signature algo (4.3) ECDSA-SHA256
|<3>| EXT[0x1f72080]: sent signature algo (5.1) RSA-SHA384
|<3>| EXT[0x1f72080]: sent signature algo (5.3) ECDSA-SHA384
|<3>| EXT[0x1f72080]: sent signature algo (6.1) RSA-SHA512
|<3>| EXT[0x1f72080]: sent signature algo (6.3) ECDSA-SHA512
|<3>| EXT[0x1f72080]: sent signature algo (3.1) RSA-SHA224
|<3>| EXT[0x1f72080]: sent signature algo (3.2) DSA-SHA224
|<3>| EXT[0x1f72080]: sent signature algo (3.3) ECDSA-SHA224
|<3>| EXT[0x1f72080]: sent signature algo (2.1) RSA-SHA1
|<3>| EXT[0x1f72080]: sent signature algo (2.2) DSA-SHA1
|<3>| EXT[0x1f72080]: sent signature algo (2.3) ECDSA-SHA1
|<3>| EXT[0x1f72080]: Sending extension SIGNATURE ALGORITHMS (28 bytes)
|<3>| HSK[0x1f72080]: CLIENT HELLO was queued [209 bytes]
|<7>| HWRITE: enqueued [CLIENT HELLO] 209. Total 209 bytes.
|<7>| HWRITE FLUSH: 209 bytes in buffer.
|<4>| REC[0x1f72080]: Preparing Packet Handshake(22) with length: 209
|<9>| ENC[0x1f72080]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 214 bytes for 0x4. Total 214 bytes.
|<4>| REC[0x1f72080]: Sent Packet[1] Handshake(22) in epoch 0 and 
length: 214
|<7>| HWRITE: wrote 1 bytes, 0 bytes left.
|<7>| WRITE FLUSH: 214 bytes in buffer.
|<7>| WRITE: wrote 214 bytes, 0 bytes left.
|<2>| ASSERT: gnutls_buffers.c:976
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1f72080]: SSL 3.1 Handshake packet received. Epoch 0, 
length: 81
|<4>| REC[0x1f72080]: Expected Packet Handshake(22)
|<4>| REC[0x1f72080]: Received Packet Handshake(22) with length: 81
|<7>| READ: Got 81 bytes from 0x4
|<7>| READ: read 81 bytes from 0x4
|<7>| RB: Have 5 bytes into buffer. Adding 81 bytes.
|<7>| RB: Requested 86 bytes
|<4>| REC[0x1f72080]: Decrypted Packet[0] Handshake(22) with length: 81
|<6>| BUF[REC]: Inserted 81 bytes of Data(22)
|<3>| HSK[0x1f72080]: SERVER HELLO was received. Length 77[77], frag 
offset 0, frag length: 77, sequence: 0
|<3>| HSK[0x1f72080]: Server's version: 3.1
|<3>| HSK[0x1f72080]: SessionID length: 32
|<3>| HSK[0x1f72080]: SessionID: 
bebaeca87a11d38bcf8dbccaf146c07a7d8e9f755f9cda0508d24f353d84ca3d
|<3>| HSK[0x1f72080]: Selected cipher suite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1f72080]: Selected compression method: NULL (0)
|<3>| EXT[0x1f72080]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 
bytes)
|<3>| HSK[0x1f72080]: Safe renegotiation succeeded
|<2>| ASSERT: gnutls_buffers.c:976
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1f72080]: SSL 3.1 Handshake packet received. Epoch 0, 
length: 1474
|<4>| REC[0x1f72080]: Expected Packet Handshake(22)
|<4>| REC[0x1f72080]: Received Packet Handshake(22) with length: 1474
|<7>| READ: Got 1474 bytes from 0x4
|<7>| READ: read 1474 bytes from 0x4
|<7>| RB: Have 5 bytes into buffer. Adding 1474 bytes.
|<7>| RB: Requested 1479 bytes
|<4>| REC[0x1f72080]: Decrypted Packet[1] Handshake(22) with length: 
1474
|<6>| BUF[REC]: Inserted 1474 bytes of Data(22)
|<3>| HSK[0x1f72080]: CERTIFICATE was received. Length 1470[1470], frag 
offset 0, frag length: 1470, sequence: 0
|<2>| ASSERT: verify.c:410
|<2>| ASSERT: verify.c:674
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- The hostname in the certificate matches 'smtp.concepts.nl'.
*** Verifying server certificate failed...
|<2>| ASSERT: gnutls_kx.c:688
|<2>| ASSERT: gnutls_handshake.c:2517
*** Fatal error: Error in the certificate.
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
  - |<2>| ASSERT: dn.c:286
|<2>| ASSERT: dn.c:286
subject `C=NL,postalCode=4817 KK,ST=Noord-Brabant,L=Breda,STREET=St. 
Ignatiusstraat 265,O=Concepts ICT,OU=Techniek,OU=Instant 
SSL,CN=smtp.concepts.nl', issuer `C=GB,ST=Greater 
Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO High-Assurance Secure 
Server CA', RSA key 2048 bits, signed using RSA-SHA1, activated 
`2013-09-05 00:00:00 UTC', expires `2014-09-05 23:59:59 UTC', SHA-1 
fingerprint `87143482688d48072e90464acbf1141b3c6e4b35'
         Public Key Id:
                 fd82f5d21e736f21b3f20070930e6709ee0238a3
         Public key's random art:
                 +--[ RSA 2048]----+
                 |       .         |
                 |  .   . . o      |
                 | + .   + B       |
                 |. o . . B..      |
                 |E    . .Soo      |
                 |      .  o.+ o . |
                 |        . o.* = .|
                 |           =.= ..|
                 |            +. ..|
                 +-----------------+

|<4>| REC: Sending Alert[2|42] - Certificate is bad
|<4>| REC[0x1f72080]: Preparing Packet Alert(21) with length: 2
|<9>| ENC[0x1f72080]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes.
|<7>| WRITE FLUSH: 7 bytes in buffer.
|<7>| WRITE: wrote 7 bytes, 0 bytes left.
|<4>| REC[0x1f72080]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
*** Handshake has failed

Any help would be appreciated

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20131030/917d5d48/attachment-0001.html>

From dkg at fifthhorseman.net  Wed Oct 30 20:51:17 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 30 Oct 2013 15:51:17 -0400
Subject: [gnutls-help] Setting up secure SMTP connection
In-Reply-To: <em5739b154-24e7-4f86-acf9-cc002ba8347a@john-laptop>
References: <em5739b154-24e7-4f86-acf9-cc002ba8347a@john-laptop>
Message-ID: <52716335.8020605@fifthhorseman.net>

On 10/30/2013 02:38 PM, John van Kemenade wrote:
> My provider requires a secure SMTP connection before authentication can
> be issued.
  [...]
> 1. I created a self-signed certificate using the commands provided here:
> http://www.virtualmin.com/node/12051
> openssl genrsa -des3 -out your.servername.com.key 1024
> openssl req -new -key your.servername.com.key -out your.servername.com.csr
> cp your.servername.com.key your.servername.com.key.org
> openssl rsa -in your.servername.com.key.org -out your.servername.com.key
> openssl x509 -req -days 365 -in your.servername.com.csr -signkey
> your.servername.com.key -out your.servername.com.crt

I'm not convinced that the above steps are necessary.  Also, if you find 
that they are necessary, this is the gnutls mailing list, so you may 
have better luck getting help here by using certtool (from the 
gnutls-bin package).

> 2. command issued to setup the connection to the SMTP server:
> gnutls-cli -d 10 --starttls --x509certfile
> demeter.kemenade.no-ip.org.crt --port 587 smtp.concepts.nl

I took a look at this server.  It looks to me like this server is 
misconfigured because it only sends its own end-entity certificate, and 
not the intermediate CA's cert.

The server operator should probably reconfigure exim to pass along the 
intermediate CA's cert.  It looks to me like this is the intermediate 
cert they need:

https://support.comodo.com/index.php?_m=downloads&_a=viewdownload&downloaditemid=101&nav=0,1

so i was able to connect with:

wget -Ointermediate.crt \
 
'https://support.comodo.com/index.php?_m=downloads&_a=downloadfile&downloaditemid=101
gnutls-cli --x509cafile intermediate.crt --port 587 --starttls \
  smtp.concepts.nl

hth,

	--dkg


From John.van.Kemenade at concepts.nl  Wed Oct 30 21:20:06 2013
From: John.van.Kemenade at concepts.nl (John van Kemenade)
Date: Wed, 30 Oct 2013 20:20:06 +0000
Subject: [gnutls-help] Antwoorden: Re:  Setting up secure SMTP connection
In-Reply-To: <52716335.8020605@fifthhorseman.net>
Message-ID: <em3d8e7455-6174-45d4-be3e-10a3d5976a14@john-laptop>

Thanks Daniel,

this takes me a step further. Now I am able to start the TLS connection.
Thanks for the quick response

John

------ Origineel bericht ------
Van: "Daniel Kahn Gillmor" <dkg at fifthhorseman.net>
Aan: "John van Kemenade" <John.van.Kemenade at concepts.nl>; 
gnutls-help at lists.gnutls.org
Verzonden: 30-10-2013 20:51:17
Onderwerp: Re: [gnutls-help] Setting up secure SMTP connection
>On 10/30/2013 02:38 PM, John van Kemenade wrote:
>>My provider requires a secure SMTP connection before authentication 
>>can
>>be issued.
>  [...]
>>1. I created a self-signed certificate using the commands provided 
>>here:
>>http://www.virtualmin.com/node/12051
>>openssl genrsa -des3 -out your.servername.com.key 1024
>>openssl req -new -key your.servername.com.key -out 
>>your.servername.com.csr
>>cp your.servername.com.key your.servername.com.key.org
>>openssl rsa -in your.servername.com.key.org -out 
>>your.servername.com.key
>>openssl x509 -req -days 365 -in your.servername.com.csr -signkey
>>your.servername.com.key -out your.servername.com.crt
>
>I'm not convinced that the above steps are necessary. Also, if you find 
>that they are necessary, this is the gnutls mailing list, so you may 
>have better luck getting help here by using certtool (from the 
>gnutls-bin package).
>
>>2. command issued to setup the connection to the SMTP server:
>>gnutls-cli -d 10 --starttls --x509certfile
>>demeter.kemenade.no-ip.org.crt --port 587 smtp.concepts.nl
>
>I took a look at this server. It looks to me like this server is 
>misconfigured because it only sends its own end-entity certificate, and 
>not the intermediate CA's cert.
>
>The server operator should probably reconfigure exim to pass along the 
>intermediate CA's cert. It looks to me like this is the intermediate 
>cert they need:
>
>https://support.comodo.com/index.php?_m=downloads&_a=viewdownload&downloaditemid=101&nav=0,1
>
>so i was able to connect with:
>
>wget -Ointermediate.crt \
>
>'https://support.comodo.com/index.php?_m=downloads&_a=downloadfile&downloaditemid=101
>gnutls-cli --x509cafile intermediate.crt --port 587 --starttls \
>  smtp.concepts.nl
>
>hth,
>
>  --dkg



From nmav at gnutls.org  Thu Oct 31 13:28:34 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 31 Oct 2013 13:28:34 +0100
Subject: [gnutls-help] gnutls 3.2.6
Message-ID: <52724CF2.8020609@gnutls.org>

Hello,
 I've just released gnutls 3.2.6. This release adds new features and
fixes bugs on the next stable branch. The most important changes are the
prioritization of the GCM mode over CBC in all priority strings, and the
enabling of TPM support by default.


* Version 3.2.6 (released 2013-10-31)

** libgnutls: Support for TPM via trousers is now enabled by default.

** libgnutls: Camellia in GCM mode has been added in default priorities,
and GCM mode is prioritized over CBC in all of the default priority strings.

** libgnutls: Added ciphersuite GNUTLS_ECDHE_RSA_AES_256_CBC_SHA384.

** libgnutls: Fixed ciphersuites
GNUTLS_ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384,
GNUTLS_ECDHE_RSA_CAMELLIA_256_CBC_SHA384 and
GNUTLS_PSK_CAMELLIA_128_GCM_SHA256. Reported by Stefan Buehler.

** libgnutls: Added support for ISO OID for RSA-SHA1 signatures.

** libgnutls: Minimum acceptable DH group parameters were increased to
767 bits from 727.

** libgnutls: Added function to obtain random data from PKCS #11 tokens.
Contributed by Wolfgang Meyer zu Bergsten.

** gnulib: updated.

** libdane: Fixed a one-off bug in dane_query_tlsa() introduced by the
previous fix. Reported by Tomas Mraz.

** p11tool: Added option generate-random.

** API and ABI modifications:
gnutls_pkcs11_token_get_random: 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.2/gnutls-3.2.6.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.6.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.6.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.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 nmav at gnutls.org  Thu Oct 31 13:28:48 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 31 Oct 2013 13:28:48 +0100
Subject: [gnutls-help] gnutls 3.1.16
Message-ID: <52724D00.30201@gnutls.org>

Hello,
 I've just released gnutls 3.1.16. This is a bug-fix release on the
 current stable branch.

* Version 3.1.16 (released 2013-10-31)

** gnulib: updated.

** libdane: Fixed a one-off bug in dane_query_tlsa() introduced by the
previous fix. Reported by Tomas Mraz.

** API and ABI modifications:
No changes since last version.


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.1/gnutls-3.1.16.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.16.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.16.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.16.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 w94f8726ui at googlemail.com  Thu Oct 31 15:32:38 2013
From: w94f8726ui at googlemail.com (w94f8726ui)
Date: Thu, 31 Oct 2013 15:32:38 +0100
Subject: [gnutls-help] certtool does not encrypt private keyfiles
Message-ID: <52726A06.8070402@gmail.com>

Hi,

i generate a key with the following line:

/usr/local/bin/certtool -p -8 --pkcs-cipher=aes-256 
--disable-quick-random --sec-param=ultra --password=XXXXX --outfile 
XXXXX.key

Now i have a wonderful keyfile with a minor problem.
The keyfile holds, pricate key, x and y in UNENCRYPTED values.
After that the encrypted keypart starts.

So, is this a bug or do i have to manually remove the unencrypted parts?
Cause i think a lot of folks generate encrypted keyfiles and think that 
all the important info would be encrypted.

Using GnuTLS 3.2.6.

best regards,
jack