Re: [openssl-users] Help with ssl error

[Jason Schultz]

>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 

Re: [openssl-users] SSL_shutdown return error when close in init

[Linsell, StevenX]

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

[Michael Tuexen]

> 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

[Viktor Dukhovni]

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 

Re: [openssl-users] Help with ssl error

[Joseph Southwell]

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

[Michael Wojcik]

> 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

[Dmitry Belyavsky]

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

[Dr. Stephen Henson]

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

[R . S via openssl-users]

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()

[Sanjaya Joshi]

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

[Jakob Bohm]

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++)?

[Matthias Ballreich]

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()

[Matt Caswell]

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