Static linking libssl.a and libcrypto.a on Linux x64 fails
So I posted this question over at stackoverflow ( https://stackoverflow.com/questions/58771714/compiling-c-and-c-with-single-makefile) but the gist of it is as follows: I am trying to statically link libssl.a and libcrypto.a into a static library of my own which I will be using in an application (Linux). So I first create that library (let's call it libAPP.a) and then I use that library in an application. So first things first: 1. when I checkout the contents of that library (nm libAPP.a | less) , almost all (I haven't confirmed every single one but it sure looks that way) SSL related symbols (ex. BIO_new) are left undefined in libAPP.a. Why is that? 2. perhaps this is related to question one above, but when I use libAPP.a in my application, I get a whole bunch of 'undefined reference to' errors for the SSL symbols; they disappear when I pass libSSL.a and libCrypto.a to the linker. may be I need a refresher course on libraries but what is the point of linking statically when I still have to keep those libraries? 3. Even after supplying all these libraries, my linker was complaining about a whole bunch of symbols like dlopen, dlclose etc so after some googling, I supplied -ldl and -lz to the linker. So those linker errors related to dlopen etc went but now it complains that it cannot find libz on the system when it is clearly present. Can anyone please elaborate on the steps need for a clean static linking of libssl.a into an application? Is it even doable on Linux considering such tight coupling of libc everywhere?? If not what are the alternatives?? -- Best Regards, Aijaz Baig
Using PSKs with openssl app.
H, This is my method for using external PSKs with the openssl tool. Does this appear correct? The application darta seems to be exchanged and if I change a PSK it will fail. I *think* this is correct... Server side: PSK=b2c9b9f57ef2fbbba8b624070b301d7f278f1b39c352d5fa849f85a3e7a3f77b openssl s_server -accept 8400 -tls1_3 -nocert -psk $PSK -ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 Client side: PSK=b2c9b9f57ef2fbbba8b624070b301d7f278f1b39c352d5fa849f85a3e7a3f77b openssl s_client -connect 127.0.0.1:8400 -tls1_3 -psk $PSK -tlsextdebug Here are the hello messages that are exchanged: TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 282 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 278 Version: TLS 1.2 (0x0303) Random: d9cd1e44a462699f2a2f794a7fb3dd129b183d3c22183bab… Session ID Length: 32 Session ID: 5525acf9be6afd90e7a7853405157bc21cda45bd708a65f9… Cipher Suites Length: 8 Cipher Suites (4 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 197 Extension: ec_point_formats (len=4) Type: ec_point_formats (11) Length: 4 EC point formats Length: 3 Elliptic curves point formats (3) Extension: supported_groups (len=22) Type: supported_groups (10) Length: 22 Supported Groups List Length: 20 Supported Groups (10 groups) Extension: session_ticket (len=0) Type: session_ticket (35) Length: 0 Data (0 bytes) Extension: encrypt_then_mac (len=0) Type: encrypt_then_mac (22) Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: signature_algorithms (len=30) Type: signature_algorithms (13) Length: 30 Signature Hash Algorithms Length: 28 Signature Hash Algorithms (14 algorithms) Extension: supported_versions (len=3) Type: supported_versions (43) Length: 3 Supported Versions length: 2 Supported Version: TLS 1.3 (0x0304) Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: key_share (len=38) Type: key_share (51) Length: 38 Key Share extension Client Key Share Length: 36 Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: eb7a84e24c88e64c0032bbdba0485281702c7929d72d1417… Extension: pre_shared_key (len=58) Type: pre_shared_key (41) Length: 58 Pre-Shared Key extension Identities Length: 21 PSK Identity (length: 15) PSK Binders length: 33 PSK Binders TLSv1.3 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 128 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 124 Version: TLS 1.2 (0x0303) Random: 4b491c81e70b2ded5bb9d922009b9d8579f9c4415f067f9b… Session ID Length: 32 Session ID: 5525acf9be6afd90e7a7853405157bc21cda45bd708a65f9… Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) Compression Method: null (0) Extensions Length: 52 Extension: supported_versions (len=2) Type: supported_versions (43) Length: 2 Supported Version: TLS 1.3 (0x0304) Extension: key_share (len=36) Type: key_share (51) Length: 36 Key Share extension Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: 33f67b055f03bb7ce049dc4cb338569d015acc5911f3c55f… Extension: pre_shared_key (len=2) Type: pre_shared_key (41) Length: 2 Pre-Shared Key extension Selected Identity: 0 Here is the client output: ➜ scripts git:(working) ✗ ./client CONNECTED(0003) TLS server extension "supported versions" (id=43), len=2 - 03 04 .. TLS server extension "key share" (id=51), len=36 - 00 1d 00 20 cd c7 59 0b-f3 98 90 e0 34 bc 01 32 ... ..Y.4..2 0010 - ed 86 cd 9c 9e e4 89 be-fe 3a 57 d0 68 c7 e5 5f
Re: Removing Extensions from Client Hello Header
On Tue, Nov 12, 2019 at 03:08:19PM -0700, Phil Neumiller wrote:
> I find the comment below about TLS 1.3 troubling.
[...]
> */*
> * TODO(TLS1.3): These APIs cannot set TLSv1.3 sig algs so we just test
> it
> * for TLSv1.2 for now until we add a new API.
> */*
> SSL_CTX_set_max_proto_version(cctx, TLS1_2_VERSION);
>
> if (testctx) {
> int ret;
>
> if (curr->list != NULL)
> ret = SSL_CTX_set1_sigalgs(cctx, curr->list, curr->listlen);
> else
> ret = SSL_CTX_set1_sigalgs_list(cctx, curr->liststr);
I don't.
>From SSL_CTX_set1_sigalgs.pod:
% The TLS 1.3 signature scheme names (such as "rsa_pss_pss_sha256") can also
% be used with the B<_list> forms of the API.
The TLS 1.3 schemes don't decompose into SIG+HASH, so this is just a constraint
inherent to the old API, not a bug.
-Ben
Re: Removing Extensions from Client Hello Header
I find the comment below about TLS 1.3 troubling.
static int test_set_sigalgs(int idx)
{
SSL_CTX *cctx = NULL, *sctx = NULL;
SSL *clientssl = NULL, *serverssl = NULL;
int testresult = 0;
const sigalgs_list *curr;
int testctx;
/* Should never happen */
if (!TEST_size_t_le((size_t)idx, OSSL_NELEM(testsigalgs) * 2))
return 0;
testctx = ((size_t)idx < OSSL_NELEM(testsigalgs));
curr = testctx ? [idx]
: [idx - OSSL_NELEM(testsigalgs)];
if (!TEST_true(create_ssl_ctx_pair(TLS_server_method(),
TLS_client_method(),
TLS1_VERSION, 0,
, , cert, privkey)))
return 0;
*/*
* TODO(TLS1.3): These APIs cannot set TLSv1.3 sig algs so we just test
it
* for TLSv1.2 for now until we add a new API.
*/*
SSL_CTX_set_max_proto_version(cctx, TLS1_2_VERSION);
if (testctx) {
int ret;
if (curr->list != NULL)
ret = SSL_CTX_set1_sigalgs(cctx, curr->list, curr->listlen);
else
ret = SSL_CTX_set1_sigalgs_list(cctx, curr->liststr);
if (!ret) {
-
Phillip Neumiller
Platform Engineering
Directstream, LLC
--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Removing Extensions from Client Hello Header
On Tue, Nov 12, 2019 at 01:13:49PM -0700, Phil Neumiller wrote: > Thanks for all the useful device. I was able to get the server to accept > this client hello message. If you're willing/able to share, it can be useful for us to know what products are buggy in that they don't implement extensions in a proper, extensible, manner and need to have the ClientHello extensions adjusted like this. If we have a list of "likely suspects" it can make diagnosing future connection issues easier. Thanks, Ben
Re: Removing Extensions from Client Hello Header
Thanks for all the useful device. I was able to get the server to accept this client hello message. TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 257 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 253 Version: TLS 1.2 (0x0303) Random: 00010002000400090012… Session ID Length: 0 Cipher Suites Length: 2 Cipher Suites (1 suite) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 210 Extension: supported_groups (len=4) Type: supported_groups (10) Length: 4 Supported Groups List Length: 2 Supported Groups (1 group) Supported Group: x25519 (0x001d) Extension: signature_algorithms (len=4) Type: signature_algorithms (13) Length: 4 Signature Hash Algorithms Length: 2 Signature Hash Algorithms (1 algorithm) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (6) Extension: key_share (len=38) Type: key_share (51) Length: 38 Key Share extension Client Key Share Length: 36 Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: 009201240249049209241249… Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: supported_versions (len=3) Type: supported_versions (43) Length: 3 Supported Versions length: 2 Supported Version: TLS 1.3 (0x0304) Extension: heartbeat (len=1) Type: heartbeat (15) Length: 1 Mode: Peer not allowed to send requests (2) Extension: pre_shared_key (len=130) Type: pre_shared_key (41) Length: 130 Pre-Shared Key extension Identities Length: 28 PSK Identity (length: 8) Identity Length: 8 Identity: 924900012492 Obfuscated Ticket Age: 0 PSK Identity (length: 8) Identity Length: 8 Identity: Obfuscated Ticket Age: 0 PSK Binders length: 98 PSK Binders So just one signature algorithm. Now the response I got from the OpenSSL TLS server is this server hello. TLSv1.3 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 90 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 86 Version: TLS 1.2 (0x0303) Random: 7f9801c0f94da77d9d2c100cba7ff587bec25bca39defd81… Session ID Length: 0 Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Compression Method: null (0) Extensions Length: 46 Extension: supported_versions (len=2) Type: supported_versions (43) Length: 2 Supported Version: TLS 1.3 (0x0304) Extension: key_share (len=36) Type: key_share (51) Length: 36 Key Share extension Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: ab6c1e5e5a83cdeee70487c509bd0810668a32fa2402f7d7… Now to try the actual hardware At least openssl TLS 1.3 is OK with just 1 signature algorithm for my special case of external out of band PSK. - Phillip Neumiller Platform Engineering Directstream, LLC -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Help on Diffie Hellman key exchange
Thanks Tomas, I will try that. On Tue, Nov 12, 2019 at 3:14 AM Tomas Mraz wrote: > On Mon, 2019-11-04 at 17:34 -0500, Jason Qian via openssl-users wrote: > > Hi > > > >We have an application that does the Diffie Hellman key exchange > > (OpenSSL/1.1.0f). > >It works fine, but under heavy loaded conditions, sometimes an > > invalide secret been generated and other side couldn't decrypt the > > data (the secret seems offset by one). > > > >The client side is c++ and the server side is java. > > > > DH_compute_key(secretKey, bnY, m_DH); > > > >Someone in the openssl group also talks about a similar issue, but > > not sure if have a solution. > > Could it be a padding issue? I.E. use DH_compute_key_padded() instead. > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > >
EVP_CIPHER_CTX_FLAG_WRAP_ALLOW
Hello, I'm trying to implement the new Russian GOST CMS specification. It uses the key wrap algorithm described here: https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-06#section-8.2 I've implemented the algorithm as a cipher with the EVP_CIPH_WRAP_MODE flag. It seems to me that the only way to avoid clearing the EVP_CIPHER_CTX_FLAG_WRAP_ALLOW flag in the EVP_CipherInit function is providing the ctrl function in the corresponding EVP_CIPHER object because the EVP_CipherInit function resets the passed EVP_CIPHER_CTX object. The EVP_CipherInit_ex does not reset the EVP_CIPHER_CTX object and theEVP_CIPHER_CTX_FLAG_WRAP_ALLOW stays untouched, so the behavior seems a bit controversial (and undocumented, at least for the 1.1.1 branch). Is this difference a desired one or an accidental one? Should it be documented or fixed? -- SY, Dmitry Belyavsky
Re: Resetting DTLS server
On Tue, Nov 12, 2019 at 9:07 AM Michael Richardson wrote:
>
> so you are showing me your server code, correct, and this is for DTLS,
> right?
> Do you call DTLSv1_accept()?
Yes, DTLS. There is no DTLSv1_accept. SSL_accept should work because
it is based on 'method' and underlying BIO. I left some steps out of
my example code (i was just hand typing it one the fly, not
copy/paste).
>
> You don't seem to be creating a new socket anywhere, or calling
> connect() on this socket.
> I'm not sure I understand your comment above about connect would not be
> a difference.
> If your DGRAM socket is not connected, how can you send packets back?
> It would be nice
> if DTLS code would store the origin of every packet and demux it into
> multiple SSL*, but it doesn't work that way.
I'm not creating a new socket because it is UDP, and i'm assuming only
one client. If you use a BIO_new_dgram, then you dont need to
"connect" the UDP socket, the dgram BIO will keep track of the
client's addr. So because of this behavior, "connect" doesn't change
anything. I have called "connect" on the sockets in other tests, but
it gives the exact same result.
SSL_accept waits for a 'clienthello', which the underlying dgram BIO
will store the client's addr, so that when SSL_accept writes the
response via the BIO, it'll get sent to the proper address. My tests
show this working just fine the first time the client connects; the
server handshakes and can read messages.
Even if i were the "connect" the socket to the clients addr, the
client comes up with the same addr/port combination, so the server's
"connected" UDP socket will continue reading mesgs from the client.
BUT it'll get stuck in SSL_read when the client restarts because
SSL_read is not expecting a "clienthello", and the library continues
to try to read more packets.
Here is a more correct version of the code
s=socket(AF_INET, SOCK_DGRAM, 0);
bind(s, , sizeof(serverAddr));
ssl=SSL_new(ctx);
bio=BIO_new_dgram(s, BIO_NOCLOSE);
SSL_set_bio(ssl, bio, bio);
SSL_accept(ssl);
// at this point the client is authenticated and handshake is
complete. ssl's underlying BIO has the clients addr.
while (1) {
FD_ZERO();
FD_SET(s, );
select(FD_SETSIZE, fds, NULL, NULL, NULL);
if (FD_ISSET(s)) {
n=SSL_read(ssl, buffer, sizeof(buffer));
if (n>0) {
printf("rx: %s\n", buffer);
} else {
printf("bad things\n");
}
}
}
> > am i missing something? is this worth fixing in the library? is this
> > intended behavior?
Re: Resetting DTLS server
On 2019-11-12 9:30 p.m., Patrick Herbst wrote:
> On Tue, Nov 12, 2019 at 3:00 AM Michael Richardson wrote:
>> Close the UDP socket on the client and open a new one to get a new
>> source port.
>> Does that work? I'm not terribly happy with this solution, but it does
>> match what TCP would do.
>>
> In general, here is what i do (assuming only 1 client for proof of
> concept, and skipping some mundane steps)
> also assuming the client is using the same addr/port, so "connect"
> would not make a difference.
so you are showing me your server code, correct, and this is for DTLS,
right?
Do you call DTLSv1_accept()?
You don't seem to be creating a new socket anywhere, or calling
connect() on this socket.
I'm not sure I understand your comment above about connect would not be
a difference.
If your DGRAM socket is not connected, how can you send packets back?
It would be nice
if DTLS code would store the origin of every packet and demux it into
multiple SSL*, but it doesn't work that way.
>
> s=socket(AF_INET, SOCK_DGRAM, 0);
> bind(s, , sizeof(serverAddr));
> ssl=SSL_new(ctx);
> bio=BIO_new_dgram(s, BIO_NOCLOSE);
> SSL_accept(ssl);
>
> while (1) {
> select(FD_SETSIZE, fds, NULL, NULL, NULL);
> if (FD_ISSET(s)) {
> n=SSL_read(ssl, buffer, sizeof(buffer));
> if (n>0) {
> printf("rx: %s\n", buffer);
> } else {
> printf("bad things\n");
> }
> }
> }
>
> What happens is form the Server standpoint, it doesn't know when a
> client restarts. When the client does restart, the server blocks on
> SSL_read while the internals of the library keep reading packets until
> it gets app data... so it ignores another clienthello, but doesn't
> notify the server of that condition.
>
> am i missing something? is this worth fixing in the library? is this
> intended behavior?
signature.asc
Description: OpenPGP digital signature
Re: Resetting DTLS server
On Tue, Nov 12, 2019 at 3:00 AM Michael Richardson wrote:
> On 2019-11-12 7:38 a.m., Patrick Herbst wrote:
> > If i setup a DTLS server, the client can connect once and send
> > messages find. but if the client restarts and tries to send data, the
> > server hangs on SSL_read.
>
> How are you handling the sockets on the server?
> If you are creating a new 5-tuple [bind/connect] socket on the server
> for each client, and the client then reuses it's socket, then it's
> trying to speak the old instance on the server.
> > I'm assuming the server does not like a clienthello message when it is
> > expecting application data.
> >
> > How can the server be made to recover and re-handshake with the
> > restarted client?
>
> Close the UDP socket on the client and open a new one to get a new
> source port.
> Does that work? I'm not terribly happy with this solution, but it does
> match what TCP would do.
>
In general, here is what i do (assuming only 1 client for proof of
concept, and skipping some mundane steps)
also assuming the client is using the same addr/port, so "connect"
would not make a difference.
s=socket(AF_INET, SOCK_DGRAM, 0);
bind(s, , sizeof(serverAddr));
ssl=SSL_new(ctx);
bio=BIO_new_dgram(s, BIO_NOCLOSE);
SSL_accept(ssl);
while (1) {
select(FD_SETSIZE, fds, NULL, NULL, NULL);
if (FD_ISSET(s)) {
n=SSL_read(ssl, buffer, sizeof(buffer));
if (n>0) {
printf("rx: %s\n", buffer);
} else {
printf("bad things\n");
}
}
}
What happens is form the Server standpoint, it doesn't know when a
client restarts. When the client does restart, the server blocks on
SSL_read while the internals of the library keep reading packets until
it gets app data... so it ignores another clienthello, but doesn't
notify the server of that condition.
am i missing something? is this worth fixing in the library? is this
intended behavior?
Re: Problems porting Openssl 1.1.1d to zos.
> An error occurred during a connection to cafe.na.tibco.com:1802. SSL > received a record with an incorrect Message Authentication Code. Error > code: SSL_ERROR_BAD_MAC_READ In case this error occurs with a chacha-poly cipher suite, the following PR probably has a fix: https://github.com/openssl/openssl/pull/10417 Patrick
Re: Problems porting Openssl 1.1.1d to zos.
Please see also GitHub issue #4154, in particular https://github.com/openssl/openssl/issues/4154#issuecomment-552838141
Re: Help on Diffie Hellman key exchange
On Mon, 2019-11-04 at 17:34 -0500, Jason Qian via openssl-users wrote: > Hi > >We have an application that does the Diffie Hellman key exchange > (OpenSSL/1.1.0f). >It works fine, but under heavy loaded conditions, sometimes an > invalide secret been generated and other side couldn't decrypt the > data (the secret seems offset by one). > >The client side is c++ and the server side is java. > > DH_compute_key(secretKey, bnY, m_DH); > >Someone in the openssl group also talks about a similar issue, but > not sure if have a solution. Could it be a padding issue? I.E. use DH_compute_key_padded() instead. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Re: Resetting DTLS server
On 2019-11-12 7:38 a.m., Patrick Herbst wrote: > If i setup a DTLS server, the client can connect once and send > messages find. but if the client restarts and tries to send data, the > server hangs on SSL_read. How are you handling the sockets on the server? If you are creating a new 5-tuple [bind/connect] socket on the server for each client, and the client then reuses it's socket, then it's trying to speak the old instance on the server. > I'm assuming the server does not like a clienthello message when it is > expecting application data. > > How can the server be made to recover and re-handshake with the > restarted client? Close the UDP socket on the client and open a new one to get a new source port. Does that work? I'm not terribly happy with this solution, but it does match what TCP would do. signature.asc Description: OpenPGP digital signature
