Re: [openssl-users] X25519 not listed in ecparam -list_curves

[Dr. Stephen Henson]

On Mon, Nov 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

> As "-list-curves" is not supposed to work here, what would be a good way to 
> tell if a given installation supports X25519?
> 

Well only OpenSSL 1.1.0 currently supports X25519. One way is to look at
the output of:

openssl list -public-key-algorithms

Though that command doesn't exist before OpenSSL 1.1.0. Alternatively just
generate a private key with:

openssl genpkey -algorithm X25519

Which will work in OpenSSL 1.1.0 but give an error in previous versions.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] C++ : Extracting CRL from a PKCS12

[Richard Stanek]

Thanks for looking at this.  I was insisting that nobody (in practice)
puts CRLs inside of a PKCS12.  Nobody does that...  I could find no
evidence that this is ever done, nor was there any support for this
deviant behavior.  ;-)

I was handed a specification to implement that had CRLs inside of
PKCS12.  From the beginning, I doubted the writers of that
specification knew what they were doing.  And I expect that they don't
have any test data, either.

Over the last few days, I had being doing exactly what you suggested,
a messy manual parsing process.  I have achieved success in building a
PKCS12 with CRLs and success in parsing that PKCS12.

Again, thanks for looking at this and validating what I have been
thinking and feeling about putting CRLs into PKCS12s.
-Rick




On Mon, Nov 14, 2016 at 2:11 PM, Dr. Stephen Henson  wrote:
> On Wed, Nov 02, 2016, Richard Stanek wrote:
>
>> My original requirements were to extract the user certificate, the
>> private key, and the CAs.  For that I was using the call to
>> PKCS12_parse(...).  This satisfied the original requirements.  Very
>> easy to find, understand, and use.
>>
>> The new requirements that I have are that I also need to extract a CRL
>> from that PKCS12.  I see that there is a CRLBag defined in the IETF
>> RFC 7292 PKCS12 Standard (https://tools.ietf.org/html/rfc7292), so I
>> know a CRL could exist inside a PKCS12.  I can't seem to find any API
>> or C++ examples that extract a CRL from a PKSC12.
>>
>> Is there an API, example code, or advice on how to extract a CRL from a 
>> PKCS12?
>>
>
> I've never come across a PKCS#12 file containig a CRL before: would it be
> possible to send me a sample which obviously doesn't contain any important
> private keys.
>
> To answer your question, yes it is should be possible but it is messy. You
> need to parse the PKCS#12 file manually (see source to PKCS12_parse). In
> the funtion parse_bag you add an extra case for NID_crlBag and call
> PKCS12_SAFEBAG_get1_crl() on the bag, you should then get back an X509_CRL
> pointer or NULL on error.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> 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] X25519 not listed in ecparam -list_curves

[Blumenthal, Uri - 0553 - MITLL]

As "-list-curves" is not supposed to work here, what would be a good way to 
tell if a given installation supports X25519?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Dr. Stephen Henson
Sent: Monday, November 14, 2016 15:02
To: openssl-users@openssl.org
Reply To: openssl-users@openssl.org
Subject: Re: [openssl-users] X25519 not listed in ecparam -list_curves
‎
On Fri, Nov 04, 2016, Viktor J?gersk?pper wrote:

> Hi,
> 
> OpenSSL 1.1.0 implemented X25519. "openssl s_client -cipher kEECDH
> -curves X25519 -connect google.com:443" works as expected, and I get
> "Server Temp Key: X25519, 253 bits". But X25519 is not listed in the
> output of "openssl ecparam -list_curves" in version 1.1.0b (I use
> 1.1.0b-2 from Debian). Should it be listed there anyway?
> 
‎
The ecparam operation lists curves supported by the EC* API. The X25519 curve
(for various reasons defined in the standards) is treated as a distinct
algorithm so it is not listed by ecparam.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] C++ : Extracting CRL from a PKCS12

[Dr. Stephen Henson]

On Wed, Nov 02, 2016, Richard Stanek wrote:

> My original requirements were to extract the user certificate, the
> private key, and the CAs.  For that I was using the call to
> PKCS12_parse(...).  This satisfied the original requirements.  Very
> easy to find, understand, and use.
> 
> The new requirements that I have are that I also need to extract a CRL
> from that PKCS12.  I see that there is a CRLBag defined in the IETF
> RFC 7292 PKCS12 Standard (https://tools.ietf.org/html/rfc7292), so I
> know a CRL could exist inside a PKCS12.  I can't seem to find any API
> or C++ examples that extract a CRL from a PKSC12.
> 
> Is there an API, example code, or advice on how to extract a CRL from a 
> PKCS12?
> 

I've never come across a PKCS#12 file containig a CRL before: would it be
possible to send me a sample which obviously doesn't contain any important
private keys.

To answer your question, yes it is should be possible but it is messy. You
need to parse the PKCS#12 file manually (see source to PKCS12_parse). In
the funtion parse_bag you add an extra case for NID_crlBag and call
PKCS12_SAFEBAG_get1_crl() on the bag, you should then get back an X509_CRL
pointer or NULL on error.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X25519 not listed in ecparam -list_curves

[Dr. Stephen Henson]

On Fri, Nov 04, 2016, Viktor J?gersk?pper wrote:

> Hi,
> 
> OpenSSL 1.1.0 implemented X25519. "openssl s_client -cipher kEECDH
> -curves X25519 -connect google.com:443" works as expected, and I get
> "Server Temp Key: X25519, 253 bits". But X25519 is not listed in the
> output of "openssl ecparam -list_curves" in version 1.1.0b (I use
> 1.1.0b-2 from Debian). Should it be listed there anyway?
> 

The ecparam operation lists curves supported by the EC* API. The X25519 curve
(for various reasons defined in the standards) is treated as a distinct
algorithm so it is not listed by ecparam.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Facing issues with dynamic loading engine RSA methods using e_capi.so library in openssl-1.1.0b.

[Richard Levitte]

What do you get from this command?

ldd ../engines/capi.so?

I think that the configuration example I gave you in my previous email
will also help this...

Cheers,
Richard

In message 

 on Fri, 11 Nov 2016 14:46:45 +, "Gupta, Saurabh" 
 said:

Saurabh.Gupta> I tried to dynamically load e_capi.so engine example on openssl
Saurabh.Gupta> version 1.1.0b present in the openssl engine directory but not 
able to
Saurabh.Gupta> offload RSA methods.
Saurabh.Gupta> 
Saurabh.Gupta> Commands Used:
Saurabh.Gupta> (i)
Saurabh.Gupta> ./openssl speed rsa -engine ../engines/capi.so
Saurabh.Gupta> Error:
Saurabh.Gupta> speed: Unknown algorithm -engine
Saurabh.Gupta> 
Saurabh.Gupta> (ii)
Saurabh.Gupta> ./openssl s_server -engine ../engines/capi.so
Saurabh.Gupta> Error:
Saurabh.Gupta> invalid engine "../engines/capi.so"
Saurabh.Gupta> 139890999146240:error:25066067:DSO support 
routines:dlfcn_load:could
Saurabh.Gupta> not load the shared library:crypto/dso/dso_dlfcn.c:113:filename
Saurabh.Gupta> (/usr/local/lib64/engines-1.1/../engines/capi.so):
Saurabh.Gupta> /usr/local/lib64/engines-1.1/../engines/capi.so: cannot open 
shared
Saurabh.Gupta> object file: No such file or directory
Saurabh.Gupta> 139890999146240:error:25070067:DSO support 
routines:DSO_load:could not
Saurabh.Gupta> load the shared library:crypto/dso/dso_lib.c:161:
Saurabh.Gupta> 139890999146240:error:260B6084:engine routines:dynamic_load:dso 
not
Saurabh.Gupta> found:crypto/engine/eng_dyn.c:414:
Saurabh.Gupta> 139890999146240:error:2606A074:engine routines:ENGINE_by_id:no 
such
Saurabh.Gupta> engine:crypto/engine/eng_list.c:339:id=../engines/capi.so
Saurabh.Gupta> 139890999146240:error:260B606D:engine routines:dynamic_load:init
Saurabh.Gupta> failed:crypto/engine/eng_dyn.c:485:
Saurabh.Gupta> Using default temp DH parameters
Saurabh.Gupta> ACCEPT
Saurabh.Gupta> 
Saurabh.Gupta> We are facing similar issue with RSA while implementing our 
custom
Saurabh.Gupta> engine, please let me know if any one have a solution for this. 
We
Saurabh.Gupta> were able to use the RSA implementation upto 1.02h version, the
Saurabh.Gupta> problem is seen 1.1.0 series.
Saurabh.Gupta> 
Saurabh.Gupta> Regards,
Saurabh.Gupta> Saurabh
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Failed to load libssl.so.1.1 while execuitng openssl comand

[Richard Levitte]

In message 

 on Fri, 11 Nov 2016 14:46:23 +, "Gupta, Saurabh" 
 said:

Saurabh.Gupta> I tried to execute ./openssl s_server command in the latest 
Openssl
Saurabh.Gupta> Version 1.1.0c after doing Openssl compilation steps:
Saurabh.Gupta> ./config
Saurabh.Gupta> make
Saurabh.Gupta> make test
Saurabh.Gupta> make install
Saurabh.Gupta> and It's throwing this error below:
Saurabh.Gupta> ./openssl: error while loading shared libraries: libssl.so.1.1: 
cannot
Saurabh.Gupta> open shared object file: No such file or directory
Saurabh.Gupta> 
Saurabh.Gupta> after debugging this issue I found this error is coming because
Saurabh.Gupta> libssl.so.1.1 is not present in /usr/lib64 directory.
Saurabh.Gupta> but by default it should search these library in 
/usr/local/lib64/
Saurabh.Gupta> directory.

Is that on Linux?  Configure like this:

./config -Wl,--enable-new-dtags,-rpath,'$(LIBRPATH)'

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

Re: [openssl-users] Increasing the server write buffer for handshakes in 1.1.0

[Matt Caswell]

On 14/11/16 13:37, Brandon Black wrote:
> On Mon, Nov 14, 2016 at 10:04 AM, Matt Caswell  wrote:
>> During the handshake phase OpenSSL adds a buffering BIO in front of the
>> wbio. However when you call SSL_get_wbio(), you get back the *real* wbio
>> (without the bbio on the front). This is a change of behaviour between
>> 1.1.0 and 1.0.2, and was because it was considered a bug that you could
>> get back a different wbio from SSL_get_wbio() than the one that you
>> originally set!
>>
>> So calling BIO_set_write_buffer_size() on the return from SSL_get_wbio()
>> is going to make no difference at all!
>>
>> Unfortunately, I don't think there *is* a way to get the bbio in 1.1.0.
>> I would certainly consider a pull request to add an accessor to get hold
>> of it (missing accessors are considered as bug-fixes and so would be
>> eligible for inclusion in a future 1.1.0d).
> 
> It would be pretty trivial to implement SSL_get_bbio(), and then we
> could patch up nginx to use it at the appropriate time (assuming
> CB_ACCEPT_LOOP is still the appropriate time - I haven't tried yet).
> But from an API usability standpoint for server implementation, this
> whole way of dealing with things seems pretty un-intuitive.
> 
> Perhaps there should be SSL-level APIs for setting the write buffer
> size before the handshaking code is entered?
> SSL_set_write_buffer_size() intended to be used shortly after
> SSL_new(), but before handshaking begins, and
> SSL_CTX_set_write_buffer_size() to set the default inherited by
> SSL_new().  The implementation details of the buffer would then be
> more-opaque, and when the bbio is first initialized it can be sized
> appropriately from the parameter set by those functions and stored in
> ssl_session_st.

That would be good too, although that would be counted as a feature, not
a bug fix so couldn't be in 1.1.0 (1.1.1 earliest). Perhaps we do
both...again I'd be happy to look at PRs in this area.

Matt

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

Re: [openssl-users] Increasing the server write buffer for handshakes in 1.1.0

[Brandon Black]

On Mon, Nov 14, 2016 at 10:04 AM, Matt Caswell  wrote:
> During the handshake phase OpenSSL adds a buffering BIO in front of the
> wbio. However when you call SSL_get_wbio(), you get back the *real* wbio
> (without the bbio on the front). This is a change of behaviour between
> 1.1.0 and 1.0.2, and was because it was considered a bug that you could
> get back a different wbio from SSL_get_wbio() than the one that you
> originally set!
>
> So calling BIO_set_write_buffer_size() on the return from SSL_get_wbio()
> is going to make no difference at all!
>
> Unfortunately, I don't think there *is* a way to get the bbio in 1.1.0.
> I would certainly consider a pull request to add an accessor to get hold
> of it (missing accessors are considered as bug-fixes and so would be
> eligible for inclusion in a future 1.1.0d).

It would be pretty trivial to implement SSL_get_bbio(), and then we
could patch up nginx to use it at the appropriate time (assuming
CB_ACCEPT_LOOP is still the appropriate time - I haven't tried yet).
But from an API usability standpoint for server implementation, this
whole way of dealing with things seems pretty un-intuitive.

Perhaps there should be SSL-level APIs for setting the write buffer
size before the handshaking code is entered?
SSL_set_write_buffer_size() intended to be used shortly after
SSL_new(), but before handshaking begins, and
SSL_CTX_set_write_buffer_size() to set the default inherited by
SSL_new().  The implementation details of the buffer would then be
more-opaque, and when the bbio is first initialized it can be sized
appropriately from the parameter set by those functions and stored in
ssl_session_st.

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

Re: [openssl-users] Increasing the server write buffer for handshakes in 1.1.0

[Matt Caswell]

On 12/11/16 16:29, Brandon Black wrote:
> Hi all,
> 
>   I'm running into an issue where if the server handshake response
> exceeds some value a little over 4K (which is pretty easy these days
> with a typical public cert, intermediate, and stapled OCSP response),
> we're suffering an extra RTT in our SSL negotiations with
> OpenSSL-1.1.0 (vs 1.0.2).  The server software is nginx.  You can see
> our internal ticket with more detail at:
> https://phabricator.wikimedia.org/T150561 .
> 
> This same issue was already raised and fixed with nginx years ago
> against older OpenSSL versions in
> https://trac.nginx.org/nginx/ticket/413 .
> 
> I suspect the workaround implemented at the time (which is obviously
> not an ideal use of the APIs to begin with, with that wbio vs rbio
> pointer comparison...) no longer works for 1.1.0.  I've tried
> unconditionally calling BIO_set_write_buffer_size() in the same
> callback as well, but it didn't improve the situation.

During the handshake phase OpenSSL adds a buffering BIO in front of the
wbio. However when you call SSL_get_wbio(), you get back the *real* wbio
(without the bbio on the front). This is a change of behaviour between
1.1.0 and 1.0.2, and was because it was considered a bug that you could
get back a different wbio from SSL_get_wbio() than the one that you
originally set!

So calling BIO_set_write_buffer_size() on the return from SSL_get_wbio()
is going to make no difference at all!

Unfortunately, I don't think there *is* a way to get the bbio in 1.1.0.
I would certainly consider a pull request to add an accessor to get hold
of it (missing accessors are considered as bug-fixes and so would be
eligible for inclusion in a future 1.1.0d).

Matt




> 
> Is there an appropriate way to use the API to work around the write
> buffer limit at handshake time for a server application with 1.1.0,
> that we could patch up nginx with?
> 
> Another alternative would be to raise the default buffer size to 8K to
> be more reflective of modern conditions.  I've made such a commit at
> https://github.com/blblack/openssl/commit/5c3f1e46b61db591ea61d560ee51535286afa1a4
> , but I haven't filed a pull request yet as I'm unsure on a couple of
> fronts here:
> 
> (1) Whether there's an easier answer for server software developers
> within the existing APIs (the main question in this post)
> 
> (2) With the default also currently being reused as the minimum
> possible buffer size, I'm not sure whether it would be acceptable to
> raise the minimum to 8K as well when changing the default. Splitting
> the two would be a bit more invasive.
> 
> 
> Thanks,
> -- Brandon
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users