Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Alessandro Ghedini via RT]

On Thu, Oct 08, 2015 at 12:47:21AM +, Moonchild via RT wrote:
> Hello people,
> 
> An enhancement request here for OpenSSL to add support for Camellia in GCM
> with ECC key exchange.
> 
> Rationale:
> Camellia has been recognized as a modern and supported cipher by ENISA,
> NESSIE, CRYPTREC, ISO and IETF among others so should be supported
> long-term. OpenSSL currently only supports the (rather expensive) DHE/RSA
> CBC+IV versions of the suite, and should be updated with the ECC and GCM
> modes of operation.
> 
> It's important to have at least one cipher coming from non-US expert bodies
> that is maintained to the same level as AES currently is, and OpenSSL seems
> to be trailing behind in that respect. I would request addition of at least
> the following:
> 
> TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc086)
> TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc08a)
> And possibly their 256-bit counterparts

Patches for this are available at [0], however there has been some resistance
to adding the new TLS cipher suites to OpenSSL (see [1]), so the discussion has
stalled.

> These suites are already supported in e.g. GNUTLS, Botan and PolarSSL, iiuc.
> Firefox will also be adding the GCM versions of Camellia to NSS

Do you have a source for the news above? IIRC Firefox used to support Camellia,
but dropped it in v37 or so.

Cheers

[0] https://github.com/openssl/openssl/pull/374
[1] https://rt.openssl.org/Ticket/Display.html?id=4017


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

[openssl-dev] [openssl.org #4076] PROBLEM： there exists a wrong return value of function int_rsa_verify()

[Zhang Yan via RT]

Bug Description:  
 Function int_rsa_verify() defined in file crypto/rsa/rsa_sign.c would 
return 1 if a signature is valid, and 0 otherwise. The variable 'ret' keeps the 
return value, and it may be assigned to 1 if the condition in line 216 is 
satisfied. The signature is regarded as invalid if the conditions in line 241 
are evaluated to be true, and the error message is dumped (in line 242) and the 
verify process is ended (in line 243). However, as variable 'ret' may keep 
value 1, this function will return 1 (in line 290) even if the signature is 
invalid, which will confuse the caller function whether the signature is really 
valid.
The related code snippets in int_rsa_verify() is as following.
168 int int_rsa_verify(int dtype, const unsigned char *m,
169unsigned int m_len,
170unsigned char *rm, size_t *prm_len,
171const unsigned char *sigbuf, size_t siglen, RSA *rsa)
172 {
173 int i, ret = 0, sigtype;
 ...
216 if (dtype == NID_mdc2 && i == 18 && s[0] == 0x04 && s[1] == 0x10) {
217 if (rm) {
218 memcpy(rm, s + 2, 16);
219 *prm_len = 16;
220 ret = 1;
221 } else if (memcmp(m, s + 2, 16))
222 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE);
223 else
224 ret = 1;  
225 }
226
227 /* Special case: SSL signature */
228 if (dtype == NID_md5_sha1) {
229 if ((i != SSL_SIG_LENGTH) || memcmp(s, m, SSL_SIG_LENGTH))
230 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE);
231 else
232 ret = 1;
233 } else {   // dtype != NID_md5_sha1
234 const unsigned char *p = s;
235 sig = d2i_X509_SIG(NULL, , (long)i);
236
237 if (sig == NULL)
238 goto err;
239
240 /* Excess data can be used to create forgeries */
241 if (p != s + i || !rsa_check_digestinfo(sig, s, i)) {
242 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE);
243 goto err;
244 }
   ...
283  err:
284 if (sig != NULL)
285 X509_SIG_free(sig);
286 if (s != NULL) {
287 OPENSSL_cleanse(s, (unsigned int)siglen);
288 OPENSSL_free(s);
289 }
290 return (ret);
291 }




 



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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Moonchild via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/10/2015 10:53, Alessandro Ghedini via RT wrote:
> Patches for this are available at [0], however there has been some
> resistance to adding the new TLS cipher suites to OpenSSL (see [1]), so
> the discussion has stalled.

That's really disappointing! I don't understand the resistance to this
addition. It's a cipher with no known attacks found over the past decade or
so...

>> These suites are already supported in e.g. GNUTLS, Botan and PolarSSL,
>> iiuc. Firefox will also be adding the GCM versions of Camellia to NSS
> 
> Do you have a source for the news above? IIRC Firefox used to support
> Camellia, but dropped it in v37 or so.

Other libs supporting this:

GNUTLS: http://gnutls.org/manual/html_node/Supported-ciphersuites.html
Botan: http://botan.randombit.net/manual/tls.html#tls-policies
PolarSSL: https://tls.mbed.org/supported-ssl-ciphersuites

Addition to Firefox/NSS:
See recent discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=1211248
(which addresses the premature removal of Camellia CBC ciphers)
and recent activity on
https://bugzilla.mozilla.org/show_bug.cgi?id=940119
(the actual implementation bug, which had stalled for a while but seems to
want to get moving again. It has a reviewed patch.)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)

iF4EAREIAAYFAlYWQZkACgkQEguw022l8qzFBgD/d+FXvjUQA8CiqpA1ID1hm5em
DFTBvTWBq5h5TIITRQ0A/0szG+yjimez7doxczfqzCpa8pb67BgegSAkUpsF6z8a
=hAzy
-END PGP SIGNATURE-


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

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

I have some questions.

On Thu, Oct 8, 2015 at 12:32 AM, Matt Caswell  wrote:

>
>
> On 07/10/15 21:44, Dmitry Belyavsky wrote:
> > Dear Matt,
> >
> > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 07/10/15 14:29, Viktor Dukhovni wrote:
> > >
> > > Should applications generally enable async mode because that might
> > > be beneficial down the road?  Or is this just for exotic hardware
> > > not likely to be seen in most environments?
> >
> > It will only be helpful if you have an engine capable of supporting
> > async. I can't really answer the question because I don't know how
> > common this will be. My hope is that this will become relatively
> common.
> > I have been toying with the idea of creating a multi-threaded async
> > engine where the engine manages a pool of threads to offload async
> work
> > to which would then offer true async support even if you don't have
> > specialist hardware.
> >
> >
> > If we have an engine executing long crypto operations, how can we adopt
> > the engine and software using this engine to process them asynchronously?
>
> The engine needs to have a way of offloading the work to "something
> else" so that it can come back and pick up the results later. Typically
> for an engine this would mean some external hardware, but as I suggested
> above it could be done using threads.
>
> From an engine perspective the work would be:
> - Receive a request to do some crypto work in the normal way via the
> engine API.
> - Offload the work to "something else"
>

So what is a mechanism of such an offload? Can I, for example, get the
(global) ASYNC_pool and add a job (function/pointer to context) to it?


> - Call the new API function ASYNC_pause_job(). This will return control
> back to the calling application.
>


> - At sometime later, preferably when the application knows the work has
> completed (* see below), the application will resume the async job. From
> an engine perspective this just appears as the ASYNC_pause_job()
> function call returning - so it just continues where it left off
> - The engine should verify that the work offloaded to "something else"
> has completed.
> - If not it just calls ASYNC_pause_job() again as before.
> - If it has completed then it collects the results and returns them back
> in the normal way for an engine
>
> From an application perspective it depends whether it is using libcrypto
> directly, or whether it is using libssl.
>
> If libssl then:
> - the application essentially operates as normal
> - additionally it must call either SSL_CTX_set_mode() or SSL_set_mode to
> set the SSL_ASYNC_MODE
> - In any call to SSL_read/SSL_write/SSL_accept/SSL_connect etc, it must
> be prepared to handle an SSL_ERROR_WANT_ASYNC response. This works in
> essentially the same way as SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE,
> i.e sometime later (* see below) it recalls
> SSL_read/SSL_write/SSL_accept/SSL_connect and the async job is resumed.
>

How will the SSL struct obtain a job id from the engine implementing, for
example, "long" RSA_METHOD?


>
> If using libcrypto then:
> - the application must determine which crypto operations it wants to
> perform asynchronously. Those operations should be wrapped in an
> application defined function.
> - the application initiates the async job by calling ASYNC_start_job and
> passing in a pointer to the function to be started as a job.
> - from an engine perspective it will work in exactly the same way as for
> libssl initiated crypto work.
> - ASYNC_start_job may return with an ASYNC_PAUSE response. The
> application can go off and do other work, and then resume the job at a
> later time by recalling ASYNC_start_job.
>

So do I understand correctly that if I want to perform SSL operations
asynchronously,
I'm able to wrap the SSL functions into the application defined functions
and then behave as described
herein before?


>
>
> So the next question is how does the application know when it is ok to
> resume a job? There are two basic models:
>
> - Event based...essentially the engine signals to the application that
> the results are ready for collection
> - Polling...in this model the application will have to periodically
> restart the job to see if it is ready to be continued or not
>
> There are API calls available for the event based model. See
> ASYNC_wake(), ASYNC_clear_wake(), ASYNC_get_wait_fd(), and
> SSL_get_async_wait_fd() in the documentation links I sent out previously.
>
> There is some example code in the ASYNC_start_job() documentation. You
> can also look at the source code for the dummy async engine.
>

Thank you. I've looked through them but still did not understand completely.


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

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 08/10/15 11:26, Dmitry Belyavsky wrote:
> Dear Matt, 
> 
> I have some questions.
> 
> On Thu, Oct 8, 2015 at 12:32 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 07/10/15 21:44, Dmitry Belyavsky wrote:
> > Dear Matt,
> >
> > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell  
> > >> wrote:
> >
> >
> >
> > On 07/10/15 14:29, Viktor Dukhovni wrote:
> > >
> > > Should applications generally enable async mode because that might
> > > be beneficial down the road?  Or is this just for exotic hardware
> > > not likely to be seen in most environments?
> >
> > It will only be helpful if you have an engine capable of supporting
> > async. I can't really answer the question because I don't know how
> > common this will be. My hope is that this will become relatively 
> common.
> > I have been toying with the idea of creating a multi-threaded async
> > engine where the engine manages a pool of threads to offload async 
> work
> > to which would then offer true async support even if you don't have
> > specialist hardware.
> >
> >
> > If we have an engine executing long crypto operations, how can we adopt
> > the engine and software using this engine to process them 
> asynchronously?
> 
> The engine needs to have a way of offloading the work to "something
> else" so that it can come back and pick up the results later. Typically
> for an engine this would mean some external hardware, but as I suggested
> above it could be done using threads.
> 
> From an engine perspective the work would be:
> - Receive a request to do some crypto work in the normal way via the
> engine API.
> - Offload the work to "something else"
> 
> 
> So what is a mechanism of such an offload? Can I, for example, get the
> (global) ASYNC_pool and add a job (function/pointer to context) to it?

The offload mechanism is entirely engine specific. We do not know how
any specific engine works or how to interface to the hardware. An engine
will be called in exactly the same way as now. The job of the engine
will be to take the parameters passed to it and initiate the work in the
engine hardware.

So in pseudo code it might look something like this:

static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
unsigned char *out, const unsigned char *in, size_t inl)
{
int jobid;

jobid = offload_cipher_to_hardware(ctx, out, in , inl);

/*
 * jobid holds a reference in the engine back to the work we just
 * started
 */

while(work_not_finished_yet(jobid)) {
/* Return control back to the calling application */
ASYNC_pause_job();
}

return get_results_from_hardware(jobid);
}

You will note that ASYNC_pause_job() does *not* do a "return" to return
control back to the user application...but calling ASYNC_pause_job()
will cause SSL_read (or whatever) to return with SSL_ERROR_WANT_ASYNC
nonetheless. The async job has its own private stack to enable this.
Recalling SSL_read from the user application will appear to the engine
like the function call ASYNC_pause_job() has returned.


> How will the SSL struct obtain a job id from the engine implementing,
> for example, "long" RSA_METHOD?

It does not need to. The SSL object has a reference to the ASYNC_JOB.
The engine can manage its own job ids - see the pseudo code above.

>  
> 
> 
> If using libcrypto then:
> - the application must determine which crypto operations it wants to
> perform asynchronously. Those operations should be wrapped in an
> application defined function.
> - the application initiates the async job by calling ASYNC_start_job and
> passing in a pointer to the function to be started as a job.
> - from an engine perspective it will work in exactly the same way as for
> libssl initiated crypto work.
> - ASYNC_start_job may return with an ASYNC_PAUSE response. The
> application can go off and do other work, and then resume the job at a
> later time by recalling ASYNC_start_job.
> 
> 
> So do I understand correctly that if I want to perform SSL operations
> asynchronously, 
> I'm able to wrap the SSL functions into the application defined
> functions and then behave as described
> herein before? 

If you are doing SSL operations you do not need to wrap them in a
function as described above (although you could do if you wanted to).
libssl will do all of this for you. You only have to define your own
function for the job if you are calling libcrypto directly. For an
application doing SSL it will work very much like non-blocking IO works
today.

Matt

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

[openssl-dev] [openssl.org #4077] Add support for EdDSA and Ed25519

[Simon Josefsson via RT]

I believe it would be useful to have OpenSSL support for Ed25519 signing
and Curve25519 key agreement.  I don't see anything on rt.openssl.org
about this (maybe the proper place to open issue is on github these
days?).  Is there interest in this from the OpenSSL team?  There are
several implementations available, but I would coordinate which one to
use with Peter Schwabe who has been working on proving correctness of
Ed25519 implementations.

/Simon



signature.asc
Description: PGP signature
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich via RT]

Also, note that the earliest this could happen is for 1.1 (it's a new feature), 
and it's not high on our priority list for that release right now.  Patches 
that are regularly rebased against master would help.


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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Alessandro Ghedini via RT]

On Thu, Oct 08, 2015 at 11:39:56am +, Salz, Rich via RT wrote:
> Also, note that the earliest this could happen is for 1.1 (it's a new
> feature), and it's not high on our priority list for that release right now.
> Patches that are regularly rebased against master would help.

I rebase my patches on master regularly when changes that cause merge conflicts
are pushed, so my camellia patches should merge cleanly.

Cheers


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

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 08/10/15 12:18, Dmitry Belyavsky wrote:
> 
> I see. So am I correct supposing that pseudo code for
> offload_cipher_to_hardware looks like this:
> 
> static int async_wrapper(void * args)
> {
> ...
> }
> 
> static ASYNC_JOB *offload (void *args)
> {
>   ASYNC_JOB *pjob = NULL;
>   int funcret;
>   size_t size = 0;
> 
>   int ret = ASYNC_start_job(, , async_wrapper, args, 
>   *args, size);
>   if (ret != ASYNC_PAUSE) return NULL;
>   return pjob;
> }
> 
> ?

No. I think you are confusing two different things.

1) How does an *application* perform asynchronous work (via libssl or
libcrypto) using an asynchronous capable engine?

2) How does an asynchronous capable engine offload async work to its
hardware?

These patches solve the first problem only. It provides an API and
mechanism for control to pass between the application and engine and
back again (perhaps multiple times) during the invocation of a long
running crypto operation. It also provides some mechanisms to enable an
engine to signal the completion of work to the application.

The second problem is entirely engine dependant. It will be a different
solution for different hardware. These patches do not provide a solution
to that problem.

Matt


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

Re: [openssl-dev] Elliptical Cipher Suites

[Aaron Jones]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/10/15 13:54, Thirumal, Karthikeyan wrote:
> Vik Am using 0.9.8a version. Am trying to fix few weak ciphers in
> my SSL connection and also to make Elliptical cipher suites
> enable. I see that ECDHE ciphers are elliptical - need more info on
> this.
> 
> Thanks & Regards

0.9.8 will be end-of-life in a matter of days, and does not support
elliptic curve cryptography; that was introduced in version 1.0.0,
also end of life soon if I recall correctly.

Version 1.0.1 is supported, and supports both ECC and TLSv1.2.
I would recommend upgrading to atleast that.

- -- 
Aaron Jones

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWFlMgAAoJEG6FTA+q1M6k8QwP/0PNp9igXfpzvPOclG0DublE
0atEp5pJwFATfphWi9ejhRJpXo4h6UP3QEhgX4e/y2RWmNdV2jCasRXGhjQEnDWD
pnoeKgNdAIFxy7jcYfj0zXk8mudX992KTKzDWErprjE5PLVnUNOjYe2rlz6blCKV
TKHafvCbUEA0B9cGJ2ed8wkDX9VZZq1pdT4Ji9oa7Nlh8jti598aO6TeJ36etfUM
vQ7hZOQLbaft5VtmmahytFsw+n4DX2b87pNrSQZURhhcAR8ZWt0+wCl+HrWgNyrA
OPEyDANys1y9u2MorxRHUtUErBD98MxklFwwc/r3DZbH6h/AxXsI4Jvz6CjMRo2G
3nuxqa4E6NELiykKccnFKiWYZHXqRNqp1OxtYO4N0HTy2EBuigyYMnVp5Lpv3r7f
TXxfDWTvttd5S+0uZ0kfaT4xSs2ctbRemJ1iXVXGpdKv/V+qqJrSDwgSdgB/+FxG
4Tbcl6Uw/RVR1LCcq7Iu4oJhpL2LoGwqXcGYumI+suDP26rkea0VMWc4AZoEsZmb
fJx3p5O4p8aMhtU+IorpnsBXRz11DrI7P/sLZdB490p2wNulNP9qNcC2SC5V4v3b
fR40omXMBk4Pdm2cAuy+MCey1pf7B9qhqVrG2XPKbs1M2oGlnlfWb22YaxiDDKsK
oskRsBrLNjugbntmtw5P
=Aqxk
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4077] Add support for EdDSA and Ed25519

[Salz, Rich]

There is a GREAT DEAL of interest in *25519 :)  It would be great to see a PR 
against master; I'd push it through the review process as fast as possible.
If you and Peter have the interest in working on this, that would be great.

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

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

On Thu, Oct 8, 2015 at 1:56 PM, Matt Caswell  wrote:

>
> > The engine needs to have a way of offloading the work to "something
> > else" so that it can come back and pick up the results later.
> Typically
> > for an engine this would mean some external hardware, but as I
> suggested
> > above it could be done using threads.
> >
> > From an engine perspective the work would be:
> > - Receive a request to do some crypto work in the normal way via the
> > engine API.
> > - Offload the work to "something else"
> >
> >
> > So what is a mechanism of such an offload? Can I, for example, get the
> > (global) ASYNC_pool and add a job (function/pointer to context) to it?
>
> The offload mechanism is entirely engine specific. We do not know how
> any specific engine works or how to interface to the hardware. An engine
> will be called in exactly the same way as now. The job of the engine
> will be to take the parameters passed to it and initiate the work in the
> engine hardware.
>
> So in pseudo code it might look something like this:
>
> static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
> unsigned char *out, const unsigned char *in, size_t inl)
> {
> int jobid;
>
> jobid = offload_cipher_to_hardware(ctx, out, in , inl);
>
> /*
>  * jobid holds a reference in the engine back to the work we just
>  * started
>  */
>
> while(work_not_finished_yet(jobid)) {
> /* Return control back to the calling application */
> ASYNC_pause_job();
> }
>
> return get_results_from_hardware(jobid);
> }
>
> You will note that ASYNC_pause_job() does *not* do a "return" to return
> control back to the user application...but calling ASYNC_pause_job()
> will cause SSL_read (or whatever) to return with SSL_ERROR_WANT_ASYNC
> nonetheless. The async job has its own private stack to enable this.
> Recalling SSL_read from the user application will appear to the engine
> like the function call ASYNC_pause_job() has returned.
>
>
> > How will the SSL struct obtain a job id from the engine implementing,
> > for example, "long" RSA_METHOD?
>
> It does not need to. The SSL object has a reference to the ASYNC_JOB.
> The engine can manage its own job ids - see the pseudo code above.
>

I see. So am I correct supposing that pseudo code for
offload_cipher_to_hardware looks like this:

static int async_wrapper(void * args)
{
...
}

static ASYNC_JOB *offload (void *args)
{
  ASYNC_JOB *pjob = NULL;
  int funcret;
  size_t size = 0;

  int ret = ASYNC_start_job(, , async_wrapper, args,
  *args, size);
  if (ret != ASYNC_PAUSE) return NULL;
  return pjob;
}

?

Thank you!

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

Re: [openssl-dev] Elliptical Cipher Suites

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 08/10/15 12:27, Aaron Jones wrote:
> On 07/10/15 13:54, Thirumal, Karthikeyan wrote:
>> Vik Am using 0.9.8a version. Am trying to fix few weak ciphers
>> in my SSL connection and also to make Elliptical cipher suites 
>> enable. I see that ECDHE ciphers are elliptical - need more info
>> on this.
> 
>> Thanks & Regards
> 
> 0.9.8 will be end-of-life in a matter of days, and does not
> support elliptic curve cryptography; that was introduced in version
> 1.0.0, also end of life soon if I recall correctly.
> 
> Version 1.0.1 is supported, and supports both ECC and TLSv1.2. I
> would recommend upgrading to atleast that.

