Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-02-13 Thread Willy Tarreau
On Mon, Feb 13, 2017 at 10:22:35AM +0100, Willy Tarreau wrote:
> On Fri, Feb 10, 2017 at 01:57:58AM +0800, Igor Pav wrote:
> > Thank you, did the trick. Config haproxy backend server to use SSL
> > like "server s1 s1.local:1000 ssl" will cause segment fault.
> > 
> > boringssl/crypto/digest/digest.c:98: EVP_MD_CTX_cleanup: Assertion
> > `ctx->pctx == ((void *)0) || ctx->pctx_ops != ((void *)0)' failed.
> > Aborted
> 
> I think it's the same issue as reported in the other thread about 1.0.1e
> failing on centos and apparently caused by a wrong fix. We'll issue 1.7.3
> soon with this fixed.

I was wrong, it was never backported to 1.7.

Willy



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-02-13 Thread Willy Tarreau
On Fri, Feb 10, 2017 at 01:57:58AM +0800, Igor Pav wrote:
> Thank you, did the trick. Config haproxy backend server to use SSL
> like "server s1 s1.local:1000 ssl" will cause segment fault.
> 
> boringssl/crypto/digest/digest.c:98: EVP_MD_CTX_cleanup: Assertion
> `ctx->pctx == ((void *)0) || ctx->pctx_ops != ((void *)0)' failed.
> Aborted

I think it's the same issue as reported in the other thread about 1.0.1e
failing on centos and apparently caused by a wrong fix. We'll issue 1.7.3
soon with this fixed.

Willy



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-02-09 Thread Igor Pav
Thank you, did the trick. Config haproxy backend server to use SSL
like "server s1 s1.local:1000 ssl" will cause segment fault.

boringssl/crypto/digest/digest.c:98: EVP_MD_CTX_cleanup: Assertion
`ctx->pctx == ((void *)0) || ctx->pctx_ops != ((void *)0)' failed.
Aborted

On Tue, Feb 7, 2017 at 11:17 PM, Emmanuel Hocdet  wrote:
> you need:
> ADDLIB="-lpthread -ldecrepit"
>
> Le 7 févr. 2017 à 16:09, Igor Pav  a écrit :
>
> Hi, Emmanuel. build with static lib, but no luck, can you provide some
> building details? Thanks.
>
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_init':
> /root/boringssl/crypto/thread_pthread.c:31: undefined reference to
> `pthread_rwlock_init'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_lock_read':
> /root/boringssl/crypto/thread_pthread.c:37: undefined reference to
> `pthread_rwlock_rdlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_lock_write':
> /root/boringssl/crypto/thread_pthread.c:43: undefined reference to
> `pthread_rwlock_wrlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_unlock_read':
> /root/boringssl/crypto/thread_pthread.c:49: undefined reference to
> `pthread_rwlock_unlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_unlock_write':
> /root/boringssl/crypto/thread_pthread.c:55: undefined reference to
> `pthread_rwlock_unlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_cleanup':
> /root/boringssl/crypto/thread_pthread.c:61: undefined reference to
> `pthread_rwlock_destroy'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_STATIC_MUTEX_lock_read':
> /root/boringssl/crypto/thread_pthread.c:65: undefined reference to
> `pthread_rwlock_rdlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_STATIC_MUTEX_lock_write':
> /root/boringssl/crypto/thread_pthread.c:71: undefined reference to
> `pthread_rwlock_wrlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_STATIC_MUTEX_unlock_read':
> /root/boringssl/crypto/thread_pthread.c:77: undefined reference to
> `pthread_rwlock_unlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_STATIC_MUTEX_unlock_write':
> /root/boringssl/crypto/thread_pthread.c:83: undefined reference to
> `pthread_rwlock_unlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function `CRYPTO_once':
> /root/boringssl/crypto/thread_pthread.c:89: undefined reference to
> `pthread_once'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `thread_local_init':
> /root/boringssl/crypto/thread_pthread.c:126: undefined reference to
> `pthread_key_create'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_get_thread_local':
> /root/boringssl/crypto/thread_pthread.c:135: undefined reference to
> `pthread_getspecific'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_set_thread_local':
> /root/boringssl/crypto/thread_pthread.c:150: undefined reference to
> `pthread_getspecific'
> /root/boringssl/crypto/thread_pthread.c:158: undefined reference to
> `pthread_setspecific'
> collect2: error: ld returned 1 exit status
> make: *** [haproxy] Error 1
>
> On Tue, Feb 7, 2017 at 9:12 PM, Emmanuel Hocdet  wrote:
>
> I Igor,
> I build haproxy with boringssl static library to avoid any conflict with
> openssl shared lib.
> It also need to be link with libdecrepit (boringssl).
>
> Le 30 janv. 2017 à 14:28, Igor Pav  a écrit :
>
> sorry for unclear question, it's quite simple, build haproxy from git
> with boringssl (DBUILD_SHARED_LIBS=1), just config a simple SSL
> frontend.
>
> On Mon, Jan 30, 2017 at 5:42 PM, Willy Tarreau  wrote:
>
> On Mon, Jan 30, 2017 at 04:07:33PM +0800, Igor Pav wrote:
>
> any idea with error?
>
> undefined symbol: BIO_read_filename
>
>
> I doubt you'll get any useful response if you don't provide at least a
> bit of information, such as what ssl lib you're using, whether or not
> this is with the patch applied, build options maybe, etc...
>
> Willy
>
>
>
>
>



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-02-07 Thread Emmanuel Hocdet
you need:
ADDLIB="-lpthread -ldecrepit"

