Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
>>> In fact, I thought that was the reason we all >>> had to wait ages before this long standing shortcoming >>> was fixed. >> >> It almost sound like you are complaining you did not have to wait ages :) > > It's the inconsistency of first insisting this cannot go > into a patch and then pushing out a broken implementation > inside a patch which was only supposed to fix security > and build issues. OK.. so that's a legitimate gripe. OpenSSL has opportunities for improvements in their testing and release process. There is ***absolutely no reason a patch should not be tested before being released. Its been a chronic problem with the project. For what its worth, I've given up on the Testing Group (https://groups.google.com/forum/#!forum/openssl-testing). No meaningful change came from it. The devs are still undisciplined in this area, and they still do what they want. Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
On 10/07/2015 23:03, Jeffrey Walton wrote: During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. Why was this introduced in a patch release? I thought improved chain building was a new feature, and thus delineated by a library version number such as 1.0.2 or 1.0.3 . I *think* "improved" chain building should have present in the library earlier. The methods always exited. See, for example, 4158, https://www.ietf.org/rfc/rfc4158.txt. Here's a real world failure due to previous, "naive" path building: https://groups.google.com/d/msg/mailing.openssl.users/72_VQJmCmCU/hUMtemRNvRoJ. The CA re-issued a root by changing the hash and serial number, but recertifying the same public key and DN. Then, the server sent the old root too as an intermediate. So there were two roots available, each with the same DN. In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. It almost sound like you are complaining you did not have to wait ages :) It's the inconsistency of first insisting this cannot go into a patch and then pushing out a broken implementation inside a patch which was only supposed to fix security and build issues. This is the kind of event which has caused many dists to cherry pickindividual changes rather than just following the official releases. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
> During certificate verification, OpenSSL (starting from version 1.0.1n and > 1.0.2b) will attempt to find an alternative certificate chain if the first > attempt to build such a chain fails. An error in the implementation of this > logic can mean that an attacker could cause certain checks on untrusted > certificates to be bypassed, such as the CA flag, enabling them to use a > valid > leaf certificate to act as a CA and "issue" an invalid certificate. > > Why was this introduced in a patch release? I thought > improved chain building was a new feature, and thus > delineated by a library version number such as 1.0.2 or > 1.0.3 . I *think* "improved" chain building should have present in the library earlier. The methods always exited. See, for example, 4158, https://www.ietf.org/rfc/rfc4158.txt. Here's a real world failure due to previous, "naive" path building: https://groups.google.com/d/msg/mailing.openssl.users/72_VQJmCmCU/hUMtemRNvRoJ. The CA re-issued a root by changing the hash and serial number, but recertifying the same public key and DN. Then, the server sent the old root too as an intermediate. So there were two roots available, each with the same DN. > In fact, I thought that was the reason we all > had to wait ages before this long standing shortcoming > was fixed. It almost sound like you are complaining you did not have to wait ages :) Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
On 09/07/15 22:46, Jakob Bohm wrote: > On 09/07/2015 15:10, OpenSSL wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> OpenSSL Security Advisory [9 Jul 2015] >> === >> >> Alternative chains certificate forgery (CVE-2015-1793) >> == >> >> Severity: High >> >> During certificate verification, OpenSSL (starting from version 1.0.1n and >> 1.0.2b) will attempt to find an alternative certificate chain if the first >> attempt to build such a chain fails. An error in the implementation of this >> logic can mean that an attacker could cause certain checks on untrusted >> certificates to be bypassed, such as the CA flag, enabling them to use a >> valid >> leaf certificate to act as a CA and "issue" an invalid certificate. > Why was this introduced in a patch release? I thought > improved chain building was a new feature, and thus > delineated by a library version number such as 1.0.2or > 1.0.3. In fact, I thought that was the reason we all > had to wait ages before this long standing shortcoming > was fixed. Is it a new feature or a defect fix? On the one hand OpenSSL has never been able to handle alternative certificate chains. If the first chain attempted fails to verify then we stop. Its always been done that way and from that point of view the ability to handle alternative cert chains is a new feature. On the other hand, from a users perspective, if you present OpenSSL with a perfectly valid certificate, and a perfectly valid trust store, then you expect it to successfully verify the certificate no matter what. OpenSSL was failing to do that, and therefore this would suggest it is a defect. My initial view was the former. This issue was raised a number of times within RT and on the openssl-dev list and also via other routes. It was clearly causing real problems for end users (and increasingly so). There was much discussion on this topic, but ultimately the decision was taken to change our mind, and treat it as a defect. For that reason it was included in a patch release. >> This issue will impact any application that verifies certificates including >> SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. > Does this vulnerability also affect applications that > use OpenSSL or the openssl command line to handle S/MIME > or other CMS messages? Yes. Ultimately it affects all applications that verify certificates. That includes the openssl command line applications. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
On 09/07/2015 15:10, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. Why was this introduced in a patch release? I thought improved chain building was a new feature, and thus delineated by a library version number such as 1.0.2or 1.0.3. In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. Does this vulnerability also affect applications that use OpenSSL or the openssl command line to handle S/MIME or other CMS messages? For example, the mail client mutt handles S/MIME by invoking the openssl command line via macros in the default configuration file. P.S. Sorry for first trying to send to -announce, MUA must have ignored the Reply-To. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S.http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
