OpenSSL version 1.1.0 pre release 2 published

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

OpenSSL version 1.1.0 pre release 2 published

Richard Levitte - VMS Whacker-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.1.0 pre release 2 (alpha)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 2 has now
   been made available. For details of changes and known issues see the
   release notes at:

        http://www.openssl.org/news/openssl-1.1.0-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The alpha release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

     * http://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.0-pre2.tar.gz
      Size: 4948288
      SHA1 checksum: d7a26cce5d4cc2b491996489d5385e0640bb92ef
      SHA256 checksum: 09e7470462e263ae853bc7a8fdb07fa439651c5f70aab4573c1a87ee2537a7ac

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.0-pre2.tar.gz
    openssl sha256 openssl-1.1.0-pre2.tar.gz

   Please download and check this alpha release as soon as possible.
   Bug reports should go to [hidden email]. Please check the release
   notes and mailing lists to avoid duplicate reports of known issues.

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWl7A8AAoJENXp5D99+e6MB2kQAJU5fn49JZ7YPx1VByhn873B
UptNfbXozRn7ceLoDxMuZlwhbZEV/2BVc37bocagTsuU2gu2RedCE4WS/Kdk9j7q
9IK7pgInLgK2gTMXuPzKFz2qxAxtSi5QJC7BRqq88gR03dl0qXuJ+eCW2Y+zKiDt
2WgAFKrbTW9reDZs2a6WLJEY2lQdsc4eKMkVfCPZTPNpwMUsXipv7egJYC5XchBG
ZM1nq8KbmwtVn1EIjH3pUxKbRIPhfza3OCwKQqWsx1XHga7fA4Cz/u+NiswcubGv
fC+Aei30Ygi3oR8QG2tdEYMWQaa54hvn06/1bh6tVi8GcXGhFXj+gUTr6dw4TlGx
wB/H3bII9slNkGC3w5kcVbSdCmH7ThTDKqeHbqPTVooOJMXMKj5EBXGKkkJ/O8Xg
P3cDhqw48LgTW6BtM0ItZE7yHrApPaJr4MWTBQj4uqUIQz0SSUnxCE7xpSJS5UPE
A/oi0p+Mzr3bJG+39lzDEqhFWxR/WP5cU9mWo68b002qwSzcOPm8RpMfqGfNJDyg
P5OVJnykeI0JU8rR85fTdJFvcGgESOfv1HnSa9sGIMLhEA6Y4GwDhM804AV9xQ3+
trLd1Y5WYTcgc8yx181psw541N1Hsxl15Jm2sPcMMYdiK5YVbi1y+K3NGfnmKnYT
/79DbTCo0r02h0k1X8JI
=It+h
-----END PGP SIGNATURE-----
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Jouni Malinen-4
On Thu, Jan 14, 2016 at 03:44:18PM +0100, Richard Levitte wrote:
>    OpenSSL version 1.1.0 pre release 2 (alpha)

>    OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 2 has now
>    been made available. For details of changes and known issues see the
>    release notes at:
>
>         http://www.openssl.org/news/openssl-1.1.0-notes.html

I needed to do following updates to hostapd/wpa_supplicant to build
against this (to a snapshot that worked with 1.1.0 pre release 1):
- use EVP_CIPHER_CTX_new() and dynamic allocation instead of having
  EVP_CIPHER_CTX ctx on stack and using EVP_CIPHER_CTX_init(&ctx)
  (I guess this was an expected change, but for some reason, pre release
   1 did not force this)
- replace "SSL_CIPHER **cipher" with "const SSL_CIPHER **cipher" in the
  SSL_set_session_secret_cb() callback function
  (I did not notice any comment about this in the changelog; was there
   supposed to be something? This broke API compatibility.. The change
   itself is fine and I already had to do some with BoringSSL, but it
   would be nice to get this type of incompatible API changes noted
   clearly)

As far as functionality is concerned, I did see number of new issues
when running through my automated test setup and especially the EAP test
cases. I haven't yet looked at what exactly caused these, but these did
not look exactly good, so that's why a quick note here first to see if
anything sounds familiar and someone would already know why the behavior
changed between pre release 1 and 2.

Many of the negative test cases that verify that server certificate
chain validation works by using mismatching trust roots (i.e., server
certificate is not issued by any of the trusted CA certificates) are
failing. OpenSSL allows the TLS handshake to be completed with the
verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func))
reports preverify_ok=1 and err=0 for the root CA and the server
certificate even though the client side has not configured that root CA
as trusted. This worked fine with pre release 1, so I'm quite concerned
about the change in behavior when nothing in the application side
changed and an untrusted server certificate suddenly became trusted by
OpenSSL update.. Is there really an intentional change in OpenSSL
requiring something additional to be done to configure peer certificate
validation to result in failure with the latest pre release?

