Re: Listing TLS 1.3 Ciphers

[Michael Richardson]

Benjamin Kaduk via openssl-users  wrote:
>> Very odd. I thought that there were more at one point.

> The ones with truncated (8-byte) authentication tag are not intended
> for general use and don't make it into the default list.

I think that those are the ones that constrained devices prefer,
such as ECDHE-ECDSA-AES128-CCM8?
So is there a way to validate that they are available, that there were
compiled in?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature

Re: Listing TLS 1.3 Ciphers

[Richard Moore]

On Wed, 10 Apr 2019 at 17:25, Benjamin Kaduk via openssl-users <
openssl-users@openssl.org> wrote:

> On Wed, Apr 10, 2019 at 12:13:27PM -0400, Dennis Clarke wrote:
>
> > Very odd. I thought that there were more at one point.
>
> The ones with truncated (8-byte) authentication tag are not intended for
> general use and don't make it into the default list.
>

They also don't appear if you explicitly try to list 'All' which is what I
found surprising.

Rich



> -Ben
>

stunnel 5.53 released

[Michal Trojnara]

Dear Users,

I have released version 5.53 of stunnel.

Version 5.53, 2019.04.10, urgency: HIGH
* Bugfixes
  - Fixed data transfer stalls introduced in stunnel 5.51.
* New features
  - Android binary updated to support Android 4.x.

Home page: https://www.stunnel.org/
Download: https://www.stunnel.org/downloads.html

SHA-256 hashes:
80439896ee14269eb70bc8bc669433c7d619018a62c9f9c5c760a24515302585 
stunnel-5.53.tar.gz
4f2d24d08f547943b8a499d411425409a52973a349c9120c650ba77d3f29ef79 
stunnel-5.53-win64-installer.exe
e619880f4fc25a7a4869cace9f6e6f3f5940cfdb764ed9987d892d9e9b0ea35d 
stunnel-5.53-android.zip

Best regards,
    Mike



signature.asc
Description: OpenPGP digital signature

Re: Listing TLS 1.3 Ciphers

[Dennis Clarke]

The ones with truncated (8-byte) authentication tag are not intended for
general use and don't make it into the default list.


There must be a Configuration option in 10-main.conf to enable them also?

Dennis

Re: Listing TLS 1.3 Ciphers

[Benjamin Kaduk via openssl-users]

On Wed, Apr 10, 2019 at 12:13:27PM -0400, Dennis Clarke wrote:
> On 4/10/19 7:37 AM, Richard Moore wrote:
> >Hi All,
> >
> >I haven't found a way to list the supported openssl ciphers from the
> >command line (i.e. get the list of potential values for -ciphersuites). I
> >understand that currently there are only 5 options however this could
> >change over time, so I wanted to avoid hard coding the list in a script.
> >Am I missing something?
> >
> >Thanks
> >
> >Rich
> 
> Strangely I only see three :
> 
> nix$ openssl version
> OpenSSL 1.1.1b  26 Feb 2019
> nix$ openssl ciphers -V -tls1_3 -s
>   0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any Au=any
> Enc=AESGCM(256) Mac=AEAD
>   0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
>   0x13,0x01 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any Au=any
> Enc=AESGCM(128) Mac=AEAD
> nix$
> 
> Very odd. I thought that there were more at one point.

The ones with truncated (8-byte) authentication tag are not intended for
general use and don't make it into the default list.

-Ben

Re: Listing TLS 1.3 Ciphers

[Matt Caswell]

On 10/04/2019 17:13, Dennis Clarke wrote:
> On 4/10/19 7:37 AM, Richard Moore wrote:
>> Hi All,
>>
>> I haven't found a way to list the supported openssl ciphers from the command
>> line (i.e. get the list of potential values for -ciphersuites). I understand
>> that currently there are only 5 options however this could change over time,
>> so I wanted to avoid hard coding the list in a script. Am I missing 
>> something?
>>
>> Thanks
>>
>> Rich
> 
> Strangely I only see three :
> 
> nix$ openssl version
> OpenSSL 1.1.1b  26 Feb 2019
> nix$ openssl ciphers -V -tls1_3 -s
>   0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any Au=any 
> Enc=AESGCM(256) Mac=AEAD
>   0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any 
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
>   0x13,0x01 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any Au=any 
> Enc=AESGCM(128) Mac=AEAD
> nix$
> 
> Very odd. I thought that there were more at one point.
> 

