Re: questions on using ed25519

[Viktor Dukhovni]

On Wed, Apr 22, 2020 at 11:46:16AM +0800, yang berlin wrote:

> Wow, thanks for the detailed reply!
> Actually I am a master student and my teacher wants me to figure out the
> use of ed25519. So I went to see openssl.
> I thought ed25519 can sign messages so I tried the dgst command. Now I know
> that I was wrong.

Well, actually it *does* sign messages, but not via "openssl dgst",
because typically ed25519 is used to sign short messages without first
running them through a digest function.  This makes it resistant to hash
function collion attacks.

There is actually more than one flavour of the ed25519 signature
algorithm, see RFC8032:

https://tools.ietf.org/html/rfc8032#section-4
https://tools.ietf.org/html/rfc8032#section-5

You can use "pkeyutl" to directly sign (short messages) with (pure)
ed25519, or, for longer messages, you can use the "prehash" variant
which signs a SHA2-512 hash.

--
Viktor.

Re: questions on using ed25519

[yang berlin]

Wow, thanks for the detailed reply!
Actually I am a master student and my teacher wants me to figure out the
use of ed25519. So I went to see openssl.
I thought ed25519 can sign messages so I tried the dgst command. Now I know
that I was wrong.
Anyway, thank you again!

Viktor Dukhovni  于2020年4月22日周三 上午1:35写道：

> On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote:
>
> > I want to use ed25519 in openssl.
>
> Why?  What actual real-world purpose do you have for ed25519?
>
> > The problem I met is: I can use "speed ed25519" to test the speed of
> > ed25519, but when I use "dgst -ed25519", it tells me that "dgst:
> > Unrecognized flag Ed25519".
>
> That's because "ed25519" is not a digest algorithm, it is a public key
> algorithm.  You can use it to sign messages, but not to compute message
> digests.
>
> > So could you please help me to learn how to use ed25519 correctly?
>
> That question has no answer.  Whether a use of "ed25519" is correct or
> incorrect depends on the security protocol in which it is to be used,
> and whether that protocol is appropriate to security requirements of
> the application using it.
>
> If you're just playing with ed25519, you can generate ed25519 keys with:
>
> $ openssl genpkey -algorithm ed25519 -out privkey.pem
>
> You can extract just the public key via:
>
> $ openssl pkey -in privkey.pem -pubout -out pubkey.pem
>
> You can generate an ed25519 self-signed public key certificate with:
>
> $ openssl req -key privkey.pem -new \
> -x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem
>
> You can use the key and certificate with s_client, and s_server
> via the "-key" and "-cert" arguments.
>
> You can also sign and/or encrypt messages with ed25519 using cms(1),
> but you may not be ready to dive into cms.
>
> Low-level public and private key operations are possible via pkeyutl(1).
>
> While the dgst(1) command supports signing message digests with various
> public key signature algorithms, ed25519 is not one of these:
>
>-sign filename
>Digitally sign the digest using the private key in "filename".
> Note
>this option does not support Ed25519 or Ed448 private keys. Use
> the
>pkeyutl command instead for this.
>
> See the pkeyutl(1) manpage.
>
> Don't assume that some use of encryption implies any gain in security.
> It could be mere security theatre.  For actual security you need to
> apply a robust protocol that matches the application's security
> requirements.
>
> --
> Viktor.
>

Re: CMS in openssl

[Jakob Bohm via openssl-users]

A few corrections:

OpenSSL included CMS (RFC3369) support since 1.0.0 (see the CHANGES 
file), though for a long time, there was an arbitrary disconnect between 
functions named CMS and functions named PKCS#7 even though it should 
have been a continuum.


The PKCS#7 and CMS standards equally and fully support any 
non-interactive algorithm that has been assigned an OID, from 
RSA+MD2+DES to HSS/LSS+STREEBOG+CAMELIA, no artifical version 
dependencies like in the OpenSSL interpretation of TLS.


On 2020-04-22 03:46, Michael Richardson wrote:

Michael Mueller  wrote:
 > We've implemented what I gather can be called a CMS on Linux and Windows
 > using openssl evp functions.

I'm not sure why you say it this way.
OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0.
Did you implement RFC3369, or something else?

You don't say if this is email or something else.

 > We need to expand this CMS to other systems, on which we have not been 
able
 > to build openssl. These other systems have a vendor supplied security
 > application. This application supports PKCS7.

 > We are being asked if our evp CMS is interoperable with PKCS7.

CMS (RFC3369/2630) is an upward revision to PKCS7 (RFC2315) 1.5.
CMS can read PKCS7 messages, but converse is not true.

I think it is possible to configure the CMS routines to produce PKCS7
messages, but I didn't do this in my RFC8366 support. I just forklift
upgraded to CMS.

 > If it is possible and more information is required to answer this 
question,
 > I'll provide such information.

 > If not, advice on how to present that argument to management would be
 > appreciated.

You will understand them, but they won't understand you.

You may be able to configure your end to generate PKCS7 easily, and it may
have little effect.  This might degenerate until just using PKCS7 everywhere.

The major difference is the eContentType that is lacking in PKCS7.
And algorithms: I think that there are few modern algorithms defined for PKCS7.

You could easily run in PKCS7 mode until you receive a CMS message from the
peer, and then upgrade to CMS.  But this winds up in a bid-down attack if
both parties run this algorithm, so you'd want to insert some extension that
said: "I can do CMS" into your PKCS7 messages.



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

Re: CMS in openssl

[Michael Richardson]

Michael Mueller  wrote:
> We've implemented what I gather can be called a CMS on Linux and Windows
> using openssl evp functions.

I'm not sure why you say it this way.
OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0.
Did you implement RFC3369, or something else?

You don't say if this is email or something else.

> We need to expand this CMS to other systems, on which we have not been 
able
> to build openssl. These other systems have a vendor supplied security
> application. This application supports PKCS7.

> We are being asked if our evp CMS is interoperable with PKCS7.

CMS (RFC3369/2630) is an upward revision to PKCS7 (RFC2315) 1.5.
CMS can read PKCS7 messages, but converse is not true.

I think it is possible to configure the CMS routines to produce PKCS7
messages, but I didn't do this in my RFC8366 support. I just forklift
upgraded to CMS.

