From jb-openssl at wisemo.com Tue Sep 1 00:57:31 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 1 Sep 2020 02:57:31 +0200 Subject: Cert hot-reloading In-Reply-To: <20200831235239.GK44511@straasha.imrryr.org> References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> <20200831235239.GK44511@straasha.imrryr.org> Message-ID: <841abba8-1af8-c1e4-d9ee-c0ccfa564747@wisemo.com> On 2020-09-01 01:52, Viktor Dukhovni wrote: > On Sun, Aug 30, 2020 at 07:54:34PM -0500, Kyle Hamilton wrote: > >> I'm not sure I can follow the "in all cases it's important to keep >> the key >> and cert in the same file" argument, particularly in line with openat() >> usage on the cert file after privilege to open the key file has been >> dropped. I agree that key/cert staleness is important to address in some >> manner, but I don't think it's necessarily appropriate here. > Well, the OP had in mind very frequent certificate chain rollover, where > presumably, in at least some deployments also the key would roll over > frequently along with the cert. > > If the form of the key/cert rollover is to place new keys and certs into > files, then *atomicity* of these updates becomes important, so that > applications loading a new key+chain pair see a matching key and > certificate and not some cert unrelated to the key. > > This, e.g., Postfix now supports loading both the key and the cert > directly from the same open file, reading both sequentially, without > racing atomic file replacements when reopening the file separately > to reach keys and certs. > > If we're going to automate things more, and exercise them with much > higher frequency. The automation needs to be robust! Another synchronization method would be for the application to decree a specific order of changing the two files, such that triggering reload on the second file would correctly load the matching contents of the other. If a future OpenSSL version includes an option to detect such change, documentation as to which file it watches for changes would guide applications in choosing which order to specify for changing the files. > Note that nothing prevents applications that have separate configuration > for the key and cert locations from opening the same file twice. If > they're using the normal OpenSSL PEM read key/cert routines, the key > is ignored when reading certs and the certs are ignored when reading > the key. > > Therefore, the single-file model is unconditionally superior in this > context. Yes, some tools (e.g. certbot), don't yet do the right > thing and atomically update a single file with both the key and the > obtained certs. This problem can be solved. We're talking about > new capabilities here, and don't need to adhere to outdated process > models. > Given the practical imposibility of managing atomic changes to a single POSIX file of variable-length data, it will often be more practical to create a complete replacement file, then replace the filename with the "mv -f" command or rename(3) function.? This would obviously only work if the directory remains accessible to the application, after it drops privileges and/or enters a chroot jail, as will already be the case for hashed certificate/crl directories. 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 From carl-eric.codere at thalesgroup.com Tue Sep 1 02:01:57 2020 From: carl-eric.codere at thalesgroup.com (CODERE Carl-Eric) Date: Tue, 1 Sep 2020 02:01:57 +0000 Subject: OpenSSL 3.0.0 security concerns using dynamic providers Message-ID: Greetings, We are currently investigating the usage of OpenSSL 3.0.0 on our side, especially for FIPS usage, but it seems that for OpenSSL 3.0.0 the providers, especially the FIPS provider, will be loaded dynamically, my main worry is that this will easily permit some kind of attacks on the cryptographic layer, for example: 1. Replacing the provider by a tampered provider by replacing the shared/dynamic library. This can partially be protected by the caller verifying the hash of the provider before calling it, will OpenSSL 3.0.0 do this, or will need to be done at integrator level? 2. Having the provider entry points made public because they are dynamic will easily permit MITM attack or modification such as through hooking, have you thought of protection mechanisms to protect against this kind of attack? With FIPS 2.0, from my understanding, it was statically linked, hence these risks would be lessened. Of course it required more work as it required a special linker script to add the hash value and with new NIST requirements, the FIPS mode needed to be enabled by default at premain, but my feeling as that it was more secure. Thanks for your guidance! Carl Eric Codere -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 1 02:26:47 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 1 Sep 2020 00:26:47 -0200 Subject: Cert hot-reloading In-Reply-To: <841abba8-1af8-c1e4-d9ee-c0ccfa564747@wisemo.com> References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> <20200831235239.GK44511@straasha.imrryr.org> <841abba8-1af8-c1e4-d9ee-c0ccfa564747@wisemo.com> Message-ID: <386CBC1F-0BD6-45F2-BA85-7973F1070ED0@dukhovni.org> > On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users wrote: > > Given the practical imposibility of managing atomic changes to a single > POSIX file of variable-length data, it will often be more practical to > create a complete replacement file, then replace the filename with the > "mv -f" command or rename(3) function. This would obviously only work > if the directory remains accessible to the application, after it drops > privileges and/or enters a chroot jail, as will already be the case > for hashed certificate/crl directories. There is no such "impossibility", indeed that's what the rename(2) system call is for. It atomically replaces files. Note that mv(1) can hide non-atomic copies across file-system boundaries and should be used with care. And this is why I mentioned retaining an open directory handle, openat(2), ... There's room here to design a robust process, if one is willing to impose reasonable constraints on the external agents that orchestrate new cert chains. As for updating two files in a particular order, and reacting only to changes in the one that's updated second, this behaves poorly when updates are racing an application cold start. The single file approach, by being more restrictive, is in fact more robust in ways that are not easy to emulate with multiple files. If someone implements a robust design with multiple files, great. I for one don't know of an in principle decent way to do that without various races, other than somewhat kludgey retry loops in the application (or library) when it finds a mismatch between the cert and the key. -- Viktor. From dar at xoe.solutions Tue Sep 1 04:00:31 2020 From: dar at xoe.solutions (David Arnold) Date: Mon, 31 Aug 2020 23:00:31 -0500 Subject: Cert hot-reloading In-Reply-To: <386CBC1F-0BD6-45F2-BA85-7973F1070ED0@dukhovni.org> References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> <20200831235239.GK44511@straasha.imrryr.org> <841abba8-1af8-c1e4-d9ee-c0ccfa564747@wisemo.com> <386CBC1F-0BD6-45F2-BA85-7973F1070ED0@dukhovni.org> Message-ID: 1. Construe symlinks to current certs in a folder (old or new / file by file) 2. Symlink that folder 3. Rename the current symlink to that new symlink atomically. On OpenSSL side statd would have to follow through on symlinks - if it shouldnt do so. This is +- how kubernetes atomically provisions config maps and secrets to pods. So there is a precedence for applications to follow this pattern. I totally agree, that those constraints shall be put on applications in order to have the freedom to focuse on a sound design. If openssl really wanted to make it easy it would provide an independent helper that would do exactly this operation on behalf of non-complying applications. Does it look like we are actually getting somewhere here? I'd still better understand why atomic pointer swaps can be difficult and how this can be mitigated. I'm sensing a bold move for a sounder certificate consumption is possible there too (with potential upsides further down). Do I sense right? El lunes, 31 de agosto de 2020, Viktor Dukhovni escribi?: > > On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users < > openssl-users at openssl.org> wrote: > > > > Given the practical imposibility of managing atomic changes to a single > > POSIX file of variable-length data, it will often be more practical to > > create a complete replacement file, then replace the filename with the > > "mv -f" command or rename(3) function. This would obviously only work > > if the directory remains accessible to the application, after it drops > > privileges and/or enters a chroot jail, as will already be the case > > for hashed certificate/crl directories. > > There is no such "impossibility", indeed that's what the rename(2) system > call is for. It atomically replaces files. Note that mv(1) can hide > non-atomic copies across file-system boundaries and should be used with > care. > > And this is why I mentioned retaining an open directory handle, openat(2), > ... > > There's room here to design a robust process, if one is willing to impose > reasonable constraints on the external agents that orchestrate new cert > chains. > > As for updating two files in a particular order, and reacting only to > changes in the one that's updated second, this behaves poorly when > updates are racing an application cold start. The single file approach, > by being more restrictive, is in fact more robust in ways that are not > easy to emulate with multiple files. > > If someone implements a robust design with multiple files, great. I for > one don't know of an in principle decent way to do that without various > races, other than somewhat kludgey retry loops in the application (or > library) when it finds a mismatch between the cert and the key. > > -- > Viktor. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 1 04:57:43 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 1 Sep 2020 00:57:43 -0400 Subject: Cert hot-reloading In-Reply-To: References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> <20200831235239.GK44511@straasha.imrryr.org> <841abba8-1af8-c1e4-d9ee-c0ccfa564747@wisemo.com> <386CBC1F-0BD6-45F2-BA85-7973F1070ED0@dukhovni.org> Message-ID: <20200901045743.GM44511@straasha.imrryr.org> On Mon, Aug 31, 2020 at 11:00:31PM -0500, David Arnold wrote: > 1. Construe symlinks to current certs in a folder (old or new / file by file) > 2. Symlink that folder > 3. Rename the current symlink to that new symlink atomically. This is fine, but does not provide atomicity of access across files in that directory. It just lets you prepare the new directory with non-atomic operations on the list of published files or file content. But if clients need to see consistent content across files, this does not solve the problem, a client might read one file before the symlink is updated and another file after. To get actual atomicity, the client would need to be sure to open a directory file descriptor, and then openat(2) to read each file relative to the directory in question. Most application code is not written that way, but conceivably OpenSSL could have an interface for loading a key and certchain from two (or perhaps even more for the cert chain) files relative to a given directory. I know how to do this on modern Unix systems, no idea whether something similar is possible on Windows. The above is *complicated*. Requiring a single file for both key and cert is far simpler. Either PEM with key + cert or perhaps (under duress) even PKCS#12. > Does it look like we are actually getting somewhere here? So far, not much, just some rough notes on the obvious obstacles. There's a lot more to do to design a usable framework for always fresh keys. Keeping it portable between Windows and Unix (assuming MacOS will be sufficiently Unix-like) and gracefully handling processes that drop privs will be challenging. Not all applications will want the same approach, so there'd need to be various knobs to set to choose one of the supported modes. Perhaps the sanest approach (but one that does nothing for legacy applications) is to provide an API that returns the *latest* SSL_CTX via some new handle that under the covers constructs a new SSL_CTX as needed. SSL_CTX *SSL_Factory_get1_CTX(SSL_CTX_FACTORY *); This would yield a reference-counted SSL_CTX that each caller must ultimately release via SSL_CTX_free() to avoid a leak. ... factory construction API calls ... ctx = SSL_Factory_get1_CTX(factory); -- ctx ref count >= 1 SSL *ssl = SSL_CTX_new(ctx); -- ctx ref count >= 2 ... SSL_free(ssl); -- ctx ref count >= 1 SSL_CTX_free(ctx); -- ctx may be freed here To address the needs of legacy clients is harder, because they expect an SSL_CTX "in hand" to be valid indefinitely, but now we want to be able age out and free old contexts, so we want some mechanism by which it becomes safe to free old contexts that we're sure no thread is still using. This is difficult to do right, because some thread may be blocked for a long time, before becoming active again and using an already known SSL_CTX pointer. It is not exactly clear how multi-threaded unmodified legacy software can be ensured crash free without memory leaks while behind the scenes we're constantly mutating the SSL_CTX. Once a pointer to an SSL_CTX has been read, it might be squirreled away in all kinds of places, and here's just no way to know that it won't be used indefinitely. -- Viktor. From dar at xoe.solutions Tue Sep 1 05:22:30 2020 From: dar at xoe.solutions (David Arnold) Date: Tue, 1 Sep 2020 00:22:30 -0500 Subject: Cert hot-reloading In-Reply-To: <20200901045743.GM44511@straasha.imrryr.org> References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> <20200831235239.GK44511@straasha.imrryr.org> <841abba8-1af8-c1e4-d9ee-c0ccfa564747@wisemo.com> <386CBC1F-0BD6-45F2-BA85-7973F1070ED0@dukhovni.org> <20200901045743.GM44511@straasha.imrryr.org> Message-ID: A SSL_CTX api seem like a good idea to provide additional guarantees to applications. Maybe Openssl - used as a library - can return to the other legacy applications that the certificate is "deemed not valid any more" whenever they try to use an outdated pointer? This ought to be a transparent scenario for a legacy application which *at the same time* also do frequent cert rolling. Would it be appropriate to record some excerpts of this discussion in github gist? I can be the secretary, if that would be uncontroversial. El lunes, 31 de agosto de 2020, Viktor Dukhovni escribi?: > On Mon, Aug 31, 2020 at 11:00:31PM -0500, David Arnold wrote: > > > 1. Construe symlinks to current certs in a folder (old or new / file by > file) > > 2. Symlink that folder > > 3. Rename the current symlink to that new symlink atomically. > > This is fine, but does not provide atomicity of access across files in > that directory. It just lets you prepare the new directory with > non-atomic operations on the list of published files or file content. > > But if clients need to see consistent content across files, this does > not solve the problem, a client might read one file before the symlink > is updated and another file after. To get actual atomicity, the client > would need to be sure to open a directory file descriptor, and then > openat(2) to read each file relative to the directory in question. > > Most application code is not written that way, but conceivably OpenSSL > could have an interface for loading a key and certchain from two (or > perhaps even more for the cert chain) files relative to a given > directory. I know how to do this on modern Unix systems, no idea > whether something similar is possible on Windows. > > The above is *complicated*. Requiring a single file for both key and > cert is far simpler. Either PEM with key + cert or perhaps (under > duress) even PKCS#12. > > > > Does it look like we are actually getting somewhere here? > > So far, not much, just some rough notes on the obvious obstacles. > There's a lot more to do to design a usable framework for always fresh > keys. Keeping it portable between Windows and Unix (assuming MacOS will > be sufficiently Unix-like) and gracefully handling processes that drop > privs will be challenging. > > Not all applications will want the same approach, so there'd need to be > various knobs to set to choose one of the supported modes. Perhaps > the sanest approach (but one that does nothing for legacy applications) > is to provide an API that returns the *latest* SSL_CTX via some new > handle that under the covers constructs a new SSL_CTX as needed. > > SSL_CTX *SSL_Factory_get1_CTX(SSL_CTX_FACTORY *); > > This would yield a reference-counted SSL_CTX that each caller must > ultimately release via SSL_CTX_free() to avoid a leak. > > ... factory construction API calls ... > ctx = SSL_Factory_get1_CTX(factory); -- ctx ref count >= 1 > SSL *ssl = SSL_CTX_new(ctx); -- ctx ref count >= 2 > ... > SSL_free(ssl); -- ctx ref count >= 1 > SSL_CTX_free(ctx); -- ctx may be freed here > > To address the needs of legacy clients is harder, because they > expect an SSL_CTX "in hand" to be valid indefinitely, but now > we want to be able age out and free old contexts, so we want > some mechanism by which it becomes safe to free old contexts > that we're sure no thread is still using. This is difficult > to do right, because some thread may be blocked for a long > time, before becoming active again and using an already known > SSL_CTX pointer. > > It is not exactly clear how multi-threaded unmodified legacy software > can be ensured crash free without memory leaks while behind the scenes > we're constantly mutating the SSL_CTX. Once a pointer to an SSL_CTX > has been read, it might be squirreled away in all kinds of places, and > here's just no way to know that it won't be used indefinitely. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 1 05:49:41 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 1 Sep 2020 01:49:41 -0400 Subject: Cert hot-reloading In-Reply-To: References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> <20200831235239.GK44511@straasha.imrryr.org> <841abba8-1af8-c1e4-d9ee-c0ccfa564747@wisemo.com> <386CBC1F-0BD6-45F2-BA85-7973F1070ED0@dukhovni.org> <20200901045743.GM44511@straasha.imrryr.org> Message-ID: <20200901054941.GP44511@straasha.imrryr.org> On Tue, Sep 01, 2020 at 12:22:30AM -0500, David Arnold wrote: > A SSL_CTX api seem like a good idea to provide additional guarantees to > applications. > > Maybe Openssl - used as a library - can return to the other legacy > applications that the certificate is "deemed not valid any more" whenever > they try to use an outdated pointer? > > This ought to be a transparent scenario for a legacy application which *at > the same time* also do frequent cert rolling. > > Would it be appropriate to record some excerpts of this discussion in > github gist? I can be the secretary, if that would be uncontroversial. > By all means, some (who don't follow the list, and in any case prefer a long-term record of this sort of issue) would rather appreciate you doing that. -- Viktor. From jb-openssl at wisemo.com Tue Sep 1 07:58:46 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 1 Sep 2020 09:58:46 +0200 Subject: Cert hot-reloading In-Reply-To: <386CBC1F-0BD6-45F2-BA85-7973F1070ED0@dukhovni.org> References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> <20200831235239.GK44511@straasha.imrryr.org> <841abba8-1af8-c1e4-d9ee-c0ccfa564747@wisemo.com> <386CBC1F-0BD6-45F2-BA85-7973F1070ED0@dukhovni.org> Message-ID: <1c8b1d38-bc12-e511-2abb-bb629a90486a@wisemo.com> On 2020-09-01 04:26, Viktor Dukhovni wrote: >> On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users wrote: >> >> Given the practical imposibility of managing atomic changes to a single >> POSIX file of variable-length data, it will often be more practical to >> create a complete replacement file, then replace the filename with the >> "mv -f" command or rename(3) function. This would obviously only work >> if the directory remains accessible to the application, after it drops >> privileges and/or enters a chroot jail, as will already be the case >> for hashed certificate/crl directories. > There is no such "impossibility", indeed that's what the rename(2) system > call is for. It atomically replaces files. Note that mv(1) can hide > non-atomic copies across file-system boundaries and should be used with > care. Note that rename(3) and link(2) do replace the file name, by making the replaced name point to a new inode, thus it would not work with calls thatmonitor an inode for content or statis change. There is no basic series of I/O calls that completely replace file contents inone step, in particular write(2) doesn't shorten the file if the new contentsis smaller than the old contents. > And this is why I mentioned retaining an open directory handle, openat(2), > ... > > There's room here to design a robust process, if one is willing to impose > reasonable constraints on the external agents that orchestrate new cert > chains. > > As for updating two files in a particular order, and reacting only to > changes in the one that's updated second, this behaves poorly when > updates are racing an application cold start. The single file approach, > by being more restrictive, is in fact more robust in ways that are not > easy to emulate with multiple files. What exactly is that "cold start" race you are talking about? Obviously, coding the logic to react badly to only one of two files being present would not work with rules that one of those two needs to arrive/change after the other. > > If someone implements a robust design with multiple files, great. I for > one don't know of an in principle decent way to do that without various > races, other than somewhat kludgey retry loops in the application (or > library) when it finds a mismatch between the cert and the key. > 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 From jb-openssl at wisemo.com Tue Sep 1 08:06:30 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 1 Sep 2020 10:06:30 +0200 Subject: Cert hot-reloading In-Reply-To: <20200901045743.GM44511@straasha.imrryr.org> References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> <20200831235239.GK44511@straasha.imrryr.org> <841abba8-1af8-c1e4-d9ee-c0ccfa564747@wisemo.com> <386CBC1F-0BD6-45F2-BA85-7973F1070ED0@dukhovni.org> <20200901045743.GM44511@straasha.imrryr.org> Message-ID: <041540f7-8a31-ad7d-6b07-c374ed0a9875@wisemo.com> On 2020-09-01 06:57, Viktor Dukhovni wrote: > On Mon, Aug 31, 2020 at 11:00:31PM -0500, David Arnold wrote: > >> 1. Construe symlinks to current certs in a folder (old or new / file by file) >> 2. Symlink that folder >> 3. Rename the current symlink to that new symlink atomically. > This is fine, but does not provide atomicity of access across files in > that directory. It just lets you prepare the new directory with > non-atomic operations on the list of published files or file content. > > But if clients need to see consistent content across files, this does > not solve the problem, a client might read one file before the symlink > is updated and another file after. To get actual atomicity, the client > would need to be sure to open a directory file descriptor, and then > openat(2) to read each file relative to the directory in question. > > Most application code is not written that way, but conceivably OpenSSL > could have an interface for loading a key and certchain from two (or > perhaps even more for the cert chain) files relative to a given > directory. I know how to do this on modern Unix systems, no idea > whether something similar is possible on Windows. On NT-based window, the undocumented Zw family of file I/O syscalls would do what you call "openat()", "current dir" is in fact a directory handle plus string equivalent stored in a user mode variable in one of the core shared objects, which is why rmdir fails if it is the current directory of any process. > The above is *complicated*. Requiring a single file for both key and > cert is far simpler. Either PEM with key + cert or perhaps (under > duress) even PKCS#12. > > >> Does it look like we are actually getting somewhere here? > So far, not much, just some rough notes on the obvious obstacles. > There's a lot more to do to design a usable framework for always fresh > keys. Keeping it portable between Windows and Unix (assuming MacOS will > be sufficiently Unix-like) and gracefully handling processes that drop > privs will be challenging. > > Not all applications will want the same approach, so there'd need to be > various knobs to set to choose one of the supported modes. Perhaps > the sanest approach (but one that does nothing for legacy applications) > is to provide an API that returns the *latest* SSL_CTX via some new > handle that under the covers constructs a new SSL_CTX as needed. > > SSL_CTX *SSL_Factory_get1_CTX(SSL_CTX_FACTORY *); > > This would yield a reference-counted SSL_CTX that each caller must > ultimately release via SSL_CTX_free() to avoid a leak. > > ... factory construction API calls ... > ctx = SSL_Factory_get1_CTX(factory); -- ctx ref count >= 1 > SSL *ssl = SSL_CTX_new(ctx); -- ctx ref count >= 2 > ... > SSL_free(ssl); -- ctx ref count >= 1 > SSL_CTX_free(ctx); -- ctx may be freed here > > To address the needs of legacy clients is harder, because they > expect an SSL_CTX "in hand" to be valid indefinitely, but now > we want to be able age out and free old contexts, so we want > some mechanism by which it becomes safe to free old contexts > that we're sure no thread is still using. This is difficult > to do right, because some thread may be blocked for a long > time, before becoming active again and using an already known > SSL_CTX pointer. > > It is not exactly clear how multi-threaded unmodified legacy software > can be ensured crash free without memory leaks while behind the scenes > we're constantly mutating the SSL_CTX. Once a pointer to an SSL_CTX > has been read, it might be squirreled away in all kinds of places, and > here's just no way to know that it won't be used indefinitely. > 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 From matt at openssl.org Tue Sep 1 10:56:41 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 1 Sep 2020 11:56:41 +0100 Subject: OpenSSL 3.0.0 security concerns using dynamic providers In-Reply-To: References: Message-ID: On 01/09/2020 03:01, CODERE Carl-Eric wrote: > 1. Replacing the provider by a tampered provider by replacing the > shared/dynamic library. This can partially be protected by the caller > verifying the hash of the provider before calling it, will OpenSSL 3.0.0 > do this, or will need to be done at integrator level? The OpenSSL 3.0 FIPS module checks its own integrity when it is first loaded. This is really intended as a sanity check. It doesn't really protect against malicious changes. I don't really see why you see this is a security concern. Of course, yes, if a malicious user was able to replace the shared/dynamic library then this would be a serious security problem. But why is this a greater risk with shared/dynamic libraries compared to static linking? In much the same way if a malicious user can change the application binary then you have a security problem. In other words if a malicious user has the ability to change any arbitrary application executable or shared library then you have a security problem. The risk doesn't really change with dynamic vs static linking. I supposed you could argue that the attack surface is marginally larger because there are more places in the filesystem that you could attack. But with any modern operating system you are going to have multiple places in the filesystem that would be a security issue if they allowed malicious users to make changes. You also have to ensure that you protect against malicious changes to your "OPENSSL_MODULES" environment variable - which can be used to override the default location to pick up provider shared objects. But again this is no different to making sure a malicious user can't make arbitrary changes to your "PATH". If they can change your "PATH" then this means they can cause you to pick up a malicious application binary. > 2. Having the provider entry points made public because they are dynamic > will easily permit MITM attack or modification such as through hooking, > have you thought of protection mechanisms to protect against this kind > of attack? This is much the same argument as above. You are worried about a malicious users being able to insert malicious providers into the system. If they can do that then they don't need to do a MITM attack. They can just replace the FIPS provider entirely with their own version. Again this is a serious security problem - but is no greater with dynamic linking vs static linking. Ultimately static linking is not designed as a security mechanism. It seems incorrect to me to rely on it as a security control. Matt From carl-eric.codere at thalesgroup.com Tue Sep 1 15:46:49 2020 From: carl-eric.codere at thalesgroup.com (CODERE Carl-Eric) Date: Tue, 1 Sep 2020 15:46:49 +0000 Subject: OpenSSL 3.0.0 security concerns using dynamic providers In-Reply-To: References: Message-ID: > -----Original Message----- > From: Matt Caswell [mailto:matt at openssl.org] > Sent: mardi 1 septembre 2020 18:57 > To: CODERE Carl-Eric ; openssl- > users at openssl.org > Subject: Re: OpenSSL 3.0.0 security concerns using dynamic providers > > > > On 01/09/2020 03:01, CODERE Carl-Eric wrote: > > 1. Replacing the provider by a tampered provider by replacing the > > shared/dynamic library. This can partially be protected by the caller > > verifying the hash of the provider before calling it, will OpenSSL > > 3.0.0 do this, or will need to be done at integrator level? > > The OpenSSL 3.0 FIPS module checks its own integrity when it is first loaded. > This is really intended as a sanity check. It doesn't really protect against > malicious changes. > > I don't really see why you see this is a security concern. Of course, yes, if a > malicious user was able to replace the shared/dynamic library then this > would be a serious security problem. But why is this a greater risk with > shared/dynamic libraries compared to static linking? In much the same way if > a malicious user can change the application binary then you have a security > problem. > > In other words if a malicious user has the ability to change any arbitrary > application executable or shared library then you have a security problem. > The risk doesn't really change with dynamic vs static linking. > Greetings, Thanks for the quick reply, actually from the perspective of mobile security, once the platform sandbox has been compromised, it is much easier for an attacker to replace a shared library with another one he has programmed than statically analyzing a properly stripped application to discover its cryptographic entry points and then patching it and/or hooking it (In the shared library the entry point names are clearly visible)... Hence final asset loss is the same, but the actual time to do the attack would be different. The goal is to add extra complexity for the attack, not to avoid it completely. > I supposed you could argue that the attack surface is marginally larger > because there are more places in the filesystem that you could attack. > But with any modern operating system you are going to have multiple places > in the filesystem that would be a security issue if they allowed malicious > users to make changes. Actually in the case of some application, that is the assumption, that the system is partially broken. > > You also have to ensure that you protect against malicious changes to your > "OPENSSL_MODULES" environment variable - which can be used to override > the default location to pick up provider shared objects. But again this is no > different to making sure a malicious user can't make arbitrary changes to > your "PATH". If they can change your "PATH" then this means they can cause > you to pick up a malicious application binary. Yes, sorry that context was not clearly defined, the attack scenarios that I was discussing are based on a sandbox based system such as mobile such as iOS and Android and partially UWP. Usually these platforms have restrictions on some of the environment variables usage. > > > 2. Having the provider entry points made public because they are > > dynamic will easily permit MITM attack or modification such as through > > hooking, have you thought of protection mechanisms to protect against > > this kind of attack? > > This is much the same argument as above. You are worried about a malicious > users being able to insert malicious providers into the system. If they can do > that then they don't need to do a MITM attack. > They can just replace the FIPS provider entirely with their own version. > Again this is a serious security problem - but is no greater with dynamic > linking vs static linking. > > Ultimately static linking is not designed as a security mechanism. It seems > incorrect to me to rely on it as a security control. > Matt I hope :) I have convinced you of the difference between static and dynamic linking in certain specific contexts. p.s: This email was sent through Outlook, so hopefully it will not be messed up too much with line breaks when it reaches you, sorry about this. Carl From tmraz at redhat.com Tue Sep 1 16:13:15 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 01 Sep 2020 18:13:15 +0200 Subject: OpenSSL 3.0.0 security concerns using dynamic providers In-Reply-To: References: Message-ID: <12856b4928045fb28452945e0a18f8983b3f6c44.camel@redhat.com> On Tue, 2020-09-01 at 15:46 +0000, CODERE Carl-Eric wrote: > > -----Original Message----- > > From: Matt Caswell [mailto:matt at openssl.org] > > Sent: mardi 1 septembre 2020 18:57 > > To: CODERE Carl-Eric ; openssl- > > users at openssl.org > > Subject: Re: OpenSSL 3.0.0 security concerns using dynamic > > providers > > > > > > > > On 01/09/2020 03:01, CODERE Carl-Eric wrote: > > > 1. Replacing the provider by a tampered provider by replacing the > > > shared/dynamic library. This can partially be protected by the > > > caller > > > verifying the hash of the provider before calling it, will > > > OpenSSL > > > 3.0.0 do this, or will need to be done at integrator level? > > > > The OpenSSL 3.0 FIPS module checks its own integrity when it is > > first loaded. > > This is really intended as a sanity check. It doesn't really > > protect against > > malicious changes. > > > > I don't really see why you see this is a security concern. Of > > course, yes, if a > > malicious user was able to replace the shared/dynamic library then > > this > > would be a serious security problem. But why is this a greater risk > > with > > shared/dynamic libraries compared to static linking? In much the > > same way if > > a malicious user can change the application binary then you have a > > security > > problem. > > > > In other words if a malicious user has the ability to change any > > arbitrary > > application executable or shared library then you have a security > > problem. > > The risk doesn't really change with dynamic vs static linking. > > > Greetings, > Thanks for the quick reply, actually from the > perspective of mobile > security, once the platform sandbox has been compromised, it is > much > easier for an attacker to replace a shared library with another one > he has > programmed than statically analyzing a properly stripped application > to discover > its cryptographic entry points and then patching it and/or hooking it > (In the > shared library the entry point names are clearly visible)... Hence > final asset > loss is the same, but the actual time to do the attack would be > different. > The goal is to add extra complexity for the attack, not to avoid it > completely. You can still build and link openssl without shared library loading support. The default provider will be then built-in. Of course, you then won't be able to load any external providers. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From matt at openssl.org Tue Sep 1 16:19:41 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 1 Sep 2020 17:19:41 +0100 Subject: OpenSSL 3.0.0 security concerns using dynamic providers In-Reply-To: References: Message-ID: <0becd817-44e9-48cb-a277-0c262284f884@openssl.org> On 01/09/2020 16:46, CODERE Carl-Eric wrote: > Greetings, > Thanks for the quick reply, actually from the perspective of mobile > security, once the platform sandbox has been compromised, it is much > easier for an attacker to replace a shared library with another one he has > programmed than statically analyzing a properly stripped application to discover > its cryptographic entry points and then patching it and/or hooking it (In the > shared library the entry point names are clearly visible)... Hence final asset > loss is the same, but the actual time to do the attack would be different. > The goal is to add extra complexity for the attack, not to avoid it completely. Slowing down an attack on an already compromised system is simply not a design goal for OpenSSL 3.0. Nor was it for the FIPS Object Module 2.0 AFAIK although it might have been an accidental by-product. Once your system is compromised there are so many ways to attack it that I severely doubt whether the difference between static vs dynamic linking is going to make much difference to the overall result. But ultimately you know your application context better than I do. From an OpenSSL perspective the decision to use dynamic linking for the FIPS provider was fundamental and meant that we could avoid a whole heap of problems that plagued the FOM 2.0. This isn't a design decision that is likely to be reversed - and certainly could not be in the 3.0 timescale. You will have to weigh the security pros and cons of this for your context. Matt From tmraz at redhat.com Tue Sep 1 16:31:15 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 01 Sep 2020 18:31:15 +0200 Subject: OpenSSL 3.0.0 security concerns using dynamic providers In-Reply-To: <12856b4928045fb28452945e0a18f8983b3f6c44.camel@redhat.com> References: <12856b4928045fb28452945e0a18f8983b3f6c44.camel@redhat.com> Message-ID: <8cc8efa699ff499e5bb2a6e0feb4ad450ed0ffbc.camel@redhat.com> On Tue, 2020-09-01 at 18:13 +0200, Tomas Mraz wrote: > On Tue, 2020-09-01 at 15:46 +0000, CODERE Carl-Eric wrote: > > > -----Original Message----- > > > From: Matt Caswell [mailto:matt at openssl.org] > > > Sent: mardi 1 septembre 2020 18:57 > > > To: CODERE Carl-Eric ; openssl- > > > users at openssl.org > > > Subject: Re: OpenSSL 3.0.0 security concerns using dynamic > > > providers > > > > > > > > > > > > On 01/09/2020 03:01, CODERE Carl-Eric wrote: > > > > 1. Replacing the provider by a tampered provider by replacing > > > > the > > > > shared/dynamic library. This can partially be protected by the > > > > caller > > > > verifying the hash of the provider before calling it, will > > > > OpenSSL > > > > 3.0.0 do this, or will need to be done at integrator level? > > > > > > The OpenSSL 3.0 FIPS module checks its own integrity when it is > > > first loaded. > > > This is really intended as a sanity check. It doesn't really > > > protect against > > > malicious changes. > > > > > > I don't really see why you see this is a security concern. Of > > > course, yes, if a > > > malicious user was able to replace the shared/dynamic library > > > then > > > this > > > would be a serious security problem. But why is this a greater > > > risk > > > with > > > shared/dynamic libraries compared to static linking? In much the > > > same way if > > > a malicious user can change the application binary then you have > > > a > > > security > > > problem. > > > > > > In other words if a malicious user has the ability to change any > > > arbitrary > > > application executable or shared library then you have a security > > > problem. > > > The risk doesn't really change with dynamic vs static linking. > > > > > Greetings, > > Thanks for the quick reply, actually from the > > perspective of mobile > > security, once the platform sandbox has been compromised, it is > > much > > easier for an attacker to replace a shared library with another > > one > > he has > > programmed than statically analyzing a properly stripped > > application > > to discover > > its cryptographic entry points and then patching it and/or hooking > > it > > (In the > > shared library the entry point names are clearly visible)... Hence > > final asset > > loss is the same, but the actual time to do the attack would be > > different. > > The goal is to add extra complexity for the attack, not to avoid it > > completely. > > You can still build and link openssl without shared library loading > support. The default provider will be then built-in. Of course, you > then won't be able to load any external providers. But yeah, I only now realized you are talking here about FIPS provider and that cannot be built-in because of the need for the checksum. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From simonkbaby at gmail.com Wed Sep 2 00:28:09 2020 From: simonkbaby at gmail.com (SIMON BABY) Date: Tue, 1 Sep 2020 17:28:09 -0700 Subject: query on api PKCS12_parse() Message-ID: Hello, I am using the api PKCS12_parse for creating the private key and certs. When I send a wrong password to the API, my process crashes in the call PKCS12_parse(). The same API works fine when I pass the correct passwd. Can someone please help to send some clues to resolve/debug this issue. p12 = d2i_PKCS12_fp(fp, NULL); PKCS12_parse(p12, passwd, &pkey, &cert, &ca)) Regards Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Wed Sep 2 03:09:18 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 01 Sep 2020 23:09:18 -0400 Subject: Cert hot-reloading In-Reply-To: <20200830232847.GH44511@straasha.imrryr.org> References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> Message-ID: <11396.1599016158@localhost> Having read through the thread, I think that Viktor is assuming that the private key will always be replaced. My reading of the CABForum push towards 13 month validity, and the LetsEncrypt 90-day process it that private key replacements are not necessarily replaced that often. The shortest *certificate* lifetimes are driven by a desire to eliminate some CRL/OCSP stuff a la RFC 8739 (was draft-ietf-acme-star) Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) Watching the certificate file and reloading it would suffice for 90% of uses. Viktor suggests using the combined private-key/certificate format. I think that's a undesired constrait. For the paranoid who want to encrypt their private keys and type passphrases when whey reload would probably not like that. It probably also fails if the private key is in an HSM (and you don't replace that private key as often, I imagine). In all algorithms I'm aware of, the public key can be derived from the private key, so we can check if the loaded private key matches the public key in the certificate. (I seem to remember some attack on some systems where doing that checked defeated the attack, but I can't recall which one) So it seems that we can easily use the mis-match of the keys to trigger a check on the private key file, and if we can't load it (passphrase, etc), then we could actually reject reloading the certificate file. The operator has clearly done something wrong, or the file system hasn't caught up to a consistent state... and the operator should do a manual reload/restart. Oh, and while I think that openssl should have some reference code that uses openat(), I rather suggest that this is reference code. Let the application deal with setting up and processing the file update events, and calling OpenSSL to potentially load a new certificate/key pair. OpenSSL should focus on the reference counting needed underneath. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Sep 2 03:48:49 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 1 Sep 2020 23:48:49 -0400 Subject: Cert hot-reloading In-Reply-To: <11396.1599016158@localhost> References: <58FWFQ.39F8042CDQTO1@xoe.solutions> <20200830232847.GH44511@straasha.imrryr.org> <11396.1599016158@localhost> Message-ID: <20200902034849.GA44511@straasha.imrryr.org> On Tue, Sep 01, 2020 at 11:09:18PM -0400, Michael Richardson wrote: > My reading of the CABForum push towards 13 month validity, and the > LetsEncrypt 90-day process it that private key replacements are not > necessarily replaced that often. Perhaps so, but the mechanism needs to be general enough to avoid making that assumption. > Viktor suggests using the combined private-key/certificate format. > I think that's a undesired constrait. > For the paranoid who want to encrypt their private keys and type passphrases > when whey reload would probably not like that. The encryption of private keys is at the PEM object level, not at the file level, so encrypted keys co?xist just fine with cleartext cert chains in the same file. > It probably also fails if the private key is in an HSM (and you don't > replace that private key as often, I imagine). This is a better argument for also offering a multifile model, because indeed in that case the key is not even in a file, all one has is some sort of key handle. I'm much less familiar with how one handles key and cert rotation with HSMs. This used to mean engines, but all that is changing in OpenSSL 3.0.0, so TBD. If both the key and the cert chain became just handles to data fetched each time they're needed, then the entire problem might become moot. But it may prove tricky to present a uniform interface to both PEM files and HSMs that works robustly for both under their respective operational models. > In all algorithms I'm aware of, the public key can be derived from the private key, > so we can check if the loaded private key matches the public key in the > certificate. (I seem to remember some attack on some systems where doing that > checked defeated the attack, but I can't recall which one) Yes, OpenSSL generally supports checking that the public key in the leaf certificate matches the public key portion of the private key, but in fact with HSMs where the public and private keys may be just opaque handles, such a check is not always possible, in that case one might actually need to attempt to sign something, and see whether the signature is valid... I don't recall the details. See https://github.com/openssl/openssl/blob/master/ssl/ssl_rsa.c#L148-L192 and related functions and also: https://github.com/openssl/openssl/blob/master/ssl/ssl_rsa.c#L148-L192 > So it seems that we can easily use the mis-match of the keys to trigger a > check on the private key file, and if we can't load it (passphrase, etc), > then we could actually reject reloading the certificate file. Right, and then backoff, retry, etc. Folks who elect a single-file format, and execute rollovers correctly can avoid the associated costs. > Oh, and while I think that openssl should have some reference code that uses > openat(), I rather suggest that this is reference code. Let the application > deal with setting up and processing the file update events, and calling > OpenSSL to potentially load a new certificate/key pair. > OpenSSL should focus on the reference counting needed underneath. Yes, that's fine, but in that case more explicit code is needed at the application layer to "make it go". Lots of tradeoffs. In any case this is a good project for someone suitably skilled. Ideally, design and documentation before code! -- Viktor. From M.Roos at f1-outsourcing.eu Thu Sep 3 07:42:07 2020 From: M.Roos at f1-outsourcing.eu (Marc Roos) Date: Thu, 3 Sep 2020 09:42:07 +0200 Subject: Testing In-Reply-To: Message-ID: <"H00000710017af05.1599118927.sx.f1-outsourcing.eu*"@MHS> PTR record, SPF, DKIM and DMARC are also set by spammers, and sometimes even just before a spam run. It is either choosing to do amazons work or not having any work. If more and more are blocking the amazon cloud it would make their clients leave and this finally migth have them spend more on their abuse department. -----Original Message----- To: openssl-users at openssl.org Subject: Re: Testing On 2020-08-31 16:28, Marc Roos wrote: > Why don't you block the whole compute cloud of amazon? > ec2-3-21-30-127.us-east-2.compute.amazonaws.com Please note, that at least our company hosts a secondary MX in the EC2 cloud, with the option to direct my posts to the list through that server.? However proper PTR record, SPF, DKIM and DMARC checks should all pass for such posts. Thus rather than blindly blacklisting the Amazon hosting service, maybe make the OpenSSL mail server check those things to catch erroneous transmissions from web servers. > > -----Original Message----- > > To: openssl-users at openssl.org > Subject: Testing > > > > -- > -----BEGIN EMAIL SIGNATURE----- > > The Gospel for all Targeted Individuals (TIs): > > [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. > Embassy Workers > > Link: > https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave > .html > > ********************************************************************** > ** > ******************** > > Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic > Qualifications as at 14 Feb 2019 and refugee seeking attempts at the > United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug > 2019) and Australia (25 Dec 2019 to 9 Jan 2020): > > [1] https://tdtemcerts.wordpress.com/ > > [2] https://tdtemcerts.blogspot.sg/ > > [3] https://www.scribd.com/user/270125049/Teo-En-Ming > > -----END EMAIL SIGNATURE----- > > 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 From levitte at openssl.org Thu Sep 3 09:16:13 2020 From: levitte at openssl.org (Richard Levitte) Date: Thu, 03 Sep 2020 11:16:13 +0200 Subject: Testing In-Reply-To: <"H00000710017aa24.1598884133.sx.f1-outsourcing.eu*"@MHS> References: <"H00000710017aa24.1598884133.sx.f1-outsourcing.eu*"@MHS> Message-ID: <87d033te3m.wl-levitte@openssl.org> For a rogue test message? However, a quick search through the mail log shows that indeed, there are messages coming from random Amazon AWS hosts that are... "interesting" I smirk a bit when I see this in our mail logs: Sep 2 10:36:06 mta postfix/smtpd[1091]: warning: non-SMTP command from ec2-184-72-79-140.compute-1.amazonaws.com[184.72.79.140]: GET / HTTP/1.1 As for blocking, we rely quite a bit on available spam-hauses, such as zen.spamhaus.org, and they do catch the occasional individual Amazon AWS machine (seen in our logs), so it seems that they do get reports on misbehaving machinery. Apart from hightened emotions (I understand them, believe you me), are there tangible reasons for applying the kind of arbitrary sledge-hammer that you propose? I would rather not, unless I really must. Cheers, Richard On Mon, 31 Aug 2020 16:28:53 +0200, Marc Roos wrote: > > > Why don't you block the whole compute cloud of amazon? > ec2-3-21-30-127.us-east-2.compute.amazonaws.com > > > -----Original Message----- > > To: openssl-users at openssl.org > Subject: Testing > > > > -- > -----BEGIN EMAIL SIGNATURE----- > > The Gospel for all Targeted Individuals (TIs): > > [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. > Embassy Workers > > Link: > https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html > > ************************************************************************ > ******************** > > Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic > Qualifications as at 14 Feb 2019 and refugee seeking attempts at the > United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug > 2019) and Australia (25 Dec 2019 to 9 Jan 2020): > > [1] https://tdtemcerts.wordpress.com/ > > [2] https://tdtemcerts.blogspot.sg/ > > [3] https://www.scribd.com/user/270125049/Teo-En-Ming > > -----END EMAIL SIGNATURE----- > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jb-openssl at wisemo.com Thu Sep 3 10:18:24 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 3 Sep 2020 12:18:24 +0200 Subject: Testing In-Reply-To: <"H00000710017af05.1599118927.sx.f1-outsourcing.eu*"@MHS> References: <"H00000710017af05.1599118927.sx.f1-outsourcing.eu*"@MHS> Message-ID: On 2020-09-03 09:42, Marc Roos wrote: > > PTR record, SPF, DKIM and DMARC are also set by spammers, and sometimes > even just before a spam run. It is either choosing to do amazons work or > not having any work. If more and more are blocking the amazon cloud it > would make their clients leave and this finally migth have them spend > more on their abuse department. > > For your information, AWS apparently blocks TCP port 25 unless the customer (not someone hacking an AWS instance) explicitly requests a custom PTR record using a form where the customer promises not to Spam. Custom PTR records don't look like ec2-184-72-79-140.compute-1.amazonaws.com . I am unsure how Richard's example that obviously tricked a server to send a HTTP request to the OpenSSL mail server got past the port 25 block (this appears to be a common form of server side request forgery). > > > -----Original Message----- > To: openssl-users at openssl.org > Subject: Re: Testing > > On 2020-08-31 16:28, Marc Roos wrote: >> Why don't you block the whole compute cloud of amazon? >> ec2-3-21-30-127.us-east-2.compute.amazonaws.com > Please note, that at least our company hosts a secondary MX in the EC2 > cloud, with the option to direct my posts to the list through that > server.? However proper PTR record, SPF, DKIM and DMARC checks should > all pass for such posts. > > Thus rather than blindly blacklisting the Amazon hosting service, maybe > make the OpenSSL mail server check those things to catch erroneous > transmissions from web servers. > > >> >> -----Original Message----- >> >> To: openssl-users at openssl.org >> Subject: Testing >> >> >> >> -- >> -----BEGIN EMAIL SIGNATURE----- >> >> The Gospel for all Targeted Individuals (TIs): >> >> [The New York Times] Microwave Weapons Are Prime Suspect in Ills of > U.S. >> Embassy Workers >> >> Link: >> https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave >> .html >> >> ********************************************************************** >> ** >> ******************** >> >> Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic >> Qualifications as at 14 Feb 2019 and refugee seeking attempts at the >> United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug >> 2019) and Australia (25 Dec 2019 to 9 Jan 2020): >> >> [1] https://tdtemcerts.wordpress.com/ >> >> [2] https://tdtemcerts.blogspot.sg/ >> >> [3] https://www.scribd.com/user/270125049/Teo-En-Ming >> >> -----END EMAIL SIGNATURE----- >> >> > > > 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 From M.Roos at f1-outsourcing.eu Thu Sep 3 10:25:02 2020 From: M.Roos at f1-outsourcing.eu (Marc Roos) Date: Thu, 3 Sep 2020 12:25:02 +0200 Subject: Testing In-Reply-To: Message-ID: <"H00000710017af46.1599128702.sx.f1-outsourcing.eu*"@MHS> Why are you defending amazon? Everyone processing significant mail and http traffic is complaining about them. They were even listed in spamhaus's top 10 abuse networks (until they started contributing to them?) From jb-openssl at wisemo.com Thu Sep 3 10:34:18 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 3 Sep 2020 12:34:18 +0200 Subject: Testing In-Reply-To: <"H00000710017af46.1599128702.sx.f1-outsourcing.eu*"@MHS> References: <"H00000710017af46.1599128702.sx.f1-outsourcing.eu*"@MHS> Message-ID: On 2020-09-03 12:25, Marc Roos wrote: > > Why are you defending amazon? Everyone processing significant mail and > http traffic is complaining about them. They were even listed in > spamhaus's top 10 abuse networks (until they started contributing to > them?) > Because we are sending non-spam mail from an AWS hosted server, and would be seriously inconvenienced if they got generally banned by mail recipients. And we did check that they were not in bad standing at spamhaus.org before choosing them to host that server. Some of their competitors failed those checks. 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 From ymazin at opentext.com Thu Sep 3 23:45:28 2020 From: ymazin at opentext.com (Yury Mazin) Date: Thu, 3 Sep 2020 23:45:28 +0000 Subject: Question about TLS 1.3 and openssl -cipher aNULL option Message-ID: Hello, We have a server was originaly using OpenSSL 1.0.2h. Server is configured to use SSL ciphers as following ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT When openssl client tries to connect to this server with command openssl s_client -connect localhost:8101-cipher aNULL it fails, because any aNULL ciphers are not available per server configuration. We have now upgraded server to use OpenSSL 1.1.1f. The current behavior is this: client can connect using the same command openssl s_client -connect localhost:8101 -cipher aNULL or openssl s_client -tls1_3 -connect localhost:8101 -cipher aNULL while the same connect attempt using TLS1.2 protocol would still fail openssl s_client -tls1_2 -connect localhost:8001-cipher aNULL Would the fact that I can connect to the server using TLS 1.3 using the following command (specifically, using -cipher aNULL, while server is configured to exclude all aNULL cipher suites) considered a security violation? openssl s_client -tls1_3 -connect localhost:8001 -cipher aNULL Also, if this a security violation, how this can be addressed in the server configuration? Lastly, if this is not a security violation, please explain. Thank you, Yury Mazin -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Sep 4 00:05:47 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Sep 2020 20:05:47 -0400 Subject: Question about TLS 1.3 and openssl -cipher aNULL option In-Reply-To: References: Message-ID: <20200904000547.GE44511@straasha.imrryr.org> On Thu, Sep 03, 2020 at 11:45:28PM +0000, Yury Mazin via openssl-users wrote: > We have a server was originaly using OpenSSL 1.0.2h. Server is > configured to use SSL ciphers as following: > > ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT > > When openssl client tries to connect to this server with command > > openssl s_client -connect localhost:8101 -cipher aNULL > > it fails, because any aNULL ciphers are not available per server > configuration. As expected. > We have now upgraded server to use OpenSSL 1.1.1f. The current > behavior is this: client can connect using the same command > > openssl s_client -connect localhost:8101 -cipher aNULL > or > openssl s_client -tls1_3 -connect localhost:8101 -cipher aNULL The "-cipher" command affects only the TLS <= 1.2 a la certe ciphersuites, but not the TLS 1.3 chinese menu cipher list. So the TLS 1.3 ciphers remain unaffected and these send a server certificate that the client ignores. > while the same connect attempt using TLS1.2 protocol would still fail > > openssl s_client -tls1_2 -connect localhost:8001 -cipher aNULL As expected. > Would the fact that I can connect to the server using TLS 1.3 using > the following command (specifically, using -cipher aNULL, while server > is configured to exclude all aNULL cipher suites) considered a > security violation? No. This is expected behaviour. -- Viktor. From bkaduk at akamai.com Fri Sep 4 00:12:53 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 3 Sep 2020 17:12:53 -0700 Subject: Question about TLS 1.3 and openssl -cipher aNULL option In-Reply-To: References: Message-ID: <20200904001252.GI20623@akamai.com> On Thu, Sep 03, 2020 at 11:45:28PM +0000, Yury Mazin via openssl-users wrote: > Hello, > > We have a server was originaly using OpenSSL 1.0.2h. > Server is configured to use SSL ciphers as following > ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT > When openssl client tries to connect to this server with command > openssl s_client -connect localhost:8101-cipher aNULL > it fails, because any aNULL ciphers are not available per server configuration. > We have now upgraded server to use OpenSSL 1.1.1f. > The current behavior is this: client can connect using the same command > openssl s_client -connect localhost:8101 -cipher aNULL > or > openssl s_client -tls1_3 -connect localhost:8101 -cipher aNULL > > while the same connect attempt using TLS1.2 protocol would still fail > > openssl s_client -tls1_2 -connect localhost:8001-cipher aNULL > > Would the fact that I can connect to the server using TLS 1.3 using the following command (specifically, using -cipher aNULL, while server is configured to exclude all aNULL cipher suites) considered a security violation? > > openssl s_client -tls1_3 -connect localhost:8001 -cipher aNULL > > Also, if this a security violation, how this can be addressed in the server configuration? > Lastly, if this is not a security violation, please explain. It is not a security violation, because you are using TLS 1.3 ciphers, and there are not any NULL-encryption TLS 1.3 ciphers. Configuration of TLS 1.3 ciphers and ciphers for previous versions of TLS are separate (since, at a protocol level, they serve different roles). See the documentation for s_client/s_server -ciphersuites for more information about TLS 1.3 ciphers. -Ben From M.Roos at f1-outsourcing.eu Fri Sep 4 07:52:38 2020 From: M.Roos at f1-outsourcing.eu (Marc Roos) Date: Fri, 4 Sep 2020 09:52:38 +0200 Subject: Testing In-Reply-To: Message-ID: <"H00000710017b0e4.1599205958.sx.f1-outsourcing.eu*"@MHS> As if amazon is the only provider you can host an mta. As I wrote before your laziness to find a proper provider solution, causes work at other providers. The only advantage that your type of customer has, is that your brains all work the same going for cheap and easy. So if I do block such a network, I block of useless traffic. I think amazon is expanding/changing strategy. Now they are even routing to dubious ip ranges. traceroute -n 185.187.119.175 traceroute to 185.187.119.175 (185.187.119.175), 30 hops max, 60 byte packets 4 92.63.170.153 0.516 ms 0.522 ms 0.534 ms 5 193.239.116.110 1.779 ms 1.154 ms 1.748 ms 6 52.93.112.28 4.971 ms 52.93.112.24 2.019 ms 52.93.112.28 4.677 ms 7 54.239.114.149 1.292 ms 54.239.114.103 1.629 ms 54.239.114.155 1.095 ms 8 * * * 9 * * * 185.187.119.2 mta119-2.msgfocus.com. 185.187.119.3 mta119-3.msgfocus.com. 185.187.119.4 mta119-4.msgfocus.com. 185.187.119.5 mta119-5.msgfocus.com. 185.187.119.6 mta119-6.msgfocus.com. 185.187.119.7 mta119-7.msgfocus.com. 185.187.119.8 mta119-8.msgfocus.com. 185.187.119.9 mta119-9.msgfocus.com. 185.187.119.10 mta119-10.msgfocus.com. 185.187.119.11 mta119-11.msgfocus.com. 185.187.119.12 mta119-12.msgfocus.com. 185.187.119.13 mta119-13.msgfocus.com. 185.187.119.14 mta119-14.msgfocus.com. 185.187.119.15 mta119-15.msgfocus.com. 185.187.119.16 mta119-16.msgfocus.com. 185.187.119.17 mta119-17.msgfocus.com. 185.187.119.18 mta119-18.msgfocus.com. 185.187.119.19 mta119-19.msgfocus.com. 185.187.119.20 mta119-20.msgfocus.com. 185.187.119.21 mta119-21.msgfocus.com. 185.187.119.22 mta119-22.msgfocus.com. 185.187.119.23 mta119-23.msgfocus.com. 185.187.119.24 mta119-24.msgfocus.com. 185.187.119.25 mta119-25.msgfocus.com. 185.187.119.26 mta119-26.msgfocus.com. 185.187.119.27 mta119-27.msgfocus.com. 185.187.119.28 mta119-28.msgfocus.com .. .. 185.187.119.223 mta119-223.msgfocus.com. 185.187.119.224 mta119-224.msgfocus.com. 185.187.119.225 mta119-225.msgfocus.com. 185.187.119.226 mta119-226.msgfocus.com. 185.187.119.227 mta119-227.msgfocus.com. 185.187.119.228 mta119-228.msgfocus.com. 185.187.119.229 mta119-229.msgfocus.com. 185.187.119.230 mta119-230.msgfocus.com. 185.187.119.231 mta119-231.msgfocus.com. 185.187.119.232 mta119-232.msgfocus.com. 185.187.119.233 mta119-233.msgfocus.com. 185.187.119.234 mta119-234.msgfocus.com. 185.187.119.235 mta119-235.msgfocus.com. 185.187.119.236 mta119-236.msgfocus.com. 185.187.119.237 mta119-237.msgfocus.com. 185.187.119.238 mta119-238.msgfocus.com. 185.187.119.239 mta119-239.msgfocus.com. 185.187.119.240 mta119-240.msgfocus.com. 185.187.119.241 mta119-241.msgfocus.com. 185.187.119.242 mta119-242.msgfocus.com. 185.187.119.243 mta119-243.msgfocus.com. 185.187.119.244 mta119-244.msgfocus.com. 185.187.119.245 mta119-245.msgfocus.com. 185.187.119.246 mta119-246.msgfocus.com. 185.187.119.247 mta119-247.msgfocus.com. 185.187.119.248 mta119-248.msgfocus.com. 185.187.119.249 mta119-249.msgfocus.com. 185.187.119.250 mta119-250.msgfocus.com. 185.187.119.251 mta119-251.msgfocus.com. 185.187.119.252 mta119-252.msgfocus.com. 185.187.119.253 mta119-253.msgfocus.com. 185.187.119.254 mta119-254.msgfocus.com. From hack3rcon at yahoo.com Fri Sep 4 10:20:17 2020 From: hack3rcon at yahoo.com (Jason Long) Date: Fri, 4 Sep 2020 10:20:17 +0000 (UTC) Subject: =?UTF-8?Q?A_question_about_the_=E2=80=9Clocalhost?= =?UTF-8?Q?.key=E2=80=9D_and_=E2=80=9Clocalhost.crt=E2=80=9D_files.?= References: <642642642.2299553.1599214817676.ref@mail.yahoo.com> Message-ID: <642642642.2299553.1599214817676@mail.yahoo.com> Hello, I think??localhost.crt? and ?localhost.key? files using by Apache and they are mandatory for get a HTTPS certificate. Some tools like "Certbot" need them. If these files deleted then how can I regenerate them? Is below command OK? # openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt I found "/usr/libexec/httpd-ssl-gencerts" tool. Is it OK too? The "localhost" is the name of my server? If my server name in "/etc/hosts" file is "my-example.net" then these files name must be "my-example.net.key" and "my-example.net.crt" ? I'm thankful if anyone answer to my questions clearly. Thank you. From tomiii at tomiii.com Fri Sep 4 16:06:35 2020 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Fri, 4 Sep 2020 09:06:35 -0700 Subject: =?UTF-8?B?UmU6IEEgcXVlc3Rpb24gYWJvdXQgdGhlIOKAnGxvY2FsaG9zdC5rZXnigJ0gYW5kIOKAnA==?= =?UTF-8?B?bG9jYWxob3N0LmNydOKAnSBmaWxlcy4=?= In-Reply-To: <642642642.2299553.1599214817676@mail.yahoo.com> References: <642642642.2299553.1599214817676.ref@mail.yahoo.com> <642642642.2299553.1599214817676@mail.yahoo.com> Message-ID: The filenames themselves are insignificant. You can name them anything you want. The apache configuration file(s) contain key/value pairs where SSLCertificateFile specifies the path to the file containing your certificate and SSLCertificateKeyFile specifies the path to the file containing your private key. There is no requirement that these filenames match the name of your server. It sounds to me like you don't understand how certificates work. I suggest you read a certificate tutorial such as this one: http://www.steves-internet-guide.com/ssl-certificates-explained/ Once you understand how certificates work, I suggest reading the apache documentation available here: https://httpd.apache.org/docs/current/ and, specifically, the documentation for mod_ssl available here: https://httpd.apache.org/docs/current/mod/mod_ssl.html Regards, Tom.III On Fri, Sep 4, 2020 at 3:20 AM Jason Long via openssl-users < openssl-users at openssl.org> wrote: > Hello, > I think ?localhost.crt? and ?localhost.key? files using by Apache and they > are mandatory for get a HTTPS certificate. Some tools like "Certbot" need > them. > If these files deleted then how can I regenerate them? Is below command OK? > > # openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout > /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt > > I found "/usr/libexec/httpd-ssl-gencerts" tool. Is it OK too? > > The "localhost" is the name of my server? If my server name in > "/etc/hosts" file is "my-example.net" then these files name must be > "my-example.net.key" and "my-example.net.crt" ? > > I'm thankful if anyone answer to my questions clearly. > > Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ymazin at opentext.com Fri Sep 4 19:00:01 2020 From: ymazin at opentext.com (Yury Mazin) Date: Fri, 4 Sep 2020 19:00:01 +0000 Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option In-Reply-To: <20200904001252.GI20623@akamai.com> References: , <20200904001252.GI20623@akamai.com> Message-ID: Thank you Benjamin, According to OpenSSL , aNULL stands for no-authentication. NULL-ciphers that you mention would be part of eNULL group, that offer no encryption. Does it mean that all 3 default protocols of TLS 1.3 offer no authentication (because they are listed under command openssl ciphers -v -s aNULL 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 Thank you, Yury ________________________________ From: Benjamin Kaduk Sent: Thursday, September 3, 2020 5:12 PM To: Yury Mazin Cc: openssl-users at openssl.org Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Thu, Sep 03, 2020 at 11:45:28PM +0000, Yury Mazin via openssl-users wrote: > Hello, > > We have a server was originaly using OpenSSL 1.0.2h. > Server is configured to use SSL ciphers as following > ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT > When openssl client tries to connect to this server with command > openssl s_client -connect localhost:8101-cipher aNULL > it fails, because any aNULL ciphers are not available per server configuration. > We have now upgraded server to use OpenSSL 1.1.1f. > The current behavior is this: client can connect using the same command > openssl s_client -connect localhost:8101 -cipher aNULL > or > openssl s_client -tls1_3 -connect localhost:8101 -cipher aNULL > > while the same connect attempt using TLS1.2 protocol would still fail > > openssl s_client -tls1_2 -connect localhost:8001-cipher aNULL > > Would the fact that I can connect to the server using TLS 1.3 using the following command (specifically, using -cipher aNULL, while server is configured to exclude all aNULL cipher suites) considered a security violation? > > openssl s_client -tls1_3 -connect localhost:8001 -cipher aNULL > > Also, if this a security violation, how this can be addressed in the server configuration? > Lastly, if this is not a security violation, please explain. It is not a security violation, because you are using TLS 1.3 ciphers, and there are not any NULL-encryption TLS 1.3 ciphers. Configuration of TLS 1.3 ciphers and ciphers for previous versions of TLS are separate (since, at a protocol level, they serve different roles). See the documentation for s_client/s_server -ciphersuites for more information about TLS 1.3 ciphers. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Sep 4 19:10:22 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 4 Sep 2020 15:10:22 -0400 Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option In-Reply-To: References: <20200904001252.GI20623@akamai.com> Message-ID: <20200904191022.GH44511@straasha.imrryr.org> On Fri, Sep 04, 2020 at 07:00:01PM +0000, Yury Mazin via openssl-users wrote: > Thank you Benjamin, > > According to OpenSSL , aNULL stands for no-authentication. Specifically, SSL 3.0 through TLS 1.2 ciphers in which the server and client exchange no certificates, and the TLS handshake consists largely of an unsigned anonymous ephemeral DH or ECDH key exchang. TLS 1.3 dropped support for anonymous DH and ECDH. Server certificates are *required. And the all-in-one ciphersuites of TLS <= 1.2, are replaced with separately negotiated components. As a result of which, in OpenSSL 1.1.1 and later, they are controlled via a different set of APIs and command-line options. Specifically, in your case, the "-ciphers aNULL" option only applies to TLS <= 1.2 > Does it mean that all 3 default protocols of TLS 1.3 offer no > authentication No. None of them "support no authentication" (which is not even strictly true, it is the protocol that does not support "no authentication", the TLS 1.3 ciphers are simply silent re certificate algorithm selection), but the "-cipher aNULL" is simply not used when TLS 1.3 is negotiated, so your question is makes incorrect assumptions to reach its tentative conclusions. -- Viktor. From ymazin at opentext.com Fri Sep 4 19:43:06 2020 From: ymazin at opentext.com (Yury Mazin) Date: Fri, 4 Sep 2020 19:43:06 +0000 Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option In-Reply-To: <20200904191022.GH44511@straasha.imrryr.org> References: <20200904001252.GI20623@akamai.com> , <20200904191022.GH44511@straasha.imrryr.org> Message-ID: Viktor, Thank you for clarifying it. Yury ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Friday, September 4, 2020 12:10 PM To: openssl-users at openssl.org Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Fri, Sep 04, 2020 at 07:00:01PM +0000, Yury Mazin via openssl-users wrote: > Thank you Benjamin, > > According to OpenSSL , aNULL stands for no-authentication. Specifically, SSL 3.0 through TLS 1.2 ciphers in which the server and client exchange no certificates, and the TLS handshake consists largely of an unsigned anonymous ephemeral DH or ECDH key exchang. TLS 1.3 dropped support for anonymous DH and ECDH. Server certificates are *required. And the all-in-one ciphersuites of TLS <= 1.2, are replaced with separately negotiated components. As a result of which, in OpenSSL 1.1.1 and later, they are controlled via a different set of APIs and command-line options. Specifically, in your case, the "-ciphers aNULL" option only applies to TLS <= 1.2 > Does it mean that all 3 default protocols of TLS 1.3 offer no > authentication No. None of them "support no authentication" (which is not even strictly true, it is the protocol that does not support "no authentication", the TLS 1.3 ciphers are simply silent re certificate algorithm selection), but the "-cipher aNULL" is simply not used when TLS 1.3 is negotiated, so your question is makes incorrect assumptions to reach its tentative conclusions. -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hack3rcon at yahoo.com Fri Sep 4 20:54:41 2020 From: hack3rcon at yahoo.com (Jason Long) Date: Fri, 4 Sep 2020 20:54:41 +0000 (UTC) Subject: Tunelling using OpenSSL. References: <1287683144.2515926.1599252881815.ref@mail.yahoo.com> Message-ID: <1287683144.2515926.1599252881815@mail.yahoo.com> Hello,Is it possible to tunnel a connection by OpenSSL? For example, use OpenSSL and a browser to encrypt browsing. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Sep 4 21:44:29 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 4 Sep 2020 21:44:29 +0000 Subject: Tunelling using OpenSSL. In-Reply-To: <1287683144.2515926.1599252881815@mail.yahoo.com> References: <1287683144.2515926.1599252881815.ref@mail.yahoo.com> <1287683144.2515926.1599252881815@mail.yahoo.com> Message-ID: > From: openssl-users On Behalf Of Jason Long via openssl-users > Sent: Friday, 4 September, 2020 16:55 [Your message had a Reply-To header directing replies to your address rather than the list. If you did that deliberately, please don't. It's rude. You post here, you read here.] > Is it possible to tunnel a connection by OpenSSL? Yes, but probably not the way you mean. The OpenSSL project delivers a variety of artifacts, including: - a library (typically built as a collection of binaries, but notionally a single library for most purposes) that implements TLS, various cryptographic primitives, and related useful functions - a command-line utility (also named "openssl") which can be used for testing, manipulating cryptographic file formats, and other purposes - SDK components such as headers for developing applications that use OpenSSL - documentation What it does NOT include is an end-user application for general-purpose cryptography, similar to what OpenSSH provides. That's a rather different function. Of course you can tunnel anything through a TLS connection; you can tunnel anything through anything. Any channel that lets you convey unbounded information entropy, at whatever rate, can be used as a tunnel. You can tunnel IP traffic in DNS requests or carrier-pidgeon messages. But OpenSSL isn't going to do that for you. There are generic tunnel applications (e.g. stunnel) that use TLS and (I believe this is true of stunnel) specifically use OpenSSL as their TLS implementation, but those are separate projects. Now, you could play games with, say, NetCat and the openssl utility to create proxy TLS connections. For example, on the client side: 1. ncat -L ... | openssl s_client ... 2. connect plaintext client to the ncat port via loopback And on the server side: 1. openssl s_server ... | ncat ... 2. ncat connects to the server via loopback That sort of thing might even have its uses, for example as a simple exfiltration shroud. But it's not something you want to use under normal circumstances. > For example, use OpenSSL and a browser to encrypt browsing. Er ... you know browsers already do that, right? That's the quintessential TLS application. It might help if you explained what you're actually trying to accomplish, and why. -- Michael Wojcik From matt at openssl.org Sat Sep 5 09:15:04 2020 From: matt at openssl.org (Matt Caswell) Date: Sat, 5 Sep 2020 10:15:04 +0100 Subject: OpenSSL is looking for a full time Administrator and Manager Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL Management Committee are looking to hire a full time Administrator and Manager. Details of the role can be found here: https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/ To apply please send your cover letter and resume to jobs at openssl.org by 20th September 2020. Regards, The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl9TVxgACgkQ2cTSbQ5g RJHKGggAn1YGhR7UwtgVXTMWUKiv4jYpXd5OaHonAaUwIFdkXUzBmmEq9PP1Thw/ A4rQ/anDZ6SfRlFaGxQB1Fyz5LRyNDhHA48lM0v/Yw55S6NfSrMaPcGRuU8Odikf 4Nd7zzD3RcOgfhphdHEXz7ykMi90ATVcLTVnaoQtkvw5LHeiXzqzBLT9+WEcENWU 4z2WLJRGTpwIBfYfm6/NQPTDzsy/VBoVW/nl1mx6jkvL2UxuOdp4rfTMz9lu3IPk CnkujXxDIVSn02xSiRccj3ujnFqOq4lwtSiOzOl/HowlCDY6DmRhIvsu1PnPzJ15 v5JbQhDpk4kHjalCsJq2QfdcP41pDQ== =h9gU -----END PGP SIGNATURE----- From gisle.vanem at gmail.com Tue Sep 8 08:34:47 2020 From: gisle.vanem at gmail.com (Gisle Vanem) Date: Tue, 8 Sep 2020 10:34:47 +0200 Subject: Empty directories Message-ID: <97dd7e34-fa18-df2d-479a-f7e6798d494e@gmail.com> I've noted that when build OpenSSL using MSVC, some empty directories are created: ./crypto/include ./crypto/providers I configured with: perl.exe -I. -I./util/perl Configure VC-WIN32-ONECORE no-makedepend enable-zlib enable-trace enable-md2 no-ec_nistp_64_gcc_128 enable-asan enable-aria enable-rc5 enable-heartbeats --prefix=/foo/bar --openssldir=/foo/bar I see that the generated Makefile has lots of '-I "crypto\include"'. AFAICS needlessly. But I see no 'mkdir crypto\include' anywhere. And I don't see 'mkdir-p.pl' is used to create these. So how are these empty directories created/used? -- --gv From matthias.st.pierre at ncp-e.com Tue Sep 8 10:25:11 2020 From: matthias.st.pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 8 Sep 2020 12:25:11 +0200 Subject: Empty directories In-Reply-To: <97dd7e34-fa18-df2d-479a-f7e6798d494e@gmail.com> References: <97dd7e34-fa18-df2d-479a-f7e6798d494e@gmail.com> Message-ID: <7629613f-98e1-1278-bdc2-fe3a23ec85eb@ncp-e.com> Hmmm... that might be a remnant which was forgotten during the reorganization of the header files, see commit [1] of pull request [2]. It tested it on master, it seems like the empty directories are created by the Configure script. Would you mind opening a GitHub issue for it? Regards, Matthias [1] https://github.com/openssl/openssl/commit/25f2138b0ab54a65ba713c093ca3734d88f7cb51 [2] https://github.com/openssl/openssl/pull/9333 On 08.09.20 10:34, Gisle Vanem wrote: > I've noted that when build OpenSSL using MSVC, > some empty directories are created: > ? ./crypto/include > ? ./crypto/providers > > I configured with: > ? perl.exe -I. -I./util/perl Configure VC-WIN32-ONECORE no-makedepend > ? enable-zlib enable-trace enable-md2 no-ec_nistp_64_gcc_128 > ? enable-asan enable-aria enable-rc5 enable-heartbeats --prefix=/foo/bar > ? --openssldir=/foo/bar > > I see that the generated Makefile has lots of > '-I "crypto\include"'. AFAICS needlessly. But I > see no 'mkdir crypto\include' anywhere. > > And I don't see 'mkdir-p.pl' is used to create these. > So how are these empty directories created/used? > From gisle.vanem at gmail.com Tue Sep 8 10:53:30 2020 From: gisle.vanem at gmail.com (Gisle Vanem) Date: Tue, 8 Sep 2020 12:53:30 +0200 Subject: Empty directories In-Reply-To: <7629613f-98e1-1278-bdc2-fe3a23ec85eb@ncp-e.com> References: <97dd7e34-fa18-df2d-479a-f7e6798d494e@gmail.com> <7629613f-98e1-1278-bdc2-fe3a23ec85eb@ncp-e.com> Message-ID: <8fade6a1-abb4-d37b-e809-26b412757a47@gmail.com> > It tested it on master, it seems like the empty directories are created by the Configure script. Where exactly? > Would you mind opening a GitHub issue for it? Done: https://github.com/openssl/openssl/issues/12815 -- --gv From ymazin at opentext.com Tue Sep 8 17:39:51 2020 From: ymazin at opentext.com (Yury Mazin) Date: Tue, 8 Sep 2020 17:39:51 +0000 Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option In-Reply-To: References: <20200904001252.GI20623@akamai.com> , <20200904191022.GH44511@straasha.imrryr.org>, Message-ID: Hello, I have a question based on the response provided to me: My question is why following openssl commands (version 1.1.1f) return those TLSv1.3 ciphers as offering no authentication and no encryption? C:\OpenText\iHub20.4-29324643-250C200831\ihub\modules\BIRTiHub\iHub\bin>openssl ciphers -v -s NULL 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 C:\OpenText\iHub20.4-29324643-250C200831\ihub\modules\BIRTiHub\iHub\bin>openssl ciphers -v -s eNULL 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 C:\OpenText\iHub20.4-29324643-250C200831\ihub\modules\BIRTiHub\iHub\bin>openssl ciphers -v -s aNULL 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 ________________________________ From: Yury Mazin Sent: Friday, September 4, 2020 12:43 PM To: openssl-users at openssl.org Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option Viktor, Thank you for clarifying it. Yury ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Friday, September 4, 2020 12:10 PM To: openssl-users at openssl.org Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Fri, Sep 04, 2020 at 07:00:01PM +0000, Yury Mazin via openssl-users wrote: > Thank you Benjamin, > > According to OpenSSL , aNULL stands for no-authentication. Specifically, SSL 3.0 through TLS 1.2 ciphers in which the server and client exchange no certificates, and the TLS handshake consists largely of an unsigned anonymous ephemeral DH or ECDH key exchang. TLS 1.3 dropped support for anonymous DH and ECDH. Server certificates are *required. And the all-in-one ciphersuites of TLS <= 1.2, are replaced with separately negotiated components. As a result of which, in OpenSSL 1.1.1 and later, they are controlled via a different set of APIs and command-line options. Specifically, in your case, the "-ciphers aNULL" option only applies to TLS <= 1.2 > Does it mean that all 3 default protocols of TLS 1.3 offer no > authentication No. None of them "support no authentication" (which is not even strictly true, it is the protocol that does not support "no authentication", the TLS 1.3 ciphers are simply silent re certificate algorithm selection), but the "-cipher aNULL" is simply not used when TLS 1.3 is negotiated, so your question is makes incorrect assumptions to reach its tentative conclusions. -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Tue Sep 8 17:57:10 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 08 Sep 2020 19:57:10 +0200 Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option In-Reply-To: References: <20200904001252.GI20623@akamai.com> , <20200904191022.GH44511@straasha.imrryr.org> , Message-ID: <8b00480d494ad185cce9bdd4cfa057a7aed6529f.camel@redhat.com> On Tue, 2020-09-08 at 17:39 +0000, Yury Mazin via openssl-users wrote: > Hello, > > I have a question based on the response provided to me: > > My question is why following openssl commands (version 1.1.1f) > return those TLSv1.3 ciphers as offering no authentication and no > encryption? What do you mean by no authentication and no encryption? The encryption is provided as you can see with the Enc=.... value. And authentication is provided as well because Au=any applies here meaning any authentication method available in TLS-1.3 protocol. As it was explained before the cipher string does not apply to TLS-1.3 ciphersuites so it does not matter if you put NULL, eNULL, aNULL or anything else as the last parameter of the ciphers command. > Yury > From: openssl-users on behalf of > Viktor Dukhovni > Sent: Friday, September 4, 2020 12:10 PM > To: openssl-users at openssl.org > Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl > -cipher aNULL option > > On Fri, Sep 04, 2020 at 07:00:01PM +0000, Yury Mazin via openssl- > users wrote: > > > Thank you Benjamin, > > > > According to OpenSSL , aNULL stands for no-authentication. > > Specifically, SSL 3.0 through TLS 1.2 ciphers in which the server and > client exchange no certificates, and the TLS handshake consists > largely > of an unsigned anonymous ephemeral DH or ECDH key exchang. > > TLS 1.3 dropped support for anonymous DH and ECDH. Server > certificates > are *required. And the all-in-one ciphersuites of TLS <= 1.2, are > replaced with separately negotiated components. As a result of > which, > in OpenSSL 1.1.1 and later, they are controlled via a different set > of > APIs and command-line options. > > Specifically, in your case, the "-ciphers aNULL" option only applies > to TLS <= 1.2 > > > Does it mean that all 3 default protocols of TLS 1.3 offer no > > authentication > > No. None of them "support no authentication" (which is not even > strictly > true, it is the protocol that does not support "no authentication", > the TLS 1.3 ciphers are simply silent re certificate algorithm > selection), > but the "-cipher aNULL" is simply not used when TLS 1.3 is > negotiated, > so your question is makes incorrect assumptions to reach its > tentative > conclusions. > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From openssl-users at dukhovni.org Tue Sep 8 17:56:57 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 8 Sep 2020 13:56:57 -0400 Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option In-Reply-To: References: <20200904001252.GI20623@akamai.com> <20200904191022.GH44511@straasha.imrryr.org> Message-ID: <20200908175657.GC4758@straasha.imrryr.org> On Tue, Sep 08, 2020 at 05:39:51PM +0000, Yury Mazin via openssl-users wrote: > I have a question based on the response provided to me: > > My question is why following openssl commands (version 1.1.1f) return > those TLSv1.3 ciphers as offering no authentication and no encryption? It does not. You still have not understood that "-ciphers" constrains **ONLY** the TLS 1.2 (and earlier) cipher lists. When you say: ciphers ... NULL you asking for all the ciphers (TLS 1.2 and 1.3) where the TLS 1.2 ciphers are NULL. To also constrain the TLS 1.3 ciphers you MUST use the -ciphersuites ... option to list the desired TLS 1.3 ciphersuites, otherwise they remain unconstrained. -- Viktor. From ymazin at opentext.com Tue Sep 8 18:17:33 2020 From: ymazin at opentext.com (Yury Mazin) Date: Tue, 8 Sep 2020 18:17:33 +0000 Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option In-Reply-To: <20200908175657.GC4758@straasha.imrryr.org> References: <20200904001252.GI20623@akamai.com> <20200904191022.GH44511@straasha.imrryr.org> , <20200908175657.GC4758@straasha.imrryr.org> Message-ID: Viktor, Thank you. Yury ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Tuesday, September 8, 2020 10:56 AM To: openssl-users at openssl.org Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Tue, Sep 08, 2020 at 05:39:51PM +0000, Yury Mazin via openssl-users wrote: > I have a question based on the response provided to me: > > My question is why following openssl commands (version 1.1.1f) return > those TLSv1.3 ciphers as offering no authentication and no encryption? It does not. You still have not understood that "-ciphers" constrains **ONLY** the TLS 1.2 (and earlier) cipher lists. When you say: ciphers ... NULL you asking for all the ciphers (TLS 1.2 and 1.3) where the TLS 1.2 ciphers are NULL. To also constrain the TLS 1.3 ciphers you MUST use the -ciphersuites ... option to list the desired TLS 1.3 ciphersuites, otherwise they remain unconstrained. -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Wed Sep 9 12:39:50 2020 From: openssl at openssl.org (OpenSSL) Date: Wed, 9 Sep 2020 12:39:50 +0000 Subject: OpenSSL Security Advisory Message-ID: <20200909123950.GA20454@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [09 September 2020] ============================================= Raccoon Attack (CVE-2020-1968) ============================== Severity: Low The Raccoon attack exploits a flaw in the TLS specification which can lead to an attacker being able to compute the pre-master secret in connections which have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would result in the attacker being able to eavesdrop on all encrypted communications sent over that TLS connection. The attack can only be exploited if an implementation re-uses a DH secret across multiple TLS connections. Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites. OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret and does not implement any "static" DH ciphersuites. OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH ciphersuite is used. These static "DH" ciphersuites are ones that start with the text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for these ciphersuites all start with "TLS_DH_" but excludes those that start with "TLS_DH_anon_". OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS connections in server processes unless the SSL_OP_SINGLE_DH_USE option was explicitly configured. Therefore all ciphersuites that use DH in servers (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a response to CVE-2016-0701. Since the vulnerability lies in the TLS specification, fixing the affected ciphersuites is not viable. For this reason 1.0.2w moves the affected ciphersuites into the "weak-ssl-ciphers" list. Support for the "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause interoperability problems in most cases since use of these ciphersuites is rare. Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL at compile time with the "enable-weak-ssl-ciphers" option. This is not recommended. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w. If upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure that affected ciphersuites are disabled through runtime configuration. Also note that the affected ciphersuites are only available on the server side if a DH certificate has been configured. These certificates are very rarely used and for this reason this issue has been classified as LOW severity. This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and Juraj Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to allow co-ordinated disclosure with other implementations. Note ==== OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of this issue on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20200909.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----- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl9YzBsACgkQ1enkP335 7oyIxg/9FWuca3/s/lY6g6a5VTPIekZMOLRUnDyzS3YePQu/sEd1w81mKoTqU+6F KQmliGqdRDk+KN8HDVd14kcLBukto8UKmkp9FpB5J4d2KK1I/Fg/DofJs6xUQYKb 5rHRLB3DDoyHEBzEEIjcqYTTThXW9ZSByVK9SKpC78IRM/B2dfd0+j4hIB/kDC/E G+wieFzexHQVdleVYT/VaJ6qS8AwvohBbt8h7yK0P6v/4vEm0spDbUmjWJBVUlUu QZyELjj8XZR3YFxt3axSuJg3JSGYlaMzkt2+DVq4qEzeJLIydLK9J8p6RNwPhsJk Rx0ez8P4N+5O7XmA0nHv3HyompdMgHlvykj8Ks4lNHVS02KKLi1jDtmOxl3Fm/hb ZNOmjn7lulV1342pw4rWL3Nge3x0s0Q5zgBCm1mqLzzu/V1ksx8FJwGA1w2cH280 dU9VedkC2wvFQije8pFrWH9l6N9Bh41DIEOnlBl0AL7IrbPdO6yMcD6vpR7hWjr3 fx4hNJSAGzJ3i/NXlSj4eR/47zkjfJyEc8Drc2QgewyqXFrK20X/LOj8MqJlc+ry pXZseh+XC8WaYDMV1ltrKvE2Ld9/0f3Ydc04AcDeu5SXPJG79ogzVnchZok7+XCj RT+a3/ES45+CTfL5v27t5QJxJcxg4siLVsILfi0rIUv0IYgH2fU= =U7OO -----END PGP SIGNATURE----- From bjorn.bidar at jolla.com Wed Sep 9 19:43:13 2020 From: bjorn.bidar at jolla.com (Bjoern Bidar) Date: Wed, 09 Sep 2020 22:43:13 +0300 Subject: Compiling OpenSSL without compabitlity with for OpenSSL 1.0 Message-ID: <3635888.cAiFvMLM6X@odin> Hey, Is it possible to build openssl this way? I'm current trying to build it this way to dest for deprecated API usage. I configure openssl like this: ./Configure \ --prefix=%{_prefix} --openssldir=%{_sysconfdir}/pki/tls ${sslflags} \ zlib enable-camellia enable-seed enable-rfc3779 \ enable-cms enable-md2 enable-rc5 \ enable-weak-ssl-ciphers \ no-mdc2 no-ec2m no-sm2 no-sm4 \ shared ${sslarch} '-DDEVRANDOM="\"/dev/urandom\""' But my build isn't able to link sucessfully: gcc -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack- protector --param=ssp-buffer-size=4 -Wformat -Wformat-security - DOPENSSL_API_COMPAT=0x10100000L -m32 -msse -msse2 -march=i686 -mfpmath=sse - mtune=generic -fno-omit-frame-pointer -fasynchronous-unwind-tables - D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -m32 - msse -msse2 -march=i686 -mfpmath=sse -mtune=generic -fno-omit-frame-pointer - fasynchronous-unwind-tables -Wa,--noexecstack -Wa,--generate-missing-build- notes=yes -L. \ -o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/ crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/ passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_client.o apps/s_server.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/storeutl.o apps/ts.o apps/verify.o apps/version.o apps/x509.o \ apps/libapps.a -lssl -lcrypto -lz -ldl -pthread /usr/bin/ld: ./libcrypto.so: undefined reference to `OpenSSLDie' Have a nice day, Bj?rn Bidar From jb-openssl at wisemo.com Wed Sep 9 20:26:00 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 9 Sep 2020 22:26:00 +0200 Subject: OpenSSL Security Advisory In-Reply-To: <20200909123950.GA20454@openssl.org> References: <20200909123950.GA20454@openssl.org> Message-ID: <6a12e8a9-e63b-3f25-9989-32d5b3c5bfba@wisemo.com> On 2020-09-09 14:39, OpenSSL wrote: > OpenSSL Security Advisory [09 September 2020] > ============================================= > > Raccoon Attack (CVE-2020-1968) > ============================== > > Severity: Low > > The Raccoon attack exploits a flaw in the TLS specification which can lead to > an attacker being able to compute the pre-master secret in connections which > have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would > result in the attacker being able to eavesdrop on all encrypted communications > sent over that TLS connection. The attack can only be exploited if an > implementation re-uses a DH secret across multiple TLS connections. Note that > this issue only impacts DH ciphersuites and not ECDH ciphersuites. > > OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret and > does not implement any "static" DH ciphersuites. > > OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH > ciphersuite is used. These static "DH" ciphersuites are ones that start with the > text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for these > ciphersuites all start with "TLS_DH_" but excludes those that start with > "TLS_DH_anon_". > > OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS > connections in server processes unless the SSL_OP_SINGLE_DH_USE option was > explicitly configured. Therefore all ciphersuites that use DH in servers > (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f > SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a > response to CVE-2016-0701. > > Since the vulnerability lies in the TLS specification, fixing the affected > ciphersuites is not viable. For this reason 1.0.2w moves the affected > ciphersuites into the "weak-ssl-ciphers" list. Support for the > "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause > interoperability problems in most cases since use of these ciphersuites is rare. > Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL at > compile time with the "enable-weak-ssl-ciphers" option. This is not recommended. > > OpenSSL 1.0.2 is out of support and no longer receiving public updates. > > Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w. If > upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure > that affected ciphersuites are disabled through runtime configuration. Also > note that the affected ciphersuites are only available on the server side if a > DH certificate has been configured. These certificates are very rarely used and > for this reason this issue has been classified as LOW severity. > > This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and Juraj > Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to > allow co-ordinated disclosure with other implementations. > > Note > ==== > > OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended > support is available for premium support customers: > https://www.openssl.org/support/contracts.html > > OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. > The impact of this issue on OpenSSL 1.1.0 has not been analysed. > > Users of these versions should upgrade to OpenSSL 1.1.1. > > References > ========== > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20200909.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 > Wouldn't a more reasonable response for 1.0.2 users have been to force on SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected cipher suites and telling affected people to recompile with the fix off? 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 From tmraz at redhat.com Thu Sep 10 07:03:06 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 10 Sep 2020 09:03:06 +0200 Subject: OpenSSL Security Advisory In-Reply-To: <6a12e8a9-e63b-3f25-9989-32d5b3c5bfba@wisemo.com> References: <20200909123950.GA20454@openssl.org> <6a12e8a9-e63b-3f25-9989-32d5b3c5bfba@wisemo.com> Message-ID: <0640726d5bde4eeaaaa676231cafce3fb7b06937.camel@redhat.com> On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: > Wouldn't a more reasonable response for 1.0.2 users have been to > force on > SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected > cipher > suites > and telling affected people to recompile with the fix off? You seem to be mixing two different affected things. One is the static DH ciphersuites. There is no remediation for these except for not using them. Fortunately they are not really used by anyone. This can be achieved on the server side by simply not providing the DH certificate. On the client side they can be dropped from the ciphers string. This is the "deprecating affected cipher suites" change part. On the other hand the reuse of DH key for ephemeral DH can be only disabled by setting SSL_OP_SINGLE_DH_USE by the calling server application. This is the part relevant for wider audience. So yes, both issues can be remediated by application calling the OpenSSL library. On the other hand it is not always possible to change the application so we also provide fix to premium support customers in terms of changing the openssl code. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From matt at openssl.org Thu Sep 10 11:56:01 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Sep 2020 12:56:01 +0100 Subject: Compiling OpenSSL without compabitlity with for OpenSSL 1.0 In-Reply-To: <3635888.cAiFvMLM6X@odin> References: <3635888.cAiFvMLM6X@odin> Message-ID: <0722bd0c-1ca4-6f7b-7a5f-e7fbe16951d5@openssl.org> On 09/09/2020 20:43, Bjoern Bidar wrote: > /usr/bin/ld: ./libcrypto.so: undefined reference to `OpenSSLDie' > What version of OpenSSL are you trying to compile? I can't seem to replicate this. Matt From bjorn.bidar at jolla.com Thu Sep 10 11:57:29 2020 From: bjorn.bidar at jolla.com (Bjoern Bidar) Date: Thu, 10 Sep 2020 14:57:29 +0300 Subject: Compiling OpenSSL without compabitlity with for OpenSSL 1.0 In-Reply-To: <0722bd0c-1ca4-6f7b-7a5f-e7fbe16951d5@openssl.org> References: <3635888.cAiFvMLM6X@odin> <0722bd0c-1ca4-6f7b-7a5f-e7fbe16951d5@openssl.org> Message-ID: <2297981.WE3X3kWuFv@hellion> It was version 1.1.1g. From jb-openssl at wisemo.com Thu Sep 10 15:14:37 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 10 Sep 2020 17:14:37 +0200 Subject: OpenSSL Security Advisory In-Reply-To: <0640726d5bde4eeaaaa676231cafce3fb7b06937.camel@redhat.com> References: <20200909123950.GA20454@openssl.org> <6a12e8a9-e63b-3f25-9989-32d5b3c5bfba@wisemo.com> <0640726d5bde4eeaaaa676231cafce3fb7b06937.camel@redhat.com> Message-ID: <2f699dae-5986-2e16-504a-a86287306879@wisemo.com> On 2020-09-10 09:03, Tomas Mraz wrote: > On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: >> Wouldn't a more reasonable response for 1.0.2 users have been to >> force on >> SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected >> cipher >> suites >> and telling affected people to recompile with the fix off? > > You seem to be mixing two different affected things. One is the static > DH ciphersuites. There is no remediation for these except for not using > them. Fortunately they are not really used by anyone. This can be > achieved on the server side by simply not providing the DH certificate. > On the client side they can be dropped from the ciphers string. This is > the "deprecating affected cipher suites" change part. > > On the other hand the reuse of DH key for ephemeral DH can be only > disabled by setting SSL_OP_SINGLE_DH_USE by the calling server application. This is the part relevant for wider audience. > > So yes, both issues can be remediated by application calling the > OpenSSL library. On the other hand it is not always possible to change > the application so we also provide fix to premium support customers in > terms of changing the openssl code. > The advisory didn't include this clarification, and didn't state if 1.0.2w fixes the DHE case by doing what 1.1.x does and act like SSL_OP_SINGLE_DH_USE is always set. 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 From matt at openssl.org Thu Sep 10 15:28:07 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Sep 2020 16:28:07 +0100 Subject: OpenSSL Security Advisory In-Reply-To: <2f699dae-5986-2e16-504a-a86287306879@wisemo.com> References: <20200909123950.GA20454@openssl.org> <6a12e8a9-e63b-3f25-9989-32d5b3c5bfba@wisemo.com> <0640726d5bde4eeaaaa676231cafce3fb7b06937.camel@redhat.com> <2f699dae-5986-2e16-504a-a86287306879@wisemo.com> Message-ID: On 10/09/2020 16:14, Jakob Bohm via openssl-users wrote: > On 2020-09-10 09:03, Tomas Mraz wrote: >> On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: >>> Wouldn't a more reasonable response for 1.0.2 users have been to >>> force on >>> SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected >>> cipher >>> suites >>> and telling affected people to recompile with the fix off? >> >> You seem to be mixing two different affected things. One is the static >> DH ciphersuites. There is no remediation for these except for not using >> them. Fortunately they are not really used by anyone. This can be >> achieved on the server side by simply not providing the DH certificate. >> On the client side they can be dropped from the ciphers string. This is >> the "deprecating affected cipher suites" change part. >> >> On the other hand the reuse of DH key for ephemeral DH can be only >> disabled by setting SSL_OP_SINGLE_DH_USE by the calling server >> application. This is the part relevant for wider audience. >> >> So yes, both issues can be remediated by application calling the >> OpenSSL library. On the other hand it is not always possible to change >> the application so we also provide fix to premium support customers in >> terms of changing the openssl code. >> > > > The advisory didn't include this clarification, Isn't the text below from the advisory more-or-less what Tomas said? "OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH ciphersuite is used ... Since the vulnerability lies in the TLS specification, fixing the affected ciphersuites is not viable. For this reason 1.0.2w moves the affected ciphersuites into the "weak-ssl-ciphers" list." > and didn't state if > 1.0.2w fixes the DHE case by doing what 1.1.x does and act like > SSL_OP_SINGLE_DH_USE is always set. The advisory says that SSL_OP_SINGLE_DH_USE was made the default in 1.0.2f: "OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS connections in server processes unless the SSL_OP_SINGLE_DH_USE option was explicitly configured. Therefore all ciphersuites that use DH in servers (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a response to CVE-2016-0701." Matt From tom.browder at gmail.com Fri Sep 11 00:15:47 2020 From: tom.browder at gmail.com (Tom Browder) Date: Thu, 10 Sep 2020 19:15:47 -0500 Subject: Compiling OpenSSL without compabitlity with for OpenSSL 1.0 In-Reply-To: <2297981.WE3X3kWuFv@hellion> References: <3635888.cAiFvMLM6X@odin> <0722bd0c-1ca4-6f7b-7a5f-e7fbe16951d5@openssl.org> <2297981.WE3X3kWuFv@hellion> Message-ID: On Thu, Sep 10, 2020 at 06:58 Bjoern Bidar wrote: > It was version 1.1.1g. What OS? I had to to some fiddling with packages and options for Debian 10 Buster to get a good compile. I have documented my journey if you're interested. Best regards, -Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From dssrrjy at yahoo.co.in Fri Sep 11 09:05:17 2020 From: dssrrjy at yahoo.co.in (Sai Srihari) Date: Fri, 11 Sep 2020 09:05:17 +0000 (UTC) Subject: OpenSSL hard coded address 0xFB00000 References: <166380943.899817.1599815117715.ref@mail.yahoo.com> Message-ID: <166380943.899817.1599815117715@mail.yahoo.com> Hi, We have been using a wrapper DLL on top of OpenSSL library in our product. While migrating to 1.0.2t, we are facing the initialization?problem in FIPs mode. After analysis we found the following information in openssl guide.------------The standard OpenSSL build with the fips option will use abase address for libeay32.dll of 0xFB00000 by default. This value was chosen because it isunlikely to conflict with other dynamically loaded libraries. In the event of a clash with anotherdynamically loaded library which will trigger runtime relocation of libeay32.dll, the integritycheck will fail with the error----------- So, the root cause seems to be that our program is using the above mentioned address by the time initialization is called. It's happening with a web application where we are making use of JNI interface to make the relevant calls. In fact there are multiple layers here to access the openssl library calls. It's something like we are calling Library1 from web application, and library1 invokes library2 and then 3 and then openssl. Could someone help me in addressing this problem? We have no choice of rebuilding openssl library as the common wrapper (on top of it) is being used by multiple?products. ThanksSai Srihari -------------- next part -------------- An HTML attachment was scrubbed... URL: From sage at sagegerard.com Tue Sep 15 21:48:32 2020 From: sage at sagegerard.com (Sage Gerard) Date: Tue, 15 Sep 2020 21:48:32 +0000 Subject: Removing difference between CLI and FFI use for computing a message digest Message-ID: I have a Racket program that uses libcrypto through FFI bindings to compute digests. It's wrong because it returns different answers than `openssl dgst`, regardless of hash algorithm. The code is here: https://github.com/zyrolasting/xiden/blob/libcrypto/openssl.rkt#L76 It is based on the example in: https://wiki.openssl.org/index.php/EVP_Message_Digests. I'm not expecting anyone to run this program or review Racket code in detail. The links are just there for context. I just want to know if there are common C-level mistakes libcrypto users make that would make their digests disagree with the CLI. As far as I can tell, I replicated the example on wiki.openssl.org well enough to deterministically compute a digest with any byte string. Let me know if there is any other context I can provide. ~slg -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Sep 15 22:01:26 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 15 Sep 2020 23:01:26 +0100 Subject: Forthcoming OpenSSL Release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1h. This release will be made available on Tuesday 22nd September 2020 between 1300-1700 UTC. OpenSSL 1.1.h is a bug-fix release. There are no CVEs addressed in this release. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl9hObYACgkQ2cTSbQ5g RJGmDAf+IPnGTpXB6XpHpuvlWWE6v0aTEOHntLgeYbqp9v3/5ay4i0qwFZk2M4Sn 9J5C/057OqqLVMq0UyXXAwhyS52KIR6VfcJKTCc/2NkgPHhee+/W5Q8SgGpXMnOP 60EIrHD5cfkestIO9fvrCHZ19RFFWlFQJnPmc64nLYyhQJ83a/AKGoug459oaxm7 lj90Rd+U4oQvEJyltsA5Urv/IAjQV24EYej1pCLb4zqerW4rLYnoATBrurclWVOa 5AXZgzuhNvtMV3/nVB7aFpfQIsg2FUaTnRW3ok+7e72oiXHndgxYW6TP0GxGOMdu RDB1ZlWWwt7LzYz8BlWTex+s23SNZA== =wNcz -----END PGP SIGNATURE----- From matt at openssl.org Tue Sep 15 22:06:56 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 15 Sep 2020 23:06:56 +0100 Subject: Removing difference between CLI and FFI use for computing a message digest In-Reply-To: References: Message-ID: <81d4c2ac-0426-44f7-5430-ec7d69ddfd68@openssl.org> On 15/09/2020 22:48, Sage Gerard wrote: > I have a Racket program that uses libcrypto through FFI bindings to > compute digests. It's wrong because it returns different answers than > `openssl dgst`,regardless of hash algorithm. > > The code is here: > https://github.com/zyrolasting/xiden/blob/libcrypto/openssl.rkt#L76 > It is based on the example in: > https://wiki.openssl.org/index.php/EVP_Message_Digests. > > I'm not expecting anyone to run this program or review Racket code in > detail. The links are just there for context. I just want to know if > there are common C-level mistakes libcrypto users make that would make > their digests disagree with the CLI. As far as I can tell, I replicated > the example on wiki.openssl.org well enough to deterministically compute > a digest with any byte string. > > Let me know if there is any other context I can provide. Common "rookie" errors that spring to mind are: 1) Use strlen on binary data and end up passing the wrong length of data to the functions. 2) Include carriage return/line feed in the input data in one context but not in another. Matt From sage at sagegerard.com Wed Sep 16 04:18:36 2020 From: sage at sagegerard.com (Sage Gerard) Date: Wed, 16 Sep 2020 04:18:36 +0000 Subject: Removing difference between CLI and FFI use for computing a message digest In-Reply-To: <81d4c2ac-0426-44f7-5430-ec7d69ddfd68@openssl.org> References: <81d4c2ac-0426-44f7-5430-ec7d69ddfd68@openssl.org> Message-ID: Thank you. I resolved the issue. The root cause was an incorrect cast on the type when crossing the FFI's boundary. ~slg ??????? Original Message ??????? On Tuesday, September 15, 2020 6:06 PM, Matt Caswell wrote: > > > On 15/09/2020 22:48, Sage Gerard wrote: > > > I have a Racket program that uses libcrypto through FFI bindings to > > compute digests. It's wrong because it returns different answers than > > `openssl dgst`,regardless of hash algorithm. > > The code is here: > > https://github.com/zyrolasting/xiden/blob/libcrypto/openssl.rkt#L76 > > It is based on the example in: > > https://wiki.openssl.org/index.php/EVP_Message_Digests. > > I'm not expecting anyone to run this program or review Racket code in > > detail. The links are just there for context. I just want to know if > > there are common C-level mistakes libcrypto users make that would make > > their digests disagree with the CLI. As far as I can tell, I replicated > > the example on wiki.openssl.org well enough to deterministically compute > > a digest with any byte string. > > Let me know if there is any other context I can provide. > > Common "rookie" errors that spring to mind are: > > 1. Use strlen on binary data and end up passing the wrong length of data > to the functions. > > 2. Include carriage return/line feed in the input data in one context > but not in another. > > Matt > From sage at sagegerard.com Wed Sep 16 14:23:17 2020 From: sage at sagegerard.com (Sage Gerard) Date: Wed, 16 Sep 2020 14:23:17 +0000 Subject: EVP_DigestSignUpdate missing from libcrypto Message-ID: For each libcrypto on my Fedora 30 instance, EVP_DigestSignUpdate appears to be missing from the extern symbols list, but EVP_DigestSign remains. This seems to be why I cannot get a reference to the implementation in other programs. [sage at jet racket]$ nm -D /usr/lib64/libcrypto.so.* | grep EVP_DigestSign 000000000013bfd0 T EVP_DigestSignFinal 000000000013bfb0 T EVP_DigestSignInit 000000000013bfd0 T EVP_DigestSignFinal 000000000013bfb0 T EVP_DigestSignInit 0000000000172e50 T EVP_DigestSign 0000000000172be0 T EVP_DigestSignFinal 0000000000172bc0 T EVP_DigestSignInit 0000000000172e50 T EVP_DigestSign 0000000000172be0 T EVP_DigestSignFinal 0000000000172bc0 T EVP_DigestSignInit [sage at jet racket]$ I'm okay with using EVP_DigestSign, but both that and online materials presume EVP_DigestSignUpdate's availability, and the source code does not seem to have a directive to exclude the signature or implementation at first glance. What can explain the symbol's absense? ~slg -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 16 14:26:48 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 16 Sep 2020 15:26:48 +0100 Subject: EVP_DigestSignUpdate missing from libcrypto In-Reply-To: References: Message-ID: <1b0e3402-9829-06cc-e692-6d45a45e6854@openssl.org> On 16/09/2020 15:23, Sage Gerard wrote: > I'm okay with using EVP_DigestSign, but both that and online materials > presume EVP_DigestSignUpdate's availability, and the source code does > not seem to have a directive to exclude the signature or implementation > at first glance. What can explain the symbol's absense? Its a macro: # define EVP_DigestSignUpdate(a,b,c) EVP_DigestUpdate(a,b,c) So, the symbol in libcrypto.so is called EVP_DigestUpdate. Note that this isn't the case in OpenSSL 3.0. It is a full symbol in its own right there. Matt From sage at sagegerard.com Wed Sep 16 14:28:27 2020 From: sage at sagegerard.com (Sage Gerard) Date: Wed, 16 Sep 2020 14:28:27 +0000 Subject: EVP_DigestSignUpdate missing from libcrypto In-Reply-To: <1b0e3402-9829-06cc-e692-6d45a45e6854@openssl.org> References: <1b0e3402-9829-06cc-e692-6d45a45e6854@openssl.org> Message-ID: Thanks, Matt. ~slg ??????? Original Message ??????? On Wednesday, September 16, 2020 10:26 AM, Matt Caswell wrote: > > > On 16/09/2020 15:23, Sage Gerard wrote: > > > I'm okay with using EVP_DigestSign, but both that and online materials > > presume EVP_DigestSignUpdate's availability, and the source code does > > not seem to have a directive to exclude the signature or implementation > > at first glance. What can explain the symbol's absense? > > Its a macro: > > define EVP_DigestSignUpdate(a,b,c) EVP_DigestUpdate(a,b,c) > > =========================================================== > > So, the symbol inlibcrypto.so is called EVP_DigestUpdate. > > Note that this isn't the case in OpenSSL 3.0. It is a full symbol in its > own right there. > > Matt From ranier_gyn at hotmail.com Thu Sep 17 00:34:39 2020 From: ranier_gyn at hotmail.com (Ranier Vilela) Date: Thu, 17 Sep 2020 00:34:39 +0000 Subject: Workaround for incorrect SSL_write() errors in OpenSSL 1.1.1. Message-ID: Hi, from nginx-dev list. SSL: workaround for incorrect SSL_write() errors in OpenSSL 1.1.1. OpenSSL 1.1.1 fails to return SSL_ERROR_SYSCALL if an error happens during SSL_write() after close_notify alert from the peer, and returns SSL_ERROR_ZERO_RETURN instead. Broken by this commit, which removes the "i == 0" check around the SSL_RECEIVED_SHUTDOWN one: https://git.openssl.org/?p=openssl.git;a=commitdiff;h=8051ab2 In particular, if a client closed the connection without reading the response but with properly sent close_notify alert, this resulted in unexpected "SSL_write() failed while ..." critical log message instead of correct "SSL_write() failed (32: Broken pipe)" at the info level. Since SSL_ERROR_ZERO_RETURN cannot be legitimately returned after SSL_write(), the fix is to convert all SSL_ERROR_ZERO_RETURN errors after SSL_write() to SSL_ERROR_SYSCALL. diffstat: src/event/ngx_event_openssl.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diffs (22 lines): diff -r 3781de64e747 -r 61011bfcdb49 src/event/ngx_event_openssl.c --- a/src/event/ngx_event_openssl.c Wed Sep 09 19:26:27 2020 +0300 +++ b/src/event/ngx_event_openssl.c Wed Sep 16 18:26:22 2020 +0300 @@ -2573,6 +2573,18 @@ ngx_ssl_write(ngx_connection_t *c, u_cha sslerr = SSL_get_error(c->ssl->connection, n); + if (sslerr == SSL_ERROR_ZERO_RETURN) { + + /* + * OpenSSL 1.1.1 fails to return SSL_ERROR_SYSCALL if an error + * happens during SSL_write() after close_notify alert from the + * peer, and returns SSL_ERROR_ZERO_RETURN instead, + * https://git.openssl.org/?p=openssl.git;a=commitdiff;h=8051ab2 + */ + + sslerr = SSL_ERROR_SYSCALL; + } + regards, Ranier Vilela From skyper at thc.org Sat Sep 19 04:46:59 2020 From: skyper at thc.org (Ralf Skyper Kaiser) Date: Sat, 19 Sep 2020 05:46:59 +0100 Subject: SRP on 1.0.1f Message-ID: Hello, I'm trying to get SRP working on some older openssl (2014) release. SRP has been officially supported in OpenSSL since 2012. The example below works fine on newer OpenSSL versions (such as 1.1.1g). I'm curious why this aint working on 1.0.1f: SRP is supported: $ openssl version OpenSSL 1.0.1f 6 Jan 2014 $ openssl ciphers 'SRP' | sed 's/\:/\n/g' SRP-DSS-AES-256-CBC-SHA SRP-RSA-AES-256-CBC-SHA SRP-AES-256-CBC-SHA SRP-DSS-3DES-EDE-CBC-SHA SRP-RSA-3DES-EDE-CBC-SHA SRP-3DES-EDE-CBC-SHA SRP-DSS-AES-128-CBC-SHA SRP-RSA-AES-128-CBC-SHA SRP-AES-128-CBC-SHA # Create a srpvfile (myself / password) $ openssl srp -srpvfile passwd.txt -add myself # Server $ openssl s_server -nocert -cipher SRP -srpvfile passwd.txt -accept 4444 # Client (same host) $ openssl s_client -srpuser myself -cipher SRP -connect 127.1:4444 Server fails with: 140700035712672:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1389: Client fails with: 139663869671072:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1278:SSL alert number 40 139663869671072:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:599: tcpdump shows that the 'Client Hello' does contain the correct ciphers (all 9 from above) but the server rejected the Client-Hello (even that server's 'openssl ciphers' command shows that all 9 are available and supported). Why? Is srp broken in 1.0.1f? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl-eric.codere at thalesgroup.com Tue Sep 22 05:12:24 2020 From: carl-eric.codere at thalesgroup.com (CODERE Carl-Eric) Date: Tue, 22 Sep 2020 05:12:24 +0000 Subject: OpenSSL-compat patches or contributions Message-ID: Greetings, On the OpenSSL 1.1.0 Changes wiki there is at the bottom of the page, there is an OpenSSL-compat source code package to help migrating to OpenSSL 1.1.X and keep compatibility with 1.0.2, how can we contribute to this, as we see there seems to be missing code... Thanks, Carl -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Tue Sep 22 13:26:18 2020 From: openssl at openssl.org (OpenSSL) Date: Tue, 22 Sep 2020 13:26:18 +0000 Subject: OpenSSL version 1.1.1h published Message-ID: <20200922132618.GA23664@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1h released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1h of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1h is available for download via HTTP 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-1.1.1h.tar.gz Size: 9810045 SHA1 checksum: 8d0d099e8973ec851368c8c775e05e1eadca1794 SHA256 checksum: 5c9ca8774bd7b03e5784f26ae9e9e6d749c9da2438545077e6b3d755a06595d9 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1h.tar.gz openssl sha256 openssl-1.1.1h.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl9p9DIACgkQ2cTSbQ5g RJG6pAf/Y6B3I9pwD6MG7lm3ywEqp2dAwYym84l39K6LrBFPOg76GmHLby92Se5/ N2S5uHPCcXrBdtHLZZTi1Tn3rwMN6EAJmedZJvMwoxeKJxNjZ2f8K8SjgUkuimSa dKbXtv92uDNRpD4X3Fv+uRatmbvygdjduwJWqgJ88ahz/IM7x1lv8E8GNnkPNBfA 9M9rDP5ThiQAetbefHBq9vb6wywwbi0FGTnXkeaYpyKDXmob0VWUdI0olMFLIUAG ZAQAD8XEPnJBVh4qCOlVy0n/5+jzcOiqcwJyORQc/U0wkV71I9XigW9H7wgg6skD iVQQe2QEODbEbtx9iMPsN4Ssmfk+VA== =OYam -----END PGP SIGNATURE----- From Michael.Wojcik at microfocus.com Tue Sep 22 14:03:05 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 22 Sep 2020 14:03:05 +0000 Subject: OpenSSL version 1.1.1h published In-Reply-To: <20200922132618.GA23664@openssl.org> References: <20200922132618.GA23664@openssl.org> Message-ID: changelog.html hasn't been updated since 1.1.1e. https://www.openssl.org/news/changelog.html#openssl-111 shows: ----- OpenSSL 1.1.1 Changes between 1.1.1e and 1.1.1f [xx XXX xxxx] Changes between 1.1.1d and 1.1.1e [17 Mar 2020] ----- I noticed this because the Release Notes page (https://www.openssl.org/news/openssl-1.1.1-notes.html) has a link to changelog.html, and I popped over there to see what minor changes might be in h. (I haven't downloaded it yet because it's usually someone else on the team who does that these days.) -- Michael Wojcik From matt at openssl.org Tue Sep 22 14:07:19 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 22 Sep 2020 15:07:19 +0100 Subject: OpenSSL version 1.1.1h published In-Reply-To: References: <20200922132618.GA23664@openssl.org> Message-ID: On 22/09/2020 15:03, Michael Wojcik wrote: > changelog.html hasn't been updated since 1.1.1e. > > https://www.openssl.org/news/changelog.html#openssl-111 shows: That's the master Changelog. Confusing I know. The link to the 1.1.1 Changelog is at the top of the page. Matt > > ----- > OpenSSL 1.1.1 > Changes between 1.1.1e and 1.1.1f [xx XXX xxxx] > Changes between 1.1.1d and 1.1.1e [17 Mar 2020] > ----- > > I noticed this because the Release Notes page (https://www.openssl.org/news/openssl-1.1.1-notes.html) has a link to changelog.html, and I popped over there to see what minor changes might be in h. (I haven't downloaded it yet because it's usually someone else on the team who does that these days.) > > -- > Michael Wojcik > From lauris.zintzmeyer at gmail.com Tue Sep 22 16:33:21 2020 From: lauris.zintzmeyer at gmail.com (Lauris Z) Date: Tue, 22 Sep 2020 18:33:21 +0200 Subject: safeseh flag on libssl and libcrypto dlls Message-ID: Hello everybody, By any chance, has anyone ever managed to get libssl and libcrypto dlls with the SafeSEH option enabled ? When I add /safeseh in the makefile at ldflag line, winchecksec tells me that SafeSEH is still in "NotPresent". I am compiling with nmake, after a perl configure, on x86 Native Tools Command Prompt for VS 2019. Thank you, Regards, Lauris -------------- next part -------------- An HTML attachment was scrubbed... URL: From BYan at visa.com Tue Sep 22 21:36:05 2020 From: BYan at visa.com (Yan, Bob) Date: Tue, 22 Sep 2020 21:36:05 +0000 Subject: ECDSA certificate question Message-ID: Hello everybody, Is there a way to generate a ECDSA certificate with SM2 typed public key and ecdsa-with-SM3 as the signature algorithm in openssl 1.1.1x version? Thank you very much! Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From BYan at visa.com Tue Sep 22 23:49:18 2020 From: BYan at visa.com (Yan, Bob) Date: Tue, 22 Sep 2020 23:49:18 +0000 Subject: ECDSA certificate question In-Reply-To: <23110.1600817733@localhost> References: <23110.1600817733@localhost> Message-ID: Thanks Michael, I tried to invoke SM3 algorithm in command "openssl req -new -key eckey.pem -x509 -sm3 -nodes -days 365 -out cert.csr", unfortunately got the following error: 140320586413888:error:100C508A:elliptic curve routines:pkey_ec_ctrl:invalid digest type:crypto/ec/ec_pmeth.c:331: -----Original Message----- From: Michael Richardson Sent: Tuesday, September 22, 2020 4:36 PM To: Yan, Bob Cc: openssl-users at openssl.org Subject: Re: ECDSA certificate question Yan, Bob via openssl-users wrote: > Is there a way to generate a ECDSA certificate with SM2 typed public > key and ecdsa-with-SM3 as the signature algorithm in openssl 1.1.1x > version? I don't know the detail with the SM3, part, but have you seen: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-09 https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki but, 1.1.1 release notes say it supports SM3. I expect you need to tweak something when "openssl req" is run. -- Michael Richardson . o O ( IPv6 I?T consulting ) Sandelman Software Works Inc, Ottawa and Worldwide From dclarke at blastwave.org Wed Sep 23 06:35:28 2020 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 23 Sep 2020 02:35:28 -0400 Subject: Are -DOPENSSLDIR -DENGINESDIR hard coded ? Message-ID: <1a0e1747-b112-9496-7792-9f1c411c3b51@blastwave.org> I have been trying to build a debug version with no-asm into a /opt/foo directory but I always see : -DOPENSSLDIR="\"/usr/local/ssl\"" and -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" during the compile. Are these hard coded in somewhere ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From dclarke at blastwave.org Wed Sep 23 08:09:09 2020 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 23 Sep 2020 04:09:09 -0400 Subject: =?UTF-8?Q?crypto/threads=5fpthread=2ec=3a48=3a5=3a_warning=3a_impli?= =?UTF-8?Q?cit_declaration_of_function_=e2=80=98pthread=5fmutexattr=5fsettyp?= =?UTF-8?B?ZeKAmQ==?= Message-ID: This is a strange error to get on Debian sid amd64 : /usr/bin/gcc-10 -I. -Iinclude -fPIC -pthread -std=iso9899:1999 -m64 -g -O0 -march=k8 -mtune=k8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -mpc80 -std=iso9899:1999 -m64 -g -O0 -march=k8 -mtune=k8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -mpc80 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/opt/bw/ssl\"" -DENGINESDIR="\"/opt/bw/lib/engines-1.1\"" -I/opt/bw/include -MMD -MF crypto/threads_pthread.d.tmp -MT crypto/threads_pthread.o -c -o crypto/threads_pthread.o crypto/threads_pthread.c crypto/threads_pthread.c: In function ?CRYPTO_THREAD_lock_new?: crypto/threads_pthread.c:48:5: warning: implicit declaration of function ?pthread_mutexattr_settype?; did you mean ?pthread_mutexattr_destroy?? [-Wimplicit-function-declaration] 48 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); | ^~~~~~~~~~~~~~~~~~~~~~~~~ | pthread_mutexattr_destroy crypto/threads_pthread.c:48:38: error: ?PTHREAD_MUTEX_RECURSIVE? undeclared (first use in this function); did you mean ?PTHREAD_MUTEX_RECURSIVE_NP?? 48 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); | ^~~~~~~~~~~~~~~~~~~~~~~ | PTHREAD_MUTEX_RECURSIVE_NP crypto/threads_pthread.c:48:38: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [Makefile:5104: crypto/threads_pthread.o] Error 1 make[1]: Leaving directory '/opt/bw/build/openssl-1.1.1h_debian_sid_5.8.0-2-amd64.004' make: *** [Makefile:174: all] Error 2 Command exited with non-zero status 2 Why should the include of pthread.h be absent here ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From mcr at sandelman.ca Wed Sep 23 12:43:15 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 23 Sep 2020 08:43:15 -0400 Subject: Are -DOPENSSLDIR -DENGINESDIR hard coded ? In-Reply-To: <1a0e1747-b112-9496-7792-9f1c411c3b51@blastwave.org> References: <1a0e1747-b112-9496-7792-9f1c411c3b51@blastwave.org> Message-ID: <31581.1600864995@localhost> Dennis Clarke via openssl-users wrote: > I have been trying to build a debug version with no-asm into a /opt/foo > directory but I always see : > -DOPENSSLDIR="\"/usr/local/ssl\"" > and > -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" > during the compile. > Are these hard coded in somewhere ? No, but show us your ./Configure line. I regularly build into other directories. For instance: ./Configure --prefix=/sandel/3rd/openssl-dtls-api linux-x86_64 Or: ./Configure --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/linux-x86_64 no-idea no-mdc2 no-rc5 no-zlib no-ssl3 enable-unit-test linux-x86_64 {from a Dockerfile where I want to replace the system copy} -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dclarke at blastwave.org Wed Sep 23 20:03:38 2020 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 23 Sep 2020 16:03:38 -0400 Subject: Are -DOPENSSLDIR -DENGINESDIR hard coded ? In-Reply-To: <31581.1600864995@localhost> References: <1a0e1747-b112-9496-7792-9f1c411c3b51@blastwave.org> <31581.1600864995@localhost> Message-ID: > No, but show us your ./Configure line. > I regularly build into other directories. > > For instance: > ./Configure --prefix=/sandel/3rd/openssl-dtls-api linux-x86_64 > Thank you for the reply. I did go looking into the resultant Makefile and there I did see that the "--prefix=/opt/foo" is needed in order to target a new destination directory. So that problem is solved. However my compile fails *everywhere* today on a multitude of systems from Debian sid on amd64 to FreeBSD UNIX on amd64 and Debian on ppc64le and ppc64 big-endian. So I know I am doing something abundantly wrong. Dennis From pgnet.dev at gmail.com Wed Sep 23 21:11:50 2020 From: pgnet.dev at gmail.com (PGNet Dev) Date: Wed, 23 Sep 2020 14:11:50 -0700 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? Message-ID: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> i've got two servers communicating over ssl. comms between them work if /etc/pki/tls/openssl.cnf includes Options = PrioritizeChaCha but fail if 'ServerPreference' (cref: Undocumented openssl.cnf options and PrioritizeChaCha https://blog.germancoding.com/2020/05/30/undocumented-openssl-cnf-options-and-prioritizechacha/ man SSL_CONF_cmd ServerPreference: use server and not client preference order when determining which cipher suite, signature algorithm or elliptic curve to use for an incoming connection. Equivalent to SSL_OP_CIPHER_SERVER_PREFERENCE. Only used by servers. ) is added, Options = ServerPreference,PrioritizeChaCha i'm trying to understand expected behavior, and troubleshoot the 2 servers are postconf mail_version mail_version = 3.5.7 dovecot --version 2.3.10.1 (a3d0e1171) they're on the same machine, which runs grep PRETTY /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 dovecot's configured to listen for SMTP submissions on its own submission proxy port 60465 dovecot then re-submits the message to postfix, on submission port 465. the openssl cnf containts /etc/pki/tls/openssl.cnf openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] MinProtocol = TLSv1.2 CipherString = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256 Ciphersuites = TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 Options = PrioritizeChaCha with that^^ config, message submit cat ~/test.eml | msmtp -a internal testrecipient at example.net to dovecot:60465 succeeds. postfix logs report no probs, Sep 23 13:43:36 mx postfix/submit-from-dovecot-proxy/smtpd[27325]: connect from internal.mx.example.com[10.0.1.50] Sep 23 13:43:36 mx postfix/submit-from-dovecot-proxy/smtpd[27325]: Trusted TLS connection established from internal.mx.example.com[10.0.1.50]: TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384 Sep 23 13:43:36 mx postfix/submit-from-dovecot-proxy/smtpd[27325]: 4BxVWX41svzWf7g: client=internal.mx.example.com[10.0.1.50] Sep 23 13:43:36 mx postfix/qmgr[27295]: 4BxVWX41svzWf7g: from=, size=583, nrcpt=1 (queue active) Sep 23 13:43:36 mx postfix/submit-from-dovecot-proxy/smtpd[27325]: disconnect from internal.mx.example.com[10.0.1.50] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Sep 23 13:43:36 mx postfix/lmtp[27329]: 4BxVWX41svzWf7g: to=, relay=mx.example.com[private/dovecot-lmtp], delay=0.03, delays=0.01/0.01/0/0.01, dsn=2.0.0, status=sent (250 2.0.0 kPB/Iniza1/YaQAA+IOfAw Saved) Sep 23 13:43:36 mx postfix/qmgr[27295]: 4BxVWX41svzWf7g: removed and the message _is_ delivered to final destination without error. mail flows -- in- & out-bound -- without interruption. OTOH, if, as mentioned above, I simply change - Options = PrioritizeChaCha + Options = ServerPreference,PrioritizeChaCha , then otherwise-identical submission to dovecot:60465 fails, cat ~/test.eml | msmtp -a internal testrecipient at example.net msmtp: envelope from address testsender at example.com not accepted by the server msmtp: server message: 421 4.4.0 internal.mx.example.com Failed to establish relay connection msmtp: could not send mail (account internal from /etc/msmtprc) and in postfix logs, Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: connect from internal.mx.example.com[10.0.1.50] Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: setting up TLS connection from internal.mx.example.com[10.0.1.50] Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: internal.mx.example.com[10.0.1.50]: TLS cipher list "TTLS13-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:!aNULL" Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: SSL_accept:before SSL initialization Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: SSL_accept:error in error Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: SSL_accept error from internal.mx.example.com[10.0.1.50]: -1 Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: lost connection after CONNECT from internal.mx.example.com[10.0.1.50] Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: disconnect from internal.mx.example.com[10.0.1.50] commands=0/0 iiuc (?) that^^ _is_ an ssl error, reported by postfix, and preventing the send 'tween dovecot & postfix. 1st, is there any reason to expect that use of "Options = ServerPreference" should _not_ work here? If not, then what's a likely cause of the problem? At this point, I'm not clear if this is postfix, dovecot, openssl, or some combo. &/or, what additional info's required to determine further? From Matthias.St.Pierre at ncp-e.com Thu Sep 24 07:01:59 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 24 Sep 2020 07:01:59 +0000 Subject: OpenSSL version 1.1.1h published In-Reply-To: References: <20200922132618.GA23664@openssl.org> Message-ID: <8c7d2b37d1e94b72b6d028a6a0419252@ncp-e.com> > On 22/09/2020 15:03, Michael Wojcik wrote: > > changelog.html hasn't been updated since 1.1.1e. > > > > https://www.openssl.org/news/changelog.html#openssl-111 shows: > > That's the master Changelog. Confusing I know. > > The link to the 1.1.1 Changelog is at the top of the page. It is indeed confusing, and it shouldn't be. See https://github.com/openssl/openssl/pull/12967 Regards, Matthias From tmraz at redhat.com Thu Sep 24 07:34:14 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 24 Sep 2020 09:34:14 +0200 Subject: OpenSSL version 1.1.1h published In-Reply-To: <8c7d2b37d1e94b72b6d028a6a0419252@ncp-e.com> References: <20200922132618.GA23664@openssl.org> <8c7d2b37d1e94b72b6d028a6a0419252@ncp-e.com> Message-ID: <334daf528d6af1ab704772ead4a9b3377adadf05.camel@redhat.com> On Thu, 2020-09-24 at 07:01 +0000, Dr. Matthias St. Pierre wrote: > > On 22/09/2020 15:03, Michael Wojcik wrote: > > > changelog.html hasn't been updated since 1.1.1e. > > > > > > https://www.openssl.org/news/changelog.html#openssl-111 shows: > > > > That's the master Changelog. Confusing I know. > > > > The link to the 1.1.1 Changelog is at the top of the page. > > It is indeed confusing, and it shouldn't be. See > https://github.com/openssl/openssl/pull/12967 But will we have to always update Changes.md and NEWS.md on all newer branches (imagine the situation when 3.0 is released and we have also a 3.0 branch) when we add something to older release? I think it would be better to just add a comment that the older branch changes are tracked elsewhere. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From Matthias.St.Pierre at ncp-e.com Thu Sep 24 08:09:59 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 24 Sep 2020 08:09:59 +0000 Subject: OpenSSL version 1.1.1h published In-Reply-To: <334daf528d6af1ab704772ead4a9b3377adadf05.camel@redhat.com> References: <20200922132618.GA23664@openssl.org> <8c7d2b37d1e94b72b6d028a6a0419252@ncp-e.com> <334daf528d6af1ab704772ead4a9b3377adadf05.camel@redhat.com> Message-ID: > I think it would be better to just add a comment that the older branch > changes are tracked elsewhere. The note is already present, it's in the second paragraph of https://www.openssl.org/news/changelog.html but it is confusing nevertheless and it would be more useful if the entire information would be visible on the website (in HTML). Currently, I am updating the two documents on master occasionally. This is not ideal, that's why I proposed in #11346 that we always update the information on master and backport the relevant changes to the stable branches (for 3.0 and beyond only, because 1.1.1 is not in markdown yet. https://github.com/openssl/openssl/pull/11346 Matthias From openssl-users at dukhovni.org Thu Sep 24 08:19:10 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 24 Sep 2020 04:19:10 -0400 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> Message-ID: <20200924081910.GG64864@straasha.imrryr.org> On Wed, Sep 23, 2020 at 02:11:50PM -0700, PGNet Dev wrote: > /etc/pki/tls/openssl.cnf > openssl_conf = default_conf > > [default_conf] > ssl_conf = ssl_sect > > [ssl_sect] > system_default = system_default_sect > > [system_default_sect] > MinProtocol = TLSv1.2 > CipherString = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256 > Ciphersuites = TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 > > Options = PrioritizeChaCha Distros have gotten rather enthusiastic of late to turn up the crypto to 11. This does not always yield good results. :-( I'd be tempted to drop most if not all of those settings, they're not email-friendly. > OTOH, if, as mentioned above, I simply change > > - Options = PrioritizeChaCha > + Options = ServerPreference,PrioritizeChaCha > > , then otherwise-identical submission to dovecot:60465 fails, > > and in postfix logs, > > Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: connect from internal.mx.example.com[10.0.1.50] > Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: setting up TLS connection from internal.mx.example.com[10.0.1.50] > Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: internal.mx.example.com[10.0.1.50]: TLS cipher list "TTLS13-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:!aNULL" > Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: SSL_accept:before SSL initialization > Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: SSL_accept:error in error > Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: SSL_accept error from internal.mx.example.com[10.0.1.50]: -1 > Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: lost connection after CONNECT from internal.mx.example.com[10.0.1.50] > Sep 23 13:45:42 mx postfix/submit-from-dovecot-proxy/smtpd[27011]: disconnect from internal.mx.example.com[10.0.1.50] commands=0/0 That's rather more verbose than default Postfix TLS logging, I hope it is temporary. Are you sure the third line is copied correctly into your post? > Sep 23 13:45:42 mx > postfix/submit-from-dovecot-proxy/smtpd[27011]: > internal.mx.example.com[10.0.1.50]: TLS cipher list > "TTLS13-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:!aNULL" That cipherlist, has an extra "T" in front of the TLS 1.3 ChaCha cipher, that should not be there... Also, Postfix has no knowledge of TLS 1.3 cipher suites, Postfix has only cipher configuration knobs only for the TLS <= 1.2 ciphers, so I don't know how that particular string ended up in your logs. Is there something in your Postfix configuration that resembles that particular blob? If so, it should not be there... -- Viktor. From pgnet.dev at gmail.com Thu Sep 24 14:43:04 2020 From: pgnet.dev at gmail.com (PGNet Dev) Date: Thu, 24 Sep 2020 07:43:04 -0700 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <20200924081910.GG64864@straasha.imrryr.org> References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> <20200924081910.GG64864@straasha.imrryr.org> Message-ID: > I'd be tempted to drop most if not all of those settings, they're not email-friendly. PUBLIC email non-friendly, because of still-frequent old cipher/protocol implementations? or, inherently problematic with TLS in/onr SMTP? in this case, there's nothing public ... both the dovecot and postfix instances are internal. the internal postfix instance hands off to a public facing external postfix instance, which exposes/uses postfix-default cipherlists only. the attempt is to clean- & tighten-up the comms internally; not that that's particularly relevant to the error(s) seen. > That's rather more verbose than default Postfix TLS logging, I hope it is temporary. yep. 'temporarily' monkeying with log levels all over the place, trying to find the cause of this^. now dialed back. > Are you sure the third line is copied correctly into your post? not entirely; it's copied from my too-busy/very-messy 'WTF?' notes. below, i've (re)included logs instead _directly_ copied from shell. > That cipherlist, has an extra "T" in front of the TLS 1.3 ChaCha cipher, that should not be there... fat thumbs in notes, I suspect. > Also, Postfix has no knowledge of TLS 1.3 cipher suites, Postfix has only cipher configuration knobs only for the TLS <= 1.2 ciphers, so I don't know how that particular string ended up in your logs. a bit too postfix-y for this list, but ... I'm then perhaps misreading http://www.postfix.org/TLS_README.html http://www.postfix.org/FORWARD_SECRECY_README.html "If you want to take maximal advantage of ciphers that offer forward secrecy see the Getting started section of FORWARD_SECRECY_README. The full document conveniently presents all information about Postfix forward secrecy support in one place: what forward secrecy is, how to tweak settings, and what you can expect to see when Postfix uses ciphers with forward secrecy. Postfix 2.8 and later, in combination with OpenSSL 0.9.7 and later allows TLS servers to preempt the TLS client's cipher-suite preference list. This is possible only with SSLv3 and later, as in SSLv2 the client chooses the cipher-suite from a list supplied by the server. By default, the OpenSSL server selects the client's most preferred cipher-suite that the server supports. With SSLv3 and later, the server may choose its own most preferred cipher-suite that is supported (offered) by the client. Setting "tls_preempt_cipherlist = yes" enables server cipher-suite preferences. The default OpenSSL behavior applies with "tls_preempt_cipherlist = no". " RE-(re-,re-,etc-)reading, I'm now scratching my head a bit as to which is the server defining the preferences ... my _goal_ was to ensure that the server receiving submission -- 1st @ the MUA -> dovecot listener, then @ dovecot -> postfix -- dictates the ciphers/suites in use. or at least declares preference. In any case, the following should be with defaults. > Is there something in your Postfix configuration that resembles that particular blob? If so, it should not be there... yep. now removed ... with postfix's tls log level dialed back down -o smtpd_tls_loglevel=1 and its tls_high_cipherlist back to default simplifying /etc/pki/tls/openssl.cnf openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] Options = PrioritizeChaCha @ test submit to dovecot cat ~/test.eml | msmtp -a internal testrecipient at example.com send/receive is successful. dovecot logs 2020-09-24 04:59:01 submission-login: Info: Login: user=, method=PLAIN, rip=10.0.1.17, lip=10.0.1.17, mpid=11209, TLS 2020-09-24 04:59:01 submission(testrecipient at example.com): Info: Successfully relayed message: from=, size=135, id=kROCNiWmbF/JKwAA+IOfAw, nrcpt=1, reply=`250 2.0.0 Ok: queued as 4BxxVF6VD2zWf49' 2020-09-24 04:59:01 lmtp(11200): Info: Connect from local 2020-09-24 04:59:01 submission(testrecipient at example.com): Info: Disconnect from 10.0.1.17: Client has quit the connection in=223 out=114 (state=READY) 2020-09-24 04:59:02 lmtp(testrecipient at example.com): Info: sieve: msgid=<4BxxVF6VD2zWf49 at mx.example.com>: stored mail into mailbox 'INBOX' 2020-09-24 04:59:02 lmtp(11200): Info: Disconnect from local: Client has quit the connection (state=READY) postfix logs Sep 24 04:59:01 mx postfix/submit-from-dovecot-proxy/smtpd[11186]: connect from internal.mx.example.com[10.0.1.17] Sep 24 04:59:01 mx postfix/submit-from-dovecot-proxy/smtpd[11186]: Trusted TLS connection established from internal.mx.example.com[10.0.1.17]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384 Sep 24 04:59:01 mx postfix/submit-from-dovecot-proxy/smtpd[11186]: 4BxxVF6VD2zWf49: client=internal.mx.example.com[10.0.1.17] Sep 24 04:59:01 mx postfix/qmgr[11139]: 4BxxVF6VD2zWf49: from=, size=577, nrcpt=1 (queue active) Sep 24 04:59:01 mx postfix/submit-from-dovecot-proxy/smtpd[11186]: disconnect from internal.mx.example.com[10.0.1.17] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Sep 24 04:59:02 mx postfix/lmtp[11190]: 4BxxVF6VD2zWf49: to=, relay=mx.example.com[private/dovecot-lmtp], delay=0.19, delays=0/0/0/0.19, dsn=2.0.0, status=sent (250 2.0.0 YCW8NiWmbF/AKwAA+IOfAw Saved) Sep 24 04:59:02 mx postfix/qmgr[11139]: 4BxxVF6VD2zWf49: removed changing only /etc/pki/tls/openssl.cnf - Options = PrioritizeChaCha + Options = ServerPreference,PrioritizeChaCha @ re-test submit to dovecot FAILs, cat ~/test.eml | msmtp -a internal testrecipient at example.com msmtp: envelope from address myexternaluser at fastmail.fm not accepted by the server msmtp: server message: 421 4.4.0 internal.mx.example.com Failed to establish relay connection msmtp: could not send mail (account internal from /etc/msmtprc) dovecot log 2020-09-24 05:01:44 submission-login: Info: Login: user=, method=PLAIN, rip=10.0.1.17, lip=10.0.1.17, mpid=11260, TLS ==> /var/log/dovecot/dovecot.log <== 2020-09-24 05:01:44 submission(testrecipient at example.com): Error: smtp-client: conn internal.mx.example.com:465 (10.0.1.17:465) [1]: connect(internal.mx.example.com:465) failed: Failed to initialize SSL: Couldn't initialize SSL context: Can't load SSL certificate: error:14187180:SSL routines:ssl_do_config:bad value: section=system_default, cmd=Options, arg=ServerPreference,PrioritizeChaCha 2020-09-24 05:01:44 submission(testrecipient at example.com): Error: Failed to establish relay connection: Failed to connect to remote server ==> /var/log/dovecot/dovecot-info.log <== 2020-09-24 05:01:44 submission(testrecipient at example.com): Info: Disconnect from 10.0.1.17: Failed to establish relay connection in=0 out=22 (state=GREETING) postfix log Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: connect from internal.mx.example.com[10.0.1.17] Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: SSL_accept error from internal.mx.example.com[10.0.1.17]: -1 Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: lost connection after CONNECT from internal.mx.example.com[10.0.1.17] Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: disconnect from internal.mx.example.com[10.0.1.17] commands=0/0 again, the _only_ change between the two submissions is the addition of the "ServerPreference" option to the openssl.cnf config. still not clear to me which piece(s) of that^ are having an issue with it. or why. for this list, my initial question is -- *IS* it openssl's "fault"? or mine, or one of the other apps'? From openssl-users at dukhovni.org Fri Sep 25 00:51:29 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 24 Sep 2020 20:51:29 -0400 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> <20200924081910.GG64864@straasha.imrryr.org> Message-ID: <20200925005129.GL64864@straasha.imrryr.org> On Thu, Sep 24, 2020 at 07:43:04AM -0700, PGNet Dev wrote: > > I'd be tempted to drop most if not all of those settings, they're not email-friendly. > > PUBLIC email non-friendly, because of still-frequent old cipher/protocol implementations? > > or, > > inherently problematic with TLS in/onr SMTP? Mostly the former. > > Also, Postfix has no knowledge of TLS 1.3 cipher suites, Postfix has > > only cipher configuration knobs only for the TLS <= 1.2 ciphers, so > > I don't know how that particular string ended up in your logs. > > a bit too postfix-y for this list, but ... > > I'm then perhaps misreading > > http://www.postfix.org/TLS_README.html > http://www.postfix.org/FORWARD_SECRECY_README.html > > In any case, the following should be with defaults. > > > Is there something in your Postfix configuration that resembles that > > particular blob? If so, it should not be there... > > yep. now removed ... That's very likely to have been the cause of the problem. That setting was not valid as a TLS <= 1.2 cipherlist. > simplifying > > /etc/pki/tls/openssl.cnf > openssl_conf = default_conf > [default_conf] > ssl_conf = ssl_sect > [ssl_sect] > system_default = system_default_sect > [system_default_sect] > Options = PrioritizeChaCha > > send/receive is successful. > > postfix logs > > Trusted TLS connection established from > internal.mx.example.com[10.0.1.17]: TLSv1.3 with > cipher TLS_AES_256_GCM_SHA384 (256/256 bits) > key-exchange X25519 server-signature ECDSA (P-384) > server-digest SHA384 client-signature ECDSA (P-384) > client-digest SHA384 So client and server both support TLS 1.3, and use AES-256-GCM by default. > changing only > > /etc/pki/tls/openssl.cnf > - Options = PrioritizeChaCha > + Options = ServerPreference,PrioritizeChaCha > > @ re-test submit to dovecot FAILs, > > postfix log > > Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: connect from internal.mx.example.com[10.0.1.17] > Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: SSL_accept error from internal.mx.example.com[10.0.1.17]: -1 > Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331: > Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: lost connection after CONNECT from internal.mx.example.com[10.0.1.17] > Sep 24 05:01:44 mx postfix/submit-from-dovecot-proxy/smtpd[11261]: disconnect from internal.mx.example.com[10.0.1.17] commands=0/0 > > again, the _only_ change between the two submissions is the addition of the "ServerPreference" option to the openssl.cnf config. This looks like the protocol version is no longer TLS 1.3 as a result, and one side or the other now expects or sent the wrong protocol version. For further progress a PCAP file is needed which contains a full capture of exactly one TCP connection corresponding to this failure. You should check for any other non-default Postfix TLS settings that may have been set to poorly chosen values. > still not clear to me which piece(s) of that^ are having an issue with it. or why. Ultimately, the TLS library (OpenSSL) is failing to interoperate between client and server after this change. But whether this is a bug in OpenSSL, or a problem setting in the application is not yet clear. > for this list, my initial question is -- *IS* it openssl's "fault"? > or mine, or one of the other apps'? You need to post A PCAP file that tshark can read with a single TCP session containing the failed handshake. What are the exact OpenSSL versons on the client and server? Anything interesting in openssl.cnf on the client end? -- Viktor. From pgnet.dev at gmail.com Fri Sep 25 01:43:05 2020 From: pgnet.dev at gmail.com (PGNet Dev) Date: Thu, 24 Sep 2020 18:43:05 -0700 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <20200925005129.GL64864@straasha.imrryr.org> References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> <20200924081910.GG64864@straasha.imrryr.org> <20200925005129.GL64864@straasha.imrryr.org> Message-ID: <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> On 9/24/20 5:51 PM, Viktor Dukhovni wrote: >> again, the _only_ change between the two submissions is the addition of the "ServerPreference" option to the openssl.cnf config. > > This looks like the protocol version is no longer TLS 1.3 as a result, > and one side or the other now expects or sent the wrong protocol > version. For further progress a PCAP file is needed which contains a > full capture of exactly one TCP connection corresponding to this > failure. > > You need to post A PCAP file that tshark can read with a single > TCP session containing the failed handshake. Been awhile since I 'de-noised' a comms dump; I'll dust off my notes, & work on getting a useful/relevant PCAP file ... > You should check for any other non-default Postfix TLS settings that > may have been set to poorly chosen values. i need to re-read, again, to figure out what those might be, and what restrictions exist. iiuc, i _should_ be able to lock this all down to specification and use of even a _single_ cipher. it's all/only 'internal' (to my org) transport after all. i can certainly live with a short list -- but with the goal to 'always' end up using TLS13 chacha20-poly1305 suite . >> still not clear to me which piece(s) of that^ are having an issue with it. or why. > > Ultimately, the TLS library (OpenSSL) is failing to interoperate between > client and server after this change. But whether this is a bug in > OpenSSL, or a problem setting in the application is not yet clear. > >> for this list, my initial question is -- *IS* it openssl's "fault"? >> or mine, or one of the other apps'? > > What are the exact OpenSSL versons on the client and server? > Anything interesting in openssl.cnf on the client end? The client/server are the _same_ host. Specifically, dovecot & postfix are submission listeners on the same box -- on different ports, of course. So they both 'experience' the same openssl.cnf Version is openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 provided by distro pacakges on Fedora 32, rpm -qa | grep ssl | sort openssl-1.1.1g-1.fc32.x86_64 openssl-devel-1.1.1g-1.fc32.x86_64 openssl-libs-1.1.1g-1.fc32.x86_64 From openssl-users at dukhovni.org Fri Sep 25 02:32:40 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 24 Sep 2020 22:32:40 -0400 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> <20200924081910.GG64864@straasha.imrryr.org> <20200925005129.GL64864@straasha.imrryr.org> <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> Message-ID: <20200925023240.GP64864@straasha.imrryr.org> On Thu, Sep 24, 2020 at 06:43:05PM -0700, PGNet Dev wrote: > Been awhile since I 'de-noised' a comms dump; I'll dust off my notes, & work on getting a useful/relevant PCAP file ... # tcpdump -s0 -w /some/file tcp port 12345 ^C # tcpdump -r /some/file 'tcp[13] & 0x12 == 2' # tcpdump -r /some/file -s0 -w session.pcap tcp port # tcpdump -r session.pcap See also: https://www.spinics.net/lists/openssl-users/msg05623.html for notes on using "tshark" to extract the detailed protocol diagnostics. These can be somewhat disappointing with TLS 1.3, because privacy...(most of the handshake is encrypted). > Version is > > openssl version > OpenSSL 1.1.1g FIPS 21 Apr 2020 Looking at the upstream OpenSSL source, the first thing to note is that the prefer chacha setting has no effect at all, unless you also have server preference set (which you can do with Postfix settings, rather than globally in the config file). Secondly, the effect of "prefer chacha" is to just synthesize a transient ordered list of server cipher preferences that moves any cha-cha ciphers to the top, cipher selection then continues as usual. So your reported symptoms re protocol version mismatch look rather perplexing, don't know what the client is doing, and whether the client is even linked with OpenSSL? Is dovecot using OpenSSL or GnuTLS? -- Viktor. From pgnet.dev at gmail.com Fri Sep 25 03:30:35 2020 From: pgnet.dev at gmail.com (PGNet Dev) Date: Thu, 24 Sep 2020 20:30:35 -0700 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <20200925023240.GP64864@straasha.imrryr.org> References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> <20200924081910.GG64864@straasha.imrryr.org> <20200925005129.GL64864@straasha.imrryr.org> <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> <20200925023240.GP64864@straasha.imrryr.org> Message-ID: <1dd31e3a-05f8-7d4d-9016-0eabaea6a39f@gmail.com> On 9/24/20 7:32 PM, Viktor Dukhovni wrote: > On Thu, Sep 24, 2020 at 06:43:05PM -0700, PGNet Dev wrote: > >> Been awhile since I 'de-noised' a comms dump; I'll dust off my notes, & work on getting a useful/relevant PCAP file ... > > # tcpdump -s0 -w /some/file tcp port 12345 thx, was already rattling around in the docs! > for notes on using "tshark" to extract the detailed protocol > diagnostics. These can be somewhat disappointing with TLS 1.3, > because privacy...(most of the handshake is encrypted). useful read > Looking at the upstream OpenSSL source, the first thing to note is that > the prefer chacha setting has no effect at all, unless you also have > server preference set (which you can do with Postfix settings, rather > than globally in the config file). i've tried with both tls_preempt_cipherlist = yes enabling postfix's cipher-suite prefs and with tls_preempt_cipherlist = no which iiuc uses the openssl.cnf 'global' setting > Secondly, the effect of "prefer chacha" is to just synthesize a > transient ordered list of server cipher preferences that moves any > cha-cha ciphers to the top, cipher selection then continues as usual. yup, that's one goal ... use chacha whenever available. > So your reported symptoms re protocol version mismatch look rather > perplexing, don't know what the client is doing, and whether the client > is even linked with OpenSSL? Is dovecot using OpenSSL or GnuTLS? dovecot's using openssl. it's used by default, https://wiki2.dovecot.org/CompilingSource#SSL.2FTLS_Support unclear if gnutls is supported still. in any case, the pkgs are built with openssl, https://src.fedoraproject.org/rpms/dovecot/blob/master/f/dovecot.spec#_155 now to the tcpdump ... for this instance with dovecot --version 2.3.10.1 (a3d0e1171) postconf mail_version mail_version = 3.5.7 openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 dovecot submission port == 60465 postfix submission port == 465 & cat /etc/pki/tls/openssl.cnf openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] !! Options = ServerPreference,PrioritizeChaCha submitting the 'failed' (as above) message cat ~/test.eml | msmtp -a internal testrecipient at example.com with this tshark cmd, tshark -n -V -i lo -d tcp.port==465,tls or -d tcp.port==60465,tls which i think does the trick?, the dump of dissected tls packets from both submission ports, is here: https://is.gd/d5R67s From openssl-users at dukhovni.org Fri Sep 25 04:13:13 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 25 Sep 2020 00:13:13 -0400 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <1dd31e3a-05f8-7d4d-9016-0eabaea6a39f@gmail.com> References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> <20200924081910.GG64864@straasha.imrryr.org> <20200925005129.GL64864@straasha.imrryr.org> <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> <20200925023240.GP64864@straasha.imrryr.org> <1dd31e3a-05f8-7d4d-9016-0eabaea6a39f@gmail.com> Message-ID: <20200925041313.GQ64864@straasha.imrryr.org> On Thu, Sep 24, 2020 at 08:30:35PM -0700, PGNet Dev wrote: > for this instance with > > dovecot --version > 2.3.10.1 (a3d0e1171) > postconf mail_version > mail_version = 3.5.7 > openssl version > OpenSSL 1.1.1g FIPS 21 Apr 2020 > > dovecot submission port == 60465 > postfix submission port == 465 > Well, the connection to port 60465 begins with a client TLS HELLO, and then a successful TLS 1.3 handshake takes place. For the connection to 465, the client connects, and just sends "QUIT", which isn't exactly a TLS HELLO. Is that really the session you intended to capture. It is not surprising that the server is "unimpressed" with the client's TLS protocol version. It is surprising that the client sent "QUIT" only .14 seconds after SYN, since if it expected to do SMTP STARTLS, it would typically wait for the server greeting for more than a fraction of a second. -- Viktor. From pgnet.dev at gmail.com Fri Sep 25 04:26:26 2020 From: pgnet.dev at gmail.com (PGNet Dev) Date: Thu, 24 Sep 2020 21:26:26 -0700 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <20200925041313.GQ64864@straasha.imrryr.org> References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> <20200924081910.GG64864@straasha.imrryr.org> <20200925005129.GL64864@straasha.imrryr.org> <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> <20200925023240.GP64864@straasha.imrryr.org> <1dd31e3a-05f8-7d4d-9016-0eabaea6a39f@gmail.com> <20200925041313.GQ64864@straasha.imrryr.org> Message-ID: <946b6af3-8840-8185-e9f0-0450c1b39b81@gmail.com> On 9/24/20 9:13 PM, Viktor Dukhovni wrote: > On Thu, Sep 24, 2020 at 08:30:35PM -0700, PGNet Dev wrote: > Is that really the session you intended to capture. Interestingly phrased! The intention was to capture the tcp data 'thru' the failed event. That^^ is the data streamed to console, with that^^ tshark command, from right before the moment I exec the msmtp send, until it fails ... and sits there. Whether that tshark cmd correctly captures that 'intention', well that's a different issue. > It is surprising that the client sent "QUIT" only .14 seconds after SYN, > since if it expected to do SMTP STARTLS, it would typically wait for the > server greeting for more than a fraction of a second. So, iiuc, that's a dovecot faux pas? I certainly don't supsect that it's the result of anything that postfix signals in the transaction. If it's 'from' dovecot, how would I ferret out whether it's dovecot code "innards", or something in the (mis)function of linked openssl libs? From openssl-users at dukhovni.org Fri Sep 25 07:18:10 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 25 Sep 2020 03:18:10 -0400 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <946b6af3-8840-8185-e9f0-0450c1b39b81@gmail.com> References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> <20200924081910.GG64864@straasha.imrryr.org> <20200925005129.GL64864@straasha.imrryr.org> <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> <20200925023240.GP64864@straasha.imrryr.org> <1dd31e3a-05f8-7d4d-9016-0eabaea6a39f@gmail.com> <20200925041313.GQ64864@straasha.imrryr.org> <946b6af3-8840-8185-e9f0-0450c1b39b81@gmail.com> Message-ID: <20200925071810.GR64864@straasha.imrryr.org> On Thu, Sep 24, 2020 at 09:26:26PM -0700, PGNet Dev wrote: > > It is surprising that the client sent "QUIT" only .14 seconds after SYN, > > since if it expected to do SMTP STARTLS, it would typically wait for the > > server greeting for more than a fraction of a second. > > So, iiuc, that's a dovecot faux pas? No, it is a misconfiguration on your part. Dovecot, as configured, is expecting to talk to a standard SUBMIT service (i.e. SMTP + STARTTLS), but you've configured the server port for TLS wrapper-mode (port 465 SMTP inside implicit TLS). You have to either configure Dovecot to submit to port 587 (or similar) that does not do TLS wrapper-mode (implicit TLS). Or configure it to use implicit TLS. I must lodge a complaint on wasting my time here, you intimated that just changing openssl.cnf makes the difference. But that is clearly not the case, because you're testing different server endpoints, with port 60465 for the "working" case, and "465" for the non-working case. It seems likely that you don't have TLS wrapper mode on port 60465. -- Viktor. From pgnet.dev at gmail.com Fri Sep 25 14:36:44 2020 From: pgnet.dev at gmail.com (PGNet Dev) Date: Fri, 25 Sep 2020 07:36:44 -0700 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <20200925071810.GR64864@straasha.imrryr.org> References: <9841d744-a749-5410-c45a-7df5c8477737@gmail.com> <20200924081910.GG64864@straasha.imrryr.org> <20200925005129.GL64864@straasha.imrryr.org> <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> <20200925023240.GP64864@straasha.imrryr.org> <1dd31e3a-05f8-7d4d-9016-0eabaea6a39f@gmail.com> <20200925041313.GQ64864@straasha.imrryr.org> <946b6af3-8840-8185-e9f0-0450c1b39b81@gmail.com> <20200925071810.GR64864@straasha.imrryr.org> Message-ID: On 9/25/20 12:18 AM, Viktor Dukhovni wrote: > On Thu, Sep 24, 2020 at 09:26:26PM -0700, PGNet Dev wrote: > I must lodge a complaint on wasting my time here seems your're done, then. thx anyway. > you intimated that just changing openssl.cnf makes the difference. i didn't 'intimate'. i stated so. as that is exactly/only what's changed. and the change it causes has been documented. > But that is clearly not the case, because you're testing different server endpoints, with port > 60465 for the "working" case, and "465" for the non-working case. that's simply not the case as stated 60465 is the dovecot submission port 465 it the postfix submission port the mua submits to dovecot at port 60465 dovecot resubmits to postfix at port 465 that same configuration is used in each/every test. again, the ONLY thing that changed between the 'working' and 'failed' cases is the setting in openssl.cnf I never directly submit to 465 > It seems likely that you don't have TLS wrapper mode on port 60465. port 60465 is, and always has been, configured for implicit SSL -- not starttls usage. From openssl-users at dukhovni.org Fri Sep 25 15:55:56 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 25 Sep 2020 11:55:56 -0400 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: References: <20200924081910.GG64864@straasha.imrryr.org> <20200925005129.GL64864@straasha.imrryr.org> <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> <20200925023240.GP64864@straasha.imrryr.org> <1dd31e3a-05f8-7d4d-9016-0eabaea6a39f@gmail.com> <20200925041313.GQ64864@straasha.imrryr.org> <946b6af3-8840-8185-e9f0-0450c1b39b81@gmail.com> <20200925071810.GR64864@straasha.imrryr.org> Message-ID: <20200925155556.GS64864@straasha.imrryr.org> On Fri, Sep 25, 2020 at 07:36:44AM -0700, PGNet Dev wrote: > > But that is clearly not the case, because you're testing different server endpoints, with port > > 60465 for the "working" case, and "465" for the non-working case. > > that's simply not the case > > as stated > > 60465 is the dovecot submission port > 465 it the postfix submission port Well, I expected you to post a working and non-workin trace for the *same* server endpoint, with the good and bad configuration. Secondly, if dovecot is in fact configured to use implicit TLS when forwarding to port 465, then sending a cleartext "QUIT" to that port is rather unexpected behaviour. That would be a dovecot bug. But if, absent the setting in question it actually performs the implicit TLS handshake, despite that setting having no effect on client TLS, then that's rather a mystery. > the mua submits to dovecot at port 60465 dovecot resubmits to postfix > at port 465 Where's the recording of the successful transmission to port 465 (and not say 587). > that same configuration is used in each/every test. The cleartext "QUIT" sent by the client strongly suggests that's not the case. Miracles may happen, but otherwise the only explanation is that the working connections also differed in additional ways beyond the ChaCha preference. > again, the ONLY thing that changed between the 'working' and 'failed' > cases is the setting in openssl.cnf How does that cause Dovecot to use cleartext on port 465, and not send a TLS client HELO? Or was that recording from a connection made by hand with telnet or the like? > I never directly submit to 465 > > > It seems likely that you don't have TLS wrapper mode on port 60465. > > port 60465 is, and always has been, configured for implicit SSL -- not starttls usage. Well, who or what sent QUIT to 465? This time this carefully enough to not make any mistakes, making sure that the recording has the correct data. There should be two separate recordings, both to port 465, one working and one not. Both made by Dovecot, before and after the openssl.cnf change. Make sure to record the second of two failure cases, just in case Dovecot is doing some sort of connection caching, and sends QUIT in the clear by mistake when dropping a cached connection. -- Viktor. From pgnet.dev at gmail.com Fri Sep 25 17:01:18 2020 From: pgnet.dev at gmail.com (PGNet Dev) Date: Fri, 25 Sep 2020 10:01:18 -0700 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <20200925155556.GS64864@straasha.imrryr.org> References: <20200924081910.GG64864@straasha.imrryr.org> <20200925005129.GL64864@straasha.imrryr.org> <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> <20200925023240.GP64864@straasha.imrryr.org> <1dd31e3a-05f8-7d4d-9016-0eabaea6a39f@gmail.com> <20200925041313.GQ64864@straasha.imrryr.org> <946b6af3-8840-8185-e9f0-0450c1b39b81@gmail.com> <20200925071810.GR64864@straasha.imrryr.org> <20200925155556.GS64864@straasha.imrryr.org> Message-ID: <8aa65c6d-cc11-78d3-3dee-c5cb6aac930d@gmail.com> On 9/25/20 8:55 AM, Viktor Dukhovni wrote: > Well, I expected you to post a working and non-workin trace for the > *same* server endpoint, with the good and bad configuration. > > Secondly, (snip) > Where's the recording of the successful transmission to port 465 (and > not say 587). you asked for a capture of the _failed_ transaction. > For further progress a PCAP file is needed which contains a > full capture of exactly one TCP connection corresponding to this > failure. > You need to post A PCAP file that tshark can read with a single > TCP session containing the failed handshake. you did not ask for captures of BOTH failed & successful transactions. i'll pass on the drama. again, thx anyway. From gsonvin at yahoo.com Fri Sep 25 19:17:03 2020 From: gsonvin at yahoo.com (Amy Smith) Date: Fri, 25 Sep 2020 19:17:03 +0000 (UTC) Subject: TCP vs TLS performance (2048 RSA AES) References: <1392765568.800823.1601061423996.ref@mail.yahoo.com> Message-ID: <1392765568.800823.1601061423996@mail.yahoo.com> Hi,I have just started using openssl for my project. I'm building small server application using intel QAT engine.1) ?I'm trying to find benchmark numbers for pure hardware based comparison between with or without QAT engine. I mmap the file which server will send (to eliminate disk performance). Any pointer where to find would be appreciated.2) I'm also trying to check if there is hardware based comparison between tcp vs tls. How much performance degradation I should expect when I start using tls instead of tcp(given it is small embedded server which is mmapping the file). I tried googling it and everywhere is mentions that there is no to very little performance effect between TCP & TLS but that is not what I see.?I see performance degradation of magnitude of 10 times. I use per core measurement. For single core if TCP performance is 50K CPS per core and throughput is 10Gbps, when I modify it to use TLS 2048 RSA with AES performance foes down to ~1Gbps and 300CPS for 128K file download. I'm using home grown tcp stack and also bypassing linux kernel for networking. Thanks,Amy -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Sep 25 21:31:53 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 25 Sep 2020 17:31:53 -0400 Subject: TLS handshake fails ("SSL_accept:error in error") for server->server connection (smtp submit dovecot->postfix) if /etc/pki/tls/openssl.cnf "Options=" includes 'ServerPreference' ? In-Reply-To: <8aa65c6d-cc11-78d3-3dee-c5cb6aac930d@gmail.com> References: <20200925005129.GL64864@straasha.imrryr.org> <451b596d-58ae-01b6-93ac-d3436d5f672d@gmail.com> <20200925023240.GP64864@straasha.imrryr.org> <1dd31e3a-05f8-7d4d-9016-0eabaea6a39f@gmail.com> <20200925041313.GQ64864@straasha.imrryr.org> <946b6af3-8840-8185-e9f0-0450c1b39b81@gmail.com> <20200925071810.GR64864@straasha.imrryr.org> <20200925155556.GS64864@straasha.imrryr.org> <8aa65c6d-cc11-78d3-3dee-c5cb6aac930d@gmail.com> Message-ID: <20200925213153.GV64864@straasha.imrryr.org> On Fri, Sep 25, 2020 at 10:01:18AM -0700, PGNet Dev wrote: > > Where's the recording of the successful transmission to port 465 (and > > not say 587). > > you asked for a capture of the _failed_ transaction. I had intended to ask for both, hard to compare otherwise. Good luck. -- Viktor. From openssl at jordan.maileater.net Sun Sep 27 17:01:20 2020 From: openssl at jordan.maileater.net (Jordan Brown) Date: Sun, 27 Sep 2020 17:01:20 +0000 Subject: TCP vs TLS performance (2048 RSA AES) In-Reply-To: <1392765568.800823.1601061423996@mail.yahoo.com> References: <1392765568.800823.1601061423996.ref@mail.yahoo.com> <1392765568.800823.1601061423996@mail.yahoo.com> Message-ID: <01010174d082fee6-22985099-e9ba-4333-8faf-52eb0c1b2af9-000000@us-west-2.amazonses.com> On 9/25/2020 12:17 PM, Amy Smith via openssl-users wrote: > I mmap the file which server will send (to eliminate disk performance). In general, this won't work.? In fact, it may make it *harder* to eliminate disk performance from a measurement. First, of course, mmap() isn't magic.? The data has to be read off the disk at some point.? The only question is when. Second, mmap() does not necessarily (and probably does not) read the data immediately.? It sets up the paging tables so that those areas of virtual memory are paged to/from the corresponding parts of the file.? Just as for a page that has been kicked out of RAM into swap space, the first access to a page causes the page to be read. If you do a plain read() then you can be pretty confident that when the read() returns the data has been read off the disk and into RAM.? The same is *not* true of mmap().? If you mmap() a file and then start to access it, the disk I/O will be in-line with your accesses. mmap() may eliminate a memory-to-memory copy of the data, since read() probably does not do the disk I/O directly into your process's buffer, but mmap() might.? (Or, a bit more precisely, your mapping might point to the same page that the kernel is using for its disk buffer.) Of course any particular implementation could do things a bit differently, but that's my perception of how it's usually done. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrobson at zenoss.com Mon Sep 28 21:35:55 2020 From: jrobson at zenoss.com (John Robson) Date: Mon, 28 Sep 2020 22:35:55 +0100 Subject: OpenSSL not accepting a certificate, whilst curl does. Message-ID: Hi, I'm really struggling to get my head around a specific scenario that isn't behaving as I expect. Hopefully someone with more experience/knowledge can set me on the right path. Note - my attempts to reproduce this in a lab have been unsuccessful, although I don't have access to the server private key, so the attempts have been with a completely independent CA chain. I have a private CA, which has signed an intermediate certificate which has signed a server certificate for an internal web server which is used by various automated systems (all linux based). The webserver (Apache) has the server cert and key, defined and in use as well as the intermediate certificate defined as the chain certificate - this all shows as expected. I have then added the root certificate to the trusted certs for an automated system (populated `/etc/pki/ca-trust/source/anchors/` run `update-ca-trust extract`). After this curl no longer complains about the certificate from the web server (expected). However OpenSSL still does (unexpected), and I presume that for the same reason(s) urllib in Python also doesn't accept the certificate. If I manually feed `openssl verify` the certificates and chain then they all come back "OK". I've set up these systems a number of times with both self signed and CA signed certs and never seen this behaviour. I'm slightly at a loss as to what diagnostics I even need at this point... so I've dropped a summary of relevant(?) diagnostics at this point below. Thanks, John -- # Check that the root is installed into the trusted bundle: # awk -v cmd='openssl x509 -noout -subject -serial -fingerprint; echo' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.trust.crt | grep -A1 CAROOT subject= /CN=CAROOT/O=org/C=XX serial=4D4C00241A7A17D0 # Check that the pem file I have is correct (serial matches above): # openssl x509 -in CAROOT.pem -text | grep erial Serial Number: 5569826994213492688 (0x4d4c00241a7a17d0) # Check that the chain is contiguous: # openssl x509 -text -noout -in CAROOT.pem | grep -A1 -e Ident -e erial Serial Number: 5569826994213492688 (0x4d4c00241a7a17d0) Signature Algorithm: sha256WithRSAEncryption X509v3 Subject Key Identifier: 2A:3E:33:88:7E:19:35:7C:6E:9D:7C:63:90:80:B8:DF:96:5A:A8:9D X509v3 Authority Key Identifier: keyid:2A:3E:33:88:7E:19:35:7C:6E:9D:7C:63:90:80:B8:DF:96:5A:A8:9D # openssl x509 -text -noout -in CAINTER.pem | grep -A1 -e Ident X509v3 Subject Key Identifier: FB:17:C5:BB:BD:AD:84:65:4F:16:A7:E8:FA:95:1D:C7:D9:29:45:6A X509v3 Authority Key Identifier: keyid:2A:3E:33:88:7E:19:35:7C:6E:9D:7C:63:90:80:B8:DF:96:5A:A8:9D # openssl x509 -text -noout -in SERVER.pem | grep -A1 -e Ident X509v3 Subject Key Identifier: F5:26:E2:09:A4:41:EC:EE:75:E2:4E:E4:02:90:B7:CD:EB:FC:4E:EC X509v3 Authority Key Identifier: keyid:FB:17:C5:BB:BD:AD:84:65:4F:16:A7:E8:FA:95:1D:C7:D9:29:45:6A To my eye those all look lined up, and the serial on the root still agrees. CURL: # curl https://server.fqdn 302 Found

Found

The document has moved here.

OpenSSL: # openssl s_client -connect server.fqdn:443 CONNECTED(00000007) depth=1 CN = CAINTER, O = org, C = XX verify error:num=2:unable to get issuer certificate issuer= CN = CAROOT, O = org, C = XX --8<-- Verify return code: 2 (unable to get issuer certificate) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Tue Sep 29 06:06:00 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 29 Sep 2020 08:06:00 +0200 Subject: OpenSSL not accepting a certificate, whilst curl does. In-Reply-To: References: Message-ID: <1de030e2ffead76cd589be5ce07b112b23551f10.camel@redhat.com> On Mon, 2020-09-28 at 22:35 +0100, John Robson via openssl-users wrote: > Hi, > > I'm really struggling to get my head around a specific scenario that > isn't behaving as I expect. Hopefully someone with more > experience/knowledge can set me on the right path. > > Note - my attempts to reproduce this in a lab have been unsuccessful, > although I don't have access to the server private key, so the > attempts have been with a completely independent CA chain. > > > I have a private CA, which has signed an intermediate certificate > which has signed a server certificate for an internal web server > which is used by various automated systems (all linux based). > > The webserver (Apache) has the server cert and key, defined and in > use as well as the intermediate certificate defined as the chain > certificate - this all shows as expected. > > I have then added the root certificate to the trusted certs for an > automated system (populated `/etc/pki/ca-trust/source/anchors/` run > `update-ca-trust extract`). > > After this curl no longer complains about the certificate from the > web server (expected). > However OpenSSL still does (unexpected), and I presume that for the > same reason(s) urllib in Python also doesn't accept the certificate. > If I manually feed `openssl verify` the certificates and chain then > they all come back "OK". > > I've set up these systems a number of times with both self signed and > CA signed certs and never seen this behaviour. ... > > > CURL: > # curl https://server.fqdn > > > 302 Found > >

Found

>

The document has moved here.

> > > OpenSSL: > # openssl s_client -connect server.fqdn:443 > CONNECTED(00000007) > depth=1 CN = CAINTER, O = org, C = XX > verify error:num=2:unable to get issuer certificate > issuer= CN = CAROOT, O = org, C = XX > --8<-- > Verify return code: 2 (unable to get issuer certificate) What is the curl library linked to? Is it using OpenSSL or something else, for example NSS, as the TLS library? What exact system are you testing on? Are you sure you've put your CAROOT certificate to the system certificate trust store? And/or is the trust store properly set up to be loaded by OpenSSL by default? -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From christian at python.org Tue Sep 29 13:30:40 2020 From: christian at python.org (Christian Heimes) Date: Tue, 29 Sep 2020 15:30:40 +0200 Subject: OpenSSL not accepting a certificate, whilst curl does. In-Reply-To: References: Message-ID: On 28/09/2020 23.35, John Robson via openssl-users wrote: > # curl https://server.fqdn > > > 302 Found > >

Found

>

The document has moved href="https://server.fqdn:443/path/">here.

> > > OpenSSL: > # openssl s_client -connect server.fqdn:443 > CONNECTED(00000007) > depth=1 CN = CAINTER, O = org, C = XX > verify error:num=2:unable to get issuer certificate > issuer= CN = CAROOT, O = org, C = XX > ?--8<-- > Verify return code: 2 (unable to get issuer certificate) Does your server use named based virtual hosting? curl sends a TLS SNI header automatically. With s_client you have to add -servername server.fqdn to send a SNI header. Christian From jrobson at zenoss.com Tue Sep 29 17:17:36 2020 From: jrobson at zenoss.com (John Robson) Date: Tue, 29 Sep 2020 18:17:36 +0100 Subject: OpenSSL not accepting a certificate, whilst curl does. In-Reply-To: <1de030e2ffead76cd589be5ce07b112b23551f10.camel@redhat.com> References: <1de030e2ffead76cd589be5ce07b112b23551f10.camel@redhat.com> Message-ID: tl;dr: Found an issue with update-ca-trust extract OpenSSL doing what it should, but update-ca-trust is only pushing the cert into some of the trust stores. Thanks Tomas On Tue, 29 Sep 2020 at 07:06, Tomas Mraz wrote: > > On Mon, 2020-09-28 at 22:35 +0100, John Robson via openssl-users wrote: > > Hi, > > > > I'm really struggling to get my head around a specific scenario that > > isn't behaving as I expect. Hopefully someone with more > > experience/knowledge can set me on the right path. > > > > Note - my attempts to reproduce this in a lab have been unsuccessful, > > although I don't have access to the server private key, so the > > attempts have been with a completely independent CA chain. > > > > > > I have a private CA, which has signed an intermediate certificate > > which has signed a server certificate for an internal web server > > which is used by various automated systems (all linux based). > > > > The webserver (Apache) has the server cert and key, defined and in > > use as well as the intermediate certificate defined as the chain > > certificate - this all shows as expected. > > > > I have then added the root certificate to the trusted certs for an > > automated system (populated `/etc/pki/ca-trust/source/anchors/` run > > `update-ca-trust extract`). > > > > After this curl no longer complains about the certificate from the > > web server (expected). > > However OpenSSL still does (unexpected), and I presume that for the > > same reason(s) urllib in Python also doesn't accept the certificate. > > If I manually feed `openssl verify` the certificates and chain then > > they all come back "OK". > > > > I've set up these systems a number of times with both self signed and > > CA signed certs and never seen this behaviour. > > ... > > > > OpenSSL: > > # openssl s_client -connect server.fqdn:443 > > CONNECTED(00000007) > > depth=1 CN = CAINTER, O = org, C = XX > > verify error:num=2:unable to get issuer certificate > > issuer= CN = CAROOT, O = org, C = XX > > --8<-- > > Verify return code: 2 (unable to get issuer certificate) > What is the curl library linked to? Is it using OpenSSL or something > else, for example NSS, as the TLS library? What exact system are you > testing on? Running curl -v on a lab box it shows that curl is using NSS, which at least gives some reason for the different behaviour. The system is a dockerised monitoring utility (clue is in the email address) with the containers based on CentOS. > Are you sure you've put your CAROOT certificate to the system > certificate trust store? And/or is the trust store properly set up to > be loaded by OpenSSL by default? Curl complains about the certificate until I add the cert to the ca-trust, so I have a good degree of confidence that the cert has been installed into the trust store - and on all the systems I've installed thus far this has also been picked up by OpenSSL. openssl connect does negotiate a key and cipher, and there is a connection created, so I'm confident there isn't a key/cipher capability mismatch, it's just the certificate verification that is failing. Checking where OpenSSL is using for it's CA trust store: # openssl version -d OPENSSLDIR: "/etc/pki/tls" In that directory cert.pem is a symlink to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, which is subtly different from the /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt I had been searching earlier - however I still see the ROOTCA entry in the pem bundle (and they have identical timestamps, indicating that both were updated by the update-ca-trust extract command). I'm getting a closer look at those files to make sure that the cert has been correctly pushed into them. I can't imagine why it wouldn't have been, but it is the next logical thing to check. OK - The issue is that update-ca-trust extract command i was using doesn't do what I would expect from the docs (and previous experience) Even with the Root CA in the anchors directory it doesn't add it to the TLS ca store, it does add it elsewhere though. If I manually add it to the ca-bundle.trust.crt then OpenSSL does verify the cert correctly, but the cert gets pulled if I then run the update again, so that's not a good long term solution. Since I have the Root CA I can test adding it to a few different containers and see whether there is something about that cert that is causing the odd behaviour. Thanks to Tomas for reminding me there are various different cert trust stores, and for ensuring that I followed the correct path deep enough to figure out what was going on. Now to try and work out ca-certificate behaviour, Cheers, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajprudvi98 at gmail.com Wed Sep 30 16:41:42 2020 From: rajprudvi98 at gmail.com (prudvi raj) Date: Wed, 30 Sep 2020 22:11:42 +0530 Subject: Does Openssl 1.1.1 Supports GHS Platforms ?? Message-ID: Hi, We are upgrading openssl library of our Embedded systems(Networking) codebase which runs on multiple platforms(Linux, Qnx & GHS) , to version 1.1.1g . (currently using 1.0.2.k) With Openssl 1.1.1g ,the CHANGES doc specifies that "QNX support has been removed" , but nowhere there's a mention of GHS .. I couldn't find a list which specifies all the supported platforms by openssl 1.1.1g ,(wiki shows something of Linux, Android, ios , Windows etc.) , So, can Openssl 1.1.1 be integrated into ghs platforms ? (is it still supported ??) Thanks, Prudvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahulmg1983 at gmail.com Wed Sep 30 17:20:11 2020 From: rahulmg1983 at gmail.com (Rahul Godbole) Date: Wed, 30 Sep 2020 22:50:11 +0530 Subject: RAND_bytes() thread safety Message-ID: Hi Is the OpenSSL function RAND_bytes() thread safe? I do not find any mention about thread safety in its man page. Thanks Rahul -------------- next part -------------- An HTML attachment was scrubbed... URL: