Re: [openssl-users] openSSL and SLOTH attack
On 07/01/2016 23:06, jonetsu wrote: Does this mean that running 1.01e in FIPS mode is protected regarding this SLOTH attack ? Does FIPS mode prevent use of MD5: Yes. Does FIPS mode prevent insecure uses of SHA-1 (a FIPS algorithm): No. Does FIPS mode prevent the SSL/TLS handshake from using 96 bit truncated HMAC values: Probably not. Does FIPS mode prevent use of the insecurely designed 'tls-unique' feature: Probably not. 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 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openSSL and SLOTH attack
Does this mean that running 1.01e in FIPS mode is protected regarding this SLOTH attack ? -- View this message in context: http://openssl.6102.n7.nabble.com/openSSL-and-SLOTH-attack-tp62055p62074.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openSSL and SLOTH attack
On 07/01/2016 16:46, Michael Wojcik wrote: As described on that web page, use OpenSSL 1.0.1f or later. That prevents the currently-practical SLOTH attack against RSA-MD5 client authentication. If you're using an OpenSSL release earlier than 1.0.1f, SLOTH is probably not your biggest problem. The authors recommend discontinuing use of MD5 and SHA-1 in general. So does nearly everyone else. Really the risk of continuing to support MD5 and SHA-1 can only meaningfully be evaluated in the context of your own threat model; but either you already know that, or you don't know what your threat model is, in which case the safe move is to drop support for MD5 and SHA-1 as soon as you can. The above is not a very accurate summary. In particular, the following would be a clearer summary: 1. Whenever possible, configure both servers and clients to avoid using MD5 or SHA-1 alone. 2. My suggestion: If it is necessary to retain SHA-1 support due to some correspondents stuck with older weak algorithms (looking at you Microsoft!), then isolate it as much as possible, e.g. with different certificates etc. 3. If possible, configure servers and clients to not choose encryption modes where the TLS handshake is confirmed using only 96 bits of the relevant HMAC. 4. Do not use the "official" tls-unique token to bind something to a TLS handshake, it is unsuited to purpose, even with the recent extension of its format. My suggestion: Instead do a strong hash (SHA-256 or better) of the complete handshake (all handshake messages in both directions, including record headers). 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 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openSSL and SLOTH attack
Michael Wojcik writes: > > As described on that web page, use OpenSSL 1.0.1f or later. That prevents the currently-practical SLOTH > attack against RSA-MD5 client authentication. > > If you're using an OpenSSL release earlier than 1.0.1f, SLOTH is probably not your biggest problem. > > The authors recommend discontinuing use of MD5 and SHA-1 in general. So does nearly everyone else. Really > the risk of continuing to support MD5 and SHA-1 can only meaningfully be evaluated in the context of your > own threat model; but either you already know that, or you don't know what your threat model is, in which > case the safe move is to drop support for MD5 and SHA-1 as soon as you can. > Are the 1.0.0 and 1.0.2 branches also affected? The article states that the issue is present in openssl versions prior to 1.0.1f. If the issue is also present in the 1.0.0 and 1.0.2 branches, will fixes be provided on those branches to address the issue? Thanks very much for your feedback. Best regards, Miriam ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d
Sorry - I thought this topic had come up again (or that this was a new continuation of the older discussion). Now I see it was an old message that had been delayed. Apologies for the noise. -- Michael Wojcik Technology Specialist, Micro Focus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] EVP_PKEY *X509_get0_pubkey(X509 *x);
> On Jan 7, 2016, at 1:39 PM, Ken Goldman wrote: > > 3 - I use this sequence: > > x509 = PEM_read_bio_X509 > EVP_PKEY = X509_get_pubkey > RSA = EVP_PKEY_get1_RSA > > What should be freed? All three structures or just a subset? All three. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] EVP_PKEY *X509_get0_pubkey(X509 *x);
Meta-comment: The documentation is very thin on when objects should or should not be freed. The application developer is forced to chose between [don't free, leak memory] and [free, access freed memory]. ~~ 1 - The documentation here says this API is available, but I don't see it in either the source or the installed header. https://www.openssl.org/docs/manmaster/crypto/X509_get_pubkey.html 2 - The doc also says that X509_get_pubkey() can be used but "the returned key must be freed up after use". It would be nice if it said how to free it. I assume that EVP_PKEY_free() is correct. 3 - I use this sequence: x509 = PEM_read_bio_X509 EVP_PKEY = X509_get_pubkey RSA = EVP_PKEY_get1_RSA What should be freed? All three structures or just a subset? ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Troubleshooting failed TLS negotiation
I'm moving samba service between a couple of FreeBSD systems (9.3 to
10.2), and I'm stuck on getting samba on the new machine to connect to
our openldap server over ssl - frustrating since I've been running
samba+ldap for 15 years or so; feel sure I'm missing something basic!
The smbd-to-ldap connection works fine with no encryption, but I get
errors when using either TLS to port 389 ("Failed to issue the StartTLS
instruction: Connect error"), or for SSL to 636 I get:
failed to bind to server ldaps://ldap-fqdn with dn="cn=admin,dc=..."
Error: Can't contact LDAP server
error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib
I'm pretty certain it's not a certificate or CA validation issue. All my
other ldap clients on that server are working as expected, including a
simple "ldapsearch -ZZ"; and openssl s_client is happy connecting to the
ldaps port. I tested different settings in openldap's ldap.conf, eg
using TLS_CACERTDIR vs TLS_CACERT and different values of TLS_REQCERT;
all seem to work equally well for ldapsearch (and equally badly for smbd).
Capturing the packet exchange between smbd and slapd, I'm seeing the
(smbd) client sends a "decrypt error" (TLS alert code 51) to the ldap
server after receiving the certificate, while the working "ldapsearch
-ZZ" moves on to client key exchange etc.
The biggest difference I can think of between the working and
non-working systems is the openssl version (FreeBSD 10.2 uses 1.0.1p
while 9.3 uses 0.9.8zd - the ldap server is using the latter). However
that doesn't explain all my other 10.x ldap/ssl clients working
successfully...
It sounds a bit like this posting from couple of years ago (which I
unfortunately couldn't see any resolution to):
http://comments.gmane.org/gmane.comp.encryption.openssl.user/49142
I'm not sure where to try looking next for the cause, would welcome any
suggestions...
Thanks, Graham
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] mailing list issues? Re: CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d
> A few zombie messages today: There were some that had been held up on the queue because of things like size limits. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] mailing list issues? Re: CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d
A few zombie messages today: Received: from mta.openssl.org (localhost [127.0.0.1]) by mta.openssl.org (Postfix) with ESMTP id 14CB4201BB; Thu, 7 Jan 2016 12:13:22 + (UTC) X-Original-To: openssl-us...@mta.openssl.org Delivered-To: openssl-us...@mta.openssl.org Received: by mta.openssl.org (Postfix, from userid 106) id 0F2632725F; Thu, 10 Dec 2015 11:50:15 + (UTC) On 10/12/2015 11:50, Jayalakshmi bhat wrote: Hi Matt Thanks for the patch. Unfortunately patch did not work. ... -- J. J. Farrell ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d
On 07/01/2016 15:52, Michael Wojcik wrote:
The proposed change:
--
static inline unsigned int constant_time_msb(unsigned int a)
{
-return 0 - (a >> (sizeof(a) * 8 - 1));
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}
-
produces an implementation-defined value in C99. See the final sentence of ISO
9899-1999 6.5.7 #5:
The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an
unsigned type
or if E1 has a signed type and a nonnegative value, the value of the
result is the integral
part of the quotient of E1 / 2**E2. If E1 has a signed type and a negative
value, the
resulting value is implementation-defined.
Some implementations fill with the sign bit in this case; some fill with 0.
It's possible the standard allows some other behavior.
Ignoring the CHAR_BITS issue, the shift portion of the original version looks
correct to me, assuming no padding bits. (The latter assumption might as well
be made, because it's unlikely the other bit-fiddling constant-time functions
work under an implementation with padding bits, and such implementations are
uncommon.) For an unsigned left operand, that right-shift should produce either
0 or 1, corresponding to the value of the MSB.
That leaves us (in the original code) with the "0 -" part. The intent here is
to have the function return either 0 (if the shift operation results in 0) or high-values
(i.e., an unsigned int with all bits set). Your new code could return 1 under some
implementations for values with the MSB set, so it's not equivalent.
Should the "0 -" part work correctly? The usual arithmetic conversions (6.3.1.8
#1) convert the 0 to 0U (i.e., 0 as an unsigned int), because int and unsigned int have
the same rank. So we either 0U - 0U, which is trivially 0, or 0U - 1U. The result of the
latter is -1, which is outside the range of unsigned int; so the resulting value is
computed by adding UINT_MAX+1 to it (notionally - this addition is per the normal rules
of arithmetic, not constrained by the C implementation). The result is UINT_MAX, which is
within the range of unsigned integer.
So if you see incorrect values from the original code, that looks like another
compiler bug, unless I'm missing something in the standard, or your
implementation doesn't conform to C99. (I don't think the relevant sections
where changed by C11, but I could be wrong.) Unfortunately, while your
alternative might work around it for some cases, it isn't guaranteed to produce
the correct result on all implementations.
Note also that changing "sizeof(a)" to "sizeof(int)" has no effect. Each unsigned integer type has
the same width as the corresponding integer type. That change just makes the code longer and more fragile if the type
of "a" is changed later. (And the parentheses around "a" in the original are unnecessary - sizeof
is an operator, not a function.)
This has all been discussed to death. On the compiler in
question, *both* versions work, but some particular
invocations of this function inlined into certain other
inline functions several levels deep triggers a compiler
bug where the compiler in question throws away a different
arithmetic operation elsewhere in the code and ends up
producing the wrong result. Changing from the portable
implementation to the old non-portable implementation
happens to avoid that compiler bug, by pure chance.
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
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d
The proposed change:
--
static inline unsigned int constant_time_msb(unsigned int a)
{
-return 0 - (a >> (sizeof(a) * 8 - 1));
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}
-
produces an implementation-defined value in C99. See the final sentence of ISO
9899-1999 6.5.7 #5:
The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an
unsigned type
or if E1 has a signed type and a nonnegative value, the value of the result
is the integral
part of the quotient of E1 / 2**E2. If E1 has a signed type and a negative
value, the
resulting value is implementation-defined.
Some implementations fill with the sign bit in this case; some fill with 0.
It's possible the standard allows some other behavior.
Ignoring the CHAR_BITS issue, the shift portion of the original version looks
correct to me, assuming no padding bits. (The latter assumption might as well
be made, because it's unlikely the other bit-fiddling constant-time functions
work under an implementation with padding bits, and such implementations are
uncommon.) For an unsigned left operand, that right-shift should produce either
0 or 1, corresponding to the value of the MSB.
That leaves us (in the original code) with the "0 -" part. The intent here is
to have the function return either 0 (if the shift operation results in 0) or
high-values (i.e., an unsigned int with all bits set). Your new code could
return 1 under some implementations for values with the MSB set, so it's not
equivalent.
Should the "0 -" part work correctly? The usual arithmetic conversions (6.3.1.8
#1) convert the 0 to 0U (i.e., 0 as an unsigned int), because int and unsigned
int have the same rank. So we either 0U - 0U, which is trivially 0, or 0U - 1U.
The result of the latter is -1, which is outside the range of unsigned int; so
the resulting value is computed by adding UINT_MAX+1 to it (notionally - this
addition is per the normal rules of arithmetic, not constrained by the C
implementation). The result is UINT_MAX, which is within the range of unsigned
integer.
So if you see incorrect values from the original code, that looks like another
compiler bug, unless I'm missing something in the standard, or your
implementation doesn't conform to C99. (I don't think the relevant sections
where changed by C11, but I could be wrong.) Unfortunately, while your
alternative might work around it for some cases, it isn't guaranteed to produce
the correct result on all implementations.
Note also that changing "sizeof(a)" to "sizeof(int)" has no effect. Each
unsigned integer type has the same width as the corresponding integer type.
That change just makes the code longer and more fragile if the type of "a" is
changed later. (And the parentheses around "a" in the original are unnecessary
- sizeof is an operator, not a function.)
--
Michael Wojcik
Technology Specialist, Micro Focus
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openSSL and SLOTH attack
Hello users, Is there any fixes available from openSSL community for the SLOTH attack - http://www.mitls.org/pages/attacks/SLOTH or what are the possible mitigation points? Thanks Sandeep ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
