Hi,
in the body of the message you just sent us, you find a detailed
description how to unsubscribe:
To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-request@xxxxxxxxxxx
Regards,
Matthias
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx>
On Behalf Of RUBEN BARAINCA
Sent: Monday, January 27, 2020 7:44 PM
To: openssl-users@xxxxxxxxxxx
Subject: Re:openssl-users Digest, Vol 62, Issue 6
Importance: High
-------- Original message --------
From: openssl-users-request@xxxxxxxxxxx
Date: Mon, Jan 27, 2020, 7:20 PM
To: openssl-users@xxxxxxxxxxx
Subject: openssl-users Digest, Vol 62, Issue 6
Send openssl-users mailing list submissions to
openssl-users@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-request@xxxxxxxxxxx
You can reach the person managing the list at
openssl-users-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."
Today's Topics:
1. Thanks for Encoding Clarification (Douglas Morris)
2. What option is not recognized by OpenSSL 1.1.1d? (Jeffrey Walton)
3. Re: What option is not recognized by OpenSSL 1.1.1d?
(Matt Caswell)
4. Determine that there is no forward progress with non blocking
SSL socket (Eran Borovik)
5. Decryption slower in 1.1.1 branch? (Dan Heinz)
----------------------------------------------------------------------
Message: 1
Date: Sun, 26 Jan 2020 04:58:42 +0000 (UTC)
From: Douglas Morris <dougbmorris@xxxxxxxxx>
To: "openssl-users@xxxxxxxxxxx" <openssl-users@xxxxxxxxxxx>
Subject: Thanks for Encoding Clarification
Message-ID: <791238297.11590163.1580014722271@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Viktor,
Thanks for meticulously answering my questions. I know the file name encoding is not necessarily the file content encoding. If a Python program were on a Windows computer, it might show a file name encoding of UTC-16, which would make UTC-16 a good guess for
what openssl <subcommand> -text would output as bytes to be converted (the way what I'm doing works with Python's subprocess module). That was my conjectural thinking and a heuristic I though might be useful. I could get the name of the operating system from
Python and map that to a 'native' encoding I suppose, but that's too much work for dubious gain. I'm not testing on Windows. It is enough to know that there is no easy and obvious way to accommodate -text bytes on various OSes, supposing they would be different.
Maybe there is no difference. I expect think there should be on older WIndows and Apple OSes. Yes, I could be wrong. I'll just go with what I knowledge I have, accept the uncertainty, and concentrate on the OS that I'
m using, which is Linux. I could always extract public key parameters and expiration dates from the OS-consistent PEM form, not that I want to try.
So DER is binary and PEM is ASCII text (which means utf-8 and not utf-16). Going by RFC 1421 via herongyang.com, the MS line breaks are a nice touch. I got the info I need to program something and troubleshoot any encoding problems from -text output bytes that
might arise. I can see that 'openssl req -in <csr> -outform DER' outputs bytes that are not to be changed. I suppose the same is true of -outform PEM. That's good to know because I was 'fixing' the received certificate (in PEM I believe) by normalizing line
breaks to '\n' and then trusting Python's universal newlines mode to write out the big string in a variable to a file with the native OS-line-break encoding. I think I'll just write out the raw bytes as received. Funny, but I ran openssl x509 -text on the
one test/staging certificate I saved to file only hours ago, and with the aforesaid 'normalization', and it displayed correctly. I know that doesn't prove that such treatment for a real certificate will work correctly for t
he Web server when the time comes, but my program is coming along and I know a little more about what's going on.
Thanks.
Douglas Morris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200126/a3e03903/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 26 Jan 2020 16:03:50 -0500
From: Jeffrey Walton <noloader@xxxxxxxxx>
To: OpenSSL Users <openssl-users@xxxxxxxxxxx>
Subject: What option is not recognized by OpenSSL 1.1.1d?
Message-ID:
<CAH8yC8k2s3=OFjOQ=MzNUsJpyJVQmMrg8UrqXbPwVeq9vo-ZDw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d.
Configure is dying:
***** Unsupported options: no-comp
--prefix=/home/jwalton/tmp/build-test
--libdir=/home/jwalton/tmp/build-test/lib
According to INSTALL at
https://github.com/openssl/openssl/blob/master/INSTALL, all the
options are supported.
Which option is not recognized by OpenSSL 1.1.1d?
Thanks in advance.
------------------------------
Message: 3
Date: Mon, 27 Jan 2020 08:40:59 +0000
From: Matt Caswell <matt@xxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: What option is not recognized by OpenSSL 1.1.1d?
Message-ID: <8a3bdb62-5ef6-3fd4-2cb0-108d5b0ebdbb@xxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
On 26/01/2020 21:03, Jeffrey Walton wrote:
> I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d.
>
> Configure is dying:
>
> ***** Unsupported options: no-comp
> --prefix=/home/jwalton/tmp/build-test
> --libdir=/home/jwalton/tmp/build-test/lib
>
> According to INSTALL at
> https://github.com/openssl/openssl/blob/master/INSTALL, all the
> options are supported.
>
> Which option is not recognized by OpenSSL 1.1.1d?
That is strange:
> ***** Unsupported options: no-comp
"no-comp" *is* supported in 1.1.1! E.g
$ perl Configure linux-x86_64 no-comp
Configuring OpenSSL version 1.1.1e-dev (0x10101050L) for linux-x86_64
Using os-specific seed configuration
Creating configdata.pm
Creating Makefile
**********************************************************************
*** ***
*** OpenSSL has been successfully configured ***
*** ***
*** If you encounter a problem while building, please open an ***
*** issue on GitHub <https://github.com/openssl/openssl/issues> ***
*** and include the output from the following command: ***
*** ***
*** perl configdata.pm --dump ***
*** ***
*** (If you are new to OpenSSL, you might want to consult the ***
*** 'Troubleshooting' section in the INSTALL file first) ***
*** ***
**********************************************************************
What was your full "Configure" line? I don't recall there being any
options that we removed in 1.1.x compared to 1.0.2...or if we did we
made them no-ops or something.
Matt
------------------------------
Message: 4
Date: Mon, 27 Jan 2020 16:06:36 +0200
From: Eran Borovik <eran.borovik@xxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Determine that there is no forward progress with non blocking
SSL socket
Message-ID:
<CAEiHZPQAZ-kjGH7jc=rBSwdYRdW3P9TGe4Dyb2_1BmjMQ74eug@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Hi all,
My application is using non-blocking sockets to send and receive data. To
avoid issues, my code guarantees that a specific socket is always owned by
a specific thread, thus preventing any issues or races from concurrently
running send and receive at the same time on the same socket.
I've read thoroughly the lists regarding the best way to use non blocking
sockets with SSL. The common wisdom I gathered was:
-It is allowed to interleave SSL_read and SSL_write, meaning that SSL_read
doesn't have to complete successfully before issuing SSL_write( this makes
sense otherwise full-duplex doesn't work).
-SSL socket has a global state. So return value from one call negates a
previous return value from other call.
My question is how to determine that forward progress isn't possible and to
return to epoll.
Suppose I have a main-loop that deals with all the pending receives and
sends for a specific socket. For simplicity, assume that I try to
SSL_receive until I get some kind of an error (WANT_READ or WANT_WRITE).
Then I try to issue SSL_send until I get error as well, but if I read
correctly the group, the new error negates previous errors so prior
receives must be retried.
When do I stop? what is the best way to actually determine there can be no
more forward progress both on the send and the receive side, and epoll must
be used?
I can think on the following "algorithm" but I am not sure if it makes
sense:
-Receive until you get an Error X.
-Send. If I receive a return value that isn't X, it means receive will have
to be retried. If I immediately receive a return value that is X, it means
that no more progress is possible and I need to wait with epoll.
Problem with the above algorithm, is that I am afraid that if the send
buffer is full and there is nothing to receive, I will keep getting
WANT_READ for receive, and WANT_WRITE for send until actual data arrives or
can be sent which defeats the purpose of epoll.
I've been banging my head here for several days. Any help here will be much
appreciated.
Thx,
Eran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200127/c105e845/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 27 Jan 2020 18:20:27 +0000
From: Dan Heinz <dheinz@xxxxxxxxxxxxxxx>
To: "openssl-users@xxxxxxxxxxx" <openssl-users@xxxxxxxxxxx>
Subject: Decryption slower in 1.1.1 branch?
Message-ID:
<BN7PR06MB6401619418224C14BB46571AD90B0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
I upgraded a library that used OpenSSL 1.0.2 to the OpenSSL 1.1.1d. On Windows, I have found that the time to decrypt had doubled.
After a bit of timestamp logging, I found the RSA_private_decrypt function is taking twice as long with 1.1.1d as it did with 1.0.2t. This is being called from a Windows 64-bit DLL.
For example, decrypting 8680 bytes of data averages about .3 seconds with the OpenSSL 1.0.2t library (statically linked). Decrypting the same data with the OpenSSL 1.1.1d library averages about .6 seconds.
I'm wondering if perhaps my build configuration is incorrect or missing something for the 1.1.1d build. Here are the configuration parameters for the 64-bit build:
Configure VC-WIN64A --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-asm no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared
I logged things granular enough to see the speed difference was in RSA_private_decrypt, but I'm not sure why it is so much slower with 1.1.1d. Any help or ideas would be appreciated!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200127/086f8561/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
openssl-users mailing list
openssl-users@xxxxxxxxxxx
https://mta.openssl.org/mailman/listinfo/openssl-users
------------------------------
End of openssl-users Digest, Vol 62, Issue 6
********************************************
|