Version 1.0.1 is EOL at end of 2016. An upgrade to 1.0.2 should be
considered.

Matt
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWFlslAAoJENnE0m0OYESRIJYIAK+jHwV2NuaLxU3FiVbYVswh
sBAczFvNTJggfZAQpaVK94S1rYK2XBeTlYz0bGv/zT74sARLtos2HxqqxLD10TgO
7yAw7OvtV5CxTu09Lf6UuYDTvATflKSREQOJQYXoMM/aK4pSQBvlChfkc7op9v+o
0RNHx4xK0A313B7tZ+fBPZnqwjruC/t1oDAVlVJ90W3y/Z0+w2cFZXbFXvUvkkPr
4HhTFXS8G1Yy+UjQ+tVbyKnHgAuR+xj6EuaLhS7xMAXJfVh34g0soB9zM36ygbHH
/Pa33tFp66QlGyTlFosFrymcq9U3PXeSIzs7HCuJZSoaHv6RGe1LJDA3qeUccb4=
=Glns
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior executed through OpenSSL tests

[Pascal Cuoq via RT]

Hello Kurt, thanks for looking into these !

On 07 Oct 2015, at 22:17, Kurt Roeckx via RT  wrote:
> 
> So some of the patches got applied, but I have some comments about
> the remaining:

> - ssl_locl.h.patch: I don't see a struct timeval
>  crypto/x509v3/v3_scts.c.  Does this comment still apply?  Maybe
>  we fixed the issue in some other way.

Sorry, this comment was unnecessarily confusing.

What we meant to say was that the OpenSSL header ssl/ssl_locl.h uses “struct 
timeval” (at line 1445: 
https://github.com/openssl/openssl/blob/b3e2272c59a5720467045e2ae62940fdb708ce76/ssl/ssl_locl.h#L1445
 ) but the POSIX header that is guaranteed to provide this type, sys/time.h, is 
not included. This is just a portability matter. It works in practice of most 
platforms because that header is dragged in by other headers.

> - malloc.patch: I started looking at it, and I have some
>  comments/questions:
>  - I currently don't see a way that s->d1 can be NULL except
>after an dtls1_free() call.  The same seem to go for
>DTLS_RECORD_LAYER_free(), ssl3_free(), pkey_hmac_cleanup(),
>aes_gcm_cleanup() and aes_ocb_cleanup().
>Are you saying there are cases we could end up calling those
>twice?

All the patches in the file malloc.patch are for problems, typically null 
pointer dereferences, that arise when the function malloc() is modeled as 
either returning a null pointer or a valid pointer to a fresh block. We know 
this because we also ran all the tests in a mode in which malloc was assumed to 
always succeed, and in that mode, none of the fixes recommended in malloc.patch 
were necessary.

So for instance, in the development version of OpenSSL that was current at the 
time of the report, that “s->d1” could be NULL because a malloc call had 
returned NULL.

>  - It seems to contain changes to the test suite to check return
>values.  It seems non-obvious that this is about memory
>allocation that might have failed, but it's probably the only
>reasons those failures can happen.

Yes, exactly. The failures of OpenSSL functions that malloc.patch adds tests 
for happen because of a specific sequence of allocation successes and failures.

>  It's a little confusing
>that it's in the same patch where you can't directly see the
>malloc failing.

Yes, it is confusing! While we are confident that each of the null pointer 
dereferences we observed can happen for a specific sequence of malloc successes 
and failures (by design of the analysis process), the fixes that we are 
suggesting may be the wrong ones for the problems we have seen. What we are 
going to do now that you have already applied many of the patches is:

- replay the same verification process on the most recent version of OpenSSL, 
and update this bug report with the issues that are still present only;

- and then give you access to the analyzer results in a way that lets you 
observe the sequence of events leading to the null pointer dereferences, and 
choose for yourselves the best remedy.






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

