[openssl-users] FIPS 140-2, a game of chance
If you don't know or care what FIPS 140-2 is, trash this message quickly before it harshes your mellow. The "RE" validation, an "Alternative Scenario 1A" clone of the #1747 validation, was approved today (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2473). It was submitted along with its identical twin "RE" validation on April 17. The two sets of paperwork differed in only one trivial aspect, "RE" in the module name for one versus "SE" for the other. Same module, same test lab, same paperwork, submitted together at the same time. We could not have devised a more perfect controlled study if we'd tried. The "SE" validation was approved on June 25 (#2398), after a little more than two months (69 calendar days, 48 working days). The "RE" validation was not approved for almost seven months (210 calendar days, 145 working days). That's three times as long for the exact same submission. I've had the experience for years now of doing very similar validation submissions and noting very different outcomes, but this is the most striking example yet of CMVP capriciousness. Why the wild disparity? Well, probably because the two identical submissions were farmed out to two different reviewers. The review process is notoriously subjective, and in fact we received "comments" (requirements for changes) for the "RE" validation whereas the "SE" one was approved as-is. As a result the two Security Policy documents are no longer identical. That doesn't explain the time discrepancy, though, as those "comments" weren't received until long after "SE" had been approved. The moral here is that FIPS 140-2 validations are a crapshoot; it's impossible to make any reliable predictions on how long any validation action will take or how it will be received. If you have really deep pockets you can submit the same validation multiple times to hedge your bets (we've actually done that[1]), but for most of us it's an open ended gamble: submit, hope, wait, ... -Steve M. [1] See http://veridicalsystems.com/blog/the-fickleness-of-fips/; note that dual submission did pay off for that client. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ECDHE Negotiation for Client but not Server
Sorted; needed to call SSL_CTX_set_tmp_ecdh with my private EC_KEY. Can someone express an opinion if using my private key is acceptable there, or if I should generate a new one from a named curve each time I create a context? Cheers, --B On Fri, Nov 13, 2015 at 11:21 AM, Benn Bollay wrote: > Hi folks - > > Tested against OpenSSL 1.0.1f and 1.0.1p (but with modifications). > > I've got some code that creates an SSL_CTX (http://pastebin.com/XveDvvch) > that works fine for negotiating ECDHE-* ciphers as a client when talking to > an s_server, but fails as a server both when accepting connections from > itself or from s_client with a no shared cipher error. > > You can download a full package to reproduce the issue at > http://www.magitech.org/gambit/ecdhetest.tar.gz > > You can run the test by using make: > > $ make all > > $ make s_server & # Run’s OpenSSL s_server in the background > > $ make t_client # Runs the client - should be able to see the handshake > complete on the server’s log window. > > $ make t_server & # After killing the s_server, start up the test server > > $ make s_client # Fails to negotiate. > > Any suggestions? > Cheers, > --B > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Does openssl server always choose highest TLS version offered?
> Rfc5246 basically says that the server will choose the highest version but I > wanted to confirm that that's what openssl does (just to be certain). That is what openssl does. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] ECDHE Negotiation for Client but not Server
Hi folks - Tested against OpenSSL 1.0.1f and 1.0.1p (but with modifications). I've got some code that creates an SSL_CTX (http://pastebin.com/XveDvvch) that works fine for negotiating ECDHE-* ciphers as a client when talking to an s_server, but fails as a server both when accepting connections from itself or from s_client with a no shared cipher error. You can download a full package to reproduce the issue at http://www.magitech.org/gambit/ecdhetest.tar.gz You can run the test by using make: $ make all $ make s_server & # Run’s OpenSSL s_server in the background $ make t_client # Runs the client - should be able to see the handshake complete on the server’s log window. $ make t_server & # After killing the s_server, start up the test server $ make s_client # Fails to negotiate. Any suggestions? Cheers, --B ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Protecting RSA keys
Hi everybody, I'm new with OpenSSL and I have some questions. The thing is that several RSA key pairs (each one for a different user) will be stored in a shared secured location (Safenet HSM). As the key pairs will be stored in the same place, we are looking for a way to ensure that one user is able to use only its own key pair, and not the key pair of another user. In this way, I'm thinking on a passphrase to protect the private key, so when the user needs to use its key pair for signing or encrypting, he must provide the passphrase. As he knows its passphrase and not the passphrase of the other key pairs, he is able to use only its own key pair. Until now, the theory. I don't know if I'm right. Supposing that I'm right, I tried to generate protected key pairs, but when using them, I'm never prompted for the passphrase. So, I'm able to use any of the keys created, instead of using only my own key. Can you help me with this issue? Thanks in advance Best regards Sergio Magra ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
> ALL BINARY ELLIPTIC CURVES This one may be premature. I understand the TLS WG is moving against it. However, I am aware of implementations of Shoup's ECIES, and they, in turn, depend on OpenSSL. I don't know if the ECIES implementations rely solely on prime fields or not, however. > BLOWFISH - probably still in use though I don't know where exactly? Linux password files and associated tools, like John the Ripper (JtR). OpenSSL is a good toolkit for research purposes. But if research is not a goal, then that's understandable. There are other crypto libraries that include research as a goal. Jeff On Fri, Nov 13, 2015 at 8:40 AM, Emilia Käsper wrote: > Hi all, > > We are considering removing from OpenSSL 1.1 known broken or outdated > cryptographic primitives. As you may know the forks have already done this > but I'd like to seek careful feedback for OpenSSL first to ensure we won't > be breaking any major applications. > > These algorithms are currently candidates for removal: > > CAST > IDEA > MDC2 > MD2 [ already disabled by default ] > RC5 [ already disabled by default ] > RIPEMD > SEED > WHIRLPOOL > ALL BINARY ELLIPTIC CURVES > > My preference would be to remove these algorithms completely (as in, delete > the code). Disabled-by-default code will either be re-enabled by distros (if > there's widespread need for it - in which case we might as well leave it in) > or will be poorly tested and is likely to just silently rot and break. This > code is bloat and maintentance burden for us - my hope is that much of this > code is effectively dead and can be removed. > > Are you aware of any mainstream need to continue supporting these algorithms > in OpenSSL 1.1? Note that an older OpenSSL library or binary, or a > standalone implementation or another crypto toolkit can always be used to > continue supporting a legacy standalone application, or to decrypt > ciphertext from the distant past. I am looking for use cases that could > cause e.g. interop breakage between new and old peers, or major pain to > distro end-users. > > These algorithms are obsolete but removing them doesn't look feasible: > > BLOWFISH - probably still in use though I don't know where exactly? > MD4 - used in NTLM > RC2 - used in PKCS#12 > > Did I miss anything from the list? ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] (2013) : PKCS12 keystore creation failing in fips mode (RT3515)
On Wed, Nov 11, 2015, jonetsu wrote: > Hello, > > > There is a thread in 2013 (30 May 03:15) in which Steve writes that OpenSSL > 1.0.1 has a bug regarding the use of PKCS12 in FIPS mode since it tries to > handle a certificate using a non-FIPS component. I think I found the commit > that fixes this, although it is part of a quite huge commit of 33,065 lines > (7e1b7485706c2b11091b5fa897fe496a2faa56cc) done earlier this year. > > > There is perhaps a simpler commit that fixes only this issue > (92830dc1ca0bb2d12bf05a12ebb798709595fa5a) although I can't see the commit in > the git tree I have fetched last week, even by branching to > remotes/origin/OpenSSL_1_0_1-stable. > > > We are using 1.0.1.e. My question is, was bug RT3515 included in a later > 1.0.1 release ? If so, which one ? > Try commit cdb6c48445ded3daafab32e5f266943d07bb512b Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
On Fri, Nov 13, 2015, Benjamin Kaduk wrote: > > As another thread calls to mind, PKCS#12 could potentially just use > triple-DES. (BTW, the CMS tests fail when openssl is configured with > no-rc2, due to this; I have a WIP patch sitting around.) > The issue is that some cuurent software (including major web browsers) still produce PKCS#12 files which include 40 bit RC2 for certificate "encryption" and OpenSSL would fail to decrypt those if it removed RC2. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
On 13/11/2015 18:00, Benjamin Kaduk wrote: On 11/13/2015 09:31 AM, Jakob Bohm wrote: On 13/11/2015 14:40, Emilia Käsper wrote: Hi all, We are considering removing from OpenSSL 1.1 known broken or outdated cryptographic primitives. As you may know the forks have already done this but I'd like to seek careful feedback for OpenSSL first to ensure we won't be breaking any major applications. These algorithms are currently candidates for removal: CAST IDEA MDC2 MD2 [ already disabled by default ] RC5 [ already disabled by default ] RIPEMD SEED WHIRLPOOL ALL BINARY ELLIPTIC CURVES I wonder why single-DES is not in the above list. (Maybe because no one has spoken up as being interested in disentangling triple-DES from single-DES?) My preference would be to remove these algorithms completely (as in, delete the code). Disabled-by-default code will either be re-enabled by distros (if there's widespread need for it - in which case we might as well leave it in) or will be poorly tested and is likely to just silently rot and break. This code is bloat and maintentance burden for us - my hope is that much of this code is effectively dead and can be removed. My hope as well :) These algorithms are obsolete but removing them doesn't look feasible: BLOWFISH - probably still in use though I don't know where exactly? MD4 - used in NTLM RC2 - used in PKCS#12 As another thread calls to mind, PKCS#12 could potentially just use triple-DES. (BTW, the CMS tests fail when openssl is configured with no-rc2, due to this; I have a WIP patch sitting around.) MD2 is still present in the self-signature on some major root certificates that are still trusted in signatures on old/historic data and documents. Note that the default OpenSSL code currently skips checking the self-signature on self-signed root certificates, but that was done based as a workaround for the disabling of MD2, and is based on the (unreliable) assumption that checking their internal consistency had no value in determining the trust. Accepting MD2 only for this limited role (and thus keeping the code around for that case only) would be more secure. I am not sure that I agree with the claim that this assumption is unreliable. There have been some (heated) discussions on the IETF tls WG list recently regarding the self-signatures on trust anchors, and I have not seen any compelling arguments there for checking the self-signature. The trust anchor is just a key and an identifier; its presence in the trust store seems necessary and sufficient to me. It is essentially a "proof-of-possession", just like the signature on a CSR. Another way to look at is that it is a consistency check rather than a trust check. One use would be to refuse import of an invalid root CA before even getting to the point of asking the user if she wants to add this certificate to the trusted roots store. Another use would be to detect accidental corruption of the trusted roots store (e.g. from disk I/O errors or partial disk writes during a system crash). The use of MD4 in NTLM is closely related to its use in the password database format of computers that interoperate with NTLM, SMB, CIFS, Microsoft Kerberos extensions etc. Those password databases and related protocols will probably outlive NTLM itself by many years. The MD4 in the NTLM password hash is unsalted, for extra insecurity. The only real reason to still be using MD4 (by way of the RC4 enctype) in Kerberos is if you need to interoperate with WinXP or Server 2003 machines, but those are not really supported anymore. We are working to get RC4 explicitly deprecated for Kerberos at the IETF. I have not checked the details, but the fundamental issue is this: Windows domain controller databases store only the unsalted MD4 password hash and/or the historic LM password hash, with most current systems configured to store only the MD4 hash. Thus any protocol that validates user identity via their knowledge of their domain password would need to either transmit the actual password to the domain controller or use some kind of cryptographic calculation where the computer closer to the user proves knowledge of the MD4 hash to the domain controller server. Historically, Microsoft has implemented multiple such cryptographic protocols: NTLMv1 was the oldest such protocol, based on a using DES in a silly way vastly similar to the LM protocol. NTLMv2 was the next version, based mostly on HMAC-MD5, introduced in the late 1990s and still the strongest supported when the client computer is not (yet) joined to the domain. Microsoft-specific variants/profiles of Kerberos V are used between modern (post 2000) domain joined computers and the trusted domain controllers of the users login domain. I have not yet studied which formulas they are currently using/ recommending/planning for this case, but they will all be constrained by the fact that the server knows nothing about the password ex
Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
On 11/13/2015 09:31 AM, Jakob Bohm wrote: > On 13/11/2015 14:40, Emilia Käsper wrote: >> Hi all, >> >> We are considering removing from OpenSSL 1.1 known broken or outdated >> cryptographic primitives. As you may know the forks have already done >> this but I'd like to seek careful feedback for OpenSSL first to >> ensure we won't be breaking any major applications. >> >> These algorithms are currently candidates for removal: >> >> CAST >> IDEA >> MDC2 >> MD2 [ already disabled by default ] >> RC5 [ already disabled by default ] >> RIPEMD >> SEED >> WHIRLPOOL >> ALL BINARY ELLIPTIC CURVES >> I wonder why single-DES is not in the above list. (Maybe because no one has spoken up as being interested in disentangling triple-DES from single-DES?) >> My preference would be to remove these algorithms completely (as in, >> delete the code). Disabled-by-default code will either be re-enabled >> by distros (if there's widespread need for it - in which case we >> might as well leave it in) or will be poorly tested and is likely to >> just silently rot and break. This code is bloat and maintentance >> burden for us - my hope is that much of this code is effectively dead >> and can be removed. >> My hope as well :) >> These algorithms are obsolete but removing them doesn't look feasible: >> >> BLOWFISH - probably still in use though I don't know where exactly? >> MD4 - used in NTLM >> RC2 - used in PKCS#12 >> As another thread calls to mind, PKCS#12 could potentially just use triple-DES. (BTW, the CMS tests fail when openssl is configured with no-rc2, due to this; I have a WIP patch sitting around.) > MD2 is still present in the self-signature on some major > root certificates that are still trusted in signatures > on old/historic data and documents. Note that the > default OpenSSL code currently skips checking the > self-signature on self-signed root certificates, but > that was done based as a workaround for the disabling > of MD2, and is based on the (unreliable) assumption > that checking their internal consistency had no value > in determining the trust. Accepting MD2 only for this > limited role (and thus keeping the code around for that > case only) would be more secure. > I am not sure that I agree with the claim that this assumption is unreliable. There have been some (heated) discussions on the IETF tls WG list recently regarding the self-signatures on trust anchors, and I have not seen any compelling arguments there for checking the self-signature. The trust anchor is just a key and an identifier; its presence in the trust store seems necessary and sufficient to me. > The use of MD4 in NTLM is closely related to its use in > the password database format of computers that > interoperate with NTLM, SMB, CIFS, Microsoft Kerberos > extensions etc. Those password databases and related > protocols will probably outlive NTLM itself by many > years. > The MD4 in the NTLM password hash is unsalted, for extra insecurity. The only real reason to still be using MD4 (by way of the RC4 enctype) in Kerberos is if you need to interoperate with WinXP or Server 2003 machines, but those are not really supported anymore. We are working to get RC4 explicitly deprecated for Kerberos at the IETF. -Ben Kaduk ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to access a bug fix ?
On 11/13/2015 10:14 AM, jonetsu wrote: > Hello, > > > I would like to see the bug fix for RT3515 'Use 3DES in pkcs12 if built with > no-rc2' although the opnssl tree I got recently does not show it: The bug fix is just the patch contained in the initial submission. > > % git status > On branch master > Your branch is up-to-date with 'origin/master'. > > > % git show 92830dc1ca0bb2d12bf05a12ebb798709595fa5a > fatal: bad object 92830dc1ca0bb2d12bf05a12ebb798709595fa5a > > > I tried with checking out a few branches: > > > remotes/origin/OpenSSL-fips-2_0-stable > remotes/origin/OpenSSL_1_0_1-stable > remotes/origin/OpenSSL_1_0_2-stable Checking out a different branch will not make any difference; "git show" checks for all objects in a given repository, whether accessible from the current HEAD or otherwise. > > And still not shown. Did that bug fix ever made it to the OpenSSL tree as > such, or was it bundled in the 33,000+ lines commit > 7e1b7485706c2b11091b5fa897fe496a2faa56cc ? It seems to be only in that mega-commit, which is not a real git merge commit despite having 'merge' in the commit message. > > Alternatively, in which 1.0.1 version was this bug fix included ? I grepped > the CHANGES file of some versions after 1.0.1e although these do not list the > bug numbers. > Looking at the pkcs12.c version in the OpenSSL_1_0_2-stable branch and OpenSSL_1_0_1-stable branch, the bugfix is not present. You would need to apply it manually or convince a committer to push the change to the stable branches. -Ben Kaduk ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Elliptic curves approved or recommended by government
> Is there a up to date list of elliptic curves approved or recommended for > government use in OpenSSL? You'll have to look outside OpenSSL for advice like that. I would suggest looking at the CFRG, part of the IETF basically. Do web search for curve recommendations. Good luck. It's a contentious area. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] How to access a bug fix ?
Hello, I would like to see the bug fix for RT3515 'Use 3DES in pkcs12 if built with no-rc2' although the opnssl tree I got recently does not show it: % git status On branch master Your branch is up-to-date with 'origin/master'. % git show 92830dc1ca0bb2d12bf05a12ebb798709595fa5a fatal: bad object 92830dc1ca0bb2d12bf05a12ebb798709595fa5a I tried with checking out a few branches: remotes/origin/OpenSSL-fips-2_0-stable remotes/origin/OpenSSL_1_0_1-stable remotes/origin/OpenSSL_1_0_2-stable And still not shown. Did that bug fix ever made it to the OpenSSL tree as such, or was it bundled in the 33,000+ lines commit 7e1b7485706c2b11091b5fa897fe496a2faa56cc ? Alternatively, in which 1.0.1 version was this bug fix included ? I grepped the CHANGES file of some versions after 1.0.1e although these do not list the bug numbers. Thanks. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
On 13/11/2015 14:40, Emilia Käsper wrote: Hi all, We are considering removing from OpenSSL 1.1 known broken or outdated cryptographic primitives. As you may know the forks have already done this but I'd like to seek careful feedback for OpenSSL first to ensure we won't be breaking any major applications. These algorithms are currently candidates for removal: CAST IDEA MDC2 MD2 [ already disabled by default ] RC5 [ already disabled by default ] RIPEMD SEED WHIRLPOOL ALL BINARY ELLIPTIC CURVES My preference would be to remove these algorithms completely (as in, delete the code). Disabled-by-default code will either be re-enabled by distros (if there's widespread need for it - in which case we might as well leave it in) or will be poorly tested and is likely to just silently rot and break. This code is bloat and maintentance burden for us - my hope is that much of this code is effectively dead and can be removed. *Are you aware of any mainstream need to continue supporting these algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or binary, or a standalone implementation or another crypto toolkit can always be used to continue supporting a legacy standalone application, or to decrypt ciphertext from the distant past. I am looking for use cases that could cause e.g. interop breakage between new and old peers, or major pain to distro end-users. These algorithms are obsolete but removing them doesn't look feasible: BLOWFISH - probably still in use though I don't know where exactly? MD4 - used in NTLM RC2 - used in PKCS#12 *Did I miss anything from the list?* BlowFish is still hardcoded into some file formats that are still in use, such as the PasswordSafe password database format, I don't know if any related implementations get the Blowfish code from OpenSSL though. IDEA was famously used in the original PGP encryption format and as such remains useful when implementing OpenPGP decryption on top of OpenSSL's libcrypto (as opposed to implementing an OpenSSL emulation on top an OpenPGP library like GNU did). I don't know if any of the 'OpenPGP in a high level language such as perl/python/php' implementations use OpenSSL's IDEA implementation as the backend though, but someone will need to trawl through CPAN (for perl), the Linux dists etc. to be sure. MD2 is still present in the self-signature on some major root certificates that are still trusted in signatures on old/historic data and documents. Note that the default OpenSSL code currently skips checking the self-signature on self-signed root certificates, but that was done based as a workaround for the disabling of MD2, and is based on the (unreliable) assumption that checking their internal consistency had no value in determining the trust. Accepting MD2 only for this limited role (and thus keeping the code around for that case only) would be more secure. The use of MD4 in NTLM is closely related to its use in the password database format of computers that interoperate with NTLM, SMB, CIFS, Microsoft Kerberos extensions etc. Those password databases and related protocols will probably outlive NTLM itself by many years. WHIRLPOOL has been frequently recommended as the premier non-NIST alternative to SHA-512, I have heard of no reason to deprecate it. The binary elliptic curve code in OpenSSL seems to have a unique patent license heritage (via Sun I think) and thus provides a unique source of such code for other FOSS code as the Certicom and Sun patents change hands in unpredictable ways. I don't know if any major CA issued ECDSA certificates using those curves, in which case they remain important to the CMS and certificate code in OpenSSL. Again I have heard of no reason to deprecate them. I do not recall any common uses for the CAST cipher, the MDC hash construct family or the RIPEMD hash function family (at this time). RC5 may be a patent problem and would probably be disabled in most OpenSSL builds anyway. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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] Converting DER encoded unsigned CSR to internal OpenSSL format
Hi Wim, I'll give this a shot, thank you for the suggestion! -Peter On Wed, Nov 11, 2015 at 5:05 PM, Wim Lewis wrote: > > On Nov 9, 2015, at 3:46 PM, Peter P. wrote: > > I'm writing an application using Openssl 1.0.2d where I am trying to > take a DER encoded unsigned CSR and read it into an X509_REQ data structure > via the d2i_X509_REQ_bio() function. This function errors out during when I > attempt to read in my unsigned CSR and I would like to know if there is any > other way to read in an unsigned CSR into an X509_REQ data structure. > > A CSR (from PKCS#10 / RFC2986) has the structure: > >SEQUENCE { CertificationRequestInfo, AlgorithmIdentifier, BIT STRING } > > where the actual request is the CertificationRequestInfo, and the > signature is composed of the AlgorithmIdentifier + BIT STRING. > > Are you trying to just read in a bare CertificationRequestInfo structure? > I suspect you can do that with a call like > > ASN1_item_d2i_bio(ASN1_ITEM_rptr(X509_REQ_INFO), bp, req) > > which is the same as the body of d2i_X509_REQ_bio(), but with X509_REQ > replaced by X509_REQ_INFO. I haven't tried it, though. > > (Whether it's a *good idea* to pass bare CSR info structs around is > another question but I'll leave that up to you.) > > > Wim. > > ___ > 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
[openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
Hi all, We are considering removing from OpenSSL 1.1 known broken or outdated cryptographic primitives. As you may know the forks have already done this but I'd like to seek careful feedback for OpenSSL first to ensure we won't be breaking any major applications. These algorithms are currently candidates for removal: CAST IDEA MDC2 MD2 [ already disabled by default ] RC5 [ already disabled by default ] RIPEMD SEED WHIRLPOOL ALL BINARY ELLIPTIC CURVES My preference would be to remove these algorithms completely (as in, delete the code). Disabled-by-default code will either be re-enabled by distros (if there's widespread need for it - in which case we might as well leave it in) or will be poorly tested and is likely to just silently rot and break. This code is bloat and maintentance burden for us - my hope is that much of this code is effectively dead and can be removed. *Are you aware of any mainstream need to continue supporting these algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or binary, or a standalone implementation or another crypto toolkit can always be used to continue supporting a legacy standalone application, or to decrypt ciphertext from the distant past. I am looking for use cases that could cause e.g. interop breakage between new and old peers, or major pain to distro end-users. These algorithms are obsolete but removing them doesn't look feasible: BLOWFISH - probably still in use though I don't know where exactly? MD4 - used in NTLM RC2 - used in PKCS#12 *Did I miss anything from the list?* Cheers, Emilia ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: Broken ChangeCipherspec record in TLS 1.2 with OpenSSL 1.0.2d?
Thank you kindly Matt, for the pointers - these connections always end with that renegotiation and subsequent failure - I suspect there is a ciphersuite problem and am following up to see what the client *will* support.Paul H. -- View this message in context: http://openssl.6102.n7.nabble.com/Broken-ChangeCipherspec-record-in-TLS-1-2-with-OpenSSL-1-0-2d-tp59592p60972.html Sent from the OpenSSL - User mailing list archive at Nabble.com.___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to get list of TLS protocols supported by OpenSSL?
On 13/11/2015 10:34, Matt Caswell wrote: On 13/11/15 02:56, pratyush parimal wrote: Hi, I'm writing a client-server program that uses TLS for communication. I'm wondering if there's any way to programmatically find out which TLS protocol versions are supported by the OpenSSL library installed on my system. I'm currently aware of three ways which "sort of" provide this information: (1) After setting up the TLS communication, call: SSL_get_version(ssl); which returns "TLSV1.2", etc. (2) Try to connect to a server using TLS by specifying all possible TLS versions in the client program, and see which connections pass/fail. (3) Call: SSL_get_ciphers(), print their names, and try to correlate them with the protocol they're associated with. Unfortunately, none of the above answer my question completely. So is it possible to ascertain which TLS protocol versions are actually supported by my server-program, without trying the above methods? My purpose is not to simply make a list for my own reference, but rather finding it out on-the-fly in the server-side program, since I may run it on different versions of OpenSSL. You can use the define TLS_MAX_VERSION to determine the highest protocol version supported by the library. If you also want to know the lowest version then that's a bit more tricky. All current released versions will define OPENSSL_NO_SSL3 if SSLv3 support has been compiled out, and OPENSSL_NO_SSL2 if SSLv2 support has been compiled out (its not currently possible to compile out other protocol versions). In the forthcoming 1.1.0 release SSLv2 support has been completely removed so you don't get OPENSSL_NO_SSL2 even though there is no SSLv2 support available (h...I wonder if we should add that?). There are other SSLv2 defines in ssl2.h that are removed in 1.1.0 which you could use to detect whether you are on a version with ssl2.h completely removed such as SSL2_MT_ERROR, i.e. something like (completely untested): #ifdef OPENSSL_NO_SSL3 #define TLS_MIN_VERSION TLS1_VERSION #elif defined(OPENSSL_NO_SSL2) || !defined(SSL2_MT_ERROR) #define TLS_MIN_VERSION SSL3_VERSION #else #define TLS_MIN_VERSION SSL2_VERSION #endif How future proof that is if we ever remove SSLv3 support I'm not sure. Matt Unfortunately that presumes that the client is compiled against configure headers from the library build. This is absolutely useless if you try to share an OpenSSL shared library compiled by a 3rd party (such as an OS distribution or an end user). What lots of people need is an ability to interrogate a compiled shared library about what is enabled in that copy, similar to how the SSL_get_ciphers() or similar can be used to determine if the current copy has been compiled without IDEA, ECC or other optional cipher suites. This is what happens in the real world when end users run your compiled program on various Linux distributions, such as Red Hat vs. OpenSUSE vs. Ubuntu... Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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] Rehandshake problem
Hey, this is on fedora 23, though I built openssl 1.0.1k (since it is the version supported on rhel 6) These are the specific test cases that are failing with openssl for us: https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n1948 https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n1950 And here is where the second handshake happens: https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n389 FWIW we are using our own bio: https://git.gnome.org/browse/glib-networking/tree/tls/openssl/gtlsbio.c?h=wip/openssl I can try to get you the pcap packet trace. About " You would normally expect to get an SSL_ERROR_WANT_READ on the client side when the server sends the HelloRequest." Yes this is what I would have expected as well. Cheers. On Fri, Nov 13, 2015 at 11:08 AM, Matt Caswell wrote: > > > On 13/11/15 08:37, Ignacio Casal wrote: > > Hey guys, > > > > I am having a specific problem that I do not seem to find a solution for. > > > > - I have a server and a client that handshake properly > > - the server will read from the client and the client from the server a > > few bytes > > - the client will try to read again > > - the server will try to handshake again by calling SSL_renegotiate and > > SSL_do_handshake. I get no errors in these calls. > > - then I would expect the client to exit from the read call with an > > error saying that needs to handshake again, instead it stays blocked on > > the read until the server sends some data. But then I get an error > > server side that there was no proper handshaking. > > > > Do you know how to get a notification client side that the client needs > > to handshake again when blocked on a read or write? > > Which OpenSSL version/platform are you using? Can you get a pcap packet > trace and post the specific errors that you are receiving? > > You would normally expect to get an SSL_ERROR_WANT_READ on the client > side when the server sends the HelloRequest. > > Matt > > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Ignacio Casal Quinteiro ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Rehandshake problem
On 13/11/15 08:37, Ignacio Casal wrote: > Hey guys, > > I am having a specific problem that I do not seem to find a solution for. > > - I have a server and a client that handshake properly > - the server will read from the client and the client from the server a > few bytes > - the client will try to read again > - the server will try to handshake again by calling SSL_renegotiate and > SSL_do_handshake. I get no errors in these calls. > - then I would expect the client to exit from the read call with an > error saying that needs to handshake again, instead it stays blocked on > the read until the server sends some data. But then I get an error > server side that there was no proper handshaking. > > Do you know how to get a notification client side that the client needs > to handshake again when blocked on a read or write? Which OpenSSL version/platform are you using? Can you get a pcap packet trace and post the specific errors that you are receiving? You would normally expect to get an SSL_ERROR_WANT_READ on the client side when the server sends the HelloRequest. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to get list of TLS protocols supported by OpenSSL?
On 13/11/15 02:56, pratyush parimal wrote: > Hi, > > I'm writing a client-server program that uses TLS for communication. > I'm wondering if there's any way to programmatically find out which TLS > protocol versions are supported by the OpenSSL library installed on my > system. > > I'm currently aware of three ways which "sort of" provide this information: > (1) After setting up the TLS communication, call: SSL_get_version(ssl); > which returns "TLSV1.2", etc. > (2) Try to connect to a server using TLS by specifying all possible TLS > versions in the client program, and see which connections pass/fail. > (3) Call: SSL_get_ciphers(), print their names, and try to correlate > them with the protocol they're associated with. > > Unfortunately, none of the above answer my question completely. > > So is it possible to ascertain which TLS protocol versions are actually > supported by my server-program, without trying the above methods? My > purpose is not to simply make a list for my own reference, but rather > finding it out on-the-fly in the server-side program, since I may run it > on different versions of OpenSSL. You can use the define TLS_MAX_VERSION to determine the highest protocol version supported by the library. If you also want to know the lowest version then that's a bit more tricky. All current released versions will define OPENSSL_NO_SSL3 if SSLv3 support has been compiled out, and OPENSSL_NO_SSL2 if SSLv2 support has been compiled out (its not currently possible to compile out other protocol versions). In the forthcoming 1.1.0 release SSLv2 support has been completely removed so you don't get OPENSSL_NO_SSL2 even though there is no SSLv2 support available (h...I wonder if we should add that?). There are other SSLv2 defines in ssl2.h that are removed in 1.1.0 which you could use to detect whether you are on a version with ssl2.h completely removed such as SSL2_MT_ERROR, i.e. something like (completely untested): #ifdef OPENSSL_NO_SSL3 #define TLS_MIN_VERSION TLS1_VERSION #elif defined(OPENSSL_NO_SSL2) || !defined(SSL2_MT_ERROR) #define TLS_MIN_VERSION SSL3_VERSION #else #define TLS_MIN_VERSION SSL2_VERSION #endif How future proof that is if we ever remove SSLv3 support I'm not sure. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Rehandshake problem
Hey guys, I am having a specific problem that I do not seem to find a solution for. - I have a server and a client that handshake properly - the server will read from the client and the client from the server a few bytes - the client will try to read again - the server will try to handshake again by calling SSL_renegotiate and SSL_do_handshake. I get no errors in these calls. - then I would expect the client to exit from the read call with an error saying that needs to handshake again, instead it stays blocked on the read until the server sends some data. But then I get an error server side that there was no proper handshaking. Do you know how to get a notification client side that the client needs to handshake again when blocked on a read or write? Cheers. -- Ignacio Casal Quinteiro ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users