[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).