openssl-users Digest, Vol 62, Issue 6
Dr. Matthias St. Pierre
Matthias.St.Pierre at ncp-e.com
Mon Jan 27 21:33:29 UTC 2020
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 at openssl.org<mailto:openssl-users-request at openssl.org>
Regards,
Matthias
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of RUBEN BARAINCA
Sent: Monday, January 27, 2020 7:44 PM
To: openssl-users at openssl.org
Subject: Re:openssl-users Digest, Vol 62, Issue 6
Importance: High
Hi!!
I want to unsubscribe.
-------- Original message --------
From: openssl-users-request at openssl.org<mailto:openssl-users-request at openssl.org>
Date: Mon, Jan 27, 2020, 7:20 PM
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Subject: openssl-users Digest, Vol 62, Issue 6
Send openssl-users mailing list submissions to
openssl-users at openssl.org<mailto:openssl-users at openssl.org>
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 at openssl.org<mailto:openssl-users-request at openssl.org>
You can reach the person managing the list at
openssl-users-owner at openssl.org<mailto:openssl-users-owner at openssl.org>
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 at yahoo.com<mailto:dougbmorris at yahoo.com>>
To: "openssl-users at openssl.org<mailto:openssl-users at openssl.org>" <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Subject: Thanks for Encoding Clarification
Message-ID: <791238297.11590163.1580014722271 at mail.yahoo.com<mailto:791238297.11590163.1580014722271 at mail.yahoo.com>>
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 at gmail.com<mailto:noloader at gmail.com>>
To: OpenSSL Users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Subject: What option is not recognized by OpenSSL 1.1.1d?
Message-ID:
<CAH8yC8k2s3=OFjOQ=MzNUsJpyJVQmMrg8UrqXbPwVeq9vo-ZDw at mail.gmail.com<mailto:CAH8yC8k2s3=OFjOQ=MzNUsJpyJVQmMrg8UrqXbPwVeq9vo-ZDw at mail.gmail.com>>
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 at openssl.org<mailto:matt at openssl.org>>
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Subject: Re: What option is not recognized by OpenSSL 1.1.1d?
Message-ID: <8a3bdb62-5ef6-3fd4-2cb0-108d5b0ebdbb at openssl.org<mailto:8a3bdb62-5ef6-3fd4-2cb0-108d5b0ebdbb at openssl.org>>
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 at gmail.com<mailto:eran.borovik at gmail.com>>
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Subject: Determine that there is no forward progress with non blocking
SSL socket
Message-ID:
<CAEiHZPQAZ-kjGH7jc=rBSwdYRdW3P9TGe4Dyb2_1BmjMQ74eug at mail.gmail.com<mailto:CAEiHZPQAZ-kjGH7jc=rBSwdYRdW3P9TGe4Dyb2_1BmjMQ74eug at mail.gmail.com>>
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 at softwarekey.com<mailto:dheinz at softwarekey.com>>
To: "openssl-users at openssl.org<mailto:openssl-users at openssl.org>" <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Subject: Decryption slower in 1.1.1 branch?
Message-ID:
<BN7PR06MB6401619418224C14BB46571AD90B0 at BN7PR06MB6401.namprd06.prod.outlook.com<mailto:BN7PR06MB6401619418224C14BB46571AD90B0 at BN7PR06MB6401.namprd06.prod.outlook.com>>
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 at openssl.org<mailto:openssl-users at openssl.org>
https://mta.openssl.org/mailman/listinfo/openssl-users
------------------------------
End of openssl-users Digest, Vol 62, Issue 6
********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200127/f8b4ad81/attachment-0001.html>
More information about the openssl-users
mailing list