Re: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX?

[Dr. Stephen Henson]

On Fri, Feb 17, 2017, Stephan M?hlstrasser wrote:

> Hi,
> 
> we use OpenSSL 1.0.2 together with PKCS#11 tokens by plugging
> methods into the RSA_METHOD structure that interface with the
> PKCS#11 token, and this works fine so far. However, for creating RSA
> signatures with PSS padding this strategy doesn't work anymore,
> because OpenSSL wants to directly encrypt with the private key in
> this case, which is not possible in PKCS#11.
> 
> Therefore my idea is to override the function pkey_rsa_sign() and
> plug a wrapper around it into the EVP_PKEY_METHOD structure that is
> associated with the EVP_PKEY_CTX to handle this special situation.
> 
> The header evp.h declares the following functions among others:
> 
> EVP_PKEY_METHOD* EVP_PKEY_meth_new(int id, int flags);
> void EVP_PKEY_meth_copy(EVP_PKEY_METHOD *dst, const EVP_PKEY_METHOD *src);
> 
> void EVP_PKEY_meth_set_sign(EVP_PKEY_METHOD *pmeth,
>   int (*sign_init)(EVP_PKEY_CTX *ctx),
>   int (*sign)(EVP_PKEY_CTX *ctx, unsigned char *sig,
> size_t *siglen, const unsigned char *tbs, size_t tbslen));
> 
> But I can't figure out how to use these functions to achieve what I
> want, because the following pieces seem to be missing:
> 
> - Retrieve the EVP_PKEY_METHOD pointer from a EVP_PKEY_CTX pointer
> - Set the EVP_PKEY_METHOD pointer for a EVP_PKEY_CTX pointer
> - Retrieve the existing "sign_init" and "sign" function pointers
> from an initialized EVP_PKEY_METHOD pointer for being able to wrap
> them
> 
> Is it possible to override methods in an EVP_PKEY_METHOD structure,
> or would it be necessary to implement a whole OpenSSL engine to do
> what I want?
> 

It should be possible yes, though AFAIK no one has yet tried to do this so
there may be some pieces missing.

In outline you'd retrieve the appropriate EVP_PKEY_METHOD for the algorithm of
interest, make a copy of it and then set the operation you wish to override,
you can also retrieve the original operation in case you sometimes wish to
call that.

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

Re: [openssl-users] RSA_method_set_sign

[Dr. Stephen Henson]

On Sat, Jan 14, 2017, Melvyn Sopacua wrote:

> Hello all,
> 
> Some background: I'd like to have a workstation that uses OpenSSL 1.1 
> instead of a lower version. For that I'm porting various pieces of 
> software and quickly discovered that I was repeating myself. In addition 
> this teaches me more about the OpenSSL library, which I consider a great 
> benefit.
> This resulted in me working on a forwards-compatibility library, using 
> the OpenSSL Wiki as a guide and the KDE QCA library as a testbed. Work 
> in progress can be seen at [1] and [2].
> 
> However, I believe I've now hit a brick wall:
> Various functions in the realm RSA_method_set_* allow us to set 
> callbacks for RSA operations. However, I see no way to implement these, 
> since various (all?) X509 structures are now opaque. In addition, the 
> default RSA_sign implementation calls the rsa_sign callback in the 
> provided RSA structure, so we'll create an infinite loop if we wrap it 
> like this:
> 
> RSA_method_set_sign(meth, my_rsa_sign);
> int my_rsa_sign(...) {
>   RSA_sign(...);
>   store_state_on_our_object();
> }
> 
> This is caused by the code in [3].
> That file also shows the problem: OpenSSL itself has access to X509_SIG 
> (and friends) internals as demonstrated in encode_pkcs1(). But, I don't 
> see any way to setup the same context(s) from outside OpenSSL. There's 
> no X509_*_set_ to setup the algorithm and parameters.
> 
> Am I missing something or is it simply no longer possible to implement 
> these callbacks properly?
> 

Can you give a pointer to the part that is causing problems?

The rsa_sign interface is used where the only interface available is passed
the digest algorithm and the raw digest and it performs its own formatting
using DigestInfo etc.

If you don't want to do that then the rsa_priv_enc method is more appropriate:
it gets passed the block to encrypt (sign) and all the DigestInfo formatting
is handled by OpenSSL itself.

If you really need to it should be possible to set up or examine an X509_SIG
structure using the available APIs. For example to retieve its fields you use
X509_SIG_get0 and to set them X509_SIG_getm.

The contained X509_ALGOR can be set up using X509_ALGOR_set0 and examined with
X509_ALGOR_get0.

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

Re: [openssl-users] Using RSASSA-PSS in command line smime / cms utility

[Dr. Stephen Henson]

On Mon, Feb 13, 2017, Harakiri via openssl-users wrote:

> Can i set the padding RSASSA-PSS or alg ECDSA via command line when using 
> openssl smime or openssl cms command?
> I can't find an option for it.

You have to use the cms command and -keyopt rsa_padding_mode:pss check out the
documentation of pkeutil for other PSS options such as setting the salt
length.

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

Re: [openssl-users] Specify padding scheme with EVP_VerifyFinal

[Dr. Stephen Henson]

On Thu, Feb 23, 2017, open...@tuta.io wrote:

> Hi Michel,
> 
> it looks like what I am looking for, but the software uses EVP_VerifyInit_ex 
> which is a typedef for EVP_DigestInit_ex. How are those functions related to 
> EVP_DigestVerifyInit? Can I use EVP_DigestVerify* functions along with 
> EVP_Verify* functions? I must not break compatibility with the old 
> implementation which needs to support arbitrary MD algorithms.
> 

You have to use the EVP_Digest* functions if you want to change the RSA
padding mode (or other parameters). This is not supported in the older
EVP_Verify* API.

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

Re: [openssl-users] Help with "tlsv1 alert insufficient security"

[Matt Caswell]

On 24/02/17 16:15, Joseph Southwell wrote:
> We upgraded from 0.9.8 to 1.0.2 and now we are seeing that message when
> we try connecting to a server that previously worked. What does it mean
> and how can I figure out how to work around it? I can’t get the server
> to change anything and I need to be able to continue connecting to it. 
> 
> openssl s_client -connect xxx.com :
> -starttls ftp
> 
> CONNECTED(0170)
> 4960:error:1407742F:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
> insufficient security:.\ssl\s23_clnt.c:770:



That is actually quite strange. This is the server sending the OpenSSL
client an alert to say that you have insufficient security in your
ClientHello. Without access to the server it is quite difficult to tell
why. What is strange is the default security has been increased
significantly between 0.9.8 and 1.0.2. Possibly some ciphers/parameters
that were previously offered are no longer offered by default in 1.0.2 -
and therefore the server can't find one it likes.

Rich's suggestion is a good one, but unfortunately only applies to
version 1.1.0 - it won't work in 1.0.2. You might want to try compiling
with the "enable-weak-ssl-ciphers" config option to see if that makes a
difference.

Alternatively, try and find out what connection params are used when
connecting from 0.9.8. That might give you a clue as to what settings
are acceptable to the server.

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Help with "tlsv1 alert insufficient security"

[Salz, Rich]

Later versions ratched up the security.  Try -ciphers DEFAULT@SECLEVEL=0

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Help with "tlsv1 alert insufficient security"

[Joseph Southwell]

We upgraded from 0.9.8 to 1.0.2 and now we are seeing that message when we try 
connecting to a server that previously worked. What does it mean and how can I 
figure out how to work around it? I can’t get the server to change anything and 
I need to be able to continue connecting to it. 

openssl s_client -connect xxx.com : -starttls ftp

CONNECTED(0170)
4960:error:1407742F:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert 
insufficient security:.\ssl\s23_clnt.c:770:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 88 bytes and written 317 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.1
Cipher: 
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1487578706
Timeout   : 300 (sec)
Verify return code: 0 (ok)


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DTLS for SCTP connections

[Michael Tuexen]

> On 24 Feb 2017, at 10:31, mahesh gs  wrote:
> 
> Hi,
> 
> I did some more search regarding this problem and found that its a defect in 
> kernel SCTP. OS was built with linux kernel version 2.6 which is quite old.
> 
> Defect Link : https://sourceforge.net/p/lksctp/mailman/message/27729264/
> 
> I upgraded to RHEL 7.1 and the problem resolved.
> 
Great. Thanks for letting us know.

Best regards
Michael
> Thanks for your support.
> 
> On Thu, Feb 23, 2017 at 10:43 AM, mahesh gs  wrote:
> Hi Michael,
> 
> I am using "Red Hat Enterprise Linux Server release 6.4 (Santiago)" and 
> openssl version is 1.1.0.
> 
> SCTP version :
> 
> [root@localhost DIAMETER]# rpm -qa | grep -i "sctp"
> lksctp-tools-1.0.10-5.el6.x86_64
> [root@localhost DIAMETER]# rpm -qi lksctp-tools-1.0.10-5.el6.x86_64
> Name: lksctp-tools Relocations: (not relocatable)
> Version : 1.0.10Vendor: Red Hat, Inc.
> Release : 5.el6 Build Date: Mon 22 Feb 2010 
> 12:24:33 PM CET
> Install Date: Wed 08 Feb 2017 10:08:12 AM CET  Build Host: 
> hs20-bc1-2.build.redhat.com
> Group   : System Environment/Libraries   Source RPM: 
> lksctp-tools-1.0.10-5.el6.src.rpm
> Size: 203688   License: GPLv2 and GPLv2+ and 
> LGPLv2 and BSD
> Signature   : RSA/8, Mon 16 Aug 2010 08:17:01 PM CEST, Key ID 199e2f91fd431d51
> Packager: Red Hat, Inc. 
> URL : http://lksctp.sourceforge.net
> Summary : User-space access to Linux Kernel SCTP
> Description :
> This is the lksctp-tools package for Linux Kernel SCTP (Stream Control
> Transmission Protocol) Reference Implementation.
> 
> 
> 
> Thanks,
> Mahesh G S
> 
> On Wed, Feb 22, 2017 at 8:33 PM, Michael Tuexen 
>  wrote:
> > On 22 Feb 2017, at 07:47, mahesh gs  wrote:
> >
> > Hi,
> >
> > Thank you for sharing the sample code.
> >
> > I tried running SCTP DTLS Echo server and client. I am facing strange 
> > problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs 
> > on the server side.
> >
> > Client side back trace
> >
> > (gdb) bt
> > #0  0x003db4c0ea10 in __recvmsg_nocancel () from /lib64/libpthread.so.0
> > #1  0x77a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073 
> > "\026\376\377", outl=17741) at bss_dgram.c:1178
> > #2  0x77a597a9 in BIO_read (b=0x6223f0, out=0x629073, outl=17741) 
> > at bio_lib.c:210
> > #3  0x77db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741, 
> > extend=) at s3_pkt.c:258
> > #4  0x77dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676
> > #5  0x77dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22, 
> > buf=0x7ffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938
> > #6  0x77dcdda5 in dtls1_get_message_fragment (s=0x622c70, 
> > st1=, stn=4449, max=30, ok=0x7ffee09c)
> > at d1_both.c:908
> > #7  0x77dce414 in dtls1_get_message (s=0x622c70, st1=4448, 
> > stn=4449, mt=14, max=30, ok=0x7ffee09c) at d1_both.c:512
> > #8  0x77dacaf9 in ssl3_get_server_done (s=0x622c70) at 
> > s3_clnt.c:2458
> > #9  0x77dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466
> > #10 0x00402f75 in start_client(char*, char*, int, int, int) ()
> > #11 0x00403573 in main ()
> >
> >
> > Server side back trace
> >
> > (gdb) info threads
> >   2 Thread 0x7793c700 (LWP 20161)  0x003db4c0ea2d in recvmsg () 
> > from /lib64/libpthread.so.0
> > * 1 Thread 0x7793e720 (LWP 20155)  0x003db4c0e84d in accept () from 
> > /lib64/libpthread.so.0
> > (gdb) t 2
> > [Switching to thread 2 (Thread 0x7793c700 (LWP 20161))]#0  
> > 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
> > (gdb) bt
> > #0  0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
> > #1  0x77a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x70001930) at 
> > bss_dgram.c:1803
> > #2  0x77dc7830 in dtls1_accept (s=0x78c0) at d1_srvr.c:403
> > #3  0x004021ee in connection_handle(void*) ()
> > #4  0x003db4c07851 in start_thread () from /lib64/libpthread.so.0
> > #5  0x003db48e890d in clone () from /lib64/libc.so.6
> > (gdb)
> >
> >
> > I am also attaching the wireshark trace (port 4443) and a server key for 
> > decoding wireshark.
> >
> > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443
> >
> > Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443 -l 
> > 50 -n 5 16.181.38.161
> >
> > Thanks in advance for your valuable input
> I've CCed Irene, who did some testing recently on FreeBSD, where the 
> implementation works.
> The server is waiting for a sender dry event which it should get.
> 
> Which version of OpenSSL are you using and which OS are you using?
> 
> Best regards
> Michael
> >
> > Regards,
> > Mahesh G S
> >
> >
> >
> > On Tue, Feb 21, 2017 at 2:28 

Re: [openssl-users] DTLS for SCTP connections

[mahesh gs]

Hi,

I did some more search regarding this problem and found that its a defect
in kernel SCTP. OS was built with linux kernel version 2.6 which is quite
old.

Defect Link : https://sourceforge.net/p/lksctp/mailman/message/27729264/

I upgraded to RHEL 7.1 and the problem resolved.

Thanks for your support.

On Thu, Feb 23, 2017 at 10:43 AM, mahesh gs  wrote:

> Hi Michael,
>
> I am using "Red Hat Enterprise Linux Server release 6.4 (Santiago)" and
> openssl version is 1.1.0.
>
> SCTP version :
>
> [root@localhost DIAMETER]# rpm -qa | grep -i "sctp"
> *lksctp-tools-1.0.10-5.el6.x86_64*
> [root@localhost DIAMETER]# rpm -qi lksctp-tools-1.0.10-5.el6.x86_64
> Name: lksctp-tools Relocations: (not relocatable)
> Version : 1.0.10Vendor: Red Hat, Inc.
> Release : 5.el6 *Build Date: Mon 22 Feb 2010
> 12:24:33 PM CET*
> Install Date: Wed 08 Feb 2017 10:08:12 AM CET  Build Host:
> hs20-bc1-2.build.redhat.com
> Group   : System Environment/Libraries   Source RPM:
> lksctp-tools-1.0.10-5.el6.src.rpm
> Size: 203688   License: GPLv2 and GPLv2+
> and LGPLv2 and BSD
> Signature   : RSA/8, Mon 16 Aug 2010 08:17:01 PM CEST, Key ID
> 199e2f91fd431d51
> Packager: Red Hat, Inc. 
> URL : http://lksctp.sourceforge.net
> Summary : User-space access to Linux Kernel SCTP
> Description :
> This is the lksctp-tools package for Linux Kernel SCTP (Stream Control
> Transmission Protocol) Reference Implementation.
>
>
>
> Thanks,
> Mahesh G S
>
> On Wed, Feb 22, 2017 at 8:33 PM, Michael Tuexen  franken.de> wrote:
>
>> > On 22 Feb 2017, at 07:47, mahesh gs  wrote:
>> >
>> > Hi,
>> >
>> > Thank you for sharing the sample code.
>> >
>> > I tried running SCTP DTLS Echo server and client. I am facing strange
>> problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs
>> on the server side.
>> >
>> > Client side back trace
>> >
>> > (gdb) bt
>> > #0  0x003db4c0ea10 in __recvmsg_nocancel () from
>> /lib64/libpthread.so.0
>> > #1  0x77a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073
>> "\026\376\377", outl=17741) at bss_dgram.c:1178
>> > #2  0x77a597a9 in BIO_read (b=0x6223f0, out=0x629073,
>> outl=17741) at bio_lib.c:210
>> > #3  0x77db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741,
>> extend=) at s3_pkt.c:258
>> > #4  0x77dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676
>> > #5  0x77dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22,
>> buf=0x7ffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938
>> > #6  0x77dcdda5 in dtls1_get_message_fragment (s=0x622c70,
>> st1=, stn=4449, max=30, ok=0x7ffee09c)
>> > at d1_both.c:908
>> > #7  0x77dce414 in dtls1_get_message (s=0x622c70, st1=4448,
>> stn=4449, mt=14, max=30, ok=0x7ffee09c) at d1_both.c:512
>> > #8  0x77dacaf9 in ssl3_get_server_done (s=0x622c70) at
>> s3_clnt.c:2458
>> > #9  0x77dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466
>> > #10 0x00402f75 in start_client(char*, char*, int, int, int) ()
>> > #11 0x00403573 in main ()
>> >
>> >
>> > Server side back trace
>> >
>> > (gdb) info threads
>> >   2 Thread 0x7793c700 (LWP 20161)  0x003db4c0ea2d in recvmsg ()
>> from /lib64/libpthread.so.0
>> > * 1 Thread 0x7793e720 (LWP 20155)  0x003db4c0e84d in accept ()
>> from /lib64/libpthread.so.0
>> > (gdb) t 2
>> > [Switching to thread 2 (Thread 0x7793c700 (LWP 20161))]#0
>> 0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
>> > (gdb) bt
>> > #0  0x003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0
>> > #1  0x77a633a6 in BIO_dgram_sctp_wait_for_dry
>> (b=0x70001930) at bss_dgram.c:1803
>> > #2  0x77dc7830 in dtls1_accept (s=0x78c0) at
>> d1_srvr.c:403
>> > #3  0x004021ee in connection_handle(void*) ()
>> > #4  0x003db4c07851 in start_thread () from /lib64/libpthread.so.0
>> > #5  0x003db48e890d in clone () from /lib64/libc.so.6
>> > (gdb)
>> >
>> >
>> > I am also attaching the wireshark trace (port 4443) and a server key
>> for decoding wireshark.
>> >
>> > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443
>> >
>> > Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443
>> -l 50 -n 5 16.181.38.161
>> >
>> > Thanks in advance for your valuable input
>> I've CCed Irene, who did some testing recently on FreeBSD, where the
>> implementation works.
>> The server is waiting for a sender dry event which it should get.
>>
>> Which version of OpenSSL are you using and which OS are you using?
>>
>> Best regards
>> Michael
>> >
>> > Regards,
>> > Mahesh G S
>> >
>> >
>> >
>> > On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen <
>> michael.tue...@lurchi.franken.de> wrote:
>> > > On 21 Feb 2017, at 09:53, mahesh gs