Re: [openssl-dev] cert_cb and TLS tickets

[Fedor Indutny]

Alessandro,

Indeed I just checked BoringSSL's source and it calls cert_cb before
resuming the session. Inviting David Benjamin into this conversation.

David,

Do you have any insights or motivation to share with us? The way BoringSSL
handles session resumption + cert_cb is a correct one in my opinion, and
I'm trying to persuade everyone here in this too :)

Thank you,
Fedor.

On Sat, Dec 10, 2016 at 2:35 PM, Alessandro Ghedini 
wrote:

> On Sat, Dec 10, 2016 at 11:13:48AM +0100, Fedor Indutny wrote:
> > This totally makes sense. Unfortunately, adding a new API method for this
> > means that I'll have to re-introduce ClientHello parser in bud, and make
> a
> > wider use of it in Node.js again.
>
> FWIW, BoringSSL offers an early callback that is passed a semi-parsed CH,
> and
> an API to extract specific extensions from it (though this returns the raw
> unparsed extension body). Something similar could be adopted for OpenSSL.
>
> Whether this should be called in the CH post process phase (immediately
> before
> cert_cb) or much earlier (like BoringSSL) is likely to affect the
> implementation
> though (e.g. I'm not sure if the CH buffer is still available in the post
> process).
>
> Might be worth noting that BoringSSL changed the CH processing recently, by
> moving the session resumption logic after cert_cb, which means cert_cb is
> now
> called every time, but without a SSL_SESSION being available. So calling
> the
> cert_cb unconditionally is not unheard of.
>
> Cheers
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cert_cb and TLS tickets

[Fedor Indutny]

Thank you for feedback, though!

On Sat, Dec 10, 2016 at 11:13 AM, Fedor Indutny  wrote:

> This totally makes sense. Unfortunately, adding a new API method for this
> means that I'll have to re-introduce ClientHello parser in bud, and make a
> wider use of it in Node.js again.
>
> On Sat, Dec 10, 2016 at 3:07 AM, Salz, Rich  wrote:
>
>> > Oh, just to restate it. I'm willing to submit the patch if we agree on
>> what exactly it should do.
>>
>>
>>
>> Might want to wait a bit.  TLS 1.3 handshakes are a bit different.
>>
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cert_cb and TLS tickets

[Fedor Indutny]

This totally makes sense. Unfortunately, adding a new API method for this
means that I'll have to re-introduce ClientHello parser in bud, and make a
wider use of it in Node.js again.

On Sat, Dec 10, 2016 at 3:07 AM, Salz, Rich  wrote:

> > Oh, just to restate it. I'm willing to submit the patch if we agree on
> what exactly it should do.
>
>
>
> Might want to wait a bit.  TLS 1.3 handshakes are a bit different.
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cert_cb and TLS tickets

[Fedor Indutny]

Oh, just to restate it. I'm willing to submit the patch if we agree on what
exactly it should do.

On Fri, Dec 9, 2016 at 11:29 PM, Fedor Indutny  wrote:

> Hello Benjamin,
>
> On Fri, Dec 9, 2016 at 11:24 PM, Benjamin Kaduk  wrote:
>
>> On 12/09/2016 01:43 PM, Fedor Indutny wrote:
>>
>> Hello,
>>
>> During development of one feature for my TLS proxy bud, I have discovered
>> that the cert_cb is invoked only for newly generated tickets/sessions. The
>> reasoning behind this is clear, but I believe that it is most likely needs
>> a revision. Here is my reasoning:
>>
>> The major use case is choosing a certificate/private key either
>> dynamically (based on various parameters of SSL structure) or
>> asynchronously (by using SSL_ERROR_WANT_X509_LOOKUP). However when the
>> TLS ticket is provided by the client, it will be parsed and loaded using
>> the ticket key from the main context, without giving a way for application
>> to override it for particular servername (from SNI). Furthermore, with the
>> TLS ticket provided application can no longer chose to provide a different
>> certificate in case of expiration or revocation.
>>
>>
>> If you had a callback that ran before session resumption (possibly the
>> existing SNI callback, possibly a new callback), would that allow you to
>> solve your problem?  I would very much like to see such an early callback
>> so as to be able to do SNI processing before resumption, possibly even
>> before version negotiation.  (And yes, I should put my money where my mouth
>> is and come up with a patch.)
>>
>
> That's exactly what I am asking for. Putting it before session resumption
> will be enough for my use case, though.
>
> Thank you,
> Fedor.
>
>
>>
>> -Ben
>>
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cert_cb and TLS tickets

[Fedor Indutny]

Hello Benjamin,

On Fri, Dec 9, 2016 at 11:24 PM, Benjamin Kaduk  wrote:

> On 12/09/2016 01:43 PM, Fedor Indutny wrote:
>
> Hello,
>
> During development of one feature for my TLS proxy bud, I have discovered
> that the cert_cb is invoked only for newly generated tickets/sessions. The
> reasoning behind this is clear, but I believe that it is most likely needs
> a revision. Here is my reasoning:
>
> The major use case is choosing a certificate/private key either
> dynamically (based on various parameters of SSL structure) or
> asynchronously (by using SSL_ERROR_WANT_X509_LOOKUP). However when the
> TLS ticket is provided by the client, it will be parsed and loaded using
> the ticket key from the main context, without giving a way for application
> to override it for particular servername (from SNI). Furthermore, with the
> TLS ticket provided application can no longer chose to provide a different
> certificate in case of expiration or revocation.
>
>
> If you had a callback that ran before session resumption (possibly the
> existing SNI callback, possibly a new callback), would that allow you to
> solve your problem?  I would very much like to see such an early callback
> so as to be able to do SNI processing before resumption, possibly even
> before version negotiation.  (And yes, I should put my money where my mouth
> is and come up with a patch.)
>

That's exactly what I am asking for. Putting it before session resumption
will be enough for my use case, though.

Thank you,
Fedor.


>
> -Ben
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cert_cb and TLS tickets

[Fedor Indutny]

On Fri, Dec 9, 2016 at 11:13 PM, Viktor Dukhovni  wrote:

> On Fri, Dec 09, 2016 at 09:47:19PM +0100, Fedor Indutny wrote:
>
> > > The callback is *correctly* only called when choosing the server
> > > certificate.  In *that* case, it is always called.  When sessions
> > > are resumed, there is no certificate to present, so no callback is
> > > made.
> >
> > That's why I said that the intended logic is clear. However, this
> > implementation makes the API unusable in at least one case. Even more,
> > there are no alternatives to this API, meaning that there is no other way
> > to delay certificate/key/context selection. Clearly this is the case for
> > which the API was created.
>
> Resumed sessions don't select any certificates, so it makes no
> sense to invoke certificate selection callbacks.
>

The problem with ticket keys is that they are assigned globally and there
is no way to control what's happening independently in asynchronous manner.
Thus API looks a bit odd: on one hand OpenSSL allows selecting certs
asynchronously, on other hand TLS tickets are going to be processed
synchronously anyway.


>
> > Ticket rotation is already possible in both bud and node.js and is
> > completely unrelated to this issue. Even with ticket rotation valid
> tickets
> > will cause asynchronous SNI lookups to be skipped.
>
> If you deny the key id, then a new session will be negotiated, and
> certificate selection callbacks will be invoked.
>

This means disabling TLS ticket keys for both bud and node.js . It is
possible, but will hurt performance significantly.


>
> > However, when valid TLS ticket is received - OpenSSL will skip the
> > `cert_cb` and will just do regular handshake as no `cert_cb` was set.
> This
> > breaks balancing and OCSP stapling fetching, which are major use cases
> for
> > both bud and node.js (which can do all of this too through external
> > modules).
>
> There is no OCSP with resumed sessions, no certificates are sent
> by the server or checked by the client.  If you want certificates,
> don't do session resumption.
>
> OpenSSL is behaving correctly.  This is a fundamental feature of TLS.
>

While I agree about OCSP, I don't see how this fundamental feature helps in
backend selection case. Clearly it is impossible to choose backends
dynamically with such reduced API implementation.

All in all, what I am asking for is an internal change that will still
adhere to the documentation. There is no fundamental feature of TLS that
could prohibit this.



>
> --
> Viktor.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cert_cb and TLS tickets

[Fedor Indutny]

Hello Viktor!

Replying inline.

On Fri, Dec 9, 2016 at 9:28 PM, Viktor Dukhovni 
wrote:

> On Fri, Dec 09, 2016 at 08:43:01PM +0100, Fedor Indutny wrote:
>
> > During development of one feature for my TLS proxy bud, I have discovered
> > that the cert_cb is invoked only for newly generated tickets/sessions.
> The
> > reasoning behind this is clear, but I believe that it is most likely
> needs
> > a revision. Here is my reasoning:
>
> The callback is *correctly* only called when choosing the server
> certificate.  In *that* case, it is always called.  When sessions
> are resumed, there is no certificate to present, so no callback is
> made.
>


That's why I said that the intended logic is clear. However, this
implementation makes the API unusable in at least one case. Even more,
there are no alternatives to this API, meaning that there is no other way
to delay certificate/key/context selection. Clearly this is the case for
which the API was created.


>
> > Furthermore, with the TLS ticket provided
> > application can no longer chose to provide a different certificate in
> case
> > of expiration or revocation.
>
> You can implement a ticket key callback that when appropriate, will
> decline tickets under suitable conditions, in which case a full
> handshake will be performed.
>
> Custom ticket callbacks that do session ticket key rotation are a
> good idea in any case, the default tickets are not rotated, which
> is not apppropriate for long-running processes.
>
>
Ticket rotation is already possible in both bud and node.js and is
completely unrelated to this issue. Even with ticket rotation valid tickets
will cause asynchronous SNI lookups to be skipped.

Let me put this into real example. "bud" does SNI balancing and
asynchronous OCSP stapling. When there are no tickets - it will connect to
some HTTP backend to fetch certificate, key, and list of cleartext
backends. It will also asynchronously fetch OCSP response from either
remote cache or OCSP authority.

However, when valid TLS ticket is received - OpenSSL will skip the
`cert_cb` and will just do regular handshake as no `cert_cb` was set. This
breaks balancing and OCSP stapling fetching, which are major use cases for
both bud and node.js (which can do all of this too through external
modules).

Hope this clarifies things a bit,
Fedor.


> --
> Viktor.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] cert_cb and TLS tickets

[Fedor Indutny]

Hello,

During development of one feature for my TLS proxy bud, I have discovered
that the cert_cb is invoked only for newly generated tickets/sessions. The
reasoning behind this is clear, but I believe that it is most likely needs
a revision. Here is my reasoning:

The major use case is choosing a certificate/private key either dynamically
(based on various parameters of SSL structure) or asynchronously (by
using SSL_ERROR_WANT_X509_LOOKUP). However when the TLS ticket is provided
by the client, it will be parsed and loaded using the ticket key from the
main context, without giving a way for application to override it for
particular servername (from SNI). Furthermore, with the TLS ticket provided
application can no longer chose to provide a different certificate in case
of expiration or revocation.

The documentation says:

"It is B called even is a certificate is already set so the callback
can modify or delete the existing certificate."

Additionally, when talking about things allowed in `cert_cb`:

"An application will typically call SSL_use_certificate() and
SSL_use_PrivateKey() to set the end entity certificate and private key.
It can add intermediate and optionally the root CA certificates using
SSL_add1_chain_cert()."

It only says that it is *typically* for applications to use these functions
not limiting them to set and use different secure contextes on cert_cb.
This is in fact what I've used in bud, and what we use in node.js too.

Proposal:

Invoke cert_cb before looking up session ids and parsing tls tickets. It is
a safe change, and it should be done to match intention of this API
documented in man pages.

Please let me know if I can help or work on this.

Thank you,
Fedor.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] SSL_read return error(Internet mail)

[Fedor Indutny]

Hello again,

Do you use renegotiation?

On Sat, Jul 16, 2016 at 3:09 AM, paladinchen(陈奇) 
wrote:

> Hi,
>Thank you for your replay, how to resovle this issue or avoid it
> hanppen ? when this error occur , will reconnect to server，affect normal
> use .
>
> i think it should hanppen in ssl init phase ,why it happen in normal
> data transmit phase .
>
> error log :
> Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message 
> type:s3_clnt.c:700
> --
> paladinchen(陈奇)
>
>
> *From:* openssl-dev 
> *Date:* 2016-07-16 14:02
> *To:* openssl-dev@openssl.org
> *CC:* openssl-dev 
> *Subject:* Re: [openssl-dev] SSL_read return error(Internet mail)
> Hello!
>
> It looks like the server replies with a bad data sometimes. I wonder if
> server could be speaking different protocols at such moments?
>
> Hope it helps,
> Fedor.
>
> On Sat, Jul 16, 2016 at 1:21 AM, paladinchen(陈奇) 
> wrote:
>
>> Hi ,
>> use openSSL lib run sometimes，and generate this error , i can't find
>> reason ,this issue always puzzled me
>> please help me, thank you .
>>
>> error log :
>> Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message 
>> type:s3_clnt.c:700
>>
>>
>> --
>> paladinchen(陈奇)
>>
>>
>>
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] SSL_read return error

[Fedor Indutny]

Hello!

It looks like the server replies with a bad data sometimes. I wonder if
server could be speaking different protocols at such moments?

Hope it helps,
Fedor.

On Sat, Jul 16, 2016 at 1:21 AM, paladinchen(陈奇) 
wrote:

> Hi ,
> use openSSL lib run sometimes，and generate this error , i can't find
> reason ,this issue always puzzled me
> please help me, thank you .
>
> error log :
> Error: error:14092072:SSL routines:SSL3_GET_SERVER_HELLO:bad message 
> type:s3_clnt.c:700
>
>
> --
> paladinchen(陈奇)
>
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny via RT]

On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell  wrote:

>
>
> On 05/02/16 22:42, Fedor Indutny wrote:
> > Matt,
> >
> > I have looked through the APIs. Will have to experiment with them
> > somewhen later to see how well they will perform, but from theoretical
> > point of view I am a bit scared of having 2 fds (and one ucontext) for
> > every job in a pool. It seems like this could be a bit of burden in
> > event-loop based model. For example, it is not hard to imagine a
> > situation in node.js application with 1 handshakes that are trying
> > to complete in parallel. Is there any need in creating this fds
> > unconditionally?
>
> Well of course the number of jobs in the pool is not the same as the
> number of handshakes. We create a pool of jobs that are shared between
> the handshakes as required in order to conserve resources. With regards
> to the fds, I mentioned that I was working on some tweaks to the API. It
> is in this area where there are tweaks being made. Specifically I am
> moving the creation of the fds to be a responsibility of the called code
> (i.e. most likely an engine) and not the async framework itself.
>

I understand what the pool means ;) The imaginary situation that I was
talking about had lots of handshakes happening in parallel. To make it a
bit real: a server that decrypts premaster secrets remotely with 2000ms
latency, that receives 1000 requests per second. In such situation pool
size needs to be at least 2000 to accommodate this amount of requests.

While 2000ms is a bit far-fetched, it is very easy to imagine that that
remote decrypting server will go absolutely down and won't respond at
all. Meaning that for some period of time (maybe 5-10 seconds) all this
load is going to attempt to take new job from the pool. While I'm sure that
SSL structures itself will take a huge stake in resources usage, having
extra fd for each of these jobs doesn't sound right to me.

I'm glad to hear that this fd-behavior is going to be overridable. This
sounds lovely!


>
> > However, again, this is only a hypothetical situation, I'm yet to see
> > how well it will behave in real situations. Just sharing some immediate
> > concerns with you.
>
> I have been collaborating with Intel on this piece of work and they have
> been testing the performance quite thoroughly. We are still working on
> optimising things, but so far so good.
>
>
Fantastic!

Thank you very much,
Fedor.


> Matt
>
>
> >
> > Thank you,
> > Fedor.
> >
> > On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT  > <mailto:r...@openssl.org>> wrote:
> >
> > Thank you very much, Matt, Rich.
> >
> > I will read through these docs tomorrow.
> >
> > On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT  > <mailto:r...@openssl.org>> wrote:
> >
> > >
> > >
> > > On 04/02/16 06:34, Salz, Rich via RT wrote:
> > > > It’s late and my response was incomplete.
> > > > The other part has already landed in master, and that's the
> "async
> > > engine" support.
> > >
> > > See:
> > >
> > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html
> > > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html
> (i.e.
> > > the SSL_MODE_ASYNC bit)
> > >
> https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html
> > >
> > > I'm working on a patch that may make some tweaks to this API, but
> you
> > > should get the idea.
> > >
> > > Matt
> > >
> > >
> > >
> >
> > ___
> > openssl-dev mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> >
> >
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3528
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell  wrote:

>
>
> On 05/02/16 22:42, Fedor Indutny wrote:
> > Matt,
> >
> > I have looked through the APIs. Will have to experiment with them
> > somewhen later to see how well they will perform, but from theoretical
> > point of view I am a bit scared of having 2 fds (and one ucontext) for
> > every job in a pool. It seems like this could be a bit of burden in
> > event-loop based model. For example, it is not hard to imagine a
> > situation in node.js application with 1 handshakes that are trying
> > to complete in parallel. Is there any need in creating this fds
> > unconditionally?
>
> Well of course the number of jobs in the pool is not the same as the
> number of handshakes. We create a pool of jobs that are shared between
> the handshakes as required in order to conserve resources. With regards
> to the fds, I mentioned that I was working on some tweaks to the API. It
> is in this area where there are tweaks being made. Specifically I am
> moving the creation of the fds to be a responsibility of the called code
> (i.e. most likely an engine) and not the async framework itself.
>

I understand what the pool means ;) The imaginary situation that I was
talking about had lots of handshakes happening in parallel. To make it a
bit real: a server that decrypts premaster secrets remotely with 2000ms
latency, that receives 1000 requests per second. In such situation pool
size needs to be at least 2000 to accommodate this amount of requests.

While 2000ms is a bit far-fetched, it is very easy to imagine that that
remote decrypting server will go absolutely down and won't respond at
all. Meaning that for some period of time (maybe 5-10 seconds) all this
load is going to attempt to take new job from the pool. While I'm sure that
SSL structures itself will take a huge stake in resources usage, having
extra fd for each of these jobs doesn't sound right to me.

I'm glad to hear that this fd-behavior is going to be overridable. This
sounds lovely!


>
> > However, again, this is only a hypothetical situation, I'm yet to see
> > how well it will behave in real situations. Just sharing some immediate
> > concerns with you.
>
> I have been collaborating with Intel on this piece of work and they have
> been testing the performance quite thoroughly. We are still working on
> optimising things, but so far so good.
>
>
Fantastic!

Thank you very much,
Fedor.


> Matt
>
>
> >
> > Thank you,
> > Fedor.
> >
> > On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT  > <mailto:r...@openssl.org>> wrote:
> >
> > Thank you very much, Matt, Rich.
> >
> > I will read through these docs tomorrow.
> >
> > On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT  > <mailto:r...@openssl.org>> wrote:
> >
> > >
> > >
> > > On 04/02/16 06:34, Salz, Rich via RT wrote:
> > > > It’s late and my response was incomplete.
> > > > The other part has already landed in master, and that's the
> "async
> > > engine" support.
> > >
> > > See:
> > >
> > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html
> > > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html
> (i.e.
> > > the SSL_MODE_ASYNC bit)
> > >
> https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html
> > >
> > > I'm working on a patch that may make some tweaks to this API, but
> you
> > > should get the idea.
> > >
> > > Matt
> > >
> > >
> > >
> >
> > ___
> > openssl-dev mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> >
> >
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny via RT]

Matt,

I have looked through the APIs. Will have to experiment with them somewhen
later to see how well they will perform, but from theoretical point of view
I am a bit scared of having 2 fds (and one ucontext) for every job in a
pool. It seems like this could be a bit of burden in event-loop based
model. For example, it is not hard to imagine a situation in node.js
application with 1 handshakes that are trying to complete in parallel.
Is there any need in creating this fds unconditionally?

However, again, this is only a hypothetical situation, I'm yet to see how
well it will behave in real situations. Just sharing some immediate
concerns with you.

Thank you,
Fedor.

On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT  wrote:

> Thank you very much, Matt, Rich.
>
> I will read through these docs tomorrow.
>
> On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT 
> wrote:
>
> >
> >
> > On 04/02/16 06:34, Salz, Rich via RT wrote:
> > > It’s late and my response was incomplete.
> > > The other part has already landed in master, and that's the "async
> > engine" support.
> >
> > See:
> >
> > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html
> > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e.
> > the SSL_MODE_ASYNC bit)
> > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html
> >
> > I'm working on a patch that may make some tweaks to this API, but you
> > should get the idea.
> >
> > Matt
> >
> >
> >
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3528
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

Matt,

I have looked through the APIs. Will have to experiment with them somewhen
later to see how well they will perform, but from theoretical point of view
I am a bit scared of having 2 fds (and one ucontext) for every job in a
pool. It seems like this could be a bit of burden in event-loop based
model. For example, it is not hard to imagine a situation in node.js
application with 1 handshakes that are trying to complete in parallel.
Is there any need in creating this fds unconditionally?

However, again, this is only a hypothetical situation, I'm yet to see how
well it will behave in real situations. Just sharing some immediate
concerns with you.

Thank you,
Fedor.

On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT  wrote:

> Thank you very much, Matt, Rich.
>
> I will read through these docs tomorrow.
>
> On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT 
> wrote:
>
> >
> >
> > On 04/02/16 06:34, Salz, Rich via RT wrote:
> > > It’s late and my response was incomplete.
> > > The other part has already landed in master, and that's the "async
> > engine" support.
> >
> > See:
> >
> > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html
> > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e.
> > the SSL_MODE_ASYNC bit)
> > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html
> >
> > I'm working on a patch that may make some tweaks to this API, but you
> > should get the idea.
> >
> > Matt
> >
> >
> >
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny via RT]

Thank you very much, Matt, Rich.

I will read through these docs tomorrow.

On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT  wrote:

>
>
> On 04/02/16 06:34, Salz, Rich via RT wrote:
> > It’s late and my response was incomplete.
> > The other part has already landed in master, and that's the "async
> engine" support.
>
> See:
>
> https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html
> https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e.
> the SSL_MODE_ASYNC bit)
> https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html
>
> I'm working on a patch that may make some tweaks to this API, but you
> should get the idea.
>
> Matt
>
>
>

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

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

Thank you very much, Matt, Rich.

I will read through these docs tomorrow.

On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT  wrote:

>
>
> On 04/02/16 06:34, Salz, Rich via RT wrote:
> > It’s late and my response was incomplete.
> > The other part has already landed in master, and that's the "async
> engine" support.
>
> See:
>
> https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html
> https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e.
> the SSL_MODE_ASYNC bit)
> https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html
>
> I'm working on a patch that may make some tweaks to this API, but you
> should get the idea.
>
> Matt
>
>
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny via RT]

Rich,

Thank you for response.

There is quite a lengthy discussion on that github PR. Is there any TL;DR
version of it?

That PR's diff doesn't really look similar to changes proposed here, as I
was mostly curious about splitting the state maching to allow deferring
things until the required data (RSA-encrypted pre-master) will be available.

I will be more than happy to revive this patch if it sounds interesting to
you. Please let me know.

Thank you,
Fedor.

On Thu, Feb 4, 2016 at 1:15 AM, Rich Salz via RT  wrote:

> our plan for async work is here:
> https://github.com/openssl/openssl/pull/451
>
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
>

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

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

Rich,

Thank you for response.

There is quite a lengthy discussion on that github PR. Is there any TL;DR
version of it?

That PR's diff doesn't really look similar to changes proposed here, as I
was mostly curious about splitting the state maching to allow deferring
things until the required data (RSA-encrypted pre-master) will be available.

I will be more than happy to revive this patch if it sounds interesting to
you. Please let me know.

Thank you,
Fedor.

On Thu, Feb 4, 2016 at 1:15 AM, Rich Salz via RT  wrote:

> our plan for async work is here:
> https://github.com/openssl/openssl/pull/451
>
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client

[Fedor Indutny]

This actually sounds like a lovely idea.

See: https://github.com/openssl/openssl/pull/603

Thank you!

On Sat, Jan 30, 2016 at 8:16 PM, Salz, Rich via RT  wrote:

> I closed the first ticket, so everything is okay.
> If you want to do GitHub pull requests and just open an RT to refer to
> that, that is also okay.
>
>
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client

[Fedor Indutny via RT]

This actually sounds like a lovely idea.

See: https://github.com/openssl/openssl/pull/603

Thank you!

On Sat, Jan 30, 2016 at 8:16 PM, Salz, Rich via RT  wrote:

> I closed the first ticket, so everything is okay.
> If you want to do GitHub pull requests and just open an RT to refer to
> that, that is also okay.
>
>
>

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

Re: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client

[Fedor Indutny via RT]

Hello Rich,

Do I need to submit updated patch separately, or was it ok to attach it to
the second email?

Thank you,
Fedor.

On Sat, Jan 30, 2016 at 7:14 PM, Rich Salz via RT  wrote:

> cancelling as OP suggests.
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
>

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

Re: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client

[Fedor Indutny]

Hello Rich,

Do I need to submit updated patch separately, or was it ok to attach it to
the second email?

Thank you,
Fedor.

On Sat, Jan 30, 2016 at 7:14 PM, Rich Salz via RT  wrote:

> cancelling as OP suggests.
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4282] Re: [PATCH] Allow downgrading when reusing sessions on client

[Fedor Indutny via RT]

Hello,

Please disregard first version of this patch. Making that change at
s3_pkt.c was too broad, and pretty much incorrect. Attached is a
new version of patch. I would appreciate any kind of feedback on
this.

Open questions that I am not sure about so far: is it safe to set
`s->first_packet = 1` on renegotiation? Why is it DTLS-only right
now? Should this patch do anything else to reset the current
session?

Thank you very much,
Fedor.

On Sat, Jan 30, 2016 at 5:04 PM, Fedor Indutny  wrote:

> When connecting to pool of diverse servers (both TLS1.0 and TLS1.2), a
> following scenario may happen:
>
>   1. Connect to TLS1.2 server, receive new session
>   2. Store this session
>   3. Attempt to reuse it later when connecting to server
>   4. Connect to different server from the pool, which speaks only TLS1.0
>   5. Get `SSL_R_WRONG_VERSION_NUMBER` error
>
> Expected behavior would be scrapping off the session, and allowing
> server to downgrade to supported protocol version the way it would do it
> if no client session would be supplied.
>
> This issue was discovered while working on following node.js bug:
>
> https://github.com/nodejs/node/issues/3692
> ---
>  ssl/s3_pkt.c  | 39 +++
>  ssl/ssltest.c | 22 +-
>  test/testssl  |  6 ++
>  3 files changed, 66 insertions(+), 1 deletion(-)
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJWrURJAAoJENcGPM4Zt+iQ0WgP/3QE4w13G+30DYgyKWPGZf7U
SSVF0Yy5ezn+syzKNEkypO2iqL4MnjuBqlyXDlWWQv534Pcmw9uJWe6sCCVf6Tls
BA+v12Fd85QoX4RqhLa6XM8BusY4srAxZbX+D6Z5C7VVLO+2ZjTGYCJhXOoBlOvf
3hYKaVlnfpP1+5Yae8VKEKm3nb6USsvTXn/UDuxxCocaGA3/O3t+vW3U/+jNbtdK
RY60T+jVSkt4fw9eL9qR072eHkUaBWIad9KgGj0gcoJA6RjDn/78Ik6P/mPCrXmG
8/wLdR+qQbjAjWB48JY9f0Vv3XhtG5KLdX/g6w6T1n3F+dVO+rRWxuG7E6J6eMuL
th+Nj3hhhtBEFwW7WnU2+MhxYyy82d1OwFs6A4tRuav86wHEi1zutfWeEcwqg5jM
c6QuERxkPeWbRnIeBcdJVguQ4kO2cWl64a7YzT46RCMSF1GAUMVpB2e38LEd11oa
Uk0KVw2dApXEmVbe8jpRSlBejKafp6lTujE5fiD+6/4foG2hwRUwBjEDpMKtHjs9
AlWzXr5vmwAQ4QKb68h+eC25C6ii4wgSflL0q8Z2hDTdAPi/5ftGOZFNSyBPh6Ub
6wVqZFrwrk5GF2HKwT1KAUEWhUeWbRXFzeknsb5P+vMNZ6qf5j+y7uYaFC+1S4SK
JmxLddBgP2N3VkKfXF7C
=QuAH
-END PGP SIGNATURE-


0001-Allow-downgrading-when-reusing-sessions-on-client.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client

[Fedor Indutny via RT]

When connecting to pool of diverse servers (both TLS1.0 and TLS1.2), a
following scenario may happen:

  1. Connect to TLS1.2 server, receive new session
  2. Store this session
  3. Attempt to reuse it later when connecting to server
  4. Connect to different server from the pool, which speaks only TLS1.0
  5. Get `SSL_R_WRONG_VERSION_NUMBER` error

Expected behavior would be scrapping off the session, and allowing
server to downgrade to supported protocol version the way it would do it
if no client session would be supplied.

This issue was discovered while working on following node.js bug:

https://github.com/nodejs/node/issues/3692
---
 ssl/s3_pkt.c  | 39 +++
 ssl/ssltest.c | 22 +-
 test/testssl  |  6 ++
 3 files changed, 66 insertions(+), 1 deletion(-)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJWrTMxAAoJENcGPM4Zt+iQ+GMQAILay2nyh47kVAv1wV3QBgfw
403IrqpoGqLCklZg0SL7zgce+gfOXMydtqbLbK6wtpFNawLPTkbDvLSVyPyixDwy
56UD+neByBXtIuOSs75qVjmAZcuT5GQMoQlIPrX2zGoaRdJls0w4TCrqcoXTDVlL
4QKbaage+EeymPyadEOKmNX2vZmoLRE+t+cMC5gLAtk7ykpAHMWmEZlwhdryP847
uJA8dI1HjvEDcUJvwSsnZLj/wZSrZcC5+QEVsEba8zlKszFYMalygPBZAneZ6zWT
GOp5oqUEEyXMlZB8VCTZcMIdEx79otpOYURYGwxNU0P6reZngc1syfgZQYYGqZ0s
ohKcWCvbKgZMfI3Vh/LhKVCho0n2G4Uy0k32vOtotmg3zyQjCaUCHdiiWPSiNYDm
BlIunymx2ZvCdIZgy/JnAOE2zXe2Hi9qlw+v6wnNH5xowVQvOf0fOgR/R3qhIdrN
6ZFMDY4Ldq0hOFwplAyQRBJZqnHxA6z43lTr5Uk8mad0kIngciFUjvmaBLpiw0r/
R8FT2uVbpDVHf6HUHGobA4cIWZ4nOYBL/mnOfp81gcG3Sd727dV0/dP0K4nyfbim
aaF5VuM2nZWlLTJZnMNZJYDGm7lM1BhkCuniD/t+ycrAHS9cdoT9H/HvcAIBnmMn
GrIf2pe3UbMmidg/TAtb
=Ci8J
-END PGP SIGNATURE-


0001-Allow-downgrading-when-reusing-sessions-on-client.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3797] [PATCH] evp: fix memory corruption on absent payload

[Fedor Indutny via RT]

Special credit to: Etienne Stalmans (SP)  for
reporting the segfault in a first place!

On Sat, Apr 11, 2015 at 5:37 PM, Fedor Indutny via RT 
wrote:

> Hello!
>
> aes-128-cbc-hmac-sha1, aes-256-cbc-hmac-sha1 ciphers expect the AEAD
> payload, but fail to operate if it wasn't supplied. In fact, in case of
> absent payload - `plen` is going to be `NO_PAYLOAD_LENGTH` and the
> memory will be corrupted (which sometimes leads to the crash).
>
> NOTE: 41cf2d2518f8b7f31287984ea9f13bc9d55205dc implicitly fixes this
> in 1.0.2, so this commit could be considered to be a partial back-port
> of that one.
>
> Attached is the suggested patch.
>
> Thank you,
> Fedor.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABAgAGBQJVKRE0AAoJENcGPM4Zt+iQKKwP/jyRhiNNMy7YVrvHTA/bF02a
> PatvQGulRJvOPw0IzB8YydAsJbrBnYrVx1eniBv+5vjcA/9Tbc3yo0drIZR+um9N
> z0ky4lDmQnIW5JHMhWkw55kEqpnV16rw5AeMfg4aNhFm/5m0tNHyb5Ft9Epu9hh0
> kLV7RGKKmdPP/3FUKtQNictKUAcESZaIJeDeB24XKTOzAuSdPEunfST0tQG6qjtL
> Chj2XrtFDJb+eonjWQmq2RZb67q2qituTOsuqv+e26mgulocnDanrRXetUiTyhDD
> fjBNXBSUHME/xmfD5ffJR/eSnzY/Xzg7E14n4S4ctIPpfZ/3ked86wCj+PC1RGT1
> Xt8lIhWwBzxDGn0161vMpFK59zWdFYBR+V6X0ubCO44F0ZfnExWAtxlr2/YkJyCS
> HYMgJEZEyIp4qt9ubJ3gOFn7r5Dzo+Dc/hi2xmEneISiYvnu5ugjh4cQU/SQxy8c
> GYI1KDbvhz0K/Z/qs/ByaSeYlcE5ZVanbvb8YyqtIAsRklaVzfapssMBMcWUTYcX
> P6lt9sAmC7/wNdXvTMCUZoLS1Gz5HX5rmfdquT82kRWI5VYfN5qwWWwz1nN3VNcb
> kyBf9NX1FJ/7tzQmYPDGNgif09vwPVD0x3q5gA5WYnrP/JZL6JYQpT9gHH7lz7Lv
> pl3+vgsqfHkGs0I+W6Hy
> =GkP4
> -END PGP SIGNATURE-
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>

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

Re: [openssl-dev] [openssl.org #3797] [PATCH] evp: fix memory corruption on absent payload

[Fedor Indutny]

Special credit to: Etienne Stalmans (SP)  for
reporting the segfault in a first place!

On Sat, Apr 11, 2015 at 5:37 PM, Fedor Indutny via RT 
wrote:

> Hello!
>
> aes-128-cbc-hmac-sha1, aes-256-cbc-hmac-sha1 ciphers expect the AEAD
> payload, but fail to operate if it wasn't supplied. In fact, in case of
> absent payload - `plen` is going to be `NO_PAYLOAD_LENGTH` and the
> memory will be corrupted (which sometimes leads to the crash).
>
> NOTE: 41cf2d2518f8b7f31287984ea9f13bc9d55205dc implicitly fixes this
> in 1.0.2, so this commit could be considered to be a partial back-port
> of that one.
>
> Attached is the suggested patch.
>
> Thank you,
> Fedor.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABAgAGBQJVKRE0AAoJENcGPM4Zt+iQKKwP/jyRhiNNMy7YVrvHTA/bF02a
> PatvQGulRJvOPw0IzB8YydAsJbrBnYrVx1eniBv+5vjcA/9Tbc3yo0drIZR+um9N
> z0ky4lDmQnIW5JHMhWkw55kEqpnV16rw5AeMfg4aNhFm/5m0tNHyb5Ft9Epu9hh0
> kLV7RGKKmdPP/3FUKtQNictKUAcESZaIJeDeB24XKTOzAuSdPEunfST0tQG6qjtL
> Chj2XrtFDJb+eonjWQmq2RZb67q2qituTOsuqv+e26mgulocnDanrRXetUiTyhDD
> fjBNXBSUHME/xmfD5ffJR/eSnzY/Xzg7E14n4S4ctIPpfZ/3ked86wCj+PC1RGT1
> Xt8lIhWwBzxDGn0161vMpFK59zWdFYBR+V6X0ubCO44F0ZfnExWAtxlr2/YkJyCS
> HYMgJEZEyIp4qt9ubJ3gOFn7r5Dzo+Dc/hi2xmEneISiYvnu5ugjh4cQU/SQxy8c
> GYI1KDbvhz0K/Z/qs/ByaSeYlcE5ZVanbvb8YyqtIAsRklaVzfapssMBMcWUTYcX
> P6lt9sAmC7/wNdXvTMCUZoLS1Gz5HX5rmfdquT82kRWI5VYfN5qwWWwz1nN3VNcb
> kyBf9NX1FJ/7tzQmYPDGNgif09vwPVD0x3q5gA5WYnrP/JZL6JYQpT9gHH7lz7Lv
> pl3+vgsqfHkGs0I+W6Hy
> =GkP4
> -END PGP SIGNATURE-
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3797] [PATCH] evp: fix memory corruption on absent payload

[Fedor Indutny via RT]

Hello!

aes-128-cbc-hmac-sha1, aes-256-cbc-hmac-sha1 ciphers expect the AEAD
payload, but fail to operate if it wasn't supplied. In fact, in case of
absent payload - `plen` is going to be `NO_PAYLOAD_LENGTH` and the
memory will be corrupted (which sometimes leads to the crash).

NOTE: 41cf2d2518f8b7f31287984ea9f13bc9d55205dc implicitly fixes this
in 1.0.2, so this commit could be considered to be a partial back-port
of that one.

Attached is the suggested patch.

Thank you,
Fedor.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJVKRE0AAoJENcGPM4Zt+iQKKwP/jyRhiNNMy7YVrvHTA/bF02a
PatvQGulRJvOPw0IzB8YydAsJbrBnYrVx1eniBv+5vjcA/9Tbc3yo0drIZR+um9N
z0ky4lDmQnIW5JHMhWkw55kEqpnV16rw5AeMfg4aNhFm/5m0tNHyb5Ft9Epu9hh0
kLV7RGKKmdPP/3FUKtQNictKUAcESZaIJeDeB24XKTOzAuSdPEunfST0tQG6qjtL
Chj2XrtFDJb+eonjWQmq2RZb67q2qituTOsuqv+e26mgulocnDanrRXetUiTyhDD
fjBNXBSUHME/xmfD5ffJR/eSnzY/Xzg7E14n4S4ctIPpfZ/3ked86wCj+PC1RGT1
Xt8lIhWwBzxDGn0161vMpFK59zWdFYBR+V6X0ubCO44F0ZfnExWAtxlr2/YkJyCS
HYMgJEZEyIp4qt9ubJ3gOFn7r5Dzo+Dc/hi2xmEneISiYvnu5ugjh4cQU/SQxy8c
GYI1KDbvhz0K/Z/qs/ByaSeYlcE5ZVanbvb8YyqtIAsRklaVzfapssMBMcWUTYcX
P6lt9sAmC7/wNdXvTMCUZoLS1Gz5HX5rmfdquT82kRWI5VYfN5qwWWwz1nN3VNcb
kyBf9NX1FJ/7tzQmYPDGNgif09vwPVD0x3q5gA5WYnrP/JZL6JYQpT9gHH7lz7Lv
pl3+vgsqfHkGs0I+W6Hy
=GkP4
-END PGP SIGNATURE-


0001-evp-fix-memory-corruption-on-absent-payload.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] evp: fix memory corruption on absent payload

[Fedor Indutny]

Hello!

aes-128-cbc-hmac-sha1, aes-256-cbc-hmac-sha1 ciphers expect the AEAD
payload, but fail to operate if it wasn't supplied. In fact, in case of
absent payload - `plen` is going to be `NO_PAYLOAD_LENGTH` and the
memory will be corrupted (which sometimes leads to the crash).

NOTE: 41cf2d2518f8b7f31287984ea9f13bc9d55205dc implicitly fixes this
in 1.0.2, so this commit could be considered to be a partial back-port
of that one.

Attached is the suggested patch.

