TLS 1.2 server

[Daiki Ueno]

Hello,

I've just pushed TLS 1.2 server fix.  While it was done in the same way
as I did for client, I'd appreciate if someone will take a look at the
changes:

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=e0b1124f72e3d5210000b3f677b401d8b2654ea4
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=4b48a9e8e28bbd468b48ed5cb95ba0cce7508be6

The latter change is not essential by now but it will be needed when we
will use a hash algorithm other than SHA1 to compute a signature of DH
params.

Anyway, TLS 1.2 server works again.  I tried it with Opera 10 and the
test output from GnuTLS says:

 Server Name: localhost
 Ephemeral DH using prime of 1024 bits.

 Protocol version: TLS1.2
 Certificate Type: X.509
 Key Exchange: DHE-RSA
 Compression NULL
 Cipher AES-256-CBC
 MAC SHA256
 Ciphersuite DHE_RSA_AES_256_CBC_SHA256

Regards,
--
Daiki Ueno


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Daiki Ueno <ueno@...> writes:

> Hello,
>
> I've just pushed TLS 1.2 server fix.  While it was done in the same way
> as I did for client, I'd appreciate if someone will take a look at the
> changes:
>
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=e0b1124f72e3d5210000b3f677b401d8b2654ea4
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=4b48a9e8e28bbd468b48ed5cb95ba0cce7508be6
>
> The latter change is not essential by now but it will be needed when we
> will use a hash algorithm other than SHA1 to compute a signature of DH
> params.
>
> Anyway, TLS 1.2 server works again.  I tried it with Opera 10 and the
> test output from GnuTLS says:

Great, thank you!  The patch seems fine to me.

What do you think we should do about the CertificateRequest
supported_signature_algorithms field?  I think the application may want
to look at the server preference when deciding which certificate to use,
and GnuTLS may want to use this information internally too, when it is
selecting the certificate.

/Simon

>  Server Name: localhost
>  Ephemeral DH using prime of 1024 bits.
>
>  Protocol version: TLS1.2
>  Certificate Type: X.509
>  Key Exchange: DHE-RSA
>  Compression NULL
>  Cipher AES-256-CBC
>  MAC SHA256
>  Ciphersuite DHE_RSA_AES_256_CBC_SHA256
>
> Regards,

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Daiki Ueno]

>>>>> In <87r5tp56c4.fsf@...>
>>>>> Simon Josefsson <simon@...> wrote:
> What do you think we should do about the CertificateRequest
> supported_signature_algorithms field?  I think the application may want
> to look at the server preference when deciding which certificate to use,
> and GnuTLS may want to use this information internally too, when it is
> selecting the certificate.

I have thought of something like:

* Provide the following default ordering of algorithms:

  RSA_SHA512(*)
  RSA_SHA384(*)
  RSA_SHA256(*)
  RSA_SHA1(+)
  DSA_SHA1(+)

  * is only available if RSA certificate is given
  + is only available if DSA certificate is given

* The application may supply the preference through a priority string
  like this: "+SIGN_RSA_SHA256:-SIGN_RSA_SHA384:!SIGN_RSA_SHA1", where
  "+" moves the given algorithm to the top, "-" moves it to the bottom,
  and "!"  disables it.

Any thoughts?

Regards,
--
Daiki Ueno


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

The x509self self-test started failing, and it may be TLS 1.2 related.
Can you take a look?

/Simon

client: sent record.
server: got data, forcing rehandshake.
client: recv returned -37.
client: doing handshake!
==12233== Invalid read of size 4
==12233==    at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172)
==12233==    by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157)
==12233==    by 0x4055197: _gnutls_gen_cert_client_cert_vrfy (auth_cert.c:1419)
==12233==    by 0x40458BD: _gnutls_send_client_certificate_verify (gnutls_kx.c:352)
==12233==    by 0x404230F: _gnutls_handshake_client (gnutls_handshake.c:2464)
==12233==    by 0x4042C0F: gnutls_handshake (gnutls_handshake.c:2311)
==12233==    by 0x804A362: client (x509self.c:189)
==12233==    by 0x804A4D1: doit (x509self.c:511)
==12233==    by 0x804AA7C: main (utils.c:148)
==12233==  Address 0x43176dd3 is not stack'd, malloc'd or (recently) free'd


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Daiki Ueno <ueno@...> writes:

>>>>>> In <87r5tp56c4.fsf@...>
>>>>>> Simon Josefsson <simon@...> wrote:
>> What do you think we should do about the CertificateRequest
>> supported_signature_algorithms field?  I think the application may want
>> to look at the server preference when deciding which certificate to use,
>> and GnuTLS may want to use this information internally too, when it is
>> selecting the certificate.
>
> I have thought of something like:
>
> * Provide the following default ordering of algorithms:
>
>   RSA_SHA512(*)
>   RSA_SHA384(*)
>   RSA_SHA256(*)
>   RSA_SHA1(+)
>   DSA_SHA1(+)
>
>   * is only available if RSA certificate is given
>   + is only available if DSA certificate is given

The approach seems OK, but I think the ordering should depend on the
NORMAL vs SECURE vs PERFORMANCE.  For similar reasons GnuTLS prefer
AES-128 over AES-256 (i.e., because of no known attacks and it is
faster), RSA_SHA256 should probably be the default in the NORMAL mode.

Thus NORMAL:

   RSA_SHA256(*)
   RSA_SHA384(*)
   RSA_SHA512(*)
   RSA_SHA1(+)
   DSA_SHA1(+)

And PERFORMANCE:

   RSA_SHA1(+)
   DSA_SHA1(+)
   RSA_SHA256(*)
   RSA_SHA384(*)
   RSA_SHA512(*)

And SECURE:

   RSA_SHA512(*)
   RSA_SHA384(*)
   RSA_SHA256(*)
   RSA_SHA1(+)
   DSA_SHA1(+)

Possibly SHA-1 should not be mentioned in the SECURE mode at all?  The
hash is considered broken even though no practical attacks are known.

> * The application may supply the preference through a priority string
>   like this: "+SIGN_RSA_SHA256:-SIGN_RSA_SHA384:!SIGN_RSA_SHA1", where
>   "+" moves the given algorithm to the top, "-" moves it to the bottom,
>   and "!"  disables it.

Sounds good.  Today ! and - have the same meaning for priority strings
(i.e., remove), but I like your model better.

Clients will probably want to be able to inspect the server's preference
list when it is in the certificate selection callback function.  I think
a new API function is needed to extract the algorithm identifiers.

Implementing the first part (i.e., sending a server side preference
list) is probably the easiest to start with.  Would you like to work on
it?  Once that is working, it will be easier to add the API to return
the algorithm list for clients.  And finally, make GnuTLS automatically
pick the most appropriate client certificate by default if the
application supplied more than one (depending on server side
preference).

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Daiki Ueno]

>>>>> In <87ske44pfy.fsf@...>
>>>>> Simon Josefsson <simon@...> wrote:
> The x509self self-test started failing, and it may be TLS 1.2 related.
> Can you take a look?

Sure, but I couldn't reproduce the failure.  What architecture did you
run the test on?

> ==12233== Invalid read of size 4
> ==12233==    at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172)
> ==12233==    by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157)
> ==12233==    by 0x4055197: _gnutls_gen_cert_client_cert_vrfy (auth_cert.c:1419)
> ==12233==    by 0x40458BD: _gnutls_send_client_certificate_verify (gnutls_kx.c:352)

Hmm, I haven't touched any of those functions, anyway I will look into
it further tomorrow.  Sorry if it is by my mistake (probably so...)

Regards,
--
Daiki Ueno


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Daiki Ueno <ueno@...> writes:

>>>>>> In <87ske44pfy.fsf@...>
>>>>>> Simon Josefsson <simon@...> wrote:
>> The x509self self-test started failing, and it may be TLS 1.2 related.
>> Can you take a look?
>
> Sure, but I couldn't reproduce the failure.  What architecture did you
> run the test on?

Debian x86.

>> ==12233== Invalid read of size 4
>> ==12233==    at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172)
>> ==12233==    by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157)
>> ==12233==    by 0x4055197: _gnutls_gen_cert_client_cert_vrfy (auth_cert.c:1419)
>> ==12233==    by 0x40458BD: _gnutls_send_client_certificate_verify (gnutls_kx.c:352)
>
> Hmm, I haven't touched any of those functions, anyway I will look into
> it further tomorrow.  Sorry if it is by my mistake (probably so...)

The error happened when I made TLS 1.2 the default, so if you didn't
pull you might not see it.  It could be something else, although the
auth_cert.c stuff did change which may have caused this -- I'll look
into it further as well when I get time.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Daiki Ueno]

>>>>> In <87eipo4jgc.fsf@...>
>>>>> Simon Josefsson <simon@...> wrote:
> >> The x509self self-test started failing, and it may be TLS 1.2 related.
> >> Can you take a look?
> >
> > Sure, but I couldn't reproduce the failure.  What architecture did you
> > run the test on?

> Debian x86.

I'm now able to reproduce it on x86.  I wonder why this is not the case
on amd64.

> >> ==12233== Invalid read of size 4
> >> ==12233==    at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172)
> >> ==12233==    by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157)

It should be fixed with:
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=01c50c13f7e7a1d676451015ef66c95511d1d734

That was actually my mistake - when I changed the underlying hash
function from SHA-1 to SHA256, I forgot to increase the buffer size of
internal hash values.

Regards,
--
Daiki Ueno


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Daiki Ueno <ueno@...> writes:

>>>>>> In <87eipo4jgc.fsf@...>
>>>>>> Simon Josefsson <simon@...> wrote:
>> >> The x509self self-test started failing, and it may be TLS 1.2 related.
>> >> Can you take a look?
>> >
>> > Sure, but I couldn't reproduce the failure.  What architecture did you
>> > run the test on?
>
>> Debian x86.
>
> I'm now able to reproduce it on x86.  I wonder why this is not the case
> on amd64.
>
>> >> ==12233== Invalid read of size 4
>> >> ==12233==    at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172)
>> >> ==12233==    by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157)
>
> It should be fixed with:
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=01c50c13f7e7a1d676451015ef66c95511d1d734
>
> That was actually my mistake - when I changed the underlying hash
> function from SHA-1 to SHA256, I forgot to increase the buffer size of
> internal hash values.

Thanks!

I'll do a release shortly, so we can more easily test how TLS 1.2 works
in some real applications now that it is the default.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Nikos Mavrogiannopoulos]

Simon Josefsson wrote:

> I'll do a release shortly, so we can more easily test how TLS 1.2 works
> in some real applications now that it is the default.

Hi,
 I've checked TLS 1.2 recently, and as far as I understand the only part
missing is support for SignatureAndHashAlgorithm in Certificate Request,
as well as the extension 'signature_algorithms'. Am I correct? Is there
something else missing?

As I see it for the support of SignatureAndHashAlgorithm in Certificate
Request the handshake must be changed (for the client at least), to hold
all handshake messages and calculate the hash based on what the server
sent. This is tricky since if implemented only for TLS 1.2 we have a
code full of ifs that will be impossible to read. I'll see whether I can
make something for it the next few days.

regards,
Nikos


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Nikos Mavrogiannopoulos <nmav@...> writes:

> Simon Josefsson wrote:
>
>> I'll do a release shortly, so we can more easily test how TLS 1.2 works
>> in some real applications now that it is the default.
>
> Hi,
>  I've checked TLS 1.2 recently, and as far as I understand the only part
> missing is support for SignatureAndHashAlgorithm in Certificate Request,
> as well as the extension 'signature_algorithms'. Am I correct? Is there
> something else missing?

That's missing, right.  Client-authentication with TLS 1.2 and
certificate signing callbacks doesn't seem to be working right either,
the sign callback receives a string of size 36 (SHA1+MD5) but it should
be a PKCS#1 SHA1/SHA2 structure.

> As I see it for the support of SignatureAndHashAlgorithm in Certificate
> Request the handshake must be changed (for the client at least), to hold
> all handshake messages and calculate the hash based on what the server
> sent. This is tricky since if implemented only for TLS 1.2 we have a
> code full of ifs that will be impossible to read. I'll see whether I can
> make something for it the next few days.

Yeah, I know. :-(

My plan was to create some helper functions to do the hashing, and set
up separate hashing for all of MD5, SHA-1, SHA-2 and let the later code
figure out which hash to actually use.  This is wasteful, but that is
the TLS 1.2 design.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Nikos Mavrogiannopoulos]

Simon Josefsson wrote:

> That's missing, right.  Client-authentication with TLS 1.2 and
> certificate signing callbacks doesn't seem to be working right either,
> the sign callback receives a string of size 36 (SHA1+MD5) but it should
> be a PKCS#1 SHA1/SHA2 structure.

Hi,
 I think I fixed this part during the weekend, however I don't know if
the value received by the callback is what it is expected.

> Yeah, I know. :-(
>
> My plan was to create some helper functions to do the hashing, and set
> up separate hashing for all of MD5, SHA-1, SHA-2 and let the later code
> figure out which hash to actually use.  This is wasteful, but that is
> the TLS 1.2 design.

I now use only SHA-1 and SHA-256 and wait for a fix in TLS 1.3 :)
(MD5 is no use for a signature anyway, and the rest... just allow SHA-256 :)

regards,
Nikos


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Nikos Mavrogiannopoulos <nmav@...> writes:

> Simon Josefsson wrote:
>
>> That's missing, right.  Client-authentication with TLS 1.2 and
>> certificate signing callbacks doesn't seem to be working right either,
>> the sign callback receives a string of size 36 (SHA1+MD5) but it should
>> be a PKCS#1 SHA1/SHA2 structure.
>
> Hi,
>  I think I fixed this part during the weekend, however I don't know if
> the value received by the callback is what it is expected.

Great, I'll check it.

Btw, I backed out some patch from the gnutls-2.8 branch because it was
added after I made the release candidate and I didn't want to delay the
release.  The patch looked quite large though, is it really appropriate
for 2.8.x?  TLS 1.2 isn't enabled by default in 2.8 because it never
worked well, so I don't think TLS 1.2 related fixes are suitable for
that branch.

>> Yeah, I know. :-(
>>
>> My plan was to create some helper functions to do the hashing, and set
>> up separate hashing for all of MD5, SHA-1, SHA-2 and let the later code
>> figure out which hash to actually use.  This is wasteful, but that is
>> the TLS 1.2 design.
>
> I now use only SHA-1 and SHA-256 and wait for a fix in TLS 1.3 :)
> (MD5 is no use for a signature anyway, and the rest... just allow SHA-256 :)

Let's see if it gets fixed...  I'm not holding my breath.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Nikos Mavrogiannopoulos]

Simon Josefsson wrote:

> Btw, I backed out some patch from the gnutls-2.8 branch because it was
> added after I made the release candidate and I didn't want to delay the
> release.  The patch looked quite large though, is it really appropriate
> for 2.8.x?  TLS 1.2 isn't enabled by default in 2.8 because it never
> worked well, so I don't think TLS 1.2 related fixes are suitable for
> that branch.

I was also worrying about it since it was many fixes in one. The only
reason I committed it, was because it fixed the memory leak issue in
interrupted handshake.

regards,
Nikos


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Nikos Mavrogiannopoulos <nmav@...> writes:

> Simon Josefsson wrote:
>
>> Btw, I backed out some patch from the gnutls-2.8 branch because it was
>> added after I made the release candidate and I didn't want to delay the
>> release.  The patch looked quite large though, is it really appropriate
>> for 2.8.x?  TLS 1.2 isn't enabled by default in 2.8 because it never
>> worked well, so I don't think TLS 1.2 related fixes are suitable for
>> that branch.
>
> I was also worrying about it since it was many fixes in one. The only
> reason I committed it, was because it fixed the memory leak issue in
> interrupted handshake.

Is it possible to fix only that leak without the other stuff?

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Nikos Mavrogiannopoulos]

Simon Josefsson wrote:

> Is it possible to fix only that leak without the other stuff?

Could be but currently I don't have the time.



_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel