Re: [openssl-users] SSL_shutdown:shutdown while in init

[Jakob Bohm]

On 18/10/2017 11:14, Matt Caswell wrote:


On 17/10/17 21:27, Chris Bare wrote:

I have the following code:

setup_ssl (char *server_name, char *port, SSL_CTX *ctx)
{
     BIO *output = BIO_new_ssl_connect (ctx);
     if (!output)
     {
         return (NULL);
     }
     BIO_get_ssl (output, );
     SSL_set_mode (ssl, SSL_MODE_AUTO_RETRY);
     SSL_set_verify (ssl, true, NULL);
     BIO_set_conn_hostname (output, server_name);
     BIO_set_conn_port(output, port);

     if (BIO_do_connect (output) <= 0)
     {
         BIO_free (output);
         return (NULL);
     }
}

If the server I'm trying to connect to does not have ssl enabled, I get
the error:
SSL23_GET_SERVER_HELLO:unknown protocol
and BIO_do_connect fails as expected, but BIO_free gives this error:
SSL_shutdown:shutdown while in init

Hmmm...that looks like an OpenSSL bug to me. It should not call
SSL_shutdown() if we are still in init. I raised this issue:

https://github.com/openssl/openssl/issues/4545


From a more general usability perspective, it would be better if
SSL_shutdown() (starting from some version number) would always do
the right thing to properly and graciously end the SSL/TLS
connection, in any state where the connection object pointer is
valid at all.  That would probably imply taking completely
different actions during init and/or after shutdown has been
initiated by either end.

Then any complicated rules about when to call/not call SSL_shutdown()
could be relegated to a section about historical bugs in older
versions.


If I don't free it, I have a memory leak.
Is there something else I need to do to clean up the BIO?

As a workaround for this I think you can just ignore the error. From
code inspection it looks to me like it should go ahead and free
everything anyway.

Matt




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CRL signature verification

[Salz, Rich via openssl-users]

➢   I was more talking about the parsing. Currently I have 40 LOC [1] to

Look at X509_get1_ocsp which is in crypto/x509v3/v3_utl.c  That’s in 1.0.2 and 
later

➢ > X509_CRL_verify.  And yes, looking through to find the serial# is what you 
have to do.

➢ That's 1.1-specific, correct?

Yes.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CRL signature verification

[Wouter Verhelst]

Hi Rich,

On 18-10-17 17:46, Salz, Rich via openssl-users wrote:
> ➢ I used libcrypto to parse out the OCSP URL from the certificate validate
> it against a whitelist of valid OCSP URLs, send an OCSP request and
> validate the response and its signature against a custom certificate
> store, and then parse out the result.
> 
> Two points on that:
> ➢ - This seems like something that should be in libcrypto rather than in
> my own code. Did I miss something obvious?
> 
> We generally don’t do any kind of network traffic (except SSL) and would 
> rather leave that up to the application.  Especially because there are all 
> sorts of other frameworks, blocking issues, DNS, etc., that make things a 
> non-simple matter.

Sorry, I should have been clearer.

I didn't mean the HTTP requests etc. I agree that that should not be
done by libcrypto.

I was more talking about the parsing. Currently I have 40 LOC [1] to
find the OCSP URL from a certificate; it seems to me that that's a lot
of stuff that I shouldn't have to be doing, and that asking OpenSSL to
parse out that URL (or really, any other X.509v3 extension's data)
should not be too complicated.

Perhaps I missed the call that I should have been using, though ;-)

[1]
https://github.com/Fedict/eid-mw/blob/master/plugins_tools/eid-viewer/verify.c#L89-L129

> ➢ - Currently I don't fall back to CRLs when the OCSP server is
> unavailable. I would like to do so; however, I can't figure out how to
> validate the signature on a CRL (which would be a pretty obvious
> failure). Alternatively, is there an obvious alternative thing that I
> should be doing, rather than manually parsing the CRL?
>   
> X509_CRL_verify.  And yes, looking through to find the serial# is what you 
> have to do.

That's 1.1-specific, correct?

-- 
Wouter Verhelst
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Where is mttest.c?

[Richard Levitte]

In message <131801d34857$50fe15e0$f2fa41a0$@mcn.org> on Wed, 18 Oct 2017 
14:23:18 -0700, "Charles Mills"  said:

charlesm> Sorry – OpenSSL is not what I do every day.
charlesm> 
charlesm> I see in the man pages a reference to crypto/threads/mttest.c.

That's the 1.0.2 manpages, right?

charlesm> I’ve got the 1.1.0f tar and the crypto directory does not
charlesm> contain a threads directory. Where do I find mttest.c?

You don't.  It's been removed in 1.1.0, and as far as I can see, you
won't find any reference to mttest.c in the 1.1.0 docs...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users