Re: [openssl-users] Unexpected behavior in certificate hostname check

[דרור מויל]

Thanks!

On Wed, 19 Sep 2018 at 00:50, Viktor Dukhovni 
wrote:

> > On Sep 18, 2018, at 5:27 PM, ⁨דרור מויל⁩ <⁨moyald...@gmail.com⁩> wrote:
> >
> > I'm experiencing some unexpected (in my opinion - and I might be in the
> wrong here) behavior in hostname checking the OpenSSL CLI utils.
>
> The default behaviour follows:
>
>https://tools.ietf.org/html/rfc6125#section-6.4.4
>
> which says:
>
>As noted, a client MUST NOT seek a match for a reference identifier
>of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
>URI-ID, or any application-specific identifier types supported by the
>client.
>
> > I'm trying to verify the hostname of a certificate which has CN=
> mysite.com and altSubj=localhost (was generated by pyca/cryptography
> example -
> https://cryptography.io/en/latest/x509/tutorial/#creating-a-self-signed-certificate)
> and the check always fails on hostname mismatch.
>
> Your certificate is poorly crafted it must list all the desired domains in
> the
> subjectAltName extension, and then may repeat one of them in the Subject
> CN as
> a fallback for legacy software.
>
> > The thing is, that when the flags=0, X509_check_host will call
> do_X509_check
> > that will verify only the altSubjNames and not the CN in the Subj.
>
> As expected.
>
> > I tried to find a way to set the flags to
> X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT
> > using a CLI flag or config but there is no such option.
> >
> > Was it meant to work like this? am I missing something?
>
> Obtain a properly crafted certificate and all will be well.
> The host flags, are not IIRC exposed via the CLI.  Good luck.
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unexpected behavior in certificate hostname check

[Viktor Dukhovni]

> On Sep 18, 2018, at 5:27 PM, ⁨דרור מויל⁩ <⁨moyald...@gmail.com⁩> wrote:
> 
> I'm experiencing some unexpected (in my opinion - and I might be in the wrong 
> here) behavior in hostname checking the OpenSSL CLI utils.

The default behaviour follows:

   https://tools.ietf.org/html/rfc6125#section-6.4.4

which says:

   As noted, a client MUST NOT seek a match for a reference identifier
   of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
   URI-ID, or any application-specific identifier types supported by the
   client.

> I'm trying to verify the hostname of a certificate which has CN=mysite.com 
> and altSubj=localhost (was generated by pyca/cryptography example - 
> https://cryptography.io/en/latest/x509/tutorial/#creating-a-self-signed-certificate)
>  and the check always fails on hostname mismatch.

Your certificate is poorly crafted it must list all the desired domains in the
subjectAltName extension, and then may repeat one of them in the Subject CN as
a fallback for legacy software.

> The thing is, that when the flags=0, X509_check_host will call do_X509_check
> that will verify only the altSubjNames and not the CN in the Subj.

As expected.

> I tried to find a way to set the flags to X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT
> using a CLI flag or config but there is no such option.
> 
> Was it meant to work like this? am I missing something?

Obtain a properly crafted certificate and all will be well.
The host flags, are not IIRC exposed via the CLI.  Good luck.

-- 
Viktor.

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

[openssl-users] Unexpected behavior in certificate hostname check

[דרור מויל]

Hi,
I'm experiencing some unexpected (in my opinion - and I might be in the
wrong here) behavior in hostname checking the OpenSSL CLI utils.
I'm trying to verify the hostname of a certificate which has CN=mysite.com
and altSubj=localhost (was generated by pyca/cryptography example -
https://cryptography.io/en/latest/x509/tutorial/#creating-a-self-signed-certificate)
and the check always fails on hostname mismatch.
I tried the following:
1. openssl x509 -in certificate.pem -checkhost mysite.com
2. openssl verify -verify_hostname mysite.com certificate.pem

I could see in the code that they both use X509_check_host and they both
call it with flags=0.
The thing is, that when the flags=0, X509_check_host will call
do_X509_check that will verify only the altSubjNames and not the CN in the
Subj.
I tried to find a way to set the flags
to X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT using a CLI flag or config but
there is no such option.

Was it meant to work like this? am I missing something?

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

Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

[Kurt Roeckx]

On Tue, Sep 18, 2018 at 05:11:42PM +, Salz, Rich via openssl-users wrote:
> >My point was about the likelihood of last-draft browsers lingering
> on in the real world for some time (like 1 to 3 years) after the
> TLS1.3-final browser versions ship.
> 
> I do not think this is a concern.  Chrome and FF auto-update and get almost 
> full coverage within a month or two, for example.  Edge hasn't shipped TLS 
> 1.3 yet. Safari encourages auto-update.  That's most of the browser market.

I think chrome and firefox cover all browsers that ever enabled a
draft version.


Kurt

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

Re: [openssl-users] OpenSSL 1.1 X509_STORE sharing

[Viktor Dukhovni]

> On Sep 18, 2018, at 1:04 PM, Viktor Dukhovni  
> wrote:
> 
> That depends on whether setting the cert_store element was done properly (in 
> a way
> that incremented the reference count) or not.  See the documentation of:
> 
>   SSL_CTX_set1_cert_store(3)
>   SSL_CTX_set_cert_store(3)
> 
> the latter does not facilitate sharing the store across multiple SSL_CTX 
> instances.

Note that SSL_CTX_set1_cert_store(3) is new with OpenSSL 1.1.x.  In OpenSSL
1.0.2, the caller would have to increment the reference count prior to 
calling SSL_CTX_cert_store().  The caller typically owns a primary copy of
the store to use when configuring various SSL_CTX objects.  In that case
the primary copy can be freed once the application no longer intends to
use the store to configuring any more SSL_CTX objects.

In OpenSSL 1.1.x there is an X509_STORE_up_ref() function.  In OpenSSL 1.0.2,
you can do that directly via:

   CRYPTO_add(>references, 1, CRYPTO_LOCK_X509_STORE);

Bottom line, you need to figure out the life-cycle of the object, and ensure
that reference counts are properly maintained.

-- 
Viktor.

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

Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

[Salz, Rich via openssl-users]

>My point was about the likelihood of last-draft browsers lingering
on in the real world for some time (like 1 to 3 years) after the
TLS1.3-final browser versions ship.

I do not think this is a concern.  Chrome and FF auto-update and get almost 
full coverage within a month or two, for example.  Edge hasn't shipped TLS 1.3 
yet. Safari encourages auto-update.  That's most of the browser market.



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

Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail.

[Paras Shah (parashah) via openssl-users]

Sure. I will open the issue.

From: Nicola 
Date: Monday, September 17, 2018 at 10:05 PM
To: "Paras Shah (parashah)" , "openssl-users@openssl.org" 

Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys 
fail.

Would it be possible for you to open this as an issue on Github and include 
there your first email and the full logs?

Thanks,

Nicola Tuveri

On Tue, 18 Sep 2018 at 01:15, Paras Shah (parashah) via openssl-users 
mailto:openssl-users@openssl.org>> wrote:

That is not it. It results in the same error for the EC key.



It is not the URL or the ID. Because for a RSA key in the softhsm with id = 
, it works fine with url containing id=%33%33



$ openssl pkey -in 
"pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%33%33;object=rsa%20key;type=private"
 -engine pkcs11 -inform ENGINE

engine "pkcs11" set.

Enter PKCS#11 token PIN for token 2.5.0-rc1:

-BEGIN PRIVATE KEY-

MIIBJwIBADANBgkqhkiG9w0BAQEFAASCAREwggENAgEAAoIBAQDD3378F1XbXJvP

WP2GtZry0u6sL3eNYktQwJfhDMz5evDG+PahVjCMszV5CZvG+Kvap40xPBJoonqi

oMAQsoLu7/fTx82aEL3TbdjXNLFnQ2KKYmfG9ymx80sLHMmdmDXpNNE+bEKJz1dp

t1Q0cVduwmqSfB8JyIE6Udz7JX7HCXaVmxoK7z4Njh3dyHsqhdqKIx0dBuK0hCaq

4zPzGP/sORA3G9ZPxxpEvF3gvE/zsXj7ifihqbqr2eIFOpB/lQqAehsgQT5/6Iq+

9pAX2LCxNkaUHYYZpMkM8Oi37jzg8PX/FnHdm9HQU2IBqYhoqo7/VsNdUDln2QHN

dGAUprcbAgMBAAE=

-END PRIVATE KEY-



Coming back to EC key, looking at the error logs emitted, it does seem to 
recognize it to be EC (the logs contain EC_routines) somehow but then fails.



On 9/17/18, 2:22 PM, "openssl-users on behalf of Richard Levitte" 
mailto:openssl-users-boun...@openssl.org> on 
behalf of levi...@openssl.org> wrote:



In message 
<4ac69fc3-bec7-46f6-882a-671196fc0...@contoso.com>
 on Mon, 17 Sep 2018 20:59:59 +, "Paras Shah (parashah)" 
mailto:paras...@cisco.com>> said:



> 4. Import the key into softhsm

>

> []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec 
key" --id  --token

> "token 2.5.0-rc1"



Ok, so here, the ID is ""



> 5. Get the pkcs11 url for the private key

>

> []:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so 
--set-pin= --list-all

>

> Object 0:

>

> URL:

> 
pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private



But here, the ID is "%11%11", and since those get percent decoded,

that's actually two vertical tabs, or with C vector syntax,

{ 0x0b, 0x0b }



I'm not sure what engine-pkcs11 asks of you otherwise, but one guess

could be to change 'id=%11%11' to 'id=' in that URL and try again.



Cheers,

Richard



--

Richard Levitte levi...@openssl.org

OpenSSL Project http://www.openssl.org/~levitte/

--

openssl-users mailing list

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


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

Re: [openssl-users] OpenSSL 1.1 X509_STORE sharing

[Viktor Dukhovni]

> On Sep 18, 2018, at 12:30 PM, Maxwell Dreytser  wrote:
> 
>> X509_STORE_free() decrements a reference count, and frees the object only
>> when the count reaches zero.
>> 
> Was this behavior the same in older versions?

Yes.

> If so, then there is no reason to clear cert_store even in older version, 
> right?

That depends on whether setting the cert_store element was done properly (in a 
way
that incremented the reference count) or not.  See the documentation of:

SSL_CTX_set1_cert_store(3)
SSL_CTX_set_cert_store(3)

the latter does not facilitate sharing the store across multiple SSL_CTX 
instances.

-- 
Viktor.

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

Re: [openssl-users] Limit the number of AES-GCM keys allowed in TLS

[Salz, Rich via openssl-users]

This is factually incorrect; the TLS values are lower than the FIPS values, for 
example.  And also, what “everyone in the know” has always stated isn’t really 
true any more.

It would be nice to keep politics out of this list.

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

Re: [openssl-users] OpenSSL 1.1 X509_STORE sharing

[Viktor Dukhovni]

> On Sep 18, 2018, at 12:12 PM, ad...@mdtech.us wrote:
> 
> I have some legacy code that I am updating for 1.1 and there they set 
> SSL_CTX::cert_store to NULL before `SSL_CTX_free`. Is this neccessary for the 
> X509_STORE to be shared between contexts?
> Note that this still has to be buildable on 1.0 with the same result.
> In the docs it says "X509_STORE_free() frees up a single X509_STORE object." 
> Does it just decrease the reference count or does it really delete the whole 
> thing and break other contexts?

X509_STORE_free() decrements a reference count, and frees the object only
when the count reaches zero.

-- 
Viktor.

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

[openssl-users] OpenSSL 1.1 X509_STORE sharing

[admin]

Hello,

I have some legacy code that I am updating for 1.1 and there they set 
SSL_CTX::cert_store to NULL before `SSL_CTX_free`. Is this neccessary 
for the X509_STORE to be shared between contexts?

Note that this still has to be buildable on 1.0 with the same result.
In the docs it says "X509_STORE_free() frees up a single X509_STORE 
object." Does it just decrease the reference count or does it really 
delete the whole thing and break other contexts?


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

Re: [openssl-users] DTLS-over-UDP client example

[aleksandr . derevianko]

Hello !

>>
>>  With such list it works, but without encoding (data send in cleartext, 
>> connection established as Cipher: NULL-SHA)
>>
>>  and if I remove eNULL on client side, it doesn't connect - server wait 
>> repeat of client cookue forever.
>>
>>  At the same time, "openssl s_client -dtls1 ..." connects fine, with Cipher: 
>> AES256-SHA
>
> Then debug why the server is ignoring the client request.
> OpenSSL has good debug output, in worst case add new prints...
>

Actually, I have traced it to ClientHello cookie exchange: test client connects 
to server, server calls generate_cookie() and never calls verify_cookie().

If I connect to test server using openssl s_client - server calls both 
generate_cookie() and verify_cookie(), and connection establishes.

If I return eNULL back in client ciphers list, server do not call  
generate_cookie(), and connection went OK.

If I comment out SSL_CTX_set_cookie_generate_cb() on server side, it still 
doesn't connect using test client but still connectes using openssl s_client.

-- 
Александр Деревянко/Aleksander Derevianko
Нач. отдела новых аппаратно-программных средств
Бомбардье Транспортейшн (Сигнал)/Bombardier Transportation (Signal) Ltd.
T:   +74959255370 Доб. 265
M: +79859229755

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

Re: [openssl-users] DTLS-over-UDP client example

[Richard Weinberger]

On Tue, Sep 18, 2018 at 9:18 AM 
wrote:> Unfortunelly, it's exactly this example which I use. You have
pointed on slightly different version,
> but all difference is:
>
> SSL_CTX_set_cookie_verify_cb(ctx, _cookie);
> instead of
> SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie);
>
> ctx = SSL_CTX_new(DTLS_client_method());
> instead of
> ctx = SSL_CTX_new(DTLSv1_client_method());
>
>
> I have tryed it, works exactly the same.
>
> In both versions, on client side cipher_list is:
> SSL_CTX_set_cipher_list(ctx, "eNULL:!MD5");
>
> With such list it works, but without encoding (data send in cleartext, 
> connection established as  Cipher: NULL-SHA)
>
> and if I remove eNULL on client side, it doesn't connect - server wait repeat 
> of client cookue forever.
>
> At the same time,  "openssl s_client -dtls1   ..." connects fine, with 
> Cipher: AES256-SHA

Then debug why the server is ignoring the client request.
OpenSSL has good debug output, in worst case add new prints...

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

Re: [openssl-users] DTLS-over-UDP client example

[aleksandr . derevianko]

Hello !

17.09.2018, 16:26, "Richard Weinberger" :
> On Thu, Sep 13, 2018 at 3:51 PM  wrote:
>>  I tryed to dig inside openssl s_client source code, but it's really too 
>> complex for me, it seems like s_client doesn't use
>>  SSL_connect, instead, using more low-level functions.
>>
>>  So, does anybody have any simple client-side implementation of DTLS over 
>> UDP connection?
>
> https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c
> ... is a good example.

Unfortunelly, it's exactly this example which I use. You have pointed on 
slightly different version,
but all difference is: 

SSL_CTX_set_cookie_verify_cb(ctx, _cookie);
instead of 
SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie);

ctx = SSL_CTX_new(DTLS_client_method());
instead of 
ctx = SSL_CTX_new(DTLSv1_client_method());


I have tryed it, works exactly the same.

In both versions, on client side cipher_list is:
SSL_CTX_set_cipher_list(ctx, "eNULL:!MD5");

With such list it works, but without encoding (data send in cleartext, 
connection established as  Cipher: NULL-SHA)

and if I remove eNULL on client side, it doesn't connect - server wait repeat 
of client cookue forever. 

At the same time,  "openssl s_client -dtls1   ..." connects fine, with Cipher: 
AES256-SHA

>
> In case you are on 1.1.x, please also see:
> https://mta.openssl.org/pipermail/openssl-users/2018-August/008498.html
>
> OpenSSL badly regressed in 1.1.x wrt. DTLS.
>

Actually, I use openssl-1.0.2o_2,1
Also, this "regression" is for multy-threaded server, not for single-threaded 
client.


-- 
Александр Деревянко/Aleksander Derevianko
Нач. отдела новых аппаратно-программных средств
Бомбардье Транспортейшн (Сигнал)/Bombardier Transportation (Signal) Ltd.
T:   +74959255370 Доб. 265
M: +79859229755

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

Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

[Jakob Bohm]

On 15/09/2018 10:46, Kurt Roeckx wrote:

On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote:

On 13/09/2018 09:57, Klaus Keppler wrote:

Hi,

thank you for all your responses.

I've just tested with Firefox Nightly 64.0a1, and both s_server and our
own app (using OpenSSL 1.1.1-release) are working fine.

The Firefox website is quite confusing:


Firefox 61 is already shipping draft-28, which is essentially the same as the 
final published version (just with a different version number).

(https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/)

This is quite confusing, as it sounds better than it actually is.
(so I've just learned that draft-28 is obviously incompatible with RFC8446)

So thank you for your input, will now continue with OpenSSL 1.1.1.
The rest will be only a matter of time. :D

Best regards

 -Klaus

Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be
removed again in a few years) to accept the draft version number of final
TLS 1.3, if the protocols are otherwise identical?

Draft versions really should die as soon as possible. If we ever put
it in a released version, it will still be in use in 10 years,
which really isn't something we want.

On the other hand, in a few weeks browsers will stop using those
draft versions, so I really don't see the point.

My point was about the likelihood of last-draft browsers lingering
on in the real world for some time (like 1 to 3 years) after the
TLS1.3-final browser versions ship.  The inspiration was the report
that facebook had done this on their own servers, presumably based
on their massive metrics of real world browsers.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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