> Le 7 févr. 2017 à 16:09, Igor Pav  a écrit :
> 
> Hi, Emmanuel. build with static lib, but no luck, can you provide some
> building details? Thanks.
> 
> /build/slib/libcrypto.a(thread_pthread.c.o): In function `CRYPTO_MUTEX_init':
> /root/boringssl/crypto/thread_pthread.c:31: undefined reference to
> `pthread_rwlock_init'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_lock_read':
> /root/boringssl/crypto/thread_pthread.c:37: undefined reference to
> `pthread_rwlock_rdlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_lock_write':
> /root/boringssl/crypto/thread_pthread.c:43: undefined reference to
> `pthread_rwlock_wrlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_unlock_read':
> /root/boringssl/crypto/thread_pthread.c:49: undefined reference to
> `pthread_rwlock_unlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_MUTEX_unlock_write':
> /root/boringssl/crypto/thread_pthread.c:55: undefined reference to
> `pthread_rwlock_unlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function 
> `CRYPTO_MUTEX_cleanup':
> /root/boringssl/crypto/thread_pthread.c:61: undefined reference to
> `pthread_rwlock_destroy'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_STATIC_MUTEX_lock_read':
> /root/boringssl/crypto/thread_pthread.c:65: undefined reference to
> `pthread_rwlock_rdlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_STATIC_MUTEX_lock_write':
> /root/boringssl/crypto/thread_pthread.c:71: undefined reference to
> `pthread_rwlock_wrlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_STATIC_MUTEX_unlock_read':
> /root/boringssl/crypto/thread_pthread.c:77: undefined reference to
> `pthread_rwlock_unlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_STATIC_MUTEX_unlock_write':
> /root/boringssl/crypto/thread_pthread.c:83: undefined reference to
> `pthread_rwlock_unlock'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function `CRYPTO_once':
> /root/boringssl/crypto/thread_pthread.c:89: undefined reference to
> `pthread_once'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function `thread_local_init':
> /root/boringssl/crypto/thread_pthread.c:126: undefined reference to
> `pthread_key_create'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_get_thread_local':
> /root/boringssl/crypto/thread_pthread.c:135: undefined reference to
> `pthread_getspecific'
> /build/slib/libcrypto.a(thread_pthread.c.o): In function
> `CRYPTO_set_thread_local':
> /root/boringssl/crypto/thread_pthread.c:150: undefined reference to
> `pthread_getspecific'
> /root/boringssl/crypto/thread_pthread.c:158: undefined reference to
> `pthread_setspecific'
> collect2: error: ld returned 1 exit status
> make: *** [haproxy] Error 1
> 
> On Tue, Feb 7, 2017 at 9:12 PM, Emmanuel Hocdet  wrote:
>> I Igor,
>> I build haproxy with boringssl static library to avoid any conflict with 
>> openssl shared lib.
>> It also need to be link with libdecrepit (boringssl).
>> 
>>> Le 30 janv. 2017 à 14:28, Igor Pav  a écrit :
>>> 
>>> sorry for unclear question, it's quite simple, build haproxy from git
>>> with boringssl (DBUILD_SHARED_LIBS=1), just config a simple SSL
>>> frontend.
>>> 
>>> On Mon, Jan 30, 2017 at 5:42 PM, Willy Tarreau  wrote:
 On Mon, Jan 30, 2017 at 04:07:33PM +0800, Igor Pav wrote:
> any idea with error?
> 
> undefined symbol: BIO_read_filename
 
 I doubt you'll get any useful response if you don't provide at least a
 bit of information, such as what ssl lib you're using, whether or not
 this is with the patch applied, build options maybe, etc...
 
 Willy
>>> 
>> 
> 



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-02-07 Thread Igor Pav
Hi, Emmanuel. build with static lib, but no luck, can you provide some
building details? Thanks.

/build/slib/libcrypto.a(thread_pthread.c.o): In function `CRYPTO_MUTEX_init':
/root/boringssl/crypto/thread_pthread.c:31: undefined reference to
`pthread_rwlock_init'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_MUTEX_lock_read':
/root/boringssl/crypto/thread_pthread.c:37: undefined reference to
`pthread_rwlock_rdlock'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_MUTEX_lock_write':
/root/boringssl/crypto/thread_pthread.c:43: undefined reference to
`pthread_rwlock_wrlock'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_MUTEX_unlock_read':
/root/boringssl/crypto/thread_pthread.c:49: undefined reference to
`pthread_rwlock_unlock'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_MUTEX_unlock_write':
/root/boringssl/crypto/thread_pthread.c:55: undefined reference to
`pthread_rwlock_unlock'
/build/slib/libcrypto.a(thread_pthread.c.o): In function `CRYPTO_MUTEX_cleanup':
/root/boringssl/crypto/thread_pthread.c:61: undefined reference to
`pthread_rwlock_destroy'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_STATIC_MUTEX_lock_read':
/root/boringssl/crypto/thread_pthread.c:65: undefined reference to
`pthread_rwlock_rdlock'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_STATIC_MUTEX_lock_write':
/root/boringssl/crypto/thread_pthread.c:71: undefined reference to
`pthread_rwlock_wrlock'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_STATIC_MUTEX_unlock_read':
/root/boringssl/crypto/thread_pthread.c:77: undefined reference to
`pthread_rwlock_unlock'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_STATIC_MUTEX_unlock_write':
/root/boringssl/crypto/thread_pthread.c:83: undefined reference to
`pthread_rwlock_unlock'
/build/slib/libcrypto.a(thread_pthread.c.o): In function `CRYPTO_once':
/root/boringssl/crypto/thread_pthread.c:89: undefined reference to
`pthread_once'
/build/slib/libcrypto.a(thread_pthread.c.o): In function `thread_local_init':
/root/boringssl/crypto/thread_pthread.c:126: undefined reference to
`pthread_key_create'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_get_thread_local':
/root/boringssl/crypto/thread_pthread.c:135: undefined reference to
`pthread_getspecific'
/build/slib/libcrypto.a(thread_pthread.c.o): In function
`CRYPTO_set_thread_local':
/root/boringssl/crypto/thread_pthread.c:150: undefined reference to
`pthread_getspecific'
/root/boringssl/crypto/thread_pthread.c:158: undefined reference to
`pthread_setspecific'
collect2: error: ld returned 1 exit status
make: *** [haproxy] Error 1

On Tue, Feb 7, 2017 at 9:12 PM, Emmanuel Hocdet  wrote:
> I Igor,
> I build haproxy with boringssl static library to avoid any conflict with 
> openssl shared lib.
> It also need to be link with libdecrepit (boringssl).
>
>> Le 30 janv. 2017 à 14:28, Igor Pav  a écrit :
>>
>> sorry for unclear question, it's quite simple, build haproxy from git
>> with boringssl (DBUILD_SHARED_LIBS=1), just config a simple SSL
>> frontend.
>>
>> On Mon, Jan 30, 2017 at 5:42 PM, Willy Tarreau  wrote:
>>> On Mon, Jan 30, 2017 at 04:07:33PM +0800, Igor Pav wrote:
 any idea with error?

 undefined symbol: BIO_read_filename
>>>
>>> I doubt you'll get any useful response if you don't provide at least a
>>> bit of information, such as what ssl lib you're using, whether or not
>>> this is with the patch applied, build options maybe, etc...
>>>
>>> Willy
>>
>



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-02-07 Thread Emmanuel Hocdet
I Igor,
I build haproxy with boringssl static library to avoid any conflict with 
openssl shared lib.
It also need to be link with libdecrepit (boringssl).

> Le 30 janv. 2017 à 14:28, Igor Pav  a écrit :
> 
> sorry for unclear question, it's quite simple, build haproxy from git
> with boringssl (DBUILD_SHARED_LIBS=1), just config a simple SSL
> frontend.
> 
> On Mon, Jan 30, 2017 at 5:42 PM, Willy Tarreau  wrote:
>> On Mon, Jan 30, 2017 at 04:07:33PM +0800, Igor Pav wrote:
>>> any idea with error?
>>> 
>>> undefined symbol: BIO_read_filename
>> 
>> I doubt you'll get any useful response if you don't provide at least a
>> bit of information, such as what ssl lib you're using, whether or not
>> this is with the patch applied, build options maybe, etc...
>> 
>> Willy
> 




Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-30 Thread Igor Pav
sorry for unclear question, it's quite simple, build haproxy from git
with boringssl (DBUILD_SHARED_LIBS=1), just config a simple SSL
frontend.

On Mon, Jan 30, 2017 at 5:42 PM, Willy Tarreau  wrote:
> On Mon, Jan 30, 2017 at 04:07:33PM +0800, Igor Pav wrote:
>> any idea with error?
>>
>>  undefined symbol: BIO_read_filename
>
> I doubt you'll get any useful response if you don't provide at least a
> bit of information, such as what ssl lib you're using, whether or not
> this is with the patch applied, build options maybe, etc...
>
> Willy



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-30 Thread Willy Tarreau
On Mon, Jan 30, 2017 at 04:07:33PM +0800, Igor Pav wrote:
> any idea with error?
> 
>  undefined symbol: BIO_read_filename

I doubt you'll get any useful response if you don't provide at least a
bit of information, such as what ssl lib you're using, whether or not
this is with the patch applied, build options maybe, etc...

Willy



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-30 Thread Igor Pav
any idea with error?

 undefined symbol: BIO_read_filename

On Mon, Jan 16, 2017 at 7:42 PM, Willy Tarreau  wrote:
> On Fri, Jan 13, 2017 at 06:11:55PM +0100, Emmanuel Hocdet wrote:
>> for 1.8dev
>
> now applied, thanks.
>
> Willy
>



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-16 Thread Willy Tarreau
On Fri, Jan 13, 2017 at 06:11:55PM +0100, Emmanuel Hocdet wrote:
> for 1.8dev

now applied, thanks.

Willy



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-16 Thread Emmanuel Hocdet
Hi Willy,

I look another change. A fix (or not?) can be out of this patch.


@@ -3851,39 +3861,41 @@ int ssl_sock_handshake(struct connection *conn, 
unsigned int flag)
return 0;
}
else if (ret == SSL_ERROR_SYSCALL) {
-#if (OPENSSL_VERSION_NUMBER >= 0x101fL) && 
!defined(LIBRESSL_VERSION_NUMBER)
-   OSSL_HANDSHAKE_STATE state;
-#endif
-   int empty_handshake;
/* if errno is null, then connection was successfully 
established */
if (!errno && conn->flags & CO_FL_WAIT_L4_CONN)
conn->flags &= ~CO_FL_WAIT_L4_CONN;
-
+   if (!conn->err_code) {<=== her 
+#ifdef OPENSSL_NO_HEARTBEATS  /* BoringSSL */
+   conn->err_code = CO_ER_SSL_HANDSHAKE;
+#else
+   int empty_handshake;

is a copy past from:

@@ -3780,6 +3787,9 @@ int ssl_sock_handshake(struct connection *conn, unsigned 
int flag)
if (!errno && conn->flags & CO_FL_WAIT_L4_CONN)
conn->flags &= ~CO_FL_WAIT_L4_CONN;
if (!conn->err_code) {
+#ifdef OPENSSL_NO_HEARTBEATS  /* BoringSSL */
+   conn->err_code = CO_ER_SSL_HANDSHAKE;
+#else
int empty_handshake;


Manu



Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-16 Thread Willy Tarreau
On Mon, Jan 16, 2017 at 12:17:39PM +0100, Emmanuel Hocdet wrote:
> > I think this one is wrong :
> > 
> > @@ -6769,13 +6779,12 @@ static struct cli_kw_list cli_kws = {{ },{
> > #if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
> > { { "show", "tls-keys", NULL }, "show tls-keys [id|*]: show tls keys 
> > references or dump tls ticket keys when id specified", 
> > cli_parse_show_tlskeys, NULL },
> > { { "set", "ssl", "tls-keys", NULL }, NULL, cli_parse_set_tlskeys, NULL 
> > },
> > -   { { "set", "ssl", "ocsp-response", NULL }, NULL, 
> > cli_parse_set_ocspresponse, NULL },
> > #endif
> > +   { { "set", "ssl", "ocsp-response", NULL }, NULL, 
> > cli_parse_set_ocspresponse, NULL },
> > { { NULL }, NULL, NULL, NULL }
> > }};
> > 
> > The conditions didn't change in cli_parse_set_ocspresponse(). OK it should
> > probably not depend on TLS_TICKETS_NO but this should be addressed as part
> > of a build fix that's independant on boringssl.
> > 
> 
> cli_parse_set_ocspresponse have #ifdef in the fonction and display error 
> message if not available.
> It should always declare in kw_list to avoid warning at compile time (not 
> used).

OK I see, thanks for the explanation.

> It break only some primary test to build with borring, and yes could be out 
> this fix.
> 
> > By the way, regarding the #ifdef cleanup, I think we can consider all this :
> >  - SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB is always set, at least since 0.9.8
> >so we should remove these ifdefs
> > 
> >  - TLS_TICKETS_NO is always set, though not necessarily > 0. I think we
> >should remove all the #ifdefs around and assume it's always > 0. The
> >compiler will catch the rare occurrences where it's forced to zero
> >(or we can even #error on this one).
> > 
> > That would remove quite some #ifdef. And possibly there are other conditions
> > that can be considered as granted since 0.9.8 which we can remove.
> > 
> > What do you think ?
> > 
> 
> I think drop all out-dated openssl support will be a very good thing.
> out-dated is about security: who want only obsolete cipher support than 
> disappear 
> from internet? sslv3 is drop, current mouvement is to drop support < tls 1.2.

Keep in mind that "the internet" is very different from "internal networks".
Most often people just want something which works internally and are even
fine with the cheaper sslv3 and rsa1024 algos between the LB and the servers.

> Yes, we can remove 0.9.8 support in 1.8dev :)

That's not what I was saying, I said "prior to 0.9.8". Once we do this
cleanup, I guess most of the #ifdefs will be gone. I don't think there
are still many there only for 0.9.8. I'd rather keep it supported if
it requires a low effort, because some LTS distros still have it (eg:
SLES11 is supported till Mar 2019 for general use). We certainly want
users to upgrade their openssl, but we also want them to upgrade their
haproxy so better not force them to stay on an old version just because
of openssl. And building openssl oneself is even worse for security
because nobody thinks about updating it when there's a vulnerability.

Cheers,
Willy




Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-16 Thread Emmanuel Hocdet
Hi Willy,

> Le 16 janv. 2017 à 11:08, Willy Tarreau <w...@1wt.eu> a écrit :
> 
> Hi Manu,
> 
> From: Emmanuel Hocdet <m...@gandi.net>
> Date: Fri, 13 Jan 2017 17:48:18 +0100
> Subject: [PATCH] BUILD: ssl: fix to build (again) with boringssl
> 
> Limitations:
> . disable force-ssl/tls (need more work)
> should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed)
> . disable generate-certificates (need more work)
> introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates.
> 
> Cleanup some #ifdef and type related to boringssl env.
> 
> I think this one is wrong :
> 
> @@ -6769,13 +6779,12 @@ static struct cli_kw_list cli_kws = {{ },{
> #if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
>   { { "show", "tls-keys", NULL }, "show tls-keys [id|*]: show tls keys 
> references or dump tls ticket keys when id specified", 
> cli_parse_show_tlskeys, NULL },
>   { { "set", "ssl", "tls-keys", NULL }, NULL, cli_parse_set_tlskeys, NULL 
> },
> - { { "set", "ssl", "ocsp-response", NULL }, NULL, 
> cli_parse_set_ocspresponse, NULL },
> #endif
> + { { "set", "ssl", "ocsp-response", NULL }, NULL, 
> cli_parse_set_ocspresponse, NULL },
>   { { NULL }, NULL, NULL, NULL }
> }};
> 
> The conditions didn't change in cli_parse_set_ocspresponse(). OK it should
> probably not depend on TLS_TICKETS_NO but this should be addressed as part
> of a build fix that's independant on boringssl.
> 

cli_parse_set_ocspresponse have #ifdef in the fonction and display error 
message if not available.
It should always declare in kw_list to avoid warning at compile time (not used).

It break only some primary test to build with borring, and yes could be out 
this fix.

> By the way, regarding the #ifdef cleanup, I think we can consider all this :
>  - SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB is always set, at least since 0.9.8
>so we should remove these ifdefs
> 
>  - TLS_TICKETS_NO is always set, though not necessarily > 0. I think we
>should remove all the #ifdefs around and assume it's always > 0. The
>compiler will catch the rare occurrences where it's forced to zero
>(or we can even #error on this one).
> 
> That would remove quite some #ifdef. And possibly there are other conditions
> that can be considered as granted since 0.9.8 which we can remove.
> 
> What do you think ?
> 

I think drop all out-dated openssl support will be a very good thing.
out-dated is about security: who want only obsolete cipher support than 
disappear 
from internet? sslv3 is drop, current mouvement is to drop support < tls 1.2.
Yes, we can remove 0.9.8 support in 1.8dev :)

Manu






Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-16 Thread Willy Tarreau
Hi Manu,

From: Emmanuel Hocdet <m...@gandi.net>
Date: Fri, 13 Jan 2017 17:48:18 +0100
Subject: [PATCH] BUILD: ssl: fix to build (again) with boringssl

Limitations:
. disable force-ssl/tls (need more work)
should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed)
. disable generate-certificates (need more work)
introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates.

Cleanup some #ifdef and type related to boringssl env.

I think this one is wrong :

@@ -6769,13 +6779,12 @@ static struct cli_kw_list cli_kws = {{ },{
 #if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
{ { "show", "tls-keys", NULL }, "show tls-keys [id|*]: show tls keys 
references or dump tls ticket keys when id specified", cli_parse_show_tlskeys, 
NULL },
{ { "set", "ssl", "tls-keys", NULL }, NULL, cli_parse_set_tlskeys, NULL 
},
-   { { "set", "ssl", "ocsp-response", NULL }, NULL, 
cli_parse_set_ocspresponse, NULL },
 #endif
+   { { "set", "ssl", "ocsp-response", NULL }, NULL, 
cli_parse_set_ocspresponse, NULL },
{ { NULL }, NULL, NULL, NULL }
 }};
 
The conditions didn't change in cli_parse_set_ocspresponse(). OK it should
probably not depend on TLS_TICKETS_NO but this should be addressed as part
of a build fix that's independant on boringssl.
 
By the way, regarding the #ifdef cleanup, I think we can consider all this :
  - SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB is always set, at least since 0.9.8
so we should remove these ifdefs

  - TLS_TICKETS_NO is always set, though not necessarily > 0. I think we
should remove all the #ifdefs around and assume it's always > 0. The
compiler will catch the rare occurrences where it's forced to zero
(or we can even #error on this one).

That would remove quite some #ifdef. And possibly there are other conditions
that can be considered as granted since 0.9.8 which we can remove.

What do you think ?

Thanks,
Willy



[PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-13 Thread Emmanuel Hocdet
for 1.8dev



0001-BUILD-ssl-fix-to-build-again-with-boringssl.patch
Description: Binary data





Re: [PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-06 Thread Emmanuel Hocdet
This patch is a WIP and should not be full functional.
Don’t merge to haproxy Willy :)

> Le 6 janv. 2017 à 18:18, Emmanuel Hocdet  a écrit :
> 
> Hi Igor,
> 
> The patch is for 1.8dev.
> 
> <0001-BUILD-ssl-fix-to-build-again-with-boringssl.patch>
> 
> 
>> Le 3 janv. 2017 à 17:19, Igor Pav  a écrit :
>> 
>> tried compile 1.7.1 with boringssl, but seems not work, error like below:
>> 
>> In file included from src/ssl_sock.c:87:0:
>> include/proto/openssl-compat.h:107:1: error: unknown type name ‘OCSP_CERTID’
>> static inline const OCSP_CERTID *OCSP_SINGLERESP_get0_id(const
>> OCSP_SINGLERESP *single)
>> ^
>> include/proto/openssl-compat.h:107:1: error: unknown type name 
>> ‘OCSP_SINGLERESP’
>> include/proto/openssl-compat.h: In function ‘OCSP_SINGLERESP_get0_id’:
>> include/proto/openssl-compat.h:109:15: error: request for member
>> ‘certId’ in something not a structure or union
>> return single->certId;
>>  ^
>> src/ssl_sock.c: In function ‘ssl_sock_bind_verifycbk’:
>> src/ssl_sock.c:1070:4: warning: implicit declaration of function
>> ‘ssl_sock_dump_errors’ [-Wimplicit-function-declaration]
>>   ssl_sock_dump_errors(conn);
>>   ^
>> src/ssl_sock.c: In function ‘ssl_sock_do_create_cert’:
>> src/ssl_sock.c:1241:3: warning: implicit declaration of function
>> ‘X509V3_EXT_conf’ [-Wimplicit-function-declaration]
>>  if (!(ext = X509V3_EXT_conf(NULL, , x509v3_ext_names[i],
>> x509v3_ext_values[i])))
>>  ^
>> src/ssl_sock.c:1241:13: warning: assignment makes pointer from integer
>> without a cast [enabled by default]
>>  if (!(ext = X509V3_EXT_conf(NULL, , x509v3_ext_names[i],
>> x509v3_ext_values[i])))
>>^
>> src/ssl_sock.c:1252:2: warning: implicit declaration of function
>> ‘EVP_PKEY_base_id’ [-Wimplicit-function-declaration]
>> key_type = EVP_PKEY_base_id(capkey);
>> ^
>> src/ssl_sock.c:1264:3: warning: implicit declaration of function
>> ‘EVP_PKEY_get_default_digest_nid’ [-Wimplicit-function-declaration]
>>  if (EVP_PKEY_get_default_digest_nid(capkey, ) <= 0)
>>  ^
>> src/ssl_sock.c: In function ‘ssl_sock_prepare_ctx’:
>> src/ssl_sock.c:2720:3: warning: implicit declaration of function
>> ‘SSL_CTX_set_ssl_version’ [-Wimplicit-function-declaration]
>>  SSL_CTX_set_ssl_version(ctx, SSLv3_server_method());
>>  ^
>> src/ssl_sock.c:2786:46: error: ‘ssl_tlsext_ticket_key_cb’ undeclared
>> (first use in this function)
>>  if (!SSL_CTX_set_tlsext_ticket_key_cb(ctx, ssl_tlsext_ticket_key_cb)) {
>> ^
>> src/ssl_sock.c:2786:46: note: each undeclared identifier is reported
>> only once for each function it appears in
>> src/ssl_sock.c:2820:13: warning: assignment discards ‘const’ qualifier
>> from pointer target type [enabled by default]
>> cipher = sk_SSL_CIPHER_value(ciphers, idx);
>>^
>> src/ssl_sock.c:2874:2: warning: passing argument 2 of
>> ‘SSL_CTX_set_tlsext_servername_callback’ from incompatible pointer
>> type [enabled by default]
>> SSL_CTX_set_tlsext_servername_callback(ctx, ssl_sock_switchctx_cbk);
>> ^
>> In file included from src/ssl_sock.c:43:0:
>> /build/boringssl/include/openssl/ssl.h:2357:20: note: expected ‘int
>> (*)(struct SSL *, int *, void *)’ but argument is of type ‘int
>> (*)(struct SSL *, int *, struct bind_conf *)’
>> OPENSSL_EXPORT int SSL_CTX_set_tlsext_servername_callback(
>>   ^
>> src/ssl_sock.c: In function ‘ssl_sock_handshake’:
>> src/ssl_sock.c:3531:48: error: ‘SSL’ has no member named ‘packet_length’
>> empty_handshake = !((SSL *)conn->xprt_ctx)->packet_length;
>>   ^
>> src/ssl_sock.c:3609:46: error: ‘SSL’ has no member named ‘packet_length’
>>   empty_handshake = !((SSL *)conn->xprt_ctx)->packet_length;
>> ^
>> make: *** [src/ssl_sock.o] Error 1
>> 
>> On Mon, Aug 18, 2014 at 6:56 AM, Lukas Tribus  wrote:
>>> Google's boringssl doesn't currently support OCSP, so
>>> disable it if detected.
>>> 
>>> OCSP support may be reintroduced as per:
>>> https://code.google.com/p/chromium/issues/detail?id=398677
>>> 
>>> In that case we can simply revert this commit.
>>> 
>>> Signed-off-by: Lukas Tribus 
>>> ---
>>> include/proto/ssl_sock.h | 2 +-
>>> src/dumpstats.c  | 2 +-
>>> src/ssl_sock.c   | 6 +++---
>>> 3 files changed, 5 insertions(+), 5 deletions(-)
>>> 
>>> diff --git a/include/proto/ssl_sock.h b/include/proto/ssl_sock.h
>>> index 3e111cd..6362953 100644
>>> --- a/include/proto/ssl_sock.h
>>> +++ b/include/proto/ssl_sock.h
>>> @@ -54,7 +54,7 @@ char *ssl_sock_get_version(struct connection *conn);
>>> int ssl_sock_get_cert_used(struct connection *conn);
>>> int ssl_sock_get_remote_common_name(struct connection *conn, struct chunk 
>>> *out);
>>> unsigned int ssl_sock_get_verify_result(struct connection *conn);
>>> -#ifdef SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB
>>> +#if (defined 

PATCH] BUILD: ssl: fix to build (again) with boringssl

2017-01-06 Thread Emmanuel Hocdet
Hi Igor,

The patch is for 1.8dev.



0001-BUILD-ssl-fix-to-build-again-with-boringssl.patch
Description: Binary data



> Le 3 janv. 2017 à 17:19, Igor Pav  a écrit :
> 
> tried compile 1.7.1 with boringssl, but seems not work, error like below:
> 
> In file included from src/ssl_sock.c:87:0:
> include/proto/openssl-compat.h:107:1: error: unknown type name ‘OCSP_CERTID’
> static inline const OCSP_CERTID *OCSP_SINGLERESP_get0_id(const
> OCSP_SINGLERESP *single)
> ^
> include/proto/openssl-compat.h:107:1: error: unknown type name 
> ‘OCSP_SINGLERESP’
> include/proto/openssl-compat.h: In function ‘OCSP_SINGLERESP_get0_id’:
> include/proto/openssl-compat.h:109:15: error: request for member
> ‘certId’ in something not a structure or union
>  return single->certId;
>   ^
> src/ssl_sock.c: In function ‘ssl_sock_bind_verifycbk’:
> src/ssl_sock.c:1070:4: warning: implicit declaration of function
> ‘ssl_sock_dump_errors’ [-Wimplicit-function-declaration]
>ssl_sock_dump_errors(conn);
>^
> src/ssl_sock.c: In function ‘ssl_sock_do_create_cert’:
> src/ssl_sock.c:1241:3: warning: implicit declaration of function
> ‘X509V3_EXT_conf’ [-Wimplicit-function-declaration]
>   if (!(ext = X509V3_EXT_conf(NULL, , x509v3_ext_names[i],
> x509v3_ext_values[i])))
>   ^
> src/ssl_sock.c:1241:13: warning: assignment makes pointer from integer
> without a cast [enabled by default]
>   if (!(ext = X509V3_EXT_conf(NULL, , x509v3_ext_names[i],
> x509v3_ext_values[i])))
> ^
> src/ssl_sock.c:1252:2: warning: implicit declaration of function
> ‘EVP_PKEY_base_id’ [-Wimplicit-function-declaration]
>  key_type = EVP_PKEY_base_id(capkey);
>  ^
> src/ssl_sock.c:1264:3: warning: implicit declaration of function
> ‘EVP_PKEY_get_default_digest_nid’ [-Wimplicit-function-declaration]
>   if (EVP_PKEY_get_default_digest_nid(capkey, ) <= 0)
>   ^
> src/ssl_sock.c: In function ‘ssl_sock_prepare_ctx’:
> src/ssl_sock.c:2720:3: warning: implicit declaration of function
> ‘SSL_CTX_set_ssl_version’ [-Wimplicit-function-declaration]
>   SSL_CTX_set_ssl_version(ctx, SSLv3_server_method());
>   ^
> src/ssl_sock.c:2786:46: error: ‘ssl_tlsext_ticket_key_cb’ undeclared
> (first use in this function)
>   if (!SSL_CTX_set_tlsext_ticket_key_cb(ctx, ssl_tlsext_ticket_key_cb)) {
>  ^
> src/ssl_sock.c:2786:46: note: each undeclared identifier is reported
> only once for each function it appears in
> src/ssl_sock.c:2820:13: warning: assignment discards ‘const’ qualifier
> from pointer target type [enabled by default]
>  cipher = sk_SSL_CIPHER_value(ciphers, idx);
> ^
> src/ssl_sock.c:2874:2: warning: passing argument 2 of
> ‘SSL_CTX_set_tlsext_servername_callback’ from incompatible pointer
> type [enabled by default]
>  SSL_CTX_set_tlsext_servername_callback(ctx, ssl_sock_switchctx_cbk);
>  ^
> In file included from src/ssl_sock.c:43:0:
> /build/boringssl/include/openssl/ssl.h:2357:20: note: expected ‘int
> (*)(struct SSL *, int *, void *)’ but argument is of type ‘int
> (*)(struct SSL *, int *, struct bind_conf *)’
> OPENSSL_EXPORT int SSL_CTX_set_tlsext_servername_callback(
>^
> src/ssl_sock.c: In function ‘ssl_sock_handshake’:
> src/ssl_sock.c:3531:48: error: ‘SSL’ has no member named ‘packet_length’
>  empty_handshake = !((SSL *)conn->xprt_ctx)->packet_length;
>^
> src/ssl_sock.c:3609:46: error: ‘SSL’ has no member named ‘packet_length’
>empty_handshake = !((SSL *)conn->xprt_ctx)->packet_length;
>  ^
> make: *** [src/ssl_sock.o] Error 1
> 
> On Mon, Aug 18, 2014 at 6:56 AM, Lukas Tribus  wrote:
>> Google's boringssl doesn't currently support OCSP, so
>> disable it if detected.
>> 
>> OCSP support may be reintroduced as per:
>> https://code.google.com/p/chromium/issues/detail?id=398677
>> 
>> In that case we can simply revert this commit.
>> 
>> Signed-off-by: Lukas Tribus 
>> ---
>> include/proto/ssl_sock.h | 2 +-
>> src/dumpstats.c  | 2 +-
>> src/ssl_sock.c   | 6 +++---
>> 3 files changed, 5 insertions(+), 5 deletions(-)
>> 
>> diff --git a/include/proto/ssl_sock.h b/include/proto/ssl_sock.h
>> index 3e111cd..6362953 100644
>> --- a/include/proto/ssl_sock.h
>> +++ b/include/proto/ssl_sock.h
>> @@ -54,7 +54,7 @@ char *ssl_sock_get_version(struct connection *conn);
>> int ssl_sock_get_cert_used(struct connection *conn);
>> int ssl_sock_get_remote_common_name(struct connection *conn, struct chunk 
>> *out);
>> unsigned int ssl_sock_get_verify_result(struct connection *conn);
>> -#ifdef SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB
>> +#if (defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined 
>> OPENSSL_IS_BORINGSSL)
>> int ssl_sock_update_ocsp_response(struct chunk *ocsp_response, char **err);
>> #endif
>> 
>> diff --git a/src/dumpstats.c b/src/dumpstats.c
>> index 5365042..3855e09 100644
>> ---