Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
On 10/07/15 19:34, R C Delgado wrote: > Hello, > > One further question. Can you please confirm that the alternative > certificate chain feature is enabled by default? It seems to be implied > in all emails regarding this matter, and I'm assuming the Advisory email > would have mentioned it otherwise. Yes, it is enabled by default. Matt > > I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS > exists but is not set in the "flags" member by default when a new X509 > context is initialised. And my code does not modify the context to > include this flag. > > Please let me know if I'm missing something. > > (I'm using OpenSSL 1.0.1o) > > Many thanks, > RCD > > > > > > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ 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 Security Advisory - CVE-2015-1793
Hello, One further question. Can you please confirm that the alternative certificate chain feature is enabled by default? It seems to be implied in all emails regarding this matter, and I'm assuming the Advisory email would have mentioned it otherwise. I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS exists but is not set in the "flags" member by default when a new X509 context is initialised. And my code does not modify the context to include this flag. Please let me know if I'm missing something. (I'm using OpenSSL 1.0.1o) Many thanks, RCD > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] -Wconversion
> Is it planned to tackle the warnings, for example by checking the involved > code lines and (carefully) replace them by explicit casting to achieve clean > compiles when using stricter warnings? Yes. Timetable TBD. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] -Wconversion
Hello, I just compiled with openssl-1.0.2c with "-Wextra -Wconversion -Wno-unused-parameter" and a got many (1251) -Wconversion-related warnings. I checked few source code lines but haven't found something mentionable. Still -Wconversion-warnings can be an indicator of conversion bugs, which could affect the code correctness. Is it planned to tackle the warnings, for example by checking the involved code lines and (carefully) replace them by explicit casting to achieve clean compiles when using stricter warnings? Best regards, M.J. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Vulnerability Disclosures
Hi, I apologize if this is the wrong place for this email - it seemed to be the most suitable of the mailing lists. I wanted to suggest that when notifying of new vulnerabilities, in addition to the severity level, information is also provided about how widespread the issue is expected to be. For example, the statement might say "this high severity bug is expected to affect around 70% of cases”, or for CVE-2015-1788 it would presumably state “around 1%” as it affects only client-side uses. This would help OpenSSL users gauge whether the upcoming vulnerability is “heartbleed”-level, or less serious/widespread. Currently a wide variety of vulnerabilities are just indicated as “high” severity, which could mean anything from a relatively minor DoS affecting 5 implementations to MITM affecting all servers/browsers. Thanks, James ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Adding ECDH_METHODs to OpenSSL ?
Hello. OpenSSL already multiple operations like ECDSA_METHOD_set_sign or ECDSA_METHOD_set_sign_setup that facilitate the work of creating Engines for ECDSA operations. Could you provide a way to do the same thing with ECDH ? Or at least, providing the definition of ecdh_method in public headers, so one doesn't have to provide it « manually » when creating ECDH performing engines ? Thank you for your work, anyway. signature.asc Description: OpenPGP digital signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Old "RSA_NET" key format
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Salz, Rich > Sent: Thursday, July 09, 2015 15:29 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] Old "RSA_NET" key format > > > Because both methods confirm your prior decisions, you therefore > conclude that you were always right in the first place. > > Provably wrong. I wanted to get rid of Netware support as the first example > that comes to mind. As the second, I want to move all uses of RC4 and MD5 > to LOW strength ciphers. Neither one of those things is happening. As one of the people who complained (publicly) about the proposal to move RC4 to LOW, I have to support Rich here. He did ask about it on the list, there were complaints, and the mooted change was abandoned (at that time; it may of course come up again, which I think is reasonable). In the flurry of changes to the OpenSSL development staff and processes after Heartbleed, some people - myself included - had the impression that the team was making changes to OpenSSL too quickly, with insufficient community input. Since then I for one have come to feel that they're being more measured and careful about making those changes than I originally believed. Removing little-used, archaic features always poses some danger of breaking existing applications. However, it's also a potent way to retire technical debt and refactor other parts of the code base, making the whole easier to maintain, which is a benefit to people not using those features. It's a procedure that shouldn't be undertaken lightly, but software development is always a matter of compromises, and sometimes it's the best compromise available. -- Michael Wojcik Technology Specialist, Micro Focus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
Thank you very much. It really helps. On Fri, Jul 10, 2015 at 2:32 PM, Matt Caswell wrote: > > > On 10/07/15 13:09, R C Delgado wrote: > > Hello, > > > > With regards to CVE-2015-1793, I've seen the example in > verify_extra_test.c. > > How deep does the certificate chain have to be? > > If I have 2 self-signed CA certificates, and a non-CA certificate is > > received for verification, will this hit the problem? > > > > Also, is it a condition of the bug that both CA certificates have to > > have the same subject names and keys, as suggested in the file? > > > The conditions for triggering the bug are a little complicated, but I'll > do my best to explain it. > > Under normal circumstances things work as follows: > > We are provided with a certificate to verify from a remote peer. Lets > call the certificate we are trying to verify Leaf. > As well as Leaf that has been provided from the remote peer, they also > supply us with a set of untrusted certs. > Finally we also have a store of trusted certs. > > OpenSSL will first attempt to build a certificate chain. The chain > building works as follows (much simplified): > > 1. Set Leaf as the top of the chain > 2. Look for the issuer of the cert at the top of the chain from within > the untrusted set. If we find it add it to the top of the chain > 3. Repeat (2) until we can't find any more certs from the untrusted set > 4. Look for the issuer of the top of the chain from the set of trusted > certs > 5. Repeat (4) until we can't find any more certs from the trusted set > > If we've found a valid chain with a trusted self signed cert at the top, > then we stop there. If not, then we continue to look to see if there is > an alternative chain that can be built. This works as follows: > > Pop all the trusted certs off the top of the chain, then start popping > the untrusted certs off. Each time we pop an untrusted cert off start > the chain building again from step 4. > > The bug occurs when during the initial chain building: > 1) We have added at least one cert from the untrusted set > 2) We have added at least one cert from the trusted store > > For 1.0.2 there is the additional condition: > 3) After doing (1) and (2) above we do not have a valid chain > > Finally (for both 1.0.1 and 1.0.2) > 4) After popping off at least one untrusted cert from the chain we can > build an alternative valid chain > > Under the above conditions the end entity cert Leaf could "issue" a new > certificate even though it is not supposed to (I'll call that invalid > certificate "Bad"). > > So these certs would need to be present (at a minimum): > > Chain 1: > > Trusted Cert 1 > | > Untrusted Cert 1 > | > Leaf > | > Bad > > Chain 2: > > Trusted Cert 2 > | > Leaf > | > Bad > > There are other possible longer chains, but this is the minimum set. For > 1.0.2, Chain 1 would have to be non-trusted, even though we have added a > trusted cert. This can occur if Trusted Cert 1 is not self signed and > its issuer is not in the trusted store. For 1.0.1 any chain will do. > Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers > of Leaf (i.e. they have the same subject names and public keys). Chain 2 > must be trusted (so Trusted Cert 2 has to be a self-signed root). > > Matt > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
On 07/10/2015 09:32 AM, Matt Caswell wrote: On 10/07/15 13:09, R C Delgado wrote: Hello, With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. How deep does the certificate chain have to be? If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? The conditions for triggering the bug are a little complicated, but I'll do my best to explain it. So these certs would need to be present (at a minimum): Chain 1: Trusted Cert 1 | Untrusted Cert 1 | Leaf | Bad Chain 2: Trusted Cert 2 | Leaf | Bad There are other possible longer chains, but this is the minimum set. For 1.0.2, Chain 1 would have to be non-trusted, even though we have added a trusted cert. This can occur if Trusted Cert 1 is not self signed and its issuer is not in the trusted store. For 1.0.1 any chain will do. Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers of Leaf (i.e. they have the same subject names and public keys). Chain 2 must be trusted (so Trusted Cert 2 has to be a self-signed root). Thanks, Matt. This is the most cogent explanation I've seen to date. Cheers -- Lewis - Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLCwww.2rosenthals.com visit my IT blogwww.2rosenthals.net/wordpress IRS Circular 230 Disclosure applies see www.2rosenthals.com - ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
On 10/07/15 13:09, R C Delgado wrote: > Hello, > > With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. > How deep does the certificate chain have to be? > If I have 2 self-signed CA certificates, and a non-CA certificate is > received for verification, will this hit the problem? > > Also, is it a condition of the bug that both CA certificates have to > have the same subject names and keys, as suggested in the file? The conditions for triggering the bug are a little complicated, but I'll do my best to explain it. Under normal circumstances things work as follows: We are provided with a certificate to verify from a remote peer. Lets call the certificate we are trying to verify Leaf. As well as Leaf that has been provided from the remote peer, they also supply us with a set of untrusted certs. Finally we also have a store of trusted certs. OpenSSL will first attempt to build a certificate chain. The chain building works as follows (much simplified): 1. Set Leaf as the top of the chain 2. Look for the issuer of the cert at the top of the chain from within the untrusted set. If we find it add it to the top of the chain 3. Repeat (2) until we can't find any more certs from the untrusted set 4. Look for the issuer of the top of the chain from the set of trusted certs 5. Repeat (4) until we can't find any more certs from the trusted set If we've found a valid chain with a trusted self signed cert at the top, then we stop there. If not, then we continue to look to see if there is an alternative chain that can be built. This works as follows: Pop all the trusted certs off the top of the chain, then start popping the untrusted certs off. Each time we pop an untrusted cert off start the chain building again from step 4. The bug occurs when during the initial chain building: 1) We have added at least one cert from the untrusted set 2) We have added at least one cert from the trusted store For 1.0.2 there is the additional condition: 3) After doing (1) and (2) above we do not have a valid chain Finally (for both 1.0.1 and 1.0.2) 4) After popping off at least one untrusted cert from the chain we can build an alternative valid chain Under the above conditions the end entity cert Leaf could "issue" a new certificate even though it is not supposed to (I'll call that invalid certificate "Bad"). So these certs would need to be present (at a minimum): Chain 1: Trusted Cert 1 | Untrusted Cert 1 | Leaf | Bad Chain 2: Trusted Cert 2 | Leaf | Bad There are other possible longer chains, but this is the minimum set. For 1.0.2, Chain 1 would have to be non-trusted, even though we have added a trusted cert. This can occur if Trusted Cert 1 is not self signed and its issuer is not in the trusted store. For 1.0.1 any chain will do. Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers of Leaf (i.e. they have the same subject names and public keys). Chain 2 must be trusted (so Trusted Cert 2 has to be a self-signed root). Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
>How deep does the certificate chain have to be? It does not matter. >If I have 2 self-signed CA certificates, and a non-CA certificate is received >for verification, will this hit the problem? >Also, is it a condition of the bug that both CA certificates have to have the >same subject names and keys, as suggested in the file? I think you are confused. The bug is not about CA's. It's about a non-CA fooling the runtime into treating it as if it were a CA and being able to issue a certificate. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory - CVE-2015-1793
Hello, With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. How deep does the certificate chain have to be? If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? Many thanks for your help. RCD ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Transferring SSL Connections from one process to another.
Hi, I have been trying to transfer SSL connections (that are in accept state with handshake completed and some data already sent/received prior to the transfer) from one process to another so that it would allow me to seamlessly receive and send over the SSL connection (from an SSL Client) once it has been transferred to the new process. Let me try to explain what I did to achieve this. 1) Created a UNIX domain socket pair between the two processes. 2) Transferred the socket descriptors from one process to another (used sendmsg and recvmsg APIs for this) 3) Retrieved the SSL_SESSION from SSL structure instance and converted this to a sequence of bytes using the OpenSSL API "i2d_SSL_Session". Sent this information from the first process using the sendmsg API (and received at the other process using the recvmsg API). 4) Converted the raw bytes to SSL_SESSION using the OpenSSL API "d2i_SSL_Session". 5) On the new process instead of doing a handshake (using the OpenSSL API SSL_do_handshake), I first set the session to the SSL_CTX structure instance using the API SSL_CTX_add_session and then set the session on on the SSL structure (by calling SSL_new with the context) instance using SSL_set_session. 6) Finally added read & write events for the socket descriptor and set the read and write handlers appropriately (to read and write plain text data). Used epoll mechanism to do so. I was able to transfer the TCP connections across the processes (confirmed by sending data over the passed over TCP Connection). However when i tried sending data (using openssl s_client) over this SSL connection it gave me the following errors followed by a close notify. 1) Got the following error when a stream cipher (RC4SHA) was used. *SSL3 alert write:fatal:decode error* *3074365640:error:1408F0A0:SSL routines:SSL3_GET_RECORD:length too short:s3_pkt.c:445* 2) Got a "decryption failed" error when a block cipher was used. I do not have the entire error description with me right now. I am not sure why I received this error. Could you help me out with the following queries? 1) Have I missed out something that I should have done to transfer SSL connections from one process to another? Is it possible to do so in the first place? If so, could you let me know how? 2) The API documentation for SSL_set_session says that it is only useful for SSL/TLS clients. I am not sure what this means. Can i use it on SSL Connections at the server side? Is it that this API can only be used to cache sessions and resume the SSL sessions at a later point in time. Regards, Sudarshan ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
