Re: [openssl.org #3106] [PATCH] Fix build with OPENSSL_NO_NEXTPROTONEG.
Hey Steve, >> While it cannot be enabled via ./config options, > > Why not? The standard way to include such options is via config or Configure > and some platforms (e.g. Windows) require this. Actually, it turns out that I was wrong, so please ignore that part. For the reference: What I meant is that currently (i.e. git master, nothing to do with the patch) OPENSSL_NO_NEXTPROTONEG cannot be enabled via ./config options and I had to pass it via CFLAGS, but that turned out to be just a user error... I didn't know that "no-XXX" is automatically translated to OPENSSL_NO_XXX and I was trying to disable NPN with "no-npn" (as described in CHANGES), which obviously didn't do much good... "no-nextprotoneg" works fine, though :) Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3106] [PATCH] Fix build with OPENSSL_NO_NEXTPROTONEG.
Hey Steve, >> While it cannot be enabled via ./config options, > > Why not? The standard way to include such options is via config or Configure > and some platforms (e.g. Windows) require this. Actually, it turns out that I was wrong, so please ignore that part. For the reference: What I meant is that currently (i.e. git master, nothing to do with the patch) OPENSSL_NO_NEXTPROTONEG cannot be enabled via ./config options and I had to pass it via CFLAGS, but that turned out to be just a user error... I didn't know that "no-XXX" is automatically translated to OPENSSL_NO_XXX and I was trying to disable NPN with "no-npn" (as described in CHANGES), which obviously didn't do much good... "no-nextprotoneg" works fine, though :) Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3102] s_server does not reject invalid client certificates in "OpenSSL 1.0.1 14 Mar 2012" with -verify or -Verify options
Steve, Thank you! That worked. That option doesn't exist in the man page for s_server (1.0.1 2013-06-04) for me, so this may be a documentation bug then? Thanks again! Jim On 08/06/2013 10:46 AM, Stephen Henson via RT wrote: On Fri Aug 02 10:23:23 2013, j...@jimkeener.com wrote: With -verify and -Verify I believe that the server should reject the connection if the certificate isn't signed by a valid CA. Is there a way to emulate such behaviour, or is there a reason that this behaves in such a manner? The -verify and -Verify options just decide if a certificate should be request and if the client must use a certificate. For debugging purposes, by default, the connection continues if the chain doesn't verify. If you use the option -verify_return_error the connection should fail. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3102] s_server does not reject invalid client certificates in "OpenSSL 1.0.1 14 Mar 2012" with -verify or -Verify options
Steve, Thank you! That worked. That option doesn't exist in the man page for s_server (1.0.1 2013-06-04) for me, so this may be a documentation bug then? Thanks again! Jim On 08/06/2013 10:46 AM, Stephen Henson via RT wrote: > On Fri Aug 02 10:23:23 2013, j...@jimkeener.com wrote: >> With -verify and -Verify I believe that the server should reject the >> connection if the certificate isn't signed by a valid CA. Is there a way >> to emulate such behaviour, or is there a reason that this behaves in >> such a manner? >> > The -verify and -Verify options just decide if a certificate should be request > and if the client must use a certificate. For debugging purposes, by default, > the connection continues if the chain doesn't verify. If you use the option > -verify_return_error the connection should fail. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Help needed with OpenSSL API (Using TLS to establish SSH-like key based trust model (fwd))
Hello,
first let me apologise in advance since this list is probably
inappropriate but I got no answer in openssl-users in more than one week,
that list seems more user-tools oriented. I forward the whole email, but
please have a look at least in the summary that prepends it. I appreciate
all help I can get. :-)
Summary:
* Client and server have their RSA key pairs. They also have exchanged
their public keys. I.e. client has server's public RSA key, Server has
client's public RSA key.
* Both generate temporary in-memory certificate with dummy data,
containing public key, and signed with private. These certificates are
both-ways exchanged during the TLS handshake.
* Now the client has to verify the server's certificate and vice-versa.
Since I disable all OpenSSL verification with
SSL_CTX_set_cert_verify_callback(), I have to do it manually.
*** THIS IS THE PART I HAVE DOUBTS ABOUT ***
For this part I call the undocumented X509_get_pubkey(received_cert), and
compare that public key to the one stored. But How can I verify that the
received certificate is not tampered, i.e. properly signed by that peer's
private key, what call in the API should I use? Any other comments on this
trust verification procedure?
Thank you in advance,
Dimitris
-- Forwarded message --
Date: Mon, 29 Jul 2013 16:29:26 +0200 (CEST)
From: Dimitrios Apostolou
To: openssl-us...@openssl.org
Subject: Using TLS to establish SSH-like key based trust model
Hello list,
I am trying to use OpenSSL to provide SSH-like trust model, by using TLS. That
means that the two peers have an RSA key pair stored, no certificate. They have
also exchanged their public keys in a secure manner. Here is the way I do it, I
would appreciate all opinions on this:
* During initialisation peers generate an in-memory, temporary x509
certificate. It contains the minimal dummy data I could get away with, i.e. a
dummy CN, issuer, and 100 years lifetime before expiring. These are never
checked anyway.
* The important step is that the certificate contains the peer's public key and
it is signed using the peer's private key:
EVP_PKEY *pkey = EVP_PKEY_new();
EVP_PKEY_assign_RSA(pkey, PRIVKEY);
X509_set_pubkey(x509, pkey);
X509_sign(x509, pkey, EVP_sha384());
* The x509 certificate is then assigned to SSL_CTX (SSL_CTX_use_certificate())
and is used for the whole application lifetime.
* For trust establishment I disable the callback mechanism
(SSL_CTX_set_cert_verify_callback(always_success_callback)) mainly because I
had issues with multiple threads. I also set the option to request certificate
both ways (SSL_CTX_set_verify(SSL_VERIFY_PEER) in both peers). Immediately
after each TLS session is established I do the following:
X509 *received_cert = SSL_get_peer_certificate(ssl);
EVP_PKEY *received_pubkey = X509_get_pubkey(received_cert);
// expected_rsa_key is the foreign peer's public key, we assume it has been
safely exchanged
EVP_PKEY expected_pubkey = { 0 };
ret = EVP_PKEY_assign_RSA(&expected_pubkey, expected_rsa_key);
ret = EVP_PKEY_cmp(received_pubkey, &expected_pubkey);
if (ret == 1)
return 1;// THE SESSION IS SECURE!
else
return 0;// WATCH-OUT!
That means I ignore all of the certificate besides the public key, which I
compare to the stored one. The in-memory certificate is re-generated from the
stored RSA key every time the application starts.
Do you think this is a secure design/implementation for my requirements? Can
you identify any flaws?
Thank you in advance,
Dimitris
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3102] s_server does not reject invalid client certificates in "OpenSSL 1.0.1 14 Mar 2012" with -verify or -Verify options
On Fri Aug 02 10:23:23 2013, j...@jimkeener.com wrote: > > With -verify and -Verify I believe that the server should reject the > connection if the certificate isn't signed by a valid CA. Is there a way > to emulate such behaviour, or is there a reason that this behaves in > such a manner? > The -verify and -Verify options just decide if a certificate should be request and if the client must use a certificate. For debugging purposes, by default, the connection continues if the chain doesn't verify. If you use the option -verify_return_error the connection should fail. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3106] [PATCH] Fix build with OPENSSL_NO_NEXTPROTONEG.
On Tue Aug 06 10:05:56 2013, pi...@cloudflare.com wrote: > > While it cannot be enabled via ./config options, Why not? The standard way to include such options is via config or Configure and some platforms (e.g. Windows) require this. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and the APLN Patch
Well there you go then. Thanks! On 06/08/2013, at 10:53 AM, Piotr Sikora wrote: > Hey Mark, > ALPN support is already in the mainline: > http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f017a8f9db3a79f3a3406cf8d493ccd346db691 > > Best regards, > Piotr Sikora > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org -- Mark Nottingham http://www.mnot.net/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and the APLN Patch
Hey Mark, ALPN support is already in the mainline: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f017a8f9db3a79f3a3406cf8d493ccd346db691 Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL and the APLN Patch
Hello OpenSSL, I'm wearing the hat of IETF HTTPbis Working Group Chair for the duration this message. We're currently developing HTTP/2.0: https://github.com/http2/http2-spec/ … and are starting to get initial implementations: https://github.com/http2/http2-spec/wiki/Implementations We have a dependency upon the TLS Working Group's ALPN specification: http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg … which has taken over for the previous NPN proposal: https://www.imperialviolet.org/2013/03/20/alpn.html Until APLN is more widely available, deploying HTTP2 for HTTPS URIs will not be possible, and developing it will be difficult. A patch for OpenSSL has been submitted: http://rt.openssl.org/Ticket/Display.html?id=3073 … but doesn't appear to have been discussed much yet. Could you give us any visibility into your intent for this patch? Note that if you have concerns / reservations about ALPN, they're best directed to the TLS Working Group. Regards, -- Mark Nottingham http://www.mnot.net/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3106] [PATCH] Fix build with OPENSSL_NO_NEXTPROTONEG.
Hello, attached patch fixes build with OPENSSL_NO_NEXTPROTONEG. While it cannot be enabled via ./config options, compiling OpenSSL with this define turned out to be extremely useful while adding ALPN support to 3rd-party software (i.e. to make sure that nothing in the added ALPN support relies on NPN code). Also, I wanted to make sure that SSL_select_next_proto() is not part of NPN and that it will be available going forward. Best regards, Piotr Sikora Fix-build-with-OPENSSL_NO_NEXTPROTONEG.patch Description: Binary data
