Re: [openssl-dev] Blog post; changing in email, crypto policy, etc
* Hubert Kario: > when I mark project as followed I'm getting messages from all issues > and all PRs - likely dozens if not hundred messages a day But isn't that the point? My main concern with Github is that I have no record of my own actions. (Their single-account policy is also a problem for some of us, but that is perhaps our own fault.) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible
* James Bottomley: > On Sat, 2017-03-25 at 16:10 +, Salz, Rich via openssl-dev wrote: >> >> > Please, in the final OpenSSL license text add the paragraph linked >> > in the above LLVM mailing list as an exception to the Apache >> > license. >> > >> > We should make sure using OpenSSL in GPLv2-only projects its >> > possible without any trouble or concern for developers. >> >> The problem is that if it is distributed under the GPLv2 there is no >> patent protection, and that is important to us. > > I've already told you once that this is a factually incorrect statement > because (L)GPLv2 contains an implicit patent licence: I think the fact that Richard rejects dual licensing indicates that it's not the lack of a licence that concerns him, but something else. He calls it “patent protection”; I assume he refers to the weak mutually assured destruction clause in the Apache license (the “If You institute patent litigation against any entity” part). I don't think the GPL, version 2, contains anything remote close to *that*, implied or otherwise. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
* Kurt Roeckx: > On Fri, Mar 24, 2017 at 08:02:25PM +0100, Florian Weimer wrote: >> * Quanah Gibson-Mount: >> >> > Zero people that I know of are saying to switch to the GPL. What is >> > being pointed out is that the incompatibility with the current >> > OpenSSL license with the GPLv2 has been a major problem. >> >> The alleged incompatibility of OpenSSL with the GPLv2 has been used to >> promote GNUTLS in the past (and to a much lesser extent, a certain >> crypto consolidation effort intending to switch everything to NSS). >> But GNUTLS has since left the GNU project, and I'm not aware of anyone >> on the distribution side still saying that the old OpenSSL license >> (particular when used as a dynamically-linked system library) and the >> GPLv2 are incompatible. It's just not considered a problem anymore. > > As far as I know, for Debian it's still a problem that a GPL > application links to openssl. > > A few examples: > - We have multiple curl versions, linked to openssl, gnutls, nss. > And you then have to build against the correct one for license > reasons. > - QT (which is LGPL?) does not itself link to libssl but can > dynamically load it so that GPL applications can use QT assuming > they don't use SSL. > - We have asked upstream projects to add an openssl exception to > their GPL license. A few examples from Debian for the reverse: - cgit links against libssl1.1 and is GPLv2 - tcpflow has GPLv2 pieces and links against libssl1.1 - many GPLv1 and GPLv2 programs which link against libgcc (which is GPLv3 with an exception, but one that arguably does not make it GPLv2-compatible) I also found a few packages with an OpenSSL exception which have merged GPL code from other sources who may or may not have agreed to the exception. It's probably marginally more productive to continue this discussion on a Debian list (not that I think anymore that this discussion matters). -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
* Quanah Gibson-Mount: > Zero people that I know of are saying to switch to the GPL. What is > being pointed out is that the incompatibility with the current > OpenSSL license with the GPLv2 has been a major problem. The alleged incompatibility of OpenSSL with the GPLv2 has been used to promote GNUTLS in the past (and to a much lesser extent, a certain crypto consolidation effort intending to switch everything to NSS). But GNUTLS has since left the GNU project, and I'm not aware of anyone on the distribution side still saying that the old OpenSSL license (particular when used as a dynamically-linked system library) and the GPLv2 are incompatible. It's just not considered a problem anymore. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread
* Nico Williams: > On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote: >> > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? >> >> It seems to have trouble to keep up with new architectures. > > New architectures are not really a problem because between a) decent > compilers with C11 and/or non-C11 atomic intrinsics, Not on Windows. > What's the alternative anyways? Using C++11. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread
* Nico Williams: > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? It seems to have trouble to keep up with new architectures. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread
On 11/25/2015 06:48 PM, Kurt Roeckx wrote: > On Wed, Nov 25, 2015 at 01:02:29PM +0100, Florian Weimer wrote: >> On 11/23/2015 11:08 PM, Kurt Roeckx wrote: >> >>> I think that we currently don't do any compile / link test to >>> detect features but that we instead explicitly say so for each >>> platform. >>> >>> Anyway, the gcc the documentation is here: >>> https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html >>> >>> TLS support clearly isn't supported everywhere. >> >> The most portable approach is to switch C++11, which provides you >> thread-local variables with destructors (and you also get portable >> atomics). There are simply no standards-based C solutions as long as >> you have to support the Microsoft compiler under Windows. > > Please note that we use C, not C++. But C11 has the same atomics > extentions as C++11. C++11 support is much more widespread than C11 support. You will have trouble finding reliable support for C11 atomics with the Microsoft toolchain. > We're also currently still targetting C89/C90 (with some minor > extentions), but I think we should try to use them if the platform > supports it. It is a lot of working getting the atomics right on all supported platforms. Florian ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread
On 11/23/2015 11:08 PM, Kurt Roeckx wrote: > I think that we currently don't do any compile / link test to > detect features but that we instead explicitly say so for each > platform. > > Anyway, the gcc the documentation is here: > https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html > > TLS support clearly isn't supported everywhere. The most portable approach is to switch C++11, which provides you thread-local variables with destructors (and you also get portable atomics). There are simply no standards-based C solutions as long as you have to support the Microsoft compiler under Windows. Florian ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
* Viktor Dukhovni: > If I were to guess, it would be that the base crypto implementations > of IDEA, SEED and binary elliptic curves need to stay. We could > perhaps get away with removing CAST and RIPEMD. Just one data point: CAST5 is still the default for GnuPG when using symmetric encryption. Florian ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
* Kurt Roeckx: > On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote: >> * Viktor Dukhovni: >> >> > If I were to guess, it would be that the base crypto implementations >> > of IDEA, SEED and binary elliptic curves need to stay. We could >> > perhaps get away with removing CAST and RIPEMD. >> >> Just one data point: CAST5 is still the default for GnuPG when using >> symmetric encryption. > > Not in gnupg 2 afaik. Debian stable has GnuPG 2.0.26, and it still uses CAST5: $ gpg2 --batch --passphrase - -c < /dev/null | gpg2 --batch --passphrase - --list-packets :symkey enc packet: version 4, cipher 3, s2k 3, hash 2 salt 45c1df2dc3dd11c2, count 2490368 (179) gpg: CAST5 encrypted data :encrypted data packet: length: 22 gpg: encrypted with 1 passphrase :compressed packet: algo=1 :literal data packet: mode b (62), created 1447798993, name="", raw data: 0 bytes gpg: WARNING: message was not integrity protected GnuPG 2.0 is still “the stable version suggested for most users”, unfortunately. GnuPG 2.1 has indeed switched to AES-128, but only in September 2014. Florian ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Self-initialization of locking/threadid callbacks and auto-detection of features
On 06/15/2015 06:02 PM, Nico Williams wrote: On Thu, Jun 11, 2015 at 10:41:58AM +0200, Florian Weimer wrote: Detecting things in libcrypto is very difficult on GNU/Linux due to the way dynamic linking works. Details? Detection based on weak symbols can break due to linking order (if the main executable is not linked against libpthread). Merely linking against libpthread, without ever creating any threads, is also not an indicator of thread usage (libcrypto, for instance, currently does this unconditionally). Perhaps OpenSSL should have several configuration flavors for Linux then. If you want to statically link a non-threaded program with OpenSSL, then you should use the libpthread static link meant for it. I have not considered the static linking case at all, to be honest. It should be used only very rarely. If the lack of stubs is a problem for static linking, glibc could be enhanced to provide them in a separate archive. A workaound for libraries may be to use a private copy (as if by static linking) of OpenSSL with distinct SONAME/symbols and initialize that copy properly. This is generally safe (we've tried it) but also a bit troublesome. On the plus side this means that ABI incompatibilities betwee OpenSSL releases become a non-issue. We can't do that because too much would need to be recompiled and relinked for updates. Or indeed, libpthread should move into libc (which I gather would take a long time and is beyond what we can do here). See my offer to add more stubs as needed. (Moving the implementation of a library to another requires support for shared object filters, at least on Solaris, so that dynamically-linked dependents of libpthread and such will find the symbols they need there, though the RTLD knows to go look in the object they moved to. We say that libpthread is a filter of libc because only the pthread-related symbols of libc appear in libpthread. IIUC the Linux RTLD does not support filters.) If I understand you correctly, we emulate them with IFUNCs in glibc. There is no additional indirection at run time, calls go directly through the libc implementation even if it is called through the libpthread symbol. Linking -lpthread has a real performance hit for unthreaded applications, so core libraries should avoid it. It shouldn't. We can get rid of the performance overhead for single-threaded case, but it's a multi-year effort, and we haven't even started. What you as a library author can do: do not link against libpthread. Most functionality you might need is available from libc proper, and where it is not, ask for advice on the libc-help list. In any case, the initialization problems when OpenSSL is used by *libraries* are simply unacceptable. Right. -- Florian Weimer / Red Hat Product Security ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 0.9.8 support after 31 Dec 2015
On 07/21/2015 01:16 PM, Brad House wrote: I'm sure you're not the only one that will be needing to support 0.9.8 after the official EOL. RedHat Enterprise Linux 5 comes to mind (supported until 3/2017), so there will definitely be others providing security related patches. On the other hand, Red Hat will only backport critical security fixes to Red Hant Enterprise Linux 5 because it is in Production Phase 3. This is considerably narrower than what is currently provided by OpenSSL upstream 0.9.8. (The main problem people have with 0.9.8 right now is lack of TLS 1.1/1.2 support, and fixing that while preserving binary compatibility with 0.9.8 is quite a challenge.) -- Florian Weimer / Red Hat Product Security ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Self-initialization of locking/threadid callbacks and auto-detection of features
On 10/30/2013 12:15 AM, Nico Williams wrote: On Tue, Oct 29, 2013 at 09:58:25PM +0100, Andy Polyakov wrote: pthreads and Windows, and one can indeed argue why wouldn't OpenSSL simply default to either of the two when appropriate. While it's more than appropriate on Windows as it is, on pthreads-powered Unices it's not as obvious. Because pthreads can be undesired in some situations. Basically it boils down to question whether or not libcrypto may be linked with libpthread or not. And answer is actually not desired. Ideally libcrypto should *detect* if Detecting things in libcrypto is very difficult on GNU/Linux due to the way dynamic linking works. More details would be nice. What follows is speculation of mine as to what you might have in mind (or even if you don't, it might be relevant). To summarize the below: OpenSSL .so's should always be linked with -lpthread on OSes where there's a standard libpthread that threaded apps are expected to use; OpenSSL static link archives should assume no threading libraries and rely on the callers to provide the threading callbacks. On GNU/Linux, you should try very hard to avoid linking -lpthread and restrict yourself to the pthreads API subset which is available without -lpthread. If something is missing, we (as in glibc upstream) can move additional functionality from libpthread to libc. Linking -lpthread has a real performance hit for unthreaded applications, so core libraries should avoid it. If you have received advice to the contrary, your source of advice is wrong. :-) -- Florian Weimer / Red Hat Product Security ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] A Question about CRYPTO_THREADID when upgrading to OpenSSL 1.0.1e
On 01/14/2014 07:12 AM, Aaron wrote: Hi All, We have upgraded our OpenSSL from 9.0.8b to OpenSSL 1.0.1e. We have encountered some thread issues. From releated OpenSSL document (http://www.openssl.org/docs/crypto/threads.html), we see the following description. /CRYPTO_THREADID and associated functions were introduced in OpenSSL 1.0.0 to replace (actually, deprecate) the previous CRYPTO_set_id_callback(), CRYPTO_get_id_callback(), and CRYPTO_thread_id() functions which assumed thread IDs to always be represented by 'unsigned long'. / We haven't change all calls to CRYPTO_set_id_callback(), CRYPTO_get_id_callback(), and CRYPTO_thread_id() in our code to CRYPTO_THREADID routines. The question I would like to ask is if we upgrade OpenSSL from 9.0.8b to OpenSSL 1.0.1e without making the above suggested change what the sebsequence is? Will this cause race conditions? Which platform are you on? -- Florian Weimer / Red Hat Product Security ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw
On 09/03/2014 11:50 PM, Rich Salz via RT wrote: We're going to try to clean up the threads situation post-1.0.2, but closing this particular ticket. Can you at least change the FAQ to make sure that OpenSSL is *not* thread safe by default? Currently, it claims the opposite. The error reporting library critically depends on working locking functions. You get strange results if you believe the FAQ that OpenSSL is thread-safe, even if you do not use any objects across threads. -- Florian Weimer / Red Hat Product Security ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] removing compression?
On 04/03/2015 09:53 PM, Salz, Rich wrote: If this will cause problems for you, please post on the list, ideally within the next week. PostgreSQL uses OpenSSL compression by default, and it is a deliberate feature (there is no application-layer compression support). -- Florian Weimer / Red Hat Product Security ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On 10/15/2014 01:46 AM, Bodo Moeller wrote: Here's a patch for the OpenSSL 1.0.1 branch that adds support for TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack (CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf). Note that the CVE identifier was assigned to the SSL 3.0 protocol issue related to CBC padding. The new SCSV does not help with that at all. But that's not a problem: when both parties support TLS, OpenSSL is not vulnerable even if both sides still enable SSL 3.0 for interoperability reasons with other peers. MITRE has not issued a CVE for the broken fallback behavior because it is not a security vulnerability—it works as designed. This means that the TLS_FALLBACK_SCSV patch currently has no CVE associated with it. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On 10/16/2014 10:41 AM, Salz, Rich wrote: Note that the CVE identifier was assigned to the SSL 3.0 protocol issue related to CBC padding. The new SCSV does not help with that at all. What? It prevents silently falling back to the broken protocol. Perhaps we can keep this battle-thread just in the TLS WG mail? It's unrelated to the TLS WG discussion. MITRE has assigned the CVE name to the SSL 3.0 protocol issue, specifically: “The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack, aka the POODLE issue.” http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566 Securing fallback is a workaround, but does not address the issue. You are still vulnerable if you use SSL 3.0 directly (because one of the peers supports only that), even if both peers implement SCSV. The proper fix comes with TLS 1.0+, and OpenSSL has implemented a transparent protocol upgrade for a long time. Don't be shy—you fixed POODLE before it was discovered, which is great! I had already asked for assignment of a separate CVE for the insecure browser fallback, but I was told that MITRE does not consider *that* a vulnerability because it is expected, documented behavior. This means that fallback-SCSV-related patches do not fix any CVE-named vulnerability, and certainly not CVE-2014-3566. Again, this is not related to the question whether the fallback SCSV is a good idea. It is a procedural issue with CVE naming. Curiously, we recently had the same problem with the bash prefix/suffix patch, which did not fix any concrete CVE-named vulnerability, either. It is confusing, and I think it shows a limitation of the CVE authority file in the light of its current applications. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
On 07/01/2014 11:50 AM, Ben Laurie wrote: Our soon-to-be-released roadmap has this to say on supported platform: * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform I strongly suggest to add 8 bit chars and 32 bit ints as an additional requirement. There is some idea that 16-bit platforms (such as MS-DOS or Windows prior to the Win32 API) are still supported, but this is clearly not the case because a lot of bounds checks assume 32-bit ints. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
On 07/02/2014 02:44 PM, Matt Caswell wrote: I strongly suggest to add 8 bit chars and 32 bit ints as an additional requirement. There is some idea that 16-bit platforms (such as MS-DOS or Windows prior to the Win32 API) are still supported, but this is clearly not the case because a lot of bounds checks assume 32-bit ints. Are there any of these platforms that would pass the Currency/Vendor support criteria? If so which ones? I fear that eComStation could fit these criteria, for the platforms I mentioned. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Locking inefficiency
On 06/11/2014 02:26 PM, Salz, Rich wrote: What kinds of operations are protected by read locks? Looking at almost any of the global data structures, such as error tables, OID tables, and so on. Often, RW locks aren't a win because maintaining just the read locks (without any writers) introduces contention at the hardware level, and parallelism does not increase all that much as a result. Paul McKenney's dissertation on RCU has some examples. We've monitored one of our applications, an SSL-terminating HTTP proxy server, under load. Of all the mutexes (futex, actually) in the system, the error lock is the most highly contended one. I'll see about posting some statistics. Is this CRYPTO_LOCK_ERR? It would be interesting which locking path actually triggers the contention. If it's the thread-local storage re-implementation, it should be possible to use an ERR implementation which uses native thread-local storage, which should be mostly contention-free. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3400] ccs received early
On 06/12/2014 01:28 PM, Salz, Rich wrote: Since the patch for CVE-2014-0224 I've so far received 2 reports about people getting the error: ccs received early. So they kiddies can read. We thought so, but good to have confirmation. Thanks! What do you mean? As far as I can tell, this is about an interoperability issue. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Locking inefficiency
On 06/10/2014 03:31 PM, Bodo Moeller wrote: The way we use the locks, in heavily multi-threaded applications, you can have a lot of contention with mutexes that wouldn't exist with read/write locks, because often all threads would only require the read locks What kinds of operations are protected by read locks? Often, RW locks aren't a win because maintaining just the read locks (without any writers) introduces contention at the hardware level, and parallelism does not increase all that much as a result. Paul McKenney's dissertation on RCU has some examples. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Locking inefficiency
On 06/11/2014 10:24 AM, Peter Waltenberg wrote: The one we (IBM) hit is composite apps. Multiple independently developed lumps of code thrown together - someone has to set the locks, but deciding who is a problem. We deal with it easily as we put a wrapper around OpenSSL and do it there, but that's not always an option. The OS installed OpenSSL's should probably also use the OS default thread model by default for similar reasons. There were also a number of cases of 'user error' with people just forgetting to set up the locking around that time. We face similar issues in Fedora and its downstreams. For glibc, we have stubs in libc which are always available and are NOPs in non-threaded problems, so that it might be feasible to set up the locking primitives by default in libcrypto, without actually linking with -lpthread. The latter is important because the presence of the threading library causes some other libraries to fall back to slower thread-safe variants. This mostly affects libstdc++ and std::shared_ptr (where atomics are used for maintaining the reference count), and to a lesser extend, malloc in glibc itself. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Which platforms will be supported in the future on which platforms will be removed?
On 06/01/2014 09:28 AM, Janpopan wrote: is there a list of currently supported platforms? Which platforms are deprecaded an could/should be removed in the sourcecode? MS-DOS? Windows 16 Bit? OS/2? Windows 95/98/ME? Windows NT/2000/XP? I think there is plenty of code which assumes size_t (and int) of at least 32 bits (in the sense that there are unguarded integer overflows with 16-bit types). Wouldn't this rule out MS-DOS and 16-bit Windows as useful platforms? -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Attribution of pull requests in git
* Ben Laurie: Is there an easy way to fix that? That is, I would expect it to show me as the committer and the original author as the author. git am does this, but merging from a Git repository does not because it changes the commit hashes and would force the submitter to rebase. In general, Git does not reliably track who submits (or fast-forward merges) commits within the system, you'll need an external mechanism for that. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[PATCH] dtls1_reassemble_fragment: Return error code on memory allocation failure
---
ssl/d1_both.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index d8bcd58..2c06fc2 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -679,8 +679,8 @@ dtls1_reassemble_fragment(SSL *s, struct hm_header_st*
msg_hdr, int *ok)
item = pitem_new(seq64be, frag);
if (item == NULL)
{
- goto err;
i = -1;
+ goto err;
}
pqueue_insert(s-d1-buffered_messages, item);
--
1.9.0
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [PATCH] Reseed PRNG on PID change
On 01/16/2014 05:03 PM, David Jacobson wrote: If you want to make sure they diverge, and make sure that multiple forks diverge differently, you should push in the process ID. Pushing in time helps with (but does not perfectly cure) the virtual machine copying problem. So I suggest pushing in the PID concatenated with some sort of time. The PID is already mixed in. It turned out this was not sufficient because PIDs are reused (see e.g. CVE-2013-1900). My initial idea was to reseed the pool if a PID change was detected, but reseeding with a high-resolution timer appears preferable. It also sidesteps the LinuxThreads issue. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Reseed PRNG on PID change
On 01/15/2014 05:44 PM, Dr. Stephen Henson wrote: On Wed, Jan 15, 2014, Florian Weimer wrote: Commit 3cd8547a2018ada88a4303067a2aa15eadc17f39 mixed the current time into the randomness pool each time RAND_bytes is called. As the resolution of gettimeofday() is limited, I propose to reseed the PRNG each time a PID change is detected. I know historically some platforms have different PIDs for different threads. That would cause problems with this patch. Ah, good old LinuxThreads. I admit it's not totally dead yet. I can add a Linux- and glibc-specific detection function which disables the reseeding if LinuxThreads is detected. (Other systems had strange threading libraries as well, but those generally shared PIDs.) Regarding replacing gettimeofday() with a CPU tick counter, I expect that many systems have a very fast gettimeofday() implementation these days (based in part on a CPU tick counter). However, time() has no such acceleration on the machines I've tested, so the current code shows a significant performance hit compared to 3cd8547a2^. The additional resolution of a tick counter might make reseeding after fork unnecessary, but it's difficult to be sure. Something not based on timing information looks desirable to me. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Reseed PRNG on PID change
On 01/16/2014 01:57 PM, Dr. Stephen Henson wrote:
On Thu, Jan 16, 2014, Florian Weimer wrote:
The additional resolution of a tick counter might make reseeding
after fork unnecessary, but it's difficult to be sure. Something
not based on timing information looks desirable to me.
I should point out that the aim of the current code is not to completely
reseed after fork() but to make the PRNG state diverge so that the two
processes do not share the same internal PRNG state.
I get that. I've reconsidered things. Time seems the only thing that
deals with the related VM snapshot issue.
I still propose to get rid of the time() call (md_rand-time.patch,
AFAICT num == 0 at this point, so I pulled the initialization out of the
loop). OPENSSL_rdtsc() appears to return 0 if the cycle counter is not
available, so md_rand-rtdsc.patch calls it unconditionally if RDRAND is
not available.
--
Florian Weimer / Red Hat Product Security Team
commit 594dcc12d4ede5cd6f4e11cdc23fff3eea20cdcf
Author: Florian Weimer fwei...@redhat.com
Date: Thu Jan 16 15:16:38 2014 +0100
ssleay_rand_seed: optimize fork protection: do not call time()
diff --git a/crypto/rand/md_rand.c b/crypto/rand/md_rand.c
index 6cab308..f2165cd 100644
--- a/crypto/rand/md_rand.c
+++ b/crypto/rand/md_rand.c
@@ -368,7 +368,6 @@ static int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo)
#ifndef GETPID_IS_MEANINGLESS
pid_t curr_pid = getpid();
#endif
- time_t curr_time = time(NULL);
int do_stir_pool = 0;
/* time value for various platforms */
#ifdef OPENSSL_SYS_WIN32
@@ -508,6 +507,15 @@ static int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo)
crypto_lock_rand = 0;
CRYPTO_w_unlock(CRYPTO_LOCK_RAND);
+ /* try to diverge the random sequence after fork and VM resumption */
+#ifndef GETPID_IS_MEANINGLESS
+ if (!MD_Update(m,(unsigned char*)curr_pid, sizeof curr_pid))
+ goto err;
+#endif
+ if (!MD_Update(m,(unsigned char*)tv, sizeof tv))
+ goto err;
+ rand_hw_seed(m);
+
while (num 0)
{
/* num_ceil -= MD_DIGEST_LENGTH/2 */
@@ -515,26 +523,6 @@ static int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo)
num-=j;
if (!MD_Init(m))
goto err;
-#ifndef GETPID_IS_MEANINGLESS
- if (curr_pid) /* just in the first iteration to save time */
- {
- if (!MD_Update(m,(unsigned char*)curr_pid,
- sizeof curr_pid))
-goto err;
- curr_pid = 0;
- }
-#endif
- if (curr_time) /* just in the first iteration to save time */
- {
- if (!MD_Update(m,(unsigned char*)curr_time,
- sizeof curr_time))
-goto err;
- if (!MD_Update(m,(unsigned char*)tv,
- sizeof tv))
-goto err;
- curr_time = 0;
- rand_hw_seed(m);
- }
if (!MD_Update(m,local_md,MD_DIGEST_LENGTH))
goto err;
if (!MD_Update(m,(unsigned char *)(md_c[0]),sizeof(md_c)))
commit 8cfc51d808a3d3b3118f3d3168fcba6c0ce79b9c
Author: Florian Weimer fwei...@redhat.com
Date: Thu Jan 16 15:35:40 2014 +0100
ssleay_rand_bytes: use cycle counter if RDRAND is not available
diff --git a/crypto/rand/md_rand.c b/crypto/rand/md_rand.c
index f2165cd..51acf44 100644
--- a/crypto/rand/md_rand.c
+++ b/crypto/rand/md_rand.c
@@ -382,9 +382,6 @@ static int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo)
#elif defined(OPENSSL_SYS_VXWORKS)
struct timespec tv;
clock_gettime(CLOCK_REALTIME, ts);
-#elif defined(OPENSSL_SYSNAME_DSPBIOS)
- unsigned long long tv, OPENSSL_rdtsc();
- tv = OPENSSL_rdtsc();
#else
struct timeval tv;
gettimeofday(tv, NULL);
@@ -674,7 +671,13 @@ static void rand_hw_seed(EVP_MD_CTX *ctx)
{
int i;
if (!(OPENSSL_ia32cap_P[1] (1(62-32
+ {
+ /* using the cycle counter is better than nothing at all */
+ unsigned long long tv, OPENSSL_rdtsc();
+ tv = OPENSSL_rdtsc();
+ MD_Update(ctx, (unsigned char *)tv, sizeof(tv));
return;
+ }
for (i = 0; i RDRAND_CALLS; i++)
{
size_t rnd;
@@ -721,7 +724,10 @@ void rand_hw_xor(unsigned char *buf, size_t num)
static void rand_hw_seed(EVP_MD_CTX *ctx)
{
- return;
+ /* using the cycle counter is better than nothing at all */
+ unsigned long long tv, OPENSSL_rdtsc();
+ tv = OPENSSL_rdtsc();
+ MD_Update(ctx, (unsigned char *)tv, sizeof(tv));
}
void rand_hw_xor(unsigned char *buf, size_t num)
Re: [PATCH] Reseed PRNG on PID change
On 01/16/2014 03:39 PM, Florian Weimer wrote: I still propose to get rid of the time() call (md_rand-time.patch, AFAICT num == 0 at this point, so I pulled the initialization out of the loop). Disregard the patches, this doesn't work. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[PATCH] Reseed PRNG on PID change
Commit 3cd8547a2018ada88a4303067a2aa15eadc17f39 mixed the current time
into the randomness pool each time RAND_bytes is called. As the
resolution of gettimeofday() is limited, I propose to reseed the PRNG
each time a PID change is detected.
This change might also be an alternative for platforms where the
gettimeofday() call is prohibitively slow.
--
Florian Weimer / Red Hat Product Security Team
commit 136a8da88ff52ad32f894fb0ecbcab5f4205ca49
Author: Florian Weimer fwei...@redhat.com
Date: Wed Jan 15 16:46:17 2014 +0100
ssleay_rand_bytes: Re-seed on PID change
diff --git a/crypto/rand/md_rand.c b/crypto/rand/md_rand.c
index 6cab308..75382b5 100644
--- a/crypto/rand/md_rand.c
+++ b/crypto/rand/md_rand.c
@@ -153,6 +153,9 @@ static unsigned char md[MD_DIGEST_LENGTH];
static long md_count[2]={0,0};
static double entropy=0;
static int initialized=0;
+#ifndef GETPID_IS_MEANINGLESS
+static pid_t prev_pid=0;
+#endif
static unsigned int crypto_lock_rand = 0; /* may be set only when a thread
* holds CRYPTO_LOCK_RAND
@@ -201,6 +204,7 @@ static void ssleay_rand_cleanup(void)
md_count[1]=0;
entropy=0;
initialized=0;
+ prev_pid=0;
}
static int ssleay_rand_add(const void *buf, int num, double add)
@@ -439,7 +443,16 @@ static int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo)
{
RAND_poll();
initialized = 1;
+ prev_pid = curr_pid;
+ }
+#ifndef GETPID_IS_MEANINGLESS
+ if (curr_pid != prev_pid)
+ {
+ RAND_poll();
+ prev_pid = curr_pid;
}
+#endif
+
if (!stirred_pool)
do_stir_pool = 1;
Re: [PATCH] sha1-x86_64/ssse3: enforce stack alignment
On 12/15/2013 07:53 PM, Yuriy Kaminskiy wrote: Apparently, stack can be misaligned on BSD (nasty! is it even allowed by amd64 ABI?), and openssl fails to deal with it (funnily, it aligns stack in non-ssse3 version [where it is only efficiency issue], but fails to do this in ssse3 version [where it is mandatory]). It's required by the amd64 ABI, and other things will break if this requirement is violated. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1e: crash in sha1_block_data_order_ssse3()
On 12/17/2013 03:17 AM, Claus Assmann wrote: Can you please try putting a breakpoint on sha1_block_data_order_ssse3, and checking what the value of %rsp is at the start of the function? Breakpoint 5, sha1_block_data_order_ssse3 () at sha1-x86_64.s:1295 1295pushq %rbx Current language: auto; currently asm (gdb) p $rsp $15 = (void *) 0x8007360a0 [looks ok] Actually, it doesn'ton function entry, %rsp must be congruent 8 modulo 16. Could you do the same thing (breakpoint and look at %rsp) for the callers up the call stack? Do you link dynamically or statically? What's your GCC version? -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1e: crash in sha1_block_data_order_ssse3()
On 12/14/2013 05:50 PM, Claus Assmann wrote: Program received signal SIGBUS, Bus error. sha1_block_data_order_ssse3 () at sha1-x86_64.s:1328 1328movdqa %xmm0,0(%rsp) movdqa needs 16-byte alignment. rsp0x800736048 0x800736048 %rsp is only 8-byte aligned. This is likely a toolchain bug, and not something that can be reasonably fixed in OpenSSL. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: UTF8 decoding, unneeded byte masking
On 08/25/2013 12:23 PM, PMHager wrote: If your intention is performance optimization you could even replace if((*p 0x80) == 0) with if((signed char)(*p) = 0) as you cannot assume that all compilers will do it correctly themselves. Actually, this proposed change relies on a GCC extension. If *p is unsigned, compilers are allowed to assume that (signed char)(*p) = 0 is always true (because signed overflow is undefined). -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 06/14/2013 03:31 PM, Dr. Stephen Henson wrote: Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared libraries are updated to include the patch existing applications wont set it: they'd all need to be recompiled. That's a valid point. Possibly alternative is to reuse one of the existing *ancient* flags. Does anyone really care about compatibility with a bug in SSLeay 0.80 for example? Wouldn't it be better to reverse the meaning of the flag and not set it in SSL_OP_ALL? -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Add WEB cipher suite selector
The attached patch adds a WEB entry to the cipher list selection. The
idea is that applications can just use that and get a reasonable set of
cipher suites, offering a trade-off between security and
interoperability. These cipher suites are all certificate-based, so
that applications send a protocol-compliant client hello without
explicitly disabling the cipher suites they do not support because they
will never supply the required key material.
--
Florian Weimer / Red Hat Product Security Team
From af125d1abb2af6dd4853188d2e6d99963ae959c2 Mon Sep 17 00:00:00 2001
From: Florian Weimer fwei...@redhat.com
Date: Mon, 26 Nov 2012 18:02:28 +0100
Subject: [PATCH] Add WEB cipher list entry
---
doc/apps/ciphers.pod | 7 +++
ssl/s2_lib.c | 2 +-
ssl/s3_lib.c | 162 +--
ssl/ssl.h| 1 +
ssl/ssl_ciph.c | 1 +
ssl/ssl_locl.h | 5 +-
6 files changed, 94 insertions(+), 84 deletions(-)
diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod
index c571830..ba08d19 100644
--- a/doc/apps/ciphers.pod
+++ b/doc/apps/ciphers.pod
@@ -139,6 +139,13 @@ the cipher suites not enabled by BALL, currently being BeNULL.
high encryption cipher suites. This currently means those with key lengths
larger than 128 bits, and some cipher suites with 128-bit keys.
+=item BWEB
+
+Cipher suites with certificate-based authentication which are also
+part of BHIGH, plus additional cipher suites required for web
+application interoperability. Currently, this adds RC4-based cipher
+suites with 128-bit keys, and triple DES with an MD5 MAC.
+
=item BMEDIUM
medium encryption cipher suites, currently some of those using 128 bit
diff --git a/ssl/s2_lib.c b/ssl/s2_lib.c
index b37792f..316350f 100644
--- a/ssl/s2_lib.c
+++ b/ssl/s2_lib.c
@@ -248,7 +248,7 @@ OPENSSL_GLOBAL const SSL_CIPHER ssl2_ciphers[]={
SSL_3DES,
SSL_MD5,
SSL_SSLV2,
- SSL_NOT_EXP|SSL_HIGH,
+ SSL_NOT_EXP|SSL_HIGH|SSL_WEB,
0,
168,
168,
diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index c6ecd8f..3f4415e 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -223,7 +223,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_RC4,
SSL_MD5,
SSL_SSLV3,
- SSL_NOT_EXP|SSL_MEDIUM,
+ SSL_NOT_EXP|SSL_MEDIUM|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
128,
128,
@@ -239,7 +239,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_RC4,
SSL_SHA1,
SSL_SSLV3,
- SSL_NOT_EXP|SSL_MEDIUM,
+ SSL_NOT_EXP|SSL_MEDIUM|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
128,
128,
@@ -321,7 +321,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_3DES,
SSL_SHA1,
SSL_SSLV3,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
168,
168,
@@ -370,7 +370,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_3DES,
SSL_SHA1,
SSL_SSLV3,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
168,
168,
@@ -418,7 +418,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_3DES,
SSL_SHA1,
SSL_SSLV3,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
168,
168,
@@ -467,7 +467,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_3DES,
SSL_SHA1,
SSL_SSLV3,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
168,
168,
@@ -515,7 +515,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_3DES,
SSL_SHA1,
SSL_SSLV3,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
168,
168,
@@ -890,7 +890,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_AES128,
SSL_SHA1,
SSL_TLSV1,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
128,
128,
@@ -905,7 +905,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_AES128,
SSL_SHA1,
SSL_TLSV1,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
128,
128,
@@ -920,7 +920,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_AES128,
SSL_SHA1,
SSL_TLSV1,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
128,
128,
@@ -935,7 +935,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_AES128,
SSL_SHA1,
SSL_TLSV1,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
128,
128,
@@ -950,7 +950,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_AES128,
SSL_SHA1,
SSL_TLSV1,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB,
SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
128,
128,
@@ -981,7 +981,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
SSL_AES256,
SSL_SHA1,
SSL_TLSV1,
- SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS|SSL_WEB
Re: [openssl.org #2909] Wildcard support for certificate matching (plus fixes)
On 11/18/2012 04:16 PM, Stephen Henson via RT wrote:
I have also added a manual page. The test case does not have full
coverage, but it is better than nothing.
Many thanks for the patch. I've applied it with a few minor changes. Let
me know if I broke anything.
Thanks for showing me the concise way for setting GENERAL_NAMEs.
I've adjusted the test case to cover the new return values
(v3nametest.patch). It shouldn't matter from a testing point of view,
but I think it's important to show the correct error checking.
The IDNA filter for wildcards was incomplete, and I couldn't find this
in any standard, so I suggest removing it (idna.patch).
--
Florian Weimer / Red Hat Product Security Team
commit 373bf51bb3a64f4d91241752be7178104d0de28b
Author: Florian Weimer fwei...@redhat.com
Date: Mon Nov 19 11:04:56 2012 +0100
Adjust v3nametest.c return value checking to API
diff --git a/crypto/x509v3/v3nametest.c b/crypto/x509v3/v3nametest.c
index 5bf1201..c1d5ff3 100644
--- a/crypto/x509v3/v3nametest.c
+++ b/crypto/x509v3/v3nametest.c
@@ -273,28 +273,38 @@ static void run_cert(X509 *crt, const char *nameincert,
ret = X509_check_host(crt, (const unsigned char *)name,
namelen, 0);
match = -1;
- if (fn-host)
+ if (ret 0)
{
- if (ret !samename)
+ fprintf(stderr, internal error in X509_check_host);
+ ++errors;
+ }
+ else if (fn-host)
+ {
+ if (ret == 1 !samename)
match = 1;
- if (!ret samename)
+ if (ret == 0 samename)
match = 0;
}
- else if (ret)
+ else if (ret == 1)
match = 1;
check_message(fn, host, nameincert, match, *pname);
ret = X509_check_host(crt, (const unsigned char *)name,
namelen, X509_CHECK_FLAG_NO_WILDCARDS);
match = -1;
- if (fn-host)
+ if (ret 0)
{
- if (ret !samename)
+ fprintf(stderr, internal error in X509_check_host);
+ ++errors;
+ }
+ else if (fn-host)
+ {
+ if (ret == 1 !samename)
match = 1;
- if (!ret samename)
+ if (ret == 0 samename)
match = 0;
}
- else if (ret)
+ else if (ret == 1)
match = 1;
check_message(fn, host-no-wildcards,
nameincert, match, *pname);
commit b399db5b4a31dd13ebc2ee114501c4ee20b748f2
Author: Florian Weimer fwei...@redhat.com
Date: Mon Nov 19 11:32:38 2012 +0100
X509_check_host: remove IDNA wildcard block
I couldn't find this in any standard, and the check was incomplete
anyway.
diff --git a/crypto/x509v3/v3_utl.c b/crypto/x509v3/v3_utl.c
index ffd9f0d..de43c2f 100644
--- a/crypto/x509v3/v3_utl.c
+++ b/crypto/x509v3/v3_utl.c
@@ -719,12 +719,7 @@ static const unsigned char *wildcard_find_star(const unsigned char *pattern,
static int equal_wildcard(const unsigned char *pattern, size_t pattern_len,
const unsigned char *subject, size_t subject_len)
{
- const unsigned char *star;
- /* Do not match IDNA names. */
- if (subject_len =4 memcmp(subject, xn--, 4) == 0)
- star = NULL;
- else
- star = wildcard_find_star(pattern, pattern_len);
+ const unsigned char *star = wildcard_find_star(pattern, pattern_len);
if (star == NULL)
return equal_nocase(pattern, pattern_len,
subject, subject_len);
diff --git a/crypto/x509v3/v3nametest.c b/crypto/x509v3/v3nametest.c
index c1d5ff3..aa0d29c 100644
--- a/crypto/x509v3/v3nametest.c
+++ b/crypto/x509v3/v3nametest.c
@@ -24,6 +24,7 @@ static const char *const exceptions[] =
set CN: host: [*.example.com] matches [a.example.com],
set CN: host: [*.example.com] matches [b.example.com],
set CN: host: [*.example.com] matches [www.example.com],
+ set CN: host: [*.example.com] matches [xn--rger-koa.example.com],
set CN: host: [test.*.example.com] does not match [test.*.example.com],
set CN: host: [test.*.example.com] matches [test.www.example.com],
set CN: host: [*.www.example.com] does not match [*.www.example.com],
@@ -36,6 +37,7 @@ static const char *const exceptions[] =
set dnsName: host: [*.example.com] does not match [*.example.com],
set dnsName: host: [*.example.com] matches [a.example.com],
set dnsName: host: [*.example.com] matches [b.example.com],
+ set dnsName: host: [*.example.com] matches [xn--rger-koa.example.com],
set dnsName: host: [*.www.example.com] matches [test.www.example.com],
set dnsName: host: [*.www.example.com] does not match [*.www.example.com],
set dnsName: host: [test.*.example.com] matches [test.www.example.com],
Fix GCC asm constraints in crypto/bn/asm/x86_64-gcc.c
When x32 support was added to this file, the constraint was dropped, allowing GCC to overlap register assignments for inputs and outputs, resulting in broken assembler code. -- Florian Weimer / Red Hat Product Security Team commit 9dbf28460d10387c819d332b7a5c0397942b75ee Author: Florian Weimer fwei...@redhat.com Date: Mon Nov 19 12:52:36 2012 +0100 Fix asm constraints in bn_add_words, bn_sub_words diff --git a/crypto/bn/asm/x86_64-gcc.c b/crypto/bn/asm/x86_64-gcc.c index d34d2dc..dfb7506 100644 --- a/crypto/bn/asm/x86_64-gcc.c +++ b/crypto/bn/asm/x86_64-gcc.c @@ -199,7 +199,7 @@ BN_ULONG bn_add_words (BN_ULONG *rp, const BN_ULONG *ap, const BN_ULONG *bp,int lea 1(%2),%2 \n loop 1b \n sbbq %0,%0 \n - : =r(ret),+c(n),+r(i) + : =r(ret),+c(n),+r(i) : r(rp),r(ap),r(bp) : cc ); @@ -224,7 +224,7 @@ BN_ULONG bn_sub_words (BN_ULONG *rp, const BN_ULONG *ap, const BN_ULONG *bp,int lea 1(%2),%2 \n loop 1b \n sbbq %0,%0 \n - : =r(ret),+c(n),+r(i) + : =r(ret),+c(n),+r(i) : r(rp),r(ap),r(bp) : cc );
Replace scary comment in s3_pkt.c
Apparently, the IV initialization was moved to tls1_enc() t1_enc.c, so
the commented-put initialization is indeed superfluous. And indeed, the
IV on the wire appears to be random.
Could someone please double-check this? Thanks.
--
Florian Weimer / Red Hat Product Security Team
commit 6ad93dd6f8ccfdb5cafe5403de8952c568657fb6
Author: Florian Weimer fwei...@redhat.com
Date: Mon Nov 19 15:10:29 2012 +0100
Replace scary comment with cross-reference
diff --git a/ssl/s3_pkt.c b/ssl/s3_pkt.c
index dca3458..239a101 100644
--- a/ssl/s3_pkt.c
+++ b/ssl/s3_pkt.c
@@ -811,8 +811,7 @@ static int do_ssl3_write(SSL *s, int type, const unsigned char *buf,
if (eivlen)
{
- /* if (RAND_pseudo_bytes(p, eivlen) = 0)
- goto err; */
+ /* IV is initialized in tls1_enc(). */
wr-length += eivlen;
}
SSL_connect.pod fix
There's a POD error in the manpage, resulting in quite misleading documentation. -- Florian Weimer / Red Hat Product Security Team commit cb06d593d1a59c932614c4e97055b441fc66c4ec Author: Florian Weimer fwei...@redhat.com Date: Tue Nov 13 14:22:44 2012 +0100 Fix POD usage in SSL_connect.pod Current perlpod needs some escaping, otherwise it will render a numbered list, resulting totally misleading return values. diff --git a/doc/ssl/SSL_connect.pod b/doc/ssl/SSL_connect.pod index cc56ebb..aa0f802 100644 --- a/doc/ssl/SSL_connect.pod +++ b/doc/ssl/SSL_connect.pod @@ -41,18 +41,18 @@ The following return values can occur: =over 4 -=item 1 +=item C1 The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been established. -=item 0 +=item C0 The TLS/SSL handshake was not successful but was shut down controlled and by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the return value Bret to find out the reason. -=item Elt0 +=item EltC0 The TLS/SSL handshake was not successful, because a fatal error occurred either at the protocol level or a connection failure occurred. The shutdown was
Wildcard support for certificate matching (plus fixes)
Hi,
the attached patch implements wildcard matching and introduces the
X509_CHECK_FLAG_NO_WILDCARDS flag to disable it if necessary.
In addition, it implements case-insensitive comparison of host names and
email address domain parts, as required by RFC 5280. Domain names and
email addresses which contain NUL characters are now rejected, to cope
with some mis-issued certificates.
I have also added a manual page. The test case does not have full
coverage, but it is better than nothing.
It might make sense to change the API so that 0 means success, 1 match
failure, and -1 an internal error. Right now, it is not possible to
tell match failures and internal errors apart.
Florian
--
Florian Weimer / Red Hat Product Security Team
diff --git a/crypto/x509v3/Makefile b/crypto/x509v3/Makefile
index 07e2df4..b54f540 100644
--- a/crypto/x509v3/Makefile
+++ b/crypto/x509v3/Makefile
@@ -13,7 +13,7 @@ AR= ar r
CFLAGS= $(INCLUDES) $(CFLAG)
GENERAL=Makefile README
-TEST=
+TEST=v3nametest.c
APPS=
LIB=$(TOP)/libcrypto.a
diff --git a/crypto/x509v3/v3_utl.c b/crypto/x509v3/v3_utl.c
index db9f05e..8f88e69 100644
--- a/crypto/x509v3/v3_utl.c
+++ b/crypto/x509v3/v3_utl.c
@@ -568,12 +568,177 @@ void X509_email_free(STACK_OF(OPENSSL_STRING) *sk)
sk_OPENSSL_STRING_pop_free(sk, str_free);
}
+typedef int (*equal_fn)(const unsigned char *pattern, size_t pattern_len,
+ const unsigned char *subject, size_t subject_len);
+
+/* Compare while ASCII ignoring case. */
+static int equal_nocase(const unsigned char *pattern, size_t pattern_len,
+ const unsigned char *subject, size_t subject_len)
+ {
+ if (pattern_len != subject_len)
+ return 0;
+ while (pattern_len)
+ {
+ unsigned char l = *pattern;
+ unsigned char r = *subject;
+ /* The pattern must not contain NUL characters. */
+ if (l == 0)
+ return 0;
+ if (l != r)
+ {
+ if ('A' = l l = 'Z')
+l = (l - 'A') + 'a';
+ if ('A' = r r = 'Z')
+r = (r - 'A') + 'a';
+ if (l != r)
+return 0;
+ }
+ ++pattern;
+ ++subject;
+ --pattern_len;
+ }
+ return 1;
+ }
+
+/* Compare using memcmp. */
+static int equal_case(const unsigned char *pattern, size_t pattern_len,
+ const unsigned char *subject, size_t subject_len)
+{
+ /* The pattern must not contain NUL characters. */
+ if (memchr(pattern, '\0', pattern_len) != NULL)
+ return 0;
+ if (pattern_len != subject_len)
+ return 0;
+ return !memcmp(pattern, subject, pattern_len);
+}
+
+/* RFC 5280, section 7.5, requires that only the domain is compared in
+ a case-insensitive manner. */
+static int equal_email(const unsigned char *a, size_t a_len,
+ const unsigned char *b, size_t b_len)
+ {
+ if (a_len != b_len)
+ return 0;
+ size_t i = a_len;
+ /* We search backwards for the '@' character, so that we do
+ not have to deal with quoted local-parts. The domain part
+ is compared in a case-insensitive manner. */
+ while (i 0)
+ {
+ --i;
+ if (a[i] == '@' || b[i] == '@')
+ {
+ if (!equal_nocase(a + i, a_len - i,
+ b + i, a_len - i))
+return 0;
+ break;
+ }
+ }
+ if (i == 0)
+ i = a_len;
+ return equal_case(a, i, b, i);
+ }
+
+/* Compare the prefix and suffix with the subject, and check that the
+ characters in-between are valid. */
+static int wildcard_match(const unsigned char *prefix, size_t prefix_len,
+ const unsigned char *suffix, size_t suffix_len,
+ const unsigned char *subject, size_t subject_len)
+ {
+ const unsigned char *wildcard_start;
+ const unsigned char *wildcard_end;
+ const unsigned char *p;
+ if (subject_len prefix_len + suffix_len)
+ return 0;
+ if (!equal_nocase(prefix, prefix_len, subject, prefix_len))
+ return 0;
+ wildcard_start = subject + prefix_len;
+ wildcard_end = subject + (subject_len - suffix_len);
+ if (!equal_nocase(wildcard_end, suffix_len, suffix, suffix_len))
+ return 0;
+ /* The wildcard must match at least one character. */
+ if (wildcard_start == wildcard_end)
+ return 0;
+ /* Check that the part matched by the wildcard contains only
+ permitted characters and only matches a single label. */
+ for (p = wildcard_start; p != wildcard_end; ++p)
+ if (!(('0' = *p *p = '9') ||
+ ('A' = *p *p = 'Z') ||
+ ('a' = *p *p = 'z') ||
+ *p == '-'))
+ return 0;
+ return 1;
+ }
+
+/* Checks if the memory region consistens of [0-9A-Za-z.-]. */
+static int valid_domain_characters(const unsigned char *p, size_t len)
+ {
+ while (len)
+ {
+ if (!(('0' = *p *p = '9') ||
+ ('A' = *p *p = 'Z') ||
+ ('a' = *p *p = 'z') ||
+ *p == '-' || *p == '.'))
+ return 0;
+ ++p;
+ --len;
+ }
+ return 1;
+ }
+
+/* Find the '*' in a wildcard pattern. If no such character is found
+ or the pattern is otherwise invalid, returns NULL. */
+static const unsigned char *wildcard_find_star(const unsigned char *pattern,
+ size_t pattern_len)
+ {
+ const unsigned char *star = memchr(pattern, '*', pattern_len);
+ size_t dot_count = 0;
+ const unsigned char
Re: [openssl.org #447] [Fwd: Bug#176058: openssl: Should askpassword only after basic input validation]
Richard Levitte via RT [EMAIL PROTECTED] writes: It would be good to know exactly which openssl commands are involved in this issue. I'm pretty sure this issue only applies for some of them. openssl ca is one of them, and probably the most cumbersome. openssl req -new -out $FILE does not verify that $FILE is a writable file. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #447] [Fwd: Bug#176058: openssl: Should ask password only after basic input validation]
Richard Levitte via RT [EMAIL PROTECTED] writes: It would be good to know exactly which openssl commands are involved in this issue. I'm pretty sure this issue only applies for some of them. openssl ca is one of them, and probably the most cumbersome. openssl req -new -out $FILE does not verify that $FILE is a writable file. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Delayed release of OpenSSL 0.9.6a beta 3
Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes:
The release of OpenSSL 0.9.6a beta3 and the true release have been
delayed. The reason for the delay is mainly due to the following
paper and the need to add a fix for the problem it describes:
http://crypto.stanford.edu/~dabo/abstracts/faults.html
Thanks for addressing this issue. The current fix for RSA-CRT, i.e.
+ if (rsa-e rsa-n)
+ {
+ if (!meth-bn_mod_exp(vrfy,r0,rsa-e,rsa-n,ctx,NULL)) goto err;
+ if (BN_cmp(I, vrfy) != 0)
+ {
+ if (!meth-bn_mod_exp(r0,I,rsa-d,rsa-n,ctx,NULL)) goto err;
+ }
+ }
is not activated if the key material doesn't provide n. Wouldn't it
be a good idea to calculate n = pq if it's not present?
Of course, calculating e is not so easy, but it should be possible to
derive it as well (from d and q).
OTOH, it's probably faster to calculate n = pq and not to rely CRT at
all.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