There are 5 but only 3 are enabled by default. I'm not sure it is possible to
get "openssl ciphers" to list all of the ones it knows about. You have to
explicitly list them in the "-ciphersuites" option. Probably we should add that
capability.

Matt

Re: Listing TLS 1.3 Ciphers

[Dennis Clarke]

On 4/10/19 7:37 AM, Richard Moore wrote:

Hi All,

I haven't found a way to list the supported openssl ciphers from the 
command line (i.e. get the list of potential values for -ciphersuites). 
I understand that currently there are only 5 options however this could 
change over time, so I wanted to avoid hard coding the list in a script. 
Am I missing something?


Thanks

Rich


Strangely I only see three :

nix$ openssl version
OpenSSL 1.1.1b  26 Feb 2019
nix$ openssl ciphers -V -tls1_3 -s
  0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any 
Au=any  Enc=AESGCM(256) Mac=AEAD
  0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any 
Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
  0x13,0x01 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any 
Au=any  Enc=AESGCM(128) Mac=AEAD

nix$

Very odd. I thought that there were more at one point.

Re: Issue with smartcard authentication for openvpn

[Antonio Iacono]

> padding = 3 means "no padding" indicating that the data for signature is 
> already padded. That's why the data size (flen) is 256 (hashed data padded to 
> the rsa key size of 2048 bits, I guess). If you are using OpenSSL 1.1.1, this 
> could be due to PSS padding in which case current implementation passes 
> pre-padded data for raw signature to the callback. AFAIK, pkcs11-helper only 
> handles PKCS1 padding (CKM_RSA_PKCS) though pkcs11 standard does support raw 
> signatures.

https://github.com/OpenSC/pkcs11-helper/blob/0e2ae10ef9611beef92457171e8c78d8e936dfca/lib/pkcs11h-openssl.c#L570

if (padding != RSA_PKCS1_PADDING) {
rv = CKR_MECHANISM_INVALID;
goto cleanup;
}

Re: Issue with smartcard authentication for openvpn

[Selva Nair]

Hi,

On Wed, Apr 10, 2019 at 10:11 AM Francois Gelis 
wrote:

> Hi all,
>
> I have a working openvpn setup with client certificate and private key
> stored on my laptop. Then, I have loaded them into a smartcard (Yubico 5
> NFC), and modified accordingly the openvpn client config. But running the
> openvpn client now fails with an error that seems to originate inside
> openssl. Here is a verbose openvpn log (only the portion that seems
> relevant for this error, but I have the full log if useful):
>
> Sat Apr  6 15:57:20 2019 us=467260 Incoming Ciphertext -> TLS
> Sat Apr  6 15:57:20 2019 us=467271 SSL state (connect): SSLv3/TLS read
> server hello
> Sat Apr  6 15:57:20 2019 us=467468 VERIFY OK: depth=1, CN=FG-CA
> Sat Apr  6 15:57:20 2019 us=467598 VERIFY KU OK
> Sat Apr  6 15:57:20 2019 us=467609 Validating certificate extended key
> usage
> Sat Apr  6 15:57:20 2019 us=467615 ++ Certificate has EKU (str) TLS Web
> Server Authentication, expects TLS Web Server Authentication
> Sat Apr  6 15:57:20 2019 us=467620 VERIFY EKU OK
> Sat Apr  6 15:57:20 2019 us=467625 VERIFY OK: depth=0, CN=tx2
> Sat Apr  6 15:57:20 2019 us=467650 SSL state (connect): SSLv3/TLS read
> server certificate
> Sat Apr  6 15:57:20 2019 us=467735 SSL state (connect): SSLv3/TLS read
> server key exchange
> Sat Apr  6 15:57:20 2019 us=467763 SSL state (connect): SSLv3/TLS read
> server certificate request
> Sat Apr  6 15:57:20 2019 us=467771 SSL state (connect): SSLv3/TLS read
> server done
> Sat Apr  6 15:57:20 2019 us=467845 SSL state (connect): SSLv3/TLS write
> client certificate
> Sat Apr  6 15:57:20 2019 us=468012 SSL state (connect): SSLv3/TLS write
> client key exchange
> Sat Apr  6 15:57:20 2019 us=468053 PKCS#11: __pkcs11h_openssl_rsa_enc
> entered - flen=256, from=0x559d078d6e70, to=0x559d078d6bc0,
> rsa=0x559d078b3630, padding=3
>

