[openssl-users] Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)
These comments are on the version of the specification released on Monday 2019-02-11 at https://www.openssl.org/docs/OpenSSL300Design.html General notes on this release: - The release was not announced on the openssl-users and openssl-announce mailing lists. A related blog post was announced two days later. - The related strategy document is at https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html (This link is broken on the www.openssl.org front page). - The draft does not link to anywhere that the public can inspect archived or version tracked document versions. Non-FIPS architecture issues: - The identifiers for predefined parameters and values (such as "fips", "on", "off", "aes-128-cbc" should be binary values that cannot be easily searched in larger program files (by attackers). This rules out both text strings, UUID values and ASN OID values. Something similar to the function ids would be ideal. Note that to make this effective, the string names of these should not appear in linked binaries. (The context of this is linking libcrypto and/or libssl into closed source binary programs, since open source binaries cannot hide their internal structure anyway). - It should be possible for applications to configure OpenSSL to load provider DLLs and config files from their own directories rather than the global well-known directory (isolation from system wide changes). - It should be possible for providers (possibly not the FIPS provider) to be linked directly into programs that link statically to libcrypto. This implies the absence of conflicting identifiers, a public API to pass the address of a |OSSL_provider_init|function, all bundled providers provided as static libraries in static library builds, and a higher level init function that initializes both libcrypto and the default provider. - Static library forms of the default provider should not force callers to include every algorithm just because they are referenced from the default dispatch tables. For example, it should be easy to link a static application that uses only AES-256-CBC and SHA-256, and contains little else. Such limited feature applications would obviously have to forego using the all-inclusive high level init function. - For use with engine-like providers (such as hardware providers and the PKCS#11 provider), it should be possible for a provider to provide algorithms like RSA at multiple abstraction levels. For example, some PKCS#11 hardware provides the raw RSA algorithm (bignum in, bignum out) while others provide specific forms such as PKCS#1.5 signature. There are even some that provide the PKCS#1.5 form with some hashes and the RSA form as a general fallback. - Similarly, some providers will provide both ends of an asymmetric algorithm, while others only provide the private key operation, leaving the public key operation to other providers (selected by core in the general way). - The general bignum library should be exposed via an API, either the legacy OpenSSL bignum API or a replacement API with an overlap of at least one major version with both APIs available. - Provider algorithm implementations should carry description/selection parameters indicating limits to access: "key-readable=yes/no", "key-writable=yes/no", "data-internal=yes/no", "data-external=yes/no" and "iv-internal=yes/no". For example, a smartcard-like provider may have "key-readable=no" and "key-writable=yes" for RSA keys, while another card may have "key-writable=no" (meaning that externally generated keys cannot be imported to the card. "data-internal" refers to the ability to process (encrypt, hash etc.) data internal to the provider, such as other keys, while "data-external" refers to the ability to process arbitrary application data. - Variable key length algorithm implementations should carry description/selection parameters indicating maximum and minimum key lengths (Some will refuse to process short keys, others will refuse long keys, some will require the key length to be a multiple of some number). - The current EVP interface abuses the general (re)init operations with omitted arguments as the main interface to update rapidly changing algorithm parameters such as IVs and/or keys. With the removal of legacy APIs, the need to provide parameter changing as explicit calls in the EVP API and provider has become more obvious. - A provider property valuable to some callers (and already a known property of some legacy APIs) is to declare that certain simple operations will always succeed, such as passing additional data bytes to a hash/mac (the rare cases of hardware disconnect and/or exceeding the algorithm maximums can be deferred to "finish" operations). A name for this property of an algorithm implementation could be "nofail=yes", and the list of non-failing operations defined for each type of algorithm should be publicly specified (a nofail hash would
[openssl-users] when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?
In particular, I'm getting a close_notify alert, followed by two NewSessionTickets from the server. The does SSL_read()/SSL_get_error(), it is returning SSL_ERROR_ZERO_RETURN, so I stop calling SSL_read(). However, that means that the NewSessionTickets aren't seen, so I don't get the callbacks from SSL_CTX_sess_set_new_cb(). Should we be calling SSL_read() until some other return value occurs? Note that no data is written by the server, and SSL_shutdown() is called from inside the server's SSL_CB_HANDSHAKE_DONE info callback. The node test suite is rife with this pracitce, where a connection is established to prove its possible, but then just ended without data transfer. For TLS1.2 we get the session callbacks, but TLS1.3 we do not. This is the trace, edited to reduce SSL_trace verbosity: server TLSWrap::SSLInfoCallback(where SSL_CB_HANDSHAKE_DONE, alert U) established? 0 state 0x21 TWST: SSLv3/TLS write session ticket TLSv1.3 server TLSWrap::DoShutdown() established? 1 ssl? 1 Sent Record Inner Content Type = Alert (21) Level=warning(1), description=close notify(0) Sent Record NewSessionTicket, Length=245 Sent Record NewSessionTicket, Length=245 client TLSWrap::OnStreamRead(nread 566) established? 1 ssl? 1 parsing? 0 eof? 0 Received Record Level=warning(1), description=close notify(0) SSL_read() => 0 SSL_get_shutdown() => SSL_RECEIVED_SHUTDOWN SSL_get_error() => SSL_ERROR_ZERO_RETURN At this point, we consider the connection closed... not sure what else to do. Thanks, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Queston about CMS_encrypt : Generates Version
Hi All, I am using CMS_sign API to generate pkcs7-envelopedData for SCEP implementation. I am facing issue as CMS_sign API generates default version, originatorInfo and recipientInfo fields as . I would like to know how to set correct values to these fields, if there is any other openssl API I need ? CMS_ContentInfo: contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3) d.envelopedData: version: originatorInfo: recipientInfos: d.ktri: version: Thanks NJ -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL 3.0 and FIPS Update
>Yes - I do expect you to be able to build just the validated source independently of the rest of the tarball so that you could (for example) run the latest main OpenSSL version but with an older module. Which means that this doesn't have to happen in the first release since there's only one runtime that works with the one FIPS module. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL 3.0 and FIPS Update
>Integrity of validated source code when other parts of the tarball get regular changes? The design doc, just recently published, talks about this a bit. Not all details are known yet. >Building the validated source code in a controlled environment separate from the full tarball? I do not believe this has been discussed within the FIPS sponsors. >(If there are answers in the FIPS 3.0.0 draft spec, they need repeating). Or a more careful reading. :) >So right now, FIPS-validated users are left hanging, with no date to get a 3.0.0 code drop to start porting and a looming deadline for the 1.0.x API. You get what you pay for. I can be harsh because I am not a member of the OpenSSL project. You can start by porting to 1.1.x now. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-project] OpenSSL 3.0 and FIPS Update
Can you give any guidance on which platforms will be validated with the OpenSSL FIPS 3.0 module? My recollection is that it will only be a handful of platforms. It would be helpful to have an idea which platforms will and will not be included. Any additional information about how other platforms can be validated would also be helpful. Thanks, Zeke Evans Senior Software Engineer, Micro Focus From: openssl-project on behalf of Matt Caswell Sent: Wednesday, February 13, 2019 4:26 AM To: openssl-annou...@openssl.org; openssl-users@openssl.org; openssl-proj...@openssl.org Subject: [openssl-project] OpenSSL 3.0 and FIPS Update Please see my blog post for an OpenSSL 3.0 and FIPS Update: https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Matt ___ openssl-project mailing list openssl-proj...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Questions about Ciphers
On 14/02/2019 16:42, Patrice Guérin wrote: > Hello, > > I have two questions : > > * I use OBJ_NAME_do_all_sorted() with OBJ_NAME_TYPE_CIPHER_METH to get the > list of supported cipher methods > Is there a difference between lowercase and uppercase names ? > I've noticed that some do not have uppercase name (ex. aes-128-ccm) > Is there a prefered name to use ? Objects have a "short name" and a "long name". In many cases the two are identical. In others they have minor differences such as uppercase vs lowercase. It doesn't matter - both forms refer to the same object. You can use either. > * In the case of GCM usage (with examples found in the OpenSSL wiki), > Is the specific control action to set the tag on decryption can be done at > the beginning rather than juste before EVP_DecryptFinal_ex() ? Yes, as long as it's done after EVP_DecryptInit_ex(). Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL 3.0 and FIPS Update
+1 on the point: firm expiration date without firm replacement date ... really?! We have to hope that the firm expiration date will actually move if the replacement isn't ready before then ... and that doesn't begin to account for the calendar time to get the new one certified Thanks, Mark Ludwig -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jakob Bohm via openssl-users Sent: Thursday, February 14, 2019 10:34 AM To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL 3.0 and FIPS Update On 13/02/2019 20:12, Matt Caswell wrote: > > On 13/02/2019 17:32, Jakob Bohm via openssl-users wrote: >> On 13/02/2019 12:26, Matt Caswell wrote: >>> Please see my blog post for an OpenSSL 3.0 and FIPS Update: >>> >>> https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ >>> >>> Matt >> Given this announcement, a few questions arise: >> >> - How will a FIPS provider in the main tarball ensure compliance >> with the strict code delivery and non-change requirements of the >> CMVP (what was previously satisfied by distributing physical >> copies of the FIPS canister source code, and sites compiling this >> in a highly controlled environment to produce a golden canister)? > My understanding is that physical distribution is no longer a requirement. And the other things in that question? Integrity of validated source code when other parts of the tarball get regular changes? Building the validated source code in a controlled environment separate from the full tarball? (If there are answers in the FIPS 3.0.0 draft spec, they need repeating). >> - Will there be a reasonable transition period where users of the >> old FIPS-validated module can transition to the new module (meaning >> that both modules are validated and usable with a supported >> FIPS-capable OpenSSL library)? I imagine that applications relying >> on the existing FIPS canister will need some time to quality test >> their code with all the API changes from OpenSSL 1.0.x to OpenSSL >> 3.0.x . OS distributions will also need some time to roll out the >> resulting feature updates to end users. > The old FIPS module will remain validated for some time to come, so both the > old > and new modules will be validated at the same time for a while. 1.0.2 will go > EOL at the end of this year. The intention is that 3.0 will be available > before > that. It's not yet clear exactly when 3.0 will become available and what the > overlap with 1.0.2 will be so I don't have an answer at this stage for > transition period. > > Matt > So right now, FIPS-validated users are left hanging, with no date to get a 3.0.0 code drop to start porting and a looming deadline for the 1.0.x API. 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL 3.0 and FIPS Update
On 14/02/2019 16:34, Jakob Bohm via openssl-users wrote: > On 13/02/2019 20:12, Matt Caswell wrote: >> >> On 13/02/2019 17:32, Jakob Bohm via openssl-users wrote: >>> On 13/02/2019 12:26, Matt Caswell wrote: Please see my blog post for an OpenSSL 3.0 and FIPS Update: https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Matt >>> Given this announcement, a few questions arise: >>> >>> - How will a FIPS provider in the main tarball ensure compliance >>> with the strict code delivery and non-change requirements of the >>> CMVP (what was previously satisfied by distributing physical >>> copies of the FIPS canister source code, and sites compiling this >>> in a highly controlled environment to produce a golden canister)? >> My understanding is that physical distribution is no longer a requirement. > And the other things in that question? > > Integrity of validated source code when other parts of the tarball > get regular changes? > > Building the validated source code in a controlled environment > separate from the full tarball? See the section of the Design document with the title "Detection of Changes inside the FIPS Boundary". Basically there will be version controlled checksum covering all of the validated source. Yes - I do expect you to be able to build just the validated source independently of the rest of the tarball so that you could (for example) run the latest main OpenSSL version but with an older module. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Questions about Ciphers
Hello, I have two questions : * I use OBJ_NAME_do_all_sorted() with OBJ_NAME_TYPE_CIPHER_METH to get the list of supported cipher methods Is there a difference between lowercase and uppercase names ? I've noticed that some do not have uppercase name (ex. aes-128-ccm) Is there a prefered name to use ? * In the case of GCM usage (with examples found in the OpenSSL wiki), Is the specific control action to set the tag on decryption can be done at the beginning rather than juste before EVP_DecryptFinal_ex() ? Thank you. Kind regards, Patrice. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL 3.0 and FIPS Update
On 13/02/2019 20:12, Matt Caswell wrote: On 13/02/2019 17:32, Jakob Bohm via openssl-users wrote: On 13/02/2019 12:26, Matt Caswell wrote: Please see my blog post for an OpenSSL 3.0 and FIPS Update: https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Matt Given this announcement, a few questions arise: - How will a FIPS provider in the main tarball ensure compliance with the strict code delivery and non-change requirements of the CMVP (what was previously satisfied by distributing physical copies of the FIPS canister source code, and sites compiling this in a highly controlled environment to produce a golden canister)? My understanding is that physical distribution is no longer a requirement. And the other things in that question? Integrity of validated source code when other parts of the tarball get regular changes? Building the validated source code in a controlled environment separate from the full tarball? (If there are answers in the FIPS 3.0.0 draft spec, they need repeating). - Will there be a reasonable transition period where users of the old FIPS-validated module can transition to the new module (meaning that both modules are validated and usable with a supported FIPS-capable OpenSSL library)? I imagine that applications relying on the existing FIPS canister will need some time to quality test their code with all the API changes from OpenSSL 1.0.x to OpenSSL 3.0.x . OS distributions will also need some time to roll out the resulting feature updates to end users. The old FIPS module will remain validated for some time to come, so both the old and new modules will be validated at the same time for a while. 1.0.2 will go EOL at the end of this year. The intention is that 3.0 will be available before that. It's not yet clear exactly when 3.0 will become available and what the overlap with 1.0.2 will be so I don't have an answer at this stage for transition period. Matt So right now, FIPS-validated users are left hanging, with no date to get a 3.0.0 code drop to start porting and a looming deadline for the 1.0.x API. 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
[openssl-users] How to get the CA list
Hey guys, I would like to get a list of all the CAs added to the X509_STORE. For this I use: X509_STORE_set_default_paths or X509_STORE_load_locations. Basically I need to get the list of the CAs out of the store or the store context. I could not figure out a proper way to do this. I tried to use X509_STORE_get1_certs but this seems to require a X509_NAME which I do not have since I want all the certificates out of the CAs. Is there a proper way to do this? Regards. -- Ignacio Casal Quinteiro -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-project] OpenSSL 3.0 and FIPS Update
On 13/02/2019 20:28, Michael Richardson wrote: > > Matt Caswell wrote: > > Please see my blog post for an OpenSSL 3.0 and FIPS Update: > > > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ > > Thank you, it is very useful to have these plans made up front. > I think your posts should probably explain what happened to 2.x, and if this > represents a move towards semantic versioning. (I think it does...?) This is all explained in one of my previous blog posts. See: https://www.openssl.org/blog/blog/2018/11/28/version/ > > In the various things linked, in particular: >https://www.openssl.org/docs/OpenSSL300Design.html > > I think that there is a missing box. Specifically, the PERL API wrappers > that are used in the test bench. I believe that the "applications" are > a serious problem as there are (in 1.1.1) still many things that are very > difficult (sometimes, it seems, impossible) to do programmatically, and which > the test cases actually simply shell out to the application to do. > An example of this is adding certain extensions to a certificate when > generating it, which is only really possible by loading pieces of > configuration file in. > > So what I'd like to see is to remove many of the applications from the core > of OpenSSL, put them into a seperate package using better-documented API > calls. Let them evolve according their own time-scale, probably taking > patches faster without disrupting the underlying libraries. > > My observation is that the Perl testing system is used to drive the tests, > but the tests do not actually use the Perl API wrapper for OpenSSL, but > rather rely on the vast number of .c files in test/*. > In other (more purely agile) projects, the test cases often serve as > documentation as to how to use the API. In OpenSSL, the test cases > rely too much on the openssl "applications", and the API is hidden. > > This would involve adopting some or all of Net::SSLeay. > While there would be some initial duplication of effort, I think that over > time it would sort itself out. Perl is no longer as cool as it used to be (I > still like it) and maybe someone would argue for Python3 or something, and > frankly I don't care which. > > What I care about is that the test cases actually test the API, rather than > depend upon 20 years of twisty code in the "applications". > And that the applications are permitted to grow/change/adapt to people's > needs, rather than living in a hard spot between developer needs and end > user needs, pissing off both groups. I don't think it is accurate to characterise the tests as not directly testing the API but instead depending on the applications to do that. That *is* probably the case in many older tests but I don't recall many (any?) such tests being written in recent years. Instead there has been much effort put into directly testing the API (as an example see sslapitest.c which did not exist a few years ago (it doesn't appear in 1.0.2), but is currently over 6000 lines long). There are also the TLSProxy tests which do use s_server/s_client. But in those cases s_server/s_client are just used to drive a handshake. The tests themselves are actually written in perl. These are not API tests (so they don't depend on adding lots of obscure options to s_server/s_client) but are instead protocol tests. These tests modify the handshake in-flight to confirm that we can handle unusual or invalid protocol messages. Actually I would love to see the removal of the s_server/s_client dependency to something custom written. IMO the applications are no longer driven by developer needs. That may have once been the case, but I don't think it is true today. That said, of course, there is plenty of room for improvement in our testing. I would love to see more complete direct testing of the API. I do think we are moving in the right direction, but it is definitely a long term project. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
