From eyal at motorolasolutions.com Thu Nov 1 06:12:05 2018 From: eyal at motorolasolutions.com (EYAL INBAR) Date: Thu, 1 Nov 2018 08:12:05 +0200 Subject: [openssl-users] CMP protocol Message-ID: Hello I have OpenSSL 1.1.1-dev that have CMP protocol implementation but didn't find it in the OpenSSL 1.1.1 version. Is it remove from the release version? Eyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Nov 1 08:32:41 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Nov 2018 08:32:41 +0000 Subject: [openssl-users] CMP protocol In-Reply-To: References: Message-ID: <24d4ea6e-38d2-d1ec-6756-612a03dc8337@openssl.org> On 01/11/2018 06:12, EYAL INBAR wrote: > Hello > > I have OpenSSL 1.1.1-dev that have CMP protocol implementation but > didn't find it in the? OpenSSL 1.1.1 version. Is it remove from the > release version?? There is no (and has never been) support for CMP in OpenSSL. There is a recent and ongoing attempt to integrate it. See: https://github.com/openssl/openssl/pull/7328 Matt From zhihong.lu at hotmail.com Thu Nov 1 09:57:56 2018 From: zhihong.lu at hotmail.com (lu zhihong) Date: Thu, 1 Nov 2018 09:57:56 +0000 Subject: [openssl-users] compile warning on 32bit platform:integer constant is too large for 'long' type Message-ID: hi,all when complie openssl 1.1.1 on linux 32bit platform, i met some compile warning,like: crypto/ec/curve448/curve448_tables.c:415: integer constant is too large for 'long' type the 64bit constant is default to 32bit long type, how should i deal with these warning? thanks in advance for your help luzhihong From ashajg18 at gmail.com Thu Nov 1 10:38:53 2018 From: ashajg18 at gmail.com (ashish ajgaonkar) Date: Thu, 1 Nov 2018 16:08:53 +0530 Subject: [openssl-users] Problem while compiling source code of OpenSSL 1.1.1 Message-ID: Hi I am trying to compile source code of OpenSSL for androidplatform While compilation Iam getting this error on my MSYS: c:/android-ndk-r17c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld.exe: error: c:/android-ndk-r17c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/../libexec/gcc/arm-linux-androideabi/4.9.x/liblto_plugin-0.dll: could not load plugin library: The parameter is incorrect. collect2.exe: error: ld returned 1 exit status make[1]: *** [Makefile:783: libcrypto.so] Error 1 make[1]: Leaving directory '/e/SSLFEATURE/openssl-1.1.1' make: *** [Makefile:171: all] Error 2 Please help me to solve this problem! Thanks and regards Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: From thulasi.goriparthi at gmail.com Fri Nov 2 07:50:22 2018 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Fri, 2 Nov 2018 13:20:22 +0530 Subject: [openssl-users] EC_KEY_check_key Message-ID: Hi, I am going through the checks done by EC_KEY_check_key method. I see the following checks in order. 1. Is point at infinity? - reject. 2. Is point not on curve? reject. 3. Is point not in the primary subgroup? reject. 4. If priv key(scalar) available, then check if scalar * G != point. If so, reject. If priv key is available and we do step 4, isn't step 3 redundant? Can we change this to something like this? if (priv key) step 4 else step 3 Thanks, Thulasi. From jb-openssl at wisemo.com Fri Nov 2 11:23:26 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 2 Nov 2018 12:23:26 +0100 Subject: [openssl-users] EC_KEY_check_key In-Reply-To: References: Message-ID: <8577999d-5e1e-b61d-117c-8e8e0c3adc18@wisemo.com> On 02/11/2018 08:50, Thulasi Goriparthi wrote: > Hi, > > I am going through the checks done by EC_KEY_check_key method. I see > the following checks in order. > > 1. Is point at infinity? - reject. > 2. Is point not on curve? reject. > 3. Is point not in the primary subgroup? reject. > 4. If priv key(scalar) available, then check if scalar * G != point. > If so, reject. > > If priv key is available and we do step 4, isn't step 3 redundant? Can > we change this to something like this? > > if (priv key) > step 4 > else > step 3 For such tests, it's always better safe than sorry. 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 From nick.papadonis.ml at gmail.com Fri Nov 2 18:29:17 2018 From: nick.papadonis.ml at gmail.com (Nicholas Papadonis) Date: Fri, 2 Nov 2018 14:29:17 -0400 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? Message-ID: Security Experts, I'm considering encrypting a tar archive and optionally a block file system (via FUSE) using either utility. Does anyone have comments on the best practices and tools for either? I read that the OpenSSL AES-CBC CLI mode is prone to a malleable attack vector and it's CLI interface should not be use directly for production. I have also read that GPG is the suggested alternative to OpenSSL CLI due to this. I have followed through with the OpenSSL CLI AES tests and am curious where the malleable attack is (in the pipe?). I am also curious to why GPG, which is an asymmetric key manager, is used for file based encryption when only a single key is required. How does GPG solve this malleable attack vector. A security expert's guidance here is much appreciated. Thank you, Nicholas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Nov 2 19:08:35 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 2 Nov 2018 19:08:35 +0000 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: Message-ID: > From: openssl-users on behalf of Nicholas Papadonis > Sent: Friday, November 2, 2018 14:29 > I read Where? It's hard for us to determine the quality of your source, or your interpretation of it, if we don't know what it is. > that the OpenSSL AES-CBC CLI mode is prone to a malleable attack vector I don't know what "malleable attack vector" is supposed to mean in this context. CBC, regardless of the cipher, has certain well-known vulnerabilities. Those probably aren't a concern for most personal file-encryption use cases. If you have regulatory/legal requirements, then rolling your own data-protection solution, even using presumed-good crypto implementations, is a Bad Idea. > and [its] CLI interface should not be use directly for production. I would certainly be leery of doing so. It's not what the openssl utility is primarily intended or designed for. There are at least two main drawbacks of using the openssl utility in production: - It primarily exposes primitives, not complete cryptosystems. That means either you're composing those primitives into a complete cryptosystem yourself, which is a process fraught with danger; or you're using an incomplete cryptosystem. In this case, if you use openssl, where is your integrity protection coming from, for example? How are you handling key management, hygiene, and disaster recovery? - Usability is minimal (for good reason - it's meant as an ad hoc toolkit). There's no error logging or auditing, and minimal diagnostics. Failure modes are pretty much "write an error message and give up". > I have also read that GPG is the suggested alternative to OpenSSL CLI due to this.? ... > I am also curious to why GPG, which is an asymmetric key manager, GPG is an implementation of the OpenPGP standard, plus additional functionality. It's much more than a "key manager". > is used for file based encryption when only a single key is required.? GPG supports symmetric encryption. A web search should turn up thousands of pages describing that feature. (Some will be out of date regarding the default cipher and other details; consult the documentation for the current GPG version. I think the default now might be AES-128 CBC, with SHA1 as the MDC, but I haven't checked.) > How does GPG solve this malleable attack vector. Hard to say without knowing what the "malleable attack vector" is. GPG *is* intended to provide a complete, if rather minimal, cryptosystem for this use case (symmetric encryption of individual files, under a personal-use threat model). For one thing, it (by default) includes an MDC for integrity validation; for another, it provides slightly more sophisticated features for key hygiene. We don't really know the parameters of your use case, so it's not really possible to make a reasonable recommendation. Do you have regulatory or statutory requirements, or requirements imposed by some other authority (e.g. an employer)? How sensitive is the data? How are you managing your key? What provisions do you need to make for disaster recovery? How are you addressing file integrity? What does your threat model look like? This is why the simplest approach is to find a complete system that addresses all your requirements. It may not be free, but then neither is your time and energy - you can pay money, or you can pay in opportunity costs and cognitive load. Of course, many people simply ignore the issues and roll their own systems. Often they'll get away with it. Sometimes it will come back to bite them. -- Micahel Wojcik From hanno at hboeck.de Fri Nov 2 19:21:38 2018 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Fri, 2 Nov 2018 20:21:38 +0100 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: Message-ID: <20181102202138.016167eb@computer> Hi, Malleability means that an attacker who is able to modify your encrypted data can - given some partial knowledge about the plaintext - do some modification of the ciphertext that will lead to specific modifications in the plaintext. This can e.g. mean that if the attacker knows your plaintext is a tar file he knows the first bytes. Thus by some clever XOR-ing he can inject blocks into your ciphertext that he can control. All of this was the basis of the efail attack earlier this year. Ideally you don't want to use any cipher that is vulnerable to these kinds of attacks. More modern cipher modes use authenticated encryption, which means they'll detect if modifications have happened. Such modes are e.g. GCM or Poly1305. As for OpenSSL CLI vs. GnuPG, neither of them is ideal, but GnuPG is better. It uses a hash to provide some kind of authentication. It's not really an authenticated encryption mode, but it comes close. -- Hanno B?ck https://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From Walter.H at mathemainzel.info Fri Nov 2 21:51:38 2018 From: Walter.H at mathemainzel.info (Walter H.) Date: Fri, 02 Nov 2018 22:51:38 +0100 Subject: [openssl-users] a problem connecting to a specific Site ... Message-ID: <5BDCC6EA.1050902@mathemainzel.info> Hello, when I try to connect to https://www.3bg.at/ I get the following error Handshake with SSL server failed: error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message but https://www.ssllabs.com/ssltest/analyze.html?d=www.3bg.at says its ok ... is the problem on my side or on their side? Thanks, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3491 bytes Desc: S/MIME Cryptographic Signature URL: From matt at openssl.org Fri Nov 2 22:05:23 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Nov 2018 22:05:23 +0000 Subject: [openssl-users] a problem connecting to a specific Site ... In-Reply-To: <5BDCC6EA.1050902@mathemainzel.info> References: <5BDCC6EA.1050902@mathemainzel.info> Message-ID: <39f2fbd8-a9d9-79db-fcba-d1b26e6eb6dd@openssl.org> On 02/11/2018 21:51, Walter H. wrote: > Hello, > > when I try to connect to https://www.3bg.at/ > I get the following error > > Handshake with SSL server failed: error:1408E0F4:SSL > routines:SSL3_GET_MESSAGE:unexpected message > > but > https://www.ssllabs.com/ssltest/analyze.html?d=www.3bg.at > says its ok ... > > is the problem on my side or on their side? You'll need to give us more information. I can connect to that server using OpenSSL 1.0.2 s_client. What version of OpenSSL are you using? Is this with your own application or from s_client? What ciphersuites have you configured? Any other relevant configuration that we should know about? Matt From socketpair at gmail.com Sat Nov 3 07:28:02 2018 From: socketpair at gmail.com (=?UTF-8?B?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 3 Nov 2018 12:28:02 +0500 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: Message-ID: Try openssl cms ( as newer alternative to s/mime) ??, 2 ????. 2018 ?. ? 23:30, Nicholas Papadonis : > > Security Experts, > > I'm considering encrypting a tar archive and optionally a block file system (via FUSE) using either utility. Does anyone have comments on the best practices and tools for either? > > I read that the OpenSSL AES-CBC CLI mode is prone to a malleable attack vector and it's CLI interface should not be use directly for production. I have also read that GPG is the suggested alternative to OpenSSL CLI due to this. I have followed through with the OpenSSL CLI AES tests and am curious where the malleable attack is (in the pipe?). I am also curious to why GPG, which is an asymmetric key manager, is used for file based encryption when only a single key is required. How does GPG solve this malleable attack vector. > > A security expert's guidance here is much appreciated. > > Thank you, > Nicholas > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Segmentation fault From Walter.H at mathemainzel.info Sat Nov 3 07:56:06 2018 From: Walter.H at mathemainzel.info (Walter H.) Date: Sat, 03 Nov 2018 08:56:06 +0100 Subject: [openssl-users] a problem connecting to a specific Site ... In-Reply-To: <39f2fbd8-a9d9-79db-fcba-d1b26e6eb6dd@openssl.org> References: <5BDCC6EA.1050902@mathemainzel.info> <39f2fbd8-a9d9-79db-fcba-d1b26e6eb6dd@openssl.org> Message-ID: <5BDD5496.7080501@mathemainzel.info> Hello, it is a little bitte weird/strange/complicated; On 02.11.2018 23:05, Matt Caswell wrote: > > On 02/11/2018 21:51, Walter H. wrote: >> Hello, >> >> when I try to connect to https://www.3bg.at/ >> I get the following error >> >> Handshake with SSL server failed: error:1408E0F4:SSL >> routines:SSL3_GET_MESSAGE:unexpected message >> >> but >> https://www.ssllabs.com/ssltest/analyze.html?d=www.3bg.at >> says its ok ... >> >> is the problem on my side or on their side? > You'll need to give us more information. I can connect to that server > using OpenSSL 1.0.2 s_client. > > What version of OpenSSL are you using? Is this with your own application > or from s_client? What ciphersuites have you configured? Any other > relevant configuration that we should know about? > > the mentioned error comes with squid - ssl-bump on; in case I switch it off and have it as normal proxy, then is really suspisious: - an old Firefox (17.0.11esr) has no problems, the Sites is shown and works - an older Google Chrome (the last one f. WinXP, v46) gives: SSL connection error ERR_SSL_PROTOCOL_ERROR - a fork of the latest Pale Moon (Mypal) and an old Palemoon itself (the last one f. WinXP) gives: An error occurred during a connection to www.3bg.at. Peer's certificate has an invalid signature. (Error code: SEC_ERROR_BAD_SIGNATURE) what is this strange? but what does this mean at the mentioned SSLlabs result: Certificate Transparency No when I compare to any other site (e.g. my own with Let's encrypt certificate), I get Certificate Transparency *Yes (certificate)* is this caused on my side or on the other side? Thanks, Walter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3491 bytes Desc: S/MIME Cryptographic Signature URL: From hanno at hboeck.de Sat Nov 3 09:11:25 2018 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Sat, 3 Nov 2018 10:11:25 +0100 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: Message-ID: <20181103101125.329fcc4c@computer> On Sat, 3 Nov 2018 12:28:02 +0500 ???? ????????? wrote: > Try openssl cms ( as newer alternative to s/mime) cms is not newer than s/mime, it's the underlying message format of s/mime. According to this https://www.openssl.org/docs/man1.0.2/apps/openssl.html it only supports deprecated cipher modes (cbc, cfb, ofb, ecb) and has exactly the malleability vulnerability the original poster was asking about (including a wide variety of obscure and some insecure ciphers). I don't think this should be recommended. -- Hanno B?ck https://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nick.papadonis.ml at gmail.com Sat Nov 3 17:02:49 2018 From: nick.papadonis.ml at gmail.com (Nicholas Papadonis) Date: Sat, 3 Nov 2018 13:02:49 -0400 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: Message-ID: comments On Fri, Nov 2, 2018 at 3:09 PM Michael Wojcik wrote: > > From: openssl-users on behalf of > Nicholas Papadonis > > Sent: Friday, November 2, 2018 14:29 > > > I read > > Where? It's hard for us to determine the quality of your source, or your > interpretation of it, if we don't know what it is. > > On stackexchange https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup > > that the OpenSSL AES-CBC CLI mode is prone to a malleable attack vector > > I don't know what "malleable attack vector" is supposed to mean in this > context. CBC, regardless of the cipher, has certain well-known > vulnerabilities. Those probably aren't a concern for most personal > file-encryption use cases. > > If you have regulatory/legal requirements, then rolling your own > data-protection solution, even using presumed-good crypto implementations, > is a Bad Idea. > > > and [its] CLI interface should not be use directly for production. > > I would certainly be leery of doing so. It's not what the openssl utility > is primarily intended or designed for. > > There are at least two main drawbacks of using the openssl utility in > production: > > - It primarily exposes primitives, not complete cryptosystems. That means > either you're composing those primitives into a complete cryptosystem > yourself, which is a process fraught with danger; or you're using an > incomplete cryptosystem. In this case, if you use openssl, where is your > integrity protection coming from, for example? How are you handling key > management, hygiene, and disaster recovery? > > - Usability is minimal (for good reason - it's meant as an ad hoc > toolkit). There's no error logging or auditing, and minimal diagnostics. > Failure modes are pretty much "write an error message and give up". > > > I have also read that GPG is the suggested alternative to OpenSSL CLI > due to this. ... > > I am also curious to why GPG, which is an asymmetric key manager, > > GPG is an implementation of the OpenPGP standard, plus additional > functionality. It's much more than a "key manager". > > > is used for file based encryption when only a single key is required. > > GPG supports symmetric encryption. A web search should turn up thousands > of pages describing that feature. (Some will be out of date regarding the > default cipher and other details; consult the documentation for the current > GPG version. I think the default now might be AES-128 CBC, with SHA1 as the > MDC, but I haven't checked.) > > How does GPG solve this malleable attack vector. > > Hard to say without knowing what the "malleable attack vector" is. > > GPG *is* intended to provide a complete, if rather minimal, cryptosystem > for this use case (symmetric encryption of individual files, under a > personal-use threat model). For one thing, it (by default) includes an MDC > for integrity validation; for another, it provides slightly more > sophisticated features for key hygiene. > > We don't really know the parameters of your use case, so it's not really > possible to make a reasonable recommendation. Do you have regulatory or > statutory requirements, or requirements imposed by some other authority > (e.g. an employer)? How sensitive is the data? How are you managing your > key? What provisions do you need to make for disaster recovery? How are you > addressing file integrity? What does your threat model look like? > No regulatory requirements. I'm a personal user making sure to take best practices into account for securing data. I also have the assumption that there are numerous attack vectors in involved in storing computer data, all the way back to the design and manufacturing process. I.e. you need to design, manufacture and test your own computer to be truly secure. I want to keep at least two copies of data in different locations for disaster recovery. Each copy itself should have a backup stored with it in case of a bit error. > > This is why the simplest approach is to find a complete system that > addresses all your requirements. It may not be free, but then neither is > your time and energy - you can pay money, or you can pay in opportunity > costs and cognitive load. Of course, many people simply ignore the issues > and roll their own systems. Often they'll get away with it. Sometimes it > will come back to bite them. > > Thanks Micahel! Nicholas > -- > Micahel Wojcik > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgiles at coyotesong.com Sat Nov 3 21:55:31 2018 From: bgiles at coyotesong.com (Bear Giles) Date: Sat, 3 Nov 2018 15:55:31 -0600 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: Message-ID: > I'm considering encrypting a tar archive and optionally a block file system (via FUSE) using either utility Linux has good support for encrypted filesystems. Google LUKS. Most (all?) distros allow you to install on an encrypted filesystem and with a little bit of research you can have encrypted external drives and thumb drives. If you dig into /etc/crypttab and udevadm you can even have encrypted drives automount as long as LUKS already has your passphrase. (E.g., I'm a bad bear because I used the same passphrase on my laptop and my thumb drives.) It's not limited to passphrases - you could use a hardware device like digikey or a file containing the secret key. > I am also curious to why GPG is used for file based encryption when only a single key is required. As I recall PGP always uses a random session key* for the actual encryption. with N copies of the key encrypted using a PBE passphrase, a public key in the keyring, etc. That's how multiple people can decrypt a file even though they don't share any keys. The data itself is chunked into blocks and each block uses the same key but a different random salt. I don't recall if also it prepends or appends random data. That's a common counter to known-text attacks like knowing that a zip file always starts with the same few bytes. (* Well, "session key" when it's data-in-flight. I don't remember the term when it's data-at-rest.) BTW a tar file starts with the name of the first entry. The 'magic numbers' are at offset 128 or so. However a compressed tar file will start with a known value since gzip, b2zip, and 7zip?, all start with their magic values. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.papadonis.ml at gmail.com Sun Nov 4 23:35:44 2018 From: nick.papadonis.ml at gmail.com (Nicholas Papadonis) Date: Sun, 4 Nov 2018 18:35:44 -0500 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: Message-ID: Comments On Sat, Nov 3, 2018 at 5:56 PM Bear Giles wrote: > > I'm considering encrypting a tar archive and optionally a block file > system (via FUSE) using either utility > > Linux has good support for encrypted filesystems. Google LUKS. > > BTW a tar file starts with the name of the first entry. The 'magic > numbers' are at offset 128 or so. However a compressed tar file will start > with a known value since gzip, b2zip, and 7zip?, all start with their magic > values. > Does tar placing known data at a certain offset increase the probability that someone can perform an attack easier? They may already know the data to decrypt at that offset and if the encrypted block overlaps, then the attack is easier. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Mon Nov 5 00:21:50 2018 From: openssl at foocrypt.net (openssl at foocrypt.net) Date: Mon, 5 Nov 2018 11:21:50 +1100 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: Message-ID: <0ED0568E-0A27-43FB-B863-25FB5B40FFD3@foocrypt.net> Hi Nick Have You tried The FooKey Method ? https://foocrypt.net/the-fookey-method Also, I will be sourcing public addendum's as addendum's to my submission into the Parliamentary Joint Committee on Intelligence and Security [ https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Intelligence_and_Security/TelcoAmendmentBill2018/Submissions ] regarding the committee?s review of the 'Telecommunication and Other Legislation Amendment (Assistance and Access) Bill 2018' after the Melbourne Cup. It will be similar to the open request for the Defence Trade Control Act review performed by the former Inspector General of Intelligence, Dr Vivian Thom. https://foocrypt.net/independent-review-of-the-defence-trade-controls-act-2012-cth-call-for-information-for-submission-as-a-case-study-from-the-openssl-community -- Regards, Mark A. Lane Cryptopocalypse NOW 01 04 2016 Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @ https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11 Cryptopocalypse NOW is the story behind the trials and tribulations encountered in creating "FooCrypt, A Tale of Cynical Cyclical Encryption." "FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening several commonly used Symmetric Open Source Encryption methods so that they are hardened to a standard that is commonly termed 'QUANTUM ENCRYPTION'. "FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under export control by the Australian Department of Defence Defence Export Controls Office due to the listing of Cryptology as a ?Dual Use? Technology as per the ?Wassenaar Arrangement? A permit from Defence Export Control is expected within the next 2 months as the Australian Signals Directorate is currently assessing the associated application(s) for export approval of "FooCrypt, A Tale of Cynical Cyclical Encryption." Early releases of "Cryptopocalypse NOW" will be available in the period leading up to June, 2016. Limited Edition Collectors versions and Hard Back Editions are available via the store on http://www.foocrypt.net/ ? Mark A. Lane 1980 - 2016, All Rights Reserved. ? FooCrypt 1980 - 2016, All Rights Reserved. ? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2016, All Rights Reserved. ? Cryptopocalypse 1980 - 2016, All Rights Reserved. > On 5 Nov 2018, at 10:35, Nicholas Papadonis wrote: > > Comments > > On Sat, Nov 3, 2018 at 5:56 PM Bear Giles > wrote: > > I'm considering encrypting a tar archive and optionally a block file system (via FUSE) using either utility > > Linux has good support for encrypted filesystems. Google LUKS. > > BTW a tar file starts with the name of the first entry. The 'magic numbers' are at offset 128 or so. However a compressed tar file will start with a known value since gzip, b2zip, and 7zip?, all start with their magic values. > > Does tar placing known data at a certain offset increase the probability that someone can perform an attack easier? They may already know the data to decrypt at that offset and if the encrypted block overlaps, then the attack is easier. > > Thanks > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From thulasi.goriparthi at gmail.com Mon Nov 5 06:20:30 2018 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Mon, 5 Nov 2018 11:50:30 +0530 Subject: [openssl-users] EC_KEY_check_key In-Reply-To: <8577999d-5e1e-b61d-117c-8e8e0c3adc18@wisemo.com> References: <8577999d-5e1e-b61d-117c-8e8e0c3adc18@wisemo.com> Message-ID: >> For such tests, it's always better safe than sorry. Not sure, if repeating the same test (or the test of the same value) would add any safety. Thanks, Thulasi. On Fri, 2 Nov 2018 at 16:53, Jakob Bohm via openssl-users wrote: > > On 02/11/2018 08:50, Thulasi Goriparthi wrote: > > Hi, > > > > I am going through the checks done by EC_KEY_check_key method. I see > > the following checks in order. > > > > 1. Is point at infinity? - reject. > > 2. Is point not on curve? reject. > > 3. Is point not in the primary subgroup? reject. > > 4. If priv key(scalar) available, then check if scalar * G != point. > > If so, reject. > > > > If priv key is available and we do step 4, isn't step 3 redundant? Can > > we change this to something like this? > > > > if (priv key) > > step 4 > > else > > step 3 > > For such tests, it's always better safe than sorry. > > > 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 From Michael.Wojcik at microfocus.com Mon Nov 5 13:47:07 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 5 Nov 2018 13:47:07 +0000 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nicholas Papadonis > Sent: Saturday, November 03, 2018 13:03 > https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup Thanks. Yes, that's talking about the CBC mode malleability issue, which Hanno Boeck described. I didn't want to assume you were referring to CBC malleability, because your original email implied you were talking about an issue specific to OpenSSL and referred to a pipeline at one point. Making assumptions that discard conflicting information can be dangerous when discussing security-related matters. (CBC malleability applies to all use of CBC mode, regardless of implementation or underlying block cipher. A cryptosystem using CBC has to provide some kind of message integrity to prevent it.) > No regulatory requirements. I'm a personal user making sure to take best practices into account for > securing data. I also have the assumption that there are numerous attack vectors in involved in storing > computer data, all the way back to the design and manufacturing process. I.e. you need to design, > manufacture and test your own computer to be truly secure. As with standards, the great thing about "best practices" is there are so many sets to choose from. Here's the thing: There is no such thing as "truly secure". Security is not an absolute state. There are various ways to model it, but it's always in some sense economic. You can look at the relative costs of attack and defense, and the value of the protected system to the attacker and the defender; you want to maximize the cost of attack, preferably so that it makes access unprofitable, while keeping the cost of defense within an appropriate budget. (Note that "cost of defense" includes things like usability for authorized users and risk of data loss if a key or ciphertext is corrupted; it's not just material and effort.) You can also model security in terms of the probability of various types of adverse events (unauthorized data exposure, alteration, or loss, in this case) and the costs to you of those events - you want to minimize the sum of the probability-cost products. Understanding security as relative rather than absolute also means that "best practices" will depend on your threat model and security budget. Now, all that said: In this particular case, if you're weighing using the openssl command-line utility or gpg, use gpg (in symmetric-encryption mode). For the reasons Hanno and I mentioned here on openssl-users, and the reasons given in that StackExchange thread. The openssl utility isn't intended for this; gpg is. Some people have suggested some other alternatives, such as encrypted filesystems. There are also inexpensive encrypting USB drives and the like, which are good for some use cases. > I want to keep at least two copies of data in different locations for disaster recovery. Each copy itself should > have a backup stored with it in case of a bit error. OK. It's good to consider and mitigate various failure modes. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Mon Nov 5 14:56:15 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 5 Nov 2018 14:56:15 +0000 Subject: [openssl-users] compile warning on 32bit platform:integer constant is too large for 'long' type In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of lu zhihong > Sent: Thursday, November 01, 2018 05:58 > > when complie openssl 1.1.1 on linux 32bit platform, i met some compile > warning,like: > > crypto/ec/curve448/curve448_tables.c:415: > integer constant is too large for 'long' type > > the 64bit constant is default to 32bit long type, how should i deal with these > warning? See https://github.com/openssl/openssl/issues/7556. Here's my initial take, though it's based only on a quick discussion with the developer here who raised that issue. I haven't tried modifying the OpenSSL sources yet. The warnings are caused by hexadecimal constants (0x...) that are larger than 32 bits. C99 and later requires that the implementation use the smallest suitable type for a hex integer constant, up to and including unsigned long long. See ISO 9899-1999 6.4.4.1 #5. (This is also true for octal constants, but not decimal ones. I haven't looked in the Rationale to see if the committee explained this decision.) C89/C90 and C94 don't have the "long long" types. Consequently, when compiling the OpenSSL 1.1.1 sources using an implementation that's running in a C90 or C94 mode, and is using an IL32 integer representation, the compiler is quite right to complain about those constants. (Of course, the standard lets an implementation issue any diagnostic for any reason whatsoever, but well-behaved C99 implementations shouldn't complain about those constants.) I think two fixes are required: 1. All platform configurations should specify a C99-conforming, or C99-plus-extensions, or later version of C, mode where available. In the issue report Simon mentions that the AIX configuration using IBM's xlC (or C Set or whatever IBM is calling it this week) is not using C99 mode, for example. That is a Bad Thing. When xlC is invoked as "cc" and no -qlanglvl option is used, it defaults to the C89-plus-extensions mode from the IBM RT PC. The OpenSSL configure script should be using CC=xlc or adding the appropriate -qlanglvl option for this platform. With GCC on Linux (or anywhere else) there's probably some option to enable C99-plus-extensions and have those integer constants interpreted as unsigned long long even in 32-bit builds. I don't blame the OpenSSL maintainers here - users (this includes me) should be submitting better configurations for the platforms we use. When we (here at the division of Micro Focus which Simon and I work in) finish our OpenSSL 1.1.1 testing, we plan to experiment with various updates like this and submit issues and pull requests. 2. The constants in question should have the "ULL" suffix, indicating they're expected to be interpreted as unsigned long long. Since "ULL" was not defined prior to C99, this should cause compilation of the affected sources to fail when the implementation doesn't support unsigned long long. That's better than a bunch of warnings which many people are likely to ignore. If there are platforms which support 64-bit integer constants but not the "ULL" suffix, we could hide this behind a token-pasting macro. But as I wrote above, I haven't tested those yet. -- Michael Wojcik Distinguished Engineer, Micro Focus From jb-openssl at wisemo.com Mon Nov 5 20:27:00 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 5 Nov 2018 21:27:00 +0100 Subject: [openssl-users] EC_KEY_check_key In-Reply-To: References: <8577999d-5e1e-b61d-117c-8e8e0c3adc18@wisemo.com> Message-ID: <8babba15-e1e6-975c-052b-485a8feb9139@wisemo.com> On 05/11/2018 07:20, Thulasi Goriparthi wrote: >>> For such tests, it's always better safe than sorry. > > Not sure, if repeating the same test (or the test of the same value) > would add any safety. > The safety is in avoiding creating some situation where its tested zero times because each test assumes the other test does it. > On Fri, 2 Nov 2018 at 16:53, Jakob Bohm via openssl-users > wrote: >> >> On 02/11/2018 08:50, Thulasi Goriparthi wrote: >>> Hi, >>> >>> I am going through the checks done by EC_KEY_check_key method. I see >>> the following checks in order. >>> >>> 1. Is point at infinity? - reject. >>> 2. Is point not on curve? reject. >>> 3. Is point not in the primary subgroup? reject. >>> 4. If priv key(scalar) available, then check if scalar * G != point. >>> If so, reject. >>> >>> If priv key is available and we do step 4, isn't step 3 redundant? Can >>> we change this to something like this? >>> >>> if (priv key) >>> step 4 >>> else >>> step 3 >> >> For such tests, it's always better safe than sorry. >> 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 From jb-openssl at wisemo.com Mon Nov 5 20:42:25 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 5 Nov 2018 21:42:25 +0100 Subject: [openssl-users] compile warning on 32bit platform:integer constant is too large for 'long' type In-Reply-To: References: Message-ID: <1ba280f6-f2f8-f1f6-94ca-370bb92376b1@wisemo.com> On 05/11/2018 15:56, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of lu zhihong >> Sent: Thursday, November 01, 2018 05:58 >> >> when complie openssl 1.1.1 on linux 32bit platform, i met some compile >> warning,like: >> >> crypto/ec/curve448/curve448_tables.c:415: >> integer constant is too large for 'long' type >> >> the 64bit constant is default to 32bit long type, how should i deal with these >> warning? > See https://github.com/openssl/openssl/issues/7556. > > Here's my initial take, though it's based only on a quick discussion with the developer here who raised that issue. I haven't tried modifying the OpenSSL sources yet. > > The warnings are caused by hexadecimal constants (0x...) that are larger than 32 bits. > > C99 and later requires that the implementation use the smallest suitable type for a hex integer constant, up to and including unsigned long long. See ISO 9899-1999 6.4.4.1 #5. (This is also true for octal constants, but not decimal ones. I haven't looked in the Rationale to see if the committee explained this decision.) > > C89/C90 and C94 don't have the "long long" types. > > Consequently, when compiling the OpenSSL 1.1.1 sources using an implementation that's running in a C90 or C94 mode, and is using an IL32 integer representation, the compiler is quite right to complain about those constants. (Of course, the standard lets an implementation issue any diagnostic for any reason whatsoever, but well-behaved C99 implementations shouldn't complain about those constants.) > > I think two fixes are required: > > 1. All platform configurations should specify a C99-conforming, or C99-plus-extensions, or later version of C, mode where available. In the issue report Simon mentions that the AIX configuration using IBM's xlC (or C Set or whatever IBM is calling it this week) is not using C99 mode, for example. That is a Bad Thing. When xlC is invoked as "cc" and no -qlanglvl option is used, it defaults to the C89-plus-extensions mode from the IBM RT PC. The OpenSSL configure script should be using CC=xlc or adding the appropriate -qlanglvl option for this platform. With GCC on Linux (or anywhere else) there's probably some option to enable C99-plus-extensions and have those integer constants interpreted as unsigned long long even in 32-bit builds. > I don't blame the OpenSSL maintainers here - users (this includes me) should be submitting better configurations for the platforms we use. When we (here at the division of Micro Focus which Simon and I work in) finish our OpenSSL 1.1.1 testing, we plan to experiment with various updates like this and submit issues and pull requests. > > 2. The constants in question should have the "ULL" suffix, indicating they're expected to be interpreted as unsigned long long. Since "ULL" was not defined prior to C99, this should cause compilation of the affected sources to fail when the implementation doesn't support unsigned long long. That's better than a bunch of warnings which many people are likely to ignore. If there are platforms which support 64-bit integer constants but not the "ULL" suffix, we could hide this behind a token-pasting macro. > > But as I wrote above, I haven't tested those yet. Note that requiring C99 would break compatibility with older platforms such as CE 5.x, so that is not a viable option. Lots of pre-C99 compilers do have either the "unsigned long long" or "unsigned __int64" type (or both) with corresponding constant suffixes of ull and ui64.? Other pre-C99 compilers make "unsigned long" (ul) 64 bit. However I would doubt the sanity of a compiler warning about array initialization constants that are in range for the array member type, even if they are not in range for some other expression type. Thus for constants used in array initialization, it may be better to use compiler specific command line options for each picky compiler. For other compilers maybe there is a common OpenSSL internal macro that appends ull or ui64 or ul as appropriate to the compiler+arch target (we use such a macro for in-house code). 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 From jb-openssl at wisemo.com Mon Nov 5 20:49:09 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 5 Nov 2018 21:49:09 +0100 Subject: [openssl-users] a problem connecting to a specific Site ... In-Reply-To: <5BDD5496.7080501@mathemainzel.info> References: <5BDCC6EA.1050902@mathemainzel.info> <39f2fbd8-a9d9-79db-fcba-d1b26e6eb6dd@openssl.org> <5BDD5496.7080501@mathemainzel.info> Message-ID: <8eee5ef3-eed9-4f65-3913-0028421aeeda@wisemo.com> On 03/11/2018 08:56, Walter H. wrote: > Hello, > > it is a little bitte weird/strange/complicated; > > On 02.11.2018 23:05, Matt Caswell wrote: >> On 02/11/2018 21:51, Walter H. wrote: >>> Hello, >>> >>> when I try to connect tohttps://www.3bg.at/ >>> I get the following error >>> >>> Handshake with SSL server failed: error:1408E0F4:SSL >>> routines:SSL3_GET_MESSAGE:unexpected message >>> >>> but >>> https://www.ssllabs.com/ssltest/analyze.html?d=www.3bg.at >>> says its ok ... >>> >>> is the problem on my side or on their side? >> You'll need to give us more information. I can connect to that server >> using OpenSSL 1.0.2 s_client. >> >> What version of OpenSSL are you using? Is this with your own application >> or from s_client? What ciphersuites have you configured? Any other >> relevant configuration that we should know about? >> >> > the mentioned error comes with squid - ssl-bump on; > in case I switch it off and have it as normal proxy, then is really > suspisious: > - an old Firefox (17.0.11esr) has no problems, the Sites is shown and > works > > - an older Google Chrome (the last one f. WinXP, v46) gives: > ? ? ? ? ? ? ? ? ? ??? SSL connection error > ????????????????????? ERR_SSL_PROTOCOL_ERROR > > - a fork of the latest Pale Moon (Mypal) and an old Palemoon itself > (the last one f. WinXP) gives: > ? ? ? ? ? ? ? ? ? ? An error occurred during a connection to www.3bg.at. > ??????????????????? Peer?s certificate has an invalid signature. > ??????????????????? (Error code: SEC_ERROR_BAD_SIGNATURE) > > what is this strange? > > but what does this mean at the mentioned SSLlabs result: > > Certificate Transparency No > > when I compare to any other site (e.g. my own with Let's encrypt > certificate), > I get > > Certificate Transparency *Yes (certificate)* > > is this caused on my side or on the other side? > > Certificate Transparency means that the CA that issued the certificate also published it using a Google-promoted protocol to provide "Transparency" for the certificate issuing industry, at the cost of customer privacy. Chrome Browser now (or soon) punishes websites that whose certificate was not published that way, making it a relevant test for web server operators wanting to check that everything will work in all browsers. 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 From jb-openssl at wisemo.com Mon Nov 5 21:06:11 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 5 Nov 2018 22:06:11 +0100 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: <20181103101125.329fcc4c@computer> References: <20181103101125.329fcc4c@computer> Message-ID: <6ab785fc-3b5b-9ee0-ef92-bb0e551c4c23@wisemo.com> On 03/11/2018 10:11, Hanno B?ck wrote: > On Sat, 3 Nov 2018 12:28:02 +0500 > ???? ????????? wrote: > >> Try openssl cms ( as newer alternative to s/mime) > cms is not newer than s/mime, it's the underlying message format of > s/mime. > > According to this > https://www.openssl.org/docs/man1.0.2/apps/openssl.html > it only supports deprecated cipher modes (cbc, cfb, ofb, ecb) and has > exactly the malleability vulnerability the original poster was asking > about (including a wide variety of obscure and some insecure ciphers). I > don't think this should be recommended. > For clarity, the "openssl smime" and "openssl cms" commands to provide mostly complete cryptosystems and are used as the S/MIME implementation for some respected e-mail clients that also use the gpg command line for OpenPGP messages. Also the "openssl smime" command (and underlying OpenSSL API) has from time to time been described as superseded by the "openssl cms" command (and API), though there are holes in the backward compatibility. Now the S/MIME and CMS encryption standard may suffer from lack of integrity checks when not carefully combined with the signing feature of that same crypto system. There are other subcommands of the openssl command line utility which are similarly respected high level operations rather than the low level primitive operations also available such as "enc". 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 From adam.lang at ecolane.com Mon Nov 5 21:51:15 2018 From: adam.lang at ecolane.com (EcolaneAdam) Date: Mon, 5 Nov 2018 14:51:15 -0700 (MST) Subject: [openssl-users] Trouble installing openssl 1.1.0 on Ubuntu 14.04 Message-ID: <1541454675952-0.post@n7.nabble.com> Hello, Several months ago I had configured ansible to deploy openssl upgrades to our Ubuntu 14.04 servers and did so with the following version via apt module: - libssl-dev=1.1.0h-2.0+ubuntu14.04.1+deb.sury.org+1 - openssl=1.1.0h-2.0+ubuntu14.04.1+deb.sury.org+1 Now when doing deployments I am getting that the version is not found. I am having trouble finding the correct version to reference. Anything I have tried hasn't worked. Any ideas? -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From thomas.schmiedl at web.de Mon Nov 5 22:58:32 2018 From: thomas.schmiedl at web.de (Thomas Schmiedl) Date: Mon, 5 Nov 2018 23:58:32 +0100 Subject: [openssl-users] Add OpenSSL-support to a project Message-ID: <2885a61a-c6f2-baf1-014e-52a1e4af505e@web.de> Hello, I use xupnpd2-mediaserver (http://xupnpd.org/xupnpd2_en.html) on my router to display HLS-streams on my TV. Some HLS-streams require a https-connection. I contacted the xupnpd2-author several times but I didn't get a reply. Since some days, he published the source (https://github.com/clark15b/xupnpd2). I'm not a developer, but I hope that someone in this mailinglist could integrate the OpenSSL/https-support to the xupnpd2 source. Best regards, Thomas From a.chris.clark at gmail.com Tue Nov 6 20:38:53 2018 From: a.chris.clark at gmail.com (Chris Clark) Date: Tue, 6 Nov 2018 12:38:53 -0800 Subject: [openssl-users] Exclude unwanted ciphers during build Message-ID: Is there a simple way of excluding unwanted ciphers or cipher suites during a build? I would like to remove ARIA in particular, but may want to remove additional ones in order to use a smaller footprint. From pgnet.dev at gmail.com Tue Nov 6 20:45:29 2018 From: pgnet.dev at gmail.com (pgndev) Date: Tue, 6 Nov 2018 12:45:29 -0800 Subject: [openssl-users] Exclude unwanted ciphers during build In-Reply-To: References: Message-ID: https://wiki.openssl.org/index.php/Compilation_and_Installation Usage: Configure [no- ...] [enable- ...] ... ^^^^^^^^^^^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Tue Nov 6 21:52:28 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 6 Nov 2018 21:52:28 +0000 Subject: [openssl-users] Exclude unwanted ciphers during build In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of pgndev > Sent: Tuesday, November 06, 2018 15:45 > https://wiki.openssl.org/index.php/Compilation_and_Installation > Usage: Configure [no- ...] [enable- ...] ... And it's documented in the INSTALL file in the tarball. Of course, details (e.g. which ciphers are available) depend on what version the OP is trying to builld - information he neglected to provide. I know, I know: mentioning ARIA implies 1.1.1. But folks, *tell us what version you're using*. That should be automatic any time you post a question to any public forum about any software product. -- Michael Wojcik Distinguished Engineer, Micro Focus From paul.davis at curatess.com Tue Nov 6 22:02:27 2018 From: paul.davis at curatess.com (Paul) Date: Tue, 6 Nov 2018 16:02:27 -0600 Subject: [openssl-users] updating openssl Message-ID: I configured Openvpn server on ubuntu 16.04 and ubuntu was using a old version of openssl 1.0.2 and I was updating openssl to v1.1.1 Now I've installed the openssl but now unable to mv file installed to ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl failed to create symbolic link '/usr/bin/openssl': File exists but then when I use openssl version /usr/bin/openssl: No such file or directory how can I correct this? Paul -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From misaki.miyashita at oracle.com Tue Nov 6 22:19:36 2018 From: misaki.miyashita at oracle.com (Misaki Miyashita) Date: Tue, 6 Nov 2018 16:19:36 -0600 Subject: [openssl-users] OpenSSL 1.0.2: CVE-2018-0735 Message-ID: <03abeaba-0ece-272a-d915-2d18c0cd6df6@oracle.com> Hi, According to the vulnerabilities website[1], OpenSSL 1.1.i and earlier and 1.1.1 are affected by CVE-2018-0735. Is it safe to assume that OpenSSL 1.0.2 is not affected by the CVE? Thank you, -- misaki [1] https://www.openssl.org/news/vulnerabilities.html CVE-2018-0735 (OpenSSL advisory) [Low severity] 29 October 2018: ??? The OpenSSL ECDSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Reported by Samuel Weiser. ??????? Fixed in OpenSSL 1.1.1a-dev (git commit) (Affected 1.1.1) ??????? Fixed in OpenSSL 1.1.0j-dev (git commit) (Affected 1.1.0-1.1.0i) From wiml at omnigroup.com Tue Nov 6 22:32:56 2018 From: wiml at omnigroup.com (Wim Lewis) Date: Tue, 6 Nov 2018 14:32:56 -0800 Subject: [openssl-users] updating openssl In-Reply-To: References: Message-ID: On 6. n?v. 2018, at 2:02 e.h., Paul wrote: > I configured Openvpn server on ubuntu 16.04 and ubuntu was using a old version of openssl 1.0.2 and I was updating openssl to v1.1.1 > Now I've installed the openssl but now unable to mv file installed to ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl > failed to create symbolic link '/usr/bin/openssl': File exists > > but then when I use openssl version > /usr/bin/openssl: No such file or directory This is really a general unix question: I suspect you have a dangling symbolic link in /usr/bin, pointing to a (now-deleted) old copy of openssl. If so, you can just rm the dangling symbolic link. From terry.y.t.chong at gmail.com Tue Nov 6 22:46:52 2018 From: terry.y.t.chong at gmail.com (Terry Chong) Date: Tue, 6 Nov 2018 14:46:52 -0800 Subject: [openssl-users] In-place encryption/decryption via the EVP_* APIs Message-ID: Hi, I am planning on using EVP_* APIs to encrypt/decrypt my data. One thing I am wondering about is whether I can do in-place encryption, meaning I don't have to pay the price of an extra memory buffer to store my cipher text and a potential memcpy back to the source buffer. I tried that with the EVP_* APIs by essentially passing in the same buffer to the plaintext and cipher text input pointers, and it seems to work. I am using AES XTS mode, and I understand that that may not work if I were to use a different mode. I am wondering if this behavior for AES XTS that allows in-place encryption/decryption is going to stay? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.papadonis.ml at gmail.com Wed Nov 7 05:14:58 2018 From: nick.papadonis.ml at gmail.com (Nicholas Papadonis) Date: Wed, 7 Nov 2018 00:14:58 -0500 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: <0ED0568E-0A27-43FB-B863-25FB5B40FFD3@foocrypt.net> References: <0ED0568E-0A27-43FB-B863-25FB5B40FFD3@foocrypt.net> Message-ID: Interesting. How about this for a start? http://nickpapadonis.com/images-share/summerian-ancient-mesopotamia-ancient-lock.jpg http://nickpapadonis.com/images-share/anunnaki1.jpg http://nickpapadonis.com/images-share/summerian-Winged_Human-headed_Bulls.JPG On Sun, Nov 4, 2018 at 7:21 PM openssl at foocrypt.net wrote: > Hi Nick > > Have You tried The FooKey Method ? https://foocrypt.net/the-fookey-method > > Also, > > I will be sourcing public addendum's as addendum's to my submission into > the Parliamentary Joint Committee on Intelligence and Security [ > https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Intelligence_and_Security/TelcoAmendmentBill2018/Submissions > ] regarding the committee?s review of the 'Telecommunication and Other > Legislation Amendment (Assistance and Access) Bill 2018' after the > Melbourne Cup. It will be similar to the open request for the Defence Trade > Control Act review performed by the former Inspector General of > Intelligence, Dr Vivian Thom. > > > https://foocrypt.net/independent-review-of-the-defence-trade-controls-act-2012-cth-call-for-information-for-submission-as-a-case-study-from-the-openssl-community > > > -- > > Regards, > > Mark A. Lane > > Cryptopocalypse NOW 01 04 2016 > > Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @ > https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11 > > Cryptopocalypse NOW is the story behind the trials and tribulations > encountered in creating "FooCrypt, A Tale of Cynical Cyclical Encryption." > > "FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening > several commonly used Symmetric Open Source Encryption methods so that they > are hardened to a standard that is commonly termed 'QUANTUM ENCRYPTION'. > > "FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under > export control by the Australian Department of Defence Defence Export > Controls Office due to the listing of Cryptology as a ?Dual Use? Technology > as per the ?Wassenaar Arrangement? > > A permit from Defence Export Control is expected within the next 2 months > as the Australian Signals Directorate is currently assessing the associated > application(s) for export approval of "FooCrypt, A Tale of Cynical Cyclical > Encryption." > > Early releases of "Cryptopocalypse NOW" will be available in the period > leading up to June, 2016. > > Limited Edition Collectors versions and Hard Back Editions are available > via the store on http://www.foocrypt.net/ > > ? Mark A. Lane 1980 - 2016, All Rights Reserved. > ? FooCrypt 1980 - 2016, All Rights Reserved. > ? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2016, All Rights > Reserved. > ? Cryptopocalypse 1980 - 2016, All Rights Reserved. > > > > On 5 Nov 2018, at 10:35, Nicholas Papadonis > wrote: > > Comments > > On Sat, Nov 3, 2018 at 5:56 PM Bear Giles wrote: > >> > I'm considering encrypting a tar archive and optionally a block file >> system (via FUSE) using either utility >> >> Linux has good support for encrypted filesystems. Google LUKS. >> > > >> BTW a tar file starts with the name of the first entry. The 'magic >> numbers' are at offset 128 or so. However a compressed tar file will start >> with a known value since gzip, b2zip, and 7zip?, all start with their magic >> values. >> > > Does tar placing known data at a certain offset increase the probability > that someone can perform an attack easier? They may already know the data > to decrypt at that offset and if the encrypted block overlaps, then the > attack is easier. > > Thanks > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Nov 7 06:57:36 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 07 Nov 2018 07:57:36 +0100 (CET) Subject: [openssl-users] Trouble installing openssl 1.1.0 on Ubuntu 14.04 In-Reply-To: <1541454675952-0.post@n7.nabble.com> References: <1541454675952-0.post@n7.nabble.com> Message-ID: <20181107.075736.1331114911695986150.levitte@openssl.org> In message <1541454675952-0.post at n7.nabble.com> on Mon, 5 Nov 2018 14:51:15 -0700 (MST), EcolaneAdam said: > Hello, > > Several months ago I had configured ansible to deploy openssl upgrades to > our Ubuntu 14.04 servers and did so with the following version via apt > module: > - libssl-dev=1.1.0h-2.0+ubuntu14.04.1+deb.sury.org+1 > - openssl=1.1.0h-2.0+ubuntu14.04.1+deb.sury.org+1 > > Now when doing deployments I am getting that the version is not found. I am > having trouble finding the correct version to reference. Anything I have > tried hasn't worked. > > Any ideas? Those package names told me I could have a look at http://deb.sury.org, and sure enough, there was something there, with a PPA link: https://launchpad.net/~ondrej/+archive/ubuntu/php/ You can see the full (I assume) list of available packages there, and for OpenSSL, I find these: 1.1.1-2+ubuntu18.10.1+deb.sury.org+2 1.1.1-2+ubuntu18.04.1+deb.sury.org+2 1.1.1-2+ubuntu16.04.1+deb.sury.org+2 1.1.1-2+ubuntu14.04.1+deb.sury.org+2 So it looks to me like you're being forced to upgrade. Note that 1.1.1 is forward compatible with 1.1.0h, so that upgrade should go smoothly. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Wed Nov 7 07:12:27 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 07 Nov 2018 08:12:27 +0100 (CET) Subject: [openssl-users] In-place encryption/decryption via the EVP_* APIs In-Reply-To: References: Message-ID: <20181107.081227.719330469946201828.levitte@openssl.org> In message on Tue, 6 Nov 2018 14:46:52 -0800, Terry Chong said: > Hi, I am planning on using EVP_* APIs to encrypt/decrypt my data. One thing I am wondering > about is whether I can do in-place encryption, meaning I don't have to pay the price of an extra > memory buffer to store my cipher text and a potential memcpy back to the source buffer. > > I tried that with the EVP_* APIs by essentially passing in the same buffer to the plaintext and cipher > text input pointers, and it seems to work. I am using AES XTS mode, and I understand that that > may not work if I were to use a different mode. > > I am wondering if this behavior for AES XTS that allows in-place encryption/decryption is going to > stay? test/evp_test.c does a number of tests on all ciphers we have test vectors for, including overlapping buffers (i.e. input and output buffer are the same). So that is to say that if that behaviour ever stopped working, we would certainly notice. Does that help? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From bgiles at coyotesong.com Wed Nov 7 14:26:56 2018 From: bgiles at coyotesong.com (Bear Giles) Date: Wed, 7 Nov 2018 07:26:56 -0700 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: <0ED0568E-0A27-43FB-B863-25FB5B40FFD3@foocrypt.net> Message-ID: FWIW I distrust encrypted drives using hardware encryption. This came out just a few days ago: https://thehackernews.com/2018/11/self-encrypting-ssd-hacking.html: Flaws in Popular Self-Encrypting SSDs Let Attackers Decrypt Data. On Tue, Nov 6, 2018 at 10:15 PM Nicholas Papadonis < nick.papadonis.ml at gmail.com> wrote: > Interesting. How about this for a start? > > > http://nickpapadonis.com/images-share/summerian-ancient-mesopotamia-ancient-lock.jpg > http://nickpapadonis.com/images-share/anunnaki1.jpg > > http://nickpapadonis.com/images-share/summerian-Winged_Human-headed_Bulls.JPG > > On Sun, Nov 4, 2018 at 7:21 PM openssl at foocrypt.net > wrote: > >> Hi Nick >> >> Have You tried The FooKey Method ? https://foocrypt.net/the-fookey-method >> >> Also, >> >> I will be sourcing public addendum's as addendum's to my submission into >> the Parliamentary Joint Committee on Intelligence and Security [ >> https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Intelligence_and_Security/TelcoAmendmentBill2018/Submissions >> ] regarding the committee?s review of the 'Telecommunication and Other >> Legislation Amendment (Assistance and Access) Bill 2018' after the >> Melbourne Cup. It will be similar to the open request for the Defence Trade >> Control Act review performed by the former Inspector General of >> Intelligence, Dr Vivian Thom. >> >> >> https://foocrypt.net/independent-review-of-the-defence-trade-controls-act-2012-cth-call-for-information-for-submission-as-a-case-study-from-the-openssl-community >> >> >> -- >> >> Regards, >> >> Mark A. Lane >> >> Cryptopocalypse NOW 01 04 2016 >> >> Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @ >> https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11 >> >> Cryptopocalypse NOW is the story behind the trials and tribulations >> encountered in creating "FooCrypt, A Tale of Cynical Cyclical Encryption." >> >> "FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening >> several commonly used Symmetric Open Source Encryption methods so that they >> are hardened to a standard that is commonly termed 'QUANTUM ENCRYPTION'. >> >> "FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under >> export control by the Australian Department of Defence Defence Export >> Controls Office due to the listing of Cryptology as a ?Dual Use? Technology >> as per the ?Wassenaar Arrangement? >> >> A permit from Defence Export Control is expected within the next 2 months >> as the Australian Signals Directorate is currently assessing the associated >> application(s) for export approval of "FooCrypt, A Tale of Cynical Cyclical >> Encryption." >> >> Early releases of "Cryptopocalypse NOW" will be available in the period >> leading up to June, 2016. >> >> Limited Edition Collectors versions and Hard Back Editions are available >> via the store on http://www.foocrypt.net/ >> >> ? Mark A. Lane 1980 - 2016, All Rights Reserved. >> ? FooCrypt 1980 - 2016, All Rights Reserved. >> ? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2016, All >> Rights Reserved. >> ? Cryptopocalypse 1980 - 2016, All Rights Reserved. >> >> >> >> On 5 Nov 2018, at 10:35, Nicholas Papadonis >> wrote: >> >> Comments >> >> On Sat, Nov 3, 2018 at 5:56 PM Bear Giles wrote: >> >>> > I'm considering encrypting a tar archive and optionally a block file >>> system (via FUSE) using either utility >>> >>> Linux has good support for encrypted filesystems. Google LUKS. >>> >> >> >>> BTW a tar file starts with the name of the first entry. The 'magic >>> numbers' are at offset 128 or so. However a compressed tar file will start >>> with a known value since gzip, b2zip, and 7zip?, all start with their magic >>> values. >>> >> >> Does tar placing known data at a certain offset increase the probability >> that someone can perform an attack easier? They may already know the data >> to decrypt at that offset and if the encrypted block overlaps, then the >> attack is easier. >> >> Thanks >> -- >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry.y.t.chong at gmail.com Wed Nov 7 14:44:34 2018 From: terry.y.t.chong at gmail.com (Terry Chong) Date: Wed, 7 Nov 2018 06:44:34 -0800 Subject: [openssl-users] In-place encryption/decryption via the EVP_* APIs In-Reply-To: <20181107.081227.719330469946201828.levitte@openssl.org> References: <20181107.081227.719330469946201828.levitte@openssl.org> Message-ID: <8B09B834-8FB6-48B8-8BBF-179EC13A0809@gmail.com> Yes it does, thank you Richard! Regards, Terry > On Nov 6, 2018, at 11:12 PM, Richard Levitte wrote: > > In message on Tue, 6 Nov 2018 14:46:52 -0800, Terry Chong said: > >> Hi, I am planning on using EVP_* APIs to encrypt/decrypt my data. One thing I am wondering >> about is whether I can do in-place encryption, meaning I don't have to pay the price of an extra >> memory buffer to store my cipher text and a potential memcpy back to the source buffer. >> >> I tried that with the EVP_* APIs by essentially passing in the same buffer to the plaintext and cipher >> text input pointers, and it seems to work. I am using AES XTS mode, and I understand that that >> may not work if I were to use a different mode. >> >> I am wondering if this behavior for AES XTS that allows in-place encryption/decryption is going to >> stay? > > test/evp_test.c does a number of tests on all ciphers we have test > vectors for, including overlapping buffers (i.e. input and output > buffer are the same). So that is to say that if that behaviour ever > stopped working, we would certainly notice. > > Does that help? > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl at foocrypt.net Wed Nov 7 14:57:34 2018 From: openssl at foocrypt.net (openssl at foocrypt.net) Date: Thu, 8 Nov 2018 01:57:34 +1100 Subject: [openssl-users] OpenSSL vs GPG for encrypting files? Security best practices? In-Reply-To: References: <0ED0568E-0A27-43FB-B863-25FB5B40FFD3@foocrypt.net> Message-ID: Ditto, But don?t tell the Australian Government, it?s probably on their back door request list?;) > On 8 Nov 2018, at 01:26, Bear Giles wrote: > > FWIW I distrust encrypted drives using hardware encryption. This came out just a few days ago: https://thehackernews.com/2018/11/self-encrypting-ssd-hacking.html : Flaws in Popular Self-Encrypting SSDs Let Attackers Decrypt Data. > > On Tue, Nov 6, 2018 at 10:15 PM Nicholas Papadonis > wrote: > Interesting. How about this for a start? > > http://nickpapadonis.com/images-share/summerian-ancient-mesopotamia-ancient-lock.jpg > http://nickpapadonis.com/images-share/anunnaki1.jpg > http://nickpapadonis.com/images-share/summerian-Winged_Human-headed_Bulls.JPG > > On Sun, Nov 4, 2018 at 7:21 PM openssl at foocrypt.net > wrote: > Hi Nick > > Have You tried The FooKey Method ? https://foocrypt.net/the-fookey-method > > Also, > > I will be sourcing public addendum's as addendum's to my submission into the Parliamentary Joint Committee on Intelligence and Security [ https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Intelligence_and_Security/TelcoAmendmentBill2018/Submissions ] regarding the committee?s review of the 'Telecommunication and Other Legislation Amendment (Assistance and Access) Bill 2018' after the Melbourne Cup. It will be similar to the open request for the Defence Trade Control Act review performed by the former Inspector General of Intelligence, Dr Vivian Thom. > > https://foocrypt.net/independent-review-of-the-defence-trade-controls-act-2012-cth-call-for-information-for-submission-as-a-case-study-from-the-openssl-community > > > -- > > Regards, > > Mark A. Lane > > Cryptopocalypse NOW 01 04 2016 > > Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @ https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11 > > Cryptopocalypse NOW is the story behind the trials and tribulations encountered in creating "FooCrypt, A Tale of Cynical Cyclical Encryption." > > "FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening several commonly used Symmetric Open Source Encryption methods so that they are hardened to a standard that is commonly termed 'QUANTUM ENCRYPTION'. > > "FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under export control by the Australian Department of Defence Defence Export Controls Office due to the listing of Cryptology as a ?Dual Use? Technology as per the ?Wassenaar Arrangement? > > A permit from Defence Export Control is expected within the next 2 months as the Australian Signals Directorate is currently assessing the associated application(s) for export approval of "FooCrypt, A Tale of Cynical Cyclical Encryption." > > Early releases of "Cryptopocalypse NOW" will be available in the period leading up to June, 2016. > > Limited Edition Collectors versions and Hard Back Editions are available via the store on http://www.foocrypt.net/ > > ? Mark A. Lane 1980 - 2016, All Rights Reserved. > ? FooCrypt 1980 - 2016, All Rights Reserved. > ? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2016, All Rights Reserved. > ? Cryptopocalypse 1980 - 2016, All Rights Reserved. > > > >> On 5 Nov 2018, at 10:35, Nicholas Papadonis > wrote: >> >> Comments >> >> On Sat, Nov 3, 2018 at 5:56 PM Bear Giles > wrote: >> > I'm considering encrypting a tar archive and optionally a block file system (via FUSE) using either utility >> >> Linux has good support for encrypted filesystems. Google LUKS. >> >> BTW a tar file starts with the name of the first entry. The 'magic numbers' are at offset 128 or so. However a compressed tar file will start with a known value since gzip, b2zip, and 7zip?, all start with their magic values. >> >> Does tar placing known data at a certain offset increase the probability that someone can perform an attack easier? They may already know the data to decrypt at that offset and if the encrypted block overlaps, then the attack is easier. >> >> Thanks >> -- >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From misaki.miyashita at oracle.com Wed Nov 7 17:23:22 2018 From: misaki.miyashita at oracle.com (Misaki Miyashita) Date: Wed, 7 Nov 2018 11:23:22 -0600 Subject: [openssl-users] OpenSSL 1.0.2: CVE-2018-5407 PortSmash Message-ID: <6ab943ac-be55-5f3d-bc80-e0e39672e3ee@oracle.com> Hi, According to the following website: ??? https://www.openwall.com/lists/oss-security/2018/11/01/4 OpenSSL <= 1.1.0h is affected. Does that mean the problem also exist in the OpenSSL 1.0.2 release? Thank you, -- misaki From janjust at nikhef.nl Thu Nov 8 09:49:47 2018 From: janjust at nikhef.nl (Jan Just Keijser) Date: Thu, 8 Nov 2018 10:49:47 +0100 Subject: [openssl-users] Add OpenSSL-support to a project In-Reply-To: <2885a61a-c6f2-baf1-014e-52a1e4af505e@web.de> References: <2885a61a-c6f2-baf1-014e-52a1e4af505e@web.de> Message-ID: <21cedb82-3ee3-340a-9ac7-cb9f07bf006b@nikhef.nl> On 05/11/18 23:58, Thomas Schmiedl wrote: > Hello, > > I use xupnpd2-mediaserver (http://xupnpd.org/xupnpd2_en.html) on my router to display HLS-streams on my TV. > > Some HLS-streams require a https-connection. I contacted the xupnpd2-author several times but I didn't get a reply. Since some > days, he published the source (https://github.com/clark15b/xupnpd2). > > I'm not a developer, but I hope that someone in this mailinglist could integrate the OpenSSL/https-support to the xupnpd2 source. > I hate to be blunt, but 1) really, wrong forum to ask: the openssl users list is not a place to ask for "please add OpenSSL support to XXX" 2) when I look at the sources for xupnpd2, it already *HAS* openssl support - simply rebuild it to get openssl support 3) you are not mentioning anything about the OS of your TV - most likely you will need to set up a special build environment to build apps for your TV.? Again, this would not be the right forum to ask for support on that. regards, JJK From bbrumley at gmail.com Thu Nov 8 12:26:41 2018 From: bbrumley at gmail.com (Billy Brumley) Date: Thu, 8 Nov 2018 14:26:41 +0200 Subject: [openssl-users] OpenSSL 1.0.2: CVE-2018-5407 PortSmash In-Reply-To: <6ab943ac-be55-5f3d-bc80-e0e39672e3ee@oracle.com> References: <6ab943ac-be55-5f3d-bc80-e0e39672e3ee@oracle.com> Message-ID: Howdy, > According to the following website: > https://www.openwall.com/lists/oss-security/2018/11/01/4 > > OpenSSL <= 1.1.0h is affected. > Does that mean the problem also exist in the OpenSSL 1.0.2 release? Yes, it does. Pending review: https://github.com/openssl/openssl/pull/7593 BBB From beldmit at gmail.com Thu Nov 8 12:44:56 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 8 Nov 2018 15:44:56 +0300 Subject: [openssl-users] x509 manual Message-ID: Hello, can anybody clarify what for the abbreviations AVA and RDN stand for? ============ sep_comma_plus, sep_comma_plus_space, sep_semi_plus_space, sep_multiline These options determine the field separators. The first character is between RDNs and the second between multiple AVAs (multiple AVAs are very rare and their use is discouraged). The options ending in "space" additionally place a space after the separator to make it more readable. The sep_multiline uses a linefeed character for the RDN separator and a spaced + for the AVA separator. It also indents the fields by four characters. If no field separator is specified then sep_comma_plus_space is used by default. ============= Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Nov 8 13:01:57 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Nov 2018 13:01:57 +0000 Subject: [openssl-users] x509 manual In-Reply-To: References: Message-ID: <6f456c92-0aec-3483-f7f5-14d3e0665e72@openssl.org> On 08/11/2018 12:44, Dmitry Belyavsky wrote: > Hello, > > can anybody clarify what for the abbreviations AVA and RDN stand for? RDN == Relative Distinguised Name AVA == Attribute Value Assertion An RDN consists of an unordered set of AVAs (but most frequently an RDN is made up of exactly one AVA, e.g. CN = "John"). A Distinguished Name (DN) is made up of a sequence of RDNs. That man page could probably do with some work to reduce the jargon. Matt > > ============ > sep_comma_plus, sep_comma_plus_space, sep_semi_plus_space, sep_multiline > These options determine the field separators. The first character is > between RDNs and the second between multiple AVAs (multiple AVAs are > very rare and their use is discouraged). The options ending in "space" > additionally place a space after the separator to make it more readable. > The sep_multiline uses a linefeed character for the RDN separator and a > spaced + for the AVA separator. It also indents the fields by four > characters. If no field separator is specified then sep_comma_plus_space > is used by default. > ============= > > Thank you! > -- > SY, Dmitry Belyavsky > From misaki.miyashita at oracle.com Thu Nov 8 13:25:03 2018 From: misaki.miyashita at oracle.com (Misaki Miyashita) Date: Thu, 8 Nov 2018 07:25:03 -0600 Subject: [openssl-users] OpenSSL 1.0.2: CVE-2018-5407 PortSmash In-Reply-To: References: <6ab943ac-be55-5f3d-bc80-e0e39672e3ee@oracle.com> Message-ID: Thanks for the info and the fix, BBB. Regards, -- misaki On 11/8/2018 6:26 AM, Billy Brumley wrote: > Howdy, > >> According to the following website: >> https://www.openwall.com/lists/oss-security/2018/11/01/4 >> >> OpenSSL <= 1.1.0h is affected. >> Does that mean the problem also exist in the OpenSSL 1.0.2 release? > Yes, it does. Pending review: > > https://github.com/openssl/openssl/pull/7593 > > BBB From beldmit at gmail.com Thu Nov 8 13:57:26 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 8 Nov 2018 16:57:26 +0300 Subject: [openssl-users] x509 manual In-Reply-To: <6f456c92-0aec-3483-f7f5-14d3e0665e72@openssl.org> References: <6f456c92-0aec-3483-f7f5-14d3e0665e72@openssl.org> Message-ID: On Thu, Nov 8, 2018 at 4:02 PM Matt Caswell wrote: > > > On 08/11/2018 12:44, Dmitry Belyavsky wrote: > > Hello, > > > > can anybody clarify what for the abbreviations AVA and RDN stand for? > > RDN == Relative Distinguised Name > AVA == Attribute Value Assertion > > An RDN consists of an unordered set of AVAs (but most frequently an RDN > is made up of exactly one AVA, e.g. CN = "John"). A Distinguished Name > (DN) is made up of a sequence of RDNs. > > That man page could probably do with some work to reduce the jargon. > I'll submit a pull request. Thank you! > > Matt > > > > > > ============ > > sep_comma_plus, sep_comma_plus_space, sep_semi_plus_space, sep_multiline > > These options determine the field separators. The first character is > > between RDNs and the second between multiple AVAs (multiple AVAs are > > very rare and their use is discouraged). The options ending in "space" > > additionally place a space after the separator to make it more readable. > > The sep_multiline uses a linefeed character for the RDN separator and a > > spaced + for the AVA separator. It also indents the fields by four > > characters. If no field separator is specified then sep_comma_plus_space > > is used by default. > > ============= > > > > Thank you! > > -- > > SY, Dmitry Belyavsky > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.davis at curatess.com Thu Nov 8 20:57:11 2018 From: paul.davis at curatess.com (Paul) Date: Thu, 8 Nov 2018 14:57:11 -0600 Subject: [openssl-users] updating openssl In-Reply-To: References: Message-ID: Thank you for the quick response On Tue, Nov 6, 2018 at 4:42 PM Wim Lewis wrote: > > On 6. n?v. 2018, at 2:02 e.h., Paul wrote: > > I configured Openvpn server on ubuntu 16.04 and ubuntu was using a old > version of openssl 1.0.2 and I was updating openssl to v1.1.1 > > Now I've installed the openssl but now unable to mv file installed to ln > -s /usr/local/ssl/bin/openssl /usr/bin/openssl > > failed to create symbolic link '/usr/bin/openssl': File exists > > > > but then when I use openssl version > > /usr/bin/openssl: No such file or directory > > > This is really a general unix question: I suspect you have a dangling > symbolic link in /usr/bin, pointing to a (now-deleted) old copy of openssl. > If so, you can just rm the dangling symbolic link. > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at cepl.eu Thu Nov 8 21:40:11 2018 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl) Date: Thu, 08 Nov 2018 22:40:11 +0100 Subject: [openssl-users] [ANN] M2Crypto 0.31.0 ... plenty of bugfixes (and support for OpenSSL 1.1.1) Message-ID: <1eeec268d3680328f682d13bf08ddb162d46e3b4.camel@cepl.eu> Hi, everybody, there is a new release of M2Crypto, most complete Python bindings for OpenSSL (from 1.0.1e to 1.1.1), supporting both Python 2 (2.6 and 2.7) and Python 3 (from 3.4 upwards). This is mostly bugfix release, including: - support for OpenSSL 1.1.1 - Fixes for Windows builds - Fixes of installs on AWS Lambda - Fixes of Mac OS X related failures - Fix Python 2.6 compatibility issues Support for OpenSSL 1.1.1 is just minimal, to make test suite pass. The biggest problem is that the latest OpenSSL doesn't raise exceptions in some situations where the earliest versions did so. Not sure, what is the proper reaction from M2Crypto size. Also, reminder, that we have special email list for development of M2Crypto. Its web page is http://redcrew.org/mailman/listinfo/ m2crypto and it is mailman with the posting address m2crypto at lists.redcrew.org so all email commands work. All complaints, support requests, and bug reports are welcome in the email list or on the issue tracker https://gitlab.com/m2crypto/m2crypto/issues Happy security hacking! Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 A man who won't die for something is not fit to live. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From aerowolf at gmail.com Thu Nov 8 23:23:12 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Thu, 8 Nov 2018 15:23:12 -0800 Subject: [openssl-users] updating openssl In-Reply-To: References: Message-ID: Generally, you don't want to replace any system-provided version of OpenSSL with a different version that has a different ABI. The way you've done so (without deleting the libraries from the older version) is safe, but don't remove the system package of openssl-1.0.2. Other packages may link to that version and stop working if you remove it. -Kyle H On Tue, Nov 6, 2018, 14:02 Paul I configured Openvpn server on ubuntu 16.04 and ubuntu was using a old > version of openssl 1.0.2 and I was updating openssl to v1.1.1 > Now I've installed the openssl but now unable to mv file installed to ln > -s /usr/local/ssl/bin/openssl /usr/bin/openssl > failed to create symbolic link '/usr/bin/openssl': File exists > > > > but then when I use openssl version > > /usr/bin/openssl: No such file or directory > > > how can I correct this? > > Paul > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited.-- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Nov 8 23:52:09 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 9 Nov 2018 00:52:09 +0100 Subject: [openssl-users] updating openssl In-Reply-To: References: Message-ID: On Debian systems, the standard procedure on Debian is to build your private/different versions of openssl (or anything else) in /usr/local, while leaving the Debain modified OpenSSL in /usr . This should keep your own code and Debian code out of each others way. Any programs you need to use with your own OpenSSL should be similarly rebuilt and put in /usr/local. I happen to do that quite a lot with OpenSSL. On 09/11/2018 00:23, Kyle Hamilton wrote: > Generally, you don't want to replace any system-provided version of > OpenSSL with a different version that has a different ABI. The way > you've done so (without deleting the libraries from the older version) > is safe, but don't remove the system package of openssl-1.0.2. Other > packages may link to that version and stop working if you remove it. > > -Kyle H > > On Tue, Nov 6, 2018, 14:02 Paul wrote: > > I configured Openvpn server on ubuntu 16.04 and ubuntu was using a > old version of openssl 1.0.2 and I was updating openssl to v1.1.1 > Now I've installed the openssl but now unable to mv file installed > to ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl > failed to create symbolic link '/usr/bin/openssl': File exists > > > > but then when I use openssl version > > /usr/bin/openssl: No such file or directory > > how can I correct this? > > Paul > > 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 From zhumzseu at 163.com Fri Nov 9 01:50:55 2018 From: zhumzseu at 163.com (=?GBK?B?1uzD99Xc?=) Date: Fri, 9 Nov 2018 09:50:55 +0800 (CST) Subject: [openssl-users] Is there any C code that implements SM2 algorithm separately? Message-ID: <7e2c90c7.6770.166f62a3d3c.Coremail.zhumzseu@163.com> Hi all, Is there any C code that implements SM2 algorithm separately, which means is there a version in C language that is implemented independently of the existing library of openssl? Thanks a lot. Best Wishes. -- ___________________________________ ??? ?????zhumzseu at 163.com ?????15651609020 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yang.yang at baishancloud.com Fri Nov 9 05:33:33 2018 From: yang.yang at baishancloud.com (Paul Yang) Date: Fri, 9 Nov 2018 13:33:33 +0800 Subject: [openssl-users] Is there any C code that implements SM2 algorithm separately? In-Reply-To: <7e2c90c7.6770.166f62a3d3c.Coremail.zhumzseu@163.com> References: <7e2c90c7.6770.166f62a3d3c.Coremail.zhumzseu@163.com> Message-ID: <234CE06F-5A7B-4694-8549-C1C83A9B8365@baishancloud.com> No, OpenSSL doesn't provide such stuff... > On Nov 9, 2018, at 09:50, ??? wrote: > > Hi all, > > Is there any C code that implements SM2 algorithm separately, which means is there a version in C language that is implemented independently of the existing library of openssl? > Thanks a lot. > > Best Wishes. > > > > > > > -- > ___________________________________ > ??? > ?????zhumzseu at 163.com > ?????15651609020 > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Nov 9 08:38:33 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 9 Nov 2018 03:38:33 -0500 Subject: [openssl-users] Server-side visibility of signature algorithm and key exchange properties? Message-ID: <20181109083832.GT4122@straasha.imrryr.org> On the client side of a TLS connection, I'm easily able to find all the primary parameters of interest: * The cipher used. * The server signature algorithm (digest, and public key) * The server key exchange algorithm (public key) enabling logging such as: TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) signature ECDSA(P-256) digest SHA256 key-exchange X25519 I am having a bit of trouble finding the equivalent information for the 3rd line on the server side. Anyone know how, in TLS 1.3 where these are not implied by the ciphersuite, to determine the signature algorithm (and curve for ECDSA), the hash algorithm and key exchange public key (with bit count for DH or curve name for ECDSA)? Are these available for inspection by the server application? If not, that may be an omission we need to address. -- Viktor. From blaufish.public.email at gmail.com Fri Nov 9 09:39:20 2018 From: blaufish.public.email at gmail.com (Peter Magnusson) Date: Fri, 9 Nov 2018 10:39:20 +0100 Subject: [openssl-users] Is there any C code that implements SM2 algorithm separately? In-Reply-To: <7e2c90c7.6770.166f62a3d3c.Coremail.zhumzseu@163.com> References: <7e2c90c7.6770.166f62a3d3c.Coremail.zhumzseu@163.com> Message-ID: You can find a number of SM2 implementations on github, etc. https://github.com/openssl/openssl/blob/9453b196343db579c590130adc63d35d2ff87188/crypto/sm2/sm2_crypt.c https://github.com/ARMmbed/mbedtls/blob/3ea8c4cb2a03724ba15c915e02d83255e1884859/library/ecdsa.c https://github.com/developerworks/sm2/blob/master/miracl/sm2.c Asymmetric ciphers are typically not "library free", because you need the big number operations. The big number operations should preferably secure versions that don't reveal private key through side-channels (timing etc), so these operations are usually are provided by a cryptographic library. On Fri, Nov 9, 2018 at 3:06 AM ??? wrote: > > Hi all, > > Is there any C code that implements SM2 algorithm separately, which means is there a version in C language that is implemented independently of the existing library of openssl? > Thanks a lot. > > Best Wishes. > > > > > > > -- > ___________________________________ > ??? > ?????zhumzseu at 163.com > ?????15651609020 > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From levitte at openssl.org Fri Nov 9 11:21:04 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 09 Nov 2018 12:21:04 +0100 (CET) Subject: [openssl-users] Is there any C code that implements SM2 algorithm separately? In-Reply-To: <7e2c90c7.6770.166f62a3d3c.Coremail.zhumzseu@163.com> References: <7e2c90c7.6770.166f62a3d3c.Coremail.zhumzseu@163.com> Message-ID: <20181109.122104.521999085012050045.levitte@openssl.org> In message <7e2c90c7.6770.166f62a3d3c.Coremail.zhumzseu at 163.com> on Fri, 9 Nov 2018 09:50:55 +0800 (CST), ??? said: > Hi all, > > Is there any C code that implements SM2 algorithm separately, which means is there a version in C > language that is implemented independently of the existing library of openssl? > Thanks a lot. Nope. We're pushing hard for people to use the EVP API, and newer algorithms are therefore only implemented as EVP backends. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Fri Nov 9 18:42:28 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 9 Nov 2018 18:42:28 +0000 Subject: [openssl-users] Server-side visibility of signature algorithm and key exchange properties? In-Reply-To: <20181109083832.GT4122@straasha.imrryr.org> References: <20181109083832.GT4122@straasha.imrryr.org> Message-ID: <74450cbf-9c6a-38a8-8f3b-7fd21a3b94a5@openssl.org> On 09/11/2018 08:38, Viktor Dukhovni wrote: > On the client side of a TLS connection, I'm easily able to find all > the primary parameters of interest: > > * The cipher used. > * The server signature algorithm (digest, and public key) > * The server key exchange algorithm (public key) > > enabling logging such as: > > TLS connection established to 127.0.0.1[127.0.0.1]:25: > TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) > signature ECDSA(P-256) digest SHA256 key-exchange X25519 > > I am having a bit of trouble finding the equivalent information for > the 3rd line on the server side. Anyone know how, in TLS 1.3 where > these are not implied by the ciphersuite, to determine the signature > algorithm (and curve for ECDSA), the hash algorithm and key exchange > public key (with bit count for DH or curve name for ECDSA)? I don't believe we currently expose the signature algorithm selected on the server side. It's held in s->s3->tmp.sigalg, but AFAICT that is only ever used internally. Similarly the key exchange public key is held in s->s3->peer_tmp. We do expose that via SSL_get_server_tmp_key(), but its a client side only function. We explicitly check that and return 0 if called on the server side. Matt > > Are these available for inspection by the server application? If > not, that may be an omission we need to address. > From openssl-users at dukhovni.org Fri Nov 9 19:42:13 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 9 Nov 2018 14:42:13 -0500 Subject: [openssl-users] Server-side visibility of signature algorithm and key exchange properties? In-Reply-To: <74450cbf-9c6a-38a8-8f3b-7fd21a3b94a5@openssl.org> References: <20181109083832.GT4122@straasha.imrryr.org> <74450cbf-9c6a-38a8-8f3b-7fd21a3b94a5@openssl.org> Message-ID: <20181109194213.GW4122@straasha.imrryr.org> On Fri, Nov 09, 2018 at 06:42:28PM +0000, Matt Caswell wrote: > > I am having a bit of trouble finding the equivalent information for > > the 3rd line on the server side. Anyone know how, in TLS 1.3 where > > these are not implied by the ciphersuite, to determine the signature > > algorithm (and curve for ECDSA), the hash algorithm and key exchange > > public key (with bit count for DH or curve name for ECDSA)? > > I don't believe we currently expose the signature algorithm selected on > the server side. It's held in s->s3->tmp.sigalg, but AFAICT that is only > ever used internally. Thanks for confirming, it is then not surprising I failed to find the relevant interfaces. :-) > Similarly the key exchange public key is held in s->s3->peer_tmp. We do > expose that via SSL_get_server_tmp_key(), but its a client side only > function. We explicitly check that and return 0 if called on the server > side. Quick question about that, since the client may also sign the key exchange when a client certificate is requested and returned, what is held on the server in s->s3->tmp.sigalg? [ I expect still the signature the server used in its CertificateVerify. And on the client side, I would expect this to hold the algorithm used by the client to sign its ClientVerify if a client cert was used. ] And it seems that on the server side s->s3->peer_tmp does actually hold the client's key exchange public key, which is necessarily for the same group as the server, so all we'd need to do is remove that 'explicit check' and that key be visible on the server side, right? -- Viktor. From Ikwyl6 at protonmail.com Fri Nov 9 20:44:57 2018 From: Ikwyl6 at protonmail.com (Ikwyl6) Date: Fri, 09 Nov 2018 20:44:57 +0000 Subject: [openssl-users] File permissions on keys, csr, and certificates Message-ID: <0nKgxPoHejkFy1cmyj0bMTDtNLSR4LtDFlukWO4ovps3KHVypSf0aiyhCb-wv8-pA3nsMi0Dxx0hzDgowcp7M0uhCZ3imPbzSI_HMCQ9lnI=@protonmail.com> Hi - I created a question on Super User about questions on file permissions and what the file permissions should be on created files. See link here: https://superuser.com/questions/1368747/file-permissions-for-openssl-created-files-for-https-web-server-lighttpd Could someone comment on what file permissions should be on each file and who should own them. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Sun Nov 11 11:33:51 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sun, 11 Nov 2018 14:33:51 +0300 Subject: [openssl-users] x509 manual In-Reply-To: References: <6f456c92-0aec-3483-f7f5-14d3e0665e72@openssl.org> Message-ID: Hello, https://github.com/openssl/openssl/pull/7614 On Thu, Nov 8, 2018 at 4:57 PM Dmitry Belyavsky wrote: > > > On Thu, Nov 8, 2018 at 4:02 PM Matt Caswell wrote: > >> >> >> On 08/11/2018 12:44, Dmitry Belyavsky wrote: >> > Hello, >> > >> > can anybody clarify what for the abbreviations AVA and RDN stand for? >> >> RDN == Relative Distinguised Name >> AVA == Attribute Value Assertion >> >> An RDN consists of an unordered set of AVAs (but most frequently an RDN >> is made up of exactly one AVA, e.g. CN = "John"). A Distinguished Name >> (DN) is made up of a sequence of RDNs. >> >> That man page could probably do with some work to reduce the jargon. >> > > I'll submit a pull request. > > Thank you! > > >> >> Matt >> >> >> > >> > ============ >> > sep_comma_plus, sep_comma_plus_space, sep_semi_plus_space, sep_multiline >> > These options determine the field separators. The first character is >> > between RDNs and the second between multiple AVAs (multiple AVAs are >> > very rare and their use is discouraged). The options ending in "space" >> > additionally place a space after the separator to make it more readable. >> > The sep_multiline uses a linefeed character for the RDN separator and a >> > spaced + for the AVA separator. It also indents the fields by four >> > characters. If no field separator is specified then sep_comma_plus_space >> > is used by default. >> > ============= >> > >> > Thank you! >> > -- >> > SY, Dmitry Belyavsky >> > >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Sun Nov 11 12:38:27 2018 From: openssl at foocrypt.net (openssl at foocrypt.net) Date: Sun, 11 Nov 2018 23:38:27 +1100 Subject: [openssl-users] AssAccess : Telecommunication and Other Legislation Amendment (Assistance and Access) Bill 2018 Message-ID: <81D70BA6-D8E3-4414-840D-CDC57215A57B@foocrypt.net> Greetings Currently down here in the land down under, the Telecommunication and Other Legislation Amendment (Assistance and Access) Bill 2018, is currently under going scrutiny via the Parliamentary Joint Committee on Intelligence and Security. Published submissions are available via : [ https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Intelligence_and_Security/TelcoAmendmentBill2018/Submissions ] along with links to the proposed leglistive changes. An accurate assessment of the bill is available via : [ https://youtu.be/eW-OMR-iWOE ] FooCrypt put forward a brief submission to the P.J.C.I.S. on the 17th of October, 2018 and is now working on an addendum that will be submitted to the P.J.C.I.S. on the 26th of Novenmeber, 2018. [ https://youtu.be/eW-OMR-iWOE ] If any members of this community wish to also provide information for a inclusion in the FooCrypt addendum via an attachment or a case study, please do so by close of business, 23rd of November, 2018 AEST, so that a summarized overview of the attachments / case studies can be performed prior to submission. Please note that it is the intent to provide the information in an ?as is? state from what we receive via email. Please provide a pdf document containing the information you wish to pass onto the P.J.C.I.S. Each pdf document will be summarized as a simple table of index. Author : Date : Location : Document Number : MD5 Checksum Obfuscation of any identifiable details is acceptable in your submission. Response can be submitted to [ assaccess at pjcis.foocrypt.net ] ? Regards, Mark A. Lane assaccess at pjcis.foocrypt.net https://pjcis.foocrypt.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Sun Nov 11 12:50:56 2018 From: openssl at foocrypt.net (openssl at foocrypt.net) Date: Sun, 11 Nov 2018 23:50:56 +1100 Subject: [openssl-users] AssAccess : Telecommunication and Other Legislation Amendment (Assistance and Access) Bill 2018 Message-ID: Greetings Currently down here in the land down under, the Telecommunication and Other Legislation Amendment (Assistance and Access) Bill 2018, is currently under going scrutiny via the Parliamentary Joint Committee on Intelligence and Security. Published submissions are available via : [ https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Intelligence_and_Security/TelcoAmendmentBill2018/Submissions ] along with links to the proposed leglistive changes. An accurate assessment of the bill is available via : [ https://youtu.be/eW-OMR-iWOE ] FooCrypt put forward a brief submission to the P.J.C.I.S. on the 17th of October, 2018 and is now working on an addendum that will be submitted to the P.J.C.I.S. on the 26th of Novenmeber, 2018. [ https://pjcis.foocrypt.net ] If any members of this community wish to also provide information for a inclusion in the FooCrypt addendum via an attachment or a case study, please do so by close of business, 23rd of November, 2018 AEST, so that a summarized overview of the attachments / case studies can be performed prior to submission. Please note that it is the intent to provide the information in an ?as is? state from what we receive via email. Please provide a pdf document containing the information you wish to pass onto the P.J.C.I.S. Each pdf document will be summarized as a simple table of index. Author : Date : Location : Document Number : MD5 Checksum Obfuscation of any identifiable details is acceptable in your submission. Response can be submitted to [ assaccess at pjcis.foocrypt.net ] ? Regards, Mark A. Lane assaccess at pjcis.foocrypt.net https://pjcis.foocrypt.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun Nov 11 16:53:55 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 11 Nov 2018 16:53:55 +0000 Subject: [openssl-users] x509 manual In-Reply-To: References: <6f456c92-0aec-3483-f7f5-14d3e0665e72@openssl.org> Message-ID: It was great to see you last week. You and the entire ?Russian crypto cohort? :) From: Dmitry Belyavsky Reply-To: openssl-users Date: Sunday, November 11, 2018 at 6:34 AM To: openssl-users Subject: Re: [openssl-users] x509 manual Hello, https://github.com/openssl/openssl/pull/7614 On Thu, Nov 8, 2018 at 4:57 PM Dmitry Belyavsky > wrote: On Thu, Nov 8, 2018 at 4:02 PM Matt Caswell > wrote: On 08/11/2018 12:44, Dmitry Belyavsky wrote: > Hello, > > can anybody clarify what for the abbreviations AVA and RDN stand for? RDN == Relative Distinguised Name AVA == Attribute Value Assertion An RDN consists of an unordered set of AVAs (but most frequently an RDN is made up of exactly one AVA, e.g. CN = "John"). A Distinguished Name (DN) is made up of a sequence of RDNs. That man page could probably do with some work to reduce the jargon. I'll submit a pull request. Thank you! Matt > > ============ > sep_comma_plus, sep_comma_plus_space, sep_semi_plus_space, sep_multiline > These options determine the field separators. The first character is > between RDNs and the second between multiple AVAs (multiple AVAs are > very rare and their use is discouraged). The options ending in "space" > additionally place a space after the separator to make it more readable. > The sep_multiline uses a linefeed character for the RDN separator and a > spaced + for the AVA separator. It also indents the fields by four > characters. If no field separator is specified then sep_comma_plus_space > is used by default. > ============= > > Thank you! > -- > SY, Dmitry Belyavsky > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- SY, Dmitry Belyavsky -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Nov 12 09:27:15 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Nov 2018 09:27:15 +0000 Subject: [openssl-users] Server-side visibility of signature algorithm and key exchange properties? In-Reply-To: <20181109194213.GW4122@straasha.imrryr.org> References: <20181109083832.GT4122@straasha.imrryr.org> <74450cbf-9c6a-38a8-8f3b-7fd21a3b94a5@openssl.org> <20181109194213.GW4122@straasha.imrryr.org> Message-ID: <429834bb-9c7b-5c8b-e3a5-8c6d60e0e1f4@openssl.org> On 09/11/2018 19:42, Viktor Dukhovni wrote: > On Fri, Nov 09, 2018 at 06:42:28PM +0000, Matt Caswell wrote: > >>> I am having a bit of trouble finding the equivalent information for >>> the 3rd line on the server side. Anyone know how, in TLS 1.3 where >>> these are not implied by the ciphersuite, to determine the signature >>> algorithm (and curve for ECDSA), the hash algorithm and key exchange >>> public key (with bit count for DH or curve name for ECDSA)? >> >> I don't believe we currently expose the signature algorithm selected on >> the server side. It's held in s->s3->tmp.sigalg, but AFAICT that is only >> ever used internally. > > Thanks for confirming, it is then not surprising I failed to find > the relevant interfaces. :-) > >> Similarly the key exchange public key is held in s->s3->peer_tmp. We do >> expose that via SSL_get_server_tmp_key(), but its a client side only >> function. We explicitly check that and return 0 if called on the server >> side. > > Quick question about that, since the client may also sign the key > exchange when a client certificate is requested and returned, what > is held on the server in s->s3->tmp.sigalg? [ I expect still the > signature the server used in its CertificateVerify. And on the > client side, I would expect this to hold the algorithm used by the > client to sign its ClientVerify if a client cert was used. ] Right - exactly that. s->s3->tmp.sigalg always holds the sigalg the endpoint selected to sign its own CertificateVerify (whether that be client or server). > > And it seems that on the server side s->s3->peer_tmp does actually > hold the client's key exchange public key, which is necessarily for > the same group as the server, so all we'd need to do is remove that > 'explicit check' and that key be visible on the server side, right? > Right - although we might want to think about the name of the function. Matt From mcr at sandelman.ca Mon Nov 12 16:20:43 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 12 Nov 2018 11:20:43 -0500 Subject: [openssl-users] understanding ASN1_item_verify() Message-ID: <26902.1542039643@localhost> Zero, my goal is to validate Certificate Signing Requests in ruby. First, https://www.openssl.org/docs/man1.1.1/man3/ASN1_item_verify.html and https://www.openssl.org/docs/man1.1.0/man3/ASN1_item_verify.html .. do not seem to exist, but at least https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_asn1_set_ctrl.html points to such a page. I'm not sure what this means for this function. It also does not show up in doc/*, but it is exported in crypto.num. Maybe it should not be used by new code? Second, I was looking at: int X509_REQ_verify(X509_REQ *a, EVP_PKEY *r) { return (ASN1_item_verify(ASN1_ITEM_rptr(X509_REQ_INFO), &a->sig_alg, a->signature, &a->req_info, r)); } as I'm not sure that I want to build a ruby wrapper for X509_REQ. I just don't understand ASN1_ITEM_rptr. My understanding is that it returns a function (or global) that would be named X509_REQ_INFO_it(). But, how does the "a" argument get connected with this? I'm thinking that there is some global "current ASN1 thing" that is involved, but surely that can't be... If there is any non-generic documentation on X509_REQ_*(), I haven't found it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matt at openssl.org Mon Nov 12 17:05:31 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Nov 2018 17:05:31 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <86b66671-8508-d720-416a-b4efd58c34bd@openssl.org> OpenSSL Security Advisory [12 November 2018] ============================================ Microarchitecture timing vulnerability in ECC scalar multiplication (CVE-2018-5407) =================================================================================== Severity: Low OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been shown to be vulnerable to a microarchitecture timing side channel attack. An attacker with sufficient access to mount local timing attacks during ECDSA signature generation could recover the private key. This issue does not impact OpenSSL 1.1.1 and is already fixed in the latest version of OpenSSL 1.1.0 (1.1.0i). OpenSSL 1.0.2 is affected but due to the low severity of this issue we are not creating a new release at this time. The 1.0.2 mitigation for this issue can be found in commit b18162a7c. OpenSSL 1.1.0 users should upgrade to 1.1.0i. This issue was reported to OpenSSL on 26th October 2018 by Alejandro Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and Nicola Tuveri. Note ==== OpenSSL 1.1.0 is currently only receiving security updates. Support for this version will end on 11th September 2019. Users of this version should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20181112.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From karsten.gorkow at insite-gmbh.de Mon Nov 12 17:25:53 2018 From: karsten.gorkow at insite-gmbh.de (Karsten Gorkow) Date: Mon, 12 Nov 2018 18:25:53 +0100 Subject: [openssl-users] Win32 BIO server, no accept Message-ID: <012001d47aac$c549f8f0$4fddead0$@insite-gmbh.de> Hello, I'm pretty new to OpenSSL and need to implement a secure connection. It's a Win32 application that uses a standard socket implementation up to now and runs for some years already. To implement SSL/TLS I downloaded 1.1 and compiled the DLLs for VS2015. The tests are all "green". Now I started to integrate OpenSSL into the application. First step for me is to replace the socket implementation with BIO, no security stuff is involved yet. The app can be configured to act as a TCP server or a client. I was able to get it to work via BIO as a client, but the problem is the server role. I don't get a valid (second) accept call, no client is able to connect. Inside the app this is done via a non-blocking listening socket (return value is always -1 with "WOULDBLOCK" set), but I even copied the sample code from the blog (blocking mode) into the app's initialization code and the second call to BIO_do_accept never returns: SSL_load_error_strings(); ERR_load_BIO_strings(); OpenSSL_add_all_algorithms(); BIO *abio, *cbio, *cbio2; /* First call to BIO_accept() sets up accept BIO */ abio = BIO_new_accept("4444"); if (BIO_do_accept(abio) <= 0) { fprintf(stderr, "Error setting up accept\n"); ERR_print_errors_fp(stderr); exit(1); } /* Wait for incoming connection */ if (BIO_do_accept(abio) <= 0) { fprintf(stderr, "Error accepting connection\n"); ERR_print_errors_fp(stderr); exit(1); } fprintf(stderr, "Connection 1 established\n"); /* Retrieve BIO for connection */ cbio = BIO_pop(abio); ... What's the problem here? I'm currently running under Win 8.1. Best regards, Karsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip at taygeta.com Tue Nov 13 02:03:00 2018 From: skip at taygeta.com (Skip Carter) Date: Mon, 12 Nov 2018 18:03:00 -0800 Subject: [openssl-users] generating shared key Message-ID: <1542074580.4604.9.camel@taygeta.com> I know this is simple but I can't seem to find find this little detail: I have Alice's public ECDH key in memory. And Bob's private ECDH key in memory. How do I combine them to get the shared key? Is this step literally the same as conventional DH ? -- Skip Carter Taygeta Scientific Inc. From openssl-users at dukhovni.org Tue Nov 13 03:49:35 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 12 Nov 2018 22:49:35 -0500 Subject: [openssl-users] generating shared key In-Reply-To: <1542074580.4604.9.camel@taygeta.com> References: <1542074580.4604.9.camel@taygeta.com> Message-ID: > On Nov 12, 2018, at 9:03 PM, Skip Carter wrote: > > I know this is simple but I can't seem to find find this little detail: > > I have Alice's public ECDH key in memory. And Bob's private ECDH key > in memory. How do I combine them to get the shared key? > > Is this step literally the same as conventional DH ? https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_derive.html -- Viktor. From karsten.gorkow at insite-gmbh.de Tue Nov 13 10:42:39 2018 From: karsten.gorkow at insite-gmbh.de (Karsten Gorkow) Date: Tue, 13 Nov 2018 11:42:39 +0100 Subject: [openssl-users] Win32 BIO server, no accept In-Reply-To: <012001d47aac$c549f8f0$4fddead0$@insite-gmbh.de> References: <012001d47aac$c549f8f0$4fddead0$@insite-gmbh.de> Message-ID: <018a01d47b3d$9b2ebce0$d18c36a0$@insite-gmbh.de> Riddle solved: Must call BIO_new_accept("0.0.0.0:4444") and it works. Von: openssl-users Im Auftrag von Karsten Gorkow Gesendet: Montag, 12. November 2018 18:26 An: openssl-users at openssl.org Betreff: [openssl-users] Win32 BIO server, no accept Hello, I'm pretty new to OpenSSL and need to implement a secure connection. It's a Win32 application that uses a standard socket implementation up to now and runs for some years already. To implement SSL/TLS I downloaded 1.1 and compiled the DLLs for VS2015. The tests are all "green". Now I started to integrate OpenSSL into the application. First step for me is to replace the socket implementation with BIO, no security stuff is involved yet. The app can be configured to act as a TCP server or a client. I was able to get it to work via BIO as a client, but the problem is the server role. I don't get a valid (second) accept call, no client is able to connect. Inside the app this is done via a non-blocking listening socket (return value is always -1 with "WOULDBLOCK" set), but I even copied the sample code from the blog (blocking mode) into the app's initialization code and the second call to BIO_do_accept never returns: SSL_load_error_strings(); ERR_load_BIO_strings(); OpenSSL_add_all_algorithms(); BIO *abio, *cbio, *cbio2; /* First call to BIO_accept() sets up accept BIO */ abio = BIO_new_accept("4444"); if (BIO_do_accept(abio) <= 0) { fprintf(stderr, "Error setting up accept\n"); ERR_print_errors_fp(stderr); exit(1); } /* Wait for incoming connection */ if (BIO_do_accept(abio) <= 0) { fprintf(stderr, "Error accepting connection\n"); ERR_print_errors_fp(stderr); exit(1); } fprintf(stderr, "Connection 1 established\n"); /* Retrieve BIO for connection */ cbio = BIO_pop(abio); ... What's the problem here? I'm currently running under Win 8.1. Best regards, Karsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip at taygeta.com Tue Nov 13 16:32:51 2018 From: skip at taygeta.com (Skip Carter) Date: Tue, 13 Nov 2018 08:32:51 -0800 Subject: [openssl-users] generating shared key In-Reply-To: References: <1542074580.4604.9.camel@taygeta.com> Message-ID: <1542126771.4604.11.camel@taygeta.com> Thanks Viktor, thats exactly what I needed On Mon, 2018-11-12 at 22:49 -0500, Viktor Dukhovni wrote: > > On Nov 12, 2018, at 9:03 PM, Skip Carter wrote: > > > > I know this is simple but I can't seem to find find this little > > detail: > > > > I have Alice's public ECDH key in memory.??And Bob's private ECDH > > key > > in memory.??How do I combine them to get the shared key? > > > > Is this step literally the same as conventional DH ? > > https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_derive.html > > --? > Viktor. > -- Skip Carter Taygeta Scientific Inc. From ca+ssl-users at esmtp.org Wed Nov 14 02:45:42 2018 From: ca+ssl-users at esmtp.org (Claus Assmann) Date: Tue, 13 Nov 2018 18:45:42 -0800 Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3 In-Reply-To: <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org> References: <1539625346.18482.5.camel@ns.five-ten-sg.com> <20181015193256.GC983@straasha.imrryr.org> <1539647379.18482.38.camel@ns.five-ten-sg.com> <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org> Message-ID: <20181114024542.GA29210@x2.esmtp.org> On Mon, Oct 15, 2018, Viktor Dukhovni wrote: > With TLS 1.3, you suddenly have clients optionally soliciting certificates > by specific CA from servers [[...]] > With 149 certs, and typical CA names O(80) bytes, we're looking at > ~12KB of cert names, which should fit into an extension that can be > up to 64KB in size. So overflowing the extension size limit would I'm a bit confused why this happens -- the OpenSSL documentation states: ------------------------------------------------------------ SSL_CTX_set_client_CA_list() sets the list of CAs sent to the client when requesting a client certificate for ctx. Ownership of list is ... ------------------------------------------------------------ Does SSL_CTX_set_client_CA_list() also set the list of CAs sent by the client (a brief look at the source code seems to confirm that, but I don't understand the code well enough)? Or what other function sets that list? sendmail does not use SSL_CTX_set0_CA_list(). From openssl-users at dukhovni.org Wed Nov 14 02:55:48 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 13 Nov 2018 21:55:48 -0500 Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3 In-Reply-To: <20181114024542.GA29210@x2.esmtp.org> References: <1539625346.18482.5.camel@ns.five-ten-sg.com> <20181015193256.GC983@straasha.imrryr.org> <1539647379.18482.38.camel@ns.five-ten-sg.com> <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org> <20181114024542.GA29210@x2.esmtp.org> Message-ID: <4FED5256-C485-48DF-B8E6-22ADEDFB2ECD@dukhovni.org> > On Nov 13, 2018, at 9:45 PM, Claus Assmann wrote: > > I'm a bit confused why this happens -- the OpenSSL documentation > states: > ------------------------------------------------------------ > SSL_CTX_set_client_CA_list() sets the list of CAs sent to the client > when requesting a client certificate for ctx. Ownership of list is > ... > ------------------------------------------------------------ In 1.1.1 (rather than the upcoming 1.1.1a) that was just one of the things it did. > Does SSL_CTX_set_client_CA_list() also set the list of CAs sent by > the client (a brief look at the source code seems to confirm that, > but I don't understand the code well enough)? Yes, that's that the case in 1.1.1 (but not the upcoming 1.1.1a) > Or what other function > sets that list? sendmail does not use SSL_CTX_set0_CA_list(). https://github.com/openssl/openssl/pull/7503 -- Viktor. From hemantranvir at gmail.com Wed Nov 14 11:54:55 2018 From: hemantranvir at gmail.com (Hemant Ranvir) Date: Wed, 14 Nov 2018 20:54:55 +0900 Subject: [openssl-users] Extracting decrypt key for AES from openssl on client side Message-ID: I have implemented AES 128 encrypt and decrypt functions and tested it with sample data and it checks out perfectly. I used the following reference: https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf Next I implemented a dummy SSL client and SSL server which uses openssl to send and receive data. It is working without any error and the messages are exchanged seamlessly. My main goal here is to use openssl for initial handshake sequence. Once the connection is established between server and client, decrypt the incoming message (this time not using the openssl api but rather by using the decrypt AES function implemented earlier) and print and similarly for outgoing message. We will focus on incoming messages. For this of course I will need the decrypt key and IV. I got the decrypt key(read key) on client side like following: (ssl is the SSL* structure of openssl for the established connection, I am accessing the source code structures of openssl directly) //following struct copied from crypto/evp/e_aes.c typedef struct { union { double align; AES_KEY ks; } ks; block128_f block; union { cbc128_f cbc; ctr128_f ctr; } stream; } EVP_AES_KEY; [Client Side] EVP_AES_KEY *cipher_data; cipher_data = EVP_CIPHER_CTX_get_cipher_data(ssl->enc_read_ctx); cipher_data->ks.ks.rd_key --> this is the decrypt key I used this key to decrypt the incoming message with the AES decrypt function but in vain. Now AES is symmetric encryption so I thought let me check the encrypt(write) key on the server side. The encrypt key on server should be equal to decrypt key on client side. I got the encrypt key on server like following: [Server Side] EVP_AES_KEY *cipher_data; cipher_data = EVP_CIPHER_CTX_get_cipher_data(ssl->enc_write_ctx); cipher_data->ks.ks.rd_key --> this is the encrypt key To my surprise they are different. Now if I use the above encrypt key of server to decrypt the message on the client side. The message is decrypted successfully.(as expected, the key used for encrypting the message is used to decrypt the message in AES standard). So I reach the following inferences: 1. The decrypt key which is acquired on the client side is encrypted in some way in openssl? 2. My method for getting the decrypt key on client side is wrong. How can I get the decrypt key on the client side which I can use in the AES decryption routine? -- Best Regards, Hemant Ranvir *"To live a creative life, we must lose our fear of being wrong.**" - J.C.Pearce* -------------- next part -------------- An HTML attachment was scrubbed... URL: From blaufish.public.email at gmail.com Wed Nov 14 14:40:19 2018 From: blaufish.public.email at gmail.com (Peter Magnusson) Date: Wed, 14 Nov 2018 15:40:19 +0100 Subject: [openssl-users] File permissions on keys, csr, and certificates In-Reply-To: <0nKgxPoHejkFy1cmyj0bMTDtNLSR4LtDFlukWO4ovps3KHVypSf0aiyhCb-wv8-pA3nsMi0Dxx0hzDgowcp7M0uhCZ3imPbzSI_HMCQ9lnI=@protonmail.com> References: <0nKgxPoHejkFy1cmyj0bMTDtNLSR4LtDFlukWO4ovps3KHVypSf0aiyhCb-wv8-pA3nsMi0Dxx0hzDgowcp7M0uhCZ3imPbzSI_HMCQ9lnI=@protonmail.com> Message-ID: root:root, chmod 400. And ideally your Root CA files should not be hosted on your web server, otherwise a server compromise also compromises your root authority. https://redmine.lighttpd.net/projects/1/wiki/docs_ssl Permissions Be careful to keep your .pem file private! Lighttpd reads all pemfiles at startup, before dropping privileges. It is therefore best to make the pem file owned by root and readable by root only: $ chown root:root /etc/lighttpd/ssl/example.org.pem $ chmod 400 /etc/lighttpd/ssl/example.org.pem On Fri, Nov 9, 2018 at 10:04 PM Ikwyl6 via openssl-users wrote: > > Hi - I created a question on Super User about questions on file permissions and what the file permissions should be on created files. See link here: > > https://superuser.com/questions/1368747/file-permissions-for-openssl-created-files-for-https-web-server-lighttpd > > Could someone comment on what file permissions should be on each file and who should own them. > > Thank you. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Wed Nov 14 16:28:04 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 14 Nov 2018 11:28:04 -0500 Subject: [openssl-users] Extracting decrypt key for AES from openssl on client side In-Reply-To: References: Message-ID: <8B9324BA-ABB9-4901-A6FA-C73E9F6F106E@dukhovni.org> > On Nov 14, 2018, at 6:54 AM, Hemant Ranvir wrote: > > My main goal here is to use openssl for initial handshake sequence. Once the connection is established between server and client, decrypt the incoming message (this time not using the openssl api but rather by using the decrypt AES function implemented earlier) This makes no sense, because TLS does not just emit a simple CBC encrypted stream after performing the handshake. So you can't do that. Use SSL_read()/SSL_write, and let the library do the message decryption/encryption for you. When done use SSL_shutdown() to cleanly terminate the stream, and depending on the application protocol, make wait for the peer's SSL_shutdown() in turn to avoid truncation attacks where completion of the stream is not implied by the higher level protocol. -- Viktor. From matt at openssl.org Wed Nov 14 18:00:02 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Nov 2018 18:00:02 +0000 Subject: [openssl-users] Forthcoming OpenSSL Releases Message-ID: <1e00c274-19f7-c862-32fa-2cc53e6b365d@openssl.org> The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1a, 1.1.0j and 1.0.2q. These releases will be made available on 20th November 2018 between approximately 1300-1700 UTC. These are bug-fix releases. They also contain the fixes for three LOW severity security issues CVE-2018-0735, CVE-2018-0734 and CVE-2018-5407 which were previously announced here: https://www.openssl.org/news/secadv/20181029.txt https://www.openssl.org/news/secadv/20181030.txt https://www.openssl.org/news/secadv/20181112.txt CVE-2018-0735 only affects the 1.1.0 branch. CVE-2018-0734 affects the 1.1.1, 1.1.0 and 1.0.2 branches. CVE-2018-5407 affects the 1.0.2 branch. It also affects older 1.1.0 releases before 1.1.0i. Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From eugene.adell at gmail.com Thu Nov 15 10:53:35 2018 From: eugene.adell at gmail.com (=?UTF-8?Q?Eug=C3=A8ne_Adell?=) Date: Thu, 15 Nov 2018 11:53:35 +0100 Subject: [openssl-users] configuring OpenSSL to split handshake messages Message-ID: Hello, I am looking for a way to configure OpenSSL then it will send handshake records one by one in their respective TCP packet, instead of sending one big message containing several records. Typically, in my network captures I see the server sending one message containing Server Hello + Certificate + Server Hello Done records, and I would like to know how to send 3 messages, each one containing only one record. I checked OpenSSL options and the user mailing-list archives without finding the answer, and I am not sure this is even possible (by configuration only). thanks in advance E.A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Nov 15 11:12:15 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Nov 2018 11:12:15 +0000 Subject: [openssl-users] configuring OpenSSL to split handshake messages In-Reply-To: References: Message-ID: <2a51a660-d3bf-2e47-5827-0a48a734f56a@openssl.org> On 15/11/2018 10:53, Eug?ne Adell wrote: > Hello, > > I am looking for a way to configure OpenSSL then it will send handshake records > one by one in their respective TCP packet, instead of sending one big message > containing several records. Typically, in my network captures I see the server > sending one message containing Server Hello + Certificate + Server Hello Done > records, and I would like to know how to send 3 messages, each one containing > only one record. I checked OpenSSL options and the user mailing-list archives > without finding the answer, and I am not sure this is even possible (by > configuration only). I'm intrigued to know why you would want to do that. Anyway, I don't believe this is currently possible without modifying the OpenSSL source code. Matt From eugene.adell at gmail.com Thu Nov 15 11:17:41 2018 From: eugene.adell at gmail.com (=?UTF-8?Q?Eug=C3=A8ne_Adell?=) Date: Thu, 15 Nov 2018 12:17:41 +0100 Subject: [openssl-users] configuring OpenSSL to split handshake messages In-Reply-To: <2a51a660-d3bf-2e47-5827-0a48a734f56a@openssl.org> References: <2a51a660-d3bf-2e47-5827-0a48a734f56a@openssl.org> Message-ID: This is mainly for experimental reason (client compliance checking, performance measurement). As the SSL/TLS protocol allows it, why not to test ? If no other solution than modifying the source code, where should I look ? Le jeu. 15 nov. 2018 ? 12:12, Matt Caswell a ?crit : > > > On 15/11/2018 10:53, Eug?ne Adell wrote: > > Hello, > > > > I am looking for a way to configure OpenSSL then it will send handshake > records > > one by one in their respective TCP packet, instead of sending one big > message > > containing several records. Typically, in my network captures I see the > server > > sending one message containing Server Hello + Certificate + Server Hello > Done > > records, and I would like to know how to send 3 messages, each one > containing > > only one record. I checked OpenSSL options and the user mailing-list > archives > > without finding the answer, and I am not sure this is even possible (by > > configuration only). > > I'm intrigued to know why you would want to do that. Anyway, I don't > believe > this is currently possible without modifying the OpenSSL source code. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Nov 15 11:33:20 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Nov 2018 11:33:20 +0000 Subject: [openssl-users] configuring OpenSSL to split handshake messages In-Reply-To: References: <2a51a660-d3bf-2e47-5827-0a48a734f56a@openssl.org> Message-ID: <5e8c8e6c-3995-5f81-b7a3-a817c9931936@openssl.org> On 15/11/2018 11:17, Eug?ne Adell wrote: > This is mainly for experimental reason (client compliance checking, performance > measurement). As the SSL/TLS protocol allows it, why not to test ? > If no other solution than modifying the source code, where should I look ? That involves messing with the TLS state machine. Not something to be done lightly. It also depends on what version of OpenSSL you are using. Assuming 1.1.0 or 1.1.1 then you would need to modify ossl_statem_server_post_work() to call statem_flush(s) for all messages that you want to immediately flush: https://github.com/openssl/openssl/blob/ac48fba036e1764dfa98ed0f0aa932491aa1c4ef/ssl/statem/statem_srvr.c#L787-L979 Possibly something like this might be sufficient as a quick hack...totally untested and without warranty of any kind: diff --git a/ssl/statem/statem_srvr.c b/ssl/statem/statem_srvr.c index e7c11c4bea..c0e613ad47 100644 --- a/ssl/statem/statem_srvr.c +++ b/ssl/statem/statem_srvr.c @@ -790,6 +790,9 @@ WORK_STATE ossl_statem_server_post_work(SSL *s, WORK_STATE wst) s->init_num = 0; + if (statem_flush(s) != 1) + return WORK_MORE_A; + switch (st->hand_state) { default: /* No post work to be done */ Matt > > Le?jeu. 15 nov. 2018 ??12:12, Matt Caswell > a ?crit?: > > > > On 15/11/2018 10:53, Eug?ne Adell wrote: > > Hello, > > > > I am looking for a way to configure OpenSSL then it will send handshake > records > > one by one in their respective TCP packet, instead of sending one big message > > containing several records. Typically, in my network captures I see the server > > sending one message containing Server Hello + Certificate + Server Hello Done > > records, and I would like to know how to send 3 messages, each one containing > > only one record. I checked OpenSSL options and the user mailing-list archives > > without finding the answer, and I am not sure this is even possible (by > > configuration only). > > I'm intrigued to know why you would want to do that. Anyway, I don't believe > this is currently possible without modifying the OpenSSL source code. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > From rsalz at akamai.com Thu Nov 15 13:20:42 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 15 Nov 2018 13:20:42 +0000 Subject: [openssl-users] configuring OpenSSL to split handshake messages In-Reply-To: References: <2a51a660-d3bf-2e47-5827-0a48a734f56a@openssl.org> Message-ID: <515BC2BD-69D1-41E3-A6EE-2AF874A47C75@akamai.com> You can do this by writing your own BIO (probably based on memory) that then dribbles data out to its own internal socket. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Nov 15 14:12:59 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 15 Nov 2018 14:12:59 +0000 Subject: [openssl-users] configuring OpenSSL to split handshake messages In-Reply-To: <2a51a660-d3bf-2e47-5827-0a48a734f56a@openssl.org> References: <2a51a660-d3bf-2e47-5827-0a48a734f56a@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Matt Caswell > Sent: Thursday, November 15, 2018 06:12 > > On 15/11/2018 10:53, Eug?ne Adell wrote: > > I am looking for a way to configure OpenSSL then it will send handshake records > > one by one in their respective TCP packet, instead of sending one big message > > containing several records. > > I'm intrigued to know why you would want to do that. Anyway, I don't believe > this is currently possible without modifying the OpenSSL source code. Even then, it can't be guaranteed at the application level. TCP is a byte-stream service; the stack is permitted to accumulate application sends and split them into TCP segments any way it likes. (And then there's the possibility of IP fragmentation on top of that, though that shouldn't happen on a local network and is unlikely these days in any case, thanks to Path MTU.) Networking APIs such as sockets may let the application attempt to flush output, but the stack can ignore that. Similarly, on the receiving side, the stack can accumulate data or deliver it to the receiving application piecemeal. As long as it's not reordered, TCP makes no guarantees about how it's broken up. (There's the TCP PSH [Push] flag, but that's merely advistory to the receiving stack; the stack can ignore it.) Applications (which includes OpenSSL in this context) should not try to control how messages appear on the wire, aside from attempting to avoid small sends when there is additional data available to send. -- Michael Wojcik Distinguished Engineer, Micro Focus From tshort at akamai.com Thu Nov 15 14:30:31 2018 From: tshort at akamai.com (Short, Todd) Date: Thu, 15 Nov 2018 14:30:31 +0000 Subject: [openssl-users] Extracting decrypt key for AES from openssl on client side In-Reply-To: <8B9324BA-ABB9-4901-A6FA-C73E9F6F106E@dukhovni.org> References: <8B9324BA-ABB9-4901-A6FA-C73E9F6F106E@dukhovni.org> Message-ID: <137A4D5B-D128-4B42-868D-A4BF3B24E959@akamai.com> I have seen this done for hardware acceleration; where the crypto chip can do everything except the handshake. (In fact, this mechanism protected at least one device that I know of from the Heartbleed debacle, since the hardware crypto did not understand the record type.) Look at how the kernel handles TLS, and how the keys are extracted from OpenSSL: https://github.com/torvalds/linux/blob/master/Documentation/networking/tls.txt https://github.com/openssl/openssl/pull/5253 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 14, 2018, at 11:28 AM, Viktor Dukhovni > wrote: On Nov 14, 2018, at 6:54 AM, Hemant Ranvir > wrote: My main goal here is to use openssl for initial handshake sequence. Once the connection is established between server and client, decrypt the incoming message (this time not using the openssl api but rather by using the decrypt AES function implemented earlier) This makes no sense, because TLS does not just emit a simple CBC encrypted stream after performing the handshake. So you can't do that. Use SSL_read()/SSL_write, and let the library do the message decryption/encryption for you. When done use SSL_shutdown() to cleanly terminate the stream, and depending on the application protocol, make wait for the peer's SSL_shutdown() in turn to avoid truncation attacks where completion of the stream is not implied by the higher level protocol. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Nov 15 15:17:52 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 15 Nov 2018 10:17:52 -0500 Subject: [openssl-users] Extracting decrypt key for AES from openssl on client side In-Reply-To: <137A4D5B-D128-4B42-868D-A4BF3B24E959@akamai.com> References: <8B9324BA-ABB9-4901-A6FA-C73E9F6F106E@dukhovni.org> <137A4D5B-D128-4B42-868D-A4BF3B24E959@akamai.com> Message-ID: > On Nov 15, 2018, at 9:30 AM, Short, Todd via openssl-users wrote: > > I have seen this done for hardware acceleration; where the crypto chip can do everything except the handshake. > (In fact, this mechanism protected at least one device that I know of from the Heartbleed debacle, since the hardware crypto did not understand the record type.) > > Look at how the kernel handles TLS, and how the keys are extracted from OpenSSL: > > https://github.com/torvalds/linux/blob/master/Documentation/networking/tls.txt > https://github.com/openssl/openssl/pull/5253 Well, it takes more than just extracting a key. One also needs to know the cipher mode, and if not AEAD then the MAC algorithm and whether the EtM extension has been negotiated, and with TLS 1.3 be prepared to process keyUpdate messages, post handshake session tickets, ... -- Viktor. From openssl-users at dukhovni.org Thu Nov 15 20:12:20 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 15 Nov 2018 15:12:20 -0500 Subject: [openssl-users] configuring OpenSSL to split handshake messages In-Reply-To: References: Message-ID: <20181115201220.GE4140@straasha.imrryr.org> > On Nov 15, 2018, at 5:53 AM, Eug?ne Adell wrote: > > I am looking for a way to configure OpenSSL then it will send handshake > records one by one in their respective TCP packet, instead of sending one > big message containing several records. Typically, in my network captures > I see the server sending one message containing Server Hello + Certificate > + Server Hello Done records, and I would like to know how to send 3 > messages, each one containing only one record. I checked OpenSSL options > and the user mailing-list archives without finding the answer, and I am > not sure this is even possible (by configuration only). Not possible "by configuration only", but if you put a biopair between OpenSSL and the network, you can read TLS records from the output side of the biopair (by reading the record header, and then reading the corresponding number of payload bytes), and then attempt to transmit each record separately by performing a separate write to the TCP socket (with Nagle delays disabled). Of course you'll then also need to read from the network socket and write the data to the input side of the biopair. There are examples of biopair use you can find. -- Viktor. From eugene.adell at gmail.com Thu Nov 15 21:51:56 2018 From: eugene.adell at gmail.com (=?UTF-8?Q?Eug=C3=A8ne_Adell?=) Date: Thu, 15 Nov 2018 22:51:56 +0100 Subject: [openssl-users] configuring OpenSSL to split handshake messages In-Reply-To: <20181115201220.GE4140@straasha.imrryr.org> References: <20181115201220.GE4140@straasha.imrryr.org> Message-ID: Thanks for all of your answers. I tried Matt's quick hack, and I confirm it's quick and efficient. I compiled and ran an Apache server, locally (but I'll make more tests) I see what I wanted to see, with the server handshake records being sent one by one. Here is the capture info : No. Time Source Destination Window size value Protocol Length Server Name Info 4 0.243570 127.0.0.1 127.0.0.1 43690 TCP 74 46706 ? 7989 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1203506813 TSecr=0 WS=128 5 0.243722 127.0.0.1 127.0.0.1 43690 TCP 74 7989 ? 46706 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1203506813 TSecr=1203506813 WS=128 6 0.243877 127.0.0.1 127.0.0.1 342 TCP 66 46706 ? 7989 [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=1203506814 TSecr=1203506813 7 0.455007 127.0.0.1 127.0.0.1 342 TLSv1.2 239 localhost Client Hello 8 0.455119 127.0.0.1 127.0.0.1 350 TCP 66 7989 ? 46706 [ACK] Seq=1 Ack=174 Win=44800 Len=0 TSval=1203507025 TSecr=1203507025 9 0.457130 127.0.0.1 127.0.0.1 350 TLSv1.2 160 Server Hello 10 0.457156 127.0.0.1 127.0.0.1 342 TCP 66 46706 ? 7989 [ACK] Seq=174 Ack=95 Win=43776 Len=0 TSval=1203507027 TSecr=1203507027 11 0.457384 127.0.0.1 127.0.0.1 350 TLSv1.2 905 Certificate 12 0.457413 127.0.0.1 127.0.0.1 355 TCP 66 46706 ? 7989 [ACK] Seq=174 Ack=934 Win=45440 Len=0 TSval=1203507027 TSecr=1203507027 13 0.464522 127.0.0.1 127.0.0.1 350 TLSv1.2 404 Server Key Exchange 14 0.464551 127.0.0.1 127.0.0.1 368 TCP 66 46706 ? 7989 [ACK] Seq=174 Ack=1272 Win=47104 Len=0 TSval=1203507034 TSecr=1203507034 15 0.464682 127.0.0.1 127.0.0.1 350 TLSv1.2 75 Server Hello Done 16 0.464706 127.0.0.1 127.0.0.1 368 TCP 66 46706 ? 7989 [ACK] Seq=174 Ack=1281 Win=47104 Len=0 TSval=1203507035 TSecr=1203507034 17 0.472451 127.0.0.1 127.0.0.1 368 TLSv1.2 192 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 18 0.474058 127.0.0.1 127.0.0.1 350 TLSv1.2 72 Change Cipher Spec 19 0.474291 127.0.0.1 127.0.0.1 350 TLSv1.2 111 Encrypted Handshake Message 20 0.474425 127.0.0.1 127.0.0.1 368 TCP 66 46706 ? 7989 [ACK] Seq=300 Ack=1332 Win=47104 Len=0 TSval=1203507044 TSecr=1203507044 21 0.475191 127.0.0.1 127.0.0.1 368 TLSv1.2 173 Application Data 22 0.476450 127.0.0.1 127.0.0.1 350 TLSv1.2 379 Application Data 23 0.477625 127.0.0.1 127.0.0.1 381 TLSv1.2 97 Encrypted Alert 24 0.477949 127.0.0.1 127.0.0.1 381 TCP 66 46706 ? 7989 [FIN, ACK] Seq=438 Ack=1645 Win=48768 Len=0 TSval=1203507048 TSecr=1203507046 25 0.478294 127.0.0.1 127.0.0.1 350 TLSv1.2 97 Encrypted Alert 26 0.478356 127.0.0.1 127.0.0.1 0 TCP 54 46706 ? 7989 [RST] Seq=439 Win=0 Len=0 Eugene. Le jeu. 15 nov. 2018 ? 21:12, Viktor Dukhovni a ?crit : > > On Nov 15, 2018, at 5:53 AM, Eug?ne Adell > wrote: > > > > I am looking for a way to configure OpenSSL then it will send handshake > > records one by one in their respective TCP packet, instead of sending one > > big message containing several records. Typically, in my network captures > > I see the server sending one message containing Server Hello + > Certificate > > + Server Hello Done records, and I would like to know how to send 3 > > messages, each one containing only one record. I checked OpenSSL options > > and the user mailing-list archives without finding the answer, and I am > > not sure this is even possible (by configuration only). > > Not possible "by configuration only", but if you put a biopair between > OpenSSL and the network, you can read TLS records from the output side > of the biopair (by reading the record header, and then reading the > corresponding number of payload bytes), and then attempt to transmit > each record separately by performing a separate write to the TCP > socket (with Nagle delays disabled). > > Of course you'll then also need to read from the network socket and > write the data to the input side of the biopair. There are examples > of biopair use you can find. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnnie.l.birch.jr at intel.com Fri Nov 16 02:35:32 2018 From: johnnie.l.birch.jr at intel.com (Birch Jr, Johnnie L) Date: Fri, 16 Nov 2018 02:35:32 +0000 Subject: [openssl-users] Using an engine for supporting SSL/TLS session creation Message-ID: Hi, I have a question that is maybe similar to this one asked about a year ago: https://mta.openssl.org/pipermail/openssl-users/2017-December/007050.html. I want to experiment with trying to hide the keys and certificates used during TLS session creation inside trusted hardware. I am not sure what is possible with openssl engines ... whether they are just for offloading for encryption and hash algorithms or if they can be used for intercepting at a higher granularity to do things such as creating packets for an initial handshake. Looking through some source code it looks like just the former is the intent, but even here I am wondering how best to get started. Specifically for a TLS handshake I am wondering what part of the handshake can be intercepted through an engine plugin? What code should I be focused on as an example and/or to interface with for creating this engine? Also, maybe an engine is not the way to go ... are there better approaches using openssl for experimenting with hiding session creation material? Thanks, Johnnie -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulo at matos-sorge.com Fri Nov 16 08:08:50 2018 From: paulo at matos-sorge.com (Paulo Matos) Date: Fri, 16 Nov 2018 09:08:50 +0100 Subject: [openssl-users] Use of SEED_ofb128_encrypt in SHA1 calculations Message-ID: Hi, I have a program where I am doing millions of calculations of SHA1 per second. This is a tight loop with call to SHA1_Init, SHA1_Update and SHA1_Final. Interestingly when I profile with gperf and visualize with pprof, I see 64.8% of the time spent in SEED_ofb128_encrypt. I can't see how seeding is related to SHA1. At the same time, I can't break into it in gdb and I can't understand where it's being called. Could you please shed some light on why this function is called and if there's something I can do about it? Kind regards, -- Paulo Matos From paulo at matos-sorge.com Fri Nov 16 09:26:53 2018 From: paulo at matos-sorge.com (Paulo Matos) Date: Fri, 16 Nov 2018 10:26:53 +0100 Subject: [openssl-users] Use of SEED_ofb128_encrypt in SHA1 calculations In-Reply-To: References: Message-ID: Apologies for my mistake. I think I was profiling the whole CPU instead of just my process. Please disregard. Paulo Matos On 16/11/2018 09:08, Paulo Matos via openssl-users wrote: > Hi, > > I have a program where I am doing millions of calculations of SHA1 per > second. This is a tight loop with call to SHA1_Init, SHA1_Update and > SHA1_Final. Interestingly when I profile with gperf and visualize with > pprof, I see 64.8% of the time spent in SEED_ofb128_encrypt. I can't see > how seeding is related to SHA1. At the same time, I can't break into it > in gdb and I can't understand where it's being called. > > Could you please shed some light on why this function is called and if > there's something I can do about it? > > Kind regards, > -- Paulo Matos From hkario at redhat.com Fri Nov 16 11:44:03 2018 From: hkario at redhat.com (Hubert Kario) Date: Fri, 16 Nov 2018 12:44:03 +0100 Subject: [openssl-users] configuring OpenSSL to split handshake messages In-Reply-To: References: <2a51a660-d3bf-2e47-5827-0a48a734f56a@openssl.org> Message-ID: <3163024.UY0eea6WM6@pintsize.usersys.redhat.com> On Thursday, 15 November 2018 12:17:41 CET Eug?ne Adell wrote: > This is mainly for experimental reason (client compliance checking, > performance measurement). As the SSL/TLS protocol allows it, why not to > test ? > If no other solution than modifying the source code, where should I look ? beating my own drum: there's https://github.com/tomato42/tlsfuzzer aimed specifically for doing that (testing and full control over handshake) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From ckashiquekvk at gmail.com Fri Nov 16 12:45:39 2018 From: ckashiquekvk at gmail.com (ASHIQUE CK) Date: Fri, 16 Nov 2018 18:15:39 +0530 Subject: [openssl-users] AESCBC support in SSL Message-ID: Hi Sir, Does SSL connection supports AESCBC ? I couldnot set AESCBC in "SSL_CTX_set_cipher_list" at client side or in "SSLCipherSuite" at apache server side. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Nov 16 15:27:32 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 16 Nov 2018 10:27:32 -0500 Subject: [openssl-users] AESCBC support in SSL In-Reply-To: References: Message-ID: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> > On Nov 16, 2018, at 7:45 AM, ASHIQUE CK wrote: > > Does SSL connection supports AESCBC? Yes, but not under that name. > I could not set AESCBC in "SSL_CTX_set_cipher_list" at client side or in "SSLCipherSuite" at apache server side. For example (constrained also to RSA and ECDHE to keep the list short): $ openssl ciphers -v 'AES128+aRSA+kECDHE:!AESGCM' ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 There isn't a cipherlist property that specifically selects CBC, so to get *only* CBC, you need to exclude AESGCM (and perhaps also AESCCM). -- Viktor. From OpenSSL at k-h.us Sun Nov 18 01:57:40 2018 From: OpenSSL at k-h.us (Ken) Date: Sat, 17 Nov 2018 17:57:40 -0800 Subject: [openssl-users] Problem with x509_verify_certificate Message-ID: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), which uses x509_verify_certificate to check the validity of a certificate on a RDP server. Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips 26 Sep 2016") everything works great. But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version "1.1.0i-fips? 14 Aug 2018") I get an error when connecting to servers that use publicly-signed certificates: Certificate details: ??????? Subject: OU = Domain Control Validated, CN = owa.xxxxx.com ??????? Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 ??????? Thumbprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx The above X.509 certificate could not be verified, possibly because you do not have the CA certificate in your certificate store, or the certificate has expired. Please look at the OpenSSL documentation on how to add a private CA to the store. Do you trust the above certificate? (Y/T/N) On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips? 14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips 26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.) Any idea what changed? (Or, better question, what needs to be changed to make this application work again?) Thanks, Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Sun Nov 18 03:23:58 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Sat, 17 Nov 2018 22:23:58 -0500 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> Message-ID: <29E3BAA3-EC0A-4D31-A8CB-E05639C8B81E@felipegasper.com> Maybe the set of stores root certificates changed with the update? Try openssl s_client to debug it? > On Nov 17, 2018, at 8:57 PM, Ken wrote: > > I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), which uses x509_verify_certificate to check the validity of a certificate on a RDP server. > > Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips 26 Sep 2016") everything works great. > > But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version "1.1.0i-fips 14 Aug 2018") I get an error when connecting to servers that use publicly-signed certificates: > > Certificate details: > Subject: OU = Domain Control Validated, CN = owa.xxxxx.com > Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 > Thumbprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx > The above X.509 certificate could not be verified, possibly because you do not have > the CA certificate in your certificate store, or the certificate has expired. > Please look at the OpenSSL documentation on how to add a private CA to the store. > Do you trust the above certificate? (Y/T/N) > > > On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips 14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips 26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.) > > > Any idea what changed? (Or, better question, what needs to be changed to make this application work again?) > > > Thanks, > Ken > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From OpenSSL at k-h.us Sun Nov 18 05:45:05 2018 From: OpenSSL at k-h.us (Ken) Date: Sat, 17 Nov 2018 21:45:05 -0800 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <29E3BAA3-EC0A-4D31-A8CB-E05639C8B81E@felipegasper.com> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <29E3BAA3-EC0A-4D31-A8CB-E05639C8B81E@felipegasper.com> Message-ID: I think that the output from s_client (see attached) says that it passed, for both versions. Also, the output from s_client shows it looking for the correct CA file on both versions (and shows that the file exists), but it only opens the CA file under openssl version "1.0.2j-fips? 26 Sep 2016". ------?Original?Message?------ From:?Felipe Gasper Sent:?Sat, 17 Nov 2018 22:23:58 -0500 To:?Openssl-users Subject:?Re: [openssl-users] Problem with x509_verify_certificate > Maybe the set of stores root certificates changed with the update? > > Try openssl s_client to debug it? > > On Nov 17, 2018, at 8:57 PM, Ken > wrote: > >> I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), >> which uses x509_verify_certificate to check the validity of a >> certificate on a RDP server. >> >> Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips? 26 >> Sep 2016") everything works great. >> >> But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version >> "1.1.0i-fips? 14 Aug 2018") I get an error when connecting to servers >> that use publicly-signed certificates: >> >> Certificate details: >> ??????? Subject: OU = Domain Control Validated, CN = owa.xxxxx.com >> >> ??????? Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield >> Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, >> CN = Starfield Secure Certificate Authority - G2 >> ??????? Thumbprint: >> xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx >> The above X.509 certificate could not be verified, possibly because >> you do not have >> the CA certificate in your certificate store, or the certificate has >> expired. >> Please look at the OpenSSL documentation on how to add a private CA >> to the store. >> Do you trust the above certificate? (Y/T/N) >> >> >> On both versions, strace shows is it checking for >> /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the >> correct CA) - but with openssl version "1.1.0i-fips? 14 Aug 2018", it >> never opens that file. (With openssl version "1.0.2j-fips? 26 Sep >> 2016", it does open/read that file, which it seems like it work need >> to, in order to find out if it matches the certificate.) >> >> >> Any idea what changed? (Or, better question, what needs to be changed >> to make this application work again?) >> >> >> Thanks, >> Ken >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- openssl s_client -connect owa.xxxxx.com:3389 < /dev/null CONNECTED(00000003) depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 verify return:1 depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 verify return:1 depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=owa.xxxxx.com i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2 --- Server certificate -----BEGIN CERTIFICATE----- MIIGNDCCBRygAwIBAgIIXFXbiPD1+PYwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMSUw IwYDVQQKExxTdGFyZmllbGQgVGVjaG5vbG9naWVzLCBJbmMuMTMwMQYDVQQLEypo . . . vpY77wmUtuPlIBBA0vmoLkqm3kLq31Ax9O83BgLCnHUHBfq3UuJSOIjZb9GDzc1L 1r1jePMxklnJFxFMS+D5gJmSNMoOnaop1EtH+8WAsnR16D15mNdtTHEzH106oJaW KTNa8smgpv+uweIrV68wsctfTK4jMdZXGdIKFy+8sA7T5aRmme0EbFl8Skzc408K QT7Tk+QwmXU= -----END CERTIFICATE----- subject=/OU=Domain Control Validated/CN=owa.xxxxx.com issuer=/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 --- No client certificate CA names sent Peer signing digest: SHA1 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3419 bytes and written 475 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-SHA384 Session-ID: 941A0000A0B1EEA13483B0FEB706B589A9F209BE3358C3A995C4ED1ED59265EE Session-ID-ctx: Master-Key: A08B359932ACFD5B74136EBB8493F324A70C4CE59031174867ECA8FF03D1A34A641E8217823F5CDDCDC5075E6DA37BA7 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1542518377 Timeout : 300 (sec) Verify return code: 0 (ok) --- DONE -------------- next part -------------- openssl s_client -connect owa.xxxxx.com:3389 < /dev/null CONNECTED(00000003) depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 verify return:1 depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 verify return:1 depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=owa.xxxxx.com i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2 --- Server certificate -----BEGIN CERTIFICATE----- MIIGNDCCBRygAwIBAgIIXFXbiPD1+PYwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMSUw IwYDVQQKExxTdGFyZmllbGQgVGVjaG5vbG9naWVzLCBJbmMuMTMwMQYDVQQLEypo . . . vpY77wmUtuPlIBBA0vmoLkqm3kLq31Ax9O83BgLCnHUHBfq3UuJSOIjZb9GDzc1L 1r1jePMxklnJFxFMS+D5gJmSNMoOnaop1EtH+8WAsnR16D15mNdtTHEzH106oJaW KTNa8smgpv+uweIrV68wsctfTK4jMdZXGdIKFy+8sA7T5aRmme0EbFl8Skzc408K QT7Tk+QwmXU= -----END CERTIFICATE----- subject=/OU=Domain Control Validated/CN=owa.xxxxx.com issuer=/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 --- No client certificate CA names sent Peer signing digest: SHA1 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3423 bytes and written 358 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-SHA384 Session-ID: F43500001034795A9A20EA524CE9866A31A3869DB075988A7B545593FE557EEB Session-ID-ctx: Master-Key: 1E07E2347032579D218950FB4DE3A15B7A13831405D44157B948D1237C22F6B8B3AE9204352E980765D5476EAF8220E3 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1542518370 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes --- DONE From openssl-users at dukhovni.org Sun Nov 18 05:54:46 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 18 Nov 2018 00:54:46 -0500 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> Message-ID: <8BCEDD80-4DFB-46F1-B9AB-847F97169A58@dukhovni.org> I would suggest running "c_rehash" on the directory, making sure it is the c_rehash for OpenSSL 1.1.x, and not some other version. > On Nov 17, 2018, at 8:57 PM, Ken wrote: > > On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips 14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips 26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.) > > Any idea what changed? (Or, better question, what needs to be changed to make this application work again?) The way that DN hashes are computed changed from 0.9.8 to 1.0.0, but IIRC then remained stable, so I would not expect a change between 1.0.2 and 1.1.0. It is difficult to offer more help without copies of the certificates in question. The main change between 1.1.0 and 1.0.2 is that "trusted_first" is now the default behaviour and cannot be changed. This means that intermediate certificates supplied with the peer chain are used only when no issuer is present in the trust store. This can lead to a different chain being computed in some cases. -- Viktor. From openssl-users at dukhovni.org Sun Nov 18 06:00:50 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 18 Nov 2018 01:00:50 -0500 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> Message-ID: <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> Most likely there's a stale (expired) copy of the intermediate certificate in question in the trust store, but the peer (server) sent an unexpired version in the handshake. The solution is to remove the stale intermediate from the trust store. > On Nov 17, 2018, at 8:57 PM, Ken wrote: > > I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), which uses x509_verify_certificate to check the validity of a certificate on a RDP server. > > Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips 26 Sep 2016") everything works great. > > But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version "1.1.0i-fips 14 Aug 2018") I get an error when connecting to servers that use publicly-signed certificates: > > Certificate details: > Subject: OU = Domain Control Validated, CN = owa.xxxxx.com > Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU =http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 > Thumbprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx > The above X.509 certificate could not be verified, possibly because you do not have > the CA certificate in your certificate store, or the certificate has expired. > Please look at the OpenSSL documentation on how to add a private CA to the store. > Do you trust the above certificate? (Y/T/N) > > > On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips 14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips 26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.) > > > Any idea what changed? (Or, better question, what needs to be changed to make this application work again?) -- Viktor. From ckashiquekvk at gmail.com Mon Nov 19 05:42:46 2018 From: ckashiquekvk at gmail.com (ASHIQUE CK) Date: Mon, 19 Nov 2018 11:12:46 +0530 Subject: [openssl-users] AESCBC support in SSL In-Reply-To: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> References: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> Message-ID: Hi, I had given all the cipher strings for "SSL_CTX_set_cipher_list" which we get under the command 'openssl ciphers' that includes CBC, but any of them didnot worked. All of them showed the error "error:141640B5:SSL routines:tls_construct_client_hello:no ciphers available". I have used TLSv1_2 or SSLv23. Also I have tried setting these strings for "SSLCipherSuite" at apache server configuration. But it makes no change for choosing the server default ciphersuit "ECDHE-RSA-AES256-GCM-SHA384". Thanks On Fri, Nov 16, 2018 at 9:15 PM Viktor Dukhovni wrote: > > > > On Nov 16, 2018, at 7:45 AM, ASHIQUE CK wrote: > > > > Does SSL connection supports AESCBC? > > Yes, but not under that name. > > > I could not set AESCBC in "SSL_CTX_set_cipher_list" at client side or > in "SSLCipherSuite" at apache server side. > > For example (constrained also to RSA and ECDHE to keep the list short): > > $ openssl ciphers -v 'AES128+aRSA+kECDHE:!AESGCM' > ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 > ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 > > There isn't a cipherlist property that specifically selects CBC, so to > get *only* CBC, you need to exclude AESGCM (and perhaps also AESCCM). > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ckashiquekvk at gmail.com Mon Nov 19 05:53:53 2018 From: ckashiquekvk at gmail.com (ASHIQUE CK) Date: Mon, 19 Nov 2018 11:23:53 +0530 Subject: [openssl-users] AESCBC support in SSL In-Reply-To: References: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> Message-ID: Is it the problem with that strings or TLS/SSL version or any other ? On Mon, Nov 19, 2018 at 11:12 AM ASHIQUE CK wrote: > Hi, > I had given all the cipher strings for "SSL_CTX_set_cipher_list" which we > get under the command 'openssl ciphers' that includes CBC, but any of them > didnot worked. All of them showed the error "error:141640B5:SSL > routines:tls_construct_client_hello:no ciphers available". I have used > TLSv1_2 or SSLv23. > Also I have tried setting these strings for "SSLCipherSuite" at apache > server configuration. But it makes no change for choosing the server > default ciphersuit "ECDHE-RSA-AES256-GCM-SHA384". > > Thanks > > On Fri, Nov 16, 2018 at 9:15 PM Viktor Dukhovni < > openssl-users at dukhovni.org> wrote: > >> >> >> > On Nov 16, 2018, at 7:45 AM, ASHIQUE CK wrote: >> > >> > Does SSL connection supports AESCBC? >> >> Yes, but not under that name. >> >> > I could not set AESCBC in "SSL_CTX_set_cipher_list" at client side or >> in "SSLCipherSuite" at apache server side. >> >> For example (constrained also to RSA and ECDHE to keep the list short): >> >> $ openssl ciphers -v 'AES128+aRSA+kECDHE:!AESGCM' >> ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 >> ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 >> >> There isn't a cipherlist property that specifically selects CBC, so to >> get *only* CBC, you need to exclude AESGCM (and perhaps also AESCCM). >> >> -- >> Viktor. >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From OpenSSL at k-h.us Mon Nov 19 06:03:23 2018 From: OpenSSL at k-h.us (Ken) Date: Sun, 18 Nov 2018 22:03:23 -0800 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <8BCEDD80-4DFB-46F1-B9AB-847F97169A58@dukhovni.org> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <8BCEDD80-4DFB-46F1-B9AB-847F97169A58@dukhovni.org> Message-ID: <654dcb8e-ae8c-2367-edf7-3d8e0c7daa24@k-h.us> "c_rehash" did not make any difference. ------?Original?Message?------ From:?Viktor Dukhovni Sent:?Sun, 18 Nov 2018 00:54:46 -0500 To:?Openssl-users Subject:?Re: [openssl-users] Problem with x509_verify_certificate > I would suggest running "c_rehash" on the directory, making sure it is > the c_rehash for OpenSSL 1.1.x, and not some other version. > >> On Nov 17, 2018, at 8:57 PM, Ken wrote: >> >> On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips 14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips 26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.) >> >> Any idea what changed? (Or, better question, what needs to be changed to make this application work again?) > The way that DN hashes are computed changed from 0.9.8 to 1.0.0, but IIRC then > remained stable, so I would not expect a change between 1.0.2 and 1.1.0. > > It is difficult to offer more help without copies of the certificates in question. > > The main change between 1.1.0 and 1.0.2 is that "trusted_first" is now > the default behaviour and cannot be changed. This means that intermediate > certificates supplied with the peer chain are used only when no issuer is > present in the trust store. This can lead to a different chain being > computed in some cases. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon Nov 19 06:03:57 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 19 Nov 2018 09:03:57 +0300 Subject: [openssl-users] AESCBC support in SSL In-Reply-To: References: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> Message-ID: Do you use any RedHat-based OS? On Mon, Nov 19, 2018 at 8:54 AM ASHIQUE CK wrote: > Is it the problem with that strings or TLS/SSL version or any other ? > > On Mon, Nov 19, 2018 at 11:12 AM ASHIQUE CK > wrote: > >> Hi, >> I had given all the cipher strings for "SSL_CTX_set_cipher_list" which >> we get under the command 'openssl ciphers' that includes CBC, but any of >> them didnot worked. All of them showed the error "error:141640B5:SSL >> routines:tls_construct_client_hello:no ciphers available". I have used >> TLSv1_2 or SSLv23. >> Also I have tried setting these strings for "SSLCipherSuite" at apache >> server configuration. But it makes no change for choosing the server >> default ciphersuit "ECDHE-RSA-AES256-GCM-SHA384". >> >> Thanks >> >> On Fri, Nov 16, 2018 at 9:15 PM Viktor Dukhovni < >> openssl-users at dukhovni.org> wrote: >> >>> >>> >>> > On Nov 16, 2018, at 7:45 AM, ASHIQUE CK >>> wrote: >>> > >>> > Does SSL connection supports AESCBC? >>> >>> Yes, but not under that name. >>> >>> > I could not set AESCBC in "SSL_CTX_set_cipher_list" at client side or >>> in "SSLCipherSuite" at apache server side. >>> >>> For example (constrained also to RSA and ECDHE to keep the list short): >>> >>> $ openssl ciphers -v 'AES128+aRSA+kECDHE:!AESGCM' >>> ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 >>> ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 >>> >>> There isn't a cipherlist property that specifically selects CBC, so to >>> get *only* CBC, you need to exclude AESGCM (and perhaps also AESCCM). >>> >>> -- >>> Viktor. >>> >>> -- >>> 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 > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From ckashiquekvk at gmail.com Mon Nov 19 06:06:17 2018 From: ckashiquekvk at gmail.com (ASHIQUE CK) Date: Mon, 19 Nov 2018 11:36:17 +0530 Subject: [openssl-users] AESCBC support in SSL In-Reply-To: References: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> Message-ID: No, We use Ubuntu 16.04 OS On Mon, Nov 19, 2018 at 11:34 AM Dmitry Belyavsky wrote: > Do you use any RedHat-based OS? > > On Mon, Nov 19, 2018 at 8:54 AM ASHIQUE CK wrote: > >> Is it the problem with that strings or TLS/SSL version or any other ? >> >> On Mon, Nov 19, 2018 at 11:12 AM ASHIQUE CK >> wrote: >> >>> Hi, >>> I had given all the cipher strings for "SSL_CTX_set_cipher_list" which >>> we get under the command 'openssl ciphers' that includes CBC, but any of >>> them didnot worked. All of them showed the error "error:141640B5:SSL >>> routines:tls_construct_client_hello:no ciphers available". I have used >>> TLSv1_2 or SSLv23. >>> Also I have tried setting these strings for "SSLCipherSuite" at apache >>> server configuration. But it makes no change for choosing the server >>> default ciphersuit "ECDHE-RSA-AES256-GCM-SHA384". >>> >>> Thanks >>> >>> On Fri, Nov 16, 2018 at 9:15 PM Viktor Dukhovni < >>> openssl-users at dukhovni.org> wrote: >>> >>>> >>>> >>>> > On Nov 16, 2018, at 7:45 AM, ASHIQUE CK >>>> wrote: >>>> > >>>> > Does SSL connection supports AESCBC? >>>> >>>> Yes, but not under that name. >>>> >>>> > I could not set AESCBC in "SSL_CTX_set_cipher_list" at client side >>>> or in "SSLCipherSuite" at apache server side. >>>> >>>> For example (constrained also to RSA and ECDHE to keep the list short): >>>> >>>> $ openssl ciphers -v 'AES128+aRSA+kECDHE:!AESGCM' >>>> ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 >>>> ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 >>>> >>>> There isn't a cipherlist property that specifically selects CBC, so to >>>> get *only* CBC, you need to exclude AESGCM (and perhaps also AESCCM). >>>> >>>> -- >>>> Viktor. >>>> >>>> -- >>>> 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 >> > > > -- > SY, Dmitry Belyavsky > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 19 06:09:45 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 19 Nov 2018 01:09:45 -0500 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <654dcb8e-ae8c-2367-edf7-3d8e0c7daa24@k-h.us> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <8BCEDD80-4DFB-46F1-B9AB-847F97169A58@dukhovni.org> <654dcb8e-ae8c-2367-edf7-3d8e0c7daa24@k-h.us> Message-ID: <739B069F-3C63-47E1-9013-768604835C49@dukhovni.org> In that case, remove stale, possibly expired intermediate CAs from your CAfile/CApath as mentioned in an earlier message. Then c_rehash once more. > On Nov 19, 2018, at 1:03 AM, Ken wrote: > > "c_rehash" did not make any difference. -- Viktor. From ckashiquekvk at gmail.com Mon Nov 19 06:09:31 2018 From: ckashiquekvk at gmail.com (ASHIQUE CK) Date: Mon, 19 Nov 2018 11:39:31 +0530 Subject: [openssl-users] AESCBC support in SSL In-Reply-To: References: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> Message-ID: Also I use OpenSSL 1.1.0h. On Mon, Nov 19, 2018 at 11:36 AM ASHIQUE CK wrote: > No, We use Ubuntu 16.04 OS > > On Mon, Nov 19, 2018 at 11:34 AM Dmitry Belyavsky > wrote: > >> Do you use any RedHat-based OS? >> >> On Mon, Nov 19, 2018 at 8:54 AM ASHIQUE CK >> wrote: >> >>> Is it the problem with that strings or TLS/SSL version or any other ? >>> >>> On Mon, Nov 19, 2018 at 11:12 AM ASHIQUE CK >>> wrote: >>> >>>> Hi, >>>> I had given all the cipher strings for "SSL_CTX_set_cipher_list" which >>>> we get under the command 'openssl ciphers' that includes CBC, but any of >>>> them didnot worked. All of them showed the error "error:141640B5:SSL >>>> routines:tls_construct_client_hello:no ciphers available". I have used >>>> TLSv1_2 or SSLv23. >>>> Also I have tried setting these strings for "SSLCipherSuite" at apache >>>> server configuration. But it makes no change for choosing the server >>>> default ciphersuit "ECDHE-RSA-AES256-GCM-SHA384". >>>> >>>> Thanks >>>> >>>> On Fri, Nov 16, 2018 at 9:15 PM Viktor Dukhovni < >>>> openssl-users at dukhovni.org> wrote: >>>> >>>>> >>>>> >>>>> > On Nov 16, 2018, at 7:45 AM, ASHIQUE CK >>>>> wrote: >>>>> > >>>>> > Does SSL connection supports AESCBC? >>>>> >>>>> Yes, but not under that name. >>>>> >>>>> > I could not set AESCBC in "SSL_CTX_set_cipher_list" at client side >>>>> or in "SSLCipherSuite" at apache server side. >>>>> >>>>> For example (constrained also to RSA and ECDHE to keep the list short): >>>>> >>>>> $ openssl ciphers -v 'AES128+aRSA+kECDHE:!AESGCM' >>>>> ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) >>>>> Mac=SHA256 >>>>> ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 >>>>> >>>>> There isn't a cipherlist property that specifically selects CBC, so to >>>>> get *only* CBC, you need to exclude AESGCM (and perhaps also AESCCM). >>>>> >>>>> -- >>>>> Viktor. >>>>> >>>>> -- >>>>> 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 >>> >> >> >> -- >> SY, Dmitry Belyavsky >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From OpenSSL at k-h.us Mon Nov 19 06:15:58 2018 From: OpenSSL at k-h.us (Ken) Date: Sun, 18 Nov 2018 22:15:58 -0800 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> Message-ID: <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> There are no stale intermediate certificates on my computer. (This was a fresh install, on a new drive. I should have never said "upgrade".) Also, strace shows that it is looking for the correct CA certificate (/var/lib/ca-certificates/openssl/4bfab552.0), and being told that it exists - but with the newer version of openssl, it never tries to open the CA certificate (the older version does). ------?Original?Message?------ From:?Viktor Dukhovni Sent:?Sun, 18 Nov 2018 01:00:50 -0500 To:?Openssl-users Subject:?Re: [openssl-users] Problem with x509_verify_certificate > Most likely there's a stale (expired) copy of the intermediate certificate in > question in the trust store, but the peer (server) sent an unexpired version > in the handshake. The solution is to remove the stale intermediate from > the trust store. > >> On Nov 17, 2018, at 8:57 PM, Ken wrote: >> >> I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), which uses x509_verify_certificate to check the validity of a certificate on a RDP server. >> >> Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips 26 Sep 2016") everything works great. >> >> But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version "1.1.0i-fips 14 Aug 2018") I get an error when connecting to servers that use publicly-signed certificates: >> >> Certificate details: >> Subject: OU = Domain Control Validated, CN = owa.xxxxx.com >> Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU =http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 >> Thumbprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx >> The above X.509 certificate could not be verified, possibly because you do not have >> the CA certificate in your certificate store, or the certificate has expired. >> Please look at the OpenSSL documentation on how to add a private CA to the store. >> Do you trust the above certificate? (Y/T/N) >> >> >> On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips 14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips 26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.) >> >> >> Any idea what changed? (Or, better question, what needs to be changed to make this application work again?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 19 06:23:37 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 19 Nov 2018 01:23:37 -0500 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> Message-ID: <5EE3448B-A095-4CE8-B845-8D258F0EB9F7@dukhovni.org> > On Nov 19, 2018, at 1:15 AM, Ken wrote: > > There are no stale intermediate certificates on my computer. The evidence suggests otherwise. > Also, strace shows that it is looking for the correct CA certificate > (/var/lib/ca-certificates/openssl/4bfab552.0), and being told that it > exists - but with the newer version of openssl, it never tries to open > the CA certificate (the older version does). The newer code uses a "trusted first" policy, which means that the intermediate certificate comes from the trust store, not the peer. When it fails to validate (as reported, the failure is verifying the issuer, not leaf certificate) one can reasonably conclude that there's something wrong with an intermediate issuer certificate in the trust store. You can check by creating a new file that contains just the expected root CA and nothing else, and setting CAfile to that, and CApath to an empty directory. Please report the results. -- Viktor. From Christian.Johansson at nixu.com Mon Nov 19 11:40:57 2018 From: Christian.Johansson at nixu.com (Christian Johansson) Date: Mon, 19 Nov 2018 11:40:57 +0000 Subject: [openssl-users] Engine NID_sha512 In-Reply-To: <967539f5b6f94954ab07cc3859f92194@SEGOTNC5113-N3.vcn.ds.volvo.net> References: <967539f5b6f94954ab07cc3859f92194@SEGOTNC5113-N3.vcn.ds.volvo.net> Message-ID: Hello I?m trying to write an engine that implements message digest functions ? specifically: sha256, sha384 and sha512. The first two work as expected, I can intercept calls to update() and final() but for sha512 it doesn?t work. From the below program output you can see that my digest_meths method is invoked as expected for sha256 and sha384 (invoked with nid 672 and 673) but nothing for sha512 even though I supply NID_sha512 in my supported_nids array. I?ve unsuccessfully tried to search for a solution to this ? so any input would be greatly appreciated. How can I hook sha512 from my engine? Relevant Openssl version: OpenSSL 1.0.2o 27 Mar 2018, Kind Regards Christian My digest_meths function: static int engine_digest_meths(ENGINE *e, const EVP_MD **digest, const int **nids, int nid) { // Avoid compiler warning (void)(e); if (!digest) { static int supported_nids[] = {NID_sha256, NID_sha384, NID_sha512, 0}; *nids = supported_nids; return 2; } static EVP_MD newEVP_MDmethods; if (nid == NID_sha256 || nid == NID_sha384 || nid == NID_sha512) { debug_print("SSLEngine: engine_digest_meths called, nid: %i \n", nid); if (nid == NID_sha256) { originalSHA256Methods = EVP_sha256(); memcpy(&newEVP_MDmethods, originalSHA256Methods, sizeof(EVP_MD)); newEVP_MDmethods.update = engine_sha256_update; newEVP_MDmethods.final = engine_sha256_final; } else if (nid == NID_sha384) { originalSHA384Methods = EVP_sha384(); memcpy(&newEVP_MDmethods, originalSHA384Methods, sizeof(EVP_MD)); newEVP_MDmethods.update = engine_sha384_update; newEVP_MDmethods.final = engine_sha384_final; } else if (nid == NID_sha512) { originalSHA512Methods = EVP_sha512(); memcpy(&newEVP_MDmethods, originalSHA512Methods, sizeof(EVP_MD)); newEVP_MDmethods.update = engine_sha512_update; newEVP_MDmethods.final = engine_sha512_final; } *digest = &newEVP_MDmethods; } else { *digest = NULL; return 0; } return 1; } Example test run: test at test:/tmp# ./engine-test Testing SHA256... SSLEngine: engine_digest_meths called, nid: 672 SSLEngine: engine_sha256_update called with 8 bytes SSLEngine: engine_sha256_final called, ret = 1, digest = 2413fb3709b05939f04cf2e92f7d0897fc2596f9ad0b8a9ea855c7bfebaae892 Openssl output = 2413fb3709b05939f04cf2e92f7d0897fc2596f9ad0b8a9ea855c7bfebaae892 Testing SHA384... SSLEngine: engine_digest_meths called, nid: 673 SSLEngine: engine_sha384_update called with 8 bytes SSLEngine: engine_sha384_final called, ret = 1, digest = 26014c5c5fbfa7ea9865f08c320abab5323a1b522c178fb513cbf5cafdf124e3d6748a549f57456ef0f1d67bb8916cc2 Openssl output = 26014c5c5fbfa7ea9865f08c320abab5323a1b522c178fb513cbf5cafdf124e3d6748a549f57456ef0f1d67bb8916cc2 Testing SHA512... Openssl output = ce57d8bc990447c7ec35557040756db2a9ff7cdab53911f3c7995bc6bf3572cda8c94fa53789e523a680de9921c067f6717e79426df467185fc7a6dbec4b2d57 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcoombs at carillon.ca Mon Nov 19 14:08:31 2018 From: dcoombs at carillon.ca (Dave Coombs) Date: Mon, 19 Nov 2018 09:08:31 -0500 Subject: [openssl-users] Engine NID_sha512 In-Reply-To: References: <967539f5b6f94954ab07cc3859f92194@SEGOTNC5113-N3.vcn.ds.volvo.net> Message-ID: Hi, > if (!digest) > { > static int supported_nids[] = {NID_sha256, NID_sha384, NID_sha512, 0}; > *nids = supported_nids; > return 2; > } I think this should be "return 3", to reflect the number of NIDs you're implementing support for. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 9617 bytes Desc: not available URL: From filipe.mfgfernandes at gmail.com Mon Nov 19 16:01:35 2018 From: filipe.mfgfernandes at gmail.com (Filipe Fernandes) Date: Mon, 19 Nov 2018 16:01:35 +0000 Subject: [openssl-users] OpenSSL - Session Resumption on an On-going Connection Message-ID: I'm developing a specific SSL Server, in which it's supposed to have an always-on socket connection. So, to be on the safe side, there's specific needs that need to be filled on this implementation. One of the needs is that the server must send a resumption request (ServerHello) to the client on a cyclic manner. I've tried everything I could, but it seems that the server does not send the ServerHello to the Client. My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the Client *on demand*? The socket should not close, nor perform a renegotiation. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Nov 19 18:46:07 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 19 Nov 2018 18:46:07 +0000 Subject: [openssl-users] OpenSSL - Session Resumption on an On-going Connection In-Reply-To: References: Message-ID: >My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the Client on demand? The socket should not close, nor perform a renegotiation. You have to shutdown and restart the TLS layer. You cannot send arbitrary ServerHello messages, it?s a protocol violation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 19 21:02:32 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 19 Nov 2018 16:02:32 -0500 Subject: [openssl-users] OpenSSL - Session Resumption on an On-going Connection In-Reply-To: References: Message-ID: <20181119210231.GJ4122@straasha.imrryr.org> On Mon, Nov 19, 2018 at 04:01:35PM +0000, Filipe Fernandes wrote: > I'm developing a specific SSL Server, in which it's supposed to have an > always-on socket connection. So, to be on the safe side, there's specific > needs that need to be filled on this implementation. One of the needs is > that the server must send a resumption request (ServerHello) to the client > on a cyclic manner. I've tried everything I could, but it seems that the > server does not send the ServerHello to the Client. This is only possible with TLS <= 1.2, TLS 1.3 eliminated renegotiation. > My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the > Client *on demand*? The socket should not close, nor perform a > renegotiation. The relevant code in apps/s_server.c is: SSL_renegotiate(con); i = SSL_do_handshake(con); this implements the handling of the 'r' magic character, see s_server(1): CONNECTED COMMANDS If a connection request is established with an SSL client and neither the -www nor the -WWW option has been used then normally any data received from the client is displayed and any key presses will be sent to the client. Certain commands are also recognized which perform special operations. These commands are a letter which must appear at the start of a line. They are listed below. [...] r Renegotiate the SSL session (TLSv1.2 and below only). R Renegotiate the SSL session and request a client certificate (TLSv1.2 and below only). -- Viktor. From OpenSSL at k-h.us Tue Nov 20 06:31:40 2018 From: OpenSSL at k-h.us (Ken) Date: Mon, 19 Nov 2018 22:31:40 -0800 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <5EE3448B-A095-4CE8-B845-8D258F0EB9F7@dukhovni.org> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> <5EE3448B-A095-4CE8-B845-8D258F0EB9F7@dukhovni.org> Message-ID: Are you saying to test with "openssl s_client -connect ..."? I don't think I know how to interpret all of the output from that, but it looked to me like it was saying everything was okay when I tried it earlier (with no changes). I just tried it again with -CApath pointing to an empty directory, and -CAfile pointing to a new copy of the root CA certificate, which I just downloaded from the provider - I do not see any difference in the output. Then, I tried again, pointing to an incorrect CA - then I see some errors: "verify error:num=20:unable to get local issuer certificate" So, it seems to me like, without any changes, s_client -connect says the certificate is fine, but the application using x509_verify_certificate thinks something is wrong.... ------?Original?Message?------ From:?Viktor Dukhovni Sent:?Mon, 19 Nov 2018 01:23:37 -0500 To:?Openssl-users Subject:?Re: [openssl-users] Problem with x509_verify_certificate > >> On Nov 19, 2018, at 1:15 AM, Ken wrote: >> >> There are no stale intermediate certificates on my computer. > The evidence suggests otherwise. > >> Also, strace shows that it is looking for the correct CA certificate >> (/var/lib/ca-certificates/openssl/4bfab552.0), and being told that it >> exists - but with the newer version of openssl, it never tries to open >> the CA certificate (the older version does). > The newer code uses a "trusted first" policy, which means that the > intermediate certificate comes from the trust store, not the peer. > When it fails to validate (as reported, the failure is verifying > the issuer, not leaf certificate) one can reasonably conclude that > there's something wrong with an intermediate issuer certificate in > the trust store. > > You can check by creating a new file that contains just > the expected root CA and nothing else, and setting CAfile to > that, and CApath to an empty directory. Please report the results. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From priyahere223 at gmail.com Tue Nov 20 06:49:49 2018 From: priyahere223 at gmail.com (priya p) Date: Tue, 20 Nov 2018 12:19:49 +0530 Subject: [openssl-users] openssl 1.1.1 opaque structures Message-ID: Hi, In openssl-1.1.1, few structures have been made opaque like HMAC_CTX, EVP_CIPHER_CTX etc., There are new API to get and set those structure members. But to zeroize those structure members in place, I dont see any API. Eg : DH strcuture has members like pub_key, priv_key. To zeroize the priv_key , what API should be used ? Can anyone clarify this ? Thanks, Priya -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Johansson at nixu.com Tue Nov 20 07:58:32 2018 From: Christian.Johansson at nixu.com (Christian Johansson) Date: Tue, 20 Nov 2018 07:58:32 +0000 Subject: [openssl-users] Engine NID_sha512 In-Reply-To: References: <967539f5b6f94954ab07cc3859f92194@SEGOTNC5113-N3.vcn.ds.volvo.net> , Message-ID: Wow - nothing like starting the day with a facepalm :-/ Huge thanks Dave!! ________________________________ Fr?n: openssl-users p? uppdrag av Dave Coombs Skickat: m?ndag, november 19, 2018 3:09 em Till: openssl-users at openssl.org ?mne: Re: [openssl-users] Engine NID_sha512 Hi, > if (!digest) > { > static int supported_nids[] = {NID_sha256, NID_sha384, NID_sha512, 0}; > *nids = supported_nids; > return 2; > } I think this should be "return 3", to reflect the number of NIDs you're implementing support for. -Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Nov 20 09:36:15 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 20 Nov 2018 09:36:15 +0000 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: Message-ID: On 20/11/2018 06:49, priya p wrote: > Hi, > > In openssl-1.1.1, few structures have been made opaque like HMAC_CTX, > EVP_CIPHER_CTX etc., > There are new API to get and set those structure members. But to zeroize those > structure members in place, I dont see any API. > Eg : DH strcuture has members like pub_key, priv_key. To zeroize the priv_key , > what API should be used ? > > > Can anyone clarify this ? In the case of DH, DH_free() also zeroizes. Matt From ckashiquekvk at gmail.com Tue Nov 20 09:54:44 2018 From: ckashiquekvk at gmail.com (ASHIQUE CK) Date: Tue, 20 Nov 2018 15:24:44 +0530 Subject: [openssl-users] AESCBC support in SSL In-Reply-To: References: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> Message-ID: Hi, Any replys ? On Mon, Nov 19, 2018 at 11:39 AM ASHIQUE CK wrote: > Also I use OpenSSL 1.1.0h. > > On Mon, Nov 19, 2018 at 11:36 AM ASHIQUE CK > wrote: > >> No, We use Ubuntu 16.04 OS >> >> On Mon, Nov 19, 2018 at 11:34 AM Dmitry Belyavsky >> wrote: >> >>> Do you use any RedHat-based OS? >>> >>> On Mon, Nov 19, 2018 at 8:54 AM ASHIQUE CK >>> wrote: >>> >>>> Is it the problem with that strings or TLS/SSL version or any other ? >>>> >>>> On Mon, Nov 19, 2018 at 11:12 AM ASHIQUE CK >>>> wrote: >>>> >>>>> Hi, >>>>> I had given all the cipher strings for "SSL_CTX_set_cipher_list" >>>>> which we get under the command 'openssl ciphers' that includes CBC, but any >>>>> of them didnot worked. All of them showed the error "error:141640B5:SSL >>>>> routines:tls_construct_client_hello:no ciphers available". I have used >>>>> TLSv1_2 or SSLv23. >>>>> Also I have tried setting these strings for "SSLCipherSuite" at >>>>> apache server configuration. But it makes no change for choosing the server >>>>> default ciphersuit "ECDHE-RSA-AES256-GCM-SHA384". >>>>> >>>>> Thanks >>>>> >>>>> On Fri, Nov 16, 2018 at 9:15 PM Viktor Dukhovni < >>>>> openssl-users at dukhovni.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> > On Nov 16, 2018, at 7:45 AM, ASHIQUE CK >>>>>> wrote: >>>>>> > >>>>>> > Does SSL connection supports AESCBC? >>>>>> >>>>>> Yes, but not under that name. >>>>>> >>>>>> > I could not set AESCBC in "SSL_CTX_set_cipher_list" at client side >>>>>> or in "SSLCipherSuite" at apache server side. >>>>>> >>>>>> For example (constrained also to RSA and ECDHE to keep the list >>>>>> short): >>>>>> >>>>>> $ openssl ciphers -v 'AES128+aRSA+kECDHE:!AESGCM' >>>>>> ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) >>>>>> Mac=SHA256 >>>>>> ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 >>>>>> >>>>>> There isn't a cipherlist property that specifically selects CBC, so to >>>>>> get *only* CBC, you need to exclude AESGCM (and perhaps also AESCCM). >>>>>> >>>>>> -- >>>>>> Viktor. >>>>>> >>>>>> -- >>>>>> 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 >>>> >>> >>> >>> -- >>> SY, Dmitry Belyavsky >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Tue Nov 20 14:17:00 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 20 Nov 2018 14:17:00 +0000 Subject: [openssl-users] OpenSSL version 1.0.2q published Message-ID: <20181120141700.GA29541@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.0.2q released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2q of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2q is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2q.tar.gz Size: 5345604 SHA1 checksum: 692f5f2f1b114f8adaadaa3e7be8cce1907f38c5 SHA256 checksum: 5744cfcbcec2b1b48629f7354203bc1e5e9b5466998bbccc5b5fcde3b18eb684 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2q.tar.gz openssl sha256 openssl-1.0.2q.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlv0D/MACgkQ2cTSbQ5g RJHZwQf/XVVXUUPD6ybAWXzWTAhb4kECMC7ahiEuLwO82IF8dafNNGLWVKU4qD5Q oHCBuHq8UUHPo1s+YeR+3phH0it8xZNUvpDw4BPFlLNkev16+yYJudl2YE9asVep 1Hup97zhSVfF7YS3o4r3TFL6VeAeC0XLHNItIYznldZ7oiI4iCvSH3rZ3Sb3O6lL EpSu3CYqgpbUI09aSZDdwYaUwj7j2KGf3D+U8U+bHY7d47GdvykSk18l1Mt2m/0K 63gDR4Nl+dgkLu6BALuqT79vhkRdiKWV4+e0GhvZPpjpoWBveYY1Q7nkfjy0Sh7j womsen61sS073bbdHZX6LoVuAsQbOw== =WXDE -----END PGP SIGNATURE----- From openssl at openssl.org Tue Nov 20 14:17:19 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 20 Nov 2018 14:17:19 +0000 Subject: [openssl-users] OpenSSL version 1.1.0j published Message-ID: <20181120141719.GA29594@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.0j released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0j of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0j is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0j.tar.gz Size: 5411919 SHA1 checksum: dcad1efbacd9a4ed67d4514470af12bbe2a1d60a SHA256 checksum: 31bec6c203ce1a8e93d5994f4ed304c63ccf07676118b6634edded12ad1b3246 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0j.tar.gz openssl sha256 openssl-1.1.0j.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlv0DwoACgkQ2cTSbQ5g RJGaxggAkHnv1uEc/zs/mIRvJDcBi4ITN3Fgeu2CdmbgMhcLXpKKcVAt28f/bT6c gVgV7OGZbJPJBEz/X6Ed8hIV5+OSIDUyER8Vywo8hhKgA7P0zZKSL6UnHSanes6x zfJCQ43+g2GSKxxBWNo3qsMtbOpgNvqRbggnsOBnrCwiNVUbNGl7BqHDmH8+KzWB tXamWDZ7Q6g6/vpLeQQlR38LXEiC928dSUmeNhbllbEUskkmVQIyys5/uRlFkCcb 9XEHmv4/lSrC3iUe0av4jfo/YjpcaknvqytW+HBgjvb4X1QAERXO0c7qdd9vGU2R 28H8/ETVDvpdnohfEHA2w3gqrZS6Kw== =1c3l -----END PGP SIGNATURE----- From openssl at openssl.org Tue Nov 20 14:17:46 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 20 Nov 2018 14:17:46 +0000 Subject: [openssl-users] OpenSSL version 1.1.1a published Message-ID: <20181120141746.GA29779@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1a released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1a of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1a is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1a.tar.gz Size: 8350547 SHA1 checksum: 8fae27b4f34445a5500c9dc50ae66b4d6472ce29 SHA256 checksum: fc20130f8b7cbd2fb918b2f14e2f429e109c31ddd0fb38fc5d71d9ffed3f9f41 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1a.tar.gz openssl sha256 openssl-1.1.1a.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlv0DbQACgkQ2cTSbQ5g RJEs7Af+K00VWk3I/Eqo+HfIwVenGBE18xo26yCNjB7anxBi0ic4b/06ilME7lcT WANVlBcWg/ea7g8k8dEFNdnKlcdcQWRo51mfVelyC1L3OrVNfNzP1BrKTutaRq9S Hv8WvGGWaNlAdtLmy9rqmZVxuUMKYf0bC+9B8QqZ4hP1FjZry/wLSgU87+dqFY5Z dWBlctsvvc/7dl0ZrovtieEXCuH6+MK4i++jWjS6d5/ON1581wkmEzIkH5tRebQO jPaSj8rJB7H1bAZiZPd7c3Db5n4TG8NNoT+Kujk0LFTP+FjwEh6/WF8jybLDgGMg Y6mJnkcXimLoCLpuNZmBh1V4BAntTQ== =7K60 -----END PGP SIGNATURE----- From openssl-users at dukhovni.org Tue Nov 20 13:56:58 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 20 Nov 2018 08:56:58 -0500 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> <5EE3448B-A095-4CE8-B845-8D258F0EB9F7@dukhovni.org> Message-ID: <97E1765C-68B9-4FCF-BDA3-5B9C1CC81380@dukhovni.org> > On Nov 20, 2018, at 1:31 AM, Ken wrote: > > Are you saying to test with "openssl s_client -connect ..."? Test both with s_client and with your application if possible. In both cases configure the CApath empty and the CAfile to hold just the appropriate trust anchor. If your application does not provide a way to specify the CAfile and CApath, OpenSSL defaults can be overridden via environment variables: SSL_CERT_DIR SSL_CERT_FILE > I don't think I know how to interpret all of the output from that, > but it looked to me like it was saying everything was okay when I > tried it earlier (with no changes). Try "s_client -quiet". For example, a failure: $ openssl s_client -quiet -starttls smtp -connect localhost:25 depth=0 CN = [...] verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = [...] verify error:num=21:unable to verify the first certificate verify return:1 and a success: $ openssl s_client -quiet -starttls smtp -connect localhost:25 -CAfile rsacert.pem -partial_chain depth=0 CN = [...] verify return:1 > I just tried it again with -CApath pointing to an empty directory, and -CAfile > pointing to a new copy of the root CA certificate, which I just downloaded from > the provider - I do not see any difference in the output. You really do need to be much more precise. Is it failing? Succeeding? What version of OpenSSL is this particular s_client associated with? At this point likely post the peer certificate chain (as reported by: sleep 2 | openssl s_client -showcerts -connect someaddr:someport 2>/dev/null | openssl crl2pkcs7 -nocert -certfile /dev/stdin | openssl pkcs7 -print_certs > Then, I tried again, pointing to an incorrect CA - then I see some errors: > "verify error:num=20:unable to get local issuer certificate" Which suggests that it worked the first time. > So, it seems to me like, without any changes, s_client -connect says > the certificate is fine, but the application using x509_verify_certificate > thinks something is wrong.... Well, which trust store is the application using? And what is this x509_verify_certificate() you speak of? I only know about X509_verify_cert(3). Which requires an appopriately initialized X509_STORE_CTX, with suitable trust store settings. -- Viktor. From mcr at sandelman.ca Tue Nov 20 15:27:53 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 20 Nov 2018 10:27:53 -0500 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: Message-ID: <18896.1542727673@localhost> priya p wrote: > In openssl-1.1.1, few structures have been made opaque like HMAC_CTX, > EVP_CIPHER_CTX etc., > There are new API to get and set those structure members. But to > zeroize those structure members in place, I dont see any API. "in place", do you mean because you've allocated them as auto variables on the stack? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From matt at openssl.org Tue Nov 20 15:29:22 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 20 Nov 2018 15:29:22 +0000 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: <18896.1542727673@localhost> References: <18896.1542727673@localhost> Message-ID: <33c3f91a-81b5-c739-08dc-01b08dbe03a1@openssl.org> On 20/11/2018 15:27, Michael Richardson wrote: > priya p wrote: > > In openssl-1.1.1, few structures have been made opaque like HMAC_CTX, > > EVP_CIPHER_CTX etc., > > > There are new API to get and set those structure members. But to > > zeroize those structure members in place, I dont see any API. > > "in place", do you mean because you've allocated them as auto variables > on the stack? It is not possible to allocate opaque structures on the stack. The compiler will complain. Matt From maoly527 at 163.com Tue Nov 20 14:48:05 2018 From: maoly527 at 163.com (maoly527) Date: Tue, 20 Nov 2018 22:48:05 +0800 Subject: [openssl-users] How to use RSA certificate and ECC certificate simutaneously In-Reply-To: <18972e11.8657.1672fadf8a6.Coremail.maoly527@163.com> References: <18972e11.8657.1672fadf8a6.Coremail.maoly527@163.com> Message-ID: Hi, Dose anyone know how to use RSA and ECC certificate simultaneously in one server? The idea is to install both RSA and ECC certificates, to use which certificate, I think it depends on the cipher requested by client. And I know the cipher list is included in client hello message, but that's a part of handshake which happens in SSL_accept(). Then how I know the cipher request from client? It would be very appreciated if anyone can help me. Thanks, Jane Mao? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Nov 20 15:44:59 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 20 Nov 2018 10:44:59 -0500 Subject: [openssl-users] How to use RSA certificate and ECC certificate simutaneously In-Reply-To: References: <18972e11.8657.1672fadf8a6.Coremail.maoly527@163.com> Message-ID: <2B1A47DD-ED0D-41A9-B38D-5FD5E1E61881@dukhovni.org> > On Nov 20, 2018, at 9:48 AM, maoly527 wrote: > > Does anyone know how to use RSA and ECC certificate simultaneously in one server? You just configure two private keys and two certificate chains by calling: if (SSL_CTX_use_certificate_chain_file(ctx, cert_file) <= 0) { /* error */; } if (SSL_CTX_use_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM) <= 0) { /* error */; } if (SSL_CTX_check_private_key(ctx) != 0) { /* error */; } once for each "cert_file" and associated "key_file" (the same file often holds both, in which case cert_file == key_file). The SSL error stack will contain error details. The SSL library will automatically select the appropriate key and certificate chain. -- Viktor. From priyahere223 at gmail.com Tue Nov 20 17:38:29 2018 From: priyahere223 at gmail.com (priya p) Date: Tue, 20 Nov 2018 23:08:29 +0530 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: <33c3f91a-81b5-c739-08dc-01b08dbe03a1@openssl.org> References: <18896.1542727673@localhost> <33c3f91a-81b5-c739-08dc-01b08dbe03a1@openssl.org> Message-ID: Thanks Matt and Michael. On Tue, 20 Nov 2018 at 20:59, Matt Caswell wrote: > > > On 20/11/2018 15:27, Michael Richardson wrote: > > priya p wrote: > > > In openssl-1.1.1, few structures have been made opaque like > HMAC_CTX, > > > EVP_CIPHER_CTX etc., > > > > > There are new API to get and set those structure members. But to > > > zeroize those structure members in place, I dont see any API. > > > > "in place", do you mean because you've allocated them as auto variables > > on the stack? > > It is not possible to allocate opaque structures on the stack. The > compiler will > complain. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From priyahere223 at gmail.com Tue Nov 20 18:04:34 2018 From: priyahere223 at gmail.com (priya p) Date: Tue, 20 Nov 2018 23:34:34 +0530 Subject: [openssl-users] lopenssl lhash API Message-ID: Hi, I don't see these openssl lhash API implemented in latest openssl-1.1.1 version. The name has changed in the latest. IMPLEMENT_LHASH_DOALL_FN, LHASH_DOALL_FN, lh_OPENSSL_CSTRING_new, lh_OPENSSL_CSTRING_retrieve. Can anyone help me with the corresponding API names in openssl-1.1.1 ? Thanks, Priya -------------- next part -------------- An HTML attachment was scrubbed... URL: From priyahere223 at gmail.com Wed Nov 21 07:03:54 2018 From: priyahere223 at gmail.com (priya p) Date: Wed, 21 Nov 2018 12:33:54 +0530 Subject: [openssl-users] lopenssl lhash API In-Reply-To: References: Message-ID: Hi, Any help? Thanks, Priya On Tue, Nov 20, 2018, 11:34 PM priya p Hi, > > I don't see these openssl lhash API implemented in latest openssl-1.1.1 > version. > The name has changed in the latest. > > > IMPLEMENT_LHASH_DOALL_FN, LHASH_DOALL_FN, lh_OPENSSL_CSTRING_new, lh_OPENSSL_CSTRING_retrieve. > > Can anyone help me with the corresponding API names in openssl-1.1.1 ? > > Thanks, > Priya > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maoly527 at 163.com Wed Nov 21 08:11:40 2018 From: maoly527 at 163.com (=?GBK?B?w6s=?=) Date: Wed, 21 Nov 2018 16:11:40 +0800 (CST) Subject: [openssl-users] How to use RSA certificate and ECC certificate simutaneously In-Reply-To: <2B1A47DD-ED0D-41A9-B38D-5FD5E1E61881@dukhovni.org> References: <18972e11.8657.1672fadf8a6.Coremail.maoly527@163.com> <2B1A47DD-ED0D-41A9-B38D-5FD5E1E61881@dukhovni.org> Message-ID: <254e2372.cde2.167355324bd.Coremail.maoly527@163.com> Hi Viktor, Many thanks for your response. We are using SSL_CTX_use_certificate() instead of SSL_CTX_use_certificate_chain_file(). Does it also support multiple certificate chains? And as I know, OpenSSL 1.0.2 and later have a separate chain store for each type of certificate (RSA, ECC or DSA), Is there any bad impact to call it multiple times for same type of certificate? Best Regards, Jane At 2018-11-20 23:44:59, "Viktor Dukhovni" wrote: >> On Nov 20, 2018, at 9:48 AM, maoly527 wrote: >> >> Does anyone know how to use RSA and ECC certificate simultaneously in one server? > >You just configure two private keys and two certificate chains by calling: > > if (SSL_CTX_use_certificate_chain_file(ctx, cert_file) <= 0) { > /* error */; > } > if (SSL_CTX_use_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM) <= 0) { > /* error */; > } > if (SSL_CTX_check_private_key(ctx) != 0) { > /* error */; > } > >once for each "cert_file" and associated "key_file" (the same file often >holds both, in which case cert_file == key_file). The SSL error stack >will contain error details. > >The SSL library will automatically select the appropriate key and certificate >chain. > >-- > Viktor. > >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Nov 21 17:24:06 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 21 Nov 2018 12:24:06 -0500 Subject: [openssl-users] How to use RSA certificate and ECC certificate simutaneously In-Reply-To: <254e2372.cde2.167355324bd.Coremail.maoly527@163.com> References: <18972e11.8657.1672fadf8a6.Coremail.maoly527@163.com> <2B1A47DD-ED0D-41A9-B38D-5FD5E1E61881@dukhovni.org> <254e2372.cde2.167355324bd.Coremail.maoly527@163.com> Message-ID: <630BC551-F1C9-46FE-BA29-7E3B4C6B90BF@dukhovni.org> > On Nov 21, 2018, at 3:11 AM, ? wrote: > > We are using SSL_CTX_use_certificate() instead of > SSL_CTX_use_certificate_chain_file(). Do you then add chain certificates one by one? > Does it also support multiple certificate chains? I believe it will work correctly in 1.1.x, and perhaps in 1.0.2, but it has been a while since I've looked at the details. Check the documentation and if necessary the source code. If the documentation fails to describe this adequately, please open an issue on Github. > And as I know, OpenSSL 1.0.2 and later have a separate chain store for > each type of certificate (RSA, ECC or DSA), Is there any bad impact to > call it multiple times for same type of certificate? No, but only the last key/cert loaded for a given algorithm will be used, any previous setting will be replaced. Make sure always load both to avoid having a certificate that does not match the private key. -- -- Viktor. From jb-openssl at wisemo.com Wed Nov 21 17:28:06 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 21 Nov 2018 18:28:06 +0100 Subject: [openssl-users] AESCBC support in SSL In-Reply-To: References: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> Message-ID: I think you missed the following: Because CBC is the oldest block cipher mode in SSL and TLS, the cipher suites using CBC don't include the letters "CBC" in their names.They simply don't mention a different mode (such as GCM or CCM). For example ECDHE-RSA-AES128-SHA uses AES128 in CBC mode. On 20/11/2018 10:54, ASHIQUE CK wrote: > Hi, > Any replys ? > > On Mon, Nov 19, 2018 at 11:39 AM ASHIQUE CK > wrote: > > Also I use?OpenSSL 1.1.0h. > > On Mon, Nov 19, 2018 at 11:36 AM ASHIQUE CK > > wrote: > > No, We use Ubuntu 16.04 OS > > On Mon, Nov 19, 2018 at 11:34 AM Dmitry Belyavsky > > wrote: > > Do you use any RedHat-based OS? > > On Mon, Nov 19, 2018 at 8:54 AM ASHIQUE CK > > > wrote: > > Is it the problem with that strings or? TLS/SSL > version or any other ? > > On Mon, Nov 19, 2018 at 11:12 AM ASHIQUE CK > > wrote: > > Hi, > I had given all the cipher strings > for??"SSL_CTX_set_cipher_list" which we get under > the command 'openssl ciphers' that includes CBC, > but any of them didnot worked. All of them showed > the error "error:141640B5:SSL > routines:tls_construct_client_hello:no ciphers > available". I have used TLSv1_2 or SSLv23. > Also I have tried setting??these strings for > "SSLCipherSuite" at apache server configuration. > But it makes no change for choosing the server > default ciphersuit "ECDHE-RSA-AES256-GCM-SHA384". > > Thanks > > On Fri, Nov 16, 2018 at 9:15 PM Viktor Dukhovni > > wrote: > > > > > On Nov 16, 2018, at 7:45 AM, ASHIQUE CK > > wrote: > > > > Does SSL connection supports AESCBC? > > Yes, but not under that name. > > >? I could not set AESCBC in > "SSL_CTX_set_cipher_list" at client side or in > "SSLCipherSuite" at apache server side. > > For example (constrained also to RSA and ECDHE > to keep the list short): > > ? $ openssl ciphers -v > 'AES128+aRSA+kECDHE:!AESGCM' > ? ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH > Au=RSA Enc=AES(128) Mac=SHA256 > ? ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA > Enc=AES(128) Mac=SHA1 > > There isn't a cipherlist property that > specifically selects CBC, so to > get *only* CBC, you need to exclude AESGCM > (and perhaps also AESCCM). > 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 From filipe.mfgfernandes at gmail.com Wed Nov 21 17:45:19 2018 From: filipe.mfgfernandes at gmail.com (Filipe Fernandes) Date: Wed, 21 Nov 2018 17:45:19 +0000 Subject: [openssl-users] OpenSSL - Session Resumption on an On-going Connection In-Reply-To: <20181119210231.GJ4122@straasha.imrryr.org> References: <20181119210231.GJ4122@straasha.imrryr.org> Message-ID: Hi Viktor, I've followed your example, and it looks like the server is doing what it's supposed to, however, I'm getting a disconnect from the server when the session expires. Which should not happen, and I can't seem to find a reason for this to be happening. As previously said, I'm developing a server that handles always-on TLS connections, and I'm trying to perform a session resumption. Thanks! On Mon, 19 Nov 2018 at 21:02, Viktor Dukhovni wrote: > On Mon, Nov 19, 2018 at 04:01:35PM +0000, Filipe Fernandes wrote: > > > I'm developing a specific SSL Server, in which it's supposed to have an > > always-on socket connection. So, to be on the safe side, there's specific > > needs that need to be filled on this implementation. One of the needs is > > that the server must send a resumption request (ServerHello) to the > client > > on a cyclic manner. I've tried everything I could, but it seems that the > > server does not send the ServerHello to the Client. > > This is only possible with TLS <= 1.2, TLS 1.3 eliminated renegotiation. > > > My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to > the > > Client *on demand*? The socket should not close, nor perform a > > renegotiation. > > The relevant code in apps/s_server.c is: > > SSL_renegotiate(con); > i = SSL_do_handshake(con); > > this implements the handling of the 'r' magic character, see s_server(1): > > CONNECTED COMMANDS > > If a connection request is established with an SSL client and > neither > the -www nor the -WWW option has been used then normally any data > received from the client is displayed and any key presses will be > sent > to the client. > > Certain commands are also recognized which perform special > operations. > These commands are a letter which must appear at the start of a > line. > They are listed below. > > [...] > > r Renegotiate the SSL session (TLSv1.2 and below only). > > R Renegotiate the SSL session and request a client certificate > (TLSv1.2 and below only). > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipe.mfgfernandes at gmail.com Wed Nov 21 18:46:51 2018 From: filipe.mfgfernandes at gmail.com (Filipe Fernandes) Date: Wed, 21 Nov 2018 18:46:51 +0000 Subject: [openssl-users] OpenSSL - Session Resumption on an On-going Connection In-Reply-To: References: <20181119210231.GJ4122@straasha.imrryr.org> Message-ID: I've misjudged. The socket is closed even if the session has not ended (I've set the session timeout to 10 times the resumption cycle). You can check the tcpdump here: https://imgfly.me/i/66LJY I'm doing exactly what is on the s_server example, without avail. if (SSL_renegotiate(GetSSL()) <= 0) { CSyException Ex("SocketSSL", "SSL_renegotiate() failed. Stopping communication."); Ex.PrintError(); SetShouldClose(TRUE); GetSSLConfig()->uiLastTLSRenegotiation = time1sVal; return FALSE; } if (SSL_do_handshake(GetSSL()) <= 0) { CSyException Ex("SocketSSL", "SSL_do_handshake() has failed. Stopping communication."); Ex.PrintError(); SetShouldClose(TRUE); GetSSLConfig()->uiLastTLSRenegotiation = time1sVal; return FALSE; } Thanks! On Wed, 21 Nov 2018 at 17:45, Filipe Fernandes < filipe.mfgfernandes at gmail.com> wrote: > Hi Viktor, > > I've followed your example, and it looks like the server is doing what > it's supposed to, however, I'm getting a disconnect from the server when > the session expires. Which should not happen, and I can't seem to find a > reason for this to be happening. > > As previously said, I'm developing a server that handles always-on TLS > connections, and I'm trying to perform a session resumption. > > > Thanks! > > > > On Mon, 19 Nov 2018 at 21:02, Viktor Dukhovni > wrote: > >> On Mon, Nov 19, 2018 at 04:01:35PM +0000, Filipe Fernandes wrote: >> >> > I'm developing a specific SSL Server, in which it's supposed to have an >> > always-on socket connection. So, to be on the safe side, there's >> specific >> > needs that need to be filled on this implementation. One of the needs is >> > that the server must send a resumption request (ServerHello) to the >> client >> > on a cyclic manner. I've tried everything I could, but it seems that the >> > server does not send the ServerHello to the Client. >> >> This is only possible with TLS <= 1.2, TLS 1.3 eliminated renegotiation. >> >> > My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to >> the >> > Client *on demand*? The socket should not close, nor perform a >> > renegotiation. >> >> The relevant code in apps/s_server.c is: >> >> SSL_renegotiate(con); >> i = SSL_do_handshake(con); >> >> this implements the handling of the 'r' magic character, see s_server(1): >> >> CONNECTED COMMANDS >> >> If a connection request is established with an SSL client and >> neither >> the -www nor the -WWW option has been used then normally any data >> received from the client is displayed and any key presses will be >> sent >> to the client. >> >> Certain commands are also recognized which perform special >> operations. >> These commands are a letter which must appear at the start of a >> line. >> They are listed below. >> >> [...] >> >> r Renegotiate the SSL session (TLSv1.2 and below only). >> >> R Renegotiate the SSL session and request a client certificate >> (TLSv1.2 and below only). >> >> -- >> Viktor. >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From OpenSSL at k-h.us Wed Nov 21 19:36:46 2018 From: OpenSSL at k-h.us (Ken) Date: Wed, 21 Nov 2018 11:36:46 -0800 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <97E1765C-68B9-4FCF-BDA3-5B9C1CC81380@dukhovni.org> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> <5EE3448B-A095-4CE8-B845-8D258F0EB9F7@dukhovni.org> <97E1765C-68B9-4FCF-BDA3-5B9C1CC81380@dukhovni.org> Message-ID: <7ac3c94d-4d8a-d36e-d1af-d4b110b51aec@k-h.us> Hi Viktor, I tested using s_client, on both systems, with no options, with CAfile pointing to the correct CA, and with CAfile pointing to the WRONG CA file - the only time it failed was on the new version, with the wrong file. (Results attached.) I guess the new version is better at checking things. You are right, x509_verify_certificate() is a function in the program, that then makes calls to openssl. (But I did not dig back into that today....) I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE, to the empty directory and the CA file - did not help. Then, I tested setting SSL_CERT_DIR to /var/lib/ca-certificates/openssl (which seems to be the default, and did not change anything), and then setting SSL_CERT_DIR to /var/lib/ca-certificates/pem/ - this made FreeRDP happy with the certificate. This implies that there is something wrong with the CA in the openssl directory, but the one in the pem directory is okay? I compared Starfield_Root_Certificate_Authority_-_G2.pem in the openssl directory on the two systems - they are a binary match. Then I compared the output of openssl x509 -in /var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text and openssl x509 -in /var/lib/ca-certificates/pem/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text The only difference is that the one from openssl ends with: " Trusted Uses: ? TLS Web Server Authentication No Rejected Uses. Alias: Starfield Root Certificate Authority - G2 " whereas the one from pem has nothing there. (I am also attaching the two certificates.) Since I am trying to make a RDP connection, does this mean that the openssl version of the CA is not valid, because it says "Web Server Authentication". And, the new version makes more extensive checks that the old version? I now have a work-around to make this application work, but I would like to know what really is going on - what changed to cause this. ------?Original?Message?------ From:?Viktor Dukhovni Sent:?Tue, 20 Nov 2018 08:56:58 -0500 To:?Openssl-users Subject:?Re: [openssl-users] Problem with x509_verify_certificate >> On Nov 20, 2018, at 1:31 AM, Ken wrote: >> >> Are you saying to test with "openssl s_client -connect ..."? > Test both with s_client and with your application if possible. > In both cases configure the CApath empty and the CAfile to hold > just the appropriate trust anchor. If your application does not > provide a way to specify the CAfile and CApath, OpenSSL defaults > can be overridden via environment variables: > > SSL_CERT_DIR > SSL_CERT_FILE > >> I don't think I know how to interpret all of the output from that, >> but it looked to me like it was saying everything was okay when I >> tried it earlier (with no changes). > Try "s_client -quiet". For example, a failure: > > $ openssl s_client -quiet -starttls smtp -connect localhost:25 > depth=0 CN = [...] > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 CN = [...] > verify error:num=21:unable to verify the first certificate > verify return:1 > > and a success: > > $ openssl s_client -quiet -starttls smtp -connect localhost:25 -CAfile rsacert.pem -partial_chain > depth=0 CN = [...] > verify return:1 > >> I just tried it again with -CApath pointing to an empty directory, and -CAfile >> pointing to a new copy of the root CA certificate, which I just downloaded from >> the provider - I do not see any difference in the output. > You really do need to be much more precise. Is it failing? Succeeding? > What version of OpenSSL is this particular s_client associated with? > At this point likely post the peer certificate chain (as reported by: > > sleep 2 | openssl s_client -showcerts -connect someaddr:someport 2>/dev/null > | openssl crl2pkcs7 -nocert -certfile /dev/stdin > | openssl pkcs7 -print_certs > >> Then, I tried again, pointing to an incorrect CA - then I see some errors: >> "verify error:num=20:unable to get local issuer certificate" > Which suggests that it worked the first time. > >> So, it seems to me like, without any changes, s_client -connect says >> the certificate is fine, but the application using x509_verify_certificate >> thinks something is wrong.... > Well, which trust store is the application using? And what is this > x509_verify_certificate() you speak of? I only know about > X509_verify_cert(3). Which requires an appopriately initialized > X509_STORE_CTX, with suitable trust store settings. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- openSUSE Leap 42.3 / OpenSSL 1.0.2j-fips 26 Sep 2016 # s_client with "no" options: $ openssl s_client -quiet -connect owa.xxxxx.com:3389 depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 verify return:1 depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 verify return:1 depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com verify return:1 # s_client, specifying correct CA: $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile sfroot-g2.crt depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 verify return:1 depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 verify return:1 depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com verify return:1 # s_client, specifying *WRONG* CA: $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 verify return:1 depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 verify return:1 depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com verify return:1 openSUSE Leap 15.0 / OpenSSL 1.1.0i-fips 14 Aug 2018 # s_client with "no" options: $ openssl s_client -quiet -connect owa.xxxxx.com:3389 depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 verify return:1 depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 verify return:1 depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com verify return:1 # s_client, specifying correct CA: $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile sfroot-g2.crt depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 verify return:1 depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 verify return:1 depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com verify return:1 # s_client, specifying *WRONG* CA: $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 verify error:num=20:unable to get local issuer certificate -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-Starfield_Root_Certificate_Authority_-_G2.pem Type: application/x-pem-file Size: 1492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pem-Starfield_Root_Certificate_Authority_-_G2.pem Type: application/x-pem-file Size: 1399 bytes Desc: not available URL: From vieuxtech at gmail.com Wed Nov 21 21:51:02 2018 From: vieuxtech at gmail.com (Sam Roberts) Date: Wed, 21 Nov 2018 13:51:02 -0800 Subject: [openssl-users] Is there any standard way of getting the error name from an SSL error? Message-ID: For example, I want the string "SSL_R_TOO_MANY_WARN_ALERTS" for an error with that value, not just the "too many alerts" description. I'm suspecting not, I don't see any use of #reason in ERR_REASON() or the macros it uses. From rsalz at akamai.com Wed Nov 21 22:20:58 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 21 Nov 2018 22:20:58 +0000 Subject: [openssl-users] Is there any standard way of getting the error name from an SSL error? In-Reply-To: References: Message-ID: <77202E2C-1526-4376-997D-3B72AA013B7B@akamai.com> > For example, I want the string "SSL_R_TOO_MANY_WARN_ALERTS" for an error with that value, not just the "too many alerts" description. You're correct, it's not done. From openssl-users at dukhovni.org Wed Nov 21 23:04:07 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 21 Nov 2018 18:04:07 -0500 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <7ac3c94d-4d8a-d36e-d1af-d4b110b51aec@k-h.us> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> <5EE3448B-A095-4CE8-B845-8D258F0EB9F7@dukhovni.org> <97E1765C-68B9-4FCF-BDA3-5B9C1CC81380@dukhovni.org> <7ac3c94d-4d8a-d36e-d1af-d4b110b51aec@k-h.us> Message-ID: <20181121230406.GR4122@straasha.imrryr.org> On Wed, Nov 21, 2018 at 11:36:46AM -0800, Ken wrote: > I tested using s_client, on both systems, with no options, with CAfile > pointing to the correct CA, and with CAfile pointing to the WRONG CA > file - the only time it failed was on the new version, with the wrong > file. (Results attached.) I guess the new version is better at checking > things. Perhaps you did not override CApath? And the default CApath succeeds with old, but not the new code? For meaningful tests you need to explicitly override both, and place just specific CA certs in CAfile, leaving CApath empty. > I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE, to the > empty directory and the CA file - did not help. I don't believe I suggested setting SSL_CERT_FILE to an empty directory, or an empty file. Though putting a freshly minted self-signed root that has never signed any certificates into CAfile, can be one test to check that your application fails when it should definitely fail. > Then, I tested setting SSL_CERT_DIR to /var/lib/ca-certificates/openssl > (which seems to be the default, and did not change anything), and then > setting SSL_CERT_DIR to /var/lib/ca-certificates/pem/ - this made > FreeRDP happy with the certificate. > > I compared > Starfield_Root_Certificate_Authority_-_G2.pem in the openssl directory > on the two systems - they are a binary match. But they're not the same, only the encapsulated X.509 certificates are the same, but one is wrapped as a "trusted certificate" with a specific trust EKU. > Then I compared the output of > > openssl x509 -in /var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text > and > openssl x509 -in /var/lib/ca-certificates/pem/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text That is, they are NOT the same. > The only difference is that the one from openssl ends with: > > Trusted Uses: > TLS Web Server Authentication > No Rejected Uses. > Alias: Starfield Root Certificate Authority - G2 Well, that's "auxiliary" trust data outside the certificate. It is part of a "TRUSTED CERTICATE" encapsulation of a CA certificate, and can be used to limit the "purpose" for which a certificate is valid. If your application does not specify "serverAuth" as the "purpose" being verified, then verification should fail. > Since I am trying to make a RDP connection, does this mean that the > openssl version of the CA is not valid, because it says "Web Server > Authentication". And, the new version makes more extensive checks that > the old version? It is valid, but has a restricted purpose. Your application needs to specify that purpose, but FreeRDP may not specify its peer as a "TLS Web Server" (really TLS server) when doing certificate verification. > I now have a work-around to make this application work, but I would like > to know what really is going on - what changed to cause this. The chain "extended Key Usage" is checked more consistently in OpenSSL 1.1.x. > OpenSSL 1.0.2j-fips 26 Sep 2016 Note that in OpenSSL 1.0.2, the "s_client" command *always* loads the *default* CAfile and default CApath, in *addition* to any CAfile and CApath you might specify. You need to point SSL_CERT_DIR to an empty directory and SSL_CERT_FILE at the desired CAfile to make sure that only the trusted certificates you want to test are used. > > # s_client with "no" options: > $ openssl s_client -quiet -connect owa.xxxxx.com:3389 > depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 > verify return:1 > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 > verify return:1 > depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com > verify return:1 This succeeds. > > # s_client, specifying correct CA: > $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile sfroot-g2.crt > depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 > verify return:1 > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 > verify return:1 > depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com > verify return:1 This likewise. > # s_client, specifying *WRONG* CA: > $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt > depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 > verify return:1 > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 > verify return:1 > depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com > verify return:1 Probably still finds the right CA in the default CApath or CAfile. > OpenSSL 1.1.0i-fips 14 Aug 2018 Note that to reduce WTF surprises, OpenSSL 1.1.x only loads the *default* CAfile and CApath when you don't specify either on the command-line, and you don't disable these with "-no-CAfile" or "-no-CApath". So the in tests below, you're not getting more than what you ask for: > # s_client with "no" options: > $ openssl s_client -quiet -connect owa.xxxxx.com:3389 > depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 > verify return:1 > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 > verify return:1 > depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com > verify return:1 This succeeds. > # s_client, specifying correct CA: > $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile sfroot-g2.crt > depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 > verify return:1 > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 > verify return:1 > depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com > verify return:1 This also succeeds. > # s_client, specifying *WRONG* CA: > $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt > openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2 > verify error:num=20:unable to get local issuer certificate Fails as expected. -- Viktor. From openssl-users at dukhovni.org Wed Nov 21 23:12:27 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 21 Nov 2018 18:12:27 -0500 Subject: [openssl-users] OpenSSL - Session Resumption on an On-going Connection In-Reply-To: References: <20181119210231.GJ4122@straasha.imrryr.org> Message-ID: <20181121231227.GS4122@straasha.imrryr.org> On Wed, Nov 21, 2018 at 05:45:19PM +0000, Filipe Fernandes wrote: > I've followed your example, and it looks like the server is doing what it's > supposed to, however, I'm getting a disconnect from the server when the > session expires. Which should not happen, and I can't seem to find a reason > for this to be happening. > > As previously said, I'm developing a server that handles always-on TLS > connections, and I'm trying to perform a session resumption. I thought you wanted renegotiation, not resumption, servers can't do "resumption", because resumption is what you do to avoid a full handshake on a *new* connection, and only the client can reconnect. You seem to be confused, and have not explained your requirements clearly. What is your *goal*? What does "always on" mean to you? Only clients can resume previous sessions, when reconnecting to a server. Is that what you're trying to do? (Implement a server with a session cache for client resumption? Support session tickets? Is there just one server or a server "farm"? Do the clients support resumption?) Or are you trying to periodically rekey a long-running connection? Or something else? -- Viktor. From ckashiquekvk at gmail.com Thu Nov 22 05:46:13 2018 From: ckashiquekvk at gmail.com (ASHIQUE CK) Date: Thu, 22 Nov 2018 11:16:13 +0530 Subject: [openssl-users] AESCBC support in SSL In-Reply-To: References: <505DA81D-D6BC-4B13-AB82-38296B4D75D3@dukhovni.org> Message-ID: Thanks Jakob. Thanks a lot. On Wed, Nov 21, 2018 at 10:58 PM Jakob Bohm via openssl-users < openssl-users at openssl.org> wrote: > I think you missed the following: > > Because CBC is the oldest block cipher mode in SSL and > TLS, the cipher suites using CBC don't include the > letters "CBC" in their names.They simply don't mention > a different mode (such as GCM or CCM). > > For example ECDHE-RSA-AES128-SHA uses AES128 in CBC mode. > > On 20/11/2018 10:54, ASHIQUE CK wrote: > > Hi, > > Any replys ? > > > > On Mon, Nov 19, 2018 at 11:39 AM ASHIQUE CK > > wrote: > > > > Also I use OpenSSL 1.1.0h. > > > > On Mon, Nov 19, 2018 at 11:36 AM ASHIQUE CK > > > wrote: > > > > No, We use Ubuntu 16.04 OS > > > > On Mon, Nov 19, 2018 at 11:34 AM Dmitry Belyavsky > > > wrote: > > > > Do you use any RedHat-based OS? > > > > On Mon, Nov 19, 2018 at 8:54 AM ASHIQUE CK > > > > > wrote: > > > > Is it the problem with that strings or TLS/SSL > > version or any other ? > > > > On Mon, Nov 19, 2018 at 11:12 AM ASHIQUE CK > > > > wrote: > > > > Hi, > > I had given all the cipher strings > > for "SSL_CTX_set_cipher_list" which we get under > > the command 'openssl ciphers' that includes CBC, > > but any of them didnot worked. All of them showed > > the error "error:141640B5:SSL > > routines:tls_construct_client_hello:no ciphers > > available". I have used TLSv1_2 or SSLv23. > > Also I have tried setting these strings for > > "SSLCipherSuite" at apache server configuration. > > But it makes no change for choosing the server > > default ciphersuit "ECDHE-RSA-AES256-GCM-SHA384". > > > > Thanks > > > > On Fri, Nov 16, 2018 at 9:15 PM Viktor Dukhovni > > > > wrote: > > > > > > > > > On Nov 16, 2018, at 7:45 AM, ASHIQUE CK > > > > wrote: > > > > > > Does SSL connection supports AESCBC? > > > > Yes, but not under that name. > > > > > I could not set AESCBC in > > "SSL_CTX_set_cipher_list" at client side or in > > "SSLCipherSuite" at apache server side. > > > > For example (constrained also to RSA and ECDHE > > to keep the list short): > > > > $ openssl ciphers -v > > 'AES128+aRSA+kECDHE:!AESGCM' > > ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH > > Au=RSA Enc=AES(128) Mac=SHA256 > > ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA > > Enc=AES(128) Mac=SHA1 > > > > There isn't a cipherlist property that > > specifically selects CBC, so to > > get *only* CBC, you need to exclude AESGCM > > (and perhaps also AESCCM). > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipe.mfgfernandes at gmail.com Thu Nov 22 11:15:46 2018 From: filipe.mfgfernandes at gmail.com (Filipe Fernandes) Date: Thu, 22 Nov 2018 11:15:46 +0000 Subject: [openssl-users] OpenSSL - Session Resumption on an On-going Connection In-Reply-To: <20181121231227.GS4122@straasha.imrryr.org> References: <20181119210231.GJ4122@straasha.imrryr.org> <20181121231227.GS4122@straasha.imrryr.org> Message-ID: > I thought you wanted renegotiation, not resumption, servers can't > do "resumption", because resumption is what you do to avoid a full > handshake on a *new* connection, and only the client can reconnect. Ok. Agreed. > You seem to be confused, and have not explained your requirements > clearly. What is your *goal*? My goal is to have the Openssl to "perform the TLS Resumption (initiated by the Hello Request message from the server or the Client Hello message from the client), in an ongoing TLS Session." (it's specifically stated on the spec, like this). > What does "always on" mean to you? Always on, means that the socket connection is up for as long as it is possible, meaning that the socket is not closed and it keeps exchanging information all the time (server<->client) > Only clients can resume previous > sessions, when reconnecting to a server. Is that what you're trying > to do? (Implement a server with a session cache for client resumption? I'm developing the server side with OpenSSL 1.0.2. And it supports cache (I've activated it on the method SSL_CTX_set_session_cache_mode). > Support session tickets? Is there just one server or a server "farm"? > Do the clients support resumption?) There's only 1 server, not a farm. How can I tell if the client supports resumption? > Or are you trying to periodically rekey a long-running connection? Maybe this is it. For me, Renegotiation is request "everything" (new pubkey, certificates, etc) Resumption, is just to refresh the keys? I'm a little confused here. > > Or something else? I think this is it :) On Wed, 21 Nov 2018 at 23:12, Viktor Dukhovni wrote: > On Wed, Nov 21, 2018 at 05:45:19PM +0000, Filipe Fernandes wrote: > > > I've followed your example, and it looks like the server is doing what > it's > > supposed to, however, I'm getting a disconnect from the server when the > > session expires. Which should not happen, and I can't seem to find a > reason > > for this to be happening. > > > > As previously said, I'm developing a server that handles always-on TLS > > connections, and I'm trying to perform a session resumption. > > I thought you wanted renegotiation, not resumption, servers can't > do "resumption", because resumption is what you do to avoid a full > handshake on a *new* connection, and only the client can reconnect. > > You seem to be confused, and have not explained your requirements > clearly. What is your *goal*? > > What does "always on" mean to you? Only clients can resume previous > sessions, when reconnecting to a server. Is that what you're trying > to do? (Implement a server with a session cache for client resumption? > Support session tickets? Is there just one server or a server "farm"? > Do the clients support resumption?) > > Or are you trying to periodically rekey a long-running connection? > > Or something else? > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Nov 22 11:56:23 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 22 Nov 2018 11:56:23 +0000 Subject: [openssl-users] OpenSSL - Session Resumption on an On-going Connection In-Reply-To: References: <20181119210231.GJ4122@straasha.imrryr.org> <20181121231227.GS4122@straasha.imrryr.org> Message-ID: <8f4c8617-7053-c24c-901d-e296d79fdc75@openssl.org> On 22/11/2018 11:15, Filipe Fernandes wrote: >>?? You seem to be confused, and have not explained your requirements >>?? clearly.? What is your *goal*? > > My goal is to have the Openssl to "perform the TLS Resumption (initiated by the > Hello Request message from the server or > the Client Hello message from the client), in an ongoing TLS Session." (it's > specifically stated on the spec, like this). I think you need to get this spec clarified. It makes no sense. It seems to be describing renegotiation, but uses the term resumption for it which has a different meaning. A handshake occurs between a client and a server at the start of a connection and establishes the cryptographic parameters to be used for that connection (including certificates/keys etc). Resumption refers to a type of handshake. Resumptions handshakes are abbreviated forms of a full handshake. They are based on the parameters established during a previous connection. So for example a certificate is not exchanged because the same cert is used from the previous connection. Renegotiation refers to the process of starting a new handshake over an existing TLS connection between a client and a server. Typically the objective is usually either to update the keys, or to request a client certificate. Like any other handshake it may be a full one or a resumption one. Only a client can ever initiate a handshake. A server can *request* a renegotiation by sending a HelloRequest message, but the client does not have to honour it. A server cannot request a resumption. > >>?? What does "always on" mean to you??? > > Always on, means that the socket connection is up for as long as it is possible, > meaning that the socket is not closed and it keeps exchanging information all > the time (server<->client) Resumption does not give you this. Renegotiation does. > >>? ?Only clients can resume previous >>?? sessions, when reconnecting to a server.? Is that what you're trying >>?? to do? (Implement a server with a session cache for client resumption? > > I'm developing the server side with OpenSSL 1.0.2. And it supports cache (I've > activated it on the method?SSL_CTX_set_session_cache_mode).??? > >>?? Support session tickets? Is there just one server or a server "farm"? >>?? Do the clients support resumption?) > > There's only 1 server, not a farm. > > How can I tell if the client supports resumption? > > >>?? Or are you trying to periodically rekey a long-running connection? > > Maybe this is it.? > > For me, Renegotiation is request "everything" (new pubkey, certificates, etc) A renegotiation is a new handshake over an existing connection. It may use a full handshake (certificates exchanged etc), or an abbreviated resumption handshake (e.g. doesn't exchange certificates again). Only the client gets to decide whether to attempt a resumption. > Resumption, is just to refresh the keys? I'm a little confused here. No. Resumption is an abbreviated handshake. It may be used at the start of a new connection or as part of a renegotiation handshake. In either case it is abbreviated because it is based on the parameters established during an earlier connection. Matt > >>??? >>?? Or something else??? > > I think this is it :) > > > On Wed, 21 Nov 2018 at 23:12, Viktor Dukhovni > wrote: > > On Wed, Nov 21, 2018 at 05:45:19PM +0000, Filipe Fernandes wrote: > > > I've followed your example, and it looks like the server is doing what it's > > supposed to, however, I'm getting a disconnect from the server when the > > session expires. Which should not happen, and I can't seem to find a reason > > for this to be happening. > > > > As previously said, I'm developing a server that handles always-on TLS > > connections, and I'm trying to perform a session resumption. > > I thought you wanted renegotiation, not resumption, servers can't > do "resumption", because resumption is what you do to avoid a full > handshake on a *new* connection, and only the client can reconnect. > > You seem to be confused, and have not explained your requirements > clearly.? What is your *goal*? > > What does "always on" mean to you?? Only clients can resume previous > sessions, when reconnecting to a server.? Is that what you're trying > to do? (Implement a server with a session cache for client resumption? > Support session tickets? Is there just one server or a server "farm"? > Do the clients support resumption?) > > Or are you trying to periodically rekey a long-running connection? > > Or something else? > > -- > ? ? ? ? Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > From andreas.pfluegl at etm.at Thu Nov 22 15:58:28 2018 From: andreas.pfluegl at etm.at (Pfluegl, Andreas) Date: Thu, 22 Nov 2018 15:58:28 +0000 Subject: [openssl-users] renegotiation expected to fail when trust configuration has changed. Message-ID: Hi, We have a C++ client application and a C++ server application using OpenSSL 1.1.0f to encrypt the TCP/IP communication. We enforce mutual authentication (also the server requests certificates from the clients and verifies if they are issued by a CA it trusts). We are able to update certificates (Host certificates and trusted CA certificates) on clients and servers without stopping the executables or interrupting the communication. We managed the update of the trusted CA certificates by using TLS Extension #3 (trusted_ca_keys) specified in RFC6066. We are able to remove old obsolete certificates (Host certificates and trusted CA certificates) on clients and servers without stopping the executables or interrupting the communication. New established TCP/IP sessions will always use the newest certificates. The update of a trusted CA certificate might look like this: * Server and clients are deployed with certificates issued by CA1, the CA1 certificate is deployed as trusted root certificate. * Certificates issued by CAnew and the CAnew certificate will be deployed to the server and all clients. Whenever a new TCP/IP session is established the new certificates are used. * Once all CAnew certificates are deployed, the CA1 certificates can be removed from the server and the clients. We also want to force established TCP sessions to move from obsolete certificates the newest certificates be triggering a renegotiation. We expect the renegotiation to fail, if the host does not have the right set of certificates. This works fine, if we trigger the renegotiation at the client, but the real benefit would be to do the renegotiation on the server. So we could remove all already connected malicious clients which have managed to steal obsolete certificates. But sadly this does not work the way we implemented it. we implemented the renegotiation by essentially calling SSL_renegotiate() and SSL_do_handshake() But see our trace for a better illustration what is going on. Note! We use SSL_CTX_set_info_callback() to get insights into OpenSSL states and set the following essential configurations: SSL_CTX_set_verify(m_ctx, SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT, &verify_callback); SSL_CTX_add_client_custom_ext(m_ctx, TLSEXT_TYPE_trusted_ca_keys, &client_add_cb, nullptr, nullptr, &client_parse_cb, nullptr); SSL_CTX_add_server_custom_ext(m_ctx, TLSEXT_TYPE_trusted_ca_keys, &server_add_cb, nullptr, nullptr, &server_parse_cb, nullptr); Scenario 1: Client triggered renegotiation (Note! works as expected) Client trace (Dist): Comment Trace snippet ___________HANDSHAKE_START_ fd=13 in state SSL negotiation finished successfully ___________CONNECT_LOOP__OK____ fd=13 in state SSL negotiation finished successfully OpenSSL called custom extension callback ++ client_add_cb Entered { Client_add_cb calls sendTrustedCAKeys() The list of trused CA's sent to the server. ++ sendTrustedCAKeys Entered { CA directory: /opt/IowaDev/Projects/WCCILProject/config/CertStore//trusted <== send peer a list of my trusted CAs. SHA1: A7:8F:B0:9A:96:A4:A0:4E:6F:B3:BF:4D:24:B3:85:0D:4A:64:9B:30 Subject : /C=AT/ST=OOE/O=ETM/OU=INNO/CN=CA1 file: af83623b.0 Out : A7:8F:B0:9A:96:A4:A0:4E:6F:B3:BF:4D:24:B3:85:0D:4A:64:9B:30 } ++ sendTrustedCAKeys returns : 1 elapsed time: 3685525ns } ++ client_add_cb returns : 1 elapsed time: 14254269ns ___________CONNECT_LOOP__OK____ fd=13 in state SSLv3/TLS write client hello ___________CONNECT_EXIT__ fd=13 in state SSLv3/TLS write client hello Server trace (Proxy): Comment Trace snippet ___________HANDSHAKE_START_ fd=316 in state before SSL initialization ___________ACCEPT__LOOP__OK____ fd=316 in state before SSL initialization ___________ACCEPT__LOOP__OK____ fd=316 in state before SSL initialization I expect server_parse_cb() returning 0 to cause the interruption of the connection. Can you confirm this? ++ CertFileTLSContextHandler::server_parse_cb Entered { == server_parse_cb: ext_type: 3 inlen: 61 in: A7:8F:B0:9A:96:A4:A0:4E:6F:B3:BF:4D:24:B3:85:0D:4A:64:9B:30 ++ CertificateStoreDirectory::findCertBy by SHA1 Entered { certificate: fde47a0f.1 ignored! does not match A7:8F:B0:9A:96:A4:A0:4E:6F:B3:BF:4D:24:B3:85:0D:4A:64:9B:30 } ++ CertificateStoreDirectory::findCertBy returns : elapsed time: 1302748ns } ++ CertFileTLSContextHandler::server_parse_cb returns : 0 elapsed time: 1351234ns ___________WRITE___ALERT_ fd=316 in state SSLv3/TLS read client hello err: fatal: decode error ___________ACCEPT__EXIT__ fd=316 in state error 11152:error:1417D0E3:SSL routines:tls_process_client_hello:parse tlsext:ssl\statem\statem_srvr.c:1209: Scenario 2: Server triggered renegotiation (Expected to interrupt connection as well.) Server trace (Proxy): Comment Trace snippet ++ TLSContextHandler::renegotiate Entered { Trusting CA certificate "/C=AT/ST=OOE/O=ETM/OU=INNO/CN=CA2" file fde47a0f.1 Use host certificate: "/C=AT/ST=OOE/L=LINZ/O=ETM/OU=INNO/CN=Sys2:Single" issued by : "/C=AT/ST=OOE/O=ETM/OU=INNO/CN=CA2" file : Single.1.cert.pem Use private key file: Single.1.key.pem ++ TLSContextHandler::doHandshake Entered { ___________HANDSHAKE_START_ fd=920 in state SSL negotiation finished successfully ___________ACCEPT__LOOP__OK____ fd=920 in state SSL negotiation finished successfully ___________ACCEPT__LOOP__OK____ fd=920 in state SSLv3/TLS write hello request Here I am missing server_parse_cb() (see Server trace scenario 1) ___________ACCEPT__EXIT__ fd=920 in state SSL negotiation finished successfully SSL_do_handshake(ssl) rc: 1, SSL error: [0] SSL_ERROR_NONE, OS error: [0] No error } ++ TLSContextHandler::doHandshake returns : 1 elapsed time: 310500ns } TLSContextHandler::renegotiate returns : 1 elapsed time: 3564000ns Client trace (Dist): Comment Trace snippet ___________HANDSHAKE_START_ fd=13 in state SSL negotiation finished successfully ___________CONNECT_LOOP__OK____ fd=13 in state SSL negotiation finished successfully client_add_cb ist called, but the server never gets the data! (see above) ++ client_add_cb Entered { ++ sendTrustedCAKeys Entered { <== send peer a list of my trusted CAs. SHA1: A7:8F:B0:9A:96:A4:A0:4E:6F:B3:BF:4D:24:B3:85:0D:4A:64:9B:30 Subject : /C=AT/ST=OOE/O=ETM/OU=INNO/CN=CA1 file: af83623b.0 Out : A7:8F:B0:9A:96:A4:A0:4E:6F:B3:BF:4D:24:B3:85:0D:4A:64:9B:30 } ++ sendTrustedCAKeys returns : 1 elapsed time: 3685525ns } ++ client_add_cb returns : 1 elapsed time: 14254269ns ___________CONNECT_LOOP__OK____ fd=13 in state SSLv3/TLS write client hello ___________CONNECT_EXIT__ fd=13 in state SSLv3/TLS write client hello Could you please advice how to solve this issue. With best regards, Andreas Pfl?gl -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Nov 22 17:45:16 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 22 Nov 2018 17:45:16 +0000 Subject: [openssl-users] renegotiation expected to fail when trust configuration has changed. In-Reply-To: References: Message-ID: <1c57056b-c090-27b9-6458-95874572d156@openssl.org> On 22/11/2018 15:58, Pfluegl, Andreas wrote: > > I expect server_parse_cb() returning 0 to cause the interruption of the connection. > > Can you confirm this? Yes. According to the docs: "If the B considers the extension data acceptable it must return 1. If it returns 0 or a negative value a fatal handshake error occurs using the TLS alert value specified in B<*al>." https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_add_server_custom_ext.html > > Here I am missing server_parse_cb() (see Server trace scenario 1) When a client receives a HelloRequest message it will send a new ClientHello and attempt to resume the connection. The attempt at resumption does not occur when a reneg is initiated from the client side unless you call SSL_renegotiate_abbreviated() instead of SSL_renegotiate(). If the attempt at resumption is successful then custom extension parsing does not get invoked on the server side. This is by design: https://github.com/openssl/openssl/blob/0fbe8491fc05d280a1f00bfc26dd3c3a6c63f04a/ssl/t1_lib.c#L2314-L2325 Unfortunately the docs in 1.1.0 are a bit lacking on this point. They have been significantly revised and updated in 1.1.1 and hopefully this is a little more obvious. In particular note that the 1.1.1 flag SSL_EXT_IGNORE_ON_RESUMPTION is automatically set when calling SSL_CTX_add_server_custom_ext(). This is so that the behaviour is backwards compatible with 1.1.0: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_add_custom_ext.html In 1.1.1 we have the new function SSL_CTX_add_custom_ext() which (among other things) allows you to control whether the callback is called during resumption or not. See the doc link above. So, in order to solve your problem, I see 2 possible solutions: 1) Upgrade to 1.1.1 and use the new SSL_CTX_add_custom_ext() API. or 2) Invalidate any sessions in the session cache for old connections that were established using the old certificate. You'll need to some additional custom code to track that I imagine. You'll also need to avoid session tickets for that to work. Probably the upgrade to 1.1.1 is your best bet since 1.1.0 is only supported until September 2019 anyway. Matt From OpenSSL at k-h.us Thu Nov 22 18:43:52 2018 From: OpenSSL at k-h.us (Ken) Date: Thu, 22 Nov 2018 10:43:52 -0800 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <20181121230406.GR4122@straasha.imrryr.org> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> <5EE3448B-A095-4CE8-B845-8D258F0EB9F7@dukhovni.org> <97E1765C-68B9-4FCF-BDA3-5B9C1CC81380@dukhovni.org> <7ac3c94d-4d8a-d36e-d1af-d4b110b51aec@k-h.us> <20181121230406.GR4122@straasha.imrryr.org> Message-ID: <8f03b765-f2f4-bff8-20a9-d7f763b2ccd9@k-h.us> Hi Viktor, It looks like FreeRDP was not setting a purpose when checking the certificate, causing this issue. I added: X509_STORE_CTX_set_default(csc, "ssl_server"); before the call to if (X509_verify_cert(csc) == 1) and this seems to make it work. I don't know if this is a "good" way to fix this, but I sent this information off to the maintainers of FreeRDP - hopefully, they can "do it right". As far as our previous message, I was having some "communications issues" the day I wrote that: >> I tested using s_client, on both systems, with no options, with CAfile >> pointing to the correct CA, and with CAfile pointing to the WRONG CA >> file - the only time it failed was on the new version, with the wrong >> file. (Results attached.) I guess the new version is better at checking >> things. > Perhaps you did not override CApath? And the default CApath succeeds > with old, but not the new code? For meaningful tests you need to > explicitly override both, and place just specific CA certs in CAfile, > leaving CApath empty. That is what I did, just not what I wrote! >> I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE, to the >> empty directory and the CA file - did not help. > I don't believe I suggested setting SSL_CERT_FILE to an empty > directory, or an empty file. Though putting a freshly minted > self-signed root that has never signed any certificates into CAfile, > can be one test to check that your application fails when it should > definitely fail. I meant that I set SSL_CERT_DIR to an empty directory, and SSL_CERT_FILE to the CA file. >> Then, I tested setting SSL_CERT_DIR to /var/lib/ca-certificates/openssl >> (which seems to be the default, and did not change anything), and then >> setting SSL_CERT_DIR to /var/lib/ca-certificates/pem/ - this made >> FreeRDP happy with the certificate. >> >> I compared >> Starfield_Root_Certificate_Authority_-_G2.pem in the openssl directory >> on the two systems - they are a binary match. > But they're not the same, only the encapsulated X.509 certificates > are the same, but one is wrapped as a "trusted certificate" with a > specific trust EKU. I meant that "/var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem" is the same on OpenSUSE 42.3 and OpenSUSE 1.5.0 >> Then I compared the output of >> >> openssl x509 -in /var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text >> and >> openssl x509 -in /var/lib/ca-certificates/pem/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text > That is, they are NOT the same. > >> The only difference is that the one from openssl ends with: >> >> Trusted Uses: >> TLS Web Server Authentication >> No Rejected Uses. >> Alias: Starfield Root Certificate Authority - G2 > Well, that's "auxiliary" trust data outside the certificate. It > is part of a "TRUSTED CERTICATE" encapsulation of a CA certificate, > and can be used to limit the "purpose" for which a certificate is > valid. > > If your application does not specify "serverAuth" as the "purpose" > being verified, then verification should fail. This was the hint that helped me. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Thu Nov 22 21:44:25 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 22 Nov 2018 22:44:25 +0100 Subject: [openssl-users] OpenSSL 1.0.2: CVE-2018-0735 In-Reply-To: <03abeaba-0ece-272a-d915-2d18c0cd6df6@oracle.com> References: <03abeaba-0ece-272a-d915-2d18c0cd6df6@oracle.com> Message-ID: <20181122214424.GA6563@roeckx.be> On Tue, Nov 06, 2018 at 04:19:36PM -0600, Misaki Miyashita wrote: > Hi, > > According to the vulnerabilities website[1], OpenSSL 1.1.i and earlier and > 1.1.1 are affected by CVE-2018-0735. > Is it safe to assume that OpenSSL 1.0.2 is not affected by the CVE? My understanding is that the code was not present in 1.0.2. To address CVE-2018-5407, that code was backported to 1.0.2, but the fixed version was used. Kurt From ckashiquekvk at gmail.com Fri Nov 23 05:11:07 2018 From: ckashiquekvk at gmail.com (ASHIQUE CK) Date: Fri, 23 Nov 2018 10:41:07 +0530 Subject: [openssl-users] Openssl speed command for AESGCM Message-ID: Hi, Does Openssl has speed command for AESGCM ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From maoly527 at 163.com Fri Nov 23 07:14:33 2018 From: maoly527 at 163.com (=?GBK?B?w6s=?=) Date: Fri, 23 Nov 2018 15:14:33 +0800 (CST) Subject: [openssl-users] How to use RSA certificate and ECC certificate simutaneously In-Reply-To: <630BC551-F1C9-46FE-BA29-7E3B4C6B90BF@dukhovni.org> References: <18972e11.8657.1672fadf8a6.Coremail.maoly527@163.com> <2B1A47DD-ED0D-41A9-B38D-5FD5E1E61881@dukhovni.org> <254e2372.cde2.167355324bd.Coremail.maoly527@163.com> <630BC551-F1C9-46FE-BA29-7E3B4C6B90BF@dukhovni.org> Message-ID: <430546fc.a517.1673f6b9115.Coremail.maoly527@163.com> Hi Viktor, >Do you then add chain certificates one by one? Yes, and SSL_CTX_use_certificate() also works in multiple certificate types on 1.0.2. Many thanks, Jane ? 2018-11-22 01:24:06?"Viktor Dukhovni" ??? >> On Nov 21, 2018, at 3:11 AM, ? wrote: >> >> We are using SSL_CTX_use_certificate() instead of >> SSL_CTX_use_certificate_chain_file(). > >Do you then add chain certificates one by one? > >> Does it also support multiple certificate chains? > >I believe it will work correctly in 1.1.x, and perhaps in 1.0.2, but >it has been a while since I've looked at the details. Check the >documentation and if necessary the source code. If the documentation >fails to describe this adequately, please open an issue on Github. > >> And as I know, OpenSSL 1.0.2 and later have a separate chain store for >> each type of certificate (RSA, ECC or DSA), Is there any bad impact to >> call it multiple times for same type of certificate? > >No, but only the last key/cert loaded for a given algorithm will be >used, any previous setting will be replaced. Make sure always load >both to avoid having a certificate that does not match the private key. > >-- >-- > Viktor. > >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From priyahere223 at gmail.com Fri Nov 23 10:33:27 2018 From: priyahere223 at gmail.com (priya p) Date: Fri, 23 Nov 2018 16:03:27 +0530 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: <18896.1542727673@localhost> <33c3f91a-81b5-c739-08dc-01b08dbe03a1@openssl.org> Message-ID: Hi, In this snippet, DH *dh; if ((dh->g = BN_new()) == NULL)-------------> 1 goto end; if (!BN_set_word(dh->g, g)) -----------------------> 2 goto end; Here as we can't reference dh structure members directly, how can we initialize and set it in case of 1 and 2 ? Thanks, Priya On Tue, 20 Nov 2018 at 23:08, priya p wrote: > Thanks Matt and Michael. > > On Tue, 20 Nov 2018 at 20:59, Matt Caswell wrote: > >> >> >> On 20/11/2018 15:27, Michael Richardson wrote: >> > priya p wrote: >> > > In openssl-1.1.1, few structures have been made opaque like >> HMAC_CTX, >> > > EVP_CIPHER_CTX etc., >> > >> > > There are new API to get and set those structure members. But to >> > > zeroize those structure members in place, I dont see any API. >> > >> > "in place", do you mean because you've allocated them as auto variables >> > on the stack? >> >> It is not possible to allocate opaque structures on the stack. The >> compiler will >> complain. >> >> Matt >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Nov 23 10:55:50 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 23 Nov 2018 10:55:50 +0000 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: <18896.1542727673@localhost> <33c3f91a-81b5-c739-08dc-01b08dbe03a1@openssl.org> Message-ID: <907dc2bb-f007-c574-0c01-d98700a8ec55@openssl.org> On 23/11/2018 10:33, priya p wrote: > Hi,? ? ? ? > ?? > In this snippet,? > > ?? ? ? DH *dh; > ? ? ? ? ? ? ? if ((dh->g = BN_new()) == NULL)-------------> 1 > ? ? ? ? ? ? ? ? ? ? ?goto end; > ? ? ? ? ? ? ?if (!BN_set_word(dh->g, g)) -----------------------> 2 > ? ? ? ? ? ? ? ? ? ? ? goto end; > > Here as we can't reference dh structure members directly,? how can we initialize > and set it in case of 1 and 2 ? Use the DH_set0_pqg() function: https://www.openssl.org/docs/man1.1.1/man3/DH_set0_pqg.html You must also set p at the same time. Matt > > Thanks, > Priya > > > On Tue, 20 Nov 2018 at 23:08, priya p > wrote: > > Thanks Matt and Michael. > > On Tue, 20 Nov 2018 at 20:59, Matt Caswell > wrote: > > > > On 20/11/2018 15:27, Michael Richardson wrote: > > priya p > wrote: > >? ? ?> In openssl-1.1.1, few structures have been made opaque like > HMAC_CTX, > >? ? ?> EVP_CIPHER_CTX etc., > > > >? ? ?> There are new API to get and set those structure members. But to > >? ? ?> zeroize those structure members in place, I dont see any API. > > > > "in place", do you mean because you've allocated them as auto variables > > on the stack? > > It is not possible to allocate opaque structures on the stack. The > compiler will > complain. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > From levitte at openssl.org Fri Nov 23 11:29:11 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 23 Nov 2018 12:29:11 +0100 (CET) Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: <33c3f91a-81b5-c739-08dc-01b08dbe03a1@openssl.org> Message-ID: <20181123.122911.542220583876995347.levitte@openssl.org> In message on Fri, 23 Nov 2018 10:33:48 +0000, openssl-users-request at openssl.org said: > Hi, > > In this snippet, > > DH *dh; > if ((dh->g = BN_new()) == NULL)-------------> 1 > goto end; > if (!BN_set_word(dh->g, g)) -----------------------> 2 > goto end; DH *dh; BIGNUM *bn_g; if ((bn_g= BN_new()) == NULL) goto end; if (!BN_set_word(bn_g, g)) goto end; if (!DH_set0_pqg(dh, NULL, NULL, bn_g)) goto end; Note that if the p parameter hasn't been set in dh, you must give that one too, so essentially, this is safer: if (!DH_set0_pqg(dh, bn_p, NULL, bn_g)) goto end; See the manual pages for DH_set0_pqg and DH_get0_pqg Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From vieuxtech at gmail.com Fri Nov 23 19:25:27 2018 From: vieuxtech at gmail.com (Sam Roberts) Date: Fri, 23 Nov 2018 11:25:27 -0800 Subject: [openssl-users] was the change in when disabled ciphers are skipped intentional? Message-ID: In 1.1.0j, if SSL_CTX_set_cipher_list() is called with "not-a-cipher" or "rc4", then SSL_R_NO_CIPHER_MATCH will occur. In 1.1.1a, set_cipher_list() suceeds, seems to return the complete cipher list (should it do this?) but later ssl_cipher_list_to_bytes() will find that ssl_cipher_disabled() is true for all the ciphers, and SSL_R_NO_CIPHERS_AVAILABLE will occur. We can work around this change, but it seems to be moving a configuration error to a runtime error, and I'm not sure this was intentional, or a side-effect of code cleanups. I couldn't find mention of it in the man page or changelog. Also, I don't understand why "not-a-cipher" matches any ciphers in 1.1.1, I'd expect the cipher list to be empty. From norm.green at gemtalksystems.com Fri Nov 23 19:28:49 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Fri, 23 Nov 2018 11:28:49 -0800 Subject: [openssl-users] 1.1.1a test/rsa_complex link failure on Solaris Message-ID: I'm seeing the following link failure on Solaris, both SPARC and x86_64 with 1.1.1a.? 1.1.1 does not have this problem.? Adding -lcrypto to the link line makes the problem go away. Any suggestions on how to proceed? Norm Green rm -f test/rsa_complex ${LDCMD:-/opt/studio12.5/bin/cc} -m64 -xstrconst -Xa -KPIC -mt -g -L. -m64 -mt? \ ??????? -o test/rsa_complex test/rsa_complex.o \ ???????? -lresolv -lsocket -lnsl -ldl -lm -lrt -lpthread Undefined?????????????????????? first referenced ?symbol???????????????????????????? in file OPENSSL_sk_pop_free???????????????? test/rsa_complex.o OPENSSL_sk_dup????????????????????? test/rsa_complex.o OPENSSL_sk_pop????????????????????? test/rsa_complex.o OPENSSL_sk_num????????????????????? test/rsa_complex.o OPENSSL_sk_new????????????????????? test/rsa_complex.o OPENSSL_sk_set????????????????????? test/rsa_complex.o OPENSSL_sk_free???????????????????? test/rsa_complex.o OPENSSL_sk_find???????????????????? test/rsa_complex.o OPENSSL_sk_push???????????????????? test/rsa_complex.o OPENSSL_sk_sort???????????????????? test/rsa_complex.o OPENSSL_sk_zero???????????????????? test/rsa_complex.o OPENSSL_sk_is_sorted??????????????? test/rsa_complex.o OPENSSL_sk_shift??????????????????? test/rsa_complex.o OPENSSL_sk_value??????????????????? test/rsa_complex.o OPENSSL_sk_delete_ptr?????????????? test/rsa_complex.o OPENSSL_sk_unshift????????????????? test/rsa_complex.o OPENSSL_sk_new_null???????????????? test/rsa_complex.o OPENSSL_sk_set_cmp_func???????????? test/rsa_complex.o OPENSSL_sk_reserve????????????????? test/rsa_complex.o OPENSSL_sk_new_reserve????????????? test/rsa_complex.o OPENSSL_sk_delete?????????????????? test/rsa_complex.o OPENSSL_sk_insert?????????????????? test/rsa_complex.o OPENSSL_sk_deep_copy??????????????? test/rsa_complex.o OPENSSL_sk_find_ex????????????????? test/rsa_complex.o ld: fatal: symbol referencing errors. No output written to test/rsa_complex Makefile:3594: recipe for target 'test/rsa_complex' failed gmake[1]: *** [test/rsa_complex] Error 2 gmake[1]: Leaving directory '/export/foof3/users/buildgss/34/build45082/slow13/openssl_1.1' Makefile:169: recipe for target 'all' failed gmake: *** [all] Error 2 buildgss>perl configdata.pm --dump Command line (with current working directory = .): ??? /export/localnew/i386.Solaris/perl/bin/perl ./Configure threads shared no-zlib --prefix=/export/foof3/users/buildgss/34/build45082/slow13/openssl_1.1/install13 debug-solaris64-x86_64-cc Perl information: ??? /export/localnew/i386.Solaris/perl/bin/perl ??? 5.20.1 for i86pc-solaris-64int Enabled features: ??? aria ??? asm ??? async ??? autoalginit ??? autoerrinit ??? autoload-config ??? bf ??? blake2 ??? camellia ??? capieng ??? cast ??? chacha ??? cmac ??? cms ??? comp ??? ct ??? deprecated ??? des ??? dgram ??? dh ??? dsa ??? dso ??? dtls ??? dynamic-engine ??? ec ??? ec2m ??? ecdh ??? ecdsa ??? engine ??? err ??? filenames ??? gost ??? hw(-.+)? ??? idea ??? md4 ??? mdc2 ??? multiblock ??? nextprotoneg ??? ocb ??? ocsp ??? pic ??? poly1305 ??? posix-io ??? psk ??? rc2 ??? rc4 ??? rdrand ??? rfc3779 ??? rmd160 ??? scrypt ??? seed ??? shared ??? siphash ??? sm2 ??? sm3 ??? sm4 ??? sock ??? srp ??? srtp ??? sse2 ??? ssl ??? static-engine ??? stdio ??? tests ??? threads ??? tls ??? ts ??? ui-console ??? whirlpool ??? tls1 ??? tls1-method ??? tls1_1 ??? tls1_1-method ??? tls1_2 ??? tls1_2-method ??? tls1_3 ??? dtls1 ??? dtls1-method ??? dtls1_2 ??? dtls1_2-method Disabled features: ??? afalgeng??????????????? [not-linux] ??? asan??????????????????? [default]???? OPENSSL_NO_ASAN ??? crypto-mdebug?????????? [default]???? OPENSSL_NO_CRYPTO_MDEBUG ??? crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE ??? devcryptoeng??????????? [default]???? OPENSSL_NO_DEVCRYPTOENG ??? ec_nistp_64_gcc_128???? [default] OPENSSL_NO_EC_NISTP_64_GCC_128 ??? egd???????????????????? [default]???? OPENSSL_NO_EGD ??? external-tests????????? [default] OPENSSL_NO_EXTERNAL_TESTS ??? fuzz-libfuzzer????????? [default] OPENSSL_NO_FUZZ_LIBFUZZER ??? fuzz-afl??????????????? [default]???? OPENSSL_NO_FUZZ_AFL ??? heartbeats????????????? [default]???? OPENSSL_NO_HEARTBEATS ??? makedepend????????????? [unavailable] ??? md2???????????????????? [default]???? OPENSSL_NO_MD2 (skip crypto/md2) ??? msan??????????????????? [default]???? OPENSSL_NO_MSAN ??? rc5???????????????????? [default]???? OPENSSL_NO_RC5 (skip crypto/rc5) ??? sctp??????????????????? [default]???? OPENSSL_NO_SCTP ??? ssl-trace?????????????? [default]???? OPENSSL_NO_SSL_TRACE ??? ubsan?????????????????? [default]???? OPENSSL_NO_UBSAN ??? unit-test?????????????? [default]???? OPENSSL_NO_UNIT_TEST ??? weak-ssl-ciphers??????? [default] OPENSSL_NO_WEAK_SSL_CIPHERS ??? zlib??????????????????? [option] ??? zlib-dynamic??????????? [default] ??? ssl3??????????????????? [default]???? OPENSSL_NO_SSL3 ??? ssl3-method???????????? [default]???? OPENSSL_NO_SSL3_METHOD Config target attributes: ??? AR => "ar", ??? ARFLAGS => "r", ??? CC => "cc", ??? CFLAGS => "-g", ??? HASHBANGPERL => "/usr/bin/env perl", ??? RANLIB => "ranlib", ??? RC => "windres", ??? aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s aesni-mb-x86_64.s", ??? aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o", ??? apps_aux_src => "", ??? apps_init_src => "", ??? apps_obj => "", ??? bf_asm_src => "bf_enc.c", ??? bf_obj => "bf_enc.o", ??? bn_asm_src => "asm/x86_64-gcc.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s", ??? bn_obj => "asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o", ??? bn_ops => "SIXTY_FOUR_BIT_LONG", ??? build_file => "Makefile", ??? build_scheme => [ "unified", "unix" ], ??? cast_asm_src => "c_enc.c", ??? cast_obj => "c_enc.o", ??? cflags => "-m64 -xstrconst -Xa -KPIC -mt", ??? chacha_asm_src => "chacha-x86_64.s", ??? chacha_obj => "chacha-x86_64.o", ??? cmll_asm_src => "cmll-x86_64.s cmll_misc.c", ??? cmll_obj => "cmll-x86_64.o cmll_misc.o", ??? cppflags => "-D_REENTRANT", ??? cpuid_asm_src => "x86_64cpuid.s", ??? cpuid_obj => "x86_64cpuid.o", ??? defines => [? ], ??? des_asm_src => "des_enc.c fcrypt_b.c", ??? des_obj => "des_enc.o fcrypt_b.o", ??? disable => [? ], ??? dso_extension => ".so", ??? dso_scheme => "dlfcn", ??? ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s", ??? ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o", ??? enable => [? ], ??? ex_libs => "-lresolv -lsocket -lnsl -ldl -lm -lrt -lpthread", ??? exe_extension => "", ??? includes => [? ], ??? keccak1600_asm_src => "keccak1600-x86_64.s", ??? keccak1600_obj => "keccak1600-x86_64.o", ??? lflags => "-m64 -mt", ??? lib_cflags => "", ??? lib_cppflags => "-DFILIO_H -DL_ENDIAN", ??? lib_defines => [? ], ??? md5_asm_src => "md5-x86_64.s", ??? md5_obj => "md5-x86_64.o", ??? modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s", ??? modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o", ??? module_cflags => "-KPIC", ??? module_cxxflags => "", ??? module_ldflags => "-m64 -G -dy -z text -Wl,-Bsymbolic", ??? multilib => "/64", ??? padlock_asm_src => "e_padlock-x86_64.s", ??? padlock_obj => "e_padlock-x86_64.o", ??? perlasm_scheme => "elf", ??? poly1305_asm_src => "poly1305-x86_64.s", ??? poly1305_obj => "poly1305-x86_64.o", ??? rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s", ??? rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o", ??? rc5_asm_src => "rc5_enc.c", ??? rc5_obj => "rc5_enc.o", ??? rmd160_asm_src => "", ??? rmd160_obj => "", ??? sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s sha1-mb-x86_64.s sha256-mb-x86_64.s", ??? sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o", ??? shared_cflag => "-KPIC", ??? shared_defflag => "-Wl,-M,", ??? shared_defines => [? ], ??? shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)", ??? shared_extension_simple => ".so", ??? shared_ldflag => "-m64 -G -dy -z text -Wl,-Bsymbolic", ??? shared_rcflag => "", ??? shared_sonameflag => "-Wl,-h,", ??? shared_target => "self", ??? thread_defines => [? ], ??? thread_scheme => "pthreads", ??? unistd => "", ??? uplink_aux_src => "", ??? uplink_obj => "", ??? wp_asm_src => "wp-x86_64.s", ??? wp_obj => "wp-x86_64.o", Recorded environment: ??? AR = ??? ARFLAGS = ??? AS = ??? ASFLAGS = ??? BUILDFILE = ??? CC = /opt/studio12.5/bin/cc ??? CFLAGS = ??? CPP = ??? CPPDEFINES = ??? CPPFLAGS = ??? CPPINCLUDES = ??? CROSS_COMPILE = ??? CXX = ??? CXXFLAGS = ??? HASHBANGPERL = ??? LD = /opt/studio12.5/bin/CC ??? LDFLAGS = ??? LDLIBS = ??? MT = ??? MTFLAGS = ??? OPENSSL_LOCAL_CONFIG_DIR = ??? PERL = /export/localnew/i386.Solaris/perl/bin/perl ??? RANLIB = ??? RC = ??? RCFLAGS = ??? RM = ??? WINDRES = ??? __CNF_CFLAGS = ??? __CNF_CPPDEFINES = ??? __CNF_CPPFLAGS = ??? __CNF_CPPINCLUDES = ??? __CNF_CXXFLAGS = ??? __CNF_LDFLAGS = ??? __CNF_LDLIBS = Makevars: ??? AR????????????? = ar ??? ARFLAGS???????? = r ??? CC????????????? = /opt/studio12.5/bin/cc ??? CFLAGS????????? = -g ??? CPPDEFINES????? = ??? CPPFLAGS??????? = ??? CPPINCLUDES???? = ??? CXXFLAGS??????? = ??? HASHBANGPERL??? = /export/localnew/i386.Solaris/perl/bin/perl ??? LD????????????? = /opt/studio12.5/bin/CC ??? LDFLAGS???????? = ??? LDLIBS????????? = ??? PERL??????????? = /export/localnew/i386.Solaris/perl/bin/perl ??? RANLIB????????? = ranlib ??? RC????????????? = windres NOTE: These variables only represent the configuration view.? The build file template may have processed these variables further, please have a look at the build file for more exact data: ??? Makefile build file: ??? Makefile build file templates: ??? Configurations/common0.tmpl ??? Configurations/unix-Makefile.tmpl ??? Configurations/common.tmpl From openssl-users at dukhovni.org Fri Nov 23 19:40:52 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 23 Nov 2018 14:40:52 -0500 Subject: [openssl-users] was the change in when disabled ciphers are skipped intentional? In-Reply-To: References: Message-ID: > On Nov 23, 2018, at 2:25 PM, Sam Roberts wrote: > > In 1.1.0j, if SSL_CTX_set_cipher_list() is called with "not-a-cipher" > or "rc4", then SSL_R_NO_CIPHER_MATCH will occur. > > In 1.1.1a, set_cipher_list() suceeds, seems to return the complete > cipher list (should it do this?) but later ssl_cipher_list_to_bytes() > will find that ssl_cipher_disabled() is true for all the ciphers, and > SSL_R_NO_CIPHERS_AVAILABLE will occur. When I try it with ciphers(1), I get (as expected) just the TLSv1.3 ciphers, which are configured separately from the TLSv1.2 (and below) ciphers: $ /opt/openssl/1.1.1/bin/openssl ciphers -v not-a-cipher TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD > Also, I don't understand why "not-a-cipher" matches any ciphers in > 1.1.1, I'd expect the cipher list to be empty. It should have the effect of disabling all SSLv3 and TLSv1.[012] ciphers, leaving just the TLSv1.3 ciphers enabled. Any change of behaviour you're seeing surely results from the introduction of a separate TLSv1.3 cipherlist, but what remains to be explained is what you mean by "seems to return the complete cipher list", is that a bug, a documentation defect or user error? -- Viktor. From vieuxtech at gmail.com Fri Nov 23 22:08:32 2018 From: vieuxtech at gmail.com (Sam Roberts) Date: Fri, 23 Nov 2018 14:08:32 -0800 Subject: [openssl-users] was the change in when disabled ciphers are skipped intentional? In-Reply-To: References: Message-ID: On Fri, Nov 23, 2018 at 11:41 AM Viktor Dukhovni wrote: > > On Nov 23, 2018, at 2:25 PM, Sam Roberts wrote: > > > > In 1.1.0j, if SSL_CTX_set_cipher_list() is called with "not-a-cipher" > > or "rc4", then SSL_R_NO_CIPHER_MATCH will occur. > > > > In 1.1.1a, set_cipher_list() suceeds, seems to return the complete > > cipher list (should it do this?) but later ssl_cipher_list_to_bytes() > > will find that ssl_cipher_disabled() is true for all the ciphers, and > > SSL_R_NO_CIPHERS_AVAILABLE will occur. So what is happening is happening is that while there are two APIs, SSL_CTX_set_ciphersuites()(TLSv1.3) and SSL_CTX_set_cipher_list()(<=TLSv1.2), they both put cipher suites into SSL_CTX.cipher_list. This basically makes the cipher_list error check: if (sk_SSL_CIPHER_num(sk) == 0) { SSLerr(SSL_F_SSL_CTX_SET_CIPHER_LIST, SSL_R_NO_CIPHER_MATCH); return 0; } bogus, because even when there were, in fact zero TLSv1.2 cipher suites configured, the check for cipher suite number will find the number greater than zero if there are TLSv1.3 cipher suites in the list. Which there will be, by default. The actual behaviour of this check depends on the order in which set_ciphersuites() and set_cipher_list() are called, a fact I can exploit to make the API backwards compatible for Node.js. I will call SSL_CTX_set_ciphersuites(ctx,"") just before calling set_cipher_list(). This will clear out the TLSv1.3 suites (we don't support 1.3 yet). Since the 1.3 suites are gone, the check for a length of zero causing NO_CIPHER_MATCH will now behave as it would be expected. This won't work in the future. I think what really should be done is that the check for _num(sk) == 0 needs to be rewritten, to iterate the list, and find the number of TLSv1.2 and below ciphers, and return NO_CIPHER_MATCH if that number is zero. Cheers, Sam > When I try it with ciphers(1), I get (as expected) just the TLSv1.3 > ciphers, which are configured separately from the TLSv1.2 (and below) > ciphers: > > $ /opt/openssl/1.1.1/bin/openssl ciphers -v not-a-cipher > TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD > TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD > TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD > > > Also, I don't understand why "not-a-cipher" matches any ciphers in > > 1.1.1, I'd expect the cipher list to be empty. > > It should have the effect of disabling all SSLv3 and TLSv1.[012] ciphers, > leaving just the TLSv1.3 ciphers enabled. > > Any change of behaviour you're seeing surely results from the introduction > of a separate TLSv1.3 cipherlist, but what remains to be explained is what > you mean by "seems to return the complete cipher list", is that a bug, a > documentation defect or user error? From priyahere223 at gmail.com Sat Nov 24 14:25:42 2018 From: priyahere223 at gmail.com (priya p) Date: Sat, 24 Nov 2018 19:55:42 +0530 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: <20181123.122911.542220583876995347.levitte@openssl.org> References: <33c3f91a-81b5-c739-08dc-01b08dbe03a1@openssl.org> <20181123.122911.542220583876995347.levitte@openssl.org> Message-ID: Thanks Matt and Richard. BIGNUM structure also has been made opaque. How to refer the members of BIGNUM structure like bn->top ? And I don't see this API implementation ""lh_OPENSSL_CSTRING_new" in openssl-1.1.1 ? Is it removed ? Thanks, Priya On Fri, 23 Nov 2018 at 16:59, Richard Levitte wrote: > In message on > Fri, 23 Nov 2018 10:33:48 +0000, openssl-users-request at openssl.org said: > > > Hi, > > > > In this snippet, > > > > DH *dh; > > if ((dh->g = BN_new()) == NULL)-------------> 1 > > goto end; > > if (!BN_set_word(dh->g, g)) -----------------------> 2 > > goto end; > > DH *dh; > BIGNUM *bn_g; > > if ((bn_g= BN_new()) == NULL) > goto end; > if (!BN_set_word(bn_g, g)) > goto end; > if (!DH_set0_pqg(dh, NULL, NULL, bn_g)) > goto end; > > Note that if the p parameter hasn't been set in dh, you must give that > one too, so essentially, this is safer: > > if (!DH_set0_pqg(dh, bn_p, NULL, bn_g)) > goto end; > > See the manual pages for DH_set0_pqg and DH_get0_pqg > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun Nov 25 04:01:29 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 25 Nov 2018 04:01:29 +0000 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: <33c3f91a-81b5-c739-08dc-01b08dbe03a1@openssl.org> <20181123.122911.542220583876995347.levitte@openssl.org> Message-ID: <0E177B02-E5D8-4FC8-B22C-125F54AACC7C@akamai.com> * BIGNUM structure also has been made opaque. How to refer the members of BIGNUM structure like bn->top ? You cannot. That is the definition of ?opaque structure.? :) Why do you need to access ?top? ? * And I don't see this API implementation ""lh_OPENSSL_CSTRING_new" in openssl-1.1.1 ? It is a static inline functions in include/openssl/safestack.h. Because it?s static-inline, it won?t show up unless it is actually used. -------------- next part -------------- An HTML attachment was scrubbed... URL: From priyahere223 at gmail.com Sun Nov 25 05:35:52 2018 From: priyahere223 at gmail.com (priya p) Date: Sun, 25 Nov 2018 11:05:52 +0530 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: <0E177B02-E5D8-4FC8-B22C-125F54AACC7C@akamai.com> References: <33c3f91a-81b5-c739-08dc-01b08dbe03a1@openssl.org> <20181123.122911.542220583876995347.levitte@openssl.org> <0E177B02-E5D8-4FC8-B22C-125F54AACC7C@akamai.com> Message-ID: Hi Matt, I want to get/set BIGNUM structure members using API like DH getter/setter ? Thanks, Priya On Sun, Nov 25, 2018, 9:32 AM Salz, Rich via openssl-users < openssl-users at openssl.org wrote: > > - BIGNUM structure also has been made opaque. How to refer the members > of BIGNUM structure like bn->top ? > > > > You cannot. That is the definition of ?opaque structure.? :) Why do you > need to access ?top? ? > > > > - And I don't see this API implementation ""lh_OPENSSL_CSTRING_new" in > openssl-1.1.1 ? > > > > It is a static inline functions in include/openssl/safestack.h. Because > it?s static-inline, it won?t show up unless it is actually used. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sun Nov 25 06:26:07 2018 From: levitte at openssl.org (Richard Levitte) Date: Sun, 25 Nov 2018 07:26:07 +0100 (CET) Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: <0E177B02-E5D8-4FC8-B22C-125F54AACC7C@akamai.com> Message-ID: <20181125.072607.1687559205620809332.levitte@openssl.org> (that was Rich responding, not Matt ;-)) There are penty of functions to assign values properly to BIGNUMs without having to resort to accessing the structure members. If you still have reasons to do so, that sounds like you want to modify the API somehow, and since you do have access to the OpenSSL source, you're free to do so (and to maintain your own patches). Cheers, Richard In message on Sun, 25 Nov 2018 11:05:52 +0530, priya p said: > Hi Matt, > > I want to get/set BIGNUM structure members using API like DH getter/setter ? > > Thanks, > Priya > > On Sun, Nov 25, 2018, 9:32 AM Salz, Rich via openssl-users > * BIGNUM structure also has been made opaque. How to refer the members of BIGNUM > structure like bn->top ? > > You cannot. That is the definition of ?opaque structure.? :) Why do you need to access ?top? ? > > * And I don't see this API implementation ""lh_OPENSSL_CSTRING_new" in openssl-1.1.1 ? > > It is a static inline functions in include/openssl/safestack.h. Because it?s static-inline, it won?t > show up unless it is actually used. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From jgh at wizmail.org Sun Nov 25 20:17:19 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 25 Nov 2018 20:17:19 +0000 Subject: [openssl-users] error message oddity Message-ID: <634b4563-cf96-040f-e52e-ded1c322d55b@wizmail.org> OpenSSL 1.1.0h-fips On OpenSuse tumbleweed I'm getting an error message lacking the last component: error:02001002:system library:fopen: This is for a deliberately-triggered error, on calling SSL_CTX_use_certificate_chain_file() with a non-existent file. The global "errno" is properly set at 2 (ENOENT) between the return from SSL_CTX_use_certificate_chain_file() and the call to ERR_error_string_n(ERR_get_error(), ...) - and a call to strerr() gets the correct string. I don't recall seeing this particular oddity on any of my other distribution system that I run the same test code on. Other systems get: error:xxxxxxxx:system library:fopen:No such file or directory for assorted values of xxxxxxxx (I'm also testing across library release versions). Any clues? Does anyone else see this, or have I borked the installation somehow? -- Thanks, Jeremy From openssl-users at dukhovni.org Sun Nov 25 21:00:37 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 25 Nov 2018 16:00:37 -0500 Subject: [openssl-users] error message oddity In-Reply-To: <634b4563-cf96-040f-e52e-ded1c322d55b@wizmail.org> References: <634b4563-cf96-040f-e52e-ded1c322d55b@wizmail.org> Message-ID: > On Nov 25, 2018, at 3:17 PM, Jeremy Harris wrote: > > OpenSSL 1.1.0h-fips FWIW (not germane to this issue), there is no FIPS module for OpenSSL 1.1.0, so the package name is rather misleading. > On OpenSuse tumbleweed I'm getting an error message lacking > the last component: > > error:02001002:system library:fopen: > > This is for a deliberately-triggered error, on calling > SSL_CTX_use_certificate_chain_file() with a non-existent file. > > The global "errno" is properly set at 2 (ENOENT) between the > return from SSL_CTX_use_certificate_chain_file() and the call > to ERR_error_string_n(ERR_get_error(), ...) - and a call > to strerr() gets the correct string. The only thing that comes to mind is that errno is thread-specific, and there may be some issue with compiler or linker flags that leads to a wrong implementation of the accessor. > I don't recall seeing this particular oddity on any of my > other distribution system that I run the same test code on. > Other systems get: > > error:xxxxxxxx:system library:fopen:No such file or directory > > for assorted values of xxxxxxxx (I'm also testing across > library release versions). > > > Any clues? Does anyone else see this, or have I borked the > installation somehow? I would try to rebuild, paying attention to the thread support flags. If that fails, ask on an OpenSuse list. It seems the issue is rather platform-specific. -- Viktor. From openssl-users at dukhovni.org Sun Nov 25 21:30:13 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 25 Nov 2018 16:30:13 -0500 Subject: [openssl-users] error message oddity In-Reply-To: <863faf43-05e8-f38e-b596-5afe38b4b484@wizmail.org> References: <634b4563-cf96-040f-e52e-ded1c322d55b@wizmail.org> <863faf43-05e8-f38e-b596-5afe38b4b484@wizmail.org> Message-ID: <51F32323-D200-4176-8B76-84D514E7D9E3@dukhovni.org> > On Nov 25, 2018, at 4:23 PM, Jeremy Harris wrote: > > That isn't the package name, it is text defined in openssl/opensslv.h That happens when "OPENSSL_FIPS" is defined: # define OPENSSL_VERSION_NUMBER 0x101000b0L # ifdef OPENSSL_FIPS # define OPENSSL_VERSION_TEXT "OpenSSL 1.1.0k-fips-dev xx XXX xxxx" # else # define OPENSSL_VERSION_TEXT "OpenSSL 1.1.0k-dev xx XXX xxxx" # endif Given no FIPS for 1.1.x, perhaps that "#ifdef" should be "#if 0". With 1.1.x the "Configure" arguments should not mention "fips". -- Viktor. From priyahere223 at gmail.com Mon Nov 26 05:14:17 2018 From: priyahere223 at gmail.com (priya p) Date: Mon, 26 Nov 2018 10:44:17 +0530 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: <20181125.072607.1687559205620809332.levitte@openssl.org> References: <0E177B02-E5D8-4FC8-B22C-125F54AACC7C@akamai.com> <20181125.072607.1687559205620809332.levitte@openssl.org> Message-ID: Hi Richard, I am unable to get the API to access bn->top value or any bn members in openssl 1.1.1 . Can you help me with the pointers to those APIs ? And I dont see "lh_OPENSSL_CSTRING_new " function in "include/openssl/safestack.h" ? Please correct me if I am wrong . Thanks, Priya On Sun, 25 Nov 2018 at 11:56, Richard Levitte wrote: > (that was Rich responding, not Matt ;-)) > > There are penty of functions to assign values properly to BIGNUMs > without having to resort to accessing the structure members. If you > still have reasons to do so, that sounds like you want to modify the > API somehow, and since you do have access to the OpenSSL source, > you're free to do so (and to maintain your own patches). > > Cheers, > Richard > > In message rMv2pibwFCck0vO0oFEWw at mail.gmail.com> on Sun, 25 Nov 2018 11:05:52 +0530, > priya p said: > > > Hi Matt, > > > > I want to get/set BIGNUM structure members using API like DH > getter/setter ? > > > > Thanks, > > Priya > > > > On Sun, Nov 25, 2018, 9:32 AM Salz, Rich via openssl-users < > openssl-users at openssl.org wrote: > > > > * BIGNUM structure also has been made opaque. How to refer the members > of BIGNUM > > structure like bn->top ? > > > > You cannot. That is the definition of ?opaque structure.? :) Why do you > need to access ?top? ? > > > > * And I don't see this API implementation ""lh_OPENSSL_CSTRING_new" in > openssl-1.1.1 ? > > > > It is a static inline functions in include/openssl/safestack.h. Because > it?s static-inline, it won?t > > show up unless it is actually used. > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 26 05:36:10 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Nov 2018 00:36:10 -0500 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: <0E177B02-E5D8-4FC8-B22C-125F54AACC7C@akamai.com> <20181125.072607.1687559205620809332.levitte@openssl.org> Message-ID: > On Nov 26, 2018, at 12:14 AM, priya p wrote: > > I am unable to get the API to access bn->top value or any bn members in openssl 1.1.1 . > Can you help me with the pointers to those APIs ? What actual problem are you trying to solve? Accessing bn->top is a goal in itself. -- Viktor. From priyahere223 at gmail.com Mon Nov 26 05:45:27 2018 From: priyahere223 at gmail.com (priya p) Date: Mon, 26 Nov 2018 11:15:27 +0530 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: <0E177B02-E5D8-4FC8-B22C-125F54AACC7C@akamai.com> <20181125.072607.1687559205620809332.levitte@openssl.org> Message-ID: I am trying to fix this part of code: int Func1 (var, bn) { *var = rc_vmalloc(bn->top * BN_BYTES); ------------------> Trying to fix this. Error it throws is " error: dereferencing pointer to incomplete type". (*var)->l = BN_bn2bin(bn, (unsigned char *)(*var)->v); . . } Thanks, Priya On Mon, 26 Nov 2018 at 11:06, Viktor Dukhovni wrote: > > On Nov 26, 2018, at 12:14 AM, priya p wrote: > > > > I am unable to get the API to access bn->top value or any bn members in > openssl 1.1.1 . > > Can you help me with the pointers to those APIs ? > > What actual problem are you trying to solve? Accessing bn->top is > a goal in itself. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hemantranvir at gmail.com Mon Nov 26 08:19:39 2018 From: hemantranvir at gmail.com (Hemant Ranvir) Date: Mon, 26 Nov 2018 17:19:39 +0900 Subject: [openssl-users] Extracting decrypt key for AES from openssl on client side In-Reply-To: References: <8B9324BA-ABB9-4901-A6FA-C73E9F6F106E@dukhovni.org> <137A4D5B-D128-4B42-868D-A4BF3B24E959@akamai.com> Message-ID: Hi Todd, That is exactly what I am trying to do. The final goal is to implement this in hardware. Anyways I figured out that the key expansion routine is slightly different, more specifically the equivalent inverse cipher routine defined in: https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf As per this the last 128 bits of the expanded key will be the key that I am looking for. I extracted that and was able to decrypt the message successfully. Thanks all the same. On Fri, Nov 16, 2018 at 12:19 AM Viktor Dukhovni wrote: > > On Nov 15, 2018, at 9:30 AM, Short, Todd via openssl-users < > openssl-users at openssl.org> wrote: > > > > I have seen this done for hardware acceleration; where the crypto chip > can do everything except the handshake. > > (In fact, this mechanism protected at least one device that I know of > from the Heartbleed debacle, since the hardware crypto did not understand > the record type.) > > > > Look at how the kernel handles TLS, and how the keys are extracted from > OpenSSL: > > > > > https://github.com/torvalds/linux/blob/master/Documentation/networking/tls.txt > > https://github.com/openssl/openssl/pull/5253 > > Well, it takes more than just extracting a key. One also needs to know > the cipher mode, and if not AEAD then the MAC algorithm and whether the > EtM extension has been negotiated, and with TLS 1.3 be prepared to > process keyUpdate messages, post handshake session tickets, ... > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Best Regards, Hemant Ranvir *"To live a creative life, we must lose our fear of being wrong.**" - J.C.Pearce* -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 26 13:32:33 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Nov 2018 08:32:33 -0500 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: <0E177B02-E5D8-4FC8-B22C-125F54AACC7C@akamai.com> <20181125.072607.1687559205620809332.levitte@openssl.org> Message-ID: <629F3F0D-B709-4B50-81FC-9B1B8F0FBABB@dukhovni.org> > On Nov 26, 2018, at 12:45 AM, priya p wrote: > > I am trying to fix this part of code: > > int Func1 (var, bn) { > *var = rc_vmalloc(bn->top * BN_BYTES); ------------------> Trying to fix this. Error it throws is " error: dereferencing pointer to incomplete type". > > (*var)->l = BN_bn2bin(bn, (unsigned char *)(*var)->v); > . > . > } Have you considered looking at the BN_bn2bin documentation? https://www.openssl.org/docs/man1.0.2/crypto/BN_bn2bin.html SYNOPSIS: int BN_bn2bin(const BIGNUM *a, unsigned char *to); DESCRIPTION: BN_bn2bin() converts the absolute value of a into big-endian form and stores it at to. to must point to BN_num_bytes(a) bytes of memory. -- Viktor. From rsalz at akamai.com Mon Nov 26 15:22:42 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 26 Nov 2018 15:22:42 +0000 Subject: [openssl-users] openssl 1.1.1 opaque structures In-Reply-To: References: <0E177B02-E5D8-4FC8-B22C-125F54AACC7C@akamai.com> <20181125.072607.1687559205620809332.levitte@openssl.org> Message-ID: <2C7D1273-3C3B-4A31-915B-C4D09E35F2B1@akamai.com> * I am unable to get the API to access bn->top value or any bn members in openssl 1.1.1 . Can you help me with the pointers to those APIs ? They do not exist. This is the first time someone has asked for them. You will need to open an issue on GitHub, and explain *why* you need access. * And I dont see "lh_OPENSSL_CSTRING_new " function in "include/openssl/safestack.h" ? Look for ?DEFINE_SPECIAL_STACK_OF_CONST(OPENSSL_CSTRING? near the end of the file. Then trace through the macros. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Nov 26 16:13:35 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 26 Nov 2018 17:13:35 +0100 Subject: [openssl-users] error message oddity In-Reply-To: <51F32323-D200-4176-8B76-84D514E7D9E3@dukhovni.org> References: <634b4563-cf96-040f-e52e-ded1c322d55b@wizmail.org> <863faf43-05e8-f38e-b596-5afe38b4b484@wizmail.org> <51F32323-D200-4176-8B76-84D514E7D9E3@dukhovni.org> Message-ID: <5eea805b-b6af-806e-d092-21eb41e814b9@wisemo.com> On 25/11/2018 22:30, Viktor Dukhovni wrote: >> On Nov 25, 2018, at 4:23 PM, Jeremy Harris wrote: >> >> That isn't the package name, it is text defined in openssl/opensslv.h > That happens when "OPENSSL_FIPS" is defined: > > # define OPENSSL_VERSION_NUMBER 0x101000b0L > # ifdef OPENSSL_FIPS > # define OPENSSL_VERSION_TEXT "OpenSSL 1.1.0k-fips-dev xx XXX xxxx" > # else > # define OPENSSL_VERSION_TEXT "OpenSSL 1.1.0k-dev xx XXX xxxx" > # endif > > Given no FIPS for 1.1.x, perhaps that "#ifdef" should be "#if 0". With > 1.1.x the "Configure" arguments should not mention "fips". > A better solution would be to have a separate part of the 1.1.0/1.1.1 headers error out hard (with #error) if attempting to build with OPENSSL_FIPS defined. This would preserve all the FIPS-related stuff (such as the above version naming code) for when a FIPS module for 1.1.x is provided, while leaving the blocking of accidental miscompilation in a clear location having no other effects. 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 From jb-openssl at wisemo.com Mon Nov 26 16:33:54 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 26 Nov 2018 17:33:54 +0100 Subject: [openssl-users] Client CA list sending is also in TLS < 1.3 (RFC6066) Message-ID: Hi, The ability of a TLS client to optionally send a list of trusted CAs to the TLS server is not new in TLS 1.3. In TLS 1.2 and older it was an extension "Trusted CA Indication" (3), defined in RFC6066 Chapter 6. So I would suggest that any OpenSSL API to control that feature in TLS 1.3 also affects the matching TLS < 1.3 functionality, and is separated from the APIs that control the TLS server sending a list of client certificate CAs to clients. This aspect was somehow missed in a recent discussion of this TLS 1.3 behavior (which I cannot find right now). 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 From OpenSSL at k-h.us Mon Nov 26 18:08:35 2018 From: OpenSSL at k-h.us (Ken) Date: Mon, 26 Nov 2018 10:08:35 -0800 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: <8f03b765-f2f4-bff8-20a9-d7f763b2ccd9@k-h.us> References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> <5EE3448B-A095-4CE8-B845-8D258F0EB9F7@dukhovni.org> <97E1765C-68B9-4FCF-BDA3-5B9C1CC81380@dukhovni.org> <7ac3c94d-4d8a-d36e-d1af-d4b110b51aec@k-h.us> <20181121230406.GR4122@straasha.imrryr.org> <8f03b765-f2f4-bff8-20a9-d7f763b2ccd9@k-h.us> Message-ID: Hi Viktor, Is it "better" to use X509_STORE_CTX_set_default(csc, "ssl_server"); or something more like purpose = X509_PURPOSE_SSL_SERVER; verify_param = X509_STORE_CTX_get0_param(csc); X509_VERIFY_PARAM_set_purpose(verify_param, purpose); X509_verify_cert(csc) When we tried the second option, it did not make any difference. When I added X509_STORE_CTX_set0_param(csc,verify_param); X509_verify_cert(csc) started returning error X509_V_ERR_CERT_CHAIN_TOO_LONG: certificate chain too long ------?Original?Message?------ From:?Ken Sent:?Thu, 22 Nov 2018 10:43:52 -0800 To:?Openssl-users Subject:?Re: [openssl-users] Problem with x509_verify_certificate > Hi Viktor, > > It looks like FreeRDP was not setting a purpose when checking the > certificate, causing this issue. I added: > > X509_STORE_CTX_set_default(csc, "ssl_server"); > > before the call to > > if (X509_verify_cert(csc) == 1) > > and this seems to make it work. I don't know if this is a "good" way > to fix this, but I sent this information off to the maintainers of > FreeRDP - hopefully, they can "do it right". > > > > > > As far as our previous message, I was having some "communications > issues" the day I wrote that: > > >>> I tested using s_client, on both systems, with no options, with CAfile >>> pointing to the correct CA, and with CAfile pointing to the WRONG CA >>> file - the only time it failed was on the new version, with the wrong >>> file. (Results attached.) I guess the new version is better at checking >>> things. >> Perhaps you did not override CApath? And the default CApath succeeds >> with old, but not the new code? For meaningful tests you need to >> explicitly override both, and place just specific CA certs in CAfile, >> leaving CApath empty. > That is what I did, just not what I wrote! > >>> I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE, to the >>> empty directory and the CA file - did not help. >> I don't believe I suggested setting SSL_CERT_FILE to an empty >> directory, or an empty file. Though putting a freshly minted >> self-signed root that has never signed any certificates into CAfile, >> can be one test to check that your application fails when it should >> definitely fail. > I meant that I set SSL_CERT_DIR to an empty directory, and > SSL_CERT_FILE to the CA file. > >>> Then, I tested setting SSL_CERT_DIR to /var/lib/ca-certificates/openssl >>> (which seems to be the default, and did not change anything), and then >>> setting SSL_CERT_DIR to /var/lib/ca-certificates/pem/ - this made >>> FreeRDP happy with the certificate. >>> >>> I compared >>> Starfield_Root_Certificate_Authority_-_G2.pem in the openssl directory >>> on the two systems - they are a binary match. >> But they're not the same, only the encapsulated X.509 certificates >> are the same, but one is wrapped as a "trusted certificate" with a >> specific trust EKU. > I meant that > "/var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem" > is the same on OpenSUSE 42.3 and OpenSUSE 1.5.0 > >>> Then I compared the output of >>> >>> openssl x509 -in /var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text >>> and >>> openssl x509 -in /var/lib/ca-certificates/pem/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text >> That is, they are NOT the same. >> >>> The only difference is that the one from openssl ends with: >>> >>> Trusted Uses: >>> TLS Web Server Authentication >>> No Rejected Uses. >>> Alias: Starfield Root Certificate Authority - G2 >> Well, that's "auxiliary" trust data outside the certificate. It >> is part of a "TRUSTED CERTICATE" encapsulation of a CA certificate, >> and can be used to limit the "purpose" for which a certificate is >> valid. >> >> If your application does not specify "serverAuth" as the "purpose" >> being verified, then verification should fail. > This was the hint that helped me. > > > Thanks! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 26 19:00:45 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Nov 2018 14:00:45 -0500 Subject: [openssl-users] Problem with x509_verify_certificate In-Reply-To: References: <5d59c979-94aa-9ccf-cc19-37fa8112e0e6@k-h.us> <96536961-C59D-4EAD-A81D-424C28629244@dukhovni.org> <663e0d0f-a590-c52d-e87b-e02336a727eb@k-h.us> <5EE3448B-A095-4CE8-B845-8D258F0EB9F7@dukhovni.org> <97E1765C-68B9-4FCF-BDA3-5B9C1CC81380@dukhovni.org> <7ac3c94d-4d8a-d36e-d1af-d4b110b51aec@k-h.us> <20181121230406.GR4122@straasha.imrryr.org> <8f03b765-f2f4-bff8-20a9-d7f763b2ccd9@k-h.us> Message-ID: <43DDBA68-B226-4095-94D9-E78D5C414674@dukhovni.org> > On Nov 26, 2018, at 1:08 PM, Ken wrote: > > Is it "better" to use > > X509_STORE_CTX_set_default(csc, "ssl_server"); This does take care of all the niggly details, but see below... > or something more like > > purpose = X509_PURPOSE_SSL_SERVER; > verify_param = X509_STORE_CTX_get0_param(csc); > X509_VERIFY_PARAM_set_purpose(verify_param, purpose); > X509_verify_cert(csc) > > When we tried the second option, it did not make any difference. The comment in check_purpose() in crypto/x509/x509_vfy.c may prove illuminating: /* * For trusted certificates we want to see whether any auxiliary trust * settings trump the purpose constraints. * * This is complicated by the fact that the trust ordinals in * ctx->param->trust are entirely independent of the purpose ordinals in * ctx->param->purpose! * * What connects them is their mutual initialization via calls from * X509_STORE_CTX_set_default() into X509_VERIFY_PARAM_lookup() which sets * related values of both param->trust and param->purpose. It is however * typically possible to infer associated trust values from a purpose value * via the X509_PURPOSE API. * * Therefore, we can only check for trust overrides when the purpose we're * checking is the same as ctx->param->purpose and ctx->param->trust is * also set. */ The solution is to call: X509_STORE_CTX_set_purpose(csc, X509_PURPOSE_SSL_SERVER) which also takes care of all the "trust" bits. The separation between purpose values and trust values is rather obscure. Sorry about that. Most applications don't have to delve this deep. > When I added X509_STORE_CTX_set0_param(csc,verify_param); This is not valid, because you don't own the reference to verify_param, and so cannot "give it away". The object ends up freed. This is why Rust has a borrow-checker... Time to start rewriting OpenSSL in Rust. -- Viktor. From openssl-users at dukhovni.org Mon Nov 26 19:04:11 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Nov 2018 14:04:11 -0500 Subject: [openssl-users] Client CA list sending is also in TLS < 1.3 (RFC6066) In-Reply-To: References: Message-ID: <56F05F3D-16F4-4388-A86E-74282DA01CD9@dukhovni.org> > On Nov 26, 2018, at 11:33 AM, Jakob Bohm via openssl-users wrote: > > In TLS 1.2 and older it was an extension "Trusted CA Indication" (3), > defined in RFC6066 Chapter 6. > > So I would suggest that any OpenSSL API to control that feature in > TLS 1.3 also affects the matching TLS < 1.3 functionality, and is > separated from the APIs that control the TLS server sending a list > of client certificate CAs to clients. > > This aspect was somehow missed in a recent discussion of this TLS 1.3 > behavior (which I cannot find right now). Thanks for the update. I guess OpenSSL never implemented RFC6066. I am not sure that support this in TLS 1.2 is worth adding, but you have a valid of principle. If it were added, it should use the same API that supports the equivalent feature in TLS 1.3 in OpenSSL 1.1.1a. -- Viktor. From jb-openssl at wisemo.com Mon Nov 26 19:15:31 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 26 Nov 2018 20:15:31 +0100 Subject: [openssl-users] Client CA list sending is also in TLS < 1.3 (RFC6066) In-Reply-To: <56F05F3D-16F4-4388-A86E-74282DA01CD9@dukhovni.org> References: <56F05F3D-16F4-4388-A86E-74282DA01CD9@dukhovni.org> Message-ID: <14ad38f9-8433-cdde-c238-8453075b4553@wisemo.com> On 26/11/2018 20:04, Viktor Dukhovni wrote: >> On Nov 26, 2018, at 11:33 AM, Jakob Bohm via openssl-users wrote: >> >> In TLS 1.2 and older it was an extension "Trusted CA Indication" (3), >> defined in RFC6066 Chapter 6. >> >> So I would suggest that any OpenSSL API to control that feature in >> TLS 1.3 also affects the matching TLS < 1.3 functionality, and is >> separated from the APIs that control the TLS server sending a list >> of client certificate CAs to clients. >> >> This aspect was somehow missed in a recent discussion of this TLS 1.3 >> behavior (which I cannot find right now). > Thanks for the update. I guess OpenSSL never implemented RFC6066. > I am not sure that support this in TLS 1.2 is worth adding, but you > have a valid of principle. If it were added, it should use the same > API that supports the equivalent feature in TLS 1.3 in OpenSSL 1.1.1a. > Just to clarify: RFC6066 is the main RFC for basic TLS extensions, with chapters defining such things as SNI, and OCSP stapling. 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 From eyal at motorolasolutions.com Tue Nov 27 10:50:45 2018 From: eyal at motorolasolutions.com (EYAL INBAR) Date: Tue, 27 Nov 2018 12:50:45 +0200 Subject: [openssl-users] Error: does not have a number assigned Message-ID: Hello I try to add API,CMP_build_KUR_req, to crypto lib and get Error: CMP_build_KUR_req does not have a number assigned Any suggestion? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Nov 27 11:09:14 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 27 Nov 2018 12:09:14 +0100 Subject: [openssl-users] Error: does not have a number assigned In-Reply-To: References: Message-ID: <63a4fb04-b973-c1de-465a-d7938b4e9d88@wisemo.com> On 27/11/2018 11:50, EYAL INBAR wrote: > Hello > > I try to add API,CMP_build_KUR_req, to crypto lib and get > > Error: CMP_build_KUR_req does not have a number assigned > > Any suggestion? This means you are compiling for a platform (probably Windows or OS/2) where names exported from DLLs are assigned unique numbers for fast lookup during application load. There is a source file in OpenSSL giving the assigned numbers. You will need to add numbers for you additional exports, and deal with the risk that a future OpenSSL release uses that number for something else. 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 From ca+ssl-users at esmtp.org Tue Nov 27 12:11:06 2018 From: ca+ssl-users at esmtp.org (Claus Assmann) Date: Tue, 27 Nov 2018 04:11:06 -0800 Subject: [openssl-users] 1.1.1a: crash in CRYPTO_THREAD_lock_free Message-ID: <20181127121106.GA27130@x2.esmtp.org> I'm trying OpenSSL 1.1.1a on FreeBSD 11.2-RELEASE-p4 and got the following crash in one of my test programs (I compiled OpenSSL with -g after the first time this happened to get at least some debug info): #0 __je_huge_salloc (tsdn=, ptr=) at extent.h:114 #1 0x000000080122d01e in ifree (tsd=) at arena.h:141468 #2 0x000000080122d5b1 in __free (ptr=0x800000000) at tsd.h:716 #3 0x0000000801535abb in _pthread_rwlock_destroy (rwlock=) 4at /usr/src/lib/libthr/thread/thr_rwlock.c:127 #4 0x0000000800e67c28 in CRYPTO_THREAD_lock_free (lock=0x801a27298) at crypto/threads_pthread.c:102 #5 0x0000000800dcb760 in EVP_PKEY_free (x=0x801a7b370) at crypto/evp/p_lib.c:601 #6 0x00000008008affce in ssl3_free (s=0x801bbd000) at ssl/s3_lib.c:3321 #7 0x0000000800904c91 in tls1_free (s=0x801bbd000) at ssl/t1_lib.c:115 #8 0x00000008008c085c in SSL_free (s=0x801bbd000) at ssl/ssl_lib.c:1204 #9 0x00000000004133d3 in sm_tlsbio_close (fp=0x6612e0, flags=0) at ../../mta/libmta/tlsbio.c:391 ... (gdb) p (pthread_rwlock_t)0x801a27298 $2 = (struct pthread_rwlock *) 0x801a27298 (gdb) p *$2 $3 = {lock = {rw_state = 1, rw_flags = 0, rw_blocked_readers = 1, rw_blocked_writers = 0, rw_spare = 0x801a272a8}, owner = 27402512} Since my program doesn't use pthreads, I compiled OpenSSL with no-threads and the crash doesn't happen (surprise...). Is this a bug in my application or in OpenSSL? I'm not sure how to debug this any further (without going into the details of pthreads on that OS). From Matthias.St.Pierre at ncp-e.com Tue Nov 27 12:38:51 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 27 Nov 2018 12:38:51 +0000 Subject: [openssl-users] Error: does not have a number assigned In-Reply-To: <63a4fb04-b973-c1de-465a-d7938b4e9d88@wisemo.com> References: <63a4fb04-b973-c1de-465a-d7938b4e9d88@wisemo.com> Message-ID: <19c7ed536b1e42e0ba2309a514825591@Ex13.ncp.local> Short version: Just do 'make update' and the numbers will be added automagically. Long version: There is a script, 'util/mkdef.pl', which gets invoked by 'make update'. It scans the header files for new APIs an updates the .num files (libcrypto.num/libeay.num and libssl.num) accordingly. For windows, it also updates the module definition files (*.def). So 'make update' will add your new API function. But be warned: As Jakob already mentioned, if you update OpenSSL it can happen that you get merge conflicts (if you use git) or your numbers will get overwritten (if you extract tarballs). You will have to renumber you symbols (or remove them and run 'make update' again). HTH, Matthias > -----Urspr?ngliche Nachricht----- > Von: openssl-users Im Auftrag von Jakob Bohm via openssl-users > Gesendet: Dienstag, 27. November 2018 12:09 > An: openssl-users at openssl.org > Betreff: Re: [openssl-users] Error: does not have a number assigned > > On 27/11/2018 11:50, EYAL INBAR wrote: > > Hello > > > > I try to add API,CMP_build_KUR_req, to crypto lib and get > > > > Error: CMP_build_KUR_req does not have a number assigned > > > > Any suggestion? > This means you are compiling for a platform (probably Windows > or OS/2) where names exported from DLLs are assigned unique > numbers for fast lookup during application load. > > There is a source file in OpenSSL giving the assigned numbers. > You will need to add numbers for you additional exports, and > deal with the risk that a future OpenSSL release uses that > number for something else. > > > 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 From openssl-users at dukhovni.org Tue Nov 27 14:58:21 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Nov 2018 09:58:21 -0500 Subject: [openssl-users] Error: does not have a number assigned In-Reply-To: <19c7ed536b1e42e0ba2309a514825591@Ex13.ncp.local> References: <63a4fb04-b973-c1de-465a-d7938b4e9d88@wisemo.com> <19c7ed536b1e42e0ba2309a514825591@Ex13.ncp.local> Message-ID: <72DD117E-7DF1-4301-9443-4777885F1128@dukhovni.org> > On Nov 27, 2018, at 7:38 AM, Dr. Matthias St. Pierre wrote: > > Short version: Just do 'make update' and the numbers will be added automagically. > > Long version: There is a script, 'util/mkdef.pl', which gets invoked by 'make update'. It scans the header files > for new APIs an updates the .num files (libcrypto.num/libeay.num and libssl.num) accordingly. For windows, > it also updates the module definition files (*.def). It might be prudent for the OP to assign a high value that OpenSSL will not likely ever reach. Start at 32767 and count down for site-local ordinals? -- Viktor. From Matthias.St.Pierre at ncp-e.com Tue Nov 27 15:28:37 2018 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 27 Nov 2018 16:28:37 +0100 Subject: [openssl-users] Error: does not have a number assigned In-Reply-To: <72DD117E-7DF1-4301-9443-4777885F1128@dukhovni.org> References: <63a4fb04-b973-c1de-465a-d7938b4e9d88@wisemo.com> <19c7ed536b1e42e0ba2309a514825591@Ex13.ncp.local> <72DD117E-7DF1-4301-9443-4777885F1128@dukhovni.org> Message-ID: Yes,?that?would?be?a?good?idea.?Although?it?does?not?prevent?merge?conflicts,?at?least?the?ordinals don't?have?to?be?renumbered?every?time.?(That's?the?way?we?solved?the?problem?in?our?company.) On 27.11.18 15:58, Viktor Dukhovni wrote: >> On Nov 27, 2018, at 7:38 AM, Dr. Matthias St. Pierre wrote: >> >> Short version: Just do 'make update' and the numbers will be added automagically. >> >> Long version: There is a script, 'util/mkdef.pl', which gets invoked by 'make update'. It scans the header files >> for new APIs an updates the .num files (libcrypto.num/libeay.num and libssl.num) accordingly. For windows, >> it also updates the module definition files (*.def). > It might be prudent for the OP to assign a high value that OpenSSL > will not likely ever reach. Start at 32767 and count down for site-local > ordinals? > From Michael.Wojcik at microfocus.com Tue Nov 27 18:55:35 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 27 Nov 2018 18:55:35 +0000 Subject: [openssl-users] error message oddity In-Reply-To: <5eea805b-b6af-806e-d092-21eb41e814b9@wisemo.com> References: <634b4563-cf96-040f-e52e-ded1c322d55b@wizmail.org> <863faf43-05e8-f38e-b596-5afe38b4b484@wizmail.org> <51F32323-D200-4176-8B76-84D514E7D9E3@dukhovni.org>, <5eea805b-b6af-806e-d092-21eb41e814b9@wisemo.com> Message-ID: You might want to check what strerror_r gives you, rather than strerror, since on GCC platforms that's what OpenSSL uses. Also, OpenSSL builds its table of error strings at startup (or, for older versions, when you tell it to). It's conceivable an application's NLS settings changed between the time when OpenSSL built its table and the time when the error occurred, which could result in different text from OpenSSL and from a strerror or strerror_r at the point of failure. ________________________________ From: openssl-users on behalf of Jakob Bohm via openssl-users Sent: Monday, November 26, 2018 11:13:35 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] error message oddity On 25/11/2018 22:30, Viktor Dukhovni wrote: >> On Nov 25, 2018, at 4:23 PM, Jeremy Harris wrote: >> >> That isn't the package name, it is text defined in openssl/opensslv.h > That happens when "OPENSSL_FIPS" is defined: > > # define OPENSSL_VERSION_NUMBER 0x101000b0L > # ifdef OPENSSL_FIPS > # define OPENSSL_VERSION_TEXT "OpenSSL 1.1.0k-fips-dev xx XXX xxxx" > # else > # define OPENSSL_VERSION_TEXT "OpenSSL 1.1.0k-dev xx XXX xxxx" > # endif > > Given no FIPS for 1.1.x, perhaps that "#ifdef" should be "#if 0". With > 1.1.x the "Configure" arguments should not mention "fips". > A better solution would be to have a separate part of the 1.1.0/1.1.1 headers error out hard (with #error) if attempting to build with OPENSSL_FIPS defined. This would preserve all the FIPS-related stuff (such as the above version naming code) for when a FIPS module for 1.1.x is provided, while leaving the blocking of accidental miscompilation in a clear location having no other effects. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Nov 27 22:47:51 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Nov 2018 17:47:51 -0500 Subject: [openssl-users] 1.1.1a: crash in CRYPTO_THREAD_lock_free In-Reply-To: <20181127121106.GA27130@x2.esmtp.org> References: <20181127121106.GA27130@x2.esmtp.org> Message-ID: <20181127224751.GX4122@straasha.imrryr.org> On Tue, Nov 27, 2018 at 04:11:06AM -0800, Claus Assmann wrote: > I'm trying OpenSSL 1.1.1a on FreeBSD 11.2-RELEASE-p4 and got the following > crash in one of my test programs (I compiled OpenSSL with -g after the > first time this happened to get at least some debug info): > > #0 __je_huge_salloc (tsdn=, ptr=) at extent.h:114 > #1 0x000000080122d01e in ifree (tsd=) at arena.h:141468 > #2 0x000000080122d5b1 in __free (ptr=0x800000000) at tsd.h:716 > #3 0x0000000801535abb in _pthread_rwlock_destroy (rwlock=) > 4at /usr/src/lib/libthr/thread/thr_rwlock.c:127 > #4 0x0000000800e67c28 in CRYPTO_THREAD_lock_free (lock=0x801a27298) at crypto/threads_pthread.c:102 > #5 0x0000000800dcb760 in EVP_PKEY_free (x=0x801a7b370) at crypto/evp/p_lib.c:601 > #6 0x00000008008affce in ssl3_free (s=0x801bbd000) at ssl/s3_lib.c:3321 > #7 0x0000000800904c91 in tls1_free (s=0x801bbd000) at ssl/t1_lib.c:115 > #8 0x00000008008c085c in SSL_free (s=0x801bbd000) at ssl/ssl_lib.c:1204 > #9 0x00000000004133d3 in sm_tlsbio_close (fp=0x6612e0, flags=0) at ../../mta/libmta/tlsbio.c:391 > ... > (gdb) p (pthread_rwlock_t)0x801a27298 > $2 = (struct pthread_rwlock *) 0x801a27298 > (gdb) p *$2 > $3 = {lock = {rw_state = 1, rw_flags = 0, rw_blocked_readers = 1, rw_blocked_writers = 0, rw_spare = 0x801a272a8}, > owner = 27402512} I also use FreeBSD 11.2-RELEASE-p4, and have a /usr/src tree: 110 int 111 _pthread_rwlock_destroy (pthread_rwlock_t *rwlock) 112 { 113 pthread_rwlock_t prwlock; 114 int ret; 115 116 prwlock = *rwlock; 117 if (prwlock == THR_RWLOCK_INITIALIZER) 118 ret = 0; 119 else if (prwlock == THR_RWLOCK_DESTROYED) 120 ret = EINVAL; 121 else if (prwlock == THR_PSHARED_PTR) { 122 *rwlock = THR_RWLOCK_DESTROYED; 123 __thr_pshared_destroy(rwlock); 124 ret = 0; 125 } else { 126 *rwlock = THR_RWLOCK_DESTROYED; 127 free(prwlock); 128 ret = 0; 129 } 130 return (ret); 131 } The first thing to note is that the function tkaes a *pointer* to a pthread_rwlock_t, but the thing pointed to is itself a pointer. It has three "magic" values, and otherwise points to allocated storage, freed on line 127 (matching your stack trace). The magic values are: #define THR_RWLOCK_INITIALIZER ((struct pthread_rwlock *)NULL) #define THR_RWLOCK_DESTROYED ((struct pthread_rwlock *)1) #define THR_PSHARED_PTR \ ((void *)(uintptr_t)((1ULL << (NBBY * sizeof(long) - 1)) | 1)) But I think that your gdb commands to display the object are not right. We have lock = (pthread_rwlock_t *)0x801a27298 *lock = prwlock = (struct pthread_rwlock_t *) 0x80000000 So you'd need to look at (**lock) not (*lock) to see the underlying structure, but the address may be invalid. I don't know how it came to be 0x800000000 (2^35)... I seems that something zeroed the low 32 bits of the pointer. More interesting that the lock might be the content of the EVP_PKEY in frame #5: #5 0x0000000800dcb760 in EVP_PKEY_free (x=0x801a7b370) at crypto/evp/p_lib.c:601 p ((struct evp_pkey_st *)0x801a7b370)[0] Knowing what type of key this is might help to narrow the search. -- Viktor. From eyal at motorolasolutions.com Wed Nov 28 06:43:40 2018 From: eyal at motorolasolutions.com (EYAL INBAR) Date: Wed, 28 Nov 2018 08:43:40 +0200 Subject: [openssl-users] Error: does not have a number assigned In-Reply-To: References: <63a4fb04-b973-c1de-465a-d7938b4e9d88@wisemo.com> <19c7ed536b1e42e0ba2309a514825591@Ex13.ncp.local> <72DD117E-7DF1-4301-9443-4777885F1128@dukhovni.org> Message-ID: Thanks I add my functions to libcrypto.num at the end (32767 ,32766 ) as your suggestions. On Tue, Nov 27, 2018 at 5:28 PM Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > > Yes, that would be a good idea. Although it does not prevent merge conflicts, at least the ordinals > > don't have to be renumbered every time. (That's the way we solved the problem in our company.) > > On 27.11.18 15:58, Viktor Dukhovni wrote: > >> On Nov 27, 2018, at 7:38 AM, Dr. Matthias St. Pierre < > Matthias.St.Pierre at ncp-e.com> wrote: > >> > >> Short version: Just do 'make update' and the numbers will be added > automagically. > >> > >> Long version: There is a script, 'util/mkdef.pl', which gets invoked > by 'make update'. It scans the header files > >> for new APIs an updates the .num files (libcrypto.num/libeay.num and > libssl.num) accordingly. For windows, > >> it also updates the module definition files (*.def). > > It might be prudent for the OP to assign a high value that OpenSSL > > will not likely ever reach. Start at 32767 and count down for site-local > > ordinals? > > > > -- > openssl-users mailing list > To unsubscribe: > https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=I5-3pNwF1_nDoDkHWrLqDas1-D3ePObax4DniWovRNU&m=67uowHFQMvna-mV7bC97t3qPXNwPn3yAfoRq4pf7CBM&s=GhNc-o-KYTetX1mheDmt0ub7ilPFP5zqZujEznqQo-o&e= > -------------- next part -------------- An HTML attachment was scrubbed... URL: From win_i008 at yahoo.com Wed Nov 28 09:06:55 2018 From: win_i008 at yahoo.com (Vinay Kumar) Date: Wed, 28 Nov 2018 09:06:55 +0000 (UTC) Subject: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library References: <913007751.142742.1543396015968.ref@mail.yahoo.com> Message-ID: <913007751.142742.1543396015968@mail.yahoo.com> Hi All, The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope GSCheck on Windows. E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the following modules for which a language could not be identified. Ensure these were compiled with debug information and run BinScope again: aes-586.obj aesni-x86.obj bf-586.obj bn-586.obj chacha-x86.obj cmll-x86.obj co-586.obj crypt586.obj des-586.obj ecp_nistz256-x86.obj ghash-x86.obj md5-586.obj poly1305-x86.obj rc4-586.obj rmd-586.obj sha1-586.obj sha256-586.obj sha512-586.obj vpaes-x86.obj wp-mmx.obj x86-gf2m.obj x86-mont.obj x86cpuid.obj Any idea on how to resolve this problem or is it expected behavior. NOTE: 1. Adding /GS flag and enabling debug mode did not resolve the problem. 2. The same works fine with 64bit Windows 'libeay32.dll' 3. For other OpenSSL library '?libssl32.dll', GSCheck passes for both 32bit and 64bit. Regards, Vinay -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.fuchs at sit.fraunhofer.de Wed Nov 28 09:15:57 2018 From: andreas.fuchs at sit.fraunhofer.de (Fuchs, Andreas) Date: Wed, 28 Nov 2018 09:15:57 +0000 Subject: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID Message-ID: <9F48E1A823B03B4790B7E6E69430724D014B459655@exch2010c.sit.fraunhofer.de> Hi all, I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg. Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31 Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this. Thus: Is the following approach correct ? So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328: - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ? - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ? - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ? - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ? - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ? Thanks a lot for any advice, Andreas From aerowolf at gmail.com Wed Nov 28 09:36:40 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Wed, 28 Nov 2018 01:36:40 -0800 Subject: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library In-Reply-To: <913007751.142742.1543396015968@mail.yahoo.com> References: <913007751.142742.1543396015968.ref@mail.yahoo.com> <913007751.142742.1543396015968@mail.yahoo.com> Message-ID: I thibk those are all the .asm modules. If they are, you'll probably want to Configure with no-asm and rebuild in order to get the C implementations. -Kyle H On Wed, Nov 28, 2018, 01:07 Vinay Kumar via openssl-users < openssl-users at openssl.org wrote: > Hi All, > > The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope > GSCheck on Windows. > > E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the > following modules for which a language could not be identified. Ensure > these were compiled with debug information and run BinScope again: > aes-586.obj > aesni-x86.obj > bf-586.obj > bn-586.obj > chacha-x86.obj > cmll-x86.obj > co-586.obj > crypt586.obj > des-586.obj > ecp_nistz256-x86.obj > ghash-x86.obj > md5-586.obj > poly1305-x86.obj > rc4-586.obj > rmd-586.obj > sha1-586.obj > sha256-586.obj > sha512-586.obj > vpaes-x86.obj > wp-mmx.obj > x86-gf2m.obj > x86-mont.obj > x86cpuid.obj > > Any idea on how to resolve this problem or is it expected behavior. > > NOTE: > 1. Adding /GS flag and enabling debug mode did not resolve the problem. > 2. The same works fine with 64bit Windows 'libeay32.dll' > 3. For other OpenSSL library ' libssl32.dll', GSCheck passes for both > 32bit and 64bit. > > > Regards, > Vinay > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angus at magsys.co.uk Wed Nov 28 09:56:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Wed, 28 Nov 2018 09:56 +0000 (GMT Standard Time) Subject: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library In-Reply-To: <913007751.142742.1543396015968@mail.yahoo.com> Message-ID: > The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for > binscope GSCheck on Windows. This must be a customised non-standard library, since 1.1.0 does not build with that name, but as libcrypto-1_1.dll. Angus From jb-openssl at wisemo.com Wed Nov 28 12:50:45 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 28 Nov 2018 13:50:45 +0100 Subject: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library In-Reply-To: <913007751.142742.1543396015968@mail.yahoo.com> References: <913007751.142742.1543396015968.ref@mail.yahoo.com> <913007751.142742.1543396015968@mail.yahoo.com> Message-ID: If GSCheck is just a tool to check if you remembered to build code with the buffer overflow checks that Microsoft C can insert, then you should just treat this as a warning that the tool doesn't know how to check code from other compilers (in this case the manual work of the OpenSSL team). On 28/11/2018 10:06, Vinay Kumar via openssl-users wrote: > Hi All, > > The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope > GSCheck on Windows. > > E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the > following modules for which a language could not be identified. Ensure > these were compiled with debug information and run BinScope again: > aes-586.obj > aesni-x86.obj > bf-586.obj > bn-586.obj > chacha-x86.obj > cmll-x86.obj > co-586.obj > crypt586.obj > des-586.obj > ecp_nistz256-x86.obj > ghash-x86.obj > md5-586.obj > poly1305-x86.obj > rc4-586.obj > rmd-586.obj > sha1-586.obj > sha256-586.obj > sha512-586.obj > vpaes-x86.obj > wp-mmx.obj > x86-gf2m.obj > x86-mont.obj > x86cpuid.obj > > Any idea on how to resolve this problem or is it expected behavior. > > NOTE: > 1. Adding /GS flag and enabling debug mode did not resolve the problem. > 2. The same works fine with 64bit Windows 'libeay32.dll' > 3. For other OpenSSL library 'libssl32.dll', GSCheck passes for both > 32bit and 64bit. 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 From matt at openssl.org Wed Nov 28 17:02:40 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 28 Nov 2018 17:02:40 +0000 Subject: [openssl-users] OpenSSL Versioning and License Message-ID: <40643fa8-321f-a85d-3484-13bb1be8aa0e@openssl.org> Please see the following blog post about OpenSSL Versioning and License: https://www.openssl.org/blog/blog/2018/11/28/version/ Matt From jifl at eCosCentric.com Wed Nov 28 19:54:34 2018 From: jifl at eCosCentric.com (Jonathan Larmour) Date: Wed, 28 Nov 2018 19:54:34 +0000 Subject: [openssl-users] [openssl-announce] OpenSSL Versioning and License In-Reply-To: <40643fa8-321f-a85d-3484-13bb1be8aa0e@openssl.org> References: <40643fa8-321f-a85d-3484-13bb1be8aa0e@openssl.org> Message-ID: <5BFEF27A.6080906@eCosCentric.com> On 28/11/18 17:02, Matt Caswell wrote: > Please see the following blog post about OpenSSL Versioning and License: > > https://www.openssl.org/blog/blog/2018/11/28/version/ :-( The Apache license is incompatible with GPLv2: https://www.apache.org/licenses/GPL-compatibility.html Those of us using GPLv2 code in products will no longer be able to use OpenSSL. For many of us, GPLv3 is not an option. What about dual licensing? Jifl From jgh at wizmail.org Wed Nov 28 20:48:10 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Wed, 28 Nov 2018 20:48:10 +0000 Subject: [openssl-users] SNI callback Message-ID: <127e03f1-9b88-f51f-c099-7a3f668c71fa@wizmail.org> OpenSSL 1.1.1 FIPS 11 Sep 2018 RHEL 8.0 beta Using SSL_CTX_set_tlsext_servername_callback() when the called routine returns SSL_TLSEXT_ERR_NOACK I was expecting the handshake to fail. It carries on; am I doing something wrong? -- Thanks, Jeremy From bkaduk at akamai.com Wed Nov 28 21:03:10 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 28 Nov 2018 15:03:10 -0600 Subject: [openssl-users] SNI callback In-Reply-To: <127e03f1-9b88-f51f-c099-7a3f668c71fa@wizmail.org> References: <127e03f1-9b88-f51f-c099-7a3f668c71fa@wizmail.org> Message-ID: <20181128210310.GB13623@akamai.com> On Wed, Nov 28, 2018 at 08:48:10PM +0000, Jeremy Harris wrote: > OpenSSL 1.1.1 FIPS 11 Sep 2018 > RHEL 8.0 beta > > Using SSL_CTX_set_tlsext_servername_callback() > when the called routine returns SSL_TLSEXT_ERR_NOACK > I was expecting the handshake to fail. It carries > on; am I doing something wrong? NOACK is basically "pretend that there wasn't a callback here"; you should probably use SSL_TLSEXT_ERR_ALERT_FATAL to abort the connection if you want the handshake to fail. -Ben From jgh at wizmail.org Wed Nov 28 21:20:09 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Wed, 28 Nov 2018 21:20:09 +0000 Subject: [openssl-users] SNI callback In-Reply-To: <20181128210310.GB13623@akamai.com> References: <127e03f1-9b88-f51f-c099-7a3f668c71fa@wizmail.org> <20181128210310.GB13623@akamai.com> Message-ID: On 28/11/2018 21:03, Benjamin Kaduk via openssl-users wrote: > On Wed, Nov 28, 2018 at 08:48:10PM +0000, Jeremy Harris wrote: >> OpenSSL 1.1.1 FIPS 11 Sep 2018 >> RHEL 8.0 beta >> >> Using SSL_CTX_set_tlsext_servername_callback() >> when the called routine returns SSL_TLSEXT_ERR_NOACK >> I was expecting the handshake to fail. It carries >> on; am I doing something wrong? > > NOACK is basically "pretend that there wasn't a callback here"; > you should probably use SSL_TLSEXT_ERR_ALERT_FATAL to abort the > connection if you want the handshake to fail. Gotcha. - Thanks From mhirkhan.17 at gmail.com Wed Nov 28 21:50:16 2018 From: mhirkhan.17 at gmail.com (mhirkhan.17) Date: Thu, 29 Nov 2018 03:20:16 +0530 Subject: [openssl-users] Mail Message-ID: <5bff0da0.1c69fb81.9889b.bd3b@mx.google.com> Sent from my Samsung Galaxy smartphone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Nov 28 22:18:04 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Nov 2018 17:18:04 -0500 Subject: [openssl-users] SNI callback In-Reply-To: <127e03f1-9b88-f51f-c099-7a3f668c71fa@wizmail.org> References: <127e03f1-9b88-f51f-c099-7a3f668c71fa@wizmail.org> Message-ID: <99A208C6-5174-4C33-802A-BD0979CB5A64@dukhovni.org> > On Nov 28, 2018, at 3:48 PM, Jeremy Harris wrote: > > Using SSL_CTX_set_tlsext_servername_callback() > when the called routine returns SSL_TLSEXT_ERR_NOACK > I was expecting the handshake to fail. It carries > on; am I doing something wrong? For an SMTP server, SNI values that don't match are not unexpected, given that e.g. with DANE the DANE-aware clients will send the TLSA base domain, while non-DANE clients will send the original MX hostname, which may be different. So while it is interesting to test failing on SNI mismatch, please DO NOT fail handshakes on SNI mismatch in SMTP. -- Viktor. From dkg at fifthhorseman.net Wed Nov 28 21:41:40 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Nov 2018 16:41:40 -0500 Subject: [openssl-users] [openssl-announce] OpenSSL Versioning and License In-Reply-To: <5BFEF27A.6080906@eCosCentric.com> References: <40643fa8-321f-a85d-3484-13bb1be8aa0e@openssl.org> <5BFEF27A.6080906@eCosCentric.com> Message-ID: <87y39cyj57.fsf@fifthhorseman.net> On Wed 2018-11-28 19:54:34 +0000, Jonathan Larmour wrote: > On 28/11/18 17:02, Matt Caswell wrote: >> Please see the following blog post about OpenSSL Versioning and License: >> >> https://www.openssl.org/blog/blog/2018/11/28/version/ > > :-( > > The Apache license is incompatible with GPLv2: > > https://www.apache.org/licenses/GPL-compatibility.html > > Those of us using GPLv2 code in products will no longer be able to use > OpenSSL. For many of us, GPLv3 is not an option. The existing OpenSSL license is arguably incompatible with GPLv2 anyway, in some analyses: https://people.gnome.org/~markmc/openssl-and-the-gpl.html so the move to apache2 appears to be an overall loosening of restrictions, not making things worse (the older license was incompatible with even GPLv3 also, yuck). So it's an improvement over the current state of play, no? That said, I also would have liked something that is GPLv2-compatible in addition to GPLv3-compatible. --dkg From jifl at eCosCentric.com Wed Nov 28 22:42:44 2018 From: jifl at eCosCentric.com (Jonathan Larmour) Date: Wed, 28 Nov 2018 22:42:44 +0000 Subject: [openssl-users] [openssl-announce] OpenSSL Versioning and License In-Reply-To: <87y39cyj57.fsf@fifthhorseman.net> References: <40643fa8-321f-a85d-3484-13bb1be8aa0e@openssl.org> <5BFEF27A.6080906@eCosCentric.com> <87y39cyj57.fsf@fifthhorseman.net> Message-ID: <5BFF19E4.4040400@eCosCentric.com> On 28/11/18 21:41, Daniel Kahn Gillmor wrote: > On Wed 2018-11-28 19:54:34 +0000, Jonathan Larmour wrote: >> On 28/11/18 17:02, Matt Caswell wrote: >>> Please see the following blog post about OpenSSL Versioning and License: >>> >>> https://www.openssl.org/blog/blog/2018/11/28/version/ >> >> :-( >> >> The Apache license is incompatible with GPLv2: >> >> https://www.apache.org/licenses/GPL-compatibility.html >> >> Those of us using GPLv2 code in products will no longer be able to use >> OpenSSL. For many of us, GPLv3 is not an option. > > The existing OpenSSL license is arguably incompatible with GPLv2 anyway, > in some analyses: > > https://people.gnome.org/~markmc/openssl-and-the-gpl.html Yes I believe any GPLv2 users have been relying on a license exception. I'm not sure the license exception in the GPL software I'm using would be sufficient if calls to OpenSSL are made from the GPL'd code: "As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License.[...]" If my own (non-GPL) code calls OpenSSL, that seems fine. But what if I have modified the GPL'd (with exception) code to call OpenSSL? > That said, I also would have liked something that is GPLv2-compatible in > addition to GPLv3-compatible. Yes, that would have made things unambiguous. Jifl From rsalz at akamai.com Wed Nov 28 23:13:30 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Nov 2018 23:13:30 +0000 Subject: [openssl-users] [openssl-announce] OpenSSL Versioning and License In-Reply-To: <5BFF19E4.4040400@eCosCentric.com> References: <40643fa8-321f-a85d-3484-13bb1be8aa0e@openssl.org> <5BFEF27A.6080906@eCosCentric.com> <87y39cyj57.fsf@fifthhorseman.net> <5BFF19E4.4040400@eCosCentric.com> Message-ID: <23218D73-B9D5-4D91-9E01-95915F0B7A09@akamai.com> This was discussed around when OpenSSL first talked about the project. You might find it worth reading the various blog entries (and comment/responses) https://www.openssl.org/blog/blog/categories/license/ One thing to note is that cryptography can be a patent minefield, and the patent protections in the Apache license were important to the project at the time we decided which license to move to. Not everyone will be happy, and we knew that at the time. Overall, however, we felt that this was the best way to go. /r$, not a member of the project any more From ca+ssl-users at esmtp.org Wed Nov 28 23:31:17 2018 From: ca+ssl-users at esmtp.org (Claus Assmann) Date: Wed, 28 Nov 2018 15:31:17 -0800 Subject: [openssl-users] 1.1.1a: crash in CRYPTO_THREAD_lock_free In-Reply-To: <20181127224751.GX4122@straasha.imrryr.org> References: <20181127121106.GA27130@x2.esmtp.org> <20181127224751.GX4122@straasha.imrryr.org> Message-ID: <20181128233117.GA31434@x2.esmtp.org> Thanks for the reply, it helped me adding some more debugging statements to various places to track down the problem: it is due to a change in TLS session handling in TLSv1.3. It seems there are multiple SSL_SESSION structures for a single SSL connection (SMTP session). The callback installed using SSL_CTX_sess_set_new_cb() was called twice for the same SSL connection and the code was written to handle only one callback per connection. This resulted in a "use after free" situation. Sorry for the false alarm. From openssl-users at dukhovni.org Wed Nov 28 23:54:55 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Nov 2018 18:54:55 -0500 Subject: [openssl-users] 1.1.1a: crash in CRYPTO_THREAD_lock_free In-Reply-To: <20181128233117.GA31434@x2.esmtp.org> References: <20181127121106.GA27130@x2.esmtp.org> <20181127224751.GX4122@straasha.imrryr.org> <20181128233117.GA31434@x2.esmtp.org> Message-ID: > On Nov 28, 2018, at 6:31 PM, Claus Assmann wrote: > > Thanks for the reply, it helped me adding some more debugging > statements to various places to track down the problem: > it is due to a change in TLS session handling in TLSv1.3. Thanks for following up, much appreciated. > It seems there are multiple SSL_SESSION structures for a single SSL > connection (SMTP session). The callback installed using > SSL_CTX_sess_set_new_cb() was called twice for the same SSL connection > and the code was written to handle only one callback per connection. Yes, by default the OpenSSL library now issues two session tickets for each full (non-resumed handshake), and a new session ticket after each resumption. Recent versions of the Postfix SMTP server, when linked against OpenSSL 1.1.1 ask the library to issue just one session ticket after a full handshake: https://github.com/vdukhovni/postfix/blame/postfix-3.3/postfix/src/tls/tls_server.c#L507-L521 and none on resumption if the current ticket is still valid (existing code from Postfix 2.11, which implements session ticket key sharing and rotation for a pool of Postfix SMTP servers on a single host): https://github.com/vdukhovni/postfix/blame/postfix-3.3/postfix/src/tls/tls_server.c#L507-L521 Linkability of sessions is not in my view a concern for SMTP, and SMTP clients either don't cache session tickets at all, or cache at most one, so issuing two initially and avoiding re-use is largely wasteful. > This resulted in a "use after free" situation. Sorry for the false > alarm. Makes sense. I did look briefly for potential issues in the library, that matched your stack trace (freeing the peer's DH public key), but did not find any smoking gun. I might however add belt-and-suspenders safety in one code path were I think that the current safe behaviour could prove fragile as the code evolves. So it has not been entirely unproductive. -- Viktor. From jb-openssl at wisemo.com Thu Nov 29 16:22:19 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 29 Nov 2018 17:22:19 +0100 Subject: [openssl-users] [openssl-announce] OpenSSL Versioning and License In-Reply-To: <5BFF19E4.4040400@eCosCentric.com> References: <40643fa8-321f-a85d-3484-13bb1be8aa0e@openssl.org> <5BFEF27A.6080906@eCosCentric.com> <87y39cyj57.fsf@fifthhorseman.net> <5BFF19E4.4040400@eCosCentric.com> Message-ID: On 28/11/2018 23:42, Jonathan Larmour wrote: > On 28/11/18 21:41, Daniel Kahn Gillmor wrote: >> On Wed 2018-11-28 19:54:34 +0000, Jonathan Larmour wrote: >>> On 28/11/18 17:02, Matt Caswell wrote: >>>> Please see the following blog post about OpenSSL Versioning and License: >>>> >>>> https://www.openssl.org/blog/blog/2018/11/28/version/ >>> :-( >>> >>> The Apache license is incompatible with GPLv2: >>> >>> https://www.apache.org/licenses/GPL-compatibility.html >>> >>> Those of us using GPLv2 code in products will no longer be able to use >>> OpenSSL. For many of us, GPLv3 is not an option. >> The existing OpenSSL license is arguably incompatible with GPLv2 anyway, >> in some analyses: >> >> https://people.gnome.org/~markmc/openssl-and-the-gpl.html > Yes I believe any GPLv2 users have been relying on a license exception. I'm > not sure the license exception in the GPL software I'm using would be > sufficient if calls to OpenSSL are made from the GPL'd code: > > "As a special exception, if other files instantiate templates or use macros or > inline functions from this file, or you compile this file and link it with > other works to produce a work based on this file, this file does not by itself > cause the resulting work to be covered by the GNU General Public License.[...]" > > If my own (non-GPL) code calls OpenSSL, that seems fine. But what if I have > modified the GPL'd (with exception) code to call OpenSSL? That's not the exception used for OpenSSL using software, that looks more like the exception used when some software that should have been LGPL was annoyingly marked as GPL instead. The OpenSSL exceptions exist in very specific software packages and mention "OpenSSL" or "The OpenSSL license" by name.? The problem (besides such an exception only applying if all the used GPL code has it) is that such an exception, depending on its wording, might not apply to an Apache-licensed OpenSSL, and it may be very hard to track down every GPL copyright holder and get them to sign off on a reworded exception that doesn't extend to other large Apache-licensed code bases. Another exception sometimes used is the "OS exception" (in the text of GPLv2 itself) applies only to an OS-bundled copy of OpenSSL, and only if the GPLv2 code is not bundled with the OS.? For example if using the specific builds of OpenSSL distributed by Debian and RedHat, a GPLv2 program not packaged by those systems can use that specific version of OpenSSL. >> That said, I also would have liked something that is GPLv2-compatible in >> addition to GPLv3-compatible. > Yes, that would have made things unambiguous. > > Jifl > 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 From mksarav at gmail.com Fri Nov 30 05:26:21 2018 From: mksarav at gmail.com (M K Saravanan) Date: Fri, 30 Nov 2018 13:26:21 +0800 Subject: [openssl-users] What is the need for 0x00 byte prefix in pubkey and prime of a static DH key pair? Message-ID: Hi, When I create static DH key pair using openssl, why the public key and prime contains the prefix 0x00 byte? For e.g. in 1024 bit key, 128 bytes is enough. private key properly shows 128 bytes. But public key and prime shows 129 bytes with a 0x00 byte at the beginning. What is the need for this 0x00 byte at the beginning? i.e. why it is using 129 bytes instead of 128? $ openssl version OpenSSL 1.1.1 11 Sep 2018 $ openssl dhparam -out mydhp.pem 1024 [...] $ openssl genpkey -paramfile ./mydhp.pem -out mydhkey.pem $ openssl pkey -in ./mydhkey.pem -text -noout DH Private-Key: (1024 bit) private-key: 52:61:87:52:b4:27:5f:c3:cf:ab:2f:20:b4:aa:b7: df:c3:87:63:50:d2:06:dd:65:8f:db:55:2e:08:d5: 62:44:1a:f5:d8:73:66:fe:a7:c4:43:be:f7:f0:d0: ba:4c:bf:f0:70:70:c9:25:92:da:ef:69:01:1a:b9: d9:d9:1f:b9:22:a6:84:48:d8:58:a8:a4:9e:7f:85: 6b:9e:45:89:07:0c:fb:00:f1:0a:fb:24:10:e4:bb: 2b:1c:7d:dc:d1:12:a3:21:5a:9b:8e:bf:9d:33:e8: 65:fe:c2:5c:ea:47:fa:00:04:80:cf:85:e1:c6:71: 67:4b:7b:71:92:07:59:48 public-key: 00:a0:0d:41:8a:27:55:07:2a:01:dd:a7:e2:86:bb: 69:71:86:1d:62:0c:f3:b7:61:78:81:37:6c:a1:d3: e8:55:9d:8a:1f:e8:5e:7f:18:00:0f:4e:1d:97:70: a0:e7:19:2b:82:69:c3:aa:61:ea:b8:9c:10:36:19: e9:b9:13:db:9a:ef:34:bf:10:f7:93:84:5d:a3:b4: 58:3a:40:ec:4b:79:06:52:b8:fe:b8:22:0d:f3:f9: 33:1e:8e:43:69:bb:77:3d:10:78:c6:65:e8:04:08: 96:1e:cc:6c:92:e4:55:f4:2c:d0:3d:b7:5f:58:70: cf:fe:a7:5f:23:e3:d9:5e:c4 prime: 00:a2:f4:9d:1c:3f:75:8f:3e:e3:c9:95:09:79:09: 16:f2:f0:61:c4:e1:b9:23:22:a3:58:d7:38:7d:06: af:57:ad:14:5e:13:bd:71:ed:31:89:cb:65:d6:46: 3b:29:57:ad:a9:8e:58:e6:df:c0:37:2f:4f:be:45: d7:c8:f1:87:ef:af:65:87:34:4a:7d:78:b8:0b:0b: 33:d8:c1:fb:05:9e:ce:9a:27:7e:4a:2a:aa:18:33: 35:ea:d0:b0:b7:fa:cb:d1:51:bf:11:98:12:24:be: 1d:1c:87:c3:37:ed:0f:b9:53:23:fc:a1:be:75:ed: 81:04:e5:6a:b3:83:40:e0:43 generator: 2 (0x2) with regards, Saravanan From rsalz at akamai.com Fri Nov 30 07:42:20 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 30 Nov 2018 07:42:20 +0000 Subject: [openssl-users] What is the need for 0x00 byte prefix in pubkey and prime of a static DH key pair? In-Reply-To: References: Message-ID: If the first byte has the high-bit set, then you have to put a leading-zero-byte so that it is not treated as a negative number. public-key: 00:a0:0d:41:8a:27:55:07:2a:01:dd:a7:e2:86:bb: ... prime: 00:a2:f4:9d:1c:3f:75:8f:3e:e3:c9:95:09:79:09: ... From matt at openssl.org Fri Nov 30 08:26:47 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 30 Nov 2018 08:26:47 +0000 Subject: [openssl-users] What is the need for 0x00 byte prefix in pubkey and prime of a static DH key pair? In-Reply-To: References: Message-ID: <8ef86237-4b09-1211-27d3-6e52c37bb6a7@openssl.org> On 30/11/2018 05:26, M K Saravanan wrote: > Hi, > > When I create static DH key pair using openssl, why the public key and > prime contains the prefix 0x00 byte? Because otherwise those numbers would be treated as negative (due to the most significant bit being set) which is incorrect. Matt From aerowolf at gmail.com Fri Nov 30 11:31:48 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Fri, 30 Nov 2018 03:31:48 -0800 Subject: [openssl-users] What is the need for 0x00 byte prefix in pubkey and prime of a static DH key pair? In-Reply-To: References: Message-ID: The DER (Distinguished Encoding Rules of ASN.1, which can be found in ITU-T recommendation X.680 and X.681) requirement is that if a particular number is positive, the highest-order bit can never be set (since the highest-order bit is always the negative sign indicator). The rules further explain that the appropriate way to encode a positive integer with the highest bit set is to add an additional 0x00 byte, making the new most significant bit into a 0. This is also why the serial number field in a certificate can be 21 bytes long, even when implementing PKIX's minimum serial number length of 20 bytes. Numbers included in an ASN.1-encoded structure aren't ever intended to be used directly, they're intended to be decoded before the data is passed back to client code. I realize this is much more information than you asked, but it might help to think of it as "it's done this way for compliance with the standards". -Kyle H On Thu, Nov 29, 2018, 21:26 M K Saravanan Hi, > > When I create static DH key pair using openssl, why the public key and > prime contains the prefix 0x00 byte? > > For e.g. in 1024 bit key, 128 bytes is enough. > > private key properly shows 128 bytes. But public key and prime shows > 129 bytes with a 0x00 byte at the beginning. What is the need for > this 0x00 byte at the beginning? i.e. why it is using 129 bytes > instead of 128? > > > $ openssl version > OpenSSL 1.1.1 11 Sep 2018 > > $ openssl dhparam -out mydhp.pem 1024 > [...] > > $ openssl genpkey -paramfile ./mydhp.pem -out mydhkey.pem > > $ openssl pkey -in ./mydhkey.pem -text -noout > DH Private-Key: (1024 bit) > private-key: > 52:61:87:52:b4:27:5f:c3:cf:ab:2f:20:b4:aa:b7: > df:c3:87:63:50:d2:06:dd:65:8f:db:55:2e:08:d5: > 62:44:1a:f5:d8:73:66:fe:a7:c4:43:be:f7:f0:d0: > ba:4c:bf:f0:70:70:c9:25:92:da:ef:69:01:1a:b9: > d9:d9:1f:b9:22:a6:84:48:d8:58:a8:a4:9e:7f:85: > 6b:9e:45:89:07:0c:fb:00:f1:0a:fb:24:10:e4:bb: > 2b:1c:7d:dc:d1:12:a3:21:5a:9b:8e:bf:9d:33:e8: > 65:fe:c2:5c:ea:47:fa:00:04:80:cf:85:e1:c6:71: > 67:4b:7b:71:92:07:59:48 > public-key: > 00:a0:0d:41:8a:27:55:07:2a:01:dd:a7:e2:86:bb: > 69:71:86:1d:62:0c:f3:b7:61:78:81:37:6c:a1:d3: > e8:55:9d:8a:1f:e8:5e:7f:18:00:0f:4e:1d:97:70: > a0:e7:19:2b:82:69:c3:aa:61:ea:b8:9c:10:36:19: > e9:b9:13:db:9a:ef:34:bf:10:f7:93:84:5d:a3:b4: > 58:3a:40:ec:4b:79:06:52:b8:fe:b8:22:0d:f3:f9: > 33:1e:8e:43:69:bb:77:3d:10:78:c6:65:e8:04:08: > 96:1e:cc:6c:92:e4:55:f4:2c:d0:3d:b7:5f:58:70: > cf:fe:a7:5f:23:e3:d9:5e:c4 > prime: > 00:a2:f4:9d:1c:3f:75:8f:3e:e3:c9:95:09:79:09: > 16:f2:f0:61:c4:e1:b9:23:22:a3:58:d7:38:7d:06: > af:57:ad:14:5e:13:bd:71:ed:31:89:cb:65:d6:46: > 3b:29:57:ad:a9:8e:58:e6:df:c0:37:2f:4f:be:45: > d7:c8:f1:87:ef:af:65:87:34:4a:7d:78:b8:0b:0b: > 33:d8:c1:fb:05:9e:ce:9a:27:7e:4a:2a:aa:18:33: > 35:ea:d0:b0:b7:fa:cb:d1:51:bf:11:98:12:24:be: > 1d:1c:87:c3:37:ed:0f:b9:53:23:fc:a1:be:75:ed: > 81:04:e5:6a:b3:83:40:e0:43 > generator: 2 (0x2) > > > with regards, > Saravanan > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.c.roberts at gmail.com Fri Nov 30 14:55:05 2018 From: bill.c.roberts at gmail.com (William Roberts) Date: Fri, 30 Nov 2018 06:55:05 -0800 Subject: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID In-Reply-To: <9F48E1A823B03B4790B7E6E69430724D014B459655@exch2010c.sit.fraunhofer.de> References: <9F48E1A823B03B4790B7E6E69430724D014B459655@exch2010c.sit.fraunhofer.de> Message-ID: On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas wrote: > > Hi all, > > I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine > The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg. What about when keys aren't restricted to one specific signing scheme and support raw encrypt/decrypt? You could just synthesize it by building up the signature structure on the client side and using the raw primitives to encrypt the signing structure directly. > > Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31 > > Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this. > Thus: Is the following approach correct ? > > So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328: > - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ? > - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ? > - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ? > - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ? > - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ? > > Thanks a lot for any advice, > Andreas > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From andreas.fuchs at sit.fraunhofer.de Fri Nov 30 17:35:20 2018 From: andreas.fuchs at sit.fraunhofer.de (Fuchs, Andreas) Date: Fri, 30 Nov 2018 17:35:20 +0000 Subject: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID In-Reply-To: References: <9F48E1A823B03B4790B7E6E69430724D014B459655@exch2010c.sit.fraunhofer.de>, Message-ID: <9F48E1A823B03B4790B7E6E69430724D014B45A823@exch2010c.sit.fraunhofer.de> The problem is as follows: The digest parameter of the TPM2_Sign command is checked against the hash algorithms supported by the TPM. If the TPM only supports SHA256, then the maximum size for the digest parameter is 32 bytes. So you cannot pass in a SHA512 hash, even though the TPM does not even perform a hash operation. Kind of stupid, I know, but thats how it goes. For RSA, I could "emulate" signing by using the TPM2_RSA_Decrypt command. For ECDSA however there is no equivalent. Thus the tpm2-tss-engine will only support up to SHA384 (since that's what most TPMs support). Therefore, the engine needs to communicate to OpenSSL's TLS not to negotiate SHA512. That was apparently added f?r 1.0.1 and 1.1.1 recently as the ASN1_PKEY_CTRL_DEFAULT_MD_NID ameth ctrl. I just don't know enough about OpenSSL as to where to start with this. Anyone have any hints please ? ________________________________________ From: William Roberts [bill.c.roberts at gmail.com] Sent: Friday, November 30, 2018 15:55 To: openssl-users at openssl.org Cc: Fuchs, Andreas Subject: Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas wrote: > > Hi all, > > I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine > The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg. What about when keys aren't restricted to one specific signing scheme and support raw encrypt/decrypt? You could just synthesize it by building up the signature structure on the client side and using the raw primitives to encrypt the signing structure directly. > > Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31 > > Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this. > Thus: Is the following approach correct ? > > So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328: > - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ? > - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ? > - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ? > - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ? > - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ? > > Thanks a lot for any advice, > Andreas > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From charlesm at mcn.org Fri Nov 30 17:47:24 2018 From: charlesm at mcn.org (Charles Mills) Date: Fri, 30 Nov 2018 09:47:24 -0800 Subject: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath Message-ID: <027201d488d4$c06f2220$414d6660$@mcn.org> (Apologies if a duplicate - I think I mis-sent the first attempt.) I wrote a TLS server application that runs under Windows and has been working successfully for years. I am currently using OpenSSL 1.1.0f. When I wrote the code I only supported a single CA file for client certificates. I pass the file name in through SSL_CTX_load_verify_locations CAfile and with CApath NULL. Recently I was asked to add support for multiple CA files. I updated my parameter handling to support a CA path, and I can now pass the path instead using SSL_CTX_load_verify_locations CApath. I am using a client certificate that was signed by my "homegrown" CA (which uses the OpenSSL utility). When I point to the CA .PEM with SSL_CTX_load_verify_locations CAfile it works perfectly. When instead I use CApath to point to a folder that contains only that one .PEM file it fails. My verify callback is driven with -Error with certificate at depth: 1 err 19:self signed certificate in certificate chain error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed:ssl\statem\statem_srvr.c:2893: Yes, the CA certificate is a root certificate and is self-signed. But it works as a CAfile. Can someone give me some guidance here? FWIW I specify SSL_CTX_set_verify(sslContext, SSL_VERIFY_PEER, verify_callback); Thanks, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Fri Nov 30 17:44:43 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 30 Nov 2018 17:44:43 +0000 Subject: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID In-Reply-To: <9F48E1A823B03B4790B7E6E69430724D014B45A823@exch2010c.sit.fraunhofer.de> References: <9F48E1A823B03B4790B7E6E69430724D014B459655@exch2010c.sit.fraunhofer.de> <9F48E1A823B03B4790B7E6E69430724D014B45A823@exch2010c.sit.fraunhofer.de> Message-ID: The way I understand the ECDSA standard, it is supposed to truncate the provided hash - which is why it is possible to have ECDSA-over-P256-SHA384. One possibility would be for you to truncate the SHA2 output yourself, IMHO. ?On 11/30/18, 12:36 PM, "openssl-users on behalf of Fuchs, Andreas" wrote: The problem is as follows: The digest parameter of the TPM2_Sign command is checked against the hash algorithms supported by the TPM. If the TPM only supports SHA256, then the maximum size for the digest parameter is 32 bytes. So you cannot pass in a SHA512 hash, even though the TPM does not even perform a hash operation. Kind of stupid, I know, but thats how it goes. For RSA, I could "emulate" signing by using the TPM2_RSA_Decrypt command. For ECDSA however there is no equivalent. Thus the tpm2-tss-engine will only support up to SHA384 (since that's what most TPMs support). Therefore, the engine needs to communicate to OpenSSL's TLS not to negotiate SHA512. That was apparently added f?r 1.0.1 and 1.1.1 recently as the ASN1_PKEY_CTRL_DEFAULT_MD_NID ameth ctrl. I just don't know enough about OpenSSL as to where to start with this. Anyone have any hints please ? ________________________________________ From: William Roberts [bill.c.roberts at gmail.com] Sent: Friday, November 30, 2018 15:55 To: openssl-users at openssl.org Cc: Fuchs, Andreas Subject: Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas wrote: > > Hi all, > > I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine > The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg. What about when keys aren't restricted to one specific signing scheme and support raw encrypt/decrypt? You could just synthesize it by building up the signature structure on the client side and using the raw primitives to encrypt the signing structure directly. > > Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31 > > Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this. > Thus: Is the following approach correct ? > > So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328: > - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ? > - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ? > - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ? > - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ? > - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ? > > Thanks a lot for any advice, > Andreas > -- > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From openssl-users at dukhovni.org Fri Nov 30 18:22:14 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 30 Nov 2018 13:22:14 -0500 Subject: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath In-Reply-To: <027201d488d4$c06f2220$414d6660$@mcn.org> References: <027201d488d4$c06f2220$414d6660$@mcn.org> Message-ID: > On Nov 30, 2018, at 12:47 PM, Charles Mills wrote: > > I am using a client certificate that was signed by my ?homegrown? CA (which uses the OpenSSL utility). When I point to the CA .PEM with SSL_CTX_load_verify_locations CAfile it works perfectly. When instead I use CApath to point to a folder that contains only that one .PEM file it fails. See the documentation of c_rehash. -- Viktor. From charlesm at mcn.org Fri Nov 30 22:00:59 2018 From: charlesm at mcn.org (Charles Mills) Date: Fri, 30 Nov 2018 14:00:59 -0800 Subject: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath In-Reply-To: References: <027201d488d4$c06f2220$414d6660$@mcn.org> Message-ID: <032001d488f8$2dc529f0$894f7dd0$@mcn.org> Thank you, yes, that solved it. May I respectfully suggest that you consider improving the error message? "Self-signed certificate in certificate chain" does not to me convey "No certificate hash links" (or "CA certificate not found in hash links"). Charles -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Friday, November 30, 2018 10:22 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath > On Nov 30, 2018, at 12:47 PM, Charles Mills wrote: > > I am using a client certificate that was signed by my ?homegrown? CA (which uses the OpenSSL utility). When I point to the CA .PEM with SSL_CTX_load_verify_locations CAfile it works perfectly. When instead I use CApath to point to a folder that contains only that one .PEM file it fails. See the documentation of c_rehash. -- Viktor. From openssl-users at dukhovni.org Fri Nov 30 23:34:33 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 30 Nov 2018 18:34:33 -0500 Subject: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath In-Reply-To: <032001d488f8$2dc529f0$894f7dd0$@mcn.org> References: <027201d488d4$c06f2220$414d6660$@mcn.org> <032001d488f8$2dc529f0$894f7dd0$@mcn.org> Message-ID: <858BE247-C4BB-4C6B-B387-A9DC47C65915@dukhovni.org> > On Nov 30, 2018, at 5:00 PM, Charles Mills wrote: > > "Self-signed certificate in certificate chain" does not to me convey "No certificate hash links" (or "CA certificate not found in hash links"). That's not really possible, because the code that's doing certificate validation works with an abstract certificate store API, and does not know whether a particular certificate should or should not have been listed a trust-anchor in some store. All we know is that we've reached a self-signed certificate in the chain (so no further issuers can be found) and it is not in any of the trust stores, so verification fails. Perhaps we could document the errors in a bit more depth, but I don't think it is possible to tell you that your CApath was missing some specific symlink. -- -- Viktor. From Michael.Wojcik at microfocus.com Fri Nov 30 23:55:49 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 30 Nov 2018 23:55:49 +0000 Subject: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath In-Reply-To: <858BE247-C4BB-4C6B-B387-A9DC47C65915@dukhovni.org> References: <027201d488d4$c06f2220$414d6660$@mcn.org> <032001d488f8$2dc529f0$894f7dd0$@mcn.org> <858BE247-C4BB-4C6B-B387-A9DC47C65915@dukhovni.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Viktor Dukhovni > Sent: Friday, November 30, 2018 16:35 > > > On Nov 30, 2018, at 5:00 PM, Charles Mills wrote: > > > > "Self-signed certificate in certificate chain" does not to me convey "No > > certificate hash links" (or "CA certificate not found in hash links"). > > That's not really possible, because the code that's doing certificate > validation works with an abstract certificate store API, and does not > know whether a particular certificate should or should not have been > listed a trust-anchor in some store. > > All we know is that we've reached a self-signed certificate in the > chain (so no further issuers can be found) and it is not in any > of the trust stores, so verification fails. > > Perhaps we could document the errors in a bit more depth, but I don't > think it is possible to tell you that your CApath was missing some > specific symlink. Viktor's points are all good ones, but considering how often this particular message causes confusion for users and developers (at least in my experience), I wonder whether changing the text to "Untrusted self-signed certificate in certificate chain" would help. That would suggest to the user that the problem might be an issue with the trust store. -- Michael Wojcik Distinguished Engineer, Micro Focus