Thank you,
Fedor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJVKRE0AAoJENcGPM4Zt+iQKKwP/jyRhiNNMy7YVrvHTA/bF02a
PatvQGulRJvOPw0IzB8YydAsJbrBnYrVx1eniBv+5vjcA/9Tbc3yo0drIZR+um9N
z0ky4lDmQnIW5JHMhWkw55kEqpnV16rw5AeMfg4aNhFm/5m0tNHyb5Ft9Epu9hh0
kLV7RGKKmdPP/3FUKtQNictKUAcESZaIJeDeB24XKTOzAuSdPEunfST0tQG6qjtL
Chj2XrtFDJb+eonjWQmq2RZb67q2qituTOsuqv+e26mgulocnDanrRXetUiTyhDD
fjBNXBSUHME/xmfD5ffJR/eSnzY/Xzg7E14n4S4ctIPpfZ/3ked86wCj+PC1RGT1
Xt8lIhWwBzxDGn0161vMpFK59zWdFYBR+V6X0ubCO44F0ZfnExWAtxlr2/YkJyCS
HYMgJEZEyIp4qt9ubJ3gOFn7r5Dzo+Dc/hi2xmEneISiYvnu5ugjh4cQU/SQxy8c
GYI1KDbvhz0K/Z/qs/ByaSeYlcE5ZVanbvb8YyqtIAsRklaVzfapssMBMcWUTYcX
P6lt9sAmC7/wNdXvTMCUZoLS1Gz5HX5rmfdquT82kRWI5VYfN5qwWWwz1nN3VNcb
kyBf9NX1FJ/7tzQmYPDGNgif09vwPVD0x3q5gA5WYnrP/JZL6JYQpT9gHH7lz7Lv
pl3+vgsqfHkGs0I+W6Hy
=GkP4
-END PGP SIGNATURE-


0001-evp-fix-memory-corruption-on-absent-payload.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Using openssl with a remote private key

[Fedor Indutny]

Hello Tigran!

I was using:

https://github.com/indutny/bud/compare/master...feature/async-key-ex

For quite a long time now. It seems that you have your own solution, but
anyway posted it here in case you are interested.

Cheers!

On Tue, Mar 17, 2015 at 8:44 AM, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) <
tgyonj...@bloomberg.net> wrote:

> Hi there!
>
> Recently I had to work on an openssl project where due to security
> requirements I had to place the private key for the server certificate on
> another machine. In order to be able to make openssl ignore the fake
> private key in the certificate I had to "hack" some data structures to
> delegate the handshake decrypt to the remote machine so that the handshake
> could succeed.
>
> I was wondering if this capability to delegate the decrypt function can be
> useful enough to incorporate into the official version.
> In cases when the client and the server are located on user's machine it
> is a risk to keep the private key on that machine.
>
> Let me know if there is a better solution for this problem.
>
> Cheers,
> Tigran
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1

[Fedor Indutny]

Thank you!

On Tue, Jan 27, 2015 at 6:02 PM, Matt Caswell  wrote:

>
>
> On 15/01/15 17:06, Fedor Indutny wrote:
> > Matt,
> >
> > Thank you for reply.
> >
> > May I ask you when do you think your patch may land in 1.0.2 or whatever?
> >
> > If this is something of your long term goals and not going to land
> > anywhere soon. Could you please tell me about issues in my patch (either
> > privately or in publiс)?
>
> My apologies for the delayed response. Things went a bit mad for a while
> with releases and the source code reformat, and I completely forgot
> about this email :-(
>
> I am hoping my patch will land in master (which means 1.1.0...aiming for
> an end of year release).
>
> I will add some notes to your RT ticket regarding your patch.
>
> You can see my draft patch here:
> https://github.com/mattcaswell/openssl/commits/late-check-trusted-v2
>
> This is still going through review so may change.
>
> Matt
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1

[Fedor Indutny]

Matt,

Thank you for reply.

May I ask you when do you think your patch may land in 1.0.2 or whatever?

If this is something of your long term goals and not going to land anywhere
soon. Could you please tell me about issues in my patch (either privately
or in publiс)?

Thank you again,
Fedor.

On Thursday, January 15, 2015, Matt Caswell  wrote:

>
>
> On 15/01/15 14:21, Matt Caswell wrote:
> >
> >
> > On 15/01/15 14:13, Fedor Indutny wrote:
> >> Hello!
> >>
> >> During the course of deprecation of stale 1024bit CA certs,
> >> node.js and io.js project teams have identified the problem with
> >> how OpenSSL client handles the server's certificate chain. It is
> >> quite evident that it ignores certificate store and loads issuer
> >> from the chain that was received. This leads to the problems with
> >> AWS and probably other service providers who sent the stale
> >> **alternative** certificate chain with same serial numbers, but
> >> 1024bit CA certificates.
> >>
> >> I have already tried proposing a solution to the OpenSSL team:
> >>
> >> https://www.mail-archive.com/openssl-dev@openssl.org/msg37721.html
> >>
> >> But one of the node.js contributors we have found this commit (from
> 2010):
> >>
> >>
> https://github.com/openssl/openssl/commit/db28aa86e00b9121bee94d1e65506bf22d5ca6e3
> >>
> >> The main question that I have is:
> >>
> >> Is it safe to float this patch on top of 1.0.1k and use it? From
> >> my knowledge of code it appears to be pretty harmless, however
> >> the fact that it wasn't backported in 5 years makes me wonder if
> >> it was considered safe after all.
> >
> > There are some concerns about the performance of trusted_first.
> > Successful certificate look ups are cached, whilst failed ones are not.
> > Therefore using trusted_first *could* have an adverse impact.
> >
> > This issue is currently under discussion within the dev team. I have an
> > alternative patch that addresses the same issue in a different way.
> > Essentially it works in a similar way to that which you proposed in
> > RT3637. However I have some issues with that patch, so I've done it
> > slightly differently.
> >
> > RT3621 is also relevant here.
>
> I should add that in any case this functionality would never be
> backported to 1.0.1 (only considered for future versions). 1.0.1 is a
> stable release and only sees bug fixes. This would be considered a
> feature and a significant change to the way certificates are verified.
>
> Matt
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1

[Fedor Indutny]

Hello!

During the course of deprecation of stale 1024bit CA certs,
node.js and io.js project teams have identified the problem with
how OpenSSL client handles the server's certificate chain. It is
quite evident that it ignores certificate store and loads issuer
from the chain that was received. This leads to the problems with
AWS and probably other service providers who sent the stale
**alternative** certificate chain with same serial numbers, but
1024bit CA certificates.

I have already tried proposing a solution to the OpenSSL team:

https://www.mail-archive.com/openssl-dev@openssl.org/msg37721.html

But one of the node.js contributors we have found this commit (from 2010):

https://github.com/openssl/openssl/commit/db28aa86e00b9121bee94d1e65506bf22d5ca6e3

The main question that I have is:

Is it safe to float this patch on top of 1.0.1k and use it? From
my knowledge of code it appears to be pretty harmless, however
the fact that it wasn't backported in 5 years makes me wonder if
it was considered safe after all.

Thank you,
Fedor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3637] [PATCH] x509: skip certs if in alternative cert chain

[Fedor Indutny via RT]

In situations like [0] the server may provide alternative certificate
chain, which is no longer valid in the current certificate store. In
fact the issuer of the leaf (or some intermediate) cert is known and
trusted, but the alternative chain certs that are sent by server are
not trusted, thus leading to `ctx->get_issuer(...)` return 0.

This patch changes the default behavior from "borking out the whole sent
chain" to "pop as much certs as needed to make it work".

Basically, it pops the last cert and checks if the previous has known
issuer.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJUkm/WAAoJENcGPM4Zt+iQO1UQAIIWnbOwB4DG3rT2E3GFQ3JU
gk2LFDFhrWgCmTPLki8TDkR664SimPYcMsI9Vg0v3v5PecQQaW2O/BLDYEJiZ07E
2nSQCI8APp10jIdt0QUmehP4uHYAYkGxOBnGzypsrXFz2N5MV4XJG1jUZOsgIgod
yZ2Vg8xTejnYrSJ/JfSNTBZy3s20wXDqh06TWNt6rn5o/AsT5l6/JVvC7Vi1DnNu
LcddPrCm2tiaUqVQP+Kn5tfYKGhACTGjnCi89t67rYYbZwxLN2YpgspB3Kv8aR4P
WMofhpZocAZ/uBQcshWe/ExiFsJESQazmM5KYLrVrLsa/hWYLx2E6Dl/N+6IvsUX
8eoG0QFa25iTRv+gLxXEiKca6EPuOWBm6kcz169nyogKBRBzASk3DMwK6TdOfiXI
5uw3zBByiI/DDaBQW62x1KTkTfrcg0pWZHurEVrSK7USr2nGLxI87IWq/e6kcd6x
QbkWmOY5qGoRVoBPjxeVowd5EfyaH2cM7bJLqXcNncYAEmIpvTUEN6YFbyUg2Nuc
DaqSUx6UrPOo3M2kyiqDdGz75Xq57ncWByvJ4Dj8DNqyxOliFG8Mldz7vDUYFbHt
aKR2UqehGsYZbnw/mFDRRtQ2WliB/BEtjISVKl7KPNgkv5twrZF7fMU/Oh3Mf7pe
Jiw6SKPj0JctQF8xpO5J
=4E+B
-END PGP SIGNATURE-


0001-x509-skip-certs-if-in-alternative-cert-chain.patch
Description: Binary data
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] x509: skip certs if in alternative cert chain

[Fedor Indutny]

In situations like [0] the server may provide alternative certificate
chain, which is no longer valid in the current certificate store. In
fact the issuer of the leaf (or some intermediate) cert is known and
trusted, but the alternative chain certs that are sent by server are
not trusted, thus leading to `ctx->get_issuer(...)` return 0.

This patch changes the default behavior from "borking out the whole sent
chain" to "pop as much certs as needed to make it work".

Basically, it pops the last cert and checks if the previous has known
issuer.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4

NOTE: Possibly duplicate, I didn't get a reply from openssl-bugs@
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJUkm/WAAoJENcGPM4Zt+iQO1UQAIIWnbOwB4DG3rT2E3GFQ3JU
gk2LFDFhrWgCmTPLki8TDkR664SimPYcMsI9Vg0v3v5PecQQaW2O/BLDYEJiZ07E
2nSQCI8APp10jIdt0QUmehP4uHYAYkGxOBnGzypsrXFz2N5MV4XJG1jUZOsgIgod
yZ2Vg8xTejnYrSJ/JfSNTBZy3s20wXDqh06TWNt6rn5o/AsT5l6/JVvC7Vi1DnNu
LcddPrCm2tiaUqVQP+Kn5tfYKGhACTGjnCi89t67rYYbZwxLN2YpgspB3Kv8aR4P
WMofhpZocAZ/uBQcshWe/ExiFsJESQazmM5KYLrVrLsa/hWYLx2E6Dl/N+6IvsUX
8eoG0QFa25iTRv+gLxXEiKca6EPuOWBm6kcz169nyogKBRBzASk3DMwK6TdOfiXI
5uw3zBByiI/DDaBQW62x1KTkTfrcg0pWZHurEVrSK7USr2nGLxI87IWq/e6kcd6x
QbkWmOY5qGoRVoBPjxeVowd5EfyaH2cM7bJLqXcNncYAEmIpvTUEN6YFbyUg2Nuc
DaqSUx6UrPOo3M2kyiqDdGz75Xq57ncWByvJ4Dj8DNqyxOliFG8Mldz7vDUYFbHt
aKR2UqehGsYZbnw/mFDRRtQ2WliB/BEtjISVKl7KPNgkv5twrZF7fMU/Oh3Mf7pe
Jiw6SKPj0JctQF8xpO5J
=4E+B
-END PGP SIGNATURE-


0001-x509-skip-certs-if-in-alternative-cert-chain.patch
Description: Binary data
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: CIPHER STRINGS

[Fedor Indutny]

Hello!

Have you seen: `openssl ciphers -v` output?

Cheers,
Fedor.

On Sun, Oct 12, 2014 at 8:13 PM, dE  wrote:

> Hi.
>
> I was reading the openssl ciphers command, where I would like to suggest
> something for the CIPHER STRINGS.
>
> Currently all possible cipher strings are listed in the man page with each
> of their names having a description which may or may not specify if it's an
> authentication, encryption, Kx or MAC algorithm. This's inconvenient.
>
> I suggest there must be a way to to list them all with catagories of
> authentication, encryption, Kx and MAC along with their common names.
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: Error _armv7_tick openssl

[Fedor Indutny]

Jay,

I seen the reports of this error on node.js issue tracker, but don't have
any other information about it yet, since I'm unable to reproduce it on my
raspberry pi.

What I tried to say, is that Illegal instruction and the SIGILL is the way
OpenSSL tries to figure out the supported features. It should not be the
source of the bug, just a part of initialisation process. The bug is most
likely happening right after this, when you see the actual crash.

Sorry for not much details,
Fedor.

On Fri, Oct 10, 2014 at 3:07 PM, Jay D Bhatt  wrote:

>  Hi Fedor,
>
>
>
> If I press ‘continue’, then also it give segmentation fault. It is not
> working normally, it exits with seg fault: saying illegal instruction.Could
> you suggest any other solution? The assembly instruction which I mentioned
> in my log was identified as illegal instruction.
>
>
>
> Thanks,
>
> Jay
>
>
>
> *From:* owner-openssl-...@openssl.org [mailto:
> owner-openssl-...@openssl.org] *On Behalf Of *Fedor Indutny
> *Sent:* 10 October 2014 15:29
> *To:* openssl-dev@openssl.org
> *Subject:* Re: Error _armv7_tick openssl
>
>
>
> Hello!
>
>
>
> I'm not a OpenSSL core developer, but anyway here are some thoughts from
> me.
>
>
>
> SIGILL is totally a normal condition, as it is caught by:
>
>
>
>
> https://github.com/openssl/openssl/blob/dabfbea7d91619b286e5d32ffc68ec7e5bd7e9bf/crypto/armcap.c#L96-L101
>
>
>
> This is a part of detecting features, so if you wish to get more details -
> please enter `continue` after catching SIGILL in gdb.
>
>
>
> Thanks,
>
> Fedor.
>
>
>
> On Fri, Oct 10, 2014 at 7:52 AM, Jay D Bhatt  wrote:
>
> Hi ,
>
>
>
> I was working on a armv7l architecture platform and was trying to run
> webruntime related library, but it was crashing _armv7_tick(). So, I did
> GDB on the wrt binary and below are the logs:
>
>
>
> root:/usr/bin> gdb wrt_launchpad_daemon
>
> GNU gdb (GDB) 7.5.1
>
> Copyright (C) 2012 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>
> and "show warranty" for details.
>
> This GDB was configured as "armv7l-tizen-linux-gnueabi".
>
> For bug reporting instructions, please see:
>
> <http://www.gnu.org/software/gdb/bugs/>...
>
> Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols
> found)...done.
>
> (gdb) run
>
> Starting program: /usr/bin/wrt_launchpad_daemon
>
> warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined
> by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
>
> To enable execution of this file add
>
> add-auto-load-safe-path /usr/lib/libthread_db.so.1
>
> line to your configuration file "/root/.gdbinit".
>
> To completely disable this security protection add
>
> set auto-load safe-path /
>
> line to your configuration file "/root/.gdbinit".
>
> For more information about this security protection see the
>
> "Auto-loading safe path" section in the GDB manual.  E.g., run from the
> shell:
>
> info "(gdb)Auto-loading safe path"
>
> warning: Unable to find libthread_db matching inferior's thread library,
> thread debugging will not be available.
>
>
>
> Program received signal SIGILL, Illegal instruction.
>
> 0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
>
> (gdb) bt
>
> #0  0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
>
> #1  0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0
>
> #2  0x2aab5e0e in call_init () from /lib/ld-linux.so.3
>
> #3  0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3
>
> #4  0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3
>
> #5  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
>
> #6  0x2aab8642 in _dl_open () from /lib/ld-linux.so.3
>
> #7  0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2
>
> #8  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
>
> #9  0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2
>
> #10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2
>
> #11 0xa744 in main ()
>
> (gdb) disas _armv7_tick
>
> Dump of assembler code for function _armv7_tick:
>
> => 0x2e2b76e8 <+0>: mrc 15, 0, r0, cr9, cr13, {0}
>
>0x2e2b76ec <+4>: bx  lr
>

Re: Error _armv7_tick openssl

[Fedor Indutny]

Hello!

I'm not a OpenSSL core developer, but anyway here are some thoughts from me.

SIGILL is totally a normal condition, as it is caught by:

https://github.com/openssl/openssl/blob/dabfbea7d91619b286e5d32ffc68ec7e5bd7e9bf/crypto/armcap.c#L96-L101

This is a part of detecting features, so if you wish to get more details -
please enter `continue` after catching SIGILL in gdb.

Thanks,
Fedor.

On Fri, Oct 10, 2014 at 7:52 AM, Jay D Bhatt  wrote:

>  Hi ,
>
>
>
> I was working on a armv7l architecture platform and was trying to run
> webruntime related library, but it was crashing _armv7_tick(). So, I did
> GDB on the wrt binary and below are the logs:
>
>
>
> root:/usr/bin> gdb wrt_launchpad_daemon
>
> GNU gdb (GDB) 7.5.1
>
> Copyright (C) 2012 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>
> and "show warranty" for details.
>
> This GDB was configured as "armv7l-tizen-linux-gnueabi".
>
> For bug reporting instructions, please see:
>
> ...
>
> Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols
> found)...done.
>
> (gdb) run
>
> Starting program: /usr/bin/wrt_launchpad_daemon
>
> warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined
> by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
>
> To enable execution of this file add
>
> add-auto-load-safe-path /usr/lib/libthread_db.so.1
>
> line to your configuration file "/root/.gdbinit".
>
> To completely disable this security protection add
>
> set auto-load safe-path /
>
> line to your configuration file "/root/.gdbinit".
>
> For more information about this security protection see the
>
> "Auto-loading safe path" section in the GDB manual.  E.g., run from the
> shell:
>
> info "(gdb)Auto-loading safe path"
>
> warning: Unable to find libthread_db matching inferior's thread library,
> thread debugging will not be available.
>
>
>
> Program received signal SIGILL, Illegal instruction.
>
> 0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
>
> (gdb) bt
>
> #0  0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
>
> #1  0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0
>
> #2  0x2aab5e0e in call_init () from /lib/ld-linux.so.3
>
> #3  0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3
>
> #4  0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3
>
> #5  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
>
> #6  0x2aab8642 in _dl_open () from /lib/ld-linux.so.3
>
> #7  0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2
>
> #8  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
>
> #9  0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2
>
> #10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2
>
> #11 0xa744 in main ()
>
> (gdb) disas _armv7_tick
>
> Dump of assembler code for function _armv7_tick:
>
> => 0x2e2b76e8 <+0>: mrc 15, 0, r0, cr9, cr13, {0}
>
>0x2e2b76ec <+4>: bx  lr
>
> End of assembler dump.
>
>
>
>
>
>
>
> It seems that either the architecture platform is not able to identify the
> instructions or some other reason, due to which it fails.
>
> Has anyone faced similar problem? Could anybody suggest some solution or
> patch which can solve this issue?
>
>
>
> Thanks,
>
> Jay
>
>
> ~~Disclaimer~~~
> Information contained and transmitted by this e-mail is confidential and
> proprietary to IGATE and its affiliates and is intended for use only by the
> recipient. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution, copying or use of this e-mail is
> strictly prohibited and you are requested to delete this e-mail immediately
> and notify the originator or mailad...@igate.com. IGATE does not enter
> into any agreement with any party by e-mail. Any views expressed by an
> individual do not necessarily reflect the view of IGATE. IGATE is not
> responsible for the consequences of any actions taken on the basis of
> information provided, through this email. The contents of an attachment to
> this e-mail may contain software viruses, which could damage your own
> computer system. While IGATE has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should carry out your own
> virus checks before opening an attachment. To know more about IGATE please
> visit www.igate.com.
>
> 
>

Re: [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

Some fixes.

On Fri, Sep 19, 2014 at 3:27 PM, Fedor Indutny  wrote:

> Sorry for a noise, here is even better version of this patch.
>
> Without BUF_MEM_grow() calls, which were actually useless,
> and with clearer state management.
>
> On Fri, Sep 19, 2014 at 12:30 PM, Fedor Indutny  wrote:
>
>> And an additional follow-up, with docs and refined code.
>>
>> On Fri, Sep 19, 2014 at 2:48 AM, Fedor Indutny  wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Here is an example of how it could be used (in my TLS terminator):
>>>
>>> https://github.com/indutny/bud/compare/master...feature/async-key-ex
>>>
>>> Basically, if you have ever used async SSL API, you should be
>>> aware of things like:
>>>
>>> SSL_ERROR_WANT_READ
>>> SSL_ERROR_WANT_WRITE
>>>
>>> In addition to these two, my patch adds:
>>>
>>> SSL_ERROR_WANT_SIGN
>>> SSL_ERROR_WANT_RSA_DECRYPT
>>>
>>> If one of these is returned - you may get the data that should
>>> be signed/decrypted with:
>>>
>>> SSL_get_key_ex_data()
>>> SSL_get_key_ex_len()
>>>
>>> Get the key type (in case of SIGN):
>>>
>>> SSL_get_key_ex_type()
>>> // Returns EVP_PKEY_RSA, EVP_PKEY_ECC
>>>
>>> And get signature digest nid with:
>>>
>>> SSL_get_key_ex_md()
>>>
>>> Please be aware of the fact that `md` could be `NID_md5_sha1`,
>>> take a look at bud's code to figure out what should be done in
>>> this case (basically, you'll need to use raw
>>> `RSA_decrypt_private()`).
>>>
>>> After performing sign/decrypt (which could happen in other
>>> thread, or on a different server) you should call:
>>>
>>> SSL_supply_key_ex()
>>>
>>> to supply the result and continue handshake process. At
>>> this point `SSL_read()`/`SSL_write()` will start returning
>>> proper values.
>>>
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1
>>>
>>> iQIcBAEBAgAGBQJUG2D2AAoJENcGPM4Zt+iQJdoQAKZxbcGpzHFktSbU3uDocy3R
>>> fywWmqkYnoJ5jWF3xn4Excv4dAGhMfb/7tm9nt9zyV8g0Qsu8ChqWTl+kgK+hj9o
>>> mV+3jhqPDWR2VhmAC3J5ZsCpNm3IW/iNgGiU+u/k9N2i0WHjYSoTHM/NooN5GIu2
>>> KKhNXPw1Y05yxOZWmbUInMl/uscGWDtzylRNyJpfLFFu3JDQy1sBTKD6UAZC5ERY
>>> 7LUZ1TqVdk1DPY3Tf/j4IaB9Ds9teGLGj63J8upJhDjWHibFzV5bx6X+FjknUB9M
>>> xaebV4yfHZNRHseBu2ZqTQ2f2MNnXVisdzJRX6oyYeyq872MsJjAFhbFhFTi0sTI
>>> T8Y9n8cjuctbn+zTISVyVqEEBl8udWTY1t14SJ9lNcdU3xAf9OzEBVdORpUDqFl+
>>> zteRC145o7gs7mEtJjyBpy8mhXB3mc13ZkC2qaJIyqkqAPODu/xlqCga7oaogHNy
>>> Q2wy0HUeX69Ra0ada3TcJQgB14qESj3Uvq1hcgFk7SEXBxkU5NJ2OcItvU1+emd7
>>> hRlQvDqiiQcK9WgsdOIKZpovtT3FswhsIy0Tv77Nx9PY04urOTEgmhPJHveCJOQq
>>> i0apvI09YgimXs4Sd5h3rs9TsKrDtG0BG0jM1zfo5zbcKE2IbMpmzOc84MxkwUSl
>>> tPV48uw46UVpu4zOOByM
>>> =zJGs
>>> -END PGP SIGNATURE-
>>>
>>> On Sat, Sep 13, 2014 at 10:59 PM, Fedor Indutny 
>>> wrote:
>>>
>>>> Here is an additional patch, to expose the type of key that should be
>>>> used for a signature.
>>>>
>>>> On Thu, Sep 11, 2014 at 10:59 AM, Fedor Indutny via RT 
>>>> wrote:
>>>>
>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>> Hash: SHA1
>>>>>
>>>>> Hello devs!
>>>>>
>>>>> Here is a patch that implements asynchronous RSA key operation
>>>>> mode for a TLS/SSL implementation in OpenSSL.
>>>>>
>>>>> Here is some technical info about it:
>>>>>
>>>>> Support async RSA exchange by providing new SSL_want_rsa_sign(),
>>>>> SSL_want_rsa_decrypt() API methods.
>>>>>
>>>>> After getting such want values - SSL_supply_key_ex_data() should be
>>>>> invoked to continue handshake with a sign/decrypt data that was
>>>>> received
>>>>> from the remote server.
>>>>> - ---
>>>>>  ssl/s3_srvr.c  | 398
>>>>> -
>>>>>  ssl/ssl.h  |  28 
>>>>>  ssl/ssl3.h |   6 +
>>>>>  ssl/ssl_lib.c  |  31 -
>>>>>  ssl/ssl_locl.h |   2 +
>>>>>  ssl/ssl_rsa.c  |  24 ++--
>>>>>  ssl/ssltest.c  | 116 -
>>>>>  test/testssl   |   6 +
>>>>>  8 files changed, 475 insertions(+), 136 deletions(-)
>>>>> -BEGIN PGP SIGNATURE-
>>>>> Version: GnuPG v1
>>>>>
>>>>> iQIcBAEBAgAGBQJUEWeCAAoJENcGPM4Zt+iQPcoP/0R9wJz0gvqi5QFiGiAyOXyD
>>>>> uWWB+lkGlB4r6AOhu1D02tQaQTaiRhSO3theSMOCZ4fQ+BMqZdyk37zq/6Z/rjnJ
>>>>> jkd062SgYeh8WCvoJSoNF+gSeDgM/WnWw2q6R1Ls+DuYdQstym9+VIgx3LLd0LO8
>>>>> 19mYHPUms0TFkzPfLqST4keHyZlLa1HzsEpdEQ8TWaU1vqqSrH6NfvPDjwwzMVWG
>>>>> yMOW8tM8I2WDU9V6zMm+Mr7qmU/zowwVmOnVu0Mi8wBpcpN1GvFGbN8oXispnLc/
>>>>> uccrKK1l98p3wnI0uXe5SmXWB5ksaEtz6CMewZotRgKR8dluwEHqIZ1mzE4+TMxK
>>>>> iFDqUlCcRIjGgssGyjbHC23inwDeN1lZjOxE0G0dhzJZcYAYWJ2rWSQQGxBJJy5Z
>>>>> VFxaElNImDyZ9uUFUtEhzGoaAV7isC9h78anTFzJMuJLTiukHERwFPvRgU/HQPNx
>>>>> EG481cmnjJ2M2hyWRBrvCna8SftUPmGHczqDPD+Tt4Ry/msoZpdwEcLNossl6GcF
>>>>> wXoAMeV5Jg8CenVobdLDQ53G1pJCcY58Zk+Ep9Va+DqfoEsyHc+XhhApMP8B4leC
>>>>> R2mwi0KVL5F6NPhqJmDi1aXKtUu4A50j3yk35aJrEjQCKv3BW1gHvlL763Sve/GL
>>>>> CAsACbfGic+GRS52Pmo2
>>>>> =f3GH
>>>>> -END PGP SIGNATURE-
>>>>>
>>>>>
>>>>
>>>
>>
>


0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch
Description: Binary data


0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch.sig
Description: Binary data

Re: [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

Sorry for a noise, here is even better version of this patch.

Without BUF_MEM_grow() calls, which were actually useless,
and with clearer state management.

On Fri, Sep 19, 2014 at 12:30 PM, Fedor Indutny  wrote:

> And an additional follow-up, with docs and refined code.
>
> On Fri, Sep 19, 2014 at 2:48 AM, Fedor Indutny  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Here is an example of how it could be used (in my TLS terminator):
>>
>> https://github.com/indutny/bud/compare/master...feature/async-key-ex
>>
>> Basically, if you have ever used async SSL API, you should be
>> aware of things like:
>>
>> SSL_ERROR_WANT_READ
>> SSL_ERROR_WANT_WRITE
>>
>> In addition to these two, my patch adds:
>>
>> SSL_ERROR_WANT_SIGN
>> SSL_ERROR_WANT_RSA_DECRYPT
>>
>> If one of these is returned - you may get the data that should
>> be signed/decrypted with:
>>
>> SSL_get_key_ex_data()
>> SSL_get_key_ex_len()
>>
>> Get the key type (in case of SIGN):
>>
>> SSL_get_key_ex_type()
>> // Returns EVP_PKEY_RSA, EVP_PKEY_ECC
>>
>> And get signature digest nid with:
>>
>> SSL_get_key_ex_md()
>>
>> Please be aware of the fact that `md` could be `NID_md5_sha1`,
>> take a look at bud's code to figure out what should be done in
>> this case (basically, you'll need to use raw
>> `RSA_decrypt_private()`).
>>
>> After performing sign/decrypt (which could happen in other
>> thread, or on a different server) you should call:
>>
>> SSL_supply_key_ex()
>>
>> to supply the result and continue handshake process. At
>> this point `SSL_read()`/`SSL_write()` will start returning
>> proper values.
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJUG2D2AAoJENcGPM4Zt+iQJdoQAKZxbcGpzHFktSbU3uDocy3R
>> fywWmqkYnoJ5jWF3xn4Excv4dAGhMfb/7tm9nt9zyV8g0Qsu8ChqWTl+kgK+hj9o
>> mV+3jhqPDWR2VhmAC3J5ZsCpNm3IW/iNgGiU+u/k9N2i0WHjYSoTHM/NooN5GIu2
>> KKhNXPw1Y05yxOZWmbUInMl/uscGWDtzylRNyJpfLFFu3JDQy1sBTKD6UAZC5ERY
>> 7LUZ1TqVdk1DPY3Tf/j4IaB9Ds9teGLGj63J8upJhDjWHibFzV5bx6X+FjknUB9M
>> xaebV4yfHZNRHseBu2ZqTQ2f2MNnXVisdzJRX6oyYeyq872MsJjAFhbFhFTi0sTI
>> T8Y9n8cjuctbn+zTISVyVqEEBl8udWTY1t14SJ9lNcdU3xAf9OzEBVdORpUDqFl+
>> zteRC145o7gs7mEtJjyBpy8mhXB3mc13ZkC2qaJIyqkqAPODu/xlqCga7oaogHNy
>> Q2wy0HUeX69Ra0ada3TcJQgB14qESj3Uvq1hcgFk7SEXBxkU5NJ2OcItvU1+emd7
>> hRlQvDqiiQcK9WgsdOIKZpovtT3FswhsIy0Tv77Nx9PY04urOTEgmhPJHveCJOQq
>> i0apvI09YgimXs4Sd5h3rs9TsKrDtG0BG0jM1zfo5zbcKE2IbMpmzOc84MxkwUSl
>> tPV48uw46UVpu4zOOByM
>> =zJGs
>> -END PGP SIGNATURE-
>>
>> On Sat, Sep 13, 2014 at 10:59 PM, Fedor Indutny 
>> wrote:
>>
>>> Here is an additional patch, to expose the type of key that should be
>>> used for a signature.
>>>
>>> On Thu, Sep 11, 2014 at 10:59 AM, Fedor Indutny via RT 
>>> wrote:
>>>
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA1
>>>>
>>>> Hello devs!
>>>>
>>>> Here is a patch that implements asynchronous RSA key operation
>>>> mode for a TLS/SSL implementation in OpenSSL.
>>>>
>>>> Here is some technical info about it:
>>>>
>>>> Support async RSA exchange by providing new SSL_want_rsa_sign(),
>>>> SSL_want_rsa_decrypt() API methods.
>>>>
>>>> After getting such want values - SSL_supply_key_ex_data() should be
>>>> invoked to continue handshake with a sign/decrypt data that was received
>>>> from the remote server.
>>>> - ---
>>>>  ssl/s3_srvr.c  | 398
>>>> -
>>>>  ssl/ssl.h  |  28 
>>>>  ssl/ssl3.h |   6 +
>>>>  ssl/ssl_lib.c  |  31 -
>>>>  ssl/ssl_locl.h |   2 +
>>>>  ssl/ssl_rsa.c  |  24 ++--
>>>>  ssl/ssltest.c  | 116 -
>>>>  test/testssl   |   6 +
>>>>  8 files changed, 475 insertions(+), 136 deletions(-)
>>>> -BEGIN PGP SIGNATURE-
>>>> Version: GnuPG v1
>>>>
>>>> iQIcBAEBAgAGBQJUEWeCAAoJENcGPM4Zt+iQPcoP/0R9wJz0gvqi5QFiGiAyOXyD
>>>> uWWB+lkGlB4r6AOhu1D02tQaQTaiRhSO3theSMOCZ4fQ+BMqZdyk37zq/6Z/rjnJ
>>>> jkd062SgYeh8WCvoJSoNF+gSeDgM/WnWw2q6R1Ls+DuYdQstym9+VIgx3LLd0LO8
>>>> 19mYHPUms0TFkzPfLqST4keHyZlLa1HzsEpdEQ8TWaU1vqqSrH6NfvPDjwwzMVWG
>>>> yMOW8tM8I2WDU9V6zMm+Mr7qmU/zowwVmOnVu0Mi8wBpcpN1GvFGbN8oXispnLc/
>>>> uccrKK1l98p3wnI0uXe5SmXWB5ksaEtz6CMewZotRgKR8dluwEHqIZ1mzE4+TMxK
>>>> iFDqUlCcRIjGgssGyjbHC23inwDeN1lZjOxE0G0dhzJZcYAYWJ2rWSQQGxBJJy5Z
>>>> VFxaElNImDyZ9uUFUtEhzGoaAV7isC9h78anTFzJMuJLTiukHERwFPvRgU/HQPNx
>>>> EG481cmnjJ2M2hyWRBrvCna8SftUPmGHczqDPD+Tt4Ry/msoZpdwEcLNossl6GcF
>>>> wXoAMeV5Jg8CenVobdLDQ53G1pJCcY58Zk+Ep9Va+DqfoEsyHc+XhhApMP8B4leC
>>>> R2mwi0KVL5F6NPhqJmDi1aXKtUu4A50j3yk35aJrEjQCKv3BW1gHvlL763Sve/GL
>>>> CAsACbfGic+GRS52Pmo2
>>>> =f3GH
>>>> -END PGP SIGNATURE-
>>>>
>>>>
>>>
>>
>


0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch
Description: Binary data


0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch.sig
Description: Binary data

Re: [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

And an additional follow-up, with docs and refined code.

On Fri, Sep 19, 2014 at 2:48 AM, Fedor Indutny  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Here is an example of how it could be used (in my TLS terminator):
>
> https://github.com/indutny/bud/compare/master...feature/async-key-ex
>
> Basically, if you have ever used async SSL API, you should be
> aware of things like:
>
> SSL_ERROR_WANT_READ
> SSL_ERROR_WANT_WRITE
>
> In addition to these two, my patch adds:
>
> SSL_ERROR_WANT_SIGN
> SSL_ERROR_WANT_RSA_DECRYPT
>
> If one of these is returned - you may get the data that should
> be signed/decrypted with:
>
> SSL_get_key_ex_data()
> SSL_get_key_ex_len()
>
> Get the key type (in case of SIGN):
>
> SSL_get_key_ex_type()
> // Returns EVP_PKEY_RSA, EVP_PKEY_ECC
>
> And get signature digest nid with:
>
> SSL_get_key_ex_md()
>
> Please be aware of the fact that `md` could be `NID_md5_sha1`,
> take a look at bud's code to figure out what should be done in
> this case (basically, you'll need to use raw
> `RSA_decrypt_private()`).
>
> After performing sign/decrypt (which could happen in other
> thread, or on a different server) you should call:
>
> SSL_supply_key_ex()
>
> to supply the result and continue handshake process. At
> this point `SSL_read()`/`SSL_write()` will start returning
> proper values.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJUG2D2AAoJENcGPM4Zt+iQJdoQAKZxbcGpzHFktSbU3uDocy3R
> fywWmqkYnoJ5jWF3xn4Excv4dAGhMfb/7tm9nt9zyV8g0Qsu8ChqWTl+kgK+hj9o
> mV+3jhqPDWR2VhmAC3J5ZsCpNm3IW/iNgGiU+u/k9N2i0WHjYSoTHM/NooN5GIu2
> KKhNXPw1Y05yxOZWmbUInMl/uscGWDtzylRNyJpfLFFu3JDQy1sBTKD6UAZC5ERY
> 7LUZ1TqVdk1DPY3Tf/j4IaB9Ds9teGLGj63J8upJhDjWHibFzV5bx6X+FjknUB9M
> xaebV4yfHZNRHseBu2ZqTQ2f2MNnXVisdzJRX6oyYeyq872MsJjAFhbFhFTi0sTI
> T8Y9n8cjuctbn+zTISVyVqEEBl8udWTY1t14SJ9lNcdU3xAf9OzEBVdORpUDqFl+
> zteRC145o7gs7mEtJjyBpy8mhXB3mc13ZkC2qaJIyqkqAPODu/xlqCga7oaogHNy
> Q2wy0HUeX69Ra0ada3TcJQgB14qESj3Uvq1hcgFk7SEXBxkU5NJ2OcItvU1+emd7
> hRlQvDqiiQcK9WgsdOIKZpovtT3FswhsIy0Tv77Nx9PY04urOTEgmhPJHveCJOQq
> i0apvI09YgimXs4Sd5h3rs9TsKrDtG0BG0jM1zfo5zbcKE2IbMpmzOc84MxkwUSl
> tPV48uw46UVpu4zOOByM
> =zJGs
> -END PGP SIGNATURE-
>
> On Sat, Sep 13, 2014 at 10:59 PM, Fedor Indutny  wrote:
>
>> Here is an additional patch, to expose the type of key that should be
>> used for a signature.
>>
>> On Thu, Sep 11, 2014 at 10:59 AM, Fedor Indutny via RT 
>> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Hello devs!
>>>
>>> Here is a patch that implements asynchronous RSA key operation
>>> mode for a TLS/SSL implementation in OpenSSL.
>>>
>>> Here is some technical info about it:
>>>
>>> Support async RSA exchange by providing new SSL_want_rsa_sign(),
>>> SSL_want_rsa_decrypt() API methods.
>>>
>>> After getting such want values - SSL_supply_key_ex_data() should be
>>> invoked to continue handshake with a sign/decrypt data that was received
>>> from the remote server.
>>> - ---
>>>  ssl/s3_srvr.c  | 398
>>> -
>>>  ssl/ssl.h  |  28 
>>>  ssl/ssl3.h |   6 +
>>>  ssl/ssl_lib.c  |  31 -
>>>  ssl/ssl_locl.h |   2 +
>>>  ssl/ssl_rsa.c  |  24 ++--
>>>  ssl/ssltest.c  | 116 -
>>>  test/testssl   |   6 +
>>>  8 files changed, 475 insertions(+), 136 deletions(-)
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1
>>>
>>> iQIcBAEBAgAGBQJUEWeCAAoJENcGPM4Zt+iQPcoP/0R9wJz0gvqi5QFiGiAyOXyD
>>> uWWB+lkGlB4r6AOhu1D02tQaQTaiRhSO3theSMOCZ4fQ+BMqZdyk37zq/6Z/rjnJ
>>> jkd062SgYeh8WCvoJSoNF+gSeDgM/WnWw2q6R1Ls+DuYdQstym9+VIgx3LLd0LO8
>>> 19mYHPUms0TFkzPfLqST4keHyZlLa1HzsEpdEQ8TWaU1vqqSrH6NfvPDjwwzMVWG
>>> yMOW8tM8I2WDU9V6zMm+Mr7qmU/zowwVmOnVu0Mi8wBpcpN1GvFGbN8oXispnLc/
>>> uccrKK1l98p3wnI0uXe5SmXWB5ksaEtz6CMewZotRgKR8dluwEHqIZ1mzE4+TMxK
>>> iFDqUlCcRIjGgssGyjbHC23inwDeN1lZjOxE0G0dhzJZcYAYWJ2rWSQQGxBJJy5Z
>>> VFxaElNImDyZ9uUFUtEhzGoaAV7isC9h78anTFzJMuJLTiukHERwFPvRgU/HQPNx
>>> EG481cmnjJ2M2hyWRBrvCna8SftUPmGHczqDPD+Tt4Ry/msoZpdwEcLNossl6GcF
>>> wXoAMeV5Jg8CenVobdLDQ53G1pJCcY58Zk+Ep9Va+DqfoEsyHc+XhhApMP8B4leC
>>> R2mwi0KVL5F6NPhqJmDi1aXKtUu4A50j3yk35aJrEjQCKv3BW1gHvlL763Sve/GL
>>> CAsACbfGic+GRS52Pmo2
>>> =f3GH
>>> -END PGP SIGNATURE-
>>>
>>>
>>
>


0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch
Description: Binary data


0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch.sig
Description: Binary data

Re: [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here is an example of how it could be used (in my TLS terminator):

https://github.com/indutny/bud/compare/master...feature/async-key-ex

Basically, if you have ever used async SSL API, you should be
aware of things like:

SSL_ERROR_WANT_READ
SSL_ERROR_WANT_WRITE

In addition to these two, my patch adds:

SSL_ERROR_WANT_SIGN
SSL_ERROR_WANT_RSA_DECRYPT

If one of these is returned - you may get the data that should
be signed/decrypted with:

SSL_get_key_ex_data()
SSL_get_key_ex_len()

Get the key type (in case of SIGN):

SSL_get_key_ex_type()
// Returns EVP_PKEY_RSA, EVP_PKEY_ECC

And get signature digest nid with:

SSL_get_key_ex_md()

Please be aware of the fact that `md` could be `NID_md5_sha1`,
take a look at bud's code to figure out what should be done in
this case (basically, you'll need to use raw
`RSA_decrypt_private()`).

After performing sign/decrypt (which could happen in other
thread, or on a different server) you should call:

SSL_supply_key_ex()

to supply the result and continue handshake process. At
this point `SSL_read()`/`SSL_write()` will start returning
proper values.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUG2D2AAoJENcGPM4Zt+iQJdoQAKZxbcGpzHFktSbU3uDocy3R
fywWmqkYnoJ5jWF3xn4Excv4dAGhMfb/7tm9nt9zyV8g0Qsu8ChqWTl+kgK+hj9o
mV+3jhqPDWR2VhmAC3J5ZsCpNm3IW/iNgGiU+u/k9N2i0WHjYSoTHM/NooN5GIu2
KKhNXPw1Y05yxOZWmbUInMl/uscGWDtzylRNyJpfLFFu3JDQy1sBTKD6UAZC5ERY
7LUZ1TqVdk1DPY3Tf/j4IaB9Ds9teGLGj63J8upJhDjWHibFzV5bx6X+FjknUB9M
xaebV4yfHZNRHseBu2ZqTQ2f2MNnXVisdzJRX6oyYeyq872MsJjAFhbFhFTi0sTI
T8Y9n8cjuctbn+zTISVyVqEEBl8udWTY1t14SJ9lNcdU3xAf9OzEBVdORpUDqFl+
zteRC145o7gs7mEtJjyBpy8mhXB3mc13ZkC2qaJIyqkqAPODu/xlqCga7oaogHNy
Q2wy0HUeX69Ra0ada3TcJQgB14qESj3Uvq1hcgFk7SEXBxkU5NJ2OcItvU1+emd7
hRlQvDqiiQcK9WgsdOIKZpovtT3FswhsIy0Tv77Nx9PY04urOTEgmhPJHveCJOQq
i0apvI09YgimXs4Sd5h3rs9TsKrDtG0BG0jM1zfo5zbcKE2IbMpmzOc84MxkwUSl
tPV48uw46UVpu4zOOByM
=zJGs
-END PGP SIGNATURE-

On Sat, Sep 13, 2014 at 10:59 PM, Fedor Indutny  wrote:

> Here is an additional patch, to expose the type of key that should be used
> for a signature.
>
> On Thu, Sep 11, 2014 at 10:59 AM, Fedor Indutny via RT 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hello devs!
>>
>> Here is a patch that implements asynchronous RSA key operation
>> mode for a TLS/SSL implementation in OpenSSL.
>>
>> Here is some technical info about it:
>>
>> Support async RSA exchange by providing new SSL_want_rsa_sign(),
>> SSL_want_rsa_decrypt() API methods.
>>
>> After getting such want values - SSL_supply_key_ex_data() should be
>> invoked to continue handshake with a sign/decrypt data that was received
>> from the remote server.
>> - ---
>>  ssl/s3_srvr.c  | 398
>> -
>>  ssl/ssl.h  |  28 
>>  ssl/ssl3.h |   6 +
>>  ssl/ssl_lib.c  |  31 -
>>  ssl/ssl_locl.h |   2 +
>>  ssl/ssl_rsa.c  |  24 ++--
>>  ssl/ssltest.c  | 116 -
>>  test/testssl   |   6 +
>>  8 files changed, 475 insertions(+), 136 deletions(-)
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJUEWeCAAoJENcGPM4Zt+iQPcoP/0R9wJz0gvqi5QFiGiAyOXyD
>> uWWB+lkGlB4r6AOhu1D02tQaQTaiRhSO3theSMOCZ4fQ+BMqZdyk37zq/6Z/rjnJ
>> jkd062SgYeh8WCvoJSoNF+gSeDgM/WnWw2q6R1Ls+DuYdQstym9+VIgx3LLd0LO8
>> 19mYHPUms0TFkzPfLqST4keHyZlLa1HzsEpdEQ8TWaU1vqqSrH6NfvPDjwwzMVWG
>> yMOW8tM8I2WDU9V6zMm+Mr7qmU/zowwVmOnVu0Mi8wBpcpN1GvFGbN8oXispnLc/
>> uccrKK1l98p3wnI0uXe5SmXWB5ksaEtz6CMewZotRgKR8dluwEHqIZ1mzE4+TMxK
>> iFDqUlCcRIjGgssGyjbHC23inwDeN1lZjOxE0G0dhzJZcYAYWJ2rWSQQGxBJJy5Z
>> VFxaElNImDyZ9uUFUtEhzGoaAV7isC9h78anTFzJMuJLTiukHERwFPvRgU/HQPNx
>> EG481cmnjJ2M2hyWRBrvCna8SftUPmGHczqDPD+Tt4Ry/msoZpdwEcLNossl6GcF
>> wXoAMeV5Jg8CenVobdLDQ53G1pJCcY58Zk+Ep9Va+DqfoEsyHc+XhhApMP8B4leC
>> R2mwi0KVL5F6NPhqJmDi1aXKtUu4A50j3yk35aJrEjQCKv3BW1gHvlL763Sve/GL
>> CAsACbfGic+GRS52Pmo2
>> =f3GH
>> -END PGP SIGNATURE-
>>
>>
>

Re: [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

Here is an additional patch, to expose the type of key that should be used
for a signature.

On Thu, Sep 11, 2014 at 10:59 AM, Fedor Indutny via RT 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello devs!
>
> Here is a patch that implements asynchronous RSA key operation
> mode for a TLS/SSL implementation in OpenSSL.
>
> Here is some technical info about it:
>
> Support async RSA exchange by providing new SSL_want_rsa_sign(),
> SSL_want_rsa_decrypt() API methods.
>
> After getting such want values - SSL_supply_key_ex_data() should be
> invoked to continue handshake with a sign/decrypt data that was received
> from the remote server.
> - ---
>  ssl/s3_srvr.c  | 398
> -
>  ssl/ssl.h  |  28 
>  ssl/ssl3.h |   6 +
>  ssl/ssl_lib.c  |  31 -
>  ssl/ssl_locl.h |   2 +
>  ssl/ssl_rsa.c  |  24 ++--
>  ssl/ssltest.c  | 116 -
>  test/testssl   |   6 +
>  8 files changed, 475 insertions(+), 136 deletions(-)
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJUEWeCAAoJENcGPM4Zt+iQPcoP/0R9wJz0gvqi5QFiGiAyOXyD
> uWWB+lkGlB4r6AOhu1D02tQaQTaiRhSO3theSMOCZ4fQ+BMqZdyk37zq/6Z/rjnJ
> jkd062SgYeh8WCvoJSoNF+gSeDgM/WnWw2q6R1Ls+DuYdQstym9+VIgx3LLd0LO8
> 19mYHPUms0TFkzPfLqST4keHyZlLa1HzsEpdEQ8TWaU1vqqSrH6NfvPDjwwzMVWG
> yMOW8tM8I2WDU9V6zMm+Mr7qmU/zowwVmOnVu0Mi8wBpcpN1GvFGbN8oXispnLc/
> uccrKK1l98p3wnI0uXe5SmXWB5ksaEtz6CMewZotRgKR8dluwEHqIZ1mzE4+TMxK
> iFDqUlCcRIjGgssGyjbHC23inwDeN1lZjOxE0G0dhzJZcYAYWJ2rWSQQGxBJJy5Z
> VFxaElNImDyZ9uUFUtEhzGoaAV7isC9h78anTFzJMuJLTiukHERwFPvRgU/HQPNx
> EG481cmnjJ2M2hyWRBrvCna8SftUPmGHczqDPD+Tt4Ry/msoZpdwEcLNossl6GcF
> wXoAMeV5Jg8CenVobdLDQ53G1pJCcY58Zk+Ep9Va+DqfoEsyHc+XhhApMP8B4leC
> R2mwi0KVL5F6NPhqJmDi1aXKtUu4A50j3yk35aJrEjQCKv3BW1gHvlL763Sve/GL
> CAsACbfGic+GRS52Pmo2
> =f3GH
> -END PGP SIGNATURE-
>
>


0002-ssl-support-non-RSA-key-signatures-in-key-ex.patch
Description: Binary data


0002-ssl-support-non-RSA-key-signatures-in-key-ex.patch.sig
Description: Binary data

[openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello devs!

Here is a patch that implements asynchronous RSA key operation
mode for a TLS/SSL implementation in OpenSSL.

Here is some technical info about it:

Support async RSA exchange by providing new SSL_want_rsa_sign(),
SSL_want_rsa_decrypt() API methods.

After getting such want values - SSL_supply_key_ex_data() should be
invoked to continue handshake with a sign/decrypt data that was received
from the remote server.
- ---
 ssl/s3_srvr.c  | 398
-
 ssl/ssl.h  |  28 
 ssl/ssl3.h |   6 +
 ssl/ssl_lib.c  |  31 -
 ssl/ssl_locl.h |   2 +
 ssl/ssl_rsa.c  |  24 ++--
 ssl/ssltest.c  | 116 -
 test/testssl   |   6 +
 8 files changed, 475 insertions(+), 136 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUEWeCAAoJENcGPM4Zt+iQPcoP/0R9wJz0gvqi5QFiGiAyOXyD
uWWB+lkGlB4r6AOhu1D02tQaQTaiRhSO3theSMOCZ4fQ+BMqZdyk37zq/6Z/rjnJ
jkd062SgYeh8WCvoJSoNF+gSeDgM/WnWw2q6R1Ls+DuYdQstym9+VIgx3LLd0LO8
19mYHPUms0TFkzPfLqST4keHyZlLa1HzsEpdEQ8TWaU1vqqSrH6NfvPDjwwzMVWG
yMOW8tM8I2WDU9V6zMm+Mr7qmU/zowwVmOnVu0Mi8wBpcpN1GvFGbN8oXispnLc/
uccrKK1l98p3wnI0uXe5SmXWB5ksaEtz6CMewZotRgKR8dluwEHqIZ1mzE4+TMxK
iFDqUlCcRIjGgssGyjbHC23inwDeN1lZjOxE0G0dhzJZcYAYWJ2rWSQQGxBJJy5Z
VFxaElNImDyZ9uUFUtEhzGoaAV7isC9h78anTFzJMuJLTiukHERwFPvRgU/HQPNx
EG481cmnjJ2M2hyWRBrvCna8SftUPmGHczqDPD+Tt4Ry/msoZpdwEcLNossl6GcF
wXoAMeV5Jg8CenVobdLDQ53G1pJCcY58Zk+Ep9Va+DqfoEsyHc+XhhApMP8B4leC
R2mwi0KVL5F6NPhqJmDi1aXKtUu4A50j3yk35aJrEjQCKv3BW1gHvlL763Sve/GL
CAsACbfGic+GRS52Pmo2
=f3GH
-END PGP SIGNATURE-



0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch
Description: Binary data


0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch.sig
Description: Binary data

[PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello devs!

Here is a patch that implements asynchronous RSA key operation
mode for a TLS/SSL implementation in OpenSSL.

Here is some technical info about it:

Support async RSA exchange by providing new SSL_want_rsa_sign(),
SSL_want_rsa_decrypt() API methods.

After getting such want values - SSL_supply_key_ex_data() should be
invoked to continue handshake with a sign/decrypt data that was received
from the remote server.
- ---
 ssl/s3_srvr.c  | 398
-
 ssl/ssl.h  |  28 
 ssl/ssl3.h |   6 +
 ssl/ssl_lib.c  |  31 -
 ssl/ssl_locl.h |   2 +
 ssl/ssl_rsa.c  |  24 ++--
 ssl/ssltest.c  | 116 -
 test/testssl   |   6 +
 8 files changed, 475 insertions(+), 136 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUEWeCAAoJENcGPM4Zt+iQPcoP/0R9wJz0gvqi5QFiGiAyOXyD
uWWB+lkGlB4r6AOhu1D02tQaQTaiRhSO3theSMOCZ4fQ+BMqZdyk37zq/6Z/rjnJ
jkd062SgYeh8WCvoJSoNF+gSeDgM/WnWw2q6R1Ls+DuYdQstym9+VIgx3LLd0LO8
19mYHPUms0TFkzPfLqST4keHyZlLa1HzsEpdEQ8TWaU1vqqSrH6NfvPDjwwzMVWG
yMOW8tM8I2WDU9V6zMm+Mr7qmU/zowwVmOnVu0Mi8wBpcpN1GvFGbN8oXispnLc/
uccrKK1l98p3wnI0uXe5SmXWB5ksaEtz6CMewZotRgKR8dluwEHqIZ1mzE4+TMxK
iFDqUlCcRIjGgssGyjbHC23inwDeN1lZjOxE0G0dhzJZcYAYWJ2rWSQQGxBJJy5Z
VFxaElNImDyZ9uUFUtEhzGoaAV7isC9h78anTFzJMuJLTiukHERwFPvRgU/HQPNx
EG481cmnjJ2M2hyWRBrvCna8SftUPmGHczqDPD+Tt4Ry/msoZpdwEcLNossl6GcF
wXoAMeV5Jg8CenVobdLDQ53G1pJCcY58Zk+Ep9Va+DqfoEsyHc+XhhApMP8B4leC
R2mwi0KVL5F6NPhqJmDi1aXKtUu4A50j3yk35aJrEjQCKv3BW1gHvlL763Sve/GL
CAsACbfGic+GRS52Pmo2
=f3GH
-END PGP SIGNATURE-


0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch
Description: Binary data


0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch.sig
Description: Binary data

Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve

[Fedor Indutny]

Nevermind, I just realized that it is using Client certificate there and
doesn't needs to be asyncified.


On Fri, Aug 29, 2014 at 12:54 AM, Fedor Indutny  wrote:

> Oh, and I have just realized that it doesn't handle `ssl3_get_cert_verify`
> case right now.
>
> I'll figure it out tomorrow.
>
>
> On Thu, Aug 28, 2014 at 2:26 PM, Fedor Indutny  wrote:
>
>> Hello again!
>>
>> Here is a second patch that improves the first one. Additionally it
>> copies and restores the packet
>> data before/after calling out async callback. However it is almost
>> evident for me that nothing
>> could overwrite `s->init_buf->data` during async handshake, so if you
>> feel confident about it -
>> please let me know and I will revert everything except style changes in
>> that 0002 patch.
>>
>>  Cheers,
>> Fedor.
>>
>>
>> On Wed, Aug 27, 2014 at 1:05 PM, Fedor Indutny  wrote:
>>
>>> Oops, just realized that I pasted whole commit message into a subject.
>>>
>>> Anyway, CCing Rich Salz here.
>>>
>>> Rich,
>>>
>>> You seem to be on a wave on triaging tickets, may be you could take a
>>> look at this one eventually?
>>>
>>> Thank you,
>>> Fedor.
>>>
>>>
>>> On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny 
>>> wrote:
>>>
>>>> This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and
>>>> `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present:
>>>>
>>>> * Server will ignore dummy RSA key, assuming that it is matching the
>>>>   certificate.
>>>> * Server will invoke this callback with either:
>>>>   * `SSL_KEY_EX_RSA`
>>>>   * `SSL_KEY_EX_RSA_SIGN`
>>>>   as a `type` argument, and some data for signature or decryption in
>>>>   `p`/`n` pair.
>>>>
>>>> At that time the sign/decryption may be performed on any thread, or even
>>>> remotely, and the result should be supplied with `SSL_supply()`. Calling
>>>> `SSL_supply()` will continue the handshake process without even touching
>>>> the real private key.
>>>>
>>>> NOTE:
>>>>
>>>> The test is missing right now, I'll add it once we will figure out how
>>>> the API should look like. Implementation appears to be working when used
>>>> with node.js, see
>>>> https://github.com/indutny/node/tree/feature/async-key-exchange and
>>>> https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing.
>>>>
>>>> ANOTHER NOTE:
>>>>
>>>> Pull Request on github: https://github.com/openssl/openssl/pull/162
>>>>
>>>
>>>
>>
>

Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve

[Fedor Indutny]

Oh, and I have just realized that it doesn't handle `ssl3_get_cert_verify`
case right now.

I'll figure it out tomorrow.


On Thu, Aug 28, 2014 at 2:26 PM, Fedor Indutny  wrote:

> Hello again!
>
> Here is a second patch that improves the first one. Additionally it copies
> and restores the packet
> data before/after calling out async callback. However it is almost evident
> for me that nothing
> could overwrite `s->init_buf->data` during async handshake, so if you feel
> confident about it -
> please let me know and I will revert everything except style changes in
> that 0002 patch.
>
>  Cheers,
> Fedor.
>
>
> On Wed, Aug 27, 2014 at 1:05 PM, Fedor Indutny  wrote:
>
>> Oops, just realized that I pasted whole commit message into a subject.
>>
>> Anyway, CCing Rich Salz here.
>>
>> Rich,
>>
>> You seem to be on a wave on triaging tickets, may be you could take a
>> look at this one eventually?
>>
>> Thank you,
>> Fedor.
>>
>>
>> On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny 
>> wrote:
>>
>>> This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and
>>> `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present:
>>>
>>> * Server will ignore dummy RSA key, assuming that it is matching the
>>>   certificate.
>>> * Server will invoke this callback with either:
>>>   * `SSL_KEY_EX_RSA`
>>>   * `SSL_KEY_EX_RSA_SIGN`
>>>   as a `type` argument, and some data for signature or decryption in
>>>   `p`/`n` pair.
>>>
>>> At that time the sign/decryption may be performed on any thread, or even
>>> remotely, and the result should be supplied with `SSL_supply()`. Calling
>>> `SSL_supply()` will continue the handshake process without even touching
>>> the real private key.
>>>
>>> NOTE:
>>>
>>> The test is missing right now, I'll add it once we will figure out how
>>> the API should look like. Implementation appears to be working when used
>>> with node.js, see
>>> https://github.com/indutny/node/tree/feature/async-key-exchange and
>>> https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing.
>>>
>>> ANOTHER NOTE:
>>>
>>> Pull Request on github: https://github.com/openssl/openssl/pull/162
>>>
>>
>>
>

Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve

[Fedor Indutny]

Hello again!

Here is a second patch that improves the first one. Additionally it copies
and restores the packet
data before/after calling out async callback. However it is almost evident
for me that nothing
could overwrite `s->init_buf->data` during async handshake, so if you feel
confident about it -
please let me know and I will revert everything except style changes in
that 0002 patch.

Cheers,
Fedor.


On Wed, Aug 27, 2014 at 1:05 PM, Fedor Indutny  wrote:

> Oops, just realized that I pasted whole commit message into a subject.
>
> Anyway, CCing Rich Salz here.
>
> Rich,
>
> You seem to be on a wave on triaging tickets, may be you could take a look
> at this one eventually?
>
> Thank you,
> Fedor.
>
>
> On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny  wrote:
>
>> This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and
>> `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present:
>>
>> * Server will ignore dummy RSA key, assuming that it is matching the
>>   certificate.
>> * Server will invoke this callback with either:
>>   * `SSL_KEY_EX_RSA`
>>   * `SSL_KEY_EX_RSA_SIGN`
>>   as a `type` argument, and some data for signature or decryption in
>>   `p`/`n` pair.
>>
>> At that time the sign/decryption may be performed on any thread, or even
>> remotely, and the result should be supplied with `SSL_supply()`. Calling
>> `SSL_supply()` will continue the handshake process without even touching
>> the real private key.
>>
>> NOTE:
>>
>> The test is missing right now, I'll add it once we will figure out how
>> the API should look like. Implementation appears to be working when used
>> with node.js, see
>> https://github.com/indutny/node/tree/feature/async-key-exchange and
>> https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing.
>>
>> ANOTHER NOTE:
>>
>> Pull Request on github: https://github.com/openssl/openssl/pull/162
>>
>
>


0002-ssl-copy-packet-before-performing-async-key-ex.patch.sig
Description: Binary data


0002-ssl-copy-packet-before-performing-async-key-ex.patch
Description: Binary data

Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve

[Fedor Indutny]

Oops, just realized that I pasted whole commit message into a subject.

Anyway, CCing Rich Salz here.

Rich,

You seem to be on a wave on triaging tickets, may be you could take a look
at this one eventually?

Thank you,
Fedor.


On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny  wrote:

> This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and
> `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present:
>
> * Server will ignore dummy RSA key, assuming that it is matching the
>   certificate.
> * Server will invoke this callback with either:
>   * `SSL_KEY_EX_RSA`
>   * `SSL_KEY_EX_RSA_SIGN`
>   as a `type` argument, and some data for signature or decryption in
>   `p`/`n` pair.
>
> At that time the sign/decryption may be performed on any thread, or even
> remotely, and the result should be supplied with `SSL_supply()`. Calling
> `SSL_supply()` will continue the handshake process without even touching
> the real private key.
>
> NOTE:
>
> The test is missing right now, I'll add it once we will figure out how the
> API should look like. Implementation appears to be working when used with
> node.js, see
> https://github.com/indutny/node/tree/feature/async-key-exchange and
> https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing.
>
> ANOTHER NOTE:
>
> Pull Request on github: https://github.com/openssl/openssl/pull/162
>

Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Server wi

[Fedor Indutny]

This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and
`SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present:

* Server will ignore dummy RSA key, assuming that it is matching the
  certificate.
* Server will invoke this callback with either:
  * `SSL_KEY_EX_RSA`
  * `SSL_KEY_EX_RSA_SIGN`
  as a `type` argument, and some data for signature or decryption in
  `p`/`n` pair.

At that time the sign/decryption may be performed on any thread, or even
remotely, and the result should be supplied with `SSL_supply()`. Calling
`SSL_supply()` will continue the handshake process without even touching
the real private key.

NOTE:

The test is missing right now, I'll add it once we will figure out how the
API should look like. Implementation appears to be working when used with
node.js, see https://github.com/indutny/node/tree/feature/async-key-exchange
and https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing.

ANOTHER NOTE:

Pull Request on github: https://github.com/openssl/openssl/pull/162


0001-ssl-introduce-async-sign-decrypt-APIs.patch
Description: Binary data


0001-ssl-introduce-async-sign-decrypt-APIs.patch.sig
Description: Binary data

Re: Forcing client to send Certificate record

[Fedor Indutny]

Viktor,

Despite being a protocol violation, it is accepted by the OpenSSL's server
implementation.

But I do see now that this is indeed covered by RFC 5246. Sorry, I have
missed that line in
the Client Certificate section.


On Wed, Aug 13, 2014 at 1:48 AM, Salz, Rich  wrote:

> > There is no need for an API for a non-interoperable feature that would
> > violate the TLS protocol:
> >
> > https://tools.ietf.org/html/rfc5246#section-7.4.6
>
> Perhaps more usefully, see
> http://datatracker.ietf.org/doc/draft-thomson-tls-care/
>
> This will almost definitely be part of TLS 1.3.  Note that it's
> version-neutral, so it will probably show up in other stacks as well.
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge MA
> IM: rs...@jabber.me Twitter: RichSalz
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>

Forcing client to send Certificate record

[Fedor Indutny]

Heya!

I just discovered that there is no way to force OpenSSL SSL client to send
Certificate rercord if server hasn't sent CertificateRequest.

Would a patch that will this API hole be welcome? What API do you guys have
in mind?

Cheers,
Fedor.

Re: [openssl.org #3397] Fwd: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

[Fedor Indutny]

I'm totally willing to cooperate on this, and may have enough skills to do
it.

Do you think it could be possible for us to collaborate on this topic?

Thank you,
Fedor.


On Wed, Jul 2, 2014 at 11:08 PM, Andy Polyakov via RT 
wrote:

> > I'd still pull Adam's changes, at least for consistency reasons. Other
> > assembly files seems to be using signed comparison for the same kinds of
> > operations.
> >
> > What do you think about it?
>
> I think it's appropriate to harmonize branches with interface. But it
> takes deal of concentration and unfortunately for this moment I'm
> limited in time. As mentioned, solution is *interim* and I leave the
> ticket open with intention to come back to it and resolve it by
> double-checking all modules, harmonizing branches and implementing
> bn_mul_mont_eligible (or similar).
>
>
>

Re: [openssl.org #3397] Fwd: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

[Fedor Indutny via RT]

I'm totally willing to cooperate on this, and may have enough skills to do
it.

Do you think it could be possible for us to collaborate on this topic?

Thank you,
Fedor.


On Wed, Jul 2, 2014 at 11:08 PM, Andy Polyakov via RT 
wrote:

> > I'd still pull Adam's changes, at least for consistency reasons. Other
> > assembly files seems to be using signed comparison for the same kinds of
> > operations.
> >
> > What do you think about it?
>
> I think it's appropriate to harmonize branches with interface. But it
> takes deal of concentration and unfortunately for this moment I'm
> limited in time. As mentioned, solution is *interim* and I leave the
> ticket open with intention to come back to it and resolve it by
> double-checking all modules, harmonizing branches and implementing
> bn_mul_mont_eligible (or similar).
>
>
>

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3397] Fwd: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

[Fedor Indutny via RT]

Andy,

I'd still pull Adam's changes, at least for consistency reasons. Other
assembly files seems to be using signed comparison for the same kinds of
operations.

What do you think about it?

Cheers,
Fedor.


On Wed, Jul 2, 2014 at 9:54 PM, Andy Polyakov via RT  wrote:

> > Discovered this problem while trying to fix
> > https://github.com/joyent/node/issues/7704.
> >
> > Attached is a fix for it.
>
> Trouble is that modified code might avoid crash, but it doesn't produce
> correct result either. [No, not even Adam's suggestion]. Actually
> bn_mul_mont is abused in bn_exp.c, because it's actually allowed to do
> nothing depending on arguments, which is noted by zero return value. The
> criteria for doing nothing is platform-specific, for example some
> platforms insist that number of elements in even and data pointers are
> aligned in specific manner. But there is one common criteria and it is
> requirement that number of elements is larger than one. Correct solution
> would be to introduce for example bn_mul_mont_eligible call that could
> be queried prior taking the path calling bn_mul_mont. For the moment
> there is only one platform that have this path, x86_64, and as interim
> measure it's possible to implement the boundary condition check as
>
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=eca441b2b4d33d2a18d163ef9b4b3aff14251c73
> .
>
>
>

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3397] Fwd: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

[Fedor Indutny]

Andy,

I'd still pull Adam's changes, at least for consistency reasons. Other
assembly files seems to be using signed comparison for the same kinds of
operations.

What do you think about it?

Cheers,
Fedor.


On Wed, Jul 2, 2014 at 9:54 PM, Andy Polyakov via RT  wrote:

> > Discovered this problem while trying to fix
> > https://github.com/joyent/node/issues/7704.
> >
> > Attached is a fix for it.
>
> Trouble is that modified code might avoid crash, but it doesn't produce
> correct result either. [No, not even Adam's suggestion]. Actually
> bn_mul_mont is abused in bn_exp.c, because it's actually allowed to do
> nothing depending on arguments, which is noted by zero return value. The
> criteria for doing nothing is platform-specific, for example some
> platforms insist that number of elements in even and data pointers are
> aligned in specific manner. But there is one common criteria and it is
> requirement that number of elements is larger than one. Correct solution
> would be to introduce for example bn_mul_mont_eligible call that could
> be queried prior taking the path calling bn_mul_mont. For the moment
> there is only one platform that have this path, x86_64, and as interim
> measure it's possible to implement the boundary condition check as
>
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=eca441b2b4d33d2a18d163ef9b4b3aff14251c73
> .
>
>
>

[openssl.org #3397] Fwd: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

[Fedor Indutny via RT]

Hello everyone!

Discovered this problem while trying to fix
https://github.com/joyent/node/issues/7704.

Attached is a fix for it.

Cheers,
Fedor.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- From c6a4d5ff66cd886023f75780e876053f019ed8de Mon Sep 17 00:00:00 2001
From: Fedor Indutny 
Date: Fri, 6 Jun 2014 14:33:10 -0700
Subject: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

Fix index overflow in bn_mul_mont and bn_mul_mont_gather5.
- ---
 crypto/bn/asm/x86_64-mont.pl  | 4 ++--
 crypto/bn/asm/x86_64-mont5.pl | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/crypto/bn/asm/x86_64-mont.pl b/crypto/bn/asm/x86_64-mont.pl
index 3803928..7ec1654 100755
- --- a/crypto/bn/asm/x86_64-mont.pl
+++ b/crypto/bn/asm/x86_64-mont.pl
@@ -174,7 +174,7 @@ $code.=<<___;
 
mulq$m1 # np[j]*m1
cmp $num,$j
- - jne .L1st
+   jl  .L1st
 
add %rax,$hi1
mov ($ap),%rax  # ap[0]
@@ -240,7 +240,7 @@ $code.=<<___;
 
mulq$m1 # np[j]*m1
cmp $num,$j
- - jne .Linner
+   jl  .Linner
 
add %rax,$hi1
mov ($ap),%rax  # ap[0]
diff --git a/crypto/bn/asm/x86_64-mont5.pl b/crypto/bn/asm/x86_64-mont5.pl
index c107df9..5cc0689 100755
- --- a/crypto/bn/asm/x86_64-mont5.pl
+++ b/crypto/bn/asm/x86_64-mont5.pl
@@ -207,7 +207,7 @@ $code.=<<___;
 
mulq$m1 # np[j]*m1
cmp $num,$j
- - jne .L1st
+   jl  .L1st
 
movq%xmm0,$m0   # bp[1]
 
@@ -290,7 +290,7 @@ $code.=<<___;
 
mulq$m1 # np[j]*m1
cmp $num,$j
- - jne .Linner
+   jl  .Linner
 
movq%xmm0,$m0   # bp[i+1]
 
- -- 
1.9.3

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTkjPhAAoJEPsOEJWxeXmZc00P/3KY+9WOVwZ2Ad+1uqRquxAQ
zlLDmhRAae0Z7mGrsExW9EHOu0RD8sMgX901uy4CAKOPon86skxbe70TPJ+8ZmMv
tGgHrJhGos6fe6x47r9KgpYFng3lltN/i6rgArDnK9fZa5+7n9/Txz/NjMUgVMd/
Fw0zAvqOqpy5Q5YxgD85tBMInZqliYiV2NGKa7hHlnCcWzqEEZThy0LpAltb4L4c
bBAviH6EzxFWE4i7f9Id0e6V0taoN5LMM0Ia2UikCXlA1sPchwojirmXEVu/vvYu
AnBsnBYLUSxHCnUFOT/EezAkiZlXnQEr8ZGOmoxfPWWrFJ4rMuxgZpjrZbZ6cIwf
CTgP0SxUQkftbP354aAJGeP8c4AtRP/PLEFB1rZovbVC0v99wzAo9xb69yXy+hUR
3D2C1Xcj7TYS2wB+u4sbUvluaLIWLTFCRxiONqNhG3J7oQQHrkleWkhrktbcQBxi
Rotqtn34zkPN6cYWjjc6j6Ww6fQpKRsyRb677fe695Jp/MgRcsg/QTz+uVg5U3HS
tt/9XDm6fg6FKD7PgBNn5okoDkKtWSRUOEUddy28B/YSB/c7AVWvbH6cLW3dp0iF
20/YuGEWSogzOEcy8Tsn0I3owLSMOe5fSCtYMoFJRCD1hlgonXpbEMMq85dnF/vg
JT5UiUwprJ54GkHFnhDX
=j4Ho
-END PGP SIGNATURE-


0001-x86_64-asm-fix-bn_mul_mont-on-odd-len-BNs.patch
Description: Binary data

Re: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

[Fedor Indutny]

Bump.


On Fri, Jun 6, 2014 at 2:35 PM, Fedor Indutny  wrote:

> Hello everyone!
>
> Discovered this problem while trying to fix
> https://github.com/joyent/node/issues/7704.
>
> Attached is a fix for it.
>
> Cheers,
> Fedor.
>

[PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

[Fedor Indutny]

Hello everyone!

Discovered this problem while trying to fix
https://github.com/joyent/node/issues/7704.

Attached is a fix for it.

Cheers,
Fedor.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- From c6a4d5ff66cd886023f75780e876053f019ed8de Mon Sep 17 00:00:00 2001
From: Fedor Indutny 
Date: Fri, 6 Jun 2014 14:33:10 -0700
Subject: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

Fix index overflow in bn_mul_mont and bn_mul_mont_gather5.
- ---
 crypto/bn/asm/x86_64-mont.pl  | 4 ++--
 crypto/bn/asm/x86_64-mont5.pl | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/crypto/bn/asm/x86_64-mont.pl b/crypto/bn/asm/x86_64-mont.pl
index 3803928..7ec1654 100755
- --- a/crypto/bn/asm/x86_64-mont.pl
+++ b/crypto/bn/asm/x86_64-mont.pl
@@ -174,7 +174,7 @@ $code.=<<___;
 
mulq$m1 # np[j]*m1
cmp $num,$j
- - jne .L1st
+   jl  .L1st
 
add %rax,$hi1
mov ($ap),%rax  # ap[0]
@@ -240,7 +240,7 @@ $code.=<<___;
 
mulq$m1 # np[j]*m1
cmp $num,$j
- - jne .Linner
+   jl  .Linner
 
add %rax,$hi1
mov ($ap),%rax  # ap[0]
diff --git a/crypto/bn/asm/x86_64-mont5.pl b/crypto/bn/asm/x86_64-mont5.pl
index c107df9..5cc0689 100755
- --- a/crypto/bn/asm/x86_64-mont5.pl
+++ b/crypto/bn/asm/x86_64-mont5.pl
@@ -207,7 +207,7 @@ $code.=<<___;
 
mulq$m1 # np[j]*m1
cmp $num,$j
- - jne .L1st
+   jl  .L1st
 
movq%xmm0,$m0   # bp[1]
 
@@ -290,7 +290,7 @@ $code.=<<___;
 
mulq$m1 # np[j]*m1
cmp $num,$j
- - jne .Linner
+   jl  .Linner
 
movq%xmm0,$m0   # bp[i+1]
 
- -- 
1.9.3

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTkjPhAAoJEPsOEJWxeXmZc00P/3KY+9WOVwZ2Ad+1uqRquxAQ
zlLDmhRAae0Z7mGrsExW9EHOu0RD8sMgX901uy4CAKOPon86skxbe70TPJ+8ZmMv
tGgHrJhGos6fe6x47r9KgpYFng3lltN/i6rgArDnK9fZa5+7n9/Txz/NjMUgVMd/
Fw0zAvqOqpy5Q5YxgD85tBMInZqliYiV2NGKa7hHlnCcWzqEEZThy0LpAltb4L4c
bBAviH6EzxFWE4i7f9Id0e6V0taoN5LMM0Ia2UikCXlA1sPchwojirmXEVu/vvYu
AnBsnBYLUSxHCnUFOT/EezAkiZlXnQEr8ZGOmoxfPWWrFJ4rMuxgZpjrZbZ6cIwf
CTgP0SxUQkftbP354aAJGeP8c4AtRP/PLEFB1rZovbVC0v99wzAo9xb69yXy+hUR
3D2C1Xcj7TYS2wB+u4sbUvluaLIWLTFCRxiONqNhG3J7oQQHrkleWkhrktbcQBxi
Rotqtn34zkPN6cYWjjc6j6Ww6fQpKRsyRb677fe695Jp/MgRcsg/QTz+uVg5U3HS
tt/9XDm6fg6FKD7PgBNn5okoDkKtWSRUOEUddy28B/YSB/c7AVWvbH6cLW3dp0iF
20/YuGEWSogzOEcy8Tsn0I3owLSMOe5fSCtYMoFJRCD1hlgonXpbEMMq85dnF/vg
JT5UiUwprJ54GkHFnhDX
=j4Ho
-END PGP SIGNATURE-


0001-x86_64-asm-fix-bn_mul_mont-on-odd-len-BNs.patch
Description: Binary data

Re: Start Contributing

[Fedor Indutny]

Hello Team!

I'd like to contribute some stuff too, let me know if I could help.

Thanks,
Fedor.


On Wed, Apr 23, 2014 at 9:17 PM, Daniel Hamacher <
danielhamacher...@gmail.com> wrote:

> Hi OpenSSL Team,
>
>
>
> Any suggestions on how to contribute. Are there specific requirements I
> need to have?
>
>
>
> Thanks,
>
> Daniel
>

[openssl.org #3323] Fwd: Cert chain inconsistency between client and server

[Fedor Indutny via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello devs!

It has just caught my attention that `SSL_get_peer_cert_chain` does
not contain `SSL_get_peer_certificate`'s value for server, but it does for
client.

Would you mind accepting patch for fixing it?

Here are relevant lines of code:

* client:
https://github.com/openssl/openssl/blob/300b9f0b704048f60776881f1d378c74d9c32fbd/ssl/s3_clnt.c#L1312-L1315
* server:
https://github.com/openssl/openssl/blob/300b9f0b704048f60776881f1d378c74d9c32fbd/ssl/s3_srvr.c#L3461-L3477

Cheers,
Fedor.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTUGdXAAoJEPsOEJWxeXmZwokQAIISCTOnQwCBeX7kBJgEdWeg
nJTDiHMM+I6bBm/C1ZkiodkIapPX+w7RAHE1OxYaqgeCKp7JWO+Bey6qQfroxJ1U
q9FtOBFzqg4O5fB6+MwbhWUXyqJE5cAgVxXeU2E9MokDNFvOpGXXtOmmRv7sBGMO
i0d5L0Fs7YS56eHYGxuy8qf7KrCswJ9muGcr/f/XNHiR6ZU0HliJRnrdoLRsiQAM
SdwtTe2L2FNeBG+q9Czh/nch5RhEv9hucnV9IPpFehzAfn3404y9wH0eBNpNnYlf
g48ccSTqTgyQQG/OlNeLbOD41qRHdUoZZ85ueU+2Gw4WrjhMxwi3fxNgU8ml5Ik+
4HINmeAshkksycWfx5tdnBXZy3iguurzpe7C9NoHl0fDJf8VCvn7sAEM50t+4ftM
4j1EqisQZufLp5R4WLlUVUHDk3bopjFvRqlZoal9SdFdUeqzqv6BDtEEKxv+6LRO
D86SsHRnpazfgkqdoizI+cZgo0b3IdRs8bsOZ4IR5RCKNt8YROEwlXqV1CueKyZJ
zpz8xkXv+tezREsiFwe2rR7iNtwqNnANwEAViH/b0GpR5IFcenKRbb/UprOVsrgF
4AlpyBPcheVRblOn4FRvUDGnQ8vNa4QW+5jxlRZuEXpaJot0xMMBFSCISUsE4bZ3
L+7POMtxSlEVXI1zChMw
=/o6W
-END PGP SIGNATURE-

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Cert chain inconsistency between client and server

[Fedor Indutny]

Ok, that's what I was actually thinking about.

Thank you very much for looking at it!


On Mon, Apr 21, 2014 at 9:56 PM, Dr. Stephen Henson wrote:

> On Fri, Apr 18, 2014, Fedor Indutny wrote:
>
> > Hello devs!
> >
> > It has just caught my attention that `SSL_get_peer_cert_chain` does
> > not contain `SSL_get_peer_certificate`'s value for server, but it does
> for
> > client.
> >
> > Would you mind accepting patch for fixing it?
> >
>
> The problem is that that inconsistency has been about for a very long time
> and
> changing it will break applications that rely on the existing behaviour.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: Cert chain inconsistency between client and server

[Fedor Indutny]

Is there any way to get some sort of feedback on it?

I have tried submitting it to r...@openssl.org, but got not reply from the
server, and
can't see it on the website.

Cheers,
Fedor.


On Mon, Apr 21, 2014 at 8:16 PM, Fedor Indutny  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello devs!
>
> It has just caught my attention that `SSL_get_peer_cert_chain` does
> not contain `SSL_get_peer_certificate`'s value for server, but it does for
> client.
>
> Would you mind accepting patch for fixing it?
>
> Here are relevant lines of code:
>
> * client:
> https://github.com/openssl/openssl/blob/300b9f0b704048f60776881f1d378c74d9c32fbd/ssl/s3_clnt.c#L1312-L1315
> * server:
> https://github.com/openssl/openssl/blob/300b9f0b704048f60776881f1d378c74d9c32fbd/ssl/s3_srvr.c#L3461-L3477
>
> Cheers,
> Fedor.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJTUGdXAAoJEPsOEJWxeXmZwokQAIISCTOnQwCBeX7kBJgEdWeg
> nJTDiHMM+I6bBm/C1ZkiodkIapPX+w7RAHE1OxYaqgeCKp7JWO+Bey6qQfroxJ1U
> q9FtOBFzqg4O5fB6+MwbhWUXyqJE5cAgVxXeU2E9MokDNFvOpGXXtOmmRv7sBGMO
> i0d5L0Fs7YS56eHYGxuy8qf7KrCswJ9muGcr/f/XNHiR6ZU0HliJRnrdoLRsiQAM
> SdwtTe2L2FNeBG+q9Czh/nch5RhEv9hucnV9IPpFehzAfn3404y9wH0eBNpNnYlf
> g48ccSTqTgyQQG/OlNeLbOD41qRHdUoZZ85ueU+2Gw4WrjhMxwi3fxNgU8ml5Ik+
> 4HINmeAshkksycWfx5tdnBXZy3iguurzpe7C9NoHl0fDJf8VCvn7sAEM50t+4ftM
> 4j1EqisQZufLp5R4WLlUVUHDk3bopjFvRqlZoal9SdFdUeqzqv6BDtEEKxv+6LRO
> D86SsHRnpazfgkqdoizI+cZgo0b3IdRs8bsOZ4IR5RCKNt8YROEwlXqV1CueKyZJ
> zpz8xkXv+tezREsiFwe2rR7iNtwqNnANwEAViH/b0GpR5IFcenKRbb/UprOVsrgF
> 4AlpyBPcheVRblOn4FRvUDGnQ8vNa4QW+5jxlRZuEXpaJot0xMMBFSCISUsE4bZ3
> L+7POMtxSlEVXI1zChMw
> =/o6W
> -END PGP SIGNATURE-
>
>

Re: Cert chain inconsistency between client and server

[Fedor Indutny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry for a short follow-up. If the fix is needed -
which behavior is more desired - the client's one or
server's one?

Fedor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTUGiJAAoJEPsOEJWxeXmZCH8P/1Lz7Fj/M8YhACvWGzGFO4WB
4Ww3UrwbIFeB2gGQJE7r69QFgfVX7NSo+WuUIYIzqzhTqfbqkUpoZMEw4guRcVkV
11d2pAMsSn+1BUtXtvYvlDkunNWog+jUftHAcdxLMvXjE+rU/DqSj2hhkVNhvL8M
k5yQzkKATZUDvUcVuFOvgbImIeZ0aA0EiqXEDcori1MzBhJyXC2HDajj9q0Fd6hG
EdRRHz3lQi1chrGNiGd4dMhVKELnq18AqWSEVpzi0hHFhkO65h+eoAVNZBGBL79c
lQDjdYR92i7HQm+p11w0wrcYMowGrE1yETYSi4m6OR4tmVIhu8XtGxWJnoa3DqNW
g3SbvZFVKAXL5anLy4E4mP6eeRlmVQY5PAiHa/x7zGPPpWtc+0RqKxcJXi8n/MHi
oi+DBzpQmracHCgyZULKyXdTh4nzr5gJNZexVyBV2CX0qGdYdEMMVGLHWGyRbqcv
WwQYAfLWpAQZZPHK7Vakg5fw+Lb4kL6nbQngvnUh5xVsi8apyVMLDtG++Rdsa+ht
Hce6eWt70eSzMMelxEG3A3e+XX7BTFfOTbcHnLkQgW9cv1evqc9Nt00+Kj7rjPq7
DzYRzWmdfgU8KWuqmjrrK0GpzblGJMdzdpFjimR348Q1WFGks/9cM4J558GEY+jD
Jg8GUmefWPEAL/e3lWGq
=21v4
-END PGP SIGNATURE-


On Fri, Apr 18, 2014 at 3:44 AM, Fedor Indutny  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello devs!
>
> It has just caught my attention that `SSL_get_peer_cert_chain` does
> not contain `SSL_get_peer_certificate`'s value for server, but it does for
> client.
>
> Would you mind accepting patch for fixing it?
>
> Here are relevant lines of code:
>
> * client:
> https://github.com/openssl/openssl/blob/300b9f0b704048f60776881f1d378c74d9c32fbd/ssl/s3_clnt.c#L1312-L1315
> * server:
> https://github.com/openssl/openssl/blob/300b9f0b704048f60776881f1d378c74d9c32fbd/ssl/s3_srvr.c#L3461-L3477
>
> Cheers,
> Fedor.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJTUGdXAAoJEPsOEJWxeXmZwokQAIISCTOnQwCBeX7kBJgEdWeg
> nJTDiHMM+I6bBm/C1ZkiodkIapPX+w7RAHE1OxYaqgeCKp7JWO+Bey6qQfroxJ1U
> q9FtOBFzqg4O5fB6+MwbhWUXyqJE5cAgVxXeU2E9MokDNFvOpGXXtOmmRv7sBGMO
> i0d5L0Fs7YS56eHYGxuy8qf7KrCswJ9muGcr/f/XNHiR6ZU0HliJRnrdoLRsiQAM
> SdwtTe2L2FNeBG+q9Czh/nch5RhEv9hucnV9IPpFehzAfn3404y9wH0eBNpNnYlf
> g48ccSTqTgyQQG/OlNeLbOD41qRHdUoZZ85ueU+2Gw4WrjhMxwi3fxNgU8ml5Ik+
> 4HINmeAshkksycWfx5tdnBXZy3iguurzpe7C9NoHl0fDJf8VCvn7sAEM50t+4ftM
> 4j1EqisQZufLp5R4WLlUVUHDk3bopjFvRqlZoal9SdFdUeqzqv6BDtEEKxv+6LRO
> D86SsHRnpazfgkqdoizI+cZgo0b3IdRs8bsOZ4IR5RCKNt8YROEwlXqV1CueKyZJ
> zpz8xkXv+tezREsiFwe2rR7iNtwqNnANwEAViH/b0GpR5IFcenKRbb/UprOVsrgF
> 4AlpyBPcheVRblOn4FRvUDGnQ8vNa4QW+5jxlRZuEXpaJot0xMMBFSCISUsE4bZ3
> L+7POMtxSlEVXI1zChMw
> =/o6W
> -END PGP SIGNATURE-
>

Cert chain inconsistency between client and server

[Fedor Indutny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello devs!

It has just caught my attention that `SSL_get_peer_cert_chain` does
not contain `SSL_get_peer_certificate`'s value for server, but it does for
client.

Would you mind accepting patch for fixing it?

Here are relevant lines of code:

* client:
https://github.com/openssl/openssl/blob/300b9f0b704048f60776881f1d378c74d9c32fbd/ssl/s3_clnt.c#L1312-L1315
* server:
https://github.com/openssl/openssl/blob/300b9f0b704048f60776881f1d378c74d9c32fbd/ssl/s3_srvr.c#L3461-L3477

Cheers,
Fedor.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTUGdXAAoJEPsOEJWxeXmZwokQAIISCTOnQwCBeX7kBJgEdWeg
nJTDiHMM+I6bBm/C1ZkiodkIapPX+w7RAHE1OxYaqgeCKp7JWO+Bey6qQfroxJ1U
q9FtOBFzqg4O5fB6+MwbhWUXyqJE5cAgVxXeU2E9MokDNFvOpGXXtOmmRv7sBGMO
i0d5L0Fs7YS56eHYGxuy8qf7KrCswJ9muGcr/f/XNHiR6ZU0HliJRnrdoLRsiQAM
SdwtTe2L2FNeBG+q9Czh/nch5RhEv9hucnV9IPpFehzAfn3404y9wH0eBNpNnYlf
g48ccSTqTgyQQG/OlNeLbOD41qRHdUoZZ85ueU+2Gw4WrjhMxwi3fxNgU8ml5Ik+
4HINmeAshkksycWfx5tdnBXZy3iguurzpe7C9NoHl0fDJf8VCvn7sAEM50t+4ftM
4j1EqisQZufLp5R4WLlUVUHDk3bopjFvRqlZoal9SdFdUeqzqv6BDtEEKxv+6LRO
D86SsHRnpazfgkqdoizI+cZgo0b3IdRs8bsOZ4IR5RCKNt8YROEwlXqV1CueKyZJ
zpz8xkXv+tezREsiFwe2rR7iNtwqNnANwEAViH/b0GpR5IFcenKRbb/UprOVsrgF
4AlpyBPcheVRblOn4FRvUDGnQ8vNa4QW+5jxlRZuEXpaJot0xMMBFSCISUsE4bZ3
L+7POMtxSlEVXI1zChMw
=/o6W
-END PGP SIGNATURE-

Re: [openssl.org #3318] memcmp vulnerable to remote timing attack

[Fedor Indutny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello!

I think that to hit this function you need to match session ids hashes
first,
but it seem to be possible indeed. What would attacker be able to do if they
would know the session id? I think knowing it without knowing the master
key and other session parameters is useless?

Btw, I am just curious why do we are not using all bytes of session id for
computation of the hash?

l=(unsigned long)
((unsigned int) a->session_id[0] )|
 ((unsigned int) a->session_id[1]<< 8L)|
((unsigned long)a->session_id[2]<<16L)|
((unsigned long)a->session_id[3]<<24L);

Cheers,
Fedor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTT6/MAAoJEPsOEJWxeXmZFowP/i6UlY00oZfSQmpkxRnOLs0C
8ALrT4inpm6EjwJhGi4VdX0nBWosCyHaz8lROVZ+kfUjwrn2b2YO/Rcxoe+lildm
eQWmv1m/dyusXwS6nNwRwBJ+5HwJ34E9iTw/zoJG6k3LMp9d5+QEKYctEV6wVFml
cOePePven4f8tOC7hEQLLS8E3S8wj9mPENM8t11siCE++r2Vm2CEB+jByKDSZc1Y
N4p/yyB/FxuAxfycbTZv5mK8DDlKLKtLtlMp4AvAge8OmJKevozSymlsDbw9XGxH
Z8Lxukx1llApv5S5S+aPYSlRZBNnWke5NrgaAZA8gZIHt2gppqoF81FAjnoHst7/
TGLpzNP7CikMwINlsnhh7Fykfu5lxQpIZ9c/jYceqF0W6bNpOX7fKobqOa+TmnoK
Km15QZCjrvmGYfQCelwG1sV1EI7slTcqcrvPjOPBRvqs6HdwWwJaDVfLU10nFx1F
iSST4/TlmPVBQI5C7clCLkWY7qRUeHDmR7jHysPzxsKnH3qrhFx4zLgyl3Xwwoed
KVgyDtXjlXr/EGGlpqBus5UxV9WVhFzBQDF6673yzDqvlD6uCm68kS5Qbf9eJvy1
291u5BzQGfX/Xm7PXicQX4T7mK8KPCEAUNGdPQA16UquImcB7ukH+6M4cY/mihTn
bb2yF8frnmQ7F2hGFB24
=FcXu
-END PGP SIGNATURE-


On Thu, Apr 17, 2014 at 11:40 AM, Peter Malone via RT wrote:

> Hi there,
>
> I believe the following memcmp call is vulnerable to a remote timing
> attack.
>
> https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L1974
>
> static int ssl_session_cmp(const SSL_SESSION *a,const SSL_SESSION *b)
> {
> if (a->ssl_version != b->ssl_version)
> return(1);
> if (a->session_id_length != b->session_id_length)
> return(1);
> return(memcmp(a->session_id,b->session_id,a->session_id_length));
> }
>
> For more information on memcmp timing attacks please see:
>
> http://rdist.root.org/2010/08/05/optimized-memcmp-leaks-useful-timing-differences/
> &&
> https://lkml.org/lkml/2013/2/10/131
>
> Regards,
> Peter.
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: OpenSSL should disable or remove heartbeat

[Fedor Indutny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Hanno!

Despite not a being an active community member, I'd like to share my
thoughts
on it, if you don't mind.

I certainly agree that this extension has a quite faulty specification and
very questionable
use. But perhaps, instead of just removing it from OpenSSL, we should try
to make IETF
deprecate it in a spec as well?

Cheers,
Fedor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTTSVtAAoJEPsOEJWxeXmZfDoP/25Eqt9Ec3SCnqOrUaSg9D01
JtNWZ8s8xq0BDdcjSCzeYh3yHPhWK2JbIhxm3t0Dq1vUK+TZtxvBHl6Vr141JioD
fM6WBGqr1eA8Htk5RkEC5xcIgDiEMs3xpGmeg0JYWaisPcdF9ChvPL51FII+FPXj
V26RJKHQhu+3XBKi3z4pmlJOvQNHaQ4B8EFw66mAfgyAVBXbi/EyHOpuJ0vZ/Z0p
WgPBnPSuhe8eu9Gmac440jvx/YHd+feYfjELw/vQiU5mZOCtgIKChu0hgSHQkke+
jTFGTTzBca/3wULAC3VtTFMwHif3bCHuN8GauuvW0NLemB3DslnbEYFCnYXp+vJl
Dv6YJOyc2XUOw576La3ZdAgyAvSnFhnGjWodkVZRYZJsXheblJcWhXOoH5TDK5Zq
mqIfTtFuPE5J2JplYs+Rgpjpss8F5hJgc1GbsfPqb4qU+VEN3DB0w2BdYBcSWt4B
PiANM0OcuaTwWS15KECR+yoItUJwbZyHmqCIsFzHlWNzymD5wr8xdcUtq0HFo8oV
B1G6vZXhoHxsB04xusK9kJZPwxbZXFL8hWwyvJprsPVEBD7v7taFHN01cItFXxGR
pSWVa0PdJc7JzvAOpJhXKKAqiQtr/cNcAUSl+BGXBkhzFMs5sPYVCXaD0a+01piw
jEjk3196JpBMEJOUBDbF
=Z4D3
-END PGP SIGNATURE-


On Tue, Apr 15, 2014 at 4:17 PM, Hanno Böck  wrote:

> Hi,
>
> I think this question needs to be asked.
>
> We have a TLS extension here that - as far as I can see - nobody uses.
> I have asked in different contexts recently if anyone is aware of real
> software that makes use of the heartbeat extension. I got often
> answerts like "it could be used for X", but not a single one of them
> saying "there is software Y that does X with it". Also, a search on
> ohloh turned up nothing.
>
> I think there is no justification to have an extension that gets
> enabled by default around if it is not used. So I propose that openssl
> either disables it in the default build or removes it completely.
> I'd suggest the first one if there are reasonable chances that anyone
> might use it in the future.
>
> And: I'd like to see a discussion on what further unused features there
> are in OpenSSL that could be disabled just to reduce attack surface.
> E.g. I could think of removing DSA key support, because nobody uses that
> anyway and DSA is a bad algorithm.
>
> cu,
> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
>

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

Yes, I agree with everyone. Just thought that linking a blog post would be
more helpful.

Better use instructions provided here, than at that page.

Thank you, guys!


On Mon, Apr 14, 2014 at 3:40 PM, Olivier BARTHELEMY <
barthel...@geovariances.com> wrote:

> I use
> export CFLAGS=-fPIC
> ./config shared --prefix=$inst && \
> make
> to build the shared library version i use
>
>
> 2014-04-14 13:34 GMT+02:00 Fedor Indutny :
>
> I guess you need to build it in a shared library mode. Take a look at this:
>>
>> http://www.linuxfromscratch.org/blfs/view/svn/postlfs/openssl.html .
>>
>> You may skip applying some unverified patches as author suggest, but
>> generally
>> the instructions are correct.
>>
>> Cheers,
>> Fedor.
>>
>>
>> On Mon, Apr 14, 2014 at 3:29 PM, LOKESH JANGIR wrote:
>>
>>> Hi,
>>>
>>> I am installing openssl in /usr/local/openssl folder and it is creating
>>> libssl.a and libcrypt.a library files. so how can i use these files as
>>> library. Or i need to install this in default folders.
>>> Should i follow this article
>>> http://www.akadia.com/services/ssh_test_certificate.html
>>>
>>> Lokesh Jangir
>>>
>>>
>>> On Mon, Apr 14, 2014 at 4:50 PM, Fedor Indutny wrote:
>>>
>>>> Hello again!
>>>>
>>>> That depends on your setup. I'd suppose that OpenSSL's default
>>>> installer should
>>>> create symlinks itself. If it did and they doesn't match the previous
>>>> location - you
>>>> could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
>>>> /lib64/libcrypt.so.1`
>>>>
>>>> Cheers,
>>>> Fedor.
>>>>
>>>>
>>>> On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR 
>>>> wrote:
>>>>
>>>>> Hi Fedor,
>>>>>
>>>>> Yes i did not move this file out. and i can see the output of ls -la 
>>>>> /lib64/libcrypt.so.1
>>>>>
>>>>> libcrypt.so -> ../../lib64/libcrypt.so.1
>>>>>
>>>>>
>>>>> I complied openssl and it created this library files,
>>>>> engines  libcrypto.a  libssl.a  pkgconfig
>>>>>
>>>>> So now should i move this libcrypt.a file to /usr/lib64 folder and
>>>>> rename this as .so ?
>>>>>
>>>>> Regards,
>>>>> Lokesh Jangir
>>>>>
>>>>>
>>>>> On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny wrote:
>>>>>
>>>>>> So, considering that it fails to start now. Could you please verify
>>>>>> that `ls -la /lib64/libcrypt.so.1` is still valid?
>>>>>>
>>>>>> Fedor.
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR >>>>> > wrote:
>>>>>>
>>>>>>> Hi Rainer,
>>>>>>>
>>>>>>> Yes, apache was running with the old library, i have moved this out,
>>>>>>> and copied new libssl library from new openssl installation folder. But 
>>>>>>> it
>>>>>>> is not working and now i am unable to start apache.
>>>>>>>
>>>>>>> Now what to do with this ?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Lokesh Jangir
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan <
>>>>>>> rainer.cana...@sevenval.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Apr 14, 2014, at 10:17 , LOKESH JANGIR 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> > Hi Team,
>>>>>>>> >
>>>>>>>> > I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl
>>>>>>>> installed. I found the same openssl vulnerability issue with my ssl
>>>>>>>> certificate. I have installed new openssl bugfixed version 1.0.1g and
>>>>>>>> create csr and key file from this. Also i have installed this on the
>>>>>>>> server. I have restarted apache service and server many times after
>>>>>>>> installation.
>>>>>>>> >
>>>>>>>> > But still it is showing my website vulnerable. Can you please
>>>>>>>> guide me what am i missing now ?
>>>>>>>>
>>>>>>>> did you use "apachectl restart", or "apachectl stop" + "apachectl
>>>>>>>> start"? If you did
>>>>>>>> the former, the process may still be running with the old, deleted
>>>>>>>> library. Try
>>>>>>>>
>>>>>>>> sudo lsof -n | grep libssl | grep DEL
>>>>>>>>
>>>>>>>> to see if that is still the case.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> rainer__
>>>>>>>> OpenSSL Project
>>>>>>>> http://www.openssl.org
>>>>>>>> Development Mailing List
>>>>>>>> openssl-dev@openssl.org
>>>>>>>> Automated List Manager
>>>>>>>> majord...@openssl.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> [image: Geovariances]
>
> Olivier BARTHELEMY *Software development engineer*
> Geovariances, 49bis avenue Franklin Roosevelt - 77215 AVON CEDEX - FRANCE
> | www.geovariances.com <http://link.geovariances.com/eml-home>
> Keep posted about Geovariances   <http://link.geovariances.com/eml-geowidget>
> <http://link.geovariances.com/eml-linkedin-gv>   
> <http://link.geovariances.com/eml-linkedin>
> <http://link.geovariances.com/eml-twitter>   
> <http://link.geovariances.com/eml-youtube>
> <http://link.geovariances.com/eml-slideshare>
>

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

I guess you need to build it in a shared library mode. Take a look at this:

http://www.linuxfromscratch.org/blfs/view/svn/postlfs/openssl.html .

You may skip applying some unverified patches as author suggest, but
generally
the instructions are correct.

Cheers,
Fedor.


On Mon, Apr 14, 2014 at 3:29 PM, LOKESH JANGIR wrote:

> Hi,
>
> I am installing openssl in /usr/local/openssl folder and it is creating
> libssl.a and libcrypt.a library files. so how can i use these files as
> library. Or i need to install this in default folders.
> Should i follow this article
> http://www.akadia.com/services/ssh_test_certificate.html
>
> Lokesh Jangir
>
>
> On Mon, Apr 14, 2014 at 4:50 PM, Fedor Indutny  wrote:
>
>> Hello again!
>>
>> That depends on your setup. I'd suppose that OpenSSL's default installer
>> should
>> create symlinks itself. If it did and they doesn't match the previous
>> location - you
>> could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
>> /lib64/libcrypt.so.1`
>>
>> Cheers,
>> Fedor.
>>
>>
>> On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR wrote:
>>
>>> Hi Fedor,
>>>
>>> Yes i did not move this file out. and i can see the output of ls -la 
>>> /lib64/libcrypt.so.1
>>>
>>> libcrypt.so -> ../../lib64/libcrypt.so.1
>>>
>>>
>>> I complied openssl and it created this library files,
>>> engines  libcrypto.a  libssl.a  pkgconfig
>>>
>>> So now should i move this libcrypt.a file to /usr/lib64 folder and
>>> rename this as .so ?
>>>
>>> Regards,
>>> Lokesh Jangir
>>>
>>>
>>> On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny wrote:
>>>
>>>> So, considering that it fails to start now. Could you please verify
>>>> that `ls -la /lib64/libcrypt.so.1` is still valid?
>>>>
>>>> Fedor.
>>>>
>>>>
>>>> On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR 
>>>> wrote:
>>>>
>>>>> Hi Rainer,
>>>>>
>>>>> Yes, apache was running with the old library, i have moved this out,
>>>>> and copied new libssl library from new openssl installation folder. But it
>>>>> is not working and now i am unable to start apache.
>>>>>
>>>>> Now what to do with this ?
>>>>>
>>>>> Regards,
>>>>> Lokesh Jangir
>>>>>
>>>>>
>>>>> On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan <
>>>>> rainer.cana...@sevenval.com> wrote:
>>>>>
>>>>>>
>>>>>> On Apr 14, 2014, at 10:17 , LOKESH JANGIR 
>>>>>> wrote:
>>>>>>
>>>>>> > Hi Team,
>>>>>> >
>>>>>> > I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl
>>>>>> installed. I found the same openssl vulnerability issue with my ssl
>>>>>> certificate. I have installed new openssl bugfixed version 1.0.1g and
>>>>>> create csr and key file from this. Also i have installed this on the
>>>>>> server. I have restarted apache service and server many times after
>>>>>> installation.
>>>>>> >
>>>>>> > But still it is showing my website vulnerable. Can you please guide
>>>>>> me what am i missing now ?
>>>>>>
>>>>>> did you use "apachectl restart", or "apachectl stop" + "apachectl
>>>>>> start"? If you did
>>>>>> the former, the process may still be running with the old, deleted
>>>>>> library. Try
>>>>>>
>>>>>> sudo lsof -n | grep libssl | grep DEL
>>>>>>
>>>>>> to see if that is still the case.
>>>>>>
>>>>>>
>>>>>>
>>>>>> rainer__
>>>>>> OpenSSL Project
>>>>>> http://www.openssl.org
>>>>>> Development Mailing List
>>>>>> openssl-dev@openssl.org
>>>>>> Automated List Manager
>>>>>> majord...@openssl.org
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

Hello again!

That depends on your setup. I'd suppose that OpenSSL's default installer
should
create symlinks itself. If it did and they doesn't match the previous
location - you
could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
/lib64/libcrypt.so.1`

Cheers,
Fedor.


On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR wrote:

> Hi Fedor,
>
> Yes i did not move this file out. and i can see the output of ls -la 
> /lib64/libcrypt.so.1
>
> libcrypt.so -> ../../lib64/libcrypt.so.1
>
>
> I complied openssl and it created this library files,
> engines  libcrypto.a  libssl.a  pkgconfig
>
> So now should i move this libcrypt.a file to /usr/lib64 folder and rename
> this as .so ?
>
> Regards,
> Lokesh Jangir
>
>
> On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny  wrote:
>
>> So, considering that it fails to start now. Could you please verify that
>> `ls -la /lib64/libcrypt.so.1` is still valid?
>>
>> Fedor.
>>
>>
>> On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR wrote:
>>
>>> Hi Rainer,
>>>
>>> Yes, apache was running with the old library, i have moved this out, and
>>> copied new libssl library from new openssl installation folder. But it is
>>> not working and now i am unable to start apache.
>>>
>>> Now what to do with this ?
>>>
>>> Regards,
>>> Lokesh Jangir
>>>
>>>
>>> On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan <
>>> rainer.cana...@sevenval.com> wrote:
>>>
>>>>
>>>> On Apr 14, 2014, at 10:17 , LOKESH JANGIR 
>>>> wrote:
>>>>
>>>> > Hi Team,
>>>> >
>>>> > I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed.
>>>> I found the same openssl vulnerability issue with my ssl certificate. I
>>>> have installed new openssl bugfixed version 1.0.1g and create csr and key
>>>> file from this. Also i have installed this on the server. I have restarted
>>>> apache service and server many times after installation.
>>>> >
>>>> > But still it is showing my website vulnerable. Can you please guide
>>>> me what am i missing now ?
>>>>
>>>> did you use "apachectl restart", or "apachectl stop" + "apachectl
>>>> start"? If you did
>>>> the former, the process may still be running with the old, deleted
>>>> library. Try
>>>>
>>>> sudo lsof -n | grep libssl | grep DEL
>>>>
>>>> to see if that is still the case.
>>>>
>>>>
>>>>
>>>> rainer__
>>>> OpenSSL Project http://www.openssl.org
>>>> Development Mailing List   openssl-dev@openssl.org
>>>> Automated List Manager   majord...@openssl.org
>>>>
>>>
>>>
>>
>

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

So, considering that it fails to start now. Could you please verify that
`ls -la /lib64/libcrypt.so.1` is still valid?

Fedor.


On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR wrote:

> Hi Rainer,
>
> Yes, apache was running with the old library, i have moved this out, and
> copied new libssl library from new openssl installation folder. But it is
> not working and now i am unable to start apache.
>
> Now what to do with this ?
>
> Regards,
> Lokesh Jangir
>
>
> On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan <
> rainer.cana...@sevenval.com> wrote:
>
>>
>> On Apr 14, 2014, at 10:17 , LOKESH JANGIR  wrote:
>>
>> > Hi Team,
>> >
>> > I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I
>> found the same openssl vulnerability issue with my ssl certificate. I have
>> installed new openssl bugfixed version 1.0.1g and create csr and key file
>> from this. Also i have installed this on the server. I have restarted
>> apache service and server many times after installation.
>> >
>> > But still it is showing my website vulnerable. Can you please guide me
>> what am i missing now ?
>>
>> did you use "apachectl restart", or "apachectl stop" + "apachectl start"?
>> If you did
>> the former, the process may still be running with the old, deleted
>> library. Try
>>
>> sudo lsof -n | grep libssl | grep DEL
>>
>> to see if that is still the case.
>>
>>
>>
>> rainer__
>> OpenSSL Project http://www.openssl.org
>> Development Mailing List   openssl-dev@openssl.org
>> Automated List Manager   majord...@openssl.org
>>
>
>

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

Hello!

What does `ldd /path/to/httpd` says?

Cheers,
Fedor.


On Mon, Apr 14, 2014 at 12:17 PM, LOKESH JANGIR wrote:

> Hi Team,
>
> I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I
> found the same openssl vulnerability issue with my ssl certificate. I have
> installed new openssl bugfixed version 1.0.1g and create csr and key file
> from this. Also i have installed this on the server. I have restarted
> apache service and server many times after installation.
>
> But still it is showing my website vulnerable. Can you please guide me
> what am i missing now ?
>
> Thanks and Regards,
> Lokesh Jangir
>

Re: ssleay PRNG entropy

[Fedor Indutny]

Hello Richard,

Yes, I see what this comment means. But what's the difference between
RAND_bytes() and RAND_pseudo_bytes() then? They seems to be using exactly
the same amount of entropy and can't ever fail or return `0` (meaning that
data is insecure).

In my opinion, current implementation could be a RAND_pseudo_bytes()
backend, and RAND_bytes() should be something more secure (considering that
it is how its described in man documentation).

Cheers,
Fedor.


On Wed, Oct 23, 2013 at 6:53 PM, Richard Könning <
richard.koenn...@ts.fujitsu.com> wrote:

> Am 21.10.2013 13:09, schrieb Fedor Indutny:
>
>  Hello devs!
>>
>> I just found that its impossible to get error from `RAND_bytes()` if
>> running on default `RAND_SSLeay()` method.
>>
>> There're a couple of reasons and observations, that are confirming it
>> (sorry for using github, its just more convenient to me):
>>
>> 1. `RAND_poll()` is called only once in initialization of method:
>> https://github.com/openssl/**openssl/blob/master/crypto/**
>> rand/md_rand.c#L436-L440<https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L436-L440>
>> and
>> https://github.com/openssl/**openssl/blob/master/crypto/**
>> rand/md_rand.c#L648-L652<https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L648-L652>
>> 2. Static variable `entropy`, which is used to determine if the PRNG
>> output is secure is never decreased, and actually stays exactly at
>> `ENTROPY_NEEDED` value all the time. This happens because `entropy -=
>> ...` happens only in following condition:
>> https://github.com/openssl/**openssl/blob/master/crypto/**
>> rand/md_rand.c#L446-L463<https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L446-L463>
>> ,
>> which is always true.
>>
>> I think I can contribute a patch to make it work properly, if this isn't
>> an intended behavior.
>>
>
> Well, the comment in the code states it imho clearly that this *is*
> intended behavior:
>
>  * Once we've had enough initial seeding we don't bother to
>> * adjust the entropy count, though, because we're not ambitious
>> * to provide *information-theoretic* randomness.
>>
>
> Ciao
> Richard
> __**__**__
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: ssleay PRNG entropy

[Fedor Indutny]

Hello again,

Is there any way to speed up discussion on this topic?

Cheers,
Fedor.


On Mon, Oct 21, 2013 at 3:09 PM, Fedor Indutny  wrote:

> Hello devs!
>
> I just found that its impossible to get error from `RAND_bytes()` if
> running on default `RAND_SSLeay()` method.
>
> There're a couple of reasons and observations, that are confirming it
> (sorry for using github, its just more convenient to me):
>
> 1. `RAND_poll()` is called only once in initialization of method:
> https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L436-L440and
> https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L648-L652
> 2. Static variable `entropy`, which is used to determine if the PRNG
> output is secure is never decreased, and actually stays exactly at
> `ENTROPY_NEEDED` value all the time. This happens because `entropy -= ...`
> happens only in following condition:
> https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L446-L463,
> which is always true.
>
> I think I can contribute a patch to make it work properly, if this isn't
> an intended behavior.
>
> Basically, to my mind, if condition in pt.2 should be removed and
> `RAND_poll()` should be called when there're not enough entropy. But
> that'll lead to enormous amounts of `RAND_poll()` calls, which will make
> performance worse that it really is.
>
> Any thoughts, opinions?
>
> Thank you,
> Fedor.
>

ssleay PRNG entropy

[Fedor Indutny]

Hello devs!

I just found that its impossible to get error from `RAND_bytes()` if
running on default `RAND_SSLeay()` method.

There're a couple of reasons and observations, that are confirming it
(sorry for using github, its just more convenient to me):

1. `RAND_poll()` is called only once in initialization of method:
https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L436-L440and
https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L648-L652
2. Static variable `entropy`, which is used to determine if the PRNG output
is secure is never decreased, and actually stays exactly at
`ENTROPY_NEEDED` value all the time. This happens because `entropy -= ...`
happens only in following condition:
https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L446-L463,
which is always true.

I think I can contribute a patch to make it work properly, if this isn't an
intended behavior.

Basically, to my mind, if condition in pt.2 should be removed and
`RAND_poll()` should be called when there're not enough entropy. But
that'll lead to enormous amounts of `RAND_poll()` calls, which will make
performance worse that it really is.

Any thoughts, opinions?

Thank you,
Fedor.

SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION

[Fedor Indutny]

Hey guys!

I've just stumbled following flag while trying to debug node.js test
failures regarding to the `renegotiate` method that I've just added. What I
was wondering is, basically, why isn't OpenSSL sending CertificateRequest
to client if it sees that session was resumed?

Particularly, my problem has happened because initially server was
accepting connection without SSL_VERIFY_PEER flag, and then renegotiating
it after setting SSL_VERIFY_PEER. And, because of session renegotiation, no
certificate was requested from client. And, no surprise, client
verification has failed.

Is it a bug, or an intended behaviour? (if it's a bug, please let me know
and I'll send you a patch for it ;) )

Cheers,
Fedor.

Re: ssl3_get_cert_verify performance

[Fedor Indutny]

Andrey,

Thank you for replying.

1. I'm running apache benchmark utility: ab -c 100 -n 10
https://localhost:44300/ . And I'm measuring handshakes/sec.
2. Certificates are here
https://github.com/indutny/tlsnappy/tree/master/keys and connections are
using following ciphers:

Cipher Suite Protocol   :TLSv1/SSLv3
Cipher Suite Name   :AES256-SHA
Cipher Suite Cipher Bits:256 (256)

3. Results of benchmarks are posted here :
http://blog.indutny.com/1.to-lock-or-not-to-lock at the bottom of page in
"Results" section.
4. I'm afraid I won't be able to do it anywhere soon, since I've only one
smartos (solaris) server at hand right now (which I can't clobber).
5. This is rather complicated right now too, see 4


Cheers,
Fedor.


On Sat, Jan 5, 2013 at 4:26 PM, Andrey Kulikov  wrote:

> I'm affraid flamegraphs for two different servers with two different
> OpenSSL libraries without information about type of load it was collected
> with and without any information other than "smth. started spending much
> more time than it was" can not give much information about root cause for
> the issue.
>
> You may start with:
> 1. Describing you test procedure. (what are you measuring? Handshakes?
> Data transfer? Multithreaded?)
> 2. Describing test environment (type of certificates, key length, used
> chiphersuites, etc)
> 3. Measure performance differences in absolute values (ms, handshakes per
> second, etc)
> 4. Measure nginx perfromance with two different OpenSSL versions.
> 5. Measure your server performance with two different OpenSSL versions.
> 6. Share your findings.
>
>
> On 5 January 2013 13:14, Fedor Indutny  wrote:
>
>> Hello devs,
>>
>> Right now I'm doing a lot of benchmarks, trying to figure out how to make
>> my https server as fast as are others (for example, nginx). I've found that
>> somewhere between 0.9.8 and 1.0.1c ssl3_get_cert_verify has started
>> spending much more time than it was.
>>
>> I wonder if you're aware of it, or if this thing can depend on some
>> SSL_CTX mode/flag.
>>
>> Here are flamegraphs for you to make it more clearer what I'm talking
>> about:
>>
>> * My server (openssl1.0.1c) - http://blog.indutny.com/f/tlsnappy-x64.svg
>> * Nginx (openssl0.9.8) - http://blog.indutny.com/f/nginx.svg
>>
>> And here are sources of my server, just in case if you need them to
>> figure something out:
>> https://github.com/indutny/tlsnappy/blob/master/src/tlsnappy.cc
>>
>> Thank you,
>> Fedor.
>>
>
>

ssl3_get_cert_verify performance

[Fedor Indutny]

Hello devs,

Right now I'm doing a lot of benchmarks, trying to figure out how to make
my https server as fast as are others (for example, nginx). I've found that
somewhere between 0.9.8 and 1.0.1c ssl3_get_cert_verify has started
spending much more time than it was.

I wonder if you're aware of it, or if this thing can depend on some SSL_CTX
mode/flag.

Here are flamegraphs for you to make it more clearer what I'm talking about:

* My server (openssl1.0.1c) - http://blog.indutny.com/f/tlsnappy-x64.svg
* Nginx (openssl0.9.8) - http://blog.indutny.com/f/nginx.svg

And here are sources of my server, just in case if you need them to figure
something out:
https://github.com/indutny/tlsnappy/blob/master/src/tlsnappy.cc

Thank you,
Fedor.

Re: Multithreading performance patches

[Fedor Indutny]

Wow, indeed my first patch is useless taking in account presence of
OPENSSL_atomic_add
and locking callback. Surely, it would be good if openssl will export this
symbol, this is very important for tlsnappy since it's compiling to shared
library and non-exported symbols are not visible for it.




On Fri, Oct 12, 2012 at 10:19 PM, Andy Polyakov  wrote:

> OPENSSL_atomic_add

Multithreading performance patches

[Fedor Indutny]

Hey people!

I'm working on fast multithreaded TLS server for node.js, and I've
encountered few problems with openssl threading support which I would like
to address with attached patches.

Please ask me if you have any questions or comments.

Cheers,
Fedor.


1.patch
Description: Binary data


2.patch
Description: Binary data

Re: M.J wants to chat

[Fedor Indutny]

Please... stop... doing.. this!
Cheers,
Fedor.



On Sun, Aug 14, 2011 at 9:30 PM, M.J  wrote:

> ---
>
> M.J wants to stay in better touch using some of Google's coolest new
> products.
>
> If you already have Gmail or Google Talk, visit:
>
> http://mail.google.com/mail/b-c3c3f1b720-ab1a397353-jEkhi454WHvAGIt5alpbtfjf_TQ
> You'll need to click this link to be able to chat with M.J.
>
> To get Gmail - a free email account from Google with over 2,800 megabytes
> of
> storage - and chat with M.J, visit:
>
> http://mail.google.com/mail/a-c3c3f1b720-ab1a397353-jEkhi454WHvAGIt5alpbtfjf_TQ
>
> Gmail offers:
> - Instant messaging right inside Gmail
> - Powerful spam protection
> - Built-in search for finding your messages and a helpful way of organizing
>  emails into "conversations"
> - No pop-up ads or untargeted banners - just text ads and related
> information
>  that are relevant to the content of your messages
>
> All this, and its yours for free. But wait, there's more! By opening a
> Gmail
> account, you also get access to Google Talk, Google's instant messaging
> service:
>
> http://www.google.com/talk/
>
> Google Talk offers:
> - Web-based chat that you can use anywhere, without a download
> - A contact list that's synchronized with your Gmail account
> - Free, high quality PC-to-PC voice calls when you download the Google Talk
>  client
>
> We're working hard to add new features and make improvements, so we might
> also
> ask for your comments and suggestions periodically. We appreciate your help
> in
> making our products even better!
>
> Thanks,
> The Google Team
>
> To learn more about Gmail and Google Talk, visit:
> http://mail.google.com/mail/help/about.html
> http://www.google.com/talk/about.html
>
> (If clicking the URLs in this message does not work, copy and paste them
> into
> the address bar of your browser).
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>