Re: [openssl-dev] [openssl.org #3982] [PATCH] Fix unhandled error condition in sslv2 client hello parsing

[Alessandro Ghedini via RT]

The GitHub pull request was merged, so this can be closed now.

Cheers


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

[openssl-dev] [openssl.org #4078] remove MDC2 support (1.1 dev branch)

[Emilia Käsper via RT]

Tracking ticket - if anyone has any concerns, please voice them now.

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

[openssl-dev] [openssl.org #4076] PROBLEM： there exists a wrong return value of function int_rsa_verify()

[Matt Caswell via RT]

On Thu Oct 08 08:55:45 2015, rucsoft...@163.com wrote:
> Bug Description:
> Function int_rsa_verify() defined in file crypto/rsa/rsa_sign.c would
> return 1 if a signature is valid, and 0 otherwise. The variable 'ret'
> keeps the return value, and it may be assigned to 1 if the condition
> in line 216 is satisfied. The signature is regarded as invalid if the
> conditions in line 241 are evaluated to be true, and the error message
> is dumped (in line 242) and the verify process is ended (in line 243).
> However, as variable 'ret' may keep value 1, this function will return
> 1 (in line 290) even if the signature is invalid, which will confuse
> the caller function whether the signature is really valid.

Thanks for your report. I think your analysis is partially correct. If the
condition on line 216 evaluates to true then this means that the signature data
is just a bare OCTETSTRING. Really there should be an "else" on line 225 to
prevent the other branches from occurring. As it is the code will fall through
to the "else" on line 233 and it will then attempt to parse the signature data
as DigestInfo (X509_SIG). This will clearly fail because we already know that
it is a bare OCTETSTRING. Therefore |sig| will be NULL and we will goto the
|err| label - which is exactly where we would have ended up anyway had there
been an else on line 225 as I suggest.

So there is no real impact to this. You will never get to the signature
validity test on line 241 as you suggest if line 216 evaluates to true (and
that test would not apply anyway in this case). Functionally then it is working
correctly (kind of). However I have applied a patch anyway to prevent the
erroneous attempt to parse sig, and to make things look a bit more sane:

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

Closing this ticket.

Matt


> The related code snippets in int_rsa_verify() is as following.
> 168 int int_rsa_verify(int dtype, const unsigned char *m,
> 169 unsigned int m_len,
> 170 unsigned char *rm, size_t *prm_len,
> 171 const unsigned char *sigbuf, size_t siglen, RSA
> *rsa)
> 172 {
> 173 int i, ret = 0, sigtype;
> ...
> 216 if (dtype == NID_mdc2 && i == 18 && s[0] == 0x04 && s[1] ==
> 0x10) {
> 217 if (rm) {
> 218 memcpy(rm, s + 2, 16);
> 219 *prm_len = 16;
> 220 ret = 1;
> 221 } else if (memcmp(m, s + 2, 16))
> 222 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE);
> 223 else
> 224 ret = 1;
> 225 }
> 226
> 227 /* Special case: SSL signature */
> 228 if (dtype == NID_md5_sha1) {
> 229 if ((i != SSL_SIG_LENGTH) || memcmp(s, m, SSL_SIG_LENGTH))
> 230 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE);
> 231 else
> 232 ret = 1;
> 233 } else { // dtype != NID_md5_sha1
> 234 const unsigned char *p = s;
> 235 sig = d2i_X509_SIG(NULL, , (long)i);
> 236
> 237 if (sig == NULL)
> 238 goto err;
> 239
> 240 /* Excess data can be used to create forgeries */
> 241 if (p != s + i || !rsa_check_digestinfo(sig, s, i)) {
> 242 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE);
> 243 goto err;
> 244 }
> ...
> 283 err:
> 284 if (sig != NULL)
> 285 X509_SIG_free(sig);
> 286 if (s != NULL) {
> 287 OPENSSL_cleanse(s, (unsigned int)siglen);
> 288 OPENSSL_free(s);
> 289 }
> 290 return (ret);
> 291 }
>
>
>
>
>

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

[openssl-dev] [openssl.org #3982] [PATCH] Fix unhandled error condition in sslv2 client hello parsing

[Matt Caswell via RT]

Patch was applied. Closing.

Matt

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

[openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Hubert Kario via RT]

The server does not abort connection upon receiving a Client Hello 
message with malformed session_id field.

Affects 1.0.1, 1.0.2 and master.

In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is 
defined as

  opaque SessionID<0..32>;

that means, that any SessionID longer than 32 bytes creates an 
incorrectly formatted Client Hello message, and as such, should be 
rejected.

Reproducer:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -
nodes -batch
openssl s_server -key localhost.key -cert localhost.crt

In different console:
pip install --pre tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git
cd tlsfuzzer
PYTHONPATH=. python scripts/test-invalid-session-id.py
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


signature.asc
Description: PGP signature
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4081] crypto/evp/e_dsa.c is orphaned

[Kaduk, Ben via RT]

crypto/evp/e_dsa.c contains only a single static struct variable, and
the file appears unreferenced from anywhere else in the tree.

It should be safe to remove.

-Ben

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

[openssl-dev] [openssl.org #4079] syntax error with EVP_CHECK_DES_KEY

[Kaduk, Ben via RT]

Code inspection of crypto/evp/e_des3.c reveals that !! was used instead
of || (and then subsequently reformatted by a script):

272 # ifdef EVP_CHECK_DES_KEY
273 if (DES_set_key_checked([0], >ks1)
274 ! !DES_set_key_checked([1], >ks2))
275 return 0;

-Ben

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Kurt Roeckx via RT]

On Thu, Oct 08, 2015 at 05:19:06PM +, Alessandro Ghedini via RT wrote:
> The problem most likely happens with SSLv2 backwards compatible ClientHello as
> well, but that seems to be easier to fix... or maybe it's time to just drop
> that compatibility code for v1.1?

I would love to have dropped that too, but 0.9.8 still sends such
client hello.  I think we're stuck with having to support that for
a while longer.


Kurt


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

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Viktor Dukhovni]

On Thu, Oct 08, 2015 at 04:12:50PM +, Hubert Kario via RT wrote:

> The server does not abort connection upon receiving a Client Hello 
> message with malformed session_id field.
> 
> Affects 1.0.1, 1.0.2 and master.
> 
> In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is 
> defined as
> 
>   opaque SessionID<0..32>;
>
> that means, that any SessionID longer than 32 bytes creates an 
> incorrectly formatted Client Hello message, and as such, should be 
> rejected.

Can be rejected, and perhaps even should be rejected, but I don't
see a MUST here.  It seems there's little harm in tolerating longer
session ids (which never match, so are effectively ignored).

So yes, I support adding a check for this (likely above the PACKET
layer), but I don't think this has much urgency and likely should
not be back-ported to stable releases.

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

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Kurt Roeckx]

On Thu, Oct 08, 2015 at 05:19:06PM +, Alessandro Ghedini via RT wrote:
> The problem most likely happens with SSLv2 backwards compatible ClientHello as
> well, but that seems to be easier to fix... or maybe it's time to just drop
> that compatibility code for v1.1?

I would love to have dropped that too, but 0.9.8 still sends such
client hello.  I think we're stuck with having to support that for
a while longer.


Kurt

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

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Alessandro Ghedini via RT]

On Thu, Oct 08, 2015 at 04:12:50pm +, Hubert Kario via RT wrote:
> The server does not abort connection upon receiving a Client Hello 
> message with malformed session_id field.
> 
> Affects 1.0.1, 1.0.2 and master.
> 
> In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is 
> defined as
> 
>   opaque SessionID<0..32>;
> 
> that means, that any SessionID longer than 32 bytes creates an 
> incorrectly formatted Client Hello message, and as such, should be 
> rejected.

Looking at the code in master, for non-v2 ClientHello messages the code uses
the PACKET_get_length_prefixed_1() function to extract the SessionID, however I
see no way to pass a maximum allowed length to it. I think a new function would
have to be added to the PACKET_* interface (I can look into this). Haven't
checked older branches yet.

The problem most likely happens with SSLv2 backwards compatible ClientHello as
well, but that seems to be easier to fix... or maybe it's time to just drop
that compatibility code for v1.1?

Cheers


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

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Hubert Kario via RT]

On Thursday 08 October 2015 17:19:06 Alessandro Ghedini via RT wrote:
> The problem most likely happens with SSLv2 backwards compatible
> ClientHello as well, but that seems to be easier to fix... or maybe
> it's time to just drop that compatibility code for v1.1?

There is quite a bit of clients that do send SSLv2 backwards compatible 
Client Hello, dropping it completely, even though it allows to 
relatively safely negotiate TLS connections, is probably going one step 
too far.

I don't plan to work on SSLv2 Client Hello fuzzing in near future 
though.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


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

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

On Thu, Oct 8, 2015 at 3:17 PM, Matt Caswell  wrote:

>
>
> No. I think you are confusing two different things.
>
> 1) How does an *application* perform asynchronous work (via libssl or
> libcrypto) using an asynchronous capable engine?
>

Ok. There is an example an explanation you have provided.


>
> 2) How does an asynchronous capable engine offload async work to its
> hardware?
>
> These patches solve the first problem only. It provides an API and
> mechanism for control to pass between the application and engine and
> back again (perhaps multiple times) during the invocation of a long
> running crypto operation. It also provides some mechanisms to enable an
> engine to signal the completion of work to the application.
>


> The second problem is entirely engine dependant. It will be a different
> solution for different hardware. These patches do not provide a solution
> to that problem.
>

