Re: pkcs12 output change between release 1.0.2 and 1.1.1
Hi Matt, Ok, we'll proceed by another way. Thank you for your fast answer Kinbd regards, Patrice. Matt Caswell a écrit : On 28/10/2021 10:06, Patrice Guérin wrote: Hi all, The output of pkcs12 command differs between release 1.0.2 and 1.1.1. The command used is openssl pkcs12 -passin pass: -nokeys -in signedcert.bin In the bag attributes, if the subject (and probably the issuer) contains bytes outside ASCII range, I get a different result and make internal unit test failed in this case. In release 1.0.2, bytes are expressed as \xHH In release 1.1.1, they are expressed as \HH Is there a way to get compatible results ? Some of the command line tools offer the ability to set a "-nameopt" flag to control the format of this output. Unfortunately the pkcs12 app is not one of them, so this is not possible. Matt
pkcs12 output change between release 1.0.2 and 1.1.1
Hi all, The output of pkcs12 command differs between release 1.0.2 and 1.1.1. The command used is openssl pkcs12 -passin pass: -nokeys -in signedcert.bin In the bag attributes, if the subject (and probably the issuer) contains bytes outside ASCII range, I get a different result and make internal unit test failed in this case. In release 1.0.2, bytes are expressed as \xHH In release 1.1.1, they are expressed as \HH Is there a way to get compatible results ? Thank you in advance. Kind regards, Patrice.
Useable digest algorithms with signature
Dear All, Which digest algorithms can be used for signature with a RSA key ? sha and ripemd160 work well, but - whirlpool that works in 1.0.2o, doesn't anymore (1.1.1j) - the same applies to blake, shake Error setting context 6116:error:0408C09D:rsa routines:check_padding_md:invalid digest:crypto\rsa\rsa_pmeth.c:390: What is the reason ? (intellectual curiosity ?) Thanks. Patrice.
Cheking public or private key
Dear All, Is there a way to check if a EVP_PKEY is a public or private key ? In the case of use of EVP_Sign or EVP_DigestSign functions, an application leads to crash with SIGSEGV if an incorrect key is given when finalizing process. Thanks in advance for your answers. Kind regards, Patrice.
Fwd: Re: openssl s_client connection fails
Hi All, Sorry, send to missing. Patrice. Message transféré Sujet : Re: openssl s_client connection fails Date : Wed, 18 Nov 2020 14:46:45 + De :Matt Caswell Pour : Patrice Guérin On 18/11/2020 14:33, Patrice Guérin wrote: Hello Matt, Thank you for your very fast answer No, I don't have access to the server though it's publicly available. Well done ! You are a genius ! The SNI trick resolves the connection failiure... So, I have another questions : 1/ Do I have to always add SNI support, even in the case it's not necessary ? It is good practice to always add SNI support. Server's that don't need it will ignore it. Increasingly servers are requiring it. Unless you happen to know the server's requirements before you start there is no way of knowing before you start a connection whether the server will be picky about it. This is one of the main reasons why the default behaviour for s_client was changed between 1.1.0 and 1.1.1. 2/ If I want to switch to 1.1.1, are the API and libraries compatible with 1.1.0. I've used no-deprecated, but I can remove it and rebuild Yes 1.1.1 is backwards compatible with 1.1.0 so in theory it should be a drop in replacement. I don't think we deprecated anything in 1.1.1 as far as I remember so no-deprecated shouldn't make a difference. The biggest change between 1.1.0 and 1.1.1 is the addition of TLSv1.3 support. This brings with it numerous implications for applications using libssl which you should be aware of. See: https://wiki.openssl.org/index.php/TLS1.3 Matt Thank you very very much. Kind regards, Patrice. Matt Caswell a écrit : On 18/11/2020 11:24, Patrice Guérin wrote: 3072988928:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1407:SSL alert number 40 This is a very generic "something went wrong" alert that is being received from the server and could be due to any number of issues. Do you have access to the server in question? If so there may be more clues in the server logs that might explain it. Does anybody have an idea on what's going wrong ? One thing that springs to mind that often goes wrong is SNI handling. s_client changed between 1.1.0 and 1.1.1 to always provider SNI by default. If the server requires SNI then it could explain this behaviour. Your can add SNI in 1.1.0 by using the "-servername" command line option followed by the name of the server in question, e.g. $ openssl s_client -connect www.openssl.org -port 443 -servername www.openssl.org Matt Thank you in advance. Kind regards Patrice.
Fwd: Re: openssl s_client connection fails
Hi All, Sorry, send to missing. Patrice. Message transféré Sujet : Re: openssl s_client connection fails Date : Wed, 18 Nov 2020 11:40:33 + De :Matt Caswell Pour : openssl-users@openssl.org On 18/11/2020 11:24, Patrice Guérin wrote: 3072988928:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1407:SSL alert number 40 This is a very generic "something went wrong" alert that is being received from the server and could be due to any number of issues. Do you have access to the server in question? If so there may be more clues in the server logs that might explain it. Does anybody have an idea on what's going wrong ? One thing that springs to mind that often goes wrong is SNI handling. s_client changed between 1.1.0 and 1.1.1 to always provider SNI by default. If the server requires SNI then it could explain this behaviour. Your can add SNI in 1.1.0 by using the "-servername" command line option followed by the name of the server in question, e.g. $ openssl s_client -connect www.openssl.org -port 443 -servername www.openssl.org Matt Thank you in advance. Kind regards Patrice.
openssl s_client connection fails
Hello, I experience the following on Linux Debian 9 (openssl 1.1.0l) : When using openssl s_client to connect on a site, I get the following CONNECTED(0003) 3072988928:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1407:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1605691623 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- The same arises with -tls1, -tls1_1 and -tls1_2. So I've built the latest 1.1.1h and test it in the same conditions and it works in all cases... Does anybody have an idea on what's going wrong ? Thank you in advance. Kind regards Patrice.
Possible Cause of error ?
Hello, Can anybody tell me what is a possible cause of error status 20087002 : 'BIO routines:BIO_lookup:system lib' This happens only once on Debian 9 standard OpenSSL package (1.1.0l-1~deb9u1) Thank you in advance. Kind regards, Patrice.
[openssl-users] Questions about Ciphers
Hello, I have two questions : * I use OBJ_NAME_do_all_sorted() with OBJ_NAME_TYPE_CIPHER_METH to get the list of supported cipher methods Is there a difference between lowercase and uppercase names ? I've noticed that some do not have uppercase name (ex. aes-128-ccm) Is there a prefered name to use ? * In the case of GCM usage (with examples found in the OpenSSL wiki), Is the specific control action to set the tag on decryption can be done at the beginning rather than juste before EVP_DecryptFinal_ex() ? Thank you. Kind regards, Patrice. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] EVP_Encrypt/EVP_Decrypt input/output buffers requirements
Hello Matt, Thank you very much. Patrice. Matt Caswell a écrit : On 30/01/2019 09:45, Patrice Guérin wrote: Hello to all, Documentation does not provide input/output buffers requirements for encryption/decryption, so is it safe to submit the same buffer (ie, input=output) for these operations ? If not, what is the minimum distance 'd' required (input = output+d) ? This is to be used in small memory environment. EVP_Encrypt*/EVP_Decrypt* support in-place encryption/decryption, i.e. where in == out. They don't support "partially" overlapping buffers, i.e. where "in != out" but some portions of the buffer still overlap. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] EVP_Encrypt/EVP_Decrypt input/output buffers requirements
Hello to all, Documentation does not provide input/output buffers requirements for encryption/decryption, so is it safe to submit the same buffer (ie, input=output) for these operations ? If not, what is the minimum distance 'd' required (input = output+d) ? This is to be used in small memory environment. Thank you. Kind regards, Patrice. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] PKCS7 signature process
Hello OpenSSL-users In the purpose of signing pdf files, I've found a difference of behaviour that I can't explain between two ways of computing signatures. The first one leads to an error in the way that Adobe says that the file was modified after signing, the second does not. First Method: BIO* BioMem = BIO_new( BIO_s_mem() ); while ( Data ) BIO_write( BioMem , Data, DataLen ); MyPKCS7 = PKCS7_sign( Certificate, PrivateKey,NULL, BioMem , PKCS7_DETACHED | PKCS7_BINARY ); PKCS7_final( MyPKCS7, BioMem , PKCS7_DETACHED | PKCS7_BINARY ); BIO* BioOut = BIO_new( BIO_s_mem() ); i2d_PKCS7_bio( BioOut , MyPKCS7 ); char* OutBuf = NULL; int OutLen = BIO_get_mem_data( BioOut , &OutBuf ); Second Method: BIO* BioMem = BIO_new( BIO_s_mem() ); MyPKCS7 = PKCS7_sign( Certificate, PrivateKey,NULL, BioMem , PKCS7_DETACHED | PKCS7_BINARY ); while ( Data ) BIO_write( BioMem , Data, DataLen ); PKCS7_final( MyPKCS7, BioMem , PKCS7_DETACHED | PKCS7_BINARY ); BIO* BioOut = BIO_new( BIO_s_mem() ); i2d_PKCS7_bio( BioOut , MyPKCS7 ); char* OutBuf = NULL; int OutLen = BIO_get_mem_data( BioOut , &OutBuf ); It seems that the order between PKCS7_sign et BIO_Write that feeds the memory BIO has an importance. Can anybody explains why the first method is incorrect ? Thank you in advance Patrice. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: CRYPTO_malloc_init()
Hello Michael, Thank you very much for your help. I will rebuild OpenSSL for static linking and use it in my program. Kind regards, Patrice. Michael Wojcik a écrit : From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Patrice Guérin Sent: Wednesday, 12 November, 2014 13:28 My second question is, in this case, is there problems to have loaded DLLs that do not match the headers I used for compilation ? Yes. I don't know offhand of a specific case on Windows where this may be a problem, if your headers are from *exactly* the same version as the library your application has loaded; but I would bet that there are some. Calling an OpenSSL library that was built with different configuration options than you used when generating the headers can definitely lead to problems, including undefined behavior (and so crashing, silent memory corruption, etc). I recently diagnosed a problem of this sort on AIX. Do I need to do static linkage of OpenSSL 0.9.8 in my DLL to avoid incompatibilities ? If you have third-party code that's loading incompatible versions of OpenSSL, it's difficult to guarantee correct behavior without statically linking it for your own use. This isn't a problem that's specific to OpenSSL; it's generally the case when dynamic linking isn't protected by strong versioning (or a highly abstracted API), and one or more dynamically-linked objects are used by independent components of the program. And strong versioning is nearly impossible with open-source projects, because - as in this case - incompatible versions can be built independently and used together in the same process. I've also seen this happen with the OpenLDAP client library, for example. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
CRYPTO_malloc_init()
Hello All, I have a program on Windows that, among tohers things, access databases through ODBC and computes sha1 values from files. OpenSSL functions are accessed through a DLL and do initialisation when it needs to. My program uses release OpenSSL 0.9.8 DLLs The used database is a PostgreSQL 9.03.04 (I think it uses OpenSSL 1.x DLLs) In my SSL Init(), I check the result of CRYPTO_malloc_init() function and throw an exception if the result is 0. I suspect that the previous access to PostgreSQL loads its OpenSSL DLLs and probably do a CRYPTO_malloc_init(). When I want to do my own, it returns 0 because allow_customize has been set to false. Is there a way to know if CRYPTO_malloc_init() has already been called by a tier ? My second question is, in this case, is there problems to have loaded DLLs that do not match the headers I used for compilation ? Do I need to do static linkage of OpenSSL 0.9.8 in my DLL to avoid incompatibilities ? Thank you for your advices. King regards, Patrice. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Does OpenSSL supports the HTTP POST request?
Hi Yogesh Of course, yes ! SSL is completly independant of HTTP protocol. HTTP GET and POST methods differ in the way of passing parameters. On GET, parameter are passed in the URI as URI?param=value¶m=value&...param=value On POST, parameters are passed in the same format param=value¶m=value&...param=value but as the request data. In one word : POST Uri HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length = param=value¶m=value&...param=value<- this is request data Once the request is build, you can send it to the web server, and read as usual. Hope this helps Patrice. Yogesh_Gujar a écrit : Hi, I want to use HTTP POST request for connecting to the server..I checked with the available sample programs but it all supports HTTP GET. So my doubt is that Is it possible to send HTTP POST message using the openSSL. If yes?then how I can achieve that? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
BIO sockets usage
Hello All, I have some basic questions about BIO sockets. In order to use BIO sockets as simple network layer without SSL negotiation. Is SSL_library_init() needed or not ? I think it's not mandatory, but I want to have a confirmation of this. On Win32 platforms, there are two functions, BIO_sock_init(void ) and BIO_sock_cleanup(void). I've seen in the sources that BIO_sock_init() is called in some places to initialize Winsock (WSAStartup) but BIO_sock_cleanup() is not. Should it be done by the application ? Thank you. Patrice. P.S. Sorry for inconvenience, I've sent the previous e-mail to owners-openssl-users. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Using OpenSsl in a .Net server (ongoing opensource project)
Amit,
No, I don't misunderstand you.
The (real) example I gave is in fact similar (I think so)
In a classic Win32 application, when mixing different compiler setting,
different compilers between application and the OpenSSL dll and use some
functions involving FILE* parameters, applink is used to resolve the crash.
The actions to do are :
Add the snippet applink.c or include the file ONLY ONCE in the main project.
I guess the same can be done with .NET application...
When running the application:
OpenSSL dll will search the application module for the OPENSSL_Applink()
function.
If it doesn't find it, OpenSLL exits with a message.
I've never done any application in .NET, just this dll.
If you take OpenSSL as a pre-built binary, it's probably a Win32 dll (so
unmanaged), and if you add the snippet in your .NET application and
OpenSSL does not resolve OPENSSL_Applink(), maybe it's because
OPENSSL_Applink() is considered as managed code.
So, maybe, adding #pragma unmanaged at the beginning of applink.c can
solve your problem.
You can use a tool called "dependancy walker" that show the exe/dlls
entry points and used dlls
http://www.dependencywalker.com/
Just see if OPENSSL_Applink is present or not...
Patrice.
Amit Ben Shahar a écrit :
Would anyone happen to know how i can eliminate the requirement of the
applink implementation? why would we actually need it?
Take a look at the other thread I gave you (Win32 OPENSSL_USE_APPLINK
usage) for further explanations... and the FAQ about Win32 applications
that crash.
Amit Ben Shahar
On Sat, Apr 24, 2010 at 13:25, Amit Ben Shahar <mailto:amit.b...@gmail.com>> wrote:
Patrice,
I think your have misunderstood me (or i did you),
From what you wrote i gather that you are talking about using .Net
dlls in native applications, which is not the case here, i need it
the other way around.
Our server is a .Net application and so we'd either have to
somehow get the Uplink/applink to recognize a method in the .Net
assembly (i understood that it cannot be in an adjacent dll) OR to
completely eliminate the Applink usage.
If i misunderstood please correct me :)
Amit Ben Shahar
VP R&D
ISQ Technologies
(+972) 545-592-934
a...@isqgroup.net <mailto:a...@isqgroup.net>
www.isqgroup.net <http://www.isqgroup.net>
2010/4/24 Patrice Guérin mailto:guer...@magic.fr>>
Hello Amit,
Maybe you can explore the "IJW" way...
I use Visual C++ 6 to build my aWin32 pplications and I had to
use some .NET Crypto functions such as RSA to communicate with
a customer.
I've used Visual C++ 2005 Express, in which I add the Win32
environment (from a platform SDK. Express don't have Win32
environment by default...) to compile
the .NET dll and use it from a win32 dll.
The trick is to use #pragma managed / #pragma unmanaged as
appropriate
cryptodotnet.h : the include file for win32/.NET
#ifndefCRYPTDOTNET_EXPORT
#defineCRYPTDOTNET_EXPORT__declspec( dllimport )
#endif
#defineCRYPTDOTNET_VERSION"1.0.0"
#defineCRYPTDOTNET_DATE"20100228"
class CRYPTDOTNET_EXPORT CryptDotNet
{
public:
CryptDotNet(){};
virtual ~CryptDotNet(){};
int RSAEncrypt( const char* XmlPublicKey, const unsigned char*
Data, const int DataLength, char* Base64EncryptBuffer, int*
Base64EncryptBufferLength );
...
};
cryptodotnet.cpp : compiled with VC++2005
#define CRYPTDOTNET_EXPORT __declspec(dllexport)
#pragma unmanaged
#include "cryptdotnet.h"
#include
#include
#pragma managed
classCryptDotNetManaged
{
public:
CryptDotNetManaged(){};
~CryptDotNetManaged(){};
int RSAEncrypt( const char* XmlPublicKey, const unsigned char*
Data, const int DataLength, char* Base64EncryptBuffer, int*
Base64EncryptBufferLength );
};
//Unmanaged interface
int CryptDotNet::RSAEncrypt( const char* XmlPublicKey, const
unsigned char* Data, const int DataLength, char* Base64EncryptBuffer, int*
Base64EncryptBufferLength )
//
{
CryptDotNetManagedc;
return c.RSAEncrypt( XmlPublicKey, Data, DataLength,
Base64EncryptBuffer, Base64EncryptBufferLength );
}
// Managed part
#pragma managed
using namespace System;
...
int CryptDotNetManaged::RSAEncrypt( )
{
Re: Using OpenSsl in a .Net server (ongoing opensource project)
Hello Amit,
Maybe you can explore the "IJW" way...
I use Visual C++ 6 to build my aWin32 pplications and I had to use some
.NET Crypto functions such as RSA to communicate with a customer.
I've used Visual C++ 2005 Express, in which I add the Win32 environment
(from a platform SDK. Express don't have Win32 environment by
default...) to compile
the .NET dll and use it from a win32 dll.
The trick is to use #pragma managed / #pragma unmanaged as appropriate
cryptodotnet.h : the include file for win32/.NET
#ifndefCRYPTDOTNET_EXPORT
#defineCRYPTDOTNET_EXPORT__declspec( dllimport )
#endif
#defineCRYPTDOTNET_VERSION"1.0.0"
#defineCRYPTDOTNET_DATE"20100228"
class CRYPTDOTNET_EXPORT CryptDotNet
{
public:
CryptDotNet(){};
virtual ~CryptDotNet(){};
int RSAEncrypt( const char* XmlPublicKey, const unsigned char* Data,
const int DataLength, char* Base64EncryptBuffer, int* Base64EncryptBufferLength
);
...
};
cryptodotnet.cpp : compiled with VC++2005
#define CRYPTDOTNET_EXPORT __declspec(dllexport)
#pragma unmanaged
#include "cryptdotnet.h"
#include
#include
#pragma managed
classCryptDotNetManaged
{
public:
CryptDotNetManaged(){};
~CryptDotNetManaged(){};
int RSAEncrypt( const char* XmlPublicKey, const unsigned char* Data,
const int DataLength, char* Base64EncryptBuffer, int* Base64EncryptBufferLength
);
};
//Unmanaged interface
int CryptDotNet::RSAEncrypt( const char* XmlPublicKey, const unsigned char*
Data, const int DataLength, char* Base64EncryptBuffer, int*
Base64EncryptBufferLength )
//
{
CryptDotNetManagedc;
return c.RSAEncrypt( XmlPublicKey, Data, DataLength,
Base64EncryptBuffer, Base64EncryptBufferLength );
}
// Managed part
#pragma managed
using namespace System;
...
int CryptDotNetManaged::RSAEncrypt( )
{ ... };
This works very well.
In your case, maybe the applink.c should be considered as unmanaged code.
some references for inspiration...
http://ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html
http://www.techheadbrothers.com/Articles.aspx/integrez-code-cplusplus-natif-applications-dotnet-page-1
(sorry... in french...)
and finally the thread "Win32 OPENSSL_USE_APPLINK usage" in OpenSSL-dev
Hope this helps.
Patrice.
Amit Ben Shahar a écrit :
On Fri, Apr 23, 2010 at 21:35, James Mansion
mailto:ja...@mansionfamily.plus.com>>
wrote:
Amit Ben Shahar wrote:
One of the crucial ingredients is ssl using OpenSsl. but we
are encountering a problem with the 'no OPENSSL_Applink' error.
as this is a .Net project, there is no way (i can think of) to
compile with the applink.c file.
1) Why is that crucial? Microsoft provide crypto support on
Windows, albeit with a different interface. What's wrong with
System.Net.Security.SslStream?
The .Net.Security.SslStream is not working in asynchronous calls,
meaning we'd have to implement it in a thread-per-connection paradigm,
which is obviously not an option.
2) Why can't you 'compile with the applink.c file'? You need a
talk to it through p/invoke - you may need to write another glue
DLL to do this. If you can locate an OpenSSL implementation that
has been wrapped as a free-threaded COM service, you might find
things easier if you don't know how to write such glue. You could
try looking in Mono's runtime, too, which I suspect delegates to
OpenSsl (tho I haven't checked).
As far as i understood it, openSsl looks for the applink
implementation in the actual application and not in dlls, but i could
have misread that, anyhow i'm not sure i would know how to do that,
can you maybe directly to such an implmentation (free-threaded COM) ?
- in the meantime i'll try checking in Mono, though i've never ever
looked at it yet. maybe i'll get lucky ;)
thanks
