- 11 3月, 2021 1 次提交
-
-
由 mamingshuai 提交于
-
- 09 9月, 2020 1 次提交
-
-
由 wenjun 提交于
-
- 17 3月, 2020 2 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NPaul Yang <kaishen.yy@antfin.com> (Merged from https://github.com/openssl/openssl/pull/11344)
-
由 Ben Kaduk 提交于
We have no need for a new set of SSL_CTXs in test_ccs_change_cipher(), so just keep using the original ones. Also, fix a typo in a comment. [extended tests] Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11336) (cherry picked from commit b3e6d666e351d45e93d29fe3813245b92a0f5815)
-
- 14 3月, 2020 1 次提交
-
-
由 Benjamin Kaduk 提交于
The TLS (pre-1.3) ChangeCipherState message is usually used to indicate the switch from the unencrypted to encrypted part of the handshake. However, it can also be used in cases where there is an existing session (such as during resumption handshakes) or when changing from one cipher to a different one (such as during renegotiation when the cipher list offered by the client has changed). This test serves to exercise such situations, allowing us to detect whether session objects are being modified in cases when they must remain immutable for thread-safety purposes. Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10943) (cherry picked from commit 3cd14e5e65011660ad8e3603cf871c8366b565fd)
-
- 11 3月, 2020 2 次提交
-
-
由 Matt Caswell 提交于
This reverts commit b98efebe. Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11282)
-
由 Matt Caswell 提交于
This reverts commit 68436f0a. The OMC did not vote in favour of backporting this to 1.1.1, so this change should be reverted. Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11282)
-
- 27 2月, 2020 1 次提交
-
-
由 h00416433 提交于
Description:openssl 1.1.1d used bu libhapverify Team:OTHERS Feature or Bugfix:Feature Binary Source:Yes, it is PrivateCode(Yes/No):No Change-Id: I8968f9c0f146b587da17a3e603bd04fb7b4c505b Reviewed-on: http://mgit-tm.rnd.huawei.com/7842784Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com> Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com> Reviewed-by: Nlinyibin 00246405 <linyibin@huawei.com> Reviewed-by: Nweiping 00548480 <ping.wei@huawei.com>
-
- 16 2月, 2020 2 次提交
-
-
由 Kurt Roeckx 提交于
Signature algorithms not using an MD weren't checked that they're allowed by the security level. Reviewed-by: NTomáš Mráz <tmraz@fedoraproject.org> GH: #11062
-
由 Kurt Roeckx 提交于
Create a whole chain of Ed488 certificates so that we can use it at security level 4 (192 bit). We had an 2048 bit RSA (112 bit, level 2) root sign the Ed488 certificate using SHA256 (128 bit, level 3). Reviewed-by: NMatt Caswell <matt@openssl.org> GH: #10785 (cherry picked from commit 77c4d3972400adf1bcb76ceea359f5453cc3e8e4)
-
- 12 2月, 2020 1 次提交
-
-
由 Matt Caswell 提交于
The hostname_cb in sslapitest.c was originally only defined if TLSv1.3 was enabled. A recently added test now uses this unconditionally, so we move the function implementation earlier in the file, and always compile it in. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11014) (cherry picked from commit 104a733df65dfd8c3dd110de9bd56f6ebfc8f2f6)
-
- 06 2月, 2020 3 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Fixes #10998 Reviewed-by: NShane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11000)
-
由 Kurt Roeckx 提交于
Reviewed-by: NViktor Dukhovni <viktor@openssl.org> GH: #10786 (cherry picked from commit b744f915ca8bb37631909728dd2529289bda8438)
-
由 Kurt Roeckx 提交于
Reviewed-by: NViktor Dukhovni <viktor@openssl.org> GH: #10786 (cherry picked from commit 4d9e8c95544d7a86765e6a46951dbe17b801875a)
-
- 31 1月, 2020 1 次提交
-
-
由 Matt Caswell 提交于
Test this on both the client and the server after a normal handshake, and after a resumption handshake. We also test what happens if an inconsistent SNI is set between the original handshake and the resumption handshake. Finally all of this is also tested in TLSv1.2 and TLSv1.3. Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/10018) (cherry picked from commit 49ef3d0719f132629ab76d4bcb4ab0c1e016277a)
-
- 25 1月, 2020 2 次提交
-
-
由 Kurt Roeckx 提交于
TLS < 1.2 has fixed signature algorithms: MD5+SHA1 for RSA and SHA1 for the others. TLS 1.2 sends a list of supported ciphers, but allows not sending it in which case SHA1 is used. TLS 1.3 makes sending the list mandatory. When we didn't receive a list from the client, we always used the defaults without checking that they are allowed by the configuration. Reviewed-by: NPaul Dale <paul.dale@oracle.com> GH: #10784 (cherry picked from commit b0031e5dc2c8c99a6c04bc7625aa00d3d20a59a5)
-
由 Kurt Roeckx 提交于
It replaces apps/server.pem that used a sha1 signature with a copy of test/certs/servercert.pem that is uses sha256. This caused the dtlstest to start failing. It's testing connection sbetween a dtls client and server. In particular it was checking that if we drop a record that the handshake recovers and still completes successfully. The test iterates a number of times. The first time through it drops the first record. The second time it drops the second one, and so on. In order to do this it has a hard-coded value for the expected number of records it should see in a handshake. That's ok because we completely control both sides of the handshake and know what records we expect to see. Small changes in message size would be tolerated because that is unlikely to have an impact on the number of records. Larger changes in message size however could increase or decrease the number of records and hence cause the test to fail. This particular test uses a mem bio which doesn't have all the CTRLs that the dgram BIO has. When we are using a dgram BIO we query that BIO to determine the MTU size. The smaller the MTU the more fragmented handshakes become. Since the mem BIO doesn't report an MTU we use a rather small default value and get quite a lot of records in our handshake. This has the tendency to increase the likelihood of the number of records changing in the test if the message size changes. It so happens that the new server certificate is smaller than the old one. AFAICT this is probably because the DNs for the Subject and Issuer are significantly shorter than previously. The result is that the number of records used to transmit the Certificate message is one less than it was before. This actually has a knock on impact for subsequent messages and how we fragment them resulting in one less ServerKeyExchange record too (the actual size of the ServerKeyExchange message hasn't changed, but where in that message it gets fragmented has). In total the number of records used in the handshake has decreased by 2 with the new server.pem file. Reviewed-by: NPaul Dale <paul.dale@oracle.com> GH: #10784 (cherry picked from commit 5fd72d96a592c3c4ef28ff11c6ef334a856b0cd1)
-
- 21 1月, 2020 1 次提交
-
-
由 Bernd Edlinger 提交于
Configure creates an empty crypto/include which gets not cleaned up with make distclean. Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/10893)
-
- 07 1月, 2020 1 次提交
-
-
由 Matt Caswell 提交于
The HMAC_CTX structure stores the original key in case the ctx is reused without changing the key. However, HMAC_Init_ex() checks its parameters such that the only code path where the stored key is ever used is in the case where HMAC_Init_ex is called with a NULL key and an explicit md is provided which is the same as the md that was provided previously. But in that case we can actually reuse the pre-digested key that we calculated last time, so we can refactor the code not to use the stored key at all. With that refactor done it is no longer necessary to store the key in the ctx at all. This means that long running ctx's will not keep the key in memory for any longer than required. Note though that the digested key *is* still kept in memory for the duration of the life of the ctx. Fixes #10743 Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10763)
-
- 23 12月, 2019 1 次提交
-
-
由 Matt Caswell 提交于
The new DH test in evp_extra_test.c broke the no-dh build so we add some guards to fix it. Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/10644) (cherry picked from commit 501fcfb8cfc1aa114ffde437039c2dc2827554ae)
-
- 16 12月, 2019 1 次提交
-
-
由 Matt Caswell 提交于
Provide a test to check tat when we assign a DH object we know whether we are dealing with PKCS#3 or X9.42 DH keys. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10593) (cherry picked from commit e295de1d8433ed07092845cb6c56aa424ff35c6d)
-
- 06 12月, 2019 1 次提交
-
-
由 Bernd Edlinger 提交于
[extended tests] Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10575)
-
- 29 11月, 2019 1 次提交
-
-
由 Matt Caswell 提交于
Issue #8675 describes a problem where calling EVP_DecryptUpdate() with an empty chunk causes the result to be different compared to if you do not use an empty chunk. This adds a test for that case. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9057)
-
- 20 11月, 2019 1 次提交
-
-
由 Patrick Steuer 提交于
In addition to 67c81ec3 which introduced this behavior in CCM mode docs but only implemented it for AES-CCM. Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10331) (cherry picked from commit f7382fbbd846dd3bdea6b8c03b6af22faf0ab94f) Conflicts: test/recipes/30-test_evp_data/evpciph.txt
-
- 15 11月, 2019 1 次提交
-
-
由 Patrick Steuer 提交于
Avoid conflicts with some linkers. Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10439) (cherry picked from commit e74b5dcf16dfd7c91d9f9a7e69c447f00d778e17) Conflicts: test/build.info
-
- 14 11月, 2019 1 次提交
-
-
由 Nicola Tuveri 提交于
Adds tests for each curve to ensure that encodings obtained through EC_POINT_hex2point() can be fed to EC_POINT_point2hex() yielding a point identical to the one from which the encoding is generated. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10329) (cherry picked from commit 35ed029b5a488924890fda2487c87f664361a33b)
-
- 13 11月, 2019 1 次提交
-
-
由 Nicola Tuveri 提交于
https://github.com/openssl/openssl/issues/10224#issuecomment-546593113 highlighted that existing testing infrastructure is not covering common usage patterns of the `req` app. This commit explicitly adds request generations thorugh the CLI using RSA, DSA and ECDSA (P-256) keys. (cherry picked from commit b2a7310af0dd190712bae2e462a7708483dd4628) Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10369)
-
- 10 11月, 2019 1 次提交
-
-
由 Patrick Steuer 提交于
Appease -Wstring-plus-int. Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9608) (cherry picked from commit e0249827b3fa81ff6c59fb14ef85d38361dd5e31)
-
- 08 11月, 2019 1 次提交
-
-
由 z00416851 提交于
Description:openssl开源社区安全补丁 Team:EMUI Feature or Bugfix:Feature Binary Source:NA PrivateCode(Yes/No):No Change-Id: Ia942e70461a3a5337de001ab0f40604776fe8f91 Reviewed-on: http://mgit-tm.rnd.huawei.com/6664137Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com> Reviewed-by: Nyanglijun 00294367 <yanglijun@huawei.com> Reviewed-by: Nluomeiling 00216346 <luomeiling@huawei.com> Reviewed-by: Nshenchunlong 00356424 <shenchunlong@huawei.com>
-
- 02 11月, 2019 1 次提交
-
-
由 Christian Heimes 提交于
Signed-off-by: NChristian Heimes <christian@python.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6553) (cherry picked from commit 132b5facf8d681db5dfa45828d8b02f1bf5df64b)
-
- 17 10月, 2019 1 次提交
-
-
由 Cesar Pereida Garcia 提交于
This commit adds testing and Known Answer Tests (KATs) to OpenSSL for the `BN_gcd` function. (cherry picked from commit b75d6310857bc44ef2851bde68a1979c18bb4807) Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10122)
-
- 15 10月, 2019 1 次提交
-
-
由 Pauli 提交于
The output format now matches coreutils *dgst tools. [ edited to remove trailing white space ] Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (cherry picked from commit f3448f5481a8d1f6fbf5fd05caaca229af0b87f7) Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/10094)
-
- 28 9月, 2019 3 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Make the include guards consistent by renaming them systematically according to the naming conventions below The public header files (in the 'include/openssl' directory) are not changed in 1.1.1, because it is a stable release. For the private header files files, the guard names try to match the path specified in the include directives, with all letters converted to upper case and '/' and '.' replaced by '_'. An extra 'OSSL_' is added as prefix. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
由 Dr. Matthias St. Pierre 提交于
Apart from public and internal header files, there is a third type called local header files, which are located next to source files in the source directory. Currently, they have different suffixes like '*_lcl.h', '*_local.h', or '*_int.h' This commit changes the different suffixes to '*_local.h' uniformly. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
由 Dr. Matthias St. Pierre 提交于
Currently, there are two different directories which contain internal header files of libcrypto which are meant to be shared internally: While header files in 'include/internal' are intended to be shared between libcrypto and libssl, the files in 'crypto/include/internal' are intended to be shared inside libcrypto only. To make things complicated, the include search path is set up in such a way that the directive #include "internal/file.h" could refer to a file in either of these two directoroes. This makes it necessary in some cases to add a '_int.h' suffix to some files to resolve this ambiguity: #include "internal/file.h" # located in 'include/internal' #include "internal/file_int.h" # located in 'crypto/include/internal' This commit moves the private crypto headers from 'crypto/include/internal' to 'include/crypto' As a result, the include directives become unambiguous #include "internal/file.h" # located in 'include/internal' #include "crypto/file.h" # located in 'include/crypto' hence the superfluous '_int.h' suffixes can be stripped. The files 'store_int.h' and 'store.h' need to be treated specially; they are joined into a single file. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
- 10 9月, 2019 2 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9847)
-
由 Dr. Matthias St. Pierre 提交于
When the new OpenSSL CSPRNG was introduced in version 1.1.1, it was announced in the release notes that it would be fork-safe, which the old CSPRNG hadn't been. The fork-safety was implemented using a fork count, which was incremented by a pthread_atfork handler. Initially, this handler was enabled by default. Unfortunately, the default behaviour had to be changed for other reasons in commit b5319bdb, so the new OpenSSL CSPRNG failed to keep its promise. This commit restores the fork-safety using a different approach. It replaces the fork count by a fork id, which coincides with the process id on UNIX-like operating systems and is zero on other operating systems. It is used to detect when an automatic reseed after a fork is necessary. To prevent a future regression, it also adds a test to verify that the child reseeds after fork. CVE-2019-1549 Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9802)
-
- 09 9月, 2019 3 次提交
-
-
由 Billy Brumley 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/9821) (cherry picked from commit 1d3cd983f56e0a580ee4216692ee3c9c7bf14de9)
-
由 Nicola Tuveri 提交于
(cherry picked from commit 65936a56461fe09e8c81bca45122af5adcfabb00) Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9813)
-
由 Nicola Tuveri 提交于
Description ----------- Upon `EC_GROUP_new_from_ecparameters()` check if the parameters match any of the built-in curves. If that is the case, return a new `EC_GROUP_new_by_curve_name()` object instead of the explicit parameters `EC_GROUP`. This affects all users of `EC_GROUP_new_from_ecparameters()`: - direct calls to `EC_GROUP_new_from_ecparameters()` - direct calls to `EC_GROUP_new_from_ecpkparameters()` with an explicit parameters argument - ASN.1 parsing of explicit parameters keys (as it eventually ends up calling `EC_GROUP_new_from_ecpkparameters()`) A parsed explicit parameter key will still be marked with the `OPENSSL_EC_EXPLICIT_CURVE` ASN.1 flag on load, so, unless programmatically forced otherwise, if the key is eventually serialized the output will still be encoded with explicit parameters, even if internally it is treated as a named curve `EC_GROUP`. Before this change, creating any `EC_GROUP` object using `EC_GROUP_new_from_ecparameters()`, yielded an object associated with the default generic `EC_METHOD`, but this was never guaranteed in the documentation. After this commit, users of the library that intentionally want to create an `EC_GROUP` object using a specific `EC_METHOD` can still explicitly call `EC_GROUP_new(foo_method)` and then manually set the curve parameters using `EC_GROUP_set_*()`. Motivation ---------- This has obvious performance benefits for the built-in curves with specialized `EC_METHOD`s and subtle but important security benefits: - the specialized methods have better security hardening than the generic implementations - optional fields in the parameter encoding, like the `cofactor`, cannot be leveraged by an attacker to force execution of the less secure code-paths for single point scalar multiplication - in general, this leads to reducing the attack surface Check the manuscript at https://arxiv.org/abs/1909.01785 for an in depth analysis of the issues related to this commit. It should be noted that `libssl` does not allow to negotiate explicit parameters (as per RFC 8422), so it is not directly affected by the consequences of using explicit parameters that this commit fixes. On the other hand, we detected external applications and users in the wild that use explicit parameters by default (and sometimes using 0 as the cofactor value, which is technically not a valid value per the specification, but is tolerated by parsers for wider compatibility given that the field is optional). These external users of `libcrypto` are exposed to these vulnerabilities and their security will benefit from this commit. Related commits --------------- While this commit is beneficial for users using built-in curves and explicit parameters encoding for serialized keys, commit b783beeadf6b80bc431e6f3230b5d5585c87ef87 (and its equivalents for the 1.0.2, 1.1.0 and 1.1.1 stable branches) fixes the consequences of the invalid cofactor values more in general also for other curves (CVE-2019-1547). The following list covers commits in `master` that are related to the vulnerabilities presented in the manuscript motivating this commit: - d2baf88c43 [crypto/rsa] Set the constant-time flag in multi-prime RSA too - 311e903d84 [crypto/asn1] Fix multiple SCA vulnerabilities during RSA key validation. - b783beeadf [crypto/ec] for ECC parameters with NULL or zero cofactor, compute it - 724339ff44 Fix SCA vulnerability when using PVK and MSBLOB key formats Note that the PRs that contributed the listed commits also include other commits providing related testing and documentation, in addition to links to PRs and commits backporting the fixes to the 1.0.2, 1.1.0 and 1.1.1 branches. This commit includes a partial backport of https://github.com/openssl/openssl/pull/8555 (commit 8402cd5f75f8c2f60d8bd39775b24b03dd8b3b38) for which the main author is Shane Lontis. Responsible Disclosure ---------------------- This and the other issues presented in https://arxiv.org/abs/1909.01785 were reported by Cesar Pereida García, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya and Billy Bob Brumley from the NISEC group at Tampere University, FINLAND. The OpenSSL Security Team evaluated the security risk for this vulnerability as low, and encouraged to propose fixes using public Pull Requests. _______________________________________________________________________________ Co-authored-by: NShane Lontis <shane.lontis@oracle.com> (Backport from https://github.com/openssl/openssl/pull/9808) Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9809)
-