So I do not understand what you mean by "offload" :-(

I understand that it's an engine-dependent, but I can't imagine a
corresponding pseudo code.


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

[openssl-dev] [openssl.org #4082] Patch: Unable to read SMIME message if there is no signer

[František Bořánek via RT]

Hi,
I found that Outook for MAC can generate (depends on setting) signed message 
where is not included sender's certificate. It works pretty good, but 
verification requires that recipients must already have sender certificate. 
Such message is attached.
Problem is that such message cannot be read by openssl. Normally, if a message 
has a sender certificate, following command print encapsulated message in 
smime.p7m.



    $ openssl smime -verify -noverify -nosigs -in ~/workspace/0004.eml 
     --- content of messge ---
    Verification successful


however the current behaviour is that error is reported instead the content of 
message



    $ openssl smime -verify -noverify -in ~/workspace/0005.eml 
    Verification failure
    139741085296288:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer 
certificate not found:pk7_smime.c:462:


The attached patch solve this issue. The signer certificate is not look up if 
there is no need for that. Here and results after what patch was applied.



    $ ./external/bin/openssl smime -in ~/workspace/0005.eml -verify
    Verification failure
    139737181419168:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer 
certificate not found:pk7_smime.c:472:    


   $ ./external/bin/openssl smime -in ~/workspace/0005.eml -verify -noverify
     --- content of message ---
    Verification failure
    139737181419168:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer 
certificate not found:pk7_smime.c:472:


    $ ./external/bin/openssl smime -in ~/workspace/0005.eml -verify 
-noverify -nosigs
     --- content of message ---
    Verification successful


The result for arguments -verify -noverify corresponds with behaviour where 
there is certificate but the signature is not valid. The message write out, but 
openssl return error.
 
---
Version: OpenSSL 1.0.1m 19 Mar 2015
OS: all affected


Regards,
František Bořánek
developer - Kerio Connect
.
Kerio Technologies s. r. o.
Anglicke nabrezi 1, 301 49 Plzen
Czech Republic
tel. +420 378 225 158
http://www.kerio.com
.
Connect. Communicate. Collaborate. Securely.


smime.p7m
Description: S/MIME encrypted message
diff --git a/OpenSSL/crypto/pkcs7/pk7_smime.c b/OpenSSL/crypto/pkcs7/pk7_smime.c
index dbd4100..60ce734 100644
--- a/OpenSSL/crypto/pkcs7/pk7_smime.c
+++ b/OpenSSL/crypto/pkcs7/pk7_smime.c
@@ -249,7 +249,7 @@ static int pkcs7_copy_existing_digest(PKCS7 *p7, 
PKCS7_SIGNER_INFO *si)
 int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store,
  BIO *indata, BIO *out, int flags)
 {
-STACK_OF(X509) *signers;
+STACK_OF(X509) *signers = 0;
 X509 *signer;
 STACK_OF(PKCS7_SIGNER_INFO) *sinfos;
 PKCS7_SIGNER_INFO *si;
@@ -294,14 +294,17 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, 
X509_STORE *store,
 return 0;
 }
 
-signers = PKCS7_get0_signers(p7, certs, flags);
-
-if (!signers)
-return 0;
+if(!(flags & PKCS7_NOSIGS) || !(flags & PKCS7_NOVERIFY)) {
+/* allow to read encapsulated data even if there is no signer */
+signers = PKCS7_get0_signers(p7, certs, flags);
+}
 
 /* Now verify the certificates */
-
-if (!(flags & PKCS7_NOVERIFY))
+if (!(flags & PKCS7_NOVERIFY)) {
+if (!signers) {
+return 0;
+}
+
 for (k = 0; k < sk_X509_num(signers); k++) {
 signer = sk_X509_value(signers, k);
 if (!(flags & PKCS7_NOCHAIN)) {
@@ -333,6 +336,7 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, 
X509_STORE *store,
 }
 /* Check for revocation status here */
 }
+}
 
 /*
  * Performance optimization: if the content is a memory BIO then store
@@ -384,7 +388,11 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, 
X509_STORE *store,
 }
 
 /* Now Verify All Signatures */
-if (!(flags & PKCS7_NOSIGS))
+if (!(flags & PKCS7_NOSIGS)) {
+if (!signers) {
+return 0;
+}
+
 for (i = 0; i < sk_PKCS7_SIGNER_INFO_num(sinfos); i++) {
 si = sk_PKCS7_SIGNER_INFO_value(sinfos, i);
 signer = sk_X509_value(signers, i);
@@ -394,6 +402,7 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, 
X509_STORE *store,
 goto err;
 }
 }
+}
 
 ret = 1;
 
@@ -405,7 +414,8 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, 
X509_STORE *store,
 }
 BIO_free_all(p7bio);
 
-sk_X509_free(signers);
+if (signers)
+sk_X509_free(signers);
 
 return ret;
 }


smime.p7s
Description: S/MIME cryptographic signature
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 08/10/15 18:56, Dmitry Belyavsky wrote:

> The second problem is entirely engine dependant. It will be a different
> solution for different hardware. These patches do not provide a solution
> to that problem.
> 
> 
> So I do not understand what you mean by "offload" :-(
> 
> I understand that it's an engine-dependent, but I can't imagine a
> corresponding pseudo code.

Ok. So this is the pseudo code I posted before for how an engine might
be implemented:

static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
unsigned char *out, const unsigned char *in, size_t inl)
{
int jobid;

jobid = offload_cipher_to_hardware(ctx, out, in , inl);

/*
 * jobid holds a reference in the engine back to the work we just
 * started
 */

while(work_not_finished_yet(jobid)) {
/* Return control back to the calling application */
ASYNC_pause_job();
}

return get_results_from_hardware(jobid);
}


So lets imagine an engine that works via threads and how those pseudo
code function call might be implemented. It could be something like this:

void initialise_engine(void)
{
start_thread(worker_main);
}

static int nextjobid = 0;

struct work_st {
int jobid;
EVP_CIPHER_CTX *ctx;
unsigned char *out;
unsigned char *in;
size_t inl;
int ret;
}

int worker_main(void)
{
struct work_st *work;

while(true) {
work = get_work_off_in_queue();
/* This is a long running operation */
work->ret = do_aes128_cbc_cipher(work->ctx, work->out, work->in,
work->inl);
put_work_in_finished_set(work);
}
}

int offload_cipher_to_hardware(EVP_CIPHER_CTX *ctx, unsigned char *out,
unsigned char *in, size_t inl) {
struct work_st *work;

work = malloc(sizeof *work);
work->ctx = ctx;
work->out = out;
work->in = in;
work->inl = inl;
work->jobid = nextjobid++;

add_work_to_in_queue(work);

return work->jobid;
}

int work_not_finished_yet(int jobid)
{
return !is_work_in_finished_set(jobid);
}

int get_results_from_hardware(int jobid)
{
struct work_st *work;

work = get_work_out_of_finished_set(jobid);

return work->ret;
}

In a hardware based engine everything in "worker_main" would be
implemented in the hardware. So the hardware gets on with the long
running crypto operation, whilst in the software control has returned
back to the application.

Does that make more sense?

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

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear  Matt,

On Thu, Oct 8, 2015 at 10:06 PM, Matt Caswell  wrote:

>
>
> On 08/10/15 18:56, Dmitry Belyavsky wrote:
>
> > The second problem is entirely engine dependant. It will be a
> different
> > solution for different hardware. These patches do not provide a
> solution
> > to that problem.
> >
> >
> > So I do not understand what you mean by "offload" :-(
> >
> > I understand that it's an engine-dependent, but I can't imagine a
> > corresponding pseudo code.
>
> Ok. So this is the pseudo code I posted before for how an engine might
> be implemented:
>
> static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
> unsigned char *out, const unsigned char *in, size_t inl)
> {
> int jobid;
>
> jobid = offload_cipher_to_hardware(ctx, out, in , inl);
>
> /*
>  * jobid holds a reference in the engine back to the work we just
>  * started
>  */
>
> while(work_not_finished_yet(jobid)) {
> /* Return control back to the calling application */
> ASYNC_pause_job();
> }
>
> return get_results_from_hardware(jobid);
> }
>
>
> So lets imagine an engine that works via threads and how those pseudo
> code function call might be implemented. It could be something like this:
>
> void initialise_engine(void)
> {
> start_thread(worker_main);
> }
>
> static int nextjobid = 0;
>
> struct work_st {
> int jobid;
> EVP_CIPHER_CTX *ctx;
> unsigned char *out;
> unsigned char *in;
> size_t inl;
> int ret;
> }
>
> int worker_main(void)
> {
> struct work_st *work;
>
> while(true) {
> work = get_work_off_in_queue();
> /* This is a long running operation */
> work->ret = do_aes128_cbc_cipher(work->ctx, work->out, work->in,
> work->inl);
> put_work_in_finished_set(work);
> }
> }
>
> int offload_cipher_to_hardware(EVP_CIPHER_CTX *ctx, unsigned char *out,
> unsigned char *in, size_t inl) {
> struct work_st *work;
>
> work = malloc(sizeof *work);
> work->ctx = ctx;
> work->out = out;
> work->in = in;
> work->inl = inl;
> work->jobid = nextjobid++;
>
> add_work_to_in_queue(work);
>
> return work->jobid;
> }
>
> int work_not_finished_yet(int jobid)
> {
> return !is_work_in_finished_set(jobid);
> }
>
> int get_results_from_hardware(int jobid)
> {
> struct work_st *work;
>
> work = get_work_out_of_finished_set(jobid);
>
> return work->ret;
> }
>
> In a hardware based engine everything in "worker_main" would be
> implemented in the hardware. So the hardware gets on with the long
> running crypto operation, whilst in the software control has returned
> back to the application.
>
> Does that make more sense?
>

Thank you! I finally got it.


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

Re: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior executed through OpenSSL tests

[Kurt Roeckx via RT]

On Thu, Oct 08, 2015 at 01:36:07PM +, Pascal Cuoq via RT wrote:
> > - ssl_locl.h.patch: I don't see a struct timeval
> >  crypto/x509v3/v3_scts.c.  Does this comment still apply?  Maybe
> >  we fixed the issue in some other way.
> 
> Sorry, this comment was unnecessarily confusing.
> 
> What we meant to say was that the OpenSSL header ssl/ssl_locl.h uses "struct 
> timeval" (at line 1445: 
> https://github.com/openssl/openssl/blob/b3e2272c59a5720467045e2ae62940fdb708ce76/ssl/ssl_locl.h#L1445
>  ) but the POSIX header that is guaranteed to provide this type, sys/time.h, 
> is not included. This is just a portability matter. It works in practice of 
> most platforms because that header is dragged in by other headers.

I understand that it's a portability issue.  But since it's not
part of the C standard we can't unconditionally include it either
because that would create other protability issues.  d1_lib.c for
instance has:
#if defined(OPENSSL_SYS_VMS)
# include 
#elif defined(OPENSSL_SYS_NETWARE) && !defined(_WINSOCK2API_)
# include 
#elif defined(OPENSSL_SYS_VXWORKS)
# include 
#elif !defined(OPENSSL_SYS_WIN32)
# include 
#endif

While bss_dgram.c just has:
# if !(defined(_WIN32) || defined(OPENSSL_SYS_VMS))
#  include 
# endif
# if defined(OPENSSL_SYS_VMS)
#  include 
# endif

> > - malloc.patch: I started looking at it, and I have some
> >  comments/questions:
> >  - I currently don't see a way that s->d1 can be NULL except
> >after an dtls1_free() call.  The same seem to go for
> >DTLS_RECORD_LAYER_free(), ssl3_free(), pkey_hmac_cleanup(),
> >aes_gcm_cleanup() and aes_ocb_cleanup().
> >Are you saying there are cases we could end up calling those
> >twice?
> 
> All the patches in the file malloc.patch are for problems, typically null 
> pointer dereferences, that arise when the function malloc() is modeled as 
> either returning a null pointer or a valid pointer to a fresh block. We know 
> this because we also ran all the tests in a mode in which malloc was assumed 
> to always succeed, and in that mode, none of the fixes recommended in 
> malloc.patch were necessary.
> 
> So for instance, in the development version of OpenSSL that was current at 
> the time of the report, that "s->d1" could be NULL because a malloc call had 
> returned NULL.

I see a check for the malloc() return value there, and as far as I
can see it's always been there. 

But you only mention the free calls while the variables are used
at other places without checking that it's NULL or not.  So I
wonder if this is some false positive, which I understand you
actually try to avoid.  So I'm guessing we're missing something,
like calling free after new failed or something.

> - replay the same verification process on the most recent version of OpenSSL, 
> and update this bug report with the issues that are still present only;
> 
> - and then give you access to the analyzer results in a way that lets you 
> observe the sequence of events leading to the null pointer dereferences, and 
> choose for yourselves the best remedy.

That would be great.


Kurt


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

[openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW...

[christian fafard via RT]

With version 'openssl-1.0.2d',in file 'test/Makefile',at line 244 shown above,
@) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) 
{die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i 
tests passed\n"'
Make test fail because you use this snippet of perl's code '(!/^0$$/)' to match 
any lines not containing only a single zero.It doesn't work as expected with 
the version 5.8.8 of perl distributed with mingw32, as you can see from the 
message above.
verify BN_addFailed! bc: 0make[1]: *** [test_bn] Error 255
I use this equivalent line to avoid the problematic negation of regex match 
'!//',
@) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) 
{print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR "\n$$i 
tests passed\n"'
I'm not expert enough to know if this code is more portable on every platforms 
and versions of perl, i'll leave it to you.
ThanksChristian Fafard
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4084] correction to the message i sent earlier...

[christian fafard via RT]

In my previous message, i mixed "above" and "below" so it was maybe unreadable 
a bit.
Sorry!
Christian Fafard  
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Alessandro Ghedini via RT]

On Thu, Oct 08, 2015 at 06:14:00pm +, Alessandro Ghedini via RT wrote:
> On Thu, Oct 08, 2015 at 05:19:06pm +, Alessandro Ghedini via RT wrote:
> > On Thu, Oct 08, 2015 at 04:12:50pm +, Hubert Kario via RT wrote:
> > > The server does not abort connection upon receiving a Client Hello 
> > > message with malformed session_id field.
> > > 
> > > Affects 1.0.1, 1.0.2 and master.
> > > 
> > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is 
> > > defined as
> > > 
> > >   opaque SessionID<0..32>;
> > > 
> > > that means, that any SessionID longer than 32 bytes creates an 
> > > incorrectly formatted Client Hello message, and as such, should be 
> > > rejected.
> > 
> > Looking at the code in master, for non-v2 ClientHello messages the code uses
> > the PACKET_get_length_prefixed_1() function to extract the SessionID, 
> > however I
> > see no way to pass a maximum allowed length to it. I think a new function 
> > would
> > have to be added to the PACKET_* interface (I can look into this). Haven't
> > checked older branches yet.
> 
> So, it turns out the check was already performed, but this failure didn't 
> cause
> the session to be aborted (the original PACKET was advanced anyway though, 
> even
> is the session_id isn't actually extracted), I don't know if this was on
> purpose though.

Another thing to consider is that the client already aborts when an invalid
session_id is received in the ServerHello and sends the ILLEGAL_PARAMETER alert.

My patch doesn't actually send any alert so the check should be moved earlier
to allow an alert to be sent, if that is desired.

Cheers


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

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Alessandro Ghedini via RT]

On Thu, Oct 08, 2015 at 05:19:06pm +, Alessandro Ghedini via RT wrote:
> On Thu, Oct 08, 2015 at 04:12:50pm +, Hubert Kario via RT wrote:
> > The server does not abort connection upon receiving a Client Hello 
> > message with malformed session_id field.
> > 
> > Affects 1.0.1, 1.0.2 and master.
> > 
> > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is 
> > defined as
> > 
> >   opaque SessionID<0..32>;
> > 
> > that means, that any SessionID longer than 32 bytes creates an 
> > incorrectly formatted Client Hello message, and as such, should be 
> > rejected.
> 
> Looking at the code in master, for non-v2 ClientHello messages the code uses
> the PACKET_get_length_prefixed_1() function to extract the SessionID, however 
> I
> see no way to pass a maximum allowed length to it. I think a new function 
> would
> have to be added to the PACKET_* interface (I can look into this). Haven't
> checked older branches yet.

So, it turns out the check was already performed, but this failure didn't cause
the session to be aborted (the original PACKET was advanced anyway though, even
is the session_id isn't actually extracted), I don't know if this was on
purpose though.

In any case I wrote a minimal patch that makes the tlsfuzzer test pass (it may
even work for SSLv2 as well):
https://github.com/openssl/openssl/pull/437

Cheers


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

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Hubert Kario]

On Thursday 08 October 2015 17:37:12 Viktor Dukhovni wrote:
> On Thu, Oct 08, 2015 at 04:12:50PM +, Hubert Kario via RT wrote:
> > The server does not abort connection upon receiving a Client Hello
> > message with malformed session_id field.
> > 
> > Affects 1.0.1, 1.0.2 and master.
> > 
> > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is
> > defined as
> > 
> >   opaque SessionID<0..32>;
> > 
> > that means, that any SessionID longer than 32 bytes creates an
> > incorrectly formatted Client Hello message, and as such, should be
> > rejected.
> 
> Can be rejected, and perhaps even should be rejected, but I don't
> see a MUST here.  It seems there's little harm in tolerating longer
> session ids (which never match, so are effectively ignored).

RFC 5246:
   decode_error
  A message could not be decoded because some field was out of the
  specified range or the length of the message was incorrect.  This
  message is always fatal and should never be observed in
  communication between proper implementations (except when messages
  were corrupted in the network)

(yes, it's not a MUST either, but I'm afraid that this was simply "too 
obvious" for designers of protocol)

> So yes, I support adding a check for this (likely above the PACKET
> layer), but I don't think this has much urgency and likely should
> not be back-ported to stable releases.

oh, sure, that particular problem isn't a serious issue, but I'm going 
through all fields and all messages so that we have full coverage (e.g. 
for valgrind)

also, accepting bigger session id's means that the session cache code is 
exercised in ways that it usually isn't, that's not a good thing to 
happen (even if it handles them correctly, as it seems, defence in depth 
is a good idea anyway)
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Alessandro Ghedini via RT]

On Thu, Oct 08, 2015 at 06:26:27pm +, Alessandro Ghedini via RT wrote:
> On Thu, Oct 08, 2015 at 06:14:00pm +, Alessandro Ghedini via RT wrote:
> > On Thu, Oct 08, 2015 at 05:19:06pm +, Alessandro Ghedini via RT wrote:
> > > On Thu, Oct 08, 2015 at 04:12:50pm +, Hubert Kario via RT wrote:
> > > > The server does not abort connection upon receiving a Client Hello 
> > > > message with malformed session_id field.
> > > > 
> > > > Affects 1.0.1, 1.0.2 and master.
> > > > 
> > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is 
> > > > defined as
> > > > 
> > > >   opaque SessionID<0..32>;
> > > > 
> > > > that means, that any SessionID longer than 32 bytes creates an 
> > > > incorrectly formatted Client Hello message, and as such, should be 
> > > > rejected.
> > > 
> > > Looking at the code in master, for non-v2 ClientHello messages the code 
> > > uses
> > > the PACKET_get_length_prefixed_1() function to extract the SessionID, 
> > > however I
> > > see no way to pass a maximum allowed length to it. I think a new function 
> > > would
> > > have to be added to the PACKET_* interface (I can look into this). Haven't
> > > checked older branches yet.
> > 
> > So, it turns out the check was already performed, but this failure didn't 
> > cause
> > the session to be aborted (the original PACKET was advanced anyway though, 
> > even
> > is the session_id isn't actually extracted), I don't know if this was on
> > purpose though.
> 
> Another thing to consider is that the client already aborts when an invalid
> session_id is received in the ServerHello and sends the ILLEGAL_PARAMETER 
> alert.
> 
> My patch doesn't actually send any alert so the check should be moved earlier
> to allow an alert to be sent, if that is desired.

FYI, I just pushed another patch that does the above (moving the check and
sending an alert) which I think is the best option (although, as Hubert pointed
out, sending the decode_error alert is not a MUST). If that's ok with you, I
can squash the two commits together and give them a better message, otherwise
just ignore the second patch.

Cheers


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

Re: [openssl-dev] [openssl.org #4081] crypto/evp/e_dsa.c is orphaned

[Alessandro Ghedini via RT]

On Thu, Oct 08, 2015 at 04:18:53pm +, Kaduk, Ben via RT wrote:
> crypto/evp/e_dsa.c contains only a single static struct variable, and
> the file appears unreferenced from anywhere else in the tree.
> 
> It should be safe to remove.

This is now fixed in my "Remove useless code" patch at
https://github.com/openssl/openssl/pull/436

Cheers


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