[openssl-dev] [openssl.org #4506] Add SSL_CTX_get_ciphers() [GitHub PR #957]
Resolving, this has been merged. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4506 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4433] Memory leak in X509_REQ_to_X509
X509_REQ_to_X509 returns a newly allocated X509 structure. If you believe that it leaks somewhere else, then please reopen this ticket with fully self-contained code, and a trace (e.g., from valgrind) showing where the leak happens. Emilia -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4433 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4529] Output of -hash option incompatible 64-bit Linux vs 32-bit Linux
On Mon May 02 19:00:03 2016, john.with...@irs.gov wrote: > > I successfully built and deployed to a 64-bit RHEL 5.11 server (using > a local installation path) and was able to configure the issuer > certificate cache for my applications. I built a separate package for > 32-bit RHEL 5.11 (again, using a local installation path). After > installation, I observed that the -hash option of the openssl command > (and hence the c_rehash utility) computed incorrect subject hashes for > the issuer certificates in the cache. Identical certificates from the > 64-bit installation were installed but the hash values were different. > Tracing the operation of the s_client module with strace indicated > that the hash values computed internally matched the hash values > produced on the 64-bit system. I replicated the symbolic links for > the issuer certificates from the 64-bit system to the 32-bit system > and the certificates presented by the remote server for my application > were verified. > That shouldn't happen: the alrgorithms used are independent of the platform so whether it is 32 or 64 bits or a completely different OS shouldn't matter. Is it possible you were accidentally using OpenSSL 0.9.8 (maybe the system version) at some point? The hash algorithm used is different between 0.9.8 and 1.0.0+ Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4529 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4529] Output of -hash option incompatible 64-bit Linux vs 32-bit Linux
To whom it may concern, I have built OpenSSL 1.0.1s for 64-bit and 32-bit version of RHEL5.11. The reasons for this are long and involve my employer, so I would detail them in this message. I successfully built and deployed to a 64-bit RHEL 5.11 server (using a local installation path) and was able to configure the issuer certificate cache for my applications. I built a separate package for 32-bit RHEL 5.11 (again, using a local installation path). After installation, I observed that the -hash option of the openssl command (and hence the c_rehash utility) computed incorrect subject hashes for the issuer certificates in the cache. Identical certificates from the 64-bit installation were installed but the hash values were different. Tracing the operation of the s_client module with strace indicated that the hash values computed internally matched the hash values produced on the 64-bit system. I replicated the symbolic links for the issuer certificates from the 64-bit system to the 32-bit system and the certificates presented by the remote server for my application were verified. Thanks! John Withers Enterprise Operations Directory Services Branch - OS:CTO:EO:ISD:DSB:PKI Champaign, Illinois Phone: (217) 974-7736 "A positive attitude may not solve all of your problems, but it will annoy enough people to make it worth the effort" -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4529 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Storing session in file and reusing at client side
Thanks Viktor. > > Client-side sessions can be serialized via i2d_SSL_SESSION and the > resulting binary data can be stored in a file for reuse by a client > via d2i_SSL_SESSION() followed by SSL_set_session() (which copies > the session, so you can free the session obtained via d2i at that > point). > > I did this thing using PEM_write_SSL_SESSION and PEM_write_SSL_SESSION respectively, which seemed to work for the server side session handling. But when I use the above mentioned methods, it gives me that illegal parameter (47) error. As a matter of fact, I was able to load the session_id into the Client hello message, and even the server method responded with the same session_id. But the next message was the fatal error which terminated the handshake. > Of course the client needs to want to reconnect to the same SSL > peer with the same security policy, otherwise session reuse is > unwise. > > I ensured I am using the same client_method (security policy), but still can't figure out why the error comes up. > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Regards Shubham Chauhan 2013099 B.Tech CSE -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4528] Bugfix for linux-armv4 build
commit fbaf30d087a2db2b4e22279e819d481fca21ac5c Author: Andy Polyakov Date: Mon May 2 15:20:41 2016 +0200 ssl/record/rec_layer_s3.c: fix typo from previous commit. Reviewed-by: Richard Levitte -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4528 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4528] Bugfix for linux-armv4 build
On 05/02/2016 10:56 AM, Florent Gluck via RT wrote: > Hi, > > When compiling for linux-armv4 there is a bug in the master branch, > version d244dd559d0e6e594e4a0f911e49509e8a7b158b, there is a missing > backslash in ssl/record/rec_layer_s3.c. > Already fixed in commit fbaf30d087a2db2b4e22279e819d481fca21ac5c -Ben -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4528 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4528] Bugfix for linux-armv4 build
Hi, When compiling for linux-armv4 there is a bug in the master branch, version d244dd559d0e6e594e4a0f911e49509e8a7b158b, there is a missing backslash in ssl/record/rec_layer_s3.c. Here is patch for the fix: --- ssl/record/rec_layer_s3.c.ori 2016-05-02 14:32:28.913137297 +0200 +++ ssl/record/rec_layer_s3.c2016-05-02 14:35:35.145497035 +0200 @@ -125,7 +125,7 @@ #if defined(OPENSSL_SMALL_FOOTPRINT) || \ !( defined(AES_ASM) && ( \ defined(__x86_64) || defined(__x86_64__) || \ -defined(_M_AMD64) || defined(_M_X64) ) +defined(_M_AMD64) || defined(_M_X64) ) \ ) # undef EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK # define EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK 0 Best regards, -- Florent Gluck Professor University of Applied Sciences Western Switzerland HES-SO hepia Rue de la Prairie 4 - 1202 Geneva - Switzerland Phone: +41.22.54625.52 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4528 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Storing session in file and reusing at client side
On Mon, May 02, 2016 at 12:23:25PM +0530, Shubham Chauhan wrote: > I wanted to store the freshly negotiated ssl/tls session in a file and > reuse it (via SSL_set_session()), in the next handshake. I was not able to > do that since the handshake got terminated giving a fatal error - illegal > parameters (47). Client-side sessions can be serialized via i2d_SSL_SESSION and the resulting binary data can be stored in a file for reuse by a client via d2i_SSL_SESSION() followed by SSL_set_session() (which copies the session, so you can free the session obtained via d2i at that point). Of course the client needs to want to reconnect to the same SSL peer with the same security policy, otherwise session reuse is unwise. -- Viktor. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4527] Bug in d2i_PrivateKey (openssl-1.1.0-pre5)
There is a bug in the implementation of d2i_PrivateKey in crypto/asn1/d2i_pr.c. If the function is called with *a != NULL and returns NULL, the value of *a is not changed, but the EVP_PKEY it refers to might have been freed or not depending on whether line 100 was reached or not. If the caller makes the wrong guess this can result in a crash due to a double free or in a memory leak. Best regards Harry Reimann -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4527 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Are you using "TLS proxy certificates"?
Thank you, yes, I mean that. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4526] bug: use of ExitProcess on Windows platforms, 1.0.2g
Hi, I'm working in the 1.0.2g version of OpenSSL, in a Windows desktop environment, specifically Win 7, 8.1, and 10 (and their equivalent server and R2 versions). Problem and Resolution: The following lines of code make use of the Microsoft API ExitProcess: Apps\Speed.c line 335: ExitProcess(ret); Ms\uplink.c line 22: ExitProcess(1); These function calls are made after fatal errors are detected and program termination is desired. ExitProcess(), however causes *orderly* shutdown of a process and all its threads, i.e. it unloads all dlls and runs all destructors. See MSDN for details of exactly what happens (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx). The MSDN page states that ExitProcess should never be called unless it is *known to be safe* to call it. These calls should simply be replaced with calls to TerminateProcess(), which is what should be called for *disorderly* shutdown. An example of usage: TerminateProcess(GetCurrentProcess(), exitcode); Effect of Problem: Because of a compilation error (wrong c++ runtime), my program executed the uplink.c ExitProcess() call. This caused the single OpenSSL thread to start executing the destructors of all my dlls, and their objects. Unfortunately, about 30 other threads were happily using those objects at that time, eventually causing a 0xC005 ACCESS_VIOLATION. Obviously an ACCESS_VIOLATION is the best case scenario, as I'm sure you can imagine at the consequences of undiscovered memory corruption, even in a terminating process. Regards, Ty Baen-Price JADE Development Team Leader Wynyard Group DDI +64 3 367 8453 Powerful Software. Connecting the Dots. wynyardgroup.com -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4526 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4525] [PATCH] SRP client key computation (PR #1017)
Hello openSSL devs, I have found an issue in the computation of the SRP session key on the client side. When computing *K = (B − kg^x**)^(a+ux) mod N*, the computations in the exponent should not be mod N. Meaning that *(a+ux)* should not go through *mod N* . It rarely happens that *(a+ux) > N *but when it is, the key computed on the client side is different from the server's one. There is a pull request pending to delete the mod operation in the exponent computation (PR #1017). Best regards, Leo Logeart -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4525 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Are you using "TLS proxy certificates"?
Hi Rich, On 27/04/16 18:45, Salz, Rich wrote: If so, please let us know. Replies to me will be summarized for the lists. what exactly do you mean by 'TLS proxy certificates' ? if you mean RFC3820 (5280) proxy certificates, then yes, we use them extensively within grid computing. regards, JJK / Jan Just Keijser Nikhef Amsterdam -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
