tried openssl 1.1.0 beta 5 with my nghttp2 docker image but libevent compilation didn’t like openssl 1.10 beta 5 heh
[91mar: `u' modifier ignored since `D' is the default (see `U')
e[0m CC evthread_pthread.lo
CC libevent_openssl_la-bufferevent_openssl.lo
e[91mIn file included from /usr/local/http2-15/include/openssl/x509.h:363:0,
from /usr/local/http2-15/include/openssl/ssl.h:150,
from bufferevent_openssl.c:67:
/usr/local/http2-15/include/openssl/x509_vfy.h:379:6: warning: redundant redeclaration of 'X509_STORE_CTX_set_verify_cb' [-Wredundant-decls]
void X509_STORE_CTX_set_verify_cb(X509_STORE_CTX *ctx,
^
/usr/local/http2-15/include/openssl/x509_vfy.h:312:6: note: previous declaration of 'X509_STORE_CTX_set_verify_cb' was here
void X509_STORE_CTX_set_verify_cb(X509_STORE_CTX *ctx,
^
e[0me[91mbufferevent_openssl.c: In function 'bio_bufferevent_new':
bufferevent_openssl.c:112:3: error: dereferencing pointer to incomplete type 'BIO {aka struct bio_st}'
b->init = 0;
^
e[0me[91mbufferevent_openssl.c: At top level:
bufferevent_openssl.c:234:1: error: variable 'methods_bufferevent' has initializer but incomplete type
static BIO_METHOD methods_bufferevent = {
^
bufferevent_openssl.c:85:27: warning: excess elements in struct initializer
#define BIO_TYPE_LIBEVENT 57
^
bufferevent_openssl.c:235:2: note: in expansion of macro 'BIO_TYPE_LIBEVENT'
BIO_TYPE_LIBEVENT, "bufferevent",
^
bufferevent_openssl.c:85:27: note: (near initialization for 'methods_bufferevent')
#define BIO_TYPE_LIBEVENT 57
^
bufferevent_openssl.c:235:2: note: in expansion of macro 'BIO_TYPE_LIBEVENT'
BIO_TYPE_LIBEVENT, "bufferevent",
^
Does anyone know when OpenSSL 1.1.0 is officially being released? It was originally slated for 12 May IIRC.
I’ve (briefly) looked into using LibreSSL or the Cloudflare patch on my Raspberry Pi but it all seems too much hassle for my Apache server given the (hopefully) imminent release of OpenSSL with Chacha20_Poly1305 support.
Note, I’m not using any elliptic curves and have A+, 4x100% on SSLLabs. It’s an exercise in masochism for a Raspberry Pi 2 without a more lightweight 256-bit equivalent stream software cipher.
Note that OpenSSL 1.1.0 is an API-breaking update as the previous version is 1.0.2.
So not only the server software has to be compatible, but also all other software which uses "libcrypto" or "libssl" running on your server.
If you imply that your RasPi would be overloaded when handling elliptic curve certificates, you're wrong. Because actually all elliptic curves used in TLS are faster than RSA.
I'm not entirely sure, but Chacha20_Poly1305 might be the fastest however.
Chacha20/Poly1305 is completely separated from the used key exchange and authentication algorithm, as it's the symmetric cipher of the cipher suit, comparable with AES. In fact, you can have elliptic curve key exchange, RSA based authentication with a ChaCha20/Poly1305 symmetric cipher: ChaCha20-Poly1305 cipher suites from draft-ietf-tls-chacha20-poly1305-04, extending TLS v1.2
I’m not suggesting the RPi would be overloaded by ECC, quite the opposite (it was far faster when I did include ECC).
I’ve just decided to use 4k DH/RSA rather than ECC. IIRC I read that post-quantum they are more resistant than ECC if you want longer term privacy.
My goal is to keep 4x100% in SSLLabs, but currently (without ECC) the only two FS 256-bit cipher suites are DHE-RSA-AES256-GCM-SHA384 and DHE-RSA-AES256-SHA. The latter is used by Firefox and isn’t optimal. Also, IIRC, Firefox 47 will support Chacha20+Poly1305, hence my interest.
I looked into that the other day with Apache (also LibreSSL), but with the hopefully imminent arrival of OpenSSL 1.1.0 I’d rather just wait and keep it all in sync with my debian repos.
This may be because you do not support DHE-RSA-AES256-SHA256. Because Firefox does not support SHA384.
And already this SHA1 is much more insecure - if you look at future attacks - than ECC could probably be. So better fix this than thinking about not-supporting ECC ciphers.
And BTW: DHE is not secure against quantum attacks. AFAIK no SSL cipher currently is. There is not really much you can do.
Edit: Indeed there are no working post-quantum-secure things in TLS, so don't worry about post-quantum attacks. Rather keep your config up-to-date with the current situation. If you use DHE I e.g. hope you've generated your own Diffie-Hellmann parameters.
Ah with DHE-RSA-AES256-SHA256, DHE-RSA-AES256-SHA you do not use AES in GCM mode. You should activate DHE-RSA-AES128-GCM-SHA256.
GCM mode is more secure than the CBC mode of AES. At least GCM is authenticated encryption.
So again: Do not worry about quantum cryptography. It really does not matter. Focus on current attacks and use strong ciphers (as e.g. the correct AES mode) and do not think what might happen when we are in a post-quantum world.
I agree with you, but one of the points of my server is as a testbed for SSLLabs with 100% everything. Allowing AES128 would lose that. I’m expecting OpenSSL 1.1.0 to help solve Firefox using CBC and SHA1 (along with Firefox 47) whilst maintaining the 100%s. It’s not a practical widely-used website, just a testbed for use with modern browsers. Getting rid of SHA-1 would mean it fails with Firefox.
1 The attacks on AES256 are mostly related key attacks, -> e.g. bad RNG -> your server is unsecure anyway
2 Performance part is mostly important on the server and not THAT much on the client because a server has far more simultaneous connects than the client.
3 when quantum comes the effective security is effectively halved meaning that you AES128 becomes essentially 64bit of security which is iirc pretty broken and AES256 becomes 128 bits effective security which will hold out a lot longer.
AES 256 is considered more vulnerable to timing attacks than AES 128bit.
This was mentioned already a few times when talking about why Certbot prefers 128bit AES ciphers.
See this thread e.g.:
Performance is not a real concern. And AFAIK whether to use AES 128 or 256bit affects both the client and the server.
Quantum computers cannot break symmetric encryption! Only asymmetric encryption is endangered by quantum computers. Thus AES is not endangered. And the additional 128bit would not matter anyway, I think.
But before you do, please inform yourself why they made this decision. They have many clever people there, so you can be almost sure they have a good reason for doing something the way they do.
Q: The commercial world appears to be moving to elliptic curves. Why is NSA continuing to support older algorithms?
A: NSA supports the use of NIST P-384 in NSS. In the original CNSSP-15 both RSA and Diffie-Hellman were included as legacy algorithms which were only to be used until replacement elliptic curve cryptography (ECC) equipment was available. Since that time NSA has come to appreciate that some of these legacy systems will be around for much longer than we had planned. Because of these legacy systems and because there is an eventual need to move to quantum resistant public key algorithms, NSA has decided that it may be more cost effective for some NSS to continue to use RSA and Diffie-Hellman with larger key sizes until the new quantum resistant public key algorithms are ready. NSA does not want to force NSS operators to pay for two cryptographic upgrades: first from RSA/Diffie-Hellman to ECC and then from ECC to quantum resistant cryptography. https://www.penfold.fr/docs/CNSA-Suite-and-Quantum-Computing-FAQ.pdf
