Re: How to upgrade openssl from 3.0.2 to 3.0.7
On 11/2/22 23:08, Anupam Dutta via openssl-users wrote: I want to upgrade the openssl version from 3.0.2 to 3.0.7. My OS version is Ubuntu 22.04.1 LTS (Jammy Jellyfish). Please help .It is urgent Ubuntu has already dealt with the new vulnerabilities. If you do the normal package upgrade procedure that you should already be doing frequently, that will fix the vulnerability in version 3.0.2-0ubuntu1.7. https://ubuntu.com/security/notices/USN-5710-1 If you want to see what version your Ubuntu machine has (or any distro that derives from Debian), do this command (as any user, sudo is not required): dpkg -l | grep libssl These commands should pick up that openssl fix as well as any other updates: sudo apt -y update sudo apt -y upgrade Thanks, Shawn
RE: SSL_read empty -> close?
> From: Felipe Gasper
> Sent: Thursday, 3 November, 2022 10:43
> >
> > And your description looks wrong anyway: shutdown(SHUT_RD) has
> > implementation-defined behavior for TCP sockets (because TCP does not
> > announce the read side of half-close to the peer), and on Linux causes
> > blocked receives and subsequent receives to return 0 (according to
> > references
>
> perl -MSocket -MIO::Socket::INET -e'my $s = IO::Socket::INET->new( Server =>
> 1, Listen => 1 ) or die; my $port = $s->sockport(); my $c = IO::Socket::INET-
> >new("localhost:$port") or die; syswrite $c, "hello"; my $sc = $s->accept();
> shutdown($sc, SHUT_RD); sysread $sc, my $buf, 512 or die $!; print $buf'
>
> ^^ The above, I believe, demonstrates to the contrary: the read buffer is
> populated prior to shutdown and drained afterward.
As I noted, I hadn't tested it. The Linux man page is ambiguous:
If how is SHUT_RD, further receptions will be disallowed.
It doesn't define "receptions". It's entirely possible that SHUT_RD will cause
the stack to reject further application data (i.e. packets that increment the
sequence number for anything other than ACK) from the peer, but permit the
socket owner to continue to receive already-buffered data. That's arguably a
poor implementation, and not what the man page appears to imply. And it looks
to be in conflict with the Single UNIX Specification Issue 7 (not that Linux
claims to be UNIX-conformant), which states that SHUT_SD "Disables further
receive operations"; "operations" certainly seems to refer to actions taken by
the caller, not by the peer.
There is a fair bit of debate about this online, and a number of people opine
that the Linux behavior is correct, and SUS (they often refer to "POSIX", but
POSIX has been superseded by SUS) is wrong. Others disagree.
The Linux kernel does take some action for a TCP socket that has SHUT_RD
requested for it, but the behavior is not simple. (One SO comment mentions it
causes it to exit the read loop in tcp_splice_read(), for example.) I'd be
leery about relying on it.
I'm not sure how shutdown(SHUT_RD) is useful in the case of a TCP socket being
used for TLS, to be perfectly honest. If the application protocol delimits
messages properly and is half-duplex (request/response), then one side should
know that no more data is expected and the other can detect incomplete
messages, so there's likely no issue. If not, there's no way to guarantee you
haven't encountered an incomplete message in bounded time (FPL Theorem
applies). SHUT_RD does not signal the peer, so the peer can still get a RST if
it continues to send. Perhaps I'm missing something, but I don't see what
failure mode is being avoided by using SHUT_RD.
--
Michael Wojcik
Re: SSL_read empty -> close?
> On Nov 3, 2022, at 11:37, Michael Wojcik via openssl-users
> wrote:
>
>> It’s a rare
>> issue, but when it does it’s a head-scratcher. To avoid that, it’s necessary
>> to shutdown(SHUT_RD) then drain the read buffer before close().
>
> Well, it's not *necessary* to do a half-close. Applications often know when
> they've received all the data the peer intends to send, thanks to
> record-delimiting mechanisms in the application protocol.
>
> And your description looks wrong anyway: shutdown(SHUT_RD) has
> implementation-defined behavior for TCP sockets (because TCP does not
> announce the read side of half-close to the peer), and on Linux causes
> blocked receives and subsequent receives to return 0 (according to references
> -- I have't tested it), which means after shutdown(SHUT_RD) you *can't* drain
> the receive buffer. shutdown(SHUT_WR) would work, since it sends a FIN,
> telling the peer you won't be sending any more data, and still allows you to
> receive.
perl -MSocket -MIO::Socket::INET -e'my $s = IO::Socket::INET->new( Server => 1,
Listen => 1 ) or die; my $port = $s->sockport(); my $c =
IO::Socket::INET->new("localhost:$port") or die; syswrite $c, "hello"; my $sc =
$s->accept(); shutdown($sc, SHUT_RD); sysread $sc, my $buf, 512 or die $!;
print $buf'
^^ The above, I believe, demonstrates to the contrary: the read buffer is
populated prior to shutdown and drained afterward.
>> I would guess that many don’t and just don’t see the
>> RST thing frequently enough to worry about it. Regardless, the documentation
>> is already pretty voluminous, so if this doesn’t bite many folks, then hey.
>
> Yes, but wiki articles are always appreciated.
I’ll see if I can whip something up.
-FG
RSA padding scheme for EVP_SealInit() ?
Hi In OpenSSL 3.x, what RSA padding scheme does EVP_SealInit() use? PKCS1 or OAEP ? In 1.1, I wrote my own version of this code that forced the padding to be OAEP and am wondering if I still need that in 3.x. Norm Green
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
Michael Wojcik via openssl-users writes: > I'm inclined to agree. While there's an argument for backward > compatibility, C99 was standardized nearly a quarter of a century > ago. OpenSSL 1.x is younger than C99. It doesn't seem like an > unreasonable requirement. That and there is no substitute for it.
RE: SSL_read empty -> close?
> From: Felipe Gasper > Sent: Thursday, 3 November, 2022 08:51 > > You probably know this, but: On Linux, at least, if a TCP socket close()s > with a non-empty read buffer, the kernel sends TCP RST to the peer. Yes, that's a conditional-compliance (SHOULD) requirement from the Host Requirements RFC. See RFC 1122, 4.2.2.13. > Some > applications “panic” when they receive the RST and discard data. Well, applications do a lot of things. Receiving an RST informs the peer that some of the data they sent was not successfully processed by the local application, so treating that as an error condition is not inappropriate. But generally it's better if the application protocol imposes its own record structure and control information on top of TCP's very basic stream. > It’s a rare > issue, but when it does it’s a head-scratcher. To avoid that, it’s necessary > to shutdown(SHUT_RD) then drain the read buffer before close(). Well, it's not *necessary* to do a half-close. Applications often know when they've received all the data the peer intends to send, thanks to record-delimiting mechanisms in the application protocol. And your description looks wrong anyway: shutdown(SHUT_RD) has implementation-defined behavior for TCP sockets (because TCP does not announce the read side of half-close to the peer), and on Linux causes blocked receives and subsequent receives to return 0 (according to references -- I have't tested it), which means after shutdown(SHUT_RD) you *can't* drain the receive buffer. shutdown(SHUT_WR) would work, since it sends a FIN, telling the peer you won't be sending any more data, and still allows you to receive. > So it seems like this *shouldn’t* be obscure, if applications do the > shutdown/drain thing. It's obscure in the sense that a great many people trying to use TLS get much more basic things wrong. More generally, the OpenSSL documentation mostly covers the OpenSSL APIs, and leaves networking up to the OpenSSL consumer to figure out. The OpenSSL wiki covers topics that people have written, and those are going to focus on common questions and areas of particular interest for someone. If the interactions among the OpenSSL API, the TLS protocol (in its various versions), and the shutdown system call haven't historically been a problem for many people, then it's "obscure" in the literal sense of not having attracted much notice. And in practice, the majority of TLS use is with HTTP, and HTTP does a fairly good job of determining when more data is expected, and handling cases where it isn't. An HTTP client that receives a complete response and then attempts to use the conversation for its next request, and gets an RST on that, for example, will just open a new conversation; it doesn't care that the old one was terminated. HTTP servers are simliarly tolerant because interactive user agents in particular cancel requests by closing (or, unfortunately, aborting) the connection all the time. > I would guess that many don’t and just don’t see the > RST thing frequently enough to worry about it. Regardless, the documentation > is already pretty voluminous, so if this doesn’t bite many folks, then hey. Yes, but wiki articles are always appreciated. -- Michael Wojcik
Re: Output buffer length in EVP_EncryptUpdate for ECB mode
On 03/11/2022 14:21, Wiktor Kwapisiewicz via openssl-users wrote:
Hello,
I'd like to clarify one aspect of the API regarding EVP_EncryptUpdate
[0] that is the length of the output buffer that should be passed to
that function ("out" parameter). (Actually I'm using EVP_CipherUpdate
but the docs are more comprehensive for EVP_EncryptUpdate).
[0]: https://www.openssl.org/docs/manmaster/man3/EVP_EncryptUpdate.html
For the record I'm using AES-128 cipher in ECB mode and the docs say:
For most ciphers and modes, the amount of data written can be
anything from zero bytes to (inl + cipher_block_size - 1) bytes. For
wrap cipher modes, the amount of data written can be anything from
zero bytes to (inl + cipher_block_size) bytes. For stream ciphers,
the amount of data written can be anything from zero bytes to inl
bytes.
AES-128-ECB doesn't appear to be a stream cipher (since the "block size"
returns 16 not the magical value of 1) and I'm unable to find any
mentions of "wrap cipher modes" in search engines. Apparently ECB is a
block cipher mode.
Does that mean that "wrap cipher modes" == "block cipher modes"?
No.
The term "block cipher" is a feature of the underlying primitive - so
AES-128 is a block cipher. It encrypts in blocks of 16 bytes. ECB is a
particular mode for using a block cipher. "Wrap" modes are specialist
modes used for encrypting key material.
Is there any documentation I could read on the reasoning of why a space
for additional block is needed in this case ("(inl + cipher_block_size)
bytes")? I'm trying to understand the differences between OpenSSL and
other cryptographic backends in an OpenPGP library [1].
EVP_EncryptUpdate() can be called repeatedly, incrementally feeding in
the data to be encrypted. The ECB mode (when used with AES-128) will
encrypt input data 16 bytes at a time, and the output size will also be
16 bytes per input block. If the data that you feed in to
EVP_EncryptUpdate() is not a multiple of 16 bytes then the amount of
data that is over a multiple of 16 bytes will be cached until a
subsequent call where it does have 16 bytes.
Let's say you call EVP_EncryptUpdate() with 15 bytes of data. In that
case all 15 bytes will be cached and 0 bytes will be output.
If you then call it again with 17 bytes of data, then added to the 15
bytes already cached we have a total of 32 bytes. This is a multiple of
16, so 2 blocks (32 bytes) will be output, so:
(inl + cipher_block_size - 1) = (17 + 16 - 1) = 32
Matt
Thank you for your time and help!
Kind regards,
Wiktor
[1]:
https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361#note_1150958453
Re: SSL_read empty -> close?
> On Nov 3, 2022, at 10:17, Michael Wojcik via openssl-users > wrote: > >> Does OpenSSL’s documentation mention that? (I’m not exhaustively >> familiar with it, but I don’t remember having seen such.) > > I doubt it. I don't see anything on the wiki, and this is a pretty obscure > issue, all things considered. You probably know this, but: On Linux, at least, if a TCP socket close()s with a non-empty read buffer, the kernel sends TCP RST to the peer. Some applications “panic” when they receive the RST and discard data. It’s a rare issue, but when it does it’s a head-scratcher. To avoid that, it’s necessary to shutdown(SHUT_RD) then drain the read buffer before close(). So it seems like this *shouldn’t* be obscure, if applications do the shutdown/drain thing. I would guess that many don’t and just don’t see the RST thing frequently enough to worry about it. Regardless, the documentation is already pretty voluminous, so if this doesn’t bite many folks, then hey. Thank you! -F
Output buffer length in EVP_EncryptUpdate for ECB mode
Hello,
I'd like to clarify one aspect of the API regarding EVP_EncryptUpdate
[0] that is the length of the output buffer that should be passed to
that function ("out" parameter). (Actually I'm using EVP_CipherUpdate
but the docs are more comprehensive for EVP_EncryptUpdate).
[0]: https://www.openssl.org/docs/manmaster/man3/EVP_EncryptUpdate.html
For the record I'm using AES-128 cipher in ECB mode and the docs say:
For most ciphers and modes, the amount of data written can be
anything from zero bytes to (inl + cipher_block_size - 1) bytes. For
wrap cipher modes, the amount of data written can be anything from
zero bytes to (inl + cipher_block_size) bytes. For stream ciphers,
the amount of data written can be anything from zero bytes to inl
bytes.
AES-128-ECB doesn't appear to be a stream cipher (since the "block size"
returns 16 not the magical value of 1) and I'm unable to find any
mentions of "wrap cipher modes" in search engines. Apparently ECB is a
block cipher mode.
Does that mean that "wrap cipher modes" == "block cipher modes"?
Is there any documentation I could read on the reasoning of why a space
for additional block is needed in this case ("(inl + cipher_block_size)
bytes")? I'm trying to understand the differences between OpenSSL and
other cryptographic backends in an OpenPGP library [1].
Thank you for your time and help!
Kind regards,
Wiktor
[1]:
https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361#note_1150958453
RE: SSL_read empty -> close?
> From: Felipe Gasper > Sent: Thursday, 3 November, 2022 07:42 > > It sounds, then like shutdown() (i.e., TCP half-close) is a no-no during a > TLS session. Um, maybe. Might generally be OK in practice, particularly with TLSv1.3, which got rid of some of the less-well-considered ideas of earlier TLS versions. Honestly I'd have to spend some time digging through chapter & verse of the RFCs to arrive at any reliable opinion on the matter, though. Someone else here may have already considered it. > Does OpenSSL’s documentation mention that? (I’m not exhaustively > familiar with it, but I don’t remember having seen such.) I doubt it. I don't see anything on the wiki, and this is a pretty obscure issue, all things considered. > It almost seems like, given that TLS notify-close then TCP close() (i.e., > without awaiting the peer’s TLS notify-close) is legitimate, OpenSSL could > gainfully tolerate/hide the EPIPE that that close() likely produces, and have > SSL_read() et al just return empty-string. Well, it could, but OpenSSL generally doesn't try to provide that type of abstraction. Also note this paragraph from the wiki page on TLSv1.3 (https://wiki.openssl.org/index.php/TLS1.3): If a client sends it's [sic] data and directly sends the close notify request and closes the connection, the server will still try to send tickets if configured to do so. Since the connection is already closed by the client, this might result in a write error and receiving the SIGPIPE signal. The write error will be ignored if it's a session ticket. But server applications can still get SIGPIPE they didn't get before. So session tickets can also be a source of EPIPE when a client closes the connection. > It surprises me that notify-close then close() is considered legitimate use. There are so many TLS implementations and TLS-using applications out there that interoperability would be hugely compromised if we didn't allow a large helping of Postel's Interoperability Principle. So most applications try to be accommodating. There's even an OpenSSL flag to ignore the case where a peer closes without sending a close-notify, in case you run into one of those and want to suppress the error. -- Michael Wojcik
Re: SSL_read empty -> close?
> On Nov 2, 2022, at 16:36, Michael Wojcik via openssl-users > wrote: > >> From: Felipe Gasper >> Sent: Wednesday, 2 November, 2022 12:46 >> >> I wouldn’t normally expect EPIPE from a read operation. I get why it happens; >> it just seems odd. Given that it’s legitimate for a TLS peer to send the >> close_notify and then immediately do TCP close, it also seems like EPIPE is a >> “fact of life” here. > > Yeah. That's because an OpenSSL "read" operation can do sends under the > covers, and an OpenSSL "send" can do receives, in order to satisfy the > requirements of TLS. Depending on the TLS version and cipher suite being > used, it might need to do that for renegotiation or the like. Or if the > socket is non-blocking you can get WANT_READ from a send and WANT_WRITE from > a receive. > > In your example it was actually a sendmsg that produced the EPIPE, but within > the logical "read" operation. > > The original idea of SSL was "just be a duplex bytestream service for the > application", i.e. be socket-like; but that abstraction proved to be rather > leaky. Much as sockets themselves are a leaky abstraction once you try to do > anything non-trivial. It sounds, then like shutdown() (i.e., TCP half-close) is a no-no during a TLS session. Does OpenSSL’s documentation mention that? (I’m not exhaustively familiar with it, but I don’t remember having seen such.) It almost seems like, given that TLS notify-close then TCP close() (i.e., without awaiting the peer’s TLS notify-close) is legitimate, OpenSSL could gainfully tolerate/hide the EPIPE that that close() likely produces, and have SSL_read() et al just return empty-string. I don’t recall having seen it in 1.1 or earlier OpenSSLs. Then again, maybe some application wants to know it shouldn’t send a notify-close. It surprises me that notify-close then close() is considered legitimate use. WebSocket and SCTP both have similar shutdown workflows, but I think they expect the peers to await each other’s “farewell” message. -FG
RE: Worried about the vulnerabilities recently found in OpenSSL versions 3.0.0 - 3.0.6.
> From: openssl-users On Behalf Of > Steven_M.irc via openssl-users > Sent: Wednesday, 2 November, 2022 17:18 > > I'm really worried about the vulnerabilities recently found in OpenSSL > versions 3.0.0 - 3.0.6. Why? What's your threat model? > If I understand things correctly (and please do > correct me if I'm wrong), it doesn't matter which version of OpenSSL clients > are running, only which version of OpenSSL *servers* are running. Thus it > seems like end-users can do very little to protect themselves. Protect themselves from what? Take the most recent issues, CVE-2022-3786 and -3602. 3786 is a potential 4-byte buffer overflow when parsing an email address component of a distinguished name in a certificate. (Note, contrary to what you wrote above, this could affect both servers and clients, since it would be triggered by parsing a malformed certificate.) This is probably not exploitable, per the OpenSSL blog post and analyses performed elsewhere, but let's imagine the worst case: OpenSSL 3.0.6 running on some platform where it's possible to leverage this BOF into an RCE. If that's a server system, then: 1) If the server doesn't request client certificates, it should reject a Certificate message from the client, and not try to parse any, so there's no exposure. 2) We'll assume *you* aren't going to send a malicious certificate, so for your connection the vulnerability is irrelevant. 3) So the only case we care about is where some other actor sends a malicious certificate and chains the RCE with other attacks to pivot and escalate and subvert the server. We're on a pretty narrow branch of the attack tree here, and more importantly, the same could be true of a vast array of potential vulnerabilities in the server site. This is only an issue if an attacker can't find any other more useful vulnerability in the site. If you pay attention to IT security, you know *that* isn't likely. If it's a client system, then you only care if it's *your* client, and you visit a malicious site. If you're in the habit of using OpenSSL 3.0.6 to connect to malicious servers, well, 3786 is not likely to be high on your list of problems. 3602 is even less likely to be exploitable. Vulnerabilities are only meaningful in the context of a threat model. I don't see a plausible threat model where these should matter to a client-side end user. -- Michael Wojcik
OpenSSL 3.0.7 make test failed on AIX 7100-04
Hi team, I compile OpenSSL 3.0.5 and 3.0.7 on AIX 7100, make and make install succeed, but make test failed at very beginning when doing "00-prep_fipsmodule_cnf.t". This is my config options: ./Configure -Wl,-R,/.uvlibs1 aix64-cc enable-fips enable-acvp-tests no-mdc2 no-idea shared --prefix=/disk1/wzhy/openssl_build/install The strange thing is that if I just add the --debug option in config options, make test succeeds. Then I try openssl fipsinstall, it shows the same error log with make test: Unable to get MAC of type HMAC INSTALL FAILED 0001:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:373:Global default library context, Algorithm (HMAC : 0), Properties () I think add -debug should not be a good solution, can you give me some help? I paste my compile information as follow: $ pwd /disk1/wzhy/openssl_build/openssl-3.0.7 $ make test make depend && make _tests ( SRCTOP=. BLDTOP=. PERL="perl" FIPSKEY="f4556650ac31d35461610bac4ed81b1a181b2d8a43ea2854cbae22ca74560813" EXE_EXT= perl ./test/run_tests.pl ) 00-prep_fipsmodule_cnf.t .. Unable to get MAC of type HMAC INSTALL FAILED 0001:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:373:Global default library context, Algorithm (HMAC : 0), Properties () ../../util/wrap.pl ../../apps/openssl fipsinstall -module ../../providers/fips.so -provider_name fips -section_name fips_sect -out ../../test/fipsmodule.cnf => 1 not ok 1 - fips install 00-prep_fipsmodule_cnf.t .. 1/? # Failed test 'fips install' # at test/recipes/00-prep_fipsmodule_cnf.t line 33. 00-prep_fipsmodule_cnf.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Test Summary Report --- 00-prep_fipsmodule_cnf.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=1, Tests=1, 0 wallclock secs ( 0.01 usr 0.00 sys + 0.10 cusr 0.01 csys = 0.12 CPU) Result: FAIL make: The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. $ apps/openssl fipsinstall -module providers/fips.so -out fips1.cnf Unable to get MAC of type HMAC INSTALL FAILED 0001:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:373:Global default library context, Algorithm (HMAC : 0), Properties () $ /disk1/wzhy/openssl_build/install/bin/openssl fipsinstall -module /disk1/wzhy/openssl_build/install/lib//ossl-modules/fips.so -out fips1.cnf Unable to get MAC of type HMAC INSTALL FAILED 0001:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:373:Global default library context, Algorithm (HMAC : 0), Properties () $ /disk1/wzhy/openssl_build/install/bin/openssl version -a OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) built on: Thu Nov 3 05:50:08 2022 UTC platform: aix64-cc options: bn(64,64) compiler: cc -qpic -q64 -qmaxmem=16384 -qro -qroconst -qthreaded -O -DB_ENDIAN -DOPENSSL_PIC -D_THREAD_SAFE -DOPENSSL_BUILDING_OPENSSL -DNDEBUG OPENSSLDIR: "/disk1/wzhy/openssl_build/install/ssl" ENGINESDIR: "/disk1/wzhy/openssl_build/install/lib/engines-3" MODULESDIR: "/disk1/wzhy/openssl_build/install/lib/ossl-modules" Seeding source: os-specific CPUINFO: N/A $ oslevel -r 7100-04 $ perl configdata.pm --dump Command line (with current working directory = .): perl ./Configure -Wl,-R,/.uvlibs1 aix64-cc enable-fips enable-acvp-tests no-mdc2 no-idea shared --prefix=/disk1/wzhy/openssl_build/install Perl information: perl 5.10.1 for aix-thread-multi Enabled features: acvp-tests aria asm async autoalginit autoerrinit autoload-config bf blake2 bulk cached-fetch camellia capieng cast chacha cmac cmp cms comp ct deprecated des dgram dh dsa dso dtls dynamic-engine ec ec2m ecdh ecdsa engine err filenames fips fips-securitychecks gost legacy loadereng md4 module multiblock nextprotoneg ocb ocsp padlockeng pic pinshared poly1305 posix-io psk rc2 rc4 rdrand rfc3779 rmd160 scrypt secure-memory seed shared siphash siv sm2 sm3 sm4 sock srp srtp sse2 ssl ssl-trace static-engine stdio tests threads tls ts ui-console whirlpool tls1 tls1-method tls1_1 tls1_1-method tls1_2 tls1_2-method tls1_3 dtls1 dtls1-method dtls1_2 dtls1_2-method Disabled features: afalgeng[not-linux] OPENSSL_NO_AFALGENG asan[default]OPENSSL_NO_ASAN buildtest-c++ [default] crypto-mdebug [default]
