Re: OpenSSL 1.1.1h not detecting expired certs
On Sun, 2020-11-01 at 11:16 -0500, Paul Smith wrote: > Does anyone have any ideas about what I might check to figure out > what's happening here? The release notes discuss enabling > MinProtocol and MaxProtocol; I do not use these and in fact I don't > invoke SSL_CONF_*() at all. Is this an issue? Should I do this? Hm. OK, I checked my code and I wasn't using SSL_CONF_*(), but I was using this after I created my SSL_CTX: _ctxt = SSL_CTX_new(TLS_method()); SSL_CTX_set_min_proto_version(_ctxt, TLS1_2_VERSION); Does that no longer work properly for some reason? If I replace the above with this: _ctxt = SSL_CTX_new(TLS_method()); SSL_CONF_CTX* cctxt = SSL_CONF_CTX_new(); SSL_CONF_CTX_set_ssl_ctx(cctxt, _ctxt); SSL_CONF_cmd(cctxt, "MinProtocol", "TLSv1.2"); Now it works. Is this a bug? Or was I just never using the interface properly? If I switch to the new method of configuration, it's not clear to me whether or not I need to preserve the SSL_CONF_CTX structure after the above code bit, as long as the SSL_CTX is there, or if I can free it immediately afterward. Based on the way it's used it seems like it only needs to exist as long as I need to configure the SSL_CTX, then it can go away and the SSL_CTX can live on.
OpenSSL 1.1.1h not detecting expired certs
I have a server linked (statically) with OpenSSL 1.1.1g (GNU/Linux, 64bit). I built everything myself, I'm not using any system libraries. I have a test in my test suite that constructs an expired self-signed cert and attempts to use it to connect to the server. When I link my server with OpenSSL 1.1.1g, it is detected properly and I see in the log (this is a construct of various openssl error info): SSL_accept failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired::0:SSL alert number 45 If I leave EVERYTHING the same about my environment and re-link the server with OpenSSL 1.1.1h instead (just re-linking the binaries with a new static libssl libcrypto), then this expired certificate is no longer detected by the server and the connection succeeds. To be sure I also tried recompiling with the 1.1.1h headers and see the same behavior. I can see that the expiration date is indeed wrong: $ openssl x509 -enddate -noout -in expired/trustStore.pem notAfter=Oct 27 15:58:50 2020 GMT but this is not noticed by my server. Does anyone have any ideas about what I might check to figure out what's happening here? The release notes discuss enabling MinProtocol and MaxProtocol; I do not use these and in fact I don't invoke SSL_CONF_*() at all. Is this an issue? Should I do this?
Re: Usage of Secure C (memcpy_s, strcpy_s etc) functions on OpenSSL
On Tue, 2019-11-26 at 23:47 +, Jordan Brown wrote: > Here's a paper on the subject: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm I love the fact that the "correct and safe" example they give in "Unnecessary Uses" is neither correct nor safe (it has a potential DOS due to memory leak). However I definitely do agree that the Appendix K functions are of marginal use _at best_... I don't use them or recommend them myself.
Re: Question: why doesn't my wildcard matching work with OpenSSL?
On Mon, 2019-06-10 at 15:14 -0400, Viktor Dukhovni wrote: > As a safety measure, OpenSSL does not support "*.tld" wildcards. > The non-wildcard portion of the domain name needs to have at > least two labels. It seems I've neglected to document this... :-( > > You can have "*.domain.example", but not "*.domain". I see, thanks, that's good info. We will try to figure out how to modify our Docker-based test configuration to use a multi-label domain name for its private network. I'm not sure how or if that will impact users, outside of our test environment. Is this something controlled by an option for X509_check_host() or is it just hardcoded and can't be modified? I didn't see any options in the docs that seem to manage that, unless it's a side-effect.
Re: Question: why doesn't my wildcard matching work with OpenSSL?
On Mon, 2019-06-10 at 20:12 +, Michael Wojcik wrote: > > What I cut out was only the base64-encoded certificate. > > Yes. That was what we needed to see. The certificate. Yep, that's my bad. Thanks for the reminder. > As it turns out, you're hitting the OpenSSL restriction on wildcards > with fewer than two domain components, as Viktor explained. I'd > forgotten about that restriction. > > However, I still recommend using a proper X.509v3 server certificate > with one or more SANs. If you're running your own CA using the > openssl utiltity, there are various online tutorials showing how to > generate modern certificates. Just to be clear, this is being seen in our docker-based test environment using a virtual network and the docker resolvers, where we're creating our own certificates so we can easily do both positive and negative testing with things like good/bad hostnames, expired certificates, incorrect chains, testing key rotation, etc. etc. Our Java and Python clients work fine, but the C/C++ clients were failing. These certificates aren't being used "for real". I'll look into enhancing our test environment to address this. Cheers!
Re: Question: why doesn't my wildcard matching work with OpenSSL?
On Mon, 2019-06-10 at 14:23 -0400, Viktor Dukhovni wrote: > > $ openssl s_client -connect admin0.domain:8004 \ > > -CAfile ca.cert -verify_hostname admin0.domain > > > > --- > > Verify return code: 62 (Hostname mismatch) > > It seems that you've elided too much information. Is the hostname > really "admin0.domain", or is there some underlying domain name > that you've obfuscated? I tried not to elide anything other than a lot of keys and stuff. Maybe that info isn't output? That is actually the hostname (I have this running in a Docker container to get the hostname set up without a lot of hassle). But maybe that's my confusion. What "hostname" is OpenSSL looking at? I told it the name I wanted it to use for the verify on the command line: "-verify_hostname admin0.domain", which matches the wildcard the certificate provides. That appears to be what the docs say; from verify(1ssl): -verify_hostname hostname Verify if the hostname matches DNS name in Subject Alternative Name or Common Name in the subject certificate. I thought that's all it used: this value plus the wildcard in the certificate. Am I misunderstanding this? Where else will openssl go looking for hostnames to match? Note that if I don't use wildcards but instead have a full hostname in the certificate, then verify hostname does work. It's only using a wildcard that doesn't match the way I thought it would. Thanks for the reply!
Question: why doesn't my wildcard matching work with OpenSSL?
I'm having problems trying to get wildcard matching working with OpenSSL. Full hostname matching is working fine, but when my certification uses a wildcard I always get an error. That includes both with OpenSSL 1.1.1b linked into my normal client, AND with the openssl CLI with a system default version. However, trying to use this same certificate and hostname matching works fine with Java and Python clients. Note for my C client I have not set any special flags for matching, I'm just using the default and using SSL_set1_host() to add the hostname. But, I can't even get it to work with openssl itself. I feel like I must be missing something dumb. Any pointers appreciated! For example, here's a connection attempt using the CLI... note if I remove the -verify_hostname option the connection works fine: $ openssl s_client -connect admin0.domain:8004 \ -CAfile ca.cert -verify_hostname admin0.domain CONNECTED(0003) depth=1 C = US, ST = MA, L = Boston, O = Mycorp, OU = Eng, CN = ca.mycorp.com verify return:1 depth=0 CN = *.domain verify return:1 --- Certificate chain 0 s:/CN=*.domain i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com 1 s:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com --- Server certificate -BEGIN CERTIFICATE- ... -END CERTIFICATE- subject=/CN=*.domain issuer=/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com --- Acceptable client certificate CA names /C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=nuocmd.mycorp.com /C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: ... Shared Requested Signature Algorithms: ... Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits ... --- SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Session-ID: ... Session-ID-ctx: Master-Key: ... Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1560181877 Timeout : 300 (sec) Verify return code: 62 (Hostname mismatch)
Shutdown examples/explanations
Does anyone have a straightforward example of the canonical way to handle SSL_shutdown() in OpenSSL 1.1.1? I mean both when my code is the initiator of the shutdown and also when I'm the peer, and also for both blocking and non-blocking BIOs? I've read and re-read the SSL_shutdown() man page and it seems to me that there's a lot of conflicting content there. It says you can call SSL_shutdown() twice, and it also says "However, it is recommended to wait for it using SSL_read() instead". It says "It is not possible to call SSL_write() after calling SSL_shutdown()", but it also says that for non-blocking BIOs, we might get an SSL_ERROR_WANT_WRITE and the calling process "must take appropriate action to satisfy the needs of SSL_shutdown()"... what "appropriate action" is is not clearly specified but I assume it means invoke SSL_write(). Under RETURN VALUES <0 it says the shutdown was not successful, but then says we can get this if an action is needed to continue the operation for non-blocking BIOs... by "continue the operation" does that mean call SSL_read() again? If so what's the difference in behavior of my code between SSL_shutdown() returning 0 or <0? I just wish the docs would say what the recommended best practices are in a clear way, rather than offering lots of not-very-clear alternatives, or that there was example code somewhere of how the OpenSSL devs designed this to be handled. Also as a separate question, if I'm always going to be closing my socket once the shutdown is complete is there any advantage in worrying about bi-directional shutdown, versus simply calling SSL_shutdown(), ignoring the return value, and closing the socket? I would like my code to be a good neighbor and play nicely with others but if it doesn't matter I guess I could side-step all the above confusion and simply get out. Let me also assume that the peer may not be reading the socket constantly. For example suppose the peer is an interactive shell of some kind and it's sitting at a prompt waiting for user input and not invoking SSL_read() etc. Is it possible to ever complete a bi- directional handshake shutdown with that peer anyway? If we need to wait for it to reply I don't see how.
Re: Is there a way to retrieve the certificate from SSL_CTX?
On Tue, 2019-03-05 at 11:28 -0800, Wim Lewis wrote: > On 5. mar. 2019, at 10:14 f.h., Paul Smith > wrote: > > E.g., I'm adding my certificate with SSL_CTX_use_certificate(); is > > there a way to get it back out? > > Does SSL_CTX_get0_certificate() do what you need? AHA! That seems to do the trick. If only it were discussed in a man page [0], I might have found it... :) Thanks Wim! [0] After you pointed me to it I did find it listed in the ssl(7) man page, but no info on it.
Is there a way to retrieve the certificate from SSL_CTX?
I'm trying to write a simple function to dump the expiration date of the certificates in my SSL_CTX cert store. I've managed to retrieve and show the CA certificates from the certificate store, and the certificate chain, but I can't find a method that retrieves the certificate itself from SSL_CTX. Is this something that is retrievable? E.g., I'm adding my certificate with SSL_CTX_use_certificate(); is there a way to get it back out?
Re: Online docs have broken links
On Fri, 2019-03-01 at 23:58 +0100, Richard Levitte wrote: > The problem isn't a lack of test_docs, the issue lies in how we > organised the manuals before (in an apps, a crypto and a ssl > directory), and the script that builds up these pages haven't been > updated to prefix properly per actual man section. > > There's a PR that I think fixes the problem: > https://github.com/openssl/web/pull/124 Thanks for looking into this issue. I had another request: can you adjust the title of the pages? Currently the titles look like this: /docs/man1.1.1/man3/SSL_accept.html This can be frustrating when I have a bunch of SSL docs open in tabs in my browser; the tab titles are all truncated to just "/docs/man..." or whatever will fit. I would prefer the title to be something like: SSL_accept(3) If you would like to keep the version in the title maybe it could be added after the name, something like: SSL_accept(3) [1.1.1] or similar. Cheers!
OpenSSL 3.0 (or 4.0) API goals
Hi all. I'm reading with interest the details coming out with respect to the next release of OpenSSL. I'm curious if there's any consideration being given to updating the API for existing interfaces, and/or checking the APIs of any new interfaces for issues that are seen in the current API. I'm talking about things like: * Const-correctness for arguments * Signed vs. unsigned values for integer values * Avoiding non-portable types in the API (the most obvious example: using "int" as the type for socket descriptors, which is only portable to Windows due to an implementation detail). * Possibly using something like uint8_t* for pointers to buffers containing binary "stuff" (this could be more annoying than helpful, requiring a lot of casting, so I'm not sure about that). Just wondering... seems like a good time to think about cleanups like that, if feasible.
Online docs have broken links
Not sure if anyone is aware or not, but many of the man pages on the openssl.org site contain broken links. Basically anywhere a man page refers to a man page in a different section, the link is broken because it uses the same section. So for example: https://www.openssl.org/docs/man1.1.1/man7/ssl.html is in section 7, but it refers to functions in section 3... however all the links are broken because they still point to section 7. See the link in the second paragraph of the description to SSL_CTX_NEW, which has this HTML linkage: SSL_CTX_new which does not exist; this should be .../man3/SSL_CTX_new.html instead. I've found other links in the man3 section which want to refer to this "ssl" page, and look for it in section 3 instead of section 7, also broken. Cheers!
[openssl-users] Multiplexing TLS / non-TLS connections on a single socket
Hi all. We have a service that currently implements a home-grown secure connection model based on SRP using AES as the cipher. We want to add support for TLS 1.2/1.3 as well, but we have to maintain backward- compatibility. Our app is in C++ and using OpenSSL 1.1.1. We really don't want to create a separate socket: we'd like to support client requests on the same socket using either the old connection method or TLS. We also want to support "pure" TLS, rather than some kind of wrapped connection protocol. This means we need to determine at connect time which method is being used. One idea is to use MSG_PEEK on the socket recv() to check the first bytes of the initial message (our protocol uses an XML message as the initial connection so seeing something like "https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] EVP_DecryptUpdate: why is this failing when out == in?
I filed https://github.com/openssl/openssl/issues/7941 about this FYI.
Cheers!
On Wed, 2018-12-19 at 01:56 -0500, Paul Smith wrote:
> As I understand it, it's legal to provide the exact same input and
> output buffer to EVP_EncryptUpdate and EVP_DecryptUpdate, but it's not
> legal to provide pointers into different parts of the same buffer.
> That's a good check.
>
> However, my implementation is getting triggered by this code in
> EVP_DecryptUpdate():
>
> if (ctx->final_used) {
> /* see comment about PTRDIFF_T comparison above */
> => if (((PTRDIFF_T)out == (PTRDIFF_T)in)
> || is_partially_overlapping(out, in, b)) {
> EVPerr(EVP_F_EVP_DECRYPTUPDATE, EVP_R_PARTIALLY_OVERLAPPING);
> return 0;
> }
>
> Can someone explain why, only in this specific situation where we're
> decrypting the final block, we require that OUT and IN not be the same
> buffer? Everywhere else we check is_partially_overlapping() only,
> without equality.
>
> I read the comment about PTRDIFF_T but I didn't come up with a reason
> for the equality check. This check was added back in 2016 in SHA
> 5fc77684f1 FWIW.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Two questions on OpenSSL EVP API
On Wed, 2018-12-19 at 08:57 +0300, Dmitry Belyavsky wrote: > > I would have thought that the true maximum would be round-up(inl, > > cipher_block_size); that is, for inl values 1-15 you'd get 16 > > bytes, and for inl values 16-31 you'd get 32 bytes, etc. (I'm not > > actually sure whether inl of 16 gets you 16 or 32 bytes...) > > > > Am I wrong about that? Would some ciphers/modes write beyond the > > end of the current "block" and into the next one? > > When you use a block cipher and pass data less than block size, it is > stored in the internal buffer. In this case you do not get encrypted > data until there is enough plain text to encrypt the full block. > > When you add more data, if you pass enough data to finalize a > previously unfinished block, you get more long ciphertext than > plaintext passed in a particular call of CipherUpdate. I see. So you potentially need enough for an almost full previous block, plus the current data. That makes sense. Thanks! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] EVP_DecryptUpdate: why is this failing when out == in?
As I understand it, it's legal to provide the exact same input and
output buffer to EVP_EncryptUpdate and EVP_DecryptUpdate, but it's not
legal to provide pointers into different parts of the same buffer.
That's a good check.
However, my implementation is getting triggered by this code in
EVP_DecryptUpdate():
if (ctx->final_used) {
/* see comment about PTRDIFF_T comparison above */
=> if (((PTRDIFF_T)out == (PTRDIFF_T)in)
|| is_partially_overlapping(out, in, b)) {
EVPerr(EVP_F_EVP_DECRYPTUPDATE, EVP_R_PARTIALLY_OVERLAPPING);
return 0;
}
Can someone explain why, only in this specific situation where we're
decrypting the final block, we require that OUT and IN not be the same
buffer? Everywhere else we check is_partially_overlapping() only,
without equality.
I read the comment about PTRDIFF_T but I didn't come up with a reason
for the equality check. This check was added back in 2016 in SHA
5fc77684f1 FWIW.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Two questions on OpenSSL EVP API
Hi all; I'm working with OpenSSL 1.1.1a, using the EVP interface to encrypt/decrypt with various ciphers/modes. I had a couple of questions: First, the encrypt update docs say: > the amount of data written may be anything from zero bytes to > (inl + cipher_block_size - 1) Is that really true? For example if my block size is 16 and my input length is 4, could the encrypt step really write as many as 19 bytes (4 + 16 - 1)? I would have thought that the true maximum would be round-up(inl, cipher_block_size); that is, for inl values 1-15 you'd get 16 bytes, and for inl values 16-31 you'd get 32 bytes, etc. (I'm not actually sure whether inl of 16 gets you 16 or 32 bytes...) Am I wrong about that? Would some ciphers/modes write beyond the end of the current "block" and into the next one? Second, the type of the outl parameter on EVP encrypt update is "int", rather than (as I would have expected) "unsigned int". Is there a possibility that EVP would set &outl to a negative value and if so, what would that mean? Do I need to check for this in my code? Same with inl; why isn't it "unsigned int"? Is there ever a reason to pass in a negative value? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
