Re: haproxy 1.9.2 with boringssl
On Tue, Jan 22, 2019 at 12:13 PM Aleksandar Lazic wrote: > Sorry for my dump question, I just want to be save not to break something. > > It would be nice to have the option '-key-update' in client.cc and server.cc > where can I put this feature request for boringssl? > > That would be make the test easy with this command. > > `./tool/bssl s_client -key-update -connect $test-haproxy-instance ` bssl is just for human experimentation, it shouldn't be used in something like a test because we break the interface from time-to-time. (Also note that BoringSSL in general "is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it." https://boringssl.googlesource.com/boringssl) You may well be better off using OpenSSL for a test like that, or perhaps writing a C/C++ program (which will probably work for either OpenSSL or BoringSSL). Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
Re: haproxy 1.9.2 with boringssl
On Tue, Jan 22, 2019 at 11:45 AM Aleksandar Lazic wrote: > Can it be reused to test a specific server like? > > ssl/test/runner/runner -test "KeyUpdate-ToServer" 127.0.0.1:8443 Not easily: it drives the implementation under test by forking a process and has quite a complex interface via command-line arguments. (I.e. https://boringssl.googlesource.com/boringssl/+/eadef4730e66f914d7b9cbb2f38ecf7989f992ed/ssl/test/test_config.h) > or should be a small c/go program be used for that test? You could easily tweak transport_common.cc to call SSL_key_update before each SSL_write or so. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
Re: haproxy 1.9.2 with boringssl
On Tue, Jan 22, 2019 at 11:16 AM Aleksandar Lazic wrote: > Agree that I get a 400 with this command. > > `echo 'K' | ./tool/bssl s_client -connect mail.google.com:443` (Note that "K" on its own line does not send a KeyUpdate message with BoringSSL's bssl tool. It just sends "K\n".) > How does boringssl test if the KeyUpdate on a server works? If you're asking how BoringSSL's internal tests exercise KeyUpdates then we maintain a fork of Go's TLS stack that is extensively modified to be able to generate a large variety of TLS patterns. That is used to exercise KeyUpdates in a number of ways: https://boringssl.googlesource.com/boringssl/+/eadef4730e66f914d7b9cbb2f38ecf7989f992ed/ssl/test/runner/runner.go#2779 Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
Re: haproxy 1.9.2 with boringssl
On Tue, Jan 22, 2019 at 10:54 AM Aleksandar Lazic wrote: > Do have boringssl a similar tool like s_client? BoringSSL builds tool/bssl (in the build directory), which is similar. However it doesn't have any magic inputs that can trigger a KeyUpdate message like OpenSSL's s_client. Cheers AGL
Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.
On Mon, Jan 21, 2019 at 10:16 AM Dirkjan Bussink wrote: > Ah ok, I recently added support in HAProxy to handle the new > SSL_CTX_set_ciphersuites option since OpenSSL handles setting TLS 1.3 ciphers > separate from the regular ones. Are those things that BoringSSL would also > want to adopt then? SSL_CTX_set_ciphersuites is more than a compatibility hack like adding a dummy #define, and the considerations are more complex. I'm not sure that we want to allow TLS 1.3 ciphersuite to be configured: the excessive number of cipher suites prior to TLS 1.3 was a problem, as was the excessive diversity of configurations. Also, string-based APIs have historically been expensive because they prevent easy static analysis. So we could add a dummy SSL_CTX_set_ciphersuites that always returns zero, but most applications would probably take that to be a fatal error so that wouldn't be helpful. So SSL_CTX_set_ciphersuites might be a case where a #ifdef is the best answer. But we'll always think about such things if asked. (If you happen to know, I would be curious who is using BoringSSL with HAProxy.) Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.
On Mon, Jan 21, 2019 at 9:49 AM Emmanuel Hocdet wrote: > Boringssl does not have SSL_OP_NO_RENEGOTIATION and need KeyUpdate to work. > As workaround, SSL_OP_NO_RENEGOTIATION could be set to 0 in openssl-compat.h. HAProxy isn't a user that we have on our radar, but BoringSSL dislikes pushing compatibility hacks into downstream projects. (You can always ask for these things to be included in BoringSSL instead.) Thus I've just added SSL_OP_NO_RENEGOTIATION as a no-op to BoringSSL: https://boringssl.googlesource.com/boringssl/+/20f4a043eb8c148d044777b849a1cc1e0168b9ee (Renegotiation is disabled by default in BoringSSL already. Also, there's only the current version of BoringSSL so no need to wait for any releases.) Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.
On Sun, Jan 20, 2019 at 3:04 PM Aleksandar Lazic wrote: > which refers to > https://www.openssl.org/docs/manmaster/man3/SSL_key_update.html > > instead of the suggested Patch? The SSL_key_update function enqueues a KeyUpdate message to be sent. The problem is that if a /client/ of HAProxy sends a KeyUpdate, HAProxy thinks that it's a pre-TLS 1.3 renegotiation message and drops the connection. Thus the patch seeks to address that. HAProxy may also want to do something like send a KeyUpdate for every x MBs of data sent, or y minutes of time elapsed, but that would be a separate feature. (And one needs to be a little cautious because OpenSSL 1.1.1 will only accept 32 KeyUpdate messages per connection.) Cheers AGL
Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.
On Sun, Jan 20, 2019 at 2:41 PM Willy Tarreau wrote: > Just out of curiosity, if such out-of-band messages are enabled again in > 1.3, do you think this might have any particular impacts on something like > kTLS where the TLS stream is deciphered by the kernel ? I don't know how > such messages can safely be delivered to userland in this case, nor if > they're needed there at all. No idea, I'm afraid. If you have a server to test, it looks like one can use OpenSSL 1.1.1's `openssl s_client` tool to send a KeyUpdate message by writing "K" on a line by itself. If I were to guess about how in-kernel TLS would work, I would think that the message would be handled internally and user-space wouldn't need to know anything about it: it just requires rotating the traffic keys and, potentially, writing a message in reply—both things that the kernel can probably handle itself. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.
KeyUpdate messages are a feature of TLS 1.3 that allows the symmetric
keys of a connection to be periodically rotated. It's
mandatory-to-implement in TLS 1.3, but not mandatory to use. Google
Chrome tried enabling KeyUpdate and promptly broke several sites, at
least some of which are using HAProxy.
The cause is that HAProxy's code to disable TLS renegotiation[1] is
triggering for TLS 1.3 post-handshake messages. But renegotiation has
been removed in TLS 1.3 and post-handshake messages are no longer
abnormal. Thus I'm attaching a patch to only enforce that check when
the version of a TLS connection is <= 1.2.
Since sites that are using HAProxy with OpenSSL 1.1.1 will break when
Chrome reenables KeyUpdate without this change, I'd like to suggest it
as a candidate for backporting to stable branches.
[1] https://github.com/haproxy/haproxy/blob/master/src/ssl_sock.c#L1472
Thank you
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
From 39a7adab6c2583f7cf4bbe0c888c4131823d6500 Mon Sep 17 00:00:00 2001
From: Adam Langley
Date: Sun, 20 Jan 2019 12:59:20 -0800
Subject: [PATCH] Ignore post-handshake messages in TLS 1.3 and later.
TLS 1.3 removed renegotiation but has other types of post-handshake
messages including KeyUpdate and post-handshake authentication. The
check for renegotiation in HAProxy is mistakenly triggering for these
messages in TLS 1.3.
Google Chrome plans on using KeyUpdate in the future so, at that time,
HAProxy linked against OpenSSL 1.1.1 will stop working (unless TLS 1.3
is disabled) without this patch.
---
src/ssl_sock.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 9153843b..854becc7 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -1463,21 +1463,26 @@ out:
#endif
void ssl_sock_infocbk(const SSL *ssl, int where, int ret)
{
struct connection *conn = SSL_get_ex_data(ssl, ssl_app_data_index);
BIO *write_bio;
(void)ret; /* shut gcc stupid warning */
if (where & SSL_CB_HANDSHAKE_START) {
/* Disable renegotiation (CVE-2009-3555) */
- if ((conn->flags & (CO_FL_CONNECTED | CO_FL_EARLY_SSL_HS | CO_FL_EARLY_DATA)) == CO_FL_CONNECTED) {
+ if ((conn->flags & (CO_FL_CONNECTED | CO_FL_EARLY_SSL_HS | CO_FL_EARLY_DATA)) == CO_FL_CONNECTED &&
+ /* Renegotiation has been removed from TLS 1.3. However,
+ TLS 1.3 post-handshake messages like KeyUpdate will still
+ trigger this callback. These must be ignored in TLS 1.3
+ to avoid false-positives. */
+ SSL_version(ssl) <= TLS1_2_VERSION) {
conn->flags |= CO_FL_ERROR;
conn->err_code = CO_ER_SSL_RENEG;
}
}
if ((where & SSL_CB_ACCEPT_LOOP) == SSL_CB_ACCEPT_LOOP) {
if (!(conn->xprt_st & SSL_SOCK_ST_FL_16K_WBFSIZE)) {
/* Long certificate chains optimz
If write and read bios are differents, we
consider that the buffering was activated,
--
2.20.1