padding = 3 means "no padding" indicating that the data for signature is
already padded. That's why the data size (flen) is 256 (hashed data padded
to the rsa key size of 2048 bits, I guess). If you are using OpenSSL 1.1.1,
this could be due to PSS padding in which case current implementation
passes pre-padded data for raw signature to the callback. AFAIK,
pkcs11-helper only handles PKCS1 padding (CKM_RSA_PKCS) though pkcs11
standard does support raw signatures.

A work around may be to restrict TLS version to 1.1 which is not ideal. Not
sure whether openssl has any config options to restrict signature
algorithms.

Sat Apr  6 15:57:20 2019 us=468060 PKCS#11: __pkcs11h_openssl_rsa_enc -
> return rv=112-'CKR_MECHANISM_INVALID'
>
>
Sat Apr  6 15:57:20 2019 us=468070 SSL alert (write): fatal: internal error
> Sat Apr  6 15:57:20 2019 us=468085 OpenSSL: error:141F0006:SSL
> routines:tls_construct_cert_verify:EVP lib
> Sat Apr  6 15:57:20 2019 us=468092 TLS_ERROR: BIO read tls_read_plaintext
> error
> Sat Apr  6 15:57:20 2019 us=468097 TLS Error: TLS object -> incoming
> plaintext read error
> Sat Apr  6 15:57:20 2019 us=468101 TLS Error: TLS handshake failed
>
> Somehow, it seems that __pkcs11h_openssl_rsa_enc was called with an
> unexpected padding. Any ideas on what might be the cause of this?
>

pkcs11-helper needs to be patched to support raw signatures.

Selva

Issue with smartcard authentication for openvpn

[Francois Gelis]

Hi all,

I have a working openvpn setup with client certificate and private key
stored on my laptop. Then, I have loaded them into a smartcard (Yubico 5
NFC), and modified accordingly the openvpn client config. But running the
openvpn client now fails with an error that seems to originate inside
openssl. Here is a verbose openvpn log (only the portion that seems
relevant for this error, but I have the full log if useful):

Sat Apr  6 15:57:20 2019 us=467260 Incoming Ciphertext -> TLS
Sat Apr  6 15:57:20 2019 us=467271 SSL state (connect): SSLv3/TLS read
server hello
Sat Apr  6 15:57:20 2019 us=467468 VERIFY OK: depth=1, CN=FG-CA
Sat Apr  6 15:57:20 2019 us=467598 VERIFY KU OK
Sat Apr  6 15:57:20 2019 us=467609 Validating certificate extended key usage
Sat Apr  6 15:57:20 2019 us=467615 ++ Certificate has EKU (str) TLS Web
Server Authentication, expects TLS Web Server Authentication
Sat Apr  6 15:57:20 2019 us=467620 VERIFY EKU OK
Sat Apr  6 15:57:20 2019 us=467625 VERIFY OK: depth=0, CN=tx2
Sat Apr  6 15:57:20 2019 us=467650 SSL state (connect): SSLv3/TLS read
server certificate
Sat Apr  6 15:57:20 2019 us=467735 SSL state (connect): SSLv3/TLS read
server key exchange
Sat Apr  6 15:57:20 2019 us=467763 SSL state (connect): SSLv3/TLS read
server certificate request
Sat Apr  6 15:57:20 2019 us=467771 SSL state (connect): SSLv3/TLS read
server done
Sat Apr  6 15:57:20 2019 us=467845 SSL state (connect): SSLv3/TLS write
client certificate
Sat Apr  6 15:57:20 2019 us=468012 SSL state (connect): SSLv3/TLS write
client key exchange
Sat Apr  6 15:57:20 2019 us=468053 PKCS#11: __pkcs11h_openssl_rsa_enc
entered - flen=256, from=0x559d078d6e70, to=0x559d078d6bc0,
rsa=0x559d078b3630, padding=3
Sat Apr  6 15:57:20 2019 us=468060 PKCS#11: __pkcs11h_openssl_rsa_enc -
return rv=112-'CKR_MECHANISM_INVALID'
Sat Apr  6 15:57:20 2019 us=468070 SSL alert (write): fatal: internal error
Sat Apr  6 15:57:20 2019 us=468085 OpenSSL: error:141F0006:SSL
routines:tls_construct_cert_verify:EVP lib
Sat Apr  6 15:57:20 2019 us=468092 TLS_ERROR: BIO read tls_read_plaintext
error
Sat Apr  6 15:57:20 2019 us=468097 TLS Error: TLS object -> incoming
plaintext read error
Sat Apr  6 15:57:20 2019 us=468101 TLS Error: TLS handshake failed

Somehow, it seems that __pkcs11h_openssl_rsa_enc was called with an
unexpected padding. Any ideas on what might be the cause of this?

Best regards,
Francois

Re: C:\Users\xxx\xx\xxx\openssl\e_os.h(13): fatal error C1083: Cannot open include file: 'limits.h': No such file or directory

[Jakob Bohm via openssl-users]

On 10/04/2019 14:28, Kingsley O wrote:

Hello,

I get the above error when trying to build openssl. I am on a x64 
Windows 10 platform, using perl 5, version 26, subversion 3 (v5.26.3) 
built for MSWin32-x64-multi-thread and Visual studio express for 
Windows 10


The file limits is clearly located within the include folder of my 
visual studio installation and I have my environment variable set so 
that i can build openssl outside of the source tree. Unfortunately, I 
am at a loss as to why the build is unable to find this file.
I have tried running vcvars32.bat and vcvarsx86_amd64.bat prior to 
running the configure and build scripts but have not been successful 
on both occasions.


In addition when i run the Configure script, I would normally select 
VC-WIN64A, and I have also tried  running vsvars32.bat prior to 
running the Configure and make scripts


Sometimes I get similar error with the build unable to find a 
different file, in this instance *winsock2.h*

*
*
Can any of you kind folk please help?  I hope you can see my screenshot

Many Thanks in advance

*C:\Users\hello\_DEV\3di\openssl>nmake*
*
*
*Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
*Copyright (C) Microsoft Corporation.  All rights reserved.*
*
*
*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
" "-omakefile" "crypto\include\internal\bn_conf.h.in 
" > crypto\include\internal\bn_conf.h*
*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
" "-omakefile" 
"crypto\include\internal\dso_conf.h.in " > 
crypto\include\internal\dso_conf.h*
*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
" "-omakefile" "doc\man7\openssl_user_macros.pod.in 
" > doc\man7\openssl_user_macros.pod*
*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
" "-omakefile" "include\openssl\opensslconf.h.in 
" > include\openssl\opensslconf.h*
*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
" "-omakefile" "test\provider_internal_test.conf.in 
" > 
test\provider_internal_test.conf*
*        "C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe" /                   depend && "C:\Program Files 
(x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" /                
   _all*

*
*
*Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
*Copyright (C) Microsoft Corporation.  All rights reserved.*
*
*
*
*
*Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
*Copyright (C) Microsoft Corporation.  All rights reserved.*
*
*
*        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 
/nologo /O2 /I "." /I "include" /I "apps\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" 
-D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5" 
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM" 
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" 
-D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" 
-D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program Files\\Common 
Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program 
Files\\OpenSSL\\lib\\engines-3\"" -D"MODULESDIR=\"C:\\Program 
Files\\OpenSSL\\lib\\ossl-modules\"" -D"OPENSSL_SYS_WIN32" 
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" 
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" 
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"   -c 
/Foapps\libapps-lib-app_rand.obj "apps\app_rand.c"*

*app_rand.c*
*C:\Users\hello\_DEV\3di\openssl\e_os.h(129): fatal error C1083: 
Cannot open include file: 'winsock2.h': No such file or directory*
*NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 14.0\VC\BIN\cl.EXE"' : return code '0x2'*

*Stop.*
*NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'*

*Stop.*


Check the value of the "INCLUDE" environment variable.  If it is
not set, try the build again from a "Developer Command Prompt"
(Under "%ProgramData%\Microsoft\Windows\Start Menu\Programs\Visual 
Studio 2015\Visual Studio Tools" )



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

C:\Users\xxx\xx\xxx\openssl\e_os.h(13): fatal error C1083: Cannot open include file: 'limits.h': No such file or directory

[Kingsley O]

Hello,

I get the above error when trying to build openssl. I am on a x64 Windows
10 platform, using perl 5, version 26, subversion 3 (v5.26.3) built for
MSWin32-x64-multi-thread and Visual studio express for Windows 10

The file limits is clearly located within the include folder of my visual
studio installation and I have my environment variable set so that i can
build openssl outside of the source tree. Unfortunately, I am at a loss as
to why the build is unable to find this file.
I have tried running vcvars32.bat and vcvarsx86_amd64.bat prior to running
the configure and build scripts but have not been successful on both
occasions.

In addition when i run the Configure script, I would normally select
VC-WIN64A, and I have also tried  running vsvars32.bat prior to running the
Configure and make scripts

Sometimes I get similar error with the build unable to find a different
file, in this instance *winsock2.h*

Can any of you kind folk please help?  I hope you can see my screenshot

Many Thanks in advance

*C:\Users\hello\_DEV\3di\openssl>nmake*

*Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
*Copyright (C) Microsoft Corporation.  All rights reserved.*

*"C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
"  "-omakefile" "crypto\include\internal\bn_conf.h.in
" > crypto\include\internal\bn_conf.h*
*"C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
"  "-omakefile" "crypto\include\internal\dso_conf.h.in
" > crypto\include\internal\dso_conf.h*
*"C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
"  "-omakefile" "doc\man7\openssl_user_macros.pod.in
" > doc\man7\openssl_user_macros.pod*
*"C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
"  "-omakefile" "include\openssl\opensslconf.h.in
" > include\openssl\opensslconf.h*
*"C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
"  "-omakefile" "test\provider_internal_test.conf.in
" > test\provider_internal_test.conf*
*"C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\BIN\nmake.exe" /   depend && "C:\Program Files
(x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" /
 _all*

*Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
*Copyright (C) Microsoft Corporation.  All rights reserved.*


*Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
*Copyright (C) Microsoft Corporation.  All rights reserved.*

*cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
/O2 /I "." /I "include" /I "apps\include" -D"L_ENDIAN" -D"OPENSSL_PIC"
-D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT"
-D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM"
-D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM"
-D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM"
-D"X25519_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program Files\\Common
Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\""
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\""
-D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"   -c /Foapps\libapps-lib-app_rand.obj
"apps\app_rand.c"*
*app_rand.c*
*C:\Users\hello\_DEV\3di\openssl\e_os.h(129): fatal error C1083: Cannot
open include file: 'winsock2.h': No such file or directory*
*NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 14.0\VC\BIN\cl.EXE"' : return code '0x2'*
*Stop.*
*NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'*
*Stop.*

Listing TLS 1.3 Ciphers

[Richard Moore]

Hi All,

I haven't found a way to list the supported openssl ciphers from the
command line (i.e. get the list of potential values for -ciphersuites). I
understand that currently there are only 5 options however this could
change over time, so I wanted to avoid hard coding the list in a script. Am
I missing something?

Thanks

Rich

Troubles using Openssl ENGINE

[Gael GUEGAN]

Hello all,

I am currently having some trouble using an openssl engine with nginx.

I was having no problems using it for loading private key through my engine.
However after adding new capabilities about symmetric encryption (AES) to the 
engine, nginx is trying to use my engine instead of the default openssl 
implementation at some point.

And so the handshake is failing, trying to use the symmetric encryption of my 
engine that I don't want him to use, here a debug log :

2019/04/09 09:34:37 [debug] 9414#0: epoll timer: 59601
2019/04/09 09:34:37 [debug] 9414#0: epoll: fd:3 ev:0001 d:B6973109
2019/04/09 09:34:37 [debug] 9414#0: *3 SSL handshake handler: 0
Init Cipher Key ... (Debug Log from the engine code)
Cleaning up ... (Debug Log from the engine code)
2019/04/09 09:34:37 [debug] 9414#0: *3 SSL_do_handshake: -1
2019/04/09 09:34:37 [debug] 9414#0: *3 SSL_get_error: 1
2019/04/09 09:34:37 [crit] 9414#0: *3 SSL_do_handshake() failed (SSL: 
error:8009D064:tpm2-tss-engine:tpm2_cipher_init_key:Failed to read TPM2 data) 
while SSL handshaking, client: 192.168.13
2019/04/09 09:34:37 [debug] 9414#0: *3 close http connection: 3
2019/04/09 09:34:37 [debug] 9414#0: *3 event timer del: 3: 24375741
2019/04/09 09:34:37 [debug] 9414#0: *3 reusable connection: 0

My idea was to disable the symmetric functionality of the engine. And I have 
attempted to modify the file ngx_event_openssl.c by calling the function 
ENGINE_unregister_ciphers(...) or ENGINE_set_default(engine, 
ENGINE_METHOD_PKEY_METHS) or configuring the openssl.cnf with only RSA algo.
I have succeeded to do it in a small c code of mine, but in nginx it is like 
some function are resetting my configuration like SSL_CTX_new().

Is someone has an idea on how to resolve my problems ? I would highly 
appreciate some help.

Other information :
~$ sudo /usr/sbin/nginx -V
nginx version: nginx/1.12.1
built with OpenSSL 1.1.0h  27 Mar 2018
TLS SNI support enabled
configure arguments: --crossbuild=Linux:arm --with-endian=big --with-int=4 
--with-long=4 --with-long-long=8 --with-ptr-size=4 --with-sig-atomic-t=4 
--with-size-t=4 --with-off-t=4 --with-time-t=4 --with-sg

Here a link to the engine : https://github.com/tpm2-software/tpm2-tss-engine




Gael GUEGAN

Re: SSL_SESSION_set1_ticket ?

[Jeremy Harris]

On 10/04/2019 11:15, Hubert Kario wrote:
> On Wednesday, 10 April 2019 12:05:21 CEST Jeremy Harris wrote:
>> On 10/04/2019 01:25, Viktor Dukhovni wrote:
>>> With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object
>>> associated with the connection object at the completion of each
>>> handshake, will contain any fresh tickets issued by the server.
>>
>> That does not match my observation.
> 
> that assumes that the server sends tickets in the first place... but the 
> point 
> stands, the TLS 1.2 server cannot provide a session ticket to the client 
> after 
> the handshake finished (client received server's Finished message), same for 
> even older protocols

I'm not saying the new ticket arrived after the handshake.  I can
see the notification of it arriving during the handshake.  Yet
the session dumped via i2d... after the handshake is bitwise identical
to that given to d2i... , SSL_set_session before the handshake.
-- 
Cheers,
  Jeremy

Re: SSL_SESSION_set1_ticket ?

[Hubert Kario]

On Wednesday, 10 April 2019 12:05:21 CEST Jeremy Harris wrote:
> On 10/04/2019 01:25, Viktor Dukhovni wrote:
> > With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object
> > associated with the connection object at the completion of each
> > handshake, will contain any fresh tickets issued by the server.
> 
> That does not match my observation.

that assumes that the server sends tickets in the first place... but the point 
stands, the TLS 1.2 server cannot provide a session ticket to the client after 
the handshake finished (client received server's Finished message), same for 
even older protocols

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.

Re: SSL write/read performance

[Matt Caswell]

On 10/04/2019 11:03, valmiki wrote:
> 
>>> Hi All,
>>>
>>> I'm trying to understand server and client code over tcp using openssl.
>>>
>>> How does the flow work when we do SSL_write or SSL_read.
>>>
>>> SSL_write -> send buffer to kernel crypto subsystem -> take encrypted 
>>> buffer and send it over network socket.
>>>
>>> Is the above understanding correct ?
>> No, this isn't correct. All crypto is done in user space* using libcrypto.
>>
>> Matt
>>
>> * Actually there is a new option in master where the kernel does the TLS
>> encryption/decryption - but it is not on by default, and if used the kernel 
>> does
>> the IO too.
>>
>> Thanks Matt.
>> So only one context switch happens, which is sending buffer to networking 
>> socket ?

Correct.

Matt

Re: SSL_SESSION_set1_ticket ?

[Jeremy Harris]

On 10/04/2019 01:25, Viktor Dukhovni wrote:
> With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object
> associated with the connection object at the completion of each
> handshake, will contain any fresh tickets issued by the server.

That does not match my observation.
-- 
Cheers,
  Jeremy

Re: SSL write/read performance

[valmiki]

>> Hi All,
>>
>> I'm trying to understand server and client code over tcp using openssl.
>>
>> How does the flow work when we do SSL_write or SSL_read.
>>
>> SSL_write -> send buffer to kernel crypto subsystem -> take encrypted buffer 
>> and send it over network socket.
>>
>> Is the above understanding correct ?
> No, this isn't correct. All crypto is done in user space* using libcrypto.
>
> Matt
>
> * Actually there is a new option in master where the kernel does the TLS
> encryption/decryption - but it is not on by default, and if used the kernel 
> does
> the IO too.
>
> Thanks Matt.
> So only one context switch happens, which is sending buffer to networking 
> socket ?
>
> Regards,
> valimki
>> If its correct we have following context switch from user to kernel space 
>> and vice versa
>>
>> -> open ssl libary to kernel crypto subsystem
>>
>> -> kernel crypto subsystem to ssl library
>>
>> -> ssl library to network subsystem
>>
>> Does this mean for sending a buffer we need to three context switches from 
>> user to kernel and vice versa ?
>>
>> Doesn't this effect performance ?
>>
>> Please correct me if my understanding is wrong.
>>
>> Regards,
>> valmiki
>>
>>
>>
>>
>>
>>

Re: SSL write/read performance

[Matt Caswell]

On 10/04/2019 10:32, valmiki wrote:
> Hi All,
> 
> I'm trying to understand server and client code over tcp using openssl.
> 
> How does the flow work when we do SSL_write or SSL_read.
> 
> SSL_write -> send buffer to kernel crypto subsystem -> take encrypted buffer 
> and send it over network socket.
> 
> Is the above understanding correct ?

No, this isn't correct. All crypto is done in user space* using libcrypto.

Matt

* Actually there is a new option in master where the kernel does the TLS
encryption/decryption - but it is not on by default, and if used the kernel does
the IO too.


> 
> If its correct we have following context switch from user to kernel space and 
> vice versa
> 
> -> open ssl libary to kernel crypto subsystem
> 
> -> kernel crypto subsystem to ssl library
> 
> -> ssl library to network subsystem
> 
> Does this mean for sending a buffer we need to three context switches from 
> user to kernel and vice versa ?
> 
> Doesn't this effect performance ?
> 
> Please correct me if my understanding is wrong.
> 
> Regards,
> valmiki
> 
> 
> 
> 
> 
> 

SSL write/read performance

[valmiki]

Hi All,

I'm trying to understand server and client code over tcp using openssl.

How does the flow work when we do SSL_write or SSL_read.

SSL_write -> send buffer to kernel crypto subsystem -> take encrypted buffer 
and send it over network socket.

Is the above understanding correct ?

If its correct we have following context switch from user to kernel space and 
vice versa

-> open ssl libary to kernel crypto subsystem

-> kernel crypto subsystem to ssl library

-> ssl library to network subsystem

Does this mean for sending a buffer we need to three context switches from user 
to kernel and vice versa ?

Doesn't this effect performance ?

Please correct me if my understanding is wrong.

Regards,
valmiki