Resetting DTLS server
If i setup a DTLS server, the client can connect once and send messages find. but if the client restarts and tries to send data, the server hangs on SSL_read. I'm assuming the server does not like a clienthello message when it is expecting application data. How can the server be made to recover and re-handshake with the restarted client?
Re: Removing Extensions from Client Hello Header
On 11/11/2019 20:51, Phil Neumiller wrote: > Extension: ec_point_formats (len=4) > Type: ec_point_formats (11) > Length: 4 > EC point formats Length: 3 > Elliptic curves point formats (3) > EC point format: uncompressed (0) > EC point format: ansiX962_compressed_prime (1) > EC point format: ansiX962_compressed_char2 (2) > Extension: session_ticket (len=0) > Type: session_ticket (35) > Length: 0 > Data (0 bytes) > Extension: encrypt_then_mac (len=0) > Type: encrypt_then_mac (22) > Length: 0 > Extension: extended_master_secret (len=0) > Type: extended_master_secret (23) > Length: 0 You don't need these four for TLSv1.3 SSL_OP_NO_TICKET will turn off session_ticket. SSL_OP_NO_ENCRYPT_THEN_MAC will turn off encrypt_then_mac. SSL_OP_NO_EXTENDED_MASTER_SECRET will turn off extended_master_secret. Don't switch off encrypt-then-mac or extended-master-secret unless you *really* need to. They don't do anything in TLSv1.3 but if you ever ended up negotiating TLSv1.2 by mistake for some reason then switching these things off has security consequences. I think the only way to get rid of ec_point_formats would be to disable EC from being used completely. But, you need EC to be enabled in order use TLSv1.3 (at least in 1.1.1 - in master its different). So I don't think you can get rid of this extension. But I'd really look at why your hardware is failing when these extensions are present. Is it intolerant of one particular extension? If so I'd just disable that one. Matt
Re: Removing Extensions from Client Hello Header
On 11/11/2019 21:09, Phil Neumiller wrote: > The hardware wants to see a client hello like the following: By this do you imply that if you give it additional extensions it fails? That is a highly non-compliant implementation!! Matt
Re: Removing Extensions from Client Hello Header
On 11/11/2019 22:12, Michael Wojcik wrote: > -Original Message- >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of >> Phil Neumiller >> Sent: Monday, November 11, 2019 15:57 >> >> Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL); > > That's just a verbose way of saying SSL_CTX_set_options(ctx, 0). > > Perhaps you meant SSL_CTX_set_options(ctx, ~SSL_OP_ALL)? I certainly wouldn't > recommend that - it would enable a host of options which aren't included in > SSL_OP_ALL, and which you very likely shouldn't be enabling. (And also some > you perhaps should, such as SSL_OP_SINGLE_ECDH_USE, though I don't remember > offhand if that affects TLSv1.3.) There is no need to enable SSL_OP_SINGLE_ECDH_USE. In fact that option does nothing: /* Removed from OpenSSL 1.1.0. Was 0x0008L */ # define SSL_OP_SINGLE_ECDH_USE 0x0 Matt
RE: Removing Extensions from Client Hello Header
-Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Phil Neumiller > Sent: Monday, November 11, 2019 15:57 > > Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL); That's just a verbose way of saying SSL_CTX_set_options(ctx, 0). Perhaps you meant SSL_CTX_set_options(ctx, ~SSL_OP_ALL)? I certainly wouldn't recommend that - it would enable a host of options which aren't included in SSL_OP_ALL, and which you very likely shouldn't be enabling. (And also some you perhaps should, such as SSL_OP_SINGLE_ECDH_USE, though I don't remember offhand if that affects TLSv1.3.) SSL_OP_ALL is defined as "various bug workarounds that should be rather harmless". I don't believe its use is appropriate here. As with any implementation of any protocol, there are limits to OpenSSL's ability to deal with noncompliant peers. This may be a case where you have to customize your OpenSSL build in order to get it to connect to your apparently-non-compliant server. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: Removing Extensions from Client Hello Header
The hardware wants to see a client hello like the following: Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 253 Version: TLS 1.2 (0x0303) Random: 00010002000400090012… GMT Unix Time: Dec 31, 1969 17:00:00.0 MST Random Bytes: 000100020004000900120024… Session ID Length: 0 Cipher Suites Length: 2 Cipher Suites (1 suite) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 210 Extension: supported_groups (len=4) Type: supported_groups (10) Length: 4 Supported Groups List Length: 2 Supported Groups (1 group) Supported Group: x25519 (0x001d) Extension: signature_algorithms (len=4) Type: signature_algorithms (13) Length: 4 Signature Hash Algorithms Length: 2 Signature Hash Algorithms (1 algorithm) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Extension: key_share (len=38) Type: key_share (51) Length: 38 Key Share extension Client Key Share Length: 36 Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: 009201240249049209241249… Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: supported_versions (len=3) Type: supported_versions (43) Length: 3 Supported Versions length: 2 Supported Version: TLS 1.3 (0x0304) Extension: heartbeat (len=1) Type: heartbeat (15) Length: 1 Mode: Peer not allowed to send requests (2) Extension: pre_shared_key (len=130) Type: pre_shared_key (41) Length: 130 Pre-Shared Key extension Identities Length: 28 PSK Identity (length: 8) Identity Length: 8 Identity: 924900012492 Obfuscated Ticket Age: 0 PSK Identity (length: 8) Identity Length: 8 Identity: Obfuscated Ticket Age: 0 PSK Binders length: 98 PSK Binders - Phillip Neumiller Platform Engineering Directstream, LLC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Removing Extensions from Client Hello Header
Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL); - Phillip Neumiller Platform Engineering Directstream, LLC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Removing Extensions from Client Hello Header
By doing the following in my code: I was able to get the Client Hello Extensions down to. Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 365 Version: TLS 1.2 (0x0303) Random: 19ff8a9231e83985887f5e45f2c9b243f0ccaa955beb1f03… Session ID Length: 32 Session ID: ebcab15bff6e5abfc14588298b45a56f74963eda97645992… Cipher Suites Length: 8 Cipher Suites (4 suites) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 284 Extension: ec_point_formats (len=4) Type: ec_point_formats (11) Length: 4 EC point formats Length: 3 Elliptic curves point formats (3) EC point format: uncompressed (0) EC point format: ansiX962_compressed_prime (1) EC point format: ansiX962_compressed_char2 (2) Extension: supported_groups (len=8) Type: supported_groups (10) Length: 8 Supported Groups List Length: 6 Supported Groups (3 groups) Supported Group: secp521r1 (0x0019) Supported Group: secp384r1 (0x0018) Supported Group: secp256r1 (0x0017) Extension: session_ticket (len=0) Type: session_ticket (35) Length: 0 Data (0 bytes) Extension: encrypt_then_mac (len=0) Type: encrypt_then_mac (22) Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: signature_algorithms (len=30) Type: signature_algorithms (13) Length: 30 Signature Hash Algorithms Length: 28 Signature Hash Algorithms (14 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ed25519 (0x0807) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (7) Signature Algorithm: ed448 (0x0808) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (8) Signature Algorithm: rsa_pss_pss_sha256 (0x0809) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (9) Signature Algorithm: rsa_pss_pss_sha384 (0x080a) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (10) Signature Algorithm: rsa_pss_pss_sha512 (0x080b) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (11) Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (4) Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (5) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (6) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Extension: supported_versions (len=3) Type: supported_versions (43) Length: 3 Supported Versions length: 2 Supported Version: TLS 1.3 (0x0304) Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: key_share (len=139) Type: key_share (51) Length: 139 Key Share
Re: Removing Extensions from Client Hello Header
On 11/11/2019 19:43, Benjamin Kaduk via openssl-users wrote: > On Mon, Nov 11, 2019 at 12:32:22PM -0700, Phil Neumiller wrote: >> I am speaking TLS 1.3 with openssl to a hardware device that I can't change. >> I need the client hello header to only support certain extensions, yet I Any compliant implementation should ignore extensions it doesn't understand so why do you need to do this? >> see no way in the SSL API to remove the default extensions in the TLS 1.3 >> client hello. Can I clear them all and just add the ones I want? What am I >> missing? Do I have to modify the SSL code to do this? It seems like there >> should be an orthodox way to do this. > > You have to disable them one by one; see SSL_CTX_set_options(3) and (e.g.) > SSL_OP_NO_EXTENDED_MASTER_SECRET. Only certain headers can be disabled in this way. Many of the extensions present in a TLSv1.3 ClientHello are necessary for proper functioning of the protocol. Which extensions did you actually want to disable? Matt
Re: Removing Extensions from Client Hello Header
On Mon, Nov 11, 2019 at 12:32:22PM -0700, Phil Neumiller wrote: > I am speaking TLS 1.3 with openssl to a hardware device that I can't change. > I need the client hello header to only support certain extensions, yet I > see no way in the SSL API to remove the default extensions in the TLS 1.3 > client hello. Can I clear them all and just add the ones I want? What am I > missing? Do I have to modify the SSL code to do this? It seems like there > should be an orthodox way to do this. You have to disable them one by one; see SSL_CTX_set_options(3) and (e.g.) SSL_OP_NO_EXTENDED_MASTER_SECRET. -Ben
Removing Extensions from Client Hello Header
I am speaking TLS 1.3 with openssl to a hardware device that I can't change. I need the client hello header to only support certain extensions, yet I see no way in the SSL API to remove the default extensions in the TLS 1.3 client hello. Can I clear them all and just add the ones I want? What am I missing? Do I have to modify the SSL code to do this? It seems like there should be an orthodox way to do this. - Phillip Neumiller Platform Engineering Directstream, LLC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: valgrind complaining about s_client (maybe assembler code?)
Hiya, On 11/11/2019 16:50, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On >> Behalf Of Stephen Farrell Sent: Monday, November 11, 2019 09:53 >> >> I'm seeing some errors from valgrind when running s_client from a >> clean build from the tip. (Details of that below.) > > Have you reviewed past discussions about valgrind and OpenSSL? I wouldn't say I reviewed it all in detail no, but yep, I did spend a while checking and didn't find the same issue. (Apologies if I missed it, which is always possible;-) > https://duckduckgo.com/html?q=site%3Amta.openssl.org%20openssl-users%20valgrind > > In general, memory-use checkers such as valgrind's memcheck are > going to be suspicious of some aspects of OpenSSL, which makes some > assumptions about memory that it knows are suitable, but which cannot > generally be verified by typical static or dynamic analysis. Sure. OTOH, I didn't see these errors until just now when I rebased with upstream so they seem to be new, (in the last couple of months), or I guess could be down to some novelty with my CPU/compiler, given I'm using a brand new laptop and Ubuntu 19.10;-) FWIW, valgrind hasn't been giving me false positives over the last year or so, and has been v. useful in finding leaks, so it'd be nice if there were a fix or better workaround than "no-asm" (but since I do have "no-asm", and don't need go-faster-stripes, this isn't urgent for me). Cheers, S. > > -- Michael Wojcik Distinguished Engineer, Micro Focus > > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: valgrind complaining about s_client (maybe assembler code?)
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Stephen Farrell > Sent: Monday, November 11, 2019 09:53 > > I'm seeing some errors from valgrind when running s_client > from a clean build from the tip. (Details of that below.) Have you reviewed past discussions about valgrind and OpenSSL? https://duckduckgo.com/html?q=site%3Amta.openssl.org%20openssl-users%20valgrind In general, memory-use checkers such as valgrind's memcheck are going to be suspicious of some aspects of OpenSSL, which makes some assumptions about memory that it knows are suitable, but which cannot generally be verified by typical static or dynamic analysis. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: Problems porting Openssl 1.1.1d to zos.
On 11.11.19 16:42, Wendell Nichols via openssl-users wrote: Is there anyone on this group with experience with ebcdic platforms, specifically zOS? I have built 1.1.1d on zOS and connections to my server work for firefox 60 but not newer versions. I don't know exactly where the cut off is or what they changed but current versions get an HMAC error. I strongly suspect that it is keying the hmac with some combination of inputs that include an improperly translated text string, but I don't know for sure. Its quite hard to track down when you don't have a debugger. The error message: An error occurred during a connection to cafe.na.tibco.com:1802. SSL received a record with an incorrect Message Authentication Code. Error code: SSL_ERROR_BAD_MAC_READ If anyone can suggest an approach to figuring this out I'd be grateful. Wendell Nichols Incidentally, I just merged a pull request that fixed a misspelled EBCDIC string to master and 1.1.1. https://github.com/openssl/openssl/pull/10396#issuecomment-552506972 But I have no idea whether it is related to your problem. Nevertheless, you might want to retry with the current tip of the OpenSSL_1_1_1-stable branch. Regards, Matthias
Problems porting Openssl 1.1.1d to zos.
Is there anyone on this group with experience with ebcdic platforms, specifically zOS? I have built 1.1.1d on zOS and connections to my server work for firefox 60 but not newer versions. I don't know exactly where the cut off is or what they changed but current versions get an HMAC error. I strongly suspect that it is keying the hmac with some combination of inputs that include an improperly translated text string, but I don't know for sure. Its quite hard to track down when you don't have a debugger. The error message: An error occurred during a connection to cafe.na.tibco.com:1802. SSL received a record with an incorrect Message Authentication Code. Error code: SSL_ERROR_BAD_MAC_READ If anyone can suggest an approach to figuring this out I'd be grateful. Wendell Nichols
valgrind complaining about s_client (maybe assembler code?)
Hiya, I'm seeing some errors from valgrind when running s_client from a clean build from the tip. (Details of that below.) In another build, (for ESNI), when I do a GCM encrypt and then read the tag, it looks like the error is coming from some sha256 assembler code: ==27027== Uninitialised value was created by a stack allocation ==27027==at 0x4B0ED63: sha256_block_data_order_avx2 (sha256-x86_64.s:4192) Building either (clean or my ESNI fork) with "no-asm" works without valgrind complaining, as do other debug builds, but it seems like once optimisation is turned on, these errors occur. They don't however, seem to affect correct operation of TLS though (in either build). On a 32-bit system the ESNI build also seems fine with or without optimisation. Details below for a clean clone from github. The full valgrind/s_client output with stdout & stderr can be found at [1]. I manually added a "-g" to the Makefile (leaving on "-O3" as well), and the equivalent output is at [2] and seems to show that valgrind sees the error around some GCM tag handling code again. The equivalent output when built with "no-asm" is at [3] and has no valgrind errors. Any ideas? Thanks, S. [1] https://down.dsg.cs.tcd.ie/misc/vgerrs.txt [2] https://down.dsg.cs.tcd.ie/misc/vgerrs-sym.txt [3] https://down.dsg.cs.tcd.ie/misc/vgnoasm.txt My system: Machine: Dell XPS13 OS: Ubuntu 19.10 up to date CPU: Intel® Core™ i7-10510U CPU @ 1.80GHz × 8 The build is using gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008 The first error seen for the clean build from the tip is: ==19663== Conditional jump or move depends on uninitialised value(s) ==19663==at 0x4B6F962: gcm_stream_final (in /home/stephen/code/openssl-clean-upstream/libcrypto.so.3) ==19663==by 0x4A7BE35: EVP_DecryptFinal_ex (in /home/stephen/code/openssl-clean-upstream/libcrypto.so.3) ==19663==by 0x4899256: tls13_enc (in /home/stephen/code/openssl-clean-upstream/libssl.so.3) ==19663==by 0x4897AED: ssl3_get_record (in /home/stephen/code/openssl-clean-upstream/libssl.so.3) ==19663==by 0x4894D27: ssl3_read_bytes (in /home/stephen/code/openssl-clean-upstream/libssl.so.3) ==19663==by 0x48AE320: tls_get_message_header (in /home/stephen/code/openssl-clean-upstream/libssl.so.3) ==19663==by 0x48A44FC: state_machine.part.0 (in /home/stephen/code/openssl-clean-upstream/libssl.so.3) ==19663==by 0x48942B7: ssl3_write_bytes (in /home/stephen/code/openssl-clean-upstream/libssl.so.3) ==19663==by 0x487B868: ssl_write_internal (in /home/stephen/code/openssl-clean-upstream/libssl.so.3) ==19663==by 0x487BA96: SSL_write (in /home/stephen/code/openssl-clean-upstream/libssl.so.3) ==19663==by 0x172E5A: s_client_main (in /home/stephen/code/openssl-clean-upstream/apps/openssl) ==19663==by 0x160105: do_cmd (in /home/stephen/code/openssl-clean-upstream/apps/openssl) The commands I used to build and generate the errors: $ cd $HOME/code $ git clone https://github.com/openssl/openssl.git openssl-clean-upstream $ cd openssl-clean-upstream $ ./config ... stuff ... $ make -j8 ... stuff ... $ export LD_LIBRARY_PATH=$HOME/code/openssl-clean-upstream $ echo -e "GET /" | valgrind ./apps/openssl s_client -msg -debug -CApath /etc/ssl/certs/ -no_ssl3 -no_tls1 -no_tls1_1 -no_tls1_2 -connect www.cloudflare.com:443 -servername www.cloudflare.com >vgerrs.txt 2>&1 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
aesni_cbc_encrypt()
Hi, I am trying to pass explicit IV during TLS 1.2 encryption. I copied explicit IV to "ivec" before below function call. But IV on the encrypted output is totally different. Can any one help ? void aesni_cbc_encrypt(const unsigned char *in, unsigned char *out, size_t length, const AES_KEY *key, unsigned char *ivec, int enc); -Ratheesh
Re: dsaparam error OpenSSL 1.1.1d
The question about -rand option is valid, but Viktor’s post is right and the rest of my post is wrong :( From: openssl-users Reply-To: Rich Salz Date: Monday, November 11, 2019 at 8:10 AM To: shiva kumar , openssl-users Subject: Re: dsaparam error OpenSSL 1.1.1d * openssl dsaparam 128 -rand file Why are you using the -rand option? Unless this is a special platform, don’t do that. * is taking long time processing the command and not producing any output. What is your hardware and software? Can you run it under a debugger, and interrupt it sometimes to see where it is?
Re: dsaparam error OpenSSL 1.1.1d
* openssl dsaparam 128 -rand file Why are you using the -rand option? Unless this is a special platform, don’t do that. * is taking long time processing the command and not producing any output. What is your hardware and software? Can you run it under a debugger, and interrupt it sometimes to see where it is?
