Re: OpenSSL 1.1.1 Windows dependencies
Hi David, I just did a check to see what Windows libraries the openssl.exe app depends on, going back to look in 1.0.2, and looking at the current development branch (master). 1.0.2: ws2_32.lib(cond: no-sock) gdi32.lib advapi32.lib crypt32.lib user32.lib bufferoverflowu.lib (cond: cl version 14+) unicows.lib (cond: win32 && -DUNICODE) master: ws2_32.lib(cond: no-sock) gdi32.lib advapi32.lib crypt32.lib user32.lib bufferoverflowu.lib (cond: cl version 14+) As you can see, it hasn't changed much (the unicows.lib dependency was there for Win9x compatibility, according to comments). But, it's quite possible that those libraries have dependencies of their own that have changed in newer Windows versions. Let me ask you this: on what Windows version was your application built? Common wisdom would be to build on the oldest version... Cheers, Richard On Thu, 20 Oct 2022 02:54:19 +0200, David Harris wrote: > > Up front, I'd like to apologize if this is an FAQ or has been answered > elsewhere > on this list: my workload means that I simply can't keep as up-to-date as I > would > like. > > I have a situation where my application fails to accept an incoming SSL > handshake on Windows Server 2012, but the identical software running on > Server 2019 accepts the same connection from the same remote client without > a problem. Other types of client software (such as Thunderbird) connect to > either system without any problems. The connecting client is a Windows Cash > Register using Window's built-in crypto facilities. If I downgrade my app to > OpenSSL 1.1.1g or earlier, the problem doesn't happen. With 1.1.1k or 1.1.1q, > I > get the error (I haven't built any versions of OpenSSL between k and q). In > case > it helps, the connection is an incoming SMTP connection on port 587, and > STARTTLS is used to begin SSL negotiation. > > SSL_accept returns -1, with an extended error of "SSL_ERROR_SYSCALL" (5), > which I understand to be largely what it returns when it doesn't have a clear > idea > of what's gone wrong. The error queue is completely empty in this situation. > The > cert is a LetsEncrypt cert that loads without errors and works fine with > other > clients. > > Do recent versions of OpenSSL 1.1.1 have dependencies on some Windows > facility (winsock and wincrypt seem likely candidates) that might work on > Server > 2019 but fail on Server 2012? > > The version of my application that is in public release uses 1.1.1g, so isn't > affected by this issue, but I'm slightly worried that I'm going to see an > uptick in > this type of problem if I release builds based on later versions of 1.1.1. > > Does this ring any bells with anyone? Again, apologies if this is answered > elsewhere - I *did* spend some time in Google but couldn't find anything that > seemed relevant. > > Thanks in advance for any advice. > > Cheers! > > -- David -- > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
RE: OpenSSL 1.1.1 Windows dependencies
> From: openssl-users On Behalf Of David > Harris > Sent: Wednesday, 19 October, 2022 18:54 > > Do recent versions of OpenSSL 1.1.1 have dependencies on some Windows > facility (winsock and wincrypt seem likely candidates) that might work on > Server 2019 but fail on Server 2012? OpenSSL on Windows has always had a dependency on Winsock/Winsock2 (see b_sock.c, e_os.h, sockets.h) for supporting socket BIOs. Obviously OpenSSL used for TLS is going to be interacting with Winsock. I can't think of any difference between Server 2012 and Server 2019 that would be relevant to the issue you describe. OpenSSL 1.1.1 uses Windows cryptographic routines in two areas I'm aware of: rand_win.c and the CAPI engine. I don't offhand see a way that a problem with the calls in rand_win.c would cause the particular symptom you described. My guess is that you're not using the CAPI engine, but you might check your OpenSSL configuration on the failing system. I think more plausible causes of this failure are things like OpenSSL configuration and interference from other software such as an endpoint firewall. Getting SYSCALL from SSL_accept *really* looks like network-stack-level interference, from a firewall or similar mechanism. Personally, if I ran into this, I'd just build OpenSSL for debug and debug into it. But I know that's not everyone's cup of tea. -- Michael Wojcik
Fwd: Proper API usage with DTLS over custom net transport
Hello,
I would be really grateful if someone can point me in the right direction
with proper OpenSSL API usage in the following scenario.
I have a custom network transport - ICE (essentially UDP socket, as a part
of typical WebRTC stack) and I need to implement a DTLS connection over it.
So given some hints from the internet I assume that using BIO_s_mem is a
tool of choice in this situation.
Suppose SSL_CTX, SSL, BIOs are created and ready.
Overall my current understanding of API usage is somewhere like this (very
broad strokes, kind of pseudocode):
if (client) SSL_set_connect_state();
if (server) SSL_set_accept_state();
while (true)
{
// On initial iteration this would make OpenSSL put some data for us to
read from out_BIO to send it over
// if we are client, and don't put anything if we are server
// On following iterations pretty much the same behaviour remains.
SSL_do_handshake();
if (out_BIO_has_data) send_data_from_out_BIO_to_net();
// So at some loop iteration on line above we've sent everything
OpenSSL wanted us to send and
// OpenSSL tells us handshake is done, so we quit the loop
if (SSL_is_init_finished()) break;
// We've sent some flight of DTLS handshake, but there could be need to
retransmit
// we ask for retransmit timeout
timeout = DTLSv1_get_timeout();
// "select"-like machinery
wait_for_timeout_or_socket_data();
if (select_resulted_in_timeout)
{
// I assume this is going to generate DTLS-protocol-wise correct
retransmission flight data in out_BIO
DTLSv1_handle_timeout();
continue;
}
// socket_data that is going to be put in in_BIO is about to be
processed by OpenSSL internals in next SSL_do_handshake() on next loop iter
above
if (select_resulted_in_socket_data) put_socket_data_to_in_BIO();
}
// So here I assume as client we've got last flight from server and ready
to send data
// And if we are a server we've sent out last flight, but we don't know
whether it has got through
// So if everything more or less correct up to this point we can expect
multiplexed traffic on ICE "socket": SRTP, SRTCP, and DTLS
// DeMultiplexing is not a problem (some RFCs cover this)
while (true)
{
sock_data = read_socket_data();
if (is_rtp(sock_data)) ...;
if (is_rtcp(sock_data)) ...;
if (is_dtls(sock_data))
}
So now the questions:
(1) If we receive some dtls data at the line above with '' what should
we do in terms of OpenSSL API calls ? I assume this dtls data could be a
client's retransmission due to server's last flight was lost or this could
be client receiving server's last flight duplicated (theoretically
could happen as long as lower layer protocol is UDP) or this could be
DTLS-encrypted real-app data or this could be DTLS-renegotiation, this also
could be a DTLS shutdown alert and anything else DTSL-related. What is the
supposed way of inferring and reacting to those different events with API ?
(2) Is the whole usage of OpenSSL even right for this scenario - maybe the
structure and sequence of API calls should be rearranged somehow ?
(3) There is an option to pass custom info_callback
with SSL_CTX_set_info_callback(). Would there be a proper usage of
this kind of callback in this scenario ?
Any other input, links to any kind of relevant supplemental material is
really appreciated.
Thanks a lot for reading, very special thanks to authors and maintainers
for all the hard work on this project.
---
Regards,
Pavel.
Resources and reading materials for installing Godaddy Wildcard SSL certificate in Fortigate firewall
Subject: Resources and reading materials for installing Godaddy Wildcard SSL certificate in Fortigate firewall Good day from Singapore, The following is a list of reference guides which I have read. [1] Fortigate firewall: Purchase and import a signed SSL certificate Link: https://docs.fortinet.com/document/fortigate/6.2.3/cookbook/825073/purchase-and-import-a-signed-ssl-certificate [2] WHAT IS A SAN (SUBJECT ALTERNATIVE NAME) AND HOW IS IT USED? Link: https://www.entrust.com/blog/2019/03/what-is-a-san-and-how-is-it-used/ [3] FortiGate Users: How to Install a Wildcard SSL Certificate Link: https://cheapsslsecurity.com/p/fortigate-users-how-to-install-a-wildcard-ssl-certificate/ [4] Export Certificates and Private Key from a PKCS#12 File with OpenSSL Link: https://www.ssl.com/how-to/export-certificates-private-key-from-pkcs12-file-with-openssl/ [5] 4 Simple Steps to Install a Fortigate SSL Certificate Link: https://comodosslstore.com/resources/steps-to-install-a-fortigate-ssl-certificate/ [6] OpenSSL Binaries Link: https://wiki.openssl.org/index.php/Binaries [7] Manually Generate a Certificate Signing Request (CSR) Using OpenSSL Link: https://www.ssl.com/how-to/manually-generate-a-certificate-signing-request-csr-using-openssl/ [8] FireDaemon OpenSSL 3.0 and 1.1.1 Binary Distributions for Microsoft Windows Link: https://kb.firedaemon.com/support/solutions/articles/4000121705 [9] CSR Decoder Link: https://www.sslshopper.com/csr-decoder.html As a result of studying the above reference guides, I have successfully installed Godaddy Wildcard SSL certificate (2 years) in Fortigate 201F firewall for an investment company in Keppel Road, Singapore on 20 Oct 2022 Thursday between 10.30 AM and 4.00 PM Singapore Time. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com
