Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
I checked out the patch and have a few questions. (I'm a non-expert.) How come some curves are omitted from the curve/c contract (eg sect163k1 and sect193r2)? Is there also a curve missing from symbol->nid (eg sect571r1)? On Wed, Apr 9, 2014 at 7:52 PM, Neil Van Dyke wrote: > Edward, your patch sounds OK to me, FWIW. > > Neil V. > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
Edward, your patch sounds OK to me, FWIW. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
My patch does not include any C code; I have not audited any existing
OpenSSL code, but to the best of my knowledge, OpenSSL + (EC)DHE is
commonly used across webservers today.
To answer your second point, the
perfect forward secrecy extensions are disabled by default, and
must be explicitly enabled on the server.
(by calling ssl-server-context-enable-dhe! and ssl-server-context-enable-ecdhe!)
Perfect Forward Secrecy, to some extent mitigates the damage
that can be done when private keys are compromised (like what happened
recently); it at least prevents an attacker from decrypting any SSL
conversations
he/she may have recorded previously. Currently, if server private keys are
compromised, with Racket's OpenSSL's current mode of operations, all
previous encrypted conversations can be decrypted.
Given what has happened recently, I am sure we can all agree that
anything that mitigates the damage when private keys are compromised is
a Good Thing.
On Wed, Apr 09, 2014 at 04:47:44PM -0400, Neil Van Dyke wrote:
> * Is anyone up to auditing the C code? To support my earlier
> concern
> ("http://lists.racket-lang.org/dev/archive/2014-February/013935.html";),
> you've probably heard in the last few days about a C oops bug in
> OpenSSL that has compromised the private keys of 2/3 of the Internet
> for over a year now. I think we are going to keep seeing exploits
> like this in SSL/TLS/etc. implementations, because some of the
> protocols are hairy, and the implementations don't seem to be
> perfect like they we need them to be.
>
> * Are all the new (to Racket) OpenSSL code paths enabled by this
> change disabled *entirely* by default, or are there some
> new-to-Racket code paths that can be negotiated by the other party
> with the default Racket use of OpenSSL? The reason I ask is that I
> believe that the fewer unnecessary OpenSSL code paths available, the
> fewer OpenSSL vulnerabilities available.
>
> (BTW, I'm not harshing on OpenSSL entirely. OpenSSL been
> indispensible for some of my work, dealing with myriad oddball
> security protocols that no one wants to take the huge development
> cost hit of coding and validating from scratch. But I don't have a
> high level of confidence in the code.)
>
> Neil V.
>
> Edward Lee wrote at 04/09/2014 04:20 PM:
> >I previously submitted this patch in late January; I've not received any
> >progress updates with regards to this patch recently - did this patch
> >get lost between then and now?
> >
> >This patch adds Perfect Forward Secrecy to Racket's OpenSSL bindings.
> >This patch has been tested on Ubuntu 12.04 (and appears to work
> >correctly in a production environment).
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
* Is anyone up to auditing the C code? To support my earlier concern
("http://lists.racket-lang.org/dev/archive/2014-February/013935.html";),
you've probably heard in the last few days about a C oops bug in OpenSSL
that has compromised the private keys of 2/3 of the Internet for over a
year now. I think we are going to keep seeing exploits like this in
SSL/TLS/etc. implementations, because some of the protocols are hairy,
and the implementations don't seem to be perfect like they we need them
to be.
* Are all the new (to Racket) OpenSSL code paths enabled by this change
disabled *entirely* by default, or are there some new-to-Racket code
paths that can be negotiated by the other party with the default Racket
use of OpenSSL? The reason I ask is that I believe that the fewer
unnecessary OpenSSL code paths available, the fewer OpenSSL
vulnerabilities available.
(BTW, I'm not harshing on OpenSSL entirely. OpenSSL been indispensible
for some of my work, dealing with myriad oddball security protocols that
no one wants to take the huge development cost hit of coding and
validating from scratch. But I don't have a high level of confidence in
the code.)
Neil V.
Edward Lee wrote at 04/09/2014 04:20 PM:
I previously submitted this patch in late January; I've not received any
progress updates with regards to this patch recently - did this patch
get lost between then and now?
This patch adds Perfect Forward Secrecy to Racket's OpenSSL bindings.
This patch has been tested on Ubuntu 12.04 (and appears to work
correctly in a production environment).
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] ECDHE patch for Racket's OpenSSL bindings.
I previously submitted this patch in late January; I've not received any progress updates with regards to this patch recently - did this patch get lost between then and now? This patch adds Perfect Forward Secrecy to Racket's OpenSSL bindings. This patch has been tested on Ubuntu 12.04 (and appears to work correctly in a production environment). diff --git a/racket/collects/openssl/dh4096.pem b/racket/collects/openssl/dh4096.pem new file mode 100644 index 000..1b35ad8 --- /dev/null +++ b/racket/collects/openssl/dh4096.pem @@ -0,0 +1,18 @@ +-BEGIN DH PARAMETERS- +MIICCAKCAgEA+hRyUsFN4VpJ1O8JLcCo/VWr19k3BCgJ4uk+d+KhehjdRqNDNyOQ +l/MOyQNQfWXPeGKmOmIig6Ev/nm6Nf9Z2B1h3R4hExf+zTiHnvVPeRBhjdQi81rt +Xeoh6TNrSBIKIHfUJWBh3va0TxxjQIs6IZOLeVNRLMqzeylWqMf49HsIXqbcokUS +Vt1BkvLdW48j8PPv5DsKRN3tloTxqDJGo9tKvj1Fuk74A+Xda1kNhB7KFlqMyN98 +VETEJ6c7KpfOo30mnK30wqw3S8OtaIR/maYX72tGOno2ehFDkq3pnPtEbD2CScxc +alJC+EL7RPk5c/tgeTvCngvc1KZn92Y//EI7G9tPZtylj2b56sHtMftIoYJ9+ODM +sccD5Piz/rejE3Ome8EOOceUSCYAhXn8b3qvxVI1ddd1pED6FHRhFvLrZxFvBEM9 +ERRMp5QqOaHJkM+Dxv8Cj6MqrCbfC4u+ZErxodzuusgDgvZiLF22uxMZbobFWyte +OvOzKGtwcTqO/1wV5gKkzu1ZVswVUQd5Gg8lJicwqRWyyNRczDDoG9jVDxmogKTH +AaqLulO7R8Ifa1SwF2DteSGVtgWEN8gDpN3RBmmPTDngyF2DHb5qmpnznwtFKdTL +KWbuHn491xNO25CQWMtem80uKw+pTnisBRF/454n1Jnhub144YRBoN8CAQI= +-END DH PARAMETERS- + +These are the 4096 bit DH parameters from "Assigned Number for SKIP Protocols" +(http://www.skip-vpn.org/spec/numbers.html). +See there for how they were generated. +Note that g is not a generator, but this is not a problem since p is a safe prime. diff --git a/racket/collects/openssl/mzssl.rkt b/racket/collects/openssl/mzssl.rkt index 2f16517..31bc8c9 100644 --- a/racket/collects/openssl/mzssl.rkt +++ b/racket/collects/openssl/mzssl.rkt @@ -34,6 +34,7 @@ TO DO: racket/tcp racket/string racket/lazy-require + racket/runtime-path "libcrypto.rkt" "libssl.rkt") (lazy-require @@ -41,7 +42,13 @@ TO DO: ["private/macosx.rkt" (load-macosx-keychain)]) (define protocol-symbol/c - (or/c 'sslv2-or-v3 'sslv2 'sslv3 'tls)) + (or/c 'sslv2-or-v3 'sslv2 'sslv3 'tls 'tls11 'tls12)) +(define curves/c + (or/c 'sect163r1 'sect163r2 'sect193r1 'sect233k1 'sect233r1 'sect239k1 +'sect283k1 'sect409k1 'sect409r1 'sect571k1 'sect571r1 +'secp160k1 'secp160r1 'secp160r2 'secp192k1 'secp224k1 'secp224r1 +'secp256k1 'secp384r1 'secp521r1 +'prime192v1 'prime256v1)) (define verify-source/c (or/c path-string? @@ -50,6 +57,7 @@ TO DO: (list/c 'macosx-keychain path-string?))) (provide + ssl-dh-param-path (contract-out [ssl-available? boolean?] [ssl-load-fail-reason (or/c #f string?)] @@ -59,6 +67,10 @@ TO DO: (c-> ssl-client-context?)] [ssl-make-server-context (->* () (protocol-symbol/c) ssl-server-context?)] + [ssl-server-context-enable-dhe! + (->* (ssl-server-context?) (path-string?) void?)] + [ssl-server-context-enable-ecdhe! + (->* (ssl-server-context?) (curves/c) void?)] [ssl-client-context? (c-> any/c boolean?)] [ssl-server-context? @@ -185,6 +197,8 @@ TO DO: (define-cpointer-type _X509*) (define-cpointer-type _ASN1_STRING*) (define-cpointer-type _STACK*) +(define-cpointer-type _DH*) +(define-cpointer-type _EC_KEY*) (define-cstruct _GENERAL_NAME ([type _int] [d _ASN1_STRING*])) (define-ssl SSLv2_client_method (_fun -> _SSL_METHOD*)) @@ -195,9 +209,19 @@ TO DO: (define-ssl SSLv23_server_method (_fun -> _SSL_METHOD*)) (define-ssl TLSv1_client_method (_fun -> _SSL_METHOD*)) (define-ssl TLSv1_server_method (_fun -> _SSL_METHOD*)) +(define-ssl TLSv1_1_client_method (_fun -> _SSL_METHOD*)) +(define-ssl TLSv1_1_server_method (_fun -> _SSL_METHOD*)) +(define-ssl TLSv1_2_client_method (_fun -> _SSL_METHOD*)) +(define-ssl TLSv1_2_server_method (_fun -> _SSL_METHOD*)) + +(define-crypto DH_free (_fun _DH* -> _void) #:wrap (deallocator)) +(define-crypto EC_KEY_free (_fun _EC_KEY* -> _void) #:wrap (deallocator)) + +(define-crypto EC_KEY_new_by_curve_name (_fun _int -> _EC_KEY*) #:wrap (allocator EC_KEY_free)) (define-crypto BIO_s_mem (_fun -> _BIO_METHOD*)) (define-crypto BIO_new (_fun _BIO_METHOD* -> _BIO*/null)) +(define-crypto BIO_new_mem_buf (_fun _pointer _int -> _BIO*)) (define-crypto BIO_free (_fun _BIO* -> _void)) (define-crypto BIO_read (_fun _BIO* _bytes _int -> _int)) @@ -259,6 +283,7 @@ TO DO: (define-ssl SSL_load_error_strings (_fun -> _void)) (define-crypto GENERAL_NAME_free _fpointer) +(define-crypto PEM_read_bio_DHparams (_fun _BIO* _pointer _pointer _pointer -> _DH*) #:wrap (allocator DH_free)) (define-crypto ASN1_STRING_length (_fun _ASN1_STRING* -> _int)) (define-crypto ASN1_STRING_data (_fun _ASN1_STRING* -> _pointer)) (define-crypto X509_NAME_get_index_by_NID (_fun _X509_NAME* _int _int -> _int)) @@ -331,8 +356,46 @@ TO DO: (define NID_commonName 13) (define GEN_DNS 2) +(define SSL_CTRL_SET_ECDH_AUTO 94) +(define SSL_CTRL_OPTIONS 32) +(defin
