ECDHE Negotiation for Client but not Server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorted; needed to call SSL_CTX_set_tmp_ecdh with my private EC_KEY.  Can
someone express an opinion if using my private key is acceptable there, or
if I should generate a new one from a named curve each time I create a
context?

Cheers,
--B

On Fri, Nov 13, 2015 at 11:21 AM, Benn Bollay <benn.bollay at gmail.com> wrote:

> Hi folks -
>
> Tested against OpenSSL 1.0.1f and 1.0.1p (but with modifications).
>
> I've got some code that creates an SSL_CTX (http://pastebin.com/XveDvvch)
> that works fine for negotiating ECDHE-* ciphers as a client when talking to
> an s_server, but fails as a server both when accepting connections from
> itself or from s_client with a no shared cipher error.
>
> You can download a full package to reproduce the issue at
> http://www.magitech.org/gambit/ecdhetest.tar.gz
>
> You can run the test by using make:
>
>   $ make all
>
>   $ make s_server & # Run?s OpenSSL s_server in the background
>
>   $ make t_client # Runs the client - should be able to see the handshake
> complete on the server?s log window.
>
>   $ make t_server & # After killing the s_server, start up the test server
>
>   $ make s_client # Fails to negotiate.
>
> Any suggestions?
> Cheers,
> --B
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151113/c6986b2c/attachment-0001.html>


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux