Re: BIO_flush Segmentation Fault Issue

[Jay Foster]

Thanks.  I wrote some simple tests to exercise this and it worked 
correctly.  I was just not seeing how.

Jay

On 10/3/2022 11:26 PM, Tomas Mraz wrote:

Your analysis is correct. However the library is still correct in
regards to refcounting even for an SSL BIO in the chain. The reason is
that the decrement of refcount of the BIOs underlying the SSL BIO is
handled through the actual freeing of the SSL BIO. If the refcount for
the SSL BIO in the chain freed by BIO_free_all() drops to zero, it
will, in ssl_free() call in bio_ssl.c, free the underlying SSL *
object. And if the refcount of that SSL object drops to zero it will
call BIO_free_all() on the underlying wbio and rbio. Which means also
the chained BIOs underlying the SSL BIO will have their refcount
dropped and they will be properly freed.

Tomas Mraz, OpenSSL

On Mon, 2022-10-03 at 09:35 -0700, Jay Foster wrote:

Your response makes sense.  I am a bit puzzled by the BIO reference
counting.  For example

  BIO_new() (or BIO_new_socket() which calls BIO_new()) produces a
BIO with a reference count of 1.
  BIO_free() drops 1 reference and if the reference count is 0,
frees
the BIO.

  BIO_push() connects the BIO to the BIO chain.  No references are
directly changed.  However, the BIO_CTRL_PUSH command is sent to the
BIO.  For the SSL BIO, this results in a call to SSL_set_bio() and
adding 1 to the next_bio reference (socket BIO).
  BIO_pop() calls BIO_CTRL_POP and disconnects the BIO from the
BIO
chain.  For the SSL BIO, the BIO_CTRL_POP subtracts one from the
next_bio reference (undoing BIO_push()).

  The problem case is calling BIO_free_all() on the BIO chain.
BIO_free_all() does not use BIO_pop().  It simply detaches each BIO
from
the chain, and calls BIO_free() for it.  If the next_bio reference
count
is > 1 (which it will be for the SSL BIO next_bio), it stops
unlinking
and freeing BIOs.  This seems asymmetrical with respect to the BIO
reference counting, and leaks the next_bio (socket BIO in this case).

What am I missing here?
Jay


On 9/29/2022 11:50 PM, Tomas Mraz wrote:

The SSL BIO should have the rbio from the SSL object as the next
BIO.
If you create the SSL BIO and then BIO_push() the TCP socket BIO
into
the SSL BIO, it will work correctly.

Otherwise, you can just fix the next BIO of the SSL BIO by using

BIO_up_ref(socketbio);
BIO_set_next(sslbio, socketbio);

The SSL BIO should always have a next BIO if properly initialized.

Tomas Mraz, OpenSSL

On Thu, 2022-09-29 at 13:02 -0700, Jay Foster wrote:

I have an application that constructs a chain of BIOs.  Sometimes
this
chain also includes an SSL BIO.  Years ago, I ran into a problem
that
caused BIO_flush() to segfault on the SSL BIO.  This turned out
to
happen because the SSL BIO is added using SSL_set_bio() instead
of
BIO_push().  SSL_set_bio() results in the SSL BIO always having a
NULL
bio_next value, so BIO_flush then crashes dereferencing this NULL
pointer when it calls BIO_copy_next_retry() on the SSL BIO (see
BIO_CTRL_FLUSH in ssl/bio_ssl.c).

This was reported as ticket 2615 years ago.

My question is, how could calling BIO_flush() on a BIO chain with
an
SSL
BIO ever work?  Is there a way to add the SSL BIO using
BIO_push()
instead of SSL_set_bio()?

Jay

Re: BIO_flush Segmentation Fault Issue

[Jay Foster]

Your response makes sense.  I am a bit puzzled by the BIO reference 
counting.  For example


    BIO_new() (or BIO_new_socket() which calls BIO_new()) produces a 
BIO with a reference count of 1.
    BIO_free() drops 1 reference and if the reference count is 0, frees 
the BIO.


    BIO_push() connects the BIO to the BIO chain.  No references are 
directly changed.  However, the BIO_CTRL_PUSH command is sent to the 
BIO.  For the SSL BIO, this results in a call to SSL_set_bio() and 
adding 1 to the next_bio reference (socket BIO).
    BIO_pop() calls BIO_CTRL_POP and disconnects the BIO from the BIO 
chain.  For the SSL BIO, the BIO_CTRL_POP subtracts one from the 
next_bio reference (undoing BIO_push()).


    The problem case is calling BIO_free_all() on the BIO chain. 
BIO_free_all() does not use BIO_pop().  It simply detaches each BIO from 
the chain, and calls BIO_free() for it.  If the next_bio reference count 
is > 1 (which it will be for the SSL BIO next_bio), it stops unlinking 
and freeing BIOs.  This seems asymmetrical with respect to the BIO 
reference counting, and leaks the next_bio (socket BIO in this case).


What am I missing here?
Jay


On 9/29/2022 11:50 PM, Tomas Mraz wrote:

The SSL BIO should have the rbio from the SSL object as the next BIO.
If you create the SSL BIO and then BIO_push() the TCP socket BIO into
the SSL BIO, it will work correctly.

Otherwise, you can just fix the next BIO of the SSL BIO by using

BIO_up_ref(socketbio);
BIO_set_next(sslbio, socketbio);

The SSL BIO should always have a next BIO if properly initialized.

Tomas Mraz, OpenSSL

On Thu, 2022-09-29 at 13:02 -0700, Jay Foster wrote:

I have an application that constructs a chain of BIOs.  Sometimes
this
chain also includes an SSL BIO.  Years ago, I ran into a problem that
caused BIO_flush() to segfault on the SSL BIO.  This turned out to
happen because the SSL BIO is added using SSL_set_bio() instead of
BIO_push().  SSL_set_bio() results in the SSL BIO always having a
NULL
bio_next value, so BIO_flush then crashes dereferencing this NULL
pointer when it calls BIO_copy_next_retry() on the SSL BIO (see
BIO_CTRL_FLUSH in ssl/bio_ssl.c).

This was reported as ticket 2615 years ago.

My question is, how could calling BIO_flush() on a BIO chain with an
SSL
BIO ever work?  Is there a way to add the SSL BIO using BIO_push()
instead of SSL_set_bio()?

Jay

BIO_flush Segmentation Fault Issue

[Jay Foster]

I have an application that constructs a chain of BIOs.  Sometimes this 
chain also includes an SSL BIO.  Years ago, I ran into a problem that 
caused BIO_flush() to segfault on the SSL BIO.  This turned out to 
happen because the SSL BIO is added using SSL_set_bio() instead of 
BIO_push().  SSL_set_bio() results in the SSL BIO always having a NULL 
bio_next value, so BIO_flush then crashes dereferencing this NULL 
pointer when it calls BIO_copy_next_retry() on the SSL BIO (see 
BIO_CTRL_FLUSH in ssl/bio_ssl.c).


This was reported as ticket 2615 years ago.

My question is, how could calling BIO_flush() on a BIO chain with an SSL 
BIO ever work?  Is there a way to add the SSL BIO using BIO_push() 
instead of SSL_set_bio()?


Jay

Build Error with 1.1.1p and 3.0.4

[Jay Foster]

I am trying to build the 1.1.1p and 3.0.4 versions of OpenSSL.  Each 
version now fails in the same place (test/v3ext.c).  The error is about 
undefined ASIdentifiers, etc. in the newly added test_asid() function. 
It looks like the newly added test_asid() function needs an  '#ifndef 
OPENSSL_NO_RFC3779' conditional around it.   The undefined types are 
defined within a '#ifndef OPENSSL_NO_RFC3779' conditional, so any 
application using them must also be.


Jay

Re: OpenSSL SSL_CTX_set_default_verify_paths Slow

[Jay Foster]

On 9/27/21 7:33 AM, Michael Richardson wrote:

Jay Foster  wrote:
 > While migrating some applications from OpenSSL 1.0.2 (and 1.1.1) to
 > 3.0.0, I have noticed that the SSL_CTX_set_default_verify_paths()
 > function is much slower in 3.0.0.  In 1.0.0 it would take about 0.1
 > seconds and in 3.0.0 it takes over 3 seconds.

Based upon your straces, the time is spend in the OS.
Are you running this on the same system?

Exact same machine.

That's still very slow... I wonder if you have a failing disk.


I don't think so.  The file system is a UBIFS on nand flash, and it 
works with 1.0.2 and 1.1.1.  Even 1.1.1 is a *little* bit slower than 
1.0.2, but nowhere near as much slower as 3.0.0.


It looks like the OpenSSL library is reading the cert.pem file in 4KB 
blocks at a time and doing some processing on the data read. It appears 
that this processing is what is taking longer.





--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

OpenSSL SSL_CTX_set_default_verify_paths Slow

[Jay Foster]

While migrating some applications from OpenSSL 1.0.2 (and 1.1.1) to 
3.0.0, I have noticed that the SSL_CTX_set_default_verify_paths() 
function is much slower in 3.0.0.  In 1.0.0 it would take about 0.1 
seconds and in 3.0.0 it takes over 3 seconds.


strace indicates that the extra time is during the actual reading of the 
cert.pem file.


OpenSSL 1.0.2u:
1583  17:41:43.233288 getuid32()    = 0
1583  17:41:43.234439 geteuid32()   = 0
1583  17:41:43.235379 getgid32()    = 0
1583  17:41:43.236314 getegid32()   = 0
1583  17:41:43.237285 open("/usr/local/ssl/cert.pem", 
O_RDONLY|O_LARGEFILE) = 4
1583  17:41:43.238790 fstat64(4, {st_mode=S_IFREG|0666, st_size=79902, 
...}) = 0
1583  17:41:43.241239 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f38000
1583  17:41:43.242257 read(4, "# Version: 1.51\n-BEGIN CERTI"..., 
4096) = 4096
1583  17:41:43.244713 read(4, "NXozS7Gas44XRrIsQxzgHVGzbjHjhMM5"..., 
4096) = 4096
1583  17:41:43.249735 read(4, "hT37ha88HQfqDjrw43bAuEbFrskLMmrz"..., 
4096) = 4096
1583  17:41:43.258402 read(4, "vT0Lwdd8KkMaOIG+YD/is\nI19wKTakyY"..., 
4096) = 4096
1583  17:41:43.266628 read(4, "QQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ"..., 
4096) = 4096
1583  17:41:43.272394 read(4, "hG5QbutC+5yqHLkP88Oe\nLe3hwcyV07e"..., 
4096) = 4096
1583  17:41:43.280053 read(4, "wA3ekEzeOEz4vMQGn+H\nLL729fdC4uW/"..., 
4096) = 4096
1583  17:41:43.286542 read(4, "M48vCR85mLK4b19p71XZQvk/iXttmkQ3"..., 
4096) = 4096
1583  17:41:43.291246 read(4, "HdWdAgMBAAGjQjBA\nMA8GA1UdEwEB/wQ"..., 
4096) = 4096
1583  17:41:43.297614 read(4, "Lpyo7RJlbmr2EkRT\ncDCVw5wrWCs9CHR"..., 
4096) = 4096
1583  17:41:43.303533 read(4, "9IVVO5EFdkKrqeKM+2x\nLXY2JtwE65/3"..., 
4096) = 4096
1583  17:41:43.310932 read(4, "F8R+GuqSVzRmZTRouNjWwl2tVZi4Ut0\n"..., 
4096) = 4096
1583  17:41:43.316617 read(4, "WRJ2p\nmj6q1WZmAT7qSeaiNbz69t2Vjp"..., 
4096) = 4096
1583  17:41:43.322393 read(4, "R5B3LjiKY0QP6x93SGVvdh2azrsw\n/FQ"..., 
4096) = 4096
1583  17:41:43.329364 read(4, "TE1MDYzMDAwMDAwMFoXDTI1MDYyOTIzN"..., 
4096) = 4096
1583  17:41:43.334562 read(4, "oXkJKtv3\nL7IezMdeatiDh6GX70k1Pnc"..., 
4096) = 4096
1583  17:41:43.341086 read(4, "CAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1e"..., 
4096) = 4096
1583  17:41:43.347563 read(4, "gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHk"..., 
4096) = 4096
1583  17:41:43.352496 read(4, "wQFMAMB\nAf8wDgYDVR0PAQH/BAQDAgGG"..., 
4096) = 4096
1583  17:41:43.359379 read(4, "Mk7BPZ7hm/ELNKjD+Jo2FR3qyH\nB5T0Y"..., 
4096) = 2078

1583  17:41:43.363656 read(4, "", 4096) = 0
1583  17:41:43.364918 close(4)  = 0
1583  17:41:43.365884 munmap(0xb6f38000, 4096) = 0
1583  17:41:43.371532 getuid32()    = 0
1583  17:41:43.372463 geteuid32()   = 0
1583  17:41:43.373396 getgid32()    = 0
1583  17:41:43.374531 getegid32()   = 0
1583  17:41:43.375540 timer_delete(0x1) = 0

OpenSSL 3.0.0:
1580  17:19:03.601282 getuid32()    = 0
1580  17:19:03.602289 geteuid32()   = 0
1580  17:19:03.603231 getgid32()    = 0
1580  17:19:03.604166 getegid32()   = 0
1580  17:19:03.605141 open("/usr/lib/ssl-3/cert.pem", 
O_RDONLY|O_LARGEFILE) = 4
1580  17:19:03.606731 fstat64(4, {st_mode=S_IFREG|0666, st_size=79902, 
...}) = 0
1580  17:19:03.609420 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ff1000
1580  17:19:03.610449 read(4, "# Version: 1.51\n-BEGIN CERTI"..., 
4096) = 4096
1580  17:19:03.612808 read(4, "NXozS7Gas44XRrIsQxzgHVGzbjHjhMM5"..., 
4096) = 4096
1580  17:19:03.713691 read(4, "hT37ha88HQfqDjrw43bAuEbFrskLMmrz"..., 
4096) = 4096
1580  17:19:03.906236 read(4, "vT0Lwdd8KkMaOIG+YD/is\nI19wKTakyY"..., 
4096) = 4096
1580  17:19:04.098848 read(4, "QQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ"..., 
4096) = 4096
1580  17:19:04.197974 read(4, "hG5QbutC+5yqHLkP88Oe\nLe3hwcyV07e"..., 
4096) = 4096
1580  17:19:04.344133 read(4, "wA3ekEzeOEz4vMQGn+H\nLL729fdC4uW/"..., 
4096) = 4096
1580  17:19:04.490050 read(4, "M48vCR85mLK4b19p71XZQvk/iXttmkQ3"..., 
4096) = 4096
1580  17:19:04.589137 read(4, "HdWdAgMBAAGjQjBA\nMA8GA1UdEwEB/wQ"..., 
4096) = 4096
1580  17:19:04.736698 read(4, "Lpyo7RJlbmr2EkRT\ncDCVw5wrWCs9CHR"..., 
4096) = 4096
1580  17:19:04.836338 read(4, "9IVVO5EFdkKrqeKM+2x\nLXY2JtwE65/3"..., 
4096) = 4096
1580  17:19:04.985568 read(4, "F8R+GuqSVzRmZTRouNjWwl2tVZi4Ut0\n"..., 
4096) = 4096
1580  17:19:05.087120 read(4, "WRJ2p\nmj6q1WZmAT7qSeaiNbz69t2Vjp"..., 
4096) = 4096
1580  17:19:05.189130 read(4, "R5B3LjiKY0QP6x93SGVvdh2azrsw\n/FQ"..., 
4096) = 4096
1580  17:19:05.343106 read(4, "TE1MDYzMDAwMDAwMFoXDTI1MDYyOTIzN"..., 
4096) = 4096
1580  17:19:05.441340 read(4, "oXkJKtv3\nL7IezMdeatiDh6GX70k1Pnc"..., 
4096) = 4096
1580  17:19:05.588597 read(4, "CAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1e"..., 
4096) = 4096
1580  17:19:05.736050 read(4, "gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHk"..., 
4096) = 4096
1580  17:19:05.896427 read(4, "wQFMAMB\nAf8wDgYDVR0PAQH/BAQDAgGG"..., 
4096) = 4096
1580  17:19:06.277284 read(4, "Mk7BPZ7hm/ELNKjD+Jo2FR3qyH\nB5T0Y"..., 
4096) = 2078

1580  17:19:06.473

Re: Performance Issue With OpenSSL 1.1.1c

[Jay Foster]

On 5/28/2019 10:39 AM, Jay Foster wrote:
I built OpenSSL 1.1.1c from the recent release, but have noticed what 
seems like a significant performance drop compared with 1.1.1b.  I 
notice this when starting lighttpd.  With 1.1.1b, lighttpd starts in a 
few seconds, but with 1.1.1c, it takes several minutes.


I also noticed that with 1.1.1b, the CFLAGS automatically included 
'-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the 
CFLAGS.  was this dropped?  I  added '-Wall -O3' to the CFLAGS, but 
this did not seem to have any affect on the performance issue 
(unrelated?).


This is for a 32-bit ARM build.

Jay

I think I have tracked down the change in 1.1.1c that is causing this.  
It is the addition of the DEVRANDOM_WAIT functionality for linux in 
e_os.h and crypto/rand/rand_unix.c.  lighttpd (libcrypto) is waiting in 
a select() call on /dev/random.  After this eventually wakes up, it then 
reads from /dev/urandom.  OpenSSL 1.1.1b did not do this, but instead 
just read from /dev/urandom.  Is there more information about this 
change (i.e., a rationale)?  I did not see anything in the CHANGES file 
about it.


Jay

Performance Issue With OpenSSL 1.1.1c

[Jay Foster]

I built OpenSSL 1.1.1c from the recent release, but have noticed what 
seems like a significant performance drop compared with 1.1.1b.  I 
notice this when starting lighttpd.  With 1.1.1b, lighttpd starts in a 
few seconds, but with 1.1.1c, it takes several minutes.


I also noticed that with 1.1.1b, the CFLAGS automatically included 
'-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the 
CFLAGS.  was this dropped?  I  added '-Wall -O3' to the CFLAGS, but this 
did not seem to have any affect on the performance issue (unrelated?).


This is for a 32-bit ARM build.

Jay

[openssl-users] OpenSSL 1.1.1 Compiler Warnings

[Jay Foster]

With the recent release of OpenSSL 1.1.1, I tried to cross compile it 
for a 32-bit ARM architecture.  I observe many compiler warnings similar 
to the following:


crypto/ec/curve448/curve448.c:30: warning: integer constant is too large 
for 'long' type
crypto/ec/curve448/curve448.c:30: warning: integer constant is too large 
for 'long' type
crypto/ec/curve448/curve448.c:30: warning: integer constant is too large 
for 'long' type
crypto/ec/curve448/curve448.c:30: warning: integer constant is too large 
for 'long' type


crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is 
too large for 'long' type
crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is 
too large for 'long' type
crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is 
too large for 'long' type
crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is 
too large for 'long' type
crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is 
too large for 'long' type
crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is 
too large for 'long' type
crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is 
too large for 'long' type
crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is 
too large for 'long' type


crypto/ec/curve448/f_generic.c:15: warning: integer constant is too 
large for 'long' type
crypto/ec/curve448/f_generic.c:15: warning: integer constant is too 
large for 'long' type
crypto/ec/curve448/f_generic.c:15: warning: integer constant is too 
large for 'long' type
crypto/ec/curve448/f_generic.c:15: warning: integer constant is too 
large for 'long' type
crypto/ec/curve448/f_generic.c:15: warning: integer constant is too 
large for 'long' type


crypto/ec/curve448/scalar.c:17: warning: integer constant is too large 
for 'long' type
crypto/ec/curve448/scalar.c:21: warning: integer constant is too large 
for 'long' type
crypto/ec/curve448/scalar.c:21: warning: integer constant is too large 
for 'long' type
crypto/ec/curve448/scalar.c:21: warning: integer constant is too large 
for 'long' type


There were many many more of these, which I omitted for brevity.  I 
looked at the source and it does look like the code is trying to stuff a 
64-bit constant into a 32-bit variable.  Does OpenSSL-1.1.1 work on 
32-bit architectures?


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

Re: [openssl-users] Using Openssl for eCOS platform

[Jay Foster]

I have used the following snippet (along with some others) in the e_os.h 
header file:


   # if defined(__ECOS)
   #  define __INITIAL_POINTER_SIZE 0
   #  define GETPID_IS_MEANINGLESS
   #  define NO_CHMOD
   #  define NO_SYSLOG
   #  define HAVE_LONG_LONG 1
   #  define HAVE_LONG_DOUBLE 1
   #  define OPENSSL_THREADS
   #  undef DEVRANDOM_EGD
   # endif

The GETPID_IS_MEANINGLESS might work for you.

Jay

On 8/17/2016 2:55 AM, Devadas kk wrote:

Hi,
 Best way to do is to modify e_os.h header file.
 This file has to do with OS specific changes.

 Something like

 #ifdef ECOS
  #define getpid ecos_task_id_fn
#endif

 ecos_task_id_fn is a placed holder, find out actual function name to 
get process ID.

 GetThreadID is the function in NETWARE.
Regards,
Devadas

On Wed, Aug 17, 2016 at 10:28 AM, ssk1506 > wrote:


Hi, I am using openssl on a n eCOS platform. I need only the
secure authentication (no encryption needed). I integrated the
openssl source code with my application. When I trying to build, I
am getting some linking errors. :undefined reference to 'getpid'
:undefined reference to 'RANDpoll' I am trying to find how to
enable or disable the macros (switches to enable or disable a
feature/service). But it seems that openssl.conf is generated from
some utitlity program and from a file opensslconf.h.in
 Pl. anyone suggest how to configure.
Regards, SSK

View this message in context: Using Openssl for eCOS platform


Sent from the OpenSSL - User mailing list archive
 at
Nabble.com.

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







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

Re: [openssl-users] openssl des-ede3-cbc does not match with Java one

[Jay Foster]

It is very likely that your text file also contains a newline at the 
end, so getting the same result as with the echo command would be 
expected.  If it is indeed the newline that is making the difference, 
you could try using the echo command with the '-n' option to suppress it.


Jay

On 11/24/2015 9:12 AM, David García wrote:

Sorry, still not getting the same result, now with the command:

echo 005863330 | openssl enc -e -des-ede3-cbc -K 
'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv  
-nosalt | openssl enc -base64


I get:

H6cr2yN8oWXn2RxiDqnXLg==

but I should get:

H6cr2yN8oWUVY3a6/Vaaow==


BTW I get the same result if the text in the echo is between '' or is 
read from a text file.


2015-11-24 18:07 GMT+01:00 David García >:


You are right Viktor, that was my problem.

Thank you very much for your help Viktor and Michael.

2015-11-24 18:00 GMT+01:00 Viktor Dukhovni
mailto:openssl-us...@dukhovni.org>>:

On Tue, Nov 24, 2015 at 05:55:42PM +0100, David García wrote:

> openssl enc -e -des-ede3-cbc -in myfile.txt -k
> 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv
 -nosalt |
> openssl enc -base64

Please read Michael's message carefully. Note the comment about
"-k" vs. "-K" (upper-case).

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




-- 
David





--
David


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


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

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Jay Foster]

On 11/17/2015 9:56 AM, Jeffrey Walton wrote:

We can significantly reduce that liability by removing any assembler
optimisations. Also just because something is available doesn't mean it
has to be "default". We can have good defaults whilst keeping old crypto.

Zooko Wilcox O'Hearn recently gave a talk at a software assurance
conference on the downsides of assembly language routines in software.
I'm trying to locate it now. All in all, this is probably a move in
the right direction, especially for non-contemporary algorithms, to
help sunset them and maintain them with minimal effort.

My bad... I just talked to Zooko about the presentation. He was not
able to attend the conference, so there is no presentation to link to.

However, here is the write-up in the Tahoe-LAFS Bug Reporter:
https://tahoe-lafs.org/trac/pycryptopp/ticket/85#comment:20. It makes
the case for No-ASM. (And was the corpus of knowledge for the
presentation).

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

I can understand the desire to remove the assembly code options, but I 
think there are legitimate reasons to leave them in.  From the write-up 
referenced (above), "because the added speed really makes no difference 
to our uses, as far as I know" was a reason given for removing 
assembly.  I think this is based on some assumptions that are not 
universally true, such as OpenSSL is running on multi-GHz multi-core 
64-bit processors.  This is not always the case.  I recently updated a 
product I support (50MHz single core) to OpenSSL 1.0.2d, and found that 
the assembly optimizations gave me a 40% increase in performance over 
the C version (AES decryption).  40% was very significant in my case.  
Seems like the low power IoT devices might be similarly CPU challenged 
in the future.


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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 2:09 PM, Jay Foster wrote:

On 6/19/2015 1:11 PM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
Behalf

Of Jay Foster
Sent: Friday, June 19, 2015 15:51
I got my application to compile and link.  It seemed to run OK, but 
when

I tried to run it on a different Windows machine, it failed with a pop
up dialog complaining it could not find LIBEAY32.dll.  I 'thought' I 
was
statically linking this library, but apparently not.  I have no idea 
how

it worked on the one machine.  What is the magic incantation to get
Visual Studio to statically link the OpenSSL libraries?

The OpenSSL libraries have to be built as static libraries.

If you configure the OpenSSL build for static libraries, that's what 
you'll get.


If you configure it for dynamic libraries, you'll get libeay32.dll 
and ssleay32.dll, and a pair of "import libraries" named libeay32.lib 
and ssleay32.lib. You won't get static libraries at all. Note the 
static libraries and the import libraries have the same name.


When you link a library to a Windows executable, you provide either a 
static library or an import library. In the latter case, the 
executable will do an implicit load of the corresponding DLL at startup.


So if you want to statically link with OpenSSL, you have to configure 
it for static linkage and build it that way. Then the libeay32.lib 
and ssleay32.lib you get should be true static libraries and not 
import libraries.


I think "no-shared" is the Configure option you need. We actually 
have a script that changes some of the OpenSSL makefiles after 
configuring, so our process is a bit different from yours.


That sounds like what I'm running into.  I rebuilt the OpenSSL 
libraries with the "no-shared" option, but this made no difference. 
Does that work for Windows?

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


I see OpenSSL build output that looks like this:

cl /Fotmp32dll\a_sign.obj  -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 
-DOPENSSL
_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 
-DWIN32_L
EAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK 
-I. -DO
PENSSL_NO_IDEA -DOPENSSL_NO_RC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 
-DOPENSSL_NO_S
SL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE 
-DOPENSSL_NO_STATIC_E
NGINE /Zi /Fdtmp32dll/lib -D_WINDLL  -DOPENSSL_BUILD_SHLIBCRYPTO -c 
.\crypto\asn

1\a_sign.c
a_sign.c

Should the "/MD" be "/MT"?
Is -DOPENSSL_BUILD_SHLIBCRYPTO right?
is -D_WINDLL right?

Do I need to specify enable-static-engine or no-dso?
Jay
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 1:11 PM, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 15:51
I got my application to compile and link.  It seemed to run OK, but when
I tried to run it on a different Windows machine, it failed with a pop
up dialog complaining it could not find LIBEAY32.dll.  I 'thought' I was
statically linking this library, but apparently not.  I have no idea how
it worked on the one machine.  What is the magic incantation to get
Visual Studio to statically link the OpenSSL libraries?

The OpenSSL libraries have to be built as static libraries.

If you configure the OpenSSL build for static libraries, that's what you'll get.

If you configure it for dynamic libraries, you'll get libeay32.dll and ssleay32.dll, and 
a pair of "import libraries" named libeay32.lib and ssleay32.lib. You won't get 
static libraries at all. Note the static libraries and the import libraries have the same 
name.

When you link a library to a Windows executable, you provide either a static 
library or an import library. In the latter case, the executable will do an 
implicit load of the corresponding DLL at startup.

So if you want to statically link with OpenSSL, you have to configure it for 
static linkage and build it that way. Then the libeay32.lib and ssleay32.lib 
you get should be true static libraries and not import libraries.

I think "no-shared" is the Configure option you need. We actually have a script 
that changes some of the OpenSSL makefiles after configuring, so our process is a bit 
different from yours.

That sounds like what I'm running into.  I rebuilt the OpenSSL libraries 
with the "no-shared" option, but this made no difference. Does that work 
for Windows?

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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 10:52 AM, Jay Foster wrote:

On 6/19/2015 8:55 AM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
Behalf

Of Jay Foster
Sent: Friday, June 19, 2015 11:49
I started over from a clean directory and the build completed.  On
linux, I would end up with two libraries (libssl, libcrypto). I don't
see these on Windows in the out32dll directory.  Does Windows create
different library names?  I'm looking for the equivalent static
libraries for libssl and libcrypto to link with my application.
The Windows static libraries are named libeay32.lib and ssleay32.lib, 
for historical reasons. At any rate, that's what I have in my Windows 
build directory; I believe those are the standard names.



Thanks, I see those.

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

I got my application to compile and link.  It seemed to run OK, but when 
I tried to run it on a different Windows machine, it failed with a pop 
up dialog complaining it could not find LIBEAY32.dll.  I 'thought' I was 
statically linking this library, but apparently not.  I have no idea how 
it worked on the one machine.  What is the magic incantation to get 
Visual Studio to statically link the OpenSSL libraries?


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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 8:55 AM, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 11:49
I started over from a clean directory and the build completed.  On
linux, I would end up with two libraries (libssl, libcrypto).  I don't
see these on Windows in the out32dll directory.  Does Windows create
different library names?  I'm looking for the equivalent static
libraries for libssl and libcrypto to link with my application.

The Windows static libraries are named libeay32.lib and ssleay32.lib, for 
historical reasons. At any rate, that's what I have in my Windows build 
directory; I believe those are the standard names.


Thanks, I see those.

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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/19/2015 8:30 AM, Jay Foster wrote:

On 6/18/2015 7:55 PM, Thomas J. Hruska wrote:

On 6/18/2015 4:46 PM, Jay Foster wrote:

I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL
1.0.2c for Windows, but get a linking error

tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86'
conflicts with target machine type 'x64'

I googled for this error, but the solutions mention changing parameters
in the VC Studio project, but I'm building from the command line with
nmake.

I'm configuring for 32-bit (perl Configure VC-WIN32 ...).  I think the
Windows system I'm compiling on is a 64-bit OS.  I know I have built
32-bit applications on it in the past from VC Studio.  Is there some
obvious fix?

Jay


What Command Prompt are you running?  You have to use the correct 
"Native Tools" for the target hardware type.  If you are building 
VC-WIN32, then you are targeting 32-bit hardware and need to run the 
x86 Native Tools Command Prompt (not the x64 version).  You can't mix 
and match targets.


If you don't want to build it yourself, there are also prebuilt 
binaries and libraries.


I tried again, but it then failed trying to compile an assembly file 
(i586 something).  It complained about an unknown operand.


I tried again adding "no-asm" to my configuration.  It seemed to 
compile fine, but again failed at the link with several undefined 
symbols:
_OPENSSL_ia32cap_P, _OPENSSL_ia32_cpuid, _md5_block_asm_data_order, 
_sha1_block_data_order, _sha256_block_data_order, and 
_sha512_block_data_order.


My goal is to obtain a static library(ies) and associated header files 
that I can use to compile my application that uses OpenSSL on 
Windows.  Where can I obtain these pre-built binaries?


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

I started over from a clean directory and the build completed.  On 
linux, I would end up with two libraries (libssl, libcrypto).  I don't 
see these on Windows in the out32dll directory.  Does Windows create 
different library names?  I'm looking for the equivalent static 
libraries for libssl and libcrypto to link with my application.


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

Re: [openssl-users] Windows Compile Fails

[Jay Foster]

On 6/18/2015 7:55 PM, Thomas J. Hruska wrote:

On 6/18/2015 4:46 PM, Jay Foster wrote:

I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL
1.0.2c for Windows, but get a linking error

tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86'
conflicts with target machine type 'x64'

I googled for this error, but the solutions mention changing parameters
in the VC Studio project, but I'm building from the command line with
nmake.

I'm configuring for 32-bit (perl Configure VC-WIN32 ...).  I think the
Windows system I'm compiling on is a 64-bit OS.  I know I have built
32-bit applications on it in the past from VC Studio.  Is there some
obvious fix?

Jay


What Command Prompt are you running?  You have to use the correct 
"Native Tools" for the target hardware type.  If you are building 
VC-WIN32, then you are targeting 32-bit hardware and need to run the 
x86 Native Tools Command Prompt (not the x64 version).  You can't mix 
and match targets.


If you don't want to build it yourself, there are also prebuilt 
binaries and libraries.


I tried again, but it then failed trying to compile an assembly file 
(i586 something).  It complained about an unknown operand.


I tried again adding "no-asm" to my configuration.  It seemed to compile 
fine, but again failed at the link with several undefined symbols:
_OPENSSL_ia32cap_P, _OPENSSL_ia32_cpuid, _md5_block_asm_data_order, 
_sha1_block_data_order, _sha256_block_data_order, and 
_sha512_block_data_order.


My goal is to obtain a static library(ies) and associated header files 
that I can use to compile my application that uses OpenSSL on Windows.  
Where can I obtain these pre-built binaries?


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

[openssl-users] Windows Compile Fails

[Jay Foster]

I'm new to building OpenSSL with Windows.  I'm trying to build OpenSSL 
1.0.2c for Windows, but get a linking error


tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86' 
conflicts with target machine type 'x64'


I googled for this error, but the solutions mention changing parameters 
in the VC Studio project, but I'm building from the command line with nmake.


I'm configuring for 32-bit (perl Configure VC-WIN32 ...).  I think the 
Windows system I'm compiling on is a 64-bit OS.  I know I have built 
32-bit applications on it in the past from VC Studio.  Is there some 
obvious fix?


Jay




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

[openssl-users] Truncating A Hash

[Jay Foster]

What is the down side of truncating a hash?  For example, an SHA-256 
hash is 256 bits.  Is it any less secure if one was to drop the last 128 
bits to make a 128 bit hash or take the MD5 hash of the SHA-256 hash to 
get a 128 bit hash?  It does not seem that such an action would make it 
any easier to brute force reverse the hash, but then again, I am clearly 
not a security expert.


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

Re: [openssl-users] 1.0.1 upgrade issue

[Jay Foster]

I'm using gcc 4.3.3 for what it's worth.
Jay
On 2/18/2015 12:53 PM, Mike Collins wrote:

Thanks Jay.

My build script is doing the same.

Not sure where to go next except to update libc to a newer version. 
Due to the toolchain (not created by me) it may be a major undertaking.


Mike

From: Jay Foster <mailto:jayf0s...@roadrunner.com>>

To: openssl-users@openssl.org <mailto:openssl-users@openssl.org>
Cc:
Date: Wed, 18 Feb 2015 10:30:40 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I'm building against libc6 (glibc 2.9) and kernel 3.2.6. Are you 
skipping the 'make depend' step?  My build script does, './Configure 
', 'make depend', 'make'.


Jay

On 2/18/2015 8:03 AM, Mike Collins wrote:

Thanks for the suggestions Jay but am still not having much luck.

Does 1.0.1 have any minimum requirements for the libc version or 
kernel version? I am currently building against libc version 2.5 with 
the kernel at 2.6.30.


Mike

-- Forwarded message --
From: Jay Foster <mailto:jayf0s...@roadrunner.com>>

To: openssl-users@openssl.org <mailto:openssl-users@openssl.org>
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also 
on an ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 
linux-armv4 shared' options (plus some others).  I found that it 
works with and without the ARM assembly accelerations (no-asm 
option), even though the ARM926EJ is an arm5te.  It works fine with 
lighttpd and passes the OpenSSL tests.  I assume you are also using 
the appropriate '--cross-compile-prefix=' option.   You might 
try adding "-mlittle-endian -mcpu=arm926ej-s -DL_ENDIAN" to the 
CFLAGS, although that should be redundant (the compiler should 
already know this).  Also, make sure there are no '-nostdinc' (or 
similar) type compiler options creeping in.  These change the search 
order of header files, which can cause OpenSSL to be built against 
the (old) headers in your tool chain, rather than it's local 
(current) headers.


I did discover that with 1.0.2, I also needed to add 
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version 
-a' command to report a useful build date.


Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:
I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l 
due to a requirement for TLS v1.1. Version 1.0.1 will cross compile 
without errors using my 1.0.0 configuration but I have identified the 
following errors on the board (so far) with the build using 1.0.1:

1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https 
will timeout with PKCS #11 error

3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery 
Lite toolchain. Configure settings (besides --prefix, etc) are 
shared, no-asm, linux-generic32, no-ssl2. All the other packages on 
the board have been rebuilt against the new openssl version.


I am looking at the key creation first since that may be causing the 
other issues. If I try to create a key from the board command line 
using "openssl genrsa -out testkey.pem 2048" I get a response of 
"Generating RSA private key, 2048 bit long modulus". At this point it 
seems to get stuck in a loop; I am seeing the progress indicators 
(".") but it will never finish creating the key. I have let it run 
10-15 minutes without completion; it just keeps displaying successive 
progress indicators. I can do Ctrl-C and it will exit.


I don't think so but are there any dependency changes from 1.0.0 to 
1.0.1?


I noticed 1.0.2 has been released so tried that as well but have the 
same result as 1.0.1


Mike



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


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

Re: [openssl-users] 1.0.1 upgrade issue

[Jay Foster]

I'm building against libc6 (glibc 2.9) and kernel 3.2.6.  Are you 
skipping the 'make depend' step?  My build script does, './Configure 
', 'make depend', 'make'.


Jay

On 2/18/2015 8:03 AM, Mike Collins wrote:

Thanks for the suggestions Jay but am still not having much luck.

Does 1.0.1 have any minimum requirements for the libc version or 
kernel version? I am currently building against libc version 2.5 with 
the kernel at 2.6.30.


Mike

------ Forwarded message --
From: Jay Foster <mailto:jayf0s...@roadrunner.com>>

To: openssl-users@openssl.org <mailto:openssl-users@openssl.org>
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also 
on an ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 
linux-armv4 shared' options (plus some others).  I found that it works 
with and without the ARM assembly accelerations (no-asm option), even 
though the ARM926EJ is an arm5te.  It works fine with lighttpd and 
passes the OpenSSL tests.  I assume you are also using the appropriate 
'--cross-compile-prefix=' option.   You might try adding 
"-mlittle-endian -mcpu=arm926ej-s -DL_ENDIAN" to the CFLAGS, although 
that should be redundant (the compiler should already know this).  
Also, make sure there are no '-nostdinc' (or similar) type compiler 
options creeping in.  These change the search order of header files, 
which can cause OpenSSL to be built against the (old) headers in your 
tool chain, rather than it's local (current) headers.


I did discover that with 1.0.2, I also needed to add 
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version 
-a' command to report a useful build date.


Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:
I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due 
to a requirement for TLS v1.1. Version 1.0.1 will cross compile 
without errors using my 1.0.0 configuration but I have identified the 
following errors on the board (so far) with the build using 1.0.1:

1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https 
will timeout with PKCS #11 error

3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery 
Lite toolchain. Configure settings (besides --prefix, etc) are shared, 
no-asm, linux-generic32, no-ssl2. All the other packages on the board 
have been rebuilt against the new openssl version.


I am looking at the key creation first since that may be causing the 
other issues. If I try to create a key from the board command line 
using "openssl genrsa -out testkey.pem 2048" I get a response of 
"Generating RSA private key, 2048 bit long modulus". At this point it 
seems to get stuck in a loop; I am seeing the progress indicators 
(".") but it will never finish creating the key. I have let it run 
10-15 minutes without completion; it just keeps displaying successive 
progress indicators. I can do Ctrl-C and it will exit.


I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the 
same result as 1.0.1


Mike


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


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

Re: [openssl-users] 1.0.1 upgrade issue

[Jay Foster]

I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on 
an ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4 
shared' options (plus some others).  I found that it works with and 
without the ARM assembly accelerations (no-asm option), even though the 
ARM926EJ is an arm5te.  It works fine with lighttpd and passes the 
OpenSSL tests.  I assume you are also using the appropriate 
'--cross-compile-prefix=' option.   You might try adding 
"-mlittle-endian -mcpu=arm926ej-s -DL_ENDIAN" to the CFLAGS, although 
that should be redundant (the compiler should already know this).  Also, 
make sure there are no '-nostdinc' (or similar) type compiler options 
creeping in.  These change the search order of header files, which can 
cause OpenSSL to be built against the (old) headers in your tool chain, 
rather than it's local (current) headers.


I did discover that with 1.0.2, I also needed to add 
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a' 
command to report a useful build date.


Jay
On 2/13/2015 7:29 AM, Mike Collins wrote:
I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due 
to a requirement for TLS v1.1. Version 1.0.1 will cross compile 
without errors using my 1.0.0 configuration but I have identified the 
following errors on the board (so far) with the build using 1.0.1:

1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https 
will timeout with PKCS #11 error

3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery 
Lite toolchain. Configure settings (besides --prefix, etc) are shared, 
no-asm, linux-generic32, no-ssl2. All the other packages on the board 
have been rebuilt against the new openssl version.


I am looking at the key creation first since that may be causing the 
other issues. If I try to create a key from the board command line 
using "openssl genrsa -out testkey.pem 2048" I get a response of 
"Generating RSA private key, 2048 bit long modulus". At this point it 
seems to get stuck in a loop; I am seeing the progress indicators 
(".") but it will never finish creating the key. I have let it run 
10-15 minutes without completion; it just keeps displaying successive 
progress indicators. I can do Ctrl-C and it will exit.


I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the 
same result as 1.0.1


Mike




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


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

Re: Make depend issue in Openssl-1.0.1j/ssl

[Jay Foster]

I ran into this as well, but fixed it. The issue for me was my build 
environment was for a cross compilation.  It had some extra 
compiler/linker options that caused the  compiler to search the sysroot 
path header files before the ones specified by -I statements.  The 
result was the compiler was using the OpenSSL header files from my tool 
chain instead of the ones in the (latest) source.  The tool chain had 
the previous version installed, so was missing the TLS_MAX_VERSION 
definition.


Normally, -I include directives will get searched first, before 
any normal system search paths.  This will get the correct header files 
from the source tree.  If you do something like '-nostdinc 
-I${SYSROOT}/usr/include -I', then the reverse will happen.  Ref 
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html.


Jay
On 10/30/2014 12:40 PM, Philip Bellino wrote:


Hello,

I am running in the following issue when I do a “make depend (after 
the “./config shared no-ssl3”):


making depend in ssl...

make[3]: Entering directory '.../openssl-1.0.1j/ssl'

s3_lib.c:3370:4: #error Code needs update for SSLv23_method() support 
beyond TLS1_2_VERSION.


d1_lib.c:274:4: #error Code needs update for DTLS_method() support 
beyond DTLS1_VERSION.


make[3]: *** [depend] Error 1

In  ssl/s3_lib.c, there is a new case statement in openssl-1.0.1j:

   case SSL_CTRL_CHECK_PROTO_VERSION:

 /* For library-internal use; checks that the current 
protocol


  * is the highest enabled version (according to

s->ctx->method,

  * as version negotiation may have changed s->method). */

 if (s->version == s->ctx->method->version)

 return 1;

 /* Apparently we're using a version-flexible SSL_METHOD

  * (not at its highest protocol version). */

 if (s->ctx->method->version == SSLv23_method()->version)

 {

#if TLS_MAX_VERSION != TLS1_2_VERSION

#  error Code needs update for SSLv23_method() support beyond 
TLS1_2_VERSION.


#endif

 if (!(s->options & SSL_OP_NO_TLSv1_2))

 return s->version == TLS1_2_VERSION;

 if (!(s->options & SSL_OP_NO_TLSv1_1))

 return s->version == TLS1_1_VERSION;

 if (!(s->options & SSL_OP_NO_TLSv1))

 return s->version == TLS1_VERSION;

 if (!(s->options & SSL_OP_NO_SSLv3))

 return s->version == SSL3_VERSION;

 if (!(s->options & SSL_OP_NO_SSLv2))

 return s->version == SSL2_VERSION;

 }

 return 0; /* Unexpected state; fail closed

--

A grep -ri TLS_MAX_VERSION *

include/openssl/tls1.h:#define TLS_MAX_VERSIONTLS1_2_VERSION

ssl/s23_clnt.c:/* ensure that TLS_MAX_VERSION is up-to-date */

ssl/s23_clnt.c: OPENSSL_assert(s->version <= TLS_MAX_VERSION);

ssl/s3_lib.c:#if TLS_MAX_VERSION != TLS1_2_VERSION

ssl/tls1.h:#define TLS_MAX_VERSIONTLS1_2_VERSION

and a  grep -ri  DTLS_MAX_VERSION  *

include/openssl/dtls1.h:#define DTLS_MAX_VERSIONDTLS1_VERSION

ssl/dtls1.h:#define DTLS_MAX_VERSIONDTLS1_VERSION

ssl/d1_lib.c:#if DTLS_MAX_VERSION != DTLS1_VERSION

ssl/d1_lib.c:return s->version == DTLS_MAX_VERSION;

This leads me to believe that the code should never have the above 
error conditions occur, but in fact it is.


Any help would be most appreciated and I apologize if I am missing 
something in my analysis.


Thanks,

Phil

*Phil Bellino*

*Principal Software Engineer| **MRV Communications Inc.*

300 Apollo Drive *| *Chelmsford, MA 01824

Phone: 978-674-6870*| *Fax: 978-674-6799

www.mrv.com

MRV-email

E-Banner 



The contents of this message, together with any attachments, are 
intended only for the use of the person(s) to whom they are addressed 
and may contain confidential and/or privileged information. If you are 
not the intended recipient, immediately advise the sender, delete this 
message and any attachments and note that any distribution, or copying 
of this message, or any attachment, is prohibited.

Re: openssl SSL3 vulnerability

[Jay Foster]

There seems to be a difference between the SSL (protocol) version and 
the Cipher version/description. You might try the following debug code 
to clarify.


printf("SSL Version: %s\n", SSL_get_version(ssl));
const SSL_CIPHER *ciph = SSL_get_current_cipher(ssl);
if (ciph)
{
printf("Cipher Version : %s\n", SSL_CIPHER_get_version(ciph));
printf("Cipher Name: %s\n", SSL_CIPHER_get_name(ciph));
  }

For example:

SSL Version: TLSv1
Cipher Version : TLSv1/SSLv3
Cipher Name: AES256-SHA

From the SSL_CIPHER_get_name(3) man page:
|SSL_CIPHER_get_version()| returns string which indicates the SSL/TLS 
protocol version that first defined the cipher. This is currently 
*SSLv2* or *TLSv1/SSLv3*. In some cases it should possibly return 
``TLSv1.2'' but does not; use |SSL_CIPHER_description()| instead.


Jay

On 10/24/2014 10:16 AM, mclellan, dave wrote:

The plot thickens, but our mails must be crossing.   I do indeed see TLSV1.2 in 
that message, but if and only if a much more restrictive set of ciphers is 
specified.  That's why I was questioning the appearance of SSLv3 in other 
cases, despite the case that I had set the options to disable SSLv3.

+-+-+-+-+-+-+-+-+-
Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 
South St.
Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749
Office:508-249-1257, FAX: 508-497-8027, Mobile:   978-500-2546, 
dave.mclel...@emc.com
+-+-+-+-+-+-+-+-+-


-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Erik Forsberg
Sent: Friday, October 24, 2014 12:46 PM
To: openssl-users@openssl.org
Subject: Re: openssl SSL3 vulnerability

That triggers my memory. I saw this too a long time ago, if I recall correctly, 
if you get a TLSv1.2 connection, its still logged as SSLv3 (there is lack of 
printable enums in the OpenSSL code. I looked at my negotiation with wireshark 
and saw that I got TLSv1.2 despite what the debug trace said.

I hope this could be fixed one day ?


-- Original Message --

On 24/10/2014 15:53, Pradeep Gudepu wrote:

To my earlier code, I have added these extra flags for client:

SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 |
SSL_OP_NO_SSLv3);

And server also has these same flags set, so that no way client and server can 
communicate on sslv2, sslv3.

But again in logs I see SSL3 is negotiated:

[2014-10-24 18:00:17.063, Info  < proxysrv:10684>] SSLConfig::Init: SSL 
initiated (OpenSSL 1.0.1j 15 Oct 2014 built on: Mon Oct 20 15:08:32 2014).
[2014-10-24 18:02:11.640, Info  < proxysrv:10684>] SSLSocket::Callback: 
Handshake done: AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  
Mac=SHA1

Does this really mean "SSLv3.0 protocol negotiated"?

Or does it just mean "SSLv3.x" (which includes TLSv1.x)?

Or perhaps "SSLv3 compatible cipher suite" (which also includes TLSv1.x)?

On server, I have these ciphers set:

::SSL_CTX_set_cipher_list(ctx,
"ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM");

Is there something wrong with these ciphers? What are best cipher argument for 
only TLSv1 communication. I think, I need not set ciphers on client side.

Thanks – Pradeep reddy.

Enjoy

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



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
:��I"Ϯ��r�m
(���Z+�K�+1���x��h���[�z�(���Z+���f�y������f���h��)z{,��

Re: Compiling OpenSSL 1.0.0o

[Jay Foster]

On 10/15/2014 3:01 PM, Jay Foster wrote:
I downloaded the OpenSSL 1.0.0o source but I am running into a new 
problem when trying to compile it.  The 'make depend' step fails with:


s3_lib.c:2507:4: error: #error Code needs update for SSLv23_method() 
support beyond TLS1_VERSION.
d1_lib.c:273:4: error: #error Code needs update for DTLS_method() 
support beyond DTLS1_VERSION.

make[1]: *** [depend] Error 1

I have tracked this down to makedepend (and probably gcc) are using 
the header files () from the tool chain 
usr/include/openssl directory, rather than the header files from the 
source directory (the tool chain contains the header files from 
1.0.0n).  I confirmed that makedepend is being passed CFLAG=" 
-I../crypto -I.. -I../include", but I suspect that the tool chain 
header file search path is being searched first.


Any suggestions on how to resolve this?

Jay
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org

I have resolved my problem.  There was a --nostdinc option along with 
some -I options to the tool chain include paths, so these were 
getting searched before the -I specified by the OpenSSL source.  
These did not show up on the makedepend output (where it was failing), 
but did on the gcc output when compiling. Ref 
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html.


Jay
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Compiling OpenSSL 1.0.0o

[Jay Foster]

I downloaded the OpenSSL 1.0.0o source but I am running into a new 
problem when trying to compile it.  The 'make depend' step fails with:


s3_lib.c:2507:4: error: #error Code needs update for SSLv23_method() 
support beyond TLS1_VERSION.
d1_lib.c:273:4: error: #error Code needs update for DTLS_method() 
support beyond DTLS1_VERSION.

make[1]: *** [depend] Error 1

I have tracked this down to makedepend (and probably gcc) are using the 
header files () from the tool chain usr/include/openssl 
directory, rather than the header files from the source directory (the 
tool chain contains the header files from 1.0.0n).  I confirmed that 
makedepend is being passed CFLAG=" -I../crypto -I.. -I../include", but I 
suspect that the tool chain header file search path is being searched first.


Any suggestions on how to resolve this?

Jay
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org