From erik at efca.com Wed May 1 02:05:06 2019 From: erik at efca.com (Erik Forsberg) Date: Tue, 30 Apr 2019 19:05:06 -0700 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN In-Reply-To: References: Message-ID: >-- Original Message -- > > >>-- Original Message -- >> >>On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote: >> >>> >Is the handshake explicit, or does the application just call >>> >SSL_read(), with OpenSSL performing the handshake as needed? >>> >>> I occasionally (somewhat rarely) see the issue mentioned by the OP. >>> Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE >>> does effectively hides the issue and connection works fine. I predominantly >>> run on Solaris 11. In my case, I open the socket myself, set non-blocking >>> mode and associates with an SSL object using SS_set_fd(). >>> The initial handshake is done explicitly. >> >>Recoverable errors should not result in SSL_ERROR_SYSCALL. This >>feels like a bug. I'd like to hear from Matt Caswell on this one. >>Perhaps someone should open an issue on Github... >> >I will scan my logs later this evening and see if this is still an issue. >Last time I remember seeing it was quote some long time ago (couple of years) > > ok, I checked my logs (3+ years worth of them) and I have not seen this error in that timeframe. so it must have been a much older OpenSSL version I used way back when I remember doing this workaround. Doesnt seem to be needed for me anymore. From matt at openssl.org Wed May 1 07:42:06 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 1 May 2019 08:42:06 +0100 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN In-Reply-To: <20190430223704.GA67454@straasha.imrryr.org> References: <60444857-0C8A-41AB-B5C2-50B62DF75EDC@dukhovni.org> <4eTWI5Vk5QBXoM1@srv.efca.com> <20190430223704.GA67454@straasha.imrryr.org> Message-ID: <4a6efadd-594b-ca1e-3f67-998ffd3a069a@openssl.org> On 30/04/2019 23:37, Viktor Dukhovni wrote: > On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote: > >>> Is the handshake explicit, or does the application just call >>> SSL_read(), with OpenSSL performing the handshake as needed? >> >> I occasionally (somewhat rarely) see the issue mentioned by the OP. >> Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE >> does effectively hides the issue and connection works fine. I predominantly >> run on Solaris 11. In my case, I open the socket myself, set non-blocking >> mode and associates with an SSL object using SS_set_fd(). >> The initial handshake is done explicitly. > > Recoverable errors should not result in SSL_ERROR_SYSCALL. This > feels like a bug. I'd like to hear from Matt Caswell on this one. > Perhaps someone should open an issue on Github... > SSL_ERROR_SYSCALL should not be raised as result of a recoverable error. This should always be considered fatal. If you are getting this but errno says EAGAIN then a number of possibilities spring to mind: 1) If a fatal error has occurred SSL_get_error() checks to see if there is an error on the OpenSSL error queue. If there is it returns SSL_ERROR_SSL (unless the error type is ERR_LIB_SYS). If there is no error at all, but libssl doesn't think the error is recoverable then it will return SSL_ERROR_SYSCALL by default. It is possible that libssl has encountered some non-syscall related error but neglected to push an error onto the error queue. Thus the return value incorrectly indicates SSL_ERROR_SYSCALL when it should have been SSL_ERROR_SSL. This would be an OpenSSL bug - but quite tricky to find since we'd have to locate the spot where no error is being pushed...but because there is no error we don't have a lot to go on! 2) A second possibility is that it really was a syscall that failed but something (either in libssl or possibly in application code) made some subsequent syscall that changed errno in the meantime. If that "something" was in libssl then that's probably also a libssl bug. (Also quite tricky to track down) 3) A third possibility is that it really is a retryable error but libssl failed to properly set its state to note that. I think this is quite a lot less likely than (1) or (2) but would also be a libssl bug. So my guess is, except in the case where the application itself has accidentally changed errno, this most likely indicates an openssl bug. The safest thing to do in such circumstances is to treat this as a fatal error. It is very unwise to retry a connection where the library has indicated a fatal error (e.g. see CVE-2019-1559) What OpenSSL version is this? Matt From John.Unsworth at synchronoss.com Wed May 1 10:59:39 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Wed, 1 May 2019 10:59:39 +0000 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN Message-ID: This is what we do: Create a non-blocking TCP socket. Call SSL_new(), SSL_set_fd(), SSL_connect() Thereafter call SSL_read(). Renegotiates handled by OpenSSL. We have only seen the error very occasionally, the vast majority of calls return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. The following is traced when we get the fail, originally we then caused a disconnect but now handle it as discussed: LDAP: session=7F38AE82F840 socket read error SSL Error Syscall: LastError 11 Note that because our code automatically reconnects and reissues failed and aborted operations customers would not normally see the error. In this case though we disconnected while a modify operation was running in the LDAP server, after reconnecting the modify was reissued and failed because of attribute deletion by the original modify. The investigation showed up the error. The customer was running a soak test and thousands (maybe millions) of reads worked fine until the failing one. Regards, John. -----Original Message----- From: openssl-users On Behalf Of Erik Forsberg Sent: 01 May 2019 03:05 To: openssl-users at openssl.org Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN CAUTION: This email originated from outside of Synchronoss. >-- Original Message -- > > >>-- Original Message -- >> >>On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote: >> >>> >Is the handshake explicit, or does the application just call >>> >SSL_read(), with OpenSSL performing the handshake as needed? >>> >>> I occasionally (somewhat rarely) see the issue mentioned by the OP. >>> Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE >>> does effectively hides the issue and connection works fine. I >>> predominantly run on Solaris 11. In my case, I open the socket >>> myself, set non-blocking mode and associates with an SSL object using SS_set_fd(). >>> The initial handshake is done explicitly. >> >>Recoverable errors should not result in SSL_ERROR_SYSCALL. This feels >>like a bug. I'd like to hear from Matt Caswell on this one. >>Perhaps someone should open an issue on Github... >> >I will scan my logs later this evening and see if this is still an issue. >Last time I remember seeing it was quote some long time ago (couple of >years) > > ok, I checked my logs (3+ years worth of them) and I have not seen this error in that timeframe. so it must have been a much older OpenSSL version I used way back when I remember doing this workaround. Doesnt seem to be needed for me anymore. From John.Unsworth at synchronoss.com Wed May 1 13:47:33 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Wed, 1 May 2019 13:47:33 +0000 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN Message-ID: This is what we do: Create a non-blocking TCP socket. Call SSL_new(), SSL_set_fd(), SSL_connect() Thereafter call SSL_read(). Renegotiates handled by OpenSSL. We have only seen the error very occasionally, the vast majority of calls return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. The following is traced when we get the fail, originally we then caused a disconnect but now handle it as discussed: LDAP: session=7F38AE82F840 socket read error SSL Error Syscall: LastError 11 Note that because our code automatically reconnects and reissues failed and aborted operations customers would not normally see the error. In this case though we disconnected while a modify operation was running in the LDAP server, after reconnecting the modify was reissued and failed because of attribute deletion by the original modify. The investigation showed up the error. The customer was running a soak test and thousands (maybe millions) of reads worked fine until the failing one. Regards, John. -----Original Message----- From: openssl-users On Behalf Of Erik Forsberg Sent: 01 May 2019 03:05 To: openssl-users at openssl.org Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN CAUTION: This email originated from outside of Synchronoss. >-- Original Message -- > > >>-- Original Message -- >> >>On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote: >> >>> >Is the handshake explicit, or does the application just call >>> >SSL_read(), with OpenSSL performing the handshake as needed? >>> >>> I occasionally (somewhat rarely) see the issue mentioned by the OP. >>> Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE >>> does effectively hides the issue and connection works fine. I >>> predominantly run on Solaris 11. In my case, I open the socket >>> myself, set non-blocking mode and associates with an SSL object using SS_set_fd(). >>> The initial handshake is done explicitly. >> >>Recoverable errors should not result in SSL_ERROR_SYSCALL. This feels >>like a bug. I'd like to hear from Matt Caswell on this one. >>Perhaps someone should open an issue on Github... >> >I will scan my logs later this evening and see if this is still an issue. >Last time I remember seeing it was quote some long time ago (couple of >years) > > ok, I checked my logs (3+ years worth of them) and I have not seen this error in that timeframe. so it must have been a much older OpenSSL version I used way back when I remember doing this workaround. Doesnt seem to be needed for me anymore. From openssl-users at dukhovni.org Thu May 2 06:25:27 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 2 May 2019 02:25:27 -0400 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: References: Message-ID: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> > On May 1, 2019, at 9:47 AM, John Unsworth wrote: > > Create a non-blocking TCP socket. > Call SSL_new(), SSL_set_fd(), SSL_connect() > Thereafter call SSL_read(). > Renegotiates handled by OpenSSL. Can you be more specific about "Create a non-blocking TCP socket"? That fully sets up the TCP connection? Also, with the non-blocking connection, how do you decide when to read? Are you using poll()? select()? epoll()? And did they report available data? In this particular case, was the client trying to read the initial bytes of the server's reply having received nothing yet in response to its query? Or was it in the middle of reading a data stream? When reading TLS records OpenSSL first reads the record layer header which indicates the payload length, and then tries to read that many bytes. Does the server send the record layer header in the same TCP segment as the payload, or in separate segments? Do you know what protocol version was negotiated? Are both ends using OpenSSL? What version on the server side? ... Can you reproduce the problem after sufficiently many client server interactions? Can you get PCAP files of any problem cases? -- Viktor. From tmraz at redhat.com Thu May 2 09:39:55 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 02 May 2019 11:39:55 +0200 Subject: Any timeframe for the 1.1.1c release? Message-ID: Hi OpenSSL developers, when is the 1.1.1c expected to be released? There were plenty of bug fixes committed to the 1.1.1 branch since the 1.1.1b release. Is the 1.1.1c release imminent? Regards, -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From John.Unsworth at synchronoss.com Thu May 2 09:56:45 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 2 May 2019 09:56:45 +0000 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> Message-ID: Create a non-blocking TCP socket socket() for a sock_stream. connect(). SSL_new(), SSL_set_fd(), SSL_connect(). The application sends LDAP operations from many threads. We have just one thread that reads LDAP results. If an operation is outstanding then the result thread does (simplified): SSL_read() If > 0 return data. Else if SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE then poll(); back to SSL_read() when data available. Else return error and disconnect. Don't know what protocol was negotiated or what the server does in terms of returned data. TCP/OpenSSL handle that. Both ends OpenSSL 1.1.0h. Problem seems to occur at random - only reproducable on customer site and after a long time running their soak test. Regards, John. -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: 02 May 2019 07:25 To: openssl-users at openssl.org Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN CAUTION: This email originated from outside of Synchronoss. > On May 1, 2019, at 9:47 AM, John Unsworth wrote: > > Create a non-blocking TCP socket. > Call SSL_new(), SSL_set_fd(), SSL_connect() Thereafter call > SSL_read(). > Renegotiates handled by OpenSSL. Can you be more specific about "Create a non-blocking TCP socket"? That fully sets up the TCP connection? Also, with the non-blocking connection, how do you decide when to read? Are you using poll()? select()? epoll()? And did they report available data? In this particular case, was the client trying to read the initial bytes of the server's reply having received nothing yet in response to its query? Or was it in the middle of reading a data stream? When reading TLS records OpenSSL first reads the record layer header which indicates the payload length, and then tries to read that many bytes. Does the server send the record layer header in the same TCP segment as the payload, or in separate segments? Do you know what protocol version was negotiated? Are both ends using OpenSSL? What version on the server side? ... Can you reproduce the problem after sufficiently many client server interactions? Can you get PCAP files of any problem cases? -- Viktor. From John.Unsworth at synchronoss.com Thu May 2 10:01:13 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 2 May 2019 10:01:13 +0000 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN In-Reply-To: <4a6efadd-594b-ca1e-3f67-998ffd3a069a@openssl.org> References: <60444857-0C8A-41AB-B5C2-50B62DF75EDC@dukhovni.org> <4eTWI5Vk5QBXoM1@srv.efca.com> <20190430223704.GA67454@straasha.imrryr.org> <4a6efadd-594b-ca1e-3f67-998ffd3a069a@openssl.org> Message-ID: Openssl 1.1.0h We have implemented the workaround - if SSL_ERROR_SYSCALL and errno=EAGAIN then treat as WANT_READ/WANT_WRITE. This (seems to) work fine. No subsequent problems, everything continues correctly. Regards, John -----Original Message----- From: openssl-users On Behalf Of Matt Caswell Sent: 01 May 2019 08:42 To: openssl-users at openssl.org Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN CAUTION: This email originated from outside of Synchronoss. On 30/04/2019 23:37, Viktor Dukhovni wrote: > On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote: > >>> Is the handshake explicit, or does the application just call >>> SSL_read(), with OpenSSL performing the handshake as needed? >> >> I occasionally (somewhat rarely) see the issue mentioned by the OP. >> Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE >> does effectively hides the issue and connection works fine. I >> predominantly run on Solaris 11. In my case, I open the socket >> myself, set non-blocking mode and associates with an SSL object using SS_set_fd(). >> The initial handshake is done explicitly. > > Recoverable errors should not result in SSL_ERROR_SYSCALL. This feels > like a bug. I'd like to hear from Matt Caswell on this one. > Perhaps someone should open an issue on Github... > SSL_ERROR_SYSCALL should not be raised as result of a recoverable error. This should always be considered fatal. If you are getting this but errno says EAGAIN then a number of possibilities spring to mind: 1) If a fatal error has occurred SSL_get_error() checks to see if there is an error on the OpenSSL error queue. If there is it returns SSL_ERROR_SSL (unless the error type is ERR_LIB_SYS). If there is no error at all, but libssl doesn't think the error is recoverable then it will return SSL_ERROR_SYSCALL by default. It is possible that libssl has encountered some non-syscall related error but neglected to push an error onto the error queue. Thus the return value incorrectly indicates SSL_ERROR_SYSCALL when it should have been SSL_ERROR_SSL. This would be an OpenSSL bug - but quite tricky to find since we'd have to locate the spot where no error is being pushed...but because there is no error we don't have a lot to go on! 2) A second possibility is that it really was a syscall that failed but something (either in libssl or possibly in application code) made some subsequent syscall that changed errno in the meantime. If that "something" was in libssl then that's probably also a libssl bug. (Also quite tricky to track down) 3) A third possibility is that it really is a retryable error but libssl failed to properly set its state to note that. I think this is quite a lot less likely than (1) or (2) but would also be a libssl bug. So my guess is, except in the case where the application itself has accidentally changed errno, this most likely indicates an openssl bug. The safest thing to do in such circumstances is to treat this as a fatal error. It is very unwise to retry a connection where the library has indicated a fatal error (e.g. see CVE-2019-1559) What OpenSSL version is this? Matt From openssl-users at dukhovni.org Thu May 2 14:55:55 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 2 May 2019 10:55:55 -0400 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> Message-ID: <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> > On May 2, 2019, at 5:56 AM, John Unsworth wrote: > > Create a non-blocking TCP socket > socket() for a sock_stream. > connect(). Do you wait for the non-blocking connect to complete at this point? > SSL_new(), SSL_set_fd(), SSL_connect(). > > The application sends LDAP operations from many threads. Are multiple threads writing to the same SSL connection? How do you ensure orderly use of the SSL connection? Sharing connections across threads without application level synchronization is not supported in OpenSSL. > We have just one thread that reads LDAP results. How are further requests locked out when you're performing reads? What is the granularity of the relevant locks? > If an operation is outstanding then the result thread does (simplified): > > SSL_read() > If > 0 return data. At this point you'd be calling SSL_get_error(), is there a lock that prevents writes between SSL_read() and SSL_read() and SSL_get_error()? > Else if SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE then poll(); back to SSL_read() when data available. > Else return error and disconnect. > > Don't know what protocol was negotiated or what the server does in terms of returned data. TCP/OpenSSL handle that. > Both ends OpenSSL 1.1.0h. > Problem seems to occur at random - only reproducable on customer site and after a long time running their soak test. It would be helpful if the customer could gather more diagnostic information from that "soak test". With 1.1.0, presumably they negotiate TLS 1.2, since TLS 1.3 is not available, while 1.2 is available on both ends. IIRC OpenSSL will normally send the record layer header in the same segment as the payload, so running into EAGAIN is unlikely after the initial 5 bytes of record header, unless the TCP receive window was nearly full. I gather the protocol is full-duplex and multiple outstanding requests can be written before the corresponding replies are read? Or is it strict half-duplex request-response? -- Viktor. From matt at openssl.org Thu May 2 16:09:03 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 May 2019 17:09:03 +0100 Subject: Any timeframe for the 1.1.1c release? In-Reply-To: References: Message-ID: <25d62169-37c3-3fd8-5e3b-041532ea2c4a@openssl.org> On 02/05/2019 10:39, Tomas Mraz wrote: > Hi OpenSSL developers, > > when is the 1.1.1c expected to be released? There were plenty of bug > fixes committed to the 1.1.1 branch since the 1.1.1b release. Is the > 1.1.1c release imminent? There are no plans at the moment. Matt From John.Unsworth at synchronoss.com Thu May 2 16:10:31 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 2 May 2019 16:10:31 +0000 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> Message-ID: Please note that the connection has been made successfully and many operations and responses have occurred before the fail. > Do you wait for the non-blocking connect to complete at this point? We connect in blocking mode then switch to non-blocking. > Are multiple threads writing to the same SSL connection? How do you ensure orderly use of the SSL connection? Sharing connections across threads without application level synchronization is not supported in OpenSSL. We use mutexes to synchronize of course. > How are further requests locked out when you're performing reads? What is the granularity of the relevant locks? The mutex only allows one SSL call at a time. > At this point you'd be calling SSL_get_error(), is there a lock that prevents writes between SSL_read() and SSL_read() and SSL_get_error()? The mutex does not protect SSL_get_error() calls. > I gather the protocol is full-duplex and multiple outstanding requests can be written before the corresponding replies are read? Or is it strict half-duplex request-response? It is full duplex and there can be multiple operations in progress. Regards, John. -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: 02 May 2019 15:56 To: openssl-users at openssl.org Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN CAUTION: This email originated from outside of Synchronoss. > On May 2, 2019, at 5:56 AM, John Unsworth wrote: > > Create a non-blocking TCP socket > socket() for a sock_stream. > connect(). Do you wait for the non-blocking connect to complete at this point? > SSL_new(), SSL_set_fd(), SSL_connect(). > > The application sends LDAP operations from many threads. Are multiple threads writing to the same SSL connection? How do you ensure orderly use of the SSL connection? Sharing connections across threads without application level synchronization is not supported in OpenSSL. > We have just one thread that reads LDAP results. How are further requests locked out when you're performing reads? What is the granularity of the relevant locks? > If an operation is outstanding then the result thread does (simplified): > > SSL_read() > If > 0 return data. At this point you'd be calling SSL_get_error(), is there a lock that prevents writes between SSL_read() and SSL_read() and SSL_get_error()? > Else if SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE then poll(); back to SSL_read() when data available. > Else return error and disconnect. > > Don't know what protocol was negotiated or what the server does in terms of returned data. TCP/OpenSSL handle that. > Both ends OpenSSL 1.1.0h. > Problem seems to occur at random - only reproducable on customer site and after a long time running their soak test. It would be helpful if the customer could gather more diagnostic information from that "soak test". With 1.1.0, presumably they negotiate TLS 1.2, since TLS 1.3 is not available, while 1.2 is available on both ends. IIRC OpenSSL will normally send the record layer header in the same segment as the payload, so running into EAGAIN is unlikely after the initial 5 bytes of record header, unless the TCP receive window was nearly full. I gather the protocol is full-duplex and multiple outstanding requests can be written before the corresponding replies are read? Or is it strict half-duplex request-response? -- Viktor. From openssl-users at dukhovni.org Thu May 2 17:23:22 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 2 May 2019 13:23:22 -0400 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> Message-ID: <20190502172322.GC67454@straasha.imrryr.org> On Thu, May 02, 2019 at 04:10:31PM +0000, John Unsworth wrote: > > Do you wait for the non-blocking connect to complete at this point? > We connect in blocking mode then switch to non-blocking. Thanks that rules connection setup out of the picture. > > Are multiple threads writing to the same SSL connection? How do you > > ensure orderly use of the SSL connection? Sharing connections across > > threads without application level synchronization is not supported in > > OpenSSL. > > We use mutexes to synchronize of course. OK. > > How are further requests locked out when you're performing reads? > > What is the granularity of the relevant locks? > > The mutex only allows one SSL call at a time. So a serialized mix of reads and writes with possibly multiple outstanding writes interleaved with the reader? Right? > > At this point you'd be calling SSL_get_error(), is there a lock that > > prevents writes between SSL_read() and SSL_read() and SSL_get_error()? > > The mutex does not protect SSL_get_error() calls. I think that's an application bug. The SSL_get_error() is using the same SSL handle as the SSL_read(), which can be materially altered by concurrent writes. (Matt, if you're still reading this thread, do you agree?) I would not release the mutex until after the call to SSL_get_error(). > > I gather the protocol is full-duplex and multiple outstanding requests > > can be written before the corresponding replies are read? Or is it strict > > half-duplex request-response? > > It is full duplex and there can be multiple operations in progress. Please retest with both the SSL_read() and SSL_get_error() running under a single lock. And similarly on the write side. Do keep in mind that a server may close the socket for further writes after replying to a number of requests (ideally sending an SSL close notify, i.e. SSL_shutdown() as it does so), at which point the SSL connection is half-closed. With a full-duplex protocol, you may also need to handle reading outstanding replies on a connection that no longer supports writes. -- Viktor. From John.Unsworth at synchronoss.com Thu May 2 17:27:28 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 2 May 2019 17:27:28 +0000 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: <20190502172322.GC67454@straasha.imrryr.org> References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> <20190502172322.GC67454@straasha.imrryr.org> Message-ID: >> I think that's an application bug. Thanks. I thought you might say that. I will change the code and get the customer to retest. Regards, John -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: 02 May 2019 18:23 To: openssl-users at openssl.org Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN CAUTION: This email originated from outside of Synchronoss. On Thu, May 02, 2019 at 04:10:31PM +0000, John Unsworth wrote: > > Do you wait for the non-blocking connect to complete at this point? > We connect in blocking mode then switch to non-blocking. Thanks that rules connection setup out of the picture. > > Are multiple threads writing to the same SSL connection? How do you > > ensure orderly use of the SSL connection? Sharing connections > > across threads without application level synchronization is not > > supported in OpenSSL. > > We use mutexes to synchronize of course. OK. > > How are further requests locked out when you're performing reads? > > What is the granularity of the relevant locks? > > The mutex only allows one SSL call at a time. So a serialized mix of reads and writes with possibly multiple outstanding writes interleaved with the reader? Right? > > At this point you'd be calling SSL_get_error(), is there a lock that > > prevents writes between SSL_read() and SSL_read() and SSL_get_error()? > > The mutex does not protect SSL_get_error() calls. I think that's an application bug. The SSL_get_error() is using the same SSL handle as the SSL_read(), which can be materially altered by concurrent writes. (Matt, if you're still reading this thread, do you agree?) I would not release the mutex until after the call to SSL_get_error(). > > I gather the protocol is full-duplex and multiple outstanding > > requests can be written before the corresponding replies are read? > > Or is it strict half-duplex request-response? > > It is full duplex and there can be multiple operations in progress. Please retest with both the SSL_read() and SSL_get_error() running under a single lock. And similarly on the write side. Do keep in mind that a server may close the socket for further writes after replying to a number of requests (ideally sending an SSL close notify, i.e. SSL_shutdown() as it does so), at which point the SSL connection is half-closed. With a full-duplex protocol, you may also need to handle reading outstanding replies on a connection that no longer supports writes. -- Viktor. From matt at openssl.org Fri May 3 09:16:22 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 May 2019 10:16:22 +0100 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: <20190502172322.GC67454@straasha.imrryr.org> References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> <20190502172322.GC67454@straasha.imrryr.org> Message-ID: <203b943f-2fb1-e9e6-7ced-8ca299820202@openssl.org> On 02/05/2019 18:23, Viktor Dukhovni wrote: >>> At this point you'd be calling SSL_get_error(), is there a lock that >>> prevents writes between SSL_read() and SSL_read() and SSL_get_error()? >> >> The mutex does not protect SSL_get_error() calls. > > I think that's an application bug. The SSL_get_error() is using > the same SSL handle as the SSL_read(), which can be materially > altered by concurrent writes. (Matt, if you're still reading this > thread, do you agree?) > > I would not release the mutex until after the call to SSL_get_error(). An SSL object should not be used in multiple threads at the same time no matter what the API call. This applies to SSL_get_error() as well. If you are doing that then that could most definitely cause the behaviour you are seeing. Matt From John.Unsworth at synchronoss.com Fri May 3 09:34:14 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Fri, 3 May 2019 09:34:14 +0000 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: <203b943f-2fb1-e9e6-7ced-8ca299820202@openssl.org> References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> <20190502172322.GC67454@straasha.imrryr.org>, <203b943f-2fb1-e9e6-7ced-8ca299820202@openssl.org> Message-ID: Testing changed code. Regards John ________________________________ From: openssl-users on behalf of Matt Caswell Sent: Friday, May 3, 2019 10:16 am To: openssl-users at openssl.org Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN CAUTION: This email originated from outside of Synchronoss. On 02/05/2019 18:23, Viktor Dukhovni wrote: >>> At this point you'd be calling SSL_get_error(), is there a lock that >>> prevents writes between SSL_read() and SSL_read() and SSL_get_error()? >> >> The mutex does not protect SSL_get_error() calls. > > I think that's an application bug. The SSL_get_error() is using > the same SSL handle as the SSL_read(), which can be materially > altered by concurrent writes. (Matt, if you're still reading this > thread, do you agree?) > > I would not release the mutex until after the call to SSL_get_error(). An SSL object should not be used in multiple threads at the same time no matter what the API call. This applies to SSL_get_error() as well. If you are doing that then that could most definitely cause the behaviour you are seeing. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rama.krushna7 at gmail.com Fri May 3 15:18:05 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Fri, 3 May 2019 20:48:05 +0530 Subject: Reg Change in Error Code Message-ID: Hi, When client(openssl) is configured with TLSv1 and Server(java) was configured with TLSv1_2, then in openssl version 1.1.0e we used to get the error code : 337002677( 0x141640B5). But with openssl 1.1.1 upgrade the error code changed to 337285301 (0x141A90B5). Moreover Earlier in java also we used to see "javax.net.ssl.SSLHandshakeException: Caused by: Remote host closed connection during handshake " exception at the server end which is not seen now. Following are my doubts. 1) Has anyone noticed this change ? 2) Where these error codes ( 337002677) and (337285301) defined ? 3) Why the java server will not throw the exception any more ? Any help is highly appreciated. Thanks and Regards, Ram Krushna -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri May 3 15:46:23 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 May 2019 16:46:23 +0100 Subject: Reg Change in Error Code In-Reply-To: References: Message-ID: On 03/05/2019 16:18, ramakrushna mishra wrote: > Hi, > > When client(openssl) is configured with TLSv1 and Server(java) was configured > with TLSv1_2, then in openssl version 1.1.0e we used to get the error code > :?337002677( 0x141640B5). But with openssl 1.1.1 upgrade the error code changed > to 337285301 > (0x141A90B5). Moreover Earlier in java also we used to see > "javax.net.ssl.SSLHandshakeException: Caused by: Remote host closed connection > during handshake " exception at the server end which is not seen now.? > > Following are my doubts.? > > 1) Has anyone noticed this change ?? > 2) Where these error codes ( 337002677) and (337285301) defined ? You can use the command line "errstr" utility for the relevant openssl version to check their meanings. For 1.1.0e: $ openssl errstr 141640B5 error:141640B5:SSL routines:tls_construct_client_hello:no ciphers available For 1.1.1: $ openssl errstr 141A90B5 error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available You can also get your application to generate these human readable error strings using the appropriate functions: https://www.openssl.org/docs/man1.1.1/man3/ERR_error_string.html Error codes are highly version specific and may change from one version to another. We do not provide any guarantee that the same error will always produce the same error code - so you should not rely on them remaining static. The different components of the error string tell you different things about the cause of the error. "SSL routines" tells us that the error came from libssl. "tls_construct_client_hello" tells us the name of the function in the source code that generated the error. Finally "no ciphers available" tells us specifically what the error was. In this case "no ciphers available" means that there are no configured ciphersuites that are suitable for use in your configuration. For example if your client is configured to only use TLSv1 but you've only configured ciphersuites suitable for use in TLSv1.2 then you will get this error. (Incidentally it seems very strange to use 1.1.0/1.1.1 but then restrict the client to using TLSv1 only - I'd recommend using the highest protocol version available for the library in use) This error occurs in the "tls_construct_client_hello" function (in 1.1.0e) which is very early in the handshake process. It occurs during construction of the very first message sent by the client (the ClientHello). It appears that in 1.1.1 the function that does this check has changed. It is now done in "ssl_cipher_list_to_bytes". This function is called from "tls_construct_client_hello". This is why the error code has changed - but it is the same underlying cause. ? > 3) Why the java server will not throw the exception any more ? Looking at the code it appears that in 1.1.0e the client just abandons the connection attempt without sending any error alert to the server. In 1.1.1 it now sends an "internal_error" alert first. This is most likely the cause of the change of behaviour on the server side. Matt > ? > Any help is highly appreciated.? > > Thanks and?Regards, > Ram Krushna From openssl-users at dukhovni.org Fri May 3 15:58:56 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 3 May 2019 11:58:56 -0400 Subject: Any timeframe for the 1.1.1c release? In-Reply-To: <25d62169-37c3-3fd8-5e3b-041532ea2c4a@openssl.org> References: <25d62169-37c3-3fd8-5e3b-041532ea2c4a@openssl.org> Message-ID: <3BECA507-6AE2-40CA-981A-C08400767957@dukhovni.org> > On May 2, 2019, at 12:09 PM, Matt Caswell wrote: > >> when is the 1.1.1c expected to be released? There were plenty of bug >> fixes committed to the 1.1.1 branch since the 1.1.1b release. Is the >> 1.1.1c release imminent? > > There are no plans at the moment. There should perhaps be a 1.1.1c soonish... There are indeed many useful improvements committed, but not yet released. -- Viktor. From openssl-users at dukhovni.org Fri May 3 22:04:05 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 3 May 2019 18:04:05 -0400 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> <20190502172322.GC67454@straasha.imrryr.org> <203b943f-2fb1-e9e6-7ced-8ca299820202@openssl.org> Message-ID: <20190503220405.GF67454@straasha.imrryr.org> On Fri, May 03, 2019 at 09:34:14AM +0000, John Unsworth wrote: > Testing changed code. For the record, though I think you realise this, *both* the SSL_read() or SSL_write() and the following SSL_get_error() need to be protected as a unit by the *same* instance of the locked mutex. It would not be enough to lock these separately. acquire_lock(); if (reading) ret = SSL_read(ssl, ...); else ret = SSL_write(ssl, ...); if (ret <= 0) err = SSL_get_error(ssl, ret); release_lock(); /* Handle EOF and errors */ -- Viktor. From rama.krushna7 at gmail.com Sat May 4 03:54:33 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Sat, 4 May 2019 09:24:33 +0530 Subject: Reg Change in Error Code In-Reply-To: References: Message-ID: Hi Matt, Thanks for the detailed response. As you suggested there is definitely a lot to improve in our code to convey the correct meaning of the code. I have tested with the changes and it conveyed the correct meaning now as you clearly stated. I just have one more doubt. Now I tried to test with the code with an ongoing customer scenario where we do not get any error or error string or the libssl method name as well. Mostly it happens when SSL_get_error() after SSL_do_handshake() returns SSL_ERROR_SYSCALL. Is there any way to capture more information about this error ? Thanks a lot again for your timely response. Regards, Ram Krushna On Sat, May 4, 2019 at 3:34 AM wrote: > Send openssl-users mailing list submissions to > openssl-users at openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-request at openssl.org > > You can reach the person managing the list at > openssl-users-owner at openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > > 1. Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 > EAGAIN (John Unsworth) > 2. Reg Change in Error Code (ramakrushna mishra) > 3. Re: Reg Change in Error Code (Matt Caswell) > 4. Re: Any timeframe for the 1.1.1c release? (Viktor Dukhovni) > 5. Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 > EAGAIN (Viktor Dukhovni) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 3 May 2019 09:34:14 +0000 > From: John Unsworth > To: "openssl-users at openssl.org" > Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 > EAGAIN > Message-ID: > < > DM6PR07MB4650AF92014D45DBB2017095F5350 at DM6PR07MB4650.namprd07.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Testing changed code. > > Regards > John > > ________________________________ > From: openssl-users on behalf of Matt > Caswell > Sent: Friday, May 3, 2019 10:16 am > To: openssl-users at openssl.org > Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN > > CAUTION: This email originated from outside of Synchronoss. > > > On 02/05/2019 18:23, Viktor Dukhovni wrote: > >>> At this point you'd be calling SSL_get_error(), is there a lock that > >>> prevents writes between SSL_read() and SSL_read() and SSL_get_error()? > >> > >> The mutex does not protect SSL_get_error() calls. > > > > I think that's an application bug. The SSL_get_error() is using > > the same SSL handle as the SSL_read(), which can be materially > > altered by concurrent writes. (Matt, if you're still reading this > > thread, do you agree?) > > > > I would not release the mutex until after the call to SSL_get_error(). > > An SSL object should not be used in multiple threads at the same time no > matter > what the API call. This applies to SSL_get_error() as well. If you are > doing > that then that could most definitely cause the behaviour you are seeing. > > Matt > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mta.openssl.org/pipermail/openssl-users/attachments/20190503/7209280b/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Fri, 3 May 2019 20:48:05 +0530 > From: ramakrushna mishra > To: openssl-users at openssl.org > Subject: Reg Change in Error Code > Message-ID: > kKorZgv4ezpaT6nxtioqJPvyS-w2rVRvA7YC0CBT5gk6Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > When client(openssl) is configured with TLSv1 and Server(java) was > configured with TLSv1_2, then in openssl version 1.1.0e we used to get the > error code : 337002677( 0x141640B5). But with openssl 1.1.1 upgrade the > error code changed to 337285301 > (0x141A90B5). Moreover Earlier in java also we used to see > "javax.net.ssl.SSLHandshakeException: Caused by: Remote host closed > connection during handshake " exception at the server end which is not seen > now. > > Following are my doubts. > > 1) Has anyone noticed this change ? > 2) Where these error codes ( 337002677) and (337285301) defined ? > 3) Why the java server will not throw the exception any more ? > > Any help is highly appreciated. > > Thanks and Regards, > Ram Krushna > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mta.openssl.org/pipermail/openssl-users/attachments/20190503/3368e8cb/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Fri, 3 May 2019 16:46:23 +0100 > From: Matt Caswell > To: openssl-users at openssl.org > Subject: Re: Reg Change in Error Code > Message-ID: > Content-Type: text/plain; charset=utf-8 > > > > On 03/05/2019 16:18, ramakrushna mishra wrote: > > Hi, > > > > When client(openssl) is configured with TLSv1 and Server(java) was > configured > > with TLSv1_2, then in openssl version 1.1.0e we used to get the error > code > > :?337002677( 0x141640B5). But with openssl 1.1.1 upgrade the error code > changed > > to 337285301 > > (0x141A90B5). Moreover Earlier in java also we used to see > > "javax.net.ssl.SSLHandshakeException: Caused by: Remote host closed > connection > > during handshake " exception at the server end which is not seen now.? > > > > Following are my doubts.? > > > > 1) Has anyone noticed this change ?? > > 2) Where these error codes ( 337002677) and (337285301) defined ? > > You can use the command line "errstr" utility for the relevant openssl > version > to check their meanings. For 1.1.0e: > > $ openssl errstr 141640B5 > error:141640B5:SSL routines:tls_construct_client_hello:no ciphers available > > For 1.1.1: > $ openssl errstr 141A90B5 > error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available > > You can also get your application to generate these human readable error > strings > using the appropriate functions: > > https://www.openssl.org/docs/man1.1.1/man3/ERR_error_string.html > > Error codes are highly version specific and may change from one version to > another. We do not provide any guarantee that the same error will always > produce > the same error code - so you should not rely on them remaining static. The > different components of the error string tell you different things about > the > cause of the error. "SSL routines" tells us that the error came from > libssl. > "tls_construct_client_hello" tells us the name of the function in the > source > code that generated the error. Finally "no ciphers available" tells us > specifically what the error was. > > In this case "no ciphers available" means that there are no configured > ciphersuites that are suitable for use in your configuration. For example > if > your client is configured to only use TLSv1 but you've only configured > ciphersuites suitable for use in TLSv1.2 then you will get this error. > (Incidentally it seems very strange to use 1.1.0/1.1.1 but then restrict > the > client to using TLSv1 only - I'd recommend using the highest protocol > version > available for the library in use) > > This error occurs in the "tls_construct_client_hello" function (in 1.1.0e) > which > is very early in the handshake process. It occurs during construction of > the > very first message sent by the client (the ClientHello). > > It appears that in 1.1.1 the function that does this check has changed. It > is > now done in "ssl_cipher_list_to_bytes". This function is called from > "tls_construct_client_hello". This is why the error code has changed - but > it is > the same underlying cause. > ? > > 3) Why the java server will not throw the exception any more ? > > Looking at the code it appears that in 1.1.0e the client just abandons the > connection attempt without sending any error alert to the server. In 1.1.1 > it > now sends an "internal_error" alert first. This is most likely the cause > of the > change of behaviour on the server side. > > Matt > > > > > ? > > Any help is highly appreciated.? > > > > Thanks and?Regards, > > Ram Krushna > > > ------------------------------ > > Message: 4 > Date: Fri, 3 May 2019 11:58:56 -0400 > From: Viktor Dukhovni > To: "openssl-users at openssl.org" > Subject: Re: Any timeframe for the 1.1.1c release? > Message-ID: <3BECA507-6AE2-40CA-981A-C08400767957 at dukhovni.org> > Content-Type: text/plain; charset=us-ascii > > > On May 2, 2019, at 12:09 PM, Matt Caswell wrote: > > > >> when is the 1.1.1c expected to be released? There were plenty of bug > >> fixes committed to the 1.1.1 branch since the 1.1.1b release. Is the > >> 1.1.1c release imminent? > > > > There are no plans at the moment. > > There should perhaps be a 1.1.1c soonish... There are indeed many useful > improvements committed, but not yet released. > > -- > Viktor. > > > > ------------------------------ > > Message: 5 > Date: Fri, 3 May 2019 18:04:05 -0400 > From: Viktor Dukhovni > To: openssl-users at openssl.org > Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 > EAGAIN > Message-ID: <20190503220405.GF67454 at straasha.imrryr.org> > Content-Type: text/plain; charset=us-ascii > > On Fri, May 03, 2019 at 09:34:14AM +0000, John Unsworth wrote: > > > Testing changed code. > > For the record, though I think you realise this, *both* the SSL_read() > or SSL_write() and the following SSL_get_error() need to be protected > as a unit by the *same* instance of the locked mutex. It would not > be enough to lock these separately. > > acquire_lock(); > if (reading) > ret = SSL_read(ssl, ...); > else > ret = SSL_write(ssl, ...); > if (ret <= 0) > err = SSL_get_error(ssl, ret); > release_lock(); > > /* Handle EOF and errors */ > > -- > Viktor. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users > > > ------------------------------ > > End of openssl-users Digest, Vol 54, Issue 4 > ******************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sat May 4 08:57:12 2019 From: matt at openssl.org (Matt Caswell) Date: Sat, 4 May 2019 09:57:12 +0100 Subject: Reg Change in Error Code In-Reply-To: References: Message-ID: <903be6fb-8949-6a5d-b649-3e6a1d2ec818@openssl.org> On 04/05/2019 04:54, ramakrushna mishra wrote: > Hi Matt, > > Thanks for the detailed response.? > As you suggested there is definitely a lot to improve in our code to convey the > correct meaning of the code.? I have tested with the changes and it conveyed the > correct meaning now as you clearly stated.? > > I just have one more doubt. Now I tried to test with the code with an ongoing > customer scenario where we do not get any error or error string or the libssl > method name as well. Mostly it happens when SSL_get_error() after > SSL_do_handshake() returns?SSL_ERROR_SYSCALL.? > > Is there any way to capture more information about this error ? The man pages have this description for SSL_ERROR_SYSCALL: SSL_ERROR_SYSCALL Some non-recoverable, fatal I/O error occurred. The OpenSSL error queue may contain more information on the error. For socket I/O on Unix systems, consult errno for details. If this error occurs then no further I/O operations should be performed on the connection and SSL_shutdown() must not be called. This value can also be returned for other errors, check the error queue for details. So I'd suggest you check errno in such a scenario. Matt From tniessen at tnie.de Sun May 5 13:15:58 2019 From: tniessen at tnie.de (=?UTF-8?Q?Tobias_Nie=c3=9fen?=) Date: Sun, 5 May 2019 15:15:58 +0200 Subject: Custom secure heap implementation Message-ID: <855e685d-8470-3a02-3fb1-e2d5ba7c6ce5@tnie.de> Hello, I have been experimenting with a custom secure heap implementation recently. Would OpenSSL be open to a patch that allows users to replace the OpenSSL implementation with their own, similarly to how CRYPTO_set_mem_functions works? Based on mem_sec.c, at least sh_malloc, sh_free, sh_actual_size and sh_allocated need to be pluggable, probably also a new function for CRYPTO_secure_used. Also, should thread safety be part of OpenSSL as it is right now (via sec_malloc_lock), or should it be up to the implementation? Regards, Tobias From paul at mad-scientist.net Sun May 5 13:46:32 2019 From: paul at mad-scientist.net (Paul Smith) Date: Sun, 05 May 2019 09:46:32 -0400 Subject: Shutdown examples/explanations Message-ID: <5e378487e2a7646bb6d9c55e015318d7b09d8aca.camel@mad-scientist.net> Does anyone have a straightforward example of the canonical way to handle SSL_shutdown() in OpenSSL 1.1.1? I mean both when my code is the initiator of the shutdown and also when I'm the peer, and also for both blocking and non-blocking BIOs? I've read and re-read the SSL_shutdown() man page and it seems to me that there's a lot of conflicting content there. It says you can call SSL_shutdown() twice, and it also says "However, it is recommended to wait for it using SSL_read() instead". It says "It is not possible to call SSL_write() after calling SSL_shutdown()", but it also says that for non-blocking BIOs, we might get an SSL_ERROR_WANT_WRITE and the calling process "must take appropriate action to satisfy the needs of SSL_shutdown()"... what "appropriate action" is is not clearly specified but I assume it means invoke SSL_write(). Under RETURN VALUES <0 it says the shutdown was not successful, but then says we can get this if an action is needed to continue the operation for non-blocking BIOs... by "continue the operation" does that mean call SSL_read() again? If so what's the difference in behavior of my code between SSL_shutdown() returning 0 or <0? I just wish the docs would say what the recommended best practices are in a clear way, rather than offering lots of not-very-clear alternatives, or that there was example code somewhere of how the OpenSSL devs designed this to be handled. Also as a separate question, if I'm always going to be closing my socket once the shutdown is complete is there any advantage in worrying about bi-directional shutdown, versus simply calling SSL_shutdown(), ignoring the return value, and closing the socket? I would like my code to be a good neighbor and play nicely with others but if it doesn't matter I guess I could side-step all the above confusion and simply get out. Let me also assume that the peer may not be reading the socket constantly. For example suppose the peer is an interactive shell of some kind and it's sitting at a prompt waiting for user input and not invoking SSL_read() etc. Is it possible to ever complete a bi- directional handshake shutdown with that peer anyway? If we need to wait for it to reply I don't see how. From director at openca.org Mon May 6 02:13:01 2019 From: director at openca.org (Dr. Pala) Date: Sun, 5 May 2019 20:13:01 -0600 Subject: How to Sign and Encrypt in CMS ? In-Reply-To: <25d62169-37c3-3fd8-5e3b-041532ea2c4a@openssl.org> References: <25d62169-37c3-3fd8-5e3b-041532ea2c4a@openssl.org> Message-ID: <13ea8409-ec0b-1131-fd53-cbe425893c34@openca.org> Hi All, small question - I was playing around with the CMS interface and I was wondering what is the right way to generate a signed and encrypted CMS. In particular, for PKCS#7, you could use the signed_and_encrypted choice... but in CMS, there is the envelopedData ... but that does not allow for signing... ??? And for the signed data, there is the signedData type... but that does not allow for encryption... The EncryptedData is for use with PSK - not a case I am interested into... So... what is the right way of doing it ? And when you receive such CMS, how do you extract the encryption algorithm from the EnvelopedData/EncryptedContentInfo (I can not find the helper function...) ? Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iijkmgiafamdaajo.png Type: image/png Size: 3146 bytes Desc: not available URL: From paul.dale at oracle.com Mon May 6 05:07:39 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 6 May 2019 15:07:39 +1000 Subject: Custom secure heap implementation In-Reply-To: <855e685d-8470-3a02-3fb1-e2d5ba7c6ce5@tnie.de> References: <855e685d-8470-3a02-3fb1-e2d5ba7c6ce5@tnie.de> Message-ID: We would consider a patch of this nature. There are plenty of platforms where we don?t know and don?t support secure memory. Having customisable hooks would allow them secure memory too. Yes, is *must* be thread safe ? just like the existing implementation. The malloc and free are the important calls. I?m not sure the size and allocated calls are used widely (but it?s worth a check). Secure memory *always* cleanses currently and I don?t see that changing ? if something is important enough to put in secure memory, it?s important enough to zero on free. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 5 May 2019, at 11:15 pm, Tobias Nie?en wrote: > > Hello, > > I have been experimenting with a custom secure heap implementation recently. Would OpenSSL be open to a patch that allows users to replace the OpenSSL implementation with their own, similarly to how CRYPTO_set_mem_functions works? Based on mem_sec.c, at least sh_malloc, sh_free, sh_actual_size and sh_allocated need to be pluggable, probably also a new function for CRYPTO_secure_used. > > Also, should thread safety be part of OpenSSL as it is right now (via sec_malloc_lock), or should it be up to the implementation? > > Regards, > Tobias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon May 6 14:52:05 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 6 May 2019 14:52:05 +0000 Subject: Custom secure heap implementation In-Reply-To: <855e685d-8470-3a02-3fb1-e2d5ba7c6ce5@tnie.de> References: <855e685d-8470-3a02-3fb1-e2d5ba7c6ce5@tnie.de> Message-ID: The intent is that you replace the upper layer, CRYPTO_secure_xxxxx What does your implementation do differently, and which platforms does it work on? From openssl at mirko.wtf Mon May 6 15:41:39 2019 From: openssl at mirko.wtf (Mirko J. Ploch) Date: Mon, 6 May 2019 11:41:39 -0400 Subject: EVP_aes_128_cbc_hmac_sha256() not working on arm64 architecture Message-ID: Hello, I'm trying to use EVP_aes_128_cbc_hmac_sha256() for encryption on an iOS device with arm64 architecture. I was able to get it working with the x86_64 architecture when running the iOS device simulator on an iMac. Is this just not capable of working on an arm64 platform? Looking at the code for EVP_aes_128_cbc_hmac_sha256, it does not look like it. I'm hoping that there is a way to get it working. https://github.com/openssl/openssl/blob/OpenSSL_1_1_1b/crypto/evp/e_aes_cbc_hmac_sha256.c Thank you, Mirko J. Ploch -------------- next part -------------- An HTML attachment was scrubbed... URL: From tniessen at tnie.de Mon May 6 18:18:45 2019 From: tniessen at tnie.de (=?UTF-8?Q?Tobias_Nie=c3=9fen?=) Date: Mon, 6 May 2019 20:18:45 +0200 Subject: Custom secure heap implementation In-Reply-To: References: <855e685d-8470-3a02-3fb1-e2d5ba7c6ce5@tnie.de> Message-ID: <883600ca-81ce-e160-3265-246acc6d3d7a@tnie.de> > What does your implementation do differently, and which platforms does it work on? It is still an early prototype, but it already allows dynamic expansion of the secure heap (as well as shrinking) and I hope to add support for Microsoft Windows after the POSIX / Linux implementation. From wiml at omnigroup.com Mon May 6 19:03:33 2019 From: wiml at omnigroup.com (Wim Lewis) Date: Mon, 6 May 2019 12:03:33 -0700 Subject: How to Sign and Encrypt in CMS ? In-Reply-To: <13ea8409-ec0b-1131-fd53-cbe425893c34@openca.org> References: <25d62169-37c3-3fd8-5e3b-041532ea2c4a@openssl.org> <13ea8409-ec0b-1131-fd53-cbe425893c34@openca.org> Message-ID: On May 5, 2019, at 7:13 PM, Dr. Pala wrote: > small question - I was playing around with the CMS interface and I was wondering what is the right way to generate a signed and encrypted CMS. In particular, for PKCS#7, you could use the signed_and_encrypted choice... but in CMS, there is the envelopedData ... but that does not allow for signing... ??? And for the signed data, there is the signedData type... but that does not allow for encryption... The EncryptedData is for use with PSK - not a case I am interested into... There are two common approaches that I know of: - You can combine a SignedData and an EnvelopedData. Depending on your use case you may want to sign first and then envelop(e), or envelope first and then sign. (IIRC, one of the RFCs suggests sign-envelop-sign, though I can't find that text right now.) - You can use the AuthenticatedEnvelopedData type from RFC5083, with an AEAD cipher mode. (This does not provide a signature, but it does provide an integrity check which may be sufficient for your needs. You can also combine it with SignedData, of course.) Note that SignedAndEnvelopedData is part of PKCS#7 but wasn't included in CMS; even PKCS#7 (RFC2315) suggests that "the sequential combination of signed-data and enveloped-data content types is generally preferable to the SignedAndEnvelopedData content type" unless you need it for compatibility reasons. Also, last time I tried, OpenSSL's API made it kind of tricky to produce a correctly formed sign-envelop or envelop-sign message; that may have improved since then, though. From John.Unsworth at synchronoss.com Tue May 7 08:05:59 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Tue, 7 May 2019 08:05:59 +0000 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: <20190503220405.GF67454@straasha.imrryr.org> References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> <20190502172322.GC67454@straasha.imrryr.org> <203b943f-2fb1-e9e6-7ced-8ca299820202@openssl.org> <20190503220405.GF67454@straasha.imrryr.org> Message-ID: Thanks, the mutex is tied to the SSL session and used for all calls (now!). The good news is that moving SSL_get_error() into the same mutex unit as SSL_read() has solved the problem. Thank you for all your help and advice. Regards, John. John Unsworth?|Meta-Directory Engineering and Support Mobile: +44 777.557.2643 -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: 03 May 2019 23:04 To: openssl-users at openssl.org Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN CAUTION: This email originated from outside of Synchronoss. On Fri, May 03, 2019 at 09:34:14AM +0000, John Unsworth wrote: > Testing changed code. For the record, though I think you realise this, *both* the SSL_read() or SSL_write() and the following SSL_get_error() need to be protected as a unit by the *same* instance of the locked mutex. It would not be enough to lock these separately. acquire_lock(); if (reading) ret = SSL_read(ssl, ...); else ret = SSL_write(ssl, ...); if (ret <= 0) err = SSL_get_error(ssl, ret); release_lock(); /* Handle EOF and errors */ -- Viktor. From John.Unsworth at synchronoss.com Tue May 7 08:20:19 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Tue, 7 May 2019 08:20:19 +0000 Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN In-Reply-To: References: <614A733C-FBB7-4031-B344-180A55475D79@dukhovni.org> <9E796689-E866-4983-A2A9-5056B4BB49A8@dukhovni.org> <20190502172322.GC67454@straasha.imrryr.org> <203b943f-2fb1-e9e6-7ced-8ca299820202@openssl.org> <20190503220405.GF67454@straasha.imrryr.org> Message-ID: Just a thought. Would it not be possible for the SSL session to create a mutex and lock it where required? Error details could be stored in Thread Local Storage to obliviate the need to call SSL_get_error() within the mutex block. Regards, John -----Original Message----- From: openssl-users On Behalf Of John Unsworth Sent: 07 May 2019 09:06 To: openssl-users at openssl.org Subject: RE: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN CAUTION: This email originated from outside of Synchronoss. Thanks, the mutex is tied to the SSL session and used for all calls (now!). The good news is that moving SSL_get_error() into the same mutex unit as SSL_read() has solved the problem. Thank you for all your help and advice. Regards, John. -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: 03 May 2019 23:04 To: openssl-users at openssl.org Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN CAUTION: This email originated from outside of Synchronoss. On Fri, May 03, 2019 at 09:34:14AM +0000, John Unsworth wrote: > Testing changed code. For the record, though I think you realise this, *both* the SSL_read() or SSL_write() and the following SSL_get_error() need to be protected as a unit by the *same* instance of the locked mutex. It would not be enough to lock these separately. acquire_lock(); if (reading) ret = SSL_read(ssl, ...); else ret = SSL_write(ssl, ...); if (ret <= 0) err = SSL_get_error(ssl, ret); release_lock(); /* Handle EOF and errors */ -- Viktor. From antiac at gmail.com Tue May 7 11:00:38 2019 From: antiac at gmail.com (Antonio Iacono) Date: Tue, 7 May 2019 13:00:38 +0200 Subject: How to Sign and Encrypt in CMS ? In-Reply-To: <13ea8409-ec0b-1131-fd53-cbe425893c34@openca.org> References: <25d62169-37c3-3fd8-5e3b-041532ea2c4a@openssl.org> <13ea8409-ec0b-1131-fd53-cbe425893c34@openca.org> Message-ID: > > > I was playing around with the CMS interface and I was wondering what is > the right way to generate a signed and encrypted CMS. > take a look at this thread https://marc.info/?l=openssl-users&m=141606382825289 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iijkmgiafamdaajo.png Type: image/png Size: 3146 bytes Desc: not available URL: From matt at openssl.org Tue May 7 15:44:24 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 May 2019 16:44:24 +0100 Subject: EVP_aes_128_cbc_hmac_sha256() not working on arm64 architecture In-Reply-To: References: Message-ID: <438c496d-f466-88d8-766b-3290e1aa6ec1@openssl.org> On 06/05/2019 16:41, Mirko J. Ploch wrote: > Hello, > > I'm trying to use?EVP_aes_128_cbc_hmac_sha256() for encryption on an iOS device > with arm64 architecture. I was able to get it working with the x86_64 > architecture when running the iOS device simulator on an iMac. Is this just not > capable of working on an arm64 platform? > > Looking at the code for EVP_aes_128_cbc_hmac_sha256, it does not look like it. > I'm hoping that there is a way to get it working. > https://github.com/openssl/openssl/blob/OpenSSL_1_1_1b/crypto/evp/e_aes_cbc_hmac_sha256.c This cipher is a special purpose cipher not intended for general use. It is specifically targeted at usage in TLS. Unless you're writing a TLS stack you probably don't want to use this. It is only available on some platforms and does runtime detection to check whether the platform is suitable or not. Most importantly the platform must have AES-NI support. It's usefulness even in a TLS stack is somewhat limited these days since it is not relevant for TLSv1.3 and does not get used if encrypt-then-mac is negotiated (which recent versions of OpenSSL will try to negotiate by default). Matt From openssl at mirko.wtf Tue May 7 19:47:02 2019 From: openssl at mirko.wtf (Mirko J. Ploch) Date: Tue, 7 May 2019 15:47:02 -0400 Subject: EVP_aes_128_cbc_hmac_sha256() not working on arm64 architecture In-Reply-To: <438c496d-f466-88d8-766b-3290e1aa6ec1@openssl.org> References: <438c496d-f466-88d8-766b-3290e1aa6ec1@openssl.org> Message-ID: Thank you for your response. You answered my question. It is not available on my target platform architecture (arm64). I do have a specific need for that cipher, and it does not have anything to do with TLS. An app that I am working on requires it for JSON Web Encryption (JWE) as the required encryption algorithm. https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31#appendix-B Best Regards, Mirko On Tue, May 7, 2019 at 11:45 AM Matt Caswell wrote: > > > On 06/05/2019 16:41, Mirko J. Ploch wrote: > > Hello, > > > > I'm trying to use EVP_aes_128_cbc_hmac_sha256() for encryption on an iOS > device > > with arm64 architecture. I was able to get it working with the x86_64 > > architecture when running the iOS device simulator on an iMac. Is this > just not > > capable of working on an arm64 platform? > > > > Looking at the code for EVP_aes_128_cbc_hmac_sha256, it does not look > like it. > > I'm hoping that there is a way to get it working. > > > https://github.com/openssl/openssl/blob/OpenSSL_1_1_1b/crypto/evp/e_aes_cbc_hmac_sha256.c > > This cipher is a special purpose cipher not intended for general use. It is > specifically targeted at usage in TLS. Unless you're writing a TLS stack > you > probably don't want to use this. It is only available on some platforms > and does > runtime detection to check whether the platform is suitable or not. Most > importantly the platform must have AES-NI support. > > It's usefulness even in a TLS stack is somewhat limited these days since > it is > not relevant for TLSv1.3 and does not get used if encrypt-then-mac is > negotiated > (which recent versions of OpenSSL will try to negotiate by default). > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue May 7 21:10:19 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 7 May 2019 23:10:19 +0200 Subject: EVP_aes_128_cbc_hmac_sha256() not working on arm64 architecture In-Reply-To: References: <438c496d-f466-88d8-766b-3290e1aa6ec1@openssl.org> Message-ID: For future library versions (4.x or whatever), it would be useful to make these combo-ciphers be better documented and available via library-level calls to separate block and mac operations where optimized intertwined implementations are not provided. Obviously, the set of such combo loops should be enhanced with the CBC-then-HMAC and other now popular combinations. But just because SSL notoriously did the surrounding logic (padding, IV management etc.) completely wrong every time (CBC then MAC is also a weak choice!) doesn't mean the composition of doing HMAC on CBC input is inherently bad in skilled hands. Blindly using only whatever is now in fashion isn't necessarily safe either, they just haven't found and published the attacks yet. On 07/05/2019 21:47, Mirko J. Ploch wrote: > Thank you for your response. You answered my question. It is not > available on my target platform architecture (arm64). > > I do have a specific need for that cipher, and it does not have > anything to do with TLS. An app that I am working on requires it for > JSON Web Encryption (JWE) as the required encryption algorithm. > > https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31#appendix-B > > On Tue, May 7, 2019 at 11:45 AM Matt Caswell > wrote: > > > > On 06/05/2019 16:41, Mirko J. Ploch wrote: > > Hello, > > > > I'm trying to use?EVP_aes_128_cbc_hmac_sha256() for encryption > on an iOS device > > with arm64 architecture. I was able to get it working with the > x86_64 > > architecture when running the iOS device simulator on an iMac. > Is this just not > > capable of working on an arm64 platform? > > > > Looking at the code for EVP_aes_128_cbc_hmac_sha256, it does not > look like it. > > I'm hoping that there is a way to get it working. > > > https://github.com/openssl/openssl/blob/OpenSSL_1_1_1b/crypto/evp/e_aes_cbc_hmac_sha256.c > > This cipher is a special purpose cipher not intended for general > use. It is > specifically targeted at usage in TLS. Unless you're writing a TLS > stack you > probably don't want to use this. It is only available on some > platforms and does > runtime detection to check whether the platform is suitable or > not. Most > importantly the platform must have AES-NI support. > > It's usefulness even in a TLS stack is somewhat limited these days > since it is > not relevant for TLSv1.3 and does not get used if encrypt-then-mac > is negotiated > (which recent versions of OpenSSL will try to negotiate by default). > > 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 Tue May 7 22:40:50 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 May 2019 23:40:50 +0100 Subject: EVP_aes_128_cbc_hmac_sha256() not working on arm64 architecture In-Reply-To: References: <438c496d-f466-88d8-766b-3290e1aa6ec1@openssl.org> Message-ID: On 07/05/2019 20:47, Mirko J. Ploch wrote: > Thank you for your response. You answered my question. It is not available on my > target platform architecture (arm64). > > I do have a specific need for that cipher, and it does not have anything to do > with TLS. An app that I am working on requires it for?JSON Web Encryption (JWE) > as the required encryption algorithm. > > https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31#appendix-B Then (in spite of the name) this is not the cipher you want to use. This cipher can *only* do the AAD specified for TLS - it is not a general purpose cipher and so will not be capable of doing the AAD specified in that draft. You can probably achieve what you want using EVP_aes_128_cbc() and then using HMAC-SHA256 separately. Matt > > Best Regards, > Mirko > > On Tue, May 7, 2019 at 11:45 AM Matt Caswell > wrote: > > > > On 06/05/2019 16:41, Mirko J. Ploch wrote: > > Hello, > > > > I'm trying to use?EVP_aes_128_cbc_hmac_sha256() for encryption on an iOS > device > > with arm64 architecture. I was able to get it working with the x86_64 > > architecture when running the iOS device simulator on an iMac. Is this > just not > > capable of working on an arm64 platform? > > > > Looking at the code for EVP_aes_128_cbc_hmac_sha256, it does not look like it. > > I'm hoping that there is a way to get it working. > > > https://github.com/openssl/openssl/blob/OpenSSL_1_1_1b/crypto/evp/e_aes_cbc_hmac_sha256.c > > This cipher is a special purpose cipher not intended for general use. It is > specifically targeted at usage in TLS. Unless you're writing a TLS stack you > probably don't want to use this. It is only available on some platforms and does > runtime detection to check whether the platform is suitable or not. Most > importantly the platform must have AES-NI support. > > It's usefulness even in a TLS stack is somewhat limited these days since it is > not relevant for TLSv1.3 and does not get used if encrypt-then-mac is negotiated > (which recent versions of OpenSSL will try to negotiate by default). > > Matt > From openssl at mirko.wtf Wed May 8 14:43:56 2019 From: openssl at mirko.wtf (Mirko J. Ploch) Date: Wed, 8 May 2019 10:43:56 -0400 Subject: EVP_aes_128_cbc_hmac_sha256() not working on arm64 architecture In-Reply-To: References: <438c496d-f466-88d8-766b-3290e1aa6ec1@openssl.org> Message-ID: Thank you Matt. You have been very helpful. On Tue, May 7, 2019 at 6:40 PM Matt Caswell wrote: > > > On 07/05/2019 20:47, Mirko J. Ploch wrote: > > Thank you for your response. You answered my question. It is not > available on my > > target platform architecture (arm64). > > > > I do have a specific need for that cipher, and it does not have anything > to do > > with TLS. An app that I am working on requires it for JSON Web > Encryption (JWE) > > as the required encryption algorithm. > > > > > https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31#appendix-B > > Then (in spite of the name) this is not the cipher you want to use. This > cipher > can *only* do the AAD specified for TLS - it is not a general purpose > cipher and > so will not be capable of doing the AAD specified in that draft. > > You can probably achieve what you want using EVP_aes_128_cbc() and then > using > HMAC-SHA256 separately. > > Matt > > > > > Best Regards, > > Mirko > > > > On Tue, May 7, 2019 at 11:45 AM Matt Caswell > > wrote: > > > > > > > > On 06/05/2019 16:41, Mirko J. Ploch wrote: > > > Hello, > > > > > > I'm trying to use EVP_aes_128_cbc_hmac_sha256() for encryption on > an iOS > > device > > > with arm64 architecture. I was able to get it working with the > x86_64 > > > architecture when running the iOS device simulator on an iMac. Is > this > > just not > > > capable of working on an arm64 platform? > > > > > > Looking at the code for EVP_aes_128_cbc_hmac_sha256, it does not > look like it. > > > I'm hoping that there is a way to get it working. > > > > > > https://github.com/openssl/openssl/blob/OpenSSL_1_1_1b/crypto/evp/e_aes_cbc_hmac_sha256.c > > > > This cipher is a special purpose cipher not intended for general > use. It is > > specifically targeted at usage in TLS. Unless you're writing a TLS > stack you > > probably don't want to use this. It is only available on some > platforms and does > > runtime detection to check whether the platform is suitable or not. > Most > > importantly the platform must have AES-NI support. > > > > It's usefulness even in a TLS stack is somewhat limited these days > since it is > > not relevant for TLSv1.3 and does not get used if encrypt-then-mac > is negotiated > > (which recent versions of OpenSSL will try to negotiate by default). > > > > Matt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Wed May 8 18:15:43 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 08 May 2019 14:15:43 -0400 Subject: configuring callbacks (or not) and SNI vs not... no shared cipher from server end Message-ID: <32734.1557339343@localhost> Diversionary issue: https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html and: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html are pretty vague. I think that SSL_set_tlsext_host_name() is probably intended to be used on the client to set the SNI, but I'm not sure. The legacy cb function returns int, but it's values are not documented. The newer cb function is better documented, but I'm a bit at a loss as to what SSL_client_hello_get0_ext() extracts. Is the CB expected to parse the extensions itself? I guess the point is that CB can set the server certificate to something appropriate, or I think, it could just decide to ignore the SNI value completely and force the certificate regardless. What is the SNI functionality otherwise on the server? Is there any support for picking a certificate based upon the SNI name? EXEC SUMMARY ------------ I am asking because I seem to have run into a situation where it does not seem to do the right thing, but I'm not sure that the error that I'm getting is really about selecting the right certificate, or if there is something else going on. Well, I'm pretty sure that the "no shared cipher" (on server) is wrong. This comes out stderr upon receipt/processing of ClientHello. Things I have tried (described below): 1) making sure that I'm running 1.1.1, which has ECDSA support, and not getting 1.0 shared object by mistake (this has happened before) 2) making sure that the SubjectName contains the target SNI. (with working certificate, it does not matter to server if I use wrong name) 3) observed private key was in different (SEC1 vs PKCS8) format, tried switching that. Many details at: http://www.sandelman.ca/tmp/certprob201905/ A longer story -------------- In testing of a rails-based HTTPS server I have typically just configured a keypair without a lot of thought to the DN used for the server. As I have some (experimental) patches to openssl and ruby-openssl, I often struggle with having the wrong shared object pulled in and then some things do not work. In particular, I would get a message about no shared cipher on the server emitted when something linked in openssl 1.0.x rather than 1.1.x, and I had configured an ECDSA keypair. I'm not sure if it was precisely: 140639813764864:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:2131: (1) which I'm now getting, but it was close to that. I seem to recall that the file name mentioned was one that was in 1.0.x, but not in 1.1.x, which was the clue that I had made a linking error. I got this again yesterday while testing, and wondered if I could excise 1.0.x completely from my laptop, and finally found that it was only an old version of libpq5 that linked against it, and an upgrade (via postgresql.org debian package) eliminated my ruby process from ever linking 1.0.x. Yet the error persisted. I test with the hostname target of "fountain-test.example.com", which I put into my /etc/hosts as ::2 (an alias on lo), and bind against. The private keys are test keys, and I could share them if that was useful. NOTE that both working and failing certificates are generated by ruby code. (2) I went back to a known working situation where a locally generated certificate with that name as the CN was present: (file: http://www.sandelman.ca/tmp/certprob201905/working-cert.txt and .pem) Issuer: DC = ca, DC = sandelman, CN = fountain-test.example.com\0A Unstrung Fountain Root CA Validity Not Before: May 7 22:56:23 2019 GMT Not After : Jun 7 08:56:23 2019 GMT Subject: DC = ca, DC = sandelman, CN = fountain-test.example.com And this one works regardless of what name I use to access it. That is, given: ::2 fountain-test.sandelman.ca fountain-test.example.com n3CE618.router.securehomegateway.ca all three of: %curl -k https://fountain-test.sandelman.ca:8443/version.json {"version":"0.7","revision":"devel"}% %curl -k https://n3CE618.router.securehomegateway.ca:8443/version.json {"version":"0.7","revision":"devel"}% %curl -k https://fountain-test.example.com:8443/version.json {"version":"0.7","revision":"devel"}% work. Using what I think is a similar certificate: /corp/projects/shg/shg_mud_supervisor/spec/files/product/Smarkaklink-n3ce618/jrc_prime256v1.crt Certificate: Data: Version: 3 (0x2) Serial Number: 840664151 (0x321b8457) Signature Algorithm: ecdsa-with-SHA256 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA Validity Not Before: May 8 17:18:37 2019 GMT Not After : Dec 31 00:00:00 2999 GMT Subject: CN = n3CE618.router.securehomegateway.ca Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:56:83:ba:e9:0d:9f:08:f4:b3:67:26:9d:52:b2: 75:5a:47:a2:44:ad:12:14:e4:7e:23:71:84:9b:6c: 2b:f5:69:91:8e:b8:ed:ec:9b:ec:9c:02:2c:b5:03: 7e:58:30:95:50:35:5f:f8:83:32:89:d6:7b:88:63: cf:bb:d3:96:c9 ASN1 OID: prime256v1 NIST CURVE: P-256 it fails: dooku-[projects/shg/shg_reach](2.6.2) mcr 10035 %curl -k https://n3CE618.router.securehomegateway.ca:8443/version.json curl: (35) Unknown SSL protocol error in connection to n3CE618.router.securehomegateway.ca:8443 ... dooku-[projects/shg/shg_mud_supervisor](2.6.2) mcr 10171 %bin/startshg Using rack adapter Thin web server (v1.7.2 codename Bachmanity) Maximum connections set to 1024 Listening on ::2:8443, CTRL+C to stop 139838954243840:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:2131: (3) I observed that one private key (working one) was in SEC1 format ("BEGIN EC PRIVATE KEY"), while the not working one was in PKCS8 format ("BEGIN PRIVATE KEY"). I tried converting: openssl ec -in key.pem -out keysec1.pem %openssl ec -in key.pem -out keysec1.pem read EC key writing EC key %cat keysec1.pem -----BEGIN EC PRIVATE KEY----- ... %cat key.pem -----BEGIN PRIVATE KEY----- but that did not help. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From John.Unsworth at synchronoss.com Wed May 8 18:22:05 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Wed, 8 May 2019 18:22:05 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris Message-ID: I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 Generic_Virtual sun4v sparc SUNW,T5140. ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 -xldscope=hidden It builds fine but all the tests fail, with or without no-asm. Can anyone help please? Here is the start of the test run: $ make test make depend && make _tests ( cd test; \ mkdir -p test-runs; \ SRCTOP=../. \ BLDTOP=../. \ RESULT_D=test-runs \ PERL="/opt/perl-5.26.1/bin/perl" \ EXE_EXT= \ OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ OPENSSL_DEBUG_MEMORY=on \ /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) ../test/recipes/01-test_abort.t .................... ok ../test/recipes/01-test_sanity.t ................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/01-test_symbol_presence.t .......... skipped: Only useful when building shared libraries ../test/recipes/01-test_test.t ..................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/02-test_errstr.t ................... Dubious, test returned 60 (wstat 15360, 0x3c00) Failed 60/76 subtests (less 16 skipped subtests: 0 okay) ../test/recipes/02-test_internal_ctype.t ........... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/02-test_lhash.t .................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/02-test_ordinals.t ................. ok ../test/recipes/02-test_stack.t .................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_exdata.t ................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_asn1.t ............ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_chacha.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_curve448.t ........ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_ec.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_mdc2.t ............ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_modes.t ........... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_poly1305.t ........ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_siphash.t ......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_sm2.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_sm4.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_ssl_cert_table.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_internal_x509.t ............ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/03-test_ui.t ....................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/04-test_asn1_decode.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/04-test_asn1_encode.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/04-test_asn1_string_table.t ........ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/04-test_bio_callback.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Regards, John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed May 8 19:31:10 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 May 2019 15:31:10 -0400 Subject: configuring callbacks (or not) and SNI vs not... no shared cipher from server end In-Reply-To: <32734.1557339343@localhost> References: <32734.1557339343@localhost> Message-ID: <20190508193110.GO67454@straasha.imrryr.org> On Wed, May 08, 2019 at 02:15:43PM -0400, Michael Richardson wrote: > Diversionary issue: > https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html > and: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html > > are pretty vague. I think that SSL_set_tlsext_host_name() is probably > intended to be used on the client to set the SNI, but I'm not sure. Yes, e.g. in the Postfix TLS client: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045 > The legacy cb function returns int, but it's values are not documented. On the server side I'm using SSL_CTX_set_tlsext_servername_callback(): https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043 https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668 > I guess the point is that CB can set the server certificate to something > appropriate, or I think, it could just decide to ignore the SNI value > completely and force the certificate regardless. Yes. > What is the SNI functionality otherwise on the server? You can interpose a secondary "virtual-host-specific" SSL_CTX for for the rest of the handshake. This carries the server certificate, but also the trust store settings for validating client certificates, the settings to request (or not) client certificates, the verification callbacks, ... It is a rather heavyweight object, best cached and re-used for multiple connections. In Postfix, it is configured with the same settings as the initial SSL_CTX, *but* no server certificates. During the SNI callback I interpose the certificate-less context, and then set the certificate chain on the connection handle (SSL *) instead. > Is there any support for picking a certificate based upon the SNI name? The application does the "picking"... The application sets one or more certificate chains (one per supported public key algorithm) that best match the SNI name, and then OpenSSL chooses one of these based on the client's advertised supported signature algorithms, ... -- Viktor. From mcr at sandelman.ca Wed May 8 20:23:38 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 08 May 2019 16:23:38 -0400 Subject: configuring callbacks (or not) and SNI vs not... no shared cipher from server end In-Reply-To: <32734.1557339343@localhost> References: <32734.1557339343@localhost> Message-ID: <2470.1557347018@localhost> My questions about the documentation of the callbacks remain. Having solved the problem, I'm pretty certain the the "no shared cipher" error message is way too overloaded. Some piece of code is clearly doing something useful, which is to check if the public/private key match. Unfortunately, that code is not announcing the mismatch in a useful way. My provisioning script, due to a typo, was generating new CSRs, but sending an ancient CSR with an old public key. Writing up the problem, I eventually noticed the public key dump from the private key file did not match the dump from the certificate. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed May 8 20:35:19 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 May 2019 16:35:19 -0400 Subject: configuring callbacks (or not) and SNI vs not... no shared cipher from server end In-Reply-To: <2470.1557347018@localhost> References: <32734.1557339343@localhost> <2470.1557347018@localhost> Message-ID: <453B75C7-92DA-430B-8541-7B56EE8A6DB8@dukhovni.org> > On May 8, 2019, at 4:23 PM, Michael Richardson wrote: > > My questions about the documentation of the callbacks remain. > Having solved the problem, I'm pretty certain the the "no shared cipher" > error message is way too overloaded. It sounds like you failed to load a matching key pair into the server's SSL context (something that you would typically check as part of setting the certificate chain and private key). Once the server context has no signing keys, it can only negotiate anon-DHE and anon-ECDHE ciphers, but the client did not offer these, so you got "no shared cipher", which is fact correct. > Some piece of code is clearly doing something useful, which is to check if > the public/private key match. Unfortunately, that code is not announcing > the mismatch in a useful way. The check is done at configuration time. You're likely not doing the key setup "by the book": https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_certkey.c#L600-L623 -- Viktor. -- Viktor. From mcr at sandelman.ca Wed May 8 20:40:07 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 08 May 2019 16:40:07 -0400 Subject: configuring callbacks (or not) and SNI vs not... no shared cipher from server end In-Reply-To: <20190508193110.GO67454@straasha.imrryr.org> References: <32734.1557339343@localhost> <20190508193110.GO67454@straasha.imrryr.org> Message-ID: <7698.1557348007@localhost> Viktor Dukhovni wrote: >> Diversionary issue: >> https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html >> and: >> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html >> >> are pretty vague. I think that SSL_set_tlsext_host_name() is probably >> intended to be used on the client to set the SNI, but I'm not sure. > Yes, e.g. in the Postfix TLS client: > https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045 So, okay. Either this URL can go into the man page, or some short code extract could go in. >> The legacy cb function returns int, but it's values are not >> documented. > On the server side I'm using SSL_CTX_set_tlsext_servername_callback(): > https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043 > https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668 >> I guess the point is that CB can set the server certificate to >> something appropriate, or I think, it could just decide to ignore the >> SNI value completely and force the certificate regardless. > Yes. I can see that the CB provides comprehensive functionality, but I worry about applications trying to parse ClientHello extensions themselves and getting it wrong. >> What is the SNI functionality otherwise on the server? > You can interpose a secondary "virtual-host-specific" SSL_CTX for for > the rest of the handshake. This carries the server certificate, but > also the trust store settings for validating client certificates, the > settings to request (or not) client certificates, the verification > callbacks, ... It is a rather heavyweight object, best cached and > re-used for multiple connections. So, it's okay to change the SSL_CTX for an SSL* after creation. That is rather surprising to me, but I guess it's okay. I suppose I feel that there ought to be reference counts, but this is C, not Rust. > In Postfix, it is configured with the same settings as the initial > SSL_CTX, *but* no server certificates. During the SNI callback I > interpose the certificate-less context, and then set the certificate > chain on the connection handle (SSL *) instead. okay, I'll use Postfix as my reference :-) >> Is there any support for picking a certificate based upon the SNI >> name? > The application does the "picking"... The application sets one or more > certificate chains (one per supported public key algorithm) that best > match the SNI name, and then OpenSSL chooses one of these based on the > client's advertised supported signature algorithms, ... What I was observing (wrongly) was that maybe the server was doing something itself if there was no callback, and it was failing. This was from looking at the code around the error code that came out. This (see other email) proved to wildly incorrect. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed May 8 21:53:36 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 May 2019 17:53:36 -0400 Subject: configuring callbacks (or not) and SNI vs not... no shared cipher from server end In-Reply-To: <7698.1557348007@localhost> References: <32734.1557339343@localhost> <20190508193110.GO67454@straasha.imrryr.org> <7698.1557348007@localhost> Message-ID: <20190508215336.GP67454@straasha.imrryr.org> On Wed, May 08, 2019 at 04:40:07PM -0400, Michael Richardson wrote: > > You can interpose a secondary "virtual-host-specific" SSL_CTX for for > > the rest of the handshake. This carries the server certificate, but > > also the trust store settings for validating client certificates, the > > settings to request (or not) client certificates, the verification > > callbacks, ... It is a rather heavyweight object, best cached and > > re-used for multiple connections. > > So, it's okay to change the SSL_CTX for an SSL* after creation. > That is rather surprising to me, but I guess it's okay. > I suppose I feel that there ought to be reference counts, but this is C, not Rust. It is not that sort of change "change", there's a call to insert a an additional CTX that interposes between the SSL handle and its parent context for most of the relevant data and function pointers. The SSL handle is still ultimately tied to the same parent context. > > In Postfix, it is configured with the same settings as the initial > > SSL_CTX, *but* no server certificates. During the SNI callback I > > interpose the certificate-less context, and then set the certificate > > chain on the connection handle (SSL *) instead. > > okay, I'll use Postfix as my reference :-) Fine by me. :-) -- Viktor. From rollastre at gmail.com Wed May 8 22:10:48 2019 From: rollastre at gmail.com (rollastre at gmail.com) Date: Thu, 9 May 2019 00:10:48 +0200 Subject: Problems building for IOS and linking to libssh2 Message-ID: <447fd934-fe54-df22-c690-3acbcfa402e6@gmail.com> Hello. I have built libssh2 with openssl in windows (MVC 2017), linux (GCC >6), mac (clang 8 - 10), android (NDK19 / API 21-24 / clang) successfully. Now I am stuck trying to build it for iOS. The error I get is about an undefined symbol as folows ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) undefined symbols for architecture armv7: ??? "_ENGINE_load_builtin_engines", referenced from: ??????? _libssh2_init in global.c.o ??????? __libssh2_init_if_needed in global.c.o ??? "_ENGINE_register_all_complete", referenced from: ??????? _libssh2_init in global.c.o ??????? __libssh2_init_if_needed in global.c.o ld: symbol(s) not found for architecture armv7 clang: error: linker command failed with exit code 1 (use -v to see invocation) From what I understand, the problem is that the static lib is not including a symbol? I am using XCode 10.2.1 and the command I used to build OpenSSL is ./Configure iphoneos-cross -lsysroot/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.2.sdk -mios-version-min=10.0 -fembed-bitcode -O3 --sysroot=/Application/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.2.sdk -fPIC --with-zlib-include=/Users/roll/sdks/zlib/include --with-zlib-lib=/Users/roll/sdks/zlib/lib the build process ends without error and a libcrypto.a and libssl.a files are created. Can anybody point me what am I doing wrong or misunderstanding? Thanks in advance. From bkaduk at akamai.com Wed May 8 22:23:38 2019 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 8 May 2019 17:23:38 -0500 Subject: configuring callbacks (or not) and SNI vs not... no shared cipher from server end In-Reply-To: <7698.1557348007@localhost> References: <32734.1557339343@localhost> <20190508193110.GO67454@straasha.imrryr.org> <7698.1557348007@localhost> Message-ID: <20190508222338.GN4464@akamai.com> On Wed, May 08, 2019 at 04:40:07PM -0400, Michael Richardson wrote: > > Viktor Dukhovni wrote: > >> Diversionary issue: > >> https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html > >> and: > >> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html > >> > >> are pretty vague. I think that SSL_set_tlsext_host_name() is probably > >> intended to be used on the client to set the SNI, but I'm not sure. > > > Yes, e.g. in the Postfix TLS client: > > > https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045 > > So, okay. > Either this URL can go into the man page, or some short code extract could go in. Probably better to have a code snippet (filing a github issue or sending a pull request would probably be good). > >> The legacy cb function returns int, but it's values are not > >> documented. > > > On the server side I'm using SSL_CTX_set_tlsext_servername_callback(): > > > https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043 > > https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668 > > >> I guess the point is that CB can set the server certificate to > >> something appropriate, or I think, it could just decide to ignore the > >> SNI value completely and force the certificate regardless. > > > Yes. > > I can see that the CB provides comprehensive functionality, but I worry about > applications trying to parse ClientHello extensions themselves and getting it wrong. It turns out that the server_name TLS extension is something of an unfortunate exception in terms of the unneeded complexity in its encoding. When I wrote the client_hello_cb functionality (at the time, know as the early_cb), I thought about whether I wanted to add a dedicated API just for the SNI value, due to the level of complexity involved. I ended up not doing so in the initial submission, both because I figured it could safely be added later as an incremental change, and because I was worried (IIRC) about being tempted to expose some of the PACKET_* APIs in the process, which is not really the right architectural choice for OpenSSL. There is, however, an existing implementation for extracting the SNI value in the test code at https://github.com/openssl/openssl/blob/master/test/handshake_helper.c#L150-L187 that has been successfully extracted and used in a couple places I know of. > >> What is the SNI functionality otherwise on the server? > > > You can interpose a secondary "virtual-host-specific" SSL_CTX for for > > the rest of the handshake. This carries the server certificate, but > > also the trust store settings for validating client certificates, the > > settings to request (or not) client certificates, the verification > > callbacks, ... It is a rather heavyweight object, best cached and > > re-used for multiple connections. > > So, it's okay to change the SSL_CTX for an SSL* after creation. > That is rather surprising to me, but I guess it's okay. > I suppose I feel that there ought to be reference counts, but this is C, not Rust. There *are* reference counts. > > In Postfix, it is configured with the same settings as the initial > > SSL_CTX, *but* no server certificates. During the SNI callback I > > interpose the certificate-less context, and then set the certificate > > chain on the connection handle (SSL *) instead. > > okay, I'll use Postfix as my reference :-) For "how to use and switch SSL_CTXs" I'm sure it's admirable, but my understanding is that it's still using the legacy server_name callback (as opposed to the new client_hello_cb), and the new callback has a lot of advantages for architectural cleanliness and avoiding some surprising behavior with respect to the ordering of certain processing in the server. So for a greenfield application I'd still suggest using the client_hello_cb (not that I'm entirely unbiased...). -Ben > >> Is there any support for picking a certificate based upon the SNI > >> name? > > > The application does the "picking"... The application sets one or more > > certificate chains (one per supported public key algorithm) that best > > match the SNI name, and then OpenSSL chooses one of these based on the > > client's advertised supported signature algorithms, ... > > What I was observing (wrongly) was that maybe the server was doing something > itself if there was no callback, and it was failing. This was from looking > at the code around the error code that came out. > This (see other email) proved to wildly incorrect. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > From 213tej at gmail.com Thu May 9 01:43:44 2019 From: 213tej at gmail.com (Teja Prabhu) Date: Thu, 9 May 2019 03:43:44 +0200 Subject: Problems building for IOS and linking to libssh2 In-Reply-To: <447fd934-fe54-df22-c690-3acbcfa402e6@gmail.com> References: <447fd934-fe54-df22-c690-3acbcfa402e6@gmail.com> Message-ID: https://stackoverflow.com/questions/6429494/undefined-symbols-for-architecture-armv7 Look at common cause 3 in the first answer. These are the undefined symbols: "_ENGINE_load_builtin_engines", referenced from: _libssh2_init in global.c.o __libssh2_init_if_needed in global.c.o "_ENGINE_register_all_complete", referenced from: _libssh2_init in global.c.o __libssh2_init_if_needed in global.c.o presumably you didn't recompile them for iOS. Teja Prabhu On Thu, May 9, 2019 at 12:11 AM rollastre at gmail.com wrote: > Hello. > > I have built libssh2 with openssl in windows (MVC 2017), linux (GCC >6), > mac (clang 8 - 10), android (NDK19 / API 21-24 / clang) successfully. > Now I am stuck trying to build it for iOS. The error I get is about an > undefined symbol as folows > > ld: warning: -headerpad_max_install_names is ignored when used with > -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) > undefined symbols for architecture armv7: > "_ENGINE_load_builtin_engines", referenced from: > _libssh2_init in global.c.o > __libssh2_init_if_needed in global.c.o > "_ENGINE_register_all_complete", referenced from: > _libssh2_init in global.c.o > __libssh2_init_if_needed in global.c.o > ld: symbol(s) not found for architecture armv7 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > From what I understand, the problem is that the static lib is not > including a symbol? > > I am using XCode 10.2.1 and the command I used to build OpenSSL is > > ./Configure iphoneos-cross > -lsysroot/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.2.sdk > > -mios-version-min=10.0 -fembed-bitcode -O3 > --sysroot=/Application/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.2.sdk > > -fPIC --with-zlib-include=/Users/roll/sdks/zlib/include > --with-zlib-lib=/Users/roll/sdks/zlib/lib > > the build process ends without error and a libcrypto.a and libssl.a > files are created. > > Can anybody point me what am I doing wrong or misunderstanding? > > Thanks in advance. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu May 9 03:06:38 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 May 2019 23:06:38 -0400 Subject: configuring callbacks (or not) and SNI vs not... no shared cipher from server end In-Reply-To: <20190508222338.GN4464@akamai.com> References: <32734.1557339343@localhost> <20190508193110.GO67454@straasha.imrryr.org> <7698.1557348007@localhost> <20190508222338.GN4464@akamai.com> Message-ID: <20190509030638.GQ67454@straasha.imrryr.org> On Wed, May 08, 2019 at 05:23:38PM -0500, Benjamin Kaduk via openssl-users wrote: > > > In Postfix, it is configured with the same settings as the initial > > > SSL_CTX, *but* no server certificates. During the SNI callback I > > > interpose the certificate-less context, and then set the certificate > > > chain on the connection handle (SSL *) instead. > > > > okay, I'll use Postfix as my reference :-) > > For "how to use and switch SSL_CTXs" I'm sure it's admirable, but my > understanding is that it's still using the legacy server_name callback > (as opposed to the new client_hello_cb), and the new callback has a lot > of advantages for architectural cleanliness and avoiding some surprising > behavior with respect to the ordering of certain processing in the > server. So for a greenfield application I'd still suggest using the > client_hello_cb (not that I'm entirely unbiased...). The reason for the choice in Postfix is that we still support OpenSSL 1.0.2, which does not have the new interface. So for now I'm using the older interface which works with both 1.0.2 and 1.1.1. Since in Postfix we not also doing anything exciting like ALPN, or other exciting extensions, I don't expect any trouble from the original callback, but perhaps I've not looked closely enough at the potential drawbacks. If there's good reason to expect trouble, I'd like to hear what specifically might go wrong. -- Viktor. From matt at openssl.org Thu May 9 08:37:49 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 9 May 2019 09:37:49 +0100 Subject: OpenSSL 1.1.1b tests fail on Solaris In-Reply-To: References: Message-ID: <84885d5b-383b-798e-e625-4cf29fb0c00f@openssl.org> What is the output from: $ make V=1 TESTS=test_sanity test Matt On 08/05/2019 19:22, John Unsworth wrote: > I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 Generic_Virtual sun4v > sparc SUNW,T5140. > > ? > > ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 -xldscope=hidden > > ? > > It builds fine but all the tests fail, with or without no-asm. Can anyone help > please? Here is the start of the test run: > > ? > > $ make test > > make depend && make _tests > > ( cd test; \ > > ? mkdir -p test-runs; \ > > ? SRCTOP=../. \ > > ? BLDTOP=../. \ > > ? RESULT_D=test-runs \ > > ?PERL="/opt/perl-5.26.1/bin/perl" \ > > ? EXE_EXT= \ > > ? OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ > > ? OPENSSL_DEBUG_MEMORY=on \ > > ??? /opt/perl-5.26.1/bin/perl .././test/run_tests.pl? ) > > ../test/recipes/01-test_abort.t .................... ok > > ../test/recipes/01-test_sanity.t ................... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/01-test_symbol_presence.t .......... skipped: Only useful when > building shared libraries > > ../test/recipes/01-test_test.t ..................... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_errstr.t ................... Dubious, test returned 60 > (wstat 15360, 0x3c00) > > Failed 60/76 subtests > > ??????? (less 16 skipped subtests: 0 okay) > > ../test/recipes/02-test_internal_ctype.t ........... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_lhash.t .................... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_ordinals.t ................. ok > > ../test/recipes/02-test_stack.t .................... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_exdata.t ................... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_asn1.t ............ Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_chacha.t .......... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_curve448.t ........ Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_ec.t .............. Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_mdc2.t ............ Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_modes.t ........... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_poly1305.t ........ Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_siphash.t ......... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_sm2.t ............. Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_sm4.t ............. Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_ssl_cert_table.t .. Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_x509.t ............ Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_ui.t ....................... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_decode.t .............. Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_encode.t .............. Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_string_table.t ........ Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_bio_callback.t ............. Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/1 subtests > > *?* > > Regards, > > John. > From John.Unsworth at synchronoss.com Thu May 9 09:12:35 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 9 May 2019 09:12:35 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris In-Reply-To: <84885d5b-383b-798e-e625-4cf29fb0c00f@openssl.org> References: <84885d5b-383b-798e-e625-4cf29fb0c00f@openssl.org> Message-ID: This looks like the problem: ld.so.1: sanitytest: fatal: relocation error: file ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not ok 1 - running sanitytest # Failed test 'running sanitytest' # at /home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests This results in the same error: sol-mds-build-01 $ cd apps sol-mds-build-01 $ ./openssl version ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found I have built static libraries. John -----Original Message----- From: openssl-users On Behalf Of Matt Caswell Sent: 09 May 2019 09:38 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris CAUTION: This email originated from outside of Synchronoss. What is the output from: $ make V=1 TESTS=test_sanity test Matt On 08/05/2019 19:22, John Unsworth wrote: > I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 > Generic_Virtual sun4v sparc SUNW,T5140. > > > > ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 > -xldscope=hidden > > > > It builds fine but all the tests fail, with or without no-asm. Can > anyone help please? Here is the start of the test run: > > > > $ make test > > make depend && make _tests > > ( cd test; \ > > mkdir -p test-runs; \ > > SRCTOP=../. \ > > BLDTOP=../. \ > > RESULT_D=test-runs \ > > PERL="/opt/perl-5.26.1/bin/perl" \ > > EXE_EXT= \ > > OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ > > OPENSSL_DEBUG_MEMORY=on \ > > /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) > > ../test/recipes/01-test_abort.t .................... ok > > ../test/recipes/01-test_sanity.t ................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/01-test_symbol_presence.t .......... skipped: Only > useful when building shared libraries > > ../test/recipes/01-test_test.t ..................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_errstr.t ................... Dubious, test > returned 60 (wstat 15360, 0x3c00) > > Failed 60/76 subtests > > (less 16 skipped subtests: 0 okay) > > ../test/recipes/02-test_internal_ctype.t ........... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_lhash.t .................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_ordinals.t ................. ok > > ../test/recipes/02-test_stack.t .................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_exdata.t ................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_asn1.t ............ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_chacha.t .......... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_curve448.t ........ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_ec.t .............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_mdc2.t ............ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_modes.t ........... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_poly1305.t ........ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_siphash.t ......... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_sm2.t ............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_sm4.t ............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_ssl_cert_table.t .. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_x509.t ............ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_ui.t ....................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_decode.t .............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_encode.t .............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_string_table.t ........ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_bio_callback.t ............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > * * > > Regards, > > John. > From John.Unsworth at synchronoss.com Thu May 9 09:47:41 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 9 May 2019 09:47:41 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris In-Reply-To: References: <84885d5b-383b-798e-e625-4cf29fb0c00f@openssl.org> Message-ID: This is the build line for sanity test: rm -f test/sanitytest ${LDCMD:-cc} -xarch=v9 -xstrconst -Xa -xO5 -xdepend -m64 -xcode=pic32 -xldscope=hidden -L. -mt \ -o test/sanitytest test/sanitytest.o \ test/libtestutil.a -lcrypto -lsocket -lnsl -ldl -lpthread -lrt cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs Does it need -lssl? John -----Original Message----- From: openssl-users On Behalf Of John Unsworth Sent: 09 May 2019 10:13 To: openssl-users at openssl.org Subject: RE: OpenSSL 1.1.1b tests fail on Solaris CAUTION: This email originated from outside of Synchronoss. This looks like the problem: ld.so.1: sanitytest: fatal: relocation error: file ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not ok 1 - running sanitytest # Failed test 'running sanitytest' # at /home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests This results in the same error: sol-mds-build-01 $ cd apps sol-mds-build-01 $ ./openssl version ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found I have built static libraries. John -----Original Message----- From: openssl-users On Behalf Of Matt Caswell Sent: 09 May 2019 09:38 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris CAUTION: This email originated from outside of Synchronoss. What is the output from: $ make V=1 TESTS=test_sanity test Matt On 08/05/2019 19:22, John Unsworth wrote: > I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 > Generic_Virtual sun4v sparc SUNW,T5140. > > > > ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 > -xldscope=hidden > > > > It builds fine but all the tests fail, with or without no-asm. Can > anyone help please? Here is the start of the test run: > > > > $ make test > > make depend && make _tests > > ( cd test; \ > > mkdir -p test-runs; \ > > SRCTOP=../. \ > > BLDTOP=../. \ > > RESULT_D=test-runs \ > > PERL="/opt/perl-5.26.1/bin/perl" \ > > EXE_EXT= \ > > OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ > > OPENSSL_DEBUG_MEMORY=on \ > > /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) > > ../test/recipes/01-test_abort.t .................... ok > > ../test/recipes/01-test_sanity.t ................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/01-test_symbol_presence.t .......... skipped: Only > useful when building shared libraries > > ../test/recipes/01-test_test.t ..................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_errstr.t ................... Dubious, test > returned 60 (wstat 15360, 0x3c00) > > Failed 60/76 subtests > > (less 16 skipped subtests: 0 okay) > > ../test/recipes/02-test_internal_ctype.t ........... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_lhash.t .................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_ordinals.t ................. ok > > ../test/recipes/02-test_stack.t .................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_exdata.t ................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_asn1.t ............ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_chacha.t .......... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_curve448.t ........ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_ec.t .............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_mdc2.t ............ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_modes.t ........... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_poly1305.t ........ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_siphash.t ......... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_sm2.t ............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_sm4.t ............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_ssl_cert_table.t .. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_x509.t ............ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_ui.t ....................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_decode.t .............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_encode.t .............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_string_table.t ........ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_bio_callback.t ............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > * * > > Regards, > > John. > From clkshd at gmail.com Thu May 9 11:43:36 2019 From: clkshd at gmail.com (Andrei Susnea) Date: Thu, 9 May 2019 14:43:36 +0300 Subject: X509v3 SAN names length question Message-ID: Hi, Using openssl 1.0.2h I'm getting SSL_ERROR_SYSCALL while trying to authenticate a certificate with the following SAN names configuration: X509v3 Subject Alternative Name: DNS:xxxx.xxxxxx.xxx.xxx.xxxxxxxxxxx.com, DNS:xxxx.xxxxxx.xxxx.xxx.xxxxxxxxxxx.com, DNS:xxxxxxxxxxx-xxxxx.xxx.xxxx.xxx.xxxxxxxxxxx.com, DNS:xxxxxxxxxxx-xxxxx.xxx.xxx.xxx.xxxxxxxxxxx.com, DNS:xxxxxxxxxxx-xxxx.xxx.xxxx.xxx.xxxxxxxxxxx.com, DNS:xxxxxxxxxxx-xxxx.xxx.xxx.xxx.xxxxxxxxxxx.com With the previous config, it worked: X509v3 Subject Alternative Name: DNS:xxxxxxxxxxx-xxxx.xxx.xxxxxx.xxx.xxxxxxxxxxx.com, DNS:xxxxxxxxxxx-xxxx.xxx.xxxxx.xxx.xxxxxxxxxxx.com, DNS:xxxxxxxxxxx-xxxxx.xxx.xxxxx.xxx.xxxxxxxxxxx.com, DNS:xxxxxxxxxxx-xxxxx.xxx.xxxxxx.xxx.xxxxxxxxxxx.com I tried upgrading to 1.0.2r with the same result. Does anyone know if it's a name length issue with this version? I read you can have as many as 150 names x 25 characters < 4k. Or if updating to 1.1.1b would fix this issue? Thanks, Andrei -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Thu May 9 12:00:42 2019 From: hkario at redhat.com (Hubert Kario) Date: Thu, 09 May 2019 14:00:42 +0200 Subject: X509v3 SAN names length question In-Reply-To: References: Message-ID: <4757795.07uVHsU8eq@pintsize.usersys.redhat.com> On Thursday, 9 May 2019 13:43:36 CEST Andrei Susnea wrote: > Hi, > > Using openssl 1.0.2h I'm getting SSL_ERROR_SYSCALL while trying to > authenticate a certificate with the following SAN names configuration: > > X509v3 Subject Alternative Name: > > DNS:xxxx.xxxxxx.xxx.xxx.xxxxxxxxxxx.com, > DNS:xxxx.xxxxxx.xxxx.xxx.xxxxxxxxxxx.com, > DNS:xxxxxxxxxxx-xxxxx.xxx.xxxx.xxx.xxxxxxxxxxx.com, > DNS:xxxxxxxxxxx-xxxxx.xxx.xxx.xxx.xxxxxxxxxxx.com, > DNS:xxxxxxxxxxx-xxxx.xxx.xxxx.xxx.xxxxxxxxxxx.com, > DNS:xxxxxxxxxxx-xxxx.xxx.xxx.xxx.xxxxxxxxxxx.com > > > With the previous config, it worked: > > X509v3 Subject Alternative Name: > DNS:xxxxxxxxxxx-xxxx.xxx.xxxxxx.xxx.xxxxxxxxxxx.com, > DNS:xxxxxxxxxxx-xxxx.xxx.xxxxx.xxx.xxxxxxxxxxx.com, > DNS:xxxxxxxxxxx-xxxxx.xxx.xxxxx.xxx.xxxxxxxxxxx.com, > DNS:xxxxxxxxxxx-xxxxx.xxx.xxxxxx.xxx.xxxxxxxxxxx.com > > > I tried upgrading to 1.0.2r with the same result. > > Does anyone know if it's a name length issue with this version? > I read you can have as many as 150 names x 25 characters < 4k. where did you get those limits? the certificate has expired, but https://1000-sans.badssl.com/ does verify otherwise with both 1.1.0i from Fedora and 1.0.2k from RHEL7: $ faketime 'last year' openssl s_client -connect 1000-sans.badssl.com:443 - servername 1000-sans.badssl.com -verify_hostname 1000-sans.badssl.com ... Verify return code: 0 (ok) https:// longextendedsubdomainnamewithoutdashesinordertotestwordwrapping.badssl.com works fine too -- 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 rama.krushna7 at gmail.com Thu May 9 13:59:11 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Thu, 9 May 2019 19:29:11 +0530 Subject: Reg slowness seen in openssl 1.1.1 Message-ID: Hi, When we use following set of SSL methods ( openssl 1.1.1) for SHA1-digest, we are witnessing slowness compared to openssl 1.1.0e. EVP_get_digestbyname EVP_MD_CTX_new EVP_DigestInit_ex EVP_DigestUpdate EVP_DigestFinal_ex Could anyone please guide me about how to debug this issue. Thanks and Regards, Ram Krushna -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinayashreeks18 at gmail.com Thu May 9 14:03:08 2019 From: vinayashreeks18 at gmail.com (vin) Date: Thu, 9 May 2019 07:03:08 -0700 (MST) Subject: Issue in linking Openssl1.1.1b to application Message-ID: <1557410588671-0.post@n7.nabble.com> Hi I was using an application with openssl0.9.8k .The procedure i used to link openssl to my application using visual studio -2008 was after building openssl i was linking libeay32.lib and ssleay32.lib to my application and including header files from include folder. Now with openssl1.1.1b ,after building openssl I am linking openssl.lib ,libcrypto.lib and libssl.lib to my application and including header files.Building application using visual studio 2008 .And when i try to register that built dll in windows 7 32 bit machine ,its giving error as "RegSvr32 : The module XXX.dll failed to load. Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. " Can anyone please tell me whether the library linking is enough or any dll linking needs to be done?? Any step i am missing please let me know? Thanks in advance -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From rsalz at akamai.com Thu May 9 14:56:53 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 May 2019 14:56:53 +0000 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: References: Message-ID: I would start with doing profiling on old and new versions to see where the slowdown is. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rama.krushna7 at gmail.com Thu May 9 15:05:51 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Thu, 9 May 2019 20:35:51 +0530 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: References: Message-ID: Hi, Thank you for the response. If we compare in quantify attached is the results. Thanks and Regards, Ram Krushna On Thu, May 9, 2019 at 8:28 PM Salz, Rich wrote: > I would start with doing profiling on old and new versions to see where > the slowdown is. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Differences between: program rx (pid 6113) collected on PentiumIII (2599 MHz) by Quantify version 7.4 150915 and program rx (pid 98772) collected on PentiumIII (2599 MHz) by Quantify version 7.4 150915. Function name Calls Cycles % change + ERR_STATE_free 0 0 + EVP_camellia_128_ctr 0 0 + EVP_cast5_ecb 0 0 + EVP_cast5_cfb64 0 0 + ossl_init_thread_stop 0 0 + lh_OBJ_NAME_get_down_load 0 0 + EVP_cast5_ofb 0 0 + doall_util_fn 0 0 + sk_EX_CALLBACK_pop_free 0 0 + utrcdInit 0 0 + RAND_DRBG_secure_new 0 0 + rand_pool_new 0 0 + lh_OBJ_NAME_set_down_load 0 0 + ossl_init_load_crypto_nodelete 0 0 + EVP_aria_256_ccm 0 0 + pam_allow_val 0 0 + lh_OBJ_NAME_error 0 0 + ossl_init_get_thread_local 0 0 + openssl_lh_strcasehash 0 0 + rand_pool_entropy_available 0 0 + aesni_ecb_encrypt 0 0 + EVP_sha512_256 0 0 + close_random_device 0 0 + do_rand_init 0 0 + RAND_DRBG_set 0 0 + otmGetDigestCtx 0 0 + ossl_store_destroy_loaders_int 0 0 + o_names_init 0 0 + __strcasecmp_l_sse42 0 0 + do_rand_drbg_init_ossl_ 0 0 + fstat 0 0 + module_free 0 0 + ctr_BCC_update 0 0 + EVP_camellia_128_ofb 0 0 + ctr_XOR 0 0 + lh_OBJ_NAME_free 0 0 + syscall_random 0 0 + EVP_sm4_ofb 0 0 + ossl_init_add_all_ciphers 0 0 + EVP_sm4_cfb128 0 0 + expand 0 0 + pthread_self 0 0 + CRYPTO_secure_allocated 0 0 + contract 0 0 + rand_pool_add_begin 0 0 + rand_pool_add_end 0 0 + EVP_CIPHER_CTX_new 0 0 + EVP_aria_192_ofb 0 0 + EVP_aria_128_cfb1 0 0 + rand_pool_init 0 0 + sk_nid_triple_free 0 0 + EVP_camellia_256_ctr 0 0 + EVP_aria_256_cfb1 0 0 + getgid 0 0 + EVP_aria_256_cfb8 0 0 + ossl_init_engine_rdrand 0 0 + check_random_device 0 0 + do_err_strings_init 0 0 + do_engine_lock_init 0 0 + EVP_camellia_128_cbc 0 0 + do_rand_init_ossl_ 0 0 + int_cleanup_item 0 0 + OPENSSL_sk_new_reserve 0 0 + get_time_stamp 0 0 + EVP_CIPHER_CTX_key_length 0 0 + sk_ENGINE_CLEANUP_ITEM_new_null 0 0 + EVP_camellia_192_cfb8 0 0 + aesni_ecb_cipher 0 0 + lh_ERR_STRING_DATA_new 0 0 + getegid 0 0 + EVP_aria_192_gcm 0 0 + RAND_DRBG_free 0 0 + init256 0 0 + EVP_CipherUpdate 0 0 + EVP_camellia_256_cbc 0 0 + EVP_aria_128_ctr 0 0 + ctr_update 0 0 + EVP_aria_192_cfb128 0 0 + EVP_shake256 0 0 + do_ex_data_init 0 0 + engine_list_add 0 0 + EVP_camellia_256_ecb 0 0 + sk_CONF_MODULE_push 0 0 + pam_digest_update 0 0 + sk_CONF_IMODULE_num 0 0 + conf_add_ssl_module 0 0 + sk_nid_triple_pop_free 0 0 + fmclear_tmp_longchar_or_memptr 0 0 + EVP_camellia_192_cfb128 0 0 + rand_drbg_get_nonce 0 0 + ossl_init_add_all_digests 0 0 + SHA256_Init 0 0 + sk_CONF_MODULE_delete 0 0 + EVP_aria_256_ecb 0 0 + EVP_aria_256_cbc 0 0 + lh_OBJ_NAME_delete 0 0 + ENGINE_register_pkey_asn1_meths 0 0 + EVP_sm4_cbc 0 0 + otm_digestCount 0 0 + ossl_init_engine_dynamic 0 0 + sk_EX_CALLBACK_num 0 0 + unknown_static_function[aesni-x86_64.o/36] 0 0 + sk_reserve 0 0 + rand_pool_add 0 0 + inc_128 0 0 + EVP_aria_192_ecb 0 0 + EVP_sm4_ecb 0 0 + unknown_static_function[aesni-x86_64.o/35] 0 0 + EVP_camellia_128_cfb1 0 0 + do_rand_drbg_init 0 0 + pam_digest_final 0 0 + sk_CONF_MODULE_value 0 0 + EVP_aria_192_cfb8 0 0 + EVP_CIPHER_CTX_free 0 0 + EVP_CIPHER_CTX_get_cipher_data 0 0 + ctr_BCC_blocks 0 0 + unknown_static_function[aesni-x86_64.o/34] 0 0 + EVP_cast5_cbc 0 0 + ossl_store_cleanup_int 0 0 + EVP_CIPHER_flags 0 0 + build_SYS_str_reasons 0 0 + EVP_camellia_192_ecb 0 0 + BIO_snprintf 0 0 + ctr_df 0 0 + open_random_devices 0 0 + update256 0 0 + EVP_CIPHER_CTX_test_flags 0 0 + EVP_CIPHER_CTX_encrypting 0 0 + ossl_init_load_crypto_nodelete_ossl_ 0 0 + sk_EVP_PBE_CTL_pop_free 0 0 + EVP_CipherInit_ex 0 0 + rand_drbg_lock 0 0 + drbg_setup 0 0 + EVP_camellia_128_cfb128 0 0 + getrn 0 0 + ctr_BCC_init 0 0 + lh_OBJ_NAME_retrieve 0 0 + CRYPTO_secure_malloc_done 0 0 + sk_CONF_MODULE_new_null 0 0 + err_do_init 0 0 + ossl_tolower 0 0 + internal_delete 0 0 + sk_void_free 0 0 + rand_pool_entropy 0 0 + rand_pool_bytes_needed 0 0 + EVP_camellia_128_ecb 0 0 + CRYPTO_THREAD_get_current_id 0 0 + sk_ENGINE_CLEANUP_ITEM_pop_free 0 0 + pam_digest_ctx_create 0 0 + rand_drbg_cleanup_entropy 0 0 + EVP_aria_128_cfb128 0 0 + RAND_DRBG_instantiate 0 0 + EVP_CIPHER_CTX_reset 0 0 + BIO_vsnprintf 0 0 + rand_pool_cleanup 0 0 + engine_list_remove 0 0 + sk_CONF_MODULE_num 0 0 + ERR_load_strings_const 0 0 + ossl_init_base 0 0 + EVP_sm3 0 0 + EVP_sha3_384 0 0 + EVP_aria_192_ctr 0 0 + otm_digestString 0 0 + final256 0 0 + EVP_aria_128_ofb 0 0 + OPENSSL_strnlen 0 0 + OPENSSL_issetugid 0 0 + rand_drbg_enable_locking 0 0 + EVP_shake128 0 0 + EVP_sm4_ctr 0 0 + o_names_init_ossl_ 0 0 + EVP_sha3_224 0 0 + rand_pool_entropy_needed 0 0 + _dopr 0 0 + lh_OSSL_STORE_LOADER_free 0 0 + lh_OBJ_NAME_new 0 0 + CRYPTO_secure_zalloc 0 0 + EVP_camellia_256_cfb1 0 0 + get_and_lock 0 0 + pam_digest_init 0 0 + int_cleanup_check 0 0 + EVP_camellia_256_ofb 0 0 + EVP_camellia_192_ctr 0 0 + err_load_strings 0 0 + rand_pool_buffer 0 0 + fmtstr 0 0 + EVP_aria_192_ccm 0 0 + EVP_camellia_256_cfb128 0 0 + sk_CONF_IMODULE_free 0 0 + EVP_camellia_256_cfb8 0 0 + rand_pool_add_nonce_data 0 0 + rand_pool_acquire_entropy 0 0 + EVP_aria_128_cbc 0 0 + drbg_ctr_uninstantiate 0 0 + EVP_aria_192_cfb1 0 0 + EVP_camellia_128_cfb8 0 0 + EVP_aria_128_ecb 0 0 + ENGINE_get_cipher_engine 0 0 + engine_dynamic 0 0 + pam_digest_ctx_delete 0 0 + err_patch 0 0 + EVP_CIPHER_CTX_block_size 0 0 + evp_app_cleanup_int 0 0 + drbg_ctr_instantiate 0 0 + ossl_init_load_crypto_strings 0 0 + aesni_init_key 0 0 + ossl_ctype_check 0 0 + utFreeCommandLine 0 0 + drbg_ctr_init 0 0 + EVP_aria_256_ctr 0 0 + EVP_aria_128_cfb8 0 0 + compute_growth 0 0 + sk_CONF_MODULE_free 0 0 + rand_pool_free 0 0 + rand_drbg_cleanup_int 0 0 + EVP_sha3_256 0 0 + rand_drbg_restart 0 0 + __strcasecmp_sse42 0 0 + EVP_camellia_192_cfb1 0 0 + EVP_aria_256_cfb128 0 0 + drbg_add 0 0 + ctr_BCC_final 0 0 + CRYPTO_secure_clear_free 0 0 + rand_pool_detach 0 0 + EVP_CIPHER_CTX_cipher 0 0 + EVP_sha3_512 0 0 + is_partially_overlapping 0 0 + EVP_aria_128_ccm 0 0 + lh_OBJ_NAME_doall 0 0 + sh_done 0 0 + EVP_aria_256_ofb 0 0 + rand_drbg_unlock 0 0 + EVP_EncryptUpdate 0 0 + rand_drbg_get_entropy 0 0 + SHA256_Final 0 0 + EVP_sha512_224 0 0 + drbg_ctr_reseed 0 0 + EVP_camellia_192_ofb 0 0 + EVP_aria_128_gcm 0 0 + EVP_camellia_192_cbc 0 0 + get_random_device 0 0 + rand_pool_length 0 0 + lh_OBJ_NAME_insert 0 0 + lh_ERR_STRING_DATA_free 0 0 + ERR_load_OSSL_STORE_strings 0 0 + sk_ENGINE_CLEANUP_ITEM_push 0 0 + def_destroy_data 0 0 + doapr_outch 0 0 + drbg_seed 0 0 + lh_ERR_STRING_DATA_retrieve 0 0 + sk_NAME_FUNCS_pop_free 0 0 + rand_drbg_new 0 0 + lh_ERR_STRING_DATA_insert 0 0 + RAND_DRBG_get0_master 0 0 + aesni_set_encrypt_key 0 0 + ctr_BCC_block 0 0 + RAND_DRBG_reseed 0 0 + EVP_aria_256_gcm 0 0 + SHA256_Update 0 0 + EVP_aria_192_cbc 0 0 + rand_drbg_cleanup_nonce 0 0 + cryptDigestCtxSize 900 1800 + cryptOEAlgSpecSize 900 1800 + cryptServiceCallbackSize 900 1800 + crypt_stub_mem_free 900 3600 + init[m_sha1.o/0] 400 4400 + cryptDigestInit 900 4500 + init[m_md5.o/0] 500 5500 + final[m_sha1.o/2] 400 6000 + pthread_mutex_destroy 900 7200 + final[m_md5.o/2] 500 7500 + update[m_sha1.o/1] 600 9600 + cryptServiceDestroy 900 9900 + update[m_md5.o/1] 700 11200 + cryptDigestCtxCleanup 900 11700 + cryptDynLockDelete 900 12600 + cryptDestructor 900 14400 + cryptOEAlgSpecProperty 1800 23400 + cryptServiceNewEx 900 25200 + cryptDigestCtxInit 900 26100 + cryptDigestUpdate 1300 33800 + cryptDigestInitEx 900 39600 + cryptDigestFinal 900 45600 + cryptCtxErrorClear 4900 58800 + pam_mac_digest 900 109800 + cryptDigestGetByName 900 182300 ! sha1_block_data_order_ssse3 -413 -246535 34.16% faster ! OPENSSL_LH_retrieve -1201 -74489 100.00% faster ! fmSecGenerateDigest -300 -70204 81.25% faster ! md5_block_asm_data_order -200 -58600 16.67% faster ! OPENSSL_cleanse -1216 -47097 25.47% faster ! memmove -1200 -46200 100.00% faster ! OBJ_NAME_get -1200 -25200 100.00% faster ! _wordcopy_fwd_aligned -1200 -22800 100.00% faster ! obj_name_hash -1200 -21600 100.00% faster ! obj_name_cmp -1200 -15600 100.00% faster ! EVP_get_digestbyname -1200 -9600 100.00% faster ! ENGINE_finish -608 -8488 32.04% faster ! engine_table_select -307 -5505 30.41% faster ! EVP_MD_CTX_clear_flags -307 -2477 18.66% faster ! fmESHA1_DIGEST 0 -1200 20.00% faster ! pthread_rwlock_unlock -9 -174 100.00% faster ! pthread_rwlock_wrlock -8 -160 100.00% faster ! ENGINE_get_first -2 -52 100.00% faster ! CRYPTO_atomic_add -2 -46 100.00% faster ! CRYPTO_THREAD_unlock -9 -45 100.00% faster ! ENGINE_get_next -2 -44 100.00% faster ! CRYPTO_THREAD_write_lock -8 -40 100.00% faster ! engine_free_util -2 -28 100.00% faster ! ERR_func_error_string -1 -20 100.00% faster ! pthread_rwlock_rdlock -1 -20 100.00% faster ! int_err_get_item -1 -19 100.00% faster ! ENGINE_register_all_digests -1 -15 100.00% faster ! ENGINE_register_all_ciphers -1 -15 100.00% faster ! EVP_sha1 -7 -14 100.00% faster ! RAND_seed -1 -13 100.00% faster ! err_string_data_hash -1 -12 100.00% faster ! ENGINE_register_digests -1 -7 100.00% faster ! ENGINE_register_ciphers -1 -7 100.00% faster ! ERR_load_CRYPTO_strings -1 -6 100.00% faster ! RAND_get_rand_method -1 -6 100.00% faster ! CRYPTO_THREAD_read_lock -1 -5 100.00% faster ! __close_nocancel[libpthread.so.0/182] -1 -4 100.00% faster ! err_string_data_cmp -1 -4 100.00% faster ! __read_nocancel[libpthread.so.0/180] -1 -4 100.00% faster ! __open_nocancel[libpthread.so.0/206] -1 -4 100.00% faster ! read[libpthread.so.0/179] -1 -2 100.00% faster ! ENGINE_free -2 -2 100.00% faster ! close[libpthread.so.0/181] -1 -2 100.00% faster ! open64[libpthread.so.0/205] -1 -2 100.00% faster ! alloc_perturb 15 60 187.50% slower ! SHA1_Init -207 109 1.38% slower ! EVP_PKEY_CTX_free -301 894 12.41% slower ! MD5_Init -100 1200 15.38% slower ! cryptServiceCtxSize 900 1800 ------% slower ! memcpy 366 1937 6.46% slower ! SHA1_Update -328 1983 5.57% slower ! __GI_memset -9 3247 4.91% slower ! CRYPTO_clear_free -301 3284 17.09% slower ! EVP_MD_CTX_new -301 3898 162.28% slower ! EVP_MD_CTX_free -301 4494 62.36% slower ! crypt_stub_mem_malloc 900 4500 ------% slower ! CRYPTO_zalloc -602 5370 14.90% slower ! __ctype_toupper_loc 900 5400 ------% slower ! EVP_DigestFinal_ex -307 5483 14.20% slower ! ENGINE_get_digest_engine -307 6586 272.83% slower ! EVP_DigestInit_ex -307 7550 12.05% slower ! EVP_MD_CTX_md_data -1142 8974 70.52% slower ! __strlen_sse42 900 9000 ------% slower ! MD5_Update -200 9800 28.41% slower ! EVP_MD_CTX_reset -301 12561 26.82% slower ! EVP_MD_CTX_test_flags 599 14397 399.58% slower ! cryptConstructor 900 16200 ------% slower ! pthread_mutex_init 900 18900 ------% slower ! ut_free 2700 18900 ------% slower ! EVP_DigestUpdate -528 19744 540.04% slower ! cryptDynLockCreate 900 19800 ------% slower ! CRYPTO_free -602 20390 169.78% slower ! cfree 2998 23984 124.81% slower ! CRYPTO_malloc -602 28186 167.63% slower ! pthread_once 8594 34376 712.60% slower ! cryptInitService 900 38700 ------% slower ! ut_malloc 2700 40500 ------% slower ! CRYPTO_THREAD_get_local 4900 49000 ------% slower ! SHA1_Final -207 68506 268.71% slower ! pthread_getspecific 4900 68600 ------% slower ! MD5_Final -100 82500 392.86% slower ! ERR_get_state 4900 102900 ------% slower ! malloc 2998 119920 124.81% slower ! CRYPTO_THREAD_run_once 8594 131170 2175.29% slower ! _int_malloc 2998 134885 121.25% slower ! _int_free 2998 186192 143.55% slower ! OPENSSL_init_crypto 3698 193038 518.06% slower ! ERR_clear_error 4900 5434100 ------% slower - do_rand_lock_init_ossl_ 0 0 - OPENSSL_sk_new 0 0 - ERR_load_strings 0 0 - RAND_OpenSSL 0 0 - rand_cleanup 0 0 - rand_seed -1 -2 - fmSecLoadLibrary -1 -17 - fmsecCall_RAND_Seed -1 -18 - rand_add -1 -2188 - init[m_md5.o/3] -600 -2400 - init[m_sha1.o/15] -607 -2428 - final[m_md5.o/1] -600 -3600 - final[m_sha1.o/14] -607 -3642 - update[m_md5.o/2] -900 -9000 - update[m_sha1.o/13] -928 -9280 - OPENSSL_LH_strhash -1200 -54000 390 differences; 6878176 Cycles (0.003 secs at 2599 MHz) 262.37% slower overall (including system calls). From rsalz at akamai.com Thu May 9 15:13:14 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 May 2019 15:13:14 +0000 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: References: Message-ID: <221BCF4F-2C5E-461D-A549-EA58B180B03A@akamai.com> So now you know where to start looking, I guess. You might also change your test program so that it calls the functions multiple times, to ?smooth out? the overhead. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu May 9 15:33:40 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 May 2019 11:33:40 -0400 Subject: X509v3 SAN names length question In-Reply-To: References: Message-ID: <20190509153340.GS67454@straasha.imrryr.org> On Thu, May 09, 2019 at 02:43:36PM +0300, Andrei Susnea wrote: > Using openssl 1.0.2h I'm getting SSL_ERROR_SYSCALL while trying to > authenticate a certificate with the following SAN names configuration: The details of the certificate content are irrelevant. Something else changed. You should be looking at the correctness of your appliction code, and PCAP captures of the traffic to detect any network-layer issues. -- Viktor. From kgoldman at us.ibm.com Thu May 9 16:25:45 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 9 May 2019 12:25:45 -0400 Subject: Issue in linking Openssl1.1.1b to application In-Reply-To: <1557410588671-0.post@n7.nabble.com> References: <1557410588671-0.post@n7.nabble.com> Message-ID: <542b1cab-8f0a-3e4a-6de4-0cfc72a6b756@us.ibm.com> On 5/9/2019 10:03 AM, vin wrote: > Hi > > I was using an application with openssl0.9.8k .The procedure i used to link > openssl to my application using visual studio -2008 was after building > openssl i was linking libeay32.lib and ssleay32.lib to my application and > including header files from include folder. > > Now with openssl1.1.1b ,after building openssl I am linking openssl.lib > ,libcrypto.lib and libssl.lib to my application and including header > files.Building application using visual studio 2008 .And when i try to > register that built dll in windows 7 32 bit machine ,its giving error as > "RegSvr32 : The module XXX.dll failed to load. Make sure the binary is > stored at the specified path or debug it to check for problems with the > binary or dependent .DLL files. > " > > Can anyone please tell me whether the library linking is enough or any dll > linking needs to be done?? > Any step i am missing please let me know? I believe that you have to set the path to the dll in your PATH environment variable. There may be some default directories, but setting the path should work. From vinayashreeks18 at gmail.com Thu May 9 17:24:04 2019 From: vinayashreeks18 at gmail.com (vin) Date: Thu, 9 May 2019 10:24:04 -0700 (MST) Subject: Issue in linking Openssl1.1.1b to application In-Reply-To: <542b1cab-8f0a-3e4a-6de4-0cfc72a6b756@us.ibm.com> References: <1557410588671-0.post@n7.nabble.com> <542b1cab-8f0a-3e4a-6de4-0cfc72a6b756@us.ibm.com> Message-ID: <1557422644307-0.post@n7.nabble.com> Hi Ken Thanks for the reply.If I am not wrong ,You are asking me to set the path of the dll in set path environment variable in testing machine (windows 7 32 bit) right?? But the issue is if same dll built with openssl0.9.8k is registering properly in same test machine. After replacing openssl libraries by openssl1.1.1b I am facing this issue.So I guess building dll using visual studio 2008 is missing some steps . Can you please help me further?? -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From rama.krushna7 at gmail.com Thu May 9 18:12:33 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Thu, 9 May 2019 23:42:33 +0530 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: <221BCF4F-2C5E-461D-A549-EA58B180B03A@akamai.com> References: <221BCF4F-2C5E-461D-A549-EA58B180B03A@akamai.com> Message-ID: Hi , I can observe slowness with standalone c programs. Attached are the sample c programs. If I run them with openssl 1.1.1 and 1.1.0e version on Linux system (Linux 2.6.32-504.el6.x86_64 x86_64 ). then I can see the difference. If I increase the number of loop in the program, then the slowness increases. Could you please look into the program and let me know if anything I am doing wrong ? Or else What could be the issue ? Thanks and Regards, Ram Krushna On Thu, May 9, 2019 at 8:43 PM Salz, Rich wrote: > So now you know where to start looking, I guess. You might also change > your test program so that it calls the functions multiple times, to ?smooth > out? the overhead. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- #include #include #include int main(int argc, char *argv[]) { char mess1[] = "Now is the time for all good men to come to the aid of their country."; char mess2[1024] ; int inlen=70, outlen,i; EVP_CIPHER_CTX *ctx; unsigned char key[] = "0123456789abcdeF"; unsigned char iv[] = "1234567887654321"; if (argv[1] == NULL) { printf ("Usage: encdec \n"); exit (1); } int do_encrypt = atoi(argv[1]); for(i =0;i<10000000;i++) { ctx = EVP_CIPHER_CTX_new(); const EVP_CIPHER *cp = EVP_get_cipherbyname("AES-128-CBC"); EVP_CipherInit_ex(ctx, cp, NULL, key, iv,do_encrypt); //EVP_CipherInit_ex(ctx, NULL, NULL, key, iv, do_encrypt); if(!EVP_CipherUpdate(ctx, mess2, &outlen, mess1, inlen)) { /* Error */ EVP_CIPHER_CTX_free(ctx); return 0; } if(!EVP_CipherFinal_ex(ctx, mess2, &outlen)) { /* Error */ EVP_CIPHER_CTX_free(ctx); return 0; } EVP_CIPHER_CTX_free(ctx); } return 1; } -------------- next part -------------- #include #include #include int main(int argc, char *argv[]) { EVP_MD_CTX *mdctx; const EVP_MD *md; char mess1[] = "Now is the time for all good men to come to the aid of their country.\n"; char mess2[] = "Now is the time for all good men to come to the aid of their country.\n"; unsigned char md_value[EVP_MAX_MD_SIZE]; unsigned int md_len, i; int j=0; if (argv[1] == NULL) { printf ("Usage: mdtest digestname\n"); exit (1); } md = EVP_get_digestbyname (argv[1]); if (md == NULL) { printf ("Unknown message digest %s\n", argv[1]); exit (1); } for (j=0;j<10000000;j++) { mdctx = EVP_MD_CTX_new (); EVP_DigestInit_ex (mdctx, md, NULL); EVP_DigestUpdate (mdctx, mess1, strlen (mess1)); EVP_DigestUpdate (mdctx, mess2, strlen (mess2)); EVP_DigestFinal_ex (mdctx, md_value, &md_len); EVP_MD_CTX_free (mdctx); } printf ("Digest is: "); for (i = 0; i < md_len; i++) printf ("%02x", md_value[i]); printf ("\n"); exit (0); } From rsalz at akamai.com Thu May 9 18:16:32 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 May 2019 18:16:32 +0000 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: References: <221BCF4F-2C5E-461D-A549-EA58B180B03A@akamai.com> Message-ID: > Could you please look into the program and let me know if anything I am doing wrong ? > Or else What could be the issue ? Sorry, no not me. Maybe someone else on the list has ideas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at synchronoss.com Thu May 9 20:56:47 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 9 May 2019 20:56:47 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris In-Reply-To: References: <84885d5b-383b-798e-e625-4cf29fb0c00f@openssl.org> Message-ID: Resend without cryptolist.txt and openssl_nm.txt attachments because they made the email too big. Attached is ar -t libcrypto.a. sol-mds-build-01 $ ar -t libcrypto.a > cryptolist.txt It contains stack.o which I see has the code for OPENSSL_sk_new_null. Attached is sol-mds-build-01 $ nm openssl > openssl_nm.txt All the OPENSSL_sk functions are missing. They are marked UNDEF and WEAK. [11397] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_deep_copy [11466] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_delete [11287] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_delete_ptr [11485] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_dup [11389] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_find [11502] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_free [11476] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_insert [11408] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_is_sorted [11583] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new [11450] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null [11458] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_reserve [11377] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_num [11467] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_pop [11402] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_pop_free [11298] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_push [11294] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_reserve [11409] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_set [11562] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_set_cmp_func [11295] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_shift [11424] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_sort [11576] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_value Attached is sol-mds-build-01 $ nm stack.o > stacklist.txt All the functions are there but are marked WEAK. [28] | 784| 412|FUNC |WEAK |2 |2 |OPENSSL_sk_deep_copy [38] | 3256| 128|FUNC |WEAK |2 |2 |OPENSSL_sk_delete [39] | 3056| 164|FUNC |WEAK |2 |2 |OPENSSL_sk_delete_ptr [51] | 96| 652|FUNC |WEAK |2 |2 |OPENSSL_sk_dup [47] | 3416| 260|FUNC |WEAK |2 |2 |OPENSSL_sk_find [48] | 3712| 260|FUNC |WEAK |2 |2 |OPENSSL_sk_find_ex [36] | 4712| 72|FUNC |WEAK |2 |2 |OPENSSL_sk_free [45] | 2544| 480|FUNC |WEAK |2 |2 |OPENSSL_sk_insert [50] | 5184| 24|FUNC |WEAK |2 |2 |OPENSSL_sk_is_sorted [32] | 1288| 16|FUNC |WEAK |2 |2 |OPENSSL_sk_new [33] | 1232| 20|FUNC |WEAK |2 |2 |OPENSSL_sk_new_null [34] | 1872| 288|FUNC |WEAK |2 |2 |OPENSSL_sk_new_reserve [30] | 4816| 24|FUNC |WEAK |2 |2 |OPENSSL_sk_num [42] | 4240| 60|FUNC |WEAK |2 |2 |OPENSSL_sk_pop [44] | 4576| 100|FUNC |WEAK |2 |2 |OPENSSL_sk_pop_free [40] | 4008| 28|FUNC |WEAK |2 |2 |OPENSSL_sk_push [35] | 2192| 316|FUNC |WEAK |2 |2 |OPENSSL_sk_reserve [46] | 4960| 68|FUNC |WEAK |2 |2 |OPENSSL_sk_set [29] | 32| 32|FUNC |WEAK |2 |2 |OPENSSL_sk_set_cmp_func [43] | 4120| 88|FUNC |WEAK |2 |2 |OPENSSL_sk_shift [49] | 5064| 84|FUNC |WEAK |2 |2 |OPENSSL_sk_sort [41] | 4072| 16|FUNC |WEAK |2 |2 |OPENSSL_sk_unshift [31] | 4872| 56|FUNC |WEAK |2 |2 |OPENSSL_sk_value [37] | 4336| 208|FUNC |WEAK |2 |2 |OPENSSL_sk_zero Does the Bind Type WEAK indicate anything? >> Note - Weak symbols are intended primarily for use in system software. Their use in application programs is discouraged. Shouldn't they be GLOBAL like the rest? How to change them? Regards, John -----Original Message----- From: John Unsworth Sent: 09 May 2019 10:48 To: openssl-users at openssl.org Subject: RE: OpenSSL 1.1.1b tests fail on Solaris This is the build line for sanity test: rm -f test/sanitytest ${LDCMD:-cc} -xarch=v9 -xstrconst -Xa -xO5 -xdepend -m64 -xcode=pic32 -xldscope=hidden -L. -mt \ -o test/sanitytest test/sanitytest.o \ test/libtestutil.a -lcrypto -lsocket -lnsl -ldl -lpthread -lrt cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs Does it need -lssl? John -----Original Message----- From: openssl-users On Behalf Of John Unsworth Sent: 09 May 2019 10:13 To: openssl-users at openssl.org Subject: RE: OpenSSL 1.1.1b tests fail on Solaris CAUTION: This email originated from outside of Synchronoss. This looks like the problem: ld.so.1: sanitytest: fatal: relocation error: file ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not ok 1 - running sanitytest # Failed test 'running sanitytest' # at /home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests This results in the same error: sol-mds-build-01 $ cd apps sol-mds-build-01 $ ./openssl version ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found I have built static libraries. John -----Original Message----- From: openssl-users On Behalf Of Matt Caswell Sent: 09 May 2019 09:38 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris CAUTION: This email originated from outside of Synchronoss. What is the output from: $ make V=1 TESTS=test_sanity test Matt On 08/05/2019 19:22, John Unsworth wrote: > I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 > Generic_Virtual sun4v sparc SUNW,T5140. > > > > ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 > -xldscope=hidden > > > > It builds fine but all the tests fail, with or without no-asm. Can > anyone help please? Here is the start of the test run: > > > > $ make test > > make depend && make _tests > > ( cd test; \ > > mkdir -p test-runs; \ > > SRCTOP=../. \ > > BLDTOP=../. \ > > RESULT_D=test-runs \ > > PERL="/opt/perl-5.26.1/bin/perl" \ > > EXE_EXT= \ > > OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ > > OPENSSL_DEBUG_MEMORY=on \ > > /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) > > ../test/recipes/01-test_abort.t .................... ok > > ../test/recipes/01-test_sanity.t ................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/01-test_symbol_presence.t .......... skipped: Only > useful when building shared libraries > > ../test/recipes/01-test_test.t ..................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_errstr.t ................... Dubious, test > returned 60 (wstat 15360, 0x3c00) > > Failed 60/76 subtests > > (less 16 skipped subtests: 0 okay) > > ../test/recipes/02-test_internal_ctype.t ........... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_lhash.t .................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/02-test_ordinals.t ................. ok > > ../test/recipes/02-test_stack.t .................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_exdata.t ................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_asn1.t ............ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_chacha.t .......... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_curve448.t ........ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_ec.t .............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_mdc2.t ............ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_modes.t ........... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_poly1305.t ........ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_siphash.t ......... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_sm2.t ............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_sm4.t ............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_ssl_cert_table.t .. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_internal_x509.t ............ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/03-test_ui.t ....................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_decode.t .............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_encode.t .............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_asn1_string_table.t ........ Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > ../test/recipes/04-test_bio_callback.t ............. Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > * * > > Regards, > > John. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: stacklist.txt URL: From dclarke at blastwave.org Thu May 9 21:03:23 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 9 May 2019 17:03:23 -0400 Subject: OpenSSL 1.1.1b tests fail on Solaris In-Reply-To: References: <84885d5b-383b-798e-e625-4cf29fb0c00f@openssl.org> Message-ID: <759cfda6-532c-bd0d-5a11-ba2fa42e76bd@blastwave.org> On 5/9/19 4:56 PM, John Unsworth wrote: ... >> >> John. >> What are you doing that is so weird? jupiter # jupiter # uname -a SunOS jupiter 5.10 Generic_150400-65 sun4u sparc SUNW,SPARC-Enterprise jupiter # psrinfo -pv The physical processor has 8 virtual processors (0-7) SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz) jupiter # /usr/local/bin/openssl version OpenSSL 1.1.1b 26 Feb 2019 jupiter # The sources compile clean with Oracle Studio and test perfect. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From kgoldman at us.ibm.com Thu May 9 20:28:03 2019 From: kgoldman at us.ibm.com (Kenneth Goldman) Date: Thu, 9 May 2019 16:28:03 -0400 Subject: Issue in linking Openssl1.1.1b to application In-Reply-To: <1557422644307-0.post@n7.nabble.com> References: <1557410588671-0.post@n7.nabble.com> <542b1cab-8f0a-3e4a-6de4-0cfc72a6b756@us.ibm.com> <1557422644307-0.post@n7.nabble.com> Message-ID: > From: vin > To: openssl-users at openssl.org > Date: 05/09/2019 01:24 PM > Subject: Re: Issue in linking Openssl1.1.1b to application > Sent by: "openssl-users" > > Hi Ken > > Thanks for the reply.If I am not wrong ,You are asking me to set the path of > the dll in set path environment variable in testing machine (windows 7 32 > bit) right?? Right. In the PATH environment variable. > > But the issue is if same dll built with openssl0.9.8k is registering > properly in same test machine. If 098 used the Shining Light installer, I recall that there was/is an option to install the dlls in the system area or not. Perhaps you installed 098 in the system area but not 111. > After replacing openssl libraries by openssl1.1.1b I am facing this issue.So > I guess building dll using visual studio 2008 is missing some steps . Oh, wait!!! I didn't notice that you're building openssl yourself. I've always used Shining Light. So it could be a problem in the way they're being build. > Can you please help me further?? Sure. I have 1.1 working with Visual Studio, although I still can't get 1.1 64-bit working with mingw. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rama.krushna7 at gmail.com Fri May 10 00:29:55 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Fri, 10 May 2019 05:59:55 +0530 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: References: <221BCF4F-2C5E-461D-A549-EA58B180B03A@akamai.com> Message-ID: Hi, Could anyone please help me wth it. Following are sslc speed results for SHA1. sslc speed sha1 Doing sha1 for 3s on 16 size blocks: 16858430 sha1's in 2.98s Doing sha1 for 3s on 64 size blocks: 14147528 sha1's in 3.00s Doing sha1 for 3s on 256 size blocks: 6436755 sha1's in 2.99s Doing sha1 for 3s on 1024 size blocks: 2055335 sha1's in 3.00s Doing sha1 for 3s on 8192 size blocks: 266404 sha1's in 2.99s Doing sha1 for 3s on 16384 size blocks: 152376 sha1's in 3.00s OpenSSL 1.1.0e 16 Feb 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DOPENSSLDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install\"" -DENGINESDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install/lib/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha1 90515.06k 301813.93k 551106.78k 701554.35k 729893.50k 832176.13k sslc speed sha1 Doing sha1 for 3s on 16 size blocks: 16939397 sha1's in 2.99s Doing sha1 for 3s on 64 size blocks: 11489920 sha1's in 3.00s Doing sha1 for 3s on 256 size blocks: 5316410 sha1's in 2.99s Doing sha1 for 3s on 1024 size blocks: 2006834 sha1's in 3.00s Doing sha1 for 3s on 8192 size blocks: 273661 sha1's in 2.98s Doing sha1 for 3s on 16384 size blocks: 150159 sha1's in 2.99s OpenSSL 1.1.1 11 Sep 2018 built on: Tue Feb 12 18:18:22 2019 UTC options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -fPIC -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DNDEBUG -fPIC The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha1 90645.60k 245118.29k 455184.27k 684999.34k 752292.25k 822811.06k Does not this means 1.1.1 process lesser number of bytes per second compared to 1.1.0e ? Thanks and Regards, Ram Krushna On Thu, May 9, 2019 at 11:46 PM Salz, Rich wrote: > *> *Could you please look into the program and let me know if anything > I am doing wrong ? > > > Or else What could be the issue ? > > > > Sorry, no not me. Maybe someone else on the list has ideas. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rama.krushna7 at gmail.com Fri May 10 01:16:08 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Fri, 10 May 2019 06:46:08 +0530 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: References: <221BCF4F-2C5E-461D-A549-EA58B180B03A@akamai.com> Message-ID: Hi , The results on a AIX machine looks more bad If I am interpreting them correctly. openssl 1.1.0e : The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha1 65019.16k 151552.49k 266107.41k 337113.93k 360792.93k 364102.89k openssl 1.1.1 : The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha1 10641.28k 21433.09k 38464.85k 48496.92k 49381.38k 51755.48k could any one please confirm if my interpretation is correct ? I doubt any issue with openssl 1.1.1 version with such wider user base. How to debug this further ? Thanks and Regards, Ram Krushna On Fri, May 10, 2019 at 5:59 AM ramakrushna mishra wrote: > Hi, > > Could anyone please help me wth it. > > Following are sslc speed results for SHA1. > > sslc speed sha1 > Doing sha1 for 3s on 16 size blocks: 16858430 sha1's in 2.98s > Doing sha1 for 3s on 64 size blocks: 14147528 sha1's in 3.00s > Doing sha1 for 3s on 256 size blocks: 6436755 sha1's in 2.99s > Doing sha1 for 3s on 1024 size blocks: 2055335 sha1's in 3.00s > Doing sha1 for 3s on 8192 size blocks: 266404 sha1's in 2.99s > Doing sha1 for 3s on 16384 size blocks: 152376 sha1's in 3.00s > OpenSSL 1.1.0e 16 Feb 2017 > built on: reproducible build, date unspecified > options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) > blowfish(ptr) > compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS > -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM > -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM > -DOPENSSLDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install\"" > -DENGINESDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install/lib/engines-1.1\"" > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes 16384 bytes > sha1 90515.06k 301813.93k 551106.78k 701554.35k > 729893.50k 832176.13k > > > > sslc speed sha1 > Doing sha1 for 3s on 16 size blocks: 16939397 sha1's in 2.99s > Doing sha1 for 3s on 64 size blocks: 11489920 sha1's in 3.00s > Doing sha1 for 3s on 256 size blocks: 5316410 sha1's in 2.99s > Doing sha1 for 3s on 1024 size blocks: 2006834 sha1's in 3.00s > Doing sha1 for 3s on 8192 size blocks: 273661 sha1's in 2.98s > Doing sha1 for 3s on 16384 size blocks: 150159 sha1's in 2.99s > OpenSSL 1.1.1 11 Sep 2018 > built on: Tue Feb 12 18:18:22 2019 UTC > options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) > blowfish(ptr) > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -fPIC > -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM > -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DNDEBUG -fPIC > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes 16384 bytes > sha1 90645.60k 245118.29k 455184.27k 684999.34k > 752292.25k 822811.06k > > Does not this means 1.1.1 process lesser number of bytes per second > compared to 1.1.0e ? > > Thanks and Regards, > Ram Krushna > > On Thu, May 9, 2019 at 11:46 PM Salz, Rich wrote: > >> *> *Could you please look into the program and let me know if anything >> I am doing wrong ? >> >> > Or else What could be the issue ? >> >> >> >> Sorry, no not me. Maybe someone else on the list has ideas. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinayashreeks18 at gmail.com Fri May 10 04:43:29 2019 From: vinayashreeks18 at gmail.com (vin) Date: Thu, 9 May 2019 21:43:29 -0700 (MST) Subject: Issue in linking Openssl1.1.1b to application In-Reply-To: References: <1557410588671-0.post@n7.nabble.com> <542b1cab-8f0a-3e4a-6de4-0cfc72a6b756@us.ibm.com> <1557422644307-0.post@n7.nabble.com> Message-ID: <1557463409022-0.post@n7.nabble.com> Hi Ken I am almost struck in registering the built dll to windows 7 32 bit machine. Can you provide me the details on which all openssl1.1.1b output lib files and output dll files that needs to be linked to any application while building in visual studio?? Or any steps needs to be added while building openssl1.1.1b,I am following the steps below Windows 32-bit 1. perl Configure VC-WIN32 2. nmake 3. nmake test 4. nmake install -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From mann.patidar at gmail.com Fri May 10 05:16:18 2019 From: mann.patidar at gmail.com (Manish Patidar) Date: Fri, 10 May 2019 10:46:18 +0530 Subject: Openssl1.1.1 fips certification Message-ID: Hi Can you please tell me what is the plan for fips certification for openssl1.1.1, when the fips version will be available ? Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Fri May 10 05:28:17 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 10 May 2019 15:28:17 +1000 Subject: Openssl1.1.1 fips certification In-Reply-To: References: Message-ID: There is no confirmed timeline for FIPS availability for OpenSSL 3.0. There will never be a FIPS 1.1.1 version. It is almost certain that there will be a gap between the end of support of 1.0.2 (end of this year) and a FIPS validated 3.0 release. If FIPS is vital for you then there is an extended support option for 1.0.2 but it isn?t free: https://www.openssl.org/support/contracts.html#premium We are still hopeful that a close to FIPS ready version of OpenSSL will be done by the end of the year and, if it is, validation would likely occur next year. I?ll reiterate: there is no definite timeline, FIPS will happen when it happens and not before. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 10 May 2019, at 3:16 pm, Manish Patidar wrote: > > Hi > Can you please tell me what is the plan for fips certification for openssl1.1.1, when the fips version will be available ? > > Regards > Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunggg at umich.edu Fri May 10 05:33:22 2019 From: sunggg at umich.edu (Sunghyun Park) Date: Thu, 9 May 2019 22:33:22 -0700 Subject: Building OpenSSL with Emscripten Message-ID: Nice to meet you all :) I faced a problem while building assembly code in OpenSSL (e.g., crypto/x86_64cpuid.s) with Emscripten. Since Emscripten does not support compilation for assembly code (As far as I know), I'm wondering if there is any version of OpenSSL that does not require compiling assembly code. Or, if there is anyone who experienced the similar problem, please share your experience. Thank you! -- Best, Sung -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Fri May 10 05:43:06 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 10 May 2019 15:43:06 +1000 Subject: Building OpenSSL with Emscripten In-Reply-To: References: Message-ID: Configure with the _no-asm_ option. It will be a **lot** slower. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 10 May 2019, at 3:33 pm, Sunghyun Park wrote: > > Nice to meet you all :) > > I faced a problem while building assembly code in OpenSSL (e.g., crypto/x86_64cpuid.s) with Emscripten. > Since Emscripten does not support compilation for assembly code (As far as I know), I'm wondering if there is any version of OpenSSL that does not require compiling assembly code. > Or, if there is anyone who experienced the similar problem, please share your experience. > > Thank you! > > -- > Best, Sung -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri May 10 06:03:53 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 10 May 2019 08:03:53 +0200 Subject: Building OpenSSL with Emscripten In-Reply-To: References: Message-ID: <2fe82a9f-1346-d856-8d6c-bf643026395a@wisemo.com> By the way, has anyone worked on a feature or patch to use browser provided crypto functions (WebCrypto etc.) when compiled to pseudo-javascript via EmScripten or WebAssembly? On 10/05/2019 07:43, Dr Paul Dale wrote: > Configure with the _no-asm_ option. > > It will be a **lot** slower. > > >> On 10 May 2019, at 3:33 pm, Sunghyun Park > > wrote: >> >> Nice to meet you all :) >> >> I faced a problem while building assembly code in OpenSSL (e.g., >> crypto/x86_64cpuid.s) with Emscripten. >> Since Emscripten does not support compilation for assembly code (As >> far as I know), I'm wondering if there is any version of OpenSSL that >> does not require compiling assembly code. >> Or, if there is anyone who experienced the similar problem, please >> share your experience. >> >> 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 sunggg at umich.edu Fri May 10 06:55:59 2019 From: sunggg at umich.edu (Sunghyun Park) Date: Thu, 9 May 2019 23:55:59 -0700 Subject: Building OpenSSL with Emscripten In-Reply-To: References: Message-ID: I realized I made a mistake when I tried that option before. Now it works great. Thank you! :) On Thu, May 9, 2019 at 10:43 PM Dr Paul Dale wrote: > Configure with the _no-asm_ option. > > It will be a **lot** slower. > > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > > > On 10 May 2019, at 3:33 pm, Sunghyun Park wrote: > > Nice to meet you all :) > > I faced a problem while building assembly code in OpenSSL (e.g., > crypto/x86_64cpuid.s) with Emscripten. > Since Emscripten does not support compilation for assembly code (As far as > I know), I'm wondering if there is any version of OpenSSL that does not > require compiling assembly code. > Or, if there is anyone who experienced the similar problem, please share > your experience. > > Thank you! > > -- > Best, Sung > > > -- Best, Sung -------------- next part -------------- An HTML attachment was scrubbed... URL: From rama.krushna7 at gmail.com Fri May 10 09:56:08 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Fri, 10 May 2019 15:26:08 +0530 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: References: <221BCF4F-2C5E-461D-A549-EA58B180B03A@akamai.com> Message-ID: Hi , I have installed openssl from scratch and there I am not observing any degradation. But I built it with in my project, there I observe the degradation. The Configure file remains same , but still in my project I can see a difference that "dynamic-engine" is present in enabled feature list. But In Configure file its present in disabled list. So, Could anyone suggest how this can be disabled ? And I want to build the openssl outside my project) with dynamic-engine enabled. What Configure argument shall i pass or make changes in Configure file to achive that ? Thanks and Regards, Ram Krushna On Fri, May 10, 2019 at 6:46 AM ramakrushna mishra wrote: > Hi , > > The results on a AIX machine looks more bad If I am interpreting them > correctly. > > openssl 1.1.0e : > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes 16384 bytes > sha1 65019.16k 151552.49k 266107.41k 337113.93k > 360792.93k 364102.89k > > > openssl 1.1.1 : > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes 16384 bytes > sha1 10641.28k 21433.09k 38464.85k 48496.92k > 49381.38k 51755.48k > > could any one please confirm if my interpretation is correct ? > I doubt any issue with openssl 1.1.1 version with such wider user base. > How to debug this further ? > > Thanks and Regards, > Ram Krushna > > > On Fri, May 10, 2019 at 5:59 AM ramakrushna mishra < > rama.krushna7 at gmail.com> wrote: > >> Hi, >> >> Could anyone please help me wth it. >> >> Following are sslc speed results for SHA1. >> >> sslc speed sha1 >> Doing sha1 for 3s on 16 size blocks: 16858430 sha1's in 2.98s >> Doing sha1 for 3s on 64 size blocks: 14147528 sha1's in 3.00s >> Doing sha1 for 3s on 256 size blocks: 6436755 sha1's in 2.99s >> Doing sha1 for 3s on 1024 size blocks: 2055335 sha1's in 3.00s >> Doing sha1 for 3s on 8192 size blocks: 266404 sha1's in 2.99s >> Doing sha1 for 3s on 16384 size blocks: 152376 sha1's in 3.00s >> OpenSSL 1.1.0e 16 Feb 2017 >> built on: reproducible build, date unspecified >> options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) >> blowfish(ptr) >> compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS >> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 >> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m >> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM >> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM >> -DOPENSSLDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install\"" >> -DENGINESDIR="\"/vobs_prgs/tools/linuxx86_64/openssl/install/lib/engines-1.1\"" >> The 'numbers' are in 1000s of bytes per second processed. >> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 >> bytes 16384 bytes >> sha1 90515.06k 301813.93k 551106.78k 701554.35k >> 729893.50k 832176.13k >> >> >> >> sslc speed sha1 >> Doing sha1 for 3s on 16 size blocks: 16939397 sha1's in 2.99s >> Doing sha1 for 3s on 64 size blocks: 11489920 sha1's in 3.00s >> Doing sha1 for 3s on 256 size blocks: 5316410 sha1's in 2.99s >> Doing sha1 for 3s on 1024 size blocks: 2006834 sha1's in 3.00s >> Doing sha1 for 3s on 8192 size blocks: 273661 sha1's in 2.98s >> Doing sha1 for 3s on 16384 size blocks: 150159 sha1's in 2.99s >> OpenSSL 1.1.1 11 Sep 2018 >> built on: Tue Feb 12 18:18:22 2019 UTC >> options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) >> blowfish(ptr) >> compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -fPIC >> -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ >> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 >> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM >> -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM >> -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DNDEBUG -fPIC >> The 'numbers' are in 1000s of bytes per second processed. >> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 >> bytes 16384 bytes >> sha1 90645.60k 245118.29k 455184.27k 684999.34k >> 752292.25k 822811.06k >> >> Does not this means 1.1.1 process lesser number of bytes per second >> compared to 1.1.0e ? >> >> Thanks and Regards, >> Ram Krushna >> >> On Thu, May 9, 2019 at 11:46 PM Salz, Rich wrote: >> >>> *> *Could you please look into the program and let me know if >>> anything I am doing wrong ? >>> >>> > Or else What could be the issue ? >>> >>> >>> >>> Sorry, no not me. Maybe someone else on the list has ideas. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Fri May 10 13:04:17 2019 From: kgoldman at us.ibm.com (Kenneth Goldman) Date: Fri, 10 May 2019 09:04:17 -0400 Subject: Issue in linking Openssl1.1.1b to application In-Reply-To: <1557463409022-0.post@n7.nabble.com> References: <1557410588671-0.post@n7.nabble.com> <542b1cab-8f0a-3e4a-6de4-0cfc72a6b756@us.ibm.com> <1557422644307-0.post@n7.nabble.com> <1557463409022-0.post@n7.nabble.com> Message-ID: > From: vin > To: openssl-users at openssl.org > Date: 05/10/2019 12:44 AM > Subject: Re: Issue in linking Openssl1.1.1b to application > Sent by: "openssl-users" > > Hi Ken > > I am almost struck in registering the built dll to windows 7 32 bit machine. > > Can you provide me the details on which all openssl1.1.1b output lib files > and output dll files that needs to be linked to any application while > building in visual studio?? With mingw, I specify this to the linker c:/program files/openssl/lib/mingw/libcrypto-1_1.a In Visual Studio, Linker - Input - Additional Dependencies: libcrypto32mdd.lib Linker - General - Additional Library Directory: c:\program files\openssl \lib\vc However, it sounded like you were linking correctly, but Windows could not find the dll at runtime. That points to a PATH issue. > > Or any steps needs to be added while building openssl1.1.1b,I am following > the steps below > Windows 32-bit > 1. perl Configure VC-WIN32 > 2. nmake > 3. nmake test > 4. nmake install I don't build myself. I use Shining Light: http://slproweb.com/products/Win32OpenSSL.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgcyient at gmail.com Fri May 10 15:01:43 2019 From: cgcyient at gmail.com (Chandu Gangireddy) Date: Fri, 10 May 2019 11:01:43 -0400 Subject: openssl failed to connect to MS Exchange Server (Office365) on RHEL 7.x Message-ID: Dear OpenSSL Users, At my corporate environment, I'm experience a challenge to use openssl s_client utility. I really appreciate if someone can help me narrow down the issue. Here the details - Platform: RHEL 7.x *Openssl version:* OpenSSL 1.0.2k-fips 26 Jan 2017 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/etc/pki/tls" engines: rdrand dynamic Command tried to tes the connectivity between my Linux client server to remote office 365 exchange server using POP3 port - $ openssl s_client -crlf -connect outlook.office365.com:995 ... ... subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=outlook.com issuer=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1 --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3952 bytes and written 415 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-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-GCM-SHA384 Session-ID: 072F0000FFDC6177DE9CAB2B59EA06E486A25AD8A2882A9B82F16678BAD74E79 Session-ID-ctx: Master-Key: DD7B59F38867FEAB9656B519FBCD743158E528C63FF9A96CE758120424159F26967F9F6FE57A9B5E7CAD806798322278 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1557500061 Timeout : 300 (sec) Verify return code: 0 (ok) --- +OK The Microsoft Exchange POP3 service is ready. [QgBOADYAUABSADEANABDAEEAMAAwADQAMgAuAG4AYQBtAHAAcgBkADEANAAuAHAAcgBvAGQALgBvAHUAdABsAG8AbwBrAC4AYwBvAG0A] *USER netcool2 at cox.com * *+OK* *PASS XXXXXXXX* *-ERR Logon failure: unknown user name or bad password.* *quit* *+OK Microsoft Exchange Server POP3 server signing off.* *read:errno=0* Operating System: Red Hat Enterprise Linux Server release 7.2 (Maipo) When I did the same from a different server, it worked as expected. Following are the two difference which I noticed between a working server and non-working server. *Working server details:* 1. Red Hat Enterprise Linux Server release 6.9 (Santiago) 2. openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Jan 30 07:47:24 EST 2017 platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/etc/pki/tls" engines: dynamic Please let me know if you need any further details from my end. Thanks, in advance. Chandu -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Fri May 10 15:09:55 2019 From: janjust at nikhef.nl (Jan Just Keijser) Date: Fri, 10 May 2019 17:09:55 +0200 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: References: <221BCF4F-2C5E-461D-A549-EA58B180B03A@akamai.com> Message-ID: On 10/05/19 03:16, ramakrushna mishra wrote: > Hi , > > The results on a AIX machine looks more bad If I am interpreting them > correctly. > > openssl 1.1.0e : > The 'numbers' are in 1000s of bytes per second processed. > type? ? ? ? ? ? ?16 bytes? ? ?64 bytes? ? 256 bytes ?1024 bytes? ?8192 > bytes? 16384 bytes > sha1? ? ? ? ? ? ?65019.16k? ?151552.49k? ?266107.41k ?337113.93k? > ?360792.93k? ?364102.89k > > > openssl 1.1.1 : > The 'numbers' are in 1000s of bytes per second processed. > type? ? ? ? ? ? ?16 bytes? ? ?64 bytes? ? 256 bytes ?1024 bytes? ?8192 > bytes? 16384 bytes > sha1? ? ? ? ? ? ?10641.28k? ? 21433.09k? ? 38464.85k 48496.92k? ? > 49381.38k? ? 51755.48k > > the numbers for openssl 1.1.1 seem wrong - I've ran a similar test on a POWER8 and POWER9 box and the results for a "out of the box compiled" openssl 1.1.0 vs openssl 1.1.1 are much closer. The only difference I did see was the (obsolete) sha1 test on Power8:? openssl 1.1.1 seems to be a bit slower than 1.1.0, but not by a factor of 7 as shown above. Also, on both POWER8 and POWER9, there does not appear to be a major difference in blowfish or aes-256 speed. As for your code: I would check that you are not using a no-asm build for openssl 1.1.1. HTH, JJK From janjust at nikhef.nl Fri May 10 15:06:49 2019 From: janjust at nikhef.nl (Jan Just Keijser) Date: Fri, 10 May 2019 17:06:49 +0200 Subject: Reg slowness seen in openssl 1.1.1 In-Reply-To: References: <221BCF4F-2C5E-461D-A549-EA58B180B03A@akamai.com> Message-ID: <5395216c-a6e7-b164-0680-ebfe704c1d82@nikhef.nl> Hi, On 10/05/19 02:29, ramakrushna mishra wrote: > Hi, > > Could anyone please help me wth it. > > Following are sslc speed results for SHA1. > > [...] > OpenSSL 1.1.0e? 16 Feb 2017 > type? ? ? ? ? ? ?16 bytes? ? ?64 bytes? ? 256 bytes? ?1024 bytes? > ?8192 bytes? 16384 bytes > sha1? ? ? ? ? ? ?90515.06k? ?301813.93k? ?551106.78k ?701554.35k? > ?729893.50k? ?832176.13k > > [...] > OpenSSL 1.1.1? 11 Sep 2018type? ? ? ? ? ? ?16 bytes ?64 bytes? ? 256 > bytes? ?1024 bytes? ?8192 bytes? 16384 bytes > sha1? ? ? ? ? ? ?90645.60k? ?245118.29k? ?455184.27k ?684999.34k? > ?752292.25k? ?822811.06k > I have a lot of experience running 'openssl speed' tests and these numbers would not worry me too much - if you were to run each of these tests 10 times **on an empty system** , then average the results , then most likely you will find that the results are within 5% of each other. IOW, OpenSSL 1.1.1 is just as fast/slow on this purely artificial speed test as 1.1.0 HTH, JJK From sreekanth1m at gmail.com Fri May 10 15:13:07 2019 From: sreekanth1m at gmail.com (Sreekanth Reddy) Date: Fri, 10 May 2019 10:13:07 -0500 Subject: Build the FIPS Object Module issue on Ubuntu 18.04 Message-ID: Hi, I am trying to build the FIPS object module using the fips library openssl-fips-2.0.16 on Ubuntu 18.04 for x86 arch. I am following the steps in https://wiki.openssl.org/index.php/FIPS_Library_and_Android below steps are followed to Build the FIPS Object Module: $ . ./setenv-android.sh $ cd openssl-fips-2.0.5/ $ ./config $ make First 3 steps are successful, able to set the environment paths, run the config but make fails with error "cryptlib.h:62:20: fatal error: stdlib.h: No such file or directory" - "#inlcude I do have the libraries under /usr/inlcude but the make is not looking at the right path. below is the error message received: In file included from cryptlib.c:117:0: cryptlib.h:62:20: fatal error: stdlib.h: No such file or directory #include ^ compilation terminated. : recipe for target 'cryptlib.o' failed make[1]: *** [cryptlib.o] Error 1 Also, attaching the complete error log. Could you please suggest what is the issue and where to change the path reference (in config). Thanks, Sreekanth -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Build FIPS Object Module_x86_Ubuntu_18.04 Type: application/octet-stream Size: 24672 bytes Desc: not available URL: From John.Unsworth at synchronoss.com Fri May 10 15:23:23 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Fri, 10 May 2019 15:23:23 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution Message-ID: This seems to be caused by the ongoing saga documented in issues 6912 and 8102. These functions were declared as weak in 1.1.1b. safestack.h # pragma weak OPENSSL_sk_num # pragma weak OPENSSL_sk_value # pragma weak OPENSSL_sk_new # pragma weak OPENSSL_sk_new_null ... lhash.h # pragma weak OPENSSL_LH_new # pragma weak OPENSSL_LH_free # pragma weak OPENSSL_LH_insert # pragma weak OPENSSL_LH_delete ... Removing these lines allows all the tests to work. I am building static libraries (no-shared) which is presumably why it works for some people out of the box if they are using shared libraries. Please advise as to the way forward. I note that one other user (see 8102) has reported this too: >>>>>>>>>>> rammishr commented on Mar 26 Hi, Sorry if this should have been posted separately. When i build openssl1.1.1b on solaris , it is successful. But while verifying the version " openssl version" it fails with below error. ld.so.1: openssl: fatal: relocation error: file /vobs_tools/prgs/src/openssl/solaris64/bin/openssl: symbol OPENSSL_sk_new_null: referenced symbol not found Killed The same machine works fine for openssl1.1.1. So, in 1.1.1b I can observe that OPENSSL_sk_new_null has been defined as below in safestack.h. pragma weak OPENSSL_sk_new_null Can this be related ? Am I missing anything while Configure ? <<<<<<<<<<<<<<< Regards, John. -----Original Message----- From: openssl-users On Behalf Of John Unsworth Sent: 09 May 2019 10:13 To: openssl-users at openssl.org Subject: RE: OpenSSL 1.1.1b tests fail on Solaris CAUTION: This email originated from outside of Synchronoss. This looks like the problem: ld.so.1: sanitytest: fatal: relocation error: file ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not ok 1 - running sanitytest # Failed test 'running sanitytest' # at /home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests This results in the same error: sol-mds-build-01 $ cd apps sol-mds-build-01 $ ./openssl version ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found I have built static libraries. John -----Original Message----- From: openssl-users On Behalf Of Matt Caswell Sent: 09 May 2019 09:38 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris CAUTION: This email originated from outside of Synchronoss. What is the output from: $ make V=1 TESTS=test_sanity test Matt On 08/05/2019 19:22, John Unsworth wrote: > I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 > Generic_Virtual sun4v sparc SUNW,T5140. > > > > ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 > -xldscope=hidden > > > > It builds fine but all the tests fail, with or without no-asm. Can > anyone help please? Here is the start of the test run: > > > > $ make test > > make depend && make _tests > > ( cd test; \ > > mkdir -p test-runs; \ > > SRCTOP=../. \ > > BLDTOP=../. \ > > RESULT_D=test-runs \ > > PERL="/opt/perl-5.26.1/bin/perl" \ > > EXE_EXT= \ > > OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ > > OPENSSL_DEBUG_MEMORY=on \ > > /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) > > ../test/recipes/01-test_abort.t .................... ok > > ../test/recipes/01-test_sanity.t ................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > Regards, > > John. > From sunggg at umich.edu Fri May 10 20:29:36 2019 From: sunggg at umich.edu (Sunghyun Park) Date: Fri, 10 May 2019 13:29:36 -0700 Subject: Building OpenSSL with Emscripten In-Reply-To: References: Message-ID: Hi, all. Thanks for your help, I could finish compilation to the end. However, athough I successfully compiled with _no-asm_ options, I found a problem when loading the compiled library in the 3rd party code base. When looking into the source code, the definition of some function seems to require a specific preprocessor to be compiled. (For example, PEM_write_bio_DSAPrivateKey needs '#define OPENSSL_FIPS'.) I installed *openssl-1.0.2r.tar.gz *and only provided *no-asm* for configuration. Am I missing some dependencies or necessary options? The error I'm facing is as follows: error: undefined symbol: AES_ctr128_encrypt warning: To disable errors for undefined symbols use `-s ERROR_ON_UNDEFINED_SYMBOLS=0` error: undefined symbol: AES_set_encrypt_key error: undefined symbol: BIO_ctrl error: undefined symbol: BIO_free error: undefined symbol: BIO_new error: undefined symbol: BIO_s_mem error: undefined symbol: BN_bn2bin error: undefined symbol: BN_free error: undefined symbol: BN_is_bit_set error: undefined symbol: BN_new error: undefined symbol: BN_num_bits error: undefined symbol: BN_set_word error: undefined symbol: CRYPTO_free error: undefined symbol: CRYPTO_malloc error: undefined symbol: DSA_free error: undefined symbol: DSA_generate_key error: undefined symbol: DSA_generate_parameters_ex error: undefined symbol: DSA_new error: undefined symbol: EC_KEY_free error: undefined symbol: EC_KEY_generate_key error: undefined symbol: EC_KEY_get0_group error: undefined symbol: EC_KEY_get0_public_key error: undefined symbol: EC_KEY_new_by_curve_name error: undefined symbol: EC_KEY_set_asn1_flag error: undefined symbol: EC_POINT_point2oct .... Any advice would be a great help! Thank you. On Thu, May 9, 2019 at 10:43 PM Dr Paul Dale wrote: > Configure with the _no-asm_ option. > > It will be a **lot** slower. > > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > > > On 10 May 2019, at 3:33 pm, Sunghyun Park wrote: > > Nice to meet you all :) > > I faced a problem while building assembly code in OpenSSL (e.g., > crypto/x86_64cpuid.s) with Emscripten. > Since Emscripten does not support compilation for assembly code (As far as > I know), I'm wondering if there is any version of OpenSSL that does not > require compiling assembly code. > Or, if there is anyone who experienced the similar problem, please share > your experience. > > Thank you! > > -- > Best, Sung > > > -- Best, Sung -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogelke+openssl at pobox.com Fri May 10 20:48:54 2019 From: vogelke+openssl at pobox.com (Karl Vogel) Date: Fri, 10 May 2019 16:48:54 -0400 (EDT) Subject: OpenSSL 1.1.1b tests fail on Solaris Message-ID: <20190510204854.C8EF9300A5B@zhtv-82326.wpafb.af.mil> An embedded and charset-unspecified text was scrubbed... Name: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sparcv9a-patch URL: From jb-openssl at wisemo.com Sat May 11 19:01:37 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sat, 11 May 2019 21:01:37 +0200 Subject: openssl failed to connect to MS Exchange Server (Office365) on RHEL 7.x In-Reply-To: References: Message-ID: Your transcript below seems to show a successful connection to Microsoft's cloud mail, then Microsoft rejecting the password and closing the connection. You are not connecting to your own Exchange server, but to a central Microsoft service that also handles their consumer mail accounts (hotmail.com, live.com, outlook.com etc.).? This service load balances connections between many servers which cab give different results for each try. On 10/05/2019 17:01, Chandu Gangireddy wrote: > Dear OpenSSL Users, > > At my corporate environment, I'm experience a challenge to use openssl > s_client utility. I really appreciate if someone can help me narrow > down the issue. > > Here the details - > > Platform: RHEL 7.x > *Openssl version:* > OpenSSL 1.0.2k-fips? 26 Jan 2017 > built on: reproducible build, date unspecified > platform: linux-x86_64 > options:? bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) > idea(int) blowfish(idx) > compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB > -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT > -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 > -grecord-gcc-switches? ?-m64 -mtune=generic -Wa,--noexecstack -DPURIFY > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM > -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM > -DGHASH_ASM -DECP_NISTZ256_ASM > OPENSSLDIR: "/etc/pki/tls" > engines:? rdrand dynamic > > Command tried to tes the connectivity between my Linux client server > to remote office 365 exchange server using POP3 port - > > $ openssl s_client -crlf?-connect outlook.office365.com:995 > > ... > ... > subject=/C=US/ST=Washington/L=Redmond/O=Microsoft > Corporation/CN=outlook.com > issuer=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1 > --- > No client certificate CA names sent > Peer signing digest: SHA256 > Server Temp Key: ECDH, P-256, 256 bits > --- > SSL handshake has read 3952 bytes and written 415 bytes > --- > New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-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-GCM-SHA384 > ? ? Session-ID: > 072F0000FFDC6177DE9CAB2B59EA06E486A25AD8A2882A9B82F16678BAD74E79 > ? ? Session-ID-ctx: > ? ? Master-Key: > DD7B59F38867FEAB9656B519FBCD743158E528C63FF9A96CE758120424159F26967F9F6FE57A9B5E7CAD806798322278 > ? ? Key-Arg? ?: None > ? ? Krb5 Principal: None > ? ? PSK identity: None > ? ? PSK identity hint: None > ? ? Start Time: 1557500061 > ? ? Timeout? ?: 300 (sec) > ? ? Verify return code: 0 (ok) > --- > +OK The Microsoft Exchange POP3 service is ready. > [QgBOADYAUABSADEANABDAEEAMAAwADQAMgAuAG4AYQBtAHAAcgBkADEANAAuAHAAcgBvAGQALgBvAHUAdABsAG8AbwBrAC4AYwBvAG0A] > *USER netcool2 at cox.com * > *+OK* > *PASS XXXXXXXX* > *-ERR Logon failure: unknown user name or bad password.* > *quit* > *+OK Microsoft Exchange Server POP3 server signing off.* > *read:errno=0* > > Operating System: > Red Hat Enterprise Linux Server release 7.2 (Maipo) > > When I did the same from a different server, it worked as expected. > Following are the two difference which I noticed between a working > server and non-working server. > * > * > *Working server details:* > 1. Red Hat Enterprise Linux Server release?6.9 (Santiago) > 2. openssl version > OpenSSL 1.0.1e-fips 11 Feb 2013 > built on: Mon Jan 30 07:47:24 EST 2017 > platform: linux-x86_64 > options:? bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) > idea(int) blowfish(idx) > compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS > -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN > -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic > -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM > -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM > -DWHIRLPOOL_ASM -DGHASH_ASM > OPENSSLDIR: "/etc/pki/tls" > engines:? dynamic > > Please let me know if you need any further details from my end. > > Thanks, in advance. > Chandu -- Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded From cgcyient at gmail.com Sat May 11 19:09:31 2019 From: cgcyient at gmail.com (Chandu Gangireddy) Date: Sat, 11 May 2019 15:09:31 -0400 Subject: openssl failed to connect to MS Exchange Server (Office365) on RHEL 7.x In-Reply-To: References: Message-ID: Thank you so much for the response Jakob. Yes I agree with you about the connection succeeded and later rejected on credentials part. The same worked from all the RHEL Version below 7 so I was thinking it might be a issue at OS level. Based on your suggestion, I feel that the issue is with the Exchange Server. Please double confirm. Thanks and Regards Chandu On Sat, May 11, 2019, 3:02 PM Jakob Bohm via openssl-users < openssl-users at openssl.org> wrote: > Your transcript below seems to show a successful connection to Microsoft's > cloud mail, then Microsoft rejecting the password and closing the > connection. > > You are not connecting to your own Exchange server, but to a central > Microsoft > service that also handles their consumer mail accounts (hotmail.com, > live.com, > outlook.com etc.). This service load balances connections between many > servers > which cab give different results for each try. > > On 10/05/2019 17:01, Chandu Gangireddy wrote: > > Dear OpenSSL Users, > > > > At my corporate environment, I'm experience a challenge to use openssl > > s_client utility. I really appreciate if someone can help me narrow > > down the issue. > > > > Here the details - > > > > Platform: RHEL 7.x > > *Openssl version:* > > OpenSSL 1.0.2k-fips 26 Jan 2017 > > built on: reproducible build, date unspecified > > platform: linux-x86_64 > > options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) > > idea(int) blowfish(idx) > > compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB > > -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT > > -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > > -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 > > -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY > > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > > -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM > > -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM > > -DGHASH_ASM -DECP_NISTZ256_ASM > > OPENSSLDIR: "/etc/pki/tls" > > engines: rdrand dynamic > > > > Command tried to tes the connectivity between my Linux client server > > to remote office 365 exchange server using POP3 port - > > > > $ openssl s_client -crlf -connect outlook.office365.com:995 > > > > ... > > ... > > subject=/C=US/ST=Washington/L=Redmond/O=Microsoft > > Corporation/CN=outlook.com > > issuer=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1 > > --- > > No client certificate CA names sent > > Peer signing digest: SHA256 > > Server Temp Key: ECDH, P-256, 256 bits > > --- > > SSL handshake has read 3952 bytes and written 415 bytes > > --- > > New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-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-GCM-SHA384 > > Session-ID: > > 072F0000FFDC6177DE9CAB2B59EA06E486A25AD8A2882A9B82F16678BAD74E79 > > Session-ID-ctx: > > Master-Key: > > > DD7B59F38867FEAB9656B519FBCD743158E528C63FF9A96CE758120424159F26967F9F6FE57A9B5E7CAD806798322278 > > Key-Arg : None > > Krb5 Principal: None > > PSK identity: None > > PSK identity hint: None > > Start Time: 1557500061 > > Timeout : 300 (sec) > > Verify return code: 0 (ok) > > --- > > +OK The Microsoft Exchange POP3 service is ready. > > > [QgBOADYAUABSADEANABDAEEAMAAwADQAMgAuAG4AYQBtAHAAcgBkADEANAAuAHAAcgBvAGQALgBvAHUAdABsAG8AbwBrAC4AYwBvAG0A] > > *USER netcool2 at cox.com * > > *+OK* > > *PASS XXXXXXXX* > > *-ERR Logon failure: unknown user name or bad password.* > > *quit* > > *+OK Microsoft Exchange Server POP3 server signing off.* > > *read:errno=0* > > > > Operating System: > > Red Hat Enterprise Linux Server release 7.2 (Maipo) > > > > When I did the same from a different server, it worked as expected. > > Following are the two difference which I noticed between a working > > server and non-working server. > > * > > * > > *Working server details:* > > 1. Red Hat Enterprise Linux Server release 6.9 (Santiago) > > 2. openssl version > > OpenSSL 1.0.1e-fips 11 Feb 2013 > > built on: Mon Jan 30 07:47:24 EST 2017 > > platform: linux-x86_64 > > options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) > > idea(int) blowfish(idx) > > compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS > > -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN > > -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic > > -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM > > -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM > > -DWHIRLPOOL_ASM -DGHASH_ASM > > OPENSSLDIR: "/etc/pki/tls" > > engines: dynamic > > > > Please let me know if you need any further details from my end. > > > > Thanks, in advance. > > Chandu > > > -- > Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 > > This message is only for its intended recipient, delete if misaddressed. > WiseMo - Remote Service Management for PCs, Phones and Embedded > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Sun May 12 10:53:22 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Sun, 12 May 2019 06:53:22 -0400 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution In-Reply-To: References: Message-ID: <2306294c-3b45-3633-ffbb-414abe309a90@blastwave.org> On 5/10/19 11:23 AM, John Unsworth wrote: > This seems to be caused by the ongoing saga documented I have this working flawlessly on S10 ... what is the issue : jupiter # /usr/local/bin/openssl version OpenSSL 1.1.1b 26 Feb 2019 dc From John.Unsworth at synchronoss.com Sun May 12 16:30:15 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Sun, 12 May 2019 16:30:15 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution In-Reply-To: <2306294c-3b45-3633-ffbb-414abe309a90@blastwave.org> References: <2306294c-3b45-3633-ffbb-414abe309a90@blastwave.org> Message-ID: As I have said at least 4 times previously I am building no-shared. Are you? -----Original Message----- From: openssl-users On Behalf Of Dennis Clarke Sent: 12 May 2019 11:53 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution CAUTION: This email originated from outside of Synchronoss. On 5/10/19 11:23 AM, John Unsworth wrote: > This seems to be caused by the ongoing saga documented I have this working flawlessly on S10 ... what is the issue : jupiter # /usr/local/bin/openssl version OpenSSL 1.1.1b 26 Feb 2019 dc From beldmit at gmail.com Sun May 12 19:25:54 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sun, 12 May 2019 22:25:54 +0300 Subject: s_client + PSK + pha Message-ID: Hello I see strange behavior of openssl s_client in case of post-handshake authorization with PSK command lines: apps/openssl s_client -connect localhost:4433 -tls1_3 -4 -ciphersuites TLS_AES_128_GCM_SHA256 -psk $PSK -enable_pha -cert cert.pem -key key.pem -trace apps/openssl s_server -accept 4433 -tls1_3 -4 -ciphersuites TLS_AES_128_GCM_SHA256 -psk $PSK -nocert -no_dhe -allow_no_dhe_kex -num_tickets 0 -Verify 3 -CAfile cert.pem -trace I use self-signed certificates with 1.1.1b branch. when I interactively request the post-handshake authentification, the client sends empty certificate list. When I use the following command lines, everything is OK: apps/openssl s_client -connect localhost:4433 -tls1_2 -4 -ciphersuites TLS_AES_128_GCM_SHA256 -cert cert.pem -key key.pem -trace -CAfile cert.pem apps/openssl s_server -accept 4433 -tls1_2 -4 -ciphersuites TLS_AES_128_GCM_SHA256 -Verify 3 -CAfile cert.pem -key key.pem -cert cert.pem -trace -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cert.pem Type: application/x-x509-ca-cert Size: 1294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: key.pem Type: application/x-x509-ca-cert Size: 1708 bytes Desc: not available URL: From madwolf at openca.org Sun May 12 21:34:27 2019 From: madwolf at openca.org (Dr. Pala) Date: Sun, 12 May 2019 17:34:27 -0400 Subject: CMS and GCM Message-ID: Hi All, I am having issues using AES GCM in EnvelopedData - in particular if I use AES CBC, that is ok, but when I try to use the GCM mode, I simply cannot finalize the data. Are there any specific operations that need to happen in order to use AES in GCM mode (as per RFC5084) ? Is there a way to list the ciphers supported when using EnvelopedData ? Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ddaoiiheablnooch.png Type: image/png Size: 3146 bytes Desc: not available URL: From samiya.khanum at broadcom.com Mon May 13 12:19:18 2019 From: samiya.khanum at broadcom.com (Samiya Khanum) Date: Mon, 13 May 2019 17:49:18 +0530 Subject: opensslconf.h file not generated Message-ID: Hi, Earlier our application used openSSL version 1.0.2n. We want to upgrade to 1.1.1b. When I compile openssl, I see "opensslconf.h" not found error. ../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal error: openssl/opensslconf.h: No such file or directory With below configure options, opensslconf.h file is not generated. I tried giving --prefix, --openssldir, disable-deprecated options as well. ./Configure linux-generic32 ./Configure \ no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \ -DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6 -DOPENSSL_IMPLEMENTS_strncasecmp \ -ffunction-sections -fdata-sections \ shared no-hw no-asm \ -m32 linux-generic32 Am I missing any option in Configure. Can someone help me on this. Thanks & Regards, Samiya khanum -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon May 13 14:03:16 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 13 May 2019 07:03:16 -0700 Subject: opensslconf.h file not generated In-Reply-To: References: Message-ID: What else did you do other than configuring? Cheers Richard Samiya Khanum via openssl-users skrev: (13 maj 2019 05:19:18 GMT-07:00) >Hi, > >Earlier our application used openSSL version 1.0.2n. We want to upgrade >to >1.1.1b. >When I compile openssl, I see "opensslconf.h" not found error. > >../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal error: >openssl/opensslconf.h: No such file or directory > >With below configure options, opensslconf.h file is not generated. I >tried >giving --prefix, --openssldir, disable-deprecated options as well. > >./Configure linux-generic32 > >./Configure \ > no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \ > -DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6 >-DOPENSSL_IMPLEMENTS_strncasecmp \ > -ffunction-sections -fdata-sections \ > shared no-hw no-asm \ > -m32 linux-generic32 > >Am I missing any option in Configure. Can someone help me on this. > >Thanks & Regards, >Samiya khanum -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From samiya.khanum at broadcom.com Mon May 13 14:19:31 2019 From: samiya.khanum at broadcom.com (Samiya Khanum) Date: Mon, 13 May 2019 19:49:31 +0530 Subject: opensslconf.h file not generated In-Reply-To: References: Message-ID: Hi Richard, I have extracted tar file and executed Configure command. Do we need to set anything before Configure? On Mon 13 May, 2019, 7:33 PM Richard Levitte, wrote: > What else did you do other than configuring? > > Cheers > Richard > > Samiya Khanum via openssl-users skrev: (13 > maj 2019 05:19:18 GMT-07:00) > >Hi, > > > >Earlier our application used openSSL version 1.0.2n. We want to upgrade > >to > >1.1.1b. > >When I compile openssl, I see "opensslconf.h" not found error. > > > >../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal error: > >openssl/opensslconf.h: No such file or directory > > > >With below configure options, opensslconf.h file is not generated. I > >tried > >giving --prefix, --openssldir, disable-deprecated options as well. > > > >./Configure linux-generic32 > > > >./Configure \ > > no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \ > > -DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6 > >-DOPENSSL_IMPLEMENTS_strncasecmp \ > > -ffunction-sections -fdata-sections \ > > shared no-hw no-asm \ > > -m32 linux-generic32 > > > >Am I missing any option in Configure. Can someone help me on this. > > > >Thanks & Regards, > >Samiya khanum > > -- > Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon May 13 17:26:45 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 13 May 2019 10:26:45 -0700 Subject: opensslconf.h file not generated In-Reply-To: References: Message-ID: <871s121d0q.wl-levitte@openssl.org> Well, you do need to actually build it, i.e. run "make" What I want to do is exactly what you did that got you that error. What command did you run after configuring? Cheers, Richard On Mon, 13 May 2019 07:19:31 -0700, Samiya Khanum wrote: > > > Hi Richard, > > I have extracted tar file and executed Configure command. Do we need to set anything before > Configure? > > On Mon 13 May, 2019, 7:33 PM Richard Levitte, wrote: > > What else did you do other than configuring? > > Cheers > Richard > > Samiya Khanum via openssl-users skrev: (13 maj 2019 05:19:18 > GMT-07:00) > >Hi, > > > >Earlier our application used openSSL version 1.0.2n. We want to upgrade > >to > >1.1.1b. > >When I compile openssl, I see "opensslconf.h" not found error. > > > >../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal error: > >openssl/opensslconf.h: No such file or directory > > > >With below configure options, opensslconf.h file is not generated. I > >tried > >giving --prefix, --openssldir, disable-deprecated options as well. > > > >./Configure linux-generic32 > > > >./Configure \ > >? ? ? ? ? ? no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \ > >? ? ? ? ? ? -DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6 > >-DOPENSSL_IMPLEMENTS_strncasecmp \ > >? ? ? ? ? ? -ffunction-sections -fdata-sections \ > >? ? ? ? ? ? shared no-hw no-asm \ > >? ? ? ? ? ? -m32 linux-generic32 > > > >Am I missing any option in Configure. Can someone help me on this. > > > >Thanks & Regards, > >Samiya khanum > > -- > Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From samiya.khanum at broadcom.com Mon May 13 18:04:07 2019 From: samiya.khanum at broadcom.com (Samiya Khanum) Date: Mon, 13 May 2019 23:34:07 +0530 Subject: opensslconf.h file not generated In-Reply-To: <871s121d0q.wl-levitte@openssl.org> References: <871s121d0q.wl-levitte@openssl.org> Message-ID: Hi Richard, When I executed "make" in openssl directory, opensslconf.h file is generated. When I do "make" in our projects build directory, opensslconf.h is not generated. is this file generated by Configure command or make command? On Mon 13 May, 2019, 10:56 PM Richard Levitte, wrote: > Well, you do need to actually build it, i.e. run "make" > > What I want to do is exactly what you did that got you that error. > What command did you run after configuring? > > Cheers, > Richard > > On Mon, 13 May 2019 07:19:31 -0700, > Samiya Khanum wrote: > > > > > > Hi Richard, > > > > I have extracted tar file and executed Configure command. Do we need to > set anything before > > Configure? > > > > On Mon 13 May, 2019, 7:33 PM Richard Levitte, > wrote: > > > > What else did you do other than configuring? > > > > Cheers > > Richard > > > > Samiya Khanum via openssl-users skrev: > (13 maj 2019 05:19:18 > > GMT-07:00) > > >Hi, > > > > > >Earlier our application used openSSL version 1.0.2n. We want to > upgrade > > >to > > >1.1.1b. > > >When I compile openssl, I see "opensslconf.h" not found error. > > > > > >../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal > error: > > >openssl/opensslconf.h: No such file or directory > > > > > >With below configure options, opensslconf.h file is not generated. I > > >tried > > >giving --prefix, --openssldir, disable-deprecated options as well. > > > > > >./Configure linux-generic32 > > > > > >./Configure \ > > > no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \ > > > -DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6 > > >-DOPENSSL_IMPLEMENTS_strncasecmp \ > > > -ffunction-sections -fdata-sections \ > > > shared no-hw no-asm \ > > > -m32 linux-generic32 > > > > > >Am I missing any option in Configure. Can someone help me on this. > > > > > >Thanks & Regards, > > >Samiya khanum > > > > -- > > Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. > > > > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From restemayer at gmail.com Mon May 13 21:44:30 2019 From: restemayer at gmail.com (Christopher R) Date: Mon, 13 May 2019 16:44:30 -0500 Subject: Crashes when generating certificate Message-ID: So I'm trying to create a certificate for a new user on my domain. Created the certificate... got everything set up... went to use it and the email is completely wrong. Oops. Missed it when I updated the configuration file, and,unfortunately, its necessary, because login depends on the email associated with the certificate. Ok, take 2. Delete everything. Delete the certificates, the request, all of it for that new user. Correct the config file and try again. Gets to the end and throws TXT_DB Error number 2. Look it up and its because a certificate with that common name is already in the database. Someone recommends editing that certificate out of the database, so I pull up the index file, find the line for the incorrect certificate, and delete it. Cool. Take 3. Generates the key and the request. Try generating the certificate... it asks for a password and then does... nothing. Kicks directly to command prompt. No error. No lines of text. No questions. Nothing created. Password->command prompt. What is going on here and how do I fix this? All I want is whatever remnants of that incorrect certificate removed, where ever they are, and a correct certificate created. From karl at denninger.net Mon May 13 22:32:07 2019 From: karl at denninger.net (Karl Denninger) Date: Mon, 13 May 2019 17:32:07 -0500 Subject: Crashes when generating certificate In-Reply-To: References: Message-ID: <1684f1ca-f04a-0f1a-9bd5-9490a4935805@denninger.net> On 5/13/2019 16:44, Christopher R wrote: > So I'm trying to create a certificate for a new user on my domain. > Created the certificate... got everything set up... went to use it and > the email is completely wrong. Oops. Missed it when I updated the > configuration file, and,unfortunately, its necessary, because login > depends on the email associated with the certificate. > > Ok, take 2. Delete everything. Delete the certificates, the request, > all of it for that new user. Correct the config file and try again. > Gets to the end and throws TXT_DB Error number 2. Look it up and its > because a certificate with that common name is already in the > database. Someone recommends editing that certificate out of the > database, so I pull up the index file, find the line for the incorrect > certificate, and delete it. > > Cool. Take 3. Generates the key and the request. Try generating the > certificate... it asks for a password and then does... nothing. Kicks > directly to command prompt. No error. No lines of text. No > questions. Nothing created. Password->command prompt. What is going > on here and how do I fix this? > > All I want is whatever remnants of that incorrect certificate removed, > where ever they are, and a correct certificate created. Not sure what you have left, but probably in the certs directory. In the future REVOKE the one with the bad information, and you can then create a new one under the same common name.? Since the index file is a flat file you can edit it, but you also have to make sure the other places it references are also updated or the software can get confused.? The better choice when an error is made is to revoke the bad cert, which prevents this from happen. -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: From skip at taygeta.com Mon May 13 22:34:08 2019 From: skip at taygeta.com (Skip Carter) Date: Mon, 13 May 2019 15:34:08 -0700 Subject: Crashes when generating certificate In-Reply-To: References: Message-ID: <1557786848.4684.1.camel@taygeta.com> Christopher, On Mon, 2019-05-13 at 16:44 -0500, Christopher R wrote: > Cool.??Take 3.??Generates the key and the request.??Try generating > the > certificate... it asks for a password and then does... > nothing.??Kicks > directly to command prompt.??No error.??No lines of text.??No > questions.??Nothing created.??Password->command prompt.??What is > going > on here and how do I fix this? > that sounds like the CA server has a password set and you are not providing it. -- Dr Everett (Skip) Carter skip at taygeta.com Taygeta Scientific Inc 607 Charles Ave Seaside CA 93955 831-641-0645 x103 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part URL: From mcr at sandelman.ca Tue May 14 01:47:08 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 13 May 2019 21:47:08 -0400 Subject: creating certificate only structure -- CMS_sign Message-ID: <3490.1557798428@localhost> https://www.openssl.org/docs/man1.1.0/man3/CMS_sign.html says: If signcert and pkey are NULL then a certificates only CMS structure is output. I am trying to create one to return in an RFC7030 (EST) /cacerts request. It appears that it needs to be a NID_pkcs7_signed. a) Do I need to set any flags? b) I assume that any certificates in the STACK_OF(X509) *certs will be included? c) Does it have to have CMS_PARTIAL or some other flags set, and then call CMS_final() explicitely? I am getting error:2E07F068:CMS routines:CMS_final:cms lib (I think I am dumping the entire error stack with: unsigned long err = ERR_get_error(); while(err != 0) { fprintf(stderr, "error: %s\n", ERR_error_string(err, NULL)); err = ERR_get_error(); } when called like: signcert: (nil) pkey: (nil) certs: 0x563df7fc1e30 bio: (nil), flg: 0 (via ruby, I haven't written a C-only example yet...) I am running with => "OpenSSL 1.1.1-dev xx XXX xxxx", which is really 1.1.1c with a patch to the DTLS code. Looking at CMS_dataInit(), it looks like if the contentType is not set, and icont is NULL, and no content was provided into the CMS structure, that it simply runs to the end and returns NULL. Or, it is type pkcs7_signed, and since cont and icont are NULL, it also returns NULL. If I had run into an error, there would be additional items on the error stack. It appears that it needs to be a NID_pkcs7_signed, so it seems that returning with no content is what is happening. I try adding some data to sign, but I get the same error. Looking at test/cmsapitest.c, I think that probably cert only payload creation is simply not tested/implemented. Would I be wrong here? I haven't looked at "openssl cms" to see if it can be built that way. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From John.Unsworth at synchronoss.com Tue May 14 09:29:23 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Tue, 14 May 2019 09:29:23 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix Message-ID: Because of the #pragma weak directive the functions are defined multiple times in both libcrypto.a and libssl.a: libcrypto.a Many UNDEF: ct_log.o [47] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null ... and more One definition from stack.c as you'd expect: stack.o [33] | 1232| 20|FUNC |WEAK |2 |2 |OPENSSL_sk_new_null libssl.a has multiple instances also, all UNDEF: d1_srtp.o [43] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null s3_lib.o [107] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null and so on. >From the linker docs: B.2.17.1 #pragma weak name In the form #pragma weak name, the directive makes name a weak symbol. The linker will not complain if it does not find a symbol definition for name. It also does not complain about multiple weak definitions of the symbol. The linker simply takes the first one it encounters. So when linking with libcrypto.a and libssl.a the first definition is taken which is UNDEF in both cases leading to the error. This can be fixed in libcrypto.a by making stack.o, lh_stats.o and lhash.o the first files included. It could also be fixed by not defining those pragmas when compiling stack.c, lh_stats.c and lhash.c because they will then be GLOB instead of WEAK and will override all the WEAK definitions. However there is no suitable fix for libssl.a because those files are not part of that library. Doing that means that executables that link libcrypto.a before libssl.s are built correctly. However if the link is libssl.a followed by libcrypto.a the UNDEF symbols from libssl.a are still used. In the shared libraries I see: libcrypto.so only instance: [3537] | 2409672| 20|FUNC |LOCL |2 |10 |OPENSSL_sk_new_null Shared libssl.so also one instance: [2091] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null and it seems that the linker will resolve those correctly. So it seems to me that the only clean solution is to not define those pragmas when compiling stack.c, lh_stats.c and lhash.c by including a suitable define in the makefiles when building the libraries that is used in safestack.h and lhash.h to omit them. I see there is also # elif defined(__SUNPRO_C) #pragma weak getisax in crypto\sparcv9cap.c so maybe that needs consideration too. Regards, John. -----Original Message----- From: openssl-users On Behalf Of John Unsworth Sent: 10 May 2019 16:23 To: openssl-users at openssl.org Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution CAUTION: This email originated from outside of Synchronoss. This seems to be caused by the ongoing saga documented in issues 6912 and 8102. These functions were declared as weak in 1.1.1b. safestack.h # pragma weak OPENSSL_sk_num # pragma weak OPENSSL_sk_value # pragma weak OPENSSL_sk_new # pragma weak OPENSSL_sk_new_null ... lhash.h # pragma weak OPENSSL_LH_new # pragma weak OPENSSL_LH_free # pragma weak OPENSSL_LH_insert # pragma weak OPENSSL_LH_delete ... Removing these lines allows all the tests to work. I am building static libraries (no-shared) which is presumably why it works for some people out of the box if they are using shared libraries. Please advise as to the way forward. I note that one other user (see 8102) has reported this too: >>>>>>>>>>> rammishr commented on Mar 26 Hi, Sorry if this should have been posted separately. When i build openssl1.1.1b on solaris , it is successful. But while verifying the version " openssl version" it fails with below error. ld.so.1: openssl: fatal: relocation error: file /vobs_tools/prgs/src/openssl/solaris64/bin/openssl: symbol OPENSSL_sk_new_null: referenced symbol not found Killed The same machine works fine for openssl1.1.1. So, in 1.1.1b I can observe that OPENSSL_sk_new_null has been defined as below in safestack.h. pragma weak OPENSSL_sk_new_null Can this be related ? Am I missing anything while Configure ? <<<<<<<<<<<<<<< Regards, John. -----Original Message----- From: openssl-users On Behalf Of John Unsworth Sent: 09 May 2019 10:13 To: openssl-users at openssl.org Subject: RE: OpenSSL 1.1.1b tests fail on Solaris CAUTION: This email originated from outside of Synchronoss. This looks like the problem: ld.so.1: sanitytest: fatal: relocation error: file ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not ok 1 - running sanitytest # Failed test 'running sanitytest' # at /home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests This results in the same error: sol-mds-build-01 $ cd apps sol-mds-build-01 $ ./openssl version ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found I have built static libraries. John -----Original Message----- From: openssl-users On Behalf Of Matt Caswell Sent: 09 May 2019 09:38 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris CAUTION: This email originated from outside of Synchronoss. What is the output from: $ make V=1 TESTS=test_sanity test Matt On 08/05/2019 19:22, John Unsworth wrote: > I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 > Generic_Virtual sun4v sparc SUNW,T5140. > > > > ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 > -xldscope=hidden > > > > It builds fine but all the tests fail, with or without no-asm. Can > anyone help please? Here is the start of the test run: > > > > $ make test > > make depend && make _tests > > ( cd test; \ > > mkdir -p test-runs; \ > > SRCTOP=../. \ > > BLDTOP=../. \ > > RESULT_D=test-runs \ > > PERL="/opt/perl-5.26.1/bin/perl" \ > > EXE_EXT= \ > > OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ > > OPENSSL_DEBUG_MEMORY=on \ > > /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) > > ../test/recipes/01-test_abort.t .................... ok > > ../test/recipes/01-test_sanity.t ................... Dubious, test > returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > Regards, > > John. > From Michael.Wojcik at microfocus.com Tue May 14 14:48:07 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 14 May 2019 14:48:07 +0000 Subject: Crashes when generating certificate In-Reply-To: <1684f1ca-f04a-0f1a-9bd5-9490a4935805@denninger.net> References: <1684f1ca-f04a-0f1a-9bd5-9490a4935805@denninger.net> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Karl Denninger > Sent: Monday, May 13, 2019 16:32 > On 5/13/2019 16:44, Christopher R wrote: > > All I want is whatever remnants of that incorrect certificate removed, > > where ever they are, and a correct certificate created. > Not sure what you have left, but probably in the certs directory. I can't think of what remnant of the old certificate would be there, except the certificate itself, in whatever the configuration file specifies for the new_certs_dir. And I've never seen that cause this problem. > In the future REVOKE the one with the bad information, and you can then > create a new one under the same common name. Seconded. This is the right way to replace an incorrectly-generated certificate. Even if you're not providing revocation information to your users (not publishing a CRL, not running an OCSP server), use "openssl ca -revoke" to revoke the old certificate. There are any number of tutorials online. > Since the index file is a flat file you can edit it, but you also have > to make sure the other places it references are also updated or the > software can get confused. Editing the CA database is a Bad Idea, in my opinion. If you must, take a backup first. In fact, if you're not prepared to at any moment lose your CA information and have to recreate your CA from scratch, you should have all of those files backed up. I put them in change management, so that I can also diff and revert to an earlier version. (Of course if your CA is used for anything other than local testing you'll want to be careful with your key hygiene; don't let an attacker get the CA private key from a backup. Encrypting the key helps but then you're relying on the entropy in the key passphrase.) -- Michael Wojcik Distinguished Engineer, Micro Focus From karl at denninger.net Tue May 14 15:22:23 2019 From: karl at denninger.net (Karl Denninger) Date: Tue, 14 May 2019 10:22:23 -0500 Subject: Crashes when generating certificate In-Reply-To: References: <1684f1ca-f04a-0f1a-9bd5-9490a4935805@denninger.net> Message-ID: On 5/14/2019 09:48, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Karl Denninger >> Sent: Monday, May 13, 2019 16:32 >> On 5/13/2019 16:44, Christopher R wrote: >>> All I want is whatever remnants of that incorrect certificate removed, >>> where ever they are, and a correct certificate created. >> Not sure what you have left, but probably in the certs directory. > I can't think of what remnant of the old certificate would be there, except the certificate itself, in whatever the configuration file specifies for the new_certs_dir. And I've never seen that cause this problem. There's a directory (by default "newcerts" but can be changed in the config file) that has a copy of the certs that OpenSSL generates.? If there's a collision in there (which could happen if the serial number is reused) "bad things" could happen.? I've not looked at the code to see if that would cause a bomb-out but the risk with playing in the database file, although it's just a flat file, and/or the serial number index is that you can wind up with conflicts. The "ca" function in openssl lacks the sort of robustness and "don't do that" sort of protections that one would expect in a "production" setting.? That's not say it can't be used that way but quite a bit of care is required to do so successfully, and toying around in the database structure by hand is rather removed from that degree of care. -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: From mcr at sandelman.ca Tue May 14 16:39:16 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 14 May 2019 12:39:16 -0400 Subject: creating certificate only structure -- CMS_sign In-Reply-To: <3490.1557798428@localhost> References: <3490.1557798428@localhost> Message-ID: <11508.1557851956@localhost> {resending, because it did not seem to make it into the archives} https://www.openssl.org/docs/man1.1.0/man3/CMS_sign.html says: If signcert and pkey are NULL then a certificates only CMS structure is output. I am trying to create one to return in an RFC7030 (EST) /cacerts request. It appears that it needs to be a NID_pkcs7_signed. a) Do I need to set any flags? b) I assume that any certificates in the STACK_OF(X509) *certs will be included? c) Does it have to have CMS_PARTIAL or some other flags set, and then call CMS_final() explicitely? I am getting error:2E07F068:CMS routines:CMS_final:cms lib (I think I am dumping the entire error stack with: unsigned long err = ERR_get_error(); while(err != 0) { fprintf(stderr, "error: %s\n", ERR_error_string(err, NULL)); err = ERR_get_error(); } when called like: signcert: (nil) pkey: (nil) certs: 0x563df7fc1e30 bio: (nil), flg: 0 (via ruby, I haven't written a C-only example yet...) I am running with => "OpenSSL 1.1.1-dev xx XXX xxxx", which is really 1.1.1c with a patch to the DTLS code. Looking at CMS_dataInit(), it looks like if the contentType is not set, and icont is NULL, and no content was provided into the CMS structure, that it simply runs to the end and returns NULL. Or, it is type pkcs7_signed, and since cont and icont are NULL, it also returns NULL. If I had run into an error, there would be additional items on the error stack. It appears that it needs to be a NID_pkcs7_signed, so it seems that returning with no content is what is happening. I try adding some data to sign, but I get the same error. Looking at test/cmsapitest.c, I think that probably cert only payload creation is simply not tested/implemented. Would I be wrong here? I haven't looked at "openssl cms" to see if it can be built that way. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From Michael.Wojcik at microfocus.com Tue May 14 16:39:08 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 14 May 2019 16:39:08 +0000 Subject: Crashes when generating certificate In-Reply-To: References: <1684f1ca-f04a-0f1a-9bd5-9490a4935805@denninger.net> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Karl Denninger > Sent: Tuesday, May 14, 2019 09:22 > On 5/14/2019 09:48, Michael Wojcik wrote: > > I can't think of what remnant of the old certificate would be there, > > except the certificate itself, in whatever the configuration file > > specifies for the new_certs_dir. And I've never seen that cause this problem. > There's a directory (by default "newcerts" but can be changed in the config > file) that has a copy of the certs that OpenSSL generates. Yeah, that's the new_certs_dir that I referred to. (That's the name of the config file setting.) > If there's a collision in there (which could happen if the serial number is > reused) "bad things" could happen. Right, the filename is taken from the serial number. So if the ca app does something like an open(..., O_CREAT | O_EXCL), and that fails, it might quit. > I've not looked at the code to see if that would cause a bomb-out but the > risk with playing in the database file, although it's just a flat file, > and/or the serial number index is that you can wind up with conflicts. Agreed. Let's see... In 1.1.1b, the ca app does a BIO_new_file for the new certificate file, and if that returns null, it does a perror followed by a goto end. I don't know what version the OP is running, though, and that perror may be missing in older OpenSSL releases. (Why do people post questions without identifying their OpenSSL version, platform, and so on?) Interestingly, right before that the ca app does a bio_open_default on outfile, which is the argument of the -out option (if any) or null for the default (stdout, I think); and if *that* fails it does a goto end without a perror. So if OP's command line has a -out and that file can't be open for output, ca will exit silently. > The "ca" function in openssl lacks the sort of robustness and "don't do that" > sort of protections that one would expect in a "production" setting. That's not > say it can't be used that way but quite a bit of care is required to do so > successfully, and toying around in the database structure by hand is rather > removed from that degree of care. Oh, definitely. I wouldn't recommend using openssl ca for any sort of production use unless you're confident you understand how openssl ca works, how PKIX works, how production CAs are supposed to work, and any details particular to your use, such as CA/BF requirements if you want to generate certificates for HTTPS servers. And then you need a lot of infrastructure around the ca app, including at least partial automation for all the CA operations, a mechanism for key hygiene, backups, auditing, and so on. Unfortunately, the CA function isn't really suitable for a free turnkey implementation (too many variables, too many infrastructure requirements), but customers who don't already have some kind of organizational CA need some way to get started with TLS. For many years we've shipped a demonstration CA based on openssl ca plus some scripts with some of our products, and some customers insist on using it in production, despite our warnings against it. I'm not happy about it, but we haven't found a good alternative. -- Michael Wojcik Distinguished Engineer, Micro Focus From samiya.khanum at broadcom.com Wed May 15 11:54:37 2019 From: samiya.khanum at broadcom.com (Samiya Khanum) Date: Wed, 15 May 2019 17:24:37 +0530 Subject: Building openssh7.9p1 and above against openssl1.1.1b Message-ID: Hi, After upgrading openssl to 1.1.1b, I am getting compilation errors in the openssh code. Does Openssh 7.9p1 and above versions support building against the openssl 1.1.1b version? In Openssh release notes, below note is mentioned: All: support building against the openssl-1.1 API (releases 1.1.0g and later). The openssl-1.0 API will remain supported at least until OpenSSL terminates security patch support for that API version. Does this mean it is supported? Thanks & Regards, Samiya khanum -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Wed May 15 14:16:29 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 15 May 2019 14:16:29 +0000 Subject: AW: Building openssh7.9p1 and above against openssl1.1.1b In-Reply-To: References: Message-ID: <1957b0d0194440aa9157d2ab51a029c7@Ex13.ncp.local> If the compilation errors are in openssh, then it might be better to ask the openssh people. Also, posting the precise error messages by the compiler would be of great help. As for your citation below: It seems to state that building against version 1.1.0 and 1.1.1 is supported, while building against version 1.0.2 will be supported until it is end-of-life, which is by the end of this year. HTH, Matthias Von: openssl-users Im Auftrag von Samiya Khanum via openssl-users Gesendet: Mittwoch, 15. Mai 2019 04:55 An: openssl-users at openssl.org Betreff: Building openssh7.9p1 and above against openssl1.1.1b Hi, After upgrading openssl to 1.1.1b, I am getting compilation errors in the openssh code. Does Openssh 7.9p1 and above versions support building against the openssl 1.1.1b version? In Openssh release notes, below note is mentioned: All: support building against the openssl-1.1 API (releases 1.1.0g and later). The openssl-1.0 API will remain supported at least until OpenSSL terminates security patch support for that API version. Does this mean it is supported? Thanks & Regards, Samiya khanum -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed May 15 15:11:28 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 15 May 2019 17:11:28 +0200 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix In-Reply-To: References: Message-ID: <37aca63f-7f9e-a8b6-4fab-ed1385c2b814@wisemo.com> Alternative suggestion (from my understanding of the documentation quoted below): Issue #pragma weak for a symbol only in the files that define that symbol, not in the ones that merely reference it. The hoped effect would be: 1. Object files that merely reference a symbol will contain regular UNDEF ? entries 2. Object files that do define such a symbol will contain a WEAK defined ? entry 3. When seeing the UNDEF entries, the linker will look for an actual ? definition 4. If finding multiple WEAK defined entries, the linker will not complain, ? just use the first found. I suspect the specified linker semantics of not trying to satisfy "WEAK UNDEF" entries would be suitable for optional link-time selected callbacks or data where a referencing library do runtime tests to see if the library- using program has provided a definition or not.? For example, it could be used for a symbol holding a list of global C++ constructors/destructors with libc code invoking that list if present without requiring dummy lists in programs without. The .so case mentioned probably works "by chance" because libssl.so references non-weak libcrypto.so symbols, forcing the definition to be included in the runtime process anyway. On 14/05/2019 11:29, John Unsworth wrote: > Because of the #pragma weak directive the functions are defined multiple times in both libcrypto.a and libssl.a: > > libcrypto.a > > Many UNDEF: > ct_log.o > [47] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > ... and more > > One definition from stack.c as you'd expect: > stack.o > [33] | 1232| 20|FUNC |WEAK |2 |2 |OPENSSL_sk_new_null > > libssl.a has multiple instances also, all UNDEF: > d1_srtp.o > [43] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > s3_lib.o > [107] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > and so on. > > From the linker docs: > B.2.17.1 #pragma weak name > In the form #pragma weak name, the directive makes name a weak symbol. The linker will not complain if it does not find a symbol definition for name. It also does not complain about multiple weak definitions of the symbol. The linker simply takes the first one it encounters. > > So when linking with libcrypto.a and libssl.a the first definition is taken which is UNDEF in both cases leading to the error. > This can be fixed in libcrypto.a by making stack.o, lh_stats.o and lhash.o the first files included. It could also be fixed by not defining those pragmas when compiling stack.c, lh_stats.c and lhash.c because they will then be GLOB instead of WEAK and will override all the WEAK definitions. > > However there is no suitable fix for libssl.a because those files are not part of that library. > > Doing that means that executables that link libcrypto.a before libssl.s are built correctly. However if the link is libssl.a followed by libcrypto.a the UNDEF symbols from libssl.a are still used. > > In the shared libraries I see: > > libcrypto.so only instance: > [3537] | 2409672| 20|FUNC |LOCL |2 |10 |OPENSSL_sk_new_null > > Shared libssl.so also one instance: > [2091] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > > and it seems that the linker will resolve those correctly. > > So it seems to me that the only clean solution is to not define those pragmas when compiling stack.c, lh_stats.c and lhash.c by including a suitable define in the makefiles when building the libraries that is used in safestack.h and lhash.h to omit them. > > I see there is also > # elif defined(__SUNPRO_C) > #pragma weak getisax > in crypto\sparcv9cap.c > so maybe that needs consideration too. > > Regards, > John. > > -----Original Message----- > From: openssl-users On Behalf Of John Unsworth > Sent: 10 May 2019 16:23 > To: openssl-users at openssl.org > Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution > > CAUTION: This email originated from outside of Synchronoss. > > > This seems to be caused by the ongoing saga documented in issues 6912 and 8102. These functions were declared as weak in 1.1.1b. > > safestack.h > # pragma weak OPENSSL_sk_num > # pragma weak OPENSSL_sk_value > # pragma weak OPENSSL_sk_new > # pragma weak OPENSSL_sk_new_null > ... > > lhash.h > # pragma weak OPENSSL_LH_new > # pragma weak OPENSSL_LH_free > # pragma weak OPENSSL_LH_insert > # pragma weak OPENSSL_LH_delete > ... > > Removing these lines allows all the tests to work. I am building static libraries (no-shared) which is presumably why it works for some people out of the box if they are using shared libraries. > > Please advise as to the way forward. I note that one other user (see 8102) has reported this too: > > rammishr commented on Mar 26 > Hi, > Sorry if this should have been posted separately. > > When i build openssl1.1.1b on solaris , it is successful. But while verifying the version " openssl version" it fails with below error. > ld.so.1: openssl: fatal: relocation error: file /vobs_tools/prgs/src/openssl/solaris64/bin/openssl: symbol OPENSSL_sk_new_null: referenced symbol not found Killed > > The same machine works fine for openssl1.1.1. > So, in 1.1.1b I can observe that OPENSSL_sk_new_null has been defined as below in safestack.h. > pragma weak OPENSSL_sk_new_null > Can this be related ? Am I missing anything while Configure ? > <<<<<<<<<<<<<<< > > Regards, > John. > > -----Original Message----- > From: openssl-users On Behalf Of John Unsworth > Sent: 09 May 2019 10:13 > To: openssl-users at openssl.org > Subject: RE: OpenSSL 1.1.1b tests fail on Solaris > > CAUTION: This email originated from outside of Synchronoss. > > > This looks like the problem: > > ld.so.1: sanitytest: fatal: relocation error: file ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not ok 1 - running sanitytest > > # Failed test 'running sanitytest' > # at /home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm line 77. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests > > This results in the same error: > sol-mds-build-01 $ cd apps > sol-mds-build-01 $ ./openssl version > ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found > > I have built static libraries. > > John > > -----Original Message----- > From: openssl-users On Behalf Of Matt Caswell > Sent: 09 May 2019 09:38 > To: openssl-users at openssl.org > Subject: Re: OpenSSL 1.1.1b tests fail on Solaris > > CAUTION: This email originated from outside of Synchronoss. > > > What is the output from: > > $ make V=1 TESTS=test_sanity test > > Matt > > On 08/05/2019 19:22, John Unsworth wrote: >> I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 >> Generic_Virtual sun4v sparc SUNW,T5140. >> >> >> >> ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 >> -xldscope=hidden >> >> >> >> It builds fine but all the tests fail, with or without no-asm. Can >> anyone help please? Here is the start of the test run: >> >> >> >> $ make test >> >> make depend && make _tests >> >> ( cd test; \ >> >> mkdir -p test-runs; \ >> >> SRCTOP=../. \ >> >> BLDTOP=../. \ >> >> RESULT_D=test-runs \ >> >> PERL="/opt/perl-5.26.1/bin/perl" \ >> >> EXE_EXT= \ >> >> OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ >> >> OPENSSL_DEBUG_MEMORY=on \ >> >> /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) >> >> ../test/recipes/01-test_abort.t .................... ok >> >> ../test/recipes/01-test_sanity.t ................... Dubious, test >> returned 1 (wstat 256, 0x100) >> >> Failed 1/1 subtests >> 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 Wed May 15 15:29:48 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 15 May 2019 17:29:48 +0200 Subject: Crashes when generating certificate In-Reply-To: References: <1684f1ca-f04a-0f1a-9bd5-9490a4935805@denninger.net> Message-ID: <267d90d2-589a-2abf-df1c-f0ebba9c10e6@wisemo.com> On 14/05/2019 18:39, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Karl Denninger >> Sent: Tuesday, May 14, 2019 09:22 >> On 5/14/2019 09:48, Michael Wojcik wrote: >>> I can't think of what remnant of the old certificate would be there, >>> except the certificate itself, in whatever the configuration file >>> specifies for the new_certs_dir. And I've never seen that cause this problem. >> There's a directory (by default "newcerts" but can be changed in the config >> file) that has a copy of the certs that OpenSSL generates. > Yeah, that's the new_certs_dir that I referred to. (That's the name of the config > file setting.) > >> If there's a collision in there (which could happen if the serial number is >> reused) "bad things" could happen. > Right, the filename is taken from the serial number. So if the ca app does something > like an open(..., O_CREAT | O_EXCL), and that fails, it might quit. > >> I've not looked at the code to see if that would cause a bomb-out but the >> risk with playing in the database file, although it's just a flat file, >> and/or the serial number index is that you can wind up with conflicts. > Agreed. > > Let's see... In 1.1.1b, the ca app does a BIO_new_file for the new > certificate file, and if that returns null, it does a perror followed by a goto end. > > I don't know what version the OP is running, though, and that perror may be missing in older OpenSSL releases. (Why do people post questions without identifying their OpenSSL version, platform, and so on?) > > Interestingly, right before that the ca app does a bio_open_default on outfile, which is the argument of the -out option (if any) or null for the default (stdout, I think); and if *that* fails it does a goto end without a perror. So if OP's command line has a -out and that file can't be open for output, ca will exit silently. > >> The "ca" function in openssl lacks the sort of robustness and "don't do that" >> sort of protections that one would expect in a "production" setting. That's not >> say it can't be used that way but quite a bit of care is required to do so >> successfully, and toying around in the database structure by hand is rather >> removed from that degree of care. > Oh, definitely. I wouldn't recommend using openssl ca for any sort of production use unless you're confident you understand how openssl ca works, how PKIX works, how production CAs are supposed to work, and any details particular to your use, such as CA/BF requirements if you want to generate certificates for HTTPS servers. And then you need a lot of infrastructure around the ca app, including at least partial automation for all the CA operations, a mechanism for key hygiene, backups, auditing, and so on. > > Unfortunately, the CA function isn't really suitable for a free turnkey implementation (too many variables, too many infrastructure requirements), but customers who don't already have some kind of organizational CA need some way to get started with TLS. For many years we've shipped a demonstration CA based on openssl ca plus some scripts with some of our products, and some customers insist on using it in production, despite our warnings against it. I'm not happy about it, but we haven't found a good alternative. Despite its obvious shortcomings, I have yet to find another ca program suitable for offline use on a small command-line only machine. Everything I have found has been bloated GUI stuff with builtin web servers and other unwanted garbage. It would be nice if a good command-line offline CA product existed, but until then, disciplined use of the OpenSSL ca "sample" command seems to be the best there is. 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 sreekanth1m at gmail.com Wed May 15 16:55:03 2019 From: sreekanth1m at gmail.com (sreekanth1m) Date: Wed, 15 May 2019 09:55:03 -0700 (MST) Subject: fipsld ./fips_premain_dso: No such file or directory In-Reply-To: <1361818323449-43934.post@n7.nabble.com> References: <1360863009697-43733.post@n7.nabble.com> <20130221223750.GA26231@openssl.org> <1361818323449-43934.post@n7.nabble.com> Message-ID: <1557939303993-0.post@n7.nabble.com> @Roar, could you let me know where to add lpthread and bsymbolic to link statically as I am also facing the the same issue when making a FIPS library. Thanks -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From John.Unsworth at synchronoss.com Wed May 15 20:08:29 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Wed, 15 May 2019 20:08:29 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix In-Reply-To: References: <37aca63f-7f9e-a8b6-4fab-ed1385c2b814@wisemo.com>, Message-ID: >> Issue #pragma weak for a symbol only in the files that define that symbol, not in the ones that merely reference it. The problem is that those pragmas are in .h files. They contain inline functions that use those symbols. The pragmas were added because of problems with apps that used the .h files (hard to avoid since they are basic crypto header files) but did not link with libcrypto.so. That library was explicitly loaded by the app, but the app would not start because of the missing symbols. See issues 6912 and 8102. Regards, John. John Unsworth |Meta-Directory Engineering and Support Mobile: +44 777.557.2643 -----Original Message----- From: openssl-users On Behalf Of Jakob Bohm via openssl-users Sent: 15 May 2019 16:11 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix CAUTION: This email originated from outside of Synchronoss. Alternative suggestion (from my understanding of the documentation quoted below): Issue #pragma weak for a symbol only in the files that define that symbol, not in the ones that merely reference it. The hoped effect would be: 1. Object files that merely reference a symbol will contain regular UNDEF entries 2. Object files that do define such a symbol will contain a WEAK defined entry 3. When seeing the UNDEF entries, the linker will look for an actual definition 4. If finding multiple WEAK defined entries, the linker will not complain, just use the first found. I suspect the specified linker semantics of not trying to satisfy "WEAK UNDEF" entries would be suitable for optional link-time selected callbacks or data where a referencing library do runtime tests to see if the library- using program has provided a definition or not. For example, it could be used for a symbol holding a list of global C++ constructors/destructors with libc code invoking that list if present without requiring dummy lists in programs without. The .so case mentioned probably works "by chance" because libssl.so references non-weak libcrypto.so symbols, forcing the definition to be included in the runtime process anyway. On 14/05/2019 11:29, John Unsworth wrote: > Because of the #pragma weak directive the functions are defined multiple times in both libcrypto.a and libssl.a: > > libcrypto.a > > Many UNDEF: > ct_log.o > [47] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > ... and more > > One definition from stack.c as you'd expect: > stack.o > [33] | 1232| 20|FUNC |WEAK |2 |2 |OPENSSL_sk_new_null > > libssl.a has multiple instances also, all UNDEF: > d1_srtp.o > [43] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > s3_lib.o > [107] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > and so on. > > From the linker docs: > B.2.17.1 #pragma weak name > In the form #pragma weak name, the directive makes name a weak symbol. The linker will not complain if it does not find a symbol definition for name. It also does not complain about multiple weak definitions of the symbol. The linker simply takes the first one it encounters. > > So when linking with libcrypto.a and libssl.a the first definition is taken which is UNDEF in both cases leading to the error. > This can be fixed in libcrypto.a by making stack.o, lh_stats.o and lhash.o the first files included. It could also be fixed by not defining those pragmas when compiling stack.c, lh_stats.c and lhash.c because they will then be GLOB instead of WEAK and will override all the WEAK definitions. > > However there is no suitable fix for libssl.a because those files are not part of that library. > > Doing that means that executables that link libcrypto.a before libssl.s are built correctly. However if the link is libssl.a followed by libcrypto.a the UNDEF symbols from libssl.a are still used. > > In the shared libraries I see: > > libcrypto.so only instance: > [3537] | 2409672| 20|FUNC |LOCL |2 |10 |OPENSSL_sk_new_null > > Shared libssl.so also one instance: > [2091] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > > and it seems that the linker will resolve those correctly. > > So it seems to me that the only clean solution is to not define those pragmas when compiling stack.c, lh_stats.c and lhash.c by including a suitable define in the makefiles when building the libraries that is used in safestack.h and lhash.h to omit them. > > I see there is also > # elif defined(__SUNPRO_C) > #pragma weak getisax > in crypto\sparcv9cap.c > so maybe that needs consideration too. > > Regards, > John. > > -----Original Message----- > From: openssl-users On Behalf Of > John Unsworth > Sent: 10 May 2019 16:23 > To: openssl-users at openssl.org > Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution > > CAUTION: This email originated from outside of Synchronoss. > > > This seems to be caused by the ongoing saga documented in issues 6912 and 8102. These functions were declared as weak in 1.1.1b. > > safestack.h > # pragma weak OPENSSL_sk_num > # pragma weak OPENSSL_sk_value > # pragma weak OPENSSL_sk_new > # pragma weak OPENSSL_sk_new_null > ... > > lhash.h > # pragma weak OPENSSL_LH_new > # pragma weak OPENSSL_LH_free > # pragma weak OPENSSL_LH_insert > # pragma weak OPENSSL_LH_delete > ... > > Removing these lines allows all the tests to work. I am building static libraries (no-shared) which is presumably why it works for some people out of the box if they are using shared libraries. > > Please advise as to the way forward. I note that one other user (see 8102) has reported this too: > > rammishr commented on Mar 26 > Hi, > Sorry if this should have been posted separately. > > When i build openssl1.1.1b on solaris , it is successful. But while verifying the version " openssl version" it fails with below error. > ld.so.1: openssl: fatal: relocation error: file > /vobs_tools/prgs/src/openssl/solaris64/bin/openssl: symbol > OPENSSL_sk_new_null: referenced symbol not found Killed > > The same machine works fine for openssl1.1.1. > So, in 1.1.1b I can observe that OPENSSL_sk_new_null has been defined as below in safestack.h. > pragma weak OPENSSL_sk_new_null > Can this be related ? Am I missing anything while Configure ? > <<<<<<<<<<<<<<< > > Regards, > John. > > -----Original Message----- > From: openssl-users On Behalf Of > John Unsworth > Sent: 09 May 2019 10:13 > To: openssl-users at openssl.org > Subject: RE: OpenSSL 1.1.1b tests fail on Solaris > > CAUTION: This email originated from outside of Synchronoss. > > > This looks like the problem: > > ld.so.1: sanitytest: fatal: relocation error: file > ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol > not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not ok > 1 - running sanitytest > > # Failed test 'running sanitytest' > # at /home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm line 77. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests > > This results in the same error: > sol-mds-build-01 $ cd apps > sol-mds-build-01 $ ./openssl version > ld.so.1: openssl: fatal: relocation error: file openssl: symbol > OPENSSL_sk_new_null: referenced symbol not found > > I have built static libraries. > > John > > -----Original Message----- > From: openssl-users On Behalf Of > Matt Caswell > Sent: 09 May 2019 09:38 > To: openssl-users at openssl.org > Subject: Re: OpenSSL 1.1.1b tests fail on Solaris > > CAUTION: This email originated from outside of Synchronoss. > > > What is the output from: > > $ make V=1 TESTS=test_sanity test > > Matt > > On 08/05/2019 19:22, John Unsworth wrote: >> I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 >> Generic_Virtual sun4v sparc SUNW,T5140. >> >> >> >> ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 >> -xldscope=hidden >> >> >> >> It builds fine but all the tests fail, with or without no-asm. Can >> anyone help please? Here is the start of the test run: >> >> >> >> $ make test >> >> make depend && make _tests >> >> ( cd test; \ >> >> mkdir -p test-runs; \ >> >> SRCTOP=../. \ >> >> BLDTOP=../. \ >> >> RESULT_D=test-runs \ >> >> PERL="/opt/perl-5.26.1/bin/perl" \ >> >> EXE_EXT= \ >> >> OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ >> >> OPENSSL_DEBUG_MEMORY=on \ >> >> /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) >> >> ../test/recipes/01-test_abort.t .................... ok >> >> ../test/recipes/01-test_sanity.t ................... Dubious, test >> returned 1 (wstat 256, 0x100) >> >> Failed 1/1 subtests >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michal.Trojnara at stunnel.org Wed May 15 20:53:53 2019 From: Michal.Trojnara at stunnel.org (Michal Trojnara) Date: Wed, 15 May 2019 22:53:53 +0200 Subject: stunnel 5.54 released Message-ID: Dear Users, I have released version 5.54 of stunnel. Version 5.54, 2019.05.15, urgency: LOW * New features ? - New "ticketKeySecret" and "ticketMacSecret" options ??? to control confidentiality and integrity protection ??? of the issued session tickets.? These options allow ??? for session resumption on other nodes in a cluster. ? - Added logging the list of active connections on ??? SIGUSR2 or with Windows GUI. ? - Logging of the assigned bind address instead of the ??? requested bind address. * Bugfixes ? - Service threads are terminated before OpenSSL cleanup ??? to prevent occasional stunnel crashes at shutdown. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 5e8588a6c274b46b1d63e1b50f0725f4908dec736f6588eb48d1eb3d20c87902? stunnel-5.54.tar.gz ed8424731f7d6e0c9b11f4c7b597a072e558dae7979102d0b213759678079481? stunnel-5.54-win64-installer.exe 7659f605065e5155577a99abe1129dbc89523796196c8bf50d3fa9265ec34d93? stunnel-5.54-android.zip Best regards, ??? Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sreekanth1m at gmail.com Wed May 15 21:56:19 2019 From: sreekanth1m at gmail.com (sreekanth1m) Date: Wed, 15 May 2019 14:56:19 -0700 (MST) Subject: Build the FIPS Object Module issue on Ubuntu 18.04 In-Reply-To: References: Message-ID: <1557957379737-0.post@n7.nabble.com> I was able to generate FIPS Object Module - fipscanister.o fipscanister.o.sha1 fips_premain.c fips_premain.c.sha1 successfully but now struck in generating Build the FIPS capable library. followed below steps: $ . ./setenv-android.sh $ cd openssl-1.0.1e/ Next, fix the makefile and run configure. $ perl -pi -e 's/install: all install_docs install_sw/install: install_docs install_sw/g' Makefile.org $ ./config fips shared no-ssl2 no-ssl3 no-comp no-hw no-engine --openssldir=/usr/local/ssl/android-14/ \ --with-fipsdir=/usr/local/ssl/android-14/ --with-fipslibdir=/usr/local/ssl/android-14/lib/ Then run make depend and make all: $ make depend $ make all make all is resulting in failure with below error message: /usr/local/ssl/android-22/bin/fipsld: ./fips_premain_dso: not found Makefile.shared: 169: recipe for target 'link_a.gnu' failed. please let me know what I am missing. Thanks -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From paul.dale at oracle.com Thu May 16 00:11:15 2019 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 15 May 2019 17:11:15 -0700 (PDT) Subject: Build the FIPS Object Module issue on Ubuntu 18.04 In-Reply-To: <1557957379737-0.post@n7.nabble.com> References: <1557957379737-0.post@n7.nabble.com> Message-ID: <233ca6dc-8973-487c-bcef-17d1695b7dbc@default> Just noting that any module built in this manner is *not* FIPS compliant. The distribution must be unmodified and build exactly as per the documentation. Any change to the files or the build process renders the result invalid from a FIPS perspective. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: sreekanth1m [mailto:sreekanth1m at gmail.com] Sent: Thursday, 16 May 2019 7:56 AM To: openssl-users at openssl.org Subject: Re: Build the FIPS Object Module issue on Ubuntu 18.04 I was able to generate FIPS Object Module - fipscanister.o fipscanister.o.sha1 fips_premain.c fips_premain.c.sha1 successfully but now struck in generating Build the FIPS capable library. followed below steps: $ . ./setenv-android.sh $ cd openssl-1.0.1e/ Next, fix the makefile and run configure. $ perl -pi -e 's/install: all install_docs install_sw/install: install_docs install_sw/g' Makefile.org $ ./config fips shared no-ssl2 no-ssl3 no-comp no-hw no-engine --openssldir=/usr/local/ssl/android-14/ \ --with-fipsdir=/usr/local/ssl/android-14/ --with-fipslibdir=/usr/local/ssl/android-14/lib/ Then run make depend and make all: $ make depend $ make all make all is resulting in failure with below error message: /usr/local/ssl/android-22/bin/fipsld: ./fips_premain_dso: not found Makefile.shared: 169: recipe for target 'link_a.gnu' failed. please let me know what I am missing. Thanks -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From jb-openssl at wisemo.com Thu May 16 08:21:15 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 16 May 2019 10:21:15 +0200 Subject: Build the FIPS Object Module issue on Ubuntu 18.04 In-Reply-To: <233ca6dc-8973-487c-bcef-17d1695b7dbc@default> References: <1557957379737-0.post@n7.nabble.com> <233ca6dc-8973-487c-bcef-17d1695b7dbc@default> Message-ID: On 16/05/2019 02:11, Paul Dale wrote: > Just noting that any module built in this manner is *not* FIPS compliant. > > The distribution must be unmodified and build exactly as per the documentation. Any change to the files or the build process renders the result invalid from a FIPS perspective. > Only deviations from the official process in creating the fipscanister invalidates the FIPS validation. The FIPS-capable OpenSSL is "outside the boundary" of the FIPS module and can be changed at will.? This is why a new FIPS validation is not needed every time OpenSSL releases a bugfix to OpenSSL 1.0.x .? 1.1.x will not have FIPS support, and 4.y.x may lack this agility. 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 shivakumar2696 at gmail.com Thu May 16 10:29:32 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Thu, 16 May 2019 15:59:32 +0530 Subject: FIPS module for OpenSSL 1.1.1x Message-ID: Hi, I wanted to move from OpenSSL 1.0.2r to 1.1.1b. I have some doubts they are 1) If I upgrade to 1.1.1b will it cause any problem to other applications? which uses openssl for communications. ( say apache http server ). 2) can I expect FIPS module for 1.1.1b as well ? 3) since OpenSSL 1.1.1b doesn't have FIPS will this affect any other application ? Thanks and regards Shivakumar S -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at synchronoss.com Thu May 16 10:46:49 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 16 May 2019 10:46:49 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix In-Reply-To: References: <37aca63f-7f9e-a8b6-4fab-ed1385c2b814@wisemo.com>, Message-ID: In the absence of any steer from openssl gurus we will proceed by removing the #pragmas in safestack.h and lhash.h while we build the no-shared libraries on solaris. Hopefully someone will come up with a proper fix at some point. Regards, John From: openssl-users On Behalf Of John Unsworth Sent: 15 May 2019 21:08 To: openssl-users at openssl.org Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix >> Issue #pragma weak for a symbol only in the files that define that symbol, not in the ones that merely reference it. The problem is that those pragmas are in .h files. They contain inline functions that use those symbols. The pragmas were added because of problems with apps that used the .h files (hard to avoid since they are basic crypto header files) but did not link with libcrypto.so. That library was explicitly loaded by the app, but the app would not start because of the missing symbols. See issues 6912 and 8102. Regards, John. -----Original Message----- From: openssl-users On Behalf Of Jakob Bohm via openssl-users Sent: 15 May 2019 16:11 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix Alternative suggestion (from my understanding of the documentation quoted below): Issue #pragma weak for a symbol only in the files that define that symbol, not in the ones that merely reference it. The hoped effect would be: 1. Object files that merely reference a symbol will contain regular UNDEF entries 2. Object files that do define such a symbol will contain a WEAK defined entry 3. When seeing the UNDEF entries, the linker will look for an actual definition 4. If finding multiple WEAK defined entries, the linker will not complain, just use the first found. I suspect the specified linker semantics of not trying to satisfy "WEAK UNDEF" entries would be suitable for optional link-time selected callbacks or data where a referencing library do runtime tests to see if the library- using program has provided a definition or not. For example, it could be used for a symbol holding a list of global C++ constructors/destructors with libc code invoking that list if present without requiring dummy lists in programs without. The .so case mentioned probably works "by chance" because libssl.so references non-weak libcrypto.so symbols, forcing the definition to be included in the runtime process anyway. On 14/05/2019 11:29, John Unsworth wrote: > Because of the #pragma weak directive the functions are defined multiple times in both libcrypto.a and libssl.a: > > libcrypto.a > > Many UNDEF: > ct_log.o > [47] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > ... and more > > One definition from stack.c as you'd expect: > stack.o > [33] | 1232| 20|FUNC |WEAK |2 |2 |OPENSSL_sk_new_null > > libssl.a has multiple instances also, all UNDEF: > d1_srtp.o > [43] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > s3_lib.o > [107] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > and so on. > > From the linker docs: > B.2.17.1 #pragma weak name > In the form #pragma weak name, the directive makes name a weak symbol. The linker will not complain if it does not find a symbol definition for name. It also does not complain about multiple weak definitions of the symbol. The linker simply takes the first one it encounters. > > So when linking with libcrypto.a and libssl.a the first definition is taken which is UNDEF in both cases leading to the error. > This can be fixed in libcrypto.a by making stack.o, lh_stats.o and lhash.o the first files included. It could also be fixed by not defining those pragmas when compiling stack.c, lh_stats.c and lhash.c because they will then be GLOB instead of WEAK and will override all the WEAK definitions. > > However there is no suitable fix for libssl.a because those files are not part of that library. > > Doing that means that executables that link libcrypto.a before libssl.s are built correctly. However if the link is libssl.a followed by libcrypto.a the UNDEF symbols from libssl.a are still used. > > In the shared libraries I see: > > libcrypto.so only instance: > [3537] | 2409672| 20|FUNC |LOCL |2 |10 |OPENSSL_sk_new_null > > Shared libssl.so also one instance: > [2091] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > > and it seems that the linker will resolve those correctly. > > So it seems to me that the only clean solution is to not define those pragmas when compiling stack.c, lh_stats.c and lhash.c by including a suitable define in the makefiles when building the libraries that is used in safestack.h and lhash.h to omit them. > > I see there is also > # elif defined(__SUNPRO_C) > #pragma weak getisax > in crypto\sparcv9cap.c > so maybe that needs consideration too. > > Regards, > John. > > -----Original Message----- > From: openssl-users On Behalf Of > John Unsworth > Sent: 10 May 2019 16:23 > To: openssl-users at openssl.org > Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution > > This seems to be caused by the ongoing saga documented in issues 6912 and 8102. These functions were declared as weak in 1.1.1b. > > safestack.h > # pragma weak OPENSSL_sk_num > # pragma weak OPENSSL_sk_value > # pragma weak OPENSSL_sk_new > # pragma weak OPENSSL_sk_new_null > ... > > lhash.h > # pragma weak OPENSSL_LH_new > # pragma weak OPENSSL_LH_free > # pragma weak OPENSSL_LH_insert > # pragma weak OPENSSL_LH_delete > ... > > Removing these lines allows all the tests to work. I am building static libraries (no-shared) which is presumably why it works for some people out of the box if they are using shared libraries. > > Please advise as to the way forward. I note that one other user (see 8102) has reported this too: > > rammishr commented on Mar 26 > Hi, > Sorry if this should have been posted separately. > > When i build openssl1.1.1b on solaris , it is successful. But while verifying the version " openssl version" it fails with below error. > ld.so.1: openssl: fatal: relocation error: file > /vobs_tools/prgs/src/openssl/solaris64/bin/openssl: symbol > OPENSSL_sk_new_null: referenced symbol not found Killed > > The same machine works fine for openssl1.1.1. > So, in 1.1.1b I can observe that OPENSSL_sk_new_null has been defined as below in safestack.h. > pragma weak OPENSSL_sk_new_null > Can this be related ? Am I missing anything while Configure ? > <<<<<<<<<<<<<<< > > Regards, > John. > > -----Original Message----- > From: openssl-users On Behalf Of > John Unsworth > Sent: 09 May 2019 10:13 > To: openssl-users at openssl.org > Subject: RE: OpenSSL 1.1.1b tests fail on Solaris > > This looks like the problem: > > ld.so.1: sanitytest: fatal: relocation error: file > ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol > not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not ok > 1 - running sanitytest > > # Failed test 'running sanitytest' > # at /home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm line 77. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests > > This results in the same error: > sol-mds-build-01 $ cd apps > sol-mds-build-01 $ ./openssl version > ld.so.1: openssl: fatal: relocation error: file openssl: symbol > OPENSSL_sk_new_null: referenced symbol not found > > I have built static libraries. > > John > > -----Original Message----- > From: openssl-users On Behalf Of > Matt Caswell > Sent: 09 May 2019 09:38 > To: openssl-users at openssl.org > Subject: Re: OpenSSL 1.1.1b tests fail on Solaris > > What is the output from: > > $ make V=1 TESTS=test_sanity test > > Matt > > On 08/05/2019 19:22, John Unsworth wrote: >> I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 >> Generic_Virtual sun4v sparc SUNW,T5140. >> >> >> >> ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 >> -xldscope=hidden >> >> >> >> It builds fine but all the tests fail, with or without no-asm. Can >> anyone help please? Here is the start of the test run: >> >> >> >> $ make test >> >> make depend && make _tests >> >> ( cd test; \ >> >> mkdir -p test-runs; \ >> >> SRCTOP=../. \ >> >> BLDTOP=../. \ >> >> RESULT_D=test-runs \ >> >> PERL="/opt/perl-5.26.1/bin/perl" \ >> >> EXE_EXT= \ >> >> OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ >> >> OPENSSL_DEBUG_MEMORY=on \ >> >> /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) >> >> ../test/recipes/01-test_abort.t .................... ok >> >> ../test/recipes/01-test_sanity.t ................... Dubious, test >> returned 1 (wstat 256, 0x100) >> >> Failed 1/1 subtests >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ludwig.mark at siemens.com Thu May 16 11:32:26 2019 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Thu, 16 May 2019 11:32:26 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix In-Reply-To: References: <37aca63f-7f9e-a8b6-4fab-ed1385c2b814@wisemo.com>, Message-ID: Thanks, from someone else who builds no-shared and will need this mod. From: openssl-users On Behalf Of John Unsworth Sent: Thursday, May 16, 2019 5:47 AM To: openssl-users at openssl.org Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix In the absence of any steer from openssl gurus we will proceed by removing the #pragmas in safestack.h and lhash.h while we build the no-shared libraries on solaris. Hopefully someone will come up with a proper fix at some point. Regards, John From: openssl-users > On Behalf Of John Unsworth Sent: 15 May 2019 21:08 To: openssl-users at openssl.org Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix >> Issue #pragma weak for a symbol only in the files that define that symbol, not in the ones that merely reference it. The problem is that those pragmas are in .h files. They contain inline functions that use those symbols. The pragmas were added because of problems with apps that used the .h files (hard to avoid since they are basic crypto header files) but did not link with libcrypto.so. That library was explicitly loaded by the app, but the app would not start because of the missing symbols. See issues 6912 and 8102. Regards, John. -----Original Message----- From: openssl-users > On Behalf Of Jakob Bohm via openssl-users Sent: 15 May 2019 16:11 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix Alternative suggestion (from my understanding of the documentation quoted below): Issue #pragma weak for a symbol only in the files that define that symbol, not in the ones that merely reference it. The hoped effect would be: 1. Object files that merely reference a symbol will contain regular UNDEF entries 2. Object files that do define such a symbol will contain a WEAK defined entry 3. When seeing the UNDEF entries, the linker will look for an actual definition 4. If finding multiple WEAK defined entries, the linker will not complain, just use the first found. I suspect the specified linker semantics of not trying to satisfy "WEAK UNDEF" entries would be suitable for optional link-time selected callbacks or data where a referencing library do runtime tests to see if the library- using program has provided a definition or not. For example, it could be used for a symbol holding a list of global C++ constructors/destructors with libc code invoking that list if present without requiring dummy lists in programs without. The .so case mentioned probably works "by chance" because libssl.so references non-weak libcrypto.so symbols, forcing the definition to be included in the runtime process anyway. On 14/05/2019 11:29, John Unsworth wrote: > Because of the #pragma weak directive the functions are defined multiple times in both libcrypto.a and libssl.a: > > libcrypto.a > > Many UNDEF: > ct_log.o > [47] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > ... and more > > One definition from stack.c as you'd expect: > stack.o > [33] | 1232| 20|FUNC |WEAK |2 |2 |OPENSSL_sk_new_null > > libssl.a has multiple instances also, all UNDEF: > d1_srtp.o > [43] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > s3_lib.o > [107] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > and so on. > > From the linker docs: > B.2.17.1 #pragma weak name > In the form #pragma weak name, the directive makes name a weak symbol. The linker will not complain if it does not find a symbol definition for name. It also does not complain about multiple weak definitions of the symbol. The linker simply takes the first one it encounters. > > So when linking with libcrypto.a and libssl.a the first definition is taken which is UNDEF in both cases leading to the error. > This can be fixed in libcrypto.a by making stack.o, lh_stats.o and lhash.o the first files included. It could also be fixed by not defining those pragmas when compiling stack.c, lh_stats.c and lhash.c because they will then be GLOB instead of WEAK and will override all the WEAK definitions. > > However there is no suitable fix for libssl.a because those files are not part of that library. > > Doing that means that executables that link libcrypto.a before libssl.s are built correctly. However if the link is libssl.a followed by libcrypto.a the UNDEF symbols from libssl.a are still used. > > In the shared libraries I see: > > libcrypto.so only instance: > [3537] | 2409672| 20|FUNC |LOCL |2 |10 |OPENSSL_sk_new_null > > Shared libssl.so also one instance: > [2091] | 0| 0|FUNC |WEAK |0 |UNDEF |OPENSSL_sk_new_null > > and it seems that the linker will resolve those correctly. > > So it seems to me that the only clean solution is to not define those pragmas when compiling stack.c, lh_stats.c and lhash.c by including a suitable define in the makefiles when building the libraries that is used in safestack.h and lhash.h to omit them. > > I see there is also > # elif defined(__SUNPRO_C) > #pragma weak getisax > in crypto\sparcv9cap.c > so maybe that needs consideration too. > > Regards, > John. > > -----Original Message----- > From: openssl-users > On Behalf Of > John Unsworth > Sent: 10 May 2019 16:23 > To: openssl-users at openssl.org > Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution > > This seems to be caused by the ongoing saga documented in issues 6912 and 8102. These functions were declared as weak in 1.1.1b. > > safestack.h > # pragma weak OPENSSL_sk_num > # pragma weak OPENSSL_sk_value > # pragma weak OPENSSL_sk_new > # pragma weak OPENSSL_sk_new_null > ... > > lhash.h > # pragma weak OPENSSL_LH_new > # pragma weak OPENSSL_LH_free > # pragma weak OPENSSL_LH_insert > # pragma weak OPENSSL_LH_delete > ... > > Removing these lines allows all the tests to work. I am building static libraries (no-shared) which is presumably why it works for some people out of the box if they are using shared libraries. > > Please advise as to the way forward. I note that one other user (see 8102) has reported this too: > > rammishr commented on Mar 26 > Hi, > Sorry if this should have been posted separately. > > When i build openssl1.1.1b on solaris , it is successful. But while verifying the version " openssl version" it fails with below error. > ld.so.1: openssl: fatal: relocation error: file > /vobs_tools/prgs/src/openssl/solaris64/bin/openssl: symbol > OPENSSL_sk_new_null: referenced symbol not found Killed > > The same machine works fine for openssl1.1.1. > So, in 1.1.1b I can observe that OPENSSL_sk_new_null has been defined as below in safestack.h. > pragma weak OPENSSL_sk_new_null > Can this be related ? Am I missing anything while Configure ? > <<<<<<<<<<<<<<< > > Regards, > John. > > -----Original Message----- > From: openssl-users > On Behalf Of > John Unsworth > Sent: 09 May 2019 10:13 > To: openssl-users at openssl.org > Subject: RE: OpenSSL 1.1.1b tests fail on Solaris > > This looks like the problem: > > ld.so.1: sanitytest: fatal: relocation error: file > ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol > not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not ok > 1 - running sanitytest > > # Failed test 'running sanitytest' > # at /home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm line 77. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests > > This results in the same error: > sol-mds-build-01 $ cd apps > sol-mds-build-01 $ ./openssl version > ld.so.1: openssl: fatal: relocation error: file openssl: symbol > OPENSSL_sk_new_null: referenced symbol not found > > I have built static libraries. > > John > > -----Original Message----- > From: openssl-users > On Behalf Of > Matt Caswell > Sent: 09 May 2019 09:38 > To: openssl-users at openssl.org > Subject: Re: OpenSSL 1.1.1b tests fail on Solaris > > What is the output from: > > $ make V=1 TESTS=test_sanity test > > Matt > > On 08/05/2019 19:22, John Unsworth wrote: >> I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 >> Generic_Virtual sun4v sparc SUNW,T5140. >> >> >> >> ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 >> -xldscope=hidden >> >> >> >> It builds fine but all the tests fail, with or without no-asm. Can >> anyone help please? Here is the start of the test run: >> >> >> >> $ make test >> >> make depend && make _tests >> >> ( cd test; \ >> >> mkdir -p test-runs; \ >> >> SRCTOP=../. \ >> >> BLDTOP=../. \ >> >> RESULT_D=test-runs \ >> >> PERL="/opt/perl-5.26.1/bin/perl" \ >> >> EXE_EXT= \ >> >> OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ >> >> OPENSSL_DEBUG_MEMORY=on \ >> >> /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) >> >> ../test/recipes/01-test_abort.t .................... ok >> >> ../test/recipes/01-test_sanity.t ................... Dubious, test >> returned 1 (wstat 256, 0x100) >> >> Failed 1/1 subtests >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Thu May 16 14:50:23 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 16 May 2019 10:50:23 -0400 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix In-Reply-To: References: <37aca63f-7f9e-a8b6-4fab-ed1385c2b814@wisemo.com> Message-ID: On 5/16/19 6:46 AM, John Unsworth wrote: > In the absence of any steer from openssl gurus we will proceed by > removing the #pragmas in safestack.h and lhash.h while we build the > no-shared libraries on solaris. Hopefully someone will come up with a > proper fix at some point. This seems awefully familiar to me. I know that I have hit this sort of thing before and did not need to hack source files. Fairly certain of it but memory being what it is who knows. Is this on sparc? With the Oracle Studio compilers? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From John.Unsworth at synchronoss.com Thu May 16 14:55:13 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 16 May 2019 14:55:13 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix In-Reply-To: References: <37aca63f-7f9e-a8b6-4fab-ed1385c2b814@wisemo.com> Message-ID: This is sparc 10, building no-shared, oracle studio 12.4. Building shared works fine. The change was introduced in 1.1.1b. -----Original Message----- From: openssl-users On Behalf Of Dennis Clarke Sent: 16 May 2019 15:50 To: openssl-users at openssl.org Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix On 5/16/19 6:46 AM, John Unsworth wrote: > In the absence of any steer from openssl gurus we will proceed by > removing the #pragmas in safestack.h and lhash.h while we build the > no-shared libraries on solaris. Hopefully someone will come up with a > proper fix at some point. This seems awefully familiar to me. I know that I have hit this sort of thing before and did not need to hack source files. Fairly certain of it but memory being what it is who knows. Is this on sparc? With the Oracle Studio compilers? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From dclarke at blastwave.org Thu May 16 15:28:28 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 16 May 2019 11:28:28 -0400 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix In-Reply-To: References: <37aca63f-7f9e-a8b6-4fab-ed1385c2b814@wisemo.com> Message-ID: On 5/16/19 10:55 AM, John Unsworth wrote: > This is sparc 10, building no-shared, oracle studio 12.4. Building shared works fine. The change was introduced in 1.1.1b. > OKay, Solaris 10 and for some reason you are using Studio 12.4? Fair enough. I will take a glance. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From levitte at openssl.org Thu May 16 16:06:24 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 16 May 2019 09:06:24 -0700 Subject: Fwd: RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix In-Reply-To: <7A7E8D5A-D4A8-49D1-BA8D-9F8BA18D1934@openssl.org> References: <7A7E8D5A-D4A8-49D1-BA8D-9F8BA18D1934@openssl.org> Message-ID: <80AF1E7D-6561-4D15-A0FE-FC2B8CED9D85@openssl.org> And now, to openssl-users. Oops... -------- Originalmeddelande -------- Fr?n: Richard Levitte Skickat: 16 maj 2019 08:34:06 GMT-07:00 Till: John Unsworth ?mne: RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix The actual problem is the call of DEFINE macros in safestack.h. They should not be there. The only reason those lines haven't been removed us that we fear someone might have use of them. I plan to submit a PR for 3.0 that does remove those lines. Cheers Richard John Unsworth skrev: (16 maj 2019 03:46:49 GMT-07:00) >In the absence of any steer from openssl gurus we will proceed by >removing the #pragmas in safestack.h and lhash.h while we build the >no-shared libraries on solaris. Hopefully someone will come up with a >proper fix at some point. > >Regards, >John > >From: openssl-users On Behalf Of >John Unsworth >Sent: 15 May 2019 21:08 >To: openssl-users at openssl.org >Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible >fix > >>> Issue #pragma weak for a symbol only in the files that define that >symbol, not in the ones that merely reference it. >The problem is that those pragmas are in .h files. They contain inline >functions that use those symbols. The pragmas were added because of >problems with apps that used the .h files (hard to avoid since they are >basic crypto header files) but did not link with libcrypto.so. That >library was explicitly loaded by the app, but the app would not start >because of the missing symbols. > >See issues 6912 and 8102. > >Regards, >John. > >-----Original Message----- >From: openssl-users On Behalf Of >Jakob Bohm via openssl-users >Sent: 15 May 2019 16:11 >To: openssl-users at openssl.org >Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution and >possible fix > >Alternative suggestion (from my understanding of the documentation >quoted >below): > >Issue #pragma weak for a symbol only in the files that define that >symbol, not in the ones that merely reference it. > >The hoped effect would be: > >1. Object files that merely reference a symbol will contain regular >UNDEF > entries >2. Object files that do define such a symbol will contain a WEAK >defined > entry >3. When seeing the UNDEF entries, the linker will look for an actual > definition >4. If finding multiple WEAK defined entries, the linker will not >complain, > just use the first found. > >I suspect the specified linker semantics of not trying to satisfy "WEAK >UNDEF" entries would be suitable for optional link-time selected >callbacks or data where a referencing library do runtime tests to see >if the library- using program has provided a definition or not. For >example, it could be used for a symbol holding a list of global C++ >constructors/destructors with libc code invoking that list if present >without requiring dummy lists in programs without. > >The .so case mentioned probably works "by chance" because libssl.so >references non-weak libcrypto.so symbols, forcing the definition to be >included in the runtime process anyway. > >On 14/05/2019 11:29, John Unsworth wrote: >> Because of the #pragma weak directive the functions are defined >multiple times in both libcrypto.a and libssl.a: >> >> libcrypto.a >> >> Many UNDEF: >> ct_log.o >> [47] | 0| 0|FUNC |WEAK |0 >|UNDEF |OPENSSL_sk_new_null >> ... and more >> >> One definition from stack.c as you'd expect: >> stack.o >> [33] | 1232| 20|FUNC |WEAK |2 |2 > |OPENSSL_sk_new_null >> >> libssl.a has multiple instances also, all UNDEF: >> d1_srtp.o >> [43] | 0| 0|FUNC |WEAK |0 >|UNDEF |OPENSSL_sk_new_null >> s3_lib.o >> [107] | 0| 0|FUNC |WEAK |0 >|UNDEF |OPENSSL_sk_new_null >> and so on. >> >> From the linker docs: >> B.2.17.1 #pragma weak name >> In the form #pragma weak name, the directive makes name a weak >symbol. The linker will not complain if it does not find a symbol >definition for name. It also does not complain about multiple weak >definitions of the symbol. The linker simply takes the first one it >encounters. >> >> So when linking with libcrypto.a and libssl.a the first definition is >taken which is UNDEF in both cases leading to the error. >> This can be fixed in libcrypto.a by making stack.o, lh_stats.o and >lhash.o the first files included. It could also be fixed by not >defining those pragmas when compiling stack.c, lh_stats.c and lhash.c >because they will then be GLOB instead of WEAK and will override all >the WEAK definitions. >> >> However there is no suitable fix for libssl.a because those files are >not part of that library. >> >> Doing that means that executables that link libcrypto.a before >libssl.s are built correctly. However if the link is libssl.a followed >by libcrypto.a the UNDEF symbols from libssl.a are still used. >> >> In the shared libraries I see: >> >> libcrypto.so only instance: >> [3537] | 2409672| 20|FUNC |LOCL >|2 |10 |OPENSSL_sk_new_null >> >> Shared libssl.so also one instance: >> [2091] | 0| 0|FUNC |WEAK >|0 |UNDEF |OPENSSL_sk_new_null >> >> and it seems that the linker will resolve those correctly. >> >> So it seems to me that the only clean solution is to not define those >pragmas when compiling stack.c, lh_stats.c and lhash.c by including a >suitable define in the makefiles when building the libraries that is >used in safestack.h and lhash.h to omit them. >> >> I see there is also >> # elif defined(__SUNPRO_C) >> #pragma weak getisax >> in crypto\sparcv9cap.c >> so maybe that needs consideration too. >> >> Regards, >> John. >> >> -----Original Message----- >> From: openssl-users On Behalf Of >> John Unsworth >> Sent: 10 May 2019 16:23 >> To: openssl-users at openssl.org >> Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution >> >> This seems to be caused by the ongoing saga documented in issues 6912 >and 8102. These functions were declared as weak in 1.1.1b. >> >> safestack.h >> # pragma weak OPENSSL_sk_num >> # pragma weak OPENSSL_sk_value >> # pragma weak OPENSSL_sk_new >> # pragma weak OPENSSL_sk_new_null >> ... >> >> lhash.h >> # pragma weak OPENSSL_LH_new >> # pragma weak OPENSSL_LH_free >> # pragma weak OPENSSL_LH_insert >> # pragma weak OPENSSL_LH_delete >> ... >> >> Removing these lines allows all the tests to work. I am building >static libraries (no-shared) which is presumably why it works for some >people out of the box if they are using shared libraries. >> >> Please advise as to the way forward. I note that one other user (see >8102) has reported this too: >> >> rammishr commented on Mar 26 >> Hi, >> Sorry if this should have been posted separately. >> >> When i build openssl1.1.1b on solaris , it is successful. But while >verifying the version " openssl version" it fails with below error. >> ld.so.1: openssl: fatal: relocation error: file >> /vobs_tools/prgs/src/openssl/solaris64/bin/openssl: symbol >> OPENSSL_sk_new_null: referenced symbol not found Killed >> >> The same machine works fine for openssl1.1.1. >> So, in 1.1.1b I can observe that OPENSSL_sk_new_null has been defined >as below in safestack.h. >> pragma weak OPENSSL_sk_new_null >> Can this be related ? Am I missing anything while Configure ? >> <<<<<<<<<<<<<<< >> >> Regards, >> John. >> >> -----Original Message----- >> From: openssl-users On Behalf Of >> John Unsworth >> Sent: 09 May 2019 10:13 >> To: openssl-users at openssl.org >> Subject: RE: OpenSSL 1.1.1b tests fail on Solaris >> >> This looks like the problem: >> >> ld.so.1: sanitytest: fatal: relocation error: file >> ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol >> not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not >ok >> 1 - running sanitytest >> >> # Failed test 'running sanitytest' >> # at >/home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Simple.pm >line 77. >> # Looks like you failed 1 test of 1. >> Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests >> >> This results in the same error: >> sol-mds-build-01 $ cd apps >> sol-mds-build-01 $ ./openssl version >> ld.so.1: openssl: fatal: relocation error: file openssl: symbol >> OPENSSL_sk_new_null: referenced symbol not found >> >> I have built static libraries. >> >> John >> >> -----Original Message----- >> From: openssl-users On Behalf Of >> Matt Caswell >> Sent: 09 May 2019 09:38 >> To: openssl-users at openssl.org >> Subject: Re: OpenSSL 1.1.1b tests fail on Solaris >> >> What is the output from: >> >> $ make V=1 TESTS=test_sanity test >> >> Matt >> >> On 08/05/2019 19:22, John Unsworth wrote: >>> I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 >>> Generic_Virtual sun4v sparc SUNW,T5140. >>> >>> >>> >>> ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 >>> -xldscope=hidden >>> >>> >>> >>> It builds fine but all the tests fail, with or without no-asm. Can >>> anyone help please? Here is the start of the test run: >>> >>> >>> >>> $ make test >>> >>> make depend && make _tests >>> >>> ( cd test; \ >>> >>> mkdir -p test-runs; \ >>> >>> SRCTOP=../. \ >>> >>> BLDTOP=../. \ >>> >>> RESULT_D=test-runs \ >>> >>> PERL="/opt/perl-5.26.1/bin/perl" \ >>> >>> EXE_EXT= \ >>> >>> OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ >>> >>> OPENSSL_DEBUG_MEMORY=on \ >>> >>> /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) >>> >>> ../test/recipes/01-test_abort.t .................... ok >>> >>> ../test/recipes/01-test_sanity.t ................... Dubious, test >>> returned 1 (wstat 256, 0x100) >>> >>> Failed 1/1 subtests >>> > >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 -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From Michael.Wojcik at microfocus.com Thu May 16 16:14:33 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 16 May 2019 16:14:33 +0000 Subject: Build the FIPS Object Module issue on Ubuntu 18.04 In-Reply-To: References: <1557957379737-0.post@n7.nabble.com> <233ca6dc-8973-487c-bcef-17d1695b7dbc@default> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Jakob Bohm via openssl-users > Sent: Thursday, May 16, 2019 02:21 > > On 16/05/2019 02:11, Paul Dale wrote: > > Just noting that any module built in this manner is *not* FIPS compliant. > > > Only deviations from the official process in creating the > fipscanister invalidates the FIPS validation. > > The FIPS-capable OpenSSL is "outside the boundary" of the > FIPS module and can be changed at will. This is why a new > FIPS validation is not needed every time OpenSSL releases > a bugfix to OpenSSL 1.0.x . That's my understanding too, though I don't deal with a FIPS-validated distribution myself. As the OpenSSL FIPS User Guide puts it, "OpenSSL itself is not validated,and never will be". For FIPS, what matters is the OpenSSL FIPS Object Module (the "canister"). However, in this case that's probably moot. The existing validations cover only a handful of Android releases (none later than 5.0, aka Lollipop) on specific hardware. So the best the OP can achieve is a FIPS 140-2 self-validation claim (or pay for a complete validation by some outside lab). Some customers may accept that, but it's weak. That's one of the problems with FIPS validation - platform restrictions means it has a short shelf life, at least in any market which actually cares about following the letter of the regulations. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Thu May 16 16:14:33 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 16 May 2019 16:14:33 +0000 Subject: FIPS module for OpenSSL 1.1.1x In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of shiva kumar > Sent: Thursday, May 16, 2019 04:30 > 1) If I upgrade to 1.1.1b will it cause any problem to other applications? which > uses openssl for communications. ( say apache http server ). I don't think anyone on the openssl-users list can predict the future. OpenSSL 1.1.1, in its default configuration (using the default cipher list, etc) does disable some algorithms which are now deemed unsafe. That may prevent connecting to old peers that only support deprecated algorithms. The workarounds are to upgrade (or reconfigure) the peers, or change the cipher list or other configuration for the component using 1.1.1. On the other hand, 1.1.1 adds support for TLSv1.3 and other newer TLS features, so it will improve compatibility with peers that require support for contemporary protocols and algorithms. Since there have been many versions of Apache, and it offers a multitude of configurations, it's impossible to guess whether you'd have interoperability issues with it. > 2) can I expect FIPS module for 1.1.1b as well ? No. This has been discussed ad nauseum on the list, and is well-documented on the openssl.org site. The next FIPS module release will be for the next major OpenSSL release (which will be called OpenSSL 3 or OpenSSL 4), and will likely not be available until sometime in 2020. > 3) since OpenSSL 1.1.1b doesn't have FIPS will this affect any other application ? Any application that uses OpenSSL and requires FIPS mode (that is, insists on enabling it) will have to use 1.0.2 until 3 (or 4) is available. Any application that claims FIPS validation (or uses "FIPS inside" branding) and uses OpenSSL will have to use 1.0.2 until 3 is available. FIPS mode should not be required for interoperability. FIPS 140-2 restricts what features are available; it doesn't add any. Those features are all still available outside FIPS mode. -- Michael Wojcik Distinguished Engineer, Micro Focus From dhamija_shalu at yahoo.com Thu May 16 16:22:13 2019 From: dhamija_shalu at yahoo.com (shalu dhamija) Date: Thu, 16 May 2019 16:22:13 +0000 (UTC) Subject: Query related to session resumption in TLS1.3 In-Reply-To: <1215030240.3310705.1558019010498@mail.yahoo.com> References: <1215030240.3310705.1558019010498.ref@mail.yahoo.com> <1215030240.3310705.1558019010498@mail.yahoo.com> Message-ID: <1144086040.3361810.1558023733499@mail.yahoo.com> Hi All, I am in process of using TLS1.3 using openssl 1.1.1b version in my client application. In order to use session resumption, I have implemented an external cache when acting as the client. The key to the cache is combination of host and port and the value? associated is SSL_SESSION*.? ?Before calling ssl_connect, I am checking if the entry corresponding to the key exists in the map. If it exists, I am calling SSL_set_session. After ssl_connect, I am checking if the session is reused or not using SSL_Session_Reused. If its not reused, I am inserting the new session obtained as a result of call to SSL_get1_session() in the map. Pseudo code is as follows: std::map sessionCache;/* Generate an SSL client context. */SSL_CTX* ctx = SSL_CTX_new(TLS_method());SSL* ssl = SSL_new(ctx);?//Check if we have a stored session?it = sessionCache.find (key);if (it != sessionCache.end())?{ SSL_set_session (ssl, it->second)} SSL_connect(ssl);int reUsed = SSL_session_reused(ssl);if (!reUsed) { session = SSL_get1_session(ssl); sessionCache.insert (key, session);} The above flow works well using TLS1.2. I can see that SSL_session_reused returns true in the second connection.? But the same flow does not work for TLS1.3. In TLSv1.3, sessions are established after the main handshake has completed. So, I have implemented the callback? SSL_CTX_sess_set_new_cb.? And in the callback, I am storing the session into the cache. In subsequent connections, the session is present in the map, SSL_set_session API returns true. But SSL_session_reused is always returning false. I have the following queries:1. Is the above mentioned approach applicable for TLS 1.3??2. There is a mention that PreShared keys are used for session resumption in TLS1.3.? Can someone please clarify, how should I make my client send psk using openssl for subsequent connection? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu May 16 16:40:38 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 May 2019 12:40:38 -0400 Subject: Query related to session resumption in TLS1.3 In-Reply-To: <1144086040.3361810.1558023733499@mail.yahoo.com> References: <1215030240.3310705.1558019010498.ref@mail.yahoo.com> <1215030240.3310705.1558019010498@mail.yahoo.com> <1144086040.3361810.1558023733499@mail.yahoo.com> Message-ID: <20190516164038.GZ67454@straasha.imrryr.org> On Thu, May 16, 2019 at 04:22:13PM +0000, shalu dhamija via openssl-users wrote: > But the same flow does not work for TLS1.3. In TLSv1.3, sessions are > established after the main handshake has completed. So, I have implemented > the callback SSL_CTX_sess_set_new_cb. And in the callback, I am storing > the session into the cache. In subsequent connections, the session is > present in the map, SSL_set_session API returns true. But SSL_session_reused > is always returning false. This is not expected, perhaps your code is not quite right. > I have the following queries: > 1. Is the above mentioned approach applicable for TLS 1.3? Yes. It works, for example, in Postfix: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L543-L547 https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1001-L1004 https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1146 > 2. There is a mention that PreShared keys are used for session > resumption in TLS1.3. This is misleading. In TLS 1.3, the PSKs and session tickets have been internally unified into a single protocol mechanism. This internal detail is not something that users need to worry about. > Can someone please clarify, how should I make my > client send psk using openssl for subsequent connection? This is not the right question. SSL_set_session() is all you need for session resumption. -- Viktor. From dclarke at blastwave.org Thu May 16 17:03:12 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 16 May 2019 13:03:12 -0400 Subject: FIPS module for OpenSSL 1.1.1x In-Reply-To: References: Message-ID: On 5/16/19 12:14 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of shiva kumar >> Sent: Thursday, May 16, 2019 04:30 > >> 1) If I upgrade to 1.1.1b will it cause any problem to other applications? which >> uses openssl for communications. ( say apache http server ). > > I don't think anyone on the openssl-users list can predict the future. > I can. However only a few microseconds. Thankfully speech and human communications are so slow on a macroscopic scale that it is measurably impossible to catch me in an error. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From John.Unsworth at synchronoss.com Thu May 16 18:53:46 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Thu, 16 May 2019 18:53:46 +0000 Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix Message-ID: Thanks. So in the meantime we can remove the DEFINE macros and the pragmas (or just the pragmas as we have done) to build the no-shared libraries. Regards, John. -------- Originalmeddelande -------- Fr?n: Richard Levitte Skickat: 16 maj 2019 08:34:06 GMT-07:00 Till: John Unsworth ?mne: RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix The actual problem is the call of DEFINE macros in safestack.h. They should not be there. The only reason those lines haven't been removed us that we fear someone might have use of them. I plan to submit a PR for 3.0 that does remove those lines. Cheers Richard John Unsworth skrev: (16 maj 2019 03:46:49 GMT-07:00) >In the absence of any steer from openssl gurus we will proceed by >removing the #pragmas in safestack.h and lhash.h while we build the >no-shared libraries on solaris. Hopefully someone will come up with a >proper fix at some point. > >Regards, >John > >From: openssl-users On Behalf Of >John Unsworth >Sent: 15 May 2019 21:08 >To: openssl-users at openssl.org >Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible >fix > >>> Issue #pragma weak for a symbol only in the files that define that >symbol, not in the ones that merely reference it. >The problem is that those pragmas are in .h files. They contain inline >functions that use those symbols. The pragmas were added because of >problems with apps that used the .h files (hard to avoid since they are >basic crypto header files) but did not link with libcrypto.so. That >library was explicitly loaded by the app, but the app would not start >because of the missing symbols. > >See issues 6912 and 8102. > >Regards, >John. > >-----Original Message----- >From: openssl-users On Behalf Of >Jakob Bohm via openssl-users >Sent: 15 May 2019 16:11 >To: openssl-users at openssl.org >Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution and >possible fix > >Alternative suggestion (from my understanding of the documentation >quoted >below): > >Issue #pragma weak for a symbol only in the files that define that >symbol, not in the ones that merely reference it. > >The hoped effect would be: > >1. Object files that merely reference a symbol will contain regular >UNDEF > entries >2. Object files that do define such a symbol will contain a WEAK >defined > entry >3. When seeing the UNDEF entries, the linker will look for an actual > definition >4. If finding multiple WEAK defined entries, the linker will not >complain, > just use the first found. > >I suspect the specified linker semantics of not trying to satisfy "WEAK >UNDEF" entries would be suitable for optional link-time selected >callbacks or data where a referencing library do runtime tests to see >if the library- using program has provided a definition or not. For >example, it could be used for a symbol holding a list of global C++ >constructors/destructors with libc code invoking that list if present >without requiring dummy lists in programs without. > >The .so case mentioned probably works "by chance" because libssl.so >references non-weak libcrypto.so symbols, forcing the definition to be >included in the runtime process anyway. > >On 14/05/2019 11:29, John Unsworth wrote: >> Because of the #pragma weak directive the functions are defined >multiple times in both libcrypto.a and libssl.a: >> >> libcrypto.a >> >> Many UNDEF: >> ct_log.o >> [47] | 0| 0|FUNC |WEAK |0 >|UNDEF |OPENSSL_sk_new_null >> ... and more >> >> One definition from stack.c as you'd expect: >> stack.o >> [33] | 1232| 20|FUNC |WEAK |2 |2 > |OPENSSL_sk_new_null >> >> libssl.a has multiple instances also, all UNDEF: >> d1_srtp.o >> [43] | 0| 0|FUNC |WEAK |0 >|UNDEF |OPENSSL_sk_new_null >> s3_lib.o >> [107] | 0| 0|FUNC |WEAK |0 >|UNDEF |OPENSSL_sk_new_null >> and so on. >> >> From the linker docs: >> B.2.17.1 #pragma weak name >> In the form #pragma weak name, the directive makes name a weak >symbol. The linker will not complain if it does not find a symbol >definition for name. It also does not complain about multiple weak >definitions of the symbol. The linker simply takes the first one it >encounters. >> >> So when linking with libcrypto.a and libssl.a the first definition is >taken which is UNDEF in both cases leading to the error. >> This can be fixed in libcrypto.a by making stack.o, lh_stats.o and >lhash.o the first files included. It could also be fixed by not >defining those pragmas when compiling stack.c, lh_stats.c and lhash.c >because they will then be GLOB instead of WEAK and will override all >the WEAK definitions. >> >> However there is no suitable fix for libssl.a because those files are >not part of that library. >> >> Doing that means that executables that link libcrypto.a before >libssl.s are built correctly. However if the link is libssl.a followed >by libcrypto.a the UNDEF symbols from libssl.a are still used. >> >> In the shared libraries I see: >> >> libcrypto.so only instance: >> [3537] | 2409672| 20|FUNC |LOCL >|2 |10 |OPENSSL_sk_new_null >> >> Shared libssl.so also one instance: >> [2091] | 0| 0|FUNC |WEAK >|0 |UNDEF |OPENSSL_sk_new_null >> >> and it seems that the linker will resolve those correctly. >> >> So it seems to me that the only clean solution is to not define those >pragmas when compiling stack.c, lh_stats.c and lhash.c by including a >suitable define in the makefiles when building the libraries that is >used in safestack.h and lhash.h to omit them. >> >> I see there is also >> # elif defined(__SUNPRO_C) >> #pragma weak getisax >> in crypto\sparcv9cap.c >> so maybe that needs consideration too. >> >> Regards, >> John. >> >> -----Original Message----- >> From: openssl-users On Behalf Of >> John Unsworth >> Sent: 10 May 2019 16:23 >> To: openssl-users at openssl.org >> Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution >> >> This seems to be caused by the ongoing saga documented in issues 6912 >and 8102. These functions were declared as weak in 1.1.1b. >> >> safestack.h >> # pragma weak OPENSSL_sk_num >> # pragma weak OPENSSL_sk_value >> # pragma weak OPENSSL_sk_new >> # pragma weak OPENSSL_sk_new_null >> ... >> >> lhash.h >> # pragma weak OPENSSL_LH_new >> # pragma weak OPENSSL_LH_free >> # pragma weak OPENSSL_LH_insert >> # pragma weak OPENSSL_LH_delete >> ... >> >> Removing these lines allows all the tests to work. I am building >static libraries (no-shared) which is presumably why it works for some >people out of the box if they are using shared libraries. >> >> Please advise as to the way forward. I note that one other user (see >8102) has reported this too: >> >> rammishr commented on Mar 26 >> Hi, >> Sorry if this should have been posted separately. >> >> When i build openssl1.1.1b on solaris , it is successful. But while >verifying the version " openssl version" it fails with below error. >> ld.so.1: openssl: fatal: relocation error: file >> /vobs_tools/prgs/src/openssl/solaris64/bin/openssl: symbol >> OPENSSL_sk_new_null: referenced symbol not found Killed >> >> The same machine works fine for openssl1.1.1. >> So, in 1.1.1b I can observe that OPENSSL_sk_new_null has been defined >as below in safestack.h. >> pragma weak OPENSSL_sk_new_null >> Can this be related ? Am I missing anything while Configure ? >> <<<<<<<<<<<<<<< >> >> Regards, >> John. >> >> -----Original Message----- >> From: openssl-users On Behalf Of >> John Unsworth >> Sent: 09 May 2019 10:13 >> To: openssl-users at openssl.org >> Subject: RE: OpenSSL 1.1.1b tests fail on Solaris >> >> This looks like the problem: >> >> ld.so.1: sanitytest: fatal: relocation error: file >> ../../test/sanitytest: symbol OPENSSL_sk_new_null: referenced symbol >> not found ../../util/shlib_wrap.sh ../../test/sanitytest => 137 not >ok >> 1 - running sanitytest >> >> # Failed test 'running sanitytest' >> # at >/home/metabld/OpenSSL/openssl-1.1.1b/test/../util/perl/OpenSSL/Test/Sim >ple.pm >line 77. >> # Looks like you failed 1 test of 1. >> Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests >> >> This results in the same error: >> sol-mds-build-01 $ cd apps >> sol-mds-build-01 $ ./openssl version >> ld.so.1: openssl: fatal: relocation error: file openssl: symbol >> OPENSSL_sk_new_null: referenced symbol not found >> >> I have built static libraries. >> >> John >> >> -----Original Message----- >> From: openssl-users On Behalf Of >> Matt Caswell >> Sent: 09 May 2019 09:38 >> To: openssl-users at openssl.org >> Subject: Re: OpenSSL 1.1.1b tests fail on Solaris >> >> What is the output from: >> >> $ make V=1 TESTS=test_sanity test >> >> Matt >> >> On 08/05/2019 19:22, John Unsworth wrote: >>> I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 >>> Generic_Virtual sun4v sparc SUNW,T5140. >>> >>> >>> >>> ./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 >>> -xldscope=hidden >>> >>> >>> >>> It builds fine but all the tests fail, with or without no-asm. Can >>> anyone help please? Here is the start of the test run: >>> >>> >>> >>> $ make test >>> >>> make depend && make _tests >>> >>> ( cd test; \ >>> >>> mkdir -p test-runs; \ >>> >>> SRCTOP=../. \ >>> >>> BLDTOP=../. \ >>> >>> RESULT_D=test-runs \ >>> >>> PERL="/opt/perl-5.26.1/bin/perl" \ >>> >>> EXE_EXT= \ >>> >>> OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ >>> >>> OPENSSL_DEBUG_MEMORY=on \ >>> >>> /opt/perl-5.26.1/bin/perl .././test/run_tests.pl ) >>> >>> ../test/recipes/01-test_abort.t .................... ok >>> >>> ../test/recipes/01-test_sanity.t ................... Dubious, test >>> returned 1 (wstat 256, 0x100) >>> >>> Failed 1/1 subtests >>> > >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 -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From paul.dale at oracle.com Fri May 17 06:31:30 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 17 May 2019 16:31:30 +1000 Subject: FIPS module for OpenSSL 1.1.1x In-Reply-To: References: Message-ID: <5A13FF26-BDF5-47ED-A498-035C01375421@oracle.com> In answer to the second question: there will *never* be a FIPS module for any 1.1.1 OpenSSL version. The next version of OpenSSL will be 3.0.0 and it will support FIPS. There will be a gap in FIPS support between the end of life of 1.0.2 and the validation of 3.0.0. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 16 May 2019, at 8:29 pm, shiva kumar wrote: > > Hi, > I wanted to move from OpenSSL 1.0.2r to 1.1.1b. I have some doubts they are > > 1) If I upgrade to 1.1.1b will it cause any problem to other applications? which uses openssl for communications. ( say apache http server ). > > 2) can I expect FIPS module for 1.1.1b as well ? > > 3) since OpenSSL 1.1.1b doesn't have FIPS will this affect any other application ? > > > > Thanks and regards > Shivakumar S > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon May 20 08:55:47 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 20 May 2019 10:55:47 +0200 Subject: Building OpenSSL with Emscripten In-Reply-To: References: Message-ID: <87woil33os.wl-levitte@openssl.org> The issue isn't with any defined or not so defined macro, but most probably rather with how you're loading the library in the 3rd party code base. Could it be that you're linking with libssl only? Cheers, Richard On Fri, 10 May 2019 22:29:36 +0200, Sunghyun Park wrote: > > Hi, all. Thanks for your help, I could finish compilation to the end.? > However, athough I successfully compiled with _no-asm_ options, I found a problem when loading the > compiled library in the 3rd party code base. > When looking into the source code, the definition of some function seems to require a specific > preprocessor to be compiled.? > (For example, PEM_write_bio_DSAPrivateKey needs '#define OPENSSL_FIPS'.) > I installed?openssl-1.0.2r.tar.gz and only provided no-asm for configuration. > Am I missing some dependencies or necessary options? > The error I'm facing is as follows: > > error: undefined symbol: AES_ctr128_encrypt > warning: To disable errors for undefined symbols use `-s ERROR_ON_UNDEFINED_SYMBOLS=0` > error: undefined symbol: AES_set_encrypt_key > error: undefined symbol: BIO_ctrl > error: undefined symbol: BIO_free > error: undefined symbol: BIO_new > error: undefined symbol: BIO_s_mem > error: undefined symbol: BN_bn2bin > error: undefined symbol: BN_free > error: undefined symbol: BN_is_bit_set > error: undefined symbol: BN_new > error: undefined symbol: BN_num_bits > error: undefined symbol: BN_set_word > error: undefined symbol: CRYPTO_free > error: undefined symbol: CRYPTO_malloc > error: undefined symbol: DSA_free > error: undefined symbol: DSA_generate_key > error: undefined symbol: DSA_generate_parameters_ex > error: undefined symbol: DSA_new > error: undefined symbol: EC_KEY_free > error: undefined symbol: EC_KEY_generate_key > error: undefined symbol: EC_KEY_get0_group > error: undefined symbol: EC_KEY_get0_public_key > error: undefined symbol: EC_KEY_new_by_curve_name > error: undefined symbol: EC_KEY_set_asn1_flag > error: undefined symbol: EC_POINT_point2oct > > .... > > Any advice would be a great help! > Thank you. > > On Thu, May 9, 2019 at 10:43 PM Dr Paul Dale wrote: > > Configure with the _no-asm_ option. > > It will be a **lot** slower. > > Pauli > --? > Dr Paul Dale | Cryptographer | Network?Security & Encryption? > Phone +61 7 3031 7217 > Oracle Australia > > On 10 May 2019, at 3:33 pm, Sunghyun Park wrote: > > Nice to meet you all :) > > I faced a problem while building assembly code in OpenSSL (e.g., crypto/x86_64cpuid.s) > with Emscripten.? > Since Emscripten does not support compilation for assembly code (As far as I know), I'm > wondering if there is any version of OpenSSL that does not require compiling assembly > code. > Or, if there is anyone who experienced the similar problem, please share your experience.? > > Thank you! > > -- > Best, Sung > > -- > Best, Sung > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Chethan.Kumar at toshiba-tsip.com Mon May 20 10:21:33 2019 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Mon, 20 May 2019 10:21:33 +0000 Subject: To get end point's IP address Message-ID: <447C096A3E2889439233CDD6DAB29F95BF3CB2DF@tosblrmbx04.TOSHIBA-TSIP.COM> Dear all, I wanted to log end point's IP address during some errors in communication using openssl. What is the best way to know end point's IP address in openssl as many applications use openssl and its not feasible to change in all of them. Initially when I tried getpeername() on SSL context, its giving proxy server's IP and not destination IP. Let me know how can achieve the same. Thanks in advance, Chethan Kumar The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Mon May 20 14:04:36 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 20 May 2019 14:04:36 +0000 Subject: To get end point's IP address In-Reply-To: <447C096A3E2889439233CDD6DAB29F95BF3CB2DF@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB2DF@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Chethan Kumar > Sent: Monday, May 20, 2019 04:22 > I wanted to log end point?s IP address during some errors in communication > using openssl. > Initially when I tried getpeername() on SSL context, its giving proxy > server?s IP and not destination IP. The proxy server address *is* the peer address. Proxies terminate TLS conversations. The client has a TLS conversation with the proxy, and the proxy may have a separate TLS conversation with the origin server. (Or with whatever the next application-level node in the chain is; there can be multiple proxies, gateways, etc.) If it didn't do TLS termination, it wouldn't be a proxy, but a router. If you have a node that's doing routing at level 4 (copying data between two TCP connections) but not doing TLS termination, there's no way to get the IP addresses of the endpoints of the other connection from the stack. That information has to be provided at the application level. (Techincal quibble: "Level 4 routing" is a somewhat dubious concept in TCP/IP, since TCP straddles OSI levels 4 and 5. But applications which forward data between TCP conversations are traditionally connsidered level-4 routers. Also, note some level-4 routing packages do TLS termination - stunnel in its base mode is an example. A level-4 router may or may not do TLS termination.) -- Michael Wojcik Distinguished Engineer, Micro Focus From james.j.decaro3.civ at mail.mil Mon May 20 19:23:36 2019 From: james.j.decaro3.civ at mail.mil (DeCaro, James John (Jim) CIV DISA SD (US)) Date: Mon, 20 May 2019 19:23:36 +0000 Subject: OpenSSL 1.1.1b installation Message-ID: <1609C7EA8C9FEF4DBBDFA1E2FB502263BBAA35F3@UMECHPA7E.easf.csd.disa.mil> Hello, I am working on a Solaris 11.4 x86 64bit virtual server. There are no specific applications loaded on it yet. I am preparing it to be a BIND server eventually. To that end, I downloaded and installed OpenSSL 1.1.1b so I have the latest and greatest to work with. The installation seemed to go well. Installed a gcc compiler, ran ./configure, make, make test and make install accepting the defaults. No errors. When I run the #openssl version -a it shows the previous version of openssl. I have tried researching the issue, and attempting to set additional PATH variables in the root .profile to include /usr/local. I think I may need to set symbolic links, but I am not sure. Any assistance would be appreciated. V/R Jim DeCaro DISA Systems Administrator SE62/Server Operations ? 301-225-8180 ? 301-375-8180 James.j.decaro3.civ at mail.mil James.j.decaro3.civ at mail.smil.mil From d3ck0r at gmail.com Tue May 21 00:16:19 2019 From: d3ck0r at gmail.com (J Decker) Date: Mon, 20 May 2019 17:16:19 -0700 Subject: Building OpenSSL with Emscripten In-Reply-To: <87woil33os.wl-levitte@openssl.org> References: <87woil33os.wl-levitte@openssl.org> Message-ID: https://stackoverflow.com/questions/52327290/linking-openssl-with-webassembly Looks very similar... 'target_link_libraries(mainTest crypto) after that it all worked without warnings.' On Mon, May 20, 2019 at 1:56 AM Richard Levitte wrote: > The issue isn't with any defined or not so defined macro, but most > probably rather with how you're loading the library in the 3rd party > code base. Could it be that you're linking with libssl only? > > Cheers, > Richard > > On Fri, 10 May 2019 22:29:36 +0200, > Sunghyun Park wrote: > > > > Hi, all. Thanks for your help, I could finish compilation to the end. > > However, athough I successfully compiled with _no-asm_ options, I found > a problem when loading the > > compiled library in the 3rd party code base. > > When looking into the source code, the definition of some function seems > to require a specific > > preprocessor to be compiled. > > (For example, PEM_write_bio_DSAPrivateKey needs '#define OPENSSL_FIPS'.) > > I installed openssl-1.0.2r.tar.gz and only provided no-asm for > configuration. > > Am I missing some dependencies or necessary options? > > The error I'm facing is as follows: > > > > error: undefined symbol: AES_ctr128_encrypt > > warning: To disable errors for undefined symbols use `-s > ERROR_ON_UNDEFINED_SYMBOLS=0` > > error: undefined symbol: AES_set_encrypt_key > > error: undefined symbol: BIO_ctrl > > error: undefined symbol: BIO_free > > error: undefined symbol: BIO_new > > error: undefined symbol: BIO_s_mem > > error: undefined symbol: BN_bn2bin > > error: undefined symbol: BN_free > > error: undefined symbol: BN_is_bit_set > > error: undefined symbol: BN_new > > error: undefined symbol: BN_num_bits > > error: undefined symbol: BN_set_word > > error: undefined symbol: CRYPTO_free > > error: undefined symbol: CRYPTO_malloc > > error: undefined symbol: DSA_free > > error: undefined symbol: DSA_generate_key > > error: undefined symbol: DSA_generate_parameters_ex > > error: undefined symbol: DSA_new > > error: undefined symbol: EC_KEY_free > > error: undefined symbol: EC_KEY_generate_key > > error: undefined symbol: EC_KEY_get0_group > > error: undefined symbol: EC_KEY_get0_public_key > > error: undefined symbol: EC_KEY_new_by_curve_name > > error: undefined symbol: EC_KEY_set_asn1_flag > > error: undefined symbol: EC_POINT_point2oct > > > > .... > > > > Any advice would be a great help! > > Thank you. > > > > On Thu, May 9, 2019 at 10:43 PM Dr Paul Dale > wrote: > > > > Configure with the _no-asm_ option. > > > > It will be a **lot** slower. > > > > Pauli > > -- > > Dr Paul Dale | Cryptographer | Network Security & Encryption > > Phone +61 7 3031 7217 > > Oracle Australia > > > > On 10 May 2019, at 3:33 pm, Sunghyun Park > wrote: > > > > Nice to meet you all :) > > > > I faced a problem while building assembly code in OpenSSL (e.g., > crypto/x86_64cpuid.s) > > with Emscripten. > > Since Emscripten does not support compilation for assembly code > (As far as I know), I'm > > wondering if there is any version of OpenSSL that does not > require compiling assembly > > code. > > Or, if there is anyone who experienced the similar problem, > please share your experience. > > > > Thank you! > > > > -- > > Best, Sung > > > > -- > > Best, Sung > > > > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dengwenbin_0301 at 126.com Tue May 21 01:26:41 2019 From: dengwenbin_0301 at 126.com (dengwenbin_0301) Date: Tue, 21 May 2019 09:26:41 +0800 (CST) Subject: Building openssl outside of the source tree" doesn't work well Message-ID: <5cb8a430.12ae.16ad7ff68cf.Coremail.dengwenbin_0301@126.com> Dear all, Following the instructions in chapter 1c "Configure OpenSSL for building outside of the source tree." of INSTALL doc, I create "obj" folder under the top directory and try to build in that folder. The result shows some header file for the file app_rand.c is not included. Is this a bug or did i miss anything? ../apps/app_rand.c:10:18: fatal error: apps.h: No such file or directory wdeng:~/wenbindfiles/openssl/openssl [master]$ ls ACKNOWLEDGEMENTS boringssl config Configure doc FAQ krb5 libcrypto.so libssl.pc ms NOTES.PERL NOTES.WIN os-dep README.ENGINE tools apps build.info config.com CONTRIBUTING engines fuzz libcrypto.a libcrypto.so.3 libssl.so NEWS NOTES.UNIX NUL providers README.FIPS util appveyor.yml build.info.patch configdata.pm crypto e_os.h include libcrypto.ld libssl.a libssl.so.3 NOTES.ANDROID NOTES.VALGRIND obj pyca-cryptography ssl VMS AUTHORS CHANGES Configurations demos external INSTALL libcrypto.pc libssl.ld LICENSE NOTES.DJGPP NOTES.VMS openssl.pc README test wdeng:~/wenbindfiles/openssl/openssl [master]$ git log -n 1 commit d3136af3c3905a730bd8fb44158aab36a2549d9b Author: Richard Levitte Date: Sat May 18 16:24:21 2019 -0700 Configure: let platform->dsoext() default with platform->shlibextsimple() We still use '.so' as a last resort... Fixes #8950 Reviewed-by: Tim Hudson (Merged from https://github.com/openssl/openssl/pull/8951) wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl [master]$ cd obj/ wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ ../config Operating system: x86_64-whatever-linux2 Configuring OpenSSL version 3.0.0-dev for target linux-x86_64 Using os-specific seed configuration Creating configdata.pm Creating Makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub *** *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** *** *** ********************************************************************** wdeng:~/wenbindfiles/openssl/openssl/obj [master]$ make make depend && make _all make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG -MMD -MF apps/libapps-lib-app_rand.d.tmp -MT apps/libapps-lib-app_rand.o -c -o apps/libapps-lib-app_rand.o ../apps/app_rand.c ../apps/app_rand.c:10:18: fatal error: apps.h: No such file or directory compilation terminated. Makefile:826: recipe for target 'apps/libapps-lib-app_rand.o' failed make[1]: *** [apps/libapps-lib-app_rand.o] Error 1 make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' Makefile:165: recipe for target 'all' failed make: *** [all] Error 2 Thanks, Wenbin -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue May 21 03:47:14 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 21 May 2019 05:47:14 +0200 Subject: Building openssl outside of the source tree" doesn't work well In-Reply-To: <5cb8a430.12ae.16ad7ff68cf.Coremail.dengwenbin_0301@126.com> References: <5cb8a430.12ae.16ad7ff68cf.Coremail.dengwenbin_0301@126.com> Message-ID: <87lfz031vh.wl-levitte@openssl.org> On Tue, 21 May 2019 03:26:41 +0200, dengwenbin_0301 wrote: > > wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl [master]$ cd obj/ > > wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ ../config > Operating system: x86_64-whatever-linux2 > Configuring OpenSSL version 3.0.0-dev for target linux-x86_64 > Using os-specific seed configuration > Creating configdata.pm > Creating Makefile > > ********************************************************************** > *** *** > *** OpenSSL has been successfully configured *** > *** *** > *** If you encounter a problem while building, please open an *** > *** issue on GitHub ; *** > *** and include the output from the following command: *** > *** *** > *** perl configdata.pm --dump *** > *** *** > *** (If you are new to OpenSSL, you might want to consult the *** > *** 'Troubleshooting' section in the INSTALL file first) *** > *** *** > ********************************************************************** > wdeng:~/wenbindfiles/openssl/openssl/obj [master]$ make > make depend && make _all > make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' > make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' > make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' > gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM > -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr > /local/lib/ossl-modules\"" -DNDEBUG -MMD -MF apps/libapps-lib-app_rand.d.tmp -MT apps/ > libapps-lib-app_rand.o -c -o apps/libapps-lib-app_rand.o ../apps/app_rand.c > ../apps/app_rand.c:10:18: fatal error: apps.h: No such file or directory > compilation terminated. > Makefile:826: recipe for target 'apps/libapps-lib-app_rand.o' failed > make[1]: *** [apps/libapps-lib-app_rand.o] Error 1 > make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' > Makefile:165: recipe for target 'all' failed > make: *** [all] Error 2 I tried exactly that just now, exactly same 'obj' ubdirectory, and it works with no problem. Something I'm noticing from your command line is that all -I options that I expect to see there are gone. This is what I expect (note that I go directly at the object file for demonstration purposes): : ; make apps/libapps-lib-app_rand.o gcc -I. -Iinclude -Iapps/include -I.. -I../include -I../apps/include -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG -MMD -MF apps/libapps-lib-app_rand.d.tmp -MT apps/libapps-lib-app_rand.o -c -o apps/libapps-lib-app_rand.o ../apps/app_rand.c So the question is what happened to '-I. -Iinclude -Iapps/include -I.. -I../include -I../apps/include' in your build. I cannot say right now, but it might help if you show the output from './configdata.pm --dump' Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From shivakumar2696 at gmail.com Tue May 21 08:28:48 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Tue, 21 May 2019 13:58:48 +0530 Subject: error while running openssl 1.1.1b config file Message-ID: Hi, when running openssl 1.1.1b config file with no-krb5 option I got as, ***** Unsupported options: no-krb5 can I know why I'am getting this error? when i remove the no-krb5 option it works. This option was working on openssl 1.0.2r, but why this option is not working here ? can I know ? Thanks and Regards Shivakumar S -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue May 21 08:33:16 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 May 2019 09:33:16 +0100 Subject: error while running openssl 1.1.1b config file In-Reply-To: References: Message-ID: On 21/05/2019 09:28, shiva kumar wrote: > Hi, > when running openssl 1.1.1b config file with?no-krb5 option > I got as,? > > ***** Unsupported options: no-krb5 > ? > can I know why I'am getting this?error?? > when i remove the no-krb5 option it works. > This option was working on openssl 1.0.2r, but why this option is not working > here ? can I know ??? There is no krb5 support at all in 1.1.0+ so the option has gone. You don't need it so just remove it. Matt From shivakumar2696 at gmail.com Tue May 21 08:44:03 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Tue, 21 May 2019 14:14:03 +0530 Subject: error while running openssl 1.1.1b config file In-Reply-To: References: Message-ID: is Kerberos v5 is completely removed or depreciated from OpenSSL 1.1.0 onwards ? On Tue, May 21, 2019 at 2:04 PM Matt Caswell wrote: > > > On 21/05/2019 09:28, shiva kumar wrote: > > Hi, > > when running openssl 1.1.1b config file with no-krb5 option > > I got as, > > > > ***** Unsupported options: no-krb5 > > > > can I know why I'am getting this error? > > when i remove the no-krb5 option it works. > > This option was working on openssl 1.0.2r, but why this option is not > working > > here ? can I know ? > > There is no krb5 support at all in 1.1.0+ so the option has gone. You > don't need > it so just remove it. > > Matt > > -- *With Best Regards* *Shivakumar S* *Mysore, Karnataka* *# 91-9945543956* -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue May 21 08:45:13 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 May 2019 09:45:13 +0100 Subject: error while running openssl 1.1.1b config file In-Reply-To: References: Message-ID: <36003e13-9de0-505b-805d-cae291d86349@openssl.org> On 21/05/2019 09:44, shiva kumar wrote: > is Kerberos v5 is completely removed or depreciated from? OpenSSL? 1.1.0 onwards? ? It was completely removed. Matt From shivakumar2696 at gmail.com Tue May 21 08:46:22 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Tue, 21 May 2019 14:16:22 +0530 Subject: error while running openssl 1.1.1b config file In-Reply-To: <36003e13-9de0-505b-805d-cae291d86349@openssl.org> References: <36003e13-9de0-505b-805d-cae291d86349@openssl.org> Message-ID: Ok, thanks. On Tue, May 21, 2019 at 2:15 PM Matt Caswell wrote: > > > On 21/05/2019 09:44, shiva kumar wrote: > > is Kerberos v5 is completely removed or depreciated from OpenSSL 1.1.0 > onwards ? > > It was completely removed. > > Matt > > -- *With Best Regards* *Shivakumar S* *Mysore, Karnataka* *# 91-9945543956* -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chethan.Kumar at toshiba-tsip.com Tue May 21 09:53:24 2019 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Tue, 21 May 2019 09:53:24 +0000 Subject: To get end point's IP address In-Reply-To: References: <447C096A3E2889439233CDD6DAB29F95BF3CB2DF@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: <447C096A3E2889439233CDD6DAB29F95BF3CB52E@tosblrmbx04.TOSHIBA-TSIP.COM> Thanks for the information. I researched more and found that tlsext_hostname member variable in SSL structure can be used to to get host name. If applications set this using SSL_set_tlsext_host_name(), is it correct to print hostname/IP in tlsext_hostname. Can I use this one to set hostname/Ip address.? Can applications acting as both server and client set this? Thanks in advance, Chethan Kumar -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Monday, May 20, 2019 7:35 PM To: openssl-users at openssl.org Subject: RE: To get end point's IP address > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Chethan Kumar > Sent: Monday, May 20, 2019 04:22 > I wanted to log end point's IP address during some errors in > communication using openssl. > Initially when I tried getpeername() on SSL context, its giving proxy > server's IP and not destination IP. The proxy server address *is* the peer address. Proxies terminate TLS conversations. The client has a TLS conversation with the proxy, and the proxy may have a separate TLS conversation with the origin server. (Or with whatever the next application-level node in the chain is; there can be multiple proxies, gateways, etc.) If it didn't do TLS termination, it wouldn't be a proxy, but a router. If you have a node that's doing routing at level 4 (copying data between two TCP connections) but not doing TLS termination, there's no way to get the IP addresses of the endpoints of the other connection from the stack. That information has to be provided at the application level. (Techincal quibble: "Level 4 routing" is a somewhat dubious concept in TCP/IP, since TCP straddles OSI levels 4 and 5. But applications which forward data between TCP conversations are traditionally connsidered level-4 routers. Also, note some level-4 routing packages do TLS termination - stunnel in its base mode is an example. A level-4 router may or may not do TLS termination.) -- Michael Wojcik Distinguished Engineer, Micro Focus The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. From karl at denninger.net Tue May 21 11:30:59 2019 From: karl at denninger.net (Karl Denninger) Date: Tue, 21 May 2019 06:30:59 -0500 Subject: To get end point's IP address In-Reply-To: <447C096A3E2889439233CDD6DAB29F95BF3CB52E@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB2DF@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95BF3CB52E@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: On 5/21/2019 4:53 AM, Chethan Kumar wrote: > Thanks for the information. > > I researched more and found that tlsext_hostname member variable in SSL structure can be used to to get host name. > If applications set this using SSL_set_tlsext_host_name(), is it correct to print hostname/IP in tlsext_hostname. > Can I use this one to set hostname/Ip address.? > Can applications acting as both server and client set this? > > Thanks in advance, > Chethan Kumar > Why do you want the specific IP address?? If the other end is behind a NAT device or similar (or a full-blown proxy) then that address is not meaningful in the context of actual identification as to the source of the communication. Better, if it is necessary to know who you're talking to, is for the client to present a certificate which the server can then verify as to validity and provenance; the client, of course, by definition has same capability against the server so it can verify that the server it thinks it is talking to is actually the one it's communicating with. -- -- Karl Denninger /The Market-Ticker/ S/MIME Email accepted and preferred -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: From lersek at redhat.com Tue May 21 14:15:20 2019 From: lersek at redhat.com (Laszlo Ersek) Date: Tue, 21 May 2019 16:15:20 +0200 Subject: why does RAND_add() take "randomness" as a "double"? Message-ID: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> (resending, with my subscription to completed) Hi OpenSSL Developers, (cross-posting and ,) OpenSSL commit [1] changed the representation of the "entropy amount" -- later renamed to "randomess" in [2] -- from "int" to "double". I've read the commit message: commit 853f757ecea74a271a7c5cdee3f3b5fe0d3ae863 Author: Bodo M?ller Date: Sat Feb 19 15:22:53 2000 +0000 Allow for higher granularity of entropy estimates by using 'double' instead of 'unsigned' counters. Seed PRNG in MacOS/GetHTTPS.src/GetHTTPS.cpp. Partially submitted by Yoram Meroz . and also checked "MacOS/GetHTTPS.src/GetHTTPS.cpp" at the same commit. But, I'm none the wiser. Can someone please explain what is gained by using a floating point type here? Is it really a relevant use case that entropy is fed from an external source to OpenSSL such that truncating the amount to a whole number of bits would cause significant lossage? (Admittedly, it could be relevant if the individual randomness bit counts were in the (0, 1) interval, both boundaries exclusive.) Using floating point for randomness representation is a problem for environments that prefer to avoid floating point altogether, such as edk2 ("UEFI") firmware Thanks, Laszlo [1] https://github.com/openssl/openssl/commit/853f757ecea7 [2] https://github.com/openssl/openssl/commit/f367ac2b2664 From kgoldman at us.ibm.com Tue May 21 14:42:09 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 21 May 2019 10:42:09 -0400 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> Message-ID: On 5/21/2019 10:15 AM, Laszlo Ersek wrote: >[snip] > > Can someone please explain what is gained by using a floating point type > here? > > Is it really a relevant use case that entropy is fed from an external > source to OpenSSL such that truncating the amount to a whole number of > bits would cause significant lossage? (Admittedly, it could be relevant > if the individual randomness bit counts were in the (0, 1) interval, > both boundaries exclusive.) > > Using floating point for randomness representation is a problem for > environments that prefer to avoid floating point altogether, such as > edk2 ("UEFI") firmware I agree, and I reported this back in 2016. We also have an environment that does not have floating point. From rsalz at akamai.com Tue May 21 14:44:39 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 21 May 2019 14:44:39 +0000 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> Message-ID: <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> When I overhauled the RAND mechanism, I tried to deprecate this use of floating point, in favor of just a number from 0 to 100 but was voted down. It *is* stupid. Luckily, on a modern system with system-provided randomness to seed the RNG, you never need this call. From Michael.Wojcik at microfocus.com Tue May 21 15:00:19 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 21 May 2019 15:00:19 +0000 Subject: To get end point's IP address In-Reply-To: <447C096A3E2889439233CDD6DAB29F95BF3CB52E@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB2DF@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95BF3CB52E@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: > From: Chethan Kumar [mailto:Chethan.Kumar at toshiba-tsip.com] > Sent: Tuesday, May 21, 2019 03:53 > > I researched more and found that tlsext_hostname member variable in SSL > structure can be used to to get host name. That's the SNI hostname, which is set by the client to the hostname (or possibly some other string identifier, such as the text representation of an IP address) that it thinks it wants to connect to. It's used by the server to determine what certificate to send to the client. It's not a reliable indicator of the server's hostname, and has nothing to do with the client's hostname. > If applications set this using SSL_set_tlsext_host_name(), is it correct to > print hostname/IP in tlsext_hostname. "correct" in what sense? "print" where? Forget OpenSSL APIs and details of OpenSSL data structures. What problem are you trying to solve? > Can I use this one to set hostname/Ip address.? Maybe. You haven't explained what you're trying to do. > Can applications acting as both server and client set this? It's set by a client. It doesn't matter what else that client is doing. -- Michael Wojcik Distinguished Engineer, Micro Focus From rsalz at akamai.com Tue May 21 15:27:44 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 21 May 2019 15:27:44 +0000 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> Message-ID: <87DEBC53-7932-49AB-A738-E01D531DBA5F@akamai.com> > If it's a sarcasm, I'm missing the point. I was't being sarcastic, I was trying to show that the team, recently, still liked the use of floating point. > There are use cases when one wants to mix/add extra randomness from, e.g., an external source (that, for whatever reasons, is trusted more than what's provided by the system). Then just set it to 1.0 and be done with it. From matt at openssl.org Tue May 21 15:43:34 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 May 2019 16:43:34 +0100 Subject: Forthcoming OpenSSL Releases Message-ID: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org> The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s. These releases will be made available on 28th May 2019 between approximately 1200-1600 UTC. OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant). 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 uri at ll.mit.edu Tue May 21 15:14:36 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 21 May 2019 15:14:36 +0000 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> Message-ID: On 5/21/19, 10:45 AM, "openssl-users on behalf of Salz, Rich via openssl-users" wrote: When I overhauled the RAND mechanism, I tried to deprecate this use of floating point, in favor of just a number from 0 to 100 but was voted down. If it's a sarcasm, I'm missing the point. It *is* stupid. In general, yes, it is. Luckily, on a modern system with system-provided randomness to seed the RNG, you never need this call. Respectfully disagree. There are use cases when one wants to mix/add extra randomness from, e.g., an external source (that, for whatever reasons, is trusted more than what's provided by the system). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5229 bytes Desc: not available URL: From dclarke at blastwave.org Tue May 21 15:51:57 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 21 May 2019 15:51:57 +0000 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <87DEBC53-7932-49AB-A738-E01D531DBA5F@akamai.com> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> <87DEBC53-7932-49AB-A738-E01D531DBA5F@akamai.com> Message-ID: <74c7f176-b7da-0cae-28c8-d1a1825ac9d0@blastwave.org> On 5/21/19 3:27 PM, Salz, Rich via openssl-users wrote: >> If it's a sarcasm, I'm missing the point. > > I was't being sarcastic, I was trying to show that the team, recently, still liked the use of floating point. > >> There are use cases when one wants to mix/add extra randomness from, e.g., an external source (that, for whatever reasons, is trusted more than what's provided by the system). > > Then just set it to 1.0 and be done with it. > External 300 baud serial attached coin flipper also works well. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From matt at openssl.org Tue May 21 15:43:34 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 May 2019 16:43:34 +0100 Subject: Forthcoming OpenSSL Releases Message-ID: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org> The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s. These releases will be made available on 28th May 2019 between approximately 1200-1600 UTC. OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant). 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 matt at openssl.org Tue May 21 15:43:34 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 May 2019 16:43:34 +0100 Subject: Forthcoming OpenSSL Releases Message-ID: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org> The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s. These releases will be made available on 28th May 2019 between approximately 1200-1600 UTC. OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant). 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 paul.dale at oracle.com Wed May 22 01:48:14 2019 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 22 May 2019 01:48:14 +0000 (UTC) Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> Message-ID: <06ce80d4-02da-4323-af3b-0d0f8be3f6eb@default> Double makes sense. Entropy is often estimated as a real value. E.g. we have the aforementioned coin flipper feeding data serially. Adding each bit sequentially means 0.125 bytes of entropy per call. Not the best example.... Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Laszlo Ersek [mailto:lersek at redhat.com] Sent: Wednesday, 22 May 2019 12:15 AM To: openssl-users at openssl.org Cc: Jian J Wang ; edk2-devel-groups-io ; Lu, XiaoyuX ; Ard Biesheuvel Subject: why does RAND_add() take "randomness" as a "double"? (resending, with my subscription to completed) Hi OpenSSL Developers, (cross-posting and ,) OpenSSL commit [1] changed the representation of the "entropy amount" -- later renamed to "randomess" in [2] -- from "int" to "double". I've read the commit message: commit 853f757ecea74a271a7c5cdee3f3b5fe0d3ae863 Author: Bodo M?ller Date: Sat Feb 19 15:22:53 2000 +0000 Allow for higher granularity of entropy estimates by using 'double' instead of 'unsigned' counters. Seed PRNG in MacOS/GetHTTPS.src/GetHTTPS.cpp. Partially submitted by Yoram Meroz . and also checked "MacOS/GetHTTPS.src/GetHTTPS.cpp" at the same commit. But, I'm none the wiser. Can someone please explain what is gained by using a floating point type here? Is it really a relevant use case that entropy is fed from an external source to OpenSSL such that truncating the amount to a whole number of bits would cause significant lossage? (Admittedly, it could be relevant if the individual randomness bit counts were in the (0, 1) interval, both boundaries exclusive.) Using floating point for randomness representation is a problem for environments that prefer to avoid floating point altogether, such as edk2 ("UEFI") firmware Thanks, Laszlo [1] https://github.com/openssl/openssl/commit/853f757ecea7 [2] https://github.com/openssl/openssl/commit/f367ac2b2664 From levitte at openssl.org Wed May 22 01:58:17 2019 From: levitte at openssl.org (Richard Levitte) Date: Wed, 22 May 2019 03:58:17 +0200 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <87DEBC53-7932-49AB-A738-E01D531DBA5F@akamai.com> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> <87DEBC53-7932-49AB-A738-E01D531DBA5F@akamai.com> Message-ID: "Salz, Rich via openssl-users" skrev: (21 maj 2019 17:27:44 CEST) >> If it's a sarcasm, I'm missing the point. > >I was't being sarcastic, I was trying to show that the team, recently, >still liked the use of floating point. > >> There are use cases when one wants to mix/add extra randomness >from, e.g., an external source (that, for whatever reasons, is trusted >more than what's provided by the system). > >Then just set it to 1.0 and be done with it. That hardly helps on systems that don't have floating point at all. Cheers Richard > > > -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From rsalz at akamai.com Wed May 22 02:07:28 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 22 May 2019 02:07:28 +0000 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> <87DEBC53-7932-49AB-A738-E01D531DBA5F@akamai.com> Message-ID: <971459BD-B4E7-46A6-A2C8-0CD68A7BC9D8@akamai.com> >Then just set it to 1.0 and be done with it. > That hardly helps on systems that don't have floating point at all. No it doesn't. Such systems aren't supported by OpenSSL. There are many places were floating point is used/supported. Removing the second arg to RAND_add is the least of the problems (look at various asm files) From Chethan.Kumar at toshiba-tsip.com Wed May 22 06:05:18 2019 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Wed, 22 May 2019 06:05:18 +0000 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 Message-ID: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> Dear all, While migrating from openssl 1.0.2n to openssl 1.1.1b, application which uses openssl was compiling against openssl 1.1.1b. Compilation is fine but its linking to both libcrypto.so.1.0.0[from /usr/lib/] and libcrypto.so.1.1. Its linking correctly to libssl.1.1. Is this correct? If so, what could be the possible reason. Thanks in advance, Chethan Kumar The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chethan.Kumar at toshiba-tsip.com Wed May 22 08:41:23 2019 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Wed, 22 May 2019 08:41:23 +0000 Subject: To get end point's IP address In-Reply-To: References: <447C096A3E2889439233CDD6DAB29F95BF3CB2DF@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95BF3CB52E@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: <447C096A3E2889439233CDD6DAB29F95BF3CB8DE@tosblrmbx04.TOSHIBA-TSIP.COM> Thanks for the input. >> If applications set this using SSL_set_tlsext_host_name(), is it >> correct to print hostname/IP in tlsext_hostname. >"correct" in what sense? "print" where? > Maybe. You haven't explained what you're trying to do. What we are trying to achieve is, if there is failure in connection between host and destination, then at the host side, log messages saying to which destination it got failed. That's why, need to know the hostname/IP address of the destination. Since many applications use openssl, we want to log messages from openssl side. Is it ok if application set IP/hostname using SSL_set_tlsext_host_name() and at openssl side, we refer tlsext_hostname to log the message.? Thanks in advance, Chethan Kumar -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Tuesday, May 21, 2019 8:30 PM To: openssl-users at openssl.org Subject: RE: To get end point's IP address > From: Chethan Kumar [mailto:Chethan.Kumar at toshiba-tsip.com] > Sent: Tuesday, May 21, 2019 03:53 > > I researched more and found that tlsext_hostname member variable in > SSL structure can be used to to get host name. That's the SNI hostname, which is set by the client to the hostname (or possibly some other string identifier, such as the text representation of an IP address) that it thinks it wants to connect to. It's used by the server to determine what certificate to send to the client. It's not a reliable indicator of the server's hostname, and has nothing to do with the client's hostname. > If applications set this using SSL_set_tlsext_host_name(), is it > correct to print hostname/IP in tlsext_hostname. "correct" in what sense? "print" where? Forget OpenSSL APIs and details of OpenSSL data structures. What problem are you trying to solve? > Can I use this one to set hostname/Ip address.? Maybe. You haven't explained what you're trying to do. > Can applications acting as both server and client set this? It's set by a client. It doesn't matter what else that client is doing. -- Michael Wojcik Distinguished Engineer, Micro Focus The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. From Pcraghavendra.Prasad at dell.com Wed May 22 09:16:37 2019 From: Pcraghavendra.Prasad at dell.com (Pcraghavendra.Prasad at dell.com) Date: Wed, 22 May 2019 09:16:37 +0000 Subject: Help Message-ID: Hi Team, Need help on the openssl library. We want to upgrade the openssl to the latest version available 1.1.1b. We are using SLES 10 SP2 build box where we need to upgrade, but when we try to upgrade it is throwing not supported error. >>>>openssl-1.1.1b # ./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl shared Operating system: x86_64-whatever-linux2 Perl v5.10.0 required--this is only v5.8.8, stopped at ./Configure line 12. BEGIN failed--compilation aborted at ./Configure line 12. Perl v5.10.0 required--this is only v5.8.8, stopped at ./Configure line 12. BEGIN failed--compilation aborted at ./Configure line 12. This system (linux-x86_64) is not supported. See file INSTALL for details. Could you please help us what is the best version that can be installed on the SLES 10 OS. Thanks, Raghavendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From public at enkore.de Wed May 22 10:35:08 2019 From: public at enkore.de (Marian Beermann) Date: Wed, 22 May 2019 12:35:08 +0200 Subject: Help In-Reply-To: References: Message-ID: <7f2c9cc4-9fbc-22f6-150e-065aaaa75ad5@enkore.de> SLES 10 is 13 years old and stopped receiving (security) updates three years ago. The best course of action here is to upgrade the operating system. -Marian Am 22.05.19 um 11:16 schrieb Pcraghavendra.Prasad at dell.com: > Hi Team, > > ? > > Need help on the openssl library. > > We want to upgrade the openssl to the latest version available 1.1.1b. > > We are using SLES 10 SP2 build box where we need to upgrade, but when we > try to upgrade it is throwing not supported error. > > ? > >>>>>openssl-1.1.1b # ./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl shared > > Operating system: x86_64-whatever-linux2 > > Perl v5.10.0 required--this is only v5.8.8, stopped at ./Configure line 12. > > BEGIN failed--compilation aborted at ./Configure line 12. > > Perl v5.10.0 required--this is only v5.8.8, stopped at ./Configure line 12. > > BEGIN failed--compilation aborted at ./Configure line 12. > > This system (linux-x86_64) is not supported. See file INSTALL for details. > > ? > > Could you please help us what is the best version that can be installed > on the SLES 10 OS. > > ? > > Thanks, > > Raghavendra > > ? > From kgoldman at us.ibm.com Wed May 22 13:31:29 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 22 May 2019 09:31:29 -0400 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <971459BD-B4E7-46A6-A2C8-0CD68A7BC9D8@akamai.com> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> <87DEBC53-7932-49AB-A738-E01D531DBA5F@akamai.com> <971459BD-B4E7-46A6-A2C8-0CD68A7BC9D8@akamai.com> Message-ID: On 5/21/2019 10:07 PM, Salz, Rich via openssl-users wrote: > >Then just set it to 1.0 and be done with it. > >> That hardly helps on systems that don't have floating point at all. > > No it doesn't. Such systems aren't supported by OpenSSL. There are many places were floating point is used/supported. > Removing the second arg to RAND_add is the least of the problems (look at various asm files) The assembler code can be bypassed on those systems. I see a few places where it's used to force an alignment, but perhaps there's another way. It's used in test programs to report performance. For us, the random number generator was the problem. From kgoldman at us.ibm.com Wed May 22 14:12:01 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 22 May 2019 10:12:01 -0400 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <06ce80d4-02da-4323-af3b-0d0f8be3f6eb@default> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <06ce80d4-02da-4323-af3b-0d0f8be3f6eb@default> Message-ID: On 5/21/2019 9:48 PM, Paul Dale wrote: > Double makes sense. Entropy is often estimated as a real value. > Having a human readable calculation using floating point doesn't (to me) mean that an API argument has to be a double. From what I see in the code, the parameter 'double entropy' is used to increment a value that eventually reaches # define ENTROPY_NEEDED 32. Couldn't the number have been an unsigned long? If more precision was needed, make the units 1/64k and make ENTROPY_NEEDED 32 * 64k. It's a bit more work for the caller, but removes the (perhaps only) place floating point is needed. From jb-openssl at wisemo.com Wed May 22 15:03:14 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 May 2019 17:03:14 +0200 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> Message-ID: <09218318-7e8e-9272-4098-1bf82e1ab5b7@wisemo.com> On 21/05/2019 16:44, Salz, Rich via openssl-users wrote: > When I overhauled the RAND mechanism, I tried to deprecate this use of floating point, in favor of just a number from 0 to 100 but was voted down. > > It *is* stupid. Luckily, on a modern system with system-provided randomness to seed the RNG, you never need this call. > > Perhaps it would have been more acceptable to use a binary base, instead of a decimal percentage, as there is nothing inherently decimal about this value. Good options inspired by other cryptographic libraries include: - Number of bits of entropy passed in call (For example, a ?perfectly balanced coin flipper could provide the 4 byte ?values "head" or "tail" with an entropy of 1 bit). - 256th of bits ditto (for example a coin flipper with a known ?slight imbalance could report 252/256th of a bit for each flip ?included in the buffer). - 32th of bits ditto (makes the "100%" case equal to ?(bytecount << 8)). In each of those 3 cases, the internal measure of "entropy left" would be in that same unit, and a compatibility mapping for the old API would do the conversion of the double as a pure inline macro that doesn't trigger "float used" compiler magics in programs that don't use it. Clarifying notes: - The current limit of considering only 32 bytes of entropy ?is an artifact of the current set of RNG algorithms, and ?should not be exposed in the API design.? For example ?future addition of post-quantum algorithms may necessitate ?having an RNG with an internal state entropy larger than ?256 bits. - Future RNG implementations may include logic to safely ?accumulate obtained entropy into "batches" before updating ?the RNG state, as this may have cryptographic benefits. - The use of a dummy double to force the alignment of ?structures and unions to the "highest known" value can ?be trivially replaced by another type where it is not ?already treated as "not actually floating point ?operations" by the compiler.? For example by passing ?"-Ddouble=long long" as a compiler option. - The use of floating point registers in CPU-specific ?vector unit optimizations can be readily avoided by ?a no-asm compile. - Floating point calculations in test programs such as ?"openssl speed" is not relevant to actual library use. - On Linux x86, test programs that avoid all floating ?point can be checked via the PF_USED_MATH flag or its ?upcoming Linux 5.x replacement.? This may be useful ?in the test suite. 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 Michael.Wojcik at microfocus.com Wed May 22 16:57:57 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 22 May 2019 16:57:57 +0000 Subject: To get end point's IP address In-Reply-To: <447C096A3E2889439233CDD6DAB29F95BF3CB8DE@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB2DF@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95BF3CB52E@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95BF3CB8DE@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: > From: Chethan Kumar [mailto:Chethan.Kumar at toshiba-tsip.com] > Sent: Wednesday, May 22, 2019 02:41 > > What we are trying to achieve is, if there is failure in connection between > host and destination, then at the host side, log messages saying to which > destination it got failed. So if the connection fails, you want the client program to be able to log some identifier for the server it's trying to connect to. > That's why, need to know the hostname/IP address of the destination. > Since many applications use openssl, we want to log messages from openssl > side. > Is it ok if application set IP/hostname using SSL_set_tlsext_host_name() and > at openssl side, we refer tlsext_hostname to log the message.? Issues with that: - It assumes the client passes the correct hostname[1] to SSL_set_tlsext_host_name(). - It assumes name resolution (usually DNS) is correct and uncompromised. The client may think it's connecting to foo.bar.baz, and call SSL_set_tlsext_host_name("foo.bar.baz"), but actually get the address for some other system from DNS. Then the connection-failure message will report an error connecting to foo.bar.baz when the problem is on some other system. - Following from the previous item, ideally you want the message to report both the desired host and the address you were trying to connect to. - I don't believe there's an accessor function for SSL_set_tlsext_host_name (i.e. SSL_get0_tlsext_host_name or similar), and accessing fields of the OpenSSL structs directly is a Bad Idea. It may cause build-time issues with later OpenSSL releases, and if you load OpenSSL dynamically (i.e. build as a shared object / DLL), you could even break existing applications by dropping in a build of a later OpenSSL release. Accessing struct fields is excessive coupling. The right way to do this is at the application level. The application knows which host it wanted to contact, and what address it found for that host, and precisely what failure it experienced. [1] There are cases where a client would pass an IP address (as a string) to SSL_set_tlsext_host_name(). Specifically, if a user specifies an IP address when telling a client to connect to a server, the client *should not* attempt reverse name resolution on that address; it should use the address literally for SNI and when comparing against SANs in the server entity certificate. (In theory it should look for IP SANs in that case, though I've seen clients that will also accept the string form of the address in a DNS SAN.) This usage is rare. -- Michael Wojcik Distinguished Engineer, Micro Focus From Matthias.St.Pierre at ncp-e.com Wed May 22 17:10:12 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 22 May 2019 17:10:12 +0000 Subject: AW: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <09218318-7e8e-9272-4098-1bf82e1ab5b7@wisemo.com> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> <09218318-7e8e-9272-4098-1bf82e1ab5b7@wisemo.com> Message-ID: <742a929a825c4c3a8a1e66b88c8d7505@Ex13.ncp.local> I think nobody of us needs to be convinced anymore that making it a 'double' was a bad idea. But the RAND api is very ancient and changing the argument type would be a breaking change. That's why we didn't dare to touch it when we overhauled the RNG implementation for 1.1.1, because we tried very hard not to add unnecessary breaking changes to the ones made in 1.1.0. Matthias From uri at ll.mit.edu Wed May 22 17:17:03 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 22 May 2019 17:17:03 +0000 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <742a929a825c4c3a8a1e66b88c8d7505@Ex13.ncp.local> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> <09218318-7e8e-9272-4098-1bf82e1ab5b7@wisemo.com> <742a929a825c4c3a8a1e66b88c8d7505@Ex13.ncp.local> Message-ID: <7FB59C90-93FC-4E50-9691-9B8699B1BFDF@ll.mit.edu> I can understand why you may not want to break existing API. Why not add another similar interface done the right way? ?On 5/22/19, 1:11 PM, "openssl-users on behalf of Dr. Matthias St. Pierre" wrote: I think nobody of us needs to be convinced anymore that making it a 'double' was a bad idea. But the RAND api is very ancient and changing the argument type would be a breaking change. That's why we didn't dare to touch it when we overhauled the RNG implementation for 1.1.1, because we tried very hard not to add unnecessary breaking changes to the ones made in 1.1.0. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5229 bytes Desc: not available URL: From dclarke at blastwave.org Wed May 22 17:32:51 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 22 May 2019 13:32:51 -0400 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <09218318-7e8e-9272-4098-1bf82e1ab5b7@wisemo.com> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> <09218318-7e8e-9272-4098-1bf82e1ab5b7@wisemo.com> Message-ID: <94332d66-b67f-bdef-347d-452da115d035@blastwave.org> > Good options inspired by other cryptographic libraries include: > > - Number of bits of entropy passed in call (For example, a > ?perfectly balanced coin flipper could provide the 4 byte > ?values "head" or "tail" with an entropy of 1 bit). Let's drop the coin flipper. It was an off hand remark and by now we all know there ain't no such thing as a good coin flip for rng. See Professor Persi Diaconis at Stanford for that : https://www.youtube.com/watch?v=AYnJv68T3MM Bell's theorem and kolmogorov aside get a radiation decay source as that is really the *only* real rng that we know of. Or that I know of. http://www.fourmilab.ch/hotbits/hardware.html -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ps: see "futility of foresight" From jb-openssl at wisemo.com Wed May 22 23:10:00 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 23 May 2019 01:10:00 +0200 Subject: why does RAND_add() take "randomness" as a "double"? In-Reply-To: <94332d66-b67f-bdef-347d-452da115d035@blastwave.org> References: <6c4a456a-3198-bfa2-6d89-433e4d3f3fd5@redhat.com> <2493E601-0591-4B6C-A291-980BC8A9C3CE@akamai.com> <09218318-7e8e-9272-4098-1bf82e1ab5b7@wisemo.com> <94332d66-b67f-bdef-347d-452da115d035@blastwave.org> Message-ID: On 22/05/2019 19:32, Dennis Clarke wrote: > >> Good options inspired by other cryptographic libraries include: >> >> - Number of bits of entropy passed in call (For example, a >> ??perfectly balanced coin flipper could provide the 4 byte >> ??values "head" or "tail" with an entropy of 1 bit). > > Let's drop the coin flipper. It was an off hand remark and by now we > all know there ain't no such thing as a good coin flip for rng. > > ??? See Professor Persi Diaconis at Stanford for that : > ??????? https://www.youtube.com/watch?v=AYnJv68T3MM > > Bell's theorem and kolmogorov aside get a radiation decay source as > that is really the *only* real rng that we know of. > Or that I know of.?? http://www.fourmilab.ch/hotbits/hardware.html The coin flipper, even if theoretically problematic, is the standard statistical example used to describe a 1-bit-at-a-time hardware RNG. It includes a nice conceptual model to discuss hardware bias (using Shannon's entropy formula etc.).? Actual 1-bit sources include the classic semiconductor shot noise fed to a comparator and some primitive implementations of radioactive RNGs. Also, radioactive sources are an unacceptable danger in many of the embedded and portable applications most likely to lack floating point support. 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 raveendra.padasalagi at broadcom.com Thu May 23 06:26:43 2019 From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi) Date: Thu, 23 May 2019 11:56:43 +0530 Subject: Compiling openssl executable as static binary Message-ID: <3c8207b26cff7a51109bb04f0700aab8@mail.gmail.com> Hi, Any help/pointers on compiling openssl library to generate static version of openssl executable for ARM64 bit linux platform will help. Thanks, Raveendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu May 23 06:40:00 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 23 May 2019 16:40:00 +1000 Subject: Compiling openssl executable as static binary In-Reply-To: <3c8207b26cff7a51109bb04f0700aab8@mail.gmail.com> References: <3c8207b26cff7a51109bb04f0700aab8@mail.gmail.com> Message-ID: <920CB80A-FE68-4171-9D1A-90BFB3A6D859@oracle.com> Link against the generated .a files rather than the .so ones? Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 23 May 2019, at 4:26 pm, Raveendra Padasalagi via openssl-users wrote: > > Hi, > > Any help/pointers on compiling openssl library to generate static version of openssl executable for ARM64 bit linux platform will help. > > Thanks, > Raveendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From raveendra.padasalagi at broadcom.com Thu May 23 06:47:09 2019 From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi) Date: Thu, 23 May 2019 12:17:09 +0530 Subject: Compiling openssl executable as static binary In-Reply-To: <920CB80A-FE68-4171-9D1A-90BFB3A6D859@oracle.com> References: <3c8207b26cff7a51109bb04f0700aab8@mail.gmail.com> <920CB80A-FE68-4171-9D1A-90BFB3A6D859@oracle.com> Message-ID: <3be029c1a7df5bfb0ed87de9afd4f04e@mail.gmail.com> Yes Paul. I tried following steps: export INSTALLDIR=/tmp/openssl_arm export OPENSSLDIR=/tmp/openssl_arm export PATH=$INSTALLDIR/bin:$PATH export CROSS=aarch64-linux-gnu export CC=${CROSS}-gcc export LD=${CROSS}-ld export AS=${CROSS}-as export AR=${CROSS}-ar export AR=${CROSS}-ar ./Configure linux-arm64 *no-shared* make make install Thanks, Raveendra *From:* Dr Paul Dale [mailto:paul.dale at oracle.com] *Sent:* Thursday, May 23, 2019 12:10 PM *To:* Raveendra Padasalagi *Cc:* openssl-users at openssl.org *Subject:* Re: Compiling openssl executable as static binary Link against the generated .a files rather than the .so ones? Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia On 23 May 2019, at 4:26 pm, Raveendra Padasalagi via openssl-users < openssl-users at openssl.org> wrote: Hi, Any help/pointers on compiling openssl library to generate static version of openssl executable for ARM64 bit linux platform will help. Thanks, Raveendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedroterrosolopes at gmail.com Thu May 23 10:58:49 2019 From: pedroterrosolopes at gmail.com (Pedro Lopes) Date: Thu, 23 May 2019 11:58:49 +0100 Subject: Opaque structures - Cant access buf_len variable from evp_cipher_ctx_st Message-ID: Good morning, I'd like to know how to get buffer length from cipher structures since 1.1 version. I'm using that variable member to know what should be the required length if something gets wrong and return to the caller. Snippet of my source code: DecryptUpdate(unsigned char* pEncryptedPart, unsigned long int ulEncryptedPartLen, unsigned char* pPart, unsigned long int *pulPartLen){ unsigned long required_rest = (ctx.buf_len + ulEncryptedPartLen) % EVP_CIPHER_block_size(mCipher); unsigned long required_len = ctx.buf_len + ulEncryptedPartLen - required_rest; if (pPart == NULL_PTR || *pulPartLen < required_len) { *pulPartLen = required_len; return pPart == NULL_PTR ? CKR_OK : CKR_BUFFER_TOO_SMALL; } ... } -- Kind Regards, Pedro Lopes -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu May 23 13:06:32 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 23 May 2019 15:06:32 +0200 Subject: Compiling openssl executable as static binary In-Reply-To: <3c8207b26cff7a51109bb04f0700aab8@mail.gmail.com> References: <3c8207b26cff7a51109bb04f0700aab8@mail.gmail.com> Message-ID: <87y32x1fs7.wl-levitte@openssl.org> How static do you want it to be? There is the configuration option '-static' that makes the binary as independent as possible, i.e. even links it with static libc. Cheers, Richard On Thu, 23 May 2019 08:26:43 +0200, Raveendra Padasalagi via openssl-users wrote: > > > Hi, > > ? > > Any help/pointers on compiling openssl library to generate static version of openssl executable > for ARM64 bit linux platform will help. > > ? > > Thanks, > > Raveendra > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From raveendra.padasalagi at broadcom.com Thu May 23 16:39:15 2019 From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi) Date: Thu, 23 May 2019 22:09:15 +0530 Subject: Compiling openssl executable as static binary In-Reply-To: <87y32x1fs7.wl-levitte@openssl.org> References: <3c8207b26cff7a51109bb04f0700aab8@mail.gmail.com> <87y32x1fs7.wl-levitte@openssl.org> Message-ID: Thanks Richard, this is what I was expecting. It worked. Configure script is not showing this option. Configuring OpenSSL version 3.0.0-dev for target Using os-specific seed configuration Usage: Configure [no- ...] [enable- ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-egd] [sctp] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--config=FILE] os/compiler[:flags] Regards, Raveendra On Thu, May 23, 2019 at 6:36 PM Richard Levitte wrote: > How static do you want it to be? There is the configuration option > '-static' that makes the binary as independent as possible, i.e. even > links it with static libc. > > Cheers, > Richard > > On Thu, 23 May 2019 08:26:43 +0200, > Raveendra Padasalagi via openssl-users wrote: > > > > > > Hi, > > > > > > > > Any help/pointers on compiling openssl library to generate static > version of openssl executable > > for ARM64 bit linux platform will help. > > > > > > > > Thanks, > > > > Raveendra > > > > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eng.mahmoudhafeez911 at gmail.com Fri May 24 03:25:12 2019 From: eng.mahmoudhafeez911 at gmail.com (Mahmoud Abd El-Hafeez) Date: Fri, 24 May 2019 05:25:12 +0200 Subject: Using openssl with embedded systems Message-ID: Greetings, I wonder if it's possible to compile the library for Microcontrollers like ARM STM32 The situation is: I have some project written c code that depends on OpenSSL library functionality. The project assumes that OpenSSL is installed on the machine. I want to cross compile the project for some microcontroller architecture like mentioned above. Is there a way to: 1- Compile the OpenSSL library to produce the .a files using the microcontroller special compiler like GNU for ARM? Or 2- Include all the library source files and headers to be compiled with the project using the microcontroller special compiler? Is there a way to handle the opensslconf.h and bn.h for the microcontroller's compiler and architecture? Please accept my apologize if questions are not eligible or not in the right place. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri May 24 12:23:58 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 24 May 2019 14:23:58 +0200 Subject: Fw:Re:Re: Building openssl outside of the source tree" doesn't work well In-Reply-To: <57ab2aa5.289c.16ae7ba5c96.Coremail.dengwenbin_0301@126.com> References: <57ab2aa5.289c.16ae7ba5c96.Coremail.dengwenbin_0301@126.com> Message-ID: <87r28o11nl.wl-levitte@openssl.org> Well, those -I options are directly generated from 'INCLUDE' statements in build.info files. Would you mind giving me the output from this command? perl configdata.pm --dump Cheers, Richard On Fri, 24 May 2019 04:45:11 +0200, dengwenbin_0301 wrote: > > > I tried on openssl-1.1.1a and openssl-1.1.1b and they all have the same issue. I think it has > something to do with my env. But i am not able to figure out what is the cause. > > Thanks, > Wenbin > > -------- Forwarding messages -------- > From: "dengwenbin_0301" > Date: 2019-05-22 09:40:19 > To: "Richard Levitte" > Subject: Re:Re: Building openssl outside of the source tree" doesn't work well > Thanks for your reply, Richard. > > Yes, the "-Iinclude -Iapps/include" is missing. I don't know why this happened. I attached the > the configdata.pm and its dump. Please help have a check. > > wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ git log -n 1 > commit d3136af3c3905a730bd8fb44158aab36a2549d9b > Author: Richard Levitte > Date: Sat May 18 16:24:21 2019 -0700 > > Configure: let platform->dsoext() default with platform->shlibextsimple() > > We still use '.so' as a last resort... > > Fixes #8950 > > Reviewed-by: Tim Hudson > (Merged from https://github.com/openssl/openssl/pull/8951) > > At 2019-05-21 11:47:14, "Richard Levitte" wrote: > >On Tue, 21 May 2019 03:26:41 +0200, > >dengwenbin_0301 wrote: > >> > >> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl [master]$ cd obj/ > >> > >> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ ../config > >> Operating system: x86_64-whatever-linux2 > >> Configuring OpenSSL version 3.0.0-dev for target linux-x86_64 > >> Using os-specific seed configuration > >> Creating configdata.pm > >> Creating Makefile > >> > >> ********************************************************************** > >> *** *** > >> *** OpenSSL has been successfully configured *** > >> *** *** > >> *** If you encounter a problem while building, please open an *** > >> *** issue on GitHub ; *** > >> *** and include the output from the following command: *** > >> *** *** > >> *** perl configdata.pm --dump *** > >> *** *** > >> *** (If you are new to OpenSSL, you might want to consult the *** > >> *** 'Troubleshooting' section in the INSTALL file first) *** > >> *** *** > >> ********************************************************************** > >> wdeng:~/wenbindfiles/openssl/openssl/obj [master]$ make > >> make depend && make _all > >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' > >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' > >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' > >> gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN > >> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > >> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM > >> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM > >> -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr > >> /local/lib/ossl-modules\"" -DNDEBUG -MMD -MF apps/libapps-lib-app_rand.d.tmp -MT apps/ > >> libapps-lib-app_rand.o -c -o apps/libapps-lib-app_rand.o ../apps/app_rand.c > >> ../apps/app_rand.c:10:18: fatal error: apps.h: No such file or directory > >> compilation terminated. > >> Makefile:826: recipe for target 'apps/libapps-lib-app_rand.o' failed > >> make[1]: *** [apps/libapps-lib-app_rand.o] Error 1 > >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' > >> Makefile:165: recipe for target 'all' failed > >> make: *** [all] Error 2 > > > >I tried exactly that just now, exactly same 'obj' ubdirectory, and it > >works with no problem. > > > >Something I'm noticing from your command line is that all -I options > >that I expect to see there are gone. This is what I expect (note that > >I go directly at the object file for demonstration purposes): > > > > : ; make apps/libapps-lib-app_rand.o > > gcc -I. -Iinclude -Iapps/include -I.. -I../include > > -I../apps/include -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 > > -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC > > -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM > > -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM > > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > > -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" > > -DENGINESDIR="\"/usr/local/lib/engines-3\"" > > -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG -MMD -MF > > apps/libapps-lib-app_rand.d.tmp -MT apps/libapps-lib-app_rand.o -c > > -o apps/libapps-lib-app_rand.o ../apps/app_rand.c > > > >So the question is what happened to '-I. -Iinclude -Iapps/include > >-I.. -I../include -I../apps/include' in your build. > > > >I cannot say right now, but it might help if you show the output from > >'./configdata.pm --dump' > > > >Cheers, > >Richard > > > >-- > >Richard Levitte levitte at openssl.org > >OpenSSL Project http://www.openssl.org/~levitte/ > > > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From andrew.lynch at atos.net Fri May 24 12:38:14 2019 From: andrew.lynch at atos.net (Lynch, Andrew) Date: Fri, 24 May 2019 12:38:14 +0000 Subject: Building 1.1.1a on Windows - how to "make update"? Message-ID: Hi, I have been working with OpenSSL 1.1.1a on Linux. We have a number of patches that are applied, including a specific version of cmpossl. To ensure that all new error codes, objects etc. are available I run "make update" after config. I.e. the build process is Unpack original distribution openssl-1.1.1a.tar.gz Apply list of patches ./config make update && make && make test Some colleagues have asked me for a Windows executable, so I have now installed ActivePerl 5.26.3 and Visual Studio 2019 on my Windows 7 desktop. The unmodified openssl-1.1.1a builds and runs just fine using Configure VC-WIN64A-masm. But with our patches applied the build fails once it gets to crypto/cmp because the include files cmperr.h and crmferr.h do not exist. On Linux these are created by make update. The Windows Makefile does not have a target "update" (or "errors" for that matter). So what is the equivalent of make update or make errors on Windows? I am wondering if I can simply copy the updated files from Linux (new _err.h, modified obj_dat.h and probably a few more) but I would prefer an official way to (re)generate them on Windows. Regards, Andrew. From levitte at openssl.org Fri May 24 14:17:37 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 24 May 2019 16:17:37 +0200 Subject: Building 1.1.1a on Windows - how to "make update"? In-Reply-To: References: Message-ID: <87k1eg0we6.wl-levitte@openssl.org> The diverse things that 'make update' generates is supposed to be the same across platforms, so the intention is that they get generated on one platform (Linux / Unix) and that these changes get distributed to all others. Cheers, Richard On Fri, 24 May 2019 14:38:14 +0200, Lynch, Andrew wrote: > > Hi, > > I have been working with OpenSSL 1.1.1a on Linux. We have a number of patches that are applied, including a specific version of cmpossl. To ensure that all new error codes, objects etc. are available I run "make update" after config. I.e. the build process is > > Unpack original distribution openssl-1.1.1a.tar.gz > Apply list of patches > ./config > make update && make && make test > > Some colleagues have asked me for a Windows executable, so I have now installed ActivePerl 5.26.3 and Visual Studio 2019 on my Windows 7 desktop. > > The unmodified openssl-1.1.1a builds and runs just fine using Configure VC-WIN64A-masm. But with our patches applied the build fails once it gets to crypto/cmp because the include files cmperr.h and crmferr.h do not exist. On Linux these are created by make update. The Windows Makefile does not have a target "update" (or "errors" for that matter). > > So what is the equivalent of make update or make errors on Windows? > > I am wondering if I can simply copy the updated files from Linux (new _err.h, modified obj_dat.h and probably a few more) but I would prefer an official way to (re)generate them on Windows. > > Regards, > Andrew. > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From andrew.lynch at atos.net Fri May 24 15:38:34 2019 From: andrew.lynch at atos.net (Lynch, Andrew) Date: Fri, 24 May 2019 15:38:34 +0000 Subject: Building 1.1.1a on Windows - how to "make update"? In-Reply-To: <87k1eg0we6.wl-levitte@openssl.org> References: <87k1eg0we6.wl-levitte@openssl.org> Message-ID: Ok, understood. I have now managed to build an executable with our patches and it is currently chugging through the tests (which seem to run much slower native than they did inside a Linux VM on the same host...) There was one more hiccup with a mkdef.pl failure ("does not have a number assigned"). Initially I had not copied util/libcrypto.num across because of a comment at the top of mkdef.pl: "Intermediary files are created, call libcrypto.num and libssl.num." That did not seem to happen in the way I expected. For reference, these are the files I copied from the updated Linux tree to Windows: include/openssl/cmperr.h include/openssl/crmferr.h crypto/cmp/cmp_err.c crypto/crmf/crmf_err.c crypto/err/openssl.txt util/libcrypto.num It turns out the applied patches did not include any new objects. obj_dat.h had only been touched by make update to bump the copyright year from 2018 to 2019. Regards, Andrew. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Levitte Sent: Friday, May 24, 2019 4:18 PM To: openssl-users at openssl.org Subject: Re: Building 1.1.1a on Windows - how to "make update"? The diverse things that 'make update' generates is supposed to be the same across platforms, so the intention is that they get generated on one platform (Linux / Unix) and that these changes get distributed to all others. Cheers, Richard On Fri, 24 May 2019 14:38:14 +0200, Lynch, Andrew wrote: > > Hi, > > I have been working with OpenSSL 1.1.1a on Linux. We have a number of > patches that are applied, including a specific version of cmpossl. To > ensure that all new error codes, objects etc. are available I run > "make update" after config. I.e. the build process is > > Unpack original distribution openssl-1.1.1a.tar.gz Apply list of > patches ./config make update && make && make test > > Some colleagues have asked me for a Windows executable, so I have now installed ActivePerl 5.26.3 and Visual Studio 2019 on my Windows 7 desktop. > > The unmodified openssl-1.1.1a builds and runs just fine using Configure VC-WIN64A-masm. But with our patches applied the build fails once it gets to crypto/cmp because the include files cmperr.h and crmferr.h do not exist. On Linux these are created by make update. The Windows Makefile does not have a target "update" (or "errors" for that matter). > > So what is the equivalent of make update or make errors on Windows? > > I am wondering if I can simply copy the updated files from Linux (new _err.h, modified obj_dat.h and probably a few more) but I would prefer an official way to (re)generate them on Windows. > > Regards, > Andrew. > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From subrata_usha at rediffmail.com Fri May 24 19:17:13 2019 From: subrata_usha at rediffmail.com (Subrata Dasgupta) Date: 24 May 2019 19:17:13 -0000 Subject: =?utf-8?B?SG93IHRvIHVzZSBDT05GX21vZHVsZXNfbG9hZF9maWxlIA==?= Message-ID: <20190524191713.30402.qmail@f5mail-224-151.rediffmail.com> Hi All,In my application I am using OPENSSL_config(NULL); call to initialize the configuration. But it seems from openssl-1.1.1 this call is deprecated and we should use CONF_modules_load_file call.But it will be difficult to add new configuration file for openssl within my application. It will be perfect if some how I can use basic default configuration just like OPENSSL_config do. But unfortunately every time CONF_modules_load_file call is failing . I have tried with NULL for config file name and app name in parameters of CONF_modules_load_file call. Tried with different flag combination as well. But all in vain. Please helpThanksSubrata -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Sat May 25 10:48:49 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sat, 25 May 2019 13:48:49 +0300 Subject: How to use CONF_modules_load_file In-Reply-To: <20190524191713.30402.qmail@f5mail-224-151.rediffmail.com> References: <20190524191713.30402.qmail@f5mail-224-151.rediffmail.com> Message-ID: Hello Subrata, If OPENSSL_config was sufficient for your purposes, I think that OPENSSL_init_crypto with flag OPENSSL_INIT_LOAD_CONFIG will do all you need. On Fri, May 24, 2019 at 10:49 PM Subrata Dasgupta via openssl-users < openssl-users at openssl.org> wrote: > Hi All, > In my application I am using OPENSSL_config(NULL); call to initialize the > configuration. But it seems from openssl-1.1.1 this call is deprecated and > we should use CONF_modules_load_file call. > But it will be difficult to add new configuration file for openssl within > my application. It will be perfect if some how I can use basic default > configuration just like OPENSSL_config do. But unfortunately every time > CONF_modules_load_file call is failing . I have tried with NULL for config > file name and app name in parameters of CONF_modules_load_file call. Tried > with different flag combination as well. But all in vain. Please help > > Thanks > Subrata > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivakumar2696 at gmail.com Mon May 27 06:54:23 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Mon, 27 May 2019 12:24:23 +0530 Subject: MAKE file not found in openssl 1.1.1b Message-ID: Hi, In the openssl 1.1.1b make files are missing when compared with the 1.0.2r openssl-1.1.1b/Makefile.org (not present) openssl-1.1.1b/apps/Makefile (not present) openssl-1.1.1b/engines/Makefile (not present) and may more are not present. How can I modify the make file options, in the above mentioned make files in 1.1.1b, which i was doing in 1.0.2r ? please help me Thanks and Regards Shiv. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.sha.jiang at gmail.com Mon May 27 07:17:06 2019 From: john.sha.jiang at gmail.com (John Jiang) Date: Mon, 27 May 2019 15:17:06 +0800 Subject: Session ID or Session ticket? Message-ID: Hi, I'm using OpenSSL 1.1.1 I just use the below s_client command to test resumption. openssl s_client -CAfile CA.cer -tls1_2 -sess_in openssl.sess -connect localhost:9443 Is there any option to take this tool to use only session id or session ticket for resumption? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon May 27 08:24:57 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 27 May 2019 10:24:57 +0200 Subject: MAKE file not found in openssl 1.1.1b In-Reply-To: References: Message-ID: <87ef4k1ezq.wl-levitte@openssl.org> On Mon, 27 May 2019 08:54:23 +0200, shiva kumar wrote: > In the openssl 1.1.1b make files are missing when compared with the 1.0.2r > openssl-1.1.1b/Makefile.org (not present) > openssl-1.1.1b/apps/Makefile (not present)? > openssl-1.1.1b/engines/Makefile (not present)? > and may more are not present. > > How can I modify the make file options, in the above mentioned make files in 1.1.1b, which i was > doing in 1.0.2r ? > please help me That is correct, there are no pre-existing Makefiles since 1.1.0. You have to run Configure, with the options you desire, to generate one (a single top Makefile). Please read INSTALL for more information. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon May 27 08:25:07 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 May 2019 09:25:07 +0100 Subject: Session ID or Session ticket? In-Reply-To: References: Message-ID: <5aba7bcb-3563-40b9-e2e6-b2602b377b43@openssl.org> On 27/05/2019 08:17, John Jiang wrote: > Hi, > I'm using OpenSSL 1.1.1 > > I just use the below s_client command to test resumption. > openssl s_client -CAfile CA.cer -tls1_2 -sess_in openssl.sess -connect > localhost:9443 > > Is there any option to take this tool to use only session id or session ticket > for resumption? The behaviour obviously partly depends on what the server supports. An OpenSSL client will always use session id based resumption if possible and there is no ticket sent from the server. If a ticket is provided it will use that instead, unless you supply the "-no_ticket" option to s_client - which disables all ticket support on the client. Matt From matt at openssl.org Mon May 27 08:33:47 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 May 2019 09:33:47 +0100 Subject: Building 1.1.1a on Windows - how to "make update"? In-Reply-To: References: <87k1eg0we6.wl-levitte@openssl.org> Message-ID: <7223f5b7-86e3-55ad-dba1-4bfc2c34b4d2@openssl.org> On 24/05/2019 16:38, Lynch, Andrew wrote: > Ok, understood. I have now managed to build an executable with our patches and it is currently chugging through the tests (which seem to run much slower native than they did inside a Linux VM on the same host...) > > There was one more hiccup with a mkdef.pl failure ("does not have a number assigned"). Initially I had not copied util/libcrypto.num across because of a comment at the top of mkdef.pl: "Intermediary files are created, call libcrypto.num and libssl.num." That did not seem to happen in the way I expected. > > For reference, these are the files I copied from the updated Linux tree to Windows: > include/openssl/cmperr.h > include/openssl/crmferr.h > crypto/cmp/cmp_err.c > crypto/crmf/crmf_err.c Are you sure the Linux tree you are using is a clean version of 1.1.1? Similarly with your original Windows tree? The 1.1.1 distribution does not have any files names cmperr.h or crmferr.h, and neither are there cmp or crmf subdirectories in the crypto dir. "make update" certainly should not be creating those files. These things *do* exist in master, but not in 1.1.1. I suggest starting from scratch with clean trees. Matt > crypto/err/openssl.txt > util/libcrypto.num > > It turns out the applied patches did not include any new objects. obj_dat.h had only been touched by make update to bump the copyright year from 2018 to 2019. > > Regards, > Andrew. > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Levitte > Sent: Friday, May 24, 2019 4:18 PM > To: openssl-users at openssl.org > Subject: Re: Building 1.1.1a on Windows - how to "make update"? > > The diverse things that 'make update' generates is supposed to be the same across platforms, so the intention is that they get generated on one platform (Linux / Unix) and that these changes get distributed to all others. > > Cheers, > Richard > > On Fri, 24 May 2019 14:38:14 +0200, > Lynch, Andrew wrote: >> >> Hi, >> >> I have been working with OpenSSL 1.1.1a on Linux. We have a number of >> patches that are applied, including a specific version of cmpossl. To >> ensure that all new error codes, objects etc. are available I run >> "make update" after config. I.e. the build process is >> >> Unpack original distribution openssl-1.1.1a.tar.gz Apply list of >> patches ./config make update && make && make test >> >> Some colleagues have asked me for a Windows executable, so I have now installed ActivePerl 5.26.3 and Visual Studio 2019 on my Windows 7 desktop. >> >> The unmodified openssl-1.1.1a builds and runs just fine using Configure VC-WIN64A-masm. But with our patches applied the build fails once it gets to crypto/cmp because the include files cmperr.h and crmferr.h do not exist. On Linux these are created by make update. The Windows Makefile does not have a target "update" (or "errors" for that matter). >> >> So what is the equivalent of make update or make errors on Windows? >> >> I am wondering if I can simply copy the updated files from Linux (new _err.h, modified obj_dat.h and probably a few more) but I would prefer an official way to (re)generate them on Windows. >> >> Regards, >> Andrew. >> From rashok.svks at gmail.com Mon May 27 09:26:34 2019 From: rashok.svks at gmail.com (Raja Ashok) Date: Mon, 27 May 2019 14:56:34 +0530 Subject: Difficulty in understanding TLS1.3 APIs in OpenSSL 1.1.1 Message-ID: Hi All, I feel like some TLS 1.3 configuration APIs in OpenSSL 1.1.1 are uncomfortable in using it. *1) Configuring Cipher Suit:* There is a new API for configuring TLS1.3 cipher suite, which is *SSL_set_ciphersuites()*. But calling only *SSL_set_ciphersuites()* does not work. Need to call old API *SSL_set_cipher_list()* first and then *SSL_set_ciphersuites()*. *2) Configuring supported groups and temp ECDHE:* Configuring temp ECDHE using *SSL_set_tmp_ECDH()* configures the corresponding curve ID as supported groups. So calling first *SSL_set1_groups()* and then calling* SSL_set_tmp_ECDH()* resets the configured groups using *SSL_set1_groups()*. I feel the configuration APIs introduced in TLS1.3 are little confusing and it should be used in certain order to achieve the required configuration. Can some one try to clarify me these API behaviours or is my understanding of using these API is incorrect ? Regards R Ashok -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.lynch at atos.net Mon May 27 09:29:03 2019 From: andrew.lynch at atos.net (Lynch, Andrew) Date: Mon, 27 May 2019 09:29:03 +0000 Subject: Building 1.1.1a on Windows - how to "make update"? In-Reply-To: <7223f5b7-86e3-55ad-dba1-4bfc2c34b4d2@openssl.org> References: <87k1eg0we6.wl-levitte@openssl.org> <7223f5b7-86e3-55ad-dba1-4bfc2c34b4d2@openssl.org> Message-ID: Hi Matt, Neither tree is "clean" at this point. That is the very reason for my problem. My set of patches leaves out some changes because they can be generated by "make update". This works fine on Unix but not on Windows. Starting with a clean version of 1.1.1a I have to apply up to a dozen patch files to get our bespoke version. These include a specific version of cmpossl, which is where cmp and crmf come from (currently being integrated into master but not available in any release yet), plus some of our own patches on top of that which add yet more functions and error codes. Hence the err files and libcrypto.num will differ depending on which of these patches are applied for a particular build. Running "make update" includes "make errors" which does create any missing err.h and _err.c files. (Obviously the new libnames have to be patched into openssl.ec.) In hindsight maybe the cumulative changes to those err files and libcrypto.num should have been part of the individual patches. At the time it seemed cleaner to simply use "make update" and have them generated cleanly for whatever subset of patches has been applied. Regards, Andrew. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Monday, May 27, 2019 10:34 AM To: openssl-users at openssl.org Subject: Re: Building 1.1.1a on Windows - how to "make update"? On 24/05/2019 16:38, Lynch, Andrew wrote: > Ok, understood. I have now managed to build an executable with our > patches and it is currently chugging through the tests (which seem to > run much slower native than they did inside a Linux VM on the same > host...) > > There was one more hiccup with a mkdef.pl failure ("does not have a number assigned"). Initially I had not copied util/libcrypto.num across because of a comment at the top of mkdef.pl: "Intermediary files are created, call libcrypto.num and libssl.num." That did not seem to happen in the way I expected. > > For reference, these are the files I copied from the updated Linux tree to Windows: > include/openssl/cmperr.h > include/openssl/crmferr.h > crypto/cmp/cmp_err.c > crypto/crmf/crmf_err.c Are you sure the Linux tree you are using is a clean version of 1.1.1? Similarly with your original Windows tree? The 1.1.1 distribution does not have any files names cmperr.h or crmferr.h, and neither are there cmp or crmf subdirectories in the crypto dir. "make update" certainly should not be creating those files. These things *do* exist in master, but not in 1.1.1. I suggest starting from scratch with clean trees. Matt > crypto/err/openssl.txt > util/libcrypto.num > > It turns out the applied patches did not include any new objects. obj_dat.h had only been touched by make update to bump the copyright year from 2018 to 2019. > > Regards, > Andrew. > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Richard Levitte > Sent: Friday, May 24, 2019 4:18 PM > To: openssl-users at openssl.org > Subject: Re: Building 1.1.1a on Windows - how to "make update"? > > The diverse things that 'make update' generates is supposed to be the same across platforms, so the intention is that they get generated on one platform (Linux / Unix) and that these changes get distributed to all others. > > Cheers, > Richard > > On Fri, 24 May 2019 14:38:14 +0200, > Lynch, Andrew wrote: >> >> Hi, >> >> I have been working with OpenSSL 1.1.1a on Linux. We have a number >> of patches that are applied, including a specific version of cmpossl. >> To ensure that all new error codes, objects etc. are available I run >> "make update" after config. I.e. the build process is >> >> Unpack original distribution openssl-1.1.1a.tar.gz Apply list of >> patches ./config make update && make && make test >> >> Some colleagues have asked me for a Windows executable, so I have now installed ActivePerl 5.26.3 and Visual Studio 2019 on my Windows 7 desktop. >> >> The unmodified openssl-1.1.1a builds and runs just fine using Configure VC-WIN64A-masm. But with our patches applied the build fails once it gets to crypto/cmp because the include files cmperr.h and crmferr.h do not exist. On Linux these are created by make update. The Windows Makefile does not have a target "update" (or "errors" for that matter). >> >> So what is the equivalent of make update or make errors on Windows? >> >> I am wondering if I can simply copy the updated files from Linux (new _err.h, modified obj_dat.h and probably a few more) but I would prefer an official way to (re)generate them on Windows. >> >> Regards, >> Andrew. >> From matt at openssl.org Mon May 27 10:11:44 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 May 2019 11:11:44 +0100 Subject: Difficulty in understanding TLS1.3 APIs in OpenSSL 1.1.1 In-Reply-To: References: Message-ID: On 27/05/2019 10:26, Raja Ashok wrote: > Hi All, > > I feel like some TLS 1.3 configuration APIs in OpenSSL 1.1.1 are uncomfortable > in using it.? > > *1) Configuring Cipher Suit:* There is a new API for configuring TLS1.3 cipher > suite, which is?/SSL_set_ciphersuites()/. But calling > only?/SSL_set_ciphersuites()/ does not work. Need to call old > API?/SSL_set_cipher_list()/ first and then? ?/SSL_set_ciphersuites()/. Hmmm...this shouldn't be the case. Order shouldn't be important. If you are experiencing that it sounds like a possible bug. > > *2) Configuring supported groups and temp ECDHE:* Configuring temp ECDHE using > /SSL_set_tmp_ECDH()/ configures the corresponding curve ID as supported groups. > So calling first /SSL_set1_groups()/ and then calling/SSL_set_tmp_ECDH()/ resets > the configured groups using /SSL_set1_groups()/. SSL_set_tmp_ECDH() is the old way of doing things (we should probably deprecate this). You shouldn't need to call this at all. Just use SSL_set1_groups. Matt From rama.krushna7 at gmail.com Mon May 27 11:53:52 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Mon, 27 May 2019 17:23:52 +0530 Subject: Reg Performance degradation on windows with openssl 1.1.1 Message-ID: Hi, I am building openssl 1.1.1 on windows with 2 different configurations and I see performance difference for des-cbc. 1) *"perl Configure VC-WIN64A enable-weak-ssl-ciphers enable-rc4 enable-deprecated no-shared enable-ssl3 no-asm --prefix= --openssldir= " * The speed test results for des-cbc with this configuration is as follows. >openssl.exe speed -evp des-cbc OpenSSL 1.1.1 11 Sep 2018 built on: Mon May 27 11:19:51 2019 UTC options:bn(64,64) rc4(int) des(long) aes(partial) idea(int) blowfish(ptr) compiler: cl /Zi /Fdossl_static.pdb /MT /Zl /Gs0 /GF /Gy " The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes des-cbc *24691.93k 27284.78k 25719.04k 26508.45k 29497.51k 25432.13k* 2) *perl Configure VC-WIN64A no-shared no-asm --prefix= --openssldir=* If I build it using above then the performance of des-cbc is faster. openssl.exe speed -evp des-cbc OpenSSL 1.1.1 11 Sep 2018 built on: Fri May 24 11:37:15 2019 UTC options:bn(64,64) rc4(int) des(long) aes(partial) idea(int) blowfish(ptr) compiler: cl /Zi /Fdossl_static.pdb /MT /Zl /Gs0 /GF /Gy /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes des-cbc *56789.82k 65988.99k 65978.20k 67490.82k 66155.86k 67321.86k* Could any one please suggest me how to debug the reason about slower performance with first configuration. Thanks and Regards, Ram Krushna -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Mon May 27 12:53:42 2019 From: hkario at redhat.com (Hubert Kario) Date: Mon, 27 May 2019 14:53:42 +0200 Subject: Difficulty in understanding TLS1.3 APIs in OpenSSL 1.1.1 In-Reply-To: References: Message-ID: <1860038.jHRYGCF287@pintsize.usersys.redhat.com> On Monday, 27 May 2019 12:11:44 CEST Matt Caswell wrote: > On 27/05/2019 10:26, Raja Ashok wrote: > > *2) Configuring supported groups and temp ECDHE:* Configuring temp ECDHE > > using /SSL_set_tmp_ECDH()/ configures the corresponding curve ID as > > supported groups. So calling first /SSL_set1_groups()/ and then > > calling/SSL_set_tmp_ECDH()/ resets the configured groups using > > /SSL_set1_groups()/. > > SSL_set_tmp_ECDH() is the old way of doing things (we should probably > deprecate this). You shouldn't need to call this at all. Just use > SSL_set1_groups. filed https://github.com/openssl/openssl/issues/9014 to track this probably "good first issue"? -- 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 Chethan.Kumar at toshiba-tsip.com Tue May 28 04:59:27 2019 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Tue, 28 May 2019 04:59:27 +0000 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> Dear all, Any help for the below query would be appreciated. Thanks in advance, Chethan Kumar From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Chethan Kumar Sent: Wednesday, May 22, 2019 11:35 AM To: openssl-users at openssl.org Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 Dear all, While migrating from openssl 1.0.2n to openssl 1.1.1b, application which uses openssl was compiling against openssl 1.1.1b. Compilation is fine but its linking to both libcrypto.so.1.0.0[from /usr/lib/] and libcrypto.so.1.1. Its linking correctly to libssl.1.1. Is this correct? If so, what could be the possible reason. Thanks in advance, Chethan Kumar The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use. The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Tue May 28 13:28:18 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 28 May 2019 13:28:18 +0000 Subject: OpenSSL version 1.0.2s published Message-ID: <20190528132818.GA24924@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.0.2s 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.2s 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.2s 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.2s.tar.gz Size: 5349149 SHA1 checksum: cf43d57a21e4baf420b3628677ebf1723ed53bc1 SHA256 checksum: cabd5c9492825ce5bd23f3c3aeed6a97f8142f606d893df216411f07d1abab96 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2s.tar.gz openssl sha256 openssl-1.0.2s.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztMAcACgkQ1enkP335 7ozPdRAAnUKK6jxlMa3O2GeVDU0ZZNS3A3zyMJd2yPCB3I3b0BMxy/ZWw4A6Vtyd l1M+GhP7/SG+kom9f6Ky2QXTW29lYQT4ImNZwU/hRI/nLKCqFw9Kzq4wqZnwlavx pI54Loz86Ysp2PIAtWJrOPxWT7HEculhhR0yOXxWAlAkRmrbrG3JdTba3UIH0T2P 3xoncvI0ODXWE6eW3hNCtxb/npo/czcAolO/EEN60tRcZm849ODgzNqpiV5zegoF cogfVaQFGcOncv4bYdxQIPBDBLWVEEkT+05agnFfZkv6hpIL8h2jrG4b46ULs+ZM 4iNznwLEVNVhF6Qm6RIffC3xrKIhmDZkGH8Y/ypBOTVk/vUhvot+a7Ab05fvnqeR O5BwxUVwNsxQdZ4v4BKJM/RE1ApHuQoezOCwfPfMT2NZd3StVueQxkwSrRhtEx8k ZnRrgtqYM8zCjqW7uVOvSIB08EZvJpIhMofIMqlfEixdTvmSvHQ8iPCQrKS0dmjA CtWdSgFbc7NYXwj5lqfr58brKhhoap/B8MFvVaGkcqhsCp5pE/a8JO79ESI7TVQD uxs28qhEj7RXNH61m9viOvu75ph6lfVxI/4Hat7yi/pzr4jpYYJXWM6Iz9PTf2PS admaUdGLOUB7L51Z7/uTHuACV16SwXryJn4b0OwuTmUQ9rsdDRA= =aI2x -----END PGP SIGNATURE----- From openssl at openssl.org Tue May 28 13:28:24 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 28 May 2019 13:28:24 +0000 Subject: OpenSSL version 1.1.0k published Message-ID: <20190528132824.GA24994@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.0k 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.0k 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.0k 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.0k.tar.gz Size: 5287321 SHA1 checksum: aaa2ddad0285575da7c9fa8021c26e5c8433ab15 SHA256 checksum: efa4965f4f773574d6cbda1cf874dbbe455ab1c0d4f906115f867d30444470b1 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0k.tar.gz openssl sha256 openssl-1.1.0k.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztMKgACgkQ1enkP335 7ozB7BAArso7v+Yy6+3TiPPaH+EAYkEr2J+WQ2D17s7M9kpW8errvyX7B/yMIVSh 1ZEPfWWtmDdd9CDqfpM/P2ttipjHvrPvwh01+Re8sm+pE8me3j9N1UkqXLpRPQuW eSAwjSYcVTgGlDlJnsDW7Yxf1vibfjA7hDHL+7MY3tdPna2rb2TICOmX1TmwR4ha Xc6E6JAH049Rjzh9NCgcxANnembTnPqRAVmxyf6ziMmvHeDe6voYQZrtagC1CHbY x1Y+Q3GMLtvebm7YRqoy3o29WFMPUPErcfPsun9aizmTR+UgePjQ9Tjq6bF9umTL 5Z1lt4JJsC0gUmKLTpPL0SNhAf1/TS59Usvk4pMefSq7ejteSzX1xoHY/VQ4U8pO pO8Vsn7k8U4azuRgi3diprYhgtMDeK4udyepFTI53Bqk/H7Gm0v+R7tYYH2Zbwqm 49UuvMlP/7XHKwo0hIoV6Ul3xrNprxoXQmTG+Tm4+AoA4Qn9jELvMe96CaeLAPxG V7NjqK7Tr4Iosso4h+Pq2oEsu3GLzXVdFYA5RORkakuX60Y8+jznKAP4WNhPS/rs zPr8fVghb0kpctodvq2px47DVQSsUf2nYGVwu205bHpGyTKuB1ZWkYbC6cQEg3yB SPlFyHmHWYjqk8RSmSKZSiN33x0ysG8kwr3PEJOEEe8bvF3r7cM= =go9J -----END PGP SIGNATURE----- From openssl at openssl.org Tue May 28 13:28:29 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 28 May 2019 13:28:29 +0000 Subject: OpenSSL version 1.1.1c published Message-ID: <20190528132829.GA25063@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1c 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.1c 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.1c 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.1c.tar.gz Size: 8864262 SHA1 checksum: 71b830a077276cbeccc994369538617a21bee808 SHA256 checksum: f6fb3079ad15076154eda9413fed42877d668e7069d9b87396d0804fdb3f4c90 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1c.tar.gz openssl sha256 openssl-1.1.1c.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztM8MACgkQ1enkP335 7ow2lRAAirwJYIX4XunYXMV88tQILxAB6iCDiN04c5r5ayJqmF5Zr3QKGDG7Vj+l q6NEmKIYpyjAxZau3orl0OC5L4Us+URFpyFpCe8BOpXjasFQYk7jycr3MI1BHYcO dl9gVx09BZriR+q9w5xBJad34leCvuCD950+9eG/DY3+xSSWLDeagzz+dhOgTnOj +YyMo+o/f+VucjsYddL2ehL5v744xdqu6Pu4JMceLaRdSfmKXRqwlob2w2UtCgoD roy4+pPVLA9FYBOOYy1n2PFGopp/c67xfQX1yB35mjAB5y3FSJAWFS0gvPaHvzj1 D+zbQSxYVksOyUSrK33KnJmouaml5+CQgYRS+Umn8549A2apkIB/yRLo2K65Iuqd KHgZGbI4cGUBEdbIxUDtvhsIr/+JlujJPvs5Eyiwm8+K/WPiZ3Hw8EXmdqTl9ITK 7URwWM4thq1sikD7RKHl4h9gEzvB6iqTd+dPbUE8jIc29HD7rPJWCw3m+gOGEoAu L0rU4palNa1Ab6kMZ2SYsXv/rH4pl0iHBBrzVOStay/k4zPYS3eD6kytyB0vLt6g f0u4heD4G4QiohqIFaDHjs8eSq1Paz3eA3Ylly8JKweBFTrHHssyz22ItGDCcQwz cOb7H3o/AdXGZOSHxHtLBQqxsUcCuUID0YTyUB43bRuLnVmWs6I= =EHRv -----END PGP SIGNATURE----- From levitte at openssl.org Tue May 28 14:07:11 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 28 May 2019 16:07:11 +0200 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: <87blzm1xm8.wl-levitte@openssl.org> In what way does it link to both? What output do you get when running 'ldd' in your application? Is it using some kind of dynamic module that happens to be linked with an older OpenSSL version? Cheers, Richard On Tue, 28 May 2019 06:59:27 +0200, Chethan Kumar wrote: > > > Dear all, > > Any help for the below query would be appreciated. > > Thanks in advance, > > Chethan Kumar > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Chethan Kumar > Sent: Wednesday, May 22, 2019 11:35 AM > To: openssl-users at openssl.org > Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 > > Dear all, > > While migrating from openssl 1.0.2n to openssl 1.1.1b, application which uses openssl was > compiling against openssl 1.1.1b. > > Compilation is fine but its linking to both libcrypto.so.1.0.0[from /usr/lib/] and > libcrypto.so.1.1. > > Its linking correctly to libssl.1.1. > > Is this correct? If so, what could be the possible reason. > > Thanks in advance, > > Chethan Kumar > > The information contained in this e-mail message and in any attachments/annexure/appendices is > confidential to the > recipient and may contain privileged information. If you are not the intended recipient, please > notify the > sender and delete the message along with any attachments/annexure/appendices. You should not > disclose, > copy or otherwise use the information contained in the message or any annexure. Any views > expressed in this e-mail > are those of the individual sender except where the sender specifically states them to be the > views of > Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. > Although this transmission and any attachments are believed to be free of any virus or other > defect that might affect any computer system into which it is received and opened, it is the > responsibility of the recipient to ensure that it is virus free and no responsibility is accepted > by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use. > > The information contained in this e-mail message and in any attachments/annexure/appendices is > confidential to the > recipient and may contain privileged information. If you are not the intended recipient, please > notify the > sender and delete the message along with any attachments/annexure/appendices. You should not > disclose, > copy or otherwise use the information contained in the message or any annexure. Any views > expressed in this e-mail > are those of the individual sender except where the sender specifically states them to be the > views of > Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. > Although this transmission and any attachments are believed to be free of any virus or other > defect that might affect any computer system into which it is received and opened, it is the > responsibility of the recipient to ensure that it is virus free and no responsibility is accepted > by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use. > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Chethan.Kumar at toshiba-tsip.com Tue May 28 14:49:20 2019 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Tue, 28 May 2019 14:49:20 +0000 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: <87blzm1xm8.wl-levitte@openssl.org> References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> <87blzm1xm8.wl-levitte@openssl.org> Message-ID: <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> I meant to say linking to both by doing ldd. When ldd is done on application, both libcrypto.so.1.0.0 and libcrypto.1.1 is shown. Here libcrypto.so.1.0.0 is taken from the one provided by OS. > Is it using some kind of dynamic module that happens to be linked with an older OpenSSL version? No, its not using any dynamic module. Its built on platform: Linux version 4.4.130-cip23-eBN-kernel (jenkins at skelios-plt) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) ) -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Levitte Sent: Tuesday, May 28, 2019 7:37 PM To: openssl-users at openssl.org Subject: Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In what way does it link to both? What output do you get when running 'ldd' in your application? Is it using some kind of dynamic module that happens to be linked with an older OpenSSL version? Cheers, Richard On Tue, 28 May 2019 06:59:27 +0200, Chethan Kumar wrote: > > > Dear all, > > Any help for the below query would be appreciated. > > Thanks in advance, > > Chethan Kumar > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Chethan Kumar > Sent: Wednesday, May 22, 2019 11:35 AM > To: openssl-users at openssl.org > Subject: Application linking to both libcrypto.so.1.0.0 and > libcrypto.so.1.1 > > Dear all, > > While migrating from openssl 1.0.2n to openssl 1.1.1b, application > which uses openssl was compiling against openssl 1.1.1b. > > Compilation is fine but its linking to both libcrypto.so.1.0.0[from > /usr/lib/] and libcrypto.so.1.1. > > Its linking correctly to libssl.1.1. > > Is this correct? If so, what could be the possible reason. > > Thanks in advance, > > Chethan Kumar > > The information contained in this e-mail message and in any > attachments/annexure/appendices is confidential to the recipient and > may contain privileged information. If you are not the intended > recipient, please notify the sender and delete the message along with > any attachments/annexure/appendices. You should not disclose, copy or > otherwise use the information contained in the message or any > annexure. Any views expressed in this e-mail are those of the > individual sender except where the sender specifically states them to > be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. > Although this transmission and any attachments are believed to be free > of any virus or other defect that might affect any computer system > into which it is received and opened, it is the responsibility of the > recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use. > > The information contained in this e-mail message and in any > attachments/annexure/appendices is confidential to the recipient and > may contain privileged information. If you are not the intended > recipient, please notify the sender and delete the message along with > any attachments/annexure/appendices. You should not disclose, copy or > otherwise use the information contained in the message or any > annexure. Any views expressed in this e-mail are those of the > individual sender except where the sender specifically states them to > be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. > Although this transmission and any attachments are believed to be free > of any virus or other defect that might affect any computer system > into which it is received and opened, it is the responsibility of the > recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use. > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. From Michael.Wojcik at microfocus.com Tue May 28 15:35:21 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 28 May 2019 15:35:21 +0000 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> <87blzm1xm8.wl-levitte@openssl.org> <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Chethan Kumar > Sent: Tuesday, May 28, 2019 08:49 > > I meant to say linking to both by doing ldd. > When ldd is done on application, both libcrypto.so.1.0.0 and libcrypto.1.1 is > shown. Don't tell us about the ldd output. Show us. ldd output is short enough to include in an email message. > > Is it using some kind of dynamic module that happens to be linked with an > older OpenSSL version? > No, its not using any dynamic module. This is obviously incorrect. You've already noted that it's loading at least three - the two versions of libcrypto and libssl. Your application may not be doing any explicit dynamic loading, but it has implicit dynamic loads. That's what ldd shows. You haven't shown us the link line for the application. -- Michael Wojcik Distinguished Engineer, Micro Focus From jayf0ster at roadrunner.com Tue May 28 17:39:33 2019 From: jayf0ster at roadrunner.com (Jay Foster) Date: Tue, 28 May 2019 10:39:33 -0700 Subject: Performance Issue With OpenSSL 1.1.1c Message-ID: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> I built OpenSSL 1.1.1c from the recent release, but have noticed what seems like a significant performance drop compared with 1.1.1b.? I notice this when starting lighttpd.? With 1.1.1b, lighttpd starts in a few seconds, but with 1.1.1c, it takes several minutes. I also noticed that with 1.1.1b, the CFLAGS automatically included '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the CFLAGS.? was this dropped?? I? added '-Wall -O3' to the CFLAGS, but this did not seem to have any affect on the performance issue (unrelated?). This is for a 32-bit ARM build. Jay From dclarke at blastwave.org Tue May 28 18:31:19 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 28 May 2019 14:31:19 -0400 Subject: Slightly funny tar ball for openssl 1.1.1c ? Message-ID: <398edee4-8413-7a21-1eaa-b31a40a4836a@blastwave.org> I don't thing I have seen this before : beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf - tar: pax_global_header: typeflag 'g' not recognized, converting to regular file beta $ Must be a gnu tar thing? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From Matthias.St.Pierre at ncp-e.com Tue May 28 19:12:21 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 28 May 2019 19:12:21 +0000 Subject: AW: Slightly funny tar ball for openssl 1.1.1c ? In-Reply-To: <398edee4-8413-7a21-1eaa-b31a40a4836a@blastwave.org> References: <398edee4-8413-7a21-1eaa-b31a40a4836a@blastwave.org> Message-ID: <188a105206084174b46b296df20c9a29@Ex13.ncp.local> > -----Urspr?ngliche Nachricht----- > I don't thing I have seen this before : > > beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf - > tar: pax_global_header: typeflag 'g' not recognized, converting to > regular file > beta $ > > Must be a gnu tar thing? Hi Dennis, it's not a bug, it's a feature. ;-) No seriously: it's the `git archive` command which is used to export the tree into a tarfile. It adds an extended header containing the commit hash of the commit which was exported. Older tar programs don't know how to deal with that header and are a bit confused about it. We had a similar discussion after 1.1.1b was released, it started here https://mta.openssl.org/pipermail/openssl-users/2019-February/009936.html see in particular reply https://mta.openssl.org/pipermail/openssl-users/2019-February/009949.html and the links to the LKML which it contains https://lkml.org/lkml/2005/6/18/5 https://marc.info/?l=linux-kernel&m=111909182607985&w=2 HTH, Matthias From dclarke at blastwave.org Tue May 28 19:19:04 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 28 May 2019 15:19:04 -0400 Subject: AW: Slightly funny tar ball for openssl 1.1.1c ? In-Reply-To: <188a105206084174b46b296df20c9a29@Ex13.ncp.local> References: <398edee4-8413-7a21-1eaa-b31a40a4836a@blastwave.org> <188a105206084174b46b296df20c9a29@Ex13.ncp.local> Message-ID: >> beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf - >> tar: pax_global_header: typeflag 'g' not recognized, converting to >> regular file >> beta $ >> >> Must be a gnu tar thing? > > Hi Dennis, > > it's not a bug, it's a feature. ;-) > > No seriously: it's the `git archive` command which is used to export the tree > into a tarfile. It adds an extended header containing the commit hash of the > commit which was exported. Older tar programs don't know how to deal > with that header and are a bit confused about it. Yep. Old POSIX tar just coughed up a one line pax_global_header file : 52 comment=97ace46e11dba4c4c2b7cb67140b6ec152cfaaf4 > > We had a similar discussion after 1.1.1b was released, it started here > https://mta.openssl.org/pipermail/openssl-users/2019-February/009936.html > > see in particular reply > https://mta.openssl.org/pipermail/openssl-users/2019-February/009949.html > > and the links to the LKML which it contains > https://lkml.org/lkml/2005/6/18/5 > https://marc.info/?l=linux-kernel&m=111909182607985&w=2 > Perfectly harmless feature. Thank you for the detailed reply. Dennis From steffen at sdaoden.eu Tue May 28 20:21:03 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 28 May 2019 22:21:03 +0200 Subject: Slightly funny tar ball for openssl 1.1.1c ? In-Reply-To: References: <398edee4-8413-7a21-1eaa-b31a40a4836a@blastwave.org> <188a105206084174b46b296df20c9a29@Ex13.ncp.local> Message-ID: <20190528202103.JH4d5%steffen@sdaoden.eu> Dennis Clarke wrote in : | |>> beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf - |>> tar: pax_global_header: typeflag 'g' not recognized, converting to |>> regular file |>> beta $ |>> |>> Must be a gnu tar thing? |> |> Hi Dennis, |> |> it's not a bug, it's a feature. ;-) |> |> No seriously: it's the `git archive` command which is used to export \ |> the tree |> into a tarfile. It adds an extended header containing the commit \ |> hash of the |> commit which was exported. Older tar programs don't know how to deal |> with that header and are a bit confused about it. | |Yep. Old POSIX tar just coughed up a one line pax_global_header file : | |52 comment=97ace46e11dba4c4c2b7cb67140b6ec152cfaaf4 | |> We had a similar discussion after 1.1.1b was released, it started here |> https://mta.openssl.org/pipermail/openssl-users/2019-February/009936.html |> |> see in particular reply |> https://mta.openssl.org/pipermail/openssl-users/2019-February/009949.html |> |> and the links to the LKML which it contains |> https://lkml.org/lkml/2005/6/18/5 |> https://marc.info/?l=linux-kernel&m=111909182607985&w=2 | |Perfectly harmless feature. Thank you for the detailed reply. Does not look harmless on some BSD unless thorougly inspected iirc. Since 2013-09-13 ([9c1375a7]) i thus repack balls # Repack with standard tar(1) to avoid new-style headers ${git} archive --format=tar --prefix="${PROGRAM}-${REL}/" v${REL}.ar | ( cd "${TMPDIR}" && ${tar} -x -f - ) cd "${TMPDIR}" ${tar} -c -f "${PROGRAM}-${REL}.tar" "${PROGRAM}-${REL}" NetBSD tar for example might say[1], which is frightening. "%s extended headers posix ustar archive." " Extracting as plain files. Following files might be" " in the wrong directory or have wrong attributes.", [1] http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/pax/tar.c?rev=1.75&content-type=text/x-cvsweb-markup&only_with_tag=MAIN --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From openssl-users at dukhovni.org Tue May 28 20:21:29 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 28 May 2019 16:21:29 -0400 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> <87blzm1xm8.wl-levitte@openssl.org> <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: <3B9189AE-F8B1-4B72-81BB-C93132ABFA4A@dukhovni.org> > On May 28, 2019, at 11:35 AM, Michael Wojcik wrote: > > Don't tell us about the ldd output. Show us. ldd output is short enough to include in an email message. More useful than "ldd" output, is output from "readelf -d", showing the NEEDED libraries, any RPATH, ... -- Viktor. From mcr at sandelman.ca Tue May 28 21:07:50 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 28 May 2019 17:07:50 -0400 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> <87blzm1xm8.wl-levitte@openssl.org> <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: <26357.1559077670@localhost> In general, this occurs because you have some other libraries (from your system) that link against libcrypto.so.1.0.0. In theory, it should all just work, but in practice I've often found my application did not work as expected. Specifically, I'd get a TLS end point that did not speak ECDSA (1.0 does not, 1.1 does). You have make a pass through the shared objects that your application references (ldd output), and then using ldd, you can discover which ones want libcrypto.so.1.0.0, and then you either have to upgrade those libraries, or you may have to compile them from source. The last time I did this, I found it was libpqclient5 (a postgresql client library), and that I was able to upgrade it to libpqclient10 rather than resort to source code. Minimal distributions like containerized alpinelinux also help to minimize your dependancies. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jayf0ster at roadrunner.com Tue May 28 21:15:51 2019 From: jayf0ster at roadrunner.com (Jay Foster) Date: Tue, 28 May 2019 14:15:51 -0700 Subject: Performance Issue With OpenSSL 1.1.1c In-Reply-To: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> Message-ID: <84571f12-68b3-f7ee-7896-c891a2e253e7@roadrunner.com> On 5/28/2019 10:39 AM, Jay Foster wrote: > I built OpenSSL 1.1.1c from the recent release, but have noticed what > seems like a significant performance drop compared with 1.1.1b.? I > notice this when starting lighttpd.? With 1.1.1b, lighttpd starts in a > few seconds, but with 1.1.1c, it takes several minutes. > > I also noticed that with 1.1.1b, the CFLAGS automatically included > '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the > CFLAGS.? was this dropped?? I? added '-Wall -O3' to the CFLAGS, but > this did not seem to have any affect on the performance issue > (unrelated?). > > This is for a 32-bit ARM build. > > Jay > I think I have tracked down the change in 1.1.1c that is causing this.? It is the addition of the DEVRANDOM_WAIT functionality for linux in e_os.h and crypto/rand/rand_unix.c.? lighttpd (libcrypto) is waiting in a select() call on /dev/random.? After this eventually wakes up, it then reads from /dev/urandom.? OpenSSL 1.1.1b did not do this, but instead just read from /dev/urandom.? Is there more information about this change (i.e., a rationale)?? I did not see anything in the CHANGES file about it. Jay From Michael.Wojcik at microfocus.com Tue May 28 21:21:33 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 28 May 2019 21:21:33 +0000 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: <3B9189AE-F8B1-4B72-81BB-C93132ABFA4A@dukhovni.org> References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> <87blzm1xm8.wl-levitte@openssl.org> <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> <3B9189AE-F8B1-4B72-81BB-C93132ABFA4A@dukhovni.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Viktor Dukhovni > Sent: Tuesday, May 28, 2019 14:21 > > > On May 28, 2019, at 11:35 AM, Michael Wojcik > wrote: > > > > Don't tell us about the ldd output. Show us. ldd output is short enough to > include in an email message. > > More useful than "ldd" output, is output from "readelf -d", > showing the NEEDED libraries, any RPATH, ... Well, yes, for this specific case (i.e. when looking at a dynamic-loading issue for a platform that uses ELF binaries and has the readelf utility). But I was making a more generic point: don't just tell us how you interpreted the result of an investigation when you can reasonably show us the actual evidence as well. This of course is part of the eternal and widespread problem of not knowing how to ask a good question. I'm trying to offer some general advice in that area (without being quite as verbose as ESR's "How To Ask Questions The Smart Way"). -- Michael Wojcik Distinguished Engineer, Micro Focus From steffen at sdaoden.eu Tue May 28 21:48:51 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 28 May 2019 23:48:51 +0200 Subject: Performance Issue With OpenSSL 1.1.1c In-Reply-To: <84571f12-68b3-f7ee-7896-c891a2e253e7@roadrunner.com> References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> <84571f12-68b3-f7ee-7896-c891a2e253e7@roadrunner.com> Message-ID: <20190528214851.YWZds%steffen@sdaoden.eu> Jay Foster wrote in <84571f12-68b3-f7ee-7896-c891a2e253e7 at roadrunner.com>: |On 5/28/2019 10:39 AM, Jay Foster wrote: |> I built OpenSSL 1.1.1c from the recent release, but have noticed what |> seems like a significant performance drop compared with 1.1.1b.? I |> notice this when starting lighttpd.? With 1.1.1b, lighttpd starts in a |> few seconds, but with 1.1.1c, it takes several minutes. |> |> I also noticed that with 1.1.1b, the CFLAGS automatically included |> '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the |> CFLAGS.? was this dropped?? I? added '-Wall -O3' to the CFLAGS, but |> this did not seem to have any affect on the performance issue |> (unrelated?). |> |> This is for a 32-bit ARM build. |> |> Jay |> |I think I have tracked down the change in 1.1.1c that is causing this.? |It is the addition of the DEVRANDOM_WAIT functionality for linux in |e_os.h and crypto/rand/rand_unix.c.? lighttpd (libcrypto) is waiting in |a select() call on /dev/random.? After this eventually wakes up, it then |reads from /dev/urandom.? OpenSSL 1.1.1b did not do this, but instead |just read from /dev/urandom.? Is there more information about this |change (i.e., a rationale)?? I did not see anything in the CHANGES file |about it. I do not know why lighttpd ends up on /dev/random for you, but in my opinion the Linux random stuff is both sophisticated and sucks. The latter because (it seems that many) people end up using haveged or similar to pimp up their entropy artificially, whereas on the other side the initial OS seeding is no longer truly supported. Writing some seed to /dev/urandom does not bring any entropy to the "real" pool. This drove me insane on my elder boxes, and on my VM server (which suddenly required minutes for booting, but mind you that was actually really OpenSSH hanging on, just the boot messages made me think something else) i even had to log in twice to end a hang of half on hour -- by doing one (maybe two) keypress(es)! Whereas that box does reasonable work by generating I/O and thus I/O based entropy, once it is up. But the pool cannot be feeded until we get there. I installed haveged, but this is ridiculous! Therefore i have written a small program entropy-saver.c which saves and restores entropy to the real pool, which is still possible (though the interface is deprecated). This works just fantastic, and even on my brand new laptop it is of value. And Linux does not take the proposed bits for granted but about halfs that. Feel free to use it. Do not use it in conjunction with haveged or something, or take care for the order. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -------------- next part -------------- A non-text attachment was scrubbed... Name: entropy-saver.c Type: text/x-csrc Size: 8521 bytes Desc: not available URL: From dclarke at blastwave.org Tue May 28 23:07:01 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 28 May 2019 19:07:01 -0400 Subject: Performance Issue With OpenSSL 1.1.1c In-Reply-To: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> Message-ID: <75db9ebf-058a-0bb8-51b5-0ad12e0cd1d3@blastwave.org> > I also noticed that with 1.1.1b, the CFLAGS automatically included > '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the > CFLAGS.? was this dropped?? I? added '-Wall -O3' to the CFLAGS, but this > did not seem to have any affect on the performance issue (unrelated?). > > This is for a 32-bit ARM build. > > Jay Well, for what it is worth, on ye old Solaris 10 sparc world things were horrific before and horrific after an upgrade. No optimization at all. Slightly better but still horrific : beta # uname -a SunOS beta 5.10 Generic_150400-65 sun4u sparc SUNW,SPARC-Enterprise beta # beta # psrinfo -pv The physical processor has 8 virtual processors (0-7) SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz) beta # * * * before * * * beta # /usr/local/bin/openssl speed rsa Doing 512 bits private rsa's for 10s: 12665 512 bits private RSA's in 9.99s Doing 512 bits public rsa's for 10s: 239095 512 bits public RSA's in 10.00s Doing 1024 bits private rsa's for 10s: 2453 1024 bits private RSA's in 9.99s Doing 1024 bits public rsa's for 10s: 95296 1024 bits public RSA's in 10.00s Doing 2048 bits private rsa's for 10s: 400 2048 bits private RSA's in 10.01s Doing 2048 bits public rsa's for 10s: 29899 2048 bits public RSA's in 10.00s Doing 3072 bits private rsa's for 10s: 164 3072 bits private RSA's in 10.04s Doing 3072 bits public rsa's for 10s: 14204 3072 bits public RSA's in 10.00s Doing 4096 bits private rsa's for 10s: 78 4096 bits private RSA's in 10.00s Doing 4096 bits public rsa's for 10s: 8257 4096 bits public RSA's in 10.00s Doing 7680 bits private rsa's for 10s: 16 7680 bits private RSA's in 10.56s Doing 7680 bits public rsa's for 10s: 2439 7680 bits public RSA's in 10.00s Doing 15360 bits private rsa's for 10s: 3 15360 bits private RSA's in 13.18s Doing 15360 bits public rsa's for 10s: 622 15360 bits public RSA's in 10.00s OpenSSL 1.1.1b 26 Feb 2019 built on: Tue Mar 26 06:51:39 2019 UTC options:bn(64,32) rc4(char) des(int) aes(partial) idea(int) blowfish(ptr) compiler: /opt/developerstudio12.6/bin/cc -KPIC -m64 -Xa -g -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -xdebugformat=dwarf -xstrconst -m64 -xarch=sparc -g -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf -DFILIO_H -DB_ENDIAN -DBN_DIV2W -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO sign verify sign/s verify/s rsa 512 bits 0.000789s 0.000042s 1267.8 23909.5 rsa 1024 bits 0.004073s 0.000105s 245.5 9529.6 rsa 2048 bits 0.025025s 0.000334s 40.0 2989.9 rsa 3072 bits 0.061220s 0.000704s 16.3 1420.4 rsa 4096 bits 0.128205s 0.001211s 7.8 825.7 rsa 7680 bits 0.660000s 0.004100s 1.5 243.9 rsa 15360 bits 4.393333s 0.016077s 0.2 62.2 beta # * * * after * * * beta # /usr/local/bin/openssl version OpenSSL 1.1.1c 28 May 2019 beta # /usr/local/bin/openssl speed rsa Doing 512 bits private rsa's for 10s: 13654 512 bits private RSA's in 9.99s Doing 512 bits public rsa's for 10s: 238275 512 bits public RSA's in 10.00s Doing 1024 bits private rsa's for 10s: 2665 1024 bits private RSA's in 10.00s Doing 1024 bits public rsa's for 10s: 95371 1024 bits public RSA's in 9.99s Doing 2048 bits private rsa's for 10s: 431 2048 bits private RSA's in 9.99s Doing 2048 bits public rsa's for 10s: 29914 2048 bits public RSA's in 10.00s Doing 3072 bits private rsa's for 10s: 164 3072 bits private RSA's in 10.04s Doing 3072 bits public rsa's for 10s: 14256 3072 bits public RSA's in 9.99s Doing 4096 bits private rsa's for 10s: 80 4096 bits private RSA's in 10.06s Doing 4096 bits public rsa's for 10s: 8278 4096 bits public RSA's in 10.00s Doing 7680 bits private rsa's for 10s: 16 7680 bits private RSA's in 10.34s Doing 7680 bits public rsa's for 10s: 2437 7680 bits public RSA's in 9.99s Doing 15360 bits private rsa's for 10s: 3 15360 bits private RSA's in 13.17s Doing 15360 bits public rsa's for 10s: 621 15360 bits public RSA's in 10.01s OpenSSL 1.1.1c 28 May 2019 built on: Tue May 28 19:37:03 2019 UTC options:bn(64,32) rc4(char) des(int) aes(partial) idea(int) blowfish(ptr) compiler: /opt/developerstudio12.6/bin/cc -KPIC -m64 -xarch=sparc -g -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf -xstrconst -Xa -m64 -xarch=sparc -g -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf -DFILIO_H -DB_ENDIAN -DBN_DIV2W -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO sign verify sign/s verify/s rsa 512 bits 0.000732s 0.000042s 1366.8 23827.5 rsa 1024 bits 0.003752s 0.000105s 266.5 9546.6 rsa 2048 bits 0.023179s 0.000334s 43.1 2991.4 rsa 3072 bits 0.061220s 0.000701s 16.3 1427.0 rsa 4096 bits 0.125750s 0.001208s 8.0 827.8 rsa 7680 bits 0.646250s 0.004099s 1.5 243.9 rsa 15360 bits 4.390000s 0.016119s 0.2 62.0 beta # The fact that it all works is good enough. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From hmurray at megapathdsl.net Wed May 29 01:55:54 2019 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 28 May 2019 18:55:54 -0700 Subject: Performance Issue With OpenSSL 1.1.1c In-Reply-To: Message from Jay Foster of "Tue, 28 May 2019 14:15:51 PDT." <84571f12-68b3-f7ee-7896-c891a2e253e7@roadrunner.com> Message-ID: <20190529015554.8CBC540605C@ip-64-139-1-69.sjc.megapath.net> jayf0ster at roadrunner.com said: > I think I have tracked down the change in 1.1.1c that is causing this.? It > is the addition of the DEVRANDOM_WAIT functionality for linux in e_os.h and > crypto/rand/rand_unix.c.? lighttpd (libcrypto) is waiting in a select() call > on /dev/random. ... I have seen similar delays that don't involve OpenSSL. [ 10.585102] [drm] Initialized qxl 0.1.0 20120117 for 0000:00:02.0 on minor 0 [ 10.605881] EDAC sbridge: Seeking for: PCI ID 8086:3ca0 [ 10.605887] EDAC sbridge: Ver: 1.1.2 [ 540.286117] random: crng init done [ 540.287631] random: 7 urandom warning(s) missed due to ratelimiting May 18 20:59:00 ntp1 kernel: [drm] Initialized qxl 0.1.0 20120117 for 0000:00:02.0 on minor 0 May 18 21:09:55 ntp1 kernel: random: crng init done -- These are my opinions. I hate spam. From Matthias.St.Pierre at ncp-e.com Wed May 29 06:20:38 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 29 May 2019 06:20:38 +0000 Subject: AW: Performance Issue With OpenSSL 1.1.1c In-Reply-To: <84571f12-68b3-f7ee-7896-c891a2e253e7@roadrunner.com> References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> <84571f12-68b3-f7ee-7896-c891a2e253e7@roadrunner.com> Message-ID: <4dbbdbd66b4c466a871282790c016113@Ex13.ncp.local> > I think I have tracked down the change in 1.1.1c that is causing this. > It is the addition of the DEVRANDOM_WAIT functionality for linux in > e_os.h and crypto/rand/rand_unix.c.? lighttpd (libcrypto) is waiting in > a select() call on /dev/random.? After this eventually wakes up, it then > reads from /dev/urandom.? OpenSSL 1.1.1b did not do this, but instead > just read from /dev/urandom.? Is there more information about this > change (i.e., a rationale)?? I did not see anything in the CHANGES file > about it. The original discussions for this change can be found on GitHub: - issue #8215, fixed by pull request #8251 - issue #8416, fixed by pull request #8428 (see links below). And you are right, the change should have been mentioned in the CHANGES file. Apologies for that. HTH, Matthias https://github.com/openssl/openssl/issues/8215 https://github.com/openssl/openssl/pull/8251 https://github.com/openssl/openssl/issues/8416 https://github.com/openssl/openssl/pull/8428 From matt at openssl.org Wed May 29 09:11:34 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 29 May 2019 10:11:34 +0100 Subject: Forthcoming OpenSSL Releases In-Reply-To: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org> References: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org> Message-ID: On 21/05/2019 16:43, Matt Caswell wrote: > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s. > > These releases will be made available on 28th May 2019 between approximately > 1200-1600 UTC. > > OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not > address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the > equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant). Correction to this announcement: OpenSSL 1.1.1c and OpenSSL 1.1.0k (released yesterday) do not address any new CVEs. They do however contain a fix for a previously announced low severity CVE (CVE-2019-1543). See the original security advisory here: https://www.openssl.org/news/secadv/20190306.txt Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Chethan.Kumar at toshiba-tsip.com Wed May 29 10:06:50 2019 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Wed, 29 May 2019 10:06:50 +0000 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> <87blzm1xm8.wl-levitte@openssl.org> <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> <3B9189AE-F8B1-4B72-81BB-C93132ABFA4A@dukhovni.org> Message-ID: <447C096A3E2889439233CDD6DAB29F95C0F22126@tosblrmbx04.TOSHIBA-TSIP.COM> Dear all, Sorry for the inconvenience caused by not asking query clearly. Below is the output from ldd on application. Seriously I didn't knew application uses these many libraries[Knew only the problem]. linux-gate.so.1 (0xf76fc000) libpam.so.0 => /lib/i386-linux-gnu/libpam.so.0 (0xf6a63000) libldap-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/libldap-2.4.so.2 (0xf6a29000) libssl.so.1.1 => /home/SYSROM_SRC/build/release/lib/libssl.so.1.1 (0xf6990000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf6972000) libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xf689c000) libcrypto.so.1.1 => /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.1 (0xf65af000) libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 (0xf657e000) libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xf6566000) libext2fs.so.2 => /lib/i386-linux-gnu/libext2fs.so.2 (0xf6516000) libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf6511000) libdns.so.69 => /home/SYSROM_SRC/build/release/lib/libdns.so.69 (0xf635c000) libisc.so.62 => /home/SYSROM_SRC/build/release/lib/libisc.so.62 (0xf62e7000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf62de000) libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0 (0xf62d2000) libkrb5.so.25 => /home/SYSROM_SRC/build/release/lib/libkrb5.so.25 (0xf6259000) libgssapi.so.2 => /home/SYSROM_SRC/build/release/lib/libgssapi.so.2 (0xf6222000) libCryptolib.so.0 => /home/SYSROM_SRC/build/release/lib/libCryptolib.so.0 (0xf6191000) libimf.so => /mfp/lib/libimf.so (0xf5dd8000) libirng.so => /usr/lib/libirng.so (0xf5c6e000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf5c1a000) libcilkrts.so.5 => /usr/lib/libcilkrts.so.5 (0xf5bec000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf5afd000) libsvml.so => /mfp/lib/libsvml.so (0xf4bbf000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf4bab000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf4ba6000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf49e4000) liblber-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/liblber-2.4.so.2 (0xf49d9000) libsasl2.so.3 => /home/SYSROM_SRC/build/release/lib/libsasl2.so.3 (0xf49a4000) /lib/i386-linux-gnu/ld-linux.so.2 (0xf76fd000) libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xf49a0000) libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xf499b000) libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 (0xf494c000) libcom_err.so.1 => /home/SYSROM_SRC/build/release/lib/libcom_err.so.1 (0xf4948000) libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xf476b000) libcap.so.2 => /lib/i386-linux-gnu/libcap.so.2 (0xf4766000) libhx509.so.5 => /home/SYSROM_SRC/build/release/lib/libhx509.so.5 (0xf4720000) libheimsqlite.so.0 => /home/SYSROM_SRC/build/release/lib/libheimsqlite.so.0 (0xf46a9000) libhcrypto.so.4 => /home/SYSROM_SRC/build/release/lib/libhcrypto.so.4 (0xf4673000) libasn1.so.8 => /home/SYSROM_SRC/build/release/lib/libasn1.so.8 (0xf45cd000) libwind.so.0 => /home/SYSROM_SRC/build/release/lib/libwind.so.0 (0xf45a3000) libroken.so.18 => /home/SYSROM_SRC/build/release/lib/libroken.so.18 (0xf458d000) libcrypt.so.1 => /lib/i386-linux-gnu/libcrypt.so.1 (0xf455b000) libheimntlm.so.0 => /home/SYSROM_SRC/build/release/lib/libheimntlm.so.0 (0xf4555000) libintlc.so.5 => /mfp/lib/libintlc.so.5 (0xf44f1000) libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xf441d000) libattr.so.1 => /lib/i386-linux-gnu/libattr.so.1 (0xf4418000) Here libcrypto.so.1.1 is newly generated using openssl 1.1.1b and libcrypto.so.1.0.0 is one provided by OS. readelf for same application is below. Dynamic section at offset 0xc29258 contains 48 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libpam.so.0] 0x00000001 (NEEDED) Shared library: [libldap-2.4.so.2] 0x00000001 (NEEDED) Shared library: [libssl.so.1.1] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libsqlite3.so.0] 0x00000001 (NEEDED) Shared library: [libcrypto.so.1.1] 0x00000001 (NEEDED) Shared library: [libk5crypto.so.3] 0x00000001 (NEEDED) Shared library: [libresolv.so.2] 0x00000001 (NEEDED) Shared library: [libext2fs.so.2] 0x00000001 (NEEDED) Shared library: [libuuid.so.1] 0x00000001 (NEEDED) Shared library: [libdns.so.69] 0x00000001 (NEEDED) Shared library: [libisc.so.62] 0x00000001 (NEEDED) Shared library: [librt.so.1] 0x00000001 (NEEDED) Shared library: [libkrb5support.so.0] 0x00000001 (NEEDED) Shared library: [libkrb5.so.25] 0x00000001 (NEEDED) Shared library: [libgssapi.so.2] 0x00000001 (NEEDED) Shared library: [libCryptolib.so.0] 0x00000001 (NEEDED) Shared library: [libimf.so] 0x00000001 (NEEDED) Shared library: [libirng.so] 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libcilkrts.so.5] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x00000001 (NEEDED) Shared library: [libsvml.so] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000e (SONAME) Library soname: [libssdk.so.0] 0x0000000f (RPATH) Library rpath: [/home/ssdk-test/Matterhorn/Skelios2/B650.10/SYSROM_SRC/NoBuildItems/common/lib/:/opt/skelios/2.0/sysroots/core2-32-skelios-linux/usr/lib/i386-linux-gnu/../i386-linux-gnu/] 0x0000000c (INIT) 0x196c88 0x0000000d (FINI) 0xae062c 0x00000004 (HASH) 0x118 0x6ffffef5 (GNU_HASH) 0x13a94 0x00000005 (STRTAB) 0x56db4 0x00000006 (SYMTAB) 0x288f4 0x0000000a (STRSZ) 1027963 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000003 (PLTGOT) 0xc2a628 0x00000002 (PLTRELSZ) 30184 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x18f6a0 0x00000011 (REL) 0x157be8 0x00000012 (RELSZ) 228024 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffe (VERNEED) 0x1579c8 0x6fffffff (VERNEEDNUM) 9 0x6ffffff0 (VERSYM) 0x151d30 0x6ffffffa (RELCOUNT) 229 0x00000000 (NULL) 0x0 Let me know in case any more information is needed to resolve the problem. Thanks in advance, Chethan -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Wednesday, May 29, 2019 2:52 AM To: openssl-users at openssl.org Subject: RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Viktor Dukhovni > Sent: Tuesday, May 28, 2019 14:21 > > > On May 28, 2019, at 11:35 AM, Michael Wojcik > wrote: > > > > Don't tell us about the ldd output. Show us. ldd output is short > > enough to > include in an email message. > > More useful than "ldd" output, is output from "readelf -d", showing > the NEEDED libraries, any RPATH, ... Well, yes, for this specific case (i.e. when looking at a dynamic-loading issue for a platform that uses ELF binaries and has the readelf utility). But I was making a more generic point: don't just tell us how you interpreted the result of an investigation when you can reasonably show us the actual evidence as well. This of course is part of the eternal and widespread problem of not knowing how to ask a good question. I'm trying to offer some general advice in that area (without being quite as verbose as ESR's "How To Ask Questions The Smart Way"). -- Michael Wojcik Distinguished Engineer, Micro Focus The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. From doctor at doctor.nl2k.ab.ca Wed May 29 13:05:48 2019 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 29 May 2019 07:05:48 -0600 Subject: Forthcoming OpenSSL Releases In-Reply-To: References: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org> Message-ID: <20190529130548.GA54662@doctor.nl2k.ab.ca> For the next branch of OpenSSL is it 1.1.2 or 1.2.0 ? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Always seek out the seed of triumph in every adversity. -Og Mandino From Michael.Wojcik at microfocus.com Wed May 29 13:43:24 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 29 May 2019 13:43:24 +0000 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: <447C096A3E2889439233CDD6DAB29F95C0F22126@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> <87blzm1xm8.wl-levitte@openssl.org> <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> <3B9189AE-F8B1-4B72-81BB-C93132ABFA4A@dukhovni.org> <447C096A3E2889439233CDD6DAB29F95C0F22126@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: > From: Chethan Kumar [mailto:Chethan.Kumar at toshiba-tsip.com] > Sent: Wednesday, May 29, 2019 04:07 > > Below is the output from ldd on application. > Seriously I didn't knew application uses these many libraries[Knew only the > problem]. > linux-gate.so.1 (0xf76fc000) > libpam.so.0 => /lib/i386-linux-gnu/libpam.so.0 (0xf6a63000) > libldap-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/libldap- > 2.4.so.2 (0xf6a29000) > libssl.so.1.1 => /home/SYSROM_SRC/build/release/lib/libssl.so.1.1 > (0xf6990000) > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf6972000) > libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 > (0xf689c000) > libcrypto.so.1.1 => > /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.1 (0xf65af000) > libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 > (0xf657e000) > libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xf6566000) > libext2fs.so.2 => /lib/i386-linux-gnu/libext2fs.so.2 (0xf6516000) > libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf6511000) > libdns.so.69 => /home/SYSROM_SRC/build/release/lib/libdns.so.69 > (0xf635c000) > libisc.so.62 => /home/SYSROM_SRC/build/release/lib/libisc.so.62 > (0xf62e7000) > librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf62de000) > libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0 > (0xf62d2000) > libkrb5.so.25 => /home/SYSROM_SRC/build/release/lib/libkrb5.so.25 > (0xf6259000) > libgssapi.so.2 => /home/SYSROM_SRC/build/release/lib/libgssapi.so.2 > (0xf6222000) > libCryptolib.so.0 => > /home/SYSROM_SRC/build/release/lib/libCryptolib.so.0 (0xf6191000) > libimf.so => /mfp/lib/libimf.so (0xf5dd8000) > libirng.so => /usr/lib/libirng.so (0xf5c6e000) > libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf5c1a000) > libcilkrts.so.5 => /usr/lib/libcilkrts.so.5 (0xf5bec000) > libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf5afd000) > libsvml.so => /mfp/lib/libsvml.so (0xf4bbf000) > libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf4bab000) > libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf4ba6000) > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf49e4000) > liblber-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/liblber- > 2.4.so.2 (0xf49d9000) > libsasl2.so.3 => /home/SYSROM_SRC/build/release/lib/libsasl2.so.3 > (0xf49a4000) > /lib/i386-linux-gnu/ld-linux.so.2 (0xf76fd000) > libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xf49a0000) > libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xf499b000) > libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 > (0xf494c000) > libcom_err.so.1 => /home/SYSROM_SRC/build/release/lib/libcom_err.so.1 > (0xf4948000) > libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/libcrypto.so.1.0.0 > (0xf476b000) So either the application program depends on libcrypto.so.1.0.0, or one of the preceding libraries does. Some path through the dependency graph leads to libcrypto.so.1.0.0. >From the readelf output below, we see it's not the application program - that only depends on libcrypto.so.1.1. So it's one of the preceding libraries. There's a good chance it's one that comes from the OS library collection rather than a library you've built (though that's by no means certain), so let's focus on ones that aren't under /home/SYSROM_SRC. Kerberos seems like a candidate, but a quick ldd on libk5crypto and libkrb5support doesn't show any libcrypto dependency. The same is true of libgssapi_krb5. Neither does libkeyutils. OpenLDAP (libldap) is generally built using NSS rather than OpenSSL, so it doesn't usually link libcrypto. None of the other OS libraries above look particularly likely to use libcrypto. So I'd suggest you use ldd on each of the libraries listed above to find out which is giving you the dependency on libcrypto.so.1.0.0. Or use LD_DEBUG to generate a loader report for your application, and work backward from that. Writing a script to use readelf to generate a dependency graph report showing the path for each dependency is left as an exercise for the reader. -- Michael Wojcik Distinguished Engineer, Micro Focus From dengwenbin_0301 at 126.com Wed May 29 14:03:57 2019 From: dengwenbin_0301 at 126.com (dengwenbin_0301) Date: Wed, 29 May 2019 22:03:57 +0800 (GMT+08:00) Subject: Fw: Building openssl outside of the source tree" doesn't work well Message-ID: <36733df0.8615.16b03e7965a.Coremail.dengwenbin_0301@126.com> Please help have a look. | | dengwenbin_0301 ???dengwenbin_0301 at 126.com | Signature is customized by Netease Mail Master --------- Forwarded Message --------- From: dengwenbin_0301 Date: 05/27/2019 14:24 To: Richard Levitte Subject: Re:Re: Fw:Re:Re: Building openssl outside of the source tree" doesn't work well Sorry, the previously attached dump might too large to send out successfully. I copied it directly here. Command line (with current working directory = .): /usr/bin/perl ../Configure linux-x86_64 Perl information: /usr/bin/perl 5.22.1 for x86_64-linux-gnu-thread-multi Enabled features: afalgeng aria asm async autoalginit autoerrinit autoload-config bf blake2 camellia capieng cast chacha cmac cms comp crmf ct deprecated des dgram dh dsa dtls dynamic-engine ec ec2m ecdh ecdsa engine err filenames fips gost idea legacy makedepend md4 mdc2 module multiblock nextprotoneg pinshared ocb ocsp padlockeng pic poly1305 posix-io psk rc2 rc4 rdrand rfc3779 rmd160 scrypt seed shared siphash siv 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: ktls [default] OPENSSL_NO_KTLS asan [default] OPENSSL_NO_ASAN buildtest-c++ [default] 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 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 trace [default] OPENSSL_NO_TRACE ubsan [default] OPENSSL_NO_UBSAN unit-test [default] OPENSSL_NO_UNIT_TEST weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS zlib [default] zlib-dynamic [default] ssl3 [default] OPENSSL_NO_SSL3 ssl3-method [default] OPENSSL_NO_SSL3_METHOD Config target attributes: AR => "ar", ARFLAGS => "r", CC => "gcc", CFLAGS => "-Wall -O3", CXX => "g++", CXXFLAGS => "-Wall -O3", 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 => "-pthread -m64", 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 => "", cpuid_asm_src => "x86_64cpuid.s", cpuid_obj => "x86_64cpuid.o", cxxflags => "-std=c++11 -pthread -m64", defines => [ ], des_asm_src => "des_enc.c fcrypt_b.c", des_obj => "des_enc.o fcrypt_b.o", disable => [ ], dso_ldflags => "-z defs", 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 => [ "afalgeng" ], ex_libs => "-ldl -pthread", includes => [ ], keccak1600_asm_src => "keccak1600-x86_64.s", keccak1600_obj => "keccak1600-x86_64.o", lflags => "", lib_cflags => "", lib_cppflags => "-DOPENSSL_USE_NODELETE -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 => "-fPIC", module_cxxflags => "", module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic", multilib => "64", padlock_asm_src => "e_padlock-x86_64.s", padlock_obj => "e_padlock-x86_64.o", perl_platform => "Unix", 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 => "-fPIC", shared_defflag => "-Wl,--version-script=", shared_defines => [ ], shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic", shared_rcflag => "", shared_sonameflag => "-Wl,-soname=", shared_target => "linux-shared", 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 = CFLAGS = CPP = CPPDEFINES = CPPFLAGS = CPPINCLUDES = CROSS_COMPILE = CXX = CXXFLAGS = HASHBANGPERL = LD = LDFLAGS = LDLIBS = MT = MTFLAGS = OPENSSL_LOCAL_CONFIG_DIR = 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 = gcc CFLAGS = -Wall -O3 CPPDEFINES = CPPFLAGS = CPPINCLUDES = CXX = g++ CXXFLAGS = -Wall -O3 HASHBANGPERL = /usr/bin/env perl LDFLAGS = LDLIBS = PERL = /usr/bin/perl RANLIB = ranlib RC = windres RCFLAGS = 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 Thanks, Wenbin zAt 2019-05-24 20:23:58, "Richard Levitte" wrote: >Well, those -I options are directly generated from 'INCLUDE' >statements in build.info files. > >Would you mind giving me the output from this command? > > perl configdata.pm --dump > >Cheers, >Richard > >On Fri, 24 May 2019 04:45:11 +0200, >dengwenbin_0301 wrote: >> >> >> I tried on openssl-1.1.1a and openssl-1.1.1b and they all have the same issue. I think it has >> something to do with my env. But i am not able to figure out what is the cause. >> >> Thanks, >> Wenbin >> >> -------- Forwarding messages -------- >> From: "dengwenbin_0301" >> Date: 2019-05-22 09:40:19 >> To: "Richard Levitte" >> Subject: Re:Re: Building openssl outside of the source tree" doesn't work well >> Thanks for your reply, Richard. >> >> Yes, the "-Iinclude -Iapps/include" is missing. I don't know why this happened. I attached the >> the configdata.pm and its dump. Please help have a check. >> >> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ git log -n 1 >> commit d3136af3c3905a730bd8fb44158aab36a2549d9b >> Author: Richard Levitte >> Date: Sat May 18 16:24:21 2019 -0700 >> >> Configure: let platform->dsoext() default with platform->shlibextsimple() >> >> We still use '.so' as a last resort... >> >> Fixes #8950 >> >> Reviewed-by: Tim Hudson >> (Merged from https://github.com/openssl/openssl/pull/8951) >> >> At 2019-05-21 11:47:14, "Richard Levitte" wrote: >> >On Tue, 21 May 2019 03:26:41 +0200, >> >dengwenbin_0301 wrote: >> >> >> >> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl [master]$ cd obj/ >> >> >> >> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ ../config >> >> Operating system: x86_64-whatever-linux2 >> >> Configuring OpenSSL version 3.0.0-dev for target linux-x86_64 >> >> Using os-specific seed configuration >> >> Creating configdata.pm >> >> Creating Makefile >> >> >> >> ********************************************************************** >> >> *** *** >> >> *** OpenSSL has been successfully configured *** >> >> *** *** >> >> *** If you encounter a problem while building, please open an *** >> >> *** issue on GitHub ; *** >> >> *** and include the output from the following command: *** >> >> *** *** >> >> *** perl configdata.pm --dump *** >> >> *** *** >> >> *** (If you are new to OpenSSL, you might want to consult the *** >> >> *** 'Troubleshooting' section in the INSTALL file first) *** >> >> *** *** >> >> ********************************************************************** >> >> wdeng:~/wenbindfiles/openssl/openssl/obj [master]$ make >> >> make depend && make _all >> >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' >> >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' >> >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' >> >> gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN >> >> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 >> >> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM >> >> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM >> >> -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr >> >> /local/lib/ossl-modules\"" -DNDEBUG -MMD -MF apps/libapps-lib-app_rand.d.tmp -MT apps/ >> >> libapps-lib-app_rand.o -c -o apps/libapps-lib-app_rand.o ../apps/app_rand.c >> >> ../apps/app_rand.c:10:18: fatal error: apps.h: No such file or directory >> >> compilation terminated. >> >> Makefile:826: recipe for target 'apps/libapps-lib-app_rand.o' failed >> >> make[1]: *** [apps/libapps-lib-app_rand.o] Error 1 >> >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' >> >> Makefile:165: recipe for target 'all' failed >> >> make: *** [all] Error 2 >> > >> >I tried exactly that just now, exactly same 'obj' ubdirectory, and it >> >works with no problem. >> > >> >Something I'm noticing from your command line is that all -I options >> >that I expect to see there are gone. This is what I expect (note that >> >I go directly at the object file for demonstration purposes): >> > >> > : ; make apps/libapps-lib-app_rand.o >> > gcc -I. -Iinclude -Iapps/include -I.. -I../include >> > -I../apps/include -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 >> > -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC >> > -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT >> > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM >> > -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM >> > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM >> > -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" >> > -DENGINESDIR="\"/usr/local/lib/engines-3\"" >> > -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG -MMD -MF >> > apps/libapps-lib-app_rand.d.tmp -MT apps/libapps-lib-app_rand.o -c >> > -o apps/libapps-lib-app_rand.o ../apps/app_rand.c >> > >> >So the question is what happened to '-I. -Iinclude -Iapps/include >> >-I.. -I../include -I../apps/include' in your build. >> > >> >I cannot say right now, but it might help if you show the output from >> >'./configdata.pm --dump' >> > >> >Cheers, >> >Richard >> > >> >-- >> >Richard Levitte levitte at openssl.org >> >OpenSSL Project http://www.openssl.org/~levitte/ >> >> >> >> >-- >Richard Levitte levitte at openssl.org >OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed May 29 14:12:24 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 29 May 2019 16:12:24 +0200 Subject: Performance Issue With OpenSSL 1.1.1c In-Reply-To: <20190528214851.YWZds%steffen@sdaoden.eu> References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> <84571f12-68b3-f7ee-7896-c891a2e253e7@roadrunner.com> <20190528214851.YWZds%steffen@sdaoden.eu> Message-ID: <23f8b94d-0078-af3c-b46a-929b9d0054ea@wisemo.com> On 28/05/2019 23:48, Steffen Nurpmeso wrote: > Jay Foster wrote in <84571f12-68b3-f7ee-7896-c891a2e253e7 at roadrunner.com>: > |On 5/28/2019 10:39 AM, Jay Foster wrote: > |> I built OpenSSL 1.1.1c from the recent release, but have noticed what > |> seems like a significant performance drop compared with 1.1.1b.? I > |> notice this when starting lighttpd.? With 1.1.1b, lighttpd starts in a > |> few seconds, but with 1.1.1c, it takes several minutes. > |> > |> I also noticed that with 1.1.1b, the CFLAGS automatically included > |> '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the > |> CFLAGS.? was this dropped?? I? added '-Wall -O3' to the CFLAGS, but > |> this did not seem to have any affect on the performance issue > |> (unrelated?). > |> > |> This is for a 32-bit ARM build. > |> > |> Jay > |> > |I think I have tracked down the change in 1.1.1c that is causing this. > |It is the addition of the DEVRANDOM_WAIT functionality for linux in > |e_os.h and crypto/rand/rand_unix.c.? lighttpd (libcrypto) is waiting in > |a select() call on /dev/random.? After this eventually wakes up, it then > |reads from /dev/urandom.? OpenSSL 1.1.1b did not do this, but instead > |just read from /dev/urandom.? Is there more information about this > |change (i.e., a rationale)?? I did not see anything in the CHANGES file > |about it. > > I do not know why lighttpd ends up on /dev/random for you, but in > my opinion the Linux random stuff is both sophisticated and sucks. > The latter because (it seems that many) people end up using > haveged or similar to pimp up their entropy artificially, whereas > on the other side the initial OS seeding is no longer truly > supported. Writing some seed to /dev/urandom does not bring any > entropy to the "real" pool. Something equivalent to your program (but not storing a bitcount field) used to be standard in Linux boot scripts before systemd.? But it typically used the old method of just writing the saved random bits into /dev/{u,}random . This makes me very surprised that they removed such a widely used interface, can you point out when that was removed from the Linux kernel? 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 steffen at sdaoden.eu Wed May 29 15:06:24 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 29 May 2019 17:06:24 +0200 Subject: Performance Issue With OpenSSL 1.1.1c In-Reply-To: <23f8b94d-0078-af3c-b46a-929b9d0054ea@wisemo.com> References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> <84571f12-68b3-f7ee-7896-c891a2e253e7@roadrunner.com> <20190528214851.YWZds%steffen@sdaoden.eu> <23f8b94d-0078-af3c-b46a-929b9d0054ea@wisemo.com> Message-ID: <20190529150624.mRkIC%steffen@sdaoden.eu> Jakob Bohm via openssl-users wrote in <23f8b94d-0078-af3c-b46a-929b9d005\ 4ea at wisemo.com>: |On 28/05/2019 23:48, Steffen Nurpmeso wrote: |> Jay Foster wrote in <84571f12-68b3-f7ee-7896-c891a2e253e7 at roadrunner.com\ |> >: |>|On 5/28/2019 10:39 AM, Jay Foster wrote: |>|> I built OpenSSL 1.1.1c from the recent release, but have noticed what |>|> seems like a significant performance drop compared with 1.1.1b.? I |>|> notice this when starting lighttpd.? With 1.1.1b, lighttpd starts in a |>|> few seconds, but with 1.1.1c, it takes several minutes. ... |>|I think I have tracked down the change in 1.1.1c that is causing this. |>|It is the addition of the DEVRANDOM_WAIT functionality for linux in |>|e_os.h and crypto/rand/rand_unix.c.? lighttpd (libcrypto) is waiting in |>|a select() call on /dev/random.? After this eventually wakes up, it then |>|reads from /dev/urandom.? OpenSSL 1.1.1b did not do this, but instead |>|just read from /dev/urandom.? Is there more information about this |>|change (i.e., a rationale)?? I did not see anything in the CHANGES file |>|about it. ... |> I do not know why lighttpd ends up on /dev/random for you, but in |> my opinion the Linux random stuff is both sophisticated and sucks. P.S.: i have now looked at the OpenSSL code and understand what you have said. It indeed selects on /dev/random. |> The latter because (it seems that many) people end up using |> haveged or similar to pimp up their entropy artificially, whereas |> on the other side the initial OS seeding is no longer truly |> supported. Writing some seed to /dev/urandom does not bring any |> entropy to the "real" pool. |Something equivalent to your program (but not storing a bitcount field) |used to be standard in Linux boot scripts before systemd.? But it |typically used the old method of just writing the saved random bits |into /dev/{u,}random . Oh, still, for example AlpineLinux did (and still does i think, using a script originating from Gentoo aka OpenRC) save a kilobyte of /dev/urandom storage, to restore it upon next boot. But it does not feed the pool which feds /dev/random, it does not count against /proc/sys/kernel/random/entropy_avail. Even that i can understand a little bit (physical access would reveal data stored in the entropy file), even though the entropy is not used but passed through state machines, which could be furtherly randomized when fed back in, like also dependent on the host hardware environment interrupts which happen and depend on actual devices i'd say, and while doing so. But you loose all the entropy that the machine collected during its last uptime, so you solely depend on some CPU features and the noise that system startup produces to create a startup entropy. After running in the problem and looking around i realized that many people seem to run the haveged daemon (there is also a kernel module which does something like this, but using it did not help me out), which applies some maths, and it is mystic as it can produce thousands of random bits in less than a second! Even on my brand new laptop, which (stepped a decade of hardware development for me and) has a 8th generation i5, i see hangs of several seconds (iirc) without the little helper i attached in the last message. With it i have a (SysV init/BSD rc script aka CRUX-Linux) boot time of two seconds, which is so horny i have to write it down. |This makes me very surprised that they removed such a widely used |interface, can you point out when that was removed from the Linux |kernel? Hm, ok, what they have actually removed was the RNDGETPOOL ioctl(2) (according to random(4)). Then my claim regarding deprecation was misleaded and wrong. Nonetheless it has to be said that today an administrator does not have, that is, i have no idea whether systemd provides something to overcome this, the possibility to simply feed in good entropy via a shell script, unless i am mistaken. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From Matthias.St.Pierre at ncp-e.com Wed May 29 15:11:02 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Wed, 29 May 2019 17:11:02 +0200 Subject: Forthcoming OpenSSL Releases In-Reply-To: <20190529130548.GA54662@doctor.nl2k.ab.ca> References: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org> <20190529130548.GA54662@doctor.nl2k.ab.ca> Message-ID: <9eb5ac75-77ff-773b-e364-728edc198a63@ncp-e.com> On 29.05.19 15:05, The Doctor wrote: > For the next branch of OpenSSL is it 1.1.2 or 1.2.0 ? > The next major release will be 3.0.0. See https://www.openssl.org/blog/blog/2018/11/28/version for an explanation. Matthias From tmraz at redhat.com Wed May 29 15:16:20 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 29 May 2019 17:16:20 +0200 Subject: Performance Issue With OpenSSL 1.1.1c In-Reply-To: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> Message-ID: On Tue, 2019-05-28 at 10:39 -0700, Jay Foster wrote: > I built OpenSSL 1.1.1c from the recent release, but have noticed > what > seems like a significant performance drop compared with 1.1.1b. I > notice this when starting lighttpd. With 1.1.1b, lighttpd starts in > a > few seconds, but with 1.1.1c, it takes several minutes. > > I also noticed that with 1.1.1b, the CFLAGS automatically included > '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in > the > CFLAGS. was this dropped? I added '-Wall -O3' to the CFLAGS, but > this > did not seem to have any affect on the performance issue > (unrelated?). > > This is for a 32-bit ARM build. To workaround the /dev/random blocking issue, you can just add: -DDEVRANDOM="\"/dev/urandom\"" as a parameter to ./Configure This will remove the special handling of /dev/urandom and /dev/random in 1.1.1c. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From rama.krushna7 at gmail.com Wed May 29 17:39:38 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Wed, 29 May 2019 23:09:38 +0530 Subject: Reg missing rc4-ia64.pl in openssl 1.1.1 Message-ID: Hi, In Openssl 1.1.1, the file "rc4-ia64.pl" is missing. This cause degradation of performance on AIX. Is this intentional for deprecating the support for RC4 ? Similarly If I build Openssl 1.1.1 on nt64 with flags "*enable-weak-ssl-ciphers" and "**enable-deprecated" , *I witness degrade in performance. Could you please help me understand how these flags can be related to speed test of all ciphers and digests ? Thanks and Regards, Ram Krushna -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed May 29 18:33:00 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 May 2019 14:33:00 -0400 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> <87blzm1xm8.wl-levitte@openssl.org> <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> <3B9189AE-F8B1-4B72-81BB-C93132ABFA4A@dukhovni.org> <447C096A3E2889439233CDD6DAB29F95C0F22126@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: <89F479C9-6F38-4E8E-954F-071D4A8C7DCC@dukhovni.org> > On May 29, 2019, at 9:43 AM, Michael Wojcik wrote: > > So either the application program depends on libcrypto.so.1.0.0, or one of the preceding libraries does. Some path through the dependency graph leads to libcrypto.so.1.0.0. Not only is the application (dynamically) linked against two different versions of OpenSSL's crypto library, it is also using both Heimdal and MIT Kerberos, which may also cause some confusion if symbol versioning does not fully take care of the overlapping APIs. > Kerberos seems like a candidate, but a quick ldd on libk5crypto and libkrb5support doesn't show any libcrypto dependency. The same is true of libgssapi_krb5. Neither does libkeyutils. Heimdal might be linked against OpenSSL. > OpenLDAP (libldap) is generally built using NSS rather than OpenSSL, so it doesn't usually link libcrypto. It is also often built against OpenSSL, the choice is rather platform-dependent. This application is a classic case of DLL-hell. On the OpenSSL side, it could benefit from the "shlib_variant" feature of the 1.1.1 builds. But if the base system's OpenSSL libraries are adequate, the OP may be better off just using those. -- Viktor. From mcr at sandelman.ca Wed May 29 18:36:42 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 29 May 2019 14:36:42 -0400 Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In-Reply-To: <447C096A3E2889439233CDD6DAB29F95C0F22126@tosblrmbx04.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95BF3CB748@tosblrmbx04.TOSHIBA-TSIP.COM> <447C096A3E2889439233CDD6DAB29F95C0F21E0F@tosblrmbx04.TOSHIBA-TSIP.COM> <87blzm1xm8.wl-levitte@openssl.org> <447C096A3E2889439233CDD6DAB29F95C0F21F87@tosblrmbx04.TOSHIBA-TSIP.COM> <3B9189AE-F8B1-4B72-81BB-C93132ABFA4A@dukhovni.org> <447C096A3E2889439233CDD6DAB29F95C0F22126@tosblrmbx04.TOSHIBA-TSIP.COM> Message-ID: <11557.1559155002@localhost> Chethan Kumar wrote: > Sorry for the inconvenience caused by not asking query clearly. > Below is the output from ldd on application. Right, and now you need to recursively go through the list with readelf or ldd, and which out which one of these libraries then requires libcrypto.1.0.0. My bet is on some of the krb libraries, likely required by sqlite or perhaps something else like this libCryptolib.so.0. Also, run your application, and use "lsof -p PID" to see the list of libraries loaded as some dependancies may be done at runtime by dlopen(). -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jetson23 at hotmail.com Wed May 29 19:44:26 2019 From: jetson23 at hotmail.com (Jason Schultz) Date: Wed, 29 May 2019 19:44:26 +0000 Subject: X509_STORE_CTX_get1_certs Message-ID: It looks like this function is available in OpenSSL 1.1.1 (not available in 1.0.2) and I think I need to use it, but I can't find documentation for it anywhere. Is this an over site, or am I missing something obvious? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed May 29 20:21:15 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 May 2019 16:21:15 -0400 Subject: X509_STORE_CTX_get1_certs In-Reply-To: References: Message-ID: <20190529202115.GS67454@straasha.imrryr.org> On Wed, May 29, 2019 at 07:44:26PM +0000, Jason Schultz wrote: > It looks like this function is available in OpenSSL 1.1.1 (not available > in 1.0.2) and I think I need to use it, but I can't find documentation for > it anywhere. In 1.0.2 it was called X509_STORE_get1_certs(). > Is this an over site, or am I missing something obvious? It has not yet been documented. -- Viktor. From levitte at openssl.org Wed May 29 20:53:01 2019 From: levitte at openssl.org (Richard Levitte) Date: Wed, 29 May 2019 22:53:01 +0200 Subject: Reg missing rc4-ia64.pl in openssl 1.1.1 In-Reply-To: References: Message-ID: <87v9xtyocy.wl-levitte@openssl.org> On Wed, 29 May 2019 19:39:38 +0200, ramakrushna mishra wrote: > In Openssl 1.1.1,? the file "rc4-ia64.pl" is missing. This cause degradation of performance on > AIX.? Is this intentional for deprecating the support for RC4 ?? It got remove as part of a larger cleanup commit: commit 624265c60e07f8e5f251d0f5b79e34cf0221af73 Author: Rich Salz Date: Thu Jun 15 12:03:40 2017 -0400 Cleanup some copyright stuff Remove some incorrect copyright references. Move copyright to standard place Add OpenSSL copyright where missing. Remove copyrighted file that we don't use any more Remove Itanium assembler for RC4 and MD5 (assembler versions of old and weak algorithms for an old chip) Standardize apps/rehash copyright comment; approved by Timo Put dual-copyright notice on mkcert Reviewed-by: Richard Levitte (Merged from https://github.com/openssl/openssl/pull/3691) > Similarly If I build Openssl 1.1.1 on nt64? with flags "enable-weak-ssl-ciphers" and " > enable-deprecated"? , I witness degrade in performance.? Could you please help me understand how > these flags can be related to speed test of all ciphers and digests ?? Degradation, compared to what? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jeremy.farrell at oracle.com Wed May 29 21:01:42 2019 From: jeremy.farrell at oracle.com (J. J. Farrell) Date: Wed, 29 May 2019 22:01:42 +0100 Subject: Reg missing rc4-ia64.pl in openssl 1.1.1 In-Reply-To: References: Message-ID: On 29/05/2019 18:39, ramakrushna mishra wrote: > > In Openssl 1.1.1,? the file "rc4-ia64.pl " is > missing. This cause degradation of performance on AIX. ... The AIX port to Itanium was never released as a product, and was abandoned altogether in 2002; I'm surprised that a degradation of performance on it matters to anyone. -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Thu May 30 00:11:19 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 30 May 2019 00:11:19 +0000 Subject: AW: Performance Issue With OpenSSL 1.1.1c In-Reply-To: References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> Message-ID: > To workaround the /dev/random blocking issue, you can just add: > > -DDEVRANDOM="\"/dev/urandom\"" > > as a parameter to ./Configure > > This will remove the special handling of /dev/urandom and /dev/random > in 1.1.1c. Tom??, Jay, I'm afraid this suggestion won't help, because `DEVRANDOM_WAIT` is defined unconditionally in e_os.h: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/e_os.h#L30-L34 This means that the select() call will happen on linux independently of what `DEVRANDOM` is defined to be: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/crypto/rand/rand_unix.c#L509-L535 I think that pull request #8251 needs to be reconsidered. Give me one day or two, I'll create a GitHub issue for that and post the link here when it's ready. Matthias From Michael.Wojcik at microfocus.com Thu May 30 00:10:27 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 30 May 2019 00:10:27 +0000 Subject: Reg missing rc4-ia64.pl in openssl 1.1.1 In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of J. J. Farrell > Sent: Wednesday, May 29, 2019 15:02 > On 29/05/2019 18:39, ramakrushna mishra wrote: >> In Openssl 1.1.1, the file "rc4-ia64.pl" is missing. This cause degradation of >> performance on AIX. ... > The AIX port to Itanium was never released as a product, and was abandoned > altogether in 2002; I'm surprised that a degradation of performance on it > matters to anyone. What, no love for unobtainable archaic platforms? Personally, I'm bemoaning the lack of a rc4-romp.pl for AIX 2 on my RT PC. And the shocking lack of assembly modules for the PDP-11. In all seriousness: It's pretty cool that OpenSSL still includes assembly modules for what are now rather niche architectures such as MIPS and PA-RISC. And in case all this is too convoluted for the OP, rc4-ia64.pl doesn't apply to extant AIX systems, which are all some variant of POWER, not IA64. (OK, somewhere someone probably has one of the other AIX variants running - AIX/390 might be the last non-POWER AIX to die, if I had to bet. But probably not AIX IA64.) -- Michael Wojcik Distinguished Engineer, Micro Focus From Matthias.St.Pierre at ncp-e.com Thu May 30 00:16:41 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 30 May 2019 00:16:41 +0000 Subject: AW: Performance Issue With OpenSSL 1.1.1c In-Reply-To: References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com> Message-ID: Correction, Tom?? was correct: there is an ` # ifndef DEVRANDOM` surrounding the problematic code: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/e_os.h#L25-L34 Neverthelesss, I still think this code needs to be changed, because the seeding should just work correctly out-of-the-box without having to add special defines on the commandline. Matthias From rama.krushna7 at gmail.com Thu May 30 03:07:31 2019 From: rama.krushna7 at gmail.com (ramakrushna mishra) Date: Thu, 30 May 2019 08:37:31 +0530 Subject: Reg missing rc4-ia64.pl in openssl 1.1.1 In-Reply-To: References: Message-ID: Hi, Thanks for all the information related to missing rc4 assembly file for IA-64 architecture. *Richard : * The following mentioned degradation on nt64 compared to the same openssl version 1.1.1 build with out using the flags " "enable-weak-ssl-ciphers" and " enable-deprecated" . Thanks and Regards, Ram Krushna > Similarly If I build Openssl 1.1.1 on nt64? with flags > "enable-weak-ssl-ciphers" and " > > enable-deprecated"? , I witness degrade in performance.? Could you > please help me understand how > > these flags can be related to speed test of all ciphers and digests ?? > > Degradation, compared to what? > > Cheers, > Richard > > End of openssl-users Digest, Vol 54, Issue 49 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetson23 at hotmail.com Thu May 30 17:02:08 2019 From: jetson23 at hotmail.com (Jason Schultz) Date: Thu, 30 May 2019 17:02:08 +0000 Subject: X509_STORE_CTX_get1_certs In-Reply-To: <20190529202115.GS67454@straasha.imrryr.org> References: , <20190529202115.GS67454@straasha.imrryr.org> Message-ID: I see. Can anyone summarize what X509_STORE_CTX_get1_certs() is doing so I can make sure my understanding of it is correct? Thanks. ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Wednesday, May 29, 2019 8:21 PM To: openssl-users at openssl.org Subject: Re: X509_STORE_CTX_get1_certs On Wed, May 29, 2019 at 07:44:26PM +0000, Jason Schultz wrote: > It looks like this function is available in OpenSSL 1.1.1 (not available > in 1.0.2) and I think I need to use it, but I can't find documentation for > it anywhere. In 1.0.2 it was called X509_STORE_get1_certs(). > Is this an over site, or am I missing something obvious? It has not yet been documented. -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swamy.j-s at in.abb.com Fri May 31 03:55:46 2019 From: swamy.j-s at in.abb.com (Swamy J-S) Date: Fri, 31 May 2019 03:55:46 +0000 Subject: c2i_ASN1_INTEGER function in Openssl 1.1.0 Message-ID: Hi, I recently updated openssl from 1.0.2n to 1.1.0g in linux system. Earlier I was using "ASN1_INTEGER *c2i_ASN1_INTEGER(ASN1_INTEGER **a, const unsigned char **pp, long len) " function. As this function is removed in openssl 1.1.0, now i replaced this with "ASN1_INTEGER *d2i_ASN1_UINTEGER(ASN1_INTEGER **a, const unsigned char **pp, long length)". Now when i build my application then i get warning as "Warning:0:-- SSL Error queue report -- Warning:0: - asn1 encoding routines|d2i_ASN1_UINTEGER|expecting an integer:218718323". What is the solution for this problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri May 31 08:41:04 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 31 May 2019 09:41:04 +0100 Subject: c2i_ASN1_INTEGER function in Openssl 1.1.0 In-Reply-To: References: Message-ID: <331091bb-4135-d4ff-b4ff-fca412d9f3a4@openssl.org> On 31/05/2019 04:55, Swamy J-S wrote: > Hi, > > > I recently updated openssl from 1.0.2n to 1.1.0g in linux system. > > > Earlier I was using > > "ASN1_INTEGER **c2i_ASN1_INTEGER*(ASN1_INTEGER **a, const unsigned char **pp, > long len) " function. As this function is removed in openssl 1.1.0, now i > replaced this with > > > "ASN1_INTEGER **d2i_ASN1_UINTEGER*(ASN1_INTEGER **a, const unsigned char **pp, > long length)".? > > Now when i build my application then i get warning as > > *"Warning:0:-- SSL Error queue report --* > *Warning:0: - asn1 encoding routines|d2i_ASN1_UINTEGER|expecting an > integer:218718323".* > * > * > * > * > What is the solution for this problem? > I spotted your stack exchange question on this before I spotted your question on this list. I'll repost my stack exchange answer here as well: ASN.1 encoding of an INTEGER (as BER or DER) consists of 1 or more "identifier" octets (usually 1), followed by 1 or more "length" octets, followed by "content" octets (the length of which is determined by the previous "length" octets). The function c2i_ASN1_INTEGER assumes you have already parsed the "identifier" and "length" octets and coverts the "content" bytes into an integer. This was removed from OpenSSL 1.1.0 because this is considered a very low level parsing operation that applications should not be calling directly. The function d2i_ASN1_UINTEGER is not a direct drop in replacement for c2i_ASN1_INTEGER. It parses the whole integer (including the "identifier" and "length" octets). If you pass it just the content octets then it will interpret the first byte as an "identifier" octet. This will likely have the wrong value for an integer and so this is probably why you are seeing the "expecting an integer" error. You will need to rewrite your code to pass the whole integer to d2i_ASN1_UINTEGER. Matt From jb-openssl at wisemo.com Fri May 31 15:23:13 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 31 May 2019 17:23:13 +0200 Subject: Reg missing rc4-ia64.pl in openssl 1.1.1 In-Reply-To: References: Message-ID: <78f27aca-3e65-6624-3385-e022eb06cd33@wisemo.com> On 30/05/2019 02:10, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of J. J. Farrell >> Sent: Wednesday, May 29, 2019 15:02 >> On 29/05/2019 18:39, ramakrushna mishra wrote: >>> In Openssl 1.1.1, the file "rc4-ia64.pl" is missing. This cause degradation of >>> performance on AIX. ... >> The AIX port to Itanium was never released as a product, and was abandoned >> altogether in 2002; I'm surprised that a degradation of performance on it >> matters to anyone. > What, no love for unobtainable archaic platforms? Note that while the OP may actually be running AIX (old beta or special contract), IA64 had publicly released OS versions of Linux, HP-UX, Windows (NT 5.01 to NT 6.01) and possibly others. Linux IA64 may or may not be in some supported distributions (in addition to site OS builds), don't know the status of HP-UX IA64, Windows NT 6.01 (== Server 2008R2) is still publicly supported by Microsoft with options to buy private support years on top. > Personally, I'm bemoaning the lack of a rc4-romp.pl for AIX 2 on my RT PC. And the shocking lack of assembly modules for the PDP-11. > > In all seriousness: It's pretty cool that OpenSSL still includes assembly modules for what are now rather niche architectures such as MIPS and PA-RISC. And in case all this is too convoluted for the OP, rc4-ia64.pl doesn't apply to extant AIX systems, which are all some variant of POWER, not IA64. MIPS is still a common platform in Linux-based routers, which generally use OpenSSL as their main cryptographic library for everything from WiFi security to OpenVPN and browser configuration.? As these are often speed constrained chips, assembler optimizations are important.? While ARM was making inroads in this market, RiscV or an Asian design are more likely successor for low cost low power router hardware. > (OK, somewhere someone probably has one of the other AIX variants running - AIX/390 might be the last non-POWER AIX to die, if I had to bet. But probably not AIX IA64.) 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 jeremy.farrell at oracle.com Fri May 31 18:10:47 2019 From: jeremy.farrell at oracle.com (J. J. Farrell) Date: Fri, 31 May 2019 19:10:47 +0100 Subject: Reg missing rc4-ia64.pl in openssl 1.1.1 In-Reply-To: <78f27aca-3e65-6624-3385-e022eb06cd33@wisemo.com> References: <78f27aca-3e65-6624-3385-e022eb06cd33@wisemo.com> Message-ID: <8d40dca6-bda7-6d8b-06bb-116764768f67@oracle.com> On 31/05/2019 16:23, Jakob Bohm via openssl-users wrote: > On 30/05/2019 02:10, Michael Wojcik wrote: >>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >>> Behalf Of J. J. Farrell >>> On 29/05/2019 18:39, ramakrushna mishra wrote: >>>> In Openssl 1.1.1,? the file "rc4-ia64.pl" is missing. This cause >>>> degradation of >>>> performance on AIX. ... >>> The AIX port to Itanium was never released as a product, and was >>> abandoned >>> altogether in 2002; I'm surprised that a degradation of performance >>> on it >>> matters to anyone. >> What, no love for unobtainable archaic platforms? > Note that while the OP may actually be running AIX (old beta or special > contract), IA64 had publicly released OS versions of Linux, HP-UX, > Windows > (NT 5.01 to NT 6.01) and possibly others. Linux IA64 may or may not be in > some supported distributions (in addition to site OS builds), don't know > the status of HP-UX IA64, As I understand it, HP-UX on IA64 has normal "factory" support through to the end of 2025 "at least"; I expect there'll be options to pay a lot for support beyond the end of factory support. -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetson23 at hotmail.com Fri May 31 19:20:21 2019 From: jetson23 at hotmail.com (Jason Schultz) Date: Fri, 31 May 2019 19:20:21 +0000 Subject: OpenSSL server sending certificate chain(inc. root cert) during handshake Message-ID: I believe this behavior is common among all supported versions of OpenSSL, but most of my testing has been with OpenSSL 1.0.2, the latest LTS release. My application using OpenSSL is acting as a server. I have a server certificate configured that has been signed by a self-signed/root certificate, so the chain is only the server certificate and the root certificate. The certificates were created using OpenSSL, for non-production use only. The server application is calling SSL_CTX_use_certificate_file() to load the server cert, residing in /etc/ssl/certs. Depending on what's in /etc/ssl/certs, the handshake behavior will show 1 of 2 things: 1. If only the server certificate (and NOT the self-signed root cert) is in /etc/ssl/certs/, only the server certificate will be presented in the handshake. 2. If the server AND self-signed root certificates are in /etc/ssl/certs/, the entire chain will be presented during the handshake. My questions deal with #2: Why does OpenSSL include the root cert in the certificate chain? Will the root cert be included in the chain any time it's in the same directory as the server cert? Is there a way, via API call, configuration, etc, to force OpenSSL to NOT send the root certificate as part of the chain in this case? Or is there something more basic I'm missing? Googling for answers has not proved fruitful as there are a lot of results, none of which pertain to my situation...although my google fu may be lacking. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vieuxtech at gmail.com Fri May 31 19:32:43 2019 From: vieuxtech at gmail.com (Sam Roberts) Date: Fri, 31 May 2019 21:32:43 +0200 Subject: OpenSSL server sending certificate chain(inc. root cert) during handshake In-Reply-To: References: Message-ID: The root cert is not used for validation, so it doesn't have to be sent. However, sending it does no harm, and it is useful for humans who are attempting to diagnose problems, it allows them to see what what root cert they are expected to have locally for sucessful cert chain validation. From jetson23 at hotmail.com Fri May 31 19:45:01 2019 From: jetson23 at hotmail.com (Jason Schultz) Date: Fri, 31 May 2019 19:45:01 +0000 Subject: OpenSSL server sending certificate chain(inc. root cert) during handshake In-Reply-To: References: , Message-ID: Right, I realize it doesn't have to be sent, my questions are why is it sent and is there a way to force OpenSSL to not send it? You may have answered the first question as to "why?". But is OpenSSL doing this just to make problems easier to diagnose? Are there other reasons? More importantly, can I force OpenSSL to not send the root cert? Thanks, Jason ________________________________ From: Sam Roberts Sent: Friday, May 31, 2019 7:32 PM To: Jason Schultz Cc: openssl-users at openssl.org Subject: Re: OpenSSL server sending certificate chain(inc. root cert) during handshake The root cert is not used for validation, so it doesn't have to be sent. However, sending it does no harm, and it is useful for humans who are attempting to diagnose problems, it allows them to see what what root cert they are expected to have locally for sucessful cert chain validation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri May 31 21:44:36 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 31 May 2019 17:44:36 -0400 Subject: OpenSSL server sending certificate chain(inc. root cert) during handshake In-Reply-To: References: Message-ID: <62B54780-8757-42BB-8C85-559C0A2DE174@dukhovni.org> > On May 31, 2019, at 3:20 PM, Jason Schultz wrote: > > My questions deal with #2: Why does OpenSSL include the root cert in the certificate chain? The OpenSSL SSL_CTX_build_cert_chain(3) function constructs a complete chain of trust for your certificate chain, based on the configured trust stores (CAfile and/or CApath). If you call this function, then you can control how your certificates chain is augmented. But if your EE certificate is the entire chain, then the internal automatic chain construction code will assume that the chain was not built, and will try to augment it unless you set the SSL_MODE_NO_AUTO_CHAIN flag via: SSL_CTX_set_mode(3), or SSL_set_mode(3) [ Which really ought to also document SSL_MODE_NO_AUTO_CHAIN ] > Will the root cert be included in the chain any time it's in the same directory > as the server cert? No, the chain is augmented based on the configured trust stores, and does not directly consider the directory holding the chain file. > Is there a way, via API call, configuration, etc, to force OpenSSL to NOT send the > root certificate as part of the chain in this case? You can set a CAfile/CApath that do not include the location of the root cert, or disable automatic chain construction, and build the chain just the way you like it via SSL_CTX_build_cert_chain(3), possibly passing the SSL_BUILD_CHAIN_FLAG_NO_ROOT flag. -- Viktor. From dengwenbin_0301 at 126.com Fri May 24 02:45:28 2019 From: dengwenbin_0301 at 126.com (dengwenbin_0301) Date: Fri, 24 May 2019 02:45:28 -0000 Subject: Fw:Re:Re: Building openssl outside of the source tree" doesn't work well Message-ID: <57ab2aa5.289c.16ae7ba5c96.Coremail.dengwenbin_0301@126.com> I tried on openssl-1.1.1a and openssl-1.1.1b and they all have the same issue. I think it has something to do with my env. But i am not able to figure out what is the cause. Thanks, Wenbin -------- Forwarding messages -------- From: "dengwenbin_0301" Date: 2019-05-22 09:40:19 To: "Richard Levitte" Subject: Re:Re: Building openssl outside of the source tree" doesn't work well Thanks for your reply, Richard. Yes, the "-Iinclude -Iapps/include" is missing. I don't know why this happened. I attached the the configdata.pm and its dump. Please help have a check. wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ git log -n 1 commit d3136af3c3905a730bd8fb44158aab36a2549d9b Author: Richard Levitte Date: Sat May 18 16:24:21 2019 -0700 Configure: let platform->dsoext() default with platform->shlibextsimple() We still use '.so' as a last resort... Fixes #8950 Reviewed-by: Tim Hudson (Merged from https://github.com/openssl/openssl/pull/8951) At 2019-05-21 11:47:14, "Richard Levitte" wrote: >On Tue, 21 May 2019 03:26:41 +0200, >dengwenbin_0301 wrote: >> >> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl [master]$ cd obj/ >> >> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ ../config >> Operating system: x86_64-whatever-linux2 >> Configuring OpenSSL version 3.0.0-dev for target linux-x86_64 >> Using os-specific seed configuration >> Creating configdata.pm >> Creating Makefile >> >> ********************************************************************** >> *** *** >> *** OpenSSL has been successfully configured *** >> *** *** >> *** If you encounter a problem while building, please open an *** >> *** issue on GitHub ; *** >> *** and include the output from the following command: *** >> *** *** >> *** perl configdata.pm --dump *** >> *** *** >> *** (If you are new to OpenSSL, you might want to consult the *** >> *** 'Troubleshooting' section in the INSTALL file first) *** >> *** *** >> ********************************************************************** >> wdeng:~/wenbindfiles/openssl/openssl/obj [master]$ make >> make depend && make _all >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' >> gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN >> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 >> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM >> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM >> -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr >> /local/lib/ossl-modules\"" -DNDEBUG -MMD -MF apps/libapps-lib-app_rand.d.tmp -MT apps/ >> libapps-lib-app_rand.o -c -o apps/libapps-lib-app_rand.o ../apps/app_rand.c >> ../apps/app_rand.c:10:18: fatal error: apps.h: No such file or directory >> compilation terminated. >> Makefile:826: recipe for target 'apps/libapps-lib-app_rand.o' failed >> make[1]: *** [apps/libapps-lib-app_rand.o] Error 1 >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj' >> Makefile:165: recipe for target 'all' failed >> make: *** [all] Error 2 > >I tried exactly that just now, exactly same 'obj' ubdirectory, and it >works with no problem. > >Something I'm noticing from your command line is that all -I options >that I expect to see there are gone. This is what I expect (note that >I go directly at the object file for demonstration purposes): > > : ; make apps/libapps-lib-app_rand.o > gcc -I. -Iinclude -Iapps/include -I.. -I../include > -I../apps/include -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 > -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC > -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM > -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" > -DENGINESDIR="\"/usr/local/lib/engines-3\"" > -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG -MMD -MF > apps/libapps-lib-app_rand.d.tmp -MT apps/libapps-lib-app_rand.o -c > -o apps/libapps-lib-app_rand.o ../apps/app_rand.c > >So the question is what happened to '-I. -Iinclude -Iapps/include >-I.. -I../include -I../apps/include' in your build. > >I cannot say right now, but it might help if you show the output from >'./configdata.pm --dump' > >Cheers, >Richard > >-- >Richard Levitte levitte at openssl.org >OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: configdata.pm Type: application/octet-stream Size: 746093 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: configdata.pm.dump Type: application/octet-stream Size: 7391 bytes Desc: not available URL: