From rt at openssl.org  Fri Jul  1 23:31:45 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Fri, 01 Jul 2016 23:31:45 +0000
Subject: [openssl-dev] [openssl.org #4598] OpenSSL fails to Configure on
	Windows 10
In-Reply-To: <CAH8yC8kKwsME2cTZFqyUvecG3RCp3PkrtUwk-rBW4xvMMJSHXw@mail.gmail.com>
References: <RT-Ticket-4598@openssl.org>
 <CAH8yC8n+9K+e8WZYES18LRVxMsKAT-sfpXMG_PKGK_-jSRSncw@mail.gmail.com>
 <rt-4.0.19-16125-1467235177-821.4598-6-0@openssl.org>
 <CAH8yC8kKwsME2cTZFqyUvecG3RCp3PkrtUwk-rBW4xvMMJSHXw@mail.gmail.com>
Message-ID: <rt-4.0.19-24181-1467415905-528.4598-6-0@openssl.org>

On Wed, Jun 29, 2016 at 5:19 PM, Richard Levitte via RT <rt at openssl.org> wrote:
> This has nothing to do with Windows 10 per se, it's the space-in-directory
> issue that's come back.
> I'm working on a solution that should avoid that problem more consistently,
> going forward.

Close it; its good as of fe964f0c88f6780fd30b26e306484b981b0a8480.

All self tests passed Files=81, Tests=396).

Jeff


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4598
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul  1 23:34:23 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 01 Jul 2016 23:34:23 +0000
Subject: [openssl-dev] [openssl.org #4598] OpenSSL fails to Configure on
	Windows 10
In-Reply-To: <rt-4.0.19-24181-1467415905-288.4598-6-0@openssl.org>
References: <RT-Ticket-4598@openssl.org>
 <CAH8yC8n+9K+e8WZYES18LRVxMsKAT-sfpXMG_PKGK_-jSRSncw@mail.gmail.com>
 <rt-4.0.19-16125-1467235177-821.4598-6-0@openssl.org>
 <CAH8yC8kKwsME2cTZFqyUvecG3RCp3PkrtUwk-rBW4xvMMJSHXw@mail.gmail.com>
 <rt-4.0.19-24181-1467415905-288.4598-6-0@openssl.org>
Message-ID: <rt-4.0.19-24181-1467416063-271.4598-6-0@openssl.org>

On Fri Jul 01 23:31:45 2016, noloader at gmail.com wrote:
> On Wed, Jun 29, 2016 at 5:19 PM, Richard Levitte via RT
> <rt at openssl.org> wrote:
> > This has nothing to do with Windows 10 per se, it's the space-in-
> > directory
> > issue that's come back.
> > I'm working on a solution that should avoid that problem more
> > consistently,
> > going forward.
>
> Close it; its good as of fe964f0c88f6780fd30b26e306484b981b0a8480.

Done

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4598
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul  2 10:59:38 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Sat, 02 Jul 2016 10:59:38 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160702105929.GA9192@roeckx.be>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
Message-ID: <rt-4.0.19-24181-1467457178-1784.4602-21-0@openssl.org>

Hi,

I received the following bug in debian:
https://bugs.debian.org/829272


I got a lot of bugs filed about packages FTBFS with openssl 1.1.0.
I started to look at some of them, and many of them are due too
structures having been made opaque. In many cases accessors already
exists, but definitely not for all.

Here is a list of accessors I so far have identified as missing. The
filenames given in the "Add to ..." comments below are suggestions
based on where similar functions are defined and implemented.


/* Add to include/openssl/x509_vfy.h : */

typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX *ctx, X509 *x);
typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509 *x, X509 *issuer);

void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
                                   X509_STORE_CTX_get_issuer get_issuer);
X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX *ctx);
void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
                                     X509_STORE_CTX_check_issued check_issued);
X509_STORE_CTX_check_issued X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);


/* Add to crypto/x509/x509_vfy.c : */

void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
                                   X509_STORE_CTX_get_issuer get_issuer)
{
    ctx->get_issuer = get_issuer;
}

X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX *ctx)
{
    return ctx->get_issuer;
}

void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
                                     X509_STORE_CTX_check_issued check_issued)
{
    ctx->check_issued = check_issued;
}

X509_STORE_CTX_check_issued X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx)
{
    return ctx->check_issued;
}


/* Add to include/openssl/x509v3.h */

void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);


/* Add to crypto/x509v3/v3_purp.c */

void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
{
    x->ex_flags |= ex_flags;
}

void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
{
    x->ex_flags &= ~ex_flags;
}


Regarding the new locking. Do I understand it correctly that e.g.

  CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);

should be replaced by something like

  CRYPTO_THREAD_write_lock(X509_STORE_get_lock(ctx));

But then the accessors to get hold of the lock objects in the opaque
structs are missing. E.g.

/* Add to some header file */

CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *ctx);

/* Add to some implementation file */

/* Add to crypto/x509/x509_lu.c */

CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *v)
{
    return v->lock;
}

Repeat for other relevant classes with locks.

	Mattias


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul  2 11:13:45 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Sat, 02 Jul 2016 11:13:45 +0000
Subject: [openssl-dev] [openssl.org #4603] HMAC_Init_ex incompatible change
	(possibly doc bug)
In-Reply-To: <20160702111340.GC9192@roeckx.be>
References: <RT-Ticket-4603@openssl.org> <20160702111340.GC9192@roeckx.be>
Message-ID: <rt-4.0.19-24183-1467458024-1781.4603-21-0@openssl.org>

Hi,

I received the following bug:
https://bugs.debian.org/829108

the HMAC manpage states:

   HMAC_Init_ex() initializes or reuses a HMAC_CTX structure to use the
   function evp_md and key key. Either can be NULL, in which case the
   existing one will be reused.

However, the current code does not allow the key to be zero when evp_md is
non-zero in all cases:

    /* If we are changing MD then we must have a key */
    if (md != NULL && md != ctx->md && (key == NULL || len < 0))
        return 0;

That means contrary to the documentation, the existing salt isn't reused
when the md argument is non-zero (and changes).

The issue is corrobated by the fact that HMAC_init_ex only relatively
recently gained a status return, so older programs won't check the return
value and will continue on, getting wrong results.

This particular line was introduced with this change:

https://github.com/openssl/openssl/commit/4b464e7b46682f568a5df550426b0cf4b22e2485

Although I don't know whether this just reworks the logic or introduces
the problem in the first place.

One program that might to be affected is GVPE - I opened a bug report
about it no longer working, although I can't find it at the moment. It
is possible (but not certain) that this is the reason for it no longer
working. Even though GVPE has had return code checking, due to a glitch
it wasn't enabled before openssl 1.1.0, so would not trigger with 1.0.x
builds.

So, either:

a) this is an incompatible and unintended change. in this case, there is potential
   for programs silently failing to compute correct hmacs now.
b) this is an incompatible but intended change, in which case this is a documentation
   bug.
c) this is not an incompatible recent change, in which case the logic always
   was like this but was reworked. in this case it is a documentation bug as well.
d) it is intended behaviour and the previous behaviour
   wasn't correct (e.g. it didn't reuse the key, but did something else).
   also a documentation bug in this case.

If this is an unintended behaviour change, maybe the large scale API
breakage in 1.1.0 would be a good moment to also rename HMAC_init_ex, so
programs have a chance to adaot.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4603
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul  4 23:40:25 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Mon, 04 Jul 2016 23:40:25 +0000
Subject: [openssl-dev] [openssl.org #4604] Missing includes for ARM on
	Android
In-Reply-To: <CAH8yC8=MF92U7wOcahd0nEKz4Q8RnbFoELfFSv5HcORdVnK0_w@mail.gmail.com>
References: <RT-Ticket-4604@openssl.org>
 <CAH8yC8=MF92U7wOcahd0nEKz4Q8RnbFoELfFSv5HcORdVnK0_w@mail.gmail.com>
Message-ID: <rt-4.0.19-30004-1467675625-216.4604-21-0@openssl.org>

>From http://stackoverflow.com/q/38192458/608639:

jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
OPENSSL_cpuid_setup: error: undefined reference to 'sigfillset'
jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
jni/openssl/lib/armeabi-v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
open_console: error: undefined reference to 'tcgetattr'
jni/openssl/lib/armeabi-v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
read_string_inner: error: undefined reference to 'signal'
jni/openssl/lib/armeabi-v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
read_string_inner: error: undefined reference to 'tcsetattr'
jni/openssl/lib/armeabi-v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
read_string_inner: error: undefined reference to 'tcsetattr'
collect2: error: ld returned 1 exit status
make[1]: *** [obj/local/armeabi-v7a/libpjsipjni.so] Error 1
make[1]: *** Waiting for unfinished jobs....
jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
open_console: error: undefined reference to 'tcgetattr'
jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
read_string_inner: error: undefined reference to 'signal'
jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
read_string_inner: error: undefined reference to 'tcsetattr'
jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
read_string_inner: error: undefined reference to 'tcsetattr'
collect2: error: ld returned 1 exit status
make[1]: *** [obj/local/armeabi/libpjsipjni.so] Error 1
jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
open_console: error: undefined reference to 'tcgetattr'
jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
read_string_inner: error: undefined reference to 'signal'
jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
read_string_inner: error: undefined reference to 'tcsetattr'
jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
read_string_inner: error: undefined reference to 'tcsetattr'
collect2: error: ld returned 1 exit status
make[1]: *** [obj/local/x86/libpjsipjni.so] Error 1
jni/openssl/lib/mips/libcrypto.a(ui_openssl.o): In function `open_console':
ui_openssl.c:(.text.open_console+0xb4): undefined reference to `tcgetattr'
jni/openssl/lib/mips/libcrypto.a(ui_openssl.o): In function `read_string_inner':
ui_openssl.c:(.text.read_string_inner+0xf0): undefined reference to `signal'
ui_openssl.c:(.text.read_string_inner+0x2c0): undefined reference to `tcsetattr'
ui_openssl.c:(.text.read_string_inner+0x39c): undefined reference to `tcsetattr'
collect2: error: ld returned 1 exit status


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4604
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul  4 23:53:06 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 04 Jul 2016 23:53:06 +0000
Subject: [openssl-dev] [openssl.org #4604] Missing includes for ARM on
	Android
In-Reply-To: <CAH8yC8=MF92U7wOcahd0nEKz4Q8RnbFoELfFSv5HcORdVnK0_w@mail.gmail.com>
References: <RT-Ticket-4604@openssl.org>
 <CAH8yC8=MF92U7wOcahd0nEKz4Q8RnbFoELfFSv5HcORdVnK0_w@mail.gmail.com>
Message-ID: <rt-4.0.19-29976-1467676386-866.4604-6-0@openssl.org>

What part of this is a bug in OpenSSL proper?

To me it looks like the classic issue when linking with static libraries, that
you have to explicitely specify the libraries that libcrypto and libssl depend
on.

Cheers,
Richard

On Mon Jul 04 23:40:25 2016, noloader at gmail.com wrote:
> From http://stackoverflow.com/q/38192458/608639:
>
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigfillset'
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
> jni/openssl/lib/armeabi-
> v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> open_console: error: undefined reference to 'tcgetattr'
> jni/openssl/lib/armeabi-
> v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'signal'
> jni/openssl/lib/armeabi-
> v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> jni/openssl/lib/armeabi-
> v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> collect2: error: ld returned 1 exit status
> make[1]: *** [obj/local/armeabi-v7a/libpjsipjni.so] Error 1
> make[1]: *** Waiting for unfinished jobs....
> jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> open_console: error: undefined reference to 'tcgetattr'
> jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'signal'
> jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> collect2: error: ld returned 1 exit status
> make[1]: *** [obj/local/armeabi/libpjsipjni.so] Error 1
> jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> open_console: error: undefined reference to 'tcgetattr'
> jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'signal'
> jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> collect2: error: ld returned 1 exit status
> make[1]: *** [obj/local/x86/libpjsipjni.so] Error 1
> jni/openssl/lib/mips/libcrypto.a(ui_openssl.o): In function
> `open_console':
> ui_openssl.c:(.text.open_console+0xb4): undefined reference to
> `tcgetattr'
> jni/openssl/lib/mips/libcrypto.a(ui_openssl.o): In function
> `read_string_inner':
> ui_openssl.c:(.text.read_string_inner+0xf0): undefined reference to
> `signal'
> ui_openssl.c:(.text.read_string_inner+0x2c0): undefined reference to
> `tcsetattr'
> ui_openssl.c:(.text.read_string_inner+0x39c): undefined reference to
> `tcsetattr'
> collect2: error: ld returned 1 exit status


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4604
Please log in as guest with password guest if prompted


From brian at briansmith.org  Tue Jul  5 01:25:43 2016
From: brian at briansmith.org (Brian Smith)
Date: Mon, 4 Jul 2016 15:25:43 -1000
Subject: [openssl-dev] ecp_nistz256 is_one is too liberal with what it
	considers to be one
Message-ID: <CAFewVt4h37KcB0sG4ZeGUiOvj0=8HezVus=vDxcfGHtkJd6xkw@mail.gmail.com>

Please see the attached program and consider the following change:

```
   if (P256_LIMBS == 8) {
     res |= a[4] ^ ONE[4];
     res |= a[5] ^ ONE[5];
     res |= a[6] ^ ONE[6];
+    res |= a[7] ^ ONE[7];
   }
```

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160704/aa6d5cd8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: is_one.c
Type: text/x-csrc
Size: 1090 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160704/aa6d5cd8/attachment-0001.c>

From nikhil.agarwal at nxp.com  Tue Jul  5 10:28:36 2016
From: nikhil.agarwal at nxp.com (Nikhil Agarwal)
Date: Tue, 5 Jul 2016 10:28:36 +0000
Subject: [openssl-dev] Auth and cipher ordering in AEAD ciphers
Message-ID: <DB5PR04MB1655C682020539784D2B9D2293390@DB5PR04MB1655.eurprd04.prod.outlook.com>

For AEAD ciphers like NID_aes_128_cbc_hmac_sha1,  I could not find any control interface defined to control authentication and cipher ordering.(i.e. whether to perform cipher first and then authentication or vice versa.(IPSEC vs. TLS use-case)).  If such an interface exist with OPENSSL can someone please help me in pointing that out? If no, is there any plan to introduce it? Also is there any interface for to specify difference packet range/length for cipher in Auth in AEAD case?

Thanks in advance
Nikhil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160705/629bc505/attachment.html>

From rt at openssl.org  Tue Jul  5 13:33:31 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Tue, 05 Jul 2016 13:33:31 +0000
Subject: [openssl-dev] [openssl.org #4605] OCSP accessors
In-Reply-To: <20160705133323.GA31096@roeckx.be>
References: <RT-Ticket-4605@openssl.org> <20160705133323.GA31096@roeckx.be>
Message-ID: <rt-4.0.19-29976-1467725611-1361.4605-21-0@openssl.org>

In https://bugs.debian.org/828254, for the software "bro"

I got a request for accessors to:
- For OCSP_RESPID *rid:
  - rid->type
  - rid->value.byKey->length
  - rid->value.byKey->data


- For OCSP_BASICRESP *basic:
  - basic->certs
  - basic->tbsResponseData->responderId


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4605
Please log in as guest with password guest if prompted


From tshort at akamai.com  Tue Jul  5 14:59:48 2016
From: tshort at akamai.com (Short, Todd)
Date: Tue, 5 Jul 2016 14:59:48 +0000
Subject: [openssl-dev] Auth and cipher ordering in AEAD ciphers
In-Reply-To: <DB5PR04MB1655C682020539784D2B9D2293390@DB5PR04MB1655.eurprd04.prod.outlook.com>
References: <DB5PR04MB1655C682020539784D2B9D2293390@DB5PR04MB1655.eurprd04.prod.outlook.com>
Message-ID: <D865C520-A64D-46F1-BD01-DCF40F522C31@akamai.com>

AEAD ciphers within OpenSSL include AES-GCM, AES-CCM and ChaCha20-Poly1305 (among others). AES-128 CBC SHA1-HMAC is not considered AEAD.

See https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption for examples.

The ciphers as described below are meant for TLS, thus they do MAC-then-Encrypt (MtE), although there is an EtM TLS extension.

You will need to use either individual crypto operations to do what you want, if the combinations offered by OpenSSL differ from the standards (e.g. IPSec) that you need to follow.

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Jul 5, 2016, at 6:28 AM, Nikhil Agarwal <nikhil.agarwal at nxp.com<mailto:nikhil.agarwal at nxp.com>> wrote:

For AEAD ciphers like NID_aes_128_cbc_hmac_sha1,  I could not find any control interface defined to control authentication and cipher ordering.(i.e. whether to perform cipher first and then authentication or vice versa.(IPSEC vs. TLS use-case)).  If such an interface exist with OPENSSL can someone please help me in pointing that out? If no, is there any plan to introduce it? Also is there any interface for to specify difference packet range/length for cipher in Auth in AEAD case?

Thanks in advance
Nikhil

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160705/7c41e16e/attachment.html>

From jonetsu at teksavvy.com  Tue Jul  5 16:42:39 2016
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 05 Jul 2016 12:42:39 -0400
Subject: [openssl-dev] FIPS: AES CTR KAT tests
Message-ID: <1aae3b059a246a4f4fd5962f70dffa47@teksavvy.com>

Hello,

I am looking for the selftests, the KAT tests, for AES CTR and CBC in openssl_fips 2.0.9.

Although many tests are directly defined, such as:

? FIPS_selftest_aes_gcm(void) in aes/fips_aes_selftest.c 

? gcmtest(FILE *in, FILE *out, int encrypt) in ../aes/fips_gcmtest.c

? And for CBC:

? static int AESTest(...) in aes/fips_aesavs.c

I did not find any tests for AES CTR.? Is AES CTR tested at all ?

Thanks.? Help would be appreciated.





From rt at openssl.org  Tue Jul  5 18:28:51 2016
From: rt at openssl.org (Noel Carboni via RT)
Date: Tue, 05 Jul 2016 18:28:51 +0000
Subject: [openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in
	OpenSSL RAND_poll() Is Ineffective
In-Reply-To: <004e01d1d6db$d511f200$7f35d600$@ProDigitalSoftware.com>
References: <RT-Ticket-4606@openssl.org>
 <004e01d1d6db$d511f200$7f35d600$@ProDigitalSoftware.com>
Message-ID: <rt-4.0.19-30004-1467743331-1441.4606-21-0@openssl.org>

This message is to the OpenSSL source code maintainers via
rt at openssl.org:

I reported this a while back and no one has seen fit to fix it.

On Windows, the RAND_poll() function in the OpenSSL library uses ancient
Heap32First and Heap32Next function calls to enumerate heap entries from
all processes, because presumably this is considered to be a good source
of entropy.

Unfortunately, these specific methods, because of things that have been
changed in Windows since the original design of the OpenSSL library, are
now so tremendously inefficient that you are actually getting nearly
zero entropy, as well as wasting a huge amount of computer time.

We're measuring the time to get to the VERY FIRST check of the MAXDELAY
operation - i.e., exactly ONE heap block has been read - as over one
half second, and that's on a fast machine!

The reason is described clearly here:

https://blogs.msdn.microsoft.com/oldnewthing/20120323-00/?p=8023

In short, on a Windows 7 or newer system OpenSSL is spending a full
second before the timeout occurs gathering one or maybe a very few heap
blocks to contribute a few bytes of entropy to the random seed.

What that article says is that the Heap32First and Heap32Next are NO
LONGER VALID FUNCTIONS on Windows to be used for the purpose of
gathering entropy!  You're not really walking many entries at all and
thus you are not getting the entropy you think you are.

Various software packages use your library and expect it to initialize
its own random seed effectively, which it is NOT doing.  Instead, it's
spending a full second spinning Windows' wheels behind the scenes and
quite possibly even disrupting other operations, for ALMOST NO BENEFIT
in entropy gathering.  I cannot stress this enough.

If you believe this should be worked-around by seeding the library
directly, or by building an alternate copy of the library oneself,
please bear this in mind:

Not everyone who ultimately uses OpenSSL has control over how OpenSSL is
being initialized.

Imagine, for example, that the OpenSSL library is embedded in another,
higher-level library, and that the product using the higher-level
library has NO DIRECT EXPOSURE to OpenSSL.  This, in fact, is the case
with our own software.  Every startup of our software, which we expect
to be interactive, takes MUCH longer than it should - a significant
portion of one second - because of this bug.

Also, if you think that the MAXDELAY parameter should be shortened, that
is not valid either.  You should understand that even the first check of
that timeout is delayed by a significant portion of a second!

This needs to be fixed!
-Noel Carboni
ProDigital Software

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted


From xoloki at gmail.com  Tue Jul  5 18:33:10 2016
From: xoloki at gmail.com (Joey Yandle)
Date: Tue, 5 Jul 2016 11:33:10 -0700
Subject: [openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in
 OpenSSL RAND_poll() Is Ineffective
In-Reply-To: <rt-4.0.19-30004-1467743331-1441.4606-21-0@openssl.org>
References: <RT-Ticket-4606@openssl.org>
 <004e01d1d6db$d511f200$7f35d600$@ProDigitalSoftware.com>
 <rt-4.0.19-30004-1467743331-1441.4606-21-0@openssl.org>
Message-ID: <CADpq_qvZu7e__mX7vUD0FLrfQ2GXexfvav_m8-d=nw7tMherBg@mail.gmail.com>

This is fixed in 1.1.

On Jul 5, 2016 11:29 AM, "Noel Carboni via RT" <rt at openssl.org> wrote:

> This message is to the OpenSSL source code maintainers via
> rt at openssl.org:
>
> I reported this a while back and no one has seen fit to fix it.
>
> On Windows, the RAND_poll() function in the OpenSSL library uses ancient
> Heap32First and Heap32Next function calls to enumerate heap entries from
> all processes, because presumably this is considered to be a good source
> of entropy.
>
> Unfortunately, these specific methods, because of things that have been
> changed in Windows since the original design of the OpenSSL library, are
> now so tremendously inefficient that you are actually getting nearly
> zero entropy, as well as wasting a huge amount of computer time.
>
> We're measuring the time to get to the VERY FIRST check of the MAXDELAY
> operation - i.e., exactly ONE heap block has been read - as over one
> half second, and that's on a fast machine!
>
> The reason is described clearly here:
>
> https://blogs.msdn.microsoft.com/oldnewthing/20120323-00/?p=8023
>
> In short, on a Windows 7 or newer system OpenSSL is spending a full
> second before the timeout occurs gathering one or maybe a very few heap
> blocks to contribute a few bytes of entropy to the random seed.
>
> What that article says is that the Heap32First and Heap32Next are NO
> LONGER VALID FUNCTIONS on Windows to be used for the purpose of
> gathering entropy!  You're not really walking many entries at all and
> thus you are not getting the entropy you think you are.
>
> Various software packages use your library and expect it to initialize
> its own random seed effectively, which it is NOT doing.  Instead, it's
> spending a full second spinning Windows' wheels behind the scenes and
> quite possibly even disrupting other operations, for ALMOST NO BENEFIT
> in entropy gathering.  I cannot stress this enough.
>
> If you believe this should be worked-around by seeding the library
> directly, or by building an alternate copy of the library oneself,
> please bear this in mind:
>
> Not everyone who ultimately uses OpenSSL has control over how OpenSSL is
> being initialized.
>
> Imagine, for example, that the OpenSSL library is embedded in another,
> higher-level library, and that the product using the higher-level
> library has NO DIRECT EXPOSURE to OpenSSL.  This, in fact, is the case
> with our own software.  Every startup of our software, which we expect
> to be interactive, takes MUCH longer than it should - a significant
> portion of one second - because of this bug.
>
> Also, if you think that the MAXDELAY parameter should be shortened, that
> is not valid either.  You should understand that even the first check of
> that timeout is delayed by a significant portion of a second!
>
> This needs to be fixed!
> -Noel Carboni
> ProDigital Software
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160705/f8903a6f/attachment.html>

From rt at openssl.org  Tue Jul  5 18:33:19 2016
From: rt at openssl.org (Joey Yandle via RT)
Date: Tue, 05 Jul 2016 18:33:19 +0000
Subject: [openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in
	OpenSSL RAND_poll() Is Ineffective
In-Reply-To: <CADpq_qvZu7e__mX7vUD0FLrfQ2GXexfvav_m8-d=nw7tMherBg@mail.gmail.com>
References: <RT-Ticket-4606@openssl.org>
 <004e01d1d6db$d511f200$7f35d600$@ProDigitalSoftware.com>
 <rt-4.0.19-30004-1467743331-1441.4606-21-0@openssl.org>
 <CADpq_qvZu7e__mX7vUD0FLrfQ2GXexfvav_m8-d=nw7tMherBg@mail.gmail.com>
Message-ID: <rt-4.0.19-29976-1467743599-267.4606-6-0@openssl.org>

This is fixed in 1.1.

On Jul 5, 2016 11:29 AM, "Noel Carboni via RT" <rt at openssl.org> wrote:

> This message is to the OpenSSL source code maintainers via
> rt at openssl.org:
>
> I reported this a while back and no one has seen fit to fix it.
>
> On Windows, the RAND_poll() function in the OpenSSL library uses ancient
> Heap32First and Heap32Next function calls to enumerate heap entries from
> all processes, because presumably this is considered to be a good source
> of entropy.
>
> Unfortunately, these specific methods, because of things that have been
> changed in Windows since the original design of the OpenSSL library, are
> now so tremendously inefficient that you are actually getting nearly
> zero entropy, as well as wasting a huge amount of computer time.
>
> We're measuring the time to get to the VERY FIRST check of the MAXDELAY
> operation - i.e., exactly ONE heap block has been read - as over one
> half second, and that's on a fast machine!
>
> The reason is described clearly here:
>
> https://blogs.msdn.microsoft.com/oldnewthing/20120323-00/?p=8023
>
> In short, on a Windows 7 or newer system OpenSSL is spending a full
> second before the timeout occurs gathering one or maybe a very few heap
> blocks to contribute a few bytes of entropy to the random seed.
>
> What that article says is that the Heap32First and Heap32Next are NO
> LONGER VALID FUNCTIONS on Windows to be used for the purpose of
> gathering entropy!  You're not really walking many entries at all and
> thus you are not getting the entropy you think you are.
>
> Various software packages use your library and expect it to initialize
> its own random seed effectively, which it is NOT doing.  Instead, it's
> spending a full second spinning Windows' wheels behind the scenes and
> quite possibly even disrupting other operations, for ALMOST NO BENEFIT
> in entropy gathering.  I cannot stress this enough.
>
> If you believe this should be worked-around by seeding the library
> directly, or by building an alternate copy of the library oneself,
> please bear this in mind:
>
> Not everyone who ultimately uses OpenSSL has control over how OpenSSL is
> being initialized.
>
> Imagine, for example, that the OpenSSL library is embedded in another,
> higher-level library, and that the product using the higher-level
> library has NO DIRECT EXPOSURE to OpenSSL.  This, in fact, is the case
> with our own software.  Every startup of our software, which we expect
> to be interactive, takes MUCH longer than it should - a significant
> portion of one second - because of this bug.
>
> Also, if you think that the MAXDELAY parameter should be shortened, that
> is not valid either.  You should understand that even the first check of
> that timeout is delayed by a significant portion of a second!
>
> This needs to be fixed!
> -Noel Carboni
> ProDigital Software
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul  5 19:00:25 2016
From: rt at openssl.org (John Denker via RT)
Date: Tue, 05 Jul 2016 19:00:25 +0000
Subject: [openssl-dev] [openssl.org #4607] improve quietness for s_client
	... also documentation for s_client + s_server
In-Reply-To: <577C03BD.3070602@av8n.com>
References: <RT-Ticket-4607@openssl.org> <577C03BD.3070602@av8n.com>
Message-ID: <rt-4.0.19-30004-1467745225-249.4607-21-0@openssl.org>

Hi --

Attached are four simple patches.
They make the apps more usable.
They should be pretty much self-explanatory.
Let me know if you have questions.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4607
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-make-s_client-more-quiet-when-quiet-is-specified.patch
Type: text/x-patch
Size: 1243 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160705/0b61dd38/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-when-a-write-to-stdout-has-failed-sending-a-message-.patch
Type: text/x-patch
Size: 1012 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160705/0b61dd38/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-document-the-verify_quiet-option-to-s_client.patch
Type: text/x-patch
Size: 2360 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160705/0b61dd38/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-document-the-verify_quiet-option-to-s_server.patch
Type: text/x-patch
Size: 2261 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160705/0b61dd38/attachment-0003.bin>

From rt at openssl.org  Tue Jul  5 21:42:41 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 05 Jul 2016 21:42:41 +0000
Subject: [openssl-dev] [openssl.org #4607] improve quietness for s_client
	... also documentation for s_client + s_server
In-Reply-To: <577C03BD.3070602@av8n.com>
References: <RT-Ticket-4607@openssl.org> <577C03BD.3070602@av8n.com>
Message-ID: <rt-4.0.19-30004-1467754961-1720.4607-6-0@openssl.org>

this is for 1.0.2, right?

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4607
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul  5 22:01:49 2016
From: rt at openssl.org (Noel Carboni via RT)
Date: Tue, 05 Jul 2016 22:01:49 +0000
Subject: [openssl-dev] [openssl.org #4606] Resolved: BUG: Windows
	Startup Code in OpenSSL RAND_poll() Is Ineffective
In-Reply-To: <006a01d1d704$9310ae40$b9320ac0$@ProDigitalSoftware.com>
References: <RT-Ticket-4606@openssl.org>
 <rt-4.0.19-30004-1467754064-1182.4606-10-0@openssl.org>
 <006a01d1d704$9310ae40$b9320ac0$@ProDigitalSoftware.com>
Message-ID: <rt-4.0.19-29976-1467756109-797.4606-6-0@openssl.org>

Joey Yandle replied that it would be resolved in 1.1, but I don't see how. 
The offending function calls are still there in the latest 1.1 beta source 
set I could find to download.

The whole section of code is gone from the current source from Github, but 
what version that will go into isn't clear.

-Noel

-----Original Message-----
From: Rich Salz via RT [mailto:rt at openssl.org]
Sent: Tue, July 5, 2016 5:28 PM
To: NCarboni at ProDigitalSoftware.com
Subject: [openssl.org #4606] Resolved: BUG: Windows Startup Code in 
OpenSSL RAND_poll() Is Ineffective

According to our records, your request has been resolved. If you have any 
further questions or concerns, please respond to this message.

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted


From rsalz at akamai.com  Tue Jul  5 22:03:42 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 5 Jul 2016 22:03:42 +0000
Subject: [openssl-dev] [openssl.org #4606] Resolved: BUG:
 Windows	Startup Code in OpenSSL RAND_poll() Is Ineffective
In-Reply-To: <rt-4.0.19-29976-1467756109-797.4606-6-0@openssl.org>
References: <RT-Ticket-4606@openssl.org>
 <rt-4.0.19-30004-1467754064-1182.4606-10-0@openssl.org>
 <006a01d1d704$9310ae40$b9320ac0$@ProDigitalSoftware.com>
 <rt-4.0.19-29976-1467756109-797.4606-6-0@openssl.org>
Message-ID: <eef6a1b43e6a4390ba5a0e72d2c7e8eb@usma1ex-dag1mb1.msg.corp.akamai.com>

I don't know what 1.1 beta source you downloaded.  The code on GitHub is the latest version of what will be 1.1  It *is* fixed, just later than the version you downloaded.



From rt at openssl.org  Tue Jul  5 22:03:46 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Tue, 05 Jul 2016 22:03:46 +0000
Subject: [openssl-dev] [openssl.org #4606] Resolved: BUG: Windows
	Startup Code in OpenSSL RAND_poll() Is Ineffective
In-Reply-To: <eef6a1b43e6a4390ba5a0e72d2c7e8eb@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4606@openssl.org>
 <rt-4.0.19-30004-1467754064-1182.4606-10-0@openssl.org>
 <006a01d1d704$9310ae40$b9320ac0$@ProDigitalSoftware.com>
 <rt-4.0.19-29976-1467756109-797.4606-6-0@openssl.org>
 <eef6a1b43e6a4390ba5a0e72d2c7e8eb@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-29976-1467756226-1935.4606-6-0@openssl.org>

I don't know what 1.1 beta source you downloaded.  The code on GitHub is the latest version of what will be 1.1  It *is* fixed, just later than the version you downloaded.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul  5 22:38:44 2016
From: rt at openssl.org (Noel Carboni via RT)
Date: Tue, 05 Jul 2016 22:38:44 +0000
Subject: [openssl-dev] [openssl.org #4606] Resolved: BUG: Windows
	Startup Code in OpenSSL RAND_poll() Is Ineffective
In-Reply-To: <006b01d1d709$91197fe0$b34c7fa0$@ProDigitalSoftware.com>
References: <RT-Ticket-4606@openssl.org>
 <rt-4.0.19-30004-1467754064-1182.4606-10-0@openssl.org>
 <006a01d1d704$9310ae40$b9320ac0$@ProDigitalSoftware.com>
 <rt-4.0.19-29976-1467756109-797.4606-6-0@openssl.org>
 <eef6a1b43e6a4390ba5a0e72d2c7e8eb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-29976-1467756226-1935.4606-6-0@openssl.org>
 <006b01d1d709$91197fe0$b34c7fa0$@ProDigitalSoftware.com>
Message-ID: <rt-4.0.19-29976-1467758324-26.4606-6-0@openssl.org>

OK, thanks.

> The code on GitHub is the latest version of what will be 1.1

Knowing that made all the difference, thank you.  It wasn't clear since 
there's some evidence of "2.0" in the various downloads.

-Noel
-----Original Message-----
From: Salz, Rich via RT [mailto:rt at openssl.org]
Sent: Tue, July 5, 2016 6:04 PM
To: NCarboni at ProDigitalSoftware.com
Cc: openssl-dev at openssl.org
Subject: RE: [openssl-dev] [openssl.org #4606] Resolved: BUG: Windows 
Startup Code in OpenSSL RAND_poll() Is Ineffective

I don't know what 1.1 beta source you downloaded.  The code on GitHub is 
the latest version of what will be 1.1  It *is* fixed, just later than the 
version you downloaded.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul  5 22:46:49 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 05 Jul 2016 22:46:49 +0000
Subject: [openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in
	OpenSSL RAND_poll() Is Ineffective
In-Reply-To: <rt-4.0.19-29976-1467758324-158.4606-6-0@openssl.org>
References: <RT-Ticket-4606@openssl.org>
 <rt-4.0.19-30004-1467754064-1182.4606-10-0@openssl.org>
 <006a01d1d704$9310ae40$b9320ac0$@ProDigitalSoftware.com>
 <rt-4.0.19-29976-1467756109-797.4606-6-0@openssl.org>
 <eef6a1b43e6a4390ba5a0e72d2c7e8eb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-29976-1467756226-1935.4606-6-0@openssl.org>
 <006b01d1d709$91197fe0$b34c7fa0$@ProDigitalSoftware.com>
 <rt-4.0.19-29976-1467758324-158.4606-6-0@openssl.org>
Message-ID: <rt-4.0.19-30004-1467758809-410.4606-6-0@openssl.org>

On Tue Jul 05 22:38:44 2016, NCarboni at ProDigitalSoftware.com wrote:
> Knowing that made all the difference, thank you. It wasn't clear since
> there's some evidence of "2.0" in the various downloads.

That's "openssl-fips" which is a FIPS module. Separate thing with its own
versioning.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed Jul  6 00:09:32 2016
From: rt at openssl.org (John Denker via RT)
Date: Wed, 06 Jul 2016 00:09:32 +0000
Subject: [openssl-dev] [openssl.org #4607] improve quietness for
	s_client ... also documentation for s_client + s_server
In-Reply-To: <577C4C33.6060507@av8n.com>
References: <RT-Ticket-4607@openssl.org> <577C03BD.3070602@av8n.com>
 <rt-4.0.19-30004-1467754961-1720.4607-6-0@openssl.org>
 <577C4C33.6060507@av8n.com>
Message-ID: <rt-4.0.19-29976-1467763772-988.4607-6-0@openssl.org>

On 07/05/2016 02:42 PM, Rich Salz via RT wrote:
> this is for 1.0.2, right?

:; openssl version
OpenSSL 1.1.0-pre6-dev

:; git log
commit c2d551c01930df54bce6517cfecd214db6e98e80
Date:   Wed Apr 27 14:47:45 2016 +0100


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4607
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed Jul  6 00:24:23 2016
From: rt at openssl.org (paul.dale@oracle.com via RT)
Date: Wed, 06 Jul 2016 00:24:23 +0000
Subject: [openssl-dev] [openssl.org #4608] Dead code in apps/openssl.c
In-Reply-To: <414ab21f-4f7e-4c9c-afae-5daca1448473@default>
References: <RT-Ticket-4608@openssl.org>
 <414ab21f-4f7e-4c9c-afae-5daca1448473@default>
Message-ID: <rt-4.0.19-30004-1467764663-1471.4608-21-0@openssl.org>

I found some dead code in apps/openssl.c which appears to be some legacy configuration handling.

Patch to remove it is attached.

 

Pauli

-- 

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia

 

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4608
Please log in as guest with password guest if prompted

-------------- next part --------------
diff --git a/apps/openssl.c b/apps/openssl.c
index 78ed023..d74fe2a 100644
--- a/apps/openssl.c
+++ b/apps/openssl.c
@@ -58,7 +58,6 @@ static void list_type(FUNC_TYPE ft);
 static void list_disabled(void);
 char *default_config_file = NULL;
 
-static CONF *config = NULL;
 BIO *bio_in = NULL;
 BIO *bio_out = NULL;
 BIO *bio_err = NULL;
@@ -243,8 +242,6 @@ int main(int argc, char *argv[])
  end:
     OPENSSL_free(copied_argv);
     OPENSSL_free(default_config_file);
-    NCONF_free(config);
-    config = NULL;
     lh_FUNCTION_free(prog);
     OPENSSL_free(arg.argv);
 

From rt at openssl.org  Thu Jul  7 09:02:19 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Thu, 07 Jul 2016 09:02:19 +0000
Subject: [openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in
	OpenSSL RAND_poll() Is Ineffective
In-Reply-To: <004e01d1d6db$d511f200$7f35d600$@ProDigitalSoftware.com>
References: <RT-Ticket-4606@openssl.org>
 <004e01d1d6db$d511f200$7f35d600$@ProDigitalSoftware.com>
Message-ID: <rt-4.0.19-30004-1467882139-1910.4606-6-0@openssl.org>

Closing this ticket - fixed in 1.1.0.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted


From c.holper at ades.at  Thu Jul  7 19:45:29 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Thu, 7 Jul 2016 21:45:29 +0200
Subject: [openssl-dev] MGF1-OAEP with SHA2
Message-ID: <e60b6513-9435-0117-8703-33c794e48eb2@ades.at>

Hi!

I try to get RSA enryption/decryption (over the API) with MGF1 
OAEP-padding other then SHA1.
As far I can see it is still limited to SHA1.

Does anyone know a patch or is there a plan to extend it?

I know too less about padding and MGF and I am not sure
it is only a change of the digest and its length to make it run with 
others than SHA1.

Thanks!

Chris

From rt at openssl.org  Thu Jul  7 20:07:33 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 07 Jul 2016 20:07:33 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160702105929.GA9192@roeckx.be>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
Message-ID: <rt-4.0.19-29976-1467922053-838.4602-6-0@openssl.org>

On Sat Jul 02 10:59:38 2016, kurt at roeckx.be wrote:
> Hi,
>
> I received the following bug in debian:
> https://bugs.debian.org/829272
>
>
> I got a lot of bugs filed about packages FTBFS with openssl 1.1.0.
> I started to look at some of them, and many of them are due too
> structures having been made opaque. In many cases accessors already
> exists, but definitely not for all.
>
> Here is a list of accessors I so far have identified as missing. The
> filenames given in the "Add to ..." comments below are suggestions
> based on where similar functions are defined and implemented.
>
>
> /* Add to include/openssl/x509_vfy.h : */
>
> typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX
> *ctx, X509 *x);
> typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509
> *x, X509 *issuer);
>
> void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> X509_STORE_CTX_get_issuer
> get_issuer);
> X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> *ctx);
> void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> X509_STORE_CTX_check_issued
> check_issued);
> X509_STORE_CTX_check_issued
> X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);

And I suppose that was only those that particular submitter needed. Looking at
crypto/include/internal/x509_int.h, I can see a whole lot more function
pointers that are unreachable.

> Regarding the new locking. Do I understand it correctly that e.g.
>
> CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
>
> should be replaced by something like
>
> CRYPTO_THREAD_write_lock(X509_STORE_get_lock(ctx));
>
> But then the accessors to get hold of the lock objects in the opaque
> structs are missing. E.g.
>
> /* Add to some header file */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *ctx);
>
> /* Add to some implementation file */
>
> /* Add to crypto/x509/x509_lu.c */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *v)
> {
> return v->lock;
> }
>
> Repeat for other relevant classes with locks.

I'll look into all of this.

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu Jul  7 21:29:09 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 07 Jul 2016 21:29:09 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160702105929.GA9192@roeckx.be>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
Message-ID: <rt-4.0.19-30004-1467926949-139.4602-6-0@openssl.org>

On Sat Jul 02 10:59:38 2016, kurt at roeckx.be wrote:
> /* Add to include/openssl/x509_vfy.h : */
>
> typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX
> *ctx, X509 *x);
> typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509
> *x, X509 *issuer);
>
> void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> X509_STORE_CTX_get_issuer
> get_issuer);
> X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> *ctx);
> void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> X509_STORE_CTX_check_issued
> check_issued);
> X509_STORE_CTX_check_issued
> X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);

For this part, https://github.com/openssl/openssl/pull/1294

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu Jul  7 21:40:24 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 07 Jul 2016 21:40:24 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160702105929.GA9192@roeckx.be>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
Message-ID: <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>

On Sat Jul 02 10:59:38 2016, kurt at roeckx.be wrote:
> /* Add to include/openssl/x509v3.h */
>
> void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
>
>
> /* Add to crypto/x509v3/v3_purp.c */
>
> void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> {
> x->ex_flags |= ex_flags;
> }
>
> void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> {
> x->ex_flags &= ~ex_flags;
> }

This gives me the heebie jeebies. ex_flags is used a lot internally, and I
can't begin to imagine the consequences of letting external code manipulate
this. I understand that in some cases, it seems easy and quick, but...

So, if someone else wants to have a go at this and can make something sensible,
please be my guest. Me, I'm backing off from this particular idea.

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu Jul  7 21:41:43 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Thu, 07 Jul 2016 21:41:43 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <e57a6d28a3eb43deab8084a9eb224a4a@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <e57a6d28a3eb43deab8084a9eb224a4a@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-30004-1467927703-670.4602-6-0@openssl.org>

I think we should ask kurt to ask the original reporter what they need to do.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu Jul  7 22:00:15 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 07 Jul 2016 22:00:15 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160702105929.GA9192@roeckx.be>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
Message-ID: <rt-4.0.19-30004-1467928815-32.4602-6-0@openssl.org>

On Sat Jul 02 10:59:38 2016, kurt at roeckx.be wrote:
> /* Add to some header file */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *ctx);
>
> /* Add to some implementation file */
>
> /* Add to crypto/x509/x509_lu.c */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *v)
> {
> return v->lock;
> }

https://github.com/openssl/openssl/pull/1295

> Repeat for other relevant classes with locks.

This has to be considered carefully. For most opaque types, it makes zero sense
to give out the lock. However, for opaque types that contain function pointers
that leads to user code, I can see scenarios where it does make sense.

For this case, I've only considered X509_STORE.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From kurt at roeckx.be  Thu Jul  7 22:42:11 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 8 Jul 2016 00:42:11 +0200
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
Message-ID: <20160707224211.GA19448@roeckx.be>

On Thu, Jul 07, 2016 at 09:40:24PM +0000, Richard Levitte via RT wrote:
> On Sat Jul 02 10:59:38 2016, kurt at roeckx.be wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> >
> >
> > /* Add to crypto/x509v3/v3_purp.c */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags |= ex_flags;
> > }
> >
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags &= ~ex_flags;
> > }
> 
> This gives me the heebie jeebies. ex_flags is used a lot internally, and I
> can't begin to imagine the consequences of letting external code manipulate
> this. I understand that in some cases, it seems easy and quick, but...
> 
> So, if someone else wants to have a go at this and can make something sensible,
> please be my guest. Me, I'm backing off from this particular idea.

Mattias,

Can you explain why this is needed, what the code is trying to do?


Kurt


From rt at openssl.org  Thu Jul  7 22:42:30 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Thu, 07 Jul 2016 22:42:30 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160707224211.GA19448@roeckx.be>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
Message-ID: <rt-4.0.19-30004-1467931350-885.4602-6-0@openssl.org>

On Thu, Jul 07, 2016 at 09:40:24PM +0000, Richard Levitte via RT wrote:
> On Sat Jul 02 10:59:38 2016, kurt at roeckx.be wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> >
> >
> > /* Add to crypto/x509v3/v3_purp.c */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags |= ex_flags;
> > }
> >
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags &= ~ex_flags;
> > }
> 
> This gives me the heebie jeebies. ex_flags is used a lot internally, and I
> can't begin to imagine the consequences of letting external code manipulate
> this. I understand that in some cases, it seems easy and quick, but...
> 
> So, if someone else wants to have a go at this and can make something sensible,
> please be my guest. Me, I'm backing off from this particular idea.

Mattias,

Can you explain why this is needed, what the code is trying to do?


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul  8 06:08:22 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 08 Jul 2016 06:08:22 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-30004-1467926949-1421.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467926949-1421.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-1832-1467958101-343.4602-6-0@openssl.org>

On Thu Jul 07 21:29:09 2016, levitte wrote:
> On Sat Jul 02 10:59:38 2016, kurt at roeckx.be wrote:
> > /* Add to include/openssl/x509_vfy.h : */
> >
> > typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX
> > *ctx, X509 *x);
> > typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509
> > *x, X509 *issuer);
> >
> > void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> > X509_STORE_CTX_get_issuer
> > get_issuer);
> > X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> > *ctx);
> > void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> > X509_STORE_CTX_check_issued
> > check_issued);
> > X509_STORE_CTX_check_issued
> > X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);
>
> For this part, https://github.com/openssl/openssl/pull/1294

So, looking at this again after some sleep, there's a part of this solution
that I'm unsure of, and it all comes back to X509_STORE_CTX_init(), where the
X509_STORE context gets initialised from the X509_STORE, including all the
function pointers. This has me wonder if the X509_STORE_CTX setters should
really be made available (perhaps with the exception of the verify and
verify_cb ones). Doesn't it make more sense to set those function pointers when
creating the X509_STORE itself? Why would those functions need to be changed in
the context?

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul  8 07:47:15 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Fri, 08 Jul 2016 07:47:15 +0000
Subject: [openssl-dev] [openssl.org #4609] Configure does not honor requests
	for ld.gold
In-Reply-To: <CAH8yC8m2o5Man2Qq8QYgK9djSFvk1k0ccL8eiws7u8EYBLK7ng@mail.gmail.com>
References: <RT-Ticket-4609@openssl.org>
 <CAH8yC8m2o5Man2Qq8QYgK9djSFvk1k0ccL8eiws7u8EYBLK7ng@mail.gmail.com>
Message-ID: <rt-4.0.19-29976-1467964035-1018.4609-21-0@openssl.org>

$ ./config LD=ld.gold
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
target already defined - linux-x86_64 (offending arg: LD=ld.gold)

And:

$ LD=ld.gold ./config
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
...

$ cat Makefile | grep ld.gold
$ cat Makefile.shared | grep ld.gold
$

I don't believe CFLAG -fuse-ld=gold is an option because the linker is
invoked directly rather than using the compiler driver. (Or at least
it used to be that way).


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul  8 08:33:57 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 08 Jul 2016 08:33:57 +0000
Subject: [openssl-dev] [openssl.org #4609] Configure does not honor requests
	for ld.gold
In-Reply-To: <CAH8yC8m2o5Man2Qq8QYgK9djSFvk1k0ccL8eiws7u8EYBLK7ng@mail.gmail.com>
References: <RT-Ticket-4609@openssl.org>
 <CAH8yC8m2o5Man2Qq8QYgK9djSFvk1k0ccL8eiws7u8EYBLK7ng@mail.gmail.com>
Message-ID: <rt-4.0.19-1832-1467966837-1309.4609-6-0@openssl.org>

On Fri Jul 08 07:47:14 2016, noloader at gmail.com wrote:
> $ ./config LD=ld.gold
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
> target already defined - linux-x86_64 (offending arg: LD=ld.gold)
>
> And:
>
> $ LD=ld.gold ./config
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> ...
>
> $ cat Makefile | grep ld.gold
> $ cat Makefile.shared | grep ld.gold
> $
>
> I don't believe CFLAG -fuse-ld=gold is an option because the linker is
> invoked directly rather than using the compiler driver. (Or at least
> it used to be that way).

'ld' is only used in one case, in Makefile.shared. That's for AIX, when
building shared objects directly from object files instead of going from the
static library. Therefore, trying to set LD makes absolutely no sense.

Also, please please please read INSTALL, it tells you what environment
variables are considered by the configuration scripts, and please please please
understand that our configuration scripts are not autoconf generated ones and
currently do not understand 'FOO=value' arguments. This has been pointed out
quite a few times already.

That being said, have you tried the following (the configuration scripts will
assume that any argument starting with a dash that they don't understand
internally are to be taken as C flags... this too has been pointed out before)?

./config -fuse-ld=gold

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul  8 09:33:01 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Fri, 08 Jul 2016 09:33:01 +0000
Subject: [openssl-dev] [openssl.org #4609] Configure does not honor
	requests for ld.gold
In-Reply-To: <CAH8yC8=T_UkhV6Z8Fh-DTcgXJxZN_Cugy2EW+CFWwULkRyk6Fg@mail.gmail.com>
References: <RT-Ticket-4609@openssl.org>
 <CAH8yC8m2o5Man2Qq8QYgK9djSFvk1k0ccL8eiws7u8EYBLK7ng@mail.gmail.com>
 <rt-4.0.19-1832-1467966837-1309.4609-6-0@openssl.org>
 <CAH8yC8=T_UkhV6Z8Fh-DTcgXJxZN_Cugy2EW+CFWwULkRyk6Fg@mail.gmail.com>
Message-ID: <rt-4.0.19-1832-1467970381-741.4609-6-0@openssl.org>

On Fri, Jul 8, 2016 at 4:33 AM, Richard Levitte via RT <rt at openssl.org> wrote:
> On Fri Jul 08 07:47:14 2016, noloader at gmail.com wrote:
>> $ ./config LD=ld.gold
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
>> target already defined - linux-x86_64 (offending arg: LD=ld.gold)
>>
>> And:
>>
>> $ LD=ld.gold ./config
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>> ...
>>
>> $ cat Makefile | grep ld.gold
>> $ cat Makefile.shared | grep ld.gold
>> $
>>
>> I don't believe CFLAG -fuse-ld=gold is an option because the linker is
>> invoked directly rather than using the compiler driver. (Or at least
>> it used to be that way).
>
> 'ld' is only used in one case, in Makefile.shared. That's for AIX, when
> building shared objects directly from object files instead of going from the
> static library. Therefore, trying to set LD makes absolutely no sense.

Hmmm... If I want to use ld.gold as my linker, the easiest path is to
set LD=ld.gold. It makes perfect sense to some....

> Also, please please please read INSTALL, it tells you what environment
> variables are considered by the configuration scripts, and please please please
> understand that our configuration scripts are not autoconf generated ones and
> currently do not understand 'FOO=value' arguments. This has been pointed out
> quite a few times already.

Why be normal :)

... but I understand why it does not make perfect sense to others.

Jeff


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul  8 09:36:42 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 08 Jul 2016 09:36:42 +0000
Subject: [openssl-dev] [openssl.org #4609] Configure does not honor requests
	for ld.gold
In-Reply-To: <rt-4.0.19-1832-1467970381-1051.4609-6-0@openssl.org>
References: <RT-Ticket-4609@openssl.org>
 <CAH8yC8m2o5Man2Qq8QYgK9djSFvk1k0ccL8eiws7u8EYBLK7ng@mail.gmail.com>
 <rt-4.0.19-1832-1467966837-1309.4609-6-0@openssl.org>
 <CAH8yC8=T_UkhV6Z8Fh-DTcgXJxZN_Cugy2EW+CFWwULkRyk6Fg@mail.gmail.com>
 <rt-4.0.19-1832-1467970381-1051.4609-6-0@openssl.org>
Message-ID: <rt-4.0.19-1832-1467970602-1598.4609-6-0@openssl.org>

On Fri Jul 08 09:33:01 2016, noloader at gmail.com wrote:
> Hmmm... If I want to use ld.gold as my linker, the easiest path is to
> set LD=ld.gold. It makes perfect sense to some....

Did it work for you when doing this?

./config -fuse-ld=gold

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted


From steve at openssl.org  Fri Jul  8 12:12:03 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 8 Jul 2016 12:12:03 +0000
Subject: [openssl-dev] MGF1-OAEP with SHA2
In-Reply-To: <e60b6513-9435-0117-8703-33c794e48eb2@ades.at>
References: <e60b6513-9435-0117-8703-33c794e48eb2@ades.at>
Message-ID: <20160708121203.GA20041@openssl.org>

On Thu, Jul 07, 2016, c.holper at ades.at wrote:

> 
> I try to get RSA enryption/decryption (over the API) with MGF1
> OAEP-padding other then SHA1.
> 

You need to use the EVP_PKEY API and pass the required algotithm to
EVP_PKEY_CTX_set_rsa_oaep_md() which is currently undocumented (fix coming
up).

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rt at openssl.org  Fri Jul  8 12:28:45 2016
From: rt at openssl.org (Hubert Kario via RT)
Date: Fri, 08 Jul 2016 12:28:45 +0000
Subject: [openssl-dev] [openssl.org #4610] Incorrect handling of malformed
	Client Key Exchange messages for ECDHE_RSA key exchange
In-Reply-To: <3037581.h6leHmcXCy@pintsize.usersys.redhat.com>
References: <RT-Ticket-4610@openssl.org> <RT-Ticket-2777@openssl.org>
 <E4599F0406A786429EDBAE349D9FE67F0295B36B@PPOMSG2.QUANTUM.com>
 <rt-4.0.19-21188-1467060187-208.2777-6-0@openssl.org>
 <3037581.h6leHmcXCy@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-15716-1467980925-1249.4610-21-0@openssl.org>

Current 1.0.1, 1.0.2 and master don't handle malformed Client Key Exchange
messages correctly.

when a malformed message, or message with incorrect parameters is received
openssl server just closes the connection instead of sending an Alert
message

reproducer script:
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-ecdhe-rsa-key-exchange-with-bad-messages.py

to reproduce:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch
openssl s_server -key localhost.key -cert localhost.crt -www 2>server.err >server.out &
openssl_pid=$!
git clone https://github.com/tomato42/tlsfuzzer
pushd tlsfuzzer
git clone https://github.com/tomato42/tlslite-ng .tlslite-ng
ln -s .tlslite-ng/tlslite tlslite
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
PYTHONPATH=. python scripts/test-ecdhe-rsa-key-exchange-with-bad-messages.py
popd
kill $openssl_pid
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4610
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160708/aa27a622/attachment-0001.sig>

From rt at openssl.org  Fri Jul  8 12:33:01 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Fri, 08 Jul 2016 12:33:01 +0000
Subject: [openssl-dev] [openssl.org #4609] Configure does not honor
	requests for ld.gold
In-Reply-To: <8a8fcdb4dde349d59a74c8a3c4a41d21@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4609@openssl.org>
 <CAH8yC8m2o5Man2Qq8QYgK9djSFvk1k0ccL8eiws7u8EYBLK7ng@mail.gmail.com>
 <rt-4.0.19-29976-1467964035-1018.4609-21-0@openssl.org>
 <8a8fcdb4dde349d59a74c8a3c4a41d21@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-29976-1467981181-1124.4609-6-0@openssl.org>

I don't know what you expect us to do.  We don't use the LD variable.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul  8 17:00:47 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Fri, 08 Jul 2016 17:00:47 +0000
Subject: [openssl-dev] [openssl.org #4592] [docs] SSL_set_app_data() returns
	'int', not 'void'
In-Reply-To: <alpine.DEB.2.20.1606271029290.22460@tvnag.unkk.fr>
References: <RT-Ticket-4592@openssl.org>
 <alpine.DEB.2.20.1606271029290.22460@tvnag.unkk.fr>
Message-ID: <rt-4.0.19-1832-1467997246-529.4592-6-0@openssl.org>

fixed in master.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4592
Please log in as guest with password guest if prompted


From dwmw2 at infradead.org  Fri Jul  8 16:43:21 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jul 2016 17:43:21 +0100
Subject: [openssl-dev] [PATCH] Add support for minimum and maximum
 protocol version supported by a cipher
Message-ID: <1467996201.4158.201.camel@infradead.org>

On Sun, 2016-02-07 at 20:17 +0100, Kurt Roeckx wrote:
> Reviewed-by: Viktor Dukhovni <viktor at openssl.org>
> 
> MR: #1595
> ---
> ?ssl/s3_lib.c???????????? | 534 +++++++++++++++++++++++++++++++----------------
> ?ssl/ssl_ciph.c?????????? | 196 +++++++++--------
> ?ssl/ssl_lib.c??????????? |?? 4 +-
> ?ssl/ssl_locl.h?????????? |? 21 +-
> ?ssl/ssl_txt.c??????????? |?? 2 +-
> ?ssl/statem/statem_clnt.c |? 18 +-
> ?ssl/statem/statem_lib.c? |?? 6 +-
> ?ssl/t1_lib.c???????????? |? 41 ++--
> ?8 files changed, 504 insertions(+), 318 deletions(-)
> 
> diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> index 51fb161..093ff09 100644
> --- a/ssl/s3_lib.c
> +++ b/ssl/s3_lib.c
> @@ -171,7 +171,8 @@ static const SSL_CIPHER ssl3_ciphers[] = {
> ????? SSL_aRSA,
> ????? SSL_eNULL,
> ????? SSL_MD5,
> -???? SSL_SSLV3,
> +???? SSL3_VERSION, TLS1_2_VERSION,
> +???? DTLS1_VERSION, DTLS1_2_VERSION,

This broke the OpenConnect VPN client, which now fails thus:

DTLS handshake failed: 1
67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers available:ssl/statem/statem_clnt.c:927:

I tried the na?vely obvious step of changing all instances of
DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.


Having said that, reverting this change isn't *sufficient* to fix
OpenSSL 1.1; it still fails with?

DTLS handshake failed: 1
67609664:error:14160098:SSL routines:read_state_machine:excessive message size:ssl/statem/statem.c:586:

... which goes back to before 1.1.0-pre1. I'll find that one later...

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160708/c0d03807/attachment.bin>

From rt at openssl.org  Fri Jul  8 18:29:26 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Fri, 08 Jul 2016 18:29:26 +0000
Subject: [openssl-dev] [openssl.org #4609] Configure does not honor
	requests for ld.gold
In-Reply-To: <CAH8yC8mc+oKSHgEwmFuzjpMaA=k+C2+=nCcQ1Waey0UxzCCdTw@mail.gmail.com>
References: <RT-Ticket-4609@openssl.org>
 <CAH8yC8m2o5Man2Qq8QYgK9djSFvk1k0ccL8eiws7u8EYBLK7ng@mail.gmail.com>
 <rt-4.0.19-29976-1467964035-1018.4609-21-0@openssl.org>
 <8a8fcdb4dde349d59a74c8a3c4a41d21@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-29976-1467981181-1124.4609-6-0@openssl.org>
 <CAH8yC8mc+oKSHgEwmFuzjpMaA=k+C2+=nCcQ1Waey0UxzCCdTw@mail.gmail.com>
Message-ID: <rt-4.0.19-15716-1468002566-803.4609-6-0@openssl.org>

On Fri, Jul 8, 2016 at 8:33 AM, Salz, Rich via RT <rt at openssl.org> wrote:
> I don't know what you expect us to do.  We don't use the LD variable.

Right. I'm just pointing out gaps.

It only gets worse for users. What happens when someone tries a
cross-compile by setting CC, AR, RANLIB, LD and a CFLAGS with
--sysroot? As far as I know, there is no RTFM for cross-compiles.

Jeff


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted


From dwmw2 at infradead.org  Fri Jul  8 18:30:26 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jul 2016 19:30:26 +0100
Subject: [openssl-dev] [PATCH] Add support for minimum and maximum
 protocol version supported by a cipher
In-Reply-To: <1467996201.4158.201.camel@infradead.org>
References: <1467996201.4158.201.camel@infradead.org>
Message-ID: <1468002626.4158.205.camel@infradead.org>

On Fri, 2016-07-08 at 17:43 +0100, David Woodhouse wrote:
> On Sun, 2016-02-07 at 20:17 +0100, Kurt Roeckx wrote:
> > Reviewed-by: Viktor Dukhovni <viktor at openssl.org>
> > 
> > MR: #1595
> > ---
> > ?ssl/s3_lib.c???????????? | 534 +++++++++++++++++++++++++++++++----------------
> > ?ssl/ssl_ciph.c?????????? | 196 +++++++++--------
> > ?ssl/ssl_lib.c??????????? |?? 4 +-
> > ?ssl/ssl_locl.h?????????? |? 21 +-
> > ?ssl/ssl_txt.c??????????? |?? 2 +-
> > ?ssl/statem/statem_clnt.c |? 18 +-
> > ?ssl/statem/statem_lib.c? |?? 6 +-
> > ?ssl/t1_lib.c???????????? |? 41 ++--
> > ?8 files changed, 504 insertions(+), 318 deletions(-)
> > 
> > diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> > index 51fb161..093ff09 100644
> > --- a/ssl/s3_lib.c
> > +++ b/ssl/s3_lib.c
> > @@ -171,7 +171,8 @@ static const SSL_CIPHER ssl3_ciphers[] = {
> > ????? SSL_aRSA,
> > ????? SSL_eNULL,
> > ????? SSL_MD5,
> > -???? SSL_SSLV3,
> > +???? SSL3_VERSION, TLS1_2_VERSION,
> > +???? DTLS1_VERSION, DTLS1_2_VERSION,
> 
> This broke the OpenConnect VPN client, which now fails thus:
> 
> DTLS handshake failed: 1
> 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers available:ssl/statem/statem_clnt.c:927:
> 
> I tried the na?vely obvious step of changing all instances of
> DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.

Of course, it's because DTLS_VERSION_LT and friends are doing precisely
the opposite of what their names imply, numerically. I hesitate to call
this a 'fix' but it highlights the issue:

diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h
index ef5eb8c..218dcce 100644
--- a/ssl/ssl_locl.h
+++ b/ssl/ssl_locl.h
@@ -259,10 +259,11 @@
                           c[1]=(unsigned char)(((l)>> 8)&0xff), \
                           c[2]=(unsigned char)(((l)    )&0xff)),c+=3)
 
-#define DTLS_VERSION_GT(v1, v2) ((v1) < (v2))
-#define DTLS_VERSION_GE(v1, v2) ((v1) <= (v2))
-#define DTLS_VERSION_LT(v1, v2) ((v1) > (v2))
-#define DTLS_VERSION_LE(v1, v2) ((v1) >= (v2))
+#define dtls_ver_cmp(v1) (((v1) == DTLS1_BAD_VER) ? 0xff00 : (v1))
+#define DTLS_VERSION_GT(v1, v2) (dtls_ver_cmp(v1) < dtls_ver_cmp(v2))
+#define DTLS_VERSION_GE(v1, v2) (dtls_ver_cmp(v1) <= dtls_ver_cmp(v2))
+#define DTLS_VERSION_LT(v1, v2) (dtls_ver_cmp(v1) > dtls_ver_cmp(v2))
+#define DTLS_VERSION_LE(v1, v2) (dtls_ver_cmp(v1) >= dtls_ver_cmp(v2))
 
 /* LOCAL STUFF */
 
> 
> Having said that, reverting this change isn't *sufficient* to fix
> OpenSSL 1.1; it still fails with?
> 
> DTLS handshake failed: 1
> 67609664:error:14160098:SSL routines:read_state_machine:excessive message size:ssl/statem/statem.c:586:
> 
> ... which goes back to before 1.1.0-pre1. I'll find that one later...

That one's simpler:

diff --git a/ssl/statem/statem_clnt.c b/ssl/statem/statem_clnt.c
index 26c4d10..b2160cd 100644
--- a/ssl/statem/statem_clnt.c
+++ b/ssl/statem/statem_clnt.c
@@ -704,6 +704,8 @@ unsigned long ossl_statem_client_max_message_size(SSL *s)
             return SERVER_HELLO_DONE_MAX_LENGTH;
 
         case TLS_ST_CR_CHANGE:
+            if (s->client_version == DTLS1_BAD_VER)
+                return 3;
             return CCS_MAX_LENGTH;
 
         case TLS_ST_CR_SESSION_TICKET:
-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160708/bb12b160/attachment-0001.bin>

From brian at briansmith.org  Fri Jul  8 19:07:39 2016
From: brian at briansmith.org (Brian Smith)
Date: Fri, 8 Jul 2016 09:07:39 -1000
Subject: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256
	correct?
In-Reply-To: <CAFewVt6pNsNFjsmxvgkGGo8QSDUf=THU7T8_Y4V=meOmE_0qHA@mail.gmail.com>
References: <CAFewVt6pNsNFjsmxvgkGGo8QSDUf=THU7T8_Y4V=meOmE_0qHA@mail.gmail.com>
Message-ID: <CAFewVt65wGVCw9i+hSwPFDy1q3OUVJB=KU4tA+UQLHNfu6Jfpw@mail.gmail.com>

Brian Smith <brian at briansmith.org> wrote:

> When doing math on short Weierstrass curves like P-256, we have to
> special case points at infinity. In Jacobian coordinates (X, Y, Z),
> points at infinity have Z == 0. However, instead of checking for Z ==
> 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it
> does, in some sense, the opposite of what I expect it to do.
>

I exchanged email with both of the original authors of the code, Shay and
Vlad. He that the ecp_nistz256_point_* functions indeed intend to represent
the point at infinity as (0, 0) and it is expected (but I did not verify)
that those functions should work when the point at infinity is encoded as
(0, 0, _).

The authors
> instead decided to encode the point at infinity as (0, 0), since the
> affine point (0, 0) isn't on the P-256 curve. It isn't clear why the
> authors chose to do that though, since the point at infinity doesn't
> (can't, logically) appear in the table of precomputed multiples of G
> anyway.


Actually, as the code says, the point at infinity implicitly occurs in the
table implicitly. Obviously the accumulator point will be at infinity until
at least a one bit is found in the scalar.


> But, it seems like the functions that do the computations, like
>
ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the
> point at infinity as (_, _, 0), not necessarily (0, 0, _). Also,
> ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and
> ec_GFp_simple_point_set_to_infinity, which represent the point at
> infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine
> uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0.
> This inconsistency is confusing, if not wrong. Given this, it seems
> like the point-at-infinity checks in the ecp_nistz256_point_add and
> ecp_nistz256_point_add_affine code should also be checking that z == 0
> instead of (x, y) == (0, 0).
>

Instead, when we convert a point from EC_POINT to P256_POINT or
P256_POINT_AFFINE, we should translate the (_, _, 0) form into the (0, 0,
0) form. And/or reject points at infinity as inputs to the function.
Similarly, when we convert the resultant P256_POINT to an EC_POINT, we
chould translate the (0, 0) encoding of the point at infinity to the (0, 0,
0) form or at least the (_, _, 0) form.

In particular, consider the case where you have an EC_POINT that isn't at
infinity, e.g. (x, y, 1). Then you call EC_POINT_set_to_infinity on it.
Then it is (x, y, 0). Then you pass it to EC_POINT_mul/EC_POINTs_mul even
though you shouldn't.

Maybe the precondition of EC_POINT_mul/EC_POINTs_mul is that none of the
input points are at infinity, in which case it doesn't matter. (But if so,
maybe these functions should do a point-at-infinity check.) But if it is
allowed to pass in the point at infinity, then the ecp_nistz256 code should
translate the input point from (_, _, 0) form to (0, 0, _) form before
doing the computation. It can use is_zero and copy_conditional and friends
to do this.

Similarly, after the computation, it should translate the (0, 0, _) form to
(_, _, 0) form. In particular, it should do such a translation before the
code sets Z_is_one, AFAICT. Note that the nistz256 code might be using the
form (0, 0, 0) instead of (0, 0, _) in which case this translation might
not be necessary.

Regardless, it would be useful to write tests for these cases:
1. Verify that the result is correct when any of the input points are (0,
0, 0)
2. Verify that the result is correct when any of the input points are (_,
_, 0).
3. Verify that the result is correct, and in particular that Z_is_one is
set correctly on the result, when the final result is at infinity,
especially for the cases where neither the input points are at infinity,
e.g. when adding (n-1)G to 1G.

Note that all of the above cases have interesting sub-cases: the G scalar
is NULL, the G scalar is non-NULL and zero-valued, G scalar is a multiple
of G, G scalar is larger than G. And same for the P scalars.

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160708/35e38df9/attachment.html>

From openssl-users at dukhovni.org  Fri Jul  8 19:13:03 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 8 Jul 2016 19:13:03 +0000
Subject: [openssl-dev] [PATCH] Add support for minimum and maximum
 protocol version supported by a cipher
In-Reply-To: <1468002626.4158.205.camel@infradead.org>
References: <1467996201.4158.201.camel@infradead.org>
 <1468002626.4158.205.camel@infradead.org>
Message-ID: <20160708191302.GH23906@mournblade.imrryr.org>

On Fri, Jul 08, 2016 at 07:30:26PM +0100, David Woodhouse wrote:

> > I tried the na?vely obvious step of changing all instances of
> > DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.
> 
> Of course, it's because DTLS_VERSION_LT and friends are doing precisely
> the opposite of what their names imply, numerically. I hesitate to call
> this a 'fix' but it highlights the issue:

Yes, unfortunately, the DTLS "bad" version of 0x0100 looks like a
very high DTLS version.  So comparisons require a special case.
Given that DTLS1_VERSION is 0xFEFF, indeed the next "lower" version
is 0xFF00 as you suggest below:


> diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h
> index ef5eb8c..218dcce 100644
> --- a/ssl/ssl_locl.h
> +++ b/ssl/ssl_locl.h
> @@ -259,10 +259,11 @@
>                            c[1]=(unsigned char)(((l)>> 8)&0xff), \
>                            c[2]=(unsigned char)(((l)    )&0xff)),c+=3)
>  
> -#define DTLS_VERSION_GT(v1, v2) ((v1) < (v2))
> -#define DTLS_VERSION_GE(v1, v2) ((v1) <= (v2))
> -#define DTLS_VERSION_LT(v1, v2) ((v1) > (v2))
> -#define DTLS_VERSION_LE(v1, v2) ((v1) >= (v2))
> +#define dtls_ver_cmp(v1) (((v1) == DTLS1_BAD_VER) ? 0xff00 : (v1))
> +#define DTLS_VERSION_GT(v1, v2) (dtls_ver_cmp(v1) < dtls_ver_cmp(v2))
> +#define DTLS_VERSION_GE(v1, v2) (dtls_ver_cmp(v1) <= dtls_ver_cmp(v2))
> +#define DTLS_VERSION_LT(v1, v2) (dtls_ver_cmp(v1) > dtls_ver_cmp(v2))
> +#define DTLS_VERSION_LE(v1, v2) (dtls_ver_cmp(v1) >= dtls_ver_cmp(v2))

Perhaps rename dtls_ver_cmp() to dtls_ver_ordinal(), "cmp" suggests
that you're actually doing a comparison.  Given this macro, one
might consider complementing the versions, so that the ordinals
compare in the usual way:

    #define dtls_ver_ordinal(v) (((v) == DTLS1_BAD_VER) ? 0x00ff : (0xffff ^ (v)))

-- 
	Viktor.

From dwmw2 at infradead.org  Fri Jul  8 19:41:51 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jul 2016 20:41:51 +0100
Subject: [openssl-dev] [PATCH] Fix missing return value checks in SCTP
Message-ID: <1468006911.4158.210.camel@infradead.org>

On Tue, 2015-08-11 at 19:36 +0100, Matt Caswell wrote:
> There are some missing return value checks in the SCTP code. In master this
> was causing a compilation failure when config'd with
> "--strict-warnings sctp".
> 
> Reviewed-by: Tim Hudson <tjh at openssl.org>
> ---
>  ssl/d1_clnt.c | 16 ++++++++++++----
>  ssl/d1_srvr.c | 18 +++++++++++++-----
>  2 files changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/ssl/d1_clnt.c b/ssl/d1_clnt.c
> index 566c154..d411614 100644
> --- a/ssl/d1_clnt.c
> +++ b/ssl/d1_clnt.c
> @@ -364,11 +364,15 @@ int dtls1_connect(SSL *s)
>                               sizeof(DTLS1_SCTP_AUTH_LABEL),
>                               DTLS1_SCTP_AUTH_LABEL);
>  
> -                    SSL_export_keying_material(s, sctpauthkey,
> +                    if (SSL_export_keying_material(s, sctpauthkey,
>                                                 sizeof(sctpauthkey),
>                                                 labelbuffer,
>                                                 sizeof(labelbuffer), NULL, 0,
> -                                               0);
> +                                               0) <= 0) {
> +                        ret = -1;
> +                        s->state = SSL_ST_ERR;
> +                        goto end;
> +                    }
>  
>                      BIO_ctrl(SSL_get_wbio(s),
>                               BIO_CTRL_DGRAM_SCTP_ADD_AUTH_KEY,

This commit (d8e8590e) and its backport to 1.0.2 (b3a62dc0) have broken
OpenConnect when SCTP is enabled, because SSL_export_keying_material()
*does* fail there. Perhaps it shouldn't...

diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index 08e3673..6db4f3a 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -2231,7 +2231,7 @@ int SSL_export_keying_material(SSL *s, unsigned char *out, size_t olen,
                                const unsigned char *p, size_t plen,
                                int use_context)
 {
-    if (s->version < TLS1_VERSION)
+    if (s->version < TLS1_VERSION && s->version != DTLS1_BAD_VER)
         return -1;
 
     return s->method->ssl3_enc->export_keying_material(s, out, olen, label,

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160708/8990db06/attachment.bin>

From dwmw2 at infradead.org  Fri Jul  8 20:15:12 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jul 2016 21:15:12 +0100
Subject: [openssl-dev] [PATCH] Add support for minimum and maximum
 protocol version supported by a cipher
In-Reply-To: <20160708191302.GH23906@mournblade.imrryr.org>
References: <1467996201.4158.201.camel@infradead.org>
 <1468002626.4158.205.camel@infradead.org>
 <20160708191302.GH23906@mournblade.imrryr.org>
Message-ID: <1468008912.4158.213.camel@infradead.org>

On Fri, 2016-07-08 at 19:13 +0000, Viktor Dukhovni wrote:
> 
> Perhaps rename dtls_ver_cmp() to dtls_ver_ordinal(), "cmp" suggests
> that you're actually doing a comparison.?

Well, 'cmp' with one argument isn't *so* easily interpreted as a
comparison, but OK :)

I've also added a comment explaining a little about what's going on.


>  Given this macro, one
> might consider complementing the versions, so that the ordinals
> compare in the usual way:
> 
> ??? #define dtls_ver_ordinal(v) (((v) == DTLS1_BAD_VER) ? 0x00ff : (0xffff ^ (v)))

I suppose we can, if someone feels strongly about it. It didn't seem
worth the additional churn.

One of 4 patches in?https://github.com/openssl/openssl/pull/1296?which
actually make OpenConnect work again...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160708/64b8ae6e/attachment-0001.bin>

From kurt at roeckx.be  Fri Jul  8 21:59:28 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 8 Jul 2016 23:59:28 +0200
Subject: [openssl-dev] [PATCH] Add support for minimum and maximum
 protocol version supported by a cipher
In-Reply-To: <1467996201.4158.201.camel@infradead.org>
References: <1467996201.4158.201.camel@infradead.org>
Message-ID: <20160708215928.GA10679@roeckx.be>

On Fri, Jul 08, 2016 at 05:43:21PM +0100, David Woodhouse wrote:
> 
> This broke the OpenConnect VPN client, which now fails thus:
> 
> DTLS handshake failed: 1
> 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers available:ssl/statem/statem_clnt.c:927:
> 
> I tried the na?vely obvious step of changing all instances of
> DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.

Can you describe how DTLS1_BAD_VER is supposed to work?  Is this
version send over the wire?  Is it negotiated?

We have no test suite coverage doing anything with DTLS1_BAD_VER
and I think the OpenConnect VPN is the only user of it.


Kurt


From dwmw2 at infradead.org  Fri Jul  8 22:25:39 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jul 2016 23:25:39 +0100
Subject: [openssl-dev] [PATCH] Add support for minimum and maximum
 protocol version supported by a cipher
In-Reply-To: <20160708215928.GA10679@roeckx.be>
References: <1467996201.4158.201.camel@infradead.org>
 <20160708215928.GA10679@roeckx.be>
Message-ID: <1468016739.4158.227.camel@infradead.org>

On Fri, 2016-07-08 at 23:59 +0200, Kurt Roeckx wrote:
> 
> Can you describe how DTLS1_BAD_VER is supposed to work?? Is this
> version send over the wire?? Is it negotiated?

It does indeed appear on the wire.

In the AnyConnect/OpenConnect case ? which, as you rightly observe, is
the only remaining user of this version of the protocol ??it's not
actually negotiated in the normal sense at all; we "resume" a session
having established the master secret and session-id over a separate
channel.

http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/dtls.c#l157

> We have no test suite coverage doing anything with DTLS1_BAD_VER
> and I think the OpenConnect VPN is the only user of it.

Yeah, test coverage would be useful... I'm not sure how complete our
*server* side support of DTLS1_BAD_VER is. I did start looking at it
briefly once, but got distracted. I'll have another look.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160708/9c08b8fd/attachment.bin>

From c.holper at ades.at  Sat Jul  9 18:42:39 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Sat, 9 Jul 2016 20:42:39 +0200
Subject: [openssl-dev]  MGF1-OAEP with SHA2
Message-ID: <42dd9890-9e6f-92db-8071-ae7554fd924b@ades.at>

Hi!

I tried with Openssl 1.0.1t from current Debian testing.
But I get
undefined symbol: EVP_PKEY_CTX_set_rsa_oaep_md

Since when version it is in the libs??
Do I need to link against other than -lssl and -lcrypto?

Thanks
Christoph

From rsalz at akamai.com  Sun Jul 10 00:34:23 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 10 Jul 2016 00:34:23 +0000
Subject: [openssl-dev] MGF1-OAEP with SHA2
In-Reply-To: <42dd9890-9e6f-92db-8071-ae7554fd924b@ades.at>
References: <42dd9890-9e6f-92db-8071-ae7554fd924b@ades.at>
Message-ID: <685a678b3e8f43279cb2921f9048d1d6@usma1ex-dag1mb1.msg.corp.akamai.com>


> undefined symbol: EVP_PKEY_CTX_set_rsa_oaep_md
> 
> Since when version it is in the libs??

It is in 1.0.2

> Do I need to link against other than -lssl and -lcrypto?

No, those are the only two libraries OpenSSL has.

From rt at openssl.org  Sun Jul 10 19:38:03 2016
From: rt at openssl.org (Matt Slot via RT)
Date: Sun, 10 Jul 2016 19:38:03 +0000
Subject: [openssl-dev] [openssl.org #4611] PKCS12_create() not thread-safe
	for ECDSA
In-Reply-To: <D3A7FB10.13970%mslot@barracuda.com>
References: <RT-Ticket-4611@openssl.org> <D3A7FB10.13970%mslot@barracuda.com>
Message-ID: <rt-4.0.19-20845-1468179483-721.4611-21-0@openssl.org>

OpenSSL 1.0.2h

The function eckey_priv_encode() may crash if the same pkey is serialized from multiple threads. Here is a sample backtrace:

#0 0x00007fff8f321f92 in _platform_memmove$VARIANT$Haswell ()
#1 0x0000000100196132 in i2c_ASN1_BIT_STRING
#2 0x00000001001a1fb2 in asn1_ex_i2c
#3 0x00000001001a1e68 in asn1_i2d_ex_primitive
#4 0x00000001001a19fd in ASN1_item_ex_i2d
#5 0x00000001001a1d8b in asn1_template_ex_i2d
#6 0x00000001001a1a8b in ASN1_item_ex_i2d
#7 0x00000001001a16d0 in asn1_item_flags_i2d
#8 0x0000000100149d3e in i2d_ECPrivateKey
#9 0x000000010014e576 in eckey_priv_encode
#10 0x000000010018e9f9 in EVP_PKEY2PKCS8_broken
#11 0x00000001001d38d9 in PKCS12_add_key
#12 0x00000001001d35a3 in PKCS12_create

EC_KEY_set_enc_flags() is called to modify/restore the encoding flags within the EC_KEY. Two calls are made to i2d_ECPrivateKey(). The first calculates the necessary buffer length, the second serializes the data into an allocated buffer. If the flags change during this period, the second call overwrites the buffer.

These APIs are documented as thread safe, and should not change the internal flags of the pkey without proper locking.

Matt Slot
Principal Software Engineer

Barracuda Networks, Inc.
317 Maynard St. Ann Arbor, MI 48104
o: 734-887-2481<tel:734-887-2481>  | m: 517-667-6243<tel:517-667-6243> | mslot at barracuda.com<mailto:mslot at barracuda.com>
Connect with us: barracuda.com/connect<http://www.barracuda.com/connect>

[cid:CA69E95D-A573-47F4-A2D6-4E3B56C36852]


===========================================================


Considering Office 365?  Barracuda security and storage solutions can help. Learn more about Barracuda solutions for Office 365 at http://barracuda.com/office365.

DISCLAIMER:
This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4611
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 36C30E00-6397-462F-94DD-A75A9D1A6C05.png
Type: image/png
Size: 4106 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160710/cd28f380/attachment-0001.png>

From rt at openssl.org  Sun Jul 10 19:41:00 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Sun, 10 Jul 2016 19:41:00 +0000
Subject: [openssl-dev] [openssl.org #4611] PKCS12_create() not
	thread-safe for ECDSA
In-Reply-To: <918c985206934055a6dbd7d187a47e79@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4611@openssl.org> <D3A7FB10.13970%mslot@barracuda.com>
 <rt-4.0.19-20845-1468179483-721.4611-21-0@openssl.org>
 <918c985206934055a6dbd7d187a47e79@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-20844-1468179660-1313.4611-6-0@openssl.org>


> These APIs are documented as thread safe, and should not change the
> internal flags of the pkey without proper locking.

Where is that?

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4611
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 10 22:37:06 2016
From: rt at openssl.org (Matt Slot via RT)
Date: Sun, 10 Jul 2016 22:37:06 +0000
Subject: [openssl-dev] [openssl.org #4611] PKCS12_create() not
	thread-safe for ECDSA
In-Reply-To: <D3A84461.407F1%mslot@barracuda.com>
References: <RT-Ticket-4611@openssl.org> <D3A7FB10.13970%mslot@barracuda.com>
 <rt-4.0.19-20845-1468179483-721.4611-21-0@openssl.org>
 <918c985206934055a6dbd7d187a47e79@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-20844-1468179660-1313.4611-6-0@openssl.org>
 <D3A84461.407F1%mslot@barracuda.com>
Message-ID: <rt-4.0.19-20845-1468190226-1328.4611-6-0@openssl.org>

On 7/10/16, 3:41 PM, "Salz, Rich via RT" <rt at openssl.org> wrote:
>>These APIs are documented as thread safe, and should not change the
>>internal flags of the pkey without proper locking.
>
>Where is that?

>From https://www.openssl.org/docs/man1.0.2/crypto/threads.html

	"OpenSSL can safely be used in multi-threaded applications provided that
at least two callback functions are set, locking_function and
threadid_func."



===========================================================


Considering Office 365?  Barracuda security and storage solutions can help. Learn more about Barracuda solutions for Office 365 at http://barracuda.com/office365.

DISCLAIMER:
This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4611
Please log in as guest with password guest if prompted


From whelee at gmail.com  Mon Jul 11 02:13:08 2016
From: whelee at gmail.com (Wang Hao Lee)
Date: Mon, 11 Jul 2016 10:13:08 +0800
Subject: [openssl-dev] Openssl apps linker errors after adding new cipher
Message-ID: <CAFRNA=U83Gh_gGijK1YOzdoJFnqNiBkpoxCeBgQQEGPgK=Dfxw@mail.gmail.com>

Dear all,

I'm pretty new to this mailing list so please be easy on me :) I have
integrated a custom 256bit symmetric cipher into OpenSSL 1.0.2g (the ubuntu
version); and now i'm facing linker errors building openssl apps. My new
cipher is called MYCIPH or myciph.

The format for the modifications are as follows:

<Filename>:

x* <Code>

*x indicates the Line No. for the modification/insertion

openssl/Makefile.org:

                97 MYCIPH_ENC= myciph_enc.o

...

144 # dirs in crypto to build

145 SDIRS= \

...

148 des aes rc2 rc4 rc5 idea bf *myciph* cast camellia seed

...

231 MYCIPH_ENC= ?$(MYCIPH_ENC)?

crypto/evp/Makefile:

22 e_des.c e_bf.c e_*myciph*.c e_idea.c ?

...

35 e_des.o e_bf.o e_*myciph*.o e_idea.o ?


obj_mac.num:*

958 *myciph* 958

objects.txt:

421 1 3 3 7 : *MYCIPH*  : *myciph*


evp.h:

87 # define EVP_MAX_IV_LENGTH *32*


782 #endif

783 #ifndef OPENSSL_NO_*MYCIPH*

784 const EVP_CIPHER *EVP_*myciph*(void);

785 #endif

786 # ifndef OPENSSL_NO_RC4


c_allc.c:

145 #ifndef OPENSSL_NO_*MYCIPH*

146 EVP_add_cipher(EVP_*myciph*());

147 EVP_add_cipher_alias(SN_drgn_bd,"*myciph*");

148 EVP_add_cipher_alias(SN_drgn_bd,"*MYCIPH*");

149 #endif

ssl_algs.c:

 81 #ifndef OPENSSL_NO_*MYCIPH*

82 EVP_add_cipher(EVP_*myciph*())?

83 #endif



ssl_locl.h:

357 # define *SSL_MYCIPH*   0x00004000L


ssl_ciph.c:

167 # define *SSL_ENC_MYCIPH_IDX* 14

168 # define SSL_ENC_NUM_IDX 15


172 static const EVP_CIPHER*ssl_cipher_methods[SSL_ENC_NUM_IDX]={

173 NULL,*NULL*,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,

NULL, NULL

174 }?


305 {0, SSL_TXT_*MYCIPH*, 0, 0, 0, SSL_*MYCIPH*, 0, 0, 0, 0, 0, 0},


//void ssl_load_ciphers(void){

407 ssl_cipher_methods[SSL_ENC_*MYCIPH*_IDX]= EVP_get_cipherbyname(SN_
*myciph*)?


//int ssl_cipher_get_evp(...){

//switch (c->algorithm_enc){

585 case SSL_*MYCIPH*:

586 i = SSL_ENC_*MYCIPH*_IDX?

587 break?


675 else if (c->algorithm_enc == SSL_*MYCIPH* &&

676 (evp=EVP_get_cipherbyname("*MYCIPH*")))

677 *enc = evp, *md = NULL?



796 *enc |= (ssl_cipher_methods[SSL_ENC_*MYCIPH*_IDX ] ==

NULL) ? SSL_*MYCIPH* :0?


1784 case SSL_*MYCIPH*:

1785 enc="*MYCIPH*(256)"?

1786 break?


s3_lib.c:

604 {

605 1,

606 SSL3_TXT_RSA_*MYCIPH*,

607 SSL3_CK_RSA_*MYCIPH*,

608 SSL_kRSA,

609 SSL_aRSA,

610 SSL_*MYCIPH*,

611 SSL_MD5,

612 SSL_SSLV3,

613 SSL_NOT_EXP|SSL_MEDIUM,

614 SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,

615 256, //Key-Size (bits)

616 256, //IV-Size (bits)

617 },


ssl.h:

              300 # define SSL_TXT_*MYCIPH* "*MYCIPH*?


ssl3.h:

179 # define SSL3_CK_RSA_*MYCIPH *0x0300001C

...

254 # define SSL3_TXT_RSA_*MYCIPH* "*MYCIPH*"


apps/prog.pl:

85 "cast-cbc", "rc5-cbc", "rc5-ecb", "rc5-cfb", "rc5-ofb",

86 "*myciph*", )

After I changed these files. Compiling using ./config fips; make depend;
make was successful and the apps can link nicely. I even manage to test my
cipher via the EVP interface: openssl speed -evp mynewcipher.

However, when I build by configuring with ./config fips shared; make
depend; make to generate shared objects for libcrypto and libssl I get the
following linker error:

making all in apps...
make[1]: Entering directory
'/home/wanghao/Documents/iVPN/openssl_new/openssl-1.0.2g/apps'
rm -f openssl
shlib_target=; if [ -n "libcrypto.so.1.0.2 libssl.so.1.0.2" ]; then \
shlib_target="linux-shared"; \
elif [ -n "" ]; then \
  FIPSLD_CC="gcc"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC
FIPSLD_CC; \
fi; \
LIBRARIES="-L.. -lssl  -L.. -lcrypto" ; \
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o dgst.o dh.o
dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o
s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o
version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o
pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o" \
LIBDEPS=" $LIBRARIES -ldl" \
link_app.${shlib_target}
make[2]: Entering directory
'/home/wanghao/Documents/iVPN/openssl_new/openssl-1.0.2g/apps'
../libssl.so: undefined reference to `EVP_flcn_bd'
collect2: error: ld returned 1 exit status
../Makefile.shared:171: recipe for target 'link_app.gnu' failed
make[2]: *** [link_app.gnu] Error 1
make[2]: Leaving directory
'/home/wanghao/Documents/iVPN/openssl_new/openssl-1.0.2g/apps'
Makefile:156: recipe for target 'openssl' failed
make[1]: *** [openssl] Error 2
make[1]: Leaving directory
'/home/wanghao/Documents/iVPN/openssl_new/openssl-1.0.2g/apps'
Makefile:297: recipe for target 'build_apps' failed
make: *** [build_apps] Error 1


Did I miss out anything I have to change? Were my changes correct? please
advise thanks.

Best Regards
Wang Hao LEE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160711/5a82a3fa/attachment-0001.html>

From kurt at roeckx.be  Mon Jul 11 09:05:22 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 11 Jul 2016 11:05:22 +0200
Subject: [openssl-dev] MGF1-OAEP with SHA2
In-Reply-To: <42dd9890-9e6f-92db-8071-ae7554fd924b@ades.at>
References: <42dd9890-9e6f-92db-8071-ae7554fd924b@ades.at>
Message-ID: <20160711090521.GA29395@roeckx.be>

On Sat, Jul 09, 2016 at 08:42:39PM +0200, c.holper at ades.at wrote:
> Hi!
> 
> I tried with Openssl 1.0.1t from current Debian testing.
> But I get
> undefined symbol: EVP_PKEY_CTX_set_rsa_oaep_md

1.0.1t is in stable, not testing.

1.0.1 doesn't have that function, 1.0.2 does.


Kurt


From rt at openssl.org  Mon Jul 11 11:34:36 2016
From: rt at openssl.org (Mattias Ellert via RT)
Date: Mon, 11 Jul 2016 11:34:36 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <1468236301.32623.23.camel@physics.uu.se>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
 <1468236301.32623.23.camel@physics.uu.se>
Message-ID: <rt-4.0.19-20845-1468236876-1136.4602-6-0@openssl.org>

fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:
> On Thu, Jul 07, 2016 at 09:40:24PM +0000, Richard Levitte via RT
> wrote:
> > On Sat Jul 02 10:59:38 2016, kurt at roeckx.be wrote:
> > > /* Add to include/openssl/x509v3.h */
> > > 
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> > > 
> > > 
> > > /* Add to crypto/x509v3/v3_purp.c */
> > > 
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags |= ex_flags;
> > > }
> > > 
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags &= ~ex_flags;
> > > }
> > 
> > This gives me the heebie jeebies. ex_flags is used a lot
> > internally, and I
> > can't begin to imagine the consequences of letting external code
> > manipulate
> > this. I understand that in some cases, it seems easy and quick,
> > but...
> > 
> > So, if someone else wants to have a go at this and can make
> > something sensible,
> > please be my guest. Me, I'm backing off from this particular idea.
> 
> Mattias,
> 
> Can you explain why this is needed, what the code is trying to do?
> 
> 
> Kurt
> 

Hi!

The modification of the extension flags happens in at least four
different packages. The modification they do is to add the EXFLAG_PROXY
bit to the flags.

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L692

https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1665
https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1740

https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1655
https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1719

https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L184

I guess having a more restrictive accessor that only sets the
EXFLAG_PROXY bit could work. I suggested the more general solution of
having set/clear accessors for arbitrary flags since it was - well more
general.

	Mattias Ellert

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5032 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160711/87f24a99/attachment.bin>

From rt at openssl.org  Mon Jul 11 12:10:27 2016
From: rt at openssl.org (Dmytro Shamatrin via RT)
Date: Mon, 11 Jul 2016 12:10:27 +0000
Subject: [openssl-dev] [openssl.org #4612] Appcrash on
	SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with
	OpenSSL-1.0.1t
In-Reply-To: <2A55BF74-E647-486D-BF3B-1A2E379315ED@gmail.com>
References: <RT-Ticket-4612@openssl.org>
 <2A55BF74-E647-486D-BF3B-1A2E379315ED@gmail.com>
Message-ID: <rt-4.0.19-20844-1468239027-1115.4612-21-0@openssl.org>

Appcrash on SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with OpenSSL-1.0.1t

After upgrade from OpenSSL-1.0.1L version to 1.0.1t we got Appcrash on windows machine. After investigation I found that it started to happen after R version. 

  #include <string.h>
  #include <openssl/bio.h>
  #include <openssl/ssl.h>
  #include <openssl/err.h>
  #include <openssl/pem.h>
  #include <openssl/x509.h>
  #include <openssl/x509_vfy.h>
  #include <openssl/crypto.h>
  #include <openssl/rand.h>
  #include <openssl/pkcs12.h>
  int main()
  {
    unsigned int off = 0;
    SSL_CTX *sslctx;
    OpenSSL_add_all_algorithms();
    SSL_load_error_strings();
    ERR_load_crypto_strings();
    SSL_library_init();
    sslctx = SSL_CTX_new(SSLv2_server_method());
    // Next line causes an issue
    SSL_CTX_set_options(sslctx, 0);
    return 0;
  }

I used following command to compile this program:

cl /I"." ost.c /link out32dll\ssleay32.lib out32dll\libeay32.lib

If you replace ssleay32.dll and libeay32.dll T with dlls from L version, everything will be working fine.

My OpenSSL compiled with VC6. To confirm that issue is not in the compiler, I've compiled openssl with VC10 and got the same issue.

I've configured OpenSSL and built OpenSSL with:
    perl Configure no-asm -DOPENSSL_USE_IPV6=0 VC-WIN32
    ms\do_ms
    nmake -f ms\ntdll.mak
    nmake -f ms\ntdll.mak test
    nmake -f ms\ntdll.mak install

We can't use x64 compiler, because we use perl, which was compiled many years ago with VC6 x86.
I also can provide my binaries, if required.

Thanks.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4612
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 11 12:10:27 2016
From: rt at openssl.org (gaowenchao via RT)
Date: Mon, 11 Jul 2016 12:10:27 +0000
Subject: [openssl-dev] [openssl.org #4613] openssl RSA key: verify error
	1.0.1t
In-Reply-To: <1b7fce0b.a33f.155d955f770.Coremail.13731461987@126.com>
References: <RT-Ticket-4613@openssl.org>
 <1b7fce0b.a33f.155d955f770.Coremail.13731461987@126.com>
Message-ID: <rt-4.0.19-20844-1468239027-1879.4613-21-0@openssl.org>

| |   | |
| |
|
Dear

I was trying to install openssl 1.0.1t on AIX5.3, and it report error when running "make test". Below is the error test.

CMS consistency test
        /usr/bin/perl cms-test.pl
CMS => PKCS#7 compatibility tests
signed content DER format, RSA key: verify error
make: 1254-004 The error code from the last command is 1.

Stop.
make: 1254-004 The error code from the last command is 2.

Could you please help to confirm whether it's a BUG, or Could you please to give me some advice about this error.

Thanks very much.



--
Gao Wenchao ???
*************************************************************
Phone?13731461987
Mail?gaochaochao501 at 126.com











|
| |
| |   | |
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4613
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 11 12:12:51 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 11 Jul 2016 12:12:51 +0000
Subject: [openssl-dev] [openssl.org #4612] Appcrash on
	SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with
	OpenSSL-1.0.1t
In-Reply-To: <2A55BF74-E647-486D-BF3B-1A2E379315ED@gmail.com>
References: <RT-Ticket-4612@openssl.org>
 <2A55BF74-E647-486D-BF3B-1A2E379315ED@gmail.com>
Message-ID: <rt-4.0.19-20845-1468239171-1439.4612-6-0@openssl.org>

SSLv2 method returns NULL now. Listed in the CHANGES file. SSLv2 has been
removed for security reasons. Do not use it. Also do not use such an old
release. :)

Closing ticket.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4612
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 11 12:14:24 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 11 Jul 2016 12:14:24 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
 <1468236301.32623.23.camel@physics.uu.se>
 <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-20845-1468239264-535.4602-6-0@openssl.org>

On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
> fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:
> > Mattias,
> >
> > Can you explain why this is needed, what the code is trying to do?
> >
> >
> > Kurt
> >
>
> Hi!
>
> The modification of the extension flags happens in at least four
> different packages. The modification they do is to add the
> EXFLAG_PROXY
> bit to the flags.

Ok, I just had a look:

>
https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L692

This looks like an old workaround, and I wonder if it's really needed any more.
If it's still needed, I'd say this may uncover a bug within OpenSSL, but in
that case, I'd rather fix that in 1.1

> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1665
> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1740

I see what this code does, it makes a name constraint check that should have
been present in OpenSSL but wasn't... until 1.1. However, there's other stuff
in that function that looks odd..

> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1655
> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1719

This is the same code as the voms you pointed at above.

>
https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L184

This is the same code as the globus-gsi-callback pointer above.

> I guess having a more restrictive accessor that only sets the
> EXFLAG_PROXY bit could work. I suggested the more general solution of
> having set/clear accessors for arbitrary flags since it was - well
> more
> general.

Mm, I'm really unsure about this one. ex_flags is part of a cache of
information that OpenSSL fiddles with whenever it checks the extensions for a
certificate. Calling anything that ends up calling X509_check_issued(),
X509_check_ca() or X509_check_purpose() will cause values to be checked and
cached for the certificates involved in the call of those functions. In the
proxy certificate case, EXFLAG_PROXY will be set for a certificate any time the
proxyCertInfo is found among its extensions.

To be blunt, I would much rather see a bug report that shows when that cache
isn't being built properly, and possibly a fix for it.

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From cata.vasile at nxp.com  Mon Jul 11 11:57:56 2016
From: cata.vasile at nxp.com (Catalin Vasile)
Date: Mon, 11 Jul 2016 11:57:56 +0000
Subject: [openssl-dev] [ARM] sha1_block_armv8 caller
In-Reply-To: <DB5PR04MB1302492C1377CA38FA9B0CEFEE3F0@DB5PR04MB1302.eurprd04.prod.outlook.com>
References: <DB5PR04MB1302492C1377CA38FA9B0CEFEE3F0@DB5PR04MB1302.eurprd04.prod.outlook.com>
Message-ID: <DB5PR04MB1302073B67DB8E86C1900FF2EE3F0@DB5PR04MB1302.eurprd04.prod.outlook.com>

Hi,

I see that there is function named sha1_block_armv8 defined in crypto/sha/asm/sha1-armv8.pl, but I cannot find any function that calls it.
Which function calls sha1_block_armv8?

Cata    

From rt at openssl.org  Mon Jul 11 12:18:53 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Mon, 11 Jul 2016 12:18:53 +0000
Subject: [openssl-dev] [openssl.org #4613] openssl RSA key: verify error
	1.0.1t
In-Reply-To: <854766e8cfd7465e86e9abe779a758d5@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4613@openssl.org>
 <1b7fce0b.a33f.155d955f770.Coremail.13731461987@126.com>
 <rt-4.0.19-20844-1468239027-1879.4613-21-0@openssl.org>
 <854766e8cfd7465e86e9abe779a758d5@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-20844-1468239533-1795.4613-6-0@openssl.org>

Can you use a more recent version?  1.0.1 is end of life and only getting security fixes (and then only for the rest of the year).

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4613
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 11 12:21:15 2016
From: rt at openssl.org (829272@bugs.debian.org via RT)
Date: Mon, 11 Jul 2016 12:21:15 +0000
Subject: [openssl-dev] Bug#829272: Info received (Fwd: [openssl.org #4602]
	Missing accessors)
In-Reply-To: <handler.829272.B829272.146823942217285.ackinfo@bugs.debian.org>
References: <RT-Ticket-4602@openssl.org>
 <1468239408.725473.14210.nullmailer@rt.openssl.org>
 <handler.829272.B829272.146823942217285.ackinfo@bugs.debian.org>
Message-ID: <rt-4.0.19-20844-1468239675-1053.4602-6-0@openssl.org>

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian OpenSSL Team <pkg-openssl-devel at lists.alioth.debian.org>

If you wish to submit further information on this problem, please
send it to 829272 at bugs.debian.org.

Please do not send mail to owner at bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
829272: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829272
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 11 13:08:32 2016
From: rt at openssl.org (Mattias Ellert via RT)
Date: Mon, 11 Jul 2016 13:08:32 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <1468242505.32623.44.camel@physics.uu.se>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467926949-1421.4602-7-0@openssl.org>
 <rt-4.0.19-1832-1467958101-1276.4602-7-0@openssl.org>
 <1468242505.32623.44.camel@physics.uu.se>
Message-ID: <rt-4.0.19-20845-1468242512-1164.4602-6-0@openssl.org>

fre 2016-07-08 klockan 06:08 +0000 skrev Richard Levitte via RT:
> On Thu Jul 07 21:29:09 2016, levitte wrote:
> > On Sat Jul 02 10:59:38 2016, kurt at roeckx.be wrote:
> > > /* Add to include/openssl/x509_vfy.h : */
> > > 
> > > typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer,
> > > X509_STORE_CTX
> > > *ctx, X509 *x);
> > > typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx,
> > > X509
> > > *x, X509 *issuer);
> > > 
> > > void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> > > X509_STORE_CTX_get_issuer
> > > get_issuer);
> > > X509_STORE_CTX_get_issuer
> > > X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> > > *ctx);
> > > void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> > > X509_STORE_CTX_check_issued
> > > check_issued);
> > > X509_STORE_CTX_check_issued
> > > X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);
> > 
> > For this part, https://github.com/openssl/openssl/pull/1294
> 
> So, looking at this again after some sleep, there's a part of this
> solution
> that I'm unsure of, and it all comes back to X509_STORE_CTX_init(),
> where the
> X509_STORE context gets initialised from the X509_STORE, including
> all the
> function pointers. This has me wonder if the X509_STORE_CTX setters
> should
> really be made available (perhaps with the exception of the verify
> and
> verify_cb ones). Doesn't it make more sense to set those function
> pointers when
> creating the X509_STORE itself? Why would those functions need to be
> changed in
> the context?
> 
> Cheers,
> Richard
> 
> --
> Richard Levitte
> levitte at openssl.org
> 

Looking at the various places in the code where?get_issuer
and?check_issued are accessed, they mostly use the context rather than
the store. Here are the places I have found:

https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71

https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581

https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059

https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997

And the following one actually uses the store and not the context:

https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

	Mattias


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5032 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160711/c275eb5a/attachment.bin>

From dwmw2 at infradead.org  Mon Jul 11 13:34:16 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 11 Jul 2016 14:34:16 +0100
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-20845-1468242512-1164.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467926949-1421.4602-7-0@openssl.org>
 <rt-4.0.19-1832-1467958101-1276.4602-7-0@openssl.org>
 <1468242505.32623.44.camel@physics.uu.se>
 <rt-4.0.19-20845-1468242512-1164.4602-6-0@openssl.org>
Message-ID: <1468244056.4158.241.camel@infradead.org>

On Mon, 2016-07-11 at 13:08 +0000, Mattias Ellert via RT wrote:
> 
> 
> Looking at the various places in the code where?get_issuer
> and?check_issued are accessed, they mostly use the context rather than
> the store. Here are the places I have found:
> 
> https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71
> 
> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581
> 
> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059
> 
> https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997
> 
> And the following one actually uses the store and not the context:
> 
> https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

I was using store.get_issuer() in OpenConnect too, because I need to
manually build the trust chain to include it on the wire ? because
even today the server might *still* suffer RT#1942 and fail to trust
our client cert unless we help it by providing the *right* chain.

I've worked around the lack of access to get_issuer() by doing a dummy
call to X509_verify_cert(), throwing away its result and then hoping
that we have something useful in store.chain (which we *can* still
access). That seems to work but I'm not stunningly happy with it; if we
can have an accessor I'd much rather go back to doing it the old way.

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
(in workaround_openssl_certchain_bug() in the hunk around line 1306)


-- 
dwmw2

From rt at openssl.org  Mon Jul 11 14:04:23 2016
From: rt at openssl.org (David Woodhouse via RT)
Date: Mon, 11 Jul 2016 14:04:23 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <1468244056.4158.241.camel@infradead.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467926949-1421.4602-7-0@openssl.org>
 <rt-4.0.19-1832-1467958101-1276.4602-7-0@openssl.org>
 <1468242505.32623.44.camel@physics.uu.se>
 <rt-4.0.19-20845-1468242512-1164.4602-6-0@openssl.org>
 <1468244056.4158.241.camel@infradead.org>
Message-ID: <rt-4.0.19-20844-1468245863-40.4602-6-0@openssl.org>

On Mon, 2016-07-11 at 13:08 +0000, Mattias Ellert via RT wrote:
> 
> 
> Looking at the various places in the code where?get_issuer
> and?check_issued are accessed, they mostly use the context rather than
> the store. Here are the places I have found:
> 
> https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71
> 
> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581
> 
> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059
> 
> https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997
> 
> And the following one actually uses the store and not the context:
> 
> https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

I was using store.get_issuer() in OpenConnect too, because I need to
manually build the trust chain to include it on the wire ? because
even today the server might *still* suffer RT#1942 and fail to trust
our client cert unless we help it by providing the *right* chain.

I've worked around the lack of access to get_issuer() by doing a dummy
call to X509_verify_cert(), throwing away its result and then hoping
that we have something useful in store.chain (which we *can* still
access). That seems to work but I'm not stunningly happy with it; if we
can have an accessor I'd much rather go back to doing it the old way.

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
(in workaround_openssl_certchain_bug() in the hunk around line 1306)


-- 
dwmw2


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 11 14:58:45 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 11 Jul 2016 14:58:45 +0000
Subject: [openssl-dev] [openssl.org #4611] PKCS12_create() not thread-safe
	for ECDSA
In-Reply-To: <D3A7FB10.13970%mslot@barracuda.com>
References: <RT-Ticket-4611@openssl.org> <D3A7FB10.13970%mslot@barracuda.com>
Message-ID: <rt-4.0.19-20845-1468249125-1883.4611-6-0@openssl.org>

ah, you're right, the lock in EC_KEY should be used. thanks.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4611
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 11 16:20:29 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Mon, 11 Jul 2016 16:20:29 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures
In-Reply-To: <20160711162016.GA3255@roeckx.be>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
Message-ID: <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>

Hi,

When trying to check what happens if we simulate malloc()
returning NULL I'm running into a problem that I'm not sure how to
deal with.

We have CRYPTO_THREAD_run_once(), which takes an init() function
that returns void, so it can't return failures.  At least the
pthread_once() function also has it as void.

But if those functions call malloc() and that returns NULL, we now
don't catch that error, and later just try to use a NULL pointer.

Anybody a good idea how to solve this?


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From kurt at x64architecture.com  Mon Jul 11 17:20:33 2016
From: kurt at x64architecture.com (Kurt Cancemi)
Date: Mon, 11 Jul 2016 13:20:33 -0400
Subject: [openssl-dev] [openssl.org #4612] Appcrash on
	SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with
	OpenSSL-1.0.1t
In-Reply-To: <rt-4.0.19-20844-1468239027-1115.4612-21-0@openssl.org>
References: <RT-Ticket-4612@openssl.org>
 <2A55BF74-E647-486D-BF3B-1A2E379315ED@gmail.com>
 <rt-4.0.19-20844-1468239027-1115.4612-21-0@openssl.org>
Message-ID: <A03FE104-A61A-45FA-B02F-79CE0737B989@x64architecture.com>

Hello,

In 1.0.1s OpenSSL disabled SSLv2 by default in the build. So use perl Configure no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 VC-WIN32

Excerpt from CHANGES

"Changes between 1.0.1r and 1.0.1s [1 Mar 2016]"
?
Disable SSLv2 default build, default negotiation and weak ciphers.  SSLv2
    is by default disabled at build-time.  Builds that are not configured with
    "enable-ssl2" will not support SSLv2.  Even if "enable-ssl2" is used,
    users who want to negotiate SSLv2 via the version-flexible SSLv23_method()
    will need to explicitly call either of:

        SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
    or
        SSL_clear_options(ssl, SSL_OP_NO_SSLv2);

    as appropriate.  Even if either of those is used, or the application
    explicitly uses the version-specific SSLv2_method() or its client and
    server variants, SSLv2 ciphers vulnerable to exhaustive search key
    recovery have been removed.  Specifically, the SSLv2 40-bit EXPORT
    ciphers, and SSLv2 56-bit DES are no longer available.
    (CVE-2016-0800)?

I highly advise you to stay clear of SSLv2 as it has numerous flaws. You are receiving crashes because SSLv2_server_method() returns NULL and SSL_CTX_new() returns NULL because the input argument (the server method) is NULL. You should check the return value of SSL_CTX_new() no matter what because it can fail.

Kurt Cancemi
kurt at x64architecture.com

> On Jul 11, 2016, at 08:10, Dmytro Shamatrin via RT <rt at openssl.org> wrote:
> 
> Appcrash on SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with OpenSSL-1.0.1t
> 
> After upgrade from OpenSSL-1.0.1L version to 1.0.1t we got Appcrash on windows machine. After investigation I found that it started to happen after R version. 


From rt at openssl.org  Mon Jul 11 17:20:47 2016
From: rt at openssl.org (Kurt Cancemi via RT)
Date: Mon, 11 Jul 2016 17:20:47 +0000
Subject: [openssl-dev] [openssl.org #4612] Appcrash on
	SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with
	OpenSSL-1.0.1t
In-Reply-To: <A03FE104-A61A-45FA-B02F-79CE0737B989@x64architecture.com>
References: <RT-Ticket-4612@openssl.org>
 <2A55BF74-E647-486D-BF3B-1A2E379315ED@gmail.com>
 <rt-4.0.19-20844-1468239027-1115.4612-21-0@openssl.org>
 <A03FE104-A61A-45FA-B02F-79CE0737B989@x64architecture.com>
Message-ID: <rt-4.0.19-20844-1468257647-1062.4612-6-0@openssl.org>

Hello,

In 1.0.1s OpenSSL disabled SSLv2 by default in the build. So use perl Configure no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 VC-WIN32

Excerpt from CHANGES

"Changes between 1.0.1r and 1.0.1s [1 Mar 2016]"
?
Disable SSLv2 default build, default negotiation and weak ciphers.  SSLv2
    is by default disabled at build-time.  Builds that are not configured with
    "enable-ssl2" will not support SSLv2.  Even if "enable-ssl2" is used,
    users who want to negotiate SSLv2 via the version-flexible SSLv23_method()
    will need to explicitly call either of:

        SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
    or
        SSL_clear_options(ssl, SSL_OP_NO_SSLv2);

    as appropriate.  Even if either of those is used, or the application
    explicitly uses the version-specific SSLv2_method() or its client and
    server variants, SSLv2 ciphers vulnerable to exhaustive search key
    recovery have been removed.  Specifically, the SSLv2 40-bit EXPORT
    ciphers, and SSLv2 56-bit DES are no longer available.
    (CVE-2016-0800)?

I highly advise you to stay clear of SSLv2 as it has numerous flaws. You are receiving crashes because SSLv2_server_method() returns NULL and SSL_CTX_new() returns NULL because the input argument (the server method) is NULL. You should check the return value of SSL_CTX_new() no matter what because it can fail.

Kurt Cancemi
kurt at x64architecture.com

> On Jul 11, 2016, at 08:10, Dmytro Shamatrin via RT <rt at openssl.org> wrote:
> 
> Appcrash on SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with OpenSSL-1.0.1t
> 
> After upgrade from OpenSSL-1.0.1L version to 1.0.1t we got Appcrash on windows machine. After investigation I found that it started to happen after R version. 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4612
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 11 17:48:06 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Mon, 11 Jul 2016 17:48:06 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc
	failures
In-Reply-To: <2b91a3576c824f4ebb0ea6d08af1ad18@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>
 <2b91a3576c824f4ebb0ea6d08af1ad18@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-20845-1468259286-472.4614-6-0@openssl.org>

Previously we've changed return-types from void to int.  If there's still time, that seems like the thing to do here.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From openssl-users at dukhovni.org  Mon Jul 11 18:14:00 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Jul 2016 18:14:00 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc
 failures
In-Reply-To: <rt-4.0.19-20845-1468259286-472.4614-6-0@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>
 <2b91a3576c824f4ebb0ea6d08af1ad18@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-20845-1468259286-472.4614-6-0@openssl.org>
Message-ID: <20160711181400.GM23906@mournblade.imrryr.org>

On Mon, Jul 11, 2016 at 05:48:06PM +0000, Salz, Rich via RT wrote:

> Previously we've changed return-types from void to int.  If there's still time, that seems like the thing to do here.

With pthread_once and friends the pattern is to use void init
functions, and as necessary check for success by examining the
resulting state after the fact.

The init function passed to pthread_once() is defined to take no
arguments and return no results.

-- 
	Viktor.

From alessandro at ghedini.me  Mon Jul 11 22:14:14 2016
From: alessandro at ghedini.me (Alessandro Ghedini)
Date: Mon, 11 Jul 2016 23:14:14 +0100
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc
 failures
In-Reply-To: <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>
Message-ID: <20160711221414.dkw7jvqq3q5e4jej@kronk.local>

On Mon, Jul 11, 2016 at 04:20:29PM +0000, Kurt Roeckx via RT wrote:
> Hi,
> 
> When trying to check what happens if we simulate malloc()
> returning NULL I'm running into a problem that I'm not sure how to
> deal with.
> 
> We have CRYPTO_THREAD_run_once(), which takes an init() function
> that returns void, so it can't return failures.  At least the
> pthread_once() function also has it as void.
> 
> But if those functions call malloc() and that returns NULL, we now
> don't catch that error, and later just try to use a NULL pointer.
> 
> Anybody a good idea how to solve this?

As Viktor said, init_once is generally used to initialize some kind of global
state, so you can try to check the result after the CRYPTO_THREAD_run_once()
call.

Cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160711/6c96bb0c/attachment.sig>

From bkaduk at akamai.com  Mon Jul 11 23:06:53 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 11 Jul 2016 18:06:53 -0500
Subject: [openssl-dev] Openssl apps linker errors after adding new cipher
In-Reply-To: <CAFRNA=U83Gh_gGijK1YOzdoJFnqNiBkpoxCeBgQQEGPgK=Dfxw@mail.gmail.com>
References: <CAFRNA=U83Gh_gGijK1YOzdoJFnqNiBkpoxCeBgQQEGPgK=Dfxw@mail.gmail.com>
Message-ID: <5784268D.6020300@akamai.com>

On 07/10/2016 09:13 PM, Wang Hao Lee wrote:
>
> After I changed these files. Compiling using ./config fips; make
> depend; make was successful and the apps can link nicely. I
> even manage to test my cipher via the EVP interface: openssl speed
> -evp mynewcipher. 
>
> However, when I build by configuring with ./config fips shared; make
> depend; make to generate shared objects for libcrypto and libssl I get
> the following linker error:
>

If I remember correctly, the Debian packaging adds a layer that uses and
export symbol list to restrict what symbols can be used from the shared
library; presumably Ubuntu has also picked up that bit of code.  Look at
openssl.ld in your source tree.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160711/5553a4e0/attachment.html>

From cata.vasile at nxp.com  Mon Jul 11 11:23:25 2016
From: cata.vasile at nxp.com (Catalin Vasile)
Date: Mon, 11 Jul 2016 11:23:25 +0000
Subject: [openssl-dev] [ARM] sha1_block_armv8 caller
Message-ID: <DB5PR04MB1302492C1377CA38FA9B0CEFEE3F0@DB5PR04MB1302.eurprd04.prod.outlook.com>

Hi,

I see that there is function named sha1_block_armv8 defined in crypto/sha/asm/sha1-armv8.pl, but I cannot find any function that calls it.

Cata

From darshanmody at avaya.com  Tue Jul 12 09:15:42 2016
From: darshanmody at avaya.com (Mody, Darshan (Darshan))
Date: Tue, 12 Jul 2016 09:15:42 +0000
Subject: [openssl-dev] Difference between re-negotiate APIs
Message-ID: <25D2EC755404B4409F263AC6D050FEBB25E256FE@AZ-FFEXMB03.global.avaya.com>

Hi

I find there are 2 APIs for SSL renegotiation. SSL_renegotiate and SSL_renegotiate_abbreviate.

What is the difference between them?

Thanks
Darshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160712/585c8e20/attachment-0001.html>

From matthauck at gmail.com  Tue Jul 12 20:03:24 2016
From: matthauck at gmail.com (Matt Hauck)
Date: Tue, 12 Jul 2016 20:03:24 +0000
Subject: [openssl-dev] EC Keys with a statically linked engine
Message-ID: <CAJyOP_3ivt6jWJuTG9QevNXYt1jOfrvZ3cBKrjKtuyjefdDUxw@mail.gmail.com>

>From my testing, it appears that EC keys that are managed by an engine (in
my case, libp11 <https://github.com/OpenSC/libp11>) are not presently
supported by OpenSSL when the engine is statically linked. This appears
primarily to be due to the implementation of the `ecdsa_check` function in
how it looks up the right method data to call.

(Context: I am currently writing a library that statically links OpenSSL
and am trying to load libp11, statically linked against openssl too. I do
not want to link libp11 statically due to licensing concerns. I have tested
with OpenSSL 1.0.1t and 1.0.2h)

Basically, when I call ECDSA_do_sign from my wrapper library, it calls
`ecdsa_check` with function pointers to its own copies of `ecdsa_free`,
`ecdsa_dup`. However, when the libp11 library loaded the private key and
set its method data (with ECDSA_set_method) from its context, it has
function pointers to its own copies of `ecdsa_free` and friends, and thus
the `EC_KEY_get_key_method_data` function always returns NULL, resulting in
openssl using its own routines to sign/decrypt/etc. rather than using the
engine's routines.

It seems to me that engines which statically link openssl will never work
with EC keys.

I have tested around with RSA keys as well, and they work fine as they do
not have this `ecdsa_check` like function that filters based on function
pointers. The method data there appears to be stored directly on the
private key object.

Questions:
1. Why is method data stored differently on EC keys than on RSA keys?
2. Was there a reason to do this filtering with function pointers this way?
Was it only to distinguish ECDSA and ECDH function data?
3. If we were to patch openssl to store this method data directly on the EC
key struct, is there anything we should be aware of breaking? Would a patch
along these lines be accepted upstream?

Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160712/3df09b13/attachment.html>

From davidben at google.com  Wed Jul 13 06:19:22 2016
From: davidben at google.com (David Benjamin)
Date: Wed, 13 Jul 2016 06:19:22 +0000
Subject: [openssl-dev] File-based bntest
Message-ID: <CAF8qwaB0AXURjt4VpEzuPw=QV1Xrg3CO2+9Q6VDL7fLpCUTxnQ@mail.gmail.com>

Hi folks,

We recently rewrote bntest to take a test vector file rather than
generating random numbers and checking by piping to bc. I figured I'd send
a pointer your way in case you were interested in this. It takes a lot less
effort to add a new test case and is easier to run on, say, a phone where
perl and bc may not be readily available.

The BN calling code is probably not very useful to you as it's all C++ and
uses our FileTest framework. But the test vectors are below, as well as a
Go tool to validate them.
https://boringssl.googlesource.com/boringssl/+/master/crypto/bn/bn_test.cc
https://boringssl.googlesource.com/boringssl/+/master/crypto/bn/bn_tests.txt
https://boringssl.googlesource.com/boringssl/+/master/crypto/bn/check_bn_tests.go

The vectors themselves are more-or-less just taken from a run of bntest,
though I did add carry tests for BN_add, etc. I'm sure there's room for
other interesting cases.

Hope this is useful,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160713/52740cce/attachment.html>

From nikhil.agarwal at nxp.com  Wed Jul 13 10:05:51 2016
From: nikhil.agarwal at nxp.com (Nikhil Agarwal)
Date: Wed, 13 Jul 2016 10:05:51 +0000
Subject: [openssl-dev] HMAC with Engine support
Message-ID: <DB5PR04MB1655C1EA9CF2B8212D51533F93310@DB5PR04MB1655.eurprd04.prod.outlook.com>

Hi All,

Is there any way in OPENSSL so that it can offload HMAC operation directly to engine.  As far as I understood from code, OPENSSL generates ipad/opad internally and uses engine only for HASH functions. Please suggest. I need this as the keys that are being used for this operation are blackened by HW Crypto engine and now only HW can use these keys.

Thanks in Advance
Nikhil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160713/3e8bdd76/attachment.html>

From rt at openssl.org  Wed Jul 13 17:09:30 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 13 Jul 2016 17:09:30 +0000
Subject: [openssl-dev] [openssl.org #4605] OCSP accessors
In-Reply-To: <20160705133323.GA31096@roeckx.be>
References: <RT-Ticket-4605@openssl.org> <20160705133323.GA31096@roeckx.be>
Message-ID: <rt-4.0.19-9387-1468429770-1919.4605-6-0@openssl.org>

Fixed now, ticket closed.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4605
Please log in as guest with password guest if prompted


From whelee at gmail.com  Thu Jul 14 03:09:36 2016
From: whelee at gmail.com (Wang Hao Lee)
Date: Thu, 14 Jul 2016 11:09:36 +0800
Subject: [openssl-dev] Openssl apps linker errors after adding new cipher
In-Reply-To: <5784268D.6020300@akamai.com>
References: <CAFRNA=U83Gh_gGijK1YOzdoJFnqNiBkpoxCeBgQQEGPgK=Dfxw@mail.gmail.com>
 <5784268D.6020300@akamai.com>
Message-ID: <CAFRNA=XTtf8pFn_+Du4wJ-H+WDPZzmQHzgV+mwt+QErFoT9UZA@mail.gmail.com>

Hi Benjamin

Great advice. After adding the symbol EVP_myciph to openssl.ld linker
script. It compiled without problems.

Cheers!

Regards
Wang Hao

On Tue, Jul 12, 2016 at 7:06 AM, Benjamin Kaduk <bkaduk at akamai.com> wrote:

> On 07/10/2016 09:13 PM, Wang Hao Lee wrote:
>
>
> After I changed these files. Compiling using ./config fips; make depend;
> make was successful and the apps can link nicely. I even manage to test my
> cipher via the EVP interface: openssl speed -evp mynewcipher.
>
> However, when I build by configuring with ./config fips shared; make
> depend; make to generate shared objects for libcrypto and libssl I get the
> following linker error:
>
>
> If I remember correctly, the Debian packaging adds a layer that uses and
> export symbol list to restrict what symbols can be used from the shared
> library; presumably Ubuntu has also picked up that bit of code.  Look at
> openssl.ld in your source tree.
>
> -Ben
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160714/c3decc07/attachment-0001.html>

From rt at openssl.org  Thu Jul 14 11:25:22 2016
From: rt at openssl.org (Anirudh Patel via RT)
Date: Thu, 14 Jul 2016 11:25:22 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange
	with X509_LOOKUP_add_dir
In-Reply-To: <CAKUCFqd0xa14SvQBJQH7gRbJq8sRVgz+2+TVFUceyaAHRGE9WQ@mail.gmail.com>
References: <RT-Ticket-4615@openssl.org>
 <CAKUCFqd0xa14SvQBJQH7gRbJq8sRVgz+2+TVFUceyaAHRGE9WQ@mail.gmail.com>
Message-ID: <rt-4.0.19-9387-1468495522-1875.4615-21-0@openssl.org>

Hi,

I have a query related to how these APIs X509_STORE_add_lookup()
and X509_LOOKUP_add_dir() work. Let me give you a brief explanation of what
I am doing:

Purpose was to add lookup for CRLs.

First when my server starts and my SSL initializes I have successfully
created a store to which lookup has been added for CRL directory.

   - pLookup = X509_STORE_add_lookup(store, X509_LOOKUP_hash_dir());
   - X509_LOOKUP_add_dir(pLookup, mCRLPath.c_str(), X509_FILETYPE_PEM)

Example CRL Directory: /var/cert/CRL/
Scenario:
1) When the system start no CRL files are present in the CRL Directory
2) Client_1 initiates a connection to my server (using openssl s_client)
3) Openssl does the lookup of CRLs for the corresponding (Sub) CAs and does
not find anything thus, giving error in the verify_callback
(UNABLE_TO_GET_CRL). In the application code I have     handled these
errors gracefully Callback is again called for further validation and the
connection is accepted.
*Result: Satisfied*

1) Now, I place two CRLs (Sub CA,Root CA) in the CRL directory (server was
still up and I did not stopped it)
    I have created a crl -hash (issuer hash) and linked them to CRL pem
certificates.
    *$hash(rootca).r0 -> root_ca.pem*
    *$hash(subca).r0 -> sub_ca.pem*
2) Client_1 again initiates a connection to my server (using openssl
s_client) (client certificate chain is : ID/Sub CA/Root CA)
3) Openssl does a lookup of CRLs and does not throw any error. Validation
happened with verify_callback getting invoked 3 times with preverify_ok =
1. Client connection is accepted
*Result: Satisfied*

1) Now, I removed the above CRL files (Sub CA/Root CA) from the CRL
directory. Based on the manual page these CRLs should be now in the cached
memory of X509_OBJECT.
2) I repeated steps (2) and (3). Connection gets accepted from the client.
Everything still works fine because openssl maintined CRL files in its
cache and found them during the lookup.
*Result: Satisfied*

Now from here the problem starts:
=========================
1) My Sub_CA revoked Client_1 certificate (since Sub_CA was the issuing CA
in the first place)
2) I recreated Sub_CA CRL and placed it in the CRL Directory.
3) Created the hash and linked it as follows:
    *$hash(sub_ca).r1* -> sub_ca.pem  (hoping that openssl still has
$hash(sub_ca).r0 in its cache, since above we have seen that the lookup
worked even when I removed the CRL files from       the CRL Directory)
4) Client_1 initiates a connection to my server and gets accepted
successfully ==== Should Not Have Happened
Based on the manual page for *X509_LOOKUP_hash_dir
- https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html
<https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html>*

> When checking for new CRLs once one CRL for given hash value is loaded,
> hash_dir lookup method checks only for certificates with sequence number
> greater than that of the already cached CRL.

Since, the sequence number has changed from r0 to r1 for same issuer
(sub_ca in my case) openssl should have done a lookup and based on the
latest sequence number should have given me an error stating Client
Certificate has been revoked.

Just to let you know, I have tested revoked certificates with the CRL and
it works fine. So no problem with that.
Openssl Version I am using is *OpenSSL 1.0.1e-fips 11 Feb 2013*

Eagerly awaiting your response. Need to implement CRL functionality ASAP
and hoping to get all the help from you guys.

Regards,
Anirudh

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu Jul 14 12:22:08 2016
From: rt at openssl.org (Anirudh Patel via RT)
Date: Thu, 14 Jul 2016 12:22:08 +0000
Subject: [openssl-dev] [openssl.org #4615] AutoReply: Cache utility
	behaving strange with X509_LOOKUP_add_dir
In-Reply-To: <CAKUCFqeK6rce1bC-J=CYJfsAgRdQ9FfRqHpNTAwJG1okrOKQGQ@mail.gmail.com>
References: <RT-Ticket-4615@openssl.org>
 <CAKUCFqeK6rce1bC-J=CYJfsAgRdQ9FfRqHpNTAwJG1okrOKQGQ@mail.gmail.com>
Message-ID: <rt-4.0.19-9387-1468498928-1945.4615-6-0@openssl.org>

On Thu, Jul 14, 2016 at 4:55 PM, The default queue via RT <rt at openssl.org>
wrote:

>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
>         "Cache utility behaving strange with X509_LOOKUP_add_dir",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [openssl.org #4615].
>
> Please include the string:
>
>          [openssl.org #4615]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
>                         Thank you,
>                         rt at openssl.org
>
> -------------------------------------------------------------------------
> Hi,
>
> I have a query related to how these APIs X509_STORE_add_lookup()
> and X509_LOOKUP_add_dir() work. Let me give you a brief explanation of what
> I am doing:
>
> Purpose was to add lookup for CRLs.
>
> First when my server starts and my SSL initializes I have successfully
> created a store to which lookup has been added for CRL directory.
>
>    - pLookup = X509_STORE_add_lookup(store, X509_LOOKUP_hash_dir());
>    - X509_LOOKUP_add_dir(pLookup, mCRLPath.c_str(), X509_FILETYPE_PEM)
>
> Example CRL Directory: /var/cert/CRL/
> Scenario:
> 1) When the system start no CRL files are present in the CRL Directory
> 2) Client_1 initiates a connection to my server (using openssl s_client)
> 3) Openssl does the lookup of CRLs for the corresponding (Sub) CAs and does
> not find anything thus, giving error in the verify_callback
> (UNABLE_TO_GET_CRL). In the application code I have     handled these
> errors gracefully Callback is again called for further validation and the
> connection is accepted.
> *Result: Satisfied*
>
> 1) Now, I place two CRLs (Sub CA,Root CA) in the CRL directory (server was
> still up and I did not stopped it)
>     I have created a crl -hash (issuer hash) and linked them to CRL pem
> certificates.
>     *$hash(rootca).r0 -> root_ca.pem*
>     *$hash(subca).r0 -> sub_ca.pem*
> 2) Client_1 again initiates a connection to my server (using openssl
> s_client) (client certificate chain is : ID/Sub CA/Root CA)
> 3) Openssl does a lookup of CRLs and does not throw any error. Validation
> happened with verify_callback getting invoked 3 times with preverify_ok =
> 1. Client connection is accepted
> *Result: Satisfied*
>
> 1) Now, I removed the above CRL files (Sub CA/Root CA) from the CRL
> directory. Based on the manual page these CRLs should be now in the cached
> memory of X509_OBJECT.
> 2) I repeated steps (2) and (3). Connection gets accepted from the client.
> Everything still works fine because openssl maintined CRL files in its
> cache and found them during the lookup.
> *Result: Satisfied*
>
> Now from here the problem starts:
> =========================
> 1) My Sub_CA revoked Client_1 certificate (since Sub_CA was the issuing CA
> in the first place)
> 2) I recreated Sub_CA CRL and placed it in the CRL Directory.
> 3) Created the hash and linked it as follows:
>     *$hash(sub_ca).r1* -> sub_ca.pem  (hoping that openssl still has
> $hash(sub_ca).r0 in its cache, since above we have seen that the lookup
> worked even when I removed the CRL files from       the CRL Directory)
> 4) Client_1 initiates a connection to my server and gets accepted
> successfully ==== Should Not Have Happened
> Based on the manual page for *X509_LOOKUP_hash_dir
> - https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html
> <https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html>*
>
> > When checking for new CRLs once one CRL for given hash value is loaded,
> > hash_dir lookup method checks only for certificates with sequence number
> > greater than that of the already cached CRL.
>
> Since, the sequence number has changed from r0 to r1 for same issuer
> (sub_ca in my case) openssl should have done a lookup and based on the
> latest sequence number should have given me an error stating Client
> Certificate has been revoked.
>
> Just to let you know, I have tested revoked certificates with the CRL and
> it works fine. So no problem with that.
> Openssl Version I am using is *OpenSSL 1.0.1e-fips 11 Feb 2013*
>
> Eagerly awaiting your response. Need to implement CRL functionality ASAP
> and hoping to get all the help from you guys.
>
> Regards,
> Anirudh
>
>
> -------------------------------------------------------------------------
> http://rt.openssl.org/Ticket/Display.html?id=4615&user=guest&pass=guest
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted


From appro at openssl.org  Thu Jul 14 12:54:41 2016
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 14 Jul 2016 14:54:41 +0200
Subject: [openssl-dev] [ARM] sha1_block_armv8 caller
In-Reply-To: <DB5PR04MB1302492C1377CA38FA9B0CEFEE3F0@DB5PR04MB1302.eurprd04.prod.outlook.com>
References: <DB5PR04MB1302492C1377CA38FA9B0CEFEE3F0@DB5PR04MB1302.eurprd04.prod.outlook.com>
Message-ID: <57878B91.3070205@openssl.org>

> I see that there is function named sha1_block_armv8 defined in
> crypto/sha/asm/sha1-armv8.pl, but I cannot find any function that
> calls it.

Note that symbol is not global, you can't even link to it from outside.
But the real question is if code is *executed*. As calling is not the
only way to get code executed, you can also branch to it. And that's
what happens, there is branch to symbol's "shadow" .Lv8_entry label from
sha1_block_data_order. Why does it branch to "shadow" label? In order to
prevent assembler from generating relocation for linker to resolve. Why
symbol at all? It's development artefact (general-purpose
sha1_block_data_order and sha1_block_armv8 were developed one after
another), but it's still useful when it comes to debugging or profiling.
And it also allows to change mind about not making the symbol global,
for example if module needs to be re-purposed.


From rt at openssl.org  Thu Jul 14 13:36:53 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Thu, 14 Jul 2016 13:36:53 +0000
Subject: [openssl-dev] [openssl.org #4609] Configure does not honor
	requests for ld.gold
In-Reply-To: <578795DB.6000308@openssl.org>
References: <RT-Ticket-4609@openssl.org>
 <CAH8yC8m2o5Man2Qq8QYgK9djSFvk1k0ccL8eiws7u8EYBLK7ng@mail.gmail.com>
 <rt-4.0.19-29976-1467964035-1018.4609-21-0@openssl.org>
 <8a8fcdb4dde349d59a74c8a3c4a41d21@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-29976-1467981181-1124.4609-6-0@openssl.org>
 <CAH8yC8mc+oKSHgEwmFuzjpMaA=k+C2+=nCcQ1Waey0UxzCCdTw@mail.gmail.com>
 <rt-4.0.19-15716-1468002566-803.4609-6-0@openssl.org>
 <578795DB.6000308@openssl.org>
Message-ID: <rt-4.0.19-10620-1468503413-1027.4609-6-0@openssl.org>

>> I don't know what you expect us to do.  We don't use the LD variable.
> 
> Right. I'm just pointing out gaps.
> 
> It only gets worse for users. What happens when someone tries a
> cross-compile by setting CC, AR, RANLIB, LD and a CFLAGS with
> --sysroot? As far as I know, there is no RTFM for cross-compiles.

Can there be one? Do we know that *all* cross-compile environments are
so similar that one can actually formulate universal TFM? Well, I'm not
saying that it's impossible to be more "eloquent" than to mention
--cross-compile-prefix and CROSS_COMPILE variable in ./INSTALL and
discuss them more specifically in Configurations/10-main.cf for Android
and iOS, I only question how "F" a "TFM" can really get. You say "it
only gets worse for users." Well, what users? For example today Debian
users can have it really simple by installing prepackaged cross
compilers along with cross-dev packages and just specify
--cross-compile-prefix alone, no need to bother with --sysroot or
anything. Moreover, if you are creative enough you can even note that if
you install qemu-user, arrange binfmt and set some variables (or create
some symbolic links) you'll be able to execute resulting alien Linux
binaries as if they were native directly from your shell prompt...
Bottom line is that there are so many variables that apparent gaps are
kind of inevitable...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted


From uri at ll.mit.edu  Thu Jul 14 20:59:47 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 14 Jul 2016 20:59:47 +0000
Subject: [openssl-dev] Error is a pod file
Message-ID: <D3AD757E.2F2EA%uri@ll.mit.edu>

install ./doc/crypto/BIO_set_callback.pod ->
/Users/ur20980/src/openssl-1.1/share/man/man3/BIO_set_callback.3
IO::File=IO(0x7f896a02d1c0) around line 42: =over should be: '=over' or
'=over positive_number'
POD document had syntax errors at /opt/local/bin/pod2man line 68.
make: *** [install_man_docs] Error 1

-- 
Regards,
Uri Blumenthal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5227 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160714/4a794985/attachment.bin>

From rsalz at akamai.com  Fri Jul 15 02:55:15 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 15 Jul 2016 02:55:15 +0000
Subject: [openssl-dev] Error is a pod file
In-Reply-To: <D3AD757E.2F2EA%uri@ll.mit.edu>
References: <D3AD757E.2F2EA%uri@ll.mit.edu>
Message-ID: <52d9b2c74d7b4985a1f9315e104226de@usma1ex-dag1mb1.msg.corp.akamai.com>

> install ./doc/crypto/BIO_set_callback.pod ->
> /Users/ur20980/src/openssl-1.1/share/man/man3/BIO_set_callback.3
> IO::File=IO(0x7f896a02d1c0) around line 42: =over should be: '=over' or
> '=over positive_number'
	
I don't understand this error message. "=over" should be "=over"?

Does adding a blank line after it fix the problem?

From levitte at openssl.org  Fri Jul 15 05:34:49 2016
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 15 Jul 2016 07:34:49 +0200 (CEST)
Subject: [openssl-dev] Error is a pod file
In-Reply-To: <52d9b2c74d7b4985a1f9315e104226de@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <D3AD757E.2F2EA%uri@ll.mit.edu>
 <52d9b2c74d7b4985a1f9315e104226de@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160715.073449.1722698424718647091.levitte@openssl.org>

In message <52d9b2c74d7b4985a1f9315e104226de at usma1ex-dag1mb1.msg.corp.akamai.com> on Fri, 15 Jul 2016 02:55:15 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> > install ./doc/crypto/BIO_set_callback.pod ->
rsalz> > /Users/ur20980/src/openssl-1.1/share/man/man3/BIO_set_callback.3
rsalz> > IO::File=IO(0x7f896a02d1c0) around line 42: =over should be: '=over' or
rsalz> > '=over positive_number'
rsalz> 	
rsalz> I don't understand this error message. "=over" should be "=over"?
rsalz> 
rsalz> Does adding a blank line after it fix the problem?

Yes.

In the POD format, everything is a paragraph, each separated from the
others with a blank line.  That includes command paragraphs.  So, what
looks like a command line to you was actually this command paragraph:

    =over
    The BIO the callback is attached to is passed in B<b>.

... and I'm pretty sure that no pod processor knows what to do with
the '=over' argument "The BIO the callback is attached to is passed in
B<b>.", hence the error message.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Fri Jul 15 05:52:55 2016
From: rt at openssl.org (Anirudh Patel via RT)
Date: Fri, 15 Jul 2016 05:52:55 +0000
Subject: [openssl-dev] Fwd: [openssl.org #4615] Cache utility behaving
	strange with X509_LOOKUP_add_dir
In-Reply-To: <CAKUCFqff-tHn38AnLawx+5Oin9yAAT0ioF-wiP8afs+njtVV3w@mail.gmail.com>
References: <RT-Ticket-4615@openssl.org>
 <CAKUCFqff-tHn38AnLawx+5Oin9yAAT0ioF-wiP8afs+njtVV3w@mail.gmail.com>
Message-ID: <rt-4.0.19-10620-1468561975-610.4615-6-0@openssl.org>

It will be very helpful if you could provide your inputs on this as soon as
possible so that I can move ahead quickly.

Regards,
Anirudh

---------- Forwarded message ----------
From: The default queue via RT <rt at openssl.org>
Date: Thu, Jul 14, 2016 at 4:55 PM
Subject: [openssl.org #4615] AutoReply: Cache utility behaving strange with
X509_LOOKUP_add_dir
To: patel3.anirudh at gmail.com



Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
        "Cache utility behaving strange with X509_LOOKUP_add_dir",
a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been
assigned an ID of [openssl.org #4615].

Please include the string:

         [openssl.org #4615]

in the subject line of all future correspondence about this issue. To do so,
you may reply to this message.

                        Thank you,
                        rt at openssl.org

-------------------------------------------------------------------------
Hi,

I have a query related to how these APIs X509_STORE_add_lookup()
and X509_LOOKUP_add_dir() work. Let me give you a brief explanation of what
I am doing:

Purpose was to add lookup for CRLs.

First when my server starts and my SSL initializes I have successfully
created a store to which lookup has been added for CRL directory.

   - pLookup = X509_STORE_add_lookup(store, X509_LOOKUP_hash_dir());
   - X509_LOOKUP_add_dir(pLookup, mCRLPath.c_str(), X509_FILETYPE_PEM)

Example CRL Directory: /var/cert/CRL/
Scenario:
1) When the system start no CRL files are present in the CRL Directory
2) Client_1 initiates a connection to my server (using openssl s_client)
3) Openssl does the lookup of CRLs for the corresponding (Sub) CAs and does
not find anything thus, giving error in the verify_callback
(UNABLE_TO_GET_CRL). In the application code I have     handled these
errors gracefully Callback is again called for further validation and the
connection is accepted.
*Result: Satisfied*

1) Now, I place two CRLs (Sub CA,Root CA) in the CRL directory (server was
still up and I did not stopped it)
    I have created a crl -hash (issuer hash) and linked them to CRL pem
certificates.
    *$hash(rootca).r0 -> root_ca.pem*
    *$hash(subca).r0 -> sub_ca.pem*
2) Client_1 again initiates a connection to my server (using openssl
s_client) (client certificate chain is : ID/Sub CA/Root CA)
3) Openssl does a lookup of CRLs and does not throw any error. Validation
happened with verify_callback getting invoked 3 times with preverify_ok =
1. Client connection is accepted
*Result: Satisfied*

1) Now, I removed the above CRL files (Sub CA/Root CA) from the CRL
directory. Based on the manual page these CRLs should be now in the cached
memory of X509_OBJECT.
2) I repeated steps (2) and (3). Connection gets accepted from the client.
Everything still works fine because openssl maintined CRL files in its
cache and found them during the lookup.
*Result: Satisfied*

Now from here the problem starts:
=========================
1) My Sub_CA revoked Client_1 certificate (since Sub_CA was the issuing CA
in the first place)
2) I recreated Sub_CA CRL and placed it in the CRL Directory.
3) Created the hash and linked it as follows:
    *$hash(sub_ca).r1* -> sub_ca.pem  (hoping that openssl still has
$hash(sub_ca).r0 in its cache, since above we have seen that the lookup
worked even when I removed the CRL files from       the CRL Directory)
4) Client_1 initiates a connection to my server and gets accepted
successfully ==== Should Not Have Happened
Based on the manual page for *X509_LOOKUP_hash_dir
- https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html
<https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html>*

> When checking for new CRLs once one CRL for given hash value is loaded,
> hash_dir lookup method checks only for certificates with sequence number
> greater than that of the already cached CRL.

Since, the sequence number has changed from r0 to r1 for same issuer
(sub_ca in my case) openssl should have done a lookup and based on the
latest sequence number should have given me an error stating Client
Certificate has been revoked.

Just to let you know, I have tested revoked certificates with the CRL and
it works fine. So no problem with that.
Openssl Version I am using is *OpenSSL 1.0.1e-fips 11 Feb 2013*

Eagerly awaiting your response. Need to implement CRL functionality ASAP
and hoping to get all the help from you guys.

Regards,
Anirudh


-------------------------------------------------------------------------
http://rt.openssl.org/Ticket/Display.html?id=4615&user=guest&pass=guest

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted


From rsalz at akamai.com  Fri Jul 15 12:15:39 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 15 Jul 2016 12:15:39 +0000
Subject: [openssl-dev] Error is a pod file
In-Reply-To: <20160715.073449.1722698424718647091.levitte@openssl.org>
References: <D3AD757E.2F2EA%uri@ll.mit.edu>
 <52d9b2c74d7b4985a1f9315e104226de@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.073449.1722698424718647091.levitte@openssl.org>
Message-ID: <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>


> In the POD format, everything is a paragraph, each separated from the
> others with a blank line.

Time to add something to find-doc-nits, perhaps.



From levitte at openssl.org  Fri Jul 15 13:10:55 2016
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 15 Jul 2016 15:10:55 +0200 (CEST)
Subject: [openssl-dev] Error is a pod file
In-Reply-To: <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <52d9b2c74d7b4985a1f9315e104226de@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.073449.1722698424718647091.levitte@openssl.org>
 <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160715.151055.2146531854738957342.levitte@openssl.org>

In message <008b774a63414d9bb286ff344ddac838 at usma1ex-dag1mb1.msg.corp.akamai.com> on Fri, 15 Jul 2016 12:15:39 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> 
rsalz> > In the POD format, everything is a paragraph, each separated from the
rsalz> > others with a blank line.
rsalz> 
rsalz> Time to add something to find-doc-nits, perhaps.

man podchecker

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Fri Jul 15 13:22:18 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 15 Jul 2016 13:22:18 +0000
Subject: [openssl-dev] [openssl.org #4611] PKCS12_create() not thread-safe
	for ECDSA
In-Reply-To: <D3A7FB10.13970%mslot@barracuda.com>
References: <RT-Ticket-4611@openssl.org> <D3A7FB10.13970%mslot@barracuda.com>
Message-ID: <rt-4.0.19-9387-1468588938-1706.4611-6-0@openssl.org>

On Sun Jul 10 19:38:03 2016, mslot at barracuda.com wrote:
> OpenSSL 1.0.2h
>
> The function eckey_priv_encode() may crash if the same pkey is
> serialized from multiple threads. Here is a sample backtrace:
>
> #0 0x00007fff8f321f92 in _platform_memmove$VARIANT$Haswell ()
> #1 0x0000000100196132 in i2c_ASN1_BIT_STRING
> #2 0x00000001001a1fb2 in asn1_ex_i2c
> #3 0x00000001001a1e68 in asn1_i2d_ex_primitive
> #4 0x00000001001a19fd in ASN1_item_ex_i2d
> #5 0x00000001001a1d8b in asn1_template_ex_i2d
> #6 0x00000001001a1a8b in ASN1_item_ex_i2d
> #7 0x00000001001a16d0 in asn1_item_flags_i2d
> #8 0x0000000100149d3e in i2d_ECPrivateKey
> #9 0x000000010014e576 in eckey_priv_encode
> #10 0x000000010018e9f9 in EVP_PKEY2PKCS8_broken
> #11 0x00000001001d38d9 in PKCS12_add_key
> #12 0x00000001001d35a3 in PKCS12_create
>
> EC_KEY_set_enc_flags() is called to modify/restore the encoding flags
> within the EC_KEY. Two calls are made to i2d_ECPrivateKey(). The first
> calculates the necessary buffer length, the second serializes the data
> into an allocated buffer. If the flags change during this period, the
> second call overwrites the buffer.
>
> These APIs are documented as thread safe, and should not change the
> internal flags of the pkey without proper locking.

Problem fixed in upcoming 1.1.0 and 1.0.2 releases. The issue was actually that
the input EC_KEY was modified at all. The code has been modified to take a
temporary shallow copy of the input EC_KEY and modify the copy instead.

Relevant commits are:

b8a7bd83e68405fdf595077973035ac6fe24cb97 (master branch)
427b22646d4642809f67352513590549650b916f (1.0.2 branch)

Closing this ticket.
Cheers,
Richard
--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4611
Please log in as guest with password guest if prompted


From rsalz at akamai.com  Fri Jul 15 15:06:55 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 15 Jul 2016 15:06:55 +0000
Subject: [openssl-dev] Error is a pod file
In-Reply-To: <20160715.151055.2146531854738957342.levitte@openssl.org>
References: <52d9b2c74d7b4985a1f9315e104226de@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.073449.1722698424718647091.levitte@openssl.org>
 <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.151055.2146531854738957342.levitte@openssl.org>
Message-ID: <425c384a54734c669753079a081826e8@usma1ex-dag1mb1.msg.corp.akamai.com>


> rsalz> Time to add something to find-doc-nits, perhaps.
> 
> man podchecker

Find-doc-nits calls podchecker and saw no complaint.

From levitte at openssl.org  Fri Jul 15 15:55:04 2016
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 15 Jul 2016 17:55:04 +0200 (CEST)
Subject: [openssl-dev] Error is a pod file
In-Reply-To: <425c384a54734c669753079a081826e8@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.151055.2146531854738957342.levitte@openssl.org>
 <425c384a54734c669753079a081826e8@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160715.175504.1790203699538086422.levitte@openssl.org>

In message <425c384a54734c669753079a081826e8 at usma1ex-dag1mb1.msg.corp.akamai.com> on Fri, 15 Jul 2016 15:06:55 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> 
rsalz> > rsalz> Time to add something to find-doc-nits, perhaps.
rsalz> > 
rsalz> > man podchecker
rsalz> 
rsalz> Find-doc-nits calls podchecker and saw no complaint.

perl util/find-doc-nits.pl -s

(I don't know what -s is for, but apparently, podchecker isn't run
unless you use that option)

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Fri Jul 15 15:59:10 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 15 Jul 2016 15:59:10 +0000
Subject: [openssl-dev] Error is a pod file
In-Reply-To: <20160715.175504.1790203699538086422.levitte@openssl.org>
References: <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.151055.2146531854738957342.levitte@openssl.org>
 <425c384a54734c669753079a081826e8@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.175504.1790203699538086422.levitte@openssl.org>
Message-ID: <e70035e75a1b4453b506c5af536ba59c@usma1ex-dag1mb1.msg.corp.akamai.com>


> perl util/find-doc-nits.pl -s
> 
> (I don't know what -s is for, but apparently, podchecker isn't run unless you
> use that option)

Forgot my own code :(

-s for stricter checking.

From paladinchen at tencent.com  Sat Jul 16 05:21:57 2016
From: paladinchen at tencent.com (=?utf-8?B?cGFsYWRpbmNoZW4o6ZmI5aWHKQ==?=)
Date: Sat, 16 Jul 2016 05:21:57 +0000
Subject: [openssl-dev] SSL_read return error
References: <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>, 
 <20160715.151055.2146531854738957342.levitte@openssl.org>,
 <425c384a54734c669753079a081826e8@usma1ex-dag1mb1.msg.corp.akamai.com>,
 <20160715.175504.1790203699538086422.levitte@openssl.org>,
 <e70035e75a1b4453b506c5af536ba59c@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <637561A39544634DB045D672FFD2217D4A546C@EXMBX-SZMAIL006.tencent.com>

Hi ,
    use openSSL lib run sometimes?and generate this error , i can't find reason ,this issue always puzzled me
please help me, thank you .

    error log :Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message type:s3_clnt.c:700


________________________________
paladinchen(??)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160716/ec791ca8/attachment.html>

From fedor at indutny.com  Sat Jul 16 06:02:07 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Sat, 16 Jul 2016 02:02:07 -0400
Subject: [openssl-dev] SSL_read return error
In-Reply-To: <637561A39544634DB045D672FFD2217D4A546C@EXMBX-SZMAIL006.tencent.com>
References: <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.151055.2146531854738957342.levitte@openssl.org>
 <425c384a54734c669753079a081826e8@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.175504.1790203699538086422.levitte@openssl.org>
 <e70035e75a1b4453b506c5af536ba59c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <637561A39544634DB045D672FFD2217D4A546C@EXMBX-SZMAIL006.tencent.com>
Message-ID: <CAEv2VfJTg1MB2sECG6wDc2cyGCveFXW58hcSE0wbKTH+gu8Epg@mail.gmail.com>

Hello!

It looks like the server replies with a bad data sometimes. I wonder if
server could be speaking different protocols at such moments?

Hope it helps,
Fedor.

On Sat, Jul 16, 2016 at 1:21 AM, paladinchen(??) <paladinchen at tencent.com>
wrote:

> Hi ,
>     use openSSL lib run sometimes?and generate this error , i can't find
> reason ,this issue always puzzled me
> please help me, thank you .
>
>     error log :
> Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message type:s3_clnt.c:700
>
>
> ------------------------------
> paladinchen(??)
>
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160716/baa41c7d/attachment.html>

From paladinchen at tencent.com  Sat Jul 16 07:09:58 2016
From: paladinchen at tencent.com (=?utf-8?B?cGFsYWRpbmNoZW4o6ZmI5aWHKQ==?=)
Date: Sat, 16 Jul 2016 07:09:58 +0000
Subject: [openssl-dev] SSL_read return error(Internet mail)
References: <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>, 
 <20160715.151055.2146531854738957342.levitte@openssl.org>,
 <425c384a54734c669753079a081826e8@usma1ex-dag1mb1.msg.corp.akamai.com>,
 <20160715.175504.1790203699538086422.levitte@openssl.org>,
 <e70035e75a1b4453b506c5af536ba59c@usma1ex-dag1mb1.msg.corp.akamai.com>,
 <637561A39544634DB045D672FFD2217D4A546C@EXMBX-SZMAIL006.tencent.com>,
 <CAEv2VfJTg1MB2sECG6wDc2cyGCveFXW58hcSE0wbKTH+gu8Epg@mail.gmail.com>
Message-ID: <637561A39544634DB045D672FFD2217D4A54BB@EXMBX-SZMAIL006.tencent.com>

Hi,
   Thank you for your replay, how to resovle this issue or avoid it hanppen ? when this error occur , will reconnect to server?affect normal use .

    i think it should hanppen in ssl init phase ,why it happen in normal data transmit phase .

    error log :Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message type:s3_clnt.c:700
________________________________
paladinchen(??)

From: openssl-dev<mailto:openssl-dev-bounces at openssl.org>
Date: 2016-07-16 14:02
To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
CC: openssl-dev<mailto:openssl-dev-bounces at openssl.org>
Subject: Re: [openssl-dev] SSL_read return error(Internet mail)
Hello!

It looks like the server replies with a bad data sometimes. I wonder if server could be speaking different protocols at such moments?

Hope it helps,
Fedor.

On Sat, Jul 16, 2016 at 1:21 AM, paladinchen(??) <paladinchen at tencent.com<mailto:paladinchen at tencent.com>> wrote:
Hi ,
    use openSSL lib run sometimes?and generate this error , i can't find reason ,this issue always puzzled me
please help me, thank you .

    error log :Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message type:s3_clnt.c:700


________________________________
paladinchen(??)


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160716/555cf37c/attachment.html>

From fedor at indutny.com  Sat Jul 16 08:51:43 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Sat, 16 Jul 2016 04:51:43 -0400
Subject: [openssl-dev] SSL_read return error(Internet mail)
In-Reply-To: <637561A39544634DB045D672FFD2217D4A54BB@EXMBX-SZMAIL006.tencent.com>
References: <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.151055.2146531854738957342.levitte@openssl.org>
 <425c384a54734c669753079a081826e8@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160715.175504.1790203699538086422.levitte@openssl.org>
 <e70035e75a1b4453b506c5af536ba59c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <637561A39544634DB045D672FFD2217D4A546C@EXMBX-SZMAIL006.tencent.com>
 <CAEv2VfJTg1MB2sECG6wDc2cyGCveFXW58hcSE0wbKTH+gu8Epg@mail.gmail.com>
 <637561A39544634DB045D672FFD2217D4A54BB@EXMBX-SZMAIL006.tencent.com>
Message-ID: <CAEv2VfLSbei9bXWoq2kcW2cv9V+ck4K+Y_HXGeJsMdwV=jHe2w@mail.gmail.com>

Hello again,

Do you use renegotiation?

On Sat, Jul 16, 2016 at 3:09 AM, paladinchen(??) <paladinchen at tencent.com>
wrote:

> Hi,
>    Thank you for your replay, how to resovle this issue or avoid it
> hanppen ? when this error occur , will reconnect to server?affect normal
> use .
>
>     i think it should hanppen in ssl init phase ,why it happen in normal
> data transmit phase .
>
>     error log :
> Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message type:s3_clnt.c:700
> ------------------------------
> paladinchen(??)
>
>
> *From:* openssl-dev <openssl-dev-bounces at openssl.org>
> *Date:* 2016-07-16 14:02
> *To:* openssl-dev at openssl.org
> *CC:* openssl-dev <openssl-dev-bounces at openssl.org>
> *Subject:* Re: [openssl-dev] SSL_read return error(Internet mail)
> Hello!
>
> It looks like the server replies with a bad data sometimes. I wonder if
> server could be speaking different protocols at such moments?
>
> Hope it helps,
> Fedor.
>
> On Sat, Jul 16, 2016 at 1:21 AM, paladinchen(??) <paladinchen at tencent.com>
> wrote:
>
>> Hi ,
>>     use openSSL lib run sometimes?and generate this error , i can't find
>> reason ,this issue always puzzled me
>> please help me, thank you .
>>
>>     error log :
>> Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message type:s3_clnt.c:700
>>
>>
>> ------------------------------
>> paladinchen(??)
>>
>>
>>
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160716/ee4ae796/attachment-0001.html>

From paladinchen at tencent.com  Sat Jul 16 09:32:51 2016
From: paladinchen at tencent.com (=?utf-8?B?cGFsYWRpbmNoZW4o6ZmI5aWHKQ==?=)
Date: Sat, 16 Jul 2016 09:32:51 +0000
Subject: [openssl-dev] SSL_read return error(Internet mail)
References: <008b774a63414d9bb286ff344ddac838@usma1ex-dag1mb1.msg.corp.akamai.com>, 
 <20160715.151055.2146531854738957342.levitte@openssl.org>,
 <425c384a54734c669753079a081826e8@usma1ex-dag1mb1.msg.corp.akamai.com>,
 <20160715.175504.1790203699538086422.levitte@openssl.org>,
 <e70035e75a1b4453b506c5af536ba59c@usma1ex-dag1mb1.msg.corp.akamai.com>,
 <637561A39544634DB045D672FFD2217D4A546C@EXMBX-SZMAIL006.tencent.com>,
 <CAEv2VfJTg1MB2sECG6wDc2cyGCveFXW58hcSE0wbKTH+gu8Epg@mail.gmail.com>,
 <637561A39544634DB045D672FFD2217D4A54BB@EXMBX-SZMAIL006.tencent.com>,
 <CAEv2VfLSbei9bXWoq2kcW2cv9V+ck4K+Y_HXGeJsMdwV=jHe2w@mail.gmail.com>
Message-ID: <637561A39544634DB045D672FFD2217D4A5673@EXMBX-SZMAIL006.tencent.com>

Hi  !
 I only see these error log , don't kown hanppen scence ?

I see log print  "s3_clnt.c" , it should run at client mode , but my process run at server mode .



________________________________
paladinchen(??)

From: openssl-dev<mailto:openssl-dev-bounces at openssl.org>
Date: 2016-07-16 16:51
To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
CC: openssl-dev<mailto:openssl-dev-bounces at openssl.org>
Subject: Re: [openssl-dev] SSL_read return error(Internet mail)
Hello again,

Do you use renegotiation?

On Sat, Jul 16, 2016 at 3:09 AM, paladinchen(??) <paladinchen at tencent.com<mailto:paladinchen at tencent.com>> wrote:
Hi,
   Thank you for your replay, how to resovle this issue or avoid it hanppen ? when this error occur , will reconnect to server?affect normal use .

    i think it should hanppen in ssl init phase ,why it happen in normal data transmit phase .

    error log :Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message type:s3_clnt.c:700
________________________________
paladinchen(??)

From: openssl-dev<mailto:openssl-dev-bounces at openssl.org>
Date: 2016-07-16 14:02
To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
CC: openssl-dev<mailto:openssl-dev-bounces at openssl.org>
Subject: Re: [openssl-dev] SSL_read return error(Internet mail)
Hello!

It looks like the server replies with a bad data sometimes. I wonder if server could be speaking different protocols at such moments?

Hope it helps,
Fedor.

On Sat, Jul 16, 2016 at 1:21 AM, paladinchen(??) <paladinchen at tencent.com<mailto:paladinchen at tencent.com>> wrote:
Hi ,
    use openSSL lib run sometimes?and generate this error , i can't find reason ,this issue always puzzled me
please help me, thank you .

    error log :Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message type:s3_clnt.c:700


________________________________
paladinchen(??)


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



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160716/9a16b87b/attachment.html>

From rt at openssl.org  Mon Jul 18 16:39:39 2016
From: rt at openssl.org (Lapprich, Harold via RT)
Date: Mon, 18 Jul 2016 16:39:39 +0000
Subject: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
In-Reply-To: <A53318AF49A84048959FE3BBF37B4DB95E03D9@CINMBCNA09.e2k.ad.ge.com>
References: <RT-Ticket-4617@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E03D9@CINMBCNA09.e2k.ad.ge.com>
Message-ID: <rt-4.0.19-19821-1468859978-1229.4617-21-0@openssl.org>

To Whom It May Concern,

openssl version -a:

            OpenSSL 1.0.2a 19 Mar 2015

built on: reproducible build, date unspecified

platform: linux-ppc

options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx)

compiler: /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/ccache /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2  -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM

OPENSSLDIR: "/etc/ssl"



                OS Name, Version, Hardware platform:

uname -a

Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT 2016 ppc GNU/Linux




Using 'openssl' in a Linux design and since it is a command line application it is always outputting content to the screen, for example:


openssl req -new -x509 -nodes -days 365 -subj "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT" -keyout start -out start

Generating a 2048 bit RSA private key

.........................................................................................+++

.............+++

writing new private key to 'start'

-----


Trying to find a way to prevent the output being output to 'stdout' but have not found a parameter (can redirect to a file but  the .....+ characters are still written to the console).


There either has to be a missed parameter or bug exist?


Thanks for your time regarding this issue,
Harold Lapprich


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4617
Please log in as guest with password guest if prompted


From janjust at nikhef.nl  Mon Jul 18 17:20:51 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Mon, 18 Jul 2016 19:20:51 +0200
Subject: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
In-Reply-To: <rt-4.0.19-19821-1468859978-1229.4617-21-0@openssl.org>
References: <RT-Ticket-4617@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E03D9@CINMBCNA09.e2k.ad.ge.com>
 <rt-4.0.19-19821-1468859978-1229.4617-21-0@openssl.org>
Message-ID: <48922eba-0449-b64b-5a92-665c48bad27c@nikhef.nl>

Hi,

On 18/07/16 18:39, Lapprich, Harold via RT wrote:
> To Whom It May Concern,
>
> openssl version -a:
>
>              OpenSSL 1.0.2a 19 Mar 2015
>
> built on: reproducible build, date unspecified
>
> platform: linux-ppc
>
> options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx)
>
> compiler: /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/ccache /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2  -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM
>
> OPENSSLDIR: "/etc/ssl"
>
>
>
>                  OS Name, Version, Hardware platform:
>
> uname -a
>
> Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT 2016 ppc GNU/Linux
>
>
>
>
> Using 'openssl' in a Linux design and since it is a command line application it is always outputting content to the screen, for example:
>
>
> openssl req -new -x509 -nodes -days 365 -subj "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT" -keyout start -out start
>
> Generating a 2048 bit RSA private key
>
> .........................................................................................+++
>
> .............+++
>
> writing new private key to 'start'
>
> -----
>
>
> Trying to find a way to prevent the output being output to 'stdout' but have not found a parameter (can redirect to a file but  the .....+ characters are still written to the console).
>
>
> There either has to be a missed parameter or bug exist?
>
This is not a bug or lacking feature.
The ....+ characters are written to stderr, so if you use
   openssl .....    > stdout 2> stderr
the characters disappear (into the file 'stderr'; use '2> /dev/null' to 
send then straight to bit-heaven).  This depends slightly on the shell 
you use, BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a 
different syntax applies.

HTH,

JJK


From rt at openssl.org  Mon Jul 18 18:26:05 2016
From: rt at openssl.org (Jan Just Keijser via RT)
Date: Mon, 18 Jul 2016 18:26:05 +0000
Subject: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
In-Reply-To: <48922eba-0449-b64b-5a92-665c48bad27c@nikhef.nl>
References: <RT-Ticket-4617@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E03D9@CINMBCNA09.e2k.ad.ge.com>
 <rt-4.0.19-19821-1468859978-1229.4617-21-0@openssl.org>
 <48922eba-0449-b64b-5a92-665c48bad27c@nikhef.nl>
Message-ID: <rt-4.0.19-19822-1468866365-1905.4617-6-0@openssl.org>

Hi,

On 18/07/16 18:39, Lapprich, Harold via RT wrote:
> To Whom It May Concern,
>
> openssl version -a:
>
>              OpenSSL 1.0.2a 19 Mar 2015
>
> built on: reproducible build, date unspecified
>
> platform: linux-ppc
>
> options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx)
>
> compiler: /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/ccache /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2  -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM
>
> OPENSSLDIR: "/etc/ssl"
>
>
>
>                  OS Name, Version, Hardware platform:
>
> uname -a
>
> Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT 2016 ppc GNU/Linux
>
>
>
>
> Using 'openssl' in a Linux design and since it is a command line application it is always outputting content to the screen, for example:
>
>
> openssl req -new -x509 -nodes -days 365 -subj "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT" -keyout start -out start
>
> Generating a 2048 bit RSA private key
>
> .........................................................................................+++
>
> .............+++
>
> writing new private key to 'start'
>
> -----
>
>
> Trying to find a way to prevent the output being output to 'stdout' but have not found a parameter (can redirect to a file but  the .....+ characters are still written to the console).
>
>
> There either has to be a missed parameter or bug exist?
>
This is not a bug or lacking feature.
The ....+ characters are written to stderr, so if you use
   openssl .....    > stdout 2> stderr
the characters disappear (into the file 'stderr'; use '2> /dev/null' to 
send then straight to bit-heaven).  This depends slightly on the shell 
you use, BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a 
different syntax applies.

HTH,

JJK


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4617
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 18 19:31:18 2016
From: rt at openssl.org (Lapprich, Harold via RT)
Date: Mon, 18 Jul 2016 19:31:18 +0000
Subject: [openssl-dev]  [openssl.org #4617] openssl Issue/Bug
In-Reply-To: <A53318AF49A84048959FE3BBF37B4DB95E04DF@CINMBCNA09.e2k.ad.ge.com>
References: <RT-Ticket-4617@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E03D9@CINMBCNA09.e2k.ad.ge.com>
 <rt-4.0.19-19821-1468859978-1229.4617-21-0@openssl.org>
 <48922eba-0449-b64b-5a92-665c48bad27c@nikhef.nl>
 <rt-4.0.19-19822-1468866365-1905.4617-6-0@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E04DF@CINMBCNA09.e2k.ad.ge.com>
Message-ID: <rt-4.0.19-19821-1468870278-959.4617-6-0@openssl.org>

JJK,

Thanks for the quick response, it is really appreciated. Can I ask where you picked up the syntax for this command line (familiar with the various shells and /dev/null but couldn't put this together)?

Thanks Again,
Harold

-----Original Message-----
From: Jan Just Keijser via RT [mailto:rt at openssl.org] 
Sent: Monday, July 18, 2016 2:26 PM
To: Lapprich, Harold (GE Aviation, US)
Cc: openssl-dev at openssl.org
Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug

Hi,

On 18/07/16 18:39, Lapprich, Harold via RT wrote:
> To Whom It May Concern,
>
> openssl version -a:
>
>              OpenSSL 1.0.2a 19 Mar 2015
>
> built on: reproducible build, date unspecified
>
> platform: linux-ppc
>
> options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx)
>
> compiler: 
> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
> r/bin/ccache 
> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
> r/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC 
> -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
> -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE 
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2  
> -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
> -DAES_ASM -DVPAES_ASM
>
> OPENSSLDIR: "/etc/ssl"
>
>
>
>                  OS Name, Version, Hardware platform:
>
> uname -a
>
> Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT 
> 2016 ppc GNU/Linux
>
>
>
>
> Using 'openssl' in a Linux design and since it is a command line application it is always outputting content to the screen, for example:
>
>
> openssl req -new -x509 -nodes -days 365 -subj 
> "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT" 
> -keyout start -out start
>
> Generating a 2048 bit RSA private key
>
> ......................................................................
> ...................+++
>
> .............+++
>
> writing new private key to 'start'
>
> -----
>
>
> Trying to find a way to prevent the output being output to 'stdout' but have not found a parameter (can redirect to a file but  the .....+ characters are still written to the console).
>
>
> There either has to be a missed parameter or bug exist?
>
This is not a bug or lacking feature.
The ....+ characters are written to stderr, so if you use
   openssl .....    > stdout 2> stderr
the characters disappear (into the file 'stderr'; use '2> /dev/null' to send then straight to bit-heaven).  This depends slightly on the shell you use, BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax applies.

HTH,

JJK


--
Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617&d=CwIDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg&m=hC-ePxGkl2IKC2iYTHYFk1qfc32xU_KzR5R3duyHaIM&s=G81nAuvPiu8kBUwgddPaVgh_UkoNVeOvf7Q4veAdNVo&e=
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4617
Please log in as guest with password guest if prompted


From doctor at doctor.nl2k.ab.ca  Mon Jul 18 23:58:36 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 18 Jul 2016 17:58:36 -0600
Subject: [openssl-dev] Moving on
Message-ID: <20160718235836.GB2296@doctor.nl2k.ab.ca>

I will be retiring our BSDI servers tonight replacing them
with FreeBSD servers.

I will still work with you on 1.0 and 1.1 development issues.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Language is the source of misunderstandings.  -Antoine de Saint-Exupery  

From rsalz at akamai.com  Tue Jul 19 00:30:12 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 19 Jul 2016 00:30:12 +0000
Subject: [openssl-dev] Moving on
In-Reply-To: <20160718235836.GB2296@doctor.nl2k.ab.ca>
References: <20160718235836.GB2296@doctor.nl2k.ab.ca>
Message-ID: <f44f3ab0672343b186204d4e20421578@usma1ex-dag1mb1.msg.corp.akamai.com>

We'll have a moment of silence ;)

Seriously, glad your subject line referred to systems, and not to you helping  test snapshots!

From anirudhp at avaya.com  Tue Jul 19 06:33:22 2016
From: anirudhp at avaya.com (Patel, Anirudh (Anirudh))
Date: Tue, 19 Jul 2016 06:33:22 +0000
Subject: [openssl-dev] openssl.org #4615 Cache utility behaving strange with
 X509_LOOKUP_add_dir
Message-ID: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>

Hi,

I have earlier raised an issue on how openssl is not looking up for newer CRLs in each lookup. The only CRL files it is taking into consideration are the ones present in the cache.

Could you please provide some inputs on this as I am blocked on the implementation front.

Regards,
Anirudh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/19efeb99/attachment.html>

From rsalz at akamai.com  Tue Jul 19 07:25:03 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 19 Jul 2016 07:25:03 +0000
Subject: [openssl-dev] openssl.org #4615 Cache utility behaving strange
 with X509_LOOKUP_add_dir
In-Reply-To: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>
Message-ID: <3f6649157a1c4fc888d5d28b4de472da@usma1ex-dag1mb1.msg.corp.akamai.com>


> I have earlier raised an issue on how openssl is not looking up for newer CRLs in each lookup. The only CRL files it is taking into consideration are the ones present in the cache.

> Could you please provide some inputs on this as I am blocked on the implementation front. ?

You mean it's not fetching CRL's over the network?  Or re-checking the files?


From anirudhp at avaya.com  Tue Jul 19 07:32:32 2016
From: anirudhp at avaya.com (Patel, Anirudh (Anirudh))
Date: Tue, 19 Jul 2016 07:32:32 +0000
Subject: [openssl-dev] openssl.org #4615 Cache utility behaving strange
 with X509_LOOKUP_add_dir
In-Reply-To: <3f6649157a1c4fc888d5d28b4de472da@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>
 <3f6649157a1c4fc888d5d28b4de472da@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E65@AZ-FFEXMB01.global.avaya.com>

It is not re-checking the files (new CRL for the same issuer) in the CRL directory
IssuerHash_YYYY.r0 (old crl for sub-ca) 
IssuerHash_YYYY.r1 (new crl for sub-ca) ---> not looked up for an incoming client connection
IssuerXXXX.r0 (old crl for root ca)

I have mentioned the complete scenario in the ticket#4615

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Salz, Rich
Sent: Tuesday, July 19, 2016 12:55 PM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange with X509_LOOKUP_add_dir


> I have earlier raised an issue on how openssl is not looking up for newer CRLs in each lookup. The only CRL files it is taking into consideration are the ones present in the cache.

> Could you please provide some inputs on this as I am blocked on the implementation front. ?

You mean it's not fetching CRL's over the network?  Or re-checking the files?

-- 
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44&s=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs&e= 

From rsalz at akamai.com  Tue Jul 19 07:50:15 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 19 Jul 2016 07:50:15 +0000
Subject: [openssl-dev] openssl.org #4615 Cache utility behaving strange
 with X509_LOOKUP_add_dir
In-Reply-To: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E65@AZ-FFEXMB01.global.avaya.com>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>
 <3f6649157a1c4fc888d5d28b4de472da@usma1ex-dag1mb1.msg.corp.akamai.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E65@AZ-FFEXMB01.global.avaya.com>
Message-ID: <b5566cbe604e4a0e8657a1c3b0b3f1cb@usma1ex-dag1mb1.msg.corp.akamai.com>


> It is not re-checking the files (new CRL for the same issuer) in the CRL
> directory

I believe that is working as designed and what you want is a new feature.

From mischa.salle at gmail.com  Tue Jul 19 07:56:47 2016
From: mischa.salle at gmail.com (Mischa Salle)
Date: Tue, 19 Jul 2016 09:56:47 +0200
Subject: [openssl-dev] openssl.org #4615 Cache utility behaving strange
 with X509_LOOKUP_add_dir
In-Reply-To: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E65@AZ-FFEXMB01.global.avaya.com>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>
 <3f6649157a1c4fc888d5d28b4de472da@usma1ex-dag1mb1.msg.corp.akamai.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E65@AZ-FFEXMB01.global.avaya.com>
Message-ID: <CAD38tB3FrZF45hpBR6ZJZ7BsXrzL3Hj2Qnom+AzjceEh_jCazA@mail.gmail.com>

Hi Anirudh,

this is as far as I know a very old issue (at least since 2002 or so).
Basically a server needs to restart periodically in order to pick up
changed CRLs. There are some workarounds, like forcibly reloading all the
CRLs periodically, even those already in the store.

Mischa Salle

On Tue, Jul 19, 2016 at 9:32 AM, Patel, Anirudh (Anirudh) <
anirudhp at avaya.com> wrote:

> It is not re-checking the files (new CRL for the same issuer) in the CRL
> directory
> IssuerHash_YYYY.r0 (old crl for sub-ca)
> IssuerHash_YYYY.r1 (new crl for sub-ca) ---> not looked up for an incoming
> client connection
> IssuerXXXX.r0 (old crl for root ca)
>
> I have mentioned the complete scenario in the ticket#4615
>
> -----Original Message-----
> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of
> Salz, Rich
> Sent: Tuesday, July 19, 2016 12:55 PM
> To: openssl-dev at openssl.org
> Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving
> strange with X509_LOOKUP_add_dir
>
>
> > I have earlier raised an issue on how openssl is not looking up for
> newer CRLs in each lookup. The only CRL files it is taking into
> consideration are the ones present in the cache.
>
> > Could you please provide some inputs on this as I am blocked on the
> implementation front.
>
> You mean it's not fetching CRL's over the network?  Or re-checking the
> files?
>
> --
> openssl-dev mailing list
> To unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44&s=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs&e=
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/6472aa94/attachment-0001.html>

From anirudhp at avaya.com  Tue Jul 19 08:24:25 2016
From: anirudhp at avaya.com (Patel, Anirudh (Anirudh))
Date: Tue, 19 Jul 2016 08:24:25 +0000
Subject: [openssl-dev] openssl.org #4615 Cache utility behaving strange
 with X509_LOOKUP_add_dir
In-Reply-To: <CAD38tB3FrZF45hpBR6ZJZ7BsXrzL3Hj2Qnom+AzjceEh_jCazA@mail.gmail.com>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>
 <3f6649157a1c4fc888d5d28b4de472da@usma1ex-dag1mb1.msg.corp.akamai.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E65@AZ-FFEXMB01.global.avaya.com>
 <CAD38tB3FrZF45hpBR6ZJZ7BsXrzL3Hj2Qnom+AzjceEh_jCazA@mail.gmail.com>
Message-ID: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21EA3@AZ-FFEXMB01.global.avaya.com>

Man page for X509_LOOKUP_hash_dir states something different though:


X509_LOOKUP_hash_dir is a more advanced method, which loads certificates and CRLs on demand, and caches them in memory once they are loaded. As of OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer CRLs are as soon as they appear in the directory

When checking for new CRLs once one CRL for given hash value is loaded, hash_dir lookup method checks only for certificates with sequence number greater than that of the already cached CRL.

a)      If you look at my scenario, firstly I did not had any CRL files under the CRL directory which has been loaded in the store when my server starts. For the incoming chain as ID/Sub CA/Root CA verify_callback is invoked which gives 3 errors X509_V_ERR_UNABLE_TO_GET_CRL one for each certificate and then follows with further validation.

b)      Then, when I placed the respective CRL files under the directory and I get the same incoming connection (chain: ID/Sub CA/Root CA) openssl verify_callback stops complaining about CRL files not found for the certs. Please note that I did not stop/start the server to load the store with CRL directory again. As stated in the man page, openssl rightly did a lookup and found new CRL files during the handshake.

c)       The problem is when a new CRL file for one the above issuer is placed under the CRL directory (with an incremented sequence number .rN) openssl is not looking at the newer CRL file but only considering the ones in the cache.

Let me know if the manual page description meant something different.

Thanks.

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Mischa Salle
Sent: Tuesday, July 19, 2016 1:27 PM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange with X509_LOOKUP_add_dir

Hi Anirudh,
this is as far as I know a very old issue (at least since 2002 or so). Basically a server needs to restart periodically in order to pick up changed CRLs. There are some workarounds, like forcibly reloading all the CRLs periodically, even those already in the store.
Mischa Salle

On Tue, Jul 19, 2016 at 9:32 AM, Patel, Anirudh (Anirudh) <anirudhp at avaya.com<mailto:anirudhp at avaya.com>> wrote:
It is not re-checking the files (new CRL for the same issuer) in the CRL directory
IssuerHash_YYYY.r0 (old crl for sub-ca)
IssuerHash_YYYY.r1 (new crl for sub-ca) ---> not looked up for an incoming client connection
IssuerXXXX.r0 (old crl for root ca)

I have mentioned the complete scenario in the ticket#4615

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>] On Behalf Of Salz, Rich
Sent: Tuesday, July 19, 2016 12:55 PM
To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
Subject: Re: [openssl-dev] openssl.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.org&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=ultotvw_l8QsxQ1Zf_5rbTjOo-JG_iZbExIaV7qPLOs&e=> #4615 Cache utility behaving strange with X509_LOOKUP_add_dir


> I have earlier raised an issue on how openssl is not looking up for newer CRLs in each lookup. The only CRL files it is taking into consideration are the ones present in the cache.

> Could you please provide some inputs on this as I am blocked on the implementation front.

You mean it's not fetching CRL's over the network?  Or re-checking the files?

--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44&s=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs&e=
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=F3JmB5AFiuX4fyQGRse7p8_yKB86uPYSSBlCWfApGfM&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/3f9b879f/attachment.html>

From rt at openssl.org  Tue Jul 19 08:31:18 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 08:31:18 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange
	with X509_LOOKUP_add_dir
In-Reply-To: <CAKUCFqd0xa14SvQBJQH7gRbJq8sRVgz+2+TVFUceyaAHRGE9WQ@mail.gmail.com>
References: <RT-Ticket-4615@openssl.org>
 <CAKUCFqd0xa14SvQBJQH7gRbJq8sRVgz+2+TVFUceyaAHRGE9WQ@mail.gmail.com>
Message-ID: <rt-4.0.19-17766-1468917078-729.4615-6-0@openssl.org>

So let me see if I understand this correctly... $hash(sub_ca).r1 and
$hash(sub_ca).r0, being of the same sub_ca, will of course have the same issuer
name. Right?

Unless I misread the source, OpenSSL will actually load both files. However,
since both CRLs have the same issuer, and cached CRLs are looked up by issuer
name, only one of them will be used (whichever the code happens to find first).

If one of those CRLs was a delta CRL, things might work differently (I'm
frankly not sure, I haven't experimented with that, and haven't spent enough
time studying that part of the code)... I assume that this isn't the case.

Is there a reason in particular you want to have two active CRLs for the
sub-CA? Does simply replacing the old with the new now work for you somehow?

Cheers,
Richard

On Thu Jul 14 11:25:22 2016, patel3.anirudh at gmail.com wrote:
> Hi,
>
> I have a query related to how these APIs X509_STORE_add_lookup()
> and X509_LOOKUP_add_dir() work. Let me give you a brief explanation of what
> I am doing:
>
> Purpose was to add lookup for CRLs.
>
> First when my server starts and my SSL initializes I have successfully
> created a store to which lookup has been added for CRL directory.
>
> - pLookup = X509_STORE_add_lookup(store, X509_LOOKUP_hash_dir());
> - X509_LOOKUP_add_dir(pLookup, mCRLPath.c_str(), X509_FILETYPE_PEM)
>
> Example CRL Directory: /var/cert/CRL/
> Scenario:
> 1) When the system start no CRL files are present in the CRL Directory
> 2) Client_1 initiates a connection to my server (using openssl s_client)
> 3) Openssl does the lookup of CRLs for the corresponding (Sub) CAs and does
> not find anything thus, giving error in the verify_callback
> (UNABLE_TO_GET_CRL). In the application code I have handled these
> errors gracefully Callback is again called for further validation and the
> connection is accepted.
> *Result: Satisfied*
>
> 1) Now, I place two CRLs (Sub CA,Root CA) in the CRL directory (server was
> still up and I did not stopped it)
> I have created a crl -hash (issuer hash) and linked them to CRL pem
> certificates.
> *$hash(rootca).r0 -> root_ca.pem*
> *$hash(subca).r0 -> sub_ca.pem*
> 2) Client_1 again initiates a connection to my server (using openssl
> s_client) (client certificate chain is : ID/Sub CA/Root CA)
> 3) Openssl does a lookup of CRLs and does not throw any error. Validation
> happened with verify_callback getting invoked 3 times with preverify_ok =
> 1. Client connection is accepted
> *Result: Satisfied*
>
> 1) Now, I removed the above CRL files (Sub CA/Root CA) from the CRL
> directory. Based on the manual page these CRLs should be now in the cached
> memory of X509_OBJECT.
> 2) I repeated steps (2) and (3). Connection gets accepted from the client.
> Everything still works fine because openssl maintined CRL files in its
> cache and found them during the lookup.
> *Result: Satisfied*
>
> Now from here the problem starts:
> =========================
> 1) My Sub_CA revoked Client_1 certificate (since Sub_CA was the issuing CA
> in the first place)
> 2) I recreated Sub_CA CRL and placed it in the CRL Directory.
> 3) Created the hash and linked it as follows:
> *$hash(sub_ca).r1* -> sub_ca.pem (hoping that openssl still has
> $hash(sub_ca).r0 in its cache, since above we have seen that the lookup
> worked even when I removed the CRL files from the CRL Directory)
> 4) Client_1 initiates a connection to my server and gets accepted
> successfully ==== Should Not Have Happened
> Based on the manual page for *X509_LOOKUP_hash_dir
> - https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html
> <https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html>*
>
> > When checking for new CRLs once one CRL for given hash value is loaded,
> > hash_dir lookup method checks only for certificates with sequence number
> > greater than that of the already cached CRL.
>
> Since, the sequence number has changed from r0 to r1 for same issuer
> (sub_ca in my case) openssl should have done a lookup and based on the
> latest sequence number should have given me an error stating Client
> Certificate has been revoked.
>
> Just to let you know, I have tested revoked certificates with the CRL and
> it works fine. So no problem with that.
> Openssl Version I am using is *OpenSSL 1.0.1e-fips 11 Feb 2013*
>
> Eagerly awaiting your response. Need to implement CRL functionality ASAP
> and hoping to get all the help from you guys.
>
> Regards,
> Anirudh


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 08:47:11 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 08:47:11 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange
	with X509_LOOKUP_add_dir
In-Reply-To: <rt-4.0.19-17766-1468917078-1020.4615-6-0@openssl.org>
References: <RT-Ticket-4615@openssl.org>
 <CAKUCFqd0xa14SvQBJQH7gRbJq8sRVgz+2+TVFUceyaAHRGE9WQ@mail.gmail.com>
 <rt-4.0.19-17766-1468917078-1020.4615-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1468918031-276.4615-6-0@openssl.org>

My answer was incorrect...

What happens when trying to find a CRL is that get_cert_by_subject (in
crypto/x509/by_dir.c) gets called, and it will try to load every file it finds
(so both $hash{sub_ca}.r0 and $hash{sub_ca}.r1). However, when trying to
storing them in the internal store, it will only do so if no other object with
the same hash is already there. Hence, $hash{sub_ca}.r1 will essentially be
ignored.

Either way, if both CRLs (with the same issuer name) were stored internally, it
would still be a good question which one would actually be used. How would that
be determined.

I suggest you try with replacing the old with the new.

Furthermore, I'm not sure this is a bug, at least in current OpenSSL. Maybe
this will be reconsidered in the future, but that will certainly be seen as a
new feature.

Time to close this ticket.

Cheers,
Richard

On Tue Jul 19 08:31:18 2016, levitte wrote:
> So let me see if I understand this correctly... $hash(sub_ca).r1 and
> $hash(sub_ca).r0, being of the same sub_ca, will of course have the
> same issuer
> name. Right?
>
> Unless I misread the source, OpenSSL will actually load both files.
> However,
> since both CRLs have the same issuer, and cached CRLs are looked up by
> issuer
> name, only one of them will be used (whichever the code happens to
> find first).
>
> If one of those CRLs was a delta CRL, things might work differently
> (I'm
> frankly not sure, I haven't experimented with that, and haven't spent
> enough
> time studying that part of the code)... I assume that this isn't the
> case.
>
> Is there a reason in particular you want to have two active CRLs for
> the
> sub-CA? Does simply replacing the old with the new now work for you
> somehow?
>
> Cheers,
> Richard
>
> On Thu Jul 14 11:25:22 2016, patel3.anirudh at gmail.com wrote:
> > Hi,
> >
> > I have a query related to how these APIs X509_STORE_add_lookup()
> > and X509_LOOKUP_add_dir() work. Let me give you a brief explanation
> > of what
> > I am doing:
> >
> > Purpose was to add lookup for CRLs.
> >
> > First when my server starts and my SSL initializes I have
> > successfully
> > created a store to which lookup has been added for CRL directory.
> >
> > - pLookup = X509_STORE_add_lookup(store, X509_LOOKUP_hash_dir());
> > - X509_LOOKUP_add_dir(pLookup, mCRLPath.c_str(), X509_FILETYPE_PEM)
> >
> > Example CRL Directory: /var/cert/CRL/
> > Scenario:
> > 1) When the system start no CRL files are present in the CRL
> > Directory
> > 2) Client_1 initiates a connection to my server (using openssl
> > s_client)
> > 3) Openssl does the lookup of CRLs for the corresponding (Sub) CAs
> > and does
> > not find anything thus, giving error in the verify_callback
> > (UNABLE_TO_GET_CRL). In the application code I have handled these
> > errors gracefully Callback is again called for further validation and
> > the
> > connection is accepted.
> > *Result: Satisfied*
> >
> > 1) Now, I place two CRLs (Sub CA,Root CA) in the CRL directory
> > (server was
> > still up and I did not stopped it)
> > I have created a crl -hash (issuer hash) and linked them to CRL pem
> > certificates.
> > *$hash(rootca).r0 -> root_ca.pem*
> > *$hash(subca).r0 -> sub_ca.pem*
> > 2) Client_1 again initiates a connection to my server (using openssl
> > s_client) (client certificate chain is : ID/Sub CA/Root CA)
> > 3) Openssl does a lookup of CRLs and does not throw any error.
> > Validation
> > happened with verify_callback getting invoked 3 times with
> > preverify_ok =
> > 1. Client connection is accepted
> > *Result: Satisfied*
> >
> > 1) Now, I removed the above CRL files (Sub CA/Root CA) from the CRL
> > directory. Based on the manual page these CRLs should be now in the
> > cached
> > memory of X509_OBJECT.
> > 2) I repeated steps (2) and (3). Connection gets accepted from the
> > client.
> > Everything still works fine because openssl maintined CRL files in
> > its
> > cache and found them during the lookup.
> > *Result: Satisfied*
> >
> > Now from here the problem starts:
> > =========================
> > 1) My Sub_CA revoked Client_1 certificate (since Sub_CA was the
> > issuing CA
> > in the first place)
> > 2) I recreated Sub_CA CRL and placed it in the CRL Directory.
> > 3) Created the hash and linked it as follows:
> > *$hash(sub_ca).r1* -> sub_ca.pem (hoping that openssl still has
> > $hash(sub_ca).r0 in its cache, since above we have seen that the
> > lookup
> > worked even when I removed the CRL files from the CRL Directory)
> > 4) Client_1 initiates a connection to my server and gets accepted
> > successfully ==== Should Not Have Happened
> > Based on the manual page for *X509_LOOKUP_hash_dir
> > - https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html
> > <https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html>*
> >
> > > When checking for new CRLs once one CRL for given hash value is
> > > loaded,
> > > hash_dir lookup method checks only for certificates with sequence
> > > number
> > > greater than that of the already cached CRL.
> >
> > Since, the sequence number has changed from r0 to r1 for same issuer
> > (sub_ca in my case) openssl should have done a lookup and based on
> > the
> > latest sequence number should have given me an error stating Client
> > Certificate has been revoked.
> >
> > Just to let you know, I have tested revoked certificates with the CRL
> > and
> > it works fine. So no problem with that.
> > Openssl Version I am using is *OpenSSL 1.0.1e-fips 11 Feb 2013*
> >
> > Eagerly awaiting your response. Need to implement CRL functionality
> > ASAP
> > and hoping to get all the help from you guys.
> >
> > Regards,
> > Anirudh
>
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted


From mischa.salle at gmail.com  Tue Jul 19 08:58:21 2016
From: mischa.salle at gmail.com (Mischa Salle)
Date: Tue, 19 Jul 2016 10:58:21 +0200
Subject: [openssl-dev] openssl.org #4615 Cache utility behaving strange
 with X509_LOOKUP_add_dir
In-Reply-To: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21EA3@AZ-FFEXMB01.global.avaya.com>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>
 <3f6649157a1c4fc888d5d28b4de472da@usma1ex-dag1mb1.msg.corp.akamai.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E65@AZ-FFEXMB01.global.avaya.com>
 <CAD38tB3FrZF45hpBR6ZJZ7BsXrzL3Hj2Qnom+AzjceEh_jCazA@mail.gmail.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21EA3@AZ-FFEXMB01.global.avaya.com>
Message-ID: <CAD38tB14Gm76=Ec2TZit1KH2dgdETiwDm6=DG9agX5P3bmbwHA@mail.gmail.com>

Hi,
the point is that they are loaded when a new file appears, meaning, a file
with a name not yet present. Once that file is loaded, it's not been loaded
from disk again (as implied by the 'caches'), also not when it changes.
The .r1 files are rarely used (only for rekeying of the CA etc., as far as
I remember), so normally you would get only replacements of existing files,
meaning OpenSSL will get then from its cache.
Note that I don't like this behaviour, but I think it is as intended.

Mischa


On Tue, Jul 19, 2016 at 10:24 AM, Patel, Anirudh (Anirudh) <
anirudhp at avaya.com> wrote:

> Man page for X509_LOOKUP_hash_dir states something different though:
>
>
>
> X509_LOOKUP_hash_dir is a more advanced method, which loads certificates
> and CRLs on demand, and caches them in memory once they are loaded. As of
> OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that
> newer CRLs are as soon as they appear in the directory
>
> When checking for new CRLs once one CRL for given hash value is loaded,
> hash_dir lookup method checks only for certificates with sequence number
> greater than that of the already cached CRL.
>
> a)      If you look at my scenario, firstly I did not had any CRL files
> under the CRL directory which has been loaded in the store when my server
> starts. For the incoming chain as ID/Sub CA/Root CA verify_callback is
> invoked which gives 3 errors *X509_V_ERR_UNABLE_TO_GET_CRL *one for each
> certificate and then follows with further validation.
>
> b)      Then, when I placed the respective CRL files under the directory
> and I get the same incoming connection (chain: ID/Sub CA/Root CA) openssl
> verify_callback stops complaining about CRL files not found for the certs.
> Please note that I did not stop/start the server to load the store with CRL
> directory again. As stated in the man page, openssl rightly did a lookup
> and found new CRL files during the handshake.
>
> c)       The problem is when a new CRL file for one the above issuer is
> placed under the CRL directory (with an incremented sequence number .rN)
> openssl is not looking at the newer CRL file but only considering the ones
> in the cache.
>
>
>
> Let me know if the manual page description meant something different.
>
>
>
> Thanks.
>
>
>
> *From:* openssl-dev [mailto:openssl-dev-bounces at openssl.org] *On Behalf
> Of *Mischa Salle
> *Sent:* Tuesday, July 19, 2016 1:27 PM
>
> *To:* openssl-dev at openssl.org
> *Subject:* Re: [openssl-dev] openssl.org #4615 Cache utility behaving
> strange with X509_LOOKUP_add_dir
>
>
>
> Hi Anirudh,
>
> this is as far as I know a very old issue (at least since 2002 or so).
> Basically a server needs to restart periodically in order to pick up
> changed CRLs. There are some workarounds, like forcibly reloading all the
> CRLs periodically, even those already in the store.
>
> Mischa Salle
>
>
>
> On Tue, Jul 19, 2016 at 9:32 AM, Patel, Anirudh (Anirudh) <
> anirudhp at avaya.com> wrote:
>
> It is not re-checking the files (new CRL for the same issuer) in the CRL
> directory
> IssuerHash_YYYY.r0 (old crl for sub-ca)
> IssuerHash_YYYY.r1 (new crl for sub-ca) ---> not looked up for an incoming
> client connection
> IssuerXXXX.r0 (old crl for root ca)
>
> I have mentioned the complete scenario in the ticket#4615
>
> -----Original Message-----
> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of
> Salz, Rich
> Sent: Tuesday, July 19, 2016 12:55 PM
> To: openssl-dev at openssl.org
> Subject: Re: [openssl-dev] openssl.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.org&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=ultotvw_l8QsxQ1Zf_5rbTjOo-JG_iZbExIaV7qPLOs&e=>
> #4615 Cache utility behaving strange with X509_LOOKUP_add_dir
>
>
> > I have earlier raised an issue on how openssl is not looking up for
> newer CRLs in each lookup. The only CRL files it is taking into
> consideration are the ones present in the cache.
>
> > Could you please provide some inputs on this as I am blocked on the
> implementation front.
>
> You mean it's not fetching CRL's over the network?  Or re-checking the
> files?
>
> --
> openssl-dev mailing list
> To unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44&s=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs&e=
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=F3JmB5AFiuX4fyQGRse7p8_yKB86uPYSSBlCWfApGfM&e=>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
Van Boshuizenstraat 443
1082 AR Amsterdam
The Netherlands
Tel. (+31/0)20-4043782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/a8b43100/attachment.html>

From anirudhp at avaya.com  Tue Jul 19 09:11:45 2016
From: anirudhp at avaya.com (Patel, Anirudh (Anirudh))
Date: Tue, 19 Jul 2016 09:11:45 +0000
Subject: [openssl-dev] openssl.org #4615 Cache utility behaving strange
 with X509_LOOKUP_add_dir
In-Reply-To: <CAD38tB14Gm76=Ec2TZit1KH2dgdETiwDm6=DG9agX5P3bmbwHA@mail.gmail.com>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>
 <3f6649157a1c4fc888d5d28b4de472da@usma1ex-dag1mb1.msg.corp.akamai.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E65@AZ-FFEXMB01.global.avaya.com>
 <CAD38tB3FrZF45hpBR6ZJZ7BsXrzL3Hj2Qnom+AzjceEh_jCazA@mail.gmail.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21EA3@AZ-FFEXMB01.global.avaya.com>
 <CAD38tB14Gm76=Ec2TZit1KH2dgdETiwDm6=DG9agX5P3bmbwHA@mail.gmail.com>
Message-ID: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21ED8@AZ-FFEXMB01.global.avaya.com>

Fine and thanks for all the explanation.

First let me give my scenario again and then I will come to Mischa?s point.

I got your point Richard but, my scenario is slightly different. What you are considering is that both $hash{sub_ca}.r0 and $hash{sub_ca}.r1 are already present in the CRL directory and has been loaded up. There might be issues with this as you mentioned below.



My case is slightly different:

1. At time T1, CRL file $hash{sub_ca}.r0 is present in the CRL directory. Store is loaded up with it and maybe as you said if, no other object with the same hash is already there this will be put in the internal store.

2. Now I get an incoming client connection and for which this CRL file is looked up and everything is fine.

3. At time T2, I removed this CRL file $hash{sub_ca}.r0 from the CRL directory (but remember it is in the internal store/cache).

4. Now I get the same incoming connection from the client as above for which openssl is currently doing a lookup and gives no error as the corresponding CRL file $hash{sub_ca}.r0 was there in the internal

    store/cache. I was expecting an error since I removed the CRL file but I did not and that is how I understood that openssl is keeping the file in the cache.

5. Above client has now been revoked by sub_ca which generated a new CRL.

6. At time T3, I placed the new CRL file as $hash{sub_ca}.r1 under the CRL directory and it is the only one since I have deleted the old one $hash{sub_ca}.r0 from the directory.

7. Again the same client tries to connect and passes away which now becomes a security concern. As per the statement mentioned on the man page, the lookup should have found and considered the new CRL (.r1)

   and not the one in the cache since its sequence number is old.

Now, from what you have just said let me ask you this:
I have .r0 file which has been loaded up in the internal store since, that issuer was not already present. Right, this is what you are saying: ?if the file is new or if that issuer is not already in the store it, it will be loaded?.
Suppose, I remove this file from the disk (.r0) and place a replacement of it as you said (this replaced CRL file has been recently published which has a list of new certificates that have been revoked). I place this file under the CRL directory as .r0 again, but openssl will now again not lookup for this file as the same issuer name file was already present in its internal store/cache. This is a replaced CRL file of an existing file CRL file but how to make it count. We need to start and stop the server again for loading up the store and refreshing the cache. This seems to be lot of work and inefficient.

Hope I have been able to made my point.

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Mischa Salle
Sent: Tuesday, July 19, 2016 2:28 PM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange with X509_LOOKUP_add_dir

Hi,
the point is that they are loaded when a new file appears, meaning, a file with a name not yet present. Once that file is loaded, it's not been loaded from disk again (as implied by the 'caches'), also not when it changes.
The .r1 files are rarely used (only for rekeying of the CA etc., as far as I remember), so normally you would get only replacements of existing files, meaning OpenSSL will get then from its cache.
Note that I don't like this behaviour, but I think it is as intended.
Mischa


On Tue, Jul 19, 2016 at 10:24 AM, Patel, Anirudh (Anirudh) <anirudhp at avaya.com<mailto:anirudhp at avaya.com>> wrote:
Man page for X509_LOOKUP_hash_dir states something different though:


X509_LOOKUP_hash_dir is a more advanced method, which loads certificates and CRLs on demand, and caches them in memory once they are loaded. As of OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer CRLs are as soon as they appear in the directory

When checking for new CRLs once one CRL for given hash value is loaded, hash_dir lookup method checks only for certificates with sequence number greater than that of the already cached CRL.

a)      If you look at my scenario, firstly I did not had any CRL files under the CRL directory which has been loaded in the store when my server starts. For the incoming chain as ID/Sub CA/Root CA verify_callback is invoked which gives 3 errors X509_V_ERR_UNABLE_TO_GET_CRL one for each certificate and then follows with further validation.

b)      Then, when I placed the respective CRL files under the directory and I get the same incoming connection (chain: ID/Sub CA/Root CA) openssl verify_callback stops complaining about CRL files not found for the certs. Please note that I did not stop/start the server to load the store with CRL directory again. As stated in the man page, openssl rightly did a lookup and found new CRL files during the handshake.

c)       The problem is when a new CRL file for one the above issuer is placed under the CRL directory (with an incremented sequence number .rN) openssl is not looking at the newer CRL file but only considering the ones in the cache.

Let me know if the manual page description meant something different.

Thanks.

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>] On Behalf Of Mischa Salle
Sent: Tuesday, July 19, 2016 1:27 PM

To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
Subject: Re: [openssl-dev] openssl.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.org&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=NM3FtBB4wlVT4uq5ccJIq8GhBUYhH_xiQVBkJ1QVX_s&s=7-gGMTBKo65sNA3NAdCAT48WVK9-kiJa_d54QmGxVmM&e=> #4615 Cache utility behaving strange with X509_LOOKUP_add_dir

Hi Anirudh,
this is as far as I know a very old issue (at least since 2002 or so). Basically a server needs to restart periodically in order to pick up changed CRLs. There are some workarounds, like forcibly reloading all the CRLs periodically, even those already in the store.
Mischa Salle

On Tue, Jul 19, 2016 at 9:32 AM, Patel, Anirudh (Anirudh) <anirudhp at avaya.com<mailto:anirudhp at avaya.com>> wrote:
It is not re-checking the files (new CRL for the same issuer) in the CRL directory
IssuerHash_YYYY.r0 (old crl for sub-ca)
IssuerHash_YYYY.r1 (new crl for sub-ca) ---> not looked up for an incoming client connection
IssuerXXXX.r0 (old crl for root ca)

I have mentioned the complete scenario in the ticket#4615

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>] On Behalf Of Salz, Rich
Sent: Tuesday, July 19, 2016 12:55 PM
To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
Subject: Re: [openssl-dev] openssl.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.org&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=ultotvw_l8QsxQ1Zf_5rbTjOo-JG_iZbExIaV7qPLOs&e=> #4615 Cache utility behaving strange with X509_LOOKUP_add_dir


> I have earlier raised an issue on how openssl is not looking up for newer CRLs in each lookup. The only CRL files it is taking into consideration are the ones present in the cache.

> Could you please provide some inputs on this as I am blocked on the implementation front.

You mean it's not fetching CRL's over the network?  Or re-checking the files?

--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44&s=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs&e=
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=F3JmB5AFiuX4fyQGRse7p8_yKB86uPYSSBlCWfApGfM&e=>

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=NM3FtBB4wlVT4uq5ccJIq8GhBUYhH_xiQVBkJ1QVX_s&s=gu_2BoTnFPbjE2U9cAYiFYofV66JRKrPpbhxdz3Nbmg&e=>



--
Van Boshuizenstraat 443
1082 AR Amsterdam
The Netherlands
Tel. (+31/0)20-4043782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/81471b07/attachment-0001.html>

From rt at openssl.org  Tue Jul 19 12:06:16 2016
From: rt at openssl.org (Lapprich, Harold via RT)
Date: Tue, 19 Jul 2016 12:06:16 +0000
Subject: [openssl-dev] [openssl.org #4617] Resolved: openssl Issue/Bug
In-Reply-To: <A53318AF49A84048959FE3BBF37B4DB95E2541@CINMBCNA09.e2k.ad.ge.com>
References: <RT-Ticket-4617@openssl.org>
 <rt-4.0.19-19822-1468875594-961.4617-10-0@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E2541@CINMBCNA09.e2k.ad.ge.com>
Message-ID: <rt-4.0.19-17767-1468929976-21.4617-6-0@openssl.org>

Hi Rich,

The organization developing and supporting 'openssl' is very professional from submittal of bugs, response, fix and maintained database of fit.

Pleasure working with the organization, thanks again,
Harold M. Lapprich

-----Original Message-----
From: Rich Salz via RT [mailto:rt at openssl.org] 
Sent: Monday, July 18, 2016 5:00 PM
To: Lapprich, Harold (GE Aviation, US)
Subject: EXT: [openssl.org #4617] Resolved: openssl Issue/Bug

According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message.

--
Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617&d=CwIDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg&m=5CIQ-EZ_0WWSG-n85-0XLk063Z1JTQiz6wTsG6RLlJI&s=ROOFDP2D1dlMNzY-PIvDQX9jGtqFu402cseNBoio4Hk&e=
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4617
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 12:07:33 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 19 Jul 2016 12:07:33 +0000
Subject: [openssl-dev] [openssl.org #4588] pkcs12 -info doesn't handle
	PKCS#12 files with PKCS#5 v2.0 PBE
In-Reply-To: <1992022.TCv6Aigntu@pintsize.usersys.redhat.com>
References: <RT-Ticket-4588@openssl.org>
 <1992022.TCv6Aigntu@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-17766-1468930053-68.4588-6-0@openssl.org>

Thanks for the report, fixed now in master and 1.0.2.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4588
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 13:29:13 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 19 Jul 2016 13:29:13 +0000
Subject: [openssl-dev] [openssl.org #4593] [PATCH] pod: fix nits related to
	spacing around commas and assignments
In-Reply-To: <1467067084-24065-1-git-send-email-vapier@gentoo.org>
References: <RT-Ticket-4593@openssl.org>
 <1467067084-24065-1-git-send-email-vapier@gentoo.org>
Message-ID: <rt-4.0.19-17767-1468934953-217.4593-6-0@openssl.org>

merged, thanks!

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4593
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 13:41:35 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 13:41:35 +0000
Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32
In-Reply-To: <CAH8yC8m0tt3xPMK2QKgbrL9dR_wmyJvp2nNNK+hS0sz4bs7ZsQ@mail.gmail.com>
References: <RT-Ticket-4584@openssl.org>
 <CAH8yC8m0tt3xPMK2QKgbrL9dR_wmyJvp2nNNK+hS0sz4bs7ZsQ@mail.gmail.com>
Message-ID: <rt-4.0.19-17766-1468935695-1831.4584-6-0@openssl.org>

Hi Jeff,

I'm going to assume that a newer checkout of the master branch won't change
much, so if you please, try this command and send mack the result:

make test TESTS='test_afalg test_rehash'

Cheers,
Richard

On Thu Jun 23 11:10:04 2016, noloader at gmail.com wrote:
> I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
> and working from HEAD:
>
> # git rev-parse HEAD
> b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92
>
> Running 'make test' under a machine configured with './Configure
> linux-x32 enable-ec_nistp_64_gcc_128' results in two failed self
> tests:
>
> make[1]: Leaving directory '/openssl'
> ( cd test; \
> SRCTOP=../. \
> BLDTOP=../. \
> PERL="perl" \
> EXE_EXT= \
> OPENSSL_ENGINES=.././engines \
> perl .././test/run_tests.pl )
> ../test/recipes/01-test_abort.t ............ ok
> ../test/recipes/01-test_ordinals.t ......... ok
> ../test/recipes/01-test_symbol_presence.t .. ok
> ../test/recipes/05-test_bf.t ............... ok
> ../test/recipes/05-test_cast.t ............. ok
> ../test/recipes/05-test_des.t .............. ok
> ../test/recipes/05-test_hmac.t ............. ok
> ../test/recipes/05-test_idea.t ............. ok
> ../test/recipes/05-test_md2.t .............. skipped: md2 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_md4.t .............. ok
> ../test/recipes/05-test_md5.t .............. ok
> ../test/recipes/05-test_mdc2.t ............. ok
> ../test/recipes/05-test_rand.t ............. ok
> ../test/recipes/05-test_rc2.t .............. ok
> ../test/recipes/05-test_rc4.t .............. ok
> ../test/recipes/05-test_rc5.t .............. skipped: rc5 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_rmd.t .............. ok
> ../test/recipes/05-test_sha1.t ............. ok
> ../test/recipes/05-test_sha256.t ........... ok
> ../test/recipes/05-test_sha512.t ........... ok
> ../test/recipes/05-test_wp.t ............... ok
> ../test/recipes/10-test_bn.t ............... ok
> ../test/recipes/10-test_exp.t .............. ok
> ../test/recipes/15-test_dh.t ............... ok
> ../test/recipes/15-test_dsa.t .............. ok
> ../test/recipes/15-test_ec.t ............... ok
> ../test/recipes/15-test_ecdh.t ............. ok
> ../test/recipes/15-test_ecdsa.t ............ ok
> ../test/recipes/15-test_rsa.t .............. ok
> ../test/recipes/20-test_enc.t .............. ok
> ../test/recipes/25-test_crl.t .............. ok
> ../test/recipes/25-test_d2i.t .............. ok
> ../test/recipes/25-test_pkcs7.t ............ ok
> ../test/recipes/25-test_req.t .............. ok
> ../test/recipes/25-test_sid.t .............. ok
> ../test/recipes/25-test_verify.t ........... ok
> ../test/recipes/25-test_x509.t ............. ok
> ../test/recipes/30-test_afalg.t ............ 1/1
> # Failed test 'running afalgtest'
> # at ../test/recipes/30-test_afalg.t line 23.
> # Looks like you failed 1 test of 1.
> ../test/recipes/30-test_afalg.t ............ Dubious, test returned 1
> (wstat 256, 0x100)
> Failed 1/1 subtests
> ../test/recipes/30-test_engine.t ........... ok
> ../test/recipes/30-test_evp.t .............. ok
> ../test/recipes/30-test_evp_extra.t ........ ok
> ../test/recipes/30-test_pbelu.t ............ ok
> ../test/recipes/40-test_rehash.t ........... 1/5
> # Failed test 'Testing that we aren't running as a privileged user,
> such as root'
> # at ../test/recipes/40-test_rehash.t line 49.
> # Looks like you failed 1 test of 5.
> ../test/recipes/40-test_rehash.t ........... Dubious, test returned 1
> (wstat 256, 0x100)
> Failed 1/5 subtests
> (less 1 skipped subtest: 3 okay)
> ../test/recipes/70-test_asyncio.t .......... ok
> ../test/recipes/70-test_clienthello.t ...... ok
> ../test/recipes/70-test_packet.t ........... ok
> ../test/recipes/70-test_sslcertstatus.t .... ok
> ../test/recipes/70-test_sslextension.t ..... ok
> ../test/recipes/70-test_sslrecords.t ....... ok
> ../test/recipes/70-test_sslsessiontick.t ... ok
> ../test/recipes/70-test_sslskewith0p.t ..... ok
> ../test/recipes/70-test_sslvertol.t ........ ok
> ../test/recipes/70-test_tlsextms.t ......... ok
> ../test/recipes/70-test_verify_extra.t ..... ok
> ../test/recipes/80-test_ca.t ............... ok
> ../test/recipes/80-test_cipherlist.t ....... ok
> ../test/recipes/80-test_cms.t .............. ok
> ../test/recipes/80-test_ct.t ............... ok
> ../test/recipes/80-test_dane.t ............. ok
> ../test/recipes/80-test_dtlsv1listen.t ..... ok
> ../test/recipes/80-test_ocsp.t ............. ok
> ../test/recipes/80-test_ssl_new.t .......... ok
> ../test/recipes/80-test_ssl_old.t .......... ok
> ../test/recipes/80-test_ssl_test_ctx.t ..... ok
> ../test/recipes/80-test_tsa.t .............. ok
> ../test/recipes/80-test_x509aux.t .......... ok
> ../test/recipes/90-test_async.t ............ ok
> ../test/recipes/90-test_bioprint.t ......... ok
> ../test/recipes/90-test_constant_time.t .... ok
> ../test/recipes/90-test_gmdiff.t ........... ok
> ../test/recipes/90-test_heartbeat.t ........ skipped: heartbeats is
> not supported by this OpenSSL build
> ../test/recipes/90-test_ige.t .............. ok
> ../test/recipes/90-test_memleak.t .......... ok
> ../test/recipes/90-test_np.t ............... ok
> ../test/recipes/90-test_p5_crpt2.t ......... ok
> ../test/recipes/90-test_secmem.t ........... ok
> ../test/recipes/90-test_srp.t .............. ok
> ../test/recipes/90-test_sslapi.t ........... ok
> ../test/recipes/90-test_threads.t .......... ok
> ../test/recipes/90-test_v3name.t ........... ok
> Test Summary Report
> -------------------
> ../test/recipes/30-test_afalg.t (Wstat: 256 Tests: 1 Failed: 1)
> Failed test: 1
> Non-zero exit status: 1
> ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)
> Failed test: 4
> Non-zero exit status: 1
> Files=80, Tests=422, 44 wallclock secs ( 0.34 usr 0.11 sys + 25.08
> cusr 2.64 csys = 28.17 CPU)
> Result: FAIL
> Failed 2/80 test programs. 2/422 subtests failed.
> Makefile:130: recipe for target 'tests' failed
> make: *** [tests] Error 255
>


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted


From hkario at redhat.com  Tue Jul 19 13:51:17 2016
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 19 Jul 2016 15:51:17 +0200
Subject: [openssl-dev] pkcs12 settings,
	Was: Re: [openssl.org #4588] pkcs12 -info doesn't handle PKCS#12
	files with PKCS#5 v2.0 PBE
In-Reply-To: <rt-4.0.19-17766-1468930053-68.4588-6-0@openssl.org>
References: <RT-Ticket-4588@openssl.org>
 <1992022.TCv6Aigntu@pintsize.usersys.redhat.com>
 <rt-4.0.19-17766-1468930053-68.4588-6-0@openssl.org>
Message-ID: <1541032.77INFnC1dm@pintsize.usersys.redhat.com>

On Tuesday, 19 July 2016 12:07:33 CEST Stephen Henson via RT wrote:
> Thanks for the report, fixed now in master and 1.0.2.
> 
> Steve.

Thanks!

I have few questions now though:

I've noticed that 1.0.2 uses sha1 hmac for the PRF while the master
uses sha256

is there a way to set this?

also, is there a way to report the MAC algorithm used over the whole
file (the one set using -macalg)

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/cef98870/attachment.sig>

From matt at openssl.org  Tue Jul 19 14:01:12 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 19 Jul 2016 15:01:12 +0100
Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32
In-Reply-To: <rt-4.0.19-17766-1468935695-1831.4584-6-0@openssl.org>
References: <RT-Ticket-4584@openssl.org>
 <CAH8yC8m0tt3xPMK2QKgbrL9dR_wmyJvp2nNNK+hS0sz4bs7ZsQ@mail.gmail.com>
 <rt-4.0.19-17766-1468935695-1831.4584-6-0@openssl.org>
Message-ID: <578E32A8.5090900@openssl.org>



On 19/07/16 14:41, Richard Levitte via RT wrote:
> Hi Jeff,
> 
> I'm going to assume that a newer checkout of the master branch won't change
> much, so if you please, try this command and send mack the result:

Who is Mack? ;-)

> 
> make test TESTS='test_afalg test_rehash'

Did you mean to include "VERBOSE=1"?

VERBOSE=1 make TESTS='test_afalg test_rehash' test

Matt


> 
> Cheers,
> Richard
> 
> On Thu Jun 23 11:10:04 2016, noloader at gmail.com wrote:
>> I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
>> and working from HEAD:
>>
>> # git rev-parse HEAD
>> b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92
>>
>> Running 'make test' under a machine configured with './Configure
>> linux-x32 enable-ec_nistp_64_gcc_128' results in two failed self
>> tests:
>>
>> make[1]: Leaving directory '/openssl'
>> ( cd test; \
>> SRCTOP=../. \
>> BLDTOP=../. \
>> PERL="perl" \
>> EXE_EXT= \
>> OPENSSL_ENGINES=.././engines \
>> perl .././test/run_tests.pl )
>> ../test/recipes/01-test_abort.t ............ ok
>> ../test/recipes/01-test_ordinals.t ......... ok
>> ../test/recipes/01-test_symbol_presence.t .. ok
>> ../test/recipes/05-test_bf.t ............... ok
>> ../test/recipes/05-test_cast.t ............. ok
>> ../test/recipes/05-test_des.t .............. ok
>> ../test/recipes/05-test_hmac.t ............. ok
>> ../test/recipes/05-test_idea.t ............. ok
>> ../test/recipes/05-test_md2.t .............. skipped: md2 is not
>> supported by this OpenSSL build
>> ../test/recipes/05-test_md4.t .............. ok
>> ../test/recipes/05-test_md5.t .............. ok
>> ../test/recipes/05-test_mdc2.t ............. ok
>> ../test/recipes/05-test_rand.t ............. ok
>> ../test/recipes/05-test_rc2.t .............. ok
>> ../test/recipes/05-test_rc4.t .............. ok
>> ../test/recipes/05-test_rc5.t .............. skipped: rc5 is not
>> supported by this OpenSSL build
>> ../test/recipes/05-test_rmd.t .............. ok
>> ../test/recipes/05-test_sha1.t ............. ok
>> ../test/recipes/05-test_sha256.t ........... ok
>> ../test/recipes/05-test_sha512.t ........... ok
>> ../test/recipes/05-test_wp.t ............... ok
>> ../test/recipes/10-test_bn.t ............... ok
>> ../test/recipes/10-test_exp.t .............. ok
>> ../test/recipes/15-test_dh.t ............... ok
>> ../test/recipes/15-test_dsa.t .............. ok
>> ../test/recipes/15-test_ec.t ............... ok
>> ../test/recipes/15-test_ecdh.t ............. ok
>> ../test/recipes/15-test_ecdsa.t ............ ok
>> ../test/recipes/15-test_rsa.t .............. ok
>> ../test/recipes/20-test_enc.t .............. ok
>> ../test/recipes/25-test_crl.t .............. ok
>> ../test/recipes/25-test_d2i.t .............. ok
>> ../test/recipes/25-test_pkcs7.t ............ ok
>> ../test/recipes/25-test_req.t .............. ok
>> ../test/recipes/25-test_sid.t .............. ok
>> ../test/recipes/25-test_verify.t ........... ok
>> ../test/recipes/25-test_x509.t ............. ok
>> ../test/recipes/30-test_afalg.t ............ 1/1
>> # Failed test 'running afalgtest'
>> # at ../test/recipes/30-test_afalg.t line 23.
>> # Looks like you failed 1 test of 1.
>> ../test/recipes/30-test_afalg.t ............ Dubious, test returned 1
>> (wstat 256, 0x100)
>> Failed 1/1 subtests
>> ../test/recipes/30-test_engine.t ........... ok
>> ../test/recipes/30-test_evp.t .............. ok
>> ../test/recipes/30-test_evp_extra.t ........ ok
>> ../test/recipes/30-test_pbelu.t ............ ok
>> ../test/recipes/40-test_rehash.t ........... 1/5
>> # Failed test 'Testing that we aren't running as a privileged user,
>> such as root'
>> # at ../test/recipes/40-test_rehash.t line 49.
>> # Looks like you failed 1 test of 5.
>> ../test/recipes/40-test_rehash.t ........... Dubious, test returned 1
>> (wstat 256, 0x100)
>> Failed 1/5 subtests
>> (less 1 skipped subtest: 3 okay)
>> ../test/recipes/70-test_asyncio.t .......... ok
>> ../test/recipes/70-test_clienthello.t ...... ok
>> ../test/recipes/70-test_packet.t ........... ok
>> ../test/recipes/70-test_sslcertstatus.t .... ok
>> ../test/recipes/70-test_sslextension.t ..... ok
>> ../test/recipes/70-test_sslrecords.t ....... ok
>> ../test/recipes/70-test_sslsessiontick.t ... ok
>> ../test/recipes/70-test_sslskewith0p.t ..... ok
>> ../test/recipes/70-test_sslvertol.t ........ ok
>> ../test/recipes/70-test_tlsextms.t ......... ok
>> ../test/recipes/70-test_verify_extra.t ..... ok
>> ../test/recipes/80-test_ca.t ............... ok
>> ../test/recipes/80-test_cipherlist.t ....... ok
>> ../test/recipes/80-test_cms.t .............. ok
>> ../test/recipes/80-test_ct.t ............... ok
>> ../test/recipes/80-test_dane.t ............. ok
>> ../test/recipes/80-test_dtlsv1listen.t ..... ok
>> ../test/recipes/80-test_ocsp.t ............. ok
>> ../test/recipes/80-test_ssl_new.t .......... ok
>> ../test/recipes/80-test_ssl_old.t .......... ok
>> ../test/recipes/80-test_ssl_test_ctx.t ..... ok
>> ../test/recipes/80-test_tsa.t .............. ok
>> ../test/recipes/80-test_x509aux.t .......... ok
>> ../test/recipes/90-test_async.t ............ ok
>> ../test/recipes/90-test_bioprint.t ......... ok
>> ../test/recipes/90-test_constant_time.t .... ok
>> ../test/recipes/90-test_gmdiff.t ........... ok
>> ../test/recipes/90-test_heartbeat.t ........ skipped: heartbeats is
>> not supported by this OpenSSL build
>> ../test/recipes/90-test_ige.t .............. ok
>> ../test/recipes/90-test_memleak.t .......... ok
>> ../test/recipes/90-test_np.t ............... ok
>> ../test/recipes/90-test_p5_crpt2.t ......... ok
>> ../test/recipes/90-test_secmem.t ........... ok
>> ../test/recipes/90-test_srp.t .............. ok
>> ../test/recipes/90-test_sslapi.t ........... ok
>> ../test/recipes/90-test_threads.t .......... ok
>> ../test/recipes/90-test_v3name.t ........... ok
>> Test Summary Report
>> -------------------
>> ../test/recipes/30-test_afalg.t (Wstat: 256 Tests: 1 Failed: 1)
>> Failed test: 1
>> Non-zero exit status: 1
>> ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)
>> Failed test: 4
>> Non-zero exit status: 1
>> Files=80, Tests=422, 44 wallclock secs ( 0.34 usr 0.11 sys + 25.08
>> cusr 2.64 csys = 28.17 CPU)
>> Result: FAIL
>> Failed 2/80 test programs. 2/422 subtests failed.
>> Makefile:130: recipe for target 'tests' failed
>> make: *** [tests] Error 255
>>
> 
> 
> --
> Richard Levitte
> levitte at openssl.org
> 

From rt at openssl.org  Tue Jul 19 14:01:17 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 19 Jul 2016 14:01:17 +0000
Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32
In-Reply-To: <578E32A8.5090900@openssl.org>
References: <RT-Ticket-4584@openssl.org>
 <CAH8yC8m0tt3xPMK2QKgbrL9dR_wmyJvp2nNNK+hS0sz4bs7ZsQ@mail.gmail.com>
 <rt-4.0.19-17766-1468935695-1831.4584-6-0@openssl.org>
 <578E32A8.5090900@openssl.org>
Message-ID: <rt-4.0.19-17766-1468936877-564.4584-6-0@openssl.org>



On 19/07/16 14:41, Richard Levitte via RT wrote:
> Hi Jeff,
> 
> I'm going to assume that a newer checkout of the master branch won't change
> much, so if you please, try this command and send mack the result:

Who is Mack? ;-)

> 
> make test TESTS='test_afalg test_rehash'

Did you mean to include "VERBOSE=1"?

VERBOSE=1 make TESTS='test_afalg test_rehash' test

Matt


> 
> Cheers,
> Richard
> 
> On Thu Jun 23 11:10:04 2016, noloader at gmail.com wrote:
>> I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
>> and working from HEAD:
>>
>> # git rev-parse HEAD
>> b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92
>>
>> Running 'make test' under a machine configured with './Configure
>> linux-x32 enable-ec_nistp_64_gcc_128' results in two failed self
>> tests:
>>
>> make[1]: Leaving directory '/openssl'
>> ( cd test; \
>> SRCTOP=../. \
>> BLDTOP=../. \
>> PERL="perl" \
>> EXE_EXT= \
>> OPENSSL_ENGINES=.././engines \
>> perl .././test/run_tests.pl )
>> ../test/recipes/01-test_abort.t ............ ok
>> ../test/recipes/01-test_ordinals.t ......... ok
>> ../test/recipes/01-test_symbol_presence.t .. ok
>> ../test/recipes/05-test_bf.t ............... ok
>> ../test/recipes/05-test_cast.t ............. ok
>> ../test/recipes/05-test_des.t .............. ok
>> ../test/recipes/05-test_hmac.t ............. ok
>> ../test/recipes/05-test_idea.t ............. ok
>> ../test/recipes/05-test_md2.t .............. skipped: md2 is not
>> supported by this OpenSSL build
>> ../test/recipes/05-test_md4.t .............. ok
>> ../test/recipes/05-test_md5.t .............. ok
>> ../test/recipes/05-test_mdc2.t ............. ok
>> ../test/recipes/05-test_rand.t ............. ok
>> ../test/recipes/05-test_rc2.t .............. ok
>> ../test/recipes/05-test_rc4.t .............. ok
>> ../test/recipes/05-test_rc5.t .............. skipped: rc5 is not
>> supported by this OpenSSL build
>> ../test/recipes/05-test_rmd.t .............. ok
>> ../test/recipes/05-test_sha1.t ............. ok
>> ../test/recipes/05-test_sha256.t ........... ok
>> ../test/recipes/05-test_sha512.t ........... ok
>> ../test/recipes/05-test_wp.t ............... ok
>> ../test/recipes/10-test_bn.t ............... ok
>> ../test/recipes/10-test_exp.t .............. ok
>> ../test/recipes/15-test_dh.t ............... ok
>> ../test/recipes/15-test_dsa.t .............. ok
>> ../test/recipes/15-test_ec.t ............... ok
>> ../test/recipes/15-test_ecdh.t ............. ok
>> ../test/recipes/15-test_ecdsa.t ............ ok
>> ../test/recipes/15-test_rsa.t .............. ok
>> ../test/recipes/20-test_enc.t .............. ok
>> ../test/recipes/25-test_crl.t .............. ok
>> ../test/recipes/25-test_d2i.t .............. ok
>> ../test/recipes/25-test_pkcs7.t ............ ok
>> ../test/recipes/25-test_req.t .............. ok
>> ../test/recipes/25-test_sid.t .............. ok
>> ../test/recipes/25-test_verify.t ........... ok
>> ../test/recipes/25-test_x509.t ............. ok
>> ../test/recipes/30-test_afalg.t ............ 1/1
>> # Failed test 'running afalgtest'
>> # at ../test/recipes/30-test_afalg.t line 23.
>> # Looks like you failed 1 test of 1.
>> ../test/recipes/30-test_afalg.t ............ Dubious, test returned 1
>> (wstat 256, 0x100)
>> Failed 1/1 subtests
>> ../test/recipes/30-test_engine.t ........... ok
>> ../test/recipes/30-test_evp.t .............. ok
>> ../test/recipes/30-test_evp_extra.t ........ ok
>> ../test/recipes/30-test_pbelu.t ............ ok
>> ../test/recipes/40-test_rehash.t ........... 1/5
>> # Failed test 'Testing that we aren't running as a privileged user,
>> such as root'
>> # at ../test/recipes/40-test_rehash.t line 49.
>> # Looks like you failed 1 test of 5.
>> ../test/recipes/40-test_rehash.t ........... Dubious, test returned 1
>> (wstat 256, 0x100)
>> Failed 1/5 subtests
>> (less 1 skipped subtest: 3 okay)
>> ../test/recipes/70-test_asyncio.t .......... ok
>> ../test/recipes/70-test_clienthello.t ...... ok
>> ../test/recipes/70-test_packet.t ........... ok
>> ../test/recipes/70-test_sslcertstatus.t .... ok
>> ../test/recipes/70-test_sslextension.t ..... ok
>> ../test/recipes/70-test_sslrecords.t ....... ok
>> ../test/recipes/70-test_sslsessiontick.t ... ok
>> ../test/recipes/70-test_sslskewith0p.t ..... ok
>> ../test/recipes/70-test_sslvertol.t ........ ok
>> ../test/recipes/70-test_tlsextms.t ......... ok
>> ../test/recipes/70-test_verify_extra.t ..... ok
>> ../test/recipes/80-test_ca.t ............... ok
>> ../test/recipes/80-test_cipherlist.t ....... ok
>> ../test/recipes/80-test_cms.t .............. ok
>> ../test/recipes/80-test_ct.t ............... ok
>> ../test/recipes/80-test_dane.t ............. ok
>> ../test/recipes/80-test_dtlsv1listen.t ..... ok
>> ../test/recipes/80-test_ocsp.t ............. ok
>> ../test/recipes/80-test_ssl_new.t .......... ok
>> ../test/recipes/80-test_ssl_old.t .......... ok
>> ../test/recipes/80-test_ssl_test_ctx.t ..... ok
>> ../test/recipes/80-test_tsa.t .............. ok
>> ../test/recipes/80-test_x509aux.t .......... ok
>> ../test/recipes/90-test_async.t ............ ok
>> ../test/recipes/90-test_bioprint.t ......... ok
>> ../test/recipes/90-test_constant_time.t .... ok
>> ../test/recipes/90-test_gmdiff.t ........... ok
>> ../test/recipes/90-test_heartbeat.t ........ skipped: heartbeats is
>> not supported by this OpenSSL build
>> ../test/recipes/90-test_ige.t .............. ok
>> ../test/recipes/90-test_memleak.t .......... ok
>> ../test/recipes/90-test_np.t ............... ok
>> ../test/recipes/90-test_p5_crpt2.t ......... ok
>> ../test/recipes/90-test_secmem.t ........... ok
>> ../test/recipes/90-test_srp.t .............. ok
>> ../test/recipes/90-test_sslapi.t ........... ok
>> ../test/recipes/90-test_threads.t .......... ok
>> ../test/recipes/90-test_v3name.t ........... ok
>> Test Summary Report
>> -------------------
>> ../test/recipes/30-test_afalg.t (Wstat: 256 Tests: 1 Failed: 1)
>> Failed test: 1
>> Non-zero exit status: 1
>> ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)
>> Failed test: 4
>> Non-zero exit status: 1
>> Files=80, Tests=422, 44 wallclock secs ( 0.34 usr 0.11 sys + 25.08
>> cusr 2.64 csys = 28.17 CPU)
>> Result: FAIL
>> Failed 2/80 test programs. 2/422 subtests failed.
>> Makefile:130: recipe for target 'tests' failed
>> make: *** [tests] Error 255
>>
> 
> 
> --
> Richard Levitte
> levitte at openssl.org
> 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 14:11:38 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 14:11:38 +0000
Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32
In-Reply-To: <rt-4.0.19-17766-1468936877-77.4584-6-0@openssl.org>
References: <RT-Ticket-4584@openssl.org>
 <CAH8yC8m0tt3xPMK2QKgbrL9dR_wmyJvp2nNNK+hS0sz4bs7ZsQ@mail.gmail.com>
 <rt-4.0.19-17766-1468935695-1831.4584-6-0@openssl.org>
 <578E32A8.5090900@openssl.org>
 <rt-4.0.19-17766-1468936877-77.4584-6-0@openssl.org>
Message-ID: <rt-4.0.19-17767-1468937498-1366.4584-6-0@openssl.org>

On Tue Jul 19 14:01:17 2016, matt wrote:
>
>
> On 19/07/16 14:41, Richard Levitte via RT wrote:
> > Hi Jeff,
> >
> > I'm going to assume that a newer checkout of the master branch won't
> > change
> > much, so if you please, try this command and send mack the result:
>
> Who is Mack? ;-)

Mack is back ;-)

> > make test TESTS='test_afalg test_rehash'
>
> Did you mean to include "VERBOSE=1"?
>
> VERBOSE=1 make TESTS='test_afalg test_rehash' test

Ah, yes, of course...

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 14:12:41 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 19 Jul 2016 14:12:41 +0000
Subject: [openssl-dev] [openssl.org #4591] asynctest: double free or
	corruption on hppa
In-Reply-To: <rt-4.0.19-21189-1467021081-1436.4591-6-0@openssl.org>
References: <RT-Ticket-4591@openssl.org> <20160626144349.GA7315@roeckx.be>
 <rt-4.0.19-21188-1466952246-1487.4591-21-0@openssl.org>
 <5770F716.9000109@openssl.org>
 <rt-4.0.19-21189-1467021081-1436.4591-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1468937560-736.4591-6-0@openssl.org>

On Mon Jun 27 09:51:21 2016, matt wrote:
>
>
> On 26/06/16 15:44, Kurt Roeckx via RT wrote:
> > Hi,
> >
> > My last upload of openssl to experimental show this on hppa:
> > *** Error in `./asynctest': double free or corruption (out):
> > 0x007307d8 ***
> > ../util/shlib_wrap.sh ./asynctest => 134
> >
> > # Failed test 'running asynctest'
> > # at ../test/testlib/OpenSSL/Test/Simple.pm line 77.
> > # Looks like you failed 1 test of 1.
> >
> > A full log can be seen at:
> >
https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=hppa&ver=1.1.0~pre5-
> > 4&stamp=1466951184
> >
> > This is with commit c32bdbf171ce6650ef045ec47b5abe0de7c264db
> >
> > The previous upload was succesful, the log of that is:
> >
https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=hppa&ver=1.1.0~pre5-
> > 3&stamp=1465602753
> >
> > That was with commit 5000a6d1215ea7d6ed6179d0bcd44263f6e3c26b
>
>
> There do not appear to be any changes at all in either the asynctest
> or
> the async code between those two commits.
>
> >
> >
> > I'm not sure if this is reproducible or not, I can try a new build
> > if needed.
>
> That would be good to know, although to take this any further I think
> we're going to need more information, e.g. a backtrace.

Is this still an issue? And if so are you able to provide a backtrace?

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4591
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 14:38:04 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 14:38:04 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures
In-Reply-To: <rt-4.0.19-20845-1468259286-1010.4614-6-0@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>
 <2b91a3576c824f4ebb0ea6d08af1ad18@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-20845-1468259286-1010.4614-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1468939084-799.4614-6-0@openssl.org>

On Mon Jul 11 17:48:06 2016, rsalz at akamai.com wrote:
> Previously we've changed return-types from void to int. If there's
> still time, that seems like the thing to do here.

I agree.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 15:23:15 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 15:23:15 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures
In-Reply-To: <20160711162016.GA3255@roeckx.be>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
Message-ID: <rt-4.0.19-17766-1468941794-53.4614-6-0@openssl.org>

On Mon Jul 11 16:20:29 2016, kurt at roeckx.be wrote:
> Hi,
>
> When trying to check what happens if we simulate malloc()
> returning NULL I'm running into a problem that I'm not sure how to
> deal with.
>
> We have CRYPTO_THREAD_run_once(), which takes an init() function
> that returns void, so it can't return failures. At least the
> pthread_once() function also has it as void.
>
> But if those functions call malloc() and that returns NULL, we now
> don't catch that error, and later just try to use a NULL pointer.
>
> Anybody a good idea how to solve this?

Rethinking this...

Most of all, we use CRYPTO_THREAD_run_once() internally to initiate the first
locks, so pretty much in an initial state of the library (not entirely true,
since we do these inits opportunistically, but it's probable that they happen
very early on). If they are having memory allocation, the running app is
probably in deep shit anyway, so a hard assert in our diverse inits would
probably be appropriate either way.

It was suggested that we change the return type of the init routine to int and
have it return something appropriate (0 for error, 1 for success, say?), but
since at least pthread_once() takes a function returning void (and thereby
doesn't care about any returned value), it seems like our hands are forced
anyway.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 15:26:58 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 19 Jul 2016 15:26:58 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc
	failures
In-Reply-To: <578E46BD.4070807@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-17766-1468941794-53.4614-6-0@openssl.org>
 <578E46BD.4070807@openssl.org>
Message-ID: <rt-4.0.19-17767-1468942018-1972.4614-6-0@openssl.org>



On 19/07/16 16:23, Richard Levitte via RT wrote:
> On Mon Jul 11 16:20:29 2016, kurt at roeckx.be wrote:
>> Hi,
>>
>> When trying to check what happens if we simulate malloc()
>> returning NULL I'm running into a problem that I'm not sure how to
>> deal with.
>>
>> We have CRYPTO_THREAD_run_once(), which takes an init() function
>> that returns void, so it can't return failures. At least the
>> pthread_once() function also has it as void.
>>
>> But if those functions call malloc() and that returns NULL, we now
>> don't catch that error, and later just try to use a NULL pointer.
>>
>> Anybody a good idea how to solve this?
> 
> Rethinking this...
> 
> Most of all, we use CRYPTO_THREAD_run_once() internally to initiate the first
> locks, so pretty much in an initial state of the library (not entirely true,
> since we do these inits opportunistically, but it's probable that they happen
> very early on). If they are having memory allocation, the running app is
> probably in deep shit anyway, so a hard assert in our diverse inits would
> probably be appropriate either way.

You are assuming that the application loads and inits OpenSSL early and
that it is critical to its function. It may not be.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 15:36:04 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 15:36:04 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures
In-Reply-To: <rt-4.0.19-17767-1468942018-1239.4614-6-0@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-17766-1468941794-53.4614-6-0@openssl.org>
 <578E46BD.4070807@openssl.org>
 <rt-4.0.19-17767-1468942018-1239.4614-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1468942564-861.4614-6-0@openssl.org>

On Tue Jul 19 15:26:58 2016, matt wrote:
>
>
> On 19/07/16 16:23, Richard Levitte via RT wrote:
> > On Mon Jul 11 16:20:29 2016, kurt at roeckx.be wrote:
> >> Hi,
> >>
> >> When trying to check what happens if we simulate malloc()
> >> returning NULL I'm running into a problem that I'm not sure how to
> >> deal with.
> >>
> >> We have CRYPTO_THREAD_run_once(), which takes an init() function
> >> that returns void, so it can't return failures. At least the
> >> pthread_once() function also has it as void.
> >>
> >> But if those functions call malloc() and that returns NULL, we now
> >> don't catch that error, and later just try to use a NULL pointer.
> >>
> >> Anybody a good idea how to solve this?
> >
> > Rethinking this...
> >
> > Most of all, we use CRYPTO_THREAD_run_once() internally to initiate
> > the first
> > locks, so pretty much in an initial state of the library (not
> > entirely true,
> > since we do these inits opportunistically, but it's probable that
> > they happen
> > very early on). If they are having memory allocation, the running app
> > is
> > probably in deep shit anyway, so a hard assert in our diverse inits
> > would
> > probably be appropriate either way.
>
> You are assuming that the application loads and inits OpenSSL early
> and
> that it is critical to its function. It may not be.

True, I made that assumption.

Ok, so the other way I can think of is a bit ugly, but... using oob data, in
this case a variable that the init routine must set to signal that everything
went well. I'm thinking a variable in CRYPTO_THREAD_run_once() that gets passed
by reference to the init routine

To be noted is that we never check the value CRYPTO_THREAD_run_once()
returns... Should we make it __owur?

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 15:36:59 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 15:36:59 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures
In-Reply-To: <rt-4.0.19-17766-1468942564-1090.4614-6-0@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-17766-1468941794-53.4614-6-0@openssl.org>
 <578E46BD.4070807@openssl.org>
 <rt-4.0.19-17767-1468942018-1239.4614-6-0@openssl.org>
 <rt-4.0.19-17766-1468942564-1090.4614-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1468942619-490.4614-6-0@openssl.org>

On Tue Jul 19 15:36:04 2016, levitte wrote:
> To be noted is that we never check the value CRYPTO_THREAD_run_once()
> returns... Should we make it __owur?

I spoke too fast. We do... just not always.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 15:40:50 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 15:40:50 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures
In-Reply-To: <rt-4.0.19-17766-1468942564-1090.4614-6-0@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-17766-1468941794-53.4614-6-0@openssl.org>
 <578E46BD.4070807@openssl.org>
 <rt-4.0.19-17767-1468942018-1239.4614-6-0@openssl.org>
 <rt-4.0.19-17766-1468942564-1090.4614-6-0@openssl.org>
Message-ID: <rt-4.0.19-17767-1468942850-875.4614-6-0@openssl.org>

On Tue Jul 19 15:36:04 2016, levitte wrote:
> Ok, so the other way I can think of is a bit ugly, but... using oob
> data, in
> this case a variable that the init routine must set to signal that
> everything
> went well. I'm thinking a variable in CRYPTO_THREAD_run_once() that
> gets passed
> by reference to the init routine

Never mind that, I wasn't thinking straight...

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From kurt at roeckx.be  Tue Jul 19 16:22:18 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 19 Jul 2016 18:22:18 +0200
Subject: [openssl-dev] [openssl.org #4591] asynctest: double free or
	corruption on hppa
In-Reply-To: <rt-4.0.19-17766-1468937560-736.4591-6-0@openssl.org>
References: <RT-Ticket-4591@openssl.org> <20160626144349.GA7315@roeckx.be>
 <rt-4.0.19-21188-1466952246-1487.4591-21-0@openssl.org>
 <5770F716.9000109@openssl.org>
 <rt-4.0.19-21189-1467021081-1436.4591-6-0@openssl.org>
 <rt-4.0.19-17766-1468937560-736.4591-6-0@openssl.org>
Message-ID: <20160719162217.GA27822@roeckx.be>

On Tue, Jul 19, 2016 at 02:12:41PM +0000, Matt Caswell via RT wrote:
> 
> Is this still an issue? And if so are you able to provide a backtrace?

This might be a combination of kernel, glibc and gcc bugs, some of
which might have been fixed.  In any case, I don't think it's an
openssl problem.

See the thread starting at:
https://lists.debian.org/debian-hppa/2016/06/msg00046.html


Kurt


From rt at openssl.org  Tue Jul 19 16:22:22 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Tue, 19 Jul 2016 16:22:22 +0000
Subject: [openssl-dev] [openssl.org #4591] asynctest: double free or
	corruption on hppa
In-Reply-To: <20160719162217.GA27822@roeckx.be>
References: <RT-Ticket-4591@openssl.org> <20160626144349.GA7315@roeckx.be>
 <rt-4.0.19-21188-1466952246-1487.4591-21-0@openssl.org>
 <5770F716.9000109@openssl.org>
 <rt-4.0.19-21189-1467021081-1436.4591-6-0@openssl.org>
 <rt-4.0.19-17766-1468937560-736.4591-6-0@openssl.org>
 <20160719162217.GA27822@roeckx.be>
Message-ID: <rt-4.0.19-17766-1468945342-1796.4591-6-0@openssl.org>

On Tue, Jul 19, 2016 at 02:12:41PM +0000, Matt Caswell via RT wrote:
> 
> Is this still an issue? And if so are you able to provide a backtrace?

This might be a combination of kernel, glibc and gcc bugs, some of
which might have been fixed.  In any case, I don't think it's an
openssl problem.

See the thread starting at:
https://lists.debian.org/debian-hppa/2016/06/msg00046.html


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4591
Please log in as guest with password guest if prompted


From kurt at roeckx.be  Tue Jul 19 16:41:08 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 19 Jul 2016 18:41:08 +0200
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc
 failures
In-Reply-To: <rt-4.0.19-20845-1468259286-472.4614-6-0@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>
 <2b91a3576c824f4ebb0ea6d08af1ad18@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-20845-1468259286-472.4614-6-0@openssl.org>
Message-ID: <20160719164107.GB27822@roeckx.be>

On Mon, Jul 11, 2016 at 05:48:06PM +0000, Salz, Rich via RT wrote:
> Previously we've changed return-types from void to int.  If there's still time, that seems like the thing to do here.

I've pushed a branched on github that at least does some of the
things.  See github #1330.


Kurt


From rt at openssl.org  Tue Jul 19 16:41:13 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Tue, 19 Jul 2016 16:41:13 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc
	failures
In-Reply-To: <20160719164107.GB27822@roeckx.be>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>
 <2b91a3576c824f4ebb0ea6d08af1ad18@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-20845-1468259286-472.4614-6-0@openssl.org>
 <20160719164107.GB27822@roeckx.be>
Message-ID: <rt-4.0.19-17767-1468946473-1163.4614-6-0@openssl.org>

On Mon, Jul 11, 2016 at 05:48:06PM +0000, Salz, Rich via RT wrote:
> Previously we've changed return-types from void to int.  If there's still time, that seems like the thing to do here.

I've pushed a branched on github that at least does some of the
things.  See github #1330.


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From uri at ll.mit.edu  Tue Jul 19 17:05:43 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 19 Jul 2016 17:05:43 +0000
Subject: [openssl-dev] doc/crypto/BIO_set_callback.pod still not fixed in
	the master
Message-ID: <D3B3D621.2F5EF%uri@ll.mit.edu>

Please add a blank line after the ?+over? around line 39 in
doc/crypto/BIO_set_callback.pod
-- 
Regards,
Uri Blumenthal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5227 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/a50c7e1c/attachment.bin>

From rt at openssl.org  Tue Jul 19 17:26:02 2016
From: rt at openssl.org (Viktor Dukhovni via RT)
Date: Tue, 19 Jul 2016 17:26:02 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc
	failures
In-Reply-To: <1454A195-0869-47FF-B290-B490F845B2A4@dukhovni.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-17766-1468941794-53.4614-6-0@openssl.org>
 <578E46BD.4070807@openssl.org>
 <rt-4.0.19-17767-1468942018-1972.4614-6-0@openssl.org>
 <1454A195-0869-47FF-B290-B490F845B2A4@dukhovni.org>
Message-ID: <rt-4.0.19-17767-1468949162-377.4614-6-0@openssl.org>


> On Jul 19, 2016, at 5:26 PM, Matt Caswell via RT <rt at openssl.org> wrote:
> 
>> Most of all, we use CRYPTO_THREAD_run_once() internally to initiate the first
>> locks, so pretty much in an initial state of the library (not entirely true,
>> since we do these inits opportunistically, but it's probable that they happen
>> very early on). If they are having memory allocation, the running app is
>> probably in deep shit anyway, so a hard assert in our diverse inits would
>> probably be appropriate either way.
> 
> You are assuming that the application loads and inits OpenSSL early and
> that it is critical to its function. It may not be.

Postfix expects to be able to continue "degraded" operation without TLS,
when TLS initialization fails.  Asserts are not acceptable.  They would
cause Postfix to look for a different SSL library.

When initialization fails, all subsequent calls can return errors, but
assert is not an option.

-- 
	Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1963 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/65017cbc/attachment.bin>

From rt at openssl.org  Tue Jul 19 17:47:43 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 19 Jul 2016 17:47:43 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures
In-Reply-To: <rt-4.0.19-17767-1468946473-620.4614-6-0@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>
 <2b91a3576c824f4ebb0ea6d08af1ad18@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-20845-1468259286-472.4614-6-0@openssl.org>
 <20160719164107.GB27822@roeckx.be>
 <rt-4.0.19-17767-1468946473-620.4614-6-0@openssl.org>
Message-ID: <rt-4.0.19-17767-1468950463-1553.4614-6-0@openssl.org>

On Tue Jul 19 16:41:13 2016, kurt at roeckx.be wrote:
> On Mon, Jul 11, 2016 at 05:48:06PM +0000, Salz, Rich via RT wrote:
> > Previously we've changed return-types from void to int. If there's
> > still time, that seems like the thing to do here.
>
> I've pushed a branched on github that at least does some of the
> things. See github #1330.

Likewise for the CRYPTO_THREAD_run_once() issue, in
https://github.com/openssl/openssl/pull/1332

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From janjust at nikhef.nl  Tue Jul 19 17:25:53 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 19 Jul 2016 19:25:53 +0200
Subject: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
In-Reply-To: <rt-4.0.19-19821-1468870278-959.4617-6-0@openssl.org>
References: <RT-Ticket-4617@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E03D9@CINMBCNA09.e2k.ad.ge.com>
 <rt-4.0.19-19821-1468859978-1229.4617-21-0@openssl.org>
 <48922eba-0449-b64b-5a92-665c48bad27c@nikhef.nl>
 <rt-4.0.19-19822-1468866365-1905.4617-6-0@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E04DF@CINMBCNA09.e2k.ad.ge.com>
 <rt-4.0.19-19821-1468870278-959.4617-6-0@openssl.org>
Message-ID: <0ec7bd58-3c5b-29a6-2c60-9efced31744f@nikhef.nl>

Hi Harold,

On 18/07/16 21:31, Lapprich, Harold via RT wrote:
> JJK,
>
> Thanks for the quick response, it is really appreciated. Can I ask where you picked up the syntax for this command line (familiar with the various shells and /dev/null but couldn't put this together)?
this is off-topic for this list, but I cannot email you directly. You 
could try reading up at
   http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html

or any other hit that comes up when searching for "linux shell stderr 
redirect"

HTH,

JJK

> -----Original Message-----
> From: Jan Just Keijser via RT [mailto:rt at openssl.org]
> Sent: Monday, July 18, 2016 2:26 PM
> To: Lapprich, Harold (GE Aviation, US)
> Cc: openssl-dev at openssl.org
> Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
>
> Hi,
>
> On 18/07/16 18:39, Lapprich, Harold via RT wrote:
>> To Whom It May Concern,
>>
>> openssl version -a:
>>
>>               OpenSSL 1.0.2a 19 Mar 2015
>>
>> built on: reproducible build, date unspecified
>>
>> platform: linux-ppc
>>
>> options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx)
>>
>> compiler:
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
>> r/bin/ccache
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
>> r/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC
>> -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2
>> -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
>> -DAES_ASM -DVPAES_ASM
>>
>> OPENSSLDIR: "/etc/ssl"
>>
>>
>>
>>                   OS Name, Version, Hardware platform:
>>
>> uname -a
>>
>> Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT
>> 2016 ppc GNU/Linux
>>
>>
>>
>>
>> Using 'openssl' in a Linux design and since it is a command line application it is always outputting content to the screen, for example:
>>
>>
>> openssl req -new -x509 -nodes -days 365 -subj
>> "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT"
>> -keyout start -out start
>>
>> Generating a 2048 bit RSA private key
>>
>> ......................................................................
>> ...................+++
>>
>> .............+++
>>
>> writing new private key to 'start'
>>
>> -----
>>
>>
>> Trying to find a way to prevent the output being output to 'stdout' but have not found a parameter (can redirect to a file but  the .....+ characters are still written to the console).
>>
>>
>> There either has to be a missed parameter or bug exist?
>>
> This is not a bug or lacking feature.
> The ....+ characters are written to stderr, so if you use
>     openssl .....    > stdout 2> stderr
> the characters disappear (into the file 'stderr'; use '2> /dev/null' to send then straight to bit-heaven).  This depends slightly on the shell you use, BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax applies.
>
> HTH,
>
> JJK
>
>
> --
> Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617&d=CwIDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg&m=hC-ePxGkl2IKC2iYTHYFk1qfc32xU_KzR5R3duyHaIM&s=G81nAuvPiu8kBUwgddPaVgh_UkoNVeOvf7Q4veAdNVo&e=
> Please log in as guest with password guest if prompted
>
>


From rt at openssl.org  Tue Jul 19 18:34:43 2016
From: rt at openssl.org (Jan Just Keijser via RT)
Date: Tue, 19 Jul 2016 18:34:43 +0000
Subject: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
In-Reply-To: <0ec7bd58-3c5b-29a6-2c60-9efced31744f@nikhef.nl>
References: <RT-Ticket-4617@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E03D9@CINMBCNA09.e2k.ad.ge.com>
 <rt-4.0.19-19821-1468859978-1229.4617-21-0@openssl.org>
 <48922eba-0449-b64b-5a92-665c48bad27c@nikhef.nl>
 <rt-4.0.19-19822-1468866365-1905.4617-6-0@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E04DF@CINMBCNA09.e2k.ad.ge.com>
 <rt-4.0.19-19821-1468870278-959.4617-6-0@openssl.org>
 <0ec7bd58-3c5b-29a6-2c60-9efced31744f@nikhef.nl>
Message-ID: <rt-4.0.19-17766-1468953283-932.4617-6-0@openssl.org>

Hi Harold,

On 18/07/16 21:31, Lapprich, Harold via RT wrote:
> JJK,
>
> Thanks for the quick response, it is really appreciated. Can I ask where you picked up the syntax for this command line (familiar with the various shells and /dev/null but couldn't put this together)?
this is off-topic for this list, but I cannot email you directly. You 
could try reading up at
   http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html

or any other hit that comes up when searching for "linux shell stderr 
redirect"

HTH,

JJK

> -----Original Message-----
> From: Jan Just Keijser via RT [mailto:rt at openssl.org]
> Sent: Monday, July 18, 2016 2:26 PM
> To: Lapprich, Harold (GE Aviation, US)
> Cc: openssl-dev at openssl.org
> Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
>
> Hi,
>
> On 18/07/16 18:39, Lapprich, Harold via RT wrote:
>> To Whom It May Concern,
>>
>> openssl version -a:
>>
>>               OpenSSL 1.0.2a 19 Mar 2015
>>
>> built on: reproducible build, date unspecified
>>
>> platform: linux-ppc
>>
>> options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx)
>>
>> compiler:
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
>> r/bin/ccache
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
>> r/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC
>> -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2
>> -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
>> -DAES_ASM -DVPAES_ASM
>>
>> OPENSSLDIR: "/etc/ssl"
>>
>>
>>
>>                   OS Name, Version, Hardware platform:
>>
>> uname -a
>>
>> Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT
>> 2016 ppc GNU/Linux
>>
>>
>>
>>
>> Using 'openssl' in a Linux design and since it is a command line application it is always outputting content to the screen, for example:
>>
>>
>> openssl req -new -x509 -nodes -days 365 -subj
>> "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT"
>> -keyout start -out start
>>
>> Generating a 2048 bit RSA private key
>>
>> ......................................................................
>> ...................+++
>>
>> .............+++
>>
>> writing new private key to 'start'
>>
>> -----
>>
>>
>> Trying to find a way to prevent the output being output to 'stdout' but have not found a parameter (can redirect to a file but  the .....+ characters are still written to the console).
>>
>>
>> There either has to be a missed parameter or bug exist?
>>
> This is not a bug or lacking feature.
> The ....+ characters are written to stderr, so if you use
>     openssl .....    > stdout 2> stderr
> the characters disappear (into the file 'stderr'; use '2> /dev/null' to send then straight to bit-heaven).  This depends slightly on the shell you use, BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax applies.
>
> HTH,
>
> JJK
>
>
> --
> Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617&d=CwIDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg&m=hC-ePxGkl2IKC2iYTHYFk1qfc32xU_KzR5R3duyHaIM&s=G81nAuvPiu8kBUwgddPaVgh_UkoNVeOvf7Q4veAdNVo&e=
> Please log in as guest with password guest if prompted
>
>


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4617
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 18:36:17 2016
From: rt at openssl.org (Lapprich, Harold via RT)
Date: Tue, 19 Jul 2016 18:36:17 +0000
Subject: [openssl-dev]  [openssl.org #4617] openssl Issue/Bug
In-Reply-To: <A53318AF49A84048959FE3BBF37B4DB95E26C7@CINMBCNA09.e2k.ad.ge.com>
References: <RT-Ticket-4617@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E03D9@CINMBCNA09.e2k.ad.ge.com>
 <rt-4.0.19-19821-1468859978-1229.4617-21-0@openssl.org>
 <48922eba-0449-b64b-5a92-665c48bad27c@nikhef.nl>
 <rt-4.0.19-19822-1468866365-1905.4617-6-0@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E04DF@CINMBCNA09.e2k.ad.ge.com>
 <rt-4.0.19-19821-1468870278-959.4617-6-0@openssl.org>
 <0ec7bd58-3c5b-29a6-2c60-9efced31744f@nikhef.nl>
 <rt-4.0.19-17766-1468953283-932.4617-6-0@openssl.org>
 <A53318AF49A84048959FE3BBF37B4DB95E26C7@CINMBCNA09.e2k.ad.ge.com>
Message-ID: <rt-4.0.19-17767-1468953377-1788.4617-6-0@openssl.org>

Thanks!

-----Original Message-----
From: Jan Just Keijser via RT [mailto:rt at openssl.org] 
Sent: Tuesday, July 19, 2016 2:35 PM
To: Lapprich, Harold (GE Aviation, US)
Cc: openssl-dev at openssl.org
Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug

Hi Harold,

On 18/07/16 21:31, Lapprich, Harold via RT wrote:
> JJK,
>
> Thanks for the quick response, it is really appreciated. Can I ask where you picked up the syntax for this command line (familiar with the various shells and /dev/null but couldn't put this together)?
this is off-topic for this list, but I cannot email you directly. You could try reading up at
   https://urldefense.proofpoint.com/v2/url?u=http-3A__tldp.org_HOWTO_Bash-2DProg-2DIntro-2DHOWTO-2D3.html&d=CwIDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg&m=MQLfDlYo7OMhseYkTLlCMQbmsjTa3oYqZ9VxCNa6TKs&s=CTpRJ8DNhRCKHc4VF3OhqAJu7asgyZYRD-fD_MgQIIs&e= 

or any other hit that comes up when searching for "linux shell stderr redirect"

HTH,

JJK

> -----Original Message-----
> From: Jan Just Keijser via RT [mailto:rt at openssl.org]
> Sent: Monday, July 18, 2016 2:26 PM
> To: Lapprich, Harold (GE Aviation, US)
> Cc: openssl-dev at openssl.org
> Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
>
> Hi,
>
> On 18/07/16 18:39, Lapprich, Harold via RT wrote:
>> To Whom It May Concern,
>>
>> openssl version -a:
>>
>>               OpenSSL 1.0.2a 19 Mar 2015
>>
>> built on: reproducible build, date unspecified
>>
>> platform: linux-ppc
>>
>> options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) 
>> blowfish(idx)
>>
>> compiler:
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/u
>> s
>> r/bin/ccache
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/u
>> s r/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC 
>> -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE 
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2 
>> -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
>> -DAES_ASM -DVPAES_ASM
>>
>> OPENSSLDIR: "/etc/ssl"
>>
>>
>>
>>                   OS Name, Version, Hardware platform:
>>
>> uname -a
>>
>> Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT
>> 2016 ppc GNU/Linux
>>
>>
>>
>>
>> Using 'openssl' in a Linux design and since it is a command line application it is always outputting content to the screen, for example:
>>
>>
>> openssl req -new -x509 -nodes -days 365 -subj 
>> "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT"
>> -keyout start -out start
>>
>> Generating a 2048 bit RSA private key
>>
>> ......................................................................
>> ...................+++
>>
>> .............+++
>>
>> writing new private key to 'start'
>>
>> -----
>>
>>
>> Trying to find a way to prevent the output being output to 'stdout' but have not found a parameter (can redirect to a file but  the .....+ characters are still written to the console).
>>
>>
>> There either has to be a missed parameter or bug exist?
>>
> This is not a bug or lacking feature.
> The ....+ characters are written to stderr, so if you use
>     openssl .....    > stdout 2> stderr
> the characters disappear (into the file 'stderr'; use '2> /dev/null' to send then straight to bit-heaven).  This depends slightly on the shell you use, BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax applies.
>
> HTH,
>
> JJK
>
>
> --
> Ticket here: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Tic
> ket_Display.html-3Fid-3D4617&d=CwIDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_Ri
> V3wUrLrDQYWSI&r=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg&m=hC-ePxGk
> l2IKC2iYTHYFk1qfc32xU_KzR5R3duyHaIM&s=G81nAuvPiu8kBUwgddPaVgh_UkoNVeOv
> f7Q4veAdNVo&e= Please log in as guest with password guest if prompted
>
>


--
Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617&d=CwIDaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg&m=MQLfDlYo7OMhseYkTLlCMQbmsjTa3oYqZ9VxCNa6TKs&s=hGWJ1xajmyidWsrr6QU3K8QnvOLwDwiowB44Kltrd1E&e=
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4617
Please log in as guest with password guest if prompted


From anirudhp at avaya.com  Tue Jul 19 20:00:15 2016
From: anirudhp at avaya.com (Patel, Anirudh (Anirudh))
Date: Tue, 19 Jul 2016 20:00:15 +0000
Subject: [openssl-dev] openssl.org #4615 Cache utility behaving strange
 with X509_LOOKUP_add_dir
In-Reply-To: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21ED8@AZ-FFEXMB01.global.avaya.com>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E37@AZ-FFEXMB01.global.avaya.com>
 <3f6649157a1c4fc888d5d28b4de472da@usma1ex-dag1mb1.msg.corp.akamai.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21E65@AZ-FFEXMB01.global.avaya.com>
 <CAD38tB3FrZF45hpBR6ZJZ7BsXrzL3Hj2Qnom+AzjceEh_jCazA@mail.gmail.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21EA3@AZ-FFEXMB01.global.avaya.com>
 <CAD38tB14Gm76=Ec2TZit1KH2dgdETiwDm6=DG9agX5P3bmbwHA@mail.gmail.com>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC21ED8@AZ-FFEXMB01.global.avaya.com>
Message-ID: <B11D088B738A4B4B9066D5CA97E2D2FB3AC221C4@AZ-FFEXMB01.global.avaya.com>

Guys,

I will make things more simpler based on all the explanations that you have given.

A $hash.r0 CRL file has been loaded in the internal store since it was unique (new name) as suggested by you. Currently, this file was present on disk under the CRL directory.
Now, this CRL file has been purged from the CRL directory (now the directory is empty with no CRL files).
As suggested by you, I got a new refreshed CRL file (which has a new list of certificates that have been revoked) from the same issuer. I save this file on disk under the CRL directory with extension same as before i.e $hash.r0. Problem persists again, that openssl does not do a lookup for this newly placed CRL file but only refers to the old CRL file of the issuer from its cache as you have mentioned below:
?Once that file is loaded, it's not been loaded from disk again (as implied by the 'caches'), also not when it changes.?

How to make this new CRL file count which is just a replacement of the old CRL file belonging to the same issuer. We cannot every time reload the store so that the cache refreshes for every new (refreshed/replaced) CRL file.

So, another question linked to this is: Is there any way to clear the store cache every time before the validation begins (so that it may look for disk files and load them since they will always be unique)? Is there any API which does that?

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Patel, Anirudh (Anirudh)
Sent: Tuesday, July 19, 2016 2:42 PM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange with X509_LOOKUP_add_dir

Fine and thanks for all the explanation.

First let me give my scenario again and then I will come to Mischa?s point.

I got your point Richard but, my scenario is slightly different. What you are considering is that both $hash{sub_ca}.r0 and $hash{sub_ca}.r1 are already present in the CRL directory and has been loaded up. There might be issues with this as you mentioned below.



My case is slightly different:

1. At time T1, CRL file $hash{sub_ca}.r0 is present in the CRL directory. Store is loaded up with it and maybe as you said if, no other object with the same hash is already there this will be put in the internal store.

2. Now I get an incoming client connection and for which this CRL file is looked up and everything is fine.

3. At time T2, I removed this CRL file $hash{sub_ca}.r0 from the CRL directory (but remember it is in the internal store/cache).

4. Now I get the same incoming connection from the client as above for which openssl is currently doing a lookup and gives no error as the corresponding CRL file $hash{sub_ca}.r0 was there in the internal

    store/cache. I was expecting an error since I removed the CRL file but I did not and that is how I understood that openssl is keeping the file in the cache.

5. Above client has now been revoked by sub_ca which generated a new CRL.

6. At time T3, I placed the new CRL file as $hash{sub_ca}.r1 under the CRL directory and it is the only one since I have deleted the old one $hash{sub_ca}.r0 from the directory.

7. Again the same client tries to connect and passes away which now becomes a security concern. As per the statement mentioned on the man page, the lookup should have found and considered the new CRL (.r1)

   and not the one in the cache since its sequence number is old.

Now, from what you have just said let me ask you this:
I have .r0 file which has been loaded up in the internal store since, that issuer was not already present. Right, this is what you are saying: ?if the file is new or if that issuer is not already in the store it, it will be loaded?.
Suppose, I remove this file from the disk (.r0) and place a replacement of it as you said (this replaced CRL file has been recently published which has a list of new certificates that have been revoked). I place this file under the CRL directory as .r0 again, but openssl will now again not lookup for this file as the same issuer name file was already present in its internal store/cache. This is a replaced CRL file of an existing file CRL file but how to make it count. We need to start and stop the server again for loading up the store and refreshing the cache. This seems to be lot of work and inefficient.

Hope I have been able to made my point.

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Mischa Salle
Sent: Tuesday, July 19, 2016 2:28 PM
To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange with X509_LOOKUP_add_dir

Hi,
the point is that they are loaded when a new file appears, meaning, a file with a name not yet present. Once that file is loaded, it's not been loaded from disk again (as implied by the 'caches'), also not when it changes.
The .r1 files are rarely used (only for rekeying of the CA etc., as far as I remember), so normally you would get only replacements of existing files, meaning OpenSSL will get then from its cache.
Note that I don't like this behaviour, but I think it is as intended.
Mischa


On Tue, Jul 19, 2016 at 10:24 AM, Patel, Anirudh (Anirudh) <anirudhp at avaya.com<mailto:anirudhp at avaya.com>> wrote:
Man page for X509_LOOKUP_hash_dir states something different though:


X509_LOOKUP_hash_dir is a more advanced method, which loads certificates and CRLs on demand, and caches them in memory once they are loaded. As of OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer CRLs are as soon as they appear in the directory

When checking for new CRLs once one CRL for given hash value is loaded, hash_dir lookup method checks only for certificates with sequence number greater than that of the already cached CRL.

a)      If you look at my scenario, firstly I did not had any CRL files under the CRL directory which has been loaded in the store when my server starts. For the incoming chain as ID/Sub CA/Root CA verify_callback is invoked which gives 3 errors X509_V_ERR_UNABLE_TO_GET_CRL one for each certificate and then follows with further validation.

b)      Then, when I placed the respective CRL files under the directory and I get the same incoming connection (chain: ID/Sub CA/Root CA) openssl verify_callback stops complaining about CRL files not found for the certs. Please note that I did not stop/start the server to load the store with CRL directory again. As stated in the man page, openssl rightly did a lookup and found new CRL files during the handshake.

c)       The problem is when a new CRL file for one the above issuer is placed under the CRL directory (with an incremented sequence number .rN) openssl is not looking at the newer CRL file but only considering the ones in the cache.

Let me know if the manual page description meant something different.

Thanks.

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>] On Behalf Of Mischa Salle
Sent: Tuesday, July 19, 2016 1:27 PM

To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
Subject: Re: [openssl-dev] openssl.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.org&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=NM3FtBB4wlVT4uq5ccJIq8GhBUYhH_xiQVBkJ1QVX_s&s=7-gGMTBKo65sNA3NAdCAT48WVK9-kiJa_d54QmGxVmM&e=> #4615 Cache utility behaving strange with X509_LOOKUP_add_dir

Hi Anirudh,
this is as far as I know a very old issue (at least since 2002 or so). Basically a server needs to restart periodically in order to pick up changed CRLs. There are some workarounds, like forcibly reloading all the CRLs periodically, even those already in the store.
Mischa Salle

On Tue, Jul 19, 2016 at 9:32 AM, Patel, Anirudh (Anirudh) <anirudhp at avaya.com<mailto:anirudhp at avaya.com>> wrote:
It is not re-checking the files (new CRL for the same issuer) in the CRL directory
IssuerHash_YYYY.r0 (old crl for sub-ca)
IssuerHash_YYYY.r1 (new crl for sub-ca) ---> not looked up for an incoming client connection
IssuerXXXX.r0 (old crl for root ca)

I have mentioned the complete scenario in the ticket#4615

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>] On Behalf Of Salz, Rich
Sent: Tuesday, July 19, 2016 12:55 PM
To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
Subject: Re: [openssl-dev] openssl.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.org&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=ultotvw_l8QsxQ1Zf_5rbTjOo-JG_iZbExIaV7qPLOs&e=> #4615 Cache utility behaving strange with X509_LOOKUP_add_dir


> I have earlier raised an issue on how openssl is not looking up for newer CRLs in each lookup. The only CRL files it is taking into consideration are the ones present in the cache.

> Could you please provide some inputs on this as I am blocked on the implementation front.

You mean it's not fetching CRL's over the network?  Or re-checking the files?

--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44&s=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs&e=
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=F3JmB5AFiuX4fyQGRse7p8_yKB86uPYSSBlCWfApGfM&e=>

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=NM3FtBB4wlVT4uq5ccJIq8GhBUYhH_xiQVBkJ1QVX_s&s=gu_2BoTnFPbjE2U9cAYiFYofV66JRKrPpbhxdz3Nbmg&e=>



--
Van Boshuizenstraat 443
1082 AR Amsterdam
The Netherlands
Tel. (+31/0)20-4043782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/35e09f4a/attachment-0001.html>

From rsalz at akamai.com  Tue Jul 19 22:17:39 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 19 Jul 2016 22:17:39 +0000
Subject: [openssl-dev] doc/crypto/BIO_set_callback.pod still not fixed
	in	the master
In-Reply-To: <D3B3D621.2F5EF%uri@ll.mit.edu>
References: <D3B3D621.2F5EF%uri@ll.mit.edu>
Message-ID: <2c7d75e96c4048faa6d209c8b1557bca@usma1ex-dag1mb1.msg.corp.akamai.com>

This was also reported as https://github.com/openssl/openssl/pull/1312 and fixed with commit 2a5f907 moments ago.



From rt at openssl.org  Tue Jul 19 22:23:56 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 19 Jul 2016 22:23:56 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange
	with X509_LOOKUP_add_dir
In-Reply-To: <rt-4.0.19-17766-1468918031-309.4615-6-0@openssl.org>
References: <RT-Ticket-4615@openssl.org>
 <CAKUCFqd0xa14SvQBJQH7gRbJq8sRVgz+2+TVFUceyaAHRGE9WQ@mail.gmail.com>
 <rt-4.0.19-17766-1468917078-1020.4615-6-0@openssl.org>
 <rt-4.0.19-17766-1468918031-309.4615-6-0@openssl.org>
Message-ID: <rt-4.0.19-17534-1468967036-1487.4615-6-0@openssl.org>

On Tue Jul 19 08:47:11 2016, levitte wrote:
> My answer was incorrect...
>
> What happens when trying to find a CRL is that get_cert_by_subject (in
> crypto/x509/by_dir.c) gets called, and it will try to load every file
> it finds
> (so both $hash{sub_ca}.r0 and $hash{sub_ca}.r1). However, when trying
> to
> storing them in the internal store, it will only do so if no other
> object with
> the same hash is already there. Hence, $hash{sub_ca}.r1 will
> essentially be
> ignored.
>
> Either way, if both CRLs (with the same issuer name) were stored
> internally, it
> would still be a good question which one would actually be used. How
> would that
> be determined.
>

If there are multiple CRLs with the appropriate scope then the first one where
the current time falls between lastUpdate and nextUpdate is used.

It is possible to dynamically update CRLs but currently only the time criteria
is used. So if the first one fails the time test the next is used. This isn't
ideal and something relying on the most recent or the highest CRL number would
be preferable.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 22:28:08 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 19 Jul 2016 22:28:08 +0000
Subject: [openssl-dev] [openssl.org #4591] asynctest: double free or
	corruption on hppa
In-Reply-To: <rt-4.0.19-17766-1468945342-1093.4591-6-0@openssl.org>
References: <RT-Ticket-4591@openssl.org> <20160626144349.GA7315@roeckx.be>
 <rt-4.0.19-21188-1466952246-1487.4591-21-0@openssl.org>
 <5770F716.9000109@openssl.org>
 <rt-4.0.19-21189-1467021081-1436.4591-6-0@openssl.org>
 <rt-4.0.19-17766-1468937560-736.4591-6-0@openssl.org>
 <20160719162217.GA27822@roeckx.be>
 <rt-4.0.19-17766-1468945342-1093.4591-6-0@openssl.org>
Message-ID: <rt-4.0.19-17767-1468967288-592.4591-6-0@openssl.org>

On Tue Jul 19 16:22:22 2016, kurt at roeckx.be wrote:
> On Tue, Jul 19, 2016 at 02:12:41PM +0000, Matt Caswell via RT wrote:
> >
> > Is this still an issue? And if so are you able to provide a backtrace?
>
> This might be a combination of kernel, glibc and gcc bugs, some of
> which might have been fixed. In any case, I don't think it's an
> openssl problem.

Ok - closing this ticket then.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4591
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 19 23:20:43 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 19 Jul 2016 23:20:43 +0000
Subject: [openssl-dev] [openssl.org #4600] Core dump when using
	-keymatexport and receiving a handshake alert
In-Reply-To: <5339913.Psn8H2xh9u@pintsize.usersys.redhat.com>
References: <RT-Ticket-4600@openssl.org>
 <5339913.Psn8H2xh9u@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-17767-1468970443-1267.4600-6-0@openssl.org>

Fixed now, thanks for the report.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4600
Please log in as guest with password guest if prompted


From steve at openssl.org  Tue Jul 19 23:35:13 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 19 Jul 2016 23:35:13 +0000
Subject: [openssl-dev] pkcs12 settings,
 Was: Re: [openssl.org #4588] pkcs12 -info doesn't handle PKCS#12
 files with PKCS#5 v2.0 PBE
In-Reply-To: <1541032.77INFnC1dm@pintsize.usersys.redhat.com>
References: <RT-Ticket-4588@openssl.org>
 <1992022.TCv6Aigntu@pintsize.usersys.redhat.com>
 <rt-4.0.19-17766-1468930053-68.4588-6-0@openssl.org>
 <1541032.77INFnC1dm@pintsize.usersys.redhat.com>
Message-ID: <20160719233513.GA15403@openssl.org>

On Tue, Jul 19, 2016, Hubert Kario wrote:

> I have few questions now though:
> 
> I've noticed that 1.0.2 uses sha1 hmac for the PRF while the master
> uses sha256
> 
> is there a way to set this?
> 

Not currently no (at least not from the command line, maybe by delving
into the pkcs12 internals). It's determined by the encryption algorithm (if it has a
preference: most don't) or the value is hard coded in p5_pbev2.c

> also, is there a way to report the MAC algorithm used over the whole
> file (the one set using -macalg)
> 

Not from the command line currently. The PKCS12_get0_mac() function can be
used to retrieve the X509_ALGOR structure corresponding to the MAC though.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From anirudhp at avaya.com  Wed Jul 20 07:27:47 2016
From: anirudhp at avaya.com (Patel, Anirudh (Anirudh))
Date: Wed, 20 Jul 2016 07:27:47 +0000
Subject: [openssl-dev] Clear X509 OBJECT cache
Message-ID: <B11D088B738A4B4B9066D5CA97E2D2FB3AC240AF@AZ-FFEXMB01.global.avaya.com>

Hi,

This is related to the X509 store cache (had a similar ticket openssl.org #4615 which I guess has already become stale). But, I believe that the documentation regarding X509_LOOKUP_hash_dir is not at all clear and is quite misleading:
>From the manual page: X509_LOOKUP_hash_dir<https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html>
"X509_LOOKUP_hash_dir  is a more advanced method, which loads certificates and CRLs on demand, and caches them in memory once they are loaded. As of OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer CRLs are as soon as they appear in the directory. When checking for new CRLs once one CRL for given hash value is loaded, hash_dir lookup method checks only for certificates with sequence number greater than that of the already cached CRL" - This certainly not happens. It should have stated that only unique file names will be loaded for once from the disk and the new ones for the same issuer will not be looked up even if you change the sequence number. This is a big problem and a difficult one to address, once for a unique issuer name a CRL file is loaded from the disk and stored in the cache, no matter if you replace the old CRL file with a new one, keeping the naming convention to whatever $hash.r0 or$hash.r1 this is never going to be looked up and loaded in the cache since the issuer name is already present in the cache. I guess this should be fixed.

Quoting one of the explanations that I got from you guys:
"The point is that they are loaded when a new file appears, meaning, a file with a name not yet present. Once that file is loaded, it's not been loaded from disk again (as implied by the 'caches'), also not when it changes"

Just to solve my problem:
Is there any way to clear the store cache every time before openssl kicks off with the validation process (invoke X509_verify_cert and the results verify_callback). I would want to clear the cache so that during every (current) lookup at the time of handshake - CRL files present on the disk are referenced and are loaded in the cache (since we cleared it earlier, thus the file name will be unique/new)? Is there any API which clears the cache?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160720/369df295/attachment.html>

From hkario at redhat.com  Wed Jul 20 12:25:42 2016
From: hkario at redhat.com (Hubert Kario)
Date: Wed, 20 Jul 2016 14:25:42 +0200
Subject: [openssl-dev] pkcs12 settings,
	Was: Re: [openssl.org #4588] pkcs12 -info doesn't handle PKCS#12
	files with PKCS#5 v2.0 PBE
In-Reply-To: <20160719233513.GA15403@openssl.org>
References: <RT-Ticket-4588@openssl.org>
 <1541032.77INFnC1dm@pintsize.usersys.redhat.com>
 <20160719233513.GA15403@openssl.org>
Message-ID: <1800252.LBbZ4OdRWX@pintsize.usersys.redhat.com>

On Tuesday, 19 July 2016 23:35:13 CEST Dr. Stephen Henson wrote:
> On Tue, Jul 19, 2016, Hubert Kario wrote:
> > I have few questions now though:
> > 
> > I've noticed that 1.0.2 uses sha1 hmac for the PRF while the master
> > uses sha256
> > 
> > is there a way to set this?
> 
> Not currently no (at least not from the command line, maybe by delving
> into the pkcs12 internals). It's determined by the encryption algorithm (if
> it has a preference: most don't) or the value is hard coded in p5_pbev2.c

yes, I don't see a simple way to do that, thanks anyway

> > also, is there a way to report the MAC algorithm used over the whole
> > file (the one set using -macalg)
> 
> Not from the command line currently. The PKCS12_get0_mac() function can be
> used to retrieve the X509_ALGOR structure corresponding to the MAC though.

something like this?
https://github.com/openssl/openssl/pull/1334

the small problem is that this prints:
MAC algorithm: sha1, <unsupported parameters>

I'm not sure how correct is that (haven't read the PKCS#12 standard)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160720/3205137e/attachment-0001.sig>

From steve at openssl.org  Wed Jul 20 14:07:37 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 20 Jul 2016 14:07:37 +0000
Subject: [openssl-dev] Clear X509 OBJECT cache
In-Reply-To: <B11D088B738A4B4B9066D5CA97E2D2FB3AC240AF@AZ-FFEXMB01.global.avaya.com>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC240AF@AZ-FFEXMB01.global.avaya.com>
Message-ID: <20160720140737.GA30285@openssl.org>

On Wed, Jul 20, 2016, Patel, Anirudh (Anirudh) wrote:

> "X509_LOOKUP_hash_dir  is a more advanced method, which loads certificates
> and CRLs on demand, and caches them in memory once they are loaded. As of
> OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer
> CRLs are as soon as they appear in the directory. When checking for new CRLs
> once one CRL for given hash value is loaded, hash_dir lookup method checks
> only for certificates with sequence number greater than that of the already
> cached CRL" - This certainly not happens. It should have stated that only
> unique file names will be loaded for once from the disk and the new ones for
> the same issuer will not be looked up even if you change the sequence
> number.
> 

They should be looked up: if they aren't this is a bug.

The problem is that unless the current time exceeds the nextUpdate field of
the new CRL it wont be used: it will use the first one where the current time
is between lastUpdate and nextUpdate.

When you added a new CRL was it just "newer" (i.e. thisUpdate later than the
current one) or had the current time exceeded nextUpdate? If the latter and
the new CRL wasn't used that's a bug which should be fixed.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Wed Jul 20 14:09:14 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 20 Jul 2016 14:09:14 +0000
Subject: [openssl-dev] Clear X509 OBJECT cache
In-Reply-To: <20160720140737.GA30285@openssl.org>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC240AF@AZ-FFEXMB01.global.avaya.com>
 <20160720140737.GA30285@openssl.org>
Message-ID: <20160720140914.GB30285@openssl.org>

On Wed, Jul 20, 2016, Dr. Stephen Henson wrote:

> On Wed, Jul 20, 2016, Patel, Anirudh (Anirudh) wrote:
> 
> > "X509_LOOKUP_hash_dir  is a more advanced method, which loads certificates
> > and CRLs on demand, and caches them in memory once they are loaded. As of
> > OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer
> > CRLs are as soon as they appear in the directory. When checking for new CRLs
> > once one CRL for given hash value is loaded, hash_dir lookup method checks
> > only for certificates with sequence number greater than that of the already
> > cached CRL" - This certainly not happens. It should have stated that only
> > unique file names will be loaded for once from the disk and the new ones for
> > the same issuer will not be looked up even if you change the sequence
> > number.
> > 
> 
> They should be looked up: if they aren't this is a bug.
> 
> The problem is that unless the current time exceeds the nextUpdate field of
> the new CRL it wont be used: it will use the first one where the current time
> is between lastUpdate and nextUpdate.
> 
> When you added a new CRL was it just "newer" (i.e. thisUpdate later than the
> the new CRL wasn't used that's a bug which should be fixed.
> 

Argh... I mean "lastUpdate" not "lastUpdate".

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Wed Jul 20 14:11:53 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 20 Jul 2016 14:11:53 +0000
Subject: [openssl-dev] Clear X509 OBJECT cache
In-Reply-To: <20160720140914.GB30285@openssl.org>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC240AF@AZ-FFEXMB01.global.avaya.com>
 <20160720140737.GA30285@openssl.org>
 <20160720140914.GB30285@openssl.org>
Message-ID: <20160720141153.GA30647@openssl.org>

On Wed, Jul 20, 2016, Dr. Stephen Henson wrote:

> On Wed, Jul 20, 2016, Dr. Stephen Henson wrote:
> 
> > On Wed, Jul 20, 2016, Patel, Anirudh (Anirudh) wrote:
> > 
> > > "X509_LOOKUP_hash_dir  is a more advanced method, which loads certificates
> > > and CRLs on demand, and caches them in memory once they are loaded. As of
> > > OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer
> > > CRLs are as soon as they appear in the directory. When checking for new CRLs
> > > once one CRL for given hash value is loaded, hash_dir lookup method checks
> > > only for certificates with sequence number greater than that of the already
> > > cached CRL" - This certainly not happens. It should have stated that only
> > > unique file names will be loaded for once from the disk and the new ones for
> > > the same issuer will not be looked up even if you change the sequence
> > > number.
> > > 
> > 
> > They should be looked up: if they aren't this is a bug.
> > 
> > The problem is that unless the current time exceeds the nextUpdate field of
> > the new CRL it wont be used: it will use the first one where the current time
> > is between lastUpdate and nextUpdate.
> > 
> > When you added a new CRL was it just "newer" (i.e. thisUpdate later than the
> > the new CRL wasn't used that's a bug which should be fixed.
> > 
> 
> Argh... I mean "lastUpdate" not "lastUpdate".
> 

Oops.. ;-)

Err... I'll try that again. I meant "lastUpdate" not "thisUpdate".

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From doctor at doctor.nl2k.ab.ca  Wed Jul 20 07:23:07 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 20 Jul 2016 01:23:07 -0600
Subject: [openssl-dev] openssl-SNAP-20160720
Message-ID: <20160720072307.GA87118@doctor.nl2k.ab.ca>

./libcrypto.so: undefined reference to `RUN_ONCE'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1  

Please fix
-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Language is the source of misunderstandings.  -Antoine de Saint-Exupery  

From levitte at openssl.org  Wed Jul 20 14:43:18 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 20 Jul 2016 16:43:18 +0200 (CEST)
Subject: [openssl-dev] openssl-SNAP-20160720
In-Reply-To: <20160720072307.GA87118@doctor.nl2k.ab.ca>
References: <20160720072307.GA87118@doctor.nl2k.ab.ca>
Message-ID: <20160720.164318.377991043424255567.levitte@openssl.org>

In message <20160720072307.GA87118 at doctor.nl2k.ab.ca> on Wed, 20 Jul 2016 01:23:07 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:

doctor> ./libcrypto.so: undefined reference to `RUN_ONCE'
doctor> cc: error: linker command failed with exit code 1 (use -v to see invocation)
doctor> *** Error code 1  
doctor> 
doctor> Please fix

Already done, you will notice in tomorrow's snapshot.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Wed Jul 20 15:11:24 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 20 Jul 2016 15:11:24 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-20844-1468245862-1610.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467926949-1421.4602-7-0@openssl.org>
 <rt-4.0.19-1832-1467958101-1276.4602-7-0@openssl.org>
 <1468242505.32623.44.camel@physics.uu.se>
 <rt-4.0.19-20845-1468242512-1164.4602-6-0@openssl.org>
 <1468244056.4158.241.camel@infradead.org>
 <rt-4.0.19-20844-1468245862-1610.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-17534-1469027484-648.4602-6-0@openssl.org>

On Mon Jul 11 14:04:22 2016, dwmw2 at infradead.org wrote:
> I was using store.get_issuer() in OpenConnect too, because I need to
> manually build the trust chain to include it on the wire ? because
> even today the server might *still* suffer RT#1942 and fail to trust
> our client cert unless we help it by providing the *right* chain.

Is this still true with OpenSSL 1.1? If so, please file a report.

> I've worked around the lack of access to get_issuer() by doing a dummy
> call to X509_verify_cert(), throwing away its result and then hoping
> that we have something useful in store.chain (which we *can* still
> access). That seems to work but I'm not stunningly happy with it; if
> we
> can have an accessor I'd much rather go back to doing it the old way.
>
> http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> (in workaround_openssl_certchain_bug() in the hunk around line 1306)

https://github.com/openssl/openssl/pull/1294 currently provides a setter for
get_issuer in X509_STORE.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed Jul 20 15:14:08 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 20 Jul 2016 15:14:08 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
 <1468236301.32623.23.camel@physics.uu.se>
 <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1469027648-1476.4602-6-0@openssl.org>

On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
> I guess having a more restrictive accessor that only sets the
> EXFLAG_PROXY bit could work. I suggested the more general solution of
> having set/clear accessors for arbitrary flags since it was - well
> more
> general.

So let me ask this in a different manner, does OpenSSL 1.1 still not set the
EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
worth a bug report of its own.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From janjust at nikhef.nl  Wed Jul 20 16:57:48 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Wed, 20 Jul 2016 18:57:48 +0200
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-17766-1469027648-1476.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be> <1468236301.32623.23.camel@physics.uu.se>
 <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
 <rt-4.0.19-17766-1469027648-1476.4602-6-0@openssl.org>
Message-ID: <a01960ce-e807-95de-ffb4-2ee7e2c76da1@nikhef.nl>

Hi Richard,

On 20/07/16 17:14, Richard Levitte via RT wrote:
> On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
>> I guess having a more restrictive accessor that only sets the
>> EXFLAG_PROXY bit could work. I suggested the more general solution of
>> having set/clear accessors for arbitrary flags since it was - well
>> more
>> general.
> So let me ask this in a different manner, does OpenSSL 1.1 still not set the
> EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
> worth a bug report of its own.
>
this ties into my earlier question and example of verifying proxy 
certificates. What if I want to explicitly *set* the EXFLAG_PROXY for a 
stack of certificates? how would I do that? how can I ensure that 
OpenSSL 1.1 will automagically trigger this flag for me? Is there a 
'get_*' function to determine which flags were set during certificate 
verification?

thanks for any pointers or advice,

JJK / Jan Just Keijser



From rt at openssl.org  Wed Jul 20 16:58:20 2016
From: rt at openssl.org (Jan Just Keijser via RT)
Date: Wed, 20 Jul 2016 16:58:20 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <a01960ce-e807-95de-ffb4-2ee7e2c76da1@nikhef.nl>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
 <1468236301.32623.23.camel@physics.uu.se>
 <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
 <rt-4.0.19-17766-1469027648-1476.4602-6-0@openssl.org>
 <a01960ce-e807-95de-ffb4-2ee7e2c76da1@nikhef.nl>
Message-ID: <rt-4.0.19-17534-1469033900-337.4602-6-0@openssl.org>

Hi Richard,

On 20/07/16 17:14, Richard Levitte via RT wrote:
> On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
>> I guess having a more restrictive accessor that only sets the
>> EXFLAG_PROXY bit could work. I suggested the more general solution of
>> having set/clear accessors for arbitrary flags since it was - well
>> more
>> general.
> So let me ask this in a different manner, does OpenSSL 1.1 still not set the
> EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
> worth a bug report of its own.
>
this ties into my earlier question and example of verifying proxy 
certificates. What if I want to explicitly *set* the EXFLAG_PROXY for a 
stack of certificates? how would I do that? how can I ensure that 
OpenSSL 1.1 will automagically trigger this flag for me? Is there a 
'get_*' function to determine which flags were set during certificate 
verification?

thanks for any pointers or advice,

JJK / Jan Just Keijser



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed Jul 20 17:10:53 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 20 Jul 2016 17:10:53 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-17534-1469033900-1170.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
 <1468236301.32623.23.camel@physics.uu.se>
 <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
 <rt-4.0.19-17766-1469027648-1476.4602-6-0@openssl.org>
 <a01960ce-e807-95de-ffb4-2ee7e2c76da1@nikhef.nl>
 <rt-4.0.19-17534-1469033900-1170.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-17534-1469034653-49.4602-6-0@openssl.org>

On Wed Jul 20 16:58:20 2016, janjust at nikhef.nl wrote:
> Hi Richard,
>
> On 20/07/16 17:14, Richard Levitte via RT wrote:
> > On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
> >> I guess having a more restrictive accessor that only sets the
> >> EXFLAG_PROXY bit could work. I suggested the more general solution
> >> of
> >> having set/clear accessors for arbitrary flags since it was - well
> >> more
> >> general.
> > So let me ask this in a different manner, does OpenSSL 1.1 still not
> > set the
> > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > That may be
> > worth a bug report of its own.
> >
> this ties into my earlier question and example of verifying proxy
> certificates. What if I want to explicitly *set* the EXFLAG_PROXY for
> a
> stack of certificates?

I assume you only want that flag set for actual proxy certs a no other. If you
simply want to make sure the certs in a stack are properly flagged by OpenSSL,
call X509_check_purpose for each of them.

> how would I do that? how can I ensure that
> OpenSSL 1.1 will automagically trigger this flag for me? Is there a
> 'get_*' function to determine which flags were set during certificate
> verification?
>
> thanks for any pointers or advice,

The function to retrieve the extension flags is X509_get_extension_flags(). You
call that for each X509*.
Incidently, this function calls X509_check_purpose to make sure the caches are
properly built up...

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From anirudhp at avaya.com  Wed Jul 20 18:04:12 2016
From: anirudhp at avaya.com (Patel, Anirudh (Anirudh))
Date: Wed, 20 Jul 2016 18:04:12 +0000
Subject: [openssl-dev] Clear X509 OBJECT cache
In-Reply-To: <20160720141153.GA30647@openssl.org>
References: <B11D088B738A4B4B9066D5CA97E2D2FB3AC240AF@AZ-FFEXMB01.global.avaya.com>
 <20160720140737.GA30285@openssl.org> <20160720140914.GB30285@openssl.org>
 <20160720141153.GA30647@openssl.org>
Message-ID: <B11D088B738A4B4B9066D5CA97E2D2FB3AC25BAD@AZ-FFEXMB01.global.avaya.com>

Thanks a lot for explaining this so clearly.

OLD CRL (present in cache): Last Update: Jul 18 11:42:52 2016 GMT
			      Next Update: Aug 17 11:42:52 2016 GMT
			      X509v3 CRL Number: 20480
Got an incoming connection when the current time was between the above (lastUpdate : current_time : nextUpdate) and thus this file got picked during the lookup, just like you explained:

> When you added a new CRL was it just "newer" (i.e. lastUpdate later than the current one)
Yes.
NEW CRL on disk: Last Update: Jul 18 12:24:39 2016 GMT
		   Next Update: Aug 17 12:24:39 2016 GMT
		  X509v3 CRL Number: 20481

Got an incoming connection when the current time is still between OLD CRL's (lastUpdate and nextUpdate) i.e current time has not exceeded OLD CRL's nextUpdate and thus the newer CRL file is never looked up(ignored).

You rightly said that we should have taken CRL Number into consideration during lookups.

So, now can you tell me how to go about it. I cannot restart my server to load the CRL files again. Is it possible for me to clear the cache before validation kicks off for every incoming connection? If yes, please tell me the API which can do this.

Thanks,
Anirudh

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Wednesday, July 20, 2016 7:42 PM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] Clear X509 OBJECT cache

On Wed, Jul 20, 2016, Dr. Stephen Henson wrote:

> On Wed, Jul 20, 2016, Dr. Stephen Henson wrote:
> 
> > On Wed, Jul 20, 2016, Patel, Anirudh (Anirudh) wrote:
> > 
> > > "X509_LOOKUP_hash_dir  is a more advanced method, which loads 
> > > certificates and CRLs on demand, and caches them in memory once 
> > > they are loaded. As of OpenSSL 1.0.0, it also checks for newer 
> > > CRLs upon each lookup, so that newer CRLs are as soon as they 
> > > appear in the directory. When checking for new CRLs once one CRL 
> > > for given hash value is loaded, hash_dir lookup method checks only 
> > > for certificates with sequence number greater than that of the 
> > > already cached CRL" - This certainly not happens. It should have 
> > > stated that only unique file names will be loaded for once from 
> > > the disk and the new ones for the same issuer will not be looked up even if you change the sequence number.
> > > 
> > 
> > They should be looked up: if they aren't this is a bug.
> > 
> > The problem is that unless the current time exceeds the nextUpdate 
> > field of the new CRL it wont be used: it will use the first one 
> > where the current time is between lastUpdate and nextUpdate.
> > 
> > When you added a new CRL was it just "newer" (i.e. thisUpdate later 
> > than the the new CRL wasn't used that's a bug which should be fixed.
> > 
> 
> Argh... I mean "lastUpdate" not "lastUpdate".
> 

Oops.. ;-)

Err... I'll try that again. I meant "lastUpdate" not "thisUpdate".

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=PFSfcnSGg1bGMDtJ40-ga01mSVP5ue8Pkfes0hfaw-E&s=_B-3I5EwxUCu1umKQkjmPAo0rDCElpGg0akAD6ecDcU&e=
--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=PFSfcnSGg1bGMDtJ40-ga01mSVP5ue8Pkfes0hfaw-E&s=e09sSwcDm-McZPDbgwFI6MlsKM9oiwB0pgLEhvlKvg4&e= 

From rt at openssl.org  Wed Jul 20 18:23:54 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 20 Jul 2016 18:23:54 +0000
Subject: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures
In-Reply-To: <rt-4.0.19-17767-1468950463-1357.4614-6-0@openssl.org>
References: <RT-Ticket-4614@openssl.org> <20160711162016.GA3255@roeckx.be>
 <rt-4.0.19-20845-1468254029-12.4614-21-0@openssl.org>
 <2b91a3576c824f4ebb0ea6d08af1ad18@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-20845-1468259286-472.4614-6-0@openssl.org>
 <20160719164107.GB27822@roeckx.be>
 <rt-4.0.19-17767-1468946473-620.4614-6-0@openssl.org>
 <rt-4.0.19-17767-1468950463-1357.4614-6-0@openssl.org>
Message-ID: <rt-4.0.19-17767-1469039034-466.4614-6-0@openssl.org>

On Tue Jul 19 17:47:43 2016, levitte wrote:
> On Tue Jul 19 16:41:13 2016, kurt at roeckx.be wrote:
> > On Mon, Jul 11, 2016 at 05:48:06PM +0000, Salz, Rich via RT wrote:
> > > Previously we've changed return-types from void to int. If there's
> > > still time, that seems like the thing to do here.
> >
> > I've pushed a branched on github that at least does some of the
> > things. See github #1330.
>
> Likewise for the CRYPTO_THREAD_run_once() issue, in
> https://github.com/openssl/openssl/pull/1332

All now merged into master branch. Closing this ticket.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed Jul 20 19:46:38 2016
From: rt at openssl.org (Dave Baggett via RT)
Date: Wed, 20 Jul 2016 19:46:38 +0000
Subject: [openssl-dev] [openssl.org #4618] BUG: Crash in do_ssl3_write
	unless OPENSSL_NO_MULTIBLOCK
In-Reply-To: <hOn6k-l3ABgU06tlqEGeAaD8TWej3wFHtVPHcw79FRrwuSY44@outlook.office365.com>
References: <RT-Ticket-4618@openssl.org>
 <hOn6k-l3ABgU06tlqEGeAaD8TWej3wFHtVPHcw79FRrwuSY44@outlook.office365.com>
Message-ID: <rt-4.0.19-17766-1469043998-816.4618-21-0@openssl.org>

OS: Mac OS X 11.11.5
Version: OpenSSL 1.1-pre6 (head code as of yesterday)
When the server fails under some circumstances, this line reads a bad address:
/* write the header */ 
 
*(outbuf[j]++) = type & 0xff; 

Because outbuf is 3. This is because prior to the alignment code, outbuf is 
NULL.
outbuf is set to s->rlayer->wbuf[0].buf, which at that point has been set to 
NULL by the code guarded by
#if !defined(OPENSSL_NO_MULTIBLOCK) && EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK 

in ssl3_write_bytes.
I'm sorry I can't give you a simple reproducer; I was able to reproduce it by 
mailing very large files with our mail app. Eventually the Exchange server 
fails and downstream code resets the write buffer and the multiblock code sets 
s->rlayer->wbuf[0].buf to NULL.
The workaround is to compile with -DOPENSSL_NO_MULTIBLOCK -- I've verified 
that this eliminates the crash in practice.
Feel free to email me if you want me to put in to some test code and reproduce 
it.
Dave
Sent with [inky](http://inky.com?kme=signature)

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4618
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5478 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160720/072f5ae8/attachment.bin>

From rt at openssl.org  Thu Jul 14 18:59:53 2016
From: rt at openssl.org (k.otik via RT)
Date: Thu, 14 Jul 2016 18:59:53 +0000
Subject: [openssl-dev] [openssl.org #4616] bug report
In-Reply-To: <4309841f-5f7b-cfd4-8cda-5b4b5629fca5@riseup.net>
References: <RT-Ticket-4616@openssl.org>
 <4309841f-5f7b-cfd4-8cda-5b4b5629fca5@riseup.net>
Message-ID: <rt-4.0.19-9387-1468522793-1274.4616-21-0@openssl.org>

OpenSSL self-test report:

OpenSSL version:  1.0.1t
Last change:      Prevent padding oracle in AES-NI CBC MAC check...
Options:          -Wa,--noexecstack no-ec_nistp_64_gcc_128 no-gmp 
no-jpake no-krb5 no-md2 no-rc5 no-rfc3779 no-sctp no-shared no-ssl2 
no-store no-unit-test no-weak-ssl-ciphers no-zlib no-zlib-dynamic 
static-engine
OS (uname):       Linux server 3.16.0-4-amd64 #1 SMP Debian 
3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux
OS (config):      x86_64-whatever-linux2
Target (default): linux-x86_64
Target:           linux-x86_64
Compiler:         Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib 
--enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre 
--enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc 
--enable-multiarch --with-arch-32=i586 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

Failure!
-----------------------------------------------------------------------------
make[1]: Entering directory '/home/imothep/T?l?chargements/openssl-1.0.1t'
making all in crypto...
make[2]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto'
making all in crypto/objects...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/objects'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/objects'
making all in crypto/md4...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/md4'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/md4'
making all in crypto/md5...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/md5'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/md5'
making all in crypto/sha...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/sha'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/sha'
making all in crypto/mdc2...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/mdc2'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/mdc2'
making all in crypto/hmac...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/hmac'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/hmac'
making all in crypto/ripemd...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ripemd'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ripemd'
making all in crypto/whrlpool...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/whrlpool'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/whrlpool'
making all in crypto/des...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/des'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/des'
making all in crypto/aes...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/aes'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/aes'
making all in crypto/rc2...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/rc2'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/rc2'
making all in crypto/rc4...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/rc4'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/rc4'
making all in crypto/idea...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/idea'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/idea'
making all in crypto/bf...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/bf'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/bf'
making all in crypto/cast...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/cast'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/cast'
making all in crypto/camellia...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/camellia'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/camellia'
making all in crypto/seed...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/seed'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/seed'
making all in crypto/modes...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/modes'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/modes'
making all in crypto/bn...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/bn'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/bn'
making all in crypto/ec...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ec'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ec'
making all in crypto/rsa...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/rsa'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/rsa'
making all in crypto/dsa...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/dsa'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/dsa'
making all in crypto/ecdsa...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ecdsa'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ecdsa'
making all in crypto/dh...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/dh'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/dh'
making all in crypto/ecdh...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ecdh'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ecdh'
making all in crypto/dso...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/dso'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/dso'
making all in crypto/engine...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/engine'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/engine'
making all in crypto/buffer...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/buffer'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/buffer'
making all in crypto/bio...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/bio'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/bio'
making all in crypto/stack...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/stack'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/stack'
making all in crypto/lhash...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/lhash'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/lhash'
making all in crypto/rand...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/rand'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/rand'
making all in crypto/err...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/err'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/err'
making all in crypto/evp...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/evp'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/evp'
making all in crypto/asn1...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/asn1'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/asn1'
making all in crypto/pem...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/pem'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/pem'
making all in crypto/x509...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/x509'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/x509'
making all in crypto/x509v3...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/x509v3'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/x509v3'
making all in crypto/conf...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/conf'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/conf'
making all in crypto/txt_db...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/txt_db'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/txt_db'
making all in crypto/pkcs7...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/pkcs7'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/pkcs7'
making all in crypto/pkcs12...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/pkcs12'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/pkcs12'
making all in crypto/comp...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/comp'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/comp'
making all in crypto/ocsp...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ocsp'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ocsp'
making all in crypto/ui...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ui'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ui'
making all in crypto/krb5...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/krb5'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/krb5'
making all in crypto/cms...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/cms'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/cms'
making all in crypto/pqueue...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/pqueue'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/pqueue'
making all in crypto/ts...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ts'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/ts'
making all in crypto/srp...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/srp'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/srp'
making all in crypto/cmac...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/cmac'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto/cmac'
if [ -n "" ]; then \
	(cd ..; make libcrypto.so.1.0.0); \
fi
make[2]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/crypto'
making all in engines...
make[2]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/engines'
echo

making all in engines/ccgost...
make[3]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/engines/ccgost'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/engines/ccgost'
make[2]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/engines'
making all in ssl...
make[2]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/ssl'
if [ -n "" ]; then \
	(cd ..; make libssl.so.1.0.0); \
fi
make[2]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/ssl'
making all in apps...
make[2]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/apps'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/apps'
making all in test...
make[2]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/test'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/test'
making all in tools...
make[2]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/tools'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/tools'
make[1]: Leaving directory '/home/imothep/T?l?chargements/openssl-1.0.1t'
-----------------------------------------------------------------------------
make[1]: Entering directory '/home/imothep/T?l?chargements/openssl-1.0.1t'
testing...
make[2]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/test'
make[3]: Entering directory '/home/imothep/T?l?chargements/openssl-1.0.1t'
making all in apps...
make[4]: Entering directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/apps'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/apps'
make[3]: Leaving directory '/home/imothep/T?l?chargements/openssl-1.0.1t'
../util/shlib_wrap.sh ./destest
Doing cbcm
Doing ecb
Doing ede ecb
Doing cbc
Doing desx cbc
Doing ede cbc
Doing pcbc
Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done
Doing ofb
Doing ofb64
Doing ede_ofb64
Doing cbc_cksum
Doing quad_cksum
input word alignment test 0 1 2 3
output word alignment test 0 1 2 3
fast crypt test
../util/shlib_wrap.sh ./ideatest
ecb idea ok
cbc idea ok
cfb64 idea ok
../util/shlib_wrap.sh ./shatest
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha1test
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha256t
Testing SHA-256 ... passed.
Testing SHA-224 ... passed.
../util/shlib_wrap.sh ./sha512t
Testing SHA-512 ... passed.
Testing SHA-384 ... passed.
../util/shlib_wrap.sh ./md4test
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
../util/shlib_wrap.sh ./md5test
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
../util/shlib_wrap.sh ./hmactest
test 0 ok
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
../util/shlib_wrap.sh ./md2test
No MD2 support
../util/shlib_wrap.sh ./mdc2test
pad1 - ok
pad2 - ok
../util/shlib_wrap.sh ./wp_test
Testing Whirlpool ......... passed.
../util/shlib_wrap.sh ./rmdtest
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
test 8 ok
../util/shlib_wrap.sh ./rc2test
ecb RC2 ok
../util/shlib_wrap.sh ./rc4test
test 0 ok
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test end processing ....................done
test multi-call ....................done
bulk test ok
../util/shlib_wrap.sh ./rc5test
No RC5 support
../util/shlib_wrap.sh ./bftest
testing blowfish in raw ecb mode
testing blowfish in ecb mode
testing blowfish set_key
testing blowfish in cbc mode
testing blowfish in cfb64 mode
testing blowfish in ofb64
../util/shlib_wrap.sh ./casttest
ecb cast5 ok
This test will take some time....123456789ABCDEF ok
../util/shlib_wrap.sh ./randtest
test 1 done
test 2 done
test 3 done
test 4 done
starting big number library test, could take a while...
test BN_add
test BN_sub
test BN_lshift1
test BN_lshift (fixed)
test BN_lshift
test BN_rshift1
test BN_rshift
test BN_sqr
test BN_mul
test BN_div
test BN_div_word
test BN_div_recp
test BN_mod
test BN_mod_mul
test BN_mont
test BN_mod_exp
test BN_mod_exp_mont_consttime
test BN_exp
test BN_kronecker
..........++++++
....................................................................................................
test BN_mod_sqrt
.....
.....
.....
.....
.....
.....
.....
.....
...................++++++++++++
.....
.....++++++++++++
.....
....................++++++++++++
.....
......++++++++++++
.....
..............++++++++++++
.....
....++++++++++++
.....
...............................++++++++++++
.....
........................++++++++++++
.....
test BN_GF2m_add
test BN_GF2m_mod
test BN_GF2m_mod_mul
test BN_GF2m_mod_sqr
test BN_GF2m_mod_inv
test BN_GF2m_mod_div
test BN_GF2m_mod_exp
test BN_GF2m_mod_sqrt
test BN_GF2m_mod_solve_quad
running bc

verify 
BN_add....................................................................................................
verify 
BN_sub......................................................................................................................................................
verify 
BN_lshift1....................................................................................................
verify BN_lshift 
(fixed)....................................................................................................
verify 
BN_lshift....................................................................................................
verify 
BN_rshift1....................................................................................................
verify 
BN_rshift....................................................................................................
verify 
BN_sqr......................................................................................................
verify 
BN_mul......................................................................................................................................................
verify 
BN_div............................................................................................................................................................................................................................................................................................................
verify 
BN_div_word........................................................................................................................................................................................................
verify 
BN_div_recp............................................................................................................................................................................................................................................................................................................
verify 
BN_mod....................................................................................................
verify 
BN_mod_mul............................................................................................................................................................................................................................................................................................................
verify BN_mont.....
verify BN_mod_exp.....
verify BN_mod_exp_mont_consttime.....
verify BN_exp.....
verify BN_kronecker
verify BN_mod_sqrt
verify BN_GF2m_add
verify BN_GF2m_mod
verify BN_GF2m_mod_mul
verify BN_GF2m_mod_sqr
verify BN_GF2m_mod_inv
verify BN_GF2m_mod_div
verify BN_GF2m_mod_exp
verify BN_GF2m_mod_sqrt
verify BN_GF2m_mod_solve_quad
2222 tests passed
test a^b%c implementations
../util/shlib_wrap.sh ./exptest
........................................................................................................................................................................................................
done
test elliptic curves
../util/shlib_wrap.sh ./ectest
Curve defined by Weierstrass equation
      y^2 = x^3 + a*x + b  (mod 0x17)
      a = 0x1
      b = 0x1
A cyclic subgroup:
      point at infinity
      x = 0xD, y = 0x7
      x = 0x5, y = 0x4
      x = 0x11, y = 0x3
      x = 0x11, y = 0x14
      x = 0x5, y = 0x13
      x = 0xD, y = 0x10
Generator as octet string, compressed form:
      030D
Generator as octet string, uncompressed form:
      040D07
Generator as octet string, hybrid form:
      070D07
A representation of the inverse of that generator in
Jacobian projective coordinates:
      X = 0xC, Y = 0xF, Z = 0xA

SEC2 curve secp160r1 -- Generator:
      x = 0x4A96B5688EF573284664698968C38BB913CBFC82
      y = 0x23A628553168947D59DCC912042351377AC5FB32
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve P-192 -- Generator:
      x = 0x188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012
      y = 0x7192B95FFC8DA78631011ED6B24CDD573F977A11E794811
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve P-224 -- Generator:
      x = 0xB70E0CBD6BB4BF7F321390B94A03C1D356C21122343280D6115C1D21
      y = 0xBD376388B5F723FB4C22DFE6CD4375A05A07476444D5819985007E34
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve P-256 -- Generator:
      x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296
      y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve P-384 -- Generator:
      x = 
0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7
      y = 
0x3617DE4A96262C6F5D9E98BF9292DC29F8F41DBD289A147CE9DA3113B5F0B8C00A60B1CE1D7E819D7A431D7C90EA0E5F
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve P-521 -- Generator:
      x = 
0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
      y = 
0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok
combined multiplication ..... ok


Curve defined by Weierstrass equation
      y^2 + x*y = x^3 + a*x^2 + b  (mod 0x13)
      a = 0x3
      b = 0x1
(0x... means binary polynomial)
A cyclic subgroup:
      point at infinity
      x = 0x6, y = 0x8
      x = 0x1, y = 0xD
      x = 0x7, y = 0x2
      x = 0x0, y = 0x1
      x = 0x7, y = 0x5
      x = 0x1, y = 0xC
      x = 0x6, y = 0xE

Generator as octet string, uncompressed form:
      040608

NIST curve K-163 -- Generator:
      x = 0x2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8
      y = 0x289070FB05D38FF58321F2E800536D538CCDAA3D9
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve B-163 -- Generator:
      x = 0x3F0EBA16286A2D57EA0991168D4994637E8343E36
      y = 0xD51FBC6C71A0094FA2CDD545B11C5C0C797324F1
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve K-233 -- Generator:
      x = 0x17232BA853A7E731AF129F22FF4149563A419C26BF50A4C9D6EEFAD6126
      y = 0x1DB537DECE819B7F70F555A67C427A8CD9BF18AEB9B56E0C11056FAE6A3
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve B-233 -- Generator:
      x = 0xFAC9DFCBAC8313BB2139F1BB755FEF65BC391F8B36F8F8EB7371FD558B
      y = 0x1006A08A41903350678E58528BEBF8A0BEFF867A7CA36716F7E01F81052
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve K-283 -- Generator:
      x = 
0x503213F78CA44883F1A3B8162F188E553CD265F23C1567A16876913B0C2AC2458492836
      y = 
0x1CCDA380F1C9E318D90F95D07E5426FE87E45C0E8184698E45962364E34116177DD2259
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve B-283 -- Generator:
      x = 
0x5F939258DB7DD90E1934F8C70B0DFEC2EED25B8557EAC9C80E2E198F8CDBECD86B12053
      y = 
0x3676854FE24141CB98FE6D4B20D02B4516FF702350EDDB0826779C813F0DF45BE8112F4
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve K-409 -- Generator:
      x = 
0x60F05F658F49C1AD3AB1890F7184210EFD0987E307C84C27ACCFB8F9F67CC2C460189EB5AAAA62EE222EB1B35540CFE9023746
      y = 
0x1E369050B7C4E42ACBA1DACBF04299C3460782F918EA427E6325165E9EA10E3DA5F6C42E9C55215AA9CA27A5863EC48D8E0286B
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve B-409 -- Generator:
      x = 
0x15D4860D088DDB3496B0C6064756260441CDE4AF1771D4DB01FFE5B34E59703DC255A868A1180515603AEAB60794E54BB7996A7
      y = 
0x61B1CFAB6BE5F32BBFA78324ED106A7636B9C5A7BD198D0158AA4F5488D08F38514F1FDF4B4F40D2181B3681C364BA0273C706
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve K-571 -- Generator:
      x = 
0x26EB7A859923FBC82189631F8103FE4AC9CA2970012D5D46024804801841CA44370958493B205E647DA304DB4CEB08CBBD1BA39494776FB988B47174DCA88C7E2945283A01C8972
      y = 
0x349DC807F4FBF374F4AEADE3BCA95314DD58CEC9F307A54FFC61EFC006D8A2C9D4979C0AC44AEA74FBEBBB9F772AEDCB620B01A7BA7AF1B320430C8591984F601CD4C143EF1C7A3
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok

NIST curve B-571 -- Generator:
      x = 
0x303001D34B856296C16C0D40D3CD7750A93D1D2955FA80AA5F40FC8DB7B2ABDBDE53950F4C0D293CDD711A35B67FB1499AE60038614F1394ABFA3B4C850D927E1E7769C8EEC2D19
      y = 
0x37BF27342DA639B6DCCFFFEB73D69D78C6C27A6009CBBCA1980F8533921E8A684423E43BAB08A576291AF8F461BB2A8B3531D2F0485C19B16E2F1516E23DD3C1A4827AF1B8AC15B
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without 
precomputation ... ok
combined multiplication ..... ok

testing internal curves: 
................................................................... ok

test ecdsa
../util/shlib_wrap.sh ./ecdsatest
some tests from X9.62:
testing prime192v1: .... ok
testing prime239v1: .... ok
testing c2tnb191v1: .... ok
testing c2tnb239v1: .... ok

testing ECDSA_sign() and ECDSA_verify() with some internal curves:
secp160k1: ........ ok
secp160r1: ........ ok
secp160r2: ........ ok
secp192k1: ........ ok
secp224k1: ........ ok
secp224r1: ........ ok
secp256k1: ........ ok
secp384r1: ........ ok
secp521r1: ........ ok
prime192v1: ........ ok
prime192v2: ........ ok
prime192v3: ........ ok
prime239v1: ........ ok
prime239v2: ........ ok
prime239v3: ........ ok
prime256v1: ........ ok
sect163k1: ........ ok
sect163r1: ........ ok
sect163r2: ........ ok
sect193r1: ........ ok
sect193r2: ........ ok
sect233k1: ........ ok
sect233r1: ........ ok
sect239k1: ........ ok
sect283k1: ........ ok
sect283r1: ........ ok
sect409k1: ........ ok
sect409r1: ........ ok
sect571k1: ........ ok
sect571r1: ........ ok
c2pnb163v1: ........ ok
c2pnb163v2: ........ ok
c2pnb163v3: ........ ok
c2pnb176v1: ........ ok
c2tnb191v1: ........ ok
c2tnb191v2: ........ ok
c2tnb191v3: ........ ok
c2pnb208w1: ........ ok
c2tnb239v1: ........ ok
c2tnb239v2: ........ ok
c2tnb239v3: ........ ok
c2pnb272w1: ........ ok
c2pnb304w1: ........ ok
c2tnb359v1: ........ ok
c2pnb368w1: ........ ok
c2tnb431r1: ........ ok
wap-wsg-idm-ecid-wtls3: ........ ok
wap-wsg-idm-ecid-wtls5: ........ ok
wap-wsg-idm-ecid-wtls7: ........ ok
wap-wsg-idm-ecid-wtls9: ........ ok
wap-wsg-idm-ecid-wtls10: ........ ok
wap-wsg-idm-ecid-wtls11: ........ ok
wap-wsg-idm-ecid-wtls12: ........ ok

ECDSA test passed
test ecdh
../util/shlib_wrap.sh ./ecdhtest
Testing key generation with NIST Prime-Curve P-192 .... ok
Testing key generation with NIST Prime-Curve P-224 .... ok
Testing key generation with NIST Prime-Curve P-256 .... ok
Testing key generation with NIST Prime-Curve P-384 .... ok
Testing key generation with NIST Prime-Curve P-521 .... ok
Testing key generation with NIST Binary-Curve K-163 .... ok
Testing key generation with NIST Binary-Curve B-163 .... ok
Testing key generation with NIST Binary-Curve K-233 .... ok
Testing key generation with NIST Binary-Curve B-233 .... ok
Testing key generation with NIST Binary-Curve K-283 .... ok
Testing key generation with NIST Binary-Curve B-283 .... ok
Testing key generation with NIST Binary-Curve K-409 .... ok
Testing key generation with NIST Binary-Curve B-409 .... ok
Testing key generation with NIST Binary-Curve K-571 .... ok
Testing key generation with NIST Binary-Curve B-571 .... ok
cat
base64
aes-128-cbc
aes-128-cbc base64
aes-128-ecb
aes-128-ecb base64
aes-192-cbc
aes-192-cbc base64
aes-192-ecb
aes-192-ecb base64
aes-256-cbc
aes-256-cbc base64
aes-256-ecb
aes-256-ecb base64
base64
base64 base64
bf
bf base64
bf-cbc
bf-cbc base64
bf-cfb
bf-cfb base64
bf-ecb
bf-ecb base64
bf-ofb
bf-ofb base64
camellia-128-cbc
camellia-128-cbc base64
camellia-128-ecb
camellia-128-ecb base64
camellia-192-cbc
camellia-192-cbc base64
camellia-192-ecb
camellia-192-ecb base64
camellia-256-cbc
camellia-256-cbc base64
camellia-256-ecb
camellia-256-ecb base64
cast
cast base64
cast-cbc
cast-cbc base64
cast5-cbc
cast5-cbc base64
cast5-cfb
cast5-cfb base64
cast5-ecb
cast5-ecb base64
cast5-ofb
cast5-ofb base64
des
des base64
des-cbc
des-cbc base64
des-cfb
des-cfb base64
des-ecb
des-ecb base64
des-ede
des-ede base64
des-ede-cbc
des-ede-cbc base64
des-ede-cfb
des-ede-cfb base64
des-ede-ofb
des-ede-ofb base64
des-ede3
des-ede3 base64
des-ede3-cbc
des-ede3-cbc base64
des-ede3-cfb
des-ede3-cfb base64
des-ede3-ofb
des-ede3-ofb base64
des-ofb
des-ofb base64
des3
des3 base64
desx
desx base64
idea
idea base64
idea-cbc
idea-cbc base64
idea-cfb
idea-cfb base64
idea-ecb
idea-ecb base64
idea-ofb
idea-ofb base64
rc2
rc2 base64
rc2-40-cbc
rc2-40-cbc base64
rc2-64-cbc
rc2-64-cbc base64
rc2-cbc
rc2-cbc base64
rc2-cfb
rc2-cfb base64
rc2-ecb
rc2-ecb base64
rc2-ofb
rc2-ofb base64
rc4
rc4 base64
rc4-40
rc4-40 base64
seed
seed base64
seed-cbc
seed-cbc base64
seed-cfb
seed-cfb base64
seed-ecb
seed-ecb base64
seed-ofb
seed-ofb base64
echo test normal x509v1 certificate
test normal x509v1 certificate
sh ./tx509 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
echo test first x509v3 certificate
test first x509v3 certificate
sh ./tx509 v3-cert1.pem 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
echo test second x509v3 certificate
test second x509v3 certificate
sh ./tx509 v3-cert2.pem 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
rsa
testing rsa conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
../util/shlib_wrap.sh ./rsa_test
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
testing crl conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing session-id conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
Generate and verify a certificate request
generating certificate request
rsa
There should be a 2 sequences of .'s and some +'s.
There should not be more that at most 80 per line
This could take some time.
Generating a 1024 bit RSA private key
..............++++++
........................................++++++
writing new private key to 'testkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Queensland]:
Locality Name (eg, city) []:Brisbane
Organization Name (eg, company) []:CryptSoft Pty Ltd
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:Eric Young
Email Address []:eay at mincom.oz.au
verify OK
testing req conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing req conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions (2)
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
The following command should have some OK's and some failures
There are definitly a few expired certificates
../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo 
../certs/demo/*.pem
../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty 
Ltd, CN = Test PCA (1024 bit)
error 10 at 1 depth lookup:certificate has expired
C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test CA (1024 bit)
error 10 at 0 depth lookup:certificate has expired
OK
../certs/demo/dsa-ca.pem: C = AU, ST = Some-State, O = Internet Widgits 
Pty Ltd, CN = PCA
error 10 at 1 depth lookup:certificate has expired
C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = CA
error 10 at 0 depth lookup:certificate has expired
OK
../certs/demo/dsa-pca.pem: C = AU, ST = Some-State, O = Internet Widgits 
Pty Ltd, CN = PCA
error 10 at 0 depth lookup:certificate has expired
OK
../certs/demo/pca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty 
Ltd, CN = Test PCA (1024 bit)
error 10 at 0 depth lookup:certificate has expired
OK
Generate a set of DH parameters
../util/shlib_wrap.sh ./dhtest
.++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*

p    =E0C65A58BE4387E7
g    =5
pri 1=754733D0CCDD2EB0
pub 1=4E476D179878C098
pri 2=678785A449B0E7DB
pub 2=BD4A5ADAED107486
key1 =24135104386A26C1
key2 =24135104386A26C1
Generate a set of DSA parameters
../util/shlib_wrap.sh ./dsatest
test generation of DSA parameters
.++++++++++++++++++++++++++++++++++++++++++++++++++*
...+........+..+...+............+.+..+..........................................................................+++++++++++++++++++++++++++++++++++++++++++++++++++*
seed
D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3
counter=105 h=2
P:
     00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68:
     69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d:
     78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac:
     32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36:
     ee:31:c8:02:91
Q:
     00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30:
     f4:8e:da:ce:91:5f
G:
     62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5:
     00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce:
     2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21:
     92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53:
     e6:d7:88:02
../util/shlib_wrap.sh ./dsatest -app2_1
test generation of DSA parameters
.++++++++++++++++++++++++++++++++++++++++++++++++++*
...+........+..+...+............+.+..+..........................................................................+++++++++++++++++++++++++++++++++++++++++++++++++++*
seed
D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3
counter=105 h=2
P:
     00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68:
     69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d:
     78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac:
     32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36:
     ee:31:c8:02:91
Q:
     00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30:
     f4:8e:da:ce:91:5f
G:
     62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5:
     00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce:
     2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21:
     92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53:
     e6:d7:88:02
Generate and certify a test certificate

make a certificate request using 'req'
rsa
Generating a 2048 bit RSA private key
.................................................................+++
................+++
writing new private key to 'keyCA.ss'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Dodgy CA

convert the certificate request into a self signed certificate using 'x509'
Signature ok
subject=/C=AU/O=Dodgy Brothers/CN=Dodgy CA
Getting Private key

convert a certificate into a certificate request using 'x509'
Getting request Private Key
Generating certificate request
verify OK
verify OK
certCA.ss: OK

make a user certificate request using 'req'
Generating a 2048 bit RSA private key
...........................+++
.......................................................+++
writing new private key to 'keyU.ss'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Brother 1
Common Name (eg, YOUR name) []:Brother 2

sign user certificate request with the just created CA via 'x509'
Signature ok
subject=/C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
Getting CA Private Key
certU.ss: OK

Certificate details
subject= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
issuer= /C=AU/O=Dodgy Brothers/CN=Dodgy CA
notBefore=Jul 14 18:42:59 2016 GMT
notAfter=Aug 13 18:42:59 2016 GMT

make a proxy certificate request using 'req'
Generating a 1024 bit RSA private key
.............................++++++
..++++++
writing new private key to 'keyP1.ss'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Brother 1
Common Name (eg, YOUR name) []:Brother 2
Common Name (eg, YOUR name) []:Proxy 1

sign proxy certificate request with the just created user certificate 
via 'x509'
Signature ok
subject=/C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
Getting CA Private Key
certP1.ss: C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, 
CN = Proxy 1
error 40 at 0 depth lookup:proxy certificates not allowed, please set 
the appropriate flag

Certificate details
subject= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
issuer= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
notBefore=Jul 14 18:42:59 2016 GMT
notAfter=Aug 13 18:42:59 2016 GMT

make another proxy certificate request using 'req'
Generating a 1024 bit RSA private key
..............................................++++++
....++++++
writing new private key to 'keyP2.ss'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Brother 1
Common Name (eg, YOUR name) []:Brother 2
Common Name (eg, YOUR name) []:Proxy 1
Common Name (eg, YOUR name) []:Proxy 2

sign second proxy certificate request with the first proxy certificate 
via 'x509'
Signature ok
subject=/C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
Getting CA Private Key
certP2.ss: C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, 
CN = Proxy 1, CN = Proxy 2
error 40 at 0 depth lookup:proxy certificates not allowed, please set 
the appropriate flag

Certificate details
subject= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
issuer= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
notBefore=Jul 14 18:42:59 2016 GMT
notAfter=Aug 13 18:42:59 2016 GMT

The generated CA certificate is certCA.ss
The generated CA private key is keyCA.ss
The generated user certificate is certU.ss
The generated user private key is keyU.ss
The first generated proxy certificate is certP1.ss
The first generated proxy private key is keyP1.ss
The second generated proxy certificate is certP2.ss
The second generated proxy private key is keyP2.ss
rsa
Generate and certify a test certificate via the 'ca' program
CA certificate filename (or enter to create)
Making CA certificate ...
Generating a 2048 bit RSA private key
........+++
...+++
writing new private key to './demoCA/private/./cakey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Dodgy CA
Using configuration from CAss.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
         Serial Number:
             ab:8e:5f:30:31:f1:a4:87
         Validity
             Not Before: Jul 14 18:42:59 2016 GMT
             Not After : Jul 14 18:42:59 2019 GMT
         Subject:
             countryName               = AU
             organizationName          = Dodgy Brothers
             commonName                = Dodgy CA
         X509v3 extensions:
             X509v3 Subject Key Identifier:
                 4C:1A:85:C9:15:0A:66:AC:27:8F:8D:DA:60:77:76:93:72:CD:73:CD
             X509v3 Authority Key Identifier:
 
keyid:4C:1A:85:C9:15:0A:66:AC:27:8F:8D:DA:60:77:76:93:72:CD:73:CD
                 DirName:/C=AU/O=Dodgy Brothers/CN=Dodgy CA
                 serial:AB:8E:5F:30:31:F1:A4:87

             X509v3 Basic Constraints:
                 CA:TRUE, pathlen:1
             X509v3 Key Usage:
                 Certificate Sign, CRL Sign
             X509v3 Issuer Alternative Name:
                 <EMPTY>

Certificate is to be certified until Jul 14 18:42:59 2019 GMT (1095 days)

Write out database with 1 new entries
Data Base Updated
Generating a 2048 bit RSA private key
......................+++
....................................+++
writing new private key to 'newkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Brother 1
Common Name (eg, YOUR name) []:Brother 2
Request is in newreq.pem, private key is in newkey.pem
Using configuration from ../apps/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
         Serial Number:
             ab:8e:5f:30:31:f1:a4:88
         Validity
             Not Before: Jul 14 18:42:59 2016 GMT
             Not After : Jul 14 18:42:59 2017 GMT
         Subject:
             countryName               = AU
             organizationName          = Dodgy Brothers
             commonName                = Brother 1
             commonName                = Brother 2
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             Netscape Comment:
                 OpenSSL Generated Certificate
             X509v3 Subject Key Identifier:
                 7B:B3:53:AA:F7:64:96:D2:4A:24:26:17:9C:1B:E7:26:6D:06:2D:26
             X509v3 Authority Key Identifier:
 
keyid:4C:1A:85:C9:15:0A:66:AC:27:8F:8D:DA:60:77:76:93:72:CD:73:CD

Certificate is to be certified until Jul 14 18:42:59 2017 GMT (365 days)
Sign the certificate? [y/n]:

1 out of 1 certificate requests certified, commit? [y/n]Write out 
database with 1 new entries
Data Base Updated
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             ab:8e:5f:30:31:f1:a4:88
     Signature Algorithm: sha1WithRSAEncryption
         Issuer: C=AU, O=Dodgy Brothers, CN=Dodgy CA
         Validity
             Not Before: Jul 14 18:42:59 2016 GMT
             Not After : Jul 14 18:42:59 2017 GMT
         Subject: C=AU, O=Dodgy Brothers, CN=Brother 1, CN=Brother 2
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
                 Public-Key: (2048 bit)
                 Modulus:
                     00:c2:1c:bb:d7:4c:d7:86:f9:a6:9b:d3:40:cb:54:
                     2f:70:38:dd:d7:44:cd:57:86:a5:e2:76:fc:f3:9a:
                     6d:af:57:f1:e9:62:06:45:e1:7f:1a:3f:41:20:84:
                     d7:0c:d3:25:bf:44:f4:b3:9a:4f:4d:fa:cf:b0:d6:
                     d7:1d:4c:59:09:75:2c:0a:2b:38:e0:6d:76:e8:3b:
                     53:b7:4f:95:02:d2:e4:74:06:fc:06:14:d3:af:4d:
                     9e:91:04:f4:6c:31:ae:67:65:2f:24:8b:e5:4e:84:
                     c1:3e:b3:f0:fb:77:aa:4f:aa:9e:be:d1:7e:fd:d6:
                     fb:b9:cd:5b:ce:b6:27:bc:d4:ac:1e:70:0c:32:0f:
                     9f:c7:fc:af:64:91:73:97:73:37:a1:0d:b9:1e:6a:
                     7d:c3:a3:b1:de:f1:cc:49:35:7f:63:dd:8b:d4:72:
                     a3:4c:fa:4a:21:3e:0a:b4:50:53:0f:e7:50:c9:7e:
                     3a:3c:72:e5:1d:f0:a8:be:e0:bd:17:29:27:ec:4c:
                     ee:65:2c:50:67:68:df:62:6a:2d:7a:8a:8a:6a:37:
                     4f:c9:ad:f9:18:43:61:0c:e1:a4:92:9a:41:d8:0e:
                     ec:3b:19:c8:01:30:d8:40:e3:28:3e:38:15:c1:c2:
                     7f:2f:d3:75:bb:6d:78:c2:f3:e0:3a:84:5a:39:36:
                     91:67
                 Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             Netscape Comment:
                 OpenSSL Generated Certificate
             X509v3 Subject Key Identifier:
                 7B:B3:53:AA:F7:64:96:D2:4A:24:26:17:9C:1B:E7:26:6D:06:2D:26
             X509v3 Authority Key Identifier:
 
keyid:4C:1A:85:C9:15:0A:66:AC:27:8F:8D:DA:60:77:76:93:72:CD:73:CD

     Signature Algorithm: sha1WithRSAEncryption
          2b:79:27:7d:b7:74:52:1f:55:e7:9c:cd:49:47:25:84:51:09:
          d4:f7:9b:b1:25:d4:32:79:6b:74:17:eb:d0:97:83:e6:ba:fc:
          55:07:10:55:79:0a:f4:b7:de:67:ad:8c:8a:1e:59:33:2a:e4:
          1e:e4:c1:d0:19:12:59:4f:98:b2:a4:ff:9f:29:93:c4:92:0e:
          ad:f5:12:01:c1:ea:52:3c:56:e3:a4:e2:63:c4:fd:ff:d9:28:
          3c:52:25:8c:8b:85:cc:5b:3b:e8:85:0a:a0:fb:b8:1f:2c:db:
          d0:3d:7b:c1:9e:c1:b4:25:7b:7f:8e:51:10:24:87:72:0f:24:
          14:c6:41:95:54:cd:7f:d7:20:1f:b9:e5:31:1d:ed:94:af:71:
          aa:ac:76:b9:3e:73:23:6d:b6:95:2c:e6:ed:b5:28:3e:1b:cc:
          69:a7:81:7b:b3:27:54:a7:fb:2c:ab:a8:6c:3f:ef:81:c7:da:
          da:32:bf:7e:0b:3c:7a:c2:19:54:ae:c5:52:02:7a:5e:39:67:
          6c:e2:43:17:30:7d:a9:9e:b2:88:27:ef:5e:22:4c:0e:1d:44:
          43:bd:8b:b1:d0:a4:bf:08:4a:f2:a5:df:81:b4:a6:14:84:8b:
          7b:41:b6:57:9b:14:1e:bb:9e:c6:27:85:97:17:eb:2c:6c:c1:
          e8:9a:82:7c
-----BEGIN CERTIFICATE-----
MIIDhTCCAm2gAwIBAgIJAKuOXzAx8aSIMA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV
BAYTAkFVMRcwFQYDVQQKDA5Eb2RneSBCcm90aGVyczERMA8GA1UEAwwIRG9kZ3kg
Q0EwHhcNMTYwNzE0MTg0MjU5WhcNMTcwNzE0MTg0MjU5WjBOMQswCQYDVQQGEwJB
VTEXMBUGA1UECgwORG9kZ3kgQnJvdGhlcnMxEjAQBgNVBAMMCUJyb3RoZXIgMTES
MBAGA1UEAwwJQnJvdGhlciAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwhy710zXhvmmm9NAy1QvcDjd10TNV4al4nb885ptr1fx6WIGReF/Gj9BIITX
DNMlv0T0s5pPTfrPsNbXHUxZCXUsCis44G126DtTt0+VAtLkdAb8BhTTr02ekQT0
bDGuZ2UvJIvlToTBPrPw+3eqT6qevtF+/db7uc1bzrYnvNSsHnAMMg+fx/yvZJFz
l3M3oQ25Hmp9w6Ox3vHMSTV/Y92L1HKjTPpKIT4KtFBTD+dQyX46PHLlHfCovuC9
Fykn7EzuZSxQZ2jfYmoteoqKajdPya35GENhDOGkkppB2A7sOxnIATDYQOMoPjgV
wcJ/L9N1u214wvPgOoRaOTaRZwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG
+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU
e7NTqvdkltJKJCYXnBvnJm0GLSYwHwYDVR0jBBgwFoAUTBqFyRUKZqwnj43aYHd2
k3LNc80wDQYJKoZIhvcNAQEFBQADggEBACt5J323dFIfVeeczUlHJYRRCdT3m7El
1DJ5a3QX69CXg+a6/FUHEFV5CvS33metjIoeWTMq5B7kwdAZEllPmLKk/58pk8SS
Dq31EgHB6lI8VuOk4mPE/f/ZKDxSJYyLhcxbO+iFCqD7uB8s29A9e8GewbQle3+O
URAkh3IPJBTGQZVUzX/XIB+55TEd7ZSvcaqsdrk+cyNttpUs5u21KD4bzGmngXuz
J1Sn+yyrqGw/74HH2toyv34LPHrCGVSuxVICel45Z2ziQxcwfamesogn714iTA4d
REO9i7HQpL8ISvKl34G0phSEi3tBtlebFB67nsYnhZcX6yxsweiagnw=
-----END CERTIFICATE-----
Signed certificate is in newcert.pem
newcert.pem: OK
Manipulate the ENGINE structures
../util/shlib_wrap.sh ./enginetest

enginetest beginning

listing available engine types
end of list
listing available engine types
engine 0, id = "test_id0", name = "First test item"
end of list
listing available engine types
end of list
listing available engine types
engine 0, id = "test_id2", name = "Third test item"
engine 1, id = "test_id1", name = "Second test item"
end of list
listing available engine types
engine 0, id = "test_id2", name = "Third test item"
end of list
listing available engine types
engine 0, id = "test_id2", name = "Third test item"
engine 1, id = "test_id3", name = "Fourth test item"
end of list
Add that should fail did.
Remove that should fail did.
listing available engine types
engine 0, id = "test_id3", name = "Fourth test item"
end of list
listing available engine types
end of list
listing available engine types
end of list
Successfully added and removed to an empty list!
About to beef up the engine-type list
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
About to empty the engine-type list
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Tests completed happily
../util/shlib_wrap.sh ./evp_test evptests.txt
Testing digest SHA1
Plaintext
0000 61 62 63
Digest
0000 a9 99 3e 36 47 06 81 6a ba 3e 25 71 78 50 c2 6c
0010 9c d0 d8 9d

Testing digest MD5
Plaintext
Digest
0000 d4 1d 8c d9 8f 00 b2 04 e9 80 09 98 ec f8 42 7e

Testing digest MD5
Plaintext
0000 61
Digest
0000 0c c1 75 b9 c0 f1 b6 a8 31 c3 99 e2 69 77 26 61

Testing digest MD5
Plaintext
0000 61 62 63
Digest
0000 90 01 50 98 3c d2 4f b0 d6 96 3f 7d 28 e1 7f 72

Testing digest MD5
Plaintext
0000 6d 65 73 73 61 67 65 20 64 69 67 65 73 74
Digest
0000 f9 6b 69 7d 7c b7 93 8d 52 5a 2f 31 aa f1 61 d0

Testing digest MD5
Plaintext
0000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
0010 71 72 73 74 75 76 77 78 79 7a
Digest
0000 c3 fc d3 d7 61 92 e4 00 7d fb 49 6c ca 67 e1 3b

Testing digest MD5
Plaintext
0000 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50
0010 51 52 53 54 55 56 57 58 59 5a 61 62 63 64 65 66
0020 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76
0030 77 78 79 7a 30 31 32 33 34 35 36 37 38 39
Digest
0000 d1 74 ab 98 d2 77 d9 f5 a5 61 1c 2c 9f 41 9d 9f

Testing digest MD5
Plaintext
0000 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36
0010 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32
0020 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38
0030 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34
0040 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30
Digest
0000 57 ed f4 a2 2b e3 c9 55 ac 49 da 2e 21 07 b6 7a

Testing cipher AES-128-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a

Testing cipher AES-192-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 dd a9 7c a4 86 4c df e0 6e af 70 a0 ec 0d 71 91

Testing cipher AES-256-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 8e a2 b7 ca 51 67 45 bf ea fc 49 90 4b 49 60 89

Testing cipher AES-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3a d7 7b b4 0d 7a 36 60 a8 9e ca f3 24 66 ef 97

Testing cipher AES-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 f5 d3 d5 85 03 b9 69 9d e7 85 89 5a 96 fd ba af

Testing cipher AES-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 43 b1 cd 7f 59 8e ce 23 88 1b 00 e3 ed 03 06 88

Testing cipher AES-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 7b 0c 78 5e 27 e8 ad 3f 82 23 20 71 04 72 5d d4

Testing cipher AES-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 bd 33 4f 1d 6e 45 f2 5f f7 12 a2 14 57 1f a5 cc

Testing cipher AES-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 97 41 04 84 6d 0a d3 ad 77 34 ec b3 ec ee 4e ef

Testing cipher AES-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 ef 7a fd 22 70 e2 e6 0a dc e0 ba 2f ac e6 44 4e

Testing cipher AES-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 9a 4b 41 ba 73 8d 6c 72 fb 16 69 16 03 c1 8e 0e

Testing cipher AES-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 f3 ee d1 bd b5 d2 a0 3c 06 4b 5a 7e 3d b1 81 f8

Testing cipher AES-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 59 1c cb 10 d4 10 ed 26 dc 5b a7 4a 31 36 28 70

Testing cipher AES-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 b6 ed 21 b9 9c a6 f4 f9 f1 53 e7 b1 be af ed 1d

Testing cipher AES-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 23 30 4b 7a 39 f9 f3 ff 06 7d 8d 8f 9e 24 ec c7

Testing cipher AES-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 76 49 ab ac 81 19 b2 46 ce e9 8e 9b 12 e9 19 7d

Testing cipher AES-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 76 49 ab ac 81 19 b2 46 ce e9 8e 9b 12 e9 19 7d
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 50 86 cb 9b 50 72 19 ee 95 db 11 3a 91 76 78 b2

Testing cipher AES-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 86 cb 9b 50 72 19 ee 95 db 11 3a 91 76 78 b2
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 73 be d6 b8 e3 c1 74 3b 71 16 e6 9e 22 22 95 16

Testing cipher AES-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 73 be d6 b8 e3 c1 74 3b 71 16 e6 9e 22 22 95 16
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 3f f1 ca a1 68 1f ac 09 12 0e ca 30 75 86 e1 a7

Testing cipher AES-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 4f 02 1d b2 43 bc 63 3d 71 78 18 3a 9f a0 71 e8

Testing cipher AES-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 4f 02 1d b2 43 bc 63 3d 71 78 18 3a 9f a0 71 e8
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 b4 d9 ad a9 ad 7d ed f4 e5 e7 38 76 3f 69 14 5a

Testing cipher AES-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 b4 d9 ad a9 ad 7d ed f4 e5 e7 38 76 3f 69 14 5a
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 57 1b 24 20 12 fb 7a e0 7f a9 ba ac 3d f1 02 e0

Testing cipher AES-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 57 1b 24 20 12 fb 7a e0 7f a9 ba ac 3d f1 02 e0
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 08 b0 e2 79 88 59 88 81 d9 20 a9 e6 4f 56 15 cd

Testing cipher AES-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 f5 8c 4c 04 d6 e5 f1 ba 77 9e ab fb 5f 7b fb d6

Testing cipher AES-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 f5 8c 4c 04 d6 e5 f1 ba 77 9e ab fb 5f 7b fb d6
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 9c fc 4e 96 7e db 80 8d 67 9f 77 7b c6 70 2c 7d

Testing cipher AES-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 9c fc 4e 96 7e db 80 8d 67 9f 77 7b c6 70 2c 7d
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 39 f2 33 69 a9 d9 ba cf a5 30 e2 63 04 23 14 61

Testing cipher AES-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 39 f2 33 69 a9 d9 ba cf a5 30 e2 63 04 23 14 61
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 b2 eb 05 e2 c3 9b e9 fc da 6c 19 07 8c 6a 9d 1b

Testing cipher AES-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a

Testing cipher AES-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 c8 a6 45 37 a0 b3 a9 3f cd e3 cd ad 9f 1c e5 8b

Testing cipher AES-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 c8 a6 45 37 a0 b3 a9 3f cd e3 cd ad 9f 1c e5 8b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 26 75 1f 67 a3 cb b1 40 b1 80 8c f1 87 a4 f4 df

Testing cipher AES-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 26 75 1f 67 a3 cb b1 40 b1 80 8c f1 87 a4 f4 df
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 c0 4b 05 35 7c 5d 1c 0e ea c4 c6 6f 9f f7 f2 e6

Testing cipher AES-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a

Testing cipher AES-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 c8 a6 45 37 a0 b3 a9 3f cd e3 cd ad 9f 1c e5 8b

Testing cipher AES-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 c8 a6 45 37 a0 b3 a9 3f cd e3 cd ad 9f 1c e5 8b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 26 75 1f 67 a3 cb b1 40 b1 80 8c f1 87 a4 f4 df

Testing cipher AES-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 26 75 1f 67 a3 cb b1 40 b1 80 8c f1 87 a4 f4 df
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 c0 4b 05 35 7c 5d 1c 0e ea c4 c6 6f 9f f7 f2 e6

Testing cipher AES-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74

Testing cipher AES-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 67 ce 7f 7f 81 17 36 21 96 1a 2b 70 17 1d 3d 7a

Testing cipher AES-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 67 ce 7f 7f 81 17 36 21 96 1a 2b 70 17 1d 3d 7a
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 2e 1e 8a 1d d5 9b 88 b1 c8 e6 0f ed 1e fa c4 c9

Testing cipher AES-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 2e 1e 8a 1d d5 9b 88 b1 c8 e6 0f ed 1e fa c4 c9
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 c0 5f 9f 9c a9 83 4f a0 42 ae 8f ba 58 4b 09 ff

Testing cipher AES-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74

Testing cipher AES-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 67 ce 7f 7f 81 17 36 21 96 1a 2b 70 17 1d 3d 7a

Testing cipher AES-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 67 ce 7f 7f 81 17 36 21 96 1a 2b 70 17 1d 3d 7a
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 2e 1e 8a 1d d5 9b 88 b1 c8 e6 0f ed 1e fa c4 c9

Testing cipher AES-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 2e 1e 8a 1d d5 9b 88 b1 c8 e6 0f ed 1e fa c4 c9
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 c0 5f 9f 9c a9 83 4f a0 42 ae 8f ba 58 4b 09 ff

Testing cipher AES-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60

Testing cipher AES-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 39 ff ed 14 3b 28 b1 c8 32 11 3c 63 31 e5 40 7b

Testing cipher AES-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 39 ff ed 14 3b 28 b1 c8 32 11 3c 63 31 e5 40 7b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 df 10 13 24 15 e5 4b 92 a1 3e d0 a8 26 7a e2 f9

Testing cipher AES-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 df 10 13 24 15 e5 4b 92 a1 3e d0 a8 26 7a e2 f9
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 75 a3 85 74 1a b9 ce f8 20 31 62 3d 55 b1 e4 71

Testing cipher AES-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60

Testing cipher AES-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 39 ff ed 14 3b 28 b1 c8 32 11 3c 63 31 e5 40 7b

Testing cipher AES-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 39 ff ed 14 3b 28 b1 c8 32 11 3c 63 31 e5 40 7b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 df 10 13 24 15 e5 4b 92 a1 3e d0 a8 26 7a e2 f9

Testing cipher AES-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 df 10 13 24 15 e5 4b 92 a1 3e d0 a8 26 7a e2 f9
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 75 a3 85 74 1a b9 ce f8 20 31 62 3d 55 b1 e4 71

Testing cipher AES-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a

Testing cipher AES-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 fe 67 cc 99 6d 32 b6 da 09 37 e9 9b af ec 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 77 89 50 8d 16 91 8f 03 f5 3c 52 da c5 4e d8 25

Testing cipher AES-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 d9 a4 da da 08 92 23 9f 6b 8b 3d 76 80 e1 56 74
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 97 40 05 1e 9c 5f ec f6 43 44 f7 a8 22 60 ed cc

Testing cipher AES-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a7 88 19 58 3f 03 08 e7 a6 bf 36 b1 38 6a bf 23
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 30 4c 65 28 f6 59 c7 78 66 a5 10 d9 c1 d6 ae 5e

Testing cipher AES-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a

Testing cipher AES-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 fe 67 cc 99 6d 32 b6 da 09 37 e9 9b af ec 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 77 89 50 8d 16 91 8f 03 f5 3c 52 da c5 4e d8 25

Testing cipher AES-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 d9 a4 da da 08 92 23 9f 6b 8b 3d 76 80 e1 56 74
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 97 40 05 1e 9c 5f ec f6 43 44 f7 a8 22 60 ed cc

Testing cipher AES-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a7 88 19 58 3f 03 08 e7 a6 bf 36 b1 38 6a bf 23
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 30 4c 65 28 f6 59 c7 78 66 a5 10 d9 c1 d6 ae 5e

Testing cipher AES-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74

Testing cipher AES-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 a6 09 b3 8d f3 b1 13 3d dd ff 27 18 ba 09 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 fc c2 8b 8d 4c 63 83 7c 09 e8 17 00 c1 10 04 01

Testing cipher AES-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 8d 9a 9a ea c0 f6 59 6f 55 9c 6d 4d af 59 a5 f2

Testing cipher AES-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 bd 52 86 ac 63 aa bd 7e b0 67 ac 54 b5 53 f7 1d
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 6d 9f 20 08 57 ca 6c 3e 9c ac 52 4b d9 ac c9 2a

Testing cipher AES-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74

Testing cipher AES-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 a6 09 b3 8d f3 b1 13 3d dd ff 27 18 ba 09 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 fc c2 8b 8d 4c 63 83 7c 09 e8 17 00 c1 10 04 01

Testing cipher AES-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 8d 9a 9a ea c0 f6 59 6f 55 9c 6d 4d af 59 a5 f2

Testing cipher AES-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 bd 52 86 ac 63 aa bd 7e b0 67 ac 54 b5 53 f7 1d
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 6d 9f 20 08 57 ca 6c 3e 9c ac 52 4b d9 ac c9 2a

Testing cipher AES-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60

Testing cipher AES-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 b7 bf 3a 5d f4 39 89 dd 97 f0 fa 97 eb ce 2f 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 4f eb dc 67 40 d2 0b 3a c8 8f 6a d8 2a 4f b0 8d

Testing cipher AES-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e1 c6 56 30 5e d1 a7 a6 56 38 05 74 6f e0 3e dc
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 71 ab 47 a0 86 e8 6e ed f3 9d 1c 5b ba 97 c4 08

Testing cipher AES-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 41 63 5b e6 25 b4 8a fc 16 66 dd 42 a0 9d 96 e7
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 01 26 14 1d 67 f3 7b e8 53 8f 5a 8b e7 40 e4 84

Testing cipher AES-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60

Testing cipher AES-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 b7 bf 3a 5d f4 39 89 dd 97 f0 fa 97 eb ce 2f 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 4f eb dc 67 40 d2 0b 3a c8 8f 6a d8 2a 4f b0 8d

Testing cipher AES-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e1 c6 56 30 5e d1 a7 a6 56 38 05 74 6f e0 3e dc
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 71 ab 47 a0 86 e8 6e ed f3 9d 1c 5b ba 97 c4 08

Testing cipher AES-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 41 63 5b e6 25 b4 8a fc 16 66 dd 42 a0 9d 96 e7
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 01 26 14 1d 67 f3 7b e8 53 8f 5a 8b e7 40 e4 84

Testing cipher AES-128-CTR(encrypt)
Key
0000 ae 68 52 f8 12 10 67 cc 4b f7 a5 76 55 77 f3 9e
IV
0000 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01
Plaintext
0000 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
Ciphertext
0000 e4 09 5d 4f b7 a7 b3 79 2d 61 75 a3 26 13 11 b8

Testing cipher AES-128-CTR(encrypt)
Key
0000 7e 24 06 78 17 fa e0 d7 43 d6 ce 1f 32 53 91 63
IV
0000 00 6c b6 db c0 54 3b 59 da 48 d9 0b 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Ciphertext
0000 51 04 a1 06 16 8a 72 d9 79 0d 41 ee 8e da d3 88
0010 eb 2e 1e fc 46 da 57 c8 fc e6 30 df 91 41 be 28

Testing cipher AES-128-CTR(encrypt)
Key
0000 76 91 be 03 5e 50 20 a8 ac 6e 61 85 29 f9 a0 dc
IV
0000 00 e0 01 7b 27 77 7f 3f 4a 17 86 f0 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23
Ciphertext
0000 c1 cf 48 a8 9f 2f fd d9 cf 46 52 e9 ef db 72 d7
0010 45 40 a4 2b de 6d 78 36 d5 9a 5c ea ae f3 10 53
0020 25 b2 07 2f

Testing cipher AES-192-CTR(encrypt)
Key
0000 16 af 5b 14 5f c9 f5 79 c1 75 f9 3e 3b fb 0e ed
0010 86 3d 06 cc fd b7 85 15
IV
0000 00 00 00 48 36 73 3c 14 7d 6d 93 cb 00 00 00 01
Plaintext
0000 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
Ciphertext
0000 4b 55 38 4f e2 59 c9 c8 4e 79 35 a0 03 cb e9 28

Testing cipher AES-192-CTR(encrypt)
Key
0000 7c 5c b2 40 1b 3d c3 3c 19 e7 34 08 19 e0 f6 9c
0010 67 8c 3d b8 e6 f6 a9 1a
IV
0000 00 96 b0 3b 02 0c 6e ad c2 cb 50 0d 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Ciphertext
0000 45 32 43 fc 60 9b 23 32 7e df aa fa 71 31 cd 9f
0010 84 90 70 1c 5a d4 a7 9c fc 1f e0 ff 42 f4 fb 00

Testing cipher AES-192-CTR(encrypt)
Key
0000 02 bf 39 1e e8 ec b1 59 b9 59 61 7b 09 65 27 9b
0010 f5 9b 60 a7 86 d3 e0 fe
IV
0000 00 07 bd fd 5c bd 60 27 8d cc 09 12 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23
Ciphertext
0000 96 89 3f c5 5e 5c 72 2f 54 0b 7d d1 dd f7 e7 58
0010 d2 88 bc 95 c6 91 65 88 45 36 c8 11 66 2f 21 88
0020 ab ee 09 35

Testing cipher AES-256-CTR(encrypt)
Key
0000 77 6b ef f2 85 1d b0 6f 4c 8a 05 42 c8 69 6f 6c
0010 6a 81 af 1e ec 96 b4 d3 7f c1 d6 89 e6 c1 c1 04
IV
0000 00 00 00 60 db 56 72 c9 7a a8 f0 b2 00 00 00 01
Plaintext
0000 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
Ciphertext
0000 14 5a d0 1d bf 82 4e c7 56 08 63 dc 71 e3 e0 c0

Testing cipher AES-256-CTR(encrypt)
Key
0000 f6 d6 6d 6b d5 2d 59 bb 07 96 36 58 79 ef f8 86
0010 c6 6d d5 1a 5b 6a 99 74 4b 50 59 0c 87 a2 38 84
IV
0000 00 fa ac 24 c1 58 5e f1 5a 43 d8 75 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Ciphertext
0000 f0 5e 23 1b 38 94 61 2c 49 ee 00 0b 80 4e b2 a9
0010 b8 30 6b 50 8f 83 9d 6a 55 30 83 1d 93 44 af 1c

Testing cipher AES-256-CTR(encrypt)
Key
0000 ff 7a 61 7c e6 91 48 e4 f1 72 6e 2f 43 58 1d e2
0010 aa 62 d9 f8 05 53 2e df f1 ee d6 87 fb 54 15 3d
IV
0000 00 1c c5 b7 51 a5 1d 70 a1 c1 11 48 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23
Ciphertext
0000 eb 6c 52 82 1d 0b bb f7 ce 75 94 46 2a ca 4f aa
0010 b4 07 df 86 65 69 fd 07 f4 8c c0 b5 83 d6 07 1f
0020 1e c0 e6 b8

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00
Ciphertext
0000 8c a6 4d e9 c1 b1 23 a7

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 ff ff ff ff ff ff ff ff
Plaintext
0000 ff ff ff ff ff ff ff ff
Ciphertext
0000 73 59 b2 16 3e 4e dc 58

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 30 00 00 00 00 00 00 00
Plaintext
0000 10 00 00 00 00 00 00 01
Ciphertext
0000 95 8e 6e 62 7a 05 55 7b

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 11 11 11 11 11 11 11 11
Plaintext
0000 11 11 11 11 11 11 11 11
Ciphertext
0000 f4 03 79 ab 9e 0e c5 33

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef
Plaintext
0000 11 11 11 11 11 11 11 11
Ciphertext
0000 17 66 8d fc 72 92 53 2d

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 11 11 11 11 11 11 11 11
Plaintext
0000 01 23 45 67 89 ab cd ef
Ciphertext
0000 8a 5a e1 f8 1a b8 f2 dd

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 fe dc ba 98 76 54 32 10
Plaintext
0000 01 23 45 67 89 ab cd ef
Ciphertext
0000 ed 39 d9 50 fa 74 bc c4

Testing cipher DESX-CBC(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef f1 e0 d3 c2 b5 a4 97 86
0010 fe dc ba 98 76 54 32 10
IV
0000 fe dc ba 98 76 54 32 10
Plaintext
0000 37 36 35 34 33 32 31 20 4e 6f 77 20 69 73 20 74
0010 68 65 20 74 69 6d 65 20 66 6f 72 20 00 00 00 00
Ciphertext
0000 84 6b 29 14 85 1e 9a 29 54 73 2f 8a a0 a6 11 c1
0010 15 cd c2 d7 95 1b 10 53 a6 3c 5e 03 b2 1a a3 c4

Testing cipher DES-EDE3-CBC(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef f1 e0 d3 c2 b5 a4 97 86
0010 fe dc ba 98 76 54 32 10
IV
0000 fe dc ba 98 76 54 32 10
Plaintext
0000 37 36 35 34 33 32 31 20 4e 6f 77 20 69 73 20 74
0010 68 65 20 74 69 6d 65 20 66 6f 72 20 00 00 00 00
Ciphertext
0000 3f e3 01 c9 62 ac 01 d0 22 13 76 3c 1c bd 4c dc
0010 79 96 57 c0 64 ec f5 d4 1c 67 38 12 cf de 96 75

Testing cipher RC4(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
Plaintext
0000 01 23 45 67 89 ab cd ef
Ciphertext
0000 75 b7 87 80 99 e0 c5 96

Testing cipher RC4(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
Plaintext
0000 00 00 00 00 00 00 00 00
Ciphertext
0000 74 94 c2 e7 10 4b 08 79

Testing cipher RC4(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00
Ciphertext
0000 de 18 89 41 a3 37 5d 3a

Testing cipher RC4(encrypt/decrypt)
Key
0000 ef 01 23 45 ef 01 23 45 ef 01 23 45 ef 01 23 45
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00
Ciphertext
0000 d6 a1 41 a7 ec 3c 38 df bd 61 5a 11 62 e1 c7 ba
0010 36 b6 78 58

Testing cipher RC4(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
Plaintext
0000 12 34 56 78 9a bc de f0 12 34 56 78 9a bc de f0
0010 12 34 56 78 9a bc de f0 12 34 56 78
Ciphertext
0000 66 a0 94 9f 8a f7 d6 89 1f 7f 83 2b a8 33 c0 0c
0010 89 2e be 30 14 3c e2 87 40 01 1e cf

Testing cipher RC4(encrypt/decrypt)
Key
0000 ef 01 23 45 ef 01 23 45 ef 01 23 45 ef 01 23 45
Plaintext
0000 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 d6 a1 41 a7 ec 3c 38 df bd 61

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Plaintext
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Ciphertext
0000 67 67 31 38 54 96 69 73 08 57 06 56 48 ea be 43

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
0010 00 11 22 33 44 55 66 77
Plaintext
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Ciphertext
0000 b4 99 34 01 b3 e9 96 f8 4e e5 ce e7 d7 9b 09 b9

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
0010 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Plaintext
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Ciphertext
0000 9a cc 23 7d ff 16 d7 6c 20 ef 7c 91 9e 3a 75 09

Testing cipher CAMELLIA-128-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 77 cf 41 20 67 af 82 70 61 35 29 14 99 19 54 6f

Testing cipher CAMELLIA-192-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 b2 2f 3c 36 b7 2d 31 32 9e ee 8a dd c2 90 6c 68

Testing cipher CAMELLIA-256-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 2e df 1f 34 18 d5 3b 88 84 1f c8 98 5f b1 ec f2

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 43 2f c5 dc d6 28 11 5b 7c 38 8d 77 0b 27 0c 96

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 0b e1 f1 40 23 78 2a 22 e8 38 4c 5a bb 7f ab 2b

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 a0 a1 ab cd 18 93 ab 6f e0 fe 5b 65 df 5f 86 36

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 e6 19 25 e0 d5 df aa 9b b2 9f 81 5b 30 76 e5 1a

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cc cc 6c 4e 13 8b 45 84 85 14 d4 8d 0d 34 39 d3

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 57 13 c6 2c 14 b2 ec 0f 83 93 b6 af d6 f5 78 5a

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 b4 0e d2 b6 0e b5 4d 09 d0 30 cf 51 1f ee f3 66

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 90 9d bd 95 79 90 96 74 8c b2 73 57 e7 3e 1d 26

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 be fd 21 9b 11 2f a0 00 98 91 9c d1 01 c9 cc fa

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 c9 1d 3a 8f 1a ea 08 a9 38 6c f4 b6 6c 01 69 ea

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 a6 23 d7 11 dc 5f 25 a5 1b b8 a8 0d 56 39 7d 28

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 79 60 10 9f b6 dc 42 94 7f cf e5 9e a3 c5 eb 6b

Testing cipher CAMELLIA-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 16 07 cf 49 4b 36 bb f0 0d ae b0 b5 03 c8 31 ab

Testing cipher CAMELLIA-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 16 07 cf 49 4b 36 bb f0 0d ae b0 b5 03 c8 31 ab
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 a2 f2 cf 67 16 29 ef 78 40 c5 a5 df b5 07 48 87

Testing cipher CAMELLIA-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a2 f2 cf 67 16 29 ef 78 40 c5 a5 df b5 07 48 87
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 0f 06 16 50 08 cf 8b 8b 5a 63 58 63 62 54 3e 54

Testing cipher CAMELLIA-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 36 a8 4c da fd 5f 9a 85 ad a0 f0 a9 93 d6 d5 77
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 74 c6 42 68 cd b8 b8 fa f5 b3 4e 8a f3 73 29 80

Testing cipher CAMELLIA-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 2a 48 30 ab 5a c4 a1 a2 40 59 55 fd 21 95 cf 93

Testing cipher CAMELLIA-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 2a 48 30 ab 5a c4 a1 a2 40 59 55 fd 21 95 cf 93
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 5d 5a 86 9b d1 4c e5 42 64 f8 92 a6 dd 2e c3 d5

Testing cipher CAMELLIA-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 5d 5a 86 9b d1 4c e5 42 64 f8 92 a6 dd 2e c3 d5
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 37 d3 59 c3 34 98 36 d8 84 e3 10 ad df 68 c4 49

Testing cipher CAMELLIA-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 37 d3 59 c3 34 98 36 d8 84 e3 10 ad df 68 c4 49
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 01 fa aa 93 0b 4a b9 91 6e 96 68 e1 42 8c 6b 08

Testing cipher CAMELLIA-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 e6 cf a3 5f c0 2b 13 4a 4d 2c 0b 67 37 ac 3e da

Testing cipher CAMELLIA-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e6 cf a3 5f c0 2b 13 4a 4d 2c 0b 67 37 ac 3e da
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 36 cb eb 73 bd 50 4b 40 70 b1 b7 de 2b 21 eb 50

Testing cipher CAMELLIA-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 36 cb eb 73 bd 50 4b 40 70 b1 b7 de 2b 21 eb 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 e3 1a 60 55 29 7d 96 ca 33 30 cd f1 b1 86 0a 83

Testing cipher CAMELLIA-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e3 1a 60 55 29 7d 96 ca 33 30 cd f1 b1 86 0a 83
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 5d 56 3f 6d 1c cc f2 36 05 1c 0c 5c 1c 58 f2 8f

Testing cipher CAMELLIA-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19

Testing cipher CAMELLIA-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 a5 3d 28 bb 82 df 74 11 03 ea 4f 92 1a 44 88 0b

Testing cipher CAMELLIA-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a5 3d 28 bb 82 df 74 11 03 ea 4f 92 1a 44 88 0b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 9c 21 57 a6 64 62 6d 1d ef 9e a4 20 fd e6 9b 96

Testing cipher CAMELLIA-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 9c 21 57 a6 64 62 6d 1d ef 9e a4 20 fd e6 9b 96
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 74 2a 25 f0 54 23 40 c7 ba ef 24 ca 84 82 bb 09

Testing cipher CAMELLIA-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19

Testing cipher CAMELLIA-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 a5 3d 28 bb 82 df 74 11 03 ea 4f 92 1a 44 88 0b

Testing cipher CAMELLIA-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a5 3d 28 bb 82 df 74 11 03 ea 4f 92 1a 44 88 0b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 9c 21 57 a6 64 62 6d 1d ef 9e a4 20 fd e6 9b 96

Testing cipher CAMELLIA-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 9c 21 57 a6 64 62 6d 1d ef 9e a4 20 fd e6 9b 96
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 74 2a 25 f0 54 23 40 c7 ba ef 24 ca 84 82 bb 09

Testing cipher CAMELLIA-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e

Testing cipher CAMELLIA-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 86 f8 49 16 27 90 6d 78 0c 7a 6d 46 ea 33 1f 98

Testing cipher CAMELLIA-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 86 f8 49 16 27 90 6d 78 0c 7a 6d 46 ea 33 1f 98
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 69 51 1c ce 59 4c f7 10 cb 98 bb 63 d7 22 1f 01

Testing cipher CAMELLIA-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 69 51 1c ce 59 4c f7 10 cb 98 bb 63 d7 22 1f 01
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 d5 b5 37 8a 3a be d5 58 03 f2 55 65 d8 90 7b 84

Testing cipher CAMELLIA-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e

Testing cipher CAMELLIA-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 86 f8 49 16 27 90 6d 78 0c 7a 6d 46 ea 33 1f 98

Testing cipher CAMELLIA-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 86 f8 49 16 27 90 6d 78 0c 7a 6d 46 ea 33 1f 98
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 69 51 1c ce 59 4c f7 10 cb 98 bb 63 d7 22 1f 01

Testing cipher CAMELLIA-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 69 51 1c ce 59 4c f7 10 cb 98 bb 63 d7 22 1f 01
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 d5 b5 37 8a 3a be d5 58 03 f2 55 65 d8 90 7b 84

Testing cipher CAMELLIA-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93

Testing cipher CAMELLIA-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 89 be db 4c cd d8 64 ea 11 ba 4c be 84 9b 5e 2b

Testing cipher CAMELLIA-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 89 be db 4c cd d8 64 ea 11 ba 4c be 84 9b 5e 2b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 55 5f c3 f3 4b dd 2d 54 c6 2d 9e 3b f3 38 c1 c4

Testing cipher CAMELLIA-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 55 5f c3 f3 4b dd 2d 54 c6 2d 9e 3b f3 38 c1 c4
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 59 53 ad ce 14 db 8c 7f 39 f1 bd 39 f3 59 bf fa

Testing cipher CAMELLIA-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93

Testing cipher CAMELLIA-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 89 be db 4c cd d8 64 ea 11 ba 4c be 84 9b 5e 2b

Testing cipher CAMELLIA-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 89 be db 4c cd d8 64 ea 11 ba 4c be 84 9b 5e 2b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 55 5f c3 f3 4b dd 2d 54 c6 2d 9e 3b f3 38 c1 c4

Testing cipher CAMELLIA-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 55 5f c3 f3 4b dd 2d 54 c6 2d 9e 3b f3 38 c1 c4
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 59 53 ad ce 14 db 8c 7f 39 f1 bd 39 f3 59 bf fa

Testing cipher CAMELLIA-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19

Testing cipher CAMELLIA-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 fe 67 cc 99 6d 32 b6 da 09 37 e9 9b af ec 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 25 62 3d b5 69 ca 51 e0 14 82 64 99 77 e2 8d 84

Testing cipher CAMELLIA-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 d9 a4 da da 08 92 23 9f 6b 8b 3d 76 80 e1 56 74
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 c7 76 63 4a 60 72 9d c6 57 d1 2b 9f ca 80 1e 98

Testing cipher CAMELLIA-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a7 88 19 58 3f 03 08 e7 a6 bf 36 b1 38 6a bf 23
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 d7 76 37 9b e0 e5 08 25 e6 81 da 1a 4c 98 0e 8e

Testing cipher CAMELLIA-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19

Testing cipher CAMELLIA-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 fe 67 cc 99 6d 32 b6 da 09 37 e9 9b af ec 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 25 62 3d b5 69 ca 51 e0 14 82 64 99 77 e2 8d 84

Testing cipher CAMELLIA-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 d9 a4 da da 08 92 23 9f 6b 8b 3d 76 80 e1 56 74
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 c7 76 63 4a 60 72 9d c6 57 d1 2b 9f ca 80 1e 98

Testing cipher CAMELLIA-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a7 88 19 58 3f 03 08 e7 a6 bf 36 b1 38 6a bf 23
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 d7 76 37 9b e0 e5 08 25 e6 81 da 1a 4c 98 0e 8e

Testing cipher CAMELLIA-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e

Testing cipher CAMELLIA-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 a6 09 b3 8d f3 b1 13 3d dd ff 27 18 ba 09 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 8e ce b7 d0 35 0d 72 c7 f7 85 62 ae bd f9 93 39

Testing cipher CAMELLIA-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 bd d6 2d bb b9 70 08 46 c5 3b 50 7f 54 46 96 f0

Testing cipher CAMELLIA-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 bd 52 86 ac 63 aa bd 7e b0 67 ac 54 b5 53 f7 1d
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 e2 80 14 e0 46 b8 02 f3 85 c4 c2 e1 3e ad 4a 72

Testing cipher CAMELLIA-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e

Testing cipher CAMELLIA-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 a6 09 b3 8d f3 b1 13 3d dd ff 27 18 ba 09 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 8e ce b7 d0 35 0d 72 c7 f7 85 62 ae bd f9 93 39

Testing cipher CAMELLIA-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 bd d6 2d bb b9 70 08 46 c5 3b 50 7f 54 46 96 f0

Testing cipher CAMELLIA-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 bd 52 86 ac 63 aa bd 7e b0 67 ac 54 b5 53 f7 1d
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 e2 80 14 e0 46 b8 02 f3 85 c4 c2 e1 3e ad 4a 72

Testing cipher CAMELLIA-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93

Testing cipher CAMELLIA-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 b7 bf 3a 5d f4 39 89 dd 97 f0 fa 97 eb ce 2f 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 12 7a d9 7e 8e 39 94 e4 82 00 27 d7 ba 10 93 68

Testing cipher CAMELLIA-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e1 c6 56 30 5e d1 a7 a6 56 38 05 74 6f e0 3e dc
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 6b ff 62 65 a6 a6 b7 a5 35 bc 65 a8 0b 17 21 4e

Testing cipher CAMELLIA-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 41 63 5b e6 25 b4 8a fc 16 66 dd 42 a0 9d 96 e7
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 0a 4a 04 04 e2 6a a7 8a 27 cb 27 1e 8b f3 cf 20

Testing cipher CAMELLIA-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93

Testing cipher CAMELLIA-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 b7 bf 3a 5d f4 39 89 dd 97 f0 fa 97 eb ce 2f 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 12 7a d9 7e 8e 39 94 e4 82 00 27 d7 ba 10 93 68

Testing cipher CAMELLIA-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e1 c6 56 30 5e d1 a7 a6 56 38 05 74 6f e0 3e dc
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 6b ff 62 65 a6 a6 b7 a5 35 bc 65 a8 0b 17 21 4e

Testing cipher CAMELLIA-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 41 63 5b e6 25 b4 8a fc 16 66 dd 42 a0 9d 96 e7
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 0a 4a 04 04 e2 6a a7 8a 27 cb 27 1e 8b f3 cf 20

Testing cipher SEED-ECB(decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Ciphertext
0000 5e ba c6 e0 05 4e 16 68 19 af f1 cc 6d 34 6c db

Testing cipher SEED-ECB(decrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 c1 1f 22 f2 01 40 50 50 84 48 35 97 e4 37 0f 43

Testing cipher SEED-ECB(decrypt)
Key
0000 47 06 48 08 51 e6 1b e8 5d 74 bf b3 fd 95 61 85
Plaintext
0000 83 a2 f8 a2 88 64 1f b9 a4 e9 a5 cc 2f 13 1c 7d
Ciphertext
0000 ee 54 d1 3e bc ae 70 6d 22 6b c3 14 2c d4 0d 4a

Testing cipher SEED-ECB(decrypt)
Key
0000 28 db c3 bc 49 ff d8 7d cf a5 09 b1 1d 42 2b e7
Plaintext
0000 b4 1e 6b e2 eb a8 4a 14 8e 2e ed 84 59 3c 5e c7
Ciphertext
0000 9b 9b 7b fc d1 81 3c b9 5d 0b 36 18 f4 0f 51 22

Testing cipher SEED-ECB(encrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Ciphertext
0000 5e ba c6 e0 05 4e 16 68 19 af f1 cc 6d 34 6c db

Testing cipher SEED-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 c1 1f 22 f2 01 40 50 50 84 48 35 97 e4 37 0f 43

Testing cipher SEED-ECB(encrypt)
Key
0000 47 06 48 08 51 e6 1b e8 5d 74 bf b3 fd 95 61 85
Plaintext
0000 83 a2 f8 a2 88 64 1f b9 a4 e9 a5 cc 2f 13 1c 7d
Ciphertext
0000 ee 54 d1 3e bc ae 70 6d 22 6b c3 14 2c d4 0d 4a

Testing cipher SEED-ECB(encrypt)
Key
0000 28 db c3 bc 49 ff d8 7d cf a5 09 b1 1d 42 2b e7
Plaintext
0000 b4 1e 6b e2 eb a8 4a 14 8e 2e ed 84 59 3c 5e c7
Ciphertext
0000 9b 9b 7b fc d1 81 3c b9 5d 0b 36 18 f4 0f 51 22

../util/shlib_wrap.sh ./evp_extra_test
PASS
test SSL protocol
../util/shlib_wrap.sh ./ssltest -test_cipherlist
testing SSLv3 cipher list order: ok
testing TLSv1 cipher list order: ok
Testing cipherlist order only. Ignoring all other options.
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffc1516bb40 a cert? 0x0x119d990
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffc1516bb20 a cert? 0x0x11a0b40
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140539174127248:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 2048 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 2048 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140477087860368:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 2048 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
Testing a lot of proxy conditions.
Some of them may turn out being invalid, which is fine.
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffcde2f9430 a cert? 0x0x21461d0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffcde2f9410 a cert? 0x0x20e49a0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140196467725968:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139875935770256:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'B' proved invalid
ERROR in CLIENT
140632504727184:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
139642822665872:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fff2a1a2f70 a cert? 0x0x28551d0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fff2a1a2f50 a cert? 0x0x27f3360
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140258176808592:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140164923119248:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
140582625785488:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffe2fe39f00 a cert? 0x0x123d1d0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffe2fe39ee0 a cert? 0x0x1244350
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139642107557520:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139707185882768:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
140657973368464:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffe15e906b0 a cert? 0x0x153d1d0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffe15e90690 a cert? 0x0x14db9a0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139884016535184:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140560057333392:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = C
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = none
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
140678201783952:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = C
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = none
Proxy rights check with condition 'B' proved invalid
ERROR in CLIENT
140659907544720:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = C
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = none
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
140428004042384:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = C
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = none
Proxy rights check with condition 'A|B&!C' proved invalid
ERROR in CLIENT
140287156762256:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
140259515877008:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffeffcaaec0 a cert? 0x0x1c3e1d0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffeffcaaea0 a cert? 0x0x1bdc9a0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139911614260880:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140412873279120:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
140112326878864:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffd8238c390 a cert? 0x0xc1a1d0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffd8238c370 a cert? 0x0xc20610
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140369805096592:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139948107998864:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.03 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
Testing a lot of proxy conditions.
Some of them may turn out being invalid, which is fine.
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
139900653676176:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'B' proved invalid
ERROR in CLIENT
140427133802128:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
140609384519312:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = A
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = A
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'A|B&!C' proved invalid
ERROR in CLIENT
140698622686864:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
140028653110928:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffe561c6b40 a cert? 0x0x264fc30
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffe561c6b20 a cert? 0x0x2655ce0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140615115171472:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139666792023696:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
140541441119888:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffdce1a3030 a cert? 0x0x1d432e0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffdce1a3010 a cert? 0x0x1d48a40
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140425962473104:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139821225215632:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = C
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = none
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
140701186844304:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = C
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = none
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'B' proved invalid
ERROR in CLIENT
140595078731408:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = C
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = none
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
139661855184528:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = C
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = none
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'A|B&!C' proved invalid
ERROR in CLIENT
139825120863888:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
140362999002768:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffe1aa333f0 a cert? 0x0x177c040
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffe1aa333d0 a cert? 0x0x1781d00
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140442862937744:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
140157029721744:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.03 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
140357949294224:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed:s3_clnt.c:1185:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
   NONE
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 
ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
   NONE
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
   NONE
client authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
   NONE
client authentication
server authentication
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
   Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
   Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
   Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair 
and app verify
Available compression methods:
   NONE
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffc09cd4b40 a cert? 0x0x1e442e0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7ffc09cd4b20 a cert? 0x0x1e49be0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 
1/CN=Proxy 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139947954886288:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
   NONE
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
   NONE
ERROR in CLIENT
139991464150672:error:14082174:SSL 
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3424:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
   NONE
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
   NONE
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 
bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.01 s
test tls1 with PSK
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
   NONE
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
rsa
Setting up TSA test directory...
Creating CA for TSA tests...
Creating a new CA for the TSA tests...
Generating a 1024 bit RSA private key
..........++++++
..................++++++
writing new private key to 'tsacakey.pem'
-----
Creating tsa_cert1.pem TSA server cert...
Generating a 1024 bit RSA private key
...........................................++++++
................................++++++
writing new private key to 'tsa_key1.pem'
-----
Using extension tsa_cert
Signature ok
subject=/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Getting CA Private Key
Creating tsa_cert2.pem non-TSA server cert...
Generating a 1024 bit RSA private key
.....................++++++
............++++++
writing new private key to 'tsa_key2.pem'
-----
Using extension non_tsa_cert
Signature ok
subject=/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa2
Getting CA Private Key
Creating req1.req time stamp request for file testtsa...
Using configuration from ../CAtsa.cnf
Printing req1.req...
Using configuration from ../CAtsa.cnf
Version: 1
Hash Algorithm: sha1
Message data:
     0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd 
HD.v&..].g.;....
     0010 - c5 b8 6e 67                                       ..ng
Policy OID: tsa_policy1
Nonce: 0xAA95A869B6AE8177
Certificate required: yes
Extensions:
Generating valid response for req1.req...
Using configuration from ../CAtsa.cnf
Warning: could not open file ./tsa_serial for reading, using serial 
number: 1
Response has been generated.
Printing response...
Using configuration from ../CAtsa.cnf
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: tsa_policy1
Hash Algorithm: sha1
Message data:
     0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd 
HD.v&..].g.;....
     0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x01
Time stamp: Jul 14 18:43:16 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: 0xAA95A869B6AE8177
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Verifying valid response...
Verification: OK
Verification: OK
Verifying valid token...
Using configuration from ../CAtsa.cnf
Verification: OK
Verification: OK
Creating req2.req time stamp request for file testtsa...
Using configuration from ../CAtsa.cnf
Printing req2.req...
Using configuration from ../CAtsa.cnf
Version: 1
Hash Algorithm: sha1
Message data:
     0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd 
HD.v&..].g.;....
     0010 - c5 b8 6e 67                                       ..ng
Policy OID: tsa_policy2
Nonce: unspecified
Certificate required: no
Extensions:
Generating valid response for req2.req...
Using configuration from ../CAtsa.cnf
Response has been generated.
Checking '-token_in' and '-token_out' options with '-reply'...
Using configuration from ../CAtsa.cnf
Using configuration from ../CAtsa.cnf
Using configuration from ../CAtsa.cnf
Version: 1
Policy OID: tsa_policy2
Hash Algorithm: sha1
Message data:
     0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd 
HD.v&..].g.;....
     0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x02
Time stamp: Jul 14 18:43:17 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: unspecified
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Using configuration from ../CAtsa.cnf
Version: 1
Policy OID: tsa_policy2
Hash Algorithm: sha1
Message data:
     0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd 
HD.v&..].g.;....
     0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x02
Time stamp: Jul 14 18:43:17 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: unspecified
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Using configuration from ../CAtsa.cnf
Response has been generated.
Version: 1
Policy OID: tsa_policy2
Hash Algorithm: sha1
Message data:
     0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd 
HD.v&..].g.;....
     0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x03
Time stamp: Jul 14 18:43:17 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: unspecified
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Printing response...
Using configuration from ../CAtsa.cnf
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: tsa_policy2
Hash Algorithm: sha1
Message data:
     0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd 
HD.v&..].g.;....
     0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x02
Time stamp: Jul 14 18:43:17 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: unspecified
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Verifying valid response...
Verification: OK
Verification: OK
Verifying response against wrong request, it should fail...
140494450083472:error:2F06606C:time stamp 
routines:TS_CHECK_POLICY:policy mismatch:ts_rsp_verify.c:586:
Verification: FAILED
Ok
Verifying response against wrong request, it should fail...
140122979145360:error:2F06606C:time stamp 
routines:TS_CHECK_POLICY:policy mismatch:ts_rsp_verify.c:586:
Verification: FAILED
Ok
Creating req3.req time stamp request for file CAtsa.cnf...
Using configuration from ../CAtsa.cnf
Printing req3.req...
Using configuration from ../CAtsa.cnf
Version: 1
Hash Algorithm: sha1
Message data:
     0000 - 1c b9 52 2b 5c 27 b0 ae-83 b8 b2 c1 6d 82 1a 7f 
..R+\'......m...
     0010 - db 63 45 e7                                       .cE.
Policy OID: unspecified
Nonce: unspecified
Certificate required: no
Extensions:
Verifying response against wrong request, it should fail...
140682870920848:error:2F064067:time stamp 
routines:TS_CHECK_IMPRINTS:message imprint mismatch:ts_rsp_verify.c:672:
Verification: FAILED
Ok
Cleaning up...
Test IGE mode
../util/shlib_wrap.sh ./igetest
Test JPAKE
../util/shlib_wrap.sh ./jpaketest
No JPAKE support
Test SRP
../util/shlib_wrap.sh ./srptest
Keys mismatch
N = 
EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
g = 2
Salt = 9A1CE5DB093828269E6A31C2F1FA43C743A0B757
Verifier = 
9BF374298F5EF524075D4A9B9DB4513344CF832375FBA1D55C16ADE0FC5427DD9A1FCA2A8DD343FC8D610F42492F7713E1DFADB0426957E4416B76FCD2A26A70FA6A516AF0D536E26595F6EC4D79900E1FF2CA168B480D9552F55CC9FD074628C308E4CC975F13AD99296A96564807D26588711960584DFCD0FBC45C4A31B0CC
b = C78D1F9A93E3D9BB07FE8A1E57725A401B8EB1528D193194AF7B301D1B6C9374
B = 
2E101EDC43CC395381E0036E6620019472EE88847FC530731093B6F1768939DE94418FB8C856E303659ED00338E66F1A0E51644008E0C6341BF8C68BF9CE3D0965899BEC0EAD4037F74A32F437E90271CE888EDE1178B1A605DFBDAC18D9BB029705FB5F5384C678793E78129D44AB5314C6D61DCECFE4FE3BD53FCA2665AD36
a = CD8FDA5B5E7CDA2060BFA41A57D1D27EBA5C43B6B513696F65423B88564967CD
A = 
281464A7D2E9A013DFEE5B0D0B396F2C2F1106407D939965ACF4F485CDF64E40107B33CB046730C33E260F8E337FF87F1F0A549FA6AB1B8EC285F451345D6870924F69A2E5FBBEF77CE0905B356AB4C68D56865FE8DF523569B4B27BC36FF303EEE28073D832C8BB3D86C30211F17E4D434A8A2DBD360877C2AED94202E6A356
Client's key = 
8377D3A38BDBE73D587E53F989BC948AC047FA33BED7CADA25FF250C09ED7CFCBF3CBFDB5ECE212B60E3F936B42172CDD60CF4CB55CE56D62C88453E5061C7824C8817C65B1D83CF642B13AEA9E5407D758568DCFA2C701340747864715D6CFB60A6C1B3947E0DECECE6735AD91FCF3864CE1651C546162AE4D405BE647BD1AE
Server's key = 
AD626861C652ABE7CDCFBEE4F151C0984F4932294F06B7943529C97A565B1BA412C053A91EFC5182AA68A78ACF9C8A2BD51C78EAD3FF706B864ABA308015723D91B17B0D27E371A49E30EE5452AF077BBAFB7EEA2B836D0C869C9765B03AB402E54DF49BC39373841909DE31922C422E456293500C5263EDD359F87BB53FD7CA
N = 
EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
g = 2
Salt = E183D33D2D4428BDE2B118570A2FCD043CA5AD0
Verifier = 
904582BA67DC3DE8A4CB2AD1852CF61A1F1AB0154F6C0956C9348A40E0D0682B81E04CDE88B6823AAB682CEA62A0FD9B4AB1B63FFF1A6F763BACB4C4444273B453F773239B2DF4F2044DF1D86D39DF90E293107883D0C71DE6B2DB10BF474240038071FB5A90E0DC6303F47E00141BEFBD2534BA7508C359331758665FF50F6F
b = 1D4A77BA99CB7E4A54E69DC019C282773ED48B4C77CE01EE9FED5DCE9C7741F
B = 
274CB8EA483390549FB1EAEA26CFF0B0D1209BCE6C28823C256CB0791EFDF3AEC4AC484EE91C66B8A88ABA395E2DA36ADC554CE9271AA39B02E9ECF05544887646DD4B8A943FC72D6925657F8E2BA74A3D431C22C142F01A376D831EC9CF91F1CB479E69364519AA73DB42A14B18F52ECEBA476213AD69FA8C1D50ABBB84DCC3
a = D48E7B142C87350D38B5DEEB329F9EA4079D740D698A65255F5EF2CC11D8D07F
A = 
7AA79C07C1F381FE50C94073E089F481D712E3823AE225CFF5EBFCDA8C65B41954D997B8A6D2D4C84FD06B61A013C72D3A453FD6DE56788D4B49F308FFFAFD21EAF89460EC3687A2359DCC2D5F7C1B743E33087BCCF4A815FE04F85925414B38CC0997C718659CC5F23D81B4F9C2BEF8A903201D237EDE63E2B68E7826A1CEB9
Client's key = 
B9BF037921178FFF8471019421D495FDA8D04AD5D73F24B81F3824BFD54463753E6B3F9AB566580592E85ED2FC0FF7ED7E690AC85F6A7918F8EE5BFBAD1F90B8AB7D52825835CEEA71C3FDA516E4792FC02876DE6C6C1CB126153F4D8AC48B8FB121EBF03D14854EA0440F914BDA63776A6A118BA209904B0916C0996CC0362B
Server's key = 
B9BF037921178FFF8471019421D495FDA8D04AD5D73F24B81F3824BFD54463753E6B3F9AB566580592E85ED2FC0FF7ED7E690AC85F6A7918F8EE5BFBAD1F90B8AB7D52825835CEEA71C3FDA516E4792FC02876DE6C6C1CB126153F4D8AC48B8FB121EBF03D14854EA0440F914BDA63776A6A118BA209904B0916C0996CC0362B
CMS consistency test
/usr/bin/perl cms-test.pl
CMS => PKCS#7 compatibility tests
signed content DER format, RSA key: verify error
Makefile:329: recipe for target 'test_cms' failed
make[2]: *** [test_cms] Error 1
make[2]: Leaving directory 
'/home/imothep/T?l?chargements/openssl-1.0.1t/test'
Makefile:460: recipe for target 'tests' failed
make[1]: *** [tests] Error 2
make[1]: Leaving directory '/home/imothep/T?l?chargements/openssl-1.0.1t'
-----------------------------------------------------------------------------


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4616
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed Jul 20 21:45:33 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Wed, 20 Jul 2016 21:45:33 +0000
Subject: [openssl-dev] [openssl.org #4616] bug report
In-Reply-To: <4309841f-5f7b-cfd4-8cda-5b4b5629fca5@riseup.net>
References: <RT-Ticket-4616@openssl.org>
 <4309841f-5f7b-cfd4-8cda-5b4b5629fca5@riseup.net>
Message-ID: <rt-4.0.19-17767-1469051133-85.4616-6-0@openssl.org>

1.0.1 is an old release and only getting security updates. please move to 1.0.2
or 'master'

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4616
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed Jul 20 21:45:53 2016
From: rt at openssl.org (Carl Byington via RT)
Date: Wed, 20 Jul 2016 21:45:53 +0000
Subject: [openssl-dev] [openssl.org #4619] compile errors with no-srp
In-Reply-To: <1469047703.9402.17.camel@ns.five-ten-sg.com>
References: <RT-Ticket-4619@openssl.org>
 <1469047703.9402.17.camel@ns.five-ten-sg.com>
Message-ID: <rt-4.0.19-17767-1469051153-1094.4619-21-0@openssl.org>

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

Source from master on github,

./Configure --prefix=/usr/local --openssldir=/usr/local/etc/pki/tls
enable-ec_nistp_64_gcc_128 zlib sctp enable-camellia enable-seed enable-
rfc3779 enable-cms enable-md2 no-mdc2 no-rc5 no-ec2m no-gost no-srp -Wa,
- --noexecstack -DPURIFY enable-deprecated shared linux-x86_64
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
    no-asan         [default]  OPENSSL_NO_ASAN (skip dir)
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
    no-crypto-mdebug-backtrace [default]
OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
    no-ec2m         [option]   OPENSSL_NO_EC2M (skip dir)
    no-egd          [default]  OPENSSL_NO_EGD (skip dir)
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL (skip dir)
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
    no-gost         [option]   OPENSSL_NO_GOST (skip dir)
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
    no-mdc2         [option]   OPENSSL_NO_MDC2 (skip dir)
    no-rc5          [option]   OPENSSL_NO_RC5 (skip dir)
    no-srp          [option]   OPENSSL_NO_SRP (skip dir)
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
    no-ssl3         [default]  OPENSSL_NO_SSL3 (skip dir)
    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
    no-ubsan        [default]  OPENSSL_NO_UBSAN (skip dir)
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
    no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip
dir)
    no-zlib-dynamic [default]


make depend
make all
....

gcc  -I. -Iinclude -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG
- -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
- -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
- -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
- -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
- -DPOLY1305_ASM -DPURIFY -DOPENSSLDIR="\"/usr/local/etc/pki/tls\""
- -DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wall -O3 -pthread
-m64
- -DL_ENDIAN  -Wa,--noexecstack -fPIC -MMD -MF ssl/t1_ext.d.tmp -MT
ssl/t1_ext.o -c -o ssl/t1_ext.o ssl/t1_ext.c
ssl/statem/statem_clnt.c: In function 'tls_construct_cke_srp':
ssl/statem/statem_clnt.c:2455: error: 'SSL' has no member named
'srp_ctx'
ssl/statem/statem_clnt.c:2457: error: 'SSL' has no member named
'srp_ctx'
ssl/statem/statem_clnt.c:2459: error: 'SSL' has no member named
'srp_ctx'
ssl/statem/statem_clnt.c:2465: error: 'SSL_SESSION' has no member named
'srp_username'
ssl/statem/statem_clnt.c:2466: error: 'SSL_SESSION' has no member named
'srp_username'
ssl/statem/statem_clnt.c:2466: error: 'SSL' has no member named
'srp_ctx'
ssl/statem/statem_clnt.c:2467: error: 'SSL_SESSION' has no member named
'srp_username'
make[2]: *** [ssl/statem/statem_clnt.o] Error 1


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAleP41cACgkQL6j7milTFsHYBACdGbcmT0xsANaKhaFz7pGNoU2F
R3cAnif6xhWLvWjTUMPkNfv/+rYV7yMc
=NEzZ
-----END PGP SIGNATURE-----



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4619
Please log in as guest with password guest if prompted


From ghudson at mit.edu  Wed Jul 20 23:30:52 2016
From: ghudson at mit.edu (Greg Hudson)
Date: Wed, 20 Jul 2016 19:30:52 -0400
Subject: [openssl-dev] Overlapping regions check
Message-ID: <x7d37n3ga4z.fsf@equal-rites.mit.edu>

With current OpenSSL master, the krb5 PKINIT tests are getting an
assertion failure which I can't attribute to our code (stack trace at
the end).  It appears that EVP_EncryptUpdate() now insists on
non-overlapping regions, but bio_enc.c:enc_read() relies on being able
to decrypt an overlapping region.

The calling code is:

    i = BIO_read(tmpmem, buf, sizeof(buf));

where buf is a local array of size 4096 which is not used for any other
purpose (i.e. has nothing to do with the tmpmem bio).

Program received signal SIGABRT, Aborted.
0x00007ffff710ec37 in __GI_raise (sig=sig at entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) back
#0  0x00007ffff710ec37 in __GI_raise (sig=sig at entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff7112028 in __GI_abort () at abort.c:89
#2  0x00007ffff7107bf6 in __assert_fail_base (
    fmt=0x7ffff72583b8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion at entry=0x7ffff618fc78 "!condition", 
    file=file at entry=0x7ffff618fb90 "crypto/evp/evp_enc.c", 
    line=line at entry=290, 
    function=function at entry=0x7ffff618fd10 <__PRETTY_FUNCTION__.16890>
    "is_partially_overlapping") at assert.c:92
#3  0x00007ffff7107ca2 in __GI___assert_fail (
    assertion=0x7ffff618fc78 "!condition", 
    file=0x7ffff618fb90 "crypto/evp/evp_enc.c", line=290, 
    function=0x7ffff618fd10 <__PRETTY_FUNCTION__.16890>
    "is_partially_overlapping") at assert.c:101
#4  0x00007ffff60d32f2 in is_partially_overlapping (ptr1=0x6286a0, 
    ptr2=0x6286e0, len=1728) at crypto/evp/evp_enc.c:290
#5  0x00007ffff60d33c6 in EVP_EncryptUpdate (ctx=0x624230, out=0x6286a0 "", 
    outl=0x628680, 
    in=0x6286e0 [edited out],
    inl=1728)
    at crypto/evp/evp_enc.c:315
#6  0x00007ffff60d3989 in EVP_DecryptUpdate (ctx=0x624230, out=0x6286a0 "", 
    outl=0x628680, 
    in=0x6286e0 [edited out],
    inl=1728)
    at crypto/evp/evp_enc.c:454
#7  0x00007ffff60d30d5 in EVP_CipherUpdate (ctx=0x624230, out=0x6286a0 "", 
    outl=0x628680, 
    in=0x6286e0 [edited out],
    inl=1728)
    at crypto/evp/evp_enc.c:211
#8  0x00007ffff60c5a95 in enc_read (b=0x63d7e0, 
    out=0x7fffffffbc00 "@\274\377\377\377\177", outl=4096)
    at crypto/evp/bio_enc.c:161
#9  0x00007ffff6034b3f in BIO_read (b=0x63d7e0, out=0x7fffffffbc00, outl=4096)
    at crypto/bio/bio_lib.c:213
#10 0x00007ffff5977ec5 in pkcs7_decrypt (context=0x608150, 
    id_cryptoctx=0x621c60, p7=0x63c990, data=0x63bbe0)
    at
    ../../../../src/plugins/preauth/pkinit/pkinit_crypto_openssl.c:5887
[rest of stack trace elided]


From rt at openssl.org  Thu Jul 21 07:14:37 2016
From: rt at openssl.org (Page, Greg via RT)
Date: Thu, 21 Jul 2016 07:14:37 +0000
Subject: [openssl-dev] [openssl.org #4620] OCSP_basic_verify()
	question/comment
In-Reply-To: <BY2PR0601MB1656075C3BA493672F46DBC698080@BY2PR0601MB1656.namprd06.prod.outlook.com>
References: <RT-Ticket-4620@openssl.org>
 <BY2PR0601MB1656075C3BA493672F46DBC698080@BY2PR0601MB1656.namprd06.prod.outlook.com>
Message-ID: <rt-4.0.19-17534-1469085277-143.4620-21-0@openssl.org>

Hello!


I have been using openssl to get OCSP status for a certificate and I ran across an interesting case.


OCSP responses do not seem to include the intermediate certificates so they have to be acquired in other ways.   I have been doing this and adding them to the certificate stack handed to OCSP_basic_verify().


However, I have noticed that these certificates are not used in creating a certificate chain back to a root CA because they are not added to the X509_STORE_CTX that is sent to X509_verify_cert() and X509_STORE_CTX_get1_chain().


I am relatively new to this so I may be incorrect; however, it seems to me that the certificates in the cert argument should be added to the X509_STORE_CTX.


What are your thoughts?


Thanks,

Greg


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4620
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu Jul 21 08:18:31 2016
From: rt at openssl.org (Mattias Ellert via RT)
Date: Thu, 21 Jul 2016 08:18:31 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <1469089098.27555.7.camel@physics.uu.se>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
 <1468236301.32623.23.camel@physics.uu.se>
 <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
 <rt-4.0.19-17766-1469027648-1476.4602-6-0@openssl.org>
 <1469089098.27555.7.camel@physics.uu.se>
Message-ID: <rt-4.0.19-17767-1469089110-579.4602-6-0@openssl.org>

ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
> > 
> > I guess having a more restrictive accessor that only sets the
> > EXFLAG_PROXY bit could work. I suggested the more general solution of
> > having set/clear accessors for arbitrary flags since it was - well
> > more
> > general.
> 
> So let me ask this in a different manner, does OpenSSL 1.1 still not set the
> EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
> worth a bug report of its own.
> 
> --
> Richard Levitte
> levitte at openssl.org
> 

The answer to this is related to Mischa's reply, which unfortunately
was only sent to the Debian BTS and not the the OpenSSL RT. I quote it
below. As indicated in the answer, setting the?EXFLAG_PROXY allows
handling non-RFC proxies in OpenSSL.

m?n 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> Hi Richard, Mattias, others,
>?
> I agree with you that it would be nice if OpenSSL could figure out
> itself whether a cert needs to be treated as a proxy, but currently that
> doesn't work reliably as far as I know.
> The flag is certainly needed in the case of non-RFC3820 proxies, also
> known as legacy proxies. Unfortunately these are still very widely used
> (majority of the proxies actually) and hence our code must be able to
> handle them correctly.
>?
> Best wishes,
> Mischa Sall?
>?

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5032 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160721/f884ffdf/attachment.bin>

From rt at openssl.org  Thu Jul 21 08:27:15 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Thu, 21 Jul 2016 08:27:15 +0000
Subject: [openssl-dev] [openssl.org #4620] OCSP_basic_verify()
	question/comment
In-Reply-To: <24f80813da6b4564b50f2e697d14879f@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4620@openssl.org>
 <BY2PR0601MB1656075C3BA493672F46DBC698080@BY2PR0601MB1656.namprd06.prod.outlook.com>
 <rt-4.0.19-17534-1469085277-143.4620-21-0@openssl.org>
 <24f80813da6b4564b50f2e697d14879f@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-17766-1469089635-262.4620-6-0@openssl.org>


> OCSP responses do not seem to include the intermediate certificates so they
> have to be acquired in other ways.   I have been doing this and adding them
> to the certificate stack handed to OCSP_basic_verify().

Perhaps adding them to X509_STORE or STORE_CTX directly?

> I am relatively new to this so I may be incorrect; however, it seems to me
> that the certificates in the cert argument should be added to the
> X509_STORE_CTX.

If you need to add certificates to validate a chain, it seems safer to explicitly add them to the store, not implicitly.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4620
Please log in as guest with password guest if prompted


From haegele at teamviewer.com  Thu Jul 21 08:56:19 2016
From: haegele at teamviewer.com (=?iso-8859-15?Q?Christian_H=E4gele?=)
Date: Thu, 21 Jul 2016 10:56:19 +0200
Subject: [openssl-dev] 1.1 release being delayed
References: <a756150f2fcb4c72a521893c3787557f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160624212857.GA1420@w1.fi> <576DB3B9.1080206@openssl.org>
Message-ID: <op.ykx0gds47t4xvc@dev-10.int.rossmanith.com>

Am 25.06.2016, 00:27 Uhr, schrieb Matt Caswell <matt at openssl.org>:

> The current thinking is Thursday 7th July, although that is not set in
> stone as it depends on what happens between now and then. We don't
> currently have any plans for a beta 3, although again that could change.

7th of July was 2 weeks ago.
Are there any news on the updated release-plans? I did not find any  
updated information on this.

Regards,

Christian


From matt at openssl.org  Thu Jul 21 09:43:20 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 21 Jul 2016 10:43:20 +0100
Subject: [openssl-dev] 1.1 release being delayed
In-Reply-To: <op.ykx0gds47t4xvc@dev-10.int.rossmanith.com>
References: <a756150f2fcb4c72a521893c3787557f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160624212857.GA1420@w1.fi> <576DB3B9.1080206@openssl.org>
 <op.ykx0gds47t4xvc@dev-10.int.rossmanith.com>
Message-ID: <e4685b44-f4ac-0543-3df2-ad135caf496b@openssl.org>



On 21/07/16 09:56, Christian H?gele wrote:
> Am 25.06.2016, 00:27 Uhr, schrieb Matt Caswell <matt at openssl.org>:
> 
>> The current thinking is Thursday 7th July, although that is not set in
>> stone as it depends on what happens between now and then. We don't
>> currently have any plans for a beta 3, although again that could change.
> 
> 7th of July was 2 weeks ago.
> Are there any news on the updated release-plans? I did not find any
> updated information on this.

We still have a number of issues that need to be resolved before we can
release. We don't yet have a new date agreed. The best I can offer at
the moment is "August". We're all working hard to try and bring it in as
soon as possible.

Matt


From rt at openssl.org  Thu Jul 21 09:51:41 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 21 Jul 2016 09:51:41 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-17767-1469089110-1621.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
 <1468236301.32623.23.camel@physics.uu.se>
 <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
 <rt-4.0.19-17766-1469027648-1476.4602-6-0@openssl.org>
 <1469089098.27555.7.camel@physics.uu.se>
 <rt-4.0.19-17767-1469089110-1621.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1469094700-124.4602-6-0@openssl.org>

On Thu Jul 21 08:18:30 2016, mattias.ellert at physics.uu.se wrote:
> ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> > On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
> > >
> > > I guess having a more restrictive accessor that only sets the
> > > EXFLAG_PROXY bit could work. I suggested the more general solution
> > > of
> > > having set/clear accessors for arbitrary flags since it was - well
> > > more
> > > general.
> >
> > So let me ask this in a different manner, does OpenSSL 1.1 still not
> > set the
> > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > That may be
> > worth a bug report of its own.
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> >
>
> The answer to this is related to Mischa's reply, which unfortunately
> was only sent to the Debian BTS and not the the OpenSSL RT. I quote it
> below. As indicated in the answer, setting the EXFLAG_PROXY allows
> handling non-RFC proxies in OpenSSL.
>
> m?n 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > Hi Richard, Mattias, others,
> >
> > I agree with you that it would be nice if OpenSSL could figure out
> > itself whether a cert needs to be treated as a proxy, but currently
> > that
> > doesn't work reliably as far as I know.
> > The flag is certainly needed in the case of non-RFC3820 proxies, also
> > known as legacy proxies. Unfortunately these are still very widely
> > used
> > (majority of the proxies actually) and hence our code must be able to
> > handle them correctly.
> >
> > Best wishes,
> > Mischa Sall?
> >

Ok... From looking at the voms code that was linked to earlier, I can see that
legacy proxy certs are recognised by an older OID (called PROXYCERTINFO_V3 in
the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions in that
version, whether they are critical or not and so on, that I can reach? Or is
the OID the only actual difference? If it's easy enough (and it currently does
look quite easy), I can certainly see adding some code in OpenSSL to recognise
those...

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu Jul 21 10:11:16 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Thu, 21 Jul 2016 10:11:16 +0000
Subject: [openssl-dev] [Pkg-openssl-devel] Bug#829272: Fwd: [openssl.org
	#4602] Missing accessors
In-Reply-To: <20160721101103.GA4472@roeckx.be>
References: <RT-Ticket-4602@openssl.org>
 <1468239408.725473.14210.nullmailer@rt.openssl.org>
 <20160711125305.GG22683@nikhef.nl> <20160721101103.GA4472@roeckx.be>
Message-ID: <rt-4.0.19-17767-1469095876-690.4602-6-0@openssl.org>

On Mon, Jul 11, 2016 at 02:53:05PM +0200, Mischa Salle wrote:
> Hi Richard, Mattias, others,
> 
> I agree with you that it would be nice if OpenSSL could figure out
> itself whether a cert needs to be treated as a proxy, but currently that
> doesn't work reliably as far as I know.
> The flag is certainly needed in the case of non-RFC3820 proxies, also
> known as legacy proxies. Unfortunately these are still very widely used
> (majority of the proxies actually) and hence our code must be able to
> handle them correctly.

Is there a way to recoginize those non-RFC3820 proxies?



Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From dwmw2 at infradead.org  Thu Jul 21 16:36:28 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 21 Jul 2016 17:36:28 +0100
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-17534-1469027484-648.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467926949-1421.4602-7-0@openssl.org>
 <rt-4.0.19-1832-1467958101-1276.4602-7-0@openssl.org>
 <1468242505.32623.44.camel@physics.uu.se>
 <rt-4.0.19-20845-1468242512-1164.4602-6-0@openssl.org>
 <1468244056.4158.241.camel@infradead.org>
 <rt-4.0.19-20844-1468245862-1610.4602-6-0@openssl.org>
 <rt-4.0.19-17534-1469027484-648.4602-6-0@openssl.org>
Message-ID: <1469118988.120686.179.camel@infradead.org>

(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +0000, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, dwmw2 at infradead.org wrote:
> > I was using store.get_issuer() in OpenConnect too, because I need to
> > manually build the trust chain to include it on the wire ? because
> > even today the server might *still* suffer RT#1942 and fail to trust
> > our client cert unless we help it by providing the *right* chain.
> 
> Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

> > I've worked around the lack of access to get_issuer() by doing a dummy
> > call to X509_verify_cert(), throwing away its result and then hoping
> > that we have something useful in store.chain (which we *can* still
> > access). That seems to work but I'm not stunningly happy with it; if
> > we
> > can have an accessor I'd much rather go back to doing it the old way.
> > 
> > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> > (in workaround_openssl_certchain_bug() in the hunk around line 1306)
> 
> https://github.com/openssl/openssl/pull/1294 currently provides a setter for
> get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160721/da992d3e/attachment.bin>

From rt at openssl.org  Thu Jul 21 16:36:53 2016
From: rt at openssl.org (David Woodhouse via RT)
Date: Thu, 21 Jul 2016 16:36:53 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <1469118988.120686.179.camel@infradead.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467926949-1421.4602-7-0@openssl.org>
 <rt-4.0.19-1832-1467958101-1276.4602-7-0@openssl.org>
 <1468242505.32623.44.camel@physics.uu.se>
 <rt-4.0.19-20845-1468242512-1164.4602-6-0@openssl.org>
 <1468244056.4158.241.camel@infradead.org>
 <rt-4.0.19-20844-1468245862-1610.4602-6-0@openssl.org>
 <rt-4.0.19-17534-1469027484-648.4602-6-0@openssl.org>
 <1469118988.120686.179.camel@infradead.org>
Message-ID: <rt-4.0.19-17767-1469119013-1530.4602-6-0@openssl.org>

(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +0000, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, dwmw2 at infradead.org wrote:
> > I was using store.get_issuer() in OpenConnect too, because I need to
> > manually build the trust chain to include it on the wire ? because
> > even today the server might *still* suffer RT#1942 and fail to trust
> > our client cert unless we help it by providing the *right* chain.
> 
> Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

> > I've worked around the lack of access to get_issuer() by doing a dummy
> > call to X509_verify_cert(), throwing away its result and then hoping
> > that we have something useful in store.chain (which we *can* still
> > access). That seems to work but I'm not stunningly happy with it; if
> > we
> > can have an accessor I'd much rather go back to doing it the old way.
> > 
> > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> > (in workaround_openssl_certchain_bug() in the hunk around line 1306)
> 
> https://github.com/openssl/openssl/pull/1294 currently provides a setter for
> get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

-- 
dwmw2
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160721/391aaa4c/attachment-0001.bin>

From rt at openssl.org  Thu Jul 21 23:37:56 2016
From: rt at openssl.org (Brian Smith via RT)
Date: Thu, 21 Jul 2016 23:37:56 +0000
Subject: [openssl-dev] [openssl.org #4621] BUG: nistz256 point addition
	check for a = +/-b doesn't work for unreduced values
In-Reply-To: <CAFewVt7ChKiRiCqDTEc2Nxw823Ketk-P4nm9B8GiR0GdoZmX8g@mail.gmail.com>
References: <RT-Ticket-4621@openssl.org>
 <CAFewVt7ChKiRiCqDTEc2Nxw823Ketk-P4nm9B8GiR0GdoZmX8g@mail.gmail.com>
Message-ID: <rt-4.0.19-17766-1469144276-106.4621-21-0@openssl.org>

I verified with the authors of the nistz256 code that all the arithmetic is
done mod P256 (P), but the results might be unreduced if they are less than
2**256. Thus, all the arithmetic must handle the cases where its inputs are
in the range [0, 2**256 - 1], not just [0, P). And, it must deal with the
cases where some values have multiple representations. For example, the
value 0 can be represented as either 0 or P + 0, 1 can be represented
either as 1 or as P + 1, etc.

The nistz256 code contains code that looks like this:

  if (is_equal(U1, U2) && !in1infty && !in2infty) {
    if (is_equal(S1, S2)) {
        ...
    }
  }

This code only works for values that have one representation; it doesn't
work for all values. For example, consider U1 == 1, U2 = P + 1. Then,
is_equal(U1, U2) returns false, but in fact U1 == U2 (mod P). Thus, we
should run the code for the exceptional case (doubling or setting to the
point at infinity), but actually we just keep going with a normal addition.

You can see that the code in ecp_nistp256 and ecp_nistp224 such as
`is_zero` handles this correctly by considering both representations of 0:
0 and P + 0.

To fix this, a constant-time conditional subtraction of P should be done on
U1 and U2, and a conditional subtraction should also be done on S1 and S2.
I discussed this with some other people familiar with the code and they
agree that this seems to be a good way to do it.

Note again that it is possible for the value 0 to be represented as either
0 or as P + 0. This brings into question whether is_zero is correct,
because it doesn't consider P to be zero. Here there was some disagreement
about whether it is necessary to check for P. I personally think that it is
safer to check for both 0 and P like the nistp256 code does, because I it
is hard to make a proof that the values cannot be P.

Not also again that the value 1 can be represented as 1 or as P + 1. Thus,
the statement Z_is_one = is_one(...); appears to also be wrong, or at least
not obviously correct.

Finally, as I mentioned on the mailing list, it seems the function is_zero
is missing a comparison of the last limb in the 32-bit case.

Unfortunately, I don't have any test vectors for triggering any bugs that
would serve as a basis of regression tests; these were found from reading
the code.

Cheers,
Brian
-- 
https://briansmith.org/

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4621
Please log in as guest with password guest if prompted


From brian at briansmith.org  Fri Jul 22 00:46:52 2016
From: brian at briansmith.org (Brian Smith)
Date: Thu, 21 Jul 2016 14:46:52 -1000
Subject: [openssl-dev] [openssl.org #4621] BUG: nistz256 point addition
 check for a = +/-b doesn't work for unreduced values
In-Reply-To: <rt-4.0.19-17766-1469144276-106.4621-21-0@openssl.org>
References: <RT-Ticket-4621@openssl.org>
 <CAFewVt7ChKiRiCqDTEc2Nxw823Ketk-P4nm9B8GiR0GdoZmX8g@mail.gmail.com>
 <rt-4.0.19-17766-1469144276-106.4621-21-0@openssl.org>
Message-ID: <CAFewVt5EPmPaDcUc7vZ70Hu_7724hEPPr+R3aGnhqhAhKUN2Dg@mail.gmail.com>

Brian Smith via RT <rt at openssl.org> wrote:

> Finally, as I mentioned on the mailing list, it seems the function is_zero
> is missing a comparison of the last limb in the 32-bit case.
>

And of course, when I said "is_zero" I meant "is_one":
https://github.com/openssl/openssl/blob/aa6bb1352b1026b20a23b49da4efdcf171926eb0/crypto/ec/ecp_nistz256.c#L226



-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160721/fd5855bd/attachment.html>

From rt at openssl.org  Fri Jul 22 00:47:05 2016
From: rt at openssl.org (Brian Smith via RT)
Date: Fri, 22 Jul 2016 00:47:05 +0000
Subject: [openssl-dev] [openssl.org #4621] BUG: nistz256 point addition
	check for a = +/-b doesn't work for unreduced values
In-Reply-To: <CAFewVt5EPmPaDcUc7vZ70Hu_7724hEPPr+R3aGnhqhAhKUN2Dg@mail.gmail.com>
References: <RT-Ticket-4621@openssl.org>
 <CAFewVt7ChKiRiCqDTEc2Nxw823Ketk-P4nm9B8GiR0GdoZmX8g@mail.gmail.com>
 <rt-4.0.19-17766-1469144276-106.4621-21-0@openssl.org>
 <CAFewVt5EPmPaDcUc7vZ70Hu_7724hEPPr+R3aGnhqhAhKUN2Dg@mail.gmail.com>
Message-ID: <rt-4.0.19-17766-1469148425-1404.4621-6-0@openssl.org>

Brian Smith via RT <rt at openssl.org> wrote:

> Finally, as I mentioned on the mailing list, it seems the function is_zero
> is missing a comparison of the last limb in the 32-bit case.
>

And of course, when I said "is_zero" I meant "is_one":
https://github.com/openssl/openssl/blob/aa6bb1352b1026b20a23b49da4efdcf171926eb0/crypto/ec/ecp_nistz256.c#L226



-- 
https://briansmith.org/

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4621
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 07:38:25 2016
From: rt at openssl.org (Mattias Ellert via RT)
Date: Fri, 22 Jul 2016 07:38:25 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <1469173093.18243.26.camel@physics.uu.se>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
 <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
 <rt-4.0.19-17766-1469027648-1476.4602-6-0@openssl.org>
 <1469089098.27555.7.camel@physics.uu.se>
 <rt-4.0.19-17767-1469089110-1621.4602-6-0@openssl.org>
 <rt-4.0.19-17766-1469094700-124.4602-6-0@openssl.org>
 <1469173093.18243.26.camel@physics.uu.se>
Message-ID: <rt-4.0.19-17767-1469173105-382.4602-6-0@openssl.org>

tor 2016-07-21 klockan 09:51 +0000 skrev Richard Levitte via RT:
> On Thu Jul 21 08:18:30 2016, mattias.ellert at physics.uu.se wrote:
> > 
> > ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> > > 
> > > On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
> > > > 
> > > > 
> > > > I guess having a more restrictive accessor that only sets the
> > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > solution
> > > > of
> > > > having set/clear accessors for arbitrary flags since it was -
> > > > well
> > > > more
> > > > general.
> > > 
> > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > not
> > > set the
> > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > That may be
> > > worth a bug report of its own.
> > > 
> > > --
> > > Richard Levitte
> > > levitte at openssl.org
> > > 
> > 
> > The answer to this is related to Mischa's reply, which
> > unfortunately
> > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > it
> > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > handling non-RFC proxies in OpenSSL.
> > 
> > m?n 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > 
> > > Hi Richard, Mattias, others,
> > > 
> > > I agree with you that it would be nice if OpenSSL could figure
> > > out
> > > itself whether a cert needs to be treated as a proxy, but
> > > currently
> > > that
> > > doesn't work reliably as far as I know.
> > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > also
> > > known as legacy proxies. Unfortunately these are still very
> > > widely
> > > used
> > > (majority of the proxies actually) and hence our code must be
> > > able to
> > > handle them correctly.
> > > 
> > > Best wishes,
> > > Mischa Sall?
> > > 
> 
> Ok... From looking at the voms code that was linked to earlier, I can
> see that
> legacy proxy certs are recognised by an older OID (called
> PROXYCERTINFO_V3 in
> the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> in that
> version, whether they are critical or not and so on, that I can
> reach? Or is
> the OID the only actual difference? If it's easy enough (and it
> currently does
> look quite easy), I can certainly see adding some code in OpenSSL to
> recognise
> those...
> 
> --
> Richard Levitte
> levitte at openssl.org

As far as I know there are three different kinds of proxies, usually
called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
respectively.

For example see "grid-proxy-init -help":

? ? -draft????????????????????Creates a draft (GSI-3) proxy
????-old??????????????????????Creates a legacy globus proxy
????-rfc??????????????????????Creates a RFC 3820 compliant proxy

The really tricky one is the old legacy version 2 proxy I think.

	Mattias

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5032 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160722/5f54166a/attachment.bin>

From rt at openssl.org  Fri Jul 22 09:53:15 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 22 Jul 2016 09:53:15 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-17767-1469173105-38.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org>
 <1468236301.32623.23.camel@physics.uu.se>
 <rt-4.0.19-20845-1468236875-604.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1469181195-1173.4602-6-0@openssl.org>

On Fri Jul 22 07:38:25 2016, mattias.ellert at physics.uu.se wrote:
> tor 2016-07-21 klockan 09:51 +0000 skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ellert at physics.uu.se wrote:
> > >
> > > ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> > > >
> > > > On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
> > > > >
> > > > >
> > > > > I guess having a more restrictive accessor that only sets the
> > > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > > solution
> > > > > of
> > > > > having set/clear accessors for arbitrary flags since it was -
> > > > > well
> > > > > more
> > > > > general.
> > > >
> > > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > > not
> > > > set the
> > > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > > That may be
> > > > worth a bug report of its own.
> > > >
> > > > --
> > > > Richard Levitte
> > > > levitte at openssl.org
> > > >
> > >
> > > The answer to this is related to Mischa's reply, which
> > > unfortunately
> > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > > it
> > > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > > handling non-RFC proxies in OpenSSL.
> > >
> > > m?n 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > >
> > > > Hi Richard, Mattias, others,
> > > >
> > > > I agree with you that it would be nice if OpenSSL could figure
> > > > out
> > > > itself whether a cert needs to be treated as a proxy, but
> > > > currently
> > > > that
> > > > doesn't work reliably as far as I know.
> > > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > > also
> > > > known as legacy proxies. Unfortunately these are still very
> > > > widely
> > > > used
> > > > (majority of the proxies actually) and hence our code must be
> > > > able to
> > > > handle them correctly.
> > > >
> > > > Best wishes,
> > > > Mischa Sall?
> > > >
> >
> > Ok... From looking at the voms code that was linked to earlier, I can
> > see that
> > legacy proxy certs are recognised by an older OID (called
> > PROXYCERTINFO_V3 in
> > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> > in that
> > version, whether they are critical or not and so on, that I can
> > reach? Or is
> > the OID the only actual difference? If it's easy enough (and it
> > currently does
> > look quite easy), I can certainly see adding some code in OpenSSL to
> > recognise
> > those...
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
>
> As far as I know there are three different kinds of proxies, usually
> called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
> respectively.
>
> For example see "grid-proxy-init -help":
>
> -draft Creates a draft (GSI-3) proxy
> -old Creates a legacy globus proxy
> -rfc Creates a RFC 3820 compliant proxy
>
> The really tricky one is the old legacy version 2 proxy I think.

Ok, so after doing quite a bit of searching, I found some references to GT2
(old) in a 3.0 document:

http://toolkit.globus.org/toolkit/docs/3.0/gsi/GSI-message-specification-02.doc
(section 5)

As I understand it, the GT2 format is a simple EE cert, with just two
differences:

1. the issuer is also a EE (so it has the basic constraint CA set to false)...
or it's another GT2 proxy, which amounts to the same thing.
2. the subject name is the issuer name plus an appended 'CN=Proxy' or
'CN=LimitedProxy'

Good so far?

My main problem here is GT3 (draft) proxy certs. If I look at
https://tools.ietf.org/html/draft-ietf-pkix-proxy-10, they look exactly the
same as RFC3820 proxy certs, down to the extension OID. If I look at a really
old draft
(http://sigillum.pl/upload/pdf/Internet%20X.509%20Public%20Key%20Infrastructure.%20Proxy%20Certificate%20Profile.pdf),
the difference is *wild*, and if look at a random shell script
(https://www.nikhef.nl/~janjust/proxy-verify/genproxy) I found while searching
for OID 1.3.6.1.4.1.3536.1.222, I find a third variant that has a slightly
different proycertinfo extension...

Btw, this should really become a new ticket, along the lines of "OpenSSL
doesn't recognise earlier proxy certs".

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 11:32:27 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 22 Jul 2016 11:32:27 +0000
Subject: [openssl-dev] [openssl.org #4622]
References: <RT-Ticket-4622@openssl.org>
Message-ID: <rt-4.0.19-17766-1469187147-0.4622-21-0@openssl.org>

Ticket derived from RT4602 (missing accessors)

Reports have been coming in that in the grid world, there are two pre-rfc3820
forms of proxy certs still being used.

Old (pre-draft) format: Looks like a regular EE cert, but has been issued by
another EE (real or proxy), and can be recognised by having the issuer name as
subject name with an extra CN appended, either 'CN=proxy' or 'CN=limited proxy'

draft format: looks like a RFC3820 proxy cert, but uses OID
1.3.6.1.4.1.3536.1.222 instead of the RFC3820 OID for proxyCertInfo.

Cc to Mattias and Mischa, who have provided valuable info on this issue in
RT4602. Guys, I hope it was ok to add you. If not, please tell me and I'll take
you off this ticket.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4622
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 11:35:11 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 22 Jul 2016 11:35:11 +0000
Subject: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise
	pre-rfc3820 proxy certs
In-Reply-To: <rt-4.0.19-17766-1469187147-1577.4622-6-0@openssl.org>
References: <RT-Ticket-4622@openssl.org>
 <rt-4.0.19-17766-1469187147-1577.4622-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1469187311-129.4622-6-0@openssl.org>

Forgive me for being sloppy, I forgot to add a subject. Now added, it says what
the actual issue is.

On Fri Jul 22 11:32:27 2016, levitte wrote:
> Ticket derived from RT4602 (missing accessors)
>
> Reports have been coming in that in the grid world, there are two pre-
> rfc3820
> forms of proxy certs still being used.
>
> Old (pre-draft) format: Looks like a regular EE cert, but has been
> issued by
> another EE (real or proxy), and can be recognised by having the issuer
> name as
> subject name with an extra CN appended, either 'CN=proxy' or
> 'CN=limited proxy'
>
> draft format: looks like a RFC3820 proxy cert, but uses OID
> 1.3.6.1.4.1.3536.1.222 instead of the RFC3820 OID for proxyCertInfo.
>
> Cc to Mattias and Mischa, who have provided valuable info on this
> issue in
> RT4602. Guys, I hope it was ok to add you. If not, please tell me and
> I'll take
> you off this ticket.
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4622
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 11:36:32 2016
From: rt at openssl.org (msalle@nikhef.nl via RT)
Date: Fri, 22 Jul 2016 11:36:32 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160722085917.GA3253@nikhef.nl>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-30004-1467927624-96.4602-6-0@openssl.org>
 <20160707224211.GA19448@roeckx.be>
 <rt-4.0.19-17766-1469027648-1476.4602-6-0@openssl.org>
 <1469089098.27555.7.camel@physics.uu.se>
 <rt-4.0.19-17767-1469089110-1621.4602-6-0@openssl.org>
 <rt-4.0.19-17766-1469094700-124.4602-6-0@openssl.org>
 <1469173093.18243.26.camel@physics.uu.se> <20160722085917.GA3253@nikhef.nl>
Message-ID: <rt-4.0.19-17766-1469187392-1616.4602-6-0@openssl.org>

On Fri, Jul 22, 2016 at 09:38:13AM +0200, Mattias Ellert wrote:
> tor 2016-07-21 klockan 09:51 +0000 skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ellert at physics.uu.se wrote:
> > > 
> > > ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> > > > 
> > > > On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
> > > > > 
> > > > > 
> > > > > I guess having a more restrictive accessor that only sets the
> > > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > > solution
> > > > > of
> > > > > having set/clear accessors for arbitrary flags since it was -
> > > > > well
> > > > > more
> > > > > general.
> > > > 
> > > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > > not
> > > > set the
> > > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > > That may be
> > > > worth a bug report of its own.
> > > > 
> > > > --
> > > > Richard Levitte
> > > > levitte at openssl.org
> > > > 
> > > 
> > > The answer to this is related to Mischa's reply, which
> > > unfortunately
> > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > > it
> > > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > > handling non-RFC proxies in OpenSSL.
> > > 
> > > m?n 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > > 
> > > > Hi Richard, Mattias, others,
> > > > 
> > > > I agree with you that it would be nice if OpenSSL could figure
> > > > out
> > > > itself whether a cert needs to be treated as a proxy, but
> > > > currently
> > > > that
> > > > doesn't work reliably as far as I know.
> > > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > > also
> > > > known as legacy proxies. Unfortunately these are still very
> > > > widely
> > > > used
> > > > (majority of the proxies actually) and hence our code must be
> > > > able to
> > > > handle them correctly.
> > > > 
> > > > Best wishes,
> > > > Mischa Sall?
> > > > 
> > 
> > Ok... From looking at the voms code that was linked to earlier, I can
> > see that
> > legacy proxy certs are recognised by an older OID (called
> > PROXYCERTINFO_V3 in
> > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> > in that
> > version, whether they are critical or not and so on, that I can
> > reach? Or is
> > the OID the only actual difference? If it's easy enough (and it
> > currently does
> > look quite easy), I can certainly see adding some code in OpenSSL to
> > recognise
> > those...
> > 
> > --
> > Richard Levitte
> > levitte at openssl.org
> 
> As far as I know there are three different kinds of proxies, usually
> called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
> respectively.
> 
> For example see "grid-proxy-init -help":
> 
> ? ? -draft????????????????????Creates a draft (GSI-3) proxy
> ????-old??????????????????????Creates a legacy globus proxy
> ????-rfc??????????????????????Creates a RFC 3820 compliant proxy
> 
> The really tricky one is the old legacy version 2 proxy I think.

Hi,

there are 3 types of proxies, in chronological order:

- so called legacy proxies, which voms-proxy-init will call old and are
  also known as GT2 proxies.
  They have no special (critical) extension and can be recognized by:
    1) being signed by an end-entity cert (i.e. a non-CA)
    2) have the same subjectDN as the issuer with one extra CN RDN
       added, which can be either
	a) "CN=proxy" for a 'inherit all' proxy
	b) "CN=limited proxy" for a limited proxy (as in OID
	   1.3.6.1.4.1.3536.1.1.1.9)
  These are widely used and we have therefore code in many places to
  handle them.

- the draft RFC proxies, also known as GT3 proxies.
  They contain an extension 1.3.6.1.4.1.3536.1.222
  At least voms-proxy-init does not mark it as critical. They are
  rarely used. The ordering in the extension is different in the sense
  that they usually put the proxyPolicy before the proxyPathlength (when
  finite, i.e. present) inside the extension, but RFC-style extensions
  also occur. In openssl.cnf style a GT3 extension would be something
  like this:
    [ gt3_proxy ]
    keyUsage = critical,digitalSignature,keyEncipherment
    1.3.6.1.4.1.3536.1.222=critical,ASN1:SEQUENCE:gt3_seq_sect

    # For a proxy pathlength of 42, leave out field2 for inf.
    [ gt3_seq_sect ]
    field1 = SEQUENCE:normal_policy
    field2 = EXPLICIT:1C,INTEGER:42

    # similarly for limited policy
    [ normal_policy ]
    p1 = OID:1.3.6.1.5.5.7.21.1

- RFC3820 compliant proxies, also known as GT4 proxies.
  They contain the standard critical extension 1.3.6.1.5.5.7.1.14

The default for at least voms-proxy-init (both from the voms-clients2
and voms-clients3) is to make the GT2 proxies, and this is why they are
still very-widely used (I think vast majority of proxies).

    Mischa
-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3382 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160722/35166e5e/attachment.bin>

From rt at openssl.org  Fri Jul 22 12:52:18 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Fri, 22 Jul 2016 12:52:18 +0000
Subject: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise
	pre-rfc3820 proxy certs
In-Reply-To: <6c78a03f51c2499e8abff2ff07ba61ad@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4622@openssl.org>
 <rt-4.0.19-17766-1469187147-1577.4622-6-0@openssl.org>
 <rt-4.0.19-17766-1469187311-129.4622-6-0@openssl.org>
 <6c78a03f51c2499e8abff2ff07ba61ad@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-17766-1469191938-1132.4622-6-0@openssl.org>

And now, with subject clearly stated, I think we should not do this.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4622
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 12:59:46 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 22 Jul 2016 12:59:46 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange
	with X509_LOOKUP_add_dir
In-Reply-To: <rt-4.0.19-17534-1468967036-553.4615-6-0@openssl.org>
References: <RT-Ticket-4615@openssl.org>
 <CAKUCFqd0xa14SvQBJQH7gRbJq8sRVgz+2+TVFUceyaAHRGE9WQ@mail.gmail.com>
 <rt-4.0.19-17766-1468917078-1020.4615-6-0@openssl.org>
 <rt-4.0.19-17766-1468918031-309.4615-6-0@openssl.org>
 <rt-4.0.19-17534-1468967036-553.4615-6-0@openssl.org>
Message-ID: <rt-4.0.19-17766-1469192386-1069.4615-6-0@openssl.org>

On Tue Jul 19 22:23:56 2016, steve wrote:
>
> If there are multiple CRLs with the appropriate scope then the first
> one where
> the current time falls between lastUpdate and nextUpdate is used.
>
> It is possible to dynamically update CRLs but currently only the time
> criteria
> is used. So if the first one fails the time test the next is used.
> This isn't
> ideal and something relying on the most recent or the highest CRL
> number would
> be preferable.
>

Please try the attached patch. This should end up using the most recent CRL
instead of the first one it sees. I've done some checks and dynamic update
works with this change. Note that if you happen to have two CRLs with an
identical lastUpdate field (down to the second) then it will just use the first
CRL it encounters again. This shouldn't be a problem in practice.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: crl.pat
Type: application/octet-stream
Size: 1186 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160722/a1a24228/attachment.obj>

From rt at openssl.org  Fri Jul 22 13:38:02 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 22 Jul 2016 13:38:02 +0000
Subject: [openssl-dev] [openssl.org #4603] HMAC_Init_ex incompatible change
	(possibly doc bug)
In-Reply-To: <20160702111340.GC9192@roeckx.be>
References: <RT-Ticket-4603@openssl.org> <20160702111340.GC9192@roeckx.be>
Message-ID: <rt-4.0.19-17767-1469194682-1927.4603-6-0@openssl.org>

On Sat Jul 02 11:13:44 2016, kurt at roeckx.be wrote:
>
> /* If we are changing MD then we must have a key */
> if (md != NULL && md != ctx->md && (key == NULL || len < 0))
> return 0;
>
> That means contrary to the documentation, the existing salt isn't
> reused
> when the md argument is non-zero (and changes).
>

This is a bug in the documentation which has since been addressed. In general
you can't change the digest while retaining the same key because in some cases
the original key is no longer available, though in some cases it did work and
others it produced the wrong value. Now we're being stricter and preventing
digest change.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4603
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 14:01:57 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 22 Jul 2016 14:01:57 +0000
Subject: [openssl-dev] [openssl.org #4610] Incorrect handling of malformed
	Client Key Exchange messages for ECDHE_RSA key exchange
In-Reply-To: <3037581.h6leHmcXCy@pintsize.usersys.redhat.com>
References: <RT-Ticket-4610@openssl.org> <RT-Ticket-2777@openssl.org>
 <E4599F0406A786429EDBAE349D9FE67F0295B36B@PPOMSG2.QUANTUM.com>
 <rt-4.0.19-21188-1467060187-208.2777-6-0@openssl.org>
 <3037581.h6leHmcXCy@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-17766-1469196117-98.4610-6-0@openssl.org>

This has now been addressed in master and 1.0.2.

Thanks for the report,
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4610
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 14:09:12 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 22 Jul 2016 14:09:12 +0000
Subject: [openssl-dev] [openssl.org #4590] accessors without const return
	arguments
In-Reply-To: <576EF43A.7010104@roumenpetrov.info>
References: <RT-Ticket-4590@openssl.org> <576EF43A.7010104@roumenpetrov.info>
Message-ID: <rt-4.0.19-17766-1469196552-242.4590-6-0@openssl.org>

On Sat Jun 25 22:09:59 2016, openssl at roumenpetrov.info wrote:
>
> Above is reason the request to remove const from return argument of get0
> methods.
>

We had a discussion about this and the preference was to have get methods
retain const for various reasons.

Instead the DSA_SIG/ECDSA_SIG structures now no longer pre-allocate r/s so they
aren't immediately freed when you set them.

> The issue is not only for ECDSA but also for DSA_SIG and RSA, DSA, DH
> keys where situation is similar.
>

Do you have some examples of how this affects other structures? For RSA/DSA/DH
keys the fields are NULL initially unless I've missed something.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4590
Please log in as guest with password guest if prompted


From janjust at nikhef.nl  Fri Jul 22 14:10:45 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Fri, 22 Jul 2016 16:10:45 +0200
Subject: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise
 pre-rfc3820 proxy certs
In-Reply-To: <rt-4.0.19-17766-1469191938-1132.4622-6-0@openssl.org>
References: <RT-Ticket-4622@openssl.org>
 <rt-4.0.19-17766-1469187147-1577.4622-6-0@openssl.org>
 <rt-4.0.19-17766-1469187311-129.4622-6-0@openssl.org>
 <6c78a03f51c2499e8abff2ff07ba61ad@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-17766-1469191938-1132.4622-6-0@openssl.org>
Message-ID: <6106b2ad-a457-df2e-2ff2-627a8fc1ca64@nikhef.nl>

Hi Rich,

On 22/07/16 14:52, Salz, Rich via RT wrote:
> And now, with subject clearly stated, I think we should not do this.
>


the original question related to this ticket was the missing accessors 
in OpenSSL 1.1. I fully agree that OpenSSL should not add support for 
pre-RFC3820 proxy, but it should allow others to write code to support 
it. That's the way OpenSSL 0.9.x and 1.0.x did it: the Globus and Voms 
people added their own handlers to the OpenSSL callbacks in order to 
support GT2, GT3 and RFC3820 (aka GT4) proxies. With OpenSSL 1.1, some 
of these handlers/callbacks seem to have been removed.

If OpenSSL 1.1 does not allow this, then the existing grid codebase is 
"stuck" with OpenSSL 1.0.x until all users start using RFC3820 proxies. 
Again, I support the notion that people should have started using these 
back in 2008 but the reality is that we in "Grid land" are stuck with 
"legacy" proxies for some time. It would be a shame if we cannot use 
OpenSSL 1.1+ on the grid.

JM2CW,

JJK / Jan Just Keijser

PS I'm a co-worker of Mischa Salle


From levitte at openssl.org  Fri Jul 22 14:23:25 2016
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 22 Jul 2016 16:23:25 +0200 (CEST)
Subject: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise
 pre-rfc3820 proxy certs
In-Reply-To: <6106b2ad-a457-df2e-2ff2-627a8fc1ca64@nikhef.nl>
References: <6c78a03f51c2499e8abff2ff07ba61ad@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-17766-1469191938-1132.4622-6-0@openssl.org>
 <6106b2ad-a457-df2e-2ff2-627a8fc1ca64@nikhef.nl>
Message-ID: <20160722.162325.2128469790779353467.levitte@openssl.org>

In message <6106b2ad-a457-df2e-2ff2-627a8fc1ca64 at nikhef.nl> on Fri, 22 Jul 2016 16:10:45 +0200, Jan Just Keijser <janjust at nikhef.nl> said:

janjust> Hi Rich,
janjust> 
janjust> On 22/07/16 14:52, Salz, Rich via RT wrote:
janjust> > And now, with subject clearly stated, I think we should not do this.
janjust> >
janjust> 
janjust> 
janjust> the original question related to this ticket was the missing accessors
janjust> in OpenSSL 1.1. I fully agree that OpenSSL should not add support for
janjust> pre-RFC3820 proxy, but it should allow others to write code to support
janjust> it. That's the way OpenSSL 0.9.x and 1.0.x did it: the Globus and Voms
janjust> people added their own handlers to the OpenSSL callbacks in order to
janjust> support GT2, GT3 and RFC3820 (aka GT4) proxies. With OpenSSL 1.1, some
janjust> of these handlers/callbacks seem to have been removed.
janjust> 
janjust> If OpenSSL 1.1 does not allow this, then the existing grid codebase is
janjust> "stuck" with OpenSSL 1.0.x until all users start using RFC3820
janjust> proxies. Again, I support the notion that people should have started
janjust> using these back in 2008 but the reality is that we in "Grid land" are
janjust> stuck with "legacy" proxies for some time. It would be a shame if we
janjust> cannot use OpenSSL 1.1+ on the grid.

Ok,

I can't say that I quite agree, mostly because it means that
"everyone" will have to implement those same handled (I've had a look
at the globus, voms and canl code, and keep noticing copies of more or
less the exact same callback source in all of them).

But, I'm listening, and I've had some internal discussion around this.

There's already been discussions around accessor functions, and
https://github.com/openssl/openssl/pull/1294 covers quite a lot
(please have a look!  I get way too few comments), and what's primarly
needed outside of that is a way to set the EXFLAG_PROXY flag on a X509*.
Correct?  For function names, I'm thinking that something as easy as
X509_cache_proxy_flag(X509 *x)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Fri Jul 22 14:28:24 2016
From: rt at openssl.org (Hubert Kario via RT)
Date: Fri, 22 Jul 2016 14:28:24 +0000
Subject: [openssl-dev] [openssl.org #4511] s_server does not send Alert
	messages upon receiving malformed Client Key Exchange
	messages in DHE key exchange
In-Reply-To: <3247634.YoxCAktUDn@pintsize.usersys.redhat.com>
References: <RT-Ticket-4511@openssl.org>
 <1501337.2KOEEos4mI@pintsize.usersys.redhat.com>
 <rt-4.0.19-3086-1460726572-1523.4511-21-0@openssl.org>
 <3247634.YoxCAktUDn@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-17767-1469197704-843.4511-6-0@openssl.org>

On Friday, 15 April 2016 13:22:52 CEST Hubert Kario via RT wrote:
> Using either current 1.0.1 or 1.0.2 branch (7a433893a and 9676402c3a
> respectively) openssl s_server command does not send Alert message upon
> receiving a malformed or invalid Client Key Exchange message in DHE key
> exchange.
> 
> That applies to messages that are longer and shorter than needed as well
> as messages that include client key shares bigger than the prime selected
> by server.

the issue is still present in master 0ed26acce328ec16a3aa
 
Reproducer:
===========
(requires Python 2.6, 3.2 or later)
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
pushd .tlslite-ng
popd
ln -s .tlslite-ng/tlslite tlslite
popd
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt \
-nodes -batch -subj /CN=localhost openssl s_server -www -key localhost.key \
-cert localhost.crt
# in another terminal, same directory
PYTHONPATH=tlsfuzzer python
tlsfuzzer/scripts/test-dhe-rsa-key-exchange-with-bad-messages.py


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4511
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160722/36a04647/attachment.sig>

From rt at openssl.org  Fri Jul 22 14:56:11 2016
From: rt at openssl.org (Hubert Kario via RT)
Date: Fri, 22 Jul 2016 14:56:11 +0000
Subject: [openssl-dev] [openssl.org #4623] OpenSSL master regression in
	handling malformed Client Key Exchange messages in RSA key exchange
In-Reply-To: <1633197.q7QCyuLxU0@pintsize.usersys.redhat.com>
References: <RT-Ticket-4623@openssl.org> <RT-Ticket-4511@openssl.org>
 <1501337.2KOEEos4mI@pintsize.usersys.redhat.com>
 <rt-4.0.19-3086-1460726572-1523.4511-21-0@openssl.org>
 <1633197.q7QCyuLxU0@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-17767-1469199371-761.4623-21-0@openssl.org>

the issue is present in master 0ed26acce328ec16a3aa and looks to have been 
introduced in commit:

$ git bisect bad
5b8fa431ae8eb5a18ba913494119e394230d4b70 is the first bad commit
commit 5b8fa431ae8eb5a18ba913494119e394230d4b70
Author: David Benjamin <davidben at google.com>
Date:   Thu Jun 16 14:15:19 2016 -0400

    Make RSA key exchange code actually constant-time.
    
    Using RSA_PKCS1_PADDING with RSA_private_decrypt is inherently unsafe.
    The API requires writing output on success and touching the error queue
    on error. Thus, although the padding check itself is constant-time as of
    294d1e36c2495ff00e697c9ff622856d3114f14f, and the logic after the
    decryption in the SSL code is constant-time as of
    adb46dbc6dd7347750df2468c93e8c34bcb93a4b, the API boundary in the middle
    still leaks whether the padding check succeeded, giving us our
    much-loved Bleichenbacher padding oracle.
    
    Instead, PKCS#1 padding must be handled by the caller which uses
    RSA_NO_PADDING, in timing-sensitive code integrated with the
    Bleichenbacher mitigation. Removing PKCS#1 padding in constant time is
    actually much simpler when the expected length is a constant (and if
    it's not a constant, avoiding a padding oracle seems unlikely), so just
    do it inline.
    
    Signed-off-by: Kurt Roeckx <kurt at roeckx.be>
    Reviewed-by: Rich Salz <rsalz at openssl.org>
    
    GH: #1222

:040000 040000 bd98bdbeaeddbc22f8a37324aaa1f1a527712a02 
9cc68f63ca3b34ed1f13b05029c3b4bb968a21cb M      ssl

when the OpenSSL receives a Client Key Exchange message that has the encrypted 
premaster secret comprised only of zero bytes, or equal to server's modulus, 
the server just aborts the connection without sending an Alert message

OpenSSL 1.0.2 (b746aa3fe05b5b) and 1.0.1 (6adf409c7432b9) do send Alert 
messages in this situation

Reproducer:
===========
(requires Python 2.6, 3.2 or later)
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
pushd .tlslite-ng
popd
ln -s .tlslite-ng/tlslite tlslite
popd
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt \
-nodes -batch -subj /CN=localhost
openssl s_server -www -key localhost.key -cert localhost.crt
# in another terminal, same directory
PYTHONPATH=tlsfuzzer python
tlsfuzzer/scripts/test-invalid-rsa-key-exchange-messages.py

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160722/01c13d70/attachment.sig>

From rt at openssl.org  Fri Jul 22 15:16:43 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 22 Jul 2016 15:16:43 +0000
Subject: [openssl-dev] [openssl.org #4511] s_server does not send Alert
	messages upon receiving malformed Client Key Exchange
	messages in DHE key exchange
In-Reply-To: <1501337.2KOEEos4mI@pintsize.usersys.redhat.com>
References: <RT-Ticket-4511@openssl.org>
 <1501337.2KOEEos4mI@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-17767-1469200603-1032.4511-6-0@openssl.org>

Fixed now in master and 1.0.2.

Thanks for the report,
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4511
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 15:26:26 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 22 Jul 2016 15:26:26 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160702105929.GA9192@roeckx.be>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
Message-ID: <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>

In addition to github PR 1294, there's now also PR 1339 which adds the function to set the EXFLAG_PROXY flag on a given certificate. 

Also, PR 1295 has been updated. Instead of a function that returns a lock, there is now a lock and an unlock function. 

To me, it seems that that covers what's being asked for. Perhaps not exactly (the setters are for X509_STORE only), but should be workable. 

(writing this from my mobile, sorry for the lack of github links) 

-- 
Richard Levitte
levitte at openssl.org
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 15:51:16 2016
From: rt at openssl.org (msalle@nikhef.nl via RT)
Date: Fri, 22 Jul 2016 15:51:16 +0000
Subject: [openssl-dev] [openssl.org #4624] Re: Bug#829272: Missing accessors
In-Reply-To: <20160722154525.GE32686@nikhef.nl>
References: <RT-Ticket-4624@openssl.org> <RT-Ticket-4602@openssl.org>
 <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
Message-ID: <rt-4.0.19-17766-1469202676-1858.4624-21-0@openssl.org>

Hi,

unless I didn't look careful enough I think we might still be missing
the current_cert (and current_issuer) from the X509_STORE_CTX, as
advertised in
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
and used in e.g.
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
and many other places for verifying the proxy chain or is there a
better/other solution for that?

Best wishes,
Mischa

On Fri, Jul 22, 2016 at 03:26:26PM +0000, Richard Levitte via RT wrote:
> In addition to github PR 1294, there's now also PR 1339 which adds the function to set the EXFLAG_PROXY flag on a given certificate. 
> 
> Also, PR 1295 has been updated. Instead of a function that returns a lock, there is now a lock and an unlock function. 
> 
> To me, it seems that that covers what's being asked for. Perhaps not exactly (the setters are for X509_STORE only), but should be workable. 
> 
> (writing this from my mobile, sorry for the lack of github links) 
> 
> -- 
> Richard Levitte
> levitte at openssl.org
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 
> -- 
> To unsubscribe, send mail to 829272-unsubscribe at bugs.debian.org.

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4624
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3382 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160722/8be210ad/attachment-0001.bin>

From rt at openssl.org  Fri Jul 22 15:56:05 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 22 Jul 2016 15:56:05 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160722154525.GE32686@nikhef.nl>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
Message-ID: <rt-4.0.19-17766-1469202965-378.4602-6-0@openssl.org>

Hi, 

Good point, I'll look into that. Also, thanks for the reminder, that HOWTO needs a rewrite, badly. 

Cheers 
Richard 

On Fri Jul 22 15:51:16 2016, msalle at nikhef.nl wrote:
> Hi,
> 
> unless I didn't look careful enough I think we might still be missing
> the current_cert (and current_issuer) from the X509_STORE_CTX, as
> advertised in
> https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> and used in e.g.
> https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> and many other places for verifying the proxy chain or is there a
> better/other solution for that?
> 
> Best wishes,
> Mischa
> 
> On Fri, Jul 22, 2016 at 03:26:26PM +0000, Richard Levitte via RT
> wrote:
> > In addition to github PR 1294, there's now also PR 1339 which adds
> > the function to set the EXFLAG_PROXY flag on a given certificate.
> >
> > Also, PR 1295 has been updated. Instead of a function that returns a
> > lock, there is now a lock and an unlock function.
> >
> > To me, it seems that that covers what's being asked for. Perhaps not
> > exactly (the setters are for X509_STORE only), but should be
> > workable.
> >
> > (writing this from my mobile, sorry for the lack of github links)
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >
> > --
> > To unsubscribe, send mail to 829272-unsubscribe at bugs.debian.org.


-- 
Richard Levitte
levitte at openssl.org
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 17:14:43 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 22 Jul 2016 17:14:43 +0000
Subject: [openssl-dev] [openssl.org #4623] OpenSSL master regression in
	handling malformed Client Key Exchange messages in RSA key exchange
In-Reply-To: <1633197.q7QCyuLxU0@pintsize.usersys.redhat.com>
References: <RT-Ticket-4623@openssl.org> <RT-Ticket-4511@openssl.org>
 <1501337.2KOEEos4mI@pintsize.usersys.redhat.com>
 <rt-4.0.19-3086-1460726572-1523.4511-21-0@openssl.org>
 <1633197.q7QCyuLxU0@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-17767-1469207682-1718.4623-6-0@openssl.org>

On Fri Jul 22 14:56:11 2016, hkario at redhat.com wrote:
> the issue is present in master 0ed26acce328ec16a3aa and looks to have
> been
> introduced in commit:
>

I tried what I thought was a fix for this which is to simply delete the lines:

if (decrypt_len < 0)
goto err;

from ssl/statem/statem_srvr.c

However your reproducer still indicates errors. I checked the message logs and
it should be now sending as many alerts as the original. The difference however
is that some of them will be sent immediately whereas originally they would be
at the end of the handshake.

Could your reproducer possibly not be expecting this?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 17:21:27 2016
From: rt at openssl.org (Hubert Kario via RT)
Date: Fri, 22 Jul 2016 17:21:27 +0000
Subject: [openssl-dev] [openssl.org #4623] OpenSSL master regression in
	handling malformed Client Key Exchange messages in RSA key exchange
In-Reply-To: <31943678.eatBllTchG@pintsize.usersys.redhat.com>
References: <RT-Ticket-4623@openssl.org>
 <1633197.q7QCyuLxU0@pintsize.usersys.redhat.com>
 <rt-4.0.19-17767-1469207682-1718.4623-6-0@openssl.org>
 <31943678.eatBllTchG@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-17767-1469208087-1834.4623-6-0@openssl.org>

On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> On Fri Jul 22 14:56:11 2016, hkario at redhat.com wrote:
> > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > been
> 
> > introduced in commit:
> I tried what I thought was a fix for this which is to simply delete the
> lines:
> 
> if (decrypt_len < 0)
> goto err;
> 
> from ssl/statem/statem_srvr.c
> 
> However your reproducer still indicates errors. I checked the message logs
> and it should be now sending as many alerts as the original. The difference
> however is that some of them will be sent immediately whereas originally
> they would be at the end of the handshake.
> 
> Could your reproducer possibly not be expecting this?

yes, it expects to be hitting the Bleichenbacher workaround - use of different 
premaster secret in case of problems with CKE message - as it's the same 
behaviour OpenSSL, NSS and GnuTLS exhibit

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160722/291b47eb/attachment.sig>

From rt at openssl.org  Fri Jul 22 17:30:05 2016
From: rt at openssl.org (Hubert Kario via RT)
Date: Fri, 22 Jul 2016 17:30:05 +0000
Subject: [openssl-dev] [openssl.org #4623] OpenSSL master regression in
	handling malformed Client Key Exchange messages in RSA key exchange
In-Reply-To: <2130579.1c3FUNMuLe@pintsize.usersys.redhat.com>
References: <RT-Ticket-4623@openssl.org>
 <1633197.q7QCyuLxU0@pintsize.usersys.redhat.com>
 <rt-4.0.19-17767-1469207682-1718.4623-6-0@openssl.org>
 <2130579.1c3FUNMuLe@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-17767-1469208605-45.4623-6-0@openssl.org>

On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> On Fri Jul 22 14:56:11 2016, hkario at redhat.com wrote:
> > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > been
> 
> > introduced in commit:
> I tried what I thought was a fix for this which is to simply delete the
> lines:
> 
> if (decrypt_len < 0)
> goto err;
> 
> from ssl/statem/statem_srvr.c
> 
> However your reproducer still indicates errors. I checked the message logs
> and it should be now sending as many alerts as the original. The difference
> however is that some of them will be sent immediately whereas originally
> they would be at the end of the handshake.
> 
> Could your reproducer possibly not be expecting this?


sorry, I copied this part:

> when the OpenSSL receives a Client Key Exchange message that has the
> encrypted
> premaster secret comprised only of zero bytes, or equal to server's modulus,
> the server just aborts the connection without sending an Alert message

from the DHE/ECDHE bug reports

the expected behaviour is to continue the connection, but the server should 
select a premaster secret that was not provided by the client, instead OpenSSL 
just closes the connection
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160722/5b9e0347/attachment.sig>

From rt at openssl.org  Fri Jul 22 19:39:07 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 22 Jul 2016 19:39:07 +0000
Subject: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise
	pre-rfc3820 proxy certs
In-Reply-To: <rt-4.0.19-17766-1469191938-891.4622-6-0@openssl.org>
References: <RT-Ticket-4622@openssl.org>
 <rt-4.0.19-17766-1469187147-1577.4622-6-0@openssl.org>
 <rt-4.0.19-17766-1469187311-129.4622-6-0@openssl.org>
 <6c78a03f51c2499e8abff2ff07ba61ad@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-17766-1469191938-891.4622-6-0@openssl.org>
Message-ID: <rt-4.0.19-17767-1469216347-1153.4622-6-0@openssl.org>

On Fri Jul 22 12:52:18 2016, rsalz at akamai.com wrote:
> And now, with subject clearly stated, I think we should not do this.

After some discussion, we decided to abandon this line of thought and get back
to accessors as off RT4602.

Closing this ticket.

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4622
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 19:53:01 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 22 Jul 2016 19:53:01 +0000
Subject: [openssl-dev] [openssl.org #4619] compile errors with no-srp
In-Reply-To: <1469047703.9402.17.camel@ns.five-ten-sg.com>
References: <RT-Ticket-4619@openssl.org>
 <1469047703.9402.17.camel@ns.five-ten-sg.com>
Message-ID: <rt-4.0.19-17767-1469217181-969.4619-6-0@openssl.org>

It's a spelling error. Fix in https://github.com/openssl/openssl/pull/1341

Cheers,
Richard

On Wed Jul 20 21:45:53 2016, carl at five-ten-sg.com wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Source from master on github,
>
> ./Configure --prefix=/usr/local --openssldir=/usr/local/etc/pki/tls
> enable-ec_nistp_64_gcc_128 zlib sctp enable-camellia enable-seed enable-
> rfc3779 enable-cms enable-md2 no-mdc2 no-rc5 no-ec2m no-gost no-srp -Wa,
> - --noexecstack -DPURIFY enable-deprecated shared linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
> no-asan [default] OPENSSL_NO_ASAN (skip dir)
> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [default]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> no-ec2m [option] OPENSSL_NO_EC2M (skip dir)
> no-egd [default] OPENSSL_NO_EGD (skip dir)
> no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir)
> no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
> no-gost [option] OPENSSL_NO_GOST (skip dir)
> no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> no-mdc2 [option] OPENSSL_NO_MDC2 (skip dir)
> no-rc5 [option] OPENSSL_NO_RC5 (skip dir)
> no-srp [option] OPENSSL_NO_SRP (skip dir)
> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir)
> no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir)
> no-ubsan [default] OPENSSL_NO_UBSAN (skip dir)
> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip
> dir)
> no-zlib-dynamic [default]
>
>
> make depend
> make all
> ....
>
> gcc -I. -Iinclude -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG
> - -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
> - -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> - -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> - -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> - -DPOLY1305_ASM -DPURIFY -DOPENSSLDIR="\"/usr/local/etc/pki/tls\""
> - -DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wall -O3 -pthread
> -m64
> - -DL_ENDIAN -Wa,--noexecstack -fPIC -MMD -MF ssl/t1_ext.d.tmp -MT
> ssl/t1_ext.o -c -o ssl/t1_ext.o ssl/t1_ext.c
> ssl/statem/statem_clnt.c: In function 'tls_construct_cke_srp':
> ssl/statem/statem_clnt.c:2455: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2457: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2459: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2465: error: 'SSL_SESSION' has no member named
> 'srp_username'
> ssl/statem/statem_clnt.c:2466: error: 'SSL_SESSION' has no member named
> 'srp_username'
> ssl/statem/statem_clnt.c:2466: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2467: error: 'SSL_SESSION' has no member named
> 'srp_username'
> make[2]: *** [ssl/statem/statem_clnt.o] Error 1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAleP41cACgkQL6j7milTFsHYBACdGbcmT0xsANaKhaFz7pGNoU2F
> R3cAnif6xhWLvWjTUMPkNfv/+rYV7yMc
> =NEzZ
> -----END PGP SIGNATURE-----
>
>


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4619
Please log in as guest with password guest if prompted


From rsalz at akamai.com  Fri Jul 22 20:32:54 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Jul 2016 20:32:54 +0000
Subject: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise
 pre-rfc3820 proxy certs
In-Reply-To: <6106b2ad-a457-df2e-2ff2-627a8fc1ca64@nikhef.nl>
References: <RT-Ticket-4622@openssl.org>
 <rt-4.0.19-17766-1469187147-1577.4622-6-0@openssl.org>
 <rt-4.0.19-17766-1469187311-129.4622-6-0@openssl.org>
 <6c78a03f51c2499e8abff2ff07ba61ad@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-17766-1469191938-1132.4622-6-0@openssl.org>
 <6106b2ad-a457-df2e-2ff2-627a8fc1ca64@nikhef.nl>
Message-ID: <c547edbc1b98441f9e08e22b1276f0c2@usma1ex-dag1mb1.msg.corp.akamai.com>

I understand, and I think Richard will provide the hooks you need.

But this is, as you say, stuff that is eight years old....

From rt at openssl.org  Fri Jul 22 20:38:30 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 22 Jul 2016 20:38:30 +0000
Subject: [openssl-dev] [openssl.org #4599] big CRLs problem with openssl
	1.0.2h
In-Reply-To: <87A602C2B312594B9BDAAC3A69D6F465077FEE25@mailbox02.isabelteam.be>
References: <RT-Ticket-4599@openssl.org>
 <87A602C2B312594B9BDAAC3A69D6F465077FEE25@mailbox02.isabelteam.be>
Message-ID: <rt-4.0.19-17448-1469219910-1915.4599-6-0@openssl.org>

This is a known issue which is fixed in the current snapshots. Commit
a1eef756cc1948ed4d1f addresses it.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4599
Please log in as guest with password guest if prompted


From brian at briansmith.org  Fri Jul 22 22:05:07 2016
From: brian at briansmith.org (Brian Smith)
Date: Fri, 22 Jul 2016 12:05:07 -1000
Subject: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256
	correct?
In-Reply-To: <CAFewVt65wGVCw9i+hSwPFDy1q3OUVJB=KU4tA+UQLHNfu6Jfpw@mail.gmail.com>
References: <CAFewVt6pNsNFjsmxvgkGGo8QSDUf=THU7T8_Y4V=meOmE_0qHA@mail.gmail.com>
 <CAFewVt65wGVCw9i+hSwPFDy1q3OUVJB=KU4tA+UQLHNfu6Jfpw@mail.gmail.com>
Message-ID: <CAFewVt4cvh3hS-ghc4EOVx5J1sWFNO-hS2grFqmMAbwhNXSV-w@mail.gmail.com>

The issue is particularly clear when we multiply the generator by
zero. Note that in general, an application shouldn't multiply the
generator by zero since there's no useful cryptographic purpose for
doing so. But, this is a convenient example.

In the code we have,

    ecp_nistz256_gather_w7(&p.a, preComputedTable[0], wvalue >> 1);
    ecp_nistz256_neg(p.p.Z, p.p.Y);
    copy_conditional(p.p.Y, p.p.Z, wvalue & 1);
    memcpy(p.p.Z, ONE, sizeof(ONE));

The generator is all zeros, so we'll start off with the point (0, 0,
1). Then we add the point at infinity over and over again, leaving
that point unchanged each time. Thus, we'll end with (0, 0, 1). Then:

    r->Z_is_one = is_one(p.p.Z) & 1;

Thus, the resulting point will be (0, 0, 1).

After the memcpy quoted above, we need to do a copy_conditional(p.p.Z,
is_infinity, ZERO) or equivalent, where ZERO is all-zeros and where
is_infinity is the result of checking if (x, y) == (0, 0).

This is just one example of an edge case that is handled in a
surprising way. I think there are more, as described in the quoted
message below.

Cheers,
Brian


Brian Smith <brian at briansmith.org> wrote:
>
> Brian Smith <brian at briansmith.org> wrote:
>>
>> When doing math on short Weierstrass curves like P-256, we have to
>> special case points at infinity. In Jacobian coordinates (X, Y, Z),
>> points at infinity have Z == 0. However, instead of checking for Z ==
>> 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it
>> does, in some sense, the opposite of what I expect it to do.
>
>
> I exchanged email with both of the original authors of the code, Shay and Vlad. He that the ecp_nistz256_point_* functions indeed intend to represent the point at infinity as (0, 0) and it is expected (but I did not verify) that those functions should work when the point at infinity is encoded as (0, 0, _).
>
>> The authors
>> instead decided to encode the point at infinity as (0, 0), since the
>> affine point (0, 0) isn't on the P-256 curve. It isn't clear why the
>> authors chose to do that though, since the point at infinity doesn't
>> (can't, logically) appear in the table of precomputed multiples of G
>> anyway.
>
>
> Actually, as the code says, the point at infinity implicitly occurs in the table implicitly. Obviously the accumulator point will be at infinity until at least a one bit is found in the scalar.
>
>>
>> But, it seems like the functions that do the computations, like
>>
>> ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the
>> point at infinity as (_, _, 0), not necessarily (0, 0, _). Also,
>> ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and
>> ec_GFp_simple_point_set_to_infinity, which represent the point at
>> infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine
>> uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0.
>> This inconsistency is confusing, if not wrong. Given this, it seems
>> like the point-at-infinity checks in the ecp_nistz256_point_add and
>> ecp_nistz256_point_add_affine code should also be checking that z == 0
>> instead of (x, y) == (0, 0).
>
>
> Instead, when we convert a point from EC_POINT to P256_POINT or P256_POINT_AFFINE, we should translate the (_, _, 0) form into the (0, 0, 0) form. And/or reject points at infinity as inputs to the function. Similarly, when we convert the resultant P256_POINT to an EC_POINT, we chould translate the (0, 0) encoding of the point at infinity to the (0, 0, 0) form or at least the (_, _, 0) form.
>
> In particular, consider the case where you have an EC_POINT that isn't at infinity, e.g. (x, y, 1). Then you call EC_POINT_set_to_infinity on it. Then it is (x, y, 0). Then you pass it to EC_POINT_mul/EC_POINTs_mul even though you shouldn't.
>
> Maybe the precondition of EC_POINT_mul/EC_POINTs_mul is that none of the input points are at infinity, in which case it doesn't matter. (But if so, maybe these functions should do a point-at-infinity check.) But if it is allowed to pass in the point at infinity, then the ecp_nistz256 code should translate the input point from (_, _, 0) form to (0, 0, _) form before doing the computation. It can use is_zero and copy_conditional and friends to do this.
>
> Similarly, after the computation, it should translate the (0, 0, _) form to (_, _, 0) form. In particular, it should do such a translation before the code sets Z_is_one, AFAICT. Note that the nistz256 code might be using the form (0, 0, 0) instead of (0, 0, _) in which case this translation might not be necessary.
>
> Regardless, it would be useful to write tests for these cases:
> 1. Verify that the result is correct when any of the input points are (0, 0, 0)
> 2. Verify that the result is correct when any of the input points are (_, _, 0).
> 3. Verify that the result is correct, and in particular that Z_is_one is set correctly on the result, when the final result is at infinity, especially for the cases where neither the input points are at infinity, e.g. when adding (n-1)G to 1G.
>
> Note that all of the above cases have interesting sub-cases: the G scalar is NULL, the G scalar is non-NULL and zero-valued, G scalar is a multiple of G, G scalar is larger than G. And same for the P scalars.
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>



-- 
https://briansmith.org/

From rt at openssl.org  Fri Jul 22 22:05:18 2016
From: rt at openssl.org (Brian Smith via RT)
Date: Fri, 22 Jul 2016 22:05:18 +0000
Subject: [openssl-dev] [openssl.org #4625] Re: Are the point-at-infinity
	checks in ecp_nistz256 correct?
In-Reply-To: <CAFewVt4cvh3hS-ghc4EOVx5J1sWFNO-hS2grFqmMAbwhNXSV-w@mail.gmail.com>
References: <RT-Ticket-4625@openssl.org>
 <CAFewVt6pNsNFjsmxvgkGGo8QSDUf=THU7T8_Y4V=meOmE_0qHA@mail.gmail.com>
 <CAFewVt65wGVCw9i+hSwPFDy1q3OUVJB=KU4tA+UQLHNfu6Jfpw@mail.gmail.com>
 <CAFewVt4cvh3hS-ghc4EOVx5J1sWFNO-hS2grFqmMAbwhNXSV-w@mail.gmail.com>
Message-ID: <rt-4.0.19-17767-1469225118-1065.4625-21-0@openssl.org>

The issue is particularly clear when we multiply the generator by
zero. Note that in general, an application shouldn't multiply the
generator by zero since there's no useful cryptographic purpose for
doing so. But, this is a convenient example.

In the code we have,

    ecp_nistz256_gather_w7(&p.a, preComputedTable[0], wvalue >> 1);
    ecp_nistz256_neg(p.p.Z, p.p.Y);
    copy_conditional(p.p.Y, p.p.Z, wvalue & 1);
    memcpy(p.p.Z, ONE, sizeof(ONE));

The generator is all zeros, so we'll start off with the point (0, 0,
1). Then we add the point at infinity over and over again, leaving
that point unchanged each time. Thus, we'll end with (0, 0, 1). Then:

    r->Z_is_one = is_one(p.p.Z) & 1;

Thus, the resulting point will be (0, 0, 1).

After the memcpy quoted above, we need to do a copy_conditional(p.p.Z,
is_infinity, ZERO) or equivalent, where ZERO is all-zeros and where
is_infinity is the result of checking if (x, y) == (0, 0).

This is just one example of an edge case that is handled in a
surprising way. I think there are more, as described in the quoted
message below.

Cheers,
Brian


Brian Smith <brian at briansmith.org> wrote:
>
> Brian Smith <brian at briansmith.org> wrote:
>>
>> When doing math on short Weierstrass curves like P-256, we have to
>> special case points at infinity. In Jacobian coordinates (X, Y, Z),
>> points at infinity have Z == 0. However, instead of checking for Z ==
>> 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it
>> does, in some sense, the opposite of what I expect it to do.
>
>
> I exchanged email with both of the original authors of the code, Shay and Vlad. He that the ecp_nistz256_point_* functions indeed intend to represent the point at infinity as (0, 0) and it is expected (but I did not verify) that those functions should work when the point at infinity is encoded as (0, 0, _).
>
>> The authors
>> instead decided to encode the point at infinity as (0, 0), since the
>> affine point (0, 0) isn't on the P-256 curve. It isn't clear why the
>> authors chose to do that though, since the point at infinity doesn't
>> (can't, logically) appear in the table of precomputed multiples of G
>> anyway.
>
>
> Actually, as the code says, the point at infinity implicitly occurs in the table implicitly. Obviously the accumulator point will be at infinity until at least a one bit is found in the scalar.
>
>>
>> But, it seems like the functions that do the computations, like
>>
>> ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the
>> point at infinity as (_, _, 0), not necessarily (0, 0, _). Also,
>> ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and
>> ec_GFp_simple_point_set_to_infinity, which represent the point at
>> infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine
>> uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0.
>> This inconsistency is confusing, if not wrong. Given this, it seems
>> like the point-at-infinity checks in the ecp_nistz256_point_add and
>> ecp_nistz256_point_add_affine code should also be checking that z == 0
>> instead of (x, y) == (0, 0).
>
>
> Instead, when we convert a point from EC_POINT to P256_POINT or P256_POINT_AFFINE, we should translate the (_, _, 0) form into the (0, 0, 0) form. And/or reject points at infinity as inputs to the function. Similarly, when we convert the resultant P256_POINT to an EC_POINT, we chould translate the (0, 0) encoding of the point at infinity to the (0, 0, 0) form or at least the (_, _, 0) form.
>
> In particular, consider the case where you have an EC_POINT that isn't at infinity, e.g. (x, y, 1). Then you call EC_POINT_set_to_infinity on it. Then it is (x, y, 0). Then you pass it to EC_POINT_mul/EC_POINTs_mul even though you shouldn't.
>
> Maybe the precondition of EC_POINT_mul/EC_POINTs_mul is that none of the input points are at infinity, in which case it doesn't matter. (But if so, maybe these functions should do a point-at-infinity check.) But if it is allowed to pass in the point at infinity, then the ecp_nistz256 code should translate the input point from (_, _, 0) form to (0, 0, _) form before doing the computation. It can use is_zero and copy_conditional and friends to do this.
>
> Similarly, after the computation, it should translate the (0, 0, _) form to (_, _, 0) form. In particular, it should do such a translation before the code sets Z_is_one, AFAICT. Note that the nistz256 code might be using the form (0, 0, 0) instead of (0, 0, _) in which case this translation might not be necessary.
>
> Regardless, it would be useful to write tests for these cases:
> 1. Verify that the result is correct when any of the input points are (0, 0, 0)
> 2. Verify that the result is correct when any of the input points are (_, _, 0).
> 3. Verify that the result is correct, and in particular that Z_is_one is set correctly on the result, when the final result is at infinity, especially for the cases where neither the input points are at infinity, e.g. when adding (n-1)G to 1G.
>
> Note that all of the above cases have interesting sub-cases: the G scalar is NULL, the G scalar is non-NULL and zero-valued, G scalar is a multiple of G, G scalar is larger than G. And same for the P scalars.
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>



-- 
https://briansmith.org/


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4625
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 22 22:16:16 2016
From: rt at openssl.org (David Benjamin via RT)
Date: Fri, 22 Jul 2016 22:16:16 +0000
Subject: [openssl-dev] [openssl.org #4623] OpenSSL master regression in
	handling malformed Client Key Exchange messages in RSA key exchange
In-Reply-To: <CAF8qwaB=AJ92haKOR_vn9yF2jJD=E8tGt2MQ2L=1kUGVuaWGCw@mail.gmail.com>
References: <RT-Ticket-4623@openssl.org>
 <1633197.q7QCyuLxU0@pintsize.usersys.redhat.com>
 <rt-4.0.19-17767-1469207682-1718.4623-6-0@openssl.org>
 <2130579.1c3FUNMuLe@pintsize.usersys.redhat.com>
 <rt-4.0.19-17767-1469208605-45.4623-6-0@openssl.org>
 <CAF8qwaB=AJ92haKOR_vn9yF2jJD=E8tGt2MQ2L=1kUGVuaWGCw@mail.gmail.com>
Message-ID: <rt-4.0.19-17767-1469225776-1151.4623-6-0@openssl.org>

On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT <rt at openssl.org> wrote:

> On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> > On Fri Jul 22 14:56:11 2016, hkario at redhat.com wrote:
> > > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > > been
> >
> > > introduced in commit:
> > I tried what I thought was a fix for this which is to simply delete the
> > lines:
> >
> > if (decrypt_len < 0)
> > goto err;
> >
> > from ssl/statem/statem_srvr.c
> >
> > However your reproducer still indicates errors. I checked the message
> logs
> > and it should be now sending as many alerts as the original. The
> difference
> > however is that some of them will be sent immediately whereas originally
> > they would be at the end of the handshake.
> >
> > Could your reproducer possibly not be expecting this?
>
>
> sorry, I copied this part:
>
> > when the OpenSSL receives a Client Key Exchange message that has the
> > encrypted
> > premaster secret comprised only of zero bytes, or equal to server's
> modulus,
> > the server just aborts the connection without sending an Alert message
>
> from the DHE/ECDHE bug reports
>
> the expected behaviour is to continue the connection, but the server should
> select a premaster secret that was not provided by the client, instead
> OpenSSL
> just closes the connection
>

I don't believe this test is correct if the encrypted premaster is equal to
the server's modulus. Such an encrypted premaster is a publicly invalid RSA
ciphertext. It is perfectly reasonable to reject it early, should unpadded
RSA_decrypt fail. The timing sensitive portion is the padding check itself,
which this code should correctly defer failure of, to avoid the padding
oracle.

The reason public decrypt failures did not trigger early alerts before was
because the old code was a little sloppy about error-handling. In addition
to not being constant time, it squashed together codepaths for publicly
invalid keys and the timing sensitive check.

It is true that it no longer sends an alert on public failures. Probably
worth fixing. Meh.

David

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted


From brian at briansmith.org  Fri Jul 22 22:35:20 2016
From: brian at briansmith.org (Brian Smith)
Date: Fri, 22 Jul 2016 12:35:20 -1000
Subject: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256
	correct?
In-Reply-To: <CAFewVt4cvh3hS-ghc4EOVx5J1sWFNO-hS2grFqmMAbwhNXSV-w@mail.gmail.com>
References: <CAFewVt6pNsNFjsmxvgkGGo8QSDUf=THU7T8_Y4V=meOmE_0qHA@mail.gmail.com>
 <CAFewVt65wGVCw9i+hSwPFDy1q3OUVJB=KU4tA+UQLHNfu6Jfpw@mail.gmail.com>
 <CAFewVt4cvh3hS-ghc4EOVx5J1sWFNO-hS2grFqmMAbwhNXSV-w@mail.gmail.com>
Message-ID: <CAFewVt5r4e-2cWY67J31MPDUxEBq8h_gcO7630agox12CqX=ug@mail.gmail.com>

Brian Smith <brian at briansmith.org> wrote:
> The issue is particularly clear when we multiply the generator by
> zero. Note that in general, an application shouldn't multiply the
> generator by zero since there's no useful cryptographic purpose for
> doing so. But, this is a convenient example.

Sorry, I was wrong. From the definition of ECDSA:

        H = Hash(M).
        Convert the bit string H to an integer e.
        w = s**?1 mod n
        u1 = (e * w) mod n
        R = u1*G + u2*Q

If the highest 256 bits of Hash(M) are zero, then e == 0 and then u1
== 0 * w == 0. So, it probably is important to handle g_scalar == 0 in
the way I described in my earlier message, using the conditional copy.

Cheers,
Brian

From rt at openssl.org  Fri Jul 22 22:35:31 2016
From: rt at openssl.org (Brian Smith via RT)
Date: Fri, 22 Jul 2016 22:35:31 +0000
Subject: [openssl-dev] [openssl.org #4626] Re: Are the point-at-infinity
	checks in ecp_nistz256 correct?
In-Reply-To: <CAFewVt5r4e-2cWY67J31MPDUxEBq8h_gcO7630agox12CqX=ug@mail.gmail.com>
References: <RT-Ticket-4626@openssl.org>
 <CAFewVt6pNsNFjsmxvgkGGo8QSDUf=THU7T8_Y4V=meOmE_0qHA@mail.gmail.com>
 <CAFewVt65wGVCw9i+hSwPFDy1q3OUVJB=KU4tA+UQLHNfu6Jfpw@mail.gmail.com>
 <CAFewVt4cvh3hS-ghc4EOVx5J1sWFNO-hS2grFqmMAbwhNXSV-w@mail.gmail.com>
 <CAFewVt5r4e-2cWY67J31MPDUxEBq8h_gcO7630agox12CqX=ug@mail.gmail.com>
Message-ID: <rt-4.0.19-17767-1469226931-472.4626-21-0@openssl.org>

Brian Smith <brian at briansmith.org> wrote:
> The issue is particularly clear when we multiply the generator by
> zero. Note that in general, an application shouldn't multiply the
> generator by zero since there's no useful cryptographic purpose for
> doing so. But, this is a convenient example.

Sorry, I was wrong. From the definition of ECDSA:

        H = Hash(M).
        Convert the bit string H to an integer e.
        w = s**?1 mod n
        u1 = (e * w) mod n
        R = u1*G + u2*Q

If the highest 256 bits of Hash(M) are zero, then e == 0 and then u1
== 0 * w == 0. So, it probably is important to handle g_scalar == 0 in
the way I described in my earlier message, using the conditional copy.

Cheers,
Brian


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4626
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 23 08:49:03 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Sat, 23 Jul 2016 08:49:03 +0000
Subject: [openssl-dev] [openssl.org #4619] compile errors with no-srp
In-Reply-To: <rt-4.0.19-17767-1469217181-375.4619-6-0@openssl.org>
References: <RT-Ticket-4619@openssl.org>
 <1469047703.9402.17.camel@ns.five-ten-sg.com>
 <rt-4.0.19-17767-1469217181-375.4619-6-0@openssl.org>
Message-ID: <rt-4.0.19-17767-1469263743-517.4619-6-0@openssl.org>

Now part of master, commit 8b9546c7085733c88f1df66da48d48a3bc5230a2

Cheers,
Richard

On Fri Jul 22 19:53:01 2016, levitte wrote:
> It's a spelling error. Fix in https://github.com/openssl/openssl/pull/1341
>
> Cheers,
> Richard
>
> On Wed Jul 20 21:45:53 2016, carl at five-ten-sg.com wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Source from master on github,
> >
> > ./Configure --prefix=/usr/local --openssldir=/usr/local/etc/pki/tls
> > enable-ec_nistp_64_gcc_128 zlib sctp enable-camellia enable-seed enable-
> > rfc3779 enable-cms enable-md2 no-mdc2 no-rc5 no-ec2m no-gost no-srp -Wa,
> > - --noexecstack -DPURIFY enable-deprecated shared linux-x86_64
> > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
> > no-asan [default] OPENSSL_NO_ASAN (skip dir)
> > no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> > no-crypto-mdebug-backtrace [default]
> > OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> > no-ec2m [option] OPENSSL_NO_EC2M (skip dir)
> > no-egd [default] OPENSSL_NO_EGD (skip dir)
> > no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir)
> > no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
> > no-gost [option] OPENSSL_NO_GOST (skip dir)
> > no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> > no-mdc2 [option] OPENSSL_NO_MDC2 (skip dir)
> > no-rc5 [option] OPENSSL_NO_RC5 (skip dir)
> > no-srp [option] OPENSSL_NO_SRP (skip dir)
> > no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> > no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir)
> > no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir)
> > no-ubsan [default] OPENSSL_NO_UBSAN (skip dir)
> > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip
> > dir)
> > no-zlib-dynamic [default]
> >
> >
> > make depend
> > make all
> > ....
> >
> > gcc -I. -Iinclude -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG
> > - -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
> > - -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> > - -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> > - -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > - -DPOLY1305_ASM -DPURIFY -DOPENSSLDIR="\"/usr/local/etc/pki/tls\""
> > - -DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wall -O3 -pthread
> > -m64
> > - -DL_ENDIAN -Wa,--noexecstack -fPIC -MMD -MF ssl/t1_ext.d.tmp -MT
> > ssl/t1_ext.o -c -o ssl/t1_ext.o ssl/t1_ext.c
> > ssl/statem/statem_clnt.c: In function 'tls_construct_cke_srp':
> > ssl/statem/statem_clnt.c:2455: error: 'SSL' has no member named
> > 'srp_ctx'
> > ssl/statem/statem_clnt.c:2457: error: 'SSL' has no member named
> > 'srp_ctx'
> > ssl/statem/statem_clnt.c:2459: error: 'SSL' has no member named
> > 'srp_ctx'
> > ssl/statem/statem_clnt.c:2465: error: 'SSL_SESSION' has no member named
> > 'srp_username'
> > ssl/statem/statem_clnt.c:2466: error: 'SSL_SESSION' has no member named
> > 'srp_username'
> > ssl/statem/statem_clnt.c:2466: error: 'SSL' has no member named
> > 'srp_ctx'
> > ssl/statem/statem_clnt.c:2467: error: 'SSL_SESSION' has no member named
> > 'srp_username'
> > make[2]: *** [ssl/statem/statem_clnt.o] Error 1
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.14 (GNU/Linux)
> >
> > iEYEAREKAAYFAleP41cACgkQL6j7milTFsHYBACdGbcmT0xsANaKhaFz7pGNoU2F
> > R3cAnif6xhWLvWjTUMPkNfv/+rYV7yMc
> > =NEzZ
> > -----END PGP SIGNATURE-----
> >
> >
>
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4619
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 23 09:44:18 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Sat, 23 Jul 2016 09:44:18 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160722154525.GE32686@nikhef.nl>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
Message-ID: <rt-4.0.19-17448-1469267058-417.4602-6-0@openssl.org>

To get current_cert, it's X509_STORE_CTX_get_current_cert().
To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()

Those functions are already present in pre-1.1 OpenSSL (at least in the 1.0.2
series)

On Fri Jul 22 15:51:16 2016, msalle at nikhef.nl wrote:
> Hi,
>
> unless I didn't look careful enough I think we might still be missing
> the current_cert (and current_issuer) from the X509_STORE_CTX, as
> advertised in
>
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> and used in e.g.
> https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> and many other places for verifying the proxy chain or is there a
> better/other solution for that?
>
> Best wishes,
> Mischa
>
> On Fri, Jul 22, 2016 at 03:26:26PM +0000, Richard Levitte via RT
> wrote:
> > In addition to github PR 1294, there's now also PR 1339 which adds
> > the function to set the EXFLAG_PROXY flag on a given certificate.
> >
> > Also, PR 1295 has been updated. Instead of a function that returns a
> > lock, there is now a lock and an unlock function.
> >
> > To me, it seems that that covers what's being asked for. Perhaps not
> > exactly (the setters are for X509_STORE only), but should be
> > workable.
> >
> > (writing this from my mobile, sorry for the lack of github links)
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >
> > --
> > To unsubscribe, send mail to 829272-unsubscribe at bugs.debian.org.


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From kurt at roeckx.be  Sat Jul 23 12:50:06 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 23 Jul 2016 14:50:06 +0200
Subject: [openssl-dev] [openssl.org #4623] OpenSSL master regression in
 handling malformed Client Key Exchange messages in RSA key exchange
In-Reply-To: <rt-4.0.19-17767-1469225776-1151.4623-6-0@openssl.org>
References: <RT-Ticket-4623@openssl.org>
 <1633197.q7QCyuLxU0@pintsize.usersys.redhat.com>
 <rt-4.0.19-17767-1469207682-1718.4623-6-0@openssl.org>
 <2130579.1c3FUNMuLe@pintsize.usersys.redhat.com>
 <rt-4.0.19-17767-1469208605-45.4623-6-0@openssl.org>
 <CAF8qwaB=AJ92haKOR_vn9yF2jJD=E8tGt2MQ2L=1kUGVuaWGCw@mail.gmail.com>
 <rt-4.0.19-17767-1469225776-1151.4623-6-0@openssl.org>
Message-ID: <20160723125006.GA14541@roeckx.be>

On Fri, Jul 22, 2016 at 10:16:16PM +0000, David Benjamin via RT wrote:
> On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT <rt at openssl.org> wrote:
> 
> > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> > > On Fri Jul 22 14:56:11 2016, hkario at redhat.com wrote:
> > > > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > > > been
> > >
> > > > introduced in commit:
> > > I tried what I thought was a fix for this which is to simply delete the
> > > lines:
> > >
> > > if (decrypt_len < 0)
> > > goto err;
> > >
> > > from ssl/statem/statem_srvr.c
> > >
> > > However your reproducer still indicates errors. I checked the message
> > logs
> > > and it should be now sending as many alerts as the original. The
> > difference
> > > however is that some of them will be sent immediately whereas originally
> > > they would be at the end of the handshake.
> > >
> > > Could your reproducer possibly not be expecting this?
> >
> >
> > sorry, I copied this part:
> >
> > > when the OpenSSL receives a Client Key Exchange message that has the
> > > encrypted
> > > premaster secret comprised only of zero bytes, or equal to server's
> > modulus,
> > > the server just aborts the connection without sending an Alert message
> >
> > from the DHE/ECDHE bug reports
> >
> > the expected behaviour is to continue the connection, but the server should
> > select a premaster secret that was not provided by the client, instead
> > OpenSSL
> > just closes the connection
> >
> 
> I don't believe this test is correct if the encrypted premaster is equal to
> the server's modulus. Such an encrypted premaster is a publicly invalid RSA
> ciphertext. It is perfectly reasonable to reject it early, should unpadded
> RSA_decrypt fail. The timing sensitive portion is the padding check itself,
> which this code should correctly defer failure of, to avoid the padding
> oracle.

I think that the test suite should allow for either of 2
behaviours in case of the public failures:
- It continues with a random premaster secret.
- It generates an error.

>From what I understand it now complains that we don't do the first,
so I think it should get changed to allow both behaviours.

> It is true that it no longer sends an alert on public failures. Probably
> worth fixing. Meh.

I don't care for which behaviour we go, and I guess that if we go
for generating an error we should send an alert.

I don't see the point in wasting time for what most likely seems
to be an attack.

What I don't understand currently is that it also rejected a
ciphertext with all 0's?  Were it too many 0's?


Kurt



From rt at openssl.org  Sat Jul 23 12:50:24 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Sat, 23 Jul 2016 12:50:24 +0000
Subject: [openssl-dev] [openssl.org #4623] OpenSSL master regression in
	handling malformed Client Key Exchange messages in RSA key exchange
In-Reply-To: <20160723125006.GA14541@roeckx.be>
References: <RT-Ticket-4623@openssl.org>
 <1633197.q7QCyuLxU0@pintsize.usersys.redhat.com>
 <rt-4.0.19-17767-1469207682-1718.4623-6-0@openssl.org>
 <2130579.1c3FUNMuLe@pintsize.usersys.redhat.com>
 <rt-4.0.19-17767-1469208605-45.4623-6-0@openssl.org>
 <CAF8qwaB=AJ92haKOR_vn9yF2jJD=E8tGt2MQ2L=1kUGVuaWGCw@mail.gmail.com>
 <rt-4.0.19-17767-1469225776-1151.4623-6-0@openssl.org>
 <20160723125006.GA14541@roeckx.be>
Message-ID: <rt-4.0.19-17448-1469278224-464.4623-6-0@openssl.org>

On Fri, Jul 22, 2016 at 10:16:16PM +0000, David Benjamin via RT wrote:
> On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT <rt at openssl.org> wrote:
> 
> > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> > > On Fri Jul 22 14:56:11 2016, hkario at redhat.com wrote:
> > > > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > > > been
> > >
> > > > introduced in commit:
> > > I tried what I thought was a fix for this which is to simply delete the
> > > lines:
> > >
> > > if (decrypt_len < 0)
> > > goto err;
> > >
> > > from ssl/statem/statem_srvr.c
> > >
> > > However your reproducer still indicates errors. I checked the message
> > logs
> > > and it should be now sending as many alerts as the original. The
> > difference
> > > however is that some of them will be sent immediately whereas originally
> > > they would be at the end of the handshake.
> > >
> > > Could your reproducer possibly not be expecting this?
> >
> >
> > sorry, I copied this part:
> >
> > > when the OpenSSL receives a Client Key Exchange message that has the
> > > encrypted
> > > premaster secret comprised only of zero bytes, or equal to server's
> > modulus,
> > > the server just aborts the connection without sending an Alert message
> >
> > from the DHE/ECDHE bug reports
> >
> > the expected behaviour is to continue the connection, but the server should
> > select a premaster secret that was not provided by the client, instead
> > OpenSSL
> > just closes the connection
> >
> 
> I don't believe this test is correct if the encrypted premaster is equal to
> the server's modulus. Such an encrypted premaster is a publicly invalid RSA
> ciphertext. It is perfectly reasonable to reject it early, should unpadded
> RSA_decrypt fail. The timing sensitive portion is the padding check itself,
> which this code should correctly defer failure of, to avoid the padding
> oracle.

I think that the test suite should allow for either of 2
behaviours in case of the public failures:
- It continues with a random premaster secret.
- It generates an error.

>From what I understand it now complains that we don't do the first,
so I think it should get changed to allow both behaviours.

> It is true that it no longer sends an alert on public failures. Probably
> worth fixing. Meh.

I don't care for which behaviour we go, and I guess that if we go
for generating an error we should send an alert.

I don't see the point in wasting time for what most likely seems
to be an attack.

What I don't understand currently is that it also rejected a
ciphertext with all 0's?  Were it too many 0's?


Kurt



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 23 22:39:22 2016
From: rt at openssl.org (Hubert Kario via RT)
Date: Sat, 23 Jul 2016 22:39:22 +0000
Subject: [openssl-dev] [openssl.org #4623] OpenSSL master regression in
	handling malformed Client Key Exchange messages in RSA key exchange
In-Reply-To: <319723939.18578758.1469310330341.JavaMail.zimbra@redhat.com>
References: <RT-Ticket-4623@openssl.org>
 <rt-4.0.19-17767-1469207682-1718.4623-6-0@openssl.org>
 <2130579.1c3FUNMuLe@pintsize.usersys.redhat.com>
 <rt-4.0.19-17767-1469208605-45.4623-6-0@openssl.org>
 <CAF8qwaB=AJ92haKOR_vn9yF2jJD=E8tGt2MQ2L=1kUGVuaWGCw@mail.gmail.com>
 <rt-4.0.19-17767-1469225776-1151.4623-6-0@openssl.org>
 <20160723125006.GA14541@roeckx.be>
 <rt-4.0.19-17448-1469278224-464.4623-6-0@openssl.org>
 <319723939.18578758.1469310330341.JavaMail.zimbra@redhat.com>
Message-ID: <rt-4.0.19-17767-1469313562-1970.4623-6-0@openssl.org>

----- Original Message -----
> From: "Kurt Roeckx via RT" <rt at openssl.org>
> To: hkario at redhat.com
> Cc: openssl-dev at openssl.org
> Sent: Saturday, July 23, 2016 2:50:24 PM
> Subject: Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange
> messages in RSA key exchange
> 
> On Fri, Jul 22, 2016 at 10:16:16PM +0000, David Benjamin via RT wrote:
> > On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT <rt at openssl.org> wrote:
> > 
> > > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> > > > On Fri Jul 22 14:56:11 2016, hkario at redhat.com wrote:
> > > > > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > > > > been
> > > >
> > > > > introduced in commit:
> > > > I tried what I thought was a fix for this which is to simply delete the
> > > > lines:
> > > >
> > > > if (decrypt_len < 0)
> > > > goto err;
> > > >
> > > > from ssl/statem/statem_srvr.c
> > > >
> > > > However your reproducer still indicates errors. I checked the message
> > > logs
> > > > and it should be now sending as many alerts as the original. The
> > > difference
> > > > however is that some of them will be sent immediately whereas
> > > > originally
> > > > they would be at the end of the handshake.
> > > >
> > > > Could your reproducer possibly not be expecting this?
> > >
> > >
> > > sorry, I copied this part:
> > >
> > > > when the OpenSSL receives a Client Key Exchange message that has the
> > > > encrypted
> > > > premaster secret comprised only of zero bytes, or equal to server's
> > > modulus,
> > > > the server just aborts the connection without sending an Alert message
> > >
> > > from the DHE/ECDHE bug reports
> > >
> > > the expected behaviour is to continue the connection, but the server
> > > should
> > > select a premaster secret that was not provided by the client, instead
> > > OpenSSL
> > > just closes the connection
> > >
> > 
> > I don't believe this test is correct if the encrypted premaster is equal to
> > the server's modulus. Such an encrypted premaster is a publicly invalid RSA
> > ciphertext. It is perfectly reasonable to reject it early, should unpadded
> > RSA_decrypt fail. The timing sensitive portion is the padding check itself,
> > which this code should correctly defer failure of, to avoid the padding
> > oracle.
> 
> I think that the test suite should allow for either of 2
> behaviours in case of the public failures:
> - It continues with a random premaster secret.
> - It generates an error.
> 
> From what I understand it now complains that we don't do the first,
> so I think it should get changed to allow both behaviours.

I can change it to do that, thing is, that this behaviour will not be shared
with NSS or GnuTLS (and likely other implementations), so it makes
fingerprinting OpenSSL easier.

> > It is true that it no longer sends an alert on public failures. Probably
> > worth fixing. Meh.
> 
> I don't care for which behaviour we go, and I guess that if we go
> for generating an error we should send an alert.

yes, if you opt for aborting early, to quote RFC, you MUST send an alert

> I don't see the point in wasting time for what most likely seems
> to be an attack.

you don't have to actually perform the RSA operation, but IMHO the handshake
should continue

> What I don't understand currently is that it also rejected a
> ciphertext with all 0's?  Were it too many 0's?

yes, there are few tests with 0's, some of them will have too many 0's :)
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted


From richmoore44 at gmail.com  Sun Jul 24 16:31:20 2016
From: richmoore44 at gmail.com (Richard Moore)
Date: Sun, 24 Jul 2016 17:31:20 +0100
Subject: [openssl-dev] Missing accessor - DSA key length
Message-ID: <CAMp7mVvewGNXP+zvZAVUWAY2TqEgRW2iAs4z=av67sGeYSP13g@mail.gmail.com>

For RSA we have RSA_bits(), for DH we have DH_bits() for DSA we seem to
only have DSA_size().

Cheers

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160724/44cde681/attachment.html>

From richmoore44 at gmail.com  Sun Jul 24 16:38:17 2016
From: richmoore44 at gmail.com (Richard Moore)
Date: Sun, 24 Jul 2016 17:38:17 +0100
Subject: [openssl-dev] Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);
Message-ID: <CAMp7mVvjE5COSXWEPXEaXyWpYVHHWLfChZei9o-3LTL0u3nTyw@mail.gmail.com>

Shouldn't this be  EC_KEY *EC_KEY_dup(const EC_KEY *src);

Cheers

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160724/63a982f7/attachment.html>

From rsalz at akamai.com  Sun Jul 24 17:19:05 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 24 Jul 2016 17:19:05 +0000
Subject: [openssl-dev] Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);
In-Reply-To: <CAMp7mVvjE5COSXWEPXEaXyWpYVHHWLfChZei9o-3LTL0u3nTyw@mail.gmail.com>
References: <CAMp7mVvjE5COSXWEPXEaXyWpYVHHWLfChZei9o-3LTL0u3nTyw@mail.gmail.com>
Message-ID: <a62628880fea43fa8505f895c22f03c2@usma1ex-dag1mb1.msg.corp.akamai.com>


> Shouldn't this be ?EC_KEY *EC_KEY_dup(const EC_KEY *src);

I think the reason it is not is because the EC_KEY has an ENGINE* and that can't be const.

Sigh, C needs 'mutable' :)

From anirudhp at avaya.com  Sun Jul 24 18:18:03 2016
From: anirudhp at avaya.com (Patel, Anirudh (Anirudh))
Date: Sun, 24 Jul 2016 18:18:03 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving
 strange with X509_LOOKUP_add_dir
Message-ID: <B11D088B738A4B4B9066D5CA97E2D2FB3AC34389@AZ-FFEXMB01.global.avaya.com>

Thanks a lot !!! Will definitely try it out :)

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Stephen Henson via RT
Sent: Friday, July 22, 2016 6:30 PM
To: patel3.anirudh at gmail.com
Cc: openssl-dev at openssl.org
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange with X509_LOOKUP_add_dir

On Tue Jul 19 22:23:56 2016, steve wrote:
>
> If there are multiple CRLs with the appropriate scope then the first 
> one where the current time falls between lastUpdate and nextUpdate is 
> used.
>
> It is possible to dynamically update CRLs but currently only the time 
> criteria is used. So if the first one fails the time test the next is 
> used.
> This isn't
> ideal and something relying on the most recent or the highest CRL 
> number would be preferable.
>

Please try the attached patch. This should end up using the most recent CRL instead of the first one it sees. I've done some checks and dynamic update works with this change. Note that if you happen to have two CRLs with an identical lastUpdate field (down to the second) then it will just use the first CRL it encounters again. This shouldn't be a problem in practice.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org&d=CwIDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=Bp9lSVfhFc-th0U-IyFkeQcZQug-CiqCOfq-N31Qu2s&s=62lTiIwo2lck_8lcBo4hTfIoJrhOkXQVrqZ2t74883E&e= 

--
Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4615&d=CwIDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=Bp9lSVfhFc-th0U-IyFkeQcZQug-CiqCOfq-N31Qu2s&s=LPnwRaPZtcWPkD-YcbSu1TqJ_bz0Y472yAqF0f2ULFM&e=
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 24 18:29:16 2016
From: rt at openssl.org (Patel, Anirudh via RT)
Date: Sun, 24 Jul 2016 18:29:16 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving
	strange with X509_LOOKUP_add_dir
In-Reply-To: <B11D088B738A4B4B9066D5CA97E2D2FB3AC34389@AZ-FFEXMB01.global.avaya.com>
References: <RT-Ticket-4615@openssl.org>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC34389@AZ-FFEXMB01.global.avaya.com>
Message-ID: <rt-4.0.19-17448-1469384956-1019.4615-6-0@openssl.org>

Thanks a lot !!! Will definitely try it out :)

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Stephen Henson via RT
Sent: Friday, July 22, 2016 6:30 PM
To: patel3.anirudh at gmail.com
Cc: openssl-dev at openssl.org
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange with X509_LOOKUP_add_dir

On Tue Jul 19 22:23:56 2016, steve wrote:
>
> If there are multiple CRLs with the appropriate scope then the first 
> one where the current time falls between lastUpdate and nextUpdate is 
> used.
>
> It is possible to dynamically update CRLs but currently only the time 
> criteria is used. So if the first one fails the time test the next is 
> used.
> This isn't
> ideal and something relying on the most recent or the highest CRL 
> number would be preferable.
>

Please try the attached patch. This should end up using the most recent CRL instead of the first one it sees. I've done some checks and dynamic update works with this change. Note that if you happen to have two CRLs with an identical lastUpdate field (down to the second) then it will just use the first CRL it encounters again. This shouldn't be a problem in practice.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org&d=CwIDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=Bp9lSVfhFc-th0U-IyFkeQcZQug-CiqCOfq-N31Qu2s&s=62lTiIwo2lck_8lcBo4hTfIoJrhOkXQVrqZ2t74883E&e= 

--
Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4615&d=CwIDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=Bp9lSVfhFc-th0U-IyFkeQcZQug-CiqCOfq-N31Qu2s&s=LPnwRaPZtcWPkD-YcbSu1TqJ_bz0Y472yAqF0f2ULFM&e=
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted


From levitte at openssl.org  Sun Jul 24 20:05:15 2016
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 24 Jul 2016 22:05:15 +0200 (CEST)
Subject: [openssl-dev] Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);
In-Reply-To: <a62628880fea43fa8505f895c22f03c2@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAMp7mVvjE5COSXWEPXEaXyWpYVHHWLfChZei9o-3LTL0u3nTyw@mail.gmail.com>
 <a62628880fea43fa8505f895c22f03c2@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160724.220515.1172616798240207500.levitte@openssl.org>

In message <a62628880fea43fa8505f895c22f03c2 at usma1ex-dag1mb1.msg.corp.akamai.com> on Sun, 24 Jul 2016 17:19:05 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> 
rsalz> > Shouldn't this be ?EC_KEY *EC_KEY_dup(const EC_KEY *src);
rsalz> 
rsalz> I think the reason it is not is because the EC_KEY has an ENGINE* and that can't be const.

The pointer to ENGINE will be const, yes, but not the ENGINE content
itself, as if it was defined like this:

    ENGINE * const engine;

What happens is that the ENGINE pointer is copied to the new
structure, and the ENGINE itself will work perfectly, both in the
source EC_KEY and the new one.

So there's no actual reason not to have const there.  It does,
however, mean that we need to add const in a few more places.  Now
many at all, actually, it took me 5 minutes.  PR coming tomorrow.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Sun Jul 24 20:33:34 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Sun, 24 Jul 2016 20:33:34 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange
	with X509_LOOKUP_add_dir
In-Reply-To: <rt-4.0.19-17448-1469384956-584.4615-6-0@openssl.org>
References: <RT-Ticket-4615@openssl.org>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC34389@AZ-FFEXMB01.global.avaya.com>
 <rt-4.0.19-17448-1469384956-584.4615-6-0@openssl.org>
Message-ID: <rt-4.0.19-17448-1469392414-1635.4615-6-0@openssl.org>

On Sun Jul 24 18:29:16 2016, anirudhp at avaya.com wrote:
> Thanks a lot !!! Will definitely try it out :)
>

Note that this bugfix is now in OpenSSL 1.0.2 and the master branch so
alternatively just try a recent snapshot.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 24 20:38:52 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Sun, 24 Jul 2016 20:38:52 +0000
Subject: [openssl-dev] [openssl.org #4613] openssl RSA key: verify error
	1.0.1t
In-Reply-To: <1b7fce0b.a33f.155d955f770.Coremail.13731461987@126.com>
References: <RT-Ticket-4613@openssl.org>
 <1b7fce0b.a33f.155d955f770.Coremail.13731461987@126.com>
Message-ID: <rt-4.0.19-17767-1469392732-930.4613-6-0@openssl.org>

On Mon Jul 11 12:10:27 2016, 13731461987 at 126.com wrote:
>
> I was trying to install openssl 1.0.1t on AIX5.3, and it report error
> when running "make test". Below is the error test.
>
> CMS consistency test
> /usr/bin/perl cms-test.pl
> CMS => PKCS#7 compatibility tests
> signed content DER format, RSA key: verify error
> make: 1254-004 The error code from the last command is 1.
>
> Stop.
> make: 1254-004 The error code from the last command is 2.
>
> Could you please help to confirm whether it's a BUG, or Could you
> please to give me some advice about this error.
>

Other platforms don't give that error. It could be a compiler issuer. You could
try updating the compiler version or turing optimisation off to see if you
still get it.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4613
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 08:49:27 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 25 Jul 2016 08:49:27 +0000
Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32
In-Reply-To: <CAH8yC8m0tt3xPMK2QKgbrL9dR_wmyJvp2nNNK+hS0sz4bs7ZsQ@mail.gmail.com>
References: <RT-Ticket-4584@openssl.org>
 <CAH8yC8m0tt3xPMK2QKgbrL9dR_wmyJvp2nNNK+hS0sz4bs7ZsQ@mail.gmail.com>
Message-ID: <rt-4.0.19-13376-1469436567-1526.4584-6-0@openssl.org>

Ping Jeff?

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 09:41:19 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 25 Jul 2016 09:41:19 +0000
Subject: [openssl-dev] [openssl.org #4618] BUG: Crash in do_ssl3_write
	unless OPENSSL_NO_MULTIBLOCK
In-Reply-To: <hOn6k-l3ABgU06tlqEGeAaD8TWej3wFHtVPHcw79FRrwuSY44@outlook.office365.com>
References: <RT-Ticket-4618@openssl.org>
 <hOn6k-l3ABgU06tlqEGeAaD8TWej3wFHtVPHcw79FRrwuSY44@outlook.office365.com>
Message-ID: <rt-4.0.19-13377-1469439679-1750.4618-6-0@openssl.org>

On Wed Jul 20 19:46:37 2016, dmb at inky.com wrote:
> OS: Mac OS X 11.11.5
> Version: OpenSSL 1.1-pre6 (head code as of yesterday)
> When the server fails under some circumstances, this line reads a bad
> address:
> /* write the header */
>
> *(outbuf[j]++) = type & 0xff;
>
> Because outbuf is 3. This is because prior to the alignment code,
> outbuf is
> NULL.
> outbuf is set to s->rlayer->wbuf[0].buf, which at that point has been
> set to
> NULL by the code guarded by
> #if !defined(OPENSSL_NO_MULTIBLOCK) && EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
>
> in ssl3_write_bytes.
> I'm sorry I can't give you a simple reproducer; I was able to
> reproduce it by
> mailing very large files with our mail app. Eventually the Exchange
> server
> fails and downstream code resets the write buffer and the multiblock
> code sets
> s->rlayer->wbuf[0].buf to NULL.
> The workaround is to compile with -DOPENSSL_NO_MULTIBLOCK -- I've
> verified
> that this eliminates the crash in practice.
> Feel free to email me if you want me to put in to some test code and
> reproduce
> it.
> Dave
> Sent with [inky](http://inky.com?kme=signature)

Hi Dave

Please could you try the attached patch and see if that resolves the issue?

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4618
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-multiblock-crash.patch
Type: text/x-patch
Size: 6255 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/dcd0357c/attachment-0001.bin>

From cata.vasile at nxp.com  Mon Jul 25 09:45:05 2016
From: cata.vasile at nxp.com (Catalin Vasile)
Date: Mon, 25 Jul 2016 09:45:05 +0000
Subject: [openssl-dev] Cross-compiling, --install_prefix deprecated
Message-ID: <DB5PR04MB1302CC1B0C15FB9F210419E2EE0D0@DB5PR04MB1302.eurprd04.prod.outlook.com>

Hi,

I keep building/testing features for OpenSSL for an embedded system and I need to be able to send my work on the board.
The build scenario is something like this:
1. make/build
2. install in temporary NFS shared folder
3. on the board I run a bash script that just does a copy in the regular /usr folder

On older releases, the Configure script in OpenSSL had a "--install_prefix" flag that, when "make install" was issued, it installed all the things in the specified install prefix, but the whole library saw itself as being installed in /usr, although I might have been installed it in /home/....
When I issued the copy script on the board, the files were actually copied at /usr, so the library knew a correct location when ran on the board.
Using the "--prefix" on the older build got the library in the correct location, but when copied on the board the binaries ran nuts because it was yelling "why aren't my files in /home/...".
Now on the newer builds I can't find "--install_prefix", and setting "--prefix" "--openssldir" and "--libdir" makes my "make install" build running in a lot of errors.

Long story short: How do I install the newest OpenSSL version in a temporary folder, but also make the system that uses it see it in the regular /usr folder after I copy it there?

Cata

From rt at openssl.org  Mon Jul 25 10:30:45 2016
From: rt at openssl.org (Steffen Nurpmeso via RT)
Date: Mon, 25 Jul 2016 10:30:45 +0000
Subject: [openssl-dev] [openssl.org #4627] Doc patch: fix constant names
In-Reply-To: <20160725102515.VmrM0ajh9%steffen@sdaoden.eu>
References: <RT-Ticket-4627@openssl.org>
 <20160725102515.VmrM0ajh9%steffen@sdaoden.eu>
Message-ID: <rt-4.0.19-13376-1469442645-638.4627-21-0@openssl.org>

Against [80f397e]

diff --git a/doc/ssl/SSL_CONF_cmd.pod b/doc/ssl/SSL_CONF_cmd.pod
index fb39f94..7b38489 100644
--- a/doc/ssl/SSL_CONF_cmd.pod
+++ b/doc/ssl/SSL_CONF_cmd.pod
@@ -124,8 +124,8 @@ than the deprecated alternative commands below.
 =item B<-no_ssl3>, B<-no_tls1>, B<-no_tls1_1>, B<-no_tls1_2>
 
 Disables protocol support for SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2 by setting the
-corresponding options B<SSL_OP_NO_SSL3>, B<SSL_OP_NO_TLS1>, B<SSL_OP_NO_TLS1_1>
-and B<SSL_OP_NO_TLS1_2> respectively.
+corresponding options B<SSL_OP_NO_SSLv3>, B<SSL_OP_NO_TLSv1>, B<SSL_OP_NO_TLSv1_1>
+and B<SSL_OP_NO_TLSv1_2> respectively.
 These options are deprecated, instead use B<-min_protocol> and B<-max_protocol>.
 
 =item B<-bugs>

--steffen


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4627
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 11:32:17 2016
From: rt at openssl.org (msalle@nikhef.nl via RT)
Date: Mon, 25 Jul 2016 11:32:17 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160725113156.GA10260@nikhef.nl>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-17448-1469267058-417.4602-6-0@openssl.org>
 <20160725113156.GA10260@nikhef.nl>
Message-ID: <rt-4.0.19-13376-1469446337-667.4602-6-0@openssl.org>

On Sat, Jul 23, 2016 at 09:44:18AM +0000, Richard Levitte via RT wrote:
> To get current_cert, it's X509_STORE_CTX_get_current_cert().
> To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()

Hi Richard,

yes, those I know, but the problem is the *setting* of the failing cert.
Since we need to walk the whole chain for the proxy pathlength
verification, we need to be able to indicate which cert is failing. See
e.g.
https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L1691
and further, in particular line 1731.
VOMS is basically using the same code
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c#L2236
and further, in particular line 2255.

Jan Just also sets the current_issuer in his grid-proxy-verify.c,
http://www.nikhef.nl/~janjust/proxy-verify/
line 346, but I'm not sure that's necessary.

    Mischa

> 
> Those functions are already present in pre-1.1 OpenSSL (at least in the 1.0.2
> series)
> 
> On Fri Jul 22 15:51:16 2016, msalle at nikhef.nl wrote:
> > Hi,
> >
> > unless I didn't look careful enough I think we might still be missing
> > the current_cert (and current_issuer) from the X509_STORE_CTX, as
> > advertised in
> >
> https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > and used in e.g.
> > https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > and many other places for verifying the proxy chain or is there a
> > better/other solution for that?
> >
> > Best wishes,
> > Mischa
> >
> > On Fri, Jul 22, 2016 at 03:26:26PM +0000, Richard Levitte via RT
> > wrote:
> > > In addition to github PR 1294, there's now also PR 1339 which adds
> > > the function to set the EXFLAG_PROXY flag on a given certificate.
> > >
> > > Also, PR 1295 has been updated. Instead of a function that returns a
> > > lock, there is now a lock and an unlock function.
> > >
> > > To me, it seems that that covers what's being asked for. Perhaps not
> > > exactly (the setters are for X509_STORE only), but should be
> > > workable.
> > >
> > > (writing this from my mobile, sorry for the lack of github links)
> > >
> > > --
> > > Richard Levitte
> > > levitte at openssl.org
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > Please log in as guest with password guest if prompted
> > >
> > > --
> > > To unsubscribe, send mail to 829272-unsubscribe at bugs.debian.org.
> 
> 
> --
> Richard Levitte
> levitte at openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3382 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/31f08dee/attachment.bin>

From rt at openssl.org  Mon Jul 25 11:46:50 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 25 Jul 2016 11:46:50 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-13376-1469446337-225.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-17448-1469267058-417.4602-6-0@openssl.org>
 <20160725113156.GA10260@nikhef.nl>
 <rt-4.0.19-13376-1469446337-225.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-13377-1469447210-1905.4602-6-0@openssl.org>

On Mon Jul 25 11:32:17 2016, msalle at nikhef.nl wrote:
> On Sat, Jul 23, 2016 at 09:44:18AM +0000, Richard Levitte via RT
> wrote:
> > To get current_cert, it's X509_STORE_CTX_get_current_cert().
> > To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()
>
> Hi Richard,
>
> yes, those I know, but the problem is the *setting* of the failing
> cert.
> Since we need to walk the whole chain for the proxy pathlength
> verification, we need to be able to indicate which cert is failing.
> See
> e.g.
> https://github.com/globus/globus-
>
toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L1691
> and further, in particular line 1731.
> VOMS is basically using the same code
> https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c#L2236
> and further, in particular line 2255.

Is that code to cope with pathlen checking bugs? That's what it looks to me. In
that case, it might no longer be needed with OpenSSL 1.1, along with some other
stuff (the subject checking stuff comes to mind). Quite frankly, I think the
grid source needs a good and hard look over, quite a bit of it shouldn't be
needed any more. The exception is recognising pre-3820 proxy certs.

> Jan Just also sets the current_issuer in his grid-proxy-verify.c,
> http://www.nikhef.nl/~janjust/proxy-verify/
> line 346, but I'm not sure that's necessary.

> Mischa
>
> >
> > Those functions are already present in pre-1.1 OpenSSL (at least in
> > the 1.0.2
> > series)
> >
> > On Fri Jul 22 15:51:16 2016, msalle at nikhef.nl wrote:
> > > Hi,
> > >
> > > unless I didn't look careful enough I think we might still be
> > > missing
> > > the current_cert (and current_issuer) from the X509_STORE_CTX, as
> > > advertised in
> > >
> >
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > > and used in e.g.
> > > https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > > and many other places for verifying the proxy chain or is there a
> > > better/other solution for that?
> > >
> > > Best wishes,
> > > Mischa
> > >
> > > On Fri, Jul 22, 2016 at 03:26:26PM +0000, Richard Levitte via RT
> > > wrote:
> > > > In addition to github PR 1294, there's now also PR 1339 which
> > > > adds
> > > > the function to set the EXFLAG_PROXY flag on a given certificate.
> > > >
> > > > Also, PR 1295 has been updated. Instead of a function that
> > > > returns a
> > > > lock, there is now a lock and an unlock function.
> > > >
> > > > To me, it seems that that covers what's being asked for. Perhaps
> > > > not
> > > > exactly (the setters are for X509_STORE only), but should be
> > > > workable.
> > > >
> > > > (writing this from my mobile, sorry for the lack of github links)
> > > >
> > > > --
> > > > Richard Levitte
> > > > levitte at openssl.org
> > > > --
> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > Please log in as guest with password guest if prompted
> > > >
> > > > --
> > > > To unsubscribe, send mail to 829272-unsubscribe at bugs.debian.org.
> >
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From levitte at openssl.org  Mon Jul 25 11:56:08 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 25 Jul 2016 13:56:08 +0200 (CEST)
Subject: [openssl-dev] Cross-compiling, --install_prefix deprecated
In-Reply-To: <DB5PR04MB1302CC1B0C15FB9F210419E2EE0D0@DB5PR04MB1302.eurprd04.prod.outlook.com>
References: <DB5PR04MB1302CC1B0C15FB9F210419E2EE0D0@DB5PR04MB1302.eurprd04.prod.outlook.com>
Message-ID: <20160725.135608.2239988517196116968.levitte@openssl.org>

In message <DB5PR04MB1302CC1B0C15FB9F210419E2EE0D0 at DB5PR04MB1302.eurprd04.prod.outlook.com> on Mon, 25 Jul 2016 09:45:05 +0000, Catalin Vasile <cata.vasile at nxp.com> said:

cata.vasile> Hi,

Hi

cata.vasile> I keep building/testing features for OpenSSL for an embedded system and I need to be able to send my work on the board.
cata.vasile> The build scenario is something like this:
cata.vasile> 1. make/build
cata.vasile> 2. install in temporary NFS shared folder
cata.vasile> 3. on the board I run a bash script that just does a copy in the regular /usr folder
cata.vasile> 
cata.vasile> On older releases, the Configure script in OpenSSL had a "--install_prefix" flag that, when "make install" was issued, it installed all the things in the specified install prefix, but the whole library saw itself as being installed in /usr, although I might have been installed it in /home/....
cata.vasile> When I issued the copy script on the board, the files were actually copied at /usr, so the library knew a correct location when ran on the board.
cata.vasile> Using the "--prefix" on the older build got the library in the correct location, but when copied on the board the binaries ran nuts because it was yelling "why aren't my files in /home/...".
cata.vasile> Now on the newer builds I can't find "--install_prefix", and setting "--prefix" "--openssldir" and "--libdir" makes my "make install" build running in a lot of errors.
cata.vasile> 
cata.vasile> Long story short: How do I install the newest OpenSSL version in a temporary folder, but also make the system that uses it see it in the regular /usr folder after I copy it there?

The following note from CHANGES answers most of your question:

  *) The INSTALL_PREFIX Makefile variable has been renamed to
     DESTDIR.  That makes for less confusion on what this variable
     is for.  Also, the configuration option --install_prefix is
     removed.
     [Richard Levitte]

There are also a few lines in INSTALL that talk about this:

     Package builders who want to configure the library for standard
     locations, but have the package installed somewhere else so that
     it can easily be packaged, can use

       $ make DESTDIR=/tmp/package-root install         # Unix
       $ mms/macro="DESTDIR=TMP:[PACKAGE-ROOT]" install ! OpenVMS

     The specified destination directory will be prepended to all
     installation target paths.

Also, --prefix and --openssldir don't work exactly like before.  They
are not as inter-dependence as they used to be.  You will find them
documented in INSTALL as well.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Mon Jul 25 12:39:43 2016
From: rt at openssl.org (msalle@nikhef.nl via RT)
Date: Mon, 25 Jul 2016 12:39:43 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160725123928.GB10260@nikhef.nl>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-17448-1469267058-417.4602-6-0@openssl.org>
 <20160725113156.GA10260@nikhef.nl>
 <rt-4.0.19-13376-1469446337-225.4602-6-0@openssl.org>
 <rt-4.0.19-13377-1469447210-1905.4602-6-0@openssl.org>
 <20160725123928.GB10260@nikhef.nl>
Message-ID: <rt-4.0.19-13377-1469450383-532.4602-6-0@openssl.org>

Hi Richard,

On Mon, Jul 25, 2016 at 11:46:50AM +0000, Richard Levitte via RT wrote:
> Is that code to cope with pathlen checking bugs? That's what it looks to me. In
> that case, it might no longer be needed with OpenSSL 1.1, along with some other
> stuff (the subject checking stuff comes to mind). Quite frankly, I think the
> grid source needs a good and hard look over, quite a bit of it shouldn't be
> needed any more. The exception is recognising pre-3820 proxy certs.
Yes it is, and although it's true that it's probably not needed for
RFC3820 proxy certs (although I haven't checked that) but we will need
to be able to verify GT3 proxies and we will need to be able to do the
whole chain verification there with the callback...
    
    Mischa

> > Jan Just also sets the current_issuer in his grid-proxy-verify.c,
> > http://www.nikhef.nl/~janjust/proxy-verify/
> > line 346, but I'm not sure that's necessary.
> 
> > Mischa
> >
> > >
> > > Those functions are already present in pre-1.1 OpenSSL (at least in
> > > the 1.0.2
> > > series)
> > >
> > > On Fri Jul 22 15:51:16 2016, msalle at nikhef.nl wrote:
> > > > Hi,
> > > >
> > > > unless I didn't look careful enough I think we might still be
> > > > missing
> > > > the current_cert (and current_issuer) from the X509_STORE_CTX, as
> > > > advertised in
> > > >
> > >
> https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > > > and used in e.g.
> > > > https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > > > and many other places for verifying the proxy chain or is there a
> > > > better/other solution for that?
> > > >
> > > > Best wishes,
> > > > Mischa
> > > >
> > > > On Fri, Jul 22, 2016 at 03:26:26PM +0000, Richard Levitte via RT
> > > > wrote:
> > > > > In addition to github PR 1294, there's now also PR 1339 which
> > > > > adds
> > > > > the function to set the EXFLAG_PROXY flag on a given certificate.
> > > > >
> > > > > Also, PR 1295 has been updated. Instead of a function that
> > > > > returns a
> > > > > lock, there is now a lock and an unlock function.
> > > > >
> > > > > To me, it seems that that covers what's being asked for. Perhaps
> > > > > not
> > > > > exactly (the setters are for X509_STORE only), but should be
> > > > > workable.
> > > > >
> > > > > (writing this from my mobile, sorry for the lack of github links)
> > > > >
> > > > > --
> > > > > Richard Levitte
> > > > > levitte at openssl.org
> > > > > --
> > > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > > Please log in as guest with password guest if prompted
> > > > >
> > > > > --
> > > > > To unsubscribe, send mail to 829272-unsubscribe at bugs.debian.org.
> > >
> > >
> > > --
> > > Richard Levitte
> > > levitte at openssl.org
> > >
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > Please log in as guest with password guest if prompted
> > >
> 
> 
> --
> Richard Levitte
> levitte at openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3382 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/a2da6414/attachment.bin>

From rsalz at akamai.com  Mon Jul 25 12:42:18 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 25 Jul 2016 12:42:18 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-13377-1469450383-532.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-17448-1469267058-417.4602-6-0@openssl.org>
 <20160725113156.GA10260@nikhef.nl>
 <rt-4.0.19-13376-1469446337-225.4602-6-0@openssl.org>
 <rt-4.0.19-13377-1469447210-1905.4602-6-0@openssl.org>
 <20160725123928.GB10260@nikhef.nl>
 <rt-4.0.19-13377-1469450383-532.4602-6-0@openssl.org>
Message-ID: <587aed903d1647c7b86a173d7958dc8e@usma1ex-dag1mb1.msg.corp.akamai.com>

Perhaps the GRID folks can just write their own validation routine completely?




From rt at openssl.org  Mon Jul 25 12:42:21 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Mon, 25 Jul 2016 12:42:21 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <587aed903d1647c7b86a173d7958dc8e@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl> <20160725113156.GA10260@nikhef.nl>
 <rt-4.0.19-13376-1469446337-225.4602-6-0@openssl.org>
 <rt-4.0.19-13377-1469447210-1905.4602-6-0@openssl.org>
 <20160725123928.GB10260@nikhef.nl>
 <rt-4.0.19-13377-1469450383-532.4602-6-0@openssl.org>
 <587aed903d1647c7b86a173d7958dc8e@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-13377-1469450541-1063.4602-6-0@openssl.org>

Perhaps the GRID folks can just write their own validation routine completely?




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 12:46:49 2016
From: rt at openssl.org (msalle@nikhef.nl via RT)
Date: Mon, 25 Jul 2016 12:46:49 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160725124636.GC10260@nikhef.nl>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-13377-1469447210-1905.4602-6-0@openssl.org>
 <20160725123928.GB10260@nikhef.nl>
 <rt-4.0.19-13377-1469450383-532.4602-6-0@openssl.org>
 <587aed903d1647c7b86a173d7958dc8e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-13377-1469450541-1063.4602-6-0@openssl.org>
 <20160725124636.GC10260@nikhef.nl>
Message-ID: <rt-4.0.19-13376-1469450809-349.4602-6-0@openssl.org>

On Mon, Jul 25, 2016 at 12:42:21PM +0000, Salz, Rich via RT wrote:
> Perhaps the GRID folks can just write their own validation routine completely?

That's exactly what we currently do, we provide a verification callback,
but we do need to be able to set the failing cert in a chain for that.

    Mischa


> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3382 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/1f173c0e/attachment.bin>

From rsalz at akamai.com  Mon Jul 25 12:47:53 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 25 Jul 2016 12:47:53 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-13376-1469450809-349.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-13377-1469447210-1905.4602-6-0@openssl.org>
 <20160725123928.GB10260@nikhef.nl>
 <rt-4.0.19-13377-1469450383-532.4602-6-0@openssl.org>
 <587aed903d1647c7b86a173d7958dc8e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-13377-1469450541-1063.4602-6-0@openssl.org>
 <20160725124636.GC10260@nikhef.nl>
 <rt-4.0.19-13376-1469450809-349.4602-6-0@openssl.org>
Message-ID: <f23ea2a4704e491e81b2cd194a59c173@usma1ex-dag1mb1.msg.corp.akamai.com>


> That's exactly what we currently do, we provide a verification callback, but
> we do need to be able to set the failing cert in a chain for that.

Stick it in EXDAT?

From rt at openssl.org  Mon Jul 25 12:47:56 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Mon, 25 Jul 2016 12:47:56 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <f23ea2a4704e491e81b2cd194a59c173@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-13377-1469450383-532.4602-6-0@openssl.org>
 <587aed903d1647c7b86a173d7958dc8e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-13377-1469450541-1063.4602-6-0@openssl.org>
 <20160725124636.GC10260@nikhef.nl>
 <rt-4.0.19-13376-1469450809-349.4602-6-0@openssl.org>
 <f23ea2a4704e491e81b2cd194a59c173@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-13376-1469450876-659.4602-6-0@openssl.org>


> That's exactly what we currently do, we provide a verification callback, but
> we do need to be able to set the failing cert in a chain for that.

Stick it in EXDAT?

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 13:05:39 2016
From: rt at openssl.org (msalle@nikhef.nl via RT)
Date: Mon, 25 Jul 2016 13:05:39 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160725130526.GD10260@nikhef.nl>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-13377-1469450541-1063.4602-6-0@openssl.org>
 <20160725124636.GC10260@nikhef.nl>
 <rt-4.0.19-13376-1469450809-349.4602-6-0@openssl.org>
 <f23ea2a4704e491e81b2cd194a59c173@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-13376-1469450876-659.4602-6-0@openssl.org>
 <20160725130526.GD10260@nikhef.nl>
Message-ID: <rt-4.0.19-13376-1469451939-190.4602-6-0@openssl.org>

On Mon, Jul 25, 2016 at 12:47:56PM +0000, Salz, Rich via RT wrote:
> 
> > That's exactly what we currently do, we provide a verification callback, but
> > we do need to be able to set the failing cert in a chain for that.
> 
> Stick it in EXDAT?

I don't think I understand what you mean...
For a proper callback, we need to be able to indicate which cert in the
chain has failed. This used to be done by setting the 'current_cert'
field in the CTX. I'm perfectly happy if we need to do this differently
e.g. by using something like a
    X509_STORE_CTX_set_error_depth(X509_STORE_CTX *ctx,int depth);
similar to the existing X509_STORE_CTX_get_error_depth()
That actually would make the most sense in any case I would think,
although I would mean that for properly handling proxy chains it would
have negative values according to the man-page...

    Mischa


-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3382 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/bb957836/attachment.bin>

From rsalz at akamai.com  Mon Jul 25 13:44:11 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 25 Jul 2016 13:44:11 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-13376-1469451939-190.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-13377-1469450541-1063.4602-6-0@openssl.org>
 <20160725124636.GC10260@nikhef.nl>
 <rt-4.0.19-13376-1469450809-349.4602-6-0@openssl.org>
 <f23ea2a4704e491e81b2cd194a59c173@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-13376-1469450876-659.4602-6-0@openssl.org>
 <20160725130526.GD10260@nikhef.nl>
 <rt-4.0.19-13376-1469451939-190.4602-6-0@openssl.org>
Message-ID: <2d016873c52746f198286f735aaeb3a6@usma1ex-dag1mb1.msg.corp.akamai.com>

I am not sure what to suggest.  This conversation is bouncing across two ticket systems and is all about a legacy certificate format that is, what, outdated since 2002?

I am hard-pressed to see why OpenSSL 1.1 has to do anything other than what Richard proposed.

From rt at openssl.org  Mon Jul 25 13:44:18 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Mon, 25 Jul 2016 13:44:18 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <2d016873c52746f198286f735aaeb3a6@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-13376-1469450809-349.4602-6-0@openssl.org>
 <f23ea2a4704e491e81b2cd194a59c173@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-13376-1469450876-659.4602-6-0@openssl.org>
 <20160725130526.GD10260@nikhef.nl>
 <rt-4.0.19-13376-1469451939-190.4602-6-0@openssl.org>
 <2d016873c52746f198286f735aaeb3a6@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-13376-1469454258-1327.4602-6-0@openssl.org>

I am not sure what to suggest.  This conversation is bouncing across two ticket systems and is all about a legacy certificate format that is, what, outdated since 2002?

I am hard-pressed to see why OpenSSL 1.1 has to do anything other than what Richard proposed.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 13:51:47 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 25 Jul 2016 13:51:47 +0000
Subject: [openssl-dev] [openssl.org #4627] Doc patch: fix constant names
In-Reply-To: <20160725102515.VmrM0ajh9%steffen@sdaoden.eu>
References: <RT-Ticket-4627@openssl.org>
 <20160725102515.VmrM0ajh9%steffen@sdaoden.eu>
Message-ID: <rt-4.0.19-13376-1469454707-1616.4627-6-0@openssl.org>

commit d49cfa3 pushed to master. thanks!

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4627
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 14:28:04 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 25 Jul 2016 14:28:04 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-13377-1469450383-82.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-17448-1469267058-417.4602-6-0@openssl.org>
 <20160725113156.GA10260@nikhef.nl>
 <rt-4.0.19-13376-1469446337-225.4602-6-0@openssl.org>
 <rt-4.0.19-13377-1469447210-1905.4602-6-0@openssl.org>
 <20160725123928.GB10260@nikhef.nl>
 <rt-4.0.19-13377-1469450383-82.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-13377-1469456884-1308.4602-6-0@openssl.org>

On Mon Jul 25 12:39:43 2016, msalle at nikhef.nl wrote:
> Hi Richard,
>
> On Mon, Jul 25, 2016 at 11:46:50AM +0000, Richard Levitte via RT
> wrote:
> > Is that code to cope with pathlen checking bugs? That's what it looks
> > to me. In
> > that case, it might no longer be needed with OpenSSL 1.1, along with
> > some other
> > stuff (the subject checking stuff comes to mind). Quite frankly, I
> > think the
> > grid source needs a good and hard look over, quite a bit of it
> > shouldn't be
> > needed any more. The exception is recognising pre-3820 proxy certs.
> Yes it is, and although it's true that it's probably not needed for
> RFC3820 proxy certs (although I haven't checked that) but we will need
> to be able to verify GT3 proxies and we will need to be able to do the
> whole chain verification there with the callback...

Why do you need to do that? That sounds like your duplicating what's already
being done for reasons I cannot fathom.

BUT... I'm realising that when you do recognise a GT3 proxy (I think I've seen
check_issued functions being used for that), there's no way for external code
to set the proxy path length for the certificate in question. While that's fine
for GT2 proxies (there's no pc path length there that I can see), it does need
to be properly set for GT3 proxies.

For the rest, though, I don't quite see why you'd need to check that path
length *again* in the verification callback. The verification callback is meant
to be used for the certification currently being checked, and should return 0
or 1, depending on if you want the current certificate to verify to to fail.
That's it.

The remaining thing to check, as far as I understand, is proxy policy. The
X509_STORE_CTX ex_data is the place to accumulate data in to make sure policy
continues to be valid thoughout the verification process.

What, in all this, am I missing?

>
> Mischa
>
> > > Jan Just also sets the current_issuer in his grid-proxy-verify.c,
> > > http://www.nikhef.nl/~janjust/proxy-verify/
> > > line 346, but I'm not sure that's necessary.
> >
> > > Mischa
> > >
> > > >
> > > > Those functions are already present in pre-1.1 OpenSSL (at least
> > > > in
> > > > the 1.0.2
> > > > series)
> > > >
> > > > On Fri Jul 22 15:51:16 2016, msalle at nikhef.nl wrote:
> > > > > Hi,
> > > > >
> > > > > unless I didn't look careful enough I think we might still be
> > > > > missing
> > > > > the current_cert (and current_issuer) from the X509_STORE_CTX,
> > > > > as
> > > > > advertised in
> > > > >
> > > >
> >
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > > > > and used in e.g.
> > > > >
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > > > > and many other places for verifying the proxy chain or is there
> > > > > a
> > > > > better/other solution for that?
> > > > >
> > > > > Best wishes,
> > > > > Mischa
> > > > >
> > > > > On Fri, Jul 22, 2016 at 03:26:26PM +0000, Richard Levitte via
> > > > > RT
> > > > > wrote:
> > > > > > In addition to github PR 1294, there's now also PR 1339 which
> > > > > > adds
> > > > > > the function to set the EXFLAG_PROXY flag on a given
> > > > > > certificate.
> > > > > >
> > > > > > Also, PR 1295 has been updated. Instead of a function that
> > > > > > returns a
> > > > > > lock, there is now a lock and an unlock function.
> > > > > >
> > > > > > To me, it seems that that covers what's being asked for.
> > > > > > Perhaps
> > > > > > not
> > > > > > exactly (the setters are for X509_STORE only), but should be
> > > > > > workable.
> > > > > >
> > > > > > (writing this from my mobile, sorry for the lack of github
> > > > > > links)
> > > > > >
> > > > > > --
> > > > > > Richard Levitte
> > > > > > levitte at openssl.org
> > > > > > --
> > > > > > Ticket here:
> > > > > > http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > > > Please log in as guest with password guest if prompted
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, send mail to 829272-
> > > > > > unsubscribe at bugs.debian.org.
> > > >
> > > >
> > > > --
> > > > Richard Levitte
> > > > levitte at openssl.org
> > > >
> > > > --
> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > Please log in as guest with password guest if prompted
> > > >
> >
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >


--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 15:11:10 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 25 Jul 2016 15:11:10 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-13377-1469456884-226.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org>
 <rt-4.0.19-17448-1469267058-417.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-13376-1469459470-592.4602-6-0@openssl.org>

On Mon Jul 25 14:28:04 2016, levitte wrote:
> BUT... I'm realising that when you do recognise a GT3 proxy (I think
> I've seen
> check_issued functions being used for that), there's no way for
> external code
> to set the proxy path length for the certificate in question. While
> that's fine
> for GT2 proxies (there's no pc path length there that I can see), it
> does need
> to be properly set for GT3 proxies.

For this, https://github.com/openssl/openssl/pull/1348

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From dwmw2 at infradead.org  Mon Jul 25 15:29:49 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 25 Jul 2016 16:29:49 +0100
Subject: [openssl-dev] [PATCH] Add support for minimum and maximum
 protocol version supported by a cipher
In-Reply-To: <20160708215928.GA10679@roeckx.be>
References: <1467996201.4158.201.camel@infradead.org>
 <20160708215928.GA10679@roeckx.be>
Message-ID: <1469460589.120686.248.camel@infradead.org>

On Fri, 2016-07-08 at 23:59 +0200, Kurt Roeckx wrote:
> 
> We have no test suite coverage doing anything with DTLS1_BAD_VER
> and I think the OpenConnect VPN is the only user of it.

I added a basic test in PR #1296. It just simulates the basic session
resume and ? since it seemed relatively trivial to add while I was at
it ? out-of-order packet RX:
https://github.com/openssl/openssl/pull/1296/commits/9538be65

This test catches all the bugs that the pull request fixes, and also
tests the session resume method that OpenConnect uses, of manually
building the ASN.1 with the session details and then using
d2i_SSL_SESSION().

It validates the handshake MAC, which is different for DTLS1_BAD_VER
because it doesn't include the handshake message headers.

It also checks the handling of the 3-byte Change Cipher Spec message,
in both directions.

I'm currently trying to stop it whining about DTLSv1_client_method()
being deprecated; I can't see how to make it work using
DTLS_client_method().

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/229324f3/attachment-0001.bin>

From uri at ll.mit.edu  Mon Jul 25 15:42:12 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 25 Jul 2016 15:42:12 +0000
Subject: [openssl-dev] Discrepancy between docs and actual behavior: CMS in
	1.0.2
Message-ID: <D3BBAB8C.2FB0F%uri@ll.mit.edu>

I confess I did not test this with 1.1.x. But in 1.0.2h there?s a problem.

CMS man page says:

If the -decrypt option is used without a recipient certificate then an
attempt is made to locate the
recipient by trying each potential recipient in turn using the supplied
private key. To thwart the MMA
attack (Bleichenbacher's attack on PKCS #1 v1.5 RSA padding) all recipients
are tried whether they
succeed or not and if no recipients match the message is "decrypted" using a
random key which will
typically output garbage. The -debug_decrypt option can be used to disable
the MMA attack protection
and return an error if no recipient can be found: this option should be used
with caution.
However, the observed behavior is different:
$ openssl cms -engine pkcs11 -keyform engine -decrypt -debug_decrypt -aes256
-inform SMIME -in Cyph_Bot_test.smime.eml -outform SMIME -out
Cyph_Bot_test.decrypt1.eml -inkey
"pkcs11:object=KEY%20MAN%20key;object-type=private"
engine "pkcs11" set.
PKCS#11 token PIN:
Error decrypting CMS using private key
140735083847760:error:2E072084:CMS routines:CMS_decrypt_set1_pkey:no
matching recipient:cms_smime.c:661:
$

The following proves that the provided private key is correct (and the above
decryption should?ve succeeded):
$ openssl cms -engine pkcs11 -keyform engine -decrypt -aes256 -inform SMIME
-in Cyph_Bot_test.smime.eml -outform SMIME -out Cyph_Bot_test.decrypt.eml
-recip ~/Documents/Certs/me_mouse_yubi_9d_.pem -inkey
"pkcs11:object=KEY%20MAN%20key;object-type=private"
engine "pkcs11" set.
PKCS#11 token PIN:
$ tail Cyph_Bot_test.decrypt.eml
Message-id: <FBD81819-1B51-48CA-939B-03E6403F5A9A at us.army.mil>

It is either a bug in the man page or a bug in the code. In either case it
should be addressed.

P.S. This is how the CMS message in question was created:
$ openssl cms -engine pkcs11 -encrypt -aes256 -inform SMIME -in
Cyph_Bot_test.eml -outform SMIME -out Cyph_Bot_test.smime.eml -subject
SMIME_ECC ~/Documents/Certs/me_mouse_yubi_9d_.pem
engine "pkcs11" set.
$ tail Cyph_Bot_test.smime.eml
p7qKV4ttuid/6ynNbobYNgSUenzrmnbO0Z03KhglAy1l/om4crfK3+5r2UJ+5daf
9kL1EUrVy6flhE198793YTZJngi3zKFYk+BY2K8wNzLEoXAfJSY6a9z8RINZW9n8


-- 
Regards,
Uri Blumenthal


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/6b700abc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5227 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/6b700abc/attachment.bin>

From rt at openssl.org  Mon Jul 25 15:47:12 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 25 Jul 2016 15:47:12 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-13376-1469459470-1541.4602-6-0@openssl.org>
References: <RT-Ticket-4602@openssl.org>
 <rt-4.0.19-17448-1469267058-417.4602-6-0@openssl.org>
 <rt-4.0.19-13376-1469459470-1541.4602-6-0@openssl.org>
Message-ID: <rt-4.0.19-13377-1469461632-592.4602-6-0@openssl.org>

On Mon Jul 25 15:11:10 2016, levitte wrote:
> On Mon Jul 25 14:28:04 2016, levitte wrote:
> > BUT... I'm realising that when you do recognise a GT3 proxy (I think
> > I've seen
> > check_issued functions being used for that), there's no way for
> > external code
> > to set the proxy path length for the certificate in question. While
> > that's fine
> > for GT2 proxies (there's no pc path length there that I can see), it
> > does need
> > to be properly set for GT3 proxies.
>
> For this, https://github.com/openssl/openssl/pull/1348

... and it got through our review process pretty quickly.

All github PRs that have been mentioned so far have now been merged into
master.

I'm closing this ticket on our side (this will hopefully happen on the Debian
side as well) as it seems to be covered by the code that has now been added.

As for everything else that has been discussed here, which also touches on
external methods of verification via the verification callback, I would say
it's out of scope for this ticket. I am interested in these talks, but then by
direct email.

--

Richard Levitte
levitte at openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 15:51:47 2016
From: rt at openssl.org (msalle@nikhef.nl via RT)
Date: Mon, 25 Jul 2016 15:51:47 +0000
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160725135935.GF10260@nikhef.nl>
References: <RT-Ticket-4602@openssl.org> <20160702105929.GA9192@roeckx.be>
 <rt-4.0.19-17766-1469201186-1614.4602-6-0@openssl.org>
 <20160722154525.GE32686@nikhef.nl>
 <rt-4.0.19-13376-1469450876-659.4602-6-0@openssl.org>
 <20160725130526.GD10260@nikhef.nl>
 <rt-4.0.19-13376-1469451939-190.4602-6-0@openssl.org>
 <2d016873c52746f198286f735aaeb3a6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-13376-1469454258-1327.4602-6-0@openssl.org>
 <20160725135935.GF10260@nikhef.nl>
Message-ID: <rt-4.0.19-13376-1469461907-1144.4602-6-0@openssl.org>

On Mon, Jul 25, 2016 at 01:44:18PM +0000, Salz, Rich via RT wrote:
> I am not sure what to suggest.  This conversation is bouncing across
> two ticket systems and is all about a legacy certificate format that
> is, what, outdated since 2002?
> I am hard-pressed to see why OpenSSL 1.1 has to do anything other than
> what Richard proposed.

The two ticket systems is indeed annoying and I don't know what to do
about that (I did not start this thread) other than removing one of
them.

The point is that if OpenSSL is providing a verification callback which
can be used to provide a custom verification of the cert chain, then it
should provide the necessary handles and the thing still missing from
what Richard proposed is a way to point to the failing certificate in
the chain. We can set the error, but not at which depth in the chain the
error occurred.
This in itself is not limited to our use-case but is a general API
request.

    Mischa




> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon Jul 25 16:14:00 2016
From: rt at openssl.org (Greg Hudson via RT)
Date: Mon, 25 Jul 2016 16:14:00 +0000
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to
	overlapping regions check
In-Reply-To: <57963956.2060809@mit.edu>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
Message-ID: <rt-4.0.19-13376-1469463240-1685.4628-21-0@openssl.org>

The attached test program works in 1.0, but fails in master with:

  a.out: crypto/evp/evp_enc.c:290: is_partially_overlapping: Assertion
`!condition' failed.

See also:

  https://mta.openssl.org/pipermail/openssl-dev/2016-July/007953.html

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

-------------- next part --------------
#include <stdio.h>
#include <stdint.h>
#include <openssl/evp.h>
#include <openssl/bio.h>

int main()
{
    BIO *b;
    uint8_t key[16] = { 0 }, data[1024] = { 0 }, buf[4096];
    int l;

    b = BIO_new(BIO_f_cipher());
    BIO_set_cipher(b, EVP_aes_128_cbc(), key, NULL, 0);
    BIO_push(b, BIO_new_mem_buf(data, sizeof(data)));

    l = BIO_read(b, buf, sizeof(buf));
    printf("%d %d %d\n", l, buf[0], buf[1]);
    return 0;
}

From levitte at openssl.org  Mon Jul 25 16:21:32 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 25 Jul 2016 18:21:32 +0200 (CEST)
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-13376-1469461907-1144.4602-6-0@openssl.org>
References: <rt-4.0.19-13376-1469454258-1327.4602-6-0@openssl.org>
 <20160725135935.GF10260@nikhef.nl>
 <rt-4.0.19-13376-1469461907-1144.4602-6-0@openssl.org>
Message-ID: <20160725.182132.1017150851230052651.levitte@openssl.org>

In message <rt-4.0.19-13376-1469461907-1144.4602-6-0 at openssl.org> on Mon, 25 Jul 2016 15:51:47 +0000, "msalle at nikhef.nl via RT" <rt at openssl.org> said:

rt> On Mon, Jul 25, 2016 at 01:44:18PM +0000, Salz, Rich via RT wrote:
rt> > I am not sure what to suggest.  This conversation is bouncing across
rt> > two ticket systems and is all about a legacy certificate format that
rt> > is, what, outdated since 2002?
rt> > I am hard-pressed to see why OpenSSL 1.1 has to do anything other than
rt> > what Richard proposed.
rt> 
rt> The two ticket systems is indeed annoying and I don't know what to do
rt> about that (I did not start this thread) other than removing one of
rt> them.

One way is to exclude rt at openssl.org from your list of recipients ;-)
(I just did, btw)
I'm also taking away 829272 at bugs.debian.org

rt> The point is that if OpenSSL is providing a verification callback which
rt> can be used to provide a custom verification of the cert chain, then it
rt> should provide the necessary handles and the thing still missing from
rt> what Richard proposed is a way to point to the failing certificate in
rt> the chain. We can set the error, but not at which depth in the chain the
rt> error occurred.
rt> This in itself is not limited to our use-case but is a general API
rt> request.

Just for clarity, when I talk about the verification callback, I'm
talking about verify_cb, settable with X509_STORE_CTX_set_verify_cb()
If you're talking about something else, please correct me.

By design, verify_cb is called for *each* certificate in the chain,
and to allow the verification result for that certificate alone to be
customized.

current_cert, current_issuer, etc are meant as input for verify_cb,
indicating which certificate in the chain the call of the callback is
about.  Why one would need to tamper with them from inside the
verify_cb function escapes me...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From dwmw2 at infradead.org  Mon Jul 25 17:20:18 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 25 Jul 2016 18:20:18 +0100
Subject: [openssl-dev] [PATCH] Add support for minimum and maximum
 protocol version supported by a cipher
In-Reply-To: <1469460589.120686.248.camel@infradead.org>
References: <1467996201.4158.201.camel@infradead.org>
 <20160708215928.GA10679@roeckx.be>
 <1469460589.120686.248.camel@infradead.org>
Message-ID: <1469467218.120686.255.camel@infradead.org>

On Mon, 2016-07-25 at 16:29 +0100, David Woodhouse wrote:
> I'm currently trying to stop it whining about DTLSv1_client_method()
> being deprecated; I can't see how to make it work using
> DTLS_client_method().

The SSL_OP_CISCO_ANYCONNECT hack doesn't work so well with
DTLS_client_method. Instead of there being one simple place where we
can set s->client_version = s->version = DTLS1_BAD_VER, we'd end up
having to play silly buggers in quite a few places. So I figured I
should probably just do it properly with support for DTLS1_BAD_VER, as
below.

Although arguably, if I've used SSL_set_session() such that
s->session->ssl_version == DTLS1_BAD_VER, that should have been
honoured.

Two new commits at the tip of PR#1296 for comment...
https://github.com/openssl/openssl/pull/1296/commits/a1c341f7
(Make DTLS1_BAD_VER work with DTLS_client_method())

https://github.com/openssl/openssl/pull/1296/commits/41800497
(Honour SSL version in SSL_set_session()).

Not entirely sure if those are the best approach... but hey, you have a
test case now :)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/b46d2799/attachment.bin>

From levitte at openssl.org  Mon Jul 25 17:25:40 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 25 Jul 2016 19:25:40 +0200 (CEST)
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <rt-4.0.19-13376-1469461907-1144.4602-6-0@openssl.org>
References: <rt-4.0.19-13376-1469454258-1327.4602-6-0@openssl.org>
 <20160725135935.GF10260@nikhef.nl>
 <rt-4.0.19-13376-1469461907-1144.4602-6-0@openssl.org>
Message-ID: <20160725.192540.1880231151036302036.levitte@openssl.org>

In message <rt-4.0.19-13376-1469461907-1144.4602-6-0 at openssl.org> on Mon, 25 Jul 2016 15:51:47 +0000, "msalle at nikhef.nl via RT" <rt at openssl.org> said:

rt> The point is that if OpenSSL is providing a verification callback which
rt> can be used to provide a custom verification of the cert chain, then it
rt> should provide the necessary handles and the thing still missing from
rt> what Richard proposed is a way to point to the failing certificate in
rt> the chain. We can set the error, but not at which depth in the chain the
rt> error occurred.
rt> This in itself is not limited to our use-case but is a general API
rt> request.

Looking around, I just discovered that someone else has had the same
thoughts as you, back in April.  These functions were added back then:

 void  X509_STORE_CTX_set_error_depth(X509_STORE_CTX *ctx, int depth);
 void  X509_STORE_CTX_set_current_cert(X509_STORE_CTX *ctx, X509 *x);

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From steve at openssl.org  Mon Jul 25 18:30:52 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 25 Jul 2016 18:30:52 +0000
Subject: [openssl-dev] Discrepancy between docs and actual behavior: CMS
 in 1.0.2
In-Reply-To: <D3BBAB8C.2FB0F%uri@ll.mit.edu>
References: <D3BBAB8C.2FB0F%uri@ll.mit.edu>
Message-ID: <20160725183052.GA27051@openssl.org>

On Mon, Jul 25, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

> I confess I did not test this with 1.1.x. But in 1.0.2h there???s a problem.
> 
> CMS man page says:
> 
> If the -decrypt option is used without a recipient certificate then an
> attempt is made to locate the
> recipient by trying each potential recipient in turn using the supplied
> private key. To thwart the MMA
> attack (Bleichenbacher's attack on PKCS #1 v1.5 RSA padding) all recipients
> are tried whether they
> succeed or not and if no recipients match the message is "decrypted" using a
> random key which will
> typically output garbage. The -debug_decrypt option can be used to disable
> the MMA attack protection
> and return an error if no recipient can be found: this option should be used
> with caution.

That's a bug in the documentation. Currently that only works for RSA keys, not
EC or DH.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rt at openssl.org  Mon Jul 25 18:36:56 2016
From: rt at openssl.org (Dave Baggett via RT)
Date: Mon, 25 Jul 2016 18:36:56 +0000
Subject: [openssl-dev] [openssl.org #4618] BUG: Crash in do_ssl3_write
	unless OPENSSL_NO_MULTIBLOCK
In-Reply-To: <qOcO2oGxHxjVyKiOvE6eqaqSLnyjCwMHgVMHOwu9uRCwMDuwo@outlook.office365.com>
References: <RT-Ticket-4618@openssl.org>
 <rt-4.0.19-13377-1469439679-1750.4618-6-0@openssl.org>
 <hOn6k-l3ABgU06tlqEGeAaD8TWej3wFHtVPHcw79FRrwuSY44@outlook.office365.com>
 <qOcO2oGxHxjVyKiOvE6eqaqSLnyjCwMHgVMHOwu9uRCwMDuwo@outlook.office365.com>
Message-ID: <rt-4.0.19-13376-1469471816-951.4618-6-0@openssl.org>

Yes, that appears to fix it. Thanks!
Dave
Sent with [inky](http://inky.com?kme=signature)
"Matt Caswell via RT" <rt at openssl.org> wrote:
>
> On Wed Jul 20 19:46:37 2016, dmb at inky.com wrote:
> > OS: Mac OS X 11.11.5
> > Version: OpenSSL 1.1-pre6 (head code as of yesterday)
> > When the server fails under some circumstances, this line reads a bad
> > address:
> > /* write the header */
> >
> > *(outbuf[j]++) = type & 0xff;
> >
> > Because outbuf is 3. This is because prior to the alignment code,
> > outbuf is
> > NULL.
> > outbuf is set to s->rlayer->wbuf[0].buf, which at that point has been
> > set to
> > NULL by the code guarded by
> > #if !defined(OPENSSL_NO_MULTIBLOCK) && EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
> >
> > in ssl3_write_bytes.
> > I'm sorry I can't give you a simple reproducer; I was able to
> > reproduce it by
> > mailing very large files with our mail app. Eventually the Exchange
> > server
> > fails and downstream code resets the write buffer and the multiblock
> > code sets
> > s->rlayer->wbuf[0].buf to NULL.
> > The workaround is to compile with -DOPENSSL_NO_MULTIBLOCK -- I've
> > verified
> > that this eliminates the crash in practice.
> > Feel free to email me if you want me to put in to some test code and
> > reproduce
> > it.
> > Dave
> > Sent with [inky](http://inky.com?kme=signature)
>
> Hi Dave
>
> Please could you try the attached patch and see if that resolves the issue?
>
> Thanks
>
> Matt
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4618
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4618
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5478 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160725/dc389ed5/attachment.bin>

From rt at openssl.org  Mon Jul 25 21:09:53 2016
From: rt at openssl.org (Jon Loeliger via RT)
Date: Mon, 25 Jul 2016 21:09:53 +0000
Subject: [openssl-dev] [openssl.org #4629] OpenSSL Bug Report: -DSSL_DEBUG
	typo
In-Reply-To: <E1bRmWB-0004US-TA@mylo.jdl.com>
References: <RT-Ticket-4629@openssl.org> <E1bRmWB-0004US-TA@mylo.jdl.com>
Message-ID: <rt-4.0.19-13376-1469480993-1620.4629-21-0@openssl.org>


Build:

Linux jdl-centos.netgate.com 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

against commmit:

    commit d49cfa3bd57ffba060f08e4088441fa392c2f9a8
    Author: Steffen Nurpmeso <steffen at sdaoden.eu>
    Date:   Mon Jul 25 12:25:15 2016 +0200

	RT4627: Doc patch: fix constant names

	Reviewed-by: Matt Caswell <matt at openssl.org>
	Signed-off-by: Rich Salz <rsalz at openssl.org>


When I add -DSSL_DEBUG to the build, I take a compile error here:

gcc  -I. -Iinclude -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_USE_DEPRECATED -DOPENSSLDIR=3D"\"/home/jdl/workspace/qat-rpms/driver/BUILD/openssl/.openssl/ssl\"" -DENGINESDIR=3D"\"/home/jdl/workspace/qat-rpms/driver/BUILD/openssl/.openssl/lib/engines-1.1\"" -Wall -O3 -pthread - -m64 -DL_ENDIAN  -Wa,--noexecstack  -MMD -MF apps/s_client.d.tmp -MTapps/s_client.o -c -o apps/s_client.o apps/s_client.c

In file included from /usr/include/bits/byteswap.h:35:0,
                 from /usr/include/endian.h:60,
                 from /usr/include/ctype.h:40,
                 from apps/s_client.c:37:
apps/s_client.c: In function 'print_stuff':
apps/s_client.c:2624:51: error: 'union BIO_sock_info_u' has no member
named 'adr'
                        ntohs(BIO_ADDR_rawport(info.adr)));

Looks like a simple s/adr/addr/ typo.


diff --git a/apps/s_client.c b/apps/s_client.c
index bc89c98..0488a27 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -2621,7 +2621,7 @@ static void print_stuff(BIO *bio, SSL *s, int full)
         if ((info.addr = BIO_ADDR_new()) != NULL
             && BIO_sock_info(sock, BIO_SOCK_INFO_ADDRESS, &info)) {
             BIO_printf(bio_c_out, "LOCAL PORT is %u\n",
-                       ntohs(BIO_ADDR_rawport(info.adr)));
+                       ntohs(BIO_ADDR_rawport(info.addr)));
         }
         BIO_ADDR_free(info.addr);
     }


HTH,
jdl


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4629
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 26 09:42:06 2016
From: rt at openssl.org (Sebastian Smolorz via RT)
Date: Tue, 26 Jul 2016 09:42:06 +0000
Subject: [openssl-dev] [openssl.org #4630] Fatal error U1077: 'ias' : return
	code '0x1' on Skylake processor
In-Reply-To: <CAH5r+pYOyo5=sjGw0maW95G_aOkyqsoahpAgcK2Uz-SFhf+oXA@mail.gmail.com>
References: <RT-Ticket-4630@openssl.org>
 <CAH5r+pYOyo5=sjGw0maW95G_aOkyqsoahpAgcK2Uz-SFhf+oXA@mail.gmail.com>
Message-ID: <rt-4.0.19-13377-1469526126-1741.4630-21-0@openssl.org>

Hi,

I'm trying to set up OpenSSL on Windows 10 64-bit (i7 Skylake), having
followed the instructions so far, after installing Visual Studio I
attempted to nmake in the openssl directory using Visual c++ 2008 command
prompt to get the following error:

     "C:\Strawberry\perl\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"
 "-omakefile" "crypto\include\internal\bn_conf.h.in" >
crypto\include\internal\bn_conf.h
            "C:\Strawberry\perl\bin\perl.exe" "-I." -Mconfigdata "util\
dofile.pl"  "-omakefile" "crypto\include\internal\dso_conf.h.in" >
crypto\include\internal\dso_conf.h
            "C:\Strawberry\perl\bin\perl.exe" "-I." -Mconfigdata "util\
dofile.pl"  "-omakefile" "include\openssl\opensslconf.h.in" >
include\openssl\opensslconf.h
            ias -d debug -ocrypto\aes\aes-ia64.obj "crypto\aes\aes-ia64.asm"
    'ias' is not recognized as an internal or external command,
    operable program or batch file.
    NMAKE : fatal error U1077: 'ias' : return code '0x1'
    Stop.

This error is different if I try to compile the 32 bit version. That
results in an error referencing NASM which I tried to install with no luck. I
was working on the latest version and I've now tried older releases which
threw fatal error U1001: syntax error : illegal character '{' in macro. I
believe IAS is referring to the Itanium processor architecture but my
machine has a Skylake processor.

Thank you for taking the time to read my question.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4630
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue Jul 26 11:04:55 2016
From: rt at openssl.org (David Woodhouse via RT)
Date: Tue, 26 Jul 2016 11:04:55 +0000
Subject: [openssl-dev] [openssl.org #4631] Another DTLS1_BAD_VER regression
	in 1.0.2
In-Reply-To: <1469531084.120686.271.camel@infradead.org>
References: <RT-Ticket-4631@openssl.org>
 <1469531084.120686.271.camel@infradead.org>
Message-ID: <rt-4.0.19-13376-1469531095-1109.4631-21-0@openssl.org>

This fix and and some other regression fixes, along with a test case,
are lined up for HEAD/1.1 in Github PR #1296.

This one is also needed in 1.0.2.


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4631
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-SSL_export_keying_material-for-DTLS1_BAD_VER.patch
Type: text/x-patch
Size: 1156 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160726/12bc166c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160726/12bc166c/attachment-0001.bin>

From levitte at openssl.org  Tue Jul 26 15:50:14 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 26 Jul 2016 17:50:14 +0200 (CEST)
Subject: [openssl-dev] [openssl.org #4602] Missing accessors
In-Reply-To: <20160726095226.GC2457@nikhef.nl>
References: <20160725.192540.1880231151036302036.levitte@openssl.org>
 <20160726095226.GC2457@nikhef.nl>
Message-ID: <20160726.175014.587024167281997438.levitte@openssl.org>

In message <20160726095226.GC2457 at nikhef.nl> on Tue, 26 Jul 2016 11:52:26 +0200, Mischa Salle <msalle at nikhef.nl> said:

msalle> Hi Richard,
msalle> 
msalle> Although I haven't looked at all our code in detail (there is quite a
msalle> lot and it is old code which we mostly inherited from others and
msalle> maintained with a handful of people on best-effort basis) but I think we
msalle> now indeed have all we need. Thank you!
msalle> 
msalle> Just for completeness, there are a number of things we need to verify or
msalle> adapt by hand:
msalle> - for non-RFC proxies, we need to be able to verify the issuer by hand
msalle>   and override the X509_check_issued(). For GT3 it could be that this is
msalle>   automatically solved by setting the EXFLAG_PROXY, I will need to check
msalle>   that, for legacy /GT2 it cannot be since we need to check for the
msalle>   /CN=proxy or /CN=limited proxy.

You need to set the proxy path length as well for GT3.  For GT2, the
initial value -1 is exactly right.

msalle> - for GT3 proxies we need to verify the pathlength constraint. If your
msalle>   pullrequest https://github.com/openssl/openssl/pull/1348 allows me to
msalle>   set a proxy pathlength constraint for a GT3 proxy which combined with
msalle>   the EXFLAG_PROXY would allow using standard verification, then that
msalle>   would probably indeed solve that problem too.

That's what I'm hoping.  Please try it out, for example by disabling
these lines and seeing if what should verify does verify:

    https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L876-L884

msalle> - for GT3 proxies we also need to be able to set (as you mention) the
msalle>   policy. I need to check that we have the necessary getters/setters for
msalle>   that now. I'll check with your new example.

I've updated the example, it compiles.  We don't have that in the ssl
test any more (or well, we have it in pre-1.1 source), I'm thinking I
should create a demo...

msalle> - The errata of the RFC specify actually 3 OIDs, also the
msalle>   id-ppl-anyLanguage / 1.3.6.1.5.5.7.21.0 which is not understood by
msalle>   OpenSSL. I don't think they are used in practice, but I like to have
msalle>   code to verify them.

You can easily do that in verify_cb, per certificate.  I think you
already do?  Also, I'm not sure what you mean with "not understood by
OpenSSL", what is OpenSSL itself supposed to do with it?

msalle>   More importantly however, in Grid, the so-called limited proxies with
msalle>   globus-owned OID 1.3.6.1.4.1.3536.1.1.1.9 are widely used, they
msalle>   indicate that the proxy may not be used for job submission, only for
msalle>   data access. So we need to have ways to verify that. For legacy/GT2
msalle>   this is indicated using /CN=limited proxy instead.

1.3.6.1.4.1.3536.1.1.1.9?  That's a policy OID, right?  OpenSSL leaves
it entirely up to verify_cb to check these policies.  That would
correspond to the check_needed_rights() call at the bottom of
doc/HOWTO/proxy_certificates.txt, right?

msalle> - Related to the previous point, the chain may not be built up from
msalle>   arbitrary language proxies: for example after a limited proxy, only
msalle>   limited proxies are allowed.

That corresponds to the "rights" idea in
doc/HOWTO/proxy_certificates.txt

msalle>   Also, we need to make sure that the chain is something like
msalle>   CA -> [ subCA ... -> ] EEC -> proxy [ -> proxy ... ]
msalle>   This can of course be done in a chain-local callback (cert+issuer).

The OpenSSL code already ensures that, and works as long as the proxy
certs are appropriately marked with X509_set_proxy_flag() beforehand
(for example via the check_issued X509_STORE function for non-RFC
proxies).  If you look in crypto/x509/x509_vfy.c, check
check_chain_extensions().  You may notice the variable 'must_be_ca',
which is a tri-state, and controls what kind of cert is expected the
next step "up".

If you find a bug in that mechanism, we're interested!

msalle> > current_cert, current_issuer, etc are meant as input for verify_cb,
msalle> > indicating which certificate in the chain the call of the callback is
msalle> > about.  Why one would need to tamper with them from inside the
msalle> > verify_cb function escapes me...
msalle> It's true that it's not really what you want to do *if* you can do
msalle> local-only checks, but that's not possible for the pathlength constraint
msalle> check (without keeping some global state or by manually setting the
msalle> effective pathlength inside each cert), hence a renewed walking the
msalle> chain is typically done upon reaching the last cert.

Like I said, please check what OpenSSL does.  There was a bug, so I
perfectly understand why you needed to override that check.  I've
fixed what I found.  If you find a bug in that mechanism, we're
interested!

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From richmoore44 at gmail.com  Tue Jul 26 16:07:04 2016
From: richmoore44 at gmail.com (Richard Moore)
Date: Tue, 26 Jul 2016 17:07:04 +0100
Subject: [openssl-dev] Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);
In-Reply-To: <20160724.220515.1172616798240207500.levitte@openssl.org>
References: <CAMp7mVvjE5COSXWEPXEaXyWpYVHHWLfChZei9o-3LTL0u3nTyw@mail.gmail.com>
 <a62628880fea43fa8505f895c22f03c2@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160724.220515.1172616798240207500.levitte@openssl.org>
Message-ID: <CAMp7mVsH=4WfYpa7sA9cEiE5zDkP7O-URKp52fc8bxJoQZ4bhg@mail.gmail.com>

I meant to ask, should I make tickets for this and the missing DSA_bits()?

Cheers

Rich.

On 24 July 2016 at 21:05, Richard Levitte <levitte at openssl.org> wrote:

> In message <
> a62628880fea43fa8505f895c22f03c2 at usma1ex-dag1mb1.msg.corp.akamai.com> on
> Sun, 24 Jul 2016 17:19:05 +0000, "Salz, Rich" <rsalz at akamai.com> said:
>
> rsalz>
> rsalz> > Shouldn't this be  EC_KEY *EC_KEY_dup(const EC_KEY *src);
> rsalz>
> rsalz> I think the reason it is not is because the EC_KEY has an ENGINE*
> and that can't be const.
>
> The pointer to ENGINE will be const, yes, but not the ENGINE content
> itself, as if it was defined like this:
>
>     ENGINE * const engine;
>
> What happens is that the ENGINE pointer is copied to the new
> structure, and the ENGINE itself will work perfectly, both in the
> source EC_KEY and the new one.
>
> So there's no actual reason not to have const there.  It does,
> however, mean that we need to add const in a few more places.  Now
> many at all, actually, it took me 5 minutes.  PR coming tomorrow.
>
> Cheers,
> Richard
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160726/ac44c29d/attachment-0001.html>

From rsalz at akamai.com  Tue Jul 26 16:08:31 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 26 Jul 2016 16:08:31 +0000
Subject: [openssl-dev] Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);
In-Reply-To: <CAMp7mVsH=4WfYpa7sA9cEiE5zDkP7O-URKp52fc8bxJoQZ4bhg@mail.gmail.com>
References: <CAMp7mVvjE5COSXWEPXEaXyWpYVHHWLfChZei9o-3LTL0u3nTyw@mail.gmail.com>
 <a62628880fea43fa8505f895c22f03c2@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160724.220515.1172616798240207500.levitte@openssl.org>
 <CAMp7mVsH=4WfYpa7sA9cEiE5zDkP7O-URKp52fc8bxJoQZ4bhg@mail.gmail.com>
Message-ID: <f92e63f64dcb403584f22bdb12e33a6b@usma1ex-dag1mb1.msg.corp.akamai.com>


> I meant to ask, should I make tickets for this and the missing DSA_bits()?

Tickets.  Or ideally PR with code:)

From rt at openssl.org  Tue Jul 26 16:49:41 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 26 Jul 2016 16:49:41 +0000
Subject: [openssl-dev] [openssl.org #4629] OpenSSL Bug Report: -DSSL_DEBUG
	typo
In-Reply-To: <E1bRmWB-0004US-TA@mylo.jdl.com>
References: <RT-Ticket-4629@openssl.org> <E1bRmWB-0004US-TA@mylo.jdl.com>
Message-ID: <rt-4.0.19-13376-1469551781-1149.4629-6-0@openssl.org>

commit 1abd292 pushed to master, thanks!

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4629
Please log in as guest with password guest if prompted


From anirudhp at avaya.com  Tue Jul 26 17:50:44 2016
From: anirudhp at avaya.com (Patel, Anirudh (Anirudh))
Date: Tue, 26 Jul 2016 17:50:44 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving
 strange with X509_LOOKUP_add_dir
Message-ID: <B11D088B738A4B4B9066D5CA97E2D2FB3AC391B3@AZ-FFEXMB01.global.avaya.com>

Thanks. This might just take some more time for me to test. In the mean time I am reverting back to a simple question.

Can we entirely disable memory caching (os should I not even think about it)? OR 
Can we somehow clear the cache (from application) every time before a lookup is going to be performed?

Regards,
Anirudh

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Stephen Henson via RT
Sent: Monday, July 25, 2016 2:04 AM
To: patel3.anirudh at gmail.com
Cc: openssl-dev at openssl.org
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange with X509_LOOKUP_add_dir

On Sun Jul 24 18:29:16 2016, anirudhp at avaya.com wrote:
> Thanks a lot !!! Will definitely try it out :)
>

Note that this bugfix is now in OpenSSL 1.0.2 and the master branch so alternatively just try a recent snapshot.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aoZLPPcxOJoGYJbpykKdkwDkQz1Xi0G8MZL91DGHBSs&s=PUsRvqUzxbh9Cfr00GQPrYAkRGZHMA2HZ3wO101zcS0&e= 

--
Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4615&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aoZLPPcxOJoGYJbpykKdkwDkQz1Xi0G8MZL91DGHBSs&s=iUAbz4SoXIvbiMzF9L05oxcAK1_o4Gn3g2o_sKeDScs&e=
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aoZLPPcxOJoGYJbpykKdkwDkQz1Xi0G8MZL91DGHBSs&s=hOx9BoqkR1AzsjiJtEr9F10ldB62-y5P7jWSFlVPaGM&e= 

From rt at openssl.org  Tue Jul 26 17:51:05 2016
From: rt at openssl.org (Patel, Anirudh via RT)
Date: Tue, 26 Jul 2016 17:51:05 +0000
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving
	strange with X509_LOOKUP_add_dir
In-Reply-To: <B11D088B738A4B4B9066D5CA97E2D2FB3AC391B3@AZ-FFEXMB01.global.avaya.com>
References: <RT-Ticket-4615@openssl.org>
 <B11D088B738A4B4B9066D5CA97E2D2FB3AC391B3@AZ-FFEXMB01.global.avaya.com>
Message-ID: <rt-4.0.19-13377-1469555465-1865.4615-6-0@openssl.org>

Thanks. This might just take some more time for me to test. In the mean time I am reverting back to a simple question.

Can we entirely disable memory caching (os should I not even think about it)? OR 
Can we somehow clear the cache (from application) every time before a lookup is going to be performed?

Regards,
Anirudh

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Stephen Henson via RT
Sent: Monday, July 25, 2016 2:04 AM
To: patel3.anirudh at gmail.com
Cc: openssl-dev at openssl.org
Subject: [openssl-dev] [openssl.org #4615] Cache utility behaving strange with X509_LOOKUP_add_dir

On Sun Jul 24 18:29:16 2016, anirudhp at avaya.com wrote:
> Thanks a lot !!! Will definitely try it out :)
>

Note that this bugfix is now in OpenSSL 1.0.2 and the master branch so alternatively just try a recent snapshot.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aoZLPPcxOJoGYJbpykKdkwDkQz1Xi0G8MZL91DGHBSs&s=PUsRvqUzxbh9Cfr00GQPrYAkRGZHMA2HZ3wO101zcS0&e= 

--
Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4615&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aoZLPPcxOJoGYJbpykKdkwDkQz1Xi0G8MZL91DGHBSs&s=iUAbz4SoXIvbiMzF9L05oxcAK1_o4Gn3g2o_sKeDScs&e=
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aoZLPPcxOJoGYJbpykKdkwDkQz1Xi0G8MZL91DGHBSs&s=hOx9BoqkR1AzsjiJtEr9F10ldB62-y5P7jWSFlVPaGM&e= 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted


From dwmw2 at infradead.org  Tue Jul 26 23:29:28 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 27 Jul 2016 00:29:28 +0100
Subject: [openssl-dev] Session resume with different TLS version?
Message-ID: <1469575768.120686.369.camel@infradead.org>

The deprecation of the version-specific methods such as
DTLSv1_client_method() has introduced a regression ? the
SSL_OP_CISCO_ANYCONNECT hack doesn't work with DTLS_client_method().

I'm looking into fixing that (in PR#1296 along with a test case and
some fixes for various other regressions). In doing so, I uncovered a
slightly more generic question...

If I am resuming a session with SSL_set_session(), and that previous
session used a specific protocol... should we negotiate that *same*
protocol again, effectively setting the minimum and maximum protocol
versions to s->session->ssl_version?

Given that DTLS1_BAD_VER only *ever* needs to be used in a session
resume, that would be a perfectly acceptable way to obtain it...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160727/1770ec91/attachment.bin>

From davidben at chromium.org  Tue Jul 26 23:52:43 2016
From: davidben at chromium.org (David Benjamin)
Date: Tue, 26 Jul 2016 23:52:43 +0000
Subject: [openssl-dev] Session resume with different TLS version?
In-Reply-To: <1469575768.120686.369.camel@infradead.org>
References: <1469575768.120686.369.camel@infradead.org>
Message-ID: <CAF8qwaAF=nZf2BXkdHmMmdfq3VXvJtiQNnixEw5YQVR627gX_A@mail.gmail.com>

Ah, you've hit upon a slew of odd behaviors which only got fully fixed on
the master branch.

On Tue, Jul 26, 2016 at 7:30 PM David Woodhouse <dwmw2 at infradead.org> wrote:

> The deprecation of the version-specific methods such as
> DTLSv1_client_method() has introduced a regression ? the
> SSL_OP_CISCO_ANYCONNECT hack doesn't work with DTLS_client_method().
>
> I'm looking into fixing that (in PR#1296 along with a test case and
> some fixes for various other regressions). In doing so, I uncovered a
> slightly more generic question...
>
> If I am resuming a session with SSL_set_session(), and that previous
> session used a specific protocol... should we negotiate that *same*
> protocol again, effectively setting the minimum and maximum protocol
> versions to s->session->ssl_version?
>

As a server, yes. Mismatching resumed and negotiated version isn't
interoperable with any client out there. This was fixed in 1.0.2 I believe
with:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=9e189b9dc10786c755919e6792e923c584c918a1
A server must first do version negotiation and then, if the version does
not match the offered session, decline to resume a session and negotiate a
full handshake.

As a client, no. This was the old behavior and causes all kinds of
problems. It should not be restored. See the discussions here:
https://github.com/openssl/openssl/pull/603
https://github.com/tlswg/tls13-spec/issues/136
If configured to offer, say, a TLS 1.1 session while the maximum version is
TLS 1.2, offer the session BUT advertise a maximum version of TLS 1.2. If
the server accepts the session, treat it as a fatal error if the session's
version does not match the negotiated version.

Anything else will cause tons of interoperability problems or weird
behaviors.

(Although 1.0 through 1.2 are more-or-less the same protocol, assuming that
"sessions" are somehow analogous across protocol versions is a bad idea.
Say you tried a resume a 1.2 AES-GCM session at 1.1. Also 1.3 resumption is
completely different from 1.2 resumption and definitely should not be
mixed.)


> Given that DTLS1_BAD_VER only *ever* needs to be used in a session
> resume, that would be a perfectly acceptable way to obtain it...
>

(I'm not familiar with DTLS1_BAD_VER, but if it's a different protocol
version, it sounds like you should configure it like other versions and not
mess with session resumption bugs.)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160726/08033948/attachment-0001.html>

From leonb at parsec.co.za  Wed Jul 27 12:13:26 2016
From: leonb at parsec.co.za (Leon Brits)
Date: Wed, 27 Jul 2016 12:13:26 +0000
Subject: [openssl-dev] DRBG entropy
Message-ID: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>

Hi all,

I have a chip (FDK RPG100) that generates randomness, but the SP800-90B python test suite indicated that the chip only provides 2.35 bits/byte of entropy. According to FIPS test lab the lowest value from all the tests are used as the entropy and 2 is too low. I must however make use of this chip.

Looking at the paragraph in the User Guide 2.0 where low entropy sources are discussed and have some additional questions:

1.     In my DRBG callback for entropy (function get_entropy in the guide), I simply used our chip as the source (the driver reading from the chip, makes it available at /dev/hwrng). Now that I've come to learn that the chip's entropy is too low, how do I ensure that this callback exists with a buffer of acceptable entropy?

2.     Should I just return a 4 times larger buffer? Wat if that is larger than the "max_len"?

3.     Can the DRBG repeatedly call the callback until the entropy is high enough?

Your advice is appreciated

Regards
LJB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160727/70757f5e/attachment.html>

From ssx at av8n.com  Wed Jul 27 13:39:52 2016
From: ssx at av8n.com (John Denker)
Date: Wed, 27 Jul 2016 06:39:52 -0700
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
Message-ID: <5798B9A8.6090409@av8n.com>

On 07/27/2016 05:13 AM, Leon Brits wrote:
> 
> I have a chip (FDK RPG100) that generates randomness, but the
> SP800-90B python test suite indicated that the chip only provides
> 2.35 bits/byte of entropy. According to FIPS test lab the lowest
> value from all the tests are used as the entropy and 2 is too low. I
> must however make use of this chip.

That's a problem on several levels.

For starters, keep in mind the following maxim:
     Testing can certainty show the absence of entropy.
     Testing can never show the presence of entropy.

That is to say, you have ascertained that 2.35 bits/byte is an
/upper bound/ on the entropy density coming from the chip.  If
you care about security, you need a lower bound.  Despite what
FIPS might lead you to believe, you cannot obtain this from testing.
The only way to obtain it is by understanding how the chip works.
This might require a treeeemendous amount of effort and expertise.

================

Secondly, entropy is probably not even the correct concept.  For any
given probability distribution P, i.e. for any given ensemble, there
are many measurable properties (i.e. functionals) you might look at.
Entropy is just one of them.  It measures a certain /average/ property.
For cryptologic security, depending on your threat model, it is quite
possible that you ought to be looking at something else.  It may help
to look at this in terms of the R?nyi functionals:
  H_0[P] = multiplicity      = Hartley functional
  H_1[P] = plain old entropy = Boltzmann functional
  H_?[P] = adamance

The entropy H_1 may be appropriate if the attacker needs to break
all messages, or a "typical" subset of messages.  The adamance H_?
may be more appropriate if there are many messages and the attacker
can win by breaking any one of them.

To say the same thing in other words:
 -- A small multiplicity (H_0) guarantees the problem is easy for the attacker.
 -- A large adamance (H_?) guarantees the problem is hard for the attacker.

================

Now let us fast-forward and suppose, hypothetically, that you
have obtained a lower bound on what the chip produces.

One way to proceed is to use a hash function.  For clarity, let's
pick SHA-256.  Obtain from the chip not just 256 bits of adamance,
but 24 bits more than that, namely 280 bits.  This arrives in the
form of a string of bytes, possibly hundreds of bytes.  Run this
through the hash function.  The output word is 32 bytes i.e. 256
bits of high-quality randomness.  The key properties are:
 a) There will be 255.99 bits of randomness per word, guaranteed
  with high probability, more than high enough for all practical
  purposes.
 b) It will be computationally infeasible to locate or exploit
  the missing 0.01 bit.

Note that it is not possible to obtain the full 256 bits of
randomness in a 256-bit word.  Downstream applications must be
designed so that 255.99 is good enough.

========

As with all of crypto, this requires attention to detail.  You
need to protect the hash inputs, outputs, and all intermediate
calculations.  For example, you don't want such things to get
swapped out.

From jim at carroll.com  Wed Jul 27 14:45:35 2016
From: jim at carroll.com (Jim Carroll)
Date: Wed, 27 Jul 2016 10:45:35 -0400
Subject: [openssl-dev] Windows uplink override, PR 1356
Message-ID: <00c501d1e815$89bda740$9d38f5c0$@carroll.com>

I'm assisting with the port of the python package M2Crypto to use OpenSSL
1.1.0. The latest windows build of python 2.7.12 still does not include
applink.c, which leaves us unable to use BIO_s_fd functions and those
BIO_s_file functions that accept FILE objects.

I'd like to offer patch #1356 (https://github.com/openssl/openssl/pull/1356)

The patch modifies how OPENSSL_Uplink() searches for the applinktable.
Instead of only searching within the process space of the application, it
enables a developer to register an optional applinktable stored in another
module (aka another DLL).

The solution requires the developer to ensure the call to
OPENSSL_SetApplink() is made from an extension that was compiled using the
same threading model as both python and the installed OpenSSL library. But,
because python's distutils system is fully aware of the build environment,
this is a trivial matter for python developers.

The patch includes documentation along with detailed example of how to use
it.


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C<Q-#0U,S1:
M,",&"2J&2(;W#0$)!#$6!!24M)D]N&9US*]IH=DN==WUU[1@;3!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0"9(2\L^&Z$=;)N6TYM0="\E<)E_F5C,CH,.D:1T;M!%1D)%.?+S^5S
MR]DY'L# A at 8M7IG.,3";1(2CG$IOLOIK8D+S<]-L>Q4*9RX]WTL8,.#)9&5(
MH:3L,J at A/U!ZM1NA4,V>13UG()X*/O*9LN&?*R1[2PB%N+4C;AE+I15KE!7@
M-@$'0V\%+C6M0^>=K9S:A"(H,W9C07A./J=?.:_<\LWQ5^AQ9&35E#^8>;)/
M4;GP':A*)RJ=S.TH91CMG:L&Y3"1QB$A3UK?I55K\YO5R:"B^B.;!99]M0/C
J/\3FUH4%M4'I";QH1+H$L#3*^,^JYU?:+K,VW^T%S>JQ0[VQ````````
`
end


From leonb at parsec.co.za  Wed Jul 27 15:23:21 2016
From: leonb at parsec.co.za (Leon Brits)
Date: Wed, 27 Jul 2016 15:23:21 +0000
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <5798B9A8.6090409@av8n.com>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com>
Message-ID: <2530f4bb681c4895bde9f115fc277575@EXCHANGESRV.PARSEC.local>

John,

Thanks for your reply.

The SP800-90B test has different types of test but the test with the lowest output is used as the maximum entropy capability of the chip. That is how I understand it from the FIPS lab.

For the FIPS validation, using a NDRNG, that source must feed the DRBG directly (FIPS lab) and not from something like the PRNG. I use seed the /dev/random from the NDRNG and then source from the PRNG, but that is not allowed for DRBGs. Again I hope I understand them correct.

They said I must look at the OpenSSL user guide v2.0 para 6.1.1 where low entropy sources are discussed. Now, I already make use of the "get_entropy" function for my DRBG implementation. I use to source from the PRNG in that callback. I must now get it directly from my entropy source, which give rise to my question of how to ensure that I have high entropy of data before the callback exits.

Regards,
LJB

From cata.vasile at nxp.com  Wed Jul 27 14:52:17 2016
From: cata.vasile at nxp.com (Catalin Vasile)
Date: Wed, 27 Jul 2016 14:52:17 +0000
Subject: [openssl-dev] [TLS1 PRF]: unknown algorithm
Message-ID: <DB5PR04MB1302BBDED35E7784524F2FB7EE0F0@DB5PR04MB1302.eurprd04.prod.outlook.com>

Hi,

I'm trying to use the EVP_PKEY_TLS1_PRF interface.

The first thing I do inside my code is:
    pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_TLS1_PRF, NULL);
But pctx is NULL after that call.

I've watched test/evp_test.c and it does not seem it does anything special, but it successful in running the TLS1-PRF tests.

Is there something I'm missing?

Best regards,
Cata

From glosterj9 at gmail.com  Wed Jul 27 16:01:58 2016
From: glosterj9 at gmail.com (john gloster)
Date: Wed, 27 Jul 2016 21:31:58 +0530
Subject: [openssl-dev] Load secrets to context.
Message-ID: <CAPJ95F_kc=0V0B1AZOGpBqZ65qoN5MyTTS77bWW4rh-OT5uLCQ@mail.gmail.com>

Hi,

Can we use both the following APIs in the same application to load
certificate to the SSL context?

*SSL_CTX_use_certificate_file()*
*SSL_CTX_use_certificate_chain_file()*

If we can how to use them?

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160727/358bc6a6/attachment.html>

From steve at openssl.org  Wed Jul 27 16:51:32 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 27 Jul 2016 16:51:32 +0000
Subject: [openssl-dev] [TLS1 PRF]: unknown algorithm
In-Reply-To: <DB5PR04MB1302BBDED35E7784524F2FB7EE0F0@DB5PR04MB1302.eurprd04.prod.outlook.com>
References: <DB5PR04MB1302BBDED35E7784524F2FB7EE0F0@DB5PR04MB1302.eurprd04.prod.outlook.com>
Message-ID: <20160727165132.GA26038@openssl.org>

On Wed, Jul 27, 2016, Catalin Vasile wrote:

> Hi,
> 
> I'm trying to use the EVP_PKEY_TLS1_PRF interface.
> 
> The first thing I do inside my code is:
>     pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_TLS1_PRF, NULL);
> But pctx is NULL after that call.
> 
> I've watched test/evp_test.c and it does not seem it does anything special, but it successful in running the TLS1-PRF tests.
> 
> Is there something I'm missing?
> 

Is it linking against an older version of OpenSSL?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Wed Jul 27 16:55:56 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 27 Jul 2016 16:55:56 +0000
Subject: [openssl-dev] Load secrets to context.
In-Reply-To: <CAPJ95F_kc=0V0B1AZOGpBqZ65qoN5MyTTS77bWW4rh-OT5uLCQ@mail.gmail.com>
References: <CAPJ95F_kc=0V0B1AZOGpBqZ65qoN5MyTTS77bWW4rh-OT5uLCQ@mail.gmail.com>
Message-ID: <20160727165556.GB26038@openssl.org>

On Wed, Jul 27, 2016, john gloster wrote:

> Hi,
> 
> Can we use both the following APIs in the same application to load
> certificate to the SSL context?
> 
> *SSL_CTX_use_certificate_file()*
> *SSL_CTX_use_certificate_chain_file()*
> 

You should only use one. If you use SSL_CTX_use_certificate_chain_file() the
file needs to contains the certificates from EE to root in order in PEM
format.

If you want to do things differently you can load the PEM files manually and
use functions like SSL_CTX_use_certificate() and SSL_CTX_add0_chain_cert().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From dwmw2 at infradead.org  Wed Jul 27 19:28:34 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 27 Jul 2016 20:28:34 +0100
Subject: [openssl-dev] Session resume with different TLS version?
In-Reply-To: <CAF8qwaAF=nZf2BXkdHmMmdfq3VXvJtiQNnixEw5YQVR627gX_A@mail.gmail.com>
References: <1469575768.120686.369.camel@infradead.org>
 <CAF8qwaAF=nZf2BXkdHmMmdfq3VXvJtiQNnixEw5YQVR627gX_A@mail.gmail.com>
Message-ID: <1469647714.120686.428.camel@infradead.org>

On Tue, 2016-07-26 at 23:52 +0000, David Benjamin wrote:
> Ah, you've hit upon a slew of odd behaviors which only got fully fixed on the master branch.

Thanks for the comprehensive response. I'm not going to touch that with
a barge-pole then.

> (I'm not familiar with?DTLS1_BAD_VER, but if it's a different
> protocol version, it sounds like you should configure it like other
> versions and not mess with session resumption bugs.)

It's a different protocol version, and the *only* way it ever gets used
in the modern world is with a session resume (because that's how
Cisco's AnyConnect VPN works). Hence the thought process was that if
the session resume would *force* the protocol version (which you now
told me it shouldn't, for the client), then I wouldn't *need* any other
method of specifying it.

In RT#3711 we had previously talked about the option of enabling full
support via something like DTLSv0_9_client_method(), and it had been
decided not to ? on the basis that the existing SSL_OP_CISCO_ANYCONNECT
hack was sufficient.

That's less true now with the generic DTLS_client_method() and
DTLS_ANY_VERSION, because the SSL_OP_CISCO_ANYCONNECT hack needs to be
propagated into a lot more places and it actually ends up being
*cleaner* to implement it "properly" AFAICT.

I've updated my submission in PR#1296 accordingly; thanks for the
feedback.

https://github.com/openssl/openssl/pull/1296

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160727/6f48363c/attachment.bin>

From paul.dale at oracle.com  Thu Jul 28 00:32:49 2016
From: paul.dale at oracle.com (Paul Dale)
Date: Wed, 27 Jul 2016 17:32:49 -0700 (PDT)
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <5798B9A8.6090409@av8n.com>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com>
Message-ID: <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>

John's spot on the mark here.  Testing gives a maximum entropy not a minimum.  While a maximum is certainly useful, it isn't what you really need to guarantee your seeding.

A simple example which passes the NIST SP800-90B first draft tests with flying colours:

        seed = ? - 3
        for i = 1 to n do
                seed = frac(exp(1+2*seed))
                entropy[i] = 256 * frac(2^20 * seed)

where frac is the fractional part function, exp is the exponential function.

I.e. start with the fractional part of the transcendental ? and iterate with a simple exponential function.  Take bits 21-28 of each iterate as a byte of "entropy".  Clearly there is really zero entropy present: the formula is simple and deterministic; the floating point arithmetic operations will all be correctly rounded; the exponential is evaluated in a well behaved area of its curve where there will be minimal rounding concerns; the bits being extracted are nowhere near where any rounding would occur and any rounding errors will likely be deterministic anyway.

Yet this passes the SP800-90B (first draft) tests as IID with 7.89 bits of entropy per byte!

IID is a statistical term meaning independent and identically distributed which in turn means that each sample doesn't depend on any of the other samples (which is clearly incorrect) and that all samples are collected from the same distribution.  The 7.89 bits of entropy per byte is pretty much as high as the NIST tests will ever say.  According to the test suite, we've got an "almost perfect" entropy source.


There are other test suites if you've got sufficient data.  The Dieharder suite is okay, however the TestU01 suite is most discerning I'm currently aware of.  Still, neither will provide an entropy estimate for you.  For either of these you will need a lot of data -- since you've got a hardware RNG, this shouldn't be a major issue.  Avoid the "ent" program, it seems to overestimate the maximum entropy present.


John's suggestion of collecting additional "entropy" and running it through a cryptographic has function is probably the best you'll be able to achieve without a deep investigation.  As for how much data to collect, be conservative.  If the estimate of the maximum entropy is 2.35 bits per byte, round this down to 2 bits per byte, 1 bit per byte or even ? bit per byte.  The lower you go the more likely you are to be getting the entropy you want.  The trade-off is the time for the hardware to generate the data and for the processor to hash it together.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: John Denker [mailto:ssx at av8n.com] 
Sent: Wednesday, 27 July 2016 11:40 PM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] DRBG entropy

On 07/27/2016 05:13 AM, Leon Brits wrote:
> 
> I have a chip (FDK RPG100) that generates randomness, but the 
> SP800-90B python test suite indicated that the chip only provides
> 2.35 bits/byte of entropy. According to FIPS test lab the lowest value 
> from all the tests are used as the entropy and 2 is too low. I must 
> however make use of this chip.

That's a problem on several levels.

For starters, keep in mind the following maxim:
     Testing can certainty show the absence of entropy.
     Testing can never show the presence of entropy.

That is to say, you have ascertained that 2.35 bits/byte is an /upper bound/ on the entropy density coming from the chip.  If you care about security, you need a lower bound.  Despite what FIPS might lead you to believe, you cannot obtain this from testing.
The only way to obtain it is by understanding how the chip works.
This might require a treeeemendous amount of effort and expertise.

================

Secondly, entropy is probably not even the correct concept.  For any given probability distribution P, i.e. for any given ensemble, there are many measurable properties (i.e. functionals) you might look at.
Entropy is just one of them.  It measures a certain /average/ property.
For cryptologic security, depending on your threat model, it is quite possible that you ought to be looking at something else.  It may help to look at this in terms of the R?nyi functionals:
  H_0[P] = multiplicity      = Hartley functional
  H_1[P] = plain old entropy = Boltzmann functional
  H_?[P] = adamance

The entropy H_1 may be appropriate if the attacker needs to break all messages, or a "typical" subset of messages.  The adamance H_? may be more appropriate if there are many messages and the attacker can win by breaking any one of them.

To say the same thing in other words:
 -- A small multiplicity (H_0) guarantees the problem is easy for the attacker.
 -- A large adamance (H_?) guarantees the problem is hard for the attacker.

================

Now let us fast-forward and suppose, hypothetically, that you have obtained a lower bound on what the chip produces.

One way to proceed is to use a hash function.  For clarity, let's pick SHA-256.  Obtain from the chip not just 256 bits of adamance, but 24 bits more than that, namely 280 bits.  This arrives in the form of a string of bytes, possibly hundreds of bytes.  Run this through the hash function.  The output word is 32 bytes i.e. 256 bits of high-quality randomness.  The key properties are:
 a) There will be 255.99 bits of randomness per word, guaranteed
  with high probability, more than high enough for all practical
  purposes.
 b) It will be computationally infeasible to locate or exploit
  the missing 0.01 bit.

Note that it is not possible to obtain the full 256 bits of randomness in a 256-bit word.  Downstream applications must be designed so that 255.99 is good enough.

========

As with all of crypto, this requires attention to detail.  You need to protect the hash inputs, outputs, and all intermediate calculations.  For example, you don't want such things to get swapped out.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From cata.vasile at nxp.com  Thu Jul 28 06:38:51 2016
From: cata.vasile at nxp.com (Catalin Vasile)
Date: Thu, 28 Jul 2016 06:38:51 +0000
Subject: [openssl-dev] [TLS1 PRF]: unknown algorithm
In-Reply-To: <20160727165132.GA26038@openssl.org>
References: <DB5PR04MB1302BBDED35E7784524F2FB7EE0F0@DB5PR04MB1302.eurprd04.prod.outlook.com>,
 <20160727165132.GA26038@openssl.org>
Message-ID: <DB5PR04MB1302AD6A380D7AA1D06B798CEE000@DB5PR04MB1302.eurprd04.prod.outlook.com>

The scenario is kind of like this:
1. I copy the newest openssl library to the platform I am testing.
2. I build evp_test along with the newest openssl version (the one from point no 1) and then I copy it on the platform I am testing.
3. With an older openssl in the build path, I build a custom application, and then copy it on the platform.

Cata V

>From: openssl-dev <openssl-dev-bounces at openssl.org> on behalf of Dr. Stephen Henson <steve at openssl.org>
>Sent: Wednesday, July 27, 2016 7:51 PM
>To: openssl-dev at openssl.org
>Subject: Re: [openssl-dev] [TLS1 PRF]: unknown algorithm
>?   
>On Wed, Jul 27, 2016, Catalin Vasile wrote:
>
>> Hi,
>> 
>> I'm trying to use the EVP_PKEY_TLS1_PRF interface.
>> 
>> The first thing I do inside my code is:
>>???? pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_TLS1_PRF, NULL);
>> But pctx is NULL after that call.
>> 
>> I've watched test/evp_test.c and it does not seem it does anything special, but it successful in running the TLS1-PRF tests.
>> 
>> Is there something I'm missing?
>> 
>
>Is it linking against an older version of OpenSSL?
>
>Steve.
>--
>Dr Stephen N. Henson. OpenSSL project core developer.
>Commercial tech support now available see: http://www.openssl.org
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>    

From leonb at parsec.co.za  Thu Jul 28 07:40:16 2016
From: leonb at parsec.co.za (Leon Brits)
Date: Thu, 28 Jul 2016 07:40:16 +0000
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com> <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
Message-ID: <2d501b0b965b44d481d61afb5443ee25@EXCHANGESRV.PARSEC.local>

Thanks for the helping me understand the whole entropy thing better. It is still get the feeling that this is a "best effort" thing and that nobody can actually proof what is correct. I am probably just bringing the math down to my level - sorry.

With that said for validation I still need to be sure that I give the required entropy back from the OpenSSL callback. Now since I am not allowed to use a hash with the DRBGs (FIPS lab and SP800-90B section 8.4), can you please confirm that, with a source of raw 2b/B entropy data, I need to return 4 times the data from the callback function?

Regards,

Leon Brits
System Engineer
Parsec

Work +27 12 678 9740 Cell +27 84 250 2855 Email leonb at parsec.co.za
www.parsec.co.za/disclaimer 

> -----Original Message-----
> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of
> Paul Dale
> Sent: 28 July 2016 02:33 AM
> To: openssl-dev at openssl.org
> Subject: Re: [openssl-dev] DRBG entropy
> 
> John's spot on the mark here.  Testing gives a maximum entropy not a
> minimum.  While a maximum is certainly useful, it isn't what you really
> need to guarantee your seeding.
> 
> A simple example which passes the NIST SP800-90B first draft tests with
> flying colours:
> 
>         seed = ? - 3
>         for i = 1 to n do
>                 seed = frac(exp(1+2*seed))
>                 entropy[i] = 256 * frac(2^20 * seed)
> 
> where frac is the fractional part function, exp is the exponential
> function.
> 
> I.e. start with the fractional part of the transcendental ? and iterate
> with a simple exponential function.  Take bits 21-28 of each iterate as a
> byte of "entropy".  Clearly there is really zero entropy present: the
> formula is simple and deterministic; the floating point arithmetic
> operations will all be correctly rounded; the exponential is evaluated in
> a well behaved area of its curve where there will be minimal rounding
> concerns; the bits being extracted are nowhere near where any rounding
> would occur and any rounding errors will likely be deterministic anyway.
> 
> Yet this passes the SP800-90B (first draft) tests as IID with 7.89 bits of
> entropy per byte!
> 
> IID is a statistical term meaning independent and identically distributed
> which in turn means that each sample doesn't depend on any of the other
> samples (which is clearly incorrect) and that all samples are collected
> from the same distribution.  The 7.89 bits of entropy per byte is pretty
> much as high as the NIST tests will ever say.  According to the test
> suite, we've got an "almost perfect" entropy source.
> 
> 
> There are other test suites if you've got sufficient data.  The Dieharder
> suite is okay, however the TestU01 suite is most discerning I'm currently
> aware of.  Still, neither will provide an entropy estimate for you.  For
> either of these you will need a lot of data -- since you've got a hardware
> RNG, this shouldn't be a major issue.  Avoid the "ent" program, it seems
> to overestimate the maximum entropy present.
> 
> 
> John's suggestion of collecting additional "entropy" and running it
> through a cryptographic has function is probably the best you'll be able
> to achieve without a deep investigation.  As for how much data to collect,
> be conservative.  If the estimate of the maximum entropy is 2.35 bits per
> byte, round this down to 2 bits per byte, 1 bit per byte or even ? bit per
> byte.  The lower you go the more likely you are to be getting the entropy
> you want.  The trade-off is the time for the hardware to generate the data
> and for the processor to hash it together.
> 
> 
> Pauli
> --
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7
> 3031 7217 Oracle Australia
> 
> -----Original Message-----
> From: John Denker [mailto:ssx at av8n.com]
> Sent: Wednesday, 27 July 2016 11:40 PM
> To: openssl-dev at openssl.org
> Subject: Re: [openssl-dev] DRBG entropy
> 
> On 07/27/2016 05:13 AM, Leon Brits wrote:
> >
> > I have a chip (FDK RPG100) that generates randomness, but the
> > SP800-90B python test suite indicated that the chip only provides
> > 2.35 bits/byte of entropy. According to FIPS test lab the lowest value
> > from all the tests are used as the entropy and 2 is too low. I must
> > however make use of this chip.
> 
> That's a problem on several levels.
> 
> For starters, keep in mind the following maxim:
>      Testing can certainty show the absence of entropy.
>      Testing can never show the presence of entropy.
> 
> That is to say, you have ascertained that 2.35 bits/byte is an /upper
> bound/ on the entropy density coming from the chip.  If you care about
> security, you need a lower bound.  Despite what FIPS might lead you to
> believe, you cannot obtain this from testing.
> The only way to obtain it is by understanding how the chip works.
> This might require a treeeemendous amount of effort and expertise.
> 
> ================
> 
> Secondly, entropy is probably not even the correct concept.  For any given
> probability distribution P, i.e. for any given ensemble, there are many
> measurable properties (i.e. functionals) you might look at.
> Entropy is just one of them.  It measures a certain /average/ property.
> For cryptologic security, depending on your threat model, it is quite
> possible that you ought to be looking at something else.  It may help to
> look at this in terms of the R?nyi functionals:
>   H_0[P] = multiplicity      = Hartley functional
>   H_1[P] = plain old entropy = Boltzmann functional
>   H_?[P] = adamance
> 
> The entropy H_1 may be appropriate if the attacker needs to break all
> messages, or a "typical" subset of messages.  The adamance H_? may be more
> appropriate if there are many messages and the attacker can win by
> breaking any one of them.
> 
> To say the same thing in other words:
>  -- A small multiplicity (H_0) guarantees the problem is easy for the
> attacker.
>  -- A large adamance (H_?) guarantees the problem is hard for the
> attacker.
> 
> ================
> 
> Now let us fast-forward and suppose, hypothetically, that you have
> obtained a lower bound on what the chip produces.
> 
> One way to proceed is to use a hash function.  For clarity, let's pick
> SHA-256.  Obtain from the chip not just 256 bits of adamance, but 24 bits
> more than that, namely 280 bits.  This arrives in the form of a string of
> bytes, possibly hundreds of bytes.  Run this through the hash function.
> The output word is 32 bytes i.e. 256 bits of high-quality randomness.  The
> key properties are:
>  a) There will be 255.99 bits of randomness per word, guaranteed
>   with high probability, more than high enough for all practical
>   purposes.
>  b) It will be computationally infeasible to locate or exploit
>   the missing 0.01 bit.
> 
> Note that it is not possible to obtain the full 256 bits of randomness in
> a 256-bit word.  Downstream applications must be designed so that 255.99
> is good enough.
> 
> ========
> 
> As with all of crypto, this requires attention to detail.  You need to
> protect the hash inputs, outputs, and all intermediate calculations.  For
> example, you don't want such things to get swapped out.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From hkario at redhat.com  Thu Jul 28 10:51:06 2016
From: hkario at redhat.com (Hubert Kario)
Date: Thu, 28 Jul 2016 12:51:06 +0200
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <2530f4bb681c4895bde9f115fc277575@EXCHANGESRV.PARSEC.local>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com>
 <2530f4bb681c4895bde9f115fc277575@EXCHANGESRV.PARSEC.local>
Message-ID: <4952917.uTjBKuQNQs@pintsize.usersys.redhat.com>

On Wednesday, 27 July 2016 15:23:21 CEST Leon Brits wrote:
> John,
> 
> Thanks for your reply.
> 
> The SP800-90B test has different types of test but the test with the lowest
> output is used as the maximum entropy capability of the chip. That is how I
> understand it from the FIPS lab.
> 
> For the FIPS validation, using a NDRNG, that source must feed the DRBG
> directly (FIPS lab) and not from something like the PRNG. I use seed the
> /dev/random from the NDRNG and then source from the PRNG, but that is not
> allowed for DRBGs. Again I hope I understand them correct.

but PRNG and DRBG is the same thing, both generate pseudo-random numbers from 
a seed using (hopefully) a cryptographically secure algorithm

FIPS definitely allows you to use output of one DRBG to seed other DRBG

in the end, you should gather as much entropy as possible in the system, and 
mix it all together and then use output of a DRBG that uses all that entropy 
to seed other DRBGs

what that means in practical terms, is feed output from your NDRNG to kernel's 
entropy pool and seed everything from /dev/urandom output (or getrandom())

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160728/dca3370a/attachment.sig>

From tshort at akamai.com  Thu Jul 28 15:20:52 2016
From: tshort at akamai.com (Short, Todd)
Date: Thu, 28 Jul 2016 15:20:52 +0000
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <4952917.uTjBKuQNQs@pintsize.usersys.redhat.com>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com>
 <2530f4bb681c4895bde9f115fc277575@EXCHANGESRV.PARSEC.local>
 <4952917.uTjBKuQNQs@pintsize.usersys.redhat.com>
Message-ID: <5C6F0CF1-6584-40D6-AE5A-593F95553439@akamai.com>

See:

https://tools.ietf.org/html/rfc4086

Section 4 suggests ways to de-skew.

--
-Todd Short
// tshort at akamai.com
// "One if by land, two if by sea, three if by the Internet."

> On Jul 28, 2016, at 6:51 AM, Hubert Kario <hkario at redhat.com> wrote:
> 
> On Wednesday, 27 July 2016 15:23:21 CEST Leon Brits wrote:
>> John,
>> 
>> Thanks for your reply.
>> 
>> The SP800-90B test has different types of test but the test with the lowest
>> output is used as the maximum entropy capability of the chip. That is how I
>> understand it from the FIPS lab.
>> 
>> For the FIPS validation, using a NDRNG, that source must feed the DRBG
>> directly (FIPS lab) and not from something like the PRNG. I use seed the
>> /dev/random from the NDRNG and then source from the PRNG, but that is not
>> allowed for DRBGs. Again I hope I understand them correct.
> 
> but PRNG and DRBG is the same thing, both generate pseudo-random numbers from
> a seed using (hopefully) a cryptographically secure algorithm
> 
> FIPS definitely allows you to use output of one DRBG to seed other DRBG
> 
> in the end, you should gather as much entropy as possible in the system, and
> mix it all together and then use output of a DRBG that uses all that entropy
> to seed other DRBGs
> 
> what that means in practical terms, is feed output from your NDRNG to kernel's
> entropy pool and seed everything from /dev/urandom output (or getrandom())
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic--
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160728/06eb3501/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160728/06eb3501/attachment-0001.sig>

From ssx at av8n.com  Thu Jul 28 16:08:32 2016
From: ssx at av8n.com (John Denker)
Date: Thu, 28 Jul 2016 09:08:32 -0700
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <2d501b0b965b44d481d61afb5443ee25@EXCHANGESRV.PARSEC.local>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com> <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
 <2d501b0b965b44d481d61afb5443ee25@EXCHANGESRV.PARSEC.local>
Message-ID: <579A2E00.5030900@av8n.com>

Let's play a guessing game.  I provide a hardware-based random number
generator of my choosing.  It produces a stream of bytes.  It has
an entropy density greater than 2.35 bits per byte.  This claim is
consistent with all the usual tests, but it is also more than that;
it is not just "apparent" entropy or an upper bound based on testing,
but real honest-to-goodness Boltzmann entropy.  The bytes are IID
(independent and identically distributed).  The design and 
implementation are open to inspection.

On each move in this game, I try to predict the exact value of the
next byte.  Every time I succeed, you pay me a dollar; every time
I fail, I pay you a dollar.  We play at least 100 moves, to minimize
stray fluctuations.

The point is, if you think entropy is a good measure of resistance
to guessing, then you should be eager to play this game, expecting
a huge profit.

Would anybody like to play?


On 07/28/2016 12:40 AM, Leon Brits wrote:
> Thanks for the helping me understand the whole entropy thing better.
>  It is still get the feeling that this is a "best effort" thing and 
> that nobody can actually proof what is correct. I am probably just 
> bringing the math down to my level - sorry.
> 
> With that said for validation I still need to be sure that I give the
> required entropy back from the OpenSSL callback. Now since I am not
> allowed to use a hash with the DRBGs (FIPS lab and SP800-90B section
> 8.4), can you please confirm that, with a source of raw 2b/B entropy
> data, I need to return 4 times the data from the callback function?

That depends on what the objective is.  The objective is not
obvious, as discussed below.

> According to FIPS test lab the lowest value from all the tests are 
> used as the entropy and 2 is too low.

  1a) I assume the idea that "2 is too low" comes from the FIPS lab.

  1b) I assume the designer's boss doesn't directly care about this,
   so long as the FIPS lab is happy.

  1c) This requirement has little if any connection to actual security.

> I must however make use of this chip.

  2a) I assume the FIPS lab doesn't care exactly which chip is used.

  2b) I assume this requirement comes from the boss.

  2c) This requirement has little if any connection to actual security.

> I am not allowed to use a hash with the DRBGs (FIPS lab and
> SP800-90B section 8.4),

Where's That From?  Section 8.4 says nothing about hashes.  It's about
health testing.  The hash doesn't interfere with health testing, unless
the implementation is badly screwed up.

Furthermore, in sections 8.2 and 8.3, and elsewhere, there is explicit
consideration of "conditioning", which is what we're talking about.

  3a) Does this requirement really come from the FIPS lab?  It 
   certainly doesn't come from SP800-90B as claimed.

  3c) This requirement has nothing to do with actual security.

> It is still get the feeling that this is a "best effort" thing and 
> that nobody can actually proof what is correct.

Where's That From?

Proofs are available, based on fundamental physics and math, delineating
what's possible and what's not.

> can you please confirm that, with a source of raw 2b/B entropy data, 
> I need to return 4 times the data from the callback function?

Two answers:
 -- My friend Dilbert says you should do that, in order to make the
  pointy-haired boss happy.
 -- You should not, however, imagine that it provides actual security.

> I have a chip (FDK RPG100) that generates randomness, but the
> SP800-90B python test suite indicated that the chip only provides
> 2.35 bits/byte of entropy

That means the chip design is broken in ways that the manufacturer
does not understand.  The mfgr data indicates it "should" be much
better than that:
  http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf

The mfgr has not analyzed the thing properly, and nobody else will
be able to analyze it at all.  The block diagram in the datasheet
is a joke:
  http://www.fdk.com/cyber-e/pdf/HM-RAE106.pdf#Page=9

> I must however make use of this chip.

My friend suggests you XOR the chip output with a decent, well-
understood HRNG.  That way you can tell the pointy-haired boss
that you "make use of this chip".



------------

Bottom line: consider the contrast:
-- I'm seeing a bunch of feelings and made-up requirements.
-- I have not yet seen any sign of concern for actual security.

Under such conditions it is not possible to give meaningful advice
on how to proceed.

From michel.sales at free.fr  Thu Jul 28 22:13:26 2016
From: michel.sales at free.fr (Michel)
Date: Fri, 29 Jul 2016 00:13:26 +0200
Subject: [openssl-dev] Building current master fails when option
	no-nextprotoneg is used
Message-ID: <003101d1e91d$445130b0$ccf39210$@sales@free.fr>

Hi,

 

Just to let you know that today's master fails to build when option
no-nextprotoneg is used.

Build stop when linking ssl_test.exe :

 

        cl  /I "." /I "include" /I "include" -DOPENSSL_USE_APPLINK
-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE
-DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM  -DWHIRLPOOL_ASM
-DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
-DOPENSSL_API_COMPAT=0x10100000L
"-DENGINESDIR=\"C:\\OpenSSL_DLL\\lib\\engines-1_1\""
"-DOPENSSLDIR=\"c:\\OpenSSL_DLL\\ssl\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo
-DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN
-D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2 /Zi /Fdapp -c
/Fotest\ssl_test_ctx.obj "test\ssl_test_ctx.c" ssl_test_ctx.c

        IF EXIST test\ssl_test.exe.manifest DEL /F /Q
test\ssl_test.exe.manifest

 

        link /nologo /debug /subsystem:console /opt:ref
/out:test\ssl_test.exe @C:\Users\...\AppData\Local\Temp\nm4C03.tmp

handshake_helper.obj : error LNK2019: unresolved external symbol
_SSL_CTX_set_next_protos_advertised_cb referenced in function
_configure_handshake_ctx

handshake_helper.obj : error LNK2019: unresolved external symbol
_SSL_CTX_set_next_proto_select_cb referenced in function
_configure_handshake_ctx

handshake_helper.obj : error LNK2019: unresolved external symbol
_SSL_get0_next_proto_negotiated referenced in function
_do_handshake_internal

test\ssl_test.exe : fatal error LNK1120: 3 unresolved externals

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
12.0

\VC\BIN\link.EXE"' : return code '0x460'

Stop.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160729/9852dd0e/attachment.html>

From kurt at roeckx.be  Thu Jul 28 22:31:07 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 29 Jul 2016 00:31:07 +0200
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com>
 <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
Message-ID: <20160728223106.GA8936@roeckx.be>

On Wed, Jul 27, 2016 at 05:32:49PM -0700, Paul Dale wrote:
> John's spot on the mark here.  Testing gives a maximum entropy not a minimum.  While a maximum is certainly useful, it isn't what you really need to guarantee your seeding.

Fom what I've read, some of the non-IID tests actually underestimate
the actual entropy.  Which is of course better the overestimating
it, but it's also annoying.

It will also never give a value higher than 6, since one of the
tests only uses 6 bits of the input.

> IID is a statistical term meaning independent and identically distributed which in turn means that each sample doesn't depend on any of the other samples (which is clearly incorrect)

You shouldn't run the IID tests when you clearly know it's not an
IID.  If fact, if you're not sure it's an IID you should use the
non-IID tests.


Kurt


From paul.dale at oracle.com  Thu Jul 28 22:40:38 2016
From: paul.dale at oracle.com (Paul Dale)
Date: Thu, 28 Jul 2016 15:40:38 -0700 (PDT)
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <20160728223106.GA8936@roeckx.be>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com> <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
 <20160728223106.GA8936@roeckx.be>
Message-ID: <772049cd-36cc-4c56-84e8-6eec241a2a6d@default>

I probably should have mentioned this in my earlier message, but the exponential example is valid for the NSIT SP800-90B non-IID tests too: 5.74889 bits per byte of assessed entropy.  Again about as good a result as the tests will ever produce given the ceiling of six on the output.  There is still zero actual entropy in the data.  The tests have massively over estimated.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia


-----Original Message-----
From: Kurt Roeckx [mailto:kurt at roeckx.be] 
Sent: Friday, 29 July 2016 8:31 AM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] DRBG entropy

On Wed, Jul 27, 2016 at 05:32:49PM -0700, Paul Dale wrote:
> John's spot on the mark here.  Testing gives a maximum entropy not a minimum.  While a maximum is certainly useful, it isn't what you really need to guarantee your seeding.

Fom what I've read, some of the non-IID tests actually underestimate the actual entropy.  Which is of course better the overestimating it, but it's also annoying.

It will also never give a value higher than 6, since one of the tests only uses 6 bits of the input.

> IID is a statistical term meaning independent and identically 
> distributed which in turn means that each sample doesn't depend on any 
> of the other samples (which is clearly incorrect)

You shouldn't run the IID tests when you clearly know it's not an IID.  If fact, if you're not sure it's an IID you should use the non-IID tests.


Kurt

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

From R.Falck at comforte.com  Fri Jul 29 01:01:40 2016
From: R.Falck at comforte.com (Rod Falck)
Date: Fri, 29 Jul 2016 01:01:40 +0000
Subject: [openssl-dev] 1.0.2h Compile fails if OPENSSL_NO_SHA512 is defined
Message-ID: <2E4E24F6E6E47843B01089BF75379228A913EF18@cf-mail.comforte.local>

I am defining OPENSSL_NO_SHA512 and get a compilation error in ssl/t1_lib.c:

[08:47:30][Step 3/5]                   c->pkeys[SSL_PKEY_ECC].digest = EVP_sha384();
[08:47:30][Step 3/5]                                                 ^
[08:47:30][Step 3/5] "D:\BuildAgent\sandbox_OpenSSL_NSK_TNSR_Debug\ssl/t1_lib.c", line 902: error(611):
[08:47:30][Step 3/5]           a value of type "int" cannot be assigned to an entity of type
[08:47:30][Step 3/5]           "const EVP_MD *"

The above code does not depend on OPENSSL_NO_SHA512 but EVP_sha384 is does not get declared in evp.h:

# ifndef OPENSSL_NO_SHA512
const EVP_MD *EVP_sha384(void);
const EVP_MD *EVP_sha512(void);
# endif

and therefore defaults to returning int, resulting in the compile error. The function containing error code, tls1_check_cert_param, did not exist in 1.0.1.

For now I have just included the #ifndef, but is that sufficient?

Rod.
--
Rod Falck. Software Architect. comForte Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160729/9dc8421b/attachment-0001.html>

From asmarner at yahoo.com  Fri Jul 29 04:11:36 2016
From: asmarner at yahoo.com (asmarner at yahoo.com)
Date: Fri, 29 Jul 2016 04:11:36 +0000 (UTC)
Subject: [openssl-dev] CA chain.
References: <1234749318.8026242.1469765496260.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1234749318.8026242.1469765496260.JavaMail.yahoo@mail.yahoo.com>

Hi,
I am new to SSL stuff.
I was wondering whether the CA chain of a certificate can be changed.
Let say the initial chain is 

Server->Intermediate CA1->Intermediate CA2->Root CA
and during renewal we have Server->Root CA


Sent from Yahoo Mail. Get the app
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160729/0c724b58/attachment.html>

From leonb at parsec.co.za  Fri Jul 29 07:36:20 2016
From: leonb at parsec.co.za (Leon Brits)
Date: Fri, 29 Jul 2016 07:36:20 +0000
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <772049cd-36cc-4c56-84e8-6eec241a2a6d@default>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com> <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
 <20160728223106.GA8936@roeckx.be>
 <772049cd-36cc-4c56-84e8-6eec241a2a6d@default>
Message-ID: <cbce98f13d8949b2a3ac8006af286245@EXCHANGESRV.PARSEC.local>

Paul,

> I probably should have mentioned this in my earlier message, but the
> exponential example is valid for the NSIT SP800-90B non-IID tests too:
> 5.74889 bits per byte of assessed entropy.  Again about as good a result
> as the tests will ever produce given the ceiling of six on the output.
> There is still zero actual entropy in the data.  The tests have massively
> over estimated.

I am just trying to get our device validated, and am not in a position to discuss the Labs test methodologies or the intrinsic math behind it. I thought that by using the NDRNG chip the entropy would not be a problem. Should have done my homework better.

Thanks for your time
LJB


From leonb at parsec.co.za  Fri Jul 29 08:00:17 2016
From: leonb at parsec.co.za (Leon Brits)
Date: Fri, 29 Jul 2016 08:00:17 +0000
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <579A2E00.5030900@av8n.com>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com> <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
 <2d501b0b965b44d481d61afb5443ee25@EXCHANGESRV.PARSEC.local>
 <579A2E00.5030900@av8n.com>
Message-ID: <40636cf195ab45248ae5c34c92595c01@EXCHANGESRV.PARSEC.local>

John,

> Let's play a guessing game.  I provide a hardware-based random number
> generator of my choosing.  It produces a stream of bytes.  It has an
> entropy density greater than 2.35 bits per byte.  This claim is consistent
> with all the usual tests, but it is also more than that; it is not just
> "apparent" entropy or an upper bound based on testing, but real honest-to-
> goodness Boltzmann entropy.  The bytes are IID (independent and
> identically distributed).  The design and implementation are open to
> inspection.
> 
> On each move in this game, I try to predict the exact value of the next
> byte.  Every time I succeed, you pay me a dollar; every time I fail, I pay
> you a dollar.  We play at least 100 moves, to minimize stray fluctuations.
> 
> The point is, if you think entropy is a good measure of resistance to
> guessing, then you should be eager to play this game, expecting a huge
> profit.
> 
> Would anybody like to play?

Brilliant analogy!
 
>   1a) I assume the idea that "2 is too low" comes from the FIPS lab.

Yes
 
>   1b) I assume the designer's boss doesn't directly care about this,
>    so long as the FIPS lab is happy.

Yes

>   1c) This requirement has little if any connection to actual security.

Correct - it's about perception of the client

>   2a) I assume the FIPS lab doesn't care exactly which chip is used.

They did request information about its working which FDK where not willing to divulge.

>   2b) I assume this requirement comes from the boss.

Correct

>   2c) This requirement has little if any connection to actual security.

Correct

> > I am not allowed to use a hash with the DRBGs (FIPS lab and SP800-90B
> > section 8.4),
> 
> Where's That From?  Section 8.4 says nothing about hashes.  It's about
> health testing.  The hash doesn't interfere with health testing, unless
> the implementation is badly screwed up.
>
> Furthermore, in sections 8.2 and 8.3, and elsewhere, there is explicit
> consideration of "conditioning", which is what we're talking about.
> 
>   3a) Does this requirement really come from the FIPS lab?  It
>    certainly doesn't come from SP800-90B as claimed.

I will ask them the question.
 
>   3c) This requirement has nothing to do with actual security.
> 
> > It is still get the feeling that this is a "best effort" thing and
> > that nobody can actually proof what is correct.
> 
> Where's That From?

My opinion (after working on this project)

> Two answers:
>  -- My friend Dilbert says you should do that, in order to make the
>   pointy-haired boss happy.

Wise old Dilbert

>  -- You should not, however, imagine that it provides actual security.

Understood.

> That means the chip design is broken in ways that the manufacturer does
> not understand.  The mfgr data indicates it "should" be much better than
> that:
>   http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf

Agreed. That is why it was selected (from what I heard).

> The mfgr has not analyzed the thing properly, and nobody else will be able
> to analyze it at all.  The block diagram in the datasheet is a joke:
>   http://www.fdk.com/cyber-e/pdf/HM-RAE106.pdf#Page=9
> 
> > I must however make use of this chip.
> 
> My friend suggests you XOR the chip output with a decent, well- understood
> HRNG.  That way you can tell the pointy-haired boss that you "make use of
> this chip".

I wish I could, but my only option to solve this now is using software.

Thanks alot for your reply and time taken to help.
Much appreciated
LJB



From rt at openssl.org  Fri Jul 29 08:01:46 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Fri, 29 Jul 2016 08:01:46 +0000
Subject: [openssl-dev] [openssl.org #4632] Configure does not honor ARMv8
	and Aarch32 flags
In-Reply-To: <CAH8yC8=Fm195_Vn19_pncFDcbRYeW_fMXzeENuyFdmq+viyR0A@mail.gmail.com>
References: <RT-Ticket-4632@openssl.org>
 <CAH8yC8=Fm195_Vn19_pncFDcbRYeW_fMXzeENuyFdmq+viyR0A@mail.gmail.com>
Message-ID: <rt-4.0.19-16000-1469779306-501.4632-21-0@openssl.org>

Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
extensions, but includes vmull and crc32 (vmull include arrangements
other than u8). The gadget also runs Raspian, which is a 32-bit OS
with hard floats.

After Configure completes, the library's -march=armv7 takes precedence
over the user's -march=armv8-a{+crc}.

$ ./config -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
Operating system: armv7l-whatever-linux2
Configuring for linux-armv4
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
    no-asan         [default]  OPENSSL_NO_ASAN (skip dir)
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
    no-crypto-mdebug-backtrace [default]
OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
    no-egd          [default]  OPENSSL_NO_EGD (skip dir)
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL (skip dir)
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-msan         [default]  OPENSSL_NO_MSAN (skip dir)
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
    no-ssl3         [default]  OPENSSL_NO_SSL3 (skip dir)
    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
    no-ubsan        [default]  OPENSSL_NO_UBSAN (skip dir)
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
    no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
    no-zlib         [default]
    no-zlib-dynamic [default]
Configuring for linux-armv4
CC            =gcc
CFLAG         =-Wall -O3 -pthread  -march=armv8-a+crc
-mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
-march=armv7-a -Wa,--noexecstack
SHARED_CFLAG  =-fPIC
DEFINES       =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_MONT
OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM AES_ASM BSAES_ASM
GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG         =
PLIB_LFLAG    =
EX_LIBS       =-ldl
APPS_OBJ      =
CPUID_OBJ     =armcap.o armv4cpuid.o
UPLINK_OBJ    =
BN_ASM        =bn_asm.o armv4-mont.o armv4-gf2m.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-armv4.o
DES_ENC       =des_enc.o fcrypt_b.o
AES_ENC       =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4_enc.o rc4_skey.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
RMD160_OBJ_ASM=
CMLL_ENC      =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ     =ghash-armv4.o ghashv8-armx.o
PADLOCK_OBJ   =
CHACHA_ENC    =chacha-armv4.o
POLY1305_OBJ  =poly1305-armv4.o
BLAKE2_OBJ    =
PROCESSOR     =
RANLIB        =ranlib
ARFLAGS       =
PERL          =/usr/bin/perl

THIRTY_TWO_BIT mode
BN_LLONG mode
RC4 uses unsigned char

Configured for linux-armv4.

**********

$ ./Configure linux-arm64ilp32 -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
...
$ make -j 4
gcc  -I. -Icrypto/include -Iinclude -DDSO_DLFCN -DHAVE_DLFCN_H
-DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM
-DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
-DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -Wall -O3 -pthread
-mabi=ilp32  -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -fPIC -MMD -MF
crypto/aes/aes_core.d.tmp -MT crypto/aes/aes_core.o -c -o
crypto/aes/aes_core.o crypto/aes/aes_core.c
gcc: error: unrecognized argument in option ?-mabi=ilp32?
gcc: note: valid arguments to ?-mabi=? are: aapcs aapcs-linux apcs-gnu
atpcs iwmmxt
...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4632
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 29 08:21:31 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Fri, 29 Jul 2016 08:21:31 +0000
Subject: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8
	and Aarch32 flags
In-Reply-To: <CAH8yC8=DY-=zEmkiRqJBe=5fpQ8w6B21XxP1isKfuGsU5YjwNQ@mail.gmail.com>
References: <RT-Ticket-4633@openssl.org>
 <CAH8yC8=DY-=zEmkiRqJBe=5fpQ8w6B21XxP1isKfuGsU5YjwNQ@mail.gmail.com>
Message-ID: <rt-4.0.19-16154-1469780491-794.4633-21-0@openssl.org>

Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
extensions, but includes vmull and crc32 (vmull include arrangements
other than u8). The gadget also runs Raspian, which is a 32-bit OS
with hard floats.

$ make test V=1

ok 1 - running enginetest
../util/shlib_wrap.sh ./enginetest => 0
ok
../test/recipes/30-test_evp.t ..............
1..1
not ok 1 - running evp_test evptests.txt
../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135

#   Failed test 'running evp_test evptests.txt'
#   at ../test/recipes/30-test_evp.t line 18.
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/30-test_evp_extra.t ........
1..1
PASS

**********

$ ./config -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
Operating system: armv7l-whatever-linux2
Configuring for linux-armv4
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
    no-asan         [default]  OPENSSL_NO_ASAN (skip dir)
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
    no-crypto-mdebug-backtrace [default]
OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
    no-egd          [default]  OPENSSL_NO_EGD (skip dir)
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL (skip dir)
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-msan         [default]  OPENSSL_NO_MSAN (skip dir)
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
    no-ssl3         [default]  OPENSSL_NO_SSL3 (skip dir)
    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
    no-ubsan        [default]  OPENSSL_NO_UBSAN (skip dir)
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
    no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
    no-zlib         [default]
    no-zlib-dynamic [default]
Configuring for linux-armv4
CC            =gcc
CFLAG         =-Wall -O3 -pthread  -march=armv8-a+crc
-mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
-march=armv7-a -Wa,--noexecstack
SHARED_CFLAG  =-fPIC
DEFINES       =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_MONT
OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM AES_ASM BSAES_ASM
GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG         =
PLIB_LFLAG    =
EX_LIBS       =-ldl
APPS_OBJ      =
CPUID_OBJ     =armcap.o armv4cpuid.o
UPLINK_OBJ    =
BN_ASM        =bn_asm.o armv4-mont.o armv4-gf2m.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-armv4.o
DES_ENC       =des_enc.o fcrypt_b.o
AES_ENC       =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4_enc.o rc4_skey.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
RMD160_OBJ_ASM=
CMLL_ENC      =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ     =ghash-armv4.o ghashv8-armx.o
PADLOCK_OBJ   =
CHACHA_ENC    =chacha-armv4.o
POLY1305_OBJ  =poly1305-armv4.o
BLAKE2_OBJ    =
PROCESSOR     =
RANLIB        =ranlib
ARFLAGS       =
PERL          =/usr/bin/perl

THIRTY_TWO_BIT mode
BN_LLONG mode
RC4 uses unsigned char

Configured for linux-armv4.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri Jul 29 09:49:51 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Fri, 29 Jul 2016 09:49:51 +0000
Subject: [openssl-dev] [openssl.org #4632] AutoReply: Configure does not
	honor ARMv8 and Aarch32 flags
In-Reply-To: <CAH8yC8kiLmEUGDj7u25jUixHH6yvrhB=y3MnmufAzP-eB88xdw@mail.gmail.com>
References: <RT-Ticket-4632@openssl.org>
 <CAH8yC8=Fm195_Vn19_pncFDcbRYeW_fMXzeENuyFdmq+viyR0A@mail.gmail.com>
 <rt-4.0.19-16000-1469779306-41.4632-3-0@openssl.org>
 <CAH8yC8kiLmEUGDj7u25jUixHH6yvrhB=y3MnmufAzP-eB88xdw@mail.gmail.com>
Message-ID: <rt-4.0.19-16000-1469785791-609.4632-6-0@openssl.org>

Attached is a patch that adds two Configure targets: linux-aarch32 and
linux-aarch32hf. It might make a good starting point for Aarch32
support.

The patch enables CRC and Crypto extensions by default. It allows the
library and users with custom engines to use the instructions to
offload to hardware.

Users will have to add their preference for -mtune.

It tested OK under the RPI3, except for the EVP failure reported at
http://rt.openssl.org/Ticket/Display.html?id=4633&user=guest&pass=guest
.

**********

diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
index d7db9a8..656b169 100644
--- a/Configurations/10-main.conf
+++ b/Configurations/10-main.conf
@@ -677,6 +677,16 @@ sub vms_info {
         inherit_from     => [ "linux-generic32", asm("armv4_asm") ],
         perlasm_scheme   => "linux32",
     },
+    "linux-aarch32" => {
+        inherit_from     => [ "linux-generic32", asm("armv4_asm") ],
+        cflags           => add("-march=armv8-a+crc
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp"),
+        perlasm_scheme   => "linux32",
+    },
+    "linux-aarch32hf" => {
+        inherit_from     => [ "linux-generic32", asm("armv4_asm") ],
+        cflags           => add("-march=armv8-a+crc
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard"),
+        perlasm_scheme   => "linux32",
+    },
     "linux-aarch64" => {
         inherit_from     => [ "linux-generic64", asm("aarch64_asm") ],
         perlasm_scheme   => "linux64",

On Fri, Jul 29, 2016 at 4:01 AM, The default queue via RT
<rt at openssl.org> wrote:
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
>         "Configure does not honor ARMv8 and Aarch32 flags",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [openssl.org #4632].
>
> Please include the string:
>
>          [openssl.org #4632]
>
> -------------------------------------------------------------------------
> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
> Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
> extensions, but includes vmull and crc32 (vmull include arrangements
> other than u8). The gadget also runs Raspian, which is a 32-bit OS
> with hard floats.
>
> After Configure completes, the library's -march=armv7 takes precedence
> over the user's -march=armv8-a{+crc}.
>
> $ ./config -march=armv8-a+crc -mtune=cortex-a53
> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
> Operating system: armv7l-whatever-linux2
> Configuring for linux-armv4
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
>     no-asan         [default]  OPENSSL_NO_ASAN (skip dir)
>     no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
>     no-crypto-mdebug-backtrace [default]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
>     no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
>     no-egd          [default]  OPENSSL_NO_EGD (skip dir)
>     no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL (skip dir)
>     no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
>     no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
>     no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
>     no-msan         [default]  OPENSSL_NO_MSAN (skip dir)
>     no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
>     no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
>     no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
>     no-ssl3         [default]  OPENSSL_NO_SSL3 (skip dir)
>     no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
>     no-ubsan        [default]  OPENSSL_NO_UBSAN (skip dir)
>     no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
>     no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
>     no-zlib         [default]
>     no-zlib-dynamic [default]
> Configuring for linux-armv4
> CC            =gcc
> CFLAG         =-Wall -O3 -pthread  -march=armv8-a+crc
> -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
> -march=armv7-a -Wa,--noexecstack
...

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4632
Please log in as guest with password guest if prompted

-------------- next part --------------
diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
index d7db9a8..656b169 100644
--- a/Configurations/10-main.conf
+++ b/Configurations/10-main.conf
@@ -677,6 +677,16 @@ sub vms_info {
         inherit_from     => [ "linux-generic32", asm("armv4_asm") ],
         perlasm_scheme   => "linux32",
     },
+    "linux-aarch32" => {
+        inherit_from     => [ "linux-generic32", asm("armv4_asm") ],
+		cflags           => add("-march=armv8-a+crc -mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp"),
+        perlasm_scheme   => "linux32",
+    },
+    "linux-aarch32hf" => {
+        inherit_from     => [ "linux-generic32", asm("armv4_asm") ],
+		cflags           => add("-march=armv8-a+crc -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard"),
+        perlasm_scheme   => "linux32",
+    },
     "linux-aarch64" => {
         inherit_from     => [ "linux-generic64", asm("aarch64_asm") ],
         perlasm_scheme   => "linux64",

From rt at openssl.org  Fri Jul 29 13:21:32 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Fri, 29 Jul 2016 13:21:32 +0000
Subject: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends
In-Reply-To: <CAF8qwaBkkq-eMHX4yieArFk4H3bZ8hS968v7FQg2cARpuGshgw@mail.gmail.com>
References: <RT-Ticket-4572@openssl.org>
 <CAF8qwaBkkq-eMHX4yieArFk4H3bZ8hS968v7FQg2cARpuGshgw@mail.gmail.com>
Message-ID: <rt-4.0.19-16154-1469798492-787.4572-6-0@openssl.org>

On Tue Jun 14 20:30:09 2016, davidben at google.com wrote:
> I recently made some changes around BoringSSL's SSL_set_bio, etc.
> which you
> all might be interested in. The BIO management has two weird behaviors
> right now:
>
> 1. The existence of bbio is leaked in the public API when it should be
> an
> implementation detail. (Otherwise you're stuck with it for DTLS where
> it's
> really messy.) SSL_get_wbio will return it, and SSL_set_bio messes up
> when
> the bbio is active.

Fixed by 2e7dc7cd688.

> 2. SSL_set_bio's object ownership story is a mess. It also doesn't
> quite
> work. This crashes:
> SSL_set_fd(ssl, 1);
> SSL_set_rfd(ssl, 2);
> But this does not:
> SSL_set_fd(ssl, 1);
> SSL_set_wfd(ssl, 2);
> Not that anyone would do such a thing, but the asymmetry is off.

Fixed by 2e7dc7cd688 and in the docs by e040a42e44.

I also added a test, which I verified against the original 1.0.2 implementation
of SSL_set_bio(), in 7fb4c82035.

I found I needed to make some tweaks to the implementation of SSL_set_bio()
from your version in order to preserve the behaviour between 1.0.2 and master.
Possibly your version was a deliberate simplification.

Anyway, marking this as resolved.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572
Please log in as guest with password guest if prompted


From ssx at av8n.com  Fri Jul 29 17:48:03 2016
From: ssx at av8n.com (John Denker)
Date: Fri, 29 Jul 2016 10:48:03 -0700
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <579A2E00.5030900@av8n.com>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com> <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
 <2d501b0b965b44d481d61afb5443ee25@EXCHANGESRV.PARSEC.local>
 <579A2E00.5030900@av8n.com>
Message-ID: <a00d3ed3-a37f-a881-0697-f5f0ecada1a9@av8n.com>

In the context of:

>> I have a chip (FDK RPG100) that generates randomness, but the
>> SP800-90B python test suite indicated that the chip only provides
>> 2.35 bits/byte of entropy

On 07/28/2016 09:08 AM, I wrote:

> That means the chip design is broken in ways that the manufacturer
> does not understand.  The mfgr data indicates it "should" be much
> better than that:
>   http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf

To be scientific, we must consider all the relevant hypotheses.

1) For starters, let's consider the possibility that the python
 test suite is broken.  Apply the test suite to a sufficiently
 random stream. 
  -- An encrypted counter should be good enough.
  -- /dev/urandom is not a paragon of virtue, but it should be
    good enough for this limited purpose.

1a) If the test suite reports a low randomness for the truly random
 stream, then the test is broken.  Find a better test suite and
 start over from Square One.

1b) If the test suite reports a high randomness for the random stream
 but a low randomness for the chip, the chip is broken and cannot be
 trusted for any serious purpose.
  -- You could derate it by another factor of 10 (down to 0.2
   bits per byte) and I still wouldn't trust it.  A stopped
   clock tells the correct time twice a day, but even so, you
   should not use it for seeding your PRNG.
  -- It must be emphasized yet again that for security you
   need a lower bound on the randomness of the source.
   Testing cannot provide this.  A good test provides an upper
   bound.  A bad test tells you nothing.  In any case, testing
   does not provide what you need.  Insofar as the chip passes
   some tests but not others, that should be sufficient to prove
   and illustrate the point.

 Seriously, if the FIPS lab accepts the broken chip for any
 purpose, with or without software postprocesing, then you
 have *two* problems:  A chip that cannot be trusted and a
 lab that cannot be trusted.


2a) We must consider the possibility that the bare chip 
 hardware is OK, but there is a board-level fault, e.g.
 wrong voltage, wrong readout timing, or whatever.

2b) Similarly there is the possibility that the bare chip
 hardware is OK but the data is being mishandled by the
 system-level driver software.  This should be relatively
 easy to fix.

===========

It must be emphasized yet again the entropy (p log 1/p) is
probably not the thing you care about anyway.  If the entropy
density is high (nearly 8 bits per byte) *and* you understand
why it is not higher, you may be able to calculate something
you can trust ... but let's not get ahead of ourselves.


From kurt at roeckx.be  Fri Jul 29 21:51:02 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 29 Jul 2016 23:51:02 +0200
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <772049cd-36cc-4c56-84e8-6eec241a2a6d@default>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com>
 <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
 <20160728223106.GA8936@roeckx.be>
 <772049cd-36cc-4c56-84e8-6eec241a2a6d@default>
Message-ID: <20160729215102.GA9628@roeckx.be>

On Thu, Jul 28, 2016 at 03:40:38PM -0700, Paul Dale wrote:
> I probably should have mentioned this in my earlier message, but the exponential example is valid for the NSIT SP800-90B non-IID tests too: 5.74889 bits per byte of assessed entropy.  Again about as good a result as the tests will ever produce given the ceiling of six on the output.  There is still zero actual entropy in the data.  The tests have massively over estimated.

Tests are never perfect.  There are various things you can do that
will let the result in giving a higher entropy estimate that what
it really has.  You should really know what your testing and input
something from a real noise source.

Some examples of things that will probably give a very high score:
- Any complex sequence of numbers, including things like pi, e,
  the output of a PRNG, ...
- Add 1 bit of entropy (or even less) into a hash function for
  every byte that you pull out of it.

I think it's important to have a model of your noise source and
check that the noise you get actually matches that model.  This
model should also include the expected entropy you get out of your
noise source.


Kurt


From kurt at roeckx.be  Fri Jul 29 22:19:17 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 30 Jul 2016 00:19:17 +0200
Subject: [openssl-dev] DRBG entropy
In-Reply-To: <579A2E00.5030900@av8n.com>
References: <b3c932fc399640c9a847227c2aee4e5d@EXCHANGESRV.PARSEC.local>
 <5798B9A8.6090409@av8n.com>
 <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default>
 <2d501b0b965b44d481d61afb5443ee25@EXCHANGESRV.PARSEC.local>
 <579A2E00.5030900@av8n.com>
Message-ID: <20160729221916.GB9628@roeckx.be>

On Thu, Jul 28, 2016 at 09:08:32AM -0700, John Denker wrote:
> 
> That means the chip design is broken in ways that the manufacturer
> does not understand.  The mfgr data indicates it "should" be much
> better than that:
>   http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf

Reading that, you don't seem to have access to the raw entropy
and the tests you are doing are meaningless.  It really should
always give you a perfect score since it should already be at
least whitened.

I have a feeling that there is at least a misunderstanding of what
that draft standard is saying and that it's isn't being followed.

But if the tests still give you such a low score something seems
to be wrong, which might either be the hardware or software.

Have you tried running NIST's software
(https://github.com/usnistgov/SP800-90B_EntropyAssessment)
yourself?  Can you run it in verbose mode and give the results of
all the tests it ran?


Kurt


From rt at openssl.org  Sat Jul 30 04:49:25 2016
From: rt at openssl.org (David Robson via RT)
Date: Sat, 30 Jul 2016 04:49:25 +0000
Subject: [openssl-dev] [openssl.org #4634] Compiling issue in openssl-1.0.2g
	no-fips
In-Reply-To: <DM2PR0301MB08472887B619ABE4EE002775C8010@DM2PR0301MB0847.namprd03.prod.outlook.com>
References: <RT-Ticket-4634@openssl.org>
 <DM2PR0301MB08472887B619ABE4EE002775C8010@DM2PR0301MB0847.namprd03.prod.outlook.com>
Message-ID: <rt-4.0.19-16000-1469854165-1155.4634-21-0@openssl.org>

Good morning!

I was building openssl for testing use with valgrind on Ubuntu 16.

I followed these steps:
$ mkdir openssl_test
$ cd openssl_test
$ apt-get source openssl
(this retrieved openssl-1.0.2g)
$./config shared -DPURIFY no-asm no-fips
$ make depend
$ make

At this point, I received this linker error:

../libcrypto.so: undefined reference to `FIPS_module_mode'

I tracked it down to the following file:
crypto/rand/md_rand.c

My temporary fix was to change in md_rand.c the reference to FIPS_module_mode() to FIPS_mode().


Thanks,
Dave Robson

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4634
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 08:32:45 2016
From: rt at openssl.org (Nvaeen Shivanna via RT)
Date: Sat, 30 Jul 2016 08:32:45 +0000
Subject: [openssl-dev] [openssl.org #4635] BUG: 100% CPU in windows with
	openssl-1.0.2h
In-Reply-To: <1469862708.23906.YahooMailMobile@web190805.mail.sg3.yahoo.com>
References: <RT-Ticket-4635@openssl.org>
 <1469862708.23906.YahooMailMobile@web190805.mail.sg3.yahoo.com>
Message-ID: <rt-4.0.19-16154-1469867564-792.4635-21-0@openssl.org>

Hi, 

We are observing 100% CPU in windows. Request you to help us to solve it.

a) SSL method used : TLSv1_2_client_method at client side and TLSv1_2_server_method at the server side

b) Open SSL version: openssl1.0.2h

c) Cipher : &quot;AES128-GCM-SHA256&quot;, we have tried other ciphers also, but the same problem observed.

We use VS2010 compile (Microsoft Visual Studio 10.0).



Rgds,
Navi




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4635
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 10:25:25 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Sat, 30 Jul 2016 10:25:25 +0000
Subject: [openssl-dev] [openssl.org #4636] Are the point-at-infinity checks
	in ecp_nistz256 correct?
References: <RT-Ticket-4636@openssl.org>
Message-ID: <rt-4.0.19-16154-1469874325-445.4636-21-0@openssl.org>

Ticket submitted by Brian Smith

When doing math on short Weierstrass curves like P-256, we have to special case
points at infinity. In Jacobian coordinates (X, Y, Z), points at infinity have
Z == 0. However, instead of checking for Z == 0, p256-x86-64 instead checks for
(X, Y) == (0, 0). In other words, it does, in some sense, the opposite of what
I expect it to do.

I have built a testing framework for exploring things like this in *ring*. I
will attach the input file for my tests which show that ecp_nistz256_point_add
seems to fail to recognize the point at infinity correctly. However, it is also
possible that I just don't understand how ecp_nistz256 intends to work. My
questions are:

1. With respect to additions of the form (a + infinity == a) and (infinity + b
== b), is the code in ecp_nistz256_point_add and ecp_nistz256_point_add_affine
correct?

2. if it is correct, could we add more explanation as to why it is correct?

3. Given the specifics of the implementation of the ecp_nistz256
implementation, is it even possible for us to encounter the point at infinity
as one of the parameters to ecp_nistz256_point_add, other than in the very
final addition that adds g_scalar*G + p_scalar*P? See Section 4.1 of [1].

Background: For based point (G) multiplication, the code has a large table of
multiples of G, in affine (not Jacobian) coordinates. The point at infinity
cannot be encoded in affine coordinates. The authors instead decided to encode
the point at infinity as (0, 0), since the affine point (0, 0) isn't on the
P-256 curve. It isn't clear why the authors chose to do that though, since the
point at infinity doesn't (can't, logically) appear in the table of precomputed
multiples of G anyway. Regardless, if you represent the point at infinity as
(0, 0) then it makes sense to check (x, y) == (0, 0).

But, it seems like the functions that do the computations, like
ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the point at
infinity as (_, _, 0), not necessarily (0, 0, _). Also, ecp_nistz256's
EC_METHOD uses ec_GFp_simple_is_at_infinity and
ec_GFp_simple_point_set_to_infinity, which represent the point at infinity with
z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine uses
EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0. This
inconsistency is confusing, if not wrong. Given this, it seems like the
point-at-infinity checks in the ecp_nistz256_point_add and
ecp_nistz256_point_add_affine code should also be checking that z == 0 instead
of (x, y) == (0, 0).

Note that this is confusing because `EC_POINT_new` followed by
`EC_POINT_to_infinity` initializes (X, Y, Z) = (0, 0, 0). Thus, the check of
(x, y) == (0, 0) "works" as well as the check z == 0. But, it doesn't work in
real-life cases where the point is infinity is encountered during calculations,
because we'll have (X, Y) != (0, 0) but Z == 0.

The assembly language code that does this check is hard to understand unless
one is familiar with SIMD. However, the C reference implementation that the
assembly language code used as a model is easy to understand. This code can be
found in the ecp_nistz256.c file.

Note the parameters of ecp_nistz256_point_add are P256_POINT, not
P256_POINT_AFFINE, so "representation of the point at infinity as (0, 0)"
doesn't make sense to me. But, that's exactly what it checks.

In ecp_nistz256_point_add_affine, it makes more sense to me, because parameter
|b| is in fact a |P256_POINT_AFFINE|. However, |a| is not a |P256_POINT_AFFINE|,
so the (x, y) == (0, 0) check doesn't make sense to me. The x86-64 and x86
assembly language code seems to emulate this exactly. I didn't test the ARM
code, but I'd guess it is similar.

[1] https://eprint.iacr.org/2014/130.pdf (Section 4.1)

Here's the specific logic I'm talking about (which is also present in the asm
code):


```
static void ecp_nistz256_point_add(P256_POINT *r,
                                   const P256_POINT *a, const P256_POINT *b) {
    [...]

    const BN_ULONG *in1_x = a->X;
    const BN_ULONG *in1_y = a->Y;
    const BN_ULONG *in1_z = a->Z;

    const BN_ULONG *in2_x = b->X;
    const BN_ULONG *in2_y = b->Y;
    const BN_ULONG *in2_z = b->Z;

    /* We encode infinity as (0,0), which is not on the curve,
     * so it is OK. */
    in1infty = (in1_x[0] | in1_x[1] | in1_x[2] | in1_x[3] |
                in1_y[0] | in1_y[1] | in1_y[2] | in1_y[3]);
    if (P256_LIMBS == 8)
        in1infty |= (in1_x[4] | in1_x[5] | in1_x[6] | in1_x[7] |
                     in1_y[4] | in1_y[5] | in1_y[6] | in1_y[7]);

    in2infty = (in2_x[0] | in2_x[1] | in2_x[2] | in2_x[3] |
                in2_y[0] | in2_y[1] | in2_y[2] | in2_y[3]);
    if (P256_LIMBS == 8)
        in2infty |= (in2_x[4] | in2_x[5] | in2_x[6] | in2_x[7] |
                     in2_y[4] | in2_y[5] | in2_y[6] | in2_y[7]);

    [...]
}

static void ecp_nistz256_point_add_affine(P256_POINT *r,
                                          const P256_POINT *a,
                                          const P256_POINT_AFFINE *b) {
    [...]

    const BN_ULONG *in1_x = a->X;
    const BN_ULONG *in1_y = a->Y;
    const BN_ULONG *in1_z = a->Z;

    const BN_ULONG *in2_x = b->X;
    const BN_ULONG *in2_y = b->Y;

    /*
     * In affine representation we encode infty as (0,0), which is not on the
     * curve, so it is OK
     */
    in1infty = (in1_x[0] | in1_x[1] | in1_x[2] | in1_x[3] |
                in1_y[0] | in1_y[1] | in1_y[2] | in1_y[3]);
    if (P256_LIMBS == 8)
        in1infty |= (in1_x[4] | in1_x[5] | in1_x[6] | in1_x[7] |
                     in1_y[4] | in1_y[5] | in1_y[6] | in1_y[7]);

    in2infty = (in2_x[0] | in2_x[1] | in2_x[2] | in2_x[3] |
                in2_y[0] | in2_y[1] | in2_y[2] | in2_y[3]);
    if (P256_LIMBS == 8)
        in2infty |= (in2_x[4] | in2_x[5] | in2_x[6] | in2_x[7] |
                     in2_y[4] | in2_y[5] | in2_y[6] | in2_y[7]);

    in1infty = is_zero(in1infty);
    in2infty = is_zero(in2infty);

    [...]
}
```

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4636
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 10:49:40 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Sat, 30 Jul 2016 10:49:40 +0000
Subject: [openssl-dev] [openssl.org #4618] BUG: Crash in do_ssl3_write
	unless OPENSSL_NO_MULTIBLOCK
In-Reply-To: <rt-4.0.19-13376-1469471816-454.4618-6-0@openssl.org>
References: <RT-Ticket-4618@openssl.org>
 <rt-4.0.19-13377-1469439679-1750.4618-6-0@openssl.org>
 <hOn6k-l3ABgU06tlqEGeAaD8TWej3wFHtVPHcw79FRrwuSY44@outlook.office365.com>
 <qOcO2oGxHxjVyKiOvE6eqaqSLnyjCwMHgVMHOwu9uRCwMDuwo@outlook.office365.com>
 <rt-4.0.19-13376-1469471816-454.4618-6-0@openssl.org>
Message-ID: <rt-4.0.19-16154-1469875780-1832.4618-6-0@openssl.org>

On Mon Jul 25 18:36:56 2016, dmb at inky.com wrote:
> Yes, that appears to fix it. Thanks!


Fixed in 58c27c207dd. Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4618
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 14:25:14 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sat, 30 Jul 2016 14:25:14 +0000
Subject: [openssl-dev] [openssl.org #4635] BUG: 100% CPU in windows with
	openssl-1.0.2h
In-Reply-To: <1469862708.23906.YahooMailMobile@web190805.mail.sg3.yahoo.com>
References: <RT-Ticket-4635@openssl.org>
 <1469862708.23906.YahooMailMobile@web190805.mail.sg3.yahoo.com>
Message-ID: <rt-4.0.19-16154-1469888714-1312.4635-6-0@openssl.org>

We need some details. Like which function(s) are using the CPU.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4635
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 14:26:05 2016
From: rt at openssl.org (Richard Moore via RT)
Date: Sat, 30 Jul 2016 14:26:05 +0000
Subject: [openssl-dev] [openssl.org #4637] Fwd: Missing accessor - DSA key
	length
In-Reply-To: <CAMp7mVvr=rrTHqpyOuOFxygWdZW4spkRtnzPz7AqZEKHs+FEqA@mail.gmail.com>
References: <RT-Ticket-4637@openssl.org>
 <CAMp7mVvewGNXP+zvZAVUWAY2TqEgRW2iAs4z=av67sGeYSP13g@mail.gmail.com>
 <CAMp7mVvr=rrTHqpyOuOFxygWdZW4spkRtnzPz7AqZEKHs+FEqA@mail.gmail.com>
Message-ID: <rt-4.0.19-16000-1469888765-1961.4637-21-0@openssl.org>

---------- Forwarded message ----------
From: Richard Moore <richmoore44 at gmail.com>
Date: 24 July 2016 at 17:31
Subject: Missing accessor - DSA key length
To: openssl-dev at openssl.org


For RSA we have RSA_bits(), for DH we have DH_bits() for DSA we seem to
only have DSA_size().

Cheers

Rich.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4637
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 14:26:05 2016
From: rt at openssl.org (Richard Moore via RT)
Date: Sat, 30 Jul 2016 14:26:05 +0000
Subject: [openssl-dev] [openssl.org #4638] Fwd: Missing const EC_KEY
	*EC_KEY_dup(EC_KEY *src); 
In-Reply-To: <CAMp7mVtSjOzYWYcDsbhJRjzSmYS6rF6_Fb51fr=2xg4kMYerjg@mail.gmail.com>
References: <RT-Ticket-4638@openssl.org>
 <CAMp7mVvjE5COSXWEPXEaXyWpYVHHWLfChZei9o-3LTL0u3nTyw@mail.gmail.com>
 <CAMp7mVtSjOzYWYcDsbhJRjzSmYS6rF6_Fb51fr=2xg4kMYerjg@mail.gmail.com>
Message-ID: <rt-4.0.19-16000-1469888765-1713.4638-21-0@openssl.org>

---------- Forwarded message ----------
From: Richard Moore <richmoore44 at gmail.com>
Date: 24 July 2016 at 17:38
Subject: Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);
To: openssl-dev at openssl.org


Shouldn't this be  EC_KEY *EC_KEY_dup(const EC_KEY *src);

Cheers

Rich.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4638
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 14:26:06 2016
From: rt at openssl.org (Richard Moore via RT)
Date: Sat, 30 Jul 2016 14:26:06 +0000
Subject: [openssl-dev] [openssl.org #4639] Missing const and docs
	X509_get_notBefore, X509_get_notAfter
In-Reply-To: <CAMp7mVsr8Rzcv=jDxPLRn6OxE+dMxT-ppH7bD4eMK=USbmGtUw@mail.gmail.com>
References: <RT-Ticket-4639@openssl.org>
 <CAMp7mVsr8Rzcv=jDxPLRn6OxE+dMxT-ppH7bD4eMK=USbmGtUw@mail.gmail.com>
Message-ID: <rt-4.0.19-16000-1469888766-716.4639-21-0@openssl.org>



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4639
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 15:39:34 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sat, 30 Jul 2016 15:39:34 +0000
Subject: [openssl-dev] [openssl.org #4632] Configure does not honor
	ARMv8 and Aarch32 flags
In-Reply-To: <815fdffe-757d-fedf-be03-ab9063920434@openssl.org>
References: <RT-Ticket-4632@openssl.org>
 <CAH8yC8=Fm195_Vn19_pncFDcbRYeW_fMXzeENuyFdmq+viyR0A@mail.gmail.com>
 <rt-4.0.19-16000-1469779306-501.4632-21-0@openssl.org>
 <815fdffe-757d-fedf-be03-ab9063920434@openssl.org>
Message-ID: <rt-4.0.19-16154-1469893174-527.4632-6-0@openssl.org>

> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
> Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
> extensions, but includes vmull and crc32 (vmull include arrangements
> other than u8). The gadget also runs Raspian, which is a 32-bit OS
> with hard floats.
> 
> After Configure completes, the library's -march=armv7 takes precedence
> over the user's -march=armv8-a{+crc}.
> 
> $ ./config -march=armv8-a+crc -mtune=cortex-a53
> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard

-mtune -mfloat-abi are more than sufficient in this case. Well, I
wouldn't be surprised if -mfloat-abi is actually redundant, because it
might be the default... And -march suggested by ./config is fine in this
case. For reference, it would be fine even if processor in question had
crypto extensions, because ARMv8 code is compiled even with -march=armv7-a.

> **********
> 
> $ ./Configure linux-arm64ilp32 -march=armv8-a+crc -mtune=cortex-a53
> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard

linux-arm64ilp32 won't do. linux-arm64ilp32 is equivalent of x32 in
x86_64 world. It takes 64-bit[!] kernel and dedicated run-time that
adheres to 64-bit calling convention. Judging from ./config output you
have 32-bit[!] kernel.

For reference, note that you can run even linux-armv4 binaries under
64-bit kernel, and it's not same as ilp32. Just like on x86_64 you can
run x86_64, x32 and x86 binaries, you can run "aarch64", "arm64ilp32"
and 32-bit (hf or not) binaries under aarch64 kernel. Well, provided
that you have corresponding libcs or linked statically...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4632
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 15:47:23 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sat, 30 Jul 2016 15:47:23 +0000
Subject: [openssl-dev] [openssl.org #4632] AutoReply: Configure does not
	honor ARMv8 and Aarch32 flags
In-Reply-To: <909f0695-b980-bc6d-4c3d-260c06717f35@openssl.org>
References: <RT-Ticket-4632@openssl.org>
 <CAH8yC8=Fm195_Vn19_pncFDcbRYeW_fMXzeENuyFdmq+viyR0A@mail.gmail.com>
 <rt-4.0.19-16000-1469779306-41.4632-3-0@openssl.org>
 <CAH8yC8kiLmEUGDj7u25jUixHH6yvrhB=y3MnmufAzP-eB88xdw@mail.gmail.com>
 <rt-4.0.19-16000-1469785791-609.4632-6-0@openssl.org>
 <909f0695-b980-bc6d-4c3d-260c06717f35@openssl.org>
Message-ID: <rt-4.0.19-16154-1469893643-912.4632-6-0@openssl.org>

> Attached is a patch that adds two Configure targets: linux-aarch32 and
> linux-aarch32hf. It might make a good starting point for Aarch32
> support.
> 
> The patch enables CRC and Crypto extensions by default.

Code that utilizes crypto extensions is compiled with -march=armv7-a by
default. Or maybe "assembled" is more accurate term.

> It allows the
> library and users with custom engines to use the instructions to
> offload to hardware.

If some custom engine requires such command line option, it can be used
when compiling the engine. OpenSSL doesn't have to be.

> Users will have to add their preference for -mtune.

See commentary in linux-armv4 section just few lines above. In your case
default configuration with ./config produces perfectly adequate output,
also modulo -mtune argument. Suggested modifications hardly add any value...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4632
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 16:15:10 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sat, 30 Jul 2016 16:15:10 +0000
Subject: [openssl-dev] [openssl.org #4633] EVP self test failure with
	ARMv8 and Aarch32 flags
In-Reply-To: <8bb447d2-dbf0-3c81-cfa6-8ba58be1153f@openssl.org>
References: <RT-Ticket-4633@openssl.org>
 <CAH8yC8=DY-=zEmkiRqJBe=5fpQ8w6B21XxP1isKfuGsU5YjwNQ@mail.gmail.com>
 <rt-4.0.19-16154-1469780491-794.4633-21-0@openssl.org>
 <8bb447d2-dbf0-3c81-cfa6-8ba58be1153f@openssl.org>
Message-ID: <rt-4.0.19-16154-1469895310-699.4633-6-0@openssl.org>

> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
> Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
> extensions, but includes vmull and crc32 (vmull include arrangements
> other than u8).

??? If you're referring to polynomial multiplication, then it's p8, not
u8. But even if you are implying that it implements p64, then I'd ask
where does this information come from? And how would it align with
Cortex-A53 reference manual which says that AES extension and PMULL
availability is denoted by one and same flag? I mean according to
reference there shouldn't be PMULL-capable processor, which is not also
AES-capable...

> The gadget also runs Raspian, which is a 32-bit OS
> with hard floats.
> 
> $ make test V=1
> 
> ok 1 - running enginetest
> ../util/shlib_wrap.sh ./enginetest => 0
> ok
> ../test/recipes/30-test_evp.t ..............
> 1..1
> not ok 1 - running evp_test evptests.txt
> ../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135
> 
> #   Failed test 'running evp_test evptests.txt'
> #   at ../test/recipes/30-test_evp.t line 18.
> # Looks like you failed 1 test of 1.

Could you execute it manually and tell with line in evptests.txt it fails?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 16:46:46 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Sat, 30 Jul 2016 16:46:46 +0000
Subject: [openssl-dev] [openssl.org #4633] EVP self test failure with
	ARMv8 and Aarch32 flags
In-Reply-To: <CAH8yC8ku2GCqYM384mY7a2o7rYm_imuzC7Dha8NaJEV0ZsHJ0w@mail.gmail.com>
References: <RT-Ticket-4633@openssl.org>
 <CAH8yC8=DY-=zEmkiRqJBe=5fpQ8w6B21XxP1isKfuGsU5YjwNQ@mail.gmail.com>
 <rt-4.0.19-16154-1469780491-794.4633-21-0@openssl.org>
 <8bb447d2-dbf0-3c81-cfa6-8ba58be1153f@openssl.org>
 <rt-4.0.19-16154-1469895310-699.4633-6-0@openssl.org>
 <CAH8yC8ku2GCqYM384mY7a2o7rYm_imuzC7Dha8NaJEV0ZsHJ0w@mail.gmail.com>
Message-ID: <rt-4.0.19-16000-1469897206-418.4633-6-0@openssl.org>

>> $ make test V=1
>>
>> ok 1 - running enginetest
>> ../util/shlib_wrap.sh ./enginetest => 0
>> ok
>> ../test/recipes/30-test_evp.t ..............
>> 1..1
>> not ok 1 - running evp_test evptests.txt
>> ../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135
>>
>> #   Failed test 'running evp_test evptests.txt'
>> #   at ../test/recipes/30-test_evp.t line 18.
>> # Looks like you failed 1 test of 1.
>
> Could you execute it manually and tell with line in evptests.txt it fails?

$ LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH" test/evp_test test/evptests.txt
Bus error

Probing further:

$ LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH" gdb test/evp_test
GNU gdb (GDB) 7.11.1
...
Reading symbols from test/evp_test...(no debugging symbols found)...done.
(gdb) r test/evptests.txt
Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
(gdb) where
#0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
#1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
#2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
#3  0x000149cc in cipher_test_run ()
#4  0x0001408c in setup_test ()
#5  0x00011a48 in main ()

(gdb) bt full
#0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
No symbol table info available.
#1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
No symbol table info available.
#2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
No symbol table info available.
#3  0x000149cc in cipher_test_run ()
No symbol table info available.
#4  0x0001408c in setup_test ()
No symbol table info available.
#5  0x00011a48 in main ()
No symbol table info available.

I've added every directory that has symbols ab object files using 'set
debug-file-directory' and 'set solib-search-path'. It looks like
Aarch64 is another platform GDB is broken on:

(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is
"/usr/local/lib/debug".
(gdb)

Jeff


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 16:57:17 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sat, 30 Jul 2016 16:57:17 +0000
Subject: [openssl-dev] [openssl.org #4630] Fatal error U1077: 'ias' :
	return code '0x1' on Skylake processor
In-Reply-To: <473649f0-fdb3-78db-c109-1142aef60ed6@openssl.org>
References: <RT-Ticket-4630@openssl.org>
 <CAH5r+pYOyo5=sjGw0maW95G_aOkyqsoahpAgcK2Uz-SFhf+oXA@mail.gmail.com>
 <rt-4.0.19-13377-1469526126-1741.4630-21-0@openssl.org>
 <473649f0-fdb3-78db-c109-1142aef60ed6@openssl.org>
Message-ID: <rt-4.0.19-16000-1469897837-262.4630-6-0@openssl.org>

Hi,

> I'm trying to set up OpenSSL on Windows 10 64-bit (i7 Skylake), having
> followed the instructions so far, after installing Visual Studio I
> attempted to nmake in the openssl directory using Visual c++ 2008 command
> prompt to get the following error:
> 
>      "C:\Strawberry\perl\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"
>  "-omakefile" "crypto\include\internal\bn_conf.h.in" >
> crypto\include\internal\bn_conf.h
>             "C:\Strawberry\perl\bin\perl.exe" "-I." -Mconfigdata "util\
> dofile.pl"  "-omakefile" "crypto\include\internal\dso_conf.h.in" >
> crypto\include\internal\dso_conf.h
>             "C:\Strawberry\perl\bin\perl.exe" "-I." -Mconfigdata "util\
> dofile.pl"  "-omakefile" "include\openssl\opensslconf.h.in" >
> include\openssl\opensslconf.h
>             ias -d debug -ocrypto\aes\aes-ia64.obj "crypto\aes\aes-ia64.asm"
>     'ias' is not recognized as an internal or external command,
>     operable program or batch file.
>     NMAKE : fatal error U1077: 'ias' : return code '0x1'
>     Stop.

You've chosen wrong platform target at ./Configure command. You've
passed VC-WIN64I, when you should have passed VC-WIN64A. For reference,
originally "I" stood for "Intel" and "A" stood for "AMD". Now we pretend
that "I" stands for "Itanium" and "A" still stands for whatever your
imagination takes you...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4630
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 17:05:01 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Sat, 30 Jul 2016 17:05:01 +0000
Subject: [openssl-dev] [openssl.org #4633] EVP self test failure with
	ARMv8 and Aarch32 flags
In-Reply-To: <CAH8yC8moCzaDX6QUB-xdKH8yFY97xpHr+sFBs6-p4FswCFYbBA@mail.gmail.com>
References: <RT-Ticket-4633@openssl.org>
 <CAH8yC8=DY-=zEmkiRqJBe=5fpQ8w6B21XxP1isKfuGsU5YjwNQ@mail.gmail.com>
 <rt-4.0.19-16154-1469780491-794.4633-21-0@openssl.org>
 <8bb447d2-dbf0-3c81-cfa6-8ba58be1153f@openssl.org>
 <rt-4.0.19-16154-1469895310-699.4633-6-0@openssl.org>
 <CAH8yC8ku2GCqYM384mY7a2o7rYm_imuzC7Dha8NaJEV0ZsHJ0w@mail.gmail.com>
 <CAH8yC8moCzaDX6QUB-xdKH8yFY97xpHr+sFBs6-p4FswCFYbBA@mail.gmail.com>
Message-ID: <rt-4.0.19-16000-1469898301-1345.4633-6-0@openssl.org>

> (gdb) bt full
> #0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
> No symbol table info available.
> #1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
> No symbol table info available.
> #2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
> No symbol table info available.
> #3  0x000149cc in cipher_test_run ()
> No symbol table info available.
> #4  0x0001408c in setup_test ()
> No symbol table info available.
> #5  0x00011a48 in main ()
> No symbol table info available.

OK, -O1 failed to reproduce it; but -O2 reproduced it:

(gdb) r test/evptests.txt
Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
CRYPTO_ccm128_decrypt (ctx=ctx at entry=0x33788,
    inp=inp at entry=0x33649
"\232_\314?\317\004\347)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
out=<optimized out>,
    out at entry=0x335d8
"\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
len=len at entry=0x20) at crypto/modes/ccm128.c:253
253            ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
(gdb)


Jeff


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 18:18:24 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sat, 30 Jul 2016 18:18:24 +0000
Subject: [openssl-dev] [openssl.org #4633] EVP self test failure with
	ARMv8 and Aarch32 flags
In-Reply-To: <117912dc-55f6-d350-4eeb-2d7b855191d6@openssl.org>
References: <RT-Ticket-4633@openssl.org>
 <CAH8yC8=DY-=zEmkiRqJBe=5fpQ8w6B21XxP1isKfuGsU5YjwNQ@mail.gmail.com>
 <rt-4.0.19-16154-1469780491-794.4633-21-0@openssl.org>
 <8bb447d2-dbf0-3c81-cfa6-8ba58be1153f@openssl.org>
 <rt-4.0.19-16154-1469895310-699.4633-6-0@openssl.org>
 <CAH8yC8ku2GCqYM384mY7a2o7rYm_imuzC7Dha8NaJEV0ZsHJ0w@mail.gmail.com>
 <CAH8yC8moCzaDX6QUB-xdKH8yFY97xpHr+sFBs6-p4FswCFYbBA@mail.gmail.com>
 <rt-4.0.19-16000-1469898301-1345.4633-6-0@openssl.org>
 <117912dc-55f6-d350-4eeb-2d7b855191d6@openssl.org>
Message-ID: <rt-4.0.19-16154-1469902704-429.4633-6-0@openssl.org>

>> (gdb) bt full
>> #0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #3  0x000149cc in cipher_test_run ()
>> No symbol table info available.
>> #4  0x0001408c in setup_test ()
>> No symbol table info available.
>> #5  0x00011a48 in main ()
>> No symbol table info available.
> 
> OK, -O1 failed to reproduce it; but -O2 reproduced it:

Well, what can I say? This is first indication that it's a compiler bug...

> (gdb) r test/evptests.txt
> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> 
> Program received signal SIGBUS, Bus error.
> CRYPTO_ccm128_decrypt (ctx=ctx at entry=0x33788,
>     inp=inp at entry=0x33649
> "\232_\314?\317\004\347)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
> out=<optimized out>,
>     out at entry=0x335d8
> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
> len=len at entry=0x20) at crypto/modes/ccm128.c:253
> 253            ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
> (gdb)

This line is within #if defined(STRICT_ALIGNMENT), which means that
compiler is responsible for aligning data, and SIGBUS means that it
failed. And indeed, looking at disassembler output it crashes in vld1.64
{d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
compiler generated the instruction, but didn't care to ensure the
alignment. There is no other conclusion one can draw but that is indeed
a compiler bug. Besides, default ./config works just fine and (once
again) I see no compelling reason for not using it.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 18:53:37 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sat, 30 Jul 2016 18:53:37 +0000
Subject: [openssl-dev] [openssl.org #4633] EVP self test failure with
	ARMv8 and Aarch32 flags
In-Reply-To: <5f59bc9d-c46c-8b0f-2691-f440e2916131@openssl.org>
References: <RT-Ticket-4633@openssl.org>
 <CAH8yC8=DY-=zEmkiRqJBe=5fpQ8w6B21XxP1isKfuGsU5YjwNQ@mail.gmail.com>
 <rt-4.0.19-16154-1469780491-794.4633-21-0@openssl.org>
 <8bb447d2-dbf0-3c81-cfa6-8ba58be1153f@openssl.org>
 <CAH8yC8ku2GCqYM384mY7a2o7rYm_imuzC7Dha8NaJEV0ZsHJ0w@mail.gmail.com>
 <CAH8yC8moCzaDX6QUB-xdKH8yFY97xpHr+sFBs6-p4FswCFYbBA@mail.gmail.com>
 <rt-4.0.19-16000-1469898301-1345.4633-6-0@openssl.org>
 <117912dc-55f6-d350-4eeb-2d7b855191d6@openssl.org>
 <rt-4.0.19-16154-1469902704-429.4633-6-0@openssl.org>
 <5f59bc9d-c46c-8b0f-2691-f440e2916131@openssl.org>
Message-ID: <rt-4.0.19-16000-1469904817-1213.4633-6-0@openssl.org>

On 7/30/2016 8:18 PM, Andy Polyakov via RT wrote:
>>> (gdb) bt full
>>> #0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #3  0x000149cc in cipher_test_run ()
>>> No symbol table info available.
>>> #4  0x0001408c in setup_test ()
>>> No symbol table info available.
>>> #5  0x00011a48 in main ()
>>> No symbol table info available.
>>
>> OK, -O1 failed to reproduce it; but -O2 reproduced it:
> 
> Well, what can I say? This is first indication that it's a compiler bug...
> 
>> (gdb) r test/evptests.txt
>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>
>> Program received signal SIGBUS, Bus error.
>> CRYPTO_ccm128_decrypt (ctx=ctx at entry=0x33788,
>>     inp=inp at entry=0x33649
>> "\232_\314?\317\004\347)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
>> out=<optimized out>,
>>     out at entry=0x335d8
>> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
>> len=len at entry=0x20) at crypto/modes/ccm128.c:253
>> 253            ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>> (gdb)
> 
> This line is within #if defined(STRICT_ALIGNMENT), which means that
> compiler is responsible for aligning data, and SIGBUS means that it
> failed. And indeed, looking at disassembler output it crashes in vld1.64
> {d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
> compiler generated the instruction, but didn't care to ensure the
> alignment. There is no other conclusion one can draw but that is indeed
> a compiler bug.

Problematic option seems to be -mfpu=crypto-neon-fp-armv8.

> Besides, default ./config works just fine and (once
> again) I see no compelling reason for not using it.

For reference, specifying -mfpu doesn't really give you an advantage in
OpenSSL. There are no floating-point calculations on
performance-critical paths. And performance-critical cases when NEON is
used for crypto operations, it's done irregardless -mfpu flag. I mean it
will use NEON even if you don't pass -mfpu. In other words, stick to
default configuration...



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 19:24:27 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Sat, 30 Jul 2016 19:24:27 +0000
Subject: [openssl-dev] [openssl.org #4633] EVP self test failure with
	ARMv8 and Aarch32 flags
In-Reply-To: <CAH8yC8mc7F_DyvfiNxdrxa0Uas48Qb3CEc1N5griJN6vKnNC=Q@mail.gmail.com>
References: <RT-Ticket-4633@openssl.org>
 <CAH8yC8=DY-=zEmkiRqJBe=5fpQ8w6B21XxP1isKfuGsU5YjwNQ@mail.gmail.com>
 <rt-4.0.19-16154-1469780491-794.4633-21-0@openssl.org>
 <8bb447d2-dbf0-3c81-cfa6-8ba58be1153f@openssl.org>
 <CAH8yC8ku2GCqYM384mY7a2o7rYm_imuzC7Dha8NaJEV0ZsHJ0w@mail.gmail.com>
 <CAH8yC8moCzaDX6QUB-xdKH8yFY97xpHr+sFBs6-p4FswCFYbBA@mail.gmail.com>
 <rt-4.0.19-16000-1469898301-1345.4633-6-0@openssl.org>
 <117912dc-55f6-d350-4eeb-2d7b855191d6@openssl.org>
 <rt-4.0.19-16154-1469902704-429.4633-6-0@openssl.org>
 <CAH8yC8mc7F_DyvfiNxdrxa0Uas48Qb3CEc1N5griJN6vKnNC=Q@mail.gmail.com>
Message-ID: <rt-4.0.19-14222-1469906667-231.4633-6-0@openssl.org>

>> (gdb) r test/evptests.txt
>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>
>> Program received signal SIGBUS, Bus error.
>> CRYPTO_ccm128_decrypt (ctx=ctx at entry=0x33788,
>>     inp=inp at entry=0x33649
>> "\232_\314?\317\004\347)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
>> out=<optimized out>,
>>     out at entry=0x335d8
>> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
>> len=len at entry=0x20) at crypto/modes/ccm128.c:253
>> 253            ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>> (gdb)
>
> This line is within #if defined(STRICT_ALIGNMENT), which means that
> compiler is responsible for aligning data, and SIGBUS means that it
> failed. And indeed, looking at disassembler output it crashes in vld1.64
> {d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
> compiler generated the instruction, but didn't care to ensure the
> alignment. There is no other conclusion one can draw but that is indeed
> a compiler bug. Besides, default ./config works just fine and (once
> again) I see no compelling reason for not using it.

I think these are the lines:

#if defined(STRICT_ALIGNMENT)
        union {
            u64 u[2];
            u8 c[16];
        } temp;
#endif

...

#if defined(STRICT_ALIGNMENT)
        memcpy(temp.c, inp, 16);
        ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
        ctx->cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
        ...
#endif

I *thought* accessing a union member through its inactive member is
undefined behavior. Once 'scratch.c' and 'temp.c' were used, using
'temp.c' and 'temp.u' leads to the UB.

Maybe my wires are crossed somewhere....

Jeff


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted


From rt at openssl.org  Sat Jul 30 20:42:37 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sat, 30 Jul 2016 20:42:37 +0000
Subject: [openssl-dev] [openssl.org #4633] EVP self test failure with
	ARMv8 and Aarch32 flags
In-Reply-To: <71778743-770d-7548-c672-977f7c7bbc48@openssl.org>
References: <RT-Ticket-4633@openssl.org>
 <CAH8yC8=DY-=zEmkiRqJBe=5fpQ8w6B21XxP1isKfuGsU5YjwNQ@mail.gmail.com>
 <rt-4.0.19-16154-1469780491-794.4633-21-0@openssl.org>
 <8bb447d2-dbf0-3c81-cfa6-8ba58be1153f@openssl.org>
 <rt-4.0.19-16000-1469898301-1345.4633-6-0@openssl.org>
 <117912dc-55f6-d350-4eeb-2d7b855191d6@openssl.org>
 <rt-4.0.19-16154-1469902704-429.4633-6-0@openssl.org>
 <CAH8yC8mc7F_DyvfiNxdrxa0Uas48Qb3CEc1N5griJN6vKnNC=Q@mail.gmail.com>
 <rt-4.0.19-14222-1469906667-231.4633-6-0@openssl.org>
 <71778743-770d-7548-c672-977f7c7bbc48@openssl.org>
Message-ID: <rt-4.0.19-16154-1469911357-66.4633-6-0@openssl.org>

>>> (gdb) r test/evptests.txt
>>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>>
>>> Program received signal SIGBUS, Bus error.
>>> CRYPTO_ccm128_decrypt (ctx=ctx at entry=0x33788,
>>>     inp=inp at entry=0x33649
>>> "\232_\314?\317\004\347)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
>>> out=<optimized out>,
>>>     out at entry=0x335d8
>>> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267?+\230dxg&",
>>> len=len at entry=0x20) at crypto/modes/ccm128.c:253
>>> 253            ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>>> (gdb)
>>
>> This line is within #if defined(STRICT_ALIGNMENT), which means that
>> compiler is responsible for aligning data, and SIGBUS means that it
>> failed. And indeed, looking at disassembler output it crashes in vld1.64
>> {d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
>> compiler generated the instruction, but didn't care to ensure the
>> alignment. There is no other conclusion one can draw but that is indeed
>> a compiler bug. Besides, default ./config works just fine and (once
>> again) I see no compelling reason for not using it.
> 
> I think these are the lines:
> 
> #if defined(STRICT_ALIGNMENT)
>         union {
>             u64 u[2];
>             u8 c[16];
>         } temp;
> #endif
> 
> ...
> 
> #if defined(STRICT_ALIGNMENT)
>         memcpy(temp.c, inp, 16);
>         ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>         ctx->cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
>         ...
> #endif
> 
> I *thought* accessing a union member through its inactive member is
> undefined behavior.

Really? It says "When a value is stored in a member of an object of
union type, the bytes of the object representation that do not
correspond to that member but do correspond to other members take
unspecified values." Referred members fully overlap and there are no
bytes that correspond to one and not another.

> Once 'scratch.c' and 'temp.c' were used, using
> 'temp.c' and 'temp.u' leads to the UB.

But either way union with u64 member has to be aligned, so references to
.u should not cause SIGBUS.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted


From davidben at google.com  Sat Jul 30 22:45:08 2016
From: davidben at google.com (David Benjamin)
Date: Sat, 30 Jul 2016 22:45:08 +0000
Subject: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends
In-Reply-To: <rt-4.0.19-16154-1469798492-787.4572-6-0@openssl.org>
References: <RT-Ticket-4572@openssl.org>
 <CAF8qwaBkkq-eMHX4yieArFk4H3bZ8hS968v7FQg2cARpuGshgw@mail.gmail.com>
 <rt-4.0.19-16154-1469798492-787.4572-6-0@openssl.org>
Message-ID: <CAF8qwaBTnyvT3e17rVzj_BKAWmsn7bzqfFGjspW3pRHMkRLP6g@mail.gmail.com>

On Fri, Jul 29, 2016 at 9:21 AM Matt Caswell via RT <rt at openssl.org> wrote:

> On Tue Jun 14 20:30:09 2016, davidben at google.com wrote:
> > I recently made some changes around BoringSSL's SSL_set_bio, etc.
> > which you
> > all might be interested in. The BIO management has two weird behaviors
> > right now:
> >
> > 1. The existence of bbio is leaked in the public API when it should be
> > an
> > implementation detail. (Otherwise you're stuck with it for DTLS where
> > it's
> > really messy.) SSL_get_wbio will return it, and SSL_set_bio messes up
> > when
> > the bbio is active.
>
> Fixed by 2e7dc7cd688.
>
> > 2. SSL_set_bio's object ownership story is a mess. It also doesn't
> > quite
> > work. This crashes:
> > SSL_set_fd(ssl, 1);
> > SSL_set_rfd(ssl, 2);
> > But this does not:
> > SSL_set_fd(ssl, 1);
> > SSL_set_wfd(ssl, 2);
> > Not that anyone would do such a thing, but the asymmetry is off.
>
> Fixed by 2e7dc7cd688 and in the docs by e040a42e44.
>
> I also added a test, which I verified against the original 1.0.2
> implementation
> of SSL_set_bio(), in 7fb4c82035.
>
> I found I needed to make some tweaks to the implementation of SSL_set_bio()
> from your version in order to preserve the behaviour between 1.0.2 and
> master.
> Possibly your version was a deliberate simplification.


Hrm. It's been a while, but I believe it was a deliberate simplification to
fix the SSL_set_rfd crash above.

My interpretation was that SSL_set_rfd and SSL_set_wfd's calling
pattern, insane
as it is, is definitively correct. Thus, the asymmetry in SSL_set_bio is a
bug and was a deliberate change on my part.

It seems your interpretation was that SSL_set_bio's behavior, insane as it
is, is definitively correct. Thus the bug lies in SSL_set_[rw]fd using
SSL_set_bio wrong, so you changed those functions and kept SSL_set_bio's
behavior as-is. (I'm not sure SSL_set_bio actually lets you implement
SSL_set_rfd, but you have the new side-specific setters and just used that.)

I like my interpretation slightly better if only because it makes
SSL_set_bio's behavior a little more sane. Judging by SSL_set_[rw]fd, it
also seems to have been the original intent. It is a behavior change, but
one I'm sure will break no one.

(If you still prefer yours, I will make BoringSSL match since I see no
reason for us to diverge here.)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160730/a52bf86e/attachment.html>

From rt at openssl.org  Sat Jul 30 22:45:33 2016
From: rt at openssl.org (David Benjamin via RT)
Date: Sat, 30 Jul 2016 22:45:33 +0000
Subject: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends
In-Reply-To: <CAF8qwaBTnyvT3e17rVzj_BKAWmsn7bzqfFGjspW3pRHMkRLP6g@mail.gmail.com>
References: <RT-Ticket-4572@openssl.org>
 <CAF8qwaBkkq-eMHX4yieArFk4H3bZ8hS968v7FQg2cARpuGshgw@mail.gmail.com>
 <rt-4.0.19-16154-1469798492-787.4572-6-0@openssl.org>
 <CAF8qwaBTnyvT3e17rVzj_BKAWmsn7bzqfFGjspW3pRHMkRLP6g@mail.gmail.com>
Message-ID: <rt-4.0.19-16000-1469918733-444.4572-6-0@openssl.org>

On Fri, Jul 29, 2016 at 9:21 AM Matt Caswell via RT <rt at openssl.org> wrote:

> On Tue Jun 14 20:30:09 2016, davidben at google.com wrote:
> > I recently made some changes around BoringSSL's SSL_set_bio, etc.
> > which you
> > all might be interested in. The BIO management has two weird behaviors
> > right now:
> >
> > 1. The existence of bbio is leaked in the public API when it should be
> > an
> > implementation detail. (Otherwise you're stuck with it for DTLS where
> > it's
> > really messy.) SSL_get_wbio will return it, and SSL_set_bio messes up
> > when
> > the bbio is active.
>
> Fixed by 2e7dc7cd688.
>
> > 2. SSL_set_bio's object ownership story is a mess. It also doesn't
> > quite
> > work. This crashes:
> > SSL_set_fd(ssl, 1);
> > SSL_set_rfd(ssl, 2);
> > But this does not:
> > SSL_set_fd(ssl, 1);
> > SSL_set_wfd(ssl, 2);
> > Not that anyone would do such a thing, but the asymmetry is off.
>
> Fixed by 2e7dc7cd688 and in the docs by e040a42e44.
>
> I also added a test, which I verified against the original 1.0.2
> implementation
> of SSL_set_bio(), in 7fb4c82035.
>
> I found I needed to make some tweaks to the implementation of SSL_set_bio()
> from your version in order to preserve the behaviour between 1.0.2 and
> master.
> Possibly your version was a deliberate simplification.


Hrm. It's been a while, but I believe it was a deliberate simplification to
fix the SSL_set_rfd crash above.

My interpretation was that SSL_set_rfd and SSL_set_wfd's calling
pattern, insane
as it is, is definitively correct. Thus, the asymmetry in SSL_set_bio is a
bug and was a deliberate change on my part.

It seems your interpretation was that SSL_set_bio's behavior, insane as it
is, is definitively correct. Thus the bug lies in SSL_set_[rw]fd using
SSL_set_bio wrong, so you changed those functions and kept SSL_set_bio's
behavior as-is. (I'm not sure SSL_set_bio actually lets you implement
SSL_set_rfd, but you have the new side-specific setters and just used that.)

I like my interpretation slightly better if only because it makes
SSL_set_bio's behavior a little more sane. Judging by SSL_set_[rw]fd, it
also seems to have been the original intent. It is a behavior change, but
one I'm sure will break no one.

(If you still prefer yours, I will make BoringSSL match since I see no
reason for us to diverge here.)

David

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 31 12:58:08 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sun, 31 Jul 2016 12:58:08 +0000
Subject: [openssl-dev] [openssl.org #4569] Enhancement request: Macros
	for x86 capability bits
In-Reply-To: <c2f2b53c-054a-0cf6-011e-c8606eda7026@openssl.org>
References: <RT-Ticket-4569@openssl.org>
 <HE1PR05MB16418CD9579D9618FD7B7147FD540@HE1PR05MB1641.eurprd05.prod.outlook.com>
 <rt-4.0.19-2299-1465918970-617.4569-21-0@openssl.org>
 <c2f2b53c-054a-0cf6-011e-c8606eda7026@openssl.org>
Message-ID: <rt-4.0.19-24508-1469969888-939.4569-6-0@openssl.org>

> For x86, define macros for capability bits (like for arm and pcc), according to https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html:

As discussed in RT#4568 and RT#4570, these are internal interfaces and
there is no intention to expose it to user, except through setting
environment variable. Even that is recommended for specific test and
debugging scenarios rather than for production use. And since macros are
of no help when setting environment variable, suggestion is declined.




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4569
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 31 13:10:39 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sun, 31 Jul 2016 13:10:39 +0000
Subject: [openssl-dev] [openssl.org #4046] Fix xmm6 register clobbering
	in crypto/bn/asm/x86_64-mont5.pl:bn_power5() under Win64
In-Reply-To: <1fd1d4e0-d9ab-6f9a-6731-9e5dbaf9fd4e@openssl.org>
References: <RT-Ticket-4046@openssl.org>
 <4C22BDED-F783-404A-BF1F-77E32F0C6470@celemony.com>
 <rt-4.0.19-4916-1442398787-1321.4046-21-0@openssl.org>
 <1fd1d4e0-d9ab-6f9a-6731-9e5dbaf9fd4e@openssl.org>
Message-ID: <rt-4.0.19-12912-1469970639-875.4046-6-0@openssl.org>

Hi,

> i had some problems on Win64 using BIO_do_handshake/BIO_should_retry in a loop. The compiler optimizer placed a local variable value in the xmm6 register.
> The content of this register was destroyed after calling BIO_do_handshake. I debugged this and found that the xmm6/xmm7 registers were not restored.
> I fixed this with following diff for openssl-1.0.2d / x86_64-mont5.pl (bn_power5 and bn_from_mont8x):
> 
> 1013a1014,1020
>> ___
>> $code.=<<___ if ($win64);
>> movaps	-88(%rsi),%xmm6
>> movaps	-72(%rsi),%xmm7
>> ___
>> $code.=<<___;
>>
> 2005a2013,2019
>> ___
>> $code.=<<___ if ($win64);
>> movaps	-88(%rsi),%xmm6
>> movaps	-72(%rsi),%xmm7
>> ___
>> $code.=<<___;
>>
> 
> The fix in bn_from_mont8x was not necessary for me but i think the lines are also missing there.

This resolved itself it the course of fixing other problems. Thanks for
report!



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4046
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 31 13:58:19 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 31 Jul 2016 13:58:19 +0000
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to
	overlapping regions check
In-Reply-To: <57963956.2060809@mit.edu>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
Message-ID: <rt-4.0.19-24508-1469973499-191.4628-6-0@openssl.org>

Does current master work? I think Andy checked in a fix.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 31 15:06:07 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sun, 31 Jul 2016 15:06:07 +0000
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due
	to overlapping regions check
In-Reply-To: <6de7f94d-394d-14b8-ec06-824b70129288@openssl.org>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
 <rt-4.0.19-24508-1469973499-191.4628-6-0@openssl.org>
 <6de7f94d-394d-14b8-ec06-824b70129288@openssl.org>
Message-ID: <rt-4.0.19-24508-1469977567-256.4628-6-0@openssl.org>

> Does current master work? I think Andy checked in a fix.

Rich was few minutes ahead. Now it's committed. Provided test case was
verified to work. Thanks for report.




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted


From rsalz at akamai.com  Sun Jul 31 15:32:26 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 31 Jul 2016 15:32:26 +0000
Subject: [openssl-dev] Building current master fails when
	option	no-nextprotoneg is used
In-Reply-To: <003101d1e91d$445130b0$ccf39210$@sales@free.fr>
References: <003101d1e91d$445130b0$ccf39210$@sales@free.fr>
Message-ID: <0284666d15e4459985b6a5ac504e804b@usma1ex-dag1mb1.msg.corp.akamai.com>


> Just to let you know that today's master fails to build when option no-nextprotoneg is used.

This will be fixed shortly; the fix is being reviewed.  Thanks.

--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz



From michel.sales at free.fr  Sun Jul 31 17:50:44 2016
From: michel.sales at free.fr (Michel)
Date: Sun, 31 Jul 2016 19:50:44 +0200
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due
	to	overlapping regions check
In-Reply-To: <rt-4.0.19-24508-1469973499-191.4628-6-0@openssl.org>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
 <rt-4.0.19-24508-1469973499-191.4628-6-0@openssl.org>
Message-ID: <000001d1eb54$13942070$3abc6150$@sales@free.fr>

Not speaking for Greg, but for me, it is now working fine again.
Thanks Andy !

-----Message d'origine-----
De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Rich
Salz via RT
Envoy??: dimanche 31 juillet 2016 15:58
??: ghudson at mit.edu
Cc?: openssl-dev at openssl.org
Objet?: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to
overlapping regions check

Does current master work? I think Andy checked in a fix.


From rt at openssl.org  Sun Jul 31 17:51:28 2016
From: rt at openssl.org (Michel via RT)
Date: Sun, 31 Jul 2016 17:51:28 +0000
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due
	to overlapping regions check
In-Reply-To: <000001d1eb54$13942070$3abc6150$@sales@free.fr>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
 <rt-4.0.19-24508-1469973499-191.4628-6-0@openssl.org>
 <000001d1eb54$13942070$3abc6150$@sales@free.fr>
Message-ID: <rt-4.0.19-12912-1469987488-749.4628-6-0@openssl.org>

Not speaking for Greg, but for me, it is now working fine again.
Thanks Andy !

-----Message d'origine-----
De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Rich
Salz via RT
Envoy??: dimanche 31 juillet 2016 15:58
??: ghudson at mit.edu
Cc?: openssl-dev at openssl.org
Objet?: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to
overlapping regions check

Does current master work? I think Andy checked in a fix.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 31 17:53:28 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 31 Jul 2016 17:53:28 +0000
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to
	overlapping regions check
In-Reply-To: <57963956.2060809@mit.edu>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
Message-ID: <rt-4.0.19-24508-1469987608-249.4628-6-0@openssl.org>

Resolved by Andy's fix. Closing.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 31 19:17:32 2016
From: rt at openssl.org (David Benjamin via RT)
Date: Sun, 31 Jul 2016 19:17:32 +0000
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due
	to overlapping regions check
In-Reply-To: <CAF8qwaAy4sqqRVA2aq=E=X3tMPguqmAmy_KpQm0TThEDfoBeUw@mail.gmail.com>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
 <rt-4.0.19-24508-1469987608-249.4628-6-0@openssl.org>
 <CAF8qwaAy4sqqRVA2aq=E=X3tMPguqmAmy_KpQm0TThEDfoBeUw@mail.gmail.com>
Message-ID: <rt-4.0.19-12912-1469992652-1205.4628-6-0@openssl.org>

Hey folks,

I do not believe this fix works and introduces buffer overflows.

Looking at this change:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=abdb460d8abe68fedcf00b52d2ba4bf4b7c1725c

It makes EVP_CipherUpdate write to out directly. While not unreasonable
(this BIO probably should never buffer more than a block and otherwise use
the buffer passed in), one must take care to never output more than outl
bytes. There are a number of problems here:

1. The logic to compute buf_len above rounds outl *up* to a multiple of
EVP_MAX_BLOCK_LENGTH. Thus, if outl > buf_len and BIO_read returns the full
buf_len bytes, EVP_CipherUpdate, may write up to buf_len bytes and exceed
outl.

2. If the EVP_CIPHER_CTX contains a partial block buffered, even if outl ==
buf_len, we may *still* output more than outl bytes. For instance, the BIO
may be connected to a pipe and BIO_read return less than buf_len. That will
feed a partial block into the EVP_CIPHER_CTX and, the next time around, we
output more data than expected.

3. Actually, #2 even means the EVP_CIPHER overlapping buffers check is
wrong. The true requirement is not "if the buffers alias, then in == out",
but "if the buffers alias, then out + ctx->num == in". EVP_CIPHER's block
cipher handling is a very leaky abstraction.

I was able to trigger a crash simply by chaining an encrypt BIO with a
memory BIO containing a large plaintext and then stream 100 bytes out of it
at a time. BIO_read would consistently return 128 and, by the time the
function returned, the stack was thoroughly clobbered.

#3 suggests a very minimal fix. Revert the direct output codepath (not
wrong, but I think the BIO needs a complete rewrite with a block-size
buffer for that sort of thing anyway). Then, instead of reading BUF_OFFSET
bytes in at the BIO_read call, read ctx->num bytes in. Then go and fix the
EVP_CIPHER overlap check so it handles the ctx->num != 0 case correctly.

NB: I'm unclear on what the BUF_OFFSET offset was originally for. The
comment just says to read the EVP_Cipher documentation, but there is no pod
file for EVP_Cipher. I am assuming it was to get around this partial block
problem, but perhaps I'm missing something and my suggestion is also wrong.

Hope this helps,

David

PS: Should the new codepath have been setting ctx->cont? The others do.
Though it looks like it might be a no-op when set to 1? I'm not sure.

PPS: This sort of streaming stuff is quite hairy. Like the poly1305
streaming bits, it would make sense to write some tests here. Get a long
plaintext/ciphertext vector or two (I'd test both a block cipher and a
stream cipher) and make sure everything behaves correctly against various
interesting read patterns. Both when the outl pattern varies and when the
inner BIO_read return pattern varies.

On Sun, Jul 31, 2016 at 1:53 PM Rich Salz via RT <rt at openssl.org> wrote:

> Resolved by Andy's fix. Closing.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 31 19:33:47 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sun, 31 Jul 2016 19:33:47 +0000
Subject: [openssl-dev] [openssl.org #4530] [BUG] OpenSSL crash on
	Windows 10
In-Reply-To: <8752d759-f175-f22c-d7ba-1f5623397b13@openssl.org>
References: <RT-Ticket-4530@openssl.org>
 <SN2PR0801MB2223F8965BFDDCBD616182129A7A0@SN2PR0801MB2223.namprd08.prod.outlook.com>
 <rt-4.0.19-2506-1462313621-705.4530-21-0@openssl.org>
 <8752d759-f175-f22c-d7ba-1f5623397b13@openssl.org>
Message-ID: <rt-4.0.19-12912-1469993627-993.4530-6-0@openssl.org>

Hi,

> Hi, our team have been experiencing a crash in some production
> machines (which I cannot reproduce in development machines) caused by
> the libeay32 module in 64 bits Windows 10 machines.
> 
> I was able to create a simple "crash application" and was able to get
> the dump of the crash along with PDB files for both the libeay32.dll
> and the sample application.
> 
> The exception code being thrown is 0xC0000005 (invalid memory access)
> and occurs inside sha1_block_data_order_shaext(), sha1-x86_64.asm,
> line 1435. The version used was 1.0.2g (but older versions also crash
> - the latest dev version from github crash as well).

Oh! Your machines don't seem like something everybody has :-) I mean
SHAEXT-capable CPUs are rare... Anyway, please verify attached patch.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4530
Please log in as guest with password guest if prompted

-------------- next part --------------
diff --git a/crypto/sha/asm/sha1-x86_64.pl b/crypto/sha/asm/sha1-x86_64.pl
index e8f61ab..97baae3 100755
--- a/crypto/sha/asm/sha1-x86_64.pl
+++ b/crypto/sha/asm/sha1-x86_64.pl
@@ -380,9 +380,9 @@ $code.=<<___;
 .align	16
 .Loop_shaext:
 	dec		$num
-	lea		0x40($inp),%rax		# next input block
+	lea		0x40($inp),%r8		# next input block
 	paddd		@MSG[0],$E
-	cmovne		%rax,$inp
+	cmovne		%r8,$inp
 	movdqa		$ABCD,$ABCD_SAVE	# offload $ABCD
 ___
 for($i=0;$i<20-4;$i+=2) {

From matt at openssl.org  Sun Jul 31 20:43:35 2016
From: matt at openssl.org (Matt Caswell)
Date: Sun, 31 Jul 2016 21:43:35 +0100
Subject: [openssl-dev] OpenSSL 1.1.0 release dates
Message-ID: <11b42d9f-9593-d9e8-3d3c-2ef0a360a56a@openssl.org>

FYI, we have recently updated our release strategy for version 1.1.0:
https://www.openssl.org/policies/releasestrat.html

The change is to add the following two dates:

- 4th August 2016, 1.1.0 beta 3 release
- 25th August 2016, 1.1.0 public release

Matt

From michel.sales at free.fr  Sun Jul 31 22:17:26 2016
From: michel.sales at free.fr (Michel)
Date: Mon, 1 Aug 2016 00:17:26 +0200
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression
	due	to overlapping regions check
In-Reply-To: <rt-4.0.19-12912-1469992652-1205.4628-6-0@openssl.org>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
 <rt-4.0.19-24508-1469987608-249.4628-6-0@openssl.org>
 <CAF8qwaAy4sqqRVA2aq=E=X3tMPguqmAmy_KpQm0TThEDfoBeUw@mail.gmail.com>
 <rt-4.0.19-12912-1469992652-1205.4628-6-0@openssl.org>
Message-ID: <000701d1eb79$676d46c0$3647d440$@sales@free.fr>

> I was able to trigger a crash simply by chaining an encrypt BIO with a
memory BIO containing a large plaintext and then stream 100 bytes out of it
at a time. BIO_read would consistently return 128 and, by the time the
function returned, the stack was thoroughly clobbered.

I am surprised. I should have been [un-?]lucky for once.
FWIW, here is what I did :
I have some files containing about 10000 of variable length lines (range is
from about 60 to 260 bytes).
File size is about 900 Kb to 1.5 Mb.
Files can be cleartext or encrypted (in this case they can be optionaly
base64 encoded).
So I have a software that chain as follow : 
File bio -> 
Base64 bio (opt) ->
Cipher bio (opt) ->
Memory bio.

For my test I read and wrote each case using 2 different ciphers : aes-128
and camelia-192.
Everything looks good : no crash, no data lost or damaged, no memory leak
and no stack overwritten.

I certainly misunderstand something, but I will be happy to test again my
use case if it can be of any help.

Regards,

Michel.


From rt at openssl.org  Sun Jul 31 22:18:10 2016
From: rt at openssl.org (Michel via RT)
Date: Sun, 31 Jul 2016 22:18:10 +0000
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due
	to overlapping regions check
In-Reply-To: <000701d1eb79$676d46c0$3647d440$@sales@free.fr>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
 <rt-4.0.19-24508-1469987608-249.4628-6-0@openssl.org>
 <CAF8qwaAy4sqqRVA2aq=E=X3tMPguqmAmy_KpQm0TThEDfoBeUw@mail.gmail.com>
 <rt-4.0.19-12912-1469992652-1205.4628-6-0@openssl.org>
 <000701d1eb79$676d46c0$3647d440$@sales@free.fr>
Message-ID: <rt-4.0.19-24508-1470003490-1634.4628-6-0@openssl.org>

> I was able to trigger a crash simply by chaining an encrypt BIO with a
memory BIO containing a large plaintext and then stream 100 bytes out of it
at a time. BIO_read would consistently return 128 and, by the time the
function returned, the stack was thoroughly clobbered.

I am surprised. I should have been [un-?]lucky for once.
FWIW, here is what I did :
I have some files containing about 10000 of variable length lines (range is
from about 60 to 260 bytes).
File size is about 900 Kb to 1.5 Mb.
Files can be cleartext or encrypted (in this case they can be optionaly
base64 encoded).
So I have a software that chain as follow : 
File bio -> 
Base64 bio (opt) ->
Cipher bio (opt) ->
Memory bio.

For my test I read and wrote each case using 2 different ciphers : aes-128
and camelia-192.
Everything looks good : no crash, no data lost or damaged, no memory leak
and no stack overwritten.

I certainly misunderstand something, but I will be happy to test again my
use case if it can be of any help.

Regards,

Michel.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun Jul 31 23:49:17 2016
From: rt at openssl.org (David Benjamin via RT)
Date: Sun, 31 Jul 2016 23:49:17 +0000
Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due
	to overlapping regions check
In-Reply-To: <CAF8qwaBAVhkK36CmHY_UgH4gVMAKG8bvAehYMht6fhe104hs4Q@mail.gmail.com>
References: <RT-Ticket-4628@openssl.org> <57963956.2060809@mit.edu>
 <rt-4.0.19-24508-1469987608-249.4628-6-0@openssl.org>
 <CAF8qwaAy4sqqRVA2aq=E=X3tMPguqmAmy_KpQm0TThEDfoBeUw@mail.gmail.com>
 <rt-4.0.19-12912-1469992652-1205.4628-6-0@openssl.org>
 <rt-4.0.19-24508-1470003490-1634.4628-6-0@openssl.org>
 <CAF8qwaBAVhkK36CmHY_UgH4gVMAKG8bvAehYMht6fhe104hs4Q@mail.gmail.com>
Message-ID: <rt-4.0.19-12912-1470008957-1544.4628-6-0@openssl.org>

On Sun, Jul 31, 2016 at 6:18 PM Michel via RT <rt at openssl.org> wrote:

> > I was able to trigger a crash simply by chaining an encrypt BIO with a
> memory BIO containing a large plaintext and then stream 100 bytes out of it
> at a time. BIO_read would consistently return 128 and, by the time the
> function returned, the stack was thoroughly clobbered.
>
> I am surprised. I should have been [un-?]lucky for once.
> FWIW, here is what I did :
> I have some files containing about 10000 of variable length lines (range is
> from about 60 to 260 bytes).
> File size is about 900 Kb to 1.5 Mb.
> Files can be cleartext or encrypted (in this case they can be optionaly
> base64 encoded).
> So I have a software that chain as follow :
> File bio ->
> Base64 bio (opt) ->
> Cipher bio (opt) ->
> Memory bio.
>
> For my test I read and wrote each case using 2 different ciphers : aes-128
> and camelia-192.
> Everything looks good : no crash, no data lost or damaged, no memory leak
> and no stack overwritten.
>
> I certainly misunderstand something, but I will be happy to test again my
> use case if it can be of any help.
>

(I'm not entirely sure which direction the arrows are meant to be going.)

You need the read to not be a multiple of 16 to trigger the issue. (Well,
that's the simplest trigger. I also got decrypt BIOs to trigger with
outl=128 because EVP_DecryptUpdate always holds back the final block.) Also
if your code will secretly tolerate the cipher BIO returning more data than
outl, you won't notice. But the API contract of BIO_read is that it will
not return more than outl bytes of data.

Reads of size 100 into a buffer of size 100 will do the trick:

outl = 100 =>
buf_len = 128 =>
i = 128 (assuming we got a full read) =>
we ask EVP_CipherUpdate to decrypt 128 bytes =>
128 bytes of output into out =>
buffer overflow

David

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted