On Tue, 2018-01-16 at 19:31 +, Sands, Daniel wrote:
> On Tue, 2018-01-16 at 14:50 +, Salz, Rich via openssl-dev wrote:
> > OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE
> > OF. Ouch! Will that cause interop problems if we change it? (I
> > don’t remember the DER
On 09/28/2017 12:21 AM, Steffen Nurpmeso wrote:
> Hello.
>
> Tomas Mraz <tm...@redhat.com> wrote:
> |I would like to restart the discussion about possibilities of system-
> |wide configurability of OpenSSL and particularly libssl.
> |
> |Historically OpenSSL all
On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote:
>
> > 1.2. This also opens the path to stronger key derivation (PBKDF2)
> > 2. During decryption, if no header block is present, and no message
> > digest was specified, the default digest SHOULD be MD5.
>
> Should it? What about
I would like to restart the discussion about possibilities of system-
wide configurability of OpenSSL and particularly libssl.
Historically OpenSSL allowed only for configuration of the enabled
ciphersuites list if application called appropriate API call. This is
now enhanced with the SSL_CONF
On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote:
> On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
> > On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev
> > wrote:
> > > I understand the concern. The issue I am wrestling with is
> >
On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev wrote:
> I understand the concern. The issue I am wrestling with is strict
> compatibility with the existing code. Does anyone really *want* the
> RNG’s to not reseed on fork? It’s hard to imagine, but maybe
> somewhere someone is.
On Fri, 2017-07-21 at 15:56 +0200, Johannes Bauer wrote:
> I've changed my code now to also use the (mutable) new
> EC_KEY_METHOD*,
> which doesn't give a diagnostic. Regardless, I believe that the first
> parameter of EC_KEY_METHOD_get_sign should be const EC_KEY_METHOD*,
> not
> EC_KEY_METHOD*.
Just a notice for anyone interested,
In Red Hat Enterprise Linux 6 and 7 we disabled support for insecure
hashes for digital signatures. Basically signatures with MD5, MD4, MD2,
and SHA0 will fail verification by default. We could not switch off the
support for these weak hash algorithms
wing such usability changes for command-
line and also allowing things like removal of obscure or insecure
features but keeping the function signatures intact (they would simply
return errors). And also keep the library SONAME so dependencies do not
need to be rebuilt.
And spare full break of API/ABI for
a NSS
and GnuTLS can use this PKCS11 module directly as a trust store, we
would like to add the same functionality to OpenSSL.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the roa
imited by
other means then perhaps it really makes no sense to replace the
existing algorithm. But we need to know this first.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road
fferent ASN.1 types? Is that it?
I also would not be too much worried - the API call should not be
completely universal - the application should know whether it is
loading a certificate or private key. It should just be able to use a
single call to load a certificate in PEM, DER, or whatever other
possible
Hi,
I'm trying to port OpenVPN to OpenSSL-1.1.0 API.
Unless I overlooked something the new OpenSSL-1.1.0 does not allow
access to the ex_nscert data of the X509 object. Would it be possible
to add such function to the API?
Regards,
--
Tomas Mraz
No matter how far down the wrong road you've
> let us know.
> Hm, not *quite* enough time for me to get a flight to Berlin today...
> and I'd have a three-year-old in tow.
I have a similar problem although I could reach Berlin by train which
is a little bit easier and cheaper. I would be very happy to meet with
O
rectly the
code that is being compiled would be replaced with what is placed into
CFLAGS/LDFLAGS. But things like -D would be kept from the config target
information.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish prov
I would like to join this request as maintainer of OpenSSL for Fedora
and Red Hat Enterprise Linux. It would clean up things for us as well.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never
).
You might get such kind of backport to something that still evolves
such as (RHEL/CentOS 7) however you would not get it in older releases
(RHEL/CentOS 5 and most probably RHEL/CentOS 6 either).
So you will still be facing the issue that there are environments wher
).
You might get such kind of backport to something that still evolves
such as (RHEL/CentOS 7) however you would not get it in older releases
(RHEL/CentOS 5 and most probably RHEL/CentOS 6 either).
So you will still be facing the issue that there are environments wher
object and set it to a
different one and boom, you have doublefree or use-after-free in your
code.
I agree that this sequence - get + set should be more precisely
documented as forbidden but that's it.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
SA_set0_key(rsa, n, e, d);
>
> rsa is left with n and e pointing to unallocated storage.
This is programmer error in your code because the RSA_get0_key is
documented to just return internal data and must not be freed. Thus
you're not allowed to pass the returned values to RSA_set0_key().
-
nst
> that? I could be convinced either way.
>
> Ah ok... sorry, I misread the intention.
>
> Agreed that we could make sure not to free the pointers in that case.
In that case this should be properly documented so the users of the API
can depend on it.
--
Tomas Mraz
No matter how far
nst
> that? I could be convinced either way.
>
> Ah ok... sorry, I misread the intention.
>
> Agreed that we could make sure not to free the pointers in that case.
In that case this should be properly documented so the users of the API
can depend on it.
--
Tomas Mraz
No matter how far
ogic need to be done for all the RSA_set0_*
> functions as well as
> rsalz> > the DSA_set0_* functions.
> rsalz>
> rsalz> That seems like a bug we should fix.
>
> No, it's by design:
>
Then perhaps there should be a function to set only the private part of
the RSA and
ogic need to be done for all the RSA_set0_*
> functions as well as
> rsalz> > the DSA_set0_* functions.
> rsalz>
> rsalz> That seems like a bug we should fix.
>
> No, it's by design:
>
Then perhaps there should be a function to set only the private part of
the RSA and
> engine into a separately managed repo (as has happened recently with
> the
> GOST engine).
>
> If I don't hear from anyone I will remove these.
As far as I know there are some customers using the Chil engine with
RHEL (openssl-1.0.1).
--
Tomas Mraz
No mat
gt; > to be any future calls to OpenSSL before the process exits.
>
> Maybe EVP_cleanup() and other similar explicit deinit functions
> should
> be deprecated, and do nothing in 1.1.0? The auto-deinit capability
> should handle it. That way you would not need to do anything
> "s
What if the server wants to discard all the application data that was
sent before the renegotiation completed? Or how the server can
recognize which part of data was received before renegotiation
completed and which after it?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
The attached patch provides documentation of some of the currently
undocumented speed options.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
diff
aving the API compatibility would be really useful thing
easing porting application code to 1.1 branch.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know wheth
even reasonable to move the implementations into
the libcryptolegacy.so however I am not sure this change is worth it for
1.1.0.
I believe the maintenance costs for pure C implementations in such
separate libcryptolegacy or even in the main C library would be quite
minimal. I would also expect the users of
=0x7ED8220B478B (i.e. the Intel CPU bit is set)
it works fine and the AVX+SSSE3 codepath is taken.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1278194 for
details.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
supported key lengths, etc.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
___
openssl-bugs-mod mailing
parameters. That's
insecure and connect is prevented by the LOGJAM fix. You can configure
the server to not use DH ciphersuites as a workaround, or patch the
mysql server to use at least 1024 bits DH parameters.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
parameters. That's
insecure and connect is prevented by the LOGJAM fix. You can configure
the server to not use DH ciphersuites as a workaround, or patch the
mysql server to use at least 1024 bits DH parameters.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
for future use anymore so I do
not care much if it is removed from openssl master branch. If you
properly announce that the support will be removed unless anybody
provides patch adding support for current secure KRB5 algorithms, I am
OK with that.
Regards,
--
Tomas Mraz
No matter how far down
problem with this. However I would expect these three ifdefs to work -
of course with OPENSSL_NO_EC implying the NO_ECDH amd NO_ECDSA. Although
I did not try it myself.
Tomas Mraz
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org
Hello OpenSSL developers,
can you please include this fix which although a trivial code change
nevertheless does have big impact on the encrypted key-wrapped data.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish
by this change of
default? If the trust anchor is not found in the trust list, the
intermediate that is sent by the peer is followed anyway.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether
once it is
released.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
___
openssl-dev mailing list
openssl
.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
__
OpenSSL Project
if
appropriate.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
__
OpenSSL Project
called for it. I am not sure what
would be the proper fix though.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though
info text.
The attached patch fixes these minor bugs.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
diff --git a/crypto/ts/ts_rsp_verify.c b/crypto/ts
.
Basically what you specify is what you get.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though
Hi,
during the review of OpenSSL commits I found this one:
https://github.com/openssl/openssl/commit/22a10c89d7c3f951339c385d57cc8fd23c0a800b
There is unfortunately not much detail in the commit message. Could this
be a possible security issue? Can you please clear that up?
Thanks,
--
Tomas
. And add something like -notafter argument that would specify the
exact end datetime in the ISO format (not duration) as a second step.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether
with the current version
does not error out.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though
define
PURIFY in their production builds. Anyone know of an example where this is
used
in a production build?
We use -DPURIFY in regular openssl packages in Red Hat Enterprise Linux
and Fedora.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
tools themselves. So once is something found by Coverity
scan it should be considered as public knowledge anyway. Manual review
by real people is something very different.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
to reenable them is to set the security
level to zero as well.
Support is unfortunately only in master at present though.
Would it be possible to get it to 1.0.2? Or is that already closed for
enhancements? Or does it break ABI compatibility?
--
Tomas Mraz
No matter how far down the wrong road
On Út, 2014-06-03 at 16:41 +, Viktor Dukhovni wrote:
On Tue, Jun 03, 2014 at 06:01:03PM +0200, Tomas Mraz via RT wrote:
openssl advertises ECC ciphersuites in SSLv2 client hello if ssl23
method is used. This is incorrect because the TLS extensions that
indicate supported curves
On St, 2014-06-04 at 13:03 +, Viktor Dukhovni wrote:
On Wed, Jun 04, 2014 at 10:45:59AM +0200, Tomas Mraz wrote:
SSLv2 is disabled by default, however when you use the ALL cipher list
which is of course something you should not do but it happened in perl
LDAP module the SSLv2 ciphers
but if you have a special purpose one such as
system set up to use FIPS approved ciphers only this is not right. And
even if there was a way to set the cipher preference string for these
https clients it would be extremely hard and error prone to set the list
for each of them individually.
--
Tomas
to add the support to Fedora openssl package but we would like to
see it upstreamed sooner or later.
Thanks,
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though
.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
diff -up openssl-1.0.1e/apps/req.c.keylen openssl-1.0.1e/apps/req.c
--- openssl-1.0.1e/apps/req.c.keylen 2014
Heh, good :)
As we both came independently to the same patch we can declare it right
and perhaps the openssl upstream developers can finally commit it to the
git repository.
__
OpenSSL Project
))
pm = RSA_PKCS1_OAEP_PADDING;
This appears to be a cut and paste error.
No, this is actually a fix for typo 'oeap' in previous versions.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
.
But given skipping the locking in the FIPS mode doesn't that mean that
the reseed operation is now not being protected under lock at all? The
FIPS DRBG does not lock before calling the add/reseed callbacks.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
(). However MD rand uses
CRYPTO_w_lock(CRYPTO_LOCK_RAND); in ssleay_rand_bytes().
This leads to double locking the CRYPTO_LOCK_RAND which can mean
undefined behavior unless for example in case of pthreads the mutex type
used is PTHREAD_MUTEX_RECURSIVE.
--
Tomas Mraz
No matter how far down the wrong road
those releases.
The -4 worked because the RDRAND engine was erroneously completely
disabled in the Fedora build. Only after the enablement of it the bug in
the CPU detection could manifest.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
is there? Or is
the test not needed because in real life situation this cannot happen? I
suppose it might happen if the key is not renegotiated during lengthy
connections with transfer of data in TB range?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
on forks
(or when a pid change is detected).
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project http://www.openssl.org
Development
the default paths only if neither
-CApath nor -CAfile is specified.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1.0.1c/apps/s_client.c.default-paths openssl-1.0.1c/apps/s_client.c
.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project http://www.openssl.org
Development Mailing List
The str member of EVP_AES_CCM_CTX structure stays uninitialized when aes
ccm is used with the vpaes backend causing it to crash when the str is
later called as it is non-NULL. The attached patch fixes the problem.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
.
It fixes the first problem (although non-portably). But there are still
the signed/unsigned int comparisons of the mtu values later in the code
in d1_both.c. Of course fixing the first problem will probably mask the
second problem.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn
the comparison
fails and the fallback code for choosing some safe MTU value is not
invoked.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
be defined by the underlying installed library version and not
the version it was built against. Of course in case the application
needs to refer to API additions for the new functionality the situation
is different, but that is not the case of TLS1.1.
--
Tomas Mraz
No matter how far down the wrong road
however I have not seen
any reports, at least in our Bugzilla, that would ask for that. So it's
just a matter of preference whether you want to change the 0/n split to
1/n-1 one.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
in libssl would be
counterproductive.
I do not know of any client that uses libssl as TLS backend that would
do such 1/n-1 split on itself.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project http://www.openssl.org
Development Mailing
.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project http://www.openssl.org
Development Mailing
non-NULL pointer in this
case.
The attached patch prevents returning invalid non-NULL pointer from the
fips_get_entropy() function.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-fips-2.0
number in the library to stay
constant. I suppose these applications should have the version check
removed as it is not guaranteed to work anyway as the ABI of openssl
depends also on the compiled-in ciphers and other compile time options.
--
Tomas Mraz
No matter how far down the wrong road you've
need to wait till the moderator
looks at it.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project
The attached trivial patch adds missing check for load_certs_crls
failure in apps.c. It is applicable to 1.0.0 and 1.0.1 branches.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1.0.0a
In some cases when a S/MIME message with broken MIME headers is
processed a NULL dereference in mime_hdr_cmp can happen. The attached
patch guards against this dereference.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
The attached simple patch allows other possible syntaxes of XMPP
starttls headers to be recognized.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -ru openssl-1.0.0d.old/apps/s_client.c openssl-1.0.0d
The attached simple patch moves the libraries that are not needed for
dynamic linking to the Libs.private section in the OpenSSL .pc files.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl
OpenSSL-1.0.1-beta2 build with no-srp option fails because there are
some missing #ifdef OPENSSL_NO_SRP directives in the s_server code. The
attached patch fixes this.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish
The attached patch changes the generated pkgconfig files so the
libraries needed for static linking are in Libs.private instead of Libs.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl
, the latest version is
acceptable.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project http
there for its guest kernels, but I don't believe
that means
we can't rely on the same protocol.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
so that means if the XSAVE test was just
dropped it would work.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project
also
implies that AVX flag [as well as FMA and XOP] is 0, which is why is
jumps to 'done' and not 'clear_avx'.
This assertion is unfortunately not true on RHEL-6 guests on AVX capable
CPUs in XEN VM.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back
The attached patch adds missing documentation for the -no_ign_eof
option.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -up openssl-1.0.0e/doc/apps/s_client.pod.doc-noeof openssl-1.0.0e/doc/apps
Here is analysis by Paolo Bonzini:
I compared crypto/x86_64cpuid.pl and crypto/x86cpuid.pl, and the code in the
latter is wrong.
From x86_64cpuid.pl:
mov %edx,%r10d # %r9d:%r10d is copy of %ecx:%edx
bt \$27,%r9d # check OSXSAVE bit
jnc
with 1/n-1.
Tomas Mraz
diff -up openssl-1.0.0e/ssl/s3_both.c.beast openssl-1.0.0e/ssl/s3_both.c
--- openssl-1.0.0e/ssl/s3_both.c.beast 2010-03-25 00:16:49.0 +0100
+++ openssl-1.0.0e/ssl/s3_both.c 2011-10-13 14:05:50.0 +0200
@@ -758,15 +758,12 @@ int ssl3_setup_write_buffer(SSL *s
of the FIPS
related code from the upstream module but it does not support the
upstream FIPS module.
Tomas Mraz
__
OpenSSL Project http://www.openssl.org
Development Mailing List
technique (sending empty fragments). Evidently there are broken SSL
implementations still in use that don't get along with this technique.
Here is an experimental patch written by me that implements the 1/n-1
record splitting technique for OpenSSL. Please test it if you're
interested.
--
Tomas
There is a missing initialization of a variable in the CHIL engine. In
case the uninitialized value of the variable answer is 'C' and there is
no prompt, the engine startup will erroneously fail.
The attached patch fixes this.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn
and the Red Hat Enterprise Linux
OpenSSL FIPS module is validated independently from the OpenSSL upstream
FIPS module.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
verification test and they do not use the
FIPS_incore_fingerprint call.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL Project
openssl cms help output contains -skeyid option which is actually -keyid
option as recognized by the cms code. The attached trivial patch
corrects the help output.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish
The attached patch written by J.H.M Ray Dassen improves detection of the
XMPP starttls sequence for s_client. Please consider applying it.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
diff -ru openssl
with static DH parameters are not really used.
The bug was found by Coverity scan.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
__
OpenSSL
().
The function then tries to reuse the structure that the pointer is
supposed to be pointing to.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
about -text -noout -out foo.txt writing info to foo.txt, and -text
-out foo.txt to stdout?
That would be still a change in the behavior that shouldn't in my opinon
be committed to the stable branches, definitely not to the 1.0.0 branch.
--
Tomas Mraz
No matter how far down the wrong road you've
of the target of the -text option output will
break expectations of some scripts people in the wild use. Although it
is slightly more logical with the change than before I'd prefer keeping
it as is at least for 1.0.x. Of course the -days error output change is
fine.
--
Tomas Mraz
No matter how far down
1 - 100 of 134 matches
Mail list logo
