From Michal.Trojnara at stunnel.org Mon Jul 2 21:51:24 2018 From: Michal.Trojnara at stunnel.org (Michal Trojnara) Date: Mon, 2 Jul 2018 23:51:24 +0200 Subject: [openssl-users] stunnel 5.48 released Message-ID: <6e9be5bb-8b33-264e-490f-0052cc9e955a@stunnel.org> Dear Users, I have released version 5.48 of stunnel. Version 5.48, 2018.07.02, urgency: HIGH * Security bugfixes - Fixed requesting client certificate when specified as a global option. * New features - Certificate subject checks modified to accept certificates if at least one of the specified checks matches. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 1011d5a302ce6a227882d094282993a3187250f42f8a801dcc1620da63b2b8df stunnel-5.48.tar.gz eb160fdf28061eb509e09824ab9cd26f4f0ca9be3b90008bba32274d5136c7eb stunnel-5.48-win32-installer.exe 667ee8c8d5440117285eb5a5ddf0d305a6dd1dbb93dcf5b7bac62f84ddba7466 stunnel-5.48-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From drescher at snafu.de Tue Jul 3 07:33:48 2018 From: drescher at snafu.de (Martin Drescher) Date: Tue, 3 Jul 2018 09:33:48 +0200 Subject: [openssl-users] Unset a given SendEnv? In-Reply-To: <7db0780d-cbf3-1345-340c-136586173011@snafu.de> References: <7db0780d-cbf3-1345-340c-136586173011@snafu.de> Message-ID: Oh, no, chancel this! Wrong list list... :-( -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From drescher at snafu.de Tue Jul 3 07:31:03 2018 From: drescher at snafu.de (Martin Drescher) Date: Tue, 3 Jul 2018 09:31:03 +0200 Subject: [openssl-users] Unset a given SendEnv? Message-ID: <7db0780d-cbf3-1345-340c-136586173011@snafu.de> G'day openssl-users, is there a way to unset a 'SendEnv' given by /etc/ssh/ssh_config? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From alexhultman at gmail.com Tue Jul 3 18:16:57 2018 From: alexhultman at gmail.com (Alex H) Date: Tue, 3 Jul 2018 20:16:57 +0200 Subject: [openssl-users] Custom memory BIO write callback, determine last segment? Message-ID: Hi, I have a custom BIO_TYPE_MEM BIO with write and read callbacks that map to a networking socket. I'm getting a lot better performance by using the MSG_MORE flag of the Linux send syscall to "cork" segments of a stream together. So far I have guessed whether to pass MSG_MORE or not based of the size of the chunk passed to the BIO write callback, but this is no longer viable. SSL_write with a long buffer will produce roughly 16kb chunks to be sent off by the BIO - how can I know if a chunk is "in the middle" of an ongoing SSL_write or if the chunk is last? I don't see anything that can help me in the BIO ctrl callback, or? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajay.nalawade at gmail.com Thu Jul 5 12:55:27 2018 From: ajay.nalawade at gmail.com (Ajay Nalawade) Date: Thu, 5 Jul 2018 18:25:27 +0530 Subject: [openssl-users] Openssl 1.0.2o issue with FIPS mode set. In-Reply-To: References: Message-ID: I am able to reproduce this issue with attached go lang based server. Am I doing anything wrong here. Is there any known issue, or any workaround available for this issue. Thanks, Ajay On Thu, Jun 7, 2018 at 12:33 PM Ajay Nalawade wrote: > Hello, > > I have golang based openssl server with FIPS mode set. I am using Openssl > library build with fips module 2.0. > With Openssl 1.0.1u version, everything was running fine. > Recently I upgraded to version 1.0.2o. With this version, under high > traffic condition (more than 4k requests per minute), read request fails > with following error. > "SSL errors: SSL routines:SSL3_GET_RECORD:decryption failed or bad record > mac" > > If I disable FIPS mode, every thing runs fine. Is there any known issue > with version 1.0.2o with FIPS mode set. > > Thanks a lot in advance, > Ajay > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_server.go Type: application/octet-stream Size: 2749 bytes Desc: not available URL: From ajay.nalawade at gmail.com Thu Jul 5 12:59:01 2018 From: ajay.nalawade at gmail.com (Ajay Nalawade) Date: Thu, 5 Jul 2018 18:29:01 +0530 Subject: [openssl-users] Openssl 1.0.2o issue with FIPS mode set. In-Reply-To: References: Message-ID: package main import ( "log" "net" "net/http" "fmt" "os" "bufio" "io" "strconv" "github.com/spacemonkeygo/openssl" ) func init_fips() { err := openssl.FIPSModeSet(true) if err != nil { panic(fmt.Errorf("%v Error:%v\n", "openssl failed to set fips mode.", err)) } log.Print("OpenSSL FIPS mode is set to: True\n") } func main() { init_fips() laddr := "0.0.0.0:443" var ln net.Listener var err error // Init SSL shared context used across connections ctx, err := openssl.NewCtxFromFiles("/etc/certs/sslcert.crt", "/etc/certs/sslcert.key") if err != nil { log.Fatalf("Failed to read ssl certificate. Error: %v", err) } // Set options and do not allow SSLv2 and SSLv3 communication _ = ctx.SetOptions(openssl.CipherServerPreference | openssl.NoSSLv2 | openssl.NoSSLv3) // Read certificate // Listen on bind address ln, err = openssl.Listen("tcp", laddr, ctx) if err != nil { log.Fatalf("Failed to start server. Error: %v", err) os.Exit(1) } else { log.Println("Started secure server") } if err != nil { log.Fatalf("server: listen: %s", err) } log.Print("server: listening") for { accepted, err := ln.Accept() if err != nil { log.Println("Got errored while accepting connection. %v", err) return } go handleClient(accepted) } } func handleClient(conn net.Conn) { defer conn.Close() reader := bufio.NewReader(conn) for { //log.Print("server: conn: waiting") var err error httpreq, err := http.ReadRequest(reader) if err != nil { log.Print("Errored while reading request. Error: %v", err) break } buf := make([]byte, httpreq.ContentLength) toread := int(httpreq.ContentLength) rbytes := 0 n := 0 for toread > 0 { n, err = httpreq.Body.Read(buf[rbytes:]) if err != nil && err != io.EOF { log.Print("Errored while reading request body. Error: %v", err) break } rbytes += n toread = toread - n } resp := append([]byte("HTTP/1.1 200 OK\r\n"+"Content-Length: "+ strconv.Itoa(len(buf))+"\r\n\r\n"), buf...) _, err = conn.Write(resp) if err != nil { log.Print("Errored while writing response. Error: %v", err) break } log.Printf("server: conn: wrote %d bytes", n) } log.Println("server: conn: closed") } On Thu, Jul 5, 2018 at 6:25 PM Ajay Nalawade wrote: > I am able to reproduce this issue with attached go lang based server. Am I > doing anything wrong here. > Is there any known issue, or any workaround available for this issue. > > Thanks, > Ajay > > On Thu, Jun 7, 2018 at 12:33 PM Ajay Nalawade > wrote: > >> Hello, >> >> I have golang based openssl server with FIPS mode set. I am using Openssl >> library build with fips module 2.0. >> With Openssl 1.0.1u version, everything was running fine. >> Recently I upgraded to version 1.0.2o. With this version, under high >> traffic condition (more than 4k requests per minute), read request fails >> with following error. >> "SSL errors: SSL routines:SSL3_GET_RECORD:decryption failed or bad record >> mac" >> >> If I disable FIPS mode, every thing runs fine. Is there any known issue >> with version 1.0.2o with FIPS mode set. >> >> Thanks a lot in advance, >> Ajay >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Thu Jul 5 18:20:12 2018 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Thu, 5 Jul 2018 23:50:12 +0530 Subject: [openssl-users] Packet capture SSL traffic Message-ID: Hi, Is there a way to capture SSL traffic using openssl and tcpdump or any other utility on Linux? I look forward to hearing from you. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Thu Jul 5 20:01:34 2018 From: tshort at akamai.com (Short, Todd) Date: Thu, 5 Jul 2018 20:01:34 +0000 Subject: [openssl-users] Packet capture SSL traffic In-Reply-To: References: Message-ID: <6DF05D52-FCBC-4DDB-BB64-4D39F6147FFA@akamai.com> wireshark.org; it will decode it for you as well. EKR used to have a utility on this website, but it?s likely out of date. Wireshark has been more frequently updated. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jul 5, 2018, at 2:20 PM, Kaushal Shriyan > wrote: Hi, Is there a way to capture SSL traffic using openssl and tcpdump or any other utility on Linux? I look forward to hearing from you. Best Regards, Kaushal -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Jul 5 22:04:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 5 Jul 2018 18:04:53 -0400 Subject: [openssl-users] Packet capture SSL traffic In-Reply-To: References: Message-ID: <20180705220453.GQ85096@straasha.imrryr.org> On Thu, Jul 05, 2018 at 11:50:12PM +0530, Kaushal Shriyan wrote: > Is there a way to capture SSL traffic using openssl and tcpdump or any > other utility on Linux? I look forward to hearing from you. See the bottom of: https://mta.openssl.org/pipermail/openssl-users/2017-April/005624.html for a short summary of how to combine "tcpdump" and "tshark" (the wireshark CLI) to get textual SSL traffic decoding. -- Viktor. From ajay.nalawade at gmail.com Fri Jul 6 06:03:50 2018 From: ajay.nalawade at gmail.com (Ajay Nalawade) Date: Fri, 6 Jul 2018 11:33:50 +0530 Subject: [openssl-users] Openssl 1.0.2o issue with FIPS mode set. In-Reply-To: References: Message-ID: Here are some more observations. 1. It did not take much load to cause this error(Creating even 2 connections in parallel gives this issue). 2. While a client is sending data, another client connecting does not error. The error seems to be only when two clients try to handshake together. If we serialise ssl wrap even thousands of clients do not give this issue. 3. There comes a time(after 40 iterations in case of 3 parallel handshaking clients) after which the server kind of gives up and keeps on giving the same error no matter how much we slow down the clients(I stopped my client script for 5 minutes before trying again). On Thu, Jul 5, 2018 at 6:29 PM Ajay Nalawade wrote: > package main > > import ( > "log" > "net" > "net/http" > "fmt" > "os" > "bufio" > "io" > "strconv" > "github.com/spacemonkeygo/openssl" > ) > > func init_fips() { > err := openssl.FIPSModeSet(true) > if err != nil { > panic(fmt.Errorf("%v Error:%v\n", "openssl failed to set > fips mode.", err)) > } > log.Print("OpenSSL FIPS mode is set to: True\n") > } > > func main() { > init_fips() > > laddr := "0.0.0.0:443" > var ln net.Listener > var err error > > // Init SSL shared context used across connections > ctx, err := openssl.NewCtxFromFiles("/etc/certs/sslcert.crt", > "/etc/certs/sslcert.key") > if err != nil { > log.Fatalf("Failed to read ssl certificate. Error: %v", err) > } > > // Set options and do not allow SSLv2 and SSLv3 communication > _ = ctx.SetOptions(openssl.CipherServerPreference | > openssl.NoSSLv2 | openssl.NoSSLv3) > > // Read certificate > // Listen on bind address > ln, err = openssl.Listen("tcp", laddr, ctx) > > if err != nil { > log.Fatalf("Failed to start server. Error: %v", > err) > os.Exit(1) > } else { > log.Println("Started secure server") > } > if err != nil { > log.Fatalf("server: listen: %s", err) > } > log.Print("server: listening") > for { > accepted, err := ln.Accept() > > if err != nil { > log.Println("Got errored while accepting connection. %v", err) > return > } > > go handleClient(accepted) > } > } > > func handleClient(conn net.Conn) { > defer conn.Close() > reader := bufio.NewReader(conn) > for { > //log.Print("server: conn: waiting") > var err error > httpreq, err := http.ReadRequest(reader) > if err != nil { > log.Print("Errored while reading request. Error: %v", err) > break > } > buf := make([]byte, httpreq.ContentLength) > toread := int(httpreq.ContentLength) > rbytes := 0 > n := 0 > for toread > 0 { > n, err = httpreq.Body.Read(buf[rbytes:]) > if err != nil && err != io.EOF { > log.Print("Errored while reading request body. > Error: %v", err) > break > } > rbytes += n > toread = toread - n > } > > resp := append([]byte("HTTP/1.1 200 OK\r\n"+"Content-Length: "+ > strconv.Itoa(len(buf))+"\r\n\r\n"), buf...) > _, err = conn.Write(resp) > if err != nil { > log.Print("Errored while writing response. Error: %v", err) > break > } > > log.Printf("server: conn: wrote %d bytes", n) > > } > log.Println("server: conn: closed") > } > > On Thu, Jul 5, 2018 at 6:25 PM Ajay Nalawade > wrote: > >> I am able to reproduce this issue with attached go lang based server. Am >> I doing anything wrong here. >> Is there any known issue, or any workaround available for this issue. >> >> Thanks, >> Ajay >> >> On Thu, Jun 7, 2018 at 12:33 PM Ajay Nalawade >> wrote: >> >>> Hello, >>> >>> I have golang based openssl server with FIPS mode set. I am using >>> Openssl library build with fips module 2.0. >>> With Openssl 1.0.1u version, everything was running fine. >>> Recently I upgraded to version 1.0.2o. With this version, under high >>> traffic condition (more than 4k requests per minute), read request fails >>> with following error. >>> "SSL errors: SSL routines:SSL3_GET_RECORD:decryption failed or bad >>> record mac" >>> >>> If I disable FIPS mode, every thing runs fine. Is there any known issue >>> with version 1.0.2o with FIPS mode set. >>> >>> Thanks a lot in advance, >>> Ajay >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajay.nalawade at gmail.com Fri Jul 6 12:25:02 2018 From: ajay.nalawade at gmail.com (Ajay Nalawade) Date: Fri, 6 Jul 2018 17:55:02 +0530 Subject: [openssl-users] Openssl 1.0.2o issue with FIPS mode set. In-Reply-To: References: Message-ID: Issue is not seen for Openssl version 1.0.2g. Issue is present for all versions post 1.0.2g. Thanks, Ajay On Fri, Jul 6, 2018 at 11:33 AM Ajay Nalawade wrote: > Here are some more observations. > 1. It did not take much load to cause this error(Creating even 2 > connections in parallel gives this issue). > 2. While a client is sending data, another client connecting does not > error. The error seems to be only when two clients try to handshake > together. If we serialise ssl wrap even thousands of clients do not give > this issue. > 3. There comes a time(after 40 iterations in case of 3 parallel > handshaking clients) after which the server kind of gives up and keeps on > giving the same error no matter how much we slow down the clients(I stopped > my client script for 5 minutes before trying again). > > On Thu, Jul 5, 2018 at 6:29 PM Ajay Nalawade > wrote: > >> package main >> >> import ( >> "log" >> "net" >> "net/http" >> "fmt" >> "os" >> "bufio" >> "io" >> "strconv" >> "github.com/spacemonkeygo/openssl" >> ) >> >> func init_fips() { >> err := openssl.FIPSModeSet(true) >> if err != nil { >> panic(fmt.Errorf("%v Error:%v\n", "openssl failed to set >> fips mode.", err)) >> } >> log.Print("OpenSSL FIPS mode is set to: True\n") >> } >> >> func main() { >> init_fips() >> >> laddr := "0.0.0.0:443" >> var ln net.Listener >> var err error >> >> // Init SSL shared context used across connections >> ctx, err := openssl.NewCtxFromFiles("/etc/certs/sslcert.crt", >> "/etc/certs/sslcert.key") >> if err != nil { >> log.Fatalf("Failed to read ssl certificate. Error: %v", err) >> } >> >> // Set options and do not allow SSLv2 and SSLv3 communication >> _ = ctx.SetOptions(openssl.CipherServerPreference | >> openssl.NoSSLv2 | openssl.NoSSLv3) >> >> // Read certificate >> // Listen on bind address >> ln, err = openssl.Listen("tcp", laddr, ctx) >> >> if err != nil { >> log.Fatalf("Failed to start server. Error: %v", >> err) >> os.Exit(1) >> } else { >> log.Println("Started secure server") >> } >> if err != nil { >> log.Fatalf("server: listen: %s", err) >> } >> log.Print("server: listening") >> for { >> accepted, err := ln.Accept() >> >> if err != nil { >> log.Println("Got errored while accepting connection. %v", err) >> return >> } >> >> go handleClient(accepted) >> } >> } >> >> func handleClient(conn net.Conn) { >> defer conn.Close() >> reader := bufio.NewReader(conn) >> for { >> //log.Print("server: conn: waiting") >> var err error >> httpreq, err := http.ReadRequest(reader) >> if err != nil { >> log.Print("Errored while reading request. Error: %v", err) >> break >> } >> buf := make([]byte, httpreq.ContentLength) >> toread := int(httpreq.ContentLength) >> rbytes := 0 >> n := 0 >> for toread > 0 { >> n, err = httpreq.Body.Read(buf[rbytes:]) >> if err != nil && err != io.EOF { >> log.Print("Errored while reading request body. >> Error: %v", err) >> break >> } >> rbytes += n >> toread = toread - n >> } >> >> resp := append([]byte("HTTP/1.1 200 OK\r\n"+"Content-Length: "+ >> strconv.Itoa(len(buf))+"\r\n\r\n"), buf...) >> _, err = conn.Write(resp) >> if err != nil { >> log.Print("Errored while writing response. Error: %v", >> err) >> break >> } >> >> log.Printf("server: conn: wrote %d bytes", n) >> >> } >> log.Println("server: conn: closed") >> } >> >> On Thu, Jul 5, 2018 at 6:25 PM Ajay Nalawade >> wrote: >> >>> I am able to reproduce this issue with attached go lang based server. Am >>> I doing anything wrong here. >>> Is there any known issue, or any workaround available for this issue. >>> >>> Thanks, >>> Ajay >>> >>> On Thu, Jun 7, 2018 at 12:33 PM Ajay Nalawade >>> wrote: >>> >>>> Hello, >>>> >>>> I have golang based openssl server with FIPS mode set. I am using >>>> Openssl library build with fips module 2.0. >>>> With Openssl 1.0.1u version, everything was running fine. >>>> Recently I upgraded to version 1.0.2o. With this version, under high >>>> traffic condition (more than 4k requests per minute), read request fails >>>> with following error. >>>> "SSL errors: SSL routines:SSL3_GET_RECORD:decryption failed or bad >>>> record mac" >>>> >>>> If I disable FIPS mode, every thing runs fine. Is there any known issue >>>> with version 1.0.2o with FIPS mode set. >>>> >>>> Thanks a lot in advance, >>>> Ajay >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From quae at daurnimator.com Thu Jul 12 08:49:28 2018 From: quae at daurnimator.com (Daurnimator) Date: Thu, 12 Jul 2018 18:49:28 +1000 Subject: [openssl-users] SSL_CTX ignores many X509_STORE fields and uses own fields Message-ID: When looking into https://github.com/wahern/luaossl/issues/140 I was surprised to learn that an SSL_CTX* (and SSL*) does not use many of the X509_STORE members. e.g. a store has a X509_VERIFY_PARAMS field, however although an SSL_CTX* has a related store, it ignores the store's params and uses it's own. For a connection pooling implementation, I need to check that an existing SSL connection is something that could be approved by a given SSL_CTX*. I was hoping this would be as simple as doing (error handling omitted for brevity): X509_STORE_CTX_init(vfy_ctx, SSL_CTX_get0_store(ctx), SSL_get_certificate(ssl), NULL); X509_verify_cert(vfy_ctx); However it appears that I really need to do: X509_STORE_CTX_init(vfy_ctx, SSL_CTX_get0_store(ctx), SSL_get_certificate(ssl), NULL); X509_VERIFY_PARAM_inherit(X509_STORE_CTX_get0_param(vfy_ctx), SSL_CTX_get0_param(ctx)); // X509_STORE_CTX_set_verify_cb based on SSL_CTX_get_verify_callback(ctx) // X509_STORE_CTX_set0_dane // etc. etc. X509_verify_cert(vfy_ctx); Is this complexity warranted? Is there any plan to remove the redundant fields? Daurn. From levitte at openssl.org Sat Jul 14 05:53:00 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 14 Jul 2018 07:53:00 +0200 (CEST) Subject: [openssl-users] Will a PKCS#12 safeContentsBag change affect anyone? Message-ID: <20180714.075300.1376319097045238111.levitte@openssl.org> Since the dawn of time, it seems that OpenSSL has had an incorrect implementation of safeContentsBag. The current RFC defines it as follows: SafeContents ::= SEQUENCE OF SafeBag safeContentsBag BAG-TYPE ::= {SafeContents IDENTIFIED BY {bagtypes 6}} However, the OpenSSL implementation is this: ASN1_ADB(PKCS12_SAFEBAG) = { ADB_ENTRY(NID_keyBag, ASN1_EXP(PKCS12_SAFEBAG, value.keybag, PKCS8_PRIV_KEY_INFO, 0)), ADB_ENTRY(NID_pkcs8ShroudedKeyBag, ASN1_EXP(PKCS12_SAFEBAG, value.shkeybag, X509_SIG, 0)), ADB_ENTRY(NID_safeContentsBag, ASN1_EXP_SET_OF(PKCS12_SAFEBAG, value.safes, PKCS12_SAFEBAG, 0)), ADB_ENTRY(NID_certBag, ASN1_EXP(PKCS12_SAFEBAG, value.bag, PKCS12_BAGS, 0)), ADB_ENTRY(NID_crlBag, ASN1_EXP(PKCS12_SAFEBAG, value.bag, PKCS12_BAGS, 0)), ADB_ENTRY(NID_secretBag, ASN1_EXP(PKCS12_SAFEBAG, value.bag, PKCS12_BAGS, 0)) } ASN1_ADB_END(PKCS12_SAFEBAG, 0, type, 0, &safebag_default_tt, NULL); Note ASN1_EXP_SET_OF, i.e. it's implemented as a SET OF, rather than a SEQUENCE OF. See https://github.com/openssl/openssl/issues/6665 for the discussion that we've had so far. A fix is already on the way, but there's the question if this will affect anyone. As far as the voices on github say so far, this particular bag appears to be unused... so that's the question we want to ask you; has anyone here used this particular bag and will therefore be affected by a change, or do you know anyone who will? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From cv.schmitt at gmail.com Sun Jul 15 20:59:18 2018 From: cv.schmitt at gmail.com (Carl-Valentin Schmitt) Date: Sun, 15 Jul 2018 22:59:18 +0200 Subject: [openssl-users] New idea Message-ID: Hello nice day Users of openSSL, I want to know, where in files of openSSL the size of password (passwd) is defined. I mean which size a password may have at maximum with openSSL. Want to pump up password size to 1 GB, because password should be read in from usb or from dvd. It is just for fun and for to test Linux a bit more. Thank you for answer. Greetz Val. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dean.Warren at scisys.co.uk Mon Jul 16 08:36:47 2018 From: Dean.Warren at scisys.co.uk (Dean Warren) Date: Mon, 16 Jul 2018 08:36:47 +0000 Subject: [openssl-users] Deployment Message-ID: <8CBE44978B040C41BCE9E0AF7527F7C807E698@citbs-mxexch0.scisys.co.uk> Built openssl 0.9.8za with no problems on SUSE Linux Enterprise Server. Just followed https://wiki.openssl.org/index.php/Compilation_and_Installation? Works a treat - thanks. However on sudo make install the new version doesn't replace the system installed version (obviously this may be different per system). How to make sudo make install overwrite my system version? Is this a parameter within ./Configure? And/or is it also OK to just replace original bins with symbolic links to new built openssl binary and library (are there others?)? Thanks in advance Dean Warren Solutions Architect - Space Division SCISYS UK Limited T: +44 (0)117 916 5182 F: +44 (0)117 916 5299 E: dean.warren at scisys.co.uk http://www.scisys.co.uk SCISYS UK Limited. Registered in England and Wales No. 4373530. Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK. Before printing, please think about the environment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Mon Jul 16 09:25:47 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Mon, 16 Jul 2018 02:25:47 -0700 Subject: [openssl-users] Deployment In-Reply-To: <8CBE44978B040C41BCE9E0AF7527F7C807E698@citbs-mxexch0.scisys.co.uk> References: <8CBE44978B040C41BCE9E0AF7527F7C807E698@citbs-mxexch0.scisys.co.uk> Message-ID: Generally, you *really* do not want to replace the vendor-provided version. Vendors often alter things to be more compatible with their ABIs, which are the binary interfaces that other programs use to link to the vendor-provided libraries. If you find you actually do want to, it's best to figure out how to get the source code of the vendor package you currently have installed, determine what patches were applied by the vendor, then apply those patches to the newer library version, and rebuild. If you have a command that can build a system installation package from source code and maybe patches that you provide, that would be even better. If you can do that, you can then install the new package you just compiled as an upgrade. If you can't build a new system package, you have to figure out what files were installed by the vendor's openssl package, and back them up. Then, you need to find the associated versions built by you, and place them by hand. And if you can't get the source code to the system version, you're going to have to wing it. On a machine that you can make mistakes on without inconveniencing other users, do the same thing as if you couldn't build a new system package. Then, after placing everything, you would generally (on most Linuxes, depending how recent their ld.so package is) run 'ldconfig' to rebuild the symbolic links to what they should be. But here's the scary part: you then need to shut the machine down, bring it back up, and attempt to connect to it via ssh or something. You will need to test *every* package that you use that links to openssl, in case there were any ABI incompatibilities introduced by the vendor. If there are any problems, you'll need to contact the vendor for an updated version. This may require paying additional support fees. Good luck! -Kyle H On Mon, Jul 16, 2018 at 1:36 AM, Dean Warren wrote: > Built openssl 0.9.8za with no problems on SUSE Linux Enterprise Server. > > Just followed > https://wiki.openssl.org/index.php/Compilation_and_Installation? > > Works a treat - thanks. > > > > However on sudo make install the new version doesn?t replace the system > installed version (obviously this may be different per system). > > > > How to make sudo make install overwrite my system version? > > Is this a parameter within ./Configure? > > And/or is it also OK to just replace original bins with symbolic links to > new built openssl binary and library (are there others?)? > > > > Thanks in advance > > Dean Warren > Solutions Architect ? Space Division > > SCISYS UK Limited > T: +44 (0)117 916 5182 > F: +44 (0)117 916 5299 > E: dean.warren at scisys.co.uk > http://www.scisys.co.uk > > > > > > SCISYS UK Limited. Registered in England and Wales No. 4373530. > Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK. > > Before printing, please think about the environment. > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From Dean.Warren at scisys.co.uk Mon Jul 16 09:31:31 2018 From: Dean.Warren at scisys.co.uk (Dean Warren) Date: Mon, 16 Jul 2018 09:31:31 +0000 Subject: [openssl-users] Deployment In-Reply-To: <787eb957-a431-46bd-ad13-d0a9e10795d3@openssl.org> References: <8CBE44978B040C41BCE9E0AF7527F7C807E698@citbs-mxexch0.scisys.co.uk> <787eb957-a431-46bd-ad13-d0a9e10795d3@openssl.org> Message-ID: <8CBE44978B040C41BCE9E0AF7527F7C807E6EB@citbs-mxexch0.scisys.co.uk> Yeah that does sounds scary. I will look into vendors options. Thanks Dean Warren -----Original Message----- From: openssl-users On Behalf Of Kyle Hamilton Sent: 16 July 2018 10:26 To: openssl-users Subject: Re: [openssl-users] Deployment Generally, you *really* do not want to replace the vendor-provided version. Vendors often alter things to be more compatible with their ABIs, which are the binary interfaces that other programs use to link to the vendor-provided libraries. If you find you actually do want to, it's best to figure out how to get the source code of the vendor package you currently have installed, determine what patches were applied by the vendor, then apply those patches to the newer library version, and rebuild. If you have a command that can build a system installation package from source code and maybe patches that you provide, that would be even better. If you can do that, you can then install the new package you just compiled as an upgrade. If you can't build a new system package, you have to figure out what files were installed by the vendor's openssl package, and back them up. Then, you need to find the associated versions built by you, and place them by hand. And if you can't get the source code to the system version, you're going to have to wing it. On a machine that you can make mistakes on without inconveniencing other users, do the same thing as if you couldn't build a new system package. Then, after placing everything, you would generally (on most Linuxes, depending how recent their ld.so package is) run 'ldconfig' to rebuild the symbolic links to what they should be. But here's the scary part: you then need to shut the machine down, bring it back up, and attempt to connect to it via ssh or something. You will need to test *every* package that you use that links to openssl, in case there were any ABI incompatibilities introduced by the vendor. If there are any problems, you'll need to contact the vendor for an updated version. This may require paying additional support fees. Good luck! -Kyle H On Mon, Jul 16, 2018 at 1:36 AM, Dean Warren wrote: > Built openssl 0.9.8za with no problems on SUSE Linux Enterprise Server. > > Just followed > https://wiki.openssl.org/index.php/Compilation_and_Installation? > > Works a treat - thanks. > > > > However on sudo make install the new version doesn?t replace the > system installed version (obviously this may be different per system). > > > > How to make sudo make install overwrite my system version? > > Is this a parameter within ./Configure? > > And/or is it also OK to just replace original bins with symbolic links > to new built openssl binary and library (are there others?)? > > > > Thanks in advance > > Dean Warren > Solutions Architect ? Space Division > > SCISYS UK Limited > T: +44 (0)117 916 5182 > F: +44 (0)117 916 5299 > E: dean.warren at scisys.co.uk > http://www.scisys.co.uk > > > > > > SCISYS UK Limited. Registered in England and Wales No. 4373530. > Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK. > > Before printing, please think about the environment. > > > -- > 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 From Michael.Wojcik at microfocus.com Mon Jul 16 14:26:32 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 16 Jul 2018 14:26:32 +0000 Subject: [openssl-users] Deployment In-Reply-To: <8CBE44978B040C41BCE9E0AF7527F7C807E6EB@citbs-mxexch0.scisys.co.uk> References: <8CBE44978B040C41BCE9E0AF7527F7C807E698@citbs-mxexch0.scisys.co.uk> <787eb957-a431-46bd-ad13-d0a9e10795d3@openssl.org> <8CBE44978B040C41BCE9E0AF7527F7C807E6EB@citbs-mxexch0.scisys.co.uk> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Dean Warren > Sent: Monday, July 16, 2018 03:32 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Deployment > > Yeah that does sounds scary. > I will look into vendors options. Also - why 0.9.8za? That's *ancient*. This seems like a lot of work for a result of rather dubious value. What problem are you trying to solve? -- Michael Wojcik Distinguished Engineer, Micro Focus From Dean.Warren at scisys.co.uk Mon Jul 16 14:32:20 2018 From: Dean.Warren at scisys.co.uk (Dean Warren) Date: Mon, 16 Jul 2018 14:32:20 +0000 Subject: [openssl-users] Deployment In-Reply-To: References: <8CBE44978B040C41BCE9E0AF7527F7C807E698@citbs-mxexch0.scisys.co.uk> <787eb957-a431-46bd-ad13-d0a9e10795d3@openssl.org> <8CBE44978B040C41BCE9E0AF7527F7C807E6EB@citbs-mxexch0.scisys.co.uk> Message-ID: <8CBE44978B040C41BCE9E0AF7527F7C807EBDC@citbs-mxexch0.scisys.co.uk> Another good question. I believe from the information I have been provided that 0.9.8za fixes the issues previously described for 0.9.8h, on SLES 11 SP1 (apparently). (Unless I am missing something here - highly possible?) Dean Warren -----Original Message----- From: openssl-users On Behalf Of Michael Wojcik Sent: 16 July 2018 15:27 To: openssl-users at openssl.org Subject: Re: [openssl-users] Deployment > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Dean Warren > Sent: Monday, July 16, 2018 03:32 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Deployment > > Yeah that does sounds scary. > I will look into vendors options. Also - why 0.9.8za? That's *ancient*. This seems like a lot of work for a result of rather dubious value. What problem are you trying to solve? -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users SCISYS UK Limited. Registered in England and Wales No. 4373530. Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK. Before printing, please think about the environment. From matt at openssl.org Mon Jul 16 14:47:41 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Jul 2018 15:47:41 +0100 Subject: [openssl-users] Deployment In-Reply-To: <8CBE44978B040C41BCE9E0AF7527F7C807EBDC@citbs-mxexch0.scisys.co.uk> References: <8CBE44978B040C41BCE9E0AF7527F7C807E698@citbs-mxexch0.scisys.co.uk> <787eb957-a431-46bd-ad13-d0a9e10795d3@openssl.org> <8CBE44978B040C41BCE9E0AF7527F7C807E6EB@citbs-mxexch0.scisys.co.uk> <8CBE44978B040C41BCE9E0AF7527F7C807EBDC@citbs-mxexch0.scisys.co.uk> Message-ID: On 16/07/18 15:32, Dean Warren wrote: > Another good question. > > I believe from the information I have been provided that 0.9.8za fixes the issues previously described for 0.9.8h, on SLES 11 SP1 (apparently). > (Unless I am missing something here - highly possible?) 0.9.8za may fix some issues present in 0.9.8h but it won't fix all the issues that have been discovered and fixed in the 4 years since it was released. The 0.9.8 version has been out of support by the OpenSSL project for some years now. Individual vendors may continue to support it and backport fixes to it - so you are better off getting the latest version from your vendor rather than from the OpenSSL project. Note that sometimes vendors freeze the version number, even though they are continuing to fix security issues, i.e. just because you have 0.9.8h it doesn't mean it has all the same issues that 0.9.8h sourced directly from the OpenSSL project has. The vendor may have patched the issues but maintained the version number at 0.9.8h. I can't say anything much specifically about Suse policy, but I did find this: https://www.suse.com/lifecycle/ This suggests that SLES 11 is still in support until 31st March 2019 (although the current version is listed as SP4 - so you may need to upgrade to that). This page suggests that their policy is to continue to fix security issues during that support period: https://www.suse.com/support/policy/ So, it seems to me, that your best bet is to upgrade to SP4 and ensure all patches are kept up-to-date. Note though that after 31st March 2019 you are into Long Term Service Pack Support (which presumably you have to pay extra for). Matt > > Dean Warren > > -----Original Message----- > From: openssl-users On Behalf Of Michael Wojcik > Sent: 16 July 2018 15:27 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Deployment > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >> Behalf Of Dean Warren >> Sent: Monday, July 16, 2018 03:32 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] Deployment >> >> Yeah that does sounds scary. >> I will look into vendors options. > > Also - why 0.9.8za? That's *ancient*. This seems like a lot of work for a result of rather dubious value. What problem are you trying to solve? > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > SCISYS UK Limited. Registered in England and Wales No. 4373530. > Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK. > > Before printing, please think about the environment. > From tongwangchen at gmail.com Mon Jul 16 15:18:57 2018 From: tongwangchen at gmail.com (Tong) Date: Mon, 16 Jul 2018 11:18:57 -0400 Subject: [openssl-users] TLS handshake certificate validation options Message-ID: Dear openssl-users: We have some old certificates that have ill-formed value for the subjectAltName extension, causing the TLS handshake to fail. Are there any options that can be configured to by-pass the parsing of the subjectAltName extension (or all the x509v3 extensions) during TLS handshake, without disabling the certificate validation all together? Thanks for any suggestions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Jul 16 16:08:28 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 16 Jul 2018 12:08:28 -0400 Subject: [openssl-users] Deployment In-Reply-To: <8CBE44978B040C41BCE9E0AF7527F7C807E698@citbs-mxexch0.scisys.co.uk> References: <8CBE44978B040C41BCE9E0AF7527F7C807E698@citbs-mxexch0.scisys.co.uk> Message-ID: <20180716160828.GL33554@straasha.imrryr.org> On Mon, Jul 16, 2018 at 08:36:47AM +0000, Dean Warren wrote: > Built openssl 0.9.8za with no problems on SUSE Linux Enterprise Server. Why would you want this particular version? It is no longer supported, and not even the last 0.9.8 release... -- Viktor. From cv.schmitt at gmail.com Mon Jul 16 19:02:38 2018 From: cv.schmitt at gmail.com (Carl-Valentin Schmitt) Date: Mon, 16 Jul 2018 21:02:38 +0200 Subject: [openssl-users] command passwd Message-ID: Up to recent time it was that Command passwd involved mcrypt. Right? Will soon OpenSSL substitute mcrypt? Or is OpenSSL too big for this? Thx for answer. Val. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jul 16 20:45:13 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 16 Jul 2018 20:45:13 +0000 Subject: [openssl-users] command passwd In-Reply-To: References: Message-ID: * Up to recent time it was that Command passwd involved mcrypt. Right? What is mcrypt? Do you mean MD5? (Probably not, but I wanted to ask.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cv.schmitt at gmail.com Mon Jul 16 20:51:09 2018 From: cv.schmitt at gmail.com (Carl-Valentin Schmitt) Date: Mon, 16 Jul 2018 22:51:09 +0200 Subject: [openssl-users] command passwd In-Reply-To: References: Message-ID: mcrypt not only has md5, it has blowfish too and other keys. You can download source at http://sf.net mcrypt is a linux command as follower oft command crypt. Salz, Rich via openssl-users schrieb am Mo., 16. Juli 2018, 22:45: > > - Up to recent time it was that Command passwd involved mcrypt. Right? > > > > What is mcrypt? Do you mean MD5? (Probably not, but I wanted to ask.) > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiml at omnigroup.com Mon Jul 16 20:57:34 2018 From: wiml at omnigroup.com (Wim Lewis) Date: Mon, 16 Jul 2018 13:57:34 -0700 Subject: [openssl-users] command passwd In-Reply-To: References: Message-ID: <672B264C-DA90-43DC-AB8D-532CDF27777E@omnigroup.com> On 16. j?l. 2018, at 1:51 e.h., Carl-Valentin Schmitt wrote: > mcrypt not only has md5, it has blowfish too and other keys. You can download source at http://sf.net > mcrypt is a linux command as follower oft command crypt. I don't think the "openssl passwd" command has ever used mcrypt. OpenSSL has implementations of (almost) all the relevant ciphers in libcrypto already. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jul 17 00:56:52 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 16 Jul 2018 20:56:52 -0400 Subject: [openssl-users] command passwd In-Reply-To: References: Message-ID: <20180717005652.GP33554@straasha.imrryr.org> On Mon, Jul 16, 2018 at 09:02:38PM +0200, Carl-Valentin Schmitt wrote: > Up to recent time it was that Command passwd involved mcrypt. Right? https://www.openssl.org/docs/manmaster/man1/passwd.html > Will soon OpenSSL substitute mcrypt? There has been little to no demand for any enhancements in this command-line utility. > Or is OpenSSL too big for this? Sounding like you're trolling might not be the best way to engage the team on suggestions to enhance the OpenSSL "passwd" command. -- Viktor. From jb-openssl at wisemo.com Tue Jul 17 03:02:48 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 17 Jul 2018 05:02:48 +0200 Subject: [openssl-users] command passwd In-Reply-To: References: Message-ID: On 16/07/2018 21:02, Carl-Valentin Schmitt wrote: > Up to recent time it was that Command passwd involved mcrypt. Right? > > Will soon OpenSSL substitute mcrypt? > Or is OpenSSL too big for this? > I guess you are referring to the libmcrypt, a cryptographic library which is kind of an alternative to OpenSSL's "libcrypto" (formerly libeay). I also presume this is about the OS level "passwd" command in some *N*X system, like Linux or BSD. If so, this would be up to the maintainers of that system command on that *N*X OS distribution to decide if they want to switch from using libmcrypt to using the OpenSSL 1.1.x's libcrypto to implement the standard cryptographic primitives involved in the *N*X password hashing schemes. In practice it should also be noted that there are often additional layers behind the passwd(1) command, such as PAM and libcrypt (no O or M).? So the actual decision to use libmcrypt, libcrypto or any other library would probably be up to the maintainer of that lower system layer. 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 angus at magsys.co.uk Tue Jul 17 09:00:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Tue, 17 Jul 2018 10:00 +0100 (BST) Subject: [openssl-users] ESNI in 1.1.1? Message-ID: Is there any way that Encrypted Server Name Indication will make the 1.1.1 release, or is too late or too experimental? Angus From matt at openssl.org Tue Jul 17 09:10:58 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Jul 2018 10:10:58 +0100 Subject: [openssl-users] ESNI in 1.1.1? In-Reply-To: References: Message-ID: <4034c015-bf5d-6f91-1158-4d2d073690d1@openssl.org> On 17/07/18 10:00, Angus Robertson - Magenta Systems Ltd wrote: > Is there any way that Encrypted Server Name Indication will make the > 1.1.1 release, or is too late or too experimental? 1.1.1 is frozen for new features, so there is no chance this would be included. In any case this is still in draft (and early draft at that). It would not be considered for inclusion until it was at RFC status. Matt From cv.schmitt at gmail.com Tue Jul 17 15:39:08 2018 From: cv.schmitt at gmail.com (SchmiTTT) Date: Tue, 17 Jul 2018 17:39:08 +0200 Subject: [openssl-users] command passwd In-Reply-To: <20180717005652.GP33554@straasha.imrryr.org> References: <20180717005652.GP33554@straasha.imrryr.org> Message-ID: <1531841948.5055.0@smtp.gmail.com> Hello Viktor, dont worry. Am not trolling. I take this seriously for my little project. :) Greetz. Val. Am Di, 17. Jul, 2018 um 2:56 A. M. schrieb Viktor Dukhovni : > On Mon, Jul 16, 2018 at 09:02:38PM +0200, Carl-Valentin Schmitt wrote: > >> Up to recent time it was that Command passwd involved mcrypt. Right? > > https://www.openssl.org/docs/manmaster/man1/passwd.html > >> Will soon OpenSSL substitute mcrypt? > > There has been little to no demand for any enhancements in this > command-line utility. > >> Or is OpenSSL too big for this? > > Sounding like you're trolling might not be the best way to engage > the team on suggestions to enhance the OpenSSL "passwd" command. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From thulasi.goriparthi at gmail.com Tue Jul 17 21:05:54 2018 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Wed, 18 Jul 2018 02:35:54 +0530 Subject: [openssl-users] TLS handshake certificate validation options In-Reply-To: References: Message-ID: Hello, You can register a verify callback function using X509_STORE_set_verify_cb() and X509_verify_cert() will call this function, which can be used to by-pass targeted errors like X509_V_ERR_INVALID_PURPOSE etc. Check callb function from apps/x509.c Thanks, Thulasi. On 16 July 2018 at 20:48, Tong wrote: > Dear openssl-users: > > We have some old certificates that have ill-formed value for the > subjectAltName extension, causing the TLS handshake to fail. > > Are there any options that can be configured to by-pass the parsing of the > subjectAltName extension (or all the x509v3 extensions) during TLS > handshake, without disabling the certificate validation all together? > > Thanks for any suggestions. > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From ryan at splintermail.com Tue Jul 17 22:36:47 2018 From: ryan at splintermail.com (Ryan Beethe) Date: Tue, 17 Jul 2018 17:36:47 -0500 Subject: [openssl-users] Appropriate use of SSL_CTX_set_cipher_list() Message-ID: <20180717223647.GA13977@archenemy.localdomain> I am writing a cross-platform C application, which I would like to release for a variety of operating systems (Windows 7+, MacOS HighSierra, Debian 8+, Ubuntu 14.04+, Fedora 27+, Centos 7+, ArchLinux, at least for now). Up to now, I have had a line of code which prepares an SSL_CTX object like something like this: SSL_CTX_set_cipher_list(ctx->ctx, CIPHERS); where `CIPHERS` was set to "HIGH:MED:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4". However, I realized that Fedora's packaging standards [1] require me to elminate this line or use the special value "PROFILE=SYSTEM" for CIPHERS. So that makes me nervous about whether or not I am using SSL_CTX_set_cipher_list() wrong. Should I be calling it at all? And if so, where would I find the "right" setting for other operating systems, since "PROFILE=SYSTEM" appears to be Fedora-specific? Ryan [1] https://fedoraproject.org/wiki/Packaging:CryptoPolicies From quae at daurnimator.com Wed Jul 18 02:00:16 2018 From: quae at daurnimator.com (Daurnimator) Date: Wed, 18 Jul 2018 12:00:16 +1000 Subject: [openssl-users] Appropriate use of SSL_CTX_set_cipher_list() In-Reply-To: <20180717223647.GA13977@archenemy.localdomain> References: <20180717223647.GA13977@archenemy.localdomain> Message-ID: On 18 July 2018 at 08:36, Ryan Beethe wrote: > So that makes me nervous about whether or not I am using > SSL_CTX_set_cipher_list() wrong. Should I be calling it at all? And if > so, where would I find the "right" setting for other operating systems, > since "PROFILE=SYSTEM" appears to be Fedora-specific? Mozilla maintain a recommended cipher list. See https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility From Michael.Wojcik at microfocus.com Wed Jul 18 13:56:15 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 18 Jul 2018 13:56:15 +0000 Subject: [openssl-users] Appropriate use of SSL_CTX_set_cipher_list() In-Reply-To: <20180717223647.GA13977@archenemy.localdomain> References: <20180717223647.GA13977@archenemy.localdomain> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Ryan Beethe > Sent: Tuesday, July 17, 2018 16:37 > > However, I realized that Fedora's packaging standards [1] require me to > elminate this line or use the special value "PROFILE=SYSTEM" for > CIPHERS. > > So that makes me nervous about whether or not I am using > SSL_CTX_set_cipher_list() wrong. Should I be calling it at all? I recommend you make it configurable. > And if > so, where would I find the "right" setting for other operating systems, > since "PROFILE=SYSTEM" appears to be Fedora-specific? Offhand, I'm not aware of other OSes that distribute implementations of OpenSSL that require platform-specific cipher-list settings. This strikes me as a Really Bad Idea on the part of the Fedora developers, but these days I'm not surprised by anything that comes out of the Red Hat organization. Personally, I'd be tempted to drop Fedora from my list of supported platforms, or to ignore their "packaging standards". I have little tolerance for this sort of nonsense. But if you want to accommodate them, put the cipher list in a configuration file, and set it to "PROFILE=SYSTEM" for Fedora and a proper suite list for everything else. That also gives your customers the flexibility to change the list if they have good reason, or if they just enjoy making poor decisions. I recommend Ivan Ristic's /Bulletproof TLS/ e-book (or the /OpenSSL Cookbook/ free excerpt, if you can't afford the full book) for cipher-suite recommendations, and much more besides. It's available from the Feisty Duck website. -- Michael Wojcik Distinguished Engineer, Micro Focus From cv.schmitt at gmail.com Wed Jul 18 16:02:22 2018 From: cv.schmitt at gmail.com (SchmiTTT) Date: Wed, 18 Jul 2018 18:02:22 +0200 Subject: [openssl-users] Fwd: Re: command passwd Message-ID: <1531929742.1833.0@smtp.gmail.com> Hello Wim and Rich, where is file "libcrypto" ? In which directory of OpenSSL-1.1.1pre8 ? thx. Greetz. Val. Am Di, 17. Jul, 2018 um 5:49 P. M. schrieb SchmiTTT : > > Hello Wim, > > I did not mean "OpenSSL passwd" - I meant the normal passwd command > in bash. > > Up to recent time this passwd command in bash involved mcrypt for > encryption of Password input. > > Val. > > Am Mo, 16. Jul, 2018 um 10:57 P. M. schrieb Wim Lewis > : >> >> On 16. j?l. 2018, at 1:51 e.h., Carl-Valentin Schmitt >>  wrote: >>> mcrypt not only has md5, it has blowfish too and other keys. You >>> can download source at http://sf.net >>> mcrypt is a linux command as follower oft command crypt. >> >> >> I don't think the "openssl passwd" command has ever used mcrypt. >> OpenSSL has implementations of (almost) all the relevant ciphers >> in libcrypto already. >> >> >> > From rsalz at akamai.com Wed Jul 18 17:30:45 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 18 Jul 2018 17:30:45 +0000 Subject: [openssl-users] Fwd: Re: command passwd In-Reply-To: <1531929742.1833.0@smtp.gmail.com> References: <1531929742.1833.0@smtp.gmail.com> Message-ID: > where is file "libcrypto" ? In which directory of OpenSSL-1.1.1pre8 ? It is not distributed. It is a library built as part of the compile process. From ryan at splintermail.com Wed Jul 18 20:24:31 2018 From: ryan at splintermail.com (Ryan Beethe) Date: Wed, 18 Jul 2018 15:24:31 -0500 Subject: [openssl-users] Appropriate use of SSL_CTX_set_cipher_list() In-Reply-To: References: <20180717223647.GA13977@archenemy.localdomain> Message-ID: <20180718202431.GA26188@archenemy.localdomain> > Offhand, I'm not aware of other OSes that distribute implementations > of OpenSSL that require platform-specific cipher-list settings. Ok, that is very helpful to know > This strikes me as a Really Bad Idea on the part of the Fedora > developers While it is a pain to have to have to have a Fedora-specific patch, I am not sure I understand why this is a bad idea? (Server applications like Apache do not fall under that guideline.) As a consumer of applications that use OpenSSL, I think I would prefer that an up-to-date list of acceptable ciphers is kept by the same folks who keep my libssl.so up-to-date, rather than depending on the developer of each individual application to keep their code in step with current security news. > I recommend Ivan Ristic's /Bulletproof TLS/ e-book I have been meaning to buy this book for a long time, so I finally did. Skimming through it, it looks excellent. I will also take another look at Mozilla's list (as mentioned by Daurnimator), and compare it to the suggestions in "Bulletproof TLS". I have been using the Mozilla list for server-side things, so I suppose it make sense to use it on the client side as well. But I still have one question, which I don't see answered explicitly anywhere: For a safe client application, should you explicitly set the cipher list explicitly, rather than trust the default cipher list that comes from the package manager's libssl? (obviously this question would not apply to operating systems which which don't distribute OpenSSL, or to Fedora) Thanks, Ryan From Michael.Wojcik at microfocus.com Wed Jul 18 22:12:55 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 18 Jul 2018 22:12:55 +0000 Subject: [openssl-users] Appropriate use of SSL_CTX_set_cipher_list() In-Reply-To: <20180718202431.GA26188@archenemy.localdomain> References: <20180717223647.GA13977@archenemy.localdomain> <20180718202431.GA26188@archenemy.localdomain> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Ryan Beethe > Sent: Wednesday, July 18, 2018 14:25 > > For a safe client application, should you explicitly set the cipher list > explicitly, rather than trust the default cipher list that comes from > the package manager's libssl? I don't think there's a definitive answer. It will depend on how well that OpenSSL package is maintained and how often the system administrator (who may just be Joe End User) updates it, the criteria used by the developer to set the cipher list, and so on. That said, I'll always prefer software that has a configurable cipher list with a decent default. If the software uses an OpenSSL provided by the OS manufacturer or some third party, and that OpenSSL comes with its own default cipher suite list, as in the Fedora case, then making the application's default "use the OpenSSL package's default" might well be acceptable. But as I user and system administrator, I always want the freedom to override it. The OpenSSL-consuming software I work on all uses our own OpenSSL builds - we don't use the OS-supplied one, if there is one - so this isn't an issue I have to deal with professionally. But we do make the cipher-suite list configurable, with a default that tries to strike a reasonable compromise between strength and compatibility. -- Michael Wojcik Distinguished Engineer, Micro Focus From pratyush.parimal at gmail.com Thu Jul 19 06:08:57 2018 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Thu, 19 Jul 2018 02:08:57 -0400 Subject: [openssl-users] How to compile OpenSSL 1.0.x with versioned symbols ? Message-ID: Hi all, Are people familiar with how to get symbols versioned with versions like "OPENSSL_1.0.x" in the libcrypto.so after compiling it yourselves? I have an application which was compiled and dynamically linked against OpenSSL 1.0.2k on a CentOS 6.7 machine. I'm trying to run it on a system where I've built and installed OpenSSL 1.0.2k myself. For compilation, I followed the instructions on the wiki page: https://wiki.openssl.org/index.php/Compilation_and_Installation? , i.e. I did: ./Configure ... make depend make make install Problem is, on execution my application complains that: "OPENSSL_1.0.2 not found". Performing "objdump -T" on the OpenSSL 1.0.2k libcrypto.so on the CentOS machine, I see some symbols versioned with the version number "OPENSSL_1.0.2" within the library. But these seem to be missing in the libcrypto.so which I built using the instructions above. Any idea how to get those symbols in ? Or how to get around this issue? Digging deeper I noticed that OpenSSL 1.1.0h (for example) does not have this problem. In fact, as part of the build process, it seems to generate two map files: ssl.map and crypto.map, which get passed as --version-script=ssl.map and --version-script=crypto.map sometime to the compiler. I also noticed that in that version of OpenSSL, there's a script called util/mkdef.pl which generates those map files. OpenSSL 1.0.2k for example, does not seem to generate those map files as part of the build process. Any idea how to generate them? I saw an example of how CentOS seems to be putting versioned symbols in using a patch (https://git.centos.org/blob/rpms!openssl.git/5fee79a733e7bcfa468ae8f400bad40a1002c8c5/SOURCES!openssl-1.0.1e-version.patch), but if someone could explain how to do that for any OpenSSL version, it would be very helpful. Thanks in advance! Pratyush. From matt at openssl.org Thu Jul 19 08:59:30 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 19 Jul 2018 09:59:30 +0100 Subject: [openssl-users] How to compile OpenSSL 1.0.x with versioned symbols ? In-Reply-To: References: Message-ID: <1eddf277-fb94-71dc-bf8a-9ccdc202728b@openssl.org> On 19/07/18 07:08, pratyush parimal wrote: > Hi all, > > Are people familiar with how to get symbols versioned with versions > like "OPENSSL_1.0.x" in the libcrypto.so after compiling it > yourselves? OpenSSL as sourced from the OpenSSL project does not support this in 1.0.x. > Problem is, on execution my application complains that: "OPENSSL_1.0.2 > not found". Performing "objdump -T" on the OpenSSL 1.0.2k libcrypto.so > on the CentOS machine, I see some symbols versioned with the version > number "OPENSSL_1.0.2" within the library. But these seem to be > missing in the libcrypto.so which I built using the instructions > above. Any idea how to get those symbols in ? Or how to get around > this issue? Vendors often patch OpenSSL with their own system specific changes. I know Debian did this to add symbol versioning for 1.0.x. It seems CentOS does too. > Digging deeper I noticed that OpenSSL 1.1.0h (for example) does not > have this problem. In fact, as part of the build process, it seems to > generate two map files: ssl.map and crypto.map, which get passed as > --version-script=ssl.map and --version-script=crypto.map sometime to > the compiler. I also noticed that in that version of OpenSSL, there's > a script called util/mkdef.pl which generates those map files. Yes, this was a new feature we added to 1.1.0. > > OpenSSL 1.0.2k for example, does not seem to generate those map files > as part of the build process. Any idea how to generate them? I saw an > example of how CentOS seems to be putting versioned symbols in using a > patch (https://git.centos.org/blob/rpms!openssl.git/5fee79a733e7bcfa468ae8f400bad40a1002c8c5/SOURCES!openssl-1.0.1e-version.patch), > but if someone could explain how to do that for any OpenSSL version, > it would be very helpful. You could try applying the CentOS patch to your own sources - but there is no official way to do this. Alternatively you could try building from the CentOS provided sources. Matt From mwood at iupui.edu Thu Jul 19 16:09:43 2018 From: mwood at iupui.edu (Mark H. Wood) Date: Thu, 19 Jul 2018 12:09:43 -0400 Subject: [openssl-users] Appropriate use of SSL_CTX_set_cipher_list() In-Reply-To: <20180718202431.GA26188@archenemy.localdomain> References: <20180717223647.GA13977@archenemy.localdomain> <20180718202431.GA26188@archenemy.localdomain> Message-ID: <20180719160943.GA13652@IUPUI.Edu> On Wed, Jul 18, 2018 at 03:24:31PM -0500, Ryan Beethe wrote: > For a safe client application, should you explicitly set the cipher list > explicitly, rather than trust the default cipher list that comes from > the package manager's libssl? I would say that the answer to that depends on another question: do you regularly review the package manager's default cipher list, and have reason to trust it? -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From cv.schmitt at gmail.com Thu Jul 19 22:18:19 2018 From: cv.schmitt at gmail.com (SchmiTTT) Date: Fri, 20 Jul 2018 00:18:19 +0200 Subject: [openssl-users] Fwd: Re: command passwd In-Reply-To: References: <1531929742.1833.0@smtp.gmail.com> Message-ID: <1532038699.15359.0@smtp.gmail.com> This is tricky to dig for the source code. I guess I would need the source code for libcrypto.a and for libcrypto.so, but so they are not part of openssl-package ... libcrypto.a and libcrypto.so are files which are built by linux-compiler? but somewhere has to be the source code for them ? Am Mi, 18. Jul, 2018 um 7:30 P. M. schrieb Salz, Rich via openssl-users : >> where is file "libcrypto" ? In which directory of >> OpenSSL-1.1.1pre8 ? > > It is not distributed. It is a library built as part of the compile > process. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rsalz at akamai.com Fri Jul 20 00:53:19 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 20 Jul 2018 00:53:19 +0000 Subject: [openssl-users] Fwd: Re: command passwd In-Reply-To: <1532038699.15359.0@smtp.gmail.com> References: <1531929742.1833.0@smtp.gmail.com> <1532038699.15359.0@smtp.gmail.com> Message-ID: <958C7647-78C0-4A77-9387-C5E1A47255CB@akamai.com> > libcrypto.a and libcrypto.so are files which are built by linux-compiler? but somewhere has to be the source code for them ? The files in the crypto directory are compiled to build the libraries. I think you will find some intro material on building C software useful. This is probably not a good place to find that info. From christian.boehme at cloudandheat.com Fri Jul 20 12:32:39 2018 From: christian.boehme at cloudandheat.com (=?UTF-8?Q?Christian_B=c3=b6hme?=) Date: Fri, 20 Jul 2018 14:32:39 +0200 Subject: [openssl-users] Authenticated encryption in CMS with OpenSSL Message-ID: <28c8158a-1d20-10ad-bbba-5b263b1b6385@cloudandheat.com> Hello all, While investigating if and how OpenSSL in several versions could be made to support authenticated encryption in CMS [1], I noticed that, e.g., AES in CCM and GCM modes disappeared completely in newer versions from the command line tools. That is, while, e.g., > openssl version OpenSSL 1.0.2g 1 Mar 2016 > openssl enc -ciphers 2>&1 | grep -E -i -- '-(ccm|gcm)' -aes-128-ccm -aes-128-cfb -aes-128-cfb1 -aes-128-gcm -aes-128-ofb -aes-128-xts -aes-192-cbc -aes-192-ccm -aes-192-cfb -aes-192-ecb -aes-192-gcm -aes-192-ofb -aes-256-ccm -aes-256-cfb -aes-256-cfb1 -aes-256-gcm -aes-256-ofb -aes-256-xts -gost89-cnt -id-aes128-CCM -id-aes128-GCM -id-aes128-wrap -id-aes192-CCM -id-aes192-GCM -id-aes192-wrap -id-aes256-CCM -id-aes256-GCM provides the modes, > openssl version OpenSSL 1.1.0h 27 Mar 2018 > openssl enc -ciphers | grep -E -i -- '-(ccm|gcm)' does not. The respective algorithms, such as EVP_aes_256_gcm() , appear to be available in both versions' libraries, though. Would someone perhaps involved in the release process be able to explain the reasoning behind dropping the authenticated encryption modes from the command line tools? Are there plans to extend OpenSSL's current support for CMS [2] to newer CMS versions? Or is there even a connection between the two, preventing the latter? Thanks, Christian [1] https://tools.ietf.org/html/rfc5083 [2] https://tools.ietf.org/html/rfc3369 -- *Christian B?hme* Developer System Integration CLOUD&HEAT *CLOUD & HEAT Technologies GmbH* K?nigsbr?cker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: christian.boehme at cloudandheat.com Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Gesch?ftsf?hrer: Nicolas R?hrs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: OpenPGP digital signature URL: From rsalz at akamai.com Fri Jul 20 13:19:52 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 20 Jul 2018 13:19:52 +0000 Subject: [openssl-users] Authenticated encryption in CMS with OpenSSL In-Reply-To: <28c8158a-1d20-10ad-bbba-5b263b1b6385@cloudandheat.com> References: <28c8158a-1d20-10ad-bbba-5b263b1b6385@cloudandheat.com> Message-ID: <6A3F8C64-F36F-489A-8195-D1CE9D689201@akamai.com> The ciphers are available, but the code to use things like AES-GCM never actually worked. Or if it claimed to work, it was actually broken. From christian.boehme at cloudandheat.com Fri Jul 20 13:41:14 2018 From: christian.boehme at cloudandheat.com (=?UTF-8?Q?Christian_B=c3=b6hme?=) Date: Fri, 20 Jul 2018 15:41:14 +0200 Subject: [openssl-users] Authenticated encryption in CMS with OpenSSL In-Reply-To: <6A3F8C64-F36F-489A-8195-D1CE9D689201@akamai.com> References: <28c8158a-1d20-10ad-bbba-5b263b1b6385@cloudandheat.com> <6A3F8C64-F36F-489A-8195-D1CE9D689201@akamai.com> Message-ID: <6e43c138-c579-0d6c-28ab-6bccd37b17e3@cloudandheat.com> On 20.07.2018 15:19, Salz, Rich via openssl-users wrote: > The ciphers are available, but the code to use things like AES-GCM never > actually worked. Or if it claimed to work, it was actually broken. I take this to mean there has actually code been written already to that effect. Has it made its way into the repo, and if so, which branch/tree could it be in? Thanks, Christian -- *Christian B?hme* Developer System Integration CLOUD&HEAT *CLOUD & HEAT Technologies GmbH* K?nigsbr?cker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: christian.boehme at cloudandheat.com Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Gesch?ftsf?hrer: Nicolas R?hrs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: OpenPGP digital signature URL: From rsalz at akamai.com Fri Jul 20 13:42:52 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 20 Jul 2018 13:42:52 +0000 Subject: [openssl-users] Authenticated encryption in CMS with OpenSSL In-Reply-To: <6e43c138-c579-0d6c-28ab-6bccd37b17e3@cloudandheat.com> References: <28c8158a-1d20-10ad-bbba-5b263b1b6385@cloudandheat.com> <6A3F8C64-F36F-489A-8195-D1CE9D689201@akamai.com> <6e43c138-c579-0d6c-28ab-6bccd37b17e3@cloudandheat.com> Message-ID: > The ciphers are available, but the code to use things like AES-GCM never > actually worked. Or if it claimed to work, it was actually broken. I take this to mean there has actually code been written already to that effect. Sorry I was not clear. This has not been implemented. In recent releases, we added a check to disallow AEAD ciphers, rather than failing (perhaps SILENTLY) later on. From christian.boehme at cloudandheat.com Fri Jul 20 13:56:29 2018 From: christian.boehme at cloudandheat.com (=?UTF-8?Q?Christian_B=c3=b6hme?=) Date: Fri, 20 Jul 2018 15:56:29 +0200 Subject: [openssl-users] Authenticated encryption in CMS with OpenSSL In-Reply-To: References: <28c8158a-1d20-10ad-bbba-5b263b1b6385@cloudandheat.com> <6A3F8C64-F36F-489A-8195-D1CE9D689201@akamai.com> <6e43c138-c579-0d6c-28ab-6bccd37b17e3@cloudandheat.com> Message-ID: <50a21053-4a32-d0a0-c578-011c0745cc59@cloudandheat.com> On 20.07.2018 15:42, Salz, Rich via openssl-users wrote: > Sorry I was not clear. > > This has not been implemented. In recent releases, we added a check to disallow AEAD ciphers, > rather than failing (perhaps SILENTLY) later on. Yeah, the checks happen in crypto/evp/evp_lib.c:EVP_CIPHER_param_to_asn1() . I understand that AEAD cipher support for CMS would have to be written from scratch, then. Thanks, Christian -- *Christian B?hme* Developer System Integration CLOUD&HEAT *CLOUD & HEAT Technologies GmbH* K?nigsbr?cker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: christian.boehme at cloudandheat.com Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Gesch?ftsf?hrer: Nicolas R?hrs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: OpenPGP digital signature URL: From cv.schmitt at gmail.com Sat Jul 21 03:36:04 2018 From: cv.schmitt at gmail.com (SchmiTTT) Date: Sat, 21 Jul 2018 05:36:04 +0200 Subject: [openssl-users] Fwd: Re: command passwd In-Reply-To: <958C7647-78C0-4A77-9387-C5E1A47255CB@akamai.com> References: <1531929742.1833.0@smtp.gmail.com> <1532038699.15359.0@smtp.gmail.com> <958C7647-78C0-4A77-9387-C5E1A47255CB@akamai.com> Message-ID: <0ab5c055-773b-25be-70ad-9cc3cdcad647@gmail.com> Is this correct? This concerns ANSI C Crypto Library ? I would have to edit libcrypt, when I want to change some sizes for libcrypto.a and for libcrypto.so ? Then compile it and merge it into Linux installation ? Am 20.07.2018 um 02:53 schrieb Salz, Rich: >> libcrypto.a and libcrypto.so are files which are built by > linux-compiler? > but somewhere has to be the source code for them ? > > > The files in the crypto directory are compiled to build the libraries. > > I think you will find some intro material on building C software useful. This is probably not a good place to find that info. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cv.schmitt at gmail.com Sat Jul 21 20:49:04 2018 From: cv.schmitt at gmail.com (Carl-Valentin Schmitt) Date: Sat, 21 Jul 2018 22:49:04 +0200 Subject: [openssl-users] Fwd: Re: command passwd In-Reply-To: <57714644-74C0-4BCE-A26B-BACB26AFD39F@akamai.com> References: <1531929742.1833.0@smtp.gmail.com> <1532038699.15359.0@smtp.gmail.com> <958C7647-78C0-4A77-9387-C5E1A47255CB@akamai.com> <0ab5c055-773b-25be-70ad-9cc3cdcad647@gmail.com> <57714644-74C0-4BCE-A26B-BACB26AFD39F@akamai.com> Message-ID: Are you Captain Kidd? Kidding the rest of your Staff? After your break you can write a howto, or I am finish when all goes well. Salz, Rich schrieb am Sa., 21. Juli 2018, 21:43: > No, it is completely wrong. > > > > I cannot give you a tutorial, sorry. > > > > *From: *SchmiTTT > *Date: *Friday, July 20, 2018 at 11:36 PM > *To: *Rich Salz , openssl-users < > openssl-users at openssl.org> > *Subject: *Re: [openssl-users] Fwd: Re: command passwd > > > > > > Is this correct? > > This concerns ANSI C Crypto Library ? > > I would have to edit libcrypt, when I want to change some sizes for > libcrypto.a and for libcrypto.so ? > > Then compile it and merge it into Linux installation ? > > > > > > > > Am 20.07.2018 um 02:53 schrieb Salz, Rich: > > libcrypto.a and libcrypto.so are files which are built by > > linux-compiler? > > but somewhere has to be the source code for them ? > > > > > > The files in the crypto directory are compiled to build the libraries. > > > > I think you will find some intro material on building C software useful. This is probably not a good place to find that info. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cv.schmitt at gmail.com Sun Jul 22 14:32:01 2018 From: cv.schmitt at gmail.com (Carl-Valentin Schmitt) Date: Sun, 22 Jul 2018 16:32:01 +0200 Subject: [openssl-users] Fwd: Re: command passwd In-Reply-To: References: <1531929742.1833.0@smtp.gmail.com> <1532038699.15359.0@smtp.gmail.com> <958C7647-78C0-4A77-9387-C5E1A47255CB@akamai.com> <0ab5c055-773b-25be-70ad-9cc3cdcad647@gmail.com> <57714644-74C0-4BCE-A26B-BACB26AFD39F@akamai.com> Message-ID: Thank you Thomas. Thomas J. Hruska schrieb am So., 22. Juli 2018, 16:08: > On 7/21/2018 1:49 PM, Carl-Valentin Schmitt wrote: > > Are you Captain Kidd? > > Kidding the rest of your Staff? > > > > After your break you can write a howto, or I am finish when all goes > well. > > > > Salz, Rich schrieb am Sa., 21. Juli 2018, 21:43: > > > >> No, it is completely wrong. > >> > >> I cannot give you a tutorial, sorry. > > Carl-Valentin, > > The instructions for building OpenSSL are in the product itself. See > the INSTALL file in the source tree. You can download the various > source code releases to OpenSSL from www.openssl.org. > > If you don't understand the INSTALL file, then maybe compiling OpenSSL > isn't right for you. If you run Linux as you claim, there's probably a > package in your package manager you can use where someone has > volunteered their time to take proper care of the package. > > Rich Salz actually gave you everything that you need to know: The magic > word "tutorial". There are tutorials on everything these days. You > just have to run Google searches for them. For example, a Google search > for "compile openssl tutorial" turns up a decent tutorial as the third > result: > > https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html > > There are even tutorials available online specific to each flavor of Linux. > > Hope that helps point you in the right direction. > > -- > Thomas Hruska > Shining Light Productions > > Home of BMP2AVI and Win32 OpenSSL. > http://www.slproweb.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cv.schmitt at gmail.com Sun Jul 22 14:36:08 2018 From: cv.schmitt at gmail.com (Carl-Valentin Schmitt) Date: Sun, 22 Jul 2018 16:36:08 +0200 Subject: [openssl-users] ... Message-ID: Hello Rich, I take back my "Captain Kidd"-remark. No offense. Val. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaymin.linux at gmail.com Mon Jul 23 11:23:31 2018 From: jaymin.linux at gmail.com (Jaymin D) Date: Mon, 23 Jul 2018 16:53:31 +0530 Subject: [openssl-users] Android AOSP Stuck due to 'libcrypto.so' Message-ID: Hi All, I have cross-compiled the openssl V1.1.0f for Android AOSP aarch64 platform. Below is my configure command for cross-compilation: ./Configure android64-aarch64 shared -fpic -fPIC -fpie -fPIE Copying 'libssl.so.1.1', 'libcrypto.so.1.1' and 'openssl(executable binary)' on the board and board has been stuck at some point in the next boot cycle. Whenever I restart the board with newly compiled 'libcrypto.so.1.1', board has been stuck in the next boot. Am trying to debug the issue, but not finding any particular root-cause for this behaviour. I have also tried V1.1.0h, but the behaviour was same. If more information require, please let me know. Any pointers or suggestions would be helpful. Regards, Jaymin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jul 23 14:55:01 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 23 Jul 2018 14:55:01 +0000 Subject: [openssl-users] ... In-Reply-To: References: Message-ID: * I take back my "Captain Kidd"-remark. * No offense. Aargh, matey. None taken. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.boehme at cloudandheat.com Mon Jul 23 14:56:55 2018 From: christian.boehme at cloudandheat.com (=?UTF-8?Q?Christian_B=c3=b6hme?=) Date: Mon, 23 Jul 2018 16:56:55 +0200 Subject: [openssl-users] openssl asn1parse -length Message-ID: Hello all, I have been trying to find a way to ascertain that the contents of a file is a DER-encoded ASN.1 structure such as $ openssl version OpenSSL 1.0.2g 1 Mar 2016 $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -i 0:d=0 hl=4 l= 978 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData 15:d=1 hl=4 l= 963 cons: cont [ 0 ] 19:d=2 hl=4 l= 959 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :03 26:d=3 hl=3 l= 133 cons: SET 29:d=4 hl=3 l= 130 cons: cont [ 3 ] 32:d=5 hl=2 l= 1 prim: INTEGER :00 35:d=5 hl=2 l= 27 cons: cont [ 0 ] 37:d=6 hl=2 l= 9 prim: OBJECT :PBKDF2 48:d=6 hl=2 l= 14 cons: SEQUENCE 50:d=7 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:64C8DCE92BE6CF80 60:d=7 hl=2 l= 2 prim: INTEGER :0800 64:d=5 hl=2 l= 46 cons: SEQUENCE 66:d=6 hl=2 l= 11 prim: OBJECT :id-alg-PWRI-KEK 79:d=6 hl=2 l= 31 cons: SEQUENCE 81:d=7 hl=2 l= 11 prim: OBJECT :camellia-256-cbc 94:d=7 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:DC131C842F099909DF465439C1B06038 112:d=5 hl=2 l= 48 prim: OCTET STRING [HEX DUMP]:7BEFFB307D05C8242A040B371EEA3C6F59F082C415057BF5A71F67437B92668CEED9C46B0F57B4E4A077B1651892D9D5 162:d=3 hl=4 l= 816 cons: SEQUENCE 166:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 177:d=4 hl=2 l= 31 cons: SEQUENCE 179:d=5 hl=2 l= 11 prim: OBJECT :camellia-256-cbc 192:d=5 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:995169EEF15C876E5F1A92DAF6A129D7 210:d=4 hl=4 l= 768 prim: cont [ 0 ] Since the files to test are rather large, I'd be content with being able to have only the first couple of bytes inspected. It would appear that the -length option allows to do just that. However, whatever argument specified, I get this: $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 4 Error in encoding 140548547200664:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:157: $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 16 Error in encoding 140076397213336:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 32 Error in encoding 139879438956184:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 64 Error in encoding 139887577974424:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 128 Error in encoding 140008118994584:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 256 Error in encoding 140518349809304:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 512 Error in encoding 140042967262872:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: etcpp. The files to test are expected to be at least 512 bytes in size. What's the expected behaviour of the -length option, BTW? Thanks, Christian -- *Christian B?hme* Developer System Integration CLOUD&HEAT *CLOUD & HEAT Technologies GmbH* K?nigsbr?cker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: christian.boehme at cloudandheat.com Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Gesch?ftsf?hrer: Nicolas R?hrs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: OpenPGP digital signature URL: From Michael.Wojcik at microfocus.com Mon Jul 23 15:00:20 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 23 Jul 2018 15:00:20 +0000 Subject: [openssl-users] Android AOSP Stuck due to 'libcrypto.so' In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jaymin D > Sent: Monday, July 23, 2018 05:24 > Whenever I restart the board with newly compiled 'libcrypto.so.1.1', board has been stuck in the next boot. Blocking trying to gather entropy during OpenSSL initialization, perhaps? I have not looked into how OpenSSL usually gathers entropy in Android. -- Michael Wojcik Distinguished Engineer, Micro Focus From cv.schmitt at gmail.com Mon Jul 23 15:06:11 2018 From: cv.schmitt at gmail.com (Carl-Valentin Schmitt) Date: Mon, 23 Jul 2018 17:06:11 +0200 Subject: [openssl-users] Android AOSP Stuck due to 'libcrypto.so' In-Reply-To: References: Message-ID: Android is as Linux not a complete Linux. (...missing Libraries?) I dont know if this would make sense, to post Android errors here. Michael Wojcik schrieb am Mo., 23. Juli 2018, 17:00: > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Jaymin D > > Sent: Monday, July 23, 2018 05:24 > > > Whenever I restart the board with newly compiled 'libcrypto.so.1.1', > board has been stuck in the next boot. > > Blocking trying to gather entropy during OpenSSL initialization, perhaps? > > I have not looked into how OpenSSL usually gathers entropy in Android. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Mon Jul 23 17:00:41 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 23 Jul 2018 17:00:41 +0000 Subject: [openssl-users] Android AOSP Stuck due to 'libcrypto.so' In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Carl-Valentin Schmitt > Sent: Monday, July 23, 2018 09:06 > Android is as Linux not a complete Linux. > I dont know if this would make sense, to post > Android errors here. This is the OpenSSL-Users list. It is in no way specific to Linux, or to any other operating system. (You would know that if you lurked for a while before posting, which is generally a good idea.) -- Michael Wojcik Distinguished Engineer, Micro Focus From jb-openssl at wisemo.com Tue Jul 24 09:41:02 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 24 Jul 2018 11:41:02 +0200 Subject: [openssl-users] openssl asn1parse -length In-Reply-To: References: Message-ID: <4c24ed9d-5d36-ed01-e246-21b0515d9707@wisemo.com> On 23/07/2018 16:56, Christian B?hme wrote: > Hello all, > > I have been trying to find a way to ascertain that the contents of a file > is a DER-encoded ASN.1 structure such as > > $ openssl version > OpenSSL 1.0.2g 1 Mar 2016 > > $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -i > 0:d=0 hl=4 l= 978 cons: SEQUENCE > 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData > 15:d=1 hl=4 l= 963 cons: cont [ 0 ] > 19:d=2 hl=4 l= 959 cons: SEQUENCE > 23:d=3 hl=2 l= 1 prim: INTEGER :03 > 26:d=3 hl=3 l= 133 cons: SET > 29:d=4 hl=3 l= 130 cons: cont [ 3 ] > 32:d=5 hl=2 l= 1 prim: INTEGER :00 > 35:d=5 hl=2 l= 27 cons: cont [ 0 ] > 37:d=6 hl=2 l= 9 prim: OBJECT :PBKDF2 > 48:d=6 hl=2 l= 14 cons: SEQUENCE > 50:d=7 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:64C8DCE92BE6CF80 > 60:d=7 hl=2 l= 2 prim: INTEGER :0800 > 64:d=5 hl=2 l= 46 cons: SEQUENCE > 66:d=6 hl=2 l= 11 prim: OBJECT :id-alg-PWRI-KEK > 79:d=6 hl=2 l= 31 cons: SEQUENCE > 81:d=7 hl=2 l= 11 prim: OBJECT :camellia-256-cbc > 94:d=7 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:DC131C842F099909DF465439C1B06038 > 112:d=5 hl=2 l= 48 prim: OCTET STRING [HEX DUMP]:7BEFFB307D05C8242A040B371EEA3C6F59F082C415057BF5A71F67437B92668CEED9C46B0F57B4E4A077B1651892D9D5 > 162:d=3 hl=4 l= 816 cons: SEQUENCE > 166:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data > 177:d=4 hl=2 l= 31 cons: SEQUENCE > 179:d=5 hl=2 l= 11 prim: OBJECT :camellia-256-cbc > 192:d=5 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:995169EEF15C876E5F1A92DAF6A129D7 > 210:d=4 hl=4 l= 768 prim: cont [ 0 ] > > Since the files to test are rather large, I'd be content with being able > to have only the first couple of bytes inspected. It would appear that the > -length option allows to do just that. However, whatever argument specified, > I get this: > > $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 4 > Error in encoding > 140548547200664:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:157: > $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 16 > Error in encoding > 140076397213336:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: > $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 32 > Error in encoding > 139879438956184:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: > $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 64 > Error in encoding > 139887577974424:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: > $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 128 > Error in encoding > 140008118994584:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: > $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 256 > Error in encoding > 140518349809304:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: > $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 512 > Error in encoding > 140042967262872:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147: > > etcpp. The files to test are expected to be at least 512 bytes in size. > > What's the expected behaviour of the -length option, BTW? > Best option is to download the documents that specify the DER (or BER) ASN.1 Encoding, which is the X.690 (2015) ITU-T "recommendation" which was a freely downloadable PDF last time I checked. Note: For clarity, DER is basically the BER but using the simplest byte sequence for everything.? BER can usually be converted to DER without knowing the data format specification (such as RFC2315 for EnvelopedData). From there, you can see that a DER (and BER) file is based on the following structure, nested and/or repeated as necessary: ? TAG??? An encoding of a data type number such as SEQUENCE ?????????? or "OBJECT" (Actually an OID). ? Length Byte length of contents (Variable length length ?????????? encoding, see X.690) ? Actual contents bytes according to TAG and specific data ?????????? type such as pkcs7 or X.509 etc.? Binary encoding ?????????? of each type is in X.690 ? Repeat terminator if Length was the (BER only) indefinite ? ? ?????? code used when a program starts output before ?????????? knowing the final length (See X.690) For example, the one you show below is thus: 0x30 (TAG for SEQUENCE) Some length value large enough to hold what follows, see X.690 ? 0x06 (TAG for OBJECT id) ? Any definite encoding of length = 9 bytes(127 possibilities) ? 0x2A (The bytes of pkcs7-envelopedData=1.2.840.113549.1.7.3) ? 0x86 .840 ? 0x48 ? 0x86 .113549 ? 0xF7 ? 0x0D ? 0x01 .1 ? 0x07 .7 ? 0x03 .3 Rest not needed for identification of a pkcs7-envelopedData file. Note that same length values can be encoded in more than one way if the file is in BER format, as is often the case with PKCS#7 files. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Soborg, 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 minfrin at sharp.fm Tue Jul 24 10:15:25 2018 From: minfrin at sharp.fm (Graham Leggett) Date: Tue, 24 Jul 2018 12:15:25 +0200 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? Message-ID: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> Hi all, Over at httpd we?re struggling with crashes and instability caused by attempts by various independent libraries we link to, all of which in turn link to openssl, initialising openssl multiple times. In turn these separate libraries might de-initialise openssl on shutdown expecting a re-initiailise to work and hilarity ensues. What is the correct way to handle openssl initialisation when multiple independent libraries are all trying to initialise openssl independently of one another? Is there reference counting of some kind? Could instability be caused by not matching the correct teardown function calls with the correct setup function calls? Regards, Graham ? From kaarthik.sk at gmail.com Tue Jul 24 11:18:48 2018 From: kaarthik.sk at gmail.com (Kaarthik Sivakumar) Date: Tue, 24 Jul 2018 16:48:48 +0530 Subject: [openssl-users] Using a TPM to sign CSRs Message-ID: An HTML attachment was scrubbed... URL: From minfrin at sharp.fm Tue Jul 24 11:40:22 2018 From: minfrin at sharp.fm (Graham Leggett) Date: Tue, 24 Jul 2018 13:40:22 +0200 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> Message-ID: <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> On 24 Jul 2018, at 12:15, Graham Leggett wrote: > Over at httpd we?re struggling with crashes and instability caused by attempts by various independent libraries we link to, all of which in turn link to openssl, initialising openssl multiple times. In turn these separate libraries might de-initialise openssl on shutdown expecting a re-initiailise to work and hilarity ensues. > > What is the correct way to handle openssl initialisation when multiple independent libraries are all trying to initialise openssl independently of one another? > > Is there reference counting of some kind? > > Could instability be caused by not matching the correct teardown function calls with the correct setup function calls? Focusing a little closer on openssl v1.1.0 we get the following, but this also seems broken at first glance. https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html "Once OPENSSL_cleanup() has been called the library cannot be reinitialised?. In our case, httpd will load mod_ssl (and in APR apr_crypto_openssl) which is in turn linked to openssl, and during a restart the module (and therefore the link to openssl I believe) will be unloaded, and thus OPENSSL_cleanup() will fail when httpd finally exits and calls atexit. Am I interpreting the above correctly? Or is it correct in v1.1.0 and above to just not initialise anything at all, not clean anything up at all, and expect openssl to ?do the right thing? when mod_ssl is unloaded? Regards, Graham ? From christian.boehme at cloudandheat.com Tue Jul 24 12:39:01 2018 From: christian.boehme at cloudandheat.com (=?UTF-8?Q?Christian_B=c3=b6hme?=) Date: Tue, 24 Jul 2018 14:39:01 +0200 Subject: [openssl-users] openssl asn1parse -length In-Reply-To: <4c24ed9d-5d36-ed01-e246-21b0515d9707@wisemo.com> References: <4c24ed9d-5d36-ed01-e246-21b0515d9707@wisemo.com> Message-ID: On 24.07.2018 11:41, Jakob Bohm wrote: > Best option is to download the documents that specify the DER > (or BER) ASN.1 Encoding, which is the X.690 (2015) ITU-T > "recommendation" which was a freely downloadable PDF last time > I checked. [?] > For example, the one you show below is thus: > 0x30 (TAG for SEQUENCE) > Some length value large enough to hold what follows, see X.690 > ? 0x06 (TAG for OBJECT id) > ? Any definite encoding of length = 9 bytes(127 possibilities) > ? 0x2A (The bytes of pkcs7-envelopedData=1.2.840.113549.1.7.3) > ? 0x86 .840 > ? 0x48 > ? 0x86 .113549 > ? 0xF7 > ? 0x0D > ? 0x01 .1 > ? 0x07 .7 > ? 0x03 .3 > Rest not needed for identification of a pkcs7-envelopedData file. > > Note that same length values can be encoded in more than one way > if the file is in BER format, as is often the case with PKCS#7 > files. Thanks heaps for your input. Much appreciated! Cheers, Christian -- *Christian B?hme* Developer System Integration CLOUD&HEAT *CLOUD & HEAT Technologies GmbH* K?nigsbr?cker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: christian.boehme at cloudandheat.com Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Gesch?ftsf?hrer: Nicolas R?hrs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: OpenPGP digital signature URL: From openssl-users at dukhovni.org Tue Jul 24 16:06:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 24 Jul 2018 12:06:53 -0400 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> Message-ID: <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> > On Jul 24, 2018, at 7:40 AM, Graham Leggett wrote: > > Or is it correct in v1.1.0 and above to just not initialise anything at all, not clean anything up at all, and expect openssl to ?do the right thing? when mod_ssl is unloaded? Yes. And *especially* when the code that depends on OpenSSL is itself a library. OpenSSL is now (and should ideally always have been) self-initializing. -- Viktor. From kgoldman at us.ibm.com Wed Jul 25 14:05:50 2018 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 25 Jul 2018 10:05:50 -0400 Subject: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm Message-ID: Seeking advice. I have a certificate with a non-standard public key algorithm -rsaesOaep. See snippet #2. With openssl 1.0, I can validate the certificate chain. With openssl 1.1 it fails with the error X509_V_ERR_EE_KEY_TOO_SMALL. See dump #1. I believe that this is due to new 1.1 code x509_vfy.c:check_key_level() calling X509_get0_pubkey(). That call will fail for the non-standard algorithm. The certificate is for old vendor hardware that cannot be updated. What are my choices? - Remain on 1.0 - Some configuration option? - Something else? #1 ~~~~~~~~~ openssl verify -CAfile cafile.pem infcert.pem error 66 at 0 depth lookup: EE certificate key too weak error infcert.pem: verification failed 22794983405376:error:0609E09C:digital envelope routines:pkey_set_type:unsupported algorithm:crypto/evp/p_lib.c:206: 22794983405376:error:0B09406F:x509 certificate routines:x509_pubkey_decode:unsupported algorithm:crypto/x509/x_pubkey.c:113: #2 ~~~~~~~~~ Subject: Subject Public Key Info: Public Key Algorithm: rsaesOaep Unable to load Public Key 140619228055400:error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239: 140619228055400:error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm:x_pubkey.c:155: X509v3 extensions: From openssl-users at dukhovni.org Wed Jul 25 14:47:49 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Jul 2018 10:47:49 -0400 Subject: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm In-Reply-To: References: Message-ID: > On Jul 25, 2018, at 10:05 AM, Ken Goldman wrote: > > I have a certificate with a non-standard public key algorithm -rsaesOaep. See snippet #2. > > With openssl 1.0, I can validate the certificate chain. With openssl 1.1 it fails with the error X509_V_ERR_EE_KEY_TOO_SMALL. See dump #1. > > I believe that this is due to new 1.1 code x509_vfy.c:check_key_level() calling X509_get0_pubkey(). That call will fail for the non-standard algorithm. > > The certificate is for old vendor hardware that cannot be updated. What are my choices? > > - Remain on 1.0 > - Some configuration option? > - Something else? The immediate cause is the order of the checks in check_key_level(). It first checks for a supported key, and only then short-circuits the logic at level <= 0 (my fault). Perhaps level 0 should not be strict in this way, in which case we might reverse the order of then (pkey == NULL) and (level <= 0) tests: static int check_key_level(X509_STORE_CTX *ctx, X509 *cert) { EVP_PKEY *pkey = X509_get0_pubkey(cert); int level = ctx->param->auth_level; /* Unsupported or malformed keys are not secure */ if (pkey == NULL) return 0; if (level <= 0) return 1; if (level > NUM_AUTH_LEVELS) level = NUM_AUTH_LEVELS; return EVP_PKEY_security_bits(pkey) >= minbits_table[level - 1]; } -- Viktor. From bill.c.roberts at gmail.com Wed Jul 25 15:28:22 2018 From: bill.c.roberts at gmail.com (William Roberts) Date: Wed, 25 Jul 2018 08:28:22 -0700 Subject: [openssl-users] Using a TPM to sign CSRs In-Reply-To: References: Message-ID: On Tue, Jul 24, 2018 at 4:18 AM, Kaarthik Sivakumar wrote: > Hello > > I need to create a key pair using a TPM (proprietary) and build a CSR and What TPM Version? If it's TPM 2.0, a new Engine project has emerged here: https://github.com/tpm2-software/tpm2-tss-engine This might be able to handle to just calling the create CSR routine. I know back-in- the-day the OpenSC engine with a PIV card could do it. You can try to get ahold of the maintainer of that project (Andraes) through a direct email or the project mailing list: - https://lists.01.org/mailman/listinfo/tpm2 > sign it using it the TPM as well. Currently I dont have an engine interface > to talk to the TPM. I do the following: > > 1. generate key pair in the TPM. private key is kept private in the TPM and > public key can be obtained out of the TPM > > 2. use the public key to generate a CSR (X509_REQ_init(), etc) > > 3. Get the hash of the CSR (X509_REQ_digest()) > > 4. Pass the digest to the TPM and get back signature > > 5. Add signature to the CSR - I dont see any way to do this. Is there an > openssl API to perform this step? I dont think I can use X509_REQ_sign() > since that will use the private key provided or if I have an engine > interface then it will call the engine to do the signing. Is there a way to > call sign() and make it call my function that can do the step 4 above? > > Thanks! > > > -kaarthik- > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From kaarthik.sk at gmail.com Wed Jul 25 16:39:39 2018 From: kaarthik.sk at gmail.com (Kaarthik Sivakumar) Date: Wed, 25 Jul 2018 22:09:39 +0530 Subject: [openssl-users] Using a TPM to sign CSRs In-Reply-To: References: Message-ID: <0b0670ca-8325-a1cd-a76e-736c9a0b420f@gmail.com> An HTML attachment was scrubbed... URL: From sudarshan12s at gmail.com Wed Jul 25 18:12:34 2018 From: sudarshan12s at gmail.com (Sudarshan Soma) Date: Wed, 25 Jul 2018 23:42:34 +0530 Subject: [openssl-users] conversion of RAND_bytes to rand in fips apporved way Message-ID: Hi, we have linked FIPS compliant openssl version against our applications. Now few applications are using libc rand function. For FIPS compliance, applications have to call approved SP 800-90A DRBG implementation. I was planning to replace libc rand with RAND_bytes for the same. But rand() returns max value of 32767 . Is there a recomended way to convert RAND_bytes to libc rand() something like this? unsigned char buf[2]; RAND_bytes(buf,2) int *rndp = malloc(4); memcpy(rndp,buf,2); return (unsigned) ((*rndp) % 32768) Please suggest . Is there a way to give number of bits instead of bytes to RAND_bytes? Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 25 18:20:57 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 25 Jul 2018 18:20:57 +0000 Subject: [openssl-users] conversion of RAND_bytes to rand in fips apporved way In-Reply-To: References: Message-ID: <0EAB5144-E067-4DE3-A7BC-951331FFD4E5@akamai.com> If RAND_MAX is a power of 2, then just ask RAND_bytes for the right number of bytes (four for 32768) and use bit-shifting to pack the value. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jul 25 18:26:21 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Jul 2018 14:26:21 -0400 Subject: [openssl-users] conversion of RAND_bytes to rand in fips apporved way In-Reply-To: References: Message-ID: <20180725182621.GL33554@straasha.imrryr.org> On Wed, Jul 25, 2018 at 11:42:34PM +0530, Sudarshan Soma wrote: > Now few applications are using libc rand function. For FIPS compliance, > applications have to call approved SP 800-90A DRBG implementation. If you're using libc's rand() for non-cryptographic purposes, you can surely continue to do that. > I was planning to replace libc rand with RAND_bytes for the same. > > But rand() returns max value of 32767. Is there a recomended way to > convert RAND_bytes to libc rand() something like this? Since 16-bit random numbers do not provide any meaningful security, it makes little sense to use a CSPRNG in a context where 16-bit random values are sufficient. > Please suggest. Is there a way to give number of bits instead of bytes to > RAND_bytes? This is probably the wrong question. -- Viktor. From Michael.Wojcik at microfocus.com Wed Jul 25 18:30:31 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 25 Jul 2018 18:30:31 +0000 Subject: [openssl-users] conversion of RAND_bytes to rand in fips apporved way In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Sudarshan Soma > Sent: Wednesday, July 25, 2018 12:13 > But rand() returns max value of 32767 . Is there a recomended way to > convert RAND_bytes to libc rand() > something like this? > unsigned char buf[2]; > RAND_bytes(buf,2) > int *rndp = malloc(4); > memcpy(rndp,buf,2); > return (unsigned) ((*rndp) % 32768) Ugh. Memory leak, unnecessary malloc, undefined behavior (only part of the rdnp object is initialized)... I really hope you don't have code like this in your application. C guarantees unsigned integer types use a pure binary representation, and 32767 is 2**15 - 1. So assuming you're only using octet-based C implementations (limits.h defines CHAR_BIT as 8), which is very likely the case, just do this: unsigned int openssl_rand(void) { unsigned char bytes[2]; RAND_bytes(bytes, 2); return (bytes[0] | (bytes[1] << 8)) & 0x7fff; } Untested, but I think that will work on any conforming C implementation with CHAR_BIT == 8, and as long as the 15 least-significant bits of the output of RAND_bytes are unbiased, the result will be an unbiased value in [0,32767]. Note this does not give you the semantics of C's rand, as it ignores any invocation of srand. Some C programs require a predictable rand; they use it for reproducible Monte Carlo test runs, for example. So replacing rand this way is not necessarily valid. Also, calling it "rand" would be a violation of the C specification, so if you want your C applications to conform to the spec, you'll have to change them anyway. Or use a macro, provided the application code never suppresses a macro definition for rand. -- Michael Wojcik Distinguished Engineer, Micro Focus From bill.c.roberts at gmail.com Wed Jul 25 19:00:17 2018 From: bill.c.roberts at gmail.com (William Roberts) Date: Wed, 25 Jul 2018 12:00:17 -0700 Subject: [openssl-users] conversion of RAND_bytes to rand in fips apporved way In-Reply-To: References: Message-ID: On Wed, Jul 25, 2018 at 11:30 AM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Sudarshan Soma >> Sent: Wednesday, July 25, 2018 12:13 > >> But rand() returns max value of 32767 . Is there a recomended way to >> convert RAND_bytes to libc rand() >> something like this? > >> unsigned char buf[2]; >> RAND_bytes(buf,2) >> int *rndp = malloc(4); >> memcpy(rndp,buf,2); >> return (unsigned) ((*rndp) % 32768) > > Ugh. Memory leak, unnecessary malloc, undefined behavior (only part of the rdnp object is initialized)... I really hope you don't have code like this in your application. > > C guarantees unsigned integer types use a pure binary representation, and 32767 is 2**15 - 1. So assuming you're only using octet-based C implementations (limits.h defines CHAR_BIT as 8), which is very likely the case, just do this: > > unsigned int openssl_rand(void) { LibC's rand() is int, so if it matters you'll want to match that interface. But usually, you want to avoid signed numbers when negative doesn't matter.. > unsigned char bytes[2]; > RAND_bytes(bytes, 2); > return (bytes[0] | (bytes[1] << 8)) & 0x7fff; You can ditch the shift logic. Offhand, i'm not sure what would happen on Big Endian machine, would it leave bit 15 high since it's in byte 0? int openssl_rand(void) { uint16_t x; RAND_bytes((unsigned char *)&x, sizeof(x)); return x & 0x7FFF; } > } > > Untested, but I think that will work on any conforming C implementation with CHAR_BIT == 8, and as long as the 15 least-significant bits of the output of RAND_bytes are unbiased, the result will be an unbiased value in [0,32767]. > > Note this does not give you the semantics of C's rand, as it ignores any invocation of srand. Some C programs require a predictable rand; they use it for reproducible Monte Carlo test runs, for example. So replacing rand this way is not necessarily valid. > > Also, calling it "rand" would be a violation of the C specification, so if you want your C applications to conform to the spec, you'll have to change them anyway. Or use a macro, provided the application code never suppresses a macro definition for rand. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From kgoldman at us.ibm.com Wed Jul 25 19:00:19 2018 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 25 Jul 2018 15:00:19 -0400 Subject: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm In-Reply-To: References: Message-ID: On 7/25/2018 10:47 AM, Viktor Dukhovni wrote: > > >> On Jul 25, 2018, at 10:05 AM, Ken Goldman wrote: >> >> I have a certificate with a non-standard public key algorithm -rsaesOaep. See snippet #2. >> >> With openssl 1.0, I can validate the certificate chain. With openssl 1.1 it fails with the error X509_V_ERR_EE_KEY_TOO_SMALL. See dump #1. >> >> I believe that this is due to new 1.1 code x509_vfy.c:check_key_level() calling X509_get0_pubkey(). That call will fail for the non-standard algorithm. >> >> The certificate is for old vendor hardware that cannot be updated. What are my choices? >> >> - Remain on 1.0 >> - Some configuration option? >> - Something else? > > The immediate cause is the order of the checks in check_key_level(). > It first checks for a supported key, and only then short-circuits > the logic at level <= 0 (my fault). Perhaps level 0 should not be > strict in this way, in which case we might reverse the order of > then (pkey == NULL) and (level <= 0) tests: > > static int check_key_level(X509_STORE_CTX *ctx, X509 *cert) > { > EVP_PKEY *pkey = X509_get0_pubkey(cert); > int level = ctx->param->auth_level; > > /* Unsupported or malformed keys are not secure */ > if (pkey == NULL) > return 0; > > if (level <= 0) > return 1; > if (level > NUM_AUTH_LEVELS) > level = NUM_AUTH_LEVELS; > > return EVP_PKEY_security_bits(pkey) >= minbits_table[level - 1]; > } If you're suggesting that altering the above code to do the level check before the call to get pkey, I think that would fix my problem. ... if I can set level to a negative value. How do I set level? Is there an API or a configuration file. From Michael.Wojcik at microfocus.com Wed Jul 25 20:03:41 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 25 Jul 2018 20:03:41 +0000 Subject: [openssl-users] conversion of RAND_bytes to rand in fips apporved way In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of William Roberts > Sent: Wednesday, July 25, 2018 13:00 > > > unsigned char bytes[2]; > > RAND_bytes(bytes, 2); > > return (bytes[0] | (bytes[1] << 8)) & 0x7fff; > > You can ditch the shift logic. Offhand, i'm not sure what would > happen on Big Endian machine, would it leave bit 15 high since it's in > byte 0? No. Bitwise operators in C work according to value, not representation, regardless of the byte order of multibyte integer types in that implementation. > int openssl_rand(void) { > uint16_t x; > RAND_bytes((unsigned char *)&x, sizeof(x)); > return x & 0x7FFF; > } That's OK if you include stdint.h, because you don't care which of the two permissible representations uint15_t has (it has to be pure-binary with no trap representations) - IF your implementation has a 16-bit unsigned integer type. uint16_t won't be defined for an implementation that doesn't. Offhand I don't know of one that is CHAR_BIT 8, though. Personally, I don't care for your version, because I don't like to see code manipulate the representation of an object without specific reason. My version follows the same pattern that correctly-written integer-marshaling code should use, for example; it has the same behavior regardless of implementation details (assuming, once again, that CHAR_BIT is 8). By the way, sizeof is an operator. There's no need to parenthesize its operand, unless the operand is a type. Of course, as Viktor pointed out, this all may be pointless anyway; it's not clear that the OP needs this functionality. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl-users at dukhovni.org Wed Jul 25 20:27:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Jul 2018 16:27:53 -0400 Subject: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm In-Reply-To: References: Message-ID: <8E9CE58B-0A83-4995-8DF6-DC6EF856C1D7@dukhovni.org> > On Jul 25, 2018, at 3:00 PM, Ken Goldman wrote: > > > If you're suggesting that altering the above code to do the level check before the call to get pkey, I think that would fix my problem. Yes, that's what I'm saying, but also asking the broader list for feedback on such a change. Should security level zero succeed even with unsupported EE keys (which somehow get used with some other software???). > ... if I can set level to a negative value. How do I set level? Is there an API or a configuration file. It does not need to be negative, the test is "<= 0", but the default is in fact -1 (not set). There is indeed a function for setting a non-default security level: X509_VERIFY_PARAM_set_auth_level() and it is documented. -- Viktor. From kgoldman at us.ibm.com Wed Jul 25 20:50:43 2018 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 25 Jul 2018 16:50:43 -0400 Subject: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm In-Reply-To: <8E9CE58B-0A83-4995-8DF6-DC6EF856C1D7@dukhovni.org> References: <8E9CE58B-0A83-4995-8DF6-DC6EF856C1D7@dukhovni.org> Message-ID: On 7/25/2018 4:27 PM, Viktor Dukhovni wrote: > > Yes, that's what I'm saying, but also asking the broader list for feedback > on such a change. Should security level zero succeed even with unsupported > EE keys (which somehow get used with some other software???). For background, this is the TPM 1.2 endorsement key certificate. I.e., this is a real application with millions of certificates issued. The key is an RSA-2048 key. The TCG (for a while) specified Public Key Algorithm: rsaesOaep rather than the commonly used Public Key Algorithm: rsaEncryption because the key is an encryption key rather than a signing key. The X509 certificate parser fails to get the public key. ~~~~~~~~~~~~~~~~~~~~~~~~ An alternative fix (I got a patch for 098 from an openssl maintainer) that accepts rsaOaep would also fix the issue. From openssl-users at dukhovni.org Wed Jul 25 22:29:27 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Jul 2018 18:29:27 -0400 Subject: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm In-Reply-To: References: <8E9CE58B-0A83-4995-8DF6-DC6EF856C1D7@dukhovni.org> Message-ID: <2D79250A-9E92-483F-BCB7-33FEEDC083AC@dukhovni.org> > On Jul 25, 2018, at 4:50 PM, Ken Goldman wrote: > > For background, this is the TPM 1.2 endorsement key certificate. I.e., this is a real application with millions of certificates issued. The key is an RSA-2048 key. > > The TCG (for a while) specified > > Public Key Algorithm: rsaesOaep > > rather than the commonly used > > Public Key Algorithm: rsaEncryption > > because the key is an encryption key rather than a signing key. > The X509 certificate parser fails to get the public key. > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > An alternative fix (I got a patch for 098 from an openssl maintainer) > that accepts rsaOaep would also fix the issue. Or perhaps both. It is not clear that my choice of rejecting unsupported key algorithms at security level 0 is the right one, but it would of course be best if the key algorithm were supported if it has non-negligible "legitimate" use. Perhaps open an issue (or PR) on github proposing (or implementing) a change to the check_key_level() logic and see whether there is support for it? -- Viktor. From amjadmsit at gmail.com Thu Jul 26 02:06:03 2018 From: amjadmsit at gmail.com (Amjad Ali) Date: Thu, 26 Jul 2018 10:06:03 +0800 Subject: [openssl-users] no shared cipher issue with freeradius Message-ID: Hi All, My client is a windows XP and Freeradius version is 3.0.15 and openssl version is [OpenSSL 1.0.1t 3 May 2016 (Library: OpenSSL 1.0.2k 26 Jan 2017)] The client sends these cipher suites to the server in auth request Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009) Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064) Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062) Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003) Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012) Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063) but I get a no shared cipher error and handshake fails. My understanding is quite limited on this issue but I've tried to set cipher_list = "DEFAULT" and "ALL:!EXPORT:!eNULL:!SSLv2" in eap.conf but nothing seems to work, I get the same no cipher issue. Assuming FreeRadius gets its ciphers from Openssl, is there a way I can make openssl to include the above keys in its cipher list? I tried to update these ciphers on the client but I couldn't find anything on google. I would appreciate if anyone can help in this regard. Many Thanks Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Thu Jul 26 13:01:22 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 26 Jul 2018 09:01:22 -0400 Subject: [openssl-users] EDDSA support yet? Message-ID: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> My Fedora 28 shipped with: OpenSSL 1.1.0h-fips? 27 Mar 2018 Does that have ED25519 support? It takes real time to set up my full test environment, and I really don't have the time right now if I am going to have to see what is in store for Fedora 29... Thanks From openssl-users at dukhovni.org Thu Jul 26 14:07:07 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 26 Jul 2018 10:07:07 -0400 Subject: [openssl-users] EDDSA support yet? In-Reply-To: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> References: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> Message-ID: > On Jul 26, 2018, at 9:01 AM, Robert Moskowitz wrote: > > My Fedora 28 shipped with: > > OpenSSL 1.1.0h-fips 27 Mar 2018 > > Does that have ED25519 support? No. You'd need 1.1.1 for that, it is currently in beta. -- Viktor. From rgm at htt-consult.com Thu Jul 26 14:10:51 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 26 Jul 2018 10:10:51 -0400 Subject: [openssl-users] EDDSA support yet? In-Reply-To: References: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> Message-ID: On 07/26/2018 10:07 AM, Viktor Dukhovni wrote: > >> On Jul 26, 2018, at 9:01 AM, Robert Moskowitz wrote: >> >> My Fedora 28 shipped with: >> >> OpenSSL 1.1.0h-fips 27 Mar 2018 >> >> Does that have ED25519 support? > No. You'd need 1.1.1 for that, it is currently in beta. > No wonder Dr. Google failed me.? I will have to see what I can do. Perhaps put together a Rawhide system then try for a build.? But that takes for a time commitment. thanks From tmraz at redhat.com Thu Jul 26 14:19:06 2018 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 26 Jul 2018 16:19:06 +0200 Subject: [openssl-users] EDDSA support yet? In-Reply-To: References: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> Message-ID: <1532614746.13685.4.camel@redhat.com> On Thu, 2018-07-26 at 10:10 -0400, Robert Moskowitz wrote: > > On 07/26/2018 10:07 AM, Viktor Dukhovni wrote: > > > > > On Jul 26, 2018, at 9:01 AM, Robert Moskowitz > > m> wrote: > > > > > > My Fedora 28 shipped with: > > > > > > OpenSSL 1.1.0h-fips 27 Mar 2018 > > > > > > Does that have ED25519 support? > > > > No. You'd need 1.1.1 for that, it is currently in beta. > > > > No wonder Dr. Google failed me. I will have to see what I can do. > Perhaps put together a Rawhide system then try for a build. But > that > takes for a time commitment. > Please note that there is now openssl-1.1.1-pre8 in Rawhide since yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final release so we will not ship an openssl prerelease in it. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From rgm at htt-consult.com Thu Jul 26 14:33:14 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 26 Jul 2018 10:33:14 -0400 Subject: [openssl-users] EDDSA support yet? In-Reply-To: <1532614746.13685.4.camel@redhat.com> References: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> <1532614746.13685.4.camel@redhat.com> Message-ID: <578ea627-93fa-3cc4-f404-ec44fdd5e177@htt-consult.com> On 07/26/2018 10:19 AM, Tomas Mraz wrote: > On Thu, 2018-07-26 at 10:10 -0400, Robert Moskowitz wrote: >> On 07/26/2018 10:07 AM, Viktor Dukhovni wrote: >>>> On Jul 26, 2018, at 9:01 AM, Robert Moskowitz >>> m> wrote: >>>> >>>> My Fedora 28 shipped with: >>>> >>>> OpenSSL 1.1.0h-fips 27 Mar 2018 >>>> >>>> Does that have ED25519 support? >>> No. You'd need 1.1.1 for that, it is currently in beta. >>> >> No wonder Dr. Google failed me. I will have to see what I can do. >> Perhaps put together a Rawhide system then try for a build. But >> that >> takes for a time commitment. >> > Please note that there is now openssl-1.1.1-pre8 in Rawhide since > yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final > release so we will not ship an openssl prerelease in it. > Does this include the armv7hl image?? If so, it is not a stretch for me to build an image on one of my test Cubieboards. From rsalz at akamai.com Thu Jul 26 15:26:20 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 26 Jul 2018 15:26:20 +0000 Subject: [openssl-users] EDDSA support yet? In-Reply-To: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> References: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> Message-ID: <0FD00FA8-BAB7-4717-810A-32CA112A33E6@akamai.com> No, you need a 1.1.1 tree. From tmraz at redhat.com Thu Jul 26 15:59:50 2018 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 26 Jul 2018 17:59:50 +0200 Subject: [openssl-users] EDDSA support yet? In-Reply-To: <578ea627-93fa-3cc4-f404-ec44fdd5e177@htt-consult.com> References: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> <1532614746.13685.4.camel@redhat.com> <578ea627-93fa-3cc4-f404-ec44fdd5e177@htt-consult.com> Message-ID: <1532620790.13685.7.camel@redhat.com> On Thu, 2018-07-26 at 10:33 -0400, Robert Moskowitz wrote: > > On 07/26/2018 10:19 AM, Tomas Mraz wrote: > > On Thu, 2018-07-26 at 10:10 -0400, Robert Moskowitz wrote: > > > On 07/26/2018 10:07 AM, Viktor Dukhovni wrote: > > > > > On Jul 26, 2018, at 9:01 AM, Robert Moskowitz > > > > t.co > > > > > m> wrote: > > > > > > > > > > My Fedora 28 shipped with: > > > > > > > > > > OpenSSL 1.1.0h-fips 27 Mar 2018 > > > > > > > > > > Does that have ED25519 support? > > > > > > > > No. You'd need 1.1.1 for that, it is currently in beta. > > > > > > > > > > No wonder Dr. Google failed me. I will have to see what I can > > > do. > > > Perhaps put together a Rawhide system then try for a build. But > > > that > > > takes for a time commitment. > > > > > > > Please note that there is now openssl-1.1.1-pre8 in Rawhide since > > yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final > > release so we will not ship an openssl prerelease in it. > > > > Does this include the armv7hl image? If so, it is not a stretch for > me > to build an image on one of my test Cubieboards. Fedora does builds for armv7hl. However I do not see any sufficiently fresh Rawhide image that would contain this build. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From bbrumley at gmail.com Thu Jul 26 17:17:01 2018 From: bbrumley at gmail.com (Billy Brumley) Date: Thu, 26 Jul 2018 20:17:01 +0300 Subject: [openssl-users] EDDSA support yet? In-Reply-To: <1532620790.13685.7.camel@redhat.com> References: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> <1532614746.13685.4.camel@redhat.com> <578ea627-93fa-3cc4-f404-ec44fdd5e177@htt-consult.com> <1532620790.13685.7.camel@redhat.com> Message-ID: Shameless self plug -- OpenSSL engine for 1.0.2, 1.1.0, and later: https://github.com/romen/libsuola BBB On Thu, Jul 26, 2018 at 6:59 PM, Tomas Mraz wrote: > On Thu, 2018-07-26 at 10:33 -0400, Robert Moskowitz wrote: >> >> On 07/26/2018 10:19 AM, Tomas Mraz wrote: >> > On Thu, 2018-07-26 at 10:10 -0400, Robert Moskowitz wrote: >> > > On 07/26/2018 10:07 AM, Viktor Dukhovni wrote: >> > > > > On Jul 26, 2018, at 9:01 AM, Robert Moskowitz > > > > > t.co >> > > > > m> wrote: >> > > > > >> > > > > My Fedora 28 shipped with: >> > > > > >> > > > > OpenSSL 1.1.0h-fips 27 Mar 2018 >> > > > > >> > > > > Does that have ED25519 support? >> > > > >> > > > No. You'd need 1.1.1 for that, it is currently in beta. >> > > > >> > > >> > > No wonder Dr. Google failed me. I will have to see what I can >> > > do. >> > > Perhaps put together a Rawhide system then try for a build. But >> > > that >> > > takes for a time commitment. >> > > >> > >> > Please note that there is now openssl-1.1.1-pre8 in Rawhide since >> > yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final >> > release so we will not ship an openssl prerelease in it. >> > >> >> Does this include the armv7hl image? If so, it is not a stretch for >> me >> to build an image on one of my test Cubieboards. > > Fedora does builds for armv7hl. However I do not see any sufficiently > fresh Rawhide image that would contain this build. > > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From sudarshan12s at gmail.com Thu Jul 26 18:00:01 2018 From: sudarshan12s at gmail.com (pavan) Date: Thu, 26 Jul 2018 11:00:01 -0700 (MST) Subject: [openssl-users] conversion of RAND_bytes to rand in fips apporved way In-Reply-To: References: Message-ID: <1532628001305-0.post@n7.nabble.com> Thanks very much for valuable suggestions. Few applciations like RADIUS/TACACS+/snmp protocol (IV generation for AES) are using rand functions. As they are related to security, i am changing the rand function used by them. >>>> and as long as the 15 least-significant bits of the output of >>>> RAND_bytes are unbiased the above input might cause FIPS compliance issues as RAND_bytes doesnt guarantee the biasing after we truncate one bit. I shall check this once. Regards, -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From rgm at htt-consult.com Thu Jul 26 18:08:02 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 26 Jul 2018 14:08:02 -0400 Subject: [openssl-users] EDDSA support yet? In-Reply-To: <1532620790.13685.7.camel@redhat.com> References: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> <1532614746.13685.4.camel@redhat.com> <578ea627-93fa-3cc4-f404-ec44fdd5e177@htt-consult.com> <1532620790.13685.7.camel@redhat.com> Message-ID: <57bfa4c7-f8df-3e73-b90c-c7bdf8d59598@htt-consult.com> On 07/26/2018 11:59 AM, Tomas Mraz wrote: > On Thu, 2018-07-26 at 10:33 -0400, Robert Moskowitz wrote: >> On 07/26/2018 10:19 AM, Tomas Mraz wrote: >>> On Thu, 2018-07-26 at 10:10 -0400, Robert Moskowitz wrote: >>>> On 07/26/2018 10:07 AM, Viktor Dukhovni wrote: >>>>>> On Jul 26, 2018, at 9:01 AM, Robert Moskowitz >>>>> t.co >>>>>> m> wrote: >>>>>> >>>>>> My Fedora 28 shipped with: >>>>>> >>>>>> OpenSSL 1.1.0h-fips 27 Mar 2018 >>>>>> >>>>>> Does that have ED25519 support? >>>>> No. You'd need 1.1.1 for that, it is currently in beta. >>>>> >>>> No wonder Dr. Google failed me. I will have to see what I can >>>> do. >>>> Perhaps put together a Rawhide system then try for a build. But >>>> that >>>> takes for a time commitment. >>>> >>> Please note that there is now openssl-1.1.1-pre8 in Rawhide since >>> yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final >>> release so we will not ship an openssl prerelease in it. >>> >> Does this include the armv7hl image? If so, it is not a stretch for >> me >> to build an image on one of my test Cubieboards. > Fedora does builds for armv7hl. However I do not see any sufficiently > fresh Rawhide image that would contain this build. > From the Fedora-arm list: openssl-1.1.1-0.pre8.fc29 was built and tagged into f29 late yesterday so it will be in the next successful compose which might be tomorrow (there's been a few issues), look for the next rawhide report to the mailing list, else you can just "dnf upgrade" your current f29 image and you'll get it once it makes the mirrors. So if is off to power up a cubieboard and get ready to build an image for testing. From mrhines at digitalocean.com Thu Jul 26 20:48:34 2018 From: mrhines at digitalocean.com (Michael R. Hines) Date: Thu, 26 Jul 2018 15:48:34 -0500 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities Message-ID: Good afternoon, Our team is trying to get an accurate understanding of whether or not cryptographic libraries are vulnerable to the kind of non-constant-time attack used by exploits such as the one recently documented here: https://www.vusec.net/wp-content/uploads/2018/07/tlbleed-author-preprint.pdf Unfortunately, Intel has not provided much guidance in this area but has indicated that software mitigation can and should be implemented by libraries like OpenSSL. We're also not currently aware of any open CVEs or embargos active for this particular side-channel attack. Any help or guidance would be appreciated. Can the openssl community comment on this? Thanks! -- /* * Michael R. Hines * Staff Engineer, DigitalOcean. */ From coolbugcheckers at gmail.com Thu Jul 26 23:24:12 2018 From: coolbugcheckers at gmail.com (Bug Checkers) Date: Thu, 26 Jul 2018 19:24:12 -0400 Subject: [openssl-users] Need a check? Message-ID: Hi, I have seen message_len has checked here: https://github.com/openssl/openssl/blob/master/crypto/ec/cur ve448/eddsa.c#L164 (message_len > 0 && !EVP_DigestUpdate(hashctx, message, message_len) But it has not checked here: https://github.com/openssl/openssl/blob/master/crypto/ec/cur ve448/eddsa.c#L275 !EVP_DigestUpdate(hashctx, message, message_len) Is there anything missing? Thanks! Mansour -------------- next part -------------- An HTML attachment was scrubbed... URL: From lobl.pavel at gmail.com Fri Jul 27 09:59:22 2018 From: lobl.pavel at gmail.com (=?UTF-8?Q?Pavel_L=C3=B6bl?=) Date: Fri, 27 Jul 2018 11:59:22 +0200 Subject: [openssl-users] pkcs11 engine private key loading Message-ID: I've already post this to opensc mailing list but I'm not really sure where the problem is. So I also try my luck here. I'm writing application which decrypts SMIME messages using smart card. I used source code of openssl cms command as reference. I'm able to decrypt already however I face the following problem. When smart card is removed while my application is running ENGINE_load_private_key still returns private key reference without any problem but later call to CMS_decrypt fails. Similarly when smart card is not present during first call to ENGINE_load_private_key it will continue to fail even after card is inserted again. I've tried to call ENGINE_init before key loading and ENGINE_finish and ENGINE_free after that but it didn't help. Only workaround I've found is exit the process and start it again. I would expect ENGINE_load_private_key to unlock the card if it is present and is not unlocked already and fail if there is no card inserted. I'm not sure what is going on here. Maybe I just got the concept wrong. I'm using debian testing with opensc 0.18.0-3 and openssl 1.1.0h-4. From rgm at htt-consult.com Fri Jul 27 13:04:55 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 27 Jul 2018 09:04:55 -0400 Subject: [openssl-users] EDDSA support yet? In-Reply-To: <1532620790.13685.7.camel@redhat.com> References: <21d83108-51fb-2d44-43b0-dce68ddaca74@htt-consult.com> <1532614746.13685.4.camel@redhat.com> <578ea627-93fa-3cc4-f404-ec44fdd5e177@htt-consult.com> <1532620790.13685.7.camel@redhat.com> Message-ID: <9005e2de-7e29-2b6d-ef02-a3deccefe839@htt-consult.com> On 07/26/2018 11:59 AM, Tomas Mraz wrote: > On Thu, 2018-07-26 at 10:33 -0400, Robert Moskowitz wrote: >> On 07/26/2018 10:19 AM, Tomas Mraz wrote: >>> On Thu, 2018-07-26 at 10:10 -0400, Robert Moskowitz wrote: >>>> On 07/26/2018 10:07 AM, Viktor Dukhovni wrote: >>>>>> On Jul 26, 2018, at 9:01 AM, Robert Moskowitz >>>>> t.co >>>>>> m> wrote: >>>>>> >>>>>> My Fedora 28 shipped with: >>>>>> >>>>>> OpenSSL 1.1.0h-fips 27 Mar 2018 >>>>>> >>>>>> Does that have ED25519 support? >>>>> No. You'd need 1.1.1 for that, it is currently in beta. >>>>> >>>> No wonder Dr. Google failed me. I will have to see what I can >>>> do. >>>> Perhaps put together a Rawhide system then try for a build. But >>>> that >>>> takes for a time commitment. >>>> >>> Please note that there is now openssl-1.1.1-pre8 in Rawhide since >>> yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final >>> release so we will not ship an openssl prerelease in it. >>> >> Does this include the armv7hl image? If so, it is not a stretch for >> me >> to build an image on one of my test Cubieboards. > Fedora does builds for armv7hl. However I do not see any sufficiently > fresh Rawhide image that would contain this build. > With:? Fedora-Xfce-armhfp-Rawhide-20180726.n.2-sda.raw.xz # openssl version OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018 So now let's see how making an ED25519 PKI works. From Michael.Wojcik at microfocus.com Fri Jul 27 13:35:55 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 27 Jul 2018 13:35:55 +0000 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Michael R. Hines via openssl-users > Sent: Thursday, July 26, 2018 14:49 > > Our team is trying to get an accurate understanding of whether or not > cryptographic libraries are vulnerable to the kind of non-constant-time > attack used by exploits such as the one recently documented here: > https://www.vusec.net/wp-content/uploads/2018/07/tlbleed-author- > preprint.pdf That's easy: Yes. The attack in the published paper is against a cryptographic library (libgcrypt), so at least one cryptographic library is vulnerable. More generally, TLBleed is not a software vulnerability, and as far as I'm aware no practical software mitigations have been shown for it. Therefore cryptographic libraries, like all other software, are vulnerable. The TLBleed authors note that their specific attack can be prevented by disabling hyperthreading (a system configuration mitigation), or by aggressively partitioning the target process address space (which would require massive code changes and would probably not be feasible for libraries, or for most applications). Beyond that we have only the usual mitigating factors: the attacker must be local and the attack requires substantial effort. (I'm only commenting on TLBleed here because I'm not sure what you mean by "non-constant-time attack". TLBleed isn't a timing side channel, so what does constant time have to do with the question?) > Unfortunately, Intel has not provided much guidance in this area but has > indicated that software mitigation can and should be implemented by > libraries like OpenSSL. Intel is spreading FUD, because they know perfectly well that microarchitecture side channel vulnerabilities are a big PR problem. So they're doing whatever they can to minimize the issue. AMD similarly are pretending that just because no one's demonstrated a TLB side channel on their processors, that they don't have to worry about the possibilities. > We're also not currently aware of any open CVEs > or embargos active for this particular side-channel attack. Well, no, because the manufacturers are claiming there is no problem, or if there is that it's someone else's. More importantly, as the TLBleed authors, and the authors of the original Spectre paper, and many other researchers have pointed out, microarchitecture side channels are a large class of vulnerabilities. Spot defenses against particular variants rarely help protect against other variants. Microarchitecture side channel attacks will be with us for a long time. -- Michael Wojcik Distinguished Engineer, Micro Focus From rgm at htt-consult.com Fri Jul 27 13:44:11 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 27 Jul 2018 09:44:11 -0400 Subject: [openssl-users] genpkey for ed25519 Message-ID: Here we go again with figuring out what to put in the command lines.? Dr. Google is not giving up enough answers. For ecdsa I started with: openssl genpkey -aes256 -algorithm ec\ ?-pkeyopt ec_paramgen_curve:prime256v1\ ?-outform pem -pkeyopt ec_param_enc:named_curve\ ?-out $dir/private/ca.key.pem I found one reference that I should use -algorithm ed25519 (though the example used caps: ED25519) But I have not found recommendation for ec_parmgen_curve or ec_param_enc Can someone point me to the information on values for these (and I suspect I will be hitting others as I go). thanks From mrhines at digitalocean.com Fri Jul 27 13:48:25 2018 From: mrhines at digitalocean.com (Michael R. Hines) Date: Fri, 27 Jul 2018 08:48:25 -0500 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities In-Reply-To: References: Message-ID: <6aa4e956-6d0e-caab-560d-bf89ee9d0cf7@digitalocean.com> On 07/27/2018 08:35 AM, Michael Wojcik wrote: >> Our team is trying to get an accurate understanding of whether or not >> cryptographic libraries are vulnerable to the kind of non-constant-time >> attack used by exploits such as the one recently documented here: >> https://www.vusec.net/wp-content/uploads/2018/07/tlbleed-author- >> preprint.pdf > That's easy: Yes. The attack in the published paper is against a cryptographic library (libgcrypt), so at least one cryptographic library is vulnerable. > > More generally, TLBleed is not a software vulnerability, and as far as I'm aware no practical software mitigations have been shown for it. Therefore cryptographic libraries, like all other software, are vulnerable. > > The TLBleed authors note that their specific attack can be prevented by disabling hyperthreading (a system configuration mitigation), or by aggressively partitioning the target process address space (which would require massive code changes and would probably not be feasible for libraries, or for most applications). Beyond that we have only the usual mitigating factors: the attacker must be local and the attack requires substantial effort. > > (I'm only commenting on TLBleed here because I'm not sure what you mean by "non-constant-time attack". TLBleed isn't a timing side channel, so what does constant time have to do with the question?) Hi Michael. Thanks for your response! The paper is in fact based on a timing attack. Both Intel (and a nice blog from Redhat) confirm this; In fact that's the only way this particular vulnerability works. It leaks bits by observing the branch path of the code referencing each bit while processing a private key based on the time it takes to hit/miss a lookup in the TLB. If the cryptographic implementation is constant-time, then the bits are not discoverable and the attack is then unavailable. We're trying to decide if we can avoid disabling hyperthreading, as our measurements show that the performance losses (even with integer workloads) are significant. Might anyone be able to comment on this particular type of attack in OpenSSL? - Michael From tmraz at redhat.com Fri Jul 27 14:04:41 2018 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 27 Jul 2018 16:04:41 +0200 Subject: [openssl-users] genpkey for ed25519 In-Reply-To: References: Message-ID: <1532700281.13685.8.camel@redhat.com> On Fri, 2018-07-27 at 09:44 -0400, Robert Moskowitz wrote: > Here we go again with figuring out what to put in the command > lines. > Dr. Google is not giving up enough answers. > > For ecdsa I started with: > > openssl genpkey -aes256 -algorithm ec\ > -pkeyopt ec_paramgen_curve:prime256v1\ > -outform pem -pkeyopt ec_param_enc:named_curve\ > -out $dir/private/ca.key.pem > > I found one reference that I should use -algorithm ed25519 (though > the > example used caps: ED25519) Yes, it is case insensitive. > But I have not found recommendation for ec_parmgen_curve or > ec_param_enc > > Can someone point me to the information on values for these (and I > suspect I will be hitting others as I go). Just do not use these options. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From Michael.Wojcik at microfocus.com Fri Jul 27 14:12:46 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 27 Jul 2018 14:12:46 +0000 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities In-Reply-To: <6aa4e956-6d0e-caab-560d-bf89ee9d0cf7@digitalocean.com> References: <6aa4e956-6d0e-caab-560d-bf89ee9d0cf7@digitalocean.com> Message-ID: > From: Michael R. Hines [mailto:mrhines at digitalocean.com] > Sent: Friday, July 27, 2018 07:48 > > > On 07/27/2018 08:35 AM, Michael Wojcik wrote: > > > > (I'm only commenting on TLBleed here because I'm not sure what you > > mean by "non-constant-time attack". TLBleed isn't a timing side channel, so > > what does constant time have to do with the question?) > > The paper is in fact based on a timing attack. Both Intel (and a nice > blog from Redhat) confirm this; In fact that's the only way this > particular vulnerability works. It leaks bits by observing the branch > path of the code referencing each bit while processing a private key > based on the time it takes to hit/miss a lookup in the TLB. Oh, yes, of course you're correct. Sorry - that's what I get for responding early in the morning. > If the > cryptographic implementation is constant-time, then the bits are not > discoverable and the attack is then unavailable. Hmm. I suppose this is true, but it's not the usual sense of "constant time" when referring to cryptographic implementations - that is, it's not constant-time explicit operations (arithmetic, etc) but constant-time memory access, which requires the implementation to predict which pages it will touch, and to know something about the TLB algorithm used by the particular CPU it's running on. I think that goes back to the TLBleed authors' mention of partitioning the target process virtual address space. For a library, that would be difficult, since it receives the key at an arbitrary address from the application. > We're trying to decide if we can avoid disabling hyperthreading, as our > measurements show that the performance losses (even with integer > workloads) are significant. > > Might anyone be able to comment on this particular type of attack in > OpenSSL? Certainly I'd need to do a lot more research before I'd feel comfortable speculating about possible mitigations within OpenSSL. I'll be interested to see if anyone else does. -- Michael Wojcik Distinguished Engineer, Micro Focus From mrhines at digitalocean.com Fri Jul 27 14:20:30 2018 From: mrhines at digitalocean.com (Michael R. Hines) Date: Fri, 27 Jul 2018 09:20:30 -0500 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities In-Reply-To: References: <6aa4e956-6d0e-caab-560d-bf89ee9d0cf7@digitalocean.com> Message-ID: On 07/27/2018 09:12 AM, Michael Wojcik wrote: > >> We're trying to decide if we can avoid disabling hyperthreading, as our >> measurements show that the performance losses (even with integer >> workloads) are significant. >> >> Might anyone be able to comment on this particular type of attack in >> OpenSSL? > Certainly I'd need to do a lot more research before I'd feel comfortable speculating about possible mitigations within OpenSSL. I'll be interested to see if anyone else does. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus Any and all guidance would be appreciated! Again, thank you so much for the response. We're having a very difficult time finding a response (of any kind) from the crypto community or from the linux distributions as well. - Michael From rgm at htt-consult.com Fri Jul 27 14:36:47 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 27 Jul 2018 10:36:47 -0400 Subject: [openssl-users] ed25519 self-signed root cert Message-ID: <1783ee2d-7158-8ac9-35b7-3146da862fdc@htt-consult.com> genpkey worked without those options.? I am going to have to look at the RFC again, as there are different types of ed25519 certs, but how will that work out in openssl?? I will have to remember back to a conversation at had at IETF 100... Anyway error on the next step: # openssl req -config $dir/openssl-root.cnf\ >????? -set_serial 0x$(openssl rand -hex $sn)\ >????? -keyform pem -outform pem\ >????? -key $dir/private/ca.key.pem -subj "$DN"\ >????? -new -x509 -days 7300 -extensions v3_ca\ >????? -out $dir/certs/ca.cert.pem Enter pass phrase for /root/ca/private/ca.key.pem: 3064983568:error:1010F08A:elliptic curve routines:pkey_ecd_ctrl:invalid digest type:crypto/ec/ecx_meth.c:801: where dir=/root/ca From openssl-users at dukhovni.org Fri Jul 27 14:43:37 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Jul 2018 10:43:37 -0400 Subject: [openssl-users] ed25519 self-signed root cert In-Reply-To: <1783ee2d-7158-8ac9-35b7-3146da862fdc@htt-consult.com> References: <1783ee2d-7158-8ac9-35b7-3146da862fdc@htt-consult.com> Message-ID: > On Jul 27, 2018, at 10:36 AM, Robert Moskowitz wrote: > > nyway error on the next step: > > # openssl req -config $dir/openssl-root.cnf\ > > -set_serial 0x$(openssl rand -hex $sn)\ > > -keyform pem -outform pem\ > > -key $dir/private/ca.key.pem -subj "$DN"\ > > -new -x509 -days 7300 -extensions v3_ca\ > > -out $dir/certs/ca.cert.pem > Enter pass phrase for /root/ca/private/ca.key.pem: > 3064983568:error:1010F08A:elliptic curve routines:pkey_ecd_ctrl:invalid digest type:crypto/ec/ecx_meth.c:801: Do you have a "default_md" in your configuration file? Ed25519 and Ed448 sign the raw data, not a digest thereof. It might be more use-friendly to figure out a way to ignore the requested digest rather than throw an error... -- -- Viktor. From rgm at htt-consult.com Fri Jul 27 14:56:59 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 27 Jul 2018 10:56:59 -0400 Subject: [openssl-users] ed25519 self-signed root cert In-Reply-To: References: <1783ee2d-7158-8ac9-35b7-3146da862fdc@htt-consult.com> Message-ID: <0c2c3b0e-b1e5-0bfd-3674-964afabae4e1@htt-consult.com> On 07/27/2018 10:43 AM, Viktor Dukhovni wrote: > >> On Jul 27, 2018, at 10:36 AM, Robert Moskowitz wrote: >> >> nyway error on the next step: >> >> # openssl req -config $dir/openssl-root.cnf\ >>> -set_serial 0x$(openssl rand -hex $sn)\ >>> -keyform pem -outform pem\ >>> -key $dir/private/ca.key.pem -subj "$DN"\ >>> -new -x509 -days 7300 -extensions v3_ca\ >>> -out $dir/certs/ca.cert.pem >> Enter pass phrase for /root/ca/private/ca.key.pem: >> 3064983568:error:1010F08A:elliptic curve routines:pkey_ecd_ctrl:invalid digest type:crypto/ec/ecx_meth.c:801: > Do you have a "default_md" in your configuration file? > Ed25519 and Ed448 sign the raw data, not a digest thereof. > > It might be more use-friendly to figure out a way to ignore > the requested digest rather than throw an error... > Ouch.? That is bad.? Since ed25519 does not use md, it should not error out on this at all.? Makes it especially challenging for a cnf file to have multiple uses.? I commented out default_md and it worked.? Dumping it shows: # openssl x509 -inform pem -in $dir/certs/ca.cert.pem\ >???????? -text -noout Certificate: ??? Data: ??????? Version: 3 (0x2) ??????? Serial Number: ??????????? 49:b3:1f:0f:cf:8a:9a:d9 ??????? Signature Algorithm: ED25519 ??????? Issuer: C = US, ST = MI, L = Oak Park, O = HTT Consulting, CN = Root CA ??????? Validity ??????????? Not Before: Jul 27 14:49:02 2018 GMT ??????????? Not After : Jul 22 14:49:02 2038 GMT ??????? Subject: C = US, ST = MI, L = Oak Park, O = HTT Consulting, CN = Root CA ??????? Subject Public Key Info: ??????????? Public Key Algorithm: ED25519 ??????????????? ED25519 Public-Key: ??????????????? pub: ??????????????????? ea:c7:3a:3c:80:49:ce:c9:a6:eb:a4:01:0a:11:df: ??????????????????? 62:58:27:e0:af:77:5c:3e:fd:73:08:24:f8:e4:b1: ??????????????????? 45:0c ??????? X509v3 extensions: ??????????? X509v3 Subject Key Identifier: D6:1B:BA:96:44:EF:F1:07:59:35:A7:F2:77:5F:82:24:21:53:9A:9F ??????????? X509v3 Authority Key Identifier: keyid:D6:1B:BA:96:44:EF:F1:07:59:35:A7:F2:77:5F:82:24:21:53:9A:9F ??????????? X509v3 Basic Constraints: critical ??????????????? CA:TRUE ??????????? X509v3 Key Usage: critical ??????????????? Certificate Sign, CRL Sign ??????????? X509v3 Subject Alternative Name: ??????????????? email:postmaster at htt-consult.com ??? Signature Algorithm: ED25519 ???????? 93:f9:f9:c2:a6:e7:ca:8f:5c:82:4b:fa:7f:a8:0f:4c:e2:46: ???????? 52:f3:99:d0:ad:f0:2c:2b:b4:f3:90:26:27:8f:36:2b:ed:cf: ???????? 58:c5:f4:28:78:ec:59:53:13:ac:96:32:fa:07:ac:b6:d8:eb: ???????? 78:2c:da:19:95:6e:ed:36:bb:09 So on to the next step. From rgm at htt-consult.com Fri Jul 27 15:25:25 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 27 Jul 2018 11:25:25 -0400 Subject: [openssl-users] Intermediate cert file failure Message-ID: on a default_md error: ?? openssl req -config $cadir/openssl-root.cnf\ ?????? -key $dir/private/intermediate.key.$format \ ?????? -keyform $format -outform $format -subj "$DN" -new\ ?????? -out $dir/csr/intermediate.csr.$format format=pem ?? openssl rand -hex $sn > $dir/serial # hex 8 is minimum, 19 is maximum ?? openssl ca -config $cadir/openssl-root.cnf -days 3650\ ?????? -extensions v3_intermediate_ca -notext\ ?????? -in $dir/csr/intermediate.csr.$format\ ?????? -out $dir/certs/intermediate.cert.pem Using configuration from /root/ca/openssl-root.cnf Enter pass phrase for /root/ca/private/ca.key.pem: Can't open /root/ca/intermediate/index.txt.attr for reading, No such file or directory 3064446992:error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:72:fopen('/root/ca/intermediate/index.txt.attr','r') 3064446992:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:79: variable lookup failed for CA_default::default_md 3064446992:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md Why is it asking for index.txt.attr?? I made serial which at least with ecdsa overrode using index.txt? And then default_md is commented out in both my .cnf files. From openssl-users at dukhovni.org Fri Jul 27 16:35:24 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Jul 2018 12:35:24 -0400 Subject: [openssl-users] Intermediate cert file failure In-Reply-To: References: Message-ID: > On Jul 27, 2018, at 11:25 AM, Robert Moskowitz wrote: > > 3064446992:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:79: > variable lookup failed for CA_default::default_md > 3064446992:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md Well ca(1) wants either an explicit "md" option or a default_md. Perhaps it does not yet support ed25519. You can sign directly with "openssl x509", but first try openssl ca -md null or openssl ca -md default and see if either of those work. -- Viktor. -- Viktor. From rgm at htt-consult.com Fri Jul 27 16:49:10 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 27 Jul 2018 12:49:10 -0400 Subject: [openssl-users] Intermediate cert file failure In-Reply-To: References: Message-ID: On 07/27/2018 12:35 PM, Viktor Dukhovni wrote: > >> On Jul 27, 2018, at 11:25 AM, Robert Moskowitz wrote: >> >> 3064446992:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:79: >> variable lookup failed for CA_default::default_md >> 3064446992:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md > Well ca(1) wants either an explicit "md" option or a default_md. > Perhaps it does not yet support ed25519. You can sign directly > with "openssl x509", but first try > > openssl ca -md null > or > openssl ca -md default > > and see if either of those work. > -md null worked: ?? openssl ca -config $cadir/openssl-root.cnf -days 3650\ ?????? -extensions v3_intermediate_ca -notext -md null\ ?????? -in $dir/csr/intermediate.csr.$format\ ?????? -out $dir/certs/intermediate.cert.pem Can't open /root/ca/intermediate/index.txt.attr for reading, No such file or directory 3064946704:error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:72:fopen('/root/ca/intermediate/index.txt.attr','r') 3064946704:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:79: Check that the request matches the signature Signature ok Certificate Details: ??????? Serial Number: ??????????? ad:0f:52:5d:91:70:1a:d3 ??????? Validity ??????????? Not Before: Jul 27 16:41:03 2018 GMT ??????????? Not After : Jul 24 16:41:03 2028 GMT ??????? Subject: ??????????? countryName?????????????? = US ??????????? stateOrProvinceName?????? = MI ??????????? organizationName????????? = HTT Consulting ??????????? commonName??????????????? = Signing CA ??????? X509v3 extensions: ??????????? X509v3 Subject Key Identifier: DB:5F:0C:00:54:DD:A6:EB:61:BD:79:13:0A:2D:EA:0A:19:82:E8:C5 ??????????? X509v3 Authority Key Identifier: keyid:D6:1B:BA:96:44:EF:F1:07:59:35:A7:F2:77:5F:82:24:21:53:9A:9F ??????????? X509v3 Basic Constraints: critical ??????????????? CA:TRUE, pathlen:0 ??????????? X509v3 Key Usage: critical ??????????????? Certificate Sign, CRL Sign ??????????? X509v3 Subject Alternative Name: ??????????????? email:postmaster at htt-consult.com Certificate is to be certified until Jul 24 16:41:03 2028 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated There was no file index.txt.attr, but now there is: # cat index.txt.attr unique_subject = yes I don't remember this from my ecdsa work with 1.1.0 This issue with md is definitely and issue.? I can try -md null on the self-signed root cert, but it seems that this should not even be referenced for ed25519 But I got my intermediate cert, so on to the next step. thanks for your help, Viktor. From rgm at htt-consult.com Fri Jul 27 17:07:20 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 27 Jul 2018 13:07:20 -0400 Subject: [openssl-users] Errors on EndEntity cert generation Message-ID: <79451cee-d8eb-3e8b-c9ce-0e89ac0448c3@htt-consult.com> The hits just keep on coming.? Made my cert req, ?? openssl req -config $dir/openssl-intermediate.cnf\ ?????? -key $dir/private/$serverfqdn.key.$format \ ?????? -subj "$DN" -new -out $dir/csr/$serverfqdn.csr.$format DN='/C=US/ST=MI/L=Oak Park/O=HTT Consulting' then tried to make the cert with: ?? openssl ca -config $dir/openssl-intermediate.cnf -days 375\ ?????? -extensions server_cert -notext -md null \ ?????? -in $dir/csr/$serverfqdn.csr.$format\ ?????? -out $dir/certs/$serverfqdn.cert.$format (note use of -md null and nothing got the earlier error) Using configuration from /root/ca/intermediate/openssl-intermediate.cnf Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem: Error Loading extension section server_cert 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=rand_serial 3065065488:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid null name:crypto/x509v3/v3_utl.c:360: 3065065488:error:22097069:X509 V3 routines:do_ext_nconf:invalid extension string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section= 3065065488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value= Please help me with these latest errors. Thanks From openssl-users at dukhovni.org Fri Jul 27 17:14:12 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Jul 2018 13:14:12 -0400 Subject: [openssl-users] Errors on EndEntity cert generation In-Reply-To: <79451cee-d8eb-3e8b-c9ce-0e89ac0448c3@htt-consult.com> References: <79451cee-d8eb-3e8b-c9ce-0e89ac0448c3@htt-consult.com> Message-ID: > On Jul 27, 2018, at 1:07 PM, Robert Moskowitz wrote: > > Error Loading extension section server_cert > 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn > 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=rand_serial > 3065065488:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid null name:crypto/x509v3/v3_utl.c:360: > 3065065488:error:22097069:X509 V3 routines:do_ext_nconf:invalid extension string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section= > 3065065488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value= > > Please help me with these latest errors. Start with a less exotic ".cnf" file. These are all configuration errors, unrelated to ed25519. Get a working RSA config file, and then switch algorithms. -- Viktor. From rgm at htt-consult.com Fri Jul 27 17:20:29 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 27 Jul 2018 13:20:29 -0400 Subject: [openssl-users] Errors on EndEntity cert generation In-Reply-To: References: <79451cee-d8eb-3e8b-c9ce-0e89ac0448c3@htt-consult.com> Message-ID: <803bbbaa-b0e9-c072-5bb3-02a4dbf5294a@htt-consult.com> On 07/27/2018 01:14 PM, Viktor Dukhovni wrote: > >> On Jul 27, 2018, at 1:07 PM, Robert Moskowitz wrote: >> >> Error Loading extension section server_cert >> 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn >> 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=rand_serial >> 3065065488:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid null name:crypto/x509v3/v3_utl.c:360: >> 3065065488:error:22097069:X509 V3 routines:do_ext_nconf:invalid extension string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section= >> 3065065488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value= >> >> Please help me with these latest errors. > Start with a less exotic ".cnf" file. These are all configuration errors, > unrelated to ed25519. Get a working RSA config file, and then switch > algorithms. > I am using a working ecdsa config file (the one in my draft-moskowitz-ecdsa-pki): # OpenSSL intermediate CA configuration file. # Copy to `$dir/intermediate/openssl-intermediate.cnf`. [ ca ] # `man ca` default_ca = CA_default [ CA_default ] # Directory and file locations. dir= $ENV::dir cadir = $ENV::cadir format= $ENV::format certs = $dir/certs crl_dir? = $dir/crl new_certs_dir? = $dir/newcerts database = $dir/index.txt serial= $dir/serial RANDFILE = $dir/private/.rand # The Intermediate key and Intermediate certificate. private_key = $dir/private/intermediate.key.$format certificate = $dir/certs/intermediate.cert.$format # For certificate revocation lists. crlnumber= $dir/crlnumber crl= $dir/crl/intermediate.crl.pem crl_extensions = crl_ext default_crl_days? = $ENV::default_crl_days # SHA-1 is deprecated, so use SHA-2 instead. # default_md? = sha256 name_opt = ca_default cert_opt = ca_default default_days= 375 preserve = no policy= policy_loose copy_extensions= copy [ policy_strict ] # The root CA should only sign intermediate certificates that match. # See the POLICY FORMAT section of `man ca`. countryName = match stateOrProvinceName? = match organizationName? = match organizationalUnitName? = optional commonName? = optional [ policy_loose ] # Allow the intermediate CA to sign a more #? diverse range of certificates. # See the POLICY FORMAT section of the `ca` man page. countryName = optional stateOrProvinceName? = optional localityName= optional organizationName? = optional organizationalUnitName? = optional commonName? = optional UID= optional [ req ] # Options for the `req` tool (`man req`). default_bits? = 2048 distinguished_name? = req_distinguished_name string_mask= utf8only req_extensions= req_ext # SHA-1 is deprecated, so use SHA-2 instead. # default_md = sha256 # Extension to add when the -x509 option is used. x509_extensions? = v3_ca [ req_distinguished_name ] # See . countryName= Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName? = Locality Name 0.organizationName? = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name UID? = User ID # Optionally, specify some defaults. # countryName_default = US # stateOrProvinceName_default? = MI # localityName_default= Oak Park # 0.organizationName_default= HTT Consulting # organizationalUnitName_default? = [ req_ext ] subjectAltName = $ENV::subjectAltName [ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true # keyUsage = critical, digitalSignature, cRLSign, keyCertSign keyUsage = critical, cRLSign, keyCertSign [ v3_intermediate_ca ] # Extensions for a typical intermediate CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 # keyUsage = critical, digitalSignature, cRLSign, keyCertSign keyUsage = critical, cRLSign, keyCertSign [ usr_cert ] # Extensions for client certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = client, email nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical,nonRepudiation,digitalSignature,keyEncipherment extendedKeyUsage = clientAuth, emailProtection crlDistributionPoints = $ENV::crlDP authorityInfoAccess = $ENV::ocspIAI [ server_cert ] # Extensions for server certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth crlDistributionPoints = $ENV::crlDP authorityInfoAccess = $ENV::ocspIAI [ crl_ext ] # Extension for CRLs (`man x509v3_config`). authorityKeyIdentifier=keyid:always [ ocsp ] # Extension for OCSP signing certificates (`man ocsp`). basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning From openssl-users at dukhovni.org Fri Jul 27 17:26:26 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Jul 2018 13:26:26 -0400 Subject: [openssl-users] Errors on EndEntity cert generation In-Reply-To: <803bbbaa-b0e9-c072-5bb3-02a4dbf5294a@htt-consult.com> References: <79451cee-d8eb-3e8b-c9ce-0e89ac0448c3@htt-consult.com> <803bbbaa-b0e9-c072-5bb3-02a4dbf5294a@htt-consult.com> Message-ID: On Jul 27, 2018, at 1:20 PM, Robert Moskowitz wrote: > > On 07/27/2018 01:14 PM, Viktor Dukhovni wrote: >> >>> On Jul 27, 2018, at 1:07 PM, Robert Moskowitz wrote: >>> >>> Error Loading extension section server_cert >>> 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn >>> 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=rand_serial >>> 3065065488:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid null name:crypto/x509v3/v3_utl.c:360: >>> 3065065488:error:22097069:X509 V3 routines:do_ext_nconf:invalid extension string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section= >>> 3065065488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value= >>> >>> Please help me with these latest errors. >> Start with a less exotic ".cnf" file. These are all configuration errors, >> unrelated to ed25519. Get a working RSA config file, and then switch >> algorithms. >> > I am using a working ecdsa config file It is a good idea to read that file and match the error messages to the file content. You'll quickly find a bunch of $ENV:: settings that must yield non-empty results, but you (surely) don't have those environment variables set... There are perhaps other issues. > (the one in my draft-moskowitz-ecdsa-pki): > > # OpenSSL intermediate CA configuration file. > # Copy to `$dir/intermediate/openssl-intermediate.cnf`. > > [ ca ] > # `man ca` > default_ca = CA_default > > [ CA_default ] > # Directory and file locations. > dir= $ENV::dir > cadir = $ENV::cadir > format= $ENV::format > > certs = $dir/certs > crl_dir = $dir/crl > new_certs_dir = $dir/newcerts > database = $dir/index.txt > serial= $dir/serial > RANDFILE = $dir/private/.rand > > # The Intermediate key and Intermediate certificate. > private_key = $dir/private/intermediate.key.$format > certificate = $dir/certs/intermediate.cert.$format > > # For certificate revocation lists. > crlnumber= $dir/crlnumber > crl= $dir/crl/intermediate.crl.pem > crl_extensions = crl_ext > default_crl_days = $ENV::default_crl_days > > # SHA-1 is deprecated, so use SHA-2 instead. > # default_md = sha256 > > name_opt = ca_default > cert_opt = ca_default > default_days= 375 > preserve = no > policy= policy_loose > copy_extensions= copy > > [ policy_strict ] > # The root CA should only sign intermediate certificates that match. > # See the POLICY FORMAT section of `man ca`. > countryName = match > stateOrProvinceName = match > organizationName = match > organizationalUnitName = optional > commonName = optional > > [ policy_loose ] > # Allow the intermediate CA to sign a more > # diverse range of certificates. > # See the POLICY FORMAT section of the `ca` man page. > countryName = optional > stateOrProvinceName = optional > localityName= optional > organizationName = optional > organizationalUnitName = optional > commonName = optional > UID= optional > > [ req ] > # Options for the `req` tool (`man req`). > default_bits = 2048 > distinguished_name = req_distinguished_name > string_mask= utf8only > req_extensions= req_ext > > # SHA-1 is deprecated, so use SHA-2 instead. > # default_md = sha256 > > # Extension to add when the -x509 option is used. > x509_extensions = v3_ca > > [ req_distinguished_name ] > # See . > countryName= Country Name (2 letter code) > stateOrProvinceName = State or Province Name > localityName = Locality Name > 0.organizationName = Organization Name > organizationalUnitName = Organizational Unit Name > commonName = Common Name > UID = User ID > > # Optionally, specify some defaults. > # countryName_default = US > # stateOrProvinceName_default = MI > # localityName_default= Oak Park > # 0.organizationName_default= HTT Consulting > # organizationalUnitName_default = > > [ req_ext ] > subjectAltName = $ENV::subjectAltName > > [ v3_ca ] > # Extensions for a typical CA (`man x509v3_config`). > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always,issuer > basicConstraints = critical, CA:true > # keyUsage = critical, digitalSignature, cRLSign, keyCertSign > keyUsage = critical, cRLSign, keyCertSign > > [ v3_intermediate_ca ] > # Extensions for a typical intermediate CA (`man x509v3_config`). > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always,issuer > basicConstraints = critical, CA:true, pathlen:0 > # keyUsage = critical, digitalSignature, cRLSign, keyCertSign > keyUsage = critical, cRLSign, keyCertSign > > [ usr_cert ] > # Extensions for client certificates (`man x509v3_config`). > basicConstraints = CA:FALSE > nsCertType = client, email > nsComment = "OpenSSL Generated Client Certificate" > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid,issuer > keyUsage = critical,nonRepudiation,digitalSignature,keyEncipherment > extendedKeyUsage = clientAuth, emailProtection > crlDistributionPoints = $ENV::crlDP > authorityInfoAccess = $ENV::ocspIAI > > [ server_cert ] > # Extensions for server certificates (`man x509v3_config`). > basicConstraints = CA:FALSE > nsCertType = server > nsComment = "OpenSSL Generated Server Certificate" > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid,issuer:always > keyUsage = critical, digitalSignature, keyEncipherment > extendedKeyUsage = serverAuth > crlDistributionPoints = $ENV::crlDP > authorityInfoAccess = $ENV::ocspIAI > > [ crl_ext ] > # Extension for CRLs (`man x509v3_config`). > authorityKeyIdentifier=keyid:always > > [ ocsp ] > # Extension for OCSP signing certificates (`man ocsp`). > basicConstraints = CA:FALSE > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid,issuer > keyUsage = critical, digitalSignature > extendedKeyUsage = critical, OCSPSigning -- Viktor. From jb-openssl at wisemo.com Fri Jul 27 17:52:29 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 27 Jul 2018 19:52:29 +0200 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities In-Reply-To: References: <6aa4e956-6d0e-caab-560d-bf89ee9d0cf7@digitalocean.com> Message-ID: <53477c10-2062-0f96-63d7-0387369ed839@wisemo.com> On 27/07/2018 16:20, Michael R. Hines via openssl-users wrote: > > On 07/27/2018 09:12 AM, Michael Wojcik wrote: >> >>> We're trying to decide if we can avoid disabling hyperthreading, as our >>> measurements show that the performance losses (even with integer >>> workloads) are significant. >>> >>> Might anyone be able to comment on this particular type of attack in >>> OpenSSL? >> Certainly I'd need to do a lot more research before I'd feel >> comfortable speculating about possible mitigations within OpenSSL. >> I'll be interested to see if anyone else does. >> >> -- >> Michael Wojcik >> Distinguished Engineer, Micro Focus > > Any and all guidance would be appreciated! > > Again, thank you so much for the response. We're having a very > difficult time finding a response (of any kind) > from the crypto community or from the linux distributions as well. It looks from your descriptions (I haven't read the paper, and may be wrong for other reasons too) like the most effective mitigation (not always available) is to use code that doesn't do data-dependent (incl. key-dependent) memory addressing. However converting normal algorithms to a form that always accesses the same memory bytes in the same order is a non-trivial job, and is further complicated by the very real risk that any code optimizer between you source code and the actual memory access hardware may undo your carefully crafted mitigations.? (Such optimizers could be in your compiler, in a JIT-based bytecode interpreter or even in the kind of modern CPU that this attack targets). And once you have done all that work to protect the cryptographic library, the CPU vulnerability still allows the attacker to observer the non-cryptographic application code that actually creates or uses the plain text (after all, you don't need the plaintext if you are not going to use it, or at least create it). For example, the attacker may measure the memory access patterns of the spell checker used when inputting the plain text, or the line break and character width calculations in code that outputs the plain text to an otherwise secure display. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From Michael.Wojcik at microfocus.com Fri Jul 27 18:44:45 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 27 Jul 2018 18:44:45 +0000 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities In-Reply-To: <53477c10-2062-0f96-63d7-0387369ed839@wisemo.com> References: <6aa4e956-6d0e-caab-560d-bf89ee9d0cf7@digitalocean.com> <53477c10-2062-0f96-63d7-0387369ed839@wisemo.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jakob Bohm > Sent: Friday, July 27, 2018 11:52 > > And once you have done all that work to protect the cryptographic > library, the CPU vulnerability still allows the attacker to observer > the non-cryptographic application code that actually creates or uses > the plain text (after all, you don't need the plaintext if you are > not going to use it, or at least create it). An interesting point. The limited bandwidth of most side-channel attacks means that these sorts of secondary secrets aren't usually targeted, but in many cases even small portions of plaintext might be useful. For example, extracting the Request-URIs from HTTP requests, or the RCPT TO lines from SMTP ones, can be useful for traffic and metadata analysis. We're in an interesting period. Back in the '90s, practitioners like Bruce Schneier were saying that cryptography wasn't the problem - that it had developed to the point where it was too difficult to attack, and there were myriad weaknesses in how cryptography was used, and in the applications that relied on it, and in infrastructure aspects such as PKI, and in the users themselves, so those were the practical targets. Then we had a couple of decades of ever-more and increasingly effective attacks on cryptosystems, including on the primitives themselves, and attacking the crypto became economically feasible again. Meanwhile we've had a gradual accumulation of attacks against the physical mechanisms implementing the crypto. These started long ago, of course (Kocher's timing attacks, and TEMPEST before that, and indeed well before the advent of computational cryptography), but they've been picking up speed. And the issues peripheral to cryptography - applications, infrastructure, users - haven't gone away. More and better cryptography; more and better attacks against it. -- Michael Wojcik Distinguished Engineer, Micro Focus From rgm at htt-consult.com Fri Jul 27 19:06:17 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 27 Jul 2018 15:06:17 -0400 Subject: [openssl-users] Errors on EndEntity cert generation In-Reply-To: References: <79451cee-d8eb-3e8b-c9ce-0e89ac0448c3@htt-consult.com> <803bbbaa-b0e9-c072-5bb3-02a4dbf5294a@htt-consult.com> Message-ID: <5c991fee-71b6-bf77-1547-b8113986c654@htt-consult.com> On 07/27/2018 01:26 PM, Viktor Dukhovni wrote: > On Jul 27, 2018, at 1:20 PM, Robert Moskowitz wrote: >> On 07/27/2018 01:14 PM, Viktor Dukhovni wrote: >>>> On Jul 27, 2018, at 1:07 PM, Robert Moskowitz wrote: >>>> >>>> Error Loading extension section server_cert >>>> 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn >>>> 3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=rand_serial >>>> 3065065488:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid null name:crypto/x509v3/v3_utl.c:360: >>>> 3065065488:error:22097069:X509 V3 routines:do_ext_nconf:invalid extension string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section= >>>> 3065065488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value= >>>> >>>> Please help me with these latest errors. >>> Start with a less exotic ".cnf" file. These are all configuration errors, >>> unrelated to ed25519. Get a working RSA config file, and then switch >>> algorithms. >>> >> I am using a working ecdsa config file > It is a good idea to read that file and match the error messages > to the file content. You'll quickly find a bunch of $ENV:: settings > that must yield non-empty results, but you (surely) don't have those > environment variables set... There are perhaps other issues. I read those messages and got stuck on the first and did not catch the last 2.? My procedure did not set ocspIAI and crlDP.? :( Even though my write up says to make sure to do this!? Sigh. Got my EE server cert.? Onwards! > >> (the one in my draft-moskowitz-ecdsa-pki): >> >> # OpenSSL intermediate CA configuration file. >> # Copy to `$dir/intermediate/openssl-intermediate.cnf`. >> >> [ ca ] >> # `man ca` >> default_ca = CA_default >> >> [ CA_default ] >> # Directory and file locations. >> dir= $ENV::dir >> cadir = $ENV::cadir >> format= $ENV::format >> >> certs = $dir/certs >> crl_dir = $dir/crl >> new_certs_dir = $dir/newcerts >> database = $dir/index.txt >> serial= $dir/serial >> RANDFILE = $dir/private/.rand >> >> # The Intermediate key and Intermediate certificate. >> private_key = $dir/private/intermediate.key.$format >> certificate = $dir/certs/intermediate.cert.$format >> >> # For certificate revocation lists. >> crlnumber= $dir/crlnumber >> crl= $dir/crl/intermediate.crl.pem >> crl_extensions = crl_ext >> default_crl_days = $ENV::default_crl_days >> >> # SHA-1 is deprecated, so use SHA-2 instead. >> # default_md = sha256 >> >> name_opt = ca_default >> cert_opt = ca_default >> default_days= 375 >> preserve = no >> policy= policy_loose >> copy_extensions= copy >> >> [ policy_strict ] >> # The root CA should only sign intermediate certificates that match. >> # See the POLICY FORMAT section of `man ca`. >> countryName = match >> stateOrProvinceName = match >> organizationName = match >> organizationalUnitName = optional >> commonName = optional >> >> [ policy_loose ] >> # Allow the intermediate CA to sign a more >> # diverse range of certificates. >> # See the POLICY FORMAT section of the `ca` man page. >> countryName = optional >> stateOrProvinceName = optional >> localityName= optional >> organizationName = optional >> organizationalUnitName = optional >> commonName = optional >> UID= optional >> >> [ req ] >> # Options for the `req` tool (`man req`). >> default_bits = 2048 >> distinguished_name = req_distinguished_name >> string_mask= utf8only >> req_extensions= req_ext >> >> # SHA-1 is deprecated, so use SHA-2 instead. >> # default_md = sha256 >> >> # Extension to add when the -x509 option is used. >> x509_extensions = v3_ca >> >> [ req_distinguished_name ] >> # See . >> countryName= Country Name (2 letter code) >> stateOrProvinceName = State or Province Name >> localityName = Locality Name >> 0.organizationName = Organization Name >> organizationalUnitName = Organizational Unit Name >> commonName = Common Name >> UID = User ID >> >> # Optionally, specify some defaults. >> # countryName_default = US >> # stateOrProvinceName_default = MI >> # localityName_default= Oak Park >> # 0.organizationName_default= HTT Consulting >> # organizationalUnitName_default = >> >> [ req_ext ] >> subjectAltName = $ENV::subjectAltName >> >> [ v3_ca ] >> # Extensions for a typical CA (`man x509v3_config`). >> subjectKeyIdentifier = hash >> authorityKeyIdentifier = keyid:always,issuer >> basicConstraints = critical, CA:true >> # keyUsage = critical, digitalSignature, cRLSign, keyCertSign >> keyUsage = critical, cRLSign, keyCertSign >> >> [ v3_intermediate_ca ] >> # Extensions for a typical intermediate CA (`man x509v3_config`). >> subjectKeyIdentifier = hash >> authorityKeyIdentifier = keyid:always,issuer >> basicConstraints = critical, CA:true, pathlen:0 >> # keyUsage = critical, digitalSignature, cRLSign, keyCertSign >> keyUsage = critical, cRLSign, keyCertSign >> >> [ usr_cert ] >> # Extensions for client certificates (`man x509v3_config`). >> basicConstraints = CA:FALSE >> nsCertType = client, email >> nsComment = "OpenSSL Generated Client Certificate" >> subjectKeyIdentifier = hash >> authorityKeyIdentifier = keyid,issuer >> keyUsage = critical,nonRepudiation,digitalSignature,keyEncipherment >> extendedKeyUsage = clientAuth, emailProtection >> crlDistributionPoints = $ENV::crlDP >> authorityInfoAccess = $ENV::ocspIAI >> >> [ server_cert ] >> # Extensions for server certificates (`man x509v3_config`). >> basicConstraints = CA:FALSE >> nsCertType = server >> nsComment = "OpenSSL Generated Server Certificate" >> subjectKeyIdentifier = hash >> authorityKeyIdentifier = keyid,issuer:always >> keyUsage = critical, digitalSignature, keyEncipherment >> extendedKeyUsage = serverAuth >> crlDistributionPoints = $ENV::crlDP >> authorityInfoAccess = $ENV::ocspIAI >> >> [ crl_ext ] >> # Extension for CRLs (`man x509v3_config`). >> authorityKeyIdentifier=keyid:always >> >> [ ocsp ] >> # Extension for OCSP signing certificates (`man ocsp`). >> basicConstraints = CA:FALSE >> subjectKeyIdentifier = hash >> authorityKeyIdentifier = keyid,issuer >> keyUsage = critical, digitalSignature >> extendedKeyUsage = critical, OCSPSigning From mrhines at digitalocean.com Sat Jul 28 01:06:23 2018 From: mrhines at digitalocean.com (Michael R. Hines) Date: Fri, 27 Jul 2018 20:06:23 -0500 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities In-Reply-To: References: <6aa4e956-6d0e-caab-560d-bf89ee9d0cf7@digitalocean.com> <53477c10-2062-0f96-63d7-0387369ed839@wisemo.com> Message-ID: On 07/27/2018 01:44 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Jakob Bohm >> Sent: Friday, July 27, 2018 11:52 >> >> And once you have done all that work to protect the cryptographic >> library, the CPU vulnerability still allows the attacker to observer >> the non-cryptographic application code that actually creates or uses >> the plain text (after all, you don't need the plaintext if you are >> not going to use it, or at least create it). > An interesting point. The limited bandwidth of most side-channel attacks means that these sorts of secondary secrets aren't usually targeted, but in many cases even small portions of plaintext might be useful. For example, extracting the Request-URIs from HTTP requests, or the RCPT TO lines from SMTP ones, can be useful for traffic and metadata analysis. > > We're in an interesting period. Back in the '90s, practitioners like Bruce Schneier were saying that cryptography wasn't the problem - that it had developed to the point where it was too difficult to attack, and there were myriad weaknesses in how cryptography was used, and in the applications that relied on it, and in infrastructure aspects such as PKI, and in the users themselves, so those were the practical targets. > > Then we had a couple of decades of ever-more and increasingly effective attacks on cryptosystems, including on the primitives themselves, and attacking the crypto became economically feasible again. > > Meanwhile we've had a gradual accumulation of attacks against the physical mechanisms implementing the crypto. These started long ago, of course (Kocher's timing attacks, and TEMPEST before that, and indeed well before the advent of computational cryptography), but they've been picking up speed. > > And the issues peripheral to cryptography - applications, infrastructure, users - haven't gone away. > > More and better cryptography; more and better attacks against it. Forgive the stupid question, but what's the takeaway for a cloud provider? Do we gather from these points that the entire set of timing attacks will never really be known? What does this confirm (or not confirm) about openssl's vulnerability (or knowable status) to TLBleed? - Michael From felipe at felipegasper.com Sat Jul 28 02:49:45 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Fri, 27 Jul 2018 22:49:45 -0400 Subject: [openssl-users] Ed25519 and X.509 Message-ID: Hi all, Are there yet OIDs for Ed25519-signed X.509? I know about the drafts for the key format but am not aware of actual OIDs to identify the signature hash algorithm. Thank you! -F From matt at openssl.org Sat Jul 28 11:00:59 2018 From: matt at openssl.org (Matt Caswell) Date: Sat, 28 Jul 2018 12:00:59 +0100 Subject: [openssl-users] genpkey for ed25519 In-Reply-To: <1532700281.13685.8.camel@redhat.com> References: <1532700281.13685.8.camel@redhat.com> Message-ID: <12187075-96fd-dc5a-10bf-bb02eb392536@openssl.org> On 27/07/18 15:04, Tomas Mraz wrote: > On Fri, 2018-07-27 at 09:44 -0400, Robert Moskowitz wrote: >> Here we go again with figuring out what to put in the command >> lines. >> Dr. Google is not giving up enough answers. >> >> For ecdsa I started with: >> >> openssl genpkey -aes256 -algorithm ec\ >> -pkeyopt ec_paramgen_curve:prime256v1\ >> -outform pem -pkeyopt ec_param_enc:named_curve\ >> -out $dir/private/ca.key.pem >> >> I found one reference that I should use -algorithm ed25519 (though >> the >> example used caps: ED25519) > > Yes, it is case insensitive. > >> But I have not found recommendation for ec_parmgen_curve or >> ec_param_enc >> >> Can someone point me to the information on values for these (and I >> suspect I will be hitting others as I go). > > Just do not use these options. > Just to add to this, the genpkey documentation gives an example for X25519 and ED448. Its the same for ED25519: https://www.openssl.org/docs/manmaster/man1/genpkey.html Matt From matt at openssl.org Sat Jul 28 11:10:59 2018 From: matt at openssl.org (Matt Caswell) Date: Sat, 28 Jul 2018 12:10:59 +0100 Subject: [openssl-users] Ed25519 and X.509 In-Reply-To: References: Message-ID: <349e8af0-9559-52ca-ab11-38caff2e3901@openssl.org> On 28/07/18 03:49, Felipe Gasper wrote: > Hi all, > > Are there yet OIDs for Ed25519-signed X.509? I know about the drafts for the key format but am not aware of actual OIDs to identify the signature hash algorithm. > > Thank you! > See: https://tools.ietf.org/html/draft-ietf-curdle-pkix-10 Matt From felipe at felipegasper.com Sat Jul 28 11:23:48 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Sat, 28 Jul 2018 07:23:48 -0400 Subject: [openssl-users] Ed25519 and X.509 In-Reply-To: <349e8af0-9559-52ca-ab11-38caff2e3901@openssl.org> References: <349e8af0-9559-52ca-ab11-38caff2e3901@openssl.org> Message-ID: I knew about this one. I see OIDs here for the key algorithm, but not the signature/hash algorithm .. ? I?m looking for the OID that precedes the signature in an X.509 structure. Thank you! -FG > On Jul 28, 2018, at 7:10 AM, Matt Caswell wrote: > > > >> On 28/07/18 03:49, Felipe Gasper wrote: >> Hi all, >> >> Are there yet OIDs for Ed25519-signed X.509? I know about the drafts for the key format but am not aware of actual OIDs to identify the signature hash algorithm. >> >> Thank you! >> > > See: > > https://tools.ietf.org/html/draft-ietf-curdle-pkix-10 > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Sat Jul 28 11:42:13 2018 From: matt at openssl.org (Matt Caswell) Date: Sat, 28 Jul 2018 12:42:13 +0100 Subject: [openssl-users] Ed25519 and X.509 In-Reply-To: References: <349e8af0-9559-52ca-ab11-38caff2e3901@openssl.org> Message-ID: <999a0084-db8e-59bc-d0d7-565e5b663643@openssl.org> On 28/07/18 12:23, Felipe Gasper wrote: > I knew about this one. I see OIDs here for the key algorithm, but not the signature/hash algorithm .. ? I?m looking for the OID that precedes the signature in an X.509 structure. There is an example of a certificate signed with Ed25519 in that document. As noted in the text: "The same algorithm identifiers are used for identifying a public key, identifying a private key and identifying a signature (for the two EdDSA related OIDs). " Note, these OIDS are for EdDSA in pure mode so there is no hash, and hence no need for a separate OID for the sig/hash pair. Matt > > Thank you! > > -FG > >> On Jul 28, 2018, at 7:10 AM, Matt Caswell wrote: >> >> >> >>> On 28/07/18 03:49, Felipe Gasper wrote: >>> Hi all, >>> >>> Are there yet OIDs for Ed25519-signed X.509? I know about the drafts for the key format but am not aware of actual OIDs to identify the signature hash algorithm. >>> >>> Thank you! >>> >> >> See: >> >> https://tools.ietf.org/html/draft-ietf-curdle-pkix-10 >> >> Matt >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From Michael.Wojcik at microfocus.com Sat Jul 28 13:44:02 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Sat, 28 Jul 2018 13:44:02 +0000 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities In-Reply-To: References: <6aa4e956-6d0e-caab-560d-bf89ee9d0cf7@digitalocean.com> <53477c10-2062-0f96-63d7-0387369ed839@wisemo.com> Message-ID: > From: Michael R. Hines [mailto:mrhines at digitalocean.com] > Sent: Friday, July 27, 2018 19:06 > > Forgive the stupid question, but what's the takeaway for a cloud > provider? Well, in general, it's probably the commonplace that security is a process, not a product. There will always be new attacks of some sort. > Do we gather from these points that the entire set of timing > attacks will never really be known? That's probably a safe assumption, particularly if "timing attacks" is defined broadly. (There was a famous timing attack against the TENEX logon mechanism back in the 1970s; does that count?) Even for computational timing attacks (like Kocher's) and microarchitectural timing attacks (like TLBleed), it would be impossible to prove you had the complete set unless the entire system was formally verified and the implementation could somehow be demonstrated to conform to the forrmal specification under all conditions. In theory you can increase the noise on the channel to the point where it's no longer economical. Research on that goes back to at least the early 1990s. The problems, of course, are making sure you comprehensively inject noise into all the known channels, and finding users willing to pay the cost - increased noise means reduced efficiency. We see this trade-off in all sorts of side-channel attacks; in the cloud, for example, you have the various results showing security issues with memory deduplication. For cloud computing, we've had at least a decade of research into this issue (see e.g. Ristenpart et al, "Hey, you, get off my cloud", published nine years ago so work presumably started no later than 2008). And it's still a problem, which means it's complicated and likely to be durable. > What does this confirm (or not confirm) about openssl's vulnerability > (or knowable status) to TLBleed? Specifically? Not much. It goes more to the general principle that systems leak information as they do work. Ultimately it comes down to thermodynamics, and you never bet against thermodynamics. -- Michael Wojcik Distinguished Engineer, Micro Focus From felipe at felipegasper.com Sat Jul 28 14:18:55 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Sat, 28 Jul 2018 10:18:55 -0400 Subject: [openssl-users] Ed25519 and X.509 In-Reply-To: <999a0084-db8e-59bc-d0d7-565e5b663643@openssl.org> References: <349e8af0-9559-52ca-ab11-38caff2e3901@openssl.org> <999a0084-db8e-59bc-d0d7-565e5b663643@openssl.org> Message-ID: <0C2BDFC4-5072-465D-85DC-5F608654F17F@felipegasper.com> Ah ok. Thank you for clarifying! -FG > On Jul 28, 2018, at 7:42 AM, Matt Caswell wrote: > > > >> On 28/07/18 12:23, Felipe Gasper wrote: >> I knew about this one. I see OIDs here for the key algorithm, but not the signature/hash algorithm .. ? I?m looking for the OID that precedes the signature in an X.509 structure. > > There is an example of a certificate signed with Ed25519 in that > document. As noted in the text: > > "The same algorithm identifiers are used for identifying a public key, > identifying a private key and identifying a signature (for the two > EdDSA related OIDs). " > > Note, these OIDS are for EdDSA in pure mode so there is no hash, and > hence no need for a separate OID for the sig/hash pair. > > Matt > > >> >> Thank you! >> >> -FG >> >>> On Jul 28, 2018, at 7:10 AM, Matt Caswell wrote: >>> >>> >>> >>>> On 28/07/18 03:49, Felipe Gasper wrote: >>>> Hi all, >>>> >>>> Are there yet OIDs for Ed25519-signed X.509? I know about the drafts for the key format but am not aware of actual OIDs to identify the signature hash algorithm. >>>> >>>> Thank you! >>>> >>> >>> See: >>> >>> https://tools.ietf.org/html/draft-ietf-curdle-pkix-10 >>> >>> Matt >>> >>> -- >>> 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 From digant.kubavat at gmail.com Sat Jul 28 16:13:00 2018 From: digant.kubavat at gmail.com (Devang Kubavat) Date: Sat, 28 Jul 2018 21:43:00 +0530 Subject: [openssl-users] Using a TPM to sign CSRs In-Reply-To: References: Message-ID: Hi Kaarhik, Please refer https://github.com/ThomasHabets/openssl-tpm-engine. It is OpenSSL TPM Engine. It will help to offload all crypto operation to TPM. Regards, Devang. On Tue, Jul 24, 2018 at 4:48 PM, Kaarthik Sivakumar wrote: > Hello > > I need to create a key pair using a TPM (proprietary) and build a CSR and > sign it using it the TPM as well. Currently I dont have an engine interface > to talk to the TPM. I do the following: > > 1. generate key pair in the TPM. private key is kept private in the TPM > and public key can be obtained out of the TPM > > 2. use the public key to generate a CSR (X509_REQ_init(), etc) > > 3. Get the hash of the CSR (X509_REQ_digest()) > > 4. Pass the digest to the TPM and get back signature > > 5. Add signature to the CSR - I dont see any way to do this. Is there an > openssl API to perform this step? I dont think I can use X509_REQ_sign() > since that will use the private key provided or if I have an engine > interface then it will call the engine to do the signing. Is there a way to > call sign() and make it call my function that can do the step 4 above? > > Thanks! > > -kaarthik- > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.boehme at cloudandheat.com Sat Jul 28 18:53:09 2018 From: christian.boehme at cloudandheat.com (=?UTF-8?Q?Christian_B=c3=b6hme?=) Date: Sat, 28 Jul 2018 20:53:09 +0200 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure Message-ID: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> Hello all, Assume that we have $ uname -srvmpio Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ openssl version OpenSSL 1.0.2g 1 Mar 2016 $ printenv SHELL /bin/bash $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63575 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 63575 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited $ dd if=/dev/zero of=plaintext.in bs=1024 count=$((1024 * 1024 * 2)) 2097152+0 records in 2097152+0 records out 2147483648 bytes (2.1 GB, 2.0 GiB) copied, 7.7645 s, 277 MB/s $ echo -n 'uno dos tres cuatro' | openssl cms -encrypt -aes-256-cbc -pwri_password fd:0 -in plaintext.in -binary -out ciphertext.der -outform DER $ ls -lAF total 4054804 -rw-rw-r-- 1 ubuntu ubuntu 2004623580 Jul 28 20:09 ciphertext.der -rw-rw-r-- 1 ubuntu ubuntu 2147483648 Jul 28 19:55 plaintext.in then we get $ openssl asn1parse -in ciphertext.der -inform DER -i 140507999028888:error:07064041:memory buffer routines:BUF_MEM_grow:malloc failure:buffer.c:113: or $ echo -n 'uno dos tres cuatro' | openssl cms -decrypt -pwri_password fd:0 -in ciphertext.der -inform DER -out plaintext.out Error reading S/MIME message 139871963694744:error:07069041:memory buffer routines:BUF_MEM_grow_clean:malloc failure:buffer.c:150: 139871963694744:error:0D06B041:asn1 encoding routines:ASN1_D2I_READ_BIO:malloc failure:a_d2i_fp.c:239: It would appear that both commands fail due to them being unable to allocate more memory to slurp the rest of the input file's contents into. Is this intentional behaviour? Both commands work when the plaintext file is half the size, i.e. 1 GiB, BTW. Thanks, Christian -- *Christian B?hme* Developer System Integration CLOUD&HEAT *CLOUD & HEAT Technologies GmbH* K?nigsbr?cker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: christian.boehme at cloudandheat.com Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Gesch?ftsf?hrer: Nicolas R?hrs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: OpenPGP digital signature URL: From rsalz at akamai.com Sat Jul 28 20:27:24 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 28 Jul 2018 20:27:24 +0000 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> Message-ID: <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> > It would appear that both commands fail due to them being unable to allocate more memory to slurp the rest of the input file's contents into. Is this intentional behaviour? It is a known issue. From bill.c.roberts at gmail.com Sat Jul 28 21:10:09 2018 From: bill.c.roberts at gmail.com (William Roberts) Date: Sat, 28 Jul 2018 14:10:09 -0700 Subject: [openssl-users] Using a TPM to sign CSRs In-Reply-To: References: Message-ID: On Sat, Jul 28, 2018, 09:13 Devang Kubavat wrote: > Hi Kaarhik, > > Please refer https://github.com/ThomasHabets/openssl-tpm-engine. It is > OpenSSL TPM Engine. It will help to offload all crypto operation to TPM. > Is this for tpm2.0? > Regards, > Devang. > > On Tue, Jul 24, 2018 at 4:48 PM, Kaarthik Sivakumar > wrote: > >> Hello >> >> I need to create a key pair using a TPM (proprietary) and build a CSR and >> sign it using it the TPM as well. Currently I dont have an engine interface >> to talk to the TPM. I do the following: >> >> 1. generate key pair in the TPM. private key is kept private in the TPM >> and public key can be obtained out of the TPM >> >> 2. use the public key to generate a CSR (X509_REQ_init(), etc) >> >> 3. Get the hash of the CSR (X509_REQ_digest()) >> >> 4. Pass the digest to the TPM and get back signature >> >> 5. Add signature to the CSR - I dont see any way to do this. Is there an >> openssl API to perform this step? I dont think I can use X509_REQ_sign() >> since that will use the private key provided or if I have an engine >> interface then it will call the engine to do the signing. Is there a way to >> call sign() and make it call my function that can do the step 4 above? >> >> Thanks! >> >> -kaarthik- >> >> >> -- >> 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 felipe at felipegasper.com Sun Jul 29 02:15:10 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Sat, 28 Jul 2018 22:15:10 -0400 Subject: [openssl-users] Slightly OT: X.509 & PCKS10 generation in Perl Message-ID: Hi all, Based on some comments I?ve seen lately, I thought it might be helpful to mention Crypt::Perl (https://metacpan.org/pod/Crypt::Perl), a Perl crypto toolkit I?ve written that implements RSA, ECC, and Ed25519 and can generate TLS certificates and CSRs. I mention it because I think the syntax is more straightforward than navigating the openssl binary and openssl.cnf. It?s not nearly as fast, of course, but I?ve found it useful. YMMV. -Felipe Gasper From kvenkatarao at infinera.com Sun Jul 29 11:30:44 2018 From: kvenkatarao at infinera.com (Kumar Venkatarao) Date: Sun, 29 Jul 2018 11:30:44 +0000 Subject: [openssl-users] Question on RSA/FIPS186-4. Message-ID: Hi, I am working on FIPS certification (v2.0.16). I?ve few questions w.r.t RSA And FIPS 186-4. We are using OpenSsl 1.0.2n With FIPS v2.0.16. I?ve browsed through some articles/discussions on the subject and As I understand, the OpenSSL doesn?t support RSA FIPS 186-4 standard. It supports FIPS 186-2 standard. The questions are ? 1. Do we plan to support this in releases that are close (Say Sep, 2018) ? 2. There are also talks about RSA FIPS 186-4 being available with redhat, suse Distributions. Since the FIPS build process, recommends the integrity checks To be done at source code, object and load times, I am not sure, if this Is recommended ? Can your team recommend us ways of getting around RSA FIPS 186-4 certification ? Thanks Kumar From rsalz at akamai.com Sun Jul 29 16:26:14 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 29 Jul 2018 16:26:14 +0000 Subject: [openssl-users] Question on RSA/FIPS186-4. Message-ID: <322466FF-A9DB-4E29-8A7C-5BA3B3209185@akamai.com> > 1. Do we plan to support this in releases that are close (Say Sep, 2018) ? No. > 2. There are also talks about RSA FIPS 186-4 being available with redhat, suse Distributions. Since the FIPS build process, recommends the integrity checks To be done at source code, object and load times, I am not sure, if this Is recommended ? I do not know if you can mix and match FIPS implementations. I know that you cannot change anything in the OpenSSL code (for example, to call "out and over" to someone else's implementation). > Can your team recommend us ways of getting around RSA FIPS 186-4 certification ? It seems that the most straightforward way is to use one of those implementations that has the algorithms you need. OpenSSL is working on a new validation, no details (such as specific algorithms) are available yet. From christian.boehme at cloudandheat.com Mon Jul 30 08:57:18 2018 From: christian.boehme at cloudandheat.com (=?UTF-8?Q?Christian_B=c3=b6hme?=) Date: Mon, 30 Jul 2018 10:57:18 +0200 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> Message-ID: <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> On 28.07.2018 22:27, Salz, Rich via openssl-users wrote: >> It would appear that both commands fail due to them being unable to > allocate more memory to slurp the rest of the input file's contents into. > Is this intentional behaviour? > > It is a known issue. What's the reason for using malloc(3) in the first place? Is this a limitation of the library or just openssl cms ? For the latter, if the argument to -in can be determined to resolve to a file descriptor of a regular file, the file's contents can be /very/ conveniently mmap(2)'ed into the process' address space, ignoring possible limits. Thanks, Christian -- *Christian B?hme* Developer System Integration CLOUD&HEAT *CLOUD & HEAT Technologies GmbH* K?nigsbr?cker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: christian.boehme at cloudandheat.com Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Gesch?ftsf?hrer: Nicolas R?hrs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: OpenPGP digital signature URL: From tmraz at redhat.com Mon Jul 30 09:47:32 2018 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 30 Jul 2018 11:47:32 +0200 Subject: [openssl-users] Intermediate cert file failure In-Reply-To: References: Message-ID: <1532944052.11215.5.camel@redhat.com> On Fri, 2018-07-27 at 12:49 -0400, Robert Moskowitz wrote: > > On 07/27/2018 12:35 PM, Viktor Dukhovni wrote: > > > > > On Jul 27, 2018, at 11:25 AM, Robert Moskowitz > > om> wrote: > > > > > > 3064446992:error:2006D080:BIO routines:BIO_new_file:no such > > > file:crypto/bio/bss_file.c:79: > > > variable lookup failed for CA_default::default_md > > > 3064446992:error:0E06D06C:configuration file > > > routines:NCONF_get_string:no > > > value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md > > > > Well ca(1) wants either an explicit "md" option or a default_md. > > Perhaps it does not yet support ed25519. You can sign directly > > with "openssl x509", but first try > > > > openssl ca -md null > > or > > openssl ca -md default > > > > and see if either of those work. > > > > -md null worked: > > openssl ca -config $cadir/openssl-root.cnf -days 3650\ > -extensions v3_intermediate_ca -notext -md null\ > -in $dir/csr/intermediate.csr.$format\ > -out $dir/certs/intermediate.cert.pem > > Can't open /root/ca/intermediate/index.txt.attr for reading, No such > file or directory > 3064946704:error:02001002:system library:fopen:No such file or > directory:crypto/bio/bss_file.c:72:fopen('/root/ca/intermediate/index > .txt.attr','r') > 3064946704:error:2006D080:BIO routines:BIO_new_file:no such > file:crypto/bio/bss_file.c:79: > Check that the request matches the signature > Signature ok > Certificate Details: > Serial Number: > ad:0f:52:5d:91:70:1a:d3 > Validity > Not Before: Jul 27 16:41:03 2018 GMT > Not After : Jul 24 16:41:03 2028 GMT > Subject: > countryName = US > stateOrProvinceName = MI > organizationName = HTT Consulting > commonName = Signing CA > X509v3 extensions: > X509v3 Subject Key Identifier: > DB:5F:0C:00:54:DD:A6:EB:61:BD:79:13:0A:2D:EA:0A:19:82:E8:C5 > X509v3 Authority Key Identifier: > keyid:D6:1B:BA:96:44:EF:F1:07:59:35:A7:F2:77:5F:82:24:21:53:9A:9F > > X509v3 Basic Constraints: critical > CA:TRUE, pathlen:0 > X509v3 Key Usage: critical > Certificate Sign, CRL Sign > X509v3 Subject Alternative Name: > email:postmaster at htt-consult.com > Certificate is to be certified until Jul 24 16:41:03 2028 GMT (3650 > days) > Sign the certificate? [y/n]:y > > > 1 out of 1 certificate requests certified, commit? [y/n]y > Write out database with 1 new entries > Data Base Updated > > There was no file index.txt.attr, but now there is: > > # cat index.txt.attr > unique_subject = yes > > I don't remember this from my ecdsa work with 1.1.0 > > This issue with md is definitely and issue. I can try -md null on > the > self-signed root cert, but it seems that this should not even be > referenced for ed25519 > > But I got my intermediate cert, so on to the next step. > > thanks for your help, Viktor. Please open a Github issue for the default_md problem. It really hampers the usability. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From minfrin at sharp.fm Mon Jul 30 12:26:32 2018 From: minfrin at sharp.fm (Graham Leggett) Date: Mon, 30 Jul 2018 14:26:32 +0200 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> Message-ID: On 24 Jul 2018, at 18:06, Viktor Dukhovni wrote: >> Or is it correct in v1.1.0 and above to just not initialise anything at all, not clean anything up at all, and expect openssl to ?do the right thing? when mod_ssl is unloaded? > > Yes. And *especially* when the code that depends on OpenSSL is itself a library. > OpenSSL is now (and should ideally always have been) self-initializing. What should be behaviour be in openssl < 1.1.0? The scenario is as follows: - httpd runs. - httpd dynamically loads mod_ssl, apr_crypto_openssl, libpq, libldap, etc. - mod_ssl, apr_crypto_openssl, libpq, libldap, etc in turn dynamically load openssl. - At some point a graceful shutdown is attempted and mod_ssl, apr_crypto_openssl, libpq, libldap, etc are unloaded. - ?what next? How should mod_ssl, apr_crypto_openssl, libpq, libldap, etc handle the unloading of openssl < 1.1.0? Should they run the openssl init functions but not the teardown functions? (And just accept a leak). Should they suppress attempts to unload mod_ssl, apr_crypto_openssl, libpq, libldap, etc if we know for sure that openssl < 1.1.0 is linked to them? Regards, Graham ? From rsalz at akamai.com Mon Jul 30 12:35:33 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 30 Jul 2018 12:35:33 +0000 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> Message-ID: > What's the reason for using malloc(3) in the first place? Is this a limitation of the library or just openssl cms ? It is a limitation of the CMS command. You might look at the -stream option. If you need more then that, well, a PR is also welcomed. From Michael.Wojcik at microfocus.com Mon Jul 30 13:22:44 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 30 Jul 2018 13:22:44 +0000 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Christian B?hme > Sent: Monday, July 30, 2018 02:57 > > For the latter, if the argument to -in can be determined to resolve to a file > descriptor of a regular file, the file's contents can be /very/ conveniently > mmap(2)'ed > into the process' address space, ignoring possible limits. Not portably, it can't. There are operating systems other than Linux and UNIX, and OpenSSL supports a number of them. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl-users at dukhovni.org Mon Jul 30 14:02:16 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Jul 2018 10:02:16 -0400 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> Message-ID: <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> > On Jul 30, 2018, at 8:26 AM, Graham Leggett wrote: > > Should they suppress attempts to unload mod_ssl, apr_crypto_openssl, libpq, libldap, etc if we know for sure that openssl < 1.1.0 is linked to them? My recommendation is never unload a library once loaded. I don't see the point, unloading and reloading on demand risks crashes and memory leaks. Others may disagree, but I prefer to not assume that unloading is safe. In OpenSSL 1.1.0, we try to do our best to make it safe, but some one-time static allocations will still leak and crash safety is likely platform-specific. -- Viktor. From Michael.Wojcik at microfocus.com Mon Jul 30 14:18:19 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 30 Jul 2018 14:18:19 +0000 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Viktor Dukhovni > Sent: Monday, July 30, 2018 08:02 > > My recommendation is never unload a library once loaded. I agree, at least in most cases. I don't know why people worry about singleton memory "leaks". If the leak isn't growing over the lifetime of the process, it's not causing any trouble. I've seen some teams obsessing about getting clean reports from dynamic-analysis tools like Valgrind. In most environments that's pointless "optimization" and a waste of development resources. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl at jordan.maileater.net Mon Jul 30 16:52:25 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Mon, 30 Jul 2018 09:52:25 -0700 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> Message-ID: <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> On 7/30/2018 7:18 AM, Michael Wojcik wrote: > I don't know why people worry about singleton memory "leaks". If the > leak isn't growing over the lifetime of the process, it's not causing > any trouble. I've seen some teams obsessing about getting clean > reports from dynamic-analysis tools like Valgrind. In most > environments that's pointless "optimization" and a waste of > development resources. Because a zero-leaks policy is a lot easier to manage than having to make a judgement call on each leak whether or not it's important, and having to filter out "unimportant" leaks when you're trying to find out whether you've introduced any "important" leaks. Maybe the test suite only caused the program to leak one buffer, but that doesn't tell you whether a real workload (or a malicious workload) will leak gigabytes. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Mon Jul 30 16:46:23 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Mon, 30 Jul 2018 09:46:23 -0700 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> Message-ID: <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> On 7/30/2018 1:57 AM, Christian B?hme wrote: > What's the reason for using malloc(3) in the first place? Is this a > limitation of the library or just openssl cms ? > > For the latter, if the argument to -in can be determined to resolve to > a file descriptor of a regular file, the file's contents can be /very/ > conveniently mmap(2)'ed into the process' address space, ignoring > possible limits. > If you can't malloc the space, you probably can't mmap it either.? I have never heard of a malloc implementation that has artificial limits; if it's failing it's because it can't find that much contiguous virtual address space, and mmap won't be able to find it either. If you're a 32-bit process, then malloc'ing or mmap'ing a 2GB object will be difficult at best. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From martygalyean at gmail.com Mon Jul 30 17:17:39 2018 From: martygalyean at gmail.com (Marty G) Date: Mon, 30 Jul 2018 13:17:39 -0400 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> Message-ID: <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> On 07/30/2018 12:52 PM, Jordan Brown wrote: > Because a zero-leaks policy is a lot easier to manage than having to > make a judgement call on each leak whether or not it's important, and > having to filter out "unimportant" leaks when you're trying to find > out whether you've introduced any "important" leaks. > > Maybe the test suite only caused the program to leak one buffer, but > that doesn't tell you whether a real workload (or a malicious > workload) will leak gigabytes. > -- > Jordan Brown, Oracle Solaris > ^^^ this So much has changed in programming culture over the decades for me to be able to call it "engineering" any more.? Too much code equivalents of duct tape, chewing gum, and kite string holding things together out there and so many consider that normal and ok. I never thought I'd see the day that someone would have to defend not leaking memory in pivotal security code like openssl however -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jul 30 17:27:40 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 30 Jul 2018 17:27:40 +0000 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> Message-ID: <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> > I never thought I'd see the day that someone would have to defend not leaking memory in pivotal security code like openssl however To be accurate, it was a couple of people saying that memory leaks *on process exit* aren?t be a big deal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Jul 30 18:07:22 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Jul 2018 14:07:22 -0400 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> Message-ID: <76DDA20E-6704-4913-B045-238561DD80AA@dukhovni.org> > On Jul 30, 2018, at 12:46 PM, Jordan Brown wrote: > > If you can't malloc the space, you probably can't mmap it either. I have never heard of a malloc implementation that has artificial limits; if it's failing it's because it can't find that much contiguous virtual address space, and mmap won't be able to find it either. > > If you're a 32-bit process, then malloc'ing or mmap'ing a 2GB object will be difficult at best. Getting out of the weeds, the core issue is that CMS message input processing doesn't stream. The entire CMS message has to fit into memory. A different data format is required for streaming large payloads. The data would need to be chunked with integrity protection and protection applied to each chunk (packet) and appropriate sequence number integrity in place to prevent reordering, insertion or deletion of chunks. CMS works fine for small messages, and could even be used to construct the integrity-protected chunks in a higher-level protocol. CMS is not appropriate for multi-gigabyte or terabyte, ... datasets. -- Viktor. From martygalyean at gmail.com Mon Jul 30 18:08:08 2018 From: martygalyean at gmail.com (Marty G) Date: Mon, 30 Jul 2018 14:08:08 -0400 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> Message-ID: <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> On 07/30/2018 01:27 PM, Salz, Rich via openssl-users wrote: > > I never thought I'd see the day that someone would have to defend > not leaking memory in pivotal security code like openssl however > > To be accurate, it was a couple of people saying that memory leaks *on > process exit* aren?t be a big deal. > > Fair enough, but it is my understanding that some RTOSes do not necessarily dealloc all memory alloc'd by a proc on proc exit.? So why not just have a rule "don't litter" instead of having complicated rules of when it is "probably ok to litter"?? Exploits nearly always leverage something programmers didn't anticipate or happens in a layer they are relying on but not directly coding so it seems fairly clear that the best path is to reduce those unknowns by explicitly cleaning up.? Taking the time to track down a memory leak rarely results in merely fixing a memory leak; usually another programming misstep is also found in conjunction with the leak. Just my $0.02 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Mon Jul 30 18:12:23 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 30 Jul 2018 18:12:23 +0000 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown > Sent: Monday, July 30, 2018 10:46 > I have never heard of a malloc implementation that has artificial limits; Er... setrlimit(RLIMIT_DATA). For OSes that claim Single UNIX Specification compliance. >if it's failing it's because it can't find that much contiguous virtual address space, and mmap won't be able to > find it either. FWIW, SUS Issue 5 defines RLIMIT_AS as applying to both malloc and mmap, but RLIMIT_DATA as applying only to malloc. (That is, mmap'd pages do not count against the data limit.) > If you're a 32-bit process, then malloc'ing or mmap'ing a 2GB object will be difficult at best. Agreed. And I'm not endorsing the mmap approach for this problem anyway - I'd use a streaming approach, so I'm not limited by address space. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Mon Jul 30 18:12:26 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 30 Jul 2018 18:12:26 +0000 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-users > Sent: Monday, July 30, 2018 11:28 > > I never thought I'd see the day that someone would have to defend not leaking memory > > in pivotal security code like openssl however > To be accurate, it was a couple of people saying that memory leaks *on process exit* aren?t be a big deal. And only singleton leaks, at that. But why sweat comprehension when there's an opportunity to be rude? As for Jordan's objection: If you don't know the source of your "leaks", then I can't say I'm particularly impressed with a zero-"leak" policy. That amounts to "let's burn a lot of cycles during process termination, rather than understand what we're doing". -- Michael Wojcik Distinguished Engineer, Micro Focus From rsalz at akamai.com Mon Jul 30 18:34:11 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 30 Jul 2018 18:34:11 +0000 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> Message-ID: * So why not just have a rule "don't litter" Have you looked at, say, the memleak testing we do? Thanks for the two cents. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhines at digitalocean.com Mon Jul 30 18:45:01 2018 From: mrhines at digitalocean.com (Michael R. Hines) Date: Mon, 30 Jul 2018 13:45:01 -0500 Subject: [openssl-users] request for TLBleed information / non-constant-time vulnerabilities In-Reply-To: References: <6aa4e956-6d0e-caab-560d-bf89ee9d0cf7@digitalocean.com> <53477c10-2062-0f96-63d7-0387369ed839@wisemo.com> Message-ID: <564629d0-d996-2842-ff40-d52f3d4cb015@digitalocean.com> By the way, these responses have been very thoughtful. I just wanted to say thanks! /* * Michael R. Hines * Staff Engineer, DigitalOcean. */ On 07/28/2018 08:44 AM, Michael Wojcik wrote: >> From: Michael R. Hines [mailto:mrhines at digitalocean.com] >> Sent: Friday, July 27, 2018 19:06 >> >> Forgive the stupid question, but what's the takeaway for a cloud >> provider? > Well, in general, it's probably the commonplace that security is a process, not a product. There will always be new attacks of some sort. > >> Do we gather from these points that the entire set of timing >> attacks will never really be known? > That's probably a safe assumption, particularly if "timing attacks" is defined broadly. (There was a famous timing attack against the TENEX logon mechanism back in the 1970s; does that count?) > > Even for computational timing attacks (like Kocher's) and microarchitectural timing attacks (like TLBleed), it would be impossible to prove you had the complete set unless the entire system was formally verified and the implementation could somehow be demonstrated to conform to the forrmal specification under all conditions. > > In theory you can increase the noise on the channel to the point where it's no longer economical. Research on that goes back to at least the early 1990s. The problems, of course, are making sure you comprehensively inject noise into all the known channels, and finding users willing to pay the cost - increased noise means reduced efficiency. We see this trade-off in all sorts of side-channel attacks; in the cloud, for example, you have the various results showing security issues with memory deduplication. > > For cloud computing, we've had at least a decade of research into this issue (see e.g. Ristenpart et al, "Hey, you, get off my cloud", published nine years ago so work presumably started no later than 2008). And it's still a problem, which means it's complicated and likely to be durable. > >> What does this confirm (or not confirm) about openssl's vulnerability >> (or knowable status) to TLBleed? > Specifically? Not much. It goes more to the general principle that systems leak information as they do work. Ultimately it comes down to thermodynamics, and you never bet against thermodynamics. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > From martygalyean at gmail.com Mon Jul 30 19:00:22 2018 From: martygalyean at gmail.com (Marty G) Date: Mon, 30 Jul 2018 15:00:22 -0400 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> Message-ID: <80c39a80-15c2-06a3-85b7-e8cccf54d435@gmail.com> On 07/30/2018 02:34 PM, Salz, Rich via openssl-users wrote: > * So why not just have a rule "don't litter" > > Have you looked at, say, the memleak testing we do? > > Thanks for the two cents. > > Of course I applaud the team's memleak testing!? How could my post be interpreted otherwise?? I wasn't trying to single anyone out, just the general idea that any memory leak is of little concern when the implications of the leak aren't fully known if the cause of the leak isn't known, and if one knows the cause, why not deal with it as simple good practice? But nothing beats good programming habits for cleaning up, i.e. "not littering" in the first place, as after the fact testing doesn't necessarily catch all cases where leaks can occur.? Analogous care at the programming stage applies to buffer overruns also as catching them after the fact is a dynamic trap shoot.? Same philosophy though.? As previously noted by another in this thread, the memleak may be load or data size dependent.? Or it may be dependent on some intermittent state of the underlying OS.? Some leaks can occur from structures accessed only via handles to the process and the OS doesn't necessarily release those structures when a process exits. But if the dev *always* explicitly makes the call to the system to release those structures via the handle then one can be far less concerned about the implications about what the system will or won't do if one doesn't For what it is worth, from my view, I'm addressing a small percentage of developers out there who may have not considered the implications of some of this and how easy it can be avoided altogether with some simple practices at code time, rather than trying to mop up later in dynamic testing.? I have nothing but the highest respect and gratefulness for the sweat and care behind openssl and wouldn't be posting at all if I didn't, so thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Jul 30 19:27:31 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Jul 2018 15:27:31 -0400 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <80c39a80-15c2-06a3-85b7-e8cccf54d435@gmail.com> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> <80c39a80-15c2-06a3-85b7-e8cccf54d435@gmail.com> Message-ID: > On Jul 30, 2018, at 3:00 PM, Marty G wrote: > > Of course I applaud the team's memleak testing! How could my post be interpreted otherwise? I wasn't trying to single anyone out, just the general idea that any memory leak is of little concern when the implications of the leak aren't fully known if the cause of the leak isn't known, and if one knows the cause, why not deal with it as simple good practice? One time initialization that allocates an object for the lifetime of the process has justifiably not been considered a "leak". Refactoring code to enable exit-time deallocation of static allocated objects is mostly fruitless work. The only time such "leaks" come into play is process exit and library unload. My advice is to not unload the library and to accept the fact that a small fixed amount of memory might not be deallocated at exit. Typically, even "valgrind" will not report "leaks" for addresses that are still referenced, so the static allocations are not a problem. Spending valuable cycles to eliminate these is not the most productive use of our time. -- Viktor. From martygalyean at gmail.com Mon Jul 30 19:43:32 2018 From: martygalyean at gmail.com (Marty G) Date: Mon, 30 Jul 2018 15:43:32 -0400 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> <80c39a80-15c2-06a3-85b7-e8cccf54d435@gmail.com> Message-ID: <8d77333d-c8f6-26b6-45b3-9f7f119c9510@gmail.com> On 07/30/2018 03:27 PM, Viktor Dukhovni wrote: > The only time such "leaks" come into play is process exit and library > unload. My advice is to not unload the library and to accept the > fact that a small fixed amount of memory might not be deallocated > at exit. Typically, even "valgrind" will not report "leaks" for > addresses that are still referenced, so the static allocations > are not a problem. > > Spending valuable cycles to eliminate these is not the most productive > use of our time. > How often does a process exit?? Only once.? After a process running for billions of cycles in thousands or millions of loops and whatnot I hardly think the relative few at the end for clean up could remotely be considered "valuable" relative to the total number of cycles executed in life of the process.? Unless you are talking about developer's time and not the processes time.? In which case I still disagree, but it is your time not mine so I won't go there.? I think the forest is being missed for the trees here, but I'm going to bow out as I've said my piece From openssl-users at dukhovni.org Mon Jul 30 20:28:40 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Jul 2018 16:28:40 -0400 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <8d77333d-c8f6-26b6-45b3-9f7f119c9510@gmail.com> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> <80c39a80-15c2-06a3-85b7-e8cccf54d435@gmail.com> <8d77333d-c8f6-26b6-45b3-9f7f119c9510@gmail.com> Message-ID: <555EDF70-DAC8-4FD7-A5F8-8244749D2C4E@dukhovni.org> > On Jul 30, 2018, at 3:43 PM, Marty G wrote: > >> Spending valuable cycles to eliminate these is not the most productive >> use of our time. I meant "developer cycles", not CPU cycles. > How often does a process exit? Only once. -- Viktor. From openssl at jordan.maileater.net Mon Jul 30 23:10:57 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Mon, 30 Jul 2018 16:10:57 -0700 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> <80c39a80-15c2-06a3-85b7-e8cccf54d435@gmail.com> Message-ID: <0488a0f6-7859-0ac5-642e-ab063b87bb81@jordan.maileater.net> On 7/30/2018 12:27 PM, Viktor Dukhovni wrote: > The only time such "leaks" come into play is process exit and library > unload. Process exit is not the only time that libraries get unloaded.? I don't happen to remember any details, but I know we've had problems with libraries that got unloaded because they were dependencies of other shared objects that are intended to be used on a "load, call, unload" basis. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Mon Jul 30 23:17:42 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Mon, 30 Jul 2018 16:17:42 -0700 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> Message-ID: On 7/30/2018 11:12 AM, Michael Wojcik wrote: > As for Jordan's objection: If you don't know the source of your > "leaks", then I can't say I'm particularly impressed with a > zero-"leak" policy. That amounts to "let's burn a lot of cycles during > process termination, rather than understand what we're doing". *Fully* understanding the implications of a bug can be quite difficult.? Often it is much easier to observe that there is a clear bug, fix it, and move along.? Are there cases where this particular leak is a problem?? Just because the developer can't think of any doesn't mean that there are none.? Is it better to spend developer effort proving that a particular leak is harmless, or fixing it? And that doesn't consider the cost to the *next* developer, who runs a leak test, finds a dozen leaks, and then needs to research each one to be sure that it isn't a result of their change. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jul 31 08:59:35 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Jul 2018 09:59:35 +0100 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> Message-ID: <78dfbb09-7bfc-d1fe-7d0a-ddf5ae4a3737@openssl.org> On 30/07/18 19:08, Marty G wrote: > On 07/30/2018 01:27 PM, Salz, Rich via openssl-users wrote: > >> > I never thought I'd see the day that someone would have to defend >> not leaking memory in pivotal security code like openssl however >> >> ? >> >> To be accurate, it was a couple of people saying that memory leaks *on >> process exit* aren?t be a big deal. >> >> ? >> >> > Fair enough, but it is my understanding that some RTOSes do not > necessarily dealloc all memory alloc'd by a proc on proc exit.? So why > not just have a rule "don't litter" instead of having complicated rules > of when it is "probably ok to litter"?? Exploits nearly always leverage > something programmers didn't anticipate or happens in a layer they are > relying on but not directly coding so it seems fairly clear that the > best path is to reduce those unknowns by explicitly cleaning up.? Taking > the time to track down a memory leak rarely results in merely fixing a > memory leak; usually another programming misstep is also found in > conjunction with the leak.? Just my $0.02 > > To be clear I can only think of one leak that we have at process exit (well technically its two instances of the same thing). And that leak is not the result of a *mistake*. It is a deliberate design decision to workaround around a problem on some platforms (i.e. anything that isn't Windows, Linux or Solaris, IIRC). See: https://github.com/openssl/openssl/blob/43a0f2733a943799060ea275516fcce00d89eb38/crypto/init.c#L145-L168 https://github.com/openssl/openssl/blob/43a0f2733a943799060ea275516fcce00d89eb38/crypto/init.c#L720-L739 Any other leaks should hopefully be being caught by our mem leak testing. Matt From ian.bilek at gmail.com Tue Jul 31 10:49:21 2018 From: ian.bilek at gmail.com (Jan Bilek) Date: Tue, 31 Jul 2018 20:49:21 +1000 Subject: [openssl-users] Chinese remainder algorithm Message-ID: Hi all, I need to reconstruct public and private keys for data signing operation from p, q, dmp1, dmq1 and iqmp. When I fill values in as per below then OpenSSL complains about missing d. RSA* pkey = RSA_new(); pkey->n = NULL; pkey->e = NULL; pkey->d = NULL; pkey->p = BN_bin2bn(secureP.data(), secureP.size(), NULL); pkey->q = BN_bin2bn(secureQ.data(), secureQ.size(), NULL); pkey->dmp1 = BN_bin2bn(secureDmp1.data(), secureDmp1.size(), NULL); pkey->dmq1 = BN_bin2bn(secureDmq1.data(), secureDmq1.size(), NULL); pkey->iqmp = BN_bin2bn(secureIqmp.data(), secureIqmp.size(), NULL); I did my homework on Google/Stackoverflow/OpenSSL docu, but I haven't been able to find out any good way to do this, while it is obvious that openssl needs to know this by deafult for its internals. Would you have any hint on where next with this? Thank you, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Jul 31 16:14:18 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 31 Jul 2018 18:14:18 +0200 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <76DDA20E-6704-4913-B045-238561DD80AA@dukhovni.org> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> <76DDA20E-6704-4913-B045-238561DD80AA@dukhovni.org> Message-ID: <33ac87a7-95c0-4b90-9426-b4c72da54ac1@wisemo.com> On 30/07/2018 20:07, Viktor Dukhovni wrote: > >> On Jul 30, 2018, at 12:46 PM, Jordan Brown wrote: >> >> If you can't malloc the space, you probably can't mmap it either. I have never heard of a malloc implementation that has artificial limits; if it's failing it's because it can't find that much contiguous virtual address space, and mmap won't be able to find it either. >> >> If you're a 32-bit process, then malloc'ing or mmap'ing a 2GB object will be difficult at best. > Getting out of the weeds, the core issue is that CMS message input processing > doesn't stream. The entire CMS message has to fit into memory. A different > data format is required for streaming large payloads. The data would need > to be chunked with integrity protection and protection applied to each > chunk (packet) and appropriate sequence number integrity in place to > prevent reordering, insertion or deletion of chunks. > > CMS works fine for small messages, and could even be used to construct > the integrity-protected chunks in a higher-level protocol. CMS is > not appropriate for multi-gigabyte or terabyte, ... datasets. > Actually, the CMS format itself is clearly designed for streamed decoding. For example, it requires the AlgorithmIdentifier of the hash algorithm(s) to precede the signed data, so a streaming implementation can set up the input hashing before knowing the full specification of the signature algorithm(s). A streaming encoder will often need to use the indefinite BER encoding of some of the outer length fields to cope with unknown input length and variably sized fields after the data. 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 christian.boehme at cloudandheat.com Tue Jul 31 16:16:06 2018 From: christian.boehme at cloudandheat.com (=?UTF-8?Q?Christian_B=c3=b6hme?=) Date: Tue, 31 Jul 2018 18:16:06 +0200 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> Message-ID: <65b27675-3029-18a2-fa57-becb807b59c4@cloudandheat.com> On 30.07.2018 20:12, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown >> Sent: Monday, July 30, 2018 10:46 [?] > FWIW, SUS Issue 5 defines RLIMIT_AS as applying to both malloc and mmap, but RLIMIT_DATA as > applying only to malloc. (That is, mmap'd pages do not count against the data limit.) mmap() , by defninition, populates the process' virtual address space, and if that is limited in size, artificially or not, then the call is going to fail, eventually. >> If you're a 32-bit process, then malloc'ing or mmap'ing a 2GB object will be difficult at best. > > Agreed. And I'm not endorsing the mmap approach for this problem anyway - I'd use a streaming > approach, so I'm not limited by address space. Let's look at the following message that was produced by symmetrically encrypting 757 plaintext octets using the Camellia cipher in CBC mode with a 256 bit key derived from a passphrase: $ cat ciphertext.pem | openssl asn1parse -i -inform PEM 0:d=0 hl=4 l= 978 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData 15:d=1 hl=4 l= 963 cons: cont [ 0 ] 19:d=2 hl=4 l= 959 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :03 26:d=3 hl=3 l= 133 cons: SET 29:d=4 hl=3 l= 130 cons: cont [ 3 ] 32:d=5 hl=2 l= 1 prim: INTEGER :00 35:d=5 hl=2 l= 27 cons: cont [ 0 ] 37:d=6 hl=2 l= 9 prim: OBJECT :PBKDF2 48:d=6 hl=2 l= 14 cons: SEQUENCE 50:d=7 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:948BAC4CEDB23DE2 60:d=7 hl=2 l= 2 prim: INTEGER :0800 64:d=5 hl=2 l= 46 cons: SEQUENCE 66:d=6 hl=2 l= 11 prim: OBJECT :id-alg-PWRI-KEK 79:d=6 hl=2 l= 31 cons: SEQUENCE 81:d=7 hl=2 l= 11 prim: OBJECT :camellia-256-cbc 94:d=7 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:D7A2F88C99A1881C1B8B6AA9E2BDD002 112:d=5 hl=2 l= 48 prim: OCTET STRING [HEX DUMP]:445771F0EA6BAA64CAF35BFC2DA546845C? 162:d=3 hl=4 l= 816 cons: SEQUENCE 166:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 177:d=4 hl=2 l= 31 cons: SEQUENCE 179:d=5 hl=2 l= 11 prim: OBJECT :camellia-256-cbc 192:d=5 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:4F8DAFF8EE165FD78C35A644735CD082 210:d=4 hl=4 l= 768 prim: cont [ 0 ] This structure, if held in a regular file, can be processed quite non-linearly, and without mmap()'ing its entire contents. The only parts that are going to grow as the plaintext grows are the ciphertext (index 192 above) and, to a lesser extend, the ones that depend on key sizes in the recipientInfos and the length components. Once the overall structure of the message is understood, sequential processing of the ciphertext should pose no problem, whichever way implemented. The pure streaming approach may be appropriate for file descriptors that are not seekable like sockets, pipes, tty ends etcpp., whereas with egular files, random access schemes using either pread(v)(2) or lseek(2) in combination with read(v)(2) can be employed. Portability is certainly an issue, but isn't this what the configure scripts are for to figure out? I also do not quite get why CMS should not lend itself to "large" data, given the above. It would seem that the whole point of the definite TLV structures is to be able to learn the type and size requirements of the data to come in the stream /before/ processing it, allowing the "processor" to take appropriate measures, and not necessarily in RAM alone. Thanks, Christian -- *Christian B?hme* Developer System Integration CLOUD&HEAT *CLOUD & HEAT Technologies GmbH* K?nigsbr?cker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: christian.boehme at cloudandheat.com Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Gesch?ftsf?hrer: Nicolas R?hrs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: OpenPGP digital signature URL: From jb-openssl at wisemo.com Tue Jul 31 16:27:10 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 31 Jul 2018 18:27:10 +0200 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <0488a0f6-7859-0ac5-642e-ab063b87bb81@jordan.maileater.net> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> <80c39a80-15c2-06a3-85b7-e8cccf54d435@gmail.com> <0488a0f6-7859-0ac5-642e-ab063b87bb81@jordan.maileater.net> Message-ID: <06cabc78-4f69-4964-c8f1-d9af92418e25@wisemo.com> On 31/07/2018 01:10, Jordan Brown wrote: > On 7/30/2018 12:27 PM, Viktor Dukhovni wrote: >> The only time such "leaks" come into play is process exit and library >> unload. > > Process exit is not the only time that libraries get unloaded.? I > don't happen to remember any details, but I know we've had problems > with libraries that got unloaded because they were dependencies of > other shared objects that are intended to be used on a "load, call, > unload" basis. > And *this* is the reason why having a common library like OpenSSL or libc refuse to get unloaded on the fly is such a horrible idea. I still recall the problems when (decades ago) Borland added such anti-unload code to some of their compiler-bundled libraries. There are processes that naturally run for a lot longer than the library-format plugins inside them, and it is highly valuable to end users to be able to upgrade those plugins on the fly without restarting the long-lived container, with all the other state it holds. 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 KHenderson at verisign.com Tue Jul 31 21:08:55 2018 From: KHenderson at verisign.com (Henderson, Karl) Date: Tue, 31 Jul 2018 21:08:55 +0000 Subject: [openssl-users] unknown cipher? Message-ID: Hi All, I?m a bit confused. We?re trying to get some number of the relative efficiency of different cypher algorithms using the openssl tool. When I type: openssl ciphers -tls1_3 -stdname -V I see this as one of the results: 0x13,0x02 - TLS_AES_256_GCM_SHA384 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD However, when I try to do a speed test on this algorithm openssl speed -evp TLS_AES_256_GCM_SHA384 speed: TLS_AES_256_GCM_SHA384 is an unknown cipher or digest What am I missing? Thanks, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: