Re: CVE-1999-0428

[Quanah Gibson-Mount]

--On Tuesday, March 3, 2020 5:16 PM -0500 Chris Rhoads 
 wrote:



But I've been unable to determine with certainty how the last
vulnerability on this list (CVE-1999-0428) was fixed.  In my research,
I've found a potential OpenSSL update in release 0.9.2b that may have
addressed the vulnerability: https://seclists.org/bugtraq/1999/Mar/144. 
But this security alert message doesn't reference any CVE number.


The above email is related to this commit in the OpenSSL source tree:

b4cadc6e1343c01b06613053a90ed2ee85e65090

Since it pre-dates the CVE being filed, it has no reference to the CVE 
itself in the commit.  Someone from the OpenSSL project would have to 
confirm if that is indeed the fix for the above CVE (and if so, then the 
CVE database needs updating).


Regards,
Quanah


--

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

Re: [RFC] TLS salt length auto detection, switch from DIGEST to AUTO

[William Roberts]

On Thu, Feb 27, 2020 at 1:01 PM Andersen, John S
 wrote:
>
> Hi All,
>
> The TPM 2.0 PKCS11 project has been attempting to get the TPM working with
> EAP-TLS WiFi.
>
> We've run into an issue where the TPM spec specifies that for RSA PSS signing
> keys, the random salt length will be the largest size allowed by the key size
> and message digest size.
>
> Server side, in SSL state machine the salt length gets set to
> RSA_PSS_SALTLEN_DIGEST (aka -1) which means the salt length must equal the
> hash length. Since the TPM used the largest size allowed by the key size and
> message digest size, rather than digest size, the handshake fails.
>
> The TSS and TPM TCG working groups will be working to modify this behavior, so
> that the salt length equals the hash length. However, rolling out the update 
> to
> the spec and then firmware updates to TPMs will take a very long time. As such
> we're wondering if OpenSSL would default to verifying with
> RSA_PSS_SALTLEN_AUTO for RSA PSS keys instead of RSA_PSS_SALTLEN_DIGEST
> as an intermediary measure.
>
> This was my original stab at it which made it work, which of course isn't 
> upstreamable.
>
> diff --git a/crypto/rsa/rsa_pss.c b/crypto/rsa/rsa_pss.c
> index f7c575d00a..26c9dcd078 100644
> --- a/crypto/rsa/rsa_pss.c
> +++ b/crypto/rsa/rsa_pss.c
> @@ -50,6 +50,10 @@ int RSA_verify_PKCS1_PSS_mgf1(RSA *rsa, const unsigned 
> char *mHash,
>  hLen = EVP_MD_size(Hash);
>  if (hLen < 0)
>  goto err;
> +
> +dprintf(2, "openssl: sLen: %d\n", sLen);
> +sLen = -2;
> +
>  /*-
>   * Negative sLen has special meanings:
>   *  -1  sLen == hLen
>
>
>
> The following isn't hacky, but it doesn't work and I'm not yet sure why 
> (still in the
> process of debugging but wanted to float the idea on the list).
>
>
>
> diff --git b/ssl/statem/statem_srvr.c a/ssl/statem/statem_srvr.c
> index 8cf9c40d15..d6793e01a4 100644
> --- b/ssl/statem/statem_srvr.c
> +++ a/ssl/statem/statem_srvr.c
> @@ -2783,7 +2783,7 @@ int tls_construct_server_key_exchange(SSL *s, WPACKET 
> *pkt)
>  }
>  if (lu->sig == EVP_PKEY_RSA_PSS) {
>  if (EVP_PKEY_CTX_set_rsa_padding(pctx, RSA_PKCS1_PSS_PADDING) <= > 0
> -|| EVP_PKEY_CTX_set_rsa_pss_saltlen(pctx, 
> RSA_PSS_SALTLEN_DIGEST) <= 0) {
> +|| EVP_PKEY_CTX_set_rsa_pss_saltlen(pctx, 
> RSA_PSS_SALTLEN_AUTO) <= 0) {
>  SSLfatal(s, SSL_AD_INTERNAL_ERROR,
>   SSL_F_TLS_CONSTRUCT_SERVER_KEY_EXCHANGE,
>  ERR_R_EVP_LIB);
>
>
> Reference: 
> https://github.com/tpm2-software/tpm2-pkcs11/pull/403#issuecomment-590395767
>

I was hoping to hear some thoughts from OSSL maintainers. I guess
perhaps the question wasn't clear. The
question is, can we relax the TLS requirement that slen == hlen and
set the flag to autodetect and upstream this?

Thanks,
Bill

CVE-1999-0428

[Chris Rhoads]

Hi openssl-users,


I am researching the known vulnerabilities of open source software that we
are considering.  According to the NIST NVD web site, the 1.1.1d version of
OpenSSL has a few known vulnerabilities:
https://nvd.nist.gov/vuln/search/results?form_type=Advanced_type=overview_type=all_vendor=cpe%3A%2F%3Aopenssl_product=cpe%3A%2F%3A%3Aopenssl_version=cpe%3A%2F%3Aopenssl%3Aopenssl%3A1.1.1d


It appears most of the vulnerabilities that are listed by NIST can be
dismissed since the security vulnerability was actually in an application
that uses OpenSSL instead of being in OpenSSL itself.


But I've been unable to determine with certainty how the last vulnerability
on this list (CVE-1999-0428) was fixed.  In my research, I've found a
potential OpenSSL update in release 0.9.2b that may have addressed the
vulnerability: https://seclists.org/bugtraq/1999/Mar/144.  But this
security alert message doesn't reference any CVE number.


The OpenSSL Vulnerabilities web page (
https://www.openssl.org/news/vulnerabilities.html) doesn't go back to 1999,
so it doesn't provide any information regarding this vulnerability.


Can anyone point me to OpenSSL documentation that indicates CVE-1999-0428
was fixed?  Thanks.

Re: Problems porting Openssl 1.1.1d to zos.

[Michael Mueller]

We recently abandoned our effort to port 1.1.1d to zos. Attempting to use
GSK now. Lack of a zos dev community is a hurdle.

M

On Mon, Mar 2, 2020, 6:04 AM K Lengauer  wrote:

> Dear all,
>
> I stumbled across this mails when looking for information regarding OpenSSL
> on zOS. Currently, I am working on getting OpenSSL 1.1.1c running on zOS.
> So
> far I created my own config "target" inside 10-main.conf based on the old
> configuration that was used pre OpenSSL 1.1.0.
>
> Still, I was not able to get that far yet and was wondering how you
> proceeded regarding this issue? Apart from some github issues and the likes
> regarding EBCDIC patches I was unable to find much advice on how to
> configure the build and how to tackle common issues. One config target for
> zOS OS390 was created a while back but then removed again from OpenSSL
> 1.1.1. With my config target I made it to the compile step but still face
> build issues. Reaching a complete build like Wendell Nichols would already
> by a great step.
>
> Are any of you aware of zOS specific OpenSSL development branches that I
> have yet to find? Or is this mainly done in private repositories/branches
> and not offered for PRs to the OpenSSL repository?
>
> Any advice is greatly appreciated.
>
>
>
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
>

RE: Config question

[Michael Wojcik]

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Richard Simard
Sent: Tuesday, March 03, 2020 07:57

> Wen I creating my root certificates I would like to add the version of the
> certification authority. I searched but I couldn't find anything. Is there
> anyone among you who could tell me how to add this information in the
> configuration of OpenSSL

What does this "version" look like?

Can you simply make it one of the components of the Subject and Issuer DNs 
(which must be the same, since this is a root certificate)? Assuming you want 
to conform to PKIX, RFC 5280 allows the serialNumber attribute (which is not 
the same as the certificate serial number) in a DN; you could use that.

There's also the old "Netscape Comment" extension. There might be other 
suitable extensions.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Re: OpenSSL reports wrong TLS version to FreeRADIUS

[Alfred Arnold]

Hi,


Alfred, I'd like to say "thanks" once more.

I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16) 
indeed sends me the second

"challenge". So, it's a huge progress.


Indeed, the capture now looks like an EAP-TLS negotiation should go on. 
The server accepted the client hello, an prepared its message flight of 
messages.  Among them is the server's Certificate message, which is quite 
huge, and so they cannot be sent in one packet.  Your client would next 
send an empty EAP-TLS message, thereby acknowledging reception of this 
message fragment.  The server would then send the next fragment of these 
messages.  Since the overall length of the message flight is 3137, and 
FreeRADUIS decided to send ~1000 bytes per fragment, expect another two of 
those 'ping-pongs' to happen until your client is able to reassemble and 
process the server's messages.


However it still complains on the unknown TLS version. I attach the 
server log and the packet capture, just in case.


Well, no idea where the version 0x0304 is coming from.  One would probably 
have to look into the FreeRADIUS sources, or ask on the proper FreeRADIUS 
mailing lists for assistance.  My personal "wild guess" is that this is 
some sort of 'internal default' as long as the the EAP-TLS module hasn't 
yet decided about the used protocol version.  I wouldn't bother about this 
too much if you're interested in other things.


There's however one other thing I wanted to mention: The Random value your 
clients sends in the Client Hello is not that random...there is the time 
stamp in the first four bytes, but the remaining 28 bytes are all-zero - 
they should contain data from a cryptographically safe random number 
generator.


Best regards

Alfred Arnold

--
Alfred Arnold   E-Mail: alf...@ccac.rwth-aachen.de
Computer Club at thehttp://john.ccac.rwth-aachen.de:8000/alf/
Technical UniversityPhone: +49-241-406526
of Aachen

Re: OpenSSL reports wrong TLS version to FreeRADIUS

[Matt Caswell]

On 02/03/2020 11:28, iilinasi wrote:
> Freeradius (3.0.16, 3.0.20)

Could be this issue:

https://github.com/FreeRADIUS/freeradius-server/issues/2385

"It may be due to the issue fixed in commit fd803c9. 3.0.17 sometimes
complained that TLS 1.3 was unknown, and refused to do TLS 1.3 at all.
That patch should fix it."

Matt

Config question

[Richard Simard]

Good Morning all.

Wen I creating my root certificates I would like to add the version of the 
certification authority. I searched but I couldn't find anything. Is there 
anyone among you who could tell me how to add this information in the 
configuration of OpenSSL
Tank-You
[https://www.groupesti.com/img/logo-28x28.png]Groupe Solutions TI
[cid:image002.jpg@01D5F141.F213CD90]
Richard Simard
B. Sc. I, ING. I, M.S.I. ASER
Président
Agent Provincial FQCQ
Matricule : 83787
Radioamateur : VA2SI Formateur et Examinateur
Groupe Solutions TI
3-4109, Saint-Alexandre
Saguenay, Québec
G8A 2H1, Canada
Cellulaire : +1 (418) 812-8760
Courriel : richard.sim...@groupesti.com



Messages de confidentialité : Ce courriel (de même que les fichiers joints) est 
strictement réservé à l'usage de la personne ou de l'entité à qui il est 
adressé et peut contenir de l'information privilégiée et confidentielle. Toute 
divulgation, distribution ou copie de ce courriel est strictement prohibée. Si 
vous avez reçu ce courriel par erreur, veuillez nous en aviser sur-le-champ, 
détruire toutes les copies et le supprimer de votre système informatique.

Confidentiality Message : This communication (including any files transmitted 
with it) is intended solely for the person or entity to whom it is addressed, 
and may contain confidential or privileged information. The disclosure, 
distribution or copying of this message is strictly forbidden. Should you have 
received this communication in error, kindly contact the sender promptly, 
destroy any copies and delete this message from your computer system.

[cid:image003.png@01D5F141.F213CD90]  [cid:image004.png@01D5F141.F213CD90]

Re: OpenSSL reports wrong TLS version to FreeRADIUS

[Matt Caswell]

On 03/03/2020 12:51, iilinasi wrote:
> Alfred, I'd like to say "thanks" once more.
> 
> I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16)
> indeed sends me the second "challenge". So, it's a huge progress.
> 
> However it still complains on the unknown TLS version. I attach the
> server log and the packet capture, just in case.

This is the interesting part from the server log.

(1) eap_tls: TLS_accept: before SSL initialization
(1) eap_tls: <<< recv UNKNOWN TLS VERSION ?0304? [length 0048]
(1) eap_tls: TLS_accept: SSLv3/TLS read client hello

The "before SSL initialization" and the "SSLv3/TLS read client hello"
strings are generated by OpenSSL. They are the return values from a call
to the function SSL_state_string_long() and are intended to give a human
readable output of what state the SSL object is in and where in the
handshake process it has got to.

Interestingly the "UNKNOWN TLS VERSION" message appears between the
"before" state and the "read client hello" state. The latter will be
returned after the SSL object has gone through its initial setup but
before or during the processing of a ClientHello received from the
client. The TLS protocol version that server will use is chosen during
the processing of that ClientHello. Depending on exactly at what point
we're at it is possible that a call to SSL_version() will return either
the selected version or (if we haven't got as far as selecting a version
yet), the version that the SSL object was initialised with.

New SSL objects created using TLS_method(), or TLS_server_method() will
have their version initialised to TLS_MAX_VERSION. In OpenSSL 1.1.1
TLS_MAX_VERSION is 0x0304 (TLSv1.3).

The string "UNKNOWN TLS VERSION" does not appear in libssl at all. So my
guess is that this warning is actually coming from eap_tls after it has
made a call to SSL_version(). Since the version has not actually been
negotiated yet it comes back with TLSv1.3, and eap_tls doesn't know how
to handle it.

Is this actually an error? Or just a warning?

Matt

Re: OpenSSL reports wrong TLS version to FreeRADIUS

[iilinasi]

;/etc/freeradius/3.0/certs/dh"
fragment_size = 1024
include_length = yes
auto_chain = yes
check_crl = no
check_all_crl = no
cipher_list = "DEFAULT"
cipher_server_preference = no
ecdh_curve = "prime256v1"
tls_max_version = "1.2"
tls_min_version = "1.0"
cache {
enable = no
lifetime = 24
name = "EAP-TLS"
max_entries = 255
persist_dir = "/var/log/freeradius/tlscache"
}
verify {
skip_if_ocsp_ok = no
}
ocsp {
enable = no
override_cert_url = yes
url = "http://127.0.0.1/ocsp/;
use_nonce = yes
timeout = 0
softfail = no
}
   }
   # Linked to sub-module rlm_eap_ttls
   ttls {
tls = "tls-common"
default_eap_type = "md5"
copy_request_to_tunnel = no
use_tunneled_reply = no
virtual_server = "inner-tunnel"
include_length = yes
require_client_cert = no
   }
tls: Using cached TLS configuration from previous invocation
   # Linked to sub-module rlm_eap_peap
   peap {
tls = "tls-common"
default_eap_type = "mschapv2"
copy_request_to_tunnel = no
use_tunneled_reply = no
proxy_tunneled_request_as_eap = yes
virtual_server = "inner-tunnel"
soh = no
require_client_cert = no
   }
tls: Using cached TLS configuration from previous invocation
   # Linked to sub-module rlm_eap_mschapv2
   mschapv2 {
with_ntdomain_hack = no
send_error = no
   }
  # Instantiating module "logintime" from file 
/etc/freeradius/3.0/mods-enabled/logintime
  # Instantiating module "files" from file 
/etc/freeradius/3.0/mods-enabled/files
reading pairlist file /etc/freeradius/3.0/mods-config/files/authorize
reading pairlist file /etc/freeradius/3.0/mods-config/files/accounting
reading pairlist file /etc/freeradius/3.0/mods-config/files/pre-proxy
  # Instantiating module "preprocess" from file 
/etc/freeradius/3.0/mods-enabled/preprocess
reading pairlist file /etc/freeradius/3.0/mods-config/preprocess/huntgroups
reading pairlist file /etc/freeradius/3.0/mods-config/preprocess/hints
  # Instantiating module "IPASS" from file 
/etc/freeradius/3.0/mods-enabled/realm
  # Instantiating module "suffix" from file 
/etc/freeradius/3.0/mods-enabled/realm
  # Instantiating module "realmpercent" from file 
/etc/freeradius/3.0/mods-enabled/realm
  # Instantiating module "ntdomain" from file 
/etc/freeradius/3.0/mods-enabled/realm
 } # modules
radiusd:  Loading Virtual Servers 
server { # from file /etc/freeradius/3.0/radiusd.conf
} # server
server default { # from file /etc/freeradius/3.0/sites-enabled/default
 # Loading authenticate {...}
 # Loading authorize {...}
Ignoring "ldap" (see raddb/mods-available/README.rst)
 # Loading preacct {...}
 # Loading accounting {...}
 # Loading post-proxy {...}
 # Loading post-auth {...}
} # server default
server inner-tunnel { # from file /etc/freeradius/3.0/sites-enabled/inner-tunnel
 # Loading authenticate {...}
 # Loading authorize {...}
 # Loading session {...}
 # Loading post-proxy {...}
 # Loading post-auth {...}
 # Skipping contents of 'if' as it is always 'false' -- 
/etc/freeradius/3.0/sites-enabled/inner-tunnel:331
} # server inner-tunnel
radiusd:  Opening IP addresses and Ports 
listen {
type = "auth"
ipaddr = *
port = 0
   limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
   }
}
listen {
type = "acct"
ipaddr = *
port = 0
   limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
   }
}
listen {
type = "auth"
ipv6addr = ::
port = 0
   limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
   }
}
listen {
type = "acct"
ipv6addr = ::
port = 0
   limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
   }
}
listen {
type = "auth"
ipaddr = 127.0.0.1
port = 18120
}
Listening on auth address * port 1812 bound to server default
Listening on acct address * port 1813 bound to server default
Listening on auth address :: port 1812 bound to server default
Listening on acct address :: port 1813 bound to server default
Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel
Listening on proxy address * port 60197
Listening on proxy address :: port 55693
Ready to process requests
(0) Received Access-Request Id 200 from 192.168.0.14:35328 to 192.168.0.59:1812 
length 67
(0)   Service-Type = Framed-User
(0)   User-Name = "test"
(0)   Framed-MTU = 1500
(0)   EAP-Message = 0x020500

Re: OpenSSL reports wrong TLS version to FreeRADIUS

[iilinasi]

Thank you Alfred!

Yup, I used old ciphers indeed. I suspect it stops even before checking 
them, but I'll add newer ones and let you know.



This is the relevant part of freeradius log, just in case:
--
(1) eap_tls: TLS_accept: before SSL initialization
(1) eap_tls: TLS_accept: before SSL initialization
(1) eap_tls: <<< recv TLS 1.3  [length 0048]
(1) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal 
protocol_version

(1) eap_tls: ERROR: TLS Alert write:fatal:protocol version
tls: TLS_accept: Error in error
(1) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): 
error:14209102:SSL 
routines:tls_early_post_process_client_hello:unsupported protocol

(1) eap_tls: ERROR: System call (I/O) error (-1)
(1) eap_tls: ERROR: TLS receive handshake failed during operation
(1) eap_tls: ERROR: [eaptls process] = fail
--


On 02.03.2020 14:15, Alfred Arnold wrote:

Hi,

I'd like to understand, how does OpenSSL get to the idea of "0304" 
version, if there is no such a

byte sequence in the packet...
My question is: how OpenSSL determines the TLS version? How to debug 
it?


I don't see any TLS 1.3 in the capture as well, but I see that your
client is using only outdated (if not to say: historic) cryptographic
algorithms: RC4, RC2 (never seen that in practice!), 3DES and DES.
And those even combined with export options to weaken key strength.
Many modern servers are configured to disallow such outdated crypto:
make your client use at least

- AES128/256 (either in CBC or GCM mode)
- TLS 1.2
- no export cipher suites

Then you might get a more positive reply from the server...

Best regards

Alfred Arnold


--
Thanks and regards,
Irina Ilina-Sidorova

Re: Ues 'openssl s_server command' to disable TLS1.0

[Matt Caswell]

On 03/03/2020 07:48, guoxiaobi...@163.com wrote:
> Dear All,
> 
>  
> 
> I hit the following error when used ‘openssl s_server -no_tls1’ command
> to disable TLS1.0 on Redhat Linux server.

Your question is slightly ambiguous. It implies you expect the command
to disable TLSv1.0 for all applications on your server. If that is what
you meant then you will be disappointed. "openssl s_server" runs a test
server to enable testing TLS connections from clients. The "-no_tls1"
option disables TLSv1.0 for that test server instance only.

If you really mean to start a test server then you need to additionally
supply a key and certificate file. By default s_server will look for the
key/cert in the file server.pem in the current working directory.
Otherwise you have to explicitly state the location of these files with
the "-key" and "-cert" options.

Matt



> It shows the openssl version
> as well.
> 
>  
> 
> 
> 
> $ openssl version
> 
> OpenSSL 1.0.1e-fips 11 Feb 2013
> 
> $ openssl s_server –no_tls1
> 
> Error opening server certificate private key file server.pem
> 
> 140057863432008:error:02001002:system library:fopen:No such file or
> directory:bss_file.c:398:fopen(‘server.pem’,’r’)
> 
> 140057863432008:error:20074002:BIO routines:FILE_CTRL:system
> lib:bss_file.c:400:
> 
> unable to load server certificate private key file
> 
> -
> 
>  
> 
> I can’t confirm if the command format is fine or not. Would you please
> help to correct me?
> 
>  
> 
> Thanks and Regards,
> 
> Chobin Guo
> 

Re: certificate verification error OpenSSL 1.1.1

[Jakob Bohm via openssl-users]

On 2020-03-03 08:19, Viktor Dukhovni wrote:

On Mon, Mar 02, 2020 at 01:48:20PM +0530, shiva kumar wrote:


when I tried to verify the the self signed certificate in OpenSSL 1.0.2 it
is giving error 18 and gives OK as o/p, when I tried the same with OpenSSL
1.1.1 there is slight change in the behavior it also gives the same error,
but instead of OK it gives different error as "*ca.crt: verification failed*"
as follows.

The 1.1.1 behaviour is correct.  But you also don't seem to have a clear
idea of what it means to "verify" a self-signed certificate.  Indeed
most likely you don't actually want to verify it at all, and are really
trying to solve other problem, which you've decided involves verifying
the certificate in question.  So it is likely best to describe the
*actual* issue you're trying to solve.

Depends heavily if you formally interpret a self-signed and self-issued
end cert as a CA issuing itself (thus requiring CA:TRUE and making it
invalid as an end cert) or as an end cert with no separate CA chain
(thus requiring CA:FALSE and making it not trusted as a CA for any other
certificate).

Either way, the typical case is to use such a self-signed and self-issued
cert in the various OpenSSL supported protocols (SSL, TLS, CMS etc.)

However, that said:


openssl verify ./ca.crt

This command verifies the certificate in question by trying to find in
the default store a chain of issuers leading up to a trust anchor
(typically a self-signed root CA).

But a self-signed certificate is self-issued, so unless it is itself
present in the trust store, no possible issuer can be found there.  So
verification must always fail, and so it does.


why I'm getting this error?

Well ultimately because you don't know what you're trying to do,
but specifically because the certificate is not issued by an
already trusted issuer.


is this an expected behavior in OpenSSL 1.1.1?

Yes.


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: Stream Encription

[Viktor Dukhovni]

On Tue, Mar 03, 2020 at 10:25:16AM +0300, Илья Юркевич (Ilya Yurkevich) via 
openssl-users wrote:

> No, I want to get CMS Enveloped data in the end of the procedure. 

The OpenSSL cms(1) command supports streaming when encoding (but not
when decoding).  If you wade through the source of apps/cms.c, you'll
find the relevant calls.

-- 
Viktor.

Re: Stream Encription

[Ilya Yurkevich]

No, I want to get CMS Enveloped data in the end of the procedure. 
 
Firstly, I initialize the encryption operation by adding recipient 
certificates, algorithms, etc., then send the data in chunks for encryption and 
receive them in an encrypted format for further writing to the file. At the end 
of the operation, I call the finalizing of the encryption, which adds the final 
bytes 0x00 0x00 to the cms structure for internal blocks, meaning the end of 
each cms block - this is what I mean. As far as I know CryptMsgUpdate() in 
CryptoApi allows it - I'm trying to explain my purpose to you better using 
examples.
I want to get something similar in OpenSSL. It’s possible?
 
Now I use such method:
…
cms = CMS_encrypt(certs, NULL, cipher, CMS_STREAM | CMS_BINARY); //call it once 
at the start
 
BIO* input = CMS_dataInit(cms, NULL); //call it once at the start

BIO_write(input, pbData, cbData);//call each time to add another part of data
 
CMS_dataFinal(cms, input); //call it once in the end of encryption
…
 
This method allows me to read data in stream mode and send it to BIO_write(). 
But I can’t send encrypted data by parts — only after calling CMS_dataFinal() — 
from cms structure. Thanks for any help.
 
>Пятница, 28 февраля 2020, 16:55 +03:00 от Dmitry Belyavsky < beld...@gmail.com 
>>:
> 
>Hello,
> 
>If you mean encryption/decryption only, I strongly suppose you should look at 
>EVP_CipherInit/Update/Final functions.  
>On Fri, Feb 28, 2020 at 4:53 PM Ilya Yurkevich via openssl-users < 
>openssl-users@openssl.org > wrote:
>>Hello,
>>I have a client, that sends me data, that I need to encrypt, in few steps. I 
>>can use such functions in PKCS11: C_EncryptInit (...), C_EncryptUpdate (...), 
>>C_EncryptFinal (...). It allows me add data, that will be encrypted at every 
>>step, using C_EncryptUpdate   function.
>> 
>>In OpenSSL I found CMS_encrypt (...) with flag = CMS_STREAM, but I can't 
>>understand how I can add data as I described above or another way? I get data 
>>in unsigned char* every time. Any help would be appreciated. Thanks. 
> 
>  --
>SY, Dmitry Belyavsky

Ues 'openssl s_server command' to disable TLS1.0

[guoxiaobinni]

Dear All,

 

I hit the following error when used 'openssl s_server -no_tls1' command to
disable TLS1.0 on Redhat Linux server. It shows the openssl version as well.

 




$ openssl version

OpenSSL 1.0.1e-fips 11 Feb 2013

$ openssl s_server -no_tls1

Error opening server certificate private key file server.pem

140057863432008:error:02001002:system library:fopen:No such file or
directory:bss_file.c:398:fopen('server.pem','r')

140057863432008:error:20074002:BIO routines:FILE_CTRL:system
lib:bss_file.c:400:

unable to load server certificate private key file


-

 

I can't confirm if the command format is fine or not. Would you please help
to correct me?

 

Thanks and Regards,

Chobin Guo