From florin at andrei.myip.org Thu Jun 1 01:58:16 2017 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 31 May 2017 18:58:16 -0700 Subject: [openssl-users] =?utf-8?q?SSL_error_=E2=80=9Cinappropriate_fallba?= =?utf-8?b?Y2vigJ0gYW5kIFRMU19GQUxMQkFDS19TQ1NW?= Message-ID: <0527d6de5ed6bea7cbbdb908bfc51b41@andrei.myip.org> A bit of context: I have this endpoint behind an AWS ALB. I do SSL termination at the ALB. To my surprise, when looking at the client_tlsnegotiation_error_count metric for the ALB, I've noticed a substantial amount of failed connection attempts due to TLS negotiation errors - perhaps around 5% of total traffic but this estimate could be wrong by a substantial margin. The clients are mostly an average cross-section of current mobile devices in use these days in the US. The ALB is configured with the default TLS policy that Amazon provides: | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server |_ least strength: A Unfortunately, ALBs do not provide error logs, so I could not directly identify why some clients are failing the SSL negotiation. Instead, I've pushed SSL termination deeper into the stack, to the Nginx frontend, and replaced the ALB with a plain TCP-based ELB. Now connections to port 443 are forwarded directly to Nginx for SSL negotiation. I've configured Nginx with the exact same protocol versions and ciphers like the ALB: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA'; ssl_prefer_server_ciphers on; I've verified with nmap and I get the same ssl-enum-ciphers list from Nginx. Now in the Nginx error log I get lots of lines like this: SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:ssl_bytes_to_cipher_list:inappropriate fallback) while SSL handshaking Still not very informative, so I've run tcpdump on port 443 on the Nginx instances. As expected, there's some amount of SSL errors like this: Secure Sockets Layer TLSv1 Record Layer: Alert (Level: Fatal, Description: Inappropriate Fallback) Content Type: Alert (21) Version: TLS 1.0 (0x0301) Length: 2 Alert Message Level: Fatal (2) Description: Inappropriate Fallback (86) In that same TCP stream there's this Client Hello packet: Secure Sockets Layer TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 165 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 161 Version: TLS 1.0 (0x0301) Random GMT Unix Time: Jun 7, 2050 12:50:05.000000000 PST Random Bytes: da03ff7045a5f76e78edf61c097c75e4e141df6649ef1861... Session ID Length: 0 Cipher Suites Length: 28 Cipher Suites (14 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_FALLBACK_SCSV (0x5600) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 92 Extension: renegotiation_info Type: renegotiation_info (0xff01) Length: 1 Renegotiation Info extension Renegotiation info extension length: 0 Extension: server_name Type: server_name (0x0000) Length: 27 Server Name Indication extension Server Name list length: 25 Server Name Type: host_name (0) Server Name length: 22 Server Name: [REDACTED] Extension: Extended Master Secret Type: Extended Master Secret (0x0017) Length: 0 Extension: SessionTicket TLS Type: SessionTicket TLS (0x0023) Length: 0 Data (0 bytes) Extension: Application Layer Protocol Negotiation Type: Application Layer Protocol Negotiation (0x0010) Length: 26 ALPN Extension Length: 24 ALPN Protocol ALPN string length: 5 ALPN Next Protocol: h2-16 ALPN string length: 8 ALPN Next Protocol: spdy/3.1 ALPN string length: 8 ALPN Next Protocol: http/1.1 Extension: ec_point_formats Type: ec_point_formats (0x000b) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: elliptic_curves Type: elliptic_curves (0x000a) Length: 8 Elliptic Curves Length: 6 Elliptic curves (3 curves) Elliptic curve: secp256r1 (0x0017) Elliptic curve: secp384r1 (0x0018) Elliptic curve: secp521r1 (0x0019) It's a little puzzling because the exchange of crypto messages uses TLS 1.0 which the server definitely supports, and the client should be very likely to support too. I've seen discussions online saying that the presence of the TLS_FALLBACK_SCSV cipher suite is an indication that this failed connection is related to anti-POODLE security measures, and the communication is likely to be retried again. Is that correct? For the most part, what I'm trying to do is find the answers to these questions: 1. Is this bad? If yes, why? (what are the things that the clients need that the endpoint is not providing) 2. If it's not bad, then why do we get this constant stream of SSL errors? It's a little difficult to search the capture file and try to correlate the failed SSL handshake with other, successful connections, because the source IPs are masked by the ELB. There might be a way to rely on the PROXY protocol header to identify IPs, but I'll have to figure out how to do that. -- Florin Andrei http://florin.myip.org/ From hrf-ssl at itg.hitachi.co.jp Thu Jun 1 08:14:32 2017 From: hrf-ssl at itg.hitachi.co.jp (=?utf-8?B?5YWx6YCa5Z+655uk77yz77yz77ys77y75qWt5YuZ77yp77yk77y9IC8gQ09N?= =?utf-8?B?TU9OU1NM77yMR1lPVU1V?=) Date: Thu, 1 Jun 2017 08:14:32 +0000 Subject: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems In-Reply-To: <4DF90FD0-08D2-49F0-81B0-F3201DB7AEA5@pobox.com> References: <15CFFC2F2156164FA093C04D7DB5BFB322D74268@GSjpTK1DCembx01.service.hitachi.net> <544aff21-4552-ea94-61e1-257f87a19f50@pobox.com> <4DF90FD0-08D2-49F0-81B0-F3201DB7AEA5@pobox.com> Message-ID: <15CFFC2F2156164FA093C04D7DB5BFB3659D82B3@GSjpTK1DCembx02.service.hitachi.net> Hello All. Sorry for the late reply. I understood. Thank you very much. Best regards, and I'll try that. Manabu > On May 12, 2017, at 5:00 PM, Michael Wojcik > wrote: > > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > >> Behalf Of Thomas Francis, Jr. > >> Sent: Friday, May 12, 2017 15:55 > >> > >>> On 5/10/17 3:55 AM, ????????????? / COMMONSSL?GYOUMU > wrote: > >>> > >>> I will build OpenSSL on SUSE Linux Enterprise Server for z Systems. > > > > What version of OpenSSL? > > > >>> But, there is not yet the machine for build, so I cannot do actual > >>> machine verification. > >>> > >>> The CPU is not Intel architecture, is probably z/Architecture. > > > > Yes, Linux for System z runs on z-architecture CPUs. > > > >>> I want to know beforehand the appropriate command-line parameters > >>> for executing "Configure". > >>> > >>> Is it right to specify "linux64-s390x" as follows? > >>> > >>> (1)cd //openssl-1.0.2k > >>> > >>> (2)./Configure linux64-s390x > >> > >> I'd suggest just running "./config". That will pick the appropriate > >> 64-bit target. Only use Configure if you want to do something > >> non-standard. :) > > > > That's certainly the place to start. Whether it will work is another > question. > > > > When we build OpenSSL for z Linux (RHEL and SLES), we use a modified > Configure that: > > > > * Adds -fPIC and -mbackchain. This is because we compile OpenSSL into > an archive library that is then linked into a shared object, so we have > to force on the shared-object flags in Configure. > > > > * Replaces -O3 with -O1, preferring robustness (or, if you prefer, > toleration for sloppiness and error) and ease of problem determination over > performance. > > > > * Replaces the asm setting[1] with ${no_asm}, for the same reason. > > > > * For 32-bit, removes /highgprs. According to my notes, highgprs does > not work correctly with some glibc versions on zLinux. > > > > The OP probably doesn't need the first three and may well not need the > last. Depending on how clever one gets with building and using OpenSSL, > though, config+Configure aren't always sufficient as supplied. That's not > a criticism - trying to accommodate every use case is not a good use of > the OpenSSL development team's time. > > > > But unless you're happy with the default build parameters and comfortable > with your platform, be prepared to learn how the OpenSSL build works. > > I think in general, the same caveat applies for any system. The default > build settings might not be what you want. But in most cases (including > Linux for z), they will get you libraries that'll work with the system > compiler toolchain if you pass only the minimum flags to specify where the > headers and libraries can be found. > > I figure if you need something else you probably already know that, and > can pass the appropriate flags in CFLAGS, CPPFLAGS, or LDFLAGS. :) Or create > a custom target. > > TOM > > PS Regarding highgprs; I suspect that's actually a problem of mixing 32-bit > s390x binaries with s390 binaries. There is a difference. But old bugs > and miscommunication means that sometimes the s390 system will think it > can load an s390x binary (and sometimes think it succeeded). :) > > > [1] There are two zLinux targets in the 1.0.2 Configure, for 64- and 32-bit. > The linux64-s390x target uses ${s390x_asm} for its asm section, but the > linux32-s90x uses an eval expression that edits $s390x_asm. We disable asm > for both. > > > > > > Michael Wojcik > > Distinguished Engineer, Micro Focus From matt at openssl.org Thu Jun 1 09:13:48 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Jun 2017 10:13:48 +0100 Subject: [openssl-users] =?utf-8?q?SSL_error_=E2=80=9Cinappropriate_fallba?= =?utf-8?b?Y2vigJ0gYW5kIFRMU19GQUxMQkFDS19TQ1NW?= In-Reply-To: <0527d6de5ed6bea7cbbdb908bfc51b41@andrei.myip.org> References: <0527d6de5ed6bea7cbbdb908bfc51b41@andrei.myip.org> Message-ID: On 01/06/17 02:58, Florin Andrei wrote: > It's a little puzzling because the exchange of crypto messages uses TLS > 1.0 which the server definitely supports, and the client should be very > likely to support too. > > I've seen discussions online saying that the presence of the > TLS_FALLBACK_SCSV cipher suite is an indication that this failed > connection is related to anti-POODLE security measures, and the > communication is likely to be retried again. Is that correct? "Normal" TLS version negotiation works like this (ignoring TLSv1.3 which isn't relevant for this discussion): the client sends the maximum TLS version that it supports in its ClientHello message (this should not be confused with the version number in the record header). The server responds with a ServerHello containing the maximum version that it supports and which is less than or equal to the client's maximum version number. For example, if the client supports TLSv1.2 but the server only supports TLSv1.0, then the ClientHello version will be TLSv1.2 and the server will respond with TLSv1.0. On the other hand if the client only supports TLSv1.0 but the server supports TLSv1.2, then the ClientHello version will be TLSv1.0 and the ServerHello version will also be TLSv1.0. This is all fine but there are some servers out there which are buggy and abort the connection if the ClientHello version is bigger than the maximum version that the server supports. To work around this some clients will do "fallback". So, they start with a ClientHello version of TLSv1.2. If the connection aborts then they might send another one with a version of TLSv1.1. If that aborts then TLSv1.0. The problem with that approach is that it can be exploited by an attacker. An attacker may be able to exploit some weakness in an earlier TLS version which is fixed in a later version. The attacker may then be able to modify the traffic to ensure that a TLSv1.2 ClientHello fails in order to force the client to fallback to the earlier exploitable version. The TLS_FALLBACK_SCSV ciphersuite is used as a counter measure to that type of attack. A client will include it if it is sending a ClientHello with a max version that is lower than the maximum that the client actually supports (because an earlier attempt with the higher version number failed). If a server receives a TLS_FALLBACK_SCSV ciphersuite in a ClientHello and it supports a higher version than the one in the ClientHello then there should have been no reason for the client to fallback and you get the "inappropriate fallback" error. The presence of this error doesn't actually mean that you are under attack. It just means that the client made an earlier connection attempt with a higher version number and it failed. There could be many reasons for the failure. For example, plausibly, if you have a lot of mobile clients then you could imagine that a network glitch could cause an earlier attempt to fail. Matt From matt at openssl.org Thu Jun 1 09:41:55 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Jun 2017 10:41:55 +0100 Subject: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e? In-Reply-To: References: Message-ID: <3cbfba7f-b1e0-72d7-2938-6f27cb13e3d4@openssl.org> On 31/05/17 21:22, Siyuan Xiang wrote: > Hi all, > > I have a legacy server only accept TLS_RSA_WITH_RC4_128_MD5 cipher. > > I have a client using openssl 1.1.0e. It doesn't include > TLS_RSA_WITH_RC4_128_MD5. > I have recompiled the openssl using enable-weak-ssl-ciphers, but it > doesn't work > but TLS_RSA_WITH_RC4_128_SHA is in client hello message. > > It looks like all MD5 related ciphers are removed. I tried to > use SSL_CTX_set_security_level to > set level to 0. but it doesn't work. > > Do you have any idea how to enable TLS_RSA_WITH_RC4_128_MD5? How have you configured your ciphersuite list? I can get this to work in 1.1.0 using s_server and s_client. Having built with "enable-weak-ssl-ciphers" I start up s_server like this: $ openssl s_server -cipher "RC4-MD5:@SECLEVEL=0" And then run s_client like this: $ openssl s_client -cipher "RC4-MD5:@SECLEVEL=0" The connection is successful and uses the RC4-MD5 ciphersuite (aka TLS_RSA_WITH_RC4_128_MD5). Matt From soryy708 at gmail.com Thu Jun 1 10:15:13 2017 From: soryy708 at gmail.com (Ivan Rubinson) Date: Thu, 1 Jun 2017 13:15:13 +0300 Subject: [openssl-users] Making a CRL with an authority key identifier Message-ID: Hello, My name is Ivan, and I'm trying to get OpenSSL to make a CRL with an authority key identifier. (a third party API expects it from the CRL) I make my own CA, use it to sign a certificate, and then generate the CRL. This is the configuration file: https://pastebin.com/yL4UBtGW (it's basically the example configuration file with a few changes). Here are the commands I run: Making the CA: > openssl req -new -x509 -days 3650 -extensions v3_ca -keyout > private/cakey.pem -out cacert.pem -config req.cnf > Making the certificate: > openssl req -new -nodes -out pdf-req.pem -keyout private/pdf-pkey.pem > -config req.cnf > openssl ca -config req.cnf -out pdf-cert.pem -infiles pdf-req.pem > Making the CRL: > openssl ca -config req.cnf -gencrl -out crl.pem > I'm using OpenSSL-Win64 0.9.8g Even though on line 251 I ask OpenSSL to have an authority key identifier, the generated CRL doesn't have it. I've searched on google and tried multiple things (like uncommenting issuerAltName, or giving it different options) and the CRL still doesn't have it. At this point I'm stumped, and I'd like to ask you nice people for help. Thank you in advance, Ivan Rubinson Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin_ja at camerfirma.com Thu Jun 1 10:22:19 2017 From: martin_ja at camerfirma.com (Juan Angel Martin (AC Camerfirma)) Date: Thu, 1 Jun 2017 12:22:19 +0200 Subject: [openssl-users] Making a CRL with an authority key identifier In-Reply-To: References: Message-ID: <082e01d2dac0$f3673910$da35ab30$@camerfirma.com> Hi, Uncomment line 54 crl_extensions = crl_ext BR Juan ?ngel De: openssl-users [mailto:openssl-users-bounces at openssl.org] En nombre de Ivan Rubinson Enviado el: jueves, 1 de junio de 2017 12:15 Para: openssl-users at openssl.org Asunto: [openssl-users] Making a CRL with an authority key identifier Hello, My name is Ivan, and I'm trying to get OpenSSL to make a CRL with an authority key identifier. (a third party API expects it from the CRL) I make my own CA, use it to sign a certificate, and then generate the CRL. This is the configuration file: https://pastebin.com/yL4UBtGW (it's basically the example configuration file with a few changes). Here are the commands I run: Making the CA: openssl req -new -x509 -days 3650 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -config req.cnf Making the certificate: openssl req -new -nodes -out pdf-req.pem -keyout private/pdf-pkey.pem -config req.cnf openssl ca -config req.cnf -out pdf-cert.pem -infiles pdf-req.pem Making the CRL: openssl ca -config req.cnf -gencrl -out crl.pem I'm using OpenSSL-Win64 0.9.8g Even though on line 251 I ask OpenSSL to have an authority key identifier, the generated CRL doesn't have it. I've searched on google and tried multiple things (like uncommenting issuerAltName, or giving it different options) and the CRL still doesn't have it. At this point I'm stumped, and I'd like to ask you nice people for help. Thank you in advance, Ivan Rubinson Virus-free. www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5926 bytes Desc: not available URL: From soryy708 at gmail.com Thu Jun 1 10:31:54 2017 From: soryy708 at gmail.com (Ivan Rubinson) Date: Thu, 1 Jun 2017 13:31:54 +0300 Subject: [openssl-users] Making a CRL with an authority key identifier In-Reply-To: <082e01d2dac0$f3673910$da35ab30$@camerfirma.com> References: <082e01d2dac0$f3673910$da35ab30$@camerfirma.com> Message-ID: Aha, I can't believe I missed that. That's why an extra pair of fresh eyes is helpful. Thank you Juan. I'll test this now. On Thu, Jun 1, 2017 at 1:22 PM, Juan Angel Martin (AC Camerfirma) < martin_ja at camerfirma.com> wrote: > Hi, > > > > Uncomment line 54 > > crl_extensions = crl_ext > > > > BR > > Juan ?ngel > > > > *De:* openssl-users [mailto:openssl-users-bounces at openssl.org] *En nombre > de *Ivan Rubinson > *Enviado el:* jueves, 1 de junio de 2017 12:15 > *Para:* openssl-users at openssl.org > *Asunto:* [openssl-users] Making a CRL with an authority key identifier > > > > Hello, > > My name is Ivan, and I'm trying to get OpenSSL to make a CRL with an > authority key identifier. > > (a third party API expects it from the CRL) > > I make my own CA, use it to sign a certificate, and then generate the CRL. > This is the configuration file: https://pastebin.com/yL4UBtGW (it's > basically the example configuration file with a few changes). > > Here are the commands I run: > > Making the CA: > > openssl req -new -x509 -days 3650 -extensions v3_ca -keyout > private/cakey.pem -out cacert.pem -config req.cnf > > Making the certificate: > > openssl req -new -nodes -out pdf-req.pem -keyout private/pdf-pkey.pem > -config req.cnf > openssl ca -config req.cnf -out pdf-cert.pem -infiles pdf-req.pem > > Making the CRL: > > openssl ca -config req.cnf -gencrl -out crl.pem > > > > I'm using OpenSSL-Win64 0.9.8g > > Even though on line 251 I ask OpenSSL to have an authority key identifier, > the generated CRL doesn't have it. I've searched on google and tried > multiple things (like uncommenting issuerAltName, or giving it different > options) and the CRL still doesn't have it. > > At this point I'm stumped, and I'd like to ask you nice people for help. > > Thank you in advance, > > Ivan Rubinson > > > > > > > Virus-free. www.avast.com > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jun 1 10:42:19 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Jun 2017 11:42:19 +0100 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> Message-ID: <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> On 25/05/17 15:29, Dennis Clarke wrote: > > So this is exclusively a change to support mingw64 ? Sorry, I missed this email somehow. This release rolls up numerous bug fixes that have been implemented since the last release. We only put particularly significant items in CHANGES. Matt > > That seems to be all that is said here : > > https://www.openssl.org/news/cl102.txt > > > > OpenSSL CHANGES > _______________ > > Changes between 1.0.2l and 1.0.2m [xx XXX xxxx] > > *) > > Changes between 1.0.2k and 1.0.2l [25 May 2017] > > *) Have 'config' recognise 64-bit mingw and choose 'mingw64' as the > target > platform rather than 'mingw'. > [Richard Levitte] > > > . > . > . > > > Dennis Clarke From dclarke at blastwave.org Thu Jun 1 13:35:13 2017 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 1 Jun 2017 09:35:13 -0400 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> Message-ID: <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> On 06/01/2017 06:42 AM, Matt Caswell wrote: > > > On 25/05/17 15:29, Dennis Clarke wrote: >> >> So this is exclusively a change to support mingw64 ? > > Sorry, I missed this email somehow. This release rolls up numerous bug > fixes that have been implemented since the last release. We only put > particularly significant items in CHANGES. > One of the curious things I do ( there are numerous it seems ) is to sometimes run a "catalog" process on a source tree where I get the file list and the sha256 hash of every file. Then compare with the previous release. There are a lot of differences. A lot. I can then "diff" for my own reasons of curiosity. So the CHANGES file isn't really "changes". Dennis Clarke From soryy708 at gmail.com Thu Jun 1 13:35:22 2017 From: soryy708 at gmail.com (Ivan Rubinson) Date: Thu, 1 Jun 2017 16:35:22 +0300 Subject: [openssl-users] Making a CRL with an authority key identifier In-Reply-To: References: <082e01d2dac0$f3673910$da35ab30$@camerfirma.com> Message-ID: Yep, that solved it. Thank you very much. On Thu, Jun 1, 2017 at 1:31 PM, Ivan Rubinson wrote: > Aha, I can't believe I missed that. > That's why an extra pair of fresh eyes is helpful. > Thank you Juan. I'll test this now. > > On Thu, Jun 1, 2017 at 1:22 PM, Juan Angel Martin (AC Camerfirma) < > martin_ja at camerfirma.com> wrote: > >> Hi, >> >> >> >> Uncomment line 54 >> >> crl_extensions = crl_ext >> >> >> >> BR >> >> Juan ?ngel >> >> >> >> *De:* openssl-users [mailto:openssl-users-bounces at openssl.org] *En >> nombre de *Ivan Rubinson >> *Enviado el:* jueves, 1 de junio de 2017 12:15 >> *Para:* openssl-users at openssl.org >> *Asunto:* [openssl-users] Making a CRL with an authority key identifier >> >> >> >> Hello, >> >> My name is Ivan, and I'm trying to get OpenSSL to make a CRL with an >> authority key identifier. >> >> (a third party API expects it from the CRL) >> >> I make my own CA, use it to sign a certificate, and then generate the >> CRL. This is the configuration file: https://pastebin.com/yL4UBtGW (it's >> basically the example configuration file with a few changes). >> >> Here are the commands I run: >> >> Making the CA: >> >> openssl req -new -x509 -days 3650 -extensions v3_ca -keyout >> private/cakey.pem -out cacert.pem -config req.cnf >> >> Making the certificate: >> >> openssl req -new -nodes -out pdf-req.pem -keyout private/pdf-pkey.pem >> -config req.cnf >> openssl ca -config req.cnf -out pdf-cert.pem -infiles pdf-req.pem >> >> Making the CRL: >> >> openssl ca -config req.cnf -gencrl -out crl.pem >> >> >> >> I'm using OpenSSL-Win64 0.9.8g >> >> Even though on line 251 I ask OpenSSL to have an authority key >> identifier, the generated CRL doesn't have it. I've searched on google and >> tried multiple things (like uncommenting issuerAltName, or giving it >> different options) and the CRL still doesn't have it. >> >> At this point I'm stumped, and I'd like to ask you nice people for help. >> >> Thank you in advance, >> >> Ivan Rubinson >> >> >> >> >> >> >> Virus-free. www.avast.com >> >> >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jun 1 13:53:47 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Jun 2017 13:53:47 +0000 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> Message-ID: <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> > So the CHANGES file isn't really "changes". The full list of everything that has changed can be found via git logs. As Matt said, we only put particularly significant items in the CHANGES file. From dclarke at blastwave.org Thu Jun 1 14:17:28 2017 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 1 Jun 2017 10:17:28 -0400 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> On 06/01/2017 09:53 AM, Salz, Rich via openssl-users wrote: >> So the CHANGES file isn't really "changes". > > The full list of everything that has changed can be found via git logs. As Matt said, we only put particularly significant items in the CHANGES file. > > Why? Why isn't the list of changes dumped into a simple text file and included in the source release tarball ? Consider users and systems which do not have git installed by default. For that matter, git does not exist or even compile on those target systems but openssl most certainly does. Dennis From matt at openssl.org Thu Jun 1 14:23:58 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Jun 2017 15:23:58 +0100 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> Message-ID: <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> On 01/06/17 15:17, Dennis Clarke wrote: > On 06/01/2017 09:53 AM, Salz, Rich via openssl-users wrote: >>> So the CHANGES file isn't really "changes". >> >> The full list of everything that has changed can be found via git >> logs. As Matt said, we only put particularly significant items in the >> CHANGES file. >> >> > > Why? > > Why isn't the list of changes dumped into a simple text file and > included in the source release tarball ? Consider users and systems > which do not have git installed by default. For that matter, git does > not exist or even compile on those target systems but openssl most > certainly does. They are easily obtainable even if you do not have git. The list for 1.0.2l is here: https://github.com/openssl/openssl/commits/OpenSSL_1_0_2l Matt From lvic4594 at gmail.com Thu Jun 1 14:26:40 2017 From: lvic4594 at gmail.com (l vic) Date: Thu, 1 Jun 2017 10:26:40 -0400 Subject: [openssl-users] CSR with multiple subject names? Message-ID: I am working with service with TLS authn that uses subject name to authenticate client. Is it possible to use list of subject names in client certificate so that service could authenticate several clients with the same key/certificate? If not, would it be possible to use alternative subject names for the same purpose? Can SANs only used in the context of DNS domains, eg to authenticate the same subject name calling from different DNS domains? Thank you, lvic -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Thu Jun 1 14:32:36 2017 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 1 Jun 2017 10:32:36 -0400 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> Message-ID: <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> > They are easily obtainable even if you do not have git. The list for > 1.0.2l is here: > > https://github.com/openssl/openssl/commits/OpenSSL_1_0_2l ( point missed ) The issue is that the CHANGES file simply isn't. The most recent for 1.0.2l being truely spartan. If this were vim or perhaps nano or even grep then I would go digging. However in these times of ever more security concerns for our servers I feel[1] that the openssl source release should at least have a trivial text list with more data than this : sedna$ git diff --stat --color OpenSSL_1_0_2l..OpenSSL_1_0_2k .travis.yml | 1 + CHANGES | 6 - Configure | 19 +- LICENSE | 4 +- Makefile.org | 8 - NEWS | 4 - README | 2 +- TABLE | 58 +-- apps/ca.c | 19 +- apps/dhparam.c | 24 +- apps/enc.c | 33 +- apps/engine.c | 9 +- apps/pkeyutl.c | 4 +- apps/prime.c | 3 - apps/progs.h | 2 +- apps/progs.pl | 30 +- apps/req.c | 6 +- apps/s_client.c | 1 - apps/s_server.c | 1 - apps/srp.c | 4 +- appveyor.yml | 8 + config | 9 - crypto/aes/Makefile | 2 +- crypto/aes/asm/aesni-sha1-x86_64.pl | 1 - crypto/aes/asm/aesni-sha256-x86_64.pl | 1 - crypto/aes/asm/bsaes-armv7.pl | 2 +- . . etc etc . util/domd | 6 +- util/mk1mf.pl | 1 - 148 files changed, 756 insertions(+), 1520 deletions(-) sedna$ Dennis [1] yes I used the word "feel" here and it it a weak argument to be sure From matt at openssl.org Thu Jun 1 14:40:36 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Jun 2017 15:40:36 +0100 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> Message-ID: <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> On 01/06/17 15:32, Dennis Clarke wrote: > >> They are easily obtainable even if you do not have git. The list for >> 1.0.2l is here: >> >> https://github.com/openssl/openssl/commits/OpenSSL_1_0_2l > > ( point missed ) > > The issue is that the CHANGES file simply isn't. The most recent for > 1.0.2l being truely spartan. If this were vim or perhaps nano or even > grep then I would go digging. However in these times of ever more > security concerns for our servers I feel[1] that the openssl source > release should at least have a trivial text list with more data than this : CHANGES is what it is - a list of changes we thought were particularly worthy of note. If that's not enough information for you then use the git logs. I see very little value in automatically extracting info out of the logs and including it in the distribution when the logs are so easily accessible elsewhere. Matt From rsalz at akamai.com Thu Jun 1 15:25:22 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Jun 2017 15:25:22 +0000 Subject: [openssl-users] CSR with multiple subject names? In-Reply-To: References: Message-ID: By default, TLS only does server-side verification. If you are using client certificates, you will have to write some code for your application. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiangsiyuan at gmail.com Thu Jun 1 17:16:01 2017 From: xiangsiyuan at gmail.com (Siyuan Xiang) Date: Thu, 1 Jun 2017 10:16:01 -0700 Subject: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e? In-Reply-To: <3cbfba7f-b1e0-72d7-2938-6f27cb13e3d4@openssl.org> References: <3cbfba7f-b1e0-72d7-2938-6f27cb13e3d4@openssl.org> Message-ID: Hi Matt, I tried the following command, it failed. following is my command. ./config enable-weak-ssl-ciphers --prefix=/opt make make DESTDIR=/path/to/dir INSTALL $ ./openssl version OpenSSL 1.1.0e 16 Feb 2017 ./openssl s_client -cipher "RC4-MD5:@SECLEVEL=0" error setting cipher list 140369010624144:error:140E6118:SSL routines:SSL_CIPHER_PROCESS_RULESTR:invalid command:ssl_ciph.c:1337: ./openssl ciphers "RC4-MD5:@SECLEVEL=0" Error in cipher list 140458428679936:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2018: However, after I change SSL_CTX_set_XXX function orders, TLS_RSA_WITH_RC4_128_MD5 do appear in client hello cipher list. SSL_CTX_set_security_level(ctx, 0); SSL_CTX_set_cipher_list(ctx, "ALL:RC4-MD5"); Regards, Siyuan --- On Thu, Jun 1, 2017 at 2:41 AM, Matt Caswell wrote: > > > On 31/05/17 21:22, Siyuan Xiang wrote: > > Hi all, > > > > I have a legacy server only accept TLS_RSA_WITH_RC4_128_MD5 cipher. > > > > I have a client using openssl 1.1.0e. It doesn't include > > TLS_RSA_WITH_RC4_128_MD5. > > I have recompiled the openssl using enable-weak-ssl-ciphers, but it > > doesn't work > > but TLS_RSA_WITH_RC4_128_SHA is in client hello message. > > > > It looks like all MD5 related ciphers are removed. I tried to > > use SSL_CTX_set_security_level to > > set level to 0. but it doesn't work. > > > > Do you have any idea how to enable TLS_RSA_WITH_RC4_128_MD5? > > How have you configured your ciphersuite list? I can get this to work in > 1.1.0 using s_server and s_client. > > Having built with "enable-weak-ssl-ciphers" I start up s_server like this: > > $ openssl s_server -cipher "RC4-MD5:@SECLEVEL=0" > > And then run s_client like this: > > $ openssl s_client -cipher "RC4-MD5:@SECLEVEL=0" > > The connection is successful and uses the RC4-MD5 ciphersuite (aka > TLS_RSA_WITH_RC4_128_MD5). > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.verhelst at fedict.be Thu Jun 1 14:54:09 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Thu, 1 Jun 2017 16:54:09 +0200 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> Message-ID: <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> On 01-06-17 16:40, Matt Caswell wrote: > CHANGES is what it is - a list of changes we thought were particularly > worthy of note. If that's not enough information for you then use the > git logs. I see very little value in automatically extracting info out > of the logs and including it in the distribution when the logs are so > easily accessible elsewhere. It might be useful to make that point at the start of the CHANGES file, then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy [date]". While that doesn't claim to be complete, the simple word "CHANGES" invokes the idea of a changelog, which should be complete -- and this file is not. If it's not meant to be, fine -- but then it doesn't hurt to say so, and it would alleviate some confusion. Thanks, -- Wouter Verhelst From florin at andrei.myip.org Thu Jun 1 18:37:55 2017 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 01 Jun 2017 11:37:55 -0700 Subject: [openssl-users] =?utf-8?q?SSL_error_=E2=80=9Cinappropriate_fallba?= =?utf-8?b?Y2vigJ0gYW5kIFRMU19GQUxMQkFDS19TQ1NW?= In-Reply-To: References: <0527d6de5ed6bea7cbbdb908bfc51b41@andrei.myip.org> Message-ID: On 2017-06-01 02:13, Matt Caswell wrote: > > The presence of this error doesn't actually mean that you are under > attack. It just means that the client made an earlier connection > attempt > with a higher version number and it failed. There could be many reasons > for the failure. For example, plausibly, if you have a lot of mobile > clients then you could imagine that a network glitch could cause an > earlier attempt to fail. It's interesting how I see a constant stream of ?inappropriate fallback? errors in the logs, but this is pretty much the only error from a TLS perspective. Sure, there's the occasional certificate failure, like once every few minutes or so, and then, rarely, there's some ancient app trying SSLv3 (which is not enabled). But looking at the Nginx error.log the ?inappropriate fallback? is basically the only error I get a perpetual flow of. If the TLS_FALLBACK_SCSV attempt is caused by a previously failed connection, that must have been something different from a TLS error, because ?inappropriate fallback? is probably over 99% of the lines in error.log - it's the only thing I see as logs are scrolling up in my viewer. Would clients actually attempt to send TLS_FALLBACK_SCSV even if the previous connection attempt failed for reasons other than TLS? If, say, the initial connection attempt failed at the TCP level? That sounds a little strange to me. Again, our clients are a mix of the average mobile devices in general use these days. -- Florin Andrei http://florin.myip.org/ From rsalz at akamai.com Thu Jun 1 18:43:31 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Jun 2017 18:43:31 +0000 Subject: [openssl-users] =?utf-8?q?SSL_error_=E2=80=9Cinappropriate_fallba?= =?utf-8?b?Y2vigJ0gYW5kIFRMU19GQUxMQkFDS19TQ1NW?= In-Reply-To: References: <0527d6de5ed6bea7cbbdb908bfc51b41@andrei.myip.org> Message-ID: <85086205ab6f468e9fc08bf0f2fde113@usma1ex-dag1mb1.msg.corp.akamai.com> > Would clients actually attempt to send TLS_FALLBACK_SCSV even if the > previous connection attempt failed for reasons other than TLS? If, say, the > initial connection attempt failed at the TCP level? That sounds a little strange > to me. Yes they do. There are many badly written clients out there. Or poor libraries. From florin at andrei.myip.org Thu Jun 1 19:12:41 2017 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 01 Jun 2017 12:12:41 -0700 Subject: [openssl-users] =?utf-8?q?SSL_error_=E2=80=9Cinappropriate_fallba?= =?utf-8?b?Y2vigJ0gYW5kIFRMU19GQUxMQkFDS19TQ1NW?= In-Reply-To: <85086205ab6f468e9fc08bf0f2fde113@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0527d6de5ed6bea7cbbdb908bfc51b41@andrei.myip.org> <85086205ab6f468e9fc08bf0f2fde113@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <4a9f61a33356fcd4407ff721d79a432f@andrei.myip.org> On 2017-06-01 11:43, Salz, Rich via openssl-users wrote: >> Would clients actually attempt to send TLS_FALLBACK_SCSV even if the >> previous connection attempt failed for reasons other than TLS? If, >> say, the >> initial connection attempt failed at the TCP level? That sounds a >> little strange >> to me. > > Yes they do. > > There are many badly written clients out there. Or poor libraries. What I find surprising is the rate of these errors. For every 100 legitimate HTTP requests that make it to Nginx, I get 2.5 ?inappropriate fallback? SSL errors. That's a lot of noise. I guess I'll have to adjust my expectations. Related question: assuming the lists of TLS protocol versions and ciphers I've enabled in Nginx are indeed exactly the same as the default TLS policy in an AWS ALB, the errors I see now logged by Nginx should be, more or less, the same population of errors I saw reflected in the ALB metrics before, right? The whole point of this exercise is to temporarily work around the lack of a TLS error log in an ALB. The error rate does seem quite similar between ALB and Nginx. I'm just wondering if the ALB is doing something that my standard Ubuntu openssl libraries are not. -- Florin Andrei http://florin.myip.org/ From rsalz at akamai.com Thu Jun 1 19:18:31 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Jun 2017 19:18:31 +0000 Subject: [openssl-users] =?utf-8?q?SSL_error_=E2=80=9Cinappropriate_fallba?= =?utf-8?b?Y2vigJ0gYW5kIFRMU19GQUxMQkFDS19TQ1NW?= In-Reply-To: <4a9f61a33356fcd4407ff721d79a432f@andrei.myip.org> References: <0527d6de5ed6bea7cbbdb908bfc51b41@andrei.myip.org> <85086205ab6f468e9fc08bf0f2fde113@usma1ex-dag1mb1.msg.corp.akamai.com> <4a9f61a33356fcd4407ff721d79a432f@andrei.myip.org> Message-ID: > What I find surprising is the rate of these errors. For every 100 legitimate > HTTP requests that make it to Nginx, I get 2.5 ?inappropriate fallback? SSL > errors. That's a lot of noise. > > I guess I'll have to adjust my expectations. That's not out of line with other measurements I've been told. > Related question: assuming the lists of TLS protocol versions and ciphers I've > enabled in Nginx are indeed exactly the same as the default TLS policy in an > AWS ALB, the errors I see now logged by Nginx should be, more or less, the > same population of errors I saw reflected in the ALB metrics before, right? Not necessarily. The network connectivity could be a very large influence. From Michael.Wojcik at microfocus.com Thu Jun 1 19:23:28 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 1 Jun 2017 19:23:28 +0000 Subject: [openssl-users] =?windows-1252?q?SSL_error_=93inappropriate_fallb?= =?windows-1252?q?ack=94_and_TLS=5FFALLBACK=5FSCSV?= In-Reply-To: <85086205ab6f468e9fc08bf0f2fde113@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0527d6de5ed6bea7cbbdb908bfc51b41@andrei.myip.org> <85086205ab6f468e9fc08bf0f2fde113@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Salz, Rich via openssl-users > Sent: Thursday, June 01, 2017 14:44 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] SSL error ?inappropriate fallback? and TLS_FALLBACK_SCSV > > > Would clients actually attempt to send TLS_FALLBACK_SCSV even if the > > previous connection attempt failed for reasons other than TLS? If, say, the > > initial connection attempt failed at the TCP level? That sounds a little strange > > to me. > > Yes they do. And they should, *if* they have actually fallen back to an older protocol version, because an attacker with the appropriate affordance (e.g. a compromised router along the path) could easily trigger a TCP failure by sending a RST. Any time the client falls back, it should include TLS_FALLBACK_SCSV in its cipher-suite list. The question is whether a client that supports fallback (and there's much debate over whether clients should support fallback, particularly in the default configuration) ought to try falling back in response to a TCP failure. On the one hand, it's entirely possible that a broken old server would reject an unrecognized protocol version by simply aborting the connection. On the other, there are a lot of other reasons for a RST, and falling back as the first resort seems rather hasty. Personally, I'd prefer clients not try to fall back at all, except perhaps clients that have a reasonable need to support broken servers, and even then only with some non-default configuration. Browser manufacturers will argue that they have to support fallback in order to support broken web servers, but I think that's dubious. > There are many badly written clients out there. Or poor libraries. Very true. On the other hand, this doesn't really answer Florin's question of why the server sees so many clients falling back. If the load is bursty, it might be listen-queue dumping. I don't know if Nginx lets you configure the listen queue depth, but at some point the stack will start dropping connections (either silently, in the BSD or "correct" manner; or with a RST, in the Winsock or "patently wrong" manner) if the sustained load is too high. But unless this is a pretty busy server or has a really high variance in its load distribution, it's probably an intermediary node that's to blame. Or the clients have a really short timeout, or the connection's being aborted by the user and the client is incorrectly falling back when that happens. Though then I'd assume Florin would see that in the Nginx logs, assuming it logs ECONNRESET. Really there are too many possibilities to make speculation worthwhile. But now that I've written all this I suppose I'll send it. Michael Wojcik Distinguished Engineer, Micro Focus From florin at andrei.myip.org Thu Jun 1 21:11:00 2017 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 01 Jun 2017 14:11:00 -0700 Subject: [openssl-users] =?utf-8?q?SSL_error_=E2=80=9Cinappropriate_fallba?= =?utf-8?b?Y2vigJ0gYW5kIFRMU19GQUxMQkFDS19TQ1NW?= In-Reply-To: References: <0527d6de5ed6bea7cbbdb908bfc51b41@andrei.myip.org> <85086205ab6f468e9fc08bf0f2fde113@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On 2017-06-01 12:23, Michael Wojcik wrote: > > On the other hand, this doesn't really answer Florin's question of why > the server sees so many clients falling back. If the load is bursty, > it might be listen-queue dumping. I don't know if Nginx lets you > configure the listen queue depth, but at some point the stack will > start dropping connections (either silently, in the BSD or "correct" > manner; or with a RST, in the Winsock or "patently wrong" manner) if > the sustained load is too high. But unless this is a pretty busy > server or has a really high variance in its load distribution, it's > probably an intermediary node that's to blame. Aggregate traffic has a smooth profile, with daily increase towards the middle of the day, and decrease towards midnight. Client sessions are typically short (way under 1 minute, perhaps most of them under 15 seconds). I don't see any errors related to what you're saying. > Or the clients have a really short timeout, or the connection's being > aborted by the user and the client is incorrectly falling back when > that happens. Though then I'd assume Florin would see that in the > Nginx logs, assuming it logs ECONNRESET. Well, I'm digging through the logs. The one thing I see often is: client X.Y.Z.K closed keepalive connection Not much other than that, and these are really "severity:info" events, I see them even with TLS termination at the ALB. I see some amount of... peer closed connection in SSL handshake while SSL handshaking ...also a "severity:info" event, at a rate about 4x less than the ?inappropriate fallback? stuff. (shrug) Seems normal. As a more informal argument: We're using whatever Amazon deemed appropriate for their TLS policy for load balancers, in terms of protocol versions and ciphers. Surely if there was a problem with versions or ciphers, we'd hear about it, or they would change it quickly, just based on the amount of traffic they receive every day. That was the main reason why I've found hard to accept that this rate of TLS errors is somehow normal; but now I think I start to understand this aspect of the protocol thanks to the excellent explanations I've seen early in this discussion. -- Florin Andrei http://florin.myip.org/ From openssl-users at dukhovni.org Fri Jun 2 01:18:26 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 1 Jun 2017 21:18:26 -0400 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> Message-ID: <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> > On Jun 1, 2017, at 10:54 AM, Wouter Verhelst wrote: > > It might be useful to make that point at the start of the CHANGES file, > then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy > [date]". While that doesn't claim to be complete, the simple word > "CHANGES" invokes the idea of a changelog, which should be complete -- > and this file is not. If it's not meant to be, fine -- but then it > doesn't hurt to say so, and it would alleviate some confusion. Sure, would "Major changes" be sufficient? This is essentially a RELEASE_NOTES file, not a comprehensive change log, which is subsumed by git. -- Viktor. From jb-openssl at wisemo.com Fri Jun 2 03:07:32 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 2 Jun 2017 05:07:32 +0200 Subject: [openssl-users] CSR with multiple subject names? In-Reply-To: References: Message-ID: On 01/06/2017 16:26, l vic wrote: > I am working with service with TLS authn that uses subject name to > authenticate client. > Is it possible to use list of subject names in client certificate so > that service could authenticate several clients with the same > key/certificate? If not, would it be possible to use alternative > subject names for the same purpose? Can SANs only used in the context > of DNS domains, eg to authenticate the same subject name calling from > different DNS domains? SANs (SubjectAlternativeNames) can contain all the name types (unlike the main Subject, which can only contain a backwards compatible DirectoryName). Depending on what kind of identity a server wants to identify, good choices for user identifying SANs are: - rfc822Name ("user at sub.domain.tld") - DirectoryName (CN=First Middle Last, OU=Department, O=Example company, street=SomeRoad 123, L=12345 SomeCity, ST=SomeState, C=US) 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 wouter.verhelst at fedict.be Fri Jun 2 07:59:34 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Fri, 2 Jun 2017 09:59:34 +0200 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> References: <20170525135756.GA25645@openssl.org> <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> Message-ID: On 02-06-17 03:18, Viktor Dukhovni wrote: > >> On Jun 1, 2017, at 10:54 AM, Wouter Verhelst wrote: >> >> It might be useful to make that point at the start of the CHANGES file, >> then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy >> [date]". While that doesn't claim to be complete, the simple word >> "CHANGES" invokes the idea of a changelog, which should be complete -- >> and this file is not. If it's not meant to be, fine -- but then it >> doesn't hurt to say so, and it would alleviate some confusion. > > Sure, would "Major changes" be sufficient? This is essentially > a RELEASE_NOTES file, not a comprehensive change log, which is > subsumed by git. Something like that, yes. Alternatively, a note saying "and a number of changes too small to be noted here, please see the git log for details" at the end of every changelog would work too (and give a hint to users where to go for more details). -- Wouter Verhelst From Manoj.Ramachandran at quest-global.com Fri Jun 2 07:00:10 2017 From: Manoj.Ramachandran at quest-global.com (Manoj Ramachandran) Date: Fri, 2 Jun 2017 07:00:10 +0000 Subject: [openssl-users] ECDSA and ECDH Message-ID: <4E0BDEB0E226504895A7E8754B262138AA905406@INBLCORMX01.quest-global.com> Hi, We are planning to designing an embedded device integrating ATECC508A module for PKI support. The embedded device is planned to communicate with a host device which will be ported with FIPS compliant OpenSSL library. Our embedded device will be using ECDSA (FIPS 186-3) and ECDH (FIPS SP800-56A) by calling APIs of ATECC508A SDK. Is there any compatibility issue? 1. Whether a digest signed using openssl library can be verified in our embedded module and vice-versa . 2. We understand that, OpenSSL doesn't have FIPS 140-2 certification for ECDH. If we use ECDH, whether we can claim our system to be FIPS 140-2 compliant? Regards, Manoj ---Disclaimer------------------------------ This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Opinions, conclusions and other information in this transmission that do not relate to the official business of QuEST Global and/or its subsidiaries, shall be understood as neither given nor endorsed by it. Any statements made herein that are tantamount to contractual obligations, promises, claims or commitments shall not be binding on the Company unless followed by written confirmation by an authorized signatory of the Company. ----------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jun 2 08:29:27 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Jun 2017 09:29:27 +0100 Subject: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e? In-Reply-To: References: <3cbfba7f-b1e0-72d7-2938-6f27cb13e3d4@openssl.org> Message-ID: <94e8f26b-3743-44ed-b38f-6c25e69c1450@openssl.org> On 01/06/17 18:16, Siyuan Xiang wrote: > Hi Matt, > > I tried the following command, it failed. following is my command. > > ./config enable-weak-ssl-ciphers --prefix=/opt > make > make DESTDIR=/path/to/dir INSTALL > > $ ./openssl version > OpenSSL 1.1.0e 16 Feb 2017 > > ./openssl s_client -cipher "RC4-MD5:@SECLEVEL=0" > > error setting cipher list > 140369010624144:error:140E6118:SSL > routines:SSL_CIPHER_PROCESS_RULESTR:invalid command:ssl_ciph.c:1337: > > > ./openssl ciphers "RC4-MD5:@SECLEVEL=0" > Error in cipher list > 140458428679936:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no > cipher match:ssl/ssl_lib.c:2018: That's very strange. Those exact same commands work fine for me. Are you sure you are picking up the version of 1.1.0e compiled with enable-weak-ssl-ciphers and not some other previous compilation of 1.1.0e? Matt > > However, after I change SSL_CTX_set_XXX function > orders, TLS_RSA_WITH_RC4_128_MD5 do appear in client hello cipher list. > > SSL_CTX_set_security_level(ctx, 0); > SSL_CTX_set_cipher_list(ctx, "ALL:RC4-MD5"); > > Regards, > Siyuan > --- > > On Thu, Jun 1, 2017 at 2:41 AM, Matt Caswell > wrote: > > > > On 31/05/17 21:22, Siyuan Xiang wrote: > > Hi all, > > > > I have a legacy server only accept TLS_RSA_WITH_RC4_128_MD5 cipher. > > > > I have a client using openssl 1.1.0e. It doesn't include > > TLS_RSA_WITH_RC4_128_MD5. > > I have recompiled the openssl using enable-weak-ssl-ciphers, but it > > doesn't work > > but TLS_RSA_WITH_RC4_128_SHA is in client hello message. > > > > It looks like all MD5 related ciphers are removed. I tried to > > use SSL_CTX_set_security_level to > > set level to 0. but it doesn't work. > > > > Do you have any idea how to enable TLS_RSA_WITH_RC4_128_MD5? > > How have you configured your ciphersuite list? I can get this to work in > 1.1.0 using s_server and s_client. > > Having built with "enable-weak-ssl-ciphers" I start up s_server like > this: > > $ openssl s_server -cipher "RC4-MD5:@SECLEVEL=0" > > And then run s_client like this: > > $ openssl s_client -cipher "RC4-MD5:@SECLEVEL=0" > > The connection is successful and uses the RC4-MD5 ciphersuite (aka > TLS_RSA_WITH_RC4_128_MD5). > > Matt > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From rsalz at akamai.com Fri Jun 2 12:26:25 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Jun 2017 12:26:25 +0000 Subject: [openssl-users] ECDSA and ECDH In-Reply-To: <4E0BDEB0E226504895A7E8754B262138AA905406@INBLCORMX01.quest-global.com> References: <4E0BDEB0E226504895A7E8754B262138AA905406@INBLCORMX01.quest-global.com> Message-ID: <327e7116054848b0b82c9226c8c1e0d4@usma1ex-dag1mb1.msg.corp.akamai.com> > with a host device which will be ported with FIPS compliant OpenSSL library. ?Our embedded device will be using ECDSA (FIPS 186-3) ?and ECDH (FIPS SP800-56A) by calling APIs of ATECC508A SDK. ?Is there any compatibility issue? ? There shouldn't be. But interop is a hard thing, and a single bug on either side can break compatibility. You really won't know until you test it. > 1. Whether a digest signed using openssl library can be verified in our embedded module and vice-versa . As I said, it should work. > 2. We understand that, OpenSSL doesn?t have FIPS 140-2 certification for ECDH. If we use ECDH, whether we can claim our system to be FIPS 140-2 compliant? You should be careful what you say. If you claim to be certified, that would be lying ... > ---Disclaimer------------------------------ This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION Please get your company policy changed. Posting a big block disclaimer like this, when writing to a public mailing list, is very obnoxious. From bsmith at progress.com Fri Jun 2 12:10:32 2017 From: bsmith at progress.com (Bill Smith) Date: Fri, 2 Jun 2017 12:10:32 +0000 Subject: [openssl-users] -fPIC option missing for crypto/bn/x86_64-gcc.c and some other files in 1.0.2l that exists in 1.0.1m & 1.1.0c Message-ID: <1ad34afb92a1468dae0205ecdc3e2622@ntmaexbe04.bedford.progress.com> Hi, I'm building OpenSSL 1.0.2l on Centos Linux 5.4. When linking the libcrypto.a library against my application, I'm getting the error: /usr/bin/ld: /vobs_prgs/src/openssl/linuxx86_64/lib/libcrypto.a(x86_64-gcc.o): relocation R_X86_64_32 against 'a local symbol' can not be used when making a shared object; recompile with -fPIC Looking at the openssl build output, sure enough, it's missing -fPIC. gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o x86_64-gcc.o asm/x86_64-gcc.c If I compare compilation output with 1.0.1m, I see that -fPIC is included. Ditto for 1.1.0c. I look at the configure output for 1.0.2l and see -fPIC is missing for CFLAG: IsMK1MF=0 CC =gcc CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM The configure output for 1.0.1m has -fPIC for CFLAG: IsMK1MF=0 CC =gcc CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_LINUX-SHARED -m64 -fvisibility=hidden -fPIC -DPIC -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM What is the correct way for me to add the -fPIC option so that crypto/bn/x86_64-gcc.c is compiled with it? Thanks! From mwood at iupui.edu Fri Jun 2 13:32:48 2017 From: mwood at iupui.edu (Mark H. Wood) Date: Fri, 2 Jun 2017 09:32:48 -0400 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> References: <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> Message-ID: <20170602133248.GB23764@IUPUI.Edu> On Thu, Jun 01, 2017 at 09:18:26PM -0400, Viktor Dukhovni wrote: > > > On Jun 1, 2017, at 10:54 AM, Wouter Verhelst wrote: > > > > It might be useful to make that point at the start of the CHANGES file, > > then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy > > [date]". While that doesn't claim to be complete, the simple word > > "CHANGES" invokes the idea of a changelog, which should be complete -- > > and this file is not. If it's not meant to be, fine -- but then it > > doesn't hurt to say so, and it would alleviate some confusion. > > Sure, would "Major changes" be sufficient? This is essentially > a RELEASE_NOTES file, not a comprehensive change log, which is > subsumed by git. Exactly. Lots of us have been trained by much experience that a file named CHANGES contains *all* of the changes, while a file named RELEASE_NOTES includes selected changes of particular significance. It's confusing to call a release-notes file CHANGES. Appending a note that, for a full change log, [DO THIS], would probably be well received. -- 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 dclarke at blastwave.org Fri Jun 2 14:28:22 2017 From: dclarke at blastwave.org (Dennis Clarke) Date: Fri, 2 Jun 2017 10:28:22 -0400 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <20170602133248.GB23764@IUPUI.Edu> References: <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> <20170602133248.GB23764@IUPUI.Edu> Message-ID: <6f6ea469-17d7-5561-2c41-249d17416030@blastwave.org> >> Sure, would "Major changes" be sufficient? This is essentially >> a RELEASE_NOTES file, not a comprehensive change log, which is >> subsumed by git. > > Exactly. Lots of us have been trained by much experience that a file > named CHANGES contains *all* of the changes, while a file named > RELEASE_NOTES includes selected changes of particular significance. > It's confusing to call a release-notes file CHANGES. > > Appending a note that, for a full change log, [DO THIS], would probably > be well received. > Simply remove the CHANGES file from the source release. Since it clearly is not a "CHANGES" list nor is it useful. I feel rather strongly that a source release of production grade quality should come with reasonable documentation. That means within the area of good judgement and reason. So a file in the production grade source tarball that has a "CHANGES" file which clearly lists nothing of any real value should be removed. Perhaps there is a very long standing tradition, not so much a de facto standard, however an expectation that the source tarball to be used for a production grade release should have certain little features in it. A file that says "INSTALL" which actually does document ways to perform an out of the box[1] compile, testsuite and then install. That can be removed entirely also and replaced with a note that says "see the internet". How about the LICENSE or README? These are archaic, ancient old dusty concepts and they go way way back to the days of Apollo workstations or Sun deskside monsters. Why do we still bother with the install of the manpages? Are those needed? Who actually ever runs "man SSL_CTX_free" and then reads the manpage? It really doesn't have much to say. Just tell the user or the package maintainer to go get it themselves somewhere. Also what is that great awful long thing CHANGES.SSLeay? Toss that out the airlock. This is what is needed, a trivial one line replacement : sedna$ cat ACKNOWLEDGMENTS Please https://www.openssl.org/community/thanks.html for the current acknowledgements. I guess I'm being foolish to think that the source release is the absolute reference standard. It is the "published" actual source as well as the essential docs for it. Perhaps expectations of that nature are just twenty or thirty year old concepts because we have the internet at our fingertips and the real data is out there .. somewhere. Go find it. Dennis Clarke [1] out of the box? sorry, my age is showing. Perhaps "git pull" ? From rsalz at akamai.com Fri Jun 2 14:33:32 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Jun 2017 14:33:32 +0000 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <20170602133248.GB23764@IUPUI.Edu> References: <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> <20170602133248.GB23764@IUPUI.Edu> Message-ID: <840b22df2dd54c4bbcea84d6137523fb@usma1ex-dag1mb1.msg.corp.akamai.com> > Appending a note that, for a full change log, [DO THIS], would probably be > well received. https://github.com/openssl/openssl/pull/3606 From rsalz at akamai.com Fri Jun 2 14:36:15 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Jun 2017 14:36:15 +0000 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <6f6ea469-17d7-5561-2c41-249d17416030@blastwave.org> References: <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> <20170602133248.GB23764@IUPUI.Edu> <6f6ea469-17d7-5561-2c41-249d17416030@blastwave.org> Message-ID: <60c2b21580254ba1b60f8c7c82ef33a1@usma1ex-dag1mb1.msg.corp.akamai.com> Dennis, Feel free to not read any documentation you find superfluous :) Too much information is not something people often say about OpenSSL. We believe many people find the current file useful. To wit, you are the first person to raise this issue that I can recall in over 20 years. From dclarke at blastwave.org Fri Jun 2 14:48:40 2017 From: dclarke at blastwave.org (Dennis Clarke) Date: Fri, 2 Jun 2017 10:48:40 -0400 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <60c2b21580254ba1b60f8c7c82ef33a1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> <20170602133248.GB23764@IUPUI.Edu> <6f6ea469-17d7-5561-2c41-249d17416030@blastwave.org> <60c2b21580254ba1b60f8c7c82ef33a1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > you are the first person to raise this issue that I can recall in over 20 years. > I'll just go back to my server cave then. dc From dclarke at blastwave.org Fri Jun 2 14:51:58 2017 From: dclarke at blastwave.org (Dennis Clarke) Date: Fri, 2 Jun 2017 10:51:58 -0400 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <60c2b21580254ba1b60f8c7c82ef33a1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> <20170602133248.GB23764@IUPUI.Edu> <6f6ea469-17d7-5561-2c41-249d17416030@blastwave.org> <60c2b21580254ba1b60f8c7c82ef33a1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <65ab444e-5abe-31bd-7351-2f2fedbd738e@blastwave.org> On 06/02/2017 10:36 AM, Salz, Rich via openssl-users wrote: > Dennis, > > Feel free to not read any documentation you find superfluous :) I'll simply leave this here as an example of truely fine CHANGES docs : https://lists.freedesktop.org/archives/xorg/2017-June/058761.html Dennis Clarke ps: that is what people generally expect to see in CHANGES but the openssl folks may disagree of course. From Michael.Wojcik at microfocus.com Fri Jun 2 14:58:12 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 2 Jun 2017 14:58:12 +0000 Subject: [openssl-users] -fPIC option missing for crypto/bn/x86_64-gcc.c and some other files in 1.0.2l that exists in 1.0.1m & 1.1.0c In-Reply-To: <1ad34afb92a1468dae0205ecdc3e2622@ntmaexbe04.bedford.progress.com> References: <1ad34afb92a1468dae0205ecdc3e2622@ntmaexbe04.bedford.progress.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Bill Smith > Sent: Friday, June 02, 2017 08:11 > > Looking at the openssl build output, sure enough, it's missing -fPIC. This is one of the reasons why we use our own Configure script for OpenSSL. When we update to a new OpenSSL release, we diff its Configure against the one from the previous release, and decide whether we need to make corresponding edits to our own Configure. We also document what we've changed in our own Configure. It looks like you're building OpenSSL into archive libraries that you then intend to link statically into your own shared objects. That's what my teams do as well. OpenSSL's Configure wants to either build OpenSSL itself as shared objects, or build archive libraries that aren't suitable for use in shared objects (i.e. lack -fPIC or whatever the local toolchain's equivalent is). At least that's the way it was back when we forked Configure in some 1.0.1 release, and we've continued to use our own Configure since. It's not ideal, but in practice updating our Configure when we get a new OpenSSL 1.0.2 release has been trivial - it hardly takes any more time than downloading the tarball and checking the signature, and certainly much less than building and testing on all of the platforms we support. And OpenSSL is still far less trouble for us than, say, OpenLDAP. Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Fri Jun 2 14:58:12 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 2 Jun 2017 14:58:12 +0000 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <6f6ea469-17d7-5561-2c41-249d17416030@blastwave.org> References: <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> <655c31e8-8604-f6c2-0317-63c6d5dffec4@openssl.org> <45db364a-cd6c-e7aa-bf49-abfc8f86f86d@blastwave.org> <91d10da2ff0845faae069e47782253b2@usma1ex-dag1mb1.msg.corp.akamai.com> <8a02ac1b-2ad7-4566-42ad-1ec247dbc109@blastwave.org> <0d9ec8db-8886-76a5-4a7b-661e219cd0a8@openssl.org> <8cb4b4f5-9830-a5d8-914e-0d5b50511d65@blastwave.org> <2c0e7488-7959-834a-6471-3c253a683062@openssl.org> <610faa9d-4230-0a79-e991-cbb1af0bd418@fedict.be> <0472CB9C-5475-4F94-AA0B-3C3F7F4A8B82@dukhovni.org> <20170602133248.GB23764@IUPUI.Edu> <6f6ea469-17d7-5561-2c41-249d17416030@blastwave.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Dennis Clarke > Sent: Friday, June 02, 2017 10:28 > > Simply remove the CHANGES file from the source release. > > Since it clearly is not a "CHANGES" list nor is it useful. It may not be useful to you. It's useful to me, and I suspect I'm not the only one. Not everyone shares your preferences and prejudices. Michael Wojcik Distinguished Engineer, Micro Focus From joe.flowers at nofreewill.com Fri Jun 2 21:36:33 2017 From: joe.flowers at nofreewill.com (Joe Flowers) Date: Fri, 2 Jun 2017 17:36:33 -0400 Subject: [openssl-users] Source code to build "OpenSSL 1.0.1e-fips 11 Feb 2013"? Message-ID: Hello Everyone, Will someone tell me where the source code is to build this version of openssl, please? "OpenSSL 1.0.1e-fips 11 Feb 2013" Thanks! Joe ----------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew_Porter at bmc.com Sat Jun 3 00:30:54 2017 From: Andrew_Porter at bmc.com (Porter, Andrew) Date: Sat, 3 Jun 2017 00:30:54 +0000 Subject: [openssl-users] Source code to build "OpenSSL 1.0.1e-fips 11 Feb 2013"? In-Reply-To: References: Message-ID: If that version string was printed by a Linux system-provided "openssl" command you'd be best off downloading the system-specific source packages. To make your best guess at building it manually yourself from original source: (a) your old OpenSSL source here: https://www.openssl.org/source/old/1.0.1/ (b) that string doesn't tell you which exact FIPS module source, the current version is here: https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz (c) The FIPS-140 User Guide here, which covers how to build first the FIPS module and then fips-enabled OpenSSL: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf Andrew From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Joe Flowers Sent: Friday, June 02, 2017 14:37 To: openssl-users at openssl.org Subject: [openssl-users] Source code to build "OpenSSL 1.0.1e-fips 11 Feb 2013"? Hello Everyone, Will someone tell me where the source code is to build this version of openssl, please? "OpenSSL 1.0.1e-fips 11 Feb 2013" Thanks! Joe ----------------- From flowers.joseph at gmail.com Sat Jun 3 10:48:48 2017 From: flowers.joseph at gmail.com (Joe Flowers) Date: Sat, 3 Jun 2017 06:48:48 -0400 Subject: [openssl-users] Source code to build "OpenSSL 1.0.1e-fips 11 Feb 2013"? In-Reply-To: References: Message-ID: Andrew, Thank you very much. This is very helpful. On Jun 2, 2017 9:17 PM, "Porter, Andrew" wrote: > If that version string was printed by a Linux system-provided "openssl" > command you'd be best off downloading the system-specific source packages. > To make your best guess at building it manually yourself from original > source: > > (a) your old OpenSSL source here: > > https://www.openssl.org/source/old/1.0.1/ > > (b) that string doesn't tell you which exact FIPS module source, the > current version is here: > > https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz > > (c) The FIPS-140 User Guide here, which covers how to build first the FIPS > module and then fips-enabled OpenSSL: > > https://www.openssl.org/docs/fips/UserGuide-2.0.pdf > > Andrew > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Joe Flowers > Sent: Friday, June 02, 2017 14:37 > To: openssl-users at openssl.org > Subject: [openssl-users] Source code to build "OpenSSL 1.0.1e-fips 11 Feb > 2013"? > > Hello Everyone, > > Will someone tell me where the source code is to build this version of > openssl, please? > > "OpenSSL 1.0.1e-fips 11 Feb 2013" > > > Thanks! > > Joe > ----------------- > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pravesh.rai at gmail.com Sun Jun 4 05:01:33 2017 From: pravesh.rai at gmail.com (Pravesh Rai) Date: Sun, 4 Jun 2017 10:31:33 +0530 Subject: [openssl-users] Problem in connecting to Java (Tomcat) server with ECDHE ciphers Message-ID: Hi, Even though I've disabled SSLvX protocols on both - client (openssl-1.0.2k) & server (Java 1.8 with Tomcat), still getting following handshake error, while executing: "openssl s_client -connect a.b.c.d: -msg -debug -cipher ECDHE-ECDSA-AES256-GCM-SHA384" ... read from 0x213f50 [0x21c410] (7 bytes => 7 (0x7)) 0000 - 15 03 03 00 02 02 28 ......( <<< TLS 1.2 [length 0005] 15 03 03 00 02 <<< TLS 1.2 Alert [length 0002], fatal handshake_failure 02 28 14756:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:769: ... And, such error happens, only when ECDHE ciphers are selected during the connection. Any clue on this? Thanks, PR -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sun Jun 4 06:29:52 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 4 Jun 2017 02:29:52 -0400 Subject: [openssl-users] Problem in connecting to Java (Tomcat) server with ECDHE ciphers In-Reply-To: References: Message-ID: On Sun, Jun 4, 2017 at 1:01 AM, Pravesh Rai wrote: > Hi, > > Even though I've disabled SSLvX protocols on both - client (openssl-1.0.2k) > & server (Java 1.8 with Tomcat), still getting following handshake error, > while executing: > > "openssl s_client -connect a.b.c.d: -msg -debug -cipher > ECDHE-ECDSA-AES256-GCM-SHA384" > GCM mode is a TLS 1.2 cipher. It looks like Java 8 enables it by default; cf. https://blogs.oracle.com/java-platform-group/jdk-8-will-use-tls-12-as-default. Maybe something like: openssl s_client -connect www.example.com:443 -tls1_2 -servername www.example.com The command uses SNI and TLS 1.2, which is pretty much standard practice nowadays. If that does not do it, then maybe you can use SSLscan to identify the protocols and cipher suites the server supports. https://github.com/rbsec/sslscan Jeff From andreas at schildbach.de Sun Jun 4 12:00:24 2017 From: andreas at schildbach.de (Andreas Schildbach) Date: Sun, 4 Jun 2017 14:00:24 +0200 Subject: [openssl-users] Possible OpenSSL 1.1.0 regression with "enc -d" command? Message-ID: I have a ciphertext that I used to decrypt with openssl enc -d -aes-256-cbc -a -in ciphertext.txt > plaintext.bin and given the correct password it decrypted fine on OpenSSL 0.9.x to 1.0.2g (Ubuntu 16.04). Now I got word that OpenSSL 1.1.0 can no longer decrypt the file. Apparently the user tested unter Arch Linux and Mint and got this error: 139925102714752:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:535 Is there some known regression with OpenSSL 1.1.0 that could cause this? I can provide an example including the correct password by mail if anyone wants to look at this; I refrained from posting this to the list because it's 30 kB. From rsalz at akamai.com Sun Jun 4 12:54:28 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 4 Jun 2017 12:54:28 +0000 Subject: [openssl-users] Possible OpenSSL 1.1.0 regression with "enc -d" command? In-Reply-To: References: Message-ID: <50560c839949414f9b15fd2981406c12@usma1ex-dag1mb1.msg.corp.akamai.com> In 1.1.0 the default digest changed from MD5 to SHA256. So use the "-digest md5" flag to read or write data from older releases. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz From andreas at schildbach.de Sun Jun 4 14:37:09 2017 From: andreas at schildbach.de (Andreas Schildbach) Date: Sun, 4 Jun 2017 16:37:09 +0200 Subject: [openssl-users] Possible OpenSSL 1.1.0 regression with "enc -d" command? In-Reply-To: <50560c839949414f9b15fd2981406c12@usma1ex-dag1mb1.msg.corp.akamai.com> References: <50560c839949414f9b15fd2981406c12@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Thanks for the pointer. Seems as if the right option is "-md" though. On 06/04/2017 02:54 PM, Salz, Rich via openssl-users wrote: > > In 1.1.0 the default digest changed from MD5 to SHA256. So use the "-digest md5" flag to read or write data from older releases. > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz at jabber.at Twitter: RichSalz > From pgnet.dev at gmail.com Sun Jun 4 19:17:53 2017 From: pgnet.dev at gmail.com (PGNet Dev) Date: Sun, 4 Jun 2017 12:17:53 -0700 Subject: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ? Message-ID: <49db6a56-ebb6-00e6-65e7-0dc2b70018d8@gmail.com> I've a new, local CA for (primary) local, self-signed, elliptical cert issuance & use. I've built/installed, openssl version OpenSSL 1.1.0f 25 May 2017 I've created a ROOT crt & key, & and an INTERMEDIATE key & csr. On exec of signing the INTERMEDIATE key with the ROOT. openssl ca -batch \ -notext \ -extensions ext_intermediate \ -config /home/sec/newCA/openssl.cnf \ -name ca_root \ -in intermediate/csr/newCA.INTERMEDIATE.csr.pem \ -out intermediate/certs/newCA.INTERMEDIATE.crt.pem It appears to complete -- the cert's created openssl x509 \ -noout \ -text \ -in intermediate/certs/newCA.INTERMEDIATE.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: 4096 (0x1000) Signature Algorithm: ecdsa-with-SHA256 ... but the process STARTS with an apparently non-fatal error ... Using configuration from /home/sec/newCA/openssl.cnf Can't open root/database.attr for reading, No such file or directory 140013244086016:error:02001002:system library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r') 140013244086016:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:81: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4096 (0x1000) Validity Not Before: Jun 4 18:54:29 2017 GMT Not After : Jun 2 18:54:29 2027 GMT ... Write out database with 1 new entries Data Base Updated The only mention of root/database is in my openssl.conf ... [ ca_root ] dir = root certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/database <------------- unique_subject = yes ... PRIOR to creating the ROOT key, I touch root/database touch intermediate/database AFTER the signing, ls -al root/database* -rw-r--r-- 1 root root 167 Jun 4 11:54 root/database -rw-r--r-- 1 root root 21 Jun 4 11:54 root/database.attr -rw-r--r-- 1 root root 0 Jun 4 11:51 root/database.old and if I RE-exec the cmd, openssl ca -batch \ ... there's no more error Using configuration /home/sec/newCA/openssl.cnf Check that the request matches the signature Signature ok Certificate Details: ... Checking cat root/database.attr unique_subject = yes Which appears (?) to originate from the "[ ca_root ]" in my openssl.cnf Do I need to touch, or manually populate, the root/database.attr prior to first exec to init as well? Or is this a bug? From noloader at gmail.com Sun Jun 4 23:51:29 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 4 Jun 2017 19:51:29 -0400 Subject: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ? In-Reply-To: <49db6a56-ebb6-00e6-65e7-0dc2b70018d8@gmail.com> References: <49db6a56-ebb6-00e6-65e7-0dc2b70018d8@gmail.com> Message-ID: > but the process STARTS with an apparently non-fatal error ... > > Using configuration from /home/sec/newCA/openssl.cnf > Can't open root/database.attr for reading, No such file or directory > 140013244086016:error:02001002:system library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r') > 140013244086016:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:81: This usually indicates the OpenSSL conf file cannot be found. Its odd that "Using configuration from /home/sec/newCA/openssl.cnf" is reported. Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf ` to isolate the issue (or maybe rule out its not a conf file problem). Jeff From pgnet.dev at gmail.com Sun Jun 4 23:56:11 2017 From: pgnet.dev at gmail.com (PGNet Dev) Date: Sun, 4 Jun 2017 16:56:11 -0700 Subject: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ? In-Reply-To: References: <49db6a56-ebb6-00e6-65e7-0dc2b70018d8@gmail.com> Message-ID: <6ab45eb7-03bf-99cb-7834-b2618f3cd67f@gmail.com> On 6/4/17 4:51 PM, Jeffrey Walton wrote: >> but the process STARTS with an apparently non-fatal error ... >> >> Using configuration from /home/sec/newCA/openssl.cnf >> Can't open root/database.attr for reading, No such file or directory >> 140013244086016:error:02001002:system library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r') >> 140013244086016:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:81: > > This usually indicates the OpenSSL conf file cannot be found. Its odd > that "Using configuration from /home/sec/newCA/openssl.cnf" is > reported. > > Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf ` > to isolate the issue (or maybe rule out its not a conf file problem). The message above doesn't indicate that openssl.cnf can't be found. In fact it explcitly states that it IS found and IS using it >> Using configuration from /home/sec/newCA/openssl.cnf It's the same openssl.cnf used in all the PRIOR steps, with not problem whatsoever. Rather it's >> Can't open root/database.attr for reading, No such file or directory that's not found. I've found that if I simply touch root/database.attr touch intermediate/database.attr as already's been done with touch root/database touch intermediate/database From noloader at gmail.com Mon Jun 5 00:57:08 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 4 Jun 2017 20:57:08 -0400 Subject: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ? In-Reply-To: <6ab45eb7-03bf-99cb-7834-b2618f3cd67f@gmail.com> References: <49db6a56-ebb6-00e6-65e7-0dc2b70018d8@gmail.com> <6ab45eb7-03bf-99cb-7834-b2618f3cd67f@gmail.com> Message-ID: On Sun, Jun 4, 2017 at 7:56 PM, PGNet Dev wrote: > On 6/4/17 4:51 PM, Jeffrey Walton wrote: >>> >>> but the process STARTS with an apparently non-fatal error ... >>> >>> Using configuration from /home/sec/newCA/openssl.cnf >>> Can't open root/database.attr for reading, No such file or >>> directory >>> 140013244086016:error:02001002:system >>> library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r') >>> 140013244086016:error:2006D080:BIO routines:BIO_new_file:no such >>> file:crypto/bio/bss_file.c:81: >> >> >> This usually indicates the OpenSSL conf file cannot be found. Its odd >> that "Using configuration from /home/sec/newCA/openssl.cnf" is >> reported. >> >> Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf ` >> to isolate the issue (or maybe rule out its not a conf file problem). > > > The message above doesn't indicate that openssl.cnf can't be found. In fact > it explcitly states that it IS found and IS using it > >>> Using configuration from /home/sec/newCA/openssl.cnf > > It's the same openssl.cnf used in all the PRIOR steps, with not problem > whatsoever. > > Rather it's > >>> Can't open root/database.attr for reading, No such file or >>> directory > > that's not found. > > I've found that if I simply > > touch root/database.attr > touch intermediate/database.attr > > as already's been done with > > touch root/database > touch intermediate/database Oh, I was not aware you were skipping steps. I guess that explains the unusual results. Jeff From noloader at gmail.com Mon Jun 5 01:18:26 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 4 Jun 2017 21:18:26 -0400 Subject: [openssl-users] 1st time through, only -- "Can't open root/database.attr for reading, No such file or directory" ? In-Reply-To: References: <49db6a56-ebb6-00e6-65e7-0dc2b70018d8@gmail.com> <6ab45eb7-03bf-99cb-7834-b2618f3cd67f@gmail.com> Message-ID: On Sun, Jun 4, 2017 at 8:57 PM, Jeffrey Walton wrote: > On Sun, Jun 4, 2017 at 7:56 PM, PGNet Dev wrote: >> On 6/4/17 4:51 PM, Jeffrey Walton wrote: >>>> >>>> but the process STARTS with an apparently non-fatal error ... >>>> >>>> Using configuration from /home/sec/newCA/openssl.cnf >>>> Can't open root/database.attr for reading, No such file or >>>> directory >>>> 140013244086016:error:02001002:system >>>> library:fopen::crypto/bio/bss_file.c:74:fopen('root/database.attr','r') >>>> 140013244086016:error:2006D080:BIO routines:BIO_new_file:no such >>>> file:crypto/bio/bss_file.c:81: >>> >>> >>> This usually indicates the OpenSSL conf file cannot be found. Its odd >>> that "Using configuration from /home/sec/newCA/openssl.cnf" is >>> reported. >>> >>> Maybe you can try `OPENSSL_CONF=/home/sec/newCA/openssl.cnf ` >>> to isolate the issue (or maybe rule out its not a conf file problem). >> >> >> The message above doesn't indicate that openssl.cnf can't be found. In fact >> it explcitly states that it IS found and IS using it >> >>>> Using configuration from /home/sec/newCA/openssl.cnf >> >> It's the same openssl.cnf used in all the PRIOR steps, with not problem >> whatsoever. >> >> Rather it's >> >>>> Can't open root/database.attr for reading, No such file or >>>> directory >> >> that's not found. >> >> I've found that if I simply >> >> touch root/database.attr >> touch intermediate/database.attr >> >> as already's been done with >> >> touch root/database >> touch intermediate/database > > Oh, I was not aware you were skipping steps. I guess that explains the > unusual results. BTW, I believe you are also supposed to add an initial serial number. Something like: echo "0" > serialno.txt Check your conf file for the filename. (The information is somewhere in the docs. It may be in the Certificates HOWTO or the CA HOWTO). Jeff From Andrew_Porter at bmc.com Mon Jun 5 17:44:41 2017 From: Andrew_Porter at bmc.com (Porter, Andrew) Date: Mon, 5 Jun 2017 17:44:41 +0000 Subject: [openssl-users] Problem in connecting to Java (Tomcat) server with ECDHE ciphers In-Reply-To: References: Message-ID: <13f2661ee7974fe78333a60934464c05@phx-exmbprd-02.adprod.bmc.com> Running sslscan against Tomcat 8.0.43 / Oracle Java 8u121 and a Tomcat server.xml containing ciphers="HIGH:!aNULL:!RC4:!MD5:@STRENGTH" shows the strongest cipher is ECDHE-RSA-AES128-GCM-SHA256 Installing the Java unlimited strength policy files increases this to ECDHE-RSA-AES256-GCM-SHA384 sslscan did not report any ECDSA ciphers from tomcat even when I changed the ciphers in server.xml to include them, even though a test Java program that enumerates supported ciphers did list (unlimited strength policy files) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 So your openssl connect line below always failed for me. Andrew From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Pravesh Rai Sent: Saturday, June 03, 2017 22:02 To: openssl-dev at openssl.org Cc: openssl-users at openssl.org Subject: [openssl-users] Problem in connecting to Java (Tomcat) server with ECDHE ciphers Hi, Even though I've disabled SSLvX protocols on both - client (openssl-1.0.2k) & server (Java 1.8 with Tomcat), still getting following handshake error, while executing: "openssl s_client -connect a.b.c.d: -msg -debug -cipher ECDHE-ECDSA-AES256-GCM-SHA384" ... read from 0x213f50 [0x21c410] (7 bytes => 7 (0x7)) 0000 - 15 03 03 00 02 02 28 ......( <<< TLS 1.2 [length 0005] 15 03 03 00 02 <<< TLS 1.2 Alert [length 0002], fatal handshake_failure 02 28 14756:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:769: ... And, such error happens, only when ECDHE ciphers are selected during the connection. Any clue on this? Thanks, PR -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiangsiyuan at gmail.com Mon Jun 5 17:51:13 2017 From: xiangsiyuan at gmail.com (Siyuan Xiang) Date: Mon, 5 Jun 2017 10:51:13 -0700 Subject: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e? In-Reply-To: <94e8f26b-3743-44ed-b38f-6c25e69c1450@openssl.org> References: <3cbfba7f-b1e0-72d7-2938-6f27cb13e3d4@openssl.org> <94e8f26b-3743-44ed-b38f-6c25e69c1450@openssl.org> Message-ID: On Fri, Jun 2, 2017 at 1:29 AM, Matt Caswell wrote: > That's very strange. Those exact same commands work fine for me. Are you > sure you are picking up the version of 1.1.0e compiled with > enable-weak-ssl-ciphers and not some other previous compilation of 1.1.0e? > Yes I am sure that it's compiled with enable-weak-ssl-ciphers Regards, Siyuan --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Jun 5 22:40:05 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 5 Jun 2017 22:40:05 +0000 Subject: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e? In-Reply-To: References: <3cbfba7f-b1e0-72d7-2938-6f27cb13e3d4@openssl.org> Message-ID: <20170605224005.GI22954@mournblade.imrryr.org> On Thu, Jun 01, 2017 at 10:16:01AM -0700, Siyuan Xiang wrote: > > ./config enable-weak-ssl-ciphers --prefix=/opt Does this set a suitable RPATH? > make > make DESTDIR=/path/to/dir INSTALL And now install in yet another place? > $ ./openssl version > OpenSSL 1.1.0e 16 Feb 2017 The resulting code is likelky using the wrong shared libraries. -- Viktor. From xiangsiyuan at gmail.com Mon Jun 5 23:19:37 2017 From: xiangsiyuan at gmail.com (Siyuan Xiang) Date: Mon, 5 Jun 2017 16:19:37 -0700 Subject: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e? In-Reply-To: <20170605224005.GI22954@mournblade.imrryr.org> References: <3cbfba7f-b1e0-72d7-2938-6f27cb13e3d4@openssl.org> <20170605224005.GI22954@mournblade.imrryr.org> Message-ID: Yes, you are right. openssl binary is linking to a wrong shared library. The code is fine, it's linking to the static library. thanks. Regards, Siyuan --- On Mon, Jun 5, 2017 at 3:40 PM, Viktor Dukhovni wrote: > On Thu, Jun 01, 2017 at 10:16:01AM -0700, Siyuan Xiang wrote: > > > > > ./config enable-weak-ssl-ciphers --prefix=/opt > > Does this set a suitable RPATH? > > > make > > make DESTDIR=/path/to/dir INSTALL > > And now install in yet another place? > > > $ ./openssl version > > OpenSSL 1.1.0e 16 Feb 2017 > > The resulting code is likelky using the wrong shared libraries. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven at raycoll.com Tue Jun 6 14:29:53 2017 From: steven at raycoll.com (Steven Collison) Date: Tue, 06 Jun 2017 07:29:53 -0700 Subject: [openssl-users] Problem in connecting to Java (Tomcat) server with ECDHE ciphers In-Reply-To: References: Message-ID: As a sanity check, are you using an ECDSA certificate on your Tomcat server? ECDHE-ECDSA-AES256-GCM-SHA384 can?t be negotiated without one. Perhaps you can try `openssl s_client -connect a.b.c.d: -msg -debug -cipher ?ECDHE-RSA-AES256-GCM-SHA384?` if you?re using an RSA cert. -Steven On 3 Jun 2017, at 22:01, Pravesh Rai wrote: > Hi, > > Even though I've disabled SSLvX protocols on both - client > (openssl-1.0.2k) > & server (Java 1.8 with Tomcat), still getting following handshake > error, > while executing: > > "openssl s_client -connect a.b.c.d: -msg -debug -cipher > ECDHE-ECDSA-AES256-GCM-SHA384" > > > ... > read from 0x213f50 [0x21c410] (7 bytes => 7 (0x7)) > 0000 - 15 03 03 00 02 02 28 ......( > <<< TLS 1.2 [length 0005] > 15 03 03 00 02 > <<< TLS 1.2 Alert [length 0002], fatal handshake_failure > 02 28 > 14756:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert > handshake failure:.\ssl\s23_clnt.c:769: > ... > > And, such error happens, only when ECDHE ciphers are selected during > the > connection. > > Any clue on this? > > Thanks, > PR > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew_Porter at bmc.com Tue Jun 6 15:33:06 2017 From: Andrew_Porter at bmc.com (Porter, Andrew) Date: Tue, 6 Jun 2017 15:33:06 +0000 Subject: [openssl-users] Problem in connecting to Java (Tomcat) server with ECDHE ciphers In-Reply-To: References: Message-ID: <2905f47cb3464c8b92b36d86639a59d1@phx-exmbprd-02.adprod.bmc.com> Thanks Steven for pointing me in the right direction: when I switched to an EC/ECDSA key for tomcat then openssl could connect using ECDHE-ECDSA-AES256-GCM-SHA384. But only after installing the unlimited strength policy files on the server, with the defaults the best was ECDHE-ECDSA-AES128-GCM-SHA256. Andrew From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steven Collison Sent: Tuesday, June 06, 2017 07:30 To: openssl-users at openssl.org Cc: openssl-dev at openssl.org Subject: Re: [openssl-users] Problem in connecting to Java (Tomcat) server with ECDHE ciphers As a sanity check, are you using an ECDSA certificate on your Tomcat server? ECDHE-ECDSA-AES256-GCM-SHA384 can?t be negotiated without one. Perhaps you can try openssl s_client -connect a.b.c.d: -msg -debug -cipher ?ECDHE-RSA-AES256-GCM-SHA384? if you?re using an RSA cert. -Steven On 3 Jun 2017, at 22:01, Pravesh Rai wrote: Hi, Even though I've disabled SSLvX protocols on both - client (openssl-1.0.2k) & server (Java 1.8 with Tomcat), still getting following handshake error, while executing: "openssl s_client -connect a.b.c.d: -msg -debug -cipher ECDHE-ECDSA-AES256-GCM-SHA384" ... read from 0x213f50 [0x21c410] (7 bytes => 7 (0x7)) 0000 - 15 03 03 00 02 02 28 ......( <<< TLS 1.2 [length 0005] 15 03 03 00 02 <<< TLS 1.2 Alert [length 0002], fatal handshake_failure 02 28 14756:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:769: ... And, such error happens, only when ECDHE ciphers are selected during the connection. Any clue on this? Thanks, PR -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerritvn at gpvno.co.za Wed Jun 7 16:13:17 2017 From: gerritvn at gpvno.co.za (gerritvn) Date: Wed, 7 Jun 2017 09:13:17 -0700 (MST) Subject: [openssl-users] Using weak ciphers in OpenSSL v 1.1.0e client Message-ID: <1496851997554-71061.post@n7.nabble.com> We are using OpenSSL in a terminal emulation product. We recently upgraded from OpenSSL v 1.0.2g to OpenSSL v 1.1.0e. Some servers we connect to do not support any of the strong ciphers which are compiled by default in OpenSSL v 1.1.0e and returns an alert with "handshake error". We recompiled with the option "enable-weak-ssl-ciphers", but that does not solve the problem. With OpenSSL v 1.0.2g one specific server selected the Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) which is shown as DES-CBC3-SHA by OpenSSL Listing ciphers with our OpenSSL 1.1.0e "enable-weak-ssl-ciphers" build with the command: openssl ciphers -v "ALL:@SECLEVEL=0" shows this entry: DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 This cipher is, however, not offered in the Client Hello when our client opens the connection. What do we need to add to our program to get our client to offer the weak ciphers as well as the strong ones? -- View this message in context: http://openssl.6102.n7.nabble.com/Using-weak-ciphers-in-OpenSSL-v-1-1-0e-client-tp71061.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From bkaduk at akamai.com Wed Jun 7 16:15:57 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 7 Jun 2017 11:15:57 -0500 Subject: [openssl-users] Using weak ciphers in OpenSSL v 1.1.0e client In-Reply-To: <1496851997554-71061.post@n7.nabble.com> References: <1496851997554-71061.post@n7.nabble.com> Message-ID: On 06/07/2017 11:13 AM, gerritvn wrote: > We are using OpenSSL in a terminal emulation product. > We recently upgraded from OpenSSL v 1.0.2g to OpenSSL v 1.1.0e. > Some servers we connect to do not support any of the strong ciphers which > are compiled by default in OpenSSL v 1.1.0e and returns an alert with > "handshake error". > We recompiled with the option "enable-weak-ssl-ciphers", but that does not > solve the problem. > With OpenSSL v 1.0.2g one specific server selected the Cipher Suite: > TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) which is shown as DES-CBC3-SHA by > OpenSSL > Listing ciphers with our OpenSSL 1.1.0e "enable-weak-ssl-ciphers" build with > the command: > openssl ciphers -v "ALL:@SECLEVEL=0" > shows this entry: > DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 > This cipher is, however, not offered in the Client Hello when our client > opens the connection. > > What do we need to add to our program to get our client to offer the weak > ciphers as well as the strong ones? > https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_security_level.html -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerritvn at gpvno.co.za Wed Jun 7 18:54:04 2017 From: gerritvn at gpvno.co.za (gerritvn) Date: Wed, 7 Jun 2017 11:54:04 -0700 (MST) Subject: [openssl-users] Using weak ciphers in OpenSSL v 1.1.0e client In-Reply-To: References: <1496851997554-71061.post@n7.nabble.com> Message-ID: Thank you Ben, but I am afraid it does not work unless I'm doing something wrong. Here is a code snippet: int CSSL::createCTX(SSL_CTX **ppctx, int &extError) { X509_NAME *xn; SSL *ssl; X509 *pX509; POSITION pos; TCHAR name[256], *cert_file = NULL, *CAfile, certInfo[512] = _T(""); int len, err; char *CApath = NULL, caFile[256]; extError = 0; if(!(*ppctx = SSL_CTX_new(SSLv23_client_method()))) { ::ShowErrorMsg((DWORD)m_pConfig, 0, 0, SSL_ERROR_CAPTION, _T("Error creating ctx object - SSL_CTX_new() failed")); extError = _SSL_CTX_NEW_FAILED; return _SSL_ERROR; } SSL_CTX_set_options(*ppctx, 0); SSL_CTX_set_security_level(*ppctx, 0); // for compatibility with weak ciphers . . Gerrit van Niekerk GP van Niekerk Ondernemings BK Roosstraat 211, Meyerspark, 0184, South Africa Tel: +27(12)8036501 Fax SA: 086 537 4131 Voip: 0105912084 Cell: +27(73)6891370 Email: gerritvn at gpvno.co.za, gerritvn1945 at gmail.com Web: http://www.gpvno.co.za On Wed, Jun 7, 2017 at 6:16 PM, OpenSSL - User mailing list [via OpenSSL] < ml+s6102n71062h14 at n7.nabble.com> wrote: > On 06/07/2017 11:13 AM, gerritvn wrote: > > We are using OpenSSL in a terminal emulation product. > We recently upgraded from OpenSSL v 1.0.2g to OpenSSL v 1.1.0e. > Some servers we connect to do not support any of the strong ciphers which > are compiled by default in OpenSSL v 1.1.0e and returns an alert with > "handshake error". > We recompiled with the option "enable-weak-ssl-ciphers", but that does not > solve the problem. > With OpenSSL v 1.0.2g one specific server selected the Cipher Suite: > TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) which is shown as DES-CBC3-SHA by > OpenSSL > Listing ciphers with our OpenSSL 1.1.0e "enable-weak-ssl-ciphers" build with > the command: > openssl ciphers -v "ALL:@SECLEVEL=0" > shows this entry: > DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 > This cipher is, however, not offered in the Client Hello when our client > opens the connection. > > What do we need to add to our program to get our client to offer the weak > ciphers as well as the strong ones? > > > > > https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_security_level.html > > -Ben > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://openssl.6102.n7.nabble.com/Using-weak-ciphers-in- > OpenSSL-v-1-1-0e-client-tp71061p71062.html > To unsubscribe from Using weak ciphers in OpenSSL v 1.1.0e client, click > here > > . > NAML > > -- View this message in context: http://openssl.6102.n7.nabble.com/Using-weak-ciphers-in-OpenSSL-v-1-1-0e-client-tp71061p71063.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerritvn at gpvno.co.za Wed Jun 7 21:25:41 2017 From: gerritvn at gpvno.co.za (gerritvn) Date: Wed, 7 Jun 2017 14:25:41 -0700 (MST) Subject: [openssl-users] Using weak ciphers in OpenSSL v 1.1.0e client In-Reply-To: References: <1496851997554-71061.post@n7.nabble.com> Message-ID: <1496870741049-71064.post@n7.nabble.com> Solution found! Add the following line: SSL_CTX_set_cipher_list(*ppctx, "ALL"); -- View this message in context: http://openssl.6102.n7.nabble.com/Using-weak-ciphers-in-OpenSSL-v-1-1-0e-client-tp71061p71064.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From npathak2 at ncsu.edu Thu Jun 8 00:26:45 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Wed, 7 Jun 2017 17:26:45 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 Message-ID: Hello All, I am new to the Openssl community. I am using the latest version of Openssl (with TLS 1.3 enabled) for performance benchmarking. I wanted to know if the session ticket support for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it needs to be explicitly enabled? Thanks Best regards, Neetish -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jun 8 08:47:39 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Jun 2017 09:47:39 +0100 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: Message-ID: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> On 08/06/17 01:26, Neetish Pathak wrote: > Hello All, > > I am new to the Openssl community. > I am using the latest version of Openssl (with TLS 1.3 enabled) for > performance benchmarking. I wanted to know if the session ticket support > for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it > needs to be explicitly enabled? It is on by default. Matt From wangbj at gmail.com Thu Jun 8 16:48:48 2017 From: wangbj at gmail.com (Baojun Wang) Date: Thu, 08 Jun 2017 16:48:48 +0000 Subject: [openssl-users] newer openSSL no longer produce libeay32 on Windows? Message-ID: Hi list, On windows platform, Some libraries (not openSSL) explicitly link with libeay32.dll, however, it seems openSSL 1.1+ only builds libssl & libcrypto (personally I prefer this, because it is consistent with other *nix platforms). What is the purpose of libeay32? Is it only for 32-bit windows, and is it only part of older openSSL (0.9.8ish)? Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well as libcrypto-1_1-x64.dll, this could be painful for application who has to specify openssl dependency, for example now I have to choose ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a more idiomatic way to make linking on windows (not only 64-bit) easier, do you have any idea? Thanks baojun -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Jun 8 17:31:39 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 8 Jun 2017 19:31:39 +0200 Subject: [openssl-users] newer openSSL no longer produce libeay32 on Windows? In-Reply-To: References: Message-ID: <7fefb3bb-15ea-bf3f-e8e0-856f5c48eba6@wisemo.com> On 08/06/2017 18:48, Baojun Wang wrote: > On windows platform, Some libraries (not openSSL) explicitly link with > libeay32.dll, however, it seems openSSL 1.1+ only builds libssl & > libcrypto (personally I prefer this, because it is consistent with > other *nix platforms). What is the purpose of libeay32? Is it only for > 32-bit windows, and is it only part of older openSSL (0.9.8ish)? > libeay was the historic name for libcrypto back when OpenSSL was SSLeay, the Windows port was late in implementing the name change. > Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well > as libcrypto-1_1-x64.dll, this could be painful for application who > has to specify openssl dependency, for example now I have to choose > ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a > more idiomatic way to make linking on windows (not only 64-bit) > easier, do you have any idea? Traditionally, Windows (like Unix) uses the same file name for 32 and 64 bits, but puts them in different directories. If they need to be in the same directory for some applications, the traditional solution is to insert "32" or "64" on its own, while still using the same file name for different architectures with the same bitness. For example a compile for 32 bit MIPS (supported by older Windows releases) or 32 bit ARM (supported by newer releases) would have the same name as for 32 bit x86. Similar for the 4 64 bit architectures supported at various times (Alpha 64 bit, Itanium, AMD x86_64, 64 bit ARM). Microsoft did some crazy experiments with a directory scheme called SxS for versioned DLLs, its badly done and should be avoided if possible. 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 ludwig.mark at siemens.com Thu Jun 8 18:26:42 2017 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Thu, 8 Jun 2017 18:26:42 +0000 Subject: [openssl-users] newer openSSL no longer produce libeay32 on Windows? In-Reply-To: <7fefb3bb-15ea-bf3f-e8e0-856f5c48eba6@wisemo.com> References: <7fefb3bb-15ea-bf3f-e8e0-856f5c48eba6@wisemo.com> Message-ID: > From: Jakob Bohm, Thursday, June 08, 2017 12:32 PM > > On 08/06/2017 18:48, Baojun Wang wrote: > > Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well > > as libcrypto-1_1-x64.dll, this could be painful for application who > > has to specify openssl dependency, for example now I have to choose > > ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a > > more idiomatic way to make linking on windows (not only 64-bit) > > easier, do you have any idea? > Traditionally, Windows (like Unix) uses the same file name for > 32 and 64 bits, but puts them in different directories. If > they need to be in the same directory for some applications, > the traditional solution is to insert "32" or "64" on its own, > while still using the same file name for different architectures > with the same bitness. For example a compile for 32 bit MIPS > (supported by older Windows releases) or 32 bit ARM (supported > by newer releases) would have the same name as for 32 bit x86. > Similar for the 4 64 bit architectures supported at various > times (Alpha 64 bit, Itanium, AMD x86_64, 64 bit ARM). > > Microsoft did some crazy experiments with a directory scheme > called SxS for versioned DLLs, its badly done and should be > avoided if possible. The side-by-side (SxS) stuff has its place, but to use it effectively requires using a "manifest" to identify the dependencies explicitly. I also don't recommend it for general use. Regarding the "32" suffix, you'll see that throughout Windows itself, on modern 64-bit versions, because the "32" dates back to the 1990s when Windows was trying to grow out of being a 16-bit DOS program (WIN.EXE) into a 32-bit "operating system" (Windows NT). Many people are misdirected with the term "Win32" into thinking that means 32-bit when it really only means "not 16-bit." Anything labeled "Win32" could be either 32-bit or 64-bit. I haven't started working with OpenSSL 1.1.n, but in OpenSSL 1.0.2, all 64-bit builds produce identically-named binaries such as libeay32.lib and libeay32.dll in the "out32" directory. Hope this helps, Mark From jb-openssl at wisemo.com Thu Jun 8 18:48:43 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 8 Jun 2017 20:48:43 +0200 Subject: [openssl-users] newer openSSL no longer produce libeay32 on Windows? In-Reply-To: References: <7fefb3bb-15ea-bf3f-e8e0-856f5c48eba6@wisemo.com> Message-ID: On 08/06/2017 20:26, Ludwig, Mark wrote: >> From: Jakob Bohm, Thursday, June 08, 2017 12:32 PM >> >> On 08/06/2017 18:48, Baojun Wang wrote: >>> Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well >>> as libcrypto-1_1-x64.dll, this could be painful for application who >>> has to specify openssl dependency, for example now I have to choose >>> ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a >>> more idiomatic way to make linking on windows (not only 64-bit) >>> easier, do you have any idea? >> Traditionally, Windows (like Unix) uses the same file name for >> 32 and 64 bits, but puts them in different directories. If >> they need to be in the same directory for some applications, >> the traditional solution is to insert "32" or "64" on its own, >> while still using the same file name for different architectures >> with the same bitness. For example a compile for 32 bit MIPS >> (supported by older Windows releases) or 32 bit ARM (supported >> by newer releases) would have the same name as for 32 bit x86. >> Similar for the 4 64 bit architectures supported at various >> times (Alpha 64 bit, Itanium, AMD x86_64, 64 bit ARM). >> >> Microsoft did some crazy experiments with a directory scheme >> called SxS for versioned DLLs, its badly done and should be >> avoided if possible. > The side-by-side (SxS) stuff has its place, but to use it > effectively requires using a "manifest" to identify the > dependencies explicitly. I also don't recommend it for > general use. > > Regarding the "32" suffix, you'll see that throughout > Windows itself, on modern 64-bit versions, because the "32" > dates back to the 1990s when Windows was trying to grow out > of being a 16-bit DOS program (WIN.EXE) into a 32-bit > "operating system" (Windows NT). Many people are > misdirected with the term "Win32" into thinking that means > 32-bit when it really only means "not 16-bit." Anything > labeled "Win32" could be either 32-bit or 64-bit. > > I haven't started working with OpenSSL 1.1.n, but in OpenSSL > 1.0.2, all 64-bit builds produce identically-named binaries > such as libeay32.lib and libeay32.dll in the "out32" > directory. I know, that was (part of) the basis for my answer. 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 npathak2 at ncsu.edu Thu Jun 8 22:12:16 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Thu, 8 Jun 2017 15:12:16 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> Message-ID: Thanks. I had one query regarding the TLS 1.3 implementation on server side. I have a simple client server program with session resumption working with TLS 1.2. When I use TLS 1.3, I see that server hello message has a malformed packet. Though the SSL handshake is successful. I am not observing session resumption. I want to know what causes server hello to have a malformed packet. Also, is any extra configuration required for TLS 1.3 ? I am assuming TLS 1.3 can also use session Ids/ tickets for session resumption. Thanks Best Regards, Neetish On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell wrote: > > > On 08/06/17 01:26, Neetish Pathak wrote: > > Hello All, > > > > I am new to the Openssl community. > > I am using the latest version of Openssl (with TLS 1.3 enabled) for > > performance benchmarking. I wanted to know if the session ticket support > > for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it > > needs to be explicitly enabled? > > It is on by default. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jun 8 22:45:44 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Jun 2017 23:45:44 +0100 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> Message-ID: On 08/06/17 23:12, Neetish Pathak wrote: > Thanks. > I had one query regarding the TLS 1.3 implementation on server side. I > have a simple client server program with session resumption working with > TLS 1.2. > When I use TLS 1.3, I see that server hello message has a malformed > packet. How do you know it is malformed? The format of the ServerHello message has changed in TLSv1.3, so if you expect it to look like a TLSv1.2 ServerHello then you will be surprised. > Though the SSL handshake is successful. I am not observing > session resumption. > I want to know what causes server hello to have a malformed packet. > Also, is any extra configuration required for TLS 1.3 ? > I am assuming TLS 1.3 can also use session Ids/ tickets for session > resumption. You probably want to read this blog post: https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ Session ids are not used in TLSv1.3 and session tickets work very differently. Session resumption should work just fine but there are some things to be aware of (discussed in the blog post). Matt > > Thanks > Best Regards, > Neetish > > On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell > wrote: > > > > On 08/06/17 01:26, Neetish Pathak wrote: > > Hello All, > > > > I am new to the Openssl community. > > I am using the latest version of Openssl (with TLS 1.3 enabled) for > > performance benchmarking. I wanted to know if the session ticket support > > for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it > > needs to be explicitly enabled? > > It is on by default. > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From bsmith at progress.com Fri Jun 9 01:45:11 2017 From: bsmith at progress.com (Bill Smith) Date: Fri, 9 Jun 2017 01:45:11 +0000 Subject: [openssl-users] -fPIC option missing for crypto/bn/x86_64-gcc.c and some other files in 1.0.2l that exists in 1.0.1m & 1.1.0c In-Reply-To: References: <1ad34afb92a1468dae0205ecdc3e2622@ntmaexbe04.bedford.progress.com> Message-ID: <0d0df679c26a4ae9a905678b645e6473@ntmaexbe04.bedford.progress.com> Thanks for the info. It turns out that we had customized the configure script but the person who did it didn't document it correctly. Once I got that sorted out, I was able to build it correctly. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik Sent: Friday, June 02, 2017 10:58 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] -fPIC option missing for crypto/bn/x86_64-gcc.c and some other files in 1.0.2l that exists in 1.0.1m & 1.1.0c > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Bill Smith > Sent: Friday, June 02, 2017 08:11 > > Looking at the openssl build output, sure enough, it's missing -fPIC. This is one of the reasons why we use our own Configure script for OpenSSL. When we update to a new OpenSSL release, we diff its Configure against the one from the previous release, and decide whether we need to make corresponding edits to our own Configure. We also document what we've changed in our own Configure. It looks like you're building OpenSSL into archive libraries that you then intend to link statically into your own shared objects. That's what my teams do as well. OpenSSL's Configure wants to either build OpenSSL itself as shared objects, or build archive libraries that aren't suitable for use in shared objects (i.e. lack -fPIC or whatever the local toolchain's equivalent is). At least that's the way it was back when we forked Configure in some 1.0.1 release, and we've continued to use our own Configure since. It's not ideal, but in practice updating our Configure when we get a new OpenSSL 1.0.2 release has been trivial - it hardly takes any more time than downloading the tarball and checking the signature, and certainly much less than building and testing on all of the platforms we support. And OpenSSL is still far less trouble for us than, say, OpenLDAP. Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rsalz at akamai.com Fri Jun 9 17:51:24 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 9 Jun 2017 17:51:24 +0000 Subject: [openssl-users] Code Health Tuesday -- Fix the FAQ Message-ID: <08d59baca17144d784af4e43b95ba9ac@usma1ex-dag1mb1.msg.corp.akamai.com> It's been awhile since we did a code health Tuesday and we're overdue for one next week. Our online FAQ is really old; it's outdated and incorrect. We haven't fully figured out how much of the older versions and older platforms we should document. So, let's fix it. Move anything older than 1.0.2 to the new "old" section. Move anything about really old platforms that aren't fully supported, or have strange wonky compilers, etc., to that same section. And along the way, let's fix up any other entries that come to mind. The repo is here: https://github.com/openssl/web The FAQ can be found here: https://github.com/openssl/web/tree/master/docs Feel free to clone the fork the repo and make pull requests. If that's too much work, open an issue with the suggested revisions (but please if it's about moving entries, do a PR). The FAQ is mostly plain text, with some markdown-like additions. It should be easy to figure out. Thanks! We'll post a reminder about this after the weekend. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Sat Jun 10 00:54:26 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Fri, 9 Jun 2017 17:54:26 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> Message-ID: Thanks Matt On Thu, Jun 8, 2017 at 3:45 PM, Matt Caswell wrote: > > > On 08/06/17 23:12, Neetish Pathak wrote: > > Thanks. > > I had one query regarding the TLS 1.3 implementation on server side. I > > have a simple client server program with session resumption working with > > TLS 1.2. > > When I use TLS 1.3, I see that server hello message has a malformed > > packet. > > How do you know it is malformed? The format of the ServerHello message > has changed in TLSv1.3, so if you expect it to look like a TLSv1.2 > ServerHello then you will be surprised. > *I know the ServerHello is malformed from the WIRESHARK LOGS. It shows an exception for the ServerHello with malformed packet message.* > > > Though the SSL handshake is successful. I am not observing > > session resumption. > > I want to know what causes server hello to have a malformed packet. > > Also, is any extra configuration required for TLS 1.3 ? > > I am assuming TLS 1.3 can also use session Ids/ tickets for session > > resumption. > > You probably want to read this blog post: > > https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ > > *This blogpost is highly useful. Thanks for directing me here. I am following the guidelines.* > Session ids are not used in TLSv1.3 and session tickets work very > differently. Session resumption should work just fine but there are some > things to be aware of (discussed in the blog post). > > Matt > > > > > > Thanks > > Best Regards, > > Neetish > > > > On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell > > wrote: > > > > > > > > On 08/06/17 01:26, Neetish Pathak wrote: > > > Hello All, > > > > > > I am new to the Openssl community. > > > I am using the latest version of Openssl (with TLS 1.3 enabled) for > > > performance benchmarking. I wanted to know if the session ticket > support > > > for session resumption enabled;ed by default for OpenSSL TLS v 1.2 > or it > > > needs to be explicitly enabled? > > > > It is on by default. > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Sat Jun 10 01:58:00 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 9 Jun 2017 20:58:00 -0500 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> Message-ID: On 06/09/2017 07:54 PM, Neetish Pathak wrote: > > On Thu, Jun 8, 2017 at 3:45 PM, Matt Caswell > wrote: > > > > On 08/06/17 23:12, Neetish Pathak wrote: > > Thanks. > > I had one query regarding the TLS 1.3 implementation on server > side. I > > have a simple client server program with session resumption > working with > > TLS 1.2. > > When I use TLS 1.3, I see that server hello message has a malformed > > packet. > > How do you know it is malformed? The format of the ServerHello message > has changed in TLSv1.3, so if you expect it to look like a TLSv1.2 > ServerHello then you will be surprised. > > > > *I know the ServerHello is malformed from the WIRESHARK LOGS. It shows > an exception for the ServerHello with malformed packet message.* It is quite likely that your version of wireshark does not know how to properly decode the TLS 1.3 ServerHello. When interpreted as a TLS 1.2 ServerHello, it is expected to show as malformed, because the protocol formats are different between the two protocols. This is what Matt was trying to say. Someone could look at the raw hex dump of the packet and decode it manually as a TLS 1.3 ServerHello to confirm whether it is actually malformed or just a wireshark error. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From nacao2001 at hotmail.com Fri Jun 9 07:45:33 2017 From: nacao2001 at hotmail.com (Ignacio Alamo Corsino) Date: Fri, 9 Jun 2017 07:45:33 +0000 Subject: [openssl-users] Understanding RSA_sign and type argument Message-ID: Hello everyone, i am having some issues understanding the RSA_sign function: RSA_sign(int type, const unsigned char *m, unsigned int m_len, unsigned char *sigret, unsigned int *siglen, RSA *rsa); As far as I know, the signing is a four step process: - Calculate hash with digest algorithm (given as argument to this function -> m) - Encapsulate hash in a DigestInfo structure (X509_SIG) - Structure padding (in RSA_private_encrypt) - Private key operation on this padded structure (in RSA_private_encrypt) Is that correct? So, during the TLS handshake, the RSA_sign function is called in the CertificateVerify step. For my tests, everytime this function is called, the hashing type is SHA512 even though I specify to use a SHA256 hash. These are the commands that I use to test TLS: #openssl s_server -accept 443 -cert cert.pem -key key.pem -Verify 1 -msg -debug -cipher eNULL:aRSA:!SHA512:SHA256 -serverpref #openssl s_client -connect localhost:443 -cert client_cert.pem -key client.key -state -cipher eNULL:aRSA:!SHA512:SHA256 How can I force TLS to use a SHA256 digest for DH? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Jun 10 14:09:15 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 10 Jun 2017 14:09:15 +0000 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> Message-ID: <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> > It is quite likely that your version of wireshark does not know how to properly decode the TLS 1.3 ServerHello. Please see https://www.ietf.org/mail-archive/web/tls/current/msg22333.html for information about downloading an early release of wireshark. From Erwann.Abalea at docusign.com Mon Jun 12 08:42:21 2017 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Mon, 12 Jun 2017 08:42:21 +0000 Subject: [openssl-users] Understanding RSA_sign and type argument In-Reply-To: References: Message-ID: <6534DA3B-0DA7-4181-ACE8-E04700BB0EA5@docusign.com> Bonjour, Add ? -sigalgs SHA256+RSA ? to one of your command lines. Cordialement, Erwann Abalea Le 9 juin 2017 ? 09:45, Ignacio Alamo Corsino > a ?crit : Hello everyone, i am having some issues understanding the RSA_sign function: RSA_sign(int type, const unsigned char *m, unsigned int m_len, unsigned char *sigret, unsigned int *siglen, RSA *rsa); As far as I know, the signing is a four step process: - Calculate hash with digest algorithm (given as argument to this function -> m) - Encapsulate hash in a DigestInfo structure (X509_SIG) - Structure padding (in RSA_private_encrypt) - Private key operation on this padded structure (in RSA_private_encrypt) Is that correct? So, during the TLS handshake, the RSA_sign function is called in the CertificateVerify step. For my tests, everytime this function is called, the hashing type is SHA512 even though I specify to use a SHA256 hash. These are the commands that I use to test TLS: #openssl s_server -accept 443 -cert cert.pem -key key.pem -Verify 1 -msg -debug -cipher eNULL:aRSA:!SHA512:SHA256 -serverpref #openssl s_client -connect localhost:443 -cert client_cert.pem -key client.key -state -cipher eNULL:aRSA:!SHA512:SHA256 How can I force TLS to use a SHA256 digest for DH? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Tue Jun 13 23:32:14 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Tue, 13 Jun 2017 16:32:14 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Thanks Salz and Benjamin for your feedback. Indeed my Wireshark version was unable to decode TLS 1.3. I got an update from the shared link. I had one doubt about the server side session caching. I read that server side server caching is disabled by default. Then, how is session resumption possible using session identifiers because that is is stateful resumption as I have understood with servers maintaining the session info. Whereas with session tickets, client maintains the session tickets. I am getting confused on the session caching concept. Could someone please clarify. Also, for TLS 1.3, should the server caching be enabled for session resumption ? Thanks BR, Neetish On Sat, Jun 10, 2017 at 7:09 AM, Salz, Rich wrote: > > It is quite likely that your version of wireshark does not know how to > properly decode the TLS 1.3 ServerHello. > > Please see https://www.ietf.org/mail-archive/web/tls/current/ > msg22333.html for information about downloading an early release of > wireshark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jun 14 00:38:42 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Jun 2017 00:38:42 +0000 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: It?s disabled by default. Servers that want to use server-side session caching have to call an API to turn it on -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Wed Jun 14 01:03:16 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Tue, 13 Jun 2017 18:03:16 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Thanks for your reply Salz. However, I want to know should the session caching be enabled on server side for TLS 1.3 for session resumption. Also, I need a clarification on how does resumption work in case of session identifiers if server side caching is not enabled Thanks BR, Neetish On Tue, Jun 13, 2017 at 5:38 PM, Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > It?s disabled by default. Servers that want to use server-side session > caching have to call an API to turn it on > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Wed Jun 14 01:33:48 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Tue, 13 Jun 2017 18:33:48 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: I need some suggestions on how I can implement session resumption in TLS 1.3. I have implemented the resumption on the client side using a callback as recommended on the TLS 1.3 blog https://www.openssl.org/blog/b log/2017/05/04/tlsv1.3/ . Still, the session resumption is not working. I know this because my new_session_cb which I have set using SSL_CTX_sess_set_new_cb is never getting invoked and also I don't see any improvement in connection time. The same implementation when I change the max TLS version to TLS1.2 works and session resumption works as desired. I am not sure how I can resolve this. As mentioned on the blog post "In TLSv1.3 sessions are not established until after the main handshake has completed. The server sends a separate post-handshake message to the client containing the session details. Typically this will happen soon after the handshake has completed, but it could be sometime later (or not at all)." I think the server is not informing the session details to client at all in my case and hence the resumption is not working. Can someone please suggest how to resolve this. Thanks Best Regards, Neetish On Tue, Jun 13, 2017 at 6:03 PM, Neetish Pathak wrote: > Thanks for your reply Salz. However, I want to know should the session > caching be enabled on server side for TLS 1.3 for session resumption. > Also, I need a clarification on how does resumption work in case of > session identifiers if server side caching is not enabled > > Thanks > BR, > Neetish > > On Tue, Jun 13, 2017 at 5:38 PM, Salz, Rich via openssl-users < > openssl-users at openssl.org> wrote: > >> It?s disabled by default. Servers that want to use server-side session >> caching have to call an API to turn it on >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jun 14 10:43:40 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Jun 2017 11:43:40 +0100 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> On 14/06/17 01:38, Salz, Rich via openssl-users wrote: > It?s disabled by default. Servers that want to use server-side session > caching have to call an API to turn it on Err, no, that's not correct. Server side caching is on by default. Client side caching is off by default. On 14/06/17 02:03, Neetish Pathak wrote: > Thanks for your reply Salz. However, I want to know should the session > caching be enabled on server side for TLS 1.3 for session resumption. It should just work by default for TLSv1.3. You don't need to enable anything. > Also, I need a clarification on how does resumption work in case of > session identifiers if server side caching is not enabled As noted above server side caching is on by default. On 14/06/17 02:33, Neetish Pathak wrote: > I need some suggestions on how I can implement session resumption in TLS > 1.3. I have implemented the resumption on the client side using a > callback as recommended on the TLS 1.3 > blog https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ > . Still, the > session resumption is not working. I know this because my new_session_cb > which I have set using SSL_CTX_sess_set_new_cb is never getting invoked > and also I don't see any improvement in connection time. > > The same implementation when I change the max TLS version to TLS1.2 > works and session resumption works as desired. > I am not sure how I can resolve this. > > As mentioned on the blog post > > "In TLSv1.3 sessions are not established until after the main handshake > has completed. The server sends a separate post-handshake message to the > client containing the session details. Typically this will happen soon > after the handshake has completed, but it could be sometime later (or > not at all)." > > I think the server is not informing the session details to client at all > in my case and hence the resumption is not working. Can someone please > suggest how to resolve this Just to be clear: you are using OpenSSL on both the server and client sides right? If you are using something other than OpenSSL on the server then the policy might be different around when the session information is sent to the client (i.e. it could happen sometime later, or not at all). If you are using OpenSSL on the server then it sends its session information immediately after the main handshake has completed, so that should not be a problem. So if I understand you correctly the client is successfully creating a TLSv1.3 connection, but the client side new session callback is never being invoked? Did you call SSL_CTX_sess_set_new_cb() before or after the SSL object itself was created? Are you able to share any code for how you have done this? Matt From nacao2001 at hotmail.com Tue Jun 13 06:15:09 2017 From: nacao2001 at hotmail.com (Ignacio Alamo Corsino) Date: Tue, 13 Jun 2017 06:15:09 +0000 Subject: [openssl-users] Understanding RSA_sign and type argument In-Reply-To: <6534DA3B-0DA7-4181-ACE8-E04700BB0EA5@docusign.com> References: , <6534DA3B-0DA7-4181-ACE8-E04700BB0EA5@docusign.com> Message-ID: Hello Erwann, Merci beaucoup! It has worked but with "-sigalgs RSA+SHA256" instead of "sigalgs SHA256+RSA" Finding this option was driving me crazy because I could not find it in the wiki page of s_server: https://wiki.openssl.org/index.php/Manual:S_server(1) Manual:S server(1) - OpenSSLWiki wiki.openssl.org NAME. s_server - SSL/TLS server program SYNOPSIS. openssl s_server [-accept port] [-naccept count] [-context id] [-verify depth] [-Verify depth] [-crl_check] [-crl ... ________________________________ De: openssl-users en nombre de Erwann Abalea Enviado: lunes, 12 de junio de 2017 10:42 Para: openssl-users at openssl.org Asunto: Re: [openssl-users] Understanding RSA_sign and type argument Bonjour, Add ? -sigalgs SHA256+RSA ? to one of your command lines. Cordialement, Erwann Abalea Le 9 juin 2017 ? 09:45, Ignacio Alamo Corsino > a ?crit : Hello everyone, i am having some issues understanding the RSA_sign function: RSA_sign(int type, const unsigned char *m, unsigned int m_len, unsigned char *sigret, unsigned int *siglen, RSA *rsa); As far as I know, the signing is a four step process: - Calculate hash with digest algorithm (given as argument to this function -> m) - Encapsulate hash in a DigestInfo structure (X509_SIG) - Structure padding (in RSA_private_encrypt) - Private key operation on this padded structure (in RSA_private_encrypt) Is that correct? So, during the TLS handshake, the RSA_sign function is called in the CertificateVerify step. For my tests, everytime this function is called, the hashing type is SHA512 even though I specify to use a SHA256 hash. These are the commands that I use to test TLS: #openssl s_server -accept 443 -cert cert.pem -key key.pem -Verify 1 -msg -debug -cipher eNULL:aRSA:!SHA512:SHA256 -serverpref #openssl s_client -connect localhost:443 -cert client_cert.pem -key client.key -state -cipher eNULL:aRSA:!SHA512:SHA256 How can I force TLS to use a SHA256 digest for DH? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Wed Jun 14 17:36:55 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Wed, 14 Jun 2017 10:36:55 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: On Wed, Jun 14, 2017 at 3:43 AM, Matt Caswell wrote: > > > On 14/06/17 01:38, Salz, Rich via openssl-users wrote: > > It?s disabled by default. Servers that want to use server-side session > > caching have to call an API to turn it on > > Err, no, that's not correct. Server side caching is on by default. > Client side caching is off by default. > I am quoting a line from Network Security with OpenSSL book (O'Reilly Media) "All sessions must have a session ID context. For the server, session caching is disabled by default unless a call to SSL_CTX_set_session_id_context is made." That's why I thought server side session caching is disabled by default. > > > On 14/06/17 02:03, Neetish Pathak wrote: > > Thanks for your reply Salz. However, I want to know should the session > > caching be enabled on server side for TLS 1.3 for session resumption. > > It should just work by default for TLSv1.3. You don't need to enable > anything. > Yea it worked for previous TLS versions, so everything was inline. But since with TLS 1.3, I was not observing the same behavior, that's why my question was for TLS 1.3. > > > Also, I need a clarification on how does resumption work in case of > > session identifiers if server side caching is not enabled > > As noted above server side caching is on by default. > > > On 14/06/17 02:33, Neetish Pathak wrote: > > I need some suggestions on how I can implement session resumption in TLS > > 1.3. I have implemented the resumption on the client side using a > > callback as recommended on the TLS 1.3 > > blog https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ > > . Still, the > > session resumption is not working. I know this because my new_session_cb > > which I have set using SSL_CTX_sess_set_new_cb is never getting invoked > > and also I don't see any improvement in connection time. > > > > The same implementation when I change the max TLS version to TLS1.2 > > works and session resumption works as desired. > > I am not sure how I can resolve this. > > > > As mentioned on the blog post > > > > "In TLSv1.3 sessions are not established until after the main handshake > > has completed. The server sends a separate post-handshake message to the > > client containing the session details. Typically this will happen soon > > after the handshake has completed, but it could be sometime later (or > > not at all)." > > > > I think the server is not informing the session details to client at all > > in my case and hence the resumption is not working. Can someone please > > suggest how to resolve this > > Just to be clear: you are using OpenSSL on both the server and client > sides right? If you are using something other than OpenSSL on the server > then the policy might be different around when the session information > is sent to the client (i.e. it could happen sometime later, or not at > all). If you are using OpenSSL on the server then it sends its session > information immediately after the main handshake has completed, so that > should not be a problem. > > So if I understand you correctly the client is successfully creating a > TLSv1.3 connection, but the client side new session callback is never > being invoked? Did you call SSL_CTX_sess_set_new_cb() before or after > the SSL object itself was created? Are you able to share any code for > how you have done this? > Yes, I am using OpenSSl on both the server and client sides and my implementation works for TLS 1.2. Yea you understood correctly, the client is creating a connection but new session callback is not getting invoked. I have called SSL_CTX_sess_set_new_cb before SSL object is created Yea, sure following is a snippet from my client side implementation. I have highlighted the relevant section for new session callback registration *static* *int* *new_session_cb*(SSL* ssl, SSL_SESSION * sess){ BIO *stmp = BIO_new_file(SESS_OUT,"w"); *if*(stmp == NULL){ BIO_printf(bio_err,"Error writing session file %s\n",SESS_OUT); }*else*{ fprintf(stderr,"Session getting set\n"); PEM_write_bio_SSL_SESSION(stmp,sess); BIO_free(stmp); resumeInput = TRUE; } *return* 0; } *int* *SocketClient::connectToServer*(){ /*Initialization ** (1)Register SSL/TLS ciphers and digests ** (2)Load Opessl error Strings*/ init_OpenSSL(); /*Creating a new SSL context object*/ ssl_ctx = SSL_CTX_new(TLS_client_method()); SSL_CTX_set_max_proto_version(ssl_ctx, MAX_TLS_VERSION); SSL_CTX_set_min_proto_version(ssl_ctx, MIN_TLS_VERSION); *if*(NULL == ssl_ctx){ fail("SocketClient.cpp : ssl_ctx object creation failed"); perror(""); }*else*{ pass("SocketClient.cpp : ssl Context created successfully"); } *if(ssl_ctx){* * SSL_CTX_set_session_cache_mode(ssl_ctx, SSL_SESS_CACHE_CLIENT* * | SSL_SESS_CACHE_NO_INTERNAL_STORE);* * SSL_CTX_sess_set_new_cb(ssl_ctx, new_session_cb);* * }* *return* 0; } int *SocketClient::sslTcpConnect*(){ /*Attaching the SSL connection to the Socket*/ *if*((*this*->conn = SSL_new(ssl_ctx)) == NULL){ perror("SocketClient.cpp : create new SSL failed "); exit(1); } /*Try to resume session*/ *#if* SESS_RESUME *if*(resumeInput){ SSL_SESSION *sess; BIO *stmp = BIO_new_file(SESS_OUT, "r"); *if* (!stmp) { BIO_printf(bio_err, "Can't open session file %s\n", SESS_OUT); ERR_print_errors(bio_err); } sess = PEM_read_bio_SSL_SESSION(stmp, NULL, 0, NULL); BIO_free(stmp); *if* (!sess) { BIO_printf(bio_err, "Can't open session file %s\n", SESS_OUT); ERR_print_errors(bio_err); } *if* (!SSL_set_session(*this*->conn, sess)) { BIO_printf(bio_err, "Can't set session\n"); ERR_print_errors(bio_err); } SSL_SESSION_free(sess); /*if(FALSE == TLSv1_3){ if(this->sessionId != NULL){ SSL_set_session(this->conn, this->sessionId); SSL_SESSION_free(this->sessionId); } }*/ } /*Another way of resumption*/ /* if(this->sessionId != NULL){ SSL_set_session(this->conn, this->sessionId); SSL_SESSION_free(this->sessionId); } */ *#endif* /****Establish TCP connection****/ /*Setting up BIO*/ bio = BIO_new_connect((*this*->serverName + ":" + *this*->portNumber ).c_str()); *if*(!bio) int_error("Error creating connection BIO"); *if*(BIO_do_connect(bio) <= 0){ fail("SocketClient.cpp : TCP connection failed"); }*else*{ pass("SocketClient.cpp : TCP connection successful"); } /*set the file descriptor socket-fd as the input/output facility for the TLS/SSL*/ SSL_set_bio(conn, bio, bio); /*Perform the SSL handshake*/ *if*(SSL_connect(conn) != 1){ fail("SocketClient.cpp : SSL connect failed"); perror(""); ERR_print_errors_fp(stderr); SSL_clear(conn); exit(1); }*else*{ *this*->isConnected = *true*; pass("SocketClient.cpp : SSL_connect successful"); } *return* 0; } *int* *SocketClient::sslTcpClosure*(){ *if* (*this*->conn){ SSL_shutdown(*this*->conn); } *if*(*this*->bio) BIO_free(*this*->bio); *return* 0; } My calling sequence is : client.connectToServer(); client.sslTcpConnect(); client.sslTcpClosure(); > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > Thanks BR, Neetish -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jun 14 17:43:25 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Jun 2017 17:43:25 +0000 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: > I am quoting a line from Network Security with OpenSSL book (O'Reilly Media) That book is 15 years old. Throw it out. From rsalz at akamai.com Wed Jun 14 18:26:06 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Jun 2017 18:26:06 +0000 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: <41ad5001ee0f4d2982986d2df7fd9bc0@svr-orw-mbx-01.mgc.mentorg.com> References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> <41ad5001ee0f4d2982986d2df7fd9bc0@svr-orw-mbx-01.mgc.mentorg.com> Message-ID: <3d48fd8c24464b359d0519af542e0a68@usma1ex-dag1mb1.msg.corp.akamai.com> > Is there a recommendation for a newer book? Many people like the Feisty Duck book(s). See if others on this list say anything. From thomas_floodeenjr at mentor.com Wed Jun 14 18:18:16 2017 From: thomas_floodeenjr at mentor.com (Floodeenjr, Thomas) Date: Wed, 14 Jun 2017 18:18:16 +0000 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: <41ad5001ee0f4d2982986d2df7fd9bc0@svr-orw-mbx-01.mgc.mentorg.com> Is there a recommendation for a newer book? -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-users Sent: Wednesday, June 14, 2017 11:43 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2 > I am quoting a line from Network Security with OpenSSL book (O'Reilly Media) That book is 15 years old. Throw it out. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From noloader at gmail.com Wed Jun 14 21:49:41 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 14 Jun 2017 17:49:41 -0400 Subject: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library) In-Reply-To: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> References: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> Message-ID: > RPATHs have advantages, but they have some major issues, too. For > instance, if for whatever reason you need to move files around so that > things are stored in a different location, suddenly you'll need to > recompile everything -- because the RPATH is a hardcoded location of the > library in use. This is very confusing, and not something that an > average developer will expect. > > There is usually no need to hardcode the location of the library in use, > provided the SONAME is configured correctly. Surprise surprise, OpenSSL > actually does that right: > > wouter at gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 > |grep SONAME > SONAME libssl.so.1.0.2 > wouter at gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > |grep SONAME > SONAME libssl.so.1.1 > > There is no way that ld.so will load libssl1.1 for an application that > is compiled against libssl.so with an SONAME of libssl.1.0.2 -- unless, > of course, you do things like muck about with RPATH and point it to the > wrong version of the library. In that case, you broke it, you get to > keep both pieces. The OpenSSL I build from sources is located in /usr/local. The gear from /usr/local is first on-path. This is what happens on Ubuntu 16.10: $ /usr/bin/openssl errstr 0x3208408D /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: relocation error: /usr/bin/openssl: symbol COMP_zlib_cleanup, version OPENSSL_1.0.0 not defined in file libcrypto.so.1.0.0 with link time reference This is what happens on Fedora release 25: $ /usr/bin/openssl errstr 0x3208408D error:3208408D:lib(50):func(132):reason(141) It seems to me SONAME's just don't work as expected. Jeff From matt at openssl.org Thu Jun 15 09:30:45 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Jun 2017 10:30:45 +0100 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: On 14/06/17 18:36, Neetish Pathak wrote: > > My calling sequence is : > > client.connectToServer(); > > client.sslTcpConnect(); > > client.sslTcpClosure(); Does your client at any point attempt to read application data (i.e. through a call to SSL_read()/SSL_read_ex()?). It is not sufficient to just connect to a server via SSL_connect(). Because the session information is established *post* handshake in TLSv1.3, OpenSSL won't see it unless you actually try and read information from the connection. Matt From npathak2 at ncsu.edu Fri Jun 16 18:58:34 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Fri, 16 Jun 2017 11:58:34 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: Hello Thanks I tried reading some content from the server side and I observed the new_session_cb getting invoked in that case on the client side. I understand that may be due to delayed NewSession info transfer from server side to client side. But it is helpful for saving the session info on the client side. (Thanks Matt for your input) However, now I have two concerns 1) I see that latency for handshake with session resumption in TLS 1.3 has not improved as much as it improves for TLS 1.2 With TLS 1.3, I observed that resumption brings down the connection time from 2.5 ms to 1.2-1.3 ms while with TLS 1.2 (using either session IDs or tickets), the connection time reduces from 2.5 ms to 0.5-0.6 ms. The whole code is similar for running the two experiments with only max TLS version changed. Can someone comment on the latency measurements for the two cases. TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please comment. 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS 1.3 RFC. How do we generate pre-shared keys in advance even without making the first connection. Can someone guide me in the right direction. Thanks Best Regards, Neetish On Thu, Jun 15, 2017 at 2:30 AM, Matt Caswell wrote: > > > On 14/06/17 18:36, Neetish Pathak wrote: > > > > My calling sequence is : > > > > client.connectToServer(); > > > > client.sslTcpConnect(); > > > > client.sslTcpClosure(); > > Does your client at any point attempt to read application data (i.e. > through a call to SSL_read()/SSL_read_ex()?). It is not sufficient to > just connect to a server via SSL_connect(). Because the session > information is established *post* handshake in TLSv1.3, OpenSSL won't > see it unless you actually try and read information from the connection. > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Fri Jun 16 19:08:23 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 16 Jun 2017 14:08:23 -0500 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: On 06/16/2017 01:58 PM, Neetish Pathak wrote: > Hello > Thanks > I tried reading some content from the server side and I observed the > new_session_cb getting invoked in that case on the client side. I > understand that may be due to delayed NewSession info transfer from > server side to client side. But it is helpful for saving the session > info on the client side. (Thanks Matt for your input) > > However, now I have two concerns > > 1) I see that latency for handshake with session resumption in TLS 1.3 > has not improved as much as it improves for TLS 1.2 > With TLS 1.3, I observed that resumption brings down the connection > time from 2.5 ms to 1.2-1.3 ms > while with TLS 1.2 (using either session IDs or tickets), the > connection time reduces from 2.5 ms to 0.5-0.6 ms. > > The whole code is similar for running the two experiments with only > max TLS version changed. Can someone comment on the latency > measurements for the two cases. > TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please > comment. > Are you seeing a HelloRetryRequest in the resumption flow? That would add an additional round trip. (Your numbers in milliseconds are of course not transferrable to other systems; round-trips is an easier to understand number.) RFC 5246 and draft-ietf-tls-tls13-20 both have message-flow diagrams that show the number of round trips in various handshake flows. > 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS > 1.3 RFC. How do we generate pre-shared keys in advance even without > making the first connection. Can someone guide me in the right direction. > The security properties of such "external" PSKs are substantially different than the "ephemeral" PSKs used in resumption flows. I do not think I can recommend their use in the general case when resumption flows are available. Regardless, external PSK support is still a work in progress: https://github.com/openssl/openssl/pull/3670 -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jun 16 22:36:28 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 16 Jun 2017 23:36:28 +0100 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote: > On 06/16/2017 01:58 PM, Neetish Pathak wrote: >> Hello >> Thanks >> I tried reading some content from the server side and I observed the >> new_session_cb getting invoked in that case on the client side. I >> understand that may be due to delayed NewSession info transfer from >> server side to client side. But it is helpful for saving the session >> info on the client side. (Thanks Matt for your input) >> >> However, now I have two concerns >> >> 1) I see that latency for handshake with session resumption in TLS 1.3 >> has not improved as much as it improves for TLS 1.2 >> With TLS 1.3, I observed that resumption brings down the connection >> time from 2.5 ms to 1.2-1.3 ms >> while with TLS 1.2 (using either session IDs or tickets), the >> connection time reduces from 2.5 ms to 0.5-0.6 ms. >> >> The whole code is similar for running the two experiments with only >> max TLS version changed. Can someone comment on the latency >> measurements for the two cases. >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please >> comment. >> > > Are you seeing a HelloRetryRequest in the resumption flow? That would > add an additional round trip. (Your numbers in milliseconds are of > course not transferrable to other systems; round-trips is an easier to > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 both have > message-flow diagrams that show the number of round trips in various > handshake flows. Care should also be taken about when you are starting your "timer" and when you stop it, e.g. if you stop your timer after the session ticket data has been received by the client then this is not a "fair" test (the connection is ready for data transfer earlier than the arrival of the session ticket). I would expect to see the TLS1.3 latency for a full handshake to be around the same as for a TLS1.2 resumption handshake. With a TLS1.3 resumption only marginally different. There are the same number of round trips for a TLS1.3 full handshake as that there are for a resumption one. The primary difference is that the Certificate message is not sent (which can be quite a large message). Your timings suggest you are testing this over a LAN where the effects of network latency are going to be relatively low. The real benefits from fewer round trips will really be seen when network latency is more significant. > >> 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS >> 1.3 RFC. How do we generate pre-shared keys in advance even without >> making the first connection. Can someone guide me in the right direction. As Ben says this is not currently supported in master but there is pending WIP PR to add it. >> > > The security properties of such "external" PSKs are substantially > different than the "ephemeral" PSKs used in resumption flows. Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE based secret (assuming a suitable kex_mode is used). What do you see as the concern? Matt From npathak2 at ncsu.edu Fri Jun 16 22:51:08 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Fri, 16 Jun 2017 15:51:08 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: Thanks Matt, Appreciate ur response and tips On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell wrote: > > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote: > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: > >> Hello > >> Thanks > >> I tried reading some content from the server side and I observed the > >> new_session_cb getting invoked in that case on the client side. I > >> understand that may be due to delayed NewSession info transfer from > >> server side to client side. But it is helpful for saving the session > >> info on the client side. (Thanks Matt for your input) > >> > >> However, now I have two concerns > >> > >> 1) I see that latency for handshake with session resumption in TLS 1.3 > >> has not improved as much as it improves for TLS 1.2 > >> With TLS 1.3, I observed that resumption brings down the connection > >> time from 2.5 ms to 1.2-1.3 ms > >> while with TLS 1.2 (using either session IDs or tickets), the > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. > >> > >> The whole code is similar for running the two experiments with only > >> max TLS version changed. Can someone comment on the latency > >> measurements for the two cases. > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please > >> comment. > >> > > > > Are you seeing a HelloRetryRequest in the resumption flow? That would > > add an additional round trip. (Your numbers in milliseconds are of > > course not transferrable to other systems; round-trips is an easier to > > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 both have > > message-flow diagrams that show the number of round trips in various > > handshake flows. > > Care should also be taken about when you are starting your "timer" and > when you stop it, e.g. if you stop your timer after the session ticket > data has been received by the client then this is not a "fair" test (the > connection is ready for data transfer earlier than the arrival of the > session ticket). > > I would expect to see the TLS1.3 latency for a full handshake to be > around the same as for a TLS1.2 resumption handshake. With a TLS1.3 > resumption only marginally different. There are the same number of round > trips for a TLS1.3 full handshake as that there are for a resumption > one. The primary difference is that the Certificate message is not sent > (which can be quite a large message). > > Your timings suggest you are testing this over a LAN where the effects > of network latency are going to be relatively low. The real benefits > from fewer round trips will really be seen when network latency is more > significant. > In my application program, I put start and stop timer before and after SSL_accept on server side and before and after SSL_connect on the client side. I am not sure how I can put timers at individual steps of Handshake using my client applications. I was assuming SSL and SSL_accept take care of the entire handshake process. Yes, I am testing on local machine. I will migrate my test to remote machines. But I am not really able to understand why TLS 1.3 is slower on my machine. Also, it is difficult to see all the messages for TLS 1.3 since all messages after server hello are encrypted when I see on Wireshark. So I am not sure where exactly session ticket info is exchanged > > > > >> 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS > >> 1.3 RFC. How do we generate pre-shared keys in advance even without > >> making the first connection. Can someone guide me in the right > direction. > > As Ben says this is not currently supported in master but there is > pending WIP PR to add it. > > >> > > > > The security properties of such "external" PSKs are substantially > > different than the "ephemeral" PSKs used in resumption flows. > > Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE > based secret (assuming a suitable kex_mode is used). What do you see as > the concern? > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Sat Jun 17 00:54:47 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 16 Jun 2017 19:54:47 -0500 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: <186e8a74-0c93-09a9-e786-5e5b0f9512b0@akamai.com> On 06/16/2017 05:36 PM, Matt Caswell wrote: >> The security properties of such "external" PSKs are substantially >> different than the "ephemeral" PSKs used in resumption flows. > Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE > based secret (assuming a suitable kex_mode is used). What do you see as > the concern? The risk of accidentally using psk_ke instead of psk_dhe_ke is noticeable, and in terms of concrete differences, there are additional requirements on external PSKs that the KDF and PSK identity must remain fixed across uses. That, combined with the potential for insufficient entropy during key generation (mentioned in section 2.2 of draft-20) seem to provide more openings for cryptographic attacks than for the full resumption flow. It is probably fine for uses where the other properties of external PSKs are needed, but I'm not sure that the risk/reward balance favors using it just to get a speedup -- TLS 1.3 resumption should already be pretty fast. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Sat Jun 17 01:15:47 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Fri, 16 Jun 2017 18:15:47 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: <186e8a74-0c93-09a9-e786-5e5b0f9512b0@akamai.com> References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> <186e8a74-0c93-09a9-e786-5e5b0f9512b0@akamai.com> Message-ID: Benjamin/Matt, Appreciate your tips and help so far. Could you give me any pointers for placing my timestamps within the OpenSSl code for right measurement for handshake. I am reading through the master code. I think since in TLS 1.3 is session tickets are sent after handshake, it would be ok to place a timestamp in the *ossl_statem_server_pre_work *function before *tls_finish_handshake* is called (This function is in state_srvr.c which updates the stjatemachine I think). *It is only called for TLS 1.3* *But I do not see any significant change when I put a timestamp here or at the end of SSL_accept on my server application program.* *Any help for the right location of time stamps will be appreciated.* *case* *TLS_ST_SW_SESSION_TICKET*: *if* (SSL_IS_TLS13(s)) { /* * Actually this is the end of the handshake, but we're going * straight into writing the session ticket out. So we finish off * the handshake, but keep the various buffers active. */ /***************************End time stamp*****************************************************/ *struct* timespec end; *clock_gettime*(CLOCK_MONOTONIC_RAW, &end); uint64_t tempTimeEnd = end.tv_nsec / 1000; *printf*("Handshake End time : %llu \n", tempTimeEnd); *return* tls_finish_handshake(s, wst, 0); } *if* (SSL_IS_DTLS(s)) { /* * We're into the last flight. We don't retransmit the last flight * unless we need to, so we don't use the timer */ st->use_timer = 0; } Thanks BR, Neetish On Fri, Jun 16, 2017 at 5:54 PM, Benjamin Kaduk via openssl-users < openssl-users at openssl.org> wrote: > On 06/16/2017 05:36 PM, Matt Caswell wrote: > > The security properties of such "external" PSKs are substantially > different than the "ephemeral" PSKs used in resumption flows. > > Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE > based secret (assuming a suitable kex_mode is used). What do you see as > the concern? > > > The risk of accidentally using psk_ke instead of psk_dhe_ke is noticeable, > and in terms of concrete differences, there are additional requirements on > external PSKs that the KDF and PSK identity must remain fixed across uses. > That, combined with the potential for insufficient entropy during key > generation (mentioned in section 2.2 of draft-20) seem to provide more > openings for cryptographic attacks than for the full resumption flow. It > is probably fine for uses where the other properties of external PSKs are > needed, but I'm not sure that the risk/reward balance favors using it just > to get a speedup -- TLS 1.3 resumption should already be pretty fast. > > -Ben > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Sun Jun 18 17:03:12 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Sun, 18 Jun 2017 22:33:12 +0530 Subject: [openssl-users] FIPS CAVP tests for WinCE. Message-ID: Hi All, I am using OpenSSL-FIPS-2.0.4 library on ARM7 + WinCE 6.0 with "user affirm" the validation for Y per I.G. G.5. We want to run latest CAVP test suites. We have built the *build_algvs and other executable* for the above product/build environment. However when we are trying to execute the executable with req file and resp file parameters, example fips_drbgvs CTR_DRBG.req CTR_DRBG.resp we end up in receiving error "error opening the input file". Later we found that WinCE environment cannot read simple character file name, it needs some windows specific conversion like WideCharToMultiByte. We have the below questions, 1. Is there any way to build the test suites on WinCE environment. User guide says it is incomplete? 2. As these are test files, is it OK to modify them? Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Jun 19 12:49:09 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 19 Jun 2017 13:49:09 +0100 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: On 16/06/17 23:51, Neetish Pathak wrote: > Thanks Matt, Appreciate ur response and tips > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > wrote: > > > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote: > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: > >> Hello > >> Thanks > >> I tried reading some content from the server side and I observed the > >> new_session_cb getting invoked in that case on the client side. I > >> understand that may be due to delayed NewSession info transfer from > >> server side to client side. But it is helpful for saving the session > >> info on the client side. (Thanks Matt for your input) > >> > >> However, now I have two concerns > >> > >> 1) I see that latency for handshake with session resumption in > TLS 1.3 > >> has not improved as much as it improves for TLS 1.2 > >> With TLS 1.3, I observed that resumption brings down the connection > >> time from 2.5 ms to 1.2-1.3 ms > >> while with TLS 1.2 (using either session IDs or tickets), the > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. > >> > >> The whole code is similar for running the two experiments with only > >> max TLS version changed. Can someone comment on the latency > >> measurements for the two cases. > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please > >> comment. > >> > > > > Are you seeing a HelloRetryRequest in the resumption flow? That would > > add an additional round trip. (Your numbers in milliseconds are of > > course not transferrable to other systems; round-trips is an easier to > > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 both have > > message-flow diagrams that show the number of round trips in various > > handshake flows. > > Care should also be taken about when you are starting your "timer" and > when you stop it, e.g. if you stop your timer after the session ticket > data has been received by the client then this is not a "fair" test (the > connection is ready for data transfer earlier than the arrival of the > session ticket). > > I would expect to see the TLS1.3 latency for a full handshake to be > around the same as for a TLS1.2 resumption handshake. With a TLS1.3 > resumption only marginally different. There are the same number of round > trips for a TLS1.3 full handshake as that there are for a resumption > one. The primary difference is that the Certificate message is not sent > (which can be quite a large message). > > Your timings suggest you are testing this over a LAN where the effects > of network latency are going to be relatively low. The real benefits > from fewer round trips will really be seen when network latency is more > significant. > > > > In my application program, I put start and stop timer before and after > SSL_accept on server side and before and after SSL_connect on the client > side. That should be fine (my worry was that you might also be including the subsequent session ticket transfer). > I am not sure how I can put timers at individual steps of Handshake > using my client applications. I was assuming SSL and SSL_accept take > care of the entire handshake process. > > Yes, I am testing on local machine. I will migrate my test to remote > machines. But I am not really able to understand why TLS 1.3 is slower > on my machine. If you are on a local machine I would not expect a significant speed up in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of round-trips required in order to avoid unnecessary network latency. If you are on a local machine then there isn't any significant network latency anyway - so timings are presumably dominated by the CPU intensive tasks. You should make sure that you are comparing like with like, i.e. the same ciphers, key lengths, key exchange algorithms, curves etc between TLSv1.2 and TLSv1.3. Differences in any one of these could obviously have significant performance impacts. Matt From smds.gladiator at gmail.com Mon Jun 19 12:55:43 2017 From: smds.gladiator at gmail.com (smds gladiator) Date: Mon, 19 Jun 2017 18:25:43 +0530 Subject: [openssl-users] Android (ARM) build support Message-ID: Hello Everyone, I am developing an android application which has a native stack underneath. My project will use native OpenSSL library. What i would to know is whether android platform (ARM arch) support for OpenSSL library is there or not. Please help me know how do I proceed building and using in my android app. Thank you, Senthil Kumar G S -------------- next part -------------- An HTML attachment was scrubbed... URL: From TopolewskiT at cumminsallison.com Mon Jun 19 16:58:34 2017 From: TopolewskiT at cumminsallison.com (Topolewski, Tom) Date: Mon, 19 Jun 2017 16:58:34 +0000 Subject: [openssl-users] Building OpenSSL-1.1.0f for WinCE (Windows Embedded Compact 7.0) Message-ID: Hello, This is the first time I'm building OpenSSL for any platform (I'm pretty new to this solution). I'm trying to build OpenSSL 1.1.0f library on ARM7 (backwards compatible, SDK version is ARM4) running Windows Embedded Compact 7.0. I'm hoping to implement a client interfacing web service requiring TLS 1.2 with the https connections. I'm following this instructions: http://documentation.unified-automation.com/uasdkcpp/1.5.2/html/CompileOpenSSLCE.html wcecompat compatibility library is compiled successfully - I'm getting two libraries: wcecompat.lib and wcecompatex.lib. Because with the 1.1.0 release the build process has changed I'm looking at this site as well: https://stackoverflow.com/questions/39076244/why-there-is-no-ms-do-ms-bat-after-perl-configure-vc-win64a Since I'm not sure where my problem is I will provide the list of steps I'm taking: 1. In Cygwin64 Terminal: tar -xvzf openssl-1.1.0f.tar.gz 2. In Visual Studio 2008 Command Prompt I'm changing directory to C:\cygwin64\home\myaccount\openssl-1.1.0f and entering the following: set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include; set LIB=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\LIB;C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib; set LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\LIB; set Path=C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCPackages;C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin;C:\cygwin64\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; set OSVERSION=WCE700 set PLATFORM=VC-CE set TARGETCPU=ARMV4I set WCECOMPAT="C:\cygwin64\home\myaccount\wcecompat-master" set LIB=C:\Program Files (x86)\Windows CE Tools\SDKs\CA_MM2_CE7\Lib\ARMv4I;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ce\lib\ARMV4I;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib set INCLUDE=C:\Program Files (x86)\Windows CE Tools\SDKs\CA_MM2_CE7\Include\Armv4i;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include; set Path=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ce\bin\x86_arm;C:\Perl64\site\bin;%Path% set LIBPATH="C:\Program Files (x86)\Windows CE Tools\SDKs\CA_MM2_CE7\Lib\ARMv4I";C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ce\lib\ARMV4I; 3. Configuring the make file with the following (full path to perl to make sure ActivePerl-5.24.0.2400 is used): c:\Perl64\bin\perl Configure no-idea no-mdc2 no-rc5 no-asm no-ssl3 VC-CE Configuring OpenSSL version 1.1.0f (0x1010006fL) no-asan [default] OPENSSL_NO_ASAN no-asm [option] OPENSSL_NO_ASM no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG no-crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 no-egd [default] OPENSSL_NO_EGD no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER no-heartbeats [default] OPENSSL_NO_HEARTBEATS no-idea [option] OPENSSL_NO_IDEA (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-mdc2 [option] OPENSSL_NO_MDC2 (skip dir) no-msan [default] OPENSSL_NO_MSAN no-rc5 [option] OPENSSL_NO_RC5 (skip dir) no-sctp [default] OPENSSL_NO_SCTP no-ssl-trace [default] OPENSSL_NO_SSL_TRACE no-ssl3 [option] OPENSSL_NO_SSL3 no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD no-ubsan [default] OPENSSL_NO_UBSAN no-unit-test [default] OPENSSL_NO_UNIT_TEST no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS no-zlib [default] no-zlib-dynamic [default] Configuring for VC-CE CC =cl CFLAG =/W3 /WX /GF /Gy /nologo -DUNICODE -D_UNICODE -DOPENSSL_SYS_WINCE-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DNO_CHMOD -DOPENSSL_SMALL_FOOTPRINT -D_WIN32_WCE=700 -DUNDER_CE=700 -DWCE_PLATFORM_VC-CE -DARM -D_ARM_ -DARMV4I -QRarch4T -QRinterwork-return -I$(WCECOMPAT)/include /MD /O1i SHARED_CFLAG = DEFINES =DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL _PIC LFLAG =/nologo /opt:ref /subsystem:windowsce,7.00 /machine:THUMB PLIB_LFLAG = EX_LIBS =3 APPS_OBJ =win32_init.o CPUID_OBJ =mem_clr.o UPLINK_OBJ = BN_ASM =bn_asm.o EC_ASM = DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM = RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ = PADLOCK_OBJ = CHACHA_ENC =chacha_enc.o POLY1305_OBJ = BLAKE2_OBJ = PROCESSOR = RANLIB =true ARFLAGS =/nologo PERL =c:\Perl64\bin\perl.exe THIRTY_TWO_BIT mode BN_LLONG mode Configured for VC-CE. 4. Compiling the library with the following: nmake Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. "c:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl" "-omakefile" "crypto\include\internal\bn_conf.h.in" > crypto\include\internal\bn_conf.h "c:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl" "-omakefile" "crypto\include\internal\dso_conf.h.in" > crypto\include\internal\dso_conf.h "c:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl" "-omakefile" "include\openssl\opensslconf.h.in" > include\openssl\opensslconf.h "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe" depend && "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe" _all Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. cl /I "." /I "crypto\include" /I "include" -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC "-DENGINESDIR=\"C:\\ProgramFiles\\OpenSSL\\lib\\engines-1_1\"" "-DOPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" /W3 /WX /GF /Gy /nologo -DUNICODE -D_UNICODE -DOPENSSL_SYS_WINCE -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DNO_CHMOD -DOPENSSL_SMALL_FOOTPRINT -D_WIN32_WCE=700 -DUNDER_CE=700 -DWCE_PLATFORM_VC-CE -DARM -D_ARM_ -DARMV4I -QRarch4T -QRinterwork-return -I"C:\cygwin64\home\myaccount\wcecompat-master"/include /MD /O1i /Zi /Fdossl_static -c /Focrypto\aes\aes_ige.obj "crypto\aes\aes_ige.c" aes_ige.c C:\cygwin64\home\myaccount\openssl-1.1.0f\e_os.h(485) : error C2220: warning treated as error - no 'object' file generated C:\cygwin64\home\myaccount\openssl-1.1.0f\e_os.h(485) : warning C4005: 'open' : macro redefinition C:\cygwin64\home\myaccount\wcecompat-master\include\io.h(25) : see previous definition of 'open' C:\cygwin64\home\myaccount\openssl-1.1.0f\e_os.h(486) : warning C4005: 'fdopen' : macro redefinition C:\cygwin64\home\myaccount\wcecompat-master\include\io.h(38) : see previous definition of 'fdopen' C:\cygwin64\home\myaccount\openssl-1.1.0f\e_os.h(487) : warning C4005: 'close' : macro redefinition C:\cygwin64\home\myaccount\wcecompat-master\include\io.h(27) : see previous definition of 'close' C:\cygwin64\home\myaccount\openssl-1.1.0f\e_os.h(491) : warning C4005: 'unlink' : macro redefinition C:\cygwin64\home\myaccount\wcecompat-master\include\io.h(32) : see previous definition of 'unlink' NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ce\bin\x86_arm\cl.EXE"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe"' : return code '0x2' Stop. This may be something simple but I use Visual Studio 2008 to build my code and manually setting up the build process is not simple for me. I would appreciate if someone could point me into a right direction. Thank you in advance. I also tried to build openssl-1.0.2l (following the same instructions). I went a little further seeing link errors and one lib (libeay32d.lib) generated but that's not an expected result. Best regards, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Mon Jun 19 18:11:03 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Mon, 19 Jun 2017 11:11:03 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: Hi Matt, Thanks Could you help with following queries 1) On the blogpost for TLS1.3, you mentions the following in the session section The specification recommends that applications only use a session once (although this is not enforced). For this reason some servers send multiple session messages to a client. To enforce the ?use once? recommendation applications could use SSL_CTX_remove_session() to mark a session as non-resumable (and remove it from the cache) once it has been used. I am a bit confused here as to why "use once" is recommended. How will resumption be ensured then ? I get a PSK in first connection and use it again for all the other connections. 2) Can you suggest some places to put a time stamp in OpenSSL code. Thanks Best Regards, Neetish On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell wrote: > > > On 16/06/17 23:51, Neetish Pathak wrote: > > Thanks Matt, Appreciate ur response and tips > > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > wrote: > > > > > > > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote: > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: > > >> Hello > > >> Thanks > > >> I tried reading some content from the server side and I observed > the > > >> new_session_cb getting invoked in that case on the client side. I > > >> understand that may be due to delayed NewSession info transfer > from > > >> server side to client side. But it is helpful for saving the > session > > >> info on the client side. (Thanks Matt for your input) > > >> > > >> However, now I have two concerns > > >> > > >> 1) I see that latency for handshake with session resumption in > > TLS 1.3 > > >> has not improved as much as it improves for TLS 1.2 > > >> With TLS 1.3, I observed that resumption brings down the > connection > > >> time from 2.5 ms to 1.2-1.3 ms > > >> while with TLS 1.2 (using either session IDs or tickets), the > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. > > >> > > >> The whole code is similar for running the two experiments with > only > > >> max TLS version changed. Can someone comment on the latency > > >> measurements for the two cases. > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. > Please > > >> comment. > > >> > > > > > > Are you seeing a HelloRetryRequest in the resumption flow? That > would > > > add an additional round trip. (Your numbers in milliseconds are of > > > course not transferrable to other systems; round-trips is an > easier to > > > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 both have > > > message-flow diagrams that show the number of round trips in > various > > > handshake flows. > > > > Care should also be taken about when you are starting your "timer" > and > > when you stop it, e.g. if you stop your timer after the session > ticket > > data has been received by the client then this is not a "fair" test > (the > > connection is ready for data transfer earlier than the arrival of the > > session ticket). > > > > I would expect to see the TLS1.3 latency for a full handshake to be > > around the same as for a TLS1.2 resumption handshake. With a TLS1.3 > > resumption only marginally different. There are the same number of > round > > trips for a TLS1.3 full handshake as that there are for a resumption > > one. The primary difference is that the Certificate message is not > sent > > (which can be quite a large message). > > > > Your timings suggest you are testing this over a LAN where the > effects > > of network latency are going to be relatively low. The real benefits > > from fewer round trips will really be seen when network latency is > more > > significant. > > > > > > > > In my application program, I put start and stop timer before and after > > SSL_accept on server side and before and after SSL_connect on the client > > side. > > That should be fine (my worry was that you might also be including the > subsequent session ticket transfer). > > > I am not sure how I can put timers at individual steps of Handshake > > using my client applications. I was assuming SSL and SSL_accept take > > care of the entire handshake process. > > > > Yes, I am testing on local machine. I will migrate my test to remote > > machines. But I am not really able to understand why TLS 1.3 is slower > > on my machine. > > If you are on a local machine I would not expect a significant speed up > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of > round-trips required in order to avoid unnecessary network latency. If > you are on a local machine then there isn't any significant network > latency anyway - so timings are presumably dominated by the CPU > intensive tasks. You should make sure that you are comparing like with > like, i.e. the same ciphers, key lengths, key exchange algorithms, > curves etc between TLSv1.2 and TLSv1.3. Differences in any one of these > could obviously have significant performance impacts. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Mon Jun 19 21:12:43 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Mon, 19 Jun 2017 14:12:43 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <8d959ffc-9a22-e3dd-4c83-63dcc3884895@openssl.org> <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak wrote: > Hi Matt, > Thanks > Could you help with following queries > > 1) On the blogpost for TLS1.3, you mentions the following in the session > section > The specification recommends that applications only use a session once > (although this is not enforced). For this reason some servers send multiple > session messages to a client. To enforce the ?use once? recommendation > applications could use SSL_CTX_remove_session() to mark a session as > non-resumable (and remove it from the cache) once it has been used. > > I am a bit confused here as to why "use once" is recommended. How will > resumption be ensured then ? I get a PSK in first connection and use it > again for all the other connections. > > > 2) Can you suggest some places to put a time stamp in OpenSSL code. > > Thanks > Best Regards, > Neetish > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell wrote: > >> >> >> On 16/06/17 23:51, Neetish Pathak wrote: >> > Thanks Matt, Appreciate ur response and tips >> > >> > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > > wrote: >> > >> > >> > >> > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote: >> > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: >> > >> Hello >> > >> Thanks >> > >> I tried reading some content from the server side and I >> observed the >> > >> new_session_cb getting invoked in that case on the client side. I >> > >> understand that may be due to delayed NewSession info transfer >> from >> > >> server side to client side. But it is helpful for saving the >> session >> > >> info on the client side. (Thanks Matt for your input) >> > >> >> > >> However, now I have two concerns >> > >> >> > >> 1) I see that latency for handshake with session resumption in >> > TLS 1.3 >> > >> has not improved as much as it improves for TLS 1.2 >> > >> With TLS 1.3, I observed that resumption brings down the >> connection >> > >> time from 2.5 ms to 1.2-1.3 ms >> > >> while with TLS 1.2 (using either session IDs or tickets), the >> > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. >> > >> >> > >> The whole code is similar for running the two experiments with >> only >> > >> max TLS version changed. Can someone comment on the latency >> > >> measurements for the two cases. >> > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. >> Please >> > >> comment. >> > >> >> > > >> > > Are you seeing a HelloRetryRequest in the resumption flow? That >> would >> > > add an additional round trip. (Your numbers in milliseconds are >> of >> > > course not transferrable to other systems; round-trips is an >> easier to >> > > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 both >> have >> > > message-flow diagrams that show the number of round trips in >> various >> > > handshake flows. >> > >> > Care should also be taken about when you are starting your "timer" >> and >> > when you stop it, e.g. if you stop your timer after the session >> ticket >> > data has been received by the client then this is not a "fair" test >> (the >> > connection is ready for data transfer earlier than the arrival of >> the >> > session ticket). >> > >> > I would expect to see the TLS1.3 latency for a full handshake to be >> > around the same as for a TLS1.2 resumption handshake. With a TLS1.3 >> > resumption only marginally different. There are the same number of >> round >> > trips for a TLS1.3 full handshake as that there are for a resumption >> > one. The primary difference is that the Certificate message is not >> sent >> > (which can be quite a large message). >> > Yes Matt, when I switch to remote machines and test my application programs, I see that TLS 1.3 is faster than TLS 1.2 in the first connection (around same time as resumption time in TLS 1.2) itself and there is marginal or no improvement in the subsequent connections even on using resumption. Does this mean that resumption in TLS 1.3 is bringing not much benefit in terms of latency. It makes sense because round trips count for resumption or no resumption is 1 in TLS 1.3. The only benefit with resumption is that the client can now send zero-RTT data. (early data). However, if we consider the overall latency in handshake, it is going to be the same equivalent to 1 round trip. Is my understanding correct ? Is there any way to enable early data or it gets activated by default once the pre-shared keys are available at both the client and server ends ? I believe session resumption as a concept doesn't hold that much value from TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first connection. Do you agree? > > >> > Your timings suggest you are testing this over a LAN where the >> effects >> > of network latency are going to be relatively low. The real benefits >> > from fewer round trips will really be seen when network latency is >> more >> > significant. >> > >> > >> > >> > In my application program, I put start and stop timer before and after >> > SSL_accept on server side and before and after SSL_connect on the client >> > side. >> >> That should be fine (my worry was that you might also be including the >> subsequent session ticket transfer). >> >> > I am not sure how I can put timers at individual steps of Handshake >> > using my client applications. I was assuming SSL and SSL_accept take >> > care of the entire handshake process. >> > >> > Yes, I am testing on local machine. I will migrate my test to remote >> > machines. But I am not really able to understand why TLS 1.3 is slower >> > on my machine. >> >> If you are on a local machine I would not expect a significant speed up >> in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of >> round-trips required in order to avoid unnecessary network latency. If >> you are on a local machine then there isn't any significant network >> latency anyway - so timings are presumably dominated by the CPU >> intensive tasks. You should make sure that you are comparing like with >> like, i.e. the same ciphers, key lengths, key exchange algorithms, >> curves etc between TLSv1.2 and TLSv1.3. Differences in any one of these >> could obviously have significant performance impacts. >> >> Matt >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Tue Jun 20 04:21:32 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 19 Jun 2017 23:21:32 -0500 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: <4f35952e-c2ce-4d6d-f18f-8cad527c2011@akamai.com> On 06/19/2017 04:12 PM, Neetish Pathak wrote: > > > On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak > wrote: > > Hi Matt, > Thanks > Could you help with following queries > > 1) On the blogpost for TLS1.3, you mentions the following in the > session section > The specification recommends that applications only use a session > once (although this is not enforced). For this reason some servers > send multiple session messages to a client. To enforce the ?use > once? recommendation applications could > use |SSL_CTX_remove_session()| to mark a session as non-resumable > (and remove it from the cache) once it has been used. > > I am a bit confused here as to why "use once" is recommended. How > will resumption be ensured then ? I get a PSK in first connection > and use it again for all the other connections. > "use once" is recommended in a limited circumstance, to prevent an attacker listening on the network from associating the (multiple) resumed sessions as being derived from the initial session. This is a new possibility in TLS 1.3, since in TLS 1.2 the session ticket was given to the client in cleartext (and presented back to the server in cleartext), so all uses of the ticket were traceable back to the original connection and linkable to each other. Using a given ticket more than once in TLS 1.3 just brings things back to basically the TLS 1.2 state in terms of linkability; it's not a catastrophic failure or anything like that. > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell > wrote: > > > > Yes Matt, when I switch to remote machines and test my application > programs, I see that TLS 1.3 is faster than TLS 1.2 in the first > connection (around same time as resumption time in TLS 1.2) itself and > there is marginal or no improvement in the subsequent connections even > on using resumption. Does this mean that resumption in TLS 1.3 is > bringing not much benefit in terms of latency. It makes sense because > round trips count for resumption or no resumption is 1 in TLS 1.3. > > The only benefit with resumption is that the client can now send > zero-RTT data. (early data). However, if we consider the overall > latency in handshake, it is going to be the same equivalent to 1 round > trip. > Is my understanding correct ? > > Is there any way to enable early data or it gets activated by default > once the pre-shared keys are available at both the client and server > ends ? > No no no no no, many times no. You really must not blindly enable early data without a proper protocol analysis to determine what would happen if an attacker replayed the early data millions of times, as is possible with the current TLS 1.3 draft specification. There are a lot of ways to hurt yourself and your users with it, and I strongly recommend against trying to enable it just because it looks faster. (There are separate APIs from the normal read/write APIs to use early data, to make you explicitly think about whether it's safe when adding support to an application.) > I believe session resumption as a concept doesn't hold that much value > from TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first > connection. Do you agree? > No. Resumption saves on transferring (and validating!) certificates and can be done without incurring the cost of an additional diffie-hellman exchange, among other things. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jun 20 09:09:00 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 20 Jun 2017 10:09:00 +0100 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: On 19/06/17 19:11, Neetish Pathak wrote: > 2) Can you suggest some places to put a time stamp in OpenSSL code. I agree with Ben's responses to all your other questions. For this question, I'm not sure what you are trying to achieve? Starting before SSL_accept/SSL_connect and finishing after they return should be fine. Or are you looking for a breakdown of where the time is going? Matt > > Thanks > Best Regards, > Neetish > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell > wrote: > > > > On 16/06/17 23:51, Neetish Pathak wrote: > > Thanks Matt, Appreciate ur response and tips > > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > >> wrote: > > > > > > > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote: > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: > > >> Hello > > >> Thanks > > >> I tried reading some content from the server side and I > observed the > > >> new_session_cb getting invoked in that case on the client > side. I > > >> understand that may be due to delayed NewSession info > transfer from > > >> server side to client side. But it is helpful for saving > the session > > >> info on the client side. (Thanks Matt for your input) > > >> > > >> However, now I have two concerns > > >> > > >> 1) I see that latency for handshake with session resumption in > > TLS 1.3 > > >> has not improved as much as it improves for TLS 1.2 > > >> With TLS 1.3, I observed that resumption brings down the > connection > > >> time from 2.5 ms to 1.2-1.3 ms > > >> while with TLS 1.2 (using either session IDs or tickets), the > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. > > >> > > >> The whole code is similar for running the two experiments > with only > > >> max TLS version changed. Can someone comment on the latency > > >> measurements for the two cases. > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my > opinion. Please > > >> comment. > > >> > > > > > > Are you seeing a HelloRetryRequest in the resumption flow? > That would > > > add an additional round trip. (Your numbers in milliseconds > are of > > > course not transferrable to other systems; round-trips is an > easier to > > > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 > both have > > > message-flow diagrams that show the number of round trips in > various > > > handshake flows. > > > > Care should also be taken about when you are starting your > "timer" and > > when you stop it, e.g. if you stop your timer after the > session ticket > > data has been received by the client then this is not a "fair" > test (the > > connection is ready for data transfer earlier than the arrival > of the > > session ticket). > > > > I would expect to see the TLS1.3 latency for a full handshake > to be > > around the same as for a TLS1.2 resumption handshake. With a > TLS1.3 > > resumption only marginally different. There are the same > number of round > > trips for a TLS1.3 full handshake as that there are for a > resumption > > one. The primary difference is that the Certificate message is > not sent > > (which can be quite a large message). > > > > Your timings suggest you are testing this over a LAN where the > effects > > of network latency are going to be relatively low. The real > benefits > > from fewer round trips will really be seen when network > latency is more > > significant. > > > > > > > > In my application program, I put start and stop timer before and after > > SSL_accept on server side and before and after SSL_connect on the > client > > side. > > That should be fine (my worry was that you might also be including the > subsequent session ticket transfer). > > > I am not sure how I can put timers at individual steps of Handshake > > using my client applications. I was assuming SSL and SSL_accept take > > care of the entire handshake process. > > > > Yes, I am testing on local machine. I will migrate my test to remote > > machines. But I am not really able to understand why TLS 1.3 is slower > > on my machine. > > If you are on a local machine I would not expect a significant speed up > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of > round-trips required in order to avoid unnecessary network latency. If > you are on a local machine then there isn't any significant network > latency anyway - so timings are presumably dominated by the CPU > intensive tasks. You should make sure that you are comparing like with > like, i.e. the same ciphers, key lengths, key exchange algorithms, > curves etc between TLSv1.2 and TLSv1.3. Differences in any one of these > could obviously have significant performance impacts. > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From npathak2 at ncsu.edu Tue Jun 20 18:52:23 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Tue, 20 Jun 2017 11:52:23 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: <4f35952e-c2ce-4d6d-f18f-8cad527c2011@akamai.com> References: <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> <4f35952e-c2ce-4d6d-f18f-8cad527c2011@akamai.com> Message-ID: Thanks Ben for all the replies and your comments. They are extremely useful for my study On Mon, Jun 19, 2017 at 9:21 PM, Benjamin Kaduk wrote: > On 06/19/2017 04:12 PM, Neetish Pathak wrote: > > > > On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak > wrote: > >> Hi Matt, >> Thanks >> Could you help with following queries >> >> 1) On the blogpost for TLS1.3, you mentions the following in the session >> section >> The specification recommends that applications only use a session once >> (although this is not enforced). For this reason some servers send multiple >> session messages to a client. To enforce the ?use once? recommendation >> applications could use SSL_CTX_remove_session() to mark a session as >> non-resumable (and remove it from the cache) once it has been used. >> >> I am a bit confused here as to why "use once" is recommended. How will >> resumption be ensured then ? I get a PSK in first connection and use it >> again for all the other connections. >> >> > "use once" is recommended in a limited circumstance, to prevent an > attacker listening on the network from associating the (multiple) resumed > sessions as being derived from the initial session. > This is a new possibility in TLS 1.3, since in TLS 1.2 the session ticket > was given to the client in cleartext (and presented back to the server in > cleartext), so all uses of the ticket were traceable back to the original > connection and linkable to each other. > > Using a given ticket more than once in TLS 1.3 just brings things back to > basically the TLS 1.2 state in terms of linkability; it's not a > catastrophic failure or anything like that. > > >> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell wrote: >> >>> >>> > Yes Matt, when I switch to remote machines and test my application > programs, I see that TLS 1.3 is faster than TLS 1.2 in the first connection > (around same time as resumption time in TLS 1.2) itself and there is > marginal or no improvement in the subsequent connections even on using > resumption. Does this mean that resumption in TLS 1.3 is bringing not much > benefit in terms of latency. It makes sense because round trips count for > resumption or no resumption is 1 in TLS 1.3. > > The only benefit with resumption is that the client can now send zero-RTT > data. (early data). However, if we consider the overall latency in > handshake, it is going to be the same equivalent to 1 round trip. > Is my understanding correct ? > > Is there any way to enable early data or it gets activated by default once > the pre-shared keys are available at both the client and server ends ? > > > No no no no no, many times no. > You really must not blindly enable early data without a proper protocol > analysis to determine what would happen if an attacker replayed the early > data millions of times, as is possible with the current TLS 1.3 draft > specification. There are a lot of ways to hurt yourself and your users > with it, and I strongly recommend against trying to enable it just because > it looks faster. > (There are separate APIs from the normal read/write APIs to use early > data, to make you explicitly think about whether it's safe when adding > support to an application.) > > > The comments give me much food for thought. I am still wondering on on the possibility for replay attacks when early data is enabled. Sorry, I am new to OpenSSL or TLS and have so many doubts. So, I understood replay attacks are possible as in early data enabled mode, data will go in the cleartext form along with clientHello, so a middleman can look into the data and replay it later. I was thinking if we use some kind of sequence number/ timestamps (as possible solution) to avoid this or it has been implemented in OpenSSL ? I am using the application for an internal project which is not going to be public. So, I am wondering if it can be used. Nevertheless, your recommendation is duly noted. > I believe session resumption as a concept doesn't hold that much value > from TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first > connection. Do you agree? > > > No. Resumption saves on transferring (and validating!) certificates and > can be done without incurring the cost of an additional diffie-hellman > exchange, among other things. > > -Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Tue Jun 20 18:52:44 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Tue, 20 Jun 2017 11:52:44 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: I Appreciate your response On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell wrote: > > > On 19/06/17 19:11, Neetish Pathak wrote: > > 2) Can you suggest some places to put a time stamp in OpenSSL code. > > I agree with Ben's responses to all your other questions. For this > question, I'm not sure what you are trying to achieve? Starting before > SSL_accept/SSL_connect and finishing after they return should be fine. > Or are you looking for a breakdown of where the time is going? > > Thanks Matt. I was asking for a breakdown since I was not sure if the > SSL_accept and SSL_connect just do the handshake or if they are doing some > other things that may impact latency and CPU usage. Just wanted to be clear > that calling SSL_connect starts ClientHello , SSL_accept unblocks on > receiving ClientHello and sends ServerHello, and both functions return > after sending Finished message from their sides (i.e. client and server). > Matt > > > > > Thanks > > Best Regards, > > Neetish > > > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell > > wrote: > > > > > > > > On 16/06/17 23:51, Neetish Pathak wrote: > > > Thanks Matt, Appreciate ur response and tips > > > > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > > >> wrote: > > > > > > > > > > > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote: > > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: > > > >> Hello > > > >> Thanks > > > >> I tried reading some content from the server side and I > > observed the > > > >> new_session_cb getting invoked in that case on the client > > side. I > > > >> understand that may be due to delayed NewSession info > > transfer from > > > >> server side to client side. But it is helpful for saving > > the session > > > >> info on the client side. (Thanks Matt for your input) > > > >> > > > >> However, now I have two concerns > > > >> > > > >> 1) I see that latency for handshake with session resumption > in > > > TLS 1.3 > > > >> has not improved as much as it improves for TLS 1.2 > > > >> With TLS 1.3, I observed that resumption brings down the > > connection > > > >> time from 2.5 ms to 1.2-1.3 ms > > > >> while with TLS 1.2 (using either session IDs or tickets), > the > > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. > > > >> > > > >> The whole code is similar for running the two experiments > > with only > > > >> max TLS version changed. Can someone comment on the latency > > > >> measurements for the two cases. > > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my > > opinion. Please > > > >> comment. > > > >> > > > > > > > > Are you seeing a HelloRetryRequest in the resumption flow? > > That would > > > > add an additional round trip. (Your numbers in milliseconds > > are of > > > > course not transferrable to other systems; round-trips is an > > easier to > > > > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 > > both have > > > > message-flow diagrams that show the number of round trips in > > various > > > > handshake flows. > > > > > > Care should also be taken about when you are starting your > > "timer" and > > > when you stop it, e.g. if you stop your timer after the > > session ticket > > > data has been received by the client then this is not a "fair" > > test (the > > > connection is ready for data transfer earlier than the arrival > > of the > > > session ticket). > > > > > > I would expect to see the TLS1.3 latency for a full handshake > > to be > > > around the same as for a TLS1.2 resumption handshake. With a > > TLS1.3 > > > resumption only marginally different. There are the same > > number of round > > > trips for a TLS1.3 full handshake as that there are for a > > resumption > > > one. The primary difference is that the Certificate message is > > not sent > > > (which can be quite a large message). > > > > > > Your timings suggest you are testing this over a LAN where the > > effects > > > of network latency are going to be relatively low. The real > > benefits > > > from fewer round trips will really be seen when network > > latency is more > > > significant. > > > > > > > > > > > > In my application program, I put start and stop timer before and > after > > > SSL_accept on server side and before and after SSL_connect on the > > client > > > side. > > > > That should be fine (my worry was that you might also be including > the > > subsequent session ticket transfer). > > > > > I am not sure how I can put timers at individual steps of Handshake > > > using my client applications. I was assuming SSL and SSL_accept > take > > > care of the entire handshake process. > > > > > > Yes, I am testing on local machine. I will migrate my test to > remote > > > machines. But I am not really able to understand why TLS 1.3 is > slower > > > on my machine. > > > > If you are on a local machine I would not expect a significant speed > up > > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the > number of > > round-trips required in order to avoid unnecessary network latency. > If > > you are on a local machine then there isn't any significant network > > latency anyway - so timings are presumably dominated by the CPU > > intensive tasks. You should make sure that you are comparing like > with > > like, i.e. the same ciphers, key lengths, key exchange algorithms, > > curves etc between TLSv1.2 and TLSv1.3. Differences in any one of > these > > could obviously have significant performance impacts. > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Tue Jun 20 23:38:53 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Tue, 20 Jun 2017 16:38:53 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <4decd63ce89340c3b44ef66e26b6cc13@usma1ex-dag1mb1.msg.corp.akamai.com> <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: I wanted to understand the replay attack vulnerability in case of enable early data of TLS 1.3 while false start is secure in that respect as I have read from https://github.com/openssl/openssl/issues/1541 So, with false start, the application data is sent from client after the first leg of the handshake i.e. one round trip is complete, so the data goes encrypted even though the handshake is not completed. In enable early data mode in TLS 1.3 for 0-RTT for session resumption, the application data is sent from the client along with the client hello message. Does the application data in early data mode go as clear text ? I assume this is also encrypted using the PSK because 0-RTT is only applicable when PSK is available on the client side. How is it vulnerable to replay attack. Please help me understand. Is there any API available in OpenSSL for false start ? Thanks Best regards, Neetish On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak wrote: > I Appreciate your response > > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell wrote: > >> >> >> On 19/06/17 19:11, Neetish Pathak wrote: >> > 2) Can you suggest some places to put a time stamp in OpenSSL code. >> >> I agree with Ben's responses to all your other questions. For this >> question, I'm not sure what you are trying to achieve? Starting before >> SSL_accept/SSL_connect and finishing after they return should be fine. >> Or are you looking for a breakdown of where the time is going? >> >> Thanks Matt. I was asking for a breakdown since I was not sure if the >> SSL_accept and SSL_connect just do the handshake or if they are doing some >> other things that may impact latency and CPU usage. Just wanted to be clear >> that calling SSL_connect starts ClientHello , SSL_accept unblocks on >> receiving ClientHello and sends ServerHello, and both functions return >> after sending Finished message from their sides (i.e. client and server). > > > > > >> Matt >> >> > >> > Thanks >> > Best Regards, >> > Neetish >> > >> > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell > > > wrote: >> > >> > >> > >> > On 16/06/17 23:51, Neetish Pathak wrote: >> > > Thanks Matt, Appreciate ur response and tips >> > > >> > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > >> > > >> wrote: >> > > >> > > >> > > >> > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote: >> > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: >> > > >> Hello >> > > >> Thanks >> > > >> I tried reading some content from the server side and I >> > observed the >> > > >> new_session_cb getting invoked in that case on the client >> > side. I >> > > >> understand that may be due to delayed NewSession info >> > transfer from >> > > >> server side to client side. But it is helpful for saving >> > the session >> > > >> info on the client side. (Thanks Matt for your input) >> > > >> >> > > >> However, now I have two concerns >> > > >> >> > > >> 1) I see that latency for handshake with session >> resumption in >> > > TLS 1.3 >> > > >> has not improved as much as it improves for TLS 1.2 >> > > >> With TLS 1.3, I observed that resumption brings down the >> > connection >> > > >> time from 2.5 ms to 1.2-1.3 ms >> > > >> while with TLS 1.2 (using either session IDs or tickets), >> the >> > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. >> > > >> >> > > >> The whole code is similar for running the two experiments >> > with only >> > > >> max TLS version changed. Can someone comment on the latency >> > > >> measurements for the two cases. >> > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my >> > opinion. Please >> > > >> comment. >> > > >> >> > > > >> > > > Are you seeing a HelloRetryRequest in the resumption flow? >> > That would >> > > > add an additional round trip. (Your numbers in milliseconds >> > are of >> > > > course not transferrable to other systems; round-trips is an >> > easier to >> > > > understand number.) RFC 5246 and draft-ietf-tls-tls13-20 >> > both have >> > > > message-flow diagrams that show the number of round trips in >> > various >> > > > handshake flows. >> > > >> > > Care should also be taken about when you are starting your >> > "timer" and >> > > when you stop it, e.g. if you stop your timer after the >> > session ticket >> > > data has been received by the client then this is not a "fair" >> > test (the >> > > connection is ready for data transfer earlier than the arrival >> > of the >> > > session ticket). >> > > >> > > I would expect to see the TLS1.3 latency for a full handshake >> > to be >> > > around the same as for a TLS1.2 resumption handshake. With a >> > TLS1.3 >> > > resumption only marginally different. There are the same >> > number of round >> > > trips for a TLS1.3 full handshake as that there are for a >> > resumption >> > > one. The primary difference is that the Certificate message is >> > not sent >> > > (which can be quite a large message). >> > > >> > > Your timings suggest you are testing this over a LAN where the >> > effects >> > > of network latency are going to be relatively low. The real >> > benefits >> > > from fewer round trips will really be seen when network >> > latency is more >> > > significant. >> > > >> > > >> > > >> > > In my application program, I put start and stop timer before and >> after >> > > SSL_accept on server side and before and after SSL_connect on the >> > client >> > > side. >> > >> > That should be fine (my worry was that you might also be including >> the >> > subsequent session ticket transfer). >> > >> > > I am not sure how I can put timers at individual steps of >> Handshake >> > > using my client applications. I was assuming SSL and SSL_accept >> take >> > > care of the entire handshake process. >> > > >> > > Yes, I am testing on local machine. I will migrate my test to >> remote >> > > machines. But I am not really able to understand why TLS 1.3 is >> slower >> > > on my machine. >> > >> > If you are on a local machine I would not expect a significant >> speed up >> > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the >> number of >> > round-trips required in order to avoid unnecessary network latency. >> If >> > you are on a local machine then there isn't any significant network >> > latency anyway - so timings are presumably dominated by the CPU >> > intensive tasks. You should make sure that you are comparing like >> with >> > like, i.e. the same ciphers, key lengths, key exchange algorithms, >> > curves etc between TLSv1.2 and TLSv1.3. Differences in any one of >> these >> > could obviously have significant performance impacts. >> > >> > 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jun 21 10:11:06 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 21 Jun 2017 11:11:06 +0100 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: References: <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> Message-ID: <3f9e6ff8-d242-20e1-97c9-3c5fb80a4fab@openssl.org> On 21/06/17 00:38, Neetish Pathak wrote: > I wanted to understand the replay attack vulnerability in case of enable > early data of TLS 1.3 while false start is secure in that respect as I > have read from https://github.com/openssl/openssl/issues/1541 > So, with false start, the application data is sent from client after the > first leg of the handshake i.e. one round trip is complete, so the data > goes encrypted even though the handshake is not completed. In enable > early data mode in TLS 1.3 for 0-RTT for session resumption, the > application data is sent from the client along with the client hello > message. Does the application data in early data mode go as clear text ? No, it is encrypted using a traffic key derived from the PSK. > I assume this is also encrypted using the PSK because 0-RTT is only > applicable when PSK is available on the client side. How is it > vulnerable to replay attack. Please help me understand. The same PSK can be used multiple times. Because the traffic key for the early data is derived from the PSK, if you later re-use the PSK and send early data again then the same traffic key will be derived. This can be exploited by an attacker who can record the early data from an earlier session and replay it later. The server will think that the replayed data is a new connection and process the early data accordingly. Early data (aka 0-RTT data) can be dangerous if not used properly. For this reason the current TLSv1.3 draft makes this note: Protocols MUST NOT use 0-RTT data without a profile that defines its use. That profile needs to identify which messages or interactions are safe to use with 0-RTT. In addition, to avoid accidental misuse, implementations SHOULD NOT enable 0-RTT unless specifically requested. Implementations SHOULD provide special functions for 0-RTT data to ensure that an application is always aware that it is sending or receiving data that might be replayed. > > Is there any API available in OpenSSL for false start ? No, OpenSSL does not support false start. As an aside please note that false start only applies to <= TLSv1.2. Matt > > Thanks > Best regards, > Neetish > > On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak > wrote: > > I Appreciate your response > > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell > wrote: > > > > On 19/06/17 19:11, Neetish Pathak wrote: > > 2) Can you suggest some places to put a time stamp in OpenSSL code. > > I agree with Ben's responses to all your other questions. For this > question, I'm not sure what you are trying to achieve? Starting > before > SSL_accept/SSL_connect and finishing after they return should be > fine. > Or are you looking for a breakdown of where the time is going? > > Thanks Matt. I was asking for a breakdown since I was not sure > if the SSL_accept and SSL_connect just do the handshake or if > they are doing some other things that may impact latency and CPU > usage. Just wanted to be clear that calling SSL_connect starts > ClientHello , SSL_accept unblocks on receiving ClientHello and > sends ServerHello, and both functions return after sending > Finished message from their sides (i.e. client and server). > > > > > > Matt > > > > > Thanks > > Best Regards, > > Neetish > > > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell > > >> wrote: > > > > > > > > On 16/06/17 23:51, Neetish Pathak wrote: > > > Thanks Matt, Appreciate ur response and tips > > > > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > > > > > >>> wrote: > > > > > > > > > > > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users > wrote: > > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: > > > >> Hello > > > >> Thanks > > > >> I tried reading some content from the server > side and I > > observed the > > > >> new_session_cb getting invoked in that case on > the client > > side. I > > > >> understand that may be due to delayed NewSession info > > transfer from > > > >> server side to client side. But it is helpful for > saving > > the session > > > >> info on the client side. (Thanks Matt for your input) > > > >> > > > >> However, now I have two concerns > > > >> > > > >> 1) I see that latency for handshake with session > resumption in > > > TLS 1.3 > > > >> has not improved as much as it improves for TLS 1.2 > > > >> With TLS 1.3, I observed that resumption brings > down the > > connection > > > >> time from 2.5 ms to 1.2-1.3 ms > > > >> while with TLS 1.2 (using either session IDs or > tickets), the > > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. > > > >> > > > >> The whole code is similar for running the two > experiments > > with only > > > >> max TLS version changed. Can someone comment on > the latency > > > >> measurements for the two cases. > > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my > > opinion. Please > > > >> comment. > > > >> > > > > > > > > Are you seeing a HelloRetryRequest in the > resumption flow? > > That would > > > > add an additional round trip. (Your numbers in > milliseconds > > are of > > > > course not transferrable to other systems; > round-trips is an > > easier to > > > > understand number.) RFC 5246 and > draft-ietf-tls-tls13-20 > > both have > > > > message-flow diagrams that show the number of > round trips in > > various > > > > handshake flows. > > > > > > Care should also be taken about when you are > starting your > > "timer" and > > > when you stop it, e.g. if you stop your timer after the > > session ticket > > > data has been received by the client then this is > not a "fair" > > test (the > > > connection is ready for data transfer earlier than > the arrival > > of the > > > session ticket). > > > > > > I would expect to see the TLS1.3 latency for a full > handshake > > to be > > > around the same as for a TLS1.2 resumption > handshake. With a > > TLS1.3 > > > resumption only marginally different. There are the same > > number of round > > > trips for a TLS1.3 full handshake as that there are > for a > > resumption > > > one. The primary difference is that the Certificate > message is > > not sent > > > (which can be quite a large message). > > > > > > Your timings suggest you are testing this over a LAN > where the > > effects > > > of network latency are going to be relatively low. > The real > > benefits > > > from fewer round trips will really be seen when network > > latency is more > > > significant. > > > > > > > > > > > > In my application program, I put start and stop timer > before and after > > > SSL_accept on server side and before and after > SSL_connect on the > > client > > > side. > > > > That should be fine (my worry was that you might also be > including the > > subsequent session ticket transfer). > > > > > I am not sure how I can put timers at individual steps > of Handshake > > > using my client applications. I was assuming SSL and > SSL_accept take > > > care of the entire handshake process. > > > > > > Yes, I am testing on local machine. I will migrate my > test to remote > > > machines. But I am not really able to understand why TLS > 1.3 is slower > > > on my machine. > > > > If you are on a local machine I would not expect a > significant speed up > > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce > the number of > > round-trips required in order to avoid unnecessary network > latency. If > > you are on a local machine then there isn't any > significant network > > latency anyway - so timings are presumably dominated by > the CPU > > intensive tasks. You should make sure that you are > comparing like with > > like, i.e. the same ciphers, key lengths, key exchange > algorithms, > > curves etc between TLSv1.2 and TLSv1.3. Differences in any > one of these > > could obviously have significant performance impacts. > > > > 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 kgoldman at us.ibm.com Wed Jun 21 17:44:34 2017 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 21 Jun 2017 13:44:34 -0400 Subject: [openssl-users] openssl 1.0 and 1.1 co-exist Message-ID: This is probably Linux specific ... Can both openssl versions co-exist on the same platform. I know that the .so is versioned, but how about the header files? Can I choose which library to build with? Do the headerso in the same /usr/include/openssl or are there links? Are there ifdefs in the header files. Is there a FAQ covering this? From npathak2 at ncsu.edu Wed Jun 21 22:17:12 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Wed, 21 Jun 2017 15:17:12 -0700 Subject: [openssl-users] Session Ticket Support in Openssl TLS 1.2 In-Reply-To: <3f9e6ff8-d242-20e1-97c9-3c5fb80a4fab@openssl.org> References: <3560b086-a730-dfa9-4fac-8acd87adc29a@openssl.org> <3f9e6ff8-d242-20e1-97c9-3c5fb80a4fab@openssl.org> Message-ID: On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell wrote: > > > On 21/06/17 00:38, Neetish Pathak wrote: > > I wanted to understand the replay attack vulnerability in case of enable > > early data of TLS 1.3 while false start is secure in that respect as I > > have read from https://github.com/openssl/openssl/issues/1541 > > So, with false start, the application data is sent from client after the > > first leg of the handshake i.e. one round trip is complete, so the data > > goes encrypted even though the handshake is not completed. In enable > > early data mode in TLS 1.3 for 0-RTT for session resumption, the > > application data is sent from the client along with the client hello > > message. Does the application data in early data mode go as clear text ? > > No, it is encrypted using a traffic key derived from the PSK. > > > I assume this is also encrypted using the PSK because 0-RTT is only > > applicable when PSK is available on the client side. How is it > > vulnerable to replay attack. Please help me understand. > > The same PSK can be used multiple times. Because the traffic key for the > early data is derived from the PSK, if you later re-use the PSK and send > early data again then the same traffic key will be derived. This can be > exploited by an attacker who can record the early data from an earlier > session and replay it later. The server will think that the replayed > data is a new connection and process the early data accordingly. > > Early data (aka 0-RTT data) can be dangerous if not used properly. For > this reason the current TLSv1.3 draft makes this note: > > Protocols MUST NOT use 0-RTT data without a profile that defines its > use. That profile needs to identify which messages or interactions > are safe to use with 0-RTT. In addition, to avoid accidental misuse, > implementations SHOULD NOT enable 0-RTT unless specifically > requested. Implementations SHOULD provide special functions for > 0-RTT data to ensure that an application is always aware that it is > sending or receiving data that might be replayed. > > > > > > Is there any API available in OpenSSL for false start ? > > No, OpenSSL does not support false start. As an aside please note that > false start only applies to <= TLSv1.2. Thanks for your comments. I need some direction on the doing server and client side authentication during the handshake. *1) For certificate sent from the server side, I am using* SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL)) for loading verification file *on the client side* Where do I get a CAFILE in the above API. If the server is sending a self signed certificate, what will be the CA file on the client side for verification. *2) For Client side authentication* I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate file on the client side to load the private key and the certificate. I read that client side authentication will not kick off unless the server sends CertificateRequest. I can use SSL_CTX_set_client_cert_cb() that sets the client_cert_cb() callback to be called on CertificateRequest. I am not sure how I can enable the server side to send CertificateRequest. What is the API for that. Should SSL_CTX_set_verify((ssl_ctx,SSL_VERIFY_PEER, NULL)) be used on server side for sending the certificateRequest message. Please correct me ? *3) Certificate request Message* Also, what is the use of CertificateVerify message. Why does client need to prove the ownership of private key for the public key sent previously in the client certificate. I assume this is not happening when the server sends the certificate. It doesn't prove the ownership of private key.Please comment Also, some guidance on a reference for understanding the authentication of certificates will be appreciated Thanks Neetish > > > Matt > > > > > Thanks > > Best regards, > > Neetish > > > > On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak > > wrote: > > > > I Appreciate your response > > > > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell > > wrote: > > > > > > > > On 19/06/17 19:11, Neetish Pathak wrote: > > > 2) Can you suggest some places to put a time stamp in OpenSSL > code. > > > > I agree with Ben's responses to all your other questions. For > this > > question, I'm not sure what you are trying to achieve? Starting > > before > > SSL_accept/SSL_connect and finishing after they return should be > > fine. > > Or are you looking for a breakdown of where the time is going? > > > > Thanks Matt. I was asking for a breakdown since I was not sure > > if the SSL_accept and SSL_connect just do the handshake or if > > they are doing some other things that may impact latency and CPU > > usage. Just wanted to be clear that calling SSL_connect starts > > ClientHello , SSL_accept unblocks on receiving ClientHello and > > sends ServerHello, and both functions return after sending > > Finished message from their sides (i.e. client and server). > > > > > > > > > > > > Matt > > > > > > > > Thanks > > > Best Regards, > > > Neetish > > > > > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell < > matt at openssl.org > > > >> wrote: > > > > > > > > > > > > On 16/06/17 23:51, Neetish Pathak wrote: > > > > Thanks Matt, Appreciate ur response and tips > > > > > > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell < > matt at openssl.org > > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users > > wrote: > > > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: > > > > >> Hello > > > > >> Thanks > > > > >> I tried reading some content from the server > > side and I > > > observed the > > > > >> new_session_cb getting invoked in that case on > > the client > > > side. I > > > > >> understand that may be due to delayed NewSession > info > > > transfer from > > > > >> server side to client side. But it is helpful for > > saving > > > the session > > > > >> info on the client side. (Thanks Matt for your > input) > > > > >> > > > > >> However, now I have two concerns > > > > >> > > > > >> 1) I see that latency for handshake with session > > resumption in > > > > TLS 1.3 > > > > >> has not improved as much as it improves for TLS > 1.2 > > > > >> With TLS 1.3, I observed that resumption brings > > down the > > > connection > > > > >> time from 2.5 ms to 1.2-1.3 ms > > > > >> while with TLS 1.2 (using either session IDs or > > tickets), the > > > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms. > > > > >> > > > > >> The whole code is similar for running the two > > experiments > > > with only > > > > >> max TLS version changed. Can someone comment on > > the latency > > > > >> measurements for the two cases. > > > > >> TLS 1.3 is supposed to be better than TLS 1.2 in > my > > > opinion. Please > > > > >> comment. > > > > >> > > > > > > > > > > Are you seeing a HelloRetryRequest in the > > resumption flow? > > > That would > > > > > add an additional round trip. (Your numbers in > > milliseconds > > > are of > > > > > course not transferrable to other systems; > > round-trips is an > > > easier to > > > > > understand number.) RFC 5246 and > > draft-ietf-tls-tls13-20 > > > both have > > > > > message-flow diagrams that show the number of > > round trips in > > > various > > > > > handshake flows. > > > > > > > > Care should also be taken about when you are > > starting your > > > "timer" and > > > > when you stop it, e.g. if you stop your timer after > the > > > session ticket > > > > data has been received by the client then this is > > not a "fair" > > > test (the > > > > connection is ready for data transfer earlier than > > the arrival > > > of the > > > > session ticket). > > > > > > > > I would expect to see the TLS1.3 latency for a full > > handshake > > > to be > > > > around the same as for a TLS1.2 resumption > > handshake. With a > > > TLS1.3 > > > > resumption only marginally different. There are the > same > > > number of round > > > > trips for a TLS1.3 full handshake as that there are > > for a > > > resumption > > > > one. The primary difference is that the Certificate > > message is > > > not sent > > > > (which can be quite a large message). > > > > > > > > Your timings suggest you are testing this over a LAN > > where the > > > effects > > > > of network latency are going to be relatively low. > > The real > > > benefits > > > > from fewer round trips will really be seen when > network > > > latency is more > > > > significant. > > > > > > > > > > > > > > > > In my application program, I put start and stop timer > > before and after > > > > SSL_accept on server side and before and after > > SSL_connect on the > > > client > > > > side. > > > > > > That should be fine (my worry was that you might also be > > including the > > > subsequent session ticket transfer). > > > > > > > I am not sure how I can put timers at individual steps > > of Handshake > > > > using my client applications. I was assuming SSL and > > SSL_accept take > > > > care of the entire handshake process. > > > > > > > > Yes, I am testing on local machine. I will migrate my > > test to remote > > > > machines. But I am not really able to understand why TLS > > 1.3 is slower > > > > on my machine. > > > > > > If you are on a local machine I would not expect a > > significant speed up > > > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce > > the number of > > > round-trips required in order to avoid unnecessary network > > latency. If > > > you are on a local machine then there isn't any > > significant network > > > latency anyway - so timings are presumably dominated by > > the CPU > > > intensive tasks. You should make sure that you are > > comparing like with > > > like, i.e. the same ciphers, key lengths, key exchange > > algorithms, > > > curves etc between TLSv1.2 and TLSv1.3. Differences in any > > one of these > > > could obviously have significant performance impacts. > > > > > > 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 > > > > > > > > > -- > 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 Jun 22 02:31:00 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 22 Jun 2017 02:31:00 +0000 Subject: [openssl-users] openssl 1.0 and 1.1 co-exist In-Reply-To: References: Message-ID: <20170622023059.GU23375@mournblade.imrryr.org> On Wed, Jun 21, 2017 at 01:44:34PM -0400, Ken Goldman wrote: > This is probably Linux specific ... > > Can both openssl versions co-exist on the same platform. I know that the > .so is versioned, but how about the header files? Can I choose which > library to build with? Yes, with care. I support systems where the base platform (debian) provides OpenSSL 1.0.1 in /usr/{include,lib,bin}, and I additionally deploy OpenSSL 1.0.2 and OpenSSL 1.1.0 in: /opt/openssl/1.0/{include,lib,bin} OpenSSL 1.0.2 /opt/openssl/1.1/{include,lib,bin} OpenSSL 1.1.0 These builds employ custom ELF symbol versions and custom ELF SONAMEs, and custom RPATHs, so that they can coexist without conflict in a single running process with the system OpenSSL library. Applications that use my builds can then be compiled with (for example): -I/opt/openssl/1.1/include \ -L/opt/openssl/1.1/lib \ -Wl,-R,/opt/openssl/1.1/lib > Do the headers go in the same /usr/include/openssl or are there links? > > Are there ifdefs in the header files. > > Is there a FAQ covering this? Not that I've seen. -- Viktor. From jb-openssl at wisemo.com Thu Jun 22 11:05:43 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 22 Jun 2017 13:05:43 +0200 Subject: [openssl-users] openssl 1.0 and 1.1 co-exist In-Reply-To: <20170622023059.GU23375@mournblade.imrryr.org> References: <20170622023059.GU23375@mournblade.imrryr.org> Message-ID: <5a988e8d-93ce-a2af-a542-ae34e08b2f8e@wisemo.com> On 22/06/2017 04:31, Viktor Dukhovni wrote: > On Wed, Jun 21, 2017 at 01:44:34PM -0400, Ken Goldman wrote: > >> This is probably Linux specific ... >> >> Can both openssl versions co-exist on the same platform. I know that the >> .so is versioned, but how about the header files? Can I choose which >> library to build with? > Yes, with care. I support systems where the base platform (debian) > provides OpenSSL 1.0.1 in /usr/{include,lib,bin}, and I additionally > deploy OpenSSL 1.0.2 and OpenSSL 1.1.0 in: > > /opt/openssl/1.0/{include,lib,bin} OpenSSL 1.0.2 > /opt/openssl/1.1/{include,lib,bin} OpenSSL 1.1.0 > > These builds employ custom ELF symbol versions and custom ELF > SONAMEs, and custom RPATHs, so that they can coexist without conflict > in a single running process with the system OpenSSL library. > > Applications that use my builds can then be compiled with (for > example): > > -I/opt/openssl/1.1/include \ > -L/opt/openssl/1.1/lib \ > -Wl,-R,/opt/openssl/1.1/lib I maintain a few Debian systems where 1.0.2 and the system 1.0.1 coexist solely based on so-names (I modified the 1.0.2 Makefile to set a different version in the so-name). Applications builds (and thus headers) for the different versions are not on the same machines, only the compiled binaries. For this simplified scenario (only one set of headers etc. per system), self-compiled OpenSSL simply goes in /usr/local with no use of Rpath. 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 weber at infotech.de Sun Jun 25 20:06:10 2017 From: weber at infotech.de (weber at infotech.de) Date: Sun, 25 Jun 2017 22:06:10 +0200 Subject: [openssl-users] X509 subject public key id-RSASSA-PSS Message-ID: Dear OpenSSSL users, we recently came across a certificate with OID: id-RSASSA-PSS aka rsassaPss in x509 subjects public key AlgorithmIdentifier. According to rfc4056 it is legitimate to use rsaEncryption or id-RSASSA-PSS as OID for the subject public key. But when listing the certs's contents or during verification, openssl v1.0.2h bails out: > 12392:error:0609E09C:digital envelope > routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231: > 12392:error:0B07706F:x509 certificate > routines:X509_PUBKEY_get:unsupported > algorithm:.\crypto\asn1\x_pubkey.c:148: which is caused by failing to assign the proper ameth structure to the key. Later in x_pubkey.c, only the method pub_decode is needed, which seems to work for rsassa pubkeys. So may we assign the same methods associated to rsaEncryption in this case or are we breaking other functionality by doing so? Thanks -- Christian Weber From Mike.Zarlenga at IGT.com Mon Jun 26 01:18:39 2017 From: Mike.Zarlenga at IGT.com (Zarlenga.Mike) Date: Mon, 26 Jun 2017 01:18:39 +0000 Subject: [openssl-users] Building libssl and libcrypto, .dlls and .libs, with different names? Message-ID: <36801de60bb64636a97247641981693c@RNOP-EXCI05.is.ad.igt.com> Good day, Has anyone on this mailing list gone through the steps necessary to build OpenSSL 1.1.0f with the old filenames (libeay and ssleay)? Our current build is based on libeay32 and ssleay32 as the 32-bit filenames and libeay64 and ssleay64 as the 64-bit filenames. Accomplishing the "64" name change requires just a simple edit on the 2 .def files after ms\do_win64a and before nmake. But the build process for 1.1.0 is different (no ms\do_win64a step) and I'm hoping someone on this list has already gone through the effort for something similar and will share so that I don't have to start digging through makefiles to reinvent the same wheel. Thanks in advance, M Zarlenga CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brett.R.Nicholas.TH at dartmouth.edu Mon Jun 26 14:21:06 2017 From: Brett.R.Nicholas.TH at dartmouth.edu (Brett R. Nicholas) Date: Mon, 26 Jun 2017 14:21:06 +0000 Subject: [openssl-users] How to define EVP_EncryptUpdate and EVP_EncryptFinal functions for an AES engine? (and a separate question re: padding). Message-ID: Hi there, I'm building a dynamic engine to support a custom AES hardware module that I've implemented in FPGA logic**, but after reading all available documentation, and pouring over the source code, I'm still very confused about the following two things..... 1. How and where I should define the EVP_[En/De]cryptInit_ex(..), EVP_[En/De]cryptUpdate(..), and EVP_[En/De]cryptFinal_ex(..) functions in my Engine code? Prior to this, I successfully built an engine for my sha256 accelerator, and now I'm trying to follow the same steps for AES. For sha256, the EVP_MD structure allowed me to declare pointers to my init, update, and final functions. This all worked flawlessly. Now, when I'm building the AES engine, I see that the EVP_CIPHER structure does not have these pointers (init, update, final), but instead has a pointer to init_key and do_cipher functions. However, the EVP encryption interface still has these functions defined. AFAIK (and please correct me if this is wrong) my init_key function is invoked by the EVP interface when I call the EVP_[En/De]cryptInit_ex function, and the do_cipher function is called upon EVP_[En/De]cryptUpdate. But how should I handle the EVP_[En/De]cryptFinal functions? Should I not be implementing them in my engine? Or am I missing something here.... 2. Does the EVP interface handle padding when a dynamic engine is involved? Or is it up to me to implement a padding structure within the engine itself? If the latter is the case, then I think the answer to the previous questions will help me figure out exactly where to implement it. So to recap, two questions: 1. How can I explicitly define which operations in my engine happen when the EVP_[En/De]cryptInit_ex(..), EVP_[En/De]cryptUpdate(..), and EVP_[En/De]cryptFinal_ex(..) functions are called from a driver program? 2. Does my engine need to handle padding the input data upon encryption, and stripping the padding when decrypting? Or does the EVP API handle the padding for me, and I only need to worry about the core AES algorithm on the arbitrary input data? (for reference, I'd like to just use standard PKCS padding) Thanks in advance, - Brett ** I'm using the Xilinx Zynq SoC, so I can create custom hardware in the programmable logic, and then interact with it from software running on the processor through the memory map, just like any peripheral....details irrelevant -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Jun 26 14:53:43 2017 From: levitte at openssl.org (Richard Levitte) Date: Mon, 26 Jun 2017 16:53:43 +0200 (CEST) Subject: [openssl-users] Building libssl and libcrypto, .dlls and .libs, with different names? In-Reply-To: <36801de60bb64636a97247641981693c@RNOP-EXCI05.is.ad.igt.com> References: <36801de60bb64636a97247641981693c@RNOP-EXCI05.is.ad.igt.com> Message-ID: <20170626.165343.599037002145796170.levitte@openssl.org> In message <36801de60bb64636a97247641981693c at RNOP-EXCI05.is.ad.igt.com> on Mon, 26 Jun 2017 01:18:39 +0000, "Zarlenga.Mike" said: Mike.Zarlenga> Has anyone on this mailing list gone through the steps necessary to Mike.Zarlenga> build OpenSSL 1.1.0f with the old filenames (libeay and ssleay)? Generally speaking, it's a bad idea. The 1.1.0 libraries aren't ABI backward compatible with the older versions. Therefore, we decided for a new naming scheme that includes the version we claim to keep being backward compatible. I would suggest that, rather than trying to fit things back to a naming scheme that no longer works, you fit your building procedures to the new scheme when building against OpenSSL 1.1.0 and on. The plan is that the names will be 'libcrypto-1_1.dll' and 'libssl-1_1.dll' for 32-bit and 'libcrypto-1_1-x64.dll' and 'libssl-1_1-x64.dll' for 64-bit for all 1.1.x OpenSSL versions. (which means that whenever 1.2.0 comes out, there will be a 'libcrypto-1_2.dll' and so on... I expect it will take a number of years before we get there) Note, btw, that the import libraries on Windows are simply called libcrypto.lib and libssl.lib from OpenSSL 1.1.0 and on. That will most likely not change at all for the far future. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From bkaduk at akamai.com Mon Jun 26 20:30:22 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 26 Jun 2017 15:30:22 -0500 Subject: [openssl-users] X509 subject public key id-RSASSA-PSS In-Reply-To: References: Message-ID: <4f12100c-9c5e-f4ef-2b37-4f3074b06bda@akamai.com> On 06/25/2017 03:06 PM, weber at infotech.de wrote: > Dear OpenSSSL users, > > we recently came across a certificate with OID: id-RSASSA-PSS aka > rsassaPss in x509 subjects public key AlgorithmIdentifier. > > According to rfc4056 it is legitimate to use rsaEncryption or > id-RSASSA-PSS as OID for the subject public key. > > But when listing the certs's contents or during verification, openssl > v1.0.2h bails out: >> 12392:error:0609E09C:digital envelope >> routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231: >> 12392:error:0B07706F:x509 certificate >> routines:X509_PUBKEY_get:unsupported >> algorithm:.\crypto\asn1\x_pubkey.c:148: > which is caused by failing to assign the proper ameth structure to the > key. > > Later in x_pubkey.c, only the method pub_decode is needed, which seems > to work for rsassa pubkeys. > So may we assign the same methods associated to rsaEncryption in this > case or are we breaking other functionality by doing so? It might be more interesting to just try using the current OpenSSL master branch (or a snapshot), which has more proper RSA-PSS support. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From npathak2 at ncsu.edu Tue Jun 27 00:05:56 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Mon, 26 Jun 2017 17:05:56 -0700 Subject: [openssl-users] (no subject) Message-ID: Hi , 1) I am working with a client and server program and want to use ECDHE-ECDSA type ciphers. I see that default Elliptic curve group supported is X25519. (when I check client and server logs on wireshark) I wish to generate a self-signed certificate for X25519 curve. But I am unable to do that the way I do for other curves like secp256r1, secp521r1 etc. I generate a private key for secp521r1 using ecparam command and then I generate the self-signed certificate. openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out server_key.pem openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730 On man page for X25519, I found the command to generate private key openssl genpkey -algorithm X25519 -out xkey.pem But as I try to generate a self signed certificate, I am getting the following error EVP_PKEY_sign_init:operation not supported for this keytype Could you please clarify where am I going wrong. Also, why is X25519 not mentioned in ec curve list using openssl ecparam -list_curves Any references to clarify my understanding will be appreciated. 2) Also, can you direct me towards what hack is needed in Openssl to support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my study purpose). Are you planning to integrate false start in OpenSSL any time. Thanks Thanks Best Regards, Neetish On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak wrote: > > > On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell wrote: > >> >> >> On 21/06/17 00:38, Neetish Pathak wrote: >> > I wanted to understand the replay attack vulnerability in case of enable >> > early data of TLS 1.3 while false start is secure in that respect as I >> > have read from https://github.com/openssl/openssl/issues/1541 >> > So, with false start, the application data is sent from client after the >> > first leg of the handshake i.e. one round trip is complete, so the data >> > goes encrypted even though the handshake is not completed. In enable >> > early data mode in TLS 1.3 for 0-RTT for session resumption, the >> > application data is sent from the client along with the client hello >> > message. Does the application data in early data mode go as clear text ? >> >> No, it is encrypted using a traffic key derived from the PSK. >> >> > I assume this is also encrypted using the PSK because 0-RTT is only >> > applicable when PSK is available on the client side. How is it >> > vulnerable to replay attack. Please help me understand. >> >> The same PSK can be used multiple times. Because the traffic key for the >> early data is derived from the PSK, if you later re-use the PSK and send >> early data again then the same traffic key will be derived. This can be >> exploited by an attacker who can record the early data from an earlier >> session and replay it later. The server will think that the replayed >> data is a new connection and process the early data accordingly. >> >> Early data (aka 0-RTT data) can be dangerous if not used properly. For >> this reason the current TLSv1.3 draft makes this note: >> >> Protocols MUST NOT use 0-RTT data without a profile that defines its >> use. That profile needs to identify which messages or interactions >> are safe to use with 0-RTT. In addition, to avoid accidental misuse, >> implementations SHOULD NOT enable 0-RTT unless specifically >> requested. Implementations SHOULD provide special functions for >> 0-RTT data to ensure that an application is always aware that it is >> sending or receiving data that might be replayed. >> >> >> > >> > Is there any API available in OpenSSL for false start ? >> >> No, OpenSSL does not support false start. As an aside please note that >> false start only applies to <= TLSv1.2. > > > Thanks for your comments. > > I need some direction on the doing server and client side authentication > during the handshake. > > *1) For certificate sent from the server side, I am using* > > SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL)) for loading > verification file *on the client side* > > Where do I get a CAFILE in the above API. If the server is sending a self > signed certificate, what will be the CA file on the client side for > verification. > > > *2) For Client side authentication* > > I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate file > on the client side to load the private key and the certificate. > I read that client side authentication will not kick off unless the server > sends CertificateRequest. I can use SSL_CTX_set_client_cert_cb() that > sets the client_cert_cb() callback to be called on CertificateRequest. > > I am not sure how I can enable the server side to send CertificateRequest. > What is the API for that. > Should SSL_CTX_set_verify((ssl_ctx,SSL_VERIFY_PEER, NULL)) be used on > server side for sending the certificateRequest message. Please correct me ? > > *3) Certificate request Message* > Also, what is the use of CertificateVerify message. Why does client need > to prove the ownership of private key for the public key sent previously in > the client certificate. I assume this is not happening when the server > sends the certificate. It doesn't prove the ownership of private key.Please > comment > > > > Also, some guidance on a reference for understanding the authentication of > certificates will be appreciated > > > Thanks > Neetish > > >> >> >> Matt >> >> > >> > Thanks >> > Best regards, >> > Neetish >> > >> > On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak > > > wrote: >> > >> > I Appreciate your response >> > >> > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell > > > wrote: >> > >> > >> > >> > On 19/06/17 19:11, Neetish Pathak wrote: >> > > 2) Can you suggest some places to put a time stamp in OpenSSL >> code. >> > >> > I agree with Ben's responses to all your other questions. For >> this >> > question, I'm not sure what you are trying to achieve? Starting >> > before >> > SSL_accept/SSL_connect and finishing after they return should be >> > fine. >> > Or are you looking for a breakdown of where the time is going? >> > >> > Thanks Matt. I was asking for a breakdown since I was not sure >> > if the SSL_accept and SSL_connect just do the handshake or if >> > they are doing some other things that may impact latency and CPU >> > usage. Just wanted to be clear that calling SSL_connect starts >> > ClientHello , SSL_accept unblocks on receiving ClientHello and >> > sends ServerHello, and both functions return after sending >> > Finished message from their sides (i.e. client and server). >> > >> > >> > >> > >> > >> > Matt >> > >> > > >> > > Thanks >> > > Best Regards, >> > > Neetish >> > > >> > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell < >> matt at openssl.org >> > > >> wrote: >> > > >> > > >> > > >> > > On 16/06/17 23:51, Neetish Pathak wrote: >> > > > Thanks Matt, Appreciate ur response and tips >> > > > >> > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell < >> matt at openssl.org >> > > >> > > > >> > >>> wrote: >> > > > >> > > > >> > > > >> > > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users >> > wrote: >> > > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote: >> > > > >> Hello >> > > > >> Thanks >> > > > >> I tried reading some content from the server >> > side and I >> > > observed the >> > > > >> new_session_cb getting invoked in that case on >> > the client >> > > side. I >> > > > >> understand that may be due to delayed NewSession >> info >> > > transfer from >> > > > >> server side to client side. But it is helpful for >> > saving >> > > the session >> > > > >> info on the client side. (Thanks Matt for your >> input) >> > > > >> >> > > > >> However, now I have two concerns >> > > > >> >> > > > >> 1) I see that latency for handshake with session >> > resumption in >> > > > TLS 1.3 >> > > > >> has not improved as much as it improves for TLS >> 1.2 >> > > > >> With TLS 1.3, I observed that resumption brings >> > down the >> > > connection >> > > > >> time from 2.5 ms to 1.2-1.3 ms >> > > > >> while with TLS 1.2 (using either session IDs or >> > tickets), the >> > > > >> connection time reduces from 2.5 ms to 0.5-0.6 >> ms. >> > > > >> >> > > > >> The whole code is similar for running the two >> > experiments >> > > with only >> > > > >> max TLS version changed. Can someone comment on >> > the latency >> > > > >> measurements for the two cases. >> > > > >> TLS 1.3 is supposed to be better than TLS 1.2 in >> my >> > > opinion. Please >> > > > >> comment. >> > > > >> >> > > > > >> > > > > Are you seeing a HelloRetryRequest in the >> > resumption flow? >> > > That would >> > > > > add an additional round trip. (Your numbers in >> > milliseconds >> > > are of >> > > > > course not transferrable to other systems; >> > round-trips is an >> > > easier to >> > > > > understand number.) RFC 5246 and >> > draft-ietf-tls-tls13-20 >> > > both have >> > > > > message-flow diagrams that show the number of >> > round trips in >> > > various >> > > > > handshake flows. >> > > > >> > > > Care should also be taken about when you are >> > starting your >> > > "timer" and >> > > > when you stop it, e.g. if you stop your timer after >> the >> > > session ticket >> > > > data has been received by the client then this is >> > not a "fair" >> > > test (the >> > > > connection is ready for data transfer earlier than >> > the arrival >> > > of the >> > > > session ticket). >> > > > >> > > > I would expect to see the TLS1.3 latency for a full >> > handshake >> > > to be >> > > > around the same as for a TLS1.2 resumption >> > handshake. With a >> > > TLS1.3 >> > > > resumption only marginally different. There are the >> same >> > > number of round >> > > > trips for a TLS1.3 full handshake as that there are >> > for a >> > > resumption >> > > > one. The primary difference is that the Certificate >> > message is >> > > not sent >> > > > (which can be quite a large message). >> > > > >> > > > Your timings suggest you are testing this over a LAN >> > where the >> > > effects >> > > > of network latency are going to be relatively low. >> > The real >> > > benefits >> > > > from fewer round trips will really be seen when >> network >> > > latency is more >> > > > significant. >> > > > >> > > > >> > > > >> > > > In my application program, I put start and stop timer >> > before and after >> > > > SSL_accept on server side and before and after >> > SSL_connect on the >> > > client >> > > > side. >> > > >> > > That should be fine (my worry was that you might also be >> > including the >> > > subsequent session ticket transfer). >> > > >> > > > I am not sure how I can put timers at individual steps >> > of Handshake >> > > > using my client applications. I was assuming SSL and >> > SSL_accept take >> > > > care of the entire handshake process. >> > > > >> > > > Yes, I am testing on local machine. I will migrate my >> > test to remote >> > > > machines. But I am not really able to understand why TLS >> > 1.3 is slower >> > > > on my machine. >> > > >> > > If you are on a local machine I would not expect a >> > significant speed up >> > > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce >> > the number of >> > > round-trips required in order to avoid unnecessary network >> > latency. If >> > > you are on a local machine then there isn't any >> > significant network >> > > latency anyway - so timings are presumably dominated by >> > the CPU >> > > intensive tasks. You should make sure that you are >> > comparing like with >> > > like, i.e. the same ciphers, key lengths, key exchange >> > algorithms, >> > > curves etc between TLSv1.2 and TLSv1.3. Differences in any >> > one of these >> > > could obviously have significant performance impacts. >> > > >> > > 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 >> > >> > >> > >> > >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jun 27 07:56:13 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Jun 2017 08:56:13 +0100 Subject: [openssl-users] (no subject) In-Reply-To: References: Message-ID: On 27/06/17 01:05, Neetish Pathak wrote: > Hi , > > 1) I am working with a client and server program and want to use > ECDHE-ECDSA type ciphers. > I see that default Elliptic curve group supported is X25519. (when I > check client and server logs on wireshark) > I wish to generate a self-signed certificate for X25519 curve. But I am > unable to do that the way I do for other curves like secp256r1, > secp521r1 etc. > > I generate a private key for secp521r1 using ecparam command and then I > generate the self-signed certificate. > > openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out > server_key.pem > > openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730 > > > On man page for X25519, > > I found the command to generate private key > > openssl genpkey -algorithm X25519 -out xkey.pem > > But as I try to generate a self signed certificate, I am getting the > following error > > EVP_PKEY_sign_init:operation not supported for this keytype It is not possible to "self-sign" an X25519 certificate because X25519 is a key-exchange algorithm only, not a digital signature algorithm. You would not typically create an X25519 certificate at all but an Ed25519 one (only supported in the master branch). > > > Could you please clarify where am I going wrong. Also, why is X25519 not > mentioned > > in ec curve list > > using openssl ecparam -list_curves X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA. X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is treated as a standalone algorithm and not integrated into the rest of the EC logic. > > > Any references to clarify my understanding will be appreciated. > > 2) Also, can you direct me towards what hack is needed in Openssl to > support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my > study purpose). For external PSKs in TLS1.3 (again only supported in master), you need to use the new SSL_CTX_set_psk_use_session_callback()/SSL_CTX_set_psk_find_session_callback() APIs. See the man pages in master for this (for some reason I notice that the documentation for this has not been updated on the website - but it *is* in the doc/man3 folder in git). > > Are you planning to integrate false start in OpenSSL any time. Thanks I am not aware of anyone working on this. Matt > > Thanks > > > Best Regards, > Neetish > > On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak > wrote: > > > > On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell > wrote: > > > > On 21/06/17 00:38, Neetish Pathak wrote: > > I wanted to understand the replay attack vulnerability in case of enable > > early data of TLS 1.3 while false start is secure in that respect as I > > have read from https://github.com/openssl/openssl/issues/1541 > > > So, with false start, the application data is sent from client after the > > first leg of the handshake i.e. one round trip is complete, so the data > > goes encrypted even though the handshake is not completed. In enable > > early data mode in TLS 1.3 for 0-RTT for session resumption, the > > application data is sent from the client along with the client hello > > message. Does the application data in early data mode go as clear text ? > > No, it is encrypted using a traffic key derived from the PSK. > > > I assume this is also encrypted using the PSK because 0-RTT is only > > applicable when PSK is available on the client side. How is it > > vulnerable to replay attack. Please help me understand. > > The same PSK can be used multiple times. Because the traffic key > for the > early data is derived from the PSK, if you later re-use the PSK > and send > early data again then the same traffic key will be derived. This > can be > exploited by an attacker who can record the early data from an > earlier > session and replay it later. The server will think that the replayed > data is a new connection and process the early data accordingly. > > Early data (aka 0-RTT data) can be dangerous if not used > properly. For > this reason the current TLSv1.3 draft makes this note: > > Protocols MUST NOT use 0-RTT data without a profile that > defines its > use. That profile needs to identify which messages or > interactions > are safe to use with 0-RTT. In addition, to avoid accidental > misuse, > implementations SHOULD NOT enable 0-RTT unless specifically > requested. Implementations SHOULD provide special functions for > 0-RTT data to ensure that an application is always aware that > it is > sending or receiving data that might be replayed. > > > > > > Is there any API available in OpenSSL for false start ? > > No, OpenSSL does not support false start. As an aside please > note that > false start only applies to <= TLSv1.2. > > > Thanks for your comments. > > I need some direction on the doing server and client side > authentication during the handshake. > > *1) For certificate sent from the server side, I am using* > > SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL)) for loading > verification file *on the client side* > > Where do I get a CAFILE in the above API. If the server is sending a > self signed certificate, what will be the CA file on the client side > for verification. > > > *2) For Client side authentication* > * > * > I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate > file on the client side to load the private key and the certificate. > I read that client side authentication will not kick off unless the > server sends CertificateRequest. I can use > SSL_CTX_set_client_cert_cb() that sets the client_cert_cb()callback > to be called on CertificateRequest. > > I am not sure how I can enable the server side to send > CertificateRequest. What is the API for that. > Should SSL_CTX_set_verify((ssl_ctx,SSL_VERIFY_PEER, NULL)) be used > on server side for sending the certificateRequest message. Please > correct me ? > > *3) Certificate request Message* > Also, what is the use of CertificateVerify message. Why does client > need to prove the ownership of private key for the public key sent > previously in the client certificate. I assume this is not happening > when the server sends the certificate. It doesn't prove the > ownership of private key.Please comment > > > > Also, some guidance on a reference for understanding the > authentication of certificates will be appreciated > > > Thanks > Neetish > > > > > Matt > > > > > Thanks > > Best regards, > > Neetish > > > > On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak > > >> wrote: > > > > I Appreciate your response > > > > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell > > >> wrote: > > > > > > > > On 19/06/17 19:11, Neetish Pathak wrote: > > > 2) Can you suggest some places to put a time stamp in OpenSSL code. > > > > I agree with Ben's responses to all your other questions. For this > > question, I'm not sure what you are trying to achieve? Starting > > before > > SSL_accept/SSL_connect and finishing after they return should be > > fine. > > Or are you looking for a breakdown of where the time is going? > > > > Thanks Matt. I was asking for a breakdown since I was not sure > > if the SSL_accept and SSL_connect just do the handshake or if > > they are doing some other things that may impact latency and CPU > > usage. Just wanted to be clear that calling SSL_connect starts > > ClientHello , SSL_accept unblocks on receiving ClientHello and > > sends ServerHello, and both functions return after sending > > Finished message from their sides (i.e. client and server). > > > > > > > > > > > > Matt > > > > > > > > Thanks > > > Best Regards, > > > Neetish > > > > > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell > > > > > > >>> wrote: > > > > > > > > > > > > On 16/06/17 23:51, Neetish Pathak wrote: > > > > Thanks Matt, Appreciate ur response and tips > > > > > > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > > > > > >> > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > On 16/06/17 20:08, Benjamin Kaduk via > openssl-users > > wrote: > > > > > On 06/16/2017 01:58 PM, Neetish Pathak > wrote: > > > > >> Hello > > > > >> Thanks > > > > >> I tried reading some content from the > server > > side and I > > > observed the > > > > >> new_session_cb getting invoked in that > case on > > the client > > > side. I > > > > >> understand that may be due to delayed > NewSession info > > > transfer from > > > > >> server side to client side. But it is > helpful for > > saving > > > the session > > > > >> info on the client side. (Thanks Matt > for your input) > > > > >> > > > > >> However, now I have two concerns > > > > >> > > > > >> 1) I see that latency for handshake > with session > > resumption in > > > > TLS 1.3 > > > > >> has not improved as much as it improves > for TLS 1.2 > > > > >> With TLS 1.3, I observed that > resumption brings > > down the > > > connection > > > > >> time from 2.5 ms to 1.2-1.3 ms > > > > >> while with TLS 1.2 (using either > session IDs or > > tickets), the > > > > >> connection time reduces from 2.5 ms to > 0.5-0.6 ms. > > > > >> > > > > >> The whole code is similar for running > the two > > experiments > > > with only > > > > >> max TLS version changed. Can someone > comment on > > the latency > > > > >> measurements for the two cases. > > > > >> TLS 1.3 is supposed to be better than > TLS 1.2 in my > > > opinion. Please > > > > >> comment. > > > > >> > > > > > > > > > > Are you seeing a HelloRetryRequest in the > > resumption flow? > > > That would > > > > > add an additional round trip. (Your > numbers in > > milliseconds > > > are of > > > > > course not transferrable to other systems; > > round-trips is an > > > easier to > > > > > understand number.) RFC 5246 and > > draft-ietf-tls-tls13-20 > > > both have > > > > > message-flow diagrams that show the > number of > > round trips in > > > various > > > > > handshake flows. > > > > > > > > Care should also be taken about when you are > > starting your > > > "timer" and > > > > when you stop it, e.g. if you stop your > timer after the > > > session ticket > > > > data has been received by the client then > this is > > not a "fair" > > > test (the > > > > connection is ready for data transfer > earlier than > > the arrival > > > of the > > > > session ticket). > > > > > > > > I would expect to see the TLS1.3 latency > for a full > > handshake > > > to be > > > > around the same as for a TLS1.2 resumption > > handshake. With a > > > TLS1.3 > > > > resumption only marginally different. > There are the same > > > number of round > > > > trips for a TLS1.3 full handshake as that > there are > > for a > > > resumption > > > > one. The primary difference is that the > Certificate > > message is > > > not sent > > > > (which can be quite a large message). > > > > > > > > Your timings suggest you are testing this > over a LAN > > where the > > > effects > > > > of network latency are going to be > relatively low. > > The real > > > benefits > > > > from fewer round trips will really be seen > when network > > > latency is more > > > > significant. > > > > > > > > > > > > > > > > In my application program, I put start and > stop timer > > before and after > > > > SSL_accept on server side and before and after > > SSL_connect on the > > > client > > > > side. > > > > > > That should be fine (my worry was that you might > also be > > including the > > > subsequent session ticket transfer). > > > > > > > I am not sure how I can put timers at > individual steps > > of Handshake > > > > using my client applications. I was assuming > SSL and > > SSL_accept take > > > > care of the entire handshake process. > > > > > > > > Yes, I am testing on local machine. I will > migrate my > > test to remote > > > > machines. But I am not really able to > understand why TLS > > 1.3 is slower > > > > on my machine. > > > > > > If you are on a local machine I would not expect a > > significant speed up > > > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed > to reduce > > the number of > > > round-trips required in order to avoid > unnecessary network > > latency. If > > > you are on a local machine then there isn't any > > significant network > > > latency anyway - so timings are presumably > dominated by > > the CPU > > > intensive tasks. You should make sure that you are > > comparing like with > > > like, i.e. the same ciphers, key lengths, key > exchange > > algorithms, > > > curves etc between TLSv1.2 and TLSv1.3. > Differences in any > > one of these > > > could obviously have significant performance > impacts. > > > > > > 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 > > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > From matt at openssl.org Tue Jun 27 09:23:59 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Jun 2017 10:23:59 +0100 Subject: [openssl-users] How to define EVP_EncryptUpdate and EVP_EncryptFinal functions for an AES engine? (and a separate question re: padding). In-Reply-To: References: Message-ID: <7906917c-d1de-48dc-2e9d-499e4a30ab52@openssl.org> On 26/06/17 15:21, Brett R. Nicholas wrote: > Hi there, > > > I'm building a dynamic engine to support a custom AES hardware module > that I've implemented in FPGA logic****, but after reading all available > documentation, and pouring over the source code, I'm still very confused > about the following two things..... > > > 1. *How and where I should define the > EVP_[En/De]cryptInit_ex(..), EVP_[En/De]cryptUpdate(..), and > EVP_[En/De]cryptFinal_ex(..) > functions in my Engine code? * > > > Prior to this, I successfully built an engine for my sha256 accelerator, > and now I'm trying to follow the same steps for AES. For sha256, the > EVP_MD structure allowed me to declare pointers to my init, update, and > final functions. This all worked flawlessly. > > > Now, when I'm building the AES engine, I see that the EVP_CIPHER > structure does not have these pointers (init, update, final), but > instead has a pointer to init_key and do_cipher functions. However, the > EVP encryption interface still has these functions defined. > > > AFAIK (and please correct me if this is wrong) my init_key function is > invoked by the EVP interface when I call the EVP_[En/De]cryptInit_ex > function, and the do_cipher function is called upon > EVP_[En/De]cryptUpdate. But how should I handle > the EVP_[En/De]cryptFinal functions? Should I not be implementing them > in my engine? Or am I missing something here.... The behaviour varies a little depending on whether you have set the EVP_CIPH_FLAG_CUSTOM_CIPHER flag for your cipher. If you have not set the EVP_CIPH_FLAG_CUSTOM_CIPHER flag: do_cipher() will only ever be invoked where the length is a multiple of a full block length. EVP_[En/De]cryptUpdate and EVP_[En/De]cryptFinal will invoke do_cipher() as required. There may not be a one-to-one correspondence between calls to those functions and calls to do_cipher(). The EVP functions handle dealing with partial blocks and padding the final block as required. If you have set the EVP_CIPH_FLAG_CUSTOM_CIPHER flag: EVP_[En/De]cryptUpdate just call do_cipher() directly. The cipher implementation itself has to handle partial blocks etc. Similarly EVP_[En/De]cryptFinal just calls do_cipher() directly, but will pass NULL for the input buffer, and 0 for the input length. Your cipher implementation will have to handle any padding etc itself. Matt From weber at infotech.de Tue Jun 27 10:28:52 2017 From: weber at infotech.de (weber at infotech.de) Date: Tue, 27 Jun 2017 12:28:52 +0200 Subject: [openssl-users] X509 subject public key id-RSASSA-PSS In-Reply-To: <4f12100c-9c5e-f4ef-2b37-4f3074b06bda@akamai.com> References: <4f12100c-9c5e-f4ef-2b37-4f3074b06bda@akamai.com> Message-ID: <51e8c594-009a-b6dc-ec1a-1ba290ffc279@infotech.de> Am 26.06.2017 um 22:30 schrieb Benjamin Kaduk: > On 06/25/2017 03:06 PM, weber at infotech.de wrote: >> Dear OpenSSSL users, >> >> we recently came across a certificate with OID: id-RSASSA-PSS aka >> rsassaPss in x509 subjects public key AlgorithmIdentifier. >> >> According to rfc4056 it is legitimate to use rsaEncryption or >> id-RSASSA-PSS as OID for the subject public key. >> >> But when listing the certs's contents or during verification, openssl >> v1.0.2h bails out: >>> 12392:error:0609E09C:digital envelope >>> routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231: >>> 12392:error:0B07706F:x509 certificate >>> routines:X509_PUBKEY_get:unsupported >>> algorithm:.\crypto\asn1\x_pubkey.c:148: >> which is caused by failing to assign the proper ameth structure to >> the key. >> >> Later in x_pubkey.c, only the method pub_decode is needed, which >> seems to work for rsassa pubkeys. >> So may we assign the same methods associated to rsaEncryption in this >> case or are we breaking other functionality by doing so? > > It might be more interesting to just try using the current OpenSSL > master branch (or a snapshot), which has more proper RSA-PSS support. > > -Ben It's absolutely the same with Version 1.0.2l. Due to time limitation we avoid updating to 1.1.0 as we assume that there will be several adaptations neccessary ... -- Christian Weber -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Jun 27 12:18:44 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Jun 2017 12:18:44 +0000 Subject: [openssl-users] X509 subject public key id-RSASSA-PSS In-Reply-To: <51e8c594-009a-b6dc-ec1a-1ba290ffc279@infotech.de> References: <4f12100c-9c5e-f4ef-2b37-4f3074b06bda@akamai.com> <51e8c594-009a-b6dc-ec1a-1ba290ffc279@infotech.de> Message-ID: <9c57f5b6588d4be4b85ebe343507db01@usma1ex-dag1mb1.msg.corp.akamai.com> 1.0.2 does not have full RSA-PSS support; you can?t use it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mike.Zarlenga at IGT.com Tue Jun 27 15:58:09 2017 From: Mike.Zarlenga at IGT.com (Zarlenga.Mike) Date: Tue, 27 Jun 2017 15:58:09 +0000 Subject: [openssl-users] Building libssl and libcrypto, .dlls and .libs, with (ABI compatibility) Message-ID: <44064b1e7c3c4db094bf63355204f6c3@RNOP-EXCI05.is.ad.igt.com> In message <36801de60bb64636a97247641981693c at RNOP-EXCI05.is.ad.igt.com> on Mon, 26 Jun 2017 01:18:39 +0000, "Zarlenga.Mike" said: MZ> Has anyone on this mailing list gone through the steps necessary to MZ> build OpenSSL 1.1.0f with the old filenames (libeay and ssleay)? RL>Generally speaking, it's a bad idea. RL>The 1.1.0 libraries aren't ABI backward compatible with the older versions. Hi Richard, Thanks for replying. Since I'm rebuilding and relinking from source code, do I need to be concerned with ABI backward compatibility? I see that build.info builds the .libs for VMS with a 32/64 suffix, the same naming convention that we're using for 1.0.n, and want to keep in 1.1.n. So, maybe, our best way forward is a small change to build.info in the IF statement for /^VC-/ ? Regards, M Zarlenga CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited. From bhat.jayalakshmi at gmail.com Tue Jun 27 19:00:19 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Wed, 28 Jun 2017 00:30:19 +0530 Subject: [openssl-users] OpenSSL FIPS CAVP tests throws an error iob_func while linking Message-ID: Hi All, I am trying to build CAVP test executable for WinCE. Most of the executable are built except 1-2. I am facing iob_func unresolved error. Every thing seems to be proper. Any idea or help is well appreciated. Regards Jaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From weber at infotech.de Tue Jun 27 21:30:09 2017 From: weber at infotech.de (weber at infotech.de) Date: Tue, 27 Jun 2017 23:30:09 +0200 Subject: [openssl-users] X509 subject public key id-RSASSA-PSS In-Reply-To: <9c57f5b6588d4be4b85ebe343507db01@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4f12100c-9c5e-f4ef-2b37-4f3074b06bda@akamai.com> <51e8c594-009a-b6dc-ec1a-1ba290ffc279@infotech.de> <9c57f5b6588d4be4b85ebe343507db01@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <4a1040aa-f8d9-1192-b026-8c402276c0a4@infotech.de> Am 27.06.2017 um 14:18 schrieb Salz, Rich via openssl-users: > > 1.0.2 does not have full RSA-PSS support; you can?t use it. > Thanks Rich, in my case it works, because we partially do the verification (and algo selection) work externally. We just need to access the public key which is rsa in both cases. Does your response mean, that RSA-PSS meanhile _is_ fully supported in 1.1.0? Any estimations about how much work has to be done for adopting the newer version? Thanks -- Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Jun 27 23:26:36 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Jun 2017 23:26:36 +0000 Subject: [openssl-users] X509 subject public key id-RSASSA-PSS In-Reply-To: <4a1040aa-f8d9-1192-b026-8c402276c0a4@infotech.de> References: <4f12100c-9c5e-f4ef-2b37-4f3074b06bda@akamai.com> <51e8c594-009a-b6dc-ec1a-1ba290ffc279@infotech.de> <9c57f5b6588d4be4b85ebe343507db01@usma1ex-dag1mb1.msg.corp.akamai.com> <4a1040aa-f8d9-1192-b026-8c402276c0a4@infotech.de> Message-ID: > Does your response mean, that RSA-PSS meanhile _is_ fully supported in 1.1.0? I hesitate to say fully, because there are no doubt parts that don't work. But RSAPSS signatures are supported. But more importantly, 1.1.1 not 1.1.0 > Any estimations about how much work has to be done for adopting the newer version? It depends. Almost all structures are opaque now, so you can't look inside at the fields direcdtly. From npathak2 at ncsu.edu Tue Jun 27 23:56:42 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Tue, 27 Jun 2017 16:56:42 -0700 Subject: [openssl-users] Loading multiple private keys a certificates on server program Message-ID: Thanks 1) How can i load multiple private keys and certificates on the server side. I need to use different keys and certificates when the client explicitly asks for a particular cipher. E.g The client can send the ciphersuite as ECDHE-RSA-AES256-GCM-SHA384 for first connection and then ECDHE-ECDSA-AES256-GCM-SHA384 for second connection Server should pick the right key and certificate (RSA and ECDSA certs respectively) I am using SSL_CTX_use_certificate_file to load the certificate but the server always picks just the first certificate mentioned in the file and fails for one of the cases with no cipher shared message What should we do to store multiple certificates and private keys at the server side so that it picks the right one corresponding to the requested cipher. Should I make certificate chain ? Should I make keystore? (PKCS12 etc) what API should be used to load the keys and certificates. Can somebody suggest the right way to do this. Thanks Best Regards, Neetish On Tue, Jun 27, 2017 at 12:56 AM, Matt Caswell wrote: > > > On 27/06/17 01:05, Neetish Pathak wrote: > > Hi , > > > > 1) I am working with a client and server program and want to use > > ECDHE-ECDSA type ciphers. > > I see that default Elliptic curve group supported is X25519. (when I > > check client and server logs on wireshark) > > I wish to generate a self-signed certificate for X25519 curve. But I am > > unable to do that the way I do for other curves like secp256r1, > > secp521r1 etc. > > > > I generate a private key for secp521r1 using ecparam command and then I > > generate the self-signed certificate. > > > > openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out > > server_key.pem > > > > openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730 > > > > > > On man page for X25519, > > > > I found the command to generate private key > > > > openssl genpkey -algorithm X25519 -out xkey.pem > > > > But as I try to generate a self signed certificate, I am getting the > > following error > > > > EVP_PKEY_sign_init:operation not supported for this keytype > > It is not possible to "self-sign" an X25519 certificate because X25519 > is a key-exchange algorithm only, not a digital signature algorithm. You > would not typically create an X25519 certificate at all but an Ed25519 > one (only supported in the master branch). > > > > > > > > Could you please clarify where am I going wrong. Also, why is X25519 not > > mentioned > > > > in ec curve list > > > > using openssl ecparam -list_curves > > X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA. > X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is > treated as a standalone algorithm and not integrated into the rest of > the EC logic. > > > > > > > Any references to clarify my understanding will be appreciated. > > > > 2) Also, can you direct me towards what hack is needed in Openssl to > > support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my > > study purpose). > > For external PSKs in TLS1.3 (again only supported in master), you need > to use the new > SSL_CTX_set_psk_use_session_callback()/SSL_CTX_set_psk_ > find_session_callback() > APIs. See the man pages in master for this (for some reason I notice > that the documentation for this has not been updated on the website - > but it *is* in the doc/man3 folder in git). > > > > > Are you planning to integrate false start in OpenSSL any time. Thanks > > I am not aware of anyone working on this. > > Matt > > > > > > Thanks > > > > > > Best Regards, > > Neetish > > > > On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak > > wrote: > > > > > > > > On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell > > wrote: > > > > > > > > On 21/06/17 00:38, Neetish Pathak wrote: > > > I wanted to understand the replay attack vulnerability in case > of enable > > > early data of TLS 1.3 while false start is secure in that > respect as I > > > have read from https://github.com/openssl/openssl/issues/1541 > > > > > So, with false start, the application data is sent from client > after the > > > first leg of the handshake i.e. one round trip is complete, so > the data > > > goes encrypted even though the handshake is not completed. In > enable > > > early data mode in TLS 1.3 for 0-RTT for session resumption, > the > > > application data is sent from the client along with the client > hello > > > message. Does the application data in early data mode go as > clear text ? > > > > No, it is encrypted using a traffic key derived from the PSK. > > > > > I assume this is also encrypted using the PSK because 0-RTT is > only > > > applicable when PSK is available on the client side. How is it > > > vulnerable to replay attack. Please help me understand. > > > > The same PSK can be used multiple times. Because the traffic key > > for the > > early data is derived from the PSK, if you later re-use the PSK > > and send > > early data again then the same traffic key will be derived. This > > can be > > exploited by an attacker who can record the early data from an > > earlier > > session and replay it later. The server will think that the > replayed > > data is a new connection and process the early data accordingly. > > > > Early data (aka 0-RTT data) can be dangerous if not used > > properly. For > > this reason the current TLSv1.3 draft makes this note: > > > > Protocols MUST NOT use 0-RTT data without a profile that > > defines its > > use. That profile needs to identify which messages or > > interactions > > are safe to use with 0-RTT. In addition, to avoid accidental > > misuse, > > implementations SHOULD NOT enable 0-RTT unless specifically > > requested. Implementations SHOULD provide special functions > for > > 0-RTT data to ensure that an application is always aware that > > it is > > sending or receiving data that might be replayed. > > > > > > > > > > Is there any API available in OpenSSL for false start ? > > > > No, OpenSSL does not support false start. As an aside please > > note that > > false start only applies to <= TLSv1.2. > > > > > > Thanks for your comments. > > > > I need some direction on the doing server and client side > > authentication during the handshake. > > > > *1) For certificate sent from the server side, I am using* > > > > SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL)) for loading > > verification file *on the client side* > > > > Where do I get a CAFILE in the above API. If the server is sending a > > self signed certificate, what will be the CA file on the client side > > for verification. > > > > > > *2) For Client side authentication* > > * > > * > > I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate > > file on the client side to load the private key and the certificate. > > I read that client side authentication will not kick off unless the > > server sends CertificateRequest. I can use > > SSL_CTX_set_client_cert_cb() that sets the client_cert_cb()callback > > to be called on CertificateRequest. > > > > I am not sure how I can enable the server side to send > > CertificateRequest. What is the API for that. > > Should SSL_CTX_set_verify((ssl_ctx,SSL_VERIFY_PEER, NULL)) be used > > on server side for sending the certificateRequest message. Please > > correct me ? > > > > *3) Certificate request Message* > > Also, what is the use of CertificateVerify message. Why does client > > need to prove the ownership of private key for the public key sent > > previously in the client certificate. I assume this is not happening > > when the server sends the certificate. It doesn't prove the > > ownership of private key.Please comment > > > > > > > > Also, some guidance on a reference for understanding the > > authentication of certificates will be appreciated > > > > > > Thanks > > Neetish > > > > > > > > > > Matt > > > > > > > > Thanks > > > Best regards, > > > Neetish > > > > > > On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak < > npathak2 at ncsu.edu > > > >> wrote: > > > > > > I Appreciate your response > > > > > > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell < > matt at openssl.org > > > >> > wrote: > > > > > > > > > > > > On 19/06/17 19:11, Neetish Pathak wrote: > > > > 2) Can you suggest some places to put a time stamp > in OpenSSL code. > > > > > > I agree with Ben's responses to all your other > questions. For this > > > question, I'm not sure what you are trying to achieve? > Starting > > > before > > > SSL_accept/SSL_connect and finishing after they return > should be > > > fine. > > > Or are you looking for a breakdown of where the time > is going? > > > > > > Thanks Matt. I was asking for a breakdown since I was > not sure > > > if the SSL_accept and SSL_connect just do the > handshake or if > > > they are doing some other things that may impact > latency and CPU > > > usage. Just wanted to be clear that calling > SSL_connect starts > > > ClientHello , SSL_accept unblocks on receiving > ClientHello and > > > sends ServerHello, and both functions return after > sending > > > Finished message from their sides (i.e. client and > server). > > > > > > > > > > > > > > > > > > Matt > > > > > > > > > > > Thanks > > > > Best Regards, > > > > Neetish > > > > > > > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell < > matt at openssl.org > > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > On 16/06/17 23:51, Neetish Pathak wrote: > > > > > Thanks Matt, Appreciate ur response and tips > > > > > > > > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > > > > > > > > > >> > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > > > > > On 16/06/17 20:08, Benjamin Kaduk via > > openssl-users > > > wrote: > > > > > > On 06/16/2017 01:58 PM, Neetish Pathak > > wrote: > > > > > >> Hello > > > > > >> Thanks > > > > > >> I tried reading some content from the > > server > > > side and I > > > > observed the > > > > > >> new_session_cb getting invoked in that > > case on > > > the client > > > > side. I > > > > > >> understand that may be due to delayed > > NewSession info > > > > transfer from > > > > > >> server side to client side. But it is > > helpful for > > > saving > > > > the session > > > > > >> info on the client side. (Thanks Matt > > for your input) > > > > > >> > > > > > >> However, now I have two concerns > > > > > >> > > > > > >> 1) I see that latency for handshake > > with session > > > resumption in > > > > > TLS 1.3 > > > > > >> has not improved as much as it improves > > for TLS 1.2 > > > > > >> With TLS 1.3, I observed that > > resumption brings > > > down the > > > > connection > > > > > >> time from 2.5 ms to 1.2-1.3 ms > > > > > >> while with TLS 1.2 (using either > > session IDs or > > > tickets), the > > > > > >> connection time reduces from 2.5 ms to > > 0.5-0.6 ms. > > > > > >> > > > > > >> The whole code is similar for running > > the two > > > experiments > > > > with only > > > > > >> max TLS version changed. Can someone > > comment on > > > the latency > > > > > >> measurements for the two cases. > > > > > >> TLS 1.3 is supposed to be better than > > TLS 1.2 in my > > > > opinion. Please > > > > > >> comment. > > > > > >> > > > > > > > > > > > > Are you seeing a HelloRetryRequest in the > > > resumption flow? > > > > That would > > > > > > add an additional round trip. (Your > > numbers in > > > milliseconds > > > > are of > > > > > > course not transferrable to other > systems; > > > round-trips is an > > > > easier to > > > > > > understand number.) RFC 5246 and > > > draft-ietf-tls-tls13-20 > > > > both have > > > > > > message-flow diagrams that show the > > number of > > > round trips in > > > > various > > > > > > handshake flows. > > > > > > > > > > Care should also be taken about when you > are > > > starting your > > > > "timer" and > > > > > when you stop it, e.g. if you stop your > > timer after the > > > > session ticket > > > > > data has been received by the client then > > this is > > > not a "fair" > > > > test (the > > > > > connection is ready for data transfer > > earlier than > > > the arrival > > > > of the > > > > > session ticket). > > > > > > > > > > I would expect to see the TLS1.3 latency > > for a full > > > handshake > > > > to be > > > > > around the same as for a TLS1.2 resumption > > > handshake. With a > > > > TLS1.3 > > > > > resumption only marginally different. > > There are the same > > > > number of round > > > > > trips for a TLS1.3 full handshake as that > > there are > > > for a > > > > resumption > > > > > one. The primary difference is that the > > Certificate > > > message is > > > > not sent > > > > > (which can be quite a large message). > > > > > > > > > > Your timings suggest you are testing this > > over a LAN > > > where the > > > > effects > > > > > of network latency are going to be > > relatively low. > > > The real > > > > benefits > > > > > from fewer round trips will really be seen > > when network > > > > latency is more > > > > > significant. > > > > > > > > > > > > > > > > > > > > In my application program, I put start and > > stop timer > > > before and after > > > > > SSL_accept on server side and before and after > > > SSL_connect on the > > > > client > > > > > side. > > > > > > > > That should be fine (my worry was that you might > > also be > > > including the > > > > subsequent session ticket transfer). > > > > > > > > > I am not sure how I can put timers at > > individual steps > > > of Handshake > > > > > using my client applications. I was assuming > > SSL and > > > SSL_accept take > > > > > care of the entire handshake process. > > > > > > > > > > Yes, I am testing on local machine. I will > > migrate my > > > test to remote > > > > > machines. But I am not really able to > > understand why TLS > > > 1.3 is slower > > > > > on my machine. > > > > > > > > If you are on a local machine I would not expect > a > > > significant speed up > > > > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed > > to reduce > > > the number of > > > > round-trips required in order to avoid > > unnecessary network > > > latency. If > > > > you are on a local machine then there isn't any > > > significant network > > > > latency anyway - so timings are presumably > > dominated by > > > the CPU > > > > intensive tasks. You should make sure that you > are > > > comparing like with > > > > like, i.e. the same ciphers, key lengths, key > > exchange > > > algorithms, > > > > curves etc between TLSv1.2 and TLSv1.3. > > Differences in any > > > one of these > > > > could obviously have significant performance > > impacts. > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > -- > > 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 levitte at openssl.org Wed Jun 28 00:18:07 2017 From: levitte at openssl.org (Richard Levitte) Date: Wed, 28 Jun 2017 02:18:07 +0200 (CEST) Subject: [openssl-users] Building libssl and libcrypto, .dlls and .libs, with (ABI compatibility) In-Reply-To: <44064b1e7c3c4db094bf63355204f6c3@RNOP-EXCI05.is.ad.igt.com> References: <44064b1e7c3c4db094bf63355204f6c3@RNOP-EXCI05.is.ad.igt.com> Message-ID: <20170628.021807.1015094998592524617.levitte@openssl.org> In message <44064b1e7c3c4db094bf63355204f6c3 at RNOP-EXCI05.is.ad.igt.com> on Tue, 27 Jun 2017 15:58:09 +0000, "Zarlenga.Mike" said: Mike.Zarlenga> In message <36801de60bb64636a97247641981693c at RNOP-EXCI05.is.ad.igt.com> on Mon, 26 Jun 2017 01:18:39 +0000, "Zarlenga.Mike" said: Mike.Zarlenga> Mike.Zarlenga> MZ> Has anyone on this mailing list gone through the steps necessary to Mike.Zarlenga> MZ> build OpenSSL 1.1.0f with the old filenames (libeay and ssleay)? Mike.Zarlenga> Mike.Zarlenga> RL>Generally speaking, it's a bad idea. Mike.Zarlenga> RL>The 1.1.0 libraries aren't ABI backward compatible with the older versions. Mike.Zarlenga> Mike.Zarlenga> Hi Richard, Mike.Zarlenga> Mike.Zarlenga> Thanks for replying. Mike.Zarlenga> Mike.Zarlenga> Since I'm rebuilding and relinking from source code, do I need to be concerned Mike.Zarlenga> with ABI backward compatibility? Depends... If you're also relinking all applications that use the DLLs, then fine... but in that case, I don't see why you bother with DLLs at all. What, exactly, do you intend to do with the resulting DLLs? Mike.Zarlenga> I see that build.info builds the .libs for VMS with a 32/64 suffix, the same naming Mike.Zarlenga> convention that we're using for 1.0.n, and want to keep in 1.1.n. So, maybe, our Mike.Zarlenga> best way forward is a small change to build.info in the IF statement for /^VC-/ ? Yes, the top build.info is the file to make changes in for this. However, once again, I really do not recommend this. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From npathak2 at ncsu.edu Wed Jun 28 22:10:22 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Wed, 28 Jun 2017 15:10:22 -0700 Subject: [openssl-users] Loading multiple private keys a certificates on server program In-Reply-To: References: Message-ID: Hi , I am building a server and client program. I wanted to know if the client intends to use a particular cipher suite ECDHE256 ECDSA 256 types and presents it to the server as its only ciphersuite. Then who decides the Diffie-hellman and EC parameters. Should the parameters be decided on the client side or the server side? Thanks Best Regards, Neetish On Tue, Jun 27, 2017 at 4:56 PM, Neetish Pathak wrote: > Thanks > 1) How can i load multiple private keys and certificates on the server > side. > I need to use different keys and certificates when the client explicitly > asks for a particular cipher. > E.g The client can send the ciphersuite as > > ECDHE-RSA-AES256-GCM-SHA384 for first connection > and then > > ECDHE-ECDSA-AES256-GCM-SHA384 for second connection > > Server should pick the right key and certificate (RSA and ECDSA certs > respectively) > > I am using > > SSL_CTX_use_certificate_file to load the certificate but the server always > picks just the first certificate mentioned in the file and fails for one of > the cases with no cipher shared message > > What should we do to store multiple certificates and private keys at the > server side so that it picks the right one corresponding to the requested > cipher. > > > Should I make certificate chain ? > > Should I make keystore? (PKCS12 etc) > > what API should be used to load the keys and certificates. Can somebody > suggest the right way to do this. > Thanks > Best Regards, > Neetish > > > On Tue, Jun 27, 2017 at 12:56 AM, Matt Caswell wrote: > >> >> >> On 27/06/17 01:05, Neetish Pathak wrote: >> > Hi , >> > >> > 1) I am working with a client and server program and want to use >> > ECDHE-ECDSA type ciphers. >> > I see that default Elliptic curve group supported is X25519. (when I >> > check client and server logs on wireshark) >> > I wish to generate a self-signed certificate for X25519 curve. But I am >> > unable to do that the way I do for other curves like secp256r1, >> > secp521r1 etc. >> > >> > I generate a private key for secp521r1 using ecparam command and then I >> > generate the self-signed certificate. >> > >> > openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out >> > server_key.pem >> > >> > openssl req -new -x509 -key server_key.pem -out server_cert.pem -days >> 730 >> > >> > >> > On man page for X25519, >> > >> > I found the command to generate private key >> > >> > openssl genpkey -algorithm X25519 -out xkey.pem >> > >> > But as I try to generate a self signed certificate, I am getting the >> > following error >> > >> > EVP_PKEY_sign_init:operation not supported for this keytype >> >> It is not possible to "self-sign" an X25519 certificate because X25519 >> is a key-exchange algorithm only, not a digital signature algorithm. You >> would not typically create an X25519 certificate at all but an Ed25519 >> one (only supported in the master branch). >> >> >> > >> > >> > Could you please clarify where am I going wrong. Also, why is X25519 not >> > mentioned >> > >> > in ec curve list >> > >> > using openssl ecparam -list_curves >> >> X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA. >> X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is >> treated as a standalone algorithm and not integrated into the rest of >> the EC logic. >> >> > >> > >> > Any references to clarify my understanding will be appreciated. >> > >> > 2) Also, can you direct me towards what hack is needed in Openssl to >> > support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my >> > study purpose). >> >> For external PSKs in TLS1.3 (again only supported in master), you need >> to use the new >> SSL_CTX_set_psk_use_session_callback()/SSL_CTX_set_psk_find_ >> session_callback() >> APIs. See the man pages in master for this (for some reason I notice >> that the documentation for this has not been updated on the website - >> but it *is* in the doc/man3 folder in git). >> >> > >> > Are you planning to integrate false start in OpenSSL any time. Thanks >> >> I am not aware of anyone working on this. >> >> Matt >> >> >> > >> > Thanks >> > >> > >> > Best Regards, >> > Neetish >> > >> > On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak > > > wrote: >> > >> > >> > >> > On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell > > > wrote: >> > >> > >> > >> > On 21/06/17 00:38, Neetish Pathak wrote: >> > > I wanted to understand the replay attack vulnerability in >> case of enable >> > > early data of TLS 1.3 while false start is secure in that >> respect as I >> > > have read from https://github.com/openssl/openssl/issues/1541 >> > >> > > So, with false start, the application data is sent from >> client after the >> > > first leg of the handshake i.e. one round trip is complete, >> so the data >> > > goes encrypted even though the handshake is not completed. In >> enable >> > > early data mode in TLS 1.3 for 0-RTT for session resumption, >> the >> > > application data is sent from the client along with the >> client hello >> > > message. Does the application data in early data mode go as >> clear text ? >> > >> > No, it is encrypted using a traffic key derived from the PSK. >> > >> > > I assume this is also encrypted using the PSK because 0-RTT >> is only >> > > applicable when PSK is available on the client side. How is it >> > > vulnerable to replay attack. Please help me understand. >> > >> > The same PSK can be used multiple times. Because the traffic key >> > for the >> > early data is derived from the PSK, if you later re-use the PSK >> > and send >> > early data again then the same traffic key will be derived. This >> > can be >> > exploited by an attacker who can record the early data from an >> > earlier >> > session and replay it later. The server will think that the >> replayed >> > data is a new connection and process the early data accordingly. >> > >> > Early data (aka 0-RTT data) can be dangerous if not used >> > properly. For >> > this reason the current TLSv1.3 draft makes this note: >> > >> > Protocols MUST NOT use 0-RTT data without a profile that >> > defines its >> > use. That profile needs to identify which messages or >> > interactions >> > are safe to use with 0-RTT. In addition, to avoid accidental >> > misuse, >> > implementations SHOULD NOT enable 0-RTT unless specifically >> > requested. Implementations SHOULD provide special functions >> for >> > 0-RTT data to ensure that an application is always aware that >> > it is >> > sending or receiving data that might be replayed. >> > >> > >> > > >> > > Is there any API available in OpenSSL for false start ? >> > >> > No, OpenSSL does not support false start. As an aside please >> > note that >> > false start only applies to <= TLSv1.2. >> > >> > >> > Thanks for your comments. >> > >> > I need some direction on the doing server and client side >> > authentication during the handshake. >> > >> > *1) For certificate sent from the server side, I am using* >> > >> > SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL)) for loading >> > verification file *on the client side* >> > >> > Where do I get a CAFILE in the above API. If the server is sending a >> > self signed certificate, what will be the CA file on the client side >> > for verification. >> > >> > >> > *2) For Client side authentication* >> > * >> > * >> > I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate >> > file on the client side to load the private key and the certificate. >> > I read that client side authentication will not kick off unless the >> > server sends CertificateRequest. I can use >> > SSL_CTX_set_client_cert_cb() that sets the client_cert_cb()callback >> > to be called on CertificateRequest. >> > >> > I am not sure how I can enable the server side to send >> > CertificateRequest. What is the API for that. >> > Should SSL_CTX_set_verify((ssl_ctx,SSL_VERIFY_PEER, NULL)) be used >> > on server side for sending the certificateRequest message. Please >> > correct me ? >> > >> > *3) Certificate request Message* >> > Also, what is the use of CertificateVerify message. Why does client >> > need to prove the ownership of private key for the public key sent >> > previously in the client certificate. I assume this is not happening >> > when the server sends the certificate. It doesn't prove the >> > ownership of private key.Please comment >> > >> > >> > >> > Also, some guidance on a reference for understanding the >> > authentication of certificates will be appreciated >> > >> > >> > Thanks >> > Neetish >> > >> > >> > >> > >> > Matt >> > >> > > >> > > Thanks >> > > Best regards, >> > > Neetish >> > > >> > > On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak < >> npathak2 at ncsu.edu >> > > >> wrote: >> > > >> > > I Appreciate your response >> > > >> > > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell < >> matt at openssl.org >> > > >> >> wrote: >> > > >> > > >> > > >> > > On 19/06/17 19:11, Neetish Pathak wrote: >> > > > 2) Can you suggest some places to put a time stamp >> in OpenSSL code. >> > > >> > > I agree with Ben's responses to all your other >> questions. For this >> > > question, I'm not sure what you are trying to >> achieve? Starting >> > > before >> > > SSL_accept/SSL_connect and finishing after they >> return should be >> > > fine. >> > > Or are you looking for a breakdown of where the time >> is going? >> > > >> > > Thanks Matt. I was asking for a breakdown since I was >> not sure >> > > if the SSL_accept and SSL_connect just do the >> handshake or if >> > > they are doing some other things that may impact >> latency and CPU >> > > usage. Just wanted to be clear that calling >> SSL_connect starts >> > > ClientHello , SSL_accept unblocks on receiving >> ClientHello and >> > > sends ServerHello, and both functions return after >> sending >> > > Finished message from their sides (i.e. client and >> server). >> > > >> > > >> > > >> > > >> > > >> > > Matt >> > > >> > > > >> > > > Thanks >> > > > Best Regards, >> > > > Neetish >> > > > >> > > > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell < >> matt at openssl.org >> > > >> > > > >> > >>> wrote: >> > > > >> > > > >> > > > >> > > > On 16/06/17 23:51, Neetish Pathak wrote: >> > > > > Thanks Matt, Appreciate ur response and tips >> > > > > >> > > > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell >> > >> > > >> > > >> > >> >> > > > > > > > > > >> > > >> > >>>> wrote: >> > > > > >> > > > > >> > > > > >> > > > > On 16/06/17 20:08, Benjamin Kaduk via >> > openssl-users >> > > wrote: >> > > > > > On 06/16/2017 01:58 PM, Neetish Pathak >> > wrote: >> > > > > >> Hello >> > > > > >> Thanks >> > > > > >> I tried reading some content from the >> > server >> > > side and I >> > > > observed the >> > > > > >> new_session_cb getting invoked in that >> > case on >> > > the client >> > > > side. I >> > > > > >> understand that may be due to delayed >> > NewSession info >> > > > transfer from >> > > > > >> server side to client side. But it is >> > helpful for >> > > saving >> > > > the session >> > > > > >> info on the client side. (Thanks Matt >> > for your input) >> > > > > >> >> > > > > >> However, now I have two concerns >> > > > > >> >> > > > > >> 1) I see that latency for handshake >> > with session >> > > resumption in >> > > > > TLS 1.3 >> > > > > >> has not improved as much as it improves >> > for TLS 1.2 >> > > > > >> With TLS 1.3, I observed that >> > resumption brings >> > > down the >> > > > connection >> > > > > >> time from 2.5 ms to 1.2-1.3 ms >> > > > > >> while with TLS 1.2 (using either >> > session IDs or >> > > tickets), the >> > > > > >> connection time reduces from 2.5 ms to >> > 0.5-0.6 ms. >> > > > > >> >> > > > > >> The whole code is similar for running >> > the two >> > > experiments >> > > > with only >> > > > > >> max TLS version changed. Can someone >> > comment on >> > > the latency >> > > > > >> measurements for the two cases. >> > > > > >> TLS 1.3 is supposed to be better than >> > TLS 1.2 in my >> > > > opinion. Please >> > > > > >> comment. >> > > > > >> >> > > > > > >> > > > > > Are you seeing a HelloRetryRequest in >> the >> > > resumption flow? >> > > > That would >> > > > > > add an additional round trip. (Your >> > numbers in >> > > milliseconds >> > > > are of >> > > > > > course not transferrable to other >> systems; >> > > round-trips is an >> > > > easier to >> > > > > > understand number.) RFC 5246 and >> > > draft-ietf-tls-tls13-20 >> > > > both have >> > > > > > message-flow diagrams that show the >> > number of >> > > round trips in >> > > > various >> > > > > > handshake flows. >> > > > > >> > > > > Care should also be taken about when you >> are >> > > starting your >> > > > "timer" and >> > > > > when you stop it, e.g. if you stop your >> > timer after the >> > > > session ticket >> > > > > data has been received by the client then >> > this is >> > > not a "fair" >> > > > test (the >> > > > > connection is ready for data transfer >> > earlier than >> > > the arrival >> > > > of the >> > > > > session ticket). >> > > > > >> > > > > I would expect to see the TLS1.3 latency >> > for a full >> > > handshake >> > > > to be >> > > > > around the same as for a TLS1.2 resumption >> > > handshake. With a >> > > > TLS1.3 >> > > > > resumption only marginally different. >> > There are the same >> > > > number of round >> > > > > trips for a TLS1.3 full handshake as that >> > there are >> > > for a >> > > > resumption >> > > > > one. The primary difference is that the >> > Certificate >> > > message is >> > > > not sent >> > > > > (which can be quite a large message). >> > > > > >> > > > > Your timings suggest you are testing this >> > over a LAN >> > > where the >> > > > effects >> > > > > of network latency are going to be >> > relatively low. >> > > The real >> > > > benefits >> > > > > from fewer round trips will really be seen >> > when network >> > > > latency is more >> > > > > significant. >> > > > > >> > > > > >> > > > > >> > > > > In my application program, I put start and >> > stop timer >> > > before and after >> > > > > SSL_accept on server side and before and after >> > > SSL_connect on the >> > > > client >> > > > > side. >> > > > >> > > > That should be fine (my worry was that you might >> > also be >> > > including the >> > > > subsequent session ticket transfer). >> > > > >> > > > > I am not sure how I can put timers at >> > individual steps >> > > of Handshake >> > > > > using my client applications. I was assuming >> > SSL and >> > > SSL_accept take >> > > > > care of the entire handshake process. >> > > > > >> > > > > Yes, I am testing on local machine. I will >> > migrate my >> > > test to remote >> > > > > machines. But I am not really able to >> > understand why TLS >> > > 1.3 is slower >> > > > > on my machine. >> > > > >> > > > If you are on a local machine I would not >> expect a >> > > significant speed up >> > > > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed >> > to reduce >> > > the number of >> > > > round-trips required in order to avoid >> > unnecessary network >> > > latency. If >> > > > you are on a local machine then there isn't any >> > > significant network >> > > > latency anyway - so timings are presumably >> > dominated by >> > > the CPU >> > > > intensive tasks. You should make sure that you >> are >> > > comparing like with >> > > > like, i.e. the same ciphers, key lengths, key >> > exchange >> > > algorithms, >> > > > curves etc between TLSv1.2 and TLSv1.3. >> > Differences in any >> > > one of these >> > > > could obviously have significant performance >> > impacts. >> > > > >> > > > 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/mailm >> an/listinfo/openssl-users >> > >> > > >> > > > > >> > > >> > > >> > > >> > -- >> > 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 rsalz at akamai.com Thu Jun 29 00:51:17 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 29 Jun 2017 00:51:17 +0000 Subject: [openssl-users] Loading multiple private keys a certificates on server program In-Reply-To: References: Message-ID: > I am building a server and client program. I wanted to know if the client intends to use a particular cipher suite ECDHE256 ECDSA 256 types and presents it to the server as its only ciphersuite. Then who decides the Diffie-hellman and EC parameters. Should the parameters be decided on the client side or the server side? This is starting to feel like a homework project. :) Read the TLS 1.2 RFC to get your answers. From npathak2 at ncsu.edu Fri Jun 30 21:18:00 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Fri, 30 Jun 2017 14:18:00 -0700 Subject: [openssl-users] PSK generation for TLS 1.3 Message-ID: Hi All, Can anyone provide me pointers on how can we generate external PSK to be used inTLS 1.3. When I save a a session using SSL_CTX_sess_set_new_cb(), it provides an in-band PSK for next resumption connection. I use PEM_write_bio_SSL_SESSION to save the session. How do we use PSK externally. Can I use the same session file which was saved during in-band connection. I believe in case of an external PSK, both client and server should have a copy in advance. Thanks Best Regards, Neetish -------------- next part -------------- An HTML attachment was scrubbed... URL: