RE: Retrieve CA for client cert from SSL*
SSL_get0_verified_chain was exactly what I needed, thanks! -Original Message- From: openssl-users On Behalf Of Viktor Dukhovni Sent: Friday, October 25, 2019 11:55 AM To: openssl-users@openssl.org Subject: Re: Retrieve CA for client cert from SSL* > On Oct 25, 2019, at 5:38 PM, Jan Just Keijser wrote: > >> Is there a way to figure out which CA the server used to validate the client >> certificate? > > on the server side? you would have to write your own verify callback to > intercept the certificate stack as it is processed. That way, you can monitor > which CA openssl selected for verification. No, that's not necessary. After the completion of the handshake one can call SSL_get0_verified_chain(3). This chain is only available on full handshakes, when validation is successful (SSL_get_verify_result(3) returns X509_V_OK). On resumption, only the leaf certificate is available from the resumed session, via SSL_get_peer_certificate(3). Of course there might not be a client certificate at all. -- Viktor.
Re: Retrieve CA for client cert from SSL*
> On Oct 25, 2019, at 5:38 PM, Jan Just Keijser wrote: > >> Is there a way to figure out which CA the server used to validate the client >> certificate? > > on the server side? you would have to write your own verify callback to > intercept the certificate stack as it is processed. That way, you can monitor > which CA openssl selected for verification. No, that's not necessary. After the completion of the handshake one can call SSL_get0_verified_chain(3). This chain is only available on full handshakes, when validation is successful (SSL_get_verify_result(3) returns X509_V_OK). On resumption, only the leaf certificate is available from the resumed session, via SSL_get_peer_certificate(3). Of course there might not be a client certificate at all. -- Viktor.
Re: Retrieve CA for client cert from SSL*
Is looking at the IssuerDN good enough?
Re: AW: openssl and external card reader support in TLS
Hi Tobias, On 23/10/19 10:11, tobias.w...@t-systems.com wrote: Our PKCS11 module development will discontinue and therefore I can`t use it anymore, but the idea is great and very interesting. To give more details we need a callback or similar mechanism to replace the signature created in Certificate TLS message with our signature coming from the card reader. TLS handshake .. S: Certificate Request C: Certificate Verify --> here we want to hook in "Signature" and replace the value! . We tried already with the client callback int (*client_cert_cb)(SSL *ssl, X509 **x509, EVP_PKEY **pkey)); But there it is mandatory to give in the private key which we don`t have, because that part is done by the card reader machine. I think the caller of the callback is doing later on a rsa sign processing with the private key and there I want to hook in! writing your own engine might be the easiest thing: the way it currently(most likely) works, is openssl -> engine_pkcs11 -> libp11 -> pkcs11 driver all you'd have to do is move your pkcs11 driver code into a fork of the engine_pkcs11 code. That code is less than 2000 lines long, so it should be fairly straightforward. JM2CW, JJK
Re: Retrieve CA for client cert from SSL*
On 24/10/19 19:55, Fen Fox wrote: Is there a way to figure out which CA the server used to validate the client certificate? on the server side? you would have to write your own verify callback to intercept the certificate stack as it is processed. That way, you can monitor which CA openssl selected for verification. HTH, JJK
Re: Are DHE_DSS cipher suites not supported?
On Fri, Oct 25, 2019 at 8:50 PM Matt Caswell wrote: > > > On 25/10/2019 09:39, Viktor Dukhovni wrote: > > On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote: > > > >> I'm using OpenSSL 1.1.1d. > >> Just want to confirm if DHE_DSS cipher suites are not supported by this > >> version. > > > > They are supported, but: > > > > * DSS ciphersuites are disabled by DEFAULT. You need to > > specify an explicit "-cipher" option to enable these, > > for example: > > > > $ openssl s_server -accept 12345 \ > > -tls1_2 -cipher DHE-DSS-AES256-GCM-SHA384 \ > > -dhparam dhparam.pem -key dsakey.pem -cert dsacert.pem > > > > or more typically: > > > > -cipher 'ALL:!RC4:!aNULL' > > > > * You should also supply DH parameters as above: > > This step is optional. It will work just fine with default parameters if > you don't specify them. > I only add option -cipher to s_server. That works for me. Thanks! > > Matt > > > > > > > -dhparam dhparam.pem > > > > I generated these with: > > > > $ openssl genpkey -genparam -algorithm dh \ > > -pkeyopt dh_paramgen_prime_len:2048 -out dhparam.pem > > >
Re: Are DHE_DSS cipher suites not supported?
On 25/10/2019 09:39, Viktor Dukhovni wrote: > On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote: > >> I'm using OpenSSL 1.1.1d. >> Just want to confirm if DHE_DSS cipher suites are not supported by this >> version. > > They are supported, but: > > * DSS ciphersuites are disabled by DEFAULT. You need to > specify an explicit "-cipher" option to enable these, > for example: > > $ openssl s_server -accept 12345 \ > -tls1_2 -cipher DHE-DSS-AES256-GCM-SHA384 \ > -dhparam dhparam.pem -key dsakey.pem -cert dsacert.pem > > or more typically: > > -cipher 'ALL:!RC4:!aNULL' > > * You should also supply DH parameters as above: This step is optional. It will work just fine with default parameters if you don't specify them. Matt > > -dhparam dhparam.pem > > I generated these with: > > $ openssl genpkey -genparam -algorithm dh \ > -pkeyopt dh_paramgen_prime_len:2048 -out dhparam.pem >
Re: Compute EC_KEY starting from X or Y coordinate only
> If I have an x-point which follows this representation > https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is > composed by 33 byte and first byte is '0x02') and I use > 'EC_POINT_set_compressed_coordinates_GFp' function, it will be > considered as compressed-y-0 or compressed-y-1? Or it is correctly > considered as the x coordinate? What you are saying and what you are doing are two different things. Your code is at a very low level. Above this there is some encoding of points, depending on any number of standards. OpenSSL implements some of them, but at a higher level. The low level API you're talking about provides maximum flexibility to map that high level encoding in to the API's "x-coord + y-bit" concept. It's up to you to figure out the details. (Including determining if the encoding in OpenSSL matches what's expected in your spec.) You need to play around a bit with the lib -- you can't expect this list to interpret the standard for you. Check the "test" folder for sample code. BBB
Re: Compute EC_KEY starting from X or Y coordinate only
But the y bit is indicated by the foutth parameter of 'EC_POINT_set_compressed_coordinates_GFp' function. Isn't the representation you linked different by that that I linked previously? Luca Thulasi Goriparthi ha scritto: 02 indicates y bit is 0 03 indicates y bit is 1 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.202.2977=rep1=pdf Thanks, Thulasi. On Fri, 25 Oct 2019 at 16:50, Luca Di Mauro wrote: Mh, maybe I didn't understand. If I have an x-point which follows this representation https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is composed by 33 byte and first byte is '0x02') and I use 'EC_POINT_set_compressed_coordinates_GFp' function, it will be considered as compressed-y-0 or compressed-y-1? Or it is correctly considered as the x coordinate? Luca Billy Brumley ha scritto: >> Thank you! I thought they were the same. >> >> And given an x-only coordinate, how can I find the y coordinate? I >> don't find the relative functions on the documentation. > > Well it depends on what you mean. Internally, > EC_POINT_set_compressed_coordinates_GFp will internally automatically > compute the y coordinate based on the y_bit argument. > > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 0, ... > EC_POINT_get_affine_coordinates_GFp(group, p, X0, Y0 ... > > That will get you one of the points in X0, Y0. > > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 1, ... > EC_POINT_get_affine_coordinates_GFp(group, p, X1, Y1 ... > > That will get you the other point in X1, Y1. (Where X0 = X1 = x.) > > (But you are probably looking to do something cryptographically > interesting between set/get, which is application specific.) > > Generally, in addition to the man pages which you seem to have found, > check the "tests" folder if you are looking for examples to get > started. > > BBB
Re: Compute EC_KEY starting from X or Y coordinate only
02 indicates y bit is 0 03 indicates y bit is 1 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.202.2977=rep1=pdf Thanks, Thulasi. On Fri, 25 Oct 2019 at 16:50, Luca Di Mauro wrote: > > Mh, maybe I didn't understand. > > If I have an x-point which follows this representation > https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is > composed by 33 byte and first byte is '0x02') and I use > 'EC_POINT_set_compressed_coordinates_GFp' function, it will be > considered as compressed-y-0 or compressed-y-1? Or it is correctly > considered as the x coordinate? > > Luca > > Billy Brumley ha scritto: > > >> Thank you! I thought they were the same. > >> > >> And given an x-only coordinate, how can I find the y coordinate? I > >> don't find the relative functions on the documentation. > > > > Well it depends on what you mean. Internally, > > EC_POINT_set_compressed_coordinates_GFp will internally automatically > > compute the y coordinate based on the y_bit argument. > > > > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 0, ... > > EC_POINT_get_affine_coordinates_GFp(group, p, X0, Y0 ... > > > > That will get you one of the points in X0, Y0. > > > > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 1, ... > > EC_POINT_get_affine_coordinates_GFp(group, p, X1, Y1 ... > > > > That will get you the other point in X1, Y1. (Where X0 = X1 = x.) > > > > (But you are probably looking to do something cryptographically > > interesting between set/get, which is application specific.) > > > > Generally, in addition to the man pages which you seem to have found, > > check the "tests" folder if you are looking for examples to get > > started. > > > > BBB > > > >
Re: Compute EC_KEY starting from X or Y coordinate only
Mh, maybe I didn't understand. If I have an x-point which follows this representation https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is composed by 33 byte and first byte is '0x02') and I use 'EC_POINT_set_compressed_coordinates_GFp' function, it will be considered as compressed-y-0 or compressed-y-1? Or it is correctly considered as the x coordinate? Luca Billy Brumley ha scritto: Thank you! I thought they were the same. And given an x-only coordinate, how can I find the y coordinate? I don't find the relative functions on the documentation. Well it depends on what you mean. Internally, EC_POINT_set_compressed_coordinates_GFp will internally automatically compute the y coordinate based on the y_bit argument. EC_POINT_set_compressed_coordinates_GFp(group, p, x, 0, ... EC_POINT_get_affine_coordinates_GFp(group, p, X0, Y0 ... That will get you one of the points in X0, Y0. EC_POINT_set_compressed_coordinates_GFp(group, p, x, 1, ... EC_POINT_get_affine_coordinates_GFp(group, p, X1, Y1 ... That will get you the other point in X1, Y1. (Where X0 = X1 = x.) (But you are probably looking to do something cryptographically interesting between set/get, which is application specific.) Generally, in addition to the man pages which you seem to have found, check the "tests" folder if you are looking for examples to get started. BBB
Re: Compute EC_KEY starting from X or Y coordinate only
> Thank you! I thought they were the same. > > And given an x-only coordinate, how can I find the y coordinate? I > don't find the relative functions on the documentation. Well it depends on what you mean. Internally, EC_POINT_set_compressed_coordinates_GFp will internally automatically compute the y coordinate based on the y_bit argument. EC_POINT_set_compressed_coordinates_GFp(group, p, x, 0, ... EC_POINT_get_affine_coordinates_GFp(group, p, X0, Y0 ... That will get you one of the points in X0, Y0. EC_POINT_set_compressed_coordinates_GFp(group, p, x, 1, ... EC_POINT_get_affine_coordinates_GFp(group, p, X1, Y1 ... That will get you the other point in X1, Y1. (Where X0 = X1 = x.) (But you are probably looking to do something cryptographically interesting between set/get, which is application specific.) Generally, in addition to the man pages which you seem to have found, check the "tests" folder if you are looking for examples to get started. BBB
Re: Compute EC_KEY starting from X or Y coordinate only
Thank you! I thought they were the same. And given an x-only coordinate, how can I find the y coordinate? I don't find the relative functions on the documentation. Luca Billy Brumley ha scritto: Don't do that. As I said, the library is trying to tell you that's not a point on the secp256k1 curve. Quickly browsing the standard, you are likely looking for the prime256v1 curve. BBB On Fri, 25 Oct 2019, 9.28 Luca Di Mauro, wrote: I think it is correct because I extracted the hexadecimal string from a packet contained in a pcap. This compressed point is created following the ETSI TS 103 097 v1.3.1 standard for secured communications in the vehicular communication context ( https://www.etsi.org/deliver/etsi_ts/103000_103099/103097/01.03.01_60/ts_103097v010301p.pdf ). I notice that the point 'pubPoint' that I created is empty when I try to call 'EC_POINT_set_compressed_coordinates_GFp' function. How can I put a BIGNUM into an EC_POINT? Luca Billy Brumley ha scritto: >> EC_GROUP* group = EC_GROUP_new_by_curve_name >> (NID_secp256k1); > >> "c16b4ce0532f5dc9d09114fe121d3956ae84f9eb677a0d4bdac1d3af7a91950c"; > > I don't believe there's a point on secp256k1 with that x-coordinate. > If you check the failure reason for > EC_POINT_set_compressed_coordinates_GFp in the debugger, that is > probably what it is telling you. > > Where did this curve / x-coord pair come from? > > BBB
Re: Are DHE_DSS cipher suites not supported?
On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote: > I'm using OpenSSL 1.1.1d. > Just want to confirm if DHE_DSS cipher suites are not supported by this > version. They are supported, but: * DSS ciphersuites are disabled by DEFAULT. You need to specify an explicit "-cipher" option to enable these, for example: $ openssl s_server -accept 12345 \ -tls1_2 -cipher DHE-DSS-AES256-GCM-SHA384 \ -dhparam dhparam.pem -key dsakey.pem -cert dsacert.pem or more typically: -cipher 'ALL:!RC4:!aNULL' * You should also supply DH parameters as above: -dhparam dhparam.pem I generated these with: $ openssl genpkey -genparam -algorithm dh \ -pkeyopt dh_paramgen_prime_len:2048 -out dhparam.pem -- Viktor.
Are DHE_DSS cipher suites not supported?
Hi, I'm using OpenSSL 1.1.1d. Just want to confirm if DHE_DSS cipher suites are not supported by this version. Please consider the below simple case, 1. s_server uses a DSA certifcate 2. force s_client to use TLS 1.2 and TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (DHE-DSS-AES256-GCM-SHA384) the connection failed, and s_server reported: no shared cipher:ssl/statem/statem_srvr.c:2259 But I still can see this cipher suite in the below doc, https://www.openssl.org/docs/man1.1.1/man1/ciphers.html
Re: Compute EC_KEY starting from X or Y coordinate only
Don't do that. As I said, the library is trying to tell you that's not a point on the secp256k1 curve. Quickly browsing the standard, you are likely looking for the prime256v1 curve. BBB On Fri, 25 Oct 2019, 9.28 Luca Di Mauro, wrote: > I think it is correct because I extracted the hexadecimal string from > a packet contained in a pcap. > > This compressed point is created following the ETSI TS 103 097 v1.3.1 > standard for secured communications in the vehicular communication > context > ( > https://www.etsi.org/deliver/etsi_ts/103000_103099/103097/01.03.01_60/ts_103097v010301p.pdf > ). > > I notice that the point 'pubPoint' that I created is empty when I try > to call 'EC_POINT_set_compressed_coordinates_GFp' function. How can I > put a BIGNUM into an EC_POINT? > > Luca > > Billy Brumley ha scritto: > > >> EC_GROUP* group = EC_GROUP_new_by_curve_name > >> (NID_secp256k1); > > > >> "c16b4ce0532f5dc9d09114fe121d3956ae84f9eb677a0d4bdac1d3af7a91950c"; > > > > I don't believe there's a point on secp256k1 with that x-coordinate. > > If you check the failure reason for > > EC_POINT_set_compressed_coordinates_GFp in the debugger, that is > > probably what it is telling you. > > > > Where did this curve / x-coord pair come from? > > > > BBB > > > >
Re: Compute EC_KEY starting from X or Y coordinate only
I think it is correct because I extracted the hexadecimal string from a packet contained in a pcap. This compressed point is created following the ETSI TS 103 097 v1.3.1 standard for secured communications in the vehicular communication context (https://www.etsi.org/deliver/etsi_ts/103000_103099/103097/01.03.01_60/ts_103097v010301p.pdf). I notice that the point 'pubPoint' that I created is empty when I try to call 'EC_POINT_set_compressed_coordinates_GFp' function. How can I put a BIGNUM into an EC_POINT? Luca Billy Brumley ha scritto: EC_GROUP* group = EC_GROUP_new_by_curve_name (NID_secp256k1); "c16b4ce0532f5dc9d09114fe121d3956ae84f9eb677a0d4bdac1d3af7a91950c"; I don't believe there's a point on secp256k1 with that x-coordinate. If you check the failure reason for EC_POINT_set_compressed_coordinates_GFp in the debugger, that is probably what it is telling you. Where did this curve / x-coord pair come from? BBB
