Re: liblegacy.a does not work unless compiled with -static
On Sat, May 2, 2020 at 12:31 AM Richard Levitte wrote: > No. When DSO support is turned off, the legacy provider code becomes > part of libcrypto, in an inaccessible state (in other words, you still > have to "load" it). Using OSSL_PROVIDER_load(NULL, "legacy")? My first try after a static only build (and delete of all .so files) got an error from that, but if its the correct way, I'll investigate more. Sam
Re: liblegacy.a does not work unless compiled with -static
On Fri, May 1, 2020 at 10:22 AM Salz, Rich via openssl-users wrote: > Hm, so DSO support is a requirement for legacy crypto now? That probably > needs to be made explicit, and see if the project gets pushback. It would mean legacy alg support would not exist for Node.js binary distributions, but I'm still figuring out how many legacy algs we support. How hard we'd push back on that would depend on how hard our users push back... but we won't know that until ossl3 makes it into a new major of node, probably spring 2021, when it might be too late to change anything.
Re: OpenSSL version 3.0.0-alpha1 published
On Thu, Apr 30, 2020 at 9:27 PM Richard Levitte wrote: > Yes, running from the DESTDIR "installation" gets you into trouble. > DESTDIR is intended to be a staging directory, i.e. a place to put Fair enough, I don't have to use DESTDIR, I configure with openssldir and prefix set to a sandbox now. We statically link openssl to get a self-contained binary. I'm not sure if --no-shared was sufficient to "build in" the legacy algs. Provider load failed, reasonably expectedly, but whether our test suite is failing because of missing legacy won't be clear to me until more of the superficial failures are fixed. Is there a reason two terms, "modules" and "providers", are both used? Are there modules that are NOT providers? It is confusing to use different names to describe the same thing, so if modules are providers, perhaps one name could be used consistently.
Re: OpenSSL version 3.0.0-alpha1 published
On Fri, Apr 24, 2020 at 9:07 AM Nicola Tuveri wrote:
> At https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers there was already
> an example of how to do this programmatically, and a link to the manpage for
> the config file syntax.
That's not working for me:
Failed to load Legacy provider: error:2567:DSO support
routines::could not load the shared library
/home/sam/w/core/tls/./node[26693]: ../../src/node_crypto.cc:6804:void
node::crypto::InitCryptoOnce(): Assertion `"Unreachable code reached"'
failed.
1: 0x557630598d84 node::Abort() [/home/sam/w/core/tls/./node]
From:
/* Load Multiple providers into the default (NULL) library context */
auto legacy = OSSL_PROVIDER_load(0, "legacy");
if (legacy == nullptr) {
unsigned long err = ERR_get_error();
fprintf(stderr, "Failed to load Legacy provider: %s\n",
ERR_error_string(err, nullptr));
UNREACHABLE();
}
auto deflt = OSSL_PROVIDER_load(0, "default");
if (deflt == nullptr) {
unsigned long err = ERR_get_error();
fprintf(stderr, "Failed to load Default provider: %s\n",
ERR_error_string(err, nullptr));
OSSL_PROVIDER_unload(legacy);
UNREACHABLE();
}
I notice that the legacy.so isn't in the same folder as the other .so
files, so I tried:
LD_LIBRARY_PATH=/usr/local/stow/openssl-3.0.0-alpha1/lib:/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules
But that didn't work.
It looks like adding this did work:
OSSL_PROVIDER_set_default_search_path(0,
"/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules");
What are the default values? I built with prefix set to /usr/local,
but then installed to the DESTDIR directory above, is that what caused
me trouble?
Cheers,
Sam
> I just added also a minimal config file example to load both the default and
> the legacy provider in the default library context.
>
>
> Cheers,
>
> Nicola
>
> On Fri, 24 Apr 2020 at 17:56, Sam Roberts wrote:
>>
>> On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell wrote:
>> > This one is interesting:
>> >
>> > ERR_OSSL_EVP_FETCH_FAILED
>> >
>> >
>> > This means that the algorithm you are trying to use isn't available in
>> > the loaded providers. Since you should be getting the default provider
>> > loaded automatically it could be because some legacy algorithms were
>> > moved to the legacy provider (MD2, MD4, MDC2, RMD160, CAST5, BF
>> > (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES)). If you're
>> > using something from that list then that would explain it.
>>
>> Can we add the legacy provider, via configuration, or via code?
website changelog didn't get updated for 1.1.1 f and g
https://www.openssl.org/news/changelog.html#openssl-111 ^--- missing the last two patch releases. Cheers, Sam
Re: OpenSSL version 3.0.0-alpha1 published
On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell wrote: > This one is interesting: > > ERR_OSSL_EVP_FETCH_FAILED > > > This means that the algorithm you are trying to use isn't available in > the loaded providers. Since you should be getting the default provider > loaded automatically it could be because some legacy algorithms were > moved to the legacy provider (MD2, MD4, MDC2, RMD160, CAST5, BF > (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES)). If you're > using something from that list then that would explain it. Can we add the legacy provider, via configuration, or via code?
Re: OpenSSL version 3.0.0-alpha1 published
Fwiw, took a quick run at building and testing Node.js against the 3.x beta. It was API compatible enough to build. The DH_, ECDH_, HMAC_, etc. deprecations make sense, will look at those. My assumption is that EVP versions of these exist in openssl 1.1.1, and that if we switch our openssl 1.1.1 code to using the EVP APIs, that that cod will then work unchanged when we update to openssl 3.x? ERR_func_error_string, what is its replacement? I didn't see it mentioned in the wiki, but its marked deprecated. Tests didn't go so well. Minor changes in error strings are to be expected, but more than that changed. I haven't looked at these yet other than scan the output, we might be relying on internals, but just for anyone curious, here's the test output: https://gist.github.com/sam-github/5a3b3775029efb3d31109d7e6e390f85
Re: OpenSSL version 3.0.0-alpha1 published
Resending to -users. On Thu, Apr 23, 2020 at 9:58 AM Sam Roberts wrote: > > Seems to be something wrong with the way config is generating the > version strings: > gcc -Icrypto -I. -Iinclude -Iproviders/common/include > -Iproviders/implementations/include -Icrypto/include -DAES_ASM > -DBSAES_ASM -DCMLL_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM > -DMD5_ASM -DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 > -DPOLY1305_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM > -DWHIRLPOOL_ASM -DX25519_ASM -fPIC -pthread -m64 -Wa,--noexecstack > -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_BUILDING_OPENSSL > -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/local/ssl\"" > -DENGINESDIR="\"/usr/local/lib/engines-3\"" > -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG -MMD -MF > crypto/libcrypto-lib-cversion.d.tmp -MT > crypto/libcrypto-lib-cversion.o -c -o crypto/libcrypto-lib-cversion.o > crypto/cversion.c > In file included from include/openssl/macros.h:11, > from include/openssl/opensslconf.h:14, > from include/openssl/macros.h:10, > from include/openssl/crypto.h:15, > from include/internal/cryptlib.h:23, > from crypto/cversion.c:10: > crypto/cversion.c: In function 'OpenSSL_version': > include/openssl/opensslv.h:91:54: error: expected ';' before numeric constant >91 | # define OPENSSL_VERSION_TEXT "OpenSSL 3.0.0-alpha1 "23 Apr 2020"" > | ^~ > crypto/cversion.c:50:16: note: in expansion of macro 'OPENSSL_VERSION_TEXT' >50 | return OPENSSL_VERSION_TEXT; > |^~~~ > make[1]: *** [Makefile:15616: crypto/libcrypto-lib-cversion.o] Error 1 > make[1]: Leaving directory '/home/sam/s/openssl-3.0.0-alpha1' > make: *** [Makefile:3009: build_sw] Error 2 > > > I'm on Linux, just did a `./config; make`. > > Its fairly obvious what the string should have been, I edited and am > continuing with the build. > > > On Thu, Apr 23, 2020 at 7:29 AM OpenSSL wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > > >OpenSSL version 3.0 alpha 1 released > > > > > >OpenSSL - The Open Source toolkit for SSL/TLS > >https://www.openssl.org/ > > > >OpenSSL 3.0 is currently in alpha. > > > >OpenSSL 3.0 alpha 1 has now been made available. > > > >Note: This OpenSSL pre-release has been provided for testing ONLY. > >It should NOT be used for security critical purposes. > > > >Specific notes on upgrading to OpenSSL 3.0 from previous versions, as > > well > >as known issues are available on the OpenSSL Wiki, here: > > > > https://wiki.openssl.org/index.php/OpenSSL_3.0 > > > >The alpha release is available for download via HTTPS and FTP from the > >following master locations (you can find the various FTP mirrors under > >https://www.openssl.org/source/mirror.html): > > > > * https://www.openssl.org/source/ > > * ftp://ftp.openssl.org/source/ > > > >The distribution file name is: > > > > o openssl-3.0.0-alpha1.tar.gz > > Size: 9530120 > > SHA1 checksum: 4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06 > > SHA256 checksum: > > 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57 > > > >The checksums were calculated using the following commands: > > > > openssl sha1 openssl-3.0.0-alpha1.tar.gz > > openssl sha256 openssl-3.0.0-alpha1.tar.gz > > > >Please download and check this $LABEL release as soon as possible. > >To report a bug, open an issue on GitHub: > > > > https://github.com/openssl/openssl/issues > > > >Please check the release notes and mailing lists to avoid duplicate > >reports of known issues. (Of course, the source is also available > >on GitHub.) > > > >Yours, > > > >The OpenSSL Project Team. > > > > -BEGIN PGP SIGNATURE- > > > > iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6hpQcACgkQ2cTSbQ5g > > RJHvtggAp7XIxm/00amD4TijQhJqMmGsj0RXqwAeSd0gWDQCf78GX4zMIW/tTgvk > > I3Mb67DsOR5gdPZN5TigyqRaXSIAzfb8ZT4Gs9lo/j8RUi5AmzT2RYexbRv6bF6E > > cQ0OabM3rk4qi4njTi/YD9YihO6/pv7tWZkkfPsN547bfm7p7fwCrEHw02En5IW8 > > hyFhkpKfA3c8MEa96yLwjhkYRTAzUmxus/mNID+Ja3/VTCmHjd1c57SHFPq9noll > > Wqzhs3jEhluZKHpwmSSA0KQh1ph0kh6fnKLEn3Oge5dYV3P+JrFCRfDEMsI1Nb/F > > hIr11rxXNxtBRKUSlOUyJATZn0sV6g== > > =uRpM > > -END PGP SIGNATURE-
Re: OpenSSL Security Advisory
That makes sense, thank you all.
Re: OpenSSL Security Advisory
The announcement claims that this affects SSL_check_chain(). Is that an exhaustive list? If an application does NOT call that function, does this mean the vulnerability is not exploitable? I ask because the the fixed function tls1_check_sig_alg is called by tls1_check_chain, and that is called directly by SSL_check_chain, but it is also called by tls1_set_cert_validity, and that is called from inside the tls state machine, but with different parameters, so its a bit hard to see if it is affected or not. Thanks, Sam On Tue, Apr 21, 2020 at 6:26 AM OpenSSL wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > OpenSSL Security Advisory [21 April 2020] > = > > Segmentation fault in SSL_check_chain (CVE-2020-1967) > = > > Severity: High > > Server or client applications that call the SSL_check_chain() function during > or > after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a > result of incorrect handling of the "signature_algorithms_cert" TLS extension. > The crash occurs if an invalid or unrecognised signature algorithm is received > from the peer. This could be exploited by a malicious peer in a Denial of > Service attack. > > OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This > issue did not affect OpenSSL versions prior to 1.1.1d. > > Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g > > This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April > 2020. It was found using the new static analysis pass being implemented in > GCC, > - -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin > Kaduk. > > Note > = > > This issue did not affect OpenSSL 1.0.2 however these versions are out of > support and no longer receiving public updates. Extended support is available > for premium support customers: https://www.openssl.org/support/contracts.html > > This issue did not affect OpenSSL 1.1.0 however these versions are out of > support and no longer receiving updates. > > Users of these versions should upgrade to OpenSSL 1.1.1. > > References > == > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20200421.txt > > Note: the online version of the advisory may be updated with additional > details > over time. > > For details of OpenSSL severity classifications please see: > https://www.openssl.org/policies/secpolicy.html > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e8uwACgkQ2cTSbQ5g > RJHHRgf+J8iVBuK6EoOvf9xm9geiDgYVFse9ckMXH92gdGbwsW4uhTNk9fCyNC+t > vsf6YGT6nKJarB5+N+LC4QB7VLo/DjlYcN9zP3mubV0eEyKHSoW6tDOWPpJ0gsbt > 2Z9iTA4GnofvhBcWLiPGgv4IUHknsOaPkRmEppSF0fDTSKuYOerfNRh9jTKHulis > Ph6dCOXE3kb5HfMwVj3UN2sP92XTig4FzpIQaZ1/2jKZaRXtzJD7pvu1fDCTkUGl > aeta5jHNypYyRKJLuJ1+1DiBtbWTFAWMUCHlkg/kgdU4hIl/lo3vgAyFs/9mQxZQ > vj2rIjoJHRj0EXqXhHoABqBHedilJQ== > =AXyP > -END PGP SIGNATURE-
Re: Forthcoming OpenSSL release
Will it include ONLY the CVE fix, or will it include other fixes, such as to the getrandom() call on some archs? commit 4dcb150ea30f9bbfa7946e6b39c30a86aca5ed02 Author: Kurt Roeckx Date: Sat Sep 28 14:59:32 2019 +0200 Add defines for __NR_getrandom for all Linux architectures Fixes: https://github.com/openssl/openssl/issues/10015 Reviewed-by: Bernd Edlinger GH: https://github.com/openssl/openssl/pull/10044 See https://github.com/nodejs/node/pull/32002 for background. On Wed, Mar 11, 2020 at 8:53 AM Matt Caswell wrote: > > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL version 1.1.1e. > > This release will be made available on Tuesday 17th March 2020 between > 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551 > previously announced here: > https://www.openssl.org/news/secadv/20191206.txt > > Please see the following page for further details of severity levels: > https://www.openssl.org/policies/secpolicy.html > > Yours > > The OpenSSL Project Team
Re: OpenSSL 3.0
On Wed, Feb 26, 2020 at 11:44 AM Salz, Rich wrote: > > The 3.0 release is a work in progress and is not done yet. > > FIPS 3.0 === OpenSSL 3.0, using a FIPS-validated crypto provider which will > be part of OpenSSL 3.0. > > The architecture documents are at https://www.openssl.org/docs Rich, I've seen all that, Matt says > alpha1, 2020-03-31: Basic functionality plus basic FIPS module That's 5 weeks from now, I'd thought the basic structure might be present now. I'm willing to start some testing now to give early feedback, and to get a sense of what will involved in porting Node.js. If asking for information is too distracting, no problem, I'll wait another month for the alpha and hope it contains some info on how to do this: > using a FIPS-validated crypto provider Cheers, Sam
Re: OpenSSL 3.0
On Wed, Feb 26, 2020 at 8:36 AM Salz, Rich wrote: > > >I'd like to give this a spin, to get an idea what's going to be > involved in porting from FIPS2.0 to 3.0, any pointers on where to > start? > > Per the blog post, "most applications should just need to be recompiled." :) > > Get the source via instructions here: https://www.openssl.org/source/ I want to build against ***FIPS3.0***. I don't find any routes to FIPS3.0 in the above link. We've already ported to openssl 1.1.1, so the non-FIPS APIs should be fine when compiled against openssl-3.0 (the promise was API compatible). My expectations based on the blog posts and arch/design docs is the FIPS3.0 will be an OpenSSL 3.0 provider, and I am guessing it will be necessary, somehow?, to tell OpenSSL which provider to use, either programmatically or via openssl.cfg? Or maybe I'm off track, and its a configure mode, and the provider will be hard-coded in if openssl-3.0 is built with FIPS? But again, how to do that? I've spent some time poking around in the source and git logs, and (again, could have missed it), I didn't see any FIPS specific doc changes or hints as what to do for FIPS3.0, and it wasn't clear where to start. Sam
Re: OpenSSL 3.0
On Tue, Feb 25, 2020 at 8:00 PM Matt Caswell wrote: > alpha1, 2020-03-31: Basic functionality plus basic FIPS module I'd like to give this a spin, to get an idea what's going to be involved in porting from FIPS2.0 to 3.0, any pointers on where to start? Sam
Re: Can a linux service work as both TLS client and server?
I'm curious, its pretty unusual to not know which side of a TCP connection is the client or server, not just TLS, HTTP, SMTP, etc. Its almost always the side that makes the accept() call that's the server, but that doesn't have to be. Why is it that you do not in this context? Without it, you are fairly far off the beaten path. A normal TLS client would not be able to connect to your "accept()" side if it tried to be a client, and a normal TLS server would never initiate a connection to your "accept()" in the hopes that the acceptor would turn around and be a client. The 1/0 isn't so terrible (well, maybe the protocol is terrible :-). To do a custom negotiation, then "step up" to TLS is done by other protocols. You could also sniff the TCP after accept, and wait a while to see if a client hello arrives to know if the other side is a client (or wait for any data, I don't think a server starts sending data until it gets something, but its been a while since I looked). Hope thats helpful, and even if not, it'd be interesting to know what apple is doing that is pushing you down this path. Sam
any subtleties about OCSP in TLS1.3 with ecdh curves?
Node.js has a bug report and repro of ocsp status not being sent from a node server to the openssl CLI when TLS1.3 is being used, but only when server is setting an ecdh curve, with SSL_CTX_set1_curves_list() repro is https://github.com/sam-github/node-ocsp-bug-repro TLS trace of success is https://github.com/sam-github/node-ocsp-bug-repro/blob/master/ok.txt, and of failure is https://github.com/sam-github/node-ocsp-bug-repro/blob/master/notok.txt I hacked up node a bit, and it does look like in both cases the same API interactions between node and openssl are ocurring, at least with respect to the cb from SSL_set_cert_cb() is happening, after which time we save some data, and then we call SSL_set_tlsext_status_ocsp_resp() with that data. AFAICT, with SSL_CTX_set1_curves_list() called, the ocsp data never shows up in the server response. I'm not sure what to look at next, does anybody have ideas? Thanks, Sam
Re: Calling EVP_DigestFinal_ex multiple times
On Mon, Jun 17, 2019 at 2:07 AM Matt Caswell wrote: > On 15/06/2019 15:08, Tobias Nießen wrote: > > I am wondering whether it is permitted to call EVP_DigestFinal_ex multiple > > times on the same context in order to retrieve the same digest twice. I > > expected OpenSSL to fail with an error code, but SHA256 seems to permit it > > whereas SHA3 seems to cause a segmentation fault. The documentation does not > > explicitely forbid or allow it, so I am wondering where this should be > > addressed: In the implementation of EVP_*, in SHA2, in SHA3, in the > > documentation, or not at all? > > I believe this should not be allowed. Probably this is a documentation issue. Just a doc issue? Shouldn't the SHAs behave more uniformly? Also, is segfaulting a reasonable result of this kind of API use, calling an API twice? Segving on bad memory is unavoidable, but calling an API twice sounds detectable. Cheers, Sam
Re: OpenSSL server sending certificate chain(inc. root cert) during handshake
The root cert is not used for validation, so it doesn't have to be sent. However, sending it does no harm, and it is useful for humans who are attempting to diagnose problems, it allows them to see what what root cert they are expected to have locally for sucessful cert chain validation.
Re: Why were edwards curves given distinct key types, aren't they EC keys?
That helps a lot, thanks.
On Sat, Mar 16, 2019 at 8:05 AM Nicola wrote:
>
> Well, they just don't have their individual type either: they are just
> `EVP_PKEY`s, with `EVP_PKEY` being the top level API in libcrypto for
> public key cryptography.
> The difference with `RSA_KEY`, `DSA_KEY`, `EC_KEY` (that can be
> encapsulated in a generic `EVP_PKEY` object) is that Ed* keys don't
> share a common module (apart from reusing common functions for parts
> of the ASN1 encoding/decoding).
> RSA, DSA and EC in libcrypto are submodules on their own, with a
> dedicated `{RSA,DSA,EC}_*` API, in part for legacy reasons. By the
> time X25519, Ed25519 and *448 were added, the new direction in the
> project was to minimise the size of the public API and recommend the
> use of the unified EVP API, so it did not make any sense to have a
> separate submodule with its own data types and API.
>
> This is of course to the best of my knowledge and mostly based on
> guesses, as I was not actively contributing to the project while some
> of these decisions were made, and I don't have the same insight on the
> history of the design of the library as other project members.
>
> BR,
>
> Nicola
>
> On Sat, Mar 16, 2019, 17:00 Sam Roberts wrote:
>>
>> That helps a lot, I can see why they are different enough from EC key
>> types to be distinct.
>>
>> It still leaves me wondering whe two edwards curves have key types
>> distinct from each other? Why aren't they both EVP_PKEY_ED? (or
>> something of the like)
>>
>> Cheers,
>> Sam
Re: Why were edwards curves given distinct key types, aren't they EC keys?
That helps a lot, I can see why they are different enough from EC key types to be distinct. It still leaves me wondering whe two edwards curves have key types distinct from each other? Why aren't they both EVP_PKEY_ED? (or something of the like) Cheers, Sam
Why were edwards curves given distinct key types, aren't they EC keys?
It seems like they are EC keys, with specific curve designs, and that also have some algorithms designed specifically for them, like EdDSA -- though it looks like that alg is being generalized to other curve types (https://tools.ietf.org/html/rfc8032#ref-EDDSA2). What about them makes it necessary to make them distinct, both from each other, and EVP_PKEY_EC? Thanks, Sam
Re: Online docs have broken links
I ran linklint on the output of `make install_html_docs`, and there are a fair amount of refs to non-existent pages as well. Maybe its worth adding a `test-docs` target? Would PRs to fix the below be welcomed? # # ERROR 18 missing html files (cross referenced) # /../man1/version.html used in 1 file: /man3/CTLOG_STORE_new.html /../man3/EVP_EncryptInit.html used in 1 file: /man3/EVP_CIPHER_meth_new.html /../man3/OSSL_STORE_SEARCH.html used in 3 files: /man3/OSSL_STORE_expect.html /man3/OSSL_STORE_find.html /man3/OSSL_STORE_supports_search.html /../man3/SSL_CTX_set_security_level.html used in 2 files: /man1/ciphers.html /man1/openssl-ciphers.html /../man7/bio.html used in 4 files: /man3/BIO_pop.html /man3/BIO_push.html /man3/BIO_should_retry.html /man3/SCT_print.html /man1/curl.html used in 2 files: /man1/openssl-tsget.html /man1/tsget.html /man1/perl.html used in 2 files: /man1/openssl-ts.html /man1/ts.html /man1/procmail.html used in 2 files: /man1/openssl-ts.html /man1/ts.html /man3/EVP_MD_CTX_set_ctx.html used in 2 files: /man3/EVP_DigestSignInit.html /man3/EVP_DigestVerifyInit.html /man3/EVP_bf.html used in 5 files: /man3/EVP_CIPHER_CTX_reset.html /man3/EVP_DecryptInit.html /man3/EVP_DecryptInit_ex.html /man3/EVP_EncryptInit.html /man3/EVP_EncryptInit_ex.html /man3/EVP_cast5.html used in 5 files: /man3/EVP_CIPHER_CTX_reset.html /man3/EVP_DecryptInit.html /man3/EVP_DecryptInit_ex.html /man3/EVP_EncryptInit.html /man3/EVP_EncryptInit_ex.html /man3/EVP_desx.html used in 5 files: /man3/EVP_CIPHER_CTX_reset.html /man3/EVP_DecryptInit.html /man3/EVP_DecryptInit_ex.html /man3/EVP_EncryptInit.html /man3/EVP_EncryptInit_ex.html /man3/EVP_idea.html used in 5 files: /man3/EVP_CIPHER_CTX_reset.html /man3/EVP_DecryptInit.html /man3/EVP_DecryptInit_ex.html /man3/EVP_EncryptInit.html /man3/EVP_EncryptInit_ex.html /man3/EVP_rc2.html used in 5 files: /man3/EVP_CIPHER_CTX_reset.html /man3/EVP_DecryptInit.html /man3/EVP_DecryptInit_ex.html /man3/EVP_EncryptInit.html /man3/EVP_EncryptInit_ex.html /man3/EVP_rc5.html used in 5 files: /man3/EVP_CIPHER_CTX_reset.html /man3/EVP_DecryptInit.html /man3/EVP_DecryptInit_ex.html /man3/EVP_EncryptInit.html /man3/EVP_EncryptInit_ex.html /man3/EVP_seed.html used in 5 files: /man3/EVP_CIPHER_CTX_reset.html /man3/EVP_DecryptInit.html /man3/EVP_DecryptInit_ex.html /man3/EVP_EncryptInit.html /man3/EVP_EncryptInit_ex.html /man3/EVP_sm4.html used in 5 files: /man3/EVP_CIPHER_CTX_reset.html /man3/EVP_DecryptInit.html /man3/EVP_DecryptInit_ex.html /man3/EVP_EncryptInit.html /man3/EVP_EncryptInit_ex.html /man3/X509_check_purpose.html used in 1 file: /man3/X509_get_extension_flags.html
Re: Stitched vs non-Stitched Ciphersuites
On Wed, Feb 27, 2019 at 8:42 AM Matt Caswell wrote: > On 27/02/2019 16:33, Sam Roberts wrote: > > That would be helpful! > > It has been updated: Thank you, that is helpful.
Re: Stitched vs non-Stitched Ciphersuites
On Tue, Feb 26, 2019 at 8:42 AM Matt Caswell wrote: > > What about AEAD ciphers? Are they considered "stitched"? > > No, they are not "stitched" but they are not impacted by this issue. We should > probably make that clearer in the advisory. That would be helpful! Even though this is fixed, would the general advice still be "avoid CBC in favour of AESCCM and AESGCM when using TLS1.2"? Or update to TLS1.3.
Re: CVE-2019-1559 advisory - what is "non-stiched" ciphersuite means?
It would have been helpful if the sec announcement had contained a specific list of cipher suites affected, even without the additional list of specific architectures vulnerable. Its hard to communicate clearly ATM to people which suites are or are not affected, so they can know if they are affected. Sam
Re: [openssl-users] when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?
On Fri, Feb 15, 2019 at 3:35 PM Matt Caswell wrote:
> On 15/02/2019 20:32, Viktor Dukhovni wrote:
> >> On Feb 15, 2019, at 12:11 PM, Sam Roberts wrote:
> > OpenSSL could delay the actual shutdown until we're about to return
> > from the SSL_accept() that invoked the callback. That is SSL_shutdown()
> > called from callbacks could be deferred until a more favourable time.
In this case, it's an SSL_read() that invoked the callback, though
probably not relevant.
And actually, no deferal would be necessary, I looks to me that the
info callback for handshake done is coming too early. Particularly,
the writing of the NewSessionTickets into the BIO should occur before
the info callback. I'll check later, but I'm pretty sure with TLS1.2
the session tickets are written and then the HANDSHAKE_DONE info
callback occurs, so the timing here is incompatible with TLS1.2.
Though the deferal mechanism might be there already. It looks like
doing an SSL_write(); SSL_shutdown() in the info callback works fine,
on the client side new ticket callbacks are fired by the SSL_read()
before the SSL_read() sees the close_notify and returns 0. I haven't
looked at the packet/API trace for this, because the tests all pass
for this case, but I do see that in the javascript called from the
HANDSHAKE_DONE callback, that calling .end("x") (write + shutdown)
causes the client to get tickets, but .end() causes it to miss them
because they are after close_notify.
> Oh - right. I missed this detail. Calling SSL_shutdown() from inside a
> callback
> is definitely a bad idea. Don't do that.
The info callback, or ANY callbacks? What about the new ticket
callback, for example? Is it expected that no SSL_ calls are made in
ANY callbacks?
This code has been working a fair number of years now, I can move it
(and review every other callback where we callout to javascript code)
to a model where callbacks just save data, set global state, and
return into SSL, and we check after returning from SSL_read() what has
happened, and callback into javascript then, but its a bit of work,
and this fringe case of TLS servers that shutdown immediately after
handshake is not likely to be that important (at least in the short
term, though if our users scream about the API change we'll have to
decide whether we can enable TLS1.3 on stable branches, or if this
difference counts as semver-major for code that didn't explicitly
opt-in to 1.3).
Cheers,
Sam
Re: [openssl-project] OpenSSL 3.0 and FIPS Update
I don't see a FIPS repo in https://github.com/openssl, or a FIPS branch in https://github.com/openssl/openssl/branches/all Has coding started? If so, is it visible anywhere? If not, where should we watch for when it does? The FIPS design doc looks like lots of thought has gone into it, which is very promising. I also looked around in github.com/openssl, even the OpenSSL_1_0_2-stable branch, and couldn't find where the openssl-fips-2.0.16.tar.gz is built from. Where is it located? Thanks, Sam
Re: when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?
Resending, I just got banned for "bounces", though why gmail would be bouncing I don't know. On Thu, Feb 14, 2019 at 2:51 PM Sam Roberts wrote: In particular, I'm getting a close_notify alert, followed by two NewSessionTickets from the server. The does SSL_read()/SSL_get_error(), it is returning SSL_ERROR_ZERO_RETURN, so I stop calling SSL_read(). However, that means that the NewSessionTickets aren't seen, so I don't get the callbacks from SSL_CTX_sess_set_new_cb(). Should we be calling SSL_read() until some other return value occurs? Note that no data is written by the server, and SSL_shutdown() is called from inside the server's SSL_CB_HANDSHAKE_DONE info callback. The node test suite is rife with this pracitce, where a connection is established to prove its possible, but then just ended without data transfer. For TLS1.2 we get the session callbacks, but TLS1.3 we do not. This is the trace, edited to reduce SSL_trace verbosity: server TLSWrap::SSLInfoCallback(where SSL_CB_HANDSHAKE_DONE, alert U) established? 0 state 0x21 TWST: SSLv3/TLS write session ticket TLSv1.3 server TLSWrap::DoShutdown() established? 1 ssl? 1 Sent Record Inner Content Type = Alert (21) Level=warning(1), description=close notify(0) Sent Record NewSessionTicket, Length=245 Sent Record NewSessionTicket, Length=245 client TLSWrap::OnStreamRead(nread 566) Received Record Level=warning(1), description=close notify(0) SSL_read() => 0 SSL_get_shutdown() => SSL_RECEIVED_SHUTDOWN SSL_get_error() => SSL_ERROR_ZERO_RETURN At this point, we consider the connection closed... not sure what else to do. Thanks, Sam
[openssl-users] when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?
In particular, I'm getting a close_notify alert, followed by two NewSessionTickets from the server. The does SSL_read()/SSL_get_error(), it is returning SSL_ERROR_ZERO_RETURN, so I stop calling SSL_read(). However, that means that the NewSessionTickets aren't seen, so I don't get the callbacks from SSL_CTX_sess_set_new_cb(). Should we be calling SSL_read() until some other return value occurs? Note that no data is written by the server, and SSL_shutdown() is called from inside the server's SSL_CB_HANDSHAKE_DONE info callback. The node test suite is rife with this pracitce, where a connection is established to prove its possible, but then just ended without data transfer. For TLS1.2 we get the session callbacks, but TLS1.3 we do not. This is the trace, edited to reduce SSL_trace verbosity: server TLSWrap::SSLInfoCallback(where SSL_CB_HANDSHAKE_DONE, alert U) established? 0 state 0x21 TWST: SSLv3/TLS write session ticket TLSv1.3 server TLSWrap::DoShutdown() established? 1 ssl? 1 Sent Record Inner Content Type = Alert (21) Level=warning(1), description=close notify(0) Sent Record NewSessionTicket, Length=245 Sent Record NewSessionTicket, Length=245 client TLSWrap::OnStreamRead(nread 566) established? 1 ssl? 1 parsing? 0 eof? 0 Received Record Level=warning(1), description=close notify(0) SSL_read() => 0 SSL_get_shutdown() => SSL_RECEIVED_SHUTDOWN SSL_get_error() => SSL_ERROR_ZERO_RETURN At this point, we consider the connection closed... not sure what else to do. Thanks, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] how is it possible to confirm that a TLS ticket was used?
On Wed, Feb 6, 2019 at 1:01 PM Viktor Dukhovni wrote: > On Tue, Feb 05, 2019 at 02:43:03PM -0800, Sam Roberts wrote: > Your ticket rotation approach looks a bit fragile. I agree, though perhaps I should not have described what was happening as rotation. The test that was failing with TLS1.3 was one in which clearing the ticket keys was supposed to invalidate previously issued keys, but it wasn't (at least, not in the same way as it did for 1.2). > Postfix keeps two session ticket keys in memory, one that's used > to both encrypt new tickets and decrypt freshly issued tickets, and > other that's used only decrypt unexpired tickets that were isssued > just before the new key was introduced. This maintains session > ticket continuity across a single key change. The key change interval > is either equal to or is twice the maximum ticket lifetime, ensuring > that tickets are only invalidated by expiration, not key rotation. This seems a very reasonable approach, I may propose it as the default after we have 1.3 support, thanks. Cheers, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] how is it possible to confirm that a TLS ticket was used?
I tracked down my problem, its due to a change in the relative order of handshake completion (as detected by the info callback, anyhow), and the callback to SSL_CTX_set_tlsext_ticket_key_cb(). With TLS1.2, I can rotate ticket keys on the server when the handshake completes, and they will only apply to the next connection. With TLS1.3, the tickets haven't been sent yet, at the time the handshake completes, so when I "rotate" the keys, the new keys are used immediately afterwards in the ticket_key_cb to encrypt the tickets for the connection that just handshaked. Its semi-obvious in retrospect, after having read our ticket key handling code, but it took me a while to find it. And it turns out that yes, SSL_session_resumed() does work with TLS tickets. Thanks for the suggestions, Viktor. Cheers, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] how is it possible to confirm that a TLS ticket was used?
On Mon, Feb 4, 2019 at 9:46 PM Viktor Dukhovni wrote: > On Mon, Feb 04, 2019 at 03:54:48PM -0800, Sam Roberts wrote: > However, because in TLS 1.3, session > tickets are sent *after* the completion of the handshake, it is > possible that the session handle you're saving is the one that does > not yet have any associated tickets, because they've not yet been > received. I'm saving the session that is passed to the callback in SSL_CTX_sess_set_new_cb() as described in https://wiki.openssl.org/index.php/TLS1.3#Sessions. > posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: Reusing old session What API are you using to confirm that the ticket was used to resume the session? SSL_session_reused? Thanks, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] how is it possible to confirm that a TLS ticket was used?
And is it possible that this is different for TLS1.2 and 1.3? Using TLS1.3, SSL_session_reused() is always returning false, I'm not sure if that's because I'm doing something else wrong, and the ticket is not being accepted and a full handshake is occurring, or if the API literally only signals "session reuse" not "tls ticket" reuse. Its also not clear from the docs if this API is supposed to work for both client & server sides. With TLS1.2, I notice that the cb to SSL_CTX_sess_set_new_cb() occurs when a session is NOT reused (and I guess a new ticket is issued), but in situation that I would expect the session to be resumed, I don't get the callback. I assume this is because it doesn't make sense to issue more tickets for a resumed connection? This gives me some confidence that ticket use is occurring. For 1.3, I'm always getting the callback (twice per connection, of course), which makes me think that somehow my ticket reuse code is working only for 1.2. For both, I'm getting the session in the new session callback, and then setting it with SSL_set_session(), so I'd expect resumption to work for either protocol. Thanks, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] is the openssl wiki down for maintenance, or is something broken?
https://wiki.openssl.org/index.php/TLS1.3 is returning ``` Sorry! This site is experiencing technical difficulties. Try waiting a few minutes and reloading. (Cannot access the database) ``` -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Thu, Jan 17, 2019 at 5:40 PM Jordan Brown wrote: > On 1/14/2019 4:09 AM, Matt Caswell wrote: > > This works more "by accident". There is no ciphersuite alias called > "TLSv1.3", so using it as above results in no ciphersuites matched. Since the > TLSv1.3 ciphersuites are on by default anyway that's all that you get back. > > > From what you say, and based on experimentation, it seems like the TLSv1.3 > ciphersuites are enabled even if you explicitly say to disable them. 3 of 5 TLS1.3 cipher suites are enabled by default I'm having to reverse engineer the intention, but I think that it was thought that the cipher list API with its mini language was too complex, so there is a new API for setting TLS1.3 cipher suites, _set_ciphersuites(), and for openssl cipher, you can pass args to it using the -ciphersuites option. You can also pass an empty string "" to clear them. Another reason for the second API and the odd interactions between them may be that there are existing apps calling the set_cipher_list() APIs.. if their arg applied to TLS1.3 ciphers, it would always clear them, so existing apps wouldn't use TLS1.3 even though they were theoretically capable. Anyhow, you are seeing that seperation of two APIs, each configuring suites for different protocol familes (pre/post TLS1.3). -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Mon, Jan 14, 2019 at 5:18 AM Yann Ylavic wrote:
> I suppose one can always, e.g.:
>
> $ openssl ciphers -v |grep TLSv1.3 |awk '{print $1}' # or whatever filtering
>
> to not depend on this "accident", right?
No, `ciphers` gives you the TLS cipher suites that are enabled, it
doesn't give all.
As you saw with both of your `ciphers` commands, they are printing the
3 TLS1.3 cipher suites that are enabled by default, but OpenSSL
supports 5 TLS1.3 cipher suites, two are missing from the output.
Cheers,
Sam
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_CTX_set_cert_verify_callback and certificate access
On Wed, Jan 9, 2019 at 6:54 PM Corey Minyard wrote: > My first inclination for a secure connection was to use ssh. However, > ssh is not as well suited for this as I would have liked, and all the > ssh libraries are tied to a file descriptor in ways that are not easily > fixable, and thus can't be used on top of an abstract connection, which > is what I need. That was rather disappointing, as it would have been > really nice to for users to just be able to ssh to ser2net. Not to second guess your finding that ssh isn't working well for you, you know your own code best, but for my own interest, I'm curious what about the fd is a problem? Perhaps the mismatch between X.509+TLS and the auth model you want are enough to reconsider your abstractions? Generating certs is pretty annoying and fragile, and using ssh clients is pretty easy! It sounds like your are building the abstractions (in C?) inside the sernet process, but maybe your abstraction can be an fd, and the "layers" can be child processes that connect fd-to-fd, sortof qmail-like? Or, ssh should be able to execute an arbitrary command on the server, and that command should be able to do anything it wants with the ssh-facing socket descriptors, perhaps sending data to/from your server which can then move the data through the in-process abstractions? Cheers, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Tue, Jan 8, 2019 at 7:10 PM Viktor Dukhovni wrote: > On Tue, Jan 08, 2019 at 02:23:27PM -0800, Sam Roberts wrote: > > node.js has an API that lists all the cipher suite names that can be > > validly passed to set_cipher_list(), but I don't see how to get them > > for TLS1.3 to list the valid inputs to set_cipher_suites(). > > The intent is that you SHOULD NOT generally customize the list. There are many reasons users might want to customize it, writing unit tests for example, to ensure that their software interoperates with clients that only support some of the ciphers. For the same reasons OpenSSL allows the cipher suite to be customized, Node.js exposes this capability to its users, along with a recommendation to not do this casually. The Node.js default will, of course, be the same as OpenSSL for TLS1.3. Anyhow, my question isn't about how to call set_cipher_suites(), its about how to get the list of ciphers supported by OpenSSL for TLS1.3 in such a way that when new ciphers become available, they are returned. I realized the link to the API I provided, not that its that relevant, was to my local dev filesystem, oops! The API is https://nodejs.org/api/crypto.html#crypto_crypto_getciphers. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
node.js has an API that lists all the cipher suite names that can be validly passed to set_cipher_list(), but I don't see how to get them for TLS1.3 to list the valid inputs to set_cipher_suites(). The openssl ciphers CLI doesn't seem able to do this either. https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html lists the 1.3 suites, there aren't many, so I could just hard-code them into our API, but that's pretty fragile, I assume there will be a few more, eventually. Or, I guess I could just link to the openssl man page online for TLS1.3, and tell people that file:///home/sam/w/core/node/out/doc/api/crypto.html#crypto_crypto_getciphers only works for TLS1.2 and below. Cheers, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] A script for hybrid encryption with openssl
On Tue, Dec 18, 2018 at 3:18 AM Nick wrote: > I should add that I don't really care about the format, or even the use of > openssl - just the ability to tackle large files with the benefits of public > key encryption, in a self-contained way without needing fiddly work deploying > the keys (as GnuPG seems to require for its keyring, judging from my > experience deploying Backup-Ninja / Duplicity using Ansible.) Maybe you should look at gpg directly, `gpg --symmetric` uses a passphrase, which doesn't sound fiddly. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] version OPENSSL_1_1_1 not defined in file libcrypto.so.1.1 with link time reference
On Wed, Dec 5, 2018 at 5:22 AM Vincent Le Bourlot wrote: > After a fresh build of branch OpenSSL_1_1_1-stable on our ppc64 machine, > openssl seems broken for an unknown reason… > Executing `openssl version` results in: I'm no expert, but try `ldd openssl`, is it dynamically linking against the libcrypto/libssl that you just built? If not, try setting LD_LIBRARY_PATH (I had to do that with my local builds from source). -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] what is the relationship between (Client)SignatureAlgorithms and cipher_list()?
Do they overlap in purpose, so the cipher list can be used to limit the signature algorithms? Or are the signature algorithms used for different purposes than the cipher suites in the cipher list? If they have to be configured seperately, is the mechanism to use https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd_value_type.html ? Thanks! Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] was the change in when disabled ciphers are skipped intentional?
On Fri, Nov 23, 2018 at 11:41 AM Viktor Dukhovni
wrote:
> > On Nov 23, 2018, at 2:25 PM, Sam Roberts wrote:
> >
> > In 1.1.0j, if SSL_CTX_set_cipher_list() is called with "not-a-cipher"
> > or "rc4", then SSL_R_NO_CIPHER_MATCH will occur.
> >
> > In 1.1.1a, set_cipher_list() suceeds, seems to return the complete
> > cipher list (should it do this?) but later ssl_cipher_list_to_bytes()
> > will find that ssl_cipher_disabled() is true for all the ciphers, and
> > SSL_R_NO_CIPHERS_AVAILABLE will occur.
So what is happening is happening is that while there are two APIs,
SSL_CTX_set_ciphersuites()(TLSv1.3) and
SSL_CTX_set_cipher_list()(<=TLSv1.2), they both put cipher suites into
SSL_CTX.cipher_list.
This basically makes the cipher_list error check:
if (sk_SSL_CIPHER_num(sk) == 0) {
SSLerr(SSL_F_SSL_CTX_SET_CIPHER_LIST, SSL_R_NO_CIPHER_MATCH);
return 0;
}
bogus, because even when there were, in fact zero TLSv1.2 cipher
suites configured, the check for cipher suite number will find the
number greater than zero if there are TLSv1.3 cipher suites in the
list. Which there will be, by default. The actual behaviour of this
check depends on the order in which set_ciphersuites() and
set_cipher_list() are called, a fact I can exploit to make the API
backwards compatible for Node.js.
I will call SSL_CTX_set_ciphersuites(ctx,"") just before calling
set_cipher_list(). This will clear out the TLSv1.3 suites (we don't
support 1.3 yet). Since the 1.3 suites are gone, the check for a
length of zero causing NO_CIPHER_MATCH will now behave as it would be
expected.
This won't work in the future.
I think what really should be done is that the check for _num(sk) == 0
needs to be rewritten, to iterate the list, and find the number of
TLSv1.2 and below ciphers, and return NO_CIPHER_MATCH if that number
is zero.
Cheers,
Sam
> When I try it with ciphers(1), I get (as expected) just the TLSv1.3
> ciphers, which are configured separately from the TLSv1.2 (and below)
> ciphers:
>
> $ /opt/openssl/1.1.1/bin/openssl ciphers -v not-a-cipher
> TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
>
> > Also, I don't understand why "not-a-cipher" matches any ciphers in
> > 1.1.1, I'd expect the cipher list to be empty.
>
> It should have the effect of disabling all SSLv3 and TLSv1.[012] ciphers,
> leaving just the TLSv1.3 ciphers enabled.
>
> Any change of behaviour you're seeing surely results from the introduction
> of a separate TLSv1.3 cipherlist, but what remains to be explained is what
> you mean by "seems to return the complete cipher list", is that a bug, a
> documentation defect or user error?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] was the change in when disabled ciphers are skipped intentional?
In 1.1.0j, if SSL_CTX_set_cipher_list() is called with "not-a-cipher" or "rc4", then SSL_R_NO_CIPHER_MATCH will occur. In 1.1.1a, set_cipher_list() suceeds, seems to return the complete cipher list (should it do this?) but later ssl_cipher_list_to_bytes() will find that ssl_cipher_disabled() is true for all the ciphers, and SSL_R_NO_CIPHERS_AVAILABLE will occur. We can work around this change, but it seems to be moving a configuration error to a runtime error, and I'm not sure this was intentional, or a side-effect of code cleanups. I couldn't find mention of it in the man page or changelog. Also, I don't understand why "not-a-cipher" matches any ciphers in 1.1.1, I'd expect the cipher list to be empty. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Is there any standard way of getting the error name from an SSL error?
For example, I want the string "SSL_R_TOO_MANY_WARN_ALERTS" for an error with that value, not just the "too many alerts" description. I'm suspecting not, I don't see any use of #reason in ERR_REASON() or the macros it uses. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PKCS7 and RSA_verify
On Thu, Sep 28, 2017 at 2:28 AM, ch wrote: > Hi! > > I thought the difference between PEM and DER is NOT ONLY a different > encoding of the string? > base64 vs. binary > > So to understand that clear please let me ask: > If I convert a PEM-signature from base64 to binary then it is DER? Yes. Well, technically it could be BER as well, but the main point is PEM is just a wrapper to transport binary via email safe text, and you can unwrap it if you want. PEM also includes a header, so you know if the object is a cert, a key, an encrypted message, etc, meta-data which is not known if you just have the binary chunk. > > Thanks > Chris > > On 2017-09-28 11:23, Wouter Verhelst wrote: >> >> On 28-09-17 01:19, ch wrote> If the pkcs-signature is binary encoded it >> is not working for verifiying >>> >>> a SMIME-message in my experience with >>> smime or cms-smime on the console. I tried to convert the binary ones to >>> base64 but that does not everytime the trick. >> >> What you call "base64" is commonly known as "PEM" :-) >> >> You can get it to parse binary, but to do so you need to specify >> "-inform der". >> > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] problem with -aes256 and -outform der in cmmand
Probably I misunderstand the context, since PKCS#8 can be used to encrypt EC private key info, some more info at https://tools.ietf.org/html/rfc5915. Which doesn't help the OP if the openssl CLI doesn't support it. On Mon, Aug 21, 2017 at 8:52 AM, Salz, Rich via openssl-users wrote: > ➢ OK. And why does DER not support encryption > > Because it is not defined. If you want to encrypt keys, you need to use > PKCS12 which might be too much for your application. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?
On Thu, Jul 20, 2017 at 4:08 PM, Dr. Stephen Henson wrote: > On Thu, Jul 20, 2017, Sam Roberts wrote: > >> >> Most of the application is compiled with /MT, but openssl-fips-2.0.16 >> is using /MD, could this be an issue? Can I/should I convince >> ms\do_fips to build against the multi-threaded runtime? >> > > Unfortunately you can't change that part of the build process in any way or > the result is no longer validated. OK, then given https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx "All modules passed to a given invocation of the linker must have been compiled with the same run-time library compiler option (/MD, /MT, /LD)." a static link is impossible, it seems. I don't think a DLL build will work for node.js given its distribution/use model, but hypothetically, is there a way to hide fipscanister in a single-threaded DLL, used by a multi-threaded app? Are you aware of any multi-threaded OpenSSL FIPS apps on Windows? node makes almost all of its openssl calls from a single thread, but there are two exceptions, getting random seeds and pbkdf2, where the cpu intensive or potentially blocking call is made from a thread pool. Cheers, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?
On Wed, Jul 19, 2017 at 6:27 PM, Dr. Stephen Henson wrote: > Try linking with fipscanister.lib too: that's where those symbols are located. OK, I'd tried that before with no luck, but I tried harder. I found that if my lib line has the fips_premain.obj, then the fipscanister.lib, then the rest of the program's obj files and libs in exactly that order, the symbols are resolved. That's progress! Now I'm hitting the dreaded MSVCRT conflicts with use of other libs problem. Most of the application is compiled with /MT, but openssl-fips-2.0.16 is using /MD, could this be an issue? Can I/should I convince ms\do_fips to build against the multi-threaded runtime? It may also be other obj files causing the issue, the MSVC message is not so helpful, I'm continuing to look. I used /nodedefaultlib:msvcrt (even though its supposed to not be recommended) and I got a link of openssl-cli, though with lots of "LNK4049 locally defined symbol _exit imported", which sounds like its another symbol of /MT and /MD mismatch. I also almost got a link of node, but it died with fipscanister.lib(cryptolib.obj): error LNK2001: unresolved symbol __imp_wcsstr, and __imp___stdio_common_vsscanf, both of which sound suspiciously like a problem with the runtime compilation flags to me. Cheers, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?
On Thu, Jul 13, 2017 at 11:07 AM, Sam Roberts wrote: > I'm having trouble linking on Windows with fipslink.pl, lots of FIPS_ > symbols are unresolved. OK, I attempted to do as ms/nt.mak does, rewriting it as a batch file: https://github.com/sam-github/node/blob/fips-win-ninja/fipslink.bat, no luck yet. The args are passed in %2 as a response file from https://github.com/sam-github/node/blob/574ddeff5197d097d7d872e2ef03127b95b4d5f9/out/Release/build.ninja#L70-L71, the rsp file is https://github.com/sam-github/node/blob/574ddeff5197d097d7d872e2ef03127b95b4d5f9/out/Release/openssl-cli.exe.rsp#L52 Note that the lib names used in the node gyp build of openssl vary a bit from the perl/ms makefile build. Anyhow, still the same link errors. My eventual goal is to build a fips node on Windows (Linux works already), but one of its build pre-reqs is the openssl CLI: C:\Users\rsam\node\out\Release>c:\users\rsam\perl\bin\perl.exe c:\usr\local\ssl\ fips-2.0\bin\fipslink.pl /nologo /subsystem:console /opt:ref /debug /out:openssl -cli.exe .\fips_premain.obj @openssl-cli.exe.rsp Integrity check OK "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\cl.exe" /Fo.\f ips_premain.obj -c c:\usr\local\ssl\fips-2.0\lib/fips_premain.c Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64 Copyright (C) Microsoft Corporation. All rights reserved. fips_premain.c link /nologo /subsystem:console /opt:ref /debug /out:openssl-cli.exe .\fips_prem ain.obj @openssl-cli.exe.rsp fips_premain.obj : error LNK2001: unresolved external symbol FIPS_text_start fips_premain.obj : error LNK2001: unresolved external symbol FIPS_incore_fingerp rint fips_premain.obj : error LNK2001: unresolved external symbol FIPS_signature crypto.lib(openssl.rand_lib.obj) : error LNK2001: unresolved external symbol FIP S_rand_set_method crypto.lib(openssl.rand_lib.obj) : error LNK2001: unresolved external symbol FIP S_get_default_drbg etc... I'd love any suggestions, as-is, the only way I can think of to figure out how FIPS builds are supposed to work is to do a pure-openssl fips build, get a dump of all the compile and link commands done by the generated makefiles, s and try working from there to reverse engineer what the ninja/batch file build should be trying to do. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?
On Thu, Jul 13, 2017 at 7:46 PM, Dr. Stephen Henson wrote: > On Thu, Jul 13, 2017, Sam Roberts wrote: > >> On Thu, Jul 13, 2017 at 1:41 PM, Dr. Stephen Henson >> wrote: >> >> >> >> Where is nt.mak? Its mentioned in the User Guide but I didn't find it >> >> in the github repo, or tarballs for openssl 1.0.2j or 1.1.0c, or >> >> tarballs for openssl-fips 2.0.9, or 2.0.16 >> >> >> > >> > It's created by OpenSSL when you follow the Windows build procedure. >> >> No luck so far. I dowloaded openssl-1.0.2l did the `perl Configure ... >> --with=fipsdir...` from section 4.3.3 and don't have a ms/nt.mak. >> > > Are you compiling with VC++ that's the only compiler which is a supported for > FIPS and Windows. yes, visual studio 2015 > If you are then you need the next step which is: > > ms\do_nasm > > to get ms\nt.mak That worked to get me the file, thanks. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?
On Thu, Jul 13, 2017 at 1:41 PM, Dr. Stephen Henson wrote: > On Thu, Jul 13, 2017, Sam Roberts wrote: >> On Thu, Jul 13, 2017 at 12:34 PM, Dr. Stephen Henson >> wrote: >> > If you do want to link against the static libraries then the easiest way >> > to do >> > that is to examine the contents of nt.mak, look for FIPSLINK and adapt the >> > rule to your needs. >> >> Where is nt.mak? Its mentioned in the User Guide but I didn't find it >> in the github repo, or tarballs for openssl 1.0.2j or 1.1.0c, or >> tarballs for openssl-fips 2.0.9, or 2.0.16 >> > > It's created by OpenSSL when you follow the Windows build procedure. No luck so far. I dowloaded openssl-1.0.2l did the `perl Configure ... --with=fipsdir...` from section 4.3.3 and don't have a ms/nt.mak. Or is it openssl-fips that is going to have the ms/nt.mak? I followed the directions in section 4.3.1 and I have a ms/ntdll.mak, but no nt.mak. For context, I've never done the openssl perl build (until just now, to try to get a nt.mak), because I'm working on Node.js. It has openssl copied into its git repo as a dependency, and builds and statically links it using a gyp based build system. This works fine for Linux FIPS, but I'm trying to get it working for Windows FIPS. First I need to figure out the fipslink.pl commands to call by hand, then I'll have the fun of trying to convince gyp to generate ninja files that call fipslink.pl correctly. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?
On Thu, Jul 13, 2017 at 12:34 PM, Dr. Stephen Henson wrote: > First if you want to link to the OpenSSL DLLs then you don't need fipslink.pl > at all: just link to them as you would any other application. I'm working on Node.js, it links statically, so this isn't an option for me. > If you do want to link against the static libraries then the easiest way to do > that is to examine the contents of nt.mak, look for FIPSLINK and adapt the > rule to your needs. Where is nt.mak? Its mentioned in the User Guide but I didn't find it in the github repo, or tarballs for openssl 1.0.2j or 1.1.0c, or tarballs for openssl-fips 2.0.9, or 2.0.16 Thanks, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] shouldn't fipslink.pl include the fipscanister.lib in the link line?
I'm having trouble linking on Windows with fipslink.pl, lots of FIPS_ symbols are unresolved. AFAICT, they are defined by the canister, and fipslink.pl is supposed to know this, and add them to the link libraries by itself, but it doesn't seem to do this. Looking at the linux fipsld, it does appear to have code to find and add fipscanister.o to the link line. Any idea what I am doing wrong, or not understanding about fipslink.pl? Thanks, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
