Re: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1

[Blumenthal, Uri - 0553 - MITLL]

> > For now the ASN.1 string is not an opaque structure.
> 
> Considering how OpenSSL design evolved, I suspect that the time may come
> when this string would become opaque. Therefore, I suggest that
> getter/setter functions should be added.

Any thoughts about the interface?

Alas, since I don't have any experience actually using these flags, I don't 
consider myself competent suggesting the API here.

Some flag bits look internal, and not necessarily ideal for applications to 
modify directly, so
while these might do:

long ASN1_STRING_get_flags(ASN1_STRING *);
void ASN1_STRING_set_flags(ASN1_STRING *, long);

This makes sense. Also, if there are flags that users are likely to need - 
perhaps explicit getter/setter calls for those individual flags? This would 
lower the likelihood of erroneously affecting unintended flags by a 
"ricochet"...

Perhaps all that's needed is:

int ASN1_BIT_STRING_set_unused(ASN1_STRING *, int);

which sets the unused bit count, checking that the ASN1_STRING type
is V_ASN1_BIT_STRING and the count is in the range [0,7].

That I don't know. I can't figure how or why I would use ..._set_unused()... 
But as I said, my competence in this particular thing is low.


smime.p7s
Description: S/MIME cryptographic signature

Re: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1

[Viktor Dukhovni]

On Tue, Jun 18, 2019 at 09:51:31PM +, Blumenthal, Uri - 0553 - MITLL wrote:

> > We should perhaps provide getter/setter functions for the flags, or
> > perhaps even a specific function for indicating the value is a bitstring,
> > and how many bits it holds.  For now the ASN.1 string is not an opaque
> > structure.
> 
> Considering how OpenSSL design evolved, I suspect that the time may come
> when this string would become opaque. Therefore, I suggest that
> getter/setter functions should be added.

Any thoughts about the interface?  Some flag bits look internal,
and not necessarily ideal for applications to modify directly, so
while these might do:

long ASN1_STRING_get_flags(ASN1_STRING *);
void ASN1_STRING_set_flags(ASN1_STRING *, long);

Perhaps all that's needed is:

int ASN1_BIT_STRING_set_unused(ASN1_STRING *, int);

which sets the unused bit count, checking that the ASN1_STRING type
is V_ASN1_BIT_STRING and the count is in the range [0,7].

-- 
Viktor.

Re: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1

[Blumenthal, Uri - 0553 - MITLL]

On 6/18/19, 5:44 PM, "openssl-users on behalf of Viktor Dukhovni" 
 
wrote:

We should
perhaps provide getter/setter functions for the flags, or perhaps
even a specific function for indicating the value is a bitstring,
and how many bits it holds.  For now the ASN.1 string is not an
opaque structure.

Considering how OpenSSL design evolved, I suspect that the time may come when 
this string would become opaque. Therefore, I suggest that getter/setter 
functions should be added.


smime.p7s
Description: S/MIME cryptographic signature

Re: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1

[Viktor Dukhovni]

On Tue, Jun 18, 2019 at 02:27:30PM -0700, Lisa Matias wrote:

> Sorry, I was just frustrated that the changes to OpenSSL 1.1.1 broke code
> which worked for nearly 15 years, by denying access to previously
> accessible C structs.

Those changes are needed to make sure that future changes in the
internals DO NOT break your code.  The internal data layout would
ideally not have been exposed the first place, but my time-machine
is out of order...

> Are you sure that the ASN.1 BIT STRING value is really stored as an ASN.1
> STRING in a X500_NAME_ENTRY, when it is a binary value and not a text value?

Yes, it is stored as ASN.1 string, which is just a buffer with a length,
but also has:

struct asn1_string_st {
int length;
int type;
unsigned char *data;
/*
 * The value of the following field depends on the type being held.  It
 * is mostly being used for BIT_STRING so if the input data has a
 * non-zero 'unused bits' value, it will be handled correctly
 */
long flags;
};

a type field (the NID for the associated OID) and flags as noted
in the comment.

> Regardless, I did try this as you helpfully suggested:
> 
> (X509_NAME_ENTRY_get_data (nameEntry)->flags) |=
> (ASN1_STRING_FLAG_BITS_LEFT | i);
> 
> And it seems to be working properly for x500UniqueIdentifer attribute,
> without any errors I can find during compile or in the content of the
> resulting certificates.
> 
> Thank you very much for your assistance.

You're welcome, that is the correct technique at present.  We should
perhaps provide getter/setter functions for the flags, or perhaps
even a specific function for indicating the value is a bitstring,
and how many bits it holds.  For now the ASN.1 string is not an
opaque structure.

-- 
Viktor.

Re: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1

[Lisa Matias]

Sorry, I was just frustrated that the changes to OpenSSL 1.1.1 broke code
which worked for nearly 15 years, by denying access to previously
accessible C structs.

I was able to use OpenSSL to generate a certificate with a subject
containing the x500UniqueIdentifier attribute as a pure ASN.1 BIT STRING,
as you can see with the following snippet from OpenSSL asn1parse.

  ___:d=5  hl=2 l=   3 prim: OBJECT:x500UniqueIdentifier
  ___:d=5  hl=2 l=  16 prim: BIT STRING

Are you sure that the ASN.1 BIT STRING value is really stored as an ASN.1
STRING in a X500_NAME_ENTRY, when it is a binary value and not a text value?

Regardless, I did try this as you helpfully suggested:

(X509_NAME_ENTRY_get_data (nameEntry)->flags) |=
(ASN1_STRING_FLAG_BITS_LEFT | i);


And it seems to be working properly for x500UniqueIdentifer attribute,
without any errors I can find during compile or in the content of the
resulting certificates.

Thank you very much for your assistance.

Lisa.


On Tue, 18 Jun 2019 at 12:30, Viktor Dukhovni 
wrote:

> On Tue, Jun 18, 2019 at 07:16:46AM -0700, Lisa Matias wrote:
>
> > If you look here:
> >
> > https://www.openssl.org/docs/man1.1.0/man3/X509_NAME_ENTRY_get_data.html
> >
> > It states:
> >
> > *X509_NAME_ENTRY_get_data() retrieves the field value of ne in
> > and ASN1_STRING structure.*
>
> Regardless of the entry type, the underlying value is always stored
> as an ASN.1 string.
>
> struct X509_name_entry_st {
> ASN1_OBJECT *object;/* AttributeType */
> ASN1_STRING *value; /* AttributeValue */
> int set;/* index of RDNSequence for this entry
> */
> int size;   /* temp variable */
> };
>
> The flags you're looking for are associated with the ASN.1 string.
> To indicate that it is a bit-string you set:
>
> value->flags |= ASN1_STRING_FLAG_BITS_LEFT | i
>
> where "i" is the number of unused bits in the final octet.
>
> > Unfortunately this does not work for any non-string X.500 attributes such
> > as x500UniqueIdentifer which is defined as an ASN.1 BIT STRING.
>
> Actually, it does.
>
> --
> Viktor.
>

Re: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1

[Viktor Dukhovni]

On Tue, Jun 18, 2019 at 07:16:46AM -0700, Lisa Matias wrote:

> If you look here:
> 
> https://www.openssl.org/docs/man1.1.0/man3/X509_NAME_ENTRY_get_data.html
> 
> It states:
> 
> *X509_NAME_ENTRY_get_data() retrieves the field value of ne in
> and ASN1_STRING structure.*

Regardless of the entry type, the underlying value is always stored
as an ASN.1 string.

struct X509_name_entry_st {
ASN1_OBJECT *object;/* AttributeType */
ASN1_STRING *value; /* AttributeValue */
int set;/* index of RDNSequence for this entry */
int size;   /* temp variable */
};

The flags you're looking for are associated with the ASN.1 string.
To indicate that it is a bit-string you set:

value->flags |= ASN1_STRING_FLAG_BITS_LEFT | i

where "i" is the number of unused bits in the final octet.

> Unfortunately this does not work for any non-string X.500 attributes such
> as x500UniqueIdentifer which is defined as an ASN.1 BIT STRING.

Actually, it does.

-- 
Viktor.

Re: PkiPath with openssl

[Wim Lewis]

On Jun 17, 2019, at 11:35 PM, Tobias Wolf  wrote:
> The specification said about sorting and providing the pki path in correct 
> order. 

Ah, I thought you were asking about producing the correct DER representation, 
not assembling the list of certs.

In that case, take a look at the documentation for X509_verify_cert() and 
X509_STORE_add_cert() (also see X509_STORE_CTX_init(), X509_VERIFY_PARAM_*(), 
X509_STORE_CTX_get*_chain()). This will discover and validate a trust chain 
from a specified certificate to any of a set of trust anchors, via a set of 
possible intermediate certificates. The resulting chain should be ordered 
properly (you may need to reverse the order).  If you don't want to spend the 
extra time verifying signatures and constraints and so on, you might be able to 
turn that off by setting some options.

I think the X509_STORE_add_cert() manpage has the most comprehensible 
description of how these pieces fit together.

RE: Issues establising SSL connection after a wget command

[Eric Ntonfo]

Hello,
Please still looking forward to a suggestion of solution on my error:1407742E 
issue below
How can i fix this?
It's not only a matter of using wget. All commands that require to ocnnect to 
an SSL server are failing
Yhans a lot
Eric



On Mon, 2019-06-17 at 20:29 +, Eric Ntonfo wrote:

Hello,
I am running an Ubuntu 12.04 TLS server and can't use wget to download software 
packages
The command
wget http://curl.haxx.se/download/curl-7.63.0.tar.bz2
fails with the following error

--2019-06-17 22:10:11--  http://curl.haxx.se/download/curl-7.63.0.tar.bz2
Resolving curl.haxx.se (curl.haxx.se)... 2a04:4e42:9::561, 151.101.38.49
Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://curl.haxx.se/download/curl-7.63.0.tar.bz2 [following]
--2019-06-17 22:10:11--  https://curl.haxx.se/download/curl-7.63.0.tar.bz2
Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:443... connected.
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert 
protocol version
Unable to establish SSL connection.

I am unable to fix this issue. I have upgraded from openssl 1.0.1 on my Ubuntu 
box to openssl 1.0.2 having heard that this latest version fix the bug
But still having it.

Can someone help please?
Regards
Eric

Re: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1

[Lisa Matias]

If you look here:

https://www.openssl.org/docs/man1.1.0/man3/X509_NAME_ENTRY_get_data.html

It states:

*X509_NAME_ENTRY_get_data() retrieves the field value of ne in
and ASN1_STRING structure.*


Unfortunately this does not work for any non-string X.500 attributes such
as x500UniqueIdentifer which is defined as an ASN.1 BIT STRING.

I am only looking to fix in OpenSSL 1.1.1, what was previously working in
all older versions of OpenSSL all the way back to 0.9.7 which included a
way to support non-string attributes in X509_NAME_ENTRY.

Thanks.

Lisa.



On Mon, 17 Jun 2019 at 22:37, Viktor Dukhovni 
wrote:

> On Mon, Jun 17, 2019 at 09:19:41PM -0700, Lisa Matias wrote:
>
> > X509_NAME_ENTRY *nameEntry;
> > nameEntry = X509_NAME_ENTRY_create_by_NID (, nid,
> > derTagToVType (tag), buffer, bufferLength);
> > *nameEntry->value->flags = specifiedFlags;*
>
> Can you be a bit more explicit about why you need to do this?
> What flags do you intend to set and why?
>
> That said, you can use:
>
> ASN1_STRING *X509_NAME_ENTRY_get_data(const X509_NAME_ENTRY *ne);
>
> to get the ASN1_STRING holding the value, and since ASN1_STRINGs
> are not opaque types, you can just use:
>
> value->flags = ...
>
> asuming that's a sensible thing to do.  You may however be straying
> into undocumented behaviour, and so it might be good to know whether
> perhaps there's a better way of getting the result you actually want.
>
> --
> Viktor.
>

Re: Something like SSL_CTX_set_alpn_select_cb for ciphers and ssl/tls protocol version

[Matt Caswell]

On 18/06/2019 10:13, Alexander Gryanko wrote:
> Hello, 
> 
> I'm looking for the way to do something like SSL_CTX_set_alpn_select_cb but 
> for
> ciphers and ssl/tls protocol version. As I see ssl_choose_server_version and
> ssl3_choose_cipher has no any callbacks in 
> tls_early_post_process_client_hello.
> Is there any way to disable protocols for some cases? Something like A/B 
> testing
> with 50% of traffic with enabled Chacha20 and 50% of traffic with disabled.

If you are using OpenSSL 1.1.1 then probably you could do something with the
client hello callback:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_client_hello_cb.html

Matt

Re: Issues establising SSL connection after a wget command

[Matt Caswell]

On 17/06/2019 21:29, Eric Ntonfo wrote:
> 
> Hello,
> I am running an Ubuntu 12.04 TLS server and can't use wget to download 
> software
> packages
> The command
> wget http://curl.haxx.se/download/curl-7.63.0.tar.bz2
> fails with the following error
> 
> --2019-06-17 22:10:11--  http://curl.haxx.se/download/curl-7.63.0.tar.bz2
> Resolving curl.haxx.se (curl.haxx.se)... 2a04:4e42:9::561, 151.101.38.49
> Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:80... connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://curl.haxx.se/download/curl-7.63.0.tar.bz2 [following]
> --2019-06-17 22:10:11--  https://curl.haxx.se/download/curl-7.63.0.tar.bz2
> Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:443... connected.
> *OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
> protocol version*
> Unable to establish SSL connection.

You get this error when the client is offering a version of TLS that is too low
for the server. I just did some tests and it appears that this server will
refuse to connect with anything less than TLSv1.2.

That should be fine with both OpenSSL 1.0.1 and OpenSSL 1.0.2. Both of those
support TLSv1.2 and will offer it by default. However an application can
override the defaults. My suspicion is that your version of wget is old and, for
some reason, is overriding the default TLS version and requiring some earlier
version.

Upgrading wget might work.

Matt


> 
> I am unable to fix this issue. I have upgraded from openssl 1.0.1 on my Ubuntu
> box to openssl 1.0.2 having heard that this latest version fix the bug
> But still having it.
> 
> Can someone help please?
> Regards
> Eric

Something like SSL_CTX_set_alpn_select_cb for ciphers and ssl/tls protocol version

[Alexander Gryanko]

Hello,

I'm looking for the way to do something like SSL_CTX_set_alpn_select_cb but
for ciphers and ssl/tls protocol version. As I see
ssl_choose_server_version and ssl3_choose_cipher has no any callbacks in
tls_early_post_process_client_hello. Is there any way to disable protocols
for some cases? Something like A/B testing with 50% of traffic with enabled
Chacha20 and 50% of traffic with disabled.

Thank you.

-- 
С уважением,
Александр Грянко

Information on Build.info

[shiva kumar]

Hi,
Actually I wanted to know how build.info file in each directory such as
apps, engines etc, will used generate the Make file, what would happen If I
wanted to change the build.info file

1) in openssl/*apps/build.info *
what would happen if I change
*DEPEND[openssl]=libapps.a ../libssl*
to
*DEPEND[openssl]=libapps.a ../libssl.a*

2)in openssl/*engines/build.info *
what would hapen if I change
*  LIBS=../libcrypto*
  to
*  LIBS=../libcrypto.a*

*  DEPEND[padlock]=../libcrypto*
  to
  *DEPEND[padlock]=../libcrypto*

  *DEPEND[capi]=../libcrypto*
  to
  *DEPEND[capi]=../libcrypto.a*

  *DEPEND[afalg]=../libcrypto*
  to
  *DEPEND[afalg]=../libcrypto*

  * DEPEND[dasync]=../libcrypto*
   to
*DEPEND[dasync]=../libcrypto*

*DEPEND[ossltest]=../libcrypt*
   to
*DEPEND[ossltest]=../libcrypt*

3) in *openssl/build.file*
what would happen if I change
*DEPEND[libssl]=libcrypto*
to
   * DEPEND[libssl]=libcrypto.a*

please let me know

Thanks and Regards
Shivakumar