> If it is possible and more information is required to answer this 
question,
> I'll provide such information.

> If not, advice on how to present that argument to management would be
> appreciated.

You will understand them, but they won't understand you.

You may be able to configure your end to generate PKCS7 easily, and it may
have little effect.  This might degenerate until just using PKCS7 everywhere.

The major difference is the eContentType that is lacking in PKCS7.
And algorithms: I think that there are few modern algorithms defined for PKCS7.

You could easily run in PKCS7 mode until you receive a CMS message from the
peer, and then upgrade to CMS.  But this winds up in a bid-down attack if
both parties run this algorithm, so you'd want to insert some extension that
said: "I can do CMS" into your PKCS7 messages.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[




signature.asc
Description: PGP signature

Re: How to disable renegation before compiling openssl

[Salz, Rich via openssl-users]

  *   Sorry for being unclear, the goal would be to just not send the SCSV 
value in the ClientHello.

Why?

Re: OpenSSL Security Advisory

[Sam Roberts]

That makes sense, thank you all.

Re: How to disable renegation before compiling openssl

[Mark Windshield]

Thanks for you reply Ben!

Sorry for being unclear, the goal would be to just not send the SCSV value
in the ClientHello.

-Mark

Am Di., 21. Apr. 2020 um 22:06 Uhr schrieb Benjamin Kaduk :

> On Tue, Apr 21, 2020 at 09:57:02PM +0200, Mark Windshield wrote:
> > Hello,
> >
> > I was wondering what I'd have to change in the openssl code/config before
> > compiling to have renegation disabled by default, so it won't send the
> > Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using curl.
>
> This description does not really make it clear whether you just want to
> prevent
> renegotiation or specifically need this SCSV value to not be included in
> the
> ClientHello -- the semantics of TLS_EMPTY_RENEGOTIATION_INFO_SCSV is "if
> renegotiation occurs, the client supports the 'secure' variant", but is
> otherwise orthogonal to whether renegotiation itself actually occurs.
>
> -Ben
>

Re: opensssl 1.1.1g test failure(s)

[Dennis Clarke via openssl-users]

On 2020-04-21 18:45, Michael Tuexen wrote:

On 21. Apr 2020, at 23:49, Matt Caswell  wrote:



On 21/04/2020 18:34, Claus Assmann wrote:

Thanks for the reply, below is the output, It seems it only fails
because the host doesn't support IPv6?


Yes - it does seem to be an IPv6 problem. I don't recall any recent
changes in this area. Were you successfully able to run the tests with
previous versions of OpenSSL?

Looks like the failing call is here:

if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
   (const void *)&on, sizeof(on)) != 0) {

Can you provide a pointer to the code?

Best regards
Michael


To which we get an errno indicating "Invalid argument". So it looks like
your host has the relevant IPV6 macros defined (otherwise we would have
got a compilation failure) - but doesn't understand them when used.

If you're not using IPv6 on that host and this is the only test failure
then it can probably be safely ignored.

Matt


Not sure what the complaints are however here on the most strict POSIX
risc environment with a really strict compiler :


.
.
.
All tests successful.
Files=155, Tests=1460, 1378 wallclock secs (10.52 usr  1.12 sys + 
1251.44 cusr 53.76 csys = 1316.84 CPU)

Result: PASS
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1g_SunOS5.10_sparc64vii+.001'

alpha$
alpha$
alpha$ uname -a
SunOS alpha 5.10 Generic_150400-65 sun4u sparc SUNW,SPARC-Enterprise
alpha$
alpha$ psrinfo -pv
The physical processor has 2 virtual processors (2 3)
  SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)
alpha$
alpha$ cc -V
cc: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30
alpha$
alpha$


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: opensssl 1.1.1g test failure(s)

[Michael Tuexen]

> On 21. Apr 2020, at 23:49, Matt Caswell  wrote:
> 
> 
> 
> On 21/04/2020 18:34, Claus Assmann wrote:
>> Thanks for the reply, below is the output, It seems it only fails
>> because the host doesn't support IPv6?
> 
> Yes - it does seem to be an IPv6 problem. I don't recall any recent
> changes in this area. Were you successfully able to run the tests with
> previous versions of OpenSSL?
> 
> Looks like the failing call is here:
> 
>if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
>   (const void *)&on, sizeof(on)) != 0) {
Can you provide a pointer to the code?

Best regards
Michael
> 
> To which we get an errno indicating "Invalid argument". So it looks like
> your host has the relevant IPV6 macros defined (otherwise we would have
> got a compilation failure) - but doesn't understand them when used.
> 
> If you're not using IPv6 on that host and this is the only test failure
> then it can probably be safely ignored.
> 
> Matt

Re: opensssl 1.1.1g test failure(s)

[Kurt Roeckx]

On Tue, Apr 21, 2020 at 10:49:25PM +0100, Matt Caswell wrote:
> 
> Looks like the failing call is here:
> 
> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
>(const void *)&on, sizeof(on)) != 0) {
> 
> To which we get an errno indicating "Invalid argument". So it looks like
> your host has the relevant IPV6 macros defined (otherwise we would have
> got a compilation failure) - but doesn't understand them when used.

OpenBSD is really weird in this regard. They always use the
behavior of IPV6_V6ONLY set to on. But if you actually try to set
it on, they return an error. They should instead return an error
when you try to set it off.


Kurt

Re: opensssl 1.1.1g test failure(s)

[Matt Caswell]

On 21/04/2020 18:34, Claus Assmann wrote:
> Thanks for the reply, below is the output, It seems it only fails
> because the host doesn't support IPv6?

Yes - it does seem to be an IPv6 problem. I don't recall any recent
changes in this area. Were you successfully able to run the tests with
previous versions of OpenSSL?

Looks like the failing call is here:

if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
   (const void *)&on, sizeof(on)) != 0) {

To which we get an errno indicating "Invalid argument". So it looks like
your host has the relevant IPV6 macros defined (otherwise we would have
got a compilation failure) - but doesn't understand them when used.

If you're not using IPv6 on that host and this is the only test failure
then it can probably be safely ignored.

Matt

Re: OpenSSL Security Advisory

[Matt Caswell]

On 21/04/2020 20:46, Sam Roberts wrote:
> The announcement claims that this affects SSL_check_chain().
>
> Is that an exhaustive list? If an application does NOT call that
> function, does this mean the vulnerability is not exploitable?

As Ben says - this is correct.

>
> I ask because the the fixed function tls1_check_sig_alg is called by
> tls1_check_chain, and that is called directly by SSL_check_chain, but
> it is also called by tls1_set_cert_validity, and that is called from

You will note that tls1_check_sig_alg is only affected if we go down the
TLSv1.3 codepath. However tls1_set_cert_validity() only has one caller
and it looks like this:

if (SSL_IS_TLS13(s)) {
...
} else {
tls1_set_cert_validity(s);
ssl_set_masks(s);
}

So it is only ever called in a non-TLSv1.3 handshake.

Matt


> inside the tls state machine, but with different parameters, so its a
> bit hard to see if it is affected or not.
>
> Thanks,
> Sam
>
> On Tue, Apr 21, 2020 at 6:26 AM OpenSSL  wrote:
>>
> OpenSSL Security Advisory [21 April 2020]
> =
> 
> Segmentation fault in SSL_check_chain (CVE-2020-1967)
> =
> 
> Severity: High
> 
> Server or client applications that call the SSL_check_chain() function during 
> or
> after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a
> result of incorrect handling of the "signature_algorithms_cert" TLS extension.
> The crash occurs if an invalid or unrecognised signature algorithm is received
> from the peer. This could be exploited by a malicious peer in a Denial of
> Service attack.
> 
> OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue.  This
> issue did not affect OpenSSL versions prior to 1.1.1d.
> 
> Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g
> 
> This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April
> 2020. It was found using the new static analysis pass being implemented in 
> GCC,
> -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin
> Kaduk.
> 
> Note
> =
> 
> This issue did not affect OpenSSL 1.0.2 however these versions are out of
> support and no longer receiving public updates. Extended support is available
> for premium support customers: https://www.openssl.org/support/contracts.html
> 
> This issue did not affect OpenSSL 1.1.0 however these versions are out of
> support and no longer receiving updates.
> 
> Users of these versions should upgrade to OpenSSL 1.1.1.
> 
> References
> ==
> 
> URL for this Security Advisory:
> https://www.openssl.org/news/secadv/20200421.txt
> 
> Note: the online version of the advisory may be updated with additional 
> details
> over time.
> 
> For details of OpenSSL severity classifications please see:
> https://www.openssl.org/policies/secpolicy.html
>

Re: TLSv1 on CentOS-8

[Viktor Dukhovni]

On Tue, Apr 21, 2020 at 04:06:04PM +0100, Junaid Mukhtar wrote:

> I have managed to block the RC4 and enable tlsv1 as per our requirements.
> 
> We have a requirement to match cipher list on the internal server to match
> the native browser cipher list as shown by the
> https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html

That requirement is likely ill-considered and unwise.  You end up
freezing in a stale list that was somebody's idea of best practice at a
point in time, often for a specific use-case that may not be yours, and
sometimes without understanding what they're doing.

> I have tried setting up different combinations on the CipherString but none
> helped. Do you have any suggestions as to how to do achieve this?

Instead, configure a broadly interoperable list of ciphers that are
known to be safe enough.  The 'DEFAULT' list is a good starting point,
and you can subtract a few types of ciphers from that as needed.

On my FreeBSD 12 system, which has OpenSSL 1.1.1, I get:

$ openssl ciphers -v -s -tls1_2 DEFAULT
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) 
Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256) 
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256) 
Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA  
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH   Au=RSA  
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) 
Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(128) 
Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(128) 
Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)  
Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA384
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)  
Mac=SHA256
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES256-SHA  TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES256-SHATLSv1 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-RSA-AES128-SHATLSv1 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA1
AES256-GCM-SHA384   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA256
AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA256
AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1

from which you could perhaps remove the kRSA ciphers, if insisting on
forward-secrecy does not break some important-enough pool of clients.

DEFAULT:!kRSA

Otherwise, I don't see anything on that list I'd be inclined to remove.

For a more advance "performance-optimized" list where AES128 is
preferred over CHACHA20 and AES256, you could go with:

AES128:CHACHA20:AES256:-ALL:ALL:!COMPLEMENTOFDEFAULT:!kRSA

The idea is to resist the temptation to explicitly order a specific list
of individual ciphers, and instead take the DEFAULT list, and lightly
prune it and/or rearrange it to optimize for some particular features.

-- 
Viktor.

Re: How to disable renegation before compiling openssl

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 09:57:02PM +0200, Mark Windshield wrote:
> Hello,
> 
> I was wondering what I'd have to change in the openssl code/config before
> compiling to have renegation disabled by default, so it won't send the
> Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using curl.

This description does not really make it clear whether you just want to prevent
renegotiation or specifically need this SCSV value to not be included in the
ClientHello -- the semantics of TLS_EMPTY_RENEGOTIATION_INFO_SCSV is "if
renegotiation occurs, the client supports the 'secure' variant", but is
otherwise orthogonal to whether renegotiation itself actually occurs.

-Ben

How to disable renegation before compiling openssl

[Mark Windshield]

Hello,

I was wondering what I'd have to change in the openssl code/config before
compiling to have renegation disabled by default, so it won't send the
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using curl.

Thanks!

Re: opensssl 1.1.1g test failure(s)

[Jakob Bohm via openssl-users]

Summary: The OpenSSL 1.1.1g test suite contains at least two bugs:

TestBug#1: Test suite fails if local network has no IPv6, error message 
(non-
  verbose) doesn't say that's the issue.  [ Testing IPv6 makes sense, 
rejecting
  regression tests on inadequate machines is important to avoid silent 
failures,
  but not telling testers that a test precondition failed or which ones 
is bad.

  ]

TestBug#2: Test suite uses ambiguous wording to report the index of 
failed test.

  Should have said "Failed test indexes:  2" or "Failed test: #2" (latter
  needs to repeat "#" for each index listed)

On 21/04/2020 19:34, Claus Assmann wrote:

On Tue, Apr 21, 2020, Benjamin Kaduk via openssl-users wrote:

On Tue, Apr 21, 2020 at 07:22:38PM +0200, Claus Assmann wrote:

../test/recipes/80-test_ssl_old.t ..
Dubious, test returned 1 (wstat 256, 0x100)

Please run again with `make V=1 TESTS=test_ssl_old test` and post the relevant 
parts of the output?

Thanks for the reply, below is the output, It seems it only fails
because the host doesn't support IPv6?

make depend && make _tests
( cd test;  mkdir -p test-runs;  SRCTOP=../.  BLDTOP=../.  RESULT_D=test-runs  
PERL="/usr/bin/perl"  EXE_EXT=  OPENSSL_ENGINES=`cd .././engines 2>/dev/null && 
pwd`  OPENSSL_DEBUG_MEMORY=on  /usr/bin/perl .././test/run_tests.pl test_ssl_old )
../test/recipes/80-test_ssl_old.t ..
1..6
# Subtest: test_ss
 1..17

...

0:error:0200E016:system library:setsockopt:Invalid 
argument:crypto/bio/b_sock2.c:255:
0:error:2008B088:BIO routines:BIO_listen:listen v6 
only:crypto/bio/b_sock2.c:256:
Doing handshakes=1 bytes=256
TLSv1.3, cipher (NONE) (NONE)
../../util/shlib_wrap.sh ../ssltest_old -s_key keyU.ss -s_cert certU.ss -c_key 
keyU.ss -c_cert certU.ss -ipv6 => 1
 not ok 13 - test TLS via IPv6
 #   Failed test 'test TLS via IPv6'
 #   at ../test/recipes/80-test_ssl_old.t line 390.
 # Looks like you failed 1 test of 13.
not ok 2 - standard SSL tests
#   Failed test 'standard SSL tests'
#   at /home/ca/pd/security/openssl-1.1.1g/test/../util/perl/OpenSSL/Test.pm 
line 1212.

...

# Looks like you failed 1 test of 6.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/6 subtests

Test Summary Report
---
../test/recipes/80-test_ssl_old.t (Wstat: 256 Tests: 6 Failed: 1)
   Failed test:  2
   Non-zero exit status: 1
Files=1, Tests=6, 12 wallclock secs ( 0.04 usr  0.06 sys +  1.77 cusr  9.78 
csys = 11.65 CPU)
Result: FAIL
*** Error 1 in . (Makefile:217 '_tests')
*** Error 1 in /home/ca/pd/security/openssl-1.1.1g (Makefile:205 'tests')



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Soborg, 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

Re: OpenSSL Security Advisory

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 12:46:43PM -0700, Sam Roberts wrote:
> The announcement claims that this affects SSL_check_chain().
> 
> Is that an exhaustive list? If an application does NOT call that
> function, does this mean the vulnerability is not exploitable?

That is correct (speaking only in terms of public APIs).

> I ask because the the fixed function tls1_check_sig_alg is called by
> tls1_check_chain, and that is called directly by SSL_check_chain, but
> it is also called by tls1_set_cert_validity, and that is called from
> inside the tls state machine, but with different parameters, so its a
> bit hard to see if it is affected or not.

As you note, the valid call chains are a bit convoluted, but the relevant
codepath is only exercised for TLS 1.3 and SSL_check_chain().

-Ben

Re: OpenSSL Security Advisory

[Sam Roberts]

The announcement claims that this affects SSL_check_chain().

Is that an exhaustive list? If an application does NOT call that
function, does this mean the vulnerability is not exploitable?

I ask because the the fixed function tls1_check_sig_alg is called by
tls1_check_chain, and that is called directly by SSL_check_chain, but
it is also called by tls1_set_cert_validity, and that is called from
inside the tls state machine, but with different parameters, so its a
bit hard to see if it is affected or not.

Thanks,
Sam

On Tue, Apr 21, 2020 at 6:26 AM OpenSSL  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> OpenSSL Security Advisory [21 April 2020]
> =
>
> Segmentation fault in SSL_check_chain (CVE-2020-1967)
> =
>
> Severity: High
>
> Server or client applications that call the SSL_check_chain() function during 
> or
> after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a
> result of incorrect handling of the "signature_algorithms_cert" TLS extension.
> The crash occurs if an invalid or unrecognised signature algorithm is received
> from the peer. This could be exploited by a malicious peer in a Denial of
> Service attack.
>
> OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue.  This
> issue did not affect OpenSSL versions prior to 1.1.1d.
>
> Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g
>
> This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April
> 2020. It was found using the new static analysis pass being implemented in 
> GCC,
> - -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin
> Kaduk.
>
> Note
> =
>
> This issue did not affect OpenSSL 1.0.2 however these versions are out of
> support and no longer receiving public updates. Extended support is available
> for premium support customers: https://www.openssl.org/support/contracts.html
>
> This issue did not affect OpenSSL 1.1.0 however these versions are out of
> support and no longer receiving updates.
>
> Users of these versions should upgrade to OpenSSL 1.1.1.
>
> References
> ==
>
> URL for this Security Advisory:
> https://www.openssl.org/news/secadv/20200421.txt
>
> Note: the online version of the advisory may be updated with additional 
> details
> over time.
>
> For details of OpenSSL severity classifications please see:
> https://www.openssl.org/policies/secpolicy.html
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e8uwACgkQ2cTSbQ5g
> RJHHRgf+J8iVBuK6EoOvf9xm9geiDgYVFse9ckMXH92gdGbwsW4uhTNk9fCyNC+t
> vsf6YGT6nKJarB5+N+LC4QB7VLo/DjlYcN9zP3mubV0eEyKHSoW6tDOWPpJ0gsbt
> 2Z9iTA4GnofvhBcWLiPGgv4IUHknsOaPkRmEppSF0fDTSKuYOerfNRh9jTKHulis
> Ph6dCOXE3kb5HfMwVj3UN2sP92XTig4FzpIQaZ1/2jKZaRXtzJD7pvu1fDCTkUGl
> aeta5jHNypYyRKJLuJ1+1DiBtbWTFAWMUCHlkg/kgdU4hIl/lo3vgAyFs/9mQxZQ
> vj2rIjoJHRj0EXqXhHoABqBHedilJQ==
> =AXyP
> -END PGP SIGNATURE-

Re: TLSv1 on CentOS-8

[Jakob Bohm via openssl-users]

That link shows whatever anyone's browser is configured to handle when 
clicking

the link.

The important thing is which browsers you need to support, like the ones on
https://www.ssllabs.com/ssltest/clients.html

Beware that the list I just linked is woefully incomplete for those of 
us who

actively target "any browser" support, especially when including old stuff
like Windows Mobile 5 and Windows XP.

On 21/04/2020 17:06, Junaid Mukhtar wrote:

Hi Tomas/Team

I have managed to block the RC4 and enable tlsv1 as per our requirements.

We have a requirement to match cipher list on the internal server to 
match the native browser cipher list as shown by the 
https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html


I have tried setting up different combinations on the CipherString but 
none helped. Do you have any suggestions as to how to do achieve this?



On Fri, Apr 17, 2020 at 6:22 PM Tomas Mraz > wrote:


On Fri, 2020-04-17 at 13:03 -0400, Viktor Dukhovni wrote:
> On Fri, Apr 17, 2020 at 05:17:47PM +0200, Tomas Mraz wrote:
>
> > Or you could modify the /etc/pki/tls/openssl.cnf:
> > Find the .include /etc/crypto-policies/back-ends/opensslcnf.config
> > line in it and insert something like:
> >
> > CipherString =
> >
@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!DES:!RC2:!RC4:
> > !IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
>
> How did this particular contraption become a recommended cipherlist?

To explain - this is basically autogenerated value from the crypto
policy definiton of the LEGACY crypto policy with just added the
!RC4.


> What's wrong with "DEFAULT"?  In OpenSSL 1.1.1 it already excludes
> RC4 (if RC4 is at all enabled at compile time):

Nothing wrong with DEFAULT. For manual configuration. This is however
something that is autogenerated.

>     $ openssl ciphers -v 'COMPLEMENTOFDEFAULT+RC4'
>     ECDHE-ECDSA-RC4-SHA     TLSv1 Kx=ECDH     Au=ECDSA Enc=RC4(128)
> Mac=SHA1
>     ECDHE-RSA-RC4-SHA       TLSv1
> Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
>     RC4-SHA                 SSLv3
> Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
>
> I find too many people cargo-culting poorly thought cipher lists
from
> some random HOWTO.  Over optimising your cipherlist is subject to
> rapid bitrot, resist the temptation...

Yeah, I should have probably suggested just: CipherString = DEFAULT

There is not much point in being as close to the autogenerated policy
as possible for this particular user's use-case.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Soborg, 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

Re: empty directory in the 1.1.1 series release tags

[Richard Levitte]

On Tue, 21 Apr 2020 19:55:41 +0200,
Quanah Gibson-Mount wrote:
> --On Tuesday, April 21, 2020 11:25 AM -0700 Norm Green
>  wrote:
> 
> >  >I use the git release tags, not the tarballs.
> > 
> > I do too, and I suspect many others do as well.
> > The empty krb5 directory has not caused grief for me, but it would be
> > nice if the git release tag directory structure matched the tarball.
> 
> I ended up doing a git rm on the krb5 dir, and then the rest of the
> tags all went in fine (I was last on 1.1.1d).  But I agree, overall I
> would expect the release tags to match the release tarballs.

To be a bit blunt, that's simply not reasonable.  There are a number
of files and directories, not the least diverse git related files,
that are never going to make it into the tarball.

Have a look at .gitattributes, you have a number of patterns there
with the attribute 'export-ignore'.  Those are files that don't make
it into the tarball.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: empty directory in the 1.1.1 series release tags

[Quanah Gibson-Mount]

--On Tuesday, April 21, 2020 11:25 AM -0700 Norm Green 
 wrote:



 >I use the git release tags, not the tarballs.

I do too, and I suspect many others do as well.
The empty krb5 directory has not caused grief for me, but it would be
nice if the git release tag directory structure matched the tarball.


I ended up doing a git rm on the krb5 dir, and then the rest of the tags 
all went in fine (I was last on 1.1.1d).  But I agree, overall I would 
expect the release tags to match the release tarballs.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: questions on using ed25519

[Viktor Dukhovni]

On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote:

> I want to use ed25519 in openssl.

Why?  What actual real-world purpose do you have for ed25519?

> The problem I met is: I can use "speed ed25519" to test the speed of
> ed25519, but when I use "dgst -ed25519", it tells me that "dgst:
> Unrecognized flag Ed25519".

That's because "ed25519" is not a digest algorithm, it is a public key
algorithm.  You can use it to sign messages, but not to compute message
digests.

> So could you please help me to learn how to use ed25519 correctly?

That question has no answer.  Whether a use of "ed25519" is correct or
incorrect depends on the security protocol in which it is to be used,
and whether that protocol is appropriate to security requirements of
the application using it.

If you're just playing with ed25519, you can generate ed25519 keys with:

$ openssl genpkey -algorithm ed25519 -out privkey.pem

You can extract just the public key via:

$ openssl pkey -in privkey.pem -pubout -out pubkey.pem

You can generate an ed25519 self-signed public key certificate with:

$ openssl req -key privkey.pem -new \
-x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem

You can use the key and certificate with s_client, and s_server
via the "-key" and "-cert" arguments.

You can also sign and/or encrypt messages with ed25519 using cms(1),
but you may not be ready to dive into cms.

Low-level public and private key operations are possible via pkeyutl(1).

While the dgst(1) command supports signing message digests with various
public key signature algorithms, ed25519 is not one of these:

   -sign filename
   Digitally sign the digest using the private key in "filename". Note
   this option does not support Ed25519 or Ed448 private keys. Use the
   pkeyutl command instead for this.

See the pkeyutl(1) manpage.

Don't assume that some use of encryption implies any gain in security.
It could be mere security theatre.  For actual security you need to
apply a robust protocol that matches the application's security
requirements.

-- 
Viktor.

Re: opensssl 1.1.1g test failure(s)

[Claus Assmann]

On Tue, Apr 21, 2020, Benjamin Kaduk via openssl-users wrote:
> On Tue, Apr 21, 2020 at 07:22:38PM +0200, Claus Assmann wrote:

> > ../test/recipes/80-test_ssl_old.t .. 
> > Dubious, test returned 1 (wstat 256, 0x100)

> Please run again with `make V=1 TESTS=test_ssl_old test` and post the 
> relevant parts of the output?

Thanks for the reply, below is the output, It seems it only fails
because the host doesn't support IPv6?

make depend && make _tests
( cd test;  mkdir -p test-runs;  SRCTOP=../.  BLDTOP=../.  RESULT_D=test-runs  
PERL="/usr/bin/perl"  EXE_EXT=  OPENSSL_ENGINES=`cd .././engines 2>/dev/null && 
pwd`  OPENSSL_DEBUG_MEMORY=on  /usr/bin/perl .././test/run_tests.pl 
test_ssl_old )
../test/recipes/80-test_ssl_old.t .. 
1..6
# Subtest: test_ss
1..17
Generating a RSA private key
..+
..+
writing new private key to 'keyCA.ss'
-
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Dodgy CA
../../util/shlib_wrap.sh ../../apps/openssl req -config ../CAss.cnf -out 
reqCA.ss -keyout keyCA.ss -new => 0
ok 1 - make cert request
Signature ok
subject=C = AU, O = Dodgy Brothers, CN = Dodgy CA
Getting Private key
../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -CAcreateserial -in 
reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile ../CAss.cnf 
-extensions v3_ca > err.ss => 0
ok 2 - convert request into self-signed cert
Getting request Private Key
Generating certificate request
../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -in certCA.ss -x509toreq 
-signkey keyCA.ss -out req2CA.ss > err.ss => 0
ok 3 - convert cert into a cert request
verify OK
../../util/shlib_wrap.sh ../../apps/openssl req -config ../../apps/openssl.cnf 
-verify -in reqCA.ss -noout => 0
ok 4 - verify request 1
verify OK
../../util/shlib_wrap.sh ../../apps/openssl req -config ../../apps/openssl.cnf 
-verify -in req2CA.ss -noout => 0
ok 5 - verify request 2
certCA.ss: OK
../../util/shlib_wrap.sh ../../apps/openssl verify -CAfile certCA.ss certCA.ss 
=> 0
ok 6 - verify signature
Generating a RSA private key
.+
.+
writing new private key to 'keyU.ss'
-
../../util/shlib_wrap.sh ../../apps/openssl req -config ../Uss.cnf -out reqU.ss 
-keyout keyU.ss -new > err.ss => 0
ok 7 - make a user cert request
Signature ok
subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2
Getting CA Private Key
../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -CAcreateserial -in 
reqU.ss -days 30 -req -out certU.ss -CA certCA.ss -CAkey keyCA.ss -CAserial 
certCA.srl -extfile ../Uss.cnf -extensions v3_ee > err.ss => 0
certU.ss: OK
../../util/shlib_wrap.sh ../../apps/openssl verify -CAfile certCA.ss certU.ss 
=> 0
ok 8 - sign user cert request
# subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2
# issuer=C = AU, O = Dodgy Brothers, CN = Dodgy CA
# notBefore=Apr 21 17:30:29 2020 GMT
# notAfter=May 21 17:30:29 2020 GMT
../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -subject -issuer 
-startdate -enddate -noout -in certU.ss => 0
ok 9 - Certificate details
# Subtest: DSA certificate creation
1..5
Generating DSA key, 1024 bits
../../util/shlib_wrap.sh ../../apps/openssl gendsa -out keyD.ss 
../../apps/dsa1024.pem > err.ss => 0
ok 1 - make a DSA key
../../util/shlib_wrap.sh ../../apps/openssl req -new -config ../Uss.cnf -out 
reqD.ss -key keyD.ss > err.ss => 0
ok 2 - make a DSA user cert request
Signature ok
subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = DSA Certificate
Getting CA Private Key
../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -CAcreateserial -in 
reqD.ss -days 30 -req -out certD.ss -CA certCA.ss -CAkey keyCA.ss -CAserial 
certCA.srl -extfile ../Uss.cnf -extensions v3_ee_dsa > err.ss => 0
ok 3 - sign DSA user cert request
certD.ss: OK
../../util/shlib_wrap.sh ../../apps/openssl verify -CAfile certCA.ss certD.ss 
=> 0
ok 4 - verify DSA user cert
# subject=C = AU, O = Dodgy Brothers, CN = Brother 1, CN = DSA Certificate
# issuer=C = AU, O = Dodgy Brothers, CN = Dodgy CA
# notBefore=Apr 21 17:30:29 2020 GMT
# notAfter=May 21 17:30:29 2020 GMT
../../util/shlib_wrap.sh ../../apps/openssl x509 -sha1 -subject -issuer 
-startdate -enddate -noout -in certD.ss => 0
ok 5 - DSA Certificate details
ok 10 - DSA certificate creation
# Subtest: ECDSA/ECDH certificate creation
1..5
../../util/shlib_wrap.sh ../../apps/openssl 

Re: opensssl 1.1.1g test failure(s)

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 07:22:38PM +0200, Claus Assmann wrote:
> Note sure whether this is already known (a search didn't bring up
> anything meaningful):
> 
> ../test/recipes/80-test_ssl_old.t .. 
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/6 subtests 
> Test Summary Report
> ---
> ../test/recipes/80-test_ssl_old.t(Wstat: 256 Tests: 6 Failed: 
> 1)

^
this is the number of failed tests

>   Failed test:  2
> ^ Is that supposed to be the number of failed tests?

No, that's the index of the failing test(s).  (I always have to check whether
it's 0-indexed or 1-indexed, though.)

>   If so, I don't see the 2nd test failure
>   (and it should probably  be "Failed test(s):"?)
> 
> Files=155, Tests=1256, 298 wallclock secs ( 0.32 usr  2.07 sys + 126.58 cusr 
> 156.65 csys = 285.62 CPU)
> Result: FAIL

Please run again with `make V=1 TESTS=test_ssl_old test` and post the relevant 
parts of the output?

Thanks,

Ben

Re: empty directory in the 1.1.1 series release tags

[Norm Green]

>I use the git release tags, not the tarballs.

I do too, and I suspect many others do as well.
The empty krb5 directory has not caused grief for me, but it would be 
nice if the git release tag directory structure matched the tarball.


Norm Green

On 4/21/2020 10:19 AM, Quanah Gibson-Mount wrote:
--On Tuesday, April 21, 2020 11:16 AM -0700 Benjamin Kaduk 
 wrote:



The 'krb5' entry in git is a submodule, used for the external tests.
It's removed while preparing release tarballs, but I'm not sure what
you are doing that's causing conflicts -- are you doing something that
involves both tarballs and git?


I use the git release tags, not the tarballs.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: empty directory in the 1.1.1 series release tags

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 10:19:28AM -0700, Quanah Gibson-Mount wrote:
> --On Tuesday, April 21, 2020 11:16 AM -0700 Benjamin Kaduk
>  wrote:
> 
> > The 'krb5' entry in git is a submodule, used for the external tests.
> > It's removed while preparing release tarballs, but I'm not sure what
> > you are doing that's causing conflicts -- are you doing something that
> > involves both tarballs and git?
> 
> I use the git release tags, not the tarballs.

Can't you just leave the empty directory in your local branch and not
have a conflict, then?

-Ben

opensssl 1.1.1g test failure(s)

[Claus Assmann]

Note sure whether this is already known (a search didn't bring up
anything meaningful):

../test/recipes/80-test_ssl_old.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/6 subtests 
Test Summary Report
---
../test/recipes/80-test_ssl_old.t(Wstat: 256 Tests: 6 Failed: 1)
  Failed test:  2
^ Is that supposed to be the number of failed tests?
  If so, I don't see the 2nd test failure
  (and it should probably  be "Failed test(s):"?)

Files=155, Tests=1256, 298 wallclock secs ( 0.32 usr  2.07 sys + 126.58 cusr 
156.65 csys = 285.62 CPU)
Result: FAIL

OS Version:
OpenBSD 6.5 amd64

Re: empty directory in the 1.1.1 series release tags

[Quanah Gibson-Mount]

--On Tuesday, April 21, 2020 11:16 AM -0700 Benjamin Kaduk 
 wrote:



The 'krb5' entry in git is a submodule, used for the external tests.
It's removed while preparing release tarballs, but I'm not sure what
you are doing that's causing conflicts -- are you doing something that
involves both tarballs and git?


I use the git release tags, not the tarballs.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: empty directory in the 1.1.1 series release tags

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 10:08:39AM -0700, Quanah Gibson-Mount wrote:
> The OpenSSL release tags contain an empty directory "krb5" that does not
> exist in the release tarball.  This is annoying because when I go to merge
> release tags, I constantly get the following:
> 
> CONFLICT (modify/delete): krb5 deleted in HEAD and modified in
> OpenSSL_1_1_1e. Version OpenSSL_1_1_1e of krb5 left in tree.
> 
> Can this please be fixed?

The 'krb5' entry in git is a submodule, used for the external tests.
It's removed while preparing release tarballs, but I'm not sure what
you are doing that's causing conflicts -- are you doing something that
involves both tarballs and git?

-Ben

empty directory in the 1.1.1 series release tags

[Quanah Gibson-Mount]

The OpenSSL release tags contain an empty directory "krb5" that does not 
exist in the release tarball.  This is annoying because when I go to merge 
release tags, I constantly get the following:


CONFLICT (modify/delete): krb5 deleted in HEAD and modified in 
OpenSSL_1_1_1e. Version OpenSSL_1_1_1e of krb5 left in tree.


Can this please be fixed?

Thanks!

--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: secure_getenv

[Michael Mueller]

IGNORE

cockpit error

I failed to compile openssl on the lowest revision release that we
support.  The error occurred when I tried to build our app on the low
rev system with openssl 1.1.1g that was built on a higher revision
linux system.

TIL secure_getenv()

On Tue, Apr 21, 2020 at 11:18 AM Michael Mueller  wrote:
>
> anybody else compiling apps against openssl 1.1.1g in Linux and
> getting link errors for secure_getenv?
>
> ../../../../OPENSSL/bin/SUSE-Linux/libcrypto.a(getenv.o): In function
> `ossl_safe_getenv': getenv.c:(.text+0x1): undefined reference to
> `secure_getenv
>
> secure_getenv() is a GNU extension
>
> Mike

secure_getenv

[Michael Mueller]

anybody else compiling apps against openssl 1.1.1g in Linux and
getting link errors for secure_getenv?

../../../../OPENSSL/bin/SUSE-Linux/libcrypto.a(getenv.o): In function
`ossl_safe_getenv': getenv.c:(.text+0x1): undefined reference to
`secure_getenv

secure_getenv() is a GNU extension

Mike

Re: TLSv1 on CentOS-8

[Junaid Mukhtar]

Hi Tomas/Team

I have managed to block the RC4 and enable tlsv1 as per our requirements.

We have a requirement to match cipher list on the internal server to match
the native browser cipher list as shown by the
https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html

I have tried setting up different combinations on the CipherString but none
helped. Do you have any suggestions as to how to do achieve this?


Regards,
Junaid


On Fri, Apr 17, 2020 at 6:22 PM Tomas Mraz  wrote:

> On Fri, 2020-04-17 at 13:03 -0400, Viktor Dukhovni wrote:
> > On Fri, Apr 17, 2020 at 05:17:47PM +0200, Tomas Mraz wrote:
> >
> > > Or you could modify the /etc/pki/tls/openssl.cnf:
> > > Find the .include /etc/crypto-policies/back-ends/opensslcnf.config
> > > line in it and insert something like:
> > >
> > > CipherString =
> > > @SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!DES:!RC2:!RC4:
> > > !IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
> >
> > How did this particular contraption become a recommended cipherlist?
>
> To explain - this is basically autogenerated value from the crypto
> policy definiton of the LEGACY crypto policy with just added the !RC4.
>
>
> > What's wrong with "DEFAULT"?  In OpenSSL 1.1.1 it already excludes
> > RC4 (if RC4 is at all enabled at compile time):
>
> Nothing wrong with DEFAULT. For manual configuration. This is however
> something that is autogenerated.
>
> > $ openssl ciphers -v 'COMPLEMENTOFDEFAULT+RC4'
> > ECDHE-ECDSA-RC4-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=RC4(128)
> > Mac=SHA1
> > ECDHE-RSA-RC4-SHA   TLSv1
> > Kx=ECDH Au=RSA  Enc=RC4(128)  Mac=SHA1
> > RC4-SHA SSLv3
> > Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1
> >
> > I find too many people cargo-culting poorly thought cipher lists from
> > some random HOWTO.  Over optimising your cipherlist is subject to
> > rapid bitrot, resist the temptation...
>
> Yeah, I should have probably suggested just: CipherString = DEFAULT
>
> There is not much point in being as close to the autogenerated policy
> as possible for this particular user's use-case.
>
> --
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]
>
>
>

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [21 April 2020]
=

Segmentation fault in SSL_check_chain (CVE-2020-1967)
=

Severity: High

Server or client applications that call the SSL_check_chain() function during or
after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a
result of incorrect handling of the "signature_algorithms_cert" TLS extension.
The crash occurs if an invalid or unrecognised signature algorithm is received
from the peer. This could be exploited by a malicious peer in a Denial of
Service attack.

OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue.  This
issue did not affect OpenSSL versions prior to 1.1.1d.

Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g

This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April
2020. It was found using the new static analysis pass being implemented in GCC,
- -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin
Kaduk.

Note
=

This issue did not affect OpenSSL 1.0.2 however these versions are out of
support and no longer receiving public updates. Extended support is available
for premium support customers: https://www.openssl.org/support/contracts.html

This issue did not affect OpenSSL 1.1.0 however these versions are out of
support and no longer receiving updates.

Users of these versions should upgrade to OpenSSL 1.1.1.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20200421.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e8uwACgkQ2cTSbQ5g
RJHHRgf+J8iVBuK6EoOvf9xm9geiDgYVFse9ckMXH92gdGbwsW4uhTNk9fCyNC+t
vsf6YGT6nKJarB5+N+LC4QB7VLo/DjlYcN9zP3mubV0eEyKHSoW6tDOWPpJ0gsbt
2Z9iTA4GnofvhBcWLiPGgv4IUHknsOaPkRmEppSF0fDTSKuYOerfNRh9jTKHulis
Ph6dCOXE3kb5HfMwVj3UN2sP92XTig4FzpIQaZ1/2jKZaRXtzJD7pvu1fDCTkUGl
aeta5jHNypYyRKJLuJ1+1DiBtbWTFAWMUCHlkg/kgdU4hIl/lo3vgAyFs/9mQxZQ
vj2rIjoJHRj0EXqXhHoABqBHedilJQ==
=AXyP
-END PGP SIGNATURE-

OpenSSL version 1.1.1g published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 1.1.1g released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1g of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.1.1-notes.html

   OpenSSL 1.1.1g is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.1g.tar.gz
  Size: 9801502
  SHA1 checksum: b213a293f2127ec3e323fb3cfc0c9807664fd997
  SHA256 checksum: 
ddb04774f1e32f0c49751e21b67216ac87852ceb056b75209af2443400636d46

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1g.tar.gz
openssl sha256 openssl-1.1.1g.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e5ZUACgkQ2cTSbQ5g
RJFGnQf8D8U0193cmqitZZ4L63ncx8aWPMdXMookxywTnhCHm7qyNGa0a41J0iZw
pRebjlrjo1rEOMFo9rNmvtoBBUs/cFD8ARsItK3Kh2ms0z4MJV4F07XJHwNkd0Wf
n18+oUS6Fj7Z8TgdA+UwBFuN248kqELDp8DYntLCzyEvkweU80JIRWhC+XawjcbA
W/zlD6oVfNsgYP38hSCQg14B+/djMTVYqtDSOBm3B+J7zRndYoTvsankWlsMmDD5
Tb6lOQ8IBEsgnlriOH936eKhlJ5UeTr2hPONnzDJ/cIUWn1RwX9yPGOoaf74IoHc
Hg/T6vP+pD3G3mDOS51Qm87A5+nDaQ==
=eNCz
-END PGP SIGNATURE-

CMS in openssl

[Michael Mueller]

Greetings esteemed openssl users,

We've implemented what I gather can be called a CMS on Linux and Windows
using openssl evp functions.

We need to expand this CMS to other systems, on which we have not been able
to build openssl. These other systems have a vendor supplied security
application. This application supports PKCS7.

We are being asked if our evp CMS is interoperable with PKCS7.

If it is possible and more information is required to answer this question,
I'll provide such information.

If not, advice on how to present that argument to management would be
appreciated.

Thank you for your assistance
Mike

RE: building a PIC enabled version of openssl 1.0.2k on Sparc 10

[tim.j.culhane]

Hi,

Just to say that you can get the -Fpic flag  by using the  'shared' argument
to  the Configure script.   The following works for me:

./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.1.1
--openssldir=/opt/openssl/1.1.1 -lrt -m64 shared zlib

Regards,

Tim


-Original Message-
From: openssl-users  On Behalf Of Michael
Wojcik
Sent: Thursday 16 April 2020 18:16
To: openssl-users@openssl.org
Subject: RE: building a PIC enabled version of openssl 1.0.2k on Sparc 10

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
> Behalf Of tim.j.culh...@gmail.com
> Sent: Thursday, April 16, 2020 08:36
>
> I'm building a PIC enabled shared library in my server which links 
> against openssl 1.0.2k libssl.a library on Sparc 10.
>
> When compiling  I see the below errors.
>
> I  originally built  the 1.0.2k version of openssl with the following 
> configure  arguments:
>
> ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.0.2k 
> --openssldir=/opt/openssl/1.0.2k -lrt -m64
>
> Do I need to  pass in  the  -fPIC flag as well, and if so  how do I do
that.

I believe you do, though our use case is different - we build OpenSSL as a
PIC archive library, which we then linked into a shared object. If you're
building OpenSSL as a shared object (well, a pair of shared objects, for
libcrypto and libssl), then you may be able to do that with the appropriate
Configure options.

My teams have switched to 1.1.1, so I don't have a 1.0.2 build handy to
check.

> I appended it to the end of the  configure  line I  show above  but 
> there was no sign of PIC in any of the top level makefiles produced.

For 1.0.2, we edited the Configure file. We kept a log of the purposes of
our changes, and looked at the Configure diffs for each new 1.0.2 release so
we could port the relevant changes back to our Configure.

We haven't had to do that with 1.1.1; its Configure is more flexible.

--

Michael Wojcik
Distinguished Engineer, Micro Focus

questions on using ed25519

[yang berlin]

Hello, I am a beginner on openssl, and I want to use the ed25519 in openssl.

The problem I met is: I can use "speed ed25519" to test the speed of
ed25519, but when I use "dgst -ed25519", it tells me that "dgst:
Unrecognized flag Ed25519". So could you please help me to learn how to use
ed25519 correctly?