EAP server side is crashing (segmentation fault) in a pretty strange way
when using CRL validation as part of the TLS handshake. This is my test
case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the
hostapd process that went through the TLS server side exchange. It looks
like a crash in OpenSSL check_revocation(), but I guess I'll need to
enable more debug symbols somewhere to get bit more helpful output. This
same test case worked fine with pre release 1. The test case ends up
using a code path that executes cs = SSL_CTX_get_cert_store() and
X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK).

==627== Conditional jump or move depends on uninitialised value(s)
==627==    at 0x6174D5: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x618280: verify_chain (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x55782F: ssl_add_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x575157: ssl3_output_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x569D3C: ossl_statem_server_construct_message (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x56461D: state_machine (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x5513BB: SSL_accept (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x50AF9C: openssl_handshake (tls_openssl.c:3180)
==627==    by 0x50AF9C: openssl_connection_handshake (tls_openssl.c:3273)
==627==    by 0x508A21: eap_server_tls_phase1 (eap_server_tls_common.c:316)
==627==    by 0x4C41B1: eap_tls_process_msg (eap_server_tls.c:247)
==627==    by 0x508C6B: eap_server_tls_process (eap_server_tls_common.c:468)
==627==    by 0x4C40C3: eap_tls_process (eap_server_tls.c:259)
==627==
==627== Use of uninitialised value of size 8
==627==    at 0x61742D: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x662C55F: ???
==627==    by 0xEFFFFFFFF: ???
==627==    by 0x654653F: ???
==627==
vex amd64->IR: unhandled instruction bytes: 0x6E 0x6F 0x6E 0x65 0x0 0x52 0x53 0x41
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==627== Invalid read of size 4
==627==    at 0x75FFEA: ??? (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0xFFF00038F: ???
==627==    by 0x20441A6D1E48C1FF: ???
==627==    by 0xFFF00038F: ???
==627==    by 0xFFF00038F: ???
==627==    by 0x1: ???
==627==    by 0x654653F: ???
==627==  Address 0x1003029407 is not stack'd, malloc'd or (recently) free'd

--
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Viktor Dukhovni

> On Jan 14, 2016, at 11:47 AM, Jouni Malinen <[hidden email]> wrote:
>
> Many of the negative test cases that verify that server certificate
> chain validation works by using mismatching trust roots (i.e., server
> certificate is not issued by any of the trusted CA certificates) are
> failing. OpenSSL allows the TLS handshake to be completed with the
> verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func))
> reports preverify_ok=1 and err=0 for the root CA and the server
> certificate even though the client side has not configured that root CA
> as trusted. This worked fine with pre release 1, so I'm quite concerned
> about the change in behavior when nothing in the application side
> changed and an untrusted server certificate suddenly became trusted by
> OpenSSL update.. Is there really an intentional change in OpenSSL
> requiring something additional to be done to configure peer certificate
> validation to result in failure with the latest pre release?
>
> EAP server side is crashing (segmentation fault) in a pretty strange way
> when using CRL validation as part of the TLS handshake. This is my test
> case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the
> hostapd process that went through the TLS server side exchange. It looks
> like a crash in OpenSSL check_revocation(), but I guess I'll need to
> enable more debug symbols somewhere to get bit more helpful output. This
> same test case worked fine with pre release 1. The test case ends up
> using a code path that executes cs = SSL_CTX_get_cert_store() and
> X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK).

Well I rewrote the certificate chain verification code, perhaps some more
polish is needed.  Please, if possible, send the chain being verified
(the leaf and and "untrusted" certs), plus the trusted roots (clearly
marked as such), and I'll look into it.

--
--
        Viktor.


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Viktor Dukhovni
In reply to this post by Jouni Malinen-4
On Thu, Jan 14, 2016 at 06:47:49PM +0200, Jouni Malinen wrote:

> EAP server side is crashing (segmentation fault) in a pretty strange way
> when using CRL validation as part of the TLS handshake. This is my test
> case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the
> hostapd process that went through the TLS server side exchange. It looks
> like a crash in OpenSSL check_revocation(), but I guess I'll need to
> enable more debug symbols somewhere to get bit more helpful output. This
> same test case worked fine with pre release 1. The test case ends up
> using a code path that executes cs = SSL_CTX_get_cert_store() and
> X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK).
>
> ==627== Conditional jump or move depends on uninitialised value(s)
> ==627==    at 0x6174D5: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd)
> ==627==    by 0x618280: verify_chain (in /home/jm/Git/hostap/hostapd/hostapd)
> ==627==    by 0x55782F: ssl_add_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd)
> ==627==    by 0x575157: ssl3_output_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd)
> ==627==    by 0x569D3C: ossl_statem_server_construct_message (in /home/jm/Git/hostap/hostapd/hostapd)
> ==627==    by 0x56461D: state_machine (in /home/jm/Git/hostap/hostapd/hostapd)
> ==627==    by 0x5513BB: SSL_accept (in /home/jm/Git/hostap/hostapd/hostapd)
> ==627==    by 0x50AF9C: openssl_handshake (tls_openssl.c:3180)
> ==627==    by 0x50AF9C: openssl_connection_handshake (tls_openssl.c:3273)
> ==627==    by 0x508A21: eap_server_tls_phase1 (eap_server_tls_common.c:316)
> ==627==    by 0x4C41B1: eap_tls_process_msg (eap_server_tls.c:247)
> ==627==    by 0x508C6B: eap_server_tls_process (eap_server_tls_common.c:468)
> ==627==    by 0x4C40C3: eap_tls_process (eap_server_tls.c:259)
> ==627==
> ==627== Use of uninitialised value of size 8
> ==627==    at 0x61742D: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd)
> ==627==    by 0x662C55F: ???
> ==627==    by 0xEFFFFFFFF: ???
> ==627==    by 0x654653F: ???

