Server-side visibility of signature algorithm and key exchange properties?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Server-side visibility of signature algorithm and key exchange properties?

Viktor Dukhovni
On the client side of a TLS connection, I'm easily able to find all
the primary parameters of interest:

    * The cipher used.
    * The server signature algorithm (digest, and public key)
    * The server key exchange algorithm (public key)

enabling logging such as:

  TLS connection established to 127.0.0.1[127.0.0.1]:25:
    TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
    signature ECDSA(P-256) digest SHA256 key-exchange X25519

I am having a bit of trouble finding the equivalent information for
the 3rd line on the server side.  Anyone know how, in TLS 1.3 where
these are not implied by the ciphersuite, to determine the signature
algorithm (and curve for ECDSA), the hash algorithm and key exchange
public key (with bit count for DH or curve name for ECDSA)?

Are these available for inspection by the server application?  If
not, that may be an omission we need to address.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Server-side visibility of signature algorithm and key exchange properties?

Matt Caswell-2


On 09/11/2018 08:38, Viktor Dukhovni wrote:

> On the client side of a TLS connection, I'm easily able to find all
> the primary parameters of interest:
>
>     * The cipher used.
>     * The server signature algorithm (digest, and public key)
>     * The server key exchange algorithm (public key)
>
> enabling logging such as:
>
>   TLS connection established to 127.0.0.1[127.0.0.1]:25:
>     TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
>     signature ECDSA(P-256) digest SHA256 key-exchange X25519
>
> I am having a bit of trouble finding the equivalent information for
> the 3rd line on the server side.  Anyone know how, in TLS 1.3 where
> these are not implied by the ciphersuite, to determine the signature
> algorithm (and curve for ECDSA), the hash algorithm and key exchange
> public key (with bit count for DH or curve name for ECDSA)?

I don't believe we currently expose the signature algorithm selected on
the server side. It's held in s->s3->tmp.sigalg, but AFAICT that is only
ever used internally.

Similarly the key exchange public key is held in s->s3->peer_tmp. We do
expose that via SSL_get_server_tmp_key(), but its a client side only
function. We explicitly check that and return 0 if called on the server
side.

Matt


>
> Are these available for inspection by the server application?  If
> not, that may be an omission we need to address.
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Server-side visibility of signature algorithm and key exchange properties?

Viktor Dukhovni
On Fri, Nov 09, 2018 at 06:42:28PM +0000, Matt Caswell wrote:

> > I am having a bit of trouble finding the equivalent information for
> > the 3rd line on the server side.  Anyone know how, in TLS 1.3 where
> > these are not implied by the ciphersuite, to determine the signature
> > algorithm (and curve for ECDSA), the hash algorithm and key exchange
> > public key (with bit count for DH or curve name for ECDSA)?
>
> I don't believe we currently expose the signature algorithm selected on
> the server side. It's held in s->s3->tmp.sigalg, but AFAICT that is only
> ever used internally.

Thanks for confirming, it is then not surprising I failed to find
the relevant interfaces. :-)

> Similarly the key exchange public key is held in s->s3->peer_tmp. We do
> expose that via SSL_get_server_tmp_key(), but its a client side only
> function. We explicitly check that and return 0 if called on the server
> side.

Quick question about that, since the client may also sign the key
exchange when a client certificate is requested and returned, what
is held on the server in s->s3->tmp.sigalg?  [ I expect still the
signature the server used in its CertificateVerify. And on the
client side, I would expect this to hold the algorithm used by the
client to sign its ClientVerify if a client cert was used. ]

And it seems that on the server side s->s3->peer_tmp does actually
hold the client's key exchange public key, which is necessarily for
the same group as the server, so all we'd need to do is remove that
'explicit check' and that key be visible on the server side, right?

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Server-side visibility of signature algorithm and key exchange properties?

Matt Caswell-2


On 09/11/2018 19:42, Viktor Dukhovni wrote:

> On Fri, Nov 09, 2018 at 06:42:28PM +0000, Matt Caswell wrote:
>
>>> I am having a bit of trouble finding the equivalent information for
>>> the 3rd line on the server side.  Anyone know how, in TLS 1.3 where
>>> these are not implied by the ciphersuite, to determine the signature
>>> algorithm (and curve for ECDSA), the hash algorithm and key exchange
>>> public key (with bit count for DH or curve name for ECDSA)?
>>
>> I don't believe we currently expose the signature algorithm selected on
>> the server side. It's held in s->s3->tmp.sigalg, but AFAICT that is only
>> ever used internally.
>
> Thanks for confirming, it is then not surprising I failed to find
> the relevant interfaces. :-)
>
>> Similarly the key exchange public key is held in s->s3->peer_tmp. We do
>> expose that via SSL_get_server_tmp_key(), but its a client side only
>> function. We explicitly check that and return 0 if called on the server
>> side.
>
> Quick question about that, since the client may also sign the key
> exchange when a client certificate is requested and returned, what
> is held on the server in s->s3->tmp.sigalg?  [ I expect still the
> signature the server used in its CertificateVerify. And on the
> client side, I would expect this to hold the algorithm used by the
> client to sign its ClientVerify if a client cert was used. ]

Right - exactly that. s->s3->tmp.sigalg always holds the sigalg the
endpoint selected to sign its own CertificateVerify (whether that be
client or server).

>
> And it seems that on the server side s->s3->peer_tmp does actually
> hold the client's key exchange public key, which is necessarily for
> the same group as the server, so all we'd need to do is remove that
> 'explicit check' and that key be visible on the server side, right?
>

Right - although we might want to think about the name of the function.

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