Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
I've committed your patch and the changes I suggested earlier, plus docs and tests. Thanks for the patch, and for the reminder! Ryan On 04/11/2014 09:30 PM, Edward Lee wrote: Thanks. I will not have time until Monday; if you can wait until then, I will have an updated patch then. --Edward On Fri, Apr 11, 2014 at 06:44:17PM -0400, Ryan Culpepper wrote: IIRC, most of the code in openssl/mzssl.rkt predates ffi/unsafe/alloc. So yes, BIO_new etc should use (allocator _) etc, and that would simplify some of the code that currently uses the local with-failure macro to do deallocation. But no need to fix that in this patch. Some comments on the patch: - Regarding curves/c, the curve NID_* definitions, and symbol->nid: There's some redundancy here that could be eliminated with the following pattern: (define curve-nid-alist '((sect163k1 . 721) )) (define curve/c (apply or/c (map car curve-nid-alist))) (define (curve->nid sym) (cond [(assq sym curve-nid-alist) => cdr] [else (error )])) That eliminates the problem of keeping the enumeration of curves in sync in three places. - SSL_CTRL_SET_ECDH_AUTO is unused; it should be removed. - There's a missing "!" in some of the symbols passed to error in ssl-server-context-enable-dhe!. If you send a new version of the patch I'll commit that; otherwise I can make the changes above myself when I get a chance. Ryan On 04/11/2014 01:46 PM, Edward Lee wrote: Thanks for catching the typo. I don't have a good answer to your second question; I really don't know if they should. --Edward On Thu, Apr 10, 2014 at 02:54:36PM -0400, Stephen Chang wrote: Ok thanks. Sorry, I think one more is missing from curve/c (sect283r1)? Another question: Should BIO_new_mem_buf have an additional "#:wrap (allocator BIO_free)" argument, similar to other allocating functions? More generally, should BIO_new and BIO_free have #:wrap arguments like the other allocating/deallocating functions? On Thu, Apr 10, 2014 at 2:11 PM, Edward Lee wrote: Those are accidental omissions; I've attached a patch that should fix the contract and symbol->nid. --Edward On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: 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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
Thanks. I will not have time until Monday; if you can wait until then, I will have an updated patch then. --Edward On Fri, Apr 11, 2014 at 06:44:17PM -0400, Ryan Culpepper wrote: > IIRC, most of the code in openssl/mzssl.rkt predates > ffi/unsafe/alloc. So yes, BIO_new etc should use (allocator _) etc, > and that would simplify some of the code that currently uses the > local with-failure macro to do deallocation. But no need to fix that > in this patch. > > Some comments on the patch: > > - Regarding curves/c, the curve NID_* definitions, and symbol->nid: > There's some redundancy here that could be eliminated with the > following pattern: > > (define curve-nid-alist > '((sect163k1 . 721) > )) > > (define curve/c (apply or/c (map car curve-nid-alist))) > > (define (curve->nid sym) > (cond [(assq sym curve-nid-alist) > => cdr] > [else (error )])) > > That eliminates the problem of keeping the enumeration of curves in > sync in three places. > > - SSL_CTRL_SET_ECDH_AUTO is unused; it should be removed. > > - There's a missing "!" in some of the symbols passed to error in > ssl-server-context-enable-dhe!. > > If you send a new version of the patch I'll commit that; otherwise I > can make the changes above myself when I get a chance. > > Ryan > > > On 04/11/2014 01:46 PM, Edward Lee wrote: > >Thanks for catching the typo. I don't have a good answer to your second > >question; I really don't know if they should. > > > >--Edward > > > >On Thu, Apr 10, 2014 at 02:54:36PM -0400, Stephen Chang wrote: > >>Ok thanks. Sorry, I think one more is missing from curve/c (sect283r1)? > >> > >>Another question: Should BIO_new_mem_buf have an additional "#:wrap > >>(allocator BIO_free)" argument, similar to other allocating functions? > >> > >>More generally, should BIO_new and BIO_free have #:wrap arguments like > >>the other allocating/deallocating functions? > >> > >>On Thu, Apr 10, 2014 at 2:11 PM, Edward Lee wrote: > >>>Those are accidental omissions; I've attached a patch that should fix > >>>the contract and symbol->nid. > >>> > >>>--Edward > >>> > >>>On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: > 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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
IIRC, most of the code in openssl/mzssl.rkt predates ffi/unsafe/alloc. So yes, BIO_new etc should use (allocator _) etc, and that would simplify some of the code that currently uses the local with-failure macro to do deallocation. But no need to fix that in this patch. Some comments on the patch: - Regarding curves/c, the curve NID_* definitions, and symbol->nid: There's some redundancy here that could be eliminated with the following pattern: (define curve-nid-alist '((sect163k1 . 721) )) (define curve/c (apply or/c (map car curve-nid-alist))) (define (curve->nid sym) (cond [(assq sym curve-nid-alist) => cdr] [else (error )])) That eliminates the problem of keeping the enumeration of curves in sync in three places. - SSL_CTRL_SET_ECDH_AUTO is unused; it should be removed. - There's a missing "!" in some of the symbols passed to error in ssl-server-context-enable-dhe!. If you send a new version of the patch I'll commit that; otherwise I can make the changes above myself when I get a chance. Ryan On 04/11/2014 01:46 PM, Edward Lee wrote: Thanks for catching the typo. I don't have a good answer to your second question; I really don't know if they should. --Edward On Thu, Apr 10, 2014 at 02:54:36PM -0400, Stephen Chang wrote: Ok thanks. Sorry, I think one more is missing from curve/c (sect283r1)? Another question: Should BIO_new_mem_buf have an additional "#:wrap (allocator BIO_free)" argument, similar to other allocating functions? More generally, should BIO_new and BIO_free have #:wrap arguments like the other allocating/deallocating functions? On Thu, Apr 10, 2014 at 2:11 PM, Edward Lee wrote: Those are accidental omissions; I've attached a patch that should fix the contract and symbol->nid. --Edward On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: 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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
Thanks for catching the typo. I don't have a good answer to your second question; I really don't know if they should. --Edward On Thu, Apr 10, 2014 at 02:54:36PM -0400, Stephen Chang wrote: > Ok thanks. Sorry, I think one more is missing from curve/c (sect283r1)? > > Another question: Should BIO_new_mem_buf have an additional "#:wrap > (allocator BIO_free)" argument, similar to other allocating functions? > > More generally, should BIO_new and BIO_free have #:wrap arguments like > the other allocating/deallocating functions? > > On Thu, Apr 10, 2014 at 2:11 PM, Edward Lee wrote: > > Those are accidental omissions; I've attached a patch that should fix > > the contract and symbol->nid. > > > > --Edward > > > > On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: > >> 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 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..f9d3faf 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,15 @@ 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 'sect163k1 +'sect163r1 'sect163r2 'sect193r1 'sect193r2 +'sect233k1 'sect233r1 'sect239k1 'sect283r1 +'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 +59,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 +69,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 +199,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 +211,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) #:wra
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
Ok thanks. Sorry, I think one more is missing from curve/c (sect283r1)? Another question: Should BIO_new_mem_buf have an additional "#:wrap (allocator BIO_free)" argument, similar to other allocating functions? More generally, should BIO_new and BIO_free have #:wrap arguments like the other allocating/deallocating functions? On Thu, Apr 10, 2014 at 2:11 PM, Edward Lee wrote: > Those are accidental omissions; I've attached a patch that should fix > the contract and symbol->nid. > > --Edward > > On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: >> 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.
Those are accidental omissions; I've attached a patch that should fix the contract and symbol->nid. --Edward On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: > 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 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..d2918ca 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,15 @@ 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 'sect163k1 +'sect163r1 'sect163r2 'sect193r1 'sect193r2 +'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 +59,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 +69,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 +199,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 +211,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 +285,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_lengt
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