See patch just posted, and also pushed to github.  This will likely fix
the CRL issue.

    commit 311f27852a18fb9c10f0c1283b639f12eea06de2
    Author: Viktor Dukhovni <[hidden email]>
    Date:   Thu Jan 14 12:23:35 2016 -0500

        Always initialize X509_STORE_CTX get_crl pointer

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Jouni Malinen-4
On Thu, Jan 14, 2016 at 05:39:39PM +0000, Viktor Dukhovni wrote:
> See patch just posted, and also pushed to github.  This will likely fix
> the CRL issue.
>
>     commit 311f27852a18fb9c10f0c1283b639f12eea06de2
>     Author: Viktor Dukhovni <[hidden email]>
>     Date:   Thu Jan 14 12:23:35 2016 -0500
>
> Always initialize X509_STORE_CTX get_crl pointer

Thanks! This applied on top of pre-rel 2 does indeed resolve the CRL
issue I saw.
 
--
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Viktor Dukhovni
In reply to this post by Jouni Malinen-4
On Thu, Jan 14, 2016 at 06:47:49PM +0200, Jouni Malinen wrote:

> Many of the negative test cases that verify that server certificate
> chain validation works by using mismatching trust roots (i.e., server
> certificate is not issued by any of the trusted CA certificates) are
> failing.

You should be able to test chains with "openssl verify(1)".  This
runs X509_verify_cert() in pretty much the same manner as with a
live TLS connection.

    # Trusted root set and matching purpose:
    $ openssl verify \
        -trusted rootcert.pem \
        -untrusted rootcert.pem -untrusted cacert.pem \
        -purpose sslserver eecert.pem; echo $?
        eecert.pem; excho $?
    eecert.pem: OK
    0

    # No trusted root
    $ openssl verify \
        -untrusted rootcert.pem -untrusted cacert.pem \
        -purpose sslserver eecert.pem; echo $?
    CN = Issuer CA
    error 20 at 1 depth lookup: unable to get local issuer certificate
    error eecert.pem: verification failed
    2

    # Wrong purpose
    $ openssl verify \
        -trusted rootcert.pem \
        -untrusted rootcert.pem -untrusted cacert.pem \
        -purpose sslclient eecert.pem; echo $?
    CN = example.com
    error 26 at 0 depth lookup: unsupported certificate purpose
    error eecert.pem: verification failed
    2

Instead of "-trusted" you can use "-CAfile" and/or "-CApath" as
usual, but "-trusted" gives more precise control, because then
*only* the certs in that file are trusted, otherwise the default
verify locations may also be in play.

It would be great if you could reproduce any failures outside of
EAP, just by checking the chain.

> OpenSSL allows the TLS handshake to be completed with the
> verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func))
> reports preverify_ok=1 and err=0 for the root CA and the server
> certificate even though the client side has not configured that root CA
> as trusted.

Please send the chain, and the trust store certificates.  Are you
using CAfile/CApath/both?

> Is there really an intentional change in OpenSSL
> requiring something additional to be done to configure peer certificate
> validation to result in failure with the latest pre release?

No, but the implementation has changed considerably, for the better
in terms of code maintainability, but new issues are a possibility.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Jouni Malinen-4
In reply to this post by Viktor Dukhovni
On Thu, Jan 14, 2016 at 12:08:06PM -0500, Viktor Dukhovni wrote:
> Well I rewrote the certificate chain verification code, perhaps some more
> polish is needed.  Please, if possible, send the chain being verified
> (the leaf and and "untrusted" certs), plus the trusted roots (clearly
> marked as such), and I'll look into it.

I'm not sure this is going to be helpful since this is a very basic case
and I cannot reproduce this with openssl verify. Anyway, the incorrect
CA and the only certificate that was configured as trusted on the client
was this one:
http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca-incorrect.pem
while the server used this certificate:
http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/server.pem
and this issuer:
http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca.pem

Not even the issue subject name match here..

Still, I'm getting this with pre-rel 2 on the client:

SSL: SSL_connect:SSLv3/TLS read server hello
OpenSSL: RX ver=0x303 content_type=22 (handshake/certificate)
TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=1 buf='/C=FI/O=w1.fi/CN=Root CA'
TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=0 buf='/C=FI/O=w1.fi/CN=server.w1.fi'

And TLS handshake completes successfully.

With OpenSSL 1.0.2d, this fails (as expected):

SSL: SSL_connect:SSLv3 read server hello A
OpenSSL: RX ver=0x303 content_type=22 (handshake/certificate)
TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 1 for '/C=FI/O=w1.fi/CN=Root CA'


So this has to be something with how the chain verification code gets
configured.. I'll see if I can find the commit that changed the behavior
to make it a bit more easier to figure out what exactly may have
happened.
 
--
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Viktor Dukhovni
On Thu, Jan 14, 2016 at 08:35:26PM +0200, Jouni Malinen wrote:

> Anyway, the incorrect
> CA and the only certificate that was configured as trusted on the client
> was this one:
> http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca-incorrect.pem
> while the server used this certificate:
>
> http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/server.pem
> and this issuer:
> http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca.pem

Thanks.  That's enough info.  Patch below.

diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
index c395acc..24ca9e3 100644
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -580,7 +580,11 @@ static int check_trust(X509_STORE_CTX *ctx, int num_untrusted)
     int num = sk_X509_num(ctx->chain);
     int trust;
 
-    if (DANETLS_HAS_TA(dane) && num_untrusted > 0) {
+    /*
+     * Check for a DANE issuer at depth 1 or greater, if it is a DANE-TA(2)
+     * match, we're done, otherwise we'll merely record the match depth.
+     */
+    if (DANETLS_HAS_TA(dane) && num_untrusted > 0 && num_untrusted < num) {
         switch (trust = check_dane_issuer(ctx, num_untrusted)) {
         case X509_TRUST_TRUSTED:
         case X509_TRUST_REJECTED:
@@ -614,12 +618,13 @@ static int check_trust(X509_STORE_CTX *ctx, int num_untrusted)
         return X509_TRUST_UNTRUSTED;
     }
 
-    if (ctx->param->flags & X509_V_FLAG_PARTIAL_CHAIN) {
+    if (num_untrusted > num && ctx->param->flags & X509_V_FLAG_PARTIAL_CHAIN) {
         /*
          * Last-resort call with no new trusted certificates, check the leaf
          * for a direct trust store match.
          */
-        x = sk_X509_value(ctx->chain, 0);
+        i = 0;
+        x = sk_X509_value(ctx->chain, i);
         mx = lookup_cert_match(ctx, x);
         if (!mx)
             return X509_TRUST_UNTRUSTED;
@@ -2894,7 +2899,7 @@ static int build_chain(X509_STORE_CTX *ctx)
             trust = check_dane_pkeys(ctx);
         if (trust == X509_TRUST_UNTRUSTED &&
             sk_X509_num(ctx->chain) == ctx->num_untrusted)
-            trust = check_trust(ctx, 1);
+            trust = check_trust(ctx, ctx->num_untrusted+1);
     }
 
     switch (trust) {

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Viktor Dukhovni

> On Jan 14, 2016, at 2:38 PM, Viktor Dukhovni <[hidden email]> wrote:
>
> Thanks.  That's enough info.  Patch below.

Or pull the master branch from github.

--
        Viktor.



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Jouni Malinen-4
On Thu, Jan 14, 2016 at 03:15:12PM -0500, Viktor Dukhovni wrote:
>
> > On Jan 14, 2016, at 2:38 PM, Viktor Dukhovni <[hidden email]> wrote:
> >
> > Thanks.  That's enough info.  Patch below.
>
> Or pull the master branch from github.

Thanks! I confirmed that both the patch on top of pre-rel 2 (+ CRL fix)
and the current master branch snapshot fixed all the test cases that I
saw failing previously.
 
--
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Viktor Dukhovni

> On Jan 14, 2016, at 3:21 PM, Jouni Malinen <[hidden email]> wrote:
>
> On Thu, Jan 14, 2016 at 03:15:12PM -0500, Viktor Dukhovni wrote:
>>
>>> On Jan 14, 2016, at 2:38 PM, Viktor Dukhovni <[hidden email]> wrote:
>>>
>>> Thanks.  That's enough info.  Patch below.
>>
>> Or pull the master branch from github.
>
> Thanks! I confirmed that both the patch on top of pre-rel 2 (+ CRL fix)
> and the current master branch snapshot fixed all the test cases that I
> saw failing previously.

Thanks for the prompt error report.  If you're willing to share your
test chains, and if it is likely to be not too difficult to include
them with the OpenSSL bundled tests, that might be worth looking into.

We definitely need more chain verification test cases, and yours failed
with the unpatched "openssl verify" when used just right:

 $ openssl verify -trusted ca-incorrect.pem -untrusted ca.pem \
      -purpose sslserver server.pem

The untrusted ca.pem came up trusted incorrectly.  The new DANE-specific
chain tests are much more comprehensive at this time than the non-DANE
ones, we'll need to address that before the final release.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Jouni Malinen-4
On Thu, Jan 14, 2016 at 03:35:48PM -0500, Viktor Dukhovni wrote:
> Thanks for the prompt error report.  If you're willing to share your
> test chains, and if it is likely to be not too difficult to include
> them with the OpenSSL bundled tests, that might be worth looking into.

All the test case I use with hostapd/wpa_supplicant hwsim testing are
available in the public git://w1.fi/hostap.git repository under the
tests/hwsim directory. Most cases that are of interest to OpenSSL are in
these files:
http://w1.fi/cgit/hostap/plain/tests/hwsim/test_ap_eap.py
http://w1.fi/cgit/hostap/plain/tests/hwsim/test_suite_b.py

The certificates used in the tests are in this directory:
http://w1.fi/cgit/hostap/tree/tests/hwsim/auth_serv

For the time being, all the certificates are from the repository, but
some of the OCSP responses used in the test cases are created
dynamically when executing the test cases.

> We definitely need more chain verification test cases, and yours failed
> with the unpatched "openssl verify" when used just right:
>
>  $ openssl verify -trusted ca-incorrect.pem -untrusted ca.pem \
>       -purpose sslserver server.pem
>
> The untrusted ca.pem came up trusted incorrectly.  The new DANE-specific
> chain tests are much more comprehensive at this time than the non-DANE
> ones, we'll need to address that before the final release.

Ah, I didn't even think of the possibility of the CA certificate sent by
the server getting trusted, so I just ran openssl verify with -CAfile..

I have been mainly focusing on different areas for
EAP-TLS/TTLS/PEAP/FAST testing, so the number of chain verification
tests that depend on internal OpenSSL functionality is still quite
small. I'm hoping to increase this, but it will take quite a bit of time
and effort to get that done.. I have higher priority on covering the
additional constraints for validation based on the steps that
wpa_supplicant can do on top of the OpenSSL chain validation (e.g.,
checking specific domain suffix and other subject/altsubject
information and OCSP) and handling different formats of certificate and
private key encoding.

Based on a quick search through the test cases, these are the trivial
combinations that can be executed with openssl verify. This assumes the
commands are run within that tests/hwsim/auth_server directory.

OPENSSL=openssl

echo "Should succeed"

$OPENSSL verify -trusted ca.pem -purpose sslserver server.pem
$OPENSSL verify -trusted ca.pem -untrusted ca.pem -purpose sslserver server.pem
$OPENSSL verify -trusted ca.pem -purpose sslclient user.pem
$OPENSSL verify -trusted iCA-user/ca-and-root.pem -untrusted iCA-server/cacert.pem -purpose sslserver iCA-server/server.pem
$OPENSSL verify -trusted iCA-server/ca-and-root.pem -untrusted iCA-user/cacert.pem -purpose sslclient iCA-user/user.pem
$OPENSSL verify -trusted ca.pem -purpose sslserver server-eku-client-server.pem
$OPENSSL verify -trusted ca.pem -purpose sslserver server-long-duration.pem
$OPENSSL verify -trusted sha512-ca.pem -purpose sslserver sha512-server.pem
$OPENSSL verify -trusted sha512-ca.pem -purpose sslserver sha384-server.pem
$OPENSSL verify -trusted sha512-ca.pem -purpose sslclient sha512-user.pem
$OPENSSL verify -trusted sha512-ca.pem -purpose sslclient sha384-user.pem
$OPENSSL verify -trusted ec-ca.pem -purpose sslserver ec-server.pem
$OPENSSL verify -trusted ec-ca.pem -purpose sslclient ec-user.pem
$OPENSSL verify -trusted ec2-ca.pem -purpose sslserver ec2-server.pem
$OPENSSL verify -trusted ec2-ca.pem -purpose sslclient ec2-user.pem

echo "Should fail"

$OPENSSL verify -trusted ca-incorrect.pem -untrusted ca.pem -purpose sslserver server.pem
$OPENSSL verify -trusted ca-incorrect.pem -purpose sslserver server.pem
$OPENSSL verify -trusted ca-incorrect.pem -untrusted ca.pem -purpose sslclient user.pem
$OPENSSL verify -trusted ca-incorrect.pem -purpose sslclient user.pem
$OPENSSL verify -trusted ca.pem -purpose sslserver server-eku-client.pem
$OPENSSL verify -trusted ca.pem -purpose sslserver server-expired.pem

--
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Corinna Vinschen
In reply to this post by Richard Levitte - VMS Whacker-2
On Jan 14 15:44, Richard Levitte wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>    OpenSSL version 1.1.0 pre release 2 (alpha)
>    ===========================================

I tried to build this for Cygwin and got some problems.

First, with 1,0.2, we built the Cygwin package with the options
enable-tlsext and no-krb5.  The 1.1.0 notes mention that Kerberos
ciphersuite support has been removed, so am I right that "no-krb5" just
isn't required anymore?  And what about "enable-tlsext"?  Is that
unchangable default now?

Second, it doesn't build.  I configured as usual for the Cygwin distro
with the following set of options:

  shared zlib enable-camellia enable-seed enable-rfc3779 enable-cms \
  enable-md2 no-idea no-rc5  [omitting enable-tlsext and no-krb5]

The build bailed out with the following error:

gcc [...] -c -o ct_lib.o ct_lib.c
In file included from /usr/include/w32api/windows.h:95:0,
                 from ../../include/openssl/async.h:60,
                 from ../../ssl/ssl_locl.h:166,
                 from ct_lib.c:63:
../../ssl/ssl_locl.h:1110:5: error: expected specifier-qualifier-list before '(' token
     X509_EXTENSIONS *tlsext_ocsp_exts;
     ^
<builtin>: recipe for target 'ct_lib.o' failed

Who had this funny idea to use the Windows definitions when building for
Cygwin?

<pleading>

Please, please, please, Cygwin is a *POSIX* layer.  Please don't use
Windows functions on Cygwin, use POSIX functions and POSIX methods,
*unless* it's really necessary.

And please, if you really think that Cygwin is lacking and you have to
fall back to using Windows stuff, please *ask* first.  It's really not
helpful to use too much native Windows stuff because you're
circumventing Cygwin's POSIX lauer and you might (i.e will)
inadvertently break something in POSIX applications built for Cygwin.

</pleading>

In this case, since Cygwin supports pthreads, why don't you use
async_posix.h, which is the right thing to do on a POSIX system.

While I was looking into this, I also found the snippet in apps/speed.c
which completely breaks Cygwin POSIX-like signal handling by using
native Win32 functions rather than POSIX signal functions.  Please,
please, don't.

Additionally it turned out that the configury used two different
macros to control a Cygwin build for no good reason, OPENSSL_SYS_CYGWIN
and OPENSSL_SYS_WIN32_CYGWIN.

Last but not least, we have a small build problem when building for the
distro:  To build the packages with additional debuginfo packages, the
packages must not be built with the -s option, plus we have to induce a
few options for the sake of creating the debuginfo information.  Up to
1.0.2 we do this by tweaking openssl's build system.  We add an expression
$(OPT_CFLAGS) to the CFLAGS definition for that.  If there's a better,
easier way to do this, I'd be grateful for a hint.

The attached patchset fixes all of the above.  With this,
openssl-1.1.0-pre2 builds fine for Cygwin.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

0001-Use-POSIX-functions-on-Cygwin-not-Win32-function.patch (2K) Download Attachment
0002-Don-t-strip-object-files-on-Cygwin.patch (2K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Corinna Vinschen
On Jan 16 19:37, Corinna Vinschen wrote:

> On Jan 14 15:44, Richard Levitte wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >    OpenSSL version 1.1.0 pre release 2 (alpha)
> >    ===========================================
>
> I tried to build this for Cygwin and got some problems.
> [...]
> The attached patchset fixes all of the above.  With this,
> openssl-1.1.0-pre2 builds fine for Cygwin.
I added another patch to this mail which sets the default CPU for 32 bit
Cygwin builds to i686, as outlined in another mail̀‡.  Cygwin won't run on
older CPUs anyway.  The path depends on the 2nd patch from my previous
mail.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

0003-On-32-bit-Cygwin-build-for-686-CPUs-only.patch (1K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Kurt Roeckx
On Sat, Jan 16, 2016 at 07:42:50PM +0100, Corinna Vinschen wrote:

> On Jan 16 19:37, Corinna Vinschen wrote:
> > On Jan 14 15:44, Richard Levitte wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > >
> > >    OpenSSL version 1.1.0 pre release 2 (alpha)
> > >    ===========================================
> >
> > I tried to build this for Cygwin and got some problems.
> > [...]
> > The attached patchset fixes all of the above.  With this,
> > openssl-1.1.0-pre2 builds fine for Cygwin.
>
> I added another patch to this mail which sets the default CPU for 32 bit
> Cygwin builds to i686, as outlined in another mail.  Cygwin won't run on
> older CPUs anyway.  The path depends on the 2nd patch from my previous
> mail.

Is gcc configure to only produce i686 code on cygwin, and so can
we maybe drop the -march instead?


Kurt

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Corinna Vinschen
On Jan 16 19:59, Kurt Roeckx wrote:

> On Sat, Jan 16, 2016 at 07:42:50PM +0100, Corinna Vinschen wrote:
> > On Jan 16 19:37, Corinna Vinschen wrote:
> > > On Jan 14 15:44, Richard Levitte wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > >
> > > >    OpenSSL version 1.1.0 pre release 2 (alpha)
> > > >    ===========================================
> > >
> > > I tried to build this for Cygwin and got some problems.
> > > [...]
> > > The attached patchset fixes all of the above.  With this,
> > > openssl-1.1.0-pre2 builds fine for Cygwin.
> >
> > I added another patch to this mail which sets the default CPU for 32 bit
> > Cygwin builds to i686, as outlined in another mail.  Cygwin won't run on
> > older CPUs anyway.  The path depends on the 2nd patch from my previous
> > mail.
>
> Is gcc configure to only produce i686 code on cygwin, and so can
> we maybe drop the -march instead?
Oh yes, indeed.  Sorry I missed that :}


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Corinna Vinschen
On Jan 16 20:01, Corinna Vinschen wrote:

> On Jan 16 19:59, Kurt Roeckx wrote:
> > On Sat, Jan 16, 2016 at 07:42:50PM +0100, Corinna Vinschen wrote:
> > > On Jan 16 19:37, Corinna Vinschen wrote:
> > > > On Jan 14 15:44, Richard Levitte wrote:
> > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > Hash: SHA1
> > > > >
> > > > >
> > > > >    OpenSSL version 1.1.0 pre release 2 (alpha)
> > > > >    ===========================================
> > > >
> > > > I tried to build this for Cygwin and got some problems.
> > > > [...]
> > > > The attached patchset fixes all of the above.  With this,
> > > > openssl-1.1.0-pre2 builds fine for Cygwin.
> > >
> > > I added another patch to this mail which sets the default CPU for 32 bit
> > > Cygwin builds to i686, as outlined in another mail.  Cygwin won't run on
> > > older CPUs anyway.  The path depends on the 2nd patch from my previous
> > > mail.
> >
> > Is gcc configure to only produce i686 code on cygwin, and so can
> > we maybe drop the -march instead?
>
> Oh yes, indeed.  Sorry I missed that :}
Here's the changed patch.


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

0003-On-32-bit-Cygwin-build-for-686-CPUs-only.patch (1K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Richard Levitte - VMS Whacker-2
In reply to this post by Corinna Vinschen
In message <[hidden email]> on Sat, 16 Jan 2016 19:37:24 +0100, Corinna Vinschen <[hidden email]> said:

vinschen> Who had this funny idea to use the Windows definitions when building for
vinschen> Cygwin?

I'm afraid that is lost in the thin web of history ;-)

vinschen> <pleading>
vinschen>
vinschen> Please, please, please, Cygwin is a *POSIX* layer.  Please don't use
vinschen> Windows functions on Cygwin, use POSIX functions and POSIX methods,
vinschen> *unless* it's really necessary.
....
vinschen> </pleading>

I hear ya.

vinschen> Last but not least, we have a small build problem when building for the
vinschen> distro:  To build the packages with additional debuginfo packages, the
vinschen> packages must not be built with the -s option, plus we have to induce a
vinschen> few options for the sake of creating the debuginfo information.  Up to
vinschen> 1.0.2 we do this by tweaking openssl's build system.  We add an expression
vinschen> $(OPT_CFLAGS) to the CFLAGS definition for that.  If there's a better,
vinschen> easier way to do this, I'd be grateful for a hint.

OPT_FLAGS would be for optimizing, do I get that right?  I suggest you
have a look at Configurations/10-main.conf, you might notice
configuration items like debug_cflags, release_cflags, debug_lflags
and release_lflags.  If you have a look at my refactor-build branch,
you will see a fairly thorough Configurations/README.  If you look the
commit titled "Refactor config - move templates docs asm templates to
Configurations", you'll find the documentation that's applicable to
what Configure in the master branch supports...  later editions are
currently only supported in my branch.

vinschen> The attached patchset fixes all of the above.  With this,
vinschen> openssl-1.1.0-pre2 builds fine for Cygwin.

I'll have a closer look at all that tomorrow.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Kurt Roeckx
On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote:
> OPT_FLAGS would be for optimizing, do I get that right?  I suggest you
> have a look at Configurations/10-main.conf, you might notice
> configuration items like debug_cflags, release_cflags, debug_lflags
> and release_lflags.  If you have a look at my refactor-build branch,
> you will see a fairly thorough Configurations/README.  If you look the
> commit titled "Refactor config - move templates docs asm templates to
> Configurations", you'll find the documentation that's applicable to
> what Configure in the master branch supports...  later editions are
> currently only supported in my branch.

In Debian we have a system that where you can override things like
the CFLAGS, and I wonder how easy it will be to integrate that
with your new system.

We have a tool called dpkg-buildflags.  By default it now returns:
$ dpkg-buildflags
CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
FCFLAGS=-g -O2 -fstack-protector-strong
FFLAGS=-g -O2 -fstack-protector-strong
GCJFLAGS=-g -O2 -fstack-protector-strong
LDFLAGS=-Wl,-z,relro
OBJCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
OBJCXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security

In the 1.0.2 branch I use this:
my $debian_cflags = `dpkg-buildflags --get CFLAGS` . `dpkg-buildflags --get CPPFLAGS` . `dpkg-buildflags --get LDFLAGS` . "-Wa,--noexecstack -Wall";

And then use $debian_cflags in the targets.

There were was no way to separate clfags/lfdlags, so I needed to
combine it.

dpkg-buildflags can return different things depending on environment variables.
Some examples:
$ DEB_BUILD_OPTIONS=noopt dpkg-buildflags --get CFLAGS
-g -O0 -fstack-protector-strong -Wformat -Werror=format-security

$ DEB_BUILD_OPTIONS=hardening=-all dpkg-buildflags --get CFLAGS
-g -O2

$ DEB_CFLAGS_APPEND=-O3 dpkg-buildflags --get CFLAGS
-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -O3


There are environment variables for both the maintainer to set the
defaults and someone who then wants to build the package with
different settings.

(I should move the -Wa,--noexecstack -Wall to environment
variables.)

Is there an easy way to I can override the flags with
dpkg-buildflags?


Kurt

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL version 1.1.0 pre release 2 published

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Sun, 17 Jan 2016 14:16:04 +0100, Kurt Roeckx <[hidden email]> said:

kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote:
kurt> > OPT_FLAGS would be for optimizing, do I get that right?  I suggest you
kurt> > have a look at Configurations/10-main.conf, you might notice
kurt> > configuration items like debug_cflags, release_cflags, debug_lflags
kurt> > and release_lflags.  If you have a look at my refactor-build branch,
kurt> > you will see a fairly thorough Configurations/README.  If you look the
kurt> > commit titled "Refactor config - move templates docs asm templates to
kurt> > Configurations", you'll find the documentation that's applicable to
kurt> > what Configure in the master branch supports...  later editions are
kurt> > currently only supported in my branch.
kurt>
kurt> In Debian we have a system that where you can override things like
kurt> the CFLAGS, and I wonder how easy it will be to integrate that
kurt> with your new system.
kurt>
kurt> We have a tool called dpkg-buildflags.  By default it now returns:
kurt> $ dpkg-buildflags
kurt> CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
kurt> CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
kurt> CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
kurt> FCFLAGS=-g -O2 -fstack-protector-strong
kurt> FFLAGS=-g -O2 -fstack-protector-strong
kurt> GCJFLAGS=-g -O2 -fstack-protector-strong
kurt> LDFLAGS=-Wl,-z,relro
kurt> OBJCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
kurt> OBJCXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
kurt>
kurt> In the 1.0.2 branch I use this:
kurt> my $debian_cflags = `dpkg-buildflags --get CFLAGS` . `dpkg-buildflags --get CPPFLAGS` . `dpkg-buildflags --get LDFLAGS` . "-Wa,--noexecstack -Wall";
kurt>
kurt> And then use $debian_cflags in the targets.
kurt>
kurt> There were was no way to separate clfags/lfdlags, so I needed to
kurt> combine it.
kurt>
kurt> dpkg-buildflags can return different things depending on environment variables.
kurt> Some examples:
kurt> $ DEB_BUILD_OPTIONS=noopt dpkg-buildflags --get CFLAGS
kurt> -g -O0 -fstack-protector-strong -Wformat -Werror=format-security
kurt>
kurt> $ DEB_BUILD_OPTIONS=hardening=-all dpkg-buildflags --get CFLAGS
kurt> -g -O2
kurt>
kurt> $ DEB_CFLAGS_APPEND=-O3 dpkg-buildflags --get CFLAGS
kurt> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -O3
kurt>
kurt>
kurt> There are environment variables for both the maintainer to set the
kurt> defaults and someone who then wants to build the package with
kurt> different settings.
kurt>
kurt> (I should move the -Wa,--noexecstack -Wall to environment
kurt> variables.)
kurt>
kurt> Is there an easy way to I can override the flags with
kurt> dpkg-buildflags?

I see where you're going with this.

As it is right now, there is no way to affect Configure via the
environment, except for the names of certain commands.  Personally,
I'd say that using those should be done carefully.  I have no plans to
expand on the use of environment variables...

However, there is always the possibility to quickly write up a small
config target for yourself in Configurations, and have them inherit
the items for an already existing target.  For example:

    cflags=` ... dpkg-buildflags --get CFLAGS`; \
    cat <<EOF > Configurations/01-debian-tmp.conf
    %targets = (
        "debian-linux-x86_64" => {
            inherit_from => [ "linux-x86_64" ],
            cflags       => "$cflags",
        }
    );
    1;
    EOF

If you want to just append or prepend your flags, you do this with the
cflags item:

            cflags       => sub { join(" ", $@, "$cflags"); },

In my refactor-build branch, I've added some lazy functions to do the
same:

            cflags       => add("$cflags"),

or

            cflags       => add_before("$cflags"),  # to prepend

Did that help?

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
12