Re: [openssl-users] Help with ssl error
>From the original question, it appears the server here only supports two >cipher suites: RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA This would explain the alert 71, which is the sent because there are no cipher suites in common. From: openssl-users on behalf of Viktor Dukhovni Sent: Tuesday, April 18, 2017 5:06 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] Help with ssl error On Tue, Apr 18, 2017 at 11:17:48AM -0400, Joseph Southwell wrote: > It doesn’t look like it requested a client certificate to me. Correct, the server alert was returned immediately in response to the TLS ClientHello. > $ openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 > -starttls ftp > CONNECTED(0104) > SSL_connect:before SSL initialization > >>> ??? [length 0005] > 16 03 01 00 ab > >>> TLS 1.2Handshake [length 00ab], ClientHello > 01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20 > 59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2 > 81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc > a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00 > 6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0 > 13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00 > ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00 > 0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00 > 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05 > 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 > 02 02 03 00 16 00 00 00 17 00 00 > SSL_connect:SSLv3/TLS write client hello > <<< ??? [length 0005] > 15 03 02 00 02 > <<< TLS 1.2Alert [length 0002], fatal insufficient_security > 02 47 > SSL3 alert read:fatal:insufficient security > SSL_connect:error in SSLv3/TLS write client hello > 3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient > security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71 The ClientHello decodes via tshark as: Secure Sockets Layer SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 171 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 167 Version: TLS 1.2 (0x0303) Random GMT Unix Time: Jun 5, 2064 16:07:35.0 AEST Random Bytes: 9dc43fde8a2059071fd7503e20cf92cba67d941d2fb281c0... Session ID Length: 0 Cipher Suites Length: 56 Cipher Suites (28 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) Cipher Suite: Unknown (0xcca9) Cipher Suite: Unknown (0xcca8) Cipher Suite: Unknown (0xccaa) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) 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_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 70 Extension: ec_point_formats Type: ec_point_formats (0x000b) Length: 4 EC point formats Length: 3 Elliptic curves point formats (3) EC point format: uncompressed (0) EC point format: ansiX96
Re: [openssl-users] SSL_shutdown return error when close in init
On Tue, 18 Apr 2017, mid...@163.com wrote: >Hello > I'm using open1.1.0e in async mode with intel QuickAssist Engine to handle > https connections? but there's some problem. > >client(ab)-- server(my program) > ><-TCP handshake> -ssl client >hello---> <-server hello,certicate...- >---client key exchange> >//here, server's SSL_do_handshake >reutrns SSL_ERROR_WANT_ASYNC repeatly, > >---FIN+ACK--> > >//client want to close the connection, then, server should close ssl >connection ,In program, I intend to close SSL connections in quiet mode? >SSL_set_quiet_shutdown(ssl,1); >SSL_shutdown(ssl); > >but SSL_shutdown returns SSL_ERROR_SSL, because SSL_in_init(s) return true. > >I'm confused, what should I do here ??? >(1) just call SSL_free(ssl) to free SSL connection, then the async engine may >callback and using SSL's waitctx, which cause crash. Also I noticed that >SSL's job >doesn't free neither, which may cause memory leak; > >(2)continue call SSL_shutdown(ssl), and it will always return SSL_ERROR_SSL > >Is anybody know? thanks The root cause of the issue is that it is not valid to move state from init to shutdown when there is still an asynchronous operation in progress. The fact that the client wants to close the connection should be saved, the asynchronous operation should be completed (keep calling SSL_do_handshake until SSL_get_error does not return SSL_ERROR_WANT_ASYNC) then based on what you saved do the same behaviour you would have done in the case of the client wanting to close the connection if you are running synchronously. As long as you have completed the asynchronous operation then there will be no problem calling SSL_free on the connection as there will be no callback that will run later. By continuing to call SSL_do_handshake until the sync job completes all you are doing is running the SSL_do_handshake to the same point it would have returned and detected the error if you were running synchronously. Note that it is never valid to call SSL_do_handshake(), start an asynchronous operation (SSL_get_error returning SSL_ERROR_WANT_ASYNC), then transition straight to calling a different asynchronous enabled function like SSL_shutdown(). If you do that you will find that when you call SSL_shutdown it will detect there is already an async job in progress and will context switch into that job rather than starting an async job for the SSL_shutdown behaviour. In other words you will end up running SSL_do_handshake code when you think you are running SSL_shutdown code. Even worse they may have completely different return behaviour so you get an unexpected result. The OpenSSL documentation makes it clear that you must keep calling the same asynchronous function with the same parameters until the async job has completed. Hope that helps, Steve Linsell Intel Shannon DCG/CID Software Development Team stevenx.lins...@intel.com -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Query regarding DTLS handshake
> On 13. Apr 2017, at 11:11, mahesh gs wrote: > > Hi, > > We are running SCTP connections with DTLS enabled in our application. We have > adapted openssl version (openssl-1.1.0e) to achieve the same. > > We have generated the self signed root and node certificates for testing. We > have a strange problem with the incomplete DTLS handshake if we run the DTLS > client and DTLS server is different systems.If we run the DTLS client and > server in same system handshake is successful, handshake is not successful if > run client and server in different VM's. > > This strange problem happens only for SCTP/DTLS connection. With the same set > of certificates TCP/TLS connection is successful and we are able to exchange > the application data. > > I am attaching the code bits for SSL_accept and SSL_connect and also the > wireshark trace of unsuccessful handshake. Please assist me to debug this > problem. > > SSL_accept returns SSL_ERROR_WANT_READ(2) infinite times but SSL_connect is > called 4 or 5 times and select system call timeout. Which OS are you using? With a test program I could reproduce SSL_accept() returning SSL_ERROR_WANT_READ under FreeBSD, but not under Linux. Haven't figured out what the problem is. So if you are using FreeBSD we might experience the same problem... Best regards Michael > > Thanks, > Mahesh G S > > > -- > 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
Re: [openssl-users] Help with ssl error
On Tue, Apr 18, 2017 at 11:17:48AM -0400, Joseph Southwell wrote: > It doesn’t look like it requested a client certificate to me. Correct, the server alert was returned immediately in response to the TLS ClientHello. > $ openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 > -starttls ftp > CONNECTED(0104) > SSL_connect:before SSL initialization > >>> ??? [length 0005] > 16 03 01 00 ab > >>> TLS 1.2Handshake [length 00ab], ClientHello > 01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20 > 59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2 > 81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc > a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00 > 6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0 > 13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00 > ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00 > 0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00 > 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05 > 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 > 02 02 03 00 16 00 00 00 17 00 00 > SSL_connect:SSLv3/TLS write client hello > <<< ??? [length 0005] > 15 03 02 00 02 > <<< TLS 1.2Alert [length 0002], fatal insufficient_security > 02 47 > SSL3 alert read:fatal:insufficient security > SSL_connect:error in SSLv3/TLS write client hello > 3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient > security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71 The ClientHello decodes via tshark as: Secure Sockets Layer SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 171 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 167 Version: TLS 1.2 (0x0303) Random GMT Unix Time: Jun 5, 2064 16:07:35.0 AEST Random Bytes: 9dc43fde8a2059071fd7503e20cf92cba67d941d2fb281c0... Session ID Length: 0 Cipher Suites Length: 56 Cipher Suites (28 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) Cipher Suite: Unknown (0xcca9) Cipher Suite: Unknown (0xcca8) Cipher Suite: Unknown (0xccaa) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) 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_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 70 Extension: ec_point_formats Type: ec_point_formats (0x000b) 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: elliptic_curves Type: elliptic_curves (0x000a) Length: 10 Elliptic Curves Length: 8 Elliptic curves (4 curves) Elliptic curve: Unknown (0x001d) Elliptic curve: secp256r1 (0x0017) Elliptic curve: secp521r1 (0x0019)
Re: [openssl-users] Help with ssl error
It doesn’t look like it requested a client certificate to me. openssl110e>openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 -starttls ftp CONNECTED(0104) SSL_connect:before SSL initialization >>> ??? [length 0005] 16 03 01 00 ab >>> TLS 1.2Handshake [length 00ab], ClientHello 01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20 59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2 81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00 6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0 13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00 ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00 0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 00 16 00 00 00 17 00 00 SSL_connect:SSLv3/TLS write client hello <<< ??? [length 0005] 15 03 02 00 02 <<< TLS 1.2Alert [length 0002], fatal insufficient_security 02 47 SSL3 alert read:fatal:insufficient security SSL_connect:error in SSLv3/TLS write client hello 3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 88 bytes and written 186 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1492518024 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- > On Apr 14, 2017, at 2:49 PM, Viktor Dukhovni > wrote: > > >> On Apr 14, 2017, at 9:48 AM, Joseph Southwell >> wrote: >> >> Version 1.1 openssl >> >> openssl.exe s_client -connect hostname:16370 -starttls ftp >> 877788:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient >> security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71 > > The remote host sent an "insufficient security" TLS alert. > >> The host I am connecting to apparently only supports the following 2 ciphers: >> RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA >> >> What should I do to make this work? > > Perhaps it is expecting a client certificate? Retry with: > > $ openssl s_client -state -msg -connect hostname:16370 -starttls ftp > > and see whether it solicited a client certificate. > > -- > Viktor. > > -- > 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
Re: [openssl-users] Multithreading: Global locks causing bottleneck in parallel SSL_write calls
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jakob Bohm > Sent: Tuesday, April 18, 2017 06:22 > > Please note that all of these "CBC vulnerabilities" you specifically > mention are SSL/TLS vulnerabilities in the particular ways that SSL3 > and current TLS versions handle padding and IV management, not > issues with CBC itself. > > Also note that GCM is very much a "marginal" design, operating at the > very edge of what is safe to do and furthermore putting all the > cryptographic "eggs" in one basket (AES and GF-2^n arithmetic). Agreed on both points. Of course with any block cipher operating mode that requires padding you have the possibility of protocol and implementation errors that create padding oracles. But with GCM you have the possibility of, say, implementation errors that lead to nonce reuse. All of the modes have risks. (Also AE / AEAD modes seem like they're on the edge of violating Moxie Marlinspike's Cryptographic Doom Principle: If message integrity isn't the very first thing you check, sooner or later you'll regret it. The CDP isn't scientific, but then neither is cryptographic protocol design. The rush to AEAD modes seems to be largely driven by performance concerns, and that does not make for good crypto. Take TLSv1.3's 0-RTT session resumption, for example.) And for most applications, attacking the crypto isn't a particularly likely mode of attack anyway. There are lower-hanging fruit, and even flawed crypto will direct the attacker's attention elsewhere. Or the nature of the application doesn't provide enough volume or flexibility to exploit a theoretical vulnerability. Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openvpn 2.4.1 with gost
Hello, As far as I know, openvpn does not work with GOST algorithms without patches. On Tue, Apr 18, 2017 at 12:16 PM, R.S via openssl-users < openssl-users@openssl.org> wrote: > Hello. > I have just build openvpn with openvpn-build with these versions: > OPENSSL_VERSION="${OPENSSL_VERSION:-1.0.2k}" > PKCS11_HELPER_VERSION="${PKCS11_HELPER_VERSION:-1.11}" > LZO_VERSION="${LZO_VERSION:-2.10}" > TAP_WINDOWS_VERSION="${TAP_WINDOWS_VERSION:-9.21.2}" > OPENVPN_VERSION="${OPENVPN_VERSION:-2.4.1}" > OPENVPN_GUI_VERSION="${OPENVPN_GUI_VERSION:-11}" > > Compilation success, no problem. > i modified openssl.cnf to include engine gost. > openssl_conf = openssl_def > [ openssl_def ] > engines = engine_section > [ engine_section ] > gost = gost_section > [gost_section] > default_algorithms=ALL > engine_id=gost > > openssl ciphers | tr ":" "\n" | grep GOST > GOST2001-GOST89-GOST89 > GOST94-GOST89-GOST89 > > openssl list-message-digest-algorithms | grep gost > gost-mac > md_gost94 > gost-mac > md_gost94 > > openssl shows me GOST. > > -- > gost-server.ovpn > - > dev tap > engine gost > auth gost-mac > cipher gost89 > tls-cipher GOST2001-GOST89-GOST89 > #comp-lzo yes > ca ca.crt > cert server.crt > key server.key > dhdhparam.pem > server 10.0.0.0 255.255.255.0 > keepalive 10 120 > proto tcp > socket-flags TCP_NODELAY > persist-key > persist-tun > > openvpn gost-server.ovpn says me > -- Initializing OpenSSL support for engine 'gost' > -- Deprecated TLS cipher name 'GOST2001-GOST89-GOST89', please use IANA > name 'TLS_GOSTR341001_WITH_28147_CNT_IMIT' > -- OpenSSL: error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher > match > -- Failed to set restricted TLS cipher list: GOST2001-GOST89-GOST89 > -- Exiting due to fatal error > > Please help with this problem > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- SY, Dmitry Belyavsky -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Integrating New Cipher Suite
On Fri, Apr 14, 2017, Schmicker, Robert wrote: > > > After some debugging (exactly as mentioned above) it appears that the cipher > suite does not show up in the ClientHello using the s_client/s_server. I > modified the cipher for testing to use 512 bits instead of 64 so that it is > ranked highest. > > Error server side: > SSL routines:tls_post_process_client_hello:no shared > cipher:ssl/statem/statem_srvr.c:1979 > > Error Client side: > SSL routines:ssl3_read_bytes:tlsv1 alert internal > error:ssl/record/rec_layer_s3.c:1469:SSL alert number 80 > > Any idea why the cipher would appear under the list of supported tls1.2 > ciphers, yet it does not appear under the ClientHello even if specified with > the -cipher option? > Hmm... it's not clear why the cipher isn't being sent in client hello. What output do you get with -security_debug_verbose option? Also try including @SECLEVEL=0 in the cipher string. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openvpn 2.4.1 with gost
Hello. I have just build openvpn with openvpn-build with these versions: OPENSSL_VERSION="${OPENSSL_VERSION:-1.0.2k}" PKCS11_HELPER_VERSION="${PKCS11_HELPER_VERSION:-1.11}" LZO_VERSION="${LZO_VERSION:-2.10}" TAP_WINDOWS_VERSION="${TAP_WINDOWS_VERSION:-9.21.2}" OPENVPN_VERSION="${OPENVPN_VERSION:-2.4.1}" OPENVPN_GUI_VERSION="${OPENVPN_GUI_VERSION:-11}" Compilation success, no problem. i modified openssl.cnf to include engine gost. openssl_conf = openssl_def [ openssl_def ] engines = engine_section [ engine_section ] gost = gost_section [gost_section] default_algorithms=ALL engine_id=gost openssl ciphers | tr ":" "\n" | grep GOST GOST2001-GOST89-GOST89 GOST94-GOST89-GOST89 openssl list-message-digest-algorithms | grep gost gost-mac md_gost94 gost-mac md_gost94 openssl shows me GOST. -- gost-server.ovpn - dev tap engine gost auth gost-mac cipher gost89 tls-cipher GOST2001-GOST89-GOST89 #comp-lzo yes ca ca.crt cert server.crt key server.key dh dhparam.pem server 10.0.0.0 255.255.255.0 keepalive 10 120 proto tcp socket-flags TCP_NODELAY persist-key persist-tun openvpn gost-server.ovpn says me -- Initializing OpenSSL support for engine 'gost' -- Deprecated TLS cipher name 'GOST2001-GOST89-GOST89', please use IANA name 'TLS_GOSTR341001_WITH_28147_CNT_IMIT' -- OpenSSL: error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match -- Failed to set restricted TLS cipher list: GOST2001-GOST89-GOST89 -- Exiting due to fatal error Please help with this problem -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Segmentation fault ssl23_connect()
Thanks. I'll try that. Regards, Sanjaya On 18 Apr 2017 15:27, "Matt Caswell" wrote: > > > On 16/04/17 20:17, Sanjaya Joshi wrote: > > Hello, > > > > I use openldap_2.3.39 to initiate secure LDAP connection (starttls) to > > external LDAP server. The used openssl version is 1.0.2k. > > > > While establishing the secure connection from client, i observe the > > following segmentation fault occasionally (Not always reproducible). > > > > Any pointers please ? > > > > Are you able to compile openssl with debug symbols? That's not a lot to > go on. > > Matt > > > " > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib64/libthread_db.so.1". > > Core was generated by `/opt/nsn/pac_bor_qx_e1/bin/border'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x7fd6b8271bd9 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 > > (gdb) bt > > #0 0x7fd6b8271bd9 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 > > #1 0x7fd6b3495516 in ssl23_connect () from > /usr/lib64/libssl.so.1.0.0 > > #2 0x7fd6b7d2d6cf in ldap_int_tls_connect (ld=0x7fd6880486d0, > > conn=0x7fd68802d9e0) at tls.c:805 > > #3 0x7fd6b7d2ece0 in ldap_int_tls_start (ld=0x7fd6880486d0, > > conn=0x7fd68802d9e0, srv=0x0) at tls.c:1511 > > #4 0x7fd6b7d2f6e9 in ldap_install_tls (ld=0x7fd6880486d0) at > tls.c:1935 > > #5 0x7fd6bb46c6c1 in open_connection_as > > (ldap_host_address=0x7fd68805de90 "10.55.433.1", port=389, > client_access=0, > > user_dn=0x7fd6880543c8 > > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > > user_pwd=0x7fd6962d3c70 "saaadh45sks", ldap_handle=0x7fd6962d2838, > > network_timeout=5000, request_id=0x7fd6962d144c, > > error_string=0x7fd6962d1440, isSecure=2, cacertFile=0x7fd688048bf8 > > "/etc/certs/cacert.pem", > > ciphers=0x7fd68805e138 > > "DHE-RSA-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:AES128-SHA", > > reqCert=0x7fd6962d2558) at ../src/api.c:1048 > > #6 0x7fd6bb46ca97 in open_secure_connection_starttls_request > > (ldap_host_address=0x7fd68805de90 "10.55.433.1", port=389, > > client_access=0, user_dn=0x7fd6880543c8 > > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > > user_pwd=0x7fd6962d3c70 "saaadh45sks", ldap_handle=0x7fd6962d2838, > > network_timeout=5000, request_id=0x7fd6962d144c, > > error_string=0x7fd6962d1440, cacertFile=0x7fd688048bf8 > > "/etc/certs/cacert.pem", > > ciphers=0x7fd68805e138 > > "DHE-RSA-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:AES128-SHA", > > reqCert=0x7fd6962d2558) at ../src/api.c:1258 > > #7 0x7fd6b9c899c8 in tryConnectExtLdap (host=0x7fd68805de90 > > "10.55.433.1", port=389, > > binddn=0x7fd6962d3380 > > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > > pwd=0x7fd6962d3c70 "saaadh45sks", > > _extHandle=@0x7fd6962d2838: 0x7fd6880486d0, peopledn=0x7fd6880495b0 > > "ou=people,ou=accounts,dc=sasa,dc=test,dc=net", secureMode=0, > > cacertFile=..., ciphers=..., reqCert=5, timeout_ms=5000) > > at ../../src/acct.cpp:1694 > > #8 0x7fd6b9c88df1 in validate_account (accountName=0x7fd6962d3380 > > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > > accountPassword=0x7fd6962d3c70 "saaadh45sks") at > ../../src/acct.cpp:1623 > > #9 0x00479d3a in set_acc > > (userName=userName@entry=0x7fd6962d3870 "user1", > > password=password@entry=0x7fd6962d3c70 "saaadh45sks") at > > ../src/borfunc_cou.c:4066 > > #10 0x0045217b in _71571_2 (_T=0x42907000) at > > ../src/bor7qxqx.sdl:600 > > #11 0x0044fd45 in _s71571_ACTIVE (_T=) at > > _Sborha7ACTIVE.c:33 > > #12 0x7fd6b6ec8a65 in call_transition (msg=0x7fd6bc0d8948, > process=96) > > at /home/core/threadmain.c:656 > > #13 call_transition_with_fatal_sig_catching (thread=, > > thread@entry=0x25d7d90, process=process@entry=96, > > msg=msg@entry=0x7fd6bc0d8948) at /home/core/threadmain.c:669 > > #14 0x7fd6b6ec9499 in execute_user_code (msg=0x7fd6bc0d8948, > > process=96, thread=0x25d7d90) > > at /home/core/threadmain.c:687 > > #15 exec_main_loop (thread=0x25d7d90) at /home/core/threadmain.c:882 > > #16 thread_context_main (arg=) at > /home/core/threadmain.c:592 > > #17 0x7fd6b64f2f50 in ?? () from /lib64/libc.so.6 > > #18 0x in ?? () > > (gdb) > > " > > > > Regards, > > Sanjaya > > > > > -- > 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
Re: [openssl-users] Multithreading: Global locks causing bottleneck in parallel SSL_write calls
On 13/04/2017 22:01, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Dipak Gaigole Sent: Thursday, April 13, 2017 15:12 I will try with disabling FIPS. Opinions differ, but many people - including myself - recommend not enabling FIPS mode unless it is explicitly required (generally because you work for the US Federal Government or a relatively small number of other organizations that let bureaucracy stand in the way of security). Where can i find current best practice cipher list? Or Can you suggest few? The free ebook /OpenSSL Cookbook/ from Feisty Duck is a good place to start. It was updated only a year ago, so it's reasonably current. https://www.feistyduck.com/books/openssl-cookbook/ Beyond that, you really need to be following current research, or at least the people who write knowledgeably about current research. Ben wrote "AES256-SHA is both CBC and SHA1, neither of which is really a current best practice". Certainly the bloom is off the rose of SHA1, particularly since the "SHAttered" demonstration of a successful collision. The reality is that SHA1 is still fine for many purposes in practice; but if you're in a position to pick a better digest, it makes sense to do so. That means SHA-256 or SHA-384; or perhaps SHA3 with appropriate parameters, but SHA3 hasn't seen widespread adoption yet. (That's more or less by design - NIST wanted to standardize SHA3 before it was needed.) Regarding CBC, he presumably was referring to the various issues with CBC mode and the general move to various AE and AEAD combining modes, particularly GCM. AES-GCM suites are most people's default recommendation these days, when there aren't any compelling reasons to use something else. With GCM you have to be careful that you have a solid implementation and you never reuse an IV, so it's a bit easier for a non-expert to screw up. But considering the aforementioned issues with CBC, it's easy to see why people recommend it. There's a ton of information - more than a non-expert can be expected to absorb - on these topics available online, even if we ignore the actual primary research and just look at treatments for lay readers. Adam Langley talks about the problems with AES-CBC in particular in this post, for example: https://security.googleblog.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html In TLS, AES-CBC is vulnerable to the BEAST (TLS 1.0 only) and Lucky13 attacks, given certain other conditions. Lucky13 (aka "Lucky Thirteen") actually applies to all block ciphers in CBC mode, if the implementation exposes certain timing side channels. These days decent implementations (including OpenSSL) try to remove or whiten side channels, but that's actually quite difficult to do comprehensively (see various pieces of research published over the past several years). Again, for many applications, these attacks simply aren't feasible. But many applications are developed without the benefit of a cryptographer who can look at them and decide whether you need to worry about them. Please note that all of these "CBC vulnerabilities" you specifically mention are SSL/TLS vulnerabilities in the particular ways that SSL3 and current TLS versions handle padding and IV management, not issues with CBC itself. Also note that GCM is very much a "marginal" design, operating at the very edge of what is safe to do and furthermore putting all the cryptographic "eggs" in one basket (AES and GF-2^n arithmetic). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] QcStatements with OpenSSL (C++)?
Hi there, can OpenSSL pasre QcStatement X509v3 Extension btw. Did OpenSSL Support these? Any Piece of example Code of how can i parse the data? Thanks Matthias -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Segmentation fault ssl23_connect()
On 16/04/17 20:17, Sanjaya Joshi wrote: > Hello, > > I use openldap_2.3.39 to initiate secure LDAP connection (starttls) to > external LDAP server. The used openssl version is 1.0.2k. > > While establishing the secure connection from client, i observe the > following segmentation fault occasionally (Not always reproducible). > > Any pointers please ? > Are you able to compile openssl with debug symbols? That's not a lot to go on. Matt > " > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `/opt/nsn/pac_bor_qx_e1/bin/border'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x7fd6b8271bd9 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 > (gdb) bt > #0 0x7fd6b8271bd9 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 > #1 0x7fd6b3495516 in ssl23_connect () from /usr/lib64/libssl.so.1.0.0 > #2 0x7fd6b7d2d6cf in ldap_int_tls_connect (ld=0x7fd6880486d0, > conn=0x7fd68802d9e0) at tls.c:805 > #3 0x7fd6b7d2ece0 in ldap_int_tls_start (ld=0x7fd6880486d0, > conn=0x7fd68802d9e0, srv=0x0) at tls.c:1511 > #4 0x7fd6b7d2f6e9 in ldap_install_tls (ld=0x7fd6880486d0) at tls.c:1935 > #5 0x7fd6bb46c6c1 in open_connection_as > (ldap_host_address=0x7fd68805de90 "10.55.433.1", port=389, client_access=0, > user_dn=0x7fd6880543c8 > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > user_pwd=0x7fd6962d3c70 "saaadh45sks", ldap_handle=0x7fd6962d2838, > network_timeout=5000, request_id=0x7fd6962d144c, > error_string=0x7fd6962d1440, isSecure=2, cacertFile=0x7fd688048bf8 > "/etc/certs/cacert.pem", > ciphers=0x7fd68805e138 > "DHE-RSA-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:AES128-SHA", > reqCert=0x7fd6962d2558) at ../src/api.c:1048 > #6 0x7fd6bb46ca97 in open_secure_connection_starttls_request > (ldap_host_address=0x7fd68805de90 "10.55.433.1", port=389, > client_access=0, user_dn=0x7fd6880543c8 > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > user_pwd=0x7fd6962d3c70 "saaadh45sks", ldap_handle=0x7fd6962d2838, > network_timeout=5000, request_id=0x7fd6962d144c, > error_string=0x7fd6962d1440, cacertFile=0x7fd688048bf8 > "/etc/certs/cacert.pem", > ciphers=0x7fd68805e138 > "DHE-RSA-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:AES128-SHA", > reqCert=0x7fd6962d2558) at ../src/api.c:1258 > #7 0x7fd6b9c899c8 in tryConnectExtLdap (host=0x7fd68805de90 > "10.55.433.1", port=389, > binddn=0x7fd6962d3380 > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > pwd=0x7fd6962d3c70 "saaadh45sks", > _extHandle=@0x7fd6962d2838: 0x7fd6880486d0, peopledn=0x7fd6880495b0 > "ou=people,ou=accounts,dc=sasa,dc=test,dc=net", secureMode=0, > cacertFile=..., ciphers=..., reqCert=5, timeout_ms=5000) > at ../../src/acct.cpp:1694 > #8 0x7fd6b9c88df1 in validate_account (accountName=0x7fd6962d3380 > "uid=user1,ou=people,ou=accounts,dc=sasa,dc=test,dc=net", > accountPassword=0x7fd6962d3c70 "saaadh45sks") at ../../src/acct.cpp:1623 > #9 0x00479d3a in set_acc > (userName=userName@entry=0x7fd6962d3870 "user1", > password=password@entry=0x7fd6962d3c70 "saaadh45sks") at > ../src/borfunc_cou.c:4066 > #10 0x0045217b in _71571_2 (_T=0x42907000) at > ../src/bor7qxqx.sdl:600 > #11 0x0044fd45 in _s71571_ACTIVE (_T=) at > _Sborha7ACTIVE.c:33 > #12 0x7fd6b6ec8a65 in call_transition (msg=0x7fd6bc0d8948, process=96) > at /home/core/threadmain.c:656 > #13 call_transition_with_fatal_sig_catching (thread=, > thread@entry=0x25d7d90, process=process@entry=96, > msg=msg@entry=0x7fd6bc0d8948) at /home/core/threadmain.c:669 > #14 0x7fd6b6ec9499 in execute_user_code (msg=0x7fd6bc0d8948, > process=96, thread=0x25d7d90) > at /home/core/threadmain.c:687 > #15 exec_main_loop (thread=0x25d7d90) at /home/core/threadmain.c:882 > #16 thread_context_main (arg=) at /home/core/threadmain.c:592 > #17 0x7fd6b64f2f50 in ?? () from /lib64/libc.so.6 > #18 0x in ?? () > (gdb) > " > > Regards, > Sanjaya > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users