Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext

[The Tester via RT]

Is there a better demo program I can use as the basis for my code? I'd be happy 
to redo my stuff based on anything that I can download and run without having 
to dig through the OpenSSL/test sets to try to find hints (which I've done, but 
there didn't seem to be a simple AES128/cbc test that I could find. The only 
matches from the string were in test binaries for ssl and evp).

And one apparently irrelevant error: the first version on Fedora below I forgot 
to change the demo code from ASE256 ot AES128... but the Valgrind complaints 
are the same when I make the change.

...
==2810== Conditional jump or move depends on uninitialised value(s)==2810==    
at 0x4C2A79E: strncmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2810==    by 0x400FF1: main (in /home/digidev/test/a.out)
==2810==  Uninitialised value was created by a stack allocation
==2810==    at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e)
...
The advantage of the Fedora VM is that it's literally brand new out of the box 
- I downloaded the latest Fedora Desktop ISO, installed using the defaults, 
then ran through the "yum install..." iterations I needs to be able to 
reproduce the problem. I suspect that you could do that in one line:
   yum install gpp gcc-c++ valgrind openssl openssl-devel

(I appreciate that this is ~500MB of download and an hour or so to install, but 
it does mean that you should be able to reproduce the problem if you're really 
desperate).

Chris

  From: The Tester 
 To: "r...@openssl.org"  
