TLS/SSL and crypto library

Overview

Welcome to the OpenSSL Project

openssl logo

github actions ci badge appveyor badge

OpenSSL is a robust, commercial-grade, full-featured Open Source Toolkit for the Transport Layer Security (TLS) protocol formerly known as the Secure Sockets Layer (SSL) protocol. The protocol implementation is based on a full-strength general purpose cryptographic library, which can also be used stand-alone.

OpenSSL is descended from the SSLeay library developed by Eric A. Young and Tim J. Hudson.

The official Home Page of the OpenSSL Project is www.openssl.org.

Table of Contents

Overview

The OpenSSL toolkit includes:

  • libssl an implementation of all TLS protocol versions up to TLSv1.3 (RFC 8446).

  • libcrypto a full-strength general purpose cryptographic library. It constitutes the basis of the TLS implementation, but can also be used independently.

  • openssl the OpenSSL command line tool, a swiss army knife for cryptographic tasks, testing and analyzing. It can be used for

    • creation of key parameters
    • creation of X.509 certificates, CSRs and CRLs
    • calculation of message digests
    • encryption and decryption
    • SSL/TLS client and server tests
    • handling of S/MIME signed or encrypted mail
    • and more...

Download

For Production Use

Source code tarballs of the official releases can be downloaded from www.openssl.org/source. The OpenSSL project does not distribute the toolkit in binary form.

However, for a large variety of operating systems precompiled versions of the OpenSSL toolkit are available. In particular on Linux and other Unix operating systems it is normally recommended to link against the precompiled shared libraries provided by the distributor or vendor.

For Testing and Development

Although testing and development could in theory also be done using the source tarballs, having a local copy of the git repository with the entire project history gives you much more insight into the code base.

The official OpenSSL Git Repository is located at git.openssl.org. There is a GitHub mirror of the repository at github.com/openssl/openssl, which is updated automatically from the former on every commit.

A local copy of the Git Repository can be obtained by cloning it from the original OpenSSL repository using

git clone git://git.openssl.org/openssl.git

or from the GitHub mirror using

git clone https://github.com/openssl/openssl.git

If you intend to contribute to OpenSSL, either to fix bugs or contribute new features, you need to fork the OpenSSL repository openssl/openssl on GitHub and clone your public fork instead.

git clone https://github.com/yourname/openssl.git

This is necessary, because all development of OpenSSL nowadays is done via GitHub pull requests. For more details, see Contributing.

Build and Install

After obtaining the Source, have a look at the INSTALL file for detailed instructions about building and installing OpenSSL. For some platforms, the installation instructions are amended by a platform specific document.

Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL 3.0 Wiki page.

Documentation

Manual Pages

The manual pages for the master branch and all current stable releases are available online.

Wiki

There is a Wiki at wiki.openssl.org which is currently not very active. It contains a lot of useful information, not all of which is up to date.

License

OpenSSL is licensed under the Apache License 2.0, which means that you are free to get and use it for commercial and non-commercial purposes as long as you fulfill its conditions.

See the LICENSE.txt file for more details.

Support

There are various ways to get in touch. The correct channel depends on your requirement. see the SUPPORT file for more details.

Contributing

If you are interested and willing to contribute to the OpenSSL project, please take a look at the CONTRIBUTING file.

Legalities

A number of nations restrict the use or export of cryptography. If you are potentially subject to such restrictions you should seek legal advice before attempting to develop or distribute cryptographic code.

Copyright

Copyright (c) 1998-2021 The OpenSSL Project

Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson

All rights reserved.

Issues
  • mingw after refactor-build: misc issues

    mingw after refactor-build: misc issues

    Testing mingw after build refactor (https://github.com/levitte/openssl/tree/refactor-build), using configuration that worked for 1.1.0-pre1/2 and 1.0.2, an early abort is the result:

    Can't locate Text/Template.pm in @INC (you may need to install the Text::Template module) (@INC contains: util util/../external/perl . /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl) at /usr/share/perl5/core_perl/parent.pm line 20.
    BEGIN failed--compilation aborted at util/dofile.pl line 45.
    

    Ref: https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.380#L797

    What needs to be done with Perl to get the required extra packages, under an AppVeyor environment?

    /cc @levitte

    opened by vszakats 362
  • Assistance request: setting up for NonStop platform support

    Assistance request: setting up for NonStop platform support

    Greetings! I'm about to submit a PR for the NonStop NSX and NSE platform ports for OpenSSL and need assistance in setting up required pieces (Configurations/x-nonstop.conf) as well as documenting the port. The overall port has two basic aspects that deviate from standard code:

    • Inclusion of platform FLOSS method redirects to emulate Linux behaviour, and
    • Changes to root id - root on NonStop is 65535 rather than 0, and
    • Compiles under c99 rather than gcc.
    issue: feature request 
    opened by rsbecker 182
  • Test 04-test_encoder_decoder.t fails on NonStop x86

    Test 04-test_encoder_decoder.t fails on NonStop x86

    This particular test works fine on 3.0.0 as released and with updates along the 3.0.0 branch. Where it fails is in master:

    04-test_encoder_decoder.t .......... 1/?
    ../../util/wrap.pl ../../test/endecode_test -rsa ../../test/certs/ee-key.pem -pss ../../test/certs/ca-pss-key.pem -context -config ../../test/default.cnf -provider default => 139
    

    This is a reopen of what was #16950 focusing on the real issue rather than the red-herring subject of that issue. I'm trying to figure out what changed between the two branches in a significant way and would like help tracking this down. Running directly and debugging using endecode_test appears to report a 0 completion code when the wrap.pl reports 139.

    triaged: bug 
    opened by rsbeckerca 128
  • Configure/Makefile: fix some FIPS installation issues

    Configure/Makefile: fix some FIPS installation issues

    This pull request fixes some FIPS installation issues (notably #13679 and #13680), but it is marked as a DRAFT, because

    • I need some help from @levitte for the analoge changes to the VMS template (descrip.mms.tmpl) and
    • there are still some open questions, ~which need to be written down and resolved first~ see followup post.

    For more details, see the commit messages.

    Commits (bottom up)

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 22:44:32 2020 +0100

    Configure/Makefile: correct the FIPS module configuration file path
    
    According to the OpenSSL 3.0 Wiki, the file should be located at
    
        $(OPENSSLDIR)/fipsmodule.cnf
    
    next to the openssl.cnf file.
    

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 22:34:41 2020 +0100

    Configure/Makefile: use the correct openssl app for FIPS installation
    
    The `openssl` app was previously called without a path, which
    would generally invoke the system's copy of the openssl application.
    Currently, that's most likely an openssl version 1.1.1 application,
    which does not recognize the `fipsinstall` command and terminates
    with an error message.
    

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 19:41:58 2020 +0100

    Configure/Makefile: fix the `-macopt` argument of the fipsinstall command
    
    The FIPS hmac key is provided as a hexadezimal string, which needs to
    be be prefixed with `hexkey:`, not `key:`.
    

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 19:41:37 2020 +0100

    Configure/Makefile fix target dependency for the FIPS provider installation
    
    Don't uninstall entire software just because FIPS provider module configuration
    file is removed.
    
    In more technical terms: since the `install_fips` target depends on `install_sw`,
    the `uninstall_sw` target should depend on `uninstall_fips`, not vice versa.
    

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 19:27:41 2020 +0100

    Configure/Makefile: fix Perl error in FIPSMODULENAME declaration
    
    Fixes #13679
    
    branch: master approval: ready to merge triaged: OTC evaluated 
    opened by mspncp 124
  • Fix reseeding issues introduced by new RAND_OpenSSL() method

    Fix reseeding issues introduced by new RAND_OpenSSL() method

    Checklist

    • [x] documentation is added or updated (RAND_add() needs to be updated)

    Introduction

    The broken 'RAND_add()/RAND_bytes()' pattern

    In the thread [openssl-dev] Plea for a new public OpenSSL RNG API I explained in detail that the different reseeding concepts of the classic OpenSSL RNG and the new RAND_DRBG API (pushing entropy via RAND_add() vs. pulling entropy via get_entropy() callback) make it so difficult to get both APIs work together in harmony, at least as far as reseeding is concerned. The following is a brief excerpt from that thread:

    In OpenSSL, the classical way for the RNG consumer to add his own randomness is to call RAND_add() before calling RAND_bytes(). If the new RAND_OpenSSL() method (the "compatibility layer" hiding the public RAND_DRBG instance) is the default, then this does not work as expected anymore:

    The reason is that a call to RAND_add() adds the provided randomness only to a global buffer (rand_bytes), from which it will be pulled during the next reseed. But no reseed is triggered. So the next RAND_bytes() call will be unaffected from the RAND_add(), which is not what the consumer expected. (The same holds for RAND_seed(), since drbg_seed() only calls into drbg_add())

    Reseeding of DRBGs occurs only at the following occasions:

    • immediately after a fork() (new)
    • if the reseed_counter exceeds the reseed_interval
    • if RAND_DRBG_generate() is called requesting prediction_resistance
    • RAND_DRBG_reseed() is called explicitely

    Note: Currently it looks like the situation is even worse: if RAND_add() is called multiple times before a reseed occurs, then the result of the previous call is overwritten.

    In this pull request I propose a solution to this problem for general discussion.

    Some background information on seeding the DRBG

    NIST SP 800-90Ar1 has the concept of security_strength. Currently there are three different security strengths for the CTR_DRBG, specified by the NIDs NID_aes_128_ctr, NID_aes_192_ctr, NID_aes_256_ctr. Their parameter values are hardcoded (in ctr_init()) and taken from 'Table 3: Definitions for the CTR_DRBG' on page 49 of NIST SP 800-90Ar1. In particular, there is no need to have an extra RANDOMNESS_NEEDED constant.

    The role of the derivation function for seeding

    The internal state of the CTR_DRBG consists of two vectors

        unsigned char K[<keylen>];
        unsigned char V[<blocklen>];
    

    so the total number of seed bytes (seedlen in Table 3) equals seedlen = keylen + blocklen. (As mentioned earlier: in the NIST document, everything is in bits, whereas in OpenSSL, entropy is in bits, buffer lengths are in bytes).

    Seeding without derivation function

    If no derivation function is used, the unmodified input is used to seed (K,V). This means, one has to provide exactly seedlen=keylen+blocken bytes, which in the case of a high quality entropy source contains much more entropy than needed: 8 * seedlen > security_strength.

    Seeding with derivation function

    If a derivation function is used (which we always do), then the input can be of variable length between drbg->min_entropylen and drbg->max_entropylen. The DF takes a variable length input and produces a pseudorandom output from which (K,V) is seeded. This is done using AES-CTR. In some sense, the DF acts as a meat grinder, compressing the entropy of the input.

    Using the derivation has two advantages: 1) min_entropylen = keylen < seedlen , so you need less input if your input has full entropy and 2) The input can be of variable size min_entropylen < inputsize < max_entropylen , which is good if your input has low entropy (say, only 2 bits per byte).

    All values can be found in Table 3 and are hardcoded in ctr_init():

    	int ctr_init(RAND_DRBG *drbg)
    	{
    		...
    
    		ctr->keylen = keylen;
    		drbg->strength = keylen * 8;
    		drbg->seedlen = keylen + 16;
    
    		if (drbg->flags & RAND_DRBG_FLAG_CTR_USE_DF) {
    			/* df initialisation */
    			static unsigned char df_key[32] = {
    				0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,
    				0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,
    				0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,
    				0x18,0x19,0x1a,0x1b,0x1c,0x1d,0x1e,0x1f
    			};
    			/* Set key schedule for df_key */
    			AES_set_encrypt_key(df_key, drbg->strength, &ctr->df_ks);
    
    			drbg->min_entropylen = ctr->keylen;
    			drbg->max_entropylen = DRBG_MAX_LENGTH;
    			drbg->min_noncelen = drbg->min_entropylen / 2;
    			drbg->max_noncelen = DRBG_MAX_LENGTH;
    			drbg->max_perslen = DRBG_MAX_LENGTH;
    			drbg->max_adinlen = DRBG_MAX_LENGTH;
    		} else {
    			drbg->min_entropylen = drbg->seedlen;
    			drbg->max_entropylen = drbg->seedlen;
    			/* Nonce not used */
    			drbg->min_noncelen = 0;
    			drbg->max_noncelen = 0;
    			drbg->max_perslen = drbg->seedlen;
    			drbg->max_adinlen = drbg->seedlen;
    		}
    
    		...
    	}
    

    The easiest way would be if get_entropy() would allocate a buffer of length max_entropylen and fill it with bytes until the entropy threshold has been reached. However, max_entropylen = DRBG_MAX_LENGTH is an astronomically high value. But this value is only a theoretical upper limit from the NIST document. I changed this members value to a more realistic value:

    	drbg->max_entropylen = 32 * drbg_min_entropylen    /* similar for adinlen, etc. */
    

    This corresponds to the very pessimistic estimate that the entropy of the input lies between 1/4 bits-per-byte and 8 bits-per-byte. That should be enough.

    Now in the callback, the buffer is filled until the required entropy threshold is reached. If the buffer overflows (which should never happen), get_entropy() fails. To facilitate this, I added a new "class" RAND_POOL which acts as container for this variable sized random input.

    This is my vision of how get_entropy() should be used. Even if get_entropy() pulls from /dev/urandom or other full-entropy sources, the implementers should have the freedom to return more than the requested entropy from alternative entropy sources and/or be allowed to return cumulate low entropy input.

    Summary of the pull request

    The solution is split in two parts:

    • Commit 1 fixes the entropy pushing part, i.e. drbg_add()
    • Commit 2 fixes the entropy pulling part, i.e. drbg_get_entropy(), and restores the original semantics of RAND_poll()

    This splitting is only for the moment to keep the changes overseeable and facilitate reviewing. Also, to keep things simple as long this is still WIP, I will avoid force pushing and address comments by adding new commits. I will squash the commits with a proper commit message when this goes out of WIP.

    Commit 1: Make drbg_add() reseed the RAND_DRBG immediately

    The obvious solution to use RAND_DRBG_reseed() creates a circular dependency, because now RAND_add() is involved both in pushing and pulling randomness:

    RAND_add() -> drbg_add() -> RAND_DRBG_reseed() -> get_entropy()
                           -> get_entropy_from_system() -> RAND_poll_ex() -> RAND_add()
    

    Using RAND_DRBG_generate() with additional input (generating and discarding some dummy output) instead of RAND_DRBG_reseed() does not solve the problem, because RAND_DRBG_generatE() can autoreseed occcasionally.

    Instead, we add a new function rand_drbg_add() which is identical to RAND_DRBG_reseed(), except that it does not pull fresh entropy (and consequently does not reset the reseed_counter). This function is used only by the RAND_METHOD drbg_add().

    Now the left hand side becomes:

    RAND_add() -> drbg_add() -> rand_drbg_add()
    

    The first commit breaks RAND_poll_ex(), but this function is rewritten and replaced by RAND_pool_fill() the second commit.

    Commit 2: Cutting the Gordian knot: Decouple the reseeding code from the two RNG APIs

    We do this by adding a new API for collecting entropy: The static fixed size RAND_BYTES_BUFFER is replaced by a more elaborate RAND_POOL "class" which acts as a container for collecting variable length randomness input for the derivation function.

    The functions RAND_poll() and drbg_get_entropy() manage their own instances of such a RAND_POOL object, which they allocate and pass down the stack to the function RAND_POOL_fill() (formerly: RAND_poll_ex(). Since the lifetime and scope of these RAND_POOL objects is limited to the stack frame of RAND_poll() and drbg_get_entropy(), respectively, there is no need for locking.

    Note also, that the RAND_POOL is completely decoupled from the RNG, the RAND_POOL_fill() callback has no notion which kind of RNG is reseeded from the data fed into the pool. Instead, the RAND_POOL class provides a rich API (@richsalz: no pun intended ;-) ) which appears a little oversized if one adheres to the principle that the operating system's RNG is the optimal entropy source with "full entropy" (8 bits per byte) and that it is not necessary to consider additional entropy sources or sources with lower entropy rates.

    However, if one seeks for a flexible way of mixing in various entropy resources, as requested by multiple contributers, then such an API may come in handy. Currently, its just a blueprint and proof-of-concept. It provides a set of accessors providing information to the callbacks on which they could base there decisions on how much entropy should be added from the availabe resources.

    I don't have a concept yet, how such a variable reseeding scheme could be managed and configured. But that's not part of this PR anyway. Input welcome, here or on openssl-dev.

    Remarks

    Randomness vs. Entropy

    Many occurrances of the term "entropy" have been replaced by the more vague term "randomness" only recently. Although being mathematician, I have no problems using "entropy" synonymously to "randomness" in colloquial language. So originally I considered that discussion vain.

    However, now this recent change change turns out to be really handy, because it enables me to consistently distinguish between a double randomness argument and a int entropy argument. The former is a floating point value measured in bytes, whereas the other is an integer value measured in bits and has a strict meaning in the sense of NIST SP800-90Ar1.

    int RAND_POOL_add(RAND_POOL *pool, const void *buffer, int num, double randomness)
    {
        size_t len  = (size_t)num;
        int entropy = (int)(randomness * 8.0);
        ...
    }
    

    TODO(DRBG)

    Some places where I seek particular feedback or closer review have been marked with TODO(DRBG). These TODO's need to be resolved and removed before the PR can go out of WIP.

    In particular, please have a closer look a the TODO(DRBG) comment preceding rand_drbg_add().

    Reviewing and Testing

    Since the RNG is a critical part of OpenSSL, any change to the code is like an open heart surgery. I'm not a seasoned committer and don't have the resources to test it on all platforms and under all circumstances. So I am grateful for any independent testing, in particular the DRBG chaining and forking stuff, since I a am only familiar with libcrypto and not such with libssl.

    What I tested: I successfully ran the standard tests and did a little debugging with gdb to check the main code paths:

    # global DRBG, fetching entropy from os for instantiation     (break at rbg_get_entropy)
    ./util/shlib_wrap.sh gdb --args ./apps/openssl rand -hex 32
    
    # chained DRBG, fetching entropy from parent DRBGfor instantiation   (break at drbg_get_entropy, then add breakpoint inside 'if (drbg->parent)'-clause)
    ./util/shlib_wrap.sh gdb --args ./apps/openssl s_client -host www.openssl.org -port 443
    
    # global DRBG, RAND_add()         (break at drbg_add)
    echo 'This is a random number' > /tmp/randfile
    ./util/shlib_wrap.sh gdb --args ./apps/openssl rand -hex -rand /tmp/randfile  12
    
    # test
    ./util/shlib_wrap.sh gdb --args ./test/drbgtest
    
    branch: master 
    opened by mspncp 122
  • Test 80-test_cmp_http fails at alpha17 on NonStop x86/ia64

    Test 80-test_cmp_http fails at alpha17 on NonStop x86/ia64

    This is a net-new failure compared with alpha16. Virtually every sub-test fails in this test. What information is needed to further investigate? An example:

    # ------------------------------------------------------------------------------
        #   Failed test 'p10cr csr non-existing file'
        #   at test/recipes/80-test_cmp_http.t line 147.
    Warning: certificate from 'trusted.crt' with subject '/O=openssl_cmp' is not a CA cert
    Unable to load PKCS#10 CSR
    error: unable to load PKCS#10 CSR from file 'empty.txt'
    cmp_main:/home/ituglib/randall/openssl-3.0/apps/cmp.c:2778:CMP error: cannot set up CMP context
    # cmp_main:/home/ituglib/randall/openssl-3.0/apps/cmp.c:2602:CMP info: using section(s) 'Mock enrollment' of OpenSSL configuration file '../Mock/test.cnf'
    # opt_str:/home/ituglib/randall/openssl-3.0/apps/cmp.c:2203:CMP warning: -proxy option argument is empty string, resetting option
    # setup_request_ctx:/home/ituglib/randall/openssl-3.0/apps/cmp.c:1488:CMP warning: -subject option is ignored for commands other than 'ir', 'cr', and 'kur' since -ref or -cert is given
    # setup_request_ctx:/home/ituglib/randall/openssl-3.0/apps/cmp.c:1500:CMP warning: -policies option is ignored for commands other than 'ir', 'cr', and 'kur'
    # setup_request_ctx:/home/ituglib/randall/openssl-3.0/apps/cmp.c:1536:CMP warning: -newkeytype option is ignored for 'p10cr' and 'rr' commands
    # setup_request_ctx:/home/ituglib/randall/openssl-3.0/apps/cmp.c:1538:CMP warning: -newkey option is ignored for 'p10cr' and 'rr' commands
    ../../../../util/wrap.pl ../../../../apps/openssl cmp -server '127.0.0.1:61432' -config ../Mock/test.cnf -section 'Mock enrollment' -certout ../../../../test-runs/test_cmp_http/test.cert.pem -proxy '' -no_proxy 127.0.0.1 -cmd p10cr -newkey new.key -newkeypass 'pass:' -certout ../../../../test-runs/test_cmp_http/test.certout_p10cr4.pem -out_trusted root.crt -csr empty.txt => 255
    
    branch: master triaged: bug 
    opened by rsbeckerca 121
  • Reorganize the header files

    Reorganize the header files

    Introduction

    Pull request #9274 started out as a task to clean up inconsistencies in the naming of the include guards. It got stuck when it turned out that not only the #include guards were named inconsistently, but also the header files themselves. Sometimes even the location of the header files in the source tree was inconsistent. After thinking about the problem for a while (see thread on openssl-project), this pull request is my attempt to tackle it properly by first reorganizing the header files consistently before adjusting the names of the include guards.

    Given the fact that OpenSSL 1.1.1 is an LTS version, it is desirable that the reorganization occurs both on master and OpenSSL_1_1_1-stable in order not to hinder future cherry-picking. However, it is impossible to cherry-pick the reorganization of the internal header files without conflicts. For that reason, a different approach will be followed (similar to #9274): The major part of the reorganization will be automated by a script, which has the advantage that the transformation steps are not only well documented, but also reproducible on the OpenSSL_1_1_1-stable branch.

    New include directory structure

    Shared internal header files

    Extending a suggestion by @levitte on openssl-project to move the directory crypto/include/internal => include/internal/crypto, I propose the following organization of the internally shared header files:

       Location      |     Include Directive      |       Include Guard
    =================+============================+=================================
    include          |                            |
      + openssl      | #include <openssl/file.h>  |  #ifndef OPENSSL_FILE_H
      |              |                            |
      + internal     |        = no files =        |
          |          |                            |
          + crypto   | #include "crypto/file.h"   |  #ifndef OPENSSL_CRYPTO_FILE_H
          |          |                            |
          + ssl      | #include "ssl/file.h"      |  #ifndef OPENSSL_SSL_FILE_H
          |          |                            |
          + provider | #include "provider/file.h" |  #ifndef OPENSSL_PROVIDER_FILE_H
          |          |                            |
          + ..etc..  |                            |
    

    (The complete layout still needs to be specified, this is only a draft.)

    Contrary to current practice, which has some disadvantages, the location of a header file doesn't depend on whether it is shared with other sub-systems or only within the same sub-system.

    Local internal header files

    In addition to the shared ones, there are also local header files, which reside along with the source files in the same directory. In order to avoid name collisions, their filenames have one of the suffixes *_locl.h, *_lcl.h, and *_local.h. The suffix should be unified and currently I'm favoring *_lcl.h, because it is most unix-like. But if another suffix is preferred, I'm open for change requests.

    Public header files

    Backporting the internal reorganization is possible without creating compatibility problems, only the public headers need to be treated with special care. Following a suggestion by @paulidale https://github.com/openssl/openssl/pull/9274#issuecomment-507069720, I intend to define the legacy include guard in addition to the new ones:

    include/openssl/file.h:
    
        #ifndef OPENSSL_FILE_H
        # define OPENSSL_FILE_H
        # define HEADER_FILE_H /* obsolete, will be removed in 3.0 */
        # endif
    

    This is going to ensure that applications which use the old include guards externally like this

        #ifndef HEADER_FILE_H
        # include <openssl/file.h>
        #endif
    

    won't fail to compile after the next 1.1.1 bugfix release.

    Implementation

    This pull request contains the fully functional (although not complete) script as a proof-of-concept. You can try it out yourself and do your own experiments. The script produces a lot of diagnostic output, which it saves and commits in the logfiles subdirectory, see d1b3b5b46b.

    How to use it

    If you look at the commits below, you will notice that all automated commits are labelled with [automated] and that a special reference (start-reorganize-header-files) marks the begin of the automated commits:

    d1b3b5b46b (HEAD -> pr-reorganize-header-files) Script succeeded. See 'logfiles' directory for details. [automated] cf8269b745 Add compatibility defines for public header include guards [automated; 1.1.1 only] 76f23ca923 Fix header file include guards [automated] 4fa2ba8fad Reorganize include files [automated] 4a6e4bbbcc Reorganize include files [automated] d7dba04ac7 Reorganize include files [automated] 053b2dcc6d Reorganize include files [automated] b46c754862 (start-reorganize-header-files) Add 'reorganize-header-files' script [automated] 350c9f0753 Remove OPENSSL_X509V3_H guards from cms code 6b684b9ae2 remove HEADER_BSS_FILE_C #include guard 74a6ecd2de util/mkerr.pl: use 'OPENSSL_' as include guard prefix of *err.h files 7a228c391e (origin/master, github/master, master) Replace long dash characters with normal ascii minus

    Prepare the start branch

    All you need to do before running the script yourself for the first time is to set the start-reorganize-header-files branch to the first commit marked [automated]:

    git branch start-reorganize-header-files b46c754862
    

    Run the script

    After that, all you need to do is to execute it from the root of the source tree.

    ./reorganize-header-files
    

    Prepare the start branch [1.1.1]

    The start-reorganize-header-files reference was chosen to be a branch (not a tag) on purpose. It as the advantage, that the commits master...start-reorganize-header-files can easily be rebased on master. They can even be rebased onto OpenSSL_1_1_1-stable without conflicts.

    So to try out the script on the OpenSSL_1_1_1-stable branch, rebase the starting branch start-reorganize-header-files as start-reorganize-header-files-111 onto OpenSSL_1_1_1-stable as follows:

    git checkout -b start-reorganize-header-files-111 start-reorganize-header-files
    git rebase master --onto OpenSSL_1_1_1-stable 
    

    Prepare the start branch [1.1.1]

    As soon as the start branch on 1.1.1 exists, you can apply the script there using the 111 option

    ./reorganize-header-files 111
    

    The script works regardless of which branch you are on, so from now on you can jump around freely between versions 1.1.1 and 3.0.

    Notes

    • The script will even run if you do not create the start branch. If it does not exist, it will create one on-the-fly off the master (resp. OpenSSL_1_1_1-stable) branch.
    • If you want to try out something, go ahead, make your changes and safe the script. Then run the script again (no need to commit your changes, the script will commit itself). See commit message of b46c754862 (or the script itself) for more details about the script.

    How it operates

    Step 0: Some preparations

    The script resets the pull request branch to a certain starting point. As first action, it commits itself to the branch. After that, it carries out steps 1 and 2. Having the script committed in the branch has two advantages, namely

    • The automated commits are implicitly documented by having the script available
    • the script supports being edited and reapplied to regenerate the automated commits

    All changes commited by the script are currently indicated by the [autogenerated] tag in the commit message title. This tag is for clarity and will be removed before the pull request goes out of WIP.

    Step 1: Reorganize the header files

    • Move crypto/include/internal => crypto/include/crypto (and rename the *_int.h suffixes to *.h)
    • Create additional directores include/internal/ssl, ... for other sub-systems and spread out the header files currently lying under include/internal into the appropriate sub-directory.
    • Unify the suffixes of the *_locl.h, *_lcl.h, and *_local.h

    Step 2: Adjust the header file include guards

    The includes are fixed automatically using fixed naming rules. For details, see the source code of the reorganize-header-files script and the logfiles directory.

    approval: done branch: master 
    opened by mspncp 114
  • Add EVP/KDF API

    Add EVP/KDF API

    This PR adds a new EVP/KDF API that collects all KDFs and PRFs under the one API.

    #include <openssl/kdf.h>

    Currently some KDFs are available directly (PBKDF2 and scrypt) while others are available through the PKEY API (scrypt, TLS1 PRF and HKDF) even though the PKEY API was originally intended for Public Key algorithms. Note that the low level KDF functions (PKCS5_PBKDF2_HMAC and EVP_PBE_scrypt) are defined in openssl/evp.h even though EVP is the high level interface.

    The new API is modeled after the current KDF support under the PKEY API in order to minimize the work required to update applications to use the new API. Support is included for PBKDF2, scrypt, TLS1 PRF and HKDF. PBKDF1 and PKCS12 KDF are not implemented.

    The low level KDF functions and PKEY KDF support have been changed to wrap the new API. Other parts of OpenSSL have not yet been updated to call the new API.

    Documentation to follow.

    • [x] documentation is added or updated
    • [x] tests are added or updated
    approval: done branch: master 
    opened by davidmakepeace 111
  • Support multi-prime RSA (RFC 8017)

    Support multi-prime RSA (RFC 8017)

    This feature is very useful if someone wants to reduce the cost of hardware accelerators and can ~be~ tolerate with a less security key. [This implementation is based on RFC 8017]

    Some performance data by using openssl speed: 2-prime: 7979 3-prime: 9908 5-prime: 18617 8-prime: 24878 15-prime: 31811 (quantity of RSA 2048-bit private key operations in 10s)

    Also, the generation time of 4096-bit key: 2-prime: 1.237 3-prime: 0.467 5-prime: 0.237 8-prime: 0.098 15-prime: 0.080 (in seconds)

    To be simplified, the maximum number of primes is limited to 16.

    After I finished this patch, I just found this previous work accidentally: https://rt.openssl.org/Ticket/Display.html?id=3477&user=guest&pass=guest. This is a 3 years old patch and was closed in the 'bug bankruptcy ' movement last year.

    Note: This patch might be buggy, consider it as an experimental feature. Let's focus on discussing if the feature is worth being included into master...

    Patent Caution: If I understand correctly, all related patents are expired on Jan 2017. (US5848159 and US7231040)

    • Introduce RSA_generate_multi_prime_key to generate multi-prime RSA private key. As well as the following functions: RSA_generate_multi_prime_key RSA_get_multi_prime_num RSA_get0_multi_prime_factors RSA_get0_multi_prime_crt_params RSA_set0_multi_prime_params RSA_set_version RSA_get_version
    • Support EVP operations for multi-prime RSA
    • Support ASN.1 operations for multi-prime RSA
    • Support multi-prime check in RSA_check_key_ex
    • Support multi-prime RSA in apps/genrsa and apps/speed
    • Support multi-prime RSA manipulation functions
    • Test cases and documentation are added
    Checklist
    • [x] documentation is added or updated
    • [x] tests are added or updated
    approval: done 
    opened by InfoHunter 97
  • OSSL_STORE 'file' loader: Try several pass phrase variants for PKCS#12

    OSSL_STORE 'file' loader: Try several pass phrase variants for PKCS#12

    Pass phrases for PKCS#12 objects are problematic, as our conversion to BMPString was very naïve in OpenSSL <1.1.0, and while being less so in OpenSSL >=1.1.0, it still doesn't account for the application locale.

    OSSL_STORE, on the other hand, is supposed to be fairly agnostic to the types of objects it loads, and thereby all internal intricaties concerning pass phrases. Therefore, we need to create a few variants of the given pass phrase when trying to open a PKCS#12 object, with the hope that this will work on PKCS#12 objects generated by OpenSSL <1.1.0 as well as OpenSSL >=1.1.0 as well as other software.

    While doing this, we need to make sure the locale is set correctly. Fortunately, that's a simple setlocale(LC_ALL, "").

    Ideas largely inspired by @dwmw2

    branch: master branch: 1.1.1 
    opened by levitte 96
  • OpenSSL 3.0.0-alpha6 6 Aug 2020 breaks perl Net::DNS::SEC ECDSA signature generation

    OpenSSL 3.0.0-alpha6 6 Aug 2020 breaks perl Net::DNS::SEC ECDSA signature generation

    The problem does not occur in the signing process itself. This statement fails with an exception raised in checkerr():

    	checkerr( EVP_DigestSignInit( ctx, NULL, md, NULL, pkey ) );
    
    

    Returned value is 0, not 1 as expected. Code works ok with alpha5 and all earlier releases. I have not been following the daily snapshots, so unable to be more precise.

    Problem occurs for both ECDSAP256SHA256 and ECDSAP384SHA384 signature generation. Signature verification is not affected which should rule out problems with md.

    branch: master triaged: bug triaged: OTC evaluated 
    opened by rwfranks 94
  • Outdated https://wiki.openssl.org/index.php/Command_Line_Utilities

    Outdated https://wiki.openssl.org/index.php/Command_Line_Utilities

    For instance, pkcs12 is linked to https://www.openssl.org/docs/manmaster/man1/pkcs12.html rather than to https://www.openssl.org/docs/manmaster/man1/openssl-pkcs12.html such that users obtain pretty outdated docs.

    Actually all of https://wiki.openssl.org/index.php/Command_Line_Utilities appears heavily outdated - at least a prominent caveat should be added.

    issue: bug report 
    opened by DDvO 0
  • CI: add GCC 11, GCC 12, Clang 13, Clang 14

    CI: add GCC 11, GCC 12, Clang 13, Clang 14

    Notably, this might have caught #18225, as Clang 14 wasn't - and is not yet until this PR - in OpenSSL's CI.

    It makes sense to ensure CI tests compilers used in newer Linux distributions:

    • Fedora 36 ships with GCC 12
    • Ubuntu 22.04 ships with Clang 14
    opened by thesamesam 0
  • kdf objects missing a return if malloc fails.

    kdf objects missing a return if malloc fails.

    I have searched through all references of ERR_R_MALLOC_FAILURE for any other instances..

    Noticed during random code inspection of coverage results

    Checklist
    • [ ] documentation is added or updated
    • [ ] tests are added or updated
    approval: done branch: master triaged: bug severity: fips change branch: 3.0 
    opened by slontis 0
  • Strict aliasing concerns in bss_dgram.c

    Strict aliasing concerns in bss_dgram.c

    The crypto/bio/bss_dgram.c file has a number of strict aliasing problems. There are a number of definitions of a union:

        union {
            size_t s;
            int i;
        }
    

    and a definition:

        union {
            unsigned __int64 ul;
            FILETIME ft;
        }
    

    The concern is that the address is taken of a union member and this is passed to a function. This breaks the strict aliasing rules. These instances ought to be rewritten using casts.

    branch: master good first issue triaged: bug 
    opened by paulidale 0
  • DTLS server does not respond to retransmitted

    DTLS server does not respond to retransmitted "Client Hello"

    Version: 20af01d46ca4086f6b1339b67c15c81d8b4a040d (4 commits before OpenSSL_1_1_1p)

    In order to reproduce the issue, use https://github.com/mniestroj/openssl/tree/reproduce-dtls-handshake-deadlock or just apply https://github.com/mniestroj/openssl/commit/b314ee46815c10d52c94f1f13afd67035edcb91e commit, which simulates dropping reply to first "Client Hello" packet (this means that client does not receive response to "Client Hello" and continues retransmitting it).

    $ apps/openssl s_server -dtls1_2 -accept 192.0.2.2:5684 -psk_identity [email protected] -psk 3172306e6d406e -cipher PSK-AES128-CCM8 -nocert -security_debug_verbose
    Using default temp DH parameters
    ACCEPT
    
    Security callback: Version=???: yes
    Security callback: Version=???: yes
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 0 (s->statem.hand_state 0)
    Don't send this message!
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    

    Recurring comparing msg_hdr.seq 0 ... messages are printed whenever new retransmitted "Client Hello" message is received. Unfortunately openssl treats that message as invalid. It looks like handling of retransmitted "Client Hello" is not handled correctly.

    mbedTLS based DTLS client was used, though it should be reproducible with any DTLS client.

    See that "Client Hello" messages are visible in Wireshark as well: wireshak_openssl

    This is quite severe bug, because restarting client (or starting new handshake) does not solve the issue and this means that there is persistent deadlock for such client. A workaround was developed, which seems to solve the issue: https://github.com/mniestroj/openssl/commit/18ad4353e8b5f35d05e742097e416b8d6a0d3f6d. After applying this workaround, DTLS server properly continues:

    $ apps/openssl s_server -dtls1_2 -accept 192.0.2.2:5684 -psk_identity [email protected] -psk 3172306e6d406e -cipher PSK-AES128-CCM8 -nocert -security_debug_verbose
    Using default temp DH parameters
    ACCEPT
    Security callback: Version=???: yes
    Security callback: Version=???: yes
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 0 (s->statem.hand_state 0)
    Don't send this message!
    comparing msg_hdr.seq 0 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    special case for handling Client Hello retransmit 1 21
    comparing msg_hdr.seq 1 s->d1->handshake_read_seq 1 (s->statem.hand_state 21)
    Security callback: Version=???: yes
    Security callback: : yes
    Security callback: Shared Signature Algorithm scheme=ecdsa_secp521r1_sha512, security bits=256: yes
    Security callback: Shared Signature Algorithm scheme=rsa_pkcs1_sha512, security bits=256: yes
    Security callback: Shared Signature Algorithm scheme=ecdsa_secp384r1_sha384, security bits=192: yes
    Security callback: Shared Signature Algorithm scheme=rsa_pkcs1_sha384, security bits=192: yes
    Security callback: Shared Signature Algorithm scheme=ecdsa_secp256r1_sha256, security bits=128: yes
    Security callback: Shared Signature Algorithm scheme=rsa_pkcs1_sha256, security bits=128: yes
    Security callback: Shared Signature Algorithm scheme=ecdsa_secp521r1_sha512, security bits=256: yes
    Security callback: Shared Signature Algorithm scheme=rsa_pkcs1_sha512, security bits=256: yes
    Security callback: Shared Signature Algorithm scheme=ecdsa_secp384r1_sha384, security bits=192: yes
    Security callback: Shared Signature Algorithm scheme=rsa_pkcs1_sha384, security bits=192: yes
    Security callback: Shared Signature Algorithm scheme=ecdsa_secp256r1_sha256, security bits=128: yes
    Security callback: Shared Signature Algorithm scheme=rsa_pkcs1_sha256, security bits=128: yes
    Security callback: Shared Ciphersuite=PSK-AES128-CCM8, security bits=128: yes
    comparing msg_hdr.seq 2 s->d1->handshake_read_seq 2 (s->statem.hand_state 26)
    comparing msg_hdr.seq 3 s->d1->handshake_read_seq 3 (s->statem.hand_state 31)
    -----BEGIN SSL SESSION PARAMETERS-----
    ...
    
    branch: master branch: 1.1.1 triaged: bug branch: 3.0 
    opened by mniestroj 3
A stable nginx module for SSL/TLS ja3 fingerprint, with high performance.

nginx-ssl-fingerprint A stable nginx module for SSL/TLS ja3 fingerprint, with high performance. Description This module adds new nginx variables for t

phuslu 29 Jun 14, 2022
s2n : an implementation of the TLS/SSL protocols

s2n-tls is a C99 implementation of the TLS/SSL protocols that is designed to be simple, small, fast, and with security as a priority. It is released a

Amazon Web Services 4.1k Jun 23, 2022
An open source, portable, easy to use, readable and flexible SSL library

README for Mbed TLS Mbed TLS is a C library that implements cryptographic primitives, X.509 certificate manipulation and the SSL/TLS and DTLS protocol

Arm Mbed 3.6k Jun 30, 2022
Obtain and parse SSL certificates

CheckCert A small utility to request the SSL certificate from a public or private web application. CheckCert helps operators in the following ways: It

Sanjiv Kawa 78 Jun 24, 2022
The UAPKI is crypto library for using in PKI with support of Ukrainian and internationlal cryptographic standards.

UAPKI The UAPKI is crypto library for using in PKI with support of Ukrainian and internationlal cryptographic standards. Fork from Cryptonite. Expert

null 23 May 27, 2022
A modern, portable, easy to use crypto library.

Sodium is a new, easy-to-use software library for encryption, decryption, signatures, password hashing and more. It is a portable, cross-compilable, i

Frank Denis 10.2k Jun 25, 2022
A lightweight, secure, easy-to-use crypto library suitable for constrained environments.

The Hydrogen library is a small, easy-to-use, hard-to-misuse cryptographic library. Features: Consistent high-level API, inspired by libsodium. Instea

Frank Denis 388 Jun 18, 2022
A Powerful, Easy-to-Use, Compact, Cross-Platform and Installation-Free Crypto Tool. 一个强大,易用,小巧,跨平台且免安装的加密解密签名工具。

GpgFrontend GpgFrontend is a Powerful, Easy-to-Use, Compact, Cross-Platform, and Installation-Free OpenPGP Crypto Tool. By using GpgFrontend, you can

Saturn&Eric 136 Jun 21, 2022
DARKCAT Project - A Strong Prototype Crypto-Locker

Darkcat is an Open Source Crypto-locker directed at an audience with an interest in the field of Cyber Security. The locker is similar to how very obnoxious Ransomwares operate using 2-Layer Key Encryption with the intent of making it almost impossible to recover any key from memory even during the event of Encryption.

Alexander Töpfer 29 Apr 17, 2022
inetd-style TLS encryption wrapper

Description The tlswrapper is an TLS encryption wrapper between remote client and local program prog. Is executed from systemd.socket/inetd/tcpserver/

Jan Mojžíš 2 Feb 23, 2022
Malware that replaces copied crypto addresses with yours.

Crypto-Clipper Malware which replaces copied crypto addresses with yours. ?? Features Multiple cryptos supported (BTC, LTC, ETH, DOGE, DASH, NEO, BCH,

Voltic 5 Apr 25, 2022
MIRACL Cryptographic SDK: Multiprecision Integer and Rational Arithmetic Cryptographic Library is a C software library that is widely regarded by developers as the gold standard open source SDK for elliptic curve cryptography (ECC).

MIRACL What is MIRACL? Multiprecision Integer and Rational Arithmetic Cryptographic Library – the MIRACL Crypto SDK – is a C software library that is

MIRACL 483 Jun 27, 2022
x509cert is a tool and library for generating X.509 certificates and certificate requests.

x509cert is a tool and library for generating X.509 certificates and certificate requests. It is written in C99 and uses BearSSL to decode keys and compute signatures.

Michael Forney 9 Nov 25, 2021
HashLibPlus is a recommended C++11 hashing library that provides a fluent interface for computing hashes and checksums of strings, files, streams, bytearrays and untyped data to mention but a few.

HashLibPlus HashLibPlus is a recommended C++11 hashing library that provides a fluent interface for computing hashes and checksums of strings, files,

Telepati 7 Apr 11, 2022
Library and command line tool to detect SHA-1 collision in a file

sha1collisiondetection Library and command line tool to detect SHA-1 collisions in files Copyright 2017 Marc Stevens [email protected] Distributed

Marc Stevens 1.2k Jun 24, 2022
Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse.

Tink A multi-language, cross-platform library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Ubuntu

Google 12.4k Jun 23, 2022
PTHash is a C++ library implementing fast and compact minimal perfect hash functions

Fast and compact minimal perfect hash functions in C++.

Giulio Ermanno Pibiri 65 Jun 18, 2022
Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockford's base32. MIT licensed with consistent, flexible API.

cppcodec Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockf

Topology 458 Jun 23, 2022
Mbedcrypto - a portable, small, easy to use and fast c++14 library for cryptography.

mbedcrypto mbedcrypto is a portable, small, easy to use, feature rich and fast c++14 library for cryptography based on fantastic and clean mbedtlsnote

amir zamani 37 Jun 16, 2022