I was hoping to tolerate some error "for now" and flag it and continue the whole process (complete the handshake and treat the ssl connection as "pass").
So for my case long res = SSL_get_verify_result( sslCtx ) from caller should return X509_V_OK.
I guess I need to explicitly set X509_STORE_CTX_set_error(ctx, X509_V_OK) before return 1 in the example if I need caller SSL_get_verify_result to return
X509_V_OK?
On Mon, Mar 14, 2022 at 12:38 PM <openssl-users-request@xxxxxxxxxxx> wrote:
[ External sender. Exercise caution. ]
Send openssl-users mailing list submissions to
openssl-users@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-request@xxxxxxxxxxx
You can reach the person managing the list at
openssl-users-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."
Today's Topics:
1. Re: DSA signatures in OpenSSL 3.0 (Richard Dymond)
2. Re: DSA signatures in OpenSSL 3.0 (Tomas Mraz)
3. Re: DSA signatures in OpenSSL 3.0 (Richard Dymond)
4. Question about examples in openssl doc
X509_STORE_CTX_verify_cb (Edward Tsang)
5. Re: Question about examples in openssl doc
X509_STORE_CTX_verify_cb (Viktor Dukhovni)
----------------------------------------------------------------------
Message: 1
Date: Mon, 14 Mar 2022 09:02:18 -0300
From: Richard Dymond <rjdymond@xxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: DSA signatures in OpenSSL 3.0
Message-ID:
<CANVKdYAFQkS8wXADdpD334V=JHp_Bamvm8s=pX2tYRLNygppTg@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
On Mon, 14 Mar 2022 at 04:52, Tomas Mraz <tomas@xxxxxxxxxxx> wrote:
> The DSA_SIG_* functions are not deprecated including the i2d and d2i
> functions. So you can use d2i_DSA_SIG to decode the DER produced by the
> EVP_DigestSign() and then obtain the r and s values from the DSA_SIG.
>
Thank you, that works! For some reason it had escaped my notice that the
DSA_SIG_* functions are not deprecated.
By the way, the reason I need to get the 'r' and 's' values from the DSA
signature is that I am encoding them one after the other as 160-bit
unsigned integers, in network byte order, as required by SSH and described
in section 6.6 of RFC 4253 (dss_signature_blob)[1]. To do this encoding I
am calling BN_bn2bin() twice to write 'r' followed by 's' at the
appropriate locations in a 40-byte buffer. By any chance, does OpenSSL 3.0
provide any support for encoding a DSA signature like this from a DSA_SIG
(i.e. without having to extract 'r' and 's' first and then use BN_bn2bin())?
Richard
[1] https://datatracker.ietf.org/doc/html/rfc4253#section-6.6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220314/a058a561/attachment-0001.htm>
------------------------------
Message: 2
Date: Mon, 14 Mar 2022 15:03:01 +0100
From: Tomas Mraz <tomas@xxxxxxxxxxx>
To: Richard Dymond <rjdymond@xxxxxxxxx>
Cc: openssl-users <openssl-users@xxxxxxxxxxx>
Subject: Re: DSA signatures in OpenSSL 3.0
Message-ID:
<40bda5bc7e776522c25d94037a7b0808c140e774.camel@xxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2022-03-14 at 08:58 -0300, Richard Dymond wrote:
> On Mon, 14 Mar 2022 at 04:52, Tomas Mraz <tomas@xxxxxxxxxxx> wrote:
> > The DSA_SIG_* functions are not deprecated including the i2d and
> > d2i
> > functions. So you can use d2i_DSA_SIG to decode the DER produced by
> > the
> > EVP_DigestSign() and then obtain the r and s values from the
> > DSA_SIG.
> >
>
>
> Thank you, that works! For some reason it had escaped my notice that
> that the DSA_SIG_* functions are not deprecated.
>
> By the way, the reason I need to get the 'r' and 's' values from the
> DSA signature is that I am encoding them one after the other as 160-
> bit unsigned integers, in network byte order, as required by SSH and
> described in section 6.6 of RFC 4253 (dss_signature_blob)[1]. To do
> this encoding I am calling BN_bn2bin() twice to write 'r' followed by
> 's' at the appropriate locations in a 40-byte buffer. By any chance,
> does OpenSSL 3.0 provide any support for encoding a DSA signature
> like this from a DSA_SIG (i.e. without having to extract 'r' and 's'
> first and then use BN_bn2bin())?
No, there is no such function. However there is not much overhead in
doing the two BN_bn2bin calls (should those be BN_bn2binpad actually?)
once you already have a DSA_SIG object.
> Richard
>
> [1] https://datatracker.ietf.org/doc/html/rfc4253#section-6.6
--
Tom?? Mr?z, OpenSSL
------------------------------
Message: 3
Date: Mon, 14 Mar 2022 13:09:01 -0300
From: Richard Dymond <rjdymond@xxxxxxxxx>
To: Tomas Mraz <tomas@xxxxxxxxxxx>
Cc: openssl-users <openssl-users@xxxxxxxxxxx>
Subject: Re: DSA signatures in OpenSSL 3.0
Message-ID:
<CANVKdYAh2uH1n-UNwMNvb18hDwD8U2DhjjQj_PpvU7XJezRKzw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
On Mon, 14 Mar 2022 at 11:03, Tomas Mraz <tomas@xxxxxxxxxxx> wrote:
> On Mon, 2022-03-14 at 08:58 -0300, Richard Dymond wrote:
> > By the way, the reason I need to get the 'r' and 's' values from the
> > DSA signature is that I am encoding them one after the other as 160-
> > bit unsigned integers, in network byte order, as required by SSH and
> > described in section 6.6 of RFC 4253 (dss_signature_blob)[1]. To do
> > this encoding I am calling BN_bn2bin() twice to write 'r' followed by
> > 's' at the appropriate locations in a 40-byte buffer. By any chance,
> > does OpenSSL 3.0 provide any support for encoding a DSA signature
> > like this from a DSA_SIG (i.e. without having to extract 'r' and 's'
> > first and then use BN_bn2bin())?
>
> No, there is no such function. However there is not much overhead in
> doing the two BN_bn2bin calls (should those be BN_bn2binpad actually?)
> once you already have a DSA_SIG object.
>
OK, I suppose that was hoping for too much. But thanks for the tip
regarding BN_bn2binpad v. BN_bn2bin - that does simplify the code a little
more.
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220314/fa41e42b/attachment-0001.htm>
------------------------------
Message: 4
Date: Mon, 14 Mar 2022 11:25:51 -0700
From: Edward Tsang <etsang@xxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Question about examples in openssl doc
X509_STORE_CTX_verify_cb
Message-ID:
<CACrfNRHerj3=hgX4Ls7DLRcAhvSd2iHrEhx5O2CqcLfkkCD-yw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
link:
https://www.openssl.org/docs/man1.1.1/man3/X509_STORE_CTX_verify_cb.html
I am trying to figure out how this example works but it does not seem to
bypass the (use the second example of X509_V_ERR_CERT_HAS_EXPIRED)
However the caller code ll
long res = SSL_get_verify_result( sslCtx ); still reports res NOT as
X509_V_OK, which it should be oper the example since it is returning as 1.
I don't think I need to use X509_STORE_CTX_set_error(ctx, X509_V_OK);
before return 1 in the X509_STORE_CTX_verify_cb example.
Or am I missing something?
Thanjs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220314/6da2e2e4/attachment-0001.htm>
------------------------------
Message: 5
Date: Mon, 14 Mar 2022 15:27:59 -0400
From: Viktor Dukhovni <openssl-users@xxxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: Question about examples in openssl doc
X509_STORE_CTX_verify_cb
Message-ID: <Yi+XP0ey1xVWM5kU@xxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
On Mon, Mar 14, 2022 at 11:25:51AM -0700, Edward Tsang via openssl-users wrote:
> https://www.openssl.org/docs/man1.1.1/man3/X509_STORE_CTX_verify_cb.html
>
> I am trying to figure out how this example works but it does not seem to
> bypass the (use the second example of X509_V_ERR_CERT_HAS_EXPIRED)
>
> However the caller code
> long res = SSL_get_verify_result( sslCtx ); still reports res NOT as
> X509_V_OK, which it should be oper the example since it is returning as 1.
This is correct and expected. Returning "ok = 1" from the verify
callback allows the handshake to continue, rather than be aborted,
but it does not and should not mark the certificate as verified.
> I don't think I need to use X509_STORE_CTX_set_error(ctx, X509_V_OK);
> before return 1 in the X509_STORE_CTX_verify_cb example.
> Or am I missing something?
You're missing something. It is best to not suppress the error code,
since this will also mean that resumed sessions are unaware of the
error, ... Rather if you want to tolerate expired certificates record
and admit that error both in the callback and after the handshake.
--
Viktor.
------------------------------
Subject: Digest Footer
_______________________________________________
openssl-users mailing list
openssl-users@xxxxxxxxxxx
https://mta.openssl.org/mailman/listinfo/openssl-users
------------------------------
End of openssl-users Digest, Vol 88, Issue 18
*********************************************
