From matt at openssl.org Thu Sep 1 08:34:10 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Sep 2016 09:34:10 +0100 Subject: [openssl-users] Working with s_time and nginx In-Reply-To: <1b16da10-7061-89be-ff66-e16369a8f871@skifremme.no> References: <1b16da10-7061-89be-ff66-e16369a8f871@skifremme.no> Message-ID: <66639a34-0225-8ede-5139-0e88ca29d081@openssl.org> On 31/08/16 17:42, Kjetil Birkeland Moe wrote: > Dear all, > I have turned to /s_time/ to evaluate the performance of a local Nginx > server setup, but seems to immediately run into problems that do not > appear when using /s_client/. > > Server setup is largely based on recommendations from bettercrypto.org, > which also demonstrate the same problems with their setup as I currently > do: "openssl s_time -connect bettercrypto.org:443 -cipher > AES128-GCM-SHA256 -time 2" returns > > * "140373676381952:error:14094410:SSL routines:ssl3_read_bytes:sslv3 > alert handshake failure:ssl/record/rec_layer_s3.c:1362:SSL alert > number 40" in OpenSSL 1.1.0 > * "140416684930936:error:14077410:SSL > routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake > failure:s23_clnt.c:769:" in version 1.0.2h. You say you don't get this problem with s_client. I just tried: openssl s_client -connect bettercrypto.org:443 -cipher AES128-GCM-SHA256 And got exactly the same error message as above. I also tried all the ciphersuites below that you list as problematic, and got the same error with s_client. So, what exactly is your command line that works with s_client? Matt From nikola.n.milev at gmail.com Thu Sep 1 11:36:02 2016 From: nikola.n.milev at gmail.com (Nikola Milev) Date: Thu, 1 Sep 2016 13:36:02 +0200 Subject: [openssl-users] OpenSSL Dragino Yun Issues In-Reply-To: References: Message-ID: Dear OpenSSL community, I have, because of Matt's suggestion of the origin of error, written a small C server that uses the same configuration and it works. Can someone tell me what's going on? The code is next (fully copied from my editor): "#include #include #include #include #include #include #include #define PROTOCOL IPPROTO_TCP #define SERV_PORT 8080 #define LISTENQ 1 #define MAXLINE 100 void exit_msg(const char* msg) ; void str_echo(int sockfd) ; ssize_t writen(int fd, const void *vptr, size_t n) ; int main(int argc, char **argv) { int listenfd, connfd; pid_t childpid; socklen_t clilen; struct sockaddr_in cliaddr, servaddr; listenfd = socket (AF_INET, SOCK_STREAM, PROTOCOL); if(listenfd < 0) { exit_msg("socket() error"); } printf("Created socket!\n"); memset(&servaddr, 0, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr = htonl (INADDR_ANY); servaddr.sin_port = htons (SERV_PORT); if(bind(listenfd, (const struct sockaddr *) &servaddr, sizeof(servaddr)) < 0) { exit_msg("bind() error"); } printf("Binded port/socket!\n"); if(listen(listenfd, LISTENQ) < 0) { exit_msg("listen() error"); } printf("Listening!\n"); while(1) { clilen = sizeof(cliaddr); connfd = accept(listenfd, (struct sockaddr *) &cliaddr, &clilen); if(connfd < 0) { exit_msg("accept() error"); } printf("Accepted!\n"); str_echo(connfd); close(connfd); } } void str_echo(int sockfd) { ssize_t n; char buf[MAXLINE]; while(1) { while ( (n = read(sockfd, buf, MAXLINE)) > 0) { writen(sockfd, buf, n); buf[n]=0; printf("Echoing %lu bytes: %s\n", n, buf); } if (n < 0 && errno == EINTR) { continue; } else if (n < 0) { exit_msg("read() failure"); } else if(n==0) { printf("Client ended!\nListening!\n"); break; } } } ssize_t writen(int fd, const void *vptr, size_t n) { size_t nleft; ssize_t nwritten; const char *ptr; ptr = vptr; nleft = n; while (nleft > 0) { if ( (nwritten = write(fd, ptr, nleft)) <= 0) { if (nwritten < 0 && errno == EINTR) { nwritten = 0; } else { return -1; } } nleft -= nwritten; ptr += nwritten; } return n; } void exit_msg(const char* msg) { perror(msg); exit(EXIT_FAILURE); }" Best regards, Nikola Milev On 1 September 2016 at 00:16, Nikola Milev wrote: > To whom it may concern, > > I have been experiencing issues with OpenSSL and DraginoYun. If you are > not the person I should have contacted, please redirect me. Thank you! > > Recently, I have tried using OpenSSL to establish a simple server > application on Dragino Yun version 2.4. First, I tested the code on my Acer > Aspire 5750ZG running Ubuntu 14.04 and it worked fine. Afterwards, I used > OpenWrt SDK to cross-compile the application. However, the application is > unable to bind the socket; the BIO_do_accept function fails. Here is the > error stack the code provided: > "2006783048:error:0200407C:lib(2):func(4):reason(124):NA:0:port='5354' > 2006783048:error:20069076:lib(32):func(105):reason(118):NA:0:" > > errstr returned these as answers: > "$ openssl errstr 0200407C > error:0200407C:system library:socket:Wrong medium type > $ openssl errstr 20069076 > error:20069076:BIO routines:BIO_get_accept_socket:unable to create socket > " > I suppose that the second one is a product of the first one. > > I have checked iptables and I have checked ports that are currently in > use, all seems to be in order. > > However, the OpenSSL s_server (in combination with s_client on the other > side) works fine. > May this be an OpenSSL bug? If not, do you have any suggestions? > > OpenSSL version on Acer is 1.0.1f 6 Jan 2014 and on Dragino 1.0.1h 5 Jun > 2014. > > In the attachment, I am providing the code(though I am not sure if it is > available on the list), mostly taken from O'Reilly "Network Security with > OpenSSL". > > All the passkeys are "raspberry". (these certificates and keys were > generated for testing purposes) > > Of course, should you need any additional information, I'd be happy to > provide it. > > I originally addressed Matt Caswell regarding the issue and I am pasting > his response to my question and my response to that. > > His response: > "Hello, > > I'm not really the best person to ask about such low level stuff. The > best place to raise these questions is on the openssl-users email list. > It also means any questions/answers are publicly archived and available > for other users. Details are here: > > https://mta.openssl.org > > However, I did have a quick look and discovered the following. The code > that raises this error looks like this: > > s = socket(server.sa.sa_family, SOCK_STREAM, SOCKET_PROTOCOL); > if (s == INVALID_SOCKET) { > SYSerr(SYS_F_SOCKET, get_last_socket_error()); > ERR_add_error_data(3, "port='", host, "'"); > BIOerr(BIO_F_BIO_GET_ACCEPT_SOCKET, BIO_R_UNABLE_TO_CREATE_SOCKET) > ; > goto err; > } > > So this is a call to the non-OpenSSL networking function "socket". In > this context "server.sa.sa_family" has been set to AF_INET a few lines > above, and "SOCKET_PROTOCOL" is a macro defined at the beginning of the > file as follows: > > # define SOCKET_PROTOCOL IPPROTO_TCP > > In other words the function that is failing is doing this: > > socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) > > This seems like a fairly fundamental failure, and might suggest that the > platform in question has no TCP/IP support available for some reason?" > > My response to his: > " > Hi Matt, > > The platform supports TCP/IP, if I deduced correctly. I have programmed an > application similar to the example in Unix Network Programming (a basic > TCP/IP echo server) and it works without any issues. Also, openssl s_server > works correctly; I tried using it with openssl s_client on the other > machine. > I will forward my question to the email list, including both of our > responses. > I am grateful for your quick response. > > Best regards, > Nikola Milev > > " > > My original mail to him is almost the same as the first part of this mail. > > I am thankful for you support! > > Best regards, > Nikola Milev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mowiener at cisco.com Thu Sep 1 10:18:33 2016 From: mowiener at cisco.com (mowiener) Date: Thu, 1 Sep 2016 03:18:33 -0700 (MST) Subject: [openssl-users] RSA sign using SHA256 with mgf1 padding In-Reply-To: <1b704769-d803-aee3-913e-d680ea24c90e@idrix.net> References: <2cd90924c05c43a79794168b0af03c3e@XCH-RCD-012.cisco.com> <1b704769-d803-aee3-913e-d680ea24c90e@idrix.net> Message-ID: <1472725113858-68152.post@n7.nabble.com> Many thanks Mounir, this is what I swa looking for. -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-sign-using-SHA256-with-mgf1-padding-tp68101p68152.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From jb-openssl at wisemo.com Thu Sep 1 12:22:20 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 1 Sep 2016 14:22:20 +0200 Subject: [openssl-users] ECC patent status questions Message-ID: <91ad4d7d-d56a-4e6b-06d0-5381f0729c36@wisemo.com> Dear OpenSSL team, Given the recent patent lawsuit between RIM/CertiCom and Avaya mentioning the ECC code in OpenSSL, what is (according to the OpenSSL team) the patent status of the ECC code in OpenSSL? Specifically: - Was the OpenSSL ECC code provided under a still-valid patent license from someone in the power to grant it, perhaps Sun (now Oracle America)? - Is the FIPS mode ECC covered through some US Government or sponsor license?, And if so, does this license extend to some non-FIPS scenarios, such as invoking the FIPS blob ECC code from a non-FIPS application (perhaps by modifying a FIPS-capable OpenSSL library to do so even in non-FIPS mode)? - Are there portions of the ECC code in OpenSSL which one should disable at configure time, similar to how RSA and IDEA were often disabled in the past? - Is this situation different depending on the OpenSSL library version? 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 uri at ll.mit.edu Thu Sep 1 16:03:24 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 1 Sep 2016 16:03:24 +0000 Subject: [openssl-users] RSA sign using SHA256 with mgf1 padding In-Reply-To: <1472725113858-68152.post@n7.nabble.com> References: <2cd90924c05c43a79794168b0af03c3e@XCH-RCD-012.cisco.com> <1b704769-d803-aee3-913e-d680ea24c90e@idrix.net> <1472725113858-68152.post@n7.nabble.com> Message-ID: <4D38D511-0CF4-40DF-989E-0278CB96A1EE@ll.mit.edu> And if you want to run it on OpenSSL-1.1, see the attached. ? --? Regards, Uri Blumenthal On 9/1/16, 6:18 , "openssl-users on behalf of mowiener" wrote: Many thanks Mounir, this is what I was looking for. \ -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_pss_signature.c Type: application/octet-stream Size: 3508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5227 bytes Desc: not available URL: From artlemuel at gmail.com Thu Sep 1 16:43:49 2016 From: artlemuel at gmail.com (Art Lemuel) Date: Thu, 1 Sep 2016 12:43:49 -0400 Subject: [openssl-users] Compiling Openssl 1.1.0 on AIX using gcc Message-ID: When compiling with FIPS, the compile terminated with a fatal error looking for #include in the crypto/err/err_all.c code. The fips.h header file lives in ../ssl/fips-2.0/include.openssl/fips.h. Am I missing something here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Sep 1 17:53:53 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Sep 2016 17:53:53 +0000 Subject: [openssl-users] Compiling Openssl 1.1.0 on AIX using gcc In-Reply-To: References: Message-ID: <90ebadf71529461e8043a86e112dc6be@usma1ex-dag1mb1.msg.corp.akamai.com> > Am I missing something here? OpenSSL 1.1.0 does not support FIPS. It's in the README.FIPS file :) From stevem at openssl.org Thu Sep 1 18:11:34 2016 From: stevem at openssl.org (Steve Marquess) Date: Thu, 1 Sep 2016 14:11:34 -0400 Subject: [openssl-users] ECC patent status questions In-Reply-To: <91ad4d7d-d56a-4e6b-06d0-5381f0729c36@wisemo.com> References: <91ad4d7d-d56a-4e6b-06d0-5381f0729c36@wisemo.com> Message-ID: <292c2652-6a0a-c1ba-6fed-9b0157b040ba@openssl.org> On 09/01/2016 08:22 AM, Jakob Bohm wrote: > Dear OpenSSL team, > > Given the recent patent lawsuit between RIM/CertiCom and Avaya > mentioning the ECC code in OpenSSL, what is (according to the > OpenSSL team) the patent status of the ECC code in OpenSSL? > > Specifically: > > - Was the OpenSSL ECC code provided under a still-valid patent > license from someone in the power to grant it, perhaps Sun > (now Oracle America)? > > - Is the FIPS mode ECC covered through some US Government or > sponsor license?, And if so, does this license extend to > some non-FIPS scenarios, such as invoking the FIPS blob ECC > code from a non-FIPS application (perhaps by modifying a > FIPS-capable OpenSSL library to do so even in non-FIPS > mode)? > > - Are there portions of the ECC code in OpenSSL which one > should disable at configure time, similar to how RSA and > IDEA were often disabled in the past? > > - Is this situation different depending on the OpenSSL > library version? Jacob, for any patent or licensing issues you really need to consult competent legal counsel. Under the U.S. legal system anyone with deep pockets can bring suit against anyone for frivolous reasons. You'll want to consult with your counsel to determine the level of risk for your particular circumstances. If a patent troll targets you for a shakedown the legal virtues of your defense are far less relevant than the size of your pocketbook. I do know that some OpenSSL end users have chosen to omit certain algorithm implementations for perceived legal reasons. The OpenSSL FIPS Object Module is provided in both full and ECC-free versions; the latter at the request of a validation sponsor. As far as I know that ECC-free version (openssl-fips-ecp-2.0.N.tar.gz) has seen very little use though, even by that original sponsor. All that said, we believe all code in OpenSSL to be properly licensed under the legal systems of most countries. We are also members of the Open Invention Network. We have a NSA ECC sublicense (https://www.openssl.org/source/NSA-PLA.pdf). I'm not going to try and offer any legal advice, though; for that you'll need to check with your own legal counsel. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marquess at opensslfoundation.org stevem at openssl.org From jb-openssl at wisemo.com Thu Sep 1 22:24:46 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 2 Sep 2016 00:24:46 +0200 Subject: [openssl-users] ECC patent status questions In-Reply-To: <292c2652-6a0a-c1ba-6fed-9b0157b040ba@openssl.org> References: <91ad4d7d-d56a-4e6b-06d0-5381f0729c36@wisemo.com> <292c2652-6a0a-c1ba-6fed-9b0157b040ba@openssl.org> Message-ID: <3272246d-bc47-ebaa-62b1-05a474c24eec@wisemo.com> On 01/09/2016 20:11, Steve Marquess wrote: > On 09/01/2016 08:22 AM, Jakob Bohm wrote: >> Dear OpenSSL team, >> >> Given the recent patent lawsuit between RIM/CertiCom and Avaya >> mentioning the ECC code in OpenSSL, what is (according to the >> OpenSSL team) the patent status of the ECC code in OpenSSL? >> >> Specifically: >> >> - Was the OpenSSL ECC code provided under a still-valid patent >> license from someone in the power to grant it, perhaps Sun >> (now Oracle America)? >> >> - Is the FIPS mode ECC covered through some US Government or >> sponsor license?, And if so, does this license extend to >> some non-FIPS scenarios, such as invoking the FIPS blob ECC >> code from a non-FIPS application (perhaps by modifying a >> FIPS-capable OpenSSL library to do so even in non-FIPS >> mode)? >> >> - Are there portions of the ECC code in OpenSSL which one >> should disable at configure time, similar to how RSA and >> IDEA were often disabled in the past? >> >> - Is this situation different depending on the OpenSSL >> library version? > Jacob, for any patent or licensing issues you really need to consult > competent legal counsel. Under the U.S. legal system anyone with deep > pockets can bring suit against anyone for frivolous reasons. You'll > want to consult with your counsel to determine the level of risk for > your particular circumstances. If a patent troll targets you for a > shakedown the legal virtues of your defense are far less relevant than > the size of your pocketbook. What on earth made you think I was asking about "legal advice"? My questions were being very specific precisely to avoid that, and to be of general interest rather than anything specific to what I do myself. > I do know that some OpenSSL end users have chosen to omit certain > algorithm implementations for perceived legal reasons. The OpenSSL FIPS > Object Module is provided in both full and ECC-free versions; the latter > at the request of a validation sponsor. As far as I know that ECC-free > version (openssl-fips-ecp-2.0.N.tar.gz) has seen very little use though, > even by that original sponsor. Indeed, my main point is that there seem to have been a somewhat sudden shift in policy from the company (Certicom/RIM) that generally holds most ECC patents, and that this shift in policy might change the /practical/ advice as to which portions of OpenSSL should be used in typical deployments. > All that said, we believe all code in OpenSSL to be properly licensed > under the legal systems of most countries. We are also members of the > Open Invention Network. We have a NSA ECC sublicense > (https://www.openssl.org/source/NSA-PLA.pdf). I'm not going to try and > offer any legal advice, though; for that you'll need to check with your > own legal counsel. As far as I understand, the OIN helps only if the OpenSSL Foundation itself became a defendant needing to counter sue etc. (I presume the OIN is one of those nice patent pools that generally promise not to sue non-aggressors, making their patents a non-issue for non-member non-aggressors). The existence of the NSA agreement is a partial answer to the first question, though it seems unclear if this license is recursively sublicensed through 3rd parties or not. Again not asking for legal advice, merely the general extent of the (sub-)license provided by the OpenSSL Foundation to the rest of the community (not just me, but almost everyone). 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 rsalz at akamai.com Thu Sep 1 22:43:44 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Sep 2016 22:43:44 +0000 Subject: [openssl-users] ECC patent status questions In-Reply-To: <3272246d-bc47-ebaa-62b1-05a474c24eec@wisemo.com> References: <91ad4d7d-d56a-4e6b-06d0-5381f0729c36@wisemo.com> <292c2652-6a0a-c1ba-6fed-9b0157b040ba@openssl.org> <3272246d-bc47-ebaa-62b1-05a474c24eec@wisemo.com> Message-ID: <8073ab54ae644b33addf9246f02686b2@usma1ex-dag1mb1.msg.corp.akamai.com> It's hard to answer these questions without wandering down the "legal advice" alleyway. I think Steve's post answered your questions. > >> - Was the OpenSSL ECC code provided under a still-valid patent > >> license from someone in the power to grant it, perhaps Sun > >> (now Oracle America)? This is our belief. > >> - Is the FIPS mode ECC covered through some US Government or > >> sponsor license?, And if so, does this license extend to > >> some non-FIPS scenarios, such as invoking the FIPS blob ECC > >> code from a non-FIPS application (perhaps by modifying a > >> FIPS-capable OpenSSL library to do so even in non-FIPS > >> mode)? The license is for the OpenSSL toolkit, and you can now read it easily online. > >> - Are there portions of the ECC code in OpenSSL which one > >> should disable at configure time, similar to how RSA and > >> IDEA were often disabled in the past? No idea. > >> - Is this situation different depending on the OpenSSL > >> library version? Not that we know. > My questions were being very specific precisely to avoid that, and to be of > general interest rather than anything specific to what I do myself. I know you were asking on behalf of the community. Thanks. > The existence of the NSA agreement is a partial answer to the first question, > though it seems unclear if this license is recursively sublicensed through 3rd > parties or not. They knew they were licensing an open source toolkit. Hope this helps. From aerowolf at gmail.com Fri Sep 2 01:27:52 2016 From: aerowolf at gmail.com (Kyle Hamilton) Date: Thu, 1 Sep 2016 18:27:52 -0700 Subject: [openssl-users] ECC patent status questions In-Reply-To: <8073ab54ae644b33addf9246f02686b2@usma1ex-dag1mb1.msg.corp.akamai.com> References: <91ad4d7d-d56a-4e6b-06d0-5381f0729c36@wisemo.com> <292c2652-6a0a-c1ba-6fed-9b0157b040ba@openssl.org> <3272246d-bc47-ebaa-62b1-05a474c24eec@wisemo.com> <8073ab54ae644b33addf9246f02686b2@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On Thu, Sep 1, 2016 at 3:43 PM, Salz, Rich wrote: > > The existence of the NSA agreement is a partial answer to the first > question, > > though it seems unclear if this license is recursively sublicensed > through 3rd > > parties or not. > > They knew they were licensing an open source toolkit. > So, it looks as though the only way for any one of us to be able to have a patent license under the NSA's license to OpenSSL Software Foundation is to get a separate license from you that doesn't allow us to redistribute or resell it. (I'm not a lawyer, but it appears to be the only way that we would be able to qualify under the "End User" definition 1A, as referenced in the grant under section 2.) Is such a license available? Could such a license be granted severally to the same people who also receive the standard BSD license, such that each individual actually receives two separate licenses for the same code (i.e., one granted with extremely limited rights solely for the purpose of qualifying to receive the NSA ECC patent license, the other being separately granted to permit redistribution and resale of integrated components but not granting any ECC license transitively)? If such a severed license were possible, I would think that such would require that the recipient of the first (limited) license obtain the code directly from openssl.org. -Kyle H -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Sep 2 02:13:55 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 2 Sep 2016 04:13:55 +0200 Subject: [openssl-users] ECC patent status questions In-Reply-To: References: <91ad4d7d-d56a-4e6b-06d0-5381f0729c36@wisemo.com> <292c2652-6a0a-c1ba-6fed-9b0157b040ba@openssl.org> <3272246d-bc47-ebaa-62b1-05a474c24eec@wisemo.com> <8073ab54ae644b33addf9246f02686b2@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <082a9604-18a8-3d16-c8be-555a0cc0c0fb@wisemo.com> On 02/09/2016 03:27, Kyle Hamilton wrote: > > On Thu, Sep 1, 2016 at 3:43 PM, Salz, Rich >wrote: > > > The existence of the NSA agreement is a partial answer to the first > question, > > though it seems unclear if this license is recursively > sublicensed through 3rd > > parties or not. > > They knew they were licensing an open source toolkit. > > > So, it looks as though the only way for any one of us to be able to > have a patent license under the NSA's license to OpenSSL Software > Foundation is to get a separate license from you that doesn't allow us > to redistribute or resell it. (I'm not a lawyer, but it appears to be > the only way that we would be able to qualify under the "End User" > definition 1A, as referenced in the grant under section 2.) Or maybe there is some quirk of US copyright law which causes the "have made" clause to formally include all copying of OpenSSL done under license from the Foundation, as those are done under the Foundation's exclusive right (as copyright holder) to "have copies made". I honestly don't know. > > Is such a license available? Could such a license be granted > severally to the same people who also receive the standard BSD > license, such that each individual actually receives two separate > licenses for the same code (i.e., one granted with extremely limited > rights solely for the purpose of qualifying to receive the NSA ECC > patent license, the other being separately granted to permit > redistribution and resale of integrated components but not granting > any ECC license transitively)? > > If such a severed license were possible, I would think that such would > require that the recipient of the first (limited) license obtain the > code directly from openssl.org . > Kind of why I asked. And that would be impractical where OpenSSL is already linked into something (such as the firmware of a Telephone). 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 Fri Sep 2 07:51:28 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Sep 2016 08:51:28 +0100 Subject: [openssl-users] OpenSSL Dragino Yun Issues In-Reply-To: References: Message-ID: <84980471-2ba7-72f0-2072-8859cff49258@openssl.org> On 01/09/16 12:36, Nikola Milev wrote: > listenfd = socket (AF_INET, SOCK_STREAM, PROTOCOL); > if(listenfd < 0) > { > exit_msg("socket() error"); > } The fact that this worked suggests that maybe we aren't sending what we think we are sending as the parameters to the equivalent socket call in OpenSSL. Either that or something really weird is happening that causes it to fail when called from OpenSSL, but not from a standalone program!! Did you compile OpenSSL yourself, or are you using pre-built binaries? If you compiled it yourself then I could provide you with a small patch to instrument the code to figure out what parameters are being sent to "socket"...either that or you could take a look at it in a debugger if it has been compiled with debugging symbols. Matt From matt at openssl.org Fri Sep 2 08:32:19 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Sep 2016 09:32:19 +0100 Subject: [openssl-users] OpenSSL Dragino Yun Issues In-Reply-To: References: <84980471-2ba7-72f0-2072-8859cff49258@openssl.org> Message-ID: <1702bdd3-96ab-7367-0a10-db4c825e1ae4@openssl.org> On 02/09/16 09:15, Nikola Milev wrote: > Matt, > > I have not compiled it myself. Compiling simpler applications for my > Dragino Yun shield is complicated enough. > > One thing that did come to mind was: could the cross compilation for > Dragino be messing with the program in any way? Also quite new in all of it. Possibly, but I'm not familiar with Dragino so I can't really comment. > > Back to OpenSSL, are there any additional settings that could have > caused the error? None that spring to mind. > > Also, I have a question about this issue on Stack Overflow. If we > resolve the issue, I think it would be good to post it there as an > answer, if you agree. Sure. If you are unable to compile OpenSSL and it doesn't have debugging symbols then its going to be difficult to take the diagnosis of this problem much further. An alternative solution for you might be a "workaround". Rather than calling BIO_do_accept(), you could create the socket yourself directly (i.e. not using the BIO calls). Once you have the have the socket file descriptor you can create a BIO from it using BIO_new_socket(). Matt > Best regards, > Nikola > > > On Sep 2, 2016 9:51 AM, "Matt Caswell" > wrote: > > > > On 01/09/16 12:36, Nikola Milev wrote: > > listenfd = socket (AF_INET, SOCK_STREAM, PROTOCOL); > > if(listenfd < 0) > > { > > exit_msg("socket() error"); > > } > > The fact that this worked suggests that maybe we aren't sending what we > think we are sending as the parameters to the equivalent socket call in > OpenSSL. Either that or something really weird is happening that causes > it to fail when called from OpenSSL, but not from a standalone program!! > > Did you compile OpenSSL yourself, or are you using pre-built binaries? > If you compiled it yourself then I could provide you with a small patch > to instrument the code to figure out what parameters are being sent to > "socket"...either that or you could take a look at it in a debugger if > it has been compiled with debugging symbols. > > Matt > From steve at openssl.org Fri Sep 2 15:32:15 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 2 Sep 2016 15:32:15 +0000 Subject: [openssl-users] RSA sign using SHA256 with mgf1 padding In-Reply-To: <2cd90924c05c43a79794168b0af03c3e@XCH-RCD-012.cisco.com> References: <2cd90924c05c43a79794168b0af03c3e@XCH-RCD-012.cisco.com> Message-ID: <20160902153214.GA1963@openssl.org> On Mon, Aug 29, 2016, Moshe Wiener (mowiener) wrote: > Hello, > I'm running an application which runs an authentication session with a server. The server provides some random data, and my application needs to sign it with its private key, and send back the signature. The server which knows the public key verifies the signature, and it good then the client which runs my application is authenticated. > This session used to run OK, until the server was changed so instead of using PKCS#1_v1.5 now it uses PKCS#1_v2.1 > Now, the server uses signature algorithm of SHA256 WITH RSA AN DMGF1. > In my application I use OpenSSL. > I think that I need to use 'RSA_padding_add_PKCS1_OAEP_mgf1' but couldn't figure out what to put in each of its arguments. > Is there somewhere a sample code which implements RSA signature with mgf1 padding and a SHA256 hash? While you can call the low level RSA padding functions directly that is not recommended. You should instead use the EVP functions to sign the data with the padding mode switched to PSS. In outline: Call EVP_DigestSignInit(), set digest, and key and get the EVP_PKEY_CTX associated with the operation. Use the EVP_PKEY_CTX to change the padding mode to PSS. You do this with: EVP_CTX_set_rsa_padding(ctx, RSA_PKCS1_PSS_PADDING). (optional)use the EVP_PKEY_CTX to change other parameters such as the salt length. Call EVP_DigestSignUpdate() with the data to be hashed. Obtain the signature with EVP_DigestSignFinal(). If that isn't clear I can come up with some sample code. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Fri Sep 2 15:39:16 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 2 Sep 2016 15:39:16 +0000 Subject: [openssl-users] Obtaining PKCS7 data length In-Reply-To: <420e88c6-a91d-3ef7-4a14-f118d409703a@edeca.net> References: <420e88c6-a91d-3ef7-4a14-f118d409703a@edeca.net> Message-ID: <20160902153916.GB1963@openssl.org> On Tue, Aug 30, 2016, David wrote: > Hi, > > I have some PKCS7 data which I can read like this with OpenSSL: > > $ openssl asn1parse -i -inform der -in data.dat > 0:d=0 hl=4 l=16208 cons: SEQUENCE > 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData > .. more .. > > I can load it in code like so: > > // buf contains the raw data, len the length > BIO *bio = BIO_new_mem_buf(buf, len); > > PKCS7 *pkcs7 = d2i_PKCS7_bio(bio, NULL); > if (!pkcs7) { > // die > } > printf("Success!"); > > This works fine and I can successfully obtain signer information etc. > However I'd like to obtain the length value as parsed from the input > data. In my example this was 16208, seen in the second line of the ASN1 > output. > > I noticed there is a length attribute to the PKCS7 structure (see > include/openssl/pkcs7.h) but pkcs7->length is always zero when I print it. > > How can I obtain the length of the overall sequence which contains PKCS7 > signed data? This is important because the length I already have may be > longer than the actual PKCS7 data. > I'm curious: why do you want that information? If you want the entire length of the parsed data you can use d2i_PKCS7() to parse the buffer: the passed pointer is then incremented to immediately follow the PKCS7 structure. You can then get the length by subtracting the start of the buffer. If you want the length of the intial SEQUENCE then this data is handled automatically by the parser and isn't directly available. You can use an ASN.1 function such as ASN1_get_object() to obtain it. However this wont always be what you want: if the PKCS#7 structure used indefinite length constructed encoding then you wont get anything useful. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From leamhall at gmail.com Fri Sep 2 15:50:09 2016 From: leamhall at gmail.com (Leam Hall) Date: Fri, 2 Sep 2016 11:50:09 -0400 Subject: [openssl-users] More secure use of DSA? Message-ID: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> Thanks to Matt Caswell for helping me fix the DSA question. His solution, based of the information I provided, was: openssl genpkey -genparam -algorithm DSA -pkeyopt \ dsa_paramgen_bits:2048 -out dsa.params openssl genpkey -paramfile dsa.params -out dsa.key Which leads to my next question. For general application and ssh level defense, is 2048 the right bit amount? Is there a reason not to go to 4096 absent very high request counts? Are there other security flags I should use? I'm currently reading Ivan's "OpenSSL cookbook but some of it is slow to sink in. Thanks! Leam From nikola.n.milev at gmail.com Fri Sep 2 15:50:54 2016 From: nikola.n.milev at gmail.com (Nikola Milev) Date: Fri, 2 Sep 2016 17:50:54 +0200 Subject: [openssl-users] OpenSSL Dragino Yun Issues In-Reply-To: <014bc52b-b75b-997a-904a-8617941c2e23@openssl.org> References: <84980471-2ba7-72f0-2072-8859cff49258@openssl.org> <1702bdd3-96ab-7367-0a10-db4c825e1ae4@openssl.org> <014bc52b-b75b-997a-904a-8617941c2e23@openssl.org> Message-ID: Matt, The suggested workaround seems to be working. I say "seems to be" because I have only tested it a little. it was tested using openssl s_client. Also, I suppose this doesn't present a security breach? Of course, if anyone manages to locate the origin of the issue, I would like to hear from them. Resent the mail so that everyone else can see it. Best regards, Nikola Milev On Sep 2, 2016 11:31 AM, "Matt Caswell" wrote: > > > On 02/09/16 10:16, Nikola Milev wrote: > > Matt, > > > > I am not sure I understand. > > > > acc = BIO_new_accept(PORT); > > > > > > BIO_set_bind_mode(acc, BIO_BIND_REUSEADDR_IF_UNUSED); > > if(!acc) > > { > > server_error_("Error creating server socket"); > > } > > if (BIO_do_accept(acc) <= 0) > > { > > server_error_("Error binding server socket"); > > } > > > > Looking at this chunk of code, I am a bit confused. Is not the socket > > created with BIO in BIO_new_accept() call? > > > > Am I supposed to create acc BIO using the socket(), then > > BIO_new_socket(), then BIO_set_port() and, afterwards, omit the first > > BIO_do_accept() call? > > I'm suggesting you don't use BIO for that piece of your code. Just do > regular "socket", "bind", "listen" and "accept" calls like you had in > your simple server code. In that code you had a variable "connfd" which > represented the incoming connection file descriptor. You can then wrap > that "connfd" in a BIO: > > bio = BIO_new(BIO_s_socket()); > > if (bio == NULL) { > goto err; > } > BIO_set_fd(bio, connfd, BIO_NOCLOSE); > > Now you can just set that BIO on the SSL object: > > SSL_set_bio(ssl, bio, bio); > > > Matt > > > > > > > > On Sep 2, 2016 10:32 AM, "Matt Caswell" > > wrote: > > > > > > > > On 02/09/16 09:15, Nikola Milev wrote: > > > Matt, > > > > > > I have not compiled it myself. Compiling simpler applications for > my > > > Dragino Yun shield is complicated enough. > > > > > > One thing that did come to mind was: could the cross compilation > for > > > Dragino be messing with the program in any way? Also quite new in > > all of it. > > > > > > Possibly, but I'm not familiar with Dragino so I can't really > comment. > > > > > > > > Back to OpenSSL, are there any additional settings that could have > > > caused the error? > > > > None that spring to mind. > > > > > > > > Also, I have a question about this issue on Stack Overflow. If we > > > resolve the issue, I think it would be good to post it there as an > > > answer, if you agree. > > > > Sure. > > > > If you are unable to compile OpenSSL and it doesn't have debugging > > symbols then its going to be difficult to take the diagnosis of this > > problem much further. > > > > An alternative solution for you might be a "workaround". Rather than > > calling BIO_do_accept(), you could create the socket yourself > directly > > (i.e. not using the BIO calls). Once you have the have the socket > file > > descriptor you can create a BIO from it using BIO_new_socket(). > > > > Matt > > > > > > > Best regards, > > > Nikola > > > > > > > > > On Sep 2, 2016 9:51 AM, "Matt Caswell" > > > > >> wrote: > > > > > > > > > > > > On 01/09/16 12:36, Nikola Milev wrote: > > > > listenfd = socket (AF_INET, SOCK_STREAM, PROTOCOL); > > > > if(listenfd < 0) > > > > { > > > > exit_msg("socket() error"); > > > > } > > > > > > The fact that this worked suggests that maybe we aren't > > sending what we > > > think we are sending as the parameters to the equivalent > > socket call in > > > OpenSSL. Either that or something really weird is happening > > that causes > > > it to fail when called from OpenSSL, but not from a standalone > > program!! > > > > > > Did you compile OpenSSL yourself, or are you using pre-built > > binaries? > > > If you compiled it yourself then I could provide you with a > > small patch > > > to instrument the code to figure out what parameters are being > > sent to > > > "socket"...either that or you could take a look at it in a > > debugger if > > > it has been compiled with debugging symbols. > > > > > > Matt > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Sep 2 15:57:04 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Sep 2016 15:57:04 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> References: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> Message-ID: Unless you have to interoperate with other systems, *do not use DSA.* If you re-use a the random, the entire key can be be exposed. Crypto is hard enough. Use RSA or an ECC method. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From leamhall at gmail.com Fri Sep 2 16:00:34 2016 From: leamhall at gmail.com (Leam Hall) Date: Fri, 2 Sep 2016 12:00:34 -0400 Subject: [openssl-users] More secure use of DSA? In-Reply-To: References: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> Message-ID: <36d17ed2-2a55-de03-8f21-e97885198b1b@gmail.com> Rich, I thought DSA was more secure than RSA? Granted, "I thought" is a newbie understanding. Leam On 09/02/16 11:57, Salz, Rich wrote: > Unless you have to interoperate with other systems, *do not use DSA.* If you re-use a the random, the entire key can be be exposed. > Crypto is hard enough. Use RSA or an ECC method. > > -- > Senior Architect, Akamai Technologies > IM: richsalz at jabber.at Twitter: RichSalz > > From rsalz at akamai.com Fri Sep 2 16:09:25 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Sep 2016 16:09:25 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <36d17ed2-2a55-de03-8f21-e97885198b1b@gmail.com> References: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> <36d17ed2-2a55-de03-8f21-e97885198b1b@gmail.com> Message-ID: > I thought DSA was more secure than RSA? Granted, "I thought" is a newbie > understanding. This is completely wrong. From leamhall at gmail.com Fri Sep 2 17:29:31 2016 From: leamhall at gmail.com (Leam Hall) Date: Fri, 2 Sep 2016 13:29:31 -0400 Subject: [openssl-users] More secure use of DSA? In-Reply-To: References: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> <36d17ed2-2a55-de03-8f21-e97885198b1b@gmail.com> Message-ID: <2c9f9032-54ca-c4d3-2150-1a7b45a5759d@gmail.com> Do you have something I can read up on? On 09/02/16 12:09, Salz, Rich wrote: > >> I thought DSA was more secure than RSA? Granted, "I thought" is a newbie >> understanding. > > This is completely wrong. > From uri at ll.mit.edu Fri Sep 2 18:16:52 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 2 Sep 2016 18:16:52 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: References: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> <36d17ed2-2a55-de03-8f21-e97885198b1b@gmail.com> Message-ID: On 9/2/16, 12:09 , "openssl-users on behalf of Salz, Rich" wrote: I thought DSA was more secure than RSA? Granted, "I thought" is a newbie understanding. This is completely wrong. If you have a consistently good source of randomness (in my environment RDRAND counts as such), then DSA is fine, and in theory is stronger than RSA because it relies on a harder mathematical problem. If your source of randomness is questionable ? DSA won?t be secure (as Rich said). Then of course there are the implementation issues ? the randomness source may be available, but does the application use it correctly? (I hope that for OpenSSL the answer is ?yes?, but I did not check, as I?m using RSA for work-related things, and ECC for fun. J) Suite B and its follow-up do not include DSA. RSA and ECC only, with a warning to stand by for PQC stuff. In summary: do what everybody else does ? use RSA. J -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5227 bytes Desc: not available URL: From rsalz at akamai.com Fri Sep 2 18:19:45 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Sep 2016 18:19:45 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <2c9f9032-54ca-c4d3-2150-1a7b45a5759d@gmail.com> References: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> <36d17ed2-2a55-de03-8f21-e97885198b1b@gmail.com> <2c9f9032-54ca-c4d3-2150-1a7b45a5759d@gmail.com> Message-ID: <51a5cfe67fff4dd0b43302519e77c675@usma1ex-dag1mb1.msg.corp.akamai.com> > Do you have something I can read up on? Search "DSA weakness" for example. Where did you get the impression that DSA was better? From lists at edeca.net Fri Sep 2 22:40:47 2016 From: lists at edeca.net (David) Date: Fri, 2 Sep 2016 23:40:47 +0100 Subject: [openssl-users] Obtaining PKCS7 data length In-Reply-To: <20160902153916.GB1963@openssl.org> References: <420e88c6-a91d-3ef7-4a14-f118d409703a@edeca.net> <20160902153916.GB1963@openssl.org> Message-ID: <0d748762-d20b-8ff3-437d-82d9e4d1d577@edeca.net> On 02/09/2016 16:39, Dr. Stephen Henson wrote: > On Tue, Aug 30, 2016, David wrote: >> How can I obtain the length of the overall sequence which contains PKCS7 >> signed data? This is important because the length I already have may be >> longer than the actual PKCS7 data. >> > I'm curious: why do you want that information? I am loading PKCS7 data from Windows Portable Executable files which is used for code signing ("Authenticode"). The file structure itself gives a length for the relevant data that I pass to d2i_PKCS7(). However there may be trailing data which does not relate to the PKCS7 structure. My requirement for the length is to spot errors or abuse by comparing the length parsed by OpenSSL to the PE specific headers, e.g. to detect issues like MS13-098 [1]. > If you want the entire length of the parsed data you can use d2i_PKCS7() to > parse the buffer: the passed pointer is then incremented to immediately follow > the PKCS7 structure. You can then get the length by subtracting the > start of the buffer. Thank you - this works fine. David 1 - https://technet.microsoft.com/en-gb/library/security/2915720 From hanno at hboeck.de Sat Sep 3 06:06:44 2016 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Sat, 3 Sep 2016 08:06:44 +0200 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <2c9f9032-54ca-c4d3-2150-1a7b45a5759d@gmail.com> References: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> <36d17ed2-2a55-de03-8f21-e97885198b1b@gmail.com> <2c9f9032-54ca-c4d3-2150-1a7b45a5759d@gmail.com> Message-ID: <20160903080644.0fcf1e49@pc1> On Fri, 2 Sep 2016 13:29:31 -0400 Leam Hall wrote: > Do you have something I can read up on? A couple: https://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/ https://cr.yp.to/talks/2015.01.07/slides-djb-20150107-a4.pdf https://eprint.iacr.org/2015/262.pdf -- Hanno B?ck https://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From liaiqin.lanzhou at gmail.com Sat Sep 3 09:57:29 2016 From: liaiqin.lanzhou at gmail.com (=?UTF-8?B?5p2O54ix55C0?=) Date: Sat, 3 Sep 2016 19:57:29 +1000 Subject: [openssl-users] how to ask peer to sign a message Message-ID: This is a bit off topic but I find openssl users a good group to ask about it. In the case of an SSL connection where the client has a certificate, is it possible for the server to request the client to sign a message with the private key of that certificate? For example, for a webmail system, when user press "send" button, is it possible for the server to ask the client browser to sign the email with the same private key, whose certificate is used to log in to that very webmail? If it is possible, is it by a special form or javascript? Thanks! Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at daku.org Sat Sep 3 22:54:42 2016 From: david at daku.org (david) Date: Sat, 03 Sep 2016 15:54:42 -0700 Subject: [openssl-users] Openssl 1_1_0 compatibility question Message-ID: <201609032255.u83Mt99N013397@telford.daku.org> Folks In the home-grown application I have, data is encrypted on Windows clients and decrypted on Centos servers, all with OpenSSL, using a shared symmetric password. My clients have been running OpenSSL versions 1.0.* with each new version being installed on Windows (using https://slproweb.com/download/Win64OpenSSL...) with no compatibility issues, EXCEPT when I switched from 1.0.2h to 1.1.0. My servers are running whichever is supported by Centos systems -- currently 1.0.1e-fips. My methods do the following, with my real values replaced by fixed values in this example: On the client: Encrypt the value "abcde" with a password "123" with salt Windows command: echo abcde | openssl enc -salt -a -A -aes128 -pass pass:123 On the server: Decrypt the salted message with the password "123", and recover the value "1". Linux command: echo (the output of the above) | openssl enc -d -salt -a -A -aes128 -pass pass:123 When the ENCRYPTING software is 1_0_2h and the decrypting software is 1_0_1e on Linux or 1_0_2h on Windows, the decryption successfully recovers the value "abcde". When the encrypting software is 1_1_0 and the decrypting software is 1_0_1e on Linux or 1_0_2h on Windows, it fails with the message: bad decrypt 139701985818440:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596: Or, in summary When both the encrypting and decrypting software are both 1_1_0, or both 1_0_2(e..h), the decryption succeeded. If the versions were different, it failed. Is this a feature or a bug? Is there some setting I should have different? Thanks in advance David From noloader at gmail.com Sun Sep 4 00:37:50 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 3 Sep 2016 20:37:50 -0400 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> References: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> Message-ID: On Fri, Sep 2, 2016 at 11:50 AM, Leam Hall wrote: > Thanks to Matt Caswell for helping me fix the DSA question. His solution, > based of the information I provided, was: > > openssl genpkey -genparam -algorithm DSA -pkeyopt \ > dsa_paramgen_bits:2048 -out dsa.params > > openssl genpkey -paramfile dsa.params -out dsa.key > > Which leads to my next question. For general application and ssh level > defense, is 2048 the right bit amount? Is there a reason not to go to 4096 > absent very high request counts? Are there other security flags I should > use? Security levels are the way to compare different algorithms. With some hand waiving, its a way to normalize the security provided by an algorithm. As cryptanalysis progresses on an algorithm, the security level usually drops. The naive attack is brute force, but sometimes that's the best known attack. 2048-bit RSA and DSA provides about 112-bits of security. AES-128 provides about 126 bits of security; AES-256 provides about 256-bits of security. SHA-1 provides about 80-bits of theoretical security due to the birthday attack, but its closer to 64-bits in practice due to Stevens attacks (Hash Clash, http://marc-stevens.nl/research/). MD5 provided about 64-bits of theoretical security, but its much less now (http://www.win.tue.nl/hashclash/rogue-ca/). There are tables of security levels from various standards groups. See, for example, SP800-57, SP800-131, ECRYPT II Yearly Report on Algorithms and Key Sizes, etc. You often need to match security levels through out your system. For example, if you are Key Agree'ing or Key Transporting to transport an AES-128 key (128-bits of security), then you _don't_ want to use a RSA 1024-bit modulus (80-bits of security). Obviously, you don't attack AES with 128-bits of security; rather, you attack the 80-bits of security in 1024 RSA because its an easier problem. Regarding SSH's position on DSA, I often wonder why they did not move against ECDSA too since its the same algorithm over a different field. DSA and ECDSA are both ElGamal-like signature schemes, both need a subgroup order with a minimum size, both use a random k, etc. Jeff From rsalz at akamai.com Sun Sep 4 12:43:46 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 4 Sep 2016 12:43:46 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: References: <6ada9694-ea0e-08ea-8936-1256487288a9@gmail.com> Message-ID: <082a3d754b3643278ca2e9937d29d7e2@usma1ex-dag1mb1.msg.corp.akamai.com> > You often need to match security levels through out your system. Shrug. I disagree. Making all the bitlengths line up always struck me as crypto-numerology. YMMV. From uri at ll.mit.edu Sun Sep 4 18:00:45 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 4 Sep 2016 18:00:45 +0000 Subject: [openssl-users] More secure use of DSA? Message-ID: <20160904180053.18292816.77741.88869@ll.mit.edu> Disagree? Then propose a better way to combine algorithms. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Salz, Rich Sent: Sunday, September 4, 2016 08:44 To: noloader at gmail.com; openssl-users at openssl.org Reply To: openssl-users at openssl.org Subject: Re: [openssl-users] More secure use of DSA? > You often need to match security levels through out your system. Shrug. I disagree. Making all the bitlengths line up always struck me as crypto-numerology. YMMV. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From rsalz at akamai.com Sun Sep 4 18:02:18 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 4 Sep 2016 18:02:18 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <20160904180053.18292816.77741.88869@ll.mit.edu> References: <20160904180053.18292816.77741.88869@ll.mit.edu> Message-ID: <21f88d6c56174f7fa4a2a22ce8451b3c@usma1ex-dag1mb1.msg.corp.akamai.com> > Disagree? Then propose a better way to combine algorithms. Sure, just explain to my first why DSA keyspace means exactly the same thing as AES keyspace. From uri at ll.mit.edu Sun Sep 4 18:07:08 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 4 Sep 2016 18:07:08 +0000 Subject: [openssl-users] More secure use of DSA? Message-ID: <20160904180717.18292816.33104.88873@ll.mit.edu> It is *not* keyspace. It is algorithm *strength* (complexity/best known effort required to break it) expressed through key length. Again, propose better ways if you can. So what's your proposed method of combining algorithms?? You reject the commonly accepted approach, but when asked to offer an alternative, you start evading? Do you have no alternative then? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Salz, Rich Sent: Sunday, September 4, 2016 14:02 To: openssl-users at openssl.org; noloader at gmail.com Reply To: openssl-users at openssl.org Subject: Re: [openssl-users] More secure use of DSA? > Disagree? Then propose a better way to combine algorithms. Sure, just explain to my first why DSA keyspace means exactly the same thing as AES keyspace. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From rsalz at akamai.com Sun Sep 4 18:42:45 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 4 Sep 2016 18:42:45 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <20160904180717.18292816.33104.88873@ll.mit.edu> References: <20160904180717.18292816.33104.88873@ll.mit.edu> Message-ID: > So what's your proposed method of combining algorithms?? You reject the > commonly accepted approach, but when asked to offer an alternative, you > start evading? Do you have no alternative then? Start evading. Sheesh. I made a casual comment and said YMMV, encouraging disagreement. Now I find myself being challenged. I am not thrilled with the tenor of this conversation. The needs of encryption aren't necessarily equivalent to the needs of authentication, nor digesting. Nobody has ever shown that they have to be equivalent strength. Why do they have to be? It's just asserted that they should match. I don't buy into that assertion, and will, instead, turn the question back: why do they have to be? From uri at ll.mit.edu Sun Sep 4 19:03:12 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 4 Sep 2016 19:03:12 +0000 Subject: [openssl-users] More secure use of DSA? Message-ID: <20160904190321.18292816.51017.88882@ll.mit.edu> There is a need to combine algorithms of different kind. Since the security of the chain is that of its weakest links - it necessitates comparison between those different algorithms. Thus the assertion that the algorithms combined together should match each other in strength, to avoid both weakening the combination below acceptable pre-defined limit and paying unneeded penalty in performance.? One alternative is combining the strongest known algorithms and pay the penalty in performance (and nobody seems to favor this option). ? I hope I answered your question, and I'm repeating mine: what is your alternative? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Salz, Rich Sent: Sunday, September 4, 2016 14:42 To: openssl-users at openssl.org Reply To: openssl-users at openssl.org Subject: Re: [openssl-users] More secure use of DSA? > So what's your proposed method of combining algorithms?? You reject the > commonly accepted approach, but when asked to offer an alternative, you > start evading? Do you have no alternative then? Start evading. Sheesh. I made a casual comment and said YMMV, encouraging disagreement. Now I find myself being challenged. I am not thrilled with the tenor of this conversation. The needs of encryption aren't necessarily equivalent to the needs of authentication, nor digesting. Nobody has ever shown that they have to be equivalent strength. Why do they have to be? It's just asserted that they should match. I don't buy into that assertion, and will, instead, turn the question back: why do they have to be? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From rsalz at akamai.com Sun Sep 4 19:07:45 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 4 Sep 2016 19:07:45 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <20160904190321.18292816.51017.88882@ll.mit.edu> References: <20160904190321.18292816.51017.88882@ll.mit.edu> Message-ID: Well, you asserted that they need to be the same. Fine. I assert they don't. We're done. From rsalz at akamai.com Sun Sep 4 19:11:58 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 4 Sep 2016 19:11:58 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <20160904190321.18292816.51017.88882@ll.mit.edu> References: <20160904190321.18292816.51017.88882@ll.mit.edu> Message-ID: <30037aeaee9c4da293334023594e963c@usma1ex-dag1mb1.msg.corp.akamai.com> > There is a need to combine algorithms of different kind. Since the security of > the chain is that of its weakest links - it necessitates comparison between > those different algorithms. Only if you think everything has to be equally protected. That's the assertion I am not thrilled with. Sometimes knowing who sent it is more important -- the metadata -- and sometimes the content -- say, the value of the check -- is more important. From noloader at gmail.com Sun Sep 4 19:21:55 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 4 Sep 2016 15:21:55 -0400 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <30037aeaee9c4da293334023594e963c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160904190321.18292816.51017.88882@ll.mit.edu> <30037aeaee9c4da293334023594e963c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > Only if you think everything has to be equally protected. That's the assertion I am not thrilled with. Sometimes knowing who sent it is more important -- the metadata -- and sometimes the content -- say, the value of the check -- is more important. And its probably easier to go around the crypto rather than through it. Why spend the compute cycles when a phishing email will usually do nicely. (I do a lot of work in US DoD and US Federal, so we have to honor security levels). Jeff From dokumentarfilme at hotmail.com Mon Sep 5 15:57:14 2016 From: dokumentarfilme at hotmail.com (.uservorname .usernachname) Date: Mon, 5 Sep 2016 15:57:14 +0000 Subject: [openssl-users] Installed openssl isn't recognized by TrouSerS Message-ID: Greetings, I configured and successfully installed openssl on my readynas duo machine (http://netgear.nas-central.org/wiki/Category:ReadyNasDUO ) However the software TrouSerS tell me to install openssl. nas-02-90-38:~# openssl version OpenSSL 1.0.0t 3 Dec 2015 nas-02-90-38:~# cd /media/trousers-0.3.13 nas-02-90-38:/media/trousers-0.3.13# ./configure checking build system type... sparc-unknown-linux-gnu checking host system type... sparc-unknown-linux-gnu checking target system type... sparc-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /media/trousers-0.3.13/missing: Unknown '--is-lightweight' option Try '/media/trousers-0.3.13/missing --help' for more information configure: WARNING: 'missing' script is too old or missing checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking Non-standard OpenSSL location... no checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for EVP_DigestUpdate in -lcrypto... no configure: error: openssl is currently the only supported crypto library for trousers. Please install openssl from http://www.openssl.org or the -devel package from your distro nas-02-90-38:/media/trousers-0.3.13# Is it possible that openssl is installed but the function EVP_DigestUpdate in -lcrypto... is missing? Any advice would be appreciated.B.R martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmane.bl4 at gishpuppy.com Mon Sep 5 16:25:13 2016 From: gmane.bl4 at gishpuppy.com (Guy) Date: Mon, 05 Sep 2016 11:25:13 -0500 Subject: [openssl-users] Openssl 1_1_0 compatibility question References: <201609032255.u83Mt99N013397@telford.daku.org> Message-ID: david wrote: > On the client: > openssl enc -salt -a -A -aes128 -pass pass:123 > > On the server: > openssl enc -d -salt -a -A -aes128 -pass pass:123 > > When the ENCRYPTING software is 1_0_2h and the > decrypting software is 1_0_1e on Linux or 1_0_2h on Windows, > the decryption successfully recovers the value "abcde". > > When the encrypting software is 1_1_0 and the > decrypting software is 1_0_1e on Linux or 1_0_2h on Windows, > it fails with the message: > > bad decrypt > 139701985818440:error:06065064:digital envelope routines: > EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596: > Reason: v1.1.0 is using the wrong key(from pass) to decrypt. v1.0.x: md5 is default digest v1.1.0: sha256 is default digest Solution: Specify the digest used to create the key. Add '-md md5' to the version 1.0.2 decryption command line, or add '-md sha256' to the v1.0.x encryption command line. From jb-openssl at wisemo.com Mon Sep 5 16:27:25 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 5 Sep 2016 18:27:25 +0200 Subject: [openssl-users] Installed openssl isn't recognized by TrouSerS In-Reply-To: References: Message-ID: <6e051264-08d0-700d-1d02-ce348e672ddc@wisemo.com> On 05/09/2016 17:57, .uservorname .usernachname wrote: > Greetings, > > I configured and successfully installed openssl on my readynas duo > machine (http://netgear.nas-central.org/wiki/Category:ReadyNasDUO ) > > However the software TrouSerS tell me to install openssl. > > nas-02-90-38:~# openssl version > OpenSSL 1.0.0t 3 Dec 2015 > nas-02-90-38:~# cd /media/trousers-0.3.13 > nas-02-90-38:/media/trousers-0.3.13# ./configure > ... > Is it possible that openssl is installed but the function > EVP_DigestUpdate in -lcrypto... is missing? Any advice would > be appreciated. > B.R martin > More likely, you have not installed the "openssl-dev", "openssl-headers" or similarly named package which provides the parts of an OpenSSL installation only needed when building software. Not installing that part of libraries by default is standard practice, as the total sum of all such parts for all installed libraries takes up a lot of disk space. 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 dokumentarfilme at hotmail.com Mon Sep 5 16:47:58 2016 From: dokumentarfilme at hotmail.com (.uservorname .usernachname) Date: Mon, 5 Sep 2016 16:47:58 +0000 Subject: [openssl-users] Installed openssl isn't recognized by TrouSerS In-Reply-To: <6e051264-08d0-700d-1d02-ce348e672ddc@wisemo.com> References: , <6e051264-08d0-700d-1d02-ce348e672ddc@wisemo.com> Message-ID: I don't tink I need the openssl-dev package or something similar because I configured and build openssl-1.0.0t from source with no ./config parameters. Openssl was installed with make install at /usr/local/ssl/ which contains: bin certs include lib man misc openssl.cnf private After trousers didn't find the openssl installation I reconfigured the openssl source with ./config --prefix=/user && make install Greetings martin > To: openssl-users at openssl.org > From: jb-openssl at wisemo.com > Date: Mon, 5 Sep 2016 18:27:25 +0200 > Subject: Re: [openssl-users] Installed openssl isn't recognized by TrouSerS > > On 05/09/2016 17:57, .uservorname .usernachname wrote: > > Greetings, > > > > I configured and successfully installed openssl on my readynas duo > > machine (http://netgear.nas-central.org/wiki/Category:ReadyNasDUO ) > > > > However the software TrouSerS tell me to install openssl. > > > > nas-02-90-38:~# openssl version > > OpenSSL 1.0.0t 3 Dec 2015 > > nas-02-90-38:~# cd /media/trousers-0.3.13 > > nas-02-90-38:/media/trousers-0.3.13# ./configure > > ... > > Is it possible that openssl is installed but the function > > EVP_DigestUpdate in -lcrypto... is missing? Any advice would > > be appreciated. > > B.R martin > > > More likely, you have not installed the "openssl-dev", > "openssl-headers" or similarly named package which provides > the parts of an OpenSSL installation only needed when > building software. Not installing that part of libraries > by default is standard practice, as the total sum of all > such parts for all installed libraries takes up a lot of > disk space. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dokumentarfilme at hotmail.com Mon Sep 5 20:51:34 2016 From: dokumentarfilme at hotmail.com (.uservorname .usernachname) Date: Mon, 5 Sep 2016 20:51:34 +0000 Subject: [openssl-users] Installed openssl isn't recognized by TrouSerS In-Reply-To: References: , , <6e051264-08d0-700d-1d02-ce348e672ddc@wisemo.com>, Message-ID: I fixed this issue by using the following config parameter ./config -Wl,-rpath=/usr/local/ssl/lib shared BR martin From: dokumentarfilme at hotmail.com To: openssl-users at openssl.org Date: Mon, 5 Sep 2016 16:47:58 +0000 Subject: Re: [openssl-users] Installed openssl isn't recognized by TrouSerS I don't tink I need the openssl-dev package or something similar because I configured and build openssl-1.0.0t from source with no ./config parameters. Openssl was installed with make install at /usr/local/ssl/ which contains: bin certs include lib man misc openssl.cnf private After trousers didn't find the openssl installation I reconfigured the openssl source with ./config --prefix=/user && make install Greetings martin > To: openssl-users at openssl.org > From: jb-openssl at wisemo.com > Date: Mon, 5 Sep 2016 18:27:25 +0200 > Subject: Re: [openssl-users] Installed openssl isn't recognized by TrouSerS > > On 05/09/2016 17:57, .uservorname .usernachname wrote: > > Greetings, > > > > I configured and successfully installed openssl on my readynas duo > > machine (http://netgear.nas-central.org/wiki/Category:ReadyNasDUO ) > > > > However the software TrouSerS tell me to install openssl. > > > > nas-02-90-38:~# openssl version > > OpenSSL 1.0.0t 3 Dec 2015 > > nas-02-90-38:~# cd /media/trousers-0.3.13 > > nas-02-90-38:/media/trousers-0.3.13# ./configure > > ... > > Is it possible that openssl is installed but the function > > EVP_DigestUpdate in -lcrypto... is missing? Any advice would > > be appreciated. > > B.R martin > > > More likely, you have not installed the "openssl-dev", > "openssl-headers" or similarly named package which provides > the parts of an OpenSSL installation only needed when > building software. Not installing that part of libraries > by default is standard practice, as the total sum of all > such parts for all installed libraries takes up a lot of > disk space. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Tue Sep 6 13:10:21 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 6 Sep 2016 13:10:21 +0000 Subject: [openssl-users] More secure use of DSA? In-Reply-To: <30037aeaee9c4da293334023594e963c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160904190321.18292816.51017.88882@ll.mit.edu> <30037aeaee9c4da293334023594e963c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <92F9073E-D76C-4D1F-8814-0C43B8EFB088@ll.mit.edu> >> There is a need to combine algorithms of different kind. Since the security of >> the chain is that of its weakest links - it necessitates comparison between >> those different algorithms. > > Only if you think everything has to be equally protected.?? Usually it is not ?equally? but ?at least at that level? and ?for the smallest cost?. Which, for example, means that you want to protect your wrapped 128-bit symmetric key with something of at least 128 bits of presumed strength ? but don?t want to pay for wrapping it with something 1024-bit strong. > That's the assertion I am not thrilled with.??Sometimes knowing who sent it > is more important -- the metadata -- and sometimes the content -- say, > the value of the check -- is more important. True. But for practical reasons people don?t want to define gazillions of cipher suites, as it would be a nightmare to define and manage. Nor do they want to have everything independently negotiable because it would introduce security holes, and besides implementations would surely get it wrong. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5227 bytes Desc: not available URL: From lminiero at gmail.com Tue Sep 6 13:55:31 2016 From: lminiero at gmail.com (Lorenzo Miniero) Date: Tue, 6 Sep 2016 15:55:31 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: References: <55715E7A.4040109@openssl.org> <55717A46.3040104@openssl.org> <5571E80A.1010406@openssl.org> Message-ID: 2015-06-05 20:42 GMT+02:00 Lorenzo Miniero : > 2015-06-05 20:18 GMT+02:00 Matt Caswell : > >> >> I see you got it working! Just some comments below >> >> On 05/06/15 12:34, Lorenzo Miniero wrote: >> > I've started looking into filters and I have some doubts, though, also >> > taking into account what you suggested, and I apologize again if this >> > turns out to be silly. As far as I've understood, what I should do is >> > changing the current pattern I use for outgoing packets: >> > >> > application < memBIO < ssl >> > >> > to something like this: >> > >> > application < memBIO < filter < ssl >> > >> > or this: >> > >> > application < filter < memBIO < ssl >> > >> > that is, a new BIO filter that enforces the fragmentation I talked >> > about. Not exactly sure about which one should be the way to go, but >> > I've given this some thought. >> >> I took a very brief look at your code and I see you went with the first >> option. That's fine, although I would have done it slightly differently: >> >> application <-- -- ssl >> | | >> | V >> filter >> ^ V >> memBIO >> >> i.e. the filter does all the reading and writing to the memBIO. libssl >> calls BIO_write(), the filter takes note of the packet sizes, and then >> writes to the membBIO. When the application wants to read data it calls >> BIO_read on the filter, and the filter figures out how big the packet >> needs to be and reads that amount out of the memBIO. Your way works too >> though. >> >> Matt >> > > > Ah I didn't know that was an option: I'm quite unfamiliar with how BIO > filters worked, and so I just went with what made sense to me while > experimenting with them. I'll try doing something along the lines you > suggested as soon as I have some time, thanks! > > Lorenzo > > Apologies for reviving this old thread, but a user of my project made me notice that my code doesn't compile on Openssl 1.1.0 anymore. Apparently the cause is some structures have been made opaque in the new version. In my case, the structure that breaks the code is BIO, as I used some of its previously public properties in my filter. Is there any transition documentation page that can help figuring out how I can adapt it accordingly? Or is the way my filter was written at the time hopelessly broken now, and a different approach to do the same needed? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Sep 6 14:05:37 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Sep 2016 15:05:37 +0100 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: References: <55715E7A.4040109@openssl.org> <55717A46.3040104@openssl.org> <5571E80A.1010406@openssl.org> Message-ID: <65cffa57-08e9-52e8-ef43-dbc30c1ce362@openssl.org> On 06/09/16 14:55, Lorenzo Miniero wrote: > Apologies for reviving this old thread, but a user of my project made me > notice that my code doesn't compile on Openssl 1.1.0 anymore. Apparently > the cause is some structures have been made opaque in the new version. > In my case, the structure that breaks the code is BIO, as I used some of > its previously public properties in my filter. Is there any transition > documentation page that can help figuring out how I can adapt it > accordingly? Or is the way my filter was written at the time hopelessly > broken now, and a different approach to do the same needed? Probably there is a "getter" function to get at what you need. What properties are they? The BIO_METHOD structure is also now opaque and needs to be setup via the BIO_meth_*() functions. See: https://www.openssl.org/docs/manmaster/crypto/BIO_meth_new.html Matt From lminiero at gmail.com Tue Sep 6 14:22:25 2016 From: lminiero at gmail.com (Lorenzo Miniero) Date: Tue, 6 Sep 2016 16:22:25 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: <65cffa57-08e9-52e8-ef43-dbc30c1ce362@openssl.org> References: <55715E7A.4040109@openssl.org> <55717A46.3040104@openssl.org> <5571E80A.1010406@openssl.org> <65cffa57-08e9-52e8-ef43-dbc30c1ce362@openssl.org> Message-ID: 2016-09-06 16:05 GMT+02:00 Matt Caswell : > > > On 06/09/16 14:55, Lorenzo Miniero wrote: > > Apologies for reviving this old thread, but a user of my project made me > > notice that my code doesn't compile on Openssl 1.1.0 anymore. Apparently > > the cause is some structures have been made opaque in the new version. > > In my case, the structure that breaks the code is BIO, as I used some of > > its previously public properties in my filter. Is there any transition > > documentation page that can help figuring out how I can adapt it > > accordingly? Or is the way my filter was written at the time hopelessly > > broken now, and a different approach to do the same needed? > > Probably there is a "getter" function to get at what you need. What > properties are they? > > The BIO_METHOD structure is also now opaque and needs to be setup via > the BIO_meth_*() functions. See: > > https://www.openssl.org/docs/manmaster/crypto/BIO_meth_new.html > > Thanks for the quick answer! Adapting the BIO_METHOD stuff looks easy enough indeed, thanks for the pointers. The problem is that, in my BIO_METHOD callbacks, I access some of the BIO properties for the logic to implement. For instance, in the *create callback I set, among others, my own helper struct pointer in the ->ptr property of the involved BIO, so that I can always access it when using the BIO itself; or, in the *write callback, I access the ->next_bio property. I'll check if/how I can set/get them on the BIO using dedicated methods instead of accessing properties directly. Thanks! Lorenzo > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Sep 6 14:27:43 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Sep 2016 15:27:43 +0100 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: References: <55715E7A.4040109@openssl.org> <55717A46.3040104@openssl.org> <5571E80A.1010406@openssl.org> <65cffa57-08e9-52e8-ef43-dbc30c1ce362@openssl.org> Message-ID: On 06/09/16 15:22, Lorenzo Miniero wrote: > 2016-09-06 16:05 GMT+02:00 Matt Caswell >: > > > > On 06/09/16 14:55, Lorenzo Miniero wrote: > > Apologies for reviving this old thread, but a user of my project made me > > notice that my code doesn't compile on Openssl 1.1.0 anymore. Apparently > > the cause is some structures have been made opaque in the new version. > > In my case, the structure that breaks the code is BIO, as I used some of > > its previously public properties in my filter. Is there any transition > > documentation page that can help figuring out how I can adapt it > > accordingly? Or is the way my filter was written at the time hopelessly > > broken now, and a different approach to do the same needed? > > Probably there is a "getter" function to get at what you need. What > properties are they? > > The BIO_METHOD structure is also now opaque and needs to be setup via > the BIO_meth_*() functions. See: > > https://www.openssl.org/docs/manmaster/crypto/BIO_meth_new.html > > > > > Thanks for the quick answer! > > Adapting the BIO_METHOD stuff looks easy enough indeed, thanks for the > pointers. The problem is that, in my BIO_METHOD callbacks, I access some > of the BIO properties for the logic to implement. For instance, in the > *create callback I set, among others, my own helper struct pointer in > the ->ptr property of the involved BIO, so that I can always access it > when using the BIO itself; or, in the *write callback, I access the > ->next_bio property. Use BIO_get_data()/BIO_set_data() for ptr, and BIO_next()/BIO_set_next() for next_bio. Matt From lminiero at gmail.com Tue Sep 6 14:31:26 2016 From: lminiero at gmail.com (Lorenzo Miniero) Date: Tue, 6 Sep 2016 16:31:26 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: References: <55715E7A.4040109@openssl.org> <55717A46.3040104@openssl.org> <5571E80A.1010406@openssl.org> <65cffa57-08e9-52e8-ef43-dbc30c1ce362@openssl.org> Message-ID: 2016-09-06 16:27 GMT+02:00 Matt Caswell : > > > On 06/09/16 15:22, Lorenzo Miniero wrote: > > 2016-09-06 16:05 GMT+02:00 Matt Caswell > >: > > > > > > > > On 06/09/16 14:55, Lorenzo Miniero wrote: > > > Apologies for reviving this old thread, but a user of my project > made me > > > notice that my code doesn't compile on Openssl 1.1.0 anymore. > Apparently > > > the cause is some structures have been made opaque in the new > version. > > > In my case, the structure that breaks the code is BIO, as I used > some of > > > its previously public properties in my filter. Is there any > transition > > > documentation page that can help figuring out how I can adapt it > > > accordingly? Or is the way my filter was written at the time > hopelessly > > > broken now, and a different approach to do the same needed? > > > > Probably there is a "getter" function to get at what you need. What > > properties are they? > > > > The BIO_METHOD structure is also now opaque and needs to be setup via > > the BIO_meth_*() functions. See: > > > > https://www.openssl.org/docs/manmaster/crypto/BIO_meth_new.html > > > > > > > > > > Thanks for the quick answer! > > > > Adapting the BIO_METHOD stuff looks easy enough indeed, thanks for the > > pointers. The problem is that, in my BIO_METHOD callbacks, I access some > > of the BIO properties for the logic to implement. For instance, in the > > *create callback I set, among others, my own helper struct pointer in > > the ->ptr property of the involved BIO, so that I can always access it > > when using the BIO itself; or, in the *write callback, I access the > > ->next_bio property. > > Use BIO_get_data()/BIO_set_data() for ptr, and BIO_next()/BIO_set_next() > for next_bio. > > I was looking at the BIO docs right now (BIO_set_init and the others) but you beat me to it... thanks again for the very fast help, it's really appreciated! Lorenzo > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at daku.org Tue Sep 6 14:39:01 2016 From: david at daku.org (david) Date: Tue, 06 Sep 2016 07:39:01 -0700 Subject: [openssl-users] Openssl 1_1_0 compatibility question In-Reply-To: References: <201609032255.u83Mt99N013397@telford.daku.org> Message-ID: <201609061443.u86EhcDL019526@telford.daku.org> At 09:25 AM 9/5/2016, you wrote: >david wrote: > > > On the client: > > openssl enc -salt -a -A -aes128 -pass pass:123 > > > > On the server: > > openssl enc -d -salt -a -A -aes128 -pass pass:123 > > > > When the ENCRYPTING software is 1_0_2h and the > > decrypting software is 1_0_1e on Linux or 1_0_2h on Windows, > > the decryption successfully recovers the value "abcde". > > > > When the encrypting software is 1_1_0 and the > > decrypting software is 1_0_1e on Linux or 1_0_2h on Windows, > > it fails with the message: > > > > bad decrypt > > 139701985818440:error:06065064:digital envelope routines: > > EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596: > > > > >Reason: >v1.1.0 is using the wrong key(from pass) to decrypt. > > v1.0.x: md5 is default digest > v1.1.0: sha256 is default digest > >Solution: >Specify the digest used to create the key. > > Add '-md md5' to the version 1.0.2 decryption command line, > or add '-md sha256' to the v1.0.x encryption command line. > Thanks for this. I must have missed the change in default-digest algorithm in the release notes. David From nicolas.brunie at kalray.eu Tue Sep 6 16:10:31 2016 From: nicolas.brunie at kalray.eu (Nicolas Brunie) Date: Tue, 06 Sep 2016 18:10:31 +0200 Subject: [openssl-users] Async engine and BIOs Message-ID: <57CEEA77.10009@kalray.eu> Hi Everyone, I am trying to mix an application with a buffer BIO over a SSL BIO which uses an asynchronous engine for offloading. I had a quick look at the SSL BIO (ssl/bio_ssl.c) and it does not seem to care about the error SSL_ERROR_WANT_ASYNC coming from a SSL_write or a SSL_read. Does this means that this error is silently ignored ? Does it means the BIO chains will retry automatically to call the SSL_write ou SSL_read with the same arguments to make it finish ? Does it mean my call to BIO_write/BIO_read will return directly when the engine call ASYNC_pause_job without fnishing the job and I have to call BIO_write / BIO_read until the sum or return value equals the amount of data I was expected it to proceed ? best regards, Nicolas From rsalz at akamai.com Tue Sep 6 17:11:01 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Sep 2016 17:11:01 +0000 Subject: [openssl-users] dates, times, durations in next release (commands) Message-ID: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> I am thinking of standardizing the syntax for dates, times, and durations used by the applications in the next releases, based on http://www.w3schools.com/xml/schema_dtypes_date.asp (with the extension that lowercase letters can also be used). Objects that need dates (x509 etc) will have a standard -start flag. It takes an ISO date-time, the time defaulting to 00:00. A time and duration can be specified by putting /duration after the start date. Or the abosolute time can be specified with an -end flag. For example -start 2017-02-10/p30d -start 2017-02-10 -end 2017-03-12 Both mean the same thing, from Feb 10 for 30 days. Comments? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at synchronoss.com Tue Sep 6 15:53:45 2016 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Tue, 6 Sep 2016 15:53:45 +0000 Subject: [openssl-users] A self-signed CA certificate in the CA file *sometimes* stops verification working Message-ID: OpenSSL 1.0.2h on Windows (different versions). I have noticed the following behaviour: 1 Create a certificate file with two CA certificates, one for the server being connected to (server A) and one for another server (server B). 2 Whichever way the CA certificates are ordered the connect works OK. 3 Add a self-signed CA certificate in the file before the one for server A. The connect fails 'Verify return code: 21 (unable to verify the first certificate)'. 4 Move the self-signed CA certificate after the one for server A. The connect works OK. Why should the self-signed certificate affect the connection when the required CA certificate is in the certificate file? Is this a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Sep 6 17:39:33 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 06 Sep 2016 19:39:33 +0200 (CEST) Subject: [openssl-users] [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160906.193933.2272151712340631325.levitte@openssl.org> In message <490f88be6dcf4d5c9baa3f3b5e4c4e83 at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 6 Sep 2016 17:11:01 +0000, "Salz, Rich" said: rsalz> I am thinking of standardizing the syntax for dates, times, and rsalz> durations used by the applications in the next releases, based on rsalz> http://www.w3schools.com/xml/schema_dtypes_date.asp (with the rsalz> extension that lowercase letters can also be used). rsalz> rsalz> Objects that need dates (x509 etc) will have a standard ?start flag. rsalz> It takes an ISO date-time, the time defaulting to 00:00. A time and rsalz> duration can be specified by putting /duration after the start date. rsalz> Or the abosolute time can be specified with an ?end flag. For example rsalz> rsalz> -start 2017-02-10/p30d rsalz> rsalz> -start 2017-02-10 ?end 2017-03-12 rsalz> rsalz> Both mean the same thing, from Feb 10 for 30 days. rsalz> rsalz> Comments? It's not a huge step to support full blown ISO 8601 (which has a few more alternatives to specify time intervals *). I like the idea. Cheers, Richard (*) https://en.wikipedia.org/wiki/ISO_8601 -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jb-openssl at wisemo.com Tue Sep 6 17:40:41 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 6 Sep 2016 19:40:41 +0200 Subject: [openssl-users] dates, times, durations in next release (commands) In-Reply-To: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <3b1a83b1-4e51-d2fc-0877-4540d7a0098a@wisemo.com> On 06/09/2016 19:11, Salz, Rich wrote: > > I am thinking of standardizing the syntax for dates, times, and > durations used by the applications in the next releases, based on > http://www.w3schools.com/xml/schema_dtypes_date.asp (with the > extension that lowercase letters can also be used). > > Objects that need dates (x509 etc) will have a standard ?start flag. > It takes an ISO date-time, the time defaulting to 00:00. A time and > duration can be specified by putting /duration after the start date. > Or the abosolute time can be specified with an ?end flag. For example > > -start 2017-02-10/p30d > > -start 2017-02-10 ?end 2017-03-12 > > Both mean the same thing, from Feb 10 for 30 days. > > Comments? > > Please don't break compatibility with any command lines that may have been embedded into thousands of scripts around the world. So if a date/time/period string was acceptable to the old code, it should remain acceptable to the new code. This does not preclude unifying the parser code and rules, it simply means that the established syntax forms need to be accepted and take priority over any new forms added where the same string could have different meanings. Another related (long standing) issue is the inability to state an "as of" date to the various commands and APIs that validate signatures, certificates etc. Both past and future dates can be needed in various use cases. For any date related code, do not limit to the timespan of the system (or POSIX) time_t type. This would fail for long- duration root certificates, long-duration Android code signing certificates and for fields that specify dates other than certificate validity (such as date of birth or date of foundation for company/organizational entities). As test cases, try encoding the foundation date of e.g. the country China (not its current regime, but the country itself) or the religious organization commonly referred to as the Roman Catholic Church. Similarly, try encoding various future dates listed in documents such as the various Climate related treaties (though those would be less likely to appear in certificates). And of cause, never confuse the PKIX profile with the ITU-T standards. For example, PKIX limits some data fields to 1s precision while the standards do not. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Tue Sep 6 17:46:33 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 6 Sep 2016 13:46:33 -0400 Subject: [openssl-users] A self-signed CA certificate in the CA file *sometimes* stops verification working In-Reply-To: References: Message-ID: > On Sep 6, 2016, at 11:53 AM, John Unsworth wrote: > > I have noticed the following behaviour: > > 1 Create a certificate file with two CA certificates, one for the server being connected to (server A) and one for another server (server B). > 2 Whichever way the CA certificates are ordered the connect works OK. > 3 Add a self-signed CA certificate in the file before the one for server A. The connect fails ?Verify return code: 21 (unable to verify the first certificate)?. > 4 Move the self-signed CA certificate after the one for server A. The connect works OK. > > Why should the self-signed certificate affect the connection when the required CA certificate is in the certificate file? Is this a bug? You've provided much too little detail for a meaningful answer. Post the server chain being validated as reported by $ openssl s_client -showcerts -connect :443 > chain.pem $ openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs and all three CA certificates. Do not post any of the private keys. -- Viktor. From kudzu at tenebras.com Tue Sep 6 18:03:02 2016 From: kudzu at tenebras.com (Michael Sierchio) Date: Tue, 6 Sep 2016 11:03:02 -0700 Subject: [openssl-users] dates, times, durations in next release (commands) In-Reply-To: <3b1a83b1-4e51-d2fc-0877-4540d7a0098a@wisemo.com> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <3b1a83b1-4e51-d2fc-0877-4540d7a0098a@wisemo.com> Message-ID: On Tue, Sep 6, 2016 at 10:40 AM, Jakob Bohm wrote: ... > Another related (long standing) issue is the inability to > state an "as of" date to the various commands and APIs that > validate signatures, certificates etc. Both past and future > dates can be needed in various use cases. ... That would be really useful. An expired or revoked certificate may still be used to verify a signature generated at a time when the certificate was valid. -- "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent man requires only two thousand five hundred." - The Mah?bh?rata -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Sep 6 19:14:38 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Sep 2016 19:14:38 +0000 Subject: [openssl-users] [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: <20160906.193933.2272151712340631325.levitte@openssl.org> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.193933.2272151712340631325.levitte@openssl.org> Message-ID: <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> > It's not a huge step to support full blown ISO 8601 (which has a few more > alternatives to specify time intervals *). I like the idea. No, it *is* a huge step. There's a reason why W3C XML schema language (XSD), not known for being lightweight, profiled the ISO standard. From levitte at openssl.org Tue Sep 6 19:34:17 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 06 Sep 2016 21:34:17 +0200 (CEST) Subject: [openssl-users] [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.193933.2272151712340631325.levitte@openssl.org> <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160906.213417.1719569548619936717.levitte@openssl.org> In message <3a1728b8c014426bb3e557832d275961 at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 6 Sep 2016 19:14:38 +0000, "Salz, Rich" said: rsalz> rsalz> > It's not a huge step to support full blown ISO 8601 (which has a few more rsalz> > alternatives to specify time intervals *). I like the idea. rsalz> rsalz> No, it *is* a huge step. There's a reason why W3C XML schema language (XSD), not known for being lightweight, profiled the ISO standard. Sorry, I was unclear. What I meant was that it's not a huge step from the XSD to full blown ISO 8601. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From John.Unsworth at synchronoss.com Tue Sep 6 18:10:42 2016 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Tue, 6 Sep 2016 18:10:42 +0000 Subject: [openssl-users] A self-signed CA certificate in the CA files *sometimes* stops verification working Message-ID: This seems to me to be very easy to validate by just inserting a self-signed certificate at the front of a CAfile that works. Attached are the 3 certificate files. _CAcerts.good is the first file with two certs the second of which is the CA cert for the server. _CAcerts.bad has the self-signed cert inserted between the two original CA certs. _CAcerts.bad.fixed has the self-signed cert last, after the valid CAcert for the server. Test 1 -------- C:\Users\junswort>openssl s_client -connect WIN-VO1BBDJPNIT.win2k12.marshhouse:6 36 -showcerts -CAfile c:\certs\_CAcerts.good WARNING: can't open config file: static/static/ssl/openssl.cnf CONNECTED(00000158) depth=1 DC = marshhouse, DC = win2k12, CN = win2k12-WIN-VO1BBDJPNIT-CA verify return:1 depth=0 CN = WIN-VO1BBDJPNIT.win2k12.marshhouse verify return:1 --- Certificate chain 0 s:/CN=WIN-VO1BBDJPNIT.win2k12.marshhouse i:/DC=marshhouse/DC=win2k12/CN=win2k12-WIN-VO1BBDJPNIT-CA -----BEGIN CERTIFICATE----- MIIGRDCCBSygAwIBAgITJwAAAAQdtc/gsC8FGAAAAAAABDANBgkqhkiG9w0BAQ0F ADBaMRowGAYKCZImiZPyLGQBGRYKbWFyc2hob3VzZTEXMBUGCgmSJomT8ixkARkW B3dpbjJrMTIxIzAhBgNVBAMTGndpbjJrMTItV0lOLVZPMUJCREpQTklULUNBMB4X DTE2MDgyNDE1MjczM1oXDTE3MDgyNDE1MjczM1owLTErMCkGA1UEAxMiV0lOLVZP MUJCREpQTklULndpbjJrMTIubWFyc2hob3VzZTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBANGrtW9LP8NV8Bv828I7jR7zHcQeGiW88NnYMalcBD9RGeR0 IPlnmudxxGTKQ7ltTXG+1dKxY9+X3e9F+okovs1Yb0Zfl9trAi1JffvvVZoSZioK HNH5j8EbDGYqw9hdnmp9FT942qBiLz5vNNN8Td9ONJ4AO2jn9mVuj3Ay6m3G+n4h cHxV4ocKL+1r1FfrHmbsvoYAo/wC0i+T+0peqOJ0hN2Eh5v09pNhGAeb6SMDR9DF xJVmENyu1+a1Q851FAZhOYPICFmtZEiXUAKnCTXswuKcuekXOJ6xA1bcVAXo4V0L SRzulW42IuhVG9cTv5fgQE8xJr9UhU3QCxtJbYkCAwEAAaOCAy4wggMqMC8GCSsG AQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8AbABsAGUAcjAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQDAgWgMHgGCSqG SIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDALBglg hkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUw BwYFKw4DAgcwCgYIKoZIhvcNAwcwTgYDVR0RBEcwRaAfBgkrBgEEAYI3GQGgEgQQ ibBbg2xk+kWByfTmlhHwqIIiV0lOLVZPMUJCREpQTklULndpbjJrMTIubWFyc2ho b3VzZTAdBgNVHQ4EFgQUSCFbjzQV9034463X2wih64kj+5QwHwYDVR0jBBgwFoAU rOn/0VeHz/Z6UbAIz6NjTLSCAi4wgecGA1UdHwSB3zCB3DCB2aCB1qCB04aB0Gxk YXA6Ly8vQ049d2luMmsxMi1XSU4tVk8xQkJESlBOSVQtQ0EsQ049V0lOLVZPMUJC REpQTklULENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2 aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbjJrMTIsREM9bWFyc2hob3VzZT9j ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz dHJpYnV0aW9uUG9pbnQwgdMGCCsGAQUFBwEBBIHGMIHDMIHABggrBgEFBQcwAoaB s2xkYXA6Ly8vQ049d2luMmsxMi1XSU4tVk8xQkJESlBOSVQtQ0EsQ049QUlBLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy YXRpb24sREM9d2luMmsxMixEQz1tYXJzaGhvdXNlP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEB DQUAA4IBAQB6BRo5lsw19dEii2GGE/4bisSDPYKcDxOKv5Nao3jtt3KGDs19ZFk3 hIQcScKo4+TFDDGsoQExk0NpGc3nRryL5HqK3jUIWhzz9SI+Fa/NMuHYdTqtuiAF fUvnmwFH/d6fIEnCKVLKoOw2ZbFO92Fl+uT8QJchfpwlMWLwWi1edHP+vhSx8v8O HG9ycnhDw4VPH7rlaSEHe3Or7Twh9F/CHpDOTPMOnqHRprUAOzjQnAlmjHsNDp/8 +smY8Z2NyhSFXnI2hXe4HOLrpEwwjD1DhdW5XQ3JW8smSJRgbQspIcmf9XNi4fAO JvJ946dYI/JOydAV4yXvqJnNot/b+ozU -----END CERTIFICATE----- --- Server certificate subject=/CN=WIN-VO1BBDJPNIT.win2k12.marshhouse issuer=/DC=marshhouse/DC=win2k12/CN=win2k12-WIN-VO1BBDJPNIT-CA --- No client certificate CA names sent Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RS A+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SH A384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1 Peer signing digest: SHA1 Server Temp Key: ECDH, P-384, 384 bits --- SSL handshake has read 2210 bytes and written 533 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-SHA384 Session-ID: E0160000CE718976B41B64700D5D6EA14414691D9F22928F1B360218A35B0E85 Session-ID-ctx: Master-Key: F0A0E15DEEE0B675A8A84C6C9E827313BCCF37AB5F65F3EA8B08E92E25D367DD 8839E878903ADC3183E5F8C1D73F5A4B Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1473184726 Timeout : 300 (sec) Verify return code: 0 (ok) Test 2 -------- C:\Users\junswort>openssl s_client -connect WIN-VO1BBDJPNIT.win2k12.marshhouse:6 36 -showcerts -CAfile c:\certs\_CAcerts.bad WARNING: can't open config file: static/static/ssl/openssl.cnf CONNECTED(00000158) depth=0 CN = WIN-VO1BBDJPNIT.win2k12.marshhouse verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = WIN-VO1BBDJPNIT.win2k12.marshhouse verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=WIN-VO1BBDJPNIT.win2k12.marshhouse i:/DC=marshhouse/DC=win2k12/CN=win2k12-WIN-VO1BBDJPNIT-CA -----BEGIN CERTIFICATE----- MIIGRDCCBSygAwIBAgITJwAAAAQdtc/gsC8FGAAAAAAABDANBgkqhkiG9w0BAQ0F ADBaMRowGAYKCZImiZPyLGQBGRYKbWFyc2hob3VzZTEXMBUGCgmSJomT8ixkARkW B3dpbjJrMTIxIzAhBgNVBAMTGndpbjJrMTItV0lOLVZPMUJCREpQTklULUNBMB4X DTE2MDgyNDE1MjczM1oXDTE3MDgyNDE1MjczM1owLTErMCkGA1UEAxMiV0lOLVZP MUJCREpQTklULndpbjJrMTIubWFyc2hob3VzZTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBANGrtW9LP8NV8Bv828I7jR7zHcQeGiW88NnYMalcBD9RGeR0 IPlnmudxxGTKQ7ltTXG+1dKxY9+X3e9F+okovs1Yb0Zfl9trAi1JffvvVZoSZioK HNH5j8EbDGYqw9hdnmp9FT942qBiLz5vNNN8Td9ONJ4AO2jn9mVuj3Ay6m3G+n4h cHxV4ocKL+1r1FfrHmbsvoYAo/wC0i+T+0peqOJ0hN2Eh5v09pNhGAeb6SMDR9DF xJVmENyu1+a1Q851FAZhOYPICFmtZEiXUAKnCTXswuKcuekXOJ6xA1bcVAXo4V0L SRzulW42IuhVG9cTv5fgQE8xJr9UhU3QCxtJbYkCAwEAAaOCAy4wggMqMC8GCSsG AQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8AbABsAGUAcjAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQDAgWgMHgGCSqG SIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDALBglg hkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUw BwYFKw4DAgcwCgYIKoZIhvcNAwcwTgYDVR0RBEcwRaAfBgkrBgEEAYI3GQGgEgQQ ibBbg2xk+kWByfTmlhHwqIIiV0lOLVZPMUJCREpQTklULndpbjJrMTIubWFyc2ho b3VzZTAdBgNVHQ4EFgQUSCFbjzQV9034463X2wih64kj+5QwHwYDVR0jBBgwFoAU rOn/0VeHz/Z6UbAIz6NjTLSCAi4wgecGA1UdHwSB3zCB3DCB2aCB1qCB04aB0Gxk YXA6Ly8vQ049d2luMmsxMi1XSU4tVk8xQkJESlBOSVQtQ0EsQ049V0lOLVZPMUJC REpQTklULENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2 aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbjJrMTIsREM9bWFyc2hob3VzZT9j ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz dHJpYnV0aW9uUG9pbnQwgdMGCCsGAQUFBwEBBIHGMIHDMIHABggrBgEFBQcwAoaB s2xkYXA6Ly8vQ049d2luMmsxMi1XSU4tVk8xQkJESlBOSVQtQ0EsQ049QUlBLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy YXRpb24sREM9d2luMmsxMixEQz1tYXJzaGhvdXNlP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEB DQUAA4IBAQB6BRo5lsw19dEii2GGE/4bisSDPYKcDxOKv5Nao3jtt3KGDs19ZFk3 hIQcScKo4+TFDDGsoQExk0NpGc3nRryL5HqK3jUIWhzz9SI+Fa/NMuHYdTqtuiAF fUvnmwFH/d6fIEnCKVLKoOw2ZbFO92Fl+uT8QJchfpwlMWLwWi1edHP+vhSx8v8O HG9ycnhDw4VPH7rlaSEHe3Or7Twh9F/CHpDOTPMOnqHRprUAOzjQnAlmjHsNDp/8 +smY8Z2NyhSFXnI2hXe4HOLrpEwwjD1DhdW5XQ3JW8smSJRgbQspIcmf9XNi4fAO JvJ946dYI/JOydAV4yXvqJnNot/b+ozU -----END CERTIFICATE----- --- Server certificate subject=/CN=WIN-VO1BBDJPNIT.win2k12.marshhouse issuer=/DC=marshhouse/DC=win2k12/CN=win2k12-WIN-VO1BBDJPNIT-CA --- No client certificate CA names sent Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RS A+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SH A384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1 Peer signing digest: SHA1 Server Temp Key: ECDH, P-384, 384 bits --- SSL handshake has read 2210 bytes and written 533 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-SHA384 Session-ID: D51D0000964C48960FBDB92D73989E9FED3BE5142A228C97055AF84A5A84F027 Session-ID-ctx: Master-Key: FBDAD623108F8AA5B342B62388C298716FC72620403BBC77D8D7C6A82EADAF02 77FC233C88D9D6B1E352E97A97B599A4 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1473184857 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) Test 3 -------- C:\Users\junswort>openssl s_client -connect WIN-VO1BBDJPNIT.win2k12.marshhouse:6 36 -showcerts -CAfile c:\certs\_CAcerts.bad.fixed WARNING: can't open config file: static/static/ssl/openssl.cnf CONNECTED(00000158) depth=1 DC = marshhouse, DC = win2k12, CN = win2k12-WIN-VO1BBDJPNIT-CA verify return:1 depth=0 CN = WIN-VO1BBDJPNIT.win2k12.marshhouse verify return:1 --- Certificate chain 0 s:/CN=WIN-VO1BBDJPNIT.win2k12.marshhouse i:/DC=marshhouse/DC=win2k12/CN=win2k12-WIN-VO1BBDJPNIT-CA -----BEGIN CERTIFICATE----- MIIGRDCCBSygAwIBAgITJwAAAAQdtc/gsC8FGAAAAAAABDANBgkqhkiG9w0BAQ0F ADBaMRowGAYKCZImiZPyLGQBGRYKbWFyc2hob3VzZTEXMBUGCgmSJomT8ixkARkW B3dpbjJrMTIxIzAhBgNVBAMTGndpbjJrMTItV0lOLVZPMUJCREpQTklULUNBMB4X DTE2MDgyNDE1MjczM1oXDTE3MDgyNDE1MjczM1owLTErMCkGA1UEAxMiV0lOLVZP MUJCREpQTklULndpbjJrMTIubWFyc2hob3VzZTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBANGrtW9LP8NV8Bv828I7jR7zHcQeGiW88NnYMalcBD9RGeR0 IPlnmudxxGTKQ7ltTXG+1dKxY9+X3e9F+okovs1Yb0Zfl9trAi1JffvvVZoSZioK HNH5j8EbDGYqw9hdnmp9FT942qBiLz5vNNN8Td9ONJ4AO2jn9mVuj3Ay6m3G+n4h cHxV4ocKL+1r1FfrHmbsvoYAo/wC0i+T+0peqOJ0hN2Eh5v09pNhGAeb6SMDR9DF xJVmENyu1+a1Q851FAZhOYPICFmtZEiXUAKnCTXswuKcuekXOJ6xA1bcVAXo4V0L SRzulW42IuhVG9cTv5fgQE8xJr9UhU3QCxtJbYkCAwEAAaOCAy4wggMqMC8GCSsG AQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8AbABsAGUAcjAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQDAgWgMHgGCSqG SIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDALBglg hkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUw BwYFKw4DAgcwCgYIKoZIhvcNAwcwTgYDVR0RBEcwRaAfBgkrBgEEAYI3GQGgEgQQ ibBbg2xk+kWByfTmlhHwqIIiV0lOLVZPMUJCREpQTklULndpbjJrMTIubWFyc2ho b3VzZTAdBgNVHQ4EFgQUSCFbjzQV9034463X2wih64kj+5QwHwYDVR0jBBgwFoAU rOn/0VeHz/Z6UbAIz6NjTLSCAi4wgecGA1UdHwSB3zCB3DCB2aCB1qCB04aB0Gxk YXA6Ly8vQ049d2luMmsxMi1XSU4tVk8xQkJESlBOSVQtQ0EsQ049V0lOLVZPMUJC REpQTklULENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2 aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbjJrMTIsREM9bWFyc2hob3VzZT9j ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz dHJpYnV0aW9uUG9pbnQwgdMGCCsGAQUFBwEBBIHGMIHDMIHABggrBgEFBQcwAoaB s2xkYXA6Ly8vQ049d2luMmsxMi1XSU4tVk8xQkJESlBOSVQtQ0EsQ049QUlBLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy YXRpb24sREM9d2luMmsxMixEQz1tYXJzaGhvdXNlP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEB DQUAA4IBAQB6BRo5lsw19dEii2GGE/4bisSDPYKcDxOKv5Nao3jtt3KGDs19ZFk3 hIQcScKo4+TFDDGsoQExk0NpGc3nRryL5HqK3jUIWhzz9SI+Fa/NMuHYdTqtuiAF fUvnmwFH/d6fIEnCKVLKoOw2ZbFO92Fl+uT8QJchfpwlMWLwWi1edHP+vhSx8v8O HG9ycnhDw4VPH7rlaSEHe3Or7Twh9F/CHpDOTPMOnqHRprUAOzjQnAlmjHsNDp/8 +smY8Z2NyhSFXnI2hXe4HOLrpEwwjD1DhdW5XQ3JW8smSJRgbQspIcmf9XNi4fAO JvJ946dYI/JOydAV4yXvqJnNot/b+ozU -----END CERTIFICATE----- --- Server certificate subject=/CN=WIN-VO1BBDJPNIT.win2k12.marshhouse issuer=/DC=marshhouse/DC=win2k12/CN=win2k12-WIN-VO1BBDJPNIT-CA --- No client certificate CA names sent Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RS A+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SH A384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1 Peer signing digest: SHA1 Server Temp Key: ECDH, P-384, 384 bits --- SSL handshake has read 2210 bytes and written 533 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-SHA384 Session-ID: 640700008BAE822317D1CCBE249A1DFDE7D40963500ABC96EFD973972C689062 Session-ID-ctx: Master-Key: 94B722012AAAD6270AF2304805C6D3C415B8C94E906A1B73ABDBF04CE850E710 D672A81CBB72AC2B17071B5B6F8BDD82 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1473185012 Timeout : 300 (sec) Verify return code: 0 (ok) -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: 06 September 2016 18:47 To: openssl-users at openssl.org Subject: Re: [openssl-users] A self-signed CA certificate in the CA file *sometimes* stops verification working > On Sep 6, 2016, at 11:53 AM, John Unsworth wrote: > > I have noticed the following behaviour: > > 1 Create a certificate file with two CA certificates, one for the server being connected to (server A) and one for another server (server B). > 2 Whichever way the CA certificates are ordered the connect works OK. > 3 Add a self-signed CA certificate in the file before the one for server A. The connect fails ?Verify return code: 21 (unable to verify the first certificate)?. > 4 Move the self-signed CA certificate after the one for server A. The connect works OK. > > Why should the self-signed certificate affect the connection when the required CA certificate is in the certificate file? Is this a bug? You've provided much too little detail for a meaningful answer. Post the server chain being validated as reported by $ openssl s_client -showcerts -connect :443 > chain.pem $ openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs and all three CA certificates. Do not post any of the private keys. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: _CAcerts.bad.fixed Type: application/octet-stream Size: 4522 bytes Desc: _CAcerts.bad.fixed URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: _CAcerts.good Type: application/octet-stream Size: 2572 bytes Desc: _CAcerts.good URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: _CAcerts.bad Type: application/octet-stream Size: 4445 bytes Desc: _CAcerts.bad URL: From openssl-users at dukhovni.org Tue Sep 6 20:13:58 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 6 Sep 2016 20:13:58 +0000 Subject: [openssl-users] A self-signed CA certificate in the CA files *sometimes* stops verification working In-Reply-To: References: Message-ID: <20160906201358.GO4670@mournblade.imrryr.org> On Tue, Sep 06, 2016 at 06:10:42PM +0000, John Unsworth wrote: > This seems to me to be very easy to validate by just inserting a self-signed certificate at the front of a CAfile that works. > > Attached are the 3 certificate files. > > _CAcerts.good is the first file with two certs the second of which is the CA cert for the server. > _CAcerts.bad has the self-signed cert inserted between the two original CA certs. > _CAcerts.bad.fixed has the self-signed cert last, after the valid CAcert for the server. The CAcerts.bad file contains a NUL byte at the start of the (should be) blank line separating two of the certificates. This prevents OpenSSL from reading the rest of the file. Cleaned-up CAfiles attached, the server cert verifies with all three. $ for file in _CAcerts.*; do echo $file; openssl verify -CAfile $file chain.pem; done _CAcerts.bad chain.pem: OK _CAcerts.bad.fixed chain.pem: OK _CAcerts.good chain.pem: OK -- Viktor. -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIDfzCCAmegAwIBAgIQXZs1QSHJgbpJzo6xfNL5MjANBgkqhkiG9w0BAQUFADBS MRUwEwYKCZImiZPyLGQBGRYFTE9DQUwxFzAVBgoJkiaJk/IsZAEZFgdKVU5TLUFE MSAwHgYDVQQDExdKVU5TLUFELUpVTlMtV0lOMjAxMi1DQTAeFw0xMzAxMTYxMTU3 MzVaFw0xODAxMTYxMjA3MzVaMFIxFTATBgoJkiaJk/IsZAEZFgVMT0NBTDEXMBUG CgmSJomT8ixkARkWB0pVTlMtQUQxIDAeBgNVBAMTF0pVTlMtQUQtSlVOUy1XSU4y MDEyLUNBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsbxYiKq2LGWV Mki8lNrjcboXiVL2pRM2GNTzoUANrPC11ylCuCG7cSqAqoEJjQ5AC62llrSR8z2F DmyslpO/vgnZu9hO81HOZFeCMcIgSuPim7dS+pbkEBvXb3oyKK8mmKFZmOh63taK hSMMzvCzIheado2qvo67se1A68x5lVWD5kUGefc8RAGhPrriYfa3cQIaYXe+KQDl 1uuKPOhJJr6VlGS8HUGCLkDwzgSbRmiYr2TmNoIl0bo3jvY3dIHKGicAxcuUTlAg psbg6pCKZiL6NKUl8BHXkvRvd/JNR81XsNNo2/54UMu0hbIGYh2D2zEFsBhIK6fU HwNg1tqs9QIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQUQorgEGd0Je1syR23SZCqgy8XsLAwEAYJKwYBBAGCNxUBBAMCAQAw DQYJKoZIhvcNAQEFBQADggEBAB7Hj+8lpsd98uMLtOGSYLePe/8cslLK6bYBScmB 3FRyBX9rrYrAclQWk8pfbnUfbXiQAhq5MXQEtx/wScJFEwQP0fXQ5it2f/9IaFya MqylPn7S2dKfTLiEdkJH1L9Ar4N9pY/EP3H6+5uZk9iMEvac9kyCgVEXlEQy1Djw 7OXn+rKdYbjFpQV4KScShRw9LUFp8SHhDi6WCdF/cAxAbhS5HSjXjHHp7l2ZuPhZ T6mELVdnF4rW9bwwJRsmbHuotrN2N5LwcybT1AX9E9lTnQrCTT7Y0c//ySCUYk+p Rol+UgE0ckRhoDfNNCP6rXNyKBZjYwdJF0+6SZqozHBXvyM= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFNzCCBB+gAwIBAgIkAhwR/6RdpYmtWdJi6rVCPPmhLs9Uf9hVmML28dKTAgIX n543MA0GCSqGSIb3DQEBBQUAMDQxGjAYBgNVBAsTEU9yZ2FuaXphdGlvbmFsIENB MRYwFAYDVQQKEw1VQlMtU1lOQy1UUkVFMB4XDTA5MDkxNTA5NTYxOFoXDTE5MDkx NTA5NTYxOFowNDEaMBgGA1UECxMRT3JnYW5pemF0aW9uYWwgQ0ExFjAUBgNVBAoT DVVCUy1TWU5DLVRSRUUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDb GtfEjhT1WXvTJBT9Jt/zftUiAbMUvxOOIww5W/TmtHZxEsruch+AAE1Xqh9d1eS6 2bkY9zuxTTAzXpI0xxiwg+Bk1ayYUBvDghUQFSw2iBXuuwx2kpcJ/1ZCJr+zm1bD TkQeBRvcRplYt1BdeVFjzkiBkJetMoe58QQmCf2+YDego+YAZkIOSTZzusXeJjAJ 4T2TdY8AHX9Y/Zu4KBhObSZetVMXwFDp1b/Y+wUnzGRw+3gni9KMOS376tNHDNxZ 1yTLtd9ZTocBjCpvKlwJaUwIvsQ+FpaGQvCkIItq4dp1GNmNIO6emhrXjSjY5WmR X4/ksfN7JeuqyoBzl1HBAgMBAAGjggIvMIICKzAdBgNVHQ4EFgQUltZ+VFHgDRx3 Z8RKixbRyE9xRL8wHwYDVR0jBBgwFoAUltZ+VFHgDRx3Z8RKixbRyE9xRL8wDAYD VR0TBAUwAwEB/zALBgNVHQ8EBAMCAQYwggHMBgtghkgBhvg3AQkEAQSCAbswggG3 BAIBAAEB/xMdTm92ZWxsIFNlY3VyaXR5IEF0dHJpYnV0ZSh0bSkWQ2h0dHA6Ly9k ZXZlbG9wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJpYnV0ZXMvY2VydGF0 dHJzX3YxMC5odG0wggFIoBoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaEaAQEA MAgwBgIBAQIBADAIMAYCAQECAQACAQCiBgIBGAEB/6OCAQSgWAIBAgICAP8CAQAD DQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQG 8N9IMBgwEAIBAAIIf/////////8BAQACBAbw30ihWAIBAgICAP8CAQADDQBAAAAA AAAAAAAAAAADCQBAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQR/6RdMBgw EAIBAAIIf/////////8BAQACBBH/pF2iTjBMAgECAgIA/wIBAAMNAID///////// /////wMJAID/////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh///// /////wEB/zANBgkqhkiG9w0BAQUFAAOCAQEAFppKAotj6ayP7FrPuhTpwLFRyQU8 LlRkQ8/1mc9JHWifWHWXawTdY6J3wEKzCa0RzIRysq8E7Toti9Q0HkFUjFGbo16v 1Cua8KD7J77XpYPrNIEB0yn3hik8cz+r5RII2dRnN93veooNugiIVNdNH5lC5Y+J v6Mxz3oFb6iLVK788vzJBuVt1PDSxq1vcT373mR3nRFQg52VK0uVtEUjSuf21xdw 7IukJXB5hP8Xrz3f0ngu6NlUIzcGXGHT01csNL+w3uQDz41V4pN68QhAr402zSCP oB3/UYw0youSN54R5BRuEfUbbSa33h/X2M93TrO4RmnGv+PguqCVyS8R bA== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDkTCCAnmgAwIBAgIQQj8qmcmMg6VNCLdo8b7ZSjANBgkqhkiG9w0BAQ0FADBa MRowGAYKCZImiZPyLGQBGRYKbWFyc2hob3VzZTEXMBUGCgmSJomT8ixkARkWB3dp bjJrMTIxIzAhBgNVBAMTGndpbjJrMTItV0lOLVZPMUJCREpQTklULUNBMCAXDTE0 MTAzMTE0MjczOFoYDzIwNjQxMDMxMTQzNzM4WjBaMRowGAYKCZImiZPyLGQBGRYK bWFyc2hob3VzZTEXMBUGCgmSJomT8ixkARkWB3dpbjJrMTIxIzAhBgNVBAMTGndp bjJrMTItV0lOLVZPMUJCREpQTklULUNBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAuLFl1SAeVfvMLBqE4A+lc/e9FTOduLx2RWu/InOMnrQZQ3xG6J1d qhAf781SPaTZR5bDpROeVYL+Wxb1WvPxIiOkhXlHiTMEyPEfUD57pozVlcGYx1aJ yBUDKqRoEWBkDftAtM7h4PwotqvVo/ib0iWP5pKsK5o/94pAcuPkiCop423sTA/h FAv/QZAhu+a9FG2bih/a96BRe3nXEfaCCRwnymSXXrPY/GSV3kOR1X9haz87v322 YGcE0/7y9dIaH2AHz2zBeq1XrnWHucea867/NnBWUaD0vXdG23wWjPtF1fk7o95J EgeP+WehUquUoR0Uy91LseoQWe+GddHL2QIDAQABo1EwTzALBgNVHQ8EBAMCAYYw DwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUrOn/0VeHz/Z6UbAIz6NjTLSCAi4w EAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQENBQADggEBAG536uWeEc+hevyj qz8LcWtZjRiAXqEkkNRlSSXmzDmfWrMGVIaf8qR15b6iT3zCwiD3Xe0m7OuDbeYH StGgPpg8LPJ4AFEkO6YBwJVUZJ/F+JeUsFMlAdHp4KumI6IaYauhtCAUUXc+wMJR BI92lf9k4HmnEtarSP016ELt7z3feY6M7/tREshmvSQjpwCbv6CN6UH/3dkral3u gM4+v7AsJ3RKon1DBuPQffeY2gYm/oD8VvTN0//jd0YyAH43HKt0bv+X266XUs/y i2Dy7VRoPX08R9Sri0qpu22a1qhUx4a+Gf4d4c7YY5cFyKZcOVTEuEsXlUXvAx0X CxTv0Gw= -----END CERTIFICATE----- -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIDfzCCAmegAwIBAgIQXZs1QSHJgbpJzo6xfNL5MjANBgkqhkiG9w0BAQUFADBS MRUwEwYKCZImiZPyLGQBGRYFTE9DQUwxFzAVBgoJkiaJk/IsZAEZFgdKVU5TLUFE MSAwHgYDVQQDExdKVU5TLUFELUpVTlMtV0lOMjAxMi1DQTAeFw0xMzAxMTYxMTU3 MzVaFw0xODAxMTYxMjA3MzVaMFIxFTATBgoJkiaJk/IsZAEZFgVMT0NBTDEXMBUG CgmSJomT8ixkARkWB0pVTlMtQUQxIDAeBgNVBAMTF0pVTlMtQUQtSlVOUy1XSU4y MDEyLUNBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsbxYiKq2LGWV Mki8lNrjcboXiVL2pRM2GNTzoUANrPC11ylCuCG7cSqAqoEJjQ5AC62llrSR8z2F DmyslpO/vgnZu9hO81HOZFeCMcIgSuPim7dS+pbkEBvXb3oyKK8mmKFZmOh63taK hSMMzvCzIheado2qvo67se1A68x5lVWD5kUGefc8RAGhPrriYfa3cQIaYXe+KQDl 1uuKPOhJJr6VlGS8HUGCLkDwzgSbRmiYr2TmNoIl0bo3jvY3dIHKGicAxcuUTlAg psbg6pCKZiL6NKUl8BHXkvRvd/JNR81XsNNo2/54UMu0hbIGYh2D2zEFsBhIK6fU HwNg1tqs9QIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQUQorgEGd0Je1syR23SZCqgy8XsLAwEAYJKwYBBAGCNxUBBAMCAQAw DQYJKoZIhvcNAQEFBQADggEBAB7Hj+8lpsd98uMLtOGSYLePe/8cslLK6bYBScmB 3FRyBX9rrYrAclQWk8pfbnUfbXiQAhq5MXQEtx/wScJFEwQP0fXQ5it2f/9IaFya MqylPn7S2dKfTLiEdkJH1L9Ar4N9pY/EP3H6+5uZk9iMEvac9kyCgVEXlEQy1Djw 7OXn+rKdYbjFpQV4KScShRw9LUFp8SHhDi6WCdF/cAxAbhS5HSjXjHHp7l2ZuPhZ T6mELVdnF4rW9bwwJRsmbHuotrN2N5LwcybT1AX9E9lTnQrCTT7Y0c//ySCUYk+p Rol+UgE0ckRhoDfNNCP6rXNyKBZjYwdJF0+6SZqozHBXvyM= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDkTCCAnmgAwIBAgIQQj8qmcmMg6VNCLdo8b7ZSjANBgkqhkiG9w0BAQ0FADBa MRowGAYKCZImiZPyLGQBGRYKbWFyc2hob3VzZTEXMBUGCgmSJomT8ixkARkWB3dp bjJrMTIxIzAhBgNVBAMTGndpbjJrMTItV0lOLVZPMUJCREpQTklULUNBMCAXDTE0 MTAzMTE0MjczOFoYDzIwNjQxMDMxMTQzNzM4WjBaMRowGAYKCZImiZPyLGQBGRYK bWFyc2hob3VzZTEXMBUGCgmSJomT8ixkARkWB3dpbjJrMTIxIzAhBgNVBAMTGndp bjJrMTItV0lOLVZPMUJCREpQTklULUNBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAuLFl1SAeVfvMLBqE4A+lc/e9FTOduLx2RWu/InOMnrQZQ3xG6J1d qhAf781SPaTZR5bDpROeVYL+Wxb1WvPxIiOkhXlHiTMEyPEfUD57pozVlcGYx1aJ yBUDKqRoEWBkDftAtM7h4PwotqvVo/ib0iWP5pKsK5o/94pAcuPkiCop423sTA/h FAv/QZAhu+a9FG2bih/a96BRe3nXEfaCCRwnymSXXrPY/GSV3kOR1X9haz87v322 YGcE0/7y9dIaH2AHz2zBeq1XrnWHucea867/NnBWUaD0vXdG23wWjPtF1fk7o95J EgeP+WehUquUoR0Uy91LseoQWe+GddHL2QIDAQABo1EwTzALBgNVHQ8EBAMCAYYw DwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUrOn/0VeHz/Z6UbAIz6NjTLSCAi4w EAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQENBQADggEBAG536uWeEc+hevyj qz8LcWtZjRiAXqEkkNRlSSXmzDmfWrMGVIaf8qR15b6iT3zCwiD3Xe0m7OuDbeYH StGgPpg8LPJ4AFEkO6YBwJVUZJ/F+JeUsFMlAdHp4KumI6IaYauhtCAUUXc+wMJR BI92lf9k4HmnEtarSP016ELt7z3feY6M7/tREshmvSQjpwCbv6CN6UH/3dkral3u gM4+v7AsJ3RKon1DBuPQffeY2gYm/oD8VvTN0//jd0YyAH43HKt0bv+X266XUs/y i2Dy7VRoPX08R9Sri0qpu22a1qhUx4a+Gf4d4c7YY5cFyKZcOVTEuEsXlUXvAx0X CxTv0Gw= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFNzCCBB+gAwIBAgIkAhwR/6RdpYmtWdJi6rVCPPmhLs9Uf9hVmML28dKTAgIX n543MA0GCSqGSIb3DQEBBQUAMDQxGjAYBgNVBAsTEU9yZ2FuaXphdGlvbmFsIENB MRYwFAYDVQQKEw1VQlMtU1lOQy1UUkVFMB4XDTA5MDkxNTA5NTYxOFoXDTE5MDkx NTA5NTYxOFowNDEaMBgGA1UECxMRT3JnYW5pemF0aW9uYWwgQ0ExFjAUBgNVBAoT DVVCUy1TWU5DLVRSRUUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDb GtfEjhT1WXvTJBT9Jt/zftUiAbMUvxOOIww5W/TmtHZxEsruch+AAE1Xqh9d1eS6 2bkY9zuxTTAzXpI0xxiwg+Bk1ayYUBvDghUQFSw2iBXuuwx2kpcJ/1ZCJr+zm1bD TkQeBRvcRplYt1BdeVFjzkiBkJetMoe58QQmCf2+YDego+YAZkIOSTZzusXeJjAJ 4T2TdY8AHX9Y/Zu4KBhObSZetVMXwFDp1b/Y+wUnzGRw+3gni9KMOS376tNHDNxZ 1yTLtd9ZTocBjCpvKlwJaUwIvsQ+FpaGQvCkIItq4dp1GNmNIO6emhrXjSjY5WmR X4/ksfN7JeuqyoBzl1HBAgMBAAGjggIvMIICKzAdBgNVHQ4EFgQUltZ+VFHgDRx3 Z8RKixbRyE9xRL8wHwYDVR0jBBgwFoAUltZ+VFHgDRx3Z8RKixbRyE9xRL8wDAYD VR0TBAUwAwEB/zALBgNVHQ8EBAMCAQYwggHMBgtghkgBhvg3AQkEAQSCAbswggG3 BAIBAAEB/xMdTm92ZWxsIFNlY3VyaXR5IEF0dHJpYnV0ZSh0bSkWQ2h0dHA6Ly9k ZXZlbG9wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJpYnV0ZXMvY2VydGF0 dHJzX3YxMC5odG0wggFIoBoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaEaAQEA MAgwBgIBAQIBADAIMAYCAQECAQACAQCiBgIBGAEB/6OCAQSgWAIBAgICAP8CAQAD DQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQG 8N9IMBgwEAIBAAIIf/////////8BAQACBAbw30ihWAIBAgICAP8CAQADDQBAAAAA AAAAAAAAAAADCQBAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQR/6RdMBgw EAIBAAIIf/////////8BAQACBBH/pF2iTjBMAgECAgIA/wIBAAMNAID///////// /////wMJAID/////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh///// /////wEB/zANBgkqhkiG9w0BAQUFAAOCAQEAFppKAotj6ayP7FrPuhTpwLFRyQU8 LlRkQ8/1mc9JHWifWHWXawTdY6J3wEKzCa0RzIRysq8E7Toti9Q0HkFUjFGbo16v 1Cua8KD7J77XpYPrNIEB0yn3hik8cz+r5RII2dRnN93veooNugiIVNdNH5lC5Y+J v6Mxz3oFb6iLVK788vzJBuVt1PDSxq1vcT373mR3nRFQg52VK0uVtEUjSuf21xdw 7IukJXB5hP8Xrz3f0ngu6NlUIzcGXGHT01csNL+w3uQDz41V4pN68QhAr402zSCP oB3/UYw0youSN54R5BRuEfUbbSa33h/X2M93TrO4RmnGv+PguqCVyS8R bA== -----END CERTIFICATE----- -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIDfzCCAmegAwIBAgIQXZs1QSHJgbpJzo6xfNL5MjANBgkqhkiG9w0BAQUFADBS MRUwEwYKCZImiZPyLGQBGRYFTE9DQUwxFzAVBgoJkiaJk/IsZAEZFgdKVU5TLUFE MSAwHgYDVQQDExdKVU5TLUFELUpVTlMtV0lOMjAxMi1DQTAeFw0xMzAxMTYxMTU3 MzVaFw0xODAxMTYxMjA3MzVaMFIxFTATBgoJkiaJk/IsZAEZFgVMT0NBTDEXMBUG CgmSJomT8ixkARkWB0pVTlMtQUQxIDAeBgNVBAMTF0pVTlMtQUQtSlVOUy1XSU4y MDEyLUNBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsbxYiKq2LGWV Mki8lNrjcboXiVL2pRM2GNTzoUANrPC11ylCuCG7cSqAqoEJjQ5AC62llrSR8z2F DmyslpO/vgnZu9hO81HOZFeCMcIgSuPim7dS+pbkEBvXb3oyKK8mmKFZmOh63taK hSMMzvCzIheado2qvo67se1A68x5lVWD5kUGefc8RAGhPrriYfa3cQIaYXe+KQDl 1uuKPOhJJr6VlGS8HUGCLkDwzgSbRmiYr2TmNoIl0bo3jvY3dIHKGicAxcuUTlAg psbg6pCKZiL6NKUl8BHXkvRvd/JNR81XsNNo2/54UMu0hbIGYh2D2zEFsBhIK6fU HwNg1tqs9QIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQUQorgEGd0Je1syR23SZCqgy8XsLAwEAYJKwYBBAGCNxUBBAMCAQAw DQYJKoZIhvcNAQEFBQADggEBAB7Hj+8lpsd98uMLtOGSYLePe/8cslLK6bYBScmB 3FRyBX9rrYrAclQWk8pfbnUfbXiQAhq5MXQEtx/wScJFEwQP0fXQ5it2f/9IaFya MqylPn7S2dKfTLiEdkJH1L9Ar4N9pY/EP3H6+5uZk9iMEvac9kyCgVEXlEQy1Djw 7OXn+rKdYbjFpQV4KScShRw9LUFp8SHhDi6WCdF/cAxAbhS5HSjXjHHp7l2ZuPhZ T6mELVdnF4rW9bwwJRsmbHuotrN2N5LwcybT1AX9E9lTnQrCTT7Y0c//ySCUYk+p Rol+UgE0ckRhoDfNNCP6rXNyKBZjYwdJF0+6SZqozHBXvyM= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDkTCCAnmgAwIBAgIQQj8qmcmMg6VNCLdo8b7ZSjANBgkqhkiG9w0BAQ0FADBa MRowGAYKCZImiZPyLGQBGRYKbWFyc2hob3VzZTEXMBUGCgmSJomT8ixkARkWB3dp bjJrMTIxIzAhBgNVBAMTGndpbjJrMTItV0lOLVZPMUJCREpQTklULUNBMCAXDTE0 MTAzMTE0MjczOFoYDzIwNjQxMDMxMTQzNzM4WjBaMRowGAYKCZImiZPyLGQBGRYK bWFyc2hob3VzZTEXMBUGCgmSJomT8ixkARkWB3dpbjJrMTIxIzAhBgNVBAMTGndp bjJrMTItV0lOLVZPMUJCREpQTklULUNBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAuLFl1SAeVfvMLBqE4A+lc/e9FTOduLx2RWu/InOMnrQZQ3xG6J1d qhAf781SPaTZR5bDpROeVYL+Wxb1WvPxIiOkhXlHiTMEyPEfUD57pozVlcGYx1aJ yBUDKqRoEWBkDftAtM7h4PwotqvVo/ib0iWP5pKsK5o/94pAcuPkiCop423sTA/h FAv/QZAhu+a9FG2bih/a96BRe3nXEfaCCRwnymSXXrPY/GSV3kOR1X9haz87v322 YGcE0/7y9dIaH2AHz2zBeq1XrnWHucea867/NnBWUaD0vXdG23wWjPtF1fk7o95J EgeP+WehUquUoR0Uy91LseoQWe+GddHL2QIDAQABo1EwTzALBgNVHQ8EBAMCAYYw DwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUrOn/0VeHz/Z6UbAIz6NjTLSCAi4w EAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQENBQADggEBAG536uWeEc+hevyj qz8LcWtZjRiAXqEkkNRlSSXmzDmfWrMGVIaf8qR15b6iT3zCwiD3Xe0m7OuDbeYH StGgPpg8LPJ4AFEkO6YBwJVUZJ/F+JeUsFMlAdHp4KumI6IaYauhtCAUUXc+wMJR BI92lf9k4HmnEtarSP016ELt7z3feY6M7/tREshmvSQjpwCbv6CN6UH/3dkral3u gM4+v7AsJ3RKon1DBuPQffeY2gYm/oD8VvTN0//jd0YyAH43HKt0bv+X266XUs/y i2Dy7VRoPX08R9Sri0qpu22a1qhUx4a+Gf4d4c7YY5cFyKZcOVTEuEsXlUXvAx0X CxTv0Gw= -----END CERTIFICATE----- From rsalz at akamai.com Tue Sep 6 20:25:00 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Sep 2016 20:25:00 +0000 Subject: [openssl-users] [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: <20160906.213417.1719569548619936717.levitte@openssl.org> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.193933.2272151712340631325.levitte@openssl.org> <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.213417.1719569548619936717.levitte@openssl.org> Message-ID: <0e12673775fc460f9927690c8a1ece22@usma1ex-dag1mb1.msg.corp.akamai.com> > Sorry, I was unclear. What I meant was that it's not a huge step from the XSD > to full blown ISO 8601. No, sorry, *I* was unclear. I think it is a huge step to go full-blown. E.g., all the missing fields and the 'w' duration. From jb-openssl at wisemo.com Tue Sep 6 20:52:32 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 6 Sep 2016 22:52:32 +0200 Subject: [openssl-users] A self-signed CA certificate in the CA files *sometimes* stops verification working In-Reply-To: References: Message-ID: <2f9a8291-2c04-749f-7162-36c4a0558d89@wisemo.com> Could this be related to the recent work to treat the list of certificates as a SET of potentially relevant certificates rather than as an ordered list of certificates that must form the trust chain? Reading through the 1.1.0 changelog makes it unclear how much of this standards-compliance fix has been implemented so far, and how much of it is included in 1.0.2h. On 06/09/2016 20:10, John Unsworth wrote: > This seems to me to be very easy to validate by just inserting a self-signed certificate at the front of a CAfile that works. > > ... > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni > Sent: 06 September 2016 18:47 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] A self-signed CA certificate in the CA file *sometimes* stops verification working > > >> On Sep 6, 2016, at 11:53 AM, John Unsworth wrote: >> >> I have noticed the following behaviour: >> >> 1 Create a certificate file with two CA certificates, one for the server being connected to (server A) and one for another server (server B). >> 2 Whichever way the CA certificates are ordered the connect works OK. >> 3 Add a self-signed CA certificate in the file before the one for server A. The connect fails ?Verify return code: 21 (unable to verify the first certificate)?. >> 4 Move the self-signed CA certificate after the one for server A. The connect works OK. >> >> Why should the self-signed certificate affect the connection when the required CA certificate is in the certificate file? Is this a bug? > You've provided much too little detail for a meaningful answer. > > Post the server chain being validated as reported by > > $ openssl s_client -showcerts -connect :443 > chain.pem > $ openssl crl2pkcs7 -nocrl -certfile chain.pem | > openssl pkcs7 -print_certs > > and all three CA certificates. Do not post any of the private keys. > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Tue Sep 6 20:55:02 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 6 Sep 2016 20:55:02 +0000 Subject: [openssl-users] A self-signed CA certificate in the CA files *sometimes* stops verification working In-Reply-To: <2f9a8291-2c04-749f-7162-36c4a0558d89@wisemo.com> References: <2f9a8291-2c04-749f-7162-36c4a0558d89@wisemo.com> Message-ID: <20160906205502.GR4670@mournblade.imrryr.org> On Tue, Sep 06, 2016 at 10:52:32PM +0200, Jakob Bohm wrote: > Could this be related to the recent work to treat the list of > certificates as a SET of potentially relevant certificates > rather than as an ordered list of certificates that must form > the trust chain? No, just a violation of the PEM format. PEM files are text files so NUL bytes are not supported. It so happens that leading NUL bytes don't work well as C strings, and the PEM reader assumes that a zero length input line is effectively EOF. -- Viktor. From John.Unsworth at synchronoss.com Tue Sep 6 22:20:15 2016 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Tue, 6 Sep 2016 22:20:15 +0000 Subject: [openssl-users] A self-signed CA certificate in the CA files *sometimes* stops verification working In-Reply-To: <20160906201358.GO4670@mournblade.imrryr.org> References: <20160906201358.GO4670@mournblade.imrryr.org> Message-ID: Thank you Victor for that valuable analysis. The original self-signed CA file has a NUL at the end which has been propagated when we created the concatenated CA file. We'll have to see how that cert was created and also correct our concatenation routine to cater for trailing NULs. That will teach me not to make assumptions! Regards, John. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: 06 September 2016 21:14 To: openssl-users at openssl.org Subject: Re: [openssl-users] A self-signed CA certificate in the CA files *sometimes* stops verification working On Tue, Sep 06, 2016 at 06:10:42PM +0000, John Unsworth wrote: > This seems to me to be very easy to validate by just inserting a self-signed certificate at the front of a CAfile that works. > > Attached are the 3 certificate files. > > _CAcerts.good is the first file with two certs the second of which is the CA cert for the server. > _CAcerts.bad has the self-signed cert inserted between the two original CA certs. > _CAcerts.bad.fixed has the self-signed cert last, after the valid CAcert for the server. The CAcerts.bad file contains a NUL byte at the start of the (should be) blank line separating two of the certificates. This prevents OpenSSL from reading the rest of the file. Cleaned-up CAfiles attached, the server cert verifies with all three. $ for file in _CAcerts.*; do echo $file; openssl verify -CAfile $file chain.pem; done _CAcerts.bad chain.pem: OK _CAcerts.bad.fixed chain.pem: OK _CAcerts.good chain.pem: OK -- Viktor. From matt at openssl.org Tue Sep 6 22:47:01 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Sep 2016 23:47:01 +0100 Subject: [openssl-users] Async engine and BIOs In-Reply-To: <57CEEA77.10009@kalray.eu> References: <57CEEA77.10009@kalray.eu> Message-ID: On 06/09/16 17:10, Nicolas Brunie wrote: > Hi Everyone, > I am trying to mix an application with a buffer BIO over a SSL BIO > which uses an asynchronous engine for offloading. > > I had a quick look at the SSL BIO (ssl/bio_ssl.c) and it does not > seem to care about the error SSL_ERROR_WANT_ASYNC coming from a > SSL_write or a SSL_read. Does this means that this error is silently > ignored ? > Does it means the BIO chains will retry automatically to call the > SSL_write ou SSL_read with the same arguments to make it finish ? Does > it mean my call to BIO_write/BIO_read will return directly when the > engine call ASYNC_pause_job without fnishing the job and I have to call > BIO_write / BIO_read until the sum or return value equals the amount of > data I was expected it to proceed ? The SSL BIO does not directly support async. You should not set an SSL object wrapped in an SSL BIO into async mode because the SSL BIO will not handle the SSL_ERROR_WANT_ASYNC response correctly. If you want to handle async events you have two options: 1) Call SSL_read()/SSL_write() directly (after setting the SSL object into ASYNC mode) and handle SSL_ERROR_WANT_ASYNC without using an SSL BIO 2) Use the ASYNC_start_job() interface directly. In the latter case you should not set the SSL object into async mode at all - because your code will be interfacing directly with the async API. If you really have to do it via BIOs you could implement your own async BIO filter that uses ASYNC_start_job() and translates ASYNC_PAUSE events into standard non-blocking IO events. Matt From dongsheng.song at gmail.com Wed Sep 7 02:13:39 2016 From: dongsheng.song at gmail.com (Dongsheng Song) Date: Wed, 7 Sep 2016 10:13:39 +0800 Subject: [openssl-users] [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.193933.2272151712340631325.levitte@openssl.org> <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On Wed, Sep 7, 2016 at 3:14 AM, Salz, Rich wrote: > > > It's not a huge step to support full blown ISO 8601 (which has a few more > > alternatives to specify time intervals *). I like the idea. > > No, it *is* a huge step. There's a reason why W3C XML schema language > (XSD), not known for being lightweight, profiled the ISO standard. > > Support RFC3339[1] is relative easy. [1] https://tools.ietf.org/html/rfc3339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Sep 7 11:11:38 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 7 Sep 2016 11:11:38 +0000 Subject: [openssl-users] [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.193933.2272151712340631325.levitte@openssl.org> <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <8f654ee535f74dc1a297ddd4d9f24483@usma1ex-dag1mb1.msg.corp.akamai.com> > Support RFC3339[1] is relative?easy. But it's not enough, as folks are asking for the ability to specify durations. From daniel at phusion.nl Wed Sep 7 12:51:58 2016 From: daniel at phusion.nl (Daniel Knoppel) Date: Wed, 7 Sep 2016 14:51:58 +0200 Subject: [openssl-users] Using RSA_PKCS1_OAEP_PADDING with high level EVP_Seal functions Message-ID: <57D00D6E.1040601@phusion.nl> Dear all, I was wondering about two things: 1. Can the EVP_Seal*() functions be told to use RSA_PKCS1_OAEP_PADDING, or do I need to stick with the lower level RSA_public_encrypt()? >From the source code it seems to me that RSA_PKCS1_PADDING is hardcoded because EVP_SealInit() [1] calls EVP_PKEY_encrypt_old() [2], which in turn has the line with hardcoded padding: ret = RSA_public_encrypt(key_len, key, ek, EVP_PKEY_get0_RSA(pubk), RSA_PKCS1_PADDING); 2. Isn't the default RSA_PKCS1_PADDING used by EVP_Seal*() vulnerable to padding oracle attacks? I mean, it's certainly possible to not to say anything about the padding result in error messages to the client but wouldn't there still be a potential information leak through response timing? How should EVP_Seal*() be used safely? Just as background info: the use case is a client encrypting a sensitive file based on a public key (using RSA-4096 + block cipher like AES-256-CBC) which is then transmitted to a webbased backend, with a final response back to the client. Nothing very special, although a high number of different clients is expected (i.e. high volume at the backend). Best regards, Daniel [1] https://github.com/openssl/openssl/blob/OpenSSL_1_1_0-stable/crypto/evp/p_seal.c [2] https://github.com/openssl/openssl/blob/OpenSSL_1_1_0-stable/crypto/evp/p_enc.c From aleksandr.v.konstantinov at gmail.com Thu Sep 8 06:50:43 2016 From: aleksandr.v.konstantinov at gmail.com (Aleksandr Konstantinov) Date: Thu, 8 Sep 2016 09:50:43 +0300 Subject: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0 Message-ID: Hello all, I'm in process of porting our project to OpenSSL 1.1.0. We have part of code which heavily uses M_ASN1_D2I_* and M_ASN1_I2D_* for defining d2i_* and i2d_* methods for new extension. For example code uses M_ASN1_D2I_vars, M_ASN1_D2I_Init and M_ASN1_D2I_start_sequence to start reading sequence of items and then proceeds with M_ASN1_D2I_get_* for content of the sequence. Could please anybody advise what would be proper replacement for those macros in OpenSSL 1.1.0? Is there any new API for such things? Or shall one do raw byte banging? Best regards, A.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opalopalop at gmail.com Thu Sep 8 10:52:28 2016 From: opalopalop at gmail.com (opal op) Date: Thu, 8 Sep 2016 12:52:28 +0200 Subject: [openssl-users] Loading certificates Message-ID: Hi everyone, i am working on my implementation of the engine that should be able to load certificates. I was wondering is there any method that should perform such a operation (like ENGINE_load_certificates if this method would exist). Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From yordanosb at gmail.com Thu Sep 8 19:12:08 2016 From: yordanosb at gmail.com (yordanos beyene) Date: Thu, 8 Sep 2016 12:12:08 -0700 Subject: [openssl-users] how to set temporary EC Diffie-Hellman parameters Message-ID: Hello, I appreciate if anyone can guide me how to set temporary EC Diffie-Hellman parameters to be able to accept SSL connections from a client using ephemeral ECDHE cipher. I have an ssl based application that can accept SSL connections. I can establish SSL connections from a client using RSA cipher ( eg AES128-SHA), but when I use the ephemeral EDHE ciphers (eg ECDHE-RSA-AES128-SHA), the SSL handshake fails. I have been googling to understand the issue for several hours, and it looks like I need to set temporary DH parameters. I added the following code right after SSL initialization and creating context in my application. ... EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); if (! ecdh) error (); if (1 != SSL_CTX_set_tmp_ecdh (session_cache_ctx, ecdh)) return -ENOMEM; EC_KEY_free (ecdh); ... But it is still not working. I am not familiar with this area, and I greatly appreciate any help. I am running OpenSSL 1.0.1 Jordan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Thu Sep 8 19:18:50 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 8 Sep 2016 19:18:50 +0000 Subject: [openssl-users] Using RSA_PKCS1_OAEP_PADDING with high level EVP_Seal functions In-Reply-To: <57D00D6E.1040601@phusion.nl> References: <57D00D6E.1040601@phusion.nl> Message-ID: <20160908191850.GA7289@openssl.org> On Wed, Sep 07, 2016, Daniel Knoppel wrote: > Dear all, > > I was wondering about two things: > > 1. Can the EVP_Seal*() functions be told to use RSA_PKCS1_OAEP_PADDING, > or do I need to stick with the lower level RSA_public_encrypt()? > > >From the source code it seems to me that RSA_PKCS1_PADDING is hardcoded > because EVP_SealInit() [1] calls EVP_PKEY_encrypt_old() [2], which in > turn has the line with hardcoded padding: > > ret = RSA_public_encrypt(key_len, key, ek, EVP_PKEY_get0_RSA(pubk), > RSA_PKCS1_PADDING); > EVP_Seal*() is an old function hard coded to use RSA_PKCS1_PADDING as you've observed. You don't need to use the low level RSA_public_encrypt() function for OAEP. Instead use the EVP_PKEY APIs EVP_PKEY_encrypt() and EVP_PKEY_decrypt() with the padding mode modified and appropriate parameters set. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Thu Sep 8 19:23:56 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 8 Sep 2016 19:23:56 +0000 Subject: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0 In-Reply-To: References: Message-ID: <20160908192356.GB7289@openssl.org> On Thu, Sep 08, 2016, Aleksandr Konstantinov wrote: > Hello all, > > I'm in process of porting our project to OpenSSL 1.1.0. We have part of > code which heavily uses M_ASN1_D2I_* and M_ASN1_I2D_* for defining d2i_* > and i2d_* methods for new extension. For example code uses M_ASN1_D2I_vars, > M_ASN1_D2I_Init and M_ASN1_D2I_start_sequence to start reading sequence of > items and then proceeds with M_ASN1_D2I_get_* for content of the > sequence. Could please anybody advise what would be proper replacement for > those macros in OpenSSL 1.1.0? Is there any new API for such things? Or > shall one do raw byte banging? > Those old macros were updated way back in OpenSSL 0.9.7 and finally retired in OpenSSL 1.1.0. You need to write an appropriate ASN.1 module to encode and decode your structure. There are many examples of this such as in crypto/cms/cms_asn1.c and some much simpler ones in crypto/x509v3 which are perhaps better suited to you needs. They use macros which start with ASN1_SEQUENCE* Is it possible to look at your old code? Then I could give some more specific pointers. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From felipe at felipegasper.com Fri Sep 9 01:02:51 2016 From: felipe at felipegasper.com (Felipe Gasper) Date: Thu, 8 Sep 2016 20:02:51 -0500 Subject: [openssl-users] X509_verify_cert() and X509_STORE_set_verify_cb() Message-ID: Hello, After I set a callback with X509_STORE_set_verify_cb(callback_fn), then run: X509_verify_cert( store_ctx, store, x509, untrusted ) Is it always true that store_ctx?s error state after X509_verify_cert() will be identical to the final call into callback_fn()? Thank you! -Felipe Gasper Houston, TX From aleksandr.v.konstantinov at gmail.com Fri Sep 9 06:41:44 2016 From: aleksandr.v.konstantinov at gmail.com (Aleksandr Konstantinov) Date: Fri, 9 Sep 2016 09:41:44 +0300 Subject: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0 In-Reply-To: <20160908192356.GB7289@openssl.org> References: <20160908192356.GB7289@openssl.org> Message-ID: Hello, Thanks for your answer. Here is one of d2i functions simplified: MYEXT * d2i_MYEXT(MYEXT ** myext, unsigned char ** pp, long length) { M_ASN1_D2I_vars(myext, MYEXT *, MYEXT_new); M_ASN1_D2I_Init(); M_ASN1_D2I_start_sequence(); M_ASN1_D2I_get_EXP_opt(ret->intmember, d2i_ASN1_INTEGER, 1); M_ASN1_D2I_get_opt(ret->intmember, d2i_ASN1_INTEGER, V_ASN1_INTEGER); M_ASN1_D2I_Finish(myext, MYEXT_free, ASN1_F_D2I_MYEXT); } Regards, A.K. On Thu, Sep 8, 2016 at 10:23 PM, Dr. Stephen Henson wrote: > On Thu, Sep 08, 2016, Aleksandr Konstantinov wrote: > > > Hello all, > > > > I'm in process of porting our project to OpenSSL 1.1.0. We have part of > > code which heavily uses M_ASN1_D2I_* and M_ASN1_I2D_* for defining d2i_* > > and i2d_* methods for new extension. For example code uses > M_ASN1_D2I_vars, > > M_ASN1_D2I_Init and M_ASN1_D2I_start_sequence to start reading sequence > of > > items and then proceeds with M_ASN1_D2I_get_* for content of the > > sequence. Could please anybody advise what would be proper replacement > for > > those macros in OpenSSL 1.1.0? Is there any new API for such things? Or > > shall one do raw byte banging? > > > > Those old macros were updated way back in OpenSSL 0.9.7 and finally > retired in > OpenSSL 1.1.0. > > You need to write an appropriate ASN.1 module to encode and decode your > structure. There are many examples of this such as in crypto/cms/cms_asn1.c > and some much simpler ones in crypto/x509v3 which are perhaps better > suited to > you needs. > > They use macros which start with ASN1_SEQUENCE* > > Is it possible to look at your old code? Then I could give some more > specific > pointers. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maverick.rishi at gmail.com Fri Sep 9 10:11:37 2016 From: maverick.rishi at gmail.com (Rishi Pathak) Date: Fri, 9 Sep 2016 15:41:37 +0530 Subject: [openssl-users] Custom lastUpdate in CRL Message-ID: Hi, For a reason we require lastUpdate to be set to a date in the previous year, with nextUpdate a year from now in our CRL. Search on google led me to a patch which allows use of startDate/endDate for CRL generation as well apart from certificates. Seems like 1.0-1 does not have it. Any pointers to how I can achieve this using OpenSSL(version) or another utility, preferably on Linux. -- -------------This message is sent with 100% recycled electrons----------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at phusion.nl Fri Sep 9 10:55:21 2016 From: daniel at phusion.nl (Daniel Knoppel) Date: Fri, 9 Sep 2016 12:55:21 +0200 Subject: [openssl-users] Using RSA_PKCS1_OAEP_PADDING with high level EVP_Seal functions In-Reply-To: <20160908191850.GA7289@openssl.org> References: <57D00D6E.1040601@phusion.nl> <20160908191850.GA7289@openssl.org> Message-ID: <57D29519.9050005@phusion.nl> Thanks for the reply! Unfortunately I'm not sure I understand what you're saying. If EVP_Seal* is an old function, is there a new function with which we can accomplish the same functionality? What I mean is that the EVP_PKEY_encrypt() looks functionally the same as RSA_public_encrypt() (just encrypting using a public key), so it doesn't help with encrypting bulk data like the EVP_Seal*() functions. For instance, with EVP_PKEY_encrypt users still have to deal with symmetric key and iv generation, something that EVP_Seal*() does for you (i.e. so you can't get it wrong). The official documentation[1] even hints that you should be using EVP_Seal*(): "For encryption and decryption see EVP_PKEY_encrypt and EVP_PKEY_decrypt respectively. However, note that these functions perform encryption and decryption only. As public key encryption is an expensive operation, normally you would wrap an encrypted message in a "digital envelope" using the EVP_SealInit and EVP_OpenInit functions." Best regards, Daniel [1] https://www.openssl.org/docs/manmaster/crypto/evp.html On 8-9-2016 21:18, Dr. Stephen Henson wrote: > On Wed, Sep 07, 2016, Daniel Knoppel wrote: > >> Dear all, >> >> I was wondering about two things: >> >> 1. Can the EVP_Seal*() functions be told to use RSA_PKCS1_OAEP_PADDING, >> or do I need to stick with the lower level RSA_public_encrypt()? >> >> >From the source code it seems to me that RSA_PKCS1_PADDING is hardcoded >> because EVP_SealInit() [1] calls EVP_PKEY_encrypt_old() [2], which in >> turn has the line with hardcoded padding: >> >> ret = RSA_public_encrypt(key_len, key, ek, EVP_PKEY_get0_RSA(pubk), >> RSA_PKCS1_PADDING); >> > > EVP_Seal*() is an old function hard coded to use RSA_PKCS1_PADDING as you've > observed. > > You don't need to use the low level RSA_public_encrypt() function for > OAEP. Instead use the EVP_PKEY APIs EVP_PKEY_encrypt() and EVP_PKEY_decrypt() > with the padding mode modified and appropriate parameters set. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > From jb-openssl at wisemo.com Fri Sep 9 11:30:22 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 9 Sep 2016 13:30:22 +0200 Subject: [openssl-users] Custom lastUpdate in CRL In-Reply-To: References: Message-ID: <0595b325-9249-b866-7ebf-8e44d729c42d@wisemo.com> On 09/09/2016 12:11, Rishi Pathak wrote: > Hi, > For a reason we require lastUpdate to be set to a date in the > previous year, with > nextUpdate a year from now in our CRL. Search on google led me to a > patch which > allows use of startDate/endDate for CRL generation as well apart from > certificates. > Seems like 1.0-1 does not have it. Any pointers to how I can achieve > this using > OpenSSL(version) or another utility, preferably on Linux. > For such tasks, I currently use the faketime utility program to run the openssl command line tool in a context with the data artificially set to the desired time in the past. I have previously suggested that an "as of" time argument be added to certificate and signature validation operations, and your use case suggests the same for issuance and signing operations as well. In fact, it seems the general solution (in future OpenSSL updates) would be for all operations that use the "current time/date" to accept an alternative value of that as an argument. 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 steve at openssl.org Fri Sep 9 11:44:46 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 9 Sep 2016 11:44:46 +0000 Subject: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0 In-Reply-To: References: <20160908192356.GB7289@openssl.org> Message-ID: <20160909114446.GA20743@openssl.org> On Fri, Sep 09, 2016, Aleksandr Konstantinov wrote: > Hello, > > Thanks for your answer. Here is one of d2i functions simplified: > > MYEXT * d2i_MYEXT(MYEXT ** myext, unsigned char ** pp, long length) { > M_ASN1_D2I_vars(myext, MYEXT *, MYEXT_new); > M_ASN1_D2I_Init(); > M_ASN1_D2I_start_sequence(); > M_ASN1_D2I_get_EXP_opt(ret->intmember, d2i_ASN1_INTEGER, 1); > M_ASN1_D2I_get_opt(ret->intmember, d2i_ASN1_INTEGER, V_ASN1_INTEGER); > M_ASN1_D2I_Finish(myext, MYEXT_free, ASN1_F_D2I_MYEXT); > } > > Presumably the two fields aren't the same? I'll call one intmember2 for this example. The above would translate to something like: ASN1_SEQUENCE(MYEXT) = { ASN1_EXP_OPT(MYEXT, intmember, ASN1_INTEGER, 1), ASN1_OPT(MYEXT, intmember2, ASN1_INTEGER) } ASN1_SEQUENCE_END(MYEXT) IMPLEMENT_ASN1_FUNCTIONS(MYEXT) Then you include: DECLARE_ASN1_FUNCTIONS(MYEXT) in a header file. That generates four functions MYEXT_new(), MYEXT_free(), d2i_MYEXT() and i2d_MYEXT(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From andreas.pfluegl at etm.at Fri Sep 9 12:26:20 2016 From: andreas.pfluegl at etm.at (Pfluegl, Andreas) Date: Fri, 9 Sep 2016 12:26:20 +0000 Subject: [openssl-users] OpenSSL Release Strategy and Blog Message-ID: We started using OpenSSL in 2010 for Windows and Linux. We gladly followed the release strategy suggestion, as it allowed us to deliver patches without recompiling our code. So we still compile and link our code against 1.0.0 while delivering the current 1.0.2x versions (which by the way works great). At Windows we started with VC10 and soon migrated to VC12, but currently we are struggling with porting to VC14. So we are considering to update the openSSL version we compile and link against to 1.0.2. I don't expect 1.0.2 to be binary compatible to 1.0.1 or 1.0.3 as 1.0.0 is, but I expect it to be binary compatible with all 1.0.2x versions. Since I found no official statement which confirms this, I'd ask you to confirm this theory of mine. Regards, Andreas Pfl?gl -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Fri Sep 9 12:32:06 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 9 Sep 2016 08:32:06 -0400 Subject: [openssl-users] OpenSSL Release Strategy and Blog In-Reply-To: References: Message-ID: On Fri, Sep 9, 2016 at 8:26 AM, Pfluegl, Andreas wrote: > We started using OpenSSL in 2010 for Windows and Linux. We gladly followed > the release strategy suggestion, as it allowed us to deliver patches without > recompiling our code. So we still compile and link our code against 1.0.0 > while delivering the current 1.0.2x versions (which by the way works great). > > At Windows we started with VC10 and soon migrated to VC12, but currently we > are struggling with porting to VC14. So we are considering to update the > openSSL version we compile and link against to 1.0.2. I don't expect 1.0.2 > to be binary compatible to 1.0.1 or 1.0.3 as 1.0.0 is, but I expect it to be > binary compatible with all 1.0.2x versions. Since I found no official > statement which confirms this, I'd ask you to confirm this theory of mine. https://www.openssl.org/docs/faq.html#MISC8 : 8. How does the versioning scheme work? After the release of OpenSSL 1.0.0 the versioning scheme changed. Letter releases (e.g. 1.0.1a) can only contain bug and security fixes and no new features. Minor releases change the last number (e.g. 1.0.2) and can contain new features that retain binary compatibility. Changes to the middle number are considered major releases and neither source nor binary compatibility is guaranteed. Jeff From maverick.rishi at gmail.com Fri Sep 9 14:37:46 2016 From: maverick.rishi at gmail.com (Rishi Pathak) Date: Fri, 9 Sep 2016 20:07:46 +0530 Subject: [openssl-users] Custom lastUpdate in CRL In-Reply-To: <0595b325-9249-b866-7ebf-8e44d729c42d@wisemo.com> References: <0595b325-9249-b866-7ebf-8e44d729c42d@wisemo.com> Message-ID: Hi Jakob, Thanks. It solved my problem for now. I agree with your suggestion. In our scenario this would be a regular thing for coming years and will not be seen as standard way for operations. -- Rishi Pathak On Fri, Sep 9, 2016 at 5:00 PM, Jakob Bohm wrote: > On 09/09/2016 12:11, Rishi Pathak wrote: > >> Hi, >> For a reason we require lastUpdate to be set to a date in the >> previous year, with >> nextUpdate a year from now in our CRL. Search on google led me to a patch >> which >> allows use of startDate/endDate for CRL generation as well apart from >> certificates. >> Seems like 1.0-1 does not have it. Any pointers to how I can achieve this >> using >> OpenSSL(version) or another utility, preferably on Linux. >> >> For such tasks, I currently use the faketime utility program > to run the openssl command line tool in a context with the > data artificially set to the desired time in the past. > > I have previously suggested that an "as of" time argument > be added to certificate and signature validation operations, > and your use case suggests the same for issuance and signing > operations as well. > > In fact, it seems the general solution (in future OpenSSL > updates) would be for all operations that use the "current > time/date" to accept an alternative value of that as an > argument. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- -------------This message is sent with 100% recycled electrons----------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Fri Sep 9 14:43:29 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Fri, 9 Sep 2016 07:43:29 -0700 Subject: [openssl-users] Using RSA_PKCS1_OAEP_PADDING with high level EVP_Seal functions In-Reply-To: <57D29519.9050005@phusion.nl> References: <57D00D6E.1040601@phusion.nl> <20160908191850.GA7289@openssl.org> <57D29519.9050005@phusion.nl> Message-ID: <38768a5c-87a7-5ceb-6ab2-74cc43483844@gemtalksystems.com> +1 I agree with Daniel's sentiment and respectfully suggest EPV_Seal* and EVP_Open be updated and kept up to date. We all know how easy it is to get crypto wrong. Having "one stop shop" functions like these are invaluable for when it comes to getting crypto right. Norm Green On 9/9/2016 3:55 AM, Daniel Knoppel wrote: > Thanks for the reply! Unfortunately I'm not sure I understand what > you're saying. > > If EVP_Seal* is an old function, is there a new function with which we > can accomplish the same functionality? > > What I mean is that the EVP_PKEY_encrypt() looks functionally the same > as RSA_public_encrypt() (just encrypting using a public key), so it > doesn't help with encrypting bulk data like the EVP_Seal*() functions. > > For instance, with EVP_PKEY_encrypt users still have to deal with > symmetric key and iv generation, something that EVP_Seal*() does for you > (i.e. so you can't get it wrong). > > The official documentation[1] even hints that you should be using > EVP_Seal*(): > "For encryption and decryption see EVP_PKEY_encrypt and EVP_PKEY_decrypt > respectively. However, note that these functions perform encryption and > decryption only. As public key encryption is an expensive operation, > normally you would wrap an encrypted message in a "digital envelope" > using the EVP_SealInit and EVP_OpenInit functions." > > Best regards, > > Daniel > [1] https://www.openssl.org/docs/manmaster/crypto/evp.html > > On 8-9-2016 21:18, Dr. Stephen Henson wrote: >> On Wed, Sep 07, 2016, Daniel Knoppel wrote: >> >>> Dear all, >>> >>> I was wondering about two things: >>> >>> 1. Can the EVP_Seal*() functions be told to use RSA_PKCS1_OAEP_PADDING, >>> or do I need to stick with the lower level RSA_public_encrypt()? >>> >>> >From the source code it seems to me that RSA_PKCS1_PADDING is hardcoded >>> because EVP_SealInit() [1] calls EVP_PKEY_encrypt_old() [2], which in >>> turn has the line with hardcoded padding: >>> >>> ret = RSA_public_encrypt(key_len, key, ek, EVP_PKEY_get0_RSA(pubk), >>> RSA_PKCS1_PADDING); >>> >> EVP_Seal*() is an old function hard coded to use RSA_PKCS1_PADDING as you've >> observed. >> >> You don't need to use the low level RSA_public_encrypt() function for >> OAEP. Instead use the EVP_PKEY APIs EVP_PKEY_encrypt() and EVP_PKEY_decrypt() >> with the padding mode modified and appropriate parameters set. >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> From yordanosb at gmail.com Fri Sep 9 15:58:56 2016 From: yordanosb at gmail.com (yordanos beyene) Date: Fri, 9 Sep 2016 08:58:56 -0700 Subject: [openssl-users] how to set temporary EC Diffie-Hellman parameters In-Reply-To: References: Message-ID: I got my application to support openssl s_client connections using the ephemeral ECDH cipher suites. I didn't initialize it properly. Now I am looking at how to get my application accept openssl connections from a client with multiple curves instead of just "NID_X9_62_prime256v1". I appreciate any tips. EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); Thanks! Jordan. On Thu, Sep 8, 2016 at 12:12 PM, yordanos beyene wrote: > Hello, > > I appreciate if anyone can guide me how to set temporary EC Diffie-Hellman > parameters to be able to accept SSL connections from a client > using ephemeral ECDHE cipher. > > I have an ssl based application that can accept SSL connections. I can > establish SSL connections from a client using RSA cipher ( eg AES128-SHA), but > when I use the ephemeral EDHE ciphers (eg ECDHE-RSA-AES128-SHA), the SSL > handshake fails. > > I have been googling to understand the issue for several hours, and it > looks like I need to set temporary DH parameters. > > I added the following code right after SSL initialization and creating > context in my application. > ... > EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); > ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); > if (! ecdh) > error (); > if (1 != SSL_CTX_set_tmp_ecdh (session_cache_ctx, ecdh)) > return -ENOMEM; > EC_KEY_free (ecdh); > ... > > But it is still not working. I am not familiar with this area, and > I greatly appreciate any help. > > I am running OpenSSL 1.0.1 > > Jordan. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmarner at yahoo.com Fri Sep 9 16:11:14 2016 From: asmarner at yahoo.com (asmarner at yahoo.com) Date: Fri, 9 Sep 2016 16:11:14 +0000 (UTC) Subject: [openssl-users] how to set temporary EC Diffie-Hellman parameters In-Reply-To: References: Message-ID: <1707647079.1965632.1473437474504@mail.yahoo.com> How about the following? ? ? EC_KEY *ecdh_parms = NULL; ? ? if (!(ecdh_parms= EC_KEY_new_by_curve_name(NID_X9_62_prime256v1)))? ? {? ? ? ? printf("ECDH key generation failed");? ? ? ? return 0;? ? } ? ? if (EC_KEY_precompute_mult(ecdh_parms, NULL) == 0)? ? {? ? ? ??printf("ECDH precomputation failed");? ? ? ? EC_KEY_free (ecdh_parms);? ? ? ? return 0;? ? } ? ? if (SSL_CTX_set_tmp_ecdh(ssl_ctx, ecdh_parms) == 0)? ? {? ? ? ??printf("ECDH key could not be set");? ? ? ? EC_KEY_free (ecdh_parms);? ? ? ? return 0;? ? } ? ? EC_KEY_free (ecdh_parms); On Friday, September 9, 2016 9:29 PM, yordanos beyene wrote: I got my application to support openssl s_client connections using the ephemeral ECDH cipher suites. I didn't initialize it properly. Now I am looking at how to get my application accept openssl connections from a client with multiple curves instead of just "NID_X9_62_prime256v1". I appreciate any tips. ????? EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); Thanks! Jordan. On Thu, Sep 8, 2016 at 12:12 PM, yordanos beyene wrote: Hello, I appreciate if anyone can guide me how to set temporary EC Diffie-Hellman parameters to be able to accept SSL connections from a client using?ephemeral ECDHE cipher. I have an ssl based application that can accept SSL connections. I can establish SSL connections from a client using RSA?cipher ( eg AES128-SHA), but when I use the ephemeral EDHE ciphers (eg ECDHE-RSA-AES128-SHA), the SSL handshake fails. I have been googling to understand the issue for several hours, and it looks like?I need to?set temporary DH parameters. I added the following code right after SSL initialization and creating context in my application.... ?? EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1);?? ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); ?? if (! ecdh) ?????? error (); ?? if (1 != SSL_CTX_set_tmp_ecdh (session_cache_ctx, ecdh)) ????? return -ENOMEM;?? EC_KEY_free (ecdh); ... But it is still not working. I am not familiar with this area, and I?greatly appreciate any help. I am running OpenSSL 1.0.1 Jordan. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Sep 9 16:25:07 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 9 Sep 2016 18:25:07 +0200 Subject: [openssl-users] Custom lastUpdate in CRL In-Reply-To: References: <0595b325-9249-b866-7ebf-8e44d729c42d@wisemo.com> Message-ID: Interestingly, it is part of standard (automated) operations here. Specifically, we use it to verify that data from the past was actually signed with certificates that were valid at that (past) point in time. It is not an ideal interface, but seems reliable in the controlled environment where it is used. On 09/09/2016 16:37, Rishi Pathak wrote: > Hi Jakob, > Thanks. It solved my problem for now. I agree with your suggestion. > In our scenario this would be a regular thing for coming years and will > not be seen as standard way for operations. > > > On Fri, Sep 9, 2016 at 5:00 PM, Jakob Bohm > wrote: > > On 09/09/2016 12:11, Rishi Pathak wrote: > > Hi, > For a reason we require lastUpdate to be set to a date > in the previous year, with > nextUpdate a year from now in our CRL. Search on google led me > to a patch which > allows use of startDate/endDate for CRL generation as well > apart from certificates. > Seems like 1.0-1 does not have it. Any pointers to how I can > achieve this using > OpenSSL(version) or another utility, preferably on Linux. > > For such tasks, I currently use the faketime utility program > to run the openssl command line tool in a context with the > data artificially set to the desired time in the past. > > I have previously suggested that an "as of" time argument > be added to certificate and signature validation operations, > and your use case suggests the same for issuance and signing > operations as well. > > In fact, it seems the general solution (in future OpenSSL > updates) would be for all operations that use the "current > time/date" to accept an alternative value of that as an > argument. > 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 elizatom at yahoo.com Sat Sep 10 12:06:32 2016 From: elizatom at yahoo.com (shanthi thomas) Date: Sat, 10 Sep 2016 12:06:32 +0000 (UTC) Subject: [openssl-users] openssl asn1parse using both -genstr and -genconf options References: <2022828529.2809903.1473509192034.ref@mail.yahoo.com> Message-ID: <2022828529.2809903.1473509192034@mail.yahoo.com> Hi,? ? I'm trying to use openssl asn1parse subprogram to encode an ASN1 structure. Some of the data in the ASN1 structure is static and I was planning to use a CONF file as shown in the examples for this via the -genconf option. However some of the data I need to pass via a command line argument for which I was planning to use the -genstr option.?However, I'm not sure how to use both the -genstr and the -genconf in a single command. I could find any examples of this either. ?Can someone point me to any good examples on how to use both these options together? Thanks!Elizabeth -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Sat Sep 10 23:20:02 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 10 Sep 2016 23:20:02 +0000 Subject: [openssl-users] openssl asn1parse using both -genstr and -genconf options In-Reply-To: <2022828529.2809903.1473509192034@mail.yahoo.com> References: <2022828529.2809903.1473509192034.ref@mail.yahoo.com> <2022828529.2809903.1473509192034@mail.yahoo.com> Message-ID: <20160910232002.GA8402@openssl.org> On Sat, Sep 10, 2016, shanthi thomas wrote: > Hi,? ? I'm trying to use openssl asn1parse subprogram to encode an ASN1 > structure. Some of the data in the ASN1 structure is static and I was > planning to use a CONF file as shown in the examples for this via the > -genconf option. However some of the data I need to pass via a command line > argument for which I was planning to use the -genstr option.?However, I'm > not sure how to use both the -genstr and the -genconf in a single command. I > could find any examples of this either. ?Can someone point me to any good > examples on how to use both these options together? While you can use -genstr and -genconf together their use is rather limited and probably wont do what you want. Instead I'd suggest passing values using environment variables and uses the config file environment variable options to include them in the appropriate places. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From dclarke at blastwave.org Sun Sep 11 15:51:51 2016 From: dclarke at blastwave.org (Dennis Clarke) Date: Sun, 11 Sep 2016 11:51:51 -0400 Subject: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec Message-ID: <7d4322cf-1a4b-0b8a-e82d-2dcc8e05282c@blastwave.org> Strange results from OpenSSL 1.0.2h built on an older sparc server with Oracle Studio 12.4 and with ALL testsuite tests passed : mimas$ openssl version OpenSSL 1.0.2h 3 May 2016 mimas$ openssl speed Doing mdc2 for 3s on 16 size blocks: 30887 mdc2's in 0.00s Doing mdc2 for 3s on 64 size blocks: 8500 mdc2's in 0.00s Doing mdc2 for 3s on 256 size blocks: 1858 mdc2's in 0.00s Doing mdc2 for 3s on 1024 size blocks: 549 mdc2's in 0.00s Doing mdc2 for 3s on 8192 size blocks: 69 mdc2's in 0.00s Doing md4 for 3s on 16 size blocks: 127674 md4's in 0.00s Doing md4 for 3s on 64 size blocks: 99595 md4's in 0.00s Doing md4 for 3s on 256 size blocks: 59892 md4's in 0.00s . . etc etc . Doing 163 bit ecdh's for 10s: 193 163-bit ECDH ops in 0.00s Doing 233 bit ecdh's for 10s: 94 233-bit ECDH ops in 0.00s Doing 283 bit ecdh's for 10s: 52 283-bit ECDH ops in 0.00s Doing 409 bit ecdh's for 10s: 22 409-bit ECDH ops in 0.00s Doing 571 bit ecdh's for 10s: 9 571-bit ECDH ops in 0.00s OpenSSL 1.0.2h 3 May 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) idea(int) blowfish(ptr) compiler: /opt/solarisstudio12.4/bin/cc -I. -I.. -I../include -KPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -xtarget=ultra2e -xarch=sparcvis -xchip=ultra2e -xcache=generic -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_REENTRANT -xdepend -DB_ENDIAN The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 0.00 0.00 0.00 0.00 0.00 mdc2 Infk Infk Infk Infk Infk md4 Infk Infk Infk Infk Infk md5 Infk Infk Infk Infk Infk . . . ghash Infk Infk Infk Infk Infk sign verify sign/s verify/s rsa 512 bits 0.000000s 0.000000s Inf Inf rsa 1024 bits 0.000000s 0.000000s Inf Inf rsa 2048 bits 0.000000s 0.000000s Inf Inf rsa 4096 bits 0.000000s 0.000000s Inf Inf sign verify sign/s verify/s dsa 512 bits 0.000000s 0.000000s Inf Inf dsa 1024 bits 0.000000s 0.000000s Inf Inf dsa 2048 bits 0.000000s 0.000000s Inf Inf sign verify sign/s verify/s 160 bit ecdsa (secp160r1) 0.0000s 0.0000s Inf Inf 192 bit ecdsa (nistp192) 0.0000s 0.0000s Inf Inf 224 bit ecdsa (nistp224) 0.0000s 0.0000s Inf Inf 256 bit ecdsa (nistp256) 0.0000s 0.0000s Inf Inf 384 bit ecdsa (nistp384) 0.0000s 0.0000s Inf Inf 521 bit ecdsa (nistp521) 0.0000s 0.0000s Inf Inf 163 bit ecdsa (nistk163) 0.0000s 0.0000s Inf Inf 233 bit ecdsa (nistk233) 0.0000s 0.0000s Inf Inf 283 bit ecdsa (nistk283) 0.0000s 0.0000s Inf Inf 409 bit ecdsa (nistk409) 0.0000s 0.0000s Inf Inf 571 bit ecdsa (nistk571) 0.0000s 0.0000s Inf Inf 163 bit ecdsa (nistb163) 0.0000s 0.0000s Inf Inf 233 bit ecdsa (nistb233) 0.0000s 0.0000s Inf Inf 283 bit ecdsa (nistb283) 0.0000s 0.0000s Inf Inf 409 bit ecdsa (nistb409) 0.0000s 0.0000s Inf Inf 571 bit ecdsa (nistb571) 0.0000s 0.0000s Inf Inf op op/s 160 bit ecdh (secp160r1) 0.0000s Inf 192 bit ecdh (nistp192) 0.0000s Inf 224 bit ecdh (nistp224) 0.0000s Inf 256 bit ecdh (nistp256) 0.0000s Inf 384 bit ecdh (nistp384) 0.0000s Inf 521 bit ecdh (nistp521) 0.0000s Inf 163 bit ecdh (nistk163) 0.0000s Inf 233 bit ecdh (nistk233) 0.0000s Inf 283 bit ecdh (nistk283) 0.0000s Inf 409 bit ecdh (nistk409) 0.0000s Inf 571 bit ecdh (nistk571) 0.0000s Inf 163 bit ecdh (nistb163) 0.0000s Inf 233 bit ecdh (nistb233) 0.0000s Inf 283 bit ecdh (nistb283) 0.0000s Inf 409 bit ecdh (nistb409) 0.0000s Inf 571 bit ecdh (nistb571) 0.0000s Inf mimas$ While I appreciate infinite performance in zero time the wall clock disagrees wildly. :-\ Some system info : mimas$ psrinfo -pv The physical processor has 1 virtual processor (0) UltraSPARC-IIe (portid 0 impl 0x13 ver 0x14 clock 500 MHz) mimas$ uname -a SunOS mimas 5.10 Generic_150400-35 sun4u sparc SUNW,UltraAX-i2 mimas$ cat /etc/release Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved. Assembled 17 January 2013 mimas$ which cc /usr/bin/cc mimas$ cc -V cc: Sun C 5.13 SunOS_sparc 2014/10/20 Is this a known bug on older slower hardware ? Dennis Clarke From wieland at purdue.edu Sun Sep 11 19:44:12 2016 From: wieland at purdue.edu (Jeff Wieland) Date: Sun, 11 Sep 2016 15:44:12 -0400 Subject: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec In-Reply-To: <7d4322cf-1a4b-0b8a-e82d-2dcc8e05282c@blastwave.org> References: <7d4322cf-1a4b-0b8a-e82d-2dcc8e05282c@blastwave.org> Message-ID: <57D5B40C.5090607@purdue.edu> I see the same thing on Sun Blade 150 (650Mhz), with OpenSSL 1.0.2h compiled with Studio 12.2 -- and with a Sun Fire V100 (550Mhz). It works correctly on a Sun Fire V240 (1.5Ghz), a Sun Ultra 10 (440Mhz), a Sun Fire T1000, and Sun Enterprise M3000. I see these results with both 32 bit and 64 bit builds. It looks like you're building and running this on an UltraSPARC 2e architecture system -- this is what the SB150 and the V100 are. -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms Dennis Clarke wrote: > > Strange results from OpenSSL 1.0.2h built on an older sparc server > with Oracle Studio 12.4 and with ALL testsuite tests passed : > > mimas$ openssl version > OpenSSL 1.0.2h 3 May 2016 > > mimas$ openssl speed > Doing mdc2 for 3s on 16 size blocks: 30887 mdc2's in 0.00s > Doing mdc2 for 3s on 64 size blocks: 8500 mdc2's in 0.00s > Doing mdc2 for 3s on 256 size blocks: 1858 mdc2's in 0.00s > Doing mdc2 for 3s on 1024 size blocks: 549 mdc2's in 0.00s > Doing mdc2 for 3s on 8192 size blocks: 69 mdc2's in 0.00s > Doing md4 for 3s on 16 size blocks: 127674 md4's in 0.00s > Doing md4 for 3s on 64 size blocks: 99595 md4's in 0.00s > Doing md4 for 3s on 256 size blocks: 59892 md4's in 0.00s > . > . etc etc > . > Doing 163 bit ecdh's for 10s: 193 163-bit ECDH ops in 0.00s > Doing 233 bit ecdh's for 10s: 94 233-bit ECDH ops in 0.00s > Doing 283 bit ecdh's for 10s: 52 283-bit ECDH ops in 0.00s > Doing 409 bit ecdh's for 10s: 22 409-bit ECDH ops in 0.00s > Doing 571 bit ecdh's for 10s: 9 571-bit ECDH ops in 0.00s > OpenSSL 1.0.2h 3 May 2016 > built on: reproducible build, date unspecified > options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) > idea(int) blowfish(ptr) > compiler: /opt/solarisstudio12.4/bin/cc -I. -I.. -I../include -KPIC > -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > -DHAVE_DLFCN_H -m64 -xtarget=ultra2e -xarch=sparcvis -xchip=ultra2e > -xcache=generic -errfmt=error -erroff=%none -errshort=full -xstrconst > -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl > -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none > -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS > -D_LARGEFILE64_SOURCE -D_REENTRANT -xdepend -DB_ENDIAN > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > md2 0.00 0.00 0.00 0.00 0.00 > mdc2 Infk Infk Infk Infk Infk > md4 Infk Infk Infk Infk Infk > md5 Infk Infk Infk Infk Infk > . > . > . > ghash Infk Infk Infk Infk Infk > sign verify sign/s verify/s > rsa 512 bits 0.000000s 0.000000s Inf Inf > rsa 1024 bits 0.000000s 0.000000s Inf Inf > rsa 2048 bits 0.000000s 0.000000s Inf Inf > rsa 4096 bits 0.000000s 0.000000s Inf Inf > sign verify sign/s verify/s > dsa 512 bits 0.000000s 0.000000s Inf Inf > dsa 1024 bits 0.000000s 0.000000s Inf Inf > dsa 2048 bits 0.000000s 0.000000s Inf Inf > sign verify sign/s verify/s > 160 bit ecdsa (secp160r1) 0.0000s 0.0000s Inf Inf > 192 bit ecdsa (nistp192) 0.0000s 0.0000s Inf Inf > 224 bit ecdsa (nistp224) 0.0000s 0.0000s Inf Inf > 256 bit ecdsa (nistp256) 0.0000s 0.0000s Inf Inf > 384 bit ecdsa (nistp384) 0.0000s 0.0000s Inf Inf > 521 bit ecdsa (nistp521) 0.0000s 0.0000s Inf Inf > 163 bit ecdsa (nistk163) 0.0000s 0.0000s Inf Inf > 233 bit ecdsa (nistk233) 0.0000s 0.0000s Inf Inf > 283 bit ecdsa (nistk283) 0.0000s 0.0000s Inf Inf > 409 bit ecdsa (nistk409) 0.0000s 0.0000s Inf Inf > 571 bit ecdsa (nistk571) 0.0000s 0.0000s Inf Inf > 163 bit ecdsa (nistb163) 0.0000s 0.0000s Inf Inf > 233 bit ecdsa (nistb233) 0.0000s 0.0000s Inf Inf > 283 bit ecdsa (nistb283) 0.0000s 0.0000s Inf Inf > 409 bit ecdsa (nistb409) 0.0000s 0.0000s Inf Inf > 571 bit ecdsa (nistb571) 0.0000s 0.0000s Inf Inf > op op/s > 160 bit ecdh (secp160r1) 0.0000s Inf > 192 bit ecdh (nistp192) 0.0000s Inf > 224 bit ecdh (nistp224) 0.0000s Inf > 256 bit ecdh (nistp256) 0.0000s Inf > 384 bit ecdh (nistp384) 0.0000s Inf > 521 bit ecdh (nistp521) 0.0000s Inf > 163 bit ecdh (nistk163) 0.0000s Inf > 233 bit ecdh (nistk233) 0.0000s Inf > 283 bit ecdh (nistk283) 0.0000s Inf > 409 bit ecdh (nistk409) 0.0000s Inf > 571 bit ecdh (nistk571) 0.0000s Inf > 163 bit ecdh (nistb163) 0.0000s Inf > 233 bit ecdh (nistb233) 0.0000s Inf > 283 bit ecdh (nistb283) 0.0000s Inf > 409 bit ecdh (nistb409) 0.0000s Inf > 571 bit ecdh (nistb571) 0.0000s Inf > mimas$ > > > While I appreciate infinite performance in zero time the wall clock > disagrees wildly. :-\ > > Some system info : > > mimas$ psrinfo -pv > The physical processor has 1 virtual processor (0) > UltraSPARC-IIe (portid 0 impl 0x13 ver 0x14 clock 500 MHz) > > mimas$ uname -a > SunOS mimas 5.10 Generic_150400-35 sun4u sparc SUNW,UltraAX-i2 > > mimas$ cat /etc/release > Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights > reserved. > Assembled 17 January 2013 > > mimas$ which cc > /usr/bin/cc > > mimas$ cc -V > cc: Sun C 5.13 SunOS_sparc 2014/10/20 > > Is this a known bug on older slower hardware ? > > Dennis Clarke From dclarke at blastwave.org Mon Sep 12 04:22:10 2016 From: dclarke at blastwave.org (Dennis Clarke) Date: Mon, 12 Sep 2016 00:22:10 -0400 Subject: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec In-Reply-To: <57D5B40C.5090607@purdue.edu> References: <7d4322cf-1a4b-0b8a-e82d-2dcc8e05282c@blastwave.org> <57D5B40C.5090607@purdue.edu> Message-ID: <1e0c1c7c-4315-586e-4363-0b94bd1518cb@blastwave.org> On 09/11/2016 03:44 PM, Jeff Wieland wrote: > I see the same thing on Sun Blade 150 (650Mhz), with OpenSSL 1.0.2h > compiled with Studio 12.2 -- and with a Sun Fire V100 (550Mhz). > > It works correctly on a Sun Fire V240 (1.5Ghz), a Sun Ultra 10 (440Mhz), > a Sun Fire T1000, and Sun Enterprise M3000. > > I see these results with both 32 bit and 64 bit builds. > > It looks like you're building and running this on an UltraSPARC 2e > architecture system -- this is what the SB150 and the V100 are. Hrmmm .. not sure what that means. Given that I run Configure with the "no-asm" option then I would think that cross platform consistency would happen. I would have to go diving into the source to find out where the timings are happening. On Solaris the best timer is the gethrtime() function as it works down to the nanosec and is accurate to the millisec at least. Dennis From amdeich at gmail.com Mon Sep 12 14:35:06 2016 From: amdeich at gmail.com (Andrey Kulikov) Date: Mon, 12 Sep 2016 17:35:06 +0300 Subject: [openssl-users] How to disable SSL session resumption completelly? Message-ID: Hello, I'm using OpenSSL 1.0.2g In my client I would like to disable SSL session resumption completely (for test purposes). I do prior to connection, after creating SSL_CTX: SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF); SSL_CTX_set_options(ctx, SSL_OP_NO_TICKET); But what I saw in traffic capture - is that my client always do session reuse with sending non-empty session ID. And server does accept it. How can I disable SSL session resumption completely? More expanded code snippet: SSL_CTX *ctx = NULL; ctx = SSL_CTX_new(SSLv23_client_method())) SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF); SSL_CTX_set_options(ctx, SSL_OP_NO_TICKET); SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL); SSL_CTX_set_verify_depth(ctx, 0); SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY); Am I doing anything wrong? Any required steps are missing? With best regards, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Sep 12 15:02:24 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 12 Sep 2016 15:02:24 +0000 Subject: [openssl-users] How to disable SSL session resumption completelly? In-Reply-To: References: Message-ID: <20160912150223.GB4670@mournblade.imrryr.org> On Mon, Sep 12, 2016 at 05:35:06PM +0300, Andrey Kulikov wrote: > I'm using OpenSSL 1.0.2g > In my client I would like to disable SSL session resumption completely (for > test purposes). The odd thing is that on the client side, nothing in OpenSSL does resumption by default, because OpenSSL does not know which cached sessions might be appropriate for a given new connection. Client-side re-use happens only via SSL_set_session(3). Perhaps your application code is explicitly assigning previous sessions to nascent SSL connections. -- VIktor. From mauriciorodriguez007 at gmail.com Mon Sep 12 15:57:43 2016 From: mauriciorodriguez007 at gmail.com (Mauricio Rodriguez) Date: Mon, 12 Sep 2016 11:57:43 -0400 Subject: [openssl-users] 1.1.0 Failed to Compile using Visual Studio 6 and SDK 2003 SP1 Message-ID: Hello, I have been able to compile 1.1.0 with no issues using just about all versions of VStudio .NET2003/2005/2008/2010. So, all good there. However, the compilation process using Visual studio 6 has not been smooth and still fails. Here is the environment I am using: - CL.exe - Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. - Windows Server 2003 SP1 SDK - My desktop is running Windows 8 Version 6.3 (Build 9600) I have been modifying 'a bit' a few of the source files and makefile to make it work. Simple things as compiler not recognizing certain macros such the declaration of the 'long long' variable using LL, which I had to switch to i64 (see 2 lines below) //static const int64_t kBottom25Bits = 0x1ffffffLL; // original line static const int64_t kBottom25Bits = 0x1ffffffi64; // it now compiles using Visual Studio 6 compiler I was able to compile the core programs but now getting lots of errors while compiling the 'test programs', so I wanted to post this message to see if this is due to the environment I am using and/or user error or if there is a real issue somewhere. Most of the issues while compiling the test programs are linked to missing data types while using the #define statements in the source code - which there are hundreds of them. Since I just registered to gain access to this group and this is my first post, I'll wait to see if someone wants additional (specific details) about my project. I can then send make file and specific errors during compilation. Thank you very much for anyone replying to my email. Mauricio -------------- next part -------------- An HTML attachment was scrubbed... URL: From wieland at purdue.edu Mon Sep 12 16:53:42 2016 From: wieland at purdue.edu (Jeff Wieland) Date: Mon, 12 Sep 2016 12:53:42 -0400 Subject: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec In-Reply-To: <1e0c1c7c-4315-586e-4363-0b94bd1518cb@blastwave.org> References: <7d4322cf-1a4b-0b8a-e82d-2dcc8e05282c@blastwave.org> <57D5B40C.5090607@purdue.edu> <1e0c1c7c-4315-586e-4363-0b94bd1518cb@blastwave.org> Message-ID: <57D6DD96.9030308@purdue.edu> Dennis Clarke wrote: > On 09/11/2016 03:44 PM, Jeff Wieland wrote: >> I see the same thing on Sun Blade 150 (650Mhz), with OpenSSL 1.0.2h >> compiled with Studio 12.2 -- and with a Sun Fire V100 (550Mhz). >> >> It works correctly on a Sun Fire V240 (1.5Ghz), a Sun Ultra 10 (440Mhz), >> a Sun Fire T1000, and Sun Enterprise M3000. >> >> I see these results with both 32 bit and 64 bit builds. >> >> It looks like you're building and running this on an UltraSPARC 2e >> architecture system -- this is what the SB150 and the V100 are. > > Hrmmm .. not sure what that means. Given that I run Configure with the > "no-asm" option then I would think that cross platform consistency > would happen. I would have to go diving into the source to find out > where the timings are happening. On Solaris the best timer is the > gethrtime() function as it works down to the nanosec and is accurate to > the millisec at least. > > Dennis > > I do build with the no-asm option, and I'm seeing the problem. I'm suspicious that somehow the compiler optimization is generating code that doesn't work quite right on the UltraSPARC 2e. -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms From nikolay.kudryavtsev at gmail.com Mon Sep 12 17:07:44 2016 From: nikolay.kudryavtsev at gmail.com (Nikolay Kudryavtsev) Date: Mon, 12 Sep 2016 20:07:44 +0300 Subject: [openssl-users] Verifying RSA-SHA1 signature? Message-ID: I have some data that was signed with RSA-SHA1 . What's the proper way of verifying that data with a signature? The signature is base64 encoded, so first I do: openssl enc -d -A -base64 -in signature.txt -out signature.sha1 Then I do: openssl dgst -verify pubkey.pem -signature signature.sha1 datafile.txt Or: openssl dgst -sha1 -verify pubkey.pem -signature signature.sha1 datafile.txt Either of those fails with: Verification Failure Whenever I try to verify data signed with my own key, everything works. But for that data that I got from a third party nothing works. That third party is adamant that the signature is correct and it's RSA_SHA1, but they've been unwilling to explain the details on how they sign it and what they use to verify. So what are the proper way of dealing with this? -- Best Regards, Nikolay Kudryavtsev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.brunie at kalray.eu Mon Sep 12 17:12:42 2016 From: nicolas.brunie at kalray.eu (Nicolas Brunie) Date: Mon, 12 Sep 2016 19:12:42 +0200 Subject: [openssl-users] Non-blocking SSL_read/SSL_write: difference between renegociation and data famine Message-ID: <57D6E20A.9080707@kalray.eu> Hi, I am trying to implement bufferization of data on a SSL connection at the application layer. To do so I implemented a wrapper to SSL_write, which fills a buffer rather than sending data directly to SSL_write. When the buffer is full the data is flushed in a call to SSL_write, but when the buffer is not full I still want to ensure that the buffer will be flushed eventually. I have a difficulty in doing so, the thread buffering the data is also the one calling SSL_read on the socket, I would like to prevent it from being frozen if the call to SSL_read does not return (I think the problem will be the same if two threads were doing SSL_write / SSL_read, since I must ensure the SSL* is not used simultaneously)/ From what I could understand, if the BIO under SSL_read is non blocking I am sure that SSL_read will return even if no data is available (with a SSL_ERROR_WANT_READ error code) but the problem is that I am not able to distinguish this error code from a possible renegociation (which also returns SSL_ERROR_WANT_READ). While the renegociation requires me to call SSL_read again with the same parameters, a SSL_ERROR_WANT_READ allows me to flush my write buffer in a SSL_write call, is not it ? Thus my questions: 1. how can I distinguish a data famine from a renegociation occuring on my SSL connection ? 1.2 In the case of a data famine, can I be sure SSL_read will return "rapidly" (not block) if there is no complete data record to be processed ? 2. Using BIO_f_buffer, it seems there is a way to request OpenSSL to buffer write data up until max Record size (setting buffer size from 4 to 16KB), is there a "OpenSSL way" to ensure the BIO_f_buffer will be flushed periodically or must it be implemented externally ? best regards, Nicolas Brunie From openssl-users at dukhovni.org Mon Sep 12 17:15:02 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 12 Sep 2016 13:15:02 -0400 Subject: [openssl-users] Verifying RSA-SHA1 signature? In-Reply-To: References: Message-ID: > On Sep 12, 2016, at 1:07 PM, Nikolay Kudryavtsev wrote: > > The signature is base64 encoded, so first I do: > openssl enc -d -A -base64 -in signature.txt -out signature.sha1 > Then I do: > openssl dgst -verify pubkey.pem -signature signature.sha1 datafile.txt > Or: > openssl dgst -sha1 -verify pubkey.pem -signature signature.sha1 datafile.txt > Either of those fails with: > Verification Failure > > Whenever I try to verify data signed with my own key, everything works. But for that data that I got from a third party nothing works. That third party is adamant that the signature is correct and it's RSA_SHA1, but they've been unwilling to explain the details on how they sign it and what they use to verify. What is the canonical representation of the text file? Does it have line-endings, or line endings? In what representation was it signed? -- Viktor. -- Viktor. From nikolay.kudryavtsev at gmail.com Mon Sep 12 17:26:09 2016 From: nikolay.kudryavtsev at gmail.com (Nikolay Kudryavtsev) Date: Mon, 12 Sep 2016 20:26:09 +0300 Subject: [openssl-users] Verifying RSA-SHA1 signature? In-Reply-To: References: Message-ID: <5ed229d6-667c-5438-678f-46f3aade99e6@gmail.com> Good question! The canonical representation is just a single string of data. I've tried asking that third party whether they have any line endings at the end when they sign it, but received no usable answer. So the most probable is no line endings. I've tried all 3 options, gonna try again just in case. -- Best Regards, Nikolay Kudryavtsev From openssl-users at dukhovni.org Mon Sep 12 18:16:14 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 12 Sep 2016 14:16:14 -0400 Subject: [openssl-users] Verifying RSA-SHA1 signature? In-Reply-To: <5ed229d6-667c-5438-678f-46f3aade99e6@gmail.com> References: <5ed229d6-667c-5438-678f-46f3aade99e6@gmail.com> Message-ID: > On Sep 12, 2016, at 1:26 PM, Nikolay Kudryavtsev wrote: > > The canonical representation is just a single string of data. I've tried asking that third party whether they have any line endings at the end when they sign it, but received no usable answer. So the most probable is no line endings. I've tried all 3 options, gonna try again just in case. While you're at it, what character set? UTF-8? UCS-16? ... Or was the string NUL-terminated, with the NUL included in the signature? Sadly there's lot of room for variation. And are you in fact in possession of the right signature key? Some folks might even return the signature in little-endian form, or for that matter the public key. -- Viktor. From bkaduk at akamai.com Mon Sep 12 18:31:16 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 12 Sep 2016 13:31:16 -0500 Subject: [openssl-users] 1.1.0 Failed to Compile using Visual Studio 6 and SDK 2003 SP1 In-Reply-To: References: Message-ID: <2aa25182-9021-8b5b-9b76-e7da73a89c34@akamai.com> On 09/12/2016 10:57 AM, Mauricio Rodriguez wrote: > Hello, > > > I have been able to compile 1.1.0 with no issues using just about all > versions of VStudio .NET2003/2005/2008/2010. So, all good there. > However, the compilation process using Visual studio 6 has not been > smooth and still fails. Here is the environment I am using: I cannot speak for the project, but Visual Studio 6.0 seems sufficiently old that I would not expect it to be a supported toolchain. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From mauriciorodriguez007 at gmail.com Mon Sep 12 19:04:28 2016 From: mauriciorodriguez007 at gmail.com (Mauricio Rodriguez) Date: Mon, 12 Sep 2016 15:04:28 -0400 Subject: [openssl-users] 1.1.0 Failed to Compile using Visual Studio 6 and SDK 2003 SP1 In-Reply-To: <2aa25182-9021-8b5b-9b76-e7da73a89c34@akamai.com> References: <2aa25182-9021-8b5b-9b76-e7da73a89c34@akamai.com> Message-ID: Ben, Thanks for your prompt answer. I was thinking the same... but was hoping someone had been able to compile and give me some ideas... I'll wait for additional feedback - hoping for the impossible. We should not be using 20 year compiler to do this - agree... On Mon, Sep 12, 2016 at 2:31 PM, Benjamin Kaduk wrote: > On 09/12/2016 10:57 AM, Mauricio Rodriguez wrote: > > Hello, > > > I have been able to compile 1.1.0 with no issues using just about all > versions of VStudio .NET2003/2005/2008/2010. So, all good there. However, > the compilation process using Visual studio 6 has not been smooth and still > fails. Here is the environment I am using: > > > I cannot speak for the project, but Visual Studio 6.0 seems sufficiently > old that I would not expect it to be a supported toolchain. > > -Ben > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Sep 12 19:11:17 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Sep 2016 19:11:17 +0000 Subject: [openssl-users] 1.1.0 Failed to Compile using Visual Studio 6 and SDK 2003 SP1 In-Reply-To: <2aa25182-9021-8b5b-9b76-e7da73a89c34@akamai.com> References: <2aa25182-9021-8b5b-9b76-e7da73a89c34@akamai.com> Message-ID: > I cannot speak for the project, but Visual Studio 6.0 seems sufficiently old that I would not expect it to be a supported toolchain. Yeah, wow, 1998? Not supported. From dclarke at blastwave.org Mon Sep 12 19:41:00 2016 From: dclarke at blastwave.org (Dennis Clarke) Date: Mon, 12 Sep 2016 15:41:00 -0400 Subject: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec In-Reply-To: <57D6DD96.9030308@purdue.edu> References: <7d4322cf-1a4b-0b8a-e82d-2dcc8e05282c@blastwave.org> <57D5B40C.5090607@purdue.edu> <1e0c1c7c-4315-586e-4363-0b94bd1518cb@blastwave.org> <57D6DD96.9030308@purdue.edu> Message-ID: <98f0419d-8c78-0e19-9b58-427df1ac1e6e@blastwave.org> >> > I do build with the no-asm option, and I'm seeing the problem. > > I'm suspicious that somehow the compiler optimization is generating code > that doesn't work quite right on the UltraSPARC 2e. I have seen this a few times now so I also felt, hrmmm, something not quite right happening on these old slow netra boxes. Which, by the way, make great indestructible DNS servers. In any case I changed the CFLAGS for the solaris64-sparcv9-cc option in Configure thus : "solaris64-sparcv9-cc","cc: -m64 -xtarget=ultra2e -xarch=sparcvis -xchip=ultra2e -xcache=generic -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_REENTRANT -xdepend -DB_ENDIAN ::-D_REENTRANT:ULTRASPARC:-lsocket -lnsl -ldl: BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL BF_PTR:${sparcv9_asm}:dlfcn:solaris-shared: -KPIC:-m64 -G -dy -z text:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/64", So the objective was to correct the wrong -xarch flag that has been in there for ages and also to get a full debug version which would be easy to single step through. So that works fine. So what I will look for is where the time calc is done, single step through that and find out why we get a 0.00sec time. Dennis From jb-openssl at wisemo.com Mon Sep 12 21:42:08 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 12 Sep 2016 23:42:08 +0200 Subject: [openssl-users] 1.1.0 Failed to Compile using Visual Studio 6 and SDK 2003 SP1 In-Reply-To: References: <2aa25182-9021-8b5b-9b76-e7da73a89c34@akamai.com> Message-ID: <61e396a7-401a-aafd-9763-92fa2c856ec6@wisemo.com> On 12/09/2016 21:11, Salz, Rich wrote: >> I cannot speak for the project, but Visual Studio 6.0 seems sufficiently old that I would not expect it to be a supported toolchain. > Yeah, wow, 1998? > > Not supported. VC 6.0 was the official Microsoft compiler until the release of Visual Studio.NET 2002. During that long run, a number of public and private projects standardized on that compiler, similar to how many open source projects standardized on GCC 2.95 . VC 6.0 was also a rather reliable and stable compiler, making it the choice for stability over some of its closest successors. But yeah, it is mostly historic now. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From mauriciorodriguez007 at gmail.com Mon Sep 12 23:55:52 2016 From: mauriciorodriguez007 at gmail.com (Mauricio Rodriguez) Date: Mon, 12 Sep 2016 19:55:52 -0400 Subject: [openssl-users] 1.1.0 Failed to Compile using Visual Studio 6 and SDK 2003 SP1 In-Reply-To: <61e396a7-401a-aafd-9763-92fa2c856ec6@wisemo.com> References: <2aa25182-9021-8b5b-9b76-e7da73a89c34@akamai.com> <61e396a7-401a-aafd-9763-92fa2c856ec6@wisemo.com> Message-ID: <827584ED-D518-4163-B578-FBE641EA0EAC@gmail.com> Jakob, Thank you very much for your feedback. I think it makes sense to use something more modern with more support and more users. Thank you for your prompt response. Mauricio Sent from my Ipad.... Ignore any typos > On Sep 12, 2016, at 5:42 PM, Jakob Bohm wrote: > > On 12/09/2016 21:11, Salz, Rich wrote: >>> I cannot speak for the project, but Visual Studio 6.0 seems sufficiently old that I would not expect it to be a supported toolchain. >> Yeah, wow, 1998? >> >> Not supported. > VC 6.0 was the official Microsoft compiler until the release > of Visual Studio.NET 2002. During that long run, a number of > public and private projects standardized on that compiler, > similar to how many open source projects standardized on GCC > 2.95 . > > VC 6.0 was also a rather reliable and stable compiler, making > it the choice for stability over some of its closest successors. > > But yeah, it is mostly historic now. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From wieland at purdue.edu Tue Sep 13 00:56:11 2016 From: wieland at purdue.edu (Jeff Wieland) Date: Mon, 12 Sep 2016 20:56:11 -0400 Subject: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec In-Reply-To: <98f0419d-8c78-0e19-9b58-427df1ac1e6e@blastwave.org> References: <7d4322cf-1a4b-0b8a-e82d-2dcc8e05282c@blastwave.org> <57D5B40C.5090607@purdue.edu> <1e0c1c7c-4315-586e-4363-0b94bd1518cb@blastwave.org> <57D6DD96.9030308@purdue.edu> <98f0419d-8c78-0e19-9b58-427df1ac1e6e@blastwave.org> Message-ID: <57D74EAB.1090805@purdue.edu> Dennis Clarke wrote: > >>> >> I do build with the no-asm option, and I'm seeing the problem. >> >> I'm suspicious that somehow the compiler optimization is generating code >> that doesn't work quite right on the UltraSPARC 2e. > > I have seen this a few times now so I also felt, hrmmm, something not > quite right happening on these old slow netra boxes. Which, by the > way, make great indestructible DNS servers. > > In any case I changed the CFLAGS for the solaris64-sparcv9-cc option in > Configure thus : > > > "solaris64-sparcv9-cc","cc: > > -m64 -xtarget=ultra2e -xarch=sparcvis -xchip=ultra2e -xcache=generic > -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff > -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee > -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf > -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS > -D_LARGEFILE64_SOURCE -D_REENTRANT -xdepend -DB_ENDIAN > > ::-D_REENTRANT:ULTRASPARC:-lsocket -lnsl -ldl: > > BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL > BF_PTR:${sparcv9_asm}:dlfcn:solaris-shared: > -KPIC:-m64 -G -dy -z text:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/64", > > > So the objective was to correct the wrong -xarch flag that has been in > there for ages and also to get a full debug version which would be > easy to single step through. > > So that works fine. > > So what I will look for is where the time calc is done, single step > through that and find out why we get a 0.00sec time. > > Dennis I get the same results compiling with Oracle's build of gcc in /usr/sfw/bin (which uses the Solaris assembler, etc.) and my own build of gcc 3.4.6 (which uses the GNU assembler, etc.). Have you tried running Oracle's builds of OpenSSL? They do the same thing on the UltraSPARC 2e: $ /usr/bin/openssl version;/usr/bin/openssl speed OpenSSL 1.0.1t 3 May 2016 Doing md2 for 3s on 16 size blocks: 140755 md2's in 0.00s Doing md2 for 3s on 64 size blocks: 73864 md2's in 0.00s Doing md2 for 3s on 256 size blocks: 25778 md2's in 0.00s Doing md2 for 3s on 1024 size blocks: 6695 md2's in 0.00s ... $ /usr/sfw/bin/openssl version;/usr/sfw/bin/openssl> OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343 CVE-2006-7250 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2008-7270 CVE-2009-0590 CVE-2009-2409 CVE-2009-3555 CVE-2010-4180 CVE-2011-4576 CVE-2011-4619 CVE-2012-0884 CVE-2012-1165 CVE-2012-2110 CVE-2012-2131 CVE-2012-2333 CVE-2013-0166 CVE-2013-0169 CVE-2014-0224 CVE-2014-3508 CVE-2014-3511 CVE-2014-3566 CVE-2014-3567 CVE-2014-3568 CVE-2014-3569 CVE-2014-3570 CVE-2014-8275 CVE-2015-0204 CVE-2015-0286 CVE-2015-0287 CVE-2015-0288 CVE-2015-0289 CVE-2015-0292 CVE-2015-0293 CVE-2015-1789 CVE-2015-1790 CVE-2015-3195 CVE-2015-3197 CVE-2015-4000 CVE-2016-0703 CVE-2016-0704 CVE-2016-0797 CVE-2016-0799 CVE-2016-0800 CVE-2016-2105 CVE-2016-2106 CVE-2016-2107 CVE-2016-2108 CVE-2016-2176) Doing md2 for 3s on 16 size blocks: 79067 md2's in 0.00s Doing md2 for 3s on 64 size blocks: 42773 md2's in 0.00s Doing md2 for 3s on 256 size blocks: 15316 md2's in 0.00s Doing md2 for 3s on 1024 size blocks: 4240 md2's in 0.00s Doing md2 for 3s on 8192 size blocks: 543 md2's in 0.00s ... They appear to work fine on the other SPARC machines that I can get test it on. -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms From dclarke at blastwave.org Tue Sep 13 01:47:55 2016 From: dclarke at blastwave.org (Dennis Clarke) Date: Mon, 12 Sep 2016 21:47:55 -0400 Subject: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec In-Reply-To: <57D74EAB.1090805@purdue.edu> References: <7d4322cf-1a4b-0b8a-e82d-2dcc8e05282c@blastwave.org> <57D5B40C.5090607@purdue.edu> <1e0c1c7c-4315-586e-4363-0b94bd1518cb@blastwave.org> <57D6DD96.9030308@purdue.edu> <98f0419d-8c78-0e19-9b58-427df1ac1e6e@blastwave.org> <57D74EAB.1090805@purdue.edu> Message-ID: <9dab5edc-8f7b-1d1d-718f-3eaac007e84a@blastwave.org> > Have you tried running Oracle's builds of OpenSSL? They do the same > thing on the UltraSPARC 2e: This is officially a bug. I'll file it and start looking into this one. Very odd. I will try this on a few other RISC architectures and see what I see. Starting with Power6. Dennis From steve at openssl.org Tue Sep 13 02:19:24 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 13 Sep 2016 02:19:24 +0000 Subject: [openssl-users] Verifying RSA-SHA1 signature? In-Reply-To: References: Message-ID: <20160913021924.GA6805@openssl.org> On Mon, Sep 12, 2016, Nikolay Kudryavtsev wrote: > > Whenever I try to verify data signed with my own key, everything > works. But for that data that I got from a third party nothing > works. That third party is adamant that the signature is correct and > it's RSA_SHA1, but they've been unwilling to explain the details on > how they sign it and what they use to verify. > > So what are the proper way of dealing with this? > You can extract the expected digest using either rsautl or pkeyutl and the public key. If that fails then there is a problem with either the key or the format. If you can successfully extract the digest then you can try various transormations on the input data in an attempt to get the same digest. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From zy_chongqing at aliyun.com Tue Sep 13 13:17:47 2016 From: zy_chongqing at aliyun.com (zy_chongqing) Date: Tue, 13 Sep 2016 21:17:47 +0800 Subject: [openssl-users] =?utf-8?q?=5Bhelp=5DSSL=5FCTX=5Fuse=5Fcertificate?= =?utf-8?q?=5Ffile_failed!?= Message-ID: <9b87f0cd-90a7-4a66-8f6a-68e5a0bfef21.zy_chongqing@aliyun.com> Hi, I have a big problem about the OpenSSL usage, please help. OS:?Linux?version?3.7.10-1.1-desktop?(geeko at buildhost)?(gcc?version?4.7.2?20130108?[gcc-4_7-branch?revision?195012]?(SUSE?Linux)?)?#1?SMP?PREEMPT?Thu?Feb?28?15:06:29?UTC?2013?(82d3f21)OpenSSL version:?OpenSSL?1.1.0??25?Aug?2016 I create a OpenSSL client for iOS APNs client, the SSL initial function as below:#define?CA_CERT_PATH ? ? ? ? ?"./pem" #define?RSA_CLIENT_CERT?????"./pem/PushChatCert.pem" #define?RSA_CLIENT_KEY ? ? ? "./pem/PushChatKey.pem"bool?CAPNSClient::InitAPNSClient() { ????SSL_library_init(); ????SSL_load_error_strings(); ????ERR_clear_error(); ????OpenSSL_add_all_algorithms(); ? ????m_pMeth?=?TLS_client_method(); ????m_pCtx?=?SSL_CTX_new(m_pMeth); ????if(NULL?==?m_pCtx) ????{ ????????ERRLOG("Could?not?get?SSL?Context"); ????????return?false; ????} ????if(0?==?SSL_CTX_load_verify_locations(m_pCtx,?NULL,?CA_CERT_PATH)) ????{ ????????/*?Handle?failed?load?here?*/ ????????ERRLOG("Failed?to?set?CA?location:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); ????????return?false; ????} ????if?(0?==?SSL_CTX_use_certificate_file(m_pCtx,?RSA_CLIENT_CERT,?SSL_FILETYPE_PEM)) ????{ ????????ERRLOG("Cannot?use?Certificate?File:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); ????????return?false; ????} ????SSL_CTX_set_default_passwd_cb_userdata(m_pCtx,?(void*)"XXXX"); ????if?(0?==?SSL_CTX_use_PrivateKey_file(m_pCtx,?RSA_CLIENT_KEY,?SSL_FILETYPE_PEM)) ????{ ????????ERRLOG("Cannot?use?Private?Key:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); ????????return?false; ????} ????if?(0?==?SSL_CTX_check_private_key(m_pCtx)) ????{ ????????ERRLOG("Private?key?does?not?match?the?certificate?public?key"); ????????return?false; ????} ????return?true; } when the programe run, the?SSL_CTX_use_certificate_file failed when load the certificate as attached! the error information is:??error:140AB18F:SSL?routines:SSL_CTX_use_certificate:ee?key?too?small as the suggestion from rt at openssl.org last night, I use?SSL_CTX_set_security_level(m_pCtx,?0) switch the security level from 1 to 0. ?But?SSL_CTX_use_certificate_file still failed! the log chang to:?error:140BF10C:SSL?routines:ssl_set_cert:x509?lib the weird thing is, this code and pem file work well on another server, which have the security level 1. So I guess the problem come from the ssl config. After searching, I found 2 openssl.cnf files, one on /etc/ssl/, another is on /usr/local/ssl. there only 4 different config between these 2 file:1.?default_bits, one is 2048, another is 10242.?basicConstraints, one is "critical,CA:true", another is "CA:true"3.?signer_digest, one is "sha256", another don't have this parameter4.?digests, one is "sha1,?sha256,?sha384,?sha512", another is "md5,?sha1" I already debug this issue for whole day, but still don't have any progress. Please help me, at least guide me how to solve it.? Thanks a lot! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PushChatCert.pem Type: application/octet-stream Size: 2139 bytes Desc: not available URL: From matt at openssl.org Tue Sep 13 14:06:44 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Sep 2016 15:06:44 +0100 Subject: [openssl-users] [help]SSL_CTX_use_certificate_file failed! In-Reply-To: <9b87f0cd-90a7-4a66-8f6a-68e5a0bfef21.zy_chongqing@aliyun.com> References: <9b87f0cd-90a7-4a66-8f6a-68e5a0bfef21.zy_chongqing@aliyun.com> Message-ID: Comments inserted... On 13/09/16 14:17, zy_chongqing wrote: > Hi, > > I have a big problem about the OpenSSL usage, please help. > OS: Linux version 3.7.10-1.1-desktop (geeko at buildhost) (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 SMP PREEMPT Thu Feb 28 15:06:29 UTC 2013 (82d3f21) > OpenSSL version: OpenSSL 1.1.0 25 Aug 2016 > > I create a OpenSSL client for iOS APNs client, the SSL initial function > as below: > #define CA_CERT_PATH "./pem" > #define RSA_CLIENT_CERT "./pem/PushChatCert.pem" > #define RSA_CLIENT_KEY "./pem/PushChatKey.pem" > bool CAPNSClient::InitAPNSClient() > { > SSL_library_init(); > SSL_load_error_strings(); > ERR_clear_error(); > OpenSSL_add_all_algorithms(); None of the above 4 function calls are required in OpenSSL 1.1.0. They can be removed. That's not your problem though... > > m_pMeth = TLS_client_method(); > > m_pCtx = SSL_CTX_new(m_pMeth); > if(NULL == m_pCtx) > { > ERRLOG("Could not get SSL Context"); > return false; > } > > if(0 == SSL_CTX_load_verify_locations(m_pCtx, NULL, CA_CERT_PATH)) > { > /* Handle failed load here */ > ERRLOG("Failed to set CA location:%s", ERR_error_string( ERR_get_error(), NULL )); > return false; > } > > if (0 == SSL_CTX_use_certificate_file(m_pCtx, RSA_CLIENT_CERT, SSL_FILETYPE_PEM)) > { > ERRLOG("Cannot use Certificate File:%s", ERR_error_string( ERR_get_error(), NULL )); > return false; > } > > SSL_CTX_set_default_passwd_cb_userdata(m_pCtx, (void*)"XXXX"); > > if (0 == SSL_CTX_use_PrivateKey_file(m_pCtx, RSA_CLIENT_KEY, SSL_FILETYPE_PEM)) > { > ERRLOG("Cannot use Private Key:%s", ERR_error_string( ERR_get_error(), NULL )); > return false; > } > > if (0 == SSL_CTX_check_private_key(m_pCtx)) > { > ERRLOG("Private key does not match the certificate public key"); > return false; > } > > return true; > } > > when the programe run, the SSL_CTX_use_certificate_file failed when load > the certificate as attached! the error information > is: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small > > as the suggestion from rt at openssl.org last night, I > use SSL_CTX_set_security_level(m_pCtx, 0) switch the security level from > 1 to 0. But SSL_CTX_use_certificate_file still failed! the log chang > to: error:140BF10C:SSL routines:ssl_set_cert:x509 lib As far as I can determine from the errors you are seeing, SSL_CTX_use_certificate_file() has successfully read the certificate file and returned a non NULL X509 object (otherwise you would have seen a different error). Once SSL_CTX_use_certificate_file() has got an X509 object it then calls SSL_CTX_use_certificate(). This calls an internal function ssl_security_cert(), which in turn calls ssl_security_cert_key(), which calls X509_get0_pubkey() on the supplied X509 object. *If this returns NULL* then an internal variable secbits which represents the number of security bits in the public key is set to -1. Subsequently various calls take place and if the number of security bits is too small (which presumably -1 is) then you get the "ee key too small" error. By setting the security level to 0, the above is avoided and processing gets further. SSL_CTX_use_certificate() next calls an internal function ssl_set_cert(). The first thing ssl_set_cert() does is call X509_get0_pubkey() again. If this return NULL then you get the "x509 lib" error. Therefore, I believe there is a problem with the X509_get0_pubkey() call, such that it is always returning NULL for your particular certificate. The question is why? Are you able to share the certificate file? Are there any other errors on the error queue besides these ones? There are a few different things that could cause this and a number of them would add additional errors to the error queue. Matt From zy_chongqing at aliyun.com Tue Sep 13 14:53:57 2016 From: zy_chongqing at aliyun.com (zy_chongqing) Date: Tue, 13 Sep 2016 22:53:57 +0800 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIFtoZWxwXVNTTF9DVFhfdXNl?= =?utf-8?q?=5Fcertificate=5Ffile_failed!?= In-Reply-To: d0fa677a-26a5-15ba-6395-5de5da2e6231@openssl.org References: <9b87f0cd-90a7-4a66-8f6a-68e5a0bfef21.zy_chongqing@aliyun.com>, d0fa677a-26a5-15ba-6395-5de5da2e6231@openssl.org Message-ID: Hi Matt, thanks for your reply. please kindly find the attached to get the certificate. actually after i set the security level to 0, some times the result is to get the error code you read before, but some times the programe will crash directly. I checked the stack information as below: [2016-09-13?11:52:03][crash?signal?number:11] 0?./MemoSrv()?[0x808031e] 1?linux-gate.so.1(__kernel_sigreturn+0)?[0xb7734400] 2?/lib/libpthread.so.0(pthread_rwlock_wrlock+0xf)?[0xb74f45ff] 3?./MemoSrv(CRYPTO_THREAD_write_lock+0x1b)?[0x81783cb] 4?./MemoSrv(X509_check_purpose+0x66)?[0x8237756] 5?./MemoSrv(X509_get_extension_flags+0x2c)?[0x823794c] 6?/usr/local/lib/libssl.so.1.1(+0x4dd65)?[0xb76a2d65] 7?/usr/local/lib/libssl.so.1.1(SSL_CTX_use_certificate+0x41)?[0xb76853c1] 8?/usr/local/lib/libssl.so.1.1(SSL_CTX_use_certificate_file+0xed)?[0xb768553d] 9?./MemoSrv()?[0x80bc93b] 10?./MemoSrv()?[0x80bd32a] 11?./MemoSrv()?[0x8088dc2] 12?./MemoSrv()?[0x80805e8] 13?/lib/libc.so.6(__libc_start_main+0xf3)?[0xb738a6e3] 14?./MemoSrv()?[0x808010d] If you need additional information or operation, please let me know.thanks!------------------------------------------------------------------????Matt Caswell ?????2016?9?13?(???) 22:07????openssl-users ????Re: [openssl-users] [help]SSL_CTX_use_certificate_file failed! Comments?inserted... On?13/09/16?14:17,?zy_chongqing?wrote: >?Hi, >? >?I?have?a?big?problem?about?the?OpenSSL?usage,?please?help. >?OS:?Linux?version?3.7.10-1.1-desktop?(geeko at buildhost)?(gcc?version?4.7.2?20130108?[gcc-4_7-branch?revision?195012]?(SUSE?Linux)?)?#1?SMP?PREEMPT?Thu?Feb?28?15:06:29?UTC?2013?(82d3f21) >?OpenSSL?version:?OpenSSL?1.1.0??25?Aug?2016 >? >?I?create?a?OpenSSL?client?for?iOS?APNs?client,?the?SSL?initial?function >?as?below: >?#define?CA_CERT_PATH??????????"./pem" >?#define?RSA_CLIENT_CERT?????"./pem/PushChatCert.pem" >?#define?RSA_CLIENT_KEY???????"./pem/PushChatKey.pem" >?bool?CAPNSClient::InitAPNSClient() >?{ >?????SSL_library_init(); >?????SSL_load_error_strings(); >?????ERR_clear_error(); >?????OpenSSL_add_all_algorithms(); None?of?the?above?4?function?calls?are?required?in?OpenSSL?1.1.0.?They can?be?removed.?That's?not?your?problem?though... >?? >?????m_pMeth?=?TLS_client_method(); >? >?????m_pCtx?=?SSL_CTX_new(m_pMeth); >?????if(NULL?==?m_pCtx) >?????{ >?????????ERRLOG("Could?not?get?SSL?Context"); >?????????return?false; >?????} >? >?????if(0?==?SSL_CTX_load_verify_locations(m_pCtx,?NULL,?CA_CERT_PATH)) >?????{ >?????????/*?Handle?failed?load?here?*/ >?????????ERRLOG("Failed?to?set?CA?location:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); >?????????return?false; >?????} >? >?????if?(0?==?SSL_CTX_use_certificate_file(m_pCtx,?RSA_CLIENT_CERT,?SSL_FILETYPE_PEM)) >?????{ >?????????ERRLOG("Cannot?use?Certificate?File:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); >?????????return?false; >?????} >? >?????SSL_CTX_set_default_passwd_cb_userdata(m_pCtx,?(void*)"XXXX"); >? >?????if?(0?==?SSL_CTX_use_PrivateKey_file(m_pCtx,?RSA_CLIENT_KEY,?SSL_FILETYPE_PEM)) >?????{ >?????????ERRLOG("Cannot?use?Private?Key:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); >?????????return?false; >?????} >? >?????if?(0?==?SSL_CTX_check_private_key(m_pCtx)) >?????{ >?????????ERRLOG("Private?key?does?not?match?the?certificate?public?key"); >?????????return?false; >?????} >? >?????return?true; >?} >? >?when?the?programe?run,?the?SSL_CTX_use_certificate_file?failed?when?load >?the?certificate?as?attached!?the?error?information >?is:??error:140AB18F:SSL?routines:SSL_CTX_use_certificate:ee?key?too?small >? >?as?the?suggestion?from?rt at openssl.org?last?night,?I >?use?SSL_CTX_set_security_level(m_pCtx,?0)?switch?the?security?level?from >?1?to?0.??But?SSL_CTX_use_certificate_file?still?failed!?the?log?chang >?to:?error:140BF10C:SSL?routines:ssl_set_cert:x509?lib As?far?as?I?can?determine?from?the?errors?you?are?seeing, SSL_CTX_use_certificate_file()?has?successfully?read?the?certificate file?and?returned?a?non?NULL?X509?object?(otherwise?you?would?have?seen a?different?error). Once?SSL_CTX_use_certificate_file()?has?got?an?X509?object?it?then?calls SSL_CTX_use_certificate(). This?calls?an?internal?function?ssl_security_cert(),?which?in?turn?calls ssl_security_cert_key(),?which?calls?X509_get0_pubkey()?on?the?supplied X509?object.?*If?this?returns?NULL*?then?an?internal?variable?secbits which?represents?the?number?of?security?bits?in?the?public?key?is?set?to -1.?Subsequently?various?calls?take?place?and?if?the?number?of?security bits?is?too?small?(which?presumably?-1?is)?then?you?get?the?"ee?key?too small"?error. By?setting?the?security?level?to?0,?the?above?is?avoided?and?processing gets?further.?SSL_CTX_use_certificate()?next?calls?an?internal?function ssl_set_cert(). The?first?thing?ssl_set_cert()?does?is?call?X509_get0_pubkey()?again.?If this?return?NULL?then?you?get?the?"x509?lib"?error. Therefore,?I?believe?there?is?a?problem?with?the?X509_get0_pubkey() call,?such?that?it?is?always?returning?NULL?for?your?particular certificate.?The?question?is?why??Are?you?able?to?share?the?certificate file???Are?there?any?other?errors?on?the?error?queue?besides?these?ones? There?are?a?few?different?things?that?could?cause?this?and?a?number?of them?would?add?additional?errors?to?the?error?queue. Matt --? openssl-users?mailing?list To?unsubscribe:?https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PushChatCert.pem Type: application/octet-stream Size: 2139 bytes Desc: not available URL: From nikolay.kudryavtsev at gmail.com Tue Sep 13 15:25:40 2016 From: nikolay.kudryavtsev at gmail.com (Nikolay Kudryavtsev) Date: Tue, 13 Sep 2016 18:25:40 +0300 Subject: [openssl-users] Verifying RSA-SHA1 signature? In-Reply-To: <20160913021924.GA6805@openssl.org> References: <20160913021924.GA6805@openssl.org> Message-ID: <6e00c48d-c403-137c-1fa9-8710f16e556a@gmail.com> Ok, thanks the help. Extracting the digest didn't work for me. But I was finally able to contact a member of that third party who had the knowledge of the procedure they use. So after some basic questions, I've asked that person "sure you sign that data with that key you sent us"? The answer was: "no, a different one". -- Best Regards, Nikolay Kudryavtsev From zy_chongqing at aliyun.com Tue Sep 13 15:29:33 2016 From: zy_chongqing at aliyun.com (zy_chongqing) Date: Tue, 13 Sep 2016 23:29:33 +0800 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIOWbnuWkje+8miBbaGVscF1T?= =?utf-8?q?SL=5FCTX=5Fuse=5Fcertificate=5Ffile_failed!?= In-Reply-To: c5feac89-486c-4560-b9a3-62c6d7f1ab2e.zy_chongqing@aliyun.com References: <9b87f0cd-90a7-4a66-8f6a-68e5a0bfef21.zy_chongqing@aliyun.com>, d0fa677a-26a5-15ba-6395-5de5da2e6231@openssl.org, c5feac89-486c-4560-b9a3-62c6d7f1ab2e.zy_chongqing@aliyun.com Message-ID: There is not other error information. And I try to get more error message by the method as below:if?(0?==?SSL_CTX_use_certificate_file(m_pCtx,?RSA_CLIENT_CERT,?SSL_FILETYPE_PEM)) ????{ ????????ERRLOG("Cannot?use?Certificate?File:%s",?ERR_error_string(?ERR_get_error(),?NULL?));????????ERRLOG("Cannot?use?Certificate?File:%s",?ERR_error_string(?ERR_get_error(),?NULL?));????????ERRLOG("Cannot?use?Certificate?File:%s",?ERR_error_string(?ERR_get_error(),?NULL?));????????ERRLOG("Cannot?use?Certificate?File:%s",?ERR_error_string(?ERR_get_error(),?NULL?));????????ERRLOG("Cannot?use?Certificate?File:%s",?ERR_error_string(?ERR_get_error(),?NULL?));????????return?false; ????} but result is:error:140AB18F:SSL?routines:SSL_CTX_use_certificate:ee?key?too?small error:00000000:lib(0):func(0):reason(0) error:00000000:lib(0):func(0):reason(0) error:00000000:lib(0):func(0):reason(0) error:00000000:lib(0):func(0):reason(0) Is my method correct to get the other error messages?------------------------------------------------------------------????zy_chongqing ?????2016?9?13?(???) 22:54????openssl-users ????[openssl-users] ??? [help]SSL_CTX_use_certificate_file failed! Hi Matt, thanks for your reply. please kindly find the attached to get the certificate. actually after i set the security level to 0, some times the result is to get the error code you read before, but some times the programe will crash directly. I checked the stack information as below: [2016-09-13?11:52:03][crash?signal?number:11] 0?./MemoSrv()?[0x808031e] 1?linux-gate.so.1(__kernel_sigreturn+0)?[0xb7734400] 2?/lib/libpthread.so.0(pthread_rwlock_wrlock+0xf)?[0xb74f45ff] 3?./MemoSrv(CRYPTO_THREAD_write_lock+0x1b)?[0x81783cb] 4?./MemoSrv(X509_check_purpose+0x66)?[0x8237756] 5?./MemoSrv(X509_get_extension_flags+0x2c)?[0x823794c] 6?/usr/local/lib/libssl.so.1.1(+0x4dd65)?[0xb76a2d65] 7?/usr/local/lib/libssl.so.1.1(SSL_CTX_use_certificate+0x41)?[0xb76853c1] 8?/usr/local/lib/libssl.so.1.1(SSL_CTX_use_certificate_file+0xed)?[0xb768553d] 9?./MemoSrv()?[0x80bc93b] 10?./MemoSrv()?[0x80bd32a] 11?./MemoSrv()?[0x8088dc2] 12?./MemoSrv()?[0x80805e8] 13?/lib/libc.so.6(__libc_start_main+0xf3)?[0xb738a6e3] 14?./MemoSrv()?[0x808010d] If you need additional information or operation, please let me know.thanks!------------------------------------------------------------------????Matt Caswell ?????2016?9?13?(???) 22:07????openssl-users ????Re: [openssl-users] [help]SSL_CTX_use_certificate_file failed! Comments?inserted... On?13/09/16?14:17,?zy_chongqing?wrote: >?Hi, >? >?I?have?a?big?problem?about?the?OpenSSL?usage,?please?help. >?OS:?Linux?version?3.7.10-1.1-desktop?(geeko at buildhost)?(gcc?version?4.7.2?20130108?[gcc-4_7-branch?revision?195012]?(SUSE?Linux)?)?#1?SMP?PREEMPT?Thu?Feb?28?15:06:29?UTC?2013?(82d3f21) >?OpenSSL?version:?OpenSSL?1.1.0??25?Aug?2016 >? >?I?create?a?OpenSSL?client?for?iOS?APNs?client,?the?SSL?initial?function >?as?below: >?#define?CA_CERT_PATH??????????"./pem" >?#define?RSA_CLIENT_CERT?????"./pem/PushChatCert.pem" >?#define?RSA_CLIENT_KEY???????"./pem/PushChatKey.pem" >?bool?CAPNSClient::InitAPNSClient() >?{ >?????SSL_library_init(); >?????SSL_load_error_strings(); >?????ERR_clear_error(); >?????OpenSSL_add_all_algorithms(); None?of?the?above?4?function?calls?are?required?in?OpenSSL?1.1.0.?They can?be?removed.?That's?not?your?problem?though... >?? >?????m_pMeth?=?TLS_client_method(); >? >?????m_pCtx?=?SSL_CTX_new(m_pMeth); >?????if(NULL?==?m_pCtx) >?????{ >?????????ERRLOG("Could?not?get?SSL?Context"); >?????????return?false; >?????} >? >?????if(0?==?SSL_CTX_load_verify_locations(m_pCtx,?NULL,?CA_CERT_PATH)) >?????{ >?????????/*?Handle?failed?load?here?*/ >?????????ERRLOG("Failed?to?set?CA?location:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); >?????????return?false; >?????} >? >?????if?(0?==?SSL_CTX_use_certificate_file(m_pCtx,?RSA_CLIENT_CERT,?SSL_FILETYPE_PEM)) >?????{ >?????????ERRLOG("Cannot?use?Certificate?File:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); >?????????return?false; >?????} >? >?????SSL_CTX_set_default_passwd_cb_userdata(m_pCtx,?(void*)"XXXX"); >? >?????if?(0?==?SSL_CTX_use_PrivateKey_file(m_pCtx,?RSA_CLIENT_KEY,?SSL_FILETYPE_PEM)) >?????{ >?????????ERRLOG("Cannot?use?Private?Key:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); >?????????return?false; >?????} >? >?????if?(0?==?SSL_CTX_check_private_key(m_pCtx)) >?????{ >?????????ERRLOG("Private?key?does?not?match?the?certificate?public?key"); >?????????return?false; >?????} >? >?????return?true; >?} >? >?when?the?programe?run,?the?SSL_CTX_use_certificate_file?failed?when?load >?the?certificate?as?attached!?the?error?information >?is:??error:140AB18F:SSL?routines:SSL_CTX_use_certificate:ee?key?too?small >? >?as?the?suggestion?from?rt at openssl.org?last?night,?I >?use?SSL_CTX_set_security_level(m_pCtx,?0)?switch?the?security?level?from >?1?to?0.??But?SSL_CTX_use_certificate_file?still?failed!?the?log?chang >?to:?error:140BF10C:SSL?routines:ssl_set_cert:x509?lib As?far?as?I?can?determine?from?the?errors?you?are?seeing, SSL_CTX_use_certificate_file()?has?successfully?read?the?certificate file?and?returned?a?non?NULL?X509?object?(otherwise?you?would?have?seen a?different?error). Once?SSL_CTX_use_certificate_file()?has?got?an?X509?object?it?then?calls SSL_CTX_use_certificate(). This?calls?an?internal?function?ssl_security_cert(),?which?in?turn?calls ssl_security_cert_key(),?which?calls?X509_get0_pubkey()?on?the?supplied X509?object.?*If?this?returns?NULL*?then?an?internal?variable?secbits which?represents?the?number?of?security?bits?in?the?public?key?is?set?to -1.?Subsequently?various?calls?take?place?and?if?the?number?of?security bits?is?too?small?(which?presumably?-1?is)?then?you?get?the?"ee?key?too small"?error. By?setting?the?security?level?to?0,?the?above?is?avoided?and?processing gets?further.?SSL_CTX_use_certificate()?next?calls?an?internal?function ssl_set_cert(). The?first?thing?ssl_set_cert()?does?is?call?X509_get0_pubkey()?again.?If this?return?NULL?then?you?get?the?"x509?lib"?error. Therefore,?I?believe?there?is?a?problem?with?the?X509_get0_pubkey() call,?such?that?it?is?always?returning?NULL?for?your?particular certificate.?The?question?is?why??Are?you?able?to?share?the?certificate file???Are?there?any?other?errors?on?the?error?queue?besides?these?ones? There?are?a?few?different?things?that?could?cause?this?and?a?number?of them?would?add?additional?errors?to?the?error?queue. Matt --? openssl-users?mailing?list To?unsubscribe:?https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 13 15:45:49 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 13 Sep 2016 15:45:49 +0000 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaICBbaGVscF1TU0xfQ1RYX3Vz?= =?utf-8?q?e=5Fcertificate=5Ffile_failed!?= In-Reply-To: References: <9b87f0cd-90a7-4a66-8f6a-68e5a0bfef21.zy_chongqing@aliyun.com> Message-ID: <20160913154548.GH4670@mournblade.imrryr.org> On Tue, Sep 13, 2016 at 10:53:57PM +0800, zy_chongqing wrote: > thanks for your reply. please kindly find the attached to get the certificate. Firstly, you posted a 2048-bit certificate, which would not normally fail with a "key too small" error, other than by failure to parse the public key. Secondly, when I start the OpenSSL 1.1.0 s_server(1) with the posted certificate as the chain file, and a random 2048-bit RSA key as the key file, the error is that the key and certificate don't match. This means that at least s_server *is* able to parse the public key. Are there some other certificates in the chain file, in addition to the leaf certificate you posted? Please post all the certificates (but not the private key) from that chain file. $ openssl genrsa 2048 >> /tmp/cert.pem Generating RSA private key, 2048 bit long modulus ........................................................................+++ ...............+++ e is 65537 (0x010001) $ openssl s_server -cert /tmp/cert.pem -accept 12345 Using default temp DH parameters error setting private key 140735148003328:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:../openssl/crypto/x509/x509_cmp.c:295: -- Viktor. From zy_chongqing at aliyun.com Tue Sep 13 15:59:06 2016 From: zy_chongqing at aliyun.com (zy_chongqing) Date: Tue, 13 Sep 2016 23:59:06 +0800 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIOWbnuWkje+8miAgW2hlbHBd?= =?utf-8?q?SSL=5FCTX=5Fuse=5Fcertificate=5Ffile_failed!?= In-Reply-To: 20160913154548.GH4670@mournblade.imrryr.org References: <9b87f0cd-90a7-4a66-8f6a-68e5a0bfef21.zy_chongqing@aliyun.com> , 20160913154548.GH4670@mournblade.imrryr.org Message-ID: Only this one certificate, acutually this file is used for the iOS APNs function.the weird thing is, I use the same file and same code on other 2 server, it work well. That is really confused me.?------------------------------------------------------------------????Viktor Dukhovni ?????2016?9?13?(???) 23:46????openssl-users ????Re: [openssl-users] ??? [help]SSL_CTX_use_certificate_file failed! On?Tue,?Sep?13,?2016?at?10:53:57PM?+0800,?zy_chongqing?wrote: >?thanks?for?your?reply.?please?kindly?find?the?attached?to?get?the?certificate. Firstly,?you?posted?a?2048-bit?certificate,?which?would?not?normally fail?with?a?"key?too?small"?error,?other?than?by?failure?to?parse the?public?key. Secondly,?when?I?start?the?OpenSSL?1.1.0?s_server(1)?with?the?posted certificate?as?the?chain?file,?and?a?random?2048-bit?RSA?key?as the?key?file,?the?error?is?that?the?key?and?certificate?don't?match. This?means?that?at?least?s_server?*is*?able?to?parse?the?public key.??Are?there?some?other?certificates?in?the?chain?file,?in addition?to?the?leaf?certificate?you?posted???Please?post?all the?certificates?(but?not?the?private?key)?from?that?chain?file. ????$?openssl?genrsa?2048?>>?/tmp/cert.pem ????Generating?RSA?private?key,?2048?bit?long?modulus ????........................................................................+++ ????...............+++ ????e?is?65537?(0x010001) ????$?openssl?s_server?-cert?/tmp/cert.pem?-accept?12345 ????Using?default?temp?DH?parameters ????error?setting?private?key ????140735148003328:error:0B080074:x509?certificate?routines:X509_check_private_key:key?values?mismatch:../openssl/crypto/x509/x509_cmp.c:295: --? ?Viktor. --? openssl-users?mailing?list To?unsubscribe:?https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 13 16:02:19 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 13 Sep 2016 16:02:19 +0000 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIOWbnuWkje+8miBbaGVscF1T?= =?utf-8?q?SL=5FCTX=5Fuse=5Fcertificate=5Ffile_failed!?= In-Reply-To: References: <9b87f0cd-90a7-4a66-8f6a-68e5a0bfef21.zy_chongqing@aliyun.com> Message-ID: <20160913160219.GJ4670@mournblade.imrryr.org> On Tue, Sep 13, 2016 at 11:59:06PM +0800, zy_chongqing wrote: > Only this one certificate, acutually this file is used for the iOS APNs > function.the weird thing is, I use the same file and same code on other > 2 server, it work well. That is really confused me. Then perhaps the copy of the file on the problem server is corrupted somehow. Or the OpenSSL libraries on the problem server are damaged. I'm afraid you'll have to figure out how the servers differ. -- Viktor. From zy_chongqing at aliyun.com Tue Sep 13 16:37:56 2016 From: zy_chongqing at aliyun.com (zy_chongqing) Date: Wed, 14 Sep 2016 00:37:56 +0800 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIOWbnuWkje+8miDlm57lpI0=?= =?utf-8?b?77yaIFtoZWxwXVNTTF9DVFhfdXNlX2NlcnRpZmljYXRlX2ZpbGUgZmFpbGVk?= =?utf-8?q?!?= In-Reply-To: 20160913160219.GJ4670@mournblade.imrryr.org References: <9b87f0cd-90a7-4a66-8f6a-68e5a0bfef21.zy_chongqing@aliyun.com> , 20160913160219.GJ4670@mournblade.imrryr.org Message-ID: <22d7d1db-a575-4443-91cb-7cf2d1c70bd7.zy_chongqing@aliyun.com> thanks all! Finally I got it! the reason is that the libcrypto and libssl that I complie is not matched. oh my god! This issue took me 24 hours!?------------------------------------------------------------------????Viktor Dukhovni ?????2016?9?14?(???) 00:02????openssl-users ????Re: [openssl-users] ??? ??? [help]SSL_CTX_use_certificate_file failed! On?Tue,?Sep?13,?2016?at?11:59:06PM?+0800,?zy_chongqing?wrote: >?Only?this?one?certificate,?acutually?this?file?is?used?for?the?iOS?APNs >?function.the?weird?thing?is,?I?use?the?same?file?and?same?code?on?other >?2?server,?it?work?well.?That?is?really?confused?me. Then?perhaps?the?copy?of?the?file?on?the?problem?server?is?corrupted somehow.??Or?the?OpenSSL?libraries?on?the?problem?server?are?damaged. I'm?afraid?you'll?have?to?figure?out?how?the?servers?differ. --? ?Viktor. --? openssl-users?mailing?list To?unsubscribe:?https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.francis.jr at pobox.com Tue Sep 13 19:30:48 2016 From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.) Date: Tue, 13 Sep 2016 15:30:48 -0400 Subject: [openssl-users] SKM_ASN1_SET_OF_i2d Message-ID: What?s the replacement for code that used SKM_ASN1_SET_OF_i2d in OpenSSL 1.1? The code I?ve got that calls this function is getting the DER encoding of a STACK_OF() as a sorted SET. This STACK_OF() is of a custom ASN1 type; and is a member of another structure that is also a custom ASN1 structure. The call looks like this: int len = SKM_ASN1_SET_OF_i2d(structureName, containingStructure->member, NULL, i2d_structureName, V_ASN1_SET, V_ASN1_UNIVERSAL, IS_SET);* ?structureName? is the typedef?d name of the C struct, which was also passed to the DEFINE_STACK_OF() and DECLARE_ASN1_FUNCTIONS() macros (in OpenSSL < 1.1, it?s DECLARE_STACK_OF(), not DEFINE_STACK_OF() ). ?containingStructure? is a pointer to a C struct, and its member, ?member? is of the type, STACK_OF(structureName). Thanks! TOM * And later it?s called again with a valid pointer of size len instead of NULL for the third parameter, to actually obtain the DER encoding. From marek.svent at gmail.com Tue Sep 13 20:00:43 2016 From: marek.svent at gmail.com (Marek Svent) Date: Tue, 13 Sep 2016 23:00:43 +0300 Subject: [openssl-users] openssl-1.0.2i? Message-ID: Hi, 1.0.2h was released four months ago and although several security issues worth for CVE number is discovered in it and there has been a lot of commits in the 1.0.2 branch fixing other important issues, there is no sign of 1.0.2i. Is it planned? Or is 1.1.x focus for development now and 1.0.2 users should track a branch which should be treated as constantly stable now? Or ... ? -- Marek -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdmoore313 at outlook.com Tue Sep 13 20:22:06 2016 From: mdmoore313 at outlook.com (M. Moore) Date: Tue, 13 Sep 2016 16:22:06 -0400 Subject: [openssl-users] Unable to decrypt: RSA_R_PADDING_CHECK_FAILED 1.1.0 In-Reply-To: References: Message-ID: I'm creating a simple utility to encrypt and decrypt files using a key pair. I'm on Windows and coding against the 1.1.0 version of Openssl. I can load the key pair and encrypt the file fine, but when I try to decrypt EVP_PKEY_decrypt always returns -1. I traced this to the rsa padding check functions and they are returning -1 but I can't figure out why. I've tried changing the padding from RSA_PKCS1_OAEP_PADDING to RSA_PKCS1_PADDING and still have the same problem. Any insight would be appreciated, here are my encrypt and decrypt functions: #define FILE_BUFFER_LENGTH 1#define ENC_BUFFER_LENGTH 2048 int encryptfile(EVP_PKEY *key, FILE *srcfp, FILE *tgtfp) { EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new(key, NULL); char *inbuf; unsigned char *outbuf; size_t in_len = 0; size_t out_len = ENC_BUFFER_LENGTH; int x; inbuf = (char*)malloc(sizeof(char)*FILE_BUFFER_LENGTH+1); outbuf = (char*)malloc(sizeof(char)*ENC_BUFFER_LENGTH+1); if (ctx == NULL) { fprintf(stderr, "Error while creating encryption context.\n"); return 0; } if (EVP_PKEY_encrypt_init(ctx) <= 0) { fprintf(stderr, "Error while initializing encryption context.\n"); return 0; } if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) { fprintf(stderr, "Error while setting encryption padding.\n"); return 0; } while (1) { in_len = fread(inbuf, 1, FILE_BUFFER_LENGTH, srcfp); if (in_len == 0) {break;} if (EVP_PKEY_encrypt(ctx, outbuf, &out_len, inbuf, in_len) <= 0) { fprintf(stderr, "Error while encrypting data.\n"); return 0; } x = fwrite(outbuf, sizeof(char), in_len, tgtfp); if (x != in_len) { fprintf(stderr, "Error while writing to target file.\n"); return 0; } } return 1;} int decryptfile(EVP_PKEY *key, FILE *srcfp, FILE *tgtfp) { ENGINE *e = ENGINE_new(); EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new(key, NULL); unsigned char *inbuf; unsigned char *outbuf; size_t in_len = 0; size_t out_len = ENC_BUFFER_LENGTH; int x; inbuf = (char*)malloc(sizeof(char)*FILE_BUFFER_LENGTH + 1); outbuf = (char*)malloc(sizeof(char)*ENC_BUFFER_LENGTH + 1); if (ctx == NULL) { fprintf(stderr, "Error while creating decryption context.\n"); return 0; } if (EVP_PKEY_decrypt_init(ctx) <= 0) { fprintf(stderr, "Error while initializing decryption context.\n"); return 0; } if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) { fprintf(stderr, "Error while setting decryption padding.\n"); return 0; } while (1) { in_len = fread(inbuf, 1, FILE_BUFFER_LENGTH, srcfp); if (in_len == 0) { break; } if (EVP_PKEY_decrypt(ctx, outbuf, &out_len, inbuf, in_len) <= 0) { fprintf(stderr, "Error while decrypting data.\n"); return 0; } x = fwrite(outbuf, sizeof(char), in_len, tgtfp); if (x != in_len) { fprintf(stderr, "Error while writing decrypted data to target file.\n"); return 0; } } return 1;} -Mike M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Tue Sep 13 20:32:22 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 13 Sep 2016 20:32:22 +0000 Subject: [openssl-users] SKM_ASN1_SET_OF_i2d In-Reply-To: References: Message-ID: <20160913203222.GA23237@openssl.org> On Tue, Sep 13, 2016, Thomas Francis, Jr. wrote: > What???s the replacement for code that used SKM_ASN1_SET_OF_i2d in OpenSSL 1.1? The code I???ve got that calls this function is getting the DER encoding of a STACK_OF() as a sorted SET. This STACK_OF() is of a custom ASN1 type; and is a member of another structure that is also a custom ASN1 structure. > > The call looks like this: > > int len = SKM_ASN1_SET_OF_i2d(structureName, containingStructure->member, NULL, i2d_structureName, V_ASN1_SET, V_ASN1_UNIVERSAL, IS_SET);* > > > ???structureName??? is the typedef???d name of the C struct, which was also passed to the DEFINE_STACK_OF() and DECLARE_ASN1_FUNCTIONS() macros (in OpenSSL < 1.1, it???s DECLARE_STACK_OF(), not DEFINE_STACK_OF() ). > > ???containingStructure??? is a pointer to a C struct, and its member, ???member??? is of the type, STACK_OF(structureName). > There isn't a precise equivalent but it looks like you need an i2d function to encode as SET OF. You can do that. First you need a typedef for the STACK_OF something like: typedef STACK_OF(FOO) FOOS Then you create an ASN.1 ITEM template like this: ASN1_ITEM_TEMPLATE(FOOS) = ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SET_OF, 0, foos, FOO) ASN1_ITEM_TEMPLATE_END(FOOS) You then add IMPLEMENT_ASN1_FUNCTIONS(FOOS) and DECLARE_ASN1_FUINCTION(FOOS). This will produce new functions i2d_FOOS, d2i_FOOS, FOOS_new() and FOOS_free() which should do what you want. If you don't want the new/free ones you can use IMPLEMENT_ASN1_ENCODE_FUNCTIONS instead. This is used in OpenSSL in a few places such as the implementation of GeneralNames which is a SEQUENCE_OF GeneralName. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From matt at openssl.org Wed Sep 14 08:25:12 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Sep 2016 09:25:12 +0100 Subject: [openssl-users] openssl-1.0.2i? In-Reply-To: References: Message-ID: <3e9cf5a0-ed74-380a-a424-5dcf57a4ac58@openssl.org> On 13/09/16 21:00, Marek Svent wrote: > Hi, > > 1.0.2h was released four months ago and although several security issues > worth for CVE number is discovered in it and there has been a lot of > commits in the 1.0.2 branch fixing other important issues, there is no > sign of 1.0.2i. Is it planned? Or is 1.1.x focus for development now and > 1.0.2 users should track a branch which should be treated as constantly > stable now? Or ... ? 1.0.2 is our Long Term Support branch and continues to be supported. See this page for our support details: https://www.openssl.org/policies/releasestrat.html WRT a new release of 1.0.2, typically we will only do a new release if a high severity security issue is discovered (or occasionally if there is a significant bug fix). Low severity defects are published immediately in git and are made available as part of the next release whenever that might happen. In other words, new releases are scheduled on an "as needed" basis as and when high severity defects are discovered and are typically announced a few days in advance of the release. Matt From wouter.verhelst at fedict.be Wed Sep 14 12:31:22 2016 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Wed, 14 Sep 2016 14:31:22 +0200 Subject: [openssl-users] openssl crl fails to parse a CRL file, which seems correct Message-ID: Hi, (this is a resend because my MUA crashed while I tried to send this mail earlier. If you get it twice, my apologies) When I try to parse some of the CRLs at , I sometimes get this error: wouter at gangtai:~$ openssl version OpenSSL 1.0.2h 3 May 2016 wouter at gangtai:~$ openssl crl -in eidc201203.crl -inform der -noout -text unable to load CRL 140694432685592:error:0D09E09B:asn1 encoding routines:X509_NAME_EX_D2I:too long:x_name.c:203: 140694432685592:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:697:Field=issuer, Type=X509_CRL_INFO 140694432685592:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:697:Field=crl, Type=X509_CRL This isn't the case for all of the CRLs, just for some of them; e.g., everything works fine for eidc201503.crl However, if I try the same on another machine nearby, which has a much older version of OpenSSL, then things seem to work fine: eidmac:~ buildslave$ openssl version OpenSSL 0.9.8zh 14 Jan 2016 eidmac:~ buildslave$ openssl crl -in eidc201203.crl -inform der -noout -text | head Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: /C=BE/CN=Citizen CA/serialNumber=201203 Last Update: Sep 14 10:22:50 2016 GMT Next Update: Sep 21 10:22:50 2016 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:7A:5F:3A:FF:2D:46:91:90:53:3F:BB:91:2D:29:82:ED:BB:78:6A:E0 This machine is a mac running OSX 10.11, the OpenSSL is the default as shipped with that OS; the other is my personal laptop, which runs Debian unstable (and the openssl is again the default). I've reproduced the same issue on Debian stable, haven't tried much else yet. I've been trying to figure out why my OpenSSL fails to parse the CRL, whereas others do not,. Any hints would be greatly appreciated. Thanks, -- Wouter Verhelst From alexhultman at gmail.com Thu Sep 15 03:07:22 2016 From: alexhultman at gmail.com (Alex Hultman) Date: Thu, 15 Sep 2016 05:07:22 +0200 Subject: [openssl-users] SSL_read, SSL_write error handling Message-ID: If SSL_write returns the error SSL_ERROR_WANT_READ, am I then allowed to call SSL_read before I have called SSL_write? What I'm trying to figure out is, can I handle SSL_ERROR_WANT_READ with one or many calls to SSL_read, and can I handle SSL_ERROR_WANT_WRITE with one or many calls to SSL_write - despite the fact that the error was thrown by the opposite SSL_* function call? Does an SSL_ERROR_WANT_READ have to be handled by the SSL_* function that caused the error, or will any of the two (SSL_read, SSL_write) functions handle this desire? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Sep 15 05:01:30 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 15 Sep 2016 05:01:30 +0000 Subject: [openssl-users] SSL_read, SSL_write error handling In-Reply-To: References: Message-ID: <20160915050130.GC4670@mournblade.imrryr.org> On Thu, Sep 15, 2016 at 05:07:22AM +0200, Alex Hultman wrote: > If SSL_write returns the error SSL_ERROR_WANT_READ, am I then allowed to > call SSL_read before I have called SSL_write? WANT_READ means that OpenSSL *internally* needs to read some (often ciphertext) bytes from the peer, and that since the socket is non-blocking or you're using BIO_pairs, ... the application must wait for data to arrive (poll(), select(), ...) and then retry the call once the socket becomes readable. It is not an invitation to read *application* layer data, which would typically also fail for lack anything to read at that moment. * WANT_READ -- Select the socket for read, and retry the original function (hanshake, read or write) once the socket is readable. * WANT_READ -- Select the socket for write, and retry the original function (hanshake, read or write) once the socket becomes writable. Again, these are not a request for the application to *consume* data, rather the application needs to retry once the socket is ready for the requested operation. OpenSSL will internally read or write to the socket. -- Viktor. From alexhultman at gmail.com Thu Sep 15 05:18:52 2016 From: alexhultman at gmail.com (Alex Hultman) Date: Thu, 15 Sep 2016 07:18:52 +0200 Subject: [openssl-users] SSL_read, SSL_write error handling In-Reply-To: <20160915050130.GC4670@mournblade.imrryr.org> References: <20160915050130.GC4670@mournblade.imrryr.org> Message-ID: I did find a very good explanation here: https://mta.openssl.org/pipermail/openssl-users/2015-March/000709.html The idea of "what SSL wants" and "what the app wants" is a very good explanation. This is the pseudocode I'm working with currently: io_callback(events) { if (messages_to_send && (events & OS_WRITABLE)) { SSL_write(.....); if (error) { if (error_is_want_read) { system_poll &= OS_READABLE; } else if (error_is_want_write) { system_poll &= OS_WRITABLE; } update_os_poll(system_poll); return; } else { // emit send success to app } } else if (app_wants_data && (events & OS_READABLE)) { SSL_read(.....); if (error) { if (error_is_want_read) { system_poll &= OS_READABLE; } else if (error_is_want_write) { system_poll &= OS_WRITABLE; } update_os_poll(system_poll); return; } else { // emit the data to app } } } This code is probably not 100% correct, but should show my design pretty clear. One needs to do what YOU want, combined with what SSL wants. However, question still remains - it is ALLOWED to perform SSL_read before SSL_write, when a previous call to SSL_write failed with WANT_READ? 2016-09-15 7:01 GMT+02:00 Viktor Dukhovni : > On Thu, Sep 15, 2016 at 05:07:22AM +0200, Alex Hultman wrote: > > > If SSL_write returns the error SSL_ERROR_WANT_READ, am I then allowed to > > call SSL_read before I have called SSL_write? > > WANT_READ means that OpenSSL *internally* needs to read some (often > ciphertext) bytes from the peer, and that since the socket is > non-blocking or you're using BIO_pairs, ... the application must > wait for data to arrive (poll(), select(), ...) and then retry > the call once the socket becomes readable. > > It is not an invitation to read *application* layer data, which > would typically also fail for lack anything to read at that > moment. > > * WANT_READ -- Select the socket for read, and retry > the original function (hanshake, read or write) once > the socket is readable. > > * WANT_READ -- Select the socket for write, and retry > the original function (hanshake, read or write) once > the socket becomes writable. > > Again, these are not a request for the application to *consume* > data, rather the application needs to retry once the socket is > ready for the requested operation. OpenSSL will internally > read or write to the socket. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.grasman at gmail.com Thu Sep 15 10:17:12 2016 From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=) Date: Thu, 15 Sep 2016 12:17:12 +0200 Subject: [openssl-users] Customize Windows library names Message-ID: Hi all, I'm looking at integrating OpenSSL 1.1 in our tree, and I noticed the Windows build system now produces decorated lib names. The general pattern seems to be lib_[-].lib where is only appended for 64-bit builds. We'd prefer a naked lib name, at least for import libs (the DLL names are not important to us, as long as the import lib binds to the right name). Is there a supported way of dumbing down the names of libcrypto and libssl? I can resort to a private patch, but it'd be nice if Configure could be convinced to keep it simple out of the box. Thanks, - Kim From Erwann.Abalea at docusign.com Thu Sep 15 09:18:06 2016 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Thu, 15 Sep 2016 09:18:06 +0000 Subject: [openssl-users] openssl crl fails to parse a CRL file, which seems correct In-Reply-To: References: Message-ID: <691B7018-392D-4C11-9FED-F9B275C7260A@docusign.com> That?s a bug in the Issuer name length check. Use the 1.1.0 version. Cordialement, Erwann Abalea > Le 14 sept. 2016 ? 14:31, Wouter Verhelst a ?crit : > > Hi, > > (this is a resend because my MUA crashed while I tried to send this mail earlier. If you get it twice, my apologies) > > When I try to parse some of the CRLs at , I sometimes get this error: > > wouter at gangtai:~$ openssl version > OpenSSL 1.0.2h 3 May 2016 > wouter at gangtai:~$ openssl crl -in eidc201203.crl -inform der -noout -text > unable to load CRL > 140694432685592:error:0D09E09B:asn1 encoding routines:X509_NAME_EX_D2I:too long:x_name.c:203: > 140694432685592:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:697:Field=issuer, Type=X509_CRL_INFO > 140694432685592:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:697:Field=crl, Type=X509_CRL > > This isn't the case for all of the CRLs, just for some of them; e.g., everything works fine for eidc201503.crl > > However, if I try the same on another machine nearby, which has a much older version of OpenSSL, then things seem to work fine: > > eidmac:~ buildslave$ openssl version > OpenSSL 0.9.8zh 14 Jan 2016 > eidmac:~ buildslave$ openssl crl -in eidc201203.crl -inform der -noout -text | head > Certificate Revocation List (CRL): > Version 2 (0x1) > Signature Algorithm: sha1WithRSAEncryption > Issuer: /C=BE/CN=Citizen CA/serialNumber=201203 > Last Update: Sep 14 10:22:50 2016 GMT > Next Update: Sep 21 10:22:50 2016 GMT > CRL extensions: > X509v3 Authority Key Identifier: > keyid:7A:5F:3A:FF:2D:46:91:90:53:3F:BB:91:2D:29:82:ED:BB:78:6A:E0 > > This machine is a mac running OSX 10.11, the OpenSSL is the default as shipped with that OS; the other is my personal laptop, which runs Debian unstable (and the openssl is again the default). I've reproduced the same issue on Debian stable, haven't tried much else yet. > > I've been trying to figure out why my OpenSSL fails to parse the CRL, whereas others do not,. Any hints would be greatly appreciated. > > Thanks, > > -- > Wouter Verhelst > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From sivagopi059 at gmail.com Thu Sep 15 10:44:59 2016 From: sivagopi059 at gmail.com (sivagopiraju) Date: Thu, 15 Sep 2016 03:44:59 -0700 (MST) Subject: [openssl-users] CVE-2016-2180 In-Reply-To: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1473936299031-68371.post@n7.nabble.com> I can't upgrade at this stage for my product, So can you give me the fix if you have. -- View this message in context: http://openssl.6102.n7.nabble.com/CVE-2016-2180-tp67815p68371.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From shinelight at shininglightpro.com Thu Sep 15 14:26:08 2016 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Thu, 15 Sep 2016 07:26:08 -0700 Subject: [openssl-users] Customize Windows library names In-Reply-To: References: Message-ID: On 9/15/2016 3:17 AM, Kim Gr?sman wrote: > Hi all, > > I'm looking at integrating OpenSSL 1.1 in our tree, and I noticed the > Windows build system now produces decorated lib names. > > The general pattern seems to be lib_[-].lib where > is only appended for 64-bit builds. > > We'd prefer a naked lib name, at least for import libs (the DLL names > are not important to us, as long as the import lib binds to the right > name). > > Is there a supported way of dumbing down the names of libcrypto and > libssl? I can resort to a private patch, but it'd be nice if Configure > could be convinced to keep it simple out of the box. > > Thanks, > - Kim The precompiled binary installer variants do this already. If you are using default builds, then that's possibly an option. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From kim.grasman at gmail.com Thu Sep 15 15:17:32 2016 From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=) Date: Thu, 15 Sep 2016 17:17:32 +0200 Subject: [openssl-users] Customize Windows library names In-Reply-To: References: Message-ID: Hi Thomas, On Thu, Sep 15, 2016 at 4:26 PM, Thomas J. Hruska wrote: > > The precompiled binary installer variants do this already. If you are using > default builds, then that's possibly an option. We prefer to build from source to allow static and dynamic code analysis, for example. But do you have a link to these precompiled binary installers? Do you know how they accomplish plain names? Thanks, - Kim From openssl-users at dukhovni.org Thu Sep 15 16:15:33 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 15 Sep 2016 16:15:33 +0000 Subject: [openssl-users] SSL_read, SSL_write error handling In-Reply-To: References: <20160915050130.GC4670@mournblade.imrryr.org> Message-ID: <20160915161533.GJ4670@mournblade.imrryr.org> On Thu, Sep 15, 2016 at 07:18:52AM +0200, Alex Hultman wrote: > io_callback(events) { > if (messages_to_send && (events & OS_WRITABLE)) { > SSL_write(.....); > if (error) { > if (error_is_want_read) { > system_poll &= OS_READABLE; > } else if (error_is_want_write) { > system_poll &= OS_WRITABLE; > } For what it's worth, you probably meant "|=" not "&=". -- Viktor. From chad at apartmentlines.com Thu Sep 15 16:55:10 2016 From: chad at apartmentlines.com (Chad Phillips) Date: Thu, 15 Sep 2016 09:55:10 -0700 Subject: [openssl-users] Seeking consultant Message-ID: Wondering if anyone can recommend a consultant. I'm having a very specific problem with a lower-level WebRTC library that I'm unable to fix myself. I have plenty of debugging information, and am pretty sure it's due to an improperly handled DTLS handshake failure. Ideally, it would be someone who can do a one-off contract, and have the work complete within a week. Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Saurabh.Gupta at cavium.com Thu Sep 15 12:41:58 2016 From: Saurabh.Gupta at cavium.com (Gupta, Saurabh) Date: Thu, 15 Sep 2016 12:41:58 +0000 Subject: [openssl-users] Openssl-1.0.1e RSA 8k is getting fail for client authentication while doing Normal Handshake Message-ID: Commands Used: x86_server: openssl s_server -cert sercert8192.pem -key serverkey8192 -Verify CAcert.pem x86_client: openssl s_client -cert clientcert8192.pem -key clientkey8192 -connect : -cipher AES128-SHA - Error log: x86( Server): verify error:unable to verify the first certificate x86 (Client): 140631662409384:error:14094417:SSL routines:SSL3_READ_BYTES:sslv3 alert illegal parameter:s3_pkt.c:1256:SSL alert number 47 140631662409384:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: Do we need to enable any flag to access 8k support? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Sep 15 20:54:09 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Sep 2016 21:54:09 +0100 Subject: [openssl-users] CVE-2016-2180 In-Reply-To: <1473936299031-68371.post@n7.nabble.com> References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> Message-ID: <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> On 15/09/16 11:44, sivagopiraju wrote: > I can't upgrade at this stage for my product, So can you give me the fix if > you have. The fix for the 1.0.1 version is here: https://github.com/openssl/openssl/commit/6adf409c7432b90c06d9890787fe56c48f2a16e7 As Rich said 1.0.0 is not supported so the fix has not been backported to that version. Matt From levitte at openssl.org Thu Sep 15 22:08:16 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 16 Sep 2016 00:08:16 +0200 (CEST) Subject: [openssl-users] Customize Windows library names In-Reply-To: References: Message-ID: <20160916.000816.1687354205337324975.levitte@openssl.org> In message on Thu, 15 Sep 2016 12:17:12 +0200, Kim Gr?sman said: kim.grasman> I'm looking at integrating OpenSSL 1.1 in our tree, and I noticed the kim.grasman> Windows build system now produces decorated lib names. For DLLs, yes. kim.grasman> The general pattern seems to be lib_[-].lib where kim.grasman> is only appended for 64-bit builds. Are you sure? Looking at my builds, I find libcrypto-1_1.dll and libssl-1_1.dll with the import libraries libcrypto.lib and libssl.lib. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jb-openssl at wisemo.com Thu Sep 15 22:12:30 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 16 Sep 2016 00:12:30 +0200 Subject: [openssl-users] Customize Windows library names In-Reply-To: <20160916.000816.1687354205337324975.levitte@openssl.org> References: <20160916.000816.1687354205337324975.levitte@openssl.org> Message-ID: <1446abd3-1599-24fe-1340-fc7f3da5e6c1@wisemo.com> On 16/09/2016 00:08, Richard Levitte wrote: > In message on Thu, 15 Sep 2016 12:17:12 +0200, Kim Gr?sman said: > > kim.grasman> I'm looking at integrating OpenSSL 1.1 in our tree, and I noticed the > kim.grasman> Windows build system now produces decorated lib names. > > For DLLs, yes. > > kim.grasman> The general pattern seems to be lib_[-].lib where > kim.grasman> is only appended for 64-bit builds. > > Are you sure? Looking at my builds, I find libcrypto-1_1.dll and > libssl-1_1.dll with the import libraries libcrypto.lib and > libssl.lib. On 64 bit too? (see OP). 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 levitte at openssl.org Thu Sep 15 22:24:33 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 16 Sep 2016 00:24:33 +0200 (CEST) Subject: [openssl-users] Customize Windows library names In-Reply-To: <1446abd3-1599-24fe-1340-fc7f3da5e6c1@wisemo.com> References: <20160916.000816.1687354205337324975.levitte@openssl.org> <1446abd3-1599-24fe-1340-fc7f3da5e6c1@wisemo.com> Message-ID: <20160916.002433.1657820010061794424.levitte@openssl.org> In message <1446abd3-1599-24fe-1340-fc7f3da5e6c1 at wisemo.com> on Fri, 16 Sep 2016 00:12:30 +0200, Jakob Bohm said: jb-openssl> On 16/09/2016 00:08, Richard Levitte wrote: jb-openssl> > In message jb-openssl> > jb-openssl> > on Thu, 15 Sep 2016 12:17:12 +0200, Kim Gr?sman jb-openssl> > said: jb-openssl> > jb-openssl> > kim.grasman> I'm looking at integrating OpenSSL 1.1 in our tree, and I jb-openssl> > noticed the jb-openssl> > kim.grasman> Windows build system now produces decorated lib names. jb-openssl> > jb-openssl> > For DLLs, yes. jb-openssl> > jb-openssl> > kim.grasman> The general pattern seems to be jb-openssl> > lib_[-].lib where jb-openssl> > kim.grasman> is only appended for 64-bit builds. jb-openssl> > jb-openssl> > Are you sure? Looking at my builds, I find libcrypto-1_1.dll and jb-openssl> > libssl-1_1.dll with the import libraries libcrypto.lib and jb-openssl> > libssl.lib. jb-openssl> On 64 bit too? (see OP). Yup. The decoration is only supposed to happen on the DLL names. That's exactly what the following lines in the top build.info does: SHARED_NAME[libcrypto]=libcrypto-{- $config{shlib_major}."_".$config{shlib_minor} -}{- $target{multilib} -} SHARED_NAME[libssl]=libssl-{- $config{shlib_major}."_".$config{shlib_minor} -}{- $target{multilib} -} For the import libs, the static names (the 'index' of SHARED_NAME) are used. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From sivagopi059 at gmail.com Fri Sep 16 04:00:07 2016 From: sivagopi059 at gmail.com (sivagopiraju) Date: Thu, 15 Sep 2016 21:00:07 -0700 (MST) Subject: [openssl-users] CVE-2016-2180 In-Reply-To: <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> Message-ID: <1473998407592-68384.post@n7.nabble.com> - int len = OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0); - BIO_write(bio, obj_txt, len); - BIO_write(bio, "\n", 1); + OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0); + BIO_printf(bio, "%s\n", obj_txt); Here, used BIO_printf instead of BIO_write, is it solve the issue? Can you please elaborate it, did't understand the solution. -- View this message in context: http://openssl.6102.n7.nabble.com/CVE-2016-2180-tp67815p68384.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From shinelight at shininglightpro.com Fri Sep 16 05:24:44 2016 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Thu, 15 Sep 2016 22:24:44 -0700 Subject: [openssl-users] Customize Windows library names In-Reply-To: References: Message-ID: <6832508c-c0ea-89bd-6130-5c568fb67ff1@shininglightpro.com> On 9/15/2016 8:17 AM, Kim Gr?sman wrote: > Hi Thomas, > > On Thu, Sep 15, 2016 at 4:26 PM, Thomas J. Hruska > wrote: >> >> The precompiled binary installer variants do this already. If you are using >> default builds, then that's possibly an option. > > We prefer to build from source to allow static and dynamic code > analysis, for example. > > But do you have a link to these precompiled binary installers? Do you > know how they accomplish plain names? > > Thanks, > - Kim https://slproweb.com/products/Win32OpenSSL.html As to how: A batch file with a set of 'copy' commands ;) -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From guru at unixarea.de Fri Sep 16 06:33:25 2016 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 16 Sep 2016 08:33:25 +0200 Subject: [openssl-users] CVE-2016-2180 In-Reply-To: <1473998407592-68384.post@n7.nabble.com> References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> <1473998407592-68384.post@n7.nabble.com> Message-ID: <20160916063325.GA1903@c720-r292778-amd64> El d?a Thursday, September 15, 2016 a las 09:00:07PM -0700, sivagopiraju escribi?: > - int len = OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0); > - BIO_write(bio, obj_txt, len); > - BIO_write(bio, "\n", 1); > + OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0); > + BIO_printf(bio, "%s\n", obj_txt); > > Here, used BIO_printf instead of BIO_write, is it solve the issue? > > Can you please elaborate it, did't understand the solution. The man page for OBJ_obj2txt() says what the function is doing and what the parms are used for or must be, but does not specify what its return value is, only that it is 'int'. Maybe it does not return the length of the resulting string. matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 "Ohne die Mauer h?tte es Krieg gegeben" Fritz Streletz u.a. "Sin el Muro hubiese habido guerra." From sivagopi059 at gmail.com Fri Sep 16 05:35:34 2016 From: sivagopi059 at gmail.com (sivagopiraju) Date: Thu, 15 Sep 2016 22:35:34 -0700 (MST) Subject: [openssl-users] CVE-2016-2180 In-Reply-To: <20160916063325.GA1903@c720-r292778-amd64> References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> <1473998407592-68384.post@n7.nabble.com> <20160916063325.GA1903@c720-r292778-amd64> Message-ID: <1474004134134-68387.post@n7.nabble.com> int OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name); OBJ_obj2txt() converts the ASN1_OBJECT a into a textual representation. The representation is written as a null terminated string to buf at most buf_len bytes are written, truncating the result if necessary.* The total amount of space required is returned*. If no_name is 0 then if the object has a long or short name then that will be used, otherwise the numerical form will be used. If no_name is 1 then the numerical form will always be used. Above statement statement saying that *amount of space required is returned*. Matthias Apitz-4 wrote > El d?a Thursday, September 15, 2016 a las 09:00:07PM -0700, sivagopiraju > escribi?: > >> - int len = OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0); >> - BIO_write(bio, obj_txt, len); >> - BIO_write(bio, "\n", 1); >> + OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0); >> + BIO_printf(bio, "%s\n", obj_txt); >> >> Here, used BIO_printf instead of BIO_write, is it solve the issue? >> >> Can you please elaborate it, did't understand the solution. > > The man page for OBJ_obj2txt() says what the function is doing and what > the parms are used for or must be, but does not specify what its return > value is, only that it is 'int'. Maybe it does not return the length of > the resulting string. > > matthias > -- > Matthias Apitz, ? > guru@ > , ? http://www.unixarea.de/ ? +49-176-38902045 > "Ohne die Mauer h?tte es Krieg gegeben" Fritz Streletz u.a. > "Sin el Muro hubiese habido guerra." > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users *Maybe it does not return the length of the resulting string. * It mean return value causing the issue. -- View this message in context: http://openssl.6102.n7.nabble.com/CVE-2016-2180-tp67815p68387.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From guru at unixarea.de Fri Sep 16 07:05:17 2016 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 16 Sep 2016 09:05:17 +0200 Subject: [openssl-users] CVE-2016-2180 In-Reply-To: <1474004134134-68387.post@n7.nabble.com> References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> <1473998407592-68384.post@n7.nabble.com> <20160916063325.GA1903@c720-r292778-amd64> <1474004134134-68387.post@n7.nabble.com> Message-ID: <20160916070517.GA2220@c720-r292778-amd64> El d?a Thursday, September 15, 2016 a las 10:35:34PM -0700, sivagopiraju escribi?: > int OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name); > > OBJ_obj2txt() converts the ASN1_OBJECT a into a textual representation. The > representation is written as a null terminated string to buf at most buf_len > bytes are written, truncating the result if necessary.* The total amount of > space required is returned*. If no_name is 0 then if the object has a long > or short name then that will be used, otherwise the numerical form will be > used. If no_name is 1 then the numerical form will always be used. > > Above statement statement saying that *amount of space required is > returned*. I saw this, but 'amount of space required' is IMHO vague, I'd expect 'the length of the resulting string is returned' matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 "Ohne die Mauer h?tte es Krieg gegeben" Fritz Streletz u.a. "Sin el Muro hubiese habido guerra." From kim.grasman at gmail.com Fri Sep 16 07:43:37 2016 From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=) Date: Fri, 16 Sep 2016 09:43:37 +0200 Subject: [openssl-users] Customize Windows library names In-Reply-To: <20160916.000816.1687354205337324975.levitte@openssl.org> References: <20160916.000816.1687354205337324975.levitte@openssl.org> Message-ID: Hi Richard, On Fri, Sep 16, 2016 at 12:08 AM, Richard Levitte wrote: > In message on Thu, 15 Sep 2016 12:17:12 +0200, Kim Gr?sman said: > > kim.grasman> I'm looking at integrating OpenSSL 1.1 in our tree, and I noticed the > kim.grasman> Windows build system now produces decorated lib names. > > For DLLs, yes. > > kim.grasman> The general pattern seems to be lib_[-].lib where > kim.grasman> is only appended for 64-bit builds. > > Are you sure? Looking at my builds, I find libcrypto-1_1.dll and > libssl-1_1.dll with the import libraries libcrypto.lib and > libssl.lib. Ahem. I *was* sure, but with a clean build, I can see you're absolutely right. I must have mixed up the DLL names and import lib names at some point. Sorry about the confusion! - Kim From matt at openssl.org Fri Sep 16 07:57:30 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 16 Sep 2016 08:57:30 +0100 Subject: [openssl-users] CVE-2016-2180 In-Reply-To: <20160916070517.GA2220@c720-r292778-amd64> References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> <1473998407592-68384.post@n7.nabble.com> <20160916063325.GA1903@c720-r292778-amd64> <1474004134134-68387.post@n7.nabble.com> <20160916070517.GA2220@c720-r292778-amd64> Message-ID: On 16/09/16 08:05, Matthias Apitz wrote: > El d?a Thursday, September 15, 2016 a las 10:35:34PM -0700, sivagopiraju escribi?: > >> int OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name); >> >> OBJ_obj2txt() converts the ASN1_OBJECT a into a textual representation. The >> representation is written as a null terminated string to buf at most buf_len >> bytes are written, truncating the result if necessary.* The total amount of >> space required is returned*. If no_name is 0 then if the object has a long >> or short name then that will be used, otherwise the numerical form will be >> used. If no_name is 1 then the numerical form will always be used. >> >> Above statement statement saying that *amount of space required is >> returned*. > > I saw this, but 'amount of space required' is IMHO vague, I'd expect > 'the length of the resulting string is returned' That is the heart of the problem. OBJ_obj2txt() does not return what you might expect. The author of TS_OBJ_print_bio() expected it to return the length of the resulting string (as you do). However OBJ_obj2txt() might truncate what it would otherwise produce if the supplied buffer isn't big enough - but it still returns the length of the untruncated string. The implementation of TS_OBJ_print_bio() used BIO_write() to print the string, using the untruncated string length. This is obviously wrong and could cause an out-of-bounds read. By swapping to BIO_printf() this is avoided because it only prints the string until it hits the NUL terminator which should always be within the bounds of the supplied buffer. Matt From levitte at openssl.org Fri Sep 16 08:09:10 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 16 Sep 2016 10:09:10 +0200 (CEST) Subject: [openssl-users] Customize Windows library names In-Reply-To: References: <20160916.000816.1687354205337324975.levitte@openssl.org> Message-ID: <20160916.100910.708688490866934306.levitte@openssl.org> In message on Fri, 16 Sep 2016 09:43:37 +0200, Kim Gr?sman said: kim.grasman> Hi Richard, kim.grasman> kim.grasman> On Fri, Sep 16, 2016 at 12:08 AM, Richard Levitte wrote: kim.grasman> > In message on Thu, 15 Sep 2016 12:17:12 +0200, Kim Gr?sman said: kim.grasman> > kim.grasman> > kim.grasman> I'm looking at integrating OpenSSL 1.1 in our tree, and I noticed the kim.grasman> > kim.grasman> Windows build system now produces decorated lib names. kim.grasman> > kim.grasman> > For DLLs, yes. kim.grasman> > kim.grasman> > kim.grasman> The general pattern seems to be lib_[-].lib where kim.grasman> > kim.grasman> is only appended for 64-bit builds. kim.grasman> > kim.grasman> > Are you sure? Looking at my builds, I find libcrypto-1_1.dll and kim.grasman> > libssl-1_1.dll with the import libraries libcrypto.lib and kim.grasman> > libssl.lib. kim.grasman> kim.grasman> Ahem. I *was* sure, but with a clean build, I can see you're absolutely right. kim.grasman> kim.grasman> I must have mixed up the DLL names and import lib names at some point. kim.grasman> kim.grasman> Sorry about the confusion! That's for confirming. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From sivagopi059 at gmail.com Fri Sep 16 07:09:30 2016 From: sivagopi059 at gmail.com (sivagopiraju) Date: Fri, 16 Sep 2016 00:09:30 -0700 (MST) Subject: [openssl-users] CVE-2016-2180 In-Reply-To: References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> <1473998407592-68384.post@n7.nabble.com> <20160916063325.GA1903@c720-r292778-amd64> <1474004134134-68387.post@n7.nabble.com> <20160916070517.GA2220@c720-r292778-amd64> Message-ID: <1474009770560-68392.post@n7.nabble.com> And a small understanding. We are supplying buffer is about to 128 bytes to fill the converted message, So, if the obj(ASN1_OBJECT) size is more than that(supplied buffer) size OBJ_obj2txt will do truncate and will return the obj(ASN1_OBJECT) message length. It results in more than 128(returned length) bytes. Because of this crash is happening. (or) In which scenario the OBJ_obj2txt() truncates the supplied message. -- View this message in context: http://openssl.6102.n7.nabble.com/CVE-2016-2180-tp67815p68392.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From matt at openssl.org Fri Sep 16 09:04:19 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 16 Sep 2016 10:04:19 +0100 Subject: [openssl-users] CVE-2016-2180 In-Reply-To: <1474009770560-68392.post@n7.nabble.com> References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> <1473998407592-68384.post@n7.nabble.com> <20160916063325.GA1903@c720-r292778-amd64> <1474004134134-68387.post@n7.nabble.com> <20160916070517.GA2220@c720-r292778-amd64> <1474009770560-68392.post@n7.nabble.com> Message-ID: On 16/09/16 08:09, sivagopiraju wrote: > And a small understanding. > > We are supplying buffer is about to 128 bytes to fill the converted message, > So, if the obj(ASN1_OBJECT) size is more than that(supplied buffer) size > OBJ_obj2txt will do truncate and will return the obj(ASN1_OBJECT) message > length. It results in more than 128(returned length) bytes. Because of this > crash is happening. Yes. If OBJ_obj2txt() would normally supply a string of length (say) 256 bytes, then it will truncate it (with a NUL terminator) into the supplied 128 byte buffer. It will still return a value of 256 though. Then when we call BIO_write() we tell it to write 256 bytes from the 128 byte buffer == Out-of-bounds read. This could mean a crash, or writing arbitrary memory contents to the BIO. By using BIO_printf() instead we only print the string up to the NUL terminator which should always be within the 128 byte buffer. Matt From guru at unixarea.de Fri Sep 16 08:27:44 2016 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 16 Sep 2016 10:27:44 +0200 Subject: [openssl-users] CVE-2016-2180 In-Reply-To: References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> <1473998407592-68384.post@n7.nabble.com> <20160916063325.GA1903@c720-r292778-amd64> <1474004134134-68387.post@n7.nabble.com> <20160916070517.GA2220@c720-r292778-amd64> Message-ID: <20160916082744.GA1808@sh4-5.1blu.de> El d?a Friday, September 16, 2016 a las 08:57:30AM +0100, Matt Caswell escribi?: > >> int OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name); > >> > >> OBJ_obj2txt() converts the ASN1_OBJECT a into a textual representation. The > >> representation is written as a null terminated string to buf at most buf_len > >> bytes are written, truncating the result if necessary.* The total amount of > >> space required is returned*. If no_name is 0 then if the object has a long > >> or short name then that will be used, otherwise the numerical form will be > >> used. If no_name is 1 then the numerical form will always be used. > >> > >> Above statement statement saying that *amount of space required is > >> returned*. > > > > I saw this, but 'amount of space required' is IMHO vague, I'd expect > > 'the length of the resulting string is returned' > > That is the heart of the problem. OBJ_obj2txt() does not return what you > might expect. The author of TS_OBJ_print_bio() expected it to return the > length of the resulting string (as you do). However OBJ_obj2txt() might > truncate what it would otherwise produce if the supplied buffer isn't > big enough - but it still returns the length of the untruncated string. > > ... I would even suggest to change the wording in the man page to: "... representation is written as a null terminated string to buf at most buf_len bytes are written, INCLUDING THE NULL BYTE, truncating the result ..." -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru at unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-176-38902045 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From sivagopi059 at gmail.com Fri Sep 16 08:14:15 2016 From: sivagopi059 at gmail.com (sivagopiraju) Date: Fri, 16 Sep 2016 01:14:15 -0700 (MST) Subject: [openssl-users] CVE-2016-2180 In-Reply-To: References: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> <1473936299031-68371.post@n7.nabble.com> <7b0ae81f-d0ee-26d2-db19-654e7c4fe488@openssl.org> <1473998407592-68384.post@n7.nabble.com> <20160916063325.GA1903@c720-r292778-amd64> <1474004134134-68387.post@n7.nabble.com> <20160916070517.GA2220@c720-r292778-amd64> <1474009770560-68392.post@n7.nabble.com> Message-ID: <1474013655551-68395.post@n7.nabble.com> Thanks for the answers, I am going to change BIO_write to BIO_printf in my product for openssl. And finally one question, NULL terminator is surely within the 128 bytes of buffer? regards, Gopi. -- View this message in context: http://openssl.6102.n7.nabble.com/CVE-2016-2180-tp67815p68395.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From chad at apartmentlines.com Fri Sep 16 18:47:35 2016 From: chad at apartmentlines.com (Chad Phillips) Date: Fri, 16 Sep 2016 11:47:35 -0700 Subject: [openssl-users] How to handle DTLS Certificate Reassembly Error Message-ID: I?m using a support library leveraging openssl to complete a DTLS handshake. Occasionally, I?ll see in my packet captures that a handshake has failed with a ?Certificate reassembly error?, and the support library doesn?t seem to be catching this properly to forward the error on. The library developers are considering handling this using a timeout solution ? triggering an error if the handshake doesn?t complete in a specified amount of time, but this feels a bit clunky to me. What?s the recommended way to get this information from openssl in this case? For reference, I?m attaching a packet capture that illustrates two of the handshake failures. Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dtls-failures.pcap Type: application/octet-stream Size: 7354 bytes Desc: not available URL: From matt at openssl.org Sat Sep 17 00:07:07 2016 From: matt at openssl.org (Matt Caswell) Date: Sat, 17 Sep 2016 01:07:07 +0100 Subject: [openssl-users] How to handle DTLS Certificate Reassembly Error In-Reply-To: References: Message-ID: <141f8f96-6cf2-88ef-e8fa-3db77607761e@openssl.org> On 16/09/16 19:47, Chad Phillips wrote: > I?m using a support library leveraging openssl to complete a DTLS handshake. You don't say what version of OpenSSL. The packet trace you sent is quite confusing, as there appears to be two separate handshakes going on at the same time that are interleaved. They are both essentially the same though, so I filtered on just one of them (the one involving UDP port 30041 - either as a source or destination port). The analysis below is just on that one handshake. > > Occasionally, I?ll see in my packet captures that a handshake has failed > with a ?Certificate reassembly error?, and the support library doesn?t > seem to be catching this properly to forward the error on. The "Certificate reassembly error" isn't really an error at all. This appears to simply be a packet that has been retransmitted. In wireshark if you select that packet and open up "Datagram Transport Layer Security" -> "Record Layer" -> "Handshake Protocol", you will see that this is an epoch 0 message (i.e. initial handshake message), with message sequence 1 (the second message sent from the Client - the first one being a ClientHello with message sequence 0). This contains the first 231 bytes of the full Certificate - which is 469 bytes in length. If you now compare this with the very first Certificate fragment sent from client to server you will see that it is identical. It seems quite clear that this is a retransmit of the earlier message from client to server. Retransmits are a normal part of DTLS and are there to handle packet loss. If a retransmitted packet is received by one of the peers, and it has seen that packet before, then it is simply ignored. Wireshark isn't ignoring it, and is reporting it as an "error" simply because it has seen it before. > > The library developers are considering handling this using a timeout > solution ? triggering an error if the handshake doesn?t complete in a > specified amount of time, but this feels a bit clunky to me. What?s the > recommended way to get this information from openssl in this case? > > For reference, I?m attaching a packet capture that illustrates two of > the handshake failures. Was this packet capture done on the client side or the server side or somewhere in the middle? There appears to be some messages missing. In particular I don't see any CCS or Finished messages being exchanged. Is the network this is over potentially noisy that might explain packet loss? It is particularly odd because an epoch 1 encrypted alert can be seen to have been sent from the server to the client which suggests that a CCS *has* been sent from the client and received by the server - but it does not appear in the packet trace. Another odd thing is that it can clearly be seen that the server retransmits the ServerHello/Certificate/ServerKeyExchange/CertRequest/ServerHelloDone flight. On receiving that the client should respond with a retransmit of the Certificate/ClientKeyExchange/CertificateVerify/CCS/Finished flight of messages. But it does not appear to do so...the retransmit does not happen until after the encrypted alert. Anyway, this really is a failed handshake, which for some reason I'm not seeing the retransmits I would expect to see in order to make it succeed. There has been no visible error, both peers are just sitting there waiting for the other one to do something. That's not going to happen if the the retransmits aren't working properly. Are both ends of the communication using OpenSSL and if so what versions? Matt From chad at apartmentlines.com Sat Sep 17 15:11:02 2016 From: chad at apartmentlines.com (Chad Phillips) Date: Sat, 17 Sep 2016 08:11:02 -0700 Subject: [openssl-users] How to handle DTLS Certificate Reassembly Error Message-ID: Matt, thanks for the reply, very helpful so far! Answers to your questions below: You don't say what version of OpenSSL. > The support library I?m using is Licode: http://lynckia.com/licode/index.html The version of openssl I have compiled into it is 1.0.2h. > The packet trace you sent is quite confusing, as there appears to be > two separate handshakes going on at the same time that are interleaved. > Yes, apologies for that, I?ll do a better job of filtering the next time. :) Those were two separate handshakes pulled from a packet capture of a group video chat, filtered through Wireshark using the ?dtls? filter. > It seems quite clear that this is a retransmit of the earlier message > from client to server. Retransmits are a normal part of DTLS and are > there to handle packet loss. If a retransmitted packet is received by > one of the peers, and it has seen that packet before, then it is simply > ignored. Wireshark isn't ignoring it, and is reporting it as an "error" > simply because it has seen it before. > Thanks for that clarification. > Was this packet capture done on the client side or the server side or > somewhere in the middle? There appears to be some messages missing. > In particular I don?t see any CCS or Finished messages being exchanged. > Is the network this is over potentially noisy that might explain packet > loss? > >From the perspective of the DTLS handshake, my server hosting the Licode library is the client, and latest stable Chrome browser is the server, if I understand the terminology correctly. The packet capture was taken from the client (Licode) side. Would the CCS or Finished messages have gotten filtered out by the ?dtls? filter I applied to the packet capture? I do have the full trace and can re-filter to just one complete connection over a specific UDP port as you suggested, let me know if that would be helpful I see these failures only in situations where browser users with slow and/or lossy internet are joining, and usually when the group size gets to be six or more participants. The particular testing scenario that generated the packets you saw was a user with 225kbps upload, 5120kbps down, 70ms delay, 0% packet loss. I?ll grant you those network conditions aren?t the best for group video chat, but if Google Hangouts can pull it off, I?d like to as well. > On receiving that the client should respond with a retransmit of > the Certificate/ClientKeyExchange/CertificateVerify/CCS/Finished > flight of messages. But it does not appear to do so?the retransmit does > not happen until after the encrypted alert. > This sounds like it might be a bug in the Licode library, not resending the retransmit properly? > Are both ends of the communication using OpenSSL and if so what versions? > >From my research, I believe Chrome uses borringssl? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sat Sep 17 22:43:02 2016 From: matt at openssl.org (Matt Caswell) Date: Sat, 17 Sep 2016 23:43:02 +0100 Subject: [openssl-users] How to handle DTLS Certificate Reassembly Error In-Reply-To: References: Message-ID: <8887b7d2-06d1-64c5-e511-9d35922762a4@openssl.org> On 17/09/16 16:11, Chad Phillips wrote: > Was this packet capture done on the client side or the server side or > somewhere in the middle? There appears to be some messages missing. > In particular I don?t see any CCS or Finished messages being > exchanged. Is the network this is over potentially noisy that might > explain packet loss? > > > From the perspective of the DTLS handshake, my server hosting the Licode > library is the client, and latest stable Chrome browser is the server, > if I understand the terminology correctly. The packet capture was taken > from the client (Licode) side. > > Would the CCS or Finished messages have gotten filtered out by the > ?dtls? filter I applied to the packet capture? I do have the full trace > and can re-filter to just one complete connection over a specific UDP > port as you suggested, let me know if that would be helpful I took another look at the packet trace. I found the CCS/Finished messages! They are actually there but wireshark is not showing them for some reason (at least my version of wireshark isn't). On the end of the packet which contains three Certificate fragments, the ClientKeyExchange and the Certificate Verify, my wireshark is then saying "Malformed Packet". This in in relation to a load of data that is in the packet after the Certificate Verify. Looking at it by eye the packets look well formed so I'm not sure why wireshark is complaining. Anyway after the Certificate Verify I can see the CCS, and an encrypted handshake message - which will be the Finished. What is odd is that we are seeing 3 Certificate fragments and 2 CertificateVerify fragments in a single network packet. OpenSSL will only fragment if it thinks the MTU isn't big enough for anything larger. It looks like licode is then combining the multiple fragments into a single packet anyway. This is probably something to do with the way licode is written meaning that OpenSSL is not getting the right MTU value. I assume the licode developers are trying to compensate for that by sending it all in one go anyway. That shouldn't cause any problems - but its a bit odd and it would be better to make sure OpenSSL gets the right MTU in the first place. I speculate that the reason I'm seeing the "malformed packet" is that, normally, you'd only see a maximum of 5 DTLS handshake records in a single packet. However, because we have fragmented the Certificate and CertificateVerify messages we've got more the 5 DTLS records in a packet. My guess is that there is a bug in wireshark that fails if it gets more the 5 records in one go. But that really is pure guess work. > > I see these failures only in situations where browser users with slow > and/or lossy internet are joining, and usually when the group size gets > to be six or more participants. The particular testing scenario that > generated the packets you saw was a user with 225kbps upload, 5120kbps > down, 70ms delay, 0% packet loss. > > I?ll grant you those network conditions aren?t the best for group video > chat, but if Google Hangouts can pull it off, I?d like to as well. > > > On receiving that the client should respond with a retransmit of > the Certificate/ClientKeyExchange/CertificateVerify/CCS/Finished > flight of messages. But it does not appear to do so?the retransmit > does not happen until after the encrypted alert. > > > This sounds like it might be a bug in the Licode library, not resending > the retransmit properly? Possibly. It could be that or it could also feasibly be a bug in OpenSSL. However I have a theory that might explain it (but it is just a theory). DTLS uses a timer to retransmit messages that may have got lost. If it hasn't had the response it expects following the last set of messages it sent by the time the timer expires, then it retransmits them. I wrote above that "On receiving that the client should respond with a retransmit of the Certificate/ClientKeyExchange/CertificateVerify/CCS/Finished flight of messages.". Actually in reality that's a bit of an over-simplification. What actually happens is the peer is waiting for some messages that it doesn't receive within its timeout (either because they are lost or delayed), and so it retransmits them. This is why we see the second set of ServerHello (etc) messages from the server. The client application usually then notices that the socket has become readable and the application calls OpenSSL to process that data. OpenSSL reads it, realises that they are retransmits of messages that it has already processed and drops them. It also checks its own timer to see if the client needs to retransmit any messages. If the client timer hasn't expired yet then it does nothing. This could be why no retransmit happens immediately after the second set of ServerHello messages, i.e. the client timer hasn't expired yet. Normally the server would continue to retransmit periodically, which would cause the client application to try and process the retransmits again, and eventually the timer will have expired and it will retransmit its last set of messages again. However in this case it seems the server only retransmits once and then doesn't try again. Perhaps boring has a different retransmit policy to us - I'm not sure. This means though that unless something else happens no further data will be received by the client until it retransmits its last set of messages...but with no further data being received the application never calls openssl again to cause it to check its timer again and make the retransmits happen! Therefore the client is sat there waiting for the server to send it something...and the server is also sat there waiting for something to happen. There is an OpenSSL API which is intended to resolve this issue: DTLSv1_handle_timeout() The application is expected to call this periodically during the handshake if no other data has been sent or received. The causes OpenSSL to check its timer and do any retransmits if necessary. If licode doesn't call this, then its plausible that this is the cause of the issue. Unfortunately there is at least one OpenSSL bug here - in the documentation: DTLSv1_handle_timeout() is undocumented :-( Matt From chad at apartmentlines.com Sun Sep 18 00:01:43 2016 From: chad at apartmentlines.com (Chad Phillips) Date: Sat, 17 Sep 2016 17:01:43 -0700 Subject: [openssl-users] How to handle DTLS Certificate Reassembly Error Message-ID: On Sat, Sep 17, 2016 at 3:43 PM, Matt Caswell wrote: There is an OpenSSL API which is intended to resolve this issue: > > DTLSv1_handle_timeout() > > The application is expected to call this periodically during the > handshake if no other data has been sent or received. The causes > OpenSSL to check its timer and do any retransmits if necessary. If > licode doesn?t call this, then its plausible that this is the cause of the > issue. ?grep -r DTLSv1_handle_timeout .? in the Licode source directory returns nothing, so we may have our culprit! Curious what versions of openssl support the DTLSv1_handle_timeout() approach? I know the Licode guys run 1.0.1g, it would be great if a single solution could be committed that was backwards compatible. Is there anything special I should know about how to use DTLSv1_handle_timeout()? Just have it run on a timer until the handshake completes? I guess I?m asking for some pre-documentation ;) Thanks again for your help, this is definitely the most clear progress I?ve made on this problem, and it?s been haunting me for months! Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sun Sep 18 08:37:25 2016 From: matt at openssl.org (Matt Caswell) Date: Sun, 18 Sep 2016 09:37:25 +0100 Subject: [openssl-users] How to handle DTLS Certificate Reassembly Error In-Reply-To: References: Message-ID: <923d3b1d-ebca-df85-d329-07df769696ea@openssl.org> On 18/09/16 01:01, Chad Phillips wrote: > On Sat, Sep 17, 2016 at 3:43 PM, Matt Caswell > wrote: > > There is an OpenSSL API which is intended to resolve this issue: > > DTLSv1_handle_timeout() > > The application is expected to call this periodically during the > handshake if no other data has been sent or received. The causes > OpenSSL to check its timer and do any retransmits if necessary. If > licode doesn?t call this, then its plausible that this is the cause > of the issue. > > > ?grep -r DTLSv1_handle_timeout .? in the Licode source directory returns > nothing, so we may have our culprit! > > Curious what versions of openssl support the DTLSv1_handle_timeout() > approach? I know the Licode guys run 1.0.1g, it would be great if a > single solution could be committed that was backwards compatible. Yes, DTLSv1_handle_timeout() is available in 1.0.1 as well. BTW there have been many DTLS bug and security fixes since 1.0.1g which is now quite old. The 1.0.1 series is now only receiving security fixes, and will go out of support completely at the end of the year. It is strongly recommended that they upgrade to a more recent version. > > Is there anything special I should know about how to use > DTLSv1_handle_timeout()? Just have it run on a timer until the handshake > completes? I guess I?m asking for some pre-documentation ;) Well the best way to use it is going to depend a lot on how the application is written. The API is fairly simple - just call DTLSv1_handle_timeout() periodically passing in the pointer to the SSL object. In our own s_server/s_client we just call it every time we go around the "select" loop on the socket. We ensure that the "select" call doesn't block indefinitely, but instead times out after the DTLS timer period has expired. We then call DTLSv1_handle_timeout() regardless of whether "select" has returned because the socket is readable, or because it has timed out. A (slightly modified and simplified) version of what we do in s_server is below: FD_ZERO(&readfds); FD_SET(s, &readfds); if (DTLSv1_get_timeout(con, &timeout)) timeoutp = &timeout; else timeoutp = NULL; i = select(width, (void *)&readfds, NULL, NULL, timeoutp); if (DTLSv1_handle_timeout(con) > 0) { BIO_printf(bio_err, "TIMEOUT occurred\n"); } if (i <= 0) continue; if (FD_ISSET(s, &readfds)) read_from_sslcon = 1; Matt From chad at apartmentlines.com Sun Sep 18 17:13:40 2016 From: chad at apartmentlines.com (Chad Phillips) Date: Sun, 18 Sep 2016 10:13:40 -0700 Subject: [openssl-users] How to handle DTLS Certificate Reassembly Error Message-ID: Great, thanks for this very clear description, I passed it along to the Licode developers, and hopefully we can put this sucker to rest. I also included your recommendation to upgrade, which is something I?ve been bugging them to do for awhile :) On Sun, Sep 18, 2016 at 1:37 AM, Matt Caswell wrote: > > > On 18/09/16 01:01, Chad Phillips wrote: > > On Sat, Sep 17, 2016 at 3:43 PM, Matt Caswell > > wrote: > > > > There is an OpenSSL API which is intended to resolve this issue: > > > > DTLSv1_handle_timeout() > > > > The application is expected to call this periodically during the > > handshake if no other data has been sent or received. The causes > > OpenSSL to check its timer and do any retransmits if necessary. If > > licode doesn?t call this, then its plausible that this is the cause > > of the issue. > > > > > > ?grep -r DTLSv1_handle_timeout .? in the Licode source directory returns > > nothing, so we may have our culprit! > > > > Curious what versions of openssl support the DTLSv1_handle_timeout() > > approach? I know the Licode guys run 1.0.1g, it would be great if a > > single solution could be committed that was backwards compatible. > > Yes, DTLSv1_handle_timeout() is available in 1.0.1 as well. BTW there > have been many DTLS bug and security fixes since 1.0.1g which is now > quite old. The 1.0.1 series is now only receiving security fixes, and > will go out of support completely at the end of the year. It is strongly > recommended that they upgrade to a more recent version. > > > > > > Is there anything special I should know about how to use > > DTLSv1_handle_timeout()? Just have it run on a timer until the handshake > > completes? I guess I?m asking for some pre-documentation ;) > > Well the best way to use it is going to depend a lot on how the > application is written. The API is fairly simple - just call > DTLSv1_handle_timeout() periodically passing in the pointer to the SSL > object. In our own s_server/s_client we just call it every time we go > around the "select" loop on the socket. We ensure that the "select" call > doesn't block indefinitely, but instead times out after the DTLS timer > period has expired. We then call DTLSv1_handle_timeout() regardless of > whether "select" has returned because the socket is readable, or because > it has timed out. A (slightly modified and simplified) version of what > we do in s_server is below: > > FD_ZERO(&readfds); > FD_SET(s, &readfds); > > if (DTLSv1_get_timeout(con, &timeout)) > timeoutp = &timeout; > else > timeoutp = NULL; > > i = select(width, (void *)&readfds, NULL, NULL, timeoutp); > > if (DTLSv1_handle_timeout(con) > 0) { > BIO_printf(bio_err, "TIMEOUT occurred\n"); > } > > if (i <= 0) > continue; > > if (FD_ISSET(s, &readfds)) > read_from_sslcon = 1; > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksandr.v.konstantinov at gmail.com Mon Sep 19 09:46:48 2016 From: aleksandr.v.konstantinov at gmail.com (Aleksandr Konstantinov) Date: Mon, 19 Sep 2016 12:46:48 +0300 Subject: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0 In-Reply-To: <20160909114446.GA20743@openssl.org> References: <20160908192356.GB7289@openssl.org> <20160909114446.GA20743@openssl.org> Message-ID: Hello, Thanks. Your answer helped a lot and I'm progressing now. Could You please also give me a hint what M_ASN1_BIT_STRING_dup/ASN1_BIT_STRING_dup could be replaced with? Best regards, A.K. On Fri, Sep 9, 2016 at 2:44 PM, Dr. Stephen Henson wrote: > On Fri, Sep 09, 2016, Aleksandr Konstantinov wrote: > > > Hello, > > > > Thanks for your answer. Here is one of d2i functions simplified: > > > > MYEXT * d2i_MYEXT(MYEXT ** myext, unsigned char ** pp, long length) { > > M_ASN1_D2I_vars(myext, MYEXT *, MYEXT_new); > > M_ASN1_D2I_Init(); > > M_ASN1_D2I_start_sequence(); > > M_ASN1_D2I_get_EXP_opt(ret->intmember, d2i_ASN1_INTEGER, 1); > > M_ASN1_D2I_get_opt(ret->intmember, d2i_ASN1_INTEGER, V_ASN1_INTEGER); > > M_ASN1_D2I_Finish(myext, MYEXT_free, ASN1_F_D2I_MYEXT); > > } > > > > > > Presumably the two fields aren't the same? I'll call one intmember2 for > this example. > > The above would translate to something like: > > ASN1_SEQUENCE(MYEXT) = { > ASN1_EXP_OPT(MYEXT, intmember, ASN1_INTEGER, 1), > ASN1_OPT(MYEXT, intmember2, ASN1_INTEGER) > } ASN1_SEQUENCE_END(MYEXT) > > IMPLEMENT_ASN1_FUNCTIONS(MYEXT) > > Then you include: > > DECLARE_ASN1_FUNCTIONS(MYEXT) > > in a header file. > > That generates four functions MYEXT_new(), MYEXT_free(), d2i_MYEXT() and > i2d_MYEXT(). > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag4ve.us at gmail.com Mon Sep 19 10:55:37 2016 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 19 Sep 2016 06:55:37 -0400 Subject: [openssl-users] Self signed cert issues In-Reply-To: References: Message-ID: End goal - I don't want the machine (curl, wget, git, etc) to throw errors when accessing a site that I trust (ie, within the company). [root at srwilson-centos7 anchors]# openssl s_client -showcerts -connect site.com:443 /dev/null|openssl x509 -outform PEM > site_git.pem [root at srwilson-centos7 anchors]# openssl verify site_git.pem site_git.pem: C = US, O = foo, OU = bar, OU = baz, OU = Devices, CN = site.com error 20 at 0 depth lookup:unable to get local issuer certificate [root at srwilson-centos7 anchors]# openssl s_client -CApath ./ -connect site.com:443 /dev/null | grep Verify Verify return code: 21 (unable to verify the first certificate) [root at srwilson-centos7 anchors]# update-ca-trust enable; update-ca-trust extract [root at srwilson-centos7 anchors]# openssl s_client -CApath ./ -connect site.com:443 /dev/null | grep Verify Verify return code: 21 (unable to verify the first certificate) This is centos 7 and I'm in /etc/pki/ca-trust/source/anchors. Obviously I'm not looking at site.com (that's probably a trusted cert anyway ;) ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Mon Sep 19 12:05:40 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 19 Sep 2016 12:05:40 +0000 Subject: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0 In-Reply-To: References: <20160908192356.GB7289@openssl.org> <20160909114446.GA20743@openssl.org> Message-ID: <20160919120540.GA30052@openssl.org> On Mon, Sep 19, 2016, Aleksandr Konstantinov wrote: > > Thanks. Your answer helped a lot and I'm progressing now. Could You please > also give me a hint what M_ASN1_BIT_STRING_dup/ASN1_BIT_STRING_dup could be > replaced with? > ASN1_STRING_dup should work fine: ASN1_BIT_STRING is actually typedefed to ASN1_STRING. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl-users at dukhovni.org Mon Sep 19 14:25:14 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 19 Sep 2016 14:25:14 +0000 Subject: [openssl-users] Self signed cert issues In-Reply-To: References: Message-ID: <20160919142514.GO4670@mournblade.imrryr.org> On Mon, Sep 19, 2016 at 06:55:37AM -0400, shawn wilson wrote: > End goal - I don't want the machine (curl, wget, git, etc) to throw errors > when accessing a site that I trust (ie, within the company). When you add a certificate to the trust store (CAfile or CApath), it will be a trust-anchor for verification if and only if: * It is a self-signed "root" CA. * It is an intermediate CA, you're running OpenSSL 1.0.2 or later, and you've set the "X509_V_FLAG_PARTIAL_CHAIN" flag (see below). * It exactly matches the peer's end-entity certificate, you're running OpenSSL 1.0.2 or later, and you've set the "X509_V_FLAG_PARTIAL_CHAIN" flag. > [root at srwilson-centos7 anchors]# openssl s_client -showcerts -connect > site.com:443 /dev/null|openssl x509 -outform PEM > site_git.pem This writes the certificates sent on the wire by "site.com" to "site_git.pem". Quite often this does not include the issuing root CA. And it is of course unwise to write whatever you get on the wire, uninspected, to your trust store. I hope you're doing this just to explain your issue. > [root at srwilson-centos7 anchors]# openssl verify site_git.pem > site_git.pem: C = US, O = foo, OU = bar, OU = baz, OU = Devices, CN = > site.com > error 20 at 0 depth lookup:unable to get local issuer certificate As you expected, this chain's trust-anchor is not yet available. > [root at srwilson-centos7 anchors]# update-ca-trust enable; update-ca-trust extract Presumably at this point, c_rehash(1) or equivalent has been executed and any certificates in that chain are in the trust store. > [root at srwilson-centos7 anchors]# openssl s_client -CApath ./ -connect > site.com:443 /dev/null | grep Verify > Verify return code: 21 (unable to verify the first certificate) This is expected if the chain in question did not include the root CA. Make sure that the certificates in question did actually get c_rehash(1) symlinks, and retest with: $ openssl s_client -partial_chain -CApath $PWD -connect site.com:443 The "-partial_chain" option turns on the "X509_V_FLAG_PARTIAL_CHAIN" verification flag, which enables intermediate and leaf trust-anchors. -- Viktor. From jinujayachandran at gmail.com Tue Sep 20 04:22:07 2016 From: jinujayachandran at gmail.com (Jinu Jayachandran) Date: Tue, 20 Sep 2016 09:52:07 +0530 Subject: [openssl-users] Building OpenSSL Library on ARM Cortex M4 based STM32F4 controller in an RTOS environment Message-ID: Hi, I am looking at the feasibility of developing an embedded Bluetooth application with OpenSSL-FIPS support on STM32F407 microcontroller(which is ARM Cortex M4 based). The application doesn't run on generic OS like Linux, Windows or android but it runs on CMSIS-RTX RTOS. I am using Keil in Windows as the developing environment with the built in armc compiler (armcc) for compilation. During my analysis I found the OpenSSL wiki which explains how to build and install OpenSSL library: Compilation and Installation . In the page although there is a section for compilation for ARM platform, there is no description on how to do it. I have also gone through the following link on compiling with ARM How To Build OpenSSL for ARM But the compiler specified here is GCC. My queries for OpenSSL-FIPS support are the following 1. Is there a library available which can used in the mentioned platform ? 2. Is it possible to port OpenSSL to ARM Cortex M4 platform with an RTOS?. To be more specific is it possible to port it to STM32F407 with CMSIS RTX ? 3. If it is possible, where should I start and how much complex is it?. 4. If I compile the OpenSSL library in GCC compiler and use it in a armc compiled application will it work ? (I have a feeling that it won't) 5. Which other SSL libraries can I use with the embedded software ? Regards Jinu -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksandr.v.konstantinov at gmail.com Tue Sep 20 09:45:05 2016 From: aleksandr.v.konstantinov at gmail.com (Aleksandr Konstantinov) Date: Tue, 20 Sep 2016 12:45:05 +0300 Subject: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0 In-Reply-To: <20160919120540.GA30052@openssl.org> References: <20160908192356.GB7289@openssl.org> <20160909114446.GA20743@openssl.org> <20160919120540.GA30052@openssl.org> Message-ID: Hello, Thanks a lot. One more question if possible. Is there any way to express single element of the ASN1 sequence which can be any of ASN1_OCTET_STRING or ASN1_UTF8STRING and potentially other types? Or maybe there is some tutorial for new interface similar to something like http://www.umich.edu/~x509/ssleay/asn1-macros.html for old one? Best regards, A.K. On Mon, Sep 19, 2016 at 3:05 PM, Dr. Stephen Henson wrote: > On Mon, Sep 19, 2016, Aleksandr Konstantinov wrote: > > > > > Thanks. Your answer helped a lot and I'm progressing now. Could You > please > > also give me a hint what M_ASN1_BIT_STRING_dup/ASN1_BIT_STRING_dup > could be > > replaced with? > > > > ASN1_STRING_dup should work fine: ASN1_BIT_STRING is actually typedefed to > ASN1_STRING. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Sep 20 11:14:50 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 20 Sep 2016 07:14:50 -0400 Subject: [openssl-users] Building OpenSSL Library on ARM Cortex M4 based STM32F4 controller in an RTOS environment In-Reply-To: References: Message-ID: <7bee4e4e-b5f2-38e8-d043-a552c493a8f6@openssl.com> On 09/20/2016 12:22 AM, Jinu Jayachandran wrote: > Hi, > > > > I am looking at the feasibility of developing an embedded Bluetooth > application with OpenSSL-FIPS support on STM32F407 microcontroller(which > is ARM Cortex M4 based). The application doesn't run on generic OS like > Linux, Windows or android but it runs on CMSIS-RTX RTOS. I am using Keil > in Windows as the developing environment with the built in armc compiler > (armcc) for compilation. > > > > During my analysis I found the OpenSSL wiki which explains how to build > and install OpenSSL library: Compilation and Installation > . > > In the page although there is a section for compilation for ARM > platform, there is no description on how to do it. > > > > I have also gone through the following link on compiling with ARM > > How To Build OpenSSL for ARM > > > > > But the compiler specified here is GCC. > > My queries for OpenSSL-FIPS support are the following > > 1. Is there a library available which can used in the mentioned > platform ? > > 2. Is it possible to port OpenSSL to ARM Cortex M4 platform with an > RTOS?. To be more specific is it possible to port it to STM32F407 with > CMSIS RTX ? > > 3. If it is possible, where should I start and how much complex is it?. > > 4. If I compile the OpenSSL library in GCC compiler and use it in a > armc compiled application will it work ? (I have a feeling that it won't) > > 5. Which other SSL libraries can I use with the embedded software ? Unfortunately these questions are all moot for the OpenSSL FIPS module. The only reason to use the FIPS module is to satisfy FIPS 140-2 requirements (usually within the U.S. DoD and Federal government). Use of the module on a non-validated platform, such as yours, will *not* satisfy those requirements. It should be possible to have your platform (RTOS on ARM) added to one of the validations, but that will cost time and money. But, until and if that is done stock OpenSSL will achieve the same level of FIPS 140-2 righteousness (i.e., none). -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From Erwann.Abalea at docusign.com Tue Sep 20 10:44:30 2016 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Tue, 20 Sep 2016 10:44:30 +0000 Subject: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0 In-Reply-To: References: <20160908192356.GB7289@openssl.org> <20160909114446.GA20743@openssl.org> <20160919120540.GA30052@openssl.org> Message-ID: <0A54D78B-7BF7-4620-AB3D-20BDE8535B2D@docusign.com> Bonjour, Something like this? /* MyChoice ::= CHOICE { anInteger INTEGER, anOctetString OCTET STRING anASCIIString IA5STRING } MyStruct ::= SEQUENCE { item1 MyChoice } */ __ File mytypes.h __ #include #define ASN1_OBJECT_dup(x) ASN1_dup_of(ASN1_OBJECT,i2d_ASN1_OBJECT,d2i_ASN1_OBJECT,x) #define DECLARE_ASN1_DUP_FUNCTION(stname) stname * stname##_dup(stname *x); typedef struct { int type; union { ASN1_INTEGER *anInteger; ASN1_OCTET_STRING *anOctetString; ASN1_IA5STRING *anASCIIString; } value; } MYCHOICE; DECLARE_ASN1_FUNCTIONS(MYCHOICE) DECLARE_ASN1_DUP_FUNCTION(MYCHOICE) DECLARE_ASN1_PRINT_FUNCTION(MYCHOICE) #define d2i_MYCHOICE_bio(bp,p) ASN1_d2i_bio_of(MYCHOICE, MYCHOICE_new,d2i_ MYCHOICE,bp,p) #define i2d_MYCHOICE_bio(bp,o) ASN1_i2d_bio_of(MYCHOICE,i2d_ MYCHOICE,bp,o) #define d2i_MYCHOICE_fp(fp,p) ASN1_d2i_fp_of(MYCHOICE, MYCHOICE_new,d2i_ MYCHOICE,fp,p) #define i2d_MYCHOICE_fp(fp,p) ASN1_i2d_fp_of(MYCHOICE,i2d_ MYCHOICE,fp,p) typedef struct { MYCHOICE *item1; } MYSTRUCT; DECLARE_ASN1_FUNCTIONS(MYSTRUCT) DECLARE_ASN1_DUP_FUNCTION(MYSTRUCT) DECLARE_ASN1_PRINT_FUNCTION(MYSTRUCT) #define d2i_MYSTRUCT_bio(bp,p) ASN1_d2i_bio_of(MYSTRUCT, MYSTRUCT_new,d2i_ MYSTRUCT,bp,p) #define i2d_MYSTRUCT_bio(bp,o) ASN1_i2d_bio_of(MYSTRUCT,i2d_ MYSTRUCT,bp,o) #define d2i_MYSTRUCT_fp(fp,p) ASN1_d2i_fp_of(MYSTRUCT, MYSTRUCT_new,d2i_ MYSTRUCT,fp,p) #define i2d_MYSTRUCT_fp(fp,p) ASN1_i2d_fp_of(MYSTRUCT,i2d_ MYSTRUCT,fp,p) ____ __ File mytypes.c __ #include #include "mytypes.h" ASN1_CHOICE(MYCHOICE) = { ASN1_SIMPLE(MYCHOICE, value.anInteger, ASN1_INTEGER), ASN1_SIMPLE(MYCHOICE, value.anOctetString, ASN1_OCTET_STRING), ASN1_SIMPLE(MYCHOICE, value.anASCIIString, ASN1_IA5STRING) } ASN1_CHOICE_END(MYCHOICE) IMPLEMENT_ASN1_FUNCTIONS(MYCHOICE) IMPLEMENT_ASN1_DUP_FUNCTION(MYCHOICE) IMPLEMENT_ASN1_PRINT_FUNCTION(MYCHOICE) ASN1_SEQUENCE(MYSTRUCT) = { ASN1_SIMPLE(MYSTRUCT, item1, MYCHOICE) } ASN1_SEQUENCE_END(MYSTRUCT) IMPLEMENT_ASN1_FUNCTIONS(MYSTRUCT) IMPLEMENT_ASN1_DUP_FUNCTION(MYSTRUCT) IMPLEMENT_ASN1_PRINT_FUNCTION(MYSTRUCT) ____ Now you can call i2d_MYSTRUCT()/d2i_MYSTRUCT() to encode/decode such a data type, and similar _bio, _fp, _dup functions as well. Cordialement, Erwann Abalea Le 20 sept. 2016 ? 11:45, Aleksandr Konstantinov > a ?crit : Hello, Thanks a lot. One more question if possible. Is there any way to express single element of the ASN1 sequence which can be any of ASN1_OCTET_STRING or ASN1_UTF8STRING and potentially other types? Or maybe there is some tutorial for new interface similar to something like http://www.umich.edu/~x509/ssleay/asn1-macros.html for old one? Best regards, A.K. On Mon, Sep 19, 2016 at 3:05 PM, Dr. Stephen Henson > wrote: On Mon, Sep 19, 2016, Aleksandr Konstantinov wrote: > > Thanks. Your answer helped a lot and I'm progressing now. Could You please > also give me a hint what M_ASN1_BIT_STRING_dup/ASN1_BIT_STRING_dup could be > replaced with? > ASN1_STRING_dup should work fine: ASN1_BIT_STRING is actually typedefed to ASN1_STRING. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Tue Sep 20 11:51:51 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 20 Sep 2016 11:51:51 +0000 Subject: [openssl-users] M_ASN1_D2I_* replacement in OpenSSL 1.1.0 In-Reply-To: References: <20160908192356.GB7289@openssl.org> <20160909114446.GA20743@openssl.org> <20160919120540.GA30052@openssl.org> Message-ID: <20160920115151.GA22040@openssl.org> On Tue, Sep 20, 2016, Aleksandr Konstantinov wrote: > Hello, > > Thanks a lot. One more question if possible. Is there any way to express > single element of the ASN1 sequence which can be any > of ASN1_OCTET_STRING or ASN1_UTF8STRING and potentially other types? That depends what you mean. If the supported types are well defined then you can use the CHOICE construction. If just about anything could go in the element then you can use ASN1_ANY which encodes and decodes ASN1_TYPE. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From jingmliu at sina.com Wed Sep 21 12:34:42 2016 From: jingmliu at sina.com (Jing Liu) Date: Wed, 21 Sep 2016 20:34:42 +0800 Subject: [openssl-users] =?gb2312?b?s7e72DogQ2Fubm90IGluc3RhbGwgT3BlblNT?= =?gb2312?b?TCAxLjEuMCB1c2luZyAnbm1ha2UgaW5zdGFsbCc=?= Message-ID: Jing Liu ??????Cannot install OpenSSL 1.1.0 using 'nmake install'?? -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 1645 bytes Desc: not available URL: From jingmliu at sina.com Wed Sep 21 12:38:52 2016 From: jingmliu at sina.com (Jing Liu) Date: Wed, 21 Sep 2016 20:38:52 +0800 Subject: [openssl-users] =?gb2312?b?s7e72DogQ2Fubm90IGluc3RhbGwgT3BlblNT?= =?gb2312?b?TCAxLjEuMCB1c2luZyAnbm1ha2UgaW5zdGFsbCc=?= Message-ID: Jing Liu ??????Cannot install OpenSSL 1.1.0 using 'nmake install'?? -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 1645 bytes Desc: not available URL: From jingmliu at sina.com Wed Sep 21 12:35:27 2016 From: jingmliu at sina.com (Jing Liu) Date: Wed, 21 Sep 2016 20:35:27 +0800 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' Message-ID: I've tried all my best to solve this problem but failed. Can you help me? - OS: Windows 10 - Perl: ActivePerl 5.12.2 build 1202 - Development environment: MS Visual Studio 2010 SP1 - OpenSSL version: OpenSSL 1.1.0 I tried to compile and install OpenSSL 1.1.0 according to the following steps: 1. decompressed OpenSSL 1.1.0 software package to directory "D:\openssl-1.1.0"; 2. opened the "Visual Studio 2010 command prompt" window using an Administrator identity; 3. switched to the directory "D:\openssl-1.1.0"; 4. D:\openssl-1.1.0> perl Configure VC-WIN32; 5. D:\openssl-1.1.0> nmake; 6. D:\openssl-1.1.0> nmake test; > So far, all steps went smoothly, but ... 7. D:\openssl-1.1.0> nmake install; Here, I got the following error and there was no file being copied to the destination directories even though those directories were successfully created. Microsoft (R) program maintenance utility 10.00.30319.01 copy right (C) Microsoft Corporation.All rights reserved. *** Installing development files created directory 'C:/Program Files (x86)/OpenSSL' created directory 'C:/Program Files (x86)/OpenSSL/include' created directory 'C:/Program Files (x86)/OpenSSL/include/openssl' Can't Open "./ms/applink.c" at .\util\copy.pl line 61. NMAKE : fatal error U1077: "C:\Perl\bin\perl.exe": return code "0x16" Stop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hartley at taxcomputersystems.com Wed Sep 21 12:54:58 2016 From: andrew.hartley at taxcomputersystems.com (Andrew Hartley) Date: Wed, 21 Sep 2016 12:54:58 +0000 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' In-Reply-To: References: Message-ID: Your step (4) to me appears to be wrong. If you are to install openssl to the following directory: C:\Program Files (x86)\OpenSSL\ then you need to do: ? perl Configure VC-WIN32 -prefix=C:\Program Files (x86)\OpenSSL When I build openSSL I use nasm, so after the above I do: ? ms\do_nasm ? nmake -a -f ms\nt.mak ? nmake -f ms\nt.mak test ? nmake -f ms\nt.mak install Does that help at all? From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jing Liu Sent: 21 September 2016 13:35 To: openssl-users at openssl.org Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' I've tried all my best to solve this problem but failed. Can you help me? - OS: Windows 10 - Perl: ActivePerl 5.12.2 build 1202 - Development environment: MS Visual Studio 2010 SP1 - OpenSSL version: OpenSSL 1.1.0 I tried to compile and install OpenSSL 1.1.0 according to the following steps: 1. decompressed OpenSSL 1.1.0 software package to directory "D:\openssl-1.1.0"; 2. opened the "Visual Studio 2010 command prompt" window using an Administrator identity; 3. switched to the directory "D:\openssl-1.1.0"; 4. D:\openssl-1.1.0> perl Configure VC-WIN32; 5. D:\openssl-1.1.0> nmake; 6. D:\openssl-1.1.0> nmake test; > So far, all steps went smoothly, but ... 7. D:\openssl-1.1.0> nmake install; Here, I got the following error and there was no file being copied to the destination directories even though those directories were successfully created. Microsoft (R) program maintenance utility 10.00.30319.01 copy right (C) Microsoft Corporation.All rights reserved. *** Installing development files created directory 'C:/Program Files (x86)/OpenSSL' created directory 'C:/Program Files (x86)/OpenSSL/include' created directory 'C:/Program Files (x86)/OpenSSL/include/openssl' Can't Open "./ms/applink.c" at .\util\copy.pl line 61. NMAKE : fatal error U1077: "C:\Perl\bin\perl.exe": return code "0x16" Stop. ______________________________________________________________________ Registered in England with company number 5347048 Registered office at Centurion House, London Road, Staines-upon-Thames, TW18 4AX This electronic message contains information from Tax Computer Systems Ltd (a wholly owned subsidiary of tax systems plc) which is confidential and may be privileged. The information is intended to be for the sole use of the individual(s) or entity to whom it is addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify the sender by telephone or e-mail (to the number or e-mail address above) immediately and destroy the message and all attached documents. Reasonable care has been taken to ensure that this communication (and any attachments or hyperlinks contained within it) is free from computer viruses. No responsibility is accepted by taxsystemsplc and the recipient should carry out any appropriate virus checks. ________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 21 13:03:45 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 21 Sep 2016 14:03:45 +0100 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' In-Reply-To: References: Message-ID: <85dd9673-8cd7-0e0f-0c51-d5ab621ee064@openssl.org> On 21/09/16 13:54, Andrew Hartley wrote: > Your step (4) to me appears to be wrong. If you are to install openssl > to the following directory: > > > > C:\Program Files (x86)\OpenSSL\ > > > > then you need to do: > > > > ? perl Configure VC-WIN32 ?prefix=C:\Program Files (x86)\OpenSSL > > > > When I build openSSL I use nasm, so after the above I do: > > > > ? ms\do_nasm > > ? nmake ?a ?f ms\nt.mak > > ? nmake ?f ms\nt.mak test > > ? nmake ?f ms\nt.mak install > > > > Does that help at all? The above is incorrect for OpenSSL 1.1.0. The build procedure has changed significantly in that version. Matt > > > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Jing Liu > *Sent:* 21 September 2016 13:35 > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake > install' > > > > I?ve tried all my best to solve this problem but failed. Can you help me? > > > > - OS: Windows 10 > > - Perl: ActivePerl 5.12.2 build 1202 > > - Development environment: MS Visual Studio 2010 SP1 > > - OpenSSL version: OpenSSL 1.1.0 > > > > I tried to compile and install OpenSSL 1.1.0 according to the following > steps: > > > > 1. decompressed OpenSSL 1.1.0 software package to directory > "D:\openssl-1.1.0"; > > 2. opened the "Visual Studio 2010 command prompt" window using an > Administrator identity; > > 3. switched to the directory "D:\openssl-1.1.0"; > > 4. D:\openssl-1.1.0> perl Configure VC-WIN32; > > 5. D:\openssl-1.1.0> nmake; > > 6. D:\openssl-1.1.0> nmake test; > > > >> So far, all steps went smoothly, but ... > > > > 7. D:\openssl-1.1.0> nmake install; > > > > Here, I got the following error and there was no file being copied to > the destination directories even though those directories were > successfully created. > > > > Microsoft (R) program maintenance utility 10.00.30319.01 copy right > (C) Microsoft Corporation.All rights reserved. > > *** Installing development files > > created directory 'C:/Program Files (x86)/OpenSSL' > > created directory 'C:/Program Files (x86)/OpenSSL/include' > > created directory 'C:/Program Files (x86)/OpenSSL/include/openssl' > > Can't Open "./ms/applink.c" at .\util\copy.pl line 61. > > NMAKE : fatal error U1077: ?C:\Perl\bin\perl.exe?: return code ?0x16? > > Stop. > > > ______________________________________________________________________ > Registered in England with company number 5347048 > Registered office at Centurion House, London Road, Staines-upon-Thames, > TW18 4AX > > This electronic message contains information from Tax Computer Systems > Ltd (a wholly owned subsidiary of tax systems plc) which is confidential > and may be privileged. The information is intended to be for the sole > use of the individual(s) or entity to whom it is addressed. If you are > not the intended recipient, be aware that any disclosure, copying, > distribution or use of the contents of this information is prohibited. > If you have received this electronic message in error, please notify the > sender by telephone or e-mail (to the number or e-mail address above) > immediately and destroy the message and all attached documents. > > Reasonable care has been taken to ensure that this communication (and > any attachments or hyperlinks contained within it) is free from computer > viruses. No responsibility is accepted by taxsystemsplc and the > recipient should carry out any appropriate virus checks. > ________________________________________________________________________ > > From levitte at openssl.org Wed Sep 21 13:10:03 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 21 Sep 2016 15:10:03 +0200 (CEST) Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' In-Reply-To: References: Message-ID: <20160921.151003.1935111807360543444.levitte@openssl.org> Andrew, I think you need to read up in the INSTALL file in 1.1.0. Jing Liu's sequence of commands seems correct to me, and with 1.1.0, the default install prefix *is* C:\Program Files (x86)\OpenSSL\ for VC-Win32. Cheers, Richard In message on Wed, 21 Sep 2016 12:54:58 +0000, Andrew Hartley said: andrew.hartley> Your step (4) to me appears to be wrong. If you are to install openssl andrew.hartley> to the following directory: andrew.hartley> andrew.hartley> C:\Program Files (x86)\OpenSSL\ andrew.hartley> andrew.hartley> then you need to do: andrew.hartley> andrew.hartley> ? perl Configure VC-WIN32 ?prefix=C:\Program Files (x86)\OpenSSL andrew.hartley> andrew.hartley> When I build openSSL I use nasm, so after the above I do: andrew.hartley> andrew.hartley> ? ms\do_nasm andrew.hartley> andrew.hartley> ? nmake ?a ?f ms\nt.mak andrew.hartley> andrew.hartley> ? nmake ?f ms\nt.mak test andrew.hartley> andrew.hartley> ? nmake ?f ms\nt.mak install andrew.hartley> andrew.hartley> Does that help at all? andrew.hartley> andrew.hartley> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On andrew.hartley> Behalf Of Jing Liu andrew.hartley> Sent: 21 September 2016 13:35 andrew.hartley> To: openssl-users at openssl.org andrew.hartley> Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake andrew.hartley> install' andrew.hartley> andrew.hartley> I?ve tried all my best to solve this problem but failed. Can you help andrew.hartley> me? andrew.hartley> andrew.hartley> - OS: Windows 10 andrew.hartley> andrew.hartley> - Perl: ActivePerl 5.12.2 build 1202 andrew.hartley> andrew.hartley> - Development environment: MS Visual Studio 2010 SP1 andrew.hartley> andrew.hartley> - OpenSSL version: OpenSSL 1.1.0 andrew.hartley> andrew.hartley> I tried to compile and install OpenSSL 1.1.0 according to the andrew.hartley> following steps: andrew.hartley> andrew.hartley> 1. decompressed OpenSSL 1.1.0 software package to directory andrew.hartley> "D:\openssl-1.1.0"; andrew.hartley> andrew.hartley> 2. opened the "Visual Studio 2010 command prompt" window using an andrew.hartley> Administrator identity; andrew.hartley> andrew.hartley> 3. switched to the directory "D:\openssl-1.1.0"; andrew.hartley> andrew.hartley> 4. D:\openssl-1.1.0> perl Configure VC-WIN32; andrew.hartley> andrew.hartley> 5. D:\openssl-1.1.0> nmake; andrew.hartley> andrew.hartley> 6. D:\openssl-1.1.0> nmake test; andrew.hartley> andrew.hartley> > So far, all steps went smoothly, but ... andrew.hartley> andrew.hartley> 7. D:\openssl-1.1.0> nmake install; andrew.hartley> andrew.hartley> Here, I got the following error and there was no file being copied to andrew.hartley> the destination directories even though those directories were andrew.hartley> successfully created. andrew.hartley> andrew.hartley> Microsoft (R) program maintenance utility 10.00.30319.01 copy right andrew.hartley> (C) Microsoft Corporation.All rights reserved. andrew.hartley> andrew.hartley> *** Installing development files andrew.hartley> andrew.hartley> created directory 'C:/Program Files (x86)/OpenSSL' andrew.hartley> andrew.hartley> created directory 'C:/Program Files (x86)/OpenSSL/include' andrew.hartley> andrew.hartley> created directory 'C:/Program Files (x86)/OpenSSL/include/openssl' andrew.hartley> andrew.hartley> Can't Open "./ms/applink.c" at .\util\copy.pl line 61. andrew.hartley> andrew.hartley> NMAKE : fatal error U1077: ?C:\Perl\bin\perl.exe?: return code ?0x16? andrew.hartley> andrew.hartley> Stop. andrew.hartley> andrew.hartley> ______________________________________________________________________ andrew.hartley> Registered in England with company number 5347048 andrew.hartley> Registered office at Centurion House, London Road, andrew.hartley> Staines-upon-Thames, TW18 4AX andrew.hartley> andrew.hartley> This electronic message contains information from Tax Computer Systems andrew.hartley> Ltd (a wholly owned subsidiary of tax systems plc) which is andrew.hartley> confidential and may be privileged. The information is intended to be andrew.hartley> for the sole use of the individual(s) or entity to whom it is andrew.hartley> addressed. If you are not the intended recipient, be aware that any andrew.hartley> disclosure, copying, distribution or use of the contents of this andrew.hartley> information is prohibited. If you have received this electronic andrew.hartley> message in error, please notify the sender by telephone or e-mail (to andrew.hartley> the number or e-mail address above) immediately and destroy the andrew.hartley> message and all attached documents. andrew.hartley> andrew.hartley> Reasonable care has been taken to ensure that this communication (and andrew.hartley> any attachments or hyperlinks contained within it) is free from andrew.hartley> computer viruses. No responsibility is accepted by taxsystemsplc and andrew.hartley> the recipient should carry out any appropriate virus checks. andrew.hartley> ________________________________________________________________________ From levitte at openssl.org Wed Sep 21 13:13:16 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 21 Sep 2016 15:13:16 +0200 (CEST) Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' In-Reply-To: References: Message-ID: <20160921.151316.381060034330687108.levitte@openssl.org> Weird problem. I assume that if you do 'dir ms' while standing in D:\openssl-1.1.0, you will in fact see applink.c. Correct? My I suggest applying the attached patch to util/copy.pl and see if you get a better explanation for the mystery? Cheers, Richard In message on Wed, 21 Sep 2016 20:35:27 +0800, "Jing Liu" said: jingmliu> I?ve tried all my best to solve this problem but failed. Can you help jingmliu> me? jingmliu> jingmliu> - OS: Windows 10 jingmliu> jingmliu> - Perl: ActivePerl 5.12.2 build 1202 jingmliu> jingmliu> - Development environment: MS Visual Studio 2010 SP1 jingmliu> jingmliu> - OpenSSL version: OpenSSL 1.1.0 jingmliu> jingmliu> I tried to compile and install OpenSSL 1.1.0 according to the jingmliu> following steps: jingmliu> jingmliu> 1. decompressed OpenSSL 1.1.0 software package to directory jingmliu> "D:\openssl-1.1.0"; jingmliu> jingmliu> 2. opened the "Visual Studio 2010 command prompt" window using an jingmliu> Administrator identity; jingmliu> jingmliu> 3. switched to the directory "D:\openssl-1.1.0"; jingmliu> jingmliu> 4. D:\openssl-1.1.0> perl Configure VC-WIN32; jingmliu> jingmliu> 5. D:\openssl-1.1.0> nmake; jingmliu> jingmliu> 6. D:\openssl-1.1.0> nmake test; jingmliu> jingmliu> > So far, all steps went smoothly, but ... jingmliu> jingmliu> 7. D:\openssl-1.1.0> nmake install; jingmliu> jingmliu> Here, I got the following error and there was no file being copied to jingmliu> the destination directories even though those directories were jingmliu> successfully created. jingmliu> jingmliu> Microsoft (R) program maintenance utility 10.00.30319.01 copy right jingmliu> (C) Microsoft Corporation.All rights reserved. jingmliu> jingmliu> *** Installing development files jingmliu> jingmliu> created directory 'C:/Program Files (x86)/OpenSSL' jingmliu> jingmliu> created directory 'C:/Program Files (x86)/OpenSSL/include' jingmliu> jingmliu> created directory 'C:/Program Files (x86)/OpenSSL/include/openssl' jingmliu> jingmliu> Can't Open "./ms/applink.c" at .\util\copy.pl line 61. jingmliu> jingmliu> NMAKE : fatal error U1077: ?C:\Perl\bin\perl.exe?: return code ?0x16? jingmliu> jingmliu> Stop. jingmliu> -------------- next part -------------- A non-text attachment was scrubbed... Name: copy.pl.diff Type: text/x-patch Size: 488 bytes Desc: not available URL: From matt at openssl.org Wed Sep 21 13:13:33 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 21 Sep 2016 14:13:33 +0100 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' In-Reply-To: References: Message-ID: <80186e15-4000-2a7d-f810-5e8d94988053@openssl.org> On 21/09/16 13:35, Jing Liu wrote: > Can't Open "./ms/applink.c" at .\util\copy.pl line 61. So, does the file ms/applink.c actually exist? And do you have permissions to open it? Matt From andrew.hartley at taxcomputersystems.com Wed Sep 21 13:26:42 2016 From: andrew.hartley at taxcomputersystems.com (Andrew Hartley) Date: Wed, 21 Sep 2016 13:26:42 +0000 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' In-Reply-To: <20160921.151003.1935111807360543444.levitte@openssl.org> References: <20160921.151003.1935111807360543444.levitte@openssl.org> Message-ID: <2a0c098d1e1a4217ad5db1927eaec847@MailSvr.tcsl.taxcomputersystems.com> Sorry, my mistake, those were the instructions I used for building openssl-1.0.2 When I do, for openssl-1.1.0: > perl Configure VC-WIN32 That works, and then I do: > nmake I get: Fatal error C1051: program database file, 'C:\...\openssl-1.1.0\ossl_static.pdb' has an obsolete format, delete it and recompile Andrew Hartley Senior Software Engineer Tel: +44 (0)1784 410 369 | Direct: +44 (0)1784 410 103 Email: andrew.hartley at taxcomputersystems.com Web: www.taxcomputersystems.com Tax Computer Systems Limited, Centurion House, London Road, Staines, TW18 4AX -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Levitte Sent: 21 September 2016 14:10 To: openssl-users at openssl.org Subject: Re: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' Andrew, I think you need to read up in the INSTALL file in 1.1.0. Jing Liu's sequence of commands seems correct to me, and with 1.1.0, the default install prefix *is* C:\Program Files (x86)\OpenSSL\ for VC-Win32. Cheers, Richard In message on Wed, 21 Sep 2016 12:54:58 +0000, Andrew Hartley said: andrew.hartley> Your step (4) to me appears to be wrong. If you are to install openssl andrew.hartley> to the following directory: andrew.hartley> andrew.hartley> C:\Program Files (x86)\OpenSSL\ andrew.hartley> andrew.hartley> then you need to do: andrew.hartley> andrew.hartley> ? perl Configure VC-WIN32 ?prefix=C:\Program Files (x86)\OpenSSL andrew.hartley> andrew.hartley> When I build openSSL I use nasm, so after the above I do: andrew.hartley> andrew.hartley> ? ms\do_nasm andrew.hartley> andrew.hartley> ? nmake ?a ?f ms\nt.mak andrew.hartley> andrew.hartley> ? nmake ?f ms\nt.mak test andrew.hartley> andrew.hartley> ? nmake ?f ms\nt.mak install andrew.hartley> andrew.hartley> Does that help at all? andrew.hartley> andrew.hartley> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On andrew.hartley> Behalf Of Jing Liu andrew.hartley> Sent: 21 September 2016 13:35 andrew.hartley> To: openssl-users at openssl.org andrew.hartley> Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake andrew.hartley> install' andrew.hartley> andrew.hartley> I?ve tried all my best to solve this problem but failed. Can you help andrew.hartley> me? andrew.hartley> andrew.hartley> - OS: Windows 10 andrew.hartley> andrew.hartley> - Perl: ActivePerl 5.12.2 build 1202 andrew.hartley> andrew.hartley> - Development environment: MS Visual Studio 2010 SP1 andrew.hartley> andrew.hartley> - OpenSSL version: OpenSSL 1.1.0 andrew.hartley> andrew.hartley> I tried to compile and install OpenSSL 1.1.0 according to the andrew.hartley> following steps: andrew.hartley> andrew.hartley> 1. decompressed OpenSSL 1.1.0 software package to directory andrew.hartley> "D:\openssl-1.1.0"; andrew.hartley> andrew.hartley> 2. opened the "Visual Studio 2010 command prompt" window using an andrew.hartley> Administrator identity; andrew.hartley> andrew.hartley> 3. switched to the directory "D:\openssl-1.1.0"; andrew.hartley> andrew.hartley> 4. D:\openssl-1.1.0> perl Configure VC-WIN32; andrew.hartley> andrew.hartley> 5. D:\openssl-1.1.0> nmake; andrew.hartley> andrew.hartley> 6. D:\openssl-1.1.0> nmake test; andrew.hartley> andrew.hartley> > So far, all steps went smoothly, but ... andrew.hartley> andrew.hartley> 7. D:\openssl-1.1.0> nmake install; andrew.hartley> andrew.hartley> Here, I got the following error and there was no file being copied to andrew.hartley> the destination directories even though those directories were andrew.hartley> successfully created. andrew.hartley> andrew.hartley> Microsoft (R) program maintenance utility 10.00.30319.01 copy right andrew.hartley> (C) Microsoft Corporation.All rights reserved. andrew.hartley> andrew.hartley> *** Installing development files andrew.hartley> andrew.hartley> created directory 'C:/Program Files (x86)/OpenSSL' andrew.hartley> andrew.hartley> created directory 'C:/Program Files (x86)/OpenSSL/include' andrew.hartley> andrew.hartley> created directory 'C:/Program Files (x86)/OpenSSL/include/openssl' andrew.hartley> andrew.hartley> Can't Open "./ms/applink.c" at .\util\copy.pl line 61. andrew.hartley> andrew.hartley> NMAKE : fatal error U1077: ?C:\Perl\bin\perl.exe?: return code ?0x16? andrew.hartley> andrew.hartley> Stop. andrew.hartley> andrew.hartley> ______________________________________________________________________ andrew.hartley> Registered in England with company number 5347048 andrew.hartley> Registered office at Centurion House, London Road, andrew.hartley> Staines-upon-Thames, TW18 4AX andrew.hartley> andrew.hartley> This electronic message contains information from Tax Computer Systems andrew.hartley> Ltd (a wholly owned subsidiary of tax systems plc) which is andrew.hartley> confidential and may be privileged. The information is intended to be andrew.hartley> for the sole use of the individual(s) or entity to whom it is andrew.hartley> addressed. If you are not the intended recipient, be aware that any andrew.hartley> disclosure, copying, distribution or use of the contents of this andrew.hartley> information is prohibited. If you have received this electronic andrew.hartley> message in error, please notify the sender by telephone or e-mail (to andrew.hartley> the number or e-mail address above) immediately and destroy the andrew.hartley> message and all attached documents. andrew.hartley> andrew.hartley> Reasonable care has been taken to ensure that this communication (and andrew.hartley> any attachments or hyperlinks contained within it) is free from andrew.hartley> computer viruses. No responsibility is accepted by taxsystemsplc and andrew.hartley> the recipient should carry out any appropriate virus checks. andrew.hartley> ________________________________________________________________________ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ______________________________________________________________________ Registered in England with company number 5347048 Registered office at Centurion House, London Road, Staines-upon-Thames, TW18 4AX This electronic message contains information from Tax Computer Systems Ltd (a wholly owned subsidiary of tax systems plc) which is confidential and may be privileged. The information is intended to be for the sole use of the individual(s) or entity to whom it is addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify the sender by telephone or e-mail (to the number or e-mail address above) immediately and destroy the message and all attached documents. Reasonable care has been taken to ensure that this communication (and any attachments or hyperlinks contained within it) is free from computer viruses. No responsibility is accepted by taxsystemsplc and the recipient should carry out any appropriate virus checks. ________________________________________________________________________ From jingmliu at sina.com Wed Sep 21 14:18:17 2016 From: jingmliu at sina.com (Jing Liu) Date: Wed, 21 Sep 2016 22:18:17 +0800 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' In-Reply-To: <80186e15-4000-2a7d-f810-5e8d94988053@openssl.org> References: <80186e15-4000-2a7d-f810-5e8d94988053@openssl.org> Message-ID: <001001d21413$00454700$00cfd500$@sina.com> Dear Matt, I've already checked for the existence of the file ms/applink.c and also thought about the file permission problem. That file does exists in the directory and I ran all those commands as an administrator. Jing -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Wednesday, September 21, 2016 9:14 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' On 21/09/16 13:35, Jing Liu wrote: > Can't Open "./ms/applink.c" at .\util\copy.pl line 61. So, does the file ms/applink.c actually exist? And do you have permissions to open it? Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From jingmliu at sina.com Thu Sep 22 02:38:56 2016 From: jingmliu at sina.com (jingmliu at sina.com) Date: Thu, 22 Sep 2016 10:38:56 +0800 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' Message-ID: <20160922023856.1EF9F81000CC@webmail.sinamail.sina.com.cn> Dear Richard, I already checkded that the file "applink.c" does exist under the directory 'D:\openssl-1.1.0\ms'. I also considered the problem of access permission. That is why I ran all the commands as an administrator. Now, I used the Perl script provided by you to revise the original "copy.pl" as the following: ... ...foreach (@filelist) { ... ... } else { $dfile = $dest; } sysopen(IN, $_, O_RDONLY|O_BINARY) || die "Can't Open $_: $!"; sysopen(OUT, $dfile, O_WRONLY|O_CREAT|O_TRUNC|O_BINARY) || die "Can't Open $dfile: $!"; while (sysread IN, $buf, 10240)... ... I don't know much about Perl. I am afraid that I had made some mistake. Now, I got the following result: D:\openssl-1.1.0>nmake install Microsoft (R) ???????? 10.00.30319.01 ?????(C) Microsoft Corporation???????? *** Installing development filescreated directory `C:/Program Files (x86)/OpenSSL'created directory `C:/Program Files (x86)/OpenSSL/include'created directory `C:/Program Files (x86)/OpenSSL/include/openssl'Can't Open "./ms/applink.c": Invalid argument at .\util\copy.pl line 61.NMAKE : fatal error U1077: ?C:\Perl\bin\perl.exe?: returen code ?0x16?Stop. D:\openssl-1.1.0> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jingmliu at sina.com Thu Sep 22 06:08:33 2016 From: jingmliu at sina.com (Jing Liu) Date: Thu, 22 Sep 2016 14:08:33 +0800 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' Message-ID: <000001d21497$c0a239c0$41e6ad40$@sina.com> Dear Richard, I already checkded that the file "applink.c" does exist under the directory 'D:\openssl-1.1.0\ms'. I also considered the problem of access permission. That is why I ran all the commands as an administrator. Now, I used the Perl script provided by you to revise the original "copy.pl" as the following: ... ... foreach (@filelist) { ... ... } else { $dfile = $dest; } sysopen(IN, $_, O_RDONLY|O_BINARY) || die "Can't Open $_: $!"; sysopen(OUT, $dfile, O_WRONLY|O_CREAT|O_TRUNC|O_BINARY) || die "Can't Open $dfile: $!"; while (sysread IN, $buf, 10240) ... ... I don't know much about Perl. I am afraid that I had made some mistake. Now, I got the following result: D:\openssl-1.1.0>nmake install Microsoft (R) ???????? 10.00.30319.01 ? ????(C) Microsoft Corporation???????? *** Installing development files created directory `C:/Program Files (x86)/OpenSSL' created directory `C:/Program Files (x86)/OpenSSL/include' created directory `C:/Program Files (x86)/OpenSSL/include/openssl' Can't Open "./ms/applink.c": Invalid argument at .\util\copy.pl line 61. NMAKE : fatal error U1077: ?C:\Perl\bin\perl.exe?: returen code ?0x16? Stop. D:\openssl-1.1.0> -------------- next part -------------- An HTML attachment was scrubbed... URL: From googleersatz at oliverniebuhr.de Thu Sep 22 06:23:48 2016 From: googleersatz at oliverniebuhr.de (Oliver Niebuhr) Date: Thu, 22 Sep 2016 08:23:48 +0200 Subject: [openssl-users] OpenSSL 102 stable Git no-tls1 unknown option Message-ID: Good morning. I just created a local Git Branch and switched to 1.0.2-stable. I hoped the Commit "Fix the no-tls1 option" with ID 847fe929108da550b506594f52fa1875ea815723 would have finally fixed it but sadly it is still broken. Or I am getting something wrong. Configure Options: perl Configure no-ssl3 no-tls1 no-idea no-mdc2 no-rc5 VC-WIN32 --prefix=C:\opensslx86 Output in VS CMD Shell: Configuring for VC-WIN32 no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-idea [option] OPENSSL_NO_IDEA (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-mdc2 [option] OPENSSL_NO_MDC2 (skip dir) no-rc5 [option] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [default] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir) no-ssl3 [option] OPENSSL_NO_SSL3 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-tls1 [option] OPENSSL_NO_TLS1 (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=1 CC =cl CFLAG =-DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM EX_LIBS = CPUID_OBJ =x86cpuid.o BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o EC_ASM = DES_ENC =des-586.o crypt586.o AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o BF_ENC =bf-586.o CAST_ENC =cast-586.o RC4_ENC =rc4-586.o RC5_ENC =rc5-586.o MD5_OBJ_ASM =md5-586.o SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o RMD160_OBJ_ASM=rmd-586.o CMLL_ENC =cmll-x86.o MODES_OBJ =ghash-x86.o ENGINES_OBJ = PROCESSOR = RANLIB =true ARFLAGS = PERL =perl THIRTY_TWO_BIT mode BN_LLONG mode RC4_INDEX mode RC4_CHUNK is undefined Configured for VC-WIN32. running ms\do_nasm.bat and compiling OpenSSL unknown option - no-tls1 unknown option - no-tls1 unknown option - no-tls1 Is this already known and about to be fixed? Or should I create a new BR? Thanks Oliver -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From noloader at gmail.com Thu Sep 22 07:11:47 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 22 Sep 2016 03:11:47 -0400 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' In-Reply-To: References: Message-ID: On Wed, Sep 21, 2016 at 8:35 AM, Jing Liu wrote: > I?ve tried all my best to solve this problem but failed. Can you help me? > > - OS: Windows 10 > > - Perl: ActivePerl 5.12.2 build 1202 > > - Development environment: MS Visual Studio 2010 SP1 > > - OpenSSL version: OpenSSL 1.1.0 Have you tried Strawberry Perl instead of Active Perl? I seem to recall someone stated they were able to clear a similar issue using Strawberry Perl. Jeff From jingmliu at sina.com Thu Sep 22 09:28:59 2016 From: jingmliu at sina.com (Jing Liu) Date: Thu, 22 Sep 2016 17:28:59 +0800 Subject: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' Message-ID: <000001d214b3$c0f8ad70$42ea0850$@sina.com> Thanks for all people who kindly helped me. My problem is solved. I uninstalled ActivePerl 5.12.2 and instead installed the current version - ActivePerl 5.24.0.2400 (64bit). Now, I compiled and installed OpenSSL 1.1.0 successfully. Cheers, Jing -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jeffrey Walton Sent: Thursday, September 22, 2016 3:12 PM To: OpenSSL Users Subject: Re: [openssl-users] Failed to install OpenSSL 1.1.0 using 'nmake install' On Wed, Sep 21, 2016 at 8:35 AM, Jing Liu wrote: > I?ve tried all my best to solve this problem but failed. Can you help me? > > - OS: Windows 10 > > - Perl: ActivePerl 5.12.2 build 1202 > > - Development environment: MS Visual Studio 2010 SP1 > > - OpenSSL version: OpenSSL 1.1.0 Have you tried Strawberry Perl instead of Active Perl? I seem to recall someone stated they were able to clear a similar issue using Strawberry Perl. Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl at openssl.org Thu Sep 22 10:56:19 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 22 Sep 2016 10:56:19 +0000 Subject: [openssl-users] OpenSSL version 1.0.1u published Message-ID: <20160922105619.GA14190@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1u 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.1u 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.1-notes.html OpenSSL 1.0.1u 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.1u.tar.gz Size: 4567068 SHA1 checksum: 93e542696598517862115fbe76a93ab66369661d SHA256 checksum: 4312b4ca1215b6f2c97007503d80db80d5157f76f8f7d3febbe6b4c56ff26739 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.1u.tar.gz openssl sha256 openssl-1.0.1u.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX47LHAAoJENnE0m0OYESRBtwH/3+HUEkaq0AjniBI23BI3e42 AiU2dCKv4DvHo4x1lNHw79GCywY06saybIcdsIri8exR7JJqi2IJ5n7inL5GA0ss 3ts98r7mDmu3qd0Qo559avsb5ChVN4PIgAXbI76uoohmbpFYowHO7pVX75kXu6Eh STzjVxjlzkM7ka2CmE/D19x1sRWvlpwaWoBQ/DwUOC+1qpyMbTzqM/RODBucwT3T pqjivwSM6mgMYoWuAUMq/r4pvFCvS08GBOSf8XLNqLVNEgmO5b3FkuxxXnoR1m2R IjDqtn3d0aRTSruKsUXfVSwWgk+la3m8Hr8sCNACRZu03GSa0NwLXrc8vYH2iMM= =Ozj3 -----END PGP SIGNATURE----- From openssl at openssl.org Thu Sep 22 10:56:45 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 22 Sep 2016 10:56:45 +0000 Subject: [openssl-users] OpenSSL version 1.0.2i published Message-ID: <20160922105645.GA14378@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2i 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.2i 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.2i 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.2i.tar.gz Size: 5308232 SHA1 checksum: 25a92574ebad029dcf2fa26c02e10400a0882111 SHA256 checksum: 9287487d11c9545b6efb287cdb70535d4e9b284dd10d51441d9b9963d000de6f The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2i.tar.gz openssl sha256 openssl-1.0.2i.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX47F5AAoJENnE0m0OYESRetYH/18tGdVDBTKEEhDxYQZ+UYCk CQpQK9Bjamv8/zD8uhj+jN92gSccTR3cPZGA88lMu5SbM48G+eU5znA8xopeHtcQ nLhiQ4XTq/Y31nGXpyAwXQElRAiEXix5QP7CA3kSAJDLF18TTzbzJWXv4wFfUPKS /5smGDQyv+40P82uo0KcS0ZRGJTH933LQCK8qqrtduxxtQRdBMU+BYuLPJZrMyFt iN05WawKk1527tqN4pmqzEVBghzd1lGe/D5VKnm77UH8zYXYPWeVXNoUoKGldMFv QCnuZ1thYCLnaolLvfzM9L4bRtIT0cOsermmes6myjRJBXUQhipjcRm4z8UGQlY= =6DTt -----END PGP SIGNATURE----- From openssl at openssl.org Thu Sep 22 10:57:15 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 22 Sep 2016 10:57:15 +0000 Subject: [openssl-users] OpenSSL version 1.1.0a published Message-ID: <20160922105715.GA14577@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0a 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.0a 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.0a 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.0a.tar.gz Size: 5161414 SHA1 checksum: 335d7168b612efd3cf16f621b09d4cd5af4232a6 SHA256 checksum: c2e696e34296cde2c9ec5dcdad9e4f042cd703932591d395c389de488302442b The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0a.tar.gz openssl sha256 openssl-1.1.0a.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX468gAAoJENnE0m0OYESRMCUIAK+hb9xpoYbWNbGBm1rwp75G 9O0uBRCNtHEgyNcnrSW9bV0HT4v/EG64IFR9KmcTYn8Jc9GIh9176I/kb233V/sI 1MJ7sUmPXODKLp1Pjz8p8dcUrS1I+rO9QfLkgZD8LEEv3yaAzku4XVNPvyJ3v2Dg MYdz5qMvzEJBYtY2BlXbsTAlWj2h5kRvQpOTxS3jsNBEyU9o7HtQClFfHffcf80j tjiBw/oKmawQQSyz9ZcamUEd7YS3BAzCbdRXJd7halXfcJcEwu6ZcI7pNm+g6lHI WI0bxgX8K8olXzboWeF4AybfRgH5Y1hiMwpCrCjFWqWHbNA6A8lhJOb7NsOpOH4= =OiyL -----END PGP SIGNATURE----- From openssl at openssl.org Thu Sep 22 10:58:09 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 22 Sep 2016 10:58:09 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20160922105809.GA15135@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [22 Sep 2016] ======================================== OCSP Status Request extension unbounded memory growth (CVE-2016-6304) ===================================================================== Severity: High A malicious client can send an excessively large OCSP Status Request extension. If that client continually requests renegotiation, sending a large OCSP Status Request extension each time, then there will be unbounded memory growth on the server. This will eventually lead to a Denial Of Service attack through memory exhaustion. Servers with a default configuration are vulnerable even if they do not support OCSP. Builds using the "no-ocsp" build time option are not affected. Servers using OpenSSL versions prior to 1.0.1g are not vulnerable in a default configuration, instead only if an application explicitly enables OCSP stapling support. OpenSSL 1.1.0 users should upgrade to 1.1.0a OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 29th August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL development team. SSL_peek() hang on empty record (CVE-2016-6305) =============================================== Severity: Moderate OpenSSL 1.1.0 SSL/TLS will hang during a call to SSL_peek() if the peer sends an empty record. This could be exploited by a malicious peer in a Denial Of Service attack. OpenSSL 1.1.0 users should upgrade to 1.1.0a This issue was reported to OpenSSL on 10th September 2016 by Alex Gaynor. The fix was developed by Matt Caswell of the OpenSSL development team. SWEET32 Mitigation (CVE-2016-2183) ================================== Severity: Low SWEET32 (https://sweet32.info) is an attack on older block cipher algorithms that use a block size of 64 bits. In mitigation for the SWEET32 attack DES based ciphersuites have been moved from the HIGH cipherstring group to MEDIUM in OpenSSL 1.0.1 and OpenSSL 1.0.2. OpenSSL 1.1.0 since release has had these ciphersuites disabled by default. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 16th August 2016 by Karthikeyan Bhargavan and Gaetan Leurent (INRIA). The fix was developed by Rich Salz of the OpenSSL development team. OOB write in MDC2_Update() (CVE-2016-6303) ========================================== Severity: Low An overflow can occur in MDC2_Update() either if called directly or through the EVP_DigestUpdate() function using MDC2. If an attacker is able to supply very large amounts of input data after a previous call to EVP_EncryptUpdate() with a partial block then a length check can overflow resulting in a heap corruption. The amount of data needed is comparable to SIZE_MAX which is impractical on most platforms. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 11th August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. Malformed SHA512 ticket DoS (CVE-2016-6302) =========================================== Severity: Low If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a DoS attack where a malformed ticket will result in an OOB read which will ultimately crash. The use of SHA512 in TLS session tickets is comparatively rare as it requires a custom server callback and ticket lookup mechanism. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 19th August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. OOB write in BN_bn2dec() (CVE-2016-2182) ======================================== Severity: Low The function BN_bn2dec() does not check the return value of BN_div_word(). This can cause an OOB write if an application uses this function with an overly large BIGNUM. This could be a problem if an overly large certificate or CRL is printed out from an untrusted source. TLS is not affected because record limits will reject an oversized certificate before it is parsed. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 2nd August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. OOB read in TS_OBJ_print_bio() (CVE-2016-2180) ============================================== Severity: Low The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is the total length the OID text representation would use and not the amount of data written. This will result in OOB reads when large OIDs are presented. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 21st July 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. Pointer arithmetic undefined behaviour (CVE-2016-2177) ====================================================== Severity: Low Avoid some undefined pointer arithmetic A common idiom in the codebase is to check limits in the following manner: "p + len > limit" Where "p" points to some malloc'd data of SIZE bytes and limit == p + SIZE "len" here could be from some externally supplied data (e.g. from a TLS message). The rules of C pointer arithmetic are such that "p + len" is only well defined where len <= SIZE. Therefore the above idiom is actually undefined behaviour. For example this could cause problems if some malloc implementation provides an address for "p" such that "p + len" actually overflows for values of len that are too big and therefore p + len < limit. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 4th May 2016 by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team. Constant time flag not preserved in DSA signing (CVE-2016-2178) =============================================================== Severity: Low Operations in the DSA signing algorithm should run in constant time in order to avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations. This has been demonstrated through a cache-timing attack to be sufficient for an attacker to recover the private DSA key. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 23rd May 2016 by C??sar Pereida (Aalto University), Billy Brumley (Tampere University of Technology), and Yuval Yarom (The University of Adelaide and NICTA). The fix was developed by C??sar Pereida. DTLS buffered message DoS (CVE-2016-2179) ========================================= Severity: Low In a DTLS connection where handshake messages are delivered out-of-order those messages that OpenSSL is not yet ready to process will be buffered for later use. Under certain circumstances, a flaw in the logic means that those messages do not get removed from the buffer even though the handshake has been completed. An attacker could force up to approx. 15 messages to remain in the buffer when they are no longer required. These messages will be cleared when the DTLS connection is closed. The default maximum size for a message is 100k. Therefore the attacker could force an additional 1500k to be consumed per connection. By opening many simulataneous connections an attacker could cause a DoS attack through memory exhaustion. OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u This issue was reported to OpenSSL on 22nd June 2016 by Quan Luo. The fix was developed by Matt Caswell of the OpenSSL development team. DTLS replay protection DoS (CVE-2016-2181) ========================================== Severity: Low A flaw in the DTLS replay attack protection mechanism means that records that arrive for future epochs update the replay protection "window" before the MAC for the record has been validated. This could be exploited by an attacker by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means that all subsequent legitimate packets are dropped causing a denial of service for a specific DTLS connection. OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u This issue was reported to OpenSSL on 21st November 2015 by the OCAP audit team. The fix was developed by Matt Caswell of the OpenSSL development team. Certificate message OOB reads (CVE-2016-6306) ============================================= Severity: Low In OpenSSL 1.0.2 and earlier some missing message length checks can result in OOB reads of up to 2 bytes beyond an allocated buffer. There is a theoretical DoS risk but this has not been observed in practice on common platforms. The messages affected are client certificate, client certificate request and server certificate. As a result the attack can only be performed against a client or a server which enables client authentication. OpenSSL 1.1.0 is not affected. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 22nd August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. Excessive allocation of memory in tls_get_message_header() (CVE-2016-6307) ========================================================================== Severity: Low A TLS message includes 3 bytes for its length in the header for the message. This would allow for messages up to 16Mb in length. Messages of this length are excessive and OpenSSL includes a check to ensure that a peer is sending reasonably sized messages in order to avoid too much memory being consumed to service a connection. A flaw in the logic of version 1.1.0 means that memory for the message is allocated too early, prior to the excessive message length check. Due to way memory is allocated in OpenSSL this could mean an attacker could force up to 21Mb to be allocated to service a connection. This could lead to a Denial of Service through memory exhaustion. However, the excessive message length check still takes place, and this would cause the connection to immediately fail. Assuming that the application calls SSL_free() on the failed conneciton in a timely manner then the 21Mb of allocated memory will then be immediately freed again. Therefore the excessive memory allocation will be transitory in nature. This then means that there is only a security impact if: 1) The application does not call SSL_free() in a timely manner in the event that the connection fails or 2) The application is working in a constrained environment where there is very little free memory or 3) The attacker initiates multiple connection attempts such that there are multiple connections in a state where memory has been allocated for the connection; SSL_free() has not yet been called; and there is insufficient memory to service the multiple requests. Except in the instance of (1) above any Denial Of Service is likely to be transitory because as soon as the connection fails the memory is subsequently freed again in the SSL_free() call. However there is an increased risk during this period of application crashes due to the lack of memory - which would then mean a more serious Denial of Service. This issue does not affect DTLS users. OpenSSL 1.1.0 TLS users should upgrade to 1.1.0a This issue was reported to OpenSSL on 18th September 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL development team. Excessive allocation of memory in dtls1_preprocess_fragment() (CVE-2016-6308) ============================================================================= Severity: Low This issue is very similar to CVE-2016-6307. The underlying defect is different but the security analysis and impacts are the same except that it impacts DTLS. A DTLS message includes 3 bytes for its length in the header for the message. This would allow for messages up to 16Mb in length. Messages of this length are excessive and OpenSSL includes a check to ensure that a peer is sending reasonably sized messages in order to avoid too much memory being consumed to service a connection. A flaw in the logic of version 1.1.0 means that memory for the message is allocated too early, prior to the excessive message length check. Due to way memory is allocated in OpenSSL this could mean an attacker could force up to 21Mb to be allocated to service a connection. This could lead to a Denial of Service through memory exhaustion. However, the excessive message length check still takes place, and this would cause the connection to immediately fail. Assuming that the application calls SSL_free() on the failed conneciton in a timely manner then the 21Mb of allocated memory will then be immediately freed again. Therefore the excessive memory allocation will be transitory in nature. This then means that there is only a security impact if: 1) The application does not call SSL_free() in a timely manner in the event that the connection fails or 2) The application is working in a constrained environment where there is very little free memory or 3) The attacker initiates multiple connection attempts such that there are multiple connections in a state where memory has been allocated for the connection; SSL_free() has not yet been called; and there is insufficient memory to service the multiple requests. Except in the instance of (1) above any Denial Of Service is likely to be transitory because as soon as the connection fails the memory is subsequently freed again in the SSL_free() call. However there is an increased risk during this period of application crashes due to the lack of memory - which would then mean a more serious Denial of Service. This issue does not affect TLS users. OpenSSL 1.1.0 DTLS users should upgrade to 1.1.0a This issue was reported to OpenSSL on 18th September 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/policies/releasestrat.html), support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date. Users of 1.0.1 are advised to upgrade. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20160922.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX465bAAoJENnE0m0OYESRfvoIAIWUhH3TgJvgh+0N4Z3FODmK CjytKRsk13F6tGPocXab5kesm602tQvjF4re9bcSHfzgDKqdrsBcGvX0ouyLzIeK Smsa/CLP2X6BH8oGa2UIbnyA4dRssnO0HPXDUC69SvplYZbhXFD3sBDK6mVudq3G N+WZ7Rba5FpcybR4ha6h13man/ArVY2p24qr0pxrlOivsTDPKHdDsY2JfezoNCKM H12Zsds5bmDxepNaRj8DNvjGJqsXENc8LLMQ1R/djp/R7yNi6OO3IDxA74JXBDsN OR+sPxlyaO7TZcktSk6YOZ5tVACxtbQmo9Tac61Pbx1QwgffK1scq/WNGsjQ1XY= =JPtf -----END PGP SIGNATURE----- From rsalz at akamai.com Thu Sep 22 14:42:54 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 22 Sep 2016 14:42:54 +0000 Subject: [openssl-users] OpenSSL 102 stable Git no-tls1 unknown option In-Reply-To: References: Message-ID: It's no-tls From googleersatz at oliverniebuhr.de Thu Sep 22 16:37:07 2016 From: googleersatz at oliverniebuhr.de (Oliver Niebuhr) Date: Thu, 22 Sep 2016 18:37:07 +0200 Subject: [openssl-users] OpenSSL 102 stable Git no-tls1 unknown option In-Reply-To: References: Message-ID: On 22.09.2016 16:42, Salz, Rich wrote: > It's no-tls > > Thanks to Matt Caswell and Richard Levitte for todays "mk1mf.pl: check for no-tls1 here as well" it compiles now :) This works probably as expected: Side Effect: I cant use s_client $somedomain:443 -tls1 (-tls1_1 / -tls1_2) anymore to test if openssl dont use TLS1.0. If I run the test without any -tls* Parameter, it shows me the first TLS Version used - in the Test Case (my private Domain) TLS1.2. OpenSSL says: -tls* = unknown option when I try it. But it still shows up in the List of Arguments. So I think the List of Arguments / Options does not get updated when the User disable some things!? Thanks again for the extremely quick Fix! And thanks in general to everyone else contributing to the OpenSSL Project! Oliver A simple User -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From chengzju at qq.com Fri Sep 23 05:07:19 2016 From: chengzju at qq.com (=?gb18030?B?1qrstvTDvLo=?=) Date: Fri, 23 Sep 2016 13:07:19 +0800 Subject: [openssl-users] disable tls renegotiation to avoid the risk of OCSP Status Request extension unbounded memory growth Message-ID: Hi guys can i avoid the risk of "OCSP Status Request extension unbounded memory growth" if i disable server's tls renegotiation ? in deed, nginx diable tls renegotiation by default since 0.8.23. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Sep 23 07:44:29 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 23 Sep 2016 08:44:29 +0100 Subject: [openssl-users] disable tls renegotiation to avoid the risk of OCSP Status Request extension unbounded memory growth In-Reply-To: References: Message-ID: <7787ed2a-0f75-2db2-88d5-f7f289a29b38@openssl.org> On 23/09/16 06:07, ???? wrote: > Hi guys > can i avoid the risk of "OCSP Status Request extension unbounded > memory growth" if i disable server's tls renegotiation ? > in deed, nginx diable tls renegotiation by default since 0.8.23. The issue occurs as a result of the attacker continually renegotiating, growing the memory each time. If renegotiation is disabled then the issue cannot occur. OpenSSL itself does not provide an easy way for applications to disable renegotiation although I understand some applications have found workarounds for that. Matt From scott_n at xypro.com Fri Sep 23 16:13:47 2016 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 23 Sep 2016 16:13:47 +0000 Subject: [openssl-users] Disable a cipher suite in openssl.cnf? Message-ID: Hi, I'm afraid the man page on the conf file is not particularly clear. I'm looking at mitigating CVE-2016-2183 (SWEET32), and am not sure how to disable the DES and 3DES suites in the conf file. Can someone give me a hand? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michal.Trojnara at stunnel.org Fri Sep 23 19:45:20 2016 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Fri, 23 Sep 2016 21:45:20 +0200 Subject: [openssl-users] stunnel 5.35 released Message-ID: <8d242d41-12a1-7e8f-429b-4b58fa669e12@stunnel.org> Dear Users, I have released version 5.35 of stunnel. The ChangeLog entry: Version 5.35, 2016.07.18, urgency: HIGH * Bugfixes - Fixed incorrectly enforced client certificate requests. - Only default to SO_EXCLUSIVEADDRUSE on Vista and later. - Fixed thread safety of the configuration file reopening. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: ffa386ae4c825f35f35157c285e7402a6d58779ad8c3822f74a9d355b54aba1d stunnel-5.35.tar.gz 36e70e109d0283cd55c416eb261234f4c1b165409e1805df369bc774551f965c stunnel-5.35-installer.exe e671a4716fd36bde67850cdb5d17f54ee32b6afec9ad4ea6825d00f72a741cc5 stunnel-5.35-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From Michal.Trojnara at stunnel.org Fri Sep 23 19:56:00 2016 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Fri, 23 Sep 2016 21:56:00 +0200 Subject: [openssl-users] stunnel 5.36 released Message-ID: <5a4620ce-7f24-7a14-40bd-6a74fb19eefb@stunnel.org> Dear Users, I have released version 5.36 of stunnel. Version 5.36, 2016.09.22, urgency: HIGH * Security bugfixes - OpenSSL DLLs updated to version 1.0.2i. https://www.openssl.org/news/secadv_20160922.txt * New features - Added support for OpenSSL 1.1.0 built with "no-deprecated". - Removed direct zlib dependency. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: eb8952fcfdfcdf5056a1f1a78e1ec5014b819c5f5f7599b924dc4490ffe4b5ea stunnel-5.36.tar.gz 0164a45812ee2292574f898b1526062c2fbeccbb9c4e679a120b16e3284d2b0e stunnel-5.36-installer.exe a82c3978e113ecc55caefa5f169f622048f6aa434e6620e78e5d88a1885a3d69 stunnel-5.36-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From richmoore44 at gmail.com Sat Sep 24 15:04:40 2016 From: richmoore44 at gmail.com (Richard Moore) Date: Sat, 24 Sep 2016 16:04:40 +0100 Subject: [openssl-users] Disable a cipher suite in openssl.cnf? In-Reply-To: References: Message-ID: On 23 September 2016 at 17:13, Scott Neugroschl wrote: > Hi, > > > > I?m afraid the man page on the conf file is not particularly clear. I?m > looking at mitigating CVE-2016-2183 (SWEET32), and am not sure how to > disable the DES and 3DES suites in the conf file. > > Can someone give me a hand? > > > ?You can't disable them in the openssl config file, you should do it in the cipher suite configuration of the affected application. Cheers Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Sat Sep 24 21:12:00 2016 From: Walter.H at mathemainzel.info (Walter H.) Date: Sat, 24 Sep 2016 23:12:00 +0200 Subject: [openssl-users] Syntax question for subjectAltName certificate extension? Message-ID: <57E6EC20.70706@mathemainzel.info> Hello, what is correct: this: subjectAltName = DNS:www.example.com, IP:127.0.0.1, IP:[2001:db8:123::1] or this: subjectAltName = DNS:www.example.com, IP:127.0.0.1, IP:2001:db8:123::1 or the question in other words: do I have to put an IPv6 address of the subjectAltName in []-brackets? Thanks, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3827 bytes Desc: S/MIME Cryptographic Signature URL: From jvp at forthepolls.org Sat Sep 24 21:52:13 2016 From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=) Date: Sat, 24 Sep 2016 14:52:13 -0700 Subject: [openssl-users] Disable a cipher suite in openssl.cnf? In-Reply-To: References: Message-ID: <57E6F58D.6060409@forthepolls.org> Mr. Neugroschl's quest for a simple solution does bring up -- in my user-oriented opinion -- a very good follow-on question: "/Why cannot a config file be utilized by openssl to simply give access based on an allow/deny mechanism that would give users system-wide control in a single place?"./ the benefits of such an implementation are clearly manifold from the admin side. as a vulnerability arises, a weakness is revealed, a specific requirement is desired; a user can close out or enable any use of that avenue in a heartbeat ... permanently (/i.e./, persisting through updates), temporarily until a patch can be applied or a new release installed, or when requirements change. this would also greatly ease using openssl (think "views" in bind: although openssl's approach does not have to be as "unified" as bind's single config file) so that openssl could be tailored to different access methods such as intranet, tunnels, VPN's, et cetera. from the dev side i would think this approach would also have benefits worth exploring. FIPS immediately comes to mind. its hard-coded approach and protracted separate compliance certification could be distilled down to checking a hash (or some such security check) on a special over-riding config file when FIPS-enabled is encountered. this would also speed access to standards creators to modify the config file on the fly instead of interludes that can consume years despite industry-wide documentation/recognition that something must be done. then, openssl merely needs to be updated with the new hash or whatever. in fact, openssl could really foster transparency within the whole auth/encrypt process by creating its own allow/deny master listing that a user could modify at will without the need to be conversant at any type of coding. providing a more inclusive and user-friendly process also could, perhaps, forestall app's from "going-it-alone" or using other vendors such as experienced with openssh and lua. i DO realize that such a "modular" approach instead of "all-or-nothing" is not a simple matter from the dev side, but permitting the user an ability to go /a la carte/ according to specific needs seems highly attractive. it could also enable user migration scheduling (think sha1 to sha2, for instance) to keep pace with internal systems integration, configuration, and updating. there are also matters like the 25519 family which "enjoyed" a decade in virtual limbo until recently emerging as the "cats-meow" of speed and security (1. non-NSA/-NIST; 2. https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-03; and 3. https://ed25519.cr.yp.to). perhaps if more people saw that it was available via openssl (assuming openssl made it so) and did earlier experimenting with it the hiatus could have been foreshortened and everyone would have benefited. i know openssl cannot include /everything/, but this particular process is Daniel J. Bernstein after all and its "pluses" well-documented and long-known. BUDGETING: i cannot image the large-donor base NOT being enthusiastic re this approach. i also certainly see where openssl could attract new and more one-time/smaller donors to such a "crowd funding" project that exhibits a very real and visible translation of time to money. Thank you, Johann v. Preu?en On 2016.Sep.24 08:04, Richard Moore wrote: > > > On 23 September 2016 at 17:13, Scott Neugroschl > wrote: > > Hi, > > I?m afraid the man page on the conf file is not particularly clear. I?m > looking at mitigating CVE-2016-2183 (SWEET32), and am not sure how to > disable the DES and 3DES suites in the conf file. > > Can someone give me a hand? > > > ? You can't disable them in the openssl config file, you should do it in the > cipher suite configuration of the affected application. > > Cheers > > Rich. > ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3825 bytes Desc: S/MIME Cryptographic Signature URL: From rsalz at akamai.com Sat Sep 24 23:16:24 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 24 Sep 2016 23:16:24 +0000 Subject: [openssl-users] Disable a cipher suite in openssl.cnf? In-Reply-To: <57E6F58D.6060409@forthepolls.org> References: <57E6F58D.6060409@forthepolls.org> Message-ID: <44b5fccd64094e6c8b7b50c1eb3ff0f5@usma1ex-dag1mb1.msg.corp.akamai.com> > Mr. Neugroschl's quest for a simple solution does bring up -- in my user-oriented opinion -- a very good follow-on question: "Why cannot a config file be utilized by openssl to simply give access based on an allow/deny mechanism that would give users system-wide control in a single place?". We just haven't gotten around to it yet. From openssl-users at dukhovni.org Sun Sep 25 02:48:34 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 24 Sep 2016 22:48:34 -0400 Subject: [openssl-users] Disable a cipher suite in openssl.cnf? In-Reply-To: <44b5fccd64094e6c8b7b50c1eb3ff0f5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <57E6F58D.6060409@forthepolls.org> <44b5fccd64094e6c8b7b50c1eb3ff0f5@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <0779786A-DDC9-44E3-A127-3DF42E797B63@dukhovni.org> > On Sep 24, 2016, at 7:16 PM, Salz, Rich wrote: > >> >> Mr. Neugroschl's quest for a simple solution does bring up -- in my user-oriented opinion -- a very good follow-on question: "Why cannot a config file be utilized by openssl to simply give access based on an allow/deny mechanism that would give users system-wide control in a single place?". > > We just haven't gotten around to it yet. The SSL_CONF API (IIRC also in 1.0.2, definitely in 1.1.0) allows for shared settings in applications that use that API to set the defaults. Most applications are not using this yet... -- Viktor. From levitte at openssl.org Sun Sep 25 19:47:03 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 25 Sep 2016 21:47:03 +0200 (CEST) Subject: [openssl-users] Syntax question for subjectAltName certificate extension? In-Reply-To: <57E6EC20.70706@mathemainzel.info> References: <57E6EC20.70706@mathemainzel.info> Message-ID: <20160925.214703.1881168597554973729.levitte@openssl.org> In message <57E6EC20.70706 at mathemainzel.info> on Sat, 24 Sep 2016 23:12:00 +0200, "Walter H." said: Walter.H> Hello, Walter.H> Walter.H> what is correct: Walter.H> Walter.H> this: Walter.H> subjectAltName = DNS:www.example.com, IP:127.0.0.1, Walter.H> IP:[2001:db8:123::1] Walter.H> Walter.H> or this: Walter.H> subjectAltName = DNS:www.example.com, IP:127.0.0.1, IP:2001:db8:123::1 Walter.H> Walter.H> or the question in other words: do I have to put an IPv6 address of Walter.H> the subjectAltName in []-brackets? Without brackets. libcrypto will figure out that it's a IPv6 address from the presence of colons. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl at openssl.org Mon Sep 26 10:32:20 2016 From: openssl at openssl.org (OpenSSL) Date: Mon, 26 Sep 2016 10:32:20 +0000 Subject: [openssl-users] OpenSSL version 1.0.2j published Message-ID: <20160926103220.GA15647@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2j 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.2j 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.2j 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.2j.tar.gz Size: 5307912 SHA1 checksum: bdfbdb416942f666865fa48fe13c2d0e588df54f SHA256 checksum: e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2j.tar.gz openssl sha256 openssl-1.0.2j.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX6O9BAAoJENnE0m0OYESRsT8H/R7NWjLkFqUOwOTjyiqOKDWa YUAUNtSM+NWgHBS8GZwNlYyvCv7oIPIuJ1cG4mwTnWc2qpUFbbOkc6bhn/VhPWi5 bW6xOlof5Xbn86G5KM5HPe9t5Gay4RiU9+ePVa8Vkn4c3UcPNYVrYdDXEjv3UvJq 3VSOJDlAndaqMyBTtX5uK82pfd63kZWi9p2a+NCEojGcBSD/cyUYQpMUdomGU5K+ ZaRh2bHLNUjGUDLDqlgTDMv8p+OYUtQ6bgGpwBYw5zQeTZy7c43yTqUjvmuEaxaj XEeJqkv59Jty5uKqYmasVHgFY+EGsE0vw3troBrNFq2ZbVCqBx41C/kOZ3828HQ= =fLO/ -----END PGP SIGNATURE----- From openssl at openssl.org Mon Sep 26 10:32:40 2016 From: openssl at openssl.org (OpenSSL) Date: Mon, 26 Sep 2016 10:32:40 +0000 Subject: [openssl-users] OpenSSL version 1.1.0b published Message-ID: <20160926103240.GA15835@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0b 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.0b 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.0b 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.0b.tar.gz Size: 5162355 SHA1 checksum: cbf391d0d68a9f144c24c5c3c5028c07fa00264c SHA256 checksum: a45de072bf9be4dea437230aaf036000f0e68c6a665931c57e76b5b036cef6f7 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0b.tar.gz openssl sha256 openssl-1.1.0b.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX6O5iAAoJENnE0m0OYESRdEUIAKzNLCT+L0z6R6mUoHYMFT/4 jctbb93RX1nu3wx9ssRdlBikpVBa6vfsS2U4MWwyYSkRTbBHVlHuezq1/2FduXPF nsLT/tjPNmXqQPPTsceKx/p7nDAnSdapz6e36HJ/8erUR7nngHKUdalV0OqoQLeX Lz6ncYVH42qFPATMM4xJzcunmY3g+CXTORHAGBZLOM0HfSgAka/iQVC8aUlYWOMO E0pMalw9yRHzsFcR++9I/vpr9TcBj/falISsaGrgAxVNMkINYRITU8wWSO3+0y+N EkSi079/CNQx2LwoVW2qTPWdbbqMgYrUG3jsBlZUeVwvLfcXsVy2FHUep+FIb4k= =SQB4 -----END PGP SIGNATURE----- From openssl at openssl.org Mon Sep 26 10:35:38 2016 From: openssl at openssl.org (OpenSSL) Date: Mon, 26 Sep 2016 10:35:38 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20160926103538.GA17557@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [26 Sep 2016] ======================================== This security update addresses issues that were caused by patches included in our previous security update, released on 22nd September 2016. Given the Critical severity of one of these flaws we have chosen to release this advisory immediately to prevent upgrades to the affected version, rather than delaying in order to provide our usual public pre-notification. Fix Use After Free for large message sizes (CVE-2016-6309) ========================================================== Severity: Critical This issue only affects OpenSSL 1.1.0a, released on 22nd September 2016. The patch applied to address CVE-2016-6307 resulted in an issue where if a message larger than approx 16k is received then the underlying buffer to store the incoming message is reallocated and moved. Unfortunately a dangling pointer to the old location is left which results in an attempt to write to the previously freed location. This is likely to result in a crash, however it could potentially lead to execution of arbitrary code. OpenSSL 1.1.0 users should upgrade to 1.1.0b This issue was reported to OpenSSL on 23rd September 2016 by Robert ??wi??cki (Google Security Team), and was found using honggfuzz. The fix was developed by Matt Caswell of the OpenSSL development team. Missing CRL sanity check (CVE-2016-7052) ======================================== Severity: Moderate This issue only affects OpenSSL 1.0.2i, released on 22nd September 2016. A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0 but was omitted from OpenSSL 1.0.2i. As a result any attempt to use CRLs in OpenSSL 1.0.2i will crash with a null pointer exception. OpenSSL 1.0.2i users should upgrade to 1.0.2j The issue was reported to OpenSSL on 22nd September 2016 by Bruce Stephens and Thomas Jakobi. The fix was developed by Matt Caswell of the OpenSSL development team. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20160926.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX6PBJAAoJENnE0m0OYESRGacIALa7/Vg0SQzqjhD/KphCdKos BjkDcEO00y3JDyYqqQxfcrM9jSwBbrNzmHdEzBcPlvvDq9qhGwsODKbGylI2St5r zVHw1qA60/+Hu9PjaGT24a8MX+fPjA4RObB/BGZ7ViucZzCxqqtJob73InKwM8+9 OyjTmrphbyFa/Hk/OUWVzjatzQjEN+a5QplRTR2Sd4fBZDWowrtOdPGmbBQfRRgm AbEO5ZPaVKBoRuMk6JsR3LFymZ2FpHjLs9HNBtSmLLdzfIXxVE+uOb9b5wdAMP/3 4cTMkhfeS3RF0GuMT3EyH/EuZS6KkjuE8y/aVTq5s3yhK3ah5kT85IO1ps0yDx0= =WJwY -----END PGP SIGNATURE----- From gjcoram at gmail.com Mon Sep 26 14:44:00 2016 From: gjcoram at gmail.com (Geoffrey Coram) Date: Mon, 26 Sep 2016 10:44:00 -0400 Subject: [openssl-users] integral size mismatch in EVP_DecodeInit Message-ID: <20160926104400.E9A73488.gjcoram@gmail.com> Hi - I'm building OpenSSL 1.0.2j for Windows CE; my build just failed this morning with an "integral size mismatch in argument." In crypto\evp\encode.c, there's this declaration: static unsigned char conv_ascii2bin(unsigned char a); but in the function int EVP_DecodeUpdate(...) the call v = conv_ascii2bin(tmp); has an argument 'tmp' that's declared as an integer. I changed it to an unsigned char, and that seems to have fixed that issue. There's another issue with a call to ASN1_GENERALIZEDTIME_adj() in crypto\x509v3\v3_scts.c And another in a call to dtls1_set_message_header() in ssl\d1_lib.c: the declaration for unsigned char *dtls1_set_message_header() says the second argument is unsigned char mt, but in static void dtls1_set_handshake_header(SSL *s, int htype, unsigned long len) the "int htype" is passed as the second argument. -Geoffrey From tony.reix at atos.net Mon Sep 26 15:26:24 2016 From: tony.reix at atos.net (REIX, Tony) Date: Mon, 26 Sep 2016 15:26:24 +0000 Subject: [openssl-users] Why 1.0.1 AND 1.0.2 ? Message-ID: <1405d92a-1ee4-3e32-1837-147184053c3b@atos.net> Hi, We (BullFreeware project: http://www.bullfreeware.com/) port OpenSSL on AIX, since ages. Since BullFreeware is not a distro (we do not deliver packages built all-together, rather we deliver RPM packages than may stay un-updated during years), we maintain a compatibility with older versions by delivering several versions of .so files. About OpenSSL, when delivering version 1.1.0(b), we also deliver older versions: 1.0.1(u) and 1.0.2(j), as .so files and mainly as .so included in .a archives. (Though all other packages make use of .a archives, the .so files are sometimes required, like by test programs directly loading .so files). # rpm2cpio /opt/freeware/src/packages/RPMS/ppc/openssl-1.1.0b-1withsslv2.aix6.1.ppc.rpm | cpio -itv | grep "\.a" -rw-r--r-- 1 root system 39232261 Sep 26 16:56 opt/freeware/lib/libcrypto.a -rw-r--r-- 1 root system 7976472 Sep 26 16:56 opt/freeware/lib/libssl.a # /usr/bin/ar -X32 -tv opt/freeware/lib/libcrypto.a rwxr-xr-x 0/0 3564172 Sep 26 16:50 2016 libcrypto.so.1.1.0 rwxr-xr-x 0/0 2920785 Sep 26 16:53 2016 libcrypto.so.1.0.0 rwxr-xr-x 0/0 3486254 Sep 26 16:53 2016 libcrypto.so.1.0.1 rwxr-xr-x 0/0 3637981 Sep 26 16:53 2016 libcrypto.so.1.0.2 # /usr/bin/ar -X32 -tv opt/freeware/lib/libssl.a rwxr-xr-x 0/0 764960 Sep 26 16:50 2016 libssl.so.1.1.0 rwxr-xr-x 0/0 571439 Sep 26 16:53 2016 libssl.so.1.0.0 rwxr-xr-x 0/0 672674 Sep 26 16:53 2016 libssl.so.1.0.1 rwxr-xr-x 0/0 798812 Sep 26 16:53 2016 libssl.so.1.0.2 However, out of more ABIs delivered by 1.0.2 compared to 1.0.1, I do not understand what is the exact difference between versions 1.0.1 and 1.0.2 . I've reread the page: https://www.openssl.org/policies/releasestrat.html and that did not help me too much. I've also found this page: https://abi-laboratory.pro/tracker/timeline/openssl/ . But it does make it much clearer. I think that I have understood that the 1.0.0 series contains the 1.0.0, 1.0.1 and 1.0.2 versions. And, since 1.0.0 version is no longer supported, end-users should move (should have already moved) to the most recent version. However, why do you still (till end of 2016) deliver new versions for both 1.0.1 and 1.0.2 : why 1.0.1 is still alive in parallel with 1.0.2 ? How are they different (out of 1.0.2 delivering more ABIs than 1.0.1) ? How 1.0.1 and 1.0.2 are different from 1.0.0 (out of 1.0.2 and 1.0.1 delivering more ABIs than 1.0.0) ? Would it be sufficient to deliver 1.0.2 now, and no more 1.0.1 ? Why an application would need or be required to stay with 1.0.1 and not move to 1.0.2 right now ? Thanks Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Sep 26 15:53:25 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 26 Sep 2016 15:53:25 +0000 Subject: [openssl-users] Why 1.0.1 AND 1.0.2 ? In-Reply-To: <1405d92a-1ee4-3e32-1837-147184053c3b@atos.net> References: <1405d92a-1ee4-3e32-1837-147184053c3b@atos.net> Message-ID: <2e6b57ebd3d9432e8c9cd9b1d813abfc@usma1ex-dag1mb1.msg.corp.akamai.com> > However, out of more ABIs delivered by 1.0.2 compared to 1.0.1, I do not understand what is the exact difference between versions 1.0.1 and 1.0.2 . Perhaps look at the CHANGES file in 1.0.2 and see what's been added? 1.0.1 only gets bugfixes, 1.0.2 adds features, but starting with 1.0.2a only gets bugfixes. Hope this help. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From gjcoram at gmail.com Mon Sep 26 15:56:51 2016 From: gjcoram at gmail.com (Geoffrey Coram) Date: Mon, 26 Sep 2016 11:56:51 -0400 Subject: [openssl-users] calloc vs kssl_calloc Message-ID: <20160926115651.6018EB40.gjcoram@gmail.com> Hi - In kssl.c around line 747, there's a definition of kssl_calloc. Why, then, on line 875, is there a call to just "calloc" ? Also line 1230,1262, 2058. (This is in openssl-1.0.2j) Thanks. From rsalz at akamai.com Mon Sep 26 16:01:59 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 26 Sep 2016 16:01:59 +0000 Subject: [openssl-users] calloc vs kssl_calloc In-Reply-To: <20160926115651.6018EB40.gjcoram@gmail.com> References: <20160926115651.6018EB40.gjcoram@gmail.com> Message-ID: <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com> Kssl_calloc calls openssl_malloc which means the data must be free'd with openssl_free. And in debug builds any non-free'd data is a leak and reported. Ton line 875 the data is allocated and never free'd, so it skips the leak detection. In some of those other places, perhaps it's because the KRB API needs something it can free or realloc? I'm not sure. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From bkaduk at akamai.com Mon Sep 26 16:11:08 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 26 Sep 2016 11:11:08 -0500 Subject: [openssl-users] calloc vs kssl_calloc In-Reply-To: <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160926115651.6018EB40.gjcoram@gmail.com> <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com> On 09/26/2016 11:01 AM, Salz, Rich wrote: > Kssl_calloc calls openssl_malloc which means the data must be free'd with openssl_free. And in debug builds any non-free'd data is a leak and reported. Ton line 875 the data is allocated and never free'd, so it skips the leak detection. In some of those other places, perhaps it's because the KRB API needs something it can free or realloc? I'm not sure. > It doesn't look like the allocated memory is used as input to a krb5 routine, so I think it's just a bug. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjcoram at gmail.com Mon Sep 26 16:32:58 2016 From: gjcoram at gmail.com (Geoffrey Coram) Date: Mon, 26 Sep 2016 12:32:58 -0400 Subject: [openssl-users] calloc vs kssl_calloc In-Reply-To: <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com> References: <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com> <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com> Message-ID: <20160926123258.F0AA5680.gjcoram@gmail.com> On 09/26/2016 12:11, Benjamin Kaduk wrote: > > On 09/26/2016 11:01 AM, Salz, Rich wrote: > > Kssl_calloc calls openssl_malloc which means the data must be > free'd with openssl_free. And in debug builds any non-free'd data is > a leak and reported. Ton line 875 the data is allocated and never > free'd, so it skips the leak detection. In some of those other > places, perhaps it's because the KRB API needs something it can free > or realloc? I'm not sure. > > > > It doesn't look like the allocated memory is used as input to a krb5 > routine, so I think it's just a bug. > > -Ben As it turns out, that wasn't the code that was giving me trouble in my application. Instead, it's the code in crypto\LPdir_win.c, which is included via crypto\LPdir_wince.c, which is included in crypto\o_dir.c I found a portability tip on the web that says not to use malloc or calloc in Windows CE applications. (Actually, Google found me a result in the book "Making Win32 Applications Mobile" by Nancy Nicolaisen.) I've cc'ed Richard Levitte, who is credited for LPdir_win.c, perhaps he can comment on whether LocalAlloc would be an appropriate replacement. Thanks. From elizatom at yahoo.com Mon Sep 26 16:55:57 2016 From: elizatom at yahoo.com (shanthi thomas) Date: Mon, 26 Sep 2016 16:55:57 +0000 (UTC) Subject: [openssl-users] openssl asn1parse using both -genstr and -genconf options In-Reply-To: <20160910232002.GA8402@openssl.org> References: <2022828529.2809903.1473509192034.ref@mail.yahoo.com> <2022828529.2809903.1473509192034@mail.yahoo.com> <20160910232002.GA8402@openssl.org> Message-ID: <407053574.4900814.1474908957592@mail.yahoo.com> That certainly helped me move along. Thank you!Is there a place where the genconf file format is explained? It does not support everything in the openssl config file format.?I was wondering if a file could be specified instead of an ENVIRONMENT variable as well.? From: Dr. Stephen Henson To: shanthi thomas ; openssl-users at openssl.org Sent: Saturday, September 10, 2016 6:20 PM Subject: Re: [openssl-users] openssl asn1parse using both -genstr and -genconf options On Sat, Sep 10, 2016, shanthi thomas wrote: > Hi,? ? I'm trying to use openssl asn1parse subprogram to encode an ASN1 > structure. Some of the data in the ASN1 structure is static and I was > planning to use a CONF file as shown in the examples for this via the > -genconf option. However some of the data I need to pass via a command line > argument for which I was planning to use the -genstr option.?However, I'm > not sure how to use both the -genstr and the -genconf in a single command. I > could find any examples of this either. ?Can someone point me to any good > examples on how to use both these options together? While you can use -genstr and -genconf together their use is rather limited and probably wont do what you want. Instead I'd suggest passing values using environment variables and uses the config file environment variable options to include them in the appropriate places. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wei.sun at consumersoft.com Mon Sep 26 23:05:41 2016 From: wei.sun at consumersoft.com (Wei Sun) Date: Mon, 26 Sep 2016 18:05:41 -0500 Subject: [openssl-users] Building on Windows against run-time library Message-ID: <69f2203e9f824b0c9f3028dcd2bc13d0@consumersoft.com> Hello, Just joined the list, and apologize if the following question was answered before. I'm building openssl 1.1.0b on Windows. It is stated that it defaults to /MD while building openssl, so is there a way to change the linker option to /MT? Wei, regards From tony.reix at atos.net Tue Sep 27 07:52:28 2016 From: tony.reix at atos.net (REIX, Tony) Date: Tue, 27 Sep 2016 07:52:28 +0000 Subject: [openssl-users] Why 1.0.1 AND 1.0.2 ? In-Reply-To: <2e6b57ebd3d9432e8c9cd9b1d813abfc@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1405d92a-1ee4-3e32-1837-147184053c3b@atos.net> <2e6b57ebd3d9432e8c9cd9b1d813abfc@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <19c06e38-e941-7c66-57c4-c5e2a3c332bb@atos.net> Reading the 1.0.2j CHANGES file, it appears that 1.0.2 was built from 1.0.1l. And there are 1124 of description of the changes for 1.0.2 and about 500 lines of changes from 1.0.1l to 1.0.1u . And my knowledge of OpenSSL is VERY VERY small. Looking at 1.0.1l, out of bug fixes, I've found some changes that do not look as bugfixes: - dhparam: generate 2048-bit parameters by default. (1.0.1n) - Reject DH handshakes with parameters shorter than 768 bits. - In DSA_generate_parameters_ex, if the provided seed is too short, use a random seed, as already documented. - Reject DH handshakes with parameters shorter than 1024 bits. - Disable SRP fake user seed to address a server memory leak. Add a new method SRP_VBASE_get1_by_user that handles the seed properly. - Remove LOW from the DEFAULT cipher list. This removes singles DES from the default. However, only the first one, in bold, appears in 1.0.1l and NOT in 1.0.2j . So, my question is still: Why OpenSSL still delivers 1.0.1* though 1.0.2* should provide the same changes plus new features ? Because change "dhparam: generate 2048-bit parameters by default." appears in 1.0.1[n-l] and not in 1.0.2* ??? I need to know in order to decide if I still manage 1.0.1 compatibility in addition to delivering 1.0.2[last version] . Help is welcome ! Tony Le 26/09/2016 ? 17:53, Salz, Rich a ?crit : However, out of more ABIs delivered by 1.0.2 compared to 1.0.1, I do not understand what is the exact difference between versions 1.0.1 and 1.0.2 . Perhaps look at the CHANGES file in 1.0.2 and see what's been added? 1.0.1 only gets bugfixes, 1.0.2 adds features, but starting with 1.0.2a only gets bugfixes. Hope this help. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden at endoframe.com Mon Sep 26 20:04:20 2016 From: braden at endoframe.com ('Braden McDaniel') Date: Mon, 26 Sep 2016 16:04:20 -0400 Subject: [openssl-users] "nmake install" attempts to write outside of prefix Message-ID: After configuring with a prefix (other than "C:\Program Files"), it seems that "nmake install" still attempts to write to "C:\Program Files\Common Files\SSL". Is there some other way to suppress this, or is this a bug in the current build system? I am using OpenSSL 1.1.0b with platform VC-WIN64A. Braden From matt at openssl.org Tue Sep 27 08:21:27 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Sep 2016 09:21:27 +0100 Subject: [openssl-users] Why 1.0.1 AND 1.0.2 ? In-Reply-To: <19c06e38-e941-7c66-57c4-c5e2a3c332bb@atos.net> References: <1405d92a-1ee4-3e32-1837-147184053c3b@atos.net> <2e6b57ebd3d9432e8c9cd9b1d813abfc@usma1ex-dag1mb1.msg.corp.akamai.com> <19c06e38-e941-7c66-57c4-c5e2a3c332bb@atos.net> Message-ID: <32c87363-8f99-05dc-9bec-b93bd4df8def@openssl.org> On 27/09/16 08:52, REIX, Tony wrote: > Reading the 1.0.2j CHANGES file, it appears that 1.0.2 was built from > 1.0.1l. > And there are 1124 of description of the changes for 1.0.2 and about 500 > lines of changes from 1.0.1l to 1.0.1u . > And my knowledge of OpenSSL is VERY VERY small. > > Looking at 1.0.1l, out of bug fixes, I've found some changes that do not > look as bugfixes: > - *dhparam: generate 2048-bit parameters by default. (1.0.1n)* > - Reject DH handshakes with parameters shorter than 768 bits. > - In DSA_generate_parameters_ex, if the provided seed is too short, use > a random seed, as already documented. > - Reject DH handshakes with parameters shorter than 1024 bits. > - Disable SRP fake user seed to address a server memory leak. > Add a new method SRP_VBASE_get1_by_user that handles the seed properly. > - Remove LOW from the DEFAULT cipher list. This removes singles DES > from the default. > > However, only the first one, in bold, appears in 1.0.1l and NOT in 1.0.2j . That's just an omission. dhparam has generated 2048-bit parameters by default in 1.0.2 since its first release. > > > So, my question is still: > > Why OpenSSL still delivers 1.0.1* though 1.0.2* should provide the same > changes plus new features ? 1.0.1 should be binary compatible with 1.0.2 (as long as they are compiled with the same configuration options etc). However many users still prefer to use an exactly matching version. > Because change "*dhparam: generate 2048-bit parameters by default."* > appears in 1.0.1[n-l] and not in 1.0.2* ??? > > > I need to know in order to decide if I still manage 1.0.1 compatibility > in addition to delivering 1.0.2[last version] . 1.0.1 is nearing end-of-life. From the beginning of this year it has been receiving security fixes only. From the end of this year it will be out of support completely. All users should be making plans to move off of 1.0.1 if they are still using it, and transitioning to 1.0.2. This should be a very easy move. Matt From jaroslav.imrich at gmail.com Tue Sep 27 08:49:47 2016 From: jaroslav.imrich at gmail.com (Jaroslav Imrich) Date: Tue, 27 Sep 2016 10:49:47 +0200 Subject: [openssl-users] "nmake install" attempts to write outside of prefix In-Reply-To: References: Message-ID: On 26 September 2016 at 22:04, Braden McDaniel wrote: > After configuring with a prefix (other than "C:\Program Files"), it seems > that "nmake install" still attempts to write to "C:\Program Files\Common > Files\SSL". Is there some other way to suppress this, or is this a bug in > the current build system? > You need to use both --prefix and --openssldir arguments. Regards, Jaroslav -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Sep 27 12:50:03 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Sep 2016 12:50:03 +0000 Subject: [openssl-users] Why 1.0.1 AND 1.0.2 ? In-Reply-To: <19c06e38-e941-7c66-57c4-c5e2a3c332bb@atos.net> References: <1405d92a-1ee4-3e32-1837-147184053c3b@atos.net> <2e6b57ebd3d9432e8c9cd9b1d813abfc@usma1ex-dag1mb1.msg.corp.akamai.com> <19c06e38-e941-7c66-57c4-c5e2a3c332bb@atos.net> Message-ID: <0935173f77f84c0dadf5bff486bbf7ed@usma1ex-dag1mb1.msg.corp.akamai.com> (Can you change your mailer to plaintext, or at least get rid of the black-on-grey styling?) > Reading the 1.0.2j CHANGES file, it appears that 1.0.2 was built from 1.0.1l. That might be the time it was branched off from it. At that point, the two releases are different. >And my knowledge of OpenSSL is VERY VERY small. Okay. But you are going to have a hard time understanding changes, then. >Looking at 1.0.1l, out of bug fixes, I've found some changes that do not look as bugfixes: Those are security issues. When someone publishes a paper that shows a weak DH key can be cracked in an hour, then a security toolkit must "move up" to longer keys by default. This article might be useful: https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ and the "SWEET32" article will talk about the DES changes. > However, only the first one, in bold, appears in 1.0.1l and NOT in 1.0.2j . No. The entry just before "28 jan" in the CHANGES file. >Why OpenSSL still delivers 1.0.1* though 1.0.2* should provide the same changes plus new features ? Your confusion is thinking that "upgraded security parameters" are new feature, and not security fixes. >Because change "dhparam: generate 2048-bit parameters by default." appears in 1.0.1[n-l] and not in 1.0.2* ??? It is. > I need to know in order to decide if I still manage 1.0.1 compatibility in addition to delivering 1.0.2[last version] . You can do what you want :) Openssl 1.0.1 becomes unsupported at the end of 2016. If you want to tell your users that you are ending support early, nobody can stop you. :) From Michael.Wojcik at microfocus.com Tue Sep 27 13:07:17 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 27 Sep 2016 13:07:17 +0000 Subject: [openssl-users] Building on Windows against run-time library In-Reply-To: <69f2203e9f824b0c9f3028dcd2bc13d0@consumersoft.com> References: <69f2203e9f824b0c9f3028dcd2bc13d0@consumersoft.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Wei Sun > Sent: Monday, September 26, 2016 19:06 > > Just joined the list, and apologize if the following question was answered > before. > > I'm building openssl 1.1.0b on Windows. It is stated that it defaults to > /MD while building openssl, so is there a way to change the linker option > to /MT? We're still using 1.0.2, so I don't know if the 1.1.0 build system is significantly different; but we use a build script of our own which edits the Perl build scripts (using Cygwin sed) after extracting the tarball and before running the OpenSSL build process. One of the things it does is force the C RTS linker switches we want. I don't know of a cleaner way to handle this particular aspect of build configuration. It's been some years since I looked into it, though. It's not an issue for us because our build scripts do a bunch of other things (as part of our integration process) besides extracting the sources and building OpenSSL, so adding this step wasn't burdensome. Michael Wojcik Distinguished Engineer, Micro Focus From marquess at openssl.com Tue Sep 27 13:41:30 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 27 Sep 2016 09:41:30 -0400 Subject: [openssl-users] new FIPS module Message-ID: <744d4295-9aa1-63f3-b1f9-2d781c5e5947@openssl.com> As always, if you don't care about FIPS 140 then count yourself lucky and move on. Work on the new FIPS module has so far taken a backseat to higher priority topics like the 1.1 release and security vulnerabilities, but we should start to make some progress soon. I've put together a rough wiki page outlining some goals for the new FIPS module: https://wiki.openssl.org/index.php/FIPS_module_3.0 Within the very tight constraints of schedule, resources, and what is permitted by FIPS 140, we want this FIPS module to be as widely useful as possible. If we've omitted anything of vital importance please speak up. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jb-openssl at wisemo.com Tue Sep 27 14:35:19 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 27 Sep 2016 16:35:19 +0200 Subject: [openssl-users] new FIPS module In-Reply-To: <744d4295-9aa1-63f3-b1f9-2d781c5e5947@openssl.com> References: <744d4295-9aa1-63f3-b1f9-2d781c5e5947@openssl.com> Message-ID: <5df1066c-9726-b8f5-751e-94a3e4cdc54e@wisemo.com> On 27/09/2016 15:41, Steve Marquess wrote: > As always, if you don't care about FIPS 140 then count yourself lucky > and move on. > > Work on the new FIPS module has so far taken a backseat to higher > priority topics like the 1.1 release and security vulnerabilities, but > we should start to make some progress soon. I've put together a rough > wiki page outlining some goals for the new FIPS module: > > https://wiki.openssl.org/index.php/FIPS_module_3.0 > > Within the very tight constraints of schedule, resources, and what is > permitted by FIPS 140, we want this FIPS module to be as widely useful > as possible. > > If we've omitted anything of vital importance please speak up. Here's one practical thing (as a suggestion): - To ensure compatibility with platform ASLR, build the FIPS cannister as completely position independent code with no relocations whenever platforms allow. This probably requires that the FIPS cannister makes all calls to outside libraries as callbacks to function pointers supplied during module init, or at least via a function table that is outside the hashed FIPS cannister. 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 Zeke.Evans at microfocus.com Tue Sep 27 14:57:54 2016 From: Zeke.Evans at microfocus.com (Zeke Evans) Date: Tue, 27 Sep 2016 14:57:54 +0000 Subject: [openssl-users] new FIPS module In-Reply-To: <744d4295-9aa1-63f3-b1f9-2d781c5e5947@openssl.com> References: <744d4295-9aa1-63f3-b1f9-2d781c5e5947@openssl.com> Message-ID: > As always, if you don't care about FIPS 140 then count yourself lucky and > move on. > > Work on the new FIPS module has so far taken a backseat to higher priority > topics like the 1.1 release and security vulnerabilities, but we should start to > make some progress soon. I've put together a rough wiki page outlining > some goals for the new FIPS module: > > https://wiki.openssl.org/index.php/FIPS_module_3.0 > > Within the very tight constraints of schedule, resources, and what is > permitted by FIPS 140, we want this FIPS module to be as widely useful as > possible. > > If we've omitted anything of vital importance please speak up. The fixed base address requirement causes problems for large Windows x86 applications and there isn't a great work around. It isn't clear to me if item 2 " Support compilation in various forms" will address this or not. An option to compile the fips module as a dll instead of a static lib would be nice or at least allow the fips capable module to be rebased. Zeke Evans Senior Software Engineer Micro Focus From graeme.perrow at sap.com Tue Sep 27 14:56:25 2016 From: graeme.perrow at sap.com (Perrow, Graeme) Date: Tue, 27 Sep 2016 14:56:25 +0000 Subject: [openssl-users] Building FIPS-capable OpenSSL on Linux PPC64 Message-ID: <97b49e1490b44222a7e5296db0b17e83@dewdfe13de43.global.corp.sap> I am trying to build FIPS OpenSSL libraries for Linux PPC64 but it does not seem possible. This has been raised before (link below) but I didn't see any resolution. http://openssl.6102.n7.nabble.com/BUG-FIPS-capable-OpenSSL-fails-to-build-on-Linux-PPC64-td66890.html I can build it if I run "./Configure linux-ppc64" but it is my understanding that you **must** build the FIPS libraries using "./config" or "./config no-asm". Is there a workaround? Is there a fix coming? Given that the problem is within the FIPS module, is a fix possible without recertification? Thanks Graeme Perrow -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Sep 27 15:19:22 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 27 Sep 2016 11:19:22 -0400 Subject: [openssl-users] Building FIPS-capable OpenSSL on Linux PPC64 In-Reply-To: <97b49e1490b44222a7e5296db0b17e83@dewdfe13de43.global.corp.sap> References: <97b49e1490b44222a7e5296db0b17e83@dewdfe13de43.global.corp.sap> Message-ID: <004921e6-f9ce-ddc2-a193-16b66f36e102@openssl.com> On 09/27/2016 10:56 AM, Perrow, Graeme wrote: > I am trying to build FIPS OpenSSL libraries for Linux PPC64 but it does > not seem possible. This has been raised before (link below) but I didn?t > see any resolution. > > > > http://openssl.6102.n7.nabble.com/BUG-FIPS-capable-OpenSSL-fails-to-build-on-Linux-PPC64-td66890.html > > > > I can build it if I run ?./Configure linux-ppc64? but it is my > understanding that you ***must*** build the FIPS libraries using > ?./config? or ?./config no-asm?. Is there a workaround? Is there a fix > coming? Given that the problem is within the FIPS module, is a fix > possible without recertification? > > > > Thanks > > Graeme Perrow > > > > > Well, your first and biggest problem is that no Linux on 64-bit PPC platforms ("OEs") have been validated. So whether you can build it there or not it moot. We can still add platforms to the 2.0 FIPS module, but of course that takes time and money. Typically we would introduce new architecture targets in config/Configure as necessary to accommodate the requirement that command line options not be used (that's where most of the revision bumps come from). -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From brian.paquin at yale.edu Tue Sep 27 17:14:29 2016 From: brian.paquin at yale.edu (Paquin, Brian) Date: Tue, 27 Sep 2016 17:14:29 +0000 Subject: [openssl-users] Can't compile Apache 2.4.23 with OpenSSL 1.1.0b Message-ID: <252BCE41-8C78-408C-8CAE-3959F8B04625@yale.edu> When I try to compile Apache 2.4.23 with OpenSSL 1.1.0b I get: secure:httpd-2.4.23 administrator$ sudo make <--many lines cut out--> /Users/administrator/Downloads/httpd-2.4.23/srclib/apr/libtool --silent --mode=link gcc -arch x86_64 -L/usr/local/openssl/lib -lssl -lcrypto -lpthread \ -o ab ab.lo /Users/administrator/Downloads/httpd-2.4.23/srclib/apr-util/libaprutil-1.la -lexpat -liconv /Users/administrator/Downloads/httpd-2.4.23/srclib/apr/libapr-1.la -lpthread Undefined symbols for architecture x86_64: "_CRYPTO_malloc_init", referenced from: _main in ab.o "_SSLv2_client_method", referenced from: _main in ab.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [ab] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 It compiles fine with 1.0.1j, but I am curious what I need to change to get 1.1.0b working? (this may be for the httpd mailing list, but since it was specific to v1.1.0 I thought I would start here. OS is Mac OS X 10.11.6. Thank you, Brian From wei.sun at consumersoft.com Tue Sep 27 18:49:53 2016 From: wei.sun at consumersoft.com (Wei Sun) Date: Tue, 27 Sep 2016 13:49:53 -0500 Subject: [openssl-users] Building on Windows against run-time library In-Reply-To: References: <69f2203e9f824b0c9f3028dcd2bc13d0@consumersoft.com> Message-ID: Hello, I'm new to the openssl build system and I'm sure there is some script I could change/add for different linking behaviors. It seems it uses /MD to build shared library and /MT to build static library for 1.1.0b. And I was able to edit generated makefile to change run-time dependency, it's not optimal solution, but it would be easiest one for our case for now. -------- Original Message -------- - From: "Michael Wojcik" - Sent: Tuesday, September 27, 2016 6:08 AM - To: "openssl-users at openssl.org" - Subject: Re: [openssl-users] Building on Windows against run-time library - - > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf - > Of Wei Sun - > Sent: Monday, September 26, 2016 19:06 - > - > Just joined the list, and apologize if the following question was answered - > before. - > - > I'm building openssl 1.1.0b on Windows. It is stated that it defaults to - > /MD while building openssl, so is there a way to change the linker option - > to /MT? - - We're still using 1.0.2, so I don't know if the 1.1.0 build system is significantly different; but we use a build script of our own which edits the Perl build scripts (using Cygwin sed) after extracting the tarball and before running the OpenSSL build process. One of the things it does is force the C RTS linker switches we want. - - I don't know of a cleaner way to handle this particular aspect of build configuration. It's been some years since I looked into it, though. - - It's not an issue for us because our build scripts do a bunch of other things (as part of our integration process) besides extracting the sources and building OpenSSL, so adding this step wasn't burdensome. - - Michael Wojcik - Distinguished Engineer, Micro Focus - - - -- - openssl-users mailing list - To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From bkaduk at akamai.com Tue Sep 27 19:23:15 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 27 Sep 2016 14:23:15 -0500 Subject: [openssl-users] Can't compile Apache 2.4.23 with OpenSSL 1.1.0b In-Reply-To: <252BCE41-8C78-408C-8CAE-3959F8B04625@yale.edu> References: <252BCE41-8C78-408C-8CAE-3959F8B04625@yale.edu> Message-ID: The library is mostly self-initializing now, so the malloc_init call is probably not needed. SSLv2 support is entirely removed. There are very drastic changes between the 1.0.x series and the 1.1.0 series, you really should read at least the NEWS file entries and maybe the CHANGES as well. Porting a large application such as Apache to the new library will be a nontrivial work, but as you suspect, is probably best discussed on the httpd mailing list. -Ben On 09/27/2016 12:14 PM, Paquin, Brian wrote: > When I try to compile Apache 2.4.23 with OpenSSL 1.1.0b I get: > > secure:httpd-2.4.23 administrator$ sudo make > <--many lines cut out--> > /Users/administrator/Downloads/httpd-2.4.23/srclib/apr/libtool --silent --mode=link gcc -arch x86_64 -L/usr/local/openssl/lib -lssl -lcrypto -lpthread \ > -o ab ab.lo /Users/administrator/Downloads/httpd-2.4.23/srclib/apr-util/libaprutil-1.la -lexpat -liconv /Users/administrator/Downloads/httpd-2.4.23/srclib/apr/libapr-1.la -lpthread > Undefined symbols for architecture x86_64: > "_CRYPTO_malloc_init", referenced from: > _main in ab.o > "_SSLv2_client_method", referenced from: > _main in ab.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[2]: *** [ab] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all-recursive] Error 1 > > It compiles fine with 1.0.1j, but I am curious what I need to change to get 1.1.0b working? > (this may be for the httpd mailing list, but since it was specific to v1.1.0 I thought I would start here. > > OS is Mac OS X 10.11.6. > > Thank you, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Sep 27 19:34:13 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Sep 2016 19:34:13 +0000 Subject: [openssl-users] Can't compile Apache 2.4.23 with OpenSSL 1.1.0b In-Reply-To: <252BCE41-8C78-408C-8CAE-3959F8B04625@yale.edu> References: <252BCE41-8C78-408C-8CAE-3959F8B04625@yale.edu> Message-ID: You might want to start here: http://apache-http-server.18135.x6.nabble.com/Support-for-OpenSSL-1-1-0-td5027694.html -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From jose.campos.romero at andaluciajunta.es Wed Sep 28 06:06:57 2016 From: jose.campos.romero at andaluciajunta.es (jose.campos.romero at andaluciajunta.es) Date: Wed, 28 Sep 2016 08:06:57 +0200 (CEST) Subject: [openssl-users] Libeay32.dll Message-ID: <1670.10.231.228.17.1475042817.squirrel@correo.andaluciajunta.es> Hi I have downloaded OpenSSL-Win32. i don?t find this dll. Can anybody help me? It should come with the download? How i can obtain or generate? An approach to concept and functions of this library? Thanks for your attention and sorry for my ignorance in this issue From Saurabh.Gupta at cavium.com Wed Sep 28 06:53:24 2016 From: Saurabh.Gupta at cavium.com (Gupta, Saurabh) Date: Wed, 28 Sep 2016 06:53:24 +0000 Subject: [openssl-users] how to generate test8192 input data for d2i_RSAPrivateKey(....) ? Message-ID: How to generate **inp for d2i_RSAPrivateKey? RSA *d2i_RSAPrivateKey(RSA **out, const uint8_t **inp, long len) We are having test512 to test4096 modulus data. How can I generate for test8192 modulus data? Regards, Saurabh -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheyendal at fortinet.com Wed Sep 28 13:58:44 2016 From: cheyendal at fortinet.com (Carl Heyendal) Date: Wed, 28 Sep 2016 13:58:44 +0000 Subject: [openssl-users] cipher suite list In-Reply-To: References: Message-ID: Hi, being somewhat of a newb to the security I thought I would ask the security community about the current best practices/guidelines for configuring the list of cipher suites that I should use in my client app. It seems like some cipher suites fall out of favour over time and I would like to use the most safe and reliable cipher suites that are currently known as of today. Appreciate any advice. /carl h. *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Sep 28 14:21:58 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 28 Sep 2016 16:21:58 +0200 (CEST) Subject: [openssl-users] Libeay32.dll In-Reply-To: <1670.10.231.228.17.1475042817.squirrel@correo.andaluciajunta.es> References: <1670.10.231.228.17.1475042817.squirrel@correo.andaluciajunta.es> Message-ID: <20160928.162158.1746906512674167663.levitte@openssl.org> In message <1670.10.231.228.17.1475042817.squirrel at correo.andaluciajunta.es> on Wed, 28 Sep 2016 08:06:57 +0200 (CEST), jose.campos.romero at andaluciajunta.es said: jose.campos.romero> I have downloaded OpenSSL-Win32. i don?t find this dll. Can anybody help me? >From where? Considering there are a number of places where this can be found, it would be good to know which one, and what OpenSSL version we're talking about. Something to be aware of is that with OpenSSL 1.1.0 and on, the library names have changed. For any 1.1.x, the library names are libcrypto-1_1.dll and libssl-1_1.dll on Win32. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kgoldman at us.ibm.com Wed Sep 28 14:23:46 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 28 Sep 2016 10:23:46 -0400 Subject: [openssl-users] Libeay32.dll In-Reply-To: <1670.10.231.228.17.1475042817.squirrel@correo.andaluciajunta.es> References: <1670.10.231.228.17.1475042817.squirrel@correo.andaluciajunta.es> Message-ID: 1 - Where did you download it from? 2 - What did you download? 3 - Where did you look? On 9/28/2016 2:06 AM, jose.campos.romero at andaluciajunta.es wrote: > Hi > > I have downloaded OpenSSL-Win32. i don?t find this dll. Can anybody help me? > > It should come with the download? How i can obtain or generate? From marquess at openssl.com Wed Sep 28 14:38:27 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 28 Sep 2016 10:38:27 -0400 Subject: [openssl-users] new FIPS module In-Reply-To: References: <744d4295-9aa1-63f3-b1f9-2d781c5e5947@openssl.com> Message-ID: <2d434a64-665b-a028-f15a-c3d0a6b6c48e@openssl.com> On 09/27/2016 10:57 AM, Zeke Evans wrote: >> ... > > The fixed base address requirement causes problems for large Windows > x86 applications and there isn't a great work around. It isn't clear > to me if item 2 " Support compilation in various forms" will address > this or not. An option to compile the fips module as a dll instead > of a static lib would be nice or at least allow the fips capable > module to be rebased. As I understand it (not being a Windows person), we don't have any options good across the Windows ecosystem. Apparently PIC isn't possible on Win32, for instance. Hopefully Andy will weigh in. If there is a graceful way to accommodate Windows we'd gladly do it. As for DLLs, the fipscanister.o code can always be embedded within a DLL or shared library. It's the rebasing that's the problem. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rsalz at akamai.com Wed Sep 28 17:29:12 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Sep 2016 17:29:12 +0000 Subject: [openssl-users] cipher suite list In-Reply-To: References: Message-ID: Some places to look include: https://wiki.mozilla.org/Security/Server_Side_TLS https://bettercrypto.org/static/applied-crypto-hardening.pdf ssllabs.com observatory.mozilla.org And, by the way, the silly huge email disclaimer is obnoxious. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Sep 28 18:57:41 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 28 Sep 2016 18:57:41 +0000 Subject: [openssl-users] cipher suite list In-Reply-To: References: Message-ID: Ivan Ristic's free OpenSSL Cookbook has a long section on cipher suite selection. It's available on feistyduck. Michael Wojcik Distinguished Engineer, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Wednesday, September 28, 2016 13:29 To: openssl-users at openssl.org Subject: Re: [openssl-users] cipher suite list Some places to look include: https://wiki.mozilla.org/Security/Server_Side_TLS https://bettercrypto.org/static/applied-crypto-hardening.pdf ssllabs.com observatory.mozilla.org And, by the way, the silly huge email disclaimer is obnoxious. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.campos.romero at andaluciajunta.es Wed Sep 28 19:06:29 2016 From: jose.campos.romero at andaluciajunta.es (jose.campos.romero at andaluciajunta.es) Date: Wed, 28 Sep 2016 21:06:29 +0200 (CEST) Subject: [openssl-users] Libeay32.dll In-Reply-To: <20160928.162158.1746906512674167663.levitte@openssl.org> References: <1670.10.231.228.17.1475042817.squirrel@correo.andaluciajunta.es> <20160928.162158.1746906512674167663.levitte@openssl.org> Message-ID: <24795.10.118.96.116.1475089589.squirrel@correo.andaluciajunta.es> Hi Thanks for your answer. I didn?t know about change of libraries names. I downloaded Win32 OpenSSL v1.1.0b from https://slproweb.com/products/Win32OpenSSL.html Thanks again > In message <1670.10.231.228.17.1475042817.squirrel at correo.andaluciajunta.es> > on Wed, 28 Sep 2016 08:06:57 +0200 (CEST), > jose.campos.romero at andaluciajunta.es said: > > jose.campos.romero> I have downloaded OpenSSL-Win32. i don?t find this dll. > Can anybody help me? > > From where? Considering there are a number of places where this can > be found, it would be good to know which one, and what OpenSSL version > we're talking about. > > Something to be aware of is that with OpenSSL 1.1.0 and on, the > library names have changed. For any 1.1.x, the library names are > libcrypto-1_1.dll and libssl-1_1.dll on Win32. > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From cheyendal at fortinet.com Wed Sep 28 19:23:12 2016 From: cheyendal at fortinet.com (Carl Heyendal) Date: Wed, 28 Sep 2016 19:23:12 +0000 Subject: [openssl-users] cipher suite list In-Reply-To: References: Message-ID: Thanks for the pointers. As for the silly disclaimer I have no control over adding it or not. My company must append it to the email when it sends it. :) From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: September-28-16 1:29 PM To: openssl-users at openssl.org Subject: [Newsletter] Re: [openssl-users] cipher suite list Some places to look include: https://wiki.mozilla.org/Security/Server_Side_TLS https://bettercrypto.org/static/applied-crypto-hardening.pdf ssllabs.com observatory.mozilla.org And, by the way, the silly huge email disclaimer is obnoxious. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Sep 28 19:25:10 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Sep 2016 19:25:10 +0000 Subject: [openssl-users] cipher suite list In-Reply-To: References: Message-ID: > As for the silly disclaimer I have no control over adding it or not. My company must append it to the email when it sends it. ? Please tell the folks at your company it is annoying. And consider posting from a non-company address, then. From cheyendal at fortinet.com Wed Sep 28 19:36:00 2016 From: cheyendal at fortinet.com (Carl Heyendal) Date: Wed, 28 Sep 2016 19:36:00 +0000 Subject: [openssl-users] cipher suite list In-Reply-To: References: Message-ID: Thanks Michael. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: September-28-16 2:58 PM To: openssl-users at openssl.org Subject: [Newsletter] Re: [openssl-users] cipher suite list Ivan Ristic's free OpenSSL Cookbook has a long section on cipher suite selection. It's available on feistyduck. Michael Wojcik Distinguished Engineer, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Wednesday, September 28, 2016 13:29 To: openssl-users at openssl.org Subject: Re: [openssl-users] cipher suite list Some places to look include: https://wiki.mozilla.org/Security/Server_Side_TLS https://bettercrypto.org/static/applied-crypto-hardening.pdf ssllabs.com observatory.mozilla.org And, by the way, the silly huge email disclaimer is obnoxious. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From janzon at gmail.com Thu Sep 29 15:55:44 2016 From: janzon at gmail.com (Daniel Janzon) Date: Thu, 29 Sep 2016 15:55:44 +0000 Subject: [openssl-users] Possible to control session reuse from the client? Message-ID: Hi! For performance testing purposes, I would like to turn off session reuse in the (homegrown) client I use for testing. Is there a function in the openssl library to do it? I tried googling for "openssl client don't send session id" but I didn't find anything useful. Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoddoz+openssl at gmail.com Thu Sep 29 16:40:55 2016 From: zoddoz+openssl at gmail.com (Troy Smoke) Date: Thu, 29 Sep 2016 09:40:55 -0700 Subject: [openssl-users] new FIPS module Message-ID: I am in the position of evaluating products that have (or claim to have) implemented the OpenSSL FIPS module. I would like to be able to be able to run a command or run the FIPS self-test on command, for the purpose of verifying if OpenSSL is operating in FIPS mode. This may not be important for most users, but I would consider it of vital importance from a testing perspective. This is also assuming that such a command/procedure would be allowed under the FIPS certification. Thanks, zoddoz >As always, if you don't care about FIPS 140 then count yourself lucky and move >on. > >Work on the new FIPS module has so far taken a backseat to higher priority >topics like the 1.1 release and security vulnerabilities, but we should start to >make some progress soon. I've put together a rough wiki page outlining some >goals for the new FIPS module: > >Caution-https://wiki.openssl.org/index.php/FIPS_module_3.0 > >Within the very tight constraints of schedule, resources, and what is permitted >by FIPS 140, we want this FIPS module to be as widely useful as possible. > >If we've omitted anything of vital importance please speak up. > >-Steve M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Thu Sep 29 16:45:31 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 29 Sep 2016 12:45:31 -0400 Subject: [openssl-users] Coverity Scan projects for OpenSSL? Message-ID: Hi Everyone, Coverity Scan has two projects for OpenSSL (https://scan.coverity.com/dashboard) * openssl/openssl * OpenSSL_release Which should we request access to for the reports? Thanks in advance. From marquess at openssl.com Thu Sep 29 20:08:32 2016 From: marquess at openssl.com (Steve Marquess) Date: Thu, 29 Sep 2016 16:08:32 -0400 Subject: [openssl-users] new FIPS module In-Reply-To: References: Message-ID: On 09/29/2016 12:40 PM, Troy Smoke wrote: > I am in the position of evaluating products that have (or claim to have) > implemented the OpenSSL FIPS module. > > I would like to be able to be able to run a command or run the FIPS > self-test on command, for the purpose of verifying if OpenSSL is > operating in FIPS mode. > > ... Keep in mind that "OpenSSL" itself doesn't "operate in FIPS mode". OpenSSL is a set of shared libraries which may be instantiated different ways by different calling applications. Application A may enable FIPS mode while application B referencing the same shared libraries doesn't. "OpenSSL" itself is never "operating in FIPS mode" independently of any applications; the term is meaningful only in the context of a specific application/process. A related question is "Does this OpenSSL install support use of the FIPS module"? We call OpenSSL built that way a "FIPS capable" OpenSSL; "capable" because calling applications can elect to enable FIPS mode (or not). To see if a specific install of OpenSSL 1.0.1/1.0.2 was built as FIPS capable, you can run the command (application): OPENSSL_FIPS=1 openssl md5 < /dev/null It will throw errors if the "openssl" command is from a FIPS capable OpenSSL; either for a self test failure (unlikely) or because of the disallowed algorithm. If not from a FIPS capable OpenSSL you just see the message "FIPS mode not supported." Note that tells you nothing about whether another application has enabled FIPS mode, though. For that you need to look under the hood of that application (i.e. ask the vendor). -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From noloader at gmail.com Thu Sep 29 20:52:08 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 29 Sep 2016 16:52:08 -0400 Subject: [openssl-users] OpenSSL 1.1.0 release (was: new FIPS module) Message-ID: > Work on the new FIPS module has so far taken a backseat to higher > priority topics like the 1.1 release ... OpenSSL 1.1.0 was a very strong release. The team did an awesome job. Hats off to them for a job that exceeded well done. I did not observe problems at places where you can take the temperature of developers, like Stack Overflow. The was an occasional "project X fails to compile with OpenSSL 1.1.0" and "How do I do Y now that Z is private" but that was expected. Other than that, you would not even know 1.1.0 was released because things went so smoothly. Jeff From openssl-users at dukhovni.org Thu Sep 29 22:00:21 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 29 Sep 2016 18:00:21 -0400 Subject: [openssl-users] Possible to control session reuse from the client? In-Reply-To: References: Message-ID: <32126FB1-2531-41E8-B066-6176D12B1E3D@dukhovni.org> > On Sep 29, 2016, at 11:55 AM, Daniel Janzon wrote: > > For performance testing purposes, I would like to turn off session reuse in the (homegrown) client I use for testing. Is there a function in the openssl library to do it? > > I tried googling for "openssl client don't send session id" but I didn't find anything useful. Just do nothing. Client sessions are not reused unless you explicitly arrange for reuse of a session by calling SSL_set_session() before SSL_connect(). If you're trying to avoid wasting memory on storing client-side sessions that you'll never reuse then this may help: SSL_CTX_set_session_cache_mode(client_ctx, SSL_SESS_CACHE_OFF); but note this is also the default state, so is also not needed unless some other code has explicitly enabled client-side caching of sessions. Only the server-side cache is enabled by default. -- -- Viktor. From matt at openssl.org Fri Sep 30 08:21:47 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 30 Sep 2016 09:21:47 +0100 Subject: [openssl-users] Coverity Scan projects for OpenSSL? In-Reply-To: References: Message-ID: <7c0afdf5-fda2-375a-9ec0-02121af36791@openssl.org> On 29/09/16 17:45, Jeffrey Walton wrote: > Hi Everyone, > > Coverity Scan has two projects for OpenSSL (https://scan.coverity.com/dashboard) > > * openssl/openssl > * OpenSSL_release > > Which should we request access to for the reports? openssl/openssl is for current maser. OpenSSL_release is for 1.0.2 Note1: we might review that now that 1.1.0 has been released. Note2: we recently changed our policy on Coverity access. Previously we did not typically allow access to the defect reports. Now we allow Defect viewer access to anyone that requests it. Matt From gjcoram at gmail.com Fri Sep 30 12:11:45 2016 From: gjcoram at gmail.com (Geoffrey Coram) Date: Fri, 30 Sep 2016 08:11:45 -0400 Subject: [openssl-users] calloc vs kssl_calloc In-Reply-To: <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com> References: <20160926115651.6018EB40.gjcoram@gmail.com> <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com> <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com> Message-ID: On Mon, Sep 26, 2016 at 12:11 PM, Benjamin Kaduk wrote: > On 09/26/2016 11:01 AM, Salz, Rich wrote: > > Kssl_calloc calls openssl_malloc which means the data must be free'd with openssl_free. And in debug builds any non-free'd data is a leak and reported. Ton line 875 the data is allocated and never free'd, so it skips the leak detection. In some of those other places, perhaps it's because the KRB API needs something it can free or realloc? I'm not sure. > > > > It doesn't look like the allocated memory is used as input to a krb5 > routine, so I think it's just a bug. > > Is there something more I should do on this issue? I recall the OpenSSL terms of use strongly discouraged people from the US from helping, due to US export restrictions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Sep 30 13:29:59 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 30 Sep 2016 13:29:59 +0000 Subject: [openssl-users] calloc vs kssl_calloc In-Reply-To: References: <20160926115651.6018EB40.gjcoram@gmail.com> <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com> <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com> Message-ID: <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com> > Is there something more I should do on this issue?? I recall the OpenSSL terms of use strongly discouraged people from the US from helping, due to US export restrictions. That's kinda outdated. From jb-openssl at wisemo.com Fri Sep 30 14:14:23 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 30 Sep 2016 16:14:23 +0200 Subject: [openssl-users] calloc vs kssl_calloc In-Reply-To: <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160926115651.6018EB40.gjcoram@gmail.com> <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com> <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com> <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <5494c531-b77a-e155-cfa6-2effc2de30c5@wisemo.com> On 30/09/2016 15:29, Salz, Rich wrote: >> Is there something more I should do on this issue? I recall the OpenSSL terms of use strongly discouraged people from the US from helping, due to US export restrictions. > That's kinda outdated. However there are very many OpenSSL users (myself included) who rely on the legal status of OpenSSL/SSLeay as having no US origin parts. If this has changed, it needs a big red banner at the top of the www.openssl.org, every affected source file with the original EAY copyright boilerplate or its OpenSSL clone etc. For example, this affects how the use of OpenSSL should be declared on various customs forms with respect to US export restrictions and embargoes. It is also a legal reason to avoid the BoringSSL US clone and to some extent the LibreSSL Canadian clone. 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 noloader at gmail.com Fri Sep 30 18:23:10 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 30 Sep 2016 14:23:10 -0400 Subject: [openssl-users] Coverity Scan projects for OpenSSL? In-Reply-To: <7c0afdf5-fda2-375a-9ec0-02121af36791@openssl.org> References: <7c0afdf5-fda2-375a-9ec0-02121af36791@openssl.org> Message-ID: > openssl/openssl is for current maser. > OpenSSL_release is for 1.0.2 > > Note1: we might review that now that 1.1.0 has been released. > > Note2: we recently changed our policy on Coverity access. Previously we > did not typically allow access to the defect reports. Now we allow > Defect viewer access to anyone that requests it. These numbers are outstanding. Defect Density - 0.02 Outstanding Defects - 4 Why aren't you announcing them? You might also consider providing an announcement when new results are available at a significant point in time for those interested in this sort of thing. "Significant point in time" might be after a major merge or passing through the release process security gate. The announcement also raises awareness for the folks who are not following the project on Coverity Scan. Ideally, your announcement would be picked up by users of OpenSSL. They would register their projects and start raising the bar in their software, too. Jeff