* topic: Change some words by accepting PR#12089
*
* 4 against, 3 for, no absensions
I am at a loss for words.
I can’t contribute to a project that feels this way. The OMC (list at [1], a
picture of some of them at [2] although it includes non-OMC members) is, in my
view, on the
C mandates that any “missing” initializers are as if 0/null were present.
{NULL, -1, 'Q', "unused end of list"} this is the change I’d like to offer
Turn off the warning.
>BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
should also be 4. If BN_BYTES is being incorrectly set to 8 on your
platform then that would explain the discrepancy. Can you check?
This
I dlon't lnow about Python's freefunc, no idea what it is, but the OpenSSL line
is defining a function with a local parameter named freefunc. Those names
shouldn't clash; what compiler and flags?
It should be possible to rename the one in safestack.h to be "freefuncarg" or
something. Can you
* >FIPS ciphers are a subset of the ciphers that OpenSSL supports.
* Is this true of both OpenSSL 2.0 FIPS version and OpenSSL 3.0 FIPS
version. (I suppose yes). But still your confirmation will be helpful.
Yes it is true for both.
* Also, current version is considered outdated,
Are you asking about the current (outdated) 2.0 module or the 3.0 module that
is still being developed?
In 2.0, once you enter FIPS mode you cannot leave it. In 3.0 you can switch
among FIPS and non-FIPS as you need to. See
https://www.openssl.org/docs/OpenSSL300Design.html for a description
* In any case, I am unaware of any existing system which meets your
requirement 3. Admittedly, I haven't specifically searched for such.
CertCo (now defunct, don’t know who has the intellectual property) had a patent
that did ALL of the things. RSA keygen, split the key, each key signs
* application/pkix-pkipath
* Defined in RFC4366 (section 8) and RFC6066 (section 10.1)
I doubt that it is worth doing this. First, because OpenSSL doesn’t support it
now, then CURL (what the original poster was talking about) can’t use it when
using OpenSSL. Instead, as others have
>Speaking of which, I've recently discovered (a documented interface
landmine) that:
status = SSL_read(ssl, ...);
err = SSL_get_error(ssl, status);
>is an anti-pattern, because the "correct" usage is:
It's not unlike checking errno without knowing if the syscall
You might find https://github.com/openssl/openssl/issues/10923 to have some
useful information.
OpenSSL is publically available.
Hm, so DSO support is a requirement for legacy crypto now? That probably needs
to be made explicit, and see if the project gets pushback.
* I have seen scripts that have the openssl smime option of -inform, or
-outform set to DEM.
That’s an error. PEM or DER. Interesting mixup. :)
It has been done. For example, we leverage the ASYNC interface to make the
private-key operations remote. There was also an RT ticket that had an
implementation for a version years ago. (I can't find the RT but I know it was
there.) The PKCS#11 stuff might also be appropriate.
>Yes, nice, why not reduce compile time and save prescious compiler
memory by getting rid of all-inline one-liners.
And link-time collapsing the identical code. I think this is an issue on some
Solaris, for example.
> Sorry for coming
over sarcastic, i am listening to "This
>I do not understand one thing at the moment. If i use
no-deprecated then the stack handling is not available:
If you use no-deprecated you have to use DEFINE_STACK_OF in exactly one file.
And use DECLARE_STACK in your common header file.
Let me know if this works, or not, for you.
* Sorry for being unclear, the goal would be to just not send the SCSV
value in the ClientHello.
Why?
>- Do you think any use for supporting some kind of alias for families of
> cipher in SSL_set_ciphersuites, like for example "TLSv1.3"
Suppose someone finds out that chacha/poly is insecure and the IETF issues a
new RFC that says "TLS 1.3 MUST NOT use" that cipher. Should the openssl alias
Isn't this the SSL EOF thing?
Just to close the loop: I decided better documentation is the only answer for
now: https://github.com/openssl/openssl/pull/11431
I'll copy the info below into a new issue.
On 3/21/20, 9:47 AM, "Salz, Rich via openssl-users"
wrote:
Argh. Thanks for the detailed e
>It seems some browsers open three to five sockets at the same time and
then don't complete SSL negotiation on all of them, just closing them
in various states.
Yes, this is exactly what they do.
>> The second question is somewhat related. Has there been a decision yet
> whether the FOM 3.0 will go through a 140-2 or a 140-3 validation?
>We are going through 140-2.
Has the list of validated platforms been made public yet?
For people using a different platform, will
Is it possible the browsers are trying to send early data?
rect. Unfortunately...
Cheers,
Richard
On Fri, 20 Mar 2020 22:12:08 +0100,
Salz, Rich via openssl-users wrote:
>
>
> The doc/man5/config.pod file says to use
>
> 1.OU = “My first OU”
>
> 2.OU =
The doc/man5/config.pod file says to use
1.OU = “My first OU”
2.OU = “My second OU”
But doc/man5/x509v3_config.pod says to append the numeric, as in
email.1 = steve@here
email.2 = steve@there
I believe the second form is correct.
The TLS RFC describes the “bytes on the wire” – the syntax for how client and
server communicate, and the semantics of those exchanges.
Is it a specification or standard? Yup both.
Is OpenSSL implementation of the spec? Yup.
What language used in the spec? It’s described in the RFC; see
> Please suggest me books or tutorials to understand OpenSSL and TLS
> cryptographic protocol in detail. I look forward to hearing from you. Thanks
> in advance.
Start with the RFC’s, then look for crypto basics – there are free books online.
* I am reading this article
Perhaps someone should writeup and submit a "NOTES.zos" file to add?
>Per section Supported Groups in RFC 8446 [1], FFDHE groups could be supported.
I was wrong, sorry for the distraction.
As others have pointed out, it will be in the next (3.0) release.
None of those choices address what happens in the 1.0.2 module goes to historic
on Sept 1. See
https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules
for details.
* That's fair. So the only option is to use another module? Extended 1.0.2
support does not resolve this either, correct?
I do not think that is the only option. For example, you might be able to use
3.0 and say it’s “in evaluation.” There might be other options, that was all I
could
* The OpenSSL FIPS Object Module will be moved to the CMVP historical list
as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module
will be after that sometime, where does this leave 1.0.2 users who need a FIPS
validated object module past that date?
Without their
>It would probably be a good idea for us to pull together a "Getting
Started" guide on the Wiki with some basic information on how to get
things going, with some links to the various man pages etc where more
detailed information is required.
This needs to be real user
* Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port
TLS 1.3 doesn’t have those groups.
> That's 5 weeks from now, I'd thought the basic structure might be present
> now.
It is. You probably have to look at the tests to see how to use things.
The 3.0 release is a work in progress and is not done yet.
FIPS 3.0 === OpenSSL 3.0, using a FIPS-validated crypto provider which will be
part of OpenSSL 3.0.
The architecture documents are at https://www.openssl.org/docs
On 2/26/20, 2:40 PM, "Sam Roberts" wrote:
On Wed, Feb 26, 2020 at
>I'd like to give this a spin, to get an idea what's going to be
involved in porting from FIPS2.0 to 3.0, any pointers on where to
start?
Per the blog post, "most applications should just need to be recompiled." :)
Get the source via instructions here:
Are you running as root? If not, that's likely to be the problem.
I believe you just load your ECDSA cert and the other stuff – Dhparams!! – is
not needed.
The first thing I would suggest is to separate ECDH, the session key exchange,
from ECDSA, the signature. Try to make ECDH with RSA work. Then just load
your ECDSA cert; you can load one cert of each type (RSA DSA) and the runtime
will figure out what to do, depending on what the client
I think the mismatch is that CSR extensions are not carried over; they have to
be added at signing time.
See https://github.com/openssl/openssl/issues/10458
A month ago Tim said[2] that PR 8797[1] requires on OMC decision on “whether or
not QUIC in this manner of approach should be added into OpenSSL at this time.”
To save you a click, this PR adds API’s to OpenSSL so that Google’s open source
QUIC implementation can be built on top of OpenSSL.
* If both default and fips provider are loaded and application generate
Rsa key pair(2048 bits) from fips provider and try to use default provider to
sign with sha1, is this allowed?
The application will have to explicitly “export” the key from the FIPS provider
and “import” it into the
TLS/TLS will take your data and wrap it inside it’s own record structure. It
has to, that’s the nature of the protocol. Thinking that a single writev() is
“encrypt buffers and then do analogous syscall” is wrong.
The next release of OpenSSL splits the “help” for commands into sections, like
this:
; ./apps/openssl rehash --help
Usage: rehash [options] [directory...]
General options:
-helpDisplay this summary
-h Display this summary
-compat Create both new- and old-style hash links
>Once we get that error, every time we try to serve a request in Apache using
>that pid, it errors out. So, it seems like something randomly corrupts that
>PID. Can someone provide some information about FIPS_CHECK_EC: pairwise test
>failed.
Once FIPS detects an error, it will stay stuck in
* I want to us ECDSA for my Web server's SSL certificate via an ACME client
to Let's Encrypt and maybe later BuyPass.
That’s fine.
* I thought that EC is better than RSA, but now I don't think so. The
answer seems to be: it depends.
There are trade-offs. The biggest one is that EC
The attached script summarizes git log data and generates CSV lines for each
commit. For example,
; git log -2 | ~/reviews.pl
8984, 2019-05-23, levi...@openssl.org, O, paul.d...@oracle.com, O
9624, 2019-08-18, bernd.edlin...@hotmail.de, C, levi...@openssl.org, O
It ignores log entries that don’t
>For using 1.1.0, we only need to call RAND_bytes() ?
Yes. But do check the return value of RAND_bytes.
>RAND_seed(seed, ::strlen(seed));
>RAND_bytes(buf, keySize / 8);
I don’t know where you are getting the seed, but it is typically binary data,
not a C string.
If you are using 1.1.0 or later, you do not need to seed things.
The question about -rand option is valid, but Viktor’s post is right and the
rest of my post is wrong :(
From: openssl-users
Reply-To: Rich Salz
Date: Monday, November 11, 2019 at 8:10 AM
To: shiva kumar , openssl-users
Subject: Re: dsaparam error OpenSSL 1.1.1d
* openssl dsaparam 128
* openssl dsaparam 128 -rand file
Why are you using the -rand option? Unless this is a special platform, don’t
do that.
* is taking long time processing the command and not producing any output.
What is your hardware and software?
Can you run it under a debugger, and interrupt it
If you are changing openssl, why not just change the init function to load your
engine and abort/exit/fail if it doesn’t load?
Why not just change things so that if your module fails to load, the library
exits?
Don't change the RAND code, change the INIT code.
Is looking at the IssuerDN good enough?
>Is there a way for me to piggyback a void* inside the SSL structure so
that I can access it from within the callback?
Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented in
https://github.com/openssl/openssl/pull/10216 (and due to be merged to master
soon)
* I can’t find documentation on how to tell TLS where to look.
Not sure about 1.0.2, but “openssl version -a” should show you the CERT
directory.
BTW, that’s an old release, you should upgrade if possible.
* Lastly, is there any chance of extending the EOL date of OpenSSL 1.0.2
till the new FIPS module/OpenSSL 3.0 becomes available?
This question gets asked a great deal. Why?
The OpenSSL project has not done any 1.0.2-FIPS work for years. This means that
if there are any CVE-level bugs in
>; git status
>On branch master
>Your branch is up-to-date with 'origin/master'.
>Untracked files:
> (use "git add ..." to include in what will be committed)
>
>include/openssl/opensslv.h
>
>nothing added to commit but untracked files present
There is nothing known to be wrong with NIST P256. If you don't have a known
reason to use 384, then don't use it.
Emilia's work removed the need to add -DPURIFY; you never need to add it.
Note that the BN code is clever, it doesn't bother to zero everything when it
knows which bits within a word it is using.
Several people have told you the following:
That is an *internal* openssl header file; do not use it.
Remove the include statement from your code. Your code is wrong.
That file is a C file, not compatible with C++
Why do you not listen?
>Greetings. I was checking for the support for Trusted
> Execution Environment (TEE) in OpenSSL.
I’m curious – what do you think would be required?
Please take a look at
https://lore.kernel.org/lkml/CAHk-=wiGg-G8JFJ=r7qf0b+utqa_weouk6v+mcmfsljlrq6...@mail.gmail.com/
and consider giving your comments.
TL;DR: see the comment below.
+ * Hacky workaround for the fact that some processes
+ * ask for truly secure random numbers and absolutely
* However if I try ECDHE, it works fine. Is DHE only cipher suites less
common now ?
* I believe its responsibility of server to generate DHparam of large
enough size.
Yes, DHE has dropped because it is hard to get right, and it takes more CPU
cycles than ECDHE.
On restart on my host with version 1.1.1d , I have this problem:
I hope you are not replacing your system OpenSSL with one you built. Don't do
that.
* I'd still like to know if it's possible to enable to both. If it's not,
though, then which one is best to enable? MD2 or
RC5? Thanks in advantage for the reply and sorry for the new email thread.
They do different things; MD2 is a digest (“hash”) function, and RC5 is a block
>I used CX509CertificateRequestCertificate class to create CSR with only
public key.
Those functions/classes/names/whatever are not part of OpenSSL.
The OpenSSL "req" command cannot process as CSR unless it is signed by the
private key. If you have a requirement to sign a CSR
Another great source is https://github.com/nabla-c0d3/trust_stores_observatory
One-stop shopping for all of apple, Android, Windows, NSS, OpenJDK, Oracle Java.
* I've another question, based on your suggestion Salz Rich, this config
@SECLEVEL can be set per host/domain, or is it impossible?
It totally depends on which webserver you are running and what it’s
configuration allows. I’m not able to answer webserver config questions BTW.
>In the same paragraph, the sentence before the one you're quoting says "If
> the subject field contains an empty sequence, then the issuing CA MUST
> include a subjectAltName extension that is marked as critical."
>It's not possible to have a missing subject name in a certificate,
* Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default
entropy sources.
* I dread the effort that this would entail.
Open an issue and maybe someone with an older platform will work on doing it.
I don’t think the project has any need to support such things. (Members of
subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD
mark subjectAltName as non-critical"
I can believe that OpenSSL doesn't support empty subjectName's. An empty one,
with no relative disintuished name components, is not the same as not present.
RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty
subjectName.
Non-empty subjectName or non-empty commonName within the subject name?
Shrug. Doesn't matter, I guess. Just populate it with the string version of
the HIT name, something like
CN=IP Address
> (why doesn't it use SSL_get_ex_data_X509_STORE_CTX_idx() instead of 0?).
History; OpenSSL reserved some exdata indices for itself.
* Had to downgrade the OpenSSL used in an application from 1.1.0k to 1.0.2s.
That’s too bad, given 1.0.2 is going to become unsupported at year-end. Was it
because the application wasn’t ready to handle opaque structures?
>Due to this I have to remove the usage of OPENSSL_thread_stop(),
>At the bottom of the man page for x509 it states the following:
The hash algorithm used in the -subject_hash and -issuer_hash options
before OpenSSL 1.0.0 was based on the deprecated MD5
algorithm and the encoding of the distinguished name. In OpenSSL 1.0.0 and
later it is based on
>Sadly, I can not make use of the "no-shared" option as I still need the
shared libraries to be built.
Statically linking against files built for shared libraries is possible on many
platforms (link against the .a even though .so exists), but not all platforms.
You can always build
>that the setenv-android.sh script doesn't account for 64 bit architectures.
Correct. The current FIPS module has not been modified for quite some time,
and your platform is not supported.
If you cannot follow the steps *exactly* you cannot claim FIPS validation. The
OpenSSL project is
Ectest has been broken for quite some time. What are the plans to get it fixed?
* Why the support for Heart beat extension is removed from openssl.
It’s intended use was to check MTU along the path. That is not very useful any
more.
* How to handle abnormal disconnection in DTLS？
You should be able to detect time-outs and “failure to close” in your
> It seems to me that the easiest thing to do is maintain that release of
OpenSSL by themselves.
>Which would be another variation of such unofficial work.
You could look at things like that. I consider it to be more like "your free
FIPS ride is done, time to pay up"
>That
>> They would have to get their own validation, their own lab to verify,
etc., etc.
>That seems to contradict the other answer, which is that legally, the
>FIPS cannister (properly built) can be used with any software outside
>the cryptographic boundary, the soon-to-be-deprecated
>Is the use of OpenSSL an actual legal requirement of the certification of
the FIPS object module, or just the easiest way to use it?
I'm not sure who you are asking this.
The exiting FIPS validations for OpenSSL only cover the 1.0.2 based source code.
>Difference would be
Didn’t you just ask this question? :)
If you followed the Win32 build instructions *exactly* and you build your
application to turn on FIPS mode and link against the canister, then yes.
If you made changes to the process, then no.
>I see those macros, but ... is there any documentation?
No.
>I'm attempting to build our RHEL 7 based product on RHEL 8 and running
> into a lot of changes from openssl 1.0.2k-fips (RHEL 7) to 1.1.1 FIPS (RHEL
> 8). I haven't found a good guide to adapting the sources to these changes.
Web search for "openssl opaque accessors" turns up many hits;
Do I construct a sequence and add items to it - top down?
No, because then you have to go back and patch the sequence length and perhaps
slide everything up or down a copule of bytes.
I would look at an existing simple sequence and start writing your own based on
that; look for
>Yes NetBSD cares about PARISC... We still build and run on it.
Thanks. The targets removed in that PR were for hpux-parisc.
>It depends on what you want to achieve. The top level template Makefile is
> in
Configureations/unix-Makefile.tmpl. Each individual directory contains a
build.info file which allows you to make per-directory changes to things
like
the sources to be compiled, etc.
And also
If you are adding new functions to the library, you need to
1A Make sure there is a prototype in one of the existing OpenSSL
header files;
OR
1B If your prototype is in a new header file, you will have to edit
Configurations/unix-Makefile.tmpl to pick up that
* The issue I have is that I don’t see ‘do_win64a’ within the ‘ms’
directory (I’m following build instructions here:
Thanks.
I had a trailing backslash on a source list, and it gobbled up the next line
which was an INCLUDE directive.
I am importing some code into openssl and getting a strange build error:
make[1]: *** No rule to make target 'crypto/bn/crypto/include.o', needed by
'libcrypto.a'. Stop.
Any common ideas on what to look for (e.g., missing header file, wrong INCLUDE
settings in build.info, etc) ?
>Then just set it to 1.0 and be done with it.
>That hardly helps on systems that don't have floating point at all.
No it doesn't. Such systems aren't supported by OpenSSL. There are many
places were floating point is used/supported.
Removing the second arg to RAND_add is the
>If it's a sarcasm, I'm missing the point.
I was't being sarcastic, I was trying to show that the team, recently, still
liked the use of floating point.
>There are use cases when one wants to mix/add extra randomness from, e.g.,
> an external source (that, for whatever reasons, is
When I overhauled the RAND mechanism, I tried to deprecate this use of floating
point, in favor of just a number from 0 to 100 but was voted down.
It *is* stupid. Luckily, on a modern system with system-provided randomness to
seed the RNG, you never need this call.
> Could you please look into the program and let me know if anything I am
> doing wrong ?
> Or else What could be the issue ?
Sorry, no not me. Maybe someone else on the list has ideas.
So now you know where to start looking, I guess. You might also change your
test program so that it calls the functions multiple times, to “smooth out” the
overhead.
I would start with doing profiling on old and new versions to see where the
slowdown is.
1 - 100 of 453 matches
Mail list logo