Cc: "openssl-dev@openssl.org"  
 Sent: Tuesday, 9 December 2014, 15:35
 Subject: Re: [openssl.org #3622] bug: crypto, valgrind reports improper memory 
access with AES128 cbc and longer plaintext
   
Thanks for the response, Andy, it's good to know that the demo program does 
actually work for someone. Sorry for the delay, I'm kinda busy with other 
things right now. Also, I realised the link was truncated, but it looks as 
though you found the demo anyway. 
https://github.com/saju/misc/blob/master/misc/openssl_aes.c
The demo program actually allocates a whole extra block for the output, so 
there should always be extra space available. Switching to calloc instead of 
malloc does not hide the issue, which suggests that it's actually a problem 
somewhere in the bowels of OpenSSL, copying unassigned values into the output. 
Likewise, the demo program uses null-terminated strings because they're easy to 
see in operation. My real program uses manually padded, known-size binary 
packets but adding extra code to show that did not seem worth while. It would 
likely lead to a bunch of other questions about design decisions and other 
irrelevancies when the problem is that valgrind is unhappy about the way 
OpenSSL (appears to) work.

I've just re-tested, pasting the code in to both C and C++ netbeans projects 
(since that's what my main project uses) and fixing the C++ convert-from-const 
errors as well as adding aes.h. Both give the same valgrind issues for me. I'm 
using  "gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)" and "valgrind-3.10.0.SVN" 
if that might make a difference.
Experimentation shows that the magic length is 96 bytes - strlen()=94 works 
fine on my machine, strlen()=95 produces the valgrind complaints. That means 
input length of 96, since the code uses strlen()+1. What's magic about a 96 
byte input size? (other than being 6 AES128 blocks)


Since I have a new Fedora 20 virtual machine handy I have also run on that with 
the same result:Using OpenSSL version "OpenSSL 1.0.1e-fips 11 Feb 2013"
==2793== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
...
==2793== Conditional jump or move depends on uninitialised value(s)
==2793==    at 0x4C2A79E: strncmp (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2793==    by 0x400FA1: main (in /home/digidev/test/a.out)
==2793==  Uninitialised value was created by a stack allocation
==2793==    at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e)
...

I hoped that the padding functions would mean that manually padding the inputs 
was not necessary. Admittedly in my real code I am doing manual padding to get 
control over the padding - the hardware I'm communicating with does not pad or 
accept padding on a plaintext that is an exact multiple of the block size where 
OpenSSL/PKCS does. But the demo uses auto padding, and I'd hoped that it would 
work.

aes_encrypt function has this:

    /* update ciphertext with the final remaining bytes */
    EVP_EncryptFinal_ex(e, ciphertext + encryptedLength, &paddingLength);
    *len = encryptedLength + paddingLength;

Surely this means that the output is padded and therefore the input does not 
need to be a multiple of the block size. The program claims to work without 
manual padding, anyway.

As far as querying the block size, that has ramifications beyond my program so 
changing it would break compatibility with hardware we've already shipped (for 
example). Al

Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext

[The Tester via RT]

Thanks for the response, Andy, it's good to know that the demo program does 
actually work for someone. Sorry for the delay, I'm kinda busy with other 
things right now. Also, I realised the link was truncated, but it looks as 
though you found the demo anyway. 
https://github.com/saju/misc/blob/master/misc/openssl_aes.c
The demo program actually allocates a whole extra block for the output, so 
there should always be extra space available. Switching to calloc instead of 
malloc does not hide the issue, which suggests that it's actually a problem 
somewhere in the bowels of OpenSSL, copying unassigned values into the output. 
Likewise, the demo program uses null-terminated strings because they're easy to 
see in operation. My real program uses manually padded, known-size binary 
packets but adding extra code to show that did not seem worth while. It would 
likely lead to a bunch of other questions about design decisions and other 
irrelevancies when the problem is that valgrind is unhappy about the way 
OpenSSL (appears to) work.

I've just re-tested, pasting the code in to both C and C++ netbeans projects 
(since that's what my main project uses) and fixing the C++ convert-from-const 
errors as well as adding aes.h. Both give the same valgrind issues for me. I'm 
using  "gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)" and "valgrind-3.10.0.SVN" 
if that might make a difference.
Experimentation shows that the magic length is 96 bytes - strlen()=94 works 
fine on my machine, strlen()=95 produces the valgrind complaints. That means 
input length of 96, since the code uses strlen()+1. What's magic about a 96 
byte input size? (other than being 6 AES128 blocks)


Since I have a new Fedora 20 virtual machine handy I have also run on that with 
the same result:Using OpenSSL version "OpenSSL 1.0.1e-fips 11 Feb 2013"
==2793== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
...
==2793== Conditional jump or move depends on uninitialised value(s)
==2793==    at 0x4C2A79E: strncmp (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2793==    by 0x400FA1: main (in /home/digidev/test/a.out)
==2793==  Uninitialised value was created by a stack allocation
==2793==    at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e)
...

I hoped that the padding functions would mean that manually padding the inputs 
was not necessary. Admittedly in my real code I am doing manual padding to get 
control over the padding - the hardware I'm communicating with does not pad or 
accept padding on a plaintext that is an exact multiple of the block size where 
OpenSSL/PKCS does. But the demo uses auto padding, and I'd hoped that it would 
work.

aes_encrypt function has this:

    /* update ciphertext with the final remaining bytes */
    EVP_EncryptFinal_ex(e, ciphertext + encryptedLength, &paddingLength);
    *len = encryptedLength + paddingLength;

Surely this means that the output is padded and therefore the input does not 
need to be a multiple of the block size. The program claims to work without 
manual padding, anyway.

As far as querying the block size, that has ramifications beyond my program so 
changing it would break compatibility with hardware we've already shipped (for 
example). All I could do if I queried was check against the hard-coded value 
and exit abruptly since my program will not work.
 ThanksChris
 

 From: Andy Polyakov via RT 
 To: prwh...@yahoo.com.au 
Cc: openssl-dev@openssl.org 
 Sent: Saturday, 6 December 2014, 3:27
 Subject: Re: [openssl.org #3622] bug: crypto, valgrind reports improper memory 
access with AES128 cbc and longer plaintext
   
> I started with an AES256 demo I found at https://github.com/saju/misc and 
> modified the initialisations to use AES128. The test strings that program 
> uses are quite short - less than 100 characters. If I add a significantly 
> longer string to those test values Valgrind reports a string of what I 
> suspect are buffer overruns. Note that I discovered this in my real code and 
> this is a simple test case that seems to demonstrate the same problem. I also 
> print the library version that the program is using.

I don't get any valgrind errors, not a single one. But then I had to add
-DAES_BLOCK_SIZE=16 at compiler command line, as program in question
failed to include . Well, I don't really want to say
"failed to include", because it implies that I'd suggest to do so, when
I don't actually mean to. Correct solution in real life would be to
query cipher block size with EVP_CIPHER_block_size, as opposite to
relying on cipher-specific header. It's just that I see no point in
fixing that program.

As for alleged buffer overruns in your program. You have to recognize
and remember that AES is a block cipher, which means that CBC encrypt
output and decrypt input lengths has to be divisible by block size.
[Ideally even encrypt input and decrypt output lengths should be
divisible, but EVP gives you some help by padding encrypt input.] I

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

[Richard Moore via RT]

On 8 December 2014 at 19:20, Steffen Nurpmeso via RT  wrote:

> and finally i propose three new values for the "Protocol" slot of
> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.
>

In Qt we've added an enum value for TLS versions that is SecureProtocols so
that we could remove versions as required without requiring apps to be
updated. It's an open question which is more likely to get updated - Qt or
the apps of course. For Qt 5.4 which is due out this week we've removed
SSL3 from this enum so apps will silently get updated to drop support for
it.

Cheers

Rich.

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

[Richard Moore]

On 8 December 2014 at 19:20, Steffen Nurpmeso via RT  wrote:

> and finally i propose three new values for the "Protocol" slot of
> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.
>

In Qt we've added an enum value for TLS versions that is SecureProtocols so
that we could remove versions as required without requiring apps to be
updated. It's an open question which is more likely to get updated - Qt or
the apps of course. For Qt 5.4 which is due out this week we've removed
SSL3 from this enum so apps will silently get updated to drop support for
it.

Cheers

Rich.
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3181] [PATCH] OCB

[Andy Polyakov]

> OCB support has been merged in. Closing my own ticket.

Following is not directly related to the case per se [which is why rt
doesn't get this message]. It's just that it makes nice example on why
one sometimes wants to implement encryption mode in assembly. If you
compare performance on AES-NI-capable processor, you'll see significant
differences depending on compiler used. Here is result for clang:

type...  8192 bytes
aes-128-ocb ...  909434.88k

And here is for gcc

aes-128-ocb ...  399447.38k

Thing is that hardware-assisted crypto is so fast that surrounding code
can start dominating execution time. I mean above is indication of such
case. And it also likely to mean that even former above result is
actually far from optimal, it's surely possible to improve it by several
*times*. Indeed, OCB is parallelizeable mode, and it should be close to
other parallelizeable ones. Here is CTR result from same processor:

aes-128-ctr ...  4407367.00k

Well, it's AEAD, so there would be some overhead, but it's minimal in
OCB. But let's compare to GCM anyway:

aes-128-gcm ...  2719591.59k

Once again, this is *not* some kind of objection, only a note that *if*
we decide to consider the mode in question important, it should be
possible to improve it by factor of several times on contemporary CPUs.

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

[Kurt Roeckx via RT]

On Mon, Dec 08, 2014 at 08:20:44PM +0100, Steffen Nurpmeso via RT wrote:
> Hello,
> 
> and finally i propose three new values for the "Protocol" slot of
> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.

I actually find the option unfortunate and I think it should have
been one that sets the minimum and maximum version.  But I think
we're too late 1.0.2 process to still change this.


Kurt


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Kurt Roeckx via RT]

On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote:
>   set ssl-protocol="ALL,-SSLv2"
> 
> This results in the obvious problem that when they (get)
> upgrade(d) their OpenSSL library they will see a completely
> intransparent error message that no normal user will understand:

It was actually my intention to keep supporting that, but I seem
to have removed that line.  I think the following patch should fix
that:
--- a/ssl/ssl_conf.c
+++ b/ssl/ssl_conf.c
@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx,
const char *value)
static const ssl_flag_tbl ssl_protocol_list[] =
{
SSL_FLAG_TBL_INV("ALL", SSL_OP_NO_SSL_MASK),
+   SSL_FLAG_TBL_INV("SSLv2", SSL_OP_NO_SSLv2),
SSL_FLAG_TBL_INV("SSLv3", SSL_OP_NO_SSLv3),
SSL_FLAG_TBL_INV("TLSv1", SSL_OP_NO_TLSv1),
SSL_FLAG_TBL_INV("TLSv1.1", SSL_OP_NO_TLSv1_1),


Kurt


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

[Salz, Rich via RT]

I think magic names -- shorthands -- are a very bad idea.  They are 
point-in-time statements whose meaning evolves, if not erodes, over time.


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

[Salz, Rich]

I think magic names -- shorthands -- are a very bad idea.  They are 
point-in-time statements whose meaning evolves, if not erodes, over time.

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Hello,

and finally i propose three new values for the "Protocol" slot of
SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.

I included OLDEST for completeness sake, NEWEST is in effect what
i've always forced for my thing whenever possible, and encouraged
users to use themselve, but of course it was pretty inflexible
before the advent of NEWEST.  :)

I think VULNERABLE is a good thing to have despite it's
humiliating name, because it could be used to automatically secure
users by simply updating the OpenSSL library, effectively giving
the option to obsolete insecure protocols faster than what was
possible in the past, and of course: only possibly so.
But anyway: in my opinion it would be a real security improvement
if users could either use "-ALL,NEWEST", or, shall that not be
possible, "ALL,-VULNERABLE", rather in the spirit "configure once
and forget, but stay secure".  Or something along these lines.

Find attached a patch that does this and can be applied on top of
the other two patches i've send regarding SSL_CONF_CTX.
Notes:

  - Readds a dummy SSLv2 value (thus includes a patch for the
other issue i've opened).

  - Fixes some whitespace-at-eol issues of the .pod.

Thanks and ciao.

P.S.: i plan to release a new minor of my thing before the
christian christmas feast, it would be _really_ great to know what
the OpenSSL thinks regarding the function renaming and these new
values, since i'm switching over to the new SSL_CONF_CTX interface
and am implementing a wrapper unless HAVE_OPENSSL_CONF_CTX becomes
omnipresent.
Thank you.

--steffen

diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod
index b6aa600..4e8b67c 100644
--- a/doc/ssl/SSL_CONF_CTX_cmd.pod
+++ b/doc/ssl/SSL_CONF_CTX_cmd.pod
@@ -74,7 +74,7 @@ B). Curve names are case sensitive.
 
 =item B<-named_curve>
 
-This sets the temporary curve used for ephemeral ECDH modes. Only used by 
+This sets the temporary curve used for ephemeral ECDH modes. Only used by
 servers
 
 The B argument is a curve name or the special value B which
@@ -85,7 +85,7 @@ can be either the B name (e.g. B) or an OpenSSL OID name
 =item B<-cipher>
 
 Sets the cipher suite list to B. Note: syntax checking of B is
-currently not performed unless a B or B structure is 
+currently not performed unless a B or B structure is
 associated with B.
 
 =item B<-cert>
@@ -111,7 +111,7 @@ operations are permitted.
 
 =item B<-no_ssl3>, B<-no_tls1>, B<-no_tls1_1>, B<-no_tls1_2>
 
-Disables protocol support for SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2 
+Disables protocol support for SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2
 by setting the corresponding options B,
 B, B and B respectively.
 
@@ -177,7 +177,7 @@ Note: the command prefix (if set) alters the recognised B values.
 =item B
 
 Sets the cipher suite list to B. Note: syntax checking of B is
-currently not performed unless an B or B structure is 
+currently not performed unless an B or B structure is
 associated with B.
 
 =item B
@@ -244,7 +244,7 @@ B). Curve names are case sensitive.
 
 =item B
 
-This sets the temporary curve used for ephemeral ECDH modes. Only used by 
+This sets the temporary curve used for ephemeral ECDH modes. Only used by
 servers
 
 The B argument is a curve name or the special value B which
@@ -259,9 +259,17 @@ The supported versions of the SSL or TLS protocol.
 The B argument is a comma separated list of supported protocols to
 enable or disable. If an protocol is preceded by B<-> that version is disabled.
 All versions are enabled by default, though applications may choose to
-explicitly disable some. Currently supported protocol values are 
-B, B, B and B. The special value B refers
-to all supported versions.
+explicitly disable some.
+Currently supported protocol values are
+B, B, B and B.
+
+Some special values are understood:
+B refers to all supported versions,
+B will always refer to the newest of the supported protocols,
+currently B,
+B refers to the oldest supported protocol, currently B,
+and B includes all protocols which have known vulnerabilities
+(in the default configuration).
 
 =item B
 
@@ -339,16 +347,16 @@ The value is a directory name.
 The order of operations is significant. This can be used to set either defaults
 or values which cannot be overridden. For example if an application calls:
 
- SSL_CONF_CTX_cmd(ctx, "Protocol", "-SSLv2");
+ SSL_CONF_CTX_cmd(ctx, "Protocol", "-SSLv3");
  SSL_CONF_CTX_cmd(ctx, userparam, uservalue);
 
-it will disable SSLv2 support by default but the user can override it. If 
+it will disable SSLv3 support by default but the user can override it. If
 however the call sequence is:
 
  SSL_CONF_CTX_cmd(ctx, userparam, uservalue);
- SSL_CONF_CTX_cmd(ctx, "Protocol", "-SSLv2");
+ SSL_CONF_CTX_cmd(ctx, "Protocol", "-SSLv3");
 
-SSLv2 is B disabled and attempt to override this by the user are
+SSLv3 is B disabled and attempt to override this by the user are
 ignored.
 
 By checking the return code of SSL_CONF_CTX_cmd() it is possible to que

[openssl-dev] [openssl.org #3626] Entropy on Win discounts CryptGenRandom length

[Glen Miner via RT]

rand_win.c(361) RAND_add(buf, sizeof(buf), 0);This is inconsistent with line 
375 which passes sizeof(buf) for the bytes of entropy.
This means that the entropy from the OS pool is discounted; in normal 
circumstances this is insignificant because the rest of this function collects 
plenty of entropy from the rest of the system.
In rare cases this leads to problems in md_rand.c -- line 403
ok = (entropy >= ENTROPY_NEEDED);   if (!ok)
In the case that rand_win.c doesn't seed with enough entropy it goes on to stir 
the pool it but never sets 'ok' afterward and so ssleay_rand_bytes returns 
failure which seems a bit harsh.
Locally we've changed rand_win.c to pass sizeof(buf) when adding the entropy 
from PROV_RSA_FULL which avoids the problems in md_rand.c -- I'm not sure what 
the intention is there, though.
The rare case involved actually came about after we discovered that RAND_poll 
was locking heaps in our process and generally causing massive hitches in 
certain parts of our game; once we'd traced it back to this heap-crawling stuff 
we made two changes to RAND_poll:
1) We increased the size of buf to 10242) We changed line 45 to if (kernel && 
!good)
The idea is that if the OS entropy pool will feed us a good chunk of good 
random numbers we can avoid beating the hell out of the heap which required 
serialization. Initially we found this worked great until certain users started 
complaining about OpenSSL errors because of the bugs described above -- it 
turns out some of them had turned off the OS Workstation service which was 
contributing entropy in rand_win.c(269) which brought us below the required 
amount of entropy in md_rand.c and here we are.
-g
  
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Steffen Nurpmeso via RT]

Commit [45f55f6] (Remove SSLv2 support, 2014-11-30) completely
removed SSLv2 support and the commit message states "The only
support for SSLv2 left is receiving a SSLv2 compatible client
hello".

If people start using SSL_CONF_CTX as they are supposed to with
v1.0.2, then it can be expected that users start using strings
like, e.g. (from my thing),

  set ssl-protocol="ALL,-SSLv2"

This results in the obvious problem that when they (get)
upgrade(d) their OpenSSL library they will see a completely
intransparent error message that no normal user will understand:

  SSL_CONF_CTX_cmd() failed:\
  error:1414E180:SSL routines:SSL_CONF_CTX_cmd:bad value

(Ah ja, my _CTX_ diff also works in practice.)
I think it would be much better if at least a user request to
explicitly disable SSLv2 is silently ignored. 
Another option would be to enhance the error message, of course...

--steffen


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3624] Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8]

[Steffen Nurpmeso via RT]

Oh yes: and on top of that former patch there really where also
dangling SSL_CTX_cmd() use cases in .pod files, which are thus and
finally changed to SSL_CONF_CTX_cmd via the attached patch, too.
Thank you.

--steffen

diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod
index ccc3dd5..b6aa600 100644
--- a/doc/ssl/SSL_CONF_CTX_cmd.pod
+++ b/doc/ssl/SSL_CONF_CTX_cmd.pod
@@ -351,26 +351,26 @@ however the call sequence is:
 SSLv2 is B disabled and attempt to override this by the user are
 ignored.
 
-By checking the return code of SSL_CTX_cmd() it is possible to query if a
-given B is recognised, this is useful is SSL_CTX_cmd() values are
+By checking the return code of SSL_CONF_CTX_cmd() it is possible to query if
+a given B is recognised, this is useful is SSL_CONF_CTX_cmd() values are
 mixed with additional application specific operations.
 
-For example an application might call SSL_CTX_cmd() and if it returns
+For example an application might call SSL_CONF_CTX_cmd() and if it returns
 -2 (unrecognised command) continue with processing of application specific
 commands.
 
-Applications can also use SSL_CTX_cmd() to process command lines though the
-utility function SSL_CTX_cmd_argv() is normally used instead. One way
-to do this is to set the prefix to an appropriate value using
+Applications can also use SSL_CONF_CTX_cmd() to process command lines though
+the utility function SSL_CONF_CTX_cmd_argv() is normally used instead.
+One way to do this is to set the prefix to an appropriate value using
 SSL_CONF_CTX_set1_prefix(), pass the current argument to B and the
 following argument to B (which may be NULL).
 
 In this case if the return value is positive then it is used to skip that
-number of arguments as they have been processed by SSL_CTX_cmd(). If -2 is
-returned then B is not recognised and application specific arguments
-can be checked instead. If -3 is returned a required argument is missing
-and an error is indicated. If 0 is returned some other error occurred and
-this can be reported back to the user.
+number of arguments as they have been processed by SSL_CONF_CTX_cmd().
+If -2 is returned then B is not recognised and application specific
+arguments can be checked instead. If -3 is returned a required argument is
+missing and an error is indicated. If 0 is returned some other error occurred
+and this can be reported back to the user.
 
 The function SSL_CONF_CTX_cmd_value_type() can be used by applications to 
 check for the existence of a command or to perform additional syntax
diff --git a/doc/ssl/SSL_CONF_CTX_set1_prefix.pod b/doc/ssl/SSL_CONF_CTX_set1_prefix.pod
index cdd952e..2e9c728 100644
--- a/doc/ssl/SSL_CONF_CTX_set1_prefix.pod
+++ b/doc/ssl/SSL_CONF_CTX_set1_prefix.pod
@@ -17,7 +17,7 @@ to B. If B is B it is restored to the default value.
 
 =head1 NOTES
 
-Command prefixes alter the commands recognised by subsequent SSL_CTX_cmd()
+Command prefixes alter the commands recognised by subsequent SSL_CONF_CTX_cmd()
 calls. For example for files, if the prefix "SSL" is set then command names
 such as "SSLProtocol", "SSLOptions" etc. are recognised instead of "Protocol"
 and "Options". Similarly for command lines if the prefix is "--ssl-" then 
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3624] Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8]

[Steffen Nurpmeso via RT]

Does:

- Fixes a typo in s_client.pod (2x "in the").

- Changes .pod to reflect reality: it is SSL_CONF_CTX_finish(),
  not SSL_CONF_finish().

- While here it seems best to change the remaining SSL_CONF_cmd(),
  SSL_CONF_cmd_argv() and SSL_CONF_cmd_value_type() to have
  a SSL_CONF_CTX_ prefix, too.
  PODs renamed accordingly.

- Adjusts all places where git grep -i matches against the former.

It compiles etc.
It's ugly to have SSL_CONF_CTX_ as a prefix, but isn't it better
to have a unique interface instead of special-treating the _cmd*
stuff?  Would be really nice like that.
- 

--steffen

diff --git a/apps/s_cb.c b/apps/s_cb.c
index f3892f9..7b111fd 100644
--- a/apps/s_cb.c
+++ b/apps/s_cb.c
@@ -1553,7 +1553,7 @@ int args_ssl(char ***pargs, int *pargc, SSL_CONF_CTX *cctx,
 	int rv;
 
 	/* Attempt to run SSL configuration command */
-	rv = SSL_CONF_cmd_argv(cctx, pargc, pargs);
+	rv = SSL_CONF_CTX_cmd_argv(cctx, pargc, pargs);
 	/* If parameter not recognised just return */
 	if (rv == 0)
 		return 0;
@@ -1613,7 +1613,7 @@ int args_ssl_call(SSL_CTX *ctx, BIO *err, SSL_CONF_CTX *cctx,
 			return 0;
 			}
 #endif
-		if (SSL_CONF_cmd(cctx, param, value) <= 0)
+		if (SSL_CONF_CTX_cmd(cctx, param, value) <= 0)
 			{
 			BIO_printf(err, "Error with command: \"%s %s\"\n",
 		param, value ? value : "");
@@ -1627,7 +1627,7 @@ int args_ssl_call(SSL_CTX *ctx, BIO *err, SSL_CONF_CTX *cctx,
 	 */
 	if (!no_ecdhe)
 		{
-		if (SSL_CONF_cmd(cctx, "-named_curve", "P-256") <= 0)
+		if (SSL_CONF_CTX_cmd(cctx, "-named_curve", "P-256") <= 0)
 			{
 			BIO_puts(err, "Error setting EC curve\n");
 			ERR_print_errors(err);
@@ -1637,7 +1637,7 @@ int args_ssl_call(SSL_CTX *ctx, BIO *err, SSL_CONF_CTX *cctx,
 #ifndef OPENSSL_NO_JPAKE
 	if (!no_jpake)
 		{
-		if (SSL_CONF_cmd(cctx, "-cipher", "PSK") <= 0)
+		if (SSL_CONF_CTX_cmd(cctx, "-cipher", "PSK") <= 0)
 			{
 			BIO_puts(err, "Error setting cipher to PSK\n");
 			ERR_print_errors(err);
diff --git a/demos/bio/client-arg.c b/demos/bio/client-arg.c
index cca7a1e..34035f5 100644
--- a/demos/bio/client-arg.c
+++ b/demos/bio/client-arg.c
@@ -25,7 +25,7 @@ int main(int argc, char **argv)
 		{
 		int rv;
 		/* Parse standard arguments */
-		rv = SSL_CONF_cmd_argv(cctx, &nargs, &args);
+		rv = SSL_CONF_CTX_cmd_argv(cctx, &nargs, &args);
 		if (rv == -3)
 			{
 			fprintf(stderr, "Missing argument for %s\n", *args);
diff --git a/demos/bio/client-conf.c b/demos/bio/client-conf.c
index 191615a..aec3c7b 100644
--- a/demos/bio/client-conf.c
+++ b/demos/bio/client-conf.c
@@ -47,7 +47,7 @@ int main(int argc, char **argv)
 	for (i = 0; i < sk_CONF_VALUE_num(sect); i++)
 		{
 		cnf = sk_CONF_VALUE_value(sect, i);
-		rv = SSL_CONF_cmd(cctx, cnf->name, cnf->value);
+		rv = SSL_CONF_CTX_cmd(cctx, cnf->name, cnf->value);
 		if (rv > 0)
 			continue;
 		if (rv != -2)
diff --git a/demos/bio/server-arg.c b/demos/bio/server-arg.c
index 0d432a4..6ba5cc4 100644
--- a/demos/bio/server-arg.c
+++ b/demos/bio/server-arg.c
@@ -41,7 +41,7 @@ int main(int argc, char *argv[])
 		{
 		int rv;
 		/* Parse standard arguments */
-		rv = SSL_CONF_cmd_argv(cctx, &nargs, &args);
+		rv = SSL_CONF_CTX_cmd_argv(cctx, &nargs, &args);
 		if (rv == -3)
 			{
 			fprintf(stderr, "Missing argument for %s\n", *args);
diff --git a/demos/bio/server-conf.c b/demos/bio/server-conf.c
index 0d940f0..f19b5b8 100644
--- a/demos/bio/server-conf.c
+++ b/demos/bio/server-conf.c
@@ -62,7 +62,7 @@ int main(int argc, char *argv[])
 		{
 		int rv;
 		cnf = sk_CONF_VALUE_value(sect, i);
-		rv = SSL_CONF_cmd(cctx, cnf->name, cnf->value);
+		rv = SSL_CONF_CTX_cmd(cctx, cnf->name, cnf->value);
 		if (rv > 0)
 			continue;
 		if (rv != -2)
diff --git a/doc/apps/s_client.pod b/doc/apps/s_client.pod
index 17308b4..ff61825 100644
--- a/doc/apps/s_client.pod
+++ b/doc/apps/s_client.pod
@@ -90,7 +90,7 @@ SSL servers.
 
 In addition to the options below the B utility also supports the
 common and client only options documented in the
-in the L
+L
 manual page.
 
 =over 4
diff --git a/doc/apps/s_server.pod b/doc/apps/s_server.pod
index 1cc965f..616de1d 100644
--- a/doc/apps/s_server.pod
+++ b/doc/apps/s_server.pod
@@ -98,8 +98,8 @@ for connections on a given port using SSL/TLS.
 
 In addition to the options below the B utility also supports the
 common and server only options documented in the
-L manual
-page.
+L
+manual page.
 
 =over 4
 
diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod
new file mode 100644
index 000..ccc3dd5
--- /dev/null
+++ b/doc/ssl/SSL_CONF_CTX_cmd.pod
@@ -0,0 +1,442 @@
+=pod
+
+=head1 NAME
+
+SSL_CONF_CTX_cmd - send configuration command
+
+=head1 SYNOPSIS
+
+ #include 
+
+ int SSL_CONF_CTX_cmd(SSL_CONF_CTX *cctx, const char *cmd, const char *value);
+ int SSL_CONF_CTX_cmd_value_type(SSL_CONF_CTX *cctx, const char *cmd);
+ int SSL_CONF_CTX_finish(SSL_CONF_CTX *cctx);
+
+=head1 DESCRIPTION
+
+The function SSL_CONF_CTX_cmd() performs configuration operation B with
+optional parameter B on B. Its pu

Re: [openssl-dev] [openssl.org #3623] faulting module ssleay32.dll, version 0.0.0.0, fault address 0x00010c8b.

[Vijendra Boopathy via RT]

Hi,

The exact error which i faced in Event log are given below.

Faulting application name: aeagent.exe, version:0.0.0.0, time
stamp:0x53e1f20f
Faulting module name: SSLEAY32.dll, version:0.0.0.0, time stamp: 0x405a2628
Exception code: 0xc005
Fault offset: 0x00010c8b
Faulting process id : 0x1bc0

What is that mean??
I googled with this error,
firefox faced the same error and they gave workaround was replace the
latest version of dll.
I did the same but no use..

Please tell what i want to do??


On 5 December 2014 at 22:01, Andy Polyakov via RT  wrote:

> > Am using openssl for my monitoring tools and i have facing *faulting
> module
> > ssleay32.dll, version 0.0.0.0, fault address 0x00010c8b *in  application
> > log and its all type of windows OS
> > May i know that it is known issue or new issue,if it is known issue
> please
> > provide issue id.
> >
> > Kindly help ASP...
> >
> > Note : am using latest openssl (openssl-1.0.1j.tar.gz
> > )
>
> Specific fault address does not provide sufficient information by itself
> and it's impossible to tell anything from it. You refer to source code,
> and if you compile it yourself, you'll have symbol information as .pdb
> files that you can use to identify failing function. You should be able
> to use it together with crash dump information in debugger to identify
> failing function and collect so called stack back-trace. Only then it
> would be possible to make some assessment about nature of the problem.
> [As for "crash dump", I don't think meaningful crash dump generation is
> enabled by default nowadays, i.e. you would have to configure it, google
> should be your friend].
>
>
>
>


-- 
Thanks & Regards
vijendra boopathy.k

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3181] [PATCH] OCB

[Matt Caswell via RT]

OCB support has been merged in. Closing my own ticket.

